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

[Vinod Koul]

On Thu, Feb 09, 2017 at 10:22:38AM +0100, Marek Szyprowski wrote:
> Hi Vinod,
> 
> On 2017-02-09 05:11, Vinod Koul wrote:
> >On Thu, Jan 26, 2017 at 03:43:05PM +0100, 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.
> >True..
> >
> >>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.
> >We shouldn't be doing much at this stage. We operate on a channel, so the
> >channel is returned to the client. We need to do these HW configurations
> >when the channel has to be prepred for a txn.
> 
> IMHO, any HW configurations should be done in alloc_chan_resources
> callback and
> it would be best if a pointer of slave device will come as a
> parameter to it.

HW configuration is dependent upon the parameters passed, which are not part
of alloc_chan_resources(). Consider it as kind of open() to get a handle for
dmaengine

> 
> >>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.
> >Yes agreed on that, plus the runtime handling needs to be built in, right
> >now the APIs dont work well with it, we disucssed these during the KS and
> >this goes without saying, patches are welcome :)
> 
> Okay, so what is the conclusion? Do you want me to do the whole
> rework of dma
> engine core to get this runtime pm patchset for pl330 merged??? Is there any
> roadmap for this rework prepared, so I can at least take a look at
> the amount
> of work needed to be done?
> 
> I'm rather new to dma engine framework and I only wanted to fix pl330 driver
> not to block turning off the power domain on Exynos5422/5433 SoCs.
> 
> I can also check again if there is any other way to find the slave device in
> alloc_chan_resources, like for example scanning the device tree for
> phandles,
> to avoid changing dmaengine core as this turned out to be too problematic
> before one will do the proper dma engine core rework.

There are few things we need to do for making APIs cleaner.

We have a mini discussion during KS/Plumbers, Here are the notes
http://www.spinics.net/lists/dmaengine/msg11570.html

I don't want to block your series for this, I will take a look at v8, first
thing in morning..

Thanks
-- 
~Vinod

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

[Vinod Koul]

On Thu, Feb 09, 2017 at 10:22:38AM +0100, Marek Szyprowski wrote:
> Hi Vinod,
> 
> On 2017-02-09 05:11, Vinod Koul wrote:
> >On Thu, Jan 26, 2017 at 03:43:05PM +0100, 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.
> >True..
> >
> >>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.
> >We shouldn't be doing much at this stage. We operate on a channel, so the
> >channel is returned to the client. We need to do these HW configurations
> >when the channel has to be prepred for a txn.
> 
> IMHO, any HW configurations should be done in alloc_chan_resources
> callback and
> it would be best if a pointer of slave device will come as a
> parameter to it.

HW configuration is dependent upon the parameters passed, which are not part
of alloc_chan_resources(). Consider it as kind of open() to get a handle for
dmaengine

> 
> >>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.
> >Yes agreed on that, plus the runtime handling needs to be built in, right
> >now the APIs dont work well with it, we disucssed these during the KS and
> >this goes without saying, patches are welcome :)
> 
> Okay, so what is the conclusion? Do you want me to do the whole
> rework of dma
> engine core to get this runtime pm patchset for pl330 merged??? Is there any
> roadmap for this rework prepared, so I can at least take a look at
> the amount
> of work needed to be done?
> 
> I'm rather new to dma engine framework and I only wanted to fix pl330 driver
> not to block turning off the power domain on Exynos5422/5433 SoCs.
> 
> I can also check again if there is any other way to find the slave device in
> alloc_chan_resources, like for example scanning the device tree for
> phandles,
> to avoid changing dmaengine core as this turned out to be too problematic
> before one will do the proper dma engine core rework.

There are few things we need to do for making APIs cleaner.

We have a mini discussion during KS/Plumbers, Here are the notes
http://www.spinics.net/lists/dmaengine/msg11570.html

I don't want to block your series for this, I will take a look at v8, first
thing in morning..

Thanks
-- 
~Vinod

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

[Ulf Hansson]

