On 30 May 2016 at 17:50, Mark Brown <broonie@xxxxxxxxxx> wrote: > On Mon, May 30, 2016 at 05:28:10PM +0200, Michal Suchanek wrote: >> On 30 May 2016 at 17:03, Mark Brown <broonie@xxxxxxxxxx> wrote: > >> > I really don't think it's worth caring too much about cases where the >> > DMA driver hasn't been compiled in, it's not like SPI is the only thing > >> It's what the driver did to start with and it was requested to fall >> back to non-DMA in the case DMA is not available. > > Why? I really can't see any sensible use case for this that doesn't > have a better solution available. Of course, the solution is to compile in the DMA driver. It's been argued that some drivers which use only short transfers will just work. > >> It's possible to add a parameter like require_dma which could be used >> to load the driver without dma if unset. If it was set by default then >> driver ordering is not important so long as dma driver is loaded >> eventually. Also an informative print that such parameter exists when >> probing the driver is deferred would be helpful. It would probably >> create quite a bit of log spam, however. The driver can be deferred >> several times during boot. > > That seems fairly hacky, if we were going to do anything like that it > should be the other way around so that we default to trying to use > resources and even then it seems like something that should be handled > at a framework level rather than having random options in individual > drivers to ignore things. Having things behave inconsistently between > different drivers is going to lead to a worse user experience and if > this is a good idea for one driver it seems like it'd be a good idea for > all of them. Hacky but doable if desirable. It's awesome for testing SPI transfer fragmentation with different drivers ;-) The previous discussion of this driver is here http://thread.gmane.org/gmane.linux.kernel/2162327 Thanks Michal -- To unsubscribe from this list: send the line "unsubscribe linux-spi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html