Re: [PATCH 0/4] McBSP smart idle and DMA op mode updates for ASoC

From: Peter Ujfalusi <peter.ujfalusi@nokia.com>
To: ext Liam Girdwood <lrg@slimlogic.co.uk>
Cc: "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
	Tony Lindgren <tony@atomide.com>,
	Mark Brown <broonie@opensource.wolfsonmicro.com>,
	"Valentin Eduardo (Nokia-D/Helsinki)"
	<eduardo.valentin@nokia.com>,
	"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>
Subject: Re: [PATCH 0/4] McBSP smart idle and DMA op mode updates for ASoC
Date: Wed, 19 May 2010 15:27:35 +0300	[thread overview]
Message-ID: <201005191527.35439.peter.ujfalusi@nokia.com> (raw)
In-Reply-To: <1274267231.3240.117.camel@odin>

On Wednesday 19 May 2010 14:07:11 ext Liam Girdwood wrote:
> On Wed, 2010-05-19 at 13:42 +0300, Eduardo Valentin wrote:
> > On Tue, May 18, 2010 at 10:13:10PM +0200, Liam Girdwood wrote:
> > > This series expands the OMAP mcbsp driver to support changing it's DMA
> > > operating mode and smart idle mode from client drivers. It's primarily
> > > aimed at lowering the power consumption for OMAP ASoC drivers by
> > > providing methods to gate clocks on the mcbsp interface at runtime.
> > > 
> > > I've also added a patch to remove the mcbsp DMA op mode sysfs set
> > > functionality. I think DMA op mode is very specific to the mcbsp
> > > client driver _only_ and shouldn't really be changed by userspace.
> > > Please let me know if you use this feature and I'll drop this patch.
> > 
> > Yeah, I'm not sure if that would be strong enough argument though.
> > Unfortunately, this dma op mode also couples with the usage of mcbsp
> > internal buffer. Which in the very end will mean a compromise between
> > delay vs. pm, as you are probably aware.
> > 
> > So, letting userspace to toggle this mode will also mean they can choose
> > between pm friendly (op mode with frame and so on) or short delay
> > friendly (element mode).
> > 
> > Of course, this might not be the best way of choosing it though.
> 
> The sysfs set interface implies userspace having knowledge of driver
> capabilities and configuration in order to safely toggle between the two
> DMA modes. Imo, the mcbsp client driver should be the only entity
> configuring it's DMA modes (in a safe manner) depending on the use case.

Furthermore, if there is a need for 'Use Cases', than the machine driver can 
provide user control to switch between them.
The thing is that in most cases these are trivial, and mostly the same settings, 
but if you throw a codec like the tlv320dac33 into the mix, which has it's own 
FIFO, than things gets complicated.
The user (the real one, not the developer) has several settings scattered all 
around the place, and those has to be configured in harmony.
The only place is to do this, is in the machine driver, whihc than can build up 
'scenarios', and configure the things in synchronized manner.

> 
> Liam

-- 
Péter
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel