[U-Boot] sf: Discussion on quad changes

[Simon Glass]

Hi Jagan,

On 15 January 2014 02:36, Jagan Teki <jagannadh.teki at 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) 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.


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


Regards,
Simon