similar to: [Bug 67051] New: No nouveau HDMI sound on NVIDIA GT430

Hello all, I'm using gentoo, with kernel 3.17.0-p1-pf and at some point, a patch was included in this branch of the gentoo kernel that broke hdmi audio. I've checked with the latest 3.19 vanilla kernel, and I still have the same problem. I cannot output multichannel sound over hdmi. After some investigations, I've narrowed down the issue to the following lines in the file

Hello Ben, The working kernel code I based my investigation was a 1.3.17 + gentoo patch (so yes, pretty old) The new one below, not working is the vanilla 3.19 (from the gentoo repo, should be identical to the latest 3.19 stable) I've narrowed down the issue to the size of the eld. The new patch (that indeed uses drm_eld_size) (with this patch, I have a working 3.19 kernel): I will need to

Since the commit 742db30c4ee6 ("drm/nouveau: Add HD-audio component notifier support"), the nouveau driver notifies and pokes the HD-audio HPD and ELD via audio component, but this seems broken. The culprit is the naive assumption that crtc->index corresponds to the HDA pin. Actually this rather corresponds to the MST dev_id (alias "pipe" in the audio component framework)

Store the ELD correctly, not just enough copies of the first byte to pad out the given ELD size. Signed-off-by: Alastair Bridgewater <alastair.bridgewater at gmail.com> --- drivers/gpu/drm/nouveau/nvkm/engine/disp/hdagt215.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/hdagt215.c

The following commit from about a year ago removed nouveau_dp_dpms() which did steps required to suspend and resume a monitor connected via DisplayPort. commit 0a0afd282fd715dd63d64b243299a64da14f8e8d Author: Ben Skeggs <bskeggs at redhat.com> Date: Mon Feb 18 23:17:53 2013 -0500 drm/nv50-/disp: move DP link training to core and train from supervisor My computer with

After a full device powerdown via the optimus power switch, we seem to lose the HDMI device completely on power on, this keep track of whether we had a hdmi audio sub function device at power on, and pokes a magic register to make it reappear after the optimus power switch is thrown. This at least works on my NVC4 machine, probably needs testing on a few other laptops with other nvidia GPUs.

So... I was wondering what the impact of splitting up the card compilation by e.g. generation would be. Depending on the split things would get fairly intertwined, so I thought I'd start small. This just splits NVC0 from everything else. I figure that for the people this matters the most to, NVC0 is the least relevant card -- people with sub-1GB of RAM, older hardware. With my config options

https://bugs.freedesktop.org/show_bug.cgi?id=32406 Summary: nouveau fails to send hotplug event to ALSA hda hdmi audio Product: xorg Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Driver/nouveau AssignedTo: nouveau

On 5 May 2014 01:43, Ben Skeggs <skeggsb at gmail.com> wrote: > On Mon, May 5, 2014 at 4:48 AM, Sergei Antonov <saproj at gmail.com> wrote: >> The following commit from about a year ago removed nouveau_dp_dpms() which >> did steps required to suspend and resume a monitor connected via DisplayPort. >> >> commit 0a0afd282fd715dd63d64b243299a64da14f8e8d

Hi Ben, The below patch from Jani also touches nouveau, can you please take a look at it an ack? The core part + nouveau apply on top of drm-next, the i915 part needs stuff from my next queue. So I'd prefer if we can get this in through drm-intel-next. Hi Dave, Ack on that from your side? Cheers, Daniel On Tue, Oct 28, 2014 at 3:20 PM, Jani Nikula <jani.nikula at intel.com> wrote:

On Fri, Aug 3, 2018 at 8:19 AM, Karol Herbst <kherbst at redhat.com> wrote: > v2: clean up left over comments > don't overwrite hdmimhz parameter > cap to 297MHz > > Signed-off-by: Karol Herbst <kherbst at redhat.com> > --- > drm/nouveau/dispnv50/disp.c | 5 +++++ > drm/nouveau/nouveau_connector.c | 15 ++++++++++----- >

From: Ville Syrjälä <ville.syrjala at linux.intel.com> Make life easier for drivers by simply passing the connector to drm_hdmi_avi_infoframe_from_display_mode() and drm_hdmi_avi_infoframe_quant_range(). That way drivers don't need to worry about is_hdmi2_sink mess. Cc: Alex Deucher <alexander.deucher at amd.com> Cc: "Christian König" <christian.koenig at amd.com>

These patches are adding support for outputting 2560x1440 at 56 over HDMI. This needs a pixel clock of 225 MHz which was not supported before. This was tested in a dual monitor setup with a GF114 (GTX 560 TI) and one HDMI monitor running with 2560x1440 at 56 and one DVI monitor running with 1920x1200 at 60. This still needs testing on other graphics cards and with dual link DVI. There is no

This is the beginnings of HDMI 2.0 support. All of the "extra" features are left out, such as 12/16bpc, YUV420, etc. I've verified that with this code, a GP108 (GT1030) can switch between 4k at 60 and 1920x1080 at 60 on a LG 4K TV. Further, I've verified via i2c tools, that the SCDC writes really do happen. I suspect that the patch for keeping track of the high-speed TMDS

This is an initial implementation of HDMI 3D mode support for the nouveau kernel driver. It works on all of the hardware that I have available to test at the moment, but I am unsure as to the overall approach taken for setting HDMI InfoFrames, there's no support for g84 or gf119 disps, and the criteria for enabling stereo support for an output seems a bit iffy. The first four patches arrange

Enable stereoscopic output for HDMI and DisplayPort connectors on NV50+ (G80+) hardware. We do not enable stereoscopy on older hardware in case there is some older board that still has HDMI output but for which we have no logic for setting the Vendor InfoFrame. With this, I get an obvious 3D output when using the "testdisplay" program from intel-gpu-tools with the "-3"

Prior to this change, some screen models would display a 2px-large purple line along left screen border, likely to complain about invalid InfoFrame content. The following bug report seems to trigger this issue: https://bugs.freedesktop.org/show_bug.cgi?id=75203 Running mmiotrace on a GTX 650 (GK107) produces the following trace, regardless of which output is used (HDMI-1, DVI-D-1, DVI-D-2), to

From: Hauke Mehrtens <hauke at hauke-m.de> Without this patch a pixel clock rate above 165 MHz on a TMDS link is assumed to be dual link. This is true for DVI, but not for HDMI. HDMI supports no dual link, but it supports pixel clock rates above 165 MHz. Only activate Dual Link mode when it is actual possible. Signed-off-by: Hauke Mehrtens <hauke at hauke-m.de> Signed-off-by: Ilia

This removes user control to force a hdmimhz. Given the vast variety of hardware and display configurations out there, I don't see how a patch like this won't blow up in our faces. I'm not saying we shouldn't do it -- we should attempt to respect the various maximums in the vbios, but until we get a solid handle on things, we should allow more user-configurability, not less, for

small update to my last version I sent out. Patches 3-6 are optional and should only improve detecting the max clocks for HDMI and DP, but they didn't underwent big testing and I am a bit concerned, that it might break detecting the DP limits on some boards. Karol Herbst (6): kms/nv50: move nv50_mstm out of the dp union in nouveau_encoder kms/nv50: reject interlaced modes if the hardware