OMAP System Control Module

From: Santosh Shilimkar <[email protected]>

Most of the OMAP4 control module register defines are not used and can be removed. Keep only needed defines and move them to common control module header just like other OMAP versions.

Signed-off-by Santosh Shilimkar <[email protected]>

Signed-off-by Eduardo Valentin <[email protected]>

---

This patch exposes the definitions under control.h to drivers outside the machine code.

Signed-off-by Eduardo Valentin <[email protected]>

---

Quoted 3 lines · Eduardo Valentin

This patch exposes the definitions under control.h to drivers outside the machine code.

Quoted 2 lines

Signed-off-by Eduardo Valentin <[email protected]>

---

After second thought, this complete header movement needs to avoided. Drivers should not anyway include something like <mach/control.h>

May be split the control.h header file data into ..
- defines used by mach-omap2/* files which can remain in "control.h" in existing location.

- common functions/defines used across drivers/*, mach-omap2/*, plat-omap/*, should
go to include/linux/omap_control.h

- Driver specific defines like thermal, usb etc, should go to respective drivers file.

What do you think ?

Regards
santosh

Hello,

Quoted 5 lines · Santosh

Quoted 3 lines · Eduardo Valentin

This patch exposes the definitions under control.h to drivers outside the machine code.

Quoted 8 lines

Quoted 2 lines

Signed-off-by Eduardo Valentin <[email protected]>

---

After second thought, this complete header movement needs to avoided. Drivers should not anyway include something like <mach/control.h>

May be split the control.h header file data into ..
- defines used by mach-omap2/* files which can remain in "control.h" in existing location.

OK..

Quoted 3 lines

- common functions/defines used across drivers/*, mach-omap2/*, plat-omap/*, should
go to include/linux/omap_control.h

Right..

Quoted 2 lines

- Driver specific defines like thermal, usb etc, should go to respective drivers file.

Indeed.

Quoted 2 lines

What do you think ?

I think we are in line. And I believe I saw a similar comment by Benoit in other email thread.

Having a better thinking of this, it makes sense to have the definition specific to drivers in the driver scope only, as they are going to be used only there anyway.

I will drop this patch off and update the remaining changes accordingly (drop the change in control.h for thermal specific and move it to omap_bandgap.h).

From: Kishon Vijay Abraham I<[email protected]>

Extracts the device data from hwmod database and create a platform device using omap device build.

The device build is done during postcore_initcall.

Signed-off-by Kishon Vijay Abraham I<[email protected]>

Signed-off-by Eduardo Valentin<[email protected]>

---
  arch/arm/mach-omap2/devices.c |   26 ++++++++++++++++++++++++++
  1 files changed, 26 insertions(+), 0 deletions(-)

arch/arm/mach-omap2/devices.c +26 -0

index 152c266..9332673 100644
@@ -40,6 +40,32 @@
  #define L3_MODULES_MAX_LEN 12
  #define L3_MODULES 3
 
+static int omap_init_control(void)
+{
+	struct omap_hwmod		*oh;
+	struct platform_device		*pdev;
+	const char			*oh_name, *name;
+
+	oh_name = "ctrl_module_core";
+	name = "omap-control-core";
+
+	oh = omap_hwmod_lookup(oh_name);
+	if (!oh) {
+		pr_err("Could not lookup hwmod for %s\n", oh_name);
+		return PTR_ERR(oh);
+	}
+
+	pdev = omap_device_build(name, -1, oh, NULL, 0, NULL, 0, true);
+	if (IS_ERR(pdev)) {
+		pr_err("Could not build omap_device for %s %s\n",
+		       name, oh_name);
+		return PTR_ERR(pdev);
+	}
+
+	return 0;
+}
+postcore_initcall(omap_init_control);
+
  static int __init omap3_l3_init(void)
  {
  	struct omap_hwmod *oh;

Quoted 6 lines · Eduardo Valentin

From: Kishon Vijay Abraham I<[email protected]>

Extracts the device data from hwmod database and create a platform device using omap device build.

The device build is done during postcore_initcall.

Do you still need that since you are supporting only DT? The device will be built automatically in the DT case.

Regards,
Benoit

Quoted 44 lines

Signed-off-by Kishon Vijay Abraham I<[email protected]>

Signed-off-by Eduardo Valentin<[email protected]>

---
 arch/arm/mach-omap2/devices.c |   26 ++++++++++++++++++++++++++
 1 files changed, 26 insertions(+), 0 deletions(-)

arch/arm/mach-omap2/devices.c +26 -0

index 152c266..9332673 100644
@@ -40,6 +40,32 @@
 #define L3_MODULES_MAX_LEN 12
 #define L3_MODULES 3
 
+static int omap_init_control(void)
+{
+	struct omap_hwmod		*oh;
+	struct platform_device		*pdev;
+	const char			*oh_name, *name;
+
+	oh_name = "ctrl_module_core";
+	name = "omap-control-core";
+
+	oh = omap_hwmod_lookup(oh_name);
+	if (!oh) {
+		pr_err("Could not lookup hwmod for %s\n", oh_name);
+		return PTR_ERR(oh);
+	}
+
+	pdev = omap_device_build(name, -1, oh, NULL, 0, NULL, 0, true);
+	if (IS_ERR(pdev)) {
+		pr_err("Could not build omap_device for %s %s\n",
+		       name, oh_name);
+		return PTR_ERR(pdev);
+	}
+
+	return 0;
+}
+postcore_initcall(omap_init_control);
+
 static int __init omap3_l3_init(void)
 {
 	struct omap_hwmod *oh;

Quoted 9 lines · Cousson Benoit

Quoted 6 lines · Eduardo Valentin

From: Kishon Vijay Abraham I<[email protected]>

Extracts the device data from hwmod database and create a platform device using omap device build.

The device build is done during postcore_initcall.

Do you still need that since you are supporting only DT? The device will be built automatically in the DT case.

In fact this is not needed for DT only probing. Dropping this one.

Quoted 47 lines

Regards,
Benoit

Quoted 43 lines

Signed-off-by Kishon Vijay Abraham I<[email protected]>

Signed-off-by Eduardo Valentin<[email protected]>

---
 arch/arm/mach-omap2/devices.c |   26 ++++++++++++++++++++++++++
 1 files changed, 26 insertions(+), 0 deletions(-)

arch/arm/mach-omap2/devices.c +26 -0

index 152c266..9332673 100644
@@ -40,6 +40,32 @@
 #define L3_MODULES_MAX_LEN 12
 #define L3_MODULES 3
 
+static int omap_init_control(void)
+{
+	struct omap_hwmod		*oh;
+	struct platform_device		*pdev;
+	const char			*oh_name, *name;
+
+	oh_name = "ctrl_module_core";
+	name = "omap-control-core";
+
+	oh = omap_hwmod_lookup(oh_name);
+	if (!oh) {
+		pr_err("Could not lookup hwmod for %s\n", oh_name);
+		return PTR_ERR(oh);
+	}
+
+	pdev = omap_device_build(name, -1, oh, NULL, 0, NULL, 0, true);
+	if (IS_ERR(pdev)) {
+		pr_err("Could not build omap_device for %s %s\n",
+		       name, oh_name);
+		return PTR_ERR(pdev);
+	}
+
+	return 0;
+}
+postcore_initcall(omap_init_control);
+
 static int __init omap3_l3_init(void)
 {
 	struct omap_hwmod *oh;

?Hi.

Quoted 4 lines · Eduardo Valentin

Quoted 3 lines · Cousson Benoit

Quoted 2 lines · Eduardo Valentin

From: Kishon Vijay Abraham I<[email protected]>

Quoted 7 lines

Quoted 6 lines

Quoted 4 lines

Extracts the device data from hwmod database and create a platform device using omap device build.

The device build is done during postcore_initcall.

Do you still need that since you are supporting only DT? The device will be built automatically in the DT case.

In fact this is not needed for DT only probing. Dropping this one.

Yes, platform device(struct platform_device) will be built automatically, but omap device(struct omap_device) will not be built.

Also when omap device is allocated(omap_device_alloc) hwmod_clocks are registered, but in case of ctrl_module_core device - no new clock are registered. So, is it fine to drop omap device and skip omap_device_build() call?

?BR,
? ?Konstantin Baydarov.

Quoted 48 lines

Quoted 48 lines

Regards,
Benoit

Quoted 43 lines

Signed-off-by Kishon Vijay Abraham I<[email protected]>

Signed-off-by Eduardo Valentin<[email protected]>

---
?arch/arm/mach-omap2/devices.c | ? 26 ++++++++++++++++++++++++++ ?1 files changed, 26 insertions(+), 0 deletions(-)

arch/arm/mach-omap2/devices.c +0 -0

index 152c266..9332673 100644
@@ -40,6 +40,32 @@

?#define L3_MODULES_MAX_LEN 12
?#define L3_MODULES 3

arch/arm/mach-omap2/devices.c +26 -0

+static int omap_init_control(void)
+{
+ ? struct omap_hwmod ? ? ? ? ? ? ? *oh;
+ ? struct platform_device ? ? ? ? ?*pdev;
+ ? const char ? ? ? ? ? ? ? ? ? ? ?*oh_name, *name;
+
+ ? oh_name = "ctrl_module_core";
+ ? name = "omap-control-core";
+
+ ? oh = omap_hwmod_lookup(oh_name);
+ ? if (!oh) {
+ ? ? ? ? ? pr_err("Could not lookup hwmod for %s\n", oh_name);
+ ? ? ? ? ? return PTR_ERR(oh);
+ ? }
+
+ ? pdev = omap_device_build(name, -1, oh, NULL, 0, NULL, 0, true);
+ ? if (IS_ERR(pdev)) {
+ ? ? ? ? ? pr_err("Could not build omap_device for %s %s\n",
+ ? ? ? ? ? ? ? ? ?name, oh_name);
+ ? ? ? ? ? return PTR_ERR(pdev);
+ ? }
+
+ ? return 0;
+}
+postcore_initcall(omap_init_control);
+

?static int __init omap3_l3_init(void)
?{
? ? struct omap_hwmod *oh;

From: Kishon Vijay Abraham I <[email protected]>

Extracts the device data from hwmod database and create a platform device using omap device build.

The device build is done during postcore_initcall.

Signed-off-by Kishon Vijay Abraham I <[email protected]>

Signed-off-by Eduardo Valentin <[email protected]>

---
 arch/arm/mach-omap2/devices.c |   26 ++++++++++++++++++++++++++
 1 files changed, 26 insertions(+), 0 deletions(-)

arch/arm/mach-omap2/devices.c +6 -0

index 152c266..9332673 100644
@@ -40,6 +40,32 @@
 #define L3_MODULES_MAX_LEN 12
 #define L3_MODULES 3
 
+static int omap_init_control(void)
+{
+	struct omap_hwmod		*oh;
+	struct platform_device		*pdev;
+	const char			*oh_name, *name;
+

arch/arm/mach-omap2/devices.c +10 -0

+	if (IS_ERR(pdev)) {
+		pr_err("Could not build omap_device for %s %s\n",
+		       name, oh_name);
+		return PTR_ERR(pdev);
+	}
+
+	return 0;
+}
+postcore_initcall(omap_init_control);
+
 static int __init omap3_l3_init(void)
 {
 	struct omap_hwmod *oh;

This is a way to add an early device for system control module. the code is also requesting for driver registration and probing. Done at early_initcall because at that time, ioremapping is possible.

Signed-off-by Eduardo Valentin <[email protected]>

---
 arch/arm/mach-omap2/devices.c |   29 +++++++++++++++++++++++++++++
 1 files changed, 29 insertions(+), 0 deletions(-)

arch/arm/mach-omap2/devices.c +14 -0

index 9332673..58cc5c3 100644
@@ -40,6 +40,35 @@
 #define L3_MODULES_MAX_LEN 12
 #define L3_MODULES 3
 
+static struct resource control_resources[] = {
+	[0] = {
+		.start	= 0x4a002000,
+		.end	= 0x4a0027ff,
+		.flags	= IORESOURCE_MEM,
+	},
+};
+static struct platform_device control_device = {
+	.name		= "omap-control-core",
+	.id		= 0,
+	.resource	= control_resources,
+	.num_resources	= ARRAY_SIZE(control_resources),
+};
+

arch/arm/mach-omap2/devices.c +5 -0

+
+	return 0;
+}
+early_initcall(plat_early_device_setup);
+
 static int omap_init_control(void)
 {
 	struct omap_hwmod		*oh;

?Hi , Eduardo.

Quoted 3 lines · Eduardo Valentin

This is a way to add an early device for system control module. the code is also requesting for driver registration and probing. Done at early_initcall because at that time, ioremapping is possible.

Quoted 28 lines

Signed-off-by Eduardo Valentin <[email protected]>

---
?arch/arm/mach-omap2/devices.c | ? 29 +++++++++++++++++++++++++++++ ?1 files changed, 29 insertions(+), 0 deletions(-)

arch/arm/mach-omap2/devices.c +0 -0

index 9332673..58cc5c3 100644
@@ -40,6 +40,35 @@

?#define L3_MODULES_MAX_LEN 12
?#define L3_MODULES 3

arch/arm/mach-omap2/devices.c +14 -0

+static struct resource control_resources[] = {
+ ? ? [0] = {
+ ? ? ? ? ? ? .start ?= 0x4a002000,
+ ? ? ? ? ? ? .end ? ?= 0x4a0027ff,
+ ? ? ? ? ? ? .flags ?= IORESOURCE_MEM,
+ ? ? },
+};
+static struct platform_device control_device = {
+ ? ? .name ? ? ? ? ? = "omap-control-core",
+ ? ? .id ? ? ? ? ? ? = 0,
+ ? ? .resource ? ? ? = control_resources,
+ ? ? .num_resources ?= ARRAY_SIZE(control_resources),
+};
+

arch/arm/mach-omap2/devices.c

Quoted 10 lines

arch/arm/mach-omap2/devices.c +10 -0

+static struct platform_device *early_devices[] __initdata = {
+ ? ? &control_device,
+};
+
+static int __init plat_early_device_setup(void)
+{
+ ? ? early_platform_add_devices(early_devices,
+ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?ARRAY_SIZE(early_devices));
+ ? ? early_platform_driver_register_all("early_omap_control");
+ ? ? early_platform_driver_probe("early_omap_control", 1, false);

I checked out git://gitorious.org/omap-thermal/omap-thermal.git omap_scm_dev.
Looks like that calling devm_kzalloc() and platform_get_resource() from early_initcall is too early.
I get following backtrace (probably the backtrace is kernel config dependent):
...
[ ? ?0.198455] [<c00193b4>] (unwind_backtrace+0x0/0xe0) from [<c02b2a10>] (do_raw_spin_lock+0x20/0x134)
[ ? ?0.207977] [<c02b2a10>] (do_raw_spin_lock+0x20/0x134) from [<c05df068>] (_raw_spin_lock_irqsave+0x58/0x64) [ ? ?0.218109] [<c05df068>] (_raw_spin_lock_irqsave+0x58/0x64) from [<c02f03bc>] (devres_add+0x18/0x38)
[ ? ?0.227600] [<c02f03bc>] (devres_add+0x18/0x38) from [<c02f07d0>] (devm_kzalloc+0x50/0x5c)
[ ? ?0.236206] [<c02f07d0>] (devm_kzalloc+0x50/0x5c) from [<c05c73a4>] (omap_control_probe+0x20/0xe4)
[ ? ?0.245544] [<c05c73a4>] (omap_control_probe+0x20/0xe4) from [<c07b3178>] (early_platform_driver_probe+0x1ac/0x23c) [ ? ?0.256378] [<c07b3178>] (early_platform_driver_probe+0x1ac/0x23c) from [<c0798030>] (plat_early_device_setup+0x2c/0x3c) [ ? ?0.267700] [<c0798030>] (plat_early_device_setup+0x2c/0x3c) from [<c078f8c4>] (do_one_initcall+0x90/0x164) [ ? ?0.277801] [<c078f8c4>] (do_one_initcall+0x90/0x164) from [<c078f9ec>] (kernel_init+0x54/0x1a4)
[ ? ?0.286956] [<c078f9ec>] (kernel_init+0x54/0x1a4) from [<c0013818>] (kernel_thread_exit+0x0/0x8)
[ ? ?0.296203] ------------[ cut here ]------------
[ ? ?0.301086] WARNING: at include/linux/kref.h:41 kobject_get+0x24/0x48()
[ ? ?0.308044] [<c00193b4>] (unwind_backtrace+0x0/0xe0) from [<c00394a4>] (warn_slowpath_common+0x48/0x60) [ ? ?0.317871] [<c00394a4>] (warn_slowpath_common+0x48/0x60) from [<c0039574>] (warn_slowpath_null+0x18/0x1c) [ ? ?0.327941] [<c0039574>] (warn_slowpath_null+0x18/0x1c) from [<c02a59b4>] (kobject_get+0x24/0x48)
[ ? ?0.337219] [<c02a59b4>] (kobject_get+0x24/0x48) from [<c02eb588>] (get_device+0x14/0x1c)
[ ? ?0.345764] [<c02eb588>] (get_device+0x14/0x1c) from [<c02eb66c>] (device_add+0xc4/0x594)
[ ? ?0.354370] [<c02eb66c>] (device_add+0xc4/0x594) from [<c03eeab4>] (of_platform_device_create_pdata+0x5c/0x7c) [ ? ?0.364807] [<c03eeab4>] (of_platform_device_create_pdata+0x5c/0x7c) from [<c03eec94>] (of_platform_bus_create+0x1c0/0x258) [ ? ?0.376403] [<c03eec94>] (of_platform_bus_create+0x1c0/0x258) from [<c03eee4c>] (of_platform_populate+0x5c/0x88) [ ? ?0.387023] [<c03eee4c>] (of_platform_populate+0x5c/0x88) from [<c07b3178>] (early_platform_driver_probe+0x1ac/0x23c) [ ? ?0.398101] [<c07b3178>] (early_platform_driver_probe+0x1ac/0x23c) from [<c0798030>] (plat_early_device_setup+0x2c/0x3c) [ ? ?0.409423] [<c0798030>] (plat_early_device_setup+0x2c/0x3c) from [<c078f8c4>] (do_one_initcall+0x90/0x164) [ ? ?0.419586] [<c078f8c4>] (do_one_initcall+0x90/0x164) from [<c078f9ec>] (kernel_init+0x54/0x1a4)
[ ? ?0.428771] [<c078f9ec>] (kernel_init+0x54/0x1a4) from [<c0013818>] (kernel_thread_exit+0x0/0x8)
[ ? ?0.437957] ---[ end trace da227214a82491b7 ]--
...

?BR,
? ?Konstantin Baydarov.

Quoted 8 lines

arch/arm/mach-omap2/devices.c +5 -0

+
+ ? ? return 0;
+}
+early_initcall(plat_early_device_setup);
+

?static int omap_init_control(void)
?{
? ? ? struct omap_hwmod ? ? ? ? ? ? ? *oh;

This is a way to add an early device for system control module. the code is also requesting for driver registration and probing. Done at early_initcall because at that time, ioremapping is possible.

Signed-off-by Eduardo Valentin <[email protected]>

---
 arch/arm/mach-omap2/devices.c |   29 +++++++++++++++++++++++++++++
 1 files changed, 29 insertions(+), 0 deletions(-)

arch/arm/mach-omap2/devices.c +0 -0

index 9332673..58cc5c3 100644

This is a way to add an early device for system control module. the code is also requesting for driver registration and probing. Done at early_initcall because at that time, ioremapping is possible.

Signed-off-by Eduardo Valentin<[email protected]>

---
  arch/arm/mach-omap2/devices.c |   29 +++++++++++++++++++++++++++++
  1 files changed, 29 insertions(+), 0 deletions(-)

arch/arm/mach-omap2/devices.c +0 -0

index 9332673..58cc5c3 100644

arch/arm/mach-omap2/devices.c +22 -0

+static struct platform_device control_device = {
+	.name		= "omap-control-core",
+	.id		= 0,
+	.resource	= control_resources,
+	.num_resources	= ARRAY_SIZE(control_resources),
+};
+
+static struct platform_device *early_devices[] __initdata = {
+	&control_device,
+};
+
+static int __init plat_early_device_setup(void)
+{
+	early_platform_add_devices(early_devices,
+				   ARRAY_SIZE(early_devices));
+	early_platform_driver_register_all("early_omap_control");
+	early_platform_driver_probe("early_omap_control", 1, false);
+
+	return 0;
+}
+early_initcall(plat_early_device_setup);
+
  static int omap_init_control(void)
  {
  	struct omap_hwmod		*oh;

This is a way to add an early device for system control module. the code is also requesting for driver registration and probing. Done at early_initcall because at that time, ioremapping is possible.

Signed-off-by Eduardo Valentin <[email protected]>

---
?arch/arm/mach-omap2/devices.c | ? 29 +++++++++++++++++++++++++++++ ?1 files changed, 29 insertions(+), 0 deletions(-)

arch/arm/mach-omap2/devices.c +0 -0

index 9332673..58cc5c3 100644
@@ -40,6 +40,35 @@

?#define L3_MODULES_MAX_LEN 12
?#define L3_MODULES 3

arch/arm/mach-omap2/devices.c +29 -0

+static struct resource control_resources[] = {
+ ? ? ? [0] = {
+ ? ? ? ? ? ? ? .start ?= 0x4a002000,
+ ? ? ? ? ? ? ? .end ? ?= 0x4a0027ff,
+ ? ? ? ? ? ? ? .flags ?= IORESOURCE_MEM,
+ ? ? ? },
+};
+static struct platform_device control_device = {
+ ? ? ? .name ? ? ? ? ? = "omap-control-core",
+ ? ? ? .id ? ? ? ? ? ? = 0,
+ ? ? ? .resource ? ? ? = control_resources,
+ ? ? ? .num_resources ?= ARRAY_SIZE(control_resources),
+};
+
+static struct platform_device *early_devices[] __initdata = {
+ ? ? ? &control_device,
+};
+
+static int __init plat_early_device_setup(void)
+{
+ ? ? ? early_platform_add_devices(early_devices,
+ ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?ARRAY_SIZE(early_devices));
+ ? ? ? early_platform_driver_register_all("early_omap_control");
+ ? ? ? early_platform_driver_probe("early_omap_control", 1, false);
+
+ ? ? ? return 0;
+}
+early_initcall(plat_early_device_setup);
+

?static int omap_init_control(void)
?{
? ? ? ?struct omap_hwmod ? ? ? ? ? ? ? *oh;

This patch introduces a MFD core device driver for OMAP system control module.

The control module allows software control of various static modes supported by the device. It is composed of two control submodules: general control module and device (padconfiguration) control module.

In this patch, the children defined are for:
. USB-phy pin control
. Bangap temperature sensor

Device driver is probed with postcore_initcall. However, as some of the APIs exposed by this driver may be needed in very early init phase, an early init class is also available: "early_omap_control".

Signed-off-by J Keerthy<[email protected]>

Signed-off-by Kishon Vijay Abraham I<[email protected]>

Signed-off-by Eduardo Valentin<[email protected]>

---
  .../devicetree/bindings/mfd/omap_control.txt       |   44 ++++
  arch/arm/mach-omap2/Kconfig                        |    1 +
  arch/arm/plat-omap/Kconfig                         |    3 +
  drivers/mfd/Kconfig                                |    9 +
  drivers/mfd/Makefile                               |    1 +
  drivers/mfd/omap-control-core.c                    |  211 ++++++++++++++++++++
  include/linux/mfd/omap_control.h                   |   69 +++++++
  7 files changed, 338 insertions(+), 0 deletions(-)

create mode 100644 Documentation/devicetree/bindings/mfd/omap_control.txt create mode 100644 drivers/mfd/omap-control-core.c
create mode 100644 include/linux/mfd/omap_control.h

Documentation/devicetree/bindings/mfd/omap_control.txt new file +44 -0

new file mode 100644
index 0000000..46d5e7e
@@ -0,0 +1,44 @@
+* Texas Instrument OMAP System Control Module (SCM) bindings
+
+The control module allows software control of various static modes supported by
+the device. The control module controls the settings of various device  modules
+through register configuration and internal signals. It also controls  the  pad
+configuration, pin functional multiplexing, and the routing of internal signals
+(such as PRCM  signals or DMA requests)  to output pins configured for hardware
+observability.
+
+Required properties:
+- compatible : Should be:
+  - "ti,omap3-control" for OMAP3 support
+  - "ti,omap4-control" for OMAP4 support
+  - "ti,omap5-control" for OMAP5 support
+
+OMAP specific properties:
+- ti,hwmods: Name of the hwmod associated to the control module:
+  Should be "ctrl_module_core";
+
+Sub-nodes:
+- bandgap : contains the bandgap node
+
+  The bindings details of individual bandgap device can be found in:
+  Documentation/devicetree/bindings/thermal/omap_bandgap.txt
+
+- usb : contains the usb phy pin control node
+
+  The only required property for this child is:
+    - compatible = "ti,omap4-control-usb";
+
+Examples:
+
+ctrl_module_core: ctrl_module_core at 4a002000 {
+	compatible = "ti,omap4-control";
+	ti,hwmods = "ctrl_module_core";
+	bandgap {
+		compatible = "ti,omap4460-bandgap";
+		interrupts =<0 126 4>; /* talert */
+		ti,tshut-gpio =<86>; /* tshut */
+	};
+	usb {
+		compatible = "ti,omap4-usb-phy";
+	};
+};

