Panic booting qemu-system-sparc64 with bochs_drm

[Mark Cave-Ayland]

On 07/07/2020 20:52, Sam Ravnborg wrote:

> 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.

Thanks Sam! If you want to add me as a CC then I'm happy to test if needed.

>> 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.

I'm afraid this part is beyond my current knowledge of the various framebuffer
implementations within the kernel :/


ATB,

Mark.