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