fbdev/sm712fb: Use correct initializer macros for struct fb_ops

Only initialize mmap and draw helpers with macros; leave read/write
callbacks to driver implementations. Fixes the following warnings:

fbdev/sm712fb: Use correct initializer macros for struct fb_ops

Only initialize mmap and draw helpers with macros; leave read/write
callbacks to driver implementations. Fixes the following warnings:

CC [M] drivers/video/fbdev/sm712fb.o
sm712fb.c:1355:25: warning: initialized field overwritten [-Woverride-init]
1355 | .fb_fillrect = cfb_fillrect,
| ^~~~~~~~~~~~
sm712fb.c:1355:25: note: (near initialization for 'smtcfb_ops.fb_fillrect')
sm712fb.c:1356:25: warning: initialized field overwritten [-Woverride-init]
1356 | .fb_imageblit = cfb_imageblit,
| ^~~~~~~~~~~~~
sm712fb.c:1356:25: note: (near initialization for 'smtcfb_ops.fb_imageblit')
sm712fb.c:1357:25: warning: initialized field overwritten [-Woverride-init]
1357 | .fb_copyarea = cfb_copyarea,
| ^~~~~~~~~~~~
sm712fb.c:1357:25: note: (near initialization for 'smtcfb_ops.fb_copyarea')
sm712fb.c:1358:25: warning: initialized field overwritten [-Woverride-init]
1358 | .fb_read = smtcfb_read,
| ^~~~~~~~~~~
sm712fb.c:1358:25: note: (near initialization for 'smtcfb_ops.fb_read')
sm712fb.c:1359:25: warning: initialized field overwritten [-Woverride-init]
1359 | .fb_write = smtcfb_write,
| ^~~~~~~~~~~~
sm712fb.c:1359:25: note: (near initialization for 'smtcfb_ops.fb_write')

Signed-off-by: Thomas Zimmermann <[email protected]>
Fixes: 586132cf1d38 ("fbdev/sm712fb: Initialize fb_ops to fbdev I/O-memory helpers")
Cc: Thomas Zimmermann <[email protected]>
Cc: Javier Martinez Canillas <[email protected]>
Cc: Sudip Mukherjee <[email protected]>
Cc: Teddy Wang <[email protected]>
Cc: Sam Ravnborg <[email protected]>
Cc: Helge Deller <[email protected]>
Cc: Arnd Bergmann <[email protected]>
Cc: [email protected]
Reviewed-by: Javier Martinez Canillas <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

show more ...

fbdev/sm712fb: Initialize fb_ops to fbdev I/O-memory helpers

Initialize the instance of struct fb_ops with fbdev initializer
macros for framebuffers in I/O address space. Set the read/write,
draw an

fbdev/sm712fb: Initialize fb_ops to fbdev I/O-memory helpers

Initialize the instance of struct fb_ops with fbdev initializer
macros for framebuffers in I/O address space. Set the read/write,
draw and mmap callbacks to the correct implementation and avoid
implicit defaults. Also select the necessary I/O helpers in Kconfig.

Fbdev drivers sometimes rely on the callbacks being NULL for a
default implementation to be invoked; hence requiring the I/O
helpers to be built in any case. Setting all callbacks in all
drivers explicitly will allow to make the I/O helpers optional.
This benefits systems that do not use these functions.

No functional changes.

Signed-off-by: Thomas Zimmermann <[email protected]>
Acked-by: Javier Martinez Canillas <[email protected]>
Cc: Sudip Mukherjee <[email protected]>
Cc: Teddy Wang <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

show more ...

fbdev: Remove FBINFO_FLAG_DEFAULT from framebuffer_alloc()'ed structs

The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct
fbinfo.flags has been allocated to zero by framebuffer_alloc(). S

fbdev: Remove FBINFO_FLAG_DEFAULT from framebuffer_alloc()'ed structs

The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct
fbinfo.flags has been allocated to zero by framebuffer_alloc(). So
do not set it.

Flags should signal differences from the default values. After cleaning
up all occurrences of FBINFO_DEFAULT, the token will be removed.

v4:
* clarify commit message (Geert, Dan)
v2:
* fix commit message (Miguel)

Signed-off-by: Thomas Zimmermann <[email protected]>
Acked-by: Sam Ravnborg <[email protected]>
Cc: Jaya Kumar <[email protected]>
Cc: Helge Deller <[email protected]>
Cc: Peter Jones <[email protected]>
Cc: Sascha Hauer <[email protected]>
Cc: Pengutronix Kernel Team <[email protected]>
Cc: Shawn Guo <[email protected]>
Cc: Fabio Estevam <[email protected]>
Cc: NXP Linux Team <[email protected]>
Cc: Maik Broemme <[email protected]>
Cc: Jingoo Han <[email protected]>
Cc: Sudip Mukherjee <[email protected]>
Cc: Teddy Wang <[email protected]>
Cc: Michal Januszewski <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

show more ...

fbdev/sm712fb: Do not include <linux/screen_info.h>

Sm712fb's dependency on <linux/screen_info.h> is artificial in that
it only uses struct screen_info for its internals. Replace the use of
struct s

fbdev/sm712fb: Do not include <linux/screen_info.h>

Sm712fb's dependency on <linux/screen_info.h> is artificial in that
it only uses struct screen_info for its internals. Replace the use of
struct screen_info with a custom data structure and remove the include
of <linux/screen_info.h>.

Signed-off-by: Thomas Zimmermann <[email protected]>
Reviewed-by: Javier Martinez Canillas <[email protected]>
Cc: Sudip Mukherjee <[email protected]>
Cc: Teddy Wang <[email protected]>
Cc: Helge Deller <[email protected]>
Reviewed-by: Arnd Bergmann <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

show more ...

fbdev: Validate info->screen_{base, buffer} in fb_ops implementations

Push the test for info->screen_base from fb_read() and fb_write() into
the implementations of struct fb_ops.{fb_read,fb_write}.

fbdev: Validate info->screen_{base, buffer} in fb_ops implementations

Push the test for info->screen_base from fb_read() and fb_write() into
the implementations of struct fb_ops.{fb_read,fb_write}. In cases where
the driver operates on info->screen_buffer, test this field instead.

While bothi fields, screen_base and screen_buffer, are stored in the
same location, they refer to different address spaces. For correctness,
we want to test each field in exactly the code that uses it.

v2:
* also test screen_base in pvr2fb (Geert)
* also test screen_buffer in ivtvfb, arcfb, broadsheetfb,
hecubafb, metronomefb and ssd1307fb (Geert)
* give a rational for the change (Geert)

Signed-off-by: Thomas Zimmermann <[email protected]>
Tested-by: Sui Jingfeng <[email protected]>
Reviewed-by: Javier Martinez Canillas <[email protected]>
Acked-by: Helge Deller <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

show more ...

fbdev: Don't re-validate info->state in fb_ops implementations

The file-op entry points fb_read() and fb_write() verify that
info->state has been set to FBINFO_STATE_RUNNING. Remove the same
test fr

fbdev: Don't re-validate info->state in fb_ops implementations

The file-op entry points fb_read() and fb_write() verify that
info->state has been set to FBINFO_STATE_RUNNING. Remove the same
test from the implementations of struct fb_ops.{fb_read,fb_write}.

v2:
* also remove test from ivtvfb, braodsheetfb, hecubafb and
metronomefb (Geert)

Signed-off-by: Thomas Zimmermann <[email protected]>
Tested-by: Sui Jingfeng <[email protected]>
Reviewed-by: Javier Martinez Canillas <[email protected]>
Reviewed-by: Geert Uytterhoeven <[email protected]>
Acked-by: Helge Deller <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

show more ...

fbdev: Add support for the nomodeset kernel parameter

Support the kernel's nomodeset parameter for all PCI-based fbdev
drivers that use aperture helpers to remove other, hardware-agnostic
graphics d

fbdev: Add support for the nomodeset kernel parameter

Support the kernel's nomodeset parameter for all PCI-based fbdev
drivers that use aperture helpers to remove other, hardware-agnostic
graphics drivers.

The parameter is a simple way of using the firmware-provided scanout
buffer if the hardware's native driver is broken. The same effect
could be achieved with per-driver options, but the importance of the
graphics output for many users makes a single, unified approach
worthwhile.

With nomodeset specified, the fbdev driver module will not load. This
unifies behavior with similar DRM drivers. In DRM helpers, modules
first check the nomodeset parameter before registering the PCI
driver. As fbdev has no such module helpers, we have to modify each
driver individually.