>>
>> Yes agreed on that, plus the runtime handling needs to be built in, right
>> now the APIs dont work well with it, we disucssed these during the KS and
>> this goes without saying, patches are welcome :)
>
>
> Okay, so what is the conclusion? Do you want me to do the whole rework of
> dma
> engine core to get this runtime pm patchset for pl330 merged??? Is there any
> roadmap for this rework prepared, so I can at least take a look at the
> amount
> of work needed to be done?
>
> I'm rather new to dma engine framework and I only wanted to fix pl330 driver
> not to block turning off the power domain on Exynos5422/5433 SoCs.

As you probably know, this is a common problem for many dma devices,
slave devices and platforms.

If possible, it would be great if we could avoid a solution that
doesn't force changes to lots of "dma consumer" drivers.

>
> I can also check again if there is any other way to find the slave device in
> alloc_chan_resources, like for example scanning the device tree for
> phandles,
> to avoid changing dmaengine core as this turned out to be too problematic
> before one will do the proper dma engine core rework.
>

Again, thanks for working on this!

Kind regards
Uffe

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

[Ulf Hansson]

>>
>> Yes agreed on that, plus the runtime handling needs to be built in, right
>> now the APIs dont work well with it, we disucssed these during the KS and
>> this goes without saying, patches are welcome :)
>
>
> Okay, so what is the conclusion? Do you want me to do the whole rework of
> dma
> engine core to get this runtime pm patchset for pl330 merged??? Is there any
> roadmap for this rework prepared, so I can at least take a look at the
> amount
> of work needed to be done?
>
> I'm rather new to dma engine framework and I only wanted to fix pl330 driver
> not to block turning off the power domain on Exynos5422/5433 SoCs.

As you probably know, this is a common problem for many dma devices,
slave devices and platforms.

If possible, it would be great if we could avoid a solution that
doesn't force changes to lots of "dma consumer" drivers.

>
> I can also check again if there is any other way to find the slave device in
> alloc_chan_resources, like for example scanning the device tree for
> phandles,
> to avoid changing dmaengine core as this turned out to be too problematic
> before one will do the proper dma engine core rework.
>

Again, thanks for working on this!

Kind regards
Uffe

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

[Marek Szyprowski]

Hi Ulf,

On 2017-02-09 10:55, Ulf Hansson wrote:

Yes agreed on that, plus the runtime handling needs to be built in, right
now the APIs dont work well with it, we disucssed these during the KS and
this goes without saying, patches are welcome :)

Okay, so what is the conclusion? Do you want me to do the whole rework of
dma
engine core to get this runtime pm patchset for pl330 merged??? Is there any
roadmap for this rework prepared, so I can at least take a look at the
amount
of work needed to be done?

I'm rather new to dma engine framework and I only wanted to fix pl330 driver
not to block turning off the power domain on Exynos5422/5433 SoCs.

As you probably know, this is a common problem for many dma devices,
slave devices and platforms.


Right, this is a common issue and someone has to finally find a solution 
for it.



If possible, it would be great if we could avoid a solution that
doesn't force changes to lots of "dma consumer" drivers.


My current solution doesn't require changing ANY "dma consumer" driver. 
However,
I have one more idea how to avoid touching dma engine ("provider") 
drivers as

well. This will also address some issues pointed by Lars.

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

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

[Marek Szyprowski]

Hi Ulf,

On 2017-02-09 10:55, Ulf Hansson wrote:

Yes agreed on that, plus the runtime handling needs to be built in, right
now the APIs dont work well with it, we disucssed these during the KS and
this goes without saying, patches are welcome :)

Okay, so what is the conclusion? Do you want me to do the whole rework of
dma
engine core to get this runtime pm patchset for pl330 merged??? Is there any
roadmap for this rework prepared, so I can at least take a look at the
amount
of work needed to be done?

I'm rather new to dma engine framework and I only wanted to fix pl330 driver
not to block turning off the power domain on Exynos5422/5433 SoCs.

As you probably know, this is a common problem for many dma devices,
slave devices and platforms.


Right, this is a common issue and someone has to finally find a solution 
for it.



If possible, it would be great if we could avoid a solution that
doesn't force changes to lots of "dma consumer" drivers.


My current solution doesn't require changing ANY "dma consumer" driver. 
However,
I have one more idea how to avoid touching dma engine ("provider") 
drivers as

well. This will also address some issues pointed by Lars.

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

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

[Marek Szyprowski]

Hi Vinod,

On 2017-02-09 05:11, Vinod Koul wrote:

