From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andres Salomon Subject: Re: [Device-drivers-devel] [PATCH] Add driver for Analog Devices ADAU1701 SigmaDSP Date: Mon, 18 Apr 2011 17:15:05 -0700 Message-ID: <20110418171505.4b1699f3@queued.net> 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> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Received: from lunge.queued.net (LUNGE.MIT.EDU [18.54.1.69]) by alsa0.perex.cz (Postfix) with ESMTP id 6EE3210381E for ; Tue, 19 Apr 2011 02:15:11 +0200 (CEST) In-Reply-To: <20110307145931.GK13471@opensource.wolfsonmicro.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: alsa-devel-bounces@alsa-project.org Errors-To: alsa-devel-bounces@alsa-project.org To: Mark Brown Cc: cliff.cai@analog.com, Mike Frysinger , alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org, device-drivers-devel@blackfin.uclinux.org, akpm@linux-foundation.org, lrg@slimlogic.co.uk List-Id: alsa-devel@alsa-project.org T24gTW9uLCA3IE1hciAyMDExIDE0OjU5OjMxICswMDAwCk1hcmsgQnJvd24gPGJyb29uaWVAb3Bl bnNvdXJjZS53b2xmc29ubWljcm8uY29tPiB3cm90ZToKCj4gT24gTW9uLCBNYXIgMDcsIDIwMTEg YXQgMDc6Mjk6MTJBTSAtMDUwMCwgTWlrZSBGcnlzaW5nZXIgd3JvdGU6Cj4gPiBPbiBNb24sIE1h ciA3LCAyMDExIGF0IDA3OjE1LCBNYXJrIEJyb3duIHdyb3RlOgo+IApbLi4uXQo+IAo+ID4gPiBS aWdodCwgYW5kIHRoaXMgaXNuJ3QgYSBwYXJ0aWN1bGFybHkgdW51c3VhbCByZXF1aXJlbWVudAo+ ID4gPiBlc3BlY2lhbGx5IGlmIHRoZSBkcml2ZXIgaXNuJ3QgZ29pbmcgdG8gaGF2ZSBhbnkgYWJp bGl0eSB0bwo+ID4gPiBpbnRlcmFjdCB3aXRoIHRoZSBEU1AgKGF0IHdoaWNoIHBvaW50IGl0J3Mg anVzdCBjb2VmZmljaWVudCBkYXRhLAo+ID4gPiB0aGUgZmFjdCB0aGF0IGl0J3MgYSBEU1AgcHJv Z3JhbSBpcyB1bmludGVyZXN0aW5nKS4gwqBUaGUgcHJvYmxlbQo+ID4gPiBpcyB0aGF0IHRoaXMg aXNuJ3QgYSBncmVhdCBpbnRlcmZhY2UgZm9yIGRvaW5nIHRoYXQuCj4gCj4gPiBpIGRvbnQgc2Vl IHN1Z2dlc3Rpb25zIG9mIGEgYmV0dGVyIGludGVyZmFjZSBhbnl3aGVyZSAuLi4KPiAKPiBJdCBj dXJyZW50bHkgaXNuJ3QgYW5kIEknZCBlbmNvdXJhZ2UgeW91IHRvIGNvbnRyaWJ1dGUgdG8gdGhl Cj4gZGlzY3Vzc2lvbiB0aGF0J3MgYmVlbiBnb2luZyBvbiBvbiB0aGlzLCBvciBldmVuIGJldHRl ciBoZWxwIG91dCB3aXRoCj4gY29kZS4gIFRoZXJlIHdhcyBzb21lIGRpc2N1c3Npb24gb24gdGhl IGxpc3QgcmVjZW50bHkgKGluIHRoZSBwYXN0Cj4gbW9udGggSUlSQykuCj4gCj4gV2hhdGV2ZXIg d2UgZG8gaXMgZ29pbmcgdG8gcmVxdWlyZSBzb21lIGFkZGl0aW9uYWwgQVBJcyBpbiBhbHNhLWxp YiwKPiBJJ2QgZXhwZWN0LiAgVGhlIGtleSByZXF1aXJlbWVudHMgSSdtIGF3YXJlIG9mIGFyZSB0 aGF0IHdlIGJlIGFibGUgdG8KPiBzdXBwb3J0Ogo+IAo+ICAtIERpc2NvdmVyYWJsZSB1c2Vyc3Bh Y2UgaW50ZXJmYWNlLgo+ICAtIFZlcnkgbGFyZ2UgZGF0YSBzaXplcyAobWVnYWJ5dGVzIGhhdmUg YmVlbiBtZW50aW9uZWQpLgo+ICAtIEFkZGluZyBhbmQgcmVtb3ZpbmcgcGFyYW1ldGVyIHNldHMg YXQgcnVudGltZSAoZm9yIGluIHN5c3RlbQo+ICAgIGNhbGxpYnJhdGlvbikuCj4gCj4gR2l2ZW4g dGhlIG51bWJlciBvZiBwZW9wbGUgbG9va2luZyBhdCB0aGlzIGZyb20gdmFyaW91cyBhbmdsZXMg SSdkCj4gZXhwZWN0IHRvIHNlZSBzb21lIHNvcnQgb2YgcHJvZ3Jlc3MgdGhpcyB5ZWFyIChwcm9i YWJseSBpbiB0aGUgbmV4dAo+IHF1YXRlciBvciBzbyksIGJ1dCBvYnZpb3VzbHkgbm8gZ3VhcmFu dGVlcy4KCk91dCBvZiBjdXJpb3NpdHksIGhhcyBhbnkgcHJvZ3Jlc3MgYmVlbiBtYWRlIG9uIHRo aXM/Cgo+IAo+ID4gd3J0IHBtLCB0aGF0J3MgYSB0cml2aWFsIHByb2dyYW1taW5nIGlzc3VlIHRo YXQgd291bGQgYmUgcmVzb2x2ZWQgaW4KPiA+IHRoZSBkcml2ZXIuICB1c2Vyc3BhY2UgbmVlZCBu b3QgY2FyZS4KPiAKPiBUaGF0J3MgdGhlIGlkZWFsLCBJIG1lbnRpb25lZCB0aGlzIGFzIHNldmVy YWwgb2YgbXkgb3RoZXIgcmV2aWV3Cj4gY29tbWVudHMgY29uY2VybmVkIGlzc3VlcyB3aXRoIHBv d2VyIG1hbmFnZW1lbnQgaW4gdGhlIGRyaXZlciAtCj4gYWRkcmVzc2luZyB0aG9zZSB3aWxsIHBy b2JhYmx5IHJlcXVpcmUgdGhhdCB0aGUgaW50ZWdyYXRpb24gb2NjdXIuCj4gCj4gPiB3cnQgc3Ry ZWFtIGZsb3dzLCBhbGwgdGhlIGN1c3RvbWVycyB3ZSd2ZSB0YWxrZWQgdG8gYXJlIGZpbmUgd2l0 aAo+ID4gdGhpcyAtLSBoYXZpbmcgc3RyZWFtIGNvbnRyb2wgYmUgYW4gYXBwbGljYXRpb24gaXNz dWUuICB0aGVpcgo+ID4gYXBwbGljYXRpb24gaXMgZHJpdmluZyB0aGUgY29kZWMgZGlyZWN0bHkg YW5kIGtub3dzIHdoZW4gaXQgbmVlZHMKPiA+IHRvIGNoYW5nZSB0aGUgZmlybXdhcmUsIHNvIGl0 IHBhdXNlcyBpdHMgYWxzYSBmbG93LCBsb2FkcyB0aGUgbmV3Cj4gPiBmaXJtd2FyZSwgYW5kIG1v dmVzIG9uLgoKV2hhdCB3b3VsZCBhY3R1YWxseSBjYXVzZSB0aGUgZmlybXdhcmUgdG8gY2hhbmdl PyAgV291bGQgdGhlIHVzZXJzcGFjZQphcHBsaWNhdGlvbiB0aGF0J3MgY3VycmVudGx5IGRyaXZp bmcgdGhlIGNvZGVjIGtub3cgdGhhdCBpdCBuZWVkcyB0bwpsb2FkIGEgbmV3IGZpcm13YXJlLCBv ciB3aWxsIHRoZXJlIGJlIG11bHRpcGxlIGFwcGxpY2F0aW9ucyBwb3RlbnRpYWxseQppbnRlcmFj dGluZyB3aXRoIHRoZSBjb2RlYyAod2l0aCBvbmx5IG9uZSBkcml2aW5nIGl0LCBhbmQgYW5vdGhl cgpkZWNpZGluZyB0aGF0IHRoZSBmaXJtd2FyZSBzaG91bGQgY2hhbmdlKT8KCk9uZSBjYW4gaW1h Z2luZSB0d28gZGlmZmVyZW50IHR5cGVzIG9mIEFQSXMgZGVwZW5kaW5nIHVwb24gdGhlIGFuc3dl cnMKdG8gdGhvc2UgcXVlc3Rpb25zLiAgSWYgdGhlIGFwcGxpY2F0aW9uIGRyaXZpbmcgdGhlIGNv ZGVjIGlzIGFsc28KY2hhbmdpbmcgdGhlIGZpcm13YXJlLCBhIHNpbXBsZSAnZWNobyBuZXdfZmly bXdhcmVfbmFtZS5iaW4gPgovc3lzLy4uLi9maWx0ZXJfY29lZmYnIChvciBlcXVpdmFsZW50IEFM U0EgZnVuY3Rpb24pCnRvIGNhdXNlIHNvbWV0aGluZyBpbiBhbHNhIGNvcmUgdG8gc3RvcC9wYXVz ZS9tdXRlIHBsYXliYWNrIG9yIGNhcHR1cmUKYW5kIHJlc3RhcnQgZXZlcnl0aGluZyBhZnRlciB0 aGUgZmlybXdhcmUgaGFzIGJlZW4gbG9hZGVkIGlzIGFsbCB0aGF0J3MKbmVjZXNzYXJ5LiAgVGhh dCBpcywgdXNlcnNwYWNlIHRyaWdnZXJzIHRoZSBmaXJtd2FyZSBsb2FkaW5nLgpIb3dldmVyLCBp ZiBtdWx0aXBsZSBhcHBsaWNhdGlvbnMgYXJlIGdvaW5nIHRvIGJlIGludGVyYWN0aW5nIHdpdGgK dGhlIGNvZGVjLCBJJ2QgaW1hZ2luZSB3ZSdkIG5lZWQgc29tZXRoaW5nIG1vcmUgY29tcGxleDsg cGVyaGFwcyBhIGhvb2sKaW4gc25kX3NvY19kYWlfb3BzIHRoYXQncyBjYWxsZWQgYW55dGltZSBz dHJlYW0gc3RhdGUgY2hhbmdlcz8gIFRoYXQKd291bGQgbGVhdmUgdXNlcnNwYWNlIG5vIGxvbmdl ciBhYmxlIHRvIGV4cGxpY2l0bHkgdHJpZ2dlciBhIHJlbG9hZCwgYnV0CmxlYXZlIHRoZSBkcml2 ZXIgc21hcnQgZW5vdWdoIHRvIGVuc3VyZSB0aGF0IHdoZW4gYSBuZXcgZmlybXdhcmUgaXMKYXZh aWxhYmxlLCBpdCB3aWxsIGJlIGxvYWRlZCBvbmNlIGl0IGlzIHNhZmUgdG8gZG8gc28gKGEgYnJl YWsgaW4KdXNlcnNwYWNlIGNvZGVjIHVzYWdlKS4KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18KQWxzYS1kZXZlbCBtYWlsaW5nIGxpc3QKQWxzYS1kZXZlbEBh bHNhLXByb2plY3Qub3JnCmh0dHA6Ly9tYWlsbWFuLmFsc2EtcHJvamVjdC5vcmcvbWFpbG1hbi9s aXN0aW5mby9hbHNhLWRldmVsCg== From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753027Ab1DSAPM (ORCPT ); Mon, 18 Apr 2011 20:15:12 -0400 Received: from LUNGE.MIT.EDU ([18.54.1.69]:41740 "EHLO lunge.queued.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751353Ab1DSAPK convert rfc822-to-8bit (ORCPT ); Mon, 18 Apr 2011 20:15:10 -0400 Date: Mon, 18 Apr 2011 17:15:05 -0700 From: Andres Salomon To: Mark Brown Cc: 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, Mike Frysinger Subject: Re: [Device-drivers-devel] [PATCH] Add driver for Analog Devices ADAU1701 SigmaDSP Message-ID: <20110418171505.4b1699f3@queued.net> In-Reply-To: <20110307145931.GK13471@opensource.wolfsonmicro.com> 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> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 7 Mar 2011 14:59:31 +0000 Mark Brown wrote: > On Mon, Mar 07, 2011 at 07:29:12AM -0500, Mike Frysinger wrote: > > On Mon, Mar 7, 2011 at 07:15, Mark Brown wrote: > [...] > > > > Right, and this isn't a particularly unusual requirement > > > especially if the driver isn't going to have any ability to > > > interact with the DSP (at which point it's just coefficient data, > > > the fact that it's a DSP program is uninteresting).  The problem > > > is that this isn't a great interface for doing that. > > > i dont see suggestions of a better interface anywhere ... > > It currently isn't and I'd encourage you to contribute to the > discussion that's been going on on this, or even better help out with > code. There was some discussion on the list recently (in the past > month IIRC). > > Whatever we do is going to require some additional APIs in alsa-lib, > I'd expect. The key requirements I'm aware of are that we be able to > support: > > - Discoverable userspace interface. > - Very large data sizes (megabytes have been mentioned). > - Adding and removing parameter sets at runtime (for in system > callibration). > > Given the number of people looking at this from various angles I'd > expect to see some sort of progress this year (probably in the next > quater or so), but obviously no guarantees. Out of curiosity, has any progress been made on this? > > > wrt pm, that's a trivial programming issue that would be resolved in > > the driver. userspace need not care. > > That's the ideal, I mentioned this as several of my other review > comments concerned issues with power management in the driver - > addressing those will probably require that the integration occur. > > > wrt stream flows, all the customers we've talked to are fine with > > this -- having stream control be an application issue. their > > application is driving the codec directly and knows when it needs > > to change the firmware, so it pauses its alsa flow, loads the new > > firmware, and moves on. What would actually cause the firmware to change? Would the userspace application that's currently driving the codec know that it needs to load a new firmware, or will there be multiple applications potentially interacting with the codec (with only one driving it, and another deciding that the firmware should change)? One can imagine two different types of APIs depending upon the answers to those questions. If the application driving the codec is also changing the firmware, a simple 'echo new_firmware_name.bin > /sys/.../filter_coeff' (or equivalent ALSA function) to cause something in alsa core to stop/pause/mute playback or capture and restart everything after the firmware has been loaded is all that's necessary. That is, userspace triggers the firmware loading. However, if multiple applications are going to be interacting with the codec, I'd imagine we'd need something more complex; perhaps a hook in snd_soc_dai_ops that's called anytime stream state changes? That would leave userspace no longer able to explicitly trigger a reload, but leave the driver smart enough to ensure that when a new firmware is available, it will be loaded once it is safe to do so (a break in userspace codec usage).