[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0cf9576d-c50e-4730-834a-3a4ceac6a4f8@sirena.org.uk>
Date: Wed, 19 Jun 2024 22:29:21 +0100
From: Mark Brown <broonie@...nel.org>
To: Marcelo Schmitt <marcelo.schmitt1@...il.com>
Cc: David Lechner <dlechner@...libre.com>,
Marcelo Schmitt <marcelo.schmitt@...log.com>, lars@...afoo.de,
Michael.Hennerich@...log.com, jic23@...nel.org, robh+dt@...nel.org,
krzysztof.kozlowski+dt@...aro.org, conor+dt@...nel.org,
nuno.sa@...log.com, linux-iio@...r.kernel.org,
devicetree@...r.kernel.org, linux-spi@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 1/6] spi: Enable controllers to extend the SPI
protocol with MOSI idle configuration
On Wed, Jun 19, 2024 at 03:58:00PM -0300, Marcelo Schmitt wrote:
> On 06/19, David Lechner wrote:
> > On 6/18/24 6:10 PM, Marcelo Schmitt wrote:
> > > +In this extension to the usual SPI protocol, the MOSI line state is specified to
> > > +be kept high when CS is active but the controller is not clocking out data to
> > I think it would be less ambiguous to say "asserted" instead of "active".
> I'm not sure. IMHO, it looks less ambiguous to say a CS is active.
> I think the most common for CS lines is to have a CS that is active low (i.e.
> the line is at a low voltage level when the controller is selecting the device).
> To me, "assert" sounds closer to the idea o setting something (like a bit to 1),
> which is the opposite of active low CS.
> Though, no strong opinion about it.
> I go with what the maintainers prefer.
I think they're synonyms but asserted is the more common term for chip
selects.
> > > +#define SPI_CONTROLLER_MOSI_IDLE_LOW BIT(8) /* Can idle MOSI low */
> > > +#define SPI_CONTROLLER_MOSI_IDLE_HIGH BIT(9) /* Can idle MOSI high */
> > I don't see where these are used anywhere else in the series. They
> > seem redundant with SPI_MOSI_IDLE_LOW and SPI_MOSI_IDLE_HIGH.
> Good point.
> They are currently not being used.
> Comparing with what we have for SPI_CONTROLLER_MULTI_CS, I'm thinking it may be
> handy to have dt properties to indicate controller MOSI idle capabilities.
> Does that sound reasonable?
We shouldn't need DT properties, we should just know if the controller
supports this based on knowing what controller is, and I'd not expect it
to depend on board wiring.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists