Re: [PATCH 7/9] spi: s3c64xx: Use dma_request_chan() directly for channel request

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 14/11/2019 1.40, Andi Shyti wrote:
> Hi Peter,
> 
>>  	if (!is_polling(sdd)) {
>>  		/* Acquire DMA channels */
>> -		sdd->rx_dma.ch = dma_request_slave_channel_reason(&pdev->dev,
>> -								  "rx");
>> +		sdd->rx_dma.ch = dma_request_chan(&pdev->dev, "rx");
> 
> I have a little concern here. We have two funcions
> 'dma_request_chan' and  'dma_request_channel' don't we end up
> making some confusion here?
> 
> Wouldn't it make more sense renaming 'dma_request_chan' to
> 'dma_request_slave_channel_reason'?

The dma_request_channel() should go away. It was the old API before we
got the dma_slave_map for non DT (and non ACPI) platforms so we can get
rid of the filter function exports from DMA drivers to clients all over
the place.

I know there are users where they provide dummy filter function.

At the end the main API to request slave DMA channel should be
dma_request_chan()
For non slave channels (not HW triggered) we have dma_request_chan_by_mask()

Imoh the dma_request_slave_channel_compat() should also go away with time.

> 
> Thanks,
> Andi
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@xxxxxxxxxxxxxxxxxxx
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

- Péter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux