On Mon, Jan 13, 2014 at 18:15 +0530, Jagan Teki wrote: > > On Mon, Jan 13, 2014 at 4:26 PM, Jagan Teki <jagannadh.t...@gmail.com> wrote: > > > > Yes the main reason for going maximum or based on controller setting > > transfer is to improve sf performance. I missed your point as didn't > > see much use cases from board to connected flash perceptive. > > > > I thought we have two options to meet this requirement. > > 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.
As outlined in my previous reply, I'm afraid that the auto detection will always end up being inferior (unreliable, potentially dangerous, still not under the user's control). A simple approach might be to have the user specify the number of data lines to use (as in your "static" example above). The question remains whether this specified number shall be taken as the exact number or as the maximum number of data lines. > As this change involves mostly on the driver parts I a thinking > to go-ahead and try to push this series to master. yes I would > mark this as my TODO list and will trigger one more thread. > > Hope this idea sounds valid, let me know for any issues. Agreed, as there are few or no complaints and concerns (yet?), let's address this limiting the number of data lines at a later point in time. Just keep awareness, that was my most important issue here. :) Given that Quad-SPI is rather new, I'd expect new designs to be "consistent" (i.e. always quad capable flash chips attached to quad capable controllers and connected via the maximum number of lines known by that time), while only after some more time the "interesting" combinations crop up (like starting with non-quad flash chip and only the necessary connections and a quad capable controller, then dropping in more recent chips without re-rolling the PCB layout; or upgrading/replacing SoCs and flash chips with "compatible" devices and not being aware of the software's "detecting" the maximum while ignoring the wires on board). 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: off...@denx.de _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot