Messages in this thread | | | Date | Mon, 30 Oct 2023 22:39:32 +0800 | Subject | Re: [PATCH 2/8] drm/loongson: Introduce a drm bridge driver for it66121 HDMI transmitter | From | Sui Jingfeng <> |
| |
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
| |