Panic booting qemu-system-sparc64 with bochs_drm

[Sam Ravnborg]

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