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?
Attachment:
signature.asc
Description: PGP signature
