All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ryosuke Yasuoka <ryasuoka@redhat.com>
To: zack.rusin@broadcom.com, maarten.lankhorst@linux.intel.com,
	mripard@kernel.org, tzimmermann@suse.de, airlied@gmail.com,
	simona@ffwll.ch, jfalempe@redhat.com, ian.forbes@broadcom.com
Cc: bcm-kernel-feedback-list@broadcom.com,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH drm-misc-next v3 0/1] add drm_panic_support for vmwgfx-stdu
Date: Thu, 16 Oct 2025 23:48:19 +0900	[thread overview]
Message-ID: <aPEFs0kYfXGZUHCA@zeus> (raw)
In-Reply-To: <20250919032936.2267240-1-ryasuoka@redhat.com>

On Fri, Sep 19, 2025 at 12:29:29PM +0900, Ryosuke Yasuoka wrote:
> Add drm_panic support for stdu in vmwgfx. This patch was tested in a VM
> with VMSVGA on Virtual Box.
> 
> Based on the feedback for v2 patch, I've made the following updates in
> my v3 patch.
> - Use MEMREMAP_WB | MEMREMAP_DEC flags for memremap
> - Use vmw_priv->initial_height and initial_width for sb and VRAM
> - Move all panic related functions to the vmwgfx_kms.c file
> - Ensure if the current display unit is 0 in get_scanout_buffer()
> 
> I did not apply all of Ian's feedback in this v3 patch for the reasons
> outlined below.
> 
> > 1. You can call `vmw_kms_write_svga` directly in `panic_flush`. There
> > is no need to mark the buffer as dirty or send any commands.
> 
> In my test environment (VirtualBox), the panic screen appears unstably 
> without dirty command's submission. Without it, the screen sometimes
> appears immediately as expected, and at other times, there's a delay
> of 15 to 20 seconds. I've also observed that it sometimes only appears
> after switching between the VirtualBox console window and other windows.
> 
> With command submission, we can stably get a panic screen. Even if it
> fails, we may get the panic screen ultimately. Therefore, I think we
> should retain vmw_kms_panic_do_bo_dirty() to submit commands.
> 
> > 2. The format should be hardcoded to RGB565 to minimize the risk of
> > overrunning VRAM. Adjust the pitch accordingly to 2x width.
> 
> While it's possible to output the panic screen with RGB565 by adjusting
> pitch and width, and BPP on the (virtual) hardware side, this approach
> causes debugfs to fail. It appears that the BPP must be reset after the
> panic screen is displayed, and there is no way to wait for the screen
> to be fully displayed within the drm_panic handler code.
> 
> In my test environment, as VRAM has enough space even when using
> XRGB8888 (32 bits), I think the risk of overruning VRAM is low. So I've
> kept the default format and CPP size.
> 
> v1:
> https://lore.kernel.org/all/20250901083701.32365-1-ryasuoka@redhat.com/
> 
> v2:
> https://lore.kernel.org/all/20250908141152.221291-2-ryasuoka@redhat.com/
> - Map a scanout_buffer to VRAM in .get_scanout_buffer
> - And then write to VRAM directly using fifo in legacy mode to avoid
> allocations or command submissions.
> 
> 
> Ryosuke Yasuoka (1):
>   drm/vmwgfx: add drm_panic support for stdu mode
> 
>  drivers/gpu/drm/vmwgfx/vmwgfx_drv.h  |   4 +
>  drivers/gpu/drm/vmwgfx/vmwgfx_kms.c  | 165 +++++++++++++++++++++++++++
>  drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c |   2 +
>  3 files changed, 171 insertions(+)
> 
> 
> base-commit: d41c79838c47bc822534cd53628fe5e0f8ad2424
> -- 
> 2.51.0

Hi all,

This is a gentle reminder for this v3 patch.
I would appreciate any feedback when you have a chance.

Ian, your feedback on v1 and v2 were very helpful. I would appreciate it
if you could take another look when you have a moment.

Any comments are welcome.

Thank you
Ryosuke


  parent reply	other threads:[~2025-10-16 14:48 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-19  3:29 [PATCH drm-misc-next v3 0/1] add drm_panic_support for vmwgfx-stdu Ryosuke Yasuoka
2025-09-19  3:29 ` [PATCH drm-misc-next v3 1/1] drm/vmwgfx: add drm_panic support for stdu mode Ryosuke Yasuoka
2025-10-16 14:48 ` Ryosuke Yasuoka [this message]
2025-10-23 20:12   ` [PATCH drm-misc-next v3 0/1] add drm_panic_support for vmwgfx-stdu Ian Forbes

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aPEFs0kYfXGZUHCA@zeus \
    --to=ryasuoka@redhat.com \
    --cc=airlied@gmail.com \
    --cc=bcm-kernel-feedback-list@broadcom.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=ian.forbes@broadcom.com \
    --cc=jfalempe@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mripard@kernel.org \
    --cc=simona@ffwll.ch \
    --cc=tzimmermann@suse.de \
    --cc=zack.rusin@broadcom.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.