| Message ID | 20210714145804.2530727-1-geert@linux-m68k.org |
|---|---|
| Headers | show |
| Series | video: fbdev: ssd1307fb: Optimizations and improvements | expand |
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 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
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
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 drivers/video/fbdev/ssd1307fb.c | 143 +++++++++++++++++++++----------- 1 file changed, 96 insertions(+), 47 deletions(-)