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