Re: [PATCH v2 0/2] ARM: OMAP4: Fix gpmc_fck clock
On 02/25/2014 07:26 AM, Mike Turquette wrote: Quoting Florian Vaussard (2014-02-23 21:44:25) On 02/23/2014 10:23 PM, Mike Turquette wrote: Quoting Florian Vaussard (2014-02-19 11:26:43) On 02/19/2014 05:22 PM, Tero Kristo wrote: On 02/19/2014 11:15 AM, Florian Vaussard wrote: Hello, Trying to get my SMSC9221 working on OMAP4 with DT, I faced a misconfigured gpmc_fck (dummy clock set to 0) resulting in serveral division-by-zero, misconfigured timings and driver lost in the La La Land. To solve this, patch 1 removes gpmc_fck from the dummy clocks, and patch 2 adds the gpmc_fck DT node and reference it from the gpmc node. Tested on DuoVero/Parlor (OMAP4430) with SMSC9221. I can't test GPMC myself, but other than that, this set looks good to go. Thank you. Would you like more test coverage by other people? I would like to see this in -rc if possible, as it is needed to boot my OMAP4 system. What OMAP4 system is this? Is this a regression for board that already has support merged into mainline? No, it is not yet merged into mainline. I was planning to post the DTS this week, when most issues are cleared. Looking at the current mainline boards, no one seems to use the GPMC, so I am just the first one to hit this issue. OK, well typically the later -rc's are for fixing observed regressions. Since your platform is not yet merged in then it's probably fine to push this for 3.15. Fair enough. 3.15 is fine. This also gives time to test the fix for other OMAP-ish processors. I can do the v3, including OMAP5 and DRA7. But for DRA7, I will need someone with the TRM telling me where is connected gpmc_fclk (Suman?). BTW, your mail client seems to have corrupted the To: header, double quotes are missing between Tero, Benoît and Tony's addresses, mixing them as the same person. Maybe an indigestion caused by the UTF8 character of Benoît? Regards, Florian -- 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/2] clk: ti: am335x: remove unecessary cpu0 clk node
Quoting Nishanth Menon (2014-01-29 10:19:16)
cpu0 clock node has no functionality, since cpufreq-cpu0 is already
capable of picking up the clock from dts.
Signed-off-by: Nishanth Menon n...@ti.com
Taken into clk-next!
Regards,
Mike
---
drivers/clk/ti/clk-33xx.c |1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/clk/ti/clk-33xx.c b/drivers/clk/ti/clk-33xx.c
index 776ee45..028b337 100644
--- a/drivers/clk/ti/clk-33xx.c
+++ b/drivers/clk/ti/clk-33xx.c
@@ -34,7 +34,6 @@ static struct ti_dt_clk am33xx_clks[] = {
DT_CLK(NULL, dpll_core_m5_ck, dpll_core_m5_ck),
DT_CLK(NULL, dpll_core_m6_ck, dpll_core_m6_ck),
DT_CLK(NULL, dpll_mpu_ck, dpll_mpu_ck),
- DT_CLK(cpu0, NULL, dpll_mpu_ck),
DT_CLK(NULL, dpll_mpu_m2_ck, dpll_mpu_m2_ck),
DT_CLK(NULL, dpll_ddr_ck, dpll_ddr_ck),
DT_CLK(NULL, dpll_ddr_m2_ck, dpll_ddr_m2_ck),
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 06/14] CLK: TI: OMAP3: Get rid of unused USB Host dummy clocks
Quoting Roger Quadros (2014-02-20 03:40:01)
The OMAP USB Host MFD driver no longer expects these non-existing
clocks from the OMAP3 platform, so get rid of them.
Looks good to me.
Regards,
Mike
CC: Tero Kristo t-kri...@ti.com
CC: Mike Turquette mturque...@linaro.org
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/cclock3xxx_data.c | 4
drivers/clk/ti/clk-3xxx.c | 4
2 files changed, 8 deletions(-)
diff --git a/arch/arm/mach-omap2/cclock3xxx_data.c
b/arch/arm/mach-omap2/cclock3xxx_data.c
index 3b05aea..4299a55 100644
--- a/arch/arm/mach-omap2/cclock3xxx_data.c
+++ b/arch/arm/mach-omap2/cclock3xxx_data.c
@@ -3495,10 +3495,6 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL, dss_tv_fck, dss_tv_fck),
CLK(NULL, dss_96m_fck, dss_96m_fck),
CLK(NULL, dss2_alwon_fck, dss2_alwon_fck),
- CLK(NULL, utmi_p1_gfclk,dummy_ck),
- CLK(NULL, utmi_p2_gfclk,dummy_ck),
- CLK(NULL, xclk60mhsp1_ck, dummy_ck),
- CLK(NULL, xclk60mhsp2_ck, dummy_ck),
CLK(NULL, init_60m_fclk,dummy_ck),
CLK(NULL, gpt1_fck, gpt1_fck),
CLK(NULL, aes2_ick, aes2_ick),
diff --git a/drivers/clk/ti/clk-3xxx.c b/drivers/clk/ti/clk-3xxx.c
index d323023..0d1750a 100644
--- a/drivers/clk/ti/clk-3xxx.c
+++ b/drivers/clk/ti/clk-3xxx.c
@@ -130,10 +130,6 @@ static struct ti_dt_clk omap3xxx_clks[] = {
DT_CLK(NULL, dss_tv_fck, dss_tv_fck),
DT_CLK(NULL, dss_96m_fck, dss_96m_fck),
DT_CLK(NULL, dss2_alwon_fck, dss2_alwon_fck),
- DT_CLK(NULL, utmi_p1_gfclk, dummy_ck),
- DT_CLK(NULL, utmi_p2_gfclk, dummy_ck),
- DT_CLK(NULL, xclk60mhsp1_ck, dummy_ck),
- DT_CLK(NULL, xclk60mhsp2_ck, dummy_ck),
DT_CLK(NULL, init_60m_fclk, dummy_ck),
DT_CLK(NULL, gpt1_fck, gpt1_fck),
DT_CLK(NULL, aes2_ick, aes2_ick),
--
1.8.3.2
--
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 v8 03/14] mfd: omap-usb-host: Use clock names as per function for reference clocks
Use a meaningful name for the reference clocks so that it indicates the
function.
CC: Lee Jones lee.jo...@linaro.org
CC: Samuel Ortiz sa...@linux.intel.com
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/mfd/omap-usb-host.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 865c276..651e249 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -718,24 +718,24 @@ static int usbhs_omap_probe(struct platform_device
*pdev)
goto err_mem;
}
- omap-xclk60mhsp1_ck = devm_clk_get(dev, xclk60mhsp1_ck);
+ omap-xclk60mhsp1_ck = devm_clk_get(dev, refclk_60m_ext_p1);
if (IS_ERR(omap-xclk60mhsp1_ck)) {
ret = PTR_ERR(omap-xclk60mhsp1_ck);
- dev_err(dev, xclk60mhsp1_ck failed error:%d\n, ret);
+ dev_err(dev, refclk_60m_ext_p1 failed error:%d\n, ret);
goto err_mem;
}
Will anything break if I were to apply the MFD patches seperately?
- omap-xclk60mhsp2_ck = devm_clk_get(dev, xclk60mhsp2_ck);
+ omap-xclk60mhsp2_ck = devm_clk_get(dev, refclk_60m_ext_p2);
if (IS_ERR(omap-xclk60mhsp2_ck)) {
ret = PTR_ERR(omap-xclk60mhsp2_ck);
- dev_err(dev, xclk60mhsp2_ck failed error:%d\n, ret);
+ dev_err(dev, refclk_60m_ext_p2 failed error:%d\n, ret);
goto err_mem;
}
- omap-init_60m_fclk = devm_clk_get(dev, init_60m_fclk);
+ omap-init_60m_fclk = devm_clk_get(dev, refclk_60m_int);
if (IS_ERR(omap-init_60m_fclk)) {
ret = PTR_ERR(omap-init_60m_fclk);
- dev_err(dev, init_60m_fclk failed error:%d\n, ret);
+ dev_err(dev, refclk_60m_int failed error:%d\n, ret);
goto err_mem;
}
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 v8 03/14] mfd: omap-usb-host: Use clock names as per function for reference clocks
Hi,
On 02/25/2014 10:52 AM, Lee Jones wrote:
Use a meaningful name for the reference clocks so that it indicates the
function.
CC: Lee Jones lee.jo...@linaro.org
CC: Samuel Ortiz sa...@linux.intel.com
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/mfd/omap-usb-host.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 865c276..651e249 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -718,24 +718,24 @@ static int usbhs_omap_probe(struct platform_device
*pdev)
goto err_mem;
}
-omap-xclk60mhsp1_ck = devm_clk_get(dev, xclk60mhsp1_ck);
+omap-xclk60mhsp1_ck = devm_clk_get(dev, refclk_60m_ext_p1);
if (IS_ERR(omap-xclk60mhsp1_ck)) {
ret = PTR_ERR(omap-xclk60mhsp1_ck);
-dev_err(dev, xclk60mhsp1_ck failed error:%d\n, ret);
+dev_err(dev, refclk_60m_ext_p1 failed error:%d\n, ret);
goto err_mem;
}
Will anything break if I were to apply the MFD patches seperately?
Nothing will break for OMAP3, but OMAP4 USB host will break (e.g. Panda board).
OMAP5 USB host was never working so it doesn't matter there.
To make sure nothing breaks, we need at least these 2 patches to go in together
with mfd changes.
[PATCH v8 08/14] ARM: dts: omap4: Update omap-usb-host node
[PATCH v8 09/14] ARM: dts: omap5: Update omap-usb-host node
Any suggestions about how we can proceed?
cheers,
-roger
-omap-xclk60mhsp2_ck = devm_clk_get(dev, xclk60mhsp2_ck);
+omap-xclk60mhsp2_ck = devm_clk_get(dev, refclk_60m_ext_p2);
if (IS_ERR(omap-xclk60mhsp2_ck)) {
ret = PTR_ERR(omap-xclk60mhsp2_ck);
-dev_err(dev, xclk60mhsp2_ck failed error:%d\n, ret);
+dev_err(dev, refclk_60m_ext_p2 failed error:%d\n, ret);
goto err_mem;
}
-omap-init_60m_fclk = devm_clk_get(dev, init_60m_fclk);
+omap-init_60m_fclk = devm_clk_get(dev, refclk_60m_int);
if (IS_ERR(omap-init_60m_fclk)) {
ret = PTR_ERR(omap-init_60m_fclk);
-dev_err(dev, init_60m_fclk failed error:%d\n, ret);
+dev_err(dev, refclk_60m_int failed error:%d\n, ret);
goto err_mem;
}
--
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 v8 03/14] mfd: omap-usb-host: Use clock names as per function for reference clocks
Use a meaningful name for the reference clocks so that it indicates the
function.
CC: Lee Jones lee.jo...@linaro.org
CC: Samuel Ortiz sa...@linux.intel.com
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/mfd/omap-usb-host.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 865c276..651e249 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -718,24 +718,24 @@ static int usbhs_omap_probe(struct platform_device
*pdev)
goto err_mem;
}
- omap-xclk60mhsp1_ck = devm_clk_get(dev, xclk60mhsp1_ck);
+ omap-xclk60mhsp1_ck = devm_clk_get(dev, refclk_60m_ext_p1);
if (IS_ERR(omap-xclk60mhsp1_ck)) {
ret = PTR_ERR(omap-xclk60mhsp1_ck);
- dev_err(dev, xclk60mhsp1_ck failed error:%d\n, ret);
+ dev_err(dev, refclk_60m_ext_p1 failed error:%d\n, ret);
goto err_mem;
}
Will anything break if I were to apply the MFD patches seperately?
Nothing will break for OMAP3, but OMAP4 USB host will break (e.g. Panda
board).
OMAP5 USB host was never working so it doesn't matter there.
To make sure nothing breaks, we need at least these 2 patches to go in
together with mfd changes.
[PATCH v8 08/14] ARM: dts: omap4: Update omap-usb-host node
[PATCH v8 09/14] ARM: dts: omap5: Update omap-usb-host node
Any suggestions about how we can proceed?
Yes, unfortunately you have to squash each of the patches into one
patch. Applying a patch which breaks a build, then applying another one
immediately after which subsequently fixes the break is not an acceptable
way of working I'm afraid. What would happen if we were to fall into
the middle of the two patches when bisecting?
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 v8 03/14] mfd: omap-usb-host: Use clock names as per function for reference clocks
On 02/25/2014 11:18 AM, Lee Jones wrote:
Use a meaningful name for the reference clocks so that it indicates the
function.
CC: Lee Jones lee.jo...@linaro.org
CC: Samuel Ortiz sa...@linux.intel.com
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/mfd/omap-usb-host.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 865c276..651e249 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -718,24 +718,24 @@ static int usbhs_omap_probe(struct platform_device
*pdev)
goto err_mem;
}
- omap-xclk60mhsp1_ck = devm_clk_get(dev, xclk60mhsp1_ck);
+ omap-xclk60mhsp1_ck = devm_clk_get(dev, refclk_60m_ext_p1);
if (IS_ERR(omap-xclk60mhsp1_ck)) {
ret = PTR_ERR(omap-xclk60mhsp1_ck);
- dev_err(dev, xclk60mhsp1_ck failed error:%d\n, ret);
+ dev_err(dev, refclk_60m_ext_p1 failed error:%d\n, ret);
goto err_mem;
}
Will anything break if I were to apply the MFD patches seperately?
Nothing will break for OMAP3, but OMAP4 USB host will break (e.g. Panda
board).
OMAP5 USB host was never working so it doesn't matter there.
To make sure nothing breaks, we need at least these 2 patches to go in
together with mfd changes.
[PATCH v8 08/14] ARM: dts: omap4: Update omap-usb-host node
[PATCH v8 09/14] ARM: dts: omap5: Update omap-usb-host node
Any suggestions about how we can proceed?
Yes, unfortunately you have to squash each of the patches into one
patch. Applying a patch which breaks a build, then applying another one
immediately after which subsequently fixes the break is not an acceptable
way of working I'm afraid. What would happen if we were to fall into
the middle of the two patches when bisecting?
OK, I'll squash patches 8 and 9 into patch 3.
cheers,
-roger
--
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 v8 06/14] CLK: TI: OMAP3: Get rid of unused USB Host dummy clocks
Hi Mike,
On 02/25/2014 10:43 AM, Mike Turquette wrote:
Quoting Roger Quadros (2014-02-20 03:40:01)
The OMAP USB Host MFD driver no longer expects these non-existing
clocks from the OMAP3 platform, so get rid of them.
Looks good to me.
Is it OK if I squash this patch with [1] and take it through the MFD tree?
Keeping them separate could break functionality if both don't go in together.
[1] - http://article.gmane.org/gmane.linux.ports.arm.kernel/303266
cheers,
-roger
CC: Tero Kristo t-kri...@ti.com
CC: Mike Turquette mturque...@linaro.org
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/cclock3xxx_data.c | 4
drivers/clk/ti/clk-3xxx.c | 4
2 files changed, 8 deletions(-)
diff --git a/arch/arm/mach-omap2/cclock3xxx_data.c
b/arch/arm/mach-omap2/cclock3xxx_data.c
index 3b05aea..4299a55 100644
--- a/arch/arm/mach-omap2/cclock3xxx_data.c
+++ b/arch/arm/mach-omap2/cclock3xxx_data.c
@@ -3495,10 +3495,6 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL, dss_tv_fck, dss_tv_fck),
CLK(NULL, dss_96m_fck, dss_96m_fck),
CLK(NULL, dss2_alwon_fck, dss2_alwon_fck),
- CLK(NULL, utmi_p1_gfclk,dummy_ck),
- CLK(NULL, utmi_p2_gfclk,dummy_ck),
- CLK(NULL, xclk60mhsp1_ck, dummy_ck),
- CLK(NULL, xclk60mhsp2_ck, dummy_ck),
CLK(NULL, init_60m_fclk,dummy_ck),
CLK(NULL, gpt1_fck, gpt1_fck),
CLK(NULL, aes2_ick, aes2_ick),
diff --git a/drivers/clk/ti/clk-3xxx.c b/drivers/clk/ti/clk-3xxx.c
index d323023..0d1750a 100644
--- a/drivers/clk/ti/clk-3xxx.c
+++ b/drivers/clk/ti/clk-3xxx.c
@@ -130,10 +130,6 @@ static struct ti_dt_clk omap3xxx_clks[] = {
DT_CLK(NULL, dss_tv_fck, dss_tv_fck),
DT_CLK(NULL, dss_96m_fck, dss_96m_fck),
DT_CLK(NULL, dss2_alwon_fck, dss2_alwon_fck),
- DT_CLK(NULL, utmi_p1_gfclk, dummy_ck),
- DT_CLK(NULL, utmi_p2_gfclk, dummy_ck),
- DT_CLK(NULL, xclk60mhsp1_ck, dummy_ck),
- DT_CLK(NULL, xclk60mhsp2_ck, dummy_ck),
DT_CLK(NULL, init_60m_fclk, dummy_ck),
DT_CLK(NULL, gpt1_fck, gpt1_fck),
DT_CLK(NULL, aes2_ick, aes2_ick),
--
1.8.3.2
--
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 v8 01/14] mfd: omap-usb-host: Get clocks based on hardware revision
On 02/25/2014 11:37 AM, Lee Jones wrote: Not all revisions have all the clocks so get the necessary clocks based on hardware revision. This should avoid un-necessary clk_get failure messages that were observed earlier. CC: Lee Jones lee.jo...@linaro.org CC: Samuel Ortiz sa...@linux.intel.com Signed-off-by: Roger Quadros rog...@ti.com --- drivers/mfd/omap-usb-host.c | 43 --- 1 file changed, 32 insertions(+), 11 deletions(-) What about patches 1 and 2. Are these safe to go in alone? patch 6 must not go in without 1. I've just asked Mike if we can squash it into 1. patch 2 can go alone. cheers, -roger -- 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 v8 01/14] mfd: omap-usb-host: Get clocks based on hardware revision
Not all revisions have all the clocks so get the necessary clocks based on hardware revision. This should avoid un-necessary clk_get failure messages that were observed earlier. CC: Lee Jones lee.jo...@linaro.org CC: Samuel Ortiz sa...@linux.intel.com Signed-off-by: Roger Quadros rog...@ti.com --- drivers/mfd/omap-usb-host.c | 43 --- 1 file changed, 32 insertions(+), 11 deletions(-) What about patches 1 and 2. Are these safe to go in alone? -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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 v8 02/14] mfd: omap-usb-host: Always fail on clk_get() error
Be more strict and always fail on clk_get() error. For OMAP3 platforms, get the 120MHz EHCI clock by its proper name 'usbhost_120m_fck' instead of its alias 'ehci_logic_fck'. CC: Lee Jones lee.jo...@linaro.org CC: Samuel Ortiz sa...@linux.intel.com Signed-off-by: Roger Quadros rog...@ti.com --- drivers/mfd/omap-usb-host.c | 65 + 1 file changed, 42 insertions(+), 23 deletions(-) Appied, thanks. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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 v8 02/14] mfd: omap-usb-host: Always fail on clk_get() error
On Tue, 25 Feb 2014, Lee Jones wrote: Be more strict and always fail on clk_get() error. For OMAP3 platforms, get the 120MHz EHCI clock by its proper name 'usbhost_120m_fck' instead of its alias 'ehci_logic_fck'. CC: Lee Jones lee.jo...@linaro.org CC: Samuel Ortiz sa...@linux.intel.com Signed-off-by: Roger Quadros rog...@ti.com --- drivers/mfd/omap-usb-host.c | 65 + 1 file changed, 42 insertions(+), 23 deletions(-) Appied, thanks. Won't apply. I guess this depends on the changes made in patch 1. I'll wait for the next drop. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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
TWL6040 fails to initialize
Hi Peter, I got recently to work on the DT support for an OMAP4 board [1], and I encountered some troubles with the probe of the twl6040 audio codec on 3.14-rc kernels. On 3.13, things were working correctly. So I somewhat managed to bisect this down to [c7f9129 mfd: twl6040: reg_defaults support for regmap]. But looking more into it, things are less obvious. When the init fails, here is what happens: [2.455749] twl6040 0-004b: Looking up vio-supply from device tree [2.456359] twl6040 0-004b: Looking up v2v1-supply from device tree [2.457061] twl6040 0-004b: Failed to set masks in 0x4: -121 [2.463043] twl6040: probe of 0-004b failed with error -121 logically resulting in [2.770050] omap-abe-twl6040 sound.4: ASoC: CODEC twl6040-codec not registered [2.70] omap-abe-twl6040 sound.4: snd_soc_register_card() failed: -517 [2.785095] platform sound.4: Driver omap-abe-twl6040 requests probe deferral We get a EREMOTEIO when calling regmap_add_irq_chip() from twl6040_probe(). regmap_add_irq_chip() will try to perform non-cached i2c writes, where the omap-i2c driver get a NACK from the remote chip. Strange enough, the non-cached read just before (i.e. twl6040_reg_read(twl6040, TWL6040_REG_ASICREV)) succeeds. After some fiddling around, I could find that delaying the call to regmap_add_irq_chip(), let's say by msleep(1), will solve the problem. As the TRM for TWL6040 is not public, and I cannot physically access the i2c bus on the board, I ran out of hypothesis. I first suspected a concurrent access from the McPDM bus, but the mcpdm driver does not seem to perform command (write) access. As the regulators are enabled just before, could it be the twl6040 IP which is not yet initialized, and NACK'ing writes but not reads? The commit c7f9129 changed the regmap logic by reducing the number of non-cached accesses, and thus changed the access timings, so it may have trigged this behaviour. But this is pure supposition, as I cannot hack the i2c bus :( And adding any kind of tracing before regmap_add_irq_chip() usually delays enough to make the probe succeeds. Any ideas? Regards, Florian [1] http://thread.gmane.org/gmane.linux.ports.arm.omap/110801 -- 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] power_supply: bq24261 charger driver
On Fri, Feb 21, 2014 at 03:44:00PM +0100, Pavel Machek wrote:
Hi!
+static inline int bq24261_set_cv(struct bq24261_charger *chip, int cv)
+{
+ int bat_volt;
+ int ret;
+ u8 reg_val;
+ u8 vindpm_val = 0x0;
+
+ /*
+ * Setting VINDPM value as per the battery voltage
+ * VBatt Vindpm Register Setting
+ * 3.7v 4.2v 0x0 (default)
+ * 3.71v - 3.96v4.36v 0x2
+ * 3.96v 4.6v 0x5
+ */
+ ret = get_battery_voltage(bat_volt);
+ if (ret) {
+ dev_err(chip-client-dev,
+ Error getting battery voltage!!\n);
+ } else {
You forget the error value and continue anyway.
On error, throw the error and program default VINDPM value.
Is it good idea to attempt charging when we can't read battery
voltage?
This function decides the VINDPM setting and doesn't enable charging.
VINDPM setting is used to ensure minimum input voltage and thereby allow to
charge with low power charging source. If the voltage read fails, then the
default VINDPM value 0x0 will be programmed and the input voltage may go down
as low as 4.2V. The charging/not charging decision is taken by power supply
charger driver and not by the chip driver. The worst case impact would be that
charging may happen with a low charge current at high battery voltages,
but doesn't compromise safety at all.
-Jenny
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/2] Introduce omap-des driver for OMAP SoCs
On Fri, Feb 14, 2014 at 10:48:41AM -0600, Joel Fernandes wrote: Here are revised patches for omap-des driver addressing review comments at: https://lkml.org/lkml/2013/8/30/116 Joel Fernandes (2): crypto: omap-des: Add omap-des driver for OMAP4/AM43xx crypto: omap-des: Add config and build options Both patches applied. Thanks! -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.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: Ideas/suggestions to avoid repeated locking and reducing too many lists with dmaengine?
On Mon, Feb 24, 2014 at 02:50:28PM -0600, Andy Gross wrote: On Mon, Feb 24, 2014 at 01:03:32PM -0600, Joel Fernandes wrote: Hi folks, Just wanted your thoughts/suggestions on how we can avoid overhead in the EDMA dmaengine driver. I am seeing a lots of performance drop specially for small transfers with EDMA versus before raw EDMA was moved to DMAEngine framework (atleast 25%). I've seen roughly the same drop in my testing. In my case it had to do with the nature of how work is done using virt-dma. The virt-dma is predicated on only letting one transaction be active at a time and it increases the latency for getting the next transaction off. For large transactions, it's negligible. But for small transactions, it is pretty evident. Wrong. virt-dma allows you to fire off the next transaction in the queue immediately that the previous transaction has finished. I know this, because sa11x0-dma does exactly that. You don't need to wait for the tasklet to be called before starting the next transaction. -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it. -- 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: Ideas/suggestions to avoid repeated locking and reducing too many lists with dmaengine?
On Mon, Feb 24, 2014 at 04:38:48PM -0600, Joel Fernandes wrote: Actually I did do some tracing earlier before I posted this thread- and notice there was excessive traces of locking/unlocking. It is very light though as you pointed and lighter without debug options. The only other notable difference is the fact that we are now going through the dmaengine framework in the newer kernel vs the faster one. Okay, for OMAP, there's additional latency caused by the tasklet which starts a transaction when there's no previous transaction running - that will be your biggest problem. I do want to move omap-dma away from having a fixed binding between claimed channels and the logical channels since that's too wasteful, and that's what the tasklet will eventually be doing - but with omap-dma being divorsed from the old code, this tasklet may not be necessary anymore (since we no longer have to operate in process context for that bit.) There's a huge pile of patches I have queued up for the next merge window in linux-next - I'd rather get these into mainline before trying to do any restructuring, otherwise we're going to get into a hell of a problem with merge conflicts. -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it. -- 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/2] ARM: dts: duovero-parlor: Add HDMI output
On Mon, Feb 24, 2014 at 05:22:27PM -0300, Javier Martinez Canillas wrote:
Hi Russell,
On Mon, Feb 24, 2014 at 3:03 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Mon, Feb 24, 2014 at 06:07:49PM +0100, Florian Vaussard wrote:
+ hdmi0: connector@0 {
+ compatible = hdmi-connector;
This looks way to generic a compatible string. Are you sure it's
correct?
That compatible string is correct according to the latest series
posted by Tomi Valkeinen to add DT bindings for the OMAP Display
SubSystem (DSS) [0].
in which case:
NN AA K K
NN N A A CC K K
N N N AA C KK
N N N AA C KK
N NN AA CC K K
NN AA K K
Yes, that's a very big nack. Two things:
1. OMAP really doesn't have the right to define a compatible string which
is as generic as hdmi-connector.
2. Even with omapdss, before it, the convention that DT people have adopted
is for the prefix to be companyname, and not a subsystem.
I'm not the only one with this concern - I discussed it with Arnd last
night and his comments were about it being obviously bogus.
The property is added on this patch [1] and as far as I understood the
idea is that it could be a generic DT binding that can be used by
platform specific HDMI connectors like the omap dss HDMI connector [2].
Why do the physical connectors need a DT binding? Surely what needs the
DT binding is the HDMI encoder - and that certainly should no way be a
generic name, because there's no such thing as a generic HDMI encoder
chip.
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
--
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 v7 0/4] mmc: omap_hsmmc: SDIO IRQ.
v7 - rebase on 3.14.0-rc3-49726-g77e15ec - split omap_hsmmc_pin_init due to regression on omap-3730 platform @tony pls try if it still works after applying patch 2? v6 - rebase on Linux 3.13-rc3 - reformatting debugfs v5 - fix compile error introduced by last minute one line fix v4: - switch to interrupts-extended format - drop ti,swakeup-missing flag convert to comaptible section v3: - removed gpio_irq from platform_data v2: - incorparated changes as suggested by reviewers - simplified workaround for am335x, gpio will now only wake the module from runtime suspend, not handle the sdio irq itself Andreas Fenkart (4): mmc: omap_hsmmc: Enable SDIO IRQ. mmc: omap_hsmmc: Remux SDIO pins within driver. mmc: omap_hsmmc: Pin remux workaround to support SDIO interrupt on AM335x. mmc: omap_hsmmc: Extend debugfs for SDIO IRQ, GPIO and pinmux. .../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 50 drivers/mmc/host/omap_hsmmc.c | 315 ++-- include/linux/platform_data/mmc-omap.h |1 + 3 files changed, 341 insertions(+), 25 deletions(-) -- 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 v7 1/4] mmc: omap_hsmmc: Enable SDIO IRQ.
For now, only support SDIO interrupt if we are booted with
DT. This is because some platforms need special quirks. And
we don't want to add new legacy mux platform init code
callbacks any longer as we are moving to DT based booting
anyways.
Signed-off-by: Andreas Fenkart afenk...@gmail.com
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index a5a38cc..bd3bb0c 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -131,6 +131,7 @@ static void apply_clk_hack(struct device *dev)
#define TC_EN (1 1)
#define BWR_EN (1 4)
#define BRR_EN (1 5)
+#define CIRQ_EN(1 8)
#define ERR_EN (1 15)
#define CTO_EN (1 16)
#define CCRC_EN(1 17)
@@ -215,6 +216,9 @@ struct omap_hsmmc_host {
int reqs_blocked;
int use_reg;
int req_in_progress;
+ int flags;
+#define HSMMC_SDIO_IRQ_ENABLED (1 0)/* SDIO irq enabled */
+
struct omap_hsmmc_next next_data;
struct omap_mmc_platform_data *pdata;
};
@@ -495,27 +499,40 @@ static void omap_hsmmc_stop_clock(struct omap_hsmmc_host
*host)
static void omap_hsmmc_enable_irq(struct omap_hsmmc_host *host,
struct mmc_command *cmd)
{
- unsigned int irq_mask;
+ u32 irq_mask = INT_EN_MASK;
+ unsigned long flags;
if (host-use_dma)
- irq_mask = INT_EN_MASK ~(BRR_EN | BWR_EN);
- else
- irq_mask = INT_EN_MASK;
+ irq_mask = ~(BRR_EN | BWR_EN);
/* Disable timeout for erases */
if (cmd-opcode == MMC_ERASE)
irq_mask = ~DTO_EN;
+ spin_lock_irqsave(host-irq_lock, flags);
OMAP_HSMMC_WRITE(host-base, STAT, STAT_CLEAR);
OMAP_HSMMC_WRITE(host-base, ISE, irq_mask);
+
+ /* latch pending CIRQ, but don't signal */
+ if (host-flags HSMMC_SDIO_IRQ_ENABLED)
+ irq_mask |= CIRQ_EN;
OMAP_HSMMC_WRITE(host-base, IE, irq_mask);
+ spin_unlock_irqrestore(host-irq_lock, flags);
}
static void omap_hsmmc_disable_irq(struct omap_hsmmc_host *host)
{
- OMAP_HSMMC_WRITE(host-base, ISE, 0);
- OMAP_HSMMC_WRITE(host-base, IE, 0);
+ u32 irq_mask = 0;
+ unsigned long flags;
+
+ spin_lock_irqsave(host-irq_lock, flags);
+ /* no transfer running, need to signal cirq if enabled */
+ if (host-flags HSMMC_SDIO_IRQ_ENABLED)
+ irq_mask |= CIRQ_EN;
+ OMAP_HSMMC_WRITE(host-base, ISE, irq_mask);
+ OMAP_HSMMC_WRITE(host-base, IE, irq_mask);
OMAP_HSMMC_WRITE(host-base, STAT, STAT_CLEAR);
+ spin_unlock_irqrestore(host-irq_lock, flags);
}
/* Calculate divisor for the given clock frequency */
@@ -1078,8 +1095,12 @@ static irqreturn_t omap_hsmmc_irq(int irq, void *dev_id)
int status;
status = OMAP_HSMMC_READ(host-base, STAT);
- while (status INT_EN_MASK host-req_in_progress) {
- omap_hsmmc_do_irq(host, status);
+ while (status (INT_EN_MASK | CIRQ_EN)) {
+ if (host-req_in_progress)
+ omap_hsmmc_do_irq(host, status);
+
+ if (status CIRQ_EN)
+ mmc_signal_sdio_irq(host-mmc);
/* Flush posted write */
status = OMAP_HSMMC_READ(host-base, STAT);
@@ -1591,6 +1612,37 @@ static void omap_hsmmc_init_card(struct mmc_host *mmc,
struct mmc_card *card)
mmc_slot(host).init_card(card);
}
+static void omap_hsmmc_enable_sdio_irq(struct mmc_host *mmc, int enable)
+{
+ struct omap_hsmmc_host *host = mmc_priv(mmc);
+ u32 irq_mask;
+ unsigned long flags;
+
+ spin_lock_irqsave(host-irq_lock, flags);
+
+ irq_mask = OMAP_HSMMC_READ(host-base, ISE);
+ if (enable) {
+ host-flags |= HSMMC_SDIO_IRQ_ENABLED;
+ irq_mask |= CIRQ_EN;
+ } else {
+ host-flags = ~HSMMC_SDIO_IRQ_ENABLED;
+ irq_mask = ~CIRQ_EN;
+ }
+ OMAP_HSMMC_WRITE(host-base, IE, irq_mask);
+
+ /*
+* if enable, piggy back detection on current request
+* but always disable immediately
+*/
+ if (!host-req_in_progress || !enable)
+ OMAP_HSMMC_WRITE(host-base, ISE, irq_mask);
+
+ /* flush posted write */
+ OMAP_HSMMC_READ(host-base, IE);
+
+ spin_unlock_irqrestore(host-irq_lock, flags);
+}
+
static void omap_hsmmc_conf_bus_power(struct omap_hsmmc_host *host)
{
u32 hctl, capa, value;
@@ -1643,7 +1695,7 @@ static const struct mmc_host_ops omap_hsmmc_ops = {
.get_cd = omap_hsmmc_get_cd,
.get_ro = omap_hsmmc_get_ro,
.init_card = omap_hsmmc_init_card,
- /* NYET -- enable_sdio_irq */
+ .enable_sdio_irq =
[PATCH v7 2/4] mmc: omap_hsmmc: Remux SDIO pins within driver.
This is a preparation for the am335x workaround where we reconfigure
dat1 as GPIO before going to suspend. If you don't specify active/idle
pinctrl there should be no change.
Idea of remuxing the pins by Tony Lindgren as well as the intial
implementation of omap_hsmmc_pin_init. All bugs are mine.
Signed-off-by: Andreas Fenkart afenk...@gmail.com
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index bd3bb0c..5e60925 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -220,6 +220,8 @@ struct omap_hsmmc_host {
#define HSMMC_SDIO_IRQ_ENABLED (1 0)/* SDIO irq enabled */
struct omap_hsmmc_next next_data;
+ struct pinctrl *pinctrl;
+ struct pinctrl_state*fixed, *active, *idle;
struct omap_mmc_platform_data *pdata;
};
@@ -476,6 +478,70 @@ static void omap_hsmmc_gpio_free(struct
omap_mmc_platform_data *pdata)
gpio_free(pdata-slots[0].switch_pin);
}
+static int omap_hsmmc_pin_init(struct omap_hsmmc_host *host)
+{
+ struct pinctrl *_pinctrl;
+ int ret;
+
+ _pinctrl = devm_pinctrl_get(host-dev);
+ if (IS_ERR(_pinctrl)) {
+ /* okay, if the bootloader set it up right */
+ dev_warn(host-dev, no pinctrl handle\n);
+ return 0;
+ }
+
+ host-fixed = pinctrl_lookup_state(_pinctrl,
+ PINCTRL_STATE_DEFAULT);
+ if (IS_ERR(host-fixed)) {
+ dev_info(host-dev,
+pins are not configured from the driver\n);
+ host-fixed = NULL;
+ devm_pinctrl_put(_pinctrl);
+ return 0;
+ }
+
+ ret = pinctrl_select_state(_pinctrl, host-fixed);
+ if (ret 0) {
+ dev_warn(host-dev, select fixed pinctrl state failed %d\n,
ret);
+ goto err;
+ }
+
+ /* For most cases we don't have wake-ups, and exit after this */
+ host-active = pinctrl_lookup_state(_pinctrl, active);
+ if (IS_ERR(host-active)) {
+ ret = PTR_ERR(host-active);
+ host-active = NULL;
+ goto done;
+ }
+
+ host-idle = pinctrl_lookup_state(_pinctrl, PINCTRL_STATE_IDLE);
+ if (IS_ERR(host-idle)) {
+ ret = PTR_ERR(host-idle);
+ host-idle = NULL;
+ goto err;
+ }
+
+ /* Let's make sure the active and idle states work */
+ ret = pinctrl_select_state(_pinctrl, host-idle);
+ if (ret 0)
+ goto err;
+
+ ret = pinctrl_select_state(_pinctrl, host-active);
+ if (ret 0)
+ goto err;
+
+ dev_info(mmc_dev(host-mmc), pins configured for wake-up events\n);
+
+done:
+ host-pinctrl = _pinctrl;
+ return 0;
+
+err:
+ dev_err(mmc_dev(host-mmc), pins configuration error: %i\n, ret);
+ devm_pinctrl_put(_pinctrl);
+ return ret;
+}
+
/*
* Start clock to the card
*/
@@ -1858,7 +1924,6 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
const struct of_device_id *match;
dma_cap_mask_t mask;
unsigned tx_req, rx_req;
- struct pinctrl *pinctrl;
apply_clk_hack(pdev-dev);
@@ -2083,10 +2148,9 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
omap_hsmmc_disable_irq(host);
- pinctrl = devm_pinctrl_get_select_default(pdev-dev);
- if (IS_ERR(pinctrl))
- dev_warn(pdev-dev,
- pins are not configured from the driver\n);
+ ret = omap_hsmmc_pin_init(host);
+ if (ret)
+ goto err_pinctrl_state;
/*
* For now, only support SDIO interrupt if we are booted with
@@ -2127,7 +2191,11 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
err_slot_name:
mmc_remove_host(mmc);
- free_irq(mmc_slot(host).card_detect_irq, host);
+ if (host-pinctrl)
+ devm_pinctrl_put(host-pinctrl);
+err_pinctrl_state:
+ if ((mmc_slot(host).card_detect_irq))
+ free_irq(mmc_slot(host).card_detect_irq, host);
err_irq_cd:
if (host-use_reg)
omap_hsmmc_reg_put(host);
@@ -2179,6 +2247,8 @@ static int omap_hsmmc_remove(struct platform_device *pdev)
dma_release_channel(host-tx_chan);
if (host-rx_chan)
dma_release_channel(host-rx_chan);
+ if (host-pinctrl)
+ devm_pinctrl_put(host-pinctrl);
pm_runtime_put_sync(host-dev);
pm_runtime_disable(host-dev);
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7 3/4] mmc: omap_hsmmc: Pin remux workaround to support SDIO interrupt on AM335x.
The am335x can't detect pending cirq in PM runtime suspend.
This patch reconfigures dat1 as a GPIO before going to suspend.
SDIO interrupts are detected with the GPIO, the GPIO will only wake
the module from suspend, SDIO irq detection will still happen through the
IP block.
Idea of remuxing the pins by Tony Lindgren, all bugs are mine.
Signed-off-by: Andreas Fenkart afenk...@gmail.com
diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
index 8c8908a..8e1195e 100644
--- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -55,3 +55,53 @@ Examples:
edma 25;
dma-names = tx, rx;
};
+
+[workaround for missing swakeup on am33xx]
+
+This SOC is missing the swakeup line, it will not detect SDIO irq
+while in suspend.
+
+ --
+ | PRCM |
+ --
+ ^ |
+ swakeup | | fclk
+ | v
+ ----- -
+ | card | -- CIRQ -- | hsmmc | -- IRQ -- | CPU |
+ ----- -
+
+In suspend the fclk is off and the module is disfunctional. Even
+register reads will fail. A small logic in the host will request
+fclk restore, when an external event is detected. Once the clock
+is restored, the host detects the event normally. Since am33xx
+doesn't have this line it never wakes from suspend.
+
+The workaround is to reconfigure the dat1 line as a GPIO upon
+suspend. To make this work, we need to set 1) the named pinctrl
+states default, active and idle, 2) the gpio detecting
+sdio irq in suspend and 3) compatibe section, see example below.
+The MMC driver will then toggle between active and idle during
+the runtime. If configuration is incomplete, a warning message is
+emitted falling back to polling. Mind not every application
+needs SDIO irq, e.g. MMC cards Affected chips are am335x,
+probably others
+
+
+ mmc1: mmc@48060100 {
+ compatible = ti,am33xx-hsmmc;
+ ...
+ interrupts-extended = intc 64 gpio2 28 0;
+ ...
+ pinctrl-names = default, active, idle
+ pinctrl-0 = mmc1_pins;
+ pinctrl-1 = mmc1_pins;
+ pinctrl-2 = mmc1_cirq_pin;
+ ...
+ };
+
+ mmc1_cirq_pin: pinmux_cirq_pin {
+ pinctrl-single,pins =
+ 0x0f8 0x3f /* GPIO2_28 */
+ ;
+ };
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 5e60925..452c05a 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -29,6 +29,7 @@
#include linux/timer.h
#include linux/clk.h
#include linux/of.h
+#include linux/of_irq.h
#include linux/of_gpio.h
#include linux/of_device.h
#include linux/omap-dma.h
@@ -36,6 +37,7 @@
#include linux/mmc/core.h
#include linux/mmc/mmc.h
#include linux/io.h
+#include linux/irq.h
#include linux/gpio.h
#include linux/regulator/consumer.h
#include linux/pinctrl/consumer.h
@@ -206,6 +208,7 @@ struct omap_hsmmc_host {
u32 sysctl;
u32 capa;
int irq;
+ int gpio_sdio_irq;
int use_dma, dma_ch;
struct dma_chan *tx_chan;
struct dma_chan *rx_chan;
@@ -218,6 +221,8 @@ struct omap_hsmmc_host {
int req_in_progress;
int flags;
#define HSMMC_SDIO_IRQ_ENABLED (1 0)/* SDIO irq enabled */
+#define HSMMC_SWAKEUP_QUIRK(1 1)
+#define HSMMC_CIRQ_GPIO_ENABLED (1 2)
struct omap_hsmmc_next next_data;
struct pinctrl *pinctrl;
@@ -225,6 +230,23 @@ struct omap_hsmmc_host {
struct omap_mmc_platform_data *pdata;
};
+static irqreturn_t omap_hsmmc_cirq(int irq, void *dev_id)
+{
+ struct omap_hsmmc_host *host = dev_id;
+ unsigned long flags;
+
+ spin_lock_irqsave(host-irq_lock, flags);
+ if (host-flags HSMMC_CIRQ_GPIO_ENABLED) {
+ disable_irq_nosync(host-gpio_sdio_irq);
+ host-flags = ~HSMMC_CIRQ_GPIO_ENABLED;
+ }
+ spin_unlock_irqrestore(host-irq_lock, flags);
+
+ pm_request_resume(host-dev); /* no use counter */
+
+ return IRQ_HANDLED;
+}
+
static int omap_hsmmc_card_detect(struct device *dev, int slot)
{
struct omap_hsmmc_host *host = dev_get_drvdata(dev);
@@ -1920,7 +1942,7 @@ static int omap_hsmmc_probe(struct platform_device *pdev)
struct mmc_host *mmc;
struct omap_hsmmc_host *host = NULL;
struct resource *res;
- int ret, irq;
+ int ret, irq, _gpio_cirq;
const struct
[PATCH v7 4/4] mmc: omap_hsmmc: Extend debugfs for SDIO IRQ, GPIO and pinmux.
Add SDIO IRQ entries to debugfs entry. Note that PSTATE shows current
state of data lines, incl. SDIO IRQ pending
Signed-off-by: Andreas Fenkart afenk...@gmail.com
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 452c05a..cf03481 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -82,6 +82,7 @@ static void apply_clk_hack(struct device *dev)
#define OMAP_HSMMC_RSP54 0x0118
#define OMAP_HSMMC_RSP76 0x011C
#define OMAP_HSMMC_DATA0x0120
+#define OMAP_HSMMC_PSTATE 0x0124
#define OMAP_HSMMC_HCTL0x0128
#define OMAP_HSMMC_SYSCTL 0x012C
#define OMAP_HSMMC_STAT0x0130
@@ -1792,14 +1793,30 @@ static int omap_hsmmc_regs_show(struct seq_file *s,
void *data)
{
struct mmc_host *mmc = s-private;
struct omap_hsmmc_host *host = mmc_priv(mmc);
+ const char* cirq_state;
+ bool suspended;
- seq_printf(s, mmc%d:\n ctx_loss:\t%d\n\nregs:\n,
- mmc-index, host-context_loss);
+ seq_printf(s, mmc%d:\n, mmc-index);
+ if (mmc-caps MMC_CAP_SDIO_IRQ)
+ cirq_state = (host-flags HSMMC_SDIO_IRQ_ENABLED) ?
+ enabled : disabled;
+ else
+ cirq_state = polling;
+ seq_printf(s, sdio irq\t%s\n, cirq_state);
- pm_runtime_get_sync(host-dev);
+ if (host-flags HSMMC_SWAKEUP_QUIRK) {
+ suspended = host-dev-power.runtime_status != RPM_ACTIVE;
+ seq_printf(s, pinmux config\t%s\n, (suspended ?
+ gpio : sdio));
+ }
+ seq_printf(s, ctx_loss:\t%d\n, host-context_loss);
+ pm_runtime_get_sync(host-dev);
+ seq_puts(s, \nregs:\n);
seq_printf(s, CON:\t\t0x%08x\n,
OMAP_HSMMC_READ(host-base, CON));
+ seq_printf(s, PSTATE:\t\t0x%08x\n,
+ OMAP_HSMMC_READ(host-base, PSTATE));
seq_printf(s, HCTL:\t\t0x%08x\n,
OMAP_HSMMC_READ(host-base, HCTL));
seq_printf(s, SYSCTL:\t\t0x%08x\n,
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ARM: dts: duovero-parlor: Add HDMI output
Hi,
On 02/25/2014 01:39 PM, Russell King - ARM Linux wrote:
On Mon, Feb 24, 2014 at 05:22:27PM -0300, Javier Martinez Canillas wrote:
Hi Russell,
On Mon, Feb 24, 2014 at 3:03 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Mon, Feb 24, 2014 at 06:07:49PM +0100, Florian Vaussard wrote:
+ hdmi0: connector@0 {
+ compatible = hdmi-connector;
This looks way to generic a compatible string. Are you sure it's
correct?
That compatible string is correct according to the latest series
posted by Tomi Valkeinen to add DT bindings for the OMAP Display
SubSystem (DSS) [0].
in which case:
NN AA K K
NN N A A CC K K
N N N AA C KK
N N N AA C KK
N NN AA CC K K
NN AA K K
What a nice nack.
Yes, that's a very big nack. Two things:
1. OMAP really doesn't have the right to define a compatible string which
is as generic as hdmi-connector.
2. Even with omapdss, before it, the convention that DT people have adopted
is for the prefix to be companyname, and not a subsystem.
I'm not the only one with this concern - I discussed it with Arnd last
night and his comments were about it being obviously bogus.
I agree. It should probably be ti,omapdss-hdmi-connector, or simply
ti,hdmi-connector, if any.
The property is added on this patch [1] and as far as I understood the
idea is that it could be a generic DT binding that can be used by
platform specific HDMI connectors like the omap dss HDMI connector [2].
Why do the physical connectors need a DT binding? Surely what needs the
DT binding is the HDMI encoder - and that certainly should no way be a
generic name, because there's no such thing as a generic HDMI encoder
chip.
The HDMI IP is declared in omap4.dtsi, with the compatible
ti,omap4-hdmi. The code of the HDMI connector [1] seems to mainly call
ops of the connected endpoint, so it seems to act as a logical
termination in the DSS chain, but I may be wrong.
Regards,
Florian
[1]
https://git.kernel.org/cgit/linux/kernel/git/tomba/linux.git/tree/drivers/video/omap2/displays-new/connector-hdmi.c?h=work%2Fdss-dt-review-3
--
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 0/2] mfd: twl6040: Small clean-ups
Hi, Here is two cleanups patches for the TWL6040 audio codec. The first one checks for an error when reading the revision register (first read in the probe path). The second removes a duplicate I2C writes. Regards, Florian Florian Vaussard (2): mfd: twl6040: Check for error when reading revision register mfd: twl6040: Remove duplicate register write drivers/mfd/twl6040.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) -- 1.8.1.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] mfd: twl6040: Remove duplicate register write
When probing, regmap_register_patch() will bypass the cache and perform i2c writes for the given patches. It is thus unnecessary to manually set the TWL6040_REG_ACCCTL register just before, as it will be done when registering the twl6040_patch. Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch --- drivers/mfd/twl6040.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/mfd/twl6040.c b/drivers/mfd/twl6040.c index 67e524e..0bd5a18 100644 --- a/drivers/mfd/twl6040.c +++ b/drivers/mfd/twl6040.c @@ -710,7 +710,6 @@ static int twl6040_probe(struct i2c_client *client, } /* dual-access registers controlled by I2C only */ - twl6040_set_bits(twl6040, TWL6040_REG_ACCCTL, TWL6040_I2CSEL); regmap_register_patch(twl6040-regmap, twl6040_patch, ARRAY_SIZE(twl6040_patch)); -- 1.8.1.2 -- 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] mfd: twl6040: Check for error when reading revision register
We may have an error when reading the revision register, so check for
the returned value.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
---
drivers/mfd/twl6040.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/mfd/twl6040.c b/drivers/mfd/twl6040.c
index 32ce1ae..67e524e 100644
--- a/drivers/mfd/twl6040.c
+++ b/drivers/mfd/twl6040.c
@@ -661,6 +661,11 @@ static int twl6040_probe(struct i2c_client *client,
init_completion(twl6040-ready);
twl6040-rev = twl6040_reg_read(twl6040, TWL6040_REG_ASICREV);
+ if (twl6040-rev 0) {
+ dev_err(client-dev, Failed to read revision register: %d\n,
+ twl6040-rev);
+ goto gpio_err;
+ }
/* ERRATA: Automatic power-up is not possible in ES1.0 */
if (twl6040_get_revid(twl6040) TWL6040_REV_ES1_0)
--
1.8.1.2
--
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/2] ARM: dts: duovero-parlor: Add HDMI output
Hi, On Tue, Feb 25, 2014 at 12:39:21PM +, Russell King - ARM Linux wrote: That compatible string is correct according to the latest series posted by Tomi Valkeinen to add DT bindings for the OMAP Display SubSystem (DSS) [0]. in which case: NN AA K K NN N A A CC K K N N N AA C KK N N N AA C KK N NN AA CC K K NN AA K K Yes, that's a very big nack. Two things: 1. OMAP really doesn't have the right to define a compatible string which is as generic as hdmi-connector. AFAIK the idea was to have hdmi-connector as part of the common display framework [1]. It's not really platform specific, since it's just a connector. Since omapdss does not yet implement the common display framework, but wants to keep a stable DT API it rewrites hdmi-connector to omapdss,hdmi-connector for now. 2. Even with omapdss, before it, the convention that DT people have adopted is for the prefix to be companyname, and not a subsystem. I'm not the only one with this concern - I discussed it with Arnd last night and his comments were about it being obviously bogus. The property is added on this patch [1] and as far as I understood the idea is that it could be a generic DT binding that can be used by platform specific HDMI connectors like the omap dss HDMI connector [2]. Why do the physical connectors need a DT binding? This is the termination of the video bus and useful information for xrandr. Surely what needs the DT binding is the HDMI encoder - and that certainly should no way be a generic name, because there's no such thing as a generic HDMI encoder chip. The HDMI encoder and companion chips are described separatly and properly prefixed [0]. [0] http://www.spinics.net/lists/linux-omap/msg102522.html [1] https://lwn.net/Articles/563157/ -- Sebastian signature.asc Description: Digital signature
Re: [PATCH 0/2] mfd: twl6040: Small clean-ups
On 02/25/2014 03:28 PM, Florian Vaussard wrote: Hi, Here is two cleanups patches for the TWL6040 audio codec. The first one checks for an error when reading the revision register (first read in the probe path). The second removes a duplicate I2C writes. Regards, Florian To both: Acked-by: Peter Ujfalusi peter.ujfal...@ti.com Florian Vaussard (2): mfd: twl6040: Check for error when reading revision register mfd: twl6040: Remove duplicate register write drivers/mfd/twl6040.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) -- Péter -- 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/2] mfd: twl6040: Check for error when reading revision register
We may have an error when reading the revision register, so check for the returned value. Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch --- drivers/mfd/twl6040.c | 5 + 1 file changed, 5 insertions(+) Applied, thanks. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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/2] mfd: twl6040: Remove duplicate register write
When probing, regmap_register_patch() will bypass the cache and perform i2c writes for the given patches. It is thus unnecessary to manually set the TWL6040_REG_ACCCTL register just before, as it will be done when registering the twl6040_patch. Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch --- drivers/mfd/twl6040.c | 1 - 1 file changed, 1 deletion(-) Applied, thanks. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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/2] mfd: twl6040: Small clean-ups
Here is two cleanups patches for the TWL6040 audio codec. The first one checks for an error when reading the revision register (first read in the probe path). The second removes a duplicate I2C writes. Regards, Florian To both: Acked-by: Peter Ujfalusi peter.ujfal...@ti.com Applied both with Peter's Ack. Florian Vaussard (2): mfd: twl6040: Check for error when reading revision register mfd: twl6040: Remove duplicate register write drivers/mfd/twl6040.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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: TWL6040 fails to initialize
Hi Florian, On 02/25/2014 12:30 PM, Florian Vaussard wrote: Hi Peter, I got recently to work on the DT support for an OMAP4 board [1], and I encountered some troubles with the probe of the twl6040 audio codec on 3.14-rc kernels. On 3.13, things were working correctly. So I somewhat managed to bisect this down to [c7f9129 mfd: twl6040: reg_defaults support for regmap]. But looking more into it, things are less obvious. Interesting. I just booted 3.14.0-rc4 with HEAD: 7472e009a3f1 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security on my PandaBoard-ES and audio comes up just fine (twl6040). When the init fails, here is what happens: [2.455749] twl6040 0-004b: Looking up vio-supply from device tree [2.456359] twl6040 0-004b: Looking up v2v1-supply from device tree [2.457061] twl6040 0-004b: Failed to set masks in 0x4: -121 [2.463043] twl6040: probe of 0-004b failed with error -121 logically resulting in Do you have the regulators in your dts file? vio and v2v1 is needed by the twl6040. [2.770050] omap-abe-twl6040 sound.4: ASoC: CODEC twl6040-codec not registered [2.70] omap-abe-twl6040 sound.4: snd_soc_register_card() failed: -517 [2.785095] platform sound.4: Driver omap-abe-twl6040 requests probe deferral We get a EREMOTEIO when calling regmap_add_irq_chip() from twl6040_probe(). regmap_add_irq_chip() will try to perform non-cached i2c writes, where the omap-i2c driver get a NACK from the remote chip. Strange enough, the non-cached read just before (i.e. twl6040_reg_read(twl6040, TWL6040_REG_ASICREV)) succeeds. Power is not enabled? There might be missing 32K clock for twl6040, can you check your board's schema against PandaBoard-ES? After some fiddling around, I could find that delaying the call to regmap_add_irq_chip(), let's say by msleep(1), will solve the problem. As the TRM for TWL6040 is not public, and I cannot physically access the i2c bus on the board, I ran out of hypothesis. I first suspected a concurrent access from the McPDM bus, but the mcpdm driver does not seem to perform command (write) access. As the regulators are enabled just before, could it be the twl6040 IP which is not yet initialized, and NACK'ing writes but not reads? The commit c7f9129 changed the regmap logic by reducing the number of non-cached accesses, and thus changed the access timings, so it may have trigged this behaviour. But this is pure supposition, as I cannot hack the i2c bus :( And adding any kind of tracing before regmap_add_irq_chip() usually delays enough to make the probe succeeds. Any ideas? Regards, Florian [1] http://thread.gmane.org/gmane.linux.ports.arm.omap/110801 -- Péter -- 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/2] mfd: twl6040: Small clean-ups
On 02/25/2014 03:27 PM, Lee Jones wrote: Here is two cleanups patches for the TWL6040 audio codec. The first one checks for an error when reading the revision register (first read in the probe path). The second removes a duplicate I2C writes. Regards, Florian To both: Acked-by: Peter Ujfalusi peter.ujfal...@ti.com Applied both with Peter's Ack. Thanks! Florian -- 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: TWL6040 fails to initialize
Hi Peter,
On 02/25/2014 03:29 PM, Peter Ujfalusi wrote:
Hi Florian,
On 02/25/2014 12:30 PM, Florian Vaussard wrote:
Hi Peter,
I got recently to work on the DT support for an OMAP4 board [1], and I
encountered some troubles with the probe of the twl6040 audio codec on
3.14-rc kernels. On 3.13, things were working correctly. So I somewhat
managed to bisect this down to [c7f9129 mfd: twl6040: reg_defaults
support for regmap]. But looking more into it, things are less obvious.
Interesting. I just booted 3.14.0-rc4 with HEAD:
7472e009a3f1 Merge branch 'for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security
on my PandaBoard-ES and audio comes up just fine (twl6040).
I know, it is weird. It appeared with 3.14-rc1, 3.13 was working just fine.
When the init fails, here is what happens:
[2.455749] twl6040 0-004b: Looking up vio-supply from device tree
[2.456359] twl6040 0-004b: Looking up v2v1-supply from device tree
[2.457061] twl6040 0-004b: Failed to set masks in 0x4: -121
[2.463043] twl6040: probe of 0-004b failed with error -121
logically resulting in
Do you have the regulators in your dts file? vio and v2v1 is needed by the
twl6040.
Yes, I have both regulators. Here is the relevant part of the DTS:
twl6040: twl@4b {
compatible = ti,twl6040;
reg = 0x4b;
interrupts = GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH;
interrupt-parent = gic;
ti,audpwron-gpio = gpio6 0 GPIO_ACTIVE_HIGH;
vio-supply = v1v8;
v2v1-supply = v2v1;
enable-active-high;
};
[2.770050] omap-abe-twl6040 sound.4: ASoC: CODEC twl6040-codec not
registered
[2.70] omap-abe-twl6040 sound.4: snd_soc_register_card() failed:
-517
[2.785095] platform sound.4: Driver omap-abe-twl6040 requests probe
deferral
We get a EREMOTEIO when calling regmap_add_irq_chip() from
twl6040_probe(). regmap_add_irq_chip() will try to perform non-cached
i2c writes, where the omap-i2c driver get a NACK from the remote chip.
Strange enough, the non-cached read just before (i.e.
twl6040_reg_read(twl6040, TWL6040_REG_ASICREV)) succeeds.
Power is not enabled? There might be missing 32K clock for twl6040, can you
check your board's schema against PandaBoard-ES?
If the power was not enabled at all, I would be unable to read the
revision register, no? And delaying the probe by one millisecond would
be of no help in this case IMHO.
Unfortunately, I don't have access to the schematics of the processor
board. Only the expansion boards from Gumstix have public schematics.
For the 32K, if it was disabled, I think that I would be unable to play
with the headset output in low-power mode, right? When I put the
msleep(), I can play to HSL/HSR and everything seems to work as expected.
Regards,
Florian
--
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: EDMA: Use platform_get_resource functions for DT
On Fri, Feb 21, 2014 at 11:36 AM, Joel Fernandes jo...@ti.com wrote:
On 02/21/2014 06:15 AM, Mark Rutland wrote:
Also, while at it get rid of the assumption in the code that CC is at reg
index 0 in the DT and xbar is at offset 1. Instead use reg-names to get the
memory resource in concern keeping things much cleaner and simpler. This
also
makes it possible to have multiple channel controllers.
While this is nice I think we have to have a fallback to the existing
behaviour if there's no reg-names property present, unless we know for
certain no-one is possibly using an existing DTB.
Yes, its true it break existing DTBs but currently only 2 TI SoCs use EDMA
this
way, the vast majority of EDMA users are yet to follow where we can do it
right.
Further, the old bindings are really limiting specially the 2 CC case and if
additionally memory maps are used in the future. So keeping the old binding is
limiting in this regard.
Here is what the platform_data used to look like when used by mach-davinci:
static struct resource da850_edma_resources[] = {
{
.name = edma_cc0,
.start = DA8XX_TPCC_BASE,
.end= DA8XX_TPCC_BASE + SZ_32K - 1,
.flags = IORESOURCE_MEM,
},
{
.name = edma_tc0,
.start = DA8XX_TPTC0_BASE,
.end= DA8XX_TPTC0_BASE + SZ_1K - 1,
.flags = IORESOURCE_MEM,
},
{
.name = edma_tc1,
.start = DA8XX_TPTC1_BASE,
.end= DA8XX_TPTC1_BASE + SZ_1K - 1,
.flags = IORESOURCE_MEM,
},
{
.name = edma_cc1,
.start = DA850_TPCC1_BASE,
.end= DA850_TPCC1_BASE + SZ_32K - 1,
.flags = IORESOURCE_MEM,
},
As you can see, there are several memory maps and different interpretations.
Considering this, IMO- it makes sense to pay a small price to keep the
semantics
sane.
Then do 1 compatible string per interpretation. That can then define
the number of CCs and TCs.
On the other hand, the other 2 options are:
1. We add a fallback if reg-names look up fails.
reg-names is supposed to be optional, so you should already have that fallback.
Rob
2. We inject reg-names property into edma DT nodes that don't have them, and
make sure all future dtsi with edma nodes mention the reg-names property.
These 2 are a bit error prone though, for example if someone deliberately
forgets to mention reg-names, and the code still works, but misbehaves in
some way.
Regards,
-Joel
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: EDMA: Use platform_get_resource functions for DT
Thanks for your suggestions.
On Tue, Feb 25, 2014 at 10:22 AM, Rob Herring robherri...@gmail.com wrote:
On Fri, Feb 21, 2014 at 11:36 AM, Joel Fernandes jo...@ti.com wrote:
On 02/21/2014 06:15 AM, Mark Rutland wrote:
Also, while at it get rid of the assumption in the code that CC is at reg
index 0 in the DT and xbar is at offset 1. Instead use reg-names to get the
memory resource in concern keeping things much cleaner and simpler. This
also
makes it possible to have multiple channel controllers.
While this is nice I think we have to have a fallback to the existing
behaviour if there's no reg-names property present, unless we know for
certain no-one is possibly using an existing DTB.
Yes, its true it break existing DTBs but currently only 2 TI SoCs use EDMA
this
way, the vast majority of EDMA users are yet to follow where we can do it
right.
Further, the old bindings are really limiting specially the 2 CC case and if
additionally memory maps are used in the future. So keeping the old binding
is
limiting in this regard.
Here is what the platform_data used to look like when used by mach-davinci:
static struct resource da850_edma_resources[] = {
{
.name = edma_cc0,
.start = DA8XX_TPCC_BASE,
.end= DA8XX_TPCC_BASE + SZ_32K - 1,
.flags = IORESOURCE_MEM,
},
{
.name = edma_tc0,
.start = DA8XX_TPTC0_BASE,
.end= DA8XX_TPTC0_BASE + SZ_1K - 1,
.flags = IORESOURCE_MEM,
},
{
.name = edma_tc1,
.start = DA8XX_TPTC1_BASE,
.end= DA8XX_TPTC1_BASE + SZ_1K - 1,
.flags = IORESOURCE_MEM,
},
{
.name = edma_cc1,
.start = DA850_TPCC1_BASE,
.end= DA850_TPCC1_BASE + SZ_32K - 1,
.flags = IORESOURCE_MEM,
},
As you can see, there are several memory maps and different interpretations.
Considering this, IMO- it makes sense to pay a small price to keep the
semantics
sane.
Then do 1 compatible string per interpretation. That can then define
the number of CCs and TCs.
Ok.
On the other hand, the other 2 options are:
1. We add a fallback if reg-names look up fails.
reg-names is supposed to be optional, so you should already have that
fallback.
With the new binding, without reg-names not sure how to fall back
there can variable number of different reg entries of different types.
There's no way to know when one ends and the other begins. The fall
back I mentioned can only work for old dtbs that only specify 1 CC.
Thanks,
-Joel
--
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/2] ARM: dts: duovero-parlor: Add HDMI output
On Tuesday 25 February 2014 14:41:48 Sebastian Reichel wrote: On Tue, Feb 25, 2014 at 12:39:21PM +, Russell King - ARM Linux wrote: That compatible string is correct according to the latest series posted by Tomi Valkeinen to add DT bindings for the OMAP Display SubSystem (DSS) [0]. in which case: NN AA K K NN N A A CC K K N N N AA C KK N N N AA C KK N NN AA CC K K NN AA K K Yes, that's a very big nack. Two things: 1. OMAP really doesn't have the right to define a compatible string which is as generic as hdmi-connector. AFAIK the idea was to have hdmi-connector as part of the common display framework [1]. It's not really platform specific, since it's just a connector. Since omapdss does not yet implement the common display framework, but wants to keep a stable DT API it rewrites hdmi-connector to omapdss,hdmi-connector for now. And since the common display framework has been pretty much nacked, we have no framework on which drivers can rely ;-) 2. Even with omapdss, before it, the convention that DT people have adopted is for the prefix to be companyname, and not a subsystem. I'm not the only one with this concern - I discussed it with Arnd last night and his comments were about it being obviously bogus. The property is added on this patch [1] and as far as I understood the idea is that it could be a generic DT binding that can be used by platform specific HDMI connectors like the omap dss HDMI connector [2]. Why do the physical connectors need a DT binding? This is the termination of the video bus and useful information for xrandr. I don't think all physical connectors require a DT binding per-se, but they need to be represented in DT as they're part of the hardware. We could push connector-related information to the nodes of all chips that have interfaces wired directly to connectors, but that would result in more complex DT bindings and core. I believe modeling connectors using separate DT nodes is be best, and would allow easier support for more complex connectors that carry multiple streams/signals in parallel (video, audio, DDC, ...). Surely what needs the DT binding is the HDMI encoder - and that certainly should no way be a generic name, because there's no such thing as a generic HDMI encoder chip. The HDMI encoder and companion chips are described separatly and properly prefixed [0]. [0] http://www.spinics.net/lists/linux-omap/msg102522.html [1] https://lwn.net/Articles/563157/ -- Regards, Laurent Pinchart signature.asc Description: This is a digitally signed message part.
Re: [PATCH 2/2] ARM: dts: duovero-parlor: Add HDMI output
On Tue, Feb 25, 2014 at 05:51:21PM +0100, Laurent Pinchart wrote: I don't think all physical connectors require a DT binding per-se, but they need to be represented in DT as they're part of the hardware. We could push connector-related information to the nodes of all chips that have interfaces wired directly to connectors, but that would result in more complex DT bindings and core. I believe modeling connectors using separate DT nodes is be best, and would allow easier support for more complex connectors that carry multiple streams/signals in parallel (video, audio, DDC, ...). There is some sanity to representing physical connectors in DT, but it's not for the reason you mention above. If you consider that it's possible on PCs to find out what connectors are on the motherboard and where they are located, this is very useful information to be stored and presented. However, the idea that you combine streams at connectors is not a universal truth, and is certainly false for HDMI. HDMI combines video and audio at the encoder stage, not at the connector stage, and many HDMI encoders will provide everything required for driving the connector. However, my major objection here is not really that: my major objection is using something as generic as hdmi-connector as a compatible string. The reason is that we have to remember that DT is not just a Linux thing. It's /supposed/ to be an OS independent representation of the hardware. If we invent something generic called a hdmi-connector then we had better first do a thorough search to make sure we're not trampling on anything which is standardized or becoming a standard - if there is, we should work with them - and if that's not possible, then we need to distingush ourselves from them. What we can't do is go around inventing generic stuff without having our eyes wide open. So, here's a good question to probe how far this has been thought through already: what has been done to discuss the creation of this generic hdmi-connector thing with the various parties who are interested in HDMI outputs under DRM using device tree? If that hasn't happened, that's quite a failing - it means that we're on the road to having two _implementation specific_ DT representations for the same hardware - one for fbdev and one for DRM. That really isn't on. Yes, it then opens a pandora's box of problems about how we determine whether DRM or fbdev should bind to the DT nodes, but that should be an entirely separate issue (and, ideally of course, both should use the same sub-drivers for the components.) -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it. -- 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 1/6] PM / Voltagedomain: Add generic clk notifier handler for regulator based dynamic voltage scaling
Hi Mike, On 02/24/2014 11:51 PM, Mike Turquette wrote: Quoting Nishanth Menon (2014-02-18 12:32:18) From: Mike Turquette mturque...@linaro.org This patch provides helper functions for drivers that wish to scale voltage through the clock rate-change notifiers. The approach taken is that the user-driver(cpufreq/devfreq) do not care about the details of the OPP table, nor does it care about handling the voltage regulator directly. By using the clk notifier flags, we are able to sequence the operations in the right order. The current logic is heavily influenced by implementation done in cpufreq-cpu0. [n...@ti.com: Fixes in logic, and broken out from clk to allow building a generic voltagedomain solution independent of cpufreq] Signed-off-by: Nishanth Menon n...@ti.com Signed-off-by: Mike Turquette mturque...@linaro.org Not-signed-off-by: Mike Turquette mturque...@linaro.org I haven't reviewed this series and it is a pretty big deviation from my original RFC. You can have authorship of the patches if you want. Sure, I had send a private note requesting clarification about the authorship, but I guess I can take this as the response :). I'm not sure about trying to capture the voltdm as a core concept. It feels a bit unwieldy to me. Considering it is a simple collation of regulators and SoC specific magic which have to be operated in tandem to clock operation, Why does it seem unwieldy? Usage of multiple voltage planes in a single voltage domain concept does not seem unique to TI processors either: For example, imx6q-cpufreq.c uses 3 regulators (arm, pu, soc), s5pv210-cpufreq.c uses two regulators (vddarm, vddint), ideally OMAP implementation would use two (vdd_mpu, vbb_mpu). I have wondered about making an abstract performance domain which is the dvfs analogue to generic power domains. This a reasonable split since gpd are good for idle power savings (e.g. clock gate, power gate, sleep state, etc) and perf domains would be good for active power savings (dvfs). Having a generic container for performance domains might make a good place to stuff all of this glue logic that we keep running into (e.g. CPU and GPU max frequencies that are related), and it might make another nice knob for the thermal folks to use. This sounds like one level higher abstraction that we are speaking of here? I was'nt intending to solve the bigger picture problem here - just an abstraction level that might allow reusablity for multiple SoCs. In fact, having an abstraction away for voltage domain(which may consist of multiple regulators and any SoC specific magic) purely allows us to move towards a direction you mention here. For the case of the OMAP voltage domains, it would be a place to stuff all of the VC/VP - ABB - Smart Reflex AVS stuff. Unfortunately, I dont completely comprehend objection we have to this approach (other than an higher level abstraction is needed) and if we do have an objection, what is the alternate approach should be for representing hardware which this series attempts to present. -- Regards, Nishanth Menon -- 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: [PATCHv2 01/16] iommu/omap: convert to devm_* interfaces
Hi Suman,
Thank you for the patch.
On Thursday 13 February 2014 12:15:32 Suman Anna wrote:
Use the various devm_ interfaces to simplify the cleanup in
probe and remove functions.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
Signed-off-by: Suman Anna s-a...@ti.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/iommu/omap-iommu.c | 52 --
1 file changed, 10 insertions(+), 42 deletions(-)
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index bcd78a7..fff2ffd 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -941,7 +941,7 @@ static int omap_iommu_probe(struct platform_device
*pdev) struct resource *res;
struct iommu_platform_data *pdata = pdev-dev.platform_data;
- obj = kzalloc(sizeof(*obj) + MMU_REG_SIZE, GFP_KERNEL);
+ obj = devm_kzalloc(pdev-dev, sizeof(*obj) + MMU_REG_SIZE, GFP_KERNEL);
if (!obj)
return -ENOMEM;
@@ -958,33 +958,18 @@ static int omap_iommu_probe(struct platform_device
*pdev) INIT_LIST_HEAD(obj-mmap);
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!res) {
- err = -ENODEV;
- goto err_mem;
- }
-
- res = request_mem_region(res-start, resource_size(res),
- dev_name(pdev-dev));
- if (!res) {
- err = -EIO;
- goto err_mem;
- }
-
- obj-regbase = ioremap(res-start, resource_size(res));
- if (!obj-regbase) {
- err = -ENOMEM;
- goto err_ioremap;
- }
+ obj-regbase = devm_ioremap_resource(obj-dev, res);
+ if (IS_ERR(obj-regbase))
+ return PTR_ERR(obj-regbase);
irq = platform_get_irq(pdev, 0);
- if (irq 0) {
- err = -ENODEV;
- goto err_irq;
- }
- err = request_irq(irq, iommu_fault_handler, IRQF_SHARED,
- dev_name(pdev-dev), obj);
+ if (irq 0)
+ return -ENODEV;
+
+ err = devm_request_irq(obj-dev, irq, iommu_fault_handler, IRQF_SHARED,
+dev_name(obj-dev), obj);
if (err 0)
- goto err_irq;
+ return err;
platform_set_drvdata(pdev, obj);
pm_runtime_irq_safe(obj-dev);
@@ -992,34 +977,17 @@ static int omap_iommu_probe(struct platform_device
*pdev)
dev_info(pdev-dev, %s registered\n, obj-name);
return 0;
-
-err_irq:
- iounmap(obj-regbase);
-err_ioremap:
- release_mem_region(res-start, resource_size(res));
-err_mem:
- kfree(obj);
- return err;
}
static int omap_iommu_remove(struct platform_device *pdev)
{
- int irq;
- struct resource *res;
struct omap_iommu *obj = platform_get_drvdata(pdev);
iopgtable_clear_entry_all(obj);
- irq = platform_get_irq(pdev, 0);
- free_irq(irq, obj);
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- release_mem_region(res-start, resource_size(res));
- iounmap(obj-regbase);
-
pm_runtime_disable(obj-dev);
dev_info(pdev-dev, %s removed\n, obj-name);
- kfree(obj);
return 0;
}
--
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
Re: [PATCHv2 02/16] iommu/omap: omap_iommu_attach() should return ENODEV, not NULL
Hi Suman,
Thank you for the patch.
On Thursday 13 February 2014 12:15:33 Suman Anna wrote:
From: Florian Vaussard florian.vauss...@epfl.ch
omap_iommu_attach() returns NULL or ERR_PTR in case of error, but
omap_iommu_attach_dev() only checks for IS_ERR. Thus a NULL return value (in
case driver_find_device fails) will cause the kernel to panic when
omap_iommu_attach_dev() dereferences the pointer.
In such case, omap_iommu_attach() should return ENODEV, not NULL.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
Acked-by: Suman Anna s-a...@ti.com
---
drivers/iommu/omap-iommu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index fff2ffd..6272c36 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -863,7 +863,7 @@ static int device_match_by_alias(struct device *dev,
void *data) **/
static struct omap_iommu *omap_iommu_attach(const char *name, u32 *iopgd)
{
- int err = -ENOMEM;
+ int err = -ENODEV;
struct device *dev;
struct omap_iommu *obj;
@@ -871,7 +871,7 @@ static struct omap_iommu *omap_iommu_attach(const char
*name, u32 *iopgd) (void *)name,
device_match_by_alias);
if (!dev)
- return NULL;
+ return ERR_PTR(err);
I would return ERR_PTR(-ENODEV) here, and remove the initialization at
declaration of err above.
obj = to_iommu(dev);
--
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
Re: [PATCHv2 07/16] iommu/omap: allow enable/disable even without pdata
Hi Suman,
Thank you for the patch.
On Thursday 13 February 2014 12:15:38 Suman Anna wrote:
From: Florian Vaussard florian.vauss...@epfl.ch
When booting with a devicetree, no platform data is provided.
Do not prematurely exit iommu_enable() and iommu_disable() in
such a case.
Note: As OMAP do not yet has a proper reset controller driver,
IOMMUs requiring a reset signal should use pdata-quirks as a
transitional solution.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
This looks good to me, but you should move this patch before 04/16, otherwise
you'll break bisection.
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/iommu/omap-iommu.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index f6afe8f..7672eb4 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -149,13 +149,10 @@ static int iommu_enable(struct omap_iommu *obj)
struct platform_device *pdev = to_platform_device(obj-dev);
struct iommu_platform_data *pdata = pdev-dev.platform_data;
- if (!pdata)
- return -EINVAL;
-
if (!arch_iommu)
return -ENODEV;
- if (pdata-deassert_reset) {
+ if (pdata pdata-deassert_reset) {
err = pdata-deassert_reset(pdev, pdata-reset_name);
if (err) {
dev_err(obj-dev, deassert_reset failed: %d\n, err);
@@ -175,14 +172,11 @@ static void iommu_disable(struct omap_iommu *obj)
struct platform_device *pdev = to_platform_device(obj-dev);
struct iommu_platform_data *pdata = pdev-dev.platform_data;
- if (!pdata)
- return;
-
arch_iommu-disable(obj);
pm_runtime_put_sync(obj-dev);
- if (pdata-assert_reset)
+ if (pdata pdata-assert_reset)
pdata-assert_reset(pdev, pdata-reset_name);
}
--
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
Re: [PATCHv2 08/16] ARM: OMAP3: remove deprecated CONFIG_OMAP_IOMMU_IVA2
On Thursday 13 February 2014 12:15:39 Suman Anna wrote:
From: Florian Vaussard florian.vauss...@epfl.ch
CONFIG_OMAP_IOMMU_IVA2 was defined originally to avoid conflicting
usage by tidspbridge and other iommu users. The same can be achieved
by marking the DT node disabled, so remove this obsolete flag and
the corresponding hwmod data can be enabled.
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
[s-a...@ti.com: revise commit log]
Signed-off-by: Suman Anna s-a...@ti.com
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 8
arch/arm/plat-omap/Kconfig | 3 ---
2 files changed, 11 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c index 4c3b1e6..81dd071 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -3029,8 +3029,6 @@ static struct omap_hwmod omap3xxx_mmu_isp_hwmod = {
.flags = HWMOD_NO_IDLEST,
};
-#ifdef CONFIG_OMAP_IOMMU_IVA2
-
/* mmu iva */
static struct omap_mmu_dev_attr mmu_iva_dev_attr = {
@@ -3082,8 +3080,6 @@ static struct omap_hwmod omap3xxx_mmu_iva_hwmod = {
.flags = HWMOD_NO_IDLEST,
};
-#endif
-
/* l4_per - gpio4 */
static struct omap_hwmod_addr_space omap3xxx_gpio4_addrs[] = {
{
@@ -3855,9 +3851,7 @@ static struct omap_hwmod_ocp_if
*omap34xx_hwmod_ocp_ifs[] __initdata = { omap3xxx_l4_core__hdq1w,
omap3xxx_sad2d__l3,
omap3xxx_l4_core__mmu_isp,
-#ifdef CONFIG_OMAP_IOMMU_IVA2
omap3xxx_l3_main__mmu_iva,
-#endif
omap34xx_l4_core__ssi,
NULL
};
@@ -3881,9 +3875,7 @@ static struct omap_hwmod_ocp_if
*omap36xx_hwmod_ocp_ifs[] __initdata = { omap3xxx_l4_core__hdq1w,
omap3xxx_sad2d__l3,
omap3xxx_l4_core__mmu_isp,
-#ifdef CONFIG_OMAP_IOMMU_IVA2
omap3xxx_l3_main__mmu_iva,
-#endif
NULL
};
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index 436ea97..02fc10d 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -86,9 +86,6 @@ config OMAP_MUX_WARNINGS
to change the pin multiplexing setup. When there are no warnings
printed, it's safe to deselect OMAP_MUX for your product.
-config OMAP_IOMMU_IVA2
- bool
-
config OMAP_MPU_TIMER
bool Use mpu timer
depends on ARCH_OMAP1
--
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
Re: [PATCHv2 03/16] Documentation: dt: add OMAP iommu bindings
Hi Suman,
Thank you for the patch.
On Thursday 13 February 2014 12:15:34 Suman Anna wrote:
From: Florian Vaussard florian.vauss...@epfl.ch
This patch adds the iommu bindings for all OMAP2+ SoCs. Apart from
the standard bindings used by OMAP peripherals, this patch uses a
'dma-window' (already used by Tegra SMMU) and adds two OMAP custom
bindings - 'ti,#tlb-entries' and 'ti,iommu-bus-err-back'.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
[s-a...@ti.com: split bindings document, add dra7 and bus error back]
Signed-off-by: Suman Anna s-a...@ti.com
---
.../devicetree/bindings/iommu/ti,omap-iommu.txt| 28 +++
1 file changed, 28 insertions(+)
create mode 100644
Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt
diff --git a/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt
b/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt new file mode
100644
index 000..116492d
--- /dev/null
+++ b/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt
@@ -0,0 +1,28 @@
+OMAP2+ IOMMU
+
+Required properties:
+- compatible : Should be one of,
+ ti,omap2-iommu for OMAP2/OMAP3 IOMMU instances
+ ti,omap4-iommu for OMAP4/OMAP5 IOMMU instances
+ ti,dra7-iommu for DRA7xx IOMMU instances
+- ti,hwmods : Name of the hwmod associated with the IOMMU instance
+- reg: Address space for the configuration registers
+- interrupts : Interrupt specifier for the IOMMU instance
+- dma-window : IOVA start address and length
Isn't the dma window more of a system configuration property than a hardware
property ? How do you expect it to be set ?
+Optional properties:
+- ti,#tlb-entries : Number of entries in the translation look-aside buffer.
+Should be either 8 or 32 (default: 32)
+- ti,iommu-bus-err-back : Indicates the IOMMU instance supports throwing
+ back a bus error response on MMU faults.
Do these features vary per IOMMU instance or per IOMMU model ? In the latter
case they could be inferred from the compatible string by the driver without
requiring them to be explicit in DT (whether you want to do so is left to you
though).
+Example:
+ /* OMAP3 ISP MMU */
+ mmu_isp: mmu@480bd400 {
+ compatible = ti,omap2-iommu;
+ reg = 0x480bd400 0x80;
+ interrupts = 24;
+ ti,hwmods = mmu_isp;
+ ti,#tlb-entries = 8;
+ dma-window = 0 0xf000;
+ };
--
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
Re: [PATCHv2 02/16] iommu/omap: omap_iommu_attach() should return ENODEV, not NULL
Hi Laurent,
On 02/25/2014 03:13 PM, Laurent Pinchart wrote:
Hi Suman,
Thank you for the patch.
On Thursday 13 February 2014 12:15:33 Suman Anna wrote:
From: Florian Vaussard florian.vauss...@epfl.ch
omap_iommu_attach() returns NULL or ERR_PTR in case of error, but
omap_iommu_attach_dev() only checks for IS_ERR. Thus a NULL return value (in
case driver_find_device fails) will cause the kernel to panic when
omap_iommu_attach_dev() dereferences the pointer.
In such case, omap_iommu_attach() should return ENODEV, not NULL.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
Acked-by: Suman Anna s-a...@ti.com
---
drivers/iommu/omap-iommu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index fff2ffd..6272c36 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -863,7 +863,7 @@ static int device_match_by_alias(struct device *dev,
void *data) **/
static struct omap_iommu *omap_iommu_attach(const char *name, u32 *iopgd)
{
- int err = -ENOMEM;
+ int err = -ENODEV;
struct device *dev;
struct omap_iommu *obj;
@@ -871,7 +871,7 @@ static struct omap_iommu *omap_iommu_attach(const char
*name, u32 *iopgd) (void *)name,
device_match_by_alias);
if (!dev)
- return NULL;
+ return ERR_PTR(err);
I would return ERR_PTR(-ENODEV) here, and remove the initialization at
declaration of err above.
The initialization at the beginning is also serving one another exit
path (a check for try_module_get), where err is not being set. If the
initialization is removed, then the err has to be set explicitly at the
other place. Let me know if you still want this changed.
regards
Suman
obj = to_iommu(dev);
--
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: [PATCHv2 07/16] iommu/omap: allow enable/disable even without pdata
Hi Laurent,
On 02/25/2014 03:15 PM, Laurent Pinchart wrote:
Hi Suman,
Thank you for the patch.
On Thursday 13 February 2014 12:15:38 Suman Anna wrote:
From: Florian Vaussard florian.vauss...@epfl.ch
When booting with a devicetree, no platform data is provided.
Do not prematurely exit iommu_enable() and iommu_disable() in
such a case.
Note: As OMAP do not yet has a proper reset controller driver,
IOMMUs requiring a reset signal should use pdata-quirks as a
transitional solution.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
This looks good to me, but you should move this patch before 04/16, otherwise
you'll break bisection.
OK, I see the point w.r.t the OMAP3 ISP node. I will move it to before
03/16 (the DT bindings patch), it shouldn't make any difference.
regards
Suman
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/iommu/omap-iommu.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index f6afe8f..7672eb4 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -149,13 +149,10 @@ static int iommu_enable(struct omap_iommu *obj)
struct platform_device *pdev = to_platform_device(obj-dev);
struct iommu_platform_data *pdata = pdev-dev.platform_data;
- if (!pdata)
- return -EINVAL;
-
if (!arch_iommu)
return -ENODEV;
- if (pdata-deassert_reset) {
+ if (pdata pdata-deassert_reset) {
err = pdata-deassert_reset(pdev, pdata-reset_name);
if (err) {
dev_err(obj-dev, deassert_reset failed: %d\n, err);
@@ -175,14 +172,11 @@ static void iommu_disable(struct omap_iommu *obj)
struct platform_device *pdev = to_platform_device(obj-dev);
struct iommu_platform_data *pdata = pdev-dev.platform_data;
- if (!pdata)
- return;
-
arch_iommu-disable(obj);
pm_runtime_put_sync(obj-dev);
- if (pdata-assert_reset)
+ if (pdata pdata-assert_reset)
pdata-assert_reset(pdev, pdata-reset_name);
}
--
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: [PATCHv2 03/16] Documentation: dt: add OMAP iommu bindings
Hi Laurent,
On 02/25/2014 03:26 PM, Laurent Pinchart wrote:
Hi Suman,
Thank you for the patch.
On Thursday 13 February 2014 12:15:34 Suman Anna wrote:
From: Florian Vaussard florian.vauss...@epfl.ch
This patch adds the iommu bindings for all OMAP2+ SoCs. Apart from
the standard bindings used by OMAP peripherals, this patch uses a
'dma-window' (already used by Tegra SMMU) and adds two OMAP custom
bindings - 'ti,#tlb-entries' and 'ti,iommu-bus-err-back'.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
[s-a...@ti.com: split bindings document, add dra7 and bus error back]
Signed-off-by: Suman Anna s-a...@ti.com
---
.../devicetree/bindings/iommu/ti,omap-iommu.txt| 28 +++
1 file changed, 28 insertions(+)
create mode 100644
Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt
diff --git a/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt
b/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt new file mode
100644
index 000..116492d
--- /dev/null
+++ b/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt
@@ -0,0 +1,28 @@
+OMAP2+ IOMMU
+
+Required properties:
+- compatible : Should be one of,
+ ti,omap2-iommu for OMAP2/OMAP3 IOMMU instances
+ ti,omap4-iommu for OMAP4/OMAP5 IOMMU instances
+ ti,dra7-iommu for DRA7xx IOMMU instances
+- ti,hwmods : Name of the hwmod associated with the IOMMU instance
+- reg: Address space for the configuration registers
+- interrupts : Interrupt specifier for the IOMMU instance
+- dma-window : IOVA start address and length
Isn't the dma window more of a system configuration property than a hardware
property ? How do you expect it to be set?
We are setting it based on the addressable range for the MMU. We are
reusing the existing defined property and it allows us to get rid of the
IOVA start and end addresses defined in the pre-DT OMAP iommu platform data.
+Optional properties:
+- ti,#tlb-entries : Number of entries in the translation look-aside buffer.
+Should be either 8 or 32 (default: 32)
+- ti,iommu-bus-err-back : Indicates the IOMMU instance supports throwing
+ back a bus error response on MMU faults.
Do these features vary per IOMMU instance or per IOMMU model ? In the latter
case they could be inferred from the compatible string by the driver without
requiring them to be explicit in DT (whether you want to do so is left to you
though).
Well, these are fixed features given an IOMMU instance, like the OMAP3
ISP is the only one that has 8 TLB entries, all the remaining ones have
32, and the IPU iommu instances are the only ones that support the bus
error response back. I have no preference to any particular way, and
sure the driver can infer these easily based on unique compatible
strings per subsystem per SoC. I just happened to go with defining
compatible strings per SoC, with the optional properties differentiating
the fixed behavior between different IOMMU instances on that SoC. This
is where I was looking for some inputs/guidance from the DT bindings
maintainers on what is the preferred method.
regards
Suman
+Example:
+ /* OMAP3 ISP MMU */
+ mmu_isp: mmu@480bd400 {
+ compatible = ti,omap2-iommu;
+ reg = 0x480bd400 0x80;
+ interrupts = 24;
+ ti,hwmods = mmu_isp;
+ ti,#tlb-entries = 8;
+ dma-window = 0 0xf000;
+ };
--
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
SD card timeout problems on Nokia N900 (omap_hsmmc on OMAP3)
Hi, I have problems with the SD-card initialization on my Nokia N900 using a 3.14-rc1 based kernel in DT boot mode. The bug is can be circumvented by changing the kernel slightly (e.g. remove some DT nodes or mark them as disabled). So the SD card's timeout problems seem to derive from kernel timing problems. I'm pretty sure, that the problems are not originating from a broken SD card, since 1. The SD card worked quite good before and still does depending on unrelated DTS changes (= loading less drivers). 2. The SD card works flawlessly on my notebook using a USB adapter 3. Another SD card showed the same problem I tried to git bisect the problem, but I just get shown some unrelated driver additions. Anyways, this is the error I get during boot: [3.896820] mmc0: mmc_rescan_try_freq: trying to init card at 40 Hz ... [5.956237] mmc0: error -110 whilst initialising SD card I added some debug prints to trace the error: * mmc_sd_init_card() * mmc_sd_get_cid() * mmc_send_app_op_cond() Can you give me any hints how to find fix the problem's source? -- Sebastian signature.asc Description: Digital signature
Re: [PATCH v2 0/2] ARM: OMAP4: Fix gpmc_fck clock
Florian, On 02/25/2014 02:10 AM, Florian Vaussard wrote: On 02/25/2014 07:26 AM, Mike Turquette wrote: Quoting Florian Vaussard (2014-02-23 21:44:25) On 02/23/2014 10:23 PM, Mike Turquette wrote: Quoting Florian Vaussard (2014-02-19 11:26:43) On 02/19/2014 05:22 PM, Tero Kristo wrote: On 02/19/2014 11:15 AM, Florian Vaussard wrote: Hello, Trying to get my SMSC9221 working on OMAP4 with DT, I faced a misconfigured gpmc_fck (dummy clock set to 0) resulting in serveral division-by-zero, misconfigured timings and driver lost in the La La Land. To solve this, patch 1 removes gpmc_fck from the dummy clocks, and patch 2 adds the gpmc_fck DT node and reference it from the gpmc node. Tested on DuoVero/Parlor (OMAP4430) with SMSC9221. I can't test GPMC myself, but other than that, this set looks good to go. Thank you. Would you like more test coverage by other people? I would like to see this in -rc if possible, as it is needed to boot my OMAP4 system. What OMAP4 system is this? Is this a regression for board that already has support merged into mainline? No, it is not yet merged into mainline. I was planning to post the DTS this week, when most issues are cleared. Looking at the current mainline boards, no one seems to use the GPMC, so I am just the first one to hit this issue. OK, well typically the later -rc's are for fixing observed regressions. Since your platform is not yet merged in then it's probably fine to push this for 3.15. Fair enough. 3.15 is fine. This also gives time to test the fix for other OMAP-ish processors. I can do the v3, including OMAP5 and DRA7. But for DRA7, I will need someone with the TRM telling me where is connected gpmc_fclk (Suman?). For DRA7, GPMC is connected off L3MAIN1_L3_GICLK (compared to L3MAIN2_L3_GICLK on OMAP5), both of which are actually just L3_ICLK. This is the l3_iclk_div in both the omap54xx-clocks.dtsi and dra7xx-clocks.dtsi files. regards Suman -- 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: [PATCHv2 02/16] iommu/omap: omap_iommu_attach() should return ENODEV, not NULL
Hi Suman,
On Tuesday 25 February 2014 16:32:03 Suman Anna wrote:
On 02/25/2014 03:13 PM, Laurent Pinchart wrote:
On Thursday 13 February 2014 12:15:33 Suman Anna wrote:
From: Florian Vaussard florian.vauss...@epfl.ch
omap_iommu_attach() returns NULL or ERR_PTR in case of error, but
omap_iommu_attach_dev() only checks for IS_ERR. Thus a NULL return value
(in case driver_find_device fails) will cause the kernel to panic when
omap_iommu_attach_dev() dereferences the pointer.
In such case, omap_iommu_attach() should return ENODEV, not NULL.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
Acked-by: Suman Anna s-a...@ti.com
---
drivers/iommu/omap-iommu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index fff2ffd..6272c36 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -863,7 +863,7 @@ static int device_match_by_alias(struct device *dev,
void *data) **/
static struct omap_iommu *omap_iommu_attach(const char *name, u32
*iopgd)
{
- int err = -ENOMEM;
+ int err = -ENODEV;
struct device *dev;
struct omap_iommu *obj;
@@ -871,7 +871,7 @@ static struct omap_iommu *omap_iommu_attach(const
char *name, u32 *iopgd)
(void *)name,
device_match_by_alias);
if (!dev)
- return NULL;
+ return ERR_PTR(err);
I would return ERR_PTR(-ENODEV) here, and remove the initialization at
declaration of err above.
The initialization at the beginning is also serving one another exit
path (a check for try_module_get), where err is not being set. If the
initialization is removed, then the err has to be set explicitly at the
other place. Let me know if you still want this changed.
The return value of iommu_enable() is unconditionally stored in err before the
try_module_get() call, so that code patch is buggy anyway and should be fixed.
I would still remove the initialization at declaration and assign -ENODEV to
err explicitly when try_module_get() fails before the goto err_module.
obj = to_iommu(dev);
--
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
Re: [PATCHv2 03/16] Documentation: dt: add OMAP iommu bindings
Hi Suman,
On Tuesday 25 February 2014 17:02:35 Suman Anna wrote:
On 02/25/2014 03:26 PM, Laurent Pinchart wrote:
On Thursday 13 February 2014 12:15:34 Suman Anna wrote:
From: Florian Vaussard florian.vauss...@epfl.ch
This patch adds the iommu bindings for all OMAP2+ SoCs. Apart from
the standard bindings used by OMAP peripherals, this patch uses a
'dma-window' (already used by Tegra SMMU) and adds two OMAP custom
bindings - 'ti,#tlb-entries' and 'ti,iommu-bus-err-back'.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
[s-a...@ti.com: split bindings document, add dra7 and bus error back]
Signed-off-by: Suman Anna s-a...@ti.com
---
.../devicetree/bindings/iommu/ti,omap-iommu.txt| 28
+++
1 file changed, 28 insertions(+)
create mode 100644
Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt
diff --git a/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt
b/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt new file mode
100644
index 000..116492d
--- /dev/null
+++ b/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt
@@ -0,0 +1,28 @@
+OMAP2+ IOMMU
+
+Required properties:
+- compatible : Should be one of,
+ ti,omap2-iommu for OMAP2/OMAP3 IOMMU instances
+ ti,omap4-iommu for OMAP4/OMAP5 IOMMU instances
+ ti,dra7-iommu for DRA7xx IOMMU instances
+- ti,hwmods : Name of the hwmod associated with the IOMMU instance
+- reg: Address space for the configuration registers
+- interrupts : Interrupt specifier for the IOMMU instance
+- dma-window : IOVA start address and length
Isn't the dma window more of a system configuration property than a
hardware property ? How do you expect it to be set?
We are setting it based on the addressable range for the MMU.
A quick look at the ISP and IVA IOMMUs in the OMAP3 shows that both support
the full 4GB VA space. Why do you need to restrict it ?
We are reusing the existing defined property and it allows us to get rid of
the IOVA start and end addresses defined in the pre-DT OMAP iommu platform
data.
+Optional properties:
+- ti,#tlb-entries : Number of entries in the translation look-aside
buffer. +Should be either 8 or 32 (default: 32)
+- ti,iommu-bus-err-back : Indicates the IOMMU instance supports throwing
+back a bus error response on MMU faults.
Do these features vary per IOMMU instance or per IOMMU model ? In the
latter case they could be inferred from the compatible string by the
driver without requiring them to be explicit in DT (whether you want to
do so is left to you though).
Well, these are fixed features given an IOMMU instance, like the OMAP3
ISP is the only one that has 8 TLB entries, all the remaining ones have
32, and the IPU iommu instances are the only ones that support the bus
error response back. I have no preference to any particular way, and
sure the driver can infer these easily based on unique compatible
strings per subsystem per SoC. I just happened to go with defining
compatible strings per SoC, with the optional properties differentiating
the fixed behavior between different IOMMU instances on that SoC. This
is where I was looking for some inputs/guidance from the DT bindings
maintainers on what is the preferred method.
I think you've made the right choice. I wasn't sure whether those parameters
varied across IOMMU instances of compatible devices (from a compatible string
point of view) or were constant. As they vary they should be expressed in DT.
+Example:
+ /* OMAP3 ISP MMU */
+ mmu_isp: mmu@480bd400 {
+ compatible = ti,omap2-iommu;
+ reg = 0x480bd400 0x80;
+ interrupts = 24;
+ ti,hwmods = mmu_isp;
+ ti,#tlb-entries = 8;
+ dma-window = 0 0xf000;
+ };
--
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
Re: [PATCH 3/4] power_supply: Introduce PSE compliant algorithm
On Fri, Feb 21, 2014 at 03:45:29PM +0100, Pavel Machek wrote: On Thu 2014-02-20 10:46:55, Jenny Tc wrote: On Tue, Feb 04, 2014 at 12:36:40PM +0100, Pavel Machek wrote: --- a/drivers/power/Kconfig +++ b/drivers/power/Kconfig @@ -22,6 +22,19 @@ config POWER_SUPPLY_CHARGER drivers to keep the charging logic outside and the charger driver just need to abstract the charger hardware. +config POWER_SUPPLY_CHARGING_ALGO_PSE + bool PSE compliant charging algorithm + help + Say Y here to select Product Safety Engineering (PSE) compliant + charging algorithm. As per PSE standard the battery characteristics + and thereby the charging rates can vary on different temperature + zones. This config will enable PSE compliant charging algorithm with + maintenance charging support. At runtime the algorithm will be + selected by the psy charger driver based on the type of the battery + charging profile. Information where to expect PSE compliant chargers would be nice. This algorithm can be used with non PSE compliant chargers also. This is a SW based charging algorithm. Ok, but you need to explain for the users when it might be good idea to select this option... Or maybe this should not be user configurable and drivers should just select it? The idea is to allow pluggable charging algorithms. Currently we have only one charging algorithm proposed, but can have other charging algorithms (like pulse charging, rule based charging etc.). Based on the platform need, the algorithms can be selected. So this should be a user configurable option. I can add more explanation on when to select this option. -- 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 V5 2/4] DRIVERS: IRQCHIP: CROSSBAR: Add support for Crossbar IP
Hi Tony, On Wednesday 05 February 2014 07:41 PM, Sricharan R wrote: Tony, On Wednesday 05 February 2014 06:41 PM, Sricharan R wrote: On Tuesday 04 February 2014 09:44 PM, Thomas Gleixner wrote: On Mon, 3 Feb 2014, Sricharan R wrote: I already have your reviewed-by tag for the first patch in this series. Kevin was pointing out that irqchip maintainer tag is needed for this patch as well to be merged. We are planning to take this series through arm-soc tree. Can i please have your tag for this patch as well ? Acked-by-me -- 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 Thanks Thomas. Kevin, I will re-send a branch based on rc1 for this. I have pushed a branch based on mainline, git://github.com/Sricharanti/sricharan.git branch: crossbar_3.14_rc1 Ping on this.. Regards, Sricharan -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/2] ARM: OMAP4: Fix gpmc_fck clock
Hi Suman, On 02/26/2014 01:05 AM, Suman Anna wrote: Florian, On 02/25/2014 02:10 AM, Florian Vaussard wrote: On 02/25/2014 07:26 AM, Mike Turquette wrote: Quoting Florian Vaussard (2014-02-23 21:44:25) On 02/23/2014 10:23 PM, Mike Turquette wrote: Quoting Florian Vaussard (2014-02-19 11:26:43) On 02/19/2014 05:22 PM, Tero Kristo wrote: On 02/19/2014 11:15 AM, Florian Vaussard wrote: Hello, Trying to get my SMSC9221 working on OMAP4 with DT, I faced a misconfigured gpmc_fck (dummy clock set to 0) resulting in serveral division-by-zero, misconfigured timings and driver lost in the La La Land. To solve this, patch 1 removes gpmc_fck from the dummy clocks, and patch 2 adds the gpmc_fck DT node and reference it from the gpmc node. Tested on DuoVero/Parlor (OMAP4430) with SMSC9221. I can't test GPMC myself, but other than that, this set looks good to go. Thank you. Would you like more test coverage by other people? I would like to see this in -rc if possible, as it is needed to boot my OMAP4 system. What OMAP4 system is this? Is this a regression for board that already has support merged into mainline? No, it is not yet merged into mainline. I was planning to post the DTS this week, when most issues are cleared. Looking at the current mainline boards, no one seems to use the GPMC, so I am just the first one to hit this issue. OK, well typically the later -rc's are for fixing observed regressions. Since your platform is not yet merged in then it's probably fine to push this for 3.15. Fair enough. 3.15 is fine. This also gives time to test the fix for other OMAP-ish processors. I can do the v3, including OMAP5 and DRA7. But for DRA7, I will need someone with the TRM telling me where is connected gpmc_fclk (Suman?). For DRA7, GPMC is connected off L3MAIN1_L3_GICLK (compared to L3MAIN2_L3_GICLK on OMAP5), both of which are actually just L3_ICLK. This is the l3_iclk_div in both the omap54xx-clocks.dtsi and dra7xx-clocks.dtsi files. Thank you very much. So I will send a v3 including this. Regards, Florian -- 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: SD card timeout problems on Nokia N900 (omap_hsmmc on OMAP3)
Hi Sebastian On Wed, Feb 26, 2014 at 12:47 AM, Sebastian Reichel s...@ring0.de wrote: Hi, I have problems with the SD-card initialization on my Nokia N900 using a 3.14-rc1 based kernel in DT boot mode. The bug is can be circumvented by changing the kernel slightly (e.g. remove some DT nodes or mark them as disabled). So the SD card's timeout problems seem to derive from kernel timing problems. I'm pretty sure, that the problems are not originating from a broken SD card, since 1. The SD card worked quite good before and still does depending on unrelated DTS changes (= loading less drivers). 2. The SD card works flawlessly on my notebook using a USB adapter 3. Another SD card showed the same problem I tried to git bisect the problem, but I just get shown some unrelated driver additions. Anyways, this is the error I get during boot: [3.896820] mmc0: mmc_rescan_try_freq: trying to init card at 40 Hz ... [5.956237] mmc0: error -110 whilst initialising SD card Are you sure that some subsystem that you deactivate don't change pin muxing setting? Can you check in the broken system if the pins of the sdcard are correctly muxed? Does it happen even if you change the sdcard? Michael I added some debug prints to trace the error: * mmc_sd_init_card() * mmc_sd_get_cid() * mmc_send_app_op_cond() Can you give me any hints how to find fix the problem's source? -- Sebastian -- 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: SD card timeout problems on Nokia N900 (omap_hsmmc on OMAP3)
Hi Sebastian, On 26.02.2014 07:02, Michael Trimarchi wrote: Hi Sebastian On Wed, Feb 26, 2014 at 12:47 AM, Sebastian Reichel s...@ring0.de wrote: Hi, I have problems with the SD-card initialization on my Nokia N900 using a 3.14-rc1 based kernel in DT boot mode. The bug is can be circumvented by changing the kernel slightly (e.g. remove some DT nodes or mark them as disabled). So the SD card's timeout problems seem to derive from kernel timing problems. I'm pretty sure, that the problems are not originating from a broken SD card, since 1. The SD card worked quite good before and still does depending on unrelated DTS changes (= loading less drivers). 2. The SD card works flawlessly on my notebook using a USB adapter 3. Another SD card showed the same problem I tried to git bisect the problem, but I just get shown some unrelated driver additions. Anyways, this is the error I get during boot: [3.896820] mmc0: mmc_rescan_try_freq: trying to init card at 40 Hz ... [5.956237] mmc0: error -110 whilst initialising SD card Are you sure that some subsystem that you deactivate don't change pin muxing setting? Can you check in the broken system if the pins of the sdcard are correctly muxed? Does it happen even if you change the sdcard? Did you try to add this patch series: http://www.spinics.net/lists/linux-omap/msg103264.html Without it I'm also having problems with MMC detection on some OMAP3 based boards. Balaji, what is the status of this patch series? Are there any chances that it will be included in v3.14? Thanks, Stefan -- 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: TWL6040 fails to initialize
On 02/25/2014 05:41 PM, Florian Vaussard wrote: If the power was not enabled at all, I would be unable to read the revision register, no? And delaying the probe by one millisecond would be of no help in this case IMHO. One thing which might cause this is that if the audpwron GPIO is set high before the twl6040 module is probing. When I request the GPIO I ask it to be set to low. If the line was high before this means we initiate the power off sequence. Can you try something like this: diff --git a/drivers/mfd/twl6040.c b/drivers/mfd/twl6040.c index 75316fb33448..d2a0bd1539ae 100644 --- a/drivers/mfd/twl6040.c +++ b/drivers/mfd/twl6040.c @@ -674,6 +674,9 @@ static int twl6040_probe(struct i2c_client *client, GPIOF_OUT_INIT_LOW, audpwron); if (ret) goto gpio_err; + + /* power-down sequence latency */ + usleep_range(500, 700); } ret = regmap_add_irq_chip(twl6040-regmap, twl6040-irq, IRQF_ONESHOT, -- Péter -- 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
