On 1/30/25 23:37, Herve Codina wrote:
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é
I am also planning to add argument for specifying target in fdtoverlay
(to support application using uboot, etc). So something like:
fdtoverlay overlay.dtbo --target "/path/to/connector"
Best regards,
Ayush Singh
