Hi,
Exynos chipsets since 542x have asynchronous bridges connecting different IPs.
These bridges should be operational during power domain switching, ie associated
clocks cannot be gated.
This patchset adds binding to provide such clocks per power domain and adds code
which enables them during domain on/off operation.
This patchset fixes power domain issues with disp1 domain and HDMI (some of them)
on Odroid XU3:
- disp1 power domain can be turned off,
- no more "imprecise external abort" faults.
The patchset is based on '[PATCH v5 0/9] Enable HDMI support on Exynos platforms' [1].
It was successfully tested on OdroidXU3.
[1]: http://permalink.gmane.org/gmane.linux.kernel.samsung-soc/42743
Regards
Andrzej
Andrzej Hajda (3):
arm/exynos: add asynchronous bridge clock bindings
arm/exynos/pm_domains: add support for async-bridge clocks
ARM: dts: exynos5420: add async-bridge clock to disp1 power domain
.../bindings/arm/exynos/power_domain.txt | 3 +++
arch/arm/boot/dts/exynos5420.dtsi | 6 +++--
arch/arm/mach-exynos/pm_domains.c | 27 ++++++++++++++++++----
3 files changed, 30 insertions(+), 6 deletions(-)
--
1.9.1
The patch adds bindings for clocks required by async-bridges
present in the particular power domain.
Signed-off-by: Andrzej Hajda <[email protected]>
---
Documentation/devicetree/bindings/arm/exynos/power_domain.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
index 1e09703..5da38c5 100644
--- a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
+++ b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
@@ -22,6 +22,9 @@ Optional Properties:
- pclkN, clkN: Pairs of parent of input clock and input clock to the
devices in this power domain. Maximum of 4 pairs (N = 0 to 3)
are supported currently.
+ - asbN: Clocks required by asynchronous bridges (ASB) present in
+ the power domain. These clock should be enabled during power
+ domain on/off operations.
- power-domains: phandle pointing to the parent power domain, for more details
see Documentation/devicetree/bindings/power/power_domain.txt
--
1.9.1
Since Exynos5420 there are async-bridges (ASB) between different IPs. These
bridges must be operational during power domain on/off, ie. clocks used
by these bridges should be enabled.
This patch enabled these clocks during domain on/off.
Signed-off-by: Andrzej Hajda <[email protected]>
---
arch/arm/mach-exynos/pm_domains.c | 27 +++++++++++++++++++++++----
1 file changed, 23 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-exynos/pm_domains.c b/arch/arm/mach-exynos/pm_domains.c
index 0e2bc36..ecff522 100644
--- a/arch/arm/mach-exynos/pm_domains.c
+++ b/arch/arm/mach-exynos/pm_domains.c
@@ -37,6 +37,7 @@ struct exynos_pm_domain {
struct clk *oscclk;
struct clk *clk[MAX_CLK_PER_DOMAIN];
struct clk *pclk[MAX_CLK_PER_DOMAIN];
+ struct clk *asb_clk[MAX_CLK_PER_DOMAIN];
};
static int exynos_pd_power(struct generic_pm_domain *domain, bool power_on)
@@ -45,14 +46,19 @@ static int exynos_pd_power(struct generic_pm_domain *domain, bool power_on)
void __iomem *base;
u32 timeout, pwr;
char *op;
+ int i;
pd = container_of(domain, struct exynos_pm_domain, pd);
base = pd->base;
+ for (i = 0; i < MAX_CLK_PER_DOMAIN; i++) {
+ if (IS_ERR(pd->asb_clk[i]))
+ break;
+ clk_prepare_enable(pd->asb_clk[i]);
+ }
+
/* Set oscclk before powering off a domain*/
if (!power_on) {
- int i;
-
for (i = 0; i < MAX_CLK_PER_DOMAIN; i++) {
if (IS_ERR(pd->clk[i]))
break;
@@ -81,8 +87,6 @@ static int exynos_pd_power(struct generic_pm_domain *domain, bool power_on)
/* Restore clocks after powering on a domain*/
if (power_on) {
- int i;
-
for (i = 0; i < MAX_CLK_PER_DOMAIN; i++) {
if (IS_ERR(pd->clk[i]))
break;
@@ -92,6 +96,12 @@ static int exynos_pd_power(struct generic_pm_domain *domain, bool power_on)
}
}
+ for (i = 0; i < MAX_CLK_PER_DOMAIN; i++) {
+ if (IS_ERR(pd->asb_clk[i]))
+ break;
+ clk_disable_unprepare(pd->asb_clk[i]);
+ }
+
return 0;
}
@@ -137,6 +147,15 @@ static __init int exynos4_pm_init_power_domain(void)
pd->pd.power_off = exynos_pd_power_off;
pd->pd.power_on = exynos_pd_power_on;
+ for (i = 0; i < MAX_CLK_PER_DOMAIN; i++) {
+ char clk_name[8];
+
+ snprintf(clk_name, sizeof(clk_name), "asb%d", i);
+ pd->asb_clk[i] = clk_get(dev, clk_name);
+ if (IS_ERR(pd->asb_clk[i]))
+ break;
+ }
+
pd->oscclk = clk_get(dev, "oscclk");
if (IS_ERR(pd->oscclk))
goto no_clk;
--
1.9.1
disp1 power domain requires operational async-bridge associated with HDMI,
ie its clock should be enabled during power on/off.
This patch fixes broken Odroid XU3 HDMI support.
Signed-off-by: Andrzej Hajda <[email protected]>
---
arch/arm/boot/dts/exynos5420.dtsi | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5420.dtsi b/arch/arm/boot/dts/exynos5420.dtsi
index b8f1c9f..13191fe 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -285,9 +285,11 @@
<&clock CLK_MOUT_SW_ACLK300>,
<&clock CLK_MOUT_USER_ACLK300_DISP1>,
<&clock CLK_MOUT_SW_ACLK400>,
- <&clock CLK_MOUT_USER_ACLK400_DISP1>;
+ <&clock CLK_MOUT_USER_ACLK400_DISP1>,
+ <&clock CLK_HDMI>;
clock-names = "oscclk", "pclk0", "clk0",
- "pclk1", "clk1", "pclk2", "clk2";
+ "pclk1", "clk1", "pclk2", "clk2",
+ "asb0";
};
pinctrl_0: pinctrl@13400000 {
--
1.9.1
Hello Andrzej,
Thanks a lot for finally finding what was causing the HDMI issue.
On 02/05/2015 01:35 PM, Andrzej Hajda wrote:
> Hi,
>
> Exynos chipsets since 542x have asynchronous bridges connecting different IPs.
> These bridges should be operational during power domain switching, ie associated
> clocks cannot be gated.
> This patchset adds binding to provide such clocks per power domain and adds code
> which enables them during domain on/off operation.
>
> This patchset fixes power domain issues with disp1 domain and HDMI (some of them)
> on Odroid XU3:
> - disp1 power domain can be turned off,
> - no more "imprecise external abort" faults.
>
> The patchset is based on '[PATCH v5 0/9] Enable HDMI support on Exynos platforms' [1].
>
It also depends on '[PATCH 0/2] Add HDMI support for Exynos5420 platform' [2].
> It was successfully tested on OdroidXU3.
>
> [1]: http://permalink.gmane.org/gmane.linux.kernel.samsung-soc/42743
Your patches looks good to me so please feel free to add:
Reviewed-by: Javier Martinez Canillas <[email protected]>
I also tested on an Exynos5420 Peach Pit Chromebook and both the "Power
domain power-domain disable failed" message and the system crash are gone.
Tested-by: Javier Martinez Canillas <[email protected]>
Best regards,
Javier
[2]: https://lkml.org/lkml/2015/1/20/235
Hi,
On 02/05/2015 11:45 PM, Javier Martinez Canillas wrote:
> Hello Andrzej,
>
> Thanks a lot for finally finding what was causing the HDMI issue.
>
> On 02/05/2015 01:35 PM, Andrzej Hajda wrote:
>> Hi,
>>
>> Exynos chipsets since 542x have asynchronous bridges connecting different IPs.
>> These bridges should be operational during power domain switching, ie associated
>> clocks cannot be gated.
>> This patchset adds binding to provide such clocks per power domain and adds code
>> which enables them during domain on/off operation.
>>
>> This patchset fixes power domain issues with disp1 domain and HDMI (some of them)
>> on Odroid XU3:
>> - disp1 power domain can be turned off,
>> - no more "imprecise external abort" faults.
>>
>> The patchset is based on '[PATCH v5 0/9] Enable HDMI support on Exynos platforms' [1].
>>
>
> It also depends on '[PATCH 0/2] Add HDMI support for Exynos5420 platform' [2].
>
>> It was successfully tested on OdroidXU3.
>>
>> [1]: http://permalink.gmane.org/gmane.linux.kernel.samsung-soc/42743
>
> Your patches looks good to me so please feel free to add:
>
> Reviewed-by: Javier Martinez Canillas <[email protected]>
>
> I also tested on an Exynos5420 Peach Pit Chromebook and both the "Power
> domain power-domain disable failed" message and the system crash are gone.
>
Really gone out "Power domain power-domain disable failed" message?
Still i get the message from second try,
# modetest -M exynos -s 23@21:1920x1080
setting mode 1920x1080@XR24 on connectors 23, crtc 21
# modetest -M exynos -s 23@21:1920x1080
setting mode 1920x1080@XR24 on connectors 23, crtc 21
[ 39.608881] Power domain power-domain disable failed
# modetest -M exynos -s 23@21:1920x1080
setting mode 1920x1080@XR24 on connectors 23, crtc 21
[ 42.827637] Power domain power-domain disable failed
...
Thanks.
> Tested-by: Javier Martinez Canillas <[email protected]>
>
> Best regards,
> Javier
>
> [2]: https://lkml.org/lkml/2015/1/20/235
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Hello Joonyoung,
On 02/06/2015 06:27 AM, Joonyoung Shim wrote:
> On 02/05/2015 11:45 PM, Javier Martinez Canillas wrote:
>>
>> I also tested on an Exynos5420 Peach Pit Chromebook and both the "Power
>> domain power-domain disable failed" message and the system crash are gone.
>>
>
> Really gone out "Power domain power-domain disable failed" message?
>
> Still i get the message from second try,
>
> # modetest -M exynos -s 23@21:1920x1080
> setting mode 1920x1080@XR24 on connectors 23, crtc 21
>
> # modetest -M exynos -s 23@21:1920x1080
> setting mode 1920x1080@XR24 on connectors 23, crtc 21
>
> [ 39.608881] Power domain power-domain disable failed
> # modetest -M exynos -s 23@21:1920x1080
> setting mode 1920x1080@XR24 on connectors 23, crtc 21
>
> [ 42.827637] Power domain power-domain disable failed
> ...
>
You are right, I tested that if I execute:
# for val in 1 0; do echo $val > /sys/class/drm/card0/device/graphics/fb0/blank; done
many times I see the "Power domain power-domain disable failed" message
again and there is no output in the HDMI display when dpms on.
But even in that case, the imprecise external abort does not happen when the
exynos_mixer driver tries to access the mixer registers and the system does
not crash anymore.
So I think that Andrzej's patches are at least a step in the right direction.
Best regards,
Javier
FIMD and MIXER IPs in disp1 power domain have async-bridges (to GSCALER),
therefore their clocks should be enabled during power domain switch.
Signed-off-by: Andrzej Hajda <[email protected]>
---
Hi,
This is 2nd version of the patch. After decrypting manual and discussion
with Marek I guess this set of clocks is more apropriate - async-bridges
are present in MIXER and FIMD, so their clocks should be enabled.
The 1st version worked for me due to fact I have forgot to remove
clk_ignore_unused kernel boot option during tests ;)
Regards
Andrzej
---
arch/arm/boot/dts/exynos5420.dtsi | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/exynos5420.dtsi b/arch/arm/boot/dts/exynos5420.dtsi
index e1fa800..58579f5 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -293,9 +293,11 @@
<&clock CLK_MOUT_SW_ACLK300>,
<&clock CLK_MOUT_USER_ACLK300_DISP1>,
<&clock CLK_MOUT_SW_ACLK400>,
- <&clock CLK_MOUT_USER_ACLK400_DISP1>;
+ <&clock CLK_MOUT_USER_ACLK400_DISP1>,
+ <&clock CLK_FIMD1>, <&clock CLK_MIXER>;
clock-names = "oscclk", "pclk0", "clk0",
- "pclk1", "clk1", "pclk2", "clk2";
+ "pclk1", "clk1", "pclk2", "clk2",
+ "asb0", "asb1";
};
pinctrl_0: pinctrl@13400000 {
--
1.9.1
Hello Andrzej,
On 02/06/2015 11:55 AM, Andrzej Hajda wrote:
> FIMD and MIXER IPs in disp1 power domain have async-bridges (to GSCALER),
> therefore their clocks should be enabled during power domain switch.
>
> Signed-off-by: Andrzej Hajda <[email protected]>
> ---
> Hi,
>
> This is 2nd version of the patch. After decrypting manual and discussion
> with Marek I guess this set of clocks is more apropriate - async-bridges
> are present in MIXER and FIMD, so their clocks should be enabled.
>
I just tested this version on my Exynos5420 Peach Pit and the power domain
failed error does not happen anymore even after enabling and disabling the
HDMI display several times.
Thanks a lot for fixing this since the dependency was not clear to me from
reading the manual.
> The 1st version worked for me due to fact I have forgot to remove
> clk_ignore_unused kernel boot option during tests ;)
>
Yes, that has bitten me too many times as well :)
> Regards
> Andrzej
> ---
Best regards,
Javier