On 12/12/2017 08:37 AM, Jagan Teki wrote: > 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.
Care to elaborate on the technical problems ? I am also CCing the Linux SPI NOR maintainers, since I believe the Linux SPI NOR framework is far superior compared to the stuff that's now in U-Boot and sharing the code as much as possible would only make sense rather than writing our own barely-maintained and crappy implementation. > 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. > -- Best regards, Marek Vasut _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot