On 12/12/2017 05:12 PM, Jagan Teki wrote: > On Tue, Dec 12, 2017 at 9:31 PM, Marek Vasut <marek.va...@gmail.com> wrote: >> 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. > > Yes we would take reference of spi-nor core especially for flash > handling but designed in the U-Boot driver model.
The SPI NOR layer in Linux should fit on top of that quite easily. > direct porting of > Linux spi-nor become another crappy. we have an expertise of how we do > it let's wait for the series to post it on mailing-list. What's the technical argument here ? -- Best regards, Marek Vasut _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
