---

yaml
---
r: 114476
b: refs/heads/master
c: a5f08a3
h: refs/heads/master
v: v3

[refs]

@@ -1,2 +1,2 @@
 ---
-refs/heads/master: e413b210c541acac1a194085627db28a122f3bdf
+refs/heads/master: a5f08a327abc45eb6cb3cc1f5fabf38607ae2acc

trunk/Documentation/ABI/testing/sysfs-class-regulator

@@ -1,7 +1,7 @@
 What:		/sys/class/regulator/.../state
 Date:		April 2008
 KernelVersion:	2.6.26
-Contact:	Liam Girdwood <lrg@slimlogic.co.uk>
+Contact:	Liam Girdwood <lg@opensource.wolfsonmicro.com>
 Description:
 		Each regulator directory will contain a field called
 		state. This holds the regulator output state.
@@ -27,7 +27,7 @@ Description:
 What:		/sys/class/regulator/.../type
 Date:		April 2008
 KernelVersion:	2.6.26
-Contact:	Liam Girdwood <lrg@slimlogic.co.uk>
+Contact:	Liam Girdwood <lg@opensource.wolfsonmicro.com>
 Description:
 		Each regulator directory will contain a field called
 		type. This holds the regulator type.
@@ -51,7 +51,7 @@ Description:
 What:		/sys/class/regulator/.../microvolts
 Date:		April 2008
 KernelVersion:	2.6.26
-Contact:	Liam Girdwood <lrg@slimlogic.co.uk>
+Contact:	Liam Girdwood <lg@opensource.wolfsonmicro.com>
 Description:
 		Each regulator directory will contain a field called
 		microvolts. This holds the regulator output voltage setting
@@ -65,7 +65,7 @@ Description:
 What:		/sys/class/regulator/.../microamps
 Date:		April 2008
 KernelVersion:	2.6.26
-Contact:	Liam Girdwood <lrg@slimlogic.co.uk>
+Contact:	Liam Girdwood <lg@opensource.wolfsonmicro.com>
 Description:
 		Each regulator directory will contain a field called
 		microamps. This holds the regulator output current limit
@@ -79,7 +79,7 @@ Description:
 What:		/sys/class/regulator/.../opmode
 Date:		April 2008
 KernelVersion:	2.6.26
-Contact:	Liam Girdwood <lrg@slimlogic.co.uk>
+Contact:	Liam Girdwood <lg@opensource.wolfsonmicro.com>
 Description:
 		Each regulator directory will contain a field called
 		opmode. This holds the regulator operating mode setting.
@@ -102,7 +102,7 @@ Description:
 What:		/sys/class/regulator/.../min_microvolts
 Date:		April 2008
 KernelVersion:	2.6.26
-Contact:	Liam Girdwood <lrg@slimlogic.co.uk>
+Contact:	Liam Girdwood <lg@opensource.wolfsonmicro.com>
 Description:
 		Each regulator directory will contain a field called
 		min_microvolts. This holds the minimum safe working regulator
@@ -116,7 +116,7 @@ Description:
 What:		/sys/class/regulator/.../max_microvolts
 Date:		April 2008
 KernelVersion:	2.6.26
-Contact:	Liam Girdwood <lrg@slimlogic.co.uk>
+Contact:	Liam Girdwood <lg@opensource.wolfsonmicro.com>
 Description:
 		Each regulator directory will contain a field called
 		max_microvolts. This holds the maximum safe working regulator
@@ -130,7 +130,7 @@ Description:
 What:		/sys/class/regulator/.../min_microamps
 Date:		April 2008
 KernelVersion:	2.6.26
-Contact:	Liam Girdwood <lrg@slimlogic.co.uk>
+Contact:	Liam Girdwood <lg@opensource.wolfsonmicro.com>
 Description:
 		Each regulator directory will contain a field called
 		min_microamps. This holds the minimum safe working regulator
@@ -145,7 +145,7 @@ Description:
 What:		/sys/class/regulator/.../max_microamps
 Date:		April 2008
 KernelVersion:	2.6.26
-Contact:	Liam Girdwood <lrg@slimlogic.co.uk>
+Contact:	Liam Girdwood <lg@opensource.wolfsonmicro.com>
 Description:
 		Each regulator directory will contain a field called
 		max_microamps. This holds the maximum safe working regulator
@@ -157,23 +157,10 @@ Description:
 		platform code.
 
 
-What:		/sys/class/regulator/.../name
-Date:		October 2008
-KernelVersion:	2.6.28
-Contact:	Liam Girdwood <lrg@slimlogic.co.uk>
-Description:
-		Each regulator directory will contain a field called
-		name. This holds a string identifying the regulator for
-		display purposes.
-
-		NOTE: this will be empty if no suitable name is provided
-		by platform or regulator drivers.
-
-
 What:		/sys/class/regulator/.../num_users
 Date:		April 2008
 KernelVersion:	2.6.26
-Contact:	Liam Girdwood <lrg@slimlogic.co.uk>
+Contact:	Liam Girdwood <lg@opensource.wolfsonmicro.com>
 Description:
 		Each regulator directory will contain a field called
 		num_users. This holds the number of consumer devices that
@@ -183,7 +170,7 @@ Description:
 What:		/sys/class/regulator/.../requested_microamps
 Date:		April 2008
 KernelVersion:	2.6.26
-Contact:	Liam Girdwood <lrg@slimlogic.co.uk>
+Contact:	Liam Girdwood <lg@opensource.wolfsonmicro.com>
 Description:
 		Each regulator directory will contain a field called
 		requested_microamps. This holds the total requested load
@@ -194,15 +181,15 @@ Description:
 What:		/sys/class/regulator/.../parent
 Date:		April 2008
 KernelVersion:	2.6.26
-Contact:	Liam Girdwood <lrg@slimlogic.co.uk>
+Contact:	Liam Girdwood <lg@opensource.wolfsonmicro.com>
 Description:
 		Some regulator directories will contain a link called parent.
 		This points to the parent or supply regulator if one exists.
 
 What:		/sys/class/regulator/.../suspend_mem_microvolts
 Date:		May 2008
 KernelVersion:	2.6.26
-Contact:	Liam Girdwood <lrg@slimlogic.co.uk>
+Contact:	Liam Girdwood <lg@opensource.wolfsonmicro.com>
 Description:
 		Each regulator directory will contain a field called
 		suspend_mem_microvolts. This holds the regulator output
@@ -216,7 +203,7 @@ Description:
 What:		/sys/class/regulator/.../suspend_disk_microvolts
 Date:		May 2008
 KernelVersion:	2.6.26
-Contact:	Liam Girdwood <lrg@slimlogic.co.uk>
+Contact:	Liam Girdwood <lg@opensource.wolfsonmicro.com>
 Description:
 		Each regulator directory will contain a field called
 		suspend_disk_microvolts. This holds the regulator output
@@ -230,7 +217,7 @@ Description:
 What:		/sys/class/regulator/.../suspend_standby_microvolts
 Date:		May 2008
 KernelVersion:	2.6.26
-Contact:	Liam Girdwood <lrg@slimlogic.co.uk>
+Contact:	Liam Girdwood <lg@opensource.wolfsonmicro.com>
 Description:
 		Each regulator directory will contain a field called
 		suspend_standby_microvolts. This holds the regulator output
@@ -244,7 +231,7 @@ Description:
 What:		/sys/class/regulator/.../suspend_mem_mode
 Date:		May 2008
 KernelVersion:	2.6.26
-Contact:	Liam Girdwood <lrg@slimlogic.co.uk>
+Contact:	Liam Girdwood <lg@opensource.wolfsonmicro.com>
 Description:
 		Each regulator directory will contain a field called
 		suspend_mem_mode. This holds the regulator operating mode
@@ -258,7 +245,7 @@ Description:
 What:		/sys/class/regulator/.../suspend_disk_mode
 Date:		May 2008
 KernelVersion:	2.6.26
-Contact:	Liam Girdwood <lrg@slimlogic.co.uk>
+Contact:	Liam Girdwood <lg@opensource.wolfsonmicro.com>
 Description:
 		Each regulator directory will contain a field called
 		suspend_disk_mode. This holds the regulator operating mode
@@ -271,7 +258,7 @@ Description:
 What:		/sys/class/regulator/.../suspend_standby_mode
 Date:		May 2008
 KernelVersion:	2.6.26
