Re: Wolfson 5102 on Beaglebone Black using ALSA

[Charles Keepax <ckeepax@opensource.wolfsonmicro.com>]

On Fri, May 27, 2016 at 06:58:39PM -0700, Clark Dunson wrote:
> We have moved from breadboard to protoboard, and with many
> orders booked, I daresay that we have moved from experimenting
> to committed.  Our application samples mostly channels of
> scientific data, but one of audio.  Ergo we will have an
> ongoing interest in the wm5102 and its DSP capabilities.  The
> more processing that we can do on the codec, the better.
>

There are some hoops to jump through to get access to the
necessary compilers etc. for the DSP, although again Joao who I
CCed on your other email would be a good place to start the
process of getting access to that.

> We are pursuing Master mode at the moment, where the McAsp on
> the BBB supplies 24.576 MHz to wm5102 on MCLK1, and then BCLK
> and WCLK are generated by wm5102.  We sample at 8x48k, and are
> driving AIF1 with dspB format.  Also, we have need to send out
> a calibration signal ~daily, via SPKOUTL.
>

All sounds fine.

> So far we have simply added our stuff at the end of the
> arizona-core.c probe, but would like to do it in a more
> up-streamable way.  In looking at the samsung/bells.c driver
> (thank you again Charles), we realized that anything past basic
> configurations will be difficult with the device tree alone.
> The regmap stuff is a nice form of API, easy to deal with.
>

Yeah please avoid doing this, the driver should support all the
features you require from the sound of things. There should be no
need to hard code register writes.

What sort of things are you setting up with these register
writes? Lets see if I can point you in the direction of the
correct place to put some of those.

> We had to simply disinvite extcon-arizona from the party
> though.  On both the WM5102-6271-CS137-M-SCH-REV2.03 and our
> protoboard, JACKDET is an IRQ gone wild.  On the Wolfson board,
> inserting my headphones into the jack shut it up.  But on our
> protoboard, where we left that pin unconnected, we found that
> the probe of extcon-arizona hard enables JACKDET.
>

I am surprised you are seeing issues on one of our boards, they
are all fairly well tested here. I would quite like to see a
kernel log on that one if I can?

Apart from that, this all seems reasonable, the extcon driver
exists to control the jack detection. If that is not wired up on
your system then not building in this part of the system seems
the correct response.

Thanks,
Charles