diff mbox

[v3,00/19] Exynos SYSMMU (IOMMU) integration with DT and DMA-mapping subsystem

Message ID 54AEB384.2040005@collabora.co.uk (mailing list archive)
State New, archived
Headers show

Commit Message

Javier Martinez Canillas Jan. 8, 2015, 4:42 p.m. UTC
Hello Joonyoung,

On 01/07/2015 10:55 AM, Joonyoung Shim wrote:
>>>
>>> I don't think iommu support and power domain issue are related. I also
>>> get displaying stripes via hdmi but it is just power domain issue
>>> regardless iommu support.
>>>
>>> I observed 8th bit from 0x1445000C register of mixer is set to 1 with
>>> displaying stripes. It means "The graphic layer0 line buffer underflow".
>>> There was same underflow issue on Exynos4 based boards. As Marek said,
>>> because LCD0 power domain was turned off.
>>>
>> 
>> Interesting, thanks a lot for sharing this information.
>>  
>>> I just tried to turn off DISP1 power domain at u-boot and DISP1 power
>>> domain is turned on from kernel hdmi and mixer driver on odroid xu3 
>>> board. As the result, i can see displaying penguin logo from hdmi.
>>>
>> 
>> Can you share the patches you are using to turn on the DISP1 power domain
>> since AFAIU the kernel does not know about the DISP1 power domain after
>> commit d51cad7df871 ("ARM: dts: remove display power domain for exynos5420").
>> 
>> I tried reverting that commit before so the kernel knows about the DISP1
>> power domain and booting with pd_ignore_unused but still had the stripes.
>>  
> 
> I add DISP1 power domain on dts and please refer below patch[0] with
> some modification on hdmi phy(Actually, i think this is not related).
> You also should disable DISP1 power domain from bootloader.
>

Thanks a lot for the patch. With your changes I have some HDMI output on
my Peach Pi. But the HDMI output is broken since the resolution is very
low and the video as a lot of visual artifacts.

In your change you are also adding clock phandles for the pd oscillator
clock and the CLK_MOUT_SW_ACLK200, CLK_MOUT_USER_ACLK200_DISP1 pairs for
the parent input and input clocks of the devices attached to the pd.

And also making changes to the clocks in the clk-exynos5420 driver. Can
you please explain the rationale for those changes? I'm asking because
without your clock changes (only adding the DISP1 pd and making the
devices as consumers), I've HDMI output too but video is even worse. This
[0] is the minimal change I have on top of 3.19-rc3 to have some output.

The docs I've access to, don't have information about the clock hierarchy.
So each time there is a clock issue, I've a hard time to figure out what's
happening.

So there seems to be two issues here, one is the mixer and hdmi modules not
being attached to the DISP1 power domain and another one is the clocks setup
not being correct to have proper HDMI video output.
 
>>> But the problem exists still because it is failed to control on/off of
>>> DISP1 power domain more than twice from kernel hdmi and mixer driver.[0]
>>>

I didn't have this issue when testing your patch against 3.19-rc2. From your
log I see that you are testing on a 3.18.1. So maybe makes sense to test with
the latest kernel version since this HDMI issue qualifies as an 3.19-rc fix?

Since commit 2ed127697eb1 ("PM / Domains: Power on the PM domain right after attach completes")
that landed in 3.19-rc1, I see that the power domain is powered on when a
device is attached. So maybe that is what makes a difference here?

>> 
>> Something that is not clear to me is how display panel is working on the
>> Peach boards if this is a power domain issue since according to the manual
>> both the modules used for display (LCD controller and DP) and the modules
>> used for HDMI (MIXER and HDMI) belong to the same power domain (DISP1).
>> 
>
> I don't know about that because i just tested on odroid xu3 board
> without display panel. Hmm, It can be any conditions to success on/off
> power domain e.g. power state of clocks and of on/off order display
> devices.
>

My guess is that this is again clock related. Since if I add the DISP1 pd to
the DTS and make the fimd node as a consumer of the pd, the display panel
works correctly (same than current mainline that doesn't have the node).

But, if I also make the mixer and hdmi nodes as consumer of the DISP1, then
the exynos dp driver's probe function fails as shown in [1]. In this case,
the HDMI output works and I see that the DISP1 power domain is not powered
off so the only thing I can think is that is a clocks issue.

> Is DISP1 power domain disabled on Peach boards to save power, not always
> on?
>

No AFAICT, currently as I mentioned before the DISP1 power domain was removed
from the exynos5420.dtsi. So since the kernel does not know about it, should
be always on. With your patch, it should not be disabled either since it has
devices attached to and I confirmed that is not powered off anymore once all
the attached devices' probe functions have been deferred and retried again.

Thanks a lot for your help and best regards,
Javier

[0]:


[1]:
exynos-dp 145b0000.dp-controller: EDID data does not include any extensions.
exynos-dp 145b0000.dp-controller: EDID Read success!
exynos-dp 145b0000.dp-controller: Link Training Clock Recovery success
exynos-dp 145b0000.dp-controller: Link Training success!
exynos-dp 145b0000.dp-controller: Timeout of video streamclk ok
exynos-dp 145b0000.dp-controller: unable to config video

Comments

Joonyoung Shim Jan. 12, 2015, 6:40 a.m. UTC | #1
Hi,

On 01/09/2015 01:42 AM, Javier Martinez Canillas wrote:
> Hello Joonyoung,
> 
> On 01/07/2015 10:55 AM, Joonyoung Shim wrote:
>>>>
>>>> I don't think iommu support and power domain issue are related. I also
>>>> get displaying stripes via hdmi but it is just power domain issue
>>>> regardless iommu support.
>>>>
>>>> I observed 8th bit from 0x1445000C register of mixer is set to 1 with
>>>> displaying stripes. It means "The graphic layer0 line buffer underflow".
>>>> There was same underflow issue on Exynos4 based boards. As Marek said,
>>>> because LCD0 power domain was turned off.
>>>>
>>>
>>> Interesting, thanks a lot for sharing this information.
>>>  
>>>> I just tried to turn off DISP1 power domain at u-boot and DISP1 power
>>>> domain is turned on from kernel hdmi and mixer driver on odroid xu3 
>>>> board. As the result, i can see displaying penguin logo from hdmi.
>>>>
>>>
>>> Can you share the patches you are using to turn on the DISP1 power domain
>>> since AFAIU the kernel does not know about the DISP1 power domain after
>>> commit d51cad7df871 ("ARM: dts: remove display power domain for exynos5420").
>>>
>>> I tried reverting that commit before so the kernel knows about the DISP1
>>> power domain and booting with pd_ignore_unused but still had the stripes.
>>>  
>>
>> I add DISP1 power domain on dts and please refer below patch[0] with
>> some modification on hdmi phy(Actually, i think this is not related).
>> You also should disable DISP1 power domain from bootloader.
>>
> 
> Thanks a lot for the patch. With your changes I have some HDMI output on
> my Peach Pi. But the HDMI output is broken since the resolution is very
> low and the video as a lot of visual artifacts.
> 
> In your change you are also adding clock phandles for the pd oscillator
> clock and the CLK_MOUT_SW_ACLK200, CLK_MOUT_USER_ACLK200_DISP1 pairs for
> the parent input and input clocks of the devices attached to the pd.
> 
> And also making changes to the clocks in the clk-exynos5420 driver. Can
> you please explain the rationale for those changes? I'm asking because
> without your clock changes (only adding the DISP1 pd and making the
> devices as consumers), I've HDMI output too but video is even worse. This
> [0] is the minimal change I have on top of 3.19-rc3 to have some output.
> 

I just refer below patches,
http://comments.gmane.org/gmane.linux.kernel.samsung-soc/34576

But i'm not sure whether DISP1 power domain is same case with MFC power domain.

> The docs I've access to, don't have information about the clock hierarchy.
> So each time there is a clock issue, I've a hard time to figure out what's
> happening.
> 
> So there seems to be two issues here, one is the mixer and hdmi modules not
> being attached to the DISP1 power domain and another one is the clocks setup
> not being correct to have proper HDMI video output.
>  

Hmm, i can see normal hdmi output still from latest upstream
kernel(3.19-rc4) with my kernel changes and u-boot changes(DISP1 power
domain disable) of prior mail on odroid xu3 board.

>>>> But the problem exists still because it is failed to control on/off of
>>>> DISP1 power domain more than twice from kernel hdmi and mixer driver.[0]
>>>>
> 
> I didn't have this issue when testing your patch against 3.19-rc2. From your
> log I see that you are testing on a 3.18.1. So maybe makes sense to test with
> the latest kernel version since this HDMI issue qualifies as an 3.19-rc fix?
> 
> Since commit 2ed127697eb1 ("PM / Domains: Power on the PM domain right after attach completes")
> that landed in 3.19-rc1, I see that the power domain is powered on when a
> device is attached. So maybe that is what makes a difference here?
> 

I'm not sure, but i get same error results from 3.19-rc4. Did you test
using exynos drm driver? I used modetest of libdrm

>>>
>>> Something that is not clear to me is how display panel is working on the
>>> Peach boards if this is a power domain issue since according to the manual
>>> both the modules used for display (LCD controller and DP) and the modules
>>> used for HDMI (MIXER and HDMI) belong to the same power domain (DISP1).
>>>
>>
>> I don't know about that because i just tested on odroid xu3 board
>> without display panel. Hmm, It can be any conditions to success on/off
>> power domain e.g. power state of clocks and of on/off order display
>> devices.
>>
> 
> My guess is that this is again clock related. Since if I add the DISP1 pd to
> the DTS and make the fimd node as a consumer of the pd, the display panel
> works correctly (same than current mainline that doesn't have the node).
> 
> But, if I also make the mixer and hdmi nodes as consumer of the DISP1, then
> the exynos dp driver's probe function fails as shown in [1]. In this case,
> the HDMI output works and I see that the DISP1 power domain is not powered
> off so the only thing I can think is that is a clocks issue.
> 

DP also is related with DISP1 power domain, so it think DP driver should
consider DISP1 power domain.

>> Is DISP1 power domain disabled on Peach boards to save power, not always
>> on?
>>
> 
> No AFAICT, currently as I mentioned before the DISP1 power domain was removed
> from the exynos5420.dtsi. So since the kernel does not know about it, should
> be always on. With your patch, it should not be disabled either since it has
> devices attached to and I confirmed that is not powered off anymore once all
> the attached devices' probe functions have been deferred and retried again.
> 

OK, finally, we should add DISP1 power domain in dts file and be able to
control on/off of DISP1 power domain.

Thanks.

> Thanks a lot for your help and best regards,
> Javier
> 
> [0]:
> diff --git a/arch/arm/boot/dts/exynos5420.dtsi b/arch/arm/boot/dts/exynos5420.dtsi
> index 517e50f6760b..9966fe7bb0ec 100644
> --- a/arch/arm/boot/dts/exynos5420.dtsi
> +++ b/arch/arm/boot/dts/exynos5420.dtsi
> @@ -265,6 +265,11 @@
>  		clock-names = "oscclk", "pclk0", "clk0";
>  	};
>  
> +	disp_pd: power-domain@100440C0 {
> +		compatible = "samsung,exynos4210-pd";
> +		reg = <0x100440C0 0x20>;
> +	};
> +
>  	msc_pd: power-domain@10044120 {
>  		compatible = "samsung,exynos4210-pd";
>  		reg = <0x10044120 0x20>;
> @@ -535,6 +540,7 @@
>  	};
>  
>  	fimd: fimd@14400000 {
> +		samsung,power-domain = <&disp_pd>;
>  		clocks = <&clock CLK_SCLK_FIMD1>, <&clock CLK_FIMD1>;
>  		clock-names = "sclk_fimd", "fimd";
>  	};
> @@ -710,6 +716,7 @@
>  		phy = <&hdmiphy>;
>  		samsung,syscon-phandle = <&pmu_system_controller>;
>  		status = "disabled";
> +		samsung,power-domain = <&disp_pd>;
>  	};
>  
>  	hdmiphy: hdmiphy@145D0000 {
> @@ -722,6 +729,7 @@
>  		interrupts = <0 94 0>;
>  		clocks = <&clock CLK_MIXER>, <&clock CLK_SCLK_HDMI>;
>  		clock-names = "mixer", "sclk_hdmi";
> +		samsung,power-domain = <&disp_pd>;
>  	};
>  
>  	gsc_0: video-scaler@13e00000 {
> 
> 
> [1]:
> exynos-dp 145b0000.dp-controller: EDID data does not include any extensions.
> exynos-dp 145b0000.dp-controller: EDID Read success!
> exynos-dp 145b0000.dp-controller: Link Training Clock Recovery success
> exynos-dp 145b0000.dp-controller: Link Training success!
> exynos-dp 145b0000.dp-controller: Timeout of video streamclk ok
> exynos-dp 145b0000.dp-controller: unable to config video
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
Joonyoung Shim Jan. 12, 2015, 9:43 a.m. UTC | #2
Hi,

On 01/12/2015 03:40 PM, Joonyoung Shim wrote:
> Hi,
> 
> On 01/09/2015 01:42 AM, Javier Martinez Canillas wrote:
>> Hello Joonyoung,
>>
>> On 01/07/2015 10:55 AM, Joonyoung Shim wrote:
>>>>>
>>>>> I don't think iommu support and power domain issue are related. I also
>>>>> get displaying stripes via hdmi but it is just power domain issue
>>>>> regardless iommu support.
>>>>>
>>>>> I observed 8th bit from 0x1445000C register of mixer is set to 1 with
>>>>> displaying stripes. It means "The graphic layer0 line buffer underflow".
>>>>> There was same underflow issue on Exynos4 based boards. As Marek said,
>>>>> because LCD0 power domain was turned off.
>>>>>
>>>>
>>>> Interesting, thanks a lot for sharing this information.
>>>>  
>>>>> I just tried to turn off DISP1 power domain at u-boot and DISP1 power
>>>>> domain is turned on from kernel hdmi and mixer driver on odroid xu3 
>>>>> board. As the result, i can see displaying penguin logo from hdmi.
>>>>>
>>>>
>>>> Can you share the patches you are using to turn on the DISP1 power domain
>>>> since AFAIU the kernel does not know about the DISP1 power domain after
>>>> commit d51cad7df871 ("ARM: dts: remove display power domain for exynos5420").
>>>>
>>>> I tried reverting that commit before so the kernel knows about the DISP1
>>>> power domain and booting with pd_ignore_unused but still had the stripes.
>>>>  
>>>
>>> I add DISP1 power domain on dts and please refer below patch[0] with
>>> some modification on hdmi phy(Actually, i think this is not related).
>>> You also should disable DISP1 power domain from bootloader.
>>>
>>
>> Thanks a lot for the patch. With your changes I have some HDMI output on
>> my Peach Pi. But the HDMI output is broken since the resolution is very
>> low and the video as a lot of visual artifacts.
>>
>> In your change you are also adding clock phandles for the pd oscillator
>> clock and the CLK_MOUT_SW_ACLK200, CLK_MOUT_USER_ACLK200_DISP1 pairs for
>> the parent input and input clocks of the devices attached to the pd.
>>
>> And also making changes to the clocks in the clk-exynos5420 driver. Can
>> you please explain the rationale for those changes? I'm asking because
>> without your clock changes (only adding the DISP1 pd and making the
>> devices as consumers), I've HDMI output too but video is even worse. This
>> [0] is the minimal change I have on top of 3.19-rc3 to have some output.
>>
> 
> I just refer below patches,
> http://comments.gmane.org/gmane.linux.kernel.samsung-soc/34576
> 
> But i'm not sure whether DISP1 power domain is same case with MFC power domain.
> 
>> The docs I've access to, don't have information about the clock hierarchy.
>> So each time there is a clock issue, I've a hard time to figure out what's
>> happening.
>>
>> So there seems to be two issues here, one is the mixer and hdmi modules not
>> being attached to the DISP1 power domain and another one is the clocks setup
>> not being correct to have proper HDMI video output.
>>  
> 
> Hmm, i can see normal hdmi output still from latest upstream
> kernel(3.19-rc4) with my kernel changes and u-boot changes(DISP1 power
> domain disable) of prior mail on odroid xu3 board.
> 
>>>>> But the problem exists still because it is failed to control on/off of
>>>>> DISP1 power domain more than twice from kernel hdmi and mixer driver.[0]
>>>>>
>>
>> I didn't have this issue when testing your patch against 3.19-rc2. From your
>> log I see that you are testing on a 3.18.1. So maybe makes sense to test with
>> the latest kernel version since this HDMI issue qualifies as an 3.19-rc fix?
>>
>> Since commit 2ed127697eb1 ("PM / Domains: Power on the PM domain right after attach completes")
>> that landed in 3.19-rc1, I see that the power domain is powered on when a
>> device is attached. So maybe that is what makes a difference here?
>>
> 

I also get ashake hdmi output since commit 2ed127697eb1, it causes
on and off of DISP1 power domain when hdmi/mixer driver probe is defered
because regulator driver is not probed yet.

I'm not sure why it causes abnormal hdmi operation.

Thanks.

> I'm not sure, but i get same error results from 3.19-rc4. Did you test
> using exynos drm driver? I used modetest of libdrm
>
diff mbox

Patch

diff --git a/arch/arm/boot/dts/exynos5420.dtsi b/arch/arm/boot/dts/exynos5420.dtsi
index 517e50f6760b..9966fe7bb0ec 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -265,6 +265,11 @@ 
 		clock-names = "oscclk", "pclk0", "clk0";
 	};
 
