Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752521Ab1CIHjH (ORCPT ); Wed, 9 Mar 2011 02:39:07 -0500 Received: from mail-fx0-f46.google.com ([209.85.161.46]:51027 "EHLO mail-fx0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750908Ab1CIHjF convert rfc822-to-8bit (ORCPT ); Wed, 9 Mar 2011 02:39:05 -0500 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=VM04MKfno9ZUd+BIM6XFMhbLKI8RGpwVatrP/MJ5oE9btTgYILOL1ICqV7o5HRhvWA u+lDV1zeLUsJsLZT8g0/RB6UMnpNOV/dHFQnfAiN/QSBRnNySdRbNdh/GGe3KvDMibAK QcAUj+kQvPm1FR+C+EuCJhpAE9sbYdZ8Jp+M0= MIME-Version: 1.0 In-Reply-To: References: <1299460302-15392-1-git-send-email-cliff.cai@analog.com> <20110307114142.GB13471@opensource.wolfsonmicro.com> <20110307121502.GG13471@opensource.wolfsonmicro.com> <20110307145931.GK13471@opensource.wolfsonmicro.com> <20110307155508.GM13471@opensource.wolfsonmicro.com> Date: Wed, 9 Mar 2011 15:39:03 +0800 Message-ID: Subject: Re: [alsa-devel] [Device-drivers-devel] [PATCH] Add driver for Analog Devices ADAU1701 SigmaDSP From: Cliff Cai To: Mike Frysinger Cc: Mark Brown , cliff.cai@analog.com, alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org, device-drivers-devel@blackfin.uclinux.org, akpm@linux-foundation.org, lrg@slimlogic.co.uk Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5485 Lines: 98 On Wed, Mar 9, 2011 at 2:08 PM, Mike Frysinger wrote: > On Mon, Mar 7, 2011 at 10:55, Mark Brown wrote: >> On Mon, Mar 07, 2011 at 10:33:25AM -0500, Mike Frysinger wrote: >>> On Mon, Mar 7, 2011 at 09:59, Mark Brown wrote: >>> > I'd expect that the driver would at least error out if the user tried to >>> > do the wrong thing here, like I say currently the firmware code is just >>> > not joined up with anything else at all. >> >>> i dont see how the driver can detect a "wrong" thing. ?the driver has >>> no idea what arbitrary code the user is going to load and what that >>> code is going to do, or validate the code in any way. ?this is why the >>> firmware has a small crc header on it -- we only make sure that what >>> the user compiled at build time matches what is loaded into the >>> hardware. >> >> At a bare minimum suddenly stopping and starting the firmware while >> audio is going through it is unlikely to work well (you'd most likely >> get a hard stop of the audio followed by a sudden hard start which sound >> very unpleasant to listeners) and so should be prevented. ?There's a >> bunch of options for doing this (including refusing to change, ensuring >> the DSP output is muted during the change or routing around the DSP >> while doing the change). > > you would probably get the "normal" clicks and pops, but i guess your > view of "wrong" is much more strict than mine ;). ?i'm not sure our > parts allow routing around the DSP (Cliff would have to comment). ?as > for the rest, i think it'd be best to let the user space app dictate > how they want to handle things. ?perhaps clicks/pops are fine with > them. ?or they arent, and so the userspace app would make sure to > pause/mute/whatever the stream. ?either way, this sounds like a policy > that shouldnt be hard coded in the codec driver. again,this part is a DSP itself not an audio codec like adau1761 whose DSP core can be bypassed. >>> > systems) there's no reason they shouldn't be able to rely on standard >>> > tools for managing their audio configurations. >> >>> if the standard tools existed today, i'd of course agree. ?but as you >>> indicated there's nothing right now for us to bug off of. ?so how >>> userspace "probes" for existing data would be however the end user >>> chooses to manage things. ?it's not like the standard tools could >>> really provide anything other than a simple string that indicates >>> "some blob exists with name xxx". ?the meaning/metadata that surrounds >>> xxx isnt really relevant from the kernel's pov. >> >> The standard tools should also be able to manage the mechanics of >> actually getting the new data into the kernel at appropriate moments. >> This includes both offering control via UIs such as alsamixer and being >> able to include configuration of the data in UCM configurations. > > exposing this via alsamixer and friends would be a useful debugging > tool so people can toy around with known working configurations. ?and > have code examples to see how to do it. > >>> > At present userspace can enumerate and change the runtime configuration >>> > the system offers via the ALSA APIs (and this will get even better once >>> > the media controller API starts being used). ?This means that you can >>> > fairly easily write a userspace that'll run on pretty much any Linux >>> > audio hardware, adapting with pure configuration for which you can >>> > provide point and click tuning (realistically by allowing the user to >>> > configure via standard ALSA tools and offering a "save as use case" type >>> > interface). ?If we start adding backdoors to drivers we're taking a step >>> > back from where we are currently by requiring that the application layer >>> > know magic stuff about individual systems in order to work with them. >> >>> from how we've seen people using these codecs, this scenario doesnt >>> make much sense. ?the different algorithms would be loaded on the fly >>> by the application and its current operating needs, not a single >>> algorithm selected by the ender user that wouldnt change for the life >>> of the app. ?not saying the scenario would never come up, just that it >>> isnt the one we'd be focused on. >> >> I'm not sure you're following what's being said here. ?The above control >> discussed above full system configuration of all the control offered by >> the system, not tuning the parameters of an individual algorithm. ?This >> includes volume controls, routing controls, algorithms, coefficients and >> anything else that can be changed. ?A scenario where you want to change >> the set of algorithms the hardware can support is certainly included in >> that. > > i just meant that the use cases we've been dealing with involve the > people developing the application taking care of picking which > firmwares to load at any particular time. ?having the end user (the > guy who buys the actual device) select firmwares doesnt make much > sense. ?but this particular qualification probably is irrelevant to > the framework you're proposing in the end. > -mike > _______________________________________________ > Alsa-devel mailing list > Alsa-devel@alsa-project.org > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/