On Tue, Feb 27, 2024 at 6:38 AM Thomas Zimmermann wrote:
>
> Dma-buf locking semantics require the caller of pin and unpin to hold
> the buffer's reservation lock. Fix DRM to adhere to the specs. This
> enables to fix the locking in DRM's console emulation. Similar changes
> for vmap and mmap
On Tue, Feb 27, 2024 at 6:39 AM Thomas Zimmermann wrote:
>
> Acquire the buffer object's reservation lock in drm_gem_pin() and
> remove locking the drivers' GEM callbacks where necessary. Same for
> unpin().
>
> DRM drivers and memory managers modified by this patch will now have
> correct
On Tue, Feb 27, 2024 at 6:39 AM Thomas Zimmermann wrote:
>
> Acquire the reservation lock directly in GEM pin callback. Same for
> unpin. Prepares for further changes.
>
> Dma-buf locking semantics require callers to hold the buffer's
> reservation lock when invoking the pin and unpin callbacks.
Hello,
We are currently looking at checking and/or possibly redesigning the
way the MSM DRM driver handles the HPD events and link training.
After a quick glance at the drivers implementing DP support, I noticed
following main approaches:
- Perform link training at the atomic_enable time, don't
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 22ba90670a51a18c6b36d285fddf92b9887c0bc3 Add linux-next specific
files for 20240227
Error/Warning reports:
https://lore.kernel.org/oe-kbuild-all/202402271629.7zzu8scf-...@intel.com
Error
Am 27.02.24 um 19:14 schrieb Dmitry Osipenko:
Hello,
Thank you for the patches!
On 2/27/24 13:14, Thomas Zimmermann wrote:
Dma-buf locking semantics require the caller of pin and unpin to hold
the buffer's reservation lock. Fix DRM to adhere to the specs. This
enables to fix the locking in
Hello,
Thank you for the patches!
On 2/27/24 13:14, Thomas Zimmermann wrote:
> Dma-buf locking semantics require the caller of pin and unpin to hold
> the buffer's reservation lock. Fix DRM to adhere to the specs. This
> enables to fix the locking in DRM's console emulation. Similar changes
>
On Tue, 2024-02-27 at 15:20 +0100, Danilo Krummrich wrote:
> Hi Timur,
>
> thanks for re-working this patch!
>
> On 2/26/24 22:02, Timur Tabi wrote:
> > The LOGINIT, LOGINTR, LOGRM, and LOGPMU buffers are circular buffers
> > that have printf-like logs from GSP-RM and PMU encoded in them.
> >
>
On Tue, 2024-02-27 at 15:23 +0100, Danilo Krummrich wrote:
> > Store the struct device pointer used to allocate the DMA buffer in
> > the nvkm_gsp_mem object. This allows nvkm_gsp_mem_dtor() to release
> > the buffer without needing the nvkm_gsp. This is needed so that
> > we can retain DMA
Hi
Am 27.02.24 um 15:03 schrieb Christian König:
Nice, looks totally valid to me.
Feel free to add to patch #2, #9, #10, #11 and #12 Reviewed-by:
Christian König
And Acked-by: Christian König to the rest.
Oh, wow. That was quick! Thanks a lot.
Best regards
Thomas
Regards,
Christian.
Hi Timur,
On 2/26/24 22:04, Timur Tabi wrote:
Store the struct device pointer used to allocate the DMA buffer in
the nvkm_gsp_mem object. This allows nvkm_gsp_mem_dtor() to release
the buffer without needing the nvkm_gsp. This is needed so that
we can retain DMA buffers even after the
Hi Timur,
thanks for re-working this patch!
On 2/26/24 22:02, Timur Tabi wrote:
The LOGINIT, LOGINTR, LOGRM, and LOGPMU buffers are circular buffers
that have printf-like logs from GSP-RM and PMU encoded in them.
LOGINIT, LOGINTR, and LOGRM are allocated by Nouveau and their DMA
addresses are
Nice, looks totally valid to me.
Feel free to add to patch #2, #9, #10, #11 and #12 Reviewed-by:
Christian König
And Acked-by: Christian König to the rest.
Regards,
Christian.
Am 27.02.24 um 11:14 schrieb Thomas Zimmermann:
Dma-buf locking semantics require the caller of pin and unpin to
Pin and vmap are distinct operations. Do not perform a pin as part
of the vmap call. This used to be necessary to keep the fbdev buffer
in place while it is being updated. Fbdev emulation has meanwhile
been fixed to lock the buffer correctly. Same for vunmap.
Signed-off-by: Thomas Zimmermann
---
The function drm_client_buffer_vmap() establishes a long-term mapping
of the client's buffer object into the kernel address space. Make sure
that buffer does not move by pinning it to its current location. Same
for vunmap with unpin.
The only caller of drm_client_buffer_vmap() is fbdev-dma, which
Acquire the buffer object's reservation lock in drm_gem_pin() and
remove locking the drivers' GEM callbacks where necessary. Same for
unpin().
DRM drivers and memory managers modified by this patch will now have
correct dma-buf locking semantics: the caller is responsible for
holding the
Pin and vmap are distinct operations. Do not perform a pin as part
of the vmap call. This used to be necessary to keep the fbdev buffer
in place while it is being updated. Fbdev emulation has meanwhile
been fixed to lock the buffer correctly. Same for vunmap.
For refactoring the code, remove the
Temporarily lock the fbdev buffer object during updates to prevent
memory managers from evicting/moving the buffer. Moving a buffer
object while update its content results in undefined behaviour.
Fbdev-generic updates its buffer object from a shadow buffer. Gem-shmem
and gem-dma helpers do not
Rename __qxl_bo_pin() to qxl_bo_pin_locked() and update all callers.
The function will be helpful for implementing the GEM pin callback
with correct semantics. Same for __qxl_bo_unpin().
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/qxl/qxl_object.c | 25 +
Implement pinning without locking in nouveau_bo_pin_locked(). Keep
nouveau_bo_pin() for acquiring the buffer object's reservation lock.
The new helper will be useful for implementing the GEM pin callback
with correct semantics. Same for unpin.
Signed-off-by: Thomas Zimmermann
---
Acquire the reservation lock directly in GEM pin callback. Same for
unpin. Prepares for further changes.
Dma-buf locking semantics require callers to hold the buffer's
reservation lock when invoking the pin and unpin callbacks. Prepare
qxl accordingly by pushing locking out of the implementation.
Acquire the reservation lock directly in GEM pin callback. Same for
unpin. Prepares for further changes.
Dma-buf locking semantics require callers to hold the buffer's
reservation lock when invoking the pin and unpin callbacks. Prepare
nouveau accordingly by pushing locking out of the
Export msm_gem_pin_pages_locked() and acquire the reservation lock
directly in GEM pin callback. Same for unpin. Prepares for further
changes.
Dma-buf locking semantics require callers to hold the buffer's
reservation lock when invoking the pin and unpin callbacks. Prepare
msm accordingly by
Rename msm_gem_pin_pages_locked() to msm_gem_get_pages_locked(). The
function doesn't pin any pages, but only acquires them. Renaming the
function makes the old name available.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/msm/msm_gem.c | 8
1 file changed, 4 insertions(+), 4
Acquire the reservation lock directly in GEM pin callback. Same for
unpin. Prepares for further changes.
Dma-buf locking semantics require callers to hold the buffer's
reservation lock when invoking the pin and unpin callbacks. Prepare
gem-vram accordingly by pushing locking out of the
Dma-buf locking semantics require the caller of pin and unpin to hold
the buffer's reservation lock. Fix DRM to adhere to the specs. This
enables to fix the locking in DRM's console emulation. Similar changes
for vmap and mmap have been posted at [1][2]
Most DRM drivers and memory managers
Export drm_gem_shmem_pin_locked() and acquire the reservation lock
directly in GEM pin callback. Same for unpin. Prepares for further
changes.
Dma-buf locking semantics require callers to hold the buffer's
reservation lock when invoking the pin and unpin callbacks. Prepare
gem-shmem accordingly
Am 27.02.24 um 09:12 schrieb Matthew Auld:
On 26/02/2024 20:21, Thomas Hellström wrote:
Hi, Christian
On Fri, 2024-02-23 at 15:30 +0100, Christian König wrote:
Am 06.02.24 um 13:56 schrieb Christian König:
Am 06.02.24 um 13:53 schrieb Thomas Hellström:
Hi, Christian,
On Fri, 2024-01-26 at
On 26/02/2024 20:21, Thomas Hellström wrote:
Hi, Christian
On Fri, 2024-02-23 at 15:30 +0100, Christian König wrote:
Am 06.02.24 um 13:56 schrieb Christian König:
Am 06.02.24 um 13:53 schrieb Thomas Hellström:
Hi, Christian,
On Fri, 2024-01-26 at 15:09 +0100, Christian König wrote:
29 matches
Mail list logo
