linux-next/sound/hda/Kconfig

config SND_HDA_CORE
	tristate
	select REGMAP

config SND_HDA_DSP_LOADER
	bool

config SND_HDA_I915
	bool
	default y
	depends on DRM_I915
	depends on SND_HDA_CORE

config SND_HDA_EXT_CORE
       tristate
       select SND_HDA_CORE
ALSA: hda - Make snd_hda_bus_type public Define the common hd-audio driver and device types to bind over snd_hda_bus_type publicly. This allows to implement other type of device and driver code over hd-audio bus. Now both struct hda_codec and struct hda_codec_driver inherit these new struct hdac_device and struct hdac_driver, respectively. The bus registration is done in subsys_initcall() to assure it before any other driver registrations. Signed-off-by: Takashi Iwai <tiwai@suse.de> 2015-02-18 04:46:37 +08:00			`config SND_HDA_CORE`
			`tristate`
ALSA: hda - Add regmap support This patch adds an infrastructure to support regmap-based verb accesses. Because o the asymmetric nature of HD-audio verbs, especially the amp verbs, we need to translate the verbs as a sort of pseudo registers to be mapped uniquely in regmap. In this patch, a pseudo register is built from the NID, the AC_VERB_GET_* and 8bit parameters, i.e. almost in the form to be sent to HD-audio bus but without codec address field. OTOH, for writing, the same pseudo register is translated to AC_VERB_SET_* automatically. The AC_VERB_SET_AMP_* verb is re-encoded from the corresponding AC_VERB_GET_AMP_* verb and parameter at writing. Some verbs has a single command for read but multiple for writes. A write for such a verb is split automatically to multiple verbs. The patch provides also a few handy helper functions. They are designed to be accessible even without regmap. When no regmap is set up (e.g. before the codec device instantiation), the direct hardware access is used. Also, it tries to avoid the unnecessary power-up. The power up/down sequence is performed only on demand. The codec driver needs to call snd_hdac_regmap_exit() and snd_hdac_regmap_exit() at probe and remove if it wants the regmap access. There is one flag added to hdac_device. When the flag lazy_cache is set, regmap helper ignores a write for a suspended device and returns as if it was actually written. It reduces the hardware access pretty much, e.g. when adjusting the mixer volume while in idle. This assumes that the driver will sync the cache later at resume properly, so use it carefully. Signed-off-by: Takashi Iwai <tiwai@suse.de> 2015-02-25 21:42:38 +08:00			`select REGMAP`
ALSA: hda - Add DSP loader to core library code Copied from the legacy driver code, no transition done yet. Signed-off-by: Takashi Iwai <tiwai@suse.de> 2015-04-14 18:53:28 +08:00
			`config SND_HDA_DSP_LOADER`
			`bool`
ALSA: hda - Move hda_i915.c from sound/pci/hda to sound/hda The file is moved to hda core and renamed to hdac_i915.c, so can be used by both legacy HDA driver and new Skylake audio driver. - Add snd_hdac_ prefix to the public APIs. - The i915 audio component is moved to core bus and dynamically allocated. - A static pointer hdac_acomp is used to help bind/unbind callbacks to get this component, because the sound card's private_data is used by the azx chip pointer, which is a legacy structure. It could be removed if private _data changes to some core structure which can be extended to find the bus. - snd_hdac_get_display_clk() is added to get the display core clock for HSW/BDW. - haswell_set_bclk() is moved to hda_intel.c because it needs to write the controller registers EM4/EM5, and only legacy HD-A needs it for HSW/BDW. - Move definition of HSW/BDW-specific registers EM4/EM5 to hda_register.h and rename them to HSW_EM4/HSW_EM5, because other HD-A controllers have different layout for the extended mode registers. Signed-off-by: Mengdong Lin <mengdong.lin@intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> 2015-05-19 22:29:30 +08:00
			`config SND_HDA_I915`
			`bool`
			`default y`
			`depends on DRM_I915`
			`depends on SND_HDA_CORE`
ALSA: hdac_ext: add extended HDA bus The new HDA controllers from Intel support new capabilities like multilink, pipe processing, SPIB, GTS etc In order to use them we create an extended HDA bus which embed the hdac bus and contains the fields for extended configurations Signed-off-by: Jeeja KP <jeeja.kp@intel.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> 2015-06-11 16:41:47 +08:00
			`config SND_HDA_EXT_CORE`
			`tristate`
			`select SND_HDA_CORE`