Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1263088 > unrolled thread

[PATCH 0/2] ASoC: Add support for DA7217 and DA7218 audio codecs

Started byAdam Thomson <Adam.Thomson.Opensource@diasemi.com>
First post2015-11-05 11:50 +0100
Last post2015-11-10 17:50 +0100
Articles 16 — 3 participants

Back to article view | Back to linux.kernel


Contents

  [PATCH 0/2] ASoC: Add support for DA7217 and DA7218 audio codecs Adam Thomson <Adam.Thomson.Opensource@diasemi.com> - 2015-11-05 11:50 +0100
    Re: [PATCH 2/2] ASoC: codecs: Add da7218 codec driver Mark Brown <broonie@kernel.org> - 2015-11-05 16:30 +0100
      RE: [PATCH 2/2] ASoC: codecs: Add da7218 codec driver "Opensource [Adam Thomson]" <Adam.Thomson.Opensource@diasemi.com> - 2015-11-06 12:20 +0100
        Re: [PATCH 2/2] ASoC: codecs: Add da7218 codec driver Mark Brown <broonie@kernel.org> - 2015-11-06 12:30 +0100
          RE: [PATCH 2/2] ASoC: codecs: Add da7218 codec driver "Opensource [Adam Thomson]" <Adam.Thomson.Opensource@diasemi.com> - 2015-11-06 13:00 +0100
            Re: [PATCH 2/2] ASoC: codecs: Add da7218 codec driver Mark Brown <broonie@kernel.org> - 2015-11-06 13:00 +0100
              RE: [PATCH 2/2] ASoC: codecs: Add da7218 codec driver "Opensource [Adam Thomson]" <Adam.Thomson.Opensource@diasemi.com> - 2015-11-06 14:20 +0100
                Re: [PATCH 2/2] ASoC: codecs: Add da7218 codec driver Mark Brown <broonie@kernel.org> - 2015-11-08 11:40 +0100
                  RE: [PATCH 2/2] ASoC: codecs: Add da7218 codec driver "Opensource [Adam Thomson]" <Adam.Thomson.Opensource@diasemi.com> - 2015-11-09 13:30 +0100
                    Re: [PATCH 2/2] ASoC: codecs: Add da7218 codec driver Mark Brown <broonie@kernel.org> - 2015-11-09 15:10 +0100
                      RE: [PATCH 2/2] ASoC: codecs: Add da7218 codec driver "Opensource [Adam Thomson]" <Adam.Thomson.Opensource@diasemi.com> - 2015-11-10 15:00 +0100
                        Re: [PATCH 2/2] ASoC: codecs: Add da7218 codec driver Mark Brown <broonie@kernel.org> - 2015-11-10 15:20 +0100
                          RE: [PATCH 2/2] ASoC: codecs: Add da7218 codec driver "Opensource [Adam Thomson]" <Adam.Thomson.Opensource@diasemi.com> - 2015-11-10 15:30 +0100
                            Re: [PATCH 2/2] ASoC: codecs: Add da7218 codec driver Mark Brown <broonie@kernel.org> - 2015-11-10 16:50 +0100
                              RE: [PATCH 2/2] ASoC: codecs: Add da7218 codec driver "Opensource [Adam Thomson]" <Adam.Thomson.Opensource@diasemi.com> - 2015-11-10 17:30 +0100
                                Re: [PATCH 2/2] ASoC: codecs: Add da7218 codec driver Mark Brown <broonie@kernel.org> - 2015-11-10 17:50 +0100

#1263088 — [PATCH 0/2] ASoC: Add support for DA7217 and DA7218 audio codecs

FromAdam Thomson <Adam.Thomson.Opensource@diasemi.com>
Date2015-11-05 11:50 +0100
Subject[PATCH 0/2] ASoC: Add support for DA7217 and DA7218 audio codecs
Message-ID<qrqhc-5qX-13@gated-at.bofh.it>
This patch set adds DT and ASoC codec driver support for DA7217 and DA7218.

Changes are based against v4.3 kernel version.

Adam Thomson (2):
  ASoC: da7218: Add bindings documentation for DA7218 audio codec
  ASoC: codecs: Add da7218 codec driver

 Documentation/devicetree/bindings/sound/da7218.txt |  116 +
 include/sound/da7218.h                             |  136 +
 sound/soc/codecs/da7218.c                          | 3349 ++++++++++++++++++++
 sound/soc/codecs/da7218.h                          | 1405 ++++++++
 4 files changed, 5006 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/sound/da7218.txt
 create mode 100644 include/sound/da7218.h
 create mode 100644 sound/soc/codecs/da7218.c
 create mode 100644 sound/soc/codecs/da7218.h

--
1.9.3

--
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/

[toc] | [next] | [standalone]


#1263327 — Re: [PATCH 2/2] ASoC: codecs: Add da7218 codec driver

FromMark Brown <broonie@kernel.org>
Date2015-11-05 16:30 +0100
SubjectRe: [PATCH 2/2] ASoC: codecs: Add da7218 codec driver
Message-ID<qruE9-8ru-7@gated-at.bofh.it>
In reply to#1263088

[Multipart message — attachments visible in raw view] — view raw

On Thu, Nov 05, 2015 at 10:43:19AM +0000, Adam Thomson wrote:

