On 03/10/2016 01:58 PM, Subhransu S. Prusty wrote: > On Thu, Mar 10, 2016 at 02:38:01PM +0530, Arnaud Pouliquen wrote: >> >> >> On 03/10/2016 06:06 AM, Vinod Koul wrote: >>> On Tue, Mar 08, 2016 at 01:53:56PM +0100, Arnaud Pouliquen wrote: >>>> Add helper function to register DAI controls that need to be >>>> linked to pcm device. >>>> A list is handled in case controls are created before dai_link probe >>> >>> Overall this patch looks good to us. But on first read it is not very clear >>> how PCM and DAIs are inter related and why you need to do this. Since we are >>> having similar issues we were able to quickly understand this, the >>> suggestion would be to elborate a bit more in changelog. >> Right, i will provide more details in commit message. >>> >>> Second, why do we need a new API for this. Why not use existing asoc >>> concepts and add one more field in dai_driver for dai_controls. >>> Core can automagically create those controls and link to PCM. >> Yes this was my first approach. Finally, i created a separate API, to be >> able to support iec generic control in DAI ( patch 3/6 and 4/6). >> These patches need possibility to attach private data to control. >> If patches 3/6 and 4/6 are rejected, for sure i will rework it to use >> existing API. >> Today It is more on compromise than an optimized solution... >> But, creating a generic iec control also implies a compatibility with >> ASoC and none ASoC drivers... > > In our view, iec controls should be made generic alsa controls and asoc > should have wrapper over these and create these controls on card enumeration > and use these wrappers. Please, could you details what you have in mind please, because I thought it was exactly what I proposed my patch-set... My approach is that i would like to take into account the creation of generic controls in the way of handling pcm control in ASoC. I tried to treat iec generic control as another PCM control in soc core, not as an exception. Because this could also be reused in future for some other generic pcm controls. > >> >>> >>> Lastly, this doesn't help our usecase of DPCM where the HDMI codec is >>> connected to a BE, so that rtd cannot be used and we need to link to FE, so >>> not sure how we can solve that... >> DPCM seems another story... I'm not fully up to date on DPCM concept, >> but as i can remember no link between FE and BE except DAPM routing. >> Perhaps, for DPCM, a solution should be to use index field for control, >> instead of trying to dynamically link the codec control to PCM device? > > That calls for a discussion on how the controls should be represented for > DPCM. Takashi/Mark/Liam we need your opinion on how the PCM related controls > should be represented in DPCM concepts. > >> >> Thanks >> Arnaud >> _______________________________________________ >> Alsa-devel mailing list >> Alsa-devel@xxxxxxxxxxxxxxxx >> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel > _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
