Re: [PATCH v8 3/3] dmaengine: pl330: Don't require irq-safe runtime PM

On 13 February 2017 at 16:47, Vinod Koul wrote: > On Mon, Feb 13, 2017 at 04:32:32PM +0100, Ulf Hansson wrote: >> [...] >> >> >> Although, I don't know of other examples, besides the runtime PM use >> >> case, where non-atomic channel prepare/unprepare would make sense. Do

Re: [PATCH v8 3/3] dmaengine: pl330: Don't require irq-safe runtime PM

On 13 February 2017 at 16:47, Vinod Koul wrote: > On Mon, Feb 13, 2017 at 04:32:32PM +0100, Ulf Hansson wrote: >> [...] >> >> >> Although, I don't know of other examples, besides the runtime PM use >> >> case, where non-atomic channel prepare/unprepare would make sense. Do >> >> you? >> > >> >

Re: [PATCH v8 3/3] dmaengine: pl330: Don't require irq-safe runtime PM

Hi Vinod, On 2017-02-13 16:47, Vinod Koul wrote: On Mon, Feb 13, 2017 at 04:32:32PM +0100, Ulf Hansson wrote: [...] Although, I don't know of other examples, besides the runtime PM use case, where non-atomic channel prepare/unprepare would make sense. Do you? The primary ask for that has

Re: [PATCH v8 3/3] dmaengine: pl330: Don't require irq-safe runtime PM

Hi Vinod, On 2017-02-13 16:47, Vinod Koul wrote: On Mon, Feb 13, 2017 at 04:32:32PM +0100, Ulf Hansson wrote: [...] Although, I don't know of other examples, besides the runtime PM use case, where non-atomic channel prepare/unprepare would make sense. Do you? The primary ask for that has

Re: [PATCH v8 3/3] dmaengine: pl330: Don't require irq-safe runtime PM

On Mon, Feb 13, 2017 at 04:32:32PM +0100, Ulf Hansson wrote: > [...] > > >> Although, I don't know of other examples, besides the runtime PM use > >> case, where non-atomic channel prepare/unprepare would make sense. Do > >> you? > > > > The primary ask for that has been to enable runtime_pm for

Re: [PATCH v8 3/3] dmaengine: pl330: Don't require irq-safe runtime PM

On Mon, Feb 13, 2017 at 04:32:32PM +0100, Ulf Hansson wrote: > [...] > > >> Although, I don't know of other examples, besides the runtime PM use > >> case, where non-atomic channel prepare/unprepare would make sense. Do > >> you? > > > > The primary ask for that has been to enable runtime_pm for

Re: [PATCH v8 3/3] dmaengine: pl330: Don't require irq-safe runtime PM

[...] >> Although, I don't know of other examples, besides the runtime PM use >> case, where non-atomic channel prepare/unprepare would make sense. Do >> you? > > The primary ask for that has been to enable runtime_pm for drivers. It's not > a new ask, but we somehow haven't gotten around to do

Re: [PATCH v8 3/3] dmaengine: pl330: Don't require irq-safe runtime PM

[...] >> Although, I don't know of other examples, besides the runtime PM use >> case, where non-atomic channel prepare/unprepare would make sense. Do >> you? > > The primary ask for that has been to enable runtime_pm for drivers. It's not > a new ask, but we somehow haven't gotten around to do

Re: [PATCH v8 3/3] dmaengine: pl330: Don't require irq-safe runtime PM

[...] >> The only related PM thing, that shall be the decision of the driver, >> is whether it wants to enable runtime PM or not, during ->probe(). > > > So do you want to create the links during the DMAengine driver probe? How do > you > plan to find all the client devices? Please note that you

Re: [PATCH v8 3/3] dmaengine: pl330: Don't require irq-safe runtime PM

[...] >> The only related PM thing, that shall be the decision of the driver, >> is whether it wants to enable runtime PM or not, during ->probe(). > > > So do you want to create the links during the DMAengine driver probe? How do > you > plan to find all the client devices? Please note that you

Re: [PATCH v8 3/3] dmaengine: pl330: Don't require irq-safe runtime PM

On Mon, Feb 13, 2017 at 01:15:27PM +0100, Marek Szyprowski wrote: > >Although, I don't know of other examples, besides the runtime PM use > >case, where non-atomic channel prepare/unprepare would make sense. Do > >you? > > Changing GFP_ATOMIC to GFP_KERNEL in some calls in the DMA engine drivers

Re: [PATCH v8 3/3] dmaengine: pl330: Don't require irq-safe runtime PM

