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?
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?
