Received-SPF: pass (google.com: domain of linux-kernel+bounces-202954-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Date: Wed, 5 Jun 2024 18:04:08 +0100
From: Mark Brown <broonie@kernel.org>
To: David Lechner <dlechner@baylibre.com>
Cc: Marcelo Schmitt <marcelo.schmitt@analog.com>, lars@metafoo.de,
	Michael.Hennerich@analog.com, jic23@kernel.org, robh+dt@kernel.org,
	krzysztof.kozlowski+dt@linaro.org, conor+dt@kernel.org,
	nuno.sa@analog.com, marcelo.schmitt1@gmail.com,
	linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
	linux-spi@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 1/6] spi: Add SPI mode bit for MOSI idle state
 configuration
Message-ID: <d09485bf-bbb5-4a3f-84b8-54478c6d78cf@sirena.org.uk>
References: <cover.1717539384.git.marcelo.schmitt@analog.com>
 <e1d5d57f7a7481c84f64a764f9898122e278739b.1717539384.git.marcelo.schmitt@analog.com>
 <0a716b10-0ae0-425f-919a-ea5d8b7975b6@sirena.org.uk>
 <5dcd9701-2725-4aff-9e73-d8f2e038be75@baylibre.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="wKVoeLpN0Xiqr2ia"
Content-Disposition: inline
In-Reply-To: <5dcd9701-2725-4aff-9e73-d8f2e038be75@baylibre.com>


--wKVoeLpN0Xiqr2ia
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Wed, Jun 05, 2024 at 11:37:48AM -0500, David Lechner wrote:
> On 6/5/24 7:24 AM, Mark Brown wrote:
> > On Tue, Jun 04, 2024 at 07:41:47PM -0300, Marcelo Schmitt wrote:

> >> The behavior of an SPI controller data output line (SDO or MOSI or COPI
> >> (Controller Output Peripheral Input) for disambiguation) is not specified
> >> when the controller is not clocking out data on SCLK edges. However, there
> >> exist SPI peripherals that require specific COPI line state when data is
> >> not being clocked out of the controller.

> I think this description is missing a key detail that the tx data line
> needs to be high just before and also during the CS assertion at the start
> of each message.

> And it would be helpful to have this more detailed description in the
> source code somewhere and not just in the commit message.

Yes, there's no way anyone could infer this from any aspect of the
series.  I think the properties also need a clearer name since someone
might want the accelerator functionality at some point.

> > Even without that we'd need feature detection so that drivers that try
> > to use this aren't just buggy when used with a controller that doesn't
> > implement it, but once you're detecting you may as well just make things
> > work.

> I could see something like this working for controllers that leave the
> tx data line in the state of the last bit of a write transfer. I.e. do a
> write transfer of 0xff (using the smallest number of bits per word
> supported by the controller) with CS not asserted, then assert CS, then
> do the rest of actual the transfers requested by the peripheral.

> But it doesn't seem like it would work for controllers that always
> return the tx data line to a low state after a write since this would
> mean that the data line would still be low during the CS assertion
> which is what we need to prevent.

With the additional requirement it's not emulatable, but we'd still need
the checks in the core.

--wKVoeLpN0Xiqr2ia
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmZgmocACgkQJNaLcl1U
h9ArVwf8Dw4cgSZA69ycN+jnU1O7GS21AXkT9STiTg+vHwxg7SZJsCwtzQUGOUqF
M5EbV1HogtLSrpupF3CYPuXqR8KoM3oQ71kQwGIBY8YNkumwuixOpkDGYhGRAM1g
HZYoyKBMeEIIKJj+Em/CmdnB/q0I1uBLYWwAZ8WcrNt6fyM08spwl1hWdXZeHwCs
52Yh9wVOaJhoNAvkUTpFQH7WfcosMA/rt1Db2cNpREp7WlcsRAaBTioff1MxAYzE
QSaN4KAGa6mqj6fUV90RP5VvJgBuzW8NbLPPcmrtCrP3VOlL5L4XssJ4qKYLuDzA
kSFzJwGtzOVx2BrKpxReUjWERRNNFQ==
=g6Wl
-----END PGP SIGNATURE-----

--wKVoeLpN0Xiqr2ia--