[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGb2v66jkd7+GMUbihQjA0ec9nDZc=k2yDT3afD1q6qo57PVVA@mail.gmail.com>
Date: Wed, 31 Aug 2016 15:55:46 +0800
From: Chen-Yu Tsai <wens@...e.org>
To: Danny Milosavljevic <dannym@...atchpost.org>
Cc: Chen-Yu Tsai <wens@...e.org>,
Maxime Ripard <maxime.ripard@...e-electrons.com>,
Mark Brown <broonie@...nel.org>,
linux-kernel <linux-kernel@...r.kernel.org>,
linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
Linux-ALSA <alsa-devel@...a-project.org>,
Jaroslav Kysela <perex@...ex.cz>,
Takashi Iwai <tiwai@...e.com>,
Liam Girdwood <lgirdwood@...il.com>,
linux-sunxi <linux-sunxi@...glegroups.com>
Subject: Re: [linux-sunxi] Re: [PATCH v9 2/2] Add mixer controls: Line-In,
FM-In, Mic 2, Capture Source, Differential Line-In.
On Wed, Aug 31, 2016 at 3:49 PM, Danny Milosavljevic
<dannym@...atchpost.org> wrote:
> Hi Chen-Yu,
>
>> My apologies. I didn't notice that VMIC was already in the driver.
>> In that your original patch did everything right.
>
> Don't worry about it :)
>
> But I have a question:
>
> If I replace DAPM_INPUT by DAPM_MIC it wants a callback that is supposed to
> fiddle with the bias.
> Do I provide one?
> If so, will it conflict with the supply?
>
> Or do I leave it as DAPM_INPUT ?
I think leaving it as DAPM_INPUT will do. Also, if you use DAPM_MIC or any
other widget type that takes a callback, the callback can be NULL.
I took a quick look at other drivers. The codecs only use non-endpoint
types, like INPUT/OUTPUT. It's up to the card to provide endpoints
(HP/SPEAKER/LINE/MIC) and route them to the codec INPUT/OUTPUTs.
Regards
ChenYu
Powered by blists - more mailing lists