From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: [RFC v3 06/11] ASoC: hdac_hda: add ASoC based HDA codec driver Date: Tue, 19 Dec 2017 17:23:44 +0100 Message-ID: References: <1513337448-31685-1-git-send-email-rakesh.a.ughreja@intel.com> <1513337448-31685-7-git-send-email-rakesh.a.ughreja@intel.com> <85DFEED57DC57344B2483EF7BF8CB60579ADA90D@BGSMSX104.gar.corp.intel.com> <85DFEED57DC57344B2483EF7BF8CB60579ADAF8C@BGSMSX104.gar.corp.intel.com> <85DFEED57DC57344B2483EF7BF8CB60579ADB65F@BGSMSX104.gar.corp.intel.com> <85DFEED57DC57344B2483EF7BF8CB60579ADCE9A@BGSMSX104.gar.corp.intel.com> <85DFEED57DC57344B2483EF7BF8CB60579ADD339@BGSMSX104.gar.corp.intel.com> <85DFEED57DC57344B2483EF7BF8CB60579ADD712@BGSMSX104.gar.corp.intel.com> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by alsa0.perex.cz (Postfix) with ESMTP id 48900266F2E for ; Tue, 19 Dec 2017 17:23:45 +0100 (CET) In-Reply-To: <85DFEED57DC57344B2483EF7BF8CB60579ADD712@BGSMSX104.gar.corp.intel.com> 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: "Ughreja, Rakesh A" Cc: "alsa-devel@alsa-project.org" , "Koul, Vinod" , "pierre-louis.bossart@linux.intel.com" , "liam.r.girdwood@linux.intel.com" , Patches Audio , "broonie@kernel.org" List-Id: alsa-devel@alsa-project.org On Tue, 19 Dec 2017 17:14:38 +0100, Ughreja, Rakesh A wrote: > > > > >-----Original Message----- > >From: Takashi Iwai [mailto:tiwai@suse.de] > >Sent: Tuesday, December 19, 2017 9:10 PM > >To: Ughreja, Rakesh A > >Cc: alsa-devel@alsa-project.org; Koul, Vinod ; pierre- > >louis.bossart@linux.intel.com; liam.r.girdwood@linux.intel.com; Patches Audio > >; broonie@kernel.org > >Subject: Re: [alsa-devel] [RFC v3 06/11] ASoC: hdac_hda: add ASoC based HDA > >codec driver > > > > > >> > >> Are you referring to the calling overhead because of the wrapper involved ? > >> > >> The way I see is we have two options. > >> > >> 1. Single driver option. - There is going to be a common wrapper here, > >> which needs to come into picture before it re-directs it to the appropriate > >> driver. This is what is done in the following patch. > >> > >> 2. Separate driver for ASoC and Legacy. - This requires ID tables, Can we move > >> id tables into separate header file ? then it can solve the problem involved in > >> option 1. This also solves the problem related to wrappers as well as the > >> problem related to accessing the ID tables via extern symbols, that you > >> mentioned in the previous series. > > > >I believe (2) is no-go, it's a straight maintenance hell. > > Got it. > > > > >> >May we start from a "big picture" to describe the whole driver > >> >bindings? > >> > > >> > >> This patch registers the hdac_driver callback at the root level agnostic to > >> asoc and legacy and then selects the appropriate legacy or asoc callbacks, > >> based on the bus which enumerated the driver. > >> > >> I cannot think of any other approach if we want to go with a single driver > >> approach. You will have to give some more hints :-) > > > >Well, a big unclear question to me is why do we need to bind the stuff > >so differently. Can't we simply provide the same binding to the > >legacy codec from asoc driver? In the legacy-support mode, asoc > >driver creates the legacy-compatible codec objects with the > >legacy-compatible hda_bus. > > > > Both the drivers i.e. ASoC and Legacy are registering the driver in > exact same way by filling the hdac_driver fields. There is no difference > in terms of HDA bus interactions. First series unifies even the data > structures hdac_device, hdac_driver and hdac_bus. Yes, that's a good part. > Once the device is enumerated and the hdac_driver->probe > is called the difference starts, primarily because ASoC vs ALSA > codec driver differences. Why so different? Is it hard to integrate them somehow? What exactly do we need to do in addition to the existing legacy HD-audio codec probe/remove/whatever? > Here also if you notice, after taking care of > the ASoC related components, ASoC codec driver calls exact same APIs of the > legacy HDA codec driver which are called by the legacy controller driver. > > The hda_bus and hda_codec data structures are also used by the ASoC > driver as it is to call legacy codec driver APIs. > > So I am not sure if we are doing binding in two different ways, or I > misunderstood you completely ? Well, I still am not sure why do we need two ways, completely switching the whole binding. If it's a matter of some additional calls on top of the legacy probe, we can add a new optional bus ops, and call it in the probe function, too. At the time of probe callback, the bus is already present. thanks, Takashi