Lothar Waßmann <l...@karo-electronics.de> writes: > Hi, > > On Wed, 08 Nov 2017 10:18:03 -0800 Eric Anholt wrote: >> Lothar Waßmann <l...@karo-electronics.de> writes: >> >> > Hi, >> > >> > drivers/gpu/drm/bridge/lvds-encoder.c driver is currently >> > dysfunctional due to: >> > |commit 13dfc0540a575b47b2d640b093ac16e9e09474f6 >> > |Author: Eric Anholt <e...@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?
signature.asc
Description: PGP signature
_______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
