On 12/1/17 8:56 AM, Takashi Iwai wrote:
On Fri, 01 Dec 2017 10:13:58 +0100, Rakesh Ughreja wrote:
Many Intel platforms (SKL,KBL) etc. in the market supports enahanced audio capabilities which also includes DSP processing. This patch carry forwads the works that is done in the previous series to enable HD Audio codecs on such platforms.
This patch series adds ASoC HDA codec driver for Intel platforms. It is written by reusing the legacy HDA ALSA codec driver. Intention is to maximize the reuse and minimize the changes in the legacy HDA codec driver.
I would like to receive feedback before proceeding further on this direction.
First of all, I appreciate this kind of work finally happening, so that ASoC HD-audio can go forward to a wider usage. However...
TODO:
- This series is tested on KBL based product (Dell XPS 13).
- Basic playback is working with headset and speakers.
- Capture operation is not tested.
- More platforms and use cases coverage can be added once we have basic agreement in terms of the overall approach.
One big thing that is unclear to me is what about the complex I/O configuration although we provide only a single machine driver, and what happens if the (legacy) codec driver allows the jack retasking. I know that nowadays the number of jacks are reduced than before, but still there will be desktop boxes with individual front and rear I/O jacks.
FIXME:
- KConfig changes does not look right, but I could not think of any proper way without making changes into legacy HDA codec driver. So need some help on this topic.
And this is another big issue. As long as you don't allow build both, it never flies with distros, and it means no dramatic improvement of the situation, either.
IOW, we have to make the codec driver working on both controller/bus implementations, and it essentially means to rewrite the HD-audio codec plumbing code. Currently, it's a kind of half-baked state, and we need to cast to unified form.
Before going into codec support, should we first deal with the selection of the ASoC/Legacy mode for the controller side of things? Even with basic HDMI/iDisp cases, we don't have a clean solution today. When I worked on the late Joule platform, there was no fallback mode which forced a recompilation depending on BIOS settings. My understanding is that there is no support for multiple drivers registering for the same PCI ID, I believe we'll have to define a top-level wrapper which arbitrates internally based on BIOS settings and user/distro preferences which mode is selected.
thanks,
Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel