[PATCH v2 1/4] drm/bridge: Add fwnode based helpers to get the next bridge

[Dmitry Baryshkov]

On Sat, 9 Mar 2024 at 11:33, Sui Jingfeng <sui.jingfeng at linux.dev> wrote:
>
> Hi,
>
>
> On 2024/3/8 04:40, Dmitry Baryshkov wrote:
> >>> But really, there is nothing so hard about it:
> >>> - Change of_node to fw_node, apply an automatic patch changing this in
> >>> bridge drivers.
> >>> - Make drm_of_bridge functions convert passed of_node and comp
> >>>
> >>> After this we can start cleaning up bridge drivers to use fw_node API
> >>> natively as you did in your patches 2-4.
> >> Yes, it's not so hard. But I'm a little busy due to other downstream developing
> >> tasks. Sorry, very sorry!
> >>
> >> During the talk with you, I observed that you are very good at fwnode domain.
> >> Are you willing to help the community to do something? For example, currently
> >> the modern drm bridge framework is corrupted by legacy implement, is it possible
> >> for us to migrate them to modern? Instead of rotting there? such as the lontium-lt9611uxc.c
> >> which create a drm connector manually, not modernized yet and it's DT dependent.
> >> So, there are a lot things to do.
> > Actually, lontium-lt9611uxc.c does both of that 😉 It supports
> > creating a connector and it as well supports attaching to a chain
> > without creating a connector. Pretty nice, isn't it?
>
>
> But why the drm_bridge_connector helpers and/or the drm_connector bridge can't suit you need?
> Coding this way just add boilerplate into drm bridge subsystem, right?

Because there are platforms, like iMX LCDIF which can use the
lt9611uxc bridge, but do not make use of the drm_bridge_connector yet.

> The code path of "creating a connector" plus the code path of "not creating a connector"
> forms a 'side-by-side' implementation imo.
>
> Besides, I have repeated many times: the DT already speak everything.
> Device drivers can completely know if there is a display connector OF device created and how many
> display bridges in the whole chain. If there are connector device node in the DT, then it should
> has a device driver bound to it(instead of create it manually) for a perfect implementation. As
> you told me we should not *over play* the device-driver model, right?

Please, don't mix the connector node in DT and the drm_connector. If
you check the code, you will see that the driver for hdmi-connector,
dp-connector and other such devices creates a drm_bridge.

-- 
With best wishes
Dmitry