On Monday 07 May 2007, Mike Frysinger wrote: > On 4/25/07, David Brownell <[EMAIL PROTECTED]> wrote: > > On Wednesday 25 April 2007, Mike Frysinger wrote: > > > > 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 ? :)
Add bits_per_word to spi_board_info, and have the device creation logic copy it into spi_device as it's created. > 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 ... I don't see what you're getting at here. The SPI core doesn't do anything with DMA, beyond passing DMA addresses through when necessary. (Needed to handle messages derived from scatterlists, since I don't want lower layers to know scatterlists, but otherwise uncommon.) And when each spi_device is created, the core calls spi_setup() with the data. That seems like the natural place to set up things like DMA and so forth... The pxa2xx_spi driver uses spi_board_info.controller_data to pass dma setup/tuning data from board init logic. - Dave - 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/
