| Message ID | 1408891857-14258-1-git-send-email-djkurtz@chromium.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
This patch works on my hardware. Xorg starts up fine with fbdev now. Thanks for the fix! --Günther Daniel Kurtz <djkurtz@chromium.org> writes: > Commit [0] stopped setting fix.smem_start and fix.smem_len when creating > the fbdev. > > [0] 2f1eab8d8ab59e799f7d51d62410b398607a7bc3 > drm/exynos/fbdev: don't set fix.smem/mmio_{start,len} > > However, smem_len is used by some userland applications to calculate the > size for mmap. In particular, it is used by xf86-video-fbdev: > > http://cgit.freedesktop.org/xorg/xserver/tree/hw/xfree86/fbdevhw/fbdevhw.c?id=xorg-server-1.15.99.903#n571 > > So, let's restore setting the smem_len to unbreak things for these users. > > Note: we are still leaving smem_start set to 0. > > Reported-by: Siarhei Siamashka <siarhei.siamashka@gmail.com> > Reported-by: Günther Noack <me@guenthernoack.de> > Signed-off-by: Daniel Kurtz <djkurtz@chromium.org> > --- > I am able to compile test this change, but would appreciate help testing it > on a system that uses xf86-video-fbdev. > > Thanks! > > drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c > index 5a7cd8b..f865736 100644 > --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c > +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c > @@ -125,6 +125,7 @@ static int exynos_drm_fbdev_update(struct drm_fb_helper *helper, > > fbi->screen_base = buffer->kvaddr; > fbi->screen_size = size; > + fbi->fix.smem_len = size; > > return 0; > } > -- > 2.1.0.rc2.206.gedb03e5
On Sun, Aug 24, 2014 at 4:50 PM, Daniel Kurtz <djkurtz@chromium.org> wrote: > Commit [0] stopped setting fix.smem_start and fix.smem_len when creating > the fbdev. > > [0] 2f1eab8d8ab59e799f7d51d62410b398607a7bc3 > drm/exynos/fbdev: don't set fix.smem/mmio_{start,len} > > However, smem_len is used by some userland applications to calculate the > size for mmap. In particular, it is used by xf86-video-fbdev: > > http://cgit.freedesktop.org/xorg/xserver/tree/hw/xfree86/fbdevhw/fbdevhw.c?id=xorg-server-1.15.99.903#n571 > > So, let's restore setting the smem_len to unbreak things for these users. > > Note: we are still leaving smem_start set to 0. Doesn't this cause a system crash when userspace (e.g. fbtest) writes into the mmap()ed /dev/fb*, as the wrong MMIO region is mapped? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
On Thu, Sep 25, 2014 at 5:32 PM, Geert Uytterhoeven <geert@linux-m68k.org> wrote: > On Sun, Aug 24, 2014 at 4:50 PM, Daniel Kurtz <djkurtz@chromium.org> wrote: >> Commit [0] stopped setting fix.smem_start and fix.smem_len when creating >> the fbdev. >> >> [0] 2f1eab8d8ab59e799f7d51d62410b398607a7bc3 >> drm/exynos/fbdev: don't set fix.smem/mmio_{start,len} >> >> However, smem_len is used by some userland applications to calculate the >> size for mmap. In particular, it is used by xf86-video-fbdev: >> >> http://cgit.freedesktop.org/xorg/xserver/tree/hw/xfree86/fbdevhw/fbdevhw.c?id=xorg-server-1.15.99.903#n571 >> >> So, let's restore setting the smem_len to unbreak things for these users. >> >> Note: we are still leaving smem_start set to 0. > > Doesn't this cause a system crash when userspace (e.g. fbtest) writes into > the mmap()ed /dev/fb*, as the wrong MMIO region is mapped? Do you see a crash during testing, or is your question hypothetical? I don't think there will be one. exynos's fbev defines its own fb_ops.fb_mmap, which uses dma_mmap_attrs() to mmap the fb's gem buffer, which was allocated by dma_alloc_attrs(). This bypasses the code in drivers/video/fbmem.c:fb_mmap() that references fix.smem_start. But, perhaps I am missing something? -Dan > > Gr{oetje,eeting}s, > > Geert > > -- > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org > > In personal conversations with technical people, I call myself a hacker. But > when I'm talking to journalists I just say "programmer" or something like that. > -- Linus Torvalds
On Thu, Sep 25, 2014 at 12:07 PM, Daniel Kurtz <djkurtz@chromium.org> wrote: > On Thu, Sep 25, 2014 at 5:32 PM, Geert Uytterhoeven > <geert@linux-m68k.org> wrote: >> On Sun, Aug 24, 2014 at 4:50 PM, Daniel Kurtz <djkurtz@chromium.org> wrote: >>> Commit [0] stopped setting fix.smem_start and fix.smem_len when creating >>> the fbdev. >>> >>> [0] 2f1eab8d8ab59e799f7d51d62410b398607a7bc3 >>> drm/exynos/fbdev: don't set fix.smem/mmio_{start,len} >>> >>> However, smem_len is used by some userland applications to calculate the >>> size for mmap. In particular, it is used by xf86-video-fbdev: >>> >>> http://cgit.freedesktop.org/xorg/xserver/tree/hw/xfree86/fbdevhw/fbdevhw.c?id=xorg-server-1.15.99.903#n571 >>> >>> So, let's restore setting the smem_len to unbreak things for these users. >>> >>> Note: we are still leaving smem_start set to 0. >> >> Doesn't this cause a system crash when userspace (e.g. fbtest) writes into >> the mmap()ed /dev/fb*, as the wrong MMIO region is mapped? > > Do you see a crash during testing, or is your question hypothetical? It was hypothetical. > I don't think there will be one. exynos's fbev defines its own > fb_ops.fb_mmap, which uses dma_mmap_attrs() to mmap the fb's gem > buffer, which was allocated by dma_alloc_attrs(). This bypasses the > code in drivers/video/fbmem.c:fb_mmap() that references > fix.smem_start. > > But, perhaps I am missing something? Thanks, having your own mapping function explains the lack of crashes. Still, some weird software may map /dev/mem instead of /dev/fb0, and use fb_fix.smem_start. But that's also unsafe in the context of LPAE. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c index 5a7cd8b..f865736 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c @@ -125,6 +125,7 @@ static int exynos_drm_fbdev_update(struct drm_fb_helper *helper, fbi->screen_base = buffer->kvaddr; fbi->screen_size = size; + fbi->fix.smem_len = size; return 0; }
Commit [0] stopped setting fix.smem_start and fix.smem_len when creating the fbdev. [0] 2f1eab8d8ab59e799f7d51d62410b398607a7bc3 drm/exynos/fbdev: don't set fix.smem/mmio_{start,len} However, smem_len is used by some userland applications to calculate the size for mmap. In particular, it is used by xf86-video-fbdev: http://cgit.freedesktop.org/xorg/xserver/tree/hw/xfree86/fbdevhw/fbdevhw.c?id=xorg-server-1.15.99.903#n571 So, let's restore setting the smem_len to unbreak things for these users. Note: we are still leaving smem_start set to 0. Reported-by: Siarhei Siamashka <siarhei.siamashka@gmail.com> Reported-by: Günther Noack <me@guenthernoack.de> Signed-off-by: Daniel Kurtz <djkurtz@chromium.org> --- I am able to compile test this change, but would appreciate help testing it on a system that uses xf86-video-fbdev. Thanks! drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 1 + 1 file changed, 1 insertion(+)