similar to: [PATCH AUTOSEL 5.5 494/542] 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

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 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

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 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

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

From: Colin Ian King <colin.king at canonical.com> [ Upstream commit f42e4b337b327b1336c978c4b5174990a25f68a0 ] The sizeof is currently on args.src and args.dst and should be on *args.src and *args.dst. Fortunately these sizes just so happen to be the same size so it worked, however, this should be fixed and it also cleans up static analysis warnings Addresses-Coverity: ("sizeof not

From: Dan Carpenter <dan.carpenter at oracle.com> [ Upstream commit 3613a9bea95a1470dd42e4ed1cc7d86ebe0a2dc0 ] We accidentally set "psb" which is a no-op instead of "*psb" so it generates a static checker warning. We should probably set it before the first error return so that it's always initialized. Fixes: 923f1bd27bf1 ("drm/nouveau/secboot/gm20b: add

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: