It was <2020-08-19 śro 14:38>, when Krzysztof Kozlowski wrote:
On Wed, Aug 19, 2020 at 02:32:01PM +0200, Łukasz Stelmach wrote:
quoted
Fix issues with DMA transfers bigger than 512 on Exynos3250.
Fix, but how? With proper explanation this should go to CC-stable.
Honestly, I don't know and I couldn't find out why. It makes stuff
work. There has been a commit like this before
0f5a751ace25 spi/s3c64xx: Enable GPIO /CS prior to starting hardware
Apparently, it was lost in
0732a9d2a155 spi/s3c64xx: Use core message handling
quoted
Signed-off-by: Łukasz Stelmach <l.stelmach@samsung.com>
---
drivers/spi/spi-s3c64xx.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c
index cf67ea60dc0e..fb5e2ba4b6b9 100644
--- a/drivers/spi/spi-s3c64xx.c
+++ b/drivers/spi/spi-s3c64xx.c
@@ -678,11 +678,11 @@ static int s3c64xx_spi_transfer_one(struct spi_master *master,
sdd->state &= ~RXBUSY;
sdd->state &= ~TXBUSY;
- s3c64xx_enable_datapath(sdd, xfer, use_dma);
-
/* Start the signals */
s3c64xx_spi_set_cs(spi, true);
+ s3c64xx_enable_datapath(sdd, xfer, use_dma);
+
spin_unlock_irqrestore(&sdd->lock, flags);
if (use_dma)
--
2.26.2
--
Łukasz Stelmach
Samsung R&D Institute Poland
Samsung Electronics
On Wed, Aug 19, 2020 at 02:51:27PM +0200, Lukasz Stelmach wrote:
It was <2020-08-19 śro 14:38>, when Krzysztof Kozlowski wrote:
quoted
On Wed, Aug 19, 2020 at 02:32:01PM +0200, Łukasz Stelmach wrote:
quoted
Fix issues with DMA transfers bigger than 512 on Exynos3250.
Fix, but how? With proper explanation this should go to CC-stable.
Honestly, I don't know and I couldn't find out why. It makes stuff
work. There has been a commit like this before
0f5a751ace25 spi/s3c64xx: Enable GPIO /CS prior to starting hardware
Apparently, it was lost in
0732a9d2a155 spi/s3c64xx: Use core message handling
Then describe at least this... maybe Mark knows why he brough back old
code after refactoring?
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
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:
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
0f5a751ace25 spi/s3c64xx: Enable GPIO /CS prior to starting hardware
quoted
Apparently, it was lost in
quoted
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. 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). 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.