arch/arm/mach-omap2/Kconfig +1 -0

index a2b946d..7dfe5e1 100644
@@ -52,6 +52,7 @@ config ARCH_OMAP4
  	select PL310_ERRATA_727915
  	select ARM_ERRATA_720789
  	select ARCH_HAS_OPP
+	select ARCH_HAS_CONTROL_MODULE
  	select PM_OPP if PM
  	select USB_ARCH_HAS_EHCI if USB_SUPPORT
  	select ARM_CPU_SUSPEND if PM

arch/arm/plat-omap/Kconfig +3 -0

index ad95c7a..222dbad 100644
@@ -5,6 +5,9 @@ menu "TI OMAP Common Features"
  config ARCH_OMAP_OTG
  	bool
 
+config ARCH_HAS_CONTROL_MODULE
+	bool
+
  choice
  	prompt "OMAP System Type"
  	default ARCH_OMAP2PLUS

drivers/mfd/Kconfig +9 -0

index 11e4438..25a66d8 100644
@@ -795,6 +795,15 @@ config MFD_WL1273_CORE
  	  driver connects the radio-wl1273 V4L2 module and the wl1273
  	  audio codec.
 
+config MFD_OMAP_CONTROL
+	bool "Texas Instruments OMAP System control module"
+	depends on ARCH_HAS_CONTROL_MODULE
+	help
+	  This is the core driver for system control module. This driver
+	  is responsible for creating the control module mfd child,
+	  like USB-pin control, pin muxing, MMC-pbias and DDR IO dynamic
+	  change for off mode.
+
  config MFD_OMAP_USB_HOST
  	bool "Support OMAP USBHS core driver"
  	depends on USB_EHCI_HCD_OMAP || USB_OHCI_HCD_OMAP3

drivers/mfd/Makefile +1 -0

index 05fa538..00f99d6 100644
@@ -106,6 +106,7 @@ obj-$(CONFIG_MFD_TPS6586X)	+= tps6586x.o
  obj-$(CONFIG_MFD_VX855)		+= vx855.o
  obj-$(CONFIG_MFD_WL1273_CORE)	+= wl1273-core.o
  obj-$(CONFIG_MFD_CS5535)	+= cs5535-mfd.o
+obj-$(CONFIG_MFD_OMAP_CONTROL)	+= omap-control-core.o
  obj-$(CONFIG_MFD_OMAP_USB_HOST)	+= omap-usb-host.o
  obj-$(CONFIG_MFD_PM8921_CORE) 	+= pm8921-core.o
  obj-$(CONFIG_MFD_PM8XXX_IRQ) 	+= pm8xxx-irq.o

drivers/mfd/omap-control-core.c new file +24 -0

new file mode 100644
index 0000000..7d8d408
@@ -0,0 +1,211 @@
+/*
+ * OMAP system control module driver file
+ *
+ * Copyright (C) 2011-2012 Texas Instruments Incorporated - http://www.ti.com/
+ * Contacts:
+ * Based on original code written by:
+ *    J Keerthy<[email protected]>
+ *    Moiz Sonasath<[email protected]>
+ * MFD clean up and re-factoring:
+ *    Eduardo Valentin<[email protected]>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ */
+
+#include<linux/module.h>
+#include<linux/export.h>

drivers/mfd/omap-control-core.c new file +40 -0

