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.