[PATCH] drm/bochs: switch fb_ops over to use drm_fb_helper_cfb helpers

Mark Cave-Ayland mark.cave-ayland at ilande.co.uk
Mon Jul 3 08:33:51 UTC 2017


On 03/07/17 09:11, Daniel Vetter wrote:

> On Sun, Jul 02, 2017 at 10:52:43PM +0100, Mark Cave-Ayland wrote:
>> The current drm_fb_helper_sys helpers referenced in fb_ops assume that the
>> video memory is in system RAM. This is not the case for sparc which uses direct
>> physical memory accesses for IO memory and causes the bochs_drm module to panic
>> immediately upon startup as it tries to initialise the framebuffer.
>>
>> Switching fb_ops over to use the drm_fb_helper_cfb helpers ensures that the
>> correct accesses are used on sparc, fixing the panic and allowing the
>> bochs_drm module to function under qemu-system-sparc64.
>>
>> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland at ilande.co.uk>
> 
> So is this generally true for bochs, or is this now going to broken
> platforms where the bochs framebuffer is in system memory?
> 
> I'm not entirely clear on that from your commit message ...

Here's my original analysis on the problem:
http://lkml.iu.edu/hypermail/linux/kernel/1706.3/04745.html where you
can see the issue is that on sparc you can't just assume that address
returned from ioremap() is a virtual address.

Most of the context for this change comes from commit 68648ed which has
this initial paragraph:

<quote>
fbdev: add drawing functions for framebuffers in system RAM

The generic drawing functions (cfbimgblt, cfbcopyarea, cfbfillrect)
assume that the framebuffer is in IO memory.  However, we have 3 drivers
(hecubafb, arcfb, and vfb) where the framebuffer is allocated from
system RAM (via vmalloc). Using _raw_read/write and family for these
drivers (as used in the cfb* functions) is illegal, especially in other
platforms.
</quote>

Given that bochs_drm is a PCI device which supports both memory and IO
accesses then I would think that the above comment about using
_raw_read/write isn't relevant here and this is the correct fix (for
reference I do see that nouveau/radeon/i915 which are also PCI-based are
already using the cfb helper functions).

Hopefully Gerd has experience using bochs_drm with other non-x86 systems
and can comment further.


ATB,

Mark.



More information about the dri-devel mailing list