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