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
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
