Hi, Piotr, General things to consider for the limitation in performance: - is the serial flash memory operating in Quad SPI? - QSCLK should be as high as possible - transfer delays - I checked them, they have default values, we should be good. - use DMA, as you suggested On 06/22/2018 10:39 AM, Boris Brezillon wrote: > [...] > >>>> +/* >>>> + * Atmel SAMA5D2 QuadSPI driver. >>>> + * >>>> + * Copyright (C) 2018 Cryptera A/S >>> >>> A non-negligible portion of this code has been copied from the existing >>> driver. Please keep the existing copyright (you can still add Cryptera's >>> one). >>> >> >> Technically this driver were written from scratch, with spi-fsl-qspi >> as example of new interface. Hence the name and code structure. >> But it's the same peripheral as Atmel's driver uses so code looks >> similar. I can unify the code to make comparsion even simpler and >> then update copyright. > > Hm, ok. Some constructs really looked like they were copied > from the old driver, hence my comment. I'll let Nicolas give his > opinion on this aspect. This driver will be a conversion of the legacy one to the spi-mem interface. I would keep the legacy copyright and add Cryptera's below, as Boris suggested. [...] >>>> +#define QSPI_SR_CMD_COMPLETED (QSPI_SR_INSTRE | QSPI_SR_CSR) >>> >>> Do you really to wait for both INSTRE and CSR to consider the command >>> as complete? >>> >> >> This part were really copied from Atmel driver. I wasn't sure so I >> used tested solution. > > Okay. I guess that's a question for Cyrille and/or Tudor then. We have to wait for both INSTRE and CSR. Best, ta -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
