[PATCH v5 1/7] dt-bindings: connector: Add mikrobus-connector

[Rob Herring]

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