Hi,
On 2024/3/9 18:39, Dmitry Baryshkov wrote:
On Sat, 9 Mar 2024 at 11:33, Sui Jingfeng <sui.jingfeng@xxxxxxxxx> 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.
Well, I have just grepped across the drm-tip kernel branch, but I don't find
iMX LCDIF you mentioned. See the search results pasted at bellow.
$ find . -name "*.dts" -type f | xargs grep "lontium,lt9611uxc"
./arm64/boot/dts/qcom/sm8450-hdk.dts: compatible = "lontium,lt9611uxc";
./arm64/boot/dts/qcom/qrb5165-rb5.dts: compatible = "lontium,lt9611uxc";
./arm64/boot/dts/qcom/qrb2210-rb1.dts: compatible = "lontium,lt9611uxc";
./arm64/boot/dts/qcom/qrb4210-rb2.dts: compatible = "lontium,lt9611uxc";
./arm64/boot/dts/qcom/sm8350-hdk.dts: compatible = "lontium,lt9611uxc";
So I can't see the drm driver that you refer to, can you pointed it out for study
purpose? Even it's exist, however, back to that time, why don't you posting a patch
to switch it to the canonical design as you mentioned and give the community a clean
design?
And those are just *reasons*, from the viewpoint of the *result*.
The merged patch results in a 'side-by-side' implement and boilerplate added
into drm bridges subsystem, the results doesn't change no matter what the
reason is, right?