The name 'nomodeset' is slightly misleading, but has been chosen for
historical reasons. Several drivers implemented it before it became a
general option for DRM. So keeping the existing name was preferred over
introducing a new one.

v2:
* print a warning if a driver does not init (Helge)
* wrap video_firmware_drivers_only() in helper

Signed-off-by: Thomas Zimmermann <[email protected]>
Reviewed-by: Javier Martinez Canillas <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

show more ...

fbdev: Remove conflicting devices on PCI bus

Remove firmware devices on the PCI bus, by calling
aperture_remove_conflicting_pci_devices() in the probe function of
each related fbdev driver. iSo far,

fbdev: Remove conflicting devices on PCI bus

Remove firmware devices on the PCI bus, by calling
aperture_remove_conflicting_pci_devices() in the probe function of
each related fbdev driver. iSo far, most of these drivers did not
remove conflicting VESA or EFI devices, or outride failed for
resource conflicts (i.e., matroxfb.) This must have been broken
for quite some time.

Signed-off-by: Thomas Zimmermann <[email protected]>
Reviewed-by: Javier Martinez Canillas <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

show more ...

video: fbdev: sm712fb: Fix crash in smtcfb_write()

When the sm712fb driver writes three bytes to the framebuffer, the
driver will crash:

BUG: unable to handle page fault for address: ffffc90001

video: fbdev: sm712fb: Fix crash in smtcfb_write()

When the sm712fb driver writes three bytes to the framebuffer, the
driver will crash:

BUG: unable to handle page fault for address: ffffc90001ffffff
RIP: 0010:smtcfb_write+0x454/0x5b0
Call Trace:
vfs_write+0x291/0xd60
? do_sys_openat2+0x27d/0x350
? __fget_light+0x54/0x340
ksys_write+0xce/0x190
do_syscall_64+0x43/0x90
entry_SYSCALL_64_after_hwframe+0x44/0xae

Fix it by removing the open-coded endianness fixup-code.

Signed-off-by: Zheyu Ma <[email protected]>
Signed-off-by: Helge Deller <[email protected]>

show more ...

video: fbdev: sm712fb: Fix crash in smtcfb_read()

Zheyu Ma reported this crash in the sm712fb driver when reading
three bytes from the framebuffer:

BUG: unable to handle page fault for address: ff

video: fbdev: sm712fb: Fix crash in smtcfb_read()

Zheyu Ma reported this crash in the sm712fb driver when reading
three bytes from the framebuffer:

BUG: unable to handle page fault for address: ffffc90001ffffff
RIP: 0010:smtcfb_read+0x230/0x3e0
Call Trace:
vfs_read+0x198/0xa00
? do_sys_openat2+0x27d/0x350
? __fget_light+0x54/0x340
ksys_read+0xce/0x190
do_syscall_64+0x43/0x90

Fix it by removing the open-coded endianess fixup-code and
by moving the pointer post decrement out the fb_readl() function.

Reported-by: Zheyu Ma <[email protected]>
Signed-off-by: Helge Deller <[email protected]>
Tested-by: Zheyu Ma <[email protected]>
Cc: [email protected]

show more ...

fbdev: sm712fb: handle ioremap() errors in probe

smtcfb_pci_probe() does not handle ioremap() errors for case 0x720. The
patch fixes that exactly like for case 0x710/2.

Found by Linux Driver Verifi

fbdev: sm712fb: handle ioremap() errors in probe

smtcfb_pci_probe() does not handle ioremap() errors for case 0x720. The
patch fixes that exactly like for case 0x710/2.

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Evgeny Novikov <[email protected]>
Cc: Sudip Mukherjee <[email protected]>
Cc: Teddy Wang <[email protected]>
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

show more ...

fbdev: sm712fb: set error code in probe

If smtcfb_pci_probe() does not detect a valid chip it cleans up
everything and returns 0. This can result in various bad things later.
The patch sets the erro

fbdev: sm712fb: set error code in probe

If smtcfb_pci_probe() does not detect a valid chip it cleans up
everything and returns 0. This can result in various bad things later.
The patch sets the error code on the corresponding path.

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Evgeny Novikov <[email protected]>
Cc: Sudip Mukherjee <[email protected]>
Cc: Teddy Wang <[email protected]>
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

show more ...

video: fbdev: sm712fb: fix an issue about iounmap for a wrong address

