From: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
To: Fabio Estevam <festevam@gmail.com>
Cc: Shawn Guo <shawnguo@kernel.org>,
Sascha Hauer <s.hauer@pengutronix.de>,
Pengutronix Kernel Team <kernel@pengutronix.de>,
NXP Linux Team <linux-imx@nxp.com>,
"moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE"
<linux-arm-kernel@lists.infradead.org>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/2] ARM: dts: imx6qdl: tqma6: minor fixes
Date: Thu, 27 Aug 2020 09:31:09 +0200 [thread overview]
Message-ID: <9978aff9c90f5e4aa2049a5c65768b9695a910c5.camel@ew.tq-group.com> (raw)
In-Reply-To: <CAOMZO5AfuPXfOmRSXAmyG-bdqGSzvTRm51NuTJ-B2PzKbLy9mw@mail.gmail.com>
On Wed, 2020-08-26 at 10:49 -0300, Fabio Estevam wrote:
> On Wed, Aug 26, 2020 at 10:13 AM Matthias Schiffer
> <matthias.schiffer@ew.tq-group.com> wrote:
>
> > Using GPIOs for chipselect would require different pinmuxing. Also,
> > why
> > use GPIOs, when the SPI controller has this built in?
>
> In the initial chips with the ECSPI controller there was a bug with
> the native chipselect controller and we had to use GPIO.
Ah, I see.
Nevertheless, hardware that uses the native chipselects of newer chips
exists (for example our TQ-Systems starterkit mainboards, the DTS of
which we're currently preparing for mainline submission). Shouldn't
num-cs be set for boards (or SoM DTSI) where not all CS pins of the SoC
are usable?
In any case, my original question was about the intended logic for
num_chipselects for SPI drivers. My proposal was:
- If num-cs is set, use that
- If num-cs is unset, use the number of cs-gpios
- If num-cs is unset and no cs-gpios are defined, use a driver-provided
default
How do other SPI controller drivers deal with this?
next prev parent reply other threads:[~2020-08-27 7:31 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-24 9:10 [PATCH 1/2] ARM: dts: imx6qdl: tqma6: fix indentation Matthias Schiffer
2020-08-24 9:10 ` [PATCH 2/2] ARM: dts: imx6qdl: tqma6: minor fixes Matthias Schiffer
2020-08-24 21:36 ` Fabio Estevam
2020-08-25 7:22 ` (EXT) " Matthias Schiffer
2020-08-25 14:24 ` Fabio Estevam
2020-08-25 14:40 ` (EXT) " Matthias Schiffer
2020-08-25 17:16 ` Fabio Estevam
2020-08-26 10:32 ` (EXT) " Matthias Schiffer
2020-08-26 10:34 ` Matthias Schiffer
2020-08-26 10:59 ` Fabio Estevam
2020-08-26 11:54 ` (EXT) " Matthias Schiffer
2020-08-26 13:01 ` Fabio Estevam
2020-08-26 13:13 ` (EXT) " Matthias Schiffer
2020-08-26 13:49 ` Fabio Estevam
2020-08-27 7:31 ` Matthias Schiffer [this message]
2020-08-27 21:27 ` Fabio Estevam
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=9978aff9c90f5e4aa2049a5c65768b9695a910c5.camel@ew.tq-group.com \
--to=matthias.schiffer@ew.tq-group.com \
--cc=festevam@gmail.com \
--cc=kernel@pengutronix.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-imx@nxp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=s.hauer@pengutronix.de \
--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).