Re: [linux-pm] [PATCH v4 2/4] mfd: omap: control: core system control driver
Hi, Tony.
On 08/08/2012 06:59 PM, Konstantin Baydarov wrote:
Yes, omap_type() is called very early , that is why I'm using
early_initcall for omap_control_base initialization.
Do you mean following?:
void __init omap2_set_globals_control(struct omap_globals *omap2_globals)
{
if (omap2_globals-ctrl)
omap2_ctrl_base = omap2_globals-ctrl;
if (omap2_globals-ctrl_pad)
omap4_ctrl_pad_base = omap2_globals-ctrl_pad;
omap_control_base = omap2_ctrl_base; // this line is added
}
Sorry for the confusion - the code above isn't correct. First, as
omap-control-core.c driver maps only control module status register the
omap_control_base should be renamed to omap_control_status_reg:
--- a/drivers/mfd/omap-control-core.c
+++ b/drivers/mfd/omap-control-core.c
@@ -35,13 +35,15 @@
#include linux/of.h
#include linux/of_address.h
-void __iomem *omap_control_base;
+void __iomem *omap_control_status_reg;
unsigned long omap_control_phys_base;
size_t omap_control_mapsize;
u32 omap_control_status_read(void)
Then, if you want to move omap_control_status_reg(omap_control_base)
initialization to the
omap2_set_globals_control(), it can be done following way:
--- a/arch/arm/mach-omap2/control.c
+++ b/arch/arm/mach-omap2/control.c
@@ -149,6 +149,8 @@ static struct omap3_control_regs control_context;
#define OMAP_CTRL_REGADDR(reg) (omap2_ctrl_base + (reg))
#define OMAP4_CTRL_PAD_REGADDR(reg)(omap4_ctrl_pad_base + (reg))
+extern void __iomem *omap_control_status_reg;
+
void __init omap2_set_globals_control(struct omap_globals *omap2_globals)
{
if (omap2_globals-ctrl)
@@ -156,6 +158,20 @@ void __init omap2_set_globals_control(struct omap_globals
*omap2_globals)
if (omap2_globals-ctrl_pad)
omap4_ctrl_pad_base = omap2_globals-ctrl_pad;
+
+ omap_control_status_reg = omap2_ctrl_base;
+ if (cpu_is_omap24xx())
+ omap_control_status_reg += OMAP24XX_CONTROL_STATUS;
+ else if (soc_is_am33xx())
+ omap_control_status_reg += AM33XX_CONTROL_STATUS;
+ else if (cpu_is_omap34xx())
+ omap_control_status_reg += OMAP343X_CONTROL_STATUS;
+ else if (cpu_is_omap44xx())
+ omap_control_status_reg += OMAP4_CTRL_MODULE_CORE_STATUS;
+ else if (soc_is_omap54xx())
+ omap_control_status_reg += OMAP5XXX_CONTROL_STATUS;
+ else
+ omap_control_status_reg = 0;
}
void __iomem *omap_ctrl_base_get(void)
Then omap_type() can be changed:
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 8018cad..916b3f6 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -39,31 +39,27 @@ unsigned int omap_rev(void)
}
EXPORT_SYMBOL(omap_rev);
+extern void __iomem *omap_control_status_reg;
+
int omap_type(void)
{
u32 val = 0;
- if (cpu_is_omap24xx()) {
- val = omap_control_status_read();
- } else if (soc_is_am33xx()) {
- val = omap_control_status_read();
- } else if (cpu_is_omap34xx()) {
- val = omap_control_status_read();
- } else if (cpu_is_omap44xx()) {
+ if(!omap_control_status_reg) {
+ pr_err(Cannot detect omap type!\n);
+ goto out;
+ }
+
+ if(!soc_is_omap54xx()) {
val = omap_control_status_read();
- } else if (soc_is_omap54xx()) {
+ val = OMAP2_DEVICETYPE_MASK;
+ val = 8;
+ } else {
val = omap_control_status_read();
val = OMAP5_DEVICETYPE_MASK;
val = 6;
- goto out;
- } else {
- pr_err(Cannot detect omap type!\n);
- goto out;
}
- val = OMAP2_DEVICETYPE_MASK;
- val = 8;
-
out:
return val;
}
BR,
Konstantin Baydarov.
Or you suggest to move
void __init of_omap_control_init(const struct of_device_id *matches)
{
struct device_node *np;
struct property *pp = 0;
for_each_matching_node(np, matches) {
pp = of_find_property(np, reg, NULL);
if(pp) {
omap_control_phys_base = (unsigned long)be32_to_cpup(pp-value);
omap_control_mapsize = (size_t)be32_to_cpup(
(void*)((char*)pp-value + 4) );
/*
* Map control module register CONTROL_STATUS register:
* omap24xx - OMAP24XX_CONTROL_STATUS
* am33xx - AM33XX_CONTROL_STATUS
* omap34xx - OMAP343X_CONTROL_STATUS
* omap44xx - OMAP4_CTRL_MODULE_CORE_STATUS
* omap54xx - OMAP5XXX_CONTROL_STATUS
*/
omap_control_base = ioremap(omap_control_phys_base,
omap_control_mapsize);
}
}
}
into omap2_set_globals_control() ?
Also if we move omap_control_base initialization to
omap2_set_globals_control(), than the initialization routine of
drivers/mfd/omap-control-core.c
Re: [linux-pm] [PATCH v4 2/4] mfd: omap: control: core system control driver
Hi, Tony.
On 08/08/2012 06:39 PM, Tony Lindgren wrote:
* Tony Lindgren t...@atomide.com [120808 07:11]:
* Tony Lindgren t...@atomide.com [120808 07:05]:
* Konstantin Baydarov kbaida...@dev.rtsoft.ru [120725 04:10]:
+
+u32 omap_control_status_read(void)
+{
+ return __raw_readl(omap_control_base);
+}
Ah OK it's changed here.. Sorry I was looking at the older
version.
+void __init of_omap_control_init(const struct of_device_id *matches)
+{
+ struct device_node *np;
+ struct property *pp = 0;
+
+ for_each_matching_node(np, matches) {
+ pp = of_find_property(np, reg, NULL);
+ if(pp) {
+ omap_control_phys_base = (unsigned
long)be32_to_cpup(pp-value);
+ omap_control_mapsize = (size_t)be32_to_cpup(
(void*)((char*)pp-value + 4) );
+ /*
+ * Map control module register CONTROL_STATUS register:
+ * omap24xx - OMAP24XX_CONTROL_STATUS
+ * am33xx - AM33XX_CONTROL_STATUS
+ * omap34xx - OMAP343X_CONTROL_STATUS
+ * omap44xx - OMAP4_CTRL_MODULE_CORE_STATUS
+ * omap54xx - OMAP5XXX_CONTROL_STATUS
+ */
+ omap_control_base = ioremap(omap_control_phys_base,
omap_control_mapsize);
+ }
+ }
+}
You should probably add a function for setting omap_control_base
separately from *set_globals* in arch/arm/mach-omap2/common.c.
That way it's initialized early for id.c, and you can initialize
everything else later as regular device drivers.
FYI, we want to initialize as much as possible late so we have
proper debugging console set up in case things go wrong.
Hmm it seems that omap_control_base is now only initialized for DT boot
case? This will break booting on almost all systems..
Looking at things more, looks like omap_type() is getting called
early from timer.c. So maybe just let set_globals initialize
omap_control_base and let omap_type() read that directly. That way
the SCM core driver can behave like a regular device driver and it
does not need to be initialized early.
Yes, omap_type() is called very early , that is why I'm using early_initcall
for omap_control_base initialization.
Do you mean following?:
void __init omap2_set_globals_control(struct omap_globals *omap2_globals)
{
if (omap2_globals-ctrl)
omap2_ctrl_base = omap2_globals-ctrl;
if (omap2_globals-ctrl_pad)
omap4_ctrl_pad_base = omap2_globals-ctrl_pad;
omap_control_base = omap2_ctrl_base; // this line is added
}
Or you suggest to move
void __init of_omap_control_init(const struct of_device_id *matches)
{
struct device_node *np;
struct property *pp = 0;
for_each_matching_node(np, matches) {
pp = of_find_property(np, reg, NULL);
if(pp) {
omap_control_phys_base = (unsigned long)be32_to_cpup(pp-value);
omap_control_mapsize = (size_t)be32_to_cpup(
(void*)((char*)pp-value + 4) );
/*
* Map control module register CONTROL_STATUS register:
* omap24xx - OMAP24XX_CONTROL_STATUS
* am33xx - AM33XX_CONTROL_STATUS
* omap34xx - OMAP343X_CONTROL_STATUS
* omap44xx - OMAP4_CTRL_MODULE_CORE_STATUS
* omap54xx - OMAP5XXX_CONTROL_STATUS
*/
omap_control_base = ioremap(omap_control_phys_base,
omap_control_mapsize);
}
}
}
into omap2_set_globals_control() ?
Also if we move omap_control_base initialization to
omap2_set_globals_control(), than the initialization routine of
drivers/mfd/omap-control-core.c become empty, because omap_control_base is the
only thing that is initialized in omap-control-core driver.
BR,
Konstantin Baydarov.
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 0/4] OMAP System Control Module
Hello.
This is a next version of series of patches(based on Eduardo Valentin's patch
set) adding a basic support for system control module, on OMAP4+ context.
As Bandgap and usb phy drivers are now independent from control module driver
and they will be sent separately. IIUC, Bandgap driver has already been sent.
OMAP system control module driver provides only one API function - read of
CONTROL_STATUS register:
u32 omap_control_status_read(void) that is used in omap_type()
The physical address of CONTROL_STATUS register is specified in DT:
ctrl_module_core: ctrl_module_core@4A0022C4 {
compatible = ti,omap4-control;
#address-cells = 1;
#size-cells = 1;
/* ranges; */
ti,hwmods = ctrl_module_core;
reg = 0x4A0022C4 0x4; /* CONTROL_STATUS register */
};
Eduardo Valentin (3):
From d4c6cf571e403f30a97db32ba6198b0c35a864b7 Mon Sep 17 00:00:00
2001
From 116a0111a6e2e563a81b0aa2dbf7a18e9ef9dbd1 Mon Sep 17 00:00:00
2001
From dda5f1badbfb82718c9ff21098998a842ce6886e Mon Sep 17 00:00:00
2001
Santosh Shilimkar (1):
From 1c2af619cc34aafc027330fbb823595e3b2d139b Mon Sep 17 00:00:00
2001
.../devicetree/bindings/mfd/omap_control.txt | 32 +
arch/arm/boot/dts/omap4.dtsi | 10 +
arch/arm/mach-omap2/Kconfig|1 +
arch/arm/mach-omap2/control.h | 48 +-
arch/arm/mach-omap2/id.c | 11 +-
.../include/mach/ctrl_module_core_44xx.h | 392 --
.../include/mach/ctrl_module_pad_core_44xx.h | 1409
.../include/mach/ctrl_module_pad_wkup_44xx.h | 236
.../include/mach/ctrl_module_wkup_44xx.h | 92 --
arch/arm/plat-omap/Kconfig |4 +
drivers/mfd/Kconfig|6 +
drivers/mfd/Makefile |1 +
drivers/mfd/omap-control-core.c| 162 +++
include/linux/mfd/omap_control.h | 35 +
14 files changed, 300 insertions(+), 2139 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mfd/omap_control.txt
delete mode 100644 arch/arm/mach-omap2/include/mach/ctrl_module_core_44xx.h
delete mode 100644 arch/arm/mach-omap2/include/mach/ctrl_module_pad_core_44xx.h
delete mode 100644 arch/arm/mach-omap2/include/mach/ctrl_module_pad_wkup_44xx.h
delete mode 100644 arch/arm/mach-omap2/include/mach/ctrl_module_wkup_44xx.h
create mode 100644 drivers/mfd/omap-control-core.c
create mode 100644 include/linux/mfd/omap_control.h
--
1.7.7.6
[PATCH v4 2/4] mfd: omap: control: core system control driver
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.
Device driver is probed with postcore_initcall.
Control module register CONTROL_STATUS that is needed
by omap_type() is early mapped by postcore_initcall_sync.
Signed-off-by: J Keerthy j-keer...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
Signed-off-by: Konstantin Baydarov kbaida...@dev.rtsoft.ru
---
.../devicetree/bindings/mfd/omap_control.txt | 32
arch/arm/mach-omap2/Kconfig|1 +
arch/arm/plat-omap/Kconfig |4 +
drivers/mfd/Kconfig|6 +
drivers/mfd/Makefile |1 +
drivers/mfd/omap-control-core.c| 162
include/linux/mfd/omap_control.h | 35 +
7 files changed, 241 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
diff --git a/Documentation/devicetree/bindings/mfd/omap_control.txt
b/Documentation/devicetree/bindings/mfd/omap_control.txt
new file mode 100644
index 000..a9dca9e
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/omap_control.txt
@@ -0,0 +1,32 @@
+* 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;
+
+OMAP CONTROL_STATUS register:
+reg = 0x4A0022C4 0x4; /* CONTROL_STATUS register */
+
+Examples:
+ctrl_module_core: ctrl_module_core@4A0022C4 {
+ compatible = ti,omap4-control;
+ #address-cells = 1;
+ #size-cells = 1;
+ /* ranges; */
+ ti,hwmods = ctrl_module_core;
+ reg = 0x4A0022C4 0x4; /* CONTROL_STATUS register */
+};
+
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index dd0fbf7..1235576 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -59,6 +59,7 @@ config ARCH_OMAP4
select ARM_ERRATA_720789
select ARCH_HAS_OPP
select PM_RUNTIME if CPU_IDLE
+ select ARCH_HAS_CONTROL_MODULE
select PM_OPP if PM
select USB_ARCH_HAS_EHCI if USB_SUPPORT
select ARM_CPU_SUSPEND if PM
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index dd36eba..2b2c9d8 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -5,6 +5,10 @@ menu TI OMAP Common Features
config ARCH_OMAP_OTG
bool
+config ARCH_HAS_CONTROL_MODULE
+ bool
+ select MFD_OMAP_CONTROL
+
choice
prompt OMAP System Type
default ARCH_OMAP2PLUS
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 92144ed..530ac60 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -823,6 +823,12 @@ 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.
+
config MFD_OMAP_USB_HOST
bool Support OMAP USBHS core driver
depends on USB_EHCI_HCD_OMAP || USB_OHCI_HCD_OMAP3
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 75f6ed6..b037443 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -107,6 +107,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
diff --git a/drivers/mfd/omap-control-core.c b/drivers/mfd/omap-control-core.c
new file mode 100644
index 000..cefbc5a
--- /dev/null
+++ b/drivers/mfd/omap-control-core.c
@@ -0,0 +1,162 @@
+/*
+ * OMAP system control
[PATCH v4 3/4] OMAP2+: use control module mfd driver in omap_type
OMAP system control module can be probed early, then
omap_type is safe to use its APIs.
TODO: add support for other omap versions
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
Signed-off-by: Konstantin Baydarov kbaida...@dev.rtsoft.ru
---
arch/arm/mach-omap2/id.c | 11 ++-
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 40373db..8018cad 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -18,6 +18,7 @@
#include linux/kernel.h
#include linux/init.h
#include linux/io.h
+#include linux/mfd/omap_control.h
#include asm/cputype.h
@@ -43,15 +44,15 @@ int omap_type(void)
u32 val = 0;
if (cpu_is_omap24xx()) {
- val = omap_ctrl_readl(OMAP24XX_CONTROL_STATUS);
+ val = omap_control_status_read();
} else if (soc_is_am33xx()) {
- val = omap_ctrl_readl(AM33XX_CONTROL_STATUS);
+ val = omap_control_status_read();
} else if (cpu_is_omap34xx()) {
- val = omap_ctrl_readl(OMAP343X_CONTROL_STATUS);
+ val = omap_control_status_read();
} else if (cpu_is_omap44xx()) {
- val = omap_ctrl_readl(OMAP4_CTRL_MODULE_CORE_STATUS);
+ val = omap_control_status_read();
} else if (soc_is_omap54xx()) {
- val = omap_ctrl_readl(OMAP5XXX_CONTROL_STATUS);
+ val = omap_control_status_read();
val = OMAP5_DEVICETYPE_MASK;
val = 6;
goto out;
--
1.7.7.6
[PATCH v4 4/4] ARM: DT: Add support to system control module for OMAP4
This patch add device tree entries on OMAP4 based boards
for System Control Module (SCM).
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
Signed-off-by: Konstantin Baydarov kbaida...@dev.rtsoft.ru
---
arch/arm/boot/dts/omap4.dtsi | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 04cbbcb..59f83c9 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -295,5 +295,15 @@
interrupt-parent = gic;
ti,hwmods = dmic;
};
+
+ ctrl_module_core: ctrl_module_core@4A0022C4 {
+ compatible = ti,omap4-control;
+ #address-cells = 1;
+ #size-cells = 1;
+ /* ranges; */
+ ti,hwmods = ctrl_module_core;
+ reg = 0x4A0022C4 0x4; /* CONTROL_STATUS register */
+ };
+
};
};
--
1.7.7.6
Re: [PATCH v4 1/4] ARM: OMAP4: Remove un-used control module headers and defines.
Hi, Balbi. On 07/25/2012 03:06 PM, Felipe Balbi wrote: Hi, On Wed, Jul 25, 2012 at 03:05:13PM +0400, Konstantin Baydarov wrote: 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 santosh.shilim...@ti.com Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com Signed-off-by: Konstantin Baydarov kbaida...@dev.rtsoft.ru Wasn't this one authored by Santosh ?? Where's his From: Santosh Shilimkar ??? I hit edit as new when I sent patches through thunderbird, I'll fix in the next series. BR, Konstantin Baydarov. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 3/4] OMAP2+: use control module mfd driver in omap_type
HI, Sergei.
On 07/25/2012 04:39 PM, Sergei Shtylyov wrote:
Hello.
On 25-07-2012 15:05, Konstantin Baydarov wrote:
OMAP system control module can be probed early, then
omap_type is safe to use its APIs.
TODO: add support for other omap versions
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
Signed-off-by: Konstantin Baydarov kbaida...@dev.rtsoft.ru
---
arch/arm/mach-omap2/id.c | 11 ++-
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 40373db..8018cad 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
[...]
@@ -43,15 +44,15 @@ int omap_type(void)
u32 val = 0;
if (cpu_is_omap24xx()) {
-val = omap_ctrl_readl(OMAP24XX_CONTROL_STATUS);
+val = omap_control_status_read();
} else if (soc_is_am33xx()) {
-val = omap_ctrl_readl(AM33XX_CONTROL_STATUS);
+val = omap_control_status_read();
} else if (cpu_is_omap34xx()) {
-val = omap_ctrl_readl(OMAP343X_CONTROL_STATUS);
+val = omap_control_status_read();
} else if (cpu_is_omap44xx()) {
-val = omap_ctrl_readl(OMAP4_CTRL_MODULE_CORE_STATUS);
+val = omap_control_status_read();
Isn't it better to merge now identical code into one *if*?
Good point.
WBR, Sergei
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/7] mfd: omap: control: core system control driver
Hi.
On 06/28/2012 08:50 AM, Eduardo Valentin wrote:
Hello,
On Wed, Jun 27, 2012 at 10:04:54PM +0400, Konstantin Baydarov wrote:
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.
Changes since previous version:
- omap-control-core: resources aren't hardcoded, they are specified in dts
file.
- omap-control-core: Control module is a built-in driver - added control
module select to ARCH_HAS_CONTROL_MODULE and ARCH_OMAP4.
Probably, no configuration option is required!
- omap-control-core: Added early init call that ioremaps control module
IOMEM window, this allows access of SCM registers very early, for example
from omap_type()
- omap-control-core: Removed device pointer from omap-control-core API
arguments, becuase there can be only one instance control
module device.
- omap-control-core: removed omap_control_get, omap_control_readl,
omap_control_writel
- omap-control-core: added omap_control_status_read that is used early in
omap_type
Signed-off-by: Konstantin Baydarov kbaida...@dev.rtsoft.ru
Signed-off-by: J Keerthy j-keer...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
.../devicetree/bindings/mfd/omap_control.txt | 44 +++
arch/arm/mach-omap2/Kconfig|1 +
arch/arm/plat-omap/Kconfig |4 +
drivers/mfd/Kconfig|9 ++
drivers/mfd/Makefile |1 +
drivers/mfd/omap-control-core.c| 131
include/linux/mfd/omap_control.h | 52
7 files changed, 242 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
diff --git a/Documentation/devicetree/bindings/mfd/omap_control.txt
b/Documentation/devicetree/bindings/mfd/omap_control.txt
new file mode 100644
index 000..46d5e7e
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/omap_control.txt
@@ -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@4a002000 {
+compatible = ti,omap4-control;
+ti,hwmods = ctrl_module_core;
+bandgap {
+compatible = ti,omap4460-bandgap;
You need to update the documentation if change the DT structure.
Ok.
+interrupts = 0 126 4; /* talert */
+ti,tshut-gpio = 86; /* tshut */
+};
+usb {
+compatible = ti,omap4-usb-phy;
+};
+};
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 4cf5142..c2ef07c 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -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
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index ad95c7a..0f9b575 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -5,6 +5,10 @@ menu TI OMAP Common Features
config ARCH_OMAP_OTG
bool
+config ARCH_HAS_CONTROL_MODULE
+bool
+select MFD_OMAP_CONTROL
+
OK now I got what you meant in patch 0. Fine for me.
choice
prompt OMAP System Type
default ARCH_OMAP2PLUS
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index e129c82..d0c5456 100644
Re: [PATCH v3 2/7] mfd: omap: control: core system control driver
Hello.
On 06/28/2012 01:49 PM, Valentin, Eduardo wrote:
Hello,
On Thu, Jun 28, 2012 at 12:37 PM, Konstantin Baydarov
kbaida...@dev.rtsoft.ru wrote:
Hi.
On 06/28/2012 08:50 AM, Eduardo Valentin wrote:
Hello,
On Wed, Jun 27, 2012 at 10:04:54PM +0400, Konstantin Baydarov wrote:
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.
Changes since previous version:
- omap-control-core: resources aren't hardcoded, they are specified in dts
file.
- omap-control-core: Control module is a built-in driver - added control
module select to ARCH_HAS_CONTROL_MODULE and ARCH_OMAP4.
Probably, no configuration option is required!
- omap-control-core: Added early init call that ioremaps control module
IOMEM window, this allows access of SCM registers very early, for example
from omap_type()
- omap-control-core: Removed device pointer from omap-control-core API
arguments, becuase there can be only one instance control
module device.
- omap-control-core: removed omap_control_get, omap_control_readl,
omap_control_writel
- omap-control-core: added omap_control_status_read that is used early in
omap_type
Signed-off-by: Konstantin Baydarov kbaida...@dev.rtsoft.ru
Signed-off-by: J Keerthy j-keer...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
.../devicetree/bindings/mfd/omap_control.txt | 44 +++
arch/arm/mach-omap2/Kconfig|1 +
arch/arm/plat-omap/Kconfig |4 +
drivers/mfd/Kconfig|9 ++
drivers/mfd/Makefile |1 +
drivers/mfd/omap-control-core.c| 131
include/linux/mfd/omap_control.h | 52
7 files changed, 242 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
diff --git a/Documentation/devicetree/bindings/mfd/omap_control.txt
b/Documentation/devicetree/bindings/mfd/omap_control.txt
new file mode 100644
index 000..46d5e7e
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/omap_control.txt
@@ -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@4a002000 {
+compatible = ti,omap4-control;
+ti,hwmods = ctrl_module_core;
+bandgap {
+compatible = ti,omap4460-bandgap;
You need to update the documentation if change the DT structure.
Ok.
+interrupts = 0 126 4; /* talert */
+ti,tshut-gpio = 86; /* tshut */
+};
+usb {
+compatible = ti,omap4-usb-phy;
+};
+};
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 4cf5142..c2ef07c 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -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
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index ad95c7a..0f9b575 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -5,6 +5,10 @@ menu TI OMAP Common Features
config ARCH_OMAP_OTG
bool
+config ARCH_HAS_CONTROL_MODULE
+bool
+select MFD_OMAP_CONTROL
+
OK now I got what you meant in patch 0. Fine for me
Re: [PATCH v3 2/7] mfd: omap: control: core system control driver
On 06/28/2012 02:12 PM, Konstantin Baydarov wrote: The interface(design) of omap-control-core.c has already been discussed many times :( Eduardo, in his patch set, suggested following design: - omap-control-core.c ioremaps SCM window and provide functions to read/write SCP register for bandgap and usb. IIRC, this approach didn't satisfy and it was suggested to have private read/write in bandgap and usb. So, my patch set introduces following design: - omap-control-core.c don't provide read/write functions for bandgap and usb. - bandgap and usb use their own private read/write functions - Each omap-control-core.c, bandgap and usb drivers remap SCM window. It's OK because SCM window is statically mapped to the same virtual address. But the problem is that SMP memory window isn't protected. I'm not sure whether it's possible to protect SCM window using this approach. I mean: - Each omap-control-core.c, bandgap and usb drivers remap SCM window. It's OK because SCM window is statically mapped. So each call of ioremap in omap-control-core.c, bandgap and usb drivers returns the same virtual address. But the problem is that SCM memory window isn't protected. I'm not sure whether it's possible to protect SCM window using this approach(when each driver remaps the same IOMEM). Another possible design is: - omap-control-core.c ioremaps and reserves SCM IOMEM window - omap-control-core.c exports omap_control_get_base(virtual base address is returned) to use in bandgap and usb_phy driver. - Bandgap and usb phy uses their own private read/write function. IIUC, this way was suggested by Tony. I guess It's better to settle the design(interface) of omap-control-core.c, bandgap and usb phy and then submit the next version of patch set. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/7] OMAP System Control Module
Hello. This is a next version of series of patches(based on Eduardo Valentin's patch set) adding a basic support for system control module, on OMAP4+ context. It is a working in progress. Main changes since previous patch set version: - Bandgap and usb phy: drivers are now independent from control module driver, they use their own functions to acess scm registers. - omap-control-core: resources aren't hardcoded, they are specified in dts file. - omap-control-core: Control module is a built-in driver - added control module select to ARCH_HAS_CONTROL_MODULE and ARCH_OMAP4. Probably, no configuration option is required! - omap-control-core: Added early init call that ioremaps control module IOMEM window, this allows access of SCM registers very early, for example from omap_type() - omap-control-core: Removed device pointer from omap-control-core API arguments, becuase there can be only one instance control module device. - omap-control-core: removed omap_control_get, omap_control_readl, omap_control_writel - omap-control-core: added omap_control_status_read that is used early in omap_type - Bandgap and usb phy: Added private spinlocks for bandgap and usb drivers. - Bandgap: Check the type of bandgap dynamically in bandgap driver probe function by reading omap core control module revision register CONTROL_GEN_CORE_REVISION. - Bandgap and usb phy: Parent SCM platform device IOMEM resources is used to get the base address of SCM window. - Bandgap masks defines were moved to drivers/thermal/omap-bandgap.c. TODO list for bandgap driver: - Reserve omap-control-core IOMEM window. - Improve thermal zone definition for OMAP4 - Introduce the thermal zones for OMAP5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/7] mfd: omap: control: core system control driver
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.
Changes since previous version:
- omap-control-core: resources aren't hardcoded, they are specified in dts file.
- omap-control-core: Control module is a built-in driver - added control module
select to ARCH_HAS_CONTROL_MODULE and ARCH_OMAP4.
Probably, no configuration option is required!
- omap-control-core: Added early init call that ioremaps control module IOMEM
window, this allows access of SCM registers very early, for example from
omap_type()
- omap-control-core: Removed device pointer from omap-control-core API
arguments, becuase there can be only one instance control
module device.
- omap-control-core: removed omap_control_get, omap_control_readl,
omap_control_writel
- omap-control-core: added omap_control_status_read that is used early in
omap_type
Signed-off-by: Konstantin Baydarov kbaida...@dev.rtsoft.ru
Signed-off-by: J Keerthy j-keer...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
.../devicetree/bindings/mfd/omap_control.txt | 44 +++
arch/arm/mach-omap2/Kconfig|1 +
arch/arm/plat-omap/Kconfig |4 +
drivers/mfd/Kconfig|9 ++
drivers/mfd/Makefile |1 +
drivers/mfd/omap-control-core.c| 131
include/linux/mfd/omap_control.h | 52
7 files changed, 242 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
diff --git a/Documentation/devicetree/bindings/mfd/omap_control.txt
b/Documentation/devicetree/bindings/mfd/omap_control.txt
new file mode 100644
index 000..46d5e7e
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/omap_control.txt
@@ -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@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;
+ };
+};
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 4cf5142..c2ef07c 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -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
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index ad95c7a..0f9b575 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -5,6 +5,10 @@ menu TI OMAP Common Features
config ARCH_OMAP_OTG
bool
+config ARCH_HAS_CONTROL_MODULE
+ bool
+ select MFD_OMAP_CONTROL
+
choice
prompt OMAP System Type
default ARCH_OMAP2PLUS
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index e129c82..d0c5456 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -822,6 +822,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
[PATCH v3 3/7] OMAP2+: use control module mfd driver in omap_type
OMAP system control module can be probed early, then
omap_type is safe to use its APIs.
TODO: add support for other omap versions
Signed-off-by: Konstantin Baydarov kbaida...@dev.rtsoft.ru
---
arch/arm/mach-omap2/id.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 00486a8..1b0cec8 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -18,6 +18,7 @@
#include linux/kernel.h
#include linux/init.h
#include linux/io.h
+#include linux/mfd/omap_control.h
#include asm/cputype.h
@@ -43,13 +44,13 @@ int omap_type(void)
u32 val = 0;
if (cpu_is_omap24xx()) {
- val = omap_ctrl_readl(OMAP24XX_CONTROL_STATUS);
+ val = omap_control_status_read(OMAP24XX_CONTROL_STATUS);
} else if (cpu_is_am33xx()) {
- val = omap_ctrl_readl(AM33XX_CONTROL_STATUS);
+ val = omap_control_status_read(AM33XX_CONTROL_STATUS);
} else if (cpu_is_omap34xx()) {
- val = omap_ctrl_readl(OMAP343X_CONTROL_STATUS);
+ val = omap_control_status_read(OMAP343X_CONTROL_STATUS);
} else if (cpu_is_omap44xx()) {
- val = omap_ctrl_readl(OMAP4_CTRL_MODULE_CORE_STATUS);
+ val = omap_control_status_read(OMAP4_CTRL_MODULE_CORE_STATUS);
} else {
pr_err(Cannot detect omap type!\n);
goto out;
--
1.7.7.6
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 4/7] mfd: omap: control: usb-phy: introduce the ctrl-module usb driver
Created a new platform driver for the platform device created by the
control module mfd core, wrt usb. This driver has API's to power on/off
the phy and the API's to write to musb mailbox.
Changes since previous version:
- Bandgap and usb phy: drivers are now independent from control module driver,
they use
their own functions to acess scm registers.
- Parent SCM platform device IOMEM resources is used to get the base address of
SCM window.
- SCM Dependency was removed from Kconfig.
- Bandgap and usb phy: Added private spinlocks for bandgap and usb drivers.
(p.s. the mailbox for musb in omap4 is present in system control
module)
[kis...@ti.com: wrote the original API's related to USB functions]
Signed-off-by: Konstantin Baydarov kbaida...@dev.rtsoft.ru
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/usb/otg/Kconfig | 12 +++
drivers/usb/otg/Makefile |1 +
drivers/usb/otg/omap4-usb-phy.c | 170 +
include/linux/usb/omap4_usb_phy.h | 53
4 files changed, 236 insertions(+), 0 deletions(-)
create mode 100644 drivers/usb/otg/omap4-usb-phy.c
create mode 100644 include/linux/usb/omap4_usb_phy.h
diff --git a/drivers/usb/otg/Kconfig b/drivers/usb/otg/Kconfig
index 5c87db0..0ed691b 100644
--- a/drivers/usb/otg/Kconfig
+++ b/drivers/usb/otg/Kconfig
@@ -78,6 +78,18 @@ config TWL6030_USB
are hooked to this driver through platform_data structure.
The definition of internal PHY APIs are in the mach-omap2 layer.
+config OMAP4_USB_PHY
+ tristate Texas Instruments OMAP4+ USB pin control driver
+ help
+ If you say yes here you get support for the Texas Instruments
+ OMAP4+ USB pin control driver. The register set is part of system
+ control module.
+
+ USB phy in OMAP configures control module register for powering on
+ the phy, configuring VBUSVALID, AVALID, IDDIG and SESSEND. For
+ performing the above mentioned configuration, API's are added in
+ by this children of the control module driver.
+
config NOP_USB_XCEIV
tristate NOP USB Transceiver Driver
select USB_OTG_UTILS
diff --git a/drivers/usb/otg/Makefile b/drivers/usb/otg/Makefile
index 41aa509..60c8c83 100644
--- a/drivers/usb/otg/Makefile
+++ b/drivers/usb/otg/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_USB_GPIO_VBUS) += gpio_vbus.o
obj-$(CONFIG_ISP1301_OMAP) += isp1301_omap.o
obj-$(CONFIG_TWL4030_USB) += twl4030-usb.o
obj-$(CONFIG_TWL6030_USB) += twl6030-usb.o
+obj-$(CONFIG_OMAP4_USB_PHY)+= omap4-usb-phy.o
obj-$(CONFIG_NOP_USB_XCEIV)+= nop-usb-xceiv.o
obj-$(CONFIG_USB_ULPI) += ulpi.o
obj-$(CONFIG_USB_ULPI_VIEWPORT)+= ulpi_viewport.o
diff --git a/drivers/usb/otg/omap4-usb-phy.c b/drivers/usb/otg/omap4-usb-phy.c
new file mode 100644
index 000..cbea2ea
--- /dev/null
+++ b/drivers/usb/otg/omap4-usb-phy.c
@@ -0,0 +1,170 @@
+/*
+ * OMAP4 system control module driver, USB control children
+ *
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * Contact:
+ *Kishon Vijay Abraham I kis...@ti.com
+ *Eduardo Valentin eduardo.valen...@ti.com
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+
+#include linux/module.h
+#include linux/init.h
+#include linux/gpio.h
+#include linux/delay.h
+#include linux/err.h
+#include linux/platform_device.h
+#include linux/usb/omap4_usb_phy.h
+
+void __iomem *omap_usb_phy_base;
+spinlock_t omap_usb_phy_lock;
+
+static int omap_usb_phy_readl(u32 reg, u32 *val)
+{
+ if (!omap_usb_phy_base)
+ return -EINVAL;
+
+ *val = __raw_readl(omap_usb_phy_base + reg);
+ return 0;
+}
+
+/*
+ * TODO: Get rid from omap_usb_phy_writel() return value -
+ * It's useless.
+ */
+static int omap_usb_phy_writel(u32 val, u32 reg)
+{
+ unsigned long flags;
+
+ if (!omap_usb_phy_base)
+ return -EINVAL;
+
+ spin_lock_irqsave(omap_usb_phy_lock, flags);
+ __raw_writel(val, omap_usb_phy_base + reg);
+ spin_unlock_irqrestore(omap_usb_phy_lock, flags);
+ return 0;
+}
+
+/**
+ * omap4_usb_phy_power - power on/off the phy using control module reg
+ * @dev: struct device *
+ * @on: 0 or 1, based on powering on or off the PHY
+ *
+ * omap_usb2
[PATCH v3 6/7] omap4: thermal: add basic CPU thermal zone
omap4: thermal: add basic CPU thermal zone
This patch exposes OMAP4 thermal sensor as a thermal zone
named cpu. Only thermal creation is done here.
TODO:
- Add cooling bindings
- Add extrapolation rules
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/thermal/Kconfig | 12 ++
drivers/thermal/Makefile|1 +
drivers/thermal/omap-bandgap.c |1 +
drivers/thermal/omap-bandgap.h | 12 ++
drivers/thermal/omap4-thermal.c | 72 +++
5 files changed, 98 insertions(+), 0 deletions(-)
create mode 100644 drivers/thermal/omap4-thermal.c
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index f9989e8..7d44b5c 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -38,3 +38,15 @@ config OMAP_BANDGAP
This includes alert interrupts generation and also the TSHUT
support.
+config OMAP4_THERMAL
+ bool Texas Instruments OMAP4 thermal support
+ depends on OMAP_BANDGAP
+ depends on ARCH_OMAP4
+ help
+ If you say yes here you get thermal support for the Texas Instruments
+ OMAP4 SoC family. The current chip supported are:
+ - OMAP4460
+
+ This includes alert interrupts generation and also the TSHUT
+ support.
+
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index 5ff1af1..6397678 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -6,3 +6,4 @@ obj-$(CONFIG_THERMAL) += thermal_sys.o
obj-$(CONFIG_SPEAR_THERMAL)+= spear_thermal.o
obj-$(CONFIG_OMAP_BANDGAP) += omap-thermal.o
omap-thermal-y := omap-bandgap.o
+omap-thermal-$(CONFIG_OMAP4_THERMAL) += omap4-thermal.o
diff --git a/drivers/thermal/omap-bandgap.c b/drivers/thermal/omap-bandgap.c
index c68fa1a..c80d879 100644
--- a/drivers/thermal/omap-bandgap.c
+++ b/drivers/thermal/omap-bandgap.c
@@ -1328,6 +1328,7 @@ static const struct omap_bandgap_data omap4460_data = {
.fclock_name = bandgap_ts_fclk,
.div_ck_name = div_ts_ck,
.conv_table = omap4460_adc_to_temp,
+ .expose_sensor = omap4_thermal_expose_sensor,
.irq = 126,
.sensors = {
{
diff --git a/drivers/thermal/omap-bandgap.h b/drivers/thermal/omap-bandgap.h
index 41f25ff..3f4c192 100644
--- a/drivers/thermal/omap-bandgap.h
+++ b/drivers/thermal/omap-bandgap.h
@@ -61,4 +61,16 @@ int omap_bandgap_write_update_interval(struct omap_bandgap
*bg_ptr, int id,
int omap_bandgap_read_temperature(struct omap_bandgap *bg_ptr, int id,
int *temperature);
+#ifdef CONFIG_OMAP4_THERMAL
+int omap4_thermal_expose_sensor(struct omap_bandgap *bg_ptr, int id,
+ char *domain);
+#else
+static inline int omap4_thermal_expose_sensor(struct omap_bandgap *bg_ptr,
+ int id, char *domain)
+{
+ return 0;
+}
+
+#endif
+
#endif
diff --git a/drivers/thermal/omap4-thermal.c b/drivers/thermal/omap4-thermal.c
new file mode 100644
index 000..fb11753
--- /dev/null
+++ b/drivers/thermal/omap4-thermal.c
@@ -0,0 +1,72 @@
+/*
+ * SPEAr thermal driver.
+ *
+ * Copyright (C) 2011-2012 Texas Instruments Inc.
+ * Contact:
+ * Eduardo Valentin eduardo.valen...@ti.com
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * 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/device.h
+#include linux/err.h
+#include linux/io.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/thermal.h
+
+#include omap-bandgap.h
+
+struct omap4_thermal_data {
+ struct thermal_zone_device *omap4_thermal;
+ struct omap_bandgap *bg_ptr;
+ int sensor_id;
+};
+
+static inline int omap4_thermal_get_temp(struct thermal_zone_device *thermal,
+unsigned long *temp)
+{
+ struct omap4_thermal_data *data = thermal-devdata;
+ int ret, tmp;
+
+ ret = omap_bandgap_read_temperature(data-bg_ptr, data-sensor_id,
+ tmp);
+ if (!ret)
+ *temp = tmp;
+
+ return ret;
+}
+
+static struct thermal_zone_device_ops omap4_thermal_ops = {
+ .get_temp = omap4_thermal_get_temp,
+};
+
+int omap4_thermal_expose_sensor(struct omap_bandgap *bg_ptr, int id,
+ char *domain)
+{
+ struct omap4_thermal_data *data;
+
+ data = devm_kzalloc(bg_ptr-dev, sizeof(*data), GFP_KERNEL);
+ if (!data) {
+ dev_err(bg_ptr-dev, kzalloc fail\n);
Re: [RFC PATCH v2 03/11] mfd: omap: control: core system control driver
Hi, Tony.
On 06/20/2012 02:22 PM, Tony Lindgren wrote:
* Konstantin Baydarov kbaida...@dev.rtsoft.ru [120618 04:36]:
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.
+++ linux-2.6/drivers/mfd/omap-control-core.c
...
+u32 omap_control_readl(u16 offset)
+{
+return __raw_readl(omap_control_base + (offset));
+}
+
+void omap_control_writel(u32 val, u16 offset)
+{
+__raw_writel(val, omap_control_base + (offset));
+}
There should not be any need to have the individual drivers use
these. Please instead just set up something where individual drivers
register with the control module core, and get their own iobase
returned so they can use readl/writel and behave like normal device
drivers.
IIUC one of the reasons drivers/mfd/omap-control-core.c introduction is
replacement of arch/arm/mach-omap2/control.c. control.c provides
omap_ctrl_readl/omap_ctrl_writel API which are heavily used in
arch/arm/mach-omap2/:
arch/arm/mach-omap2/hsmmc.c
arch/arm/mach-omap2/usb-fs.c
arch/arm/mach-omap2/sr_device.c
arch/arm/mach-omap2/id.c
...
So,the same API set (omap_control_readl/omap_control_writel) was added to
omap-control-core.c.
If omap-control-core.c should only service users from driver/ directory, than I
agree - we can remove
omap_control_readl/omap_control_writel from omap-control-core.c.
But IIUC you are agree to switch arch/arm/mach-omap2/id.c from control.c to
omap-control-core.c. If arch/arm/mach-omap2/id.c is switched to control.c, then
I guess all arch/arm/mach-omap2/*.c should be switched to omap-control-core.c
as well. But this means that omap-control-core.c should provide
omap_control_readl/omap_control_writel API.
BR,
Konstantin Baydarov.
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH v2 00/11] OMAP System Control Module
Hello. This is a next version of series of patches(based on Eduardo Valentin's patch set) adding a basic support for system control module, on OMAP4+ context. It is a working in progress. Main changes since previous patch set version: - Bandgap and usb phy: drivers are now independent from control module driver, they use their own API functions. Dependency was removed from Kconfig. - omap-control-core: driver is basically the same as arch/arm/mach-omap2/control.c, but resources aren't hardcoded, they are specified in dts file. - omap-control-core: Control module is a built-in driver - added control module select to ARCH_HAS_CONTROL_MODULE and ARCH_OMAP4. Probably, no configuration option is required! - omap-control-core: Added early init call that ioremaps control module IOMEM window, this allows omap-control-core.c API to be called very early, for example from omap_type() - omap-control-core: Removed device pointer from omap-control-core API arguments, becuase there can be only one instance control module device. - Bandgap and usb phy: Added private spinlocks for bandgap and usb drivers. - Bandgap: Check the type of bandgap dynamically in bandgap driver probe function by reading omap core control module revision register CONTROL_GEN_CORE_REVISION. TODO list for bandgap driver: - Currently, bandgap and usb phy are children of control module, but, in fact, the drivers are independent, so probably they should be independent entries in dts as well. - Reserve omap-control-core IOMEM window. - Improve thermal zone definition for OMAP4 - Introduce the thermal zones for OMAP5 Overall series has been tested only with panda board OMAP4430, so bandgap and usb phy drivers weren't tested at all. --- Documentation/devicetree/bindings/mfd/omap_control.txt | 44 Documentation/devicetree/bindings/thermal/omap_bandgap.txt | 27 arch/arm/boot/dts/omap4.dtsi | 17 arch/arm/mach-omap2/Kconfig |1 arch/arm/mach-omap2/am35xx-emac.c|2 arch/arm/mach-omap2/board-3430sdp.c |2 arch/arm/mach-omap2/board-4430sdp.c |2 arch/arm/mach-omap2/board-am3517crane.c |2 arch/arm/mach-omap2/board-am3517evm.c|2 arch/arm/mach-omap2/board-apollon.c |2 arch/arm/mach-omap2/board-cm-t3517.c |2 arch/arm/mach-omap2/board-h4.c |2 arch/arm/mach-omap2/board-igep0020.c |2 arch/arm/mach-omap2/board-ldp.c |2 arch/arm/mach-omap2/board-omap3logic.c |2 arch/arm/mach-omap2/board-omap4panda.c |2 arch/arm/mach-omap2/clock2420_data.c |2 arch/arm/mach-omap2/clock2430_data.c |2 arch/arm/mach-omap2/clock3xxx_data.c |2 arch/arm/mach-omap2/clock44xx_data.c |2 arch/arm/mach-omap2/common.c |2 arch/arm/mach-omap2/control.c|2 arch/arm/mach-omap2/control.h| 416 -- arch/arm/mach-omap2/cpuidle34xx.c|2 arch/arm/mach-omap2/devices.c|2 arch/arm/mach-omap2/display.c|2 arch/arm/mach-omap2/hsmmc.c |2 arch/arm/mach-omap2/id.c |7 arch/arm/mach-omap2/include/mach/control.h | 567 +++ arch/arm/mach-omap2/include/mach/ctrl_module_core_44xx.h | 391 -- arch/arm/mach-omap2/include/mach/ctrl_module_pad_core_44xx.h | 1409 - arch/arm/mach-omap2/include/mach/ctrl_module_pad_wkup_44xx.h | 236 - arch/arm/mach-omap2/include/mach/ctrl_module_wkup_44xx.h | 92 arch/arm/mach-omap2/mcbsp.c |2 arch/arm/mach-omap2/mux.c|2 arch/arm/mach-omap2/omap_phy_internal.c |2 arch/arm/mach-omap2/opp3xxx_data.c |2 arch/arm/mach-omap2/opp4xxx_data.c |2 arch/arm/mach-omap2/pm24xx.c |2 arch/arm/mach-omap2/pm34xx.c |2 arch/arm/mach-omap2/prcm.c |2 arch/arm/mach-omap2/serial.c |2 arch/arm/mach-omap2/sleep34xx.S |2 arch/arm/mach-omap2/sr_device.c |2 arch/arm/mach-omap2/usb-fs.c |2 arch/arm/mach-omap2/voltage.c|2
[RFC PATCH v2 02/11] ARM: OMAP: expose control.h to mach area
This patch exposes the definitions under control.h to
drivers outside the machine code.
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
arch/arm/mach-omap2/am35xx-emac.c|2 +-
arch/arm/mach-omap2/board-3430sdp.c |2 +-
arch/arm/mach-omap2/board-4430sdp.c |2 +-
arch/arm/mach-omap2/board-am3517crane.c |2 +-
arch/arm/mach-omap2/board-am3517evm.c|2 +-
arch/arm/mach-omap2/board-apollon.c |2 +-
arch/arm/mach-omap2/board-cm-t3517.c |2 +-
arch/arm/mach-omap2/board-h4.c |2 +-
arch/arm/mach-omap2/board-igep0020.c |2 +-
arch/arm/mach-omap2/board-ldp.c |2 +-
arch/arm/mach-omap2/board-omap3logic.c |2 +-
arch/arm/mach-omap2/board-omap4panda.c |2 +-
arch/arm/mach-omap2/board-omap4pcm049.c |2 +-
arch/arm/mach-omap2/clock2420_data.c |2 +-
arch/arm/mach-omap2/clock2430_data.c |2 +-
arch/arm/mach-omap2/clock3xxx_data.c |2 +-
arch/arm/mach-omap2/clock44xx_data.c |2 +-
arch/arm/mach-omap2/common.c |2 +-
arch/arm/mach-omap2/control.c|2 +-
arch/arm/mach-omap2/cpuidle34xx.c|2 +-
arch/arm/mach-omap2/devices.c|2 +-
arch/arm/mach-omap2/display.c|2 +-
arch/arm/mach-omap2/hsmmc.c |2 +-
arch/arm/mach-omap2/id.c |2 +-
arch/arm/mach-omap2/{ = include/mach}/control.h |2 +-
arch/arm/mach-omap2/mcbsp.c |2 +-
arch/arm/mach-omap2/mux.c|2 +-
arch/arm/mach-omap2/omap_phy_internal.c |2 +-
arch/arm/mach-omap2/opp3xxx_data.c |2 +-
arch/arm/mach-omap2/opp4xxx_data.c |2 +-
arch/arm/mach-omap2/pm24xx.c |2 +-
arch/arm/mach-omap2/pm34xx.c |2 +-
arch/arm/mach-omap2/prcm.c |2 +-
arch/arm/mach-omap2/serial.c |2 +-
arch/arm/mach-omap2/sleep34xx.S |2 +-
arch/arm/mach-omap2/sr_device.c |2 +-
arch/arm/mach-omap2/usb-fs.c |2 +-
arch/arm/mach-omap2/voltage.c|2 +-
38 files changed, 38 insertions(+), 38 deletions(-)
rename arch/arm/mach-omap2/{ = include/mach}/control.h (99%)
diff --git a/arch/arm/mach-omap2/am35xx-emac.c
b/arch/arm/mach-omap2/am35xx-emac.c
index 447682c..c3da28a 100644
--- a/arch/arm/mach-omap2/am35xx-emac.c
+++ b/arch/arm/mach-omap2/am35xx-emac.c
@@ -21,7 +21,7 @@
#include plat/irqs.h
#include mach/am35xx.h
-#include control.h
+#include mach/control.h
static struct mdio_platform_data am35xx_emac_mdio_pdata;
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index 37abb0d..ad1132b 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -46,7 +46,7 @@
#include sdram-qimonda-hyb18m512160af-6.h
#include hsmmc.h
#include pm.h
-#include control.h
+#include mach/control.h
#include common-board-devices.h
#define CONFIG_DISABLE_HFCLK 1
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 94af6cd..8f7f76b 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -47,7 +47,7 @@
#include mux.h
#include hsmmc.h
-#include control.h
+#include mach/control.h
#include common-board-devices.h
#define ETH_KS8851_IRQ 34
diff --git a/arch/arm/mach-omap2/board-am3517crane.c
b/arch/arm/mach-omap2/board-am3517crane.c
index 3b8a53c..2ad514d 100644
--- a/arch/arm/mach-omap2/board-am3517crane.c
+++ b/arch/arm/mach-omap2/board-am3517crane.c
@@ -32,7 +32,7 @@
#include am35xx-emac.h
#include mux.h
-#include control.h
+#include mach/control.h
#define GPIO_USB_POWER 35
#define GPIO_USB_NRESET38
diff --git a/arch/arm/mach-omap2/board-am3517evm.c
b/arch/arm/mach-omap2/board-am3517evm.c
index 99790eb..bef6586 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -41,7 +41,7 @@
#include am35xx-emac.h
#include mux.h
-#include control.h
+#include mach/control.h
#include hsmmc.h
#define LCD_PANEL_PWR 176
diff --git a/arch/arm/mach-omap2/board-apollon.c
b/arch/arm/mach-omap2/board-apollon.c
index 768ece2..bd04fe2 100644
--- a/arch/arm/mach-omap2/board-apollon.c
+++ b/arch/arm/mach-omap2/board-apollon.c
@@ -44,7 +44,7 @@
#include video/omap-panel-generic-dpi.h
#include mux.h
-#include control.h
+#include mach/control.h
/* LED Switch macros */
#define LED0_GPIO1313
diff --git a/arch/arm/mach-omap2/board-cm-t3517.c
b/arch/arm/mach-omap2/board-cm-t3517.c
index 9e66e16..1d2b7a3 100644
---
[RFC PATCH v2 03/11] mfd: omap: control: core system control driver
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.
Changes since previous version:
- omap-control-core: driver is basically the same as
arch/arm/mach-omap2/control.c, but resources aren't hardcoded, they are
specified in dts file.
- omap-control-core: Control module is a built-in driver - added control module
select to ARCH_HAS_CONTROL_MODULE and ARCH_OMAP4.
Probably, no configuration option is required!
- omap-control-core: Added early init call that ioremaps control module IOMEM
window, this allows
omap-control-core.c API to be called very early, for example from omap_type()
- omap-control-core: Removed device pointer from omap-control-core API
arguments, becuase there can be only one instance control
module device.
Signed-off-by: Konstantin Baydarov kbaida...@dev.rtsoft.ru
Signed-off-by: J Keerthy j-keer...@ti.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
Documentation/devicetree/bindings/mfd/omap_control.txt | 44 +
arch/arm/mach-omap2/Kconfig|1
arch/arm/plat-omap/Kconfig |4
drivers/mfd/Kconfig|9 +
drivers/mfd/Makefile |1
drivers/mfd/omap-control-core.c| 141 +
include/linux/mfd/omap_control.h | 70
7 files changed, 270 insertions(+)
Index: linux-2.6/Documentation/devicetree/bindings/mfd/omap_control.txt
===
--- /dev/null
+++ linux-2.6/Documentation/devicetree/bindings/mfd/omap_control.txt
@@ -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@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;
+ };
+};
Index: linux-2.6/arch/arm/mach-omap2/Kconfig
===
--- linux-2.6.orig/arch/arm/mach-omap2/Kconfig
+++ linux-2.6/arch/arm/mach-omap2/Kconfig
@@ -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
Index: linux-2.6/arch/arm/plat-omap/Kconfig
===
--- linux-2.6.orig/arch/arm/plat-omap/Kconfig
+++ linux-2.6/arch/arm/plat-omap/Kconfig
@@ -5,6 +5,10 @@ menu TI OMAP Common Features
config ARCH_OMAP_OTG
bool
+config ARCH_HAS_CONTROL_MODULE
+ bool
+ select MFD_OMAP_CONTROL
+
choice
prompt OMAP System Type
default ARCH_OMAP2PLUS
Index: linux-2.6/drivers/mfd/Kconfig
===
--- linux-2.6.orig/drivers/mfd/Kconfig
+++ linux-2.6/drivers/mfd/Kconfig
@@ -822,6 +822,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
[RFC PATCH v2 05/11] mfd: omap: control: usb-phy: introduce the ctrl-module usb driver
Created a new platform driver for the platform device created by the
control module mfd core, wrt usb. This driver has API's to power on/off
the phy and the API's to write to musb mailbox.
Changes since previous version:
- Bandgap and usb phy: drivers are now independent from control module driver,
they use their own API functions.
Dependency was removed from Kconfig.
- Bandgap and usb phy: Added private spinlocks for bandgap and usb drivers.
(p.s. the mailbox for musb in omap4 is present in system control
module)
[kis...@ti.com: wrote the original API's related to USB functions]
Signed-off-by: Konstantin Baydarov kbaida...@dev.rtsoft.ru
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/usb/otg/Kconfig | 12 ++
drivers/usb/otg/Makefile |1
drivers/usb/otg/omap4-usb-phy.c | 167 ++
include/linux/usb/omap4_usb_phy.h | 53
4 files changed, 233 insertions(+)
Index: linux-2.6/drivers/usb/otg/Kconfig
===
--- linux-2.6.orig/drivers/usb/otg/Kconfig
+++ linux-2.6/drivers/usb/otg/Kconfig
@@ -78,6 +78,18 @@ config TWL6030_USB
are hooked to this driver through platform_data structure.
The definition of internal PHY APIs are in the mach-omap2 layer.
+config OMAP4_USB_PHY
+ tristate Texas Instruments OMAP4+ USB pin control driver
+ help
+ If you say yes here you get support for the Texas Instruments
+ OMAP4+ USB pin control driver. The register set is part of system
+ control module.
+
+ USB phy in OMAP configures control module register for powering on
+ the phy, configuring VBUSVALID, AVALID, IDDIG and SESSEND. For
+ performing the above mentioned configuration, API's are added in
+ by this children of the control module driver.
+
config NOP_USB_XCEIV
tristate NOP USB Transceiver Driver
select USB_OTG_UTILS
Index: linux-2.6/drivers/usb/otg/Makefile
===
--- linux-2.6.orig/drivers/usb/otg/Makefile
+++ linux-2.6/drivers/usb/otg/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_USB_GPIO_VBUS) += gpio_vbus
obj-$(CONFIG_ISP1301_OMAP) += isp1301_omap.o
obj-$(CONFIG_TWL4030_USB) += twl4030-usb.o
obj-$(CONFIG_TWL6030_USB) += twl6030-usb.o
+obj-$(CONFIG_OMAP4_USB_PHY)+= omap4-usb-phy.o
obj-$(CONFIG_NOP_USB_XCEIV)+= nop-usb-xceiv.o
obj-$(CONFIG_USB_ULPI) += ulpi.o
obj-$(CONFIG_USB_ULPI_VIEWPORT)+= ulpi_viewport.o
Index: linux-2.6/drivers/usb/otg/omap4-usb-phy.c
===
--- /dev/null
+++ linux-2.6/drivers/usb/otg/omap4-usb-phy.c
@@ -0,0 +1,167 @@
+/*
+ * OMAP4 system control module driver, USB control children
+ *
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * Contact:
+ *Kishon Vijay Abraham I kis...@ti.com
+ *Eduardo Valentin eduardo.valen...@ti.com
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+
+#include linux/module.h
+#include linux/init.h
+#include linux/gpio.h
+#include linux/delay.h
+#include linux/err.h
+#include linux/platform_device.h
+#include linux/usb/omap4_usb_phy.h
+
+void __iomem *omap_usb_phy_base;
+spinlock_t omap_usb_phy_lock;
+
+static int omap_usb_phy_readl(u32 reg, u32 *val)
+{
+ if (!omap_usb_phy_base)
+ return -EINVAL;
+
+ *val = __raw_readl(omap_usb_phy_base + reg);
+ return 0;
+}
+
+/*
+ * TODO: Get rid from omap_usb_phy_writel() return value -
+ * It's useless.
+ */
+static int omap_usb_phy_writel(u32 val, u32 reg)
+{
+ unsigned long flags;
+
+ if (!omap_usb_phy_base)
+ return -EINVAL;
+
+ spin_lock_irqsave(omap_usb_phy_lock, flags);
+ __raw_writel(val, omap_usb_phy_base + reg);
+ spin_unlock_irqrestore(omap_usb_phy_lock, flags);
+ return 0;
+}
+
+/**
+ * omap4_usb_phy_power - power on/off the phy using control module reg
+ * @dev: struct device *
+ * @on: 0 or 1, based on powering on or off the PHY
+ *
+ * omap_usb2 can call this API to power on or off the PHY.
+ */
+int omap4_usb_phy_power(struct device *dev, int on)
+{
+ u32 val;
+ int ret
[RFC PATCH v2 06/11] ARM: OMAP4+: Adding the temperature sensor register set bit fields
OMAP4460 specific temperature sensor register bit fields are added. Existing OMAP4 entries are renamed to OMAP4430. Signed-off-by: Keerthy j-keer...@ti.com Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com --- arch/arm/mach-omap2/include/mach/control.h | 116 1 files changed, 116 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/include/mach/control.h b/arch/arm/mach-omap2/include/mach/control.h index cf42764..171b504 100644 --- a/arch/arm/mach-omap2/include/mach/control.h +++ b/arch/arm/mach-omap2/include/mach/control.h @@ -230,6 +230,122 @@ /* OMAP44xx control McBSP padconf */ #define OMAP4_CTRL_MODULE_PAD_CORE_CONTROL_MCBSPLP 0x061c +/* TEMP_SENSOR OMAP4430 */ +#define OMAP4430_BGAP_TEMPSOFF_SHIFT 12 +#define OMAP4430_BGAP_TEMPSOFF_MASK(1 12) +#define OMAP4430_BGAP_TSHUT_SHIFT 11 +#define OMAP4430_BGAP_TSHUT_MASK (1 11) +#define OMAP4430_BGAP_TEMP_SENSOR_CONTCONV_SHIFT 10 +#define OMAP4430_BGAP_TEMP_SENSOR_CONTCONV_MASK(1 10) +#define OMAP4430_BGAP_TEMP_SENSOR_SOC_SHIFT9 +#define OMAP4430_BGAP_TEMP_SENSOR_SOC_MASK (1 9) +#define OMAP4430_BGAP_TEMP_SENSOR_EOCZ_SHIFT 8 +#define OMAP4430_BGAP_TEMP_SENSOR_EOCZ_MASK(1 8) +#define OMAP4430_BGAP_TEMP_SENSOR_DTEMP_SHIFT 0 +#define OMAP4430_BGAP_TEMP_SENSOR_DTEMP_MASK (0xff 0) + +/* TEMP_SENSOR OMAP4460 */ +#define OMAP4460_BGAP_TEMPSOFF_SHIFT 13 +#define OMAP4460_BGAP_TEMPSOFF_MASK(1 13) +#define OMAP4460_BGAP_TEMP_SENSOR_SOC_SHIFT11 +#define OMAP4460_BGAP_TEMP_SENSOR_SOC_MASK (1 11) +#define OMAP4460_BGAP_TEMP_SENSOR_EOCZ_SHIFT 10 +#define OMAP4460_BGAP_TEMP_SENSOR_EOCZ_MASK(1 10) +#define OMAP4460_BGAP_TEMP_SENSOR_DTEMP_SHIFT 0 +#define OMAP4460_BGAP_TEMP_SENSOR_DTEMP_MASK (0x3ff 0) + +/* BANDGAP_CTRL */ +#define OMAP4460_SINGLE_MODE_SHIFT 31 +#define OMAP4460_SINGLE_MODE_MASK (1 31) +#define OMAP4460_MASK_HOT_SHIFT1 +#define OMAP4460_MASK_HOT_MASK (1 1) +#define OMAP4460_MASK_COLD_SHIFT 0 +#define OMAP4460_MASK_COLD_MASK(1 0) + +/* BANDGAP_COUNTER */ +#define OMAP4460_COUNTER_SHIFT 0 +#define OMAP4460_COUNTER_MASK (0xff 0) + +/* BANDGAP_THRESHOLD */ +#define OMAP4460_T_HOT_SHIFT 16 +#define OMAP4460_T_HOT_MASK(0x3ff 16) +#define OMAP4460_T_COLD_SHIFT 0 +#define OMAP4460_T_COLD_MASK (0x3ff 0) + +/* TSHUT_THRESHOLD */ +#define OMAP4460_TSHUT_HOT_SHIFT 16 +#define OMAP4460_TSHUT_HOT_MASK(0x3ff 16) +#define OMAP4460_TSHUT_COLD_SHIFT 0 +#define OMAP4460_TSHUT_COLD_MASK (0x3ff 0) + +/* BANDGAP_STATUS */ +#define OMAP4460_CLEAN_STOP_SHIFT 3 +#define OMAP4460_CLEAN_STOP_MASK (1 3) +#define OMAP4460_BGAP_ALERT_SHIFT 2 +#define OMAP4460_BGAP_ALERT_MASK (1 2) +#define OMAP4460_HOT_FLAG_SHIFT1 +#define OMAP4460_HOT_FLAG_MASK (1 1) +#define OMAP4460_COLD_FLAG_SHIFT 0 +#define OMAP4460_COLD_FLAG_MASK(1 0) + +/* TEMP_SENSOR OMAP5430 */ +#define OMAP5430_BGAP_TEMP_SENSOR_SOC_SHIFT12 +#define OMAP5430_BGAP_TEMP_SENSOR_SOC_MASK (1 12) +#define OMAP5430_BGAP_TEMPSOFF_SHIFT 11 +#define OMAP5430_BGAP_TEMPSOFF_MASK(1 11) +#define OMAP5430_BGAP_TEMP_SENSOR_EOCZ_SHIFT 10 +#define OMAP5430_BGAP_TEMP_SENSOR_EOCZ_MASK(1 10) +#define OMAP5430_BGAP_TEMP_SENSOR_DTEMP_SHIFT 0 +#define OMAP5430_BGAP_TEMP_SENSOR_DTEMP_MASK (0x3ff 0) + +/* BANDGAP_CTRL */ +#define OMAP5430_MASK_HOT_CORE_SHIFT 5 +#define OMAP5430_MASK_HOT_CORE_MASK(1 5) +#define OMAP5430_MASK_COLD_CORE_SHIFT 4 +#define OMAP5430_MASK_COLD_CORE_MASK (1 4) +#define OMAP5430_MASK_HOT_MM_SHIFT 3 +#define OMAP5430_MASK_HOT_MM_MASK (1 3) +#define OMAP5430_MASK_COLD_MM_SHIFT2 +#define OMAP5430_MASK_COLD_MM_MASK (1 2) +#define OMAP5430_MASK_HOT_MPU_SHIFT1 +#define OMAP5430_MASK_HOT_MPU_MASK (1 1) +#define OMAP5430_MASK_COLD_MPU_SHIFT 0 +#define OMAP5430_MASK_COLD_MPU_MASK(1 0) + +/* BANDGAP_COUNTER */ +#define
[RFC PATCH v2 04/11] OMAP2+: use control module mfd driver in omap_type
OMAP system control module can be probed early, then
omap_type is safe to use its APIs.
TODO: add support for other omap versions
Signed-off-by: Konstantin Baydarov kbaida...@dev.rtsoft.ru
---
arch/arm/mach-omap2/id.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
Index: linux-2.6/arch/arm/mach-omap2/id.c
===
--- linux-2.6.orig/arch/arm/mach-omap2/id.c
+++ linux-2.6/arch/arm/mach-omap2/id.c
@@ -18,6 +18,7 @@
#include linux/kernel.h
#include linux/init.h
#include linux/io.h
+#include linux/mfd/omap_control.h
#include asm/cputype.h
@@ -38,6 +39,8 @@ unsigned int omap_rev(void)
}
EXPORT_SYMBOL(omap_rev);
+u32 omap_control_readl(u16 offset);
+
int omap_type(void)
{
u32 val = 0;
@@ -49,7 +52,7 @@ int omap_type(void)
} else if (cpu_is_omap34xx()) {
val = omap_ctrl_readl(OMAP343X_CONTROL_STATUS);
} else if (cpu_is_omap44xx()) {
- val = omap_ctrl_readl(OMAP4_CTRL_MODULE_CORE_STATUS);
+ val = omap_control_readl(OMAP4_CTRL_MODULE_CORE_STATUS);
} else {
pr_err(Cannot detect omap type!\n);
goto out;
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH v2 07/11] ARM: OMAP4+: thermal: introduce bandgap temperature sensor
In the System Control Module, OMAP supplies a voltage reference
and a temperature sensor feature that are gathered in the band
gap voltage and temperature sensor (VBGAPTS) module. The band
gap provides current and voltage reference for its internal
circuits and other analog IP blocks. The analog-to-digital
converter (ADC) produces an output value that is proportional
to the silicon temperature.
This patch provides a platform driver which expose this feature.
It is moduled as a MFD child of the System Control Module core
MFD driver.
This driver provides only APIs to access the device properties,
like temperature, thresholds and update rate.
Changes since previous version:
- Bandgap and usb phy: drivers are now independent from control module driver,
they use their own API functions.
- Bandgap and usb phy: Added private spinlocks for bandgap and usb drivers.
- Bandgap: Check the type of bandgap dynamically in bandgap driver probe
function by reading
omap core control module revision register CONTROL_GEN_CORE_REVISION.
Signed-off-by: Konstantin Baydarov kbaida...@dev.rtsoft.ru
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
Signed-off-by: Keerthy j-keer...@ti.com
---
Documentation/devicetree/bindings/thermal/omap_bandgap.txt | 27
drivers/thermal/Kconfig| 12
drivers/thermal/Makefile |4
drivers/thermal/omap-bandgap.c | 1654 +
drivers/thermal/omap-bandgap.h | 64
5 files changed, 1760 insertions(+), 1 deletion(-)
Index: linux-2.6/Documentation/devicetree/bindings/thermal/omap_bandgap.txt
===
--- /dev/null
+++ linux-2.6/Documentation/devicetree/bindings/thermal/omap_bandgap.txt
@@ -0,0 +1,27 @@
+* Texas Instrument OMAP SCM bandgap bindings
+
+In the System Control Module, OMAP supplies a voltage reference
+and a temperature sensor feature that are gathered in the band
+gap voltage and temperature sensor (VBGAPTS) module. The band
+gap provides current and voltage reference for its internal
+circuits and other analog IP blocks. The analog-to-digital
+converter (ADC) produces an output value that is proportional
+to the silicon temperature.
+
+Required properties:
+- compatible : Should be:
+ - ti,omap4460-control-bandgap : for OMAP4460 bandgap
+ - ti,omap5430-control-bandgap : for OMAP5430 bandgap
+- interrupts : this entry should indicate which interrupt line
+the talert signal is routed to;
+Specific:
+- ti,tshut-gpio : this entry should be used to inform which GPIO
+line the tshut signal is routed to;
+
+Example:
+
+bandgap {
+ compatible = ti,omap4460-control-bandgap;
+ interrupts = 0 126 4; /* talert */
+ ti,tshut-gpio = 86;
+};
Index: linux-2.6/drivers/thermal/Kconfig
===
--- linux-2.6.orig/drivers/thermal/Kconfig
+++ linux-2.6/drivers/thermal/Kconfig
@@ -26,3 +26,15 @@ config SPEAR_THERMAL
help
Enable this to plug the SPEAr thermal sensor driver into the Linux
thermal framework
+
+config OMAP_BANDGAP
+ tristate Texas Instruments OMAP4+ temperature sensor driver
+ depends on THERMAL
+ help
+ If you say yes here you get support for the Texas Instruments
+ OMAP4460+ on die bandgap temperature sensor support. The register
+ set is part of system control module.
+
+ This includes alert interrupts generation and also the TSHUT
+ support.
+
Index: linux-2.6/drivers/thermal/Makefile
===
--- linux-2.6.orig/drivers/thermal/Makefile
+++ linux-2.6/drivers/thermal/Makefile
@@ -3,4 +3,6 @@
#
obj-$(CONFIG_THERMAL) += thermal_sys.o
-obj-$(CONFIG_SPEAR_THERMAL)+= spear_thermal.o
\ No newline at end of file
+obj-$(CONFIG_SPEAR_THERMAL)+= spear_thermal.o
+obj-$(CONFIG_OMAP_BANDGAP) += omap-thermal.o
+omap-thermal-y := omap-bandgap.o
Index: linux-2.6/drivers/thermal/omap-bandgap.c
===
--- /dev/null
+++ linux-2.6/drivers/thermal/omap-bandgap.c
@@ -0,0 +1,1654 @@
+/*
+ * OMAP4 Bandgap temperature sensor driver
+ *
+ * Copyright (C) 2011-2012 Texas Instruments Incorporated - http://www.ti.com/
+ * Author: J Keerthy j-keer...@ti.com
+ * Author: Moiz Sonasath m-sonas...@ti.com
+ * Couple of fixes, DT and MFD adaptation:
+ * Eduardo Valentin eduardo.valen...@ti.com
+ *
+ * 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
[RFC PATCH v2 08/11] omap4: thermal: add basic CPU thermal zone
This patch exposes OMAP4 thermal sensor as a thermal zone
named cpu. Only thermal creation is done here.
TODO:
- Add cooling bindings
- Add extrapolation rules
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
drivers/thermal/Kconfig | 12 ++
drivers/thermal/Makefile|1
drivers/thermal/omap-bandgap.c |1
drivers/thermal/omap-bandgap.h | 12 ++
drivers/thermal/omap4-thermal.c | 72
5 files changed, 98 insertions(+)
Index: linux-2.6/drivers/thermal/Kconfig
===
--- linux-2.6.orig/drivers/thermal/Kconfig
+++ linux-2.6/drivers/thermal/Kconfig
@@ -38,3 +38,15 @@ config OMAP_BANDGAP
This includes alert interrupts generation and also the TSHUT
support.
+config OMAP4_THERMAL
+ bool Texas Instruments OMAP4 thermal support
+ depends on OMAP_BANDGAP
+ depends on ARCH_OMAP4
+ help
+ If you say yes here you get thermal support for the Texas Instruments
+ OMAP4 SoC family. The current chip supported are:
+ - OMAP4460
+
+ This includes alert interrupts generation and also the TSHUT
+ support.
+
Index: linux-2.6/drivers/thermal/Makefile
===
--- linux-2.6.orig/drivers/thermal/Makefile
+++ linux-2.6/drivers/thermal/Makefile
@@ -6,3 +6,4 @@ obj-$(CONFIG_THERMAL) += thermal_sys.o
obj-$(CONFIG_SPEAR_THERMAL)+= spear_thermal.o
obj-$(CONFIG_OMAP_BANDGAP) += omap-thermal.o
omap-thermal-y := omap-bandgap.o
+omap-thermal-$(CONFIG_OMAP4_THERMAL) += omap4-thermal.o
Index: linux-2.6/drivers/thermal/omap-bandgap.c
===
--- linux-2.6.orig/drivers/thermal/omap-bandgap.c
+++ linux-2.6/drivers/thermal/omap-bandgap.c
@@ -1213,6 +1213,7 @@ static const struct omap_bandgap_data om
.fclock_name = bandgap_ts_fclk,
.div_ck_name = div_ts_ck,
.conv_table = omap4460_adc_to_temp,
+ .expose_sensor = omap4_thermal_expose_sensor,
.irq = 126,
.sensors = {
{
Index: linux-2.6/drivers/thermal/omap-bandgap.h
===
--- linux-2.6.orig/drivers/thermal/omap-bandgap.h
+++ linux-2.6/drivers/thermal/omap-bandgap.h
@@ -61,4 +61,16 @@ int omap_bandgap_write_update_interval(s
int omap_bandgap_read_temperature(struct omap_bandgap *bg_ptr, int id,
int *temperature);
+#ifdef CONFIG_OMAP4_THERMAL
+int omap4_thermal_expose_sensor(struct omap_bandgap *bg_ptr, int id,
+ char *domain);
+#else
+static inline int omap4_thermal_expose_sensor(struct omap_bandgap *bg_ptr,
+ int id, char *domain)
+{
+ return 0;
+}
+
+#endif
+
#endif
Index: linux-2.6/drivers/thermal/omap4-thermal.c
===
--- /dev/null
+++ linux-2.6/drivers/thermal/omap4-thermal.c
@@ -0,0 +1,72 @@
+/*
+ * SPEAr thermal driver.
+ *
+ * Copyright (C) 2011-2012 Texas Instruments Inc.
+ * Contact:
+ * Eduardo Valentin eduardo.valen...@ti.com
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * 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/device.h
+#include linux/err.h
+#include linux/io.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/thermal.h
+
+#include omap-bandgap.h
+
+struct omap4_thermal_data {
+ struct thermal_zone_device *omap4_thermal;
+ struct omap_bandgap *bg_ptr;
+ int sensor_id;
+};
+
+static inline int omap4_thermal_get_temp(struct thermal_zone_device *thermal,
+unsigned long *temp)
+{
+ struct omap4_thermal_data *data = thermal-devdata;
+ int ret, tmp;
+
+ ret = omap_bandgap_read_temperature(data-bg_ptr, data-sensor_id,
+ tmp);
+ if (!ret)
+ *temp = tmp;
+
+ return ret;
+}
+
+static struct thermal_zone_device_ops omap4_thermal_ops = {
+ .get_temp = omap4_thermal_get_temp,
+};
+
+int omap4_thermal_expose_sensor(struct omap_bandgap *bg_ptr, int id,
+ char *domain)
+{
+ struct omap4_thermal_data *data;
+
+ data = devm_kzalloc(bg_ptr-dev, sizeof(*data), GFP_KERNEL);
+ if (!data) {
+ dev_err(bg_ptr-dev, kzalloc fail\n);
+ return -ENOMEM;
+ }
+
[RFC PATCH v2 09/11] ARM: DT: Add support to system control module for OMAP4
This patch adds device tree entries on OMAP4 based boards
for System Control Module (SCM).
TODO:
The IOMEM windows of ctrl_module_core, bandgap, usbphy overlap, so
probably only specific registers should be specified in dts for
bandgap and usb phy entries.
Signed-off-by: Konstantin Baydarov kbaida...@dev.rtsoft.ru
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
arch/arm/boot/dts/omap4.dtsi | 17 +
1 file changed, 17 insertions(+)
Index: linux-2.6/arch/arm/boot/dts/omap4.dtsi
===
--- linux-2.6.orig/arch/arm/boot/dts/omap4.dtsi
+++ linux-2.6/arch/arm/boot/dts/omap4.dtsi
@@ -272,5 +272,22 @@
ti,hwmods = mmc5;
ti,needs-special-reset;
};
+
+ ctrl_module_core: ctrl_module_core@4a002000 {
+ compatible = ti,omap4-control;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+ ti,hwmods = ctrl_module_core;
+ reg = 0x4a002000 0x1000;
+ bandgap@4a002000 {
+ compatible = ti,omap4-bandgap;
+ reg = 0x4a002000 0x1000;
+ };
+ usb@4a002000 {
+ compatible = ti,omap4-usb-phy;
+ reg = 0x4a002000 0x1000;
+ };
+ };
};
};
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 03/11] arm: omap: device: create a device for system control module
Hi.
On 05/29/2012 01:44 PM, Eduardo Valentin wrote:
On Fri, May 25, 2012 at 02:30:44PM +0200, Cousson Benoit wrote:
On 5/25/2012 10:25 AM, Eduardo Valentin wrote:
From: Kishon Vijay Abraham Ikis...@ti.com
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.
Regards,
Benoit
Signed-off-by: Kishon Vijay Abraham Ikis...@ti.com
Signed-off-by: Eduardo Valentineduardo.valen...@ti.com
---
arch/arm/mach-omap2/devices.c | 26 ++
1 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 152c266..9332673 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -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;
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 05/11] mfd: omap: control: core system control driver
Hi, Tony. On 06/01/2012 03:29 PM, Tony Lindgren wrote: * Cousson, Benoit b-cous...@ti.com [120529 06:29]: On 5/28/2012 1:35 PM, Eduardo Valentin wrote: 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 :-) 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? 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. 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). BR, Konstantin Baydarov. Regards, Tony ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 05/11] mfd: omap: control: core system control driver
On 06/01/2012 06:13 PM, Tony Lindgren wrote: * Konstantin Baydarov kbaida...@dev.rtsoft.ru [120601 06:44]: On 06/01/2012 03:29 PM, Tony Lindgren wrote: 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). Hmm I guess you mean L4_44XX_VIRT + offset. Otherwise drivers would not work at all.. Or else I don't follow you. Right. I mean when 0x4A00 2000(scm base) is remapped in scm driver, ioremap() always returns same virtual address (0xfc002000). Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 11/11] ARM: DT: Add support to system control module for OMAP4
Hi. On 05/30/2012 01:26 PM, Cousson, Benoit wrote: On 5/30/2012 11:05 AM, Konstantin Baydarov wrote: On 05/30/2012 12:38 PM, Cousson, Benoit wrote: On 5/29/2012 11:49 AM, Konstantin Baydarov wrote: Hi, Eduardo. On 05/25/2012 12:26 PM, Eduardo Valentin wrote: This patch add device tree entries on OMAP4 based boards for System Control Module (SCM). ... I believe that CPU-specific bandgap definition should be moved to bard specific dts. Mmm, why, since it is CPU specific and not board specific. I has to be in the SoC file. Speaking about omap4430 - omap4430 bandgap differs from omap4460, so if omap4430 bandgap support will be added to omap-bandgap driver the version of bandgap should specified in dts file. omap4.dtsi is a common for omap4 boards, that is why I'm suggesting to move bandgap description to probably board specific file. OK, I got your point, but in that case we could potentially define a omap4460.dtsi file. Another solution is to determine bandgap type in driver probe function, but in that case ti,omap4460-bandgap in omap4.dtsi should be replaced to ti,omap4-bandgap. Yes, this is the best solution, but that assume that we can identify the control module version from the HW, which is not necessarily true :-( The IP_REVISION (offset = 0) value are unfortunately not documented, so we should read it to check if they are different from omap4430 and 4460. The bitfield layout in that register is: IP_REV_MAJOR: 8..10 IP_REV_CUSTOM: 6..7 IP_REV_MINOR: 0..5 The value of CONTROL_GEN_CORE_REVISION register on my panda board(4430) is: CONTROL_GEN_CORE_REVISION: 0x4900 CONTROL_GEN_CORE_HWINFO: 0x0 Eduardo, could you check CONTROL_GEN_CORE_REVISION on your 4460 board. BR, Konstantin Baydarov. Regards, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 11/11] ARM: DT: Add support to system control module for OMAP4
Hi.
On 05/31/2012 04:52 PM, Cousson, Benoit wrote:
On 5/31/2012 2:49 PM, Eduardo Valentin wrote:
Hello,
On Thu, May 31, 2012 at 04:06:00PM +0400, Konstantin Baydarov wrote:
Hi.
On 05/30/2012 01:26 PM, Cousson, Benoit wrote:
On 5/30/2012 11:05 AM, Konstantin Baydarov wrote:
On 05/30/2012 12:38 PM, Cousson, Benoit wrote:
On 5/29/2012 11:49 AM, Konstantin Baydarov wrote:
Hi, Eduardo.
On 05/25/2012 12:26 PM, Eduardo Valentin wrote:
This patch add device tree entries on OMAP4 based boards for
System Control Module (SCM).
...
I believe that CPU-specific bandgap definition should be moved to
bard specific dts.
Mmm, why, since it is CPU specific and not board specific. I has to
be in the SoC file.
Speaking about omap4430 - omap4430 bandgap differs from omap4460, so
if omap4430 bandgap support will be added to omap-bandgap driver the
version of bandgap should specified in dts file. omap4.dtsi is a
common for omap4 boards, that is why I'm suggesting to move bandgap
description to probably board specific file.
OK, I got your point, but in that case we could potentially define a
omap4460.dtsi file.
Another solution is to
determine bandgap type in driver probe function, but in that case
ti,omap4460-bandgap in omap4.dtsi should be replaced to
ti,omap4-bandgap.
Yes, this is the best solution, but that assume that we can identify the
control module version from the HW, which is not necessarily true :-(
The IP_REVISION (offset = 0) value are unfortunately not documented, so we
should read it to check if they are different from omap4430 and 4460.
The bitfield layout in that register is:
IP_REV_MAJOR: 8..10
IP_REV_CUSTOM: 6..7
IP_REV_MINOR: 0..5
The value of CONTROL_GEN_CORE_REVISION register on my panda board(4430) is:
CONTROL_GEN_CORE_REVISION: 0x4900
CONTROL_GEN_CORE_HWINFO: 0x0
Eduardo, could you check CONTROL_GEN_CORE_REVISION on your 4460 board.
4460:
[root@(none) ~]# omapconf read 0x4A002000
4A00
[root@(none) ~]# omapconf read 0x4A002004
4470:
[root@(none) ~]# omapconf read 0x4A002000
4B00
[root@(none) ~]# omapconf read 0x4A002004
Nice! We do have a cool progression 1 - 2 - 3 for each revision.
Well at least for the SCM.
Benoit
This patch allows checking of bandgap type dynamically in bandgap driver
probe function by reading omap core control module revision register
CONTROL_GEN_CORE_REVISION. It lets bandgap module to be defined in common
omap4.dtsi, because all cpu specific attributes(irq and tshut number)
were moved to driver.
Patch wasn't tested because I have panda 4430 board.
Signed-off-by: Konstantin Baydarov kbaida...@dev.rtsoft.ru
Index: omap-thermal/arch/arm/boot/dts/omap4.dtsi
===
--- omap-thermal.orig/arch/arm/boot/dts/omap4.dtsi
+++ omap-thermal/arch/arm/boot/dts/omap4.dtsi
@@ -277,9 +277,7 @@
compatible = ti,omap4-control;
ti,hwmods = ctrl_module_core;
bandgap {
- compatible = ti,omap4460-bandgap;
- interrupts = 0 126 4; /* talert */
- ti,tshut-gpio = 86; /* tshut */
+ compatible = ti,omap4-bandgap;
};
usb {
compatible = ti,omap4-usb-phy;
Index: omap-thermal/drivers/thermal/omap-bandgap.c
===
--- omap-thermal.orig/drivers/thermal/omap-bandgap.c
+++ omap-thermal/drivers/thermal/omap-bandgap.c
@@ -219,12 +219,14 @@ struct omap_temp_sensor {
struct omap_bandgap_data {
boolhas_talert;
boolhas_tshut;
+ int tshut_gpio;
const int *conv_table;
char*fclock_name;
char*div_ck_name;
int sensor_count;
int (*report_temperature)(struct omap_bandgap *bg_ptr, int id);
int (*expose_sensor)(struct omap_bandgap *bg_ptr, int id, char *domain);
+ int irq;
/* this needs to be at the end */
struct omap_temp_sensor sensors[];
@@ -1189,10 +1191,12 @@ static int omap_bandgap_talert_init(stru
static const struct omap_bandgap_data omap4460_data = {
.has_talert = true,
.has_tshut = true,
+ .tshut_gpio = 86,
.fclock_name = bandgap_ts_fclk,
.div_ck_name = div_ts_ck,
.conv_table = omap4460_adc_to_temp,
.expose_sensor = omap4_thermal_expose_sensor,
+ .irq = 126,
.sensors = {
{
.registers = omap4460_mpu_temp_sensor_registers,
@@ -1206,9 +1210,11 @@ static const struct omap_bandgap_data om
static const struct
Re: [RFC PATCH 11/11] ARM: DT: Add support to system control module for OMAP4
On 05/30/2012 12:38 PM, Cousson, Benoit wrote:
On 5/29/2012 11:49 AM, Konstantin Baydarov wrote:
Hi, Eduardo.
On 05/25/2012 12:26 PM, Eduardo Valentin wrote:
This patch add device tree entries on OMAP4 based boards
for System Control Module (SCM).
Signed-off-by: Eduardo Valentineduardo.valen...@ti.com
---
arch/arm/boot/dts/omap4.dtsi | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 359c497..d2cb392 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -272,5 +272,18 @@
ti,hwmods = mmc5;
ti,needs-special-reset;
};
+
+ctrl_module_core: ctrl_module_core@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 */
+};
I believe that CPU-specific bandgap definition should be moved to bard
specific dts.
Mmm, why, since it is CPU specific and not board specific. I has to be in the
SoC file.
Speaking about omap4430 - omap4430 bandgap differs from omap4460, so if
omap4430 bandgap support will be added to omap-bandgap driver the version of
bandgap should specified in dts file. omap4.dtsi is a common for omap4 boards,
that is why I'm suggesting to move bandgap description to probably board
specific file.
Another solution is to determine bandgap type in driver probe function, but in
that case ti,omap4460-bandgap in omap4.dtsi should be replaced to
ti,omap4-bandgap.
BR,
Konstantin Baydarov.
Regards,
Benoit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 11/11] ARM: DT: Add support to system control module for OMAP4
Hi. On 05/30/2012 01:26 PM, Cousson, Benoit wrote: On 5/30/2012 11:05 AM, Konstantin Baydarov wrote: On 05/30/2012 12:38 PM, Cousson, Benoit wrote: On 5/29/2012 11:49 AM, Konstantin Baydarov wrote: Hi, Eduardo. On 05/25/2012 12:26 PM, Eduardo Valentin wrote: This patch add device tree entries on OMAP4 based boards for System Control Module (SCM). ... I believe that CPU-specific bandgap definition should be moved to bard specific dts. Mmm, why, since it is CPU specific and not board specific. I has to be in the SoC file. Speaking about omap4430 - omap4430 bandgap differs from omap4460, so if omap4430 bandgap support will be added to omap-bandgap driver the version of bandgap should specified in dts file. omap4.dtsi is a common for omap4 boards, that is why I'm suggesting to move bandgap description to probably board specific file. OK, I got your point, but in that case we could potentially define a omap4460.dtsi file. Another solution is to determine bandgap type in driver probe function, but in that case ti,omap4460-bandgap in omap4.dtsi should be replaced to ti,omap4-bandgap. Yes, this is the best solution, but that assume that we can identify the control module version from the HW, which is not necessarily true :-( The IP_REVISION (offset = 0) value are unfortunately not documented, so we should read it to check if they are different from omap4430 and 4460. The bitfield layout in that register is: IP_REV_MAJOR: 8..10 IP_REV_CUSTOM: 6..7 IP_REV_MINOR: 0..5 Probably, cpu_is_omap443x() and cpu_is_omap446x() can be used in bandgap driver probe function. Actually many drivers use cpu_is_omap*(): drivers/mfd/omap-usb-host.c drivers/mfd/twl-core.c BR, Konstantin Baydarov. Regards, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 11/11] ARM: DT: Add support to system control module for OMAP4
Hi, Eduardo.
On 05/25/2012 12:26 PM, Eduardo Valentin wrote:
This patch add device tree entries on OMAP4 based boards
for System Control Module (SCM).
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
arch/arm/boot/dts/omap4.dtsi | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 359c497..d2cb392 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -272,5 +272,18 @@
ti,hwmods = mmc5;
ti,needs-special-reset;
};
+
+ ctrl_module_core: ctrl_module_core@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 */
+ };
I believe that CPU-specific bandgap definition should be moved to bard specific
dts.
BR,
Konstantin Baydarov.
+ usb {
+ compatible = ti,omap4-usb-phy;
+ };
+ };
};
};
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 03/11] arm: omap: device: create a device for system control module
Hi.
On 05/25/2012 12:25 PM, Eduardo Valentin wrote:
From: Kishon Vijay Abraham I kis...@ti.com
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 kis...@ti.com
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
---
arch/arm/mach-omap2/devices.c | 26 ++
1 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 152c266..9332673 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -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);
I noticed that control module omap device is created and configured according
to following idle flags:
static struct omap_hwmod_class_sysconfig omap44xx_ctrl_module_sysc = {
.rev_offs= 0x,
.sysc_offs= 0x0010,
.sysc_flags= SYSC_HAS_SIDLEMODE,
.idlemodes= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
SIDLE_SMART_WKUP),
.sysc_fields= omap_hwmod_sysc_type2,
};
IIUC, .idlemodes= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
SIDLE_SMART_WKUP) means that CONTROL_GEN_CORE idlemode will be set to
0x2,0x3: Clock is automatically gated when there is no access to the Control
Module through L4-interconnect. See CONTROL_GEN_CORE_SYSCONFIG register.
So IIUC theoretically CONTROL_GEN_CORE module clock can be automatically gated.
Recalling that CONTROL_GEN_CORE module has an THERMAL_ALERT interrupt that is
used by the bandgap driver, I'm wondering if the THERMAL_ALERT interrupt will
be fired when CONTROL_GEN_CORE module clock is gated?
Probably bandgap driver should set CONTROL_GEN_CORE idle mode to SIDLE_NO, to
prevent loosing THERMAL_ALERT interrupt?
BR,
Konstantin Baydarov.
+ 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;
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 00/11] OMAP System Control Module
Hi. On 05/25/2012 12:25 PM, Eduardo Valentin wrote: Hello Paul and Tony, This is a series of patches adding a basic support for system control module, on OMAP4+ context. It is a working in progress, but I wanted to share already to get your feedback. I've modeled the driver as an MFD. You will see in this series: . A rework of the system control module header (patch from Santosh, picked from the list) . Device creation for control module core . Early device creation for control module core . The MFD core driver for system control module . The MFD child for usb-phy pin control . The MFD child for bandgap sensor . Very early exposure of OMAP4 thermal zone . All added drivers are only supporting DT probing . The series is based on linux-omap master, as it has the hwmod entries for SCM. The overall idea of this series is to put in place the infrastructure. It is not touching nor removing the existing APIs under mach-omap2/control.c for now. But the target is to have these APIs moved to the MFD core driver. For early access, like ID checking, I have written the platform driver as an early platform driver and you will see also early device addition and probing under device.c for this case. This is of course a proposal. I see that there are people that thing this is a bit of an overkill. Konstantin (CCd) was proposing a simpler solution by having APIs with early_* prefixes, and solve the IO address mapping with a DT entry, for instance. But feel free to propose better ways. In my latest version I got rid from early API set, check out patch for V3 patch set. I'll attach patch for current version later. BR, Konstantin Baydarov. This code has been ripped off from the Android 3.1 branch. I have rewritten a couple of things, but the major driver functions and API's entries are kept. So, based on this series, I see as a TODO list, for system control core driver: - Start to move all the existing APIs under mach-omap2/control.c to the mfd core. - Rewrite the users of the existing APIs, mentioned on previous item Once we decide the API and agree on how to deal with early calls. - Add remaining children (from top of my head, the CAM is one of them, but I also think we should prob have one for HWOBS for instance) - Test on boards that use the existing APIs. TODO list for bandgap driver: - Improve thermal zone definition for OMAP4 - Introduce the thermal zones for OMAP5 Amit, due to hwmod dep, I didn't include any cooling binding in this series, based on the generic CPU cooling device. Overall series has been tested only with panda board OMAP4460. Your comments are welcome. All best, Eduardo Valentin (9): ARM: OMAP: expose control.h to mach area OMAP: Add early device for system control module mfd: omap: control: core system control driver OMAP2+: use control module mfd driver in omap_type mfd: omap: control: usb-phy: introduce the ctrl-module usb driver ARM: OMAP4+: Adding the temperature sensor register set bit fields ARM: OMAP4+: thermal: introduce bandgap temperature sensor omap4: thermal: add basic CPU thermal zone ARM: DT: Add support to system control module for OMAP4 Kishon Vijay Abraham I (1): arm: omap: device: create a device for system control module Santosh Shilimkar (1): ARM: OMAP4: Remove un-used control module headers and defines. .../devicetree/bindings/mfd/omap_control.txt | 44 + .../devicetree/bindings/thermal/omap_bandgap.txt | 27 + arch/arm/boot/dts/omap4.dtsi | 13 + arch/arm/mach-omap2/Kconfig|1 + arch/arm/mach-omap2/am35xx-emac.c |2 +- arch/arm/mach-omap2/board-3430sdp.c|2 +- arch/arm/mach-omap2/board-4430sdp.c|2 +- arch/arm/mach-omap2/board-am3517crane.c|2 +- arch/arm/mach-omap2/board-am3517evm.c |2 +- arch/arm/mach-omap2/board-apollon.c|2 +- arch/arm/mach-omap2/board-cm-t3517.c |2 +- arch/arm/mach-omap2/board-h4.c |2 +- arch/arm/mach-omap2/board-igep0020.c |2 +- arch/arm/mach-omap2/board-ldp.c|2 +- arch/arm/mach-omap2/board-omap3logic.c |2 +- arch/arm/mach-omap2/board-omap4panda.c |2 +- arch/arm/mach-omap2/board-omap4pcm049.c|2 +- arch/arm/mach-omap2/clock2420_data.c |2 +- arch/arm/mach-omap2/clock2430_data.c |2 +- arch/arm/mach-omap2/clock3xxx_data.c |2 +- arch/arm/mach-omap2/clock44xx_data.c |2 +- arch/arm/mach-omap2/common.c |2 +- arch/arm/mach-omap2/control.c |2 +- arch/arm/mach-omap2/cpuidle34xx.c |2 +- arch/arm/mach-omap2/devices.c | 57 +- arch/arm/mach-omap2
Re: [RFC PATCH 04/11] OMAP: Add early device for system control module
Hi , Eduardo.
On 05/25/2012 12:25 PM, Eduardo Valentin wrote:
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 eduardo.valen...@ti.com
---
arch/arm/mach-omap2/devices.c | 29 +
1 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 9332673..58cc5c3 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -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),
+};
+
+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.
+
+ return 0;
+}
+early_initcall(plat_early_device_setup);
+
static int omap_init_control(void)
{
struct omap_hwmod *oh;
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 04/11] OMAP: Add early device for system control module
Hi.
On 05/25/2012 12:25 PM, Eduardo Valentin wrote:
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 eduardo.valen...@ti.com
---
arch/arm/mach-omap2/devices.c | 29 +
1 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 9332673..58cc5c3 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -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,
+ },
+};
Init control module platform device resources from device tree instead of
hard-coding them.
Prevent control module driver registering itself second time after it has
already been registered by early_platform_driver_register_all().
Signed-off-by: Konstantin Baydarov kbaida...@dev.rtsoft.ru
Index: omap-thermal/arch/arm/boot/dts/omap4.dtsi
===
--- omap-thermal.orig/arch/arm/boot/dts/omap4.dtsi
+++ omap-thermal/arch/arm/boot/dts/omap4.dtsi
@@ -275,7 +275,10 @@
ctrl_module_core: ctrl_module_core@4a002000 {
compatible = ti,omap4-control;
+ #address-cells = 1;
+ #size-cells = 1;
ti,hwmods = ctrl_module_core;
+ reg = 0x4a002000 0x1000;
bandgap {
compatible = ti,omap4460-bandgap;
interrupts = 0 126 4; /* talert */
Index: omap-thermal/arch/arm/mach-omap2/devices.c
===
--- omap-thermal.orig/arch/arm/mach-omap2/devices.c
+++ omap-thermal/arch/arm/mach-omap2/devices.c
@@ -18,6 +18,7 @@
#include linux/slab.h
#include linux/of.h
#include linux/platform_data/omap4-keypad.h
+#include linux/of_address.h
#include mach/hardware.h
#include mach/irqs.h
@@ -40,6 +41,7 @@
#define L3_MODULES_MAX_LEN 12
#define L3_MODULES 3
+#if 0
static struct resource control_resources[] = {
[0] = {
.start = 0x4a002000,
@@ -47,6 +49,17 @@ static struct resource control_resources
.flags = IORESOURCE_MEM,
},
};
+#endif
+
+static const struct of_device_id of_omap_control_match[] = {
+ { .compatible = ti,omap3-control, },
+ { .compatible = ti,omap4-control, },
+ { .compatible = ti,omap5-control, },
+ { },
+};
+
+static struct resource control_resources[1];
+
static struct platform_device control_device = {
.name = omap-control-core,
.id = 0,
@@ -58,8 +71,56 @@ static struct platform_device *early_dev
control_device,
};
+int __init omap_control_of_init(struct device_node *node,
+struct device_node *parent)
+{
+ struct resource res;
+
+ if (WARN_ON(!node))
+ return -ENODEV;
+
+ if (of_address_to_resource(node, 0, res)) {
+ WARN(1, unable to get intc registers\n);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+void __init of_omap_control_init(const struct of_device_id *matches)
+{
+ struct device_node *np;
+ struct property *pp = 0;
+ unsigned long phys_base = 0;
+ size_t mapsize = 0;
+
+ for_each_matching_node(np, matches) {
+
+ pp = of_find_property(np, reg, NULL);
+ if(pp) {
+// printk(\t\t of_omap_control_init(): ioremap %x
\n, be32_to_cpup(pp-value));
+// printk(\t\t of_omap_control_init(): 2 value %x
\n, be32_to_cpup( (char*)pp-value + 4 ) );
+// printk(\t\t of_omap_control_init(): length %x
\n, pp-length);
+
+ phys_base = (resource_size_t)be32_to_cpup(pp-value);
+ mapsize = (size_t)be32_to_cpup(
(void*)((char*)pp-value + 4) );
+#if 0
+ omap_control_data.base = ioremap(phys_base, mapsize);
+ if(omap_control_data.base)
+ omap_control_module = omap_control_data;
+#endif
+ control_resources[0].start = phys_base;
+ control_resources[0].end = phys_base + mapsize;
+ control_resources[0].flags = IORESOURCE_MEM;
+ printk(\t\t of_omap_control_init(): start addr %x
\n, control_resources[0].start);
+ printk(\t\t of_omap_control_init(): end addr %x
\n, control_resources[0].end);
+ }
+ }
+}
+
static int __init
Re: [RFC PATCH 00/11] OMAP System Control Module
Hi.
On 05/25/2012 03:11 PM, Valentin, Eduardo wrote:
Konstantin,
On Fri, May 25, 2012 at 1:50 PM, Konstantin Baydarov
kbaida...@dev.rtsoft.ru wrote:
Hi.
On 05/25/2012 12:25 PM, Eduardo Valentin wrote:
Hello Paul and Tony,
This is a series of patches adding a basic support for system control
module,
on OMAP4+ context. It is a working in progress, but I wanted to share
already
to get your feedback.
I've modeled the driver as an MFD. You will see in this series:
. A rework of the system control module header (patch from Santosh, picked
from the list)
. Device creation for control module core
. Early device creation for control module core
. The MFD core driver for system control module
. The MFD child for usb-phy pin control
. The MFD child for bandgap sensor
. Very early exposure of OMAP4 thermal zone
. All added drivers are only supporting DT probing
. The series is based on linux-omap master, as it has the hwmod entries for
SCM.
The overall idea of this series is to put in place the infrastructure. It is
not touching nor removing the existing APIs under mach-omap2/control.c for
now.
But the target is to have these APIs moved to the MFD core driver.
For early access, like ID checking, I have written the platform driver
as an early platform driver and you will see also early device addition
and probing under device.c for this case. This is of course a proposal.
I see that there are people that thing this is a bit of an overkill.
Konstantin (CCd) was proposing a simpler solution by having
APIs with early_* prefixes, and solve the IO address mapping with
a DT entry, for instance. But feel free to propose better ways.
In my latest version I got rid from early API set, check out patch for V3
patch set.
I'll attach patch for current version later.
Please send it across so we can compare your approach with the one
present in this series.
Moved control module window remap to early_initcall to allow usage of
control module API very early during kernel initialization.
Switched omap_type() to omap-control-core.c API.
Signed-off-by: Konstantin Baydarov kbaida...@dev.rtsoft.ru
Index: omap-thermal/drivers/mfd/omap-control-core.c
===
--- omap-thermal.orig/drivers/mfd/omap-control-core.c
+++ omap-thermal/drivers/mfd/omap-control-core.c
@@ -31,12 +31,16 @@
#include linux/mfd/core.h
#include linux/mfd/omap_control.h
+#include linux/of.h
+#include linux/of_address.h
+
static struct omap_control *omap_control_module;
+struct omap_control omap_control_data;
/**
* omap_control_readl: Read a single omap control module register.
*
- * @dev: device to read from.
+ * @dev: unused - there is only one controle module
* @reg: register to read.
* @val: output with register value.
*
@@ -44,7 +48,7 @@ static struct omap_control *omap_control
*/
int omap_control_readl(struct device *dev, u32 reg, u32 *val)
{
- struct omap_control *omap_control = dev_get_drvdata(dev);
+ struct omap_control *omap_control = omap_control_module;
if (!omap_control)
return -EINVAL;
@@ -58,7 +62,7 @@ EXPORT_SYMBOL_GPL(omap_control_readl);
/**
* omap_control_writel: Write a single omap control module register.
*
- * @dev: device to read from.
+ * @dev: unused - there is only one controle module
* @val: value to write.
* @reg: register to write to.
*
@@ -66,7 +70,7 @@ EXPORT_SYMBOL_GPL(omap_control_readl);
*/
int omap_control_writel(struct device *dev, u32 val, u32 reg)
{
- struct omap_control *omap_control = dev_get_drvdata(dev);
+ struct omap_control *omap_control = omap_control_module;
unsigned long flags;
if (!omap_control)
@@ -130,40 +134,26 @@ static const struct of_device_id of_omap
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) {
+ if (!omap_control_module) {
dev_err(dev, ioremap failed\n);
return -EADDRNOTAVAIL;
}
+ omap_control = omap_control_module;
- 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
Re: [RFC PATCH 09/11] ARM: OMAP4+: thermal: introduce bandgap temperature sensor
Hi.
On 05/25/2012 12:25 PM, Eduardo Valentin wrote:
In the System Control Module, OMAP supplies a voltage reference
and a temperature sensor feature that are gathered in the band
gap voltage and temperature sensor (VBGAPTS) module. The band
gap provides current and voltage reference for its internal
circuits and other analog IP blocks. The analog-to-digital
converter (ADC) produces an output value that is proportional
to the silicon temperature.
This patch provides a platform driver which expose this feature.
It is moduled as a MFD child of the System Control Module core
MFD driver.
This driver provides only APIs to access the device properties,
like temperature, thresholds and update rate.
Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com
Signed-off-by: Keerthy j-keer...@ti.com
---
.../devicetree/bindings/thermal/omap_bandgap.txt | 27 +
drivers/thermal/Kconfig| 13 +
drivers/thermal/Makefile |4 +-
drivers/thermal/omap-bandgap.c | 1601
drivers/thermal/omap-bandgap.h | 63 +
5 files changed, 1707 insertions(+), 1 deletions(-)
create mode 100644 Documentation/devicetree/bindings/thermal/omap_bandgap.txt
create mode 100644 drivers/thermal/omap-bandgap.c
create mode 100644 drivers/thermal/omap-bandgap.h
Add private spin lock in omap-bandgap driver to prevent blocking of
control module general registers access.
I wasn't able to test - I have panda 4430 board.
TODO:
Prevent over-usage of spin_lock/spin_unlock for sequential calls of
bg_writel().
Signed-off-by: Konstantin Baydarov kbaida...@dev.rtsoft.ru
Index: omap-thermal/drivers/mfd/omap-control-core.c
===
--- omap-thermal.orig/drivers/mfd/omap-control-core.c
+++ omap-thermal/drivers/mfd/omap-control-core.c
@@ -67,6 +67,19 @@ EXPORT_SYMBOL_GPL(omap_control_readl);
int omap_control_writel(struct device *dev, u32 val, u32 reg)
{
struct omap_control *omap_control = dev_get_drvdata(dev);
+
+ if (!omap_control)
+ return -EINVAL;
+
+ writel(val, omap_control-base + reg);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(omap_control_writel);
+
+int omap_control_lock_writel(struct device *dev, u32 val, u32 reg)
+{
+ struct omap_control *omap_control = dev_get_drvdata(dev);
unsigned long flags;
if (!omap_control)
@@ -78,7 +91,7 @@ int omap_control_writel(struct device *d
return 0;
}
-EXPORT_SYMBOL_GPL(omap_control_writel);
+EXPORT_SYMBOL_GPL(omap_control_lock_writel);
/**
* omap_control_get: returns the control module device pinter
@@ -136,6 +149,9 @@ static int __devinit omap_control_probe(
struct device_node *np = dev-of_node;
struct omap_control *omap_control;
+ printk(\n\t\t omap_control_probe(): enter );
+ dump_stack();
+
omap_control = devm_kzalloc(dev, sizeof(*omap_control), GFP_KERNEL);
if (!omap_control) {
dev_err(dev, not enough memory for omap_control\n);
Index: omap-thermal/drivers/thermal/omap-bandgap.c
===
--- omap-thermal.orig/drivers/thermal/omap-bandgap.c
+++ omap-thermal/drivers/thermal/omap-bandgap.c
@@ -154,6 +154,7 @@ struct temp_sensor_registers {
u32 status_cold_mask;
u32 bgap_efuse;
+ spinlock_t bg_reg_lock;
};
/**
@@ -579,6 +580,17 @@ omap5430_adc_to_temp[OMAP5430_ADC_END_VA
124600, 124900, 125000, 125000, 125000, 125000,
};
+static int bg_writel(struct device *dev, u32 val, u32 reg, spinlock_t *lock)
+{
+ unsigned long flags;
+ int ret;
+
+ spin_lock_irqsave(lock, flags);
+ ret = omap_control_writel(dev, val, reg);
+ spin_unlock_irqrestore(lock, flags);
+ return ret;
+}
+
static irqreturn_t talert_irq_handler(int irq, void *data)
{
struct omap_bandgap *bg_ptr = data;
@@ -615,7 +627,7 @@ static irqreturn_t talert_irq_handler(in
ctrl |= tsr-mask_hot_mask;
}
- r |= omap_control_writel(cdev, ctrl, tsr-bgap_mask_ctrl);
+ r |= bg_writel(cdev, ctrl, tsr-bgap_mask_ctrl,
tsr-bg_reg_lock);
if (r) {
dev_err(bg_ptr-dev, failed to ack talert
interrupt\n);
@@ -705,7 +717,7 @@ static int temp_sensor_unmask_interrupts
reg_val |= tsr-mask_cold_mask;
else
reg_val = ~tsr-mask_cold_mask;
- err |= omap_control_writel(cdev, reg_val, tsr-bgap_mask_ctrl);
+ err |= bg_writel(cdev, reg_val, tsr-bgap_mask_ctrl, tsr-bg_reg_lock);
if (err) {
dev_err(bg_ptr-dev, failed to unmask interrupts\n);
@@ -751,14 +763,14 @@ int temp_sensor_configure_thot(struct om
/* write the new t_cold value */
reg_val = thresh_val (~tsr
