Hi On Wed, May 20, 2020 at 5:42 PM Lucas Stach <l.stach@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx> 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
