Re: [RFC] Adding export-symbols to specification

[Herve Codina <herve.codina@bootlin.com>]

Hi Quentin,

On Thu, 30 Jan 2025 17:47:16 +0100
Quentin Schulz <quentin.schulz@cherry.de> 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@sntech.de/
> 
> 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@bootlin.com/
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@bootlin.com/

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@bootlin.com/

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@bootlin.com/

The related driver applying the overlay:
  https://lore.kernel.org/all/20240917-hotplug-drm-bridge-v4-8-bc4dfee61be6@bootlin.com/
Even if some modification are still needed in this driver, the base ideas are
already present.

Best regards,
Hervé