[PATCH 1/2] spi: pxa2xx: Update comment in int_transfer_complete()

[PATCH 1/2] spi: pxa2xx: Update comment in int_transfer_complete()

[Jarkko Nikula]

The register writes here actually don't stop the SSP but clean and
disable interrupts and set the receive FIFO inactivity timeout to zero.

Signed-off-by: Jarkko Nikula <jarkko.nikula-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
---
 drivers/spi/spi-pxa2xx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c
index 227e8bad19e6..9b9a528a9fbd 100644
--- a/drivers/spi/spi-pxa2xx.c
+++ b/drivers/spi/spi-pxa2xx.c
@@ -572,7 +572,7 @@ static void int_error_stop(struct driver_data *drv_data, const char* msg)
 
 static void int_transfer_complete(struct driver_data *drv_data)
 {
-	/* Stop SSP */
+	/* Clear and disable interrupts */
 	write_SSSR_CS(drv_data, drv_data->clear_sr);
 	reset_sccr1(drv_data);
 	if (!pxa25x_ssp_comp(drv_data))
-- 
2.7.0

--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/2] spi: pxa2xx: Fix too early chipselect deassert

[Jarkko Nikula]

There is a chance that chipselect is deasserted too early while the last
clock cycle is still running. Protocol analyzers will see this as a failed
last byte. This is more likely to occur with slow bitrates, for instance
at 25 kbps.

Reason for this is when using SPI mode 0 that both SPI host controller and
SPI slave will drive the data lines at the falling edge of clock signal
and sample at the rising edge. Receive FIFO gets the last bit now at the
rising edge and code sees transfer to be finished either by the interrupt
in PIO mode or by the DMA completion in DMA mode.

The SSP Time Out register SSTO should take care of delaying the
completion but it does not seems to have effect at least on Intel
Skylake and Broxton even when using long enough values. Depending on
timing code may get into point where chipselect is deasserted while the
last clock cycle is still running at its second half cycle.

Fix this by adding a wait loop in giveback() that waits until SSP becomes
idle before deasserting the chipselect.

Reported-by: Weifeng Voon <weifeng.voon-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Signed-off-by: Jarkko Nikula <jarkko.nikula-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
---
For normal development cycle. This is not a fatal issue and I guess real SPI
slaves may not hickup because of it. But you never know.
---
 drivers/spi/spi-pxa2xx.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c