+	disp_pd: power-domain@100440C0 {
+		compatible = "samsung,exynos4210-pd";
+		reg = <0x100440C0 0x20>;
+	};
+
 	msc_pd: power-domain@10044120 {
 		compatible = "samsung,exynos4210-pd";
 		reg = <0x10044120 0x20>;
@@ -535,6 +540,7 @@ 
 	};
 
 	fimd: fimd@14400000 {
+		samsung,power-domain = <&disp_pd>;
 		clocks = <&clock CLK_SCLK_FIMD1>, <&clock CLK_FIMD1>;
 		clock-names = "sclk_fimd", "fimd";
 	};
@@ -710,6 +716,7 @@ 
 		phy = <&hdmiphy>;
 		samsung,syscon-phandle = <&pmu_system_controller>;
 		status = "disabled";
+		samsung,power-domain = <&disp_pd>;
 	};
 
 	hdmiphy: hdmiphy@145D0000 {
@@ -722,6 +729,7 @@ 
 		interrupts = <0 94 0>;
 		clocks = <&clock CLK_MIXER>, <&clock CLK_SCLK_HDMI>;
 		clock-names = "mixer", "sclk_hdmi";
+		samsung,power-domain = <&disp_pd>;
 	};
 
 	gsc_0: video-scaler@13e00000 {