From: Rob Herring <robh@kernel.org>
To: Michael Walle <michael@walle.cc>
Cc: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>,
Mark Brown <broonie@kernel.org>,
devicetree@vger.kernel.org, Changming Huang <jerry.huang@nxp.com>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Yang-Leo Li <leoyang.li@nxp.com>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
linux-spi <linux-spi@vger.kernel.org>,
Shawn Guo <shawnguo@kernel.org>,
Vladimir Oltean <olteanv@gmail.com>
Subject: Re: [EXT] Re: [PATCH 1/2 v4] dt-bindings: dspi: added for semtech sx1301
Date: Thu, 21 Apr 2022 14:08:21 -0500 [thread overview]
Message-ID: <CAL_JsqJr0fvqL_6CL__Q6aY0AVD+gL4=g46Y=j2r=fJy9jDwGg@mail.gmail.com> (raw)
In-Reply-To: <30f2f62406bab8225cc88013b414016d@walle.cc>
On Thu, Apr 21, 2022 at 10:16 AM Michael Walle <michael@walle.cc> 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 ..>;
> }
Rob
next prev parent reply other threads:[~2022-04-21 19:08 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-20 7:31 [PATCH 1/2 v4] dt-bindings: dspi: added for semtech sx1301 Changming Huang
2022-04-20 7:31 ` [PATCH 2/2 v4] arm64: dts: fsl-ls1028a: add dspi2 support Changming Huang
2022-04-20 12:06 ` [PATCH 1/2 v4] dt-bindings: dspi: added for semtech sx1301 Krzysztof Kozlowski
2022-04-21 9:11 ` [EXT] " Jerry Huang
2022-04-21 9:18 ` Krzysztof Kozlowski
2022-04-21 9:35 ` Jerry Huang
2022-04-21 9:44 ` Michael Walle
2022-04-21 10:06 ` Jerry Huang
2022-04-21 11:08 ` Krzysztof Kozlowski
2022-04-21 11:56 ` Michael Walle
2022-04-21 14:23 ` Rob Herring
2022-04-21 15:16 ` Michael Walle
2022-04-21 19:08 ` Rob Herring [this message]
2022-04-22 2:19 ` Jerry Huang
2022-04-21 14:27 ` Rob Herring
2022-04-20 13:29 ` Rob Herring
2022-04-21 9:12 ` [EXT] " Jerry Huang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAL_JsqJr0fvqL_6CL__Q6aY0AVD+gL4=g46Y=j2r=fJy9jDwGg@mail.gmail.com' \
--to=robh@kernel.org \
--cc=broonie@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=jerry.huang@nxp.com \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=krzysztof.kozlowski@linaro.org \
--cc=leoyang.li@nxp.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-spi@vger.kernel.org \
--cc=michael@walle.cc \
--cc=olteanv@gmail.com \
--cc=shawnguo@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).