[alsa-devel] [RFC v3 06/11] ASoC: hdac_hda: add ASoC based HDA codec driver

[Takashi Iwai]

On Tue, 19 Dec 2017 17:14:38 +0100,
Ughreja, Rakesh A wrote:
> 
> 
> 
> >-----Original Message-----
> >From: Takashi Iwai [mailto:tiwai at suse.de]
> >Sent: Tuesday, December 19, 2017 9:10 PM
> >To: Ughreja, Rakesh A <rakesh.a.ughreja at intel.com>
> >Cc: alsa-devel at alsa-project.org; Koul, Vinod <vinod.koul at intel.com>; pierre-
> >louis.bossart at linux.intel.com; liam.r.girdwood at linux.intel.com; Patches Audio
> ><patches.audio at intel.com>; broonie at 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