[U-Boot] [RFC PATCH] sf: New SF-NOR framework

[Jagan Teki]

Hi Marek,

On 13 November 2014 03:46, Marek Vasut <marex at denx.de> wrote:
> On Wednesday, November 12, 2014 at 01:19:02 AM, Jagan Teki wrote:
>> On 12 November 2014 04:26, Marek Vasut <marex at denx.de> wrote:
>> > On Tuesday, November 11, 2014 at 10:37:33 PM, Jagan Teki wrote:
>> >> On 12 November 2014 02:52, Marek Vasut <marex at denx.de> wrote:
>> >> > On Tuesday, November 11, 2014 at 09:50:35 PM, Jagannadha Sutradharudu
>> >> > Teki
>> >> >
>> >> > wrote:
>> >> >> This is long lasting work that I did last few months back,
>> >> >> I'm sure it's where much need now.
>> >> >>
>> >> >> - spi driver: drivers/spi/fsl_qspi.c
>> >> >> - flash attributes in spi_slave {} and
>> >> >> - etc ...
>> >> >> making spi subsystem becomes more flash specific rather operating
>> >> >> as a generic spi bus. So SF-NOR divides normal spi flash operations
>> >> >> through generic SPI API's(sf_spi.c) and more spi flash(sf) specific
>> >> >> operations through SF NOR API's.
>> >> >>
>> >> >> So the controllers those are operating more on flash needs to
>> >> >> write a driver on drivers/mtd/spi/ example fsl_qspi.c
>> >> >>
>> >> >> I have not tested more accuratly as of now, will come back again
>> >> >> with new feature additions/removal, zynq_qspi additions and more...
>> >> >>
>> >> >> Note: dm-spi ops can gets effected with this new framework
>> >> >> { .ops            = &spi_flash_std_ops, } and will fix that in next
>> >> >> version patches.
>> >> >>
>> >> >> Signed-off-by: Jagannadha Sutradharudu Teki
>> >> >> <jagannadh.teki at gmail.com>
>> >> >
>> >> > I have but a general question -- why did you not just import the
>> >> > spi-nor framework from Linux ?
>> >>
>> >> Well, importing spi-nor from Linux is may not be a good idea as we
>> >> have a working stuff
>> >> at our end along with different dependencies and I'm sure this will
>> >> becomes similar way as
>> >> spi-nor at some point of time.
>> >
>> > What you said doesn't add up to me -- you introduced a completely new
>> > framework in this patch, right ? So what exact "working stuff" do we
>> > have if this is a completely new code ?
>>
>> Yes - this is a new framework with exiting working code by maintain sf_nor
>> {} to common for spi_sf drivers and flash based drivers.
>>
>> Not completely new code, It's a re-arranged proven/working existing
>> code, please understand this.
>> re-arranged as we have an issue with spi is handling more flash stuff.
>
> OK, I will not argue about which one is more proven, that's not the point here.

My intend is not about that, I'm saying sf is long running working
stuff not more than that.

>
>> > Compared to that, the SPI NOR framework in Linux is being actively
>> > maintained and actively used for a while now, so it's actually a proven
>> > code already. Also, we just recently resynced MTD subsystem with Linux,
>> > adding the SPI NOR framework which is based on that same MTD framework
>> > would probably be pretty straighforward.
>>
>> Even sf stuff in u-boot is actively maintained and code in sf and
>> Linux are almost similar
>> except Linux specific stuff. I don't see any point to import the Linux
>> stuff as we have working
>> and actively maintained stuff. By addition of this I'm sure something
>> proved will not effect.
>
> Given that the MTD code is imported from Linux, pulling in another part of
> that MTD code (the SPI NOR framework) would trim down the divergence of the
> codebase. This would make things easier in the long run too, since we could
> then just sync with Linux and the bugfixes and new features could be simply
> imported from Linux too . It would make things easier for contributors too,
> since they won't have to learn two codebases, but just one (the linux one).

Yes, I agree with the points you noted, thank you about that.

But, we cannot compare serial flash handing in Linux vs U-boot in all
the aspects.
Unlike Linux - U-Boot the core serial flash handling is need to talk
to lot of aspects
like cmd_sf, cmd_spi, drivers/spi, some parts from u-boot code and
recently links with
driver models.

Having all these sense, current serial flash stuff is well handling
all these and well tested
on the respective hardware. So this new framework is not going change
the derivatives apart
from moving real flash stuff to out side of spi subsystem.

I think you knew all these stuff, but explaining here to identify the
more code relations wrt sf.

If we import spi-nor from Linux I need to take care all the stuff from
base, which is going
to another work that also needs lot of testing. And also spi-nor is
standardized since last less
than a year and it is also growing. U-boot sf is well tested one and
if we make changes wrt
current code and have same flash features compared to Linux and one
point the framework
will become stronger.

MTD code, can be straight forward to add it to sf, no much work
required I suppose.

>From all these points, I'm going tell one point here is - As u-boot sf
is a tested framework and have
positive feature support till now, and then if we modify this by
excluding flash features from spi
then it will become a well structure framework and I'm sure for that.

thanks!
-- 
Jagan.