Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1679761

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

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

Show all headers | View raw


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


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