sf: New SF-NOR framework

RFC PATCH New Jagannadha Sutradharudu Teki 2 participants 7 messages Nov 11, 2014 – Nov 16, 2014 Memory technology devices (MTD)

lore

Share & tools

lore

Jagannadha Sutradharudu Teki

author

2014-11-11 20:50 UTC #0 lore raw

RFC PATCH 1/1 sf: New SF-NOR framework

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 <[email protected]>

---
 doc/SPI/README.sf-nor     |  51 ++++++
 drivers/mtd/spi/Makefile  |   4 +-
 drivers/mtd/spi/sf_core.c | 389 ++++++++++++++++++++++++++++++++++++++++++++++
 drivers/mtd/spi/sf_core.h | 263 +++++++++++++++++++++++++++++++
 drivers/mtd/spi/sf_ops.c  | 147 +++++++-----------
 drivers/mtd/spi/sf_spi.c  | 230 +++++++++++++++++++++++++++
 include/spi_flash.h       |  15 +-
 7 files changed, 996 insertions(+), 103 deletions(-)
 create mode 100644 doc/SPI/README.sf-nor
 create mode 100644 drivers/mtd/spi/sf_core.c
 create mode 100644 drivers/mtd/spi/sf_core.h
 create mode 100644 drivers/mtd/spi/sf_spi.c

doc/SPI/README.sf-nor new file +51 -0

new file mode 100644
index 0000000..ded60f1
@@ -0,0 +1,51 @@
+SF-NOR framework:
+================
+
+1. Introduction
+
+Due to vast increasing of new spi flash features and operations the current
+serial flash framework in u-boot is difficult to manage the relation between
+spi bus vs spi flash(one of the connected slave). All newly added features
+are effecting spi_slave {} to become flash specific rather than generic spi bus.
+
+So there is a new framework that divides normal flash operations through generic
+SPI API's and more spi flash(sf) specific operations through SF NOR API's.
+
+This division of operations are taken care by new framework called "sf-nor".
+
+2. SF NOR
+
+		 _______________
+		|		|
+		|    cmd_sf.c	|
+		|_______________|
+			|
+			|
+		 _______V_______
+		|		|
+		|  spi_flash.h	|
+		|_______________|
+			|
+			|
+	       _________V_________	
+	      |		          |
+	      |    sf_core        |
+	      |    (sf_core.c)    |
+	      |___________________|
+		     |	       |	
+		     |	       |
+		 ____V____     |
+		|	  |    |
+		| sf_spi.c|    |
+		|_________|    |
+		     |	       |
+		     |	       |
+		     V	       V	
+	    drivers/spi/*    drivers/mtd/spi/zynq_qspi.c
+
+common/cmd_sf.c: spi flash command interface
+include/spi_flash.h: spi flash api interface
+drivers/mtd/spi/sf_core.c: SF Core
+drivers/mtd/spi/sf_spi.c: sf emulation for all drivers/spi/*
+drivers/spi: spi drivers
+drivers/mtd/spi/zynq_qspi.c: zynq qspi controller driver

drivers/mtd/spi/Makefile +2 -2

index 15789a0..2ddeadf 100644
@@ -13,9 +13,9 @@ obj-$(CONFIG_SPL_SPI_BOOT)	+= fsl_espi_spl.o
 endif
 
 #ifndef CONFIG_DM_SPI
-obj-$(CONFIG_SPI_FLASH) += sf_probe.o
+obj-$(CONFIG_SPI_FLASH) += sf_core.o
 #endif
-obj-$(CONFIG_CMD_SF) += sf.o
+obj-$(CONFIG_CMD_SF) += sf_spi.o
 obj-$(CONFIG_SPI_FLASH) += sf_ops.o sf_params.o
 obj-$(CONFIG_SPI_FRAM_RAMTRON) += ramtron.o
 obj-$(CONFIG_SPI_FLASH_SANDBOX) += sandbox.o

drivers/mtd/spi/sf_core.c new file +389 -0

389 lines not on this page · raw message

drivers/mtd/spi/sf_core.h new file +263 -0

263 lines not on this page · raw message

drivers/mtd/spi/sf_ops.c +60 ~~-87~~

425 lines not on this page · raw message

drivers/mtd/spi/sf_spi.c new file +230 -0

230 lines not on this page · raw message

include/spi_flash.h +1 ~~-14~~

index 5913b39..90ce389 100644
@@ -68,26 +68,13 @@ struct spi_flash {
 #else
 	struct spi_slave *spi;
 #endif
+	struct sf_nor *nor;
 	const char *name;
-	u8 dual_flash;
-	u8 shift;
 
 	u32 size;
-	u32 page_size;
 	u32 sector_size;
 	u32 erase_size;
-#ifdef CONFIG_SPI_FLASH_BAR
-	u8 bank_read_cmd;
-	u8 bank_write_cmd;
-	u8 bank_curr;
-#endif
-	u8 poll_cmd;
-	u8 erase_cmd;
-	u8 read_cmd;
-	u8 write_cmd;
-	u8 dummy_byte;
 
-	void *memory_map;
 #ifndef CONFIG_DM_SPI_FLASH
 	/*
 	 * These are not strictly needed for driver model, but keep them here

Signature · 1 line

1.9.1

Marek Vasut

2014-11-11 21:22 UTC #1 lore raw

RFC PATCH 1/1 sf: New SF-NOR framework

Quoted 14 lines · Jagannadha Sutradharudu Teki

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

Quoted 8 lines

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 <[email protected]>

I have but a general question -- why did you not just import the spi-nor framework from Linux ?

Best regards,
Marek Vasut

Jagan Teki

author

2014-11-11 21:37 UTC #2 lore raw

RFC PATCH 1/1 sf: New SF-NOR framework

Quoted 19 lines · Marek Vasut

Quoted 17 lines · Jagannadha Sutradharudu Teki
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...

Quoted 8 lines

Quoted 5 lines
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 <[email protected]>
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.

thanks!

Signature · 1 line

Jagan.

Marek Vasut

2014-11-11 22:56 UTC #3 lore raw

RFC PATCH 1/1 sf: New SF-NOR framework

Quoted 28 lines · Jagan Teki

Quoted 27 lines · Marek Vasut
On Tuesday, November 11, 2014 at 09:50:35 PM, Jagannadha Sutradharudu Teki
Quoted 22 lines · 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 <[email protected]>

Quoted 8 lines

Quoted 2 lines
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 ?

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.

Best regards,
Marek Vasut

Jagan Teki

author

2014-11-12 00:19 UTC #4 lore raw

RFC PATCH 1/1 sf: New SF-NOR framework

Quoted 38 lines · Marek Vasut

Quoted 28 lines · Jagan Teki
Quoted 27 lines · Marek Vasut
On Tuesday, November 11, 2014 at 09:50:35 PM, Jagannadha Sutradharudu Teki
Quoted 22 lines · 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 <[email protected]>
Quoted 8 lines
Quoted 2 lines
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.

Quoted 3 lines

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.

Quoted 6 lines

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.

thanks!

Signature · 1 line

Jagan.

Marek Vasut

2014-11-12 22:16 UTC #5 lore raw

RFC PATCH 1/1 sf: New SF-NOR framework

Quoted 44 lines · Jagan Teki

Quoted 39 lines · Marek Vasut
Quoted 29 lines · Jagan Teki
Quoted 28 lines · Marek Vasut
On Tuesday, November 11, 2014 at 09:50:35 PM, Jagannadha Sutradharudu Teki
Quoted 23 lines · 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
<[email protected]>
Quoted 8 lines
Quoted 2 lines
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.
Quoted 3 lines
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 ?

Quoted 6 lines

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.

Quoted 6 lines

Quoted 5 lines
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.

Quoted 6 lines

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

Best regards,
Marek Vasut

Jagan Teki

author

2014-11-16 18:58 UTC #6 lore raw

RFC PATCH 1/1 sf: New SF-NOR framework

Hi Marek,

Quoted 45 lines · Marek Vasut

Quoted 44 lines · Jagan Teki
Quoted 42 lines · Marek Vasut
Quoted 29 lines · Jagan Teki
Quoted 28 lines · Marek Vasut
On Tuesday, November 11, 2014 at 09:50:35 PM, Jagannadha Sutradharudu Teki
Quoted 23 lines · 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
<[email protected]>
Quoted 8 lines
Quoted 2 lines
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 ?

Quoted 8 lines

Quoted 6 lines
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.

Quoted 14 lines

Quoted 7 lines
Quoted 6 lines
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.
Quoted 6 lines
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.

Quoted 6 lines

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!

Signature · 1 line

Jagan.