>-----Original Message----- >From: Rob Herring <robh@xxxxxxxxxx> >Sent: 2022年4月22日 3:08 >To: Michael Walle <michael@xxxxxxxx> >Cc: Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxx>; Mark Brown ><broonie@xxxxxxxxxx>; devicetree@xxxxxxxxxxxxxxx; Jerry Huang ><jerry.huang@xxxxxxx>; Krzysztof Kozlowski ><krzysztof.kozlowski+dt@xxxxxxxxxx>; Leo Li <leoyang.li@xxxxxxx>; >linux-arm-kernel <linux-arm-kernel@xxxxxxxxxxxxxxxxxxx>; >linux-kernel@xxxxxxxxxxxxxxx; linux-spi <linux-spi@xxxxxxxxxxxxxxx>; Shawn Guo ><shawnguo@xxxxxxxxxx>; Vladimir Oltean <olteanv@xxxxxxxxx> >Subject: Re: [EXT] Re: [PATCH 1/2 v4] dt-bindings: dspi: added for semtech sx1301 > >Caution: EXT Email > >On Thu, Apr 21, 2022 at 10:16 AM Michael Walle <michael@xxxxxxxx> wrote: >> >> Am 2022-04-21 16:23, schrieb Rob Herring: >> >> > What's needed here is a connector node (and driver) for the mikrobus >> > socket. The connector node's purpose is to decouple the host DT from >> > add-on board overlay DT. Something like this: >> >> Funny I had a similar idea to have a connector with all the >> properties, but I failed to see how that would be of any help. >> >> Do you mind an example of such an overlay? Judging by the spi and i2c >> subnode, I guess it will amend the connector node and fill in it's >> devices? > >Right. > >> >> And all the child device properties will reference the connector, >> correct? > >Right. > >> >> > connector { >> > // And a more specific compatible if pins can have alt funcs? >> > // Spec version needed? >> > compatible = "mikrobus-socket"; >> > >> > // Will need regulators defined if child devices expect >> > // regulators >> > vcc-33-supply = <®33>; >> > vcc-5-supply = <®5v>; >> > >> > i2c-parent = <&i2c1>; // Already a defined property >> > spi-parent = <&spi0>; // New >> >> uart/serial needed too? > >Yes. Serial has the extra issue in the kernel that tty vs. serdev are mutually >exclusive and decided by presence or not of a child node for the UART. That would >need some work to dynamically switch. I think I have some old patches doing that, >but they probably break some aspects of TTY expectations. > >> >> > >> > // RST pin >> > reset-gpios = <&gpio 4 0>; >> > >> > // remap 'INT' (index 0) to host interrupt >> > #interrupt-cells = <2>; >> > #address-cells = <0>; >> > interrupt-map = <0 0 &gpio 3 0>; >> > >> > spi { >> >> For example: >> >> my-device@0 { >> reg = <0>; // really needed? there is only one SPI CS line > >Yes, needed. > >> compatible = "my-device"; >> reset-gpios = // may be left unset if it's optional, but what >> // what if it is a required property and in hardware >> // its connected to the RST pin of the module? > >Probably should not be required and the connector driver manages it. > >> other-gpios = <&connector 2>; >> vdd-supply = // what comes here? <&connector VCC_33>? > >That has to be figured out, but *-supply doesn't take arg cells currently. Probably >the connector needs to define its own regulator nodes. > >> interrupts-extended = <&connector 0 ..>; } > So, how to handle the MkcroBus connector? Any suggestion for following? &dspi2 { bus-num = <2>; status = "okay"; /* MikcroBus1 */ spi@0 { compatible = "mikcroe,mikcroe-socket"; reg = <0>; spi-max-frequency = <2000000>; fsl,spi-cs-sck-delay = <1000000>; fsl,spi-sck-cs-delay = <50>; }; };