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 rakesh.a.ughreja@intel.com Cc: alsa-devel@alsa-project.org; Koul, Vinod vinod.koul@intel.com; pierre- louis.bossart@linux.intel.com; liam.r.girdwood@linux.intel.com; Patches Audio patches.audio@intel.com; 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.
- 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.
- 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