[alsa-devel] [PATCH v2 0/2] ALSA: hda: add module flag snd_adsp_enable
This is second attempt for creating a module option for hda core to select either legacy HDA driver or upcoming ASoC driver. This series still relies on module flag (with feedback from previous series baked in). The eventual plan is to rely on HW advertised capabilities and BIOS configuration to load either driver, but since ASoC driver has still some time to get fully merged and matured on various system, we will rely on module flag till the who ASoC HDA systems is completed and available is all distros
Vinod Koul (2): ALSA: hda: add snd_adsp_enable module flag ALSA: hda: use snd_adsp_enable in HDA driver
include/sound/hdaudio.h | 11 +++++++++++ sound/hda/hda_bus_type.c | 6 ++++++ sound/pci/hda/hda_controller.h | 1 + sound/pci/hda/hda_intel.c | 10 +++++++++- 4 files changed, 27 insertions(+), 1 deletion(-)
Some Intel HDA controllers sport a DSP. These systems can also be enabled with ASoC HDA driver as well. So add a flag in hda-core to enable/disable aDSP. This flag for now is false, and should be true once the ASoC based systems mature. The integrators/OS vendors can configure this flag based on system preference.
Signed-off-by: Jeeja KP jeeja.kp@intel.com Signed-off-by: Vinod Koul vinod.koul@intel.com --- include/sound/hdaudio.h | 11 +++++++++++ sound/hda/hda_bus_type.c | 6 ++++++ 2 files changed, 17 insertions(+)
diff --git a/include/sound/hdaudio.h b/include/sound/hdaudio.h index 4caf1fde8a4f..7c4dd26abd4e 100644 --- a/include/sound/hdaudio.h +++ b/include/sound/hdaudio.h @@ -13,6 +13,17 @@ #include <sound/hda_verbs.h> #include <drm/i915_component.h>
+/* + * snd_adsp_enable: exported HD-A aDSP enable configuration. + * + * Some Intel HDA controllers sport a DSP, for these platform we can bypass + * aDSP and use as regular HDA controller or enable aDSP and use aDSP + * along with I2S codecs etc. + * hdac_adsp_enable would enable the aDSP based HDA controller if the + * platform supports it + */ +extern bool snd_adsp_enable; + /* codec node id */ typedef u16 hda_nid_t;
diff --git a/sound/hda/hda_bus_type.c b/sound/hda/hda_bus_type.c index 89c2711baaaf..8fb4e8b1398e 100644 --- a/sound/hda/hda_bus_type.c +++ b/sound/hda/hda_bus_type.c @@ -10,6 +10,12 @@ MODULE_DESCRIPTION("HD-audio bus"); MODULE_LICENSE("GPL");
+bool snd_adsp_enable = false; +EXPORT_SYMBOL_GPL(snd_adsp_enable); + +module_param(snd_adsp_enable, bool, 0444); +MODULE_PARM_DESC(snd_adsp_enable, "HD-A aDSP enable configuration"); + /** * hdac_get_device_id - gets the hdac device id entry * @hdev: HD-audio core device
The SKL platform support aDSP, so we add a new caps AZX_DCAPS_ADSP for this. On platforms with aDSP we still load the HDA driver till ASoC SKL driver is merged and ecosystem around it matured. Later on we need to move this based on BIOS configuration of platform
Signed-off-by: Jeeja KP jeeja.kp@intel.com Signed-off-by: Vinod Koul vinod.koul@intel.com --- sound/pci/hda/hda_controller.h | 1 + sound/pci/hda/hda_intel.c | 10 +++++++++- 2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/sound/pci/hda/hda_controller.h b/sound/pci/hda/hda_controller.h index 314105cd5061..e30aec1af780 100644 --- a/sound/pci/hda/hda_controller.h +++ b/sound/pci/hda/hda_controller.h @@ -50,6 +50,7 @@ #define AZX_DCAPS_CORBRP_SELF_CLEAR (1 << 28) /* CORBRP clears itself after reset */ #define AZX_DCAPS_NO_MSI64 (1 << 29) /* Stick to 32-bit MSIs */ #define AZX_DCAPS_SEPARATE_STREAM_TAG (1 << 30) /* capture and playback use separate stream tag */ +#define AZX_DCAPS_ADSP (1 << 31) /* Intel aDSP support */
enum { AZX_SNOOP_TYPE_NONE, diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index ea0df95bff5d..b91610bd4fba 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -1894,6 +1894,14 @@ static int azx_probe(struct pci_dev *pci, return -ENOENT; }
+ /* + * check if this device has aDSP caps and DSP is disabled in + * configuration, then go ahead, otherwise ASoC driver will load for + * this device + */ + if ((pci_id->driver_data && AZX_DCAPS_ADSP) && (snd_adsp_enable == true)) + return -ENODEV; + err = snd_card_new(&pci->dev, index[dev], id[dev], THIS_MODULE, 0, &card); if (err < 0) { @@ -2101,7 +2109,7 @@ static const struct pci_device_id azx_ids[] = { .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_SKYLAKE }, /* Sunrise Point-LP */ { PCI_DEVICE(0x8086, 0x9d70), - .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_SKYLAKE }, + .driver_data = AZX_DRIVER_PCH | AZX_DCAPS_INTEL_SKYLAKE | AZX_DCAPS_ADSP }, /* Haswell */ { PCI_DEVICE(0x8086, 0x0a0c), .driver_data = AZX_DRIVER_HDMI | AZX_DCAPS_INTEL_HASWELL },
At Thu, 18 Jun 2015 12:08:23 +0530, Vinod Koul wrote:
This is second attempt for creating a module option for hda core to select either legacy HDA driver or upcoming ASoC driver. This series still relies on module flag (with feedback from previous series baked in). The eventual plan is to rely on HW advertised capabilities and BIOS configuration to load either driver, but since ASoC driver has still some time to get fully merged and matured on various system, we will rely on module flag till the who ASoC HDA systems is completed and available is all distros
Well, somehow I prefer postponing this. The method would work but is indeed hackish, so let's put this together with other pieces as a last resort unless any better solution is found. For the driver development itself, this isn't really needed; you can put blacklist at any time.
thanks,
Takashi
Vinod Koul (2): ALSA: hda: add snd_adsp_enable module flag ALSA: hda: use snd_adsp_enable in HDA driver
include/sound/hdaudio.h | 11 +++++++++++ sound/hda/hda_bus_type.c | 6 ++++++ sound/pci/hda/hda_controller.h | 1 + sound/pci/hda/hda_intel.c | 10 +++++++++- 4 files changed, 27 insertions(+), 1 deletion(-)
-- 1.9.1
On Fri, Jun 19, 2015 at 01:37:22PM +0200, Takashi Iwai wrote:
At Thu, 18 Jun 2015 12:08:23 +0530, Vinod Koul wrote:
This is second attempt for creating a module option for hda core to select either legacy HDA driver or upcoming ASoC driver. This series still relies on module flag (with feedback from previous series baked in). The eventual plan is to rely on HW advertised capabilities and BIOS configuration to load either driver, but since ASoC driver has still some time to get fully merged and matured on various system, we will rely on module flag till the who ASoC HDA systems is completed and available is all distros
Well, somehow I prefer postponing this. The method would work but is indeed hackish, so let's put this together with other pieces as a last resort unless any better solution is found. For the driver development itself, this isn't really needed; you can put blacklist at any time.
Okay blacklist will work too...
participants (2)
-
Takashi Iwai -
Vinod Koul