linux-kernel - Re: [PATCH v3 7/8] ASoC: wm8998: Initial WM8998 codec driver

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20150506092405.GA17710@opensource.wolfsonmicro.com>
Date:	Wed, 6 May 2015 10:24:05 +0100
From:	Richard Fitzgerald <rf@...nsource.wolfsonmicro.com>
To:	Mark Brown <broonie@...nel.org>
Cc:	lee.jones@...aro.org, linus.walleij@...aro.org, gnurou@...il.com,
	cw00.choi@...sung.com, myungjoo.ham@...sung.com,
	devicetree@...r.kernel.org, alsa-devel@...a-project.org,
	patches@...nsource.wolfsonmicro.com, linux-kernel@...r.kernel.org,
	linux-gpio@...r.kernel.org, ckeepax@...nsource.wolfsonmicro.com
Subject: Re: [PATCH v3 7/8] ASoC: wm8998: Initial WM8998 codec driver

On Tue, May 05, 2015 at 10:59:34PM +0100, Mark Brown wrote:
> On Tue, May 05, 2015 at 02:31:29PM +0100, Richard Fitzgerald wrote:
> 
> > We can't really tell people what the selection does because that depends on
> > the external hardware. The A setting might be a headset mic, or a line in,
> > or a builtin mic...
> 
> > All we can do is say what the selection is called generically by the codec.
> > So take the IN1L signal, on the codec it has two inputs "A" and "B". The
> > IN1L Mux control has two settings "A" and "B". That seems clear.
> 
> So you're saying that you've got a mux on a single physical input which
> has two inputs?  Are you sure that this is actually a mux and not some
> sort of mode setting that should be in platform data or DT - what do
> these settinngs actually correspond to?  The routes in the driver look
> like there's two physical pins for each one of IN1L/R which the device
> can switch between for some reason which does correspond to a mux but
> that'd more normally be named IN1AL or similar.
> 

No, I'm just saying I don't see how calling the mux positions "IN1AL"
is any clearer than calling them "A" and "B". The "IN1AL" names of the
DAPM widgets is purely an internal detail that you wouldn't see through
the ALSA interface anyway so they don't relate any more closely to what
Joe user is seeing in the control list. The IN1L mux is for IN1L
so including that information in the mux position is redundant. For me
the real benefit of the "A"/"B" naming is that if you're reading through
a configuration script and saw something like

    'IN1L Mux' = 'B'
    'IN1R Mux' = 'B'

It's much more readably obvious that both channels are set the same
rather than

    'IN1L Mux' = 'IN1BL'
    'IN1R Mux' = 'IN1BR'

The second version doesn't tell you any more information than the first
but makes it harder to scan so you have to read more carefully to check
the settings


> Though if the left and right side need to be set to the same thing
> (which IIRC a previous version had code to check for and you did mention
> in your mail) all the time then why are there two separate muxes anyway?

They only need to be set the same if the "A" input is set to digital mic
mode because that uses pins from both the left and right channel to
run the single digital interface. If the A input is analogue the two
channels are independant so the left/right muxes can be set to A or B
inputs independantly.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/