> +/* ALC */
> +static void da7218_alc_calib(struct snd_soc_codec *codec)
> +{
> +	struct da7218_priv *da7218 = snd_soc_codec_get_drvdata(codec);
> +	u8 calib_ctrl;
> +	int i = 0;
> +	bool calibrated = false;
> +
> +	/* Bypass cache so it saves current settings */
> +	regcache_cache_bypass(da7218->regmap, true);

What ensures that nothing else is running at the same time this is?  

> +static int da7218_mic_lvl_det_sw_put(struct snd_kcontrol *kcontrol,
> +				     struct snd_ctl_elem_value *ucontrol)
> +{

Why is this a user visible control?

> +	/* Default all mixers off */
> +	snd_soc_write(codec, DA7218_DROUTING_OUTDAI_1L, 0);
> +	snd_soc_write(codec, DA7218_DROUTING_OUTDAI_1R, 0);
> +	snd_soc_write(codec, DA7218_DROUTING_OUTDAI_2L, 0);
> +	snd_soc_write(codec, DA7218_DROUTING_OUTDAI_2R, 0);
> +	snd_soc_write(codec, DA7218_DROUTING_OUTFILT_1L, 0);
> +	snd_soc_write(codec, DA7218_DROUTING_OUTFILT_1R, 0);
> +	snd_soc_write(codec, DA7218_DROUTING_ST_OUTFILT_1L, 0);
> +	snd_soc_write(codec, DA7218_DROUTING_ST_OUTFILT_1R, 0);

We generally just use the device defaults, why change them?

[toc] | [prev] | [next] | [standalone]


#1263920 — RE: [PATCH 2/2] ASoC: codecs: Add da7218 codec driver

From"Opensource [Adam Thomson]" <Adam.Thomson.Opensource@diasemi.com>
Date2015-11-06 12:20 +0100
SubjectRE: [PATCH 2/2] ASoC: codecs: Add da7218 codec driver
Message-ID<qrNdM-3Ni-17@gated-at.bofh.it>
In reply to#1263327
T24gTm92ZW1iZXIgNSwgMjAxNSAxNToyOCwgTWFyayBCcm93biB3cm90ZToNCg0KPiA+ICsvKiBB
TEMgKi8NCj4gPiArc3RhdGljIHZvaWQgZGE3MjE4X2FsY19jYWxpYihzdHJ1Y3Qgc25kX3NvY19j
b2RlYyAqY29kZWMpDQo+ID4gK3sNCj4gPiArCXN0cnVjdCBkYTcyMThfcHJpdiAqZGE3MjE4ID0g
c25kX3NvY19jb2RlY19nZXRfZHJ2ZGF0YShjb2RlYyk7DQo+ID4gKwl1OCBjYWxpYl9jdHJsOw0K
PiA+ICsJaW50IGkgPSAwOw0KPiA+ICsJYm9vbCBjYWxpYnJhdGVkID0gZmFsc2U7DQo+ID4gKw0K
PiA+ICsJLyogQnlwYXNzIGNhY2hlIHNvIGl0IHNhdmVzIGN1cnJlbnQgc2V0dGluZ3MgKi8NCj4g
PiArCXJlZ2NhY2hlX2NhY2hlX2J5cGFzcyhkYTcyMTgtPnJlZ21hcCwgdHJ1ZSk7DQo+IA0KPiBX
aGF0IGVuc3VyZXMgdGhhdCBub3RoaW5nIGVsc2UgaXMgcnVubmluZyBhdCB0aGUgc2FtZSB0aW1l
IHRoaXMgaXM/DQoNCklzIGEgZmFpciBwb2ludC4gT3JpZ2luYWxseSBJIHdhcyBzYXZpbmcgdGhl
IHN0YXRlIG9mIHJlZ2lzdGVycyB0aGVuDQpyZS1pbnN0YXRpbmcgdGhlbSBhdCB0aGUgZW5kLCB3
aGljaCB3b3JrZWQgZmluZSwgYnV0IHRoZW4gd2FzIHRyeWluZyB0byBiZQ0KY2xldmVyIGFuZCB0
aWR5IHRoaW5ncyB1cCBieSBieXBhc3NpbmcgdGhlIGNhY2hlIGluc3RlYWQuIFdpbGwgcmV2ZXJ0
IGJhY2sgdG8NCnRoZSBwcmV2aW91cyBtZXRob2QuDQoNCj4gDQo+ID4gK3N0YXRpYyBpbnQgZGE3
MjE4X21pY19sdmxfZGV0X3N3X3B1dChzdHJ1Y3Qgc25kX2tjb250cm9sICprY29udHJvbCwNCj4g
PiArCQkJCSAgICAgc3RydWN0IHNuZF9jdGxfZWxlbV92YWx1ZSAqdWNvbnRyb2wpDQo+ID4gK3sN
Cj4gDQo+IFdoeSBpcyB0aGlzIGEgdXNlciB2aXNpYmxlIGNvbnRyb2w/DQoNCkkgY2FuIGVudmlz
YWdlIGluIGEgc3lzdGVtIHlvdSBtYXkgd2FudCB0byBjaG9vc2Ugd2hpY2ggY2FwdHVyZSBjaGFu
bmVscyBjYW4NCnRyaWdnZXIgbGV2ZWwgZGV0ZWN0aW9uIChpZiBhbnkpLCBhbmQgdGhpcyBtYXkg
Y2hhbmdlIGRlcGVuZGluZyBvbiB0aGUgdXNlLWNhc2UNCmF0IHRoZSB0aW1lLCBzbyBoYXZpbmcg
aXQgYXMgYSBjb250cm9sIG1ha2VzIHNlbnNlIHRvIG1lLg0KDQo+IA0KPiA+ICsJLyogRGVmYXVs
dCBhbGwgbWl4ZXJzIG9mZiAqLw0KPiA+ICsJc25kX3NvY193cml0ZShjb2RlYywgREE3MjE4X0RS
T1VUSU5HX09VVERBSV8xTCwgMCk7DQo+ID4gKwlzbmRfc29jX3dyaXRlKGNvZGVjLCBEQTcyMThf
RFJPVVRJTkdfT1VUREFJXzFSLCAwKTsNCj4gPiArCXNuZF9zb2Nfd3JpdGUoY29kZWMsIERBNzIx
OF9EUk9VVElOR19PVVREQUlfMkwsIDApOw0KPiA+ICsJc25kX3NvY193cml0ZShjb2RlYywgREE3
MjE4X0RST1VUSU5HX09VVERBSV8yUiwgMCk7DQo+ID4gKwlzbmRfc29jX3dyaXRlKGNvZGVjLCBE
QTcyMThfRFJPVVRJTkdfT1VURklMVF8xTCwgMCk7DQo+ID4gKwlzbmRfc29jX3dyaXRlKGNvZGVj
LCBEQTcyMThfRFJPVVRJTkdfT1VURklMVF8xUiwgMCk7DQo+ID4gKwlzbmRfc29jX3dyaXRlKGNv
ZGVjLCBEQTcyMThfRFJPVVRJTkdfU1RfT1VURklMVF8xTCwgMCk7DQo+ID4gKwlzbmRfc29jX3dy
aXRlKGNvZGVjLCBEQTcyMThfRFJPVVRJTkdfU1RfT1VURklMVF8xUiwgMCk7DQo+IA0KPiBXZSBn
ZW5lcmFsbHkganVzdCB1c2UgdGhlIGRldmljZSBkZWZhdWx0cywgd2h5IGNoYW5nZSB0aGVtPw0K
DQpJIGZpZ3VyZWQgaXQgbWFkZSBtb3JlIHNlbnNlIHRvIGhhdmUgdGhlIGRldmljZSBzdGFydCB3
aXRoIGF1ZGlvIHJvdXRlcyBkaXNhYmxlZA0KYnV0IEkgY2FuIHJlbW92ZSB0aGlzIGFzIGl0J3Mg
cmVhbGx5IG5vdCBlc3NlbnRpYWwuDQo=
--
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/

[toc] | [prev] | [next] | [standalone]


#1263921 — Re: [PATCH 2/2] ASoC: codecs: Add da7218 codec driver

FromMark Brown <broonie@kernel.org>
Date2015-11-06 12:30 +0100
SubjectRe: [PATCH 2/2] ASoC: codecs: Add da7218 codec driver
Message-ID<qrNns-3QE-17@gated-at.bofh.it>
In reply to#1263920

[Multipart message — attachments visible in raw view] — view raw

On Fri, Nov 06, 2015 at 11:11:38AM +0000, Opensource [Adam Thomson] wrote:
> On November 5, 2015 15:28, Mark Brown wrote:

> > > +static int da7218_mic_lvl_det_sw_put(struct snd_kcontrol *kcontrol,
> > > +				     struct snd_ctl_elem_value *ucontrol)
> > > +{

> > Why is this a user visible control?

> I can envisage in a system you may want to choose which capture channels can
> trigger level detection (if any), and this may change depending on the use-case
> at the time, so having it as a control makes sense to me.

What is a "capture channel" here?

[toc] | [prev] | [next] | [standalone]


#1263944 — RE: [PATCH 2/2] ASoC: codecs: Add da7218 codec driver

From"Opensource [Adam Thomson]" <Adam.Thomson.Opensource@diasemi.com>
Date2015-11-06 13:00 +0100
SubjectRE: [PATCH 2/2] ASoC: codecs: Add da7218 codec driver
Message-ID<qrNQt-40S-3@gated-at.bofh.it>
In reply to#1263921
T24gTm92ZW1iZXIgNiwgMjAxNSAxMToyMiwgTWFyayBCcm93biB3cm90ZToNCg0KPiA+ID4gPiAr
c3RhdGljIGludCBkYTcyMThfbWljX2x2bF9kZXRfc3dfcHV0KHN0cnVjdCBzbmRfa2NvbnRyb2wg
Kmtjb250cm9sLA0KPiA+ID4gPiArCQkJCSAgICAgc3RydWN0IHNuZF9jdGxfZWxlbV92YWx1ZSAq
dWNvbnRyb2wpDQo+ID4gPiA+ICt7DQo+IA0KPiA+ID4gV2h5IGlzIHRoaXMgYSB1c2VyIHZpc2li
bGUgY29udHJvbD8NCj4gDQo+ID4gSSBjYW4gZW52aXNhZ2UgaW4gYSBzeXN0ZW0geW91IG1heSB3
YW50IHRvIGNob29zZSB3aGljaCBjYXB0dXJlIGNoYW5uZWxzIGNhbg0KPiA+IHRyaWdnZXIgbGV2
ZWwgZGV0ZWN0aW9uIChpZiBhbnkpLCBhbmQgdGhpcyBtYXkgY2hhbmdlIGRlcGVuZGluZyBvbiB0
aGUgdXNlLWNhc2UNCj4gPiBhdCB0aGUgdGltZSwgc28gaGF2aW5nIGl0IGFzIGEgY29udHJvbCBt
YWtlcyBzZW5zZSB0byBtZS4NCj4gDQo+IFdoYXQgaXMgYSAiY2FwdHVyZSBjaGFubmVsIiBoZXJl
Pw0KDQpJbnB1dCBmaWx0ZXJzIDFML1IgYW5kIDJML1IsIHdoaWNoIGFyZSBmZWQgZnJvbSBlaXRo
ZXIgTWljMShBREMxKSBvciBETWljMUwvUg0KYW5kIE1pYzIoQURDMikgb3IgRE1pYzJML1IuDQo=
--
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/

[toc] | [prev] | [next] | [standalone]


#1263946 — Re: [PATCH 2/2] ASoC: codecs: Add da7218 codec driver

FromMark Brown <broonie@kernel.org>
Date2015-11-06 13:00 +0100
SubjectRe: [PATCH 2/2] ASoC: codecs: Add da7218 codec driver
Message-ID<qrNQt-40S-11@gated-at.bofh.it>
In reply to#1263944

[Multipart message — attachments visible in raw view] — view raw

On Fri, Nov 06, 2015 at 11:53:00AM +0000, Opensource [Adam Thomson] wrote:
> On November 6, 2015 11:22, Mark Brown wrote:

> > > I can envisage in a system you may want to choose which capture channels can
> > > trigger level detection (if any), and this may change depending on the use-case
> > > at the time, so having it as a control makes sense to me.

> > What is a "capture channel" here?

> Input filters 1L/R and 2L/R, which are fed from either Mic1(ADC1) or DMic1L/R
> and Mic2(ADC2) or DMic2L/R.

Hang on, is this just recording a DC value with the ADC and then looking
at that?

[toc] | [prev] | [next] | [standalone]


#1264006 — RE: [PATCH 2/2] ASoC: codecs: Add da7218 codec driver

From"Opensource [Adam Thomson]" <Adam.Thomson.Opensource@diasemi.com>
Date2015-11-06 14:20 +0100
SubjectRE: [PATCH 2/2] ASoC: codecs: Add da7218 codec driver
Message-ID<qrP5U-4Zf-21@gated-at.bofh.it>
In reply to#1263946
T24gTm92ZW1iZXIgNiwgMjAxNSAxMTo1NSwgTWFyayBCcm93biB3cm90ZToNCg0KPiA+ID4gPiBJ
IGNhbiBlbnZpc2FnZSBpbiBhIHN5c3RlbSB5b3UgbWF5IHdhbnQgdG8gY2hvb3NlIHdoaWNoIGNh
cHR1cmUgY2hhbm5lbHMgY2FuDQo+ID4gPiA+IHRyaWdnZXIgbGV2ZWwgZGV0ZWN0aW9uIChpZiBh
bnkpLCBhbmQgdGhpcyBtYXkgY2hhbmdlIGRlcGVuZGluZyBvbiB0aGUgdXNlLWNhc2UNCj4gPiA+
ID4gYXQgdGhlIHRpbWUsIHNvIGhhdmluZyBpdCBhcyBhIGNvbnRyb2wgbWFrZXMgc2Vuc2UgdG8g
bWUuDQo+IA0KPiA+ID4gV2hhdCBpcyBhICJjYXB0dXJlIGNoYW5uZWwiIGhlcmU/DQo+IA0KPiA+
IElucHV0IGZpbHRlcnMgMUwvUiBhbmQgMkwvUiwgd2hpY2ggYXJlIGZlZCBmcm9tIGVpdGhlciBN
aWMxKEFEQzEpIG9yIERNaWMxTC9SDQo+ID4gYW5kIE1pYzIoQURDMikgb3IgRE1pYzJML1IuDQo+
IA0KPiBIYW5nIG9uLCBpcyB0aGlzIGp1c3QgcmVjb3JkaW5nIGEgREMgdmFsdWUgd2l0aCB0aGUg
QURDIGFuZCB0aGVuIGxvb2tpbmcNCj4gYXQgdGhhdD8NCg0KVGhlIFJNUyBvZiB0aGUgTWljIHNp
Z25hbCBpcyB0YWtlbiBhbmQgY29tcGFyZWQgdG8gdGhlIHRyaWdnZXIgbGV2ZWwgc2V0LiBJZg0K
aXQncyBhYm92ZSB0aGF0IGxldmVsIHRoZW4gYW4gSVJRIGlzIHJhaXNlZC4NCg==
--
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/

[toc] | [prev] | [next] | [standalone]


#1265071 — Re: [PATCH 2/2] ASoC: codecs: Add da7218 codec driver

FromMark Brown <broonie@kernel.org>
Date2015-11-08 11:40 +0100
SubjectRe: [PATCH 2/2] ASoC: codecs: Add da7218 codec driver
Message-ID<qsvya-7nD-17@gated-at.bofh.it>
In reply to#1264006

[Multipart message — attachments visible in raw view] — view raw

On Fri, Nov 06, 2015 at 01:17:28PM +0000, Opensource [Adam Thomson] wrote:
> On November 6, 2015 11:55, Mark Brown wrote:

> > Hang on, is this just recording a DC value with the ADC and then looking
> > at that?

> The RMS of the Mic signal is taken and compared to the trigger level set. If
> it's above that level then an IRQ is raised.

What I'm trying to figure out here is if this depends on the audio
routing at runtime or if it's got dedicated configuration?

[toc] | [prev] | [next] | [standalone]


#1265615 — RE: [PATCH 2/2] ASoC: codecs: Add da7218 codec driver

From"Opensource [Adam Thomson]" <Adam.Thomson.Opensource@diasemi.com>
Date2015-11-09 13:30 +0100
SubjectRE: [PATCH 2/2] ASoC: codecs: Add da7218 codec driver
Message-ID<qsTKa-6ln-13@gated-at.bofh.it>
In reply to#1265071
T24gTm92ZW1iZXIgOCwgMjAxNSAxMDozNCwgTWFyayBCcm93biB3cm90ZToNCg0KPiA+ID4gSGFu
ZyBvbiwgaXMgdGhpcyBqdXN0IHJlY29yZGluZyBhIERDIHZhbHVlIHdpdGggdGhlIEFEQyBhbmQg
dGhlbiBsb29raW5nDQo+ID4gPiBhdCB0aGF0Pw0KPiANCj4gPiBUaGUgUk1TIG9mIHRoZSBNaWMg
c2lnbmFsIGlzIHRha2VuIGFuZCBjb21wYXJlZCB0byB0aGUgdHJpZ2dlciBsZXZlbCBzZXQuIElm
DQo+ID4gaXQncyBhYm92ZSB0aGF0IGxldmVsIHRoZW4gYW4gSVJRIGlzIHJhaXNlZC4NCj4gDQo+
IFdoYXQgSSdtIHRyeWluZyB0byBmaWd1cmUgb3V0IGhlcmUgaXMgaWYgdGhpcyBkZXBlbmRzIG9u
IHRoZSBhdWRpbw0KPiByb3V0aW5nIGF0IHJ1bnRpbWUgb3IgaWYgaXQncyBnb3QgZGVkaWNhdGVk
IGNvbmZpZ3VyYXRpb24/DQoNClRoaXMgZmVhdHVyZSBpcyBhdmFpbGFibGUgZm9yIGFueS9hbGwg
bWljcyBjb25uZWN0ZWQuIFdoaWNoIG1pY3MgYXJlIGVuYWJsZWQNCmlzIGEgcnVudGltZSBjb25m
aWd1cmF0aW9uIG9mIHJvdXRpbmcsIHNvIHRvIG1lIGl0IG1ha2VzIHNlbnNlIGFsc28gdGhhdCB3
ZSBjYW4NCmNvbmZpZ3VyZSB3aGljaCBjaGFubmVsIHRyaWdnZXJzIGFuIGV2ZW50LCBiYXNlZCBv
biBvdXIgc2NlbmFyaW8gYXQgdGhhdCB0aW1lLg0K
--
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/

[toc] | [prev] | [next] | [standalone]


#1265693 — Re: [PATCH 2/2] ASoC: codecs: Add da7218 codec driver

FromMark Brown <broonie@kernel.org>
Date2015-11-09 15:10 +0100
SubjectRe: [PATCH 2/2] ASoC: codecs: Add da7218 codec driver
Message-ID<qsViV-7qm-11@gated-at.bofh.it>
In reply to#1265615

[Multipart message — attachments visible in raw view] — view raw

On Mon, Nov 09, 2015 at 12:28:39PM +0000, Opensource [Adam Thomson] wrote:
> On November 8, 2015 10:34, Mark Brown wrote:

> > What I'm trying to figure out here is if this depends on the audio
> > routing at runtime or if it's got dedicated configuration?

> This feature is available for any/all mics connected. Which mics are enabled
> is a runtime configuration of routing, so to me it makes sense also that we can
> configure which channel triggers an event, based on our scenario at that time.

The general userspace expectation is that the detection is always active
and consistent rather than varying at runtime - runtime variability
might be a bit surprising for it, and even then variability in what is
detected based on other settings is a bit surprising.  If the hardware
is that limited I guess it's about all that can be done but I'm still
not clear what the use cases are for configuring the levels (as opposed
ot the routing).

[toc] | [prev] | [next] | [standalone]


#1266517 — RE: [PATCH 2/2] ASoC: codecs: Add da7218 codec driver

From"Opensource [Adam Thomson]" <Adam.Thomson.Opensource@diasemi.com>
Date2015-11-10 15:00 +0100
SubjectRE: [PATCH 2/2] ASoC: codecs: Add da7218 codec driver
Message-ID<qthCO-5MA-17@gated-at.bofh.it>
In reply to#1265693
T24gTm92ZW1iZXIgOSwgMjAxNSAxNDowMiwgTWFyayBCcm93biB3cm90ZToNCg0KPiA+ID4gV2hh
dCBJJ20gdHJ5aW5nIHRvIGZpZ3VyZSBvdXQgaGVyZSBpcyBpZiB0aGlzIGRlcGVuZHMgb24gdGhl
IGF1ZGlvDQo+ID4gPiByb3V0aW5nIGF0IHJ1bnRpbWUgb3IgaWYgaXQncyBnb3QgZGVkaWNhdGVk
IGNvbmZpZ3VyYXRpb24/DQo+IA0KPiA+IFRoaXMgZmVhdHVyZSBpcyBhdmFpbGFibGUgZm9yIGFu
eS9hbGwgbWljcyBjb25uZWN0ZWQuIFdoaWNoIG1pY3MgYXJlIGVuYWJsZWQNCj4gPiBpcyBhIHJ1
bnRpbWUgY29uZmlndXJhdGlvbiBvZiByb3V0aW5nLCBzbyB0byBtZSBpdCBtYWtlcyBzZW5zZSBh
bHNvIHRoYXQgd2UgY2FuDQo+ID4gY29uZmlndXJlIHdoaWNoIGNoYW5uZWwgdHJpZ2dlcnMgYW4g
ZXZlbnQsIGJhc2VkIG9uIG91ciBzY2VuYXJpbyBhdCB0aGF0IHRpbWUuDQo+IA0KPiBUaGUgZ2Vu
ZXJhbCB1c2Vyc3BhY2UgZXhwZWN0YXRpb24gaXMgdGhhdCB0aGUgZGV0ZWN0aW9uIGlzIGFsd2F5
cyBhY3RpdmUNCj4gYW5kIGNvbnNpc3RlbnQgcmF0aGVyIHRoYW4gdmFyeWluZyBhdCBydW50aW1l
IC0gcnVudGltZSB2YXJpYWJpbGl0eQ0KPiBtaWdodCBiZSBhIGJpdCBzdXJwcmlzaW5nIGZvciBp
dCwgYW5kIGV2ZW4gdGhlbiB2YXJpYWJpbGl0eSBpbiB3aGF0IGlzDQo+IGRldGVjdGVkIGJhc2Vk
IG9uIG90aGVyIHNldHRpbmdzIGlzIGEgYml0IHN1cnByaXNpbmcuICBJZiB0aGUgaGFyZHdhcmUN
Cj4gaXMgdGhhdCBsaW1pdGVkIEkgZ3Vlc3MgaXQncyBhYm91dCBhbGwgdGhhdCBjYW4gYmUgZG9u
ZSBidXQgSSdtIHN0aWxsDQo+IG5vdCBjbGVhciB3aGF0IHRoZSB1c2UgY2FzZXMgYXJlIGZvciBj
b25maWd1cmluZyB0aGUgbGV2ZWxzIChhcyBvcHBvc2VkDQo+IG90IHRoZSByb3V0aW5nKS4NCg0K
SG93IGFib3V0IHRoZSBleGFtcGxlIG9mIGFsd2F5cyBvbiB2b2ljZSBpbiBBbmRyb2lkLCB3aGlj
aCBjYW4gYmUgZW5hYmxlZCBhbmQNCmRpc2FibGVkLCBkZXBlbmRpbmcgb24gdXNlciBzZXR0aW5n
cywgYW5kIHJvdXRpbmcgd2lsbCB2YXJ5IGRlcGVuZGluZyBvbiB3aGljaA0KbWljIGlzIGluIHVz
ZSBhdCB0aGUgdGltZT8gRm9yIHRoZSBsZXZlbGxpbmcgaXMgaXQgbm90IHBsYXVzaWJsZSB0aGF0
IGEgdXNlcg0KY291bGQgY29uZmlndXJlIHRoZSBsZXZlbCBiYXNlZCBvbiB0aGVpciBjdXJyZW50
IGVudmlyb25tZW50LiBZb3UgaGF2ZQ0KbW9kZXJhdGVseSBsb3VkIGJhY2tncm91bmQgbm9pc2Us
IHRoZW4geW91ciB0aHJlc2hvbGQgd291bGQgd2FudCB0byBiZQ0KaGlnaGVyLCBidXQgaW4gYSBx
dWlldCBlbnZpcm9ubWVudCB0aGUgbGlrZWxpaG9vZCBpcyB5b3Ugd291bGQgd2FudCB0byBsb3dl
cg0KdGhhdCB0aHJlc2hvbGQ/DQo=
--
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/

[toc] | [prev] | [next] | [standalone]


#1266532 — Re: [PATCH 2/2] ASoC: codecs: Add da7218 codec driver

FromMark Brown <broonie@kernel.org>
Date2015-11-10 15:20 +0100
SubjectRe: [PATCH 2/2] ASoC: codecs: Add da7218 codec driver
Message-ID<qthWb-68s-27@gated-at.bofh.it>
In reply to#1266517

[Multipart message — attachments visible in raw view] — view raw

On Tue, Nov 10, 2015 at 01:55:30PM +0000, Opensource [Adam Thomson] wrote:
> On November 9, 2015 14:02, Mark Brown wrote:

> > The general userspace expectation is that the detection is always active
> > and consistent rather than varying at runtime - runtime variability
> > might be a bit surprising for it, and even then variability in what is
> > detected based on other settings is a bit surprising.  If the hardware
> > is that limited I guess it's about all that can be done but I'm still
> > not clear what the use cases are for configuring the levels (as opposed
> > ot the routing).

> How about the example of always on voice in Android, which can be enabled and
> disabled, depending on user settings, and routing will vary depending on which
> mic is in use at the time? For the levelling is it not plausible that a user
> could configure the level based on their current environment. You have
> moderately loud background noise, then your threshold would want to be
> higher, but in a quiet environment the likelihood is you would want to lower
> that threshold?

So this *isn't* a normal mic detection feature?  What's the userspace
interface for reporting then?

[toc] | [prev] | [next] | [standalone]


#1266536 — RE: [PATCH 2/2] ASoC: codecs: Add da7218 codec driver

From"Opensource [Adam Thomson]" <Adam.Thomson.Opensource@diasemi.com>
Date2015-11-10 15:30 +0100
SubjectRE: [PATCH 2/2] ASoC: codecs: Add da7218 codec driver
Message-ID<qti5Q-6bC-7@gated-at.bofh.it>
In reply to#1266532
T24gTm92ZW1iZXIgMTAsIDIwMTUgMTQ6MTUsIE1hcmsgQnJvd24gd3JvdGU6DQoNCj4gPiA+IFRo
ZSBnZW5lcmFsIHVzZXJzcGFjZSBleHBlY3RhdGlvbiBpcyB0aGF0IHRoZSBkZXRlY3Rpb24gaXMg
YWx3YXlzIGFjdGl2ZQ0KPiA+ID4gYW5kIGNvbnNpc3RlbnQgcmF0aGVyIHRoYW4gdmFyeWluZyBh
dCBydW50aW1lIC0gcnVudGltZSB2YXJpYWJpbGl0eQ0KPiA+ID4gbWlnaHQgYmUgYSBiaXQgc3Vy
cHJpc2luZyBmb3IgaXQsIGFuZCBldmVuIHRoZW4gdmFyaWFiaWxpdHkgaW4gd2hhdCBpcw0KPiA+
ID4gZGV0ZWN0ZWQgYmFzZWQgb24gb3RoZXIgc2V0dGluZ3MgaXMgYSBiaXQgc3VycHJpc2luZy4g
IElmIHRoZSBoYXJkd2FyZQ0KPiA+ID4gaXMgdGhhdCBsaW1pdGVkIEkgZ3Vlc3MgaXQncyBhYm91
dCBhbGwgdGhhdCBjYW4gYmUgZG9uZSBidXQgSSdtIHN0aWxsDQo+ID4gPiBub3QgY2xlYXIgd2hh
dCB0aGUgdXNlIGNhc2VzIGFyZSBmb3IgY29uZmlndXJpbmcgdGhlIGxldmVscyAoYXMgb3Bwb3Nl
ZA0KPiA+ID4gb3QgdGhlIHJvdXRpbmcpLg0KPiANCj4gPiBIb3cgYWJvdXQgdGhlIGV4YW1wbGUg
b2YgYWx3YXlzIG9uIHZvaWNlIGluIEFuZHJvaWQsIHdoaWNoIGNhbiBiZSBlbmFibGVkIGFuZA0K
PiA+IGRpc2FibGVkLCBkZXBlbmRpbmcgb24gdXNlciBzZXR0aW5ncywgYW5kIHJvdXRpbmcgd2ls
bCB2YXJ5IGRlcGVuZGluZyBvbiB3aGljaA0KPiA+IG1pYyBpcyBpbiB1c2UgYXQgdGhlIHRpbWU/
IEZvciB0aGUgbGV2ZWxsaW5nIGlzIGl0IG5vdCBwbGF1c2libGUgdGhhdCBhIHVzZXINCj4gPiBj
b3VsZCBjb25maWd1cmUgdGhlIGxldmVsIGJhc2VkIG9uIHRoZWlyIGN1cnJlbnQgZW52aXJvbm1l
bnQuIFlvdSBoYXZlDQo+ID4gbW9kZXJhdGVseSBsb3VkIGJhY2tncm91bmQgbm9pc2UsIHRoZW4g
eW91ciB0aHJlc2hvbGQgd291bGQgd2FudCB0byBiZQ0KPiA+IGhpZ2hlciwgYnV0IGluIGEgcXVp
ZXQgZW52aXJvbm1lbnQgdGhlIGxpa2VsaWhvb2QgaXMgeW91IHdvdWxkIHdhbnQgdG8gbG93ZXIN
Cj4gPiB0aGF0IHRocmVzaG9sZD8NCj4gDQo+IFNvIHRoaXMgKmlzbid0KiBhIG5vcm1hbCBtaWMg
ZGV0ZWN0aW9uIGZlYXR1cmU/ICBXaGF0J3MgdGhlIHVzZXJzcGFjZQ0KPiBpbnRlcmZhY2UgZm9y
IHJlcG9ydGluZyB0aGVuPw0KDQpCeSBtaWMgZGV0ZWN0aW9uIHlvdSB0aG91Z2h0IHRoaXMgd2Fz
IHRvIGRldGVjdCBpZiBhIG1pYyB3YXMgcHJlc2VudCBvciBub3Q/DQpJdCdzIHRvIGRldGVjdCB0
aGUgbm9pc2UgbGV2ZWwgb24gYSBtaWMgYW5kIHJhaXNlIGFuIGV2ZW50IGlmIHRoZSBjYXB0dXJl
ZA0Kc291bmQgaXMgYWJvdmUgYSBzcGVjaWZpYyB0aHJlc2hvbGQgbGV2ZWwuIEFwb2xvZ2llcyBp
ZiB0aGF0IHdhc24ndCBjbGVhci4NCg0KSW4gdGhlIGRyaXZlciBjb2RlIEknbSB1c2luZyBLRVlf
Vk9JQ0VDT01NQU5ELCBhbmQgc2ltdWxhdGluZyBhIHByZXNzIGFuZA0KcmVsZWFzZSBvZiB0aGlz
IGtleSwgdG8gaW5kaWNhdGUgdG8gdXNlci1zcGFjZS4gVGhpcyBzZWVtZWQgbGlrZSB0aGUgb2J2
aW91cw0KY2hvaWNlIGZvciB0aGlzIGZlYXR1cmUgdG8gbWUsIGFsdGhvdWdoIEknZCBoYXBwaWx5
IGdldCB5b3VyIG9waW5pb24gb24gdGhpcy4NCg==
--
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/

[toc] | [prev] | [next] | [standalone]


#1266586 — Re: [PATCH 2/2] ASoC: codecs: Add da7218 codec driver

FromMark Brown <broonie@kernel.org>
Date2015-11-10 16:50 +0100
SubjectRe: [PATCH 2/2] ASoC: codecs: Add da7218 codec driver
Message-ID<qtjlg-6UG-27@gated-at.bofh.it>
In reply to#1266536

[Multipart message — attachments visible in raw view] — view raw

On Tue, Nov 10, 2015 at 02:24:13PM +0000, Opensource [Adam Thomson] wrote:
> On November 10, 2015 14:15, Mark Brown wrote:

> > So this *isn't* a normal mic detection feature?  What's the userspace
> > interface for reporting then?

> By mic detection you thought this was to detect if a mic was present or not?

That and button detection.

> It's to detect the noise level on a mic and raise an event if the captured
> sound is above a specific threshold level. Apologies if that wasn't clear.

> In the driver code I'm using KEY_VOICECOMMAND, and simulating a press and
> release of this key, to indicate to user-space. This seemed like the obvious
> choice for this feature to me, although I'd happily get your opinion on this.

That seems like a particularly unfortunate choice given that
VOICECOMMAND is used in the standard Google headset mapping (see
ts3a227e for an example, that's a device specifically aimed at providing
accessory detection in Chromebooks).  There's also been some pushback
against using the input devices due to the difficulty in enabling apps
to access input devices - ALSA controls were preferred instead but
that's less helpful for tinyalsa.  Perhaps that can be added relatively
easily, or a uevent or something.

Not sure what the best way forward here is, the other implementations of
this that I'm aware of do more of the detection in offload and present
streams of detected audio to userspace via normal capture.

I would at least suggest moving this into a separate patch and doing
the integration separately.

[toc] | [prev] | [next] | [standalone]


#1266625 — RE: [PATCH 2/2] ASoC: codecs: Add da7218 codec driver

From"Opensource [Adam Thomson]" <Adam.Thomson.Opensource@diasemi.com>
Date2015-11-10 17:30 +0100
SubjectRE: [PATCH 2/2] ASoC: codecs: Add da7218 codec driver
Message-ID<qtjXY-7nY-5@gated-at.bofh.it>
In reply to#1266586
T24gTm92ZW1iZXIgMTAsIDIwMTUgMTU6NDUsIE1hcmsgQnJvd24gd3JvdGU6DQoNCj4gPiBJdCdz
IHRvIGRldGVjdCB0aGUgbm9pc2UgbGV2ZWwgb24gYSBtaWMgYW5kIHJhaXNlIGFuIGV2ZW50IGlm
IHRoZSBjYXB0dXJlZA0KPiA+IHNvdW5kIGlzIGFib3ZlIGEgc3BlY2lmaWMgdGhyZXNob2xkIGxl
dmVsLiBBcG9sb2dpZXMgaWYgdGhhdCB3YXNuJ3QgY2xlYXIuDQo+IA0KPiA+IEluIHRoZSBkcml2
ZXIgY29kZSBJJ20gdXNpbmcgS0VZX1ZPSUNFQ09NTUFORCwgYW5kIHNpbXVsYXRpbmcgYSBwcmVz
cyBhbmQNCj4gPiByZWxlYXNlIG9mIHRoaXMga2V5LCB0byBpbmRpY2F0ZSB0byB1c2VyLXNwYWNl
LiBUaGlzIHNlZW1lZCBsaWtlIHRoZSBvYnZpb3VzDQo+ID4gY2hvaWNlIGZvciB0aGlzIGZlYXR1
cmUgdG8gbWUsIGFsdGhvdWdoIEknZCBoYXBwaWx5IGdldCB5b3VyIG9waW5pb24gb24gdGhpcy4N
Cj4gDQo+IFRoYXQgc2VlbXMgbGlrZSBhIHBhcnRpY3VsYXJseSB1bmZvcnR1bmF0ZSBjaG9pY2Ug
Z2l2ZW4gdGhhdA0KPiBWT0lDRUNPTU1BTkQgaXMgdXNlZCBpbiB0aGUgc3RhbmRhcmQgR29vZ2xl
IGhlYWRzZXQgbWFwcGluZyAoc2VlDQo+IHRzM2EyMjdlIGZvciBhbiBleGFtcGxlLCB0aGF0J3Mg
YSBkZXZpY2Ugc3BlY2lmaWNhbGx5IGFpbWVkIGF0IHByb3ZpZGluZw0KPiBhY2Nlc3NvcnkgZGV0
ZWN0aW9uIGluIENocm9tZWJvb2tzKS4gIFRoZXJlJ3MgYWxzbyBiZWVuIHNvbWUgcHVzaGJhY2sN
Cj4gYWdhaW5zdCB1c2luZyB0aGUgaW5wdXQgZGV2aWNlcyBkdWUgdG8gdGhlIGRpZmZpY3VsdHkg
aW4gZW5hYmxpbmcgYXBwcw0KPiB0byBhY2Nlc3MgaW5wdXQgZGV2aWNlcyAtIEFMU0EgY29udHJv
bHMgd2VyZSBwcmVmZXJyZWQgaW5zdGVhZCBidXQNCj4gdGhhdCdzIGxlc3MgaGVscGZ1bCBmb3Ig
dGlueWFsc2EuICBQZXJoYXBzIHRoYXQgY2FuIGJlIGFkZGVkIHJlbGF0aXZlbHkNCj4gZWFzaWx5
LCBvciBhIHVldmVudCBvciBzb21ldGhpbmcuDQo+IA0KDQpJIGNob3NlIFZPSUNFQ09NTUFORCBh
cyBJIHRob3VnaHQgdGhpcyBraW5kIG9mIGZlYXR1cmUgbWlnaHQgb2ZmZXIgdGhlIHNhbWUga2lu
ZA0Kb2YgdXNlIGFzIHRoZSBwaHlzaWNhbCBidXR0b24sIGJ1dCBpZiB0aGlzIG9ubHkgZm9yIEdv
b2dsZSBoZWFkc2V0IHVzZSB0aGVuIGZhaXINCmVub3VnaC4gDQoNCj4gTm90IHN1cmUgd2hhdCB0
aGUgYmVzdCB3YXkgZm9yd2FyZCBoZXJlIGlzLCB0aGUgb3RoZXIgaW1wbGVtZW50YXRpb25zIG9m
DQo+IHRoaXMgdGhhdCBJJ20gYXdhcmUgb2YgZG8gbW9yZSBvZiB0aGUgZGV0ZWN0aW9uIGluIG9m
ZmxvYWQgYW5kIHByZXNlbnQNCj4gc3RyZWFtcyBvZiBkZXRlY3RlZCBhdWRpbyB0byB1c2Vyc3Bh
Y2UgdmlhIG5vcm1hbCBjYXB0dXJlLg0KPiANCg0KWWVzLCB0aGlzIGlzIGZhciBtb3JlIHNpbXBs
aXN0aWMsIGFuZCBhbnkgdm9pY2UgcHJvY2Vzc2luZyBvciBjYXB0dXJlIGlzIG5vdA0KaGFuZGxl
ZCBieSB0aGUgY29kZWMuIEl0IGp1c3QgYW4gaW5kaWNhdGlvbiBvZiBhYm92ZSB0aHJlc2hvbGQg
bm9pc2UgbGV2ZWwgYXQNCnRoZSBtaWMuIEZvciB0aGUgaW1wbGVtZW50YXRpb25zIHlvdSBrbm93
IG9mLCBob3cgYXJlIHRob3NlIGV2ZW50cyBpbmRpY2F0ZWQgdG8NCnVzZXItc3BhY2U/DQoNCj4g
SSB3b3VsZCBhdCBsZWFzdCBzdWdnZXN0IG1vdmluZyB0aGlzIGludG8gYSBzZXBhcmF0ZSBwYXRj
aCBhbmQgZG9pbmcNCj4gdGhlIGludGVncmF0aW9uIHNlcGFyYXRlbHkuDQoNCkFyZSB5b3UgaGFw
cHkgZm9yIG1lIHRvIGxlYXZlIHRoZSBhY3R1YWwgY29udHJvbHMgZm9yIHRoaXMgZmVhdHVyZSBp
biwgd2l0aG91dA0KdGhlIHVzZXItc3BhY2UgcmVwb3J0aW5nIHNpZGU/IE90aGVyd2lzZSBpdCdz
IGEgcGFpbiB0byBzdHJpcCB0aGF0IG91dCwgYW5kIHRoZW4NCnJlLWluc3RhdGUgbGF0ZXIuIFRo
ZSBldmVudCBjYW4gYmUgbWFza2VkIG9mZiB1bnRpbCB0aGUgdXNlci1zcGFjZSByZXBvcnRpbmcN
CmlzIGFkZGVkIGluIGEgc3Vic2VxdWVudCBwYXRjaC4NCg==
--
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/

[toc] | [prev] | [next] | [standalone]


#1266637 — Re: [PATCH 2/2] ASoC: codecs: Add da7218 codec driver

FromMark Brown <broonie@kernel.org>
Date2015-11-10 17:50 +0100
SubjectRe: [PATCH 2/2] ASoC: codecs: Add da7218 codec driver
Message-ID<qtkhl-7vy-39@gated-at.bofh.it>
In reply to#1266625

[Multipart message — attachments visible in raw view] — view raw

On Tue, Nov 10, 2015 at 04:21:04PM +0000, Opensource [Adam Thomson] wrote:
> On November 10, 2015 15:45, Mark Brown wrote:

> > That seems like a particularly unfortunate choice given that
> > VOICECOMMAND is used in the standard Google headset mapping (see
> > ts3a227e for an example, that's a device specifically aimed at providing
> > accessory detection in Chromebooks).  There's also been some pushback
> > against using the input devices due to the difficulty in enabling apps
> > to access input devices - ALSA controls were preferred instead but
> > that's less helpful for tinyalsa.  Perhaps that can be added relatively
> > easily, or a uevent or something.

> I chose VOICECOMMAND as I thought this kind of feature might offer the same kind
> of use as the physical button, but if this only for Google headset use then fair
> enough. 

No, that's a generic button but the point is that the expected workflow
from userspace is going to be different if the user pressed a button to
initiate a voice command compared to if they use an activation phrase.

> > Not sure what the best way forward here is, the other implementations of
> > this that I'm aware of do more of the detection in offload and present
> > streams of detected audio to userspace via normal capture.

> Yes, this is far more simplistic, and any voice processing or capture is not
> handled by the codec. It just an indication of above threshold noise level at
> the mic. For the implementations you know of, how are those events indicated to
> user-space?

I'm not aware of any implementations that just do the activity
detection.  I've seen hardware with it but nobody using it in software.

> > I would at least suggest moving this into a separate patch and doing
> > the integration separately.

> Are you happy for me to leave the actual controls for this feature in, without
> the user-space reporting side? Otherwise it's a pain to strip that out, and then
> re-instate later. The event can be masked off until the user-space reporting
> is added in a subsequent patch.

Possibly, let's see what the code looks like.

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web