imx-drm: regression due to commit 503fe87bd0a8 ("gpu: ipu-v3: Fix imx-ipuv3-crtc module autoloading")

6 messages, 4 authors, 2016-05-18 · open the first message on its own page

imx-drm: regression due to commit 503fe87bd0a8 ("gpu: ipu-v3: Fix imx-ipuv3-crtc module autoloading")

From: Lothar Waßmann <hidden>
Date: 2016-05-13 10:33:36

Hi,

the commit 503fe87bd0a8 ("gpu: ipu-v3: Fix imx-ipuv3-crtc module autoloading")
indeed fixes the autoloading issue, but completely breaks the driver in
non-modular mode (at least with the parallel-display driver I didn't
yet check with the imx-ldb driver.
Can anyone confirm that the imx-drm driver in current linux-next
(next-20160512) works for them with any i.MX6 or i.MX53 board?

I'm always very suspicious when seeing code moving of_node's from
one device to another or assigning of_node's to platform devices that
weren't instantiated via DT.


Lothar Wa?mann

imx-drm: regression due to commit 503fe87bd0a8 ("gpu: ipu-v3: Fix imx-ipuv3-crtc module autoloading")

From: linux@armlinux.org.uk (Russell King - ARM Linux)
Date: 2016-05-13 10:44:37

On Fri, May 13, 2016 at 12:33:36PM +0200, Lothar Wa?mann wrote:
I'm always very suspicious when seeing code moving of_node's from
one device to another or assigning of_node's to platform devices that
weren't instantiated via DT.
It's completely wrong to add an of_node to a device on the same bus
that already has a device with the same of_node - doing so means
that the bus matching code will match the same device driver to both
devices, which may not be what you want to happen.

Just don't do it, it's a bug waiting to happen.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

imx-drm: regression due to commit 503fe87bd0a8 ("gpu: ipu-v3: Fix imx-ipuv3-crtc module autoloading")

From: p.zabel@pengutronix.de (Philipp Zabel)
Date: 2016-05-13 11:04:12

Hi Lothar,

Am Freitag, den 13.05.2016, 12:33 +0200 schrieb Lothar Wa?mann:
Hi,

the commit 503fe87bd0a8 ("gpu: ipu-v3: Fix imx-ipuv3-crtc module autoloading")
indeed fixes the autoloading issue, but completely breaks the driver in
non-modular mode (at least with the parallel-display driver I didn't
yet check with the imx-ldb driver.
Can anyone confirm that the imx-drm driver in current linux-next
(next-20160512) works for them with any i.MX6 or i.MX53 board?
I have sent a patch: https://patchwork.kernel.org/patch/9081661/
that I'd appreciate your input on.

regards
Philipp

imx-drm: regression due to commit 503fe87bd0a8 ("gpu: ipu-v3: Fix imx-ipuv3-crtc module autoloading")

From: Marcel Ziswiler <hidden>
Date: 2016-05-17 14:27:00

Hi there

On Fri, 2016-05-13 at 12:33 +0200, Lothar Wa?mann wrote:
Hi,

the commit 503fe87bd0a8 ("gpu: ipu-v3: Fix imx-ipuv3-crtc module
autoloading")
indeed fixes the autoloading issue, but completely breaks the driver
in
non-modular mode (at least with the parallel-display driver I didn't
yet check with the imx-ldb driver.
Can anyone confirm that the imx-drm driver in current linux-next
(next-20160512) works for them with any i.MX6 or i.MX53 board?
I can confirm that this is actually broken both in v4.6 and next-
20160517. Reverting commit 407c9eba7897 ("drm/imx: Remove of_node
assignment from ipuv3-crtc driver probe") in both cases makes regular
imx_v6_v7_defconfig work again.
I'm always very suspicious when seeing code moving of_node's from
one device to another or assigning of_node's to platform devices that
weren't instantiated via DT.


Lothar Wa?mann
Cheers

Marcel
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

imx-drm: regression due to commit 503fe87bd0a8 ("gpu: ipu-v3: Fix imx-ipuv3-crtc module autoloading")

From: Lothar Waßmann <hidden>
Date: 2016-05-18 09:12:43

Hi,

On Fri, 13 May 2016 13:04:12 +0200 Philipp Zabel wrote:
Hi Lothar,

Am Freitag, den 13.05.2016, 12:33 +0200 schrieb Lothar Wa?mann:
quoted
Hi,

the commit 503fe87bd0a8 ("gpu: ipu-v3: Fix imx-ipuv3-crtc module autoloading")
indeed fixes the autoloading issue, but completely breaks the driver in
non-modular mode (at least with the parallel-display driver I didn't
yet check with the imx-ldb driver.
Can anyone confirm that the imx-drm driver in current linux-next
(next-20160512) works for them with any i.MX6 or i.MX53 board?
I have sent a patch: https://patchwork.kernel.org/patch/9081661/
that I'd appreciate your input on.
This patch works for the parallel-display driver but not for imx-ldb
(I didn't test the TV or HDMI drivers). It works when the DRM driver is
built as modules, but when it is non-modular I get a framebuffer
device which is useable from userspace, but no output on the LVDS
interface.

When reverting 503fe87bd0a8346ba9d8b7f49115dcd0a4185226 instead of
applying the above patch, the builtin driver works normally.


Lothar Wa?mann

imx-drm: regression due to commit 503fe87bd0a8 ("gpu: ipu-v3: Fix imx-ipuv3-crtc module autoloading")

From: p.zabel@pengutronix.de (Philipp Zabel)
Date: 2016-05-18 12:50:50

Am Mittwoch, den 18.05.2016, 11:12 +0200 schrieb Lothar Wa?mann:
Hi,

On Fri, 13 May 2016 13:04:12 +0200 Philipp Zabel wrote:
quoted
Hi Lothar,

Am Freitag, den 13.05.2016, 12:33 +0200 schrieb Lothar Wa?mann:
quoted
Hi,

the commit 503fe87bd0a8 ("gpu: ipu-v3: Fix imx-ipuv3-crtc module autoloading")
indeed fixes the autoloading issue, but completely breaks the driver in
non-modular mode (at least with the parallel-display driver I didn't
yet check with the imx-ldb driver.
Can anyone confirm that the imx-drm driver in current linux-next
(next-20160512) works for them with any i.MX6 or i.MX53 board?
I have sent a patch: https://patchwork.kernel.org/patch/9081661/
that I'd appreciate your input on.
This patch works for the parallel-display driver but not for imx-ldb
(I didn't test the TV or HDMI drivers). It works when the DRM driver is
built as modules, but when it is non-modular I get a framebuffer
device which is useable from userspace, but no output on the LVDS
interface.

When reverting 503fe87bd0a8346ba9d8b7f49115dcd0a4185226 instead of
applying the above patch, the builtin driver works normally.
Thank you for testing, I'll send a new version.

regards
Philipp
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help