Re: [RFC] Adding export-symbols to specification

On 1/30/25 23:37, Herve Codina wrote:

> Hi Quentin,
>
> On Thu, 30 Jan 2025 17:47:16 +0100
> Quentin Schulz <[email protected]> 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/[email protected]/
>>
>> 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/[email protected]/
> 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/[email protected]/
>
> 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/[email protected]/
>
> 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/[email protected]/
>
> The related driver applying the overlay:
>    https://lore.kernel.org/all/[email protected]/
> 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