On Thu, Jan 26, 2017 at 03:43:05PM +0100, 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.

True..


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.

We shouldn't be doing much at this stage. We operate on a channel, so the
channel is returned to the client. We need to do these HW configurations
when the channel has to be prepred for a txn.


IMHO, any HW configurations should be done in alloc_chan_resources 
callback and
it would be best if a pointer of slave device will come as a parameter 
to it.



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.

Yes agreed on that, plus the runtime handling needs to be built in, right
now the APIs dont work well with it, we disucssed these during the KS and
this goes without saying, patches are welcome :)


Okay, so what is the conclusion? Do you want me to do the whole rework 
of dma

engine core to get this runtime pm patchset for pl330 merged??? Is there any
roadmap for this rework prepared, so I can at least take a look at the 
amount

of work needed to be done?

I'm rather new to dma engine framework and I only wanted to fix pl330 driver
not to block turning off the power domain on Exynos5422/5433 SoCs.

I can also check again if there is any other way to find the slave device in
alloc_chan_resources, like for example scanning the device tree for 
phandles,

to avoid changing dmaengine core as this turned out to be too problematic
before one will do the proper dma engine core rework.

> ...

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

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

[Marek Szyprowski]

Hi Vinod,

On 2017-02-09 05:11, Vinod Koul wrote:

On Thu, Jan 26, 2017 at 03:43:05PM +0100, 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.

True..


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.

We shouldn't be doing much at this stage. We operate on a channel, so the
channel is returned to the client. We need to do these HW configurations
when the channel has to be prepred for a txn.


IMHO, any HW configurations should be done in alloc_chan_resources 
callback and
it would be best if a pointer of slave device will come as a parameter 
to it.



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.

Yes agreed on that, plus the runtime handling needs to be built in, right
now the APIs dont work well with it, we disucssed these during the KS and
this goes without saying, patches are welcome :)


Okay, so what is the conclusion? Do you want me to do the whole rework 
of dma

engine core to get this runtime pm patchset for pl330 merged??? Is there any
roadmap for this rework prepared, so I can at least take a look at the 
amount

of work needed to be done?

I'm rather new to dma engine framework and I only wanted to fix pl330 driver
not to block turning off the power domain on Exynos5422/5433 SoCs.

I can also check again if there is any other way to find the slave device in
alloc_chan_resources, like for example scanning the device tree for 
phandles,

to avoid changing dmaengine core as this turned out to be too problematic
before one will do the proper dma engine core rework.

> ...

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

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

[Vinod Koul]

On Thu, Jan 26, 2017 at 03:43:05PM +0100, Marek Szyprowski wrote:
> Hi Lars,
> 
> 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.

True..

> 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.

We shouldn't be doing much at this stage. We operate on a channel, so the
channel is returned to the client. We need to do these HW configurations
when the channel has to be prepred for a txn.

> 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.

Yes agreed on that, plus the runtime handling needs to be built in, right
now the APIs dont work well with it, we disucssed these during the KS and
this goes without saying, patches are welcome :)

> 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

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

[Vinod Koul]

On Thu, Jan 26, 2017 at 03:43:05PM +0100, Marek Szyprowski wrote:
> Hi Lars,
> 
> 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.

True..

> 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.

We shouldn't be doing much at this stage. We operate on a channel, so the
channel is returned to the client. We need to do these HW configurations
when the channel has to be prepred for a txn.

> 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.

Yes agreed on that, plus the runtime handling needs to be built in, right
now the APIs dont work well with it, we disucssed these during the KS and
this goes without saying, patches are welcome :)

> 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

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

[Vinod Koul]

On Fri, Feb 03, 2017 at 02:01:27PM +0100, Marek Szyprowski wrote:
> 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?

Nothing :) I am slowly clearning up my queue and should process this series
in couple of days or so...

-- 
~Vinod

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

[Vinod Koul]

On Fri, Feb 03, 2017 at 02:01:27PM +0100, Marek Szyprowski wrote:
> 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?

Nothing :) I am slowly clearning up my queue and should process this series
in couple of days or so...

-- 
~Vinod

Re: [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 Institute Poland

Re: [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 Institute Poland

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

[Marek Szyprowski]

Hi Lars,

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...

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

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

[Marek Szyprowski]

Hi Lars,

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...

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

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

[Lars-Peter Clausen]

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.

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

[Lars-Peter Clausen]

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.

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

[Marek Szyprowski]

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.

Signed-off-by: Marek Szyprowski 
Reviewed-by: Ulf Hansson 
Acked-by: Arnd Bergmann 
---
 drivers/dma/amba-pl08x.c|  2 +-
 drivers/dma/at_hdmac.c  |  4 ++--
 drivers/dma/at_xdmac.c  |  2 +-
 drivers/dma/bcm2835-dma.c   |  2 +-
 drivers/dma/coh901318.c |  2 +-
 drivers/dma/cppi41.c|  2 +-
 drivers/dma/dma-jz4780.c|  2 +-
 drivers/dma/dmaengine.c |  2 +-
 drivers/dma/dw/platform.c   |  2 +-
 drivers/dma/edma.c  |  4 ++--
 drivers/dma/fsl-edma.c  |  2 +-
 drivers/dma/img-mdc-dma.c   |  2 +-
 drivers/dma/imx-dma.c   |  2 +-
 drivers/dma/imx-sdma.c  |  2 +-
 drivers/dma/k3dma.c |  2 +-
 drivers/dma/lpc18xx-dmamux.c|  2 +-
 drivers/dma/mmp_pdma.c  |  2 +-
 drivers/dma/mmp_tdma.c  |  2 +-
 drivers/dma/moxart-dma.c|  2 +-
 drivers/dma/mxs-dma.c   |  2 +-
 drivers/dma/nbpfaxi.c   |  2 +-
 drivers/dma/of-dma.c| 19 ---
 drivers/dma/pl330.c |  3 ++-
 drivers/dma/pxa_dma.c   |  2 +-
 drivers/dma/qcom/bam_dma.c  |  2 +-
 drivers/dma/sh/rcar-dmac.c  |  2 +-
 drivers/dma/sh/shdma-of.c   |  2 +-
 drivers/dma/sh/usb-dmac.c   |  2 +-
 drivers/dma/sirf-dma.c  |  2 +-
 drivers/dma/st_fdma.c   |  2 +-
 drivers/dma/ste_dma40.c |  2 +-
 drivers/dma/stm32-dma.c |  2 +-
 drivers/dma/sun4i-dma.c |  2 +-
 drivers/dma/sun6i-dma.c |  2 +-
 drivers/dma/tegra20-apb-dma.c   |  2 +-
 drivers/dma/tegra210-adma.c |  2 +-
 drivers/dma/xilinx/xilinx_dma.c |  2 +-
 drivers/dma/xilinx/zynqmp_dma.c |  2 +-
 drivers/dma/zx_dma.c|  2 +-
 include/linux/of_dma.h  | 19 +++
 sound/soc/sh/rcar/dma.c |  5 +++--
 sound/soc/sh/rcar/dvc.c |  3 ++-
 sound/soc/sh/rcar/rsnd.h|  3 ++-
 sound/soc/sh/rcar/src.c |  3 ++-
 sound/soc/sh/rcar/ssi.c |  3 ++-
 45 files changed, 75 insertions(+), 61 deletions(-)

diff --git a/drivers/dma/amba-pl08x.c b/drivers/dma/amba-pl08x.c
index 0b7c6ce629a6..194089c98755 100644
--- a/drivers/dma/amba-pl08x.c
+++ b/drivers/dma/amba-pl08x.c
@@ -2059,7 +2059,7 @@ static struct dma_chan *pl08x_find_chan_id(struct 
pl08x_driver_data *pl08x,
 }
 
 static struct dma_chan *pl08x_of_xlate(struct of_phandle_args *dma_spec,
-  struct of_dma *ofdma)
+struct of_dma *ofdma, struct device *slave)
 {
struct pl08x_driver_data *pl08x = ofdma->of_dma_data;
struct dma_chan *dma_chan;
diff --git a/drivers/dma/at_hdmac.c b/drivers/dma/at_hdmac.c
index 1baf3404a365..b228b263ac0c 100644
--- a/drivers/dma/at_hdmac.c
+++ b/drivers/dma/at_hdmac.c
@@ -1788,7 +1788,7 @@ static bool at_dma_filter(struct dma_chan *chan, void 
*slave)
 }
 
 static struct dma_chan *at_dma_xlate(struct of_phandle_args *dma_spec,
-struct of_dma *of_dma)
+   struct of_dma *of_dma, struct device *slave)
 {
struct dma_chan *chan;
struct at_dma_chan *atchan;
@@ -1847,7 +1847,7 @@ static struct dma_chan *at_dma_xlate(struct 
of_phandle_args *dma_spec,
 }
 #else
 static struct dma_chan *at_dma_xlate(struct of_phandle_args *dma_spec,
-struct of_dma *of_dma)
+   struct of_dma *of_dma, struct device *slave)
 {
return NULL;
 }
