| Message ID | 1447151049-25370-1-git-send-email-m.szyprowski@samsung.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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
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 -- 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
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,
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 -- 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
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,
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 -- 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
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 -- 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
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,
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
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,
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>;
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(-)