[U-Boot] sf: Discussion on quad changes

Jagan Teki jagannadh.teki at gmail.com
Wed Jan 15 04:36:25 EST 2014


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-commands-support-td171225.html#a171290

--
Thanks,
Jagan.



More information about the linux-mtd mailing list