[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130516175241.GF1627@sirena.org.uk>
Date: Thu, 16 May 2013 18:52:41 +0100
From: Mark Brown <broonie@...nel.org>
To: Matthew Mowdy <Matthew.Mowdy@...imintegrated.com>
Cc: "abrestic@...omium.org" <abrestic@...omium.org>,
"lgirdwood@...il.com" <lgirdwood@...il.com>,
"perex@...ex.cz" <perex@...ex.cz>, "tiwai@...e.de" <tiwai@...e.de>,
Sachin Kamat <sachin.kamat@...aro.org>,
Kuninori Morimoto <kuninori.morimoto.gx@...esas.com>,
Dylan Reid <dgreid@...omium.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Ralph Birt <Ralph.Birt@...imintegrated.com>,
Evan Ragsdale <Evan.Ragsdale@...imintegrated.com>
Subject: Re: [PATCH] ASoC: max98090: add digital mic mux to record path
On Wed, May 15, 2013 at 09:10:23PM -0700, Matthew Mowdy wrote:
Sorry, didn't manage to find the content I meant to reply to in here due
to the formatting issues I mentioned in my mail and the enormous reams
of datsheet that were pasted in. Anyway....
> Default Routing:
> Of note (software can confirm) I believe the default DAPM routing for the driver was intentional setup such that :
This indicates that the driver is broken, the driver should be using the
chip defaults.
> Record:
> o If a headset MIC is present, record from it.
>
> o If not, digital MIC is the default record input.
This is a bug, the driver should not be making any automatic routing
decisions. The behaviour you describe would break some fairly obvious
use cases like speakerphone while headset is connected.
> Playback:
> o When headphones are detected, playback is through the headphone output.
> o When headphones are not present, playback was through the speaker outputs.
Similarly here, this is junk.
> The defaults can be modified by each end user as needed (for analog
> microphones, line inputs, etc.). Please insure any patch to the
> baseline driver reflects the correct operation of the digital
> microphone enable bits, and preserves the intended default operation.
No, this is stupid and will be buggy. The register default values need
to reflect the silicon defaults, the frameworks (both ASoC and regmap)
do things like suppress writes that have no effect and rely on knowing
the silicon defaults for that.
The framework already allows the application layer to configure the
device through the controls exposed to userspace, if people need to
modify a CODEC driver for their system that reflects a problem in the
CODEC driver.
Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)
Powered by blists - more mailing lists