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