Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1679761
| From | Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH] drm/bochs: switch fb_ops over to use drm_fb_helper_cfb helpers |
| Date | 2017-07-03 10:40 +0200 |
| Message-ID | <tZ53I-70B-13@gated-at.bofh.it> (permalink) |
| References | <tYV4l-88R-7@gated-at.bofh.it> <tZ4Km-6Tf-11@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
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.
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[PATCH] drm/bochs: switch fb_ops over to use drm_fb_helper_cfb helpers Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> - 2017-07-03 00:00 +0200
Re: [PATCH] drm/bochs: switch fb_ops over to use drm_fb_helper_cfb helpers Daniel Vetter <daniel@ffwll.ch> - 2017-07-03 10:20 +0200
Re: [PATCH] drm/bochs: switch fb_ops over to use drm_fb_helper_cfb helpers Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> - 2017-07-03 10:40 +0200
Re: [PATCH] drm/bochs: switch fb_ops over to use drm_fb_helper_cfb helpers Gerd Hoffmann <kraxel@redhat.com> - 2017-07-03 11:00 +0200
Re: [PATCH] drm/bochs: switch fb_ops over to use drm_fb_helper_cfb helpers Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> - 2017-07-03 11:10 +0200
csiph-web