Re: [PATCH 3/3] ARM: dts: EMIF and LPDDR2 device tree data for OMAP5 boards
+ devicetree-discuss
Hi Benoit,
On Wednesday 10 October 2012 08:31 PM, Benoit Cousson wrote:
On 10/10/2012 02:05 PM, Lokesh Vutla wrote:
Device tree data for the EMIF sdram controllers in OMAP5
and LPDDR2 memory devices attached to OMAP5 boards.
Nit: Could you make a sentence with a verb to explain what you are doing
in this patch.
I am really sorry about this.
I ll make sure that all patch descriptions will be clear in V2 of this
patch series.
In this patch I am adding device tree data for LPDDR2 memory devices
attached to omap5-sevm and also adding device tree data for EMIF sdram
controllers in OMAP5.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
arch/arm/boot/dts/lpddr2_data.dtsi | 64 +++-
arch/arm/boot/dts/omap5-evm.dts| 11 +++
arch/arm/boot/dts/omap5.dtsi | 18 ++
3 files changed, 92 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/lpddr2_data.dtsi
b/arch/arm/boot/dts/lpddr2_data.dtsi
index f97f70f..8e8c1bc 100644
--- a/arch/arm/boot/dts/lpddr2_data.dtsi
+++ b/arch/arm/boot/dts/lpddr2_data.dtsi
@@ -3,7 +3,7 @@
*/
/ {
- elpida_ECB240ABACN: lpddr2 {
+ elpida_ECB240ABACN: lpddr2@0 {
compatible = Elpida,ECB240ABACN,jedec,lpddr2-s4;
density = 2048;
io-width= 32;
@@ -64,4 +64,66 @@
tDQSCK-max-derated = 6000;
};
};
+
+ samsung_K3PE0E000B: lpddr2@1 {
I'm confused now, why are you reusing the same lpddr2_data.dtsi file?
You should create a file per memory. That will make the reuse much easier.
If the goal of your first patch was to do that, it is then the wrong
approach.
Yes, I wanted to group data for all lppdr2 devices in a single file than
creating separate file for each device.
May be a dumb question, Why can't we group data for all the lpddr2
devices in a single file?
+ compatible = Samsung,K3PE0E000B,jedec,lpddr2-s4;
+ density = 4096;
+ io-width= 32;
+
+ tRPab-min-tck = 3;
+ tRCD-min-tck= 3;
+ tWR-min-tck = 3;
+ tRASmin-min-tck = 3;
+ tRRD-min-tck= 2;
+ tWTR-min-tck= 2;
+ tXP-min-tck = 2;
+ tRTP-min-tck= 2;
+ tCKE-min-tck= 3;
+ tCKESR-min-tck = 3;
+ tFAW-min-tck= 8;
+
+ timings_samsung_K3PE0E000B_533mhz: lpddr2-timings@0 {
+ compatible = jedec,lpddr2-timings;
+ min-freq= 1000;
+ max-freq= 5;
+ tRPab = 21000;
+ tRCD= 18000;
+ tWR = 15000;
+ tRAS-min= 42000;
+ tRRD= 1;
+ tWTR= 7500;
+ tXP = 7500;
+ tRTP= 7500;
+ tCKESR = 15000;
+ tDQSCK-max = 5500;
+ tFAW= 5;
+ tZQCS = 9;
+ tZQCL = 36;
+ tZQinit = 100;
+ tRAS-max-ns = 7;
+ tDQSCK-max-derated = 5620;
+ };
+
+ timings_samsung_K3PE0E000B_266mhz: lpddr2-timings@1 {
+ compatible = jedec,lpddr2-timings;
+ min-freq= 1000;
+ max-freq= 2;
+ tRPab = 21000;
+ tRCD= 18000;
+ tWR = 15000;
+ tRAS-min= 42000;
+ tRRD= 1;
+ tWTR= 7500;
+ tXP = 7500;
+ tRTP= 7500;
+ tCKESR = 15000;
+ tDQSCK-max = 5500;
+ tFAW= 5;
+ tZQCS = 9;
+ tZQCL = 36;
+ tZQinit = 100;
+ tRAS-max-ns = 7;
+ tDQSCK-max-derated = 6000;
+ };
+ };
};
diff --git a/arch/arm/boot/dts/omap5-evm.dts b/arch/arm/boot/dts/omap5-evm.dts
index 6f87e1a..8a952f8 100644
--- a/arch/arm/boot/dts/omap5-evm.dts
+++ b/arch/arm/boot/dts/omap5-evm.dts
@@ -8,6 +8,7 @@
/dts-v1/;
/include/ omap5.dtsi
+/include/ lpddr2_data.dtsi
/ {
model = TI OMAP5 EVM board;
@@ -82,3 +83,13 @@
0x020700d9; /* SEARCH */
Re: [PATCH 1/3] ARM: dts: Renaming elpida_ecb240abacn.dtsi as lpddr2_data.dtsi
+ devicetree-discuss
Hi Benoit,
On Wednesday 10 October 2012 08:18 PM, Benoit Cousson wrote:
Hi Lokesh,
On 10/10/2012 02:05 PM, Lokesh Vutla wrote:
Renaming elpida_ecb240abacn.dtsi file generic, so that the
same file can be reused for other parts from different vendors.
Could you elaborate a little bit?
Are these settings purely reflecting lpddr2 spec timings?
The basic idea is to group data for all the lpddr2 devices in a single
file instead of creating separate file for each lpddr2 device.
Right now the file elpida_ecb240abacn.dtsi contains only data for
lpddr2-s4 2G parts from Elpida.
I wanted to add data for lpddr2-s4 4G parts from Samsung.
So I renamed the file elpida_ecb240abacn.dtsi as lpddr2_data.dtsi.
Please let me know if more clarification is needed.
Thanks,
Lokesh
Regards,
Benoit
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
arch/arm/boot/dts/{elpida_ecb240abacn.dtsi = lpddr2_data.dtsi} |0
arch/arm/boot/dts/omap4-panda.dts |2 +-
arch/arm/boot/dts/omap4-sdp.dts |2 +-
3 files changed, 2 insertions(+), 2 deletions(-)
rename arch/arm/boot/dts/{elpida_ecb240abacn.dtsi = lpddr2_data.dtsi} (100%)
diff --git a/arch/arm/boot/dts/elpida_ecb240abacn.dtsi
b/arch/arm/boot/dts/lpddr2_data.dtsi
similarity index 100%
rename from arch/arm/boot/dts/elpida_ecb240abacn.dtsi
rename to arch/arm/boot/dts/lpddr2_data.dtsi
diff --git a/arch/arm/boot/dts/omap4-panda.dts
b/arch/arm/boot/dts/omap4-panda.dts
index 20b966e..09d3a32 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -8,7 +8,7 @@
/dts-v1/;
/include/ omap4.dtsi
-/include/ elpida_ecb240abacn.dtsi
+/include/ lpddr2_data.dtsi
/ {
model = TI OMAP4 PandaBoard;
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 94a23b3..dd749fc 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -8,7 +8,7 @@
/dts-v1/;
/include/ omap4.dtsi
-/include/ elpida_ecb240abacn.dtsi
+/include/ lpddr2_data.dtsi
/ {
model = TI OMAP4 SDP board;
--
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
Error when building modules for omap2plus_defconfig in mainline
Daily build on Linus's tree is failing for the past 2-3 days make modules with omap2plus_defconfig.. ERROR: snd_hwparams_to_dma_slave_config [sound/soc/omap/snd-soc-omap.ko] undefined! ERROR: snd_dmaengine_pcm_pointer [sound/soc/omap/snd-soc-omap.ko] undefined! ERROR: snd_dmaengine_pcm_open [sound/soc/omap/snd-soc-omap.ko] undefined! ERROR: snd_dmaengine_pcm_close [sound/soc/omap/snd-soc-omap.ko] undefined! ERROR: snd_dmaengine_pcm_get_chan [sound/soc/omap/snd-soc-omap.ko] undefined! ERROR: snd_dmaengine_pcm_trigger [sound/soc/omap/snd-soc-omap.ko] undefined! make[2]: *** [__modpost] Error 1 make[1]: *** [modules] Error 2 make: *** [sub-make] Error 2 Just wanted to check if a fix is already on the way for -rc1 or someone is aware of it.. Thanks, Venkat. -- 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/3] usb: xhci: Add the suspend/resume functionality
On Wed, Oct 10, 2012 at 10:58:16AM -0700, Sarah Sharp wrote: On Wed, Oct 10, 2012 at 07:35:48PM +0530, Vikas C Sajjan wrote: From: Vikas Sajjan vikas.saj...@linaro.org Adding the suspend and resume functionality for the XHCI driver Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com Signed-off-by: Vikas C Sajjan vikas.saj...@linaro.org CC: Doug Anderson diand...@chromium.org Acked-by: Sarah Sharp sarah.a.sh...@linux.intel.com Felipe, you want to take this? I can, will get to these patches in a while. -- balbi signature.asc Description: Digital signature
Re: [PATCH 3/3] exynos5: usb: dwc3: Add the suspend/resume functionality
Hi,
On Wed, Oct 10, 2012 at 07:35:49PM +0530, Vikas C Sajjan wrote:
From: Vikas Sajjan vikas.saj...@linaro.org
Adding the suspend and resume functionality to exynos dwc3 driver
Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
Signed-off-by: Vikas C Sajjan vikas.saj...@linaro.org
CC: Doug Anderson diand...@chromium.org
---
drivers/usb/dwc3/dwc3-exynos.c | 60
1 files changed, 60 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
index ca65978..1154cee 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -15,6 +15,7 @@
#include linux/module.h
#include linux/kernel.h
#include linux/slab.h
+#include linux/pm_runtime.h
#include linux/platform_device.h
#include linux/platform_data/dwc3-exynos.h
#include linux/dma-mapping.h
@@ -200,11 +201,70 @@ static int __devexit dwc3_exynos_remove(struct
platform_device *pdev)
return 0;
}
+#ifdef CONFIG_PM
+static int dwc3_exynos_suspend(struct device *dev)
+{
+ struct dwc3_exynos_data *pdata = dev-platform_data;
+ struct dwc3_exynos *exynos;
+ struct platform_device *pdev = to_platform_device(dev);
you shouldn't have to access platform device here.
+
+ exynos = dev_get_drvdata(dev);
+
+ if (!exynos)
+ return -EINVAL;
this shouldn't ever be the case and if it is, it deserves the Oops.
+
+ if (pdata pdata-phy_exit)
+ pdata-phy_exit(pdev, pdata-phy_type);
NAK, you should introduce a proper PHY driver and handle PHY suspend
generically in dwc3/core.c
+ clk_disable(exynos-clk);
+
+ return 0;
+}
+
+static int dwc3_exynos_resume(struct device *dev)
+{
+ struct dwc3_exynos_data *pdata = dev-platform_data;
+ struct dwc3_exynos *exynos;
+ struct platform_device *pdev = to_platform_device(dev);
ditto
+ exynos = dev_get_drvdata(dev);
+
+ if (!exynos)
+ return -EINVAL;
ditto
+ clk_enable(exynos-clk);
+
+ /* PHY initialization */
+ if (!pdata) {
+ dev_dbg(pdev-dev, missing platform data\n);
+ } else {
+ if (pdata-phy_init)
+ pdata-phy_init(pdev, pdata-phy_type);
+ }
missing PHY driver
+ /* runtime set active to reflect active state. */
+ pm_runtime_disable(dev);
+ pm_runtime_set_active(dev);
+ pm_runtime_enable(dev);
+
+ return 0;
+}
+
+static const struct dev_pm_ops dwc3_exynos_pm_ops = {
+ .suspend= dwc3_exynos_suspend,
+ .resume = dwc3_exynos_resume,
+};
right here you should:
#define DWC3_EXYNOS_DEV_PM_OPS (dwc3_exynos_pm_ops)
#else
#define DWC3_EXYNOS_DEV_PM_OPS NULL
+#endif /* CONFIG_PM */
+
static struct platform_driver dwc3_exynos_driver = {
.probe = dwc3_exynos_probe,
.remove = __devexit_p(dwc3_exynos_remove),
.driver = {
.name = exynos-dwc3,
+#ifdef CONFIG_PM
+ .pm = dwc3_exynos_pm_ops,
.pm = DWC3_EXYNOS_DEV_PM_OPS,
+#endif
avoid the ifdeferry all over, see above.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 0/3] USB: dwc3: Add suspend/resume support
On Wed, Oct 10, 2012 at 07:35:46PM +0530, Vikas C Sajjan wrote: From: Vikas Sajjan vikas.saj...@linaro.org This patchset adds suspend/resume functionality to dwc3-core layer and xhci-platform driver. It also adds S2R support to dwc3-exynos glue layer. how has this been tested ? For how long ? Based on 'usb-next' branch. Vikas Sajjan (3): usb: dwc3: Add the suspend/resume functionality usb: xhci: Add the suspend/resume functionality exynos5: usb: dwc3: Add the suspend/resume functionality drivers/usb/dwc3/core.c| 268 +--- drivers/usb/dwc3/dwc3-exynos.c | 60 + drivers/usb/host/xhci-plat.c | 44 +++ 3 files changed, 273 insertions(+), 99 deletions(-) -- 1.7.6.5 -- balbi signature.asc Description: Digital signature
Re: [PATCH 1/3] usb: dwc3: Add the suspend/resume functionality
Hi,
On Wed, Oct 10, 2012 at 07:35:47PM +0530, Vikas C Sajjan wrote:
From: Vikas Sajjan vikas.saj...@linaro.org
Adding the suspend and resume funtionality to DWC3 core.
Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
Signed-off-by: Vikas C Sajjan vikas.saj...@linaro.org
CC: Doug Anderson diand...@chromium.org
---
drivers/usb/dwc3/core.c | 268 +-
1 files changed, 169 insertions(+), 99 deletions(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index b415c0c..58b51e1 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -70,51 +70,20 @@ MODULE_PARM_DESC(maximum_speed, Maximum supported
speed.);
static DECLARE_BITMAP(dwc3_devs, DWC3_DEVS_POSSIBLE);
-int dwc3_get_device_id(void)
-{
- int id;
-
-again:
- id = find_first_zero_bit(dwc3_devs, DWC3_DEVS_POSSIBLE);
- if (id DWC3_DEVS_POSSIBLE) {
- int old;
-
- old = test_and_set_bit(id, dwc3_devs);
- if (old)
- goto again;
- } else {
- pr_err(dwc3: no space for new device\n);
- id = -ENOMEM;
- }
-
- return id;
-}
-EXPORT_SYMBOL_GPL(dwc3_get_device_id);
-
-void dwc3_put_device_id(int id)
-{
- int ret;
-
- if (id 0)
- return;
-
- ret = test_bit(id, dwc3_devs);
- WARN(!ret, dwc3: ID %d not in use\n, id);
- smp_mb__before_clear_bit();
- clear_bit(id, dwc3_devs);
-}
-EXPORT_SYMBOL_GPL(dwc3_put_device_id);
-
-void dwc3_set_mode(struct dwc3 *dwc, u32 mode)
why are you even moving all this code around ? Doesn't look necessary.
+static void __devinit dwc3_cache_hwparams(struct dwc3 *dwc)
{
- u32 reg;
+ struct dwc3_hwparams*parms = dwc-hwparams;
- reg = dwc3_readl(dwc-regs, DWC3_GCTL);
- reg = ~(DWC3_GCTL_PRTCAPDIR(DWC3_GCTL_PRTCAP_OTG));
- reg |= DWC3_GCTL_PRTCAPDIR(mode);
- dwc3_writel(dwc-regs, DWC3_GCTL, reg);
+ parms-hwparams0 = dwc3_readl(dwc-regs, DWC3_GHWPARAMS0);
+ parms-hwparams1 = dwc3_readl(dwc-regs, DWC3_GHWPARAMS1);
+ parms-hwparams2 = dwc3_readl(dwc-regs, DWC3_GHWPARAMS2);
+ parms-hwparams3 = dwc3_readl(dwc-regs, DWC3_GHWPARAMS3);
+ parms-hwparams4 = dwc3_readl(dwc-regs, DWC3_GHWPARAMS4);
+ parms-hwparams5 = dwc3_readl(dwc-regs, DWC3_GHWPARAMS5);
+ parms-hwparams6 = dwc3_readl(dwc-regs, DWC3_GHWPARAMS6);
+ parms-hwparams7 = dwc3_readl(dwc-regs, DWC3_GHWPARAMS7);
+ parms-hwparams8 = dwc3_readl(dwc-regs, DWC3_GHWPARAMS8);
}
-
/**
* dwc3_core_soft_reset - Issues core soft reset and PHY reset
* @dwc: pointer to our context structure
@@ -160,6 +129,102 @@ static void dwc3_core_soft_reset(struct dwc3 *dwc)
dwc3_writel(dwc-regs, DWC3_GCTL, reg);
}
+static int dwc3_core_reset(struct dwc3 *dwc)
this looks unnecessary.
+{
+ unsigned long timeout;
+ u32 reg;
+
+ /* issue device SoftReset too */
+ timeout = jiffies + msecs_to_jiffies(500);
+ dwc3_writel(dwc-regs, DWC3_DCTL, DWC3_DCTL_CSFTRST);
+ do {
+ reg = dwc3_readl(dwc-regs, DWC3_DCTL);
+ if (!(reg DWC3_DCTL_CSFTRST))
+ break;
+
+ if (time_after(jiffies, timeout)) {
+ dev_err(dwc-dev, Reset Timed Out\n);
+ return -ETIMEDOUT;
+ }
+
+ cpu_relax();
+ } while (true);
+
+ dwc3_core_soft_reset(dwc);
+
+ dwc3_cache_hwparams(dwc);
+
+ reg = dwc3_readl(dwc-regs, DWC3_GCTL);
+ reg = ~DWC3_GCTL_SCALEDOWN_MASK;
+ reg = ~DWC3_GCTL_DISSCRAMBLE;
+
+ switch (DWC3_GHWPARAMS1_EN_PWROPT(dwc-hwparams.hwparams1)) {
+ case DWC3_GHWPARAMS1_EN_PWROPT_CLK:
+ reg = ~DWC3_GCTL_DSBLCLKGTNG;
+ break;
+ default:
+ dev_dbg(dwc-dev, No power optimization available\n);
+ }
+
+ /*
+ * WORKAROUND: DWC3 revisions 1.90a have a bug
+ * where the device can fail to connect at SuperSpeed
+ * and falls back to high-speed mode which causes
+ * the device to enter a Connect/Disconnect loop
+ */
+ if (dwc-revision DWC3_REVISION_190A)
+ reg |= DWC3_GCTL_U2RSTECN;
+
+ dwc3_writel(dwc-regs, DWC3_GCTL, reg);
+
+ return 0;
+}
+
+int dwc3_get_device_id(void)
+{
+ int id;
+
+again:
+ id = find_first_zero_bit(dwc3_devs, DWC3_DEVS_POSSIBLE);
+ if (id DWC3_DEVS_POSSIBLE) {
+ int old;
+
+ old = test_and_set_bit(id, dwc3_devs);
+ if (old)
+ goto again;
+ } else {
+ pr_err(dwc3: no space for new device\n);
+ id = -ENOMEM;
+ }
+
+ return id;
+}
+EXPORT_SYMBOL_GPL(dwc3_get_device_id);
+
+void dwc3_put_device_id(int id)
+{
+ int ret;
+
+ if (id 0)
+
Re: [PATCH 2/3] usb: xhci: Add the suspend/resume functionality
On Wed, Oct 10, 2012 at 07:35:48PM +0530, Vikas C Sajjan wrote:
From: Vikas Sajjan vikas.saj...@linaro.org
Adding the suspend and resume functionality for the XHCI driver
Signed-off-by: Abhilash Kesavan a.kesa...@samsung.com
Signed-off-by: Vikas C Sajjan vikas.saj...@linaro.org
CC: Doug Anderson diand...@chromium.org
---
drivers/usb/host/xhci-plat.c | 44
++
1 files changed, 44 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index df90fe5..384cf4d 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -185,11 +185,55 @@ static int xhci_plat_remove(struct platform_device *dev)
return 0;
}
+#ifdef CONFIG_PM
+static int xhci_plat_suspend(struct device *dev)
+{
+ struct usb_hcd *hcd;
+ struct xhci_hcd *xhci;
+
+ hcd = dev_get_drvdata(dev);
make it a single line, together with declaration.
+ if (!hcd)
+ return -EINVAL;
remove this.
+ xhci = hcd_to_xhci(hcd);
make it a single line, together with declaration.
+ /* Make sure that the HCD Core as set state HC_STATE_SUSPENDED */
HCD Core *HAS* set ??? I think this also deserves a to after state:
/* Make sure HCD Core has set state to HC_STATE_SUSPENDED */
+ if (hcd-state != HC_STATE_SUSPENDED ||
+ xhci-shared_hcd-state != HC_STATE_SUSPENDED)
+ return -EINVAL;
+
+ return xhci_suspend(xhci);
+}
+
+static int xhci_plat_resume(struct device *dev)
+{
+ struct usb_hcd *hcd;
+ struct xhci_hcd *xhci;
+
+ hcd = dev_get_drvdata(dev);
make it a single line, together with declaration.
+ if (!hcd)
+ return -EINVAL;
remove this.
+
+ xhci = hcd_to_xhci(hcd);
make it a single line, together with declaration.
+ return xhci_resume(xhci, 0);
+}
this should look like:
static int xhci_plat_resume(struct device *dev)
{
struct usb_hcd *hcd = dev_get_drvdata(dev);
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
return xhci_resume(xhci, 0);
}
+static const struct dev_pm_ops xhci_plat_pm_ops = {
+ .suspend= xhci_plat_suspend,
+ .resume = xhci_plat_resume,
+};
#define XHCI_PLAT_PM_OPS(xhci_plat_pm_ops)
#else
#define XHCI_PLAT_PM_OPSNULL
#endif
+#endif
+
static struct platform_driver usb_xhci_driver = {
.probe = xhci_plat_probe,
.remove = xhci_plat_remove,
.driver = {
.name = xhci-hcd,
+#ifdef CONFIG_PM
+ .pm = xhci_plat_pm_ops,
+#endif
.pm = XHCI_PLAT_PM_OPS,
--
balbi
signature.asc
Description: Digital signature
Re: Error when building modules for omap2plus_defconfig in mainline
Hi Venkat, On Thursday 11 October 2012 12:32 PM, Venkatraman S wrote: Daily build on Linus's tree is failing for the past 2-3 days make modules with omap2plus_defconfig.. ERROR: snd_hwparams_to_dma_slave_config [sound/soc/omap/snd-soc-omap.ko] undefined! ERROR: snd_dmaengine_pcm_pointer [sound/soc/omap/snd-soc-omap.ko] undefined! ERROR: snd_dmaengine_pcm_open [sound/soc/omap/snd-soc-omap.ko] undefined! ERROR: snd_dmaengine_pcm_close [sound/soc/omap/snd-soc-omap.ko] undefined! ERROR: snd_dmaengine_pcm_get_chan [sound/soc/omap/snd-soc-omap.ko] undefined! ERROR: snd_dmaengine_pcm_trigger [sound/soc/omap/snd-soc-omap.ko] undefined! make[2]: *** [__modpost] Error 1 make[1]: *** [modules] Error 2 make: *** [sub-make] Error 2 Just wanted to check if a fix is already on the way for -rc1 or someone is aware of it.. This is already fixed by Peter. Here is the patch http://mailman.alsa-project.org/pipermail/alsa-devel/2012-October/055902.html Thanks Lokesh Thanks, Venkat. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] ARM: OMAP: i2c: fix interrupt flood during resume
On Wed, Oct 10, 2012 at 5:48 PM, Kalle Jokiniemi kalle.jokini...@jollamobile.com wrote: The resume_noirq enables interrupts one-by-one starting from first one. Now if the wake up event for suspend came from i2c device, the i2c bus irq gets enabled before the threaded i2c device irq, causing a flood of i2c bus interrupts as the threaded irq that should clear the event is not enabled yet. Fixed the issue by adding suspend_noirq and resume_early functions that keep i2c bus interrupts disabled until resume_noirq has run completely. Issue was detected doing a wake up from autosleep with twl4030 power key on N9. Patch tested on N9. Signed-off-by: Kalle Jokiniemi kalle.jokini...@jollamobile.com Thanks for rebasing however since you were actually interested in one of the older stable releases how about cc stable? -- 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/3] ARM: dts: EMIF and LPDDR2 device tree data for OMAP5 boards
Hi Lokesh,
On 10/11/2012 08:16 AM, Lokesh Vutla wrote:
+ devicetree-discuss
Hi Benoit,
On Wednesday 10 October 2012 08:31 PM, Benoit Cousson wrote:
On 10/10/2012 02:05 PM, Lokesh Vutla wrote:
Device tree data for the EMIF sdram controllers in OMAP5
and LPDDR2 memory devices attached to OMAP5 boards.
Nit: Could you make a sentence with a verb to explain what you are doing
in this patch.
I am really sorry about this.
I ll make sure that all patch descriptions will be clear in V2 of this
patch series.
In this patch I am adding device tree data for LPDDR2 memory devices
attached to omap5-sevm and also adding device tree data for EMIF sdram
controllers in OMAP5.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
arch/arm/boot/dts/lpddr2_data.dtsi | 64
+++-
arch/arm/boot/dts/omap5-evm.dts| 11 +++
arch/arm/boot/dts/omap5.dtsi | 18 ++
3 files changed, 92 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/lpddr2_data.dtsi
b/arch/arm/boot/dts/lpddr2_data.dtsi
index f97f70f..8e8c1bc 100644
--- a/arch/arm/boot/dts/lpddr2_data.dtsi
+++ b/arch/arm/boot/dts/lpddr2_data.dtsi
@@ -3,7 +3,7 @@
*/
/ {
-elpida_ECB240ABACN: lpddr2 {
+elpida_ECB240ABACN: lpddr2@0 {
compatible= Elpida,ECB240ABACN,jedec,lpddr2-s4;
density= 2048;
io-width= 32;
@@ -64,4 +64,66 @@
tDQSCK-max-derated = 6000;
};
};
+
+samsung_K3PE0E000B: lpddr2@1 {
I'm confused now, why are you reusing the same lpddr2_data.dtsi file?
You should create a file per memory. That will make the reuse much
easier.
If the goal of your first patch was to do that, it is then the wrong
approach.
Yes, I wanted to group data for all lppdr2 devices in a single file than
creating separate file for each device.
May be a dumb question, Why can't we group data for all the lpddr2
devices in a single file?
Well, why should we do that? What will be the advantage?
That will increase the size of the DTS/DTB with data nobody will care if
only one type of memory is used on a given platform.
Going in the same direction you can consider adding every OMAP
description into a single DTS... Does that really make sense?
So clearly there is no point doing that, it will cluttered the OMAP4 DTB
with useless Samsung memory data. And the same issue for OMAP5 board
that will contain Elpida memory information. And it will get worst each
time someone will want to add a new memory in this file.
You should just include the data you need for a given board.
Regards,
Benoit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] ARM: dts: EMIF and LPDDR2 device tree data for OMAP5 boards
On Thursday 11 October 2012 01:41 PM, Benoit Cousson wrote:
Hi Lokesh,
On 10/11/2012 08:16 AM, Lokesh Vutla wrote:
+ devicetree-discuss
Hi Benoit,
On Wednesday 10 October 2012 08:31 PM, Benoit Cousson wrote:
On 10/10/2012 02:05 PM, Lokesh Vutla wrote:
Device tree data for the EMIF sdram controllers in OMAP5
and LPDDR2 memory devices attached to OMAP5 boards.
Nit: Could you make a sentence with a verb to explain what you are doing
in this patch.
I am really sorry about this.
I ll make sure that all patch descriptions will be clear in V2 of this
patch series.
In this patch I am adding device tree data for LPDDR2 memory devices
attached to omap5-sevm and also adding device tree data for EMIF sdram
controllers in OMAP5.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
arch/arm/boot/dts/lpddr2_data.dtsi | 64
+++-
arch/arm/boot/dts/omap5-evm.dts| 11 +++
arch/arm/boot/dts/omap5.dtsi | 18 ++
3 files changed, 92 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/lpddr2_data.dtsi
b/arch/arm/boot/dts/lpddr2_data.dtsi
index f97f70f..8e8c1bc 100644
--- a/arch/arm/boot/dts/lpddr2_data.dtsi
+++ b/arch/arm/boot/dts/lpddr2_data.dtsi
@@ -3,7 +3,7 @@
*/
/ {
-elpida_ECB240ABACN: lpddr2 {
+elpida_ECB240ABACN: lpddr2@0 {
compatible= Elpida,ECB240ABACN,jedec,lpddr2-s4;
density= 2048;
io-width= 32;
@@ -64,4 +64,66 @@
tDQSCK-max-derated = 6000;
};
};
+
+samsung_K3PE0E000B: lpddr2@1 {
I'm confused now, why are you reusing the same lpddr2_data.dtsi file?
You should create a file per memory. That will make the reuse much
easier.
If the goal of your first patch was to do that, it is then the wrong
approach.
Yes, I wanted to group data for all lppdr2 devices in a single file than
creating separate file for each device.
May be a dumb question, Why can't we group data for all the lpddr2
devices in a single file?
Well, why should we do that? What will be the advantage?
That will increase the size of the DTS/DTB with data nobody will care if
only one type of memory is used on a given platform.
Going in the same direction you can consider adding every OMAP
description into a single DTS... Does that really make sense?
So clearly there is no point doing that, it will cluttered the OMAP4 DTB
with useless Samsung memory data. And the same issue for OMAP5 board
that will contain Elpida memory information. And it will get worst each
time someone will want to add a new memory in this file.
You should just include the data you need for a given board.
I agree with Benoit. Keeping the memory data files separate will be
better and also if some non-omap boards is using the memory parts,
the separate files can be re-used.
Regards
Santosh
--
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 4/4] mtd: nand: omap2: Add data correction support
On Thu, Oct 11, 2012 at 06:27:13AM +0100, Philip, Avinash wrote: (...) Another simple strategy could use the fact that you add a 14th zero byte to the 13 BCH bytes for RBL compatibility: RBL compatibility (14th byte) is applicable only for BCH8 ecc scheme. So I am planning adding an extra byte (0) for BCH4 ecc scheme. So with this we can go for same approaches in BCH4 BCH8 ecc scheme. If I understood correctly, software BCH ecc scheme is modifying calculated ecc data to handle bit flips in erased pages. If that is the only reason, whether same logic can go for same ECC calculation (remove modification of calculated ecc in case of software ecc correction) by adding an extra byte (0) in spare area to handle erased pages. So can you share if I am missing something? Yes, the only reason why a constant polynomial is added to hw-generated ECC bytes is to transparently handle bitflips in erased pages. Handling erased pages this way has several benefits over the zero byte hack: - cleaner code, no checking of the zero byte - no expensive scan of data+spare area when reading an erased block: this step can significantly slow down the initial UBI scan (lots of erased pages to read) - no need to worry about the (very unlikely) possibility of having more than 4 bitflips in the zero byte OTOH, having the same ECC codes for both ELM and non-ELM chips with RBL compatibility sounds nice and would also simplify things. Note: on platforms where we use SW BCH correction, we also use the MLC OMAP boot mode, which is more robust and not compatible with 8-bit/4-bit BCH layouts. I don't know which way is better for the OMAP community: 1. Unifying ECC modes = loosing the constant polynomial benefits, but gaining RBL compat and simplifying code 2. Keeping separate ECC modes = code bloat Tony, do you have an opinion on this ? BTW, Afzal is submitting a series of patches [1] which are not compatible with your series; is there any plan to merge your patches ? BR, -- Ivan [1] http://lists.infradead.org/pipermail/linux-mtd/2012-October/044374.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 1/3] ARM: dts: Renaming elpida_ecb240abacn.dtsi as lpddr2_data.dtsi
On 10/11/2012 08:16 AM, Lokesh Vutla wrote: + devicetree-discuss Hi Benoit, On Wednesday 10 October 2012 08:18 PM, Benoit Cousson wrote: Hi Lokesh, On 10/10/2012 02:05 PM, Lokesh Vutla wrote: Renaming elpida_ecb240abacn.dtsi file generic, so that the same file can be reused for other parts from different vendors. Could you elaborate a little bit? Are these settings purely reflecting lpddr2 spec timings? The basic idea is to group data for all the lpddr2 devices in a single file instead of creating separate file for each lpddr2 device. Right now the file elpida_ecb240abacn.dtsi contains only data for lpddr2-s4 2G parts from Elpida. I wanted to add data for lpddr2-s4 4G parts from Samsung. So I renamed the file elpida_ecb240abacn.dtsi as lpddr2_data.dtsi. Please let me know if more clarification is needed. Well, not anymore... as explained in the previous email, you should not do that. Keep the Elpida file and create another one for the Samsung part. Then each board will be able to select the proper one and include only the relevant data. Regards, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ARM: dts: Renaming elpida_ecb240abacn.dtsi as lpddr2_data.dtsi
On Thursday 11 October 2012 01:58 PM, Benoit Cousson wrote: On 10/11/2012 08:16 AM, Lokesh Vutla wrote: + devicetree-discuss Hi Benoit, On Wednesday 10 October 2012 08:18 PM, Benoit Cousson wrote: Hi Lokesh, On 10/10/2012 02:05 PM, Lokesh Vutla wrote: Renaming elpida_ecb240abacn.dtsi file generic, so that the same file can be reused for other parts from different vendors. Could you elaborate a little bit? Are these settings purely reflecting lpddr2 spec timings? The basic idea is to group data for all the lpddr2 devices in a single file instead of creating separate file for each lpddr2 device. Right now the file elpida_ecb240abacn.dtsi contains only data for lpddr2-s4 2G parts from Elpida. I wanted to add data for lpddr2-s4 4G parts from Samsung. So I renamed the file elpida_ecb240abacn.dtsi as lpddr2_data.dtsi. Please let me know if more clarification is needed. Well, not anymore... as explained in the previous email, you should not do that. Keep the Elpida file and create another one for the Samsung part. Then each board will be able to select the proper one and include only the relevant data. OK, Ill agree with you. I ll do the changes and post the V2. Thanks, Lokesh Regards, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] usb: xhci: Add the suspend/resume functionality
Hi, On Thu, Oct 11, 2012 at 02:22:42PM +0530, Vikas Sajjan wrote: Hi Felipe, Thanks for the comments, will get back with modifications. cool, but please avoid top posting ;-) -- balbi signature.asc Description: Digital signature
RE: [PATCH 4/4] mtd: nand: omap2: Add data correction support
On Thu, Oct 11, 2012 at 13:51:49, Ivan Djelic wrote: On Thu, Oct 11, 2012 at 06:27:13AM +0100, Philip, Avinash wrote: (...) Another simple strategy could use the fact that you add a 14th zero byte to the 13 BCH bytes for RBL compatibility: RBL compatibility (14th byte) is applicable only for BCH8 ecc scheme. So I am planning adding an extra byte (0) for BCH4 ecc scheme. So with this we can go for same approaches in BCH4 BCH8 ecc scheme. If I understood correctly, software BCH ecc scheme is modifying calculated ecc data to handle bit flips in erased pages. If that is the only reason, whether same logic can go for same ECC calculation (remove modification of calculated ecc in case of software ecc correction) by adding an extra byte (0) in spare area to handle erased pages. So can you share if I am missing something? Yes, the only reason why a constant polynomial is added to hw-generated ECC bytes is to transparently handle bitflips in erased pages. Handling erased pages this way has several benefits over the zero byte hack: - cleaner code, no checking of the zero byte - no expensive scan of data+spare area when reading an erased block: this step can significantly slow down the initial UBI scan (lots of erased pages to read) Thanks for raising this point. In order to reduce scan time of data+spare area when reading an erased block, we can follow below steps 1. Create a standard ecc vector for erased page check against it with calculated ecc of erased page. 2. If the vectors won't match, go for counting bit flips in erased page. 3. Again filtering of erased page can done by checking zero at fixed locations in spare area. Note: Reading of bits in erased page should done only for pages having bitflips. - no need to worry about the (very unlikely) possibility of having more than 4 bitflips in the zero byte OTOH, having the same ECC codes for both ELM and non-ELM chips with RBL compatibility sounds nice and would also simplify things. Note: on platforms where we use SW BCH correction, we also use the MLC OMAP boot mode, which is more robust and not compatible with 8-bit/4-bit BCH layouts. I don't know which way is better for the OMAP community: 1. Unifying ECC modes = loosing the constant polynomial benefits, but gaining RBL compat and simplifying code 2. Keeping separate ECC modes = code bloat Tony, do you have an opinion on this ? BTW, Afzal is submitting a series of patches [1] which are not compatible with your series; is there any plan to merge your patches ? My next series will be on top Afzal's changes. Thanks Avinash BR, -- Ivan [1] http://lists.infradead.org/pipermail/linux-mtd/2012-October/044374.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
omap3 gpmc: irq-20 could not claim: err -2
Hello, I'm getting the kernel log messages early in the bootup sequence (kernel 3.6.1 mainline) [0.121337] GPMC revision 5.0 [0.121582] gpmc: irq-20 could not claim: err -22 this is on beagleboard, which is calling omap_nand_flash_init(), so no omap_nand_platform_data specified in board file NAND still works since it is operated in NAND_OMAP_PREFETCH_POLLED mode; however, I'd like to try NAND_OMAP_PREFETCH_IRQ to see if it brings any performance gains just passing NAND_OMAP_PREFETCH_IRQ via gmpc_nand_init() hangs the kernel (I guess since the request_irq() failed earlier) another question is dev_ready which also seems to depend on IRQ also can you make any recommendation w.r.t NAND performance on OMAP? thanks, regards, p. -- Peter Meerwald +43-664-218 (mobile) -- 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 00/24] OMAP serial driver flow control fixes, and preparation for DMA engine conversion
Hi Kevin, On Wednesday 10 October 2012 11:59 PM, Kevin Hilman wrote: Hi Sourav, Sourav sourav.pod...@ti.com writes: [...] Boot Tested this patch series against v3.6 tag(applied cleanly) on panda board and PM tested(hitting off in Idle and suspend) on omap3630 based beagle board. Note, I also tested the patches against the current master but only after rebasing, since the current master includes serial patches from Felipe Balbi[1]. [1] https://lkml.org/lkml/2012/8/24/139 Tested-by: Sourav Poddar sourav.pod...@ti.com Did you test flow control after off-mode transitons? Russell indicated that the context save/restore is not saving important bits related to HW flow control, so I suspect some more testing, specifically of flow control after off-mode is needed. Kevin The testing done was without any flow control enabled. I will try to figure out how to do a hardware flow control testing and see the status after the off mode. ~Sourav -- 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 00/24] OMAP serial driver flow control fixes, and preparation for DMA engine conversion
On Thu, Oct 11, 2012 at 03:13:43PM +0530, Sourav wrote: Hi Kevin, On Wednesday 10 October 2012 11:59 PM, Kevin Hilman wrote: Hi Sourav, Sourav sourav.pod...@ti.com writes: [...] Boot Tested this patch series against v3.6 tag(applied cleanly) on panda board and PM tested(hitting off in Idle and suspend) on omap3630 based beagle board. Note, I also tested the patches against the current master but only after rebasing, since the current master includes serial patches from Felipe Balbi[1]. [1] https://lkml.org/lkml/2012/8/24/139 Tested-by: Sourav Poddar sourav.pod...@ti.com Did you test flow control after off-mode transitons? Russell indicated that the context save/restore is not saving important bits related to HW flow control, so I suspect some more testing, specifically of flow control after off-mode is needed. Kevin The testing done was without any flow control enabled. So, as the patch set is about fixing the flow control stuff, would you say that your testing without flow control enabled has much value? I will try to figure out how to do a hardware flow control testing and see the status after the off mode. It's software flow control which isn't properly restored... -- 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: omap3 gpmc: irq-20 could not claim: err -2
Hi Peter, On Thu, Oct 11, 2012 at 15:05:43, Peter Meerwald wrote: I'm getting the kernel log messages early in the bootup sequence (kernel 3.6.1 mainline) [0.121337] GPMC revision 5.0 [0.121582] gpmc: irq-20 could not claim: err -22 This issue has been present for quite some time, now as certain gpmc patches got merged recently (during the ongoing merge window), this should be gone. NAND still works since it is operated in NAND_OMAP_PREFETCH_POLLED mode; however, I'd like to try NAND_OMAP_PREFETCH_IRQ to see if it brings any performance gains I vaguely remember that once while checking irq mode (not mainline, on am335x-evm), speed was less compared to default, so I doubt whether you get any performance gains, anyway it would be good to know performance results in your case. just passing NAND_OMAP_PREFETCH_IRQ via gmpc_nand_init() hangs the kernel (I guess since the request_irq() failed earlier) With mainline HEAD, you should be able to use irq. another question is dev_ready which also seems to depend on IRQ also Now it is no more. can you make any recommendation w.r.t NAND performance on OMAP? Once DMA was checked, but found it slower than other two, not sure whether I was doing anything wrong. Right now don't have any suggestions, if I come across any will let you know. Regards Afzal
Re: [RFC 00/24] OMAP serial driver flow control fixes, and preparation for DMA engine conversion
Hi Russell, On Thursday 11 October 2012 03:24 PM, Russell King - ARM Linux wrote: On Thu, Oct 11, 2012 at 03:13:43PM +0530, Sourav wrote: Hi Kevin, On Wednesday 10 October 2012 11:59 PM, Kevin Hilman wrote: Hi Sourav, Sourav sourav.pod...@ti.com writes: [...] Boot Tested this patch series against v3.6 tag(applied cleanly) on panda board and PM tested(hitting off in Idle and suspend) on omap3630 based beagle board. Note, I also tested the patches against the current master but only after rebasing, since the current master includes serial patches from Felipe Balbi[1]. [1] https://lkml.org/lkml/2012/8/24/139 Tested-by: Sourav Poddar sourav.pod...@ti.com Did you test flow control after off-mode transitons? Russell indicated that the context save/restore is not saving important bits related to HW flow control, so I suspect some more testing, specifically of flow control after off-mode is needed. Kevin The testing done was without any flow control enabled. So, as the patch set is about fixing the flow control stuff, would you say that your testing without flow control enabled has much value? True. I missed that point while doing the testing. Sorry for that. I further looked into it and saw some two options in my minicom settings(Hardware Flow Control/ Software Flow Control) Which I am thinking are the ones used to enable the flow control ? and they are both set to NO. I already enable software flow control and did the testing on beagle, where things are working fine after off mode. But if I enable hardware flow control, the teraterm does not allow me to load my fs and uImage from mmc. If you have any pointers on how to test hardware flow control, I will like to do that on my beagle board. Thanks, Sourav I will try to figure out how to do a hardware flow control testing and see the status after the off mode. It's software flow control which isn't properly restored... -- 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: OMAP4: hwmod data: Add McASP data port address space
Hi Ricardo,
On 10/09/2012 04:15 PM, Ricardo Neri wrote:
Hi Benoit,
Have you had a chance to look at this patch? Maybe you want me to submit
it differently or to a different list?
Sorry, I missed it. It looks fine and aligned with what I have done for
OMAP5. I just have few minors comments.
Thanks!
Ricardo
On 09/27/2012 11:33 AM, Ricardo Neri wrote:
McASP has a configuration port and a data port. This patch adds the
address
space entry for the data port as described in the OMAP4 TRM.
Also, add names to the address spaces.
Signed-off-by: Ricardo Neri ricardo.n...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index f31f3bc..cb5b463 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -4951,10 +4951,16 @@ static struct omap_hwmod_ocp_if
omap44xx_l4_abe__mcasp = {
static struct omap_hwmod_addr_space omap44xx_mcasp_dma_addrs[] = {
{
+.name= cfg,
.pa_start= 0x49028000,
.pa_end= 0x490283ff,
.flags= ADDR_TYPE_RT
},
+{
+.name= dat,
+.pa_start= 0x4902A000,
You should use lower case for hex number.
+.pa_end= 0x4902Afff,
In the data I have, the end is 0x4012a3ff.
Do we need to extend it to fff?
Regards,
Benoit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 00/24] OMAP serial driver flow control fixes, and preparation for DMA engine conversion
On Thu, Oct 11, 2012 at 03:51:00PM +0530, Sourav wrote: True. I missed that point while doing the testing. Sorry for that. I further looked into it and saw some two options in my minicom settings(Hardware Flow Control/ Software Flow Control) Which I am thinking are the ones used to enable the flow control ? and they are both set to NO. I already enable software flow control and did the testing on beagle, where things are working fine after off mode. But if I enable hardware flow control, the teraterm does not allow me to load my fs and uImage from mmc. If you have any pointers on how to test hardware flow control, I will like to do that on my beagle board. Okay, it sounds like I need to do a teach-in on flow control... First, hardware flow control. Hardware flow control is operated by two signals: RTS and CTS. In conventional setups, CTS is an input to the transmitter, and controls whether the transmitter may start the transmission of a new character. If CTS is deasserted, the transmitter will stop after the completion of the previous character. When hardware flow control is disabled, the transmitter ignores this signal. RTS is an output, and is generally used to control the remote transmitter. (There are setups where RTS means something else, but the kernel doesn't support other schemes directly.) RTS is asserted when either hardware flow control is disabled, or there is sufficient space to receive more characters from the remote end. This is a symetrical setup, so that two UARTs connected together using this scheme will have the RTS of one connected to the CTS of the other. This way, each can signal whether characters should be transmitted. So, in minicom, when hardware flow control is disabled, your hosts transmitter will ignore the state of the CTS signal, and will hold its RTS asserted. If hardware flow control in minicom is enabled, then that tells the kernel (and possibly hardware) to take note of the CTS signal, and pause transmission when CTS is deasserted. It will also cause the RTS signal to be manipulated according to available buffer space on the receive side. Obviously minicom will try to ensure that any characters received are displayed as quickly as possible, so it's unlikely that the receive side will fill up. When you're logged into a system via a serial line, the hardware flow control state is controlled by the CRTSCTS termios flag. That can be seen and manipulated by stty. stty -a to see all flags. stty -crtscts to disable, stty crtscts to enable. Now, for software flow control. It operates in the same way as above, but instead of a hardware signal reporting the state, characters are embedded into the stream. In normal situations, these characters are the standard ^Q (noramlly XON) and ^S (XOFF) characters. You'll find that works in gnome-terminals, xterms, and many places because it's part of the standard terminal interface. You can type these characters into minicom with or without software flow control disabled; it just passes them through unmodified. When software flow control is enabled, and the tty receive buffers start to fill up, the kernel will queue a high-priority XOFF character for the UART to transmit to the remote end. Once the tty buffers have emptied sufficiently, it will queue a high-priority XON character. If software flow control is disabled, it will ignore this. When hardware assisted software flow control is enabled, this will be done by the hardware itself in response to the UART FIFO filling up and emptying. For the target, software flow control has more configuration options: ixon: controls whether the transmitter starts/stops on reception of xon/xoff characters ixoff: controls the generation of xon/xoff characters ixany: permits any received character (including xon) to restart transmission stop char: sets the xoff character to the specified character start char: sets the xon character to the specified character xon and xoff default to ^Q and ^S respectively, there's no need to 'initialize' them prior to use. So, to enable software flow control (which is probably already enabled on the target): stty ixon ixoff and then you can type ^S and ^Q into minicom to stop/start the target's transmit output. Finally, to make the target's input buffer fill up, arrange for the target not to read from the controlling tty at all. sleep 120 will do that for two minutes, after which the input will be gobbled up by the shell (which it'll try to interpret as commands.) So, probably better to do: sleep 120; echo Finished; cat /dev/null instead, and then send lots of data, and check whether the transmission stops, whether the right xon/xoff characters are transmitted, and whether any overrun errors are reported. Going the other way, you can suspend minicom (^a z) and then arrange for the target to send lots of data, and again check
Re: [PATCH 0/4] OMAP-GPMC generic timing migration
Hi, On 05.10.2012 18:00, Afzal Mohammed wrote: This series provides a generic gpmc timing calculation routine. There were three peripherals (OneNAND, tusb6010, smc91x) using custom timing calculations, they are migrated to use the generic timing calculation. Such a generic routine would help create a driver out of gpmc platform code, which would be peripheral agnostic and thus lead to DT finally. Input to generic timing calculation routine would be gpmc peripheral timings, output - translated timings that gpmc can understand. Later, to DT'ify, gpmc peripheral timings could be passed through DT. Input timings that has been used here are selected such that it represents those that are present in peripheral timing datasheets. Admittedly, I lost track on the multiple GPMC series here, and they also cause major merge conflicts with Linus' current master branch. Could you tell me which patches I need on top of soon-to-be-3.7-rc1? I would like to augment this to make GPMC attached NAND probable in DT, in case this is still an open topic. Thanks for you hard work, Daniel This series has been created by pulling out last 4 patches in v7 of the series, OMAP-GPMC: generic time calc, prepare for driver This was done to have easy path for common zImage gpmc cleanup patches. Proposed generic routine has been tested on OneNAND (async) on OMAP3EVM rev C (as mainline does not have the OneNAND support for this, local patch were used to test). For other cases of custom timing calculation (tusb6010, smc91x non-muxed, OneNAND sync), generic timing calculation routine was verified by simulating on OMAP3EVM. This series is available @ git://gitorious.org/x0148406-public/linux-kernel.git gpmc-timing-v1 and is based on linux-next (next-20121005) and is dependent on http://marc.info/?l=linux-omapm=134945131602622w=2 http://marc.info/?l=linux-omapm=134945239306131w=2 This series as such is only the first version, but these patches has already undergone one change before being made as this series. The change was in using ps instead of ns to prevent rounding errors. Also along with this series documentation has been improved. Regards Afzal Afzal Mohammed (4): ARM: OMAP2+: gpmc: generic timing calculation ARM: OMAP2+: onenand: generic timing calculation ARM: OMAP2+: smc91x: generic timing calculation ARM: OMAP2+: tusb6010: generic timing calculation Documentation/bus-devices/ti-gpmc.txt | 122 + arch/arm/mach-omap2/gpmc-onenand.c| 124 + arch/arm/mach-omap2/gpmc-smc91x.c | 43 ++--- arch/arm/mach-omap2/gpmc.c| 325 ++ arch/arm/mach-omap2/gpmc.h| 102 --- arch/arm/mach-omap2/usb-tusb6010.c| 182 +-- 6 files changed, 633 insertions(+), 265 deletions(-) create mode 100644 Documentation/bus-devices/ti-gpmc.txt -- 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 0/4] OMAP-GPMC generic timing migration
Hi Daniel, On Thu, Oct 11, 2012 at 17:15:42, Daniel Mack wrote: Admittedly, I lost track on the multiple GPMC series here, and they also cause major merge conflicts with Linus' current master branch. Could you tell me which patches I need on top of soon-to-be-3.7-rc1? I Series [1-2] plus this series would be the required. Note that 1st patch of series [2] has already reached mainline. Another easy way would be, pull, git://gitorious.org/x0148406-public/linux-kernel.git gpmc-timing git checkout -b gpmc myremote/gpmc-timing git rebase --onto Linus-current-master next-20121005 (or 080aa9c) would like to augment this to make GPMC attached NAND probable in DT, in case this is still an open topic. I would be doing gpmc DT conversion next. Hoping that this series too will be picked up by Tony, as once this series is accepted, during DT conversion we need not rely on auxdata (a last resort option) for timings. Thanks for you hard work, Thanks, it was a pleasure to read the above. Regards Afzal [1] http://marc.info/?l=linux-omapm=134945131602622w=2 [2] http://marc.info/?l=linux-omapm=134967458329531w=2
[PATCH V2 3/3] ARM: dts: omap5-evm: LPDDR2 memory device details for EVM
Samsung's K3PE0E000B memory part is used in OMAP5-evm board.
Adding timings and geometry details for Samsung's memory part and
attaching the same to device-handle of EMIF1/2.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
arch/arm/boot/dts/omap5-evm.dts | 11 +
arch/arm/boot/dts/samsung_k3pe0e000b.dtsi | 67 +
2 files changed, 78 insertions(+)
create mode 100644 arch/arm/boot/dts/samsung_k3pe0e000b.dtsi
diff --git a/arch/arm/boot/dts/omap5-evm.dts b/arch/arm/boot/dts/omap5-evm.dts
index 6f87e1a..ed1d1b5 100644
--- a/arch/arm/boot/dts/omap5-evm.dts
+++ b/arch/arm/boot/dts/omap5-evm.dts
@@ -8,6 +8,7 @@
/dts-v1/;
/include/ omap5.dtsi
+/include/ samsung_k3pe0e000b.dtsi
/ {
model = TI OMAP5 EVM board;
@@ -82,3 +83,13 @@
0x020700d9;/* SEARCH */
linux,input-no-autorepeat;
};
+
+emif1 {
+ cs1-used;
+ device-handle = samsung_K3PE0E000B;
+};
+
+emif2 {
+ cs1-used;
+ device-handle = samsung_K3PE0E000B;
+};
diff --git a/arch/arm/boot/dts/samsung_k3pe0e000b.dtsi
b/arch/arm/boot/dts/samsung_k3pe0e000b.dtsi
new file mode 100644
index 000..b352d69
--- /dev/null
+++ b/arch/arm/boot/dts/samsung_k3pe0e000b.dtsi
@@ -0,0 +1,67 @@
+/*
+ * Timings and Geometry for Samsung K3PE0E000B memory part
+ */
+
+/ {
+ samsung_K3PE0E000B: lpddr2 {
+ compatible = Samsung,K3PE0E000B,jedec,lpddr2-s4;
+ density = 4096;
+ io-width= 32;
+
+ tRPab-min-tck = 3;
+ tRCD-min-tck= 3;
+ tWR-min-tck = 3;
+ tRASmin-min-tck = 3;
+ tRRD-min-tck= 2;
+ tWTR-min-tck= 2;
+ tXP-min-tck = 2;
+ tRTP-min-tck= 2;
+ tCKE-min-tck= 3;
+ tCKESR-min-tck = 3;
+ tFAW-min-tck= 8;
+
+ timings_samsung_K3PE0E000B_533mhz: lpddr2-timings@0 {
+ compatible = jedec,lpddr2-timings;
+ min-freq= 1000;
+ max-freq= 5;
+ tRPab = 21000;
+ tRCD= 18000;
+ tWR = 15000;
+ tRAS-min= 42000;
+ tRRD= 1;
+ tWTR= 7500;
+ tXP = 7500;
+ tRTP= 7500;
+ tCKESR = 15000;
+ tDQSCK-max = 5500;
+ tFAW= 5;
+ tZQCS = 9;
+ tZQCL = 36;
+ tZQinit = 100;
+ tRAS-max-ns = 7;
+ tDQSCK-max-derated = 6000;
+ };
+
+ timings_samsung_K3PE0E000B_266mhz: lpddr2-timings@1 {
+ compatible = jedec,lpddr2-timings;
+ min-freq= 1000;
+ max-freq= 2;
+ tRPab = 21000;
+ tRCD= 18000;
+ tWR = 15000;
+ tRAS-min= 42000;
+ tRRD= 1;
+ tWTR= 7500;
+ tXP = 7500;
+ tRTP= 7500;
+ tCKESR = 15000;
+ tDQSCK-max = 5500;
+ tFAW= 5;
+ tZQCS = 9;
+ tZQCL = 36;
+ tZQinit = 100;
+ tRAS-max-ns = 7;
+ tDQSCK-max-derated = 6000;
+ };
+ };
+};
--
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
[PATCH V2 2/3] ARM: dts: omap5: EMIF device tree data for OMAP5 boards
Adding EMIF device tree data for OMAP5 boards.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
arch/arm/boot/dts/omap5.dtsi | 24
1 file changed, 24 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 5db33f4..445aeea 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -319,5 +319,29 @@
ti,buffer-size = 128;
ti,hwmods = mcbsp3;
};
+
+ emif1: emif@0x4c00 {
+ compatible = ti,emif-4d5;
+ ti,hwmods = emif1;
+ phy-type= 2;
+ reg = 0x4c00 0x3ff;
+ interrupts = 0 110 0x4;
+ interrupt-parent = gic;
+ hw-caps-read-idle-ctrl;
+ hw-caps-ll-interface;
+ hw-caps-temp-alert;
+ };
+
+ emif2: emif@0x4d00 {
+ compatible = ti,emif-4d5;
+ ti,hwmods = emif2;
+ phy-type= 2;
+ reg = 0x4d00 0x3ff;
+ interrupts = 0 111 0x4;
+ interrupt-parent = gic;
+ hw-caps-read-idle-ctrl;
+ hw-caps-ll-interface;
+ hw-caps-temp-alert;
+ };
};
};
--
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
[PATCH V2 0/3] ARM: dts: omap5: EMIF and LPDDR2 device tree data
This patch series adds Device tree data for the EMIF sdram controllers in OMAP5 and LPDDR2 memory devices in OMAP5-evm board. Testing: - Boot tested on OMAP5430 evm. - Built EMIF as a module. Changes from v1: * Created a seperate dtsi file for Samsung LPDDR2 memory device used in OMAP5-evm. * Passing reg and interrupt fields from dt for EMIF1 and EMIF2. Lokesh Vutla (3): ARM: dts: omap5-evm: Fix size of memory defined for EVM ARM: dts: omap5: EMIF device tree data for OMAP5 boards ARM: dts: omap5-evm: LPDDR2 memory device details for EVM arch/arm/boot/dts/omap5-evm.dts | 13 +- arch/arm/boot/dts/omap5.dtsi | 24 +++ arch/arm/boot/dts/samsung_k3pe0e000b.dtsi | 67 + 3 files changed, 103 insertions(+), 1 deletion(-) create mode 100644 arch/arm/boot/dts/samsung_k3pe0e000b.dtsi -- 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
[PATCH V2 1/3] ARM: dts: omap5-evm: Fix size of memory defined for EVM
Memory present for OMAP5-evm is 2GB. But in dts file
it is specified as 1GB. Correcting the same.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
arch/arm/boot/dts/omap5-evm.dts |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap5-evm.dts b/arch/arm/boot/dts/omap5-evm.dts
index 9c41a3f..6f87e1a 100644
--- a/arch/arm/boot/dts/omap5-evm.dts
+++ b/arch/arm/boot/dts/omap5-evm.dts
@@ -15,7 +15,7 @@
memory {
device_type = memory;
- reg = 0x8000 0x4000; /* 1 GB */
+ reg = 0x8000 0x8000; /* 2 GB */
};
vmmcsd_fixed: fixedregulator-mmcsd {
--
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: [RFC][PATCH v4? 0/7] Adaptive Body-Bias for OMAP
On 18:26-20121003, Mike Turquette wrote: From: Mike Turquette mturque...@linaro.org [...] arch/arm/mach-omap2/Makefile |8 +- arch/arm/mach-omap2/abb.c | 322 + arch/arm/mach-omap2/abb.h | 94 [...] arch/arm/plat-omap/include/plat/voltage.h |1 + 18 files changed, 699 insertions(+), 37 deletions(-) create mode 100644 arch/arm/mach-omap2/abb.c create mode 100644 arch/arm/mach-omap2/abb.h create mode 100644 arch/arm/mach-omap2/abb36xx_data.c create mode 100644 arch/arm/mach-omap2/abb44xx_data.c dumb question: with the request to move everything out of mach-omap2 directory, do we still want to add more files into mach-omap2? Regards, NM -- 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 00/24] OMAP serial driver flow control fixes, and preparation for DMA engine conversion
Hi Sourav, On 10/11/2012 05:21 AM, Sourav wrote: [snip] I already enable software flow control and did the testing on beagle, where things are working fine after off mode. But if I enable hardware flow control, the teraterm does not allow me to load my fs and uImage from mmc. If you have any pointers on how to test hardware flow control, I will like to do that on my beagle board. For h/w flow control, you need to check if the CTS and RTS signals are being brought out to the serial header on the beagle-board. Looking at the schematics for the 3430 beagle board, it appears that only the UART RX and TX signals are available on the serial header. Therefore, I don't believe you can test h/w flow control using the console with that board. I do see that you can access all the UART2 signals (RX/TX/CTS/RTS) via the expansion connector on the beagle. However, to connect to a serial port on a PC you need to have a voltage level-shifter in-between. There are some companies out there that make them [1], but you need to make sure you have one that can support a 1.8V input. Cheers Jon [1] http://elinux.org/RS232_Level_Shifter -- 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 4/4] mtd: nand: omap2: Add data correction support
* Ivan Djelic ivan.dje...@parrot.com [121011 01:23]: I don't know which way is better for the OMAP community: 1. Unifying ECC modes = loosing the constant polynomial benefits, but gaining RBL compat and simplifying code 2. Keeping separate ECC modes = code bloat Tony, do you have an opinion on this ? Well right now I'm mostly interested in making device drivers independent of the arch/arm/*omap*/* code. That's where Afzal's patches help quite a bit, so let's get those in first. So from that point of view, option #1 above sounds better as the first step :) Ideally of course option #1 should not limit us from adding extra features in the long run. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] OMAP-GPMC generic timing migration
* Mohammed, Afzal af...@ti.com [121011 05:48]: Hi Daniel, On Thu, Oct 11, 2012 at 17:15:42, Daniel Mack wrote: Admittedly, I lost track on the multiple GPMC series here, and they also cause major merge conflicts with Linus' current master branch. Could you tell me which patches I need on top of soon-to-be-3.7-rc1? I Series [1-2] plus this series would be the required. Note that 1st patch of series [2] has already reached mainline. Another easy way would be, pull, git://gitorious.org/x0148406-public/linux-kernel.git gpmc-timing git checkout -b gpmc myremote/gpmc-timing git rebase --onto Linus-current-master next-20121005 (or 080aa9c) After -rc1 is out, let's plan on adding the minimal set required for removing plat and mach includes from drivers into a clean-up branch. Afzal, can you maybe do a pull request for that set against -rc1 when it's out? Just the minimal set of patches. would like to augment this to make GPMC attached NAND probable in DT, in case this is still an open topic. I would be doing gpmc DT conversion next. Hoping that this series too will be picked up by Tony, as once this series is accepted, during DT conversion we need not rely on auxdata (a last resort option) for timings. Yes, then please do a second pull request for what's needed to apply the minimal DT bindings. For the DT binding, let's just leave out the timings for now as we can load those from auxdata. Then the binding for the timings can be added later on. So just the minimal binding using standard features for the iorange and interrupt. Thanks, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] mmc: omap_hsmmc: fix host reference after mmc_free_host
struct omap_hsmmc_host *host should not be accessed after mmc_free_host(). Reorder mmc_free_host() after iounmap(host-base). Signed-off-by: Balaji T K balaj...@ti.com --- drivers/mmc/host/omap_hsmmc.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c index d9af5f1..02421a9 100644 --- a/drivers/mmc/host/omap_hsmmc.c +++ b/drivers/mmc/host/omap_hsmmc.c @@ -2010,8 +2010,8 @@ static int __devexit omap_hsmmc_remove(struct platform_device *pdev) clk_put(host-dbclk); } - mmc_free_host(host-mmc); iounmap(host-base); + mmc_free_host(host-mmc); omap_hsmmc_gpio_free(pdev-dev.platform_data); res = platform_get_resource(pdev, IORESOURCE_MEM, 0); -- 1.7.5.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] ARM: OMAP4: hwmod data: Add McASP data port address space
Hi Benoit,
Thanks for reviewing!
On 10/11/2012 05:29 AM, Benoit Cousson wrote:
Hi Ricardo,
On 10/09/2012 04:15 PM, Ricardo Neri wrote:
Hi Benoit,
Have you had a chance to look at this patch? Maybe you want me to submit
it differently or to a different list?
Sorry, I missed it. It looks fine and aligned with what I have done for
OMAP5. I just have few minors comments.
Thanks!
Ricardo
On 09/27/2012 11:33 AM, Ricardo Neri wrote:
McASP has a configuration port and a data port. This patch adds the
address
space entry for the data port as described in the OMAP4 TRM.
Also, add names to the address spaces.
Signed-off-by: Ricardo Neri ricardo.n...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index f31f3bc..cb5b463 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -4951,10 +4951,16 @@ static struct omap_hwmod_ocp_if
omap44xx_l4_abe__mcasp = {
static struct omap_hwmod_addr_space omap44xx_mcasp_dma_addrs[] = {
{
+.name= cfg,
.pa_start= 0x49028000,
.pa_end= 0x490283ff,
.flags= ADDR_TYPE_RT
},
+{
+.name= dat,
+.pa_start= 0x4902A000,
You should use lower case for hex number.
Ok, I'll do it.
+.pa_end= 0x4902Afff,
In the data I have, the end is 0x4012a3ff.
Do we need to extend it to fff?
Not sure. I took this number from the Table 2-7 of OMAP4 TRM. In
general, I see that the .pa_end values for several modules in
omap_hwmod_44xx_data.c do not match the Chapter 2 of OMAP4 TRM. Examples
of this are omap44xx_aess_addrs, omap44xx_mcbsp1/2/3_addrs,
omap44xx_dmic_addrs, omap44xx_dss_addrs, omap44xx_dss_dsi1_addrs,
omap44xx_dss_dsi2_addrs. Is there any reason for this? Maybe your data
is more accurate.
BR,
Ricardo
Regards,
Benoit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFT/PATCH] serial: omap: prevent resume if device is not suspended.
Hi Sourav, Felipe, any progress on fixing the N800 problem? Would be good to keep it booting since we use it as our primary 2420 test platform. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH v2 00/16] DMA Engine support for AM33xx
Changes since v1: - Rebased on top of mainline from 12250d8 - Dropped the feature removal schedule patch - Implemented dma_request_slave_channel_compat() and converted the mmc and spi drivers to use it - Dropped unneeded #address-cells and #size-cells from EDMA DT support - Moved private EDMA header to linux/platform_data/ and removed some unneeded definitions - Fixed parsing of optional properties TODO: - Add AM33xx crossbar support to the private EDMA API (any EDMA events on the crossbar are not supported) - Add dmaengine support for per-channel caps so the hack to set the maximum segments can be replaced with a query to the dmaengine driver 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 mainline from 12250d843e8489ee00b5b7726da855e51694e792 and the following patches: - Vaibhav's patch to fix AM33xx boot on mainline https://patchwork.kernel.org/patch/1569231/ - 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. 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 yet. This is tested on BeagleBone with a SPI framebuffer driver and SD card. It is regression tested 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. 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 AM335x dmaengine: edma: enable build for AM33XX dmaengine: edma: Add TI EDMA device tree binding ARM: dts: add AM33XX EDMA support ARM: omap: add hsmmc am33xx specific init 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 Documentation/devicetree/bindings/dma/ti-edma.txt | 49 + .../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 25 +- Documentation/devicetree/bindings/spi/omap-spi.txt | 27 +- arch/arm/Kconfig |1 + arch/arm/boot/dts/am335x-bone.dts | 23 + arch/arm/boot/dts/am33xx.dtsi | 100 ++ arch/arm/common/Kconfig|3 + arch/arm/common/Makefile |1 + arch/arm/common/edma.c | 1781 arch/arm/mach-davinci/Makefile |2 +- arch/arm/mach-davinci/board-da830-evm.c|4 +- arch/arm/mach-davinci/board-da850-evm.c|8 +- arch/arm/mach-davinci/board-dm646x-evm.c |4 +- arch/arm/mach-davinci/board-omapl138-hawk.c|8 +- arch/arm/mach-davinci/board-tnetv107x-evm.c|2 +- arch/arm/mach-davinci/davinci.h|2 +- arch/arm/mach-davinci/devices-da8xx.c |8 +- arch/arm/mach-davinci/devices-tnetv107x.c |6 +- arch/arm/mach-davinci/devices.c|7 +- arch/arm/mach-davinci/dm355.c |6 +- arch/arm/mach-davinci/dm365.c |6 +- arch/arm/mach-davinci/dm644x.c |6 +- arch/arm/mach-davinci/dm646x.c |6 +- arch/arm/mach-davinci/dma.c| 1588
[RFC PATCH v2 12/16] mmc: omap_hsmmc: add generic DMA request support to the DT binding
The binding definition is based on the generic DMA request binding.
Signed-off-by: Matt Porter mpor...@ti.com
---
.../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 25 +++-
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
index be76a23..d1b8932 100644
--- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -19,8 +19,28 @@ 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
+dmas: DMA controller phandle and DMA request value ordered pair
+One tx and one rx pair is required.
+dma-names: DMA request names. These strings correspond 1:1 with
+the ordered pairs in dmas. The RX request must be rx and the
+TX request must be tx.
+
+Examples:
+
+[hwmod populated DMA resources]
+
+ mmc1: mmc@0x4809c000 {
+ compatible = ti,omap4-hsmmc;
+ reg = 0x4809c000 0x400;
+ ti,hwmods = mmc1;
+ ti,dual-volt;
+ bus-width = 4;
+ vmmc-supply = vmmc; /* phandle to regulator node */
+ ti,non-removable;
+ };
+
+[generic DMA request binding]
-Example:
mmc1: mmc@0x4809c000 {
compatible = ti,omap4-hsmmc;
reg = 0x4809c000 0x400;
@@ -29,4 +49,7 @@ Example:
bus-width = 4;
vmmc-supply = vmmc; /* phandle to regulator node */
ti,non-removable;
+ dmas = edma 24
+ edma 25;
+ dma-names = tx, rx;
};
--
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
[RFC PATCH v2 15/16] spi: omap2-mcspi: add generic DMA request support to the DT binding
The binding definition is based on the generic DMA request binding.
Signed-off-by: Matt Porter mpor...@ti.com
---
Documentation/devicetree/bindings/spi/omap-spi.txt | 27 +++-
1 file changed, 26 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/spi/omap-spi.txt
b/Documentation/devicetree/bindings/spi/omap-spi.txt
index 81df374..11aff04 100644
--- a/Documentation/devicetree/bindings/spi/omap-spi.txt
+++ b/Documentation/devicetree/bindings/spi/omap-spi.txt
@@ -7,8 +7,18 @@ Required properties:
- ti,spi-num-cs : Number of chipselect supported by the instance.
- ti,hwmods: Name of the hwmod associated to the McSPI
+Optional properties:
+- dmas: List of DMA controller phandle and DMA request ordered
+ pairs. One tx and one rx pair is required for each chip
+ select.
+- dma-names: List of DMA request names. These strings correspond
+ 1:1 with the ordered pairs in dmas. The string naming is
+ to be rxN and txN for RX and TX requests,
+ respectively, where N equals the chip select number.
-Example:
+Examples:
+
+[hwmod populated DMA resources]
mcspi1: mcspi@1 {
#address-cells = 1;
@@ -18,3 +28,18 @@ mcspi1: mcspi@1 {
ti,spi-num-cs = 4;
};
+[generic DMA request binding]
+
+mcspi1: mcspi@1 {
+#address-cells = 1;
+#size-cells = 0;
+compatible = ti,omap4-mcspi;
+ti,hwmods = mcspi1;
+ti,spi-num-cs = 2;
+dmas = edma 42
+ edma 43
+ edma 44
+ edma 45;
+dma-names = tx0, rx0, tx1, rx1;
+};
+
--
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
[RFC PATCH v2 16/16] ARM: dts: add AM33XX SPI support
Adds AM33XX SPI support to the am33xx.dtsi and the BeagleBone
dts.
Signed-off-by: Matt Porter mpor...@ti.com
---
arch/arm/boot/dts/am335x-bone.dts | 17 +++
arch/arm/boot/dts/am33xx.dtsi | 43 +
2 files changed, 60 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index 5510979..23edfd8 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -18,6 +18,17 @@
reg = 0x8000 0x1000; /* 256 MB */
};
+ am3358_pinmux: pinmux@44e10800 {
+ spi1_pins: pinmux_spi1_pins {
+ pinctrl-single,pins =
+ 0x190 0x13 /* mcasp0_aclkx.spi1_sclk,
OUTPUT_PULLUP | MODE3 */
+ 0x194 0x33 /* mcasp0_fsx.spi1_d0,
INPUT_PULLUP | MODE3 */
+ 0x198 0x13 /* mcasp0_axr0.spi1_d1,
OUTPUT_PULLUP | MODE3 */
+ 0x19c 0x13 /* mcasp0_ahclkr.spi1_cs0,
OUTPUT_PULLUP | MODE3 */
+ ;
+ };
+ };
+
ocp {
uart1: serial@44e09000 {
status = okay;
@@ -84,3 +95,9 @@
mmc1 {
vmmc-supply = ldo3_reg;
};
+
+spi1 {
+ status = okay;
+ pinctrl-names = default;
+ pinctrl-0 = spi1_pins;
+};
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index ef8e105..854235e 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -40,6 +40,15 @@
};
};
+ am3358_pinmux: pinmux@44e10800 {
+ compatible = pinctrl-single;
+ reg = 0x44e10800 0x0238;
+ #address-cells = 1;
+ #size-cells = 0;
+ pinctrl-single,register-width = 32;
+ pinctrl-single,function-mask = 0x7f;
+ };
+
/*
* XXX: Use a flat representation of the AM33XX interconnect.
* The real AM33XX interconnect network is quite complex.Since
@@ -260,6 +269,40 @@
status = disabled;
};
+ spi0: spi@4803 {
+ compatible = ti,omap4-mcspi;
+ ti,hwmods = spi0;
+ #address-cells = 1;
+ #size-cells = 0;
+ reg = 0x4803 0x400;
+ interrupt-parent = intc;
+ interrupt = 65;
+ dmas = edma 16
+ edma 17
+ edma 18
+ edma 19;
+ dma-names = tx0, rx0, tx1, rx1;
+ ti,spi-num-cs = 2;
+ status = disabled;
+ };
+
+ spi1: spi@481a {
+ compatible = ti,omap4-mcspi;
+ ti,hwmods = spi1;
+ #address-cells = 1;
+ #size-cells = 0;
+ reg = 0x481a 0x400;
+ interrupt-parent = intc;
+ interrupt = 125;
+ dmas = edma 42
+ edma 43
+ edma 44
+ edma 45;
+ dma-names = tx0, rx0, tx1, rx1;
+ ti,spi-num-cs = 2;
+ status = disabled;
+ };
+
wdt2: wdt@44e35000 {
compatible = ti,omap3-wdt;
ti,hwmods = wd_timer2;
--
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
[RFC PATCH v2 14/16] spi: omap2-mcspi: convert to dma_request_slave_channel_compat()
Convert dmaengine channel requests to use
dma_request_slave_channel_compat(). This supports the DT case of
platforms requiring channel selection from either the OMAP DMA or
the EDMA engine. AM33xx only boots from DT and is the only user
implementing EDMA so in the !DT case we can default to the OMAP DMA
filter.
Signed-off-by: Matt Porter mpor...@ti.com
---
drivers/spi/spi-omap2-mcspi.c | 65 -
1 file changed, 45 insertions(+), 20 deletions(-)
diff --git a/drivers/spi/spi-omap2-mcspi.c b/drivers/spi/spi-omap2-mcspi.c
index 3542fdc..793ae8c 100644
--- a/drivers/spi/spi-omap2-mcspi.c
+++ b/drivers/spi/spi-omap2-mcspi.c
@@ -103,6 +103,9 @@ struct omap2_mcspi_dma {
struct completion dma_tx_completion;
struct completion dma_rx_completion;
+
+ char dma_rx_ch_name[14];
+ char dma_tx_ch_name[14];
};
/* use PIO for small transfers, avoiding DMA setup/teardown overhead and
@@ -819,14 +822,23 @@ static int omap2_mcspi_request_dma(struct spi_device *spi)
dma_cap_zero(mask);
dma_cap_set(DMA_SLAVE, mask);
sig = mcspi_dma-dma_rx_sync_dev;
- mcspi_dma-dma_rx = dma_request_channel(mask, omap_dma_filter_fn, sig);
+
+ mcspi_dma-dma_rx =
+ dma_request_slave_channel_compat(mask, omap_dma_filter_fn,
+sig, master-dev,
+mcspi_dma-dma_rx_ch_name);
+
if (!mcspi_dma-dma_rx) {
dev_err(spi-dev, no RX DMA engine channel for McSPI\n);
return -EAGAIN;
}
sig = mcspi_dma-dma_tx_sync_dev;
- mcspi_dma-dma_tx = dma_request_channel(mask, omap_dma_filter_fn, sig);
+ mcspi_dma-dma_tx =
+ dma_request_slave_channel_compat(mask, omap_dma_filter_fn,
+sig, master-dev,
+mcspi_dma-dma_tx_ch_name);
+
if (!mcspi_dma-dma_tx) {
dev_err(spi-dev, no TX DMA engine channel for McSPI\n);
dma_release_channel(mcspi_dma-dma_rx);
@@ -1217,29 +1229,42 @@ static int __devinit omap2_mcspi_probe(struct
platform_device *pdev)
goto free_master;
for (i = 0; i master-num_chipselect; i++) {
- char dma_ch_name[14];
+ char *dma_rx_ch_name = mcspi-dma_channels[i].dma_rx_ch_name;
+ char *dma_tx_ch_name = mcspi-dma_channels[i].dma_tx_ch_name;
struct resource *dma_res;
- sprintf(dma_ch_name, rx%d, i);
- dma_res = platform_get_resource_byname(pdev, IORESOURCE_DMA,
- dma_ch_name);
- if (!dma_res) {
- dev_dbg(pdev-dev, cannot get DMA RX channel\n);
- status = -ENODEV;
- break;
- }
+ sprintf(dma_rx_ch_name, rx%d, i);
+ if (!pdev-dev.of_node) {
+ dma_res =
+ platform_get_resource_byname(pdev,
+IORESOURCE_DMA,
+dma_rx_ch_name);
+ if (!dma_res) {
+ dev_dbg(pdev-dev,
+ cannot get DMA RX channel\n);
+ status = -ENODEV;
+ break;
+ }
- mcspi-dma_channels[i].dma_rx_sync_dev = dma_res-start;
- sprintf(dma_ch_name, tx%d, i);
- dma_res = platform_get_resource_byname(pdev, IORESOURCE_DMA,
- dma_ch_name);
- if (!dma_res) {
- dev_dbg(pdev-dev, cannot get DMA TX channel\n);
- status = -ENODEV;
- break;
+ mcspi-dma_channels[i].dma_rx_sync_dev =
+ dma_res-start;
}
+ sprintf(dma_tx_ch_name, tx%d, i);
+ if (!pdev-dev.of_node) {
+ dma_res =
+ platform_get_resource_byname(pdev,
+IORESOURCE_DMA,
+dma_tx_ch_name);
+ if (!dma_res) {
+ dev_dbg(pdev-dev,
+ cannot get DMA TX channel\n);
+ status = -ENODEV;
+ break;
+ }
- mcspi-dma_channels[i].dma_tx_sync_dev = dma_res-start;
+ mcspi-dma_channels[i].dma_tx_sync_dev =
+ dma_res-start;
+ }
}
if
[RFC PATCH v2 13/16] ARM: dts: add AM33XX MMC support
Adds AM33XX MMC support to the am33xx.dtsi and the BeagleBone
dts.
Signed-off-by: Matt Porter mpor...@ti.com
---
arch/arm/boot/dts/am335x-bone.dts |6 ++
arch/arm/boot/dts/am33xx.dtsi | 27 +++
2 files changed, 33 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index c634f87..5510979 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -70,6 +70,8 @@
};
ldo3_reg: regulator@5 {
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 330;
regulator-always-on;
};
@@ -78,3 +80,7 @@
};
};
};
+
+mmc1 {
+ vmmc-supply = ldo3_reg;
+};
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 2ddb31b..ef8e105 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -233,6 +233,33 @@
status = disabled;
};
+ mmc1: mmc@4806 {
+ compatible = ti,omap3-hsmmc;
+ ti,hwmods = mmc1;
+ ti,dual-volt;
+ ti,needs-special-reset;
+ dmas = edma 24
+ edma 25;
+ dma-names = tx, rx;
+ };
+
+ mmc2: mmc@481d8000 {
+ compatible = ti,omap3-hsmmc;
+ ti,hwmods = mmc2;
+ ti,needs-special-reset;
+ dmas = edma 2
+ edma 3;
+ dma-names = tx, rx;
+ status = disabled;
+ };
+
+ mmc3: mmc@4781 {
+ compatible = ti,omap3-hsmmc;
+ ti,hwmods = mmc3;
+ ti,needs-special-reset;
+ status = disabled;
+ };
+
wdt2: wdt@44e35000 {
compatible = ti,omap3-wdt;
ti,hwmods = wd_timer2;
--
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
[RFC PATCH v2 11/16] mmc: omap_hsmmc: limit max_segs with the EDMA DMAC
The EDMA DMAC has a hardware limitation that prevents supporting
scatter gather lists with any number of segments. Since the EDMA
DMA Engine driver sets the maximum segments to 16, we do the
same.
TODO: this will be replaced once the DMA Engine API supports an
API to query the DMAC's segment size limit.
Signed-off-by: Matt Porter mpor...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index b327cd0..52bab01 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1828,6 +1828,16 @@ static int __devinit omap_hsmmc_probe(struct
platform_device *pdev)
* as we want. */
mmc-max_segs = 1024;
+ /* Eventually we should get our max_segs limitation for EDMA by
+* querying the dmaengine API */
+ if (pdev-dev.of_node) {
+ struct device_node *parent = pdev-dev.of_node-parent;
+ struct device_node *node;
+ node = of_find_node_by_name(parent, edma);
+ if (node)
+ mmc-max_segs = 16;
+ }
+
mmc-max_blk_size = 512; /* Block Length at max can be 1024 */
mmc-max_blk_count = 0x;/* No. of Blocks is 16 bits */
mmc-max_req_size = mmc-max_blk_size * mmc-max_blk_count;
--
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
[RFC PATCH v2 10/16] mmc: omap_hsmmc: convert to dma_request_slave_channel_compat()
Convert dmaengine channel requests to use
dma_request_slave_channel_compat(). This supports the DT case of
platforms requiring channel selection from either the OMAP DMA or
the EDMA engine. AM33xx only boots from DT and is the only user
implementing EDMA so in the !DT case we can default to the OMAP DMA
filter.
Signed-off-by: Matt Porter mpor...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 54bfd0c..b327cd0 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1866,14 +1866,20 @@ static int __devinit omap_hsmmc_probe(struct
platform_device *pdev)
dma_cap_zero(mask);
dma_cap_set(DMA_SLAVE, mask);
- host-rx_chan = dma_request_channel(mask, omap_dma_filter_fn, rx_req);
+ host-rx_chan =
+ dma_request_slave_channel_compat(mask, omap_dma_filter_fn,
+rx_req, pdev-dev, rx);
+
if (!host-rx_chan) {
dev_err(mmc_dev(host-mmc), unable to obtain RX DMA engine
channel %u\n, rx_req);
ret = -ENXIO;
goto err_irq;
}
- host-tx_chan = dma_request_channel(mask, omap_dma_filter_fn, tx_req);
+ host-tx_chan =
+ dma_request_slave_channel_compat(mask, omap_dma_filter_fn,
+tx_req, pdev-dev, tx);
+
if (!host-tx_chan) {
dev_err(mmc_dev(host-mmc), unable to obtain TX DMA engine
channel %u\n, tx_req);
ret = -ENXIO;
--
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
[RFC PATCH v2 01/16] dmaengine: edma: fix slave config dependency on direction
The edma_slave_config() implementation depends on the
direction field such that it will not properly configure
a slave channel when called without direction set.
This fixes the implementation so that the slave config
is copied as is and prep_slave_sg() handles the
direction dependent handling. spi-omap2-mcspi and
omap_hsmmc both expose this bug as they configure the
slave channel config from a common path with an unconfigured
direction field.
Signed-off-by: Matt Porter mpor...@ti.com
---
drivers/dma/edma.c | 55 ++--
1 file changed, 27 insertions(+), 28 deletions(-)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 05aea3c..fdcf079 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -69,9 +69,7 @@ struct edma_chan {
int ch_num;
boolalloced;
int slot[EDMA_MAX_SLOTS];
- dma_addr_t addr;
- int addr_width;
- int maxburst;
+ struct dma_slave_config cfg;
};
struct edma_cc {
@@ -178,29 +176,14 @@ static int edma_terminate_all(struct edma_chan *echan)
return 0;
}
-
static int edma_slave_config(struct edma_chan *echan,
- struct dma_slave_config *config)
+ struct dma_slave_config *cfg)
{
- if ((config-src_addr_width DMA_SLAVE_BUSWIDTH_4_BYTES) ||
- (config-dst_addr_width DMA_SLAVE_BUSWIDTH_4_BYTES))
+ if (cfg-src_addr_width == DMA_SLAVE_BUSWIDTH_8_BYTES ||
+ cfg-dst_addr_width == DMA_SLAVE_BUSWIDTH_8_BYTES)
return -EINVAL;
- if (config-direction == DMA_MEM_TO_DEV) {
- if (config-dst_addr)
- echan-addr = config-dst_addr;
- if (config-dst_addr_width)
- echan-addr_width = config-dst_addr_width;
- if (config-dst_maxburst)
- echan-maxburst = config-dst_maxburst;
- } else if (config-direction == DMA_DEV_TO_MEM) {
- if (config-src_addr)
- echan-addr = config-src_addr;
- if (config-src_addr_width)
- echan-addr_width = config-src_addr_width;
- if (config-src_maxburst)
- echan-maxburst = config-src_maxburst;
- }
+ memcpy(echan-cfg, cfg, sizeof(echan-cfg));
return 0;
}
@@ -235,6 +218,9 @@ static struct dma_async_tx_descriptor *edma_prep_slave_sg(
struct edma_chan *echan = to_edma_chan(chan);
struct device *dev = chan-device-dev;
struct edma_desc *edesc;
+ dma_addr_t dev_addr;
+ enum dma_slave_buswidth dev_width;
+ u32 burst;
struct scatterlist *sg;
int i;
int acnt, bcnt, ccnt, src, dst, cidx;
@@ -243,7 +229,20 @@ static struct dma_async_tx_descriptor *edma_prep_slave_sg(
if (unlikely(!echan || !sgl || !sg_len))
return NULL;
- if (echan-addr_width == DMA_SLAVE_BUSWIDTH_UNDEFINED) {
+ if (direction == DMA_DEV_TO_MEM) {
+ dev_addr = echan-cfg.src_addr;
+ dev_width = echan-cfg.src_addr_width;
+ burst = echan-cfg.src_maxburst;
+ } else if (direction == DMA_MEM_TO_DEV) {
+ dev_addr = echan-cfg.dst_addr;
+ dev_width = echan-cfg.dst_addr_width;
+ burst = echan-cfg.dst_maxburst;
+ } else {
+ dev_err(dev, %s: bad direction?\n, __func__);
+ return NULL;
+ }
+
+ if (dev_width == DMA_SLAVE_BUSWIDTH_UNDEFINED) {
dev_err(dev, Undefined slave buswidth\n);
return NULL;
}
@@ -275,14 +274,14 @@ static struct dma_async_tx_descriptor *edma_prep_slave_sg(
}
}
- acnt = echan-addr_width;
+ acnt = dev_width;
/*
* If the maxburst is equal to the fifo width, use
* A-synced transfers. This allows for large contiguous
* buffer transfers using only one PaRAM set.
*/
- if (echan-maxburst == 1) {
+ if (burst == 1) {
edesc-absync = false;
ccnt = sg_dma_len(sg) / acnt / (SZ_64K - 1);
bcnt = sg_dma_len(sg) / acnt - ccnt * (SZ_64K - 1);
@@ -302,7 +301,7 @@ static struct dma_async_tx_descriptor *edma_prep_slave_sg(
*/
} else {
edesc-absync = true;
- bcnt = echan-maxburst;
+ bcnt = burst;
ccnt = sg_dma_len(sg) / (acnt * bcnt);
if (ccnt (SZ_64K - 1)) {
dev_err(dev, Exceeded max SG segment size\n);
@@ -313,13 +312,13 @@ static struct
[RFC PATCH v2 03/16] ARM: edma: remove unused transfer controller handlers
Fix build on OMAP, the irqs are undefined on AM33xx.
These error interrupt handlers were hardcoded as disabled
so since they are unused code, simply remove them.
Signed-off-by: Matt Porter mpor...@ti.com
---
arch/arm/common/edma.c | 37 -
1 file changed, 37 deletions(-)
diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index 4411087..a3d189d 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -494,26 +494,6 @@ static irqreturn_t dma_ccerr_handler(int irq, void *data)
return IRQ_HANDLED;
}
-/**
- *
- * Transfer controller error interrupt handlers
- *
- */
-
-#define tc_errs_handledfalse /* disabled as long as they're NOPs */
-
-static irqreturn_t dma_tc0err_handler(int irq, void *data)
-{
- dev_dbg(data, dma_tc0err_handler\n);
- return IRQ_HANDLED;
-}
-
-static irqreturn_t dma_tc1err_handler(int irq, void *data)
-{
- dev_dbg(data, dma_tc1err_handler\n);
- return IRQ_HANDLED;
-}
-
static int reserve_contiguous_slots(int ctlr, unsigned int id,
unsigned int num_slots,
unsigned int start_slot)
@@ -1538,23 +1518,6 @@ static int __init edma_probe(struct platform_device
*pdev)
arch_num_cc++;
}
- if (tc_errs_handled) {
- status = request_irq(IRQ_TCERRINT0, dma_tc0err_handler, 0,
- edma_tc0, pdev-dev);
- if (status 0) {
- dev_dbg(pdev-dev, request_irq %d failed -- %d\n,
- IRQ_TCERRINT0, status);
- return status;
- }
- status = request_irq(IRQ_TCERRINT, dma_tc1err_handler, 0,
- edma_tc1, pdev-dev);
- if (status 0) {
- dev_dbg(pdev-dev, request_irq %d -- %d\n,
- IRQ_TCERRINT, status);
- return status;
- }
- }
-
return 0;
fail:
--
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
[RFC PATCH v2 04/16] ARM: edma: add DT and runtime PM support for AM335x
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.
TODO: add AM33XX crossbar support and DT binding
Signed-off-by: Matt Porter mpor...@ti.com
---
arch/arm/common/edma.c | 252 +--
arch/arm/mach-davinci/board-da830-evm.c |4 +-
arch/arm/mach-davinci/board-da850-evm.c |8 +-
arch/arm/mach-davinci/board-dm646x-evm.c|4 +-
arch/arm/mach-davinci/board-omapl138-hawk.c |8 +-
arch/arm/mach-davinci/devices-da8xx.c |8 +-
arch/arm/mach-davinci/devices-tnetv107x.c |4 +-
arch/arm/mach-davinci/dm355.c |4 +-
arch/arm/mach-davinci/dm365.c |4 +-
arch/arm/mach-davinci/dm644x.c |4 +-
arch/arm/mach-davinci/dm646x.c |4 +-
include/linux/platform_data/edma.h |8 +-
12 files changed, 271 insertions(+), 41 deletions(-)
diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index a3d189d..fd039db 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 linux/platform_data/edma.h
@@ -1366,30 +1373,237 @@ 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) {
+ 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;
+
[RFC PATCH v2 05/16] dmaengine: edma: enable build for AM33XX
Enable TI EDMA option on OMAP. Signed-off-by: Matt Porter mpor...@ti.com --- drivers/dma/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig index 677cd6e..eaea1c2 100644 --- a/drivers/dma/Kconfig +++ b/drivers/dma/Kconfig @@ -210,7 +210,7 @@ config SIRF_DMA config TI_EDMA tristate TI EDMA support - depends on ARCH_DAVINCI + depends on ARCH_DAVINCI || ARCH_OMAP select DMA_ENGINE select DMA_VIRTUAL_CHANNELS default n -- 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
[RFC PATCH v2 08/16] ARM: omap: add hsmmc am33xx specific init
AM33xx requires special handling in hsmmc initialization platform glue. Signed-off-by: Matt Porter mpor...@ti.com --- arch/arm/mach-omap2/hsmmc.c |7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c index 4d3a632..42ce988 100644 --- a/arch/arm/mach-omap2/hsmmc.c +++ b/arch/arm/mach-omap2/hsmmc.c @@ -365,7 +365,7 @@ static int __init omap_hsmmc_pdata_init(struct omap2_hsmmc_info *c, else mmc-slots[0].ocr_mask = c-ocr_mask; - if (!soc_is_am35xx()) + if (!soc_is_am35xx() !soc_is_am33xx()) mmc-slots[0].features |= HSMMC_HAS_PBIAS; if (cpu_is_omap44xx() (omap_rev() OMAP4430_REV_ES1_0)) @@ -388,7 +388,7 @@ static int __init omap_hsmmc_pdata_init(struct omap2_hsmmc_info *c, } } - if (soc_is_am35xx()) + if (soc_is_am35xx() || soc_is_am33xx()) mmc-slots[0].set_power = nop_mmc_set_power; /* OMAP3630 HSMMC1 supports only 4-bit */ @@ -489,7 +489,8 @@ static void __init omap_hsmmc_init_one(struct omap2_hsmmc_info *hsmmcinfo, if (res 0) goto free_mmc; - omap_hsmmc_mux(mmc_data, (ctrl_nr - 1)); + if (!soc_is_am33xx()) + omap_hsmmc_mux(mmc_data, (ctrl_nr - 1)); name = omap_hsmmc; res = snprintf(oh_name, MAX_OMAP_MMC_HWMOD_NAME_LEN, -- 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
[RFC PATCH v2 09/16] dmaengine: add dma_request_slave_channel_compat()
Adds a dma_request_slave_channel_compat() wrapper which accepts
both the arguments from dma_request_channel() and
dma_request_slave_channel(). Based on whether the driver is
instantiated via DT, the appropriate channel request call will be
made.
This allows for a much cleaner migration of drivers to the
dmaengine DT API as platforms continue to be mixed between those
that boot using DT and those that do not.
Suggested-by: Tony Lindgren t...@atomide.com
Signed-off-by: Matt Porter mpor...@ti.com
---
include/linux/dmaengine.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index c88f302..11d9e25 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -1007,6 +1007,16 @@ void dma_run_dependencies(struct dma_async_tx_descriptor
*tx);
struct dma_chan *dma_find_channel(enum dma_transaction_type tx_type);
struct dma_chan *net_dma_find_channel(void);
#define dma_request_channel(mask, x, y) __dma_request_channel((mask), x, y)
+static inline struct dma_chan
+*dma_request_slave_channel_compat(dma_cap_mask_t mask, dma_filter_fn fn,
+ void *fn_param, struct device *dev,
+ char *name)
+{
+ if (dev-of_node)
+ return dma_request_slave_channel(dev, name);
+ else
+ return dma_request_channel(mask, fn, fn_param);
+}
/* --- Helper iov-locking functions --- */
--
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
[RFC PATCH v2 07/16] ARM: dts: add AM33XX EDMA support
Adds AM33XX EDMA support to the am33xx.dtsi as documented in
Documentation/devicetree/bindings/dma/ti-edma.txt
Signed-off-by: Matt Porter mpor...@ti.com
---
arch/arm/boot/dts/am33xx.dtsi | 30 ++
1 file changed, 30 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index bb31bff..2ddb31b 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -62,6 +62,36 @@
reg = 0x4820 0x1000;
};
+ edma: edma@4900 {
+ compatible = ti,edma3;
+ ti,hwmods = tpcc, tptc0, tptc1, tptc2;
+ reg = 0x4900 0x1;
+ interrupt-parent = intc;
+ interrupts = 12 13 14;
+ #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;
+ };
+
gpio1: gpio@44e07000 {
compatible = ti,omap4-gpio;
ti,hwmods = gpio1;
--
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
[RFC PATCH v2 06/16] dmaengine: edma: Add TI EDMA device tree binding
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;
+ 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
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH v2 02/16] ARM: davinci: move private EDMA API to arm/common
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 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/{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 | 198 ++
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, 228 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 767aae8..56b7b23 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -911,6 +911,7 @@ config ARCH_DAVINCI
select GENERIC_IRQ_CHIP
select ARCH_HAS_HOLES_MEMORYMODEL
select NEED_MACH_GPIO_H
+ select TI_PRIV_EDMA
help
Support for TI's DaVinci platform.
diff --git a/arch/arm/common/Kconfig b/arch/arm/common/Kconfig
index 283fa1d..bd87838 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 2227eff..97c639e 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
+#include linux/platform_data/edma.h
#include linux/platform_data/keyscan-davinci.h
#include mach/hardware.h
-#include mach/edma.h
#include media/davinci/vpfe_capture.h
#include media/davinci/vpif_types.h
diff --git a/arch/arm/mach-davinci/devices-tnetv107x.c
[PATCH] of: dma: fix protection of DMA controller data stored by DMA helpers
In the current implementation of the OF DMA helpers, read-copy-update (RCU)
linked lists are being used for storing and accessing the DMA controller data.
This part of implementation is based upon V2 of the DMA helpers by Nicolas [1].
During a recent review of RCU, it became apparent that the code is missing the
required rcu_read_lock()/unlock() calls as well as synchronisation calls before
freeing any memory protected by RCU.
Having looked into adding the appropriate RCU calls to protect the DMA data it
became apparent that with the current DMA helper implementation, using RCU is
not as attractive as it may have been before. The main reasons being that ...
1. We need to protect the DMA data around calls to the xlate function.
2. The of_dma_simple_xlate() function calls the DMA engine function
dma_request_channel() which employs a mutex and so could sleep.
3. The RCU read-side critical sections must not sleep and so we cannot hold
an RCU read lock around the xlate function.
Therefore, instead of using RCU, an alternative for this use-case is to employ
a simple spinlock inconjunction with a usage count variable to keep track of
how many current users of the DMA data structure there are. With this
implementation, the DMA data cannot be freed until all current users of the
DMA data are finished.
This patch is based upon the DMA helpers fix for potential deadlock [2].
[1] http://article.gmane.org/gmane.linux.ports.arm.omap/73622
[2] http://marc.info/?l=linux-arm-kernelm=134859982520984w=2
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
drivers/of/dma.c | 89
include/linux/of_dma.h |5 +--
2 files changed, 70 insertions(+), 24 deletions(-)
diff --git a/drivers/of/dma.c b/drivers/of/dma.c
index 4bed490..59631b2 100644
--- a/drivers/of/dma.c
+++ b/drivers/of/dma.c
@@ -19,28 +19,61 @@
#include linux/of_dma.h
static LIST_HEAD(of_dma_list);
+static DEFINE_SPINLOCK(of_dma_lock);
/**
- * of_dma_find_controller - Find a DMA controller in DT DMA helpers list
- * @np:device node of DMA controller
+ * of_dma_get_controller - Get a DMA controller in DT DMA helpers list
+ * @dma_spec: pointer to DMA specifier as found in the device tree
+ *
+ * Finds a DMA controller with matching device node and number for dma cells
+ * in a list of registered DMA controllers. If a match is found the use_count
+ * variable is increased and a valid pointer to the DMA data stored is retuned.
+ * A NULL pointer is returned if no match is found.
*/
-static struct of_dma *of_dma_find_controller(struct device_node *np)
+static struct of_dma *of_dma_get_controller(struct of_phandle_args *dma_spec)
{
struct of_dma *ofdma;
+ spin_lock(of_dma_lock);
+
if (list_empty(of_dma_list)) {
- pr_err(empty DMA controller list\n);
+ spin_unlock(of_dma_lock);
return NULL;
}
- list_for_each_entry_rcu(ofdma, of_dma_list, of_dma_controllers)
- if (ofdma-of_node == np)
+ list_for_each_entry(ofdma, of_dma_list, of_dma_controllers)
+ if ((ofdma-of_node == dma_spec-np)
+ (ofdma-of_dma_nbcells == dma_spec-args_count)) {
+ ofdma-use_count++;
+ spin_unlock(of_dma_lock);
return ofdma;
+ }
+
+ spin_unlock(of_dma_lock);
+
+ pr_debug(%s: can't find DMA controller %s\n, __func__,
+dma_spec-np-full_name);
return NULL;
}
/**
+ * of_dma_put_controller - Decrement use count for a registered DMA controller
+ * @of_dma:pointer to DMA controller data
+ *
+ * Decrements the use_count variable in the DMA data structure. This function
+ * should be called only when a valid pointer is returned from
+ * of_dma_get_controller() and no further accesses to data referenced by that
+ * pointer are needed.
+ */
+static void of_dma_put_controller(struct of_dma *ofdma)
+{
+ spin_lock(of_dma_lock);
+ ofdma-use_count--;
+ spin_unlock(of_dma_lock);
+}
+
+/**
* of_dma_controller_register - Register a DMA controller to DT DMA helpers
* @np:device node of DMA controller
* @of_dma_xlate: translation function which converts a phandle
@@ -81,9 +114,10 @@ int of_dma_controller_register(struct device_node *np,
ofdma-of_dma_nbcells = nbcells;
ofdma-of_dma_xlate = of_dma_xlate;
ofdma-of_dma_data = data;
+ ofdma-use_count = 0;
/* Now queue of_dma controller structure in list */
- list_add_tail_rcu(ofdma-of_dma_controllers, of_dma_list);
+ list_add_tail(ofdma-of_dma_controllers, of_dma_list);
return 0;
}
@@ -95,15 +129,32 @@ EXPORT_SYMBOL_GPL(of_dma_controller_register);
*
* Memory allocated by of_dma_controller_register() is freed here.
*/
-void of_dma_controller_free(struct device_node *np)
+int of_dma_controller_free(struct
Re: [PATCH v3] ARM: OMAP: i2c: fix interrupt flood during resume
Hi Kalle,
Kalle Jokiniemi kalle.jokini...@jollamobile.com writes:
The resume_noirq enables interrupts one-by-one starting from
first one. Now if the wake up event for suspend came from i2c
device, the i2c bus irq gets enabled before the threaded
i2c device irq, causing a flood of i2c bus interrupts as the
threaded irq that should clear the event is not enabled yet.
Fixed the issue by adding suspend_noirq and resume_early
functions that keep i2c bus interrupts disabled until
resume_noirq has run completely.
Issue was detected doing a wake up from autosleep with
twl4030 power key on N9. Patch tested on N9.
Signed-off-by: Kalle Jokiniemi kalle.jokini...@jollamobile.com
This version looks good, thanks for the extra comments.
Reviewed-by: Kevin Hilman khil...@ti.com
Tested-by: Kevin Hilman khil...@ti.com
Wolfram, This should also probably be Cc'd to stable since it affects
earlier kernels as well. Thanks,
Kevin
---
drivers/i2c/busses/i2c-omap.c | 34 ++
1 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index a0e49f6..991341b 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1132,6 +1132,36 @@ static int __devexit omap_i2c_remove(struct
platform_device *pdev)
}
#ifdef CONFIG_PM
+#ifdef CONFIG_PM_SLEEP
+static int omap_i2c_suspend_noirq(struct device *dev)
+{
+
+ struct platform_device *pdev = to_platform_device(dev);
+ struct omap_i2c_dev *_dev = platform_get_drvdata(pdev);
+
+ /* Disabling irq here to balance the enable in resume_early */
+ disable_irq(_dev-irq);
+ return 0;
+}
+
+static int omap_i2c_resume_early(struct device *dev)
+{
+
+ struct platform_device *pdev = to_platform_device(dev);
+ struct omap_i2c_dev *_dev = platform_get_drvdata(pdev);
+
+ /*
+ * The noirq_resume enables the interrupts one by one,
+ * this causes a interrupt flood if the SW irq actually reading
+ * event from i2c device is enabled only after i2c bus irq, as the
+ * irq that should clear the event is still disabled. We have to
+ * keep the bus irq disabled until all other irqs have been enabled.
+ */
+ enable_irq(_dev-irq);
+
+ return 0;
+}
+#endif
#ifdef CONFIG_PM_RUNTIME
static int omap_i2c_runtime_suspend(struct device *dev)
{
@@ -1183,6 +1213,10 @@ static int omap_i2c_runtime_resume(struct device *dev)
#endif /* CONFIG_PM_RUNTIME */
static struct dev_pm_ops omap_i2c_pm_ops = {
+#ifdef CONFIG_PM_SLEEP
+ .suspend_noirq = omap_i2c_suspend_noirq,
+ .resume_early = omap_i2c_resume_early,
+#endif
SET_RUNTIME_PM_OPS(omap_i2c_runtime_suspend,
omap_i2c_runtime_resume, NULL)
};
--
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 00/16] DMA Engine support for AM33xx
On Thu, Oct 11, 2012 at 10:31:58PM +0100, Grant Likely wrote: Hey Matt, Do you know now similar are the EDMA engines on the am33xx and am389x? I've been working on am389x upstreaming and I'll try these patches out if it is the same engine. Hi Grant, It's the same one. am389x/ti816x and am387x/ti814x are part of the same architectural family as am33xx. They've just never had a lot of upstream support from TI. I heard rumors that you might be working with am389x and I'm glad you're confirming that for me! ;) The only differences between am33xx's implementation and the others is going to be the number PaRAM slots, number of TCs, the channel mapping, and then the crossbar mapping. As you can see from the TODO list, I don't yet support the crossbar, but it'll be in the next version of this series. The other items are already covered in the DT binding so it should be straightforward to hook this up for am389x assuming your hwmod and clock data is good for that part. -Matt -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/6] OMAP: iommu: hwmod, reset handling and runtime PM
These patches are needed for remoteproc to work on OMAP4. Introduced iommu hwmod support for OMAP3 (iva, isp) and OMAP4 (ipu, dsp), along with the corresponding runtime PM and routines to deassert reset lines, enable/disable clocks and configure sysc registers. Although IOMMU hwmod patches were already submitted in the past, this series adds few more changes, like: - New reset handling. - Save and restore context code rework. - Device tree bindings for OMAP3 and OMAP4. For this series I just dropped the patches already included in mainline. Previous work can be found at: [v2] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg75701.html [v1] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg70447.html [old iteration without reset, save/restore and device tree] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg60133.html Omar Ramirez Luna (6): ARM: OMAP3/4: iommu: migrate to hwmod framework ARM: OMAP3/4: iommu: adapt to runtime pm ARM: OMAP: iommu: pm runtime save and restore context ARM: OMAP: iommu: optimize save and restore routines ARM: OMAP: iommu: add device tree support arm/dts: OMAP3/4: Add iommu nodes .../devicetree/bindings/arm/omap/iommu.txt | 10 ++ arch/arm/boot/dts/omap3.dtsi | 12 +- arch/arm/boot/dts/omap4.dtsi | 17 +- arch/arm/mach-omap2/devices.c |2 +- arch/arm/mach-omap2/iommu2.c | 74 ++-- arch/arm/mach-omap2/omap-iommu.c | 176 +--- arch/arm/plat-omap/include/plat/iommu.h| 20 ++- arch/arm/plat-omap/include/plat/iommu2.h |4 - drivers/iommu/omap-iommu.c | 163 ++ 9 files changed, 245 insertions(+), 233 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/omap/iommu.txt -- 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 v3 1/6] ARM: OMAP3/4: iommu: migrate to hwmod framework
Use hwmod data and device attributes to build and register an
omap device for iommu driver.
- Update the naming convention in isp module.
- Remove unneeded check for number of resources, as this is now
handled by omap_device and prevents driver from loading.
- Now unused, remove platform device and resource data, handling
of sysconfig register for softreset purposes, use default
latency structure.
- Use hwmod API for reset handling.
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
arch/arm/mach-omap2/devices.c |2 +-
arch/arm/mach-omap2/iommu2.c| 19
arch/arm/mach-omap2/omap-iommu.c| 165 +++
arch/arm/plat-omap/include/plat/iommu.h |8 +-
drivers/iommu/omap-iommu.c | 23 -
5 files changed, 64 insertions(+), 153 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index c8c2117..e084b94 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -213,7 +213,7 @@ static struct platform_device omap3isp_device = {
};
static struct omap_iommu_arch_data omap3_isp_iommu = {
- .name = isp,
+ .name = mmu_isp,
};
int omap3_init_camera(struct isp_platform_data *pdata)
diff --git a/arch/arm/mach-omap2/iommu2.c b/arch/arm/mach-omap2/iommu2.c
index eefc379..35cab47 100644
--- a/arch/arm/mach-omap2/iommu2.c
+++ b/arch/arm/mach-omap2/iommu2.c
@@ -32,12 +32,8 @@
#define MMU_SYS_IDLE_SMART (2 MMU_SYS_IDLE_SHIFT)
#define MMU_SYS_IDLE_MASK (3 MMU_SYS_IDLE_SHIFT)
-#define MMU_SYS_SOFTRESET (1 1)
#define MMU_SYS_AUTOIDLE 1
-/* SYSSTATUS */
-#define MMU_SYS_RESETDONE 1
-
/* IRQSTATUS IRQENABLE */
#define MMU_IRQ_MULTIHITFAULT (1 4)
#define MMU_IRQ_TABLEWALKFAULT (1 3)
@@ -88,7 +84,6 @@ static void __iommu_set_twl(struct omap_iommu *obj, bool on)
static int omap2_iommu_enable(struct omap_iommu *obj)
{
u32 l, pa;
- unsigned long timeout;
if (!obj-iopgd || !IS_ALIGNED((u32)obj-iopgd, SZ_16K))
return -EINVAL;
@@ -97,20 +92,6 @@ static int omap2_iommu_enable(struct omap_iommu *obj)
if (!IS_ALIGNED(pa, SZ_16K))
return -EINVAL;
- iommu_write_reg(obj, MMU_SYS_SOFTRESET, MMU_SYSCONFIG);
-
- timeout = jiffies + msecs_to_jiffies(20);
- do {
- l = iommu_read_reg(obj, MMU_SYSSTATUS);
- if (l MMU_SYS_RESETDONE)
- break;
- } while (!time_after(jiffies, timeout));
-
- if (!(l MMU_SYS_RESETDONE)) {
- dev_err(obj-dev, can't take mmu out of reset\n);
- return -ENODEV;
- }
-
l = iommu_read_reg(obj, MMU_REVISION);
dev_info(obj-dev, %s: version %d.%d\n, obj-name,
(l 4) 0xf, l 0xf);
diff --git a/arch/arm/mach-omap2/omap-iommu.c b/arch/arm/mach-omap2/omap-iommu.c
index df298d4..e400845 100644
--- a/arch/arm/mach-omap2/omap-iommu.c
+++ b/arch/arm/mach-omap2/omap-iommu.c
@@ -12,153 +12,64 @@
#include linux/module.h
#include linux/platform_device.h
+#include linux/err.h
+#include linux/slab.h
#include plat/iommu.h
+#include plat/omap_hwmod.h
+#include plat/omap_device.h
#include soc.h
#include common.h
-struct iommu_device {
- resource_size_t base;
- int irq;
- struct iommu_platform_data pdata;
- struct resource res[2];
-};
-static struct iommu_device *devices;
-static int num_iommu_devices;
-
-#ifdef CONFIG_ARCH_OMAP3
-static struct iommu_device omap3_devices[] = {
- {
- .base = 0x480bd400,
- .irq = 24 + OMAP_INTC_START,
- .pdata = {
- .name = isp,
- .nr_tlb_entries = 8,
- .clk_name = cam_ick,
- .da_start = 0x0,
- .da_end = 0xF000,
- },
- },
-#if defined(CONFIG_OMAP_IOMMU_IVA2)
- {
- .base = 0x5d00,
- .irq = 28 + OMAP_INTC_START,
- .pdata = {
- .name = iva2,
- .nr_tlb_entries = 32,
- .clk_name = iva2_ck,
- .da_start = 0x1100,
- .da_end = 0xF000,
- },
- },
-#endif
-};
-#define NR_OMAP3_IOMMU_DEVICES ARRAY_SIZE(omap3_devices)
-static struct platform_device *omap3_iommu_pdev[NR_OMAP3_IOMMU_DEVICES];
-#else
-#define omap3_devices NULL
-#define NR_OMAP3_IOMMU_DEVICES 0
-#define omap3_iommu_pdev NULL
-#endif
-
-#ifdef CONFIG_ARCH_OMAP4
-static struct iommu_device omap4_devices[] = {
- {
- .base = OMAP4_MMU1_BASE,
- .irq = 100 + OMAP44XX_IRQ_GIC_START,
- .pdata = {
- .name = ducati,
- .nr_tlb_entries = 32,
- .clk_name = ipu_fck,
- .da_start = 0x0,
-
[PATCH 1/6] ARM: OMAP3/4: iommu: migrate to hwmod framework
Use hwmod data and device attributes to build and register an
omap device for iommu driver.
- Update the naming convention in isp module.
- Remove unneeded check for number of resources, as this is now
handled by omap_device and prevents driver from loading.
- Now unused, remove platform device and resource data, handling
of sysconfig register for softreset purposes, use default
latency structure.
- Use hwmod API for reset handling.
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
arch/arm/mach-omap2/devices.c |2 +-
arch/arm/mach-omap2/iommu2.c| 19
arch/arm/mach-omap2/omap-iommu.c| 165 +++
arch/arm/plat-omap/include/plat/iommu.h |8 +-
drivers/iommu/omap-iommu.c | 23 -
5 files changed, 64 insertions(+), 153 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index c8c2117..e084b94 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -213,7 +213,7 @@ static struct platform_device omap3isp_device = {
};
static struct omap_iommu_arch_data omap3_isp_iommu = {
- .name = isp,
+ .name = mmu_isp,
};
int omap3_init_camera(struct isp_platform_data *pdata)
diff --git a/arch/arm/mach-omap2/iommu2.c b/arch/arm/mach-omap2/iommu2.c
index eefc379..35cab47 100644
--- a/arch/arm/mach-omap2/iommu2.c
+++ b/arch/arm/mach-omap2/iommu2.c
@@ -32,12 +32,8 @@
#define MMU_SYS_IDLE_SMART (2 MMU_SYS_IDLE_SHIFT)
#define MMU_SYS_IDLE_MASK (3 MMU_SYS_IDLE_SHIFT)
-#define MMU_SYS_SOFTRESET (1 1)
#define MMU_SYS_AUTOIDLE 1
-/* SYSSTATUS */
-#define MMU_SYS_RESETDONE 1
-
/* IRQSTATUS IRQENABLE */
#define MMU_IRQ_MULTIHITFAULT (1 4)
#define MMU_IRQ_TABLEWALKFAULT (1 3)
@@ -88,7 +84,6 @@ static void __iommu_set_twl(struct omap_iommu *obj, bool on)
static int omap2_iommu_enable(struct omap_iommu *obj)
{
u32 l, pa;
- unsigned long timeout;
if (!obj-iopgd || !IS_ALIGNED((u32)obj-iopgd, SZ_16K))
return -EINVAL;
@@ -97,20 +92,6 @@ static int omap2_iommu_enable(struct omap_iommu *obj)
if (!IS_ALIGNED(pa, SZ_16K))
return -EINVAL;
- iommu_write_reg(obj, MMU_SYS_SOFTRESET, MMU_SYSCONFIG);
-
- timeout = jiffies + msecs_to_jiffies(20);
- do {
- l = iommu_read_reg(obj, MMU_SYSSTATUS);
- if (l MMU_SYS_RESETDONE)
- break;
- } while (!time_after(jiffies, timeout));
-
- if (!(l MMU_SYS_RESETDONE)) {
- dev_err(obj-dev, can't take mmu out of reset\n);
- return -ENODEV;
- }
-
l = iommu_read_reg(obj, MMU_REVISION);
dev_info(obj-dev, %s: version %d.%d\n, obj-name,
(l 4) 0xf, l 0xf);
diff --git a/arch/arm/mach-omap2/omap-iommu.c b/arch/arm/mach-omap2/omap-iommu.c
index df298d4..e400845 100644
--- a/arch/arm/mach-omap2/omap-iommu.c
+++ b/arch/arm/mach-omap2/omap-iommu.c
@@ -12,153 +12,64 @@
#include linux/module.h
#include linux/platform_device.h
+#include linux/err.h
+#include linux/slab.h
#include plat/iommu.h
+#include plat/omap_hwmod.h
+#include plat/omap_device.h
#include soc.h
#include common.h
-struct iommu_device {
- resource_size_t base;
- int irq;
- struct iommu_platform_data pdata;
- struct resource res[2];
-};
-static struct iommu_device *devices;
-static int num_iommu_devices;
-
-#ifdef CONFIG_ARCH_OMAP3
-static struct iommu_device omap3_devices[] = {
- {
- .base = 0x480bd400,
- .irq = 24 + OMAP_INTC_START,
- .pdata = {
- .name = isp,
- .nr_tlb_entries = 8,
- .clk_name = cam_ick,
- .da_start = 0x0,
- .da_end = 0xF000,
- },
- },
-#if defined(CONFIG_OMAP_IOMMU_IVA2)
- {
- .base = 0x5d00,
- .irq = 28 + OMAP_INTC_START,
- .pdata = {
- .name = iva2,
- .nr_tlb_entries = 32,
- .clk_name = iva2_ck,
- .da_start = 0x1100,
- .da_end = 0xF000,
- },
- },
-#endif
-};
-#define NR_OMAP3_IOMMU_DEVICES ARRAY_SIZE(omap3_devices)
-static struct platform_device *omap3_iommu_pdev[NR_OMAP3_IOMMU_DEVICES];
-#else
-#define omap3_devices NULL
-#define NR_OMAP3_IOMMU_DEVICES 0
-#define omap3_iommu_pdev NULL
-#endif
-
-#ifdef CONFIG_ARCH_OMAP4
-static struct iommu_device omap4_devices[] = {
- {
- .base = OMAP4_MMU1_BASE,
- .irq = 100 + OMAP44XX_IRQ_GIC_START,
- .pdata = {
- .name = ducati,
- .nr_tlb_entries = 32,
- .clk_name = ipu_fck,
- .da_start = 0x0,
-
[PATCH v3 2/6] ARM: OMAP3/4: iommu: adapt to runtime pm
Use runtime PM functionality interfaced with hwmod enable/idle
functions, to replace direct clock operations and sysconfig
handling.
Dues to reset sequence, pm_runtime_put_sync must be used, to avoid
possible operations with the module under reset.
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
arch/arm/mach-omap2/iommu2.c | 17 ---
arch/arm/mach-omap2/omap-iommu.c |1 -
arch/arm/plat-omap/include/plat/iommu.h |2 --
arch/arm/plat-omap/include/plat/iommu2.h |2 --
drivers/iommu/omap-iommu.c | 45 +-
5 files changed, 19 insertions(+), 48 deletions(-)
diff --git a/arch/arm/mach-omap2/iommu2.c b/arch/arm/mach-omap2/iommu2.c
index 35cab47..3e47786 100644
--- a/arch/arm/mach-omap2/iommu2.c
+++ b/arch/arm/mach-omap2/iommu2.c
@@ -25,15 +25,6 @@
*/
#define IOMMU_ARCH_VERSION 0x0011
-/* SYSCONF */
-#define MMU_SYS_IDLE_SHIFT 3
-#define MMU_SYS_IDLE_FORCE (0 MMU_SYS_IDLE_SHIFT)
-#define MMU_SYS_IDLE_NONE (1 MMU_SYS_IDLE_SHIFT)
-#define MMU_SYS_IDLE_SMART (2 MMU_SYS_IDLE_SHIFT)
-#define MMU_SYS_IDLE_MASK (3 MMU_SYS_IDLE_SHIFT)
-
-#define MMU_SYS_AUTOIDLE 1
-
/* IRQSTATUS IRQENABLE */
#define MMU_IRQ_MULTIHITFAULT (1 4)
#define MMU_IRQ_TABLEWALKFAULT (1 3)
@@ -96,11 +87,6 @@ static int omap2_iommu_enable(struct omap_iommu *obj)
dev_info(obj-dev, %s: version %d.%d\n, obj-name,
(l 4) 0xf, l 0xf);
- l = iommu_read_reg(obj, MMU_SYSCONFIG);
- l = ~MMU_SYS_IDLE_MASK;
- l |= (MMU_SYS_IDLE_SMART | MMU_SYS_AUTOIDLE);
- iommu_write_reg(obj, l, MMU_SYSCONFIG);
-
iommu_write_reg(obj, pa, MMU_TTB);
__iommu_set_twl(obj, true);
@@ -114,7 +100,6 @@ static void omap2_iommu_disable(struct omap_iommu *obj)
l = ~MMU_CNTL_MASK;
iommu_write_reg(obj, l, MMU_CNTL);
- iommu_write_reg(obj, MMU_SYS_IDLE_FORCE, MMU_SYSCONFIG);
dev_dbg(obj-dev, %s is shutting down\n, obj-name);
}
@@ -243,8 +228,6 @@ omap2_iommu_dump_ctx(struct omap_iommu *obj, char *buf,
ssize_t len)
char *p = buf;
pr_reg(REVISION);
- pr_reg(SYSCONFIG);
- pr_reg(SYSSTATUS);
pr_reg(IRQSTATUS);
pr_reg(IRQENABLE);
pr_reg(WALKING_ST);
diff --git a/arch/arm/mach-omap2/omap-iommu.c b/arch/arm/mach-omap2/omap-iommu.c
index e400845..82a422a 100644
--- a/arch/arm/mach-omap2/omap-iommu.c
+++ b/arch/arm/mach-omap2/omap-iommu.c
@@ -34,7 +34,6 @@ static int __init omap_iommu_dev_init(struct omap_hwmod *oh,
void *unused)
return -ENOMEM;
pdata-name = oh-name;
- pdata-clk_name = oh-main_clk;
pdata-nr_tlb_entries = a-nr_tlb_entries;
pdata-da_start = a-da_start;
pdata-da_end = a-da_end;
diff --git a/arch/arm/plat-omap/include/plat/iommu.h
b/arch/arm/plat-omap/include/plat/iommu.h
index 0fa913d..902d193 100644
--- a/arch/arm/plat-omap/include/plat/iommu.h
+++ b/arch/arm/plat-omap/include/plat/iommu.h
@@ -30,7 +30,6 @@ struct iotlb_entry {
struct omap_iommu {
const char *name;
struct module *owner;
- struct clk *clk;
void __iomem*regbase;
struct device *dev;
void*isr_priv;
@@ -120,7 +119,6 @@ struct omap_mmu_dev_attr {
struct iommu_platform_data {
const char *name;
- const char *clk_name;
const char *reset_name;
int nr_tlb_entries;
u32 da_start;
diff --git a/arch/arm/plat-omap/include/plat/iommu2.h
b/arch/arm/plat-omap/include/plat/iommu2.h
index d4116b5..1579694 100644
--- a/arch/arm/plat-omap/include/plat/iommu2.h
+++ b/arch/arm/plat-omap/include/plat/iommu2.h
@@ -19,8 +19,6 @@
* MMU Register offsets
*/
#define MMU_REVISION 0x00
-#define MMU_SYSCONFIG 0x10
-#define MMU_SYSSTATUS 0x14
#define MMU_IRQSTATUS 0x18
#define MMU_IRQENABLE 0x1c
#define MMU_WALKING_ST 0x40
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index c1caee4..37644c4 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -16,11 +16,11 @@
#include linux/slab.h
#include linux/interrupt.h
#include linux/ioport.h
-#include linux/clk.h
#include linux/platform_device.h
#include linux/iommu.h
#include linux/mutex.h
#include linux/spinlock.h
+#include linux/pm_runtime.h
#include asm/cacheflush.h
@@ -142,11 +142,10 @@ static int iommu_enable(struct omap_iommu *obj)
}
}
- clk_enable(obj-clk);
+ pm_runtime_get_sync(obj-dev);
err = arch_iommu-enable(obj);
- clk_disable(obj-clk);
return err;
}
@@ -158,11 +157,9 @@ static void iommu_disable(struct omap_iommu *obj)
if (!obj || !pdata)
return;
- clk_enable(obj-clk);
-
arch_iommu-disable(obj);
- clk_disable(obj-clk);
+ pm_runtime_put_sync(obj-dev);
if
[PATCH 2/6] ARM: OMAP3/4: iommu: adapt to runtime pm
Use runtime PM functionality interfaced with hwmod enable/idle
functions, to replace direct clock operations and sysconfig
handling.
Dues to reset sequence, pm_runtime_put_sync must be used, to avoid
possible operations with the module under reset.
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
arch/arm/mach-omap2/iommu2.c | 17 ---
arch/arm/mach-omap2/omap-iommu.c |1 -
arch/arm/plat-omap/include/plat/iommu.h |2 --
arch/arm/plat-omap/include/plat/iommu2.h |2 --
drivers/iommu/omap-iommu.c | 45 +-
5 files changed, 19 insertions(+), 48 deletions(-)
diff --git a/arch/arm/mach-omap2/iommu2.c b/arch/arm/mach-omap2/iommu2.c
index 35cab47..3e47786 100644
--- a/arch/arm/mach-omap2/iommu2.c
+++ b/arch/arm/mach-omap2/iommu2.c
@@ -25,15 +25,6 @@
*/
#define IOMMU_ARCH_VERSION 0x0011
-/* SYSCONF */
-#define MMU_SYS_IDLE_SHIFT 3
-#define MMU_SYS_IDLE_FORCE (0 MMU_SYS_IDLE_SHIFT)
-#define MMU_SYS_IDLE_NONE (1 MMU_SYS_IDLE_SHIFT)
-#define MMU_SYS_IDLE_SMART (2 MMU_SYS_IDLE_SHIFT)
-#define MMU_SYS_IDLE_MASK (3 MMU_SYS_IDLE_SHIFT)
-
-#define MMU_SYS_AUTOIDLE 1
-
/* IRQSTATUS IRQENABLE */
#define MMU_IRQ_MULTIHITFAULT (1 4)
#define MMU_IRQ_TABLEWALKFAULT (1 3)
@@ -96,11 +87,6 @@ static int omap2_iommu_enable(struct omap_iommu *obj)
dev_info(obj-dev, %s: version %d.%d\n, obj-name,
(l 4) 0xf, l 0xf);
- l = iommu_read_reg(obj, MMU_SYSCONFIG);
- l = ~MMU_SYS_IDLE_MASK;
- l |= (MMU_SYS_IDLE_SMART | MMU_SYS_AUTOIDLE);
- iommu_write_reg(obj, l, MMU_SYSCONFIG);
-
iommu_write_reg(obj, pa, MMU_TTB);
__iommu_set_twl(obj, true);
@@ -114,7 +100,6 @@ static void omap2_iommu_disable(struct omap_iommu *obj)
l = ~MMU_CNTL_MASK;
iommu_write_reg(obj, l, MMU_CNTL);
- iommu_write_reg(obj, MMU_SYS_IDLE_FORCE, MMU_SYSCONFIG);
dev_dbg(obj-dev, %s is shutting down\n, obj-name);
}
@@ -243,8 +228,6 @@ omap2_iommu_dump_ctx(struct omap_iommu *obj, char *buf,
ssize_t len)
char *p = buf;
pr_reg(REVISION);
- pr_reg(SYSCONFIG);
- pr_reg(SYSSTATUS);
pr_reg(IRQSTATUS);
pr_reg(IRQENABLE);
pr_reg(WALKING_ST);
diff --git a/arch/arm/mach-omap2/omap-iommu.c b/arch/arm/mach-omap2/omap-iommu.c
index e400845..82a422a 100644
--- a/arch/arm/mach-omap2/omap-iommu.c
+++ b/arch/arm/mach-omap2/omap-iommu.c
@@ -34,7 +34,6 @@ static int __init omap_iommu_dev_init(struct omap_hwmod *oh,
void *unused)
return -ENOMEM;
pdata-name = oh-name;
- pdata-clk_name = oh-main_clk;
pdata-nr_tlb_entries = a-nr_tlb_entries;
pdata-da_start = a-da_start;
pdata-da_end = a-da_end;
diff --git a/arch/arm/plat-omap/include/plat/iommu.h
b/arch/arm/plat-omap/include/plat/iommu.h
index 0fa913d..902d193 100644
--- a/arch/arm/plat-omap/include/plat/iommu.h
+++ b/arch/arm/plat-omap/include/plat/iommu.h
@@ -30,7 +30,6 @@ struct iotlb_entry {
struct omap_iommu {
const char *name;
struct module *owner;
- struct clk *clk;
void __iomem*regbase;
struct device *dev;
void*isr_priv;
@@ -120,7 +119,6 @@ struct omap_mmu_dev_attr {
struct iommu_platform_data {
const char *name;
- const char *clk_name;
const char *reset_name;
int nr_tlb_entries;
u32 da_start;
diff --git a/arch/arm/plat-omap/include/plat/iommu2.h
b/arch/arm/plat-omap/include/plat/iommu2.h
index d4116b5..1579694 100644
--- a/arch/arm/plat-omap/include/plat/iommu2.h
+++ b/arch/arm/plat-omap/include/plat/iommu2.h
@@ -19,8 +19,6 @@
* MMU Register offsets
*/
#define MMU_REVISION 0x00
-#define MMU_SYSCONFIG 0x10
-#define MMU_SYSSTATUS 0x14
#define MMU_IRQSTATUS 0x18
#define MMU_IRQENABLE 0x1c
#define MMU_WALKING_ST 0x40
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index c1caee4..37644c4 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -16,11 +16,11 @@
#include linux/slab.h
#include linux/interrupt.h
#include linux/ioport.h
-#include linux/clk.h
#include linux/platform_device.h
#include linux/iommu.h
#include linux/mutex.h
#include linux/spinlock.h
+#include linux/pm_runtime.h
#include asm/cacheflush.h
@@ -142,11 +142,10 @@ static int iommu_enable(struct omap_iommu *obj)
}
}
- clk_enable(obj-clk);
+ pm_runtime_get_sync(obj-dev);
err = arch_iommu-enable(obj);
- clk_disable(obj-clk);
return err;
}
@@ -158,11 +157,9 @@ static void iommu_disable(struct omap_iommu *obj)
if (!obj || !pdata)
return;
- clk_enable(obj-clk);
-
arch_iommu-disable(obj);
- clk_disable(obj-clk);
+ pm_runtime_put_sync(obj-dev);
if
[PATCH v3 3/6] ARM: OMAP: iommu: pm runtime save and restore context
Save and restore context during pm runtime transitions.
For now, the previous API for this purpose will trigger
pm runtime functions, and will be left as exported symbol
for compatibility with it's only user.
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
drivers/iommu/omap-iommu.c | 29 +++--
1 file changed, 27 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index 37644c4..875e894 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -97,7 +97,7 @@ void omap_iommu_save_ctx(struct device *dev)
{
struct omap_iommu *obj = dev_to_omap_iommu(dev);
- arch_iommu-save_ctx(obj);
+ pm_runtime_put_sync(obj-dev);
}
EXPORT_SYMBOL_GPL(omap_iommu_save_ctx);
@@ -109,7 +109,7 @@ void omap_iommu_restore_ctx(struct device *dev)
{
struct omap_iommu *obj = dev_to_omap_iommu(dev);
- arch_iommu-restore_ctx(obj);
+ pm_runtime_get_sync(obj-dev);
}
EXPORT_SYMBOL_GPL(omap_iommu_restore_ctx);
@@ -1008,11 +1008,36 @@ static int __devexit omap_iommu_remove(struct
platform_device *pdev)
return 0;
}
+static int omap_iommu_runtime_suspend(struct device *dev)
+{
+ struct omap_iommu *obj = to_iommu(dev);
+
+ arch_iommu-save_ctx(obj);
+
+ return 0;
+}
+
+static int omap_iommu_runtime_resume(struct device *dev)
+{
+ struct omap_iommu *obj = to_iommu(dev);
+
+ arch_iommu-restore_ctx(obj);
+
+ return 0;
+}
+
+static const struct dev_pm_ops iommu_pm_ops = {
+ SET_RUNTIME_PM_OPS(omap_iommu_runtime_suspend,
+ omap_iommu_runtime_resume,
+ NULL)
+};
+
static struct platform_driver omap_iommu_driver = {
.probe = omap_iommu_probe,
.remove = __devexit_p(omap_iommu_remove),
.driver = {
.name = omap-iommu,
+ .pm = iommu_pm_ops,
},
};
--
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/6] ARM: OMAP: iommu: pm runtime save and restore context
Save and restore context during pm runtime transitions.
For now, the previous API for this purpose will trigger
pm runtime functions, and will be left as exported symbol
for compatibility with it's only user.
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
drivers/iommu/omap-iommu.c | 29 +++--
1 file changed, 27 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index 37644c4..875e894 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -97,7 +97,7 @@ void omap_iommu_save_ctx(struct device *dev)
{
struct omap_iommu *obj = dev_to_omap_iommu(dev);
- arch_iommu-save_ctx(obj);
+ pm_runtime_put_sync(obj-dev);
}
EXPORT_SYMBOL_GPL(omap_iommu_save_ctx);
@@ -109,7 +109,7 @@ void omap_iommu_restore_ctx(struct device *dev)
{
struct omap_iommu *obj = dev_to_omap_iommu(dev);
- arch_iommu-restore_ctx(obj);
+ pm_runtime_get_sync(obj-dev);
}
EXPORT_SYMBOL_GPL(omap_iommu_restore_ctx);
@@ -1008,11 +1008,36 @@ static int __devexit omap_iommu_remove(struct
platform_device *pdev)
return 0;
}
+static int omap_iommu_runtime_suspend(struct device *dev)
+{
+ struct omap_iommu *obj = to_iommu(dev);
+
+ arch_iommu-save_ctx(obj);
+
+ return 0;
+}
+
+static int omap_iommu_runtime_resume(struct device *dev)
+{
+ struct omap_iommu *obj = to_iommu(dev);
+
+ arch_iommu-restore_ctx(obj);
+
+ return 0;
+}
+
+static const struct dev_pm_ops iommu_pm_ops = {
+ SET_RUNTIME_PM_OPS(omap_iommu_runtime_suspend,
+ omap_iommu_runtime_resume,
+ NULL)
+};
+
static struct platform_driver omap_iommu_driver = {
.probe = omap_iommu_probe,
.remove = __devexit_p(omap_iommu_remove),
.driver = {
.name = omap-iommu,
+ .pm = iommu_pm_ops,
},
};
--
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 v3 4/6] ARM: OMAP: iommu: optimize save and restore routines
These functions save and restore registers irrespectively of their
read or write permissions, this ends up in registers being saved
that can't be restored because of read only attributes. OTOH, so
far only 3 of them need to be saved.
In future GP_REG (which is present only on OMAP4 ipu) needs to be
saved but right now there is no API that can alter its value. Also,
protected TLB entries must be saved but this can be in a separate
patch as the original code didn't implement the loop to traverse
protected TLB entries.
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
arch/arm/mach-omap2/iommu2.c | 38 ++
arch/arm/plat-omap/include/plat/iommu.h | 10 +++-
arch/arm/plat-omap/include/plat/iommu2.h |2 --
drivers/iommu/omap-iommu.c |3 +--
4 files changed, 28 insertions(+), 25 deletions(-)
diff --git a/arch/arm/mach-omap2/iommu2.c b/arch/arm/mach-omap2/iommu2.c
index 3e47786..cd77abb 100644
--- a/arch/arm/mach-omap2/iommu2.c
+++ b/arch/arm/mach-omap2/iommu2.c
@@ -19,6 +19,7 @@
#include linux/stringify.h
#include plat/iommu.h
+#include plat/omap-pm.h
/*
* omap2 architecture specific register bit definitions
@@ -55,20 +56,26 @@
static void __iommu_set_twl(struct omap_iommu *obj, bool on)
{
- u32 l = iommu_read_reg(obj, MMU_CNTL);
+ u32 l;
if (on)
- iommu_write_reg(obj, MMU_IRQ_TWL_MASK, MMU_IRQENABLE);
+ l = MMU_IRQ_TWL_MASK;
else
- iommu_write_reg(obj, MMU_IRQ_TLB_MISS_MASK, MMU_IRQENABLE);
+ l = MMU_IRQ_TLB_MISS_MASK;
+
+ iommu_write_reg(obj, l, MMU_IRQENABLE);
+ obj-context.irqen = l;
+ l = iommu_read_reg(obj, MMU_CNTL);
l = ~MMU_CNTL_MASK;
+
if (on)
l |= (MMU_CNTL_MMU_EN | MMU_CNTL_TWL_EN);
else
l |= (MMU_CNTL_MMU_EN);
iommu_write_reg(obj, l, MMU_CNTL);
+ obj-context.cntl = l;
}
@@ -88,6 +95,7 @@ static int omap2_iommu_enable(struct omap_iommu *obj)
(l 4) 0xf, l 0xf);
iommu_write_reg(obj, pa, MMU_TTB);
+ obj-context.ttb = pa;
__iommu_set_twl(obj, true);
@@ -100,6 +108,7 @@ static void omap2_iommu_disable(struct omap_iommu *obj)
l = ~MMU_CNTL_MASK;
iommu_write_reg(obj, l, MMU_CNTL);
+ obj-context.cntl = l;
dev_dbg(obj-dev, %s is shutting down\n, obj-name);
}
@@ -249,28 +258,17 @@ out:
static void omap2_iommu_save_ctx(struct omap_iommu *obj)
{
- int i;
- u32 *p = obj-ctx;
-
- for (i = 0; i (MMU_REG_SIZE / sizeof(u32)); i++) {
- p[i] = iommu_read_reg(obj, i * sizeof(u32));
- dev_dbg(obj-dev, %s\t[%02d] %08x\n, __func__, i, p[i]);
- }
-
- BUG_ON(p[0] != IOMMU_ARCH_VERSION);
+ obj-ctx_loss_cnt = omap_pm_get_dev_context_loss_count(obj-dev);
}
static void omap2_iommu_restore_ctx(struct omap_iommu *obj)
{
- int i;
- u32 *p = obj-ctx;
-
- for (i = 0; i (MMU_REG_SIZE / sizeof(u32)); i++) {
- iommu_write_reg(obj, p[i], i * sizeof(u32));
- dev_dbg(obj-dev, %s\t[%02d] %08x\n, __func__, i, p[i]);
- }
+ if (omap_pm_get_dev_context_loss_count(obj-dev) == obj-ctx_loss_cnt)
+ return;
- BUG_ON(p[0] != IOMMU_ARCH_VERSION);
+ iommu_write_reg(obj, obj-context.ttb, MMU_TTB);
+ iommu_write_reg(obj, obj-context.irqen, MMU_IRQENABLE);
+ iommu_write_reg(obj, obj-context.cntl, MMU_CNTL);
}
static void omap2_cr_to_e(struct cr_regs *cr, struct iotlb_entry *e)
diff --git a/arch/arm/plat-omap/include/plat/iommu.h
b/arch/arm/plat-omap/include/plat/iommu.h
index 902d193..af14486 100644
--- a/arch/arm/plat-omap/include/plat/iommu.h
+++ b/arch/arm/plat-omap/include/plat/iommu.h
@@ -27,6 +27,13 @@ struct iotlb_entry {
};
};
+/* context registers */
+struct iommu_regs {
+ u32 irqen;
+ u32 cntl;
+ u32 ttb;
+};
+
struct omap_iommu {
const char *name;
struct module *owner;
@@ -50,7 +57,8 @@ struct omap_iommu {
struct list_headmmap;
struct mutexmmap_lock; /* protect mmap */
- void *ctx; /* iommu context: registres saved area */
+ struct iommu_regs context;
+ int ctx_loss_cnt;
u32 da_start;
u32 da_end;
};
diff --git a/arch/arm/plat-omap/include/plat/iommu2.h
b/arch/arm/plat-omap/include/plat/iommu2.h
index 1579694..bc43d41 100644
--- a/arch/arm/plat-omap/include/plat/iommu2.h
+++ b/arch/arm/plat-omap/include/plat/iommu2.h
@@ -35,8 +35,6 @@
#define MMU_READ_RAM 0x6c
#define MMU_EMU_FAULT_AD 0x70
-#define MMU_REG_SIZE 256
-
/*
* MMU Register bit definitions
*/
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index 875e894..e266ad7 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -924,14 +924,13 @@ static int __devinit
[PATCH v3 5/6] ARM: OMAP: iommu: add device tree support
Adapt driver to use DT if provided.
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
.../devicetree/bindings/arm/omap/iommu.txt | 10 +++
arch/arm/mach-omap2/omap-iommu.c |4 ++
drivers/iommu/omap-iommu.c | 65 +++-
3 files changed, 78 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/arm/omap/iommu.txt
diff --git a/Documentation/devicetree/bindings/arm/omap/iommu.txt
b/Documentation/devicetree/bindings/arm/omap/iommu.txt
new file mode 100644
index 000..2bb780f
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/omap/iommu.txt
@@ -0,0 +1,10 @@
+* MMU (Memory Management Unit)
+
+MMU present in OMAP subsystems.
+
+Required properties:
+ compatible : should be ti,omap3-iommu for OMAP3 MMUs
+ compatible : should be ti,omap4-iommu for OMAP4 MMUs
+
+Optional properties:
+ None
diff --git a/arch/arm/mach-omap2/omap-iommu.c b/arch/arm/mach-omap2/omap-iommu.c
index 82a422a..4d6145d 100644
--- a/arch/arm/mach-omap2/omap-iommu.c
+++ b/arch/arm/mach-omap2/omap-iommu.c
@@ -11,6 +11,7 @@
*/
#include linux/module.h
+#include linux/of.h
#include linux/platform_device.h
#include linux/err.h
#include linux/slab.h
@@ -29,6 +30,9 @@ static int __init omap_iommu_dev_init(struct omap_hwmod *oh,
void *unused)
struct omap_mmu_dev_attr *a = (struct omap_mmu_dev_attr *)oh-dev_attr;
static int i;
+ if (of_have_populated_dt())
+ return 0;
+
pdata = kzalloc(sizeof(*pdata), GFP_KERNEL);
if (!pdata)
return -ENOMEM;
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index e266ad7..946366f 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -21,12 +21,15 @@
#include linux/mutex.h
#include linux/spinlock.h
#include linux/pm_runtime.h
+#include linux/of.h
#include asm/cacheflush.h
#include plat/iommu.h
#include plat/iopgtable.h
+#include plat/omap_device.h
+#include plat/omap_hwmod.h
#define for_each_iotlb_cr(obj, n, __i, cr) \
for (__i = 0; \
@@ -916,13 +919,63 @@ static void omap_iommu_detach(struct omap_iommu *obj)
/*
* OMAP Device MMU(IOMMU) detection
*/
+static int __devinit
+iommu_add_platform_data_from_dt(struct platform_device *pdev)
+{
+ struct iommu_platform_data *pdata;
+ struct device_node *node = pdev-dev.of_node;
+ struct omap_hwmod *oh;
+ struct omap_mmu_dev_attr *a;
+ int ret = 0;
+
+ pdata = kzalloc(sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ return -ENOMEM;
+
+ of_property_read_string(node, ti,hwmods, pdata-name);
+ oh = omap_hwmod_lookup(pdata-name);
+ if (!oh) {
+ dev_err(pdev-dev, Cannot lookup hwmod '%s'\n, pdata-name);
+ ret = -ENODEV;
+ goto out;
+ }
+
+ a = (struct omap_mmu_dev_attr *)oh-dev_attr;
+ pdata-nr_tlb_entries = a-nr_tlb_entries;
+ pdata-da_start = a-da_start;
+ pdata-da_end = a-da_end;
+
+ if (oh-rst_lines_cnt == 1) {
+ pdata-reset_name = oh-rst_lines-name;
+ pdata-assert_reset = omap_device_assert_hardreset;
+ pdata-deassert_reset = omap_device_deassert_hardreset;
+ }
+
+ ret = platform_device_add_data(pdev, pdata, sizeof(*pdata));
+ if (ret)
+ dev_err(pdev-dev, Cannot add pdata for %s\n, pdata-name);
+
+out:
+ kfree(pdata);
+
+ return ret;
+}
+
static int __devinit omap_iommu_probe(struct platform_device *pdev)
{
int err = -ENODEV;
int irq;
struct omap_iommu *obj;
struct resource *res;
- struct iommu_platform_data *pdata = pdev-dev.platform_data;
+ struct iommu_platform_data *pdata;
+
+ if (of_have_populated_dt()) {
+ err = iommu_add_platform_data_from_dt(pdev);
+ if (err)
+ return err;
+ }
+
+ pdata = pdev-dev.platform_data;
obj = kzalloc(sizeof(*obj), GFP_KERNEL);
if (!obj)
@@ -1031,12 +1084,22 @@ static const struct dev_pm_ops iommu_pm_ops = {
NULL)
};
+#if defined(CONFIG_OF)
+static const struct of_device_id omap_iommu_of_match[] = {
+ { .compatible = ti,omap3-iommu },
+ { .compatible = ti,omap4-iommu },
+ { },
+};
+MODULE_DEVICE_TABLE(of, omap_iommu_of_match);
+#endif
+
static struct platform_driver omap_iommu_driver = {
.probe = omap_iommu_probe,
.remove = __devexit_p(omap_iommu_remove),
.driver = {
.name = omap-iommu,
.pm = iommu_pm_ops,
+ .of_match_table = of_match_ptr(omap_iommu_of_match),
},
};
--
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
[PATCH 4/6] ARM: OMAP: iommu: optimize save and restore routines
These functions save and restore registers irrespectively of their
read or write permissions, this ends up in registers being saved
that can't be restored because of read only attributes. OTOH, so
far only 3 of them need to be saved.
In future GP_REG (which is present only on OMAP4 ipu) needs to be
saved but right now there is no API that can alter its value. Also,
protected TLB entries must be saved but this can be in a separate
patch as the original code didn't implement the loop to traverse
protected TLB entries.
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
arch/arm/mach-omap2/iommu2.c | 38 ++
arch/arm/plat-omap/include/plat/iommu.h | 10 +++-
arch/arm/plat-omap/include/plat/iommu2.h |2 --
drivers/iommu/omap-iommu.c |3 +--
4 files changed, 28 insertions(+), 25 deletions(-)
diff --git a/arch/arm/mach-omap2/iommu2.c b/arch/arm/mach-omap2/iommu2.c
index 3e47786..cd77abb 100644
--- a/arch/arm/mach-omap2/iommu2.c
+++ b/arch/arm/mach-omap2/iommu2.c
@@ -19,6 +19,7 @@
#include linux/stringify.h
#include plat/iommu.h
+#include plat/omap-pm.h
/*
* omap2 architecture specific register bit definitions
@@ -55,20 +56,26 @@
static void __iommu_set_twl(struct omap_iommu *obj, bool on)
{
- u32 l = iommu_read_reg(obj, MMU_CNTL);
+ u32 l;
if (on)
- iommu_write_reg(obj, MMU_IRQ_TWL_MASK, MMU_IRQENABLE);
+ l = MMU_IRQ_TWL_MASK;
else
- iommu_write_reg(obj, MMU_IRQ_TLB_MISS_MASK, MMU_IRQENABLE);
+ l = MMU_IRQ_TLB_MISS_MASK;
+
+ iommu_write_reg(obj, l, MMU_IRQENABLE);
+ obj-context.irqen = l;
+ l = iommu_read_reg(obj, MMU_CNTL);
l = ~MMU_CNTL_MASK;
+
if (on)
l |= (MMU_CNTL_MMU_EN | MMU_CNTL_TWL_EN);
else
l |= (MMU_CNTL_MMU_EN);
iommu_write_reg(obj, l, MMU_CNTL);
+ obj-context.cntl = l;
}
@@ -88,6 +95,7 @@ static int omap2_iommu_enable(struct omap_iommu *obj)
(l 4) 0xf, l 0xf);
iommu_write_reg(obj, pa, MMU_TTB);
+ obj-context.ttb = pa;
__iommu_set_twl(obj, true);
@@ -100,6 +108,7 @@ static void omap2_iommu_disable(struct omap_iommu *obj)
l = ~MMU_CNTL_MASK;
iommu_write_reg(obj, l, MMU_CNTL);
+ obj-context.cntl = l;
dev_dbg(obj-dev, %s is shutting down\n, obj-name);
}
@@ -249,28 +258,17 @@ out:
static void omap2_iommu_save_ctx(struct omap_iommu *obj)
{
- int i;
- u32 *p = obj-ctx;
-
- for (i = 0; i (MMU_REG_SIZE / sizeof(u32)); i++) {
- p[i] = iommu_read_reg(obj, i * sizeof(u32));
- dev_dbg(obj-dev, %s\t[%02d] %08x\n, __func__, i, p[i]);
- }
-
- BUG_ON(p[0] != IOMMU_ARCH_VERSION);
+ obj-ctx_loss_cnt = omap_pm_get_dev_context_loss_count(obj-dev);
}
static void omap2_iommu_restore_ctx(struct omap_iommu *obj)
{
- int i;
- u32 *p = obj-ctx;
-
- for (i = 0; i (MMU_REG_SIZE / sizeof(u32)); i++) {
- iommu_write_reg(obj, p[i], i * sizeof(u32));
- dev_dbg(obj-dev, %s\t[%02d] %08x\n, __func__, i, p[i]);
- }
+ if (omap_pm_get_dev_context_loss_count(obj-dev) == obj-ctx_loss_cnt)
+ return;
- BUG_ON(p[0] != IOMMU_ARCH_VERSION);
+ iommu_write_reg(obj, obj-context.ttb, MMU_TTB);
+ iommu_write_reg(obj, obj-context.irqen, MMU_IRQENABLE);
+ iommu_write_reg(obj, obj-context.cntl, MMU_CNTL);
}
static void omap2_cr_to_e(struct cr_regs *cr, struct iotlb_entry *e)
diff --git a/arch/arm/plat-omap/include/plat/iommu.h
b/arch/arm/plat-omap/include/plat/iommu.h
index 902d193..af14486 100644
--- a/arch/arm/plat-omap/include/plat/iommu.h
+++ b/arch/arm/plat-omap/include/plat/iommu.h
@@ -27,6 +27,13 @@ struct iotlb_entry {
};
};
+/* context registers */
+struct iommu_regs {
+ u32 irqen;
+ u32 cntl;
+ u32 ttb;
+};
+
struct omap_iommu {
const char *name;
struct module *owner;
@@ -50,7 +57,8 @@ struct omap_iommu {
struct list_headmmap;
struct mutexmmap_lock; /* protect mmap */
- void *ctx; /* iommu context: registres saved area */
+ struct iommu_regs context;
+ int ctx_loss_cnt;
u32 da_start;
u32 da_end;
};
diff --git a/arch/arm/plat-omap/include/plat/iommu2.h
b/arch/arm/plat-omap/include/plat/iommu2.h
index 1579694..bc43d41 100644
--- a/arch/arm/plat-omap/include/plat/iommu2.h
+++ b/arch/arm/plat-omap/include/plat/iommu2.h
@@ -35,8 +35,6 @@
#define MMU_READ_RAM 0x6c
#define MMU_EMU_FAULT_AD 0x70
-#define MMU_REG_SIZE 256
-
/*
* MMU Register bit definitions
*/
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index 875e894..e266ad7 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -924,14 +924,13 @@ static int __devinit
Re: [PATCH v2 1/5] [media] omap3isp: Fix compilation error in ispreg.h
Hi Mauro, On Sunday 07 October 2012 10:17:18 Mauro Carvalho Chehab wrote: Em Tue, 2 Oct 2012 09:31:58 -0700 Tony Lindgren escreveu: * Ido Yariv i...@wizery.com [121001 15:48]: Commit c49f34bc (ARM: OMAP2+ Move SoC specific headers to be local to mach-omap2) moved omap34xx.h to mach-omap2. This broke omap3isp, as it includes omap34xx.h. Instead of moving omap34xx to platform_data, simply add the two definitions the driver needs and remove the include altogether. Signed-off-by: Ido Yariv i...@wizery.com I'm assuming that Mauro picks this one up, sorry for breaking it. Picked, thanks. With regards to the other patches in this series, IMHO, it makes more sense to go through arm omap tree, so, for the patches on this series that touch at drivers/media/platform/*: Acked-by: Mauro Carvalho Chehab mche...@redhat.com Acked-by: Tony Lindgren t...@atomide.com --- drivers/media/platform/omap3isp/ispreg.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/media/platform/omap3isp/ispreg.h b/drivers/media/platform/omap3isp/ispreg.h index 084ea77..e2c57f3 100644 --- a/drivers/media/platform/omap3isp/ispreg.h +++ b/drivers/media/platform/omap3isp/ispreg.h @@ -27,13 +27,13 @@ #ifndef OMAP3_ISP_REG_H #define OMAP3_ISP_REG_H -#include plat/omap34xx.h - - #define CM_CAM_MCLK_HZ 17280 /* Hz */ /* ISP Submodules offset */ +#define L4_34XX_BASE 0x4800 +#define OMAP3430_ISP_BASE(L4_34XX_BASE + 0xBC000) + #define OMAP3ISP_REG_BASEOMAP3430_ISP_BASE #define OMAP3ISP_REG(offset) (OMAP3ISP_REG_BASE + (offset)) I'll send a follow-up patch that removes all those definitions as they're actually not needed. -- Regards, Laurent Pinchart -- 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 6/6] arm/dts: OMAP3/4: Add iommu nodes
Add nodes for iommu DT, to interface with hwmods.
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Benoit Cousson b-cous...@ti.com
Signed-off-by: Omar Ramirez Luna omar.l...@linaro.org
---
arch/arm/boot/dts/omap3.dtsi | 12 +++-
arch/arm/boot/dts/omap4.dtsi | 17 -
2 files changed, 27 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index f38ea87..c76872e 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -37,12 +37,17 @@
};
iva {
- compatible = ti,iva2.2;
+ compatible = ti,iva2.2, simple-bus;
ti,hwmods = iva;
dsp {
compatible = ti,omap3-c64;
};
+
+ mmu_iva: mmu_iva@5d00 {
+ compatible = ti,omap3-iommu;
+ ti,hwmods = mmu_iva;
+ };
};
};
@@ -227,6 +232,11 @@
ti,hwmods = mmc3;
};
+ mmu_isp: mmu_isp@480bd400 {
+ compatible = ti,omap3-iommu;
+ ti,hwmods = mmu_isp;
+ };
+
wdt2: wdt@48314000 {
compatible = ti,omap3-wdt;
ti,hwmods = wd_timer2;
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 3883f94..f084418 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -71,8 +71,23 @@
};
dsp {
- compatible = ti,omap3-c64;
+ compatible = ti,omap3-c64, simple-bus;
ti,hwmods = dsp;
+
+ mmu_dsp: mmu_dsp@4a066000 {
+ compatible = ti,omap4-iommu;
+ ti,hwmods = mmu_dsp;
+ };
+ };
+
+ ipu {
+ compatible = ti,omap4-ipu, simple-bus;
+ ti,hwmods = ipu;
+
+ mmu_ipu: mmu_ipu@55082000 {
+ compatible = ti,omap4-iommu;
+ ti,hwmods = mmu_ipu;
+ };
};
iva {
--
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
