From: Dave Airlie
When a buffer is evicted for memory pressure or TTM evict all,
the placement is set to the eviction domain, this means the
buffer never gets revalidated on the next exec to the correct domain.
I think this should be fine to use the initial domain from the
object creation
From: Dave Airlie
When a buffer is evicted for memory pressure or TTM evict all,
the placement is set to the eviction domain, this means the
buffer never gets revalidated on the next exec to the correct domain.
I think this should be fine to use the initial domain from the
object creation
From: Dave Airlie
Currently, enabling SG_DEBUG in the kernel will cause nouveau to hit a
BUG() on startup, when the iommu is enabled:
kernel BUG at include/linux/scatterlist.h:187!
invalid opcode: [#1] PREEMPT SMP NOPTI
CPU: 7 PID: 930 Comm: (udev-worker) Not tainted 6.9.0-rc3Lyude-Test
From: Dave Airlie
Currently, enabling SG_DEBUG in the kernel will cause nouveau to hit a
BUG() on startup, when the iommu is enabled:
kernel BUG at include/linux/scatterlist.h:187!
invalid opcode: [#1] PREEMPT SMP NOPTI
CPU: 7 PID: 930 Comm: (udev-worker) Not tainted 6.9.0-rc3Lyude-Test
rogramming for DP
Daniele Ceraolo Spurio (1):
drm/xe/guc: Check error code when initializing the CT mutex
Dave Airlie (5):
Merge tag 'drm-intel-fixes-2024-05-08' of
https://anongit.freedesktop.org/git/drm/drm-intel into drm-fixes
Merge tag 'drm-xe-fixes-2024-05-09
On Thu, 9 May 2024 at 09:00, Alex Deucher wrote:
>
> Hi Dave, Sima,
>
> Fixes for 6.9.
>
> The following changes since commit dd5a440a31fae6e459c0d627162825505361:
>
> Linux 6.9-rc7 (2024-05-05 14:06:01 -0700)
>
> are available in the Git repository at:
>
>
On Thu, 9 May 2024 at 09:00, Alex Deucher wrote:
>
> Hi Dave, Sima,
>
> Fixes for 6.9.
>
> The following changes since commit dd5a440a31fae6e459c0d627162825505361:
>
> Linux 6.9-rc7 (2024-05-05 14:06:01 -0700)
>
> are available in the Git repository at:
>
>
> Let me know if this understanding is correct.
>
> Or what would you like to do in such situation?
>
> >
> > Not sure how it is really a good idea.
> >
> > Adaptive locality of memory is still an unsolved problem in Linux,
> > sadly.
> >
> > > > However, the migration stuff should really not be
fix the call oder in amdgpu_ttm_move() v2
Dave Airlie (3):
Merge tag 'amd-drm-fixes-6.9-2024-05-01' of
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes
Merge tag 'drm-xe-fixes-2024-05-02' of
https://gitlab.freedesktop.org/drm/xe/kernel into drm-fixes
Merge tag 'drm-misc
> Currently, this can result in runtime PM issues on systems where memory
> Luckily, we don't actually need to allocate coherent memory for the page
> table thanks to being able to pass the GPU a radix3 page table for
> suspend/resume data. So, let's rewrite nvkm_gsp_radix3_sg() to use the sg
>
> Currently, this can result in runtime PM issues on systems where memory
> Luckily, we don't actually need to allocate coherent memory for the page
> table thanks to being able to pass the GPU a radix3 page table for
> suspend/resume data. So, let's rewrite nvkm_gsp_radix3_sg() to use the sg
>
This looks like a good start, though I wonder can we just refactor out
the common code from the vma and non-vma paths easier.
Also I wonder should we add a new GETPARAM so userspace can know this
change is available.
Of course we also need a pointer to the userspace implementation to
move
allocations
- Fix PF/VF relay messages
Alex Deucher (1):
drm/amdgpu/sdma5.2: use legacy HDP flush for SDMA2/3
Christian Gmeiner (1):
Revert "drm/etnaviv: Expose a few more chipspecs to userspace"
Dave Airlie (4):
: remove invalid resource->start check v2
drm/amdgpu: fix visible VRAM handling during faults
Dave Airlie (4):
nouveau: fix instmem race condition around ptr stores
Merge tag 'amd-drm-fixes-6.9-2024-04-17' of
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes
Merge tag '
From: Dave Airlie
I'm pretty sure this optimisation is actually not a great idea,
and is racy with other things waiting for fences.
Just nuke it, there should be no need to do fence waits in a
busy CPU loop.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/nouveau/nouveau_bo.c| 2
From: Dave Airlie
I'm pretty sure this optimisation is actually not a great idea,
and is racy with other things waiting for fences.
Just nuke it, there should be no need to do fence waits in a
busy CPU loop.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/nouveau/nouveau_bo.c| 2
On Wed, 17 Apr 2024 at 10:57, Ben Skeggs wrote:
>
> This is a series of cleanups that I intended on doing after posting
> the initial GSP-RM support several months ago, and have now had the
> opportunity to work on again.
>
> The main intention here is to replace the ioctl-like interface that
>
On Thu, 11 Apr 2024 at 17:32, Arnd Bergmann wrote:
>
> On Thu, Apr 11, 2024, at 09:15, Ard Biesheuvel wrote:
> > On Thu, 11 Apr 2024 at 03:11, Samuel Holland
> > wrote:
> >> On 2024-04-10 8:02 PM, Thiago Jung Bauermann wrote:
> >> > Samuel Holland writes:
> >>
> >> >> The short-term fix would
On Thu, 11 Apr 2024 at 17:32, Arnd Bergmann wrote:
>
> On Thu, Apr 11, 2024, at 09:15, Ard Biesheuvel wrote:
> > On Thu, 11 Apr 2024 at 03:11, Samuel Holland
> > wrote:
> >> On 2024-04-10 8:02 PM, Thiago Jung Bauermann wrote:
> >> > Samuel Holland writes:
> >>
> >> >> The short-term fix would
path in panfrost_mmu_map_fault_addr()
Dave Airlie (6):
Merge tag 'drm-intel-fixes-2024-04-10' of
https://anongit.freedesktop.org/git/drm/drm-intel into drm-fixes
Merge tag 'amd-drm-fixes-6.9-2024-04-10' of
https://gitlab.freedesktop.org/agd5f/linux into drm-fixes
Merge tag
From: Dave Airlie
Running a lot of VK CTS in parallel against nouveau, once every
few hours you might see something like this crash.
BUG: kernel NULL pointer dereference, address: 0008
PGD 800114e6e067 P4D 800114e6e067 PUD 109046067 PMD 0
Oops: [#1] PREEMPT SMP PTI
CPU
From: Dave Airlie
Running a lot of VK CTS in parallel against nouveau, once every
few hours you might see something like this crash.
BUG: kernel NULL pointer dereference, address: 0008
PGD 800114e6e067 P4D 800114e6e067 PUD 109046067 PMD 0
Oops: [#1] PREEMPT SMP PTI
CPU
On Tue, 9 Apr 2024 at 21:33, Danilo Krummrich wrote:
>
> On 4/9/24 10:27, Lucas Stach wrote:
> > Am Dienstag, dem 09.04.2024 um 10:34 +1000 schrieb Dave Airlie:
> >> From: Dave Airlie
> >>
> >> Running a lot of VK CTS in parallel against nouveau, once every
On Tue, 9 Apr 2024 at 21:33, Danilo Krummrich wrote:
>
> On 4/9/24 10:27, Lucas Stach wrote:
> > Am Dienstag, dem 09.04.2024 um 10:34 +1000 schrieb Dave Airlie:
> >> From: Dave Airlie
> >>
> >> Running a lot of VK CTS in parallel against nouveau, once every
for 6.9-rc4
nouveau:
- regression fix for GSP display enable.
Dave Airlie (1):
nouveau: fix devinit paths to only handle display on GSP.
drivers/gpu/drm/nouveau/nvkm/subdev/devinit/gm107.c | 12
drivers/gpu/drm
On Mon, 8 Apr 2024 at 23:05, Timur Tabi wrote:
>
> On Mon, 2024-04-08 at 16:42 +1000, Dave Airlie wrote:
> > This reverts:
> > nouveau/gsp: don't check devinit disable on GSP.
> > and applies a further fix.
> >
> > It turns out the open gpu driver, checks thi
On Mon, 8 Apr 2024 at 23:05, Timur Tabi wrote:
>
> On Mon, 2024-04-08 at 16:42 +1000, Dave Airlie wrote:
> > This reverts:
> > nouveau/gsp: don't check devinit disable on GSP.
> > and applies a further fix.
> >
> > It turns out the open gpu driver, checks thi
From: Dave Airlie
Running a lot of VK CTS in parallel against nouveau, once every
few hours you might see something like this crash.
BUG: kernel NULL pointer dereference, address: 0008
PGD 800114e6e067 P4D 800114e6e067 PUD 109046067 PMD 0
Oops: [#1] PREEMPT SMP PTI
CPU
From: Dave Airlie
Running a lot of VK CTS in parallel against nouveau, once every
few hours you might see something like this crash.
BUG: kernel NULL pointer dereference, address: 0008
PGD 800114e6e067 P4D 800114e6e067 PUD 109046067 PMD 0
Oops: [#1] PREEMPT SMP PTI
CPU
d of quite of a lot of GSP error spam in dmesg.
>
> Signed-off-by: Lyude Paul
For the two patches,
Reviewed-by: Dave Airlie
> ---
> drivers/gpu/drm/nouveau/nouveau_dp.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/gpu/drm/nouveau/nouve
d of quite of a lot of GSP error spam in dmesg.
>
> Signed-off-by: Lyude Paul
For the two patches,
Reviewed-by: Dave Airlie
> ---
> drivers/gpu/drm/nouveau/nouveau_dp.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/gpu/drm/nouveau/nouve
sable on GSP.")
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/nouveau/nvkm/subdev/devinit/gm107.c | 12
drivers/gpu/drm/nouveau/nvkm/subdev/devinit/r535.c | 1 +
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/devinit/gm107.c
b/d
sable on GSP.")
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/nouveau/nvkm/subdev/devinit/gm107.c | 12
drivers/gpu/drm/nouveau/nvkm/subdev/devinit/r535.c | 1 +
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/devinit/gm107.c
b/d
On Sat, 30 Mar 2024 at 04:39, Abhinav Kumar wrote:
>
>
>
> On 3/26/2024 2:23 PM, Miguel Ojeda wrote:
> > Clang 14 in an (essentially) defconfig arm64 build for next-20240326
> > reports [1]:
> >
> > drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c:843:6: error:
> > variable 'out' set but not
On Sat, 30 Mar 2024 at 04:39, Abhinav Kumar wrote:
>
>
>
> On 3/26/2024 2:23 PM, Miguel Ojeda wrote:
> > Clang 14 in an (essentially) defconfig arm64 build for next-20240326
> > reports [1]:
> >
> > drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c:843:6: error:
> > variable 'out' set but not
the computation for compressed_bpp for DISPLAY < 13
Arun R Murthy (1):
drm/i915/dp: Remove support for UHBR13.5
Christian Hewitt (1):
drm/panfrost: fix power transition timeout warnings
Colin Ian King (1):
drm/nouveau/gr/gf100: Remove second semicolon
Dave Airlie (4):
nouv
On Wed, 27 Mar 2024 at 19:52, Thomas Hellström
wrote:
>
> Hi!
>
> With our SVM mirror work we'll soon start looking at HMM cross-device
> support. The identified needs are
>
> 1) Instead of migrating foreign device memory to system when the
> current device is faulting, leave it in place...
> 1a)
: Fix divide-by-zero regression on DP MST unplug with nouveau
Chris Park (1):
drm/amd/display: Prevent crash when disable stream
Chris Wilson (1):
drm/i915/gt: Reset queue_priority_hint on parking
Dave Airlie (5):
Merge tag 'drm-xe-fixes-2024-03-26' of
https
From: Dave Airlie
dEQP-VK.sparse_resources.image_rebind.2d_array.r64i.128_128_8
was causing a remap operation like the below.
op_remap: prev: 003fffed 000f a5abd18a
op_remap: next:
op_remap: unmap: 003fffed 0010 0
op_map: map
From: Dave Airlie
dEQP-VK.sparse_resources.image_rebind.2d_array.r64i.128_128_8
was causing a remap operation like the below.
op_remap: prev: 003fffed 000f a5abd18a
op_remap: next:
op_remap: unmap: 003fffed 0010 0
op_map: map
NULL check in dc_state_release
Arthur Grillo (1):
drm: Fix drm_fixp2int_round() making it add 0.5
Aurabindo Pillai (1):
drm/amd/display: Enable DML2 debug flags
ChunTao Tso (1):
drm/amd/display: Amend coasting vtotal for replay low hz
Dave Airlie (6):
nouveau: reset
>
> > -/* Workaround for a spec issue.
> > - *Can be removed once no longer needed, and threading can be enabled.
> */
> > +/* TODO: investigate if this can be removed to make decoding
> completely
> > + * independent. */
> > FFVulkanDecodeContext *dec;
>
>
On Thu, 14 Mar 2024 at 11:49, Linus Torvalds
wrote:
>
> On Tue, 12 Mar 2024 at 21:07, Dave Airlie wrote:
> >
> > I've done a trial merge into your tree from a few hours ago, there
> > are definitely some slighty messy conflicts, I've pushed a sample
> > branch here
From: Dave Airlie
GSP should be handling this and I can see no evidence in opengpu
driver that this register should be touched.
Fixed acceleration on 2080 Ti GPUs.
Fixes: 15740541e8f0 ("drm/nouveau/devinit/tu102-: prepare for GSP-RM")
Signed-off-by: Dave Airlie
---
drivers/gpu/d
From: Dave Airlie
GSP should be handling this and I can see no evidence in opengpu
driver that this register should be touched.
Fixed acceleration on 2080 Ti GPUs.
Fixes: 15740541e8f0 ("drm/nouveau/devinit/tu102-: prepare for GSP-RM")
Signed-off-by: Dave Airlie
---
drivers/gpu/d
From: Dave Airlie
Later attempts to refault the bo won't happen and the whole
GPU does to lunch. I think Christian's refactoring of this
code out to the driver broke this not very well tested path.
Fixes: 141b15e59175 ("drm/nouveau: move io_reserve_lru handling into the driver
v5
From: Dave Airlie
Later attempts to refault the bo won't happen and the whole
GPU does to lunch. I think Christian's refactoring of this
code out to the driver broke this not very well tested path.
Fixes: 141b15e59175 ("drm/nouveau: move io_reserve_lru handling into the driver
v5
-intel-fixes-2024-03-01' of
https://anongit.freedesktop.org/git/drm/drm-intel into drm-fixes
Dave Airlie (5):
Merge tag 'drm-intel-fixes-2024-03-07' of
https://anongit.freedesktop.org/git/drm/drm-intel into drm-fixes
Merge tag 'drm-xe-fixes-2024-03-07' of
https://gitlab.freedesktop.org
rm/xe/mmio: fix build warning for BAR resize on 32-bit
Christian König (1):
drm/ttm/tests: depend on UML || COMPILE_TEST
Dave Airlie (5):
Merge tag 'drm-misc-fixes-2024-02-29' of
https://anongit.freedesktop.org/git/drm/drm-misc into drm-fixes
Merge tag 'drm-xe-fixes-2024-02-29
From: Dave Airlie
This lock is just protecting the umem list so name it as such.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/nouveau/include/nvkm/core/client.h | 2 +-
drivers/gpu/drm/nouveau/nvkm/core/client.c | 2 +-
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/umem.c | 12
From: Dave Airlie
This lock is just protecting the umem list so name it as such.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/nouveau/include/nvkm/core/client.h | 2 +-
drivers/gpu/drm/nouveau/nvkm/core/client.c | 2 +-
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/umem.c | 12
From: Dave Airlie
It appears the client object tree has no locking unless I've missed
something else. Fix races around adding/removing client objects,
mostly vram bar mappings.
4562.099306] general protection fault, probably for non-canonical address
0x6677ed422bceb80c: [#1] PREEMPT SMP
From: Dave Airlie
It appears the client object tree has no locking unless I've missed
something else. Fix races around adding/removing client objects,
mostly vram bar mappings.
4562.099306] general protection fault, probably for non-canonical address
0x6677ed422bceb80c: [#1] PREEMPT SMP
From: Dave Airlie
Turns out usage is always in bytes not shifted.
Fixes: 72fa02fdf833 ("nouveau: add an ioctl to report vram usage")
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/nouveau/nouveau_abi16.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drive
From: Dave Airlie
Turns out usage is always in bytes not shifted.
Fixes: 72fa02fdf833 ("nouveau: add an ioctl to report vram usage")
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/nouveau/nouveau_abi16.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drive
This is probably something I knew about and forgot, but I'll ask if
anyone has considered cleaning it up (or maybe I should fix nouveau).
nouveau sets up the resource manager using vram_size >> PAGE_SHIFT as
the bounds, but the bo sizes are in bytes, hence usage ends up being
accounted in bytes,
On Sat, 24 Feb 2024 at 03:01, Danilo Krummrich wrote:
>
> On Fri, Feb 23, 2024 at 10:14:53AM +1000, Dave Airlie wrote:
> > On Fri, 23 Feb 2024 at 00:45, Danilo Krummrich wrote:
> > >
> > > Using the kernel global workqueue to signal fences can lead to
> > >
On Sat, 24 Feb 2024 at 03:01, Danilo Krummrich wrote:
>
> On Fri, Feb 23, 2024 at 10:14:53AM +1000, Dave Airlie wrote:
> > On Fri, 23 Feb 2024 at 00:45, Danilo Krummrich wrote:
> > >
> > > Using the kernel global workqueue to signal fences can lead to
> > >
On Mon, 26 Feb 2024 at 07:26, David Laight wrote:
>
> ...
> > Yes, yes, that may end up requiring getting rid of some current users of
> >
> > #define MIN(a,b) ((a)<(b) ? (a):(b))
> >
> > but dammit, we don't actually have _that_ many of them, and why should
> > we have random drivers doing
):
drm/buddy: Modify duplicate list_splice_tail call
Ashutosh Dixit (2):
drm/xe/xe_gt_idle: Drop redundant newline in name
drm/xe: Fix modpost warning on xe_mocs kunit module
Dan Carpenter (1):
drm/nouveau/mmu/r535: uninitialized variable in r535_bar_new_()
Dave Airlie (7
AX_ACTIVE limit is reached by waiters, this can
> prevent the work signaling the fence from running.
>
> While this seems fairly unlikely, it's potentially exploitable.
LGTM
Reviewed-by: Dave Airlie
probably should go into drm-misc-fixes?
>
> Fixes: 39126abc5e20 ("
AX_ACTIVE limit is reached by waiters, this can
> prevent the work signaling the fence from running.
>
> While this seems fairly unlikely, it's potentially exploitable.
LGTM
Reviewed-by: Dave Airlie
probably should go into drm-misc-fixes?
>
> Fixes: 39126abc5e20 ("
Can someone pick these up into misc?
Dave.
On Thu, 22 Feb 2024 at 04:48, Erik Kurzinger wrote:
>
> It looks these these patches have still not been merged after one month, is
> there anything more that needs to be done for this to happen?
>
> On 1/25/24 10:12, Daniel Vetter wrote:
> > On Fri,
vam (1):
drm/buddy: Fix alloc_range() error handling code
Dan Carpenter (1):
drm/amd/display: Fix && vs || typos
Danilo Krummrich (2):
drm/nouveau: don't fini scheduler if not initialized
drm/nouveau: omit to create schedulers using the legacy uAPI
Dave Airlie (5
On Thu, 15 Feb 2024 at 20:06, Tvrtko Ursulin
wrote:
>
> Hi Dave, Daniel,
>
> First pull request for 6.9 with probably one more coming in one to two
> weeks.
>
> Nothing to interesting in this one, mostly a sprinkle of small fixes in
> GuC, HuC, Perf/OA, a tiny bit of prep work for future
On Thu, 15 Feb 2024 at 20:06, Tvrtko Ursulin
wrote:
>
> Hi Dave, Daniel,
>
> First pull request for 6.9 with probably one more coming in one to two
> weeks.
>
> Nothing to interesting in this one, mostly a sprinkle of small fixes in
> GuC, HuC, Perf/OA, a tiny bit of prep work for future
On Thu, 15 Feb 2024 at 20:06, Tvrtko Ursulin
wrote:
>
> Hi Dave, Daniel,
>
> First pull request for 6.9 with probably one more coming in one to two
> weeks.
>
> Nothing to interesting in this one, mostly a sprinkle of small fixes in
> GuC, HuC, Perf/OA, a tiny bit of prep work for future
(ignore this one, sent another just after)
On Wed, 14 Feb 2024 at 13:40, Dave Airlie wrote:
>
> From: Dave Airlie
>
> Turing and Ampere will continue to use the old paths by default,
> but we should allow distros to decide what the policy is.
>
> Signed-off-by: Dave Airlie
(ignore this one, sent another just after)
On Wed, 14 Feb 2024 at 13:40, Dave Airlie wrote:
>
> From: Dave Airlie
>
> Turing and Ampere will continue to use the old paths by default,
> but we should allow distros to decide what the policy is.
>
> Signed-off-by: Dave Airlie
From: Dave Airlie
Turing and Ampere will continue to use the old paths by default,
but we should allow distros to decide what the policy is.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/nouveau/Kconfig| 8
drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c | 6 +-
2
From: Dave Airlie
Turing and Ampere will continue to use the old paths by default,
but we should allow distros to decide what the policy is.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/nouveau/Kconfig| 8
drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c | 6 +-
2
From: Dave Airlie
Turing and Ampere will continue to use the old paths by default,
but we should allow distros to decide what the policy is.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/nouveau/Kconfig| 8
drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c | 3 +++
2
From: Dave Airlie
Turing and Ampere will continue to use the old paths by default,
but we should allow distros to decide what the policy is.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/nouveau/Kconfig| 8
drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c | 3 +++
2
t; It makes sense to allocate struct nouveau_sched separately anyway, since
> in a subsequent commit we can also avoid to allocate a struct
> nouveau_sched in nouveau_abi16_ioctl_channel_alloc() at all, if the
> VM_BIND uAPI has been disabled due to the legacy uAPI being used.
Looks good,
for th
t; It makes sense to allocate struct nouveau_sched separately anyway, since
> in a subsequent commit we can also avoid to allocate a struct
> nouveau_sched in nouveau_abi16_ioctl_channel_alloc() at all, if the
> VM_BIND uAPI has been disabled due to the legacy uAPI being used.
Looks good,
for th
On Fri, 9 Feb 2024 at 14:38, Ashwin Bhat wrote:
>
> Hello,
>
> During Vulkanised 2024 I was super excited to hear and learn about Lavapipe
> https://vulkan.org/user/pages/09.events/vulkanised-2024/Vulkanised-2024-faith-ekstrand-collabora-Iago-toral-igalia.pdf
>
> Are there some basic tutorials
):
drm/xe: circumvent bogus stringop-overflow warning
Dan Carpenter (1):
drm/i915/gvt: Fix uninitialized variable in handle_mmio()
Dave Airlie (6):
nouveau/gsp: use correct size for registry rpc.
Merge tag 'drm-misc-fixes-2024-02-08' of
git://anongit.freedesktop.org/drm/drm-misc
> Best Regards,
> - Maíra
>
> On 2/7/24 03:56, Dave Airlie wrote:
> > I'm just looking over the userptr handling in both drivers, and of
> > course they've chosen different ways to represent things. Again this
> > is a divergence that is just going to get more annoying over
I'm just looking over the userptr handling in both drivers, and of
course they've chosen different ways to represent things. Again this
is a divergence that is just going to get more annoying over time and
eventually I'd like to make hmm/userptr driver independent as much as
possible, so we get
>> NULL.
> >>>>>
> >>>>> Fixes: 6dbd9004a55 ("drm/sched: Drain all entities in DRM sched run job
> >>>>> worker")
> >>> First of all there's a small typo in this Fixes tag that needs to be
> >>> fixed.
> >
On Tue, 6 Feb 2024 at 02:22, Danilo Krummrich wrote:
>
> On 1/29/24 02:50, Dave Airlie wrote:
> > From: Dave Airlie
> >
> > This should break the deadlock between the fctx lock and the irq lock.
> >
> > This offloads the processing off the work from the irq
On Tue, 6 Feb 2024 at 02:22, Danilo Krummrich wrote:
>
> On 1/29/24 02:50, Dave Airlie wrote:
> > From: Dave Airlie
> >
> > This should break the deadlock between the fctx lock and the irq lock.
> >
> > This offloads the processing off the work from the irq
On Mon, 6 Nov 2023 at 20:47, Jocelyn Falempe wrote:
>
> On 23/10/2023 10:30, Jocelyn Falempe wrote:
> > On 20/10/2023 14:06, Thomas Zimmermann wrote:
> >> (cc'ing lkml for feedback)
> >>
> >> Hi Jocelyn
> >>
> >> Am 19.10.23 um 15:55 schrieb Jocelyn Falempe:
> >>> We found a regression in v5.10
md/display: fix USB-C flag update after enc10 feature init
Dave Airlie (5):
Merge tag 'drm-misc-fixes-2024-02-01' of
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes
Merge tag 'drm-xe-fixes-2024-02-01' of
https://gitlab.freedesktop.org/drm/xe/kernel into drm-fixes
Merge ta
On Fri, 2 Feb 2024 at 07:33, Timur Tabi wrote:
>
> On Thu, 2024-02-01 at 13:55 -0600, Timur Tabi wrote:
> > +static void
> > +nvkm_gsp_mem_dtor(struct nvkm_gsp *gsp, struct nvkm_gsp_mem *mem)
> > +{
> > + if (mem->data) {
> > + dma_free_coherent(gsp->subdev.device->dev,
From: Dave Airlie
Timur pointed this out before, and it just slipped my mind,
but this might help some things work better, around pcie power
management.
Fixes: 8d55b0a940bb ("nouveau/gsp: add some basic registry entries.")
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/nouveau/nvkm/
From: Dave Airlie
Timur pointed this out before, and it just slipped my mind,
but this might help some things work better, around pcie power
management.
Fixes: 8d55b0a940bb ("nouveau/gsp: add some basic registry entries.")
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/nouveau/nvkm/
From: Dave Airlie
This should break the deadlock between the fctx lock and the irq lock.
This offloads the processing off the work from the irq into a workqueue.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/nouveau/nouveau_fence.c | 24 ++--
drivers/gpu/drm/nouveau
From: Dave Airlie
This should break the deadlock between the fctx lock and the irq lock.
This offloads the processing off the work from the irq into a workqueue.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/nouveau/nouveau_fence.c | 24 ++--
drivers/gpu/drm/nouveau
/panel: samsung-s6d7aa0: drop DRM_BUS_FLAG_DE_HIGH for lsl080al02
Bagas Sanjaya (1):
drm/dp_mst: Separate @failing_port list in
drm_dp_mst_atomic_check_mgr() comment
ChunTao Tso (1):
drm/amd/display: Replay + IPS + ABM in Full Screen VPB
Dave Airlie (9):
Merge tag 'drm-intel-next
Just FYI this conflictted pretty heavily with drm-misc-next changes in
the same area, someone should check drm-tip has the correct
resolution, I'm not really sure what is definitely should be.
Dave.
On Fri, 19 Jan 2024 at 16:37, Inki Dae wrote:
>
> Really sorry for late. Will pick it up.
>
>
Just FYI I'm pulling this into drm-fixes straight as is, since if
fixes the regression and avoids the revert, however please keep
discussing until we are sure things are right, and we can deal with
any fixes in a follow-up patch.
Dave.
On Fri, 26 Jan 2024 at 03:32, Matthew Brost wrote:
>
> On
On Fri, 26 Jan 2024 at 04:28, Daniel Vetter wrote:
>
> On Tue, Jan 23, 2024 at 05:25:38PM +1000, Dave Airlie wrote:
> > From: Dave Airlie
> >
> > fences are signalled on nvidia hw using non-stall interrupts.
> >
> > non-stall interrupts are not latched from my
On Fri, 26 Jan 2024 at 04:28, Daniel Vetter wrote:
>
> On Tue, Jan 23, 2024 at 05:25:38PM +1000, Dave Airlie wrote:
> > From: Dave Airlie
> >
> > fences are signalled on nvidia hw using non-stall interrupts.
> >
> > non-stall interrupts are not latched from my
From: Dave Airlie
fences are signalled on nvidia hw using non-stall interrupts.
non-stall interrupts are not latched from my reading.
When nouveau emits a fence, it requests a NON_STALL signalling,
but it only calls the interface to allow the non-stall irq to happen
after it has already
From: Dave Airlie
fences are signalled on nvidia hw using non-stall interrupts.
non-stall interrupts are not latched from my reading.
When nouveau emits a fence, it requests a NON_STALL signalling,
but it only calls the interface to allow the non-stall irq to happen
after it has already
On Tue, 23 Jan 2024 at 12:21, Dave Airlie wrote:
>
> On Tue, 23 Jan 2024 at 12:15, Steven Rostedt wrote:
> >
> > On Mon, 22 Jan 2024 19:56:08 -0500
> > "Bhardwaj, Rajneesh" wrote:
> >
> > >
> > > On 1/22/2024 7:43 PM, Linus Torvalds w
On Tue, 23 Jan 2024 at 12:15, Steven Rostedt wrote:
>
> On Mon, 22 Jan 2024 19:56:08 -0500
> "Bhardwaj, Rajneesh" wrote:
>
> >
> > On 1/22/2024 7:43 PM, Linus Torvalds wrote:
> > > On Mon, 22 Jan 2024 at 15:17, Steven Rostedt wrote:
> > >> Perhaps this is the real fix?
> > > If you send a
From: Dave Airlie
ttm init was changed to look at numa node, but that needed a device.
Only qxl appears to not hand in a device, so just fix that.
Fixes: b0a7ce53d494 ("drm/ttm: Schedule delayed_delete worker closer")
Reported-by: Steven Rostedt
Cc: Rajneesh Bhardwaj
Signed-of
From: Dave Airlie
ttm init was changed to look at numa node, but that needed a device.
Only qxl appears to not hand in a device, so just fix that.
Fixes: b0a7ce53d494 ("drm/ttm: Schedule delayed_delete worker closer")
Reported-by: Steven Rostedt
Cc: Rajneesh Bhardwaj
Signed-of
1 - 100 of 18377 matches
Mail list logo
