Hi Arnd, + Nicolas Ferre
Le 01/08/2017 à 22:10, Arnd Bergmann a écrit : > On Tue, Aug 1, 2017 at 9:41 PM, Cyrille Pitchen > <[email protected]> wrote: >> Le 22/07/2017 à 00:21, Arnd Bergmann a écrit : > >>> --- a/drivers/mtd/spi-nor/atmel-quadspi.c >>> +++ b/drivers/mtd/spi-nor/atmel-quadspi.c >>> @@ -208,9 +208,9 @@ static int atmel_qspi_run_transfer(struct atmel_qspi >>> *aq, >>> if (cmd->enable.bits.address) >>> ahb_mem += cmd->address; >>> if (cmd->tx_buf) >>> - _memcpy_toio(ahb_mem, cmd->tx_buf, cmd->buf_len); >>> + memcpy_toio(ahb_mem, cmd->tx_buf, cmd->buf_len); >>> else >>> - _memcpy_fromio(cmd->rx_buf, ahb_mem, cmd->buf_len); >>> + memcpy_fromio(cmd->rx_buf, ahb_mem, cmd->buf_len); >>> >> >> At least on AT91 platforms and likely on most ARM boards, >> memcpy_fromio == memcpy_toio == memcpy. > > Just to give more background, it's a bit more complicated than this: > > On big-endian kernels, memcpy_fromio/memcpy_toio are > always defined as _memcpy_fromio/_memcpy_toio so we > do byte load/store operations in the correct order, while > little-endian kernels have the optimized mmiocpy() that redirects > to memcpy(). This is true for all ARM platforms other than EBSA110 > IIRC. > > Also, mmiocpy is an exported symbol that aliases to the external > memcpy definition, but we can't call memcpy directly, because gcc > knows how to inline calls to memcpy() and replace them by direct > load/store instructions that might be unaligned and trap on uncached > mmio areas. > >> I got some sama5d2 hardware last week, so I'll try to test your patch >> within few days because as you said maybe memcpy() was broken when I >> developed this driver at first but now memcpy() is likely to have been >> fixed so it might be interesting to get rid of _memcpy_fromio() and >> _memcpy_toio() because this is not the first time those 2 functions have >> created issues when building the Atmel Quad SPI driver on other platforms. >> >> So thanks for you're patch, I'll give it a try :) > Bad news: I've just tested this patch, applied onto the spi-nor/next branch of l2-mtd (based on 4.14.0-rc4), with a sama5d2 xplained board + Macronix MX25L25673G Quad SPI memory but it fails on the very first SPI command, Read JEDEC ID (9Fh): atmel_qspi f0020000.spi: unrecognized JEDEC id bytes: c2, 20, 20 atmel_qspi: probe of f0020000.spi failed with error -2 Best regards, Cyrille > Ok, thanks. > > Arnd >
