Hi :
2018-01-03 18:59 GMT+08:00 Lukasz Majewski <lu...@denx.de>:
> Hi Jagan,
>
> > On Wed, Jan 3, 2018 at 2:18 PM, Vignesh R <vigne...@ti.com> wrote:
> > >
> > >
> > > On Tuesday 02 January 2018 03:39 PM, Jagan Teki wrote:
> > >> On Thu, Dec 28, 2017 at 8:14 PM, Lukasz Majewski <lu...@denx.de>
> > >> wrote:
> > >>> Hi Jagan,
> > >>>
> > >>>> Compared to previous series’s [1], [2], [3] and [4] this patch
> > >>>> set redefined most of the implementation suitable to fit into
> > >>>> existing driver-model.
> > >>>>
> > >>>> MTD is generic subsystem for underlying flash devices like nand,
> > >>>> parallel nor, spinor, dataflash etc. So to drive this theory with
> > >>>> driver model(with an example of block layer) mtd is common device
> > >>>> interaction for most of memory technology flashes like nand,
> > >>>> parallel nor, spinor, dataflash etc, these are treated as
> > >>>> interface types wrt u-boot driver model.
> > >>>>
> > >>>> Once the respective interface driver bind happen, the uclass
> > >>>> driver will pass an 'interface type' to mtd layer to create
> > >>>> device for it, for example once spinor ULASS_SPI_NOR driver bind
> > >>>> happen, the uclass driver of spinor will pass MTD_IF_TYPE_SPI_NOR
> > >>>> interface type to create mtd device for spinor devices.
> > >>>>
> > >>>> SPI-NOR:
> > >>>> =======
> > >>>> Some of the SPI device drivers at drivers/spi not a real
> > >>>> spi controllers, Unlike normal/generic SPI controllers they
> > >>>> operates only with SPI-NOR flash devices. these were technically
> > >>>> termed as SPI-NOR controllers, Ex: drivers/spi/fsl_qspi.c
> > >>>>
> > >>>> The problem with these were resides at drivers/spi is entire
> > >>>> SPI layer becomes SPI-NOR flash oriented which is absolutely
> > >>>> a wrong indication where SPI layer getting effected more with
> > >>>> flash operations - So this SPI-NOR core will resolve this issue
> > >>>> by separating all SPI-NOR flash operations from spi layer and
> > >>>> creats a generic layer called SPI-NOR core which can be used to
> > >>>> interact SPI-NOR to SPI driver interface layer and the SPI-NOR
> > >>>> controller driver.
> > >>>
> > >>> I must admit that I'm a bit confused....
> > >>>
> > >>> If you don't mind I would like to ask for clarification of a few
> > >>> things:
> > >>>
> > >>>
> > >>>
> > >>>>
> > >>>> =======================================
> > >>>> cmd/spinor.c
> > >>>
> > >>> ^^^^^ - this would be a new set of commands to
> > >>> comply with DM?
> > >>
> > >> with this series yes, and we're working on supporting the same
> > >> with non-dm.
> > >>>
> > >>> What about "sf" command which we use now to get
> > >>> access to SPI-NOR memory? A lot of boards already use "sf"
> > >>> command... which may be tricky to replace.
> > >>
> > >> end-goal will be replace sf with spinor command and removal of 'sf'
> > >> will be done when the new spi-nor framework stable enough to handle
> > >> all scenarios which are spi-flash supporting as of now.
> > >
> > > I don't agree on adding new cmd and removing sf. It would be
> > > impractical to change all boot cmds to replace sf with spinor cmd
> > > all over U-Boot. Not to forget the envs already stored on non
> > > volatile media need updation to work with new cmd.
> > > If SPI NOR framework is to abstract all accesses to nor flash
> > > devices in U-Boot, then why cannot it replace the logic
> > > implementing cmd sf? All that is changing is that mtd/spi/* is
> > > replaced by spi-nor.c + m25p80.c. sf probe can be modified achieve
> > > what spinor dev does sf read for spinor read and so on. Board
> > > configs would just need to enable MTD related configs.
> >
> > I know how hard it is adding new command in u-boot,
>
> Yes, it is. Especially command which duplicates already present
> functionality.
>
> > you can understood
> > the reason for adding new command if you follow the previous versions
> > on this series and I hope you does.
>
> I must admit that this is the first version, which I reviewed.
>
> The only feasible way would be to have new Kconfig option for this
> framework, force spinor for new boards and ..... wait.
>
> After some long time (how long do we struggle with DM
> conversion/Kconfig?) we could think about removing "sf" command.
>
> I do want to emphasis that I do agree with Vignesh - there are many
> boards out there, which do use sf command, with even more dangerous
> situation when company X only plan to update u-boot, but has envs in a
> separate partition. Breaking "sf" equals to brick of on-field
> devices....
>
> IMHO - we shall have sf command as an alias to new "spinor" command
> (even by calling run_command("spinor....");).
>
> > we have been adding mtd, spi-nor
> > changes to existing mtd/spi and sf.c since from first series and
> > observed many issue with respective to framework design(where we move
> > spi-nor controller drivers on to mtd side) along with driver model. In
> > v9 we worked on designing MTD UCLASS where mtd command can be commonly
> > interfaced to all underlying flash devices. and from continuous
> > evaluation on driver model this series we designed MTD uclass can be a
> > generic and make run-time creation of underlying flash devices with
> > interface type, spi-nor is one of the interface. So to make the
> > framework suitable to command interface the new command named as
> > spinor. adding/supporting all these new design on top of mtd/spi or sf
> > doesn’t smooth easy which is proved on previous version. technically
> > sf termed as spi-flash comprise of spinor and spinand, spinand can be
> > another interface type with spinand command and adding new features on
> > legacy code doesn't make sense to me it will eventually breaking
> > legacy dependencies.
> >
> > Will all these new framework design, driver model, feasibility to sync
> > Linux spi-nor.c we adding relevant command, and env.
> >
>
>
>
Can we make a finall direction now, more than one year passed since
Jagan's first version, and now it gets V10.
From the Linux kernel upstream, the spi nor framework switch to mtd/spi-nor
for a long time, and it works fine now.
I hope u-boot spi nor can switch to mtd/spi-nor too, so we can share many
logic with the kernel code.
Besides， I have a rockchip SPI-NOR controller（SFC), I wrote two different
version drivers， one is based on
drivers/spi, another is based on Jagan's mtd/spi-nor , but I don't know how
to move forward, as the direction is not
clear.
>
> Best regards,
>
> Lukasz Majewski
>
> --
>
> DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
>
> _______________________________________________
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
>
>
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
