Hi Quentin, On Thu, 30 Jan 2025 17:47:16 +0100 Quentin Schulz <quentin.schulz@xxxxxxxxx> wrote: > Hi Ayush, > > This is actually quite interesting. I don't know exactly how far we > could push this. > > FYI, we have a Q7 carrierboard which supports three different modules > today. This carrierboard currently has two adapter boards that are > compatible with all three modules. One is Haikou Video Demo, see patch > here: > https://lore.kernel.org/linux-rockchip/20241127143719.660658-4-heiko@xxxxxxxxx/ > > We could resolve differences in i2c bus by adding another label to the > bus node that is exposed on the connector, so that isn't much of an > issue. MIPI DSI PHY and controller may be a different story as those may > have different bindings that would make it difficult to support with one > overlay? Haven't checked yet though. See [1] and [2] for the DTS (not > yet overlays...) of the other two SoM that this adapter works with. > However, this would resolve the issue of having different GPIOs for > reset and interrupt lines. Anyway, I'm not sure this export-symbols > stuff would actually help us, just being curious here, will keep an eye > on it but probably won't be able to help much. > > [1] > https://git.theobroma-systems.com/puma-linux.git/tree/arch/arm64/boot/dts/rockchip/px30-ringneck-haikou-video-demo.dts?h=v6.6.39-puma > [2] > https://git.theobroma-systems.com/puma-linux.git/tree/arch/arm64/boot/dts/rockchip/rk3399-puma-haikou-video-demo.dts?h=v6.6.39-puma > Related to buses like i2c or even DSI, we are working on it. We have presented the big picture in https://lore.kernel.org/all/20240917-hotplug-drm-bridge-v4-0-bc4dfee61be6@xxxxxxxxxxx/ When this series was sent, export-symbols and nexus node were not present. A talk has been done at Plumbers: https://lpc.events/event/18/contributions/1696/ An the nexus node came from Plumbers discussion and export-symbols came right after in order to solve symbols resolution. Back to i2c bus, we have proposed the following: https://lore.kernel.org/all/20240917-hotplug-drm-bridge-v4-5-bc4dfee61be6@xxxxxxxxxxx/ I recently took the i2c topic and I plan to send an updated iteration with issue fixed using the 'i2c-parent' and 'i2c-bus-extension'. On DSI bus, my colleague Luca is working on it. He already extracted specific DRM modification out of the big picture and sent a dedicated series: https://lore.kernel.org/all/20241231-hotplug-drm-bridge-v5-0-173065a1ece1@xxxxxxxxxxx/ I hope those pointers will show you the direction we take and maybe help in your issues. > On 1/27/25 2:45 PM, Ayush Singh wrote: > [...] > > A board with two connectors can be described with: > > > > > > connector1: connector1 { > > ... > > export-symbols { > > connector = <&connector1>; > > }; > > }; > > > > connector2: connector2 { > > ... > > export-symbols { > > connector = <&connector2>; > > }; > > }; > > > > > > In that case, the same overlay with unresolved 'connector' symbol can be > > applied on both connectors and the correct symbol resolution (connector1 > > or connector2) will be done. > > > > I'm not sure to understand how the tooling would figure out to which > connector of the baseboard should the overlay be applied? > > In the case of a single connector and a single overlay, that's fine. But > in the case of 2+ connectors, 2+ adapters but a single overlay, how does > the system know which connector it should resolve the "connector" part > in the overlay? Is there some tooling involved? E.g. providing an > argument (like which connector from the board to use?). Or are you > expecting that applying the overlay once will pick connector1 and > applying the overlay a second time would pick connector2? If you have > multiple overlays for different adapters using this connector > abstraction, the first one to be applied would be the on the first > connector and then the second on the second one? What if I have nothing > connected on connector 1 but on connector 2, how do I specify to which > connector the overlay should apply? In my case, I have a driver for the connector and our driver apply the overlay. The symbol resolution is done at runtime by the kernel when the overlay is applied by the driver. https://lore.kernel.org/all/20241209151830.95723-1-herve.codina@xxxxxxxxxxx/ The related driver applying the overlay: https://lore.kernel.org/all/20240917-hotplug-drm-bridge-v4-8-bc4dfee61be6@xxxxxxxxxxx/ Even if some modification are still needed in this driver, the base ideas are already present. Best regards, Hervé
