On Wed, 2007-10-31 at 00:11 -0700, David Brownell wrote: > On Tuesday 30 October 2007, Bryan Wu wrote: > > Maybe there are some confusion of mixing up the spi_trasnfer.speed_hz > > with the spi_device.max_speed_hz. > > > > spi_device.max_speed_hz comes from spi_board_info.max_speed_hz, it is > > for the default max speed value. > > It's initialized from board_info, yes. Drivers can override it > using spi_setup(). > > One would expect they only override _downwards_ but that's not > guaranteed anywhere. A driver might have a way to establish that > this particular board can run faster, for example. >
IMO, the spi_transfer.speed_hz <= spi_board_info.max_speed_hz and if spi_trasnfer.speed_hz is 0, we should use spi_board_info.max_speed_hz. >From the meaning of max_speed_hz, the spi_transfer.speed_hz should not beyond max_speed_hz. In your explanation, the max_speed_hz is just a default value. the transfer speed_hz can beyond max_speed_hz. We found the bug in M25P16 should be related this missing checking of the transfer speed_hz. > > > spi_transfer.speed_hz comes from upper applications for each spi > > transfer setting. > > Certainly; all spi_transfer records come from applications! > If that value is zero, that transfer segment uses the limit > from the spi_device ... otherwise, it can differ. Again, > the limits can vary based on devise characteristics; maybe > it can't feed data as fast for some commands. > > (ISTR the M25P16 in $SUBJECT has two read commands, one of > which is only usable at clock rates below 33 MHz or so, but > most other commands can work above that speed just fine.) > OK, We check it on Blackfin board. -Bryan Wu - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
