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

2016-05-18 Thread Philipp Zabel
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:
> > 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.
> > 
> 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



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

2016-05-18 Thread Lothar Waßmann
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:
> > 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")

2016-05-17 Thread Marcel Ziswiler
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")

2016-05-13 Thread Philipp Zabel
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")

2016-05-13 Thread 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'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")

2016-05-13 Thread Russell King - ARM Linux
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.