Message ID | 20210714145804.2530727-1-geert@linux-m68k.org (mailing list archive) |
---|---|
Headers | show |
Series | video: fbdev: ssd1307fb: Optimizations and improvements | expand |
Hi Geert, On Wed, Jul 14, 2021 at 04:57:59PM +0200, Geert Uytterhoeven wrote: > Hi all, > > This patch series optimizes console operations on ssd1307fb, after the > customary fixes and cleanups. What is required to to have a drm driver that could do the same? Note: I will take a look at the patches a bit later. Sam
Hi Sam, On Wed, Jul 14, 2021 at 5:27 PM Sam Ravnborg <sam@ravnborg.org> wrote: > On Wed, Jul 14, 2021 at 04:57:59PM +0200, Geert Uytterhoeven wrote: > > This patch series optimizes console operations on ssd1307fb, after the > > customary fixes and cleanups. > > What is required to to have a drm driver that could do the same? Add monochrome support to DRM? > Note: I will take a look at the patches a bit later. TIA! Gr{oetje,eeting}s, Geert
Hi Geert, On Wed, Jul 14, 2021 at 04:57:59PM +0200, Geert Uytterhoeven wrote: > Hi all, > > This patch series optimizes console operations on ssd1307fb, after the > customary fixes and cleanups. > > Currently, each screen update triggers an I2C transfer of all screen > data, up to 1 KiB of data for a 128x64 display, which takes at least 20 > ms in Fast mode. While many displays are smaller, and thus require less > data to be transferred, 20 ms is still an optimistic value, as the > actual data transfer may be much slower, especially on bitbanged I2C > drivers. After this series, the amount of data transfer is reduced, as > fillrect, copyarea, and imageblit only update the rectangle that > changed. > > This has been tested on an Adafruit FeatherWing OLED with an SSD1306 > controller and a 128x32 OLED, connected to an OrangeCrab ECP5 FPGA board > running a 64 MHz VexRiscv RISC-V softcore, where it reduced the CPU > usage for blinking the cursor from more than 70% to ca. 10%. > > Thanks for your comments! > > Geert Uytterhoeven (5): > video: fbdev: ssd1307fb: Propagate errors via > ssd1307fb_update_display() > video: fbdev: ssd1307fb: Simplify ssd1307fb_update_display() > video: fbdev: ssd1307fb: Extract ssd1307fb_set_address_range() > video: fbdev: ssd1307fb: Optimize screen updates > video: fbdev: ssd1307fb: Cache address ranges A few comments left for a couple of patches. The remaining patches are: Acked-by: Sam Ravnborg <sam@ravnborg.org> Do you have commit rights to drm-misc-next? Sam
Hi Sam, On Mon, Jul 19, 2021 at 9:23 PM Sam Ravnborg <sam@ravnborg.org> wrote: > On Wed, Jul 14, 2021 at 04:57:59PM +0200, Geert Uytterhoeven wrote: > > This patch series optimizes console operations on ssd1307fb, after the > > customary fixes and cleanups. > > > > Currently, each screen update triggers an I2C transfer of all screen > > data, up to 1 KiB of data for a 128x64 display, which takes at least 20 > > ms in Fast mode. While many displays are smaller, and thus require less > > data to be transferred, 20 ms is still an optimistic value, as the > > actual data transfer may be much slower, especially on bitbanged I2C > > drivers. After this series, the amount of data transfer is reduced, as > > fillrect, copyarea, and imageblit only update the rectangle that > > changed. > > > > This has been tested on an Adafruit FeatherWing OLED with an SSD1306 > > controller and a 128x32 OLED, connected to an OrangeCrab ECP5 FPGA board > > running a 64 MHz VexRiscv RISC-V softcore, where it reduced the CPU > > usage for blinking the cursor from more than 70% to ca. 10%. > > > > Thanks for your comments! > > > > Geert Uytterhoeven (5): > > video: fbdev: ssd1307fb: Propagate errors via > > ssd1307fb_update_display() > > video: fbdev: ssd1307fb: Simplify ssd1307fb_update_display() > > video: fbdev: ssd1307fb: Extract ssd1307fb_set_address_range() > > video: fbdev: ssd1307fb: Optimize screen updates > > video: fbdev: ssd1307fb: Cache address ranges > > A few comments left for a couple of patches. > The remaining patches are: > Acked-by: Sam Ravnborg <sam@ravnborg.org> Thank you! > Do you have commit rights to drm-misc-next? No I have not (and I don't think I should). Gr{oetje,eeting}s, Geert
Hi Geert, On Tue, Jul 20, 2021 at 09:33:11AM +0200, Geert Uytterhoeven wrote: > Hi Sam, > > On Mon, Jul 19, 2021 at 9:23 PM Sam Ravnborg <sam@ravnborg.org> wrote: > > On Wed, Jul 14, 2021 at 04:57:59PM +0200, Geert Uytterhoeven wrote: > > > This patch series optimizes console operations on ssd1307fb, after the > > > customary fixes and cleanups. > > > > > > Currently, each screen update triggers an I2C transfer of all screen > > > data, up to 1 KiB of data for a 128x64 display, which takes at least 20 > > > ms in Fast mode. While many displays are smaller, and thus require less > > > data to be transferred, 20 ms is still an optimistic value, as the > > > actual data transfer may be much slower, especially on bitbanged I2C > > > drivers. After this series, the amount of data transfer is reduced, as > > > fillrect, copyarea, and imageblit only update the rectangle that > > > changed. > > > > > > This has been tested on an Adafruit FeatherWing OLED with an SSD1306 > > > controller and a 128x32 OLED, connected to an OrangeCrab ECP5 FPGA board > > > running a 64 MHz VexRiscv RISC-V softcore, where it reduced the CPU > > > usage for blinking the cursor from more than 70% to ca. 10%. > > > > > > Thanks for your comments! > > > > > > Geert Uytterhoeven (5): > > > video: fbdev: ssd1307fb: Propagate errors via > > > ssd1307fb_update_display() > > > video: fbdev: ssd1307fb: Simplify ssd1307fb_update_display() > > > video: fbdev: ssd1307fb: Extract ssd1307fb_set_address_range() > > > video: fbdev: ssd1307fb: Optimize screen updates > > > video: fbdev: ssd1307fb: Cache address ranges > > > > A few comments left for a couple of patches. > > The remaining patches are: > > Acked-by: Sam Ravnborg <sam@ravnborg.org> > > Thank you! > > > Do you have commit rights to drm-misc-next? > > No I have not (and I don't think I should). I would love to have you around for the fbdev stuff, as you knows a ton more about fbdev than I do - I am just pretending. And it would then be good if you could apply patches too. I for one may be off for shorter or longer periods as this is purely driven by interest. Note: I assume you will resend the series - then I can apply. Sam
On Thu, Jul 15, 2021 at 8:54 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > Hi Sam, > > On Wed, Jul 14, 2021 at 5:27 PM Sam Ravnborg <sam@ravnborg.org> wrote: > > On Wed, Jul 14, 2021 at 04:57:59PM +0200, Geert Uytterhoeven wrote: > > > This patch series optimizes console operations on ssd1307fb, after the > > > customary fixes and cleanups. > > > > What is required to to have a drm driver that could do the same? > > Add monochrome support to DRM? I think the bits that are missing for that are - wiring up the conversion from R* formats to their fbdev counterparts in the emulation helper (if you want to support userspace sending the native format directly through fbdev Everything else is there and we have drivers doing this, e.g. drm/tiny/repaper.c. -Daniel > > > Note: I will take a look at the patches a bit later. > > TIA! > > 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