[U-Boot] [RFC 0/5] sf: Update spi-nor framework

[Marek Vasut]

On 12/12/2017 05:12 PM, Jagan Teki wrote:
> On Tue, Dec 12, 2017 at 9:31 PM, Marek Vasut <marek.vasut at 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.kushwaha at nxp.com> wrote:
>>>> Hi Marek,
>>>>
>>>>> -----Original Message-----
>>>>> From: Marek Vasut [mailto:marek.vasut at gmail.com]
>>>>> Sent: Monday, December 11, 2017 3:04 PM
>>>>> To: Prabhakar Kushwaha <prabhakar.kushwaha at nxp.com>; u-
>>>>> boot at lists.denx.de
>>>>> Cc: jagannadh.teki at gmail.com; Poonam Aggrwal
>>>>> <poonam.aggrwal at nxp.com>; Suresh Gupta <suresh.gupta at nxp.com>;
>>>>> cyrille.pitchen at 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