[PATCH v3 0/2] rtc: omap: update AM335x rtc ip revision
The syntax of compatible property in DT is to mention the Most specific match to most generic match. Since AM335x is the platform with latest IP revision, add it 1st in the device id table. This way, we can add new matching compatible as 1st and maintain old compatible string for backwards compatibility. ex: compatible = ti,am3352-rtc, ti,da830-rtc; Also, update am335x .dtsi file (am33xx.dtsi) as above. Note: This is a part of previously submitted patch-set [1]. Out of 4 patches, 3 was accepted and 1 got an acceptable NAK. Hence resubmitting only the rejected + updated changes. Changes in V3: - As per Mark Rutland's suggestion [2], maintain old compatible string and add the new matching string as the 1st compatible. Changes in V2: - Coding style corrections (remove extra space, use lower case for hex numbers - use prefix ARM: for commit subject keeping with arch/arm convention) - use [AM/am]3352 instead of [AM/am]335x to keep the all usages in sync. - Use index defined for struct members so they remain in sync - Add new compatible to existing one so that when driver supports enhanced features of hardware, they are available to the user else the basic functionality still works [2] https://lkml.org/lkml/2013/7/3/74 [1] https://lkml.org/lkml/2013/8/1/442 Hebbar Gururaja (1): ARM: dts: AM33XX: update rtc node compatibility Hebbar, Gururaja (1): rtc: omap: update of_device_id to reflect latest ip revisions arch/arm/boot/dts/am33xx.dtsi |2 +- drivers/rtc/rtc-omap.c|6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) -- 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 1/2] rtc: omap: update of_device_id to reflect latest ip revisions
The syntax of compatible property in DT is to mention the Most specific
match to most generic match.
Since AM335x is the platform with latest IP revision, add it 1st in
the device id table.
This way, we can add new matching compatible as 1st and maintain old
compatible string for backwards compatibility.
ex:
compatible = ti,am3352-rtc, ti,da830-rtc;
Signed-off-by: Hebbar, Gururaja gururaja.heb...@ti.com
CC: mark.rutl...@arm.com
---
Changes in v3:
- new patch
:100644 100644 dc62cc3... 2f0968c... M drivers/rtc/rtc-omap.c
drivers/rtc/rtc-omap.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index dc62cc3..2f0968c 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -330,12 +330,12 @@ static struct platform_device_id omap_rtc_devtype[] = {
MODULE_DEVICE_TABLE(platform, omap_rtc_devtype);
static const struct of_device_id omap_rtc_of_match[] = {
- { .compatible = ti,da830-rtc,
- .data = omap_rtc_devtype[OMAP_RTC_DATA_DA830_IDX],
- },
{ .compatible = ti,am3352-rtc,
.data = omap_rtc_devtype[OMAP_RTC_DATA_AM335X_IDX],
},
+ { .compatible = ti,da830-rtc,
+ .data = omap_rtc_devtype[OMAP_RTC_DATA_DA830_IDX],
+ },
{},
};
MODULE_DEVICE_TABLE(of, omap_rtc_of_match);
--
1.7.0.4
--
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/2] ARM: dts: AM33XX: update rtc node compatibility
From: Hebbar Gururaja gururaja.heb...@ti.com
Since AM33xx RTC IP has RTC_IRQWAKEEN to support Alarm Wake-up, update
the rtc compatible property to enable handling of this feature inside
rtc-omap driver.
Signed-off-by: Hebbar Gururaja gururaja.heb...@ti.com
CC: mark.rutl...@arm.com
---
Changes in V3:
- Instead of replacing the old matching string, add new
matching compatible as 1st and maintain old compatible string
for backwards compatibility
Changes in V2:
- Add new compatible to existing one so that when driver
supports enhanced features of hardware, they are available
to the user else the basic functionality still works
:100644 100644 0aaf8ce... daeafa0... M arch/arm/boot/dts/am33xx.dtsi
arch/arm/boot/dts/am33xx.dtsi |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 0aaf8ce..daeafa0 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -317,7 +317,7 @@
};
rtc@44e3e000 {
- compatible = ti,da830-rtc;
+ compatible = ti,am3352-rtc, ti,da830-rtc;
reg = 0x44e3e000 0x1000;
interrupts = 75
76;
--
1.7.0.4
--
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 1/2] rtc: omap: update of_device_id to reflect latest ip revisions
The syntax of compatible property in DT is to mention the Most specific
match to most generic match.
Since AM335x is the platform with latest IP revision, add it 1st in
the device id table.
This way, we can add new matching compatible as 1st and maintain old
compatible string for backwards compatibility.
ex:
compatible = ti,am3352-rtc, ti,da830-rtc;
Signed-off-by: Hebbar, Gururaja gururaja.heb...@ti.com
CC: mark.rutl...@arm.com
---
Changes in V4:
- Rebased on latest linux-next (as on 160813).
- Correct a type AM335X -- AM3352
Changes in v3:
- new patch
:100644 100644 dc62cc3... 2f0968c... M drivers/rtc/rtc-omap.c
drivers/rtc/rtc-omap.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index dc62cc3..2f0968c 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -330,12 +330,12 @@ static struct platform_device_id omap_rtc_devtype[] = {
MODULE_DEVICE_TABLE(platform, omap_rtc_devtype);
static const struct of_device_id omap_rtc_of_match[] = {
- { .compatible = ti,da830-rtc,
- .data = omap_rtc_devtype[OMAP_RTC_DATA_DA830_IDX],
- },
{ .compatible = ti,am3352-rtc,
.data = omap_rtc_devtype[OMAP_RTC_DATA_AM3352_IDX],
},
+ { .compatible = ti,da830-rtc,
+ .data = omap_rtc_devtype[OMAP_RTC_DATA_DA830_IDX],
+ },
{},
};
MODULE_DEVICE_TABLE(of, omap_rtc_of_match);
--
1.7.0.4
--
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/2] rtc: omap: update AM335x rtc ip revision
The syntax of compatible property in DT is to mention the Most specific match to most generic match. Since AM335x is the platform with latest IP revision, add it 1st in the device id table. This way, we can add new matching compatible as 1st and maintain old compatible string for backwards compatibility. ex: compatible = ti,am3352-rtc, ti,da830-rtc; Also, update am335x .dtsi file (am33xx.dtsi) as above. Note: This is a part of previously submitted patch-set [1]. Out of 4 patches, 3 was accepted and 1 got an acceptable NAK. Hence resubmitting only the rejected + updated changes. Changes in V4: - Rebased on latest linux-next (as on 160813). - Correct a type AM335X -- AM3352 Changes in V3: - As per Mark Rutland's suggestion [2], maintain old compatible string and add the new matching string as the 1st compatible. Changes in V2: - Coding style corrections (remove extra space, use lower case for hex numbers - use prefix ARM: for commit subject keeping with arch/arm convention) - use [AM/am]3352 instead of [AM/am]335x to keep the all usages in sync. - Use index defined for struct members so they remain in sync - Add new compatible to existing one so that when driver supports enhanced features of hardware, they are available to the user else the basic functionality still works [2] https://lkml.org/lkml/2013/7/3/74 [1] https://lkml.org/lkml/2013/8/1/442 Hebbar Gururaja (1): ARM: dts: AM33XX: update rtc node compatibility Hebbar, Gururaja (1): rtc: omap: update of_device_id to reflect latest ip revisions arch/arm/boot/dts/am33xx.dtsi |2 +- drivers/rtc/rtc-omap.c|6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) -- 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 2/2] ARM: dts: AM33XX: update rtc node compatibility
From: Hebbar Gururaja gururaja.heb...@ti.com
Since AM33xx RTC IP has RTC_IRQWAKEEN to support Alarm Wake-up, update
the rtc compatible property to enable handling of this feature inside
rtc-omap driver.
Signed-off-by: Hebbar Gururaja gururaja.heb...@ti.com
CC: mark.rutl...@arm.com
---
Changes in V4:
- No change.
Changes in V3:
- Instead of replacing the old matching string, add new
matching compatible as 1st and maintain old compatible string
for backwards compatibility
Changes in V2:
- Add new compatible to existing one so that when driver
supports enhanced features of hardware, they are available
to the user else the basic functionality still works
:100644 100644 0aaf8ce... daeafa0... M arch/arm/boot/dts/am33xx.dtsi
arch/arm/boot/dts/am33xx.dtsi |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 0aaf8ce..daeafa0 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -317,7 +317,7 @@
};
rtc@44e3e000 {
- compatible = ti,da830-rtc;
+ compatible = ti,am3352-rtc, ti,da830-rtc;
reg = 0x44e3e000 0x1000;
interrupts = 75
76;
--
1.7.0.4
--
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 V2 3/4] rtc: omap: add rtc wakeup support to alarm events
On some platforms (like AM33xx), a special register (RTC_IRQWAKEEN)
is available to enable Alarm Wakeup feature. This register needs to be
properly handled for the rtcwake to work properly.
Platforms using such IP should set ti,am3352-rtc in rtc device dt
compatibility node.
Signed-off-by: Hebbar Gururaja gururaja.heb...@ti.com
Acked-by: Kevin Hilman khil...@linaro.org
Acked-by: Sekhar Nori nsek...@ti.com
Cc: Grant Likely grant.lik...@linaro.org
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Rob Landley r...@landley.net
Cc: Alessandro Zummo a.zu...@towertech.it
Cc: rtc-li...@googlegroups.com
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-...@vger.kernel.org
---
Changes in V2:
- Coding style corrections (use lower case for hex numbers)
- use [AM/am]3352 instead of [AM/am]335x to keep the all
usages in sync.
- Use index defined for struct members so they remain in sync
:100644 100644 b47aa41... 5a0f02d... M
Documentation/devicetree/bindings/rtc/rtc-omap.txt
:100644 100644 761919d... c2e18fe... M drivers/rtc/rtc-omap.c
Documentation/devicetree/bindings/rtc/rtc-omap.txt |6 +-
drivers/rtc/rtc-omap.c | 60 +---
2 files changed, 57 insertions(+), 9 deletions(-)
diff --git a/Documentation/devicetree/bindings/rtc/rtc-omap.txt
b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
index b47aa41..5a0f02d 100644
--- a/Documentation/devicetree/bindings/rtc/rtc-omap.txt
+++ b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
@@ -1,7 +1,11 @@
TI Real Time Clock
Required properties:
-- compatible: ti,da830-rtc
+- compatible:
+ - ti,da830-rtc - for RTC IP used similar to that on DA8xx SoC family.
+ - ti,am3352-rtc - for RTC IP used similar to that on AM335x SoC
family.
+ This RTC IP has special WAKE-EN Register to enable
+ Wakeup generation for event Alarm.
- reg: Address range of rtc register set
- interrupts: rtc timer, alarm interrupts in order
- interrupt-parent: phandle for the interrupt controller
diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index 761919d..c2e18fe 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -72,6 +72,8 @@
#define OMAP_RTC_KICK0_REG 0x6c
#define OMAP_RTC_KICK1_REG 0x70
+#define OMAP_RTC_IRQWAKEEN 0x7c
+
/* OMAP_RTC_CTRL_REG bit fields: */
#define OMAP_RTC_CTRL_SPLIT(17)
#define OMAP_RTC_CTRL_DISABLE (16)
@@ -96,12 +98,21 @@
#define OMAP_RTC_INTERRUPTS_IT_ALARM(13)
#define OMAP_RTC_INTERRUPTS_IT_TIMER(12)
+/* OMAP_RTC_IRQWAKEEN bit fields: */
+#define OMAP_RTC_IRQWAKEEN_ALARM_WAKEEN(11)
+
/* OMAP_RTC_KICKER values */
#defineKICK0_VALUE 0x83e70b13
#defineKICK1_VALUE 0x95a4f1e0
#defineOMAP_RTC_HAS_KICKER 0x1
+/*
+ * Few RTC IP revisions has special WAKE-EN Register to enable Wakeup
+ * generation for event Alarm.
+ */
+#defineOMAP_RTC_HAS_IRQWAKEEN 0x2
+
static void __iomem*rtc_base;
#define rtc_read(addr) readb(rtc_base + (addr))
@@ -301,12 +312,18 @@ static struct rtc_class_ops omap_rtc_ops = {
static int omap_rtc_alarm;
static int omap_rtc_timer;
-#defineOMAP_RTC_DATA_DA830_IDX 1
+#defineOMAP_RTC_DATA_AM3352_IDX1
+#defineOMAP_RTC_DATA_DA830_IDX 2
static struct platform_device_id omap_rtc_devtype[] = {
{
.name = DRIVER_NAME,
- }, {
+ },
+ [OMAP_RTC_DATA_AM3352_IDX] = {
+ .name = am3352-rtc,
+ .driver_data = OMAP_RTC_HAS_KICKER | OMAP_RTC_HAS_IRQWAKEEN,
+ },
+ [OMAP_RTC_DATA_DA830_IDX] = {
.name = da830-rtc,
.driver_data = OMAP_RTC_HAS_KICKER,
},
@@ -318,6 +335,9 @@ static const struct of_device_id omap_rtc_of_match[] = {
{ .compatible = ti,da830-rtc,
.data = omap_rtc_devtype[OMAP_RTC_DATA_DA830_IDX],
},
+ { .compatible = ti,am3352-rtc,
+ .data = omap_rtc_devtype[OMAP_RTC_DATA_AM3352_IDX],
+ },
{},
};
MODULE_DEVICE_TABLE(of, omap_rtc_of_match);
@@ -466,16 +486,28 @@ static u8 irqstat;
static int omap_rtc_suspend(struct device *dev)
{
+ u8 irqwake_stat;
+ struct platform_device *pdev = to_platform_device(dev);
+ const struct platform_device_id *id_entry =
+ platform_get_device_id(pdev);
+
irqstat = rtc_read(OMAP_RTC_INTERRUPTS_REG);
/* FIXME the RTC alarm is not currently acting as a wakeup event
-* source, and in fact this enable() call is just saving a flag
-* that's never used...
+* source on some platforms, and in fact this enable() call is just
+* saving a flag that's never used
[Patch V2 1/4] rtc: omap: restore back (hard-code) wakeup support
rtc-omap driver modules is used both by OMAP1/2, Davinci SoC platforms. However, rtc wake support on OMAP1 is broken. Hence the device_init_wakeup() was removed from rtc-omap driver and moved to platform board files that supported it (DA850/OMAP-L138). [1] However, recently [2] it was suggested that driver should always do a device_init_wakeup(dev, true). Platforms that don't want/need wakeup support can disable it from userspace via: echo disabled /sys/devices/.../power/wakeup Also, with the new DT boot-up, board file doesn't exist and hence there is no way to have device wakeup support rtc. The fix for above issues, is to hard code device_init_wakeup() inside driver and let platforms that don't need this, handle it through the sysfs power entry. [1] https://patchwork.kernel.org/patch/136731/ [2] http://www.mail-archive.com/davinci-linux-open-source@linux. davincidsp.com/msg26077.html Signed-off-by: Hebbar Gururaja gururaja.heb...@ti.com Acked-by: Kevin Hilman khil...@linaro.org Cc: Alessandro Zummo a.zu...@towertech.it Cc: rtc-li...@googlegroups.com --- :100644 100644 b0ba3fc... 761919d... M drivers/rtc/rtc-omap.c drivers/rtc/rtc-omap.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c index b0ba3fc..761919d 100644 --- a/drivers/rtc/rtc-omap.c +++ b/drivers/rtc/rtc-omap.c @@ -423,6 +423,8 @@ static int __init omap_rtc_probe(struct platform_device *pdev) *is write-only, and always reads as zero...) */ + device_init_wakeup(pdev-dev, true); + if (new_ctrl (u8) OMAP_RTC_CTRL_SPLIT) pr_info(%s: split power mode\n, pdev-name); -- 1.7.9.5 -- 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 V2 2/4] ARM: Davinci: da8xx/omap-l1: Remove hard coding of rtc device wakeup
Since now rtc-omap driver itself calls deice_init_wakeup(dev, true),
duplicate call from the rtc device registration can be removed.
This is basically a partial revert of the prev commit
commit 75c99bb0006ee065b4e2995078d779418b0fab54
Author: Sekhar Nori nsek...@ti.com
davinci: da8xx/omap-l1: mark RTC as a wakeup source
Signed-off-by: Hebbar Gururaja gururaja.heb...@ti.com
Acked-by: Kevin Hilman khil...@linaro.org
Acked-by: Sekhar Nori nsek...@ti.com
Cc: Russell King li...@arm.linux.org.uk
---
Changes in V2:
- Coding style corrections (remove extra space)
- use prefix ARM: for commit subject keeping with arch/arm convention
:100644 100644 bf57252... 9140b1c... M arch/arm/mach-davinci/devices-da8xx.c
arch/arm/mach-davinci/devices-da8xx.c |9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/arch/arm/mach-davinci/devices-da8xx.c
b/arch/arm/mach-davinci/devices-da8xx.c
index bf57252..9140b1c 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -827,14 +827,7 @@ static struct platform_device da8xx_rtc_device = {
int da8xx_register_rtc(void)
{
- int ret;
-
- ret = platform_device_register(da8xx_rtc_device);
- if (!ret)
- /* Atleast on DA850, RTC is a wakeup source */
- device_init_wakeup(da8xx_rtc_device.dev, true);
-
- return ret;
+ return platform_device_register(da8xx_rtc_device);
}
static void __iomem *da8xx_ddr2_ctlr_base;
--
1.7.9.5
--
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 V2 4/4] ARM: dts: AM33XX: update rtc node compatibility
Since AM33xx RTC IP has RTC_IRQWAKEEN to support Alarm Wake-up.
Update the rtc compatible property to ti,am3352-rtc to enable handling
of this feature inside rtc-omap driver.
Signed-off-by: Hebbar Gururaja gururaja.heb...@ti.com
---
:100644 100644 77aa1b0... dde180a... M arch/arm/boot/dts/am33xx.dtsi
arch/arm/boot/dts/am33xx.dtsi |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 77aa1b0..dde180a 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -297,7 +297,7 @@
};
rtc@44e3e000 {
- compatible = ti,da830-rtc;
+ compatible = ti,am3352-rtc;
reg = 0x44e3e000 0x1000;
interrupts = 75
76;
--
1.7.9.5
--
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 V2 0/4] rtc: omap: handle rtc wakeup support in driver
rtc-omap driver modules is used both by OMAP1/2, Davinci SoC platforms. However, rtc wake support on OMAP1 is broken. Hence the device_init_wakeup() was removed from rtc-omap driver and moved to platform board files that supported it (DA850/OMAP-L138). [1] However, recently [2] it was suggested that driver should always do a device_init_wakeup(dev, true). Platforms that don't want/need wakeup support can disable it from userspace via: echo disabled /sys/devices/.../power/wakeup Also, with the new DT boot-up, board file doesn't exist and hence there is no way to have device wakeup support rtc. The fix for above issues, is to hard code device_init_wakeup() inside driver and let platforms that don't need this, handle it through the sysfs power entry. Also, update Davinci AM335x files to above changes. [1] https://patchwork.kernel.org/patch/136731/ [2] http://www.mail-archive.com/davinci-linux-open-source@linux. davincidsp.com/msg26077.html Changes in V2: - Coding style corrections (remove extra space, use lower case for hex numbers - use prefix ARM: for commit subject keeping with arch/arm convention) - use [AM/am]3352 instead of [AM/am]335x to keep the all usages in sync. - Use index defined for struct members so they remain in sync - Add new compatible to existing one so that when driver supports enhanced features of hardware, they are available to the user else the basic functionality still works Hebbar Gururaja (4): rtc: omap: restore back (hard-code) wakeup support ARM: Davinci: da8xx/omap-l1: Remove hard coding of rtc device wakeup rtc: omap: add rtc wakeup support to alarm events ARM: dts: AM33XX: update rtc node compatibility Documentation/devicetree/bindings/rtc/rtc-omap.txt |6 +- arch/arm/boot/dts/am33xx.dtsi |2 +- arch/arm/mach-davinci/devices-da8xx.c |9 +-- drivers/rtc/rtc-omap.c | 62 +--- 4 files changed, 61 insertions(+), 18 deletions(-) -- 1.7.9.5 -- 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 3/4] rtc: omap: add rtc wakeup support to alarm events
On Tue, Jul 02, 2013 at 11:32:34, Nori, Sekhar wrote:
On 6/28/2013 3:05 PM, Hebbar Gururaja wrote:
On some platforms (like AM33xx), a special register (RTC_IRQWAKEEN)
is available to enable Alarm Wakeup feature. This register needs to be
properly handled for the rtcwake to work properly.
Platforms using such IP should set ti,am3352-rtc in rtc device dt
compatibility node.
Signed-off-by: Hebbar Gururaja gururaja.heb...@ti.com
Cc: Grant Likely grant.lik...@linaro.org
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Rob Landley r...@landley.net
Cc: Sekhar Nori nsek...@ti.com
Cc: Kevin Hilman khil...@linaro.org
Cc: Alessandro Zummo a.zu...@towertech.it
Cc: rtc-li...@googlegroups.com
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-...@vger.kernel.org
---
[...]
-#defineOMAP_RTC_DATA_DA830_IDX 1
+#defineOMAP_RTC_DATA_DA830_IDX 1
+#defineOMAP_RTC_DATA_AM335X_IDX2
static struct platform_device_id omap_rtc_devtype[] = {
{
@@ -309,6 +321,9 @@ static struct platform_device_id omap_rtc_devtype[] = {
}, {
.name = da830-rtc,
.driver_data = OMAP_RTC_HAS_KICKER,
+ }, {
+ .name = am335x-rtc,
may be use am3352-rtc here just to keep the platform device name and of
compatible in sync.
Correct. I will update the same in v2.
+ .driver_data = OMAP_RTC_HAS_KICKER | OMAP_RTC_HAS_IRQWAKEEN,
},
{},
It is better to use the index defined above in the static initialization
so they remain in sync.
Sorry. I didn’t get this.
...
[OMAP_RTC_DATA_DA830_IDX] = {
.name = da830-rtc,
.driver_data = OMAP_RTC_HAS_KICKER,
},
...
};
@@ -318,6 +333,9 @@ static const struct of_device_id omap_rtc_of_match[] = {
{ .compatible = ti,da830-rtc,
.data = omap_rtc_devtype[OMAP_RTC_DATA_DA830_IDX],
},
+ { .compatible = ti,am3352-rtc,
+ .data = omap_rtc_devtype[OMAP_RTC_DATA_AM335X_IDX],
+ },
{},
};
MODULE_DEVICE_TABLE(of, omap_rtc_of_match);
Apart from these minor issues, the patch looks good to me.
Acked-by: Sekhar Nori nsek...@ti.com
Thanks,
Sekhar
Regards,
Gururaja
RE: [PATCH 3/4] rtc: omap: add rtc wakeup support to alarm events
On Tue, Jul 02, 2013 at 11:39:28, Nori, Sekhar wrote:
On 7/2/2013 11:34 AM, Hebbar, Gururaja wrote:
On Tue, Jul 02, 2013 at 11:32:34, Nori, Sekhar wrote:
On 6/28/2013 3:05 PM, Hebbar Gururaja wrote:
On some platforms (like AM33xx), a special register (RTC_IRQWAKEEN)
is available to enable Alarm Wakeup feature. This register needs to be
properly handled for the rtcwake to work properly.
Platforms using such IP should set ti,am3352-rtc in rtc device dt
compatibility node.
Signed-off-by: Hebbar Gururaja gururaja.heb...@ti.com
Cc: Grant Likely grant.lik...@linaro.org
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Rob Landley r...@landley.net
Cc: Sekhar Nori nsek...@ti.com
Cc: Kevin Hilman khil...@linaro.org
Cc: Alessandro Zummo a.zu...@towertech.it
Cc: rtc-li...@googlegroups.com
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-...@vger.kernel.org
---
[...]
-#define OMAP_RTC_DATA_DA830_IDX 1
+#define OMAP_RTC_DATA_DA830_IDX 1
+#define OMAP_RTC_DATA_AM335X_IDX2
static struct platform_device_id omap_rtc_devtype[] = {
{
@@ -309,6 +321,9 @@ static struct platform_device_id omap_rtc_devtype[] =
{
}, {
.name = da830-rtc,
.driver_data = OMAP_RTC_HAS_KICKER,
+ }, {
+ .name = am335x-rtc,
may be use am3352-rtc here just to keep the platform device name and of
compatible in sync.
Correct. I will update the same in v2.
+ .driver_data = OMAP_RTC_HAS_KICKER | OMAP_RTC_HAS_IRQWAKEEN,
},
{},
It is better to use the index defined above in the static initialization
so they remain in sync.
Sorry. I didn’t get this.
See example below I provided. If its still not clear, let me know what
is not clear.
...
[OMAP_RTC_DATA_DA830_IDX] = {
.name = da830-rtc,
.driver_data = OMAP_RTC_HAS_KICKER,
},
Thanks for the clarification. In this case will it ok if I update the previous
member also.
Thanks,
Sekhar
Regards,
Gururaja
RE: [PATCH 4/4] ARM: dts: AM33XX: update rtc node compatibility
On Tue, Jul 02, 2013 at 11:42:49, Nori, Sekhar wrote:
Changing to Benoit's gmail id since he apparently wont access TI mail
anymore.
On 6/28/2013 3:05 PM, Hebbar Gururaja wrote:
Since AM33xx RTC IP has RTC_IRQWAKEEN to support Alarm Wake-up.
Update the rtc compatible property to ti,am3352-rtc to enable handling
of this feature inside rtc-omap driver.
Signed-off-by: Hebbar Gururaja gururaja.heb...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Sekhar Nori nsek...@ti.com
Cc: Kevin Hilman khil...@linaro.org
Cc: b-cous...@ti.com
---
:100644 100644 77aa1b0... dde180a... M arch/arm/boot/dts/am33xx.dtsi
arch/arm/boot/dts/am33xx.dtsi |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 77aa1b0..dde180a 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -297,7 +297,7 @@
};
rtc@44e3e000 {
- compatible = ti,da830-rtc;
+ compatible = ti,am3352-rtc;
compatible is a list so you can instead do:
compatible = ti,am3352-rtc, ti,da830-rtc;
That way the dts works irrespective of driver updates. When driver
supports enhanced features of hardware, they are available to the user
else the basic functionality still works.
Ok. I will update the same now in v2.
Thanks,
Sekhar
Regards,
Gururaja
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj��!�i
RE: [PATCH 4/4] ARM: dts: AM33XX: update rtc node compatibility
On Tue, Jul 02, 2013 at 11:42:49, Nori, Sekhar wrote:
Changing to Benoit's gmail id since he apparently wont access TI mail
anymore.
On 6/28/2013 3:05 PM, Hebbar Gururaja wrote:
Since AM33xx RTC IP has RTC_IRQWAKEEN to support Alarm Wake-up.
Update the rtc compatible property to ti,am3352-rtc to enable handling
of this feature inside rtc-omap driver.
Signed-off-by: Hebbar Gururaja gururaja.heb...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Sekhar Nori nsek...@ti.com
Cc: Kevin Hilman khil...@linaro.org
Cc: b-cous...@ti.com
---
:100644 100644 77aa1b0... dde180a... M arch/arm/boot/dts/am33xx.dtsi
arch/arm/boot/dts/am33xx.dtsi |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 77aa1b0..dde180a 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -297,7 +297,7 @@
};
rtc@44e3e000 {
- compatible = ti,da830-rtc;
+ compatible = ti,am3352-rtc;
compatible is a list so you can instead do:
compatible = ti,am3352-rtc, ti,da830-rtc;
I believe the order is not important here. I mean, below is also fine. Right?
compatible = ti,da830-rtc, ti,am3352-rtc;
That way the dts works irrespective of driver updates. When driver
supports enhanced features of hardware, they are available to the user
else the basic functionality still works.
Thanks,
Sekhar
Regards,
Gururaja
RE: [PATCH 3/4] rtc: omap: add rtc wakeup support to alarm events
Hi all,
Kindly ignore this message. It was sent in wrong format.
Sorry for the noise
Regards,
Gururaja
On Wed, Jul 03, 2013 at 10:26:57, Hebbar, Gururaja wrote:
Below is the code snippet I was referring to
From drivers/rtc/rtc-omap.c
static struct platform_device_id omap_rtc_devtype[] = {
{
.name = DRIVER_NAME,
},
[OMAP_RTC_DATA_AM3352_IDX] = {
.name = am3352-rtc,
.driver_data = OMAP_RTC_HAS_KICKER | OMAP_RTC_HAS_IRQWAKEEN,
},
[OMAP_RTC_DATA_DA830_IDX] = {
.name = da830-rtc,
.driver_data = OMAP_RTC_HAS_KICKER,
},
{},
};
MODULE_DEVICE_TABLE(platform, omap_rtc_devtype);
static const struct of_device_id omap_rtc_of_match[] = {
{ .compatible = ti,da830-rtc,
.data = omap_rtc_devtype[OMAP_RTC_DATA_DA830_IDX],
},
{ .compatible = ti,am3352-rtc,
.data = omap_rtc_devtype[OMAP_RTC_DATA_AM3352_IDX],
},
{},
};
MODULE_DEVICE_TABLE(of, omap_rtc_of_match);
From arch/arm/boot/dts/am33xx.dtsi
rtc@44e3e000 {
compatible = ti,da830-rtc, ti,am3352-rtc;
reg = 0x44e3e000 0x1000;
interrupts = 75
76;
ti,hwmods = rtc;
};
As seen from above snippet, 2 compatible items are specified for
compatible dt property (ti,da830-rtc ti,am3352-rtc”)
These are the same compatibles that are mentioned in the of_device_id
structure inside rtc-omap driver.
What I observed is, if we mention both compatible in the .dtsi file that
are under one single of_device_id structure, the first match from the
of_device_id structure is considered (ti,da830-rtc in above case)
To confirm, I switched the 2 compatible inside of_device_id structure as
below
static const struct of_device_id omap_rtc_of_match[] = {
{ .compatible = ti,am3352-rtc,
.data = omap_rtc_devtype[OMAP_RTC_DATA_AM3352_IDX],
},
{ .compatible = ti,da830-rtc,
.data = omap_rtc_devtype[OMAP_RTC_DATA_DA830_IDX],
},
{},
};
In this case, the first match from compatible field was chosen
(ti,am3352-rtc now).
Hope this is clear.
Kindly let me know when you are free to discuss.
Regards
Gururaja
-Original Message-
From: Nori, Sekhar
Sent: Tuesday, July 02, 2013 11:47 AM
To: Hebbar, Gururaja
Cc: khil...@linaro.org; t...@atomide.com; Cousson, Benoit; linux-
o...@vger.kernel.org; devicetree-disc...@lists.ozlabs.org; linux-
ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
davinci-linux-open-sou...@linux.davincidsp.com; Bedia, Vaibhav;
Rajashekhara, Sudhakar; Grant Likely; Rob Herring; Rob Landley;
Alessandro Zummo; rtc-li...@googlegroups.com; linux-
d...@vger.kernel.org
Subject: Re: [PATCH 3/4] rtc: omap: add rtc wakeup support to
alarm events
On 7/2/2013 11:41 AM, Hebbar, Gururaja wrote:
On Tue, Jul 02, 2013 at 11:39:28, Nori, Sekhar wrote:
On 7/2/2013 11:34 AM, Hebbar, Gururaja wrote:
On Tue, Jul 02, 2013 at 11:32:34, Nori, Sekhar wrote:
On 6/28/2013 3:05 PM, Hebbar Gururaja wrote:
On some platforms (like AM33xx), a special register
(RTC_IRQWAKEEN)
is available to enable Alarm Wakeup feature. This register
needs to be
properly handled for the rtcwake to work properly.
Platforms using such IP should set ti,am3352-rtc in rtc
device dt
compatibility node.
Signed-off-by: Hebbar Gururaja gururaja.heb...@ti.com
mailto:gururaja.heb...@ti.com
Cc: Grant Likely grant.lik...@linaro.org
mailto:grant.lik...@linaro.org
Cc: Rob Herring rob.herr...@calxeda.com
mailto:rob.herr...@calxeda.com
Cc: Rob Landley r...@landley.net mailto:r...@landley.net
Cc: Sekhar Nori nsek...@ti.com mailto:nsek...@ti.com
Cc: Kevin Hilman khil...@linaro.org mailto:khil...@linaro.org
Cc: Alessandro Zummo a.zu...@towertech.it
mailto:a.zu...@towertech.it
Cc: rtc-li...@googlegroups.com
mailto:rtc-li...@googlegroups.com
Cc: devicetree-disc...@lists.ozlabs.org
mailto:devicetree-disc...@lists.ozlabs.org
Cc: linux-...@vger.kernel.org mailto:linux-...@vger.kernel.org
---
[...]
-#define OMAP_RTC_DATA_DA830_IDX 1
+#define OMAP_RTC_DATA_DA830_IDX 1
+#define OMAP_RTC_DATA_AM335X_IDX 2
static struct platform_device_id omap_rtc_devtype[] = {
{
@@ -309,6 +321,9 @@ static struct platform_device_id
omap_rtc_devtype[] = {
}, {
.name = da830-rtc,
.driver_data = OMAP_RTC_HAS_KICKER,
+ }, {
+ .name = am335x-rtc,
may be use am3352-rtc here just to keep the platform device
name and of
compatible in sync.
Correct. I will update the same in v2.
+ .driver_data = OMAP_RTC_HAS_KICKER |
OMAP_RTC_HAS_IRQWAKEEN
RE: [PATCH 2/4] davinci: da8xx/omap-l1: Remove hard coding of rtc device wakeup
On Tue, Jul 02, 2013 at 05:37:43, Kevin Hilman wrote:
Hebbar Gururaja gururaja.heb...@ti.com writes:
Since now rtc-omap driver itself calls deice_init_wakeup(dev, true),
duplicate call from the rtc device registration can be removed.
This is basically a partial revert of the prev commit
commit 75c99bb0006ee065b4e2995078d779418b0fab54
Author: Sekhar Nori nsek...@ti.com
davinci: da8xx/omap-l1: mark RTC as a wakeup source
Signed-off-by: Hebbar Gururaja gururaja.heb...@ti.com
Cc: Sekhar Nori nsek...@ti.com
Cc: Kevin Hilman khil...@linaro.org
Cc: Russell King li...@arm.linux.org.uk
---
:100644 100644 bf57252... 85a900c... M
arch/arm/mach-davinci/devices-da8xx.c
arch/arm/mach-davinci/devices-da8xx.c |9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/arch/arm/mach-davinci/devices-da8xx.c
b/arch/arm/mach-davinci/devices-da8xx.c
index bf57252..85a900c 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -827,14 +827,7 @@ static struct platform_device da8xx_rtc_device = {
int da8xx_register_rtc(void)
{
- int ret;
-
- ret = platform_device_register(da8xx_rtc_device);
- if (!ret)
- /* Atleast on DA850, RTC is a wakeup source */
- device_init_wakeup(da8xx_rtc_device.dev, true);
-
- return ret;
+ return platform_device_register(da8xx_rtc_device);
nit: extra space between 'return' and 'platform_'
Thanks for the review. V2 will soon follow.
}
static void __iomem *da8xx_ddr2_ctlr_base;
Otherwise,
Acked-by: Kevin Hilman khil...@linaro.org
Regards,
Gururaja
--
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 3/4] rtc: omap: add rtc wakeup support to alarm events
On Tue, Jul 02, 2013 at 05:45:01, Kevin Hilman wrote: Hebbar Gururaja gururaja.heb...@ti.com writes: On some platforms (like AM33xx), a special register (RTC_IRQWAKEEN) is available to enable Alarm Wakeup feature. This register needs to be properly handled for the rtcwake to work properly. Platforms using such IP should set ti,am3352-rtc in rtc device dt compatibility node. Signed-off-by: Hebbar Gururaja gururaja.heb...@ti.com Cc: Grant Likely grant.lik...@linaro.org Cc: Rob Herring rob.herr...@calxeda.com Cc: Rob Landley r...@landley.net Cc: Sekhar Nori nsek...@ti.com Cc: Kevin Hilman khil...@linaro.org Cc: Alessandro Zummo a.zu...@towertech.it Cc: rtc-li...@googlegroups.com Cc: devicetree-disc...@lists.ozlabs.org Cc: linux-...@vger.kernel.org Acked-by: Kevin Hilman khil...@linaro.org ...with a minor nit below... --- :100644 100644 b47aa41... 5a0f02d... M Documentation/devicetree/bindings/rtc/rtc-omap.txt :100644 100644 761919d... 666b0c2... M drivers/rtc/rtc-omap.c Documentation/devicetree/bindings/rtc/rtc-omap.txt |6 ++- drivers/rtc/rtc-omap.c | 56 +--- 2 files changed, 54 insertions(+), 8 deletions(-) diff --git a/Documentation/devicetree/bindings/rtc/rtc-omap.txt b/Documentation/devicetree/bindings/rtc/rtc-omap.txt index b47aa41..5a0f02d 100644 --- a/Documentation/devicetree/bindings/rtc/rtc-omap.txt +++ b/Documentation/devicetree/bindings/rtc/rtc-omap.txt @@ -1,7 +1,11 @@ TI Real Time Clock Required properties: -- compatible: ti,da830-rtc +- compatible: + - ti,da830-rtc - for RTC IP used similar to that on DA8xx SoC family. + - ti,am3352-rtc - for RTC IP used similar to that on AM335x SoC family. + This RTC IP has special WAKE-EN Register to enable + Wakeup generation for event Alarm. - reg: Address range of rtc register set - interrupts: rtc timer, alarm interrupts in order - interrupt-parent: phandle for the interrupt controller diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c index 761919d..666b0c2 100644 --- a/drivers/rtc/rtc-omap.c +++ b/drivers/rtc/rtc-omap.c @@ -72,6 +72,8 @@ #define OMAP_RTC_KICK0_REG 0x6c #define OMAP_RTC_KICK1_REG 0x70 +#define OMAP_RTC_IRQWAKEEN 0x7C + nit: letters in hex numbers are usually lower-case. Thanks for the review. V2 will soon follow. Kevin Regards, Gururaja -- 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 2/4] davinci: da8xx/omap-l1: Remove hard coding of rtc device wakeup
On Tue, Jul 02, 2013 at 11:10:14, Nori, Sekhar wrote: On 6/28/2013 3:05 PM, Hebbar Gururaja wrote: Since now rtc-omap driver itself calls deice_init_wakeup(dev, true), duplicate call from the rtc device registration can be removed. This is basically a partial revert of the prev commit commit 75c99bb0006ee065b4e2995078d779418b0fab54 Author: Sekhar Nori nsek...@ti.com davinci: da8xx/omap-l1: mark RTC as a wakeup source Signed-off-by: Hebbar Gururaja gururaja.heb...@ti.com Cc: Sekhar Nori nsek...@ti.com Cc: Kevin Hilman khil...@linaro.org Cc: Russell King li...@arm.linux.org.uk Subject line should be prefixed with ARM: keeping with arch/arm convention. Otherwise looks good. Will fix it in v2. Acked-by: Sekhar Nori nsek...@ti.com Thanks for the review. Thanks, Sekhar Regards, Gururaja
[PATCH 0/4] rtc: omap: handle rtc wakeup support in driver
rtc-omap driver modules is used both by OMAP1/2, Davinci SoC platforms. However, rtc wake support on OMAP1 is broken. Hence the device_init_wakeup() was removed from rtc-omap driver and moved to platform board files that supported it (DA850/OMAP-L138). [1] However, recently [2] it was suggested that driver should always do a device_init_wakeup(dev, true). Platforms that don't want/need wakeup support can disable it from userspace via: echo disabled /sys/devices/.../power/wakeup Also, with the new DT boot-up, board file doesn't exist and hence there is no way to have device wakeup support rtc. The fix for above issues, is to hard code device_init_wakeup() inside driver and let platforms that don't need this, handle it through the sysfs power entry. Also, update Davinci AM335x files to above changes. [1] https://patchwork.kernel.org/patch/136731/ [2] http://www.mail-archive.com/davinci-linux-open-source@linux. davincidsp.com/msg26077.html Hebbar Gururaja (4): rtc: omap: restore back (hard-code) wakeup support davinci: da8xx/omap-l1: Remove hard coding of rtc device wakeup rtc: omap: add rtc wakeup support to alarm events ARM: dts: AM33XX: update rtc node compatibility Documentation/devicetree/bindings/rtc/rtc-omap.txt |6 +- arch/arm/boot/dts/am33xx.dtsi |2 +- arch/arm/mach-davinci/devices-da8xx.c |9 +-- drivers/rtc/rtc-omap.c | 58 +--- 4 files changed, 58 insertions(+), 17 deletions(-) -- 1.7.9.5 -- 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 2/4] davinci: da8xx/omap-l1: Remove hard coding of rtc device wakeup
Since now rtc-omap driver itself calls deice_init_wakeup(dev, true),
duplicate call from the rtc device registration can be removed.
This is basically a partial revert of the prev commit
commit 75c99bb0006ee065b4e2995078d779418b0fab54
Author: Sekhar Nori nsek...@ti.com
davinci: da8xx/omap-l1: mark RTC as a wakeup source
Signed-off-by: Hebbar Gururaja gururaja.heb...@ti.com
Cc: Sekhar Nori nsek...@ti.com
Cc: Kevin Hilman khil...@linaro.org
Cc: Russell King li...@arm.linux.org.uk
---
:100644 100644 bf57252... 85a900c... M arch/arm/mach-davinci/devices-da8xx.c
arch/arm/mach-davinci/devices-da8xx.c |9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/arch/arm/mach-davinci/devices-da8xx.c
b/arch/arm/mach-davinci/devices-da8xx.c
index bf57252..85a900c 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -827,14 +827,7 @@ static struct platform_device da8xx_rtc_device = {
int da8xx_register_rtc(void)
{
- int ret;
-
- ret = platform_device_register(da8xx_rtc_device);
- if (!ret)
- /* Atleast on DA850, RTC is a wakeup source */
- device_init_wakeup(da8xx_rtc_device.dev, true);
-
- return ret;
+ return platform_device_register(da8xx_rtc_device);
}
static void __iomem *da8xx_ddr2_ctlr_base;
--
1.7.9.5
--
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 1/4] rtc: omap: restore back (hard-code) wakeup support
rtc-omap driver modules is used both by OMAP1/2, Davinci SoC platforms. However, rtc wake support on OMAP1 is broken. Hence the device_init_wakeup() was removed from rtc-omap driver and moved to platform board files that supported it (DA850/OMAP-L138). [1] However, recently [2] it was suggested that driver should always do a device_init_wakeup(dev, true). Platforms that don't want/need wakeup support can disable it from userspace via: echo disabled /sys/devices/.../power/wakeup Also, with the new DT boot-up, board file doesn't exist and hence there is no way to have device wakeup support rtc. The fix for above issues, is to hard code device_init_wakeup() inside driver and let platforms that don't need this, handle it through the sysfs power entry. [1] https://patchwork.kernel.org/patch/136731/ [2] http://www.mail-archive.com/davinci-linux-open-source@linux. davincidsp.com/msg26077.html Signed-off-by: Hebbar Gururaja gururaja.heb...@ti.com Cc: Alessandro Zummo a.zu...@towertech.it Cc: rtc-li...@googlegroups.com --- :100644 100644 b0ba3fc... 761919d... M drivers/rtc/rtc-omap.c drivers/rtc/rtc-omap.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c index b0ba3fc..761919d 100644 --- a/drivers/rtc/rtc-omap.c +++ b/drivers/rtc/rtc-omap.c @@ -423,6 +423,8 @@ static int __init omap_rtc_probe(struct platform_device *pdev) *is write-only, and always reads as zero...) */ + device_init_wakeup(pdev-dev, true); + if (new_ctrl (u8) OMAP_RTC_CTRL_SPLIT) pr_info(%s: split power mode\n, pdev-name); -- 1.7.9.5 -- 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 3/4] rtc: omap: add rtc wakeup support to alarm events
On some platforms (like AM33xx), a special register (RTC_IRQWAKEEN)
is available to enable Alarm Wakeup feature. This register needs to be
properly handled for the rtcwake to work properly.
Platforms using such IP should set ti,am3352-rtc in rtc device dt
compatibility node.
Signed-off-by: Hebbar Gururaja gururaja.heb...@ti.com
Cc: Grant Likely grant.lik...@linaro.org
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Rob Landley r...@landley.net
Cc: Sekhar Nori nsek...@ti.com
Cc: Kevin Hilman khil...@linaro.org
Cc: Alessandro Zummo a.zu...@towertech.it
Cc: rtc-li...@googlegroups.com
Cc: devicetree-disc...@lists.ozlabs.org
Cc: linux-...@vger.kernel.org
---
:100644 100644 b47aa41... 5a0f02d... M
Documentation/devicetree/bindings/rtc/rtc-omap.txt
:100644 100644 761919d... 666b0c2... M drivers/rtc/rtc-omap.c
Documentation/devicetree/bindings/rtc/rtc-omap.txt |6 ++-
drivers/rtc/rtc-omap.c | 56 +---
2 files changed, 54 insertions(+), 8 deletions(-)
diff --git a/Documentation/devicetree/bindings/rtc/rtc-omap.txt
b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
index b47aa41..5a0f02d 100644
--- a/Documentation/devicetree/bindings/rtc/rtc-omap.txt
+++ b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
@@ -1,7 +1,11 @@
TI Real Time Clock
Required properties:
-- compatible: ti,da830-rtc
+- compatible:
+ - ti,da830-rtc - for RTC IP used similar to that on DA8xx SoC family.
+ - ti,am3352-rtc - for RTC IP used similar to that on AM335x SoC
family.
+ This RTC IP has special WAKE-EN Register to enable
+ Wakeup generation for event Alarm.
- reg: Address range of rtc register set
- interrupts: rtc timer, alarm interrupts in order
- interrupt-parent: phandle for the interrupt controller
diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index 761919d..666b0c2 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -72,6 +72,8 @@
#define OMAP_RTC_KICK0_REG 0x6c
#define OMAP_RTC_KICK1_REG 0x70
+#define OMAP_RTC_IRQWAKEEN 0x7C
+
/* OMAP_RTC_CTRL_REG bit fields: */
#define OMAP_RTC_CTRL_SPLIT(17)
#define OMAP_RTC_CTRL_DISABLE (16)
@@ -96,12 +98,21 @@
#define OMAP_RTC_INTERRUPTS_IT_ALARM(13)
#define OMAP_RTC_INTERRUPTS_IT_TIMER(12)
+/* OMAP_RTC_IRQWAKEEN bit fields: */
+#define OMAP_RTC_IRQWAKEEN_ALARM_WAKEEN(11)
+
/* OMAP_RTC_KICKER values */
#defineKICK0_VALUE 0x83e70b13
#defineKICK1_VALUE 0x95a4f1e0
#defineOMAP_RTC_HAS_KICKER 0x1
+/*
+ * Few RTC IP revisions has special WAKE-EN Register to enable Wakeup
+ * generation for event Alarm.
+ */
+#defineOMAP_RTC_HAS_IRQWAKEEN 0x2
+
static void __iomem*rtc_base;
#define rtc_read(addr) readb(rtc_base + (addr))
@@ -301,7 +312,8 @@ static struct rtc_class_ops omap_rtc_ops = {
static int omap_rtc_alarm;
static int omap_rtc_timer;
-#defineOMAP_RTC_DATA_DA830_IDX 1
+#defineOMAP_RTC_DATA_DA830_IDX 1
+#defineOMAP_RTC_DATA_AM335X_IDX2
static struct platform_device_id omap_rtc_devtype[] = {
{
@@ -309,6 +321,9 @@ static struct platform_device_id omap_rtc_devtype[] = {
}, {
.name = da830-rtc,
.driver_data = OMAP_RTC_HAS_KICKER,
+ }, {
+ .name = am335x-rtc,
+ .driver_data = OMAP_RTC_HAS_KICKER | OMAP_RTC_HAS_IRQWAKEEN,
},
{},
};
@@ -318,6 +333,9 @@ static const struct of_device_id omap_rtc_of_match[] = {
{ .compatible = ti,da830-rtc,
.data = omap_rtc_devtype[OMAP_RTC_DATA_DA830_IDX],
},
+ { .compatible = ti,am3352-rtc,
+ .data = omap_rtc_devtype[OMAP_RTC_DATA_AM335X_IDX],
+ },
{},
};
MODULE_DEVICE_TABLE(of, omap_rtc_of_match);
@@ -466,16 +484,28 @@ static u8 irqstat;
static int omap_rtc_suspend(struct device *dev)
{
+ u8 irqwake_stat;
+ struct platform_device *pdev = to_platform_device(dev);
+ const struct platform_device_id *id_entry =
+ platform_get_device_id(pdev);
+
irqstat = rtc_read(OMAP_RTC_INTERRUPTS_REG);
/* FIXME the RTC alarm is not currently acting as a wakeup event
-* source, and in fact this enable() call is just saving a flag
-* that's never used...
+* source on some platforms, and in fact this enable() call is just
+* saving a flag that's never used...
*/
- if (device_may_wakeup(dev))
+ if (device_may_wakeup(dev)) {
enable_irq_wake(omap_rtc_alarm);
- else
+
+ if (id_entry-driver_data OMAP_RTC_HAS_IRQWAKEEN) {
+ irqwake_stat = rtc_read(OMAP_RTC_IRQWAKEEN);
+ irqwake_stat
[PATCH 4/4] ARM: dts: AM33XX: update rtc node compatibility
Since AM33xx RTC IP has RTC_IRQWAKEEN to support Alarm Wake-up.
Update the rtc compatible property to ti,am3352-rtc to enable handling
of this feature inside rtc-omap driver.
Signed-off-by: Hebbar Gururaja gururaja.heb...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Sekhar Nori nsek...@ti.com
Cc: Kevin Hilman khil...@linaro.org
Cc: b-cous...@ti.com
---
:100644 100644 77aa1b0... dde180a... M arch/arm/boot/dts/am33xx.dtsi
arch/arm/boot/dts/am33xx.dtsi |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 77aa1b0..dde180a 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -297,7 +297,7 @@
};
rtc@44e3e000 {
- compatible = ti,da830-rtc;
+ compatible = ti,am3352-rtc;
reg = 0x44e3e000 0x1000;
interrupts = 75
76;
--
1.7.9.5
--
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 5/5] mmc: omap_hsmmc: Add reg-offset to bindings documentation
On Wed, Jun 26, 2013 at 06:55:01, Fernandes, Joel wrote: From: Joel A Fernandes agnel.j...@gmail.com A new reg-offset property was added to account for register offsets in some omap-hsmmc's. Document the new property. Small nitpick I usually get feedback that any driver DT changes and the associated Binding doc update should come in one single patch for better readability. In this case, I believe it would be patch 1/5 5/5 Regards, Gururaja Signed-off-by: Joel A Fernandes agnel.j...@gmail.com --- .../devicetree/bindings/mmc/ti-omap-hsmmc.txt |3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt index 8c8908a..33f4b1e 100644 --- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt +++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt @@ -20,6 +20,9 @@ ti,dual-volt: boolean, supports dual voltage cards ti,non-removable: non-removable slot (like eMMC) ti,needs-special-reset: Requires a special softreset sequence ti,needs-special-hs-handling: HSMMC IP needs special setting for handling High Speed +reg-offset: Supplementing the common reg property (described in bindings/mmc/mmc.txt), +some omap-hsmmc's can start an offset from reg but are otherwise identical to others. +The registers between start to offset are considered reserved. dmas: List of DMA specifiers with the controller specific format as described in the generic DMA client binding. A tx and rx specifier is required. -- 1.7.9.5 -- 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 11/11] i2c: omap: enhance pinctrl support
On Fri, May 31, 2013 at 20:25:38, Strashko, Grygorii wrote:
On 05/31/2013 01:13 PM, Hebbar Gururaja wrote:
Amend the I2C omap pin controller to optionally take a pin control
handle and set the state of the pins to:
- default on boot, resume and before performing an i2c transfer
- idle after initial default, after resume default, and after each
i2c xfer
- sleep on suspend()
By optionally putting the pins into sleep state in the suspend callback
we can accomplish two things.
- One is to minimize current leakage from pins and thus save power,
- second, we can prevent the IP from driving pins output in an
uncontrolled manner, which may happen if the power domain drops the
domain regulator.
Note:
A .suspend .resume callback is added which simply puts the pins to sleep
state upon suspend are moved to default idle state upon resume.
If any of the above pin states are missing in dt, a warning message
about the missing state is displayed.
If certain pin-states are not available, to remove this warning message
pass respective state name with null phandler.
(Changes based on i2c-nomadik.c)
Signed-off-by: Hebbar Gururaja gururaja.heb...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Wolfram Sang w...@the-dreams.de
Cc: linux-omap@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
:100644 100644 e02f9e3... 588ba28... M drivers/i2c/busses/i2c-omap.c
drivers/i2c/busses/i2c-omap.c | 112
++---
1 file changed, 105 insertions(+), 7 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index e02f9e3..588ba28 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -214,7 +214,11 @@ struct omap_i2c_dev {
u16 westate;
u16 errata;
- struct pinctrl *pins;
+ /* Three pin states - default, idle sleep */
+ struct pinctrl *pinctrl;
+ struct pinctrl_state*pins_default;
+ struct pinctrl_state*pins_idle;
+ struct pinctrl_state*pins_sleep;
};
static const u8 reg_map_ip_v1[] = {
@@ -641,6 +645,11 @@ omap_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg
msgs[], int num)
if (IS_ERR_VALUE(r))
goto out;
The current HWMOD framework configures PINs to enable state before
enabling the device and
switch PINs to idle state after disabling the device. Why here its done
in different order?
AFAIK, in case of DT boot, oh-mux will be NULL. So hwmod will not change
Any pins.
+ /* Optionaly enable pins to be muxed in and configured */
+ if (!IS_ERR(dev-pins_default))
+ if (pinctrl_select_state(dev-pinctrl, dev-pins_default))
+ dev_err(dev-dev, could not set default pins\n);
+
r = omap_i2c_wait_for_bb(dev);
if (r 0)
goto out;
@@ -664,7 +673,13 @@ omap_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg
msgs[], int num)
out:
pm_runtime_mark_last_busy(dev-dev);
+
pm_runtime_put_autosuspend(dev-dev);
+ /* Optionally let pins go into idle state */
+ if (!IS_ERR(dev-pins_idle))
+ if (pinctrl_select_state(dev-pinctrl, dev-pins_idle))
+ dev_err(dev-dev, could not set pins to idle state\n);
+
return r;
}
@@ -1123,14 +1138,47 @@ omap_i2c_probe(struct platform_device *pdev)
dev-set_mpu_wkup_lat = pdata-set_mpu_wkup_lat;
}
- dev-pins = devm_pinctrl_get_select_default(pdev-dev);
- if (IS_ERR(dev-pins)) {
- if (PTR_ERR(dev-pins) == -EPROBE_DEFER)
+ dev-pinctrl = devm_pinctrl_get(pdev-dev);
May be struct device -pins-p can be used instead of dev-pinctrl?
+ if (!IS_ERR(dev-pinctrl)) {
+ dev-pins_default = pinctrl_lookup_state(dev-pinctrl,
+PINCTRL_STATE_DEFAULT);
+ if (IS_ERR(dev-pins_default))
+ dev_dbg(pdev-dev, could not get default pinstate\n);
+ else
+ if (pinctrl_select_state(dev-pinctrl,
+dev-pins_default))
+ dev_err(pdev-dev,
+ could not set default pinstate\n);
Don't need to set Default pin state
Default pins state is applied by DD framework automatically before
device probing
and stored in struct device -pins-default_state
Correct.
+
+ dev-pins_idle = pinctrl_lookup_state(dev-pinctrl,
+ PINCTRL_STATE_IDLE);
+ if (IS_ERR(dev-pins_idle))
+ dev_dbg(pdev-dev, could not get idle pinstate\n);
+ else
+ /* If possible, let's idle until the first transfer */
+ if (pinctrl_select_state(dev-pinctrl
RE: [PATCH 11/11] i2c: omap: enhance pinctrl support
On Fri, May 31, 2013 at 23:04:59, Kevin Hilman wrote: Hebbar Gururaja gururaja.heb...@ti.com writes: Amend the I2C omap pin controller to optionally take a pin control handle and set the state of the pins to: - default on boot, resume and before performing an i2c transfer - idle after initial default, after resume default, and after each i2c xfer - sleep on suspend() By optionally putting the pins into sleep state in the suspend callback we can accomplish two things. - One is to minimize current leakage from pins and thus save power, - second, we can prevent the IP from driving pins output in an uncontrolled manner, which may happen if the power domain drops the domain regulator. Note: A .suspend .resume callback is added which simply puts the pins to sleep state upon suspend are moved to default idle state upon resume. If any of the above pin states are missing in dt, a warning message about the missing state is displayed. If certain pin-states are not available, to remove this warning message pass respective state name with null phandler. (Changes based on i2c-nomadik.c) Signed-off-by: Hebbar Gururaja gururaja.heb...@ti.com Cc: Tony Lindgren t...@atomide.com Cc: Wolfram Sang w...@the-dreams.de Cc: linux-omap@vger.kernel.org Cc: linux-...@vger.kernel.org [...] @@ -664,7 +673,13 @@ omap_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg msgs[], int num) out: pm_runtime_mark_last_busy(dev-dev); + pm_runtime_put_autosuspend(dev-dev); + /* Optionally let pins go into idle state */ + if (!IS_ERR(dev-pins_idle)) + if (pinctrl_select_state(dev-pinctrl, dev-pins_idle)) + dev_err(dev-dev, could not set pins to idle state\n); This is wrong. You're changing the muxing before the device actually goes idle. Anything you want to happen when the device actually idles for real has to be in runtime PM callbacks. Looking below, I see it's already in the callbacks, so why is it here also? Just to be double sure. Seems it is unwanted. [...] @@ -1300,6 +1348,10 @@ static int omap_i2c_runtime_suspend(struct device *dev) omap_i2c_read_reg(_dev, OMAP_I2C_STAT_REG); } + if (!IS_ERR(_dev-pins_idle)) + if (pinctrl_select_state(_dev-pinctrl, _dev-pins_idle)) + dev_err(dev, could not set pins to idle state\n); + return 0; } Kevin Regards, Gururaja -- 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 11/11] i2c: omap: enhance pinctrl support
On Fri, May 31, 2013 at 23:37:02, Kevin Hilman wrote:
+Linus Walleij (pinctrl maintainer)
Hebbar Gururaja gururaja.heb...@ti.com writes:
Amend the I2C omap pin controller to optionally take a pin control
handle and set the state of the pins to:
- default on boot, resume and before performing an i2c transfer
- idle after initial default, after resume default, and after each
i2c xfer
- sleep on suspend()
By optionally putting the pins into sleep state in the suspend callback
we can accomplish two things.
- One is to minimize current leakage from pins and thus save power,
- second, we can prevent the IP from driving pins output in an
uncontrolled manner, which may happen if the power domain drops the
domain regulator.
Note:
A .suspend .resume callback is added which simply puts the pins to sleep
state upon suspend are moved to default idle state upon resume.
If any of the above pin states are missing in dt, a warning message
about the missing state is displayed.
If certain pin-states are not available, to remove this warning message
pass respective state name with null phandler.
(Changes based on i2c-nomadik.c)
Signed-off-by: Hebbar Gururaja gururaja.heb...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Wolfram Sang w...@the-dreams.de
Cc: linux-omap@vger.kernel.org
Cc: linux-...@vger.kernel.org
[...]
@@ -1123,14 +1138,47 @@ omap_i2c_probe(struct platform_device *pdev)
dev-set_mpu_wkup_lat = pdata-set_mpu_wkup_lat;
}
- dev-pins = devm_pinctrl_get_select_default(pdev-dev);
- if (IS_ERR(dev-pins)) {
- if (PTR_ERR(dev-pins) == -EPROBE_DEFER)
+ dev-pinctrl = devm_pinctrl_get(pdev-dev);
+ if (!IS_ERR(dev-pinctrl)) {
+ dev-pins_default = pinctrl_lookup_state(dev-pinctrl,
+PINCTRL_STATE_DEFAULT);
This part is already done by probe in driver core, why does it need to
be done again. dev-pins-default_state should already have this.
(c.f. pinctrl_bind_pins() in drivers/base/pinctrl.c)
But that brings up a bigger question about whether or not we should be
doing the rest of this (idle/sleep) pin management in the drivers or in
the driver core as well. I would much prefer it be handled by the
driver core.
In fact, since these are all PM related events, it should probably be
handled by the PM core and seems pretty straight forward to do so.
Let me pull out some info about these and come back
Kevin
Regards,
Gururaja
--
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 09/11] mmc: omap_hsmmc: enhance pinctrl support
On Tue, Jun 04, 2013 at 12:49:57, Linus Walleij wrote: On Tue, Jun 4, 2013 at 9:11 AM, Linus Walleij linus.wall...@linaro.org wrote: On Fri, May 31, 2013 at 12:13 PM, Hebbar Gururaja gururaja.heb...@ti.com wrote: Amend the hsmmc controller to optionally take a pin control handle and set the state of the pins to: - default on boot, resume and before performing a mmc transfer - idle after initial default, after resume default, and after each mmc/sd card access - sleep on suspend() By optionally putting the pins into sleep state in the suspend callback we can accomplish two things. - One is to minimize current leakage from pins and thus save power, - second, we can prevent the IP from driving pins output in an uncontrolled manner, which may happen if the power domain drops the domain regulator. If any of the above pin states are missing in dt, a warning message about the missing state is displayed. If certain pin-states are not available, to remove this warning message pass respective state name with null phandler. Signed-off-by: Hebbar Gururaja gururaja.heb...@ti.com Cc: Balaji T K balaj...@ti.com Cc: Chris Ball c...@laptop.org Cc: linux-...@vger.kernel.org Cc: linux-omap@vger.kernel.org This is perfectly correct. Acked-by: Linus Walleij linus.wall...@linaro.org So please consider my other option given in patch 2 instead. I will check how I can be a part of this implementation Yours, Linus Walleij Regards, Gururaja -- 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 11/11] i2c: omap: enhance pinctrl support
Amend the I2C omap pin controller to optionally take a pin control
handle and set the state of the pins to:
- default on boot, resume and before performing an i2c transfer
- idle after initial default, after resume default, and after each
i2c xfer
- sleep on suspend()
By optionally putting the pins into sleep state in the suspend callback
we can accomplish two things.
- One is to minimize current leakage from pins and thus save power,
- second, we can prevent the IP from driving pins output in an
uncontrolled manner, which may happen if the power domain drops the
domain regulator.
Note:
A .suspend .resume callback is added which simply puts the pins to sleep
state upon suspend are moved to default idle state upon resume.
If any of the above pin states are missing in dt, a warning message
about the missing state is displayed.
If certain pin-states are not available, to remove this warning message
pass respective state name with null phandler.
(Changes based on i2c-nomadik.c)
Signed-off-by: Hebbar Gururaja gururaja.heb...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Wolfram Sang w...@the-dreams.de
Cc: linux-omap@vger.kernel.org
Cc: linux-...@vger.kernel.org
---
:100644 100644 e02f9e3... 588ba28... M drivers/i2c/busses/i2c-omap.c
drivers/i2c/busses/i2c-omap.c | 112 ++---
1 file changed, 105 insertions(+), 7 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index e02f9e3..588ba28 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -214,7 +214,11 @@ struct omap_i2c_dev {
u16 westate;
u16 errata;
- struct pinctrl *pins;
+ /* Three pin states - default, idle sleep */
+ struct pinctrl *pinctrl;
+ struct pinctrl_state*pins_default;
+ struct pinctrl_state*pins_idle;
+ struct pinctrl_state*pins_sleep;
};
static const u8 reg_map_ip_v1[] = {
@@ -641,6 +645,11 @@ omap_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg
msgs[], int num)
if (IS_ERR_VALUE(r))
goto out;
+ /* Optionaly enable pins to be muxed in and configured */
+ if (!IS_ERR(dev-pins_default))
+ if (pinctrl_select_state(dev-pinctrl, dev-pins_default))
+ dev_err(dev-dev, could not set default pins\n);
+
r = omap_i2c_wait_for_bb(dev);
if (r 0)
goto out;
@@ -664,7 +673,13 @@ omap_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg
msgs[], int num)
out:
pm_runtime_mark_last_busy(dev-dev);
+
pm_runtime_put_autosuspend(dev-dev);
+ /* Optionally let pins go into idle state */
+ if (!IS_ERR(dev-pins_idle))
+ if (pinctrl_select_state(dev-pinctrl, dev-pins_idle))
+ dev_err(dev-dev, could not set pins to idle state\n);
+
return r;
}
@@ -1123,14 +1138,47 @@ omap_i2c_probe(struct platform_device *pdev)
dev-set_mpu_wkup_lat = pdata-set_mpu_wkup_lat;
}
- dev-pins = devm_pinctrl_get_select_default(pdev-dev);
- if (IS_ERR(dev-pins)) {
- if (PTR_ERR(dev-pins) == -EPROBE_DEFER)
+ dev-pinctrl = devm_pinctrl_get(pdev-dev);
+ if (!IS_ERR(dev-pinctrl)) {
+ dev-pins_default = pinctrl_lookup_state(dev-pinctrl,
+PINCTRL_STATE_DEFAULT);
+ if (IS_ERR(dev-pins_default))
+ dev_dbg(pdev-dev, could not get default pinstate\n);
+ else
+ if (pinctrl_select_state(dev-pinctrl,
+dev-pins_default))
+ dev_err(pdev-dev,
+ could not set default pinstate\n);
+
+ dev-pins_idle = pinctrl_lookup_state(dev-pinctrl,
+ PINCTRL_STATE_IDLE);
+ if (IS_ERR(dev-pins_idle))
+ dev_dbg(pdev-dev, could not get idle pinstate\n);
+ else
+ /* If possible, let's idle until the first transfer */
+ if (pinctrl_select_state(dev-pinctrl, dev-pins_idle))
+ dev_err(pdev-dev,
+ could not set idle pinstate\n);
+
+ dev-pins_sleep = pinctrl_lookup_state(dev-pinctrl,
+ PINCTRL_STATE_SLEEP);
+ if (IS_ERR(dev-pins_sleep))
+ dev_dbg(pdev-dev, could not get sleep pinstate\n);
+ } else {
+ if (PTR_ERR(dev-pinctrl) == -EPROBE_DEFER)
return -EPROBE_DEFER;
- dev_warn(pdev-dev, did not get pins for i2c error: %li\n,
-PTR_ERR(dev-pins));
- dev
[PATCH 09/11] mmc: omap_hsmmc: enhance pinctrl support
Amend the hsmmc controller to optionally take a pin control handle and
set the state of the pins to:
- default on boot, resume and before performing a mmc transfer
- idle after initial default, after resume default, and after each
mmc/sd card access
- sleep on suspend()
By optionally putting the pins into sleep state in the suspend callback
we can accomplish two things.
- One is to minimize current leakage from pins and thus save power,
- second, we can prevent the IP from driving pins output in an
uncontrolled manner, which may happen if the power domain drops the
domain regulator.
If any of the above pin states are missing in dt, a warning message
about the missing state is displayed.
If certain pin-states are not available, to remove this warning message
pass respective state name with null phandler.
Signed-off-by: Hebbar Gururaja gururaja.heb...@ti.com
Cc: Balaji T K balaj...@ti.com
Cc: Chris Ball c...@laptop.org
Cc: linux-...@vger.kernel.org
Cc: linux-omap@vger.kernel.org
---
:100644 100644 6e44025... a2d69aa... M drivers/mmc/host/omap_hsmmc.c
drivers/mmc/host/omap_hsmmc.c | 79 ++---
1 file changed, 74 insertions(+), 5 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 6e44025..a2d69aa 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -183,6 +183,12 @@ struct omap_hsmmc_host {
struct omap_hsmmc_next next_data;
struct omap_mmc_platform_data *pdata;
+
+ /* Three pin states - default, idle sleep */
+ struct pinctrl *pinctrl;
+ struct pinctrl_state*pins_default;
+ struct pinctrl_state*pins_idle;
+ struct pinctrl_state*pins_sleep;
};
static int omap_hsmmc_card_detect(struct device *dev, int slot)
@@ -1775,7 +1781,6 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
const struct of_device_id *match;
dma_cap_mask_t mask;
unsigned tx_req, rx_req;
- struct pinctrl *pinctrl;
match = of_match_device(of_match_ptr(omap_mmc_of_match), pdev-dev);
if (match) {
@@ -1982,10 +1987,46 @@ static int omap_hsmmc_probe(struct platform_device
*pdev)
omap_hsmmc_disable_irq(host);
- pinctrl = devm_pinctrl_get_select_default(pdev-dev);
- if (IS_ERR(pinctrl))
- dev_warn(pdev-dev,
- pins are not configured from the driver\n);
+ host-pinctrl = devm_pinctrl_get(pdev-dev);
+ if (!IS_ERR(host-pinctrl)) {
+ host-pins_default = pinctrl_lookup_state(host-pinctrl,
+ PINCTRL_STATE_DEFAULT);
+ if (IS_ERR(host-pins_default))
+ dev_dbg(pdev-dev, could not get default pinstate\n);
+ else
+ if (pinctrl_select_state(host-pinctrl,
+host-pins_default))
+ dev_err(pdev-dev,
+ could not set default pinstate\n);
+
+ host-pins_idle = pinctrl_lookup_state(host-pinctrl,
+ PINCTRL_STATE_IDLE);
+ if (IS_ERR(host-pins_idle))
+ dev_dbg(pdev-dev, could not get idle pinstate\n);
+ else
+ /* If possible, let's idle until the first transfer */
+ if (pinctrl_select_state(host-pinctrl,
+host-pins_idle))
+ dev_err(pdev-dev,
+ could not set idle pinstate\n);
+
+ host-pins_sleep = pinctrl_lookup_state(host-pinctrl,
+ PINCTRL_STATE_SLEEP);
+ if (IS_ERR(host-pins_sleep))
+ dev_dbg(pdev-dev, could not get sleep pinstate\n);
+ } else {
+ /*
+ * Since we continue even when pinctrl node is not found,
+ * Invalidate pins as not available. This is to make sure that
+ * IS_ERR(pins_xxx) results in failure when used.
+ */
+ host-pins_default = ERR_PTR(-ENODATA);
+ host-pins_idle = ERR_PTR(-ENODATA);
+ host-pins_sleep = ERR_PTR(-ENODATA);
+
+ dev_dbg(pdev-dev, did not get pins for mmc error: %li\n,
+ PTR_ERR(host-pinctrl));
+ }
omap_hsmmc_protect_card(host);
@@ -2135,6 +2176,12 @@ static int omap_hsmmc_suspend(struct device *dev)
clk_disable_unprepare(host-dbclk);
err:
pm_runtime_put_sync(host-dev);
+
+ /* Optionally let pins go into sleep states */
+ if (!IS_ERR(host-pins_sleep))
+ if (pinctrl_select_state(host-pinctrl, host-pins_sleep))
+ dev_err(dev
RE: [net-next resend PATCH 1/6] net: cpsw: enhance pinctrl support
On Thu, May 23, 2013 at 12:27:41, David Miller wrote: From: Mugunthan V N mugunthan...@ti.com Date: Tue, 21 May 2013 15:24:58 +0530 + priv-pins_default = pinctrl_lookup_state(priv-pinctrl, + PINCTRL_STATE_DEFAULT); This is not indented correctly. Argument on the second, and subsequent, lines of a function call must start at the first column after the openning parenthesis of the function call itself. Well, if I am correct, doing so will make the line cross 80 character limit. If you could (please I ask), can you let me know how it can be handled in above situation. I will make the changes/corrections and re-send it. Thanks a lot in advance. Please audit for this problem in your entire patch series, fix it up, and resubmit the full set of patches. Thanks. Regards, Gururaja -- 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] spi/omap2: Let device core handle pinctrl
On Fri, May 10, 2013 at 15:26:29, Mark Brown wrote: On Tue, May 07, 2013 at 10:47:31AM +, Hebbar, Gururaja wrote: On Tue, May 07, 2013 at 14:25:35, Mark Brown wrote: There's also been some discussion about factoring out the suspend/resume code since it's going to get equally repetitive. Really. Any link/referenceso that I can follow. But I think each module will have its own work to do. May be I can confirm once I look at the factoring-out discussion. It was part of the threads where the idea of adding the helper for the boilerplate stuff to the core was discussed initially IIRC. Ok. Thanks. I will check for it. I will be submitting a patch to enhance the existing pinctrl support for spi omap2 shortly which does above work. How soon is shortly? Since I am adding this Pinctrl PM mode support to many other drivers (i2c, cpsw, da8xx-fb, hsmmc, ti-pwm, usb ...), I would say Shortly = 1 week - 10 days. Well, I guess I'll keep the patch for now and drop it when you send out the PM code. Fair enough. Regards, Gururaja -- 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] spi/omap2: Let device core handle pinctrl
On Tue, May 07, 2013 at 14:25:35, Mark Brown wrote:
On Tue, May 07, 2013 at 03:56:09AM +, Hebbar, Gururaja wrote:
There are cases where driver('s) needs to place pin-mux's to sleep on
suspend
default/idle on resume. For such cases Pinctrl needs to be handled inside
the driver. Example [1].
Well, obviously - but at the minute the driver is pure boilerplate.
Correct.
There's also been some discussion about factoring out the suspend/resume
code since it's going to get equally repetitive.
Really. Any link/referenceso that I can follow.
But I think each module will have its own work to do. May be I can confirm once
I look at the factoring-out discussion.
I will be submitting a patch to enhance the existing pinctrl support for
spi omap2 shortly which does above work.
How soon is shortly?
Since I am adding this Pinctrl PM mode support to many other drivers (i2c,
cpsw, da8xx-fb, hsmmc, ti-pwm, usb ...), I would say Shortly = 1 week - 10 days.
Regards,
Gururaja
--
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] spi/omap2: Let device core handle pinctrl
On Tue, May 07, 2013 at 01:06:38, Mark Brown wrote:
Since commit ab78029 (drivers/pinctrl: grab default handles from device
core) we can rely on device core for handling pinctrl so remove
devm_pinctrl_get_select_default() from the driver.
NACK.
There are cases where driver('s) needs to place pin-mux's to sleep on suspend
default/idle on resume. For such cases Pinctrl needs to be handled inside
the driver. Example [1].
I will be submitting a patch to enhance the existing pinctrl support for
spi omap2 shortly which does above work.
Regards
Gururaja
[1]
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/spi/spi-pl022.c
pl022_suspend_resources() pl022_resume_resources()
Signed-off-by: Mark Brown broo...@opensource.wolfsonmicro.com
---
drivers/spi/spi-omap2-mcspi.c |7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index 893c3d7..3777bd5 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -38,7 +38,6 @@
#include linux/pm_runtime.h
#include linux/of.h
#include linux/of_device.h
-#include linux/pinctrl/consumer.h
#include linux/spi/spi.h
@@ -1170,7 +1169,6 @@ static int omap2_mcspi_probe(struct platform_device
*pdev)
static int bus_num = 1;
struct device_node *node = pdev-dev.of_node;
const struct of_device_id *match;
- struct pinctrl *pinctrl;
master = spi_alloc_master(pdev-dev, sizeof *mcspi);
if (master == NULL) {
@@ -1268,11 +1266,6 @@ static int omap2_mcspi_probe(struct platform_device
*pdev)
if (status 0)
goto dma_chnl_free;
- pinctrl = devm_pinctrl_get_select_default(pdev-dev);
- if (IS_ERR(pinctrl))
- dev_warn(pdev-dev,
- pins are not configured from the driver\n);
-
pm_runtime_use_autosuspend(pdev-dev);
pm_runtime_set_autosuspend_delay(pdev-dev, SPI_AUTOSUSPEND_TIMEOUT);
pm_runtime_enable(pdev-dev);
--
1.7.10.4
--
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
Regards,
Gururaja
--
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] ARM: OMAP2: am33xx-hwmod: Fix register offset NULL check bug
On Thu, Jan 31, 2013 at 12:58:36, Koen Kooi wrote:
Op 30 jan. 2013, om 15:39 heeft Hebbar Gururaja gururaja.heb...@ti.com het
volgende geschreven:
am33xx_cm_wait_module_ready() checks if register offset is NULL.
int am33xx_cm_wait_module_ready(u16 inst, s16 cdoffs, u16 clkctrl_offs)
{
int i = 0;
if (!clkctrl_offs)
return 0;
In case of AM33xx, CLKCTRL register offset for different clock domains
are not uniformly placed. An example of this would be the RTC clock
domain with CLKCTRL offset at 0x00.
In such cases the module ready check is skipped which leads to a data
abort during boot-up when RTC registers is accessed.
Remove this check here to avoid checking module readiness for modules
with clkctrl register offset at 0x00.
Signed-off-by: Hebbar Gururaja gururaja.heb...@ti.com
I can confirm that this fixes the crash on boot with CONFIG_RTC_DRV_OMAP=y
with 3.8-rc5
Could you please share the crash log for my reference?
regards,
Koen
Regards,
Gururaja
--
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 v2 1/2] ARM: OMAP2+: AM33xx: hwmod: add missing HWMOD_NO_IDLEST flags
struct omap_hwmod records belonging to wkup m3 domain is missing
HWMOD_NO_IDLEST flags; add them.
Signed-off-by: Hebbar Gururaja gururaja.heb...@ti.com
---
Change in v2:
- new patch
:100644 100644 646c14d... 1ab693e... M
arch/arm/mach-omap2/omap_hwmod_33xx_data.c
arch/arm/mach-omap2/omap_hwmod_33xx_data.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index 646c14d..1ab693e 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -262,7 +262,8 @@ static struct omap_hwmod am33xx_wkup_m3_hwmod = {
.name = wkup_m3,
.class = am33xx_wkup_m3_hwmod_class,
.clkdm_name = l4_wkup_aon_clkdm,
- .flags = HWMOD_INIT_NO_RESET, /* Keep hardreset asserted */
+ /* Keep hardreset asserted */
+ .flags = HWMOD_INIT_NO_RESET | HWMOD_NO_IDLEST,
.mpu_irqs = am33xx_wkup_m3_irqs,
.main_clk = dpll_core_m4_div2_ck,
.prcm = {
--
1.7.9.5
--
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 v2 2/2] ARM: OMAP2: am33xx-hwmod: Fix register offset NULL check bug
am33xx_cm_wait_module_ready() checks if register offset is NULL.
int am33xx_cm_wait_module_ready(u16 inst, s16 cdoffs, u16 clkctrl_offs)
{
int i = 0;
if (!clkctrl_offs)
return 0;
In case of AM33xx, CLKCTRL register offset for different clock domains
are not uniformly placed. An example of this would be the RTC clock
domain with CLKCTRL offset at 0x00.
In such cases the module ready check is skipped which leads to a data
abort during boot-up when RTC registers is accessed.
Remove this check here to avoid checking module readiness for modules
with clkctrl register offset at 0x00.
Signed-off-by: Hebbar Gururaja gururaja.heb...@ti.com
---
Change in v2:
- No change
:100644 100644 058ce3c... 325a515... M arch/arm/mach-omap2/cm33xx.c
arch/arm/mach-omap2/cm33xx.c |3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm/mach-omap2/cm33xx.c b/arch/arm/mach-omap2/cm33xx.c
index 058ce3c..325a515 100644
--- a/arch/arm/mach-omap2/cm33xx.c
+++ b/arch/arm/mach-omap2/cm33xx.c
@@ -241,9 +241,6 @@ int am33xx_cm_wait_module_ready(u16 inst, s16 cdoffs, u16
clkctrl_offs)
{
int i = 0;
- if (!clkctrl_offs)
- return 0;
-
omap_test_timeout(_is_module_ready(inst, cdoffs, clkctrl_offs),
MAX_MODULE_READY_TIME, i);
--
1.7.9.5
--
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 v2 0/2] ARM: OMAP2+: AM33xx: fix hwmod Clock Control Module
1. Add add missing HWMOD_NO_IDLEST flags 2. Fix register offset NULL check bug Changes in v2: - As per Paul's suggestion 1st add HWMOD_NO_IDLEST flag where it is necessary and then correct the clock control register offset check bug. Hebbar Gururaja (2): ARM: OMAP2+: AM33xx: hwmod: add missing HWMOD_NO_IDLEST flags ARM: OMAP2: am33xx-hwmod: Fix register offset NULL check bug arch/arm/mach-omap2/cm33xx.c |3 --- arch/arm/mach-omap2/omap_hwmod_33xx_data.c |3 ++- 2 files changed, 2 insertions(+), 4 deletions(-) -- 1.7.9.5 -- 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 v2 1/2] ARM: OMAP2+: AM33xx: hwmod: add missing HWMOD_NO_IDLEST flags
On Thu, Jan 31, 2013 at 20:58:24, Paul Walmsley wrote:
Hi
On Thu, 31 Jan 2013, Hebbar Gururaja wrote:
struct omap_hwmod records belonging to wkup m3 domain is missing
HWMOD_NO_IDLEST flags; add them.
Signed-off-by: Hebbar Gururaja gururaja.heb...@ti.com
I've modified this patch to add some more description of why it's needed
as a fix, and queued it for v3.8-rc fixes.
Updated patch follows.
Thanks for the review update.
Regards,
Gururaja
- Paul
From: Hebbar Gururaja gururaja.heb...@ti.com
Date: Thu, 31 Jan 2013 19:55:26 +0530
Subject: [PATCH] ARM: OMAP2+: AM33xx: hwmod: add missing HWMOD_NO_IDLEST
flags
struct omap_hwmod records belonging to wkup m3 domain is missing
HWMOD_NO_IDLEST flags; add them.
This patch is a prerequisite for a subsequent patch, 'ARM: OMAP2:
am33xx-hwmod: Fix register offset NULL check bug'. That patch would
otherwise attempt to read from reserved bits.
Signed-off-by: Hebbar Gururaja gururaja.heb...@ti.com
[p...@pwsan.com: add some more explanation in the patch description]
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/omap_hwmod_33xx_data.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index 646c14d..1ab693e 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -262,7 +262,8 @@ static struct omap_hwmod am33xx_wkup_m3_hwmod = {
.name = wkup_m3,
.class = am33xx_wkup_m3_hwmod_class,
.clkdm_name = l4_wkup_aon_clkdm,
- .flags = HWMOD_INIT_NO_RESET, /* Keep hardreset asserted */
+ /* Keep hardreset asserted */
+ .flags = HWMOD_INIT_NO_RESET | HWMOD_NO_IDLEST,
.mpu_irqs = am33xx_wkup_m3_irqs,
.main_clk = dpll_core_m4_div2_ck,
.prcm = {
--
1.7.10.4
--
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 v2 2/2] ARM: OMAP2: am33xx-hwmod: Fix register offset NULL check bug
On Thu, Jan 31, 2013 at 21:00:32, Paul Walmsley wrote:
+ Koen
Hi
On Thu, 31 Jan 2013, Hebbar Gururaja wrote:
am33xx_cm_wait_module_ready() checks if register offset is NULL.
int am33xx_cm_wait_module_ready(u16 inst, s16 cdoffs, u16 clkctrl_offs)
{
int i = 0;
if (!clkctrl_offs)
return 0;
In case of AM33xx, CLKCTRL register offset for different clock domains
are not uniformly placed. An example of this would be the RTC clock
domain with CLKCTRL offset at 0x00.
In such cases the module ready check is skipped which leads to a data
abort during boot-up when RTC registers is accessed.
Remove this check here to avoid checking module readiness for modules
with clkctrl register offset at 0x00.
Signed-off-by: Hebbar Gururaja gururaja.heb...@ti.com
Some text has been added to the patch description to describe Koen's test
results, and the updated patch has been queued for v3.8-rc fixes. Updated
patch follows.
- Paul
Thanks for the review update.
Regards,
Gururaja
From: Hebbar Gururaja gururaja.heb...@ti.com
Date: Thu, 31 Jan 2013 19:55:27 +0530
Subject: [PATCH] ARM: OMAP2: am33xx-hwmod: Fix register offset NULL check
bug
am33xx_cm_wait_module_ready() checks if register offset is NULL.
int am33xx_cm_wait_module_ready(u16 inst, s16 cdoffs, u16 clkctrl_offs)
{
int i = 0;
if (!clkctrl_offs)
return 0;
In case of AM33xx, CLKCTRL register offset for different clock domains
are not uniformly placed. An example of this would be the RTC clock
domain with CLKCTRL offset at 0x00.
In such cases the module ready check is skipped which leads to a data
abort during boot-up when RTC registers is accessed.
Remove this check here to avoid checking module readiness for modules
with clkctrl register offset at 0x00.
Koen Kooi notes that this patch fixes a crash on boot with
CONFIG_RTC_DRV_OMAP=y with v3.8-rc5.
Signed-off-by: Hebbar Gururaja gururaja.heb...@ti.com
Cc: Koen Kooi k...@dominion.thruhere.net
[p...@pwsan.com: noted Koen's test in the patch description]
Signed-off-by: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/cm33xx.c |3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm/mach-omap2/cm33xx.c b/arch/arm/mach-omap2/cm33xx.c
index 058ce3c..325a515 100644
--- a/arch/arm/mach-omap2/cm33xx.c
+++ b/arch/arm/mach-omap2/cm33xx.c
@@ -241,9 +241,6 @@ int am33xx_cm_wait_module_ready(u16 inst, s16 cdoffs, u16
clkctrl_offs)
{
int i = 0;
- if (!clkctrl_offs)
- return 0;
-
omap_test_timeout(_is_module_ready(inst, cdoffs, clkctrl_offs),
MAX_MODULE_READY_TIME, i);
--
1.7.10.4
--
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 v2] ARM: OMAP2: hwmod: Fix register offset NULL check bug
On Thu, Dec 20, 2012 at 13:05:27, Paul Walmsley wrote: On Thu, 20 Dec 2012, Hebbar, Gururaja wrote: On Wed, Dec 19, 2012 at 07:43:50, Paul Walmsley wrote: We've got a few hwmods on OMAP44xx that don't have clkctrl_offs registers listed in the hwmod data, and which are not marked with HWMOD_NO_IDLEST. What's going to happen in those cases? Hmm. This is a special case to me. Let me go back and do some review. Will be back with some more details. Probably what needs to happen is that those hwmods need to be marked with HWMOD_NO_IDLEST, in a separate patch before yours. As far as I can tell, that's how they should have been marked initially. Then your patch should be fine. Looking at latest kernel v3.8-rc5, there is separate cm33xx.c file which handles module ready checking for am33xx platform. So I will update this patch to work on this file instead of touching omap4 related file (cminst44xx.c) - Paul Regards, Gururaja -- 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] ARM: OMAP2: am33xx-hwmod: Fix register offset NULL check bug
am33xx_cm_wait_module_ready() checks if register offset is NULL.
int am33xx_cm_wait_module_ready(u16 inst, s16 cdoffs, u16 clkctrl_offs)
{
int i = 0;
if (!clkctrl_offs)
return 0;
In case of AM33xx, CLKCTRL register offset for different clock domains
are not uniformly placed. An example of this would be the RTC clock
domain with CLKCTRL offset at 0x00.
In such cases the module ready check is skipped which leads to a data
abort during boot-up when RTC registers is accessed.
Remove this check here to avoid checking module readiness for modules
with clkctrl register offset at 0x00.
Signed-off-by: Hebbar Gururaja gururaja.heb...@ti.com
---
Changes in v3:
- Since now there is separate cm33xx.c file which handles module
ready checking for am33xx platform, use the same for the fix.
- Also update subject to indicate am33xx platform name
Changes in v2:
- update commit message to reflect the actual cause. Previous
message conveyed a wrong/opposite message.
:100644 100644 058ce3c... 325a515... M arch/arm/mach-omap2/cm33xx.c
arch/arm/mach-omap2/cm33xx.c |3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm/mach-omap2/cm33xx.c b/arch/arm/mach-omap2/cm33xx.c
index 058ce3c..325a515 100644
--- a/arch/arm/mach-omap2/cm33xx.c
+++ b/arch/arm/mach-omap2/cm33xx.c
@@ -241,9 +241,6 @@ int am33xx_cm_wait_module_ready(u16 inst, s16 cdoffs, u16
clkctrl_offs)
{
int i = 0;
- if (!clkctrl_offs)
- return 0;
-
omap_test_timeout(_is_module_ready(inst, cdoffs, clkctrl_offs),
MAX_MODULE_READY_TIME, i);
--
1.7.9.5
--
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 v2] ARM: OMAP2: hwmod: Fix register offset NULL check bug
On Wed, Jan 30, 2013 at 22:09:51, Paul Walmsley wrote: On Wed, 30 Jan 2013, Hebbar, Gururaja wrote: On Thu, Dec 20, 2012 at 13:05:27, Paul Walmsley wrote: On Thu, 20 Dec 2012, Hebbar, Gururaja wrote: On Wed, Dec 19, 2012 at 07:43:50, Paul Walmsley wrote: We've got a few hwmods on OMAP44xx that don't have clkctrl_offs registers listed in the hwmod data, and which are not marked with HWMOD_NO_IDLEST. What's going to happen in those cases? Hmm. This is a special case to me. Let me go back and do some review. Will be back with some more details. Probably what needs to happen is that those hwmods need to be marked with HWMOD_NO_IDLEST, in a separate patch before yours. As far as I can tell, that's how they should have been marked initially. Then your patch should be fine. Looking at latest kernel v3.8-rc5, there is separate cm33xx.c file which handles module ready checking for am33xx platform. So I will update this patch to work on this file instead of touching omap4 related file (cminst44xx.c) The same problem still exists. According to the TRM, there's at least one AM335x CLKCTRL register that doesn't have IDLEST bits. So to avoid reading reserved bits, either this patch or a preceding patch should mark those hwmods with HWMOD_NO_IDLEST. Ok. I will look into this now. - Paul Regards, Gururaja -- 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 01/14] ARM: davinci: move private EDMA API to arm/common
On Fri, Jan 11, 2013 at 11:18:37, Porter, Matt wrote:
Move mach-davinci/dma.c to common/edma.c so it can be used
by OMAP (specifically AM33xx) as well. This just moves the
private EDMA API and enables it to build on OMAP.
Signed-off-by: Matt Porter mpor...@ti.com
---
arch/arm/Kconfig |1 +
arch/arm/common/Kconfig|3 +
arch/arm/common/Makefile |1 +
arch/arm/{mach-davinci/dma.c = common/edma.c} |2 +-
arch/arm/mach-davinci/Makefile |2 +-
arch/arm/mach-davinci/board-tnetv107x-evm.c|2 +-
arch/arm/mach-davinci/davinci.h|2 +-
arch/arm/mach-davinci/devices-tnetv107x.c |2 +-
arch/arm/mach-davinci/devices.c|7 +-
arch/arm/mach-davinci/dm355.c |2 +-
arch/arm/mach-davinci/dm365.c |2 +-
arch/arm/mach-davinci/dm644x.c |2 +-
arch/arm/mach-davinci/dm646x.c |2 +-
arch/arm/mach-davinci/include/mach/da8xx.h |2 +-
arch/arm/mach-davinci/include/mach/edma.h | 267
arch/arm/plat-omap/Kconfig |1 +
drivers/dma/edma.c |2 +-
drivers/mmc/host/davinci_mmc.c |1 +
include/linux/mfd/davinci_voicecodec.h |3 +-
include/linux/platform_data/edma.h | 182
Headers file are just moved here. So git mv file1 flie2; and the git
format-patch -C on commit should just generate few lines of patch.
include/linux/platform_data/spi-davinci.h |2 +-
sound/soc/davinci/davinci-evm.c|1 +
sound/soc/davinci/davinci-pcm.c|1 +
sound/soc/davinci/davinci-pcm.h|2 +-
sound/soc/davinci/davinci-sffsdr.c |6 +-
25 files changed, 212 insertions(+), 288 deletions(-)
rename arch/arm/{mach-davinci/dma.c = common/edma.c} (99%)
delete mode 100644 arch/arm/mach-davinci/include/mach/edma.h
create mode 100644 include/linux/platform_data/edma.h
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 67874b8..7637d31 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -932,6 +932,7 @@ config ARCH_DAVINCI
select GENERIC_IRQ_CHIP
select HAVE_IDE
select NEED_MACH_GPIO_H
+ select TI_PRIV_EDMA
select USE_OF
select ZONE_DMA
help
diff --git a/arch/arm/common/Kconfig b/arch/arm/common/Kconfig
index 45ceeb0..9e32d0d 100644
--- a/arch/arm/common/Kconfig
+++ b/arch/arm/common/Kconfig
@@ -40,3 +40,6 @@ config SHARP_PARAM
config SHARP_SCOOP
bool
+
+config TI_PRIV_EDMA
+ bool
diff --git a/arch/arm/common/Makefile b/arch/arm/common/Makefile
index e8a4e58..d09a39b 100644
--- a/arch/arm/common/Makefile
+++ b/arch/arm/common/Makefile
@@ -13,3 +13,4 @@ obj-$(CONFIG_SHARP_PARAM) += sharpsl_param.o
obj-$(CONFIG_SHARP_SCOOP)+= scoop.o
obj-$(CONFIG_PCI_HOST_ITE8152) += it8152.o
obj-$(CONFIG_ARM_TIMER_SP804)+= timer-sp.o
+obj-$(CONFIG_TI_PRIV_EDMA) += edma.o
diff --git a/arch/arm/mach-davinci/dma.c b/arch/arm/common/edma.c
similarity index 99%
rename from arch/arm/mach-davinci/dma.c
rename to arch/arm/common/edma.c
index a685e97..4411087 100644
--- a/arch/arm/mach-davinci/dma.c
+++ b/arch/arm/common/edma.c
@@ -25,7 +25,7 @@
#include linux/io.h
#include linux/slab.h
-#include mach/edma.h
+#include linux/platform_data/edma.h
/* Offsets matching struct edmacc_param */
#define PARM_OPT 0x00
diff --git a/arch/arm/mach-davinci/Makefile b/arch/arm/mach-davinci/Makefile
index fb5c1aa..493a36b 100644
--- a/arch/arm/mach-davinci/Makefile
+++ b/arch/arm/mach-davinci/Makefile
@@ -5,7 +5,7 @@
# Common objects
obj-y:= time.o clock.o serial.o psc.o \
-dma.o usb.o common.o sram.o aemif.o
+usb.o common.o sram.o aemif.o
obj-$(CONFIG_DAVINCI_MUX)+= mux.o
diff --git a/arch/arm/mach-davinci/board-tnetv107x-evm.c
b/arch/arm/mach-davinci/board-tnetv107x-evm.c
index be30997..86f55ba 100644
--- a/arch/arm/mach-davinci/board-tnetv107x-evm.c
+++ b/arch/arm/mach-davinci/board-tnetv107x-evm.c
@@ -26,12 +26,12 @@
#include linux/input.h
#include linux/input/matrix_keypad.h
#include linux/spi/spi.h
+#include linux/platform_data/edma.h
#include asm/mach/arch.h
#include asm/mach-types.h
#include mach/irqs.h
-#include mach/edma.h
#include mach/mux.h
#include mach/cp_intc.h
#include mach/tnetv107x.h
diff --git a/arch/arm/mach-davinci/davinci.h b/arch/arm/mach-davinci/davinci.h
index 12d544b..d26a6bc 100644
--- a/arch/arm/mach-davinci/davinci.h
+++ b/arch/arm/mach-davinci/davinci.h
@@ -23,9 +23,9 @@
#include linux/platform_device.h
#include linux/spi/spi.h
#include linux/platform_data/davinci_asp.h
RE: [PATCH v4 05/14] dmaengine: edma: Add TI EDMA device tree binding
On Fri, Jan 11, 2013 at 11:18:41, Porter, Matt wrote:
The binding definition is based on the generic DMA controller
binding.
Signed-off-by: Matt Porter mpor...@ti.com
---
Documentation/devicetree/bindings/dma/ti-edma.txt | 51
+
1 file changed, 51 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/ti-edma.txt
diff --git a/Documentation/devicetree/bindings/dma/ti-edma.txt
b/Documentation/devicetree/bindings/dma/ti-edma.txt
new file mode 100644
index 000..3344345
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/ti-edma.txt
@@ -0,0 +1,51 @@
+TI EDMA
+
+Required properties:
+- compatible : ti,edma3
+- ti,hwmods: Name of the hwmods associated to the EDMA
+- ti,edma-regions: Number of regions
+- ti,edma-slots: Number of slots
+- ti,edma-queue-tc-map: List of transfer control to queue mappings
+- ti,edma-queue-priority-map: List of queue priority mappings
+- ti,edma-default-queue: Default queue value
+
+Optional properties:
+- ti,edma-reserved-channels: List of reserved channel regions
+- ti,edma-reserved-slots: List of reserved slot regions
+- ti,edma-xbar-event-map: Crossbar event to channel map
+
+Example:
+
+edma: edma@4900 {
+ #address-cells = 1;
+ #size-cells = 0;
address-cells size-cells are only required when current node is a parent
node it has sibling/child nodes (that too if the child node uses reg
property).
+ reg = 0x4900 0x1;
+ interrupt-parent = intc;
+ interrupts = 12 13 14;
+ compatible = ti,edma3;
+ ti,hwmods = tpcc, tptc0, tptc1, tptc2;
+ #dma-cells = 1;
+ dma-channels = 64;
+ ti,edma-regions = 4;
+ ti,edma-slots = 256;
+ ti,edma-reserved-channels = 0 2
+ 14 2
+ 26 6
+ 48 4
+ 56 8;
+ ti,edma-reserved-slots = 0 2
+ 14 2
+ 26 6
+ 48 4
+ 56 8
+ 64 127;
+ ti,edma-queue-tc-map = 0 0
+ 1 1
+ 2 2;
+ ti,edma-queue-priority-map = 0 0
+ 1 1
+ 2 2;
+ ti,edma-default-queue = 0;
+ ti,edma-xbar-event-map = 1 12
+ 2 13;
+};
--
1.7.9.5
___
Davinci-linux-open-source mailing list
davinci-linux-open-sou...@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Regards,
Gururaja
--
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 v3 13/16] ARM: dts: add AM33XX MMC support
Matt, On Thu, Oct 18, 2012 at 18:56:52, Porter, Matt wrote: Adds AM33XX MMC support for am335x-bone and am335x-evm. I want to test Suspend/Resume feature on omap hsmmc driver. Do you any tree based on mainline kernel v3.8-rc1 with these edma mmc patches. Signed-off-by: Matt Porter mpor...@ti.com --- arch/arm/boot/dts/am335x-bone.dts |6 ++ arch/arm/boot/dts/am335x-evm.dts |6 ++ arch/arm/boot/dts/am33xx.dtsi | 27 +++ 3 files changed, 39 insertions(+) ..snip.. ..snip.. ..snip.. Regards, Gururaja -- 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 v2] ARM: OMAP2: hwmod: Fix register offset NULL check bug
On Wed, Dec 19, 2012 at 07:43:50, Paul Walmsley wrote:
On Tue, 18 Dec 2012, Hebbar Gururaja wrote:
From: Hebbar, Gururaja gururaja.heb...@ti.com
omap4_cminst_wait_module_ready() checks if register offset is NULL.
int omap4_cminst_wait_module_ready(u8 part, u16 inst, s16 cdoffs,
u16 clkctrl_offs)
{
int i = 0;
if (!clkctrl_offs)
return 0;
In case of AM33xx, CLKCTRL register offset for different clock domains
are not uniformly placed. An example of this would be the RTC clock
domain with CLKCTRL offset at 0x00.
In such cases the module ready check is skipped which leads to a data
abort during boot-up when RTC registers is accessed.
We've got a few hwmods on OMAP44xx that don't have clkctrl_offs registers
listed in the hwmod data, and which are not marked with HWMOD_NO_IDLEST.
What's going to happen in those cases?
Hmm. This is a special case to me. Let me go back and do some review.
Will be back with some more details.
- Paul
Regards,
Gururaja
--
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] ARM: OMAP2: hwmod: Fix register offset NULL check bug
From: Hebbar, Gururaja gururaja.heb...@ti.com
omap4_cminst_wait_module_ready() checks if register offset is NULL.
int omap4_cminst_wait_module_ready(u8 part, u16 inst, s16 cdoffs,
u16 clkctrl_offs)
{
int i = 0;
if (!clkctrl_offs)
return 0;
In case of AM33xx, not all clock domains have CLKSTCTRL at 0x00. An
example of this would be the RTC clock domain. In such cases the
module ready check is skipped which leads to a data abort during bootup
when RTC registers is accessed.
Since the actual base address is verified in
omap4_cminst_read_inst_reg(), this check here is not required at all
and hence can be removed.
Signed-off-by: Hebbar, Gururaja gururaja.heb...@ti.com
---
:100644 100644 7f9a464... 40545ff... M arch/arm/mach-omap2/cminst44xx.c
arch/arm/mach-omap2/cminst44xx.c |3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm/mach-omap2/cminst44xx.c b/arch/arm/mach-omap2/cminst44xx.c
index 7f9a464..40545ff 100644
--- a/arch/arm/mach-omap2/cminst44xx.c
+++ b/arch/arm/mach-omap2/cminst44xx.c
@@ -271,9 +271,6 @@ int omap4_cminst_wait_module_ready(u8 part, u16 inst, s16
cdoffs,
{
int i = 0;
- if (!clkctrl_offs)
- return 0;
-
omap_test_timeout(_is_module_ready(part, inst, cdoffs, clkctrl_offs),
MAX_MODULE_READY_TIME, i);
--
1.7.9.5
--
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] ARM: OMAP2: hwmod: Fix register offset NULL check bug
On Tue, Dec 18, 2012 at 18:01:43, Balbi, Felipe wrote:
Hi,
On Tue, Dec 18, 2012 at 06:02:09PM +0530, Hebbar Gururaja wrote:
From: Hebbar, Gururaja gururaja.heb...@ti.com
omap4_cminst_wait_module_ready() checks if register offset is NULL.
int omap4_cminst_wait_module_ready(u8 part, u16 inst, s16 cdoffs,
u16 clkctrl_offs)
{
int i = 0;
if (!clkctrl_offs)
return 0;
In case of AM33xx, not all clock domains have CLKSTCTRL at 0x00. An
example of this would be the RTC clock domain. In such cases the
module ready check is skipped which leads to a data abort during bootup
when RTC registers is accessed.
Since the actual base address is verified in
omap4_cminst_read_inst_reg(), this check here is not required at all
and hence can be removed.
Signed-off-by: Hebbar, Gururaja gururaja.heb...@ti.com
---
:100644 100644 7f9a464... 40545ff... M arch/arm/mach-omap2/cminst44xx.c
arch/arm/mach-omap2/cminst44xx.c |3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm/mach-omap2/cminst44xx.c
b/arch/arm/mach-omap2/cminst44xx.c
index 7f9a464..40545ff 100644
--- a/arch/arm/mach-omap2/cminst44xx.c
+++ b/arch/arm/mach-omap2/cminst44xx.c
@@ -271,9 +271,6 @@ int omap4_cminst_wait_module_ready(u8 part, u16 inst,
s16 cdoffs,
{
int i = 0;
- if (!clkctrl_offs)
- return 0;
looks like commit log has the wrong argument. I believe you meant to say
that AM33xx has CLKSTCTRL exactly at 0x00 and that's why this check has
to be removed. No ?
Correct. Thanks for the correction. V2 on the way.
--
balbi
Regards,
Gururaja
--
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 v2] ARM: OMAP2: hwmod: Fix register offset NULL check bug
From: Hebbar, Gururaja gururaja.heb...@ti.com
omap4_cminst_wait_module_ready() checks if register offset is NULL.
int omap4_cminst_wait_module_ready(u8 part, u16 inst, s16 cdoffs,
u16 clkctrl_offs)
{
int i = 0;
if (!clkctrl_offs)
return 0;
In case of AM33xx, CLKCTRL register offset for different clock domains
are not uniformly placed. An example of this would be the RTC clock
domain with CLKCTRL offset at 0x00.
In such cases the module ready check is skipped which leads to a data
abort during boot-up when RTC registers is accessed.
Since the actual base address is verified in
omap4_cminst_read_inst_reg(), this check here is not required at all
and hence can be removed.
Signed-off-by: Hebbar, Gururaja gururaja.heb...@ti.com
---
Changes in v2:
- update commit message to reflect the actual cause. Previous
message conveyed a wrong/opposite message.
:100644 100644 7f9a464... 40545ff... M arch/arm/mach-omap2/cminst44xx.c
arch/arm/mach-omap2/cminst44xx.c |3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm/mach-omap2/cminst44xx.c b/arch/arm/mach-omap2/cminst44xx.c
index 7f9a464..40545ff 100644
--- a/arch/arm/mach-omap2/cminst44xx.c
+++ b/arch/arm/mach-omap2/cminst44xx.c
@@ -271,9 +271,6 @@ int omap4_cminst_wait_module_ready(u8 part, u16 inst, s16
cdoffs,
{
int i = 0;
- if (!clkctrl_offs)
- return 0;
-
omap_test_timeout(_is_module_ready(part, inst, cdoffs, clkctrl_offs),
MAX_MODULE_READY_TIME, i);
--
1.7.9.5
--
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 v3 00/16] DMA Engine support for AM33XX
On Thu, Oct 18, 2012 at 18:56:39, Porter, Matt wrote: ...snip... ...snip... ...snip... This series adds DMA Engine support for AM33xx, which uses an EDMA DMAC. The EDMA DMAC has been previously supported by only a private API implementation (much like the situation with OMAP DMA) found on the DaVinci family of SoCs. The series applies on top of 3.7-rc1 and the following patches: - GPMC fails to reserve memory fix: http://www.spinics.net/lists/linux-omap/msg79675.html - TPS65910 regulator fix: https://patchwork.kernel.org/patch/1593651/ - dmaengine DT support from Vinod's dmaengine_dt branch in git://git.infradead.org/users/vkoul/slave-dma.git since 027478851791df751176398be02a3b1c5f6aa824 The approach taken is similar to how OMAP DMA is being converted to DMA Engine support. With the functional EDMA private API already existing in mach-davinci/dma.c, we first move that to an ARM common area so it can be shared. Adding DT and runtime PM support to the private EDMA API implementation allows it to run on AM33xx. AM33xx *only* boots using DT so we leverage Jon's generic DT DMA helpers to register EDMA DMAC with the of_dma framework and then add support for calling the dma_request_slave_channel() API to both the mmc and spi drivers. With this series both BeagleBone and the AM335x EVM have working MMC and SPI support. This is tested on BeagleBone with a SPI framebuffer driver and MMC rootfs. A trivial gpio DMA event misc driver was used to test the crossbar DMA event support. It is also tested on the AM335x EVM with the onboard SPI flash and MMC rootfs. The branch at https://github.com/ohporter/linux/tree/edma-dmaengine-v3 has the complete series, dependencies, and some test drivers/defconfigs. Regression testing was done on AM180x-EVM (which also makes use of the EDMA dmaengine driver and the EDMA private API) using SD, SPI flash, and the onboard audio supported by the ASoC Davinci driver. Since you have tested MMC, and probably will be adding Audio support for AM335x as well, I believe you will also be adding Pin-mux support for both the modules. Can you share your plan to release the next version? I have few patches pending for AM335x Audio (DT related). Thanks in advance Regards Gururaja After this series, the plan is to convert the last in-tree user of the private EDMA API (davinci-pcm/mcasp) and then eliminate the private EDMA API by folding its functionality into drivers/dma/edma.c. Matt Porter (16): dmaengine: edma: fix slave config dependency on direction ARM: davinci: move private EDMA API to arm/common ARM: edma: remove unused transfer controller handlers ARM: edma: add DT and runtime PM support for AM33XX ARM: edma: add AM33XX crossbar event support dmaengine: edma: enable build for AM33XX dmaengine: edma: Add TI EDMA device tree binding ARM: dts: add AM33XX EDMA support dmaengine: add dma_request_slave_channel_compat() mmc: omap_hsmmc: convert to dma_request_slave_channel_compat() mmc: omap_hsmmc: limit max_segs with the EDMA DMAC mmc: omap_hsmmc: add generic DMA request support to the DT binding ARM: dts: add AM33XX MMC support spi: omap2-mcspi: convert to dma_request_slave_channel_compat() spi: omap2-mcspi: add generic DMA request support to the DT binding ARM: dts: add AM33XX SPI support -- 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: discrepancy while save and restore of debounce registers
On Thu, Oct 18, 2012 at 21:44:56, Hunter, Jon wrote: Hi Gururaja, On 10/18/2012 12:31 AM, Hebbar, Gururaja wrote: Jon, On Thu, Oct 18, 2012 at 02:42:01, Hunter, Jon wrote: [snip] My doubt/questions are 1. Why should debounce registers be updated only when it's accessed previously? If debounce is not being used by any of the gpios, then there is no need to restore them as there are no bits set. So this makes sense and saves a couple register writes. What I want to know is that other than saving register writes, is there any other important stuff that specifies this requirement. From a HW perspective, none that I can see. From a SW perspective, yes, as I mentioned if you restore these registers without first initialising the context variables where these registers are stored, then you may be restoring unknown values to the registers and that is bad. 2. What is the relation between updating debounce registers and crash seen on others registers? This I am not sure about. I gave this a quick try on my omap3430 beagle board, but I did not see any side-effects from doing this. However, if you are always restoring the debounce context regardless of whether debounce is being used, then you could be writing bad values to the debounce registers as the context variables bank-context.debouce and bank-context.debouce_en may not initialised. So that is bad. However, that said I am still not sure how this could cause a crash. Can you share more details on ... Sorry for missing below details in first post. 1. The OMAP platform you are using? I was trying this on TI AM335x platform (repo below). On AM335x EVM board http://arago-project.org/git/projects/?p=linux-am33x.git;a=shortlog; h=refs/heads/v3.2-staging 2. What linux distro/environment you are using? Arago AM335x PSP release (linux 3.2 + am335x patch-set) 3. If there are any specific steps to reproduce this 100% of the time? On top of this tree, try suspend/resume using echo mem /syspower/state I have a beagle-bone but unfortunately, suspend does not appear to be supported in the mainline kernel yet so I am unable to test this on the am335x on the mainline. You can try the suspend/resume on BB from Arago tree which I mentioned above Have you compared the gpio driver from your v3.2 branch with the current mainline to see how different this code is? Ideally, it would be good to test on the mainline kernel for another data point to see if this is local to your branch. The mainline kernel omap GPIO driver has changed a lot from current arago tree (which is at v3.2). Upon comparing is when I found out about the register access check done before restoring. Cheers Jon Regards, Gururaja -- 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] mmc: omap_hsmmc: Enable HSPE bit for high speed cards
On Thu, Nov 01, 2012 at 01:46:26, Balbi, Felipe wrote: Hi, On Thu, Nov 01, 2012 at 01:21:36AM +0530, Venkatraman S wrote: On Wed, Oct 31, 2012 at 5:56 PM, Felipe Balbi ba...@ti.com wrote: Hi, On Wed, Oct 31, 2012 at 05:27:36PM +0530, Hebbar, Gururaja wrote: HSMMC IP on AM33xx need a special setting to handle High-speed cards. Other platforms like TI81xx, OMAP4 may need this as-well. This depends on the HSMMC IP timing closure done for the high speed cards. From AM335x TRM (SPRUH73F - 18.3.12 Output Signals Generation) The MMC/SD/SDIO output signals can be driven on either falling edge or rising edge depending on the SD_HCTL[2] HSPE bit. This feature allows to reach better timing performance, and thus to increase data transfer frequency. There are few pre-requisites for enabling the HSPE bit - Controller should support High-Speed-Enable Bit and - Controller should not be using DDR Mode and - Controller should advertise that it supports High Speed in capabilities register and - MMC/SD clock coming out of controller 25MHz Note: The implementation reuses the output of calc_divisor() so as to reduce code addition. Signed-off-by: Hebbar, Gururaja gururaja.heb...@ti.com this looks good to my eyes, hopefully I haven't missed anything: Reviewed-by: Felipe Balbi ba...@ti.com Except for the excessively verbose comments which are just duplicating the code, Quote + * Enable High-Speed Support + * Pre-Requisites + * - Controller should support High-Speed-Enable Bit + * - Controller should not be using DDR Mode + * - Controller should advertise that it supports High Speed + *in capabilities register + * - MMC/SD clock coming out of controller 25MHz + */ /Quote I'm ok with this patch as well. I'm putting a few patches under test including this one, and will send it to Chris as part of that series. I'll strip out the above mentioned comments, unless there are any objections. please don't. Detailing the pre-requisites for getting HSP mode working isn't bad at all. Should someone decide to change the behavior and ends up breaking it, the comment will help putting things back together. my 2 cents, you've got the final decision though. Same here. Description is required in commit message since it will help in during git bisect. -- balbi Regards, Gururaja -- 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: [RESEND PATCH] mmc: omap_hsmmc: Enable HSPE bit for high speed cards
On Wed, Oct 31, 2012 at 11:14:28, Balbi, Felipe wrote:
Hi,
On Wed, Oct 31, 2012 at 06:17:02AM +0100, Hebbar, Gururaja wrote:
On Mon, Oct 29, 2012 at 21:47:19, Balbi, Felipe wrote:
Hi,
On Mon, Oct 29, 2012 at 06:26:48PM +0530, Hebbar, Gururaja wrote:
HSMMC IP on AM33xx need a special setting to handle High-speed cards.
Other platforms like TI81xx, OMAP4 may need this as-well. This depends
on the HSMMC IP timing closure done for the high speed cards.
From AM335x TRM (SPRUH73F - 18.3.12 Output Signals Generation)
The MMC/SD/SDIO output signals can be driven on either falling edge or
rising edge depending on the SD_HCTL[2] HSPE bit. This feature allows
to reach better timing performance, and thus to increase data transfer
frequency.
There are few pre-requisites for enabling the HSPE bit
- Controller should support High-Speed-Enable Bit and
- Controller should not be using DDR Mode and
- Controller should advertise that it supports High Speed in
capabilities register and
- MMC/SD clock coming out of controller 25MHz
Signed-off-by: Hebbar, Gururaja gururaja.heb...@ti.com
---
Rebased on mmc-next (v3.7.0-rc1)
Only Build tested since EDMA support for AM335x is not yet added
:100644 100644 be76a23... ed271fc... M
Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
:100644 100644 8b4e4f2... 346af5b... M
arch/arm/plat-omap/include/plat/mmc.h
:100644 100644 54bfd0c... 3fd95cb... M drivers/mmc/host/omap_hsmmc.c
.../devicetree/bindings/mmc/ti-omap-hsmmc.txt |1 +
arch/arm/plat-omap/include/plat/mmc.h |1 +
drivers/mmc/host/omap_hsmmc.c | 30
+++-
3 files changed, 31 insertions(+), 1 deletions(-)
diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
index be76a23..ed271fc 100644
--- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -19,6 +19,7 @@ ti,dual-volt: boolean, supports dual voltage cards
supply-name examples are vmmc, vmmc_aux etc
ti,non-removable: non-removable slot (like eMMC)
ti,needs-special-reset: Requires a special softreset sequence
+ti,needs-special-hs-handling: HSMMC IP needs special setting for
handling High Speed
can't you do runtime revision detection for this ?
Platforms like AM335x TI814x both use the same IP.
But only AM335x needed this bit to be set in order to sustain high
speed transfers. This was concluded after AM335x HSMMC IP timing
closure was completed for High speed Cards.
fair enough.
Example:
mmc1: mmc@0x4809c000 {
diff --git a/arch/arm/plat-omap/include/plat/mmc.h
b/arch/arm/plat-omap/include/plat/mmc.h
index 8b4e4f2..346af5b 100644
--- a/arch/arm/plat-omap/include/plat/mmc.h
+++ b/arch/arm/plat-omap/include/plat/mmc.h
@@ -126,6 +126,7 @@ struct omap_mmc_platform_data {
/* we can put the features above into this variable */
#define HSMMC_HAS_PBIAS(1 0)
#define HSMMC_HAS_UPDATED_RESET(1 1)
+#define HSMMC_HAS_HSPE_SUPPORT (1 2)
unsigned features;
int switch_pin; /* gpio (card detect) */
diff --git a/drivers/mmc/host/omap_hsmmc.c
b/drivers/mmc/host/omap_hsmmc.c
index 54bfd0c..3fd95cb 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -62,6 +62,7 @@
#define VS18 (1 26)
#define VS30 (1 25)
+#define HSS(1 21)
#define SDVS18 (0x5 9)
#define SDVS30 (0x6 9)
#define SDVS33 (0x7 9)
@@ -89,6 +90,7 @@
#define MSBS (1 5)
#define BCE(1 1)
#define FOUR_BIT (1 1)
+#define HSPE (1 2)
#define DDR(1 19)
#define DW8(1 5)
#define CC 0x1
@@ -489,6 +491,7 @@ static void omap_hsmmc_set_clock(struct
omap_hsmmc_host *host)
struct mmc_ios *ios = host-mmc-ios;
unsigned long regval;
unsigned long timeout;
+ unsigned long clkdiv;
dev_vdbg(mmc_dev(host-mmc), Set clock to %uHz\n, ios-clock);
@@ -496,7 +499,8 @@ static void omap_hsmmc_set_clock(struct
omap_hsmmc_host *host)
regval = OMAP_HSMMC_READ(host-base, SYSCTL);
regval = regval ~(CLKD_MASK | DTO_MASK);
- regval = regval | (calc_divisor(host, ios) 6) | (DTO 16);
+ clkdiv = calc_divisor(host, ios);
+ regval = regval | (clkdiv 6) | (DTO
[RESEND PATCH V2] mmc: omap_hsmmc: Enable HSPE bit for high speed cards
HSMMC IP on AM33xx need a special setting to handle High-speed cards.
Other platforms like TI81xx, OMAP4 may need this as-well. This depends
on the HSMMC IP timing closure done for the high speed cards.
From AM335x TRM (SPRUH73F - 18.3.12 Output Signals Generation)
The MMC/SD/SDIO output signals can be driven on either falling edge or
rising edge depending on the SD_HCTL[2] HSPE bit. This feature allows
to reach better timing performance, and thus to increase data transfer
frequency.
There are few pre-requisites for enabling the HSPE bit
- Controller should support High-Speed-Enable Bit and
- Controller should not be using DDR Mode and
- Controller should advertise that it supports High Speed in
capabilities register and
- MMC/SD clock coming out of controller 25MHz
Note:
The implementation reuses the output of calc_divisor() so as to reduce
code addition.
Signed-off-by: Hebbar, Gururaja gururaja.heb...@ti.com
---
Rebased on mmc-next (v3.7.0-rc1)
Only Build tested since EDMA support for AM335x is not yet added
Changes in V2
- Added note in commit message about code re-use
- replaced ((a BIT(n) == BIT(n))) with (a BIT(n)) since
effectively both are same.
:100644 100644 be76a23... ed271fc... M
Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
:100644 100644 8b4e4f2... 346af5b... M arch/arm/plat-omap/include/plat/mmc.h
:100644 100644 54bfd0c... 5ea4c9d... M drivers/mmc/host/omap_hsmmc.c
.../devicetree/bindings/mmc/ti-omap-hsmmc.txt |1 +
arch/arm/plat-omap/include/plat/mmc.h |1 +
drivers/mmc/host/omap_hsmmc.c | 30 +++-
3 files changed, 31 insertions(+), 1 deletions(-)
diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
index be76a23..ed271fc 100644
--- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -19,6 +19,7 @@ ti,dual-volt: boolean, supports dual voltage cards
supply-name examples are vmmc, vmmc_aux etc
ti,non-removable: non-removable slot (like eMMC)
ti,needs-special-reset: Requires a special softreset sequence
+ti,needs-special-hs-handling: HSMMC IP needs special setting for handling High
Speed
Example:
mmc1: mmc@0x4809c000 {
diff --git a/arch/arm/plat-omap/include/plat/mmc.h
b/arch/arm/plat-omap/include/plat/mmc.h
index 8b4e4f2..346af5b 100644
--- a/arch/arm/plat-omap/include/plat/mmc.h
+++ b/arch/arm/plat-omap/include/plat/mmc.h
@@ -126,6 +126,7 @@ struct omap_mmc_platform_data {
/* we can put the features above into this variable */
#define HSMMC_HAS_PBIAS(1 0)
#define HSMMC_HAS_UPDATED_RESET(1 1)
+#define HSMMC_HAS_HSPE_SUPPORT (1 2)
unsigned features;
int switch_pin; /* gpio (card detect) */
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 54bfd0c..5ea4c9d 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -62,6 +62,7 @@
#define VS18 (1 26)
#define VS30 (1 25)
+#define HSS(1 21)
#define SDVS18 (0x5 9)
#define SDVS30 (0x6 9)
#define SDVS33 (0x7 9)
@@ -89,6 +90,7 @@
#define MSBS (1 5)
#define BCE(1 1)
#define FOUR_BIT (1 1)
+#define HSPE (1 2)
#define DDR(1 19)
#define DW8(1 5)
#define CC 0x1
@@ -489,6 +491,7 @@ static void omap_hsmmc_set_clock(struct omap_hsmmc_host
*host)
struct mmc_ios *ios = host-mmc-ios;
unsigned long regval;
unsigned long timeout;
+ unsigned long clkdiv;
dev_vdbg(mmc_dev(host-mmc), Set clock to %uHz\n, ios-clock);
@@ -496,7 +499,8 @@ static void omap_hsmmc_set_clock(struct omap_hsmmc_host
*host)
regval = OMAP_HSMMC_READ(host-base, SYSCTL);
regval = regval ~(CLKD_MASK | DTO_MASK);
- regval = regval | (calc_divisor(host, ios) 6) | (DTO 16);
+ clkdiv = calc_divisor(host, ios);
+ regval = regval | (clkdiv 6) | (DTO 16);
OMAP_HSMMC_WRITE(host-base, SYSCTL, regval);
OMAP_HSMMC_WRITE(host-base, SYSCTL,
OMAP_HSMMC_READ(host-base, SYSCTL) | ICE);
@@ -507,6 +511,27 @@ static void omap_hsmmc_set_clock(struct omap_hsmmc_host
*host)
time_before(jiffies, timeout))
cpu_relax();
+ /*
+* Enable High-Speed Support
+* Pre-Requisites
+* - Controller should support High-Speed-Enable Bit
+* - Controller should not be using DDR Mode
+* - Controller should advertise that it supports High Speed
+*in capabilities register
+* - MMC/SD clock coming out of controller 25MHz
[PATCH V3] mmc: omap_hsmmc: Enable HSPE bit for high speed cards
HSMMC IP on AM33xx need a special setting to handle High-speed cards.
Other platforms like TI81xx, OMAP4 may need this as-well. This depends
on the HSMMC IP timing closure done for the high speed cards.
From AM335x TRM (SPRUH73F - 18.3.12 Output Signals Generation)
The MMC/SD/SDIO output signals can be driven on either falling edge or
rising edge depending on the SD_HCTL[2] HSPE bit. This feature allows
to reach better timing performance, and thus to increase data transfer
frequency.
There are few pre-requisites for enabling the HSPE bit
- Controller should support High-Speed-Enable Bit and
- Controller should not be using DDR Mode and
- Controller should advertise that it supports High Speed in
capabilities register and
- MMC/SD clock coming out of controller 25MHz
Note:
The implementation reuses the output of calc_divisor() so as to reduce
code addition.
Signed-off-by: Hebbar, Gururaja gururaja.heb...@ti.com
---
Rebased on mmc-next (v3.7.0-rc1)
Only Build tested since EDMA support for AM335x is not yet added
Changes in V2
- Added note in commit message about code re-use
- replaced ((a BIT(n) == BIT(n))) with (a BIT(n)) since
effectively both are same.
Changes in V3
- use symbolic define for hardcoded value (2500)
- use of_property_read_bool() instead of of_find_property()
:100644 100644 be76a23... ed271fc... M
Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
:100644 100644 8b4e4f2... 346af5b... M arch/arm/plat-omap/include/plat/mmc.h
:100644 100644 5434fd8... 4f7fcee... M drivers/mmc/host/omap_hsmmc.c
.../devicetree/bindings/mmc/ti-omap-hsmmc.txt |1 +
arch/arm/plat-omap/include/plat/mmc.h |1 +
drivers/mmc/host/omap_hsmmc.c | 31 +++-
3 files changed, 32 insertions(+), 1 deletions(-)
diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
index be76a23..ed271fc 100644
--- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -19,6 +19,7 @@ ti,dual-volt: boolean, supports dual voltage cards
supply-name examples are vmmc, vmmc_aux etc
ti,non-removable: non-removable slot (like eMMC)
ti,needs-special-reset: Requires a special softreset sequence
+ti,needs-special-hs-handling: HSMMC IP needs special setting for handling High
Speed
Example:
mmc1: mmc@0x4809c000 {
diff --git a/arch/arm/plat-omap/include/plat/mmc.h
b/arch/arm/plat-omap/include/plat/mmc.h
index 8b4e4f2..346af5b 100644
--- a/arch/arm/plat-omap/include/plat/mmc.h
+++ b/arch/arm/plat-omap/include/plat/mmc.h
@@ -126,6 +126,7 @@ struct omap_mmc_platform_data {
/* we can put the features above into this variable */
#define HSMMC_HAS_PBIAS(1 0)
#define HSMMC_HAS_UPDATED_RESET(1 1)
+#define HSMMC_HAS_HSPE_SUPPORT (1 2)
unsigned features;
int switch_pin; /* gpio (card detect) */
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 5434fd8..4f7fcee 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -63,6 +63,7 @@
#define VS18 (1 26)
#define VS30 (1 25)
+#define HSS(1 21)
#define SDVS18 (0x5 9)
#define SDVS30 (0x6 9)
#define SDVS33 (0x7 9)
@@ -90,6 +91,7 @@
#define MSBS (1 5)
#define BCE(1 1)
#define FOUR_BIT (1 1)
+#define HSPE (1 2)
#define DDR(1 19)
#define DW8(1 5)
#define CC 0x1
@@ -113,6 +115,7 @@
#define MMC_TIMEOUT_MS 20
#define OMAP_MMC_MIN_CLOCK 40
#define OMAP_MMC_MAX_CLOCK 5200
+#define HSMMC_CLKOUT 2500
#define DRIVER_NAMEomap_hsmmc
/*
@@ -495,6 +498,7 @@ static void omap_hsmmc_set_clock(struct omap_hsmmc_host
*host)
struct mmc_ios *ios = host-mmc-ios;
unsigned long regval;
unsigned long timeout;
+ unsigned long clkdiv;
dev_vdbg(mmc_dev(host-mmc), Set clock to %uHz\n, ios-clock);
@@ -502,7 +506,8 @@ static void omap_hsmmc_set_clock(struct omap_hsmmc_host
*host)
regval = OMAP_HSMMC_READ(host-base, SYSCTL);
regval = regval ~(CLKD_MASK | DTO_MASK);
- regval = regval | (calc_divisor(host, ios) 6) | (DTO 16);
+ clkdiv = calc_divisor(host, ios);
+ regval = regval | (clkdiv 6) | (DTO 16);
OMAP_HSMMC_WRITE(host-base, SYSCTL, regval);
OMAP_HSMMC_WRITE(host-base, SYSCTL,
OMAP_HSMMC_READ(host-base, SYSCTL) | ICE);
@@ -513,6 +518,27 @@ static void omap_hsmmc_set_clock(struct omap_hsmmc_host
*host)
time_before(jiffies, timeout))
cpu_relax
RE: [RESEND PATCH] mmc: omap_hsmmc: Enable HSPE bit for high speed cards
On Mon, Oct 29, 2012 at 21:47:19, Balbi, Felipe wrote:
Hi,
On Mon, Oct 29, 2012 at 06:26:48PM +0530, Hebbar, Gururaja wrote:
HSMMC IP on AM33xx need a special setting to handle High-speed cards.
Other platforms like TI81xx, OMAP4 may need this as-well. This depends
on the HSMMC IP timing closure done for the high speed cards.
From AM335x TRM (SPRUH73F - 18.3.12 Output Signals Generation)
The MMC/SD/SDIO output signals can be driven on either falling edge or
rising edge depending on the SD_HCTL[2] HSPE bit. This feature allows
to reach better timing performance, and thus to increase data transfer
frequency.
There are few pre-requisites for enabling the HSPE bit
- Controller should support High-Speed-Enable Bit and
- Controller should not be using DDR Mode and
- Controller should advertise that it supports High Speed in
capabilities register and
- MMC/SD clock coming out of controller 25MHz
Signed-off-by: Hebbar, Gururaja gururaja.heb...@ti.com
---
Rebased on mmc-next (v3.7.0-rc1)
Only Build tested since EDMA support for AM335x is not yet added
:100644 100644 be76a23... ed271fc... M
Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
:100644 100644 8b4e4f2... 346af5b... M
arch/arm/plat-omap/include/plat/mmc.h
:100644 100644 54bfd0c... 3fd95cb... M drivers/mmc/host/omap_hsmmc.c
.../devicetree/bindings/mmc/ti-omap-hsmmc.txt |1 +
arch/arm/plat-omap/include/plat/mmc.h |1 +
drivers/mmc/host/omap_hsmmc.c | 30
+++-
3 files changed, 31 insertions(+), 1 deletions(-)
diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
index be76a23..ed271fc 100644
--- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -19,6 +19,7 @@ ti,dual-volt: boolean, supports dual voltage cards
supply-name examples are vmmc, vmmc_aux etc
ti,non-removable: non-removable slot (like eMMC)
ti,needs-special-reset: Requires a special softreset sequence
+ti,needs-special-hs-handling: HSMMC IP needs special setting for handling
High Speed
can't you do runtime revision detection for this ?
Platforms like AM335x TI814x both use the same IP.
But only AM335x needed this bit to be set in order to sustain high
speed transfers. This was concluded after AM335x HSMMC IP timing
closure was completed for High speed Cards.
Example:
mmc1: mmc@0x4809c000 {
diff --git a/arch/arm/plat-omap/include/plat/mmc.h
b/arch/arm/plat-omap/include/plat/mmc.h
index 8b4e4f2..346af5b 100644
--- a/arch/arm/plat-omap/include/plat/mmc.h
+++ b/arch/arm/plat-omap/include/plat/mmc.h
@@ -126,6 +126,7 @@ struct omap_mmc_platform_data {
/* we can put the features above into this variable */
#define HSMMC_HAS_PBIAS(1 0)
#define HSMMC_HAS_UPDATED_RESET(1 1)
+#define HSMMC_HAS_HSPE_SUPPORT (1 2)
unsigned features;
int switch_pin; /* gpio (card detect) */
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 54bfd0c..3fd95cb 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -62,6 +62,7 @@
#define VS18 (1 26)
#define VS30 (1 25)
+#define HSS(1 21)
#define SDVS18 (0x5 9)
#define SDVS30 (0x6 9)
#define SDVS33 (0x7 9)
@@ -89,6 +90,7 @@
#define MSBS (1 5)
#define BCE(1 1)
#define FOUR_BIT (1 1)
+#define HSPE (1 2)
#define DDR(1 19)
#define DW8(1 5)
#define CC 0x1
@@ -489,6 +491,7 @@ static void omap_hsmmc_set_clock(struct omap_hsmmc_host
*host)
struct mmc_ios *ios = host-mmc-ios;
unsigned long regval;
unsigned long timeout;
+ unsigned long clkdiv;
dev_vdbg(mmc_dev(host-mmc), Set clock to %uHz\n, ios-clock);
@@ -496,7 +499,8 @@ static void omap_hsmmc_set_clock(struct omap_hsmmc_host
*host)
regval = OMAP_HSMMC_READ(host-base, SYSCTL);
regval = regval ~(CLKD_MASK | DTO_MASK);
- regval = regval | (calc_divisor(host, ios) 6) | (DTO 16);
+ clkdiv = calc_divisor(host, ios);
+ regval = regval | (clkdiv 6) | (DTO 16);
not part of $SUBJECT
The output of the calc_divisor() is reused in the below HSPE checking. So
instead of calling it twice I have taken the output of that function into
a variable and reused it.
OMAP_HSMMC_WRITE(host-base, SYSCTL, regval);
OMAP_HSMMC_WRITE(host-base, SYSCTL,
OMAP_HSMMC_READ(host-base, SYSCTL) | ICE);
@@ -507,6 +511,27
RE: [PATCH] ARM: OMAP2+: AM33XX: clock data: fix mcasp entries
On Wed, Oct 31, 2012 at 01:58:32, Joel A Fernandes wrote: Hi Gururaja, On Mon, Oct 29, 2012 at 10:45 AM, Hebbar, Gururaja gururaja.heb...@ti.com wrote: Matt, On Wed, Oct 10, 2012 at 20:00:49, Porter, Matt wrote: 6ea74cb ARM: OMAP2+: hwmod: get rid of all omap_clk_get_by_name usage exposes a bug in the AM33XX clock data for mcasp. After moving to clk_get() usage, the _init() of all registered hwmods fails on mcasp0 due to incorrect clock data causing clk_get() to fail. This causes all successive hwmods to fail to _init() leaving them in a bad state. This patch updates the mcasp clock entries so clk_get() will succeed. It is tested on BeagleBone and is needed for 3.7-rc1 to fix AM33xx boot. I want to test Audio on AM335x Evm with your EDMA patches. I have few patches for AM335x. Can you share the link to the repo branch on which I need to rebase? The patches are related to mcasp dt node, mcasp pinmux in dt, etc... I was wondering about the status of following patches you wrote, not added to mainline yet: (1) ASoC: Davinci: machine: Add device tree binding https://patchwork.kernel.org/patch/1380511/ - will this be resubmitted? There was no review comments for V3 I submitted. (2) ASoC: AM33XX: Add support for AM33xx SoC Audio https://github.com/joelagnel/linux-kernel/commit/973cfb48bdb70018b3869a21595bde8630efb29d I want to re-submit both the patches along with 2 more patch-set [1]. I am waiting for Matt Porters to reply with his recent branch, so that I can do a final test and re-submit. [1]. arm/dts: Add tlv320aic3x codec DT data to am335x-evm.dts arm/dts: add mcasp1 dt node to am335x-evm.dt ASoC: davinci-mcasp: Add pinctrl support arm/dts: AM33XX: setup pinctrl for mcasp1 on am335x-evm I need Mark Brown's Ack for the 3rd patch. There was some discussion about adding pinctrl support for Audio drivers. I couldn't get the final decision taken on it. I will rebase on to brownie-asoc/for-next and submit it today. Are you planning on sending/resending these patches again? I could do this too. I guess all other audio patches except for audio dts stuff is already in. Thanks, Joel Regards, Gururaja -- 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
[RESEND PATCH] mmc: omap_hsmmc: Enable HSPE bit for high speed cards
HSMMC IP on AM33xx need a special setting to handle High-speed cards.
Other platforms like TI81xx, OMAP4 may need this as-well. This depends
on the HSMMC IP timing closure done for the high speed cards.
From AM335x TRM (SPRUH73F - 18.3.12 Output Signals Generation)
The MMC/SD/SDIO output signals can be driven on either falling edge or
rising edge depending on the SD_HCTL[2] HSPE bit. This feature allows
to reach better timing performance, and thus to increase data transfer
frequency.
There are few pre-requisites for enabling the HSPE bit
- Controller should support High-Speed-Enable Bit and
- Controller should not be using DDR Mode and
- Controller should advertise that it supports High Speed in
capabilities register and
- MMC/SD clock coming out of controller 25MHz
Signed-off-by: Hebbar, Gururaja gururaja.heb...@ti.com
---
Rebased on mmc-next (v3.7.0-rc1)
Only Build tested since EDMA support for AM335x is not yet added
:100644 100644 be76a23... ed271fc... M
Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
:100644 100644 8b4e4f2... 346af5b... M arch/arm/plat-omap/include/plat/mmc.h
:100644 100644 54bfd0c... 3fd95cb... M drivers/mmc/host/omap_hsmmc.c
.../devicetree/bindings/mmc/ti-omap-hsmmc.txt |1 +
arch/arm/plat-omap/include/plat/mmc.h |1 +
drivers/mmc/host/omap_hsmmc.c | 30 +++-
3 files changed, 31 insertions(+), 1 deletions(-)
diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
index be76a23..ed271fc 100644
--- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -19,6 +19,7 @@ ti,dual-volt: boolean, supports dual voltage cards
supply-name examples are vmmc, vmmc_aux etc
ti,non-removable: non-removable slot (like eMMC)
ti,needs-special-reset: Requires a special softreset sequence
+ti,needs-special-hs-handling: HSMMC IP needs special setting for handling High
Speed
Example:
mmc1: mmc@0x4809c000 {
diff --git a/arch/arm/plat-omap/include/plat/mmc.h
b/arch/arm/plat-omap/include/plat/mmc.h
index 8b4e4f2..346af5b 100644
--- a/arch/arm/plat-omap/include/plat/mmc.h
+++ b/arch/arm/plat-omap/include/plat/mmc.h
@@ -126,6 +126,7 @@ struct omap_mmc_platform_data {
/* we can put the features above into this variable */
#define HSMMC_HAS_PBIAS(1 0)
#define HSMMC_HAS_UPDATED_RESET(1 1)
+#define HSMMC_HAS_HSPE_SUPPORT (1 2)
unsigned features;
int switch_pin; /* gpio (card detect) */
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 54bfd0c..3fd95cb 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -62,6 +62,7 @@
#define VS18 (1 26)
#define VS30 (1 25)
+#define HSS(1 21)
#define SDVS18 (0x5 9)
#define SDVS30 (0x6 9)
#define SDVS33 (0x7 9)
@@ -89,6 +90,7 @@
#define MSBS (1 5)
#define BCE(1 1)
#define FOUR_BIT (1 1)
+#define HSPE (1 2)
#define DDR(1 19)
#define DW8(1 5)
#define CC 0x1
@@ -489,6 +491,7 @@ static void omap_hsmmc_set_clock(struct omap_hsmmc_host
*host)
struct mmc_ios *ios = host-mmc-ios;
unsigned long regval;
unsigned long timeout;
+ unsigned long clkdiv;
dev_vdbg(mmc_dev(host-mmc), Set clock to %uHz\n, ios-clock);
@@ -496,7 +499,8 @@ static void omap_hsmmc_set_clock(struct omap_hsmmc_host
*host)
regval = OMAP_HSMMC_READ(host-base, SYSCTL);
regval = regval ~(CLKD_MASK | DTO_MASK);
- regval = regval | (calc_divisor(host, ios) 6) | (DTO 16);
+ clkdiv = calc_divisor(host, ios);
+ regval = regval | (clkdiv 6) | (DTO 16);
OMAP_HSMMC_WRITE(host-base, SYSCTL, regval);
OMAP_HSMMC_WRITE(host-base, SYSCTL,
OMAP_HSMMC_READ(host-base, SYSCTL) | ICE);
@@ -507,6 +511,27 @@ static void omap_hsmmc_set_clock(struct omap_hsmmc_host
*host)
time_before(jiffies, timeout))
cpu_relax();
+ /*
+* Enable High-Speed Support
+* Pre-Requisites
+* - Controller should support High-Speed-Enable Bit
+* - Controller should not be using DDR Mode
+* - Controller should advertise that it supports High Speed
+*in capabilities register
+* - MMC/SD clock coming out of controller 25MHz
+*/
+ if ((mmc_slot(host).features HSMMC_HAS_HSPE_SUPPORT)
+ (ios-timing != MMC_TIMING_UHS_DDR50)
+ ((OMAP_HSMMC_READ(host-base, CAPA) HSS) == HSS)) {
+ regval = OMAP_HSMMC_READ(host-base, HCTL
RE: [PATCH] ARM: OMAP2+: AM33XX: clock data: fix mcasp entries
Matt, On Wed, Oct 10, 2012 at 20:00:49, Porter, Matt wrote: 6ea74cb ARM: OMAP2+: hwmod: get rid of all omap_clk_get_by_name usage exposes a bug in the AM33XX clock data for mcasp. After moving to clk_get() usage, the _init() of all registered hwmods fails on mcasp0 due to incorrect clock data causing clk_get() to fail. This causes all successive hwmods to fail to _init() leaving them in a bad state. This patch updates the mcasp clock entries so clk_get() will succeed. It is tested on BeagleBone and is needed for 3.7-rc1 to fix AM33xx boot. I want to test Audio on AM335x Evm with your EDMA patches. I have few patches for AM335x. Can you share the link to the repo branch on which I need to rebase? The patches are related to mcasp dt node, mcasp pinmux in dt, etc... ..snip.. ..snip.. Thanks Regards, Gururaja -- 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 v3 05/16] ARM: edma: add AM33XX crossbar event support
On Thu, Oct 18, 2012 at 18:56:44, Porter, Matt wrote:
Adds support for the per-EDMA channel event mux. This is required
for any peripherals using DMA crossbar mapped events.
Signed-off-by: Matt Porter mpor...@ti.com
---
arch/arm/common/edma.c | 63
+++-
include/linux/platform_data/edma.h |1 +
2 files changed, 63 insertions(+), 1 deletion(-)
..snip..
..snip..
+
+ for (i = 0; xbar_chans[i][0] != -1; i++) {
+ shift = (xbar_chans[i][1] % 4) * 8;
+ offset = xbar_chans[i][1] 2;
+ offset = 2;
+ mux = __raw_readl((void *)((u32)xbar + offset));
+ mux = (~(0xff shift));
+ mux |= (xbar_chans[i][0] shift);
+ __raw_writel(mux, (void *)((u32)xbar + offset));
This method of calculating Xbar Channel offset has a bug that
the code breaks with unaligned access trap error when requested
channel to be mapped is odd.
This was fixed in Arago tree [1]. Kindly verify
+ }
+
+ pdata-xbar_chans = xbar_chans;
+
+ return 0;
+}
+
..snip..
..snip..
[1]
http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;
h=c08d3cb557adf71c79aeefb3395455824e83
Regards,
Gururaja
--
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
discrepancy while save and restore of debounce registers
Hi,
I came across a peculiar issue while updating GPIO debounce registers on
OMAP platform.
According to mainline commit ae547354a8ed59f19b57f7e1de9c7816edfc3537
gpio/omap: save and restore debounce registers
GPIO debounce registers need to be saved and restored for proper functioning
of driver.
...
@@ -1363,6 +1369,12 @@ static void omap_gpio_restore_context(struct gpio_bank
*bank)
__raw_writel(bank-context.fallingdetect,
bank-base + bank-regs-fallingdetect);
__raw_writel(bank-context.dataout, bank-base + bank-regs-dataout);
+ if (bank-dbck_enable_mask) {
+ __raw_writel(bank-context.debounce, bank-base +
+ bank-regs-debounce);
+ __raw_writel(bank-context.debounce_en,
+ bank-base + bank-regs-debounce_en);
+ }
}
Due to copy/paste of this commit into my local tree, I missed the check for
bank-dbck_enable_mask, and directly restored the saved value from context.
After this, I saw random crashes when accessing different registers (sometimes
its OE register and sometime its DATAOUT register).
These crashes were seen across 2nd and subsequent suspend/resume.
My doubt/questions are
1. Why should debounce registers be updated only when it's accessed previously?
2. What is the relation between updating debounce registers and crash seen on
others registers?
Thanks in advance for the support.
Regards
Gururaja
RE: discrepancy while save and restore of debounce registers
Jon,
On Thu, Oct 18, 2012 at 02:42:01, Hunter, Jon wrote:
Hi Gururaja,
On 10/17/2012 01:13 AM, Hebbar, Gururaja wrote:
Hi,
I came across a peculiar issue while updating GPIO debounce registers on
OMAP platform.
According to mainline commit ae547354a8ed59f19b57f7e1de9c7816edfc3537
gpio/omap: save and restore debounce registers
GPIO debounce registers need to be saved and restored for proper functioning
of driver.
...
@@ -1363,6 +1369,12 @@ static void omap_gpio_restore_context(struct
gpio_bank *bank)
__raw_writel(bank-context.fallingdetect,
bank-base + bank-regs-fallingdetect);
__raw_writel(bank-context.dataout, bank-base +
bank-regs-dataout);
+ if (bank-dbck_enable_mask) {
+ __raw_writel(bank-context.debounce, bank-base +
+ bank-regs-debounce);
+ __raw_writel(bank-context.debounce_en,
+ bank-base +
bank-regs-debounce_en);
+ }
}
Due to copy/paste of this commit into my local tree, I missed the check for
bank-dbck_enable_mask, and directly restored the saved value from context.
After this, I saw random crashes when accessing different registers
(sometimes
its OE register and sometime its DATAOUT register).
These crashes were seen across 2nd and subsequent suspend/resume.
My doubt/questions are
1. Why should debounce registers be updated only when it's accessed
previously?
If debounce is not being used by any of the gpios, then there is no need
to restore them as there are no bits set. So this makes sense and saves
a couple register writes.
What I want to know is that other than saving register writes, is there any
other important stuff that specifies this requirement.
2. What is the relation between updating debounce registers and crash seen
on
others registers?
This I am not sure about. I gave this a quick try on my omap3430 beagle
board, but I did not see any side-effects from doing this. However, if
you are always restoring the debounce context regardless of whether
debounce is being used, then you could be writing bad values to the
debounce registers as the context variables bank-context.debouce and
bank-context.debouce_en may not initialised. So that is bad. However,
that said I am still not sure how this could cause a crash.
Can you share more details on ...
Sorry for missing below details in first post.
1. The OMAP platform you are using?
I was trying this on TI AM335x platform (repo below). On AM335x EVM board
http://arago-project.org/git/projects/?p=linux-am33x.git;a=shortlog;
h=refs/heads/v3.2-staging
2. What linux distro/environment you are using?
Arago AM335x PSP release (linux 3.2 + am335x patch-set)
3. If there are any specific steps to reproduce this 100% of the time?
On top of this tree, try suspend/resume using echo mem /syspower/state
Cheers
Jon
Regards,
Gururaja
--
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 v2 08/16] ARM: omap: add hsmmc am33xx specific init
Matt On Fri, Oct 12, 2012 at 00:34:33, Porter, Matt wrote: AM33xx requires special handling in hsmmc initialization platform glue. Since AM335x boots mainly through DT, do we still need this patch. This function will be called in case of initializing hsmmc with Platform data. Signed-off-by: Matt Porter mpor...@ti.com --- arch/arm/mach-omap2/hsmmc.c |7 --- 1 file changed, 4 insertions(+), 3 deletions(-) ..snip.. ..snip.. name = omap_hsmmc; res = snprintf(oh_name, MAX_OMAP_MMC_HWMOD_NAME_LEN, -- 1.7.9.5 ___ Davinci-linux-open-source mailing list davinci-linux-open-sou...@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source Regards, Gururaja -- 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 v2 0/7] uio_pruss cleanup and platform support
On Sat, Oct 06, 2012 at 02:58:26, Porter, Matt wrote: On Fri, Oct 05, 2012 at 04:43:56AM +, Hebbar, Gururaja wrote: Matt, On Wed, Oct 03, 2012 at 20:30:58, Porter, Matt wrote: On Fri, Sep 28, 2012 at 03:37:45PM -0400, Matt Porter wrote: Changes since v1: - Replaced uio_pruss private SRAM API use with genalloc - Added DA850 platform device and clock support - Added DA850 L3 RAM gen_pool support - Split out DT binding This series enables uio_pruss on both DA850 and AM33xx. The driver previously was not enabled by any platform and the private SRAM API was accessing an invalid SRAM bank for use on DA850. For AM33xx, DT, pinctrl, and runtime PM support are added since AM33xx only boots via DT. I'm dropping AM33xx/OMAP support from v3 for this series Just for my clarification, I believe you will be taking up AM33xx/OMAP SRAM support later once you have completed supporting DaVinci. Right? There's no SRAM support for uio_pruss to be handled for AM33xx, Sorry for not being clearer. I was referring to adding SRAM support for McASP module on AM335x platform. but I will be posting a separate series with the DT portion and some alternate hard reset handling implementation. I find the private OMAP reset api to be very ugly but we might have to go with that for now. I didn't want the OMAP hard reset portion to hold up the more important part of this cleanup. -Matt since the focus has turned to fixing Davinci SRAM to provide genalloc support and the associated use of that in the driver. I'll have a separate series with AM33xx support since dealing cleanly with external resets on OMAP is a bigger issue. -Matt ___ Davinci-linux-open-source mailing list davinci-linux-open-sou...@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source Regards, Gururaja ___ Davinci-linux-open-source mailing list davinci-linux-open-sou...@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source Regards, Gururaja -- 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 v2 0/7] uio_pruss cleanup and platform support
Matt, On Wed, Oct 03, 2012 at 20:30:58, Porter, Matt wrote: On Fri, Sep 28, 2012 at 03:37:45PM -0400, Matt Porter wrote: Changes since v1: - Replaced uio_pruss private SRAM API use with genalloc - Added DA850 platform device and clock support - Added DA850 L3 RAM gen_pool support - Split out DT binding This series enables uio_pruss on both DA850 and AM33xx. The driver previously was not enabled by any platform and the private SRAM API was accessing an invalid SRAM bank for use on DA850. For AM33xx, DT, pinctrl, and runtime PM support are added since AM33xx only boots via DT. I'm dropping AM33xx/OMAP support from v3 for this series Just for my clarification, I believe you will be taking up AM33xx/OMAP SRAM support later once you have completed supporting DaVinci. Right? since the focus has turned to fixing Davinci SRAM to provide genalloc support and the associated use of that in the driver. I'll have a separate series with AM33xx support since dealing cleanly with external resets on OMAP is a bigger issue. -Matt ___ Davinci-linux-open-source mailing list davinci-linux-open-sou...@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source Regards, Gururaja -- 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] mmc: omap_hsmmc: Enable HSPE bit for high speed cards
On Thu, Sep 27, 2012 at 16:31:14, Koen Kooi wrote: Op 26 sep. 2012, om 13:37 heeft Hebbar, Gururaja gururaja.heb...@ti.com het volgende geschreven: On Wed, Sep 12, 2012 at 17:32:38, Hebbar, Gururaja wrote: On Wed, Sep 12, 2012 at 14:19:51, S, Venkatraman wrote: On Tue, Sep 4, 2012 at 6:39 PM, Hebbar, Gururaja gururaja.heb...@ti.com wrote: HSMMC IP on AM33xx need a special setting to handle High-speed cards. Other platforms like TI81xx, OMAP4 may need this as-well. This depends on the HSMMC IP timing closure done for the high speed cards. From AM335x TRM (SPRUH73F - 18.3.12 Output Signals Generation) The MMC/SD/SDIO output signals can be driven on either falling edge or rising edge depending on the SD_HCTL[2] HSPE bit. This feature allows to reach better timing performance, and thus to increase data transfer frequency. There are few pre-requisites for enabling the HSPE bit - Controller should support High-Speed-Enable Bit and - Controller should not be using DDR Mode and - Controller should advertise that it supports High Speed in capabilities register and - MMC/SD clock coming out of controller 25MHz The patch is well written. But then, I don't see a need for a DT binding for this feature. My reasons for DT Binding 1. Not all platforms using this driver has this bit (OMAP2) 2. Not all platforms using this driver needs this bit to be enabled (OMAP4) 3. Platforms which require this bit this to be set needs a method to inform driver. In order to not disturb old/unsupported platforms, I chose this DT method. By definition, HS implies 25MHz or above, so that check seems to be redundant as well. There are chances that the platform Max Clock output from HSMMC IP is than 25 MHz even if the card is High Speed. In such cases it would be better to Confirm that the Clock output is actually 25 MHz Kindly correct me if I am wrong. Meanwhile, I'll check with HSPE enabled on OMAP. Gentle Ping. Matt Poter recently submitted EDMA related patches as RFC. He confirmed that basic mmc is working on AM335x with his edma patches. Above patch is required to get High-speed cards working on AM335x. I haven't seen any review comments for this. Can this be pulled in for 3.7? I had trouble applying this to 3.6-rc7, is that a known problem and should I try linux-next? I just applied it applied it on Linux-next/master (locally merged with linux-omap-dt branch). It applied without any issues. regards, Koen Regards, Gururaja -- 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/13] DMA Engine support for AM33xx
On Fri, Sep 21, 2012 at 23:52:11, Porter, Matt wrote:
On Fri, Sep 21, 2012 at 08:27:07AM +, Hebbar, Gururaja wrote:
On Thu, Sep 20, 2012 at 20:13:33, Porter, Matt wrote:
This series adds DMA Engine support for AM33xx, which uses
an EDMA DMAC. The EDMA DMAC has been previously supported by only
a private API implementation (much like the situation with OMAP
DMA) found on the DaVinci family of SoCs.
There are a mind-boggling number of dependencies for this series:
- Jon Hunter's OF DMA helpers series
https://patchwork.kernel.org/patch/1461061/
https://patchwork.kernel.org/patch/1461051/
- Patch to address OF DMA helpers naming issues:
https://patchwork.kernel.org/patch/1477921/
- EDMA DMA Engine wrapper driver in linux-next
c2dde5f8f2095d7c623ff3565c1462e190272273
- EDMA DMA Engine wrapper driver bug fix:
https://patchwork.kernel.org/patch/1474411/
- A huge number of patches in linux-next for AM33xx boot
(too numerous to list)
The approach taken is similar to how OMAP DMA is being converted to
DMA Engine support. With the functional EDMA private API already
existing in mach-davinci/dma.c, we first move that to an ARM common
area so it can be shared. Adding DT and runtime PM support to the
private EDMA API implementation allows it to run on AM33xx. AM33xx
*only* boots using DT so we leverage Jon's generic DT DMA helpers to
register EDMA DMAC with the of_dma framework and then add support
for calling the dma_request_slave_channel() API to both the mmc
and spi drivers.
What works? Well, with this series we now have MMC and SPI support
on AM33xx. The only caveat for MMC is that the mmc3 controller has
its events on the crossbar and is not usable right now.
This is tested on BeagleBone with a SPI framebuffer driver and SD
card.
After this series, the plan is to convert the last in-tree user
of the private EDMA API (davinci-pcm/mcasp) and then eliminate
the private EDMA API by folding its functionality into
drivers/dma/edma.c.
TODO:
add AM33xx crossbar support to the private EDMA API
(any EDMA events on the crossbar are not supported)
Can you please mention the base repo you have taken as starting point.
(repo + extra patches ...).
It's mainline 3.6-rc6 and you can see the complete set of patches
at https://github.com/ohporter/linux/tree/edma-dmaengine-am33xx-rfc-v1
after commit 5698bd757d55b1bb87edd1a9744ab09c142abfc2
This will help us to test the code.
This is because I looked at the patch 12/13 and I see that mmc
device-node is modified. But in mainline I don’t see device
node for mmc (yet).
Oops. You'll need e62aae450bcdefbe9d7bc277ae0ef645 and
fe97304557d2c6f7d0aaf1ea028ea48ffca366a9 which I forgot to include
in this series. I'll have them in for v2.
Yesterday I tested edma patches on latest linux-next/master + merge of
linux-omap/for_3.7/dts_part2. Below are my observations
1. baseline = linux-next/master + merge of linux-omap/for_3.7/dts_part2
2. on top of above branch, I applied patches [1-9]/13 of your edma
patches
3. few patches required trivial changes before applying
4. Applied dma of patches as you mentioned
5. add custom patch (ARM: CUSTOM: Build a uImage with dtb already
appended)
From https://github.com/hvaibhav/am335x-linux/commit/
7e72f5ed4b702c9373d19f7626f07ae31a381d53#arch/arm/Makefile
6. Modified 9/13 patch to apply properly on latest am33xx.dtsi.
a. Edma portion as it is
b. mmc portion as below
mmc1: mmc@4806 {
compatible = ti,omap3-hsmmc;
ti,hwmods = mmc1;
ti,dual-volt;
ti,needs-special-reset;
bus-width = 4;
vmmc-supply = vmmc_reg;
dmas = edma 24
edma 25;
dma-names = tx, rx;
};
c. added mmc pinmux as-well
7. make CROSS_COMPILE=arm-arago-linux-gnueabi- ARCH=arm distclean
make CROSS_COMPILE=arm-arago-linux-gnueabi- ARCH=arm
omap2plus_defconfig
8. enabled TI_EDMA from menuconfig (since it was not enabled for
omap2plus_defconfig
9. make CROSS_COMPILE=arm-arago-linux-gnueabi- ARCH=arm uImage
make CROSS_COMPILE=arm-arago-linux-gnueabi- ARCH=arm
uImage-dtb.am335x-evm
With above changes, edma probe was failing at request_mem_region()
Inside linux-next/arch/arm/common/edma.c -- edma_probe()
I had to modify edma_probe as below
diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index f337f81..efe2673 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -1589,11 +1589,11 @@ static int __init edma_probe(struct platform_device
*pdev)
for (j = 0; j EDMA_MAX_CC; j++) {
if (node
RE: [PATCH] mmc: omap_hsmmc: Enable HSPE bit for high speed cards
On Wed, Sep 12, 2012 at 17:32:38, Hebbar, Gururaja wrote: On Wed, Sep 12, 2012 at 14:19:51, S, Venkatraman wrote: On Tue, Sep 4, 2012 at 6:39 PM, Hebbar, Gururaja gururaja.heb...@ti.com wrote: HSMMC IP on AM33xx need a special setting to handle High-speed cards. Other platforms like TI81xx, OMAP4 may need this as-well. This depends on the HSMMC IP timing closure done for the high speed cards. From AM335x TRM (SPRUH73F - 18.3.12 Output Signals Generation) The MMC/SD/SDIO output signals can be driven on either falling edge or rising edge depending on the SD_HCTL[2] HSPE bit. This feature allows to reach better timing performance, and thus to increase data transfer frequency. There are few pre-requisites for enabling the HSPE bit - Controller should support High-Speed-Enable Bit and - Controller should not be using DDR Mode and - Controller should advertise that it supports High Speed in capabilities register and - MMC/SD clock coming out of controller 25MHz The patch is well written. But then, I don't see a need for a DT binding for this feature. My reasons for DT Binding 1. Not all platforms using this driver has this bit (OMAP2) 2. Not all platforms using this driver needs this bit to be enabled (OMAP4) 3. Platforms which require this bit this to be set needs a method to inform driver. In order to not disturb old/unsupported platforms, I chose this DT method. By definition, HS implies 25MHz or above, so that check seems to be redundant as well. There are chances that the platform Max Clock output from HSMMC IP is than 25 MHz even if the card is High Speed. In such cases it would be better to Confirm that the Clock output is actually 25 MHz Kindly correct me if I am wrong. Meanwhile, I'll check with HSPE enabled on OMAP. Gentle Ping. Matt Poter recently submitted EDMA related patches as RFC. He confirmed that basic mmc is working on AM335x with his edma patches. Above patch is required to get High-speed cards working on AM335x. I haven't seen any review comments for this. Can this be pulled in for 3.7? Regards, Venkat. Regards, Gururaja Regards, Gururaja -- 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/13] DMA Engine support for AM33xx
On Fri, Sep 21, 2012 at 23:52:11, Porter, Matt wrote: On Fri, Sep 21, 2012 at 08:27:07AM +, Hebbar, Gururaja wrote: On Thu, Sep 20, 2012 at 20:13:33, Porter, Matt wrote: This series adds DMA Engine support for AM33xx, which uses an EDMA DMAC. The EDMA DMAC has been previously supported by only a private API implementation (much like the situation with OMAP DMA) found on the DaVinci family of SoCs. There are a mind-boggling number of dependencies for this series: - Jon Hunter's OF DMA helpers series https://patchwork.kernel.org/patch/1461061/ https://patchwork.kernel.org/patch/1461051/ - Patch to address OF DMA helpers naming issues: https://patchwork.kernel.org/patch/1477921/ - EDMA DMA Engine wrapper driver in linux-next c2dde5f8f2095d7c623ff3565c1462e190272273 - EDMA DMA Engine wrapper driver bug fix: https://patchwork.kernel.org/patch/1474411/ - A huge number of patches in linux-next for AM33xx boot (too numerous to list) The approach taken is similar to how OMAP DMA is being converted to DMA Engine support. With the functional EDMA private API already existing in mach-davinci/dma.c, we first move that to an ARM common area so it can be shared. Adding DT and runtime PM support to the private EDMA API implementation allows it to run on AM33xx. AM33xx *only* boots using DT so we leverage Jon's generic DT DMA helpers to register EDMA DMAC with the of_dma framework and then add support for calling the dma_request_slave_channel() API to both the mmc and spi drivers. What works? Well, with this series we now have MMC and SPI support on AM33xx. The only caveat for MMC is that the mmc3 controller has its events on the crossbar and is not usable right now. This is tested on BeagleBone with a SPI framebuffer driver and SD card. After this series, the plan is to convert the last in-tree user of the private EDMA API (davinci-pcm/mcasp) and then eliminate the private EDMA API by folding its functionality into drivers/dma/edma.c. TODO: add AM33xx crossbar support to the private EDMA API (any EDMA events on the crossbar are not supported) Can you please mention the base repo you have taken as starting point. (repo + extra patches ...). It's mainline 3.6-rc6 and you can see the complete set of patches at https://github.com/ohporter/linux/tree/edma-dmaengine-am33xx-rfc-v1 after commit 5698bd757d55b1bb87edd1a9744ab09c142abfc2 Thanks for the link. However, I was looking for the mainline kernel repo/branch That you first used as baseline. This will help us to test the code. This is because I looked at the patch 12/13 and I see that mmc device-node is modified. But in mainline I don’t see device node for mmc (yet). Oops. You'll need e62aae450bcdefbe9d7bc277ae0ef645 and fe97304557d2c6f7d0aaf1ea028ea48ffca366a9 which I forgot to include in this series. I'll have them in for v2. -Matt Matt Porter (13): ARM: davinci: move private EDMA API to arm/common ARM: edma: remove unused transfer controller handlers ARM: edma: add DT and runtime PM support for AM335x dmaengine: edma: enable build for AM335x dma: Add TI EDMA device tree binding ARM: omap: add hsmmc am33xx specific init mmc: omap_hsmmc: dma_request_slave_channel() support for DT platforms mmc: omap_hsmmc: limit max_segs with the EDMA DMAC mmc: omap_hsmmc: add generic DMA request support to the DT binding spi: omap2-mcspi: dma_request_slave_channel() support for DT platforms spi: omap2-mcspi: add generic DMA request support to the DT binding ARM: dts: add am33xx EDMA support Documentation: add schedule for removing private EDMA API Documentation/devicetree/bindings/dma/ti-edma.txt | 49 + .../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 25 +- Documentation/devicetree/bindings/spi/omap-spi.txt | 27 +- Documentation/feature-removal-schedule.txt | 10 + arch/arm/Kconfig |1 + arch/arm/boot/dts/am33xx.dtsi | 46 + arch/arm/common/Kconfig|3 + arch/arm/common/Makefile |1 + arch/arm/common/edma.c | 1779 arch/arm/include/asm/mach/edma.h | 267 +++ arch/arm/mach-davinci/Makefile |2 +- arch/arm/mach-davinci/devices.c|3 +- arch/arm/mach-davinci/dm355.c |2 +- arch/arm/mach-davinci/dm365.c |2 +- arch/arm/mach-davinci/dm644x.c |2 +- arch/arm/mach-davinci/dm646x.c |2 +- arch/arm/mach-davinci/dma.c| 1588 - arch
RE: [RFC PATCH 01/13] ARM: davinci: move private EDMA API to arm/common
On Thu, Sep 20, 2012 at 20:13:34, Porter, Matt wrote: Move mach-davinci/dma.c to common/edma.c so it can be used by OMAP (specifically AM33xx atm) as well. This just moves the private EDMA API but does not support OMAP. Signed-off-by: Matt Porter mpor...@ti.com --- arch/arm/Kconfig |1 + arch/arm/common/Kconfig|3 + arch/arm/common/Makefile |1 + arch/arm/common/edma.c | 1588 arch/arm/include/asm/mach/edma.h | 267 + arch/arm/mach-davinci/Makefile |2 +- arch/arm/mach-davinci/devices.c|3 +- arch/arm/mach-davinci/dm355.c |2 +- arch/arm/mach-davinci/dm365.c |2 +- arch/arm/mach-davinci/dm644x.c |2 +- arch/arm/mach-davinci/dm646x.c |2 +- arch/arm/mach-davinci/dma.c| 1588 arch/arm/mach-davinci/include/mach/asp.h |2 +- This will clash with patch ASoC/ARM: Davinci: McASP: split asp header into platform and audio specific queued in ASoC tree by Mark Brown tree (Auio - ASoC Tree) I forgot to mention this last time. Sorry arch/arm/mach-davinci/include/mach/da8xx.h |3 +- arch/arm/mach-davinci/include/mach/edma.h | 267 - arch/arm/mach-davinci/include/mach/spi.h |2 +- arch/arm/plat-omap/Kconfig |1 + 17 files changed, 1872 insertions(+), 1864 deletions(-) create mode 100644 arch/arm/common/edma.c create mode 100644 arch/arm/include/asm/mach/edma.h delete mode 100644 arch/arm/mach-davinci/dma.c delete mode 100644 arch/arm/mach-davinci/include/mach/edma.h ...snip... ...snip... Regards, Gururaja -- 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 01/13] ARM: davinci: move private EDMA API to arm/common
On Thu, Sep 20, 2012 at 20:13:34, Porter, Matt wrote: Move mach-davinci/dma.c to common/edma.c so it can be used by OMAP (specifically AM33xx atm) as well. This just moves the private EDMA API but does not support OMAP. Signed-off-by: Matt Porter mpor...@ti.com --- arch/arm/Kconfig |1 + arch/arm/common/Kconfig|3 + arch/arm/common/Makefile |1 + arch/arm/common/edma.c | 1588 arch/arm/include/asm/mach/edma.h | 267 + arch/arm/mach-davinci/Makefile |2 +- arch/arm/mach-davinci/devices.c|3 +- arch/arm/mach-davinci/dm355.c |2 +- arch/arm/mach-davinci/dm365.c |2 +- arch/arm/mach-davinci/dm644x.c |2 +- arch/arm/mach-davinci/dm646x.c |2 +- arch/arm/mach-davinci/dma.c| 1588 Please use –M option, while generating patches via git-format-patch. This reduces the patch size if files are copied/renamed/moved. arch/arm/mach-davinci/include/mach/asp.h |2 +- arch/arm/mach-davinci/include/mach/da8xx.h |3 +- arch/arm/mach-davinci/include/mach/edma.h | 267 - arch/arm/mach-davinci/include/mach/spi.h |2 +- arch/arm/plat-omap/Kconfig |1 + 17 files changed, 1872 insertions(+), 1864 deletions(-) create mode 100644 arch/arm/common/edma.c create mode 100644 arch/arm/include/asm/mach/edma.h delete mode 100644 arch/arm/mach-davinci/dma.c delete mode 100644 arch/arm/mach-davinci/include/mach/edma.h ...snip... ...snip... ...snip... -- 1.7.9.5 ___ Davinci-linux-open-source mailing list davinci-linux-open-sou...@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source Regards, Gururaja -- 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/13] DMA Engine support for AM33xx
On Thu, Sep 20, 2012 at 20:13:33, Porter, Matt wrote: This series adds DMA Engine support for AM33xx, which uses an EDMA DMAC. The EDMA DMAC has been previously supported by only a private API implementation (much like the situation with OMAP DMA) found on the DaVinci family of SoCs. There are a mind-boggling number of dependencies for this series: - Jon Hunter's OF DMA helpers series https://patchwork.kernel.org/patch/1461061/ https://patchwork.kernel.org/patch/1461051/ - Patch to address OF DMA helpers naming issues: https://patchwork.kernel.org/patch/1477921/ - EDMA DMA Engine wrapper driver in linux-next c2dde5f8f2095d7c623ff3565c1462e190272273 - EDMA DMA Engine wrapper driver bug fix: https://patchwork.kernel.org/patch/1474411/ - A huge number of patches in linux-next for AM33xx boot (too numerous to list) The approach taken is similar to how OMAP DMA is being converted to DMA Engine support. With the functional EDMA private API already existing in mach-davinci/dma.c, we first move that to an ARM common area so it can be shared. Adding DT and runtime PM support to the private EDMA API implementation allows it to run on AM33xx. AM33xx *only* boots using DT so we leverage Jon's generic DT DMA helpers to register EDMA DMAC with the of_dma framework and then add support for calling the dma_request_slave_channel() API to both the mmc and spi drivers. What works? Well, with this series we now have MMC and SPI support on AM33xx. The only caveat for MMC is that the mmc3 controller has its events on the crossbar and is not usable right now. This is tested on BeagleBone with a SPI framebuffer driver and SD card. After this series, the plan is to convert the last in-tree user of the private EDMA API (davinci-pcm/mcasp) and then eliminate the private EDMA API by folding its functionality into drivers/dma/edma.c. TODO: add AM33xx crossbar support to the private EDMA API (any EDMA events on the crossbar are not supported) Can you please mention the base repo you have taken as starting point. (repo + extra patches ...). This will help us to test the code. This is because I looked at the patch 12/13 and I see that mmc device-node is modified. But in mainline I don’t see device node for mmc (yet). Matt Porter (13): ARM: davinci: move private EDMA API to arm/common ARM: edma: remove unused transfer controller handlers ARM: edma: add DT and runtime PM support for AM335x dmaengine: edma: enable build for AM335x dma: Add TI EDMA device tree binding ARM: omap: add hsmmc am33xx specific init mmc: omap_hsmmc: dma_request_slave_channel() support for DT platforms mmc: omap_hsmmc: limit max_segs with the EDMA DMAC mmc: omap_hsmmc: add generic DMA request support to the DT binding spi: omap2-mcspi: dma_request_slave_channel() support for DT platforms spi: omap2-mcspi: add generic DMA request support to the DT binding ARM: dts: add am33xx EDMA support Documentation: add schedule for removing private EDMA API Documentation/devicetree/bindings/dma/ti-edma.txt | 49 + .../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 25 +- Documentation/devicetree/bindings/spi/omap-spi.txt | 27 +- Documentation/feature-removal-schedule.txt | 10 + arch/arm/Kconfig |1 + arch/arm/boot/dts/am33xx.dtsi | 46 + arch/arm/common/Kconfig|3 + arch/arm/common/Makefile |1 + arch/arm/common/edma.c | 1779 arch/arm/include/asm/mach/edma.h | 267 +++ arch/arm/mach-davinci/Makefile |2 +- arch/arm/mach-davinci/devices.c|3 +- arch/arm/mach-davinci/dm355.c |2 +- arch/arm/mach-davinci/dm365.c |2 +- arch/arm/mach-davinci/dm644x.c |2 +- arch/arm/mach-davinci/dm646x.c |2 +- arch/arm/mach-davinci/dma.c| 1588 - arch/arm/mach-davinci/include/mach/asp.h |2 +- arch/arm/mach-davinci/include/mach/da8xx.h |3 +- arch/arm/mach-davinci/include/mach/edma.h | 267 --- arch/arm/mach-davinci/include/mach/spi.h |2 +- arch/arm/mach-omap2/hsmmc.c|7 +- arch/arm/plat-omap/Kconfig |1 + drivers/dma/Kconfig|2 +- drivers/dma/edma.c |2 +- drivers/mmc/host/omap_hsmmc.c | 26 +- drivers/spi/spi-omap2-mcspi.c | 68 +- 27 files changed, 2296 insertions(+), 1893 deletions(-) create mode 100644 Documentation/devicetree/bindings/dma/ti-edma.txt
RE: [RFC PATCH 05/13] dma: Add TI EDMA device tree binding
On Thu, Sep 20, 2012 at 20:13:38, Porter, Matt wrote:
The binding definition is based on the generic DMA controller
binding.
Signed-off-by: Matt Porter mpor...@ti.com
---
Documentation/devicetree/bindings/dma/ti-edma.txt | 49
+
1 file changed, 49 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/ti-edma.txt
diff --git a/Documentation/devicetree/bindings/dma/ti-edma.txt
b/Documentation/devicetree/bindings/dma/ti-edma.txt
new file mode 100644
index 000..06402eb
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/ti-edma.txt
@@ -0,0 +1,49 @@
+TI EDMA
+
+Required properties:
+- compatible : ti,edma3
+- ti,hwmods: Name of the hwmods associated to the EDMA
+- ti,edma-regions: Number of regions
+- ti,edma-slots: Number of slots
+- ti,edma-queue-tc-map: List of transfer control to queue mappings
+- ti,edma-queue-priority-map: List of queue priority mappings
+- ti,edma-default-queue: Default queue value
+
+Optional properties:
+- ti,edma-reserved-channels: List of reserved channel regions
+- ti,edma-reserved-slots: List of reserved slot regions
+
+Example:
+
+edma: edma@4900 {
+ #address-cells = 1;
+ #size-cells = 0;
address-cells size-cells are only required when current node is a parent
node it has sibling/child nodes (that too if the child node uses reg
property).
+ reg = 0x4900 0x1;
+ interrupt-parent = intc;
+ interrupts = 12 13 14;
+ compatible = ti,edma3;
+ ti,hwmods = tpcc, tptc0, tptc1, tptc2;
+ #dma-cells = 1;
+ dma-channels = 64;
+ ti,edma-regions = 4;
+ ti,edma-slots = 256;
+ ti,edma-reserved-channels = 0 2
+ 14 2
+ 26 6
+ 48 4
+ 56 8;
+ ti,edma-reserved-slots = 0 2
+ 14 2
+ 26 6
+ 48 4
+ 56 8
+ 64 127;
+ ti,edma-queue-tc-map = 0 0
+ 1 1
+ 2 2;
+ ti,edma-queue-priority-map = 0 0
+ 1 1
+ 2 2;
+ ti,edma-default-queue = 0;
+};
+
--
1.7.9.5
___
Davinci-linux-open-source mailing list
davinci-linux-open-sou...@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Regards,
Gururaja
--
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/13] ARM: edma: add DT and runtime PM support for AM335x
On Thu, Sep 20, 2012 at 20:13:36, Porter, Matt wrote:
Adds support for parsing the TI EDMA DT data into the required
EDMA private API platform data.
Calls runtime PM API only in the DT case in order to unidle the
associated hwmods on AM335x.
Signed-off-by: Matt Porter mpor...@ti.com
---
arch/arm/common/edma.c | 252
--
arch/arm/include/asm/mach/edma.h |8 +-
2 files changed, 244 insertions(+), 16 deletions(-)
The binding documentation should be updated along with the driver
change that does introduce the binding. You could just merged patch #4
and #5.
diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index 001d268..f337f81 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -24,6 +24,13 @@
#include linux/platform_device.h
#include linux/io.h
#include linux/slab.h
+#include linux/edma.h
+#include linux/err.h
+#include linux/of_address.h
+#include linux/of_device.h
+#include linux/of_dma.h
+#include linux/of_irq.h
+#include linux/pm_runtime.h
#include asm/mach/edma.h
@@ -1366,30 +1373,236 @@ void edma_clear_event(unsigned channel)
EXPORT_SYMBOL(edma_clear_event);
/*---*/
+static int edma_of_read_u32_to_s8_array(const struct device_node *np,
+ const char *propname, s8 *out_values,
+ size_t sz)
+{
+ struct property *prop = of_find_property(np, propname, NULL);
+ const __be32 *val;
+
+ if (!prop)
+ return -EINVAL;
+ if (!prop-value)
+ return -ENODATA;
+ if ((sz * sizeof(u32)) prop-length)
+ return -EOVERFLOW;
+
+ val = prop-value;
+
+ while (sz--)
+ *out_values++ = (s8)(be32_to_cpup(val++) 0xff);
+
+ /* Terminate it */
+ *out_values++ = -1;
+ *out_values++ = -1;
+
+ return 0;
+}
+
+static int edma_of_read_u32_to_s16_array(const struct device_node *np,
+ const char *propname, s16 *out_values,
+ size_t sz)
+{
+ struct property *prop = of_find_property(np, propname, NULL);
+ const __be32 *val;
+
+ if (!prop)
+ return -EINVAL;
+ if (!prop-value)
+ return -ENODATA;
+ if ((sz * sizeof(u32)) prop-length)
+ return -EOVERFLOW;
+
+ val = prop-value;
+
+ while (sz--)
+ *out_values++ = (s16)(be32_to_cpup(val++) 0x);
+
+ /* Terminate it */
+ *out_values++ = -1;
+ *out_values++ = -1;
+
+ return 0;
+}
+
+static int edma_of_parse_dt(struct device *dev,
+ struct device_node *node,
+ struct edma_soc_info *pdata)
+{
+ int ret = 0;
+ u32 value;
+ struct property *prop;
+ size_t sz;
+ struct edma_rsv_info *rsv_info;
+ s16 (*rsv_chans)[2], (*rsv_slots)[2];
+ s8 (*queue_tc_map)[2], (*queue_priority_map)[2];
+
+ ret = of_property_read_u32(node, dma-channels, value);
+ if (ret 0)
+ return ret;
+ pdata-n_channel = value;
+
+ ret = of_property_read_u32(node, ti,edma-regions, value);
+ if (ret 0)
+ return ret;
+ pdata-n_region = value;
+
+ ret = of_property_read_u32(node, ti,edma-slots, value);
+ if (ret 0)
+ return ret;
+ pdata-n_slot = value;
+
+ pdata-n_cc = 1;
+ /* This is unused */
+ pdata-n_tc = 3;
+
+ rsv_info =
+ devm_kzalloc(dev, sizeof(struct edma_rsv_info), GFP_KERNEL);
+ if (!rsv_info)
+ return -ENOMEM;
+ pdata-rsv = rsv_info;
+
+ /* Build the reserved channel/slots arrays */
+ prop = of_find_property(node, ti,edma-reserved-channels, sz);
+ if (!prop)
+ return -EINVAL;
+
+ rsv_chans =
+ devm_kzalloc(dev, sz/sizeof(s16) + 2*sizeof(s16), GFP_KERNEL);
+ if (!rsv_chans)
+ return -ENOMEM;
+ pdata-rsv-rsv_chans = rsv_chans;
+
+ ret = edma_of_read_u32_to_s16_array(node, ti,edma-reserved-channels,
+ (s16 *)rsv_chans, sz/sizeof(u32));
+ if (ret 0)
+ return ret;
+
+ prop = of_find_property(node, ti,edma-reserved-slots, sz);
+ if (!prop)
+ return -EINVAL;
+
Binding Documentation mentions edma-reserved-[channels/slots] as optional.
But here the code returns as error if they are not found. Kindly reconfirm
From patch-set 5/13
+Optional properties:
+- ti,edma-reserved-channels: List of reserved channel regions
+- ti,edma-reserved-slots: List of reserved slot regions
+ rsv_slots = devm_kzalloc(dev,
+ sz/sizeof(s16) + 2*sizeof(s16),
+ GFP_KERNEL);
+ if (!rsv_slots)
+ return -ENOMEM;
+
RE: [RFC PATCH 01/13] ARM: davinci: move private EDMA API to arm/common
On Fri, Sep 21, 2012 at 14:59:23, Russell King - ARM Linux wrote: On Thu, Sep 20, 2012 at 10:43:34AM -0400, Matt Porter wrote: Move mach-davinci/dma.c to common/edma.c so it can be used by OMAP (specifically AM33xx atm) as well. This just moves the private EDMA API but does not support OMAP. Signed-off-by: Matt Porter mpor...@ti.com --- arch/arm/Kconfig |1 + arch/arm/common/Kconfig|3 + arch/arm/common/Makefile |1 + arch/arm/common/edma.c | 1588 arch/arm/include/asm/mach/edma.h | 267 + asm/mach should not be used as a dumping ground for platform header files. It is there to provide the interfaces between generic ARM architecture code and platform code. (At least four files that are there at the moment need to be moved out of there - patch series to follow...) Can this be moved to include/linux/platform_data/ ? ___ Davinci-linux-open-source mailing list davinci-linux-open-sou...@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source Regards, Gururaja -- 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 V2] mmc: omap_hsmmc: Pass on the suspend failure to the PM core
From: Vaibhav Bedia vaibhav.be...@ti.com
In some cases mmc_suspend_host() is not able to claim the
host and proceed with the suspend process. The core returns
-EBUSY to the host controller driver. Unfortunately, the
host controller driver does not pass on this information
to the PM core and hence the system suspend process continues.
ret = mmc_suspend_host(host-mmc);
if (ret) {
host-suspended = 0;
if (host-pdata-resume) {
ret = host-pdata-resume(dev, host-slot_id);
The return status from mmc_suspend_host() is overwritten by return
status from host-pdata-resume. So the original return status is lost.
In these cases the MMC core gets to an unexpected state
during resume and multiple issues related to MMC crop up.
1. Host controller driver starts accessing the device registers
before the clocks are enabled which leads to a prefetch abort.
2. A file copy thread which was launched before suspend gets
stuck due to the host not being reclaimed during resume.
To avoid such problems pass on the -EBUSY status to the PM core
from the host controller driver. With this change, MMC core
suspend might still fail but it does not end up making the
system unusable. Suspend gets aborted and the user can try
suspending the system again.
Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com
Signed-off-by: Hebbar, Gururaja gururaja.heb...@ti.com
---
Changes from V1:
- Instead of forcibly returning -EBUSY on err, retain old
status and pass on the same to the caller.
- add more detail to commit message (explanation with code
snippet)
:100644 100644 9afdd20... d9af5f1... M drivers/mmc/host/omap_hsmmc.c
drivers/mmc/host/omap_hsmmc.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 9afdd20..d9af5f1 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -2050,8 +2050,7 @@ static int omap_hsmmc_suspend(struct device *dev)
if (ret) {
host-suspended = 0;
if (host-pdata-resume) {
- ret = host-pdata-resume(dev, host-slot_id);
- if (ret)
+ if (host-pdata-resume(dev, host-slot_id))
dev_dbg(dev, Unmask interrupt failed\n);
}
goto err;
--
1.7.0.4
--
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] mmc: omap_hsmmc: Pass on the suspend failure to the PM core
On Tue, Sep 11, 2012 at 11:13:26, S, Venkatraman wrote: On Tue, Sep 4, 2012 at 6:38 PM, Hebbar, Gururaja gururaja.heb...@ti.com wrote: From: Vaibhav Bedia vaibhav.be...@ti.com In some cases mmc_suspend_host() is not able to claim the host and proceed with the suspend process. The core returns -EBUSY to the host controller driver. Unfortunately, the host controller driver does not pass on this information to the PM core and hence the system suspend process continues. In these cases the MMC core gets to an unexpected state during resume and multiple issues related to MMC crop up. 1. Host controller driver starts accessing the device registers before the clocks are enabled which leads to a prefetch abort. 2. A file copy thread which was launched before suspend gets stuck due to the host not being reclaimed during resume. To avoid such problems pass on the -EBUSY status to the PM core from the host controller driver. With this change, MMC core suspend might still fail but it does not end up making the system unusable. Suspend gets aborted and the user can try suspending the system again. The last time we discussed this, didn't we plan to fix this differently ? Holding the return code of mmc_suspend_host in a separate variable and passing it to the caller of omap_hsmmc_suspend looks more sane to me. I just pushed a new revision (V2) with above changes. I also added extra information (explanation with code snippet). Kindly let me know your review for the same. Regards, Gururaja -- 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] mmc: omap_hsmmc: Enable HSPE bit for high speed cards
On Tue, Sep 04, 2012 at 18:39:11, Hebbar, Gururaja wrote:
HSMMC IP on AM33xx need a special setting to handle High-speed cards.
Other platforms like TI81xx, OMAP4 may need this as-well. This depends
on the HSMMC IP timing closure done for the high speed cards.
From AM335x TRM (SPRUH73F - 18.3.12 Output Signals Generation)
The MMC/SD/SDIO output signals can be driven on either falling edge or
rising edge depending on the SD_HCTL[2] HSPE bit. This feature allows
to reach better timing performance, and thus to increase data transfer
frequency.
There are few pre-requisites for enabling the HSPE bit
- Controller should support High-Speed-Enable Bit and
- Controller should not be using DDR Mode and
- Controller should advertise that it supports High Speed in
capabilities register and
- MMC/SD clock coming out of controller 25MHz
Gentle Ping. Is there any update on this patch?. If not, can this be pulled in.
Signed-off-by: Hebbar, Gururaja gururaja.heb...@ti.com
---
:100644 100644 be76a23... ed271fc... M
Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
:100644 100644 eb3e4d5... 00c658b... M
arch/arm/plat-omap/include/plat/mmc.h
:100644 100644 c3e96a2... 0e14834... Mdrivers/mmc/host/omap_hsmmc.c
.../devicetree/bindings/mmc/ti-omap-hsmmc.txt |1 +
arch/arm/plat-omap/include/plat/mmc.h |1 +
drivers/mmc/host/omap_hsmmc.c | 30
+++-
3 files changed, 31 insertions(+), 1 deletions(-)
diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
index be76a23..ed271fc 100644
--- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -19,6 +19,7 @@ ti,dual-volt: boolean, supports dual voltage cards
supply-name examples are vmmc, vmmc_aux etc
ti,non-removable: non-removable slot (like eMMC)
ti,needs-special-reset: Requires a special softreset sequence
+ti,needs-special-hs-handling: HSMMC IP needs special setting for handling
High Speed
Example:
mmc1: mmc@0x4809c000 {
diff --git a/arch/arm/plat-omap/include/plat/mmc.h
b/arch/arm/plat-omap/include/plat/mmc.h
index eb3e4d5..00c658b 100644
--- a/arch/arm/plat-omap/include/plat/mmc.h
+++ b/arch/arm/plat-omap/include/plat/mmc.h
@@ -127,6 +127,7 @@ struct omap_mmc_platform_data {
/* we can put the features above into this variable */
#define HSMMC_HAS_PBIAS (1 0)
#define HSMMC_HAS_UPDATED_RESET (1 1)
+#define HSMMC_HAS_HSPE_SUPPORT (1 2)
unsigned features;
int switch_pin; /* gpio (card detect) */
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index c3e96a2..0e14834 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -63,6 +63,7 @@
#define VS18 (1 26)
#define VS30 (1 25)
+#define HSS (1 21)
#define SDVS18 (0x5 9)
#define SDVS30 (0x6 9)
#define SDVS33 (0x7 9)
@@ -90,6 +91,7 @@
#define MSBS (1 5)
#define BCE (1 1)
#define FOUR_BIT (1 1)
+#define HSPE (1 2)
#define DDR (1 19)
#define DW8 (1 5)
#define CC 0x1
@@ -490,6 +492,7 @@ static void omap_hsmmc_set_clock(struct omap_hsmmc_host
*host)
struct mmc_ios *ios = host-mmc-ios;
unsigned long regval;
unsigned long timeout;
+ unsigned long clkdiv;
dev_vdbg(mmc_dev(host-mmc), Set clock to %uHz\n, ios-clock);
@@ -497,7 +500,8 @@ static void omap_hsmmc_set_clock(struct omap_hsmmc_host
*host)
regval = OMAP_HSMMC_READ(host-base, SYSCTL);
regval = regval ~(CLKD_MASK | DTO_MASK);
- regval = regval | (calc_divisor(host, ios) 6) | (DTO 16);
+ clkdiv = calc_divisor(host, ios);
+ regval = regval | (clkdiv 6) | (DTO 16);
OMAP_HSMMC_WRITE(host-base, SYSCTL, regval);
OMAP_HSMMC_WRITE(host-base, SYSCTL,
OMAP_HSMMC_READ(host-base, SYSCTL) | ICE);
@@ -508,6 +512,27 @@ static void omap_hsmmc_set_clock(struct omap_hsmmc_host
*host)
time_before(jiffies, timeout))
cpu_relax();
+ /*
+ * Enable High-Speed Support
+ * Pre-Requisites
+ * - Controller should support High-Speed-Enable Bit
+ * - Controller should not be using DDR Mode
+ * - Controller should advertise that it supports High Speed
+ *in capabilities register
+ * - MMC/SD clock coming out of controller 25MHz
+ */
+ if ((mmc_slot(host).features HSMMC_HAS_HSPE_SUPPORT)
+ (ios-timing != MMC_TIMING_UHS_DDR50)
+ ((OMAP_HSMMC_READ
RE: [PATCH] mmc: omap_hsmmc: Pass on the suspend failure to the PM core
On Tue, Sep 11, 2012 at 11:13:26, S, Venkatraman wrote: On Tue, Sep 4, 2012 at 6:38 PM, Hebbar, Gururaja gururaja.heb...@ti.com wrote: From: Vaibhav Bedia vaibhav.be...@ti.com In some cases mmc_suspend_host() is not able to claim the host and proceed with the suspend process. The core returns -EBUSY to the host controller driver. Unfortunately, the host controller driver does not pass on this information to the PM core and hence the system suspend process continues. In these cases the MMC core gets to an unexpected state during resume and multiple issues related to MMC crop up. 1. Host controller driver starts accessing the device registers before the clocks are enabled which leads to a prefetch abort. 2. A file copy thread which was launched before suspend gets stuck due to the host not being reclaimed during resume. To avoid such problems pass on the -EBUSY status to the PM core from the host controller driver. With this change, MMC core suspend might still fail but it does not end up making the system unusable. Suspend gets aborted and the user can try suspending the system again. The last time we discussed this, didn't we plan to fix this differently ? Holding the return code of mmc_suspend_host in a separate variable and passing it to the caller of omap_hsmmc_suspend looks more sane to me. Correct. I missed it. I will reformat the patch and resend it. Regards, Gururaja -- 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] mmc: omap_hsmmc: Enable HSPE bit for high speed cards
On Wed, Sep 12, 2012 at 14:51:34, Krishnamoorthy, Balaji T wrote:
On Tue, Sep 4, 2012 at 6:39 PM, Hebbar, Gururaja gururaja.heb...@ti.com
wrote:
HSMMC IP on AM33xx need a special setting to handle High-speed cards.
Other platforms like TI81xx, OMAP4 may need this as-well. This depends
on the HSMMC IP timing closure done for the high speed cards.
From AM335x TRM (SPRUH73F - 18.3.12 Output Signals Generation)
The MMC/SD/SDIO output signals can be driven on either falling edge or
rising edge depending on the SD_HCTL[2] HSPE bit. This feature allows
to reach better timing performance, and thus to increase data transfer
frequency.
Is this specific to some boards or all board with TI81xx ?
What is the side-effect if not done ?
Platforms like (AM335x) needed this bit to be set in order to sustain high
speed transfers. This was concluded after HSMMC IP timing closure was
completed for High speed Cards.
This was confirmed on high speed cards with very low setup/hold delay (in the
order of nsec) was tested. For AM335x, this bit was to be set to meet setup
requirement and hold requirement for MMC/SD HS cards.
There are few pre-requisites for enabling the HSPE bit
- Controller should support High-Speed-Enable Bit and
- Controller should not be using DDR Mode and
- Controller should advertise that it supports High Speed in
capabilities register and
- MMC/SD clock coming out of controller 25MHz
Signed-off-by: Hebbar, Gururaja gururaja.heb...@ti.com
---
:100644 100644 be76a23... ed271fc... M
Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
:100644 100644 eb3e4d5... 00c658b... M
arch/arm/plat-omap/include/plat/mmc.h
:100644 100644 c3e96a2... 0e14834... M drivers/mmc/host/omap_hsmmc.c
..snip..
..snip..
..snip..
+ /*
+* Enable High-Speed Support
+* Pre-Requisites
+* - Controller should support High-Speed-Enable Bit
+* - Controller should not be using DDR Mode
+* - Controller should advertise that it supports High Speed
+*in capabilities register
+* - MMC/SD clock coming out of controller 25MHz
+*/
+ if ((mmc_slot(host).features HSMMC_HAS_HSPE_SUPPORT)
+ (ios-timing != MMC_TIMING_UHS_DDR50)
+ ((OMAP_HSMMC_READ(host-base, CAPA) HSS) == HSS)) {
+ regval = OMAP_HSMMC_READ(host-base, HCTL);
+ if (clkdiv (clk_get_rate(host-fclk)/clkdiv) 2500)
I think clkdiv is not needed
clk_get_rate(host-fclk)/clkdiv is same as ios-clock
There are chances that the platform is not supporting Clock output from HSMMC
IP greater than 25 MHz even if the card is High Speed. So it would be better
to check host-fclk than ios-clock.
Kindly correct me if I am wrong.
+ regval |= HSPE;
+ else
+ regval = ~HSPE;
+
+ OMAP_HSMMC_WRITE(host-base, HCTL, regval);
+ }
+
omap_hsmmc_start_clock(host);
}
@@ -1701,6 +1726,9 @@ static struct omap_mmc_platform_data
*of_get_hsmmc_pdata(struct device *dev)
if (of_find_property(np, ti,needs-special-reset, NULL))
pdata-slots[0].features |= HSMMC_HAS_UPDATED_RESET;
+ if (of_find_property(np, ti,needs-special-hs-handling, NULL))
+ pdata-slots[0].features |= HSMMC_HAS_HSPE_SUPPORT;
+
return pdata;
}
#else
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Regards,
Gururaja
--
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] mmc: omap_hsmmc: Enable HSPE bit for high speed cards
On Wed, Sep 12, 2012 at 14:19:51, S, Venkatraman wrote: On Tue, Sep 4, 2012 at 6:39 PM, Hebbar, Gururaja gururaja.heb...@ti.com wrote: HSMMC IP on AM33xx need a special setting to handle High-speed cards. Other platforms like TI81xx, OMAP4 may need this as-well. This depends on the HSMMC IP timing closure done for the high speed cards. From AM335x TRM (SPRUH73F - 18.3.12 Output Signals Generation) The MMC/SD/SDIO output signals can be driven on either falling edge or rising edge depending on the SD_HCTL[2] HSPE bit. This feature allows to reach better timing performance, and thus to increase data transfer frequency. There are few pre-requisites for enabling the HSPE bit - Controller should support High-Speed-Enable Bit and - Controller should not be using DDR Mode and - Controller should advertise that it supports High Speed in capabilities register and - MMC/SD clock coming out of controller 25MHz The patch is well written. But then, I don't see a need for a DT binding for this feature. My reasons for DT Binding 1. Not all platforms using this driver has this bit (OMAP2) 2. Not all platforms using this driver needs this bit to be enabled (OMAP4) 3. Platforms which require this bit this to be set needs a method to inform driver. In order to not disturb old/unsupported platforms, I chose this DT method. By definition, HS implies 25MHz or above, so that check seems to be redundant as well. There are chances that the platform Max Clock output from HSMMC IP is than 25 MHz even if the card is High Speed. In such cases it would be better to Confirm that the Clock output is actually 25 MHz Kindly correct me if I am wrong. Meanwhile, I'll check with HSPE enabled on OMAP. Regards, Venkat. Regards, Gururaja -- 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] mmc: omap_hsmmc: Pass on the suspend failure to the PM core
From: Vaibhav Bedia vaibhav.be...@ti.com In some cases mmc_suspend_host() is not able to claim the host and proceed with the suspend process. The core returns -EBUSY to the host controller driver. Unfortunately, the host controller driver does not pass on this information to the PM core and hence the system suspend process continues. In these cases the MMC core gets to an unexpected state during resume and multiple issues related to MMC crop up. 1. Host controller driver starts accessing the device registers before the clocks are enabled which leads to a prefetch abort. 2. A file copy thread which was launched before suspend gets stuck due to the host not being reclaimed during resume. To avoid such problems pass on the -EBUSY status to the PM core from the host controller driver. With this change, MMC core suspend might still fail but it does not end up making the system unusable. Suspend gets aborted and the user can try suspending the system again. Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com Signed-off-by: Hebbar, Gururaja gururaja.heb...@ti.com --- :100644 100644 9afdd20... c3e96a2... M drivers/mmc/host/omap_hsmmc.c drivers/mmc/host/omap_hsmmc.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c index 9afdd20..c3e96a2 100644 --- a/drivers/mmc/host/omap_hsmmc.c +++ b/drivers/mmc/host/omap_hsmmc.c @@ -2054,6 +2054,7 @@ static int omap_hsmmc_suspend(struct device *dev) if (ret) dev_dbg(dev, Unmask interrupt failed\n); } + ret = -EBUSY; goto err; } -- 1.7.1 -- 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] mmc: omap_hsmmc: Enable HSPE bit for high speed cards
HSMMC IP on AM33xx need a special setting to handle High-speed cards.
Other platforms like TI81xx, OMAP4 may need this as-well. This depends
on the HSMMC IP timing closure done for the high speed cards.
From AM335x TRM (SPRUH73F - 18.3.12 Output Signals Generation)
The MMC/SD/SDIO output signals can be driven on either falling edge or
rising edge depending on the SD_HCTL[2] HSPE bit. This feature allows
to reach better timing performance, and thus to increase data transfer
frequency.
There are few pre-requisites for enabling the HSPE bit
- Controller should support High-Speed-Enable Bit and
- Controller should not be using DDR Mode and
- Controller should advertise that it supports High Speed in
capabilities register and
- MMC/SD clock coming out of controller 25MHz
Signed-off-by: Hebbar, Gururaja gururaja.heb...@ti.com
---
:100644 100644 be76a23... ed271fc... M
Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
:100644 100644 eb3e4d5... 00c658b... M arch/arm/plat-omap/include/plat/mmc.h
:100644 100644 c3e96a2... 0e14834... M drivers/mmc/host/omap_hsmmc.c
.../devicetree/bindings/mmc/ti-omap-hsmmc.txt |1 +
arch/arm/plat-omap/include/plat/mmc.h |1 +
drivers/mmc/host/omap_hsmmc.c | 30 +++-
3 files changed, 31 insertions(+), 1 deletions(-)
diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
index be76a23..ed271fc 100644
--- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -19,6 +19,7 @@ ti,dual-volt: boolean, supports dual voltage cards
supply-name examples are vmmc, vmmc_aux etc
ti,non-removable: non-removable slot (like eMMC)
ti,needs-special-reset: Requires a special softreset sequence
+ti,needs-special-hs-handling: HSMMC IP needs special setting for handling High
Speed
Example:
mmc1: mmc@0x4809c000 {
diff --git a/arch/arm/plat-omap/include/plat/mmc.h
b/arch/arm/plat-omap/include/plat/mmc.h
index eb3e4d5..00c658b 100644
--- a/arch/arm/plat-omap/include/plat/mmc.h
+++ b/arch/arm/plat-omap/include/plat/mmc.h
@@ -127,6 +127,7 @@ struct omap_mmc_platform_data {
/* we can put the features above into this variable */
#define HSMMC_HAS_PBIAS(1 0)
#define HSMMC_HAS_UPDATED_RESET(1 1)
+#define HSMMC_HAS_HSPE_SUPPORT (1 2)
unsigned features;
int switch_pin; /* gpio (card detect) */
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index c3e96a2..0e14834 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -63,6 +63,7 @@
#define VS18 (1 26)
#define VS30 (1 25)
+#define HSS(1 21)
#define SDVS18 (0x5 9)
#define SDVS30 (0x6 9)
#define SDVS33 (0x7 9)
@@ -90,6 +91,7 @@
#define MSBS (1 5)
#define BCE(1 1)
#define FOUR_BIT (1 1)
+#define HSPE (1 2)
#define DDR(1 19)
#define DW8(1 5)
#define CC 0x1
@@ -490,6 +492,7 @@ static void omap_hsmmc_set_clock(struct omap_hsmmc_host
*host)
struct mmc_ios *ios = host-mmc-ios;
unsigned long regval;
unsigned long timeout;
+ unsigned long clkdiv;
dev_vdbg(mmc_dev(host-mmc), Set clock to %uHz\n, ios-clock);
@@ -497,7 +500,8 @@ static void omap_hsmmc_set_clock(struct omap_hsmmc_host
*host)
regval = OMAP_HSMMC_READ(host-base, SYSCTL);
regval = regval ~(CLKD_MASK | DTO_MASK);
- regval = regval | (calc_divisor(host, ios) 6) | (DTO 16);
+ clkdiv = calc_divisor(host, ios);
+ regval = regval | (clkdiv 6) | (DTO 16);
OMAP_HSMMC_WRITE(host-base, SYSCTL, regval);
OMAP_HSMMC_WRITE(host-base, SYSCTL,
OMAP_HSMMC_READ(host-base, SYSCTL) | ICE);
@@ -508,6 +512,27 @@ static void omap_hsmmc_set_clock(struct omap_hsmmc_host
*host)
time_before(jiffies, timeout))
cpu_relax();
+ /*
+* Enable High-Speed Support
+* Pre-Requisites
+* - Controller should support High-Speed-Enable Bit
+* - Controller should not be using DDR Mode
+* - Controller should advertise that it supports High Speed
+*in capabilities register
+* - MMC/SD clock coming out of controller 25MHz
+*/
+ if ((mmc_slot(host).features HSMMC_HAS_HSPE_SUPPORT)
+ (ios-timing != MMC_TIMING_UHS_DDR50)
+ ((OMAP_HSMMC_READ(host-base, CAPA) HSS) == HSS)) {
+ regval = OMAP_HSMMC_READ(host-base, HCTL);
+ if (clkdiv (clk_get_rate(host-fclk)/clkdiv) 2500)
+ regval |= HSPE
RE: [PATCHv6 14/24] i2c: omap: always return IRQ_HANDLED
On Tue, Aug 14, 2012 at 19:48:56, Datta, Shubhrajyoti wrote:
From: Felipe Balbi ba...@ti.com
otherwise we could get our IRQ line disabled due
to many spurious IRQs.
Patch description should be readable by itself. It is not a continuation of
subject line.
Signed-off-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 80ebcf5..eb6898b 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -962,7 +962,7 @@ complete:
}
} while (stat);
- return count ? IRQ_HANDLED : IRQ_NONE;
+ return IRQ_HANDLED;
}
static const struct i2c_algorithm omap_i2c_algo = {
--
1.7.5.4
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Regards,
Gururaja
--
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: arm system wide sram support
Ping... any updates please On Fri, Jul 13, 2012 at 15:25:11, Hebbar, Gururaja wrote: Hi, I have started working on Audio support for TI AM335x SOC. It uses the same McASP IP as in Davinci platform. The mcasp driver (davinci-pcm) uses SRAM api's. Currently OMAP Davinci have their own allocation systems, and both with their own ways of copying functions into the SRAM. A Patch was floating in the ML which supported merging this functionality as a unified consolidated sram support. https://patchwork.kernel.org/patch/961222/ However I believe the patch was not accepted and I couldn't find any updates on it later. Can someone give me some pointers about the status for this patch or If there has been any update on this? Is anyone working on this consolidation? Thanks Regards Gururaja ___ Davinci-linux-open-source mailing list davinci-linux-open-sou...@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source Regards, Gururaja -- 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
arm system wide sram support
Hi, I have started working on Audio support for TI AM335x SOC. It uses the same McASP IP as in Davinci platform. The mcasp driver (davinci-pcm) uses SRAM api's. Currently OMAP Davinci have their own allocation systems, and both with their own ways of copying functions into the SRAM. A Patch was floating in the ML which supported merging this functionality as a unified consolidated sram support. https://patchwork.kernel.org/patch/961222/ However I believe the patch was not accepted and I couldn't find any updates on it later. Can someone give me some pointers about the status for this patch or If there has been any update on this? Is anyone working on this consolidation? Thanks Regards Gururaja
RE: [PATCHv7 14/18] I2C: OMAP: Use SET_RUNTIME_PM_OPS
Bablpi,
On Wed, Apr 11, 2012 at 17:05:38, Balbi, Felipe wrote:
On Wed, Apr 11, 2012 at 04:42:52PM +0530, Shubhrajyoti D wrote:
Use SET_RUNTIME_PM_OPS macro to set runtime functions.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 11 ---
1 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index dd65416..28de1d2 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1217,15 +1217,12 @@ static int omap_i2c_runtime_resume(struct device
*dev)
return 0;
}
+#endif
static struct dev_pm_ops omap_i2c_pm_ops = {
- .runtime_suspend = omap_i2c_runtime_suspend,
- .runtime_resume = omap_i2c_runtime_resume,
+ SET_RUNTIME_PM_OPS(omap_i2c_runtime_suspend,
+ omap_i2c_runtime_resume, NULL)
};
-#define OMAP_I2C_PM_OPS (omap_i2c_pm_ops)
-#else
-#define OMAP_I2C_PM_OPS NULL
-#endif
I think you should keep this define, otherwise the pm pointer will
always be valid.
No. using SET_RUNTIME_PM_OPS will make it NULL when !CONFIG_PM_RUNTIME
Kindly correct me if I am wrong.
--
balbi
Regards,
Gururaja
--
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: [PATCHv7 14/18] I2C: OMAP: Use SET_RUNTIME_PM_OPS
On Wed, Apr 11, 2012 at 17:40:58, Balbi, Felipe wrote:
On Wed, Apr 11, 2012 at 12:09:22PM +, Hebbar, Gururaja wrote:
Bablpi,
On Wed, Apr 11, 2012 at 17:05:38, Balbi, Felipe wrote:
On Wed, Apr 11, 2012 at 04:42:52PM +0530, Shubhrajyoti D wrote:
Use SET_RUNTIME_PM_OPS macro to set runtime functions.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/i2c/busses/i2c-omap.c | 11 ---
1 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c
b/drivers/i2c/busses/i2c-omap.c
index dd65416..28de1d2 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1217,15 +1217,12 @@ static int omap_i2c_runtime_resume(struct
device *dev)
return 0;
}
+#endif
static struct dev_pm_ops omap_i2c_pm_ops = {
- .runtime_suspend = omap_i2c_runtime_suspend,
- .runtime_resume = omap_i2c_runtime_resume,
+ SET_RUNTIME_PM_OPS(omap_i2c_runtime_suspend,
+ omap_i2c_runtime_resume, NULL)
};
-#define OMAP_I2C_PM_OPS (omap_i2c_pm_ops)
-#else
-#define OMAP_I2C_PM_OPS NULL
-#endif
I think you should keep this define, otherwise the pm pointer will
always be valid.
No. using SET_RUNTIME_PM_OPS will make it NULL when !CONFIG_PM_RUNTIME
Kindly correct me if I am wrong.
you will have a defined structure with NULL members, but the structure
itself is still valid.
Oops. You are correct. I stand corrected.
--
balbi
Regards,
Gururaja
--
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 v2 5/8] mmc: host: omap_hsmmc: trivial cleanups
On Fri, Mar 16, 2012 at 19:09:01, S, Venkatraman wrote: From: Felipe Balbi ba...@ti.com a bunch of non-functional cleanups to the omap_hsmmc driver. It basically decreases indentation level, drop unneeded s/unneeded/unneeded. Better to use unnecessary dereferences and drop unneded accesses to the platform_device Same as above structure. Signed-off-by: Felipe Balbi ba...@ti.com Signed-off-by: Venkatraman S svenk...@ti.com --- ..snip.. ..snip.. } -- 1.7.10.rc0.41.gfa678 -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Regards, Gururaja -- 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 00/10] I2C updates
Hi, I am interested in testing these patches on AM335x. Do you have a tree with these patches applied so that I can pull. On Fri, Feb 10, 2012 at 19:29:55, Datta, Shubhrajyoti wrote: This patch series colates the various i2c updates into a series. Since it is collection of various patches the version info is not retained, however most of them undergone multiple versions. This is rebased to linus head commit 63082402968f4b73f10b28a8ac1f3da821aeb82d The patch series does the following - Warn fixes if CONFIG_PM_RUNTIME is not selected. - I2C register restore only if context if the context is lost - Bus busy recovery mechanism. - the reset is not done in init. Tested on omap4sdp and omap3sdp. Cc: Kevin Hilman khil...@ti.com Cc: Ben Dooks ben-li...@fluff.org Jon Hunter (1): I2C: OMAP: Correct I2C revision for OMAP3 Shubhrajyoti D (8): I2C : OMAP : make omap_i2c_unidle/idle functions depend on CONFIG_PM_RUNTIME OMAP : I2C : Remove reset at init OMAP: I2C: I2C register restore only if context is lost OMAP: I2C: Fix the interrupt clearing in OMAP4 OMAP: I2C: Fix the mismatch of pm_runtime enable and disable OMAP: I2C: Optimise the remove code OMAP: I2C: Fix the error handling I2C: OMAP: Don't check if wait_for_completion_timeout() returns less than zero Vikram Pandita (1): I2C: OMAP: Recover from Bus Busy condition drivers/i2c/busses/i2c-omap.c | 173 - 1 files changed, 101 insertions(+), 72 deletions(-) Regards, Gururaja -- 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 v9 00/25] gpio/omap: driver cleanup and fixes
Tarun, I am interested in testing these patches on AM335x. Do you have a tree with these patches applied so that I can pull. On Thu, Feb 02, 2012 at 23:00:26, DebBarma, Tarun Kanti wrote: The following changes since commit 62aa2b537c6f5957afd98e29f96897419ed5ebab: Linus Torvalds (1): Linux 3.3-rc2 are available in the git repository at: http://gitorious.org/~tarunkanti/omap-sw-develoment/tarunkantis-linux-omap-dev Branch: for_3.4/gpio_cleanup_fixes_v9 This series is continuation of cleanup of OMAP GPIO driver and fixes. The cleanup include getting rid of cpu_is_* checks wherever possible, use of gpio_bank list instead of static array, use of unique platform specific value associated data member to OMAP platforms to avoid cpu_is_* checks. The series also include PM runtime support. Power Tests a) OMAP3430SDP - Modify board-3430sdp.c file to have multiple GPIO modules active with debounce timeout enabled. - Enable CPU-Idle - Enable UART timeouts - Enable offmode - echo mem /sys/power/state - Verify retention and offmode count increment Used following patches to avoid exception during system suspend:- [PATCH RFC 1/2] mtd : Prevent the NULL pointer access [PATCH RFC 2/2] mtd : Make the mtd_suspend return 0 if the suspend is not implemented # echo mem /sys/power/state [ 47.128021] PM: Syncing filesystems ... done. [ 47.144104] Freezing user space processes ... (elapsed 0.01 seconds) done. [ 47.168243] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) don e. [ 47.205139] Unable to handle kernel NULL pointer dereference at virtual addre ss 00a0 [ 47.213317] pgd = deaac000 [ 47.216033] [00a0] *pgd=9e932831, *pte=, *ppte= [ 47.222381] Internal error: Oops: 17 [#1] SMP [ 47.226745] Modules linked in: [ 47.229827] CPU: 0Not tainted (3.3.0-rc2-00031-g12c5c5c #235) [ 47.236022] PC is at mtd_cls_suspend+0x8/0x20 [ 47.240386] LR is at mtd_cls_suspend+0x8/0x20 [ 47.244750] pc : [c02e78f8]lr : [c02e78f8]psr: a013 [ 47.244750] sp : dea1fe60 ip : fp : c0ee7d40 [ 47.256256] r10: c0ee7cf0 r9 : r8 : c02e78f0 [ 47.261474] r7 : r6 : r5 : 0002 r4 : dea45800 [ 47.268005] r3 : deb4cac0 r2 : r1 : 0002 r0 : [ 47.274536] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 47.281677] Control: 10c5387d Table: 9eaac019 DAC: 0015 [ 47.287445] Process sh (pid: 1177, stack limit = 0xdea1e2f8) [ 47.293090] Stack: (0xdea1fe60 to 0xdea2) [...] b) ZOOM3 - Enable CPU-Idle - Enable UART timeout - echo mem /sys/power/state - Wakeup system using serial keyboard - Verify retention count increment Functional Tests - Done on OMAP2430, OMAP3430SDP, ZOOM3, OMAP4430 Bootup Test - Done on OMAP1710 Used following patch to fix OMAP1 build error:- [PATCH] i2c: OMAP: Fix OMAP1 build error [..] [..] Charulatha V (8): gpio/omap: remove dependency on gpio_bank_count gpio/omap: use flag to identify wakeup domain gpio/omap: make gpio_context part of gpio_bank structure gpio/omap: make non-wakeup GPIO part of pdata gpio/omap: avoid cpu checks during module ena/disable gpio/omap: use pinctrl offset instead of macro gpio/omap: remove bank-method METHOD_* macros gpio/omap: fix bankwidth for OMAP7xx MPUIO Nishanth Menon (4): gpio/omap: save and restore debounce registers gpio/omap: enable irq at the end of all configuration in restore gpio/omap: restore OE only after setting the output level gpio/omap: handle set_dataout reg capable IP on restore Tarun Kanti DebBarma (13): gpio/omap: handle save/restore context in GPIO driver gpio/omap: further cleanup using wkup_en register gpio/omap: use level/edge detect reg offsets gpio/omap: remove hardcoded offsets in context save/restore gpio/omap: cleanup set_gpio_triggering function gpio/omap: cleanup omap_gpio_mod_init function gpio/omap: remove unnecessary bit-masking for read access gpio/omap: use pm-runtime framework gpio/omap: optimize suspend and resume functions gpio/omap: cleanup prepare_for_idle and resume_after_idle gpio/omap: fix debounce clock handling gpio/omap: fix incorrect access of debounce module gpio/omap: remove omap_gpio_save_context overhead arch/arm/mach-omap1/gpio15xx.c |7 +- arch/arm/mach-omap1/gpio16xx.c | 47 ++- arch/arm/mach-omap1/gpio7xx.c | 14 +- arch/arm/mach-omap2/gpio.c | 36 +- arch/arm/mach-omap2/pm34xx.c | 14 - arch/arm/plat-omap/include/plat/gpio.h | 29 +- drivers/gpio/gpio-omap.c | 1099 +--- 7
RE: [PATCH v9 00/25] gpio/omap: driver cleanup and fixes
Hi, On Fri, Feb 03, 2012 at 15:29:49, DebBarma, Tarun Kanti wrote: On Fri, Feb 3, 2012 at 2:51 PM, Hebbar, Gururaja gururaja.heb...@ti.com wrote: Tarun, I am interested in testing these patches on AM335x. Do you have a tree with these patches applied so that I can pull. You can find the series here:- git://gitorious.org/~tarunkanti/omap-sw-develoment/tarunkantis-linux-oma p-dev for_3.4/gpio_cleanup_fixes_v9 I am unable to download from this repo. The Gitorious web page fails to show the tree and gives 500 error downloading using https protocol fails with below error. ghebbar@linux-psp-server:~/projects/linux-gits/gitorious-omap$ git remote add omap-gpio2 https://git.gitorious.org/omap-sw-develoment/linux-omap-dev.git ghebbar@linux-psp-server:~/projects/linux-gits/gitorious-omap$ git fetch omap-gpio2 error: Unable to get pack index https://git.gitorious.org/omap-sw-develoment/linux-omap-dev.git/objects/pack/pack-a461f67f3067aa122c09f38cf55346152c9fafb8.idx error: Unable to get pack index https://git.gitorious.org/omap-sw-develoment/linux-omap-dev.git/objects/pack/pack-a66a5d34b6388e1b0c6b49fe4a029cbf755b17c7.idx error: Unable to get pack index https://git.gitorious.org/omap-sw-develoment/linux-omap-dev.git/objects/pack/pack-952401733bd66c72bc947b54ad5a04ca8edfff2a.idx error: Unable to get pack index https://git.gitorious.org/omap-sw-develoment/linux-omap-dev.git/objects/pack/pack-1f38918dfb5427f9b79b88d7c6cda15e85c2ad92.idx error: Unable to get pack file https://git.gitorious.org/omap-sw-develoment/linux-omap-dev.git/objects/pack/pack-2e39094e5e34e6ce642fc2513727a2025b23f8c7.pack GnuTLS recv error (-9): A TLS packet with unexpected length was received. error: Unable to find f5af8c1f05d8a1e27ca910285da3fee28eb5acce under https://git.gitorious.org/omap-sw-develoment/linux-omap-dev.git Cannot obtain needed object f5af8c1f05d8a1e27ca910285da3fee28eb5acce while processing commit 7e0e6be8759e6423a4f97b4bbc5e9fec0e5cfde3. error: Fetch failed. ghebbar@linux-psp-server:~/projects/linux-gits/gitorious-omap$ git fetch omap-gpio2 error: Unable to get pack index https://git.gitorious.org/omap-sw-develoment/linux-omap-dev.git/objects/pack/pack-a461f67f3067aa122c09f38cf55346152c9fafb8.idx error: wrong index v2 file size in .git/objects/pack/pack-952401733bd66c72bc947b54ad5a04ca8edfff2a.idx error: .git/objects/pack/pack-2e39094e5e34e6ce642fc2513727a2025b23f8c7.pack SHA1 checksum mismatch error: inflate: data stream error (invalid distance too far back) is there any issue with the repo. -- Tarun On Thu, Feb 02, 2012 at 23:00:26, DebBarma, Tarun Kanti wrote: The following changes since commit 62aa2b537c6f5957afd98e29f96897419ed5ebab: Linus Torvalds (1): Linux 3.3-rc2 are available in the git repository at: http://gitorious.org/~tarunkanti/omap-sw-develoment/tarunkantis-linux-om ap-dev http://gitorious.org/%7Etarunkanti/omap-sw-develoment/tarunkantis-linux -omap-dev Branch: for_3.4/gpio_cleanup_fixes_v9 This series is continuation of cleanup of OMAP GPIO driver and fixes. The cleanup include getting rid of cpu_is_* checks wherever possible, use of gpio_bank list instead of static array, use of unique platform specific value associated data member to OMAP platforms to avoid cpu_is_* checks. The series also include PM runtime support. Power Tests a) OMAP3430SDP - Modify board-3430sdp.c file to have multiple GPIO modules active with debounce timeout enabled. - Enable CPU-Idle - Enable UART timeouts - Enable offmode - echo mem /sys/power/state - Verify retention and offmode count increment Used following patches to avoid exception during system suspend:- [PATCH RFC 1/2] mtd : Prevent the NULL pointer access [PATCH RFC 2/2] mtd : Make the mtd_suspend return 0 if the suspend is not implemented # echo mem /sys/power/state [ 47.128021] PM: Syncing filesystems ... done. [ 47.144104] Freezing user space processes ... (elapsed 0.01 seconds) done. [ 47.168243] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) don e. [ 47.205139] Unable to handle kernel NULL pointer dereference at virtual addre ss 00a0 [ 47.213317] pgd = deaac000 [ 47.216033] [00a0] *pgd=9e932831, *pte=, *ppte= [ 47.222381] Internal error: Oops: 17 [#1] SMP [ 47.226745] Modules linked in: [ 47.229827] CPU: 0Not tainted (3.3.0-rc2-00031-g12c5c5c #235) [ 47.236022] PC is at mtd_cls_suspend+0x8/0x20 [ 47.240386] LR is at mtd_cls_suspend+0x8/0x20 [ 47.244750] pc : [c02e78f8]lr : [c02e78f8]psr: a013 [ 47.244750] sp : dea1fe60 ip
RE: [PATCH] mmc: omap: remove clock rate hard coding
On Tue, Dec 20, 2011 at 15:12, S, Venkatraman wrote:
From: Balaji TK balaj...@ti.com
MMC master clock rate can vary for each instance of the MMC controller
on the device. Use clk_get_rate instead to get the value.
Signed-off-by: Balaji TK balaj...@ti.com
Reviewed-by: Venkatraman S svenk...@ti.com
---
drivers/mmc/host/omap_hsmmc.c |7 +++
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index d5fe43d..5b35c7e 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -120,7 +120,6 @@
#define MMC_AUTOSUSPEND_DELAY100
#define MMC_TIMEOUT_MS 20
-#define OMAP_MMC_MASTER_CLOCK9600
#define OMAP_MMC_MIN_CLOCK 40
#define OMAP_MMC_MAX_CLOCK 5200
#define DRIVER_NAME omap_hsmmc
@@ -598,12 +597,12 @@ static void omap_hsmmc_disable_irq(struct
omap_hsmmc_host *host)
}
/* Calculate divisor for the given clock frequency */
-static u16 calc_divisor(struct mmc_ios *ios)
+static u16 calc_divisor(struct omap_hsmmc_host *host, struct mmc_ios *ios)
{
u16 dsor = 0;
if (ios-clock) {
- dsor = DIV_ROUND_UP(OMAP_MMC_MASTER_CLOCK, ios-clock);
+ dsor = DIV_ROUND_UP(clk_get_rate(host-fclk), ios-clock);
if (dsor 250)
dsor = 250;
}
@@ -623,7 +622,7 @@ static void omap_hsmmc_set_clock(struct omap_hsmmc_host
*host)
regval = OMAP_HSMMC_READ(host-base, SYSCTL);
regval = regval ~(CLKD_MASK | DTO_MASK);
- regval = regval | (calc_divisor(ios) 6) | (DTO 16);
+ regval = regval | (calc_divisor(host, ios) 6) | (DTO 16);
OMAP_HSMMC_WRITE(host-base, SYSCTL, regval);
OMAP_HSMMC_WRITE(host-base, SYSCTL,
OMAP_HSMMC_READ(host-base, SYSCTL) | ICE);
--
1.7.1
--
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
Tested on AM335x platform.
Tested-by: Hebbar, Gururaja gururaja.heb...@ti.com
Regards,
Gururaja
--
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
