On Tue, Jun 28, 2016 at 10:43:47AM +0530, Subhransu S. Prusty wrote: > 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. Hi Takashi, Any more feedback or looking for more details? Regards, Subhransu > > > > 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
