On Fri, Feb 23, 2024 at 10:21:36PM +0100, Konrad Dybcio wrote:
> Bit of a megaseries, bunched together for your testing convenience..
> Needs mesa!27665 [1] on the userland part, kmscube happily spins.
>
> I'm feeling quite lukewarm about the memory barriers in patch 3..
>
> Patch 1 for
On 2/27/24 11:10, Will Deacon wrote:
On Fri, Feb 23, 2024 at 10:21:36PM +0100, Konrad Dybcio wrote:
Bit of a megaseries, bunched together for your testing convenience..
Needs mesa!27665 [1] on the userland part, kmscube happily spins.
I'm feeling quite lukewarm about the memory barriers in
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
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
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 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
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
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
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
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
---
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
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
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 +
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
---
Hi,
Since 6.8-rc1 the VT console is no longer mirrored on an external
display on coldplug or hotplug on the Lenovo ThinkPad X13s.
The hotplug notification appears to be generated immediately but it is
no longer forwarded or processed correctly:
[ 22.578434] msm_dpu ae01000.display-controller:
[send with a reduced set of recipients, we all get enough mail already]
On 27.02.24 13:40, Johan Hovold wrote:
>
> Since 6.8-rc1 the VT console is no longer mirrored on an external
> display on coldplug or hotplug on the Lenovo ThinkPad X13s.
>
Thx for the report!
> I've previously reported
Hi,
Since 6.8-rc1 I have seen (and received reports) of hard resets of the
Lenovo ThinkPad X13s after connecting and disconnecting an external
display.
I have triggered this on a simple disconnect while in a VT console, but
also when stopping Xorg after having repeatedly connected and
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
On Mon, Feb 26, 2024 at 8:01 PM Dmitry Baryshkov
wrote:
>
> On Mon, 26 Feb 2024 at 08:33, Masahiro Yamada wrote:
> >
> > On Mon, Feb 26, 2024 at 11:11 AM Dmitry Baryshkov
> > wrote:
> > >
> > > The driver might decide to put the _shipped files to the subdir.
> >
> >
> >
> > Please stop this
On 22/02/2024 16:55, Abel Vesa wrote:
> Add the X1E80100 to the list of compatibles and document the is-edp
> flag. The controllers are expected to operate in DP mode by default,
> and this flag can be used to select eDP mode.
>
> Signed-off-by: Abel Vesa
> ---
>
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.
On 2/27/2024 2:08 PM, Dmitry Baryshkov wrote:
This reverts commit e467e0bde881 ("drm/msm/dp: use
drm_bridge_hpd_notify() to report HPD status changes").
The commit changed the way how the MSM DP driver communicates
HPD-related events to the userspace. The mentioned commit made some of
the
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
This reverts commit e467e0bde881 ("drm/msm/dp: use
drm_bridge_hpd_notify() to report HPD status changes").
The commit changed the way how the MSM DP driver communicates
HPD-related events to the userspace. The mentioned commit made some of
the HPD events being reported earlier. This way userspace
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 Thu, Feb 22, 2024 at 05:55:07PM +0200, Abel Vesa wrote:
> Instead of relying on different compatibles for eDP and DP, use
> the is-edp property from DT to figure out the connector type and
> then pass on that information to the PHY.
>
> Reviewed-by: Dmitry Baryshkov
> Signed-off-by: Abel Vesa
On 2/27/2024 2:11 PM, Abhinav Kumar wrote:
On 2/27/2024 2:08 PM, Dmitry Baryshkov wrote:
This reverts commit e467e0bde881 ("drm/msm/dp: use
drm_bridge_hpd_notify() to report HPD status changes").
The commit changed the way how the MSM DP driver communicates
HPD-related events to the
On Wed, Feb 28, 2024 at 12:08:08AM +0200, Dmitry Baryshkov wrote:
> This reverts commit e467e0bde881 ("drm/msm/dp: use
> drm_bridge_hpd_notify() to report HPD status changes").
>
> The commit changed the way how the MSM DP driver communicates
> HPD-related events to the userspace. The mentioned
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
31 matches
Mail list logo