diff --git a/drivers/dma/at_xdmac.c b/drivers/dma/at_xdmac.c
index 7d4e0bcda9af..9ddd868c9b59 100644
--- a/drivers/dma/at_xdmac.c
+++ b/drivers/dma/at_xdmac.c
@@ -508,7 +508,7 @@ static inline void at_xdmac_increment_block_count(struct 
dma_chan *chan,
 }
 
 static struct dma_chan *at_xdmac_xlate(struct of_phandle_args *dma_spec,
-  struct of_dma *of_dma)
+   struct of_dma *of_dma, struct device *slave)
 {
struct at_xdmac *atxdmac = of_dma->of_dma_data;
struct at_xdmac_chan*atchan;
diff --git a/drivers/dma/bcm2835-dma.c b/drivers/dma/bcm2835-dma.c
index e18dc596cf24..e9c417ad2141 100644
--- a/drivers/dma/bcm2835-dma.c
+++ b/drivers/dma/bcm2835-dma.c
@@ -877,7 +877,7 @@ static void bcm2835_dma_free(struct bcm2835_dmadev *od)
 MODULE_DEVICE_TABLE(of, bcm2835_dma_of_match);
 
 static struct dma_chan *bcm2835_dma_xlate(struct of_phandle_args *spec,
-  struct of_dma *ofdma)
+struct of_dma *ofdma, struct device *slave)
 {
struct bcm2835_dmadev *d = ofdma->of_dma_data;
struct dma_chan *chan;
diff --git a/drivers/dma/coh901318.c 

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

[Marek Szyprowski]

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.

Signed-off-by: Marek Szyprowski 
Reviewed-by: Ulf Hansson 
Acked-by: Arnd Bergmann 
---
 drivers/dma/amba-pl08x.c|  2 +-
 drivers/dma/at_hdmac.c  |  4 ++--
 drivers/dma/at_xdmac.c  |  2 +-
 drivers/dma/bcm2835-dma.c   |  2 +-
 drivers/dma/coh901318.c |  2 +-
 drivers/dma/cppi41.c|  2 +-
 drivers/dma/dma-jz4780.c|  2 +-
 drivers/dma/dmaengine.c |  2 +-
 drivers/dma/dw/platform.c   |  2 +-
 drivers/dma/edma.c  |  4 ++--
 drivers/dma/fsl-edma.c  |  2 +-
 drivers/dma/img-mdc-dma.c   |  2 +-
 drivers/dma/imx-dma.c   |  2 +-
 drivers/dma/imx-sdma.c  |  2 +-
 drivers/dma/k3dma.c |  2 +-
 drivers/dma/lpc18xx-dmamux.c|  2 +-
 drivers/dma/mmp_pdma.c  |  2 +-
 drivers/dma/mmp_tdma.c  |  2 +-
 drivers/dma/moxart-dma.c|  2 +-
 drivers/dma/mxs-dma.c   |  2 +-
 drivers/dma/nbpfaxi.c   |  2 +-
 drivers/dma/of-dma.c| 19 ---
 drivers/dma/pl330.c |  3 ++-
 drivers/dma/pxa_dma.c   |  2 +-
 drivers/dma/qcom/bam_dma.c  |  2 +-
 drivers/dma/sh/rcar-dmac.c  |  2 +-
 drivers/dma/sh/shdma-of.c   |  2 +-
 drivers/dma/sh/usb-dmac.c   |  2 +-
 drivers/dma/sirf-dma.c  |  2 +-
 drivers/dma/st_fdma.c   |  2 +-
 drivers/dma/ste_dma40.c |  2 +-
 drivers/dma/stm32-dma.c |  2 +-
 drivers/dma/sun4i-dma.c |  2 +-
 drivers/dma/sun6i-dma.c |  2 +-
 drivers/dma/tegra20-apb-dma.c   |  2 +-
 drivers/dma/tegra210-adma.c |  2 +-
 drivers/dma/xilinx/xilinx_dma.c |  2 +-
 drivers/dma/xilinx/zynqmp_dma.c |  2 +-
 drivers/dma/zx_dma.c|  2 +-
 include/linux/of_dma.h  | 19 +++
 sound/soc/sh/rcar/dma.c |  5 +++--
 sound/soc/sh/rcar/dvc.c |  3 ++-
 sound/soc/sh/rcar/rsnd.h|  3 ++-
 sound/soc/sh/rcar/src.c |  3 ++-
 sound/soc/sh/rcar/ssi.c |  3 ++-
 45 files changed, 75 insertions(+), 61 deletions(-)

diff --git a/drivers/dma/amba-pl08x.c b/drivers/dma/amba-pl08x.c
index 0b7c6ce629a6..194089c98755 100644
--- a/drivers/dma/amba-pl08x.c
+++ b/drivers/dma/amba-pl08x.c
@@ -2059,7 +2059,7 @@ static struct dma_chan *pl08x_find_chan_id(struct 
pl08x_driver_data *pl08x,
 }
 
 static struct dma_chan *pl08x_of_xlate(struct of_phandle_args *dma_spec,
-  struct of_dma *ofdma)
+struct of_dma *ofdma, struct device *slave)
 {
struct pl08x_driver_data *pl08x = ofdma->of_dma_data;
struct dma_chan *dma_chan;
diff --git a/drivers/dma/at_hdmac.c b/drivers/dma/at_hdmac.c
index 1baf3404a365..b228b263ac0c 100644
--- a/drivers/dma/at_hdmac.c
+++ b/drivers/dma/at_hdmac.c
@@ -1788,7 +1788,7 @@ static bool at_dma_filter(struct dma_chan *chan, void 
*slave)
 }
 
 static struct dma_chan *at_dma_xlate(struct of_phandle_args *dma_spec,
-struct of_dma *of_dma)
+   struct of_dma *of_dma, struct device *slave)
 {
struct dma_chan *chan;
struct at_dma_chan *atchan;
@@ -1847,7 +1847,7 @@ static struct dma_chan *at_dma_xlate(struct 
of_phandle_args *dma_spec,
 }
 #else
 static struct dma_chan *at_dma_xlate(struct of_phandle_args *dma_spec,
-struct of_dma *of_dma)
+   struct of_dma *of_dma, struct device *slave)
 {
return NULL;
 }