On Mon, Feb 13, 2017 at 01:15:27PM +0100, Marek Szyprowski wrote: > >Although, I don't know of other examples, besides the runtime PM use > >case, where non-atomic channel prepare/unprepare would make sense. Do > >you? > > Changing GFP_ATOMIC to GFP_KERNEL in some calls in the DMA engine drivers

Re: [PATCH v8 3/3] dmaengine: pl330: Don't require irq-safe runtime PM

On Mon, Feb 13, 2017 at 12:11:54PM +0100, Ulf Hansson wrote: > >> > >> If we could set up the device link already at device initialization, > >> it should also be possible to avoid getting -EPROBE_DEFER for dma > >> client drivers when requesting their dma channels. > > > > Well if we defer then

Re: [PATCH v8 3/3] dmaengine: pl330: Don't require irq-safe runtime PM

On Mon, Feb 13, 2017 at 12:11:54PM +0100, Ulf Hansson wrote: > >> > >> If we could set up the device link already at device initialization, > >> it should also be possible to avoid getting -EPROBE_DEFER for dma > >> client drivers when requesting their dma channels. > > > > Well if we defer then

Re: [PATCH v8 3/3] dmaengine: pl330: Don't require irq-safe runtime PM

Hi Ulf, On 2017-02-13 12:11, Ulf Hansson wrote: If we could set up the device link already at device initialization, it should also be possible to avoid getting -EPROBE_DEFER for dma client drivers when requesting their dma channels. Well if we defer then driver will regiser with dmaengine

Re: [PATCH v8 3/3] dmaengine: pl330: Don't require irq-safe runtime PM

Hi Ulf, On 2017-02-13 12:11, Ulf Hansson wrote: If we could set up the device link already at device initialization, it should also be possible to avoid getting -EPROBE_DEFER for dma client drivers when requesting their dma channels. Well if we defer then driver will regiser with dmaengine

Re: [PATCH v8 3/3] dmaengine: pl330: Don't require irq-safe runtime PM

Hi Vinod, On 2017-02-13 03:03, Vinod Koul wrote: On Fri, Feb 10, 2017 at 02:57:09PM +0100, Ulf Hansson wrote: On 10 February 2017 at 12:51, Marek Szyprowski wrote: On 2017-02-10 05:50, Vinod Koul wrote: On Thu, Feb 09, 2017 at 03:22:51PM +0100, Marek Szyprowski

Re: [PATCH v8 3/3] dmaengine: pl330: Don't require irq-safe runtime PM

Hi Vinod, On 2017-02-13 03:03, Vinod Koul wrote: On Fri, Feb 10, 2017 at 02:57:09PM +0100, Ulf Hansson wrote: On 10 February 2017 at 12:51, Marek Szyprowski wrote: On 2017-02-10 05:50, Vinod Koul wrote: On Thu, Feb 09, 2017 at 03:22:51PM +0100, Marek Szyprowski wrote: +static int

Re: [PATCH v8 3/3] dmaengine: pl330: Don't require irq-safe runtime PM

