Displaying 20 results from an estimated 1100 matches similar to: "[bug report] drm/nouveau/disp/nv50-: add channel interfaces to control error interrupts"
2018 May 27
1
[PATCH][next] drm/nouveau/disp: avoid potential overflow on shift of int value
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
2018 Jul 03
1
[bug report] drm/nouveau/disp/nv50-: add channel interfaces to control error interrupts
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/changf119.c:55 gf119_disp_chan_intr()
warn: should '1 << chan->chid.user' be a 64 bit type?
2020 Feb 08
2
[PATCH] nv50_disp_chan_mthd: ensure mthd is not NULL
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
2018 Aug 20
3
[PATCH 0/2] drm/nouveau: Fix GM107 disp init failures on ThinkPad P50
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 +++++++++++++++++--
2020 Feb 20
1
[PATCH] nv50_disp_chan_mthd: ensure mthd is not NULL
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>
2020 Jan 29
1
nv50_disp_chan_mthd: ensure mthd is not NULL
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
[PATCH AUTOSEL 5.5 494/542] drm/nouveau/disp/nv50-: prevent oops when no channel method map provided
2020 Feb 14
0
[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
[PATCH AUTOSEL 5.4 424/459] drm/nouveau/disp/nv50-: prevent oops when no channel method map provided
2020 Feb 14
0
[PATCH AUTOSEL 5.4 424/459] 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
2020 Feb 14
0
[PATCH AUTOSEL 4.19 232/252] 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
2020 Feb 14
0
[PATCH AUTOSEL 4.14 170/186] 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
[PATCH AUTOSEL 4.9 127/141] drm/nouveau/disp/nv50-: prevent oops when no channel method map provided
2020 Feb 14
0
[PATCH AUTOSEL 4.9 127/141] 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
[PATCH AUTOSEL 4.4 090/100] drm/nouveau/disp/nv50-: prevent oops when no channel method map provided
2020 Feb 14
0
[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
2016 Oct 24
1
[PATCH v2 1/2] drm/nouveau: add missing header dependencies
We get a few warnings when building kernel with W=1:
drivers/gpu/drm/nouveau/nvkm/core/firmware.c:34:1: warning: no previous prototype for 'nvkm_firmware_get' [-Wmissing-prototypes]
drivers/gpu/drm/nouveau/nvkm/core/firmware.c:58:1: warning: no previous prototype for 'nvkm_firmware_put' [-Wmissing-prototypes]
drivers/gpu/drm/nouveau/nvkm/subdev/fb/sddr3.c:69:1: warning: no previous
2016 Oct 22
18
[PATCH 01/17] drm/nouveau/core: add missing header dependencies
We get 2 warnings when building kernel with W=1:
drivers/gpu/drm/nouveau/nvkm/core/firmware.c:34:1: warning: no previous prototype for 'nvkm_firmware_get' [-Wmissing-prototypes]
drivers/gpu/drm/nouveau/nvkm/core/firmware.c:58:1: warning: no previous prototype for 'nvkm_firmware_put' [-Wmissing-prototypes]
In fact, these functions are declared in
2018 Aug 20
0
[PATCH 2/2] drm/nouveau: Fix GM107 disp dmac chan init on ThinkPad P50
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
[
2020 Jan 30
0
nv50_disp_chan_mthd: ensure mthd is not NULL
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
2020 Feb 20
0
[PATCH] nv50_disp_chan_mthd: ensure mthd is not NULL
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'
2016 Sep 25
0
[PATCH 2/3] drm/nouveau: mark symbols static where possible
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
2017 Feb 19
8
[Bug 99858] New: disp: ERROR 4 [INVALID_VALUE] 84 chid 0 mthd 0828 data 000099bb
https://bugs.freedesktop.org/show_bug.cgi?id=99858
Bug ID: 99858
Summary: disp: ERROR 4 [INVALID_VALUE] 84 [] chid 0 mthd 0828
data 000099bb
Product: xorg
Version: unspecified
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity: normal
Priority: medium
2012 Dec 05
2
[RFC PATCH] drm/nouveau: report channel owner in error messages
Full piglit run with this patch:
http://people.freedesktop.org/~mslusarz/chan_owners.txt
This patch covers only a small subset of all error messages, so:
Not-yet-signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com>
Comments? Ideas?
(This commit depends on this one:
http://people.freedesktop.org/~mslusarz/0001-drm-nouveau-split-fifo-interrupt-handler.patch )
---