| Message ID | 20191211193954.747745-1-jean.pihet@newoldbits.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | spi: spi-ti-qspi: Support large NOR SPI flash | expand |
Hi Mark, Tony, Vignesh, Ping on this series V2. Can you please check the reworked patches? BR, Jean On Wed, Dec 11, 2019 at 8:40 PM Jean Pihet <jean.pihet@newoldbits.com> wrote: > > v2 release. > > Large devices are bigger than >64MB in size. > > - Remove unused macro for fclk rate. > - Since the TI QSPI IP block only maps 64MB of MMIO, use MMIO > below the 64MB boundary and software generated transfers above. > - Optimize the software generated byte-transfers for dual and quad > I/O read operations. The speed-up is 4.9x for quad I/O reads. > > Note: depends on Tony's patches for hwmod cleanup, in order to get the > desired QSPI clk rate: > - [PATCH 1/2] ARM: dts: Configure interconnect target module for am4 qspi > - [PATCH 2/2] ARM: OMAP2+: Drop legacy platform data for am4 qspi > > Tested using raw accesses (mtd_debug) and JFFS2 FS read/write/erase; > in single, dual and quad modes. > All accesses have been checked on the logic analyzer. > > Jean Pihet (3): > spi: spi-ti-qspi: Remove unused macro for fclk frequency > spi: spi-ti-qspi: support large flash devices > spi: spi-ti-qspi: optimize byte-transfers > > drivers/spi/spi-ti-qspi.c | 84 ++++++++++++++++++++++++++++++++++++--- > 1 file changed, 79 insertions(+), 5 deletions(-) > > -- > 2.23.0 >
On Tue, Dec 17, 2019 at 01:24:15PM +0100, Jean Pihet wrote: > Hi Mark, Tony, Vignesh, > > Ping on this series V2. Can you please check the reworked patches? Please don't send content free pings and please allow a reasonable time for review. People get busy, go on holiday, attend conferences and so on so unless there is some reason for urgency (like critical bug fixes) please allow at least a couple of weeks for review. If there have been review comments then people may be waiting for those to be addressed. Sending content free pings adds to the mail volume (if they are seen at all) which is often the problem and since they can't be reviewed directly if something has gone wrong you'll have to resend the patches anyway, so sending again is generally a better approach though there are some other maintainers who like them - if in doubt look at how patches for the subsystem are normally handled.
On Fri, Dec 20, 2019 at 12:59 PM Mark Brown <broonie@kernel.org> wrote: > > On Tue, Dec 17, 2019 at 01:24:15PM +0100, Jean Pihet wrote: > > Hi Mark, Tony, Vignesh, > > > > Ping on this series V2. Can you please check the reworked patches? > > Please don't send content free pings and please allow a reasonable time > for review. People get busy, go on holiday, attend conferences and so > on so unless there is some reason for urgency (like critical bug fixes) > please allow at least a couple of weeks for review. If there have been > review comments then people may be waiting for those to be addressed. Sorry about that, I did not know if sending again was better than a (gentle) ping. Thanks for reviewing! Regards, Jean > > Sending content free pings adds to the mail volume (if they are seen at > all) which is often the problem and since they can't be reviewed > directly if something has gone wrong you'll have to resend the patches > anyway, so sending again is generally a better approach though there are > some other maintainers who like them - if in doubt look at how patches > for the subsystem are normally handled.