[alsa-devel] [PATCH v2 2/6] ASoC: samsung: Add Samsung Low Power Audio Subsystem driver

[Sylwester Nawrocki]

On 07/01/2016 05:07 PM, Mark Brown wrote:
> On Thu, Jun 30, 2016 at 07:16:46PM +0200, Sylwester Nawrocki wrote:
> 
>> > Sorry, I didn't notice this e-mail earlier.  With previous Exynos versions
>> > the LPASS (or AudioSS) was mainly about the embedded audio DSP processor
>> > (at least WRT to SFRs), which was not required for boards supported in 
>> > the mainline kernel. Since e.g. Exynos5433 the LPASS SFR region contains 
>> > also entries related to other IP blocks, like I2S or DMAC.  Even though 
>> > functionality covered by these registers is still rather trivial, like 
>> > SW resets and unmasking interrupts, it's essential for the whole audio 
>> > subsystem operation. The intention was to have in future the LPASS driver 
>> > covering any functionality provided by the embedded audio dedicated MCU.
>> > I'm afraid we have to handle those power sequences in central place to
>> > ensure proper SoC operation. I would also rather avoid adding any exynos 
>> > quirks to the PL330 DMAC driver.
>
> Hrm.  This is sounding a bit like a combination of a power domain and
> an interrupt controller, would something like that fit in perhaps?
> Depends on how many of these trivial bits there are I think...

To me LPASS is somehow similar to the camera subsystem, it's a container/
manager for all the audio related sub-IP blocks.  The LPASS (top) SFR 
region contains bits for resetting sub-blocks like: DMAC, SRAM, TIMER, WDT,
I2S, UART.  It also contains mask and status bits of interrupts from those
IP blocks to the CPU or the embedded MCU (CA5). An (incomplete) list of 
registers can be seen at [1]. There are also entries for software triggered
interrupts to the CPU/MCU, for the MCU reset vector control and general 
purpose register for CPU/MCU communication.

In the SoC there is a dedicated power domain for the whole audio subsystem 
and LPASS also contains a VIC itself. We could try to decompose the LPASS 
top block into various subsystems but I seriously doubt it's a good way
forward. I think LPASS should rather be some top level SoC platform entity.

[1] https://goo.gl/JiYbaZ