On Tue, Dec 12, 2017 at 11:44 AM, Prabhakar Kushwaha <prabhakar.kushw...@nxp.com> wrote: > Hi Marek, > >> -----Original Message----- >> From: Marek Vasut [mailto:marek.va...@gmail.com] >> Sent: Monday, December 11, 2017 3:04 PM >> To: Prabhakar Kushwaha <prabhakar.kushw...@nxp.com>; u- >> b...@lists.denx.de >> Cc: jagannadh.t...@gmail.com; Poonam Aggrwal >> <poonam.aggr...@nxp.com>; Suresh Gupta <suresh.gu...@nxp.com>; >> cyrille.pitc...@atmel.com >> Subject: Re: [RFC 0/5] sf: Update spi-nor framework >> >> On 12/11/2017 06:57 AM, Prabhakar Kushwaha wrote: >> > SPI-NOR framework currently supports- >> > - (1-1-1, 1-1-2, 1-1-4) read protocols >> > - read latency(dummy bytes) are hardcoded with the assumption >> > that the flash would support it. >> > - No support of mode bits. >> > - No support of flash size above 128Mib >> > >> > This patch set add support of 1-2-2, 1-4-4 read protocols. >> > It ports Linux commits "mtd: spi-nor: add a stateless method to support >> > memory size above 128Mib" and "mtd: spi-nor: parse Serial Flash >> > Discoverable Parameters (SFDP) tables". It enables 4byte address opcode >> > and run time flash parameters discovery including dummy cycle and mode >> > cycle. >> > >> > Finally it update fsl-quadspi driver to store(set_mode) spi bus mode and >> > provision for run-time LUTs creation. >> > >> > Note: This patch-set is only **compliation** tested. Sending RFC to get >> > early feed-back on the approach. >> > >> > Prabhakar Kushwaha (5): >> > sf: Add support of 1-2-2, 1-4-4 IO READ protocols >> > sf: add method to support memory size above 128Mib >> > sf: parse Serial Flash Discoverable Parameters (SFDP) tables >> > sf: fsl_qspi: Add support of fsl_qspi_set_mode >> > sf: fsl_quadspi: Configue LUT based on padding information >> > >> > drivers/mtd/spi/sf_internal.h | 230 +++++++++++++++- >> > drivers/mtd/spi/spi_flash.c | 574 >> +++++++++++++++++++++++++++++++++++++++- >> > drivers/spi/fsl_qspi.c | 85 +++++- >> > include/spi_flash.h | 2 + >> > 5 files changed, 875 insertions(+), 18 deletions(-) >> > >> >> Could you rather port the entire SPI NOR framework from Linux 4.14 ? >> That'd make more sense than porting bits and pieces on top of the >> current crappy code IMO. > > I agree with you. Linux 4.14 SPI NOR framework should be ported. > I may not able to do this because of bandwidth and lack of expertise. > I will request Jagan (custodian) to look into this. > > This RFC patch-set can easily be applied to existing and ported Linux SPI > NOR framework when it gets available. > > For now, I think these patches(the next version) with the existing framework > can be reviewed and accepted. > Please help to share your views. > > For next version of this patch set, I will be working on testing it to > enable other flashes. > It will also help Jagan during 4.14 porting. > Jagan, your views?
direct-porting from Linux is not so optimal(not well suited for U-Boot design) as I've tried before. We're working on the dm-driven spi-nor. So I will continue to review your patches on current code and will see how we can merge the same once dm-spi-nor available. Jagan. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
