Re: [PATCH 5/5] RFC spi: sun4i: add DMA support

[Michal Suchanek]

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