Hi Marek,
On 13 November 2014 03:46, Marek Vasut marex@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@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@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@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!