From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Subhransu S. Prusty" Subject: Re: [RFC 00/11] ASoC: hdac: Add hdac generic driver Date: Fri, 8 Jul 2016 13:51:39 +0530 Message-ID: <20160708082135.GA15524@subhransu-desktop> References: <1466999284-14782-1-git-send-email-subhransu.s.prusty@intel.com> <20160628051347.GH14022@subhransu-desktop> <20160708073348.GB15209@subhransu-desktop> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by alsa0.perex.cz (Postfix) with ESMTP id 1A1A8260674 for ; Fri, 8 Jul 2016 10:25:25 +0200 (CEST) Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: alsa-devel-bounces@alsa-project.org To: Takashi Iwai Cc: patches.audio@intel.com, alsa-devel@alsa-project.org, broonie@kernel.org, lgirdwood@gmail.com List-Id: alsa-devel@alsa-project.org 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. Regards, Subhransu > > > Takashi --