[alsa-devel] [PATCH v7 2/4] dmaengine: Forward slave device pointer to of_xlate callback

[Marek Szyprowski]

Hi All,

On 2017-01-26 15:43, Marek Szyprowski wrote:
> On 2017-01-25 14:12, Lars-Peter Clausen wrote:
>> On 01/25/2017 11:28 AM, Marek Szyprowski wrote:
>>> Add pointer to slave device to of_dma_xlate to let DMA engine driver
>>> to know which slave device is using given DMA channel. This will be
>>> later used to implement non-irq-safe runtime PM for DMA engine driver.
>> of_dma_xlate() is used to translate from a OF phandle and a specifier 
>> to a
>> DMA channel. On one hand this does not necessarily mean that the 
>> channel is
>> actually going to be used by the slave that called the xlate function.
>> Modifying the driver state when a lookup of the channel is done is a
>> layering violation. And this approach is also missing a way to 
>> disassociate
>> a slave from a DMA channel, e.g. when it is no longer used.
>>
>> On the other hand there are other mechanisms to translate between 
>> some kind
>> of firmware handle to a DMA channel which are completely ignored here.
>>
>> So this approach does not work. This is something that needs to be 
>> done at
>> the dmaengine level, not a the firmware resource translation level. 
>> And it
>> needs a matching method that is called when the channel is disassociated
>> from a device, when the device no longer uses the DMA channel.
>
> Frankly I agree that of_dma_xlate() should only return the requested 
> channel
> to the dmaengine core and do not do any modification in the the driver 
> state.
>
> However the current dma engine design and implementation breaks this 
> rule.
> Please check the drivers - how do they implement of_xlate callback. They
> usually call dma_get_any_slave_channel, dma_get_slave_channel or
> __dma_request_channel there, which in turn calls dma_chan_get, which then
> calls back to device_alloc_chan_resources callback. Some of the 
> drivers also
> do a hardware configuration or other resource allocation in of_xlate.
> This is a bit messy design and leave no place in the core to set slave 
> device
> before device_alloc_chan_resources callback, where one would expect to 
> have
> it already set.
>
> The best place to add new calls to the dmaengine drivers to set slave 
> device
> would be just before device_alloc_chan_resources(), what in turn means 
> that
> the current dmaengine core should do in dma_chan_get(). This would 
> require to
> forward the slave device pointer via even more layers including the 
> of_xlate
> callback too. IMHO this is not worth the effort.
>
> DMA engine core and API definitely needs some cleanup. During such 
> cleanup
> the slave device pointer might be moved out of xlate into separate 
> callback
> when the core gets ready for such operation.
>
> I ignored other paths for other firmware handle to a DMA channel 
> translation
> mechanism because for the current pl330 driver they are simply not 
> used. I
> assume that if one needs to implement similar things for drivers 
> relying on
> them, he will update the respective DMA engine core parts.
>
> Slave device assignments can be cleared in 
> device_chan_release_resources if
> this is needed and that what existing DMA engine drivers do with the 
> resources
> allocated in the of_xlate callback...

Vinod: could you comment this patchset? Is there a chance to get it 
merged or
at least give it a try in -next? If not, could you provide some hints 
what should
I do?

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland