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

[Michael Walle]

Hi,

On Thu Jun 27, 2024 at 7:29 PM CEST, 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
> >
> > 	spi {
> > 		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?

Yes, interesting problem. That info should go into the cover letter.

> My goal is to have only 1 overlay required for the board config at most. 
> Ideally, I would actually like to add the dt for most mikroBUS boards to 
> upstream and thus only the following overlay would be required:
>
> ```
>
> &connector0 {
>
>      board = <&temp-board>;
>
> };

That's then per board, per click board. right?

>
> ```
>
>
> The problem with making it children is that each connector will require 
> seperate overlays for board configs.

Right.

> Additionally, there are boards with 1 wire eeprom available which can 
> theselves store the overlay. In the current setup it will look as follows:
>
> ```
>
> &mikrobus_board {

Where is that phandle pointing to? And what if there are two boards?

>
>      thermo-sensor {
>
>          ...
>
>      };
>
> };

But here you can have subnodes, no? These could then be just
enumerated as usual.

&mikrobus_board {
	mikrobus_gpio: gpio {
		gpio-controller;
		#gpio-cells = <1>;
	};

	spi {
		cs-gpios = <&mikrobus_gpio 1>;

		spi at 0 {
			compatible = "mydevice";
			reg = <0>;
		};
	};
};


> ```

Not sure what this is, but my mail reader doesn't render RST? ;)

-michael

>
> Which is completely independent of the connector. If the same can be 
> achieved with child-node as well, then I am open to doing that.
>
>
> >
> > Also, the mikrobus-connector driver could translate the chipselects.
> >
> > -michael
>
> Yes, so it is currently doing that. Translating chip select name to the 
> actual number. I am doing it the name way since some boards might use 
> pins other than CS as chipselect and not all connectors will allow all 
> pins to be used as chipselect.
>
>
> Ayush Singh