Hi Michael,
On Thu, 20 Mar 2025 at 21:15, Michael Kelley <mhkli...@outlook.com> wrote:
> From: Geert Uytterhoeven <ge...@linux-m68k.org> Sent: Thursday, March 20,
> 2025 3:46 AM
> > On Wed, 19 Mar 2025 at 21:29, Michael Kelley <mhkli...@outlook.com> wrote:
> > > From: Helge Deller <del...@gmx.de> Sent: Tuesday, March 18, 2025 1:16 AM
> > > > On 3/18/25 03:05, Michael Kelley wrote:
> > > > > The fbdev deferred I/O support was originally added to the hyperv_fb
> > > > > driver in the
> > > > > 5.6 kernel, and based on my recent experiments, it has never worked
> > > > > correctly when
> > > > > the framebuffer is allocated from kernel memory. fbdev deferred I/O
> > > > > support for using
> > > > > kernel memory as the framebuffer was originally added in commit
> > > > > 37b4837959cb9
> > > > > back in 2008 in Linux 2.6.29. But I don't see how it ever worked
> > > > > properly, unless
> > > > > changes in generic memory management somehow broke it in the
> > > > > intervening years.
> > > > >
> > > > > I think I know how to fix all this. But before working on a patch, I
> > > > > wanted to check
> > > > > with the fbdev community to see if this might be a known issue and
> > > > > whether there
> > > > > is any additional insight someone might offer. Thanks for any
> > > > > comments or help.
> > > >
> > > > I haven't heard of any major deferred-i/o issues since I've jumped into
> > > > fbdev
> > > > maintenance. But you might be right, as I haven't looked much into it
> > > > yet and
> > > > there are just a few drivers using it.
> > >
> > > Thanks for the input. In the fbdev directory, there are 9 drivers using
> > > deferred I/O.
> > > Of those, 6 use vmalloc() to allocate the framebuffer, and that path
> > > works just fine.
> > > The other 3 use alloc_pages(), dma_alloc_coherent(), or
> > > __get_free_pages(), all of
> > > which manifest the underlying problem when munmap()'ed. Those 3 drivers
> > > are:
> > >
> > > * hyperv_fb.c, which I'm working with
> > > * sh_mobile_lcdcfb.c
> > > * ssd1307fb.c
> >
> > Nowadays sh_mobile_lcdcfb is used only on various SuperH boards
> > (I have no hardware to test).
> >
> > sh_mobile_lcdcfb was used on ARM-based SH/R-Mobile SoCs until DT
> > support was added to the DRM driver for the corresponding hardware.
> > The platform using it was migrated to DRM in commit 138588e9fa237f97
> > ("ARM: dts: renesas: r8a7740: Add LCDC nodes") in v6.8). At the time
> > of the conversion, fbtest worked fine with sh_mobile_lcdcfb.
>
> OK, good to know. sh_mobile_lcdcfb gets its framebuffer using
> dma_alloc_coherent(). Do you recall how big the framebuffer was?
> If over 4 MiB, dma_alloc_coherent() would have allocated from CMA,
> and that works OK.
1536000 bytes (800x480 (960 virtual), 16bpp), i.e. less than 4 MiB.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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
