[PATCH 1/8] spi: spi-s3c64xx: swap s3c64xx_spi_set_cs() and s3c64xx_enable_datapath()

[Mark Brown]

On Wed, Aug 19, 2020 at 04:01:52PM +0200, Lukasz Stelmach wrote:
> It was <2020-08-19 śro 14:16>, when Mark Brown wrote:
> > On Wed, Aug 19, 2020 at 02:58:22PM +0200, Krzysztof Kozlowski wrote:
> >> On Wed, Aug 19, 2020 at 02:51:27PM +0200, Lukasz Stelmach wrote:

> >> >     0732a9d2a155 spi/s3c64xx: Use core message handling

> >> Then describe at least this... maybe Mark knows why he brough back old
> >> code after refactoring?

> > I'm not sure what's being referred to as being lost in the second commit
> > TBH.

> Order of enable_cs() and enable_datapath(). The order 0f5a sets makes
> (for a reaseon I don't know) my devices work. In the latter commit,
> which rewrites "everything", enable_datapath() is called before what
> later (in aa4964c4eb3e) became s3c64xx_spi_set_cs().

That's doesn't look like what the changes do.  Note that the enable_cs()
function that got moved in 0f5a751ace250097 (spi/s3c64xx: Enable GPIO
/CS prior to starting hardware) does not touch the chip registers at
all, it only manipulates GPIOs, code that was subsequently factored out
into the core.  The write to the _SLAVE_SEL register has so far as I can
see always been after enable_datapath() right back to the initial
commit, it just got made more complex for the Exynos7 controller (I'm
guessing your new one might be an ancestor of that?) in bf77cba95f8c06
(spi: s3c64xx: add support for exynos7 SPI controller) and then factored
out in the commit you mention above.

Are you sure your new ordering works for all controller revisions?
According to the comment the _set_cs() is what's actually kicking off
the transfer which suggests that the data/DMA needed to be ready
beforehand to avoid an underflow or something (and nobody reported
issues before, I know people have done things like downloaded firmwares
using this controller...), this could be something that got changed
between revisions.

Please include human readable descriptions of things like commits and
issues being discussed in e-mail in your mails, this makes them much
easier for humans to read especially when they have no internet access.

> > The first commit is simple code motion rather than a correctness
> > thing, and more related to the handling of GPIO controlled chip
> > selects according to the description (which people should be using
> > with that controller anyway where possible IIRC, the native chip
> > select has too many assumptions about what it's doing).

> Funny, but without the automatic CS control (see the next patch in this
> series) my stuff does not work.

There's two things, there's changing the controller registers and there
is the use of the signal coming out of the controller as the chip select
that the device on the SPI bus sees.  Most systems have pinmuxing which
allows the internal chip select to just not be connected to anything
which is what I'm talking about in the above text, IIRC all versions of
the controller have unfortunate assumptions about how chip selects
should work which make GPIO controlled chip selects much better.

> > I don't know that I ever actually used a system that used the native
> > chip select as the actual chip select.  Perhaps some quirk was
> > introduced where the chip select signal does something?

> > The commit is also lacking a description of what the issues that are
> > being fixed are.

> On Exynos3250 DMA transfers from SPI longer than 512 fail.

Could you expand on "fail" please?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20200819/1fbd5b73/attachment.sig>