[2/2] spi: sh-msiof: Use DMA if possible

Commit Message

グェン・アン・ホァン Jan. 11, 2019, 8:58 a.m. UTC

From: Hoan Nguyen An <[e-mail]>

Currently, this driver only supports feature for DMA 32-bits.
In this case, only if the data length is divisible by 4 to use
DMA, otherwise PIO will be used. This patch will suggest use
the DMA 32-bits with 4bytes of words, then the remaining data
will be transmitted by PIO mode.

Signed-off-by: Hoan Nguyen An <[e-mail]>
---
 drivers/spi/spi-sh-msiof.c | 8 ++------
 1 file changed, 2 insertions(+), 6 deletions(-)

Comments

Geert Uytterhoeven Jan. 11, 2019, 10:05 a.m. UTC | #1

Hi Hoan,

On Fri, Jan 11, 2019 at 10:27 AM Hoan <[e-mail]> wrote:
> On 2019/01/11 18:09, Geert Uytterhoeven wrote:
> > On Fri, Jan 11, 2019 at 9:59 AM Nguyen An Hoan <[e-mail]> wrote:
> >> From: Hoan Nguyen An <[e-mail]>
> >>
> >> Currently, this driver only supports feature for DMA 32-bits.
> >> In this case, only if the data length is divisible by 4 to use
> >> DMA, otherwise PIO will be used. This patch will suggest use
> >> the DMA 32-bits with 4bytes of words, then the remaining data
> >> will be transmitted by PIO mode.
> >>
> >> Signed-off-by: Hoan Nguyen An <[e-mail]>
> > Thanks for your patch, that's a great idea!
> >
> > Reviewed-by: Geert Uytterhoeven <[e-mail]>
> > with a small suggestion below.
> Currently, I only test the transmit-receive spi with AT25C eeprom,
> because the maximum length of data I test with eeprom is only 18 bytes,
> so with this patch, there will be times when clock timing time and pulse
> of data transmission (I Observed by  sigrock logic analyzer) will not be
> beautiful compared to PIO mode.
> I worry if other devices using this driver also limit the maximum length
> of transmission/reception to 18bytes.

One other issue is that MSIOF drops the hardware chip select in between
transfers.  Before, transfers that fully fit in the FIFO were sent in a
single transfer, keeping the hardware chip select asserted during the
full transfer.
If transfers are split, and you need the chip select to be asserted
during the full transfer, you have to use a GPIO chip select instead.
I believe the split can already happen since your commit 916d9802e4b0723c
("spi: sh-msiof: Reduce the number of times write to and perform the
transmission from FIFO")?

However, for most SPI slave devices (e.g. AT25), that issue is moot, as
they need a GPIO chip select anyway, to avoid dropping the chip select
in between transfers belonging to the same message.

Gr{oetje,eeting}s,

                        Geert

グェン・アン・ホァン Jan. 18, 2019, 8:19 a.m. UTC | #2

Dear Geert-san

Thanks you for your comments!

On 2019/01/11 19:05, Geert Uytterhoeven wrote:
> Hi Hoan,
>
> On Fri, Jan 11, 2019 at 10:27 AM Hoan <[e-mail]> wrote:
>> ....
>> Currently, I only test the transmit-receive spi with AT25C eeprom,
>> because the maximum length of data I test with eeprom is only 18 bytes,
>> so with this patch, there will be times when clock timing time and pulse
>> of data transmission (I Observed by  sigrock logic analyzer) will not be
>> beautiful compared to PIO mode.
>> I worry if other devices using this driver also limit the maximum length
>> of transmission/reception to 18bytes.
> One other issue is that MSIOF drops the hardware chip select in between
> transfers.  Before, transfers that fully fit in the FIFO were sent in a
> single transfer, keeping the hardware chip select asserted during the
> full transfer.
> If transfers are split, and you need the chip select to be asserted
> during the full transfer, you have to use a GPIO chip select instead.
> I believe the split can already happen since your commit 916d9802e4b0723c
> ("spi: sh-msiof: Reduce the number of times write to and perform the
> transmission from FIFO")?

That's right, aligning the maximum message length of 18-bytes current 
with AT25 eeprom.

> However, for most SPI slave devices (e.g. AT25), that issue is moot, as
> they need a GPIO chip select anyway, to avoid dropping the chip select
> in between transfers belonging to the same message.
But I worry here is whether other devices using spi also align data? I 
think not.
So with SPI-MSIOF as SPI driver, we serve all devices using SPI, not 
only EEPROM,
and we don't care what Slave is. As far as code and theory is concerned,
I think there is no problem.
So I will update this patch.


Thanks you very much!

Hoan.


> Gr{oetje,eeting}s,
>
>                          Geert
>

Patch

diff --git a/drivers/spi/spi-sh-msiof.c b/drivers/spi/spi-sh-msiof.c
index 64adf34..241cc6e 100644
--- a/drivers/spi/spi-sh-msiof.c
+++ b/drivers/spi/spi-sh-msiof.c
@@ -937,17 +937,13 @@  static int sh_msiof_transfer_one(struct spi_master *master,
 		unsigned int l = 0;
 
 		if (tx_buf)
-			l = min(len, p->tx_fifo_size * 4);
+			l = min(len - len % 4, p->tx_fifo_size * 4);
 		if (rx_buf)
-			l = min(len, p->rx_fifo_size * 4);
+			l = min(len - len % 4, p->rx_fifo_size * 4);
 
 		if (bits <= 8) {
-			if (l & 3)
-				break;
 			copy32 = copy_bswap32;
 		} else if (bits <= 16) {
-			if (l & 3)
-				break;
 			copy32 = copy_wswap32;
 		} else {
 			copy32 = copy_plain32;