On Wed, 3 Mar 2010 12:51:58 +0800 David Brownell <david-b@xxxxxxxxxxx> wrote: > On Tuesday 02 March 2010, Feng Tang wrote: > > + * 3. This driver doesn't support work with a spi cotnroller in > > DMA mode, > > As Grant said: That's a bug ... one that will randomly > kick in based on whether the underlying SPI controller driver > happens to use DMA for a given transaction. > > >From this perspective, yes, it's a bug that this driver use non DMA-safe IO buffer, which prevents it to be portable for all kinds of controllers, and I can make it DMA safe. But I still don't think it's a good idea to use DMA for Max3110 for performance reason, I know there is some spi controller who only works in DMA mode. Here comes another idea, can we add a capability flag in struct spi_master indicating the master supporting poll or dma or both. Also we add similar bits in struct spi_transfer indicating the this transfer wants to be handled in poll or dma mode. For spi controller driver, it can claim its capability when registering as a spi_master, for a spi device driver, it can select the working mode based on spi_master's capability and set the working mode in struct spi_transfer. Then controller and device don't need to guess what the other is capable, and make the info public. Any thoughts? Thanks, Feng -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
