[U-Boot] sf: Discussion on quad changes

[U-Boot] sf: Discussion on quad changes

[Jagan Teki]

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.

[U-Boot] sf: Discussion on quad changes

[Simon Glass]

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

[U-Boot] sf: Discussion on quad changes

[Gerhard Sittig]

[ 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
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de