[alsa-devel] [PATCH 1/2] ALSA: hda - Enable i915 binding for gen3/4 HDMI/DP
This patch fills the holes and now all i915 HDMI/DP codecs are managed over the audio ELD notifier, finally. The old gen3/gen4 chips have usually only a single pin/converter pair, and the digital port mapping is fixed.
Signed-off-by: Takashi Iwai tiwai@suse.de --- sound/hda/hdac_i915.c | 11 +++++++++++ sound/pci/hda/patch_hdmi.c | 21 +++++++++++++++------ 2 files changed, 26 insertions(+), 6 deletions(-)
diff --git a/sound/hda/hdac_i915.c b/sound/hda/hdac_i915.c index d0da2508823e..c62a9f830b84 100644 --- a/sound/hda/hdac_i915.c +++ b/sound/hda/hdac_i915.c @@ -128,6 +128,9 @@ EXPORT_SYMBOL_GPL(snd_hdac_get_display_clk); * Pin Widget 4 - PORT B (port = 1 in i915 driver) * Pin Widget 5 - PORT C (port = 2 in i915 driver) * Pin Widget 6 - PORT D (port = 3 in i915 driver) + * + * on earlier models: + * Pin Widget 3 - PORT B */ static int pin2port(struct hdac_device *codec, hda_nid_t pin_nid) { @@ -139,6 +142,14 @@ static int pin2port(struct hdac_device *codec, hda_nid_t pin_nid) case 0x80862882: /* VLV */ base_nid = 3; break; + case 0x80862801: /* Bearlake */ + case 0x80862802: /* Cantiga */ + case 0x80862803: /* Eaglelake */ + case 0x80862880: /* CedarTrail */ + case 0x808629fb: /* Crestline HDMI */ + if (WARN_ON(pin_nid != 0x03)) + return -1; + return 1; /* only port B */ default: base_nid = 4; break; diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c index 4833c7bdd1e8..2a3bf1584f3b 100644 --- a/sound/pci/hda/patch_hdmi.c +++ b/sound/pci/hda/patch_hdmi.c @@ -2286,6 +2286,15 @@ static void intel_pin_eld_notify(void *audio_ptr, int port) case 0x80862882: /* VLV */ pin_nid = port + 0x03; break; + case 0x80862801: /* Bearlake */ + case 0x80862802: /* Cantiga */ + case 0x80862803: /* Eaglelake */ + case 0x80862880: /* CedarTrail */ + case 0x808629fb: /* Crestline HDMI */ + if (WARN_ON(port != 1)) /* assume only port B */ + return; + pin_nid = 0x03; + break; default: pin_nid = port + 0x04; break; @@ -2424,7 +2433,7 @@ static int patch_i915_byt_hdmi(struct hda_codec *codec) return 0; }
-/* Intel IronLake, SandyBridge and IvyBridge; with eld notifier */ +/* Intel Gen3/Gen4, IronLake, SandyBridge and IvyBridge; with eld notifier */ static int patch_i915_cpt_hdmi(struct hda_codec *codec) { struct hdmi_spec *spec; @@ -3627,9 +3636,9 @@ HDA_CODEC_ENTRY(0x11069f81, "VX900 HDMI/DP", patch_via_hdmi), HDA_CODEC_ENTRY(0x11069f84, "VX11 HDMI/DP", patch_generic_hdmi), HDA_CODEC_ENTRY(0x11069f85, "VX11 HDMI/DP", patch_generic_hdmi), HDA_CODEC_ENTRY(0x80860054, "IbexPeak HDMI", patch_i915_cpt_hdmi), -HDA_CODEC_ENTRY(0x80862801, "Bearlake HDMI", patch_generic_hdmi), -HDA_CODEC_ENTRY(0x80862802, "Cantiga HDMI", patch_generic_hdmi), -HDA_CODEC_ENTRY(0x80862803, "Eaglelake HDMI", patch_generic_hdmi), +HDA_CODEC_ENTRY(0x80862801, "Bearlake HDMI", patch_i915_cpt_hdmi), +HDA_CODEC_ENTRY(0x80862802, "Cantiga HDMI", patch_i915_cpt_hdmi), +HDA_CODEC_ENTRY(0x80862803, "Eaglelake HDMI", patch_i915_cpt_hdmi), HDA_CODEC_ENTRY(0x80862804, "IbexPeak HDMI", patch_i915_cpt_hdmi), HDA_CODEC_ENTRY(0x80862805, "CougarPoint HDMI", patch_i915_cpt_hdmi), HDA_CODEC_ENTRY(0x80862806, "PantherPoint HDMI", patch_i915_cpt_hdmi), @@ -3638,10 +3647,10 @@ HDA_CODEC_ENTRY(0x80862808, "Broadwell HDMI", patch_i915_hsw_hdmi), HDA_CODEC_ENTRY(0x80862809, "Skylake HDMI", patch_i915_hsw_hdmi), HDA_CODEC_ENTRY(0x8086280a, "Broxton HDMI", patch_i915_hsw_hdmi), HDA_CODEC_ENTRY(0x8086280b, "Kabylake HDMI", patch_i915_hsw_hdmi), -HDA_CODEC_ENTRY(0x80862880, "CedarTrail HDMI", patch_generic_hdmi), +HDA_CODEC_ENTRY(0x80862880, "CedarTrail HDMI", patch_i915_cpt_hdmi), HDA_CODEC_ENTRY(0x80862882, "Valleyview2 HDMI", patch_i915_byt_hdmi), HDA_CODEC_ENTRY(0x80862883, "Braswell HDMI", patch_i915_byt_hdmi), -HDA_CODEC_ENTRY(0x808629fb, "Crestline HDMI", patch_generic_hdmi), +HDA_CODEC_ENTRY(0x808629fb, "Crestline HDMI", patch_i915_cpt_hdmi), /* special ID for generic HDMI */ HDA_CODEC_ENTRY(HDA_CODEC_ID_GENERIC_HDMI, "Generic HDMI", patch_generic_hdmi), {} /* terminator */
On Skylake and onwards, the HD-audio controller driver needs to bind with i915 for having the control of power well audio domain before actually probing the codec. This leads to the load of i915 driver from the audio driver side. But, there are systems that have no Intel graphics but Nvidia or AMD GPU, although they still use HD-audio bus for the onboard audio codecs. On these, loading the i915 driver is nothing but a useless memory and CPU consumption.
A simple way to avoid it is just to look for the Intel graphics PCI entry beforehand, and try to bind with i915 only when such an entry is found. Currently, it assumes the PCI display class. If another class appears, this needs to be extended (although it's very unlikely).
Signed-off-by: Takashi Iwai tiwai@suse.de --- sound/hda/hdac_i915.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+)
diff --git a/sound/hda/hdac_i915.c b/sound/hda/hdac_i915.c index c62a9f830b84..3c8e6d93d4df 100644 --- a/sound/hda/hdac_i915.c +++ b/sound/hda/hdac_i915.c @@ -298,6 +298,17 @@ int snd_hdac_i915_register_notifier(const struct i915_audio_component_audio_ops } EXPORT_SYMBOL_GPL(snd_hdac_i915_register_notifier);
+/* check whether intel graphics is present */ +static bool i915_gfx_present(void) +{ + static struct pci_device_id ids[] = { + { PCI_DEVICE_CLASS(PCI_BASE_CLASS_DISPLAY << 16, 0xff0000) }, + {} + }; + return pci_dev_present(ids); +} + + /** * snd_hdac_i915_init - Initialize i915 audio component * @bus: HDA core bus @@ -320,6 +331,9 @@ int snd_hdac_i915_init(struct hdac_bus *bus) if (WARN_ON(hdac_acomp)) return -EBUSY;
+ if (!i915_gfx_present()) + return -ENODEV; + acomp = kzalloc(sizeof(*acomp), GFP_KERNEL); if (!acomp) return -ENOMEM;
On Wed, Mar 30, 2016 at 05:46:02PM +0200, Takashi Iwai wrote:
On Skylake and onwards, the HD-audio controller driver needs to bind with i915 for having the control of power well audio domain before actually probing the codec. This leads to the load of i915 driver from the audio driver side. But, there are systems that have no Intel graphics but Nvidia or AMD GPU, although they still use HD-audio bus for the onboard audio codecs. On these, loading the i915 driver is nothing but a useless memory and CPU consumption.
A simple way to avoid it is just to look for the Intel graphics PCI entry beforehand, and try to bind with i915 only when such an entry is found. Currently, it assumes the PCI display class. If another class appears, this needs to be extended (although it's very unlikely).
Signed-off-by: Takashi Iwai tiwai@suse.de
sound/hda/hdac_i915.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+)
diff --git a/sound/hda/hdac_i915.c b/sound/hda/hdac_i915.c index c62a9f830b84..3c8e6d93d4df 100644 --- a/sound/hda/hdac_i915.c +++ b/sound/hda/hdac_i915.c @@ -298,6 +298,17 @@ int snd_hdac_i915_register_notifier(const struct i915_audio_component_audio_ops } EXPORT_SYMBOL_GPL(snd_hdac_i915_register_notifier);
+/* check whether intel graphics is present */ +static bool i915_gfx_present(void) +{
- static struct pci_device_id ids[] = {
{ PCI_DEVICE_CLASS(PCI_BASE_CLASS_DISPLAY << 16, 0xff0000) },{}- };
- return pci_dev_present(ids);
+}
Should this be checking for at least the Intel vendor ID? External GPUs should be display class devices too, no?
/**
- snd_hdac_i915_init - Initialize i915 audio component
- @bus: HDA core bus
@@ -320,6 +331,9 @@ int snd_hdac_i915_init(struct hdac_bus *bus) if (WARN_ON(hdac_acomp)) return -EBUSY;
- if (!i915_gfx_present())
return -ENODEV;- acomp = kzalloc(sizeof(*acomp), GFP_KERNEL); if (!acomp) return -ENOMEM;
-- 2.7.4
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
On Thu, 31 Mar 2016 14:56:40 +0200, Ville Syrjälä wrote:
On Wed, Mar 30, 2016 at 05:46:02PM +0200, Takashi Iwai wrote:
On Skylake and onwards, the HD-audio controller driver needs to bind with i915 for having the control of power well audio domain before actually probing the codec. This leads to the load of i915 driver from the audio driver side. But, there are systems that have no Intel graphics but Nvidia or AMD GPU, although they still use HD-audio bus for the onboard audio codecs. On these, loading the i915 driver is nothing but a useless memory and CPU consumption.
A simple way to avoid it is just to look for the Intel graphics PCI entry beforehand, and try to bind with i915 only when such an entry is found. Currently, it assumes the PCI display class. If another class appears, this needs to be extended (although it's very unlikely).
Signed-off-by: Takashi Iwai tiwai@suse.de
sound/hda/hdac_i915.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+)
diff --git a/sound/hda/hdac_i915.c b/sound/hda/hdac_i915.c index c62a9f830b84..3c8e6d93d4df 100644 --- a/sound/hda/hdac_i915.c +++ b/sound/hda/hdac_i915.c @@ -298,6 +298,17 @@ int snd_hdac_i915_register_notifier(const struct i915_audio_component_audio_ops } EXPORT_SYMBOL_GPL(snd_hdac_i915_register_notifier);
+/* check whether intel graphics is present */ +static bool i915_gfx_present(void) +{
- static struct pci_device_id ids[] = {
{ PCI_DEVICE_CLASS(PCI_BASE_CLASS_DISPLAY << 16, 0xff0000) },{}- };
- return pci_dev_present(ids);
+}
Should this be checking for at least the Intel vendor ID? External GPUs should be display class devices too, no?
Doh, yes, of course. This has been slipped while refactoring.
thanks,
Takashi
On Wed, Mar 30, 2016 at 05:46:01PM +0200, Takashi Iwai wrote:
This patch fills the holes and now all i915 HDMI/DP codecs are managed over the audio ELD notifier, finally. The old gen3/gen4 chips have usually only a single pin/converter pair, and the digital port mapping is fixed.
Signed-off-by: Takashi Iwai tiwai@suse.de
sound/hda/hdac_i915.c | 11 +++++++++++ sound/pci/hda/patch_hdmi.c | 21 +++++++++++++++------ 2 files changed, 26 insertions(+), 6 deletions(-)
diff --git a/sound/hda/hdac_i915.c b/sound/hda/hdac_i915.c index d0da2508823e..c62a9f830b84 100644 --- a/sound/hda/hdac_i915.c +++ b/sound/hda/hdac_i915.c @@ -128,6 +128,9 @@ EXPORT_SYMBOL_GPL(snd_hdac_get_display_clk);
- Pin Widget 4 - PORT B (port = 1 in i915 driver)
- Pin Widget 5 - PORT C (port = 2 in i915 driver)
- Pin Widget 6 - PORT D (port = 3 in i915 driver)
- on earlier models:
- Pin Widget 3 - PORT B
Hmm. ctg/elk have potentially multiple HDMI ports. Although they only have one video DIP block so can send infoframes only to one of the ports at a time. I wonder how this relates to the audio part, as in does the pin widget 3 always map to the port that is getting infoframes currently? I do have one elk with two HDMI ports here so I could do some experiments if needed.
*/ static int pin2port(struct hdac_device *codec, hda_nid_t pin_nid) { @@ -139,6 +142,14 @@ static int pin2port(struct hdac_device *codec, hda_nid_t pin_nid) case 0x80862882: /* VLV */ base_nid = 3; break;
- case 0x80862801: /* Bearlake */
Hmm. I wonder if this is bearlake-C or something earlier. BLC doesn't actually exist AFAIK, and earlier bearlake is gen3 and doesn't even support native HDMI output so not sure what this is doing here.
- case 0x80862802: /* Cantiga */
- case 0x80862803: /* Eaglelake */
- case 0x80862880: /* CedarTrail */
Cedartrail is some powervr atom thing. Should have nothing to do with i915.
- case 0x808629fb: /* Crestline HDMI */
CL is gen4 and we don't support native HDMI output on those. Strangely enough our spec says CL/BW do support TMDS encoding on the SDVO/HDMI ports and that CL also has the video DIP block and the HDA registers. Not sure what to make of that really.
if (WARN_ON(pin_nid != 0x03))return -1;return 1; /* only port B */diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c index 4833c7bdd1e8..2a3bf1584f3b 100644 --- a/sound/pci/hda/patch_hdmi.c +++ b/sound/pci/hda/patch_hdmi.c @@ -2286,6 +2286,15 @@ static void intel_pin_eld_notify(void *audio_ptr, int port) case 0x80862882: /* VLV */ pin_nid = port + 0x03; break;
- case 0x80862801: /* Bearlake */
- case 0x80862802: /* Cantiga */
- case 0x80862803: /* Eaglelake */
- case 0x80862880: /* CedarTrail */
- case 0x808629fb: /* Crestline HDMI */
if (WARN_ON(port != 1)) /* assume only port B */return;pin_nid = 0x03;break;@@ -2424,7 +2433,7 @@ static int patch_i915_byt_hdmi(struct hda_codec *codec) return 0; }
-/* Intel IronLake, SandyBridge and IvyBridge; with eld notifier */ +/* Intel Gen3/Gen4, IronLake, SandyBridge and IvyBridge; with eld notifier */ static int patch_i915_cpt_hdmi(struct hda_codec *codec) { struct hdmi_spec *spec; @@ -3627,9 +3636,9 @@ HDA_CODEC_ENTRY(0x11069f81, "VX900 HDMI/DP", patch_via_hdmi), HDA_CODEC_ENTRY(0x11069f84, "VX11 HDMI/DP", patch_generic_hdmi), HDA_CODEC_ENTRY(0x11069f85, "VX11 HDMI/DP", patch_generic_hdmi), HDA_CODEC_ENTRY(0x80860054, "IbexPeak HDMI", patch_i915_cpt_hdmi), -HDA_CODEC_ENTRY(0x80862801, "Bearlake HDMI", patch_generic_hdmi), -HDA_CODEC_ENTRY(0x80862802, "Cantiga HDMI", patch_generic_hdmi), -HDA_CODEC_ENTRY(0x80862803, "Eaglelake HDMI", patch_generic_hdmi), +HDA_CODEC_ENTRY(0x80862801, "Bearlake HDMI", patch_i915_cpt_hdmi), +HDA_CODEC_ENTRY(0x80862802, "Cantiga HDMI", patch_i915_cpt_hdmi), +HDA_CODEC_ENTRY(0x80862803, "Eaglelake HDMI", patch_i915_cpt_hdmi), HDA_CODEC_ENTRY(0x80862804, "IbexPeak HDMI", patch_i915_cpt_hdmi), HDA_CODEC_ENTRY(0x80862805, "CougarPoint HDMI", patch_i915_cpt_hdmi), HDA_CODEC_ENTRY(0x80862806, "PantherPoint HDMI", patch_i915_cpt_hdmi), @@ -3638,10 +3647,10 @@ HDA_CODEC_ENTRY(0x80862808, "Broadwell HDMI", patch_i915_hsw_hdmi), HDA_CODEC_ENTRY(0x80862809, "Skylake HDMI", patch_i915_hsw_hdmi), HDA_CODEC_ENTRY(0x8086280a, "Broxton HDMI", patch_i915_hsw_hdmi), HDA_CODEC_ENTRY(0x8086280b, "Kabylake HDMI", patch_i915_hsw_hdmi), -HDA_CODEC_ENTRY(0x80862880, "CedarTrail HDMI", patch_generic_hdmi), +HDA_CODEC_ENTRY(0x80862880, "CedarTrail HDMI", patch_i915_cpt_hdmi), HDA_CODEC_ENTRY(0x80862882, "Valleyview2 HDMI", patch_i915_byt_hdmi), HDA_CODEC_ENTRY(0x80862883, "Braswell HDMI", patch_i915_byt_hdmi), -HDA_CODEC_ENTRY(0x808629fb, "Crestline HDMI", patch_generic_hdmi), +HDA_CODEC_ENTRY(0x808629fb, "Crestline HDMI", patch_i915_cpt_hdmi), /* special ID for generic HDMI */ HDA_CODEC_ENTRY(HDA_CODEC_ID_GENERIC_HDMI, "Generic HDMI", patch_generic_hdmi), {} /* terminator */ -- 2.7.4
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
On Thu, 31 Mar 2016 14:30:26 +0200, Ville Syrjälä wrote:
On Wed, Mar 30, 2016 at 05:46:01PM +0200, Takashi Iwai wrote:
This patch fills the holes and now all i915 HDMI/DP codecs are managed over the audio ELD notifier, finally. The old gen3/gen4 chips have usually only a single pin/converter pair, and the digital port mapping is fixed.
Signed-off-by: Takashi Iwai tiwai@suse.de
sound/hda/hdac_i915.c | 11 +++++++++++ sound/pci/hda/patch_hdmi.c | 21 +++++++++++++++------ 2 files changed, 26 insertions(+), 6 deletions(-)
diff --git a/sound/hda/hdac_i915.c b/sound/hda/hdac_i915.c index d0da2508823e..c62a9f830b84 100644 --- a/sound/hda/hdac_i915.c +++ b/sound/hda/hdac_i915.c @@ -128,6 +128,9 @@ EXPORT_SYMBOL_GPL(snd_hdac_get_display_clk);
- Pin Widget 4 - PORT B (port = 1 in i915 driver)
- Pin Widget 5 - PORT C (port = 2 in i915 driver)
- Pin Widget 6 - PORT D (port = 3 in i915 driver)
- on earlier models:
- Pin Widget 3 - PORT B
Hmm. ctg/elk have potentially multiple HDMI ports. Although they only have one video DIP block so can send infoframes only to one of the ports at a time. I wonder how this relates to the audio part, as in does the pin widget 3 always map to the port that is getting infoframes currently? I do have one elk with two HDMI ports here so I could do some experiments if needed.
That's great. I'd like to see how many audio pins are there. Could you take alsa-info.sh snapshot without my patches? If the port switching happens but it's not seen in the audio side, we'd need to record the last active audio port in i915 side and let i915 function taking it (e.g. when port = -1 is passed by callback).
*/ static int pin2port(struct hdac_device *codec, hda_nid_t pin_nid) { @@ -139,6 +142,14 @@ static int pin2port(struct hdac_device *codec, hda_nid_t pin_nid) case 0x80862882: /* VLV */ base_nid = 3; break;
- case 0x80862801: /* Bearlake */
Hmm. I wonder if this is bearlake-C or something earlier. BLC doesn't actually exist AFAIK, and earlier bearlake is gen3 and doesn't even support native HDMI output so not sure what this is doing here.
Possibly wrongly named. Looking at the history, it seems to be labeled as "G45 DEVBLC" originally. I only checked Cantiga and Eaglelake, so far.
- case 0x80862802: /* Cantiga */
- case 0x80862803: /* Eaglelake */
- case 0x80862880: /* CedarTrail */
Cedartrail is some powervr atom thing. Should have nothing to do with i915.
Thanks, this one should be removed.
- case 0x808629fb: /* Crestline HDMI */
CL is gen4 and we don't support native HDMI output on those. Strangely enough our spec says CL/BW do support TMDS encoding on the SDVO/HDMI ports and that CL also has the video DIP block and the HDA registers. Not sure what to make of that really.
Hm, OK, in a safer side, we may revert for these entries.
Takashi
On Thu, Mar 31, 2016 at 02:45:13PM +0200, Takashi Iwai wrote:
On Thu, 31 Mar 2016 14:30:26 +0200, Ville Syrjälä wrote:
On Wed, Mar 30, 2016 at 05:46:01PM +0200, Takashi Iwai wrote:
This patch fills the holes and now all i915 HDMI/DP codecs are managed over the audio ELD notifier, finally. The old gen3/gen4 chips have usually only a single pin/converter pair, and the digital port mapping is fixed.
Signed-off-by: Takashi Iwai tiwai@suse.de
sound/hda/hdac_i915.c | 11 +++++++++++ sound/pci/hda/patch_hdmi.c | 21 +++++++++++++++------ 2 files changed, 26 insertions(+), 6 deletions(-)
diff --git a/sound/hda/hdac_i915.c b/sound/hda/hdac_i915.c index d0da2508823e..c62a9f830b84 100644 --- a/sound/hda/hdac_i915.c +++ b/sound/hda/hdac_i915.c @@ -128,6 +128,9 @@ EXPORT_SYMBOL_GPL(snd_hdac_get_display_clk);
- Pin Widget 4 - PORT B (port = 1 in i915 driver)
- Pin Widget 5 - PORT C (port = 2 in i915 driver)
- Pin Widget 6 - PORT D (port = 3 in i915 driver)
- on earlier models:
- Pin Widget 3 - PORT B
Hmm. ctg/elk have potentially multiple HDMI ports. Although they only have one video DIP block so can send infoframes only to one of the ports at a time. I wonder how this relates to the audio part, as in does the pin widget 3 always map to the port that is getting infoframes currently? I do have one elk with two HDMI ports here so I could do some experiments if needed.
That's great. I'd like to see how many audio pins are there. Could you take alsa-info.sh snapshot without my patches?
Attached.
If the port switching happens but it's not seen in the audio side, we'd need to record the last active audio port in i915 side and let i915 function taking it (e.g. when port = -1 is passed by callback).
I played around with the machine a bit and HDMI audio works as long as just one of the ports has the audio enable bit set. If the bit is set on multiple ports, there is no audio. Doesn't matter if I drive the ports with the same pipe or two different pipes. Oh, and I just found a note in the spec to confirm this behaviour. I'll need to rework the i915 HDMI code a bit to make this work correctly.
Also I tested sending video related infoframes to one port and audio to the other port, and that also worked. I verified that at least the video infoframes really went to the port I want by having the AVI infoframe indicate YCbCr 4:4:4 while actually sending RGB data, and checking that the colors distorted on the correct port. But I'm not sure if the audio infoframe gets sent to the right port in this case. Since I don't have any HDMI analyzers and such I think I need to try and make a similar expriment with the audio infoframe to see which ports gets it. But that involves reading the spec and some code to find something useful to tweak in the infoframe.
*/ static int pin2port(struct hdac_device *codec, hda_nid_t pin_nid) { @@ -139,6 +142,14 @@ static int pin2port(struct hdac_device *codec, hda_nid_t pin_nid) case 0x80862882: /* VLV */ base_nid = 3; break;
- case 0x80862801: /* Bearlake */
Hmm. I wonder if this is bearlake-C or something earlier. BLC doesn't actually exist AFAIK, and earlier bearlake is gen3 and doesn't even support native HDMI output so not sure what this is doing here.
Possibly wrongly named. Looking at the history, it seems to be labeled as "G45 DEVBLC" originally.
Yeah that sounds like the thing that doesn't exist.
I only checked Cantiga and Eaglelake, so far.
- case 0x80862802: /* Cantiga */
- case 0x80862803: /* Eaglelake */
- case 0x80862880: /* CedarTrail */
Cedartrail is some powervr atom thing. Should have nothing to do with i915.
Thanks, this one should be removed.
- case 0x808629fb: /* Crestline HDMI */
CL is gen4 and we don't support native HDMI output on those. Strangely enough our spec says CL/BW do support TMDS encoding on the SDVO/HDMI ports and that CL also has the video DIP block and the HDA registers. Not sure what to make of that really.
Hm, OK, in a safer side, we may revert for these entries.
Another interesting mess I noticed is that we set the audio enable bit in the SDVO/HDMI port register even in SDVO mode. That doesn't really make any sense as SDVO only deals with the video data and the ADD2 card should get the audio data from the HDA bus or via i2s/spdif. Unfortunately I have no proper HDMI capable ADD2 cards to play around with. The one I have seems totally bonkers as it doesn't even respond to the SDVO HDMI opcodes. Also that card has an spdif input connector for audio so I assume it doesn't hang around on the HDA bus.
I don't know if anyone has really ever tried to get SDVO and HDA working together properly.
On Fri, 01 Apr 2016 19:53:05 +0200, Ville Syrjälä wrote:
On Thu, Mar 31, 2016 at 02:45:13PM +0200, Takashi Iwai wrote:
On Thu, 31 Mar 2016 14:30:26 +0200, Ville Syrjälä wrote:
On Wed, Mar 30, 2016 at 05:46:01PM +0200, Takashi Iwai wrote:
This patch fills the holes and now all i915 HDMI/DP codecs are managed over the audio ELD notifier, finally. The old gen3/gen4 chips have usually only a single pin/converter pair, and the digital port mapping is fixed.
Signed-off-by: Takashi Iwai tiwai@suse.de
sound/hda/hdac_i915.c | 11 +++++++++++ sound/pci/hda/patch_hdmi.c | 21 +++++++++++++++------ 2 files changed, 26 insertions(+), 6 deletions(-)
diff --git a/sound/hda/hdac_i915.c b/sound/hda/hdac_i915.c index d0da2508823e..c62a9f830b84 100644 --- a/sound/hda/hdac_i915.c +++ b/sound/hda/hdac_i915.c @@ -128,6 +128,9 @@ EXPORT_SYMBOL_GPL(snd_hdac_get_display_clk);
- Pin Widget 4 - PORT B (port = 1 in i915 driver)
- Pin Widget 5 - PORT C (port = 2 in i915 driver)
- Pin Widget 6 - PORT D (port = 3 in i915 driver)
- on earlier models:
- Pin Widget 3 - PORT B
Hmm. ctg/elk have potentially multiple HDMI ports. Although they only have one video DIP block so can send infoframes only to one of the ports at a time. I wonder how this relates to the audio part, as in does the pin widget 3 always map to the port that is getting infoframes currently? I do have one elk with two HDMI ports here so I could do some experiments if needed.
That's great. I'd like to see how many audio pins are there. Could you take alsa-info.sh snapshot without my patches?
Attached.
Thanks! So it still has only a single audio pin.
If the port switching happens but it's not seen in the audio side, we'd need to record the last active audio port in i915 side and let i915 function taking it (e.g. when port = -1 is passed by callback).
I played around with the machine a bit and HDMI audio works as long as just one of the ports has the audio enable bit set. If the bit is set on multiple ports, there is no audio. Doesn't matter if I drive the ports with the same pipe or two different pipes. Oh, and I just found a note in the spec to confirm this behaviour. I'll need to rework the i915 HDMI code a bit to make this work correctly.
Also I tested sending video related infoframes to one port and audio to the other port, and that also worked. I verified that at least the video infoframes really went to the port I want by having the AVI infoframe indicate YCbCr 4:4:4 while actually sending RGB data, and checking that the colors distorted on the correct port. But I'm not sure if the audio infoframe gets sent to the right port in this case. Since I don't have any HDMI analyzers and such I think I need to try and make a similar expriment with the audio infoframe to see which ports gets it. But that involves reading the spec and some code to find something useful to tweak in the infoframe.
OK, so we'd need to track the active port in anyway, so the necessary change in the audio side seems minimal. At most, some extension of component ops (e.g. allowing to pass port=-1) would be necessary.
*/ static int pin2port(struct hdac_device *codec, hda_nid_t pin_nid) { @@ -139,6 +142,14 @@ static int pin2port(struct hdac_device *codec, hda_nid_t pin_nid) case 0x80862882: /* VLV */ base_nid = 3; break;
- case 0x80862801: /* Bearlake */
Hmm. I wonder if this is bearlake-C or something earlier. BLC doesn't actually exist AFAIK, and earlier bearlake is gen3 and doesn't even support native HDMI output so not sure what this is doing here.
Possibly wrongly named. Looking at the history, it seems to be labeled as "G45 DEVBLC" originally.
Yeah that sounds like the thing that doesn't exist.
Aha, interesting. But keeping it wouldn't hurt so much :)
I only checked Cantiga and Eaglelake, so far.
- case 0x80862802: /* Cantiga */
- case 0x80862803: /* Eaglelake */
- case 0x80862880: /* CedarTrail */
Cedartrail is some powervr atom thing. Should have nothing to do with i915.
Thanks, this one should be removed.
- case 0x808629fb: /* Crestline HDMI */
CL is gen4 and we don't support native HDMI output on those. Strangely enough our spec says CL/BW do support TMDS encoding on the SDVO/HDMI ports and that CL also has the video DIP block and the HDA registers. Not sure what to make of that really.
Hm, OK, in a safer side, we may revert for these entries.
Another interesting mess I noticed is that we set the audio enable bit in the SDVO/HDMI port register even in SDVO mode. That doesn't really make any sense as SDVO only deals with the video data and the ADD2 card should get the audio data from the HDA bus or via i2s/spdif. Unfortunately I have no proper HDMI capable ADD2 cards to play around with. The one I have seems totally bonkers as it doesn't even respond to the SDVO HDMI opcodes. Also that card has an spdif input connector for audio so I assume it doesn't hang around on the HDA bus.
I don't know if anyone has really ever tried to get SDVO and HDA working together properly.
OK, so maybe it's safer to start with only CTG and ELK.
thanks,
Takashi
participants (2)
-
Takashi Iwai -
Ville Syrjälä