Hi all.
As you may have noticed, recently I've been working on a reworked version
of sm712fb, and planned to convert it to a DRM/KMS driver. Besides using
it on embedded/non-x86 systems, I thought it would be a good idea to support
histrocial x86 laptops with this VGA chipset as well, so I've acquired a
machine for testing.
However, soon I found a nasty problem. The BIOS does not reset the chip
on boot! Like most graphics controller of that era, sm712 chipset has a
VGA compatible mode and a 2D framebuffer mode. The power-on default is
VGA. The BIOS writer just assumed this, and does nothing to reinitialize
it. If one uses the framebuffer driver under Linux, once the machine reboots,
the entire LCD panel becomes a piece of garbage.
AFAIK, the framebuffer driver would be running throughout the kernel's life-
cycle, is it really possible to workaround this issue by restoring on VGA
state upon reboot?
Thanks,
Tom Li
On Thu, 07 Mar 2019, Tom Li <[email protected]> wrote:
> Hi all.
>
> As you may have noticed, recently I've been working on a reworked version
> of sm712fb, and planned to convert it to a DRM/KMS driver. Besides using
> it on embedded/non-x86 systems, I thought it would be a good idea to support
> histrocial x86 laptops with this VGA chipset as well, so I've acquired a
> machine for testing.
>
> However, soon I found a nasty problem. The BIOS does not reset the chip
> on boot! Like most graphics controller of that era, sm712 chipset has a
> VGA compatible mode and a 2D framebuffer mode. The power-on default is
> VGA. The BIOS writer just assumed this, and does nothing to reinitialize
> it. If one uses the framebuffer driver under Linux, once the machine reboots,
> the entire LCD panel becomes a piece of garbage.
>
> AFAIK, the framebuffer driver would be running throughout the kernel's life-
> cycle, is it really possible to workaround this issue by restoring on VGA
> state upon reboot?
It's possible to do this using a reboot notifier. I am not sure if there
are better ways to achieve the same, but there's at least one example of
using reboot notifiers to achieve the exact same goal.
See drivers/video/fbdev/aty/atyfb_base.c, look for
register_reboot_notifier().
HTH,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
Hi Jani,
On Thu, Mar 7, 2019 at 10:00 AM Jani Nikula <[email protected]> wrote:
> On Thu, 07 Mar 2019, Tom Li <[email protected]> wrote:
> > As you may have noticed, recently I've been working on a reworked version
> > of sm712fb, and planned to convert it to a DRM/KMS driver. Besides using
> > it on embedded/non-x86 systems, I thought it would be a good idea to support
> > histrocial x86 laptops with this VGA chipset as well, so I've acquired a
> > machine for testing.
> >
> > However, soon I found a nasty problem. The BIOS does not reset the chip
> > on boot! Like most graphics controller of that era, sm712 chipset has a
> > VGA compatible mode and a 2D framebuffer mode. The power-on default is
> > VGA. The BIOS writer just assumed this, and does nothing to reinitialize
> > it. If one uses the framebuffer driver under Linux, once the machine reboots,
> > the entire LCD panel becomes a piece of garbage.
> >
> > AFAIK, the framebuffer driver would be running throughout the kernel's life-
> > cycle, is it really possible to workaround this issue by restoring on VGA
> > state upon reboot?
>
> It's possible to do this using a reboot notifier. I am not sure if there
> are better ways to achieve the same, but there's at least one example of
> using reboot notifiers to achieve the exact same goal.
>
> See drivers/video/fbdev/aty/atyfb_base.c, look for
> register_reboot_notifier().
Or a shutdown handler, which is more device-centric?
(cfr. "[3/4] fbdev: atafb: Fix broken frame buffer after kexec",
https://patchwork.kernel.org/patch/10814381/).
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
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
On Thu, Mar 07, 2019 at 10:39:23AM +0100, Geert Uytterhoeven wrote:
> On Thu, Mar 7, 2019 at 10:00 AM Jani Nikula <[email protected]> wrote:
> > It's possible to do this using a reboot notifier. I am not sure if there
> > are better ways to achieve the same, but there's at least one example of
> > using reboot notifiers to achieve the exact same goal.
> >
> > See drivers/video/fbdev/aty/atyfb_base.c, look for
> > register_reboot_notifier().
>
> Or a shutdown handler, which is more device-centric?
> (cfr. "[3/4] fbdev: atafb: Fix broken frame buffer after kexec",
> https://patchwork.kernel.org/patch/10814381/).
>
> Gr{oetje,eeting}s,
Thanks, I knew reboot_notifier but I thought it feels "hacky" to use it in a
device driver, shutdown() handler looks better.
Nevertheless, does it mean there's no way to prevent it from happening if the
user issues a emergency reboot? Like an automatic reboot after a kernel panic,
or a SysRq-B reboot.
Tom Li
Hi Tom,
On Thu, Mar 7, 2019 at 10:38 PM Tom Li <[email protected]> wrote:
> On Thu, Mar 07, 2019 at 10:39:23AM +0100, Geert Uytterhoeven wrote:
> > On Thu, Mar 7, 2019 at 10:00 AM Jani Nikula <[email protected]> wrote:
> > > It's possible to do this using a reboot notifier. I am not sure if there
> > > are better ways to achieve the same, but there's at least one example of
> > > using reboot notifiers to achieve the exact same goal.
> > >
> > > See drivers/video/fbdev/aty/atyfb_base.c, look for
> > > register_reboot_notifier().
> >
> > Or a shutdown handler, which is more device-centric?
> > (cfr. "[3/4] fbdev: atafb: Fix broken frame buffer after kexec",
> > https://patchwork.kernel.org/patch/10814381/).
> >
> > Gr{oetje,eeting}s,
>
> Thanks, I knew reboot_notifier but I thought it feels "hacky" to use it in a
> device driver, shutdown() handler looks better.
>
> Nevertheless, does it mean there's no way to prevent it from happening if the
> user issues a emergency reboot? Like an automatic reboot after a kernel panic,
> or a SysRq-B reboot.
If Linux performs a reboot, it calls the shutdown handlers.
I think that includes reboot on panic, or SysRq-B, but I'd have to check to
be 100% sure.
If the kernel just crashes, of course all of that doesn't happen.
Is your graphics card reset when the reset button is pressed, or only on
cold power on?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
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
On Fri, Mar 08, 2019 at 10:13:58AM +0100, Geert Uytterhoeven wrote:
> Hi Tom,
>
> If the kernel just crashes, of course all of that doesn't happen.
> Is your graphics card reset when the reset button is pressed, or only on
> cold power on?
It's a laptop, so it doesn't have a reset button. I've tried reboot=cold/warn
but apparently it doesn't make any difference. So I think only a cold boot can
reset the graphics card.
> On Thu, Mar 7, 2019 at 10:38 PM Tom Li <[email protected]> wrote:
> > Nevertheless, does it mean there's no way to prevent it from happening if the
> > user issues a emergency reboot? Like an automatic reboot after a kernel panic,
> > or a SysRq-B reboot.
>
> If Linux performs a reboot, it calls the shutdown handlers.
> I think that includes reboot on panic, or SysRq-B, but I'd have to check to
> be 100% sure.
Okay, glad to hear that. If it works for SysRq-B or panic reboot, I think
it would be enough. After all, hard kernel crashes are rare nowadays, and
most crashes are hard lockups. In case it happens, the user just presses
the power button to halt.
NMI watchdog reset is still an issue though, but I don't think people who
are playing with those ~1999-2002 hardware (like this one) is actually using
it. Anyway, In this case, I think putting a special note in the documentation,
and raising a warning in dmesg (WARNING: LCD output may be corrupted on reset,
read ./Documentation/fb/sm712fb.txt!) would be adequate.
Thanks,
Tom Li
On Fri, Mar 08, 2019 at 06:35:36PM +0800, Tom Li wrote:
> On Fri, Mar 08, 2019 at 10:13:58AM +0100, Geert Uytterhoeven wrote:
> > On Thu, Mar 7, 2019 at 10:38 PM Tom Li <[email protected]> wrote:
> > > Nevertheless, does it mean there's no way to prevent it from happening if the
> > > user issues a emergency reboot? Like an automatic reboot after a kernel panic,
> > > or a SysRq-B reboot.
> >
> > If Linux performs a reboot, it calls the shutdown handlers.
> > I think that includes reboot on panic, or SysRq-B, but I'd have to check to
> > be 100% sure.
>
> Okay, glad to hear that. If it works for SysRq-B or panic reboot, I think
> it would be enough. After all, hard kernel crashes are rare nowadays, and
> most crashes are hard lockups. In case it happens, the user just presses
> the power button to halt.
As I suspected, emergency reboot via SysRq-B is a hard reboot and none of the
reboot handler will be called. I've put a for (;;) {} loop in .shutdown(), the
kernel would hang during a normal reboot, but a SysRq-B reboot will reset the
machine immediately.
Fortunately, I've found a way to stop trigger the bug in the driver, so no
shutdown handler is needed anymore.
Cheers,
Tom Li