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

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

[Lothar Waßmann]

Hi,

drivers/gpu/drm/bridge/lvds-encoder.c driver is currently
dysfunctional due to:
|commit 13dfc0540a575b47b2d640b093ac16e9e09474f6
|Author: Eric Anholt <eric@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?


Lothar Waßmann
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Eric Anholt]

[-- Attachment #1.1: Type: text/plain, Size: 1035 bytes --]

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

> Hi,
>
> drivers/gpu/drm/bridge/lvds-encoder.c driver is currently
> dysfunctional due to:
> |commit 13dfc0540a575b47b2d640b093ac16e9e09474f6
> |Author: Eric Anholt <eric@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?

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Lothar Waßmann]

Hi,

On Wed, 08 Nov 2017 10:18:03 -0800 Eric Anholt wrote:
> Lothar Waßmann <LW@KARO-electronics.de> writes:
> 
> > Hi,
> >
> > drivers/gpu/drm/bridge/lvds-encoder.c driver is currently
> > dysfunctional due to:
> > |commit 13dfc0540a575b47b2d640b093ac16e9e09474f6
> > |Author: Eric Anholt <eric@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.


Lothar Waßmann
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Eric Anholt]

[-- Attachment #1.1: Type: text/plain, Size: 1666 bytes --]

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

> Hi,
>
> On Wed, 08 Nov 2017 10:18:03 -0800 Eric Anholt wrote:
>> Lothar Waßmann <LW@KARO-electronics.de> writes:
>> 
>> > Hi,
>> >
>> > drivers/gpu/drm/bridge/lvds-encoder.c driver is currently
>> > dysfunctional due to:
>> > |commit 13dfc0540a575b47b2d640b093ac16e9e09474f6
>> > |Author: Eric Anholt <eric@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?

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Archit Taneja]

On 11/14/2017 02:33 AM, Eric Anholt wrote:
> Lothar Waßmann <LW@KARO-electronics.de> writes:
> 
>> Hi,
>>
>> On Wed, 08 Nov 2017 10:18:03 -0800 Eric Anholt wrote:
>>> Lothar Waßmann <LW@KARO-electronics.de> writes:
>>>
>>>> Hi,
>>>>
>>>> drivers/gpu/drm/bridge/lvds-encoder.c driver is currently
>>>> dysfunctional due to:
>>>> |commit 13dfc0540a575b47b2d640b093ac16e9e09474f6
>>>> |Author: Eric Anholt <eric@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?

I think slipping in another bridge seems to make more sense. When we converted
to panel-bridge, we didn't create a bridge entity for the lvds-encoder itself,
we just created the panel-bridge's bridge, which anyway is more a glue-layer
for drm_panel than a real bridge entity.

Thanks,
Archit

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel