[ 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