Re: [PATCH 0/4] vkms: Switch to shadow-buffered plane state

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Jul 12, 2021 at 6:53 PM Thomas Zimmermann <tzimmermann@xxxxxxx> wrote:
>
> Hi
>
> Am 12.07.21 um 13:56 schrieb Sumera Priyadarsini:
> > On Mon, Jul 5, 2021 at 1:16 PM Thomas Zimmermann <tzimmermann@xxxxxxx> wrote:
> >>
> >> Vkms copies each plane's framebuffer into the output buffer; essentially
> >> using a shadow buffer. DRM provides struct drm_shadow_plane_state, which
> >> handles the details of mapping/unmapping shadow buffers into memory for
> >> active planes.
> >>
> >> Convert vkms to the helpers. Makes vkms use shared code and gives more
> >> test exposure to shadow-plane helpers.
> >>
> >> Thomas Zimmermann (4):
> >>    drm/gem: Export implementation of shadow-plane helpers
> >>    drm/vkms: Inherit plane state from struct drm_shadow_plane_state
> >>    drm/vkms: Let shadow-plane helpers prepare the plane's FB
> >>    drm/vkms: Use dma-buf mapping from shadow-plane state for composing
> >>
> >>   drivers/gpu/drm/drm_gem_atomic_helper.c | 55 ++++++++++++++++++++++--
> >>   drivers/gpu/drm/vkms/vkms_composer.c    | 26 ++++++-----
> >>   drivers/gpu/drm/vkms/vkms_drv.h         |  6 ++-
> >>   drivers/gpu/drm/vkms/vkms_plane.c       | 57 ++++++-------------------
> >>   include/drm/drm_gem_atomic_helper.h     |  6 +++
> >>   5 files changed, 86 insertions(+), 64 deletions(-)
> >>
> >>
> >> base-commit: 3d3b5479895dd6dd133571ded4318adf595708ba
> >> --
> >> 2.32.0
> >>
> > Hi,
> >
> > Thanks for the patches. The switch to shadow-plane helpers also solved
> > a bug that was causing a kernel
> > panic during some IGT kms_flip subtests on the vkms virtual hw patch.
>
> Melissa mention something like that as well and I don't really
> understand. Patch 3 removes an error message from the code, but is the
> actual bug also gone?

Yes, I think so. Earlier, while testing the vkms virtual hw patch, the
tests were
not just failing, but the vmap fail also preceeded a page fault which required a
whole restart. Check these logs around line 303:
https://pastebin.pl/view/03b750be.

I could be wrong but I think if the same bug was still present, then
the kernel panic
would also happen even if the error message was not being returned.

Cheers,
Sumera

>
> There's little difference between vkms' original code and the shared
> helper; except for the order of operations in prepare_fb. The shared
> helper synchronizes fences before mapping; vkms mapped first.
>
> (Maybe the shared helper should warn about failed vmaps as well. But
> that's for another patch.)
>
> Best regards
> Thomas
>
> >
> > Tested-by: Sumera Priyadarsini <sylphrenadin@xxxxxxxxx>
> >
> > Cheers,
> > Sumera
> >
>
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Maxfeldstr. 5, 90409 Nürnberg, Germany
> (HRB 36809, AG Nürnberg)
> Geschäftsführer: Felix Imendörffer
>




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux