Hi,
On 2023/10/30 21:39, Maxime Ripard wrote:
On Mon, Oct 30, 2023 at 09:25:50PM +0800, Sui Jingfeng wrote:
I think my approach provide a solution, while still keep the bridges drivers
to a modular at the same time. Despite simple, it indeed solve the problem.
It simple because of explicit control of the loading order by myself, not by
rely on the framework or something else (say component)
It is not totally duplicating, I have rewrite part of them. You can compare
to see what I'm changed. It is just that it66162 was upstream-ed earlier than
our solution. But I also have write display drivers for lt8618 and lt8619
completely by myself.
Even though our local drm bridges driver will not be able to enjoy the updates.
We will accept such a results(or pain). I can maintain our local drm bridges
drivers by myself. Sorry, on this technique point, we will not follow your idea.
I'm sure that my approach is toward to right direction for our device at now.
If someone invent a better solution to handle this problem, which make the
various drm bridges drivers usable out of box, then I will follow and cooperate
to test.
As far as I'm concerned, the two options are either you reuse the
already existing driver or this series isn't merged.
It's not that I don't want to use thealready existing display bridge driver, It is just that it is not
suitable for non DT-based system to use. Our system using UEFI+ACPI,
beside the I2C, there also have GPIO HPD interrupt hardware. ACPI-based system and DT-based system have different way to use(request) the hardware.
Can you feel my words?
If the variousdisplay bridge drivers are really ready to use, why I have to refuse?
Ignoring what issue we raised and still merging your patch isn't on the
table, sorry.
Maxime
