similar to: [PATCH AUTOSEL 4.4 090/100] drm/nouveau/disp/nv50-: prevent oops when no channel method map provided

From: Ben Skeggs <bskeggs at redhat.com> [ Upstream commit 0e6176c6d286316e9431b4f695940cfac4ffe6c2 ] The implementations for most channel types contains a map of methods to priv registers in order to provide debugging info when a disp exception has been raised. This info is missing from the implementation of PIO channels as they're rather simplistic already, however, if an exception

From: Ben Skeggs <bskeggs at redhat.com> [ Upstream commit 0e6176c6d286316e9431b4f695940cfac4ffe6c2 ] The implementations for most channel types contains a map of methods to priv registers in order to provide debugging info when a disp exception has been raised. This info is missing from the implementation of PIO channels as they're rather simplistic already, however, if an exception

From: Ben Skeggs <bskeggs at redhat.com> [ Upstream commit 0e6176c6d286316e9431b4f695940cfac4ffe6c2 ] The implementations for most channel types contains a map of methods to priv registers in order to provide debugging info when a disp exception has been raised. This info is missing from the implementation of PIO channels as they're rather simplistic already, however, if an exception

From: Ben Skeggs <bskeggs at redhat.com> [ Upstream commit 0e6176c6d286316e9431b4f695940cfac4ffe6c2 ] The implementations for most channel types contains a map of methods to priv registers in order to provide debugging info when a disp exception has been raised. This info is missing from the implementation of PIO channels as they're rather simplistic already, however, if an exception

From: Ben Skeggs <bskeggs at redhat.com> [ Upstream commit 0e6176c6d286316e9431b4f695940cfac4ffe6c2 ] The implementations for most channel types contains a map of methods to priv registers in order to provide debugging info when a disp exception has been raised. This info is missing from the implementation of PIO channels as they're rather simplistic already, however, if an exception

Hi Fr?d?ric, It appears Ben made his own version of this patch (probably based on the one you added to the kernel bz), and it's already upstream: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.6-rc2&id=0e6176c6d286316e9431b4f695940cfac4ffe6c2 Cheers, -ilia On Thu, Feb 20, 2020 at 12:19 PM Fr?d?ric Pierret <frederic.pierret at qubes-os.org>

Pointer to structure array is assumed not NULL by default. It has the consequence to raise a kernel panic when it's not the case. Basically, running at least a RTX2080TI on Xen makes a bad mmio error which causes having 'mthd' pointer to be NULL in 'channv50.c'. From the code, it's assumed to be not NULL by accessing directly 'mthd->data[0]' which is the reason

On Wed, Jan 29, 2020 at 05:22:13PM +0100, Fr?d?ric Pierret wrote: > Dear Ben Skeggs, > > Please find attached a patch solving a blocking issue I encountered: > https://bugzilla.kernel.org/show_bug.cgi?id=206299 > > Basically, running at least a RTX2080TI on Xen makes a bad mmio error > which causes having 'mthd' pointer to be NULL in 'channv50.c'. From the

Hi, Is anything missing here? How can I get this merged? Best regards, Fr?d?ric Pierret On 2020-02-08 20:43, Fr?d?ric Pierret wrote: > Pointer to structure array is assumed not NULL by default. It has > the consequence to raise a kernel panic when it's not the case. > > Basically, running at least a RTX2080TI on Xen makes a bad mmio error > which causes having 'mthd'

Dear Ben Skeggs, Please find attached a patch solving a blocking issue I encountered: https://bugzilla.kernel.org/show_bug.cgi?id=206299 Basically, running at least a RTX2080TI on Xen makes a bad mmio error which causes having 'mthd' pointer to be NULL in 'channv50.c'. From the code, it's assumed to be not NULL by accessing directly 'mthd->data[0]' which is the

From: Colin Ian King <colin.king at canonical.com> The constant values being shifted are 32 bit integers and may potentially overflow on the shift. Avoid this potential overflow by making them unsigned long long values before the shift. Detected by CoverityScan, CID#1469383, 1469400 ("Unintentional integer overflow") Signed-off-by: Colin Ian King <colin.king at

Just like how the P50 will occasionally leave the disp's core channel on before nouveau starts initializing, it will occasionally do the same thing with the rest of the dmac channel in addition to the core channel. Example: [ 1.604375] nouveau 0000:01:00.0: disp: outp 04:0006:0f81: no heads (0 3 4) [ 1.604858] nouveau 0000:01:00.0: disp: outp 04:0006:0f81: aux power -> always [

We get a few warnings when building kernel with W=1: drivers/gpu/drm/nouveau/nvkm/subdev/bios/fan.c:29:1: warning: no previous prototype for 'nvbios_fan_table' [-Wmissing-prototypes] drivers/gpu/drm/nouveau/nvkm/subdev/clk/gt215.c:184:1: warning: no previous prototype for 'gt215_clk_info' [-Wmissing-prototypes] drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgt215.c:153:1: warning: no

Hello Ben Skeggs, The patch a9c44a88ca2f: "drm/nouveau/disp/nv50-: add channel interfaces to control error interrupts" from May 8, 2018, leads to the following static checker warning: drivers/gpu/drm/nouveau/nvkm/engine/disp/channv50.c:169 nv50_disp_chan_intr() warn: should '65537 << chan->chid.user' be a 64 bit type?

We get some warnings when building kernel with W=1: drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf117.c:222:1: warning: no previous prototype for 'gf117_grctx_generate_main' [-Wmissing-prototypes] drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxnv50.c:255:1: warning: no previous prototype for 'nv50_grctx_fill' [-Wmissing-prototypes] drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxnv50.c:265:1:

On Thu, Feb 2, 2017 at 5:09 PM, Phil Turmel <philip at turmel.org> wrote: > On 02/02/2017 05:01 PM, Ilia Mirkin wrote: > >> Note that a lot of this stuff has been redone for kernel 4.10 to >> conform to atomic modesetting. I wouldn't be surprised if that >> jiggers things around enough to fix your issue. But perhaps not. >> Worth a shot. [As an aside, this

From: Thierry Reding <treding at nvidia.com> [ Upstream commit 21454fe697fde188ad6fb541f94b9838fa73ab38 ] Tegra firmware doesn't actually use any version numbers and passing -1 causes the existing firmware binaries not to be found. Use version 0 to find the correct files. Fixes: ef16dc278ec2 ("drm/nouveau/gr/gf100-: select implementation based on available FW")

GP102's cursors go from chan 17..20. Increase the array size to hold their data properly. Fixes: e50fcff15f ("drm/nouveau/disp/gp102: fix cursor/overlay immediate channel indices") Cc: stable at vger.kernel.org # v4.10+ Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- drm/nouveau/nvkm/engine/disp/nv50.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

This series fixes some intermittent issues with bringing up the dedicated GM107 GPU that I've been observing on my ThinkPad P50. More details within. Lyude Paul (2): drm/nouveau: Fix GM107 disp core chan init on ThinkPad P50 drm/nouveau: Fix GM107 disp dmac chan init on ThinkPad P50 .../drm/nouveau/nvkm/engine/disp/coregf119.c | 21 +++++++++++++++++--

The following functions are not declared outside of the file they are in, so make them static to avoid these warnings: drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c:745:1: warning: symbol 'gf100_gr_fecs_start_ctxsw' was not declared. Should it be static? drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c:760:1: warning: symbol 'gf100_gr_fecs_stop_ctxsw' was not declared. Should it be