-Contact:	Liam Girdwood <lrg@slimlogic.co.uk>
+Contact:	Liam Girdwood <lg@opensource.wolfsonmicro.com>
 Description:
 		Each regulator directory will contain a field called
 		suspend_standby_mode. This holds the regulator operating mode
@@ -285,7 +272,7 @@ Description:
 What:		/sys/class/regulator/.../suspend_mem_state
 Date:		May 2008
 KernelVersion:	2.6.26
-Contact:	Liam Girdwood <lrg@slimlogic.co.uk>
+Contact:	Liam Girdwood <lg@opensource.wolfsonmicro.com>
 Description:
 		Each regulator directory will contain a field called
 		suspend_mem_state. This holds the regulator operating state
@@ -300,7 +287,7 @@ Description:
 What:		/sys/class/regulator/.../suspend_disk_state
 Date:		May 2008
 KernelVersion:	2.6.26
-Contact:	Liam Girdwood <lrg@slimlogic.co.uk>
+Contact:	Liam Girdwood <lg@opensource.wolfsonmicro.com>
 Description:
 		Each regulator directory will contain a field called
 		suspend_disk_state. This holds the regulator operating state
@@ -315,7 +302,7 @@ Description:
 What:		/sys/class/regulator/.../suspend_standby_state
 Date:		May 2008
 KernelVersion:	2.6.26
-Contact:	Liam Girdwood <lrg@slimlogic.co.uk>
+Contact:	Liam Girdwood <lg@opensource.wolfsonmicro.com>
 Description:
 		Each regulator directory will contain a field called
 		suspend_standby_state. This holds the regulator operating

trunk/Documentation/feature-removal-schedule.txt

@@ -287,13 +287,6 @@ Who:	Glauber Costa <gcosta@redhat.com>
 
 ---------------------------
 
-What:	remove HID compat support
-When:	2.6.29
-Why:	needed only as a temporary solution until distros fix themselves up
-Who:	Jiri Slaby <jirislaby@gmail.com>
-
----------------------------
-
 What:	/sys/o2cb symlink
 When:	January 2010
 Why:	/sys/fs/o2cb is the proper location for this information - /sys/o2cb

trunk/Documentation/filesystems/ocfs2.txt

@@ -76,9 +76,3 @@ localalloc=8(*)		Allows custom localalloc size in MB. If the value is too
 			large, the fs will silently revert it to the default.
 			Localalloc is not enabled for local mounts.
 localflocks		This disables cluster aware flock.
-inode64			Indicates that Ocfs2 is allowed to create inodes at
-			any location in the filesystem, including those which
-			will result in inode numbers occupying more than 32
-			bits of significance.
-user_xattr	(*)	Enables Extended User Attributes.
-nouser_xattr		Disables Extended User Attributes.

trunk/Documentation/power/regulator/machine.txt

@@ -2,8 +2,17 @@ Regulator Machine Driver Interface
 ===================================
 
 The regulator machine driver interface is intended for board/machine specific
-initialisation code to configure the regulator subsystem.
+initialisation code to configure the regulator subsystem. Typical things that
+machine drivers would do are :-
 
+ 1. Regulator -> Device mapping.
+ 2. Regulator supply configuration.
+ 3. Power Domain constraint setting.
+
+
+
+1. Regulator -> device mapping
+==============================
 Consider the following machine :-
 
   Regulator-1 -+-> Regulator-2 --> [Consumer A @ 1.8 - 2.0V]
@@ -12,82 +21,81 @@ Consider the following machine :-
 
 The drivers for consumers A & B must be mapped to the correct regulator in
 order to control their power supply. This mapping can be achieved in machine
-initialisation code by creating a struct regulator_consumer_supply for
-each regulator.
-
-struct regulator_consumer_supply {
-	struct device *dev;	/* consumer */
-	const char *supply;	/* consumer supply - e.g. "vcc" */
-};
+initialisation code by calling :-
 
-e.g. for the machine above
+int regulator_set_device_supply(const char *regulator, struct device *dev,
+				const char *supply);
 
-static struct regulator_consumer_supply regulator1_consumers[] = {
-{
-	.dev	= &platform_consumerB_device.dev,
-	.supply	= "Vcc",
-},};
+and is shown with the following code :-
 
-static struct regulator_consumer_supply regulator2_consumers[] = {
-{
-	.dev	= &platform_consumerA_device.dev,
-	.supply	= "Vcc",
-},};
+regulator_set_device_supply("Regulator-1", devB, "Vcc");
+regulator_set_device_supply("Regulator-2", devA, "Vcc");
 
 This maps Regulator-1 to the 'Vcc' supply for Consumer B and maps Regulator-2
 to the 'Vcc' supply for Consumer A.
 
-Constraints can now be registered by defining a struct regulator_init_data
-for each regulator power domain. This structure also maps the consumers
-to their supply regulator :-
-
-static struct regulator_init_data regulator1_data = {
-	.constraints = {
-		.min_uV = 3300000,
-		.max_uV = 3300000,
-		.valid_modes_mask = REGULATOR_MODE_NORMAL,
-	},
-	.num_consumer_supplies = ARRAY_SIZE(regulator1_consumers),
-	.consumer_supplies = regulator1_consumers,
-};
+
+2. Regulator supply configuration.
+==================================
+Consider the following machine (again) :-
+
+  Regulator-1 -+-> Regulator-2 --> [Consumer A @ 1.8 - 2.0V]
+               |
+               +-> [Consumer B @ 3.3V]
 
 Regulator-1 supplies power to Regulator-2. This relationship must be registered
 with the core so that Regulator-1 is also enabled when Consumer A enables it's
-supply (Regulator-2). The supply regulator is set by the supply_regulator_dev
-field below:-
-
-static struct regulator_init_data regulator2_data = {
-	.supply_regulator_dev = &platform_regulator1_device.dev,
-	.constraints = {
-		.min_uV = 1800000,
-		.max_uV = 2000000,
-		.valid_ops_mask = REGULATOR_CHANGE_VOLTAGE,
-		.valid_modes_mask = REGULATOR_MODE_NORMAL,
-	},
-	.num_consumer_supplies = ARRAY_SIZE(regulator2_consumers),
-	.consumer_supplies = regulator2_consumers,
+supply (Regulator-2).
+
+This relationship can be register with the core via :-
+
+int regulator_set_supply(const char *regulator, const char *regulator_supply);
+
+In this example we would use the following code :-
+
+regulator_set_supply("Regulator-2", "Regulator-1");
+
+Relationships can be queried by calling :-
+
+const char *regulator_get_supply(const char *regulator);
+
+
+3. Power Domain constraint setting.
+===================================
+Each power domain within a system has physical constraints on voltage and
+current. This must be defined in software so that the power domain is always
+operated within specifications.
+
+Consider the following machine (again) :-
+
+  Regulator-1 -+-> Regulator-2 --> [Consumer A @ 1.8 - 2.0V]
+               |
+               +-> [Consumer B @ 3.3V]
+
+This gives us two regulators and two power domains:
+
+                   Domain 1: Regulator-2, Consumer B.
+                   Domain 2: Consumer A.
+
+Constraints can be registered by calling :-
+
+int regulator_set_platform_constraints(const char *regulator,
+	struct regulation_constraints *constraints);
+
+The example is defined as follows :-
+
+struct regulation_constraints domain_1 = {
+	.min_uV = 3300000,
+	.max_uV = 3300000,
+	.valid_modes_mask = REGULATOR_MODE_NORMAL,
 };
 
-Finally the regulator devices must be registered in the usual manner.
-
-static struct platform_device regulator_devices[] = {
-{
-	.name = "regulator",
-	.id = DCDC_1,
-	.dev = {
-		.platform_data = &regulator1_data,
-	},
-},
-{
-	.name = "regulator",
-	.id = DCDC_2,
-	.dev = {
-		.platform_data = &regulator2_data,
-	},
-},
+struct regulation_constraints domain_2 = {
+	.min_uV = 1800000,
+	.max_uV = 2000000,
+	.valid_ops_mask = REGULATOR_CHANGE_VOLTAGE,
+	.valid_modes_mask = REGULATOR_MODE_NORMAL,
 };
-/* register regulator 1 device */
-platform_device_register(&wm8350_regulator_devices[0]);
 
-/* register regulator 2 device */
-platform_device_register(&wm8350_regulator_devices[1]);
+regulator_set_platform_constraints("Regulator-1", &domain_1);
+regulator_set_platform_constraints("Regulator-2", &domain_2);