linux-kernel - Re: [PATCH v8 1/5] PM / Runtime: Add getter for querying the IRQ safe option

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20141105140910.GP1870@intel.com>
Date:	Wed, 5 Nov 2014 19:39:10 +0530
From:	Vinod Koul <vinod.koul@...el.com>
To:	Laurent Pinchart <laurent.pinchart@...asonboard.com>
Cc:	Krzysztof Kozlowski <k.kozlowski@...sung.com>,
	Pavel Machek <pavel@....cz>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Len Brown <len.brown@...el.com>,
	Jonathan Corbet <corbet@....net>,
	Russell King <linux@....linux.org.uk>,
	Dan Williams <dan.j.williams@...el.com>,
	Ulf Hansson <ulf.hansson@...aro.org>,
	Alan Stern <stern@...land.harvard.edu>,
	linux-pm@...r.kernel.org, linux-doc@...r.kernel.org,
	linux-kernel@...r.kernel.org, dmaengine@...r.kernel.org,
	Lars-Peter Clausen <lars@...afoo.de>,
	Michal Simek <michal.simek@...inx.com>,
	Kyungmin Park <kyungmin.park@...sung.com>,
	Marek Szyprowski <m.szyprowski@...sung.com>,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>
Subject: Re: [PATCH v8 1/5] PM / Runtime: Add getter for querying the IRQ
 safe option

On Mon, Nov 03, 2014 at 06:59:37PM +0200, Laurent Pinchart wrote:
> > > Many other drivers suffer from the same problem. While I won't reject your
> > > proposed fix, I would prefer a more generic approach.
> > > 
> > > One option that has been discussed previously was to use a work queue to
> > > delay starting the DMA transfer to an interruptible context where
> > > pm_runtime_get_sync() could be called. However, as Russell pointed out
> > > [1],
> > > even that won't work in all cases as the DMA slave might need the transfer
> > > to be started before enabling part of its hardware (OMAP audio seem to be
> > > such a case).
> > > 
> > > I've heard a rumor of a possible DMA engine rework to forbid calling the
> > > descriptor preparation API from atomic context. This could be used as a
> > > base to implement runtime PM, as DMA slave drivers should not prepare
> > > descriptors if they don't need to use them. However that's a long term
> > > plan, and we need a solution sooner than that.
> > 
> > Well it is not a rumour :)
> 
> I didn't want to put too much pressure on you by quoting you on that :-)
> 
> > I have been contemplating that now that async_tx will be killed so we dont
> > have to worry about that usage. For the slave dma usage, we can change the
> > prepare API to be non atomic. I think the users will be okay with approach.
> > This way drivers can use runtime pm calls in prepare.
> 
> I'd certainly welcome that. There's a couple of users we will need to fix as 
> they call the prepare API from an atomic context. I'm thinking about ASoC 
> drivers in particular.
ASoC is impler to fix as we can do this is ASoC prepare which is not atomic.
So we would need to split prepare and submit on that

> Do you have any time line in mind ?
Not yet, perhpaps the one after next merge window will be good target.

-- 
~Vinod
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/