linux-kernel - Re: [alsa-devel] [PATCH v5] ASoC: rockchip: Add machine driver for RK3399 GRU Boards

Open Source and information security mailing list archives

Date:	Wed, 15 Jun 2016 19:36:17 -0700
From:	Ben Zhang <benzh@...omium.org>
To:	Mark Brown <broonie@...nel.org>
Cc:	Rob Herring <robh@...nel.org>, Mark Rutland <mark.rutland@....com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Linux-ALSA <alsa-devel@...a-project.org>,
	Xing Zheng <zhengxing@...k-chips.com>,
	Pawel Moll <pawel.moll@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Takashi Iwai <tiwai@...e.com>,
	Doug Anderson <dianders@...omium.org>,
	Liam Girdwood <lgirdwood@...il.com>,
	"open list:ARM/Rockchip SoC..." <linux-rockchip@...ts.infradead.org>,
	Kumar Gala <galak@...eaurora.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Heiko Stübner <heiko@...ech.de>,
	smbarber@...omium.org
Subject: Re: [alsa-devel] [PATCH v5] ASoC: rockchip: Add machine driver for
 RK3399 GRU Boards

On Wed, Jun 15, 2016 at 5:44 AM, Rob Herring <robh@...nel.org> wrote:
> On Wed, Jun 15, 2016 at 4:53 AM, Mark Brown <broonie@...nel.org> wrote:
>> On Tue, Jun 14, 2016 at 05:38:10PM -0500, Rob Herring wrote:
>>> On Mon, Jun 13, 2016 at 04:42:18PM +0800, Xing Zheng wrote:
>>
>>> > +sound {
>>> > +   compatible = "rockchip,rk3399-gru-sound";
>>> > +   rockchip,cpu = <&i2s0>;
>>> > +   rockchip,codec = <&max98357a &rt5514 &da7219>;
>>
>>> These seem fairly standard though a variety of versions in the bindings.
>>> Can we use audio-codec and audio-cpu (or cpu or audio-dai) here? Mark?
>>
>> Well, the roles aren't actually that standard (the fact that there's
>> multiple CODECs and one CPU DAI here is really odd and definitely needs
>> a very system specific interpretation).  If they were standard we
>> already have the simple-card binding that things should be using.
>> There's no point in standard property names if the interpretation has to
>> be non-standard.
>
> Okay, I agree with the system specific interpretation part. However, I
> don't think using simple-card or not determines using common
> properties.
>

Hi Mark, I have a question for the one CPU DAI + multiple CODECs
setup. The machine driver defines 3 DAI links, connecting the same CPU
DAI to 3 different CODEC DAIs. Does ASoC/DAPM support
enabling/disabling an individual DAI link based on the status of the
endpoint widget (e.g. DAPM_SPK) connected to the corresponding CODEC?

The goal is to let user select either headphone(da7219) or
speaker(max98357a) as output. max98357a driver does not expose a
kcontrol for mute. It sets a shutdown GPIO on PCM_TRIGGER_START/STOP.
And it seems soc_pcm_trigger calls the trigger op of all 3 CODEC DAIs,
even when the DAPM_SPK widget is disabled by its pin switch.

>> The vendor specific prefixes are there because all bindings are supposed
>> to add prefixes to property names.
>
> ...unless they are common.
>
> Rob
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@...a-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Thanks,
Ben

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