[alsa-devel] DAPM over two regmaps (and a mailbox)

[Chen-Yu Tsai]

Hi Maxime,

On Mon, Sep 19, 2016 at 7:34 PM, Maxime Ripard
<maxime.ripard at free-electrons.com> wrote:
> On Mon, Sep 19, 2016 at 12:12:47PM +0100, Mark Brown wrote:
>> On Mon, Sep 19, 2016 at 12:54:19PM +0200, Maxime Ripard wrote:
>>
>> > That codec is mapped in memory, however, we have a bunch of DAPM
>> > widgets that are mapped in a separate register space, that should
>> > probably be exposed through a syscon (but isn't yet).
>>
>> Why not just represent those as a separate device?
>
> I don't know, this seems to be supplies to muxers, mixers, DACs, the
> amplifier (and the amplifier volume too, even though that's not a
> widget), and it looks really intertwinned, how would you separate
> them?

I asked Mark the same question a while ago. I was looking at the A31s
codec, which is kind of a cross between A31 and A23. Mark recommended
using aux devices. AFAIU the codec would just register the DAC and
ADC widgets, the digital volume control, and whatever digital bits
there are. The analog side would be done in a asoc component driver,
which would register all the analog widgets and controls. You then
tie them together at the card level.

AFAIK the digital parts and analog parts are in different power domains,
probably to keep audio bypass working in standby mode.

As for the A31s, I only got as far as implementing the regmap using
custom read/write callbacks, and part of the register definition.
Unfortunately I saved my work with git stash, which I accidentally
wiped out with git reflog expire...

Regards
ChenYu

>> > To make things worse, the register in the syscon behaves as a mailbox,
>> > where you actually have to set in that register the address you want
>> > to modify and the new value, in a single write. This also seem to
>> > deviate from the usual DAPM access pattern.
>>
>> This is totally fine, just use events for the things that aren't simple
>> register updates - there are a large number of examples in the tree,
>> simple register access is totally optional.
>
> Ah, yes, that seems to be just right. Thanks!
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com