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

[Subhransu S. Prusty]

On Fri, Jul 08, 2016 at 10:37:48AM +0200, Takashi Iwai wrote:
> 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?

This is not implemented in this patchset. But yes it's already in our plan.
This series only programs the required verbs. We will add optional features,
jack detection, vendor specific quirks and other features after the basic
drivers is merged.

Regards,
Subhransu
> 
> 
> Takashi
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel at alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

--