similar to: [PATCH AUTOSEL 5.7 314/388] drm/nouveau/disp/gm200-: fix NV_PDISP_SOR_HDMI2_CTRL(n) selection

From: Ben Skeggs <bskeggs at redhat.com> [ Upstream commit a1ef8bad506e4ffa0c57ac5f8cb99ab5cbc3b1fc ] This is a SOR register, and not indexed by the bound head. Fixes display not coming up on high-bandwidth HDMI displays under a number of configurations. Signed-off-by: Ben Skeggs <bskeggs at redhat.com> Signed-off-by: Sasha Levin <sashal at kernel.org> ---

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

Hi James, I semi-recently added support for HDMI 2.0 (in 4.20+, so you're good), which is why you got 60Hz in the first place. In order for the high rates to work, something called "scrambling" must be enabled. This is done by 2-party agreement between the sink and the source. The sink will inform the source that it's about to use scrambling (by writing to the SCDC register on

On 2019-08-06 12:32 p.m., Ilia Mirkin wrote: > Hi James, > > I semi-recently added support for HDMI 2.0 (in 4.20+, so you're good), > which is why you got 60Hz in the first place. In order for the high > rates to work, something called "scrambling" must be enabled. This is > done by 2-party agreement between the sink and the source. The sink > will inform the

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. v2: Make is_hdmi2_sink() return true for sil-sii8620 Adapt to omap/vc4 changes Cc: Alex Deucher

On Tue, 20 Nov 2018, Ville Syrjala <ville.syrjala at linux.intel.com> wrote: > 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. Overall

Can you try something very simple - unplug the cable, and plug it back in, while the TV is on, and set to the HDMI input? That should ensure that the SCDC write can go through at modeset time. You can also force nouveau to avoid any modes that require scrambling by booting with nouveau.hdmimhz=340. Cheers, -ilia On Tue, Aug 6, 2019 at 1:15 PM James <bjlockie at lockie.ca> wrote: >

On August 6, 2019 1:36:09 p.m. Ilia Mirkin <imirkin at alum.mit.edu> wrote: > Can you try something very simple - unplug the cable, and plug it back > in, while the TV is on, and set to the HDMI input? I still only get 30Hz. I did just update the tv firmware s9 maybe that is why I can't get it 60Hz anymore. I wish I kept better track of the timeline. With the new HDMI 2 cable I

Both Coverity and GCC with -Wstringop-overflow noticed that nvif_outp_acquire_dp() accidentally defined its second argument with 1 additional element: drivers/gpu/drm/nouveau/dispnv50/disp.c: In function 'nv50_pior_atomic_enable': drivers/gpu/drm/nouveau/dispnv50/disp.c:1813:17: error: 'nvif_outp_acquire_dp' accessing 16 bytes in a region of size 15 [-Werror=stringop-overflow=]

Sorry! I've been pretty busy until now, this is: Reviewed-by: Lyude Paul <lyude at redhat.com> Let me know if you've pushed it already or if you want me to push it to drm- misc On Wed, 2023-01-25 at 12:15 -0800, Kees Cook wrote: > Ping. I'll take this via my tree unless someone else wants to take it... > > On Sun, Nov 27, 2022 at 10:30:41AM -0800, Kees Cook wrote:

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>

Despite being an atomic driver, nouveau has a lot of leftover code that relies on retrieving information regarding the new atomic state from members of drm_encoder and drm_crtc. The first field being used, drm_encoder.crtc, is deprecated for atomic drivers. The second field being used is drm_crtc.state, which is only really sensible to use outside of an atomic modeset. So, add some helpers to

Use nvkm_memory_target() to know the location of the instance block used for secure boot, instead of guessing through the presence of a RAM device. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- Ben, feel free to squash this one into the original secboot patch since it is a really minor fix. drm/nouveau/nvkm/subdev/secboot/gm200.c | 2 +- 1 file changed, 1 insertion(+), 1

The state of the falcons was not properly updated after running the unload ACR, which caused it to be run again (and thus fail) when nvkm_secboot_fini() was called during resume. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- Ben, please feel free to squash this into the gm200 secboot implementation patch - this fixes a bug that should not have been here to begin with.

From: Ben Skeggs <bskeggs at redhat.com> [ Upstream commit 7adc77aa0e11f25b0e762859219c70852cd8d56f ] Method init is typically ordered by class in the FW image as ThreeD, TwoD, Compute. Due to a bug in parsing the FW into our internal format, we've been accidentally sending Twod + Compute methods to the ThreeD class, as well as Compute methods to the TwoD class - oops. Signed-off-by:

From: Ben Skeggs <bskeggs at redhat.com> [ Upstream commit 7adc77aa0e11f25b0e762859219c70852cd8d56f ] Method init is typically ordered by class in the FW image as ThreeD, TwoD, Compute. Due to a bug in parsing the FW into our internal format, we've been accidentally sending Twod + Compute methods to the ThreeD class, as well as Compute methods to the TwoD class - oops. Signed-off-by:

From: Ben Skeggs <bskeggs at redhat.com> [ Upstream commit 7adc77aa0e11f25b0e762859219c70852cd8d56f ] Method init is typically ordered by class in the FW image as ThreeD, TwoD, Compute. Due to a bug in parsing the FW into our internal format, we've been accidentally sending Twod + Compute methods to the ThreeD class, as well as Compute methods to the TwoD class - oops. Signed-off-by:

From: Ben Skeggs <bskeggs at redhat.com> [ Upstream commit 7adc77aa0e11f25b0e762859219c70852cd8d56f ] Method init is typically ordered by class in the FW image as ThreeD, TwoD, Compute. Due to a bug in parsing the FW into our internal format, we've been accidentally sending Twod + Compute methods to the ThreeD class, as well as Compute methods to the TwoD class - oops. Signed-off-by:

From: Ben Skeggs <bskeggs at redhat.com> [ Upstream commit 7adc77aa0e11f25b0e762859219c70852cd8d56f ] Method init is typically ordered by class in the FW image as ThreeD, TwoD, Compute. Due to a bug in parsing the FW into our internal format, we've been accidentally sending Twod + Compute methods to the ThreeD class, as well as Compute methods to the TwoD class - oops. Signed-off-by:

This allows temperature readouts on maxwell2 GPUs. Signed-off-by: Karol Herbst <karolherbst at gmail.com> --- drm/nouveau/include/nvkm/subdev/therm.h | 1 + drm/nouveau/nvkm/engine/device/base.c | 3 +++ drm/nouveau/nvkm/subdev/therm/Kbuild | 1 + drm/nouveau/nvkm/subdev/therm/g84.c | 2 +- drm/nouveau/nvkm/subdev/therm/gm200.c | 39 +++++++++++++++++++++++++++++++++