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

Michael Walle
2024-06-27T17:49:20Z

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@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@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