Hi Gerd.
On Tue, Jul 07, 2020 at 09:03:41AM +0200, Gerd Hoffmann wrote:
Yes, that's correct - I can confirm that the simplified diff below works:
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c index 5609e164805f..83af05fac604 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);
fb_memcpy_tofb(dst, src, len);fb_memcpy_tofb is #defined to sbus_memcpy_toio @ sparc which looks wrong to me given that this is a pci not a sbus device. sparc also has memcpy_toio which looks better to me.
Looked at sbus_memcpy_toio and memcpy_toio for sparc64. They are essential the same. Only read bytes in little-endian format, the other read bytes in big-endian format. So thats the same.
I will prepare a proper patch with focus on fixin sparc64 only.
There are blit helpers in drm_format_helper.c which already use memcpy_toio(), I guess we should do the same here. Not fully sure we can use memcpy_toio() unconditionally here. Given that a shadow framebuffer makes sense only in case the real framebuffer is not in normal ram we probably can.
Not so sure about this part. We unconditionally enable the use of a shadow framebuffer. But on some archs the framebuffer is not in io space - but then on these architectures memcpy_toio boils down to a simple memcpy. So maybe in the end everything is fine.
Sam