+
+/**
+ * omap_control_readl: Read a single omap control module register.
+ *
+ * @dev: device to read from.
+ * @reg: register to read.
+ * @val: output with register value.
+ *
+ * returns 0 on success or -EINVAL in case struct device is invalid.
+ */
+int omap_control_readl(struct device *dev, u32 reg, u32 *val)
+{
+	struct omap_control *omap_control = dev_get_drvdata(dev);
+
+	if (!omap_control)
+		return -EINVAL;
+
+	*val = readl(omap_control->base + reg);
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(omap_control_readl);
+
+/**
+ * omap_control_writel: Write a single omap control module register.
+ *
+ * @dev: device to read from.
+ * @val: value to write.
+ * @reg: register to write to.
+ *
+ * returns 0 on success or -EINVAL in case struct device is invalid.
+ */
+int omap_control_writel(struct device *dev, u32 val, u32 reg)
+{
+	struct omap_control *omap_control = dev_get_drvdata(dev);
+	unsigned long flags;
+
+	if (!omap_control)
+		return -EINVAL;
+

drivers/mfd/omap-control-core.c new file +4 -0

+ *
+ * The modules which has to use control module API's to read or write should
+ * call this API to get the control module device pointer.
+ */

drivers/mfd/omap-control-core.c new file +29 -0

+
+	return omap_control_module->dev;
+}
+EXPORT_SYMBOL_GPL(omap_control_get);
+
+/**
+ * omap_control_put: returns the control module device pinter
+ *
+ * The modules which has to use control module API's to read or write should
+ * call this API to get the control module device pointer.
+ */
+void omap_control_put(struct device *dev)
+{
+	struct omap_control *omap_control = dev_get_drvdata(dev);
+	unsigned long flags;
+
+	if (!omap_control)
+		return;
+
+	spin_lock_irqsave(&omap_control->reg_lock, flags);
+	omap_control->use_count--;
+	spin_unlock_irqrestore(&omap_control_module->reg_lock, flags);
+}
+EXPORT_SYMBOL_GPL(omap_control_put);
+
+static const struct of_device_id of_omap_control_match[] = {
+	{ .compatible = "ti,omap3-control", },
+	{ .compatible = "ti,omap4-control", },
+	{ .compatible = "ti,omap5-control", },

drivers/mfd/omap-control-core.c new file +74 -0

+
+	omap_control = devm_kzalloc(dev, sizeof(*omap_control), GFP_KERNEL);
+	if (!omap_control) {
+		dev_err(dev, "not enough memory for omap_control\n");
+		return -ENOMEM;
+	}
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	if (!res) {
+		dev_err(dev, "missing memory base resource\n");
+		return -EINVAL;
+	}
+
+	base = devm_request_and_ioremap(dev, res);
+	if (!base) {
+		dev_err(dev, "ioremap failed\n");
+		return -EADDRNOTAVAIL;
+	}
+
+	omap_control->base = base;
+	omap_control->dev = dev;
+	spin_lock_init(&omap_control->reg_lock);
+
+	platform_set_drvdata(pdev, omap_control);
+	omap_control_module = omap_control;
+
+	return of_platform_populate(np, of_omap_control_match, NULL, dev);
+}
+
+static int __devexit omap_control_remove(struct platform_device *pdev)
+{
+	struct omap_control *omap_control = platform_get_drvdata(pdev);
+
+	spin_lock(&omap_control->reg_lock);
+	if (omap_control->use_count>  0) {
+		spin_unlock(&omap_control->reg_lock);
+		dev_err(&pdev->dev, "device removed while still being used\n");
+		return -EBUSY;
+	}
+	spin_unlock(&omap_control->reg_lock);
+
+	iounmap(omap_control->base);
+	platform_set_drvdata(pdev, NULL);
+
+	return 0;
+}
+
+static struct platform_driver omap_control_driver = {
+	.probe			= omap_control_probe,
+	.remove			= __devexit_p(omap_control_remove),
+	.driver = {
+		.name		= "omap-control-core",
+		.owner		= THIS_MODULE,
+		.of_match_table	= of_omap_control_match,
+	},
+};
+
+static int __init omap_control_init(void)
+{
+	return platform_driver_register(&omap_control_driver);
+}
+postcore_initcall_sync(omap_control_init);
+
+static void __exit omap_control_exit(void)
+{
+	platform_driver_unregister(&omap_control_driver);
+}
+module_exit(omap_control_exit);
+early_platform_init("early_omap_control",&omap_control_driver);
+
+MODULE_DESCRIPTION("OMAP system control module driver");
+MODULE_LICENSE("GPL v2");
+MODULE_ALIAS("platform:omap-control-core");
+MODULE_AUTHOR("Texas Instruments Inc.");

include/linux/mfd/omap_control.h new file +25 -0

new file mode 100644
index 0000000..7a33eda
@@ -0,0 +1,69 @@
+/*
+ * OMAP system control module header file
+ *
+ * Copyright (C) 2011-2012 Texas Instruments Incorporated - http://www.ti.com/
+ * Contact:
+ *   J Keerthy<[email protected]>
+ *   Moiz Sonasath<[email protected]>
+ *   Abraham, Kishon Vijay<[email protected]>
+ *   Eduardo Valentin<[email protected]>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ */
+
+#ifndef __DRIVERS_OMAP_CONTROL_H
+#define __DRIVERS_OMAP_CONTROL_H
+
+#include<linux/err.h>

Quoted 172 lines · Eduardo Valentin

This patch introduces a MFD core device driver for OMAP system control module.

The control module allows software control of various static modes supported by the device. It is composed of two control submodules: general control module and device (padconfiguration) control module.

In this patch, the children defined are for:
. USB-phy pin control
. Bangap temperature sensor

Device driver is probed with postcore_initcall. However, as some of the APIs exposed by this driver may be needed in very early init phase, an early init class is also available: "early_omap_control".

Signed-off-by J Keerthy<[email protected]>

Signed-off-by Kishon Vijay Abraham I<[email protected]>

Signed-off-by Eduardo Valentin<[email protected]>

---
 .../devicetree/bindings/mfd/omap_control.txt       |   44 ++++
 arch/arm/mach-omap2/Kconfig                        |    1 +
 arch/arm/plat-omap/Kconfig                         |    3 +
 drivers/mfd/Kconfig                                |    9 +
 drivers/mfd/Makefile                               |    1 +
 drivers/mfd/omap-control-core.c                    |  211 ++++++++++++++++++++
 include/linux/mfd/omap_control.h                   |   69 +++++++
 7 files changed, 338 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mfd/omap_control.txt
 create mode 100644 drivers/mfd/omap-control-core.c
 create mode 100644 include/linux/mfd/omap_control.h

Documentation/devicetree/bindings/mfd/omap_control.txt new file +44 -0

new file mode 100644
index 0000000..46d5e7e
@@ -0,0 +1,44 @@
+* Texas Instrument OMAP System Control Module (SCM) bindings
+
+The control module allows software control of various static modes supported by
+the device. The control module controls the settings of various device  modules
+through register configuration and internal signals. It also controls  the  pad
+configuration, pin functional multiplexing, and the routing of internal signals
+(such as PRCM  signals or DMA requests)  to output pins configured for hardware
+observability.
+
+Required properties:
+- compatible : Should be:
+  - "ti,omap3-control" for OMAP3 support
+  - "ti,omap4-control" for OMAP4 support
+  - "ti,omap5-control" for OMAP5 support
+
+OMAP specific properties:
+- ti,hwmods: Name of the hwmod associated to the control module:
+  Should be "ctrl_module_core";
+
+Sub-nodes:
+- bandgap : contains the bandgap node
+
+  The bindings details of individual bandgap device can be found in:
+  Documentation/devicetree/bindings/thermal/omap_bandgap.txt
+
+- usb : contains the usb phy pin control node
+
+  The only required property for this child is:
+    - compatible = "ti,omap4-control-usb";
+
+Examples:
+
+ctrl_module_core: ctrl_module_core at 4a002000 {
+	compatible = "ti,omap4-control";
+	ti,hwmods = "ctrl_module_core";
+	bandgap {
+		compatible = "ti,omap4460-bandgap";
+		interrupts =<0 126 4>; /* talert */
+		ti,tshut-gpio =<86>; /* tshut */
+	};
+	usb {
+		compatible = "ti,omap4-usb-phy";
+	};
+};

arch/arm/mach-omap2/Kconfig +1 -0

index a2b946d..7dfe5e1 100644
@@ -52,6 +52,7 @@ config ARCH_OMAP4
 	select PL310_ERRATA_727915
 	select ARM_ERRATA_720789
 	select ARCH_HAS_OPP
+	select ARCH_HAS_CONTROL_MODULE
 	select PM_OPP if PM
 	select USB_ARCH_HAS_EHCI if USB_SUPPORT
 	select ARM_CPU_SUSPEND if PM

arch/arm/plat-omap/Kconfig +3 -0

index ad95c7a..222dbad 100644
@@ -5,6 +5,9 @@ menu "TI OMAP Common Features"
 config ARCH_OMAP_OTG
 	bool
 
+config ARCH_HAS_CONTROL_MODULE
+	bool
+
 choice
 	prompt "OMAP System Type"
 	default ARCH_OMAP2PLUS

drivers/mfd/Kconfig +9 -0

index 11e4438..25a66d8 100644
@@ -795,6 +795,15 @@ config MFD_WL1273_CORE
 	  driver connects the radio-wl1273 V4L2 module and the wl1273
 	  audio codec.
 
+config MFD_OMAP_CONTROL
+	bool "Texas Instruments OMAP System control module"
+	depends on ARCH_HAS_CONTROL_MODULE
+	help
+	  This is the core driver for system control module. This driver
+	  is responsible for creating the control module mfd child,
+	  like USB-pin control, pin muxing, MMC-pbias and DDR IO dynamic
+	  change for off mode.
+
 config MFD_OMAP_USB_HOST
 	bool "Support OMAP USBHS core driver"
 	depends on USB_EHCI_HCD_OMAP || USB_OHCI_HCD_OMAP3

drivers/mfd/Makefile +1 -0

index 05fa538..00f99d6 100644
@@ -106,6 +106,7 @@ obj-$(CONFIG_MFD_TPS6586X)	+= tps6586x.o
 obj-$(CONFIG_MFD_VX855)		+= vx855.o
 obj-$(CONFIG_MFD_WL1273_CORE)	+= wl1273-core.o
 obj-$(CONFIG_MFD_CS5535)	+= cs5535-mfd.o
+obj-$(CONFIG_MFD_OMAP_CONTROL)	+= omap-control-core.o
 obj-$(CONFIG_MFD_OMAP_USB_HOST)	+= omap-usb-host.o
 obj-$(CONFIG_MFD_PM8921_CORE) 	+= pm8921-core.o
 obj-$(CONFIG_MFD_PM8XXX_IRQ) 	+= pm8xxx-irq.o

drivers/mfd/omap-control-core.c new file +24 -0

new file mode 100644
index 0000000..7d8d408
@@ -0,0 +1,211 @@
+/*
+ * OMAP system control module driver file
+ *
+ * Copyright (C) 2011-2012 Texas Instruments Incorporated - http://www.ti.com/
+ * Contacts:
+ * Based on original code written by:
+ *    J Keerthy<[email protected]>
+ *    Moiz Sonasath<[email protected]>
+ * MFD clean up and re-factoring:
+ *    Eduardo Valentin<[email protected]>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ */
+
+#include<linux/module.h>
+#include<linux/export.h>

drivers/mfd/omap-control-core.c line 34

Quoted 10 lines

drivers/mfd/omap-control-core.c new file +10 -0

+#include<linux/platform_device.h>
+#include<linux/slab.h>
+#include<linux/io.h>
+#include<linux/err.h>
+#include<linux/of_platform.h>
+#include<linux/of_address.h>
+#include<linux/mfd/core.h>
+#include<linux/mfd/omap_control.h>
+
+static struct omap_control *omap_control_module;

Mmm, we can have up to 4 control module instances in OMAP4.

Well, I'm not sure it worth considering them as separate devices. Is that your plan as well?

But since they all have different base address, it will be trick to handle them with only a single entry.

Quoted 45 lines

drivers/mfd/omap-control-core.c new file +44 -0

+
+/**
+ * omap_control_readl: Read a single omap control module register.
+ *
+ * @dev: device to read from.
+ * @reg: register to read.
+ * @val: output with register value.
+ *
+ * returns 0 on success or -EINVAL in case struct device is invalid.
+ */
+int omap_control_readl(struct device *dev, u32 reg, u32 *val)
+{
+	struct omap_control *omap_control = dev_get_drvdata(dev);
+
+	if (!omap_control)
+		return -EINVAL;
+
+	*val = readl(omap_control->base + reg);
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(omap_control_readl);
+
+/**
+ * omap_control_writel: Write a single omap control module register.
+ *
+ * @dev: device to read from.
+ * @val: value to write.
+ * @reg: register to write to.
+ *
+ * returns 0 on success or -EINVAL in case struct device is invalid.
+ */
+int omap_control_writel(struct device *dev, u32 val, u32 reg)
+{
+	struct omap_control *omap_control = dev_get_drvdata(dev);
+	unsigned long flags;
+
+	if (!omap_control)
+		return -EINVAL;
+
+	spin_lock_irqsave(&omap_control->reg_lock, flags);
+	writel(val, omap_control->base + reg);
+	spin_unlock_irqrestore(&omap_control->reg_lock, flags);
+

drivers/mfd/omap-control-core.c line 84

Quoted 6 lines

drivers/mfd/omap-control-core.c new file +6 -0

+	return 0;
+}
+EXPORT_SYMBOL_GPL(omap_control_writel);
+
+/**
+ * omap_control_get: returns the control module device pinter

typo

Quoted 10 lines

drivers/mfd/omap-control-core.c new file +9 -0

+ *
+ * The modules which has to use control module API's to read or write should
+ * call this API to get the control module device pointer.
+ */
+struct device *omap_control_get(void)
+{
+	unsigned long flags;
+
+	if (!omap_control_module)

drivers/mfd/omap-control-core.c line 98

Quoted 5 lines

drivers/mfd/omap-control-core.c new file +5 -0

+		return ERR_PTR(-ENODEV);
+
+	spin_lock_irqsave(&omap_control_module->reg_lock, flags);
+	omap_control_module->use_count++;
+	spin_unlock_irqrestore(&omap_control_module->reg_lock, flags);

Don't we do have some better way to increment atomically a variable in Linux.

Quoted 36 lines

drivers/mfd/omap-control-core.c new file +35 -0

+
+	return omap_control_module->dev;
+}
+EXPORT_SYMBOL_GPL(omap_control_get);
+
+/**
+ * omap_control_put: returns the control module device pinter
+ *
+ * The modules which has to use control module API's to read or write should
+ * call this API to get the control module device pointer.
+ */
+void omap_control_put(struct device *dev)
+{
+	struct omap_control *omap_control = dev_get_drvdata(dev);
+	unsigned long flags;
+
+	if (!omap_control)
+		return;
+
+	spin_lock_irqsave(&omap_control->reg_lock, flags);
+	omap_control->use_count--;
+	spin_unlock_irqrestore(&omap_control_module->reg_lock, flags);
+}
+EXPORT_SYMBOL_GPL(omap_control_put);
+
+static const struct of_device_id of_omap_control_match[] = {
+	{ .compatible = "ti,omap3-control", },
+	{ .compatible = "ti,omap4-control", },
+	{ .compatible = "ti,omap5-control", },
+	{ },
+};
+
+static int __devinit omap_control_probe(struct platform_device *pdev)
+{
+	struct resource *res;

drivers/mfd/omap-control-core.c line 137

Quoted 4 lines

drivers/mfd/omap-control-core.c new file +4 -0

+	void __iomem *base;
+	struct device *dev =&pdev->dev;
+	struct device_node *np = dev->of_node;
+	struct omap_control *omap_control;

Maybe omap_control_data instead? At least if this is drvdata only. If this is supposed to be the *handle* to the control module instance, it should be fine.

Quoted 106 lines

drivers/mfd/omap-control-core.c new file +74 -0

+
+	omap_control = devm_kzalloc(dev, sizeof(*omap_control), GFP_KERNEL);
+	if (!omap_control) {
+		dev_err(dev, "not enough memory for omap_control\n");
+		return -ENOMEM;
+	}
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	if (!res) {
+		dev_err(dev, "missing memory base resource\n");
+		return -EINVAL;
+	}
+
+	base = devm_request_and_ioremap(dev, res);
+	if (!base) {
+		dev_err(dev, "ioremap failed\n");
+		return -EADDRNOTAVAIL;
+	}
+
+	omap_control->base = base;
+	omap_control->dev = dev;
+	spin_lock_init(&omap_control->reg_lock);
+
+	platform_set_drvdata(pdev, omap_control);
+	omap_control_module = omap_control;
+
+	return of_platform_populate(np, of_omap_control_match, NULL, dev);
+}
+
+static int __devexit omap_control_remove(struct platform_device *pdev)
+{
+	struct omap_control *omap_control = platform_get_drvdata(pdev);
+
+	spin_lock(&omap_control->reg_lock);
+	if (omap_control->use_count>  0) {
+		spin_unlock(&omap_control->reg_lock);
+		dev_err(&pdev->dev, "device removed while still being used\n");
+		return -EBUSY;
+	}
+	spin_unlock(&omap_control->reg_lock);
+
+	iounmap(omap_control->base);
+	platform_set_drvdata(pdev, NULL);
+
+	return 0;
+}
+
+static struct platform_driver omap_control_driver = {
+	.probe			= omap_control_probe,
+	.remove			= __devexit_p(omap_control_remove),
+	.driver = {
+		.name		= "omap-control-core",
+		.owner		= THIS_MODULE,
+		.of_match_table	= of_omap_control_match,
+	},
+};
+
+static int __init omap_control_init(void)
+{
+	return platform_driver_register(&omap_control_driver);
+}
+postcore_initcall_sync(omap_control_init);
+
+static void __exit omap_control_exit(void)
+{
+	platform_driver_unregister(&omap_control_driver);
+}
+module_exit(omap_control_exit);
+early_platform_init("early_omap_control",&omap_control_driver);
+
+MODULE_DESCRIPTION("OMAP system control module driver");
+MODULE_LICENSE("GPL v2");
+MODULE_ALIAS("platform:omap-control-core");
+MODULE_AUTHOR("Texas Instruments Inc.");

include/linux/mfd/omap_control.h new file +25 -0

new file mode 100644
index 0000000..7a33eda
@@ -0,0 +1,69 @@
+/*
+ * OMAP system control module header file
+ *
+ * Copyright (C) 2011-2012 Texas Instruments Incorporated - http://www.ti.com/
+ * Contact:
+ *   J Keerthy<[email protected]>
+ *   Moiz Sonasath<[email protected]>
+ *   Abraham, Kishon Vijay<[email protected]>
+ *   Eduardo Valentin<[email protected]>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ */
+
+#ifndef __DRIVERS_OMAP_CONTROL_H
+#define __DRIVERS_OMAP_CONTROL_H
+
+#include<linux/err.h>

include/linux/mfd/omap_control.h line 35

Quoted 10 lines

include/linux/mfd/omap_control.h new file +10 -0

+
+/**
+ * struct system control module - scm device structure
+ * @dev: device pointer
+ * @base: Base of the temp I/O
+ * @reg_lock: protect omap_control structure
+ * @use_count: track API users
+ */
+struct omap_control {
+	struct device		*dev;

Do you really need the dev?
You API is device based and not omap_control based, so it should not be needed.

I guess we should be consistent here. We can store the devices and used a device based API or store the omap_control and thus expose a omap_control API.

Regards,
Benoit

Hello,

Quoted 186 lines · Cousson Benoit

Quoted 172 lines · Eduardo Valentin

This patch introduces a MFD core device driver for OMAP system control module.

The control module allows software control of various static modes supported by the device. It is composed of two control submodules: general control module and device (padconfiguration) control module.

In this patch, the children defined are for:
. USB-phy pin control
. Bangap temperature sensor

Device driver is probed with postcore_initcall. However, as some of the APIs exposed by this driver may be needed in very early init phase, an early init class is also available: "early_omap_control".

Signed-off-by J Keerthy<[email protected]>

Signed-off-by Kishon Vijay Abraham I<[email protected]>

Signed-off-by Eduardo Valentin<[email protected]>

---
  .../devicetree/bindings/mfd/omap_control.txt       |   44 ++++
  arch/arm/mach-omap2/Kconfig                        |    1 +
  arch/arm/plat-omap/Kconfig                         |    3 +
  drivers/mfd/Kconfig                                |    9 +
  drivers/mfd/Makefile                               |    1 +
  drivers/mfd/omap-control-core.c                    |  211 ++++++++++++++++++++
  include/linux/mfd/omap_control.h                   |   69 +++++++
  7 files changed, 338 insertions(+), 0 deletions(-)

create mode 100644 Documentation/devicetree/bindings/mfd/omap_control.txt create mode 100644 drivers/mfd/omap-control-core.c
create mode 100644 include/linux/mfd/omap_control.h

Documentation/devicetree/bindings/mfd/omap_control.txt new file +44 -0

new file mode 100644
index 0000000..46d5e7e
@@ -0,0 +1,44 @@
+* Texas Instrument OMAP System Control Module (SCM) bindings
+
+The control module allows software control of various static modes supported by
+the device. The control module controls the settings of various device  modules
+through register configuration and internal signals. It also controls  the  pad
+configuration, pin functional multiplexing, and the routing of internal signals
+(such as PRCM  signals or DMA requests)  to output pins configured for hardware
+observability.
+
+Required properties:
+- compatible : Should be:
+  - "ti,omap3-control" for OMAP3 support
+  - "ti,omap4-control" for OMAP4 support
+  - "ti,omap5-control" for OMAP5 support
+
+OMAP specific properties:
+- ti,hwmods: Name of the hwmod associated to the control module:
+  Should be "ctrl_module_core";
+
+Sub-nodes:
+- bandgap : contains the bandgap node
+
+  The bindings details of individual bandgap device can be found in:
+  Documentation/devicetree/bindings/thermal/omap_bandgap.txt
+
+- usb : contains the usb phy pin control node
+
+  The only required property for this child is:
+    - compatible = "ti,omap4-control-usb";
+
+Examples:
+
+ctrl_module_core: ctrl_module_core at 4a002000 {
+	compatible = "ti,omap4-control";
+	ti,hwmods = "ctrl_module_core";
+	bandgap {
+		compatible = "ti,omap4460-bandgap";
+		interrupts =<0 126 4>; /* talert */
+		ti,tshut-gpio =<86>; /* tshut */
+	};
+	usb {
+		compatible = "ti,omap4-usb-phy";
+	};
+};

arch/arm/mach-omap2/Kconfig +1 -0

index a2b946d..7dfe5e1 100644
@@ -52,6 +52,7 @@ config ARCH_OMAP4
  	select PL310_ERRATA_727915
  	select ARM_ERRATA_720789
  	select ARCH_HAS_OPP
+	select ARCH_HAS_CONTROL_MODULE
  	select PM_OPP if PM
  	select USB_ARCH_HAS_EHCI if USB_SUPPORT
  	select ARM_CPU_SUSPEND if PM

arch/arm/plat-omap/Kconfig +3 -0

index ad95c7a..222dbad 100644
@@ -5,6 +5,9 @@ menu "TI OMAP Common Features"
  config ARCH_OMAP_OTG
  	bool
 
+config ARCH_HAS_CONTROL_MODULE
+	bool
+
  choice
  	prompt "OMAP System Type"
  	default ARCH_OMAP2PLUS

drivers/mfd/Kconfig +9 -0

index 11e4438..25a66d8 100644
@@ -795,6 +795,15 @@ config MFD_WL1273_CORE
  	  driver connects the radio-wl1273 V4L2 module and the wl1273
  	  audio codec.
 
+config MFD_OMAP_CONTROL
+	bool "Texas Instruments OMAP System control module"
+	depends on ARCH_HAS_CONTROL_MODULE
+	help
+	  This is the core driver for system control module. This driver
+	  is responsible for creating the control module mfd child,
+	  like USB-pin control, pin muxing, MMC-pbias and DDR IO dynamic
+	  change for off mode.
+
  config MFD_OMAP_USB_HOST
  	bool "Support OMAP USBHS core driver"
  	depends on USB_EHCI_HCD_OMAP || USB_OHCI_HCD_OMAP3

drivers/mfd/Makefile +1 -0

index 05fa538..00f99d6 100644
@@ -106,6 +106,7 @@ obj-$(CONFIG_MFD_TPS6586X)	+= tps6586x.o
  obj-$(CONFIG_MFD_VX855)		+= vx855.o
  obj-$(CONFIG_MFD_WL1273_CORE)	+= wl1273-core.o
  obj-$(CONFIG_MFD_CS5535)	+= cs5535-mfd.o
+obj-$(CONFIG_MFD_OMAP_CONTROL)	+= omap-control-core.o
  obj-$(CONFIG_MFD_OMAP_USB_HOST)	+= omap-usb-host.o
  obj-$(CONFIG_MFD_PM8921_CORE) 	+= pm8921-core.o
  obj-$(CONFIG_MFD_PM8XXX_IRQ) 	+= pm8xxx-irq.o

drivers/mfd/omap-control-core.c new file +24 -0

new file mode 100644
index 0000000..7d8d408
@@ -0,0 +1,211 @@
+/*
+ * OMAP system control module driver file
+ *
+ * Copyright (C) 2011-2012 Texas Instruments Incorporated - http://www.ti.com/
+ * Contacts:
+ * Based on original code written by:
+ *    J Keerthy<[email protected]>
+ *    Moiz Sonasath<[email protected]>
+ * MFD clean up and re-factoring:
+ *    Eduardo Valentin<[email protected]>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ */
+
+#include<linux/module.h>
+#include<linux/export.h>

drivers/mfd/omap-control-core.c line 34

Quoted 10 lines

drivers/mfd/omap-control-core.c new file +10 -0

+#include<linux/platform_device.h>
+#include<linux/slab.h>
+#include<linux/io.h>
+#include<linux/err.h>
+#include<linux/of_platform.h>
+#include<linux/of_address.h>
+#include<linux/mfd/core.h>
+#include<linux/mfd/omap_control.h>
+
+static struct omap_control *omap_control_module;

Mmm, we can have up to 4 control module instances in OMAP4.

Quoted 2 lines

Well, I'm not sure it worth considering them as separate devices. Is that your plan as well?

At least for now I was focusing on the ctrl_module_core ...

Quoted 2 lines

But since they all have different base address, it will be trick to handle them with only a single entry.

Indeed. We can always add the support latter on.

I am not sure what would be the best way to handle those instances though, and how they are going to expose APIs. Would need to have an instance bound to API set?

Quoted 44 lines

Quoted 44 lines

drivers/mfd/omap-control-core.c new file +44 -0

+
+/**
+ * omap_control_readl: Read a single omap control module register.
+ *
+ * @dev: device to read from.
+ * @reg: register to read.
+ * @val: output with register value.
+ *
+ * returns 0 on success or -EINVAL in case struct device is invalid.
+ */
+int omap_control_readl(struct device *dev, u32 reg, u32 *val)
+{
+	struct omap_control *omap_control = dev_get_drvdata(dev);
+
+	if (!omap_control)
+		return -EINVAL;
+
+	*val = readl(omap_control->base + reg);
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(omap_control_readl);
+
+/**
+ * omap_control_writel: Write a single omap control module register.
+ *
+ * @dev: device to read from.
+ * @val: value to write.
+ * @reg: register to write to.
+ *
+ * returns 0 on success or -EINVAL in case struct device is invalid.
+ */
+int omap_control_writel(struct device *dev, u32 val, u32 reg)
+{
+	struct omap_control *omap_control = dev_get_drvdata(dev);
+	unsigned long flags;
+
+	if (!omap_control)
+		return -EINVAL;
+
+	spin_lock_irqsave(&omap_control->reg_lock, flags);
+	writel(val, omap_control->base + reg);
+	spin_unlock_irqrestore(&omap_control->reg_lock, flags);
+

Quoted 8 lines

drivers/mfd/omap-control-core.c line 84

Quoted 6 lines

drivers/mfd/omap-control-core.c new file +6 -0

+	return 0;
+}
+EXPORT_SYMBOL_GPL(omap_control_writel);
+
+/**
+ * omap_control_get: returns the control module device pinter

typo

K

Quoted 10 lines

Quoted 10 lines

drivers/mfd/omap-control-core.c new file +9 -0

+ *
+ * The modules which has to use control module API's to read or write should
+ * call this API to get the control module device pointer.
+ */
+struct device *omap_control_get(void)
+{
+	unsigned long flags;
+
+	if (!omap_control_module)

Quoted 8 lines

drivers/mfd/omap-control-core.c line 98

Quoted 5 lines

drivers/mfd/omap-control-core.c new file +5 -0

+		return ERR_PTR(-ENODEV);
+
+	spin_lock_irqsave(&omap_control_module->reg_lock, flags);
+	omap_control_module->use_count++;
+	spin_unlock_irqrestore(&omap_control_module->reg_lock, flags);

Don't we do have some better way to increment atomically a variable in Linux.

Yeah we have, atomic API. In general I think the SCM/bangap/phy APIs need to be revisited WRT locking, in general.

Quoted 36 lines

Quoted 36 lines

drivers/mfd/omap-control-core.c new file +35 -0

+
+	return omap_control_module->dev;
+}
+EXPORT_SYMBOL_GPL(omap_control_get);
+
+/**
+ * omap_control_put: returns the control module device pinter
+ *
+ * The modules which has to use control module API's to read or write should
+ * call this API to get the control module device pointer.
+ */
+void omap_control_put(struct device *dev)
+{
+	struct omap_control *omap_control = dev_get_drvdata(dev);
+	unsigned long flags;
+
+	if (!omap_control)
+		return;
+
+	spin_lock_irqsave(&omap_control->reg_lock, flags);
+	omap_control->use_count--;
+	spin_unlock_irqrestore(&omap_control_module->reg_lock, flags);
+}
+EXPORT_SYMBOL_GPL(omap_control_put);
+
+static const struct of_device_id of_omap_control_match[] = {
+	{ .compatible = "ti,omap3-control", },
+	{ .compatible = "ti,omap4-control", },
+	{ .compatible = "ti,omap5-control", },
+	{ },
+};
+
+static int __devinit omap_control_probe(struct platform_device *pdev)
+{
+	struct resource *res;

Quoted 8 lines

drivers/mfd/omap-control-core.c line 137

Quoted 4 lines

drivers/mfd/omap-control-core.c new file +4 -0

+	void __iomem *base;
+	struct device *dev =&pdev->dev;
+	struct device_node *np = dev->of_node;
+	struct omap_control *omap_control;

Maybe omap_control_data instead? At least if this is drvdata only. If this is supposed to be the *handle* to the control module instance, it should be fine.

That's suppose to be the phandle :-)

Quoted 121 lines

Quoted 106 lines

drivers/mfd/omap-control-core.c new file +74 -0

+
+	omap_control = devm_kzalloc(dev, sizeof(*omap_control), GFP_KERNEL);
+	if (!omap_control) {
+		dev_err(dev, "not enough memory for omap_control\n");
+		return -ENOMEM;
+	}
+
+	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+	if (!res) {
+		dev_err(dev, "missing memory base resource\n");
+		return -EINVAL;
+	}
+
+	base = devm_request_and_ioremap(dev, res);
+	if (!base) {
+		dev_err(dev, "ioremap failed\n");
+		return -EADDRNOTAVAIL;
+	}
+
+	omap_control->base = base;
+	omap_control->dev = dev;
+	spin_lock_init(&omap_control->reg_lock);
+
+	platform_set_drvdata(pdev, omap_control);
+	omap_control_module = omap_control;
+
+	return of_platform_populate(np, of_omap_control_match, NULL, dev);
+}
+
+static int __devexit omap_control_remove(struct platform_device *pdev)
+{
+	struct omap_control *omap_control = platform_get_drvdata(pdev);
+
+	spin_lock(&omap_control->reg_lock);
+	if (omap_control->use_count>   0) {
+		spin_unlock(&omap_control->reg_lock);
+		dev_err(&pdev->dev, "device removed while still being used\n");
+		return -EBUSY;
+	}
+	spin_unlock(&omap_control->reg_lock);
+
+	iounmap(omap_control->base);
+	platform_set_drvdata(pdev, NULL);
+
+	return 0;
+}
+
+static struct platform_driver omap_control_driver = {
+	.probe			= omap_control_probe,
+	.remove			= __devexit_p(omap_control_remove),
+	.driver = {
+		.name		= "omap-control-core",
+		.owner		= THIS_MODULE,
+		.of_match_table	= of_omap_control_match,
+	},
+};
+
+static int __init omap_control_init(void)
+{
+	return platform_driver_register(&omap_control_driver);
+}
+postcore_initcall_sync(omap_control_init);
+
+static void __exit omap_control_exit(void)
+{
+	platform_driver_unregister(&omap_control_driver);
+}
+module_exit(omap_control_exit);
+early_platform_init("early_omap_control",&omap_control_driver);
+
+MODULE_DESCRIPTION("OMAP system control module driver");
+MODULE_LICENSE("GPL v2");
+MODULE_ALIAS("platform:omap-control-core");
+MODULE_AUTHOR("Texas Instruments Inc.");

include/linux/mfd/omap_control.h new file +25 -0

new file mode 100644
index 0000000..7a33eda
@@ -0,0 +1,69 @@
+/*
+ * OMAP system control module header file
+ *
+ * Copyright (C) 2011-2012 Texas Instruments Incorporated - http://www.ti.com/
+ * Contact:
+ *   J Keerthy<[email protected]>
+ *   Moiz Sonasath<[email protected]>
+ *   Abraham, Kishon Vijay<[email protected]>
+ *   Eduardo Valentin<[email protected]>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ */
+
+#ifndef __DRIVERS_OMAP_CONTROL_H
+#define __DRIVERS_OMAP_CONTROL_H
+
+#include<linux/err.h>

include/linux/mfd/omap_control.h line 35

Quoted 10 lines

include/linux/mfd/omap_control.h new file +10 -0

+
+/**
+ * struct system control module - scm device structure
+ * @dev: device pointer
+ * @base: Base of the temp I/O
+ * @reg_lock: protect omap_control structure
+ * @use_count: track API users
+ */
+struct omap_control {
+	struct device		*dev;

Do you really need the dev?
You API is device based and not omap_control based, so it should not be needed.

Quoted 3 lines

I guess we should be consistent here. We can store the devices and used a device based API or store the omap_control and thus expose a omap_control API.

Yeah, this API structure is left over of the previous driver.

The omap_control_get returns the SCM device reference and the users of SCM use it as parameter for the SCM APIs.

We need to have in mind that, for SCM, the users are:
a. Its children (USB phy, BG, etc)
b. Non children users (mach code)

The refcounting and the locking needs to take care of both I'd say. The struct dev was just a way to pass the SCM phandle.

Quoted 3 lines

Regards,
Benoit

Quoted 7 lines · Eduardo Valentin

Quoted 5 lines

Mmm, we can have up to 4 control module instances in OMAP4.

Well, I'm not sure it worth considering them as separate devices. Is that your plan as well?

At least for now I was focusing on the ctrl_module_core ...

OK, that's a good start already :-)

Quoted 5 lines

Quoted 2 lines

But since they all have different base address, it will be trick to handle them with only a single entry.

Indeed. We can always add the support latter on.

Quoted 3 lines

I am not sure what would be the best way to handle those instances though, and how they are going to expose APIs. Would need to have an instance bound to API set?

We should not go to that path I guess. We should have an API at children level independent of the underlying control module partitioning.

Quoted 16 lines · Cousson, Benoit

Quoted 7 lines · Eduardo Valentin

Quoted 5 lines

Mmm, we can have up to 4 control module instances in OMAP4.

Well, I'm not sure it worth considering them as separate devices. Is that your plan as well?

At least for now I was focusing on the ctrl_module_core ...

OK, that's a good start already :-)

Quoted 5 lines

Quoted 2 lines

But since they all have different base address, it will be trick to handle them with only a single entry.

Indeed. We can always add the support latter on.

Quoted 7 lines

Quoted 3 lines

I am not sure what would be the best way to handle those instances though, and how they are going to expose APIs. Would need to have an instance bound to API set?

We should not go to that path I guess. We should have an API at children level independent of the underlying control module partitioning.

These should be separate driver instances for the control modules.

And then the ioremapped area should ignore at least the padconf registers so drivers/pinctrl/pinctrl-simple can handle those. There should not be any dependencies to the SCM driver from pinctrl-simple, the core SCM driver can manage the clocks and trigger the save of padconf regs.

Also we should allow MMC driver handle the MMC specific registers and USB driver(s) handle the USB specific registers if possible. Those should not live under drivers/mfd unless there are some dependencies other than trying to ioremap the whole SCM module instead of ioremapping in each driver.

We can have a static map for the SCM, so ioremapping each driver individually should not be an issue.

Quoted 39 lines · Tony Lindgren

Quoted 16 lines · Cousson, Benoit

Quoted 7 lines · Eduardo Valentin

Quoted 5 lines

Mmm, we can have up to 4 control module instances in OMAP4.

Well, I'm not sure it worth considering them as separate devices. Is that your plan as well?

At least for now I was focusing on the ctrl_module_core ...

OK, that's a good start already :-)

Quoted 5 lines

Quoted 2 lines

But since they all have different base address, it will be trick to handle them with only a single entry.

Indeed. We can always add the support latter on.

Quoted 7 lines

Quoted 3 lines

I am not sure what would be the best way to handle those instances though, and how they are going to expose APIs. Would need to have an instance bound to API set?

We should not go to that path I guess. We should have an API at children level independent of the underlying control module partitioning.

These should be separate driver instances for the control modules.

And then the ioremapped area should ignore at least the padconf registers so drivers/pinctrl/pinctrl-simple can handle those. There should not be any dependencies to the SCM driver from pinctrl-simple, the core SCM driver can manage the clocks and trigger the save of padconf regs.

Also we should allow MMC driver handle the MMC specific registers and USB driver(s) handle the USB specific registers if possible. Those should not live under drivers/mfd unless there are some dependencies other than trying to ioremap the whole SCM module instead of ioremapping in each driver.

Quoted 3 lines

We can have a static map for the SCM, so ioremapping each driver individually should not be an issue.

This sounds a good idea. With this we may not even need a core control module drivers if all the individual drivers take care of the registers they care. Mapping shouldn't be a problem as you mentioned.

Quoted 34 lines · Santosh

Quoted 33 lines · Tony Lindgren

Quoted 16 lines · Cousson, Benoit

Quoted 7 lines · Eduardo Valentin

Quoted 5 lines

Mmm, we can have up to 4 control module instances in OMAP4.

Well, I'm not sure it worth considering them as separate devices. Is that your plan as well?

At least for now I was focusing on the ctrl_module_core ...

OK, that's a good start already :-)

Quoted 5 lines

Quoted 2 lines

But since they all have different base address, it will be trick to handle them with only a single entry.

Indeed. We can always add the support latter on.

Quoted 7 lines

Quoted 3 lines

I am not sure what would be the best way to handle those instances though, and how they are going to expose APIs. Would need to have an instance bound to API set?

We should not go to that path I guess. We should have an API at children level independent of the underlying control module partitioning.

These should be separate driver instances for the control modules.

And then the ioremapped area should ignore at least the padconf registers so drivers/pinctrl/pinctrl-simple can handle those. There should not be any dependencies to the SCM driver from pinctrl-simple, the core SCM driver can manage the clocks and trigger the save of padconf regs.

Quoted 8 lines

Quoted 8 lines

Also we should allow MMC driver handle the MMC specific registers and USB driver(s) handle the USB specific registers if possible. Those should not live under drivers/mfd unless there are some dependencies other than trying to ioremap the whole SCM module instead of ioremapping in each driver.

We can have a static map for the SCM, so ioremapping each driver individually should not be an issue.

Quoted 4 lines

Quoted 1 line

This sounds a good idea. With this we may not even need a core control module drivers if all the individual drivers take care of the registers they care. Mapping shouldn't be a problem as you mentioned.

We should keep the MFD for PM / OCP single port correctness. Other than that it will be mostly useless, indeed.

Regards,
Benoit

Quoted 10 lines · Cousson, Benoit

Quoted 5 lines · Eduardo Valentin

Quoted 4 lines

Mmm, we can have up to 4 control module instances in OMAP4.

Well, I'm not sure it worth considering them as separate devices. Is that your plan as well?

At least for now I was focusing on the ctrl_module_core ...

OK, that's a good start already :-)

Quoted 2 lines

Quoted 2 lines

But since they all have different base address, it will be trick to handle them with only a single entry.

Quoted 8 lines

Quoted 5 lines

Indeed. We can always add the support latter on.

I am not sure what would be the best way to handle those instances though, and how they are going to expose APIs. Would need to have an instance bound to API set?

We should not go to that path I guess. We should have an API at children level independent of the underlying control module partitioning.

These should be separate driver instances for the control modules.

And then the ioremapped area should ignore at least the padconf registers so drivers/pinctrl/pinctrl-simple can handle those. There should not be any dependencies to the SCM driver from pinctrl-simple, the core SCM driver can manage the clocks and trigger the save of padconf regs.

Also we should allow MMC driver handle the MMC specific registers and USB driver(s) handle the USB specific registers if possible. Those should not live under drivers/mfd unless there are some dependencies other than trying to ioremap the whole SCM module instead of ioremapping in each driver.

We can have a static map for the SCM, so ioremapping each driver individually should not be an issue.

Regards,

Tony

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Quoted 3 lines · Tony Lindgren

We can have a static map for the SCM, so ioremapping each driver individually should not be an issue.

Actually SCM registers window is mapped statically. Mapping is defined in omap44xx_io_desc[] in arch/arm/mach-omap2/io.c:

...

        .virtual    = L4_44XX_VIRT,
        .pfn        = __phys_to_pfn(L4_44XX_PHYS),
        .length        = L4_44XX_SIZE,
        .type        = MT_DEVICE,

...

So ioremap() always returns same virtual address (0xfc002000).

Quoted 13 lines · Konstantin Baydarov

Quoted 2 lines · Tony Lindgren

We can have a static map for the SCM, so ioremapping each driver individually should not be an issue.

Actually SCM registers window is mapped statically. Mapping is defined in omap44xx_io_desc[] in arch/arm/mach-omap2/io.c:

...

        .virtual    = L4_44XX_VIRT,
        .pfn        = __phys_to_pfn(L4_44XX_PHYS),
        .length        = L4_44XX_SIZE,
        .type        = MT_DEVICE,

...

Quoted 1 line

So ioremap() always returns same virtual address (0xfc002000).

Hmm I guess you mean L4_44XX_VIRT + offset. Otherwise drivers would not work at all.. Or else I don't follow you.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

This patch introduces a MFD core device driver for OMAP system control module.

The control module allows software control of various static modes supported by the device. It is composed of two control submodules: general control module and device (padconfiguration) control module.

In this patch, the children defined are for:
. USB-phy pin control
. Bangap temperature sensor

Device driver is probed with postcore_initcall. However, as some of the APIs exposed by this driver may be needed in very early init phase, an early init class is also available: "early_omap_control".

Signed-off-by J Keerthy <[email protected]>

Signed-off-by Kishon Vijay Abraham I <[email protected]>

Signed-off-by Eduardo Valentin <[email protected]>

---

?choice
? ? ? ?prompt "OMAP System Type"
? ? ? ?default ARCH_OMAP2PLUS

drivers/mfd/Kconfig +0 -0

index 11e4438..25a66d8 100644
@@ -795,6 +795,15 @@ config MFD_WL1273_CORE

? ? ? ? ?driver connects the radio-wl1273 V4L2 module and the wl1273 ? ? ? ? ?audio codec.

drivers/mfd/Kconfig +9 -0

+config MFD_OMAP_CONTROL
+ ? ? ? bool "Texas Instruments OMAP System control module"
+ ? ? ? depends on ARCH_HAS_CONTROL_MODULE
+ ? ? ? help
+ ? ? ? ? This is the core driver for system control module. This driver
+ ? ? ? ? is responsible for creating the control module mfd child,
+ ? ? ? ? like USB-pin control, pin muxing, MMC-pbias and DDR IO dynamic
+ ? ? ? ? change for off mode.
+

?config MFD_OMAP_USB_HOST
? ? ? ?bool "Support OMAP USBHS core driver"
? ? ? ?depends on USB_EHCI_HCD_OMAP || USB_OHCI_HCD_OMAP3

drivers/mfd/Makefile +0 -0

index 05fa538..00f99d6 100644
@@ -106,6 +106,7 @@ obj-$(CONFIG_MFD_TPS6586X) ?+= tps6586x.o

?obj-$(CONFIG_MFD_VX855) ? ? ? ? ? ? ? ?+= vx855.o ?obj-$(CONFIG_MFD_WL1273_CORE) ?+= wl1273-core.o ?obj-$(CONFIG_MFD_CS5535) ? ? ? += cs5535-mfd.o +obj-$(CONFIG_MFD_OMAP_CONTROL) += omap-control-core.o ?obj-$(CONFIG_MFD_OMAP_USB_HOST) ? ? ? ?+= omap-usb-host.o ?obj-$(CONFIG_MFD_PM8921_CORE) ?+= pm8921-core.o ?obj-$(CONFIG_MFD_PM8XXX_IRQ) ? += pm8xxx-irq.o

drivers/mfd/omap-control-core.c new file +47 -0

new file mode 100644
index 0000000..7d8d408
@@ -0,0 +1,211 @@
+/*
+ * OMAP system control module driver file
+ *
+ * Copyright (C) 2011-2012 Texas Instruments Incorporated - http://www.ti.com/
+ * Contacts:
+ * Based on original code written by:
+ * ? ?J Keerthy <[email protected]>
+ * ? ?Moiz Sonasath <[email protected]>
+ * MFD clean up and re-factoring:
+ * ? ?Eduardo Valentin <[email protected]>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ?See the GNU
+ * General Public License for more details.
+ *
+ */
+
+#include <linux/module.h>
+#include <linux/export.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+#include <linux/io.h>
+#include <linux/err.h>
+#include <linux/of_platform.h>
+#include <linux/of_address.h>
+#include <linux/mfd/core.h>
+#include <linux/mfd/omap_control.h>
+
+static struct omap_control *omap_control_module;
+
+/**
+ * omap_control_readl: Read a single omap control module register.
+ *
+ * @dev: device to read from.
+ * @reg: register to read.
+ * @val: output with register value.
+ *
+ * returns 0 on success or -EINVAL in case struct device is invalid.
+ */
+int omap_control_readl(struct device *dev, u32 reg, u32 *val)
+{
+ ? ? ? struct omap_control *omap_control = dev_get_drvdata(dev);

drivers/mfd/omap-control-core.c new file +99 -0

+/**
+ * omap_control_writel: Write a single omap control module register.
+ *
+ * @dev: device to read from.
+ * @val: value to write.
+ * @reg: register to write to.
+ *
+ * returns 0 on success or -EINVAL in case struct device is invalid.
+ */
+int omap_control_writel(struct device *dev, u32 val, u32 reg)
+{
+ ? ? ? struct omap_control *omap_control = dev_get_drvdata(dev);
+ ? ? ? unsigned long flags;
+
+ ? ? ? if (!omap_control)
+ ? ? ? ? ? ? ? return -EINVAL;
+
+ ? ? ? spin_lock_irqsave(&omap_control->reg_lock, flags);
+ ? ? ? writel(val, omap_control->base + reg);
+ ? ? ? spin_unlock_irqrestore(&omap_control->reg_lock, flags);
+
+ ? ? ? return 0;
+}
+EXPORT_SYMBOL_GPL(omap_control_writel);
+
+/**
+ * omap_control_get: returns the control module device pinter
+ *
+ * The modules which has to use control module API's to read or write should
+ * call this API to get the control module device pointer.
+ */
+struct device *omap_control_get(void)
+{
+ ? ? ? unsigned long flags;
+
+ ? ? ? if (!omap_control_module)
+ ? ? ? ? ? ? ? return ERR_PTR(-ENODEV);
+
+ ? ? ? spin_lock_irqsave(&omap_control_module->reg_lock, flags);
+ ? ? ? omap_control_module->use_count++;
+ ? ? ? spin_unlock_irqrestore(&omap_control_module->reg_lock, flags);
+
+ ? ? ? return omap_control_module->dev;
+}
+EXPORT_SYMBOL_GPL(omap_control_get);
+
+/**
+ * omap_control_put: returns the control module device pinter
+ *
+ * The modules which has to use control module API's to read or write should
+ * call this API to get the control module device pointer.
+ */
+void omap_control_put(struct device *dev)
+{
+ ? ? ? struct omap_control *omap_control = dev_get_drvdata(dev);
+ ? ? ? unsigned long flags;
+
+ ? ? ? if (!omap_control)
+ ? ? ? ? ? ? ? return;
+
+ ? ? ? spin_lock_irqsave(&omap_control->reg_lock, flags);
+ ? ? ? omap_control->use_count--;
+ ? ? ? spin_unlock_irqrestore(&omap_control_module->reg_lock, flags);
+}
+EXPORT_SYMBOL_GPL(omap_control_put);
+
+static const struct of_device_id of_omap_control_match[] = {
+ ? ? ? { .compatible = "ti,omap3-control", },
+ ? ? ? { .compatible = "ti,omap4-control", },
+ ? ? ? { .compatible = "ti,omap5-control", },
+ ? ? ? { },
+};
+
+static int __devinit omap_control_probe(struct platform_device *pdev)
+{
+ ? ? ? struct resource *res;
+ ? ? ? void __iomem *base;
+ ? ? ? struct device *dev = &pdev->dev;
+ ? ? ? struct device_node *np = dev->of_node;
+ ? ? ? struct omap_control *omap_control;
+
+ ? ? ? omap_control = devm_kzalloc(dev, sizeof(*omap_control), GFP_KERNEL);
+ ? ? ? if (!omap_control) {
+ ? ? ? ? ? ? ? dev_err(dev, "not enough memory for omap_control\n");
+ ? ? ? ? ? ? ? return -ENOMEM;
+ ? ? ? }
+
+ ? ? ? res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ ? ? ? if (!res) {
+ ? ? ? ? ? ? ? dev_err(dev, "missing memory base resource\n");
+ ? ? ? ? ? ? ? return -EINVAL;
+ ? ? ? }
+
+ ? ? ? base = devm_request_and_ioremap(dev, res);
+ ? ? ? if (!base) {
+ ? ? ? ? ? ? ? dev_err(dev, "ioremap failed\n");
+ ? ? ? ? ? ? ? return -EADDRNOTAVAIL;
+ ? ? ? }
+

Quoted 22 lines · Eduardo Valentin

This patch introduces a MFD core device driver for OMAP system control module.

The control module allows software control of various static modes supported by the device. It is composed of two control submodules: general control module and device (padconfiguration) control module.

In this patch, the children defined are for:
. USB-phy pin control
. Bangap temperature sensor

Device driver is probed with postcore_initcall. However, as some of the APIs exposed by this driver may be needed in very early init phase, an early init class is also available: "early_omap_control".

Signed-off-by J Keerthy <[email protected]>

Signed-off-by Kishon Vijay Abraham I <[email protected]>

Signed-off-by Eduardo Valentin <[email protected]>

---

[..]

Quoted 8 lines

arch/arm/plat-omap/Kconfig +0 -0

index ad95c7a..222dbad 100644
@@ -5,6 +5,9 @@ menu "TI OMAP Common Features"

?config ARCH_OMAP_OTG
? ? ? ?bool

arch/arm/plat-omap/Kconfig menu "TI OMAP Common Features" · line 10

Quoted 3 lines

arch/arm/plat-omap/Kconfig +3 -0

+config ARCH_HAS_CONTROL_MODULE
+ ? ? ? bool
+

Thanks for getting rid of OMAP CONFIG here.

Quoted 93 lines

?choice
? ? ? ?prompt "OMAP System Type"
? ? ? ?default ARCH_OMAP2PLUS

drivers/mfd/Kconfig +0 -0

index 11e4438..25a66d8 100644
@@ -795,6 +795,15 @@ config MFD_WL1273_CORE

? ? ? ? ?driver connects the radio-wl1273 V4L2 module and the wl1273 ? ? ? ? ?audio codec.

drivers/mfd/Kconfig +9 -0

+config MFD_OMAP_CONTROL
+ ? ? ? bool "Texas Instruments OMAP System control module"
+ ? ? ? depends on ARCH_HAS_CONTROL_MODULE
+ ? ? ? help
+ ? ? ? ? This is the core driver for system control module. This driver
+ ? ? ? ? is responsible for creating the control module mfd child,
+ ? ? ? ? like USB-pin control, pin muxing, MMC-pbias and DDR IO dynamic
+ ? ? ? ? change for off mode.
+

?config MFD_OMAP_USB_HOST
? ? ? ?bool "Support OMAP USBHS core driver"
? ? ? ?depends on USB_EHCI_HCD_OMAP || USB_OHCI_HCD_OMAP3

drivers/mfd/Makefile +0 -0

index 05fa538..00f99d6 100644
@@ -106,6 +106,7 @@ obj-$(CONFIG_MFD_TPS6586X) ?+= tps6586x.o

?obj-$(CONFIG_MFD_VX855) ? ? ? ? ? ? ? ?+= vx855.o ?obj-$(CONFIG_MFD_WL1273_CORE) ?+= wl1273-core.o ?obj-$(CONFIG_MFD_CS5535) ? ? ? += cs5535-mfd.o +obj-$(CONFIG_MFD_OMAP_CONTROL) += omap-control-core.o ?obj-$(CONFIG_MFD_OMAP_USB_HOST) ? ? ? ?+= omap-usb-host.o ?obj-$(CONFIG_MFD_PM8921_CORE) ?+= pm8921-core.o ?obj-$(CONFIG_MFD_PM8XXX_IRQ) ? += pm8xxx-irq.o

drivers/mfd/omap-control-core.c new file +51 -0

new file mode 100644
index 0000000..7d8d408
@@ -0,0 +1,211 @@
+/*
+ * OMAP system control module driver file
+ *
+ * Copyright (C) 2011-2012 Texas Instruments Incorporated - http://www.ti.com/
+ * Contacts:
+ * Based on original code written by:
+ * ? ?J Keerthy <[email protected]>
+ * ? ?Moiz Sonasath <[email protected]>
+ * MFD clean up and re-factoring:
+ * ? ?Eduardo Valentin <[email protected]>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ?See the GNU
+ * General Public License for more details.
+ *
+ */
+
+#include <linux/module.h>
+#include <linux/export.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+#include <linux/io.h>
+#include <linux/err.h>
+#include <linux/of_platform.h>
+#include <linux/of_address.h>
+#include <linux/mfd/core.h>
+#include <linux/mfd/omap_control.h>
+
+static struct omap_control *omap_control_module;
+
+/**
+ * omap_control_readl: Read a single omap control module register.
+ *
+ * @dev: device to read from.
+ * @reg: register to read.
+ * @val: output with register value.
+ *
+ * returns 0 on success or -EINVAL in case struct device is invalid.
+ */
+int omap_control_readl(struct device *dev, u32 reg, u32 *val)
+{
+ ? ? ? struct omap_control *omap_control = dev_get_drvdata(dev);
+
+ ? ? ? if (!omap_control)
+ ? ? ? ? ? ? ? return -EINVAL;
+

drivers/mfd/omap-control-core.c line 57

Quoted 6 lines

drivers/mfd/omap-control-core.c new file +6 -0

+ ? ? ? *val = readl(omap_control->base + reg);
+
+ ? ? ? return 0;
+}
+EXPORT_SYMBOL_GPL(omap_control_readl);
+

I might have missed in the last scan, but can you let function return the register value.

I am guessing, you did this for error case handling. You might want to stick to read API semantic and just have WARN_ON() to take care of error case.

Quoted 104 lines

drivers/mfd/omap-control-core.c new file +103 -0

+/**
+ * omap_control_writel: Write a single omap control module register.
+ *
+ * @dev: device to read from.
+ * @val: value to write.
+ * @reg: register to write to.
+ *
+ * returns 0 on success or -EINVAL in case struct device is invalid.
+ */
+int omap_control_writel(struct device *dev, u32 val, u32 reg)
+{
+ ? ? ? struct omap_control *omap_control = dev_get_drvdata(dev);
+ ? ? ? unsigned long flags;
+
+ ? ? ? if (!omap_control)
+ ? ? ? ? ? ? ? return -EINVAL;
+
+ ? ? ? spin_lock_irqsave(&omap_control->reg_lock, flags);
+ ? ? ? writel(val, omap_control->base + reg);
+ ? ? ? spin_unlock_irqrestore(&omap_control->reg_lock, flags);
+
+ ? ? ? return 0;
+}
+EXPORT_SYMBOL_GPL(omap_control_writel);
+
+/**
+ * omap_control_get: returns the control module device pinter
+ *
+ * The modules which has to use control module API's to read or write should
+ * call this API to get the control module device pointer.
+ */
+struct device *omap_control_get(void)
+{
+ ? ? ? unsigned long flags;
+
+ ? ? ? if (!omap_control_module)
+ ? ? ? ? ? ? ? return ERR_PTR(-ENODEV);
+
+ ? ? ? spin_lock_irqsave(&omap_control_module->reg_lock, flags);
+ ? ? ? omap_control_module->use_count++;
+ ? ? ? spin_unlock_irqrestore(&omap_control_module->reg_lock, flags);
+
+ ? ? ? return omap_control_module->dev;
+}
+EXPORT_SYMBOL_GPL(omap_control_get);
+
+/**
+ * omap_control_put: returns the control module device pinter
+ *
+ * The modules which has to use control module API's to read or write should
+ * call this API to get the control module device pointer.
+ */
+void omap_control_put(struct device *dev)
+{
+ ? ? ? struct omap_control *omap_control = dev_get_drvdata(dev);
+ ? ? ? unsigned long flags;
+
+ ? ? ? if (!omap_control)
+ ? ? ? ? ? ? ? return;
+
+ ? ? ? spin_lock_irqsave(&omap_control->reg_lock, flags);
+ ? ? ? omap_control->use_count--;
+ ? ? ? spin_unlock_irqrestore(&omap_control_module->reg_lock, flags);
+}
+EXPORT_SYMBOL_GPL(omap_control_put);
+
+static const struct of_device_id of_omap_control_match[] = {
+ ? ? ? { .compatible = "ti,omap3-control", },
+ ? ? ? { .compatible = "ti,omap4-control", },
+ ? ? ? { .compatible = "ti,omap5-control", },
+ ? ? ? { },
+};
+
+static int __devinit omap_control_probe(struct platform_device *pdev)
+{
+ ? ? ? struct resource *res;
+ ? ? ? void __iomem *base;
+ ? ? ? struct device *dev = &pdev->dev;
+ ? ? ? struct device_node *np = dev->of_node;
+ ? ? ? struct omap_control *omap_control;
+
+ ? ? ? omap_control = devm_kzalloc(dev, sizeof(*omap_control), GFP_KERNEL);
+ ? ? ? if (!omap_control) {
+ ? ? ? ? ? ? ? dev_err(dev, "not enough memory for omap_control\n");
+ ? ? ? ? ? ? ? return -ENOMEM;
+ ? ? ? }
+
+ ? ? ? res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ ? ? ? if (!res) {
+ ? ? ? ? ? ? ? dev_err(dev, "missing memory base resource\n");
+ ? ? ? ? ? ? ? return -EINVAL;
+ ? ? ? }
+
+ ? ? ? base = devm_request_and_ioremap(dev, res);
+ ? ? ? if (!base) {
+ ? ? ? ? ? ? ? dev_err(dev, "ioremap failed\n");
+ ? ? ? ? ? ? ? return -EADDRNOTAVAIL;
+ ? ? ? }
+
+ ? ? ? omap_control->base = base;
+ ? ? ? omap_control->dev = dev;
+ ? ? ? spin_lock_init(&omap_control->reg_lock);
+

drivers/mfd/omap-control-core.c line 57

Quoted 6 lines

drivers/mfd/omap-control-core.c new file +6 -0

+ ? ? ? platform_set_drvdata(pdev, omap_control);
+ ? ? ? omap_control_module = omap_control;
+
+ ? ? ? return of_platform_populate(np, of_omap_control_match, NULL, dev);
+}
+

Will the probe get called on multiple devices and race ?

drivers/mfd/omap-control-core.c line 178

Quoted 13 lines

drivers/mfd/omap-control-core.c new file +12 -0

+static int __devexit omap_control_remove(struct platform_device *pdev)
+{
+ ? ? ? struct omap_control *omap_control = platform_get_drvdata(pdev);
+
+ ? ? ? spin_lock(&omap_control->reg_lock);
+ ? ? ? if (omap_control->use_count > 0) {
+ ? ? ? ? ? ? ? spin_unlock(&omap_control->reg_lock);
+ ? ? ? ? ? ? ? dev_err(&pdev->dev, "device removed while still being used\n");
+ ? ? ? ? ? ? ? return -EBUSY;
+ ? ? ? }
+ ? ? ? spin_unlock(&omap_control->reg_lock);
+

Do you really need above lock where you are just doing the register read. smp_rmb(), should be enough, I guess.

Regards
Santosh

Hello,

Quoted 34 lines · Santosh

Quoted 22 lines · Eduardo Valentin

This patch introduces a MFD core device driver for OMAP system control module.

The control module allows software control of various static modes supported by the device. It is composed of two control submodules: general control module and device (padconfiguration) control module.

In this patch, the children defined are for:
. USB-phy pin control
. Bangap temperature sensor

Device driver is probed with postcore_initcall. However, as some of the APIs exposed by this driver may be needed in very early init phase, an early init class is also available: "early_omap_control".

Signed-off-by J Keerthy <[email protected]>

Signed-off-by Kishon Vijay Abraham I <[email protected]>

Signed-off-by Eduardo Valentin <[email protected]>

---

[..]

Quoted 8 lines

arch/arm/plat-omap/Kconfig +0 -0

index ad95c7a..222dbad 100644
@@ -5,6 +5,9 @@ menu "TI OMAP Common Features"

?config ARCH_OMAP_OTG
? ? ? ?bool

Quoted 4 lines

arch/arm/plat-omap/Kconfig menu "TI OMAP Common Features" · line 10

Quoted 3 lines

arch/arm/plat-omap/Kconfig +3 -0

+config ARCH_HAS_CONTROL_MODULE
+ ? ? ? bool
+

Thanks for getting rid of OMAP CONFIG here.

OK. ARCH_HAS_CONTROL_MODULE is a bit too generic though..

Quoted 93 lines

Quoted 93 lines

?choice
? ? ? ?prompt "OMAP System Type"
? ? ? ?default ARCH_OMAP2PLUS

drivers/mfd/Kconfig +0 -0

index 11e4438..25a66d8 100644
@@ -795,6 +795,15 @@ config MFD_WL1273_CORE

? ? ? ? ?driver connects the radio-wl1273 V4L2 module and the wl1273 ? ? ? ? ?audio codec.

drivers/mfd/Kconfig +9 -0

+config MFD_OMAP_CONTROL
+ ? ? ? bool "Texas Instruments OMAP System control module"
+ ? ? ? depends on ARCH_HAS_CONTROL_MODULE
+ ? ? ? help
+ ? ? ? ? This is the core driver for system control module. This driver
+ ? ? ? ? is responsible for creating the control module mfd child,
+ ? ? ? ? like USB-pin control, pin muxing, MMC-pbias and DDR IO dynamic
+ ? ? ? ? change for off mode.
+

?config MFD_OMAP_USB_HOST
? ? ? ?bool "Support OMAP USBHS core driver"
? ? ? ?depends on USB_EHCI_HCD_OMAP || USB_OHCI_HCD_OMAP3

drivers/mfd/Makefile +0 -0

index 05fa538..00f99d6 100644
@@ -106,6 +106,7 @@ obj-$(CONFIG_MFD_TPS6586X) ?+= tps6586x.o

?obj-$(CONFIG_MFD_VX855) ? ? ? ? ? ? ? ?+= vx855.o ?obj-$(CONFIG_MFD_WL1273_CORE) ?+= wl1273-core.o ?obj-$(CONFIG_MFD_CS5535) ? ? ? += cs5535-mfd.o +obj-$(CONFIG_MFD_OMAP_CONTROL) += omap-control-core.o ?obj-$(CONFIG_MFD_OMAP_USB_HOST) ? ? ? ?+= omap-usb-host.o ?obj-$(CONFIG_MFD_PM8921_CORE) ?+= pm8921-core.o ?obj-$(CONFIG_MFD_PM8XXX_IRQ) ? += pm8xxx-irq.o

drivers/mfd/omap-control-core.c new file +51 -0

new file mode 100644
index 0000000..7d8d408
@@ -0,0 +1,211 @@
+/*
+ * OMAP system control module driver file
+ *
+ * Copyright (C) 2011-2012 Texas Instruments Incorporated - http://www.ti.com/
+ * Contacts:
+ * Based on original code written by:
+ * ? ?J Keerthy <[email protected]>
+ * ? ?Moiz Sonasath <[email protected]>
+ * MFD clean up and re-factoring:
+ * ? ?Eduardo Valentin <[email protected]>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ?See the GNU
+ * General Public License for more details.
+ *
+ */
+
+#include <linux/module.h>
+#include <linux/export.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+#include <linux/io.h>
+#include <linux/err.h>
+#include <linux/of_platform.h>
+#include <linux/of_address.h>
+#include <linux/mfd/core.h>
+#include <linux/mfd/omap_control.h>
+
+static struct omap_control *omap_control_module;
+
+/**
+ * omap_control_readl: Read a single omap control module register.
+ *
+ * @dev: device to read from.
+ * @reg: register to read.
+ * @val: output with register value.
+ *
+ * returns 0 on success or -EINVAL in case struct device is invalid.
+ */
+int omap_control_readl(struct device *dev, u32 reg, u32 *val)
+{
+ ? ? ? struct omap_control *omap_control = dev_get_drvdata(dev);
+
+ ? ? ? if (!omap_control)
+ ? ? ? ? ? ? ? return -EINVAL;
+

Quoted 8 lines

drivers/mfd/omap-control-core.c line 57

Quoted 6 lines

drivers/mfd/omap-control-core.c new file +6 -0

+ ? ? ? *val = readl(omap_control->base + reg);
+
+ ? ? ? return 0;
+}
+EXPORT_SYMBOL_GPL(omap_control_readl);
+

I might have missed in the last scan, but can you let function return the register value.