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. 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. thanks! -- Jagan Teki Free Software Engineer | www.openedev.com U-Boot, Linux | Upstream Maintainer Hyderabad, India. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
