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 <na-h...@jinso.co.jp> 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
