On Thu, Feb 20, 2020 at 12:04:47PM +0530, Sameer Pujar wrote: > The Audio Hub (AHUB) comprises a collection of hardware accelerators for > audio pre/post-processing and a programmable full crossbar (XBAR) for > routing audio data across these accelerators in time and in parallel. > AHUB supports multiple interfaces to I2S, DSPK, DMIC etc., XBAR is a > switch used to configure or modify audio routing between HW accelerators > present inside AHUB. > > This patch registers AHUB component with ASoC framework. The component > driver exposes DAPM widgets, routes and kcontrols for the device. The DAI > driver exposes AHUB interfaces, which can be used to connect different > components in the ASoC layer. Currently the driver takes care of XBAR > programming to allow audio data flow through various clients of the AHUB. The current way to represent complex digitial routing inside SoCs is to use DPCM, this is not great and causes a bunch of problems with the framework but it's at least consistent between SoCs and is less visible to the ABI than this is. Ideally what we'd be doing is propagating digital configuration along audio paths like we do for analog with DAPM, Morimoto-san has done a lot of the groundwork for doing that with converting everything to components but nobody has worked on that yet. Your stuff looks a lot more like this than it does DPCM at the minute but it completely sidesteps the digital configuration part of things without trying to integrate with the framework which isn't great. I'm really not thrilled about the idea of just hacking around the side of things like this is doing, the ideal thing would be starting the work on the framework to propagate digital configuration - I *think* you can get away with only a subset of the problem here (just copying configuration straight through) since this looks like it's just straight point to point links with little in the way of DSP. If not DPCM would be the way to go I think.
Attachment:
signature.asc
Description: PGP signature
