[U-Boot] sf: Discussion on quad changes
Hi All,
This particular discussion is a next level add-on for thread [1]
State of u-boot now: - Added quad changes on u-boot and will be available in coming release. - Added commands are 1) 1-line # Array slow read, Array fast read(available before) 2) 2-line # Dual fast read, Dual IO read 3) 3-line # Quad fast read, quad IO read, Quad page program - The implementation "will determine the fastest command by taking the supported commands from the flash and the controller, controller is always been a priority." - Suppose we have a flash that supports all types of commands then from driver side we have an option to set the particular command and the same option will goes to sf and will determine the fastest one. ex: if flash supports all, but the driver supports dual fast then the outcome read could be dual fast.
And even Linux will also does the similar implementation, i guess. The main reason for going maximum or based on controller setting transfer is to improve sf performance.
But from previous thread of discussion - Gerhard Sittig, identified a side-effect on this implementation as per as board to connected flash perceptive.
The question as per my understanding was "If a controller support 1, 2, and 4 lines then the BoardA is designed to connect a flash with 4-lines, BoardB is designed to connect a flash with 2-lines and BoardC is designed to connect a flash with 1-line."
In above scenario - as we have a common controller driver that may set an option to support quad then BoardB and BoardC will fail to transfer.
Gerhard Sittig, please add if i miss any points here!
I do agree this scenario and I have few possible inputs. 1) dynamic - auto-detection: Get the max_nof_lines based on the board to connected flash. So-that we can configure the transfer mode based on the lines. no idea yet, how to get the max_nof_lines dynamically - any inputs. 2) static: from user level we may give the max_nof_lines ex: sf probe probe [[[bus:]cs]:max_nof_line] [hz] [mode] If user can't input max_nof_line so-that driver will go with single and the rest case transfer modes assigned based on the given input. for Linux it can be pdata or dts.
Request for comments!
[1] http://u-boot.10912.n7.nabble.com/PATCH-v7-01-17-sf-Add-extended-read-comman...
-- Thanks, Jagan.
Hi Jagan,
On 15 January 2014 02:36, Jagan Teki jagannadh.teki@gmail.com wrote:
Hi All,
This particular discussion is a next level add-on for thread [1]
State of u-boot now:
- Added quad changes on u-boot and will be available in coming release.
- Added commands are
- 1-line # Array slow read, Array fast read(available before)
- 2-line # Dual fast read, Dual IO read
- 3-line # Quad fast read, quad IO read, Quad page program
- The implementation "will determine the fastest command by taking the supported commands from the flash and the controller, controller is always
been a priority."
- Suppose we have a flash that supports all types of commands then from driver side we have an option to set the particular command and the same option will goes to sf and will determine the fastest one. ex: if flash supports all, but the driver supports dual fast then
the outcome read could be dual fast.
And even Linux will also does the similar implementation, i guess. The main reason for going maximum or based on controller setting transfer is to improve sf performance.
But from previous thread of discussion - Gerhard Sittig, identified a side-effect on this implementation as per as board to connected flash perceptive.
The question as per my understanding was "If a controller support 1, 2, and 4 lines then the BoardA is designed to connect a flash with 4-lines, BoardB is designed to connect a flash with 2-lines and BoardC is designed to connect a flash with 1-line."
In above scenario - as we have a common controller driver that may set an option to support quad then BoardB and BoardC will fail to transfer.
Gerhard Sittig, please add if i miss any points here!
I do agree this scenario and I have few possible inputs.
- dynamic - auto-detection: Get the max_nof_lines based on the board to connected flash. So-that we can configure the transfer mode based on the lines. no idea yet, how to get the max_nof_lines dynamically - any inputs.
- static: from user level we may give the max_nof_lines ex: sf probe probe [[[bus:]cs]:max_nof_line] [hz] [mode] If user can't input max_nof_line so-that driver will go with single and the rest case transfer modes assigned based on the given input. for Linux it can be pdata or dts.
I don't have strong opinions on this, but do have a question. How about board-level configuration? Some boards may use device tree to indicate which SPI pins / features are available. Perhaps the configuration could have 'detect' option also. But in many cases I would expect that the board vendor would know what is supported, and any 'sf' options should respect that.
Request for comments!
[1] http://u-boot.10912.n7.nabble.com/PATCH-v7-01-17-sf-Add-extended-read-comman...
-- Thanks, Jagan.
Regards, Simon
[ Cc: list heavily trimmed ]
On Wed, Jan 15, 2014 at 11:01 -0700, Simon Glass wrote:
I don't have strong opinions on this, but do have a question. How about board-level configuration? Some boards may use device tree to indicate which SPI pins / features are available. Perhaps the configuration could have 'detect' option also. But in many cases I would expect that the board vendor would know what is supported, and any 'sf' options should respect that.
Yes, just like the Linux kernel supports device tree specs whether to use hardware handshake for UARTs, modem control signals, maximum frequencies for SPI transfers, FIFO partitions depending on expected data volume and transfer rates, etc (all options that cannot get determined from detected chips alone), there certainly should be the opportunity to limit the use of advanced SPI communication features in case those don't work or are not applicable. Regardless whether it's device tree or some other source of information.
The current state may be a good starting point, but with any automatic approach that is so optimistic yet ignores involved components I'd expect issues in the near future. There must be some way for users to limit this greed. :) Or defaults should be more conservative if operation is not to get broken, and higher performance should explicitly get requested.
virtually yours Gerhard Sittig
participants (3)
-
Gerhard Sittig -
Jagan Teki -
Simon Glass