Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19;
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
Date:   Thu, 21 Apr 2022 17:16:40 +0200
From:   Michael Walle <michael@walle.cc>
To:     Rob Herring <robh@kernel.org>
Cc:     krzysztof.kozlowski@linaro.org, broonie@kernel.org,
        devicetree@vger.kernel.org, jerry.huang@nxp.com,
        krzysztof.kozlowski+dt@linaro.org, leoyang.li@nxp.com,
        linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org,
        linux-spi@vger.kernel.org, shawnguo@kernel.org,
        Vladimir Oltean <olteanv@gmail.com>
Subject: Re: [EXT] Re: [PATCH 1/2 v4] dt-bindings: dspi: added for semtech
 sx1301
In-Reply-To: <YmFo+EntwxIsco/t@robh.at.kernel.org>
References: <f6086989-a4c1-4223-fad0-79bd5719432e@linaro.org>
 <20220421094421.288672-1-michael@walle.cc>
 <YmFo+EntwxIsco/t@robh.at.kernel.org>
User-Agent: Roundcube Webmail/1.4.13
Message-ID: <30f2f62406bab8225cc88013b414016d@walle.cc>
Precedence: bulk

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?

And all the child device properties will reference the connector,
correct?

> 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 = <&reg33>;
> 	vcc-5-supply = <&reg5v>;
> 
> 	i2c-parent = <&i2c1>; // Already a defined property
> 	spi-parent = <&spi0>; // New

uart/serial needed too?

> 
> 	// 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
   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?
   other-gpios = <&connector 2>;
   vdd-supply = // what comes here? <&connector VCC_33>?
   interrupts-extended = <&connector 0 ..>;
}

-michael

> 		//devices
> 	};
> 
> 	i2c {
> 
> 	};
> };
> 
> The DT spec defines 'foo-map' properties extending interrupt-map.
> Currently only GPIO is defined. We might want to do the same thing for
> PWM. Or we make the connector node both a PWM consumer and provider.
> 
> Rob