[alsa-devel] configuring machine specific DAPM for codec + headset jack detect

[Mark Brown]

On Tue, Oct 18, 2016 at 11:16:40AM -0700, Tim Harvey wrote:
> On Tue, Oct 18, 2016 at 4:02 AM, Mark Brown <broonie at kernel.org> wrote:

> > No, you need to write that code if you want it - we do mark not
> > connected things with the intention that someone could implement this
> > but nobody did yet.

> OK - that explains why 'snd_soc_dapm_disable_pin' and
> 'snd_soc_dapm_enable_pin' didn't have any noticeable affect when I was
> calling those from a machine driver. I will plan on having to setup
> all the ALSA controls manually in my OS configuration (Android in this
> use case using tinyalsa_hal).

No, those do useful things with DAPM but not what you're looking for.
For things that are disconnected you want _nc_pin().

> > You can ramp the power down time up but no, there's no way to disable it
> > completely in the kernel - this is normally done in the sound server and
> > tends to work better that way as starting and stopping the digital audio
> > stream tends to be glitchy.

> I haven't found where the power down time is specified/configured -
> can you point me to that?

pmdown_time.

> I'm not quite understanding the DAPM widgets in the driver. These
> registers are configured by:
>         SND_SOC_DAPM_PGA("Left HP Out", HPLOUT_CTRL, 0, 0, NULL, 0),
>         SND_SOC_DAPM_PGA("Right HP Out", HPROUT_CTRL, 0, 0, NULL, 0),

> yet those don't show up in amixer as controls so they are somehow used
> internally.

DAPM widgets are not controls, they're purely internal to the kernel.
The kernel will power up any DAPM widgets that form part of a complete
audio path from input to output or which are forced on.

> Looking at the tlv32aic3105 datasheet
> (http://www.ti.com/lit/ds/symlink/tlv320aic3105.pdf) Register 51
> (0x33) has its mute control in bit3 so I would expect that bit to be
> cleared before and set after applying this stuff. Is there a missing
> SND_SOC_DAPM* in that driver perhaps?

You *can* hook mutes into DAPM with _AUTODISABLE controls but it's
rarely required.

> Incidentally, the board I'm working with has a DC biased headphone. If
> I modify the board to AC bias the headphone the pop goes away, but I'm
> thinking that isn't really the right solution and that there is
> something instead missing from the tlv320aic3x.c driver that should be
> muting/unmuting the outputs around the above register changes.

I'm not sure what you mean by DC and AC bias here, sorry.  Do you mean
VMID referenced vs ground referenced?  If it's that then it sounds like
the driver ought to be biasing the headphones in set_bias_level()
probably based on some DT information, though I'd also say that I can't
think of any reason why you wouldn't want ground referenced outputs so
perhaps I'm missing something.

> Regarding the ts3a227e headset detect/config switch
> (http://www.ti.com/lit/ds/symlink/ts3a227e.pdf), what is the proper
> way to hook that into the Linux input layer via the simple-sound-card
> driver? The ts3a227e_enable_jack_detect function exported from the
> ts3a227e.c driver is only currently called by two machine drivers that
> have explicit support. I suppose if I want to add support for this
> using simple-sound-card I would need to add a custom dt binding to
> that driver?

There was a thread a while back where Dylan Reid proposed a custom jack
binding ("Add a gpio jack device" IIRC) but that ground to a halt.
Right now I'd expect a custom machine driver for something like this
which is obviously not ideal but is going to be a lot easier for you to
implement.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20161018/154110f7/attachment-0001.sig>