the sfb->fb->screen_base is not save the value get by iounmap() when
the chip id is 0x720. so iounmap() for address sfb->fb->scr

video: fbdev: sm712fb: fix an issue about iounmap for a wrong address

the sfb->fb->screen_base is not save the value get by iounmap() when
the chip id is 0x720. so iounmap() for address sfb->fb->screen_base
is not right.

Fixes: 1461d6672864854 ("staging: sm7xxfb: merge sm712fb with fbdev")
Cc: Andy Shevchenko <[email protected]>
Cc: Sudip Mukherjee <[email protected]>
Cc: Teddy Wang <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Dejin Zheng <[email protected]>
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

show more ...

video: constify fb ops across all drivers

Now that the fbops member of struct fb_info is const, we can start
making the ops const as well.

This does not cover all drivers; some actually modify the

video: constify fb ops across all drivers

Now that the fbops member of struct fb_info is const, we can start
making the ops const as well.

This does not cover all drivers; some actually modify the fbops struct,
for example to adjust for different configurations, and others do more
involved things that I'd rather not touch in practically obsolete
drivers. Mostly this is the low hanging fruit where we can add "const"
and be done with it.

v3:
- un-constify atyfb, mb862xx, nvidia and uvesabf (0day)

v2:
- fix typo (Christophe de Dinechin)
- use "static const" instead of "const static" in mx3fb.c
- also constify smscufx.c

Cc: [email protected]
Reviewed-by: Daniel Vetter <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/ce67f14435f3af498f2e8bf35ce4be11f7504132.1575390740.git.jani.nikula@intel.com

show more ...

video: fbdev: sm712fb: Use dev_get_drvdata

Instead of using to_pci_dev + pci_get_drvdata,
use dev_get_drvdata to make code simpler.

Signed-off-by: Chuhong Yuan <[email protected]>
Cc: Sudip Mukh

video: fbdev: sm712fb: Use dev_get_drvdata

Instead of using to_pci_dev + pci_get_drvdata,
use dev_get_drvdata to make code simpler.

Signed-off-by: Chuhong Yuan <[email protected]>
Cc: Sudip Mukherjee <[email protected]>
Cc: Teddy Wang <[email protected]>
[b.zolnierkie: fix patch summary]
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]

show more ...

video: fbdev: don't print error message on framebuffer_alloc() failure

framebuffer_alloc() can fail only on kzalloc() memory allocation
failure and since kzalloc() will print error message in such c

video: fbdev: don't print error message on framebuffer_alloc() failure

framebuffer_alloc() can fail only on kzalloc() memory allocation
failure and since kzalloc() will print error message in such case
we can omit printing extra error message in drivers (which BTW is
what the majority of framebuffer_alloc() users is doing already).

Cc: "Bruno Prémont" <[email protected]>
Cc: Jiri Kosina <[email protected]>
Cc: Benjamin Tissoires <[email protected]>
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>

show more ...

fbdev: sm712fb: fix memory frequency by avoiding a switch/case fallthrough

