drivers/gpu/drm/bridge/lvds-encoder.c broken in mainline

[Eric Anholt]

Lothar Waßmann <LW at KARO-electronics.de> writes:

> Hi,
>
> On Wed, 08 Nov 2017 10:18:03 -0800 Eric Anholt wrote:
>> Lothar Waßmann <LW at KARO-electronics.de> writes:
>> 
>> > Hi,
>> >
>> > drivers/gpu/drm/bridge/lvds-encoder.c driver is currently
>> > dysfunctional due to:
>> > |commit 13dfc0540a575b47b2d640b093ac16e9e09474f6
>> > |Author: Eric Anholt <eric at anholt.net>
>> > |Date:   Fri Jun 2 13:25:14 2017 -0700
>> > |
>> > |    drm/bridge: Refactor out the panel wrapper from the lvds-encoder bridge.
>> >
>> > Also, there is no in-kernel user of this driver, so that it obviously
>> > doesn't get tested in any way. There is only one dts file (r8a7779-marzen.dts)
>> > that instantiates this driver, but it has an incomplete OF graph. The missing
>> > link for the OF graph is provided by either r8a77xx-aa104xd12-panel.dtsi or
>> > r8a77xx-aa121td01-panel.dtsi, but those files are referenced nowhere in
>> > the kernel source.
>> >
>> > Should the driver be removed or moved to staging, until it is properly
>> > fixed?
>> 
>> I can't see any behavior change about the DT handling in that commit,
>> and I didn't intend for there to be any.  Could you help me understand
>> what went wrong?
>>
> With the offending commit applied, the lvds-encoder driver is being
> attached to the device associated with the lcd-panel driver's of_node
> (panel-simple in my case) rather than the lvds-encoder's of_node.

Anyone have any thoughts on best handling this?  Slip another bridge in
attached to this of_node that chains to panel-bridge's bridge, or just
have a panel-bridge entrypoint for what node to register the bridge on?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20171113/8f080ae8/attachment.sig>