Hi Ulf, On 2017-02-10 14:57, Ulf Hansson wrote: On 10 February 2017 at 12:51, Marek Szyprowski wrote: On 2017-02-10 05:50, Vinod Koul wrote: On Thu, Feb 09, 2017 at 03:22:51PM +0100, Marek Szyprowski wrote: +static int pl330_set_slave(struct dma_chan *chan, struct

Re: [PATCH v8 3/3] dmaengine: pl330: Don't require irq-safe runtime PM

Hi Ulf, On 2017-02-10 14:57, Ulf Hansson wrote: On 10 February 2017 at 12:51, Marek Szyprowski wrote: On 2017-02-10 05:50, Vinod Koul wrote: On Thu, Feb 09, 2017 at 03:22:51PM +0100, Marek Szyprowski wrote: +static int pl330_set_slave(struct dma_chan *chan, struct device *slave) +{ +

Re: [PATCH v8 3/3] dmaengine: pl330: Don't require irq-safe runtime PM

>> >> If we could set up the device link already at device initialization, >> it should also be possible to avoid getting -EPROBE_DEFER for dma >> client drivers when requesting their dma channels. > > Well if we defer then driver will regiser with dmaengine after it is > probed, so a client will

Re: [PATCH v8 3/3] dmaengine: pl330: Don't require irq-safe runtime PM

>> >> If we could set up the device link already at device initialization, >> it should also be possible to avoid getting -EPROBE_DEFER for dma >> client drivers when requesting their dma channels. > > Well if we defer then driver will regiser with dmaengine after it is > probed, so a client will

Re: [PATCH v8 3/3] dmaengine: pl330: Don't require irq-safe runtime PM

On Fri, Feb 10, 2017 at 02:57:09PM +0100, Ulf Hansson wrote: > On 10 February 2017 at 12:51, Marek Szyprowski > wrote: > > Hi Vinod, > > > > On 2017-02-10 05:50, Vinod Koul wrote: > >> > >> On Thu, Feb 09, 2017 at 03:22:51PM +0100, Marek Szyprowski wrote: > >> > >>>

Re: [PATCH v8 3/3] dmaengine: pl330: Don't require irq-safe runtime PM

On Fri, Feb 10, 2017 at 02:57:09PM +0100, Ulf Hansson wrote: > On 10 February 2017 at 12:51, Marek Szyprowski > wrote: > > Hi Vinod, > > > > On 2017-02-10 05:50, Vinod Koul wrote: > >> > >> On Thu, Feb 09, 2017 at 03:22:51PM +0100, Marek Szyprowski wrote: > >> > >>> +static int

Re: [PATCH v8 3/3] dmaengine: pl330: Don't require irq-safe runtime PM

On 10 February 2017 at 12:51, Marek Szyprowski wrote: > Hi Vinod, > > On 2017-02-10 05:50, Vinod Koul wrote: >> >> On Thu, Feb 09, 2017 at 03:22:51PM +0100, Marek Szyprowski wrote: >> >>> +static int pl330_set_slave(struct dma_chan *chan, struct device *slave) >>> +{ >>>

Re: [PATCH v8 3/3] dmaengine: pl330: Don't require irq-safe runtime PM

On 10 February 2017 at 12:51, Marek Szyprowski wrote: > Hi Vinod, > > On 2017-02-10 05:50, Vinod Koul wrote: >> >> On Thu, Feb 09, 2017 at 03:22:51PM +0100, Marek Szyprowski wrote: >> >>> +static int pl330_set_slave(struct dma_chan *chan, struct device *slave) >>> +{ >>> + struct

Re: [PATCH v8 3/3] dmaengine: pl330: Don't require irq-safe runtime PM

Hi Vinod, On 2017-02-10 05:50, Vinod Koul wrote: On Thu, Feb 09, 2017 at 03:22:51PM +0100, Marek Szyprowski wrote: +static int pl330_set_slave(struct dma_chan *chan, struct device *slave) +{ + struct dma_pl330_chan *pch = to_pchan(chan); + struct pl330_dmac *pl330 = pch->dmac; +

Re: [PATCH v8 3/3] dmaengine: pl330: Don't require irq-safe runtime PM

Hi Vinod, On 2017-02-10 05:50, Vinod Koul wrote: On Thu, Feb 09, 2017 at 03:22:51PM +0100, Marek Szyprowski wrote: +static int pl330_set_slave(struct dma_chan *chan, struct device *slave) +{ + struct dma_pl330_chan *pch = to_pchan(chan); + struct pl330_dmac *pl330 = pch->dmac; +

Re: [PATCH v8 3/3] dmaengine: pl330: Don't require irq-safe runtime PM

On Thu, Feb 09, 2017 at 03:22:51PM +0100, Marek Szyprowski wrote: > +static int pl330_set_slave(struct dma_chan *chan, struct device *slave) > +{ > + struct dma_pl330_chan *pch = to_pchan(chan); > + struct pl330_dmac *pl330 = pch->dmac; > + int i; > + > + mutex_lock(>rpm_lock);

Re: [PATCH v8 3/3] dmaengine: pl330: Don't require irq-safe runtime PM

On Thu, Feb 09, 2017 at 03:22:51PM +0100, Marek Szyprowski wrote: > +static int pl330_set_slave(struct dma_chan *chan, struct device *slave) > +{ > + struct dma_pl330_chan *pch = to_pchan(chan); > + struct pl330_dmac *pl330 = pch->dmac; > + int i; > + > + mutex_lock(>rpm_lock);

[PATCH v8 3/3] dmaengine: pl330: Don't require irq-safe runtime PM

This patch replaces irq-safe runtime PM with non-irq-safe version based on the new approach. Existing, irq-safe runtime PM implementation for PL330 was not bringing much benefits of its own - only clocks were enabled/disabled. Another limitation of irq-safe runtime PM is a fact, that it may

[PATCH v8 3/3] dmaengine: pl330: Don't require irq-safe runtime PM

This patch replaces irq-safe runtime PM with non-irq-safe version based on the new approach. Existing, irq-safe runtime PM implementation for PL330 was not bringing much benefits of its own - only clocks were enabled/disabled. Another limitation of irq-safe runtime PM is a fact, that it may