A fallthrough in switch/case was introduced in f627caf55b8e ("fbdev:
sm712fb: fix crashes and garbled display during DPMS m

fbdev: sm712fb: fix memory frequency by avoiding a switch/case fallthrough

A fallthrough in switch/case was introduced in f627caf55b8e ("fbdev:
sm712fb: fix crashes and garbled display during DPMS modesetting"),
due to my copy-paste error, which would cause the memory clock frequency
for SM720 to be programmed to SM712.

Since it only reprograms the clock to a different frequency, it's only
a benign issue without visible side-effect, so it also evaded Sudip
Mukherjee's code review and regression tests. scripts/checkpatch.pl
also failed to discover the issue, possibly due to nested switch
statements.

This issue was found by Stephen Rothwell by building linux-next with
-Wimplicit-fallthrough.

Reported-by: Stephen Rothwell <[email protected]>
Fixes: f627caf55b8e ("fbdev: sm712fb: fix crashes and garbled display during DPMS modesetting")
Signed-off-by: Yifeng Li <[email protected]>
Cc: Sudip Mukherjee <[email protected]>
Cc: "Gustavo A. R. Silva" <[email protected]>
Cc: Kees Cook <[email protected]>
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>

show more ...

fbdev: sm712fb: use 1024x768 by default on non-MIPS, fix garbled display

Loongson MIPS netbooks use 1024x600 LCD panels, which is the original
target platform of this driver, but nearly all old x86

fbdev: sm712fb: use 1024x768 by default on non-MIPS, fix garbled display

Loongson MIPS netbooks use 1024x600 LCD panels, which is the original
target platform of this driver, but nearly all old x86 laptops have
1024x768. Lighting 768 panels using 600's timings would partially
garble the display. Since it's not possible to distinguish them reliably,
we change the default to 768, but keep 600 as-is on MIPS.

Further, earlier laptops, such as IBM Thinkpad 240X, has a 800x600 LCD
panel, this driver would probably garbled those display. As we don't
have one for testing, the original behavior of the driver is kept as-is,
but the problem has been documented is the comments.

Signed-off-by: Yifeng Li <[email protected]>
Tested-by: Sudip Mukherjee <[email protected]>
Cc: Teddy Wang <[email protected]>
Cc: <[email protected]> # v4.4+
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>

show more ...

fbdev: sm712fb: fix support for 1024x768-16 mode

In order to support the 1024x600 panel on Yeeloong Loongson MIPS
laptop, the original 1024x768-16 table was modified to 1024x600-16,
without leaving

fbdev: sm712fb: fix support for 1024x768-16 mode

In order to support the 1024x600 panel on Yeeloong Loongson MIPS
laptop, the original 1024x768-16 table was modified to 1024x600-16,
without leaving the original. It causes problem on x86 laptop as
the 1024x768-16 support was still claimed but not working.

Fix it by introducing the 1024x768-16 mode.

Signed-off-by: Yifeng Li <[email protected]>
Tested-by: Sudip Mukherjee <[email protected]>
Cc: Teddy Wang <[email protected]>
Cc: <[email protected]> # v4.4+
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>

show more ...

fbdev: sm712fb: fix crashes and garbled display during DPMS modesetting

On a Thinkpad s30 (Pentium III / i440MX, Lynx3DM), blanking the display
or starting the X server will crash and freeze the sys

fbdev: sm712fb: fix crashes and garbled display during DPMS modesetting

On a Thinkpad s30 (Pentium III / i440MX, Lynx3DM), blanking the display
or starting the X server will crash and freeze the system, or garble the
display.

Experiments showed this problem can mostly be solved by adjusting the
order of register writes. Also, sm712fb failed to consider the difference
of clock frequency when unblanking the display, and programs the clock for
SM712 to SM720.

Fix them by adjusting the order of register writes, and adding an
additional check for SM720 for programming the clock frequency.

Signed-off-by: Yifeng Li <[email protected]>
Tested-by: Sudip Mukherjee <[email protected]>
Cc: Teddy Wang <[email protected]>
Cc: <[email protected]> # v4.4+
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>

show more ...

fbdev: sm712fb: fix crashes during framebuffer writes by correctly mapping VRAM

On a Thinkpad s30 (Pentium III / i440MX, Lynx3DM), running fbtest or X
will crash the machine instantly, because the V

fbdev: sm712fb: fix crashes during framebuffer writes by correctly mapping VRAM

On a Thinkpad s30 (Pentium III / i440MX, Lynx3DM), running fbtest or X
will crash the machine instantly, because the VRAM/framebuffer is not
mapped correctly.

On SM712, the framebuffer starts at the beginning of address space, but
SM720's framebuffer starts at the 1 MiB offset from the beginning. However,
sm712fb fails to take this into account, as a result, writing to the
framebuffer will destroy all the registers and kill the system immediately.
Another problem is the driver assumes 8 MiB of VRAM for SM720, but some
SM720 system, such as this IBM Thinkpad, only has 4 MiB of VRAM.

Fix this problem by removing the hardcoded VRAM size, adding a function to
query the amount of VRAM from register MCR76 on SM720, and adding proper
framebuffer offset.

Please note that the memory map may have additional problems on Big-Endian
system, which is not available for testing by myself. But I highly suspect
that the original code is also broken on Big-Endian machines for SM720, so
at least we are not making the problem worse. More, the driver also assumed
SM710/SM712 has 4 MiB of VRAM, but it has a 2 MiB version as well, and used
in earlier laptops, such as IBM Thinkpad 240X, the driver would probably
crash on them. I've never seen one of those machines and cannot fix it, but
I have documented these problems in the comments.

Signed-off-by: Yifeng Li <[email protected]>
Tested-by: Sudip Mukherjee <[email protected]>
Cc: Teddy Wang <[email protected]>
Cc: <[email protected]> # v4.4+
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>

show more ...

fbdev: sm712fb: fix boot screen glitch when sm712fb replaces VGA

When the machine is booted in VGA mode, loading sm712fb would cause
a glitch of random pixels shown on the screen. To prevent it from

fbdev: sm712fb: fix boot screen glitch when sm712fb replaces VGA

When the machine is booted in VGA mode, loading sm712fb would cause
a glitch of random pixels shown on the screen. To prevent it from
happening, we first clear the entire framebuffer, and we also need
to stop calling smtcfb_setmode() during initialization, the fbdev
layer will call it for us later when it's ready.

Signed-off-by: Yifeng Li <[email protected]>
Tested-by: Sudip Mukherjee <[email protected]>
Cc: Teddy Wang <[email protected]>
Cc: <[email protected]> # v4.4+
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>

show more ...

fbdev: sm712fb: fix VRAM detection, don't set SR70/71/74/75

On a Thinkpad s30 (Pentium III / i440MX, Lynx3DM), the amount of Video
RAM is not detected correctly by the xf86-video-siliconmotion drive

fbdev: sm712fb: fix VRAM detection, don't set SR70/71/74/75

On a Thinkpad s30 (Pentium III / i440MX, Lynx3DM), the amount of Video
RAM is not detected correctly by the xf86-video-siliconmotion driver.
This is because sm712fb overwrites the GPR71 Scratch Pad Register, which
is set by BIOS on x86 and used to indicate amount of VRAM.

Other Scratch Pad Registers, including GPR70/74/75, don't have the same
side-effect, but overwriting to them is still questionable, as they are
not related to modesetting.

Stop writing to SR70/71/74/75 (a.k.a GPR70/71/74/75).

Signed-off-by: Yifeng Li <[email protected]>
Tested-by: Sudip Mukherjee <[email protected]>
Cc: Teddy Wang <[email protected]>
Cc: <[email protected]> # v4.4+
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>

show more ...

fbdev: sm712fb: fix brightness control on reboot, don't set SR30

On a Thinkpad s30 (Pentium III / i440MX, Lynx3DM), rebooting with
sm712fb framebuffer driver would cause the role of brightness up/do

fbdev: sm712fb: fix brightness control on reboot, don't set SR30

On a Thinkpad s30 (Pentium III / i440MX, Lynx3DM), rebooting with
sm712fb framebuffer driver would cause the role of brightness up/down
button to swap.

Experiments showed the FPR30 register caused this behavior. Moreover,
even if this register don't have side-effect on other systems, over-
writing it is also highly questionable, since it was originally
configurated by the motherboard manufacturer by hardwiring pull-down
resistors to indicate the type of LCD panel. We should not mess with
it.

Stop writing to the SR30 (a.k.a FPR30) register.

Signed-off-by: Yifeng Li <[email protected]>
Tested-by: Sudip Mukherjee <[email protected]>
Cc: Teddy Wang <[email protected]>
Cc: <[email protected]> # v4.4+
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>

show more ...

fbdev: sm712fb: fix white screen of death on reboot, don't set CR3B-CR3F

On a Thinkpad s30 (Pentium III / i440MX, Lynx3DM), rebooting with
sm712fb framebuffer driver would cause a white screen of de

fbdev: sm712fb: fix white screen of death on reboot, don't set CR3B-CR3F

On a Thinkpad s30 (Pentium III / i440MX, Lynx3DM), rebooting with
sm712fb framebuffer driver would cause a white screen of death on
the next POST, presumably the proper timings for the LCD panel was
not reprogrammed properly by the BIOS.

Experiments showed a few CRTC Scratch Registers, including CRT3D,
CRT3E and CRT3F may be used internally by BIOS as some flags. CRT3B is
a hardware testing register, we shouldn't mess with it. CRT3C has
blanking signal and line compare control, which is not needed for this
driver.

Stop writing to CR3B-CR3F (a.k.a CRT3B-CRT3F) registers. Even if these
registers don't have side-effect on other systems, writing to them is
also highly questionable.

Signed-off-by: Yifeng Li <[email protected]>
Tested-by: Sudip Mukherjee <[email protected]>
Cc: Teddy Wang <[email protected]>
Cc: <[email protected]> # v4.4+
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>

show more ...