diff --git a/drivers/dma/at_xdmac.c b/drivers/dma/at_xdmac.c
index 7d4e0bcda9af..9ddd868c9b59 100644
--- a/drivers/dma/at_xdmac.c
+++ b/drivers/dma/at_xdmac.c
@@ -508,7 +508,7 @@ static inline void at_xdmac_increment_block_count(struct 
dma_chan *chan,
 }
 
 static struct dma_chan *at_xdmac_xlate(struct of_phandle_args *dma_spec,
-  struct of_dma *of_dma)
+   struct of_dma *of_dma, struct device *slave)
 {
struct at_xdmac *atxdmac = of_dma->of_dma_data;
struct at_xdmac_chan*atchan;
diff --git a/drivers/dma/bcm2835-dma.c b/drivers/dma/bcm2835-dma.c
index e18dc596cf24..e9c417ad2141 100644
--- a/drivers/dma/bcm2835-dma.c
+++ b/drivers/dma/bcm2835-dma.c
@@ -877,7 +877,7 @@ static void bcm2835_dma_free(struct bcm2835_dmadev *od)
 MODULE_DEVICE_TABLE(of, bcm2835_dma_of_match);
 
 static struct dma_chan *bcm2835_dma_xlate(struct of_phandle_args *spec,
-  struct of_dma *ofdma)
+struct of_dma *ofdma, struct device *slave)
 {
struct bcm2835_dmadev *d = ofdma->of_dma_data;
struct dma_chan *chan;
diff --git a/drivers/dma/coh901318.c b/drivers/dma/coh901318.c
index 74794c9859f6..dbc4fb44f326 100644