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. > strictly. As a generic hint, I would recommend the following: > > - Try lots of different codecs and pin configurations. > At best, write an emulator and process on it, and check the > robustness and the correctness of your code. > For example, the old AD1984A is one of the beasts that gives you a > hell of complex routes. Also the recent Cirrus codecs gives you > tons of I/O pins. > > - Think how to remap the pins and other setups in general. Only problem with remapping of the pins, I can think of is, the way it is represented in DAPM route. In DAPM pins are modelled with multiple DAPM widgets (input/output, PGA) to handle this remapping capability. Any pin capable of remapping will be represented with both an input and output DAPM widget and will have all possible route mapping registered with DAPM. The remap capability of pin will appear as an alsa control in userspace. Based on the configuration from userspace the pin capability will be programmed in the driver. > This is one of the most important keys. Writing the generic code is > only to solve a tip of iceberg. The most difficult part is to adapt > the generic code to the real machine configurations. > > - Think how to handle the vendor-specific codes. > Majority of machines have the own code due to the headset, EAPD, These will be handled through alsa controls. There will be many though due to many optional features and vendor specific. > digital mic or LED controls, as well as the non-standard jack > detection. Can you please explain more on what is non-standard jack detection? Thanks Subhransu > > > Takashi > > > > > Hardik T Shah (1): > > ASoC: Add dai_ops to set the stream tag. > > > > Subhransu S. Prusty (10): > > ALSA: hdac: Add codec helper library > > ALSA: hda - Add macro to test pin widget's input capability > > ASoC: hdac: Add a generic hdac driver framework > > ASoC: hdac: Create DAPM model for HDA widgets > > ASoC: dapm: Create API to add a single route element > > ASoC: hdac: Build DAPM graph by querying through widget connection > > list > > ASoC: hdac: Register widget event handlers > > ALSA: hda - macro to get default config device of pin widgets > > ASoC: dapm: Export snd_soc_dapm_new_control > > ASoC: hdac: Export API to create machine controls > > > > include/sound/hdaudio.h | 1 + > > include/sound/soc-dai.h | 12 + > > include/sound/soc-dapm.h | 5 + > > sound/hda/ext/Makefile | 3 +- > > sound/hda/ext/hdac_codec.c | 188 +++++ > > sound/hda/ext/hdac_codec.h | 52 ++ > > sound/hda/local.h | 13 + > > sound/soc/codecs/Kconfig | 5 + > > sound/soc/codecs/Makefile | 2 + > > sound/soc/codecs/hdac_generic.c | 1561 +++++++++++++++++++++++++++++++++++++++ > > sound/soc/codecs/hdac_generic.h | 31 + > > sound/soc/soc-core.c | 35 + > > sound/soc/soc-dapm.c | 22 + > > 13 files changed, 1929 insertions(+), 1 deletion(-) > > create mode 100644 sound/hda/ext/hdac_codec.c > > create mode 100644 sound/hda/ext/hdac_codec.h > > create mode 100644 sound/soc/codecs/hdac_generic.c > > create mode 100644 sound/soc/codecs/hdac_generic.h > > > > -- > > 1.9.1 > > > _______________________________________________ > Alsa-devel mailing list > Alsa-devel@xxxxxxxxxxxxxxxx > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel -- _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
