[alsa-devel] [RFC 00/11] ASoC: hdac: Add hdac generic driver

[Takashi Iwai]

On Fri, 08 Jul 2016 10:21:39 +0200,
Subhransu S. Prusty wrote:
> 
> On Fri, Jul 08, 2016 at 09:53:05AM +0200, Takashi Iwai wrote:
> > On Fri, 08 Jul 2016 09:33:48 +0200,
> > Subhransu S. Prusty wrote:
> > > 
> > > On Tue, Jun 28, 2016 at 10:43:47AM +0530, Subhransu S. Prusty wrote:
> > > > On Mon, Jun 27, 2016 at 09:05:47AM +0200, Takashi Iwai wrote:
> > > > > On Mon, 27 Jun 2016 05:47:53 +0200,
> > > > > Subhransu S. Prusty wrote:
> > > > > > 
> > > > > > HDA devices generically can be modelled with DAPM in ASoC. This
> > > > > > series adds a framework in ASoC to model HDA devices. HDA widgets
> > > > > > are enumerated and one or multiple DAPM widget(s) are created.
> > > > > > Connection list is queried for each widget to identify the
> > > > > > connection between two endpoints and modelled using DAPM graph.
> > > > > > 
> > > > > > Set of event handlers are defined for each widget type. Based on
> > > > > > DAPM events required verbs are sent to program codec.
> > > > > > 
> > > > > > Finally a function is exported to query for the device endpoint
> > > > > > configuration to create machine controls.
> > > > > 
> > > > > Well...  This is really a hard way to go.  The generic codec support
> > > > > is good, but only if it can cover most of stuff.  That is, you'll have
> > > > > to think of the exceptions from the beginning, because the majority of
> > > > > HD-audio devices are exceptional, i.e. don't follow the standard
> > > > 
> > > > Hi Takashi,
> > > > 
> > > > Thanks for review.
> > > > 
> > > > I think, more detail in the cover letter would have been helpful here. Sorry
> > > > for missing out. Let me explain more.
> > > > 
> > > > Intention here is to create a framework for the HDA devices in ASoC. This
> > > > will follow standard. This will be registered as generic "virtual" class
> > > > device. If there is no match found for vendor id and device id, then the
> > > > class driver will be loaded. For vendor specific devices, a match function
> > > > will be provided. With the help of this, the vendor quirks will be
> > > > registered. Additional widgets, controls and route will be created in a
> > > > vendor specific way through vendor ops. So its similar to patch files in
> > > > legacy HDA driver.
> > > > 
> > > > Vendor specific quirks patch series will follow after the framework is
> > > > merged.
> > > 
> > > Hi Takashi,
> > > 
> > > Any more feedback or looking for more details?
> > 
> > Sorry I haven't looked at the patchset much, as they are mostly for
> > ASoC specific.  BTW, what about EAPD and pin vref?  Are they set up
> > and configurable?
> 
> EAPD can be configured as an widget if capability available.  vref can
> be alsa control to the user to set the percentage value.

Were these implemented in your patchset, or mean as a plan?


Takashi