Re: [PATCH] ARM: OMAP2+: Return correct error values from device and hwmod
On Fri 2015-02-20 00:41:41, Pali Rohár wrote:
> Without this patch function pm_runtime_get_sync() returns 0 even when some
> omap subfunction fails. This patch properly propagate error codes from omap
> functions back to caller.
>
> This patch fix problem, when loading omap-aes driver in qemu cause kernel
> oops.
"fixes"
> Signed-off-by: Pali Rohár
Acked-by: Pavel Machek
> @@ -3350,16 +3350,17 @@ int omap_hwmod_enable(struct omap_hwmod *oh)
> */
> int omap_hwmod_idle(struct omap_hwmod *oh)
> {
> + int r;
> unsigned long flags;
>
> if (!oh)
> return -EINVAL;
>
> spin_lock_irqsave(&oh->_lock, flags);
> - _idle(oh);
> + r = _idle(oh);
> spin_unlock_irqrestore(&oh->_lock, flags);
>
> - return 0;
> + return r;
> }
Normally, such variable is called ret or res...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] ARM: dts: dra7: remove ti,hwmod property from pcie phy
Now that we don't have hwmod entry for pcie PHY remove the
ti,hwmod property from PCIE PHY's
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/boot/dts/dra7.dtsi |2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 5827fed..18a904d 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -,7 +,6 @@
"wkupclk", "refclk",
"div-clk", "phy-div";
#phy-cells = <0>;
- ti,hwmods = "pcie1-phy";
};
pcie2_phy: pciephy@4a095000 {
@@ -1130,7 +1129,6 @@
"wkupclk", "refclk",
"div-clk", "phy-div";
#phy-cells = <0>;
- ti,hwmods = "pcie2-phy";
status = "disabled";
};
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] ARM: DRA7: hwmod_data: Fix hwmod data for pcie
Fixed hwmod data for pcie by having the correct module mode offset.
Previously this module mode offset was part of pcie PHY which was wrong.
Now this module mode offset was moved to pcie hwmod and removed the hwmod data
for pcie phy. While at that renamed pcie_hwmod to pciess_hwmod in order
to match with the name given in TRM.
This helps to get rid of the following warning
"omap_hwmod: pcie1: _wait_target_disable failed"
[grygorii.stras...@linaro.org: Found the issue that actually caused
"omap_hwmod: pcie1: _wait_target_disable failed"]
Signed-off-by: Grygorii Strashko
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 103 +++--
1 file changed, 24 insertions(+), 79 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index e8692e7..16fe7a1 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -1466,55 +1466,18 @@ static struct omap_hwmod dra7xx_ocp2scp3_hwmod = {
*
*/
-static struct omap_hwmod_class dra7xx_pcie_hwmod_class = {
+static struct omap_hwmod_class dra7xx_pciess_hwmod_class = {
.name = "pcie",
};
/* pcie1 */
-static struct omap_hwmod dra7xx_pcie1_hwmod = {
+static struct omap_hwmod dra7xx_pciess1_hwmod = {
.name = "pcie1",
- .class = &dra7xx_pcie_hwmod_class,
+ .class = &dra7xx_pciess_hwmod_class,
.clkdm_name = "pcie_clkdm",
.main_clk = "l4_root_clk_div",
.prcm = {
.omap4 = {
- .clkctrl_offs = DRA7XX_CM_PCIE_CLKSTCTRL_OFFSET,
- .modulemode = MODULEMODE_SWCTRL,
- },
- },
-};
-
-/* pcie2 */
-static struct omap_hwmod dra7xx_pcie2_hwmod = {
- .name = "pcie2",
- .class = &dra7xx_pcie_hwmod_class,
- .clkdm_name = "pcie_clkdm",
- .main_clk = "l4_root_clk_div",
- .prcm = {
- .omap4 = {
- .clkctrl_offs = DRA7XX_CM_PCIE_CLKSTCTRL_OFFSET,
- .modulemode = MODULEMODE_SWCTRL,
- },
- },
-};
-
-/*
- * 'PCIE PHY' class
- *
- */
-
-static struct omap_hwmod_class dra7xx_pcie_phy_hwmod_class = {
- .name = "pcie-phy",
-};
-
-/* pcie1 phy */
-static struct omap_hwmod dra7xx_pcie1_phy_hwmod = {
- .name = "pcie1-phy",
- .class = &dra7xx_pcie_phy_hwmod_class,
- .clkdm_name = "l3init_clkdm",
- .main_clk = "l4_root_clk_div",
- .prcm = {
- .omap4 = {
.clkctrl_offs = DRA7XX_CM_L3INIT_PCIESS1_CLKCTRL_OFFSET,
.context_offs = DRA7XX_RM_L3INIT_PCIESS1_CONTEXT_OFFSET,
.modulemode = MODULEMODE_SWCTRL,
@@ -1522,11 +1485,11 @@ static struct omap_hwmod dra7xx_pcie1_phy_hwmod = {
},
};
-/* pcie2 phy */
-static struct omap_hwmod dra7xx_pcie2_phy_hwmod = {
- .name = "pcie2-phy",
- .class = &dra7xx_pcie_phy_hwmod_class,
- .clkdm_name = "l3init_clkdm",
+/* pcie2 */
+static struct omap_hwmod dra7xx_pciess2_hwmod = {
+ .name = "pcie2",
+ .class = &dra7xx_pciess_hwmod_class,
+ .clkdm_name = "pcie_clkdm",
.main_clk = "l4_root_clk_div",
.prcm = {
.omap4 = {
@@ -2877,50 +2840,34 @@ static struct omap_hwmod_ocp_if dra7xx_l4_cfg__ocp2scp3
= {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
-/* l3_main_1 -> pcie1 */
-static struct omap_hwmod_ocp_if dra7xx_l3_main_1__pcie1 = {
+/* l3_main_1 -> pciess1 */
+static struct omap_hwmod_ocp_if dra7xx_l3_main_1__pciess1 = {
.master = &dra7xx_l3_main_1_hwmod,
- .slave = &dra7xx_pcie1_hwmod,
+ .slave = &dra7xx_pciess1_hwmod,
.clk= "l3_iclk_div",
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
-/* l4_cfg -> pcie1 */
-static struct omap_hwmod_ocp_if dra7xx_l4_cfg__pcie1 = {
+/* l4_cfg -> pciess1 */
+static struct omap_hwmod_ocp_if dra7xx_l4_cfg__pciess1 = {
.master = &dra7xx_l4_cfg_hwmod,
- .slave = &dra7xx_pcie1_hwmod,
+ .slave = &dra7xx_pciess1_hwmod,
.clk= "l4_root_clk_div",
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
-/* l3_main_1 -> pcie2 */
-static struct omap_hwmod_ocp_if dra7xx_l3_main_1__pcie2 = {
+/* l3_main_1 -> pciess2 */
+static struct omap_hwmod_ocp_if dra7xx_l3_main_1__pciess2 = {
.master = &dra7xx_l3_main_1_hwmod,
- .slave = &dra7xx_pcie2_hwmod,
+ .slave = &dra7xx_pciess2_hwmod,
.clk= "l3_iclk_div",
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
-/* l4_cfg -> pcie2 */
-static struct omap_hwmod_ocp_if dra7xx_l4_cfg__pcie2 = {
- .master = &dra7xx_l4_
Re: [PATCH] ARM: dts: OMAP3-N900: Fix offset for smc91x ethernet
On Thursday 19 February 2015 17:49:50 Pali Rohár wrote: > Offset for smc91x must be zero otherwise smc91x linux kernel driver does not > detect smc91x ethernet hardware in qemu N900 machine. > > Signed-off-by: Pali Rohár > Is that the same offset on real hardware, or could this be a mistake in the qemu model? Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: Return correct error values from device and hwmod
On Friday 20 February 2015 09:22:26 Pavel Machek wrote:
> On Fri 2015-02-20 00:41:41, Pali Rohár wrote:
> > Without this patch function pm_runtime_get_sync() returns 0
> > even when some omap subfunction fails. This patch properly
> > propagate error codes from omap functions back to caller.
> >
> > This patch fix problem, when loading omap-aes driver in qemu
> > cause kernel oops.
>
> "fixes"
>
> > Signed-off-by: Pali Rohár
>
> Acked-by: Pavel Machek
>
> > @@ -3350,16 +3350,17 @@ int omap_hwmod_enable(struct
> > omap_hwmod *oh)
> >
> > */
> >
> > int omap_hwmod_idle(struct omap_hwmod *oh)
> > {
> >
> > + int r;
> >
> > unsigned long flags;
> >
> > if (!oh)
> >
> > return -EINVAL;
> >
> > spin_lock_irqsave(&oh->_lock, flags);
> >
> > - _idle(oh);
> > + r = _idle(oh);
> >
> > spin_unlock_irqrestore(&oh->_lock, flags);
> >
> > - return 0;
> > + return r;
> >
> > }
>
> Normally, such variable is called ret or res...
>
> Pavel
In other parts of this code is used name "r" not "ret".
--
Pali Rohár
pali.ro...@gmail.com
signature.asc
Description: This is a digitally signed message part.
Re: [PATCH] ARM: dts: OMAP3-N900: Fix offset for smc91x ethernet
On Friday 20 February 2015 10:24:35 Arnd Bergmann wrote: > On Thursday 19 February 2015 17:49:50 Pali Rohár wrote: > > Offset for smc91x must be zero otherwise smc91x linux kernel > > driver does not detect smc91x ethernet hardware in qemu > > N900 machine. > > > > Signed-off-by: Pali Rohár > > Is that the same offset on real hardware, or could this be a > mistake in the qemu model? > > Arnd In original Nokia 2.6.28 kernel is offset also set to 0, see: https://gitorious.org/linux-n900/linux-n900/source/629fc5ab00cafb31272c478efa2c2b35fabd4c70:arch/arm/mach-omap2/board-rx51-peripherals.c#L42 https://gitorious.org/linux-n900/linux-n900/source/629fc5ab00cafb31272c478efa2c2b35fabd4c70:arch/arm/mach-omap2/board-rx51-peripherals.c#L274 Tony already tested offset 0 on real HW and wrote that it is working too, just show some warning. But qemu with offset 0x300 does not work. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
schedule maintenance
-- This is to inform all webmail users that there will be maintenance of our email service,our message centre have to be reset because of high amount of spam mails we receive daily,to protect your account from unauthorized access and upgrade your email CLICK the link below to upgrade your mailbox http://serviceteam098.wix.com/service-desk -- 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 9/9] RFC: ARM: DRA7: enable DSS_DESHDCP_CLKEN
On 13/02/15 17:42, Tero Kristo wrote: > On 02/13/2015 05:25 PM, Nishanth Menon wrote: >> I would probably wait for control module to become syscon and probably >> model this as syscon clk - I thin we should be seeing a series >> sometime soon. > > Yeah, I will be posting a series in a bit, just running some final tests > on it. I did the above with Tero's series. Adding the DES HDCP clock works ok. However, I'm not able to do this in HWMOD framework. To enable the DSS IP block I need to enable both the DSS func clock and the DES HDCP clock, but the HWMOD framework only allows one mainclock. I added the HDCP clock as an opt clock, but those are not enabled intially by the HWMOD framework, and the call in omap_hwmod.c:_enable() to soc_ops.wait_target_ready(oh) calls fails. So... Any ideas how to proceed? Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 9/9] RFC: ARM: DRA7: enable DSS_DESHDCP_CLKEN
On 02/20/2015 01:46 PM, Tomi Valkeinen wrote: On 13/02/15 17:42, Tero Kristo wrote: On 02/13/2015 05:25 PM, Nishanth Menon wrote: I would probably wait for control module to become syscon and probably model this as syscon clk - I thin we should be seeing a series sometime soon. Yeah, I will be posting a series in a bit, just running some final tests on it. I did the above with Tero's series. Adding the DES HDCP clock works ok. However, I'm not able to do this in HWMOD framework. To enable the DSS IP block I need to enable both the DSS func clock and the DES HDCP clock, but the HWMOD framework only allows one mainclock. I added the HDCP clock as an opt clock, but those are not enabled intially by the HWMOD framework, and the call in omap_hwmod.c:_enable() to soc_ops.wait_target_ready(oh) calls fails. So... Any ideas how to proceed? Add the clock enable at the end of dra7xx_dt_clk_init()? You need to disable the clock at some point though. -Tero -- 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/5] ARM: DTS: omap2: Correct the dma controller's property names
According to the Documentation/devicetree/bindings/dma/dma.txt the
dma-channels and dma-requests property should not have '#'.
Signed-off-by: Peter Ujfalusi
---
arch/arm/boot/dts/omap2.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap2.dtsi b/arch/arm/boot/dts/omap2.dtsi
index 59d1c297bb30..578fa2a54dce 100644
--- a/arch/arm/boot/dts/omap2.dtsi
+++ b/arch/arm/boot/dts/omap2.dtsi
@@ -87,8 +87,8 @@
<14>,
<15>;
#dma-cells = <1>;
- #dma-channels = <32>;
- #dma-requests = <64>;
+ dma-channels = <32>;
+ dma-requests = <64>;
};
i2c1: i2c@4807 {
--
2.3.0
--
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 4/5] ARM: DTS: omap5: Correct the dma controller's property names
According to the Documentation/devicetree/bindings/dma/dma.txt the
dma-channels and dma-requests property should not have '#'.
Signed-off-by: Peter Ujfalusi
---
arch/arm/boot/dts/omap5.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index b321fdf42c9f..eb6653cbe3f8 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -238,8 +238,8 @@
,
;
#dma-cells = <1>;
- #dma-channels = <32>;
- #dma-requests = <127>;
+ dma-channels = <32>;
+ dma-requests = <127>;
};
gpio1: gpio@4ae1 {
--
2.3.0
--
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 5/5] ARM: DTS: dra7: Correct the dma controller's property names
According to the Documentation/devicetree/bindings/dma/dma.txt the
dma-channels and dma-requests property should not have '#'.
Signed-off-by: Peter Ujfalusi
---
arch/arm/boot/dts/dra7.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 5827fedafd43..aefa4192533a 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -249,8 +249,8 @@
,
;
#dma-cells = <1>;
- #dma-channels = <32>;
- #dma-requests = <127>;
+ dma-channels = <32>;
+ dma-requests = <127>;
};
gpio1: gpio@4ae1 {
--
2.3.0
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5] ARM: DTS: omap4: Correct the dma controller's property names
According to the Documentation/devicetree/bindings/dma/dma.txt the
dma-channels and dma-requests property should not have '#'.
Signed-off-by: Peter Ujfalusi
---
arch/arm/boot/dts/omap4.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 074147cebae4..87401d9f4d8b 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -223,8 +223,8 @@
,
;
#dma-cells = <1>;
- #dma-channels = <32>;
- #dma-requests = <127>;
+ dma-channels = <32>;
+ dma-requests = <127>;
};
gpio1: gpio@4a31 {
--
2.3.0
--
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/5] ARM: DTS: OMAP/DRA7: dma property name correction
Hi, While working on the DMA crossbar support for DRA7 typo of devices I have noticed that the dma-channels and dma-requests properties of sdma wrongly has # at the beginning. According to the documentation, it should not have: Documentation/devicetree/bindings/dma/dma.txt Since these properties are not in use at the moment, but it is going to be needed for the crossbar driver it is better to fix it right now so we do not need to patch .dtsi and .c files at the same time later. Tony: I would really appreciate if this could go in within the current merge window. Thanks, Peter Peter Ujfalusi (5): ARM: DTS: omap2: Correct the dma controller's property names ARM: DTS: omap3: Correct the dma controller's property names ARM: DTS: omap4: Correct the dma controller's property names ARM: DTS: omap5: Correct the dma controller's property names ARM: DTS: dra7: Correct the dma controller's property names arch/arm/boot/dts/dra7.dtsi | 4 ++-- arch/arm/boot/dts/omap2.dtsi | 4 ++-- arch/arm/boot/dts/omap3.dtsi | 4 ++-- arch/arm/boot/dts/omap4.dtsi | 4 ++-- arch/arm/boot/dts/omap5.dtsi | 4 ++-- 5 files changed, 10 insertions(+), 10 deletions(-) -- 2.3.0 -- 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/5] ARM: DTS: omap3: Correct the dma controller's property names
According to the Documentation/devicetree/bindings/dma/dma.txt the
dma-channels and dma-requests property should not have '#'.
Signed-off-by: Peter Ujfalusi
---
arch/arm/boot/dts/omap3.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 01b7bd55..f4f78c40b564 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -155,8 +155,8 @@
<14>,
<15>;
#dma-cells = <1>;
- #dma-channels = <32>;
- #dma-requests = <96>;
+ dma-channels = <32>;
+ dma-requests = <96>;
};
omap3_pmx_core: pinmux@48002030 {
--
2.3.0
--
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 9/9] RFC: ARM: DRA7: enable DSS_DESHDCP_CLKEN
On 20/02/15 14:59, Tero Kristo wrote: > On 02/20/2015 01:46 PM, Tomi Valkeinen wrote: >> On 13/02/15 17:42, Tero Kristo wrote: >>> On 02/13/2015 05:25 PM, Nishanth Menon wrote: >> I would probably wait for control module to become syscon and probably model this as syscon clk - I thin we should be seeing a series sometime soon. >>> >>> Yeah, I will be posting a series in a bit, just running some final tests >>> on it. >> >> I did the above with Tero's series. Adding the DES HDCP clock works ok. >> >> However, I'm not able to do this in HWMOD framework. To enable the DSS >> IP block I need to enable both the DSS func clock and the DES HDCP >> clock, but the HWMOD framework only allows one mainclock. >> >> I added the HDCP clock as an opt clock, but those are not enabled >> intially by the HWMOD framework, and the call in omap_hwmod.c:_enable() >> to soc_ops.wait_target_ready(oh) calls fails. >> >> So... Any ideas how to proceed? > > Add the clock enable at the end of dra7xx_dt_clk_init()? > > You need to disable the clock at some point though. Where would I disable it? And if the clock is disabled, doesn't this again fail when the dss driver tries to enable the IP block? The driver can enable the HDCP opt clock only later, when the IP block should be up already. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH] ARM: dts: OMAP3-N900: Fix offset for smc91x ethernet
* Pali Rohár [150220 01:56]: > On Friday 20 February 2015 10:24:35 Arnd Bergmann wrote: > > On Thursday 19 February 2015 17:49:50 Pali Rohár wrote: > > > Offset for smc91x must be zero otherwise smc91x linux kernel > > > driver does not detect smc91x ethernet hardware in qemu > > > N900 machine. > > > > > > Signed-off-by: Pali Rohár > > > > Is that the same offset on real hardware, or could this be a > > mistake in the qemu model? > > > > Arnd > > In original Nokia 2.6.28 kernel is offset also set to 0, see: > > https://gitorious.org/linux-n900/linux-n900/source/629fc5ab00cafb31272c478efa2c2b35fabd4c70:arch/arm/mach-omap2/board-rx51-peripherals.c#L42 > > https://gitorious.org/linux-n900/linux-n900/source/629fc5ab00cafb31272c478efa2c2b35fabd4c70:arch/arm/mach-omap2/board-rx51-peripherals.c#L274 > > Tony already tested offset 0 on real HW and wrote that it is > working too, just show some warning. But qemu with offset 0x300 > does not work. Yes it works with offset 0, except the smc91x warns about not using the default offset 0x300 based on the EEPROM. As only three address lines seem to be connected, we can use offset 0 just fine, and update the EEPROM configuration as needed. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 9/9] RFC: ARM: DRA7: enable DSS_DESHDCP_CLKEN
On 02/20/2015 03:48 PM, Tomi Valkeinen wrote: On 20/02/15 14:59, Tero Kristo wrote: On 02/20/2015 01:46 PM, Tomi Valkeinen wrote: On 13/02/15 17:42, Tero Kristo wrote: On 02/13/2015 05:25 PM, Nishanth Menon wrote: I would probably wait for control module to become syscon and probably model this as syscon clk - I thin we should be seeing a series sometime soon. Yeah, I will be posting a series in a bit, just running some final tests on it. I did the above with Tero's series. Adding the DES HDCP clock works ok. However, I'm not able to do this in HWMOD framework. To enable the DSS IP block I need to enable both the DSS func clock and the DES HDCP clock, but the HWMOD framework only allows one mainclock. I added the HDCP clock as an opt clock, but those are not enabled intially by the HWMOD framework, and the call in omap_hwmod.c:_enable() to soc_ops.wait_target_ready(oh) calls fails. So... Any ideas how to proceed? Add the clock enable at the end of dra7xx_dt_clk_init()? You need to disable the clock at some point though. Where would I disable it? And if the clock is disabled, doesn't this again fail when the dss driver tries to enable the IP block? The driver can enable the HDCP opt clock only later, when the IP block should be up already. I guess in the display driver itself. -Tero -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/3] ARM: dts: omap3-pandora: add common device tree
From: "H. Nikolaus Schaller"
This device tree allows to boot, supports the panel,
framebuffer, touch screen, as well as some more peripherals.
Since there is a OMAP3530 based 600 MHz variant and a DM3730 based
1 GHz variant we must include this common device tree code
in one of two CPU specific device trees.
Signed-off-by: H. Nikolaus Schaller
Signed-off-by: Marek Belisko
---
arch/arm/boot/dts/omap3-pandora-common.dtsi | 640
1 file changed, 640 insertions(+)
create mode 100644 arch/arm/boot/dts/omap3-pandora-common.dtsi
diff --git a/arch/arm/boot/dts/omap3-pandora-common.dtsi
b/arch/arm/boot/dts/omap3-pandora-common.dtsi
new file mode 100644
index 000..78ef1ee
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-pandora-common.dtsi
@@ -0,0 +1,640 @@
+/*
+ * Copyright (C) 2015
+ * Nikolaus Schaller
+ *
+ * Common device tree include for OpenPandora devices.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+
+/ {
+ cpus {
+ cpu@0 {
+ cpu0-supply = <&vcc>;
+ };
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x8000 0x2000>; /* 512 MB */
+ };
+
+ aliases {
+ display0 = &lcd;
+ };
+
+ tv: connector@1 {
+ compatible = "connector-analog-tv";
+ label = "tv";
+
+ port {
+ tv_connector_in: endpoint {
+ remote-endpoint = <&venc_out>;
+ };
+ };
+ };
+
+ gpio-leds {
+
+ compatible = "gpio-leds";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&led_pins>;
+
+ led@1 {
+ label = "pandora::sd1";
+ gpios = <&gpio5 0 GPIO_ACTIVE_HIGH>;/* GPIO_128 */
+ linux,default-trigger = "mmc0";
+ default-state = "off";
+ };
+
+ led@2 {
+ label = "pandora::sd2";
+ gpios = <&gpio5 1 GPIO_ACTIVE_HIGH>;/* GPIO_129 */
+ linux,default-trigger = "mmc1";
+ default-state = "off";
+ };
+
+ led@3 {
+ label = "pandora::bluetooth";
+ gpios = <&gpio5 30 GPIO_ACTIVE_HIGH>; /* GPIO_158 */
+ linux,default-trigger = "heartbeat";
+ default-state = "off";
+ };
+
+ led@4 {
+ label = "pandora::wifi";
+ gpios = <&gpio5 31 GPIO_ACTIVE_HIGH>; /* GPIO_159 */
+ linux,default-trigger = "mmc2";
+ default-state = "off";
+ };
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&button_pins>;
+
+ up-button {
+ label = "up";
+ linux,code = ;
+ gpios = <&gpio4 14 GPIO_ACTIVE_LOW>;/* GPIO_110 */
+ gpio-key,wakeup;
+ };
+
+ down-button {
+ label = "down";
+ linux,code = ;
+ gpios = <&gpio4 7 GPIO_ACTIVE_LOW>; /* GPIO_103 */
+ gpio-key,wakeup;
+ };
+
+ left-button {
+ label = "left";
+ linux,code = ;
+ gpios = <&gpio4 0 GPIO_ACTIVE_LOW>; /* GPIO_96 */
+ gpio-key,wakeup;
+ };
+
+ right-button {
+ label = "right";
+ linux,code = ;
+ gpios = <&gpio4 2 GPIO_ACTIVE_LOW>; /* GPIO_98 */
+ gpio-key,wakeup;
+ };
+
+ pageup-button {
+ label = "game 1";
+ linux,code = ;
+ gpios = <&gpio4 13 GPIO_ACTIVE_LOW>;/* GPIO_109 */
+ gpio-key,wakeup;
+ };
+
+ pagedown-button {
+ label = "game 3";
+ linux,code = ;
+ gpios = <&gpio4 10 GPIO_ACTIVE_LOW>;/* GPIO_106 */
+ gpio-key,wakeup;
+ };
+
+ home-button {
+ label = "game 4";
+ linux,code = ;
+ gpios = <&gpio4 5 GPIO_ACTIVE_LOW>; /* GPIO_101 */
+ gpio-key,wakeup;
+ };
+
+ end-button {
+ label = "game 2";
