ARM: dts: exynos5422-odroid*: remove fimd node

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(-)

-- 
1.9.2

--
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,

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

--
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