From: Sam Ravnborg <sam@ravnborg.org> To: dri-devel@lists.freedesktop.org Cc: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>, Gerd Hoffmann <kraxel@redhat.com>, Thomas Zimmermann <tzimmermann@suse.de>, sparclinux@vger.kernel.org, Sam Ravnborg <sam@ravnborg.org>, "David S. Miller" <davem@davemloft.net> Subject: [PATCH] drm/drm_fb_helper: fix fbdev with sparc64 Date: Thu, 09 Jul 2020 19:30:16 +0000 [thread overview] Message-ID: <20200709193016.291267-1-sam@ravnborg.org> (raw) Mark reported that sparc64 would panic while booting using qemu. Mark bisected this to a patch that introduced generic fbdev emulation to the bochs DRM driver. Mark pointed out that a similar bug was fixed before where the sys helpers was replaced by cfb helpers. The culprint here is that the framebuffer reside in IO memory which requires SPARC ASI_PHYS (physical) loads and stores. The current bohcs DRM driver uses a shadow buffer. So all copying to the framebuffer happens in drm_fb_helper_dirty_blit_real(). The fix is to replace the memcpy with memcpy_toio() from io.h. memcpy_toio() uses writeb() where the original fbdev code used sbus_memcpy_toio(). The latter uses sbus_writeb(). The difference between writeb() and sbus_memcpy_toio() is that writeb() writes bytes in little-endian, where sbus_writeb() writes bytes in big-endian. As endian does not matter for byte writes they are the same. So we can safely use memcpy_toio() here. For many architectures memcpy_toio() is a simple memcpy(). One sideeffect that is unknow is if this has any impact on other architectures. So far the analysis tells that this change is OK for other arch's. but testing would be good. Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Reported-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Tested-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Cc: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: sparclinux@vger.kernel.org --- drivers/gpu/drm/drm_fb_helper.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c index 5609e164805f..4d05b0ab1592 100644 --- a/drivers/gpu/drm/drm_fb_helper.c +++ b/drivers/gpu/drm/drm_fb_helper.c @@ -399,7 +399,7 @@ static void drm_fb_helper_dirty_blit_real(struct drm_fb_helper *fb_helper, unsigned int y; for (y = clip->y1; y < clip->y2; y++) { - memcpy(dst, src, len); + memcpy_toio(dst, src, len); src += fb->pitches[0]; dst += fb->pitches[0]; } -- 2.25.1
WARNING: multiple messages have this Message-ID (diff)
From: Sam Ravnborg <sam@ravnborg.org> To: dri-devel@lists.freedesktop.org Cc: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>, Gerd Hoffmann <kraxel@redhat.com>, Thomas Zimmermann <tzimmermann@suse.de>, sparclinux@vger.kernel.org, Sam Ravnborg <sam@ravnborg.org>, "David S. Miller" <davem@davemloft.net> Subject: [PATCH] drm/drm_fb_helper: fix fbdev with sparc64 Date: Thu, 9 Jul 2020 21:30:16 +0200 [thread overview] Message-ID: <20200709193016.291267-1-sam@ravnborg.org> (raw) Mark reported that sparc64 would panic while booting using qemu. Mark bisected this to a patch that introduced generic fbdev emulation to the bochs DRM driver. Mark pointed out that a similar bug was fixed before where the sys helpers was replaced by cfb helpers. The culprint here is that the framebuffer reside in IO memory which requires SPARC ASI_PHYS (physical) loads and stores. The current bohcs DRM driver uses a shadow buffer. So all copying to the framebuffer happens in drm_fb_helper_dirty_blit_real(). The fix is to replace the memcpy with memcpy_toio() from io.h. memcpy_toio() uses writeb() where the original fbdev code used sbus_memcpy_toio(). The latter uses sbus_writeb(). The difference between writeb() and sbus_memcpy_toio() is that writeb() writes bytes in little-endian, where sbus_writeb() writes bytes in big-endian. As endian does not matter for byte writes they are the same. So we can safely use memcpy_toio() here. For many architectures memcpy_toio() is a simple memcpy(). One sideeffect that is unknow is if this has any impact on other architectures. So far the analysis tells that this change is OK for other arch's. but testing would be good. Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Reported-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Tested-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Cc: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: sparclinux@vger.kernel.org --- drivers/gpu/drm/drm_fb_helper.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c index 5609e164805f..4d05b0ab1592 100644 --- a/drivers/gpu/drm/drm_fb_helper.c +++ b/drivers/gpu/drm/drm_fb_helper.c @@ -399,7 +399,7 @@ static void drm_fb_helper_dirty_blit_real(struct drm_fb_helper *fb_helper, unsigned int y; for (y = clip->y1; y < clip->y2; y++) { - memcpy(dst, src, len); + memcpy_toio(dst, src, len); src += fb->pitches[0]; dst += fb->pitches[0]; } -- 2.25.1 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
next reply other threads:[~2020-07-09 19:30 UTC|newest] Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-07-09 19:30 Sam Ravnborg [this message] 2020-07-09 19:30 ` [PATCH] drm/drm_fb_helper: fix fbdev with sparc64 Sam Ravnborg 2020-07-10 1:36 ` kernel test robot 2020-07-10 1:36 ` kernel test robot 2020-07-10 1:36 ` kernel test robot 2020-07-10 6:28 ` Thomas Zimmermann 2020-07-10 6:28 ` Thomas Zimmermann 2020-07-10 19:10 ` Mark Cave-Ayland 2020-07-10 19:10 ` Mark Cave-Ayland 2020-07-10 21:11 ` Dave Airlie 2020-07-10 21:11 ` Dave Airlie 2020-07-13 16:21 ` Daniel Vetter 2020-07-13 16:21 ` Daniel Vetter 2020-07-13 18:39 ` Sam Ravnborg 2020-07-13 18:39 ` Sam Ravnborg 2020-07-13 19:32 ` Daniel Vetter 2020-07-13 19:32 ` Daniel Vetter 2020-07-14 6:41 ` Thomas Zimmermann 2020-07-14 6:41 ` Thomas Zimmermann 2020-07-14 8:41 ` Daniel Vetter 2020-07-14 8:41 ` Daniel Vetter 2020-07-14 8:56 ` Thomas Zimmermann 2020-07-14 8:56 ` Thomas Zimmermann 2020-07-24 4:53 ` Dave Airlie 2020-07-24 4:53 ` Dave Airlie 2020-07-24 6:23 ` Sam Ravnborg 2020-07-24 6:23 ` Sam Ravnborg 2020-07-24 8:09 ` Daniel Vetter 2020-07-24 8:09 ` Daniel Vetter 2020-07-24 6:56 ` Thomas Zimmermann 2020-07-24 6:56 ` Thomas Zimmermann
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=20200709193016.291267-1-sam@ravnborg.org \ --to=sam@ravnborg.org \ --cc=davem@davemloft.net \ --cc=dri-devel@lists.freedesktop.org \ --cc=kraxel@redhat.com \ --cc=mark.cave-ayland@ilande.co.uk \ --cc=sparclinux@vger.kernel.org \ --cc=tzimmermann@suse.de \ /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: linkBe 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.