mirror of
git://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs.git
synced 2026-10-28 12:53:14 +01:00
Muhammad Bilal
cc7cd2a922
sm750_hw_imageblit() advances its monochrome source pointer by
src_delta per scanline, and computes the correct rounded-up stride
internally as:
bytes_per_scan = (width + start_bit + 7) / 8;
Its only caller, lynxfb_ops_imageblit(), instead passed src_delta as
image->width >> 3. For widths not a multiple of 8 this under-counted
the stride, so the source pointer fell further behind the real
per-scanline layout on every line, corrupting the rendered image.
Rather than just fixing the caller's calculation, remove src_delta
as a parameter entirely and have sm750_hw_imageblit() advance by the
bytes_per_scan it already computes for itself. There has only ever
been one caller, and that caller was passing an out-of-sync
derivative of the same width/start_bit values sm750_hw_imageblit()
already has, so keeping stride as a separate parameter served no
purpose beyond letting the two calculations drift apart, which is
exactly what happened here.
Rounding up, rather than down, is the direction consistent with the
rest of the fbdev core: struct fb_image mono bitmap data (the same
image->data this driver receives) is walked elsewhere with byte
strides derived from a ceiling division of width by 8. The generic
mono bit iterator in drivers/video/fbdev/core/fb_imageblit.h advances
scanlines with "iter->data += BITS_TO_BYTES(iter->width)", and
BITS_TO_BYTES() (include/linux/bitops.h) is a ceiling division.
sm750_hw_imageblit()'s own "(width + start_bit + 7) / 8" is that same
ceiling division with an added start_bit offset, so the caller's
">> 3" (floor) was the one calculation out of step with how this data
layout is handled everywhere else.
Found by code review of sm750_hw_imageblit()'s internal stride
calculation against what its only caller was passing in, and
confirmed with a clean -Werror build. I do not have this hardware,
so this has not been exercised at runtime on real sm750 silicon.
Fixes: 81dee67e21 ("staging: sm750fb: add sm750 to staging")
Cc: [email protected]
Reviewed-by: Dan Carpenter <[email protected]>
Signed-off-by: Muhammad Bilal <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Introduction: SM750 of Silicon MOtion is pci express display controller device. The SM750 embedded graphics features include: - dual display - 2D acceleration - 16MB integrated video memory About the kernel module parameter of driver: Use 1280,8bpp index color and 60 hz mode: insmod ./sm750fb.ko g_option="1280x1024-8@60" Disable MTRR,Disable 2d acceleration,Disable hardware cursor, and use a 800x600 mode : insmod ./sm750fb.ko g_option="noaccel:nomtrr:nohwc:800x600" dual frame buffer for driver with "dual" parameter insmod ./sm750fb.ko g_option="dual,800x600:1024x768" it will create fb0 and fb1 (or fb1,fb2 if fb0 already exist) under /dev and user can use con2fb to link fbX and ttyX Notes: 1) if you build the driver with built-in method, the parameter you edited in the grub config file will be also the same format as above modular method,but additionally add "video=sm750fb:" ahead of parameters,so,it looks like: video=sm750fb:noaccel,1280x1024@60,otherparam,etc... it equal to modular method with below command: insmod ./sm750fb.ko g_option="noaccel:1280x1024@60:otherparm:etc..." 2) if you put 800x600 into the parameter without bpp and refresh rate, kernel driver will defaulty use 16bpp and 60hz Important: if you have vesafb enabled in your config then /dev/fb0 will be created by vesafb and this driver will use fb1, fb2. In that case, you need to configure your X-server to use fb1. Another simple althernative is to disable vesafb from your config.