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