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

[Jagan Teki]

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. 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.