[PATCH] ARM: dts: exynos5422-odroid*: remove fimd node

[PATCH] ARM: dts: exynos5422-odroid*: remove fimd node

[Marek Szyprowski]

FIMD device is not used at all on Exynos5422-based Odroid XU3-lite and
XU4. XU3 board teorethically can support FIMD with DisplayPort
connector, but due to hw limitation/design it doesn't work in most
cases. It is also not even enabled in XU3 dts file.

FIMD node was enabled mainly due to limitation of early Exynos DRM
driver, which didn't initialize properly when no FIMD device was
available. This node can be now safetly removed from XU3-common dtsi and
added layer to Odroid XU3 dts, when Display Port driver gets enabled.

Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
---
 arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 5 -----
 1 file changed, 5 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
index 1af5bdc..9134217 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
@@ -67,11 +67,6 @@
 			<19200000>;
 };
 
-&fimd {
-	status = "okay";
-};
-
-
 &hdmi {
 	status = "okay";
 	hpd-gpio = <&gpx3 7 GPIO_ACTIVE_HIGH>;
-- 
1.9.2

Re: [PATCH] ARM: dts: exynos5422-odroid*: remove fimd node

[Krzysztof Kozlowski]

On 10.11.2015 19:24, Marek Szyprowski wrote:
> FIMD device is not used at all on Exynos5422-based Odroid XU3-lite and
> XU4. XU3 board teorethically can support FIMD with DisplayPort

s/teorethically/theoretically/

> connector, but due to hw limitation/design it doesn't work in most
> cases. It is also not even enabled in XU3 dts file.
> 
> FIMD node was enabled mainly due to limitation of early Exynos DRM
> driver, which didn't initialize properly when no FIMD device was
> available. This node can be now safetly removed from XU3-common dtsi and

s/safetly/safely/

> added layer to Odroid XU3 dts, when Display Port driver gets enabled.
> 
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
>  arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 5 -----
>  1 file changed, 5 deletions(-)

Tested on Odroid XU4 board (HDMI, IOMMU enabled):

Tested-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>


No need for respin, the changelog fixes above can be done during applying.


BTW, do you know why we don't have EXYNOS_IOMMU enabled in defconfig?
Any reasons against?

Best regards,
Krzysztof


> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> index 1af5bdc..9134217 100644
> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> @@ -67,11 +67,6 @@
>  			<19200000>;
>  };
>  
> -&fimd {
> -	status = "okay";
> -};
> -
> -
>  &hdmi {
>  	status = "okay";
>  	hpd-gpio = <&gpx3 7 GPIO_ACTIVE_HIGH>;
> 

Re: [PATCH] ARM: dts: exynos5422-odroid*: remove fimd node

[Thomas Pietrowski]

When I was trying to build kernel 4.3.0 (from linux-stable) with
EXYNOS_IOMMU I was getting an kernel oop on boot, which forced me to
restart, so the kernel was not usable. Sadly I didn't make a paste of
it.
Can try to reproduce this error and send it if you like.

Are you not getting this error when building the kernel with it? (I
also own a Odroid U3+.)

Regards :)

