On Tue, Sep 20, 2016 at 3:15 AM, Maxime Ripard maxime.ripard@free-electrons.com wrote:
Hi,
On Mon, Sep 19, 2016 at 10:56:10PM +0800, Chen-Yu Tsai wrote:
On Mon, Sep 19, 2016 at 7:34 PM, Maxime Ripard maxime.ripard@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.
We're working on the A33, that has yet another setup from the A23..
Looks like the "analog control" bits are similar, if not completely the same. As described on page 221, the bits are accessed through a mapping mechanism in register 0x01f015c0.
So the solution would likely be the same for A31s/A23/A33: a platform device/driver for that particular piece of hardware that registers a custom regmap and an ASoC component. This would be under the PRCM mfd. The main codec would list this (I think it's by name?) under it's aux_components.
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.
Ok. How would that work? Can you setup routes between widgets defined in different components?
Indeed you can. I think that is what the ASoC card is for, to stitch up various components. Not sure if you can directly use widgets from aux components in the codec component driver though. I guess it depends on the probe/binding sequence.
AFAIK the digital parts and analog parts are in different power domains, probably to keep audio bypass working in standby mode.
I don't think we have control over those power domains though, do we?
Technically we can control them from external regulators, though probably just for suspend. The main part of the SoC would be under the SYS domain, while the analog bits, like the R_ block would be under the RTC domain.
There might also be a register controlling them in the PRCM block. I suppose that's out of the scope of this discussion.
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...
I guess some lessons are meant to be learned the hard way :)
Yes. I lost some work on the A31/A31s codec driver. Mainly the A31s parts, and some bits of renaming for the A31. :(
Regards ChenYu