Hi
On Wed, May 20, 2020 at 5:42 PM Lucas Stach l.stach@pengutronix.de wrote:
Am Mittwoch, den 20.05.2020, 16:20 +0800 schrieb Shengjiu Wang:
Hi
On Tue, May 19, 2020 at 6:04 PM Lucas Stach l.stach@pengutronix.de wrote:
Am Dienstag, den 19.05.2020, 17:41 +0800 schrieb Shengjiu Wang:
There are two requirements that we need to move the request of dma channel from probe to open.
How do you handle -EPROBE_DEFER return code from the channel request if you don't do it in probe?
I use the dma_request_slave_channel or dma_request_channel instead of dmaengine_pcm_request_chan_of. so there should be not -EPROBE_DEFER return code.
This is a pretty weak argument. The dmaengine device might probe after you try to get the channel. Using a function to request the channel that doesn't allow you to handle probe deferral is IMHO a bug and should be fixed, instead of building even more assumptions on top of it.
I see some driver also request dma channel in open() or hw_params(). how can they avoid the defer probe issue? for example： sound/arm/pxa2xx-pcm-lib.c sound/soc/sprd/sprd-pcm-dma.c
- When dma device binds with power-domains, the power will
be enabled when we request dma channel. If the request of dma channel happen on probe, then the power-domains will be always enabled after kernel boot up, which is not good for power saving, so we need to move the request of dma channel to .open();
This is certainly something which could be fixed in the dmaengine driver.
Dma driver always call the pm_runtime_get_sync in device_alloc_chan_resources, the device_alloc_chan_resources is called when channel is requested. so power is enabled on channel request.
So why can't you fix the dmaengine driver to do that RPM call at a later time when the channel is actually going to be used? This will allow further power savings with other slave devices than the audio PCM.
Regards, Lucas
It seems the best place for calling pm_runtime_get_sync is the device_alloc_chan_resources, and calling pm_runtime_put_sync in the .device_free_chan_resources
For the slave_sg mode, the .device_prep_slave_sg and .device_issue_pending will be called many times after .device_alloc_chan_resources. so it is not good to call pm_runtime_get_sync in .device_prep_slave_sg or .device_issue_pending
best regards wang shengjiu