index 9b9a528a9fbd..ce66cf44bba5 100644
--- a/drivers/spi/spi-pxa2xx.c
+++ b/drivers/spi/spi-pxa2xx.c
@@ -496,6 +496,7 @@ static void giveback(struct driver_data *drv_data)
 {
 	struct spi_transfer* last_transfer;
 	struct spi_message *msg;
+	unsigned long timeout;
 
 	msg = drv_data->cur_msg;
 	drv_data->cur_msg = NULL;
@@ -508,6 +509,12 @@ static void giveback(struct driver_data *drv_data)
 	if (last_transfer->delay_usecs)
 		udelay(last_transfer->delay_usecs);
 
+	/* Wait until SSP becomes idle before deasserting the CS */
+	timeout = jiffies + msecs_to_jiffies(10);
+	while (pxa2xx_spi_read(drv_data, SSSR) & SSSR_BSY &&
+	       !time_after(jiffies, timeout))
+		cpu_relax();
+
 	/* Drop chip select UNLESS cs_change is true or we are returning
 	 * a message with an error, or next message is for another chip
 	 */
-- 
2.7.0

--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Applied "spi: pxa2xx: Fix too early chipselect deassert" to the spi tree

[Mark Brown]

The patch

   spi: pxa2xx: Fix too early chipselect deassert

has been applied to the spi tree at

   git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From 7a8d44bc89e5cddcd5c0704a11a90484d36ba6ba Mon Sep 17 00:00:00 2001
From: Jarkko Nikula <jarkko.nikula-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Date: Thu, 4 Feb 2016 12:30:57 +0200
Subject: [PATCH] spi: pxa2xx: Fix too early chipselect deassert

There is a chance that chipselect is deasserted too early while the last
clock cycle is still running. Protocol analyzers will see this as a failed
last byte. This is more likely to occur with slow bitrates, for instance
at 25 kbps.

Reason for this is when using SPI mode 0 that both SPI host controller and
SPI slave will drive the data lines at the falling edge of clock signal
and sample at the rising edge. Receive FIFO gets the last bit now at the
rising edge and code sees transfer to be finished either by the interrupt
in PIO mode or by the DMA completion in DMA mode.

The SSP Time Out register SSTO should take care of delaying the
completion but it does not seems to have effect at least on Intel
Skylake and Broxton even when using long enough values. Depending on
timing code may get into point where chipselect is deasserted while the
last clock cycle is still running at its second half cycle.

Fix this by adding a wait loop in giveback() that waits until SSP becomes
idle before deasserting the chipselect.

Reported-by: Weifeng Voon <weifeng.voon-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Signed-off-by: Jarkko Nikula <jarkko.nikula-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Signed-off-by: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
 drivers/spi/spi-pxa2xx.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c
index 9b9a528a9fbd..ce66cf44bba5 100644
--- a/drivers/spi/spi-pxa2xx.c
+++ b/drivers/spi/spi-pxa2xx.c
@@ -496,6 +496,7 @@ static void giveback(struct driver_data *drv_data)
 {
 	struct spi_transfer* last_transfer;
 	struct spi_message *msg;
+	unsigned long timeout;
 
 	msg = drv_data->cur_msg;
 	drv_data->cur_msg = NULL;
@@ -508,6 +509,12 @@ static void giveback(struct driver_data *drv_data)
 	if (last_transfer->delay_usecs)
 		udelay(last_transfer->delay_usecs);
 
+	/* Wait until SSP becomes idle before deasserting the CS */
+	timeout = jiffies + msecs_to_jiffies(10);
+	while (pxa2xx_spi_read(drv_data, SSSR) & SSSR_BSY &&
+	       !time_after(jiffies, timeout))
+		cpu_relax();
+
 	/* Drop chip select UNLESS cs_change is true or we are returning
 	 * a message with an error, or next message is for another chip
 	 */
-- 
2.7.0.rc3

--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Applied "spi: pxa2xx: Update comment in int_transfer_complete()" to the spi tree

[Mark Brown]

The patch

   spi: pxa2xx: Update comment in int_transfer_complete()

has been applied to the spi tree at

   git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From 07550df04712c88717d2ab6578bb36bbd4305e35 Mon Sep 17 00:00:00 2001
From: Jarkko Nikula <jarkko.nikula-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Date: Thu, 4 Feb 2016 12:30:56 +0200
Subject: [PATCH] spi: pxa2xx: Update comment in int_transfer_complete()

The register writes here actually don't stop the SSP but clean and
disable interrupts and set the receive FIFO inactivity timeout to zero.

Signed-off-by: Jarkko Nikula <jarkko.nikula-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Signed-off-by: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
 drivers/spi/spi-pxa2xx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c
index 227e8bad19e6..9b9a528a9fbd 100644
--- a/drivers/spi/spi-pxa2xx.c
+++ b/drivers/spi/spi-pxa2xx.c
@@ -572,7 +572,7 @@ static void int_error_stop(struct driver_data *drv_data, const char* msg)
 
 static void int_transfer_complete(struct driver_data *drv_data)
 {
-	/* Stop SSP */
+	/* Clear and disable interrupts */
 	write_SSSR_CS(drv_data, drv_data->clear_sr);
 	reset_sccr1(drv_data);
 	if (!pxa25x_ssp_comp(drv_data))
-- 
2.7.0.rc3

--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] spi: pxa2xx: Update comment in int_transfer_complete()

[Robert Jarzmik]

Jarkko Nikula <jarkko.nikula-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> writes:

> The register writes here actually don't stop the SSP but clean and
> disable interrupts and set the receive FIFO inactivity timeout to zero.
>
> Signed-off-by: Jarkko Nikula <jarkko.nikula-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Acked-by: Robert Jarzmik <robert.jarzmik-GANU6spQydw@public.gmane.org>

Cheers.

-- 
Robert
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] spi: pxa2xx: Fix too early chipselect deassert

[Robert Jarzmik]

Jarkko Nikula <jarkko.nikula-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> writes:

> There is a chance that chipselect is deasserted too early while the last
> clock cycle is still running. Protocol analyzers will see this as a failed
> last byte. This is more likely to occur with slow bitrates, for instance
> at 25 kbps.
>
> Reason for this is when using SPI mode 0 that both SPI host controller and
> SPI slave will drive the data lines at the falling edge of clock signal
> and sample at the rising edge. Receive FIFO gets the last bit now at the
> rising edge and code sees transfer to be finished either by the interrupt
> in PIO mode or by the DMA completion in DMA mode.
>
> The SSP Time Out register SSTO should take care of delaying the
> completion but it does not seems to have effect at least on Intel
> Skylake and Broxton even when using long enough values. Depending on
> timing code may get into point where chipselect is deasserted while the
> last clock cycle is still running at its second half cycle.
>
> Fix this by adding a wait loop in giveback() that waits until SSP becomes
> idle before deasserting the chipselect.
>
> Reported-by: Weifeng Voon <weifeng.voon-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> Signed-off-by: Jarkko Nikula <jarkko.nikula-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
> ---
> For normal development cycle. This is not a fatal issue and I guess real SPI
> slaves may not hickup because of it. But you never know.

I feel quite nervous about this one, as it will affect all pxa variants, for a
Skylake and Broxton issues.

What makes me even more nervous is that I don't have a way to test it yet ...

I will neither ack nor block it, let's have others judge it first.

Cheers.

-- 
Robert
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] spi: pxa2xx: Fix too early chipselect deassert

[Jarkko Nikula]

On 02/04/2016 11:01 PM, Robert Jarzmik wrote:
> Jarkko Nikula <jarkko.nikula-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> writes:
>
>> There is a chance that chipselect is deasserted too early while the last
>> clock cycle is still running. Protocol analyzers will see this as a failed
>> last byte. This is more likely to occur with slow bitrates, for instance
>> at 25 kbps.
>>
>> Reason for this is when using SPI mode 0 that both SPI host controller and
>> SPI slave will drive the data lines at the falling edge of clock signal
>> and sample at the rising edge. Receive FIFO gets the last bit now at the
>> rising edge and code sees transfer to be finished either by the interrupt
>> in PIO mode or by the DMA completion in DMA mode.
>>
>> The SSP Time Out register SSTO should take care of delaying the
>> completion but it does not seems to have effect at least on Intel
>> Skylake and Broxton even when using long enough values. Depending on
>> timing code may get into point where chipselect is deasserted while the
>> last clock cycle is still running at its second half cycle.
>>
>> Fix this by adding a wait loop in giveback() that waits until SSP becomes
>> idle before deasserting the chipselect.
>>
>> Reported-by: Weifeng Voon <weifeng.voon-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
>> Signed-off-by: Jarkko Nikula <jarkko.nikula-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
>> ---
>> For normal development cycle. This is not a fatal issue and I guess real SPI
>> slaves may not hickup because of it. But you never know.
>
> I feel quite nervous about this one, as it will affect all pxa variants, for a
> Skylake and Broxton issues.
>
> What makes me even more nervous is that I don't have a way to test it yet ...
>
> I will neither ack nor block it, let's have others judge it first.
>
I didn't see reason to do this conditionally as pxa2xx_spi_flush() is 
polling the busy bit too. However your question reminded me I haven't 
looked the PXA data sheets at all but just the code only that changes 
don't break the existing PXA cases.

According to PXA3xx datasheet the busy bit is defined as in Intel platforms.

-- 
Jarkko
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html