On Mon, 2007-05-07 at 19:47 -0400, Mike Frysinger wrote: > On 4/25/07, David Brownell <[EMAIL PROTECTED]> wrote: > > On Wednesday 25 April 2007, Mike Frysinger wrote: > > > the spi_device structure has a bits_per_word so that you can change > > > the value on a per-device setting, yet the spi_board_info structure > > > does not ... this means that the bus-specific structure has to have a > > > bits_per_word member which the spi bus driver will copy into the spi > > > device bits_per_word member > > > > Actually that's more likely a driver-specific characteristic than > > something related to board wiring/configuration ... a characteristic > > of the particular protocol requests being made. That's why for > > example bits_per_word has a per-transfer override, and drivers are > > able to call spi_setup(spi). > > hmm, true ... > > > > is there something obvious i'm missing ? seems to me that if the > > > generic spi framework respects bits_per_word on a per-spi device > > > basis, then it should be exposed in the generic info structure so that > > > the setting can be tracked in the boards file ... > > > > The initial driver set didn't need it, that's all. ISTR someone > > else pointed out this quirk, but never provided a patch to resolve > > the issue. > > so which direction should it be ? or should it be both ? :) > > Blackfin at the moment is doing DMA/bits_per_word setup in the boards > ... we could move these to the drivers and have each one just call > spi_setup() at init, or i could post a patch for the common framework > if you think that's an OK direction to [also] go ... > -mike
Yes, it is very common for spi_framework. DMA setting as well as bits_per_word setup should be imported to spi_board_info struct. And currently, there are some duplicated data members in spi_device struct spi_board_info struct. This two structs are confused driver writers and boards driver users. Thanks -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/
