On Thu, Jun 27, 2024 at 10:59:46PM +0530, Ayush Singh wrote:
> On 6/27/24 22:42, Michael Walle wrote:
>
> > Hi,
> >
> > Could you give us a DT snippet of how this should look like with a
> > board?
> >
> > On Thu Jun 27, 2024 at 6:26 PM CEST, Ayush Singh wrote:
> > > + board:
> > > + description: board attached to mikrobus connector
> > > + $ref: /schemas/types.yaml#/definitions/phandle-array
> > Shouldn't this be a subnode of the connector?
> >
> > i.e.
> >
> > connector {
> > compatible = "mikrobus-connector";
> >
> > // phandles to the parent controllers
These are per bus, so put them in the child bus nodes:
> >
> > spi {
spi-bus = <&spiN>;
spi-cs = ...
The base DT would have the spi node and these properties. The overlay
would still apply to the connector node, but also have the 'spi' node
along with the devices.
Note that whatever is done here, I expect to work on any connector with
SPI, I2C, etc. So structuring the bindings for that would be nice. There
is also this effort which needs the same bindings[1].
> > temp-sensor@0 {
> > compatible = "maxim,max31855k";
> > reg = <0>;
> > };
> > };
> >
> > i2c {
> > ..
> > };
> > };
> >
> > I don't think you can introduce a new
> > compatible = "maxim,max31855k", "mikrobus,spi";
> > if there is already a binding for "maxim,max31855k". But I might be
> > wrong. Why is this compatible needed at all?
>
> So I did consider the design you just proposed, but I was not able to solve
> a few issues.
>
> 1. How to deal with say 2 mikrobus connectors in a single system?
I don't understand why that's a problem? It's no different than the same
overlay working on multiple vendor's boards which I imagine you want
too. The connector node in the base DT has to remap everything from base
DT into a mikrobus defined number/name space. For example, host GPIO N
is mapped to mikrobus connector GPIO 0 and so on.
There is one issue in knowing what the target node is. Standardizing the
target path or connector node label only works for 1 connector per
system. You can have an empty target path in the overlay and something
else can decide the target. This is what's being done for overlays with
the dynamic PCI nodes. For example, maybe an eeprom tells the driver
what overlay to apply.
Rob
[1] https://lore.kernel.org/all/20240510-hotplug-drm-bridge-v2-0-ec32f2c66d56@xxxxxxxxxxx/