2015-11-11 1:43 GMT+01:00 Krzysztof Kozlowski <k.kozlowski@samsung.com>:
> On 10.11.2015 19:24, Marek Szyprowski wrote:
>> FIMD device is not used at all on Exynos5422-based Odroid XU3-lite and
>> XU4. XU3 board teorethically can support FIMD with DisplayPort
>
> s/teorethically/theoretically/
>
>> connector, but due to hw limitation/design it doesn't work in most
>> cases. It is also not even enabled in XU3 dts file.
>>
>> FIMD node was enabled mainly due to limitation of early Exynos DRM
>> driver, which didn't initialize properly when no FIMD device was
>> available. This node can be now safetly removed from XU3-common dtsi and
>
> s/safetly/safely/
>
>> added layer to Odroid XU3 dts, when Display Port driver gets enabled.
>>
>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
>> ---
>>  arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 5 -----
>>  1 file changed, 5 deletions(-)
>
> Tested on Odroid XU4 board (HDMI, IOMMU enabled):
>
> Tested-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
> Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
>
>
> No need for respin, the changelog fixes above can be done during applying.
>
>
> BTW, do you know why we don't have EXYNOS_IOMMU enabled in defconfig?
> Any reasons against?
>
> Best regards,
> Krzysztof
>
>
>> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>> index 1af5bdc..9134217 100644
>> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
>> @@ -67,11 +67,6 @@
>>                       <19200000>;
>>  };
>>
>> -&fimd {
>> -     status = "okay";
>> -};
>> -
>> -
>>  &hdmi {
>>       status = "okay";
>>       hpd-gpio = <&gpx3 7 GPIO_ACTIVE_HIGH>;
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: dts: exynos5422-odroid*: remove fimd node

[Javier Martinez Canillas]

Hello Krzysztof,

On 11/10/2015 09:43 PM, Krzysztof Kozlowski wrote:

[snip]

> 
> 
> BTW, do you know why we don't have EXYNOS_IOMMU enabled in defconfig?
> Any reasons against?
>

It was explicitly disabled by commit 6562f3bd396a ("ARM: exynos_defconfig:
Disable IOMMU support") because Exynos IOMMU support was broken and caused
a BUG on boot, the discussion of the patch is [0].

But I just tested booting a v4.4-rc2 kernel on an Exynos5800 Peach Pi with
Exynos IOMMU enabled and the machine boots, display is working and
/sys/kernel/iommu_grups/*/devices shows that the devices were correctly
attached to an IOMMU group so things seems to have been sorted out now.

So it seems that EXYNOS_IOMMU could be enabled again. It would be good to
give such a patch a spin at kernelci before posting IMHO though just to be
sure there are no issues remaining.

> Best regards,
> Krzysztof
> 
> 

[0]: https://lkml.org/lkml/2015/2/17/163

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America

Re: [PATCH] ARM: dts: exynos5422-odroid*: remove fimd node

[Krzysztof Kozlowski]

On 23.11.2015 22:56, Javier Martinez Canillas wrote:
> Hello Krzysztof,
> 
> On 11/10/2015 09:43 PM, Krzysztof Kozlowski wrote:
> 
> [snip]
> 
>>
>>
>> BTW, do you know why we don't have EXYNOS_IOMMU enabled in defconfig?
>> Any reasons against?
>>
> 
> It was explicitly disabled by commit 6562f3bd396a ("ARM: exynos_defconfig:
> Disable IOMMU support") because Exynos IOMMU support was broken and caused
> a BUG on boot, the discussion of the patch is [0].

Right, now I remember.


> But I just tested booting a v4.4-rc2 kernel on an Exynos5800 Peach Pi with
> Exynos IOMMU enabled and the machine boots, display is working and
> /sys/kernel/iommu_grups/*/devices shows that the devices were correctly
> attached to an IOMMU group so things seems to have been sorted out now.
> 
> So it seems that EXYNOS_IOMMU could be enabled again. It would be good to
> give such a patch a spin at kernelci before posting IMHO though just to be
> sure there are no issues remaining.

Yes for enabling. No for testing only on kernelci. Booting is not a
sufficient test in this case. I would expect testing also display - at
least some frame buffer console on DP or HDMI (or whatever output could
be generated... Xorg/Wayland would be better of course). You need it
because display and camera (including complementary modules like JPEG,
MFC etc) are actually the only users of Exynos IOMMU in mainline.

Best regards,
Krzysztof

Re: [PATCH] ARM: dts: exynos5422-odroid*: remove fimd node

[Javier Martinez Canillas]

Hello Krzysztof,

On 11/24/2015 12:50 AM, Krzysztof Kozlowski wrote:
> On 23.11.2015 22:56, Javier Martinez Canillas wrote:
>> Hello Krzysztof,
>>
>> On 11/10/2015 09:43 PM, Krzysztof Kozlowski wrote:
>>
>> [snip]
>>
>>>
>>>
>>> BTW, do you know why we don't have EXYNOS_IOMMU enabled in defconfig?
>>> Any reasons against?
>>>
>>
>> It was explicitly disabled by commit 6562f3bd396a ("ARM: exynos_defconfig:
>> Disable IOMMU support") because Exynos IOMMU support was broken and caused
>> a BUG on boot, the discussion of the patch is [0].
> 
> Right, now I remember.
> 
> 
>> But I just tested booting a v4.4-rc2 kernel on an Exynos5800 Peach Pi with
>> Exynos IOMMU enabled and the machine boots, display is working and
>> /sys/kernel/iommu_grups/*/devices shows that the devices were correctly
>> attached to an IOMMU group so things seems to have been sorted out now.
>>
>> So it seems that EXYNOS_IOMMU could be enabled again. It would be good to
>> give such a patch a spin at kernelci before posting IMHO though just to be
>> sure there are no issues remaining.
> 
> Yes for enabling. No for testing only on kernelci. Booting is not a
> sufficient test in this case. I would expect testing also display - at

Sorry if I didn't explain myself clearly. I didn't mean that kernelci was
enough to test Exynos IOMMU support, what I said is that would be nice to
have some boot coverage besides the normal manual (or automated) display
testing that someone could do on available platforms as discussed over IRC.

> least some frame buffer console on DP or HDMI (or whatever output could
> be generated... Xorg/Wayland would be better of course). You need it

Yes, as I mentioned in the previous email, I tested display (with X) on an
Exynos5800 Peach Pi. I don't have a rootfs with wayland/weston handy but I
could prepare one tomorrow to give a try.

> because display and camera (including complementary modules like JPEG,
> MFC etc) are actually the only users of Exynos IOMMU in mainline.
>

Do you have some test cases for MFC? I know that Gstreamer has support
for it but I don't know what Gst pipelines I can use to test if all is
working correctly.

> Best regards,
> Krzysztof
>

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America

Re: [PATCH] ARM: dts: exynos5422-odroid*: remove fimd node

[Krzysztof Kozlowski]

On 24.11.2015 13:32, Javier Martinez Canillas wrote:
> 
>> least some frame buffer console on DP or HDMI (or whatever output could
>> be generated... Xorg/Wayland would be better of course). You need it
> 
> Yes, as I mentioned in the previous email, I tested display (with X) on an
> Exynos5800 Peach Pi. I don't have a rootfs with wayland/weston handy but I
> could prepare one tomorrow to give a try.

I think one X-window system is sufficient. More important would be to
test different drivers.

> 
>> because display and camera (including complementary modules like JPEG,
>> MFC etc) are actually the only users of Exynos IOMMU in mainline.
>>
> 
> Do you have some test cases for MFC? I know that Gstreamer has support
> for it but I don't know what Gst pipelines I can use to test if all is
> working correctly.

Yes, I think we have. I think Jacek Anaszewski or Andrzej Hajda (both
Cc-ed) were developing MFC drivers and testing it.

Jacek, Andrzej, Marek,

Do you have test cases for Exynos MFC drivers? Is it possible to share them?

Best regards,
Krzysztof

Re: [PATCH] ARM: dts: exynos5422-odroid*: remove fimd node

[Andrzej Hajda]

Hi Javier, Krzysztof,

On 11/26/2015 04:49 AM, Krzysztof Kozlowski wrote:
...
> Do you have some test cases for MFC? I know that Gstreamer has support
> for it but I don't know what Gst pipelines I can use to test if all is
> working correctly.
> Yes, I think we have. I think Jacek Anaszewski or Andrzej Hajda (both
> Cc-ed) were developing MFC drivers and testing it.
>
> Jacek, Andrzej, Marek,
>
> Do you have test cases for Exynos MFC drivers? Is it possible to share them?

There are test apps at:
http://git.linuxtv.org/cgit.cgi/snawrocki/samsung-utils.git/
v4l2-mfc-example - MFC decoder,
v4l2-mfc-encoder - MFC encoder,


Regards
Andrzej

Re: [PATCH] ARM: dts: exynos5422-odroid*: remove fimd node

[Javier Martinez Canillas]

Hello Andrzej,

On 11/26/2015 08:49 AM, Andrzej Hajda wrote:
> Hi Javier, Krzysztof,
> 
> On 11/26/2015 04:49 AM, Krzysztof Kozlowski wrote:
> ...
>> Do you have some test cases for MFC? I know that Gstreamer has support
>> for it but I don't know what Gst pipelines I can use to test if all is
>> working correctly.
>> Yes, I think we have. I think Jacek Anaszewski or Andrzej Hajda (both
>> Cc-ed) were developing MFC drivers and testing it.
>>
>> Jacek, Andrzej, Marek,
>>
>> Do you have test cases for Exynos MFC drivers? Is it possible to share them?
> 
> There are test apps at:
> http://git.linuxtv.org/cgit.cgi/snawrocki/samsung-utils.git/
> v4l2-mfc-example - MFC decoder,
> v4l2-mfc-encoder - MFC encoder,
>

Great, thanks a lot for the information.
 
> 
> Regards
> Andrzej
> 

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America

Re: [PATCH] ARM: dts: exynos5422-odroid*: remove fimd node

[Marek Szyprowski]

Hello,

On 2015-11-24 05:32, Javier Martinez Canillas wrote:
> Hello Krzysztof,
>
> On 11/24/2015 12:50 AM, Krzysztof Kozlowski wrote:
>> On 23.11.2015 22:56, Javier Martinez Canillas wrote:
>>> Hello Krzysztof,
>>>
>>> On 11/10/2015 09:43 PM, Krzysztof Kozlowski wrote:
>>>
>>> [snip]
>>>
>>>> BTW, do you know why we don't have EXYNOS_IOMMU enabled in defconfig?
>>>> Any reasons against?
>>> It was explicitly disabled by commit 6562f3bd396a ("ARM: exynos_defconfig:
>>> Disable IOMMU support") because Exynos IOMMU support was broken and caused
>>> a BUG on boot, the discussion of the patch is [0].
>> Right, now I remember.
>>
>>
>>> But I just tested booting a v4.4-rc2 kernel on an Exynos5800 Peach Pi with
>>> Exynos IOMMU enabled and the machine boots, display is working and
>>> /sys/kernel/iommu_grups/*/devices shows that the devices were correctly
>>> attached to an IOMMU group so things seems to have been sorted out now.
>>>
>>> So it seems that EXYNOS_IOMMU could be enabled again. It would be good to
>>> give such a patch a spin at kernelci before posting IMHO though just to be
>>> sure there are no issues remaining.
>> Yes for enabling. No for testing only on kernelci. Booting is not a
>> sufficient test in this case. I would expect testing also display - at
> Sorry if I didn't explain myself clearly. I didn't mean that kernelci was
> enough to test Exynos IOMMU support, what I said is that would be nice to
> have some boot coverage besides the normal manual (or automated) display
> testing that someone could do on available platforms as discussed over IRC.
>
>> least some frame buffer console on DP or HDMI (or whatever output could
>> be generated... Xorg/Wayland would be better of course). You need it
> Yes, as I mentioned in the previous email, I tested display (with X) on an
> Exynos5800 Peach Pi. I don't have a rootfs with wayland/weston handy but I
> could prepare one tomorrow to give a try.
>
>> because display and camera (including complementary modules like JPEG,
>> MFC etc) are actually the only users of Exynos IOMMU in mainline.
>>
> Do you have some test cases for MFC? I know that Gstreamer has support
> for it but I don't know what Gst pipelines I can use to test if all is
> working correctly.

Please note that mainline driver for MFC doesn't work with IOMMU enabled 
yet.
I plan to finish a patch for it when I find some free time.

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

Re: [PATCH] ARM: dts: exynos5422-odroid*: remove fimd node

[Javier Martinez Canillas]

Hello Marek,

On 11/26/2015 11:29 AM, Marek Szyprowski wrote:
> Hello,
> 
> On 2015-11-24 05:32, Javier Martinez Canillas wrote:
>> Hello Krzysztof,
>>
>> On 11/24/2015 12:50 AM, Krzysztof Kozlowski wrote:
>>> On 23.11.2015 22:56, Javier Martinez Canillas wrote:
>>>> Hello Krzysztof,
>>>>
>>>> On 11/10/2015 09:43 PM, Krzysztof Kozlowski wrote:
>>>>
>>>> [snip]
>>>>
>>>>> BTW, do you know why we don't have EXYNOS_IOMMU enabled in defconfig?
>>>>> Any reasons against?
>>>> It was explicitly disabled by commit 6562f3bd396a ("ARM: exynos_defconfig:
>>>> Disable IOMMU support") because Exynos IOMMU support was broken and caused
>>>> a BUG on boot, the discussion of the patch is [0].
>>> Right, now I remember.
>>>
>>>
>>>> But I just tested booting a v4.4-rc2 kernel on an Exynos5800 Peach Pi with
>>>> Exynos IOMMU enabled and the machine boots, display is working and
>>>> /sys/kernel/iommu_grups/*/devices shows that the devices were correctly
>>>> attached to an IOMMU group so things seems to have been sorted out now.
>>>>
>>>> So it seems that EXYNOS_IOMMU could be enabled again. It would be good to
>>>> give such a patch a spin at kernelci before posting IMHO though just to be
>>>> sure there are no issues remaining.
>>> Yes for enabling. No for testing only on kernelci. Booting is not a
>>> sufficient test in this case. I would expect testing also display - at
>> Sorry if I didn't explain myself clearly. I didn't mean that kernelci was
>> enough to test Exynos IOMMU support, what I said is that would be nice to
>> have some boot coverage besides the normal manual (or automated) display
>> testing that someone could do on available platforms as discussed over IRC.
>>
>>> least some frame buffer console on DP or HDMI (or whatever output could
>>> be generated... Xorg/Wayland would be better of course). You need it
>> Yes, as I mentioned in the previous email, I tested display (with X) on an
>> Exynos5800 Peach Pi. I don't have a rootfs with wayland/weston handy but I
>> could prepare one tomorrow to give a try.
>>
>>> because display and camera (including complementary modules like JPEG,
>>> MFC etc) are actually the only users of Exynos IOMMU in mainline.
>>>
>> Do you have some test cases for MFC? I know that Gstreamer has support
>> for it but I don't know what Gst pipelines I can use to test if all is
>> working correctly.
> 
> Please note that mainline driver for MFC doesn't work with IOMMU enabled yet.
> I plan to finish a patch for it when I find some free time.
>

Thanks a lot for the information. Then that's a reason to not enable IOMMU
by default in the defconfig until the MFC driver works correctly with that.
 
> Best regards

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America