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:

quoted

On Wed, Aug 19, 2020 at 02:51:27PM +0200, Lukasz Stelmach wrote:

quoted

quoted

Honestly, I don't know and I couldn't find out why. It makes stuff
work. There has been a commit like this before

quoted

quoted

    0f5a751ace25 spi/s3c64xx: Enable GPIO /CS prior to starting hardware

quoted

quoted

Apparently, it was lost in

quoted

quoted

    0732a9d2a155 spi/s3c64xx: Use core message handling

quoted

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().

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.

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.

-- 
Łukasz Stelmach
Samsung R&D Institute Poland
Samsung Electronics