similar to: [PATCH] drm/nouveau/kms: Remove set but not used 'ret'

On Tue, 2020-09-22 at 17:25 +0800, Tian Tao wrote: > This addresses the following gcc warning with "make W=1": > drivers/gpu/drm/nouveau/dispnv50/disp.c: In function ?nv50_mstm_prepare?: > drivers/gpu/drm/nouveau/dispnv50/disp.c:1378:6: warning: > variable ?ret? set but not used [-Wunused-but-set-variable] > > Signed-off-by: Tian Tao <tiantao6 at hisilicon.com>

This addresses the following gcc warning with "make W=1": drivers/gpu/drm/nouveau/dispnv50/disp.c: In function ?nv50_mstm_prepare?: drivers/gpu/drm/nouveau/dispnv50/disp.c:1378:6: warning: variable ?ret? set but not used [-Wunused-but-set-variable] Signed-off-by: Tian Tao <tiantao6 at hisilicon.com> Reviewed-by: Lyude Paul <lyude at redhat.com> --- v2:Remove the braces

Fixes gcc '-Wunused-but-set-variable' warning: drivers/gpu/drm/nouveau/dispnv50/disp.c: In function nv50_mstm_cleanup: drivers/gpu/drm/nouveau/dispnv50/disp.c:1303:6: warning: variable ?ret? set but not used [-Wunused-but-set-variable] drivers/gpu/drm/nouveau/dispnv50/disp.c: In function nv50_mstm_prepare: drivers/gpu/drm/nouveau/dispnv50/disp.c:1327:6: warning: variable ?ret? set but

nv50_msto_disable() does not call nv50_outp_release() to match nv50_outp_acquire() like other disable(). Add the missed call to fix it. Signed-off-by: Chuhong Yuan <hslester96 at gmail.com> --- drivers/gpu/drm/nouveau/dispnv50/disp.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c b/drivers/gpu/drm/nouveau/dispnv50/disp.c index

This is mainly for dropping interlaced modes on DP connectors if the GPU would otherwise display garbage or EVO timesout. It also adds experimental detection of the HDMI clock limit we currently hard limit depending on the GPU generation. Starting with GF110 GPUs, we can retrieve the limit directly from the GPU and may make the hdmimhz parameter obsolete. Testing this series with 2560x1440 or

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

fixed the following warnings drivers/gpu/drm/nouveau/nouveau_bo.c:1227:17: warning: variable ?dev? set but not used [-Wunused-but-set-variable] drivers/gpu/drm/nouveau/nouveau_bo.c:1251:17: warning: variable ?dev? set but not used [-Wunused-but-set-variable] Signed-off-by: Tian Tao <tiantao6 at hisilicon.com> --- drivers/gpu/drm/nouveau/nouveau_bo.c | 2 -- 1 file changed, 2 deletions(-)

So we don't ever have to worry about drivers touching drm_dp_mst_port structs without verifying them and crashing again. Lyude Paul (6): drm/dp_mst: Add drm_dp_get_payload_info() drm/nouveau: Use drm_dp_get_payload_info() for getting payload/vcpi drm/nouveau: Stop reading port->mgr in nv50_mstc_get_modes() drm/nouveau: Stop reading port->mgr in nv50_mstc_detect() drm/dp_mst:

Hi folks, Currently, when the device is removed (or the driver is unbound) the nouveau_drm structure de-allocated. However, it's still accessible from and used by some DRM layer callbacks. For example, file handles can be closed after the device has been removed (physically or otherwise). This series converts the Nouveau device structure to be allocated and de-allocated with the

This hooks up the DRM helpers for dumping information on the current status of each MST topology from nouveau's perspective to debugfs files, similar to what i915 does (albeit, i915 labels their debugfs node for this as i915_dp_mst_info). Lyude Paul (2): drm/nouveau: Expose nv50 MST structures in disp.h drm/nouveau: Hook up dp_mst_info in debugfs drivers/gpu/drm/nouveau/dispnv50/disp.c

From: Colin Ian King <colin.king at canonical.com> The check to see if mstm->msto is null is redundant because it is an array and hence can never be null. Remove the redundant check. Detected by CoverityScan, CID#1375915 ("Array compared against 0") Signed-off-by: Colin Ian King <colin.king at canonical.com> --- drivers/gpu/drm/nouveau/nv50_display.c | 2 +- 1 file

From: Colin Ian King <colin.king at canonical.com> The null check on the array msto is incorrect since msto is never null. The null check should be instead on msto[i] since this is being dereferenced in the call to drm_mode_connector_attach_encoder. Thanks to Emil Velikov for pointing out the mistake in my original fix and for suggesting the correct fix. Detected by CoverityScan,

On 17/08/17 23:07, Ilia Mirkin wrote: > On Thu, Aug 17, 2017 at 6:03 PM, Colin King <colin.king at canonical.com> wrote: >> From: Colin Ian King <colin.king at canonical.com> >> >> The null check on the array msto is incorrect since msto is never >> null. The null check should be instead on msto[i] since this is >> being dereferenced in the call to

Currently, nouveau tries to go through the drm_dp_mst_port structures itself in order to retrieve the relevant payload and VCPI information that it needs to report to the GPU. This is wrong: mstc->port could be destroyed at any point, and additionally the payload could be changed at any point because it doesn't bother trying to grab the payload lock. So; remove nv50_msto_payload entirely

[sorry about the resend-copy pasted the wrong header and I want to make sure this doesn't get missed!] This patchset does some cleaning up of the atomic VCPI helpers for MST, and converts nouveau over to using them. I would have included amdgpu in this patch as well, but at the moment moving them over to the atomic helpers is nontrivial. Cc: Daniel Vetter <daniel at ffwll.ch> Lyude

This patchset does some cleaning up of the atomic VCPI helpers for MST, and converts nouveau over to using them. I would have included amdgpu in this patch as well, but at the moment moving them over to the atomic helpers is nontrivial. Cc: Daniel Vetter <daniel at ffwll.ch> Lyude Paul (5): drm/dp_mst: Add some atomic state iterator macros drm/dp_mst: Start tracking per-port VCPI

This patchset does some cleaning up of the atomic VCPI helpers for MST, and converts nouveau over to using them. I would have included amdgpu in this patch as well, but at the moment moving them over to the atomic helpers is nontrivial. Cc: Daniel Vetter <daniel at ffwll.ch> Lyude Paul (5): drm/dp_mst: Add some atomic state iterator macros drm/dp_mst: Start tracking per-port VCPI

Hi Bastian, Ian, while I was working on the recent batch of security updates I noticed that the obvious backport of the related patch caused an HVM guest to be crashed as soon as a user inside that guest tried to ptrace a child process. While talking to Jan, I realized that in 4.2 the inject exception code subtly changed in a way that treats TRAP_debug as a HW event (that is triggered by no

On Tue, Sep 03, 2019 at 04:46:03PM -0400, Lyude Paul wrote: > Finally! For a very long time, our MST helpers have had one very > annoying issue: They don't know how to reprobe the topology state when > coming out of suspend. This means that if a user has a machine connected > to an MST topology and decides to suspend their machine, we lose all > topology changes that happened

[ Upstream commit b513a18cf1d705bd04efd91c417e79e4938be093 ] This is much louder then we want. VCPI allocation failures are quite normal, since they will happen if any part of the modesetting process is interrupted by removing the DP MST topology in question. So just print a debugging message on VCPI failures instead. Signed-off-by: Lyude Paul <lyude at redhat.com> Fixes: f479c0ba4a17