All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sam Ravnborg <sam@ravnborg.org>
To: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Cc: Gerd Hoffmann <kraxel@redhat.com>, dri-devel@lists.freedesktop.org
Subject: Re: Panic booting qemu-system-sparc64 with bochs_drm
Date: Sat, 4 Jul 2020 16:52:12 +0200	[thread overview]
Message-ID: <20200704145212.GA791554@ravnborg.org> (raw)
In-Reply-To: <1d19833f-2977-a12f-f3a9-ef0d509ef366@ilande.co.uk>

Hi Mark.

On Sat, Jul 04, 2020 at 03:16:47PM +0100, Mark Cave-Ayland wrote:
> On 04/07/2020 14:41, Sam Ravnborg wrote:
> 
> > I think what is happening is that the bochs driver request a shadow copy
> > for the frambuffer. And with the change to fbops we now use the cfb_
> > functions to write to the shadow framebuffer - which is not in any IO
> > space. So this does not work.
> > 
> > So maybe all we need is the fix in drm_fb_helper_dirty_blit_real().
> > If you try to undo the change so fbops is set to &drm_fbdev_fb_ops,
> > but keep the fix in drm_fb_helper_dirty_blit_real() how does it then
> > behave?
> 
> Bingo! I just tried that and the framebuffer is now working under qemu-system-sparc64
> again - thank you so much for the help! From what you said I guess
> drm_fb_helper_dirty_blit_real() is responsible syncing the shadow copy?
> 
> Below is the current working diff based upon your previous one: it certainly feels
> like the difference in memcpy() behaviour should be hidden away in fb_memcpy_tofb()
> or similar.

From your feedback so far I thnk the minimal fix would be like this:

> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> .. static void drm_fb_helper_dirty_blit_real(struct drm_fb_helper *fb_helper,
>         size_t len = (clip->x2 - clip->x1) * cpp;
>         unsigned int y;
> 
>         for (y = clip->y1; y < clip->y2; y++) {
> -               memcpy(dst, src, len);
> +               fb_memcpy_tofb(dst, src, len);
>                 src += fb->pitches[0];
>                 dst += fb->pitches[0];
>         }

(Hand edited, patch s not a valid syntax)

But I need feedback from someone that know all this a bit better
to judge if this is an OK change.
For once - this will only work with shadow buffers.

	Sam



> diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> index 6c3ef49b46b3..dce9adf7d189 100644
> --- a/include/drm/drm_mode_config.h
> +++ b/include/drm/drm_mode_config.h
> @@ -865,6 +865,15 @@ struct drm_mode_config {
>          */
>         bool prefer_shadow_fbdev;
> 
> +       /**
> +        * @use_cfb_for_fbdev:
> +        *
> +        * Use cfb variants of drm_fb_helper_cfb_{fillrect,copyarea,imageblit}
> +        * The cfb variants are required when the CPU do not allow direct
> +        * access to the framebuffer (for example sparc64)
> +        */
> +       bool use_cfb_for_fbdev;
> +
>         /**
>          * @quirk_addfb_prefer_xbgr_30bpp:
>          *
> 
> > I did not find time to follow your instructions to test this myself with
> > qemu - sorry.
> 
> No worries, I do appreciate that as a maintainer it can be hard to fit these things
> around life, family, job etc.
> 
> 
> ATB,
> 
> Mark.
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2020-07-04 14:52 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-03 21:57 Panic booting qemu-system-sparc64 with bochs_drm Mark Cave-Ayland
2020-07-03 22:54 ` Mark Cave-Ayland
2020-07-04  7:23 ` Sam Ravnborg
2020-07-04 11:11   ` Mark Cave-Ayland
2020-07-04 13:09     ` Mark Cave-Ayland
2020-07-04 13:41       ` Sam Ravnborg
2020-07-04 14:16         ` Mark Cave-Ayland
2020-07-04 14:52           ` Sam Ravnborg [this message]
2020-07-06 19:36             ` Mark Cave-Ayland
2020-07-07  7:03               ` Gerd Hoffmann
2020-07-07 16:17                 ` Mark Cave-Ayland
2020-07-07 17:38                   ` Gerd Hoffmann
2020-07-07 19:52                 ` Sam Ravnborg
2020-07-07 21:06                   ` Mark Cave-Ayland

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=20200704145212.GA791554@ravnborg.org \
    --to=sam@ravnborg.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=kraxel@redhat.com \
    --cc=mark.cave-ayland@ilande.co.uk \
    /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.