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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
