* [PATCH 00/21] some fbcon patches, mostly locking
@ 2022-01-31 21:05 ` Daniel Vetter
0 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-01-31 21:05 UTC (permalink / raw)
To: DRI Development
Cc: Intel Graphics Development, linux-fbdev, LKML, Daniel Vetter
Hi all,
This took way longer than I hoped, but well I got lost in head-scratching
locking problems. Anyway ended up typing a pile of fbcon patches. Rough
overview:
- MAINTAINER entry for fbdev core in drm-misc, with the usual group
maintainering
- The reverts, but with a compile time option. I looked into combining
this with the RFC from Helge, but it looked like worse than either
approach, so I've kept mine. I think merging either is fine, no personal
stake here on the bikeshed color.
- The real distraction, aka a bunch of cleanups and mostly locking work
for fbcon. I managed to ditch at least one locking FIXME from fbcon.c.
The bad news that I spent a bunch more time pondering about the bigger
locking issues in fbcon.c, and I think as-is they're unfixable. We need
the threaded printk support to land first, so that we're not adding
lock_fb_info() to all printk() contexts. Because that just cannot work.
That also means we'll likely have another fbcon regression to face, in the
form of worse oops printing ability. And that one I don't think we can fix
with clever application of #ifdef, because changing locking rules at
compile time in fundamental ways is just not a very good idea.
Anyway, testing, review, feedback and all that very much welcome, as
usual.
Cheers, Daniel
Daniel Vetter (21):
MAINTAINERS: Add entry for fbdev core
fbcon: Resurrect fbcon accelerated scrolling code
fbcon: Restore fbcon scrolling acceleration
fbcon: delete a few unneeded forward decl
fbcon: Introduce wrapper for console->fb_info lookup
fbcon: delete delayed loading code
fbdev/sysfs: Fix locking
fbcon: Use delayed work for cursor
fbcon: Replace FBCON_FLAGS_INIT with a boolean
fb: Delete fb_info->queue
fbcon: Extract fbcon_open/release helpers
fbcon: Ditch error handling for con2fb_release_oldinfo
fbcon: move more common code into fb_open()
fbcon: use lock_fb_info in fbcon_open/release
fbcon: Consistently protect deferred_takeover with console_lock()
fbcon: Move console_lock for register/unlink/unregister
fbcon: Move more code into fbcon_release
fbcon: untangle fbcon_exit
fbcon: Maintain a private array of fb_info
Revert "fbdev: Prevent probing generic drivers if a FB is already
registered"
fbdev: Make registered_fb[] private to fbmem.c
Documentation/gpu/todo.rst | 13 +-
MAINTAINERS | 6 +
drivers/video/console/Kconfig | 11 +
drivers/video/fbdev/core/bitblit.c | 16 +
drivers/video/fbdev/core/fbcon.c | 1072 +++++++++++++++++------
drivers/video/fbdev/core/fbcon.h | 67 +-
drivers/video/fbdev/core/fbcon_ccw.c | 28 +-
drivers/video/fbdev/core/fbcon_cw.c | 28 +-
drivers/video/fbdev/core/fbcon_rotate.h | 21 +
drivers/video/fbdev/core/fbcon_ud.c | 37 +-
drivers/video/fbdev/core/fbmem.c | 35 +-
drivers/video/fbdev/core/fbsysfs.c | 2 +
drivers/video/fbdev/core/tileblit.c | 16 +
drivers/video/fbdev/efifb.c | 11 -
drivers/video/fbdev/simplefb.c | 11 -
drivers/video/fbdev/skeletonfb.c | 12 +-
include/linux/fb.h | 10 +-
17 files changed, 1017 insertions(+), 379 deletions(-)
--
2.33.0
^ permalink raw reply [flat|nested] 241+ messages in thread
* [PATCH 00/21] some fbcon patches, mostly locking
@ 2022-01-31 21:05 ` Daniel Vetter
0 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-01-31 21:05 UTC (permalink / raw)
To: DRI Development
Cc: Daniel Vetter, Intel Graphics Development, linux-fbdev, LKML
Hi all,
This took way longer than I hoped, but well I got lost in head-scratching
locking problems. Anyway ended up typing a pile of fbcon patches. Rough
overview:
- MAINTAINER entry for fbdev core in drm-misc, with the usual group
maintainering
- The reverts, but with a compile time option. I looked into combining
this with the RFC from Helge, but it looked like worse than either
approach, so I've kept mine. I think merging either is fine, no personal
stake here on the bikeshed color.
- The real distraction, aka a bunch of cleanups and mostly locking work
for fbcon. I managed to ditch at least one locking FIXME from fbcon.c.
The bad news that I spent a bunch more time pondering about the bigger
locking issues in fbcon.c, and I think as-is they're unfixable. We need
the threaded printk support to land first, so that we're not adding
lock_fb_info() to all printk() contexts. Because that just cannot work.
That also means we'll likely have another fbcon regression to face, in the
form of worse oops printing ability. And that one I don't think we can fix
with clever application of #ifdef, because changing locking rules at
compile time in fundamental ways is just not a very good idea.
Anyway, testing, review, feedback and all that very much welcome, as
usual.
Cheers, Daniel
Daniel Vetter (21):
MAINTAINERS: Add entry for fbdev core
fbcon: Resurrect fbcon accelerated scrolling code
fbcon: Restore fbcon scrolling acceleration
fbcon: delete a few unneeded forward decl
fbcon: Introduce wrapper for console->fb_info lookup
fbcon: delete delayed loading code
fbdev/sysfs: Fix locking
fbcon: Use delayed work for cursor
fbcon: Replace FBCON_FLAGS_INIT with a boolean
fb: Delete fb_info->queue
fbcon: Extract fbcon_open/release helpers
fbcon: Ditch error handling for con2fb_release_oldinfo
fbcon: move more common code into fb_open()
fbcon: use lock_fb_info in fbcon_open/release
fbcon: Consistently protect deferred_takeover with console_lock()
fbcon: Move console_lock for register/unlink/unregister
fbcon: Move more code into fbcon_release
fbcon: untangle fbcon_exit
fbcon: Maintain a private array of fb_info
Revert "fbdev: Prevent probing generic drivers if a FB is already
registered"
fbdev: Make registered_fb[] private to fbmem.c
Documentation/gpu/todo.rst | 13 +-
MAINTAINERS | 6 +
drivers/video/console/Kconfig | 11 +
drivers/video/fbdev/core/bitblit.c | 16 +
drivers/video/fbdev/core/fbcon.c | 1072 +++++++++++++++++------
drivers/video/fbdev/core/fbcon.h | 67 +-
drivers/video/fbdev/core/fbcon_ccw.c | 28 +-
drivers/video/fbdev/core/fbcon_cw.c | 28 +-
drivers/video/fbdev/core/fbcon_rotate.h | 21 +
drivers/video/fbdev/core/fbcon_ud.c | 37 +-
drivers/video/fbdev/core/fbmem.c | 35 +-
drivers/video/fbdev/core/fbsysfs.c | 2 +
drivers/video/fbdev/core/tileblit.c | 16 +
drivers/video/fbdev/efifb.c | 11 -
drivers/video/fbdev/simplefb.c | 11 -
drivers/video/fbdev/skeletonfb.c | 12 +-
include/linux/fb.h | 10 +-
17 files changed, 1017 insertions(+), 379 deletions(-)
--
2.33.0
^ permalink raw reply [flat|nested] 241+ messages in thread
* [Intel-gfx] [PATCH 00/21] some fbcon patches, mostly locking
@ 2022-01-31 21:05 ` Daniel Vetter
0 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-01-31 21:05 UTC (permalink / raw)
To: DRI Development
Cc: Daniel Vetter, Intel Graphics Development, linux-fbdev, LKML
Hi all,
This took way longer than I hoped, but well I got lost in head-scratching
locking problems. Anyway ended up typing a pile of fbcon patches. Rough
overview:
- MAINTAINER entry for fbdev core in drm-misc, with the usual group
maintainering
- The reverts, but with a compile time option. I looked into combining
this with the RFC from Helge, but it looked like worse than either
approach, so I've kept mine. I think merging either is fine, no personal
stake here on the bikeshed color.
- The real distraction, aka a bunch of cleanups and mostly locking work
for fbcon. I managed to ditch at least one locking FIXME from fbcon.c.
The bad news that I spent a bunch more time pondering about the bigger
locking issues in fbcon.c, and I think as-is they're unfixable. We need
the threaded printk support to land first, so that we're not adding
lock_fb_info() to all printk() contexts. Because that just cannot work.
That also means we'll likely have another fbcon regression to face, in the
form of worse oops printing ability. And that one I don't think we can fix
with clever application of #ifdef, because changing locking rules at
compile time in fundamental ways is just not a very good idea.
Anyway, testing, review, feedback and all that very much welcome, as
usual.
Cheers, Daniel
Daniel Vetter (21):
MAINTAINERS: Add entry for fbdev core
fbcon: Resurrect fbcon accelerated scrolling code
fbcon: Restore fbcon scrolling acceleration
fbcon: delete a few unneeded forward decl
fbcon: Introduce wrapper for console->fb_info lookup
fbcon: delete delayed loading code
fbdev/sysfs: Fix locking
fbcon: Use delayed work for cursor
fbcon: Replace FBCON_FLAGS_INIT with a boolean
fb: Delete fb_info->queue
fbcon: Extract fbcon_open/release helpers
fbcon: Ditch error handling for con2fb_release_oldinfo
fbcon: move more common code into fb_open()
fbcon: use lock_fb_info in fbcon_open/release
fbcon: Consistently protect deferred_takeover with console_lock()
fbcon: Move console_lock for register/unlink/unregister
fbcon: Move more code into fbcon_release
fbcon: untangle fbcon_exit
fbcon: Maintain a private array of fb_info
Revert "fbdev: Prevent probing generic drivers if a FB is already
registered"
fbdev: Make registered_fb[] private to fbmem.c
Documentation/gpu/todo.rst | 13 +-
MAINTAINERS | 6 +
drivers/video/console/Kconfig | 11 +
drivers/video/fbdev/core/bitblit.c | 16 +
drivers/video/fbdev/core/fbcon.c | 1072 +++++++++++++++++------
drivers/video/fbdev/core/fbcon.h | 67 +-
drivers/video/fbdev/core/fbcon_ccw.c | 28 +-
drivers/video/fbdev/core/fbcon_cw.c | 28 +-
drivers/video/fbdev/core/fbcon_rotate.h | 21 +
drivers/video/fbdev/core/fbcon_ud.c | 37 +-
drivers/video/fbdev/core/fbmem.c | 35 +-
drivers/video/fbdev/core/fbsysfs.c | 2 +
drivers/video/fbdev/core/tileblit.c | 16 +
drivers/video/fbdev/efifb.c | 11 -
drivers/video/fbdev/simplefb.c | 11 -
drivers/video/fbdev/skeletonfb.c | 12 +-
include/linux/fb.h | 10 +-
17 files changed, 1017 insertions(+), 379 deletions(-)
--
2.33.0
^ permalink raw reply [flat|nested] 241+ messages in thread
* [PATCH 01/21] MAINTAINERS: Add entry for fbdev core
2022-01-31 21:05 ` Daniel Vetter
(?)
@ 2022-01-31 21:05 ` Daniel Vetter
-1 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-01-31 21:05 UTC (permalink / raw)
To: DRI Development
Cc: Intel Graphics Development, linux-fbdev, LKML, Daniel Vetter,
Dave Airlie, Jani Nikula, Linus Torvalds, Pavel Machek,
Sam Ravnborg, Greg Kroah-Hartman, Javier Martinez Canillas,
Claudio Suarez, Tomi Valkeinen, Geert Uytterhoeven,
Thomas Zimmermann, Daniel Vetter, Sven Schnelle, Gerd Hoffmann
Ever since Tomi extracted the core code in 2014 it's been defacto me
maintaining this, with help from others from dri-devel and sometimes
Linus (but those are mostly merge conflicts):
$ git shortlog -ns drivers/video/fbdev/core/ | head -n5
35 Daniel Vetter
23 Linus Torvalds
10 Hans de Goede
9 Dave Airlie
6 Peter Rosin
I think ideally we'd also record that the various firmware fb drivers
(efifb, vesafb, ...) are also maintained in drm-misc because for the
past few years the patches have either been to fix handover issues
with drm drivers, or caused handover issues with drm drivers. So any
other tree just doesn't make sense. But also, there's plenty of
outdated MAINTAINER entries for these with people and git trees that
haven't been active in years, so maybe let's just leave them alone.
And furthermore distros are now adopting simpledrm as the firmware fb
driver, so hopefully the need to care about the fbdev firmware drivers
will go down going forward.
Note that drm-misc is group maintained, I expect that to continue like
we've done before, so no new expectations that patches all go through
my hands. That would be silly. This also means I'm happy to put any
other volunteer's name in the M: line, but otherwise git log says I'm
the one who's stuck with this.
Cc: Dave Airlie <airlied@gmail.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Linux Fbdev development list <linux-fbdev@vger.kernel.org>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Javier Martinez Canillas <javierm@redhat.com>
Cc: DRI Development <dri-devel@lists.freedesktop.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Cc: Claudio Suarez <cssk@net-c.es>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Sven Schnelle <svens@stackframe.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
MAINTAINERS | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index ea3e6c914384..49809eaa3096 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7573,6 +7573,12 @@ S: Maintained
W: http://floatingpoint.sourceforge.net/emulator/index.html
F: arch/x86/math-emu/
+FRAMEBUFFER CORE
+M: Daniel Vetter <daniel@ffwll.ch>
+F: drivers/video/fbdev/core/
+S: Odd Fixes
+T: git git://anongit.freedesktop.org/drm/drm-misc
+
FRAMEBUFFER LAYER
M: Helge Deller <deller@gmx.de>
L: linux-fbdev@vger.kernel.org
--
2.33.0
^ permalink raw reply related [flat|nested] 241+ messages in thread
* [PATCH 01/21] MAINTAINERS: Add entry for fbdev core
@ 2022-01-31 21:05 ` Daniel Vetter
0 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-01-31 21:05 UTC (permalink / raw)
To: DRI Development
Cc: linux-fbdev, Thomas Zimmermann, Sam Ravnborg, Daniel Vetter,
Daniel Vetter, Intel Graphics Development, LKML,
Javier Martinez Canillas, Linus Torvalds, Tomi Valkeinen,
Claudio Suarez, Gerd Hoffmann, Pavel Machek, Greg Kroah-Hartman,
Geert Uytterhoeven, Sven Schnelle
Ever since Tomi extracted the core code in 2014 it's been defacto me
maintaining this, with help from others from dri-devel and sometimes
Linus (but those are mostly merge conflicts):
$ git shortlog -ns drivers/video/fbdev/core/ | head -n5
35 Daniel Vetter
23 Linus Torvalds
10 Hans de Goede
9 Dave Airlie
6 Peter Rosin
I think ideally we'd also record that the various firmware fb drivers
(efifb, vesafb, ...) are also maintained in drm-misc because for the
past few years the patches have either been to fix handover issues
with drm drivers, or caused handover issues with drm drivers. So any
other tree just doesn't make sense. But also, there's plenty of
outdated MAINTAINER entries for these with people and git trees that
haven't been active in years, so maybe let's just leave them alone.
And furthermore distros are now adopting simpledrm as the firmware fb
driver, so hopefully the need to care about the fbdev firmware drivers
will go down going forward.
Note that drm-misc is group maintained, I expect that to continue like
we've done before, so no new expectations that patches all go through
my hands. That would be silly. This also means I'm happy to put any
other volunteer's name in the M: line, but otherwise git log says I'm
the one who's stuck with this.
Cc: Dave Airlie <airlied@gmail.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Linux Fbdev development list <linux-fbdev@vger.kernel.org>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Javier Martinez Canillas <javierm@redhat.com>
Cc: DRI Development <dri-devel@lists.freedesktop.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Cc: Claudio Suarez <cssk@net-c.es>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Sven Schnelle <svens@stackframe.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
MAINTAINERS | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index ea3e6c914384..49809eaa3096 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7573,6 +7573,12 @@ S: Maintained
W: http://floatingpoint.sourceforge.net/emulator/index.html
F: arch/x86/math-emu/
+FRAMEBUFFER CORE
+M: Daniel Vetter <daniel@ffwll.ch>
+F: drivers/video/fbdev/core/
+S: Odd Fixes
+T: git git://anongit.freedesktop.org/drm/drm-misc
+
FRAMEBUFFER LAYER
M: Helge Deller <deller@gmx.de>
L: linux-fbdev@vger.kernel.org
--
2.33.0
^ permalink raw reply related [flat|nested] 241+ messages in thread
* [Intel-gfx] [PATCH 01/21] MAINTAINERS: Add entry for fbdev core
@ 2022-01-31 21:05 ` Daniel Vetter
0 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-01-31 21:05 UTC (permalink / raw)
To: DRI Development
Cc: linux-fbdev, Thomas Zimmermann, Sam Ravnborg, Daniel Vetter,
Daniel Vetter, Intel Graphics Development, LKML,
Javier Martinez Canillas, Linus Torvalds, Tomi Valkeinen,
Gerd Hoffmann, Pavel Machek, Greg Kroah-Hartman,
Geert Uytterhoeven, Dave Airlie, Sven Schnelle
Ever since Tomi extracted the core code in 2014 it's been defacto me
maintaining this, with help from others from dri-devel and sometimes
Linus (but those are mostly merge conflicts):
$ git shortlog -ns drivers/video/fbdev/core/ | head -n5
35 Daniel Vetter
23 Linus Torvalds
10 Hans de Goede
9 Dave Airlie
6 Peter Rosin
I think ideally we'd also record that the various firmware fb drivers
(efifb, vesafb, ...) are also maintained in drm-misc because for the
past few years the patches have either been to fix handover issues
with drm drivers, or caused handover issues with drm drivers. So any
other tree just doesn't make sense. But also, there's plenty of
outdated MAINTAINER entries for these with people and git trees that
haven't been active in years, so maybe let's just leave them alone.
And furthermore distros are now adopting simpledrm as the firmware fb
driver, so hopefully the need to care about the fbdev firmware drivers
will go down going forward.
Note that drm-misc is group maintained, I expect that to continue like
we've done before, so no new expectations that patches all go through
my hands. That would be silly. This also means I'm happy to put any
other volunteer's name in the M: line, but otherwise git log says I'm
the one who's stuck with this.
Cc: Dave Airlie <airlied@gmail.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Linux Fbdev development list <linux-fbdev@vger.kernel.org>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Javier Martinez Canillas <javierm@redhat.com>
Cc: DRI Development <dri-devel@lists.freedesktop.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Cc: Claudio Suarez <cssk@net-c.es>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Sven Schnelle <svens@stackframe.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
MAINTAINERS | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index ea3e6c914384..49809eaa3096 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7573,6 +7573,12 @@ S: Maintained
W: http://floatingpoint.sourceforge.net/emulator/index.html
F: arch/x86/math-emu/
+FRAMEBUFFER CORE
+M: Daniel Vetter <daniel@ffwll.ch>
+F: drivers/video/fbdev/core/
+S: Odd Fixes
+T: git git://anongit.freedesktop.org/drm/drm-misc
+
FRAMEBUFFER LAYER
M: Helge Deller <deller@gmx.de>
L: linux-fbdev@vger.kernel.org
--
2.33.0
^ permalink raw reply related [flat|nested] 241+ messages in thread
* [PATCH 02/21] fbcon: Resurrect fbcon accelerated scrolling code
2022-01-31 21:05 ` Daniel Vetter
(?)
@ 2022-01-31 21:05 ` Daniel Vetter
-1 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-01-31 21:05 UTC (permalink / raw)
To: DRI Development
Cc: Intel Graphics Development, linux-fbdev, LKML, Daniel Vetter,
Claudio Suarez, stable, Dave Airlie, Jani Nikula, Linus Torvalds,
Pavel Machek, Sam Ravnborg, Greg Kroah-Hartman,
Javier Martinez Canillas, Tomi Valkeinen, Geert Uytterhoeven,
Thomas Zimmermann, Daniel Vetter, Sven Schnelle, Gerd Hoffmann
This reverts commit b3ec8cdf457e ("fbdev: Garbage collect fbdev
scrolling acceleration, part 1 (from TODO list)"), but with a twist:
Because distros like fedora&suse (probably more) really want to move
away from fbcon as much as possible, and don't have a need for fancy
accelerated fbcon even less, hide the code behind an option.
There's also been noises about resurrecting the scrollback code and
other pieces, so there's plenty of need for such an option it seems.
Compared to direct revert I did move functions around a bit so they're
all in one block, to minimize the number of #ifdef.
I also tried to stuff this all into a separate file, but that didn't
really look much better. I also considered duplicating fbcon_scroll()
since that's a bit meh now, but again didn't seem worth the trouble.
Maybe when we resurect more code.
And finally to shut up unused parameter warnings warnings the macros
became static inline.
References: https://lore.kernel.org/dri-devel/feea8303-2b83-fc36-972c-4fc8ad723bde@gmx.de/
Fixes: b3ec8cdf457e ("fbdev: Garbage collect fbdev scrolling acceleration, part 1 (from TODO list)")
Cc: Claudio Suarez <cssk@net-c.es>
Cc: <stable@vger.kernel.org> # v5.16+
Cc: Dave Airlie <airlied@gmail.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Linux Fbdev development list <linux-fbdev@vger.kernel.org>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Javier Martinez Canillas <javierm@redhat.com>
Cc: DRI Development <dri-devel@lists.freedesktop.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Cc: Claudio Suarez <cssk@net-c.es>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Sven Schnelle <svens@stackframe.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
Documentation/gpu/todo.rst | 13 +-
drivers/video/console/Kconfig | 11 +
drivers/video/fbdev/core/bitblit.c | 16 +
drivers/video/fbdev/core/fbcon.c | 491 +++++++++++++++++++++++-
drivers/video/fbdev/core/fbcon.h | 59 +++
drivers/video/fbdev/core/fbcon_ccw.c | 28 +-
drivers/video/fbdev/core/fbcon_cw.c | 28 +-
drivers/video/fbdev/core/fbcon_rotate.h | 21 +
drivers/video/fbdev/core/fbcon_ud.c | 37 +-
drivers/video/fbdev/core/tileblit.c | 16 +
drivers/video/fbdev/skeletonfb.c | 12 +-
include/linux/fb.h | 2 +-
12 files changed, 701 insertions(+), 33 deletions(-)
diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index da138dd39883..29506815d24a 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -303,19 +303,16 @@ Level: Advanced
Garbage collect fbdev scrolling acceleration
--------------------------------------------
-Scroll acceleration has been disabled in fbcon. Now it works as the old
-SCROLL_REDRAW mode. A ton of code was removed in fbcon.c and the hook bmove was
-removed from fbcon_ops.
-Remaining tasks:
+Scroll acceleration is disabled in fbcon by hard-wiring p->scrollmode =
+SCROLL_REDRAW. There's a ton of code this will allow us to remove:
-- a bunch of the hooks in fbcon_ops could be removed or simplified by calling
+- lots of code in fbcon.c
+
+- a bunch of the hooks in fbcon_ops, maybe the remaining hooks could be called
directly instead of the function table (with a switch on p->rotate)
- fb_copyarea is unused after this, and can be deleted from all drivers
-- after that, fb_copyarea can be deleted from fb_ops in include/linux/fb.h as
- well as cfb_copyarea
-
Note that not all acceleration code can be deleted, since clearing and cursor
support is still accelerated, which might be good candidates for further
deletion projects.
diff --git a/drivers/video/console/Kconfig b/drivers/video/console/Kconfig
index 840d9813b0bc..f83f5c755084 100644
--- a/drivers/video/console/Kconfig
+++ b/drivers/video/console/Kconfig
@@ -78,6 +78,17 @@ config FRAMEBUFFER_CONSOLE
help
Low-level framebuffer-based console driver.
+config FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
+ bool "Enable legacy fbcon code for hw acceleration"
+ depends on FRAMEBUFFER_CONSOLE
+ default n
+ help
+ Only enable this options if you are in full control of machine since
+ the fbcon acceleration code is essentially unmaintained and known
+ problematic.
+
+ If unsure, select n.
+
config FRAMEBUFFER_CONSOLE_DETECT_PRIMARY
bool "Map the console to the primary display device"
depends on FRAMEBUFFER_CONSOLE
diff --git a/drivers/video/fbdev/core/bitblit.c b/drivers/video/fbdev/core/bitblit.c
index 01fae2c96965..f98e8f298bc1 100644
--- a/drivers/video/fbdev/core/bitblit.c
+++ b/drivers/video/fbdev/core/bitblit.c
@@ -43,6 +43,21 @@ static void update_attr(u8 *dst, u8 *src, int attribute,
}
}
+static void bit_bmove(struct vc_data *vc, struct fb_info *info, int sy,
+ int sx, int dy, int dx, int height, int width)
+{
+ struct fb_copyarea area;
+
+ area.sx = sx * vc->vc_font.width;
+ area.sy = sy * vc->vc_font.height;
+ area.dx = dx * vc->vc_font.width;
+ area.dy = dy * vc->vc_font.height;
+ area.height = height * vc->vc_font.height;
+ area.width = width * vc->vc_font.width;
+
+ info->fbops->fb_copyarea(info, &area);
+}
+
static void bit_clear(struct vc_data *vc, struct fb_info *info, int sy,
int sx, int height, int width)
{
@@ -378,6 +393,7 @@ static int bit_update_start(struct fb_info *info)
void fbcon_set_bitops(struct fbcon_ops *ops)
{
+ ops->bmove = bit_bmove;
ops->clear = bit_clear;
ops->putcs = bit_putcs;
ops->clear_margins = bit_clear_margins;
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 99ecd9a6d844..2ff90061c7f3 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -1125,6 +1125,14 @@ static void fbcon_init(struct vc_data *vc, int init)
ops->graphics = 0;
+ /*
+ * No more hw acceleration for fbcon.
+ *
+ * FIXME: Garbage collect all the now dead code after sufficient time
+ * has passed.
+ */
+ p->scrollmode = SCROLL_REDRAW;
+
/*
* ++guenther: console.c:vc_allocate() relies on initializing
* vc_{cols,rows}, but we must not set those if we are only
@@ -1211,13 +1219,14 @@ static void fbcon_deinit(struct vc_data *vc)
* This system is now divided into two levels because of complications
* caused by hardware scrolling. Top level functions:
*
- * fbcon_clear(), fbcon_putc(), fbcon_clear_margins()
+ * fbcon_bmove(), fbcon_clear(), fbcon_putc(), fbcon_clear_margins()
*
* handles y values in range [0, scr_height-1] that correspond to real
* screen positions. y_wrap shift means that first line of bitmap may be
* anywhere on this display. These functions convert lineoffsets to
* bitmap offsets and deal with the wrap-around case by splitting blits.
*
+ * fbcon_bmove_physical_8() -- These functions fast implementations
* fbcon_clear_physical_8() -- of original fbcon_XXX fns.
* fbcon_putc_physical_8() -- (font width != 8) may be added later
*
@@ -1390,6 +1399,291 @@ static void fbcon_set_disp(struct fb_info *info, struct fb_var_screeninfo *var,
}
}
+#ifdef CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
+static void fbcon_redraw_move(struct vc_data *vc, struct fbcon_display *p,
+ int line, int count, int dy)
+{
+ unsigned short *s = (unsigned short *)
+ (vc->vc_origin + vc->vc_size_row * line);
+
+ while (count--) {
+ unsigned short *start = s;
+ unsigned short *le = advance_row(s, 1);
+ unsigned short c;
+ int x = 0;
+ unsigned short attr = 1;
+
+ do {
+ c = scr_readw(s);
+ if (attr != (c & 0xff00)) {
+ attr = c & 0xff00;
+ if (s > start) {
+ fbcon_putcs(vc, start, s - start,
+ dy, x);
+ x += s - start;
+ start = s;
+ }
+ }
+ console_conditional_schedule();
+ s++;
+ } while (s < le);
+ if (s > start)
+ fbcon_putcs(vc, start, s - start, dy, x);
+ console_conditional_schedule();
+ dy++;
+ }
+}
+
+static __inline__ void ywrap_up(struct vc_data *vc, int count)
+{
+ struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fbcon_ops *ops = info->fbcon_par;
+ struct fbcon_display *p = &fb_display[vc->vc_num];
+
+ p->yscroll += count;
+ if (p->yscroll >= p->vrows) /* Deal with wrap */
+ p->yscroll -= p->vrows;
+ ops->var.xoffset = 0;
+ ops->var.yoffset = p->yscroll * vc->vc_font.height;
+ ops->var.vmode |= FB_VMODE_YWRAP;
+ ops->update_start(info);
+ scrollback_max += count;
+ if (scrollback_max > scrollback_phys_max)
+ scrollback_max = scrollback_phys_max;
+ scrollback_current = 0;
+}
+
+static __inline__ void ywrap_down(struct vc_data *vc, int count)
+{
+ struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fbcon_ops *ops = info->fbcon_par;
+ struct fbcon_display *p = &fb_display[vc->vc_num];
+
+ p->yscroll -= count;
+ if (p->yscroll < 0) /* Deal with wrap */
+ p->yscroll += p->vrows;
+ ops->var.xoffset = 0;
+ ops->var.yoffset = p->yscroll * vc->vc_font.height;
+ ops->var.vmode |= FB_VMODE_YWRAP;
+ ops->update_start(info);
+ scrollback_max -= count;
+ if (scrollback_max < 0)
+ scrollback_max = 0;
+ scrollback_current = 0;
+}
+
+static __inline__ void ypan_up(struct vc_data *vc, int count)
+{
+ struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fbcon_display *p = &fb_display[vc->vc_num];
+ struct fbcon_ops *ops = info->fbcon_par;
+
+ p->yscroll += count;
+ if (p->yscroll > p->vrows - vc->vc_rows) {
+ ops->bmove(vc, info, p->vrows - vc->vc_rows,
+ 0, 0, 0, vc->vc_rows, vc->vc_cols);
+ p->yscroll -= p->vrows - vc->vc_rows;
+ }
+
+ ops->var.xoffset = 0;
+ ops->var.yoffset = p->yscroll * vc->vc_font.height;
+ ops->var.vmode &= ~FB_VMODE_YWRAP;
+ ops->update_start(info);
+ fbcon_clear_margins(vc, 1);
+ scrollback_max += count;
+ if (scrollback_max > scrollback_phys_max)
+ scrollback_max = scrollback_phys_max;
+ scrollback_current = 0;
+}
+
+static __inline__ void ypan_up_redraw(struct vc_data *vc, int t, int count)
+{
+ struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fbcon_ops *ops = info->fbcon_par;
+ struct fbcon_display *p = &fb_display[vc->vc_num];
+
+ p->yscroll += count;
+
+ if (p->yscroll > p->vrows - vc->vc_rows) {
+ p->yscroll -= p->vrows - vc->vc_rows;
+ fbcon_redraw_move(vc, p, t + count, vc->vc_rows - count, t);
+ }
+
+ ops->var.xoffset = 0;
+ ops->var.yoffset = p->yscroll * vc->vc_font.height;
+ ops->var.vmode &= ~FB_VMODE_YWRAP;
+ ops->update_start(info);
+ fbcon_clear_margins(vc, 1);
+ scrollback_max += count;
+ if (scrollback_max > scrollback_phys_max)
+ scrollback_max = scrollback_phys_max;
+ scrollback_current = 0;
+}
+
+static __inline__ void ypan_down(struct vc_data *vc, int count)
+{
+ struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fbcon_display *p = &fb_display[vc->vc_num];
+ struct fbcon_ops *ops = info->fbcon_par;
+
+ p->yscroll -= count;
+ if (p->yscroll < 0) {
+ ops->bmove(vc, info, 0, 0, p->vrows - vc->vc_rows,
+ 0, vc->vc_rows, vc->vc_cols);
+ p->yscroll += p->vrows - vc->vc_rows;
+ }
+
+ ops->var.xoffset = 0;
+ ops->var.yoffset = p->yscroll * vc->vc_font.height;
+ ops->var.vmode &= ~FB_VMODE_YWRAP;
+ ops->update_start(info);
+ fbcon_clear_margins(vc, 1);
+ scrollback_max -= count;
+ if (scrollback_max < 0)
+ scrollback_max = 0;
+ scrollback_current = 0;
+}
+
+static __inline__ void ypan_down_redraw(struct vc_data *vc, int t, int count)
+{
+ struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fbcon_ops *ops = info->fbcon_par;
+ struct fbcon_display *p = &fb_display[vc->vc_num];
+
+ p->yscroll -= count;
+
+ if (p->yscroll < 0) {
+ p->yscroll += p->vrows - vc->vc_rows;
+ fbcon_redraw_move(vc, p, t, vc->vc_rows - count, t + count);
+ }
+
+ ops->var.xoffset = 0;
+ ops->var.yoffset = p->yscroll * vc->vc_font.height;
+ ops->var.vmode &= ~FB_VMODE_YWRAP;
+ ops->update_start(info);
+ fbcon_clear_margins(vc, 1);
+ scrollback_max -= count;
+ if (scrollback_max < 0)
+ scrollback_max = 0;
+ scrollback_current = 0;
+}
+
+static void fbcon_bmove_rec(struct vc_data *vc, struct fbcon_display *p, int sy, int sx,
+ int dy, int dx, int height, int width, u_int y_break)
+{
+ struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fbcon_ops *ops = info->fbcon_par;
+ u_int b;
+
+ if (sy < y_break && sy + height > y_break) {
+ b = y_break - sy;
+ if (dy < sy) { /* Avoid trashing self */
+ fbcon_bmove_rec(vc, p, sy, sx, dy, dx, b, width,
+ y_break);
+ fbcon_bmove_rec(vc, p, sy + b, sx, dy + b, dx,
+ height - b, width, y_break);
+ } else {
+ fbcon_bmove_rec(vc, p, sy + b, sx, dy + b, dx,
+ height - b, width, y_break);
+ fbcon_bmove_rec(vc, p, sy, sx, dy, dx, b, width,
+ y_break);
+ }
+ return;
+ }
+
+ if (dy < y_break && dy + height > y_break) {
+ b = y_break - dy;
+ if (dy < sy) { /* Avoid trashing self */
+ fbcon_bmove_rec(vc, p, sy, sx, dy, dx, b, width,
+ y_break);
+ fbcon_bmove_rec(vc, p, sy + b, sx, dy + b, dx,
+ height - b, width, y_break);
+ } else {
+ fbcon_bmove_rec(vc, p, sy + b, sx, dy + b, dx,
+ height - b, width, y_break);
+ fbcon_bmove_rec(vc, p, sy, sx, dy, dx, b, width,
+ y_break);
+ }
+ return;
+ }
+ ops->bmove(vc, info, real_y(p, sy), sx, real_y(p, dy), dx,
+ height, width);
+}
+
+static void fbcon_bmove(struct vc_data *vc, int sy, int sx, int dy, int dx,
+ int height, int width)
+{
+ struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fbcon_display *p = &fb_display[vc->vc_num];
+
+ if (fbcon_is_inactive(vc, info))
+ return;
+
+ if (!width || !height)
+ return;
+
+ /* Split blits that cross physical y_wrap case.
+ * Pathological case involves 4 blits, better to use recursive
+ * code rather than unrolled case
+ *
+ * Recursive invocations don't need to erase the cursor over and
+ * over again, so we use fbcon_bmove_rec()
+ */
+ fbcon_bmove_rec(vc, p, sy, sx, dy, dx, height, width,
+ p->vrows - p->yscroll);
+}
+
+static void fbcon_redraw_blit(struct vc_data *vc, struct fb_info *info,
+ struct fbcon_display *p, int line, int count, int ycount)
+{
+ int offset = ycount * vc->vc_cols;
+ unsigned short *d = (unsigned short *)
+ (vc->vc_origin + vc->vc_size_row * line);
+ unsigned short *s = d + offset;
+ struct fbcon_ops *ops = info->fbcon_par;
+
+ while (count--) {
+ unsigned short *start = s;
+ unsigned short *le = advance_row(s, 1);
+ unsigned short c;
+ int x = 0;
+
+ do {
+ c = scr_readw(s);
+
+ if (c == scr_readw(d)) {
+ if (s > start) {
+ ops->bmove(vc, info, line + ycount, x,
+ line, x, 1, s-start);
+ x += s - start + 1;
+ start = s + 1;
+ } else {
+ x++;
+ start++;
+ }
+ }
+
+ scr_writew(c, d);
+ console_conditional_schedule();
+ s++;
+ d++;
+ } while (s < le);
+ if (s > start)
+ ops->bmove(vc, info, line + ycount, x, line, x, 1,
+ s-start);
+ console_conditional_schedule();
+ if (ycount > 0)
+ line++;
+ else {
+ line--;
+ /* NOTE: We subtract two lines from these pointers */
+ s -= vc->vc_size_row;
+ d -= vc->vc_size_row;
+ }
+ }
+}
+#endif
+
static void fbcon_redraw(struct vc_data *vc, struct fbcon_display *p,
int line, int count, int offset)
{
@@ -1450,6 +1744,9 @@ static bool fbcon_scroll(struct vc_data *vc, unsigned int t, unsigned int b,
{
struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
struct fbcon_display *p = &fb_display[vc->vc_num];
+#ifdef CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
+ int scroll_partial = info->flags & FBINFO_PARTIAL_PAN_OK;
+#endif
if (fbcon_is_inactive(vc, info))
return true;
@@ -1466,6 +1763,7 @@ static bool fbcon_scroll(struct vc_data *vc, unsigned int t, unsigned int b,
case SM_UP:
if (count > vc->vc_rows) /* Maximum realistic size */
count = vc->vc_rows;
+#ifndef CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
fbcon_redraw(vc, p, t, b - t - count,
count * vc->vc_cols);
fbcon_clear(vc, b - count, 0, count, vc->vc_cols);
@@ -1475,10 +1773,99 @@ static bool fbcon_scroll(struct vc_data *vc, unsigned int t, unsigned int b,
vc->vc_video_erase_char,
vc->vc_size_row * count);
return true;
+#else
+ if (logo_shown >= 0)
+ goto redraw_up;
+ switch (p->scrollmode) {
+ case SCROLL_MOVE:
+ fbcon_redraw_blit(vc, info, p, t, b - t - count,
+ count);
+ fbcon_clear(vc, b - count, 0, count, vc->vc_cols);
+ scr_memsetw((unsigned short *) (vc->vc_origin +
+ vc->vc_size_row *
+ (b - count)),
+ vc->vc_video_erase_char,
+ vc->vc_size_row * count);
+ return true;
+
+ case SCROLL_WRAP_MOVE:
+ if (b - t - count > 3 * vc->vc_rows >> 2) {
+ if (t > 0)
+ fbcon_bmove(vc, 0, 0, count, 0, t,
+ vc->vc_cols);
+ ywrap_up(vc, count);
+ if (vc->vc_rows - b > 0)
+ fbcon_bmove(vc, b - count, 0, b, 0,
+ vc->vc_rows - b,
+ vc->vc_cols);
+ } else if (info->flags & FBINFO_READS_FAST)
+ fbcon_bmove(vc, t + count, 0, t, 0,
+ b - t - count, vc->vc_cols);
+ else
+ goto redraw_up;
+ fbcon_clear(vc, b - count, 0, count, vc->vc_cols);
+ break;
+
+ case SCROLL_PAN_REDRAW:
+ if ((p->yscroll + count <=
+ 2 * (p->vrows - vc->vc_rows))
+ && ((!scroll_partial && (b - t == vc->vc_rows))
+ || (scroll_partial
+ && (b - t - count >
+ 3 * vc->vc_rows >> 2)))) {
+ if (t > 0)
+ fbcon_redraw_move(vc, p, 0, t, count);
+ ypan_up_redraw(vc, t, count);
+ if (vc->vc_rows - b > 0)
+ fbcon_redraw_move(vc, p, b,
+ vc->vc_rows - b, b);
+ } else
+ fbcon_redraw_move(vc, p, t + count, b - t - count, t);
+ fbcon_clear(vc, b - count, 0, count, vc->vc_cols);
+ break;
+
+ case SCROLL_PAN_MOVE:
+ if ((p->yscroll + count <=
+ 2 * (p->vrows - vc->vc_rows))
+ && ((!scroll_partial && (b - t == vc->vc_rows))
+ || (scroll_partial
+ && (b - t - count >
+ 3 * vc->vc_rows >> 2)))) {
+ if (t > 0)
+ fbcon_bmove(vc, 0, 0, count, 0, t,
+ vc->vc_cols);
+ ypan_up(vc, count);
+ if (vc->vc_rows - b > 0)
+ fbcon_bmove(vc, b - count, 0, b, 0,
+ vc->vc_rows - b,
+ vc->vc_cols);
+ } else if (info->flags & FBINFO_READS_FAST)
+ fbcon_bmove(vc, t + count, 0, t, 0,
+ b - t - count, vc->vc_cols);
+ else
+ goto redraw_up;
+ fbcon_clear(vc, b - count, 0, count, vc->vc_cols);
+ break;
+
+ case SCROLL_REDRAW:
+ redraw_up:
+ fbcon_redraw(vc, p, t, b - t - count,
+ count * vc->vc_cols);
+ fbcon_clear(vc, b - count, 0, count, vc->vc_cols);
+ scr_memsetw((unsigned short *) (vc->vc_origin +
+ vc->vc_size_row *
+ (b - count)),
+ vc->vc_video_erase_char,
+ vc->vc_size_row * count);
+ return true;
+ }
+ break;
+#endif
case SM_DOWN:
if (count > vc->vc_rows) /* Maximum realistic size */
count = vc->vc_rows;
+#ifndef CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
fbcon_redraw(vc, p, b - 1, b - t - count,
-count * vc->vc_cols);
fbcon_clear(vc, t, 0, count, vc->vc_cols);
@@ -1488,10 +1875,96 @@ static bool fbcon_scroll(struct vc_data *vc, unsigned int t, unsigned int b,
vc->vc_video_erase_char,
vc->vc_size_row * count);
return true;
+#else
+ if (logo_shown >= 0)
+ goto redraw_down;
+ switch (p->scrollmode) {
+ case SCROLL_MOVE:
+ fbcon_redraw_blit(vc, info, p, b - 1, b - t - count,
+ -count);
+ fbcon_clear(vc, t, 0, count, vc->vc_cols);
+ scr_memsetw((unsigned short *) (vc->vc_origin +
+ vc->vc_size_row *
+ t),
+ vc->vc_video_erase_char,
+ vc->vc_size_row * count);
+ return true;
+
+ case SCROLL_WRAP_MOVE:
+ if (b - t - count > 3 * vc->vc_rows >> 2) {
+ if (vc->vc_rows - b > 0)
+ fbcon_bmove(vc, b, 0, b - count, 0,
+ vc->vc_rows - b,
+ vc->vc_cols);
+ ywrap_down(vc, count);
+ if (t > 0)
+ fbcon_bmove(vc, count, 0, 0, 0, t,
+ vc->vc_cols);
+ } else if (info->flags & FBINFO_READS_FAST)
+ fbcon_bmove(vc, t, 0, t + count, 0,
+ b - t - count, vc->vc_cols);
+ else
+ goto redraw_down;
+ fbcon_clear(vc, t, 0, count, vc->vc_cols);
+ break;
+
+ case SCROLL_PAN_MOVE:
+ if ((count - p->yscroll <= p->vrows - vc->vc_rows)
+ && ((!scroll_partial && (b - t == vc->vc_rows))
+ || (scroll_partial
+ && (b - t - count >
+ 3 * vc->vc_rows >> 2)))) {
+ if (vc->vc_rows - b > 0)
+ fbcon_bmove(vc, b, 0, b - count, 0,
+ vc->vc_rows - b,
+ vc->vc_cols);
+ ypan_down(vc, count);
+ if (t > 0)
+ fbcon_bmove(vc, count, 0, 0, 0, t,
+ vc->vc_cols);
+ } else if (info->flags & FBINFO_READS_FAST)
+ fbcon_bmove(vc, t, 0, t + count, 0,
+ b - t - count, vc->vc_cols);
+ else
+ goto redraw_down;
+ fbcon_clear(vc, t, 0, count, vc->vc_cols);
+ break;
+
+ case SCROLL_PAN_REDRAW:
+ if ((count - p->yscroll <= p->vrows - vc->vc_rows)
+ && ((!scroll_partial && (b - t == vc->vc_rows))
+ || (scroll_partial
+ && (b - t - count >
+ 3 * vc->vc_rows >> 2)))) {
+ if (vc->vc_rows - b > 0)
+ fbcon_redraw_move(vc, p, b, vc->vc_rows - b,
+ b - count);
+ ypan_down_redraw(vc, t, count);
+ if (t > 0)
+ fbcon_redraw_move(vc, p, count, t, 0);
+ } else
+ fbcon_redraw_move(vc, p, t, b - t - count, t + count);
+ fbcon_clear(vc, t, 0, count, vc->vc_cols);
+ break;
+
+ case SCROLL_REDRAW:
+ redraw_down:
+ fbcon_redraw(vc, p, b - 1, b - t - count,
+ -count * vc->vc_cols);
+ fbcon_clear(vc, t, 0, count, vc->vc_cols);
+ scr_memsetw((unsigned short *) (vc->vc_origin +
+ vc->vc_size_row *
+ t),
+ vc->vc_video_erase_char,
+ vc->vc_size_row * count);
+ return true;
+ }
+#endif
}
return false;
}
+
static void updatescrollmode(struct fbcon_display *p,
struct fb_info *info,
struct vc_data *vc)
@@ -1664,7 +2137,21 @@ static int fbcon_switch(struct vc_data *vc)
updatescrollmode(p, info, vc);
- scrollback_phys_max = 0;
+ switch (p->scrollmode) {
+ case SCROLL_WRAP_MOVE:
+ scrollback_phys_max = p->vrows - vc->vc_rows;
+ break;
+ case SCROLL_PAN_MOVE:
+ case SCROLL_PAN_REDRAW:
+ scrollback_phys_max = p->vrows - 2 * vc->vc_rows;
+ if (scrollback_phys_max < 0)
+ scrollback_phys_max = 0;
+ break;
+ default:
+ scrollback_phys_max = 0;
+ break;
+ }
+
scrollback_max = 0;
scrollback_current = 0;
diff --git a/drivers/video/fbdev/core/fbcon.h b/drivers/video/fbdev/core/fbcon.h
index a00603b4451a..5246d0f2574b 100644
--- a/drivers/video/fbdev/core/fbcon.h
+++ b/drivers/video/fbdev/core/fbcon.h
@@ -29,6 +29,7 @@ struct fbcon_display {
/* Filled in by the low-level console driver */
const u_char *fontdata;
int userfont; /* != 0 if fontdata kmalloc()ed */
+ u_short scrollmode; /* Scroll Method */
u_short inverse; /* != 0 text black on white as default */
short yscroll; /* Hardware scrolling */
int vrows; /* number of virtual rows */
@@ -51,6 +52,8 @@ struct fbcon_display {
};
struct fbcon_ops {
+ void (*bmove)(struct vc_data *vc, struct fb_info *info, int sy,
+ int sx, int dy, int dx, int height, int width);
void (*clear)(struct vc_data *vc, struct fb_info *info, int sy,
int sx, int height, int width);
void (*putcs)(struct vc_data *vc, struct fb_info *info,
@@ -149,6 +152,62 @@ static inline int attr_col_ec(int shift, struct vc_data *vc,
#define attr_bgcol_ec(bgshift, vc, info) attr_col_ec(bgshift, vc, info, 0)
#define attr_fgcol_ec(fgshift, vc, info) attr_col_ec(fgshift, vc, info, 1)
+ /*
+ * Scroll Method
+ */
+
+/* There are several methods fbcon can use to move text around the screen:
+ *
+ * Operation Pan Wrap
+ *---------------------------------------------
+ * SCROLL_MOVE copyarea No No
+ * SCROLL_PAN_MOVE copyarea Yes No
+ * SCROLL_WRAP_MOVE copyarea No Yes
+ * SCROLL_REDRAW imageblit No No
+ * SCROLL_PAN_REDRAW imageblit Yes No
+ * SCROLL_WRAP_REDRAW imageblit No Yes
+ *
+ * (SCROLL_WRAP_REDRAW is not implemented yet)
+ *
+ * In general, fbcon will choose the best scrolling
+ * method based on the rule below:
+ *
+ * Pan/Wrap > accel imageblit > accel copyarea >
+ * soft imageblit > (soft copyarea)
+ *
+ * Exception to the rule: Pan + accel copyarea is
+ * preferred over Pan + accel imageblit.
+ *
+ * The above is typical for PCI/AGP cards. Unless
+ * overridden, fbcon will never use soft copyarea.
+ *
+ * If you need to override the above rule, set the
+ * appropriate flags in fb_info->flags. For example,
+ * to prefer copyarea over imageblit, set
+ * FBINFO_READS_FAST.
+ *
+ * Other notes:
+ * + use the hardware engine to move the text
+ * (hw-accelerated copyarea() and fillrect())
+ * + use hardware-supported panning on a large virtual screen
+ * + amifb can not only pan, but also wrap the display by N lines
+ * (i.e. visible line i = physical line (i+N) % yres).
+ * + read what's already rendered on the screen and
+ * write it in a different place (this is cfb_copyarea())
+ * + re-render the text to the screen
+ *
+ * Whether to use wrapping or panning can only be figured out at
+ * runtime (when we know whether our font height is a multiple
+ * of the pan/wrap step)
+ *
+ */
+
+#define SCROLL_MOVE 0x001
+#define SCROLL_PAN_MOVE 0x002
+#define SCROLL_WRAP_MOVE 0x003
+#define SCROLL_REDRAW 0x004
+#define SCROLL_PAN_REDRAW 0x005
+
#ifdef CONFIG_FB_TILEBLITTING
extern void fbcon_set_tileops(struct vc_data *vc, struct fb_info *info);
#endif
diff --git a/drivers/video/fbdev/core/fbcon_ccw.c b/drivers/video/fbdev/core/fbcon_ccw.c
index ffa78936eaab..9cd2c4b05c32 100644
--- a/drivers/video/fbdev/core/fbcon_ccw.c
+++ b/drivers/video/fbdev/core/fbcon_ccw.c
@@ -59,12 +59,31 @@ static void ccw_update_attr(u8 *dst, u8 *src, int attribute,
}
}
+
+static void ccw_bmove(struct vc_data *vc, struct fb_info *info, int sy,
+ int sx, int dy, int dx, int height, int width)
+{
+ struct fbcon_ops *ops = info->fbcon_par;
+ struct fb_copyarea area;
+ u32 vyres = GETVYRES(ops->p->scrollmode, info);
+
+ area.sx = sy * vc->vc_font.height;
+ area.sy = vyres - ((sx + width) * vc->vc_font.width);
+ area.dx = dy * vc->vc_font.height;
+ area.dy = vyres - ((dx + width) * vc->vc_font.width);
+ area.width = height * vc->vc_font.height;
+ area.height = width * vc->vc_font.width;
+
+ info->fbops->fb_copyarea(info, &area);
+}
+
static void ccw_clear(struct vc_data *vc, struct fb_info *info, int sy,
int sx, int height, int width)
{
+ struct fbcon_ops *ops = info->fbcon_par;
struct fb_fillrect region;
int bgshift = (vc->vc_hi_font_mask) ? 13 : 12;
- u32 vyres = info->var.yres;
+ u32 vyres = GETVYRES(ops->p->scrollmode, info);
region.color = attr_bgcol_ec(bgshift,vc,info);
region.dx = sy * vc->vc_font.height;
@@ -121,7 +140,7 @@ static void ccw_putcs(struct vc_data *vc, struct fb_info *info,
u32 cnt, pitch, size;
u32 attribute = get_attribute(info, scr_readw(s));
u8 *dst, *buf = NULL;
- u32 vyres = info->var.yres;
+ u32 vyres = GETVYRES(ops->p->scrollmode, info);
if (!ops->fontbuffer)
return;
@@ -210,7 +229,7 @@ static void ccw_cursor(struct vc_data *vc, struct fb_info *info, int mode,
int attribute, use_sw = vc->vc_cursor_type & CUR_SW;
int err = 1, dx, dy;
char *src;
- u32 vyres = info->var.yres;
+ u32 vyres = GETVYRES(ops->p->scrollmode, info);
if (!ops->fontbuffer)
return;
@@ -368,7 +387,7 @@ static int ccw_update_start(struct fb_info *info)
{
struct fbcon_ops *ops = info->fbcon_par;
u32 yoffset;
- u32 vyres = info->var.yres;
+ u32 vyres = GETVYRES(ops->p->scrollmode, info);
int err;
yoffset = (vyres - info->var.yres) - ops->var.xoffset;
@@ -383,6 +402,7 @@ static int ccw_update_start(struct fb_info *info)
void fbcon_rotate_ccw(struct fbcon_ops *ops)
{
+ ops->bmove = ccw_bmove;
ops->clear = ccw_clear;
ops->putcs = ccw_putcs;
ops->clear_margins = ccw_clear_margins;
diff --git a/drivers/video/fbdev/core/fbcon_cw.c b/drivers/video/fbdev/core/fbcon_cw.c
index 92e5b7fb51ee..88d89fad3f05 100644
--- a/drivers/video/fbdev/core/fbcon_cw.c
+++ b/drivers/video/fbdev/core/fbcon_cw.c
@@ -44,12 +44,31 @@ static void cw_update_attr(u8 *dst, u8 *src, int attribute,
}
}
+
+static void cw_bmove(struct vc_data *vc, struct fb_info *info, int sy,
+ int sx, int dy, int dx, int height, int width)
+{
+ struct fbcon_ops *ops = info->fbcon_par;
+ struct fb_copyarea area;
+ u32 vxres = GETVXRES(ops->p->scrollmode, info);
+
+ area.sx = vxres - ((sy + height) * vc->vc_font.height);
+ area.sy = sx * vc->vc_font.width;
+ area.dx = vxres - ((dy + height) * vc->vc_font.height);
+ area.dy = dx * vc->vc_font.width;
+ area.width = height * vc->vc_font.height;
+ area.height = width * vc->vc_font.width;
+
+ info->fbops->fb_copyarea(info, &area);
+}
+
static void cw_clear(struct vc_data *vc, struct fb_info *info, int sy,
int sx, int height, int width)
{
+ struct fbcon_ops *ops = info->fbcon_par;
struct fb_fillrect region;
int bgshift = (vc->vc_hi_font_mask) ? 13 : 12;
- u32 vxres = info->var.xres;
+ u32 vxres = GETVXRES(ops->p->scrollmode, info);
region.color = attr_bgcol_ec(bgshift,vc,info);
region.dx = vxres - ((sy + height) * vc->vc_font.height);
@@ -106,7 +125,7 @@ static void cw_putcs(struct vc_data *vc, struct fb_info *info,
u32 cnt, pitch, size;
u32 attribute = get_attribute(info, scr_readw(s));
u8 *dst, *buf = NULL;
- u32 vxres = info->var.xres;
+ u32 vxres = GETVXRES(ops->p->scrollmode, info);
if (!ops->fontbuffer)
return;
@@ -193,7 +212,7 @@ static void cw_cursor(struct vc_data *vc, struct fb_info *info, int mode,
int attribute, use_sw = vc->vc_cursor_type & CUR_SW;
int err = 1, dx, dy;
char *src;
- u32 vxres = info->var.xres;
+ u32 vxres = GETVXRES(ops->p->scrollmode, info);
if (!ops->fontbuffer)
return;
@@ -350,7 +369,7 @@ static void cw_cursor(struct vc_data *vc, struct fb_info *info, int mode,
static int cw_update_start(struct fb_info *info)
{
struct fbcon_ops *ops = info->fbcon_par;
- u32 vxres = info->var.xres;
+ u32 vxres = GETVXRES(ops->p->scrollmode, info);
u32 xoffset;
int err;
@@ -366,6 +385,7 @@ static int cw_update_start(struct fb_info *info)
void fbcon_rotate_cw(struct fbcon_ops *ops)
{
+ ops->bmove = cw_bmove;
ops->clear = cw_clear;
ops->putcs = cw_putcs;
ops->clear_margins = cw_clear_margins;
diff --git a/drivers/video/fbdev/core/fbcon_rotate.h b/drivers/video/fbdev/core/fbcon_rotate.h
index b528b2e54283..21cb81615883 100644
--- a/drivers/video/fbdev/core/fbcon_rotate.h
+++ b/drivers/video/fbdev/core/fbcon_rotate.h
@@ -11,6 +11,27 @@
#ifndef _FBCON_ROTATE_H
#define _FBCON_ROTATE_H
+#ifdef CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
+#define GETVYRES(s,i) ({ \
+ (s == SCROLL_REDRAW || s == SCROLL_MOVE) ? \
+ (i)->var.yres : (i)->var.yres_virtual; })
+
+#define GETVXRES(s,i) ({ \
+ (s == SCROLL_REDRAW || s == SCROLL_MOVE || !(i)->fix.xpanstep) ? \
+ (i)->var.xres : (i)->var.xres_virtual; })
+#else
+static inline u32 GETVYRES(int s, struct fb_info *i)
+{
+ return i->var.yres;
+}
+
+static inline u32 GETVXRES(int s, struct fb_info *i)
+{
+ return i->var.xres;
+}
+#endif
+
+
static inline int pattern_test_bit(u32 x, u32 y, u32 pitch, const char *pat)
{
u32 tmp = (y * pitch) + x, index = tmp / 8, bit = tmp % 8;
diff --git a/drivers/video/fbdev/core/fbcon_ud.c b/drivers/video/fbdev/core/fbcon_ud.c
index 09619bd8e021..8d5e66b1bdfb 100644
--- a/drivers/video/fbdev/core/fbcon_ud.c
+++ b/drivers/video/fbdev/core/fbcon_ud.c
@@ -44,13 +44,33 @@ static void ud_update_attr(u8 *dst, u8 *src, int attribute,
}
}
+
+static void ud_bmove(struct vc_data *vc, struct fb_info *info, int sy,
+ int sx, int dy, int dx, int height, int width)
+{
+ struct fbcon_ops *ops = info->fbcon_par;
+ struct fb_copyarea area;
+ u32 vyres = GETVYRES(ops->p->scrollmode, info);
+ u32 vxres = GETVXRES(ops->p->scrollmode, info);
+
+ area.sy = vyres - ((sy + height) * vc->vc_font.height);
+ area.sx = vxres - ((sx + width) * vc->vc_font.width);
+ area.dy = vyres - ((dy + height) * vc->vc_font.height);
+ area.dx = vxres - ((dx + width) * vc->vc_font.width);
+ area.height = height * vc->vc_font.height;
+ area.width = width * vc->vc_font.width;
+
+ info->fbops->fb_copyarea(info, &area);
+}
+
static void ud_clear(struct vc_data *vc, struct fb_info *info, int sy,
int sx, int height, int width)
{
+ struct fbcon_ops *ops = info->fbcon_par;
struct fb_fillrect region;
int bgshift = (vc->vc_hi_font_mask) ? 13 : 12;
- u32 vyres = info->var.yres;
- u32 vxres = info->var.xres;
+ u32 vyres = GETVYRES(ops->p->scrollmode, info);
+ u32 vxres = GETVXRES(ops->p->scrollmode, info);
region.color = attr_bgcol_ec(bgshift,vc,info);
region.dy = vyres - ((sy + height) * vc->vc_font.height);
@@ -142,8 +162,8 @@ static void ud_putcs(struct vc_data *vc, struct fb_info *info,
u32 mod = vc->vc_font.width % 8, cnt, pitch, size;
u32 attribute = get_attribute(info, scr_readw(s));
u8 *dst, *buf = NULL;
- u32 vyres = info->var.yres;
- u32 vxres = info->var.xres;
+ u32 vyres = GETVYRES(ops->p->scrollmode, info);
+ u32 vxres = GETVXRES(ops->p->scrollmode, info);
if (!ops->fontbuffer)
return;
@@ -239,8 +259,8 @@ static void ud_cursor(struct vc_data *vc, struct fb_info *info, int mode,
int attribute, use_sw = vc->vc_cursor_type & CUR_SW;
int err = 1, dx, dy;
char *src;
- u32 vyres = info->var.yres;
- u32 vxres = info->var.xres;
+ u32 vyres = GETVYRES(ops->p->scrollmode, info);
+ u32 vxres = GETVXRES(ops->p->scrollmode, info);
if (!ops->fontbuffer)
return;
@@ -390,8 +410,8 @@ static int ud_update_start(struct fb_info *info)
{
struct fbcon_ops *ops = info->fbcon_par;
int xoffset, yoffset;
- u32 vyres = info->var.yres;
- u32 vxres = info->var.xres;
+ u32 vyres = GETVYRES(ops->p->scrollmode, info);
+ u32 vxres = GETVXRES(ops->p->scrollmode, info);
int err;
xoffset = vxres - info->var.xres - ops->var.xoffset;
@@ -409,6 +429,7 @@ static int ud_update_start(struct fb_info *info)
void fbcon_rotate_ud(struct fbcon_ops *ops)
{
+ ops->bmove = ud_bmove;
ops->clear = ud_clear;
ops->putcs = ud_putcs;
ops->clear_margins = ud_clear_margins;
diff --git a/drivers/video/fbdev/core/tileblit.c b/drivers/video/fbdev/core/tileblit.c
index 72af95053bcb..2768eff247ba 100644
--- a/drivers/video/fbdev/core/tileblit.c
+++ b/drivers/video/fbdev/core/tileblit.c
@@ -16,6 +16,21 @@
#include <asm/types.h>
#include "fbcon.h"
+static void tile_bmove(struct vc_data *vc, struct fb_info *info, int sy,
+ int sx, int dy, int dx, int height, int width)
+{
+ struct fb_tilearea area;
+
+ area.sx = sx;
+ area.sy = sy;
+ area.dx = dx;
+ area.dy = dy;
+ area.height = height;
+ area.width = width;
+
+ info->tileops->fb_tilecopy(info, &area);
+}
+
static void tile_clear(struct vc_data *vc, struct fb_info *info, int sy,
int sx, int height, int width)
{
@@ -118,6 +133,7 @@ void fbcon_set_tileops(struct vc_data *vc, struct fb_info *info)
struct fb_tilemap map;
struct fbcon_ops *ops = info->fbcon_par;
+ ops->bmove = tile_bmove;
ops->clear = tile_clear;
ops->putcs = tile_putcs;
ops->clear_margins = tile_clear_margins;
diff --git a/drivers/video/fbdev/skeletonfb.c b/drivers/video/fbdev/skeletonfb.c
index 0fe922f726e9..bcacfb6934fa 100644
--- a/drivers/video/fbdev/skeletonfb.c
+++ b/drivers/video/fbdev/skeletonfb.c
@@ -505,15 +505,15 @@ void xxxfb_fillrect(struct fb_info *p, const struct fb_fillrect *region)
}
/**
- * xxxfb_copyarea - OBSOLETE function.
+ * xxxfb_copyarea - REQUIRED function. Can use generic routines if
+ * non acclerated hardware and packed pixel based.
* Copies one area of the screen to another area.
- * Will be deleted in a future version
*
* @info: frame buffer structure that represents a single frame buffer
* @area: Structure providing the data to copy the framebuffer contents
* from one region to another.
*
- * This drawing operation copied a rectangular area from one area of the
+ * This drawing operation copies a rectangular area from one area of the
* screen to another area.
*/
void xxxfb_copyarea(struct fb_info *p, const struct fb_copyarea *area)
@@ -645,9 +645,9 @@ static const struct fb_ops xxxfb_ops = {
.fb_setcolreg = xxxfb_setcolreg,
.fb_blank = xxxfb_blank,
.fb_pan_display = xxxfb_pan_display,
- .fb_fillrect = xxxfb_fillrect, /* Needed !!! */
- .fb_copyarea = xxxfb_copyarea, /* Obsolete */
- .fb_imageblit = xxxfb_imageblit, /* Needed !!! */
+ .fb_fillrect = xxxfb_fillrect, /* Needed !!! */
+ .fb_copyarea = xxxfb_copyarea, /* Needed !!! */
+ .fb_imageblit = xxxfb_imageblit, /* Needed !!! */
.fb_cursor = xxxfb_cursor, /* Optional !!! */
.fb_sync = xxxfb_sync,
.fb_ioctl = xxxfb_ioctl,
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 3da95842b207..02f362c661c8 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -262,7 +262,7 @@ struct fb_ops {
/* Draws a rectangle */
void (*fb_fillrect) (struct fb_info *info, const struct fb_fillrect *rect);
- /* Copy data from area to another. Obsolete. */
+ /* Copy data from area to another */
void (*fb_copyarea) (struct fb_info *info, const struct fb_copyarea *region);
/* Draws a image to the display */
void (*fb_imageblit) (struct fb_info *info, const struct fb_image *image);
--
2.33.0
^ permalink raw reply related [flat|nested] 241+ messages in thread
* [PATCH 02/21] fbcon: Resurrect fbcon accelerated scrolling code
@ 2022-01-31 21:05 ` Daniel Vetter
0 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-01-31 21:05 UTC (permalink / raw)
To: DRI Development
Cc: linux-fbdev, Thomas Zimmermann, Sam Ravnborg, Daniel Vetter,
Daniel Vetter, Intel Graphics Development, LKML, stable,
Javier Martinez Canillas, Linus Torvalds, Tomi Valkeinen,
Claudio Suarez, Pavel Machek, Greg Kroah-Hartman,
Geert Uytterhoeven, Sven Schnelle, Gerd Hoffmann
This reverts commit b3ec8cdf457e ("fbdev: Garbage collect fbdev
scrolling acceleration, part 1 (from TODO list)"), but with a twist:
Because distros like fedora&suse (probably more) really want to move
away from fbcon as much as possible, and don't have a need for fancy
accelerated fbcon even less, hide the code behind an option.
There's also been noises about resurrecting the scrollback code and
other pieces, so there's plenty of need for such an option it seems.
Compared to direct revert I did move functions around a bit so they're
all in one block, to minimize the number of #ifdef.
I also tried to stuff this all into a separate file, but that didn't
really look much better. I also considered duplicating fbcon_scroll()
since that's a bit meh now, but again didn't seem worth the trouble.
Maybe when we resurect more code.
And finally to shut up unused parameter warnings warnings the macros
became static inline.
References: https://lore.kernel.org/dri-devel/feea8303-2b83-fc36-972c-4fc8ad723bde@gmx.de/
Fixes: b3ec8cdf457e ("fbdev: Garbage collect fbdev scrolling acceleration, part 1 (from TODO list)")
Cc: Claudio Suarez <cssk@net-c.es>
Cc: <stable@vger.kernel.org> # v5.16+
Cc: Dave Airlie <airlied@gmail.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Linux Fbdev development list <linux-fbdev@vger.kernel.org>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Javier Martinez Canillas <javierm@redhat.com>
Cc: DRI Development <dri-devel@lists.freedesktop.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Cc: Claudio Suarez <cssk@net-c.es>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Sven Schnelle <svens@stackframe.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
Documentation/gpu/todo.rst | 13 +-
drivers/video/console/Kconfig | 11 +
drivers/video/fbdev/core/bitblit.c | 16 +
drivers/video/fbdev/core/fbcon.c | 491 +++++++++++++++++++++++-
drivers/video/fbdev/core/fbcon.h | 59 +++
drivers/video/fbdev/core/fbcon_ccw.c | 28 +-
drivers/video/fbdev/core/fbcon_cw.c | 28 +-
drivers/video/fbdev/core/fbcon_rotate.h | 21 +
drivers/video/fbdev/core/fbcon_ud.c | 37 +-
drivers/video/fbdev/core/tileblit.c | 16 +
drivers/video/fbdev/skeletonfb.c | 12 +-
include/linux/fb.h | 2 +-
12 files changed, 701 insertions(+), 33 deletions(-)
diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index da138dd39883..29506815d24a 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -303,19 +303,16 @@ Level: Advanced
Garbage collect fbdev scrolling acceleration
--------------------------------------------
-Scroll acceleration has been disabled in fbcon. Now it works as the old
-SCROLL_REDRAW mode. A ton of code was removed in fbcon.c and the hook bmove was
-removed from fbcon_ops.
-Remaining tasks:
+Scroll acceleration is disabled in fbcon by hard-wiring p->scrollmode =
+SCROLL_REDRAW. There's a ton of code this will allow us to remove:
-- a bunch of the hooks in fbcon_ops could be removed or simplified by calling
+- lots of code in fbcon.c
+
+- a bunch of the hooks in fbcon_ops, maybe the remaining hooks could be called
directly instead of the function table (with a switch on p->rotate)
- fb_copyarea is unused after this, and can be deleted from all drivers
-- after that, fb_copyarea can be deleted from fb_ops in include/linux/fb.h as
- well as cfb_copyarea
-
Note that not all acceleration code can be deleted, since clearing and cursor
support is still accelerated, which might be good candidates for further
deletion projects.
diff --git a/drivers/video/console/Kconfig b/drivers/video/console/Kconfig
index 840d9813b0bc..f83f5c755084 100644
--- a/drivers/video/console/Kconfig
+++ b/drivers/video/console/Kconfig
@@ -78,6 +78,17 @@ config FRAMEBUFFER_CONSOLE
help
Low-level framebuffer-based console driver.
+config FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
+ bool "Enable legacy fbcon code for hw acceleration"
+ depends on FRAMEBUFFER_CONSOLE
+ default n
+ help
+ Only enable this options if you are in full control of machine since
+ the fbcon acceleration code is essentially unmaintained and known
+ problematic.
+
+ If unsure, select n.
+
config FRAMEBUFFER_CONSOLE_DETECT_PRIMARY
bool "Map the console to the primary display device"
depends on FRAMEBUFFER_CONSOLE
diff --git a/drivers/video/fbdev/core/bitblit.c b/drivers/video/fbdev/core/bitblit.c
index 01fae2c96965..f98e8f298bc1 100644
--- a/drivers/video/fbdev/core/bitblit.c
+++ b/drivers/video/fbdev/core/bitblit.c
@@ -43,6 +43,21 @@ static void update_attr(u8 *dst, u8 *src, int attribute,
}
}
+static void bit_bmove(struct vc_data *vc, struct fb_info *info, int sy,
+ int sx, int dy, int dx, int height, int width)
+{
+ struct fb_copyarea area;
+
+ area.sx = sx * vc->vc_font.width;
+ area.sy = sy * vc->vc_font.height;
+ area.dx = dx * vc->vc_font.width;
+ area.dy = dy * vc->vc_font.height;
+ area.height = height * vc->vc_font.height;
+ area.width = width * vc->vc_font.width;
+
+ info->fbops->fb_copyarea(info, &area);
+}
+
static void bit_clear(struct vc_data *vc, struct fb_info *info, int sy,
int sx, int height, int width)
{
@@ -378,6 +393,7 @@ static int bit_update_start(struct fb_info *info)
void fbcon_set_bitops(struct fbcon_ops *ops)
{
+ ops->bmove = bit_bmove;
ops->clear = bit_clear;
ops->putcs = bit_putcs;
ops->clear_margins = bit_clear_margins;
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 99ecd9a6d844..2ff90061c7f3 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -1125,6 +1125,14 @@ static void fbcon_init(struct vc_data *vc, int init)
ops->graphics = 0;
+ /*
+ * No more hw acceleration for fbcon.
+ *
+ * FIXME: Garbage collect all the now dead code after sufficient time
+ * has passed.
+ */
+ p->scrollmode = SCROLL_REDRAW;
+
/*
* ++guenther: console.c:vc_allocate() relies on initializing
* vc_{cols,rows}, but we must not set those if we are only
@@ -1211,13 +1219,14 @@ static void fbcon_deinit(struct vc_data *vc)
* This system is now divided into two levels because of complications
* caused by hardware scrolling. Top level functions:
*
- * fbcon_clear(), fbcon_putc(), fbcon_clear_margins()
+ * fbcon_bmove(), fbcon_clear(), fbcon_putc(), fbcon_clear_margins()
*
* handles y values in range [0, scr_height-1] that correspond to real
* screen positions. y_wrap shift means that first line of bitmap may be
* anywhere on this display. These functions convert lineoffsets to
* bitmap offsets and deal with the wrap-around case by splitting blits.
*
+ * fbcon_bmove_physical_8() -- These functions fast implementations
* fbcon_clear_physical_8() -- of original fbcon_XXX fns.
* fbcon_putc_physical_8() -- (font width != 8) may be added later
*
@@ -1390,6 +1399,291 @@ static void fbcon_set_disp(struct fb_info *info, struct fb_var_screeninfo *var,
}
}
+#ifdef CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
+static void fbcon_redraw_move(struct vc_data *vc, struct fbcon_display *p,
+ int line, int count, int dy)
+{
+ unsigned short *s = (unsigned short *)
+ (vc->vc_origin + vc->vc_size_row * line);
+
+ while (count--) {
+ unsigned short *start = s;
+ unsigned short *le = advance_row(s, 1);
+ unsigned short c;
+ int x = 0;
+ unsigned short attr = 1;
+
+ do {
+ c = scr_readw(s);
+ if (attr != (c & 0xff00)) {
+ attr = c & 0xff00;
+ if (s > start) {
+ fbcon_putcs(vc, start, s - start,
+ dy, x);
+ x += s - start;
+ start = s;
+ }
+ }
+ console_conditional_schedule();
+ s++;
+ } while (s < le);
+ if (s > start)
+ fbcon_putcs(vc, start, s - start, dy, x);
+ console_conditional_schedule();
+ dy++;
+ }
+}
+
+static __inline__ void ywrap_up(struct vc_data *vc, int count)
+{
+ struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fbcon_ops *ops = info->fbcon_par;
+ struct fbcon_display *p = &fb_display[vc->vc_num];
+
+ p->yscroll += count;
+ if (p->yscroll >= p->vrows) /* Deal with wrap */
+ p->yscroll -= p->vrows;
+ ops->var.xoffset = 0;
+ ops->var.yoffset = p->yscroll * vc->vc_font.height;
+ ops->var.vmode |= FB_VMODE_YWRAP;
+ ops->update_start(info);
+ scrollback_max += count;
+ if (scrollback_max > scrollback_phys_max)
+ scrollback_max = scrollback_phys_max;
+ scrollback_current = 0;
+}
+
+static __inline__ void ywrap_down(struct vc_data *vc, int count)
+{
+ struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fbcon_ops *ops = info->fbcon_par;
+ struct fbcon_display *p = &fb_display[vc->vc_num];
+
+ p->yscroll -= count;
+ if (p->yscroll < 0) /* Deal with wrap */
+ p->yscroll += p->vrows;
+ ops->var.xoffset = 0;
+ ops->var.yoffset = p->yscroll * vc->vc_font.height;
+ ops->var.vmode |= FB_VMODE_YWRAP;
+ ops->update_start(info);
+ scrollback_max -= count;
+ if (scrollback_max < 0)
+ scrollback_max = 0;
+ scrollback_current = 0;
+}
+
+static __inline__ void ypan_up(struct vc_data *vc, int count)
+{
+ struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fbcon_display *p = &fb_display[vc->vc_num];
+ struct fbcon_ops *ops = info->fbcon_par;
+
+ p->yscroll += count;
+ if (p->yscroll > p->vrows - vc->vc_rows) {
+ ops->bmove(vc, info, p->vrows - vc->vc_rows,
+ 0, 0, 0, vc->vc_rows, vc->vc_cols);
+ p->yscroll -= p->vrows - vc->vc_rows;
+ }
+
+ ops->var.xoffset = 0;
+ ops->var.yoffset = p->yscroll * vc->vc_font.height;
+ ops->var.vmode &= ~FB_VMODE_YWRAP;
+ ops->update_start(info);
+ fbcon_clear_margins(vc, 1);
+ scrollback_max += count;
+ if (scrollback_max > scrollback_phys_max)
+ scrollback_max = scrollback_phys_max;
+ scrollback_current = 0;
+}
+
+static __inline__ void ypan_up_redraw(struct vc_data *vc, int t, int count)
+{
+ struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fbcon_ops *ops = info->fbcon_par;
+ struct fbcon_display *p = &fb_display[vc->vc_num];
+
+ p->yscroll += count;
+
+ if (p->yscroll > p->vrows - vc->vc_rows) {
+ p->yscroll -= p->vrows - vc->vc_rows;
+ fbcon_redraw_move(vc, p, t + count, vc->vc_rows - count, t);
+ }
+
+ ops->var.xoffset = 0;
+ ops->var.yoffset = p->yscroll * vc->vc_font.height;
+ ops->var.vmode &= ~FB_VMODE_YWRAP;
+ ops->update_start(info);
+ fbcon_clear_margins(vc, 1);
+ scrollback_max += count;
+ if (scrollback_max > scrollback_phys_max)
+ scrollback_max = scrollback_phys_max;
+ scrollback_current = 0;
+}
+
+static __inline__ void ypan_down(struct vc_data *vc, int count)
+{
+ struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fbcon_display *p = &fb_display[vc->vc_num];
+ struct fbcon_ops *ops = info->fbcon_par;
+
+ p->yscroll -= count;
+ if (p->yscroll < 0) {
+ ops->bmove(vc, info, 0, 0, p->vrows - vc->vc_rows,
+ 0, vc->vc_rows, vc->vc_cols);
+ p->yscroll += p->vrows - vc->vc_rows;
+ }
+
+ ops->var.xoffset = 0;
+ ops->var.yoffset = p->yscroll * vc->vc_font.height;
+ ops->var.vmode &= ~FB_VMODE_YWRAP;
+ ops->update_start(info);
+ fbcon_clear_margins(vc, 1);
+ scrollback_max -= count;
+ if (scrollback_max < 0)
+ scrollback_max = 0;
+ scrollback_current = 0;
+}
+
+static __inline__ void ypan_down_redraw(struct vc_data *vc, int t, int count)
+{
+ struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fbcon_ops *ops = info->fbcon_par;
+ struct fbcon_display *p = &fb_display[vc->vc_num];
+
+ p->yscroll -= count;
+
+ if (p->yscroll < 0) {
+ p->yscroll += p->vrows - vc->vc_rows;
+ fbcon_redraw_move(vc, p, t, vc->vc_rows - count, t + count);
+ }
+
+ ops->var.xoffset = 0;
+ ops->var.yoffset = p->yscroll * vc->vc_font.height;
+ ops->var.vmode &= ~FB_VMODE_YWRAP;
+ ops->update_start(info);
+ fbcon_clear_margins(vc, 1);
+ scrollback_max -= count;
+ if (scrollback_max < 0)
+ scrollback_max = 0;
+ scrollback_current = 0;
+}
+
+static void fbcon_bmove_rec(struct vc_data *vc, struct fbcon_display *p, int sy, int sx,
+ int dy, int dx, int height, int width, u_int y_break)
+{
+ struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fbcon_ops *ops = info->fbcon_par;
+ u_int b;
+
+ if (sy < y_break && sy + height > y_break) {
+ b = y_break - sy;
+ if (dy < sy) { /* Avoid trashing self */
+ fbcon_bmove_rec(vc, p, sy, sx, dy, dx, b, width,
+ y_break);
+ fbcon_bmove_rec(vc, p, sy + b, sx, dy + b, dx,
+ height - b, width, y_break);
+ } else {
+ fbcon_bmove_rec(vc, p, sy + b, sx, dy + b, dx,
+ height - b, width, y_break);
+ fbcon_bmove_rec(vc, p, sy, sx, dy, dx, b, width,
+ y_break);
+ }
+ return;
+ }
+
+ if (dy < y_break && dy + height > y_break) {
+ b = y_break - dy;
+ if (dy < sy) { /* Avoid trashing self */
+ fbcon_bmove_rec(vc, p, sy, sx, dy, dx, b, width,
+ y_break);
+ fbcon_bmove_rec(vc, p, sy + b, sx, dy + b, dx,
+ height - b, width, y_break);
+ } else {
+ fbcon_bmove_rec(vc, p, sy + b, sx, dy + b, dx,
+ height - b, width, y_break);
+ fbcon_bmove_rec(vc, p, sy, sx, dy, dx, b, width,
+ y_break);
+ }
+ return;
+ }
+ ops->bmove(vc, info, real_y(p, sy), sx, real_y(p, dy), dx,
+ height, width);
+}
+
+static void fbcon_bmove(struct vc_data *vc, int sy, int sx, int dy, int dx,
+ int height, int width)
+{
+ struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fbcon_display *p = &fb_display[vc->vc_num];
+
+ if (fbcon_is_inactive(vc, info))
+ return;
+
+ if (!width || !height)
+ return;
+
+ /* Split blits that cross physical y_wrap case.
+ * Pathological case involves 4 blits, better to use recursive
+ * code rather than unrolled case
+ *
+ * Recursive invocations don't need to erase the cursor over and
+ * over again, so we use fbcon_bmove_rec()
+ */
+ fbcon_bmove_rec(vc, p, sy, sx, dy, dx, height, width,
+ p->vrows - p->yscroll);
+}
+
+static void fbcon_redraw_blit(struct vc_data *vc, struct fb_info *info,
+ struct fbcon_display *p, int line, int count, int ycount)
+{
+ int offset = ycount * vc->vc_cols;
+ unsigned short *d = (unsigned short *)
+ (vc->vc_origin + vc->vc_size_row * line);
+ unsigned short *s = d + offset;
+ struct fbcon_ops *ops = info->fbcon_par;
+
+ while (count--) {
+ unsigned short *start = s;
+ unsigned short *le = advance_row(s, 1);
+ unsigned short c;
+ int x = 0;
+
+ do {
+ c = scr_readw(s);
+
+ if (c == scr_readw(d)) {
+ if (s > start) {
+ ops->bmove(vc, info, line + ycount, x,
+ line, x, 1, s-start);
+ x += s - start + 1;
+ start = s + 1;
+ } else {
+ x++;
+ start++;
+ }
+ }
+
+ scr_writew(c, d);
+ console_conditional_schedule();
+ s++;
+ d++;
+ } while (s < le);
+ if (s > start)
+ ops->bmove(vc, info, line + ycount, x, line, x, 1,
+ s-start);
+ console_conditional_schedule();
+ if (ycount > 0)
+ line++;
+ else {
+ line--;
+ /* NOTE: We subtract two lines from these pointers */
+ s -= vc->vc_size_row;
+ d -= vc->vc_size_row;
+ }
+ }
+}
+#endif
+
static void fbcon_redraw(struct vc_data *vc, struct fbcon_display *p,
int line, int count, int offset)
{
@@ -1450,6 +1744,9 @@ static bool fbcon_scroll(struct vc_data *vc, unsigned int t, unsigned int b,
{
struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
struct fbcon_display *p = &fb_display[vc->vc_num];
+#ifdef CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
+ int scroll_partial = info->flags & FBINFO_PARTIAL_PAN_OK;
+#endif
if (fbcon_is_inactive(vc, info))
return true;
@@ -1466,6 +1763,7 @@ static bool fbcon_scroll(struct vc_data *vc, unsigned int t, unsigned int b,
case SM_UP:
if (count > vc->vc_rows) /* Maximum realistic size */
count = vc->vc_rows;
+#ifndef CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
fbcon_redraw(vc, p, t, b - t - count,
count * vc->vc_cols);
fbcon_clear(vc, b - count, 0, count, vc->vc_cols);
@@ -1475,10 +1773,99 @@ static bool fbcon_scroll(struct vc_data *vc, unsigned int t, unsigned int b,
vc->vc_video_erase_char,
vc->vc_size_row * count);
return true;
+#else
+ if (logo_shown >= 0)
+ goto redraw_up;
+ switch (p->scrollmode) {
+ case SCROLL_MOVE:
+ fbcon_redraw_blit(vc, info, p, t, b - t - count,
+ count);
+ fbcon_clear(vc, b - count, 0, count, vc->vc_cols);
+ scr_memsetw((unsigned short *) (vc->vc_origin +
+ vc->vc_size_row *
+ (b - count)),
+ vc->vc_video_erase_char,
+ vc->vc_size_row * count);
+ return true;
+
+ case SCROLL_WRAP_MOVE:
+ if (b - t - count > 3 * vc->vc_rows >> 2) {
+ if (t > 0)
+ fbcon_bmove(vc, 0, 0, count, 0, t,
+ vc->vc_cols);
+ ywrap_up(vc, count);
+ if (vc->vc_rows - b > 0)
+ fbcon_bmove(vc, b - count, 0, b, 0,
+ vc->vc_rows - b,
+ vc->vc_cols);
+ } else if (info->flags & FBINFO_READS_FAST)
+ fbcon_bmove(vc, t + count, 0, t, 0,
+ b - t - count, vc->vc_cols);
+ else
+ goto redraw_up;
+ fbcon_clear(vc, b - count, 0, count, vc->vc_cols);
+ break;
+
+ case SCROLL_PAN_REDRAW:
+ if ((p->yscroll + count <=
+ 2 * (p->vrows - vc->vc_rows))
+ && ((!scroll_partial && (b - t == vc->vc_rows))
+ || (scroll_partial
+ && (b - t - count >
+ 3 * vc->vc_rows >> 2)))) {
+ if (t > 0)
+ fbcon_redraw_move(vc, p, 0, t, count);
+ ypan_up_redraw(vc, t, count);
+ if (vc->vc_rows - b > 0)
+ fbcon_redraw_move(vc, p, b,
+ vc->vc_rows - b, b);
+ } else
+ fbcon_redraw_move(vc, p, t + count, b - t - count, t);
+ fbcon_clear(vc, b - count, 0, count, vc->vc_cols);
+ break;
+
+ case SCROLL_PAN_MOVE:
+ if ((p->yscroll + count <=
+ 2 * (p->vrows - vc->vc_rows))
+ && ((!scroll_partial && (b - t == vc->vc_rows))
+ || (scroll_partial
+ && (b - t - count >
+ 3 * vc->vc_rows >> 2)))) {
+ if (t > 0)
+ fbcon_bmove(vc, 0, 0, count, 0, t,
+ vc->vc_cols);
+ ypan_up(vc, count);
+ if (vc->vc_rows - b > 0)
+ fbcon_bmove(vc, b - count, 0, b, 0,
+ vc->vc_rows - b,
+ vc->vc_cols);
+ } else if (info->flags & FBINFO_READS_FAST)
+ fbcon_bmove(vc, t + count, 0, t, 0,
+ b - t - count, vc->vc_cols);
+ else
+ goto redraw_up;
+ fbcon_clear(vc, b - count, 0, count, vc->vc_cols);
+ break;
+
+ case SCROLL_REDRAW:
+ redraw_up:
+ fbcon_redraw(vc, p, t, b - t - count,
+ count * vc->vc_cols);
+ fbcon_clear(vc, b - count, 0, count, vc->vc_cols);
+ scr_memsetw((unsigned short *) (vc->vc_origin +
+ vc->vc_size_row *
+ (b - count)),
+ vc->vc_video_erase_char,
+ vc->vc_size_row * count);
+ return true;
+ }
+ break;
+#endif
case SM_DOWN:
if (count > vc->vc_rows) /* Maximum realistic size */
count = vc->vc_rows;
+#ifndef CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
fbcon_redraw(vc, p, b - 1, b - t - count,
-count * vc->vc_cols);
fbcon_clear(vc, t, 0, count, vc->vc_cols);
@@ -1488,10 +1875,96 @@ static bool fbcon_scroll(struct vc_data *vc, unsigned int t, unsigned int b,
vc->vc_video_erase_char,
vc->vc_size_row * count);
return true;
+#else
+ if (logo_shown >= 0)
+ goto redraw_down;
+ switch (p->scrollmode) {
+ case SCROLL_MOVE:
+ fbcon_redraw_blit(vc, info, p, b - 1, b - t - count,
+ -count);
+ fbcon_clear(vc, t, 0, count, vc->vc_cols);
+ scr_memsetw((unsigned short *) (vc->vc_origin +
+ vc->vc_size_row *
+ t),
+ vc->vc_video_erase_char,
+ vc->vc_size_row * count);
+ return true;
+
+ case SCROLL_WRAP_MOVE:
+ if (b - t - count > 3 * vc->vc_rows >> 2) {
+ if (vc->vc_rows - b > 0)
+ fbcon_bmove(vc, b, 0, b - count, 0,
+ vc->vc_rows - b,
+ vc->vc_cols);
+ ywrap_down(vc, count);
+ if (t > 0)
+ fbcon_bmove(vc, count, 0, 0, 0, t,
+ vc->vc_cols);
+ } else if (info->flags & FBINFO_READS_FAST)
+ fbcon_bmove(vc, t, 0, t + count, 0,
+ b - t - count, vc->vc_cols);
+ else
+ goto redraw_down;
+ fbcon_clear(vc, t, 0, count, vc->vc_cols);
+ break;
+
+ case SCROLL_PAN_MOVE:
+ if ((count - p->yscroll <= p->vrows - vc->vc_rows)
+ && ((!scroll_partial && (b - t == vc->vc_rows))
+ || (scroll_partial
+ && (b - t - count >
+ 3 * vc->vc_rows >> 2)))) {
+ if (vc->vc_rows - b > 0)
+ fbcon_bmove(vc, b, 0, b - count, 0,
+ vc->vc_rows - b,
+ vc->vc_cols);
+ ypan_down(vc, count);
+ if (t > 0)
+ fbcon_bmove(vc, count, 0, 0, 0, t,
+ vc->vc_cols);
+ } else if (info->flags & FBINFO_READS_FAST)
+ fbcon_bmove(vc, t, 0, t + count, 0,
+ b - t - count, vc->vc_cols);
+ else
+ goto redraw_down;
+ fbcon_clear(vc, t, 0, count, vc->vc_cols);
+ break;
+
+ case SCROLL_PAN_REDRAW:
+ if ((count - p->yscroll <= p->vrows - vc->vc_rows)
+ && ((!scroll_partial && (b - t == vc->vc_rows))
+ || (scroll_partial
+ && (b - t - count >
+ 3 * vc->vc_rows >> 2)))) {
+ if (vc->vc_rows - b > 0)
+ fbcon_redraw_move(vc, p, b, vc->vc_rows - b,
+ b - count);
+ ypan_down_redraw(vc, t, count);
+ if (t > 0)
+ fbcon_redraw_move(vc, p, count, t, 0);
+ } else
+ fbcon_redraw_move(vc, p, t, b - t - count, t + count);
+ fbcon_clear(vc, t, 0, count, vc->vc_cols);
+ break;
+
+ case SCROLL_REDRAW:
+ redraw_down:
+ fbcon_redraw(vc, p, b - 1, b - t - count,
+ -count * vc->vc_cols);
+ fbcon_clear(vc, t, 0, count, vc->vc_cols);
+ scr_memsetw((unsigned short *) (vc->vc_origin +
+ vc->vc_size_row *
+ t),
+ vc->vc_video_erase_char,
+ vc->vc_size_row * count);
+ return true;
+ }
+#endif
}
return false;
}
+
static void updatescrollmode(struct fbcon_display *p,
struct fb_info *info,
struct vc_data *vc)
@@ -1664,7 +2137,21 @@ static int fbcon_switch(struct vc_data *vc)
updatescrollmode(p, info, vc);
- scrollback_phys_max = 0;
+ switch (p->scrollmode) {
+ case SCROLL_WRAP_MOVE:
+ scrollback_phys_max = p->vrows - vc->vc_rows;
+ break;
+ case SCROLL_PAN_MOVE:
+ case SCROLL_PAN_REDRAW:
+ scrollback_phys_max = p->vrows - 2 * vc->vc_rows;
+ if (scrollback_phys_max < 0)
+ scrollback_phys_max = 0;
+ break;
+ default:
+ scrollback_phys_max = 0;
+ break;
+ }
+
scrollback_max = 0;
scrollback_current = 0;
diff --git a/drivers/video/fbdev/core/fbcon.h b/drivers/video/fbdev/core/fbcon.h
index a00603b4451a..5246d0f2574b 100644
--- a/drivers/video/fbdev/core/fbcon.h
+++ b/drivers/video/fbdev/core/fbcon.h
@@ -29,6 +29,7 @@ struct fbcon_display {
/* Filled in by the low-level console driver */
const u_char *fontdata;
int userfont; /* != 0 if fontdata kmalloc()ed */
+ u_short scrollmode; /* Scroll Method */
u_short inverse; /* != 0 text black on white as default */
short yscroll; /* Hardware scrolling */
int vrows; /* number of virtual rows */
@@ -51,6 +52,8 @@ struct fbcon_display {
};
struct fbcon_ops {
+ void (*bmove)(struct vc_data *vc, struct fb_info *info, int sy,
+ int sx, int dy, int dx, int height, int width);
void (*clear)(struct vc_data *vc, struct fb_info *info, int sy,
int sx, int height, int width);
void (*putcs)(struct vc_data *vc, struct fb_info *info,
@@ -149,6 +152,62 @@ static inline int attr_col_ec(int shift, struct vc_data *vc,
#define attr_bgcol_ec(bgshift, vc, info) attr_col_ec(bgshift, vc, info, 0)
#define attr_fgcol_ec(fgshift, vc, info) attr_col_ec(fgshift, vc, info, 1)
+ /*
+ * Scroll Method
+ */
+
+/* There are several methods fbcon can use to move text around the screen:
+ *
+ * Operation Pan Wrap
+ *---------------------------------------------
+ * SCROLL_MOVE copyarea No No
+ * SCROLL_PAN_MOVE copyarea Yes No
+ * SCROLL_WRAP_MOVE copyarea No Yes
+ * SCROLL_REDRAW imageblit No No
+ * SCROLL_PAN_REDRAW imageblit Yes No
+ * SCROLL_WRAP_REDRAW imageblit No Yes
+ *
+ * (SCROLL_WRAP_REDRAW is not implemented yet)
+ *
+ * In general, fbcon will choose the best scrolling
+ * method based on the rule below:
+ *
+ * Pan/Wrap > accel imageblit > accel copyarea >
+ * soft imageblit > (soft copyarea)
+ *
+ * Exception to the rule: Pan + accel copyarea is
+ * preferred over Pan + accel imageblit.
+ *
+ * The above is typical for PCI/AGP cards. Unless
+ * overridden, fbcon will never use soft copyarea.
+ *
+ * If you need to override the above rule, set the
+ * appropriate flags in fb_info->flags. For example,
+ * to prefer copyarea over imageblit, set
+ * FBINFO_READS_FAST.
+ *
+ * Other notes:
+ * + use the hardware engine to move the text
+ * (hw-accelerated copyarea() and fillrect())
+ * + use hardware-supported panning on a large virtual screen
+ * + amifb can not only pan, but also wrap the display by N lines
+ * (i.e. visible line i = physical line (i+N) % yres).
+ * + read what's already rendered on the screen and
+ * write it in a different place (this is cfb_copyarea())
+ * + re-render the text to the screen
+ *
+ * Whether to use wrapping or panning can only be figured out at
+ * runtime (when we know whether our font height is a multiple
+ * of the pan/wrap step)
+ *
+ */
+
+#define SCROLL_MOVE 0x001
+#define SCROLL_PAN_MOVE 0x002
+#define SCROLL_WRAP_MOVE 0x003
+#define SCROLL_REDRAW 0x004
+#define SCROLL_PAN_REDRAW 0x005
+
#ifdef CONFIG_FB_TILEBLITTING
extern void fbcon_set_tileops(struct vc_data *vc, struct fb_info *info);
#endif
diff --git a/drivers/video/fbdev/core/fbcon_ccw.c b/drivers/video/fbdev/core/fbcon_ccw.c
index ffa78936eaab..9cd2c4b05c32 100644
--- a/drivers/video/fbdev/core/fbcon_ccw.c
+++ b/drivers/video/fbdev/core/fbcon_ccw.c
@@ -59,12 +59,31 @@ static void ccw_update_attr(u8 *dst, u8 *src, int attribute,
}
}
+
+static void ccw_bmove(struct vc_data *vc, struct fb_info *info, int sy,
+ int sx, int dy, int dx, int height, int width)
+{
+ struct fbcon_ops *ops = info->fbcon_par;
+ struct fb_copyarea area;
+ u32 vyres = GETVYRES(ops->p->scrollmode, info);
+
+ area.sx = sy * vc->vc_font.height;
+ area.sy = vyres - ((sx + width) * vc->vc_font.width);
+ area.dx = dy * vc->vc_font.height;
+ area.dy = vyres - ((dx + width) * vc->vc_font.width);
+ area.width = height * vc->vc_font.height;
+ area.height = width * vc->vc_font.width;
+
+ info->fbops->fb_copyarea(info, &area);
+}
+
static void ccw_clear(struct vc_data *vc, struct fb_info *info, int sy,
int sx, int height, int width)
{
+ struct fbcon_ops *ops = info->fbcon_par;
struct fb_fillrect region;
int bgshift = (vc->vc_hi_font_mask) ? 13 : 12;
- u32 vyres = info->var.yres;
+ u32 vyres = GETVYRES(ops->p->scrollmode, info);
region.color = attr_bgcol_ec(bgshift,vc,info);
region.dx = sy * vc->vc_font.height;
@@ -121,7 +140,7 @@ static void ccw_putcs(struct vc_data *vc, struct fb_info *info,
u32 cnt, pitch, size;
u32 attribute = get_attribute(info, scr_readw(s));
u8 *dst, *buf = NULL;
- u32 vyres = info->var.yres;
+ u32 vyres = GETVYRES(ops->p->scrollmode, info);
if (!ops->fontbuffer)
return;
@@ -210,7 +229,7 @@ static void ccw_cursor(struct vc_data *vc, struct fb_info *info, int mode,
int attribute, use_sw = vc->vc_cursor_type & CUR_SW;
int err = 1, dx, dy;
char *src;
- u32 vyres = info->var.yres;
+ u32 vyres = GETVYRES(ops->p->scrollmode, info);
if (!ops->fontbuffer)
return;
@@ -368,7 +387,7 @@ static int ccw_update_start(struct fb_info *info)
{
struct fbcon_ops *ops = info->fbcon_par;
u32 yoffset;
- u32 vyres = info->var.yres;
+ u32 vyres = GETVYRES(ops->p->scrollmode, info);
int err;
yoffset = (vyres - info->var.yres) - ops->var.xoffset;
@@ -383,6 +402,7 @@ static int ccw_update_start(struct fb_info *info)
void fbcon_rotate_ccw(struct fbcon_ops *ops)
{
+ ops->bmove = ccw_bmove;
ops->clear = ccw_clear;
ops->putcs = ccw_putcs;
ops->clear_margins = ccw_clear_margins;
diff --git a/drivers/video/fbdev/core/fbcon_cw.c b/drivers/video/fbdev/core/fbcon_cw.c
index 92e5b7fb51ee..88d89fad3f05 100644
--- a/drivers/video/fbdev/core/fbcon_cw.c
+++ b/drivers/video/fbdev/core/fbcon_cw.c
@@ -44,12 +44,31 @@ static void cw_update_attr(u8 *dst, u8 *src, int attribute,
}
}
+
+static void cw_bmove(struct vc_data *vc, struct fb_info *info, int sy,
+ int sx, int dy, int dx, int height, int width)
+{
+ struct fbcon_ops *ops = info->fbcon_par;
+ struct fb_copyarea area;
+ u32 vxres = GETVXRES(ops->p->scrollmode, info);
+
+ area.sx = vxres - ((sy + height) * vc->vc_font.height);
+ area.sy = sx * vc->vc_font.width;
+ area.dx = vxres - ((dy + height) * vc->vc_font.height);
+ area.dy = dx * vc->vc_font.width;
+ area.width = height * vc->vc_font.height;
+ area.height = width * vc->vc_font.width;
+
+ info->fbops->fb_copyarea(info, &area);
+}
+
static void cw_clear(struct vc_data *vc, struct fb_info *info, int sy,
int sx, int height, int width)
{
+ struct fbcon_ops *ops = info->fbcon_par;
struct fb_fillrect region;
int bgshift = (vc->vc_hi_font_mask) ? 13 : 12;
- u32 vxres = info->var.xres;
+ u32 vxres = GETVXRES(ops->p->scrollmode, info);
region.color = attr_bgcol_ec(bgshift,vc,info);
region.dx = vxres - ((sy + height) * vc->vc_font.height);
@@ -106,7 +125,7 @@ static void cw_putcs(struct vc_data *vc, struct fb_info *info,
u32 cnt, pitch, size;
u32 attribute = get_attribute(info, scr_readw(s));
u8 *dst, *buf = NULL;
- u32 vxres = info->var.xres;
+ u32 vxres = GETVXRES(ops->p->scrollmode, info);
if (!ops->fontbuffer)
return;
@@ -193,7 +212,7 @@ static void cw_cursor(struct vc_data *vc, struct fb_info *info, int mode,
int attribute, use_sw = vc->vc_cursor_type & CUR_SW;
int err = 1, dx, dy;
char *src;
- u32 vxres = info->var.xres;
+ u32 vxres = GETVXRES(ops->p->scrollmode, info);
if (!ops->fontbuffer)
return;
@@ -350,7 +369,7 @@ static void cw_cursor(struct vc_data *vc, struct fb_info *info, int mode,
static int cw_update_start(struct fb_info *info)
{
struct fbcon_ops *ops = info->fbcon_par;
- u32 vxres = info->var.xres;
+ u32 vxres = GETVXRES(ops->p->scrollmode, info);
u32 xoffset;
int err;
@@ -366,6 +385,7 @@ static int cw_update_start(struct fb_info *info)
void fbcon_rotate_cw(struct fbcon_ops *ops)
{
+ ops->bmove = cw_bmove;
ops->clear = cw_clear;
ops->putcs = cw_putcs;
ops->clear_margins = cw_clear_margins;
diff --git a/drivers/video/fbdev/core/fbcon_rotate.h b/drivers/video/fbdev/core/fbcon_rotate.h
index b528b2e54283..21cb81615883 100644
--- a/drivers/video/fbdev/core/fbcon_rotate.h
+++ b/drivers/video/fbdev/core/fbcon_rotate.h
@@ -11,6 +11,27 @@
#ifndef _FBCON_ROTATE_H
#define _FBCON_ROTATE_H
+#ifdef CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
+#define GETVYRES(s,i) ({ \
+ (s == SCROLL_REDRAW || s == SCROLL_MOVE) ? \
+ (i)->var.yres : (i)->var.yres_virtual; })
+
+#define GETVXRES(s,i) ({ \
+ (s == SCROLL_REDRAW || s == SCROLL_MOVE || !(i)->fix.xpanstep) ? \
+ (i)->var.xres : (i)->var.xres_virtual; })
+#else
+static inline u32 GETVYRES(int s, struct fb_info *i)
+{
+ return i->var.yres;
+}
+
+static inline u32 GETVXRES(int s, struct fb_info *i)
+{
+ return i->var.xres;
+}
+#endif
+
+
static inline int pattern_test_bit(u32 x, u32 y, u32 pitch, const char *pat)
{
u32 tmp = (y * pitch) + x, index = tmp / 8, bit = tmp % 8;
diff --git a/drivers/video/fbdev/core/fbcon_ud.c b/drivers/video/fbdev/core/fbcon_ud.c
index 09619bd8e021..8d5e66b1bdfb 100644
--- a/drivers/video/fbdev/core/fbcon_ud.c
+++ b/drivers/video/fbdev/core/fbcon_ud.c
@@ -44,13 +44,33 @@ static void ud_update_attr(u8 *dst, u8 *src, int attribute,
}
}
+
+static void ud_bmove(struct vc_data *vc, struct fb_info *info, int sy,
+ int sx, int dy, int dx, int height, int width)
+{
+ struct fbcon_ops *ops = info->fbcon_par;
+ struct fb_copyarea area;
+ u32 vyres = GETVYRES(ops->p->scrollmode, info);
+ u32 vxres = GETVXRES(ops->p->scrollmode, info);
+
+ area.sy = vyres - ((sy + height) * vc->vc_font.height);
+ area.sx = vxres - ((sx + width) * vc->vc_font.width);
+ area.dy = vyres - ((dy + height) * vc->vc_font.height);
+ area.dx = vxres - ((dx + width) * vc->vc_font.width);
+ area.height = height * vc->vc_font.height;
+ area.width = width * vc->vc_font.width;
+
+ info->fbops->fb_copyarea(info, &area);
+}
+
static void ud_clear(struct vc_data *vc, struct fb_info *info, int sy,
int sx, int height, int width)
{
+ struct fbcon_ops *ops = info->fbcon_par;
struct fb_fillrect region;
int bgshift = (vc->vc_hi_font_mask) ? 13 : 12;
- u32 vyres = info->var.yres;
- u32 vxres = info->var.xres;
+ u32 vyres = GETVYRES(ops->p->scrollmode, info);
+ u32 vxres = GETVXRES(ops->p->scrollmode, info);
region.color = attr_bgcol_ec(bgshift,vc,info);
region.dy = vyres - ((sy + height) * vc->vc_font.height);
@@ -142,8 +162,8 @@ static void ud_putcs(struct vc_data *vc, struct fb_info *info,
u32 mod = vc->vc_font.width % 8, cnt, pitch, size;
u32 attribute = get_attribute(info, scr_readw(s));
u8 *dst, *buf = NULL;
- u32 vyres = info->var.yres;
- u32 vxres = info->var.xres;
+ u32 vyres = GETVYRES(ops->p->scrollmode, info);
+ u32 vxres = GETVXRES(ops->p->scrollmode, info);
if (!ops->fontbuffer)
return;
@@ -239,8 +259,8 @@ static void ud_cursor(struct vc_data *vc, struct fb_info *info, int mode,
int attribute, use_sw = vc->vc_cursor_type & CUR_SW;
int err = 1, dx, dy;
char *src;
- u32 vyres = info->var.yres;
- u32 vxres = info->var.xres;
+ u32 vyres = GETVYRES(ops->p->scrollmode, info);
+ u32 vxres = GETVXRES(ops->p->scrollmode, info);
if (!ops->fontbuffer)
return;
@@ -390,8 +410,8 @@ static int ud_update_start(struct fb_info *info)
{
struct fbcon_ops *ops = info->fbcon_par;
int xoffset, yoffset;
- u32 vyres = info->var.yres;
- u32 vxres = info->var.xres;
+ u32 vyres = GETVYRES(ops->p->scrollmode, info);
+ u32 vxres = GETVXRES(ops->p->scrollmode, info);
int err;
xoffset = vxres - info->var.xres - ops->var.xoffset;
@@ -409,6 +429,7 @@ static int ud_update_start(struct fb_info *info)
void fbcon_rotate_ud(struct fbcon_ops *ops)
{
+ ops->bmove = ud_bmove;
ops->clear = ud_clear;
ops->putcs = ud_putcs;
ops->clear_margins = ud_clear_margins;
diff --git a/drivers/video/fbdev/core/tileblit.c b/drivers/video/fbdev/core/tileblit.c
index 72af95053bcb..2768eff247ba 100644
--- a/drivers/video/fbdev/core/tileblit.c
+++ b/drivers/video/fbdev/core/tileblit.c
@@ -16,6 +16,21 @@
#include <asm/types.h>
#include "fbcon.h"
+static void tile_bmove(struct vc_data *vc, struct fb_info *info, int sy,
+ int sx, int dy, int dx, int height, int width)
+{
+ struct fb_tilearea area;
+
+ area.sx = sx;
+ area.sy = sy;
+ area.dx = dx;
+ area.dy = dy;
+ area.height = height;
+ area.width = width;
+
+ info->tileops->fb_tilecopy(info, &area);
+}
+
static void tile_clear(struct vc_data *vc, struct fb_info *info, int sy,
int sx, int height, int width)
{
@@ -118,6 +133,7 @@ void fbcon_set_tileops(struct vc_data *vc, struct fb_info *info)
struct fb_tilemap map;
struct fbcon_ops *ops = info->fbcon_par;
+ ops->bmove = tile_bmove;
ops->clear = tile_clear;
ops->putcs = tile_putcs;
ops->clear_margins = tile_clear_margins;
diff --git a/drivers/video/fbdev/skeletonfb.c b/drivers/video/fbdev/skeletonfb.c
index 0fe922f726e9..bcacfb6934fa 100644
--- a/drivers/video/fbdev/skeletonfb.c
+++ b/drivers/video/fbdev/skeletonfb.c
@@ -505,15 +505,15 @@ void xxxfb_fillrect(struct fb_info *p, const struct fb_fillrect *region)
}
/**
- * xxxfb_copyarea - OBSOLETE function.
+ * xxxfb_copyarea - REQUIRED function. Can use generic routines if
+ * non acclerated hardware and packed pixel based.
* Copies one area of the screen to another area.
- * Will be deleted in a future version
*
* @info: frame buffer structure that represents a single frame buffer
* @area: Structure providing the data to copy the framebuffer contents
* from one region to another.
*
- * This drawing operation copied a rectangular area from one area of the
+ * This drawing operation copies a rectangular area from one area of the
* screen to another area.
*/
void xxxfb_copyarea(struct fb_info *p, const struct fb_copyarea *area)
@@ -645,9 +645,9 @@ static const struct fb_ops xxxfb_ops = {
.fb_setcolreg = xxxfb_setcolreg,
.fb_blank = xxxfb_blank,
.fb_pan_display = xxxfb_pan_display,
- .fb_fillrect = xxxfb_fillrect, /* Needed !!! */
- .fb_copyarea = xxxfb_copyarea, /* Obsolete */
- .fb_imageblit = xxxfb_imageblit, /* Needed !!! */
+ .fb_fillrect = xxxfb_fillrect, /* Needed !!! */
+ .fb_copyarea = xxxfb_copyarea, /* Needed !!! */
+ .fb_imageblit = xxxfb_imageblit, /* Needed !!! */
.fb_cursor = xxxfb_cursor, /* Optional !!! */
.fb_sync = xxxfb_sync,
.fb_ioctl = xxxfb_ioctl,
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 3da95842b207..02f362c661c8 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -262,7 +262,7 @@ struct fb_ops {
/* Draws a rectangle */
void (*fb_fillrect) (struct fb_info *info, const struct fb_fillrect *rect);
- /* Copy data from area to another. Obsolete. */
+ /* Copy data from area to another */
void (*fb_copyarea) (struct fb_info *info, const struct fb_copyarea *region);
/* Draws a image to the display */
void (*fb_imageblit) (struct fb_info *info, const struct fb_image *image);
--
2.33.0
^ permalink raw reply related [flat|nested] 241+ messages in thread
* [Intel-gfx] [PATCH 02/21] fbcon: Resurrect fbcon accelerated scrolling code
@ 2022-01-31 21:05 ` Daniel Vetter
0 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-01-31 21:05 UTC (permalink / raw)
To: DRI Development
Cc: linux-fbdev, Thomas Zimmermann, Sam Ravnborg, Daniel Vetter,
Daniel Vetter, Intel Graphics Development, LKML, stable,
Javier Martinez Canillas, Linus Torvalds, Tomi Valkeinen,
Pavel Machek, Greg Kroah-Hartman, Geert Uytterhoeven,
Dave Airlie, Sven Schnelle, Gerd Hoffmann
This reverts commit b3ec8cdf457e ("fbdev: Garbage collect fbdev
scrolling acceleration, part 1 (from TODO list)"), but with a twist:
Because distros like fedora&suse (probably more) really want to move
away from fbcon as much as possible, and don't have a need for fancy
accelerated fbcon even less, hide the code behind an option.
There's also been noises about resurrecting the scrollback code and
other pieces, so there's plenty of need for such an option it seems.
Compared to direct revert I did move functions around a bit so they're
all in one block, to minimize the number of #ifdef.
I also tried to stuff this all into a separate file, but that didn't
really look much better. I also considered duplicating fbcon_scroll()
since that's a bit meh now, but again didn't seem worth the trouble.
Maybe when we resurect more code.
And finally to shut up unused parameter warnings warnings the macros
became static inline.
References: https://lore.kernel.org/dri-devel/feea8303-2b83-fc36-972c-4fc8ad723bde@gmx.de/
Fixes: b3ec8cdf457e ("fbdev: Garbage collect fbdev scrolling acceleration, part 1 (from TODO list)")
Cc: Claudio Suarez <cssk@net-c.es>
Cc: <stable@vger.kernel.org> # v5.16+
Cc: Dave Airlie <airlied@gmail.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Linux Fbdev development list <linux-fbdev@vger.kernel.org>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Javier Martinez Canillas <javierm@redhat.com>
Cc: DRI Development <dri-devel@lists.freedesktop.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Cc: Claudio Suarez <cssk@net-c.es>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Sven Schnelle <svens@stackframe.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
Documentation/gpu/todo.rst | 13 +-
drivers/video/console/Kconfig | 11 +
drivers/video/fbdev/core/bitblit.c | 16 +
drivers/video/fbdev/core/fbcon.c | 491 +++++++++++++++++++++++-
drivers/video/fbdev/core/fbcon.h | 59 +++
drivers/video/fbdev/core/fbcon_ccw.c | 28 +-
drivers/video/fbdev/core/fbcon_cw.c | 28 +-
drivers/video/fbdev/core/fbcon_rotate.h | 21 +
drivers/video/fbdev/core/fbcon_ud.c | 37 +-
drivers/video/fbdev/core/tileblit.c | 16 +
drivers/video/fbdev/skeletonfb.c | 12 +-
include/linux/fb.h | 2 +-
12 files changed, 701 insertions(+), 33 deletions(-)
diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index da138dd39883..29506815d24a 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -303,19 +303,16 @@ Level: Advanced
Garbage collect fbdev scrolling acceleration
--------------------------------------------
-Scroll acceleration has been disabled in fbcon. Now it works as the old
-SCROLL_REDRAW mode. A ton of code was removed in fbcon.c and the hook bmove was
-removed from fbcon_ops.
-Remaining tasks:
+Scroll acceleration is disabled in fbcon by hard-wiring p->scrollmode =
+SCROLL_REDRAW. There's a ton of code this will allow us to remove:
-- a bunch of the hooks in fbcon_ops could be removed or simplified by calling
+- lots of code in fbcon.c
+
+- a bunch of the hooks in fbcon_ops, maybe the remaining hooks could be called
directly instead of the function table (with a switch on p->rotate)
- fb_copyarea is unused after this, and can be deleted from all drivers
-- after that, fb_copyarea can be deleted from fb_ops in include/linux/fb.h as
- well as cfb_copyarea
-
Note that not all acceleration code can be deleted, since clearing and cursor
support is still accelerated, which might be good candidates for further
deletion projects.
diff --git a/drivers/video/console/Kconfig b/drivers/video/console/Kconfig
index 840d9813b0bc..f83f5c755084 100644
--- a/drivers/video/console/Kconfig
+++ b/drivers/video/console/Kconfig
@@ -78,6 +78,17 @@ config FRAMEBUFFER_CONSOLE
help
Low-level framebuffer-based console driver.
+config FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
+ bool "Enable legacy fbcon code for hw acceleration"
+ depends on FRAMEBUFFER_CONSOLE
+ default n
+ help
+ Only enable this options if you are in full control of machine since
+ the fbcon acceleration code is essentially unmaintained and known
+ problematic.
+
+ If unsure, select n.
+
config FRAMEBUFFER_CONSOLE_DETECT_PRIMARY
bool "Map the console to the primary display device"
depends on FRAMEBUFFER_CONSOLE
diff --git a/drivers/video/fbdev/core/bitblit.c b/drivers/video/fbdev/core/bitblit.c
index 01fae2c96965..f98e8f298bc1 100644
--- a/drivers/video/fbdev/core/bitblit.c
+++ b/drivers/video/fbdev/core/bitblit.c
@@ -43,6 +43,21 @@ static void update_attr(u8 *dst, u8 *src, int attribute,
}
}
+static void bit_bmove(struct vc_data *vc, struct fb_info *info, int sy,
+ int sx, int dy, int dx, int height, int width)
+{
+ struct fb_copyarea area;
+
+ area.sx = sx * vc->vc_font.width;
+ area.sy = sy * vc->vc_font.height;
+ area.dx = dx * vc->vc_font.width;
+ area.dy = dy * vc->vc_font.height;
+ area.height = height * vc->vc_font.height;
+ area.width = width * vc->vc_font.width;
+
+ info->fbops->fb_copyarea(info, &area);
+}
+
static void bit_clear(struct vc_data *vc, struct fb_info *info, int sy,
int sx, int height, int width)
{
@@ -378,6 +393,7 @@ static int bit_update_start(struct fb_info *info)
void fbcon_set_bitops(struct fbcon_ops *ops)
{
+ ops->bmove = bit_bmove;
ops->clear = bit_clear;
ops->putcs = bit_putcs;
ops->clear_margins = bit_clear_margins;
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 99ecd9a6d844..2ff90061c7f3 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -1125,6 +1125,14 @@ static void fbcon_init(struct vc_data *vc, int init)
ops->graphics = 0;
+ /*
+ * No more hw acceleration for fbcon.
+ *
+ * FIXME: Garbage collect all the now dead code after sufficient time
+ * has passed.
+ */
+ p->scrollmode = SCROLL_REDRAW;
+
/*
* ++guenther: console.c:vc_allocate() relies on initializing
* vc_{cols,rows}, but we must not set those if we are only
@@ -1211,13 +1219,14 @@ static void fbcon_deinit(struct vc_data *vc)
* This system is now divided into two levels because of complications
* caused by hardware scrolling. Top level functions:
*
- * fbcon_clear(), fbcon_putc(), fbcon_clear_margins()
+ * fbcon_bmove(), fbcon_clear(), fbcon_putc(), fbcon_clear_margins()
*
* handles y values in range [0, scr_height-1] that correspond to real
* screen positions. y_wrap shift means that first line of bitmap may be
* anywhere on this display. These functions convert lineoffsets to
* bitmap offsets and deal with the wrap-around case by splitting blits.
*
+ * fbcon_bmove_physical_8() -- These functions fast implementations
* fbcon_clear_physical_8() -- of original fbcon_XXX fns.
* fbcon_putc_physical_8() -- (font width != 8) may be added later
*
@@ -1390,6 +1399,291 @@ static void fbcon_set_disp(struct fb_info *info, struct fb_var_screeninfo *var,
}
}
+#ifdef CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
+static void fbcon_redraw_move(struct vc_data *vc, struct fbcon_display *p,
+ int line, int count, int dy)
+{
+ unsigned short *s = (unsigned short *)
+ (vc->vc_origin + vc->vc_size_row * line);
+
+ while (count--) {
+ unsigned short *start = s;
+ unsigned short *le = advance_row(s, 1);
+ unsigned short c;
+ int x = 0;
+ unsigned short attr = 1;
+
+ do {
+ c = scr_readw(s);
+ if (attr != (c & 0xff00)) {
+ attr = c & 0xff00;
+ if (s > start) {
+ fbcon_putcs(vc, start, s - start,
+ dy, x);
+ x += s - start;
+ start = s;
+ }
+ }
+ console_conditional_schedule();
+ s++;
+ } while (s < le);
+ if (s > start)
+ fbcon_putcs(vc, start, s - start, dy, x);
+ console_conditional_schedule();
+ dy++;
+ }
+}
+
+static __inline__ void ywrap_up(struct vc_data *vc, int count)
+{
+ struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fbcon_ops *ops = info->fbcon_par;
+ struct fbcon_display *p = &fb_display[vc->vc_num];
+
+ p->yscroll += count;
+ if (p->yscroll >= p->vrows) /* Deal with wrap */
+ p->yscroll -= p->vrows;
+ ops->var.xoffset = 0;
+ ops->var.yoffset = p->yscroll * vc->vc_font.height;
+ ops->var.vmode |= FB_VMODE_YWRAP;
+ ops->update_start(info);
+ scrollback_max += count;
+ if (scrollback_max > scrollback_phys_max)
+ scrollback_max = scrollback_phys_max;
+ scrollback_current = 0;
+}
+
+static __inline__ void ywrap_down(struct vc_data *vc, int count)
+{
+ struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fbcon_ops *ops = info->fbcon_par;
+ struct fbcon_display *p = &fb_display[vc->vc_num];
+
+ p->yscroll -= count;
+ if (p->yscroll < 0) /* Deal with wrap */
+ p->yscroll += p->vrows;
+ ops->var.xoffset = 0;
+ ops->var.yoffset = p->yscroll * vc->vc_font.height;
+ ops->var.vmode |= FB_VMODE_YWRAP;
+ ops->update_start(info);
+ scrollback_max -= count;
+ if (scrollback_max < 0)
+ scrollback_max = 0;
+ scrollback_current = 0;
+}
+
+static __inline__ void ypan_up(struct vc_data *vc, int count)
+{
+ struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fbcon_display *p = &fb_display[vc->vc_num];
+ struct fbcon_ops *ops = info->fbcon_par;
+
+ p->yscroll += count;
+ if (p->yscroll > p->vrows - vc->vc_rows) {
+ ops->bmove(vc, info, p->vrows - vc->vc_rows,
+ 0, 0, 0, vc->vc_rows, vc->vc_cols);
+ p->yscroll -= p->vrows - vc->vc_rows;
+ }
+
+ ops->var.xoffset = 0;
+ ops->var.yoffset = p->yscroll * vc->vc_font.height;
+ ops->var.vmode &= ~FB_VMODE_YWRAP;
+ ops->update_start(info);
+ fbcon_clear_margins(vc, 1);
+ scrollback_max += count;
+ if (scrollback_max > scrollback_phys_max)
+ scrollback_max = scrollback_phys_max;
+ scrollback_current = 0;
+}
+
+static __inline__ void ypan_up_redraw(struct vc_data *vc, int t, int count)
+{
+ struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fbcon_ops *ops = info->fbcon_par;
+ struct fbcon_display *p = &fb_display[vc->vc_num];
+
+ p->yscroll += count;
+
+ if (p->yscroll > p->vrows - vc->vc_rows) {
+ p->yscroll -= p->vrows - vc->vc_rows;
+ fbcon_redraw_move(vc, p, t + count, vc->vc_rows - count, t);
+ }
+
+ ops->var.xoffset = 0;
+ ops->var.yoffset = p->yscroll * vc->vc_font.height;
+ ops->var.vmode &= ~FB_VMODE_YWRAP;
+ ops->update_start(info);
+ fbcon_clear_margins(vc, 1);
+ scrollback_max += count;
+ if (scrollback_max > scrollback_phys_max)
+ scrollback_max = scrollback_phys_max;
+ scrollback_current = 0;
+}
+
+static __inline__ void ypan_down(struct vc_data *vc, int count)
+{
+ struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fbcon_display *p = &fb_display[vc->vc_num];
+ struct fbcon_ops *ops = info->fbcon_par;
+
+ p->yscroll -= count;
+ if (p->yscroll < 0) {
+ ops->bmove(vc, info, 0, 0, p->vrows - vc->vc_rows,
+ 0, vc->vc_rows, vc->vc_cols);
+ p->yscroll += p->vrows - vc->vc_rows;
+ }
+
+ ops->var.xoffset = 0;
+ ops->var.yoffset = p->yscroll * vc->vc_font.height;
+ ops->var.vmode &= ~FB_VMODE_YWRAP;
+ ops->update_start(info);
+ fbcon_clear_margins(vc, 1);
+ scrollback_max -= count;
+ if (scrollback_max < 0)
+ scrollback_max = 0;
+ scrollback_current = 0;
+}
+
+static __inline__ void ypan_down_redraw(struct vc_data *vc, int t, int count)
+{
+ struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fbcon_ops *ops = info->fbcon_par;
+ struct fbcon_display *p = &fb_display[vc->vc_num];
+
+ p->yscroll -= count;
+
+ if (p->yscroll < 0) {
+ p->yscroll += p->vrows - vc->vc_rows;
+ fbcon_redraw_move(vc, p, t, vc->vc_rows - count, t + count);
+ }
+
+ ops->var.xoffset = 0;
+ ops->var.yoffset = p->yscroll * vc->vc_font.height;
+ ops->var.vmode &= ~FB_VMODE_YWRAP;
+ ops->update_start(info);
+ fbcon_clear_margins(vc, 1);
+ scrollback_max -= count;
+ if (scrollback_max < 0)
+ scrollback_max = 0;
+ scrollback_current = 0;
+}
+
+static void fbcon_bmove_rec(struct vc_data *vc, struct fbcon_display *p, int sy, int sx,
+ int dy, int dx, int height, int width, u_int y_break)
+{
+ struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fbcon_ops *ops = info->fbcon_par;
+ u_int b;
+
+ if (sy < y_break && sy + height > y_break) {
+ b = y_break - sy;
+ if (dy < sy) { /* Avoid trashing self */
+ fbcon_bmove_rec(vc, p, sy, sx, dy, dx, b, width,
+ y_break);
+ fbcon_bmove_rec(vc, p, sy + b, sx, dy + b, dx,
+ height - b, width, y_break);
+ } else {
+ fbcon_bmove_rec(vc, p, sy + b, sx, dy + b, dx,
+ height - b, width, y_break);
+ fbcon_bmove_rec(vc, p, sy, sx, dy, dx, b, width,
+ y_break);
+ }
+ return;
+ }
+
+ if (dy < y_break && dy + height > y_break) {
+ b = y_break - dy;
+ if (dy < sy) { /* Avoid trashing self */
+ fbcon_bmove_rec(vc, p, sy, sx, dy, dx, b, width,
+ y_break);
+ fbcon_bmove_rec(vc, p, sy + b, sx, dy + b, dx,
+ height - b, width, y_break);
+ } else {
+ fbcon_bmove_rec(vc, p, sy + b, sx, dy + b, dx,
+ height - b, width, y_break);
+ fbcon_bmove_rec(vc, p, sy, sx, dy, dx, b, width,
+ y_break);
+ }
+ return;
+ }
+ ops->bmove(vc, info, real_y(p, sy), sx, real_y(p, dy), dx,
+ height, width);
+}
+
+static void fbcon_bmove(struct vc_data *vc, int sy, int sx, int dy, int dx,
+ int height, int width)
+{
+ struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fbcon_display *p = &fb_display[vc->vc_num];
+
+ if (fbcon_is_inactive(vc, info))
+ return;
+
+ if (!width || !height)
+ return;
+
+ /* Split blits that cross physical y_wrap case.
+ * Pathological case involves 4 blits, better to use recursive
+ * code rather than unrolled case
+ *
+ * Recursive invocations don't need to erase the cursor over and
+ * over again, so we use fbcon_bmove_rec()
+ */
+ fbcon_bmove_rec(vc, p, sy, sx, dy, dx, height, width,
+ p->vrows - p->yscroll);
+}
+
+static void fbcon_redraw_blit(struct vc_data *vc, struct fb_info *info,
+ struct fbcon_display *p, int line, int count, int ycount)
+{
+ int offset = ycount * vc->vc_cols;
+ unsigned short *d = (unsigned short *)
+ (vc->vc_origin + vc->vc_size_row * line);
+ unsigned short *s = d + offset;
+ struct fbcon_ops *ops = info->fbcon_par;
+
+ while (count--) {
+ unsigned short *start = s;
+ unsigned short *le = advance_row(s, 1);
+ unsigned short c;
+ int x = 0;
+
+ do {
+ c = scr_readw(s);
+
+ if (c == scr_readw(d)) {
+ if (s > start) {
+ ops->bmove(vc, info, line + ycount, x,
+ line, x, 1, s-start);
+ x += s - start + 1;
+ start = s + 1;
+ } else {
+ x++;
+ start++;
+ }
+ }
+
+ scr_writew(c, d);
+ console_conditional_schedule();
+ s++;
+ d++;
+ } while (s < le);
+ if (s > start)
+ ops->bmove(vc, info, line + ycount, x, line, x, 1,
+ s-start);
+ console_conditional_schedule();
+ if (ycount > 0)
+ line++;
+ else {
+ line--;
+ /* NOTE: We subtract two lines from these pointers */
+ s -= vc->vc_size_row;
+ d -= vc->vc_size_row;
+ }
+ }
+}
+#endif
+
static void fbcon_redraw(struct vc_data *vc, struct fbcon_display *p,
int line, int count, int offset)
{
@@ -1450,6 +1744,9 @@ static bool fbcon_scroll(struct vc_data *vc, unsigned int t, unsigned int b,
{
struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
struct fbcon_display *p = &fb_display[vc->vc_num];
+#ifdef CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
+ int scroll_partial = info->flags & FBINFO_PARTIAL_PAN_OK;
+#endif
if (fbcon_is_inactive(vc, info))
return true;
@@ -1466,6 +1763,7 @@ static bool fbcon_scroll(struct vc_data *vc, unsigned int t, unsigned int b,
case SM_UP:
if (count > vc->vc_rows) /* Maximum realistic size */
count = vc->vc_rows;
+#ifndef CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
fbcon_redraw(vc, p, t, b - t - count,
count * vc->vc_cols);
fbcon_clear(vc, b - count, 0, count, vc->vc_cols);
@@ -1475,10 +1773,99 @@ static bool fbcon_scroll(struct vc_data *vc, unsigned int t, unsigned int b,
vc->vc_video_erase_char,
vc->vc_size_row * count);
return true;
+#else
+ if (logo_shown >= 0)
+ goto redraw_up;
+ switch (p->scrollmode) {
+ case SCROLL_MOVE:
+ fbcon_redraw_blit(vc, info, p, t, b - t - count,
+ count);
+ fbcon_clear(vc, b - count, 0, count, vc->vc_cols);
+ scr_memsetw((unsigned short *) (vc->vc_origin +
+ vc->vc_size_row *
+ (b - count)),
+ vc->vc_video_erase_char,
+ vc->vc_size_row * count);
+ return true;
+
+ case SCROLL_WRAP_MOVE:
+ if (b - t - count > 3 * vc->vc_rows >> 2) {
+ if (t > 0)
+ fbcon_bmove(vc, 0, 0, count, 0, t,
+ vc->vc_cols);
+ ywrap_up(vc, count);
+ if (vc->vc_rows - b > 0)
+ fbcon_bmove(vc, b - count, 0, b, 0,
+ vc->vc_rows - b,
+ vc->vc_cols);
+ } else if (info->flags & FBINFO_READS_FAST)
+ fbcon_bmove(vc, t + count, 0, t, 0,
+ b - t - count, vc->vc_cols);
+ else
+ goto redraw_up;
+ fbcon_clear(vc, b - count, 0, count, vc->vc_cols);
+ break;
+
+ case SCROLL_PAN_REDRAW:
+ if ((p->yscroll + count <=
+ 2 * (p->vrows - vc->vc_rows))
+ && ((!scroll_partial && (b - t == vc->vc_rows))
+ || (scroll_partial
+ && (b - t - count >
+ 3 * vc->vc_rows >> 2)))) {
+ if (t > 0)
+ fbcon_redraw_move(vc, p, 0, t, count);
+ ypan_up_redraw(vc, t, count);
+ if (vc->vc_rows - b > 0)
+ fbcon_redraw_move(vc, p, b,
+ vc->vc_rows - b, b);
+ } else
+ fbcon_redraw_move(vc, p, t + count, b - t - count, t);
+ fbcon_clear(vc, b - count, 0, count, vc->vc_cols);
+ break;
+
+ case SCROLL_PAN_MOVE:
+ if ((p->yscroll + count <=
+ 2 * (p->vrows - vc->vc_rows))
+ && ((!scroll_partial && (b - t == vc->vc_rows))
+ || (scroll_partial
+ && (b - t - count >
+ 3 * vc->vc_rows >> 2)))) {
+ if (t > 0)
+ fbcon_bmove(vc, 0, 0, count, 0, t,
+ vc->vc_cols);
+ ypan_up(vc, count);
+ if (vc->vc_rows - b > 0)
+ fbcon_bmove(vc, b - count, 0, b, 0,
+ vc->vc_rows - b,
+ vc->vc_cols);
+ } else if (info->flags & FBINFO_READS_FAST)
+ fbcon_bmove(vc, t + count, 0, t, 0,
+ b - t - count, vc->vc_cols);
+ else
+ goto redraw_up;
+ fbcon_clear(vc, b - count, 0, count, vc->vc_cols);
+ break;
+
+ case SCROLL_REDRAW:
+ redraw_up:
+ fbcon_redraw(vc, p, t, b - t - count,
+ count * vc->vc_cols);
+ fbcon_clear(vc, b - count, 0, count, vc->vc_cols);
+ scr_memsetw((unsigned short *) (vc->vc_origin +
+ vc->vc_size_row *
+ (b - count)),
+ vc->vc_video_erase_char,
+ vc->vc_size_row * count);
+ return true;
+ }
+ break;
+#endif
case SM_DOWN:
if (count > vc->vc_rows) /* Maximum realistic size */
count = vc->vc_rows;
+#ifndef CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
fbcon_redraw(vc, p, b - 1, b - t - count,
-count * vc->vc_cols);
fbcon_clear(vc, t, 0, count, vc->vc_cols);
@@ -1488,10 +1875,96 @@ static bool fbcon_scroll(struct vc_data *vc, unsigned int t, unsigned int b,
vc->vc_video_erase_char,
vc->vc_size_row * count);
return true;
+#else
+ if (logo_shown >= 0)
+ goto redraw_down;
+ switch (p->scrollmode) {
+ case SCROLL_MOVE:
+ fbcon_redraw_blit(vc, info, p, b - 1, b - t - count,
+ -count);
+ fbcon_clear(vc, t, 0, count, vc->vc_cols);
+ scr_memsetw((unsigned short *) (vc->vc_origin +
+ vc->vc_size_row *
+ t),
+ vc->vc_video_erase_char,
+ vc->vc_size_row * count);
+ return true;
+
+ case SCROLL_WRAP_MOVE:
+ if (b - t - count > 3 * vc->vc_rows >> 2) {
+ if (vc->vc_rows - b > 0)
+ fbcon_bmove(vc, b, 0, b - count, 0,
+ vc->vc_rows - b,
+ vc->vc_cols);
+ ywrap_down(vc, count);
+ if (t > 0)
+ fbcon_bmove(vc, count, 0, 0, 0, t,
+ vc->vc_cols);
+ } else if (info->flags & FBINFO_READS_FAST)
+ fbcon_bmove(vc, t, 0, t + count, 0,
+ b - t - count, vc->vc_cols);
+ else
+ goto redraw_down;
+ fbcon_clear(vc, t, 0, count, vc->vc_cols);
+ break;
+
+ case SCROLL_PAN_MOVE:
+ if ((count - p->yscroll <= p->vrows - vc->vc_rows)
+ && ((!scroll_partial && (b - t == vc->vc_rows))
+ || (scroll_partial
+ && (b - t - count >
+ 3 * vc->vc_rows >> 2)))) {
+ if (vc->vc_rows - b > 0)
+ fbcon_bmove(vc, b, 0, b - count, 0,
+ vc->vc_rows - b,
+ vc->vc_cols);
+ ypan_down(vc, count);
+ if (t > 0)
+ fbcon_bmove(vc, count, 0, 0, 0, t,
+ vc->vc_cols);
+ } else if (info->flags & FBINFO_READS_FAST)
+ fbcon_bmove(vc, t, 0, t + count, 0,
+ b - t - count, vc->vc_cols);
+ else
+ goto redraw_down;
+ fbcon_clear(vc, t, 0, count, vc->vc_cols);
+ break;
+
+ case SCROLL_PAN_REDRAW:
+ if ((count - p->yscroll <= p->vrows - vc->vc_rows)
+ && ((!scroll_partial && (b - t == vc->vc_rows))
+ || (scroll_partial
+ && (b - t - count >
+ 3 * vc->vc_rows >> 2)))) {
+ if (vc->vc_rows - b > 0)
+ fbcon_redraw_move(vc, p, b, vc->vc_rows - b,
+ b - count);
+ ypan_down_redraw(vc, t, count);
+ if (t > 0)
+ fbcon_redraw_move(vc, p, count, t, 0);
+ } else
+ fbcon_redraw_move(vc, p, t, b - t - count, t + count);
+ fbcon_clear(vc, t, 0, count, vc->vc_cols);
+ break;
+
+ case SCROLL_REDRAW:
+ redraw_down:
+ fbcon_redraw(vc, p, b - 1, b - t - count,
+ -count * vc->vc_cols);
+ fbcon_clear(vc, t, 0, count, vc->vc_cols);
+ scr_memsetw((unsigned short *) (vc->vc_origin +
+ vc->vc_size_row *
+ t),
+ vc->vc_video_erase_char,
+ vc->vc_size_row * count);
+ return true;
+ }
+#endif
}
return false;
}
+
static void updatescrollmode(struct fbcon_display *p,
struct fb_info *info,
struct vc_data *vc)
@@ -1664,7 +2137,21 @@ static int fbcon_switch(struct vc_data *vc)
updatescrollmode(p, info, vc);
- scrollback_phys_max = 0;
+ switch (p->scrollmode) {
+ case SCROLL_WRAP_MOVE:
+ scrollback_phys_max = p->vrows - vc->vc_rows;
+ break;
+ case SCROLL_PAN_MOVE:
+ case SCROLL_PAN_REDRAW:
+ scrollback_phys_max = p->vrows - 2 * vc->vc_rows;
+ if (scrollback_phys_max < 0)
+ scrollback_phys_max = 0;
+ break;
+ default:
+ scrollback_phys_max = 0;
+ break;
+ }
+
scrollback_max = 0;
scrollback_current = 0;
diff --git a/drivers/video/fbdev/core/fbcon.h b/drivers/video/fbdev/core/fbcon.h
index a00603b4451a..5246d0f2574b 100644
--- a/drivers/video/fbdev/core/fbcon.h
+++ b/drivers/video/fbdev/core/fbcon.h
@@ -29,6 +29,7 @@ struct fbcon_display {
/* Filled in by the low-level console driver */
const u_char *fontdata;
int userfont; /* != 0 if fontdata kmalloc()ed */
+ u_short scrollmode; /* Scroll Method */
u_short inverse; /* != 0 text black on white as default */
short yscroll; /* Hardware scrolling */
int vrows; /* number of virtual rows */
@@ -51,6 +52,8 @@ struct fbcon_display {
};
struct fbcon_ops {
+ void (*bmove)(struct vc_data *vc, struct fb_info *info, int sy,
+ int sx, int dy, int dx, int height, int width);
void (*clear)(struct vc_data *vc, struct fb_info *info, int sy,
int sx, int height, int width);
void (*putcs)(struct vc_data *vc, struct fb_info *info,
@@ -149,6 +152,62 @@ static inline int attr_col_ec(int shift, struct vc_data *vc,
#define attr_bgcol_ec(bgshift, vc, info) attr_col_ec(bgshift, vc, info, 0)
#define attr_fgcol_ec(fgshift, vc, info) attr_col_ec(fgshift, vc, info, 1)
+ /*
+ * Scroll Method
+ */
+
+/* There are several methods fbcon can use to move text around the screen:
+ *
+ * Operation Pan Wrap
+ *---------------------------------------------
+ * SCROLL_MOVE copyarea No No
+ * SCROLL_PAN_MOVE copyarea Yes No
+ * SCROLL_WRAP_MOVE copyarea No Yes
+ * SCROLL_REDRAW imageblit No No
+ * SCROLL_PAN_REDRAW imageblit Yes No
+ * SCROLL_WRAP_REDRAW imageblit No Yes
+ *
+ * (SCROLL_WRAP_REDRAW is not implemented yet)
+ *
+ * In general, fbcon will choose the best scrolling
+ * method based on the rule below:
+ *
+ * Pan/Wrap > accel imageblit > accel copyarea >
+ * soft imageblit > (soft copyarea)
+ *
+ * Exception to the rule: Pan + accel copyarea is
+ * preferred over Pan + accel imageblit.
+ *
+ * The above is typical for PCI/AGP cards. Unless
+ * overridden, fbcon will never use soft copyarea.
+ *
+ * If you need to override the above rule, set the
+ * appropriate flags in fb_info->flags. For example,
+ * to prefer copyarea over imageblit, set
+ * FBINFO_READS_FAST.
+ *
+ * Other notes:
+ * + use the hardware engine to move the text
+ * (hw-accelerated copyarea() and fillrect())
+ * + use hardware-supported panning on a large virtual screen
+ * + amifb can not only pan, but also wrap the display by N lines
+ * (i.e. visible line i = physical line (i+N) % yres).
+ * + read what's already rendered on the screen and
+ * write it in a different place (this is cfb_copyarea())
+ * + re-render the text to the screen
+ *
+ * Whether to use wrapping or panning can only be figured out at
+ * runtime (when we know whether our font height is a multiple
+ * of the pan/wrap step)
+ *
+ */
+
+#define SCROLL_MOVE 0x001
+#define SCROLL_PAN_MOVE 0x002
+#define SCROLL_WRAP_MOVE 0x003
+#define SCROLL_REDRAW 0x004
+#define SCROLL_PAN_REDRAW 0x005
+
#ifdef CONFIG_FB_TILEBLITTING
extern void fbcon_set_tileops(struct vc_data *vc, struct fb_info *info);
#endif
diff --git a/drivers/video/fbdev/core/fbcon_ccw.c b/drivers/video/fbdev/core/fbcon_ccw.c
index ffa78936eaab..9cd2c4b05c32 100644
--- a/drivers/video/fbdev/core/fbcon_ccw.c
+++ b/drivers/video/fbdev/core/fbcon_ccw.c
@@ -59,12 +59,31 @@ static void ccw_update_attr(u8 *dst, u8 *src, int attribute,
}
}
+
+static void ccw_bmove(struct vc_data *vc, struct fb_info *info, int sy,
+ int sx, int dy, int dx, int height, int width)
+{
+ struct fbcon_ops *ops = info->fbcon_par;
+ struct fb_copyarea area;
+ u32 vyres = GETVYRES(ops->p->scrollmode, info);
+
+ area.sx = sy * vc->vc_font.height;
+ area.sy = vyres - ((sx + width) * vc->vc_font.width);
+ area.dx = dy * vc->vc_font.height;
+ area.dy = vyres - ((dx + width) * vc->vc_font.width);
+ area.width = height * vc->vc_font.height;
+ area.height = width * vc->vc_font.width;
+
+ info->fbops->fb_copyarea(info, &area);
+}
+
static void ccw_clear(struct vc_data *vc, struct fb_info *info, int sy,
int sx, int height, int width)
{
+ struct fbcon_ops *ops = info->fbcon_par;
struct fb_fillrect region;
int bgshift = (vc->vc_hi_font_mask) ? 13 : 12;
- u32 vyres = info->var.yres;
+ u32 vyres = GETVYRES(ops->p->scrollmode, info);
region.color = attr_bgcol_ec(bgshift,vc,info);
region.dx = sy * vc->vc_font.height;
@@ -121,7 +140,7 @@ static void ccw_putcs(struct vc_data *vc, struct fb_info *info,
u32 cnt, pitch, size;
u32 attribute = get_attribute(info, scr_readw(s));
u8 *dst, *buf = NULL;
- u32 vyres = info->var.yres;
+ u32 vyres = GETVYRES(ops->p->scrollmode, info);
if (!ops->fontbuffer)
return;
@@ -210,7 +229,7 @@ static void ccw_cursor(struct vc_data *vc, struct fb_info *info, int mode,
int attribute, use_sw = vc->vc_cursor_type & CUR_SW;
int err = 1, dx, dy;
char *src;
- u32 vyres = info->var.yres;
+ u32 vyres = GETVYRES(ops->p->scrollmode, info);
if (!ops->fontbuffer)
return;
@@ -368,7 +387,7 @@ static int ccw_update_start(struct fb_info *info)
{
struct fbcon_ops *ops = info->fbcon_par;
u32 yoffset;
- u32 vyres = info->var.yres;
+ u32 vyres = GETVYRES(ops->p->scrollmode, info);
int err;
yoffset = (vyres - info->var.yres) - ops->var.xoffset;
@@ -383,6 +402,7 @@ static int ccw_update_start(struct fb_info *info)
void fbcon_rotate_ccw(struct fbcon_ops *ops)
{
+ ops->bmove = ccw_bmove;
ops->clear = ccw_clear;
ops->putcs = ccw_putcs;
ops->clear_margins = ccw_clear_margins;
diff --git a/drivers/video/fbdev/core/fbcon_cw.c b/drivers/video/fbdev/core/fbcon_cw.c
index 92e5b7fb51ee..88d89fad3f05 100644
--- a/drivers/video/fbdev/core/fbcon_cw.c
+++ b/drivers/video/fbdev/core/fbcon_cw.c
@@ -44,12 +44,31 @@ static void cw_update_attr(u8 *dst, u8 *src, int attribute,
}
}
+
+static void cw_bmove(struct vc_data *vc, struct fb_info *info, int sy,
+ int sx, int dy, int dx, int height, int width)
+{
+ struct fbcon_ops *ops = info->fbcon_par;
+ struct fb_copyarea area;
+ u32 vxres = GETVXRES(ops->p->scrollmode, info);
+
+ area.sx = vxres - ((sy + height) * vc->vc_font.height);
+ area.sy = sx * vc->vc_font.width;
+ area.dx = vxres - ((dy + height) * vc->vc_font.height);
+ area.dy = dx * vc->vc_font.width;
+ area.width = height * vc->vc_font.height;
+ area.height = width * vc->vc_font.width;
+
+ info->fbops->fb_copyarea(info, &area);
+}
+
static void cw_clear(struct vc_data *vc, struct fb_info *info, int sy,
int sx, int height, int width)
{
+ struct fbcon_ops *ops = info->fbcon_par;
struct fb_fillrect region;
int bgshift = (vc->vc_hi_font_mask) ? 13 : 12;
- u32 vxres = info->var.xres;
+ u32 vxres = GETVXRES(ops->p->scrollmode, info);
region.color = attr_bgcol_ec(bgshift,vc,info);
region.dx = vxres - ((sy + height) * vc->vc_font.height);
@@ -106,7 +125,7 @@ static void cw_putcs(struct vc_data *vc, struct fb_info *info,
u32 cnt, pitch, size;
u32 attribute = get_attribute(info, scr_readw(s));
u8 *dst, *buf = NULL;
- u32 vxres = info->var.xres;
+ u32 vxres = GETVXRES(ops->p->scrollmode, info);
if (!ops->fontbuffer)
return;
@@ -193,7 +212,7 @@ static void cw_cursor(struct vc_data *vc, struct fb_info *info, int mode,
int attribute, use_sw = vc->vc_cursor_type & CUR_SW;
int err = 1, dx, dy;
char *src;
- u32 vxres = info->var.xres;
+ u32 vxres = GETVXRES(ops->p->scrollmode, info);
if (!ops->fontbuffer)
return;
@@ -350,7 +369,7 @@ static void cw_cursor(struct vc_data *vc, struct fb_info *info, int mode,
static int cw_update_start(struct fb_info *info)
{
struct fbcon_ops *ops = info->fbcon_par;
- u32 vxres = info->var.xres;
+ u32 vxres = GETVXRES(ops->p->scrollmode, info);
u32 xoffset;
int err;
@@ -366,6 +385,7 @@ static int cw_update_start(struct fb_info *info)
void fbcon_rotate_cw(struct fbcon_ops *ops)
{
+ ops->bmove = cw_bmove;
ops->clear = cw_clear;
ops->putcs = cw_putcs;
ops->clear_margins = cw_clear_margins;
diff --git a/drivers/video/fbdev/core/fbcon_rotate.h b/drivers/video/fbdev/core/fbcon_rotate.h
index b528b2e54283..21cb81615883 100644
--- a/drivers/video/fbdev/core/fbcon_rotate.h
+++ b/drivers/video/fbdev/core/fbcon_rotate.h
@@ -11,6 +11,27 @@
#ifndef _FBCON_ROTATE_H
#define _FBCON_ROTATE_H
+#ifdef CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
+#define GETVYRES(s,i) ({ \
+ (s == SCROLL_REDRAW || s == SCROLL_MOVE) ? \
+ (i)->var.yres : (i)->var.yres_virtual; })
+
+#define GETVXRES(s,i) ({ \
+ (s == SCROLL_REDRAW || s == SCROLL_MOVE || !(i)->fix.xpanstep) ? \
+ (i)->var.xres : (i)->var.xres_virtual; })
+#else
+static inline u32 GETVYRES(int s, struct fb_info *i)
+{
+ return i->var.yres;
+}
+
+static inline u32 GETVXRES(int s, struct fb_info *i)
+{
+ return i->var.xres;
+}
+#endif
+
+
static inline int pattern_test_bit(u32 x, u32 y, u32 pitch, const char *pat)
{
u32 tmp = (y * pitch) + x, index = tmp / 8, bit = tmp % 8;
diff --git a/drivers/video/fbdev/core/fbcon_ud.c b/drivers/video/fbdev/core/fbcon_ud.c
index 09619bd8e021..8d5e66b1bdfb 100644
--- a/drivers/video/fbdev/core/fbcon_ud.c
+++ b/drivers/video/fbdev/core/fbcon_ud.c
@@ -44,13 +44,33 @@ static void ud_update_attr(u8 *dst, u8 *src, int attribute,
}
}
+
+static void ud_bmove(struct vc_data *vc, struct fb_info *info, int sy,
+ int sx, int dy, int dx, int height, int width)
+{
+ struct fbcon_ops *ops = info->fbcon_par;
+ struct fb_copyarea area;
+ u32 vyres = GETVYRES(ops->p->scrollmode, info);
+ u32 vxres = GETVXRES(ops->p->scrollmode, info);
+
+ area.sy = vyres - ((sy + height) * vc->vc_font.height);
+ area.sx = vxres - ((sx + width) * vc->vc_font.width);
+ area.dy = vyres - ((dy + height) * vc->vc_font.height);
+ area.dx = vxres - ((dx + width) * vc->vc_font.width);
+ area.height = height * vc->vc_font.height;
+ area.width = width * vc->vc_font.width;
+
+ info->fbops->fb_copyarea(info, &area);
+}
+
static void ud_clear(struct vc_data *vc, struct fb_info *info, int sy,
int sx, int height, int width)
{
+ struct fbcon_ops *ops = info->fbcon_par;
struct fb_fillrect region;
int bgshift = (vc->vc_hi_font_mask) ? 13 : 12;
- u32 vyres = info->var.yres;
- u32 vxres = info->var.xres;
+ u32 vyres = GETVYRES(ops->p->scrollmode, info);
+ u32 vxres = GETVXRES(ops->p->scrollmode, info);
region.color = attr_bgcol_ec(bgshift,vc,info);
region.dy = vyres - ((sy + height) * vc->vc_font.height);
@@ -142,8 +162,8 @@ static void ud_putcs(struct vc_data *vc, struct fb_info *info,
u32 mod = vc->vc_font.width % 8, cnt, pitch, size;
u32 attribute = get_attribute(info, scr_readw(s));
u8 *dst, *buf = NULL;
- u32 vyres = info->var.yres;
- u32 vxres = info->var.xres;
+ u32 vyres = GETVYRES(ops->p->scrollmode, info);
+ u32 vxres = GETVXRES(ops->p->scrollmode, info);
if (!ops->fontbuffer)
return;
@@ -239,8 +259,8 @@ static void ud_cursor(struct vc_data *vc, struct fb_info *info, int mode,
int attribute, use_sw = vc->vc_cursor_type & CUR_SW;
int err = 1, dx, dy;
char *src;
- u32 vyres = info->var.yres;
- u32 vxres = info->var.xres;
+ u32 vyres = GETVYRES(ops->p->scrollmode, info);
+ u32 vxres = GETVXRES(ops->p->scrollmode, info);
if (!ops->fontbuffer)
return;
@@ -390,8 +410,8 @@ static int ud_update_start(struct fb_info *info)
{
struct fbcon_ops *ops = info->fbcon_par;
int xoffset, yoffset;
- u32 vyres = info->var.yres;
- u32 vxres = info->var.xres;
+ u32 vyres = GETVYRES(ops->p->scrollmode, info);
+ u32 vxres = GETVXRES(ops->p->scrollmode, info);
int err;
xoffset = vxres - info->var.xres - ops->var.xoffset;
@@ -409,6 +429,7 @@ static int ud_update_start(struct fb_info *info)
void fbcon_rotate_ud(struct fbcon_ops *ops)
{
+ ops->bmove = ud_bmove;
ops->clear = ud_clear;
ops->putcs = ud_putcs;
ops->clear_margins = ud_clear_margins;
diff --git a/drivers/video/fbdev/core/tileblit.c b/drivers/video/fbdev/core/tileblit.c
index 72af95053bcb..2768eff247ba 100644
--- a/drivers/video/fbdev/core/tileblit.c
+++ b/drivers/video/fbdev/core/tileblit.c
@@ -16,6 +16,21 @@
#include <asm/types.h>
#include "fbcon.h"
+static void tile_bmove(struct vc_data *vc, struct fb_info *info, int sy,
+ int sx, int dy, int dx, int height, int width)
+{
+ struct fb_tilearea area;
+
+ area.sx = sx;
+ area.sy = sy;
+ area.dx = dx;
+ area.dy = dy;
+ area.height = height;
+ area.width = width;
+
+ info->tileops->fb_tilecopy(info, &area);
+}
+
static void tile_clear(struct vc_data *vc, struct fb_info *info, int sy,
int sx, int height, int width)
{
@@ -118,6 +133,7 @@ void fbcon_set_tileops(struct vc_data *vc, struct fb_info *info)
struct fb_tilemap map;
struct fbcon_ops *ops = info->fbcon_par;
+ ops->bmove = tile_bmove;
ops->clear = tile_clear;
ops->putcs = tile_putcs;
ops->clear_margins = tile_clear_margins;
diff --git a/drivers/video/fbdev/skeletonfb.c b/drivers/video/fbdev/skeletonfb.c
index 0fe922f726e9..bcacfb6934fa 100644
--- a/drivers/video/fbdev/skeletonfb.c
+++ b/drivers/video/fbdev/skeletonfb.c
@@ -505,15 +505,15 @@ void xxxfb_fillrect(struct fb_info *p, const struct fb_fillrect *region)
}
/**
- * xxxfb_copyarea - OBSOLETE function.
+ * xxxfb_copyarea - REQUIRED function. Can use generic routines if
+ * non acclerated hardware and packed pixel based.
* Copies one area of the screen to another area.
- * Will be deleted in a future version
*
* @info: frame buffer structure that represents a single frame buffer
* @area: Structure providing the data to copy the framebuffer contents
* from one region to another.
*
- * This drawing operation copied a rectangular area from one area of the
+ * This drawing operation copies a rectangular area from one area of the
* screen to another area.
*/
void xxxfb_copyarea(struct fb_info *p, const struct fb_copyarea *area)
@@ -645,9 +645,9 @@ static const struct fb_ops xxxfb_ops = {
.fb_setcolreg = xxxfb_setcolreg,
.fb_blank = xxxfb_blank,
.fb_pan_display = xxxfb_pan_display,
- .fb_fillrect = xxxfb_fillrect, /* Needed !!! */
- .fb_copyarea = xxxfb_copyarea, /* Obsolete */
- .fb_imageblit = xxxfb_imageblit, /* Needed !!! */
+ .fb_fillrect = xxxfb_fillrect, /* Needed !!! */
+ .fb_copyarea = xxxfb_copyarea, /* Needed !!! */
+ .fb_imageblit = xxxfb_imageblit, /* Needed !!! */
.fb_cursor = xxxfb_cursor, /* Optional !!! */
.fb_sync = xxxfb_sync,
.fb_ioctl = xxxfb_ioctl,
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 3da95842b207..02f362c661c8 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -262,7 +262,7 @@ struct fb_ops {
/* Draws a rectangle */
void (*fb_fillrect) (struct fb_info *info, const struct fb_fillrect *rect);
- /* Copy data from area to another. Obsolete. */
+ /* Copy data from area to another */
void (*fb_copyarea) (struct fb_info *info, const struct fb_copyarea *region);
/* Draws a image to the display */
void (*fb_imageblit) (struct fb_info *info, const struct fb_image *image);
--
2.33.0
^ permalink raw reply related [flat|nested] 241+ messages in thread
* [PATCH 03/21] fbcon: Restore fbcon scrolling acceleration
2022-01-31 21:05 ` Daniel Vetter
(?)
@ 2022-01-31 21:05 ` Daniel Vetter
-1 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-01-31 21:05 UTC (permalink / raw)
To: DRI Development
Cc: Intel Graphics Development, linux-fbdev, LKML, Daniel Vetter,
Helge Deller, stable, Claudio Suarez, Dave Airlie, Jani Nikula,
Linus Torvalds, Pavel Machek, Sam Ravnborg, Greg Kroah-Hartman,
Javier Martinez Canillas, Tomi Valkeinen, Geert Uytterhoeven,
Thomas Zimmermann, Daniel Vetter, Sven Schnelle, Gerd Hoffmann
This functionally undoes 39aead8373b3 ("fbcon: Disable accelerated
scrolling"), but behind the FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
option.
References: https://lore.kernel.org/dri-devel/feea8303-2b83-fc36-972c-4fc8ad723bde@gmx.de/
Fixes: 39aead8373b3 ("fbcon: Disable accelerated scrolling")
Cc: Helge Deller <deller@gmx.de>
Cc: <stable@vger.kernel.org> # v5.11+
Cc: Claudio Suarez <cssk@net-c.es>
Cc: Dave Airlie <airlied@gmail.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Linux Fbdev development list <linux-fbdev@vger.kernel.org>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Javier Martinez Canillas <javierm@redhat.com>
Cc: DRI Development <dri-devel@lists.freedesktop.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Cc: Claudio Suarez <cssk@net-c.es>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Sven Schnelle <svens@stackframe.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
drivers/video/fbdev/core/fbcon.c | 48 ++++++++++++++++++++++++++++----
1 file changed, 42 insertions(+), 6 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 2ff90061c7f3..39dc18a5de86 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -1125,13 +1125,15 @@ static void fbcon_init(struct vc_data *vc, int init)
ops->graphics = 0;
- /*
- * No more hw acceleration for fbcon.
- *
- * FIXME: Garbage collect all the now dead code after sufficient time
- * has passed.
- */
+#ifdef CONFIG_FRAMEBUFFER_CONSOLE_ROTATION
+ if ((info->flags & FBINFO_HWACCEL_COPYAREA) &&
+ !(info->flags & FBINFO_HWACCEL_DISABLED))
+ p->scrollmode = SCROLL_MOVE;
+ else /* default to something safe */
+ p->scrollmode = SCROLL_REDRAW;
+#else
p->scrollmode = SCROLL_REDRAW;
+#endif
/*
* ++guenther: console.c:vc_allocate() relies on initializing
@@ -1971,15 +1973,49 @@ static void updatescrollmode(struct fbcon_display *p,
{
struct fbcon_ops *ops = info->fbcon_par;
int fh = vc->vc_font.height;
+ int cap = info->flags;
+ u16 t = 0;
+ int ypan = FBCON_SWAP(ops->rotate, info->fix.ypanstep,
+ info->fix.xpanstep);
+ int ywrap = FBCON_SWAP(ops->rotate, info->fix.ywrapstep, t);
int yres = FBCON_SWAP(ops->rotate, info->var.yres, info->var.xres);
int vyres = FBCON_SWAP(ops->rotate, info->var.yres_virtual,
info->var.xres_virtual);
+ int good_pan = (cap & FBINFO_HWACCEL_YPAN) &&
+ divides(ypan, vc->vc_font.height) && vyres > yres;
+ int good_wrap = (cap & FBINFO_HWACCEL_YWRAP) &&
+ divides(ywrap, vc->vc_font.height) &&
+ divides(vc->vc_font.height, vyres) &&
+ divides(vc->vc_font.height, yres);
+ int reading_fast = cap & FBINFO_READS_FAST;
+ int fast_copyarea = (cap & FBINFO_HWACCEL_COPYAREA) &&
+ !(cap & FBINFO_HWACCEL_DISABLED);
+ int fast_imageblit = (cap & FBINFO_HWACCEL_IMAGEBLIT) &&
+ !(cap & FBINFO_HWACCEL_DISABLED);
p->vrows = vyres/fh;
if (yres > (fh * (vc->vc_rows + 1)))
p->vrows -= (yres - (fh * vc->vc_rows)) / fh;
if ((yres % fh) && (vyres % fh < yres % fh))
p->vrows--;
+
+ if (good_wrap || good_pan) {
+ if (reading_fast || fast_copyarea)
+ p->scrollmode = good_wrap ?
+ SCROLL_WRAP_MOVE : SCROLL_PAN_MOVE;
+ else
+ p->scrollmode = good_wrap ? SCROLL_REDRAW :
+ SCROLL_PAN_REDRAW;
+ } else {
+ if (reading_fast || (fast_copyarea && !fast_imageblit))
+ p->scrollmode = SCROLL_MOVE;
+ else
+ p->scrollmode = SCROLL_REDRAW;
+ }
+
+#ifndef CONFIG_FRAMEBUFFER_CONSOLE_ROTATION
+ p->scrollmode = SCROLL_REDRAW;
+#endif
}
#define PITCH(w) (((w) + 7) >> 3)
--
2.33.0
^ permalink raw reply related [flat|nested] 241+ messages in thread
* [PATCH 03/21] fbcon: Restore fbcon scrolling acceleration
@ 2022-01-31 21:05 ` Daniel Vetter
0 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-01-31 21:05 UTC (permalink / raw)
To: DRI Development
Cc: Sven Schnelle, linux-fbdev, Thomas Zimmermann, Sam Ravnborg,
Daniel Vetter, Daniel Vetter, Intel Graphics Development, LKML,
stable, Javier Martinez Canillas, Linus Torvalds, Tomi Valkeinen,
Claudio Suarez, Pavel Machek, Greg Kroah-Hartman,
Geert Uytterhoeven, Helge Deller, Gerd Hoffmann
This functionally undoes 39aead8373b3 ("fbcon: Disable accelerated
scrolling"), but behind the FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
option.
References: https://lore.kernel.org/dri-devel/feea8303-2b83-fc36-972c-4fc8ad723bde@gmx.de/
Fixes: 39aead8373b3 ("fbcon: Disable accelerated scrolling")
Cc: Helge Deller <deller@gmx.de>
Cc: <stable@vger.kernel.org> # v5.11+
Cc: Claudio Suarez <cssk@net-c.es>
Cc: Dave Airlie <airlied@gmail.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Linux Fbdev development list <linux-fbdev@vger.kernel.org>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Javier Martinez Canillas <javierm@redhat.com>
Cc: DRI Development <dri-devel@lists.freedesktop.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Cc: Claudio Suarez <cssk@net-c.es>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Sven Schnelle <svens@stackframe.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
drivers/video/fbdev/core/fbcon.c | 48 ++++++++++++++++++++++++++++----
1 file changed, 42 insertions(+), 6 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 2ff90061c7f3..39dc18a5de86 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -1125,13 +1125,15 @@ static void fbcon_init(struct vc_data *vc, int init)
ops->graphics = 0;
- /*
- * No more hw acceleration for fbcon.
- *
- * FIXME: Garbage collect all the now dead code after sufficient time
- * has passed.
- */
+#ifdef CONFIG_FRAMEBUFFER_CONSOLE_ROTATION
+ if ((info->flags & FBINFO_HWACCEL_COPYAREA) &&
+ !(info->flags & FBINFO_HWACCEL_DISABLED))
+ p->scrollmode = SCROLL_MOVE;
+ else /* default to something safe */
+ p->scrollmode = SCROLL_REDRAW;
+#else
p->scrollmode = SCROLL_REDRAW;
+#endif
/*
* ++guenther: console.c:vc_allocate() relies on initializing
@@ -1971,15 +1973,49 @@ static void updatescrollmode(struct fbcon_display *p,
{
struct fbcon_ops *ops = info->fbcon_par;
int fh = vc->vc_font.height;
+ int cap = info->flags;
+ u16 t = 0;
+ int ypan = FBCON_SWAP(ops->rotate, info->fix.ypanstep,
+ info->fix.xpanstep);
+ int ywrap = FBCON_SWAP(ops->rotate, info->fix.ywrapstep, t);
int yres = FBCON_SWAP(ops->rotate, info->var.yres, info->var.xres);
int vyres = FBCON_SWAP(ops->rotate, info->var.yres_virtual,
info->var.xres_virtual);
+ int good_pan = (cap & FBINFO_HWACCEL_YPAN) &&
+ divides(ypan, vc->vc_font.height) && vyres > yres;
+ int good_wrap = (cap & FBINFO_HWACCEL_YWRAP) &&
+ divides(ywrap, vc->vc_font.height) &&
+ divides(vc->vc_font.height, vyres) &&
+ divides(vc->vc_font.height, yres);
+ int reading_fast = cap & FBINFO_READS_FAST;
+ int fast_copyarea = (cap & FBINFO_HWACCEL_COPYAREA) &&
+ !(cap & FBINFO_HWACCEL_DISABLED);
+ int fast_imageblit = (cap & FBINFO_HWACCEL_IMAGEBLIT) &&
+ !(cap & FBINFO_HWACCEL_DISABLED);
p->vrows = vyres/fh;
if (yres > (fh * (vc->vc_rows + 1)))
p->vrows -= (yres - (fh * vc->vc_rows)) / fh;
if ((yres % fh) && (vyres % fh < yres % fh))
p->vrows--;
+
+ if (good_wrap || good_pan) {
+ if (reading_fast || fast_copyarea)
+ p->scrollmode = good_wrap ?
+ SCROLL_WRAP_MOVE : SCROLL_PAN_MOVE;
+ else
+ p->scrollmode = good_wrap ? SCROLL_REDRAW :
+ SCROLL_PAN_REDRAW;
+ } else {
+ if (reading_fast || (fast_copyarea && !fast_imageblit))
+ p->scrollmode = SCROLL_MOVE;
+ else
+ p->scrollmode = SCROLL_REDRAW;
+ }
+
+#ifndef CONFIG_FRAMEBUFFER_CONSOLE_ROTATION
+ p->scrollmode = SCROLL_REDRAW;
+#endif
}
#define PITCH(w) (((w) + 7) >> 3)
--
2.33.0
^ permalink raw reply related [flat|nested] 241+ messages in thread
* [Intel-gfx] [PATCH 03/21] fbcon: Restore fbcon scrolling acceleration
@ 2022-01-31 21:05 ` Daniel Vetter
0 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-01-31 21:05 UTC (permalink / raw)
To: DRI Development
Cc: Sven Schnelle, linux-fbdev, Thomas Zimmermann, Sam Ravnborg,
Daniel Vetter, Daniel Vetter, Intel Graphics Development, LKML,
stable, Javier Martinez Canillas, Linus Torvalds, Tomi Valkeinen,
Pavel Machek, Greg Kroah-Hartman, Geert Uytterhoeven,
Dave Airlie, Helge Deller, Gerd Hoffmann
This functionally undoes 39aead8373b3 ("fbcon: Disable accelerated
scrolling"), but behind the FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
option.
References: https://lore.kernel.org/dri-devel/feea8303-2b83-fc36-972c-4fc8ad723bde@gmx.de/
Fixes: 39aead8373b3 ("fbcon: Disable accelerated scrolling")
Cc: Helge Deller <deller@gmx.de>
Cc: <stable@vger.kernel.org> # v5.11+
Cc: Claudio Suarez <cssk@net-c.es>
Cc: Dave Airlie <airlied@gmail.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Linux Fbdev development list <linux-fbdev@vger.kernel.org>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Javier Martinez Canillas <javierm@redhat.com>
Cc: DRI Development <dri-devel@lists.freedesktop.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Cc: Claudio Suarez <cssk@net-c.es>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Sven Schnelle <svens@stackframe.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
drivers/video/fbdev/core/fbcon.c | 48 ++++++++++++++++++++++++++++----
1 file changed, 42 insertions(+), 6 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 2ff90061c7f3..39dc18a5de86 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -1125,13 +1125,15 @@ static void fbcon_init(struct vc_data *vc, int init)
ops->graphics = 0;
- /*
- * No more hw acceleration for fbcon.
- *
- * FIXME: Garbage collect all the now dead code after sufficient time
- * has passed.
- */
+#ifdef CONFIG_FRAMEBUFFER_CONSOLE_ROTATION
+ if ((info->flags & FBINFO_HWACCEL_COPYAREA) &&
+ !(info->flags & FBINFO_HWACCEL_DISABLED))
+ p->scrollmode = SCROLL_MOVE;
+ else /* default to something safe */
+ p->scrollmode = SCROLL_REDRAW;
+#else
p->scrollmode = SCROLL_REDRAW;
+#endif
/*
* ++guenther: console.c:vc_allocate() relies on initializing
@@ -1971,15 +1973,49 @@ static void updatescrollmode(struct fbcon_display *p,
{
struct fbcon_ops *ops = info->fbcon_par;
int fh = vc->vc_font.height;
+ int cap = info->flags;
+ u16 t = 0;
+ int ypan = FBCON_SWAP(ops->rotate, info->fix.ypanstep,
+ info->fix.xpanstep);
+ int ywrap = FBCON_SWAP(ops->rotate, info->fix.ywrapstep, t);
int yres = FBCON_SWAP(ops->rotate, info->var.yres, info->var.xres);
int vyres = FBCON_SWAP(ops->rotate, info->var.yres_virtual,
info->var.xres_virtual);
+ int good_pan = (cap & FBINFO_HWACCEL_YPAN) &&
+ divides(ypan, vc->vc_font.height) && vyres > yres;
+ int good_wrap = (cap & FBINFO_HWACCEL_YWRAP) &&
+ divides(ywrap, vc->vc_font.height) &&
+ divides(vc->vc_font.height, vyres) &&
+ divides(vc->vc_font.height, yres);
+ int reading_fast = cap & FBINFO_READS_FAST;
+ int fast_copyarea = (cap & FBINFO_HWACCEL_COPYAREA) &&
+ !(cap & FBINFO_HWACCEL_DISABLED);
+ int fast_imageblit = (cap & FBINFO_HWACCEL_IMAGEBLIT) &&
+ !(cap & FBINFO_HWACCEL_DISABLED);
p->vrows = vyres/fh;
if (yres > (fh * (vc->vc_rows + 1)))
p->vrows -= (yres - (fh * vc->vc_rows)) / fh;
if ((yres % fh) && (vyres % fh < yres % fh))
p->vrows--;
+
+ if (good_wrap || good_pan) {
+ if (reading_fast || fast_copyarea)
+ p->scrollmode = good_wrap ?
+ SCROLL_WRAP_MOVE : SCROLL_PAN_MOVE;
+ else
+ p->scrollmode = good_wrap ? SCROLL_REDRAW :
+ SCROLL_PAN_REDRAW;
+ } else {
+ if (reading_fast || (fast_copyarea && !fast_imageblit))
+ p->scrollmode = SCROLL_MOVE;
+ else
+ p->scrollmode = SCROLL_REDRAW;
+ }
+
+#ifndef CONFIG_FRAMEBUFFER_CONSOLE_ROTATION
+ p->scrollmode = SCROLL_REDRAW;
+#endif
}
#define PITCH(w) (((w) + 7) >> 3)
--
2.33.0
^ permalink raw reply related [flat|nested] 241+ messages in thread
* [PATCH 04/21] fbcon: delete a few unneeded forward decl
2022-01-31 21:05 ` Daniel Vetter
(?)
@ 2022-01-31 21:05 ` Daniel Vetter
-1 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-01-31 21:05 UTC (permalink / raw)
To: DRI Development
Cc: Intel Graphics Development, linux-fbdev, LKML, Daniel Vetter,
Daniel Vetter, Helge Deller, Daniel Vetter, Thomas Zimmermann,
Du Cheng, Tetsuo Handa, Claudio Suarez, Greg Kroah-Hartman
I didn't bother with any code movement to fix the others, these just
got a bit in the way.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Helge Deller <deller@gmx.de>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Du Cheng <ducheng2@gmail.com>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Claudio Suarez <cssk@net-c.es>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/video/fbdev/core/fbcon.c | 13 +------------
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 39dc18a5de86..2a575620ef59 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -163,18 +163,7 @@ static int fbcon_cursor_noblink;
* Interface used by the world
*/
-static const char *fbcon_startup(void);
-static void fbcon_init(struct vc_data *vc, int init);
-static void fbcon_deinit(struct vc_data *vc);
-static void fbcon_clear(struct vc_data *vc, int sy, int sx, int height,
- int width);
-static void fbcon_putc(struct vc_data *vc, int c, int ypos, int xpos);
-static void fbcon_putcs(struct vc_data *vc, const unsigned short *s,
- int count, int ypos, int xpos);
static void fbcon_clear_margins(struct vc_data *vc, int bottom_only);
-static void fbcon_cursor(struct vc_data *vc, int mode);
-static int fbcon_switch(struct vc_data *vc);
-static int fbcon_blank(struct vc_data *vc, int blank, int mode_switch);
static void fbcon_set_palette(struct vc_data *vc, const unsigned char *table);
/*
@@ -184,8 +173,8 @@ static void fbcon_set_disp(struct fb_info *info, struct fb_var_screeninfo *var,
int unit);
static void fbcon_modechanged(struct fb_info *info);
static void fbcon_set_all_vcs(struct fb_info *info);
-static void fbcon_start(void);
static void fbcon_exit(void);
+
static struct device *fbcon_device;
#ifdef CONFIG_FRAMEBUFFER_CONSOLE_ROTATION
--
2.33.0
^ permalink raw reply related [flat|nested] 241+ messages in thread
* [PATCH 04/21] fbcon: delete a few unneeded forward decl
@ 2022-01-31 21:05 ` Daniel Vetter
0 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-01-31 21:05 UTC (permalink / raw)
To: DRI Development
Cc: linux-fbdev, Thomas Zimmermann, Du Cheng, Tetsuo Handa,
Daniel Vetter, Intel Graphics Development, LKML, Claudio Suarez,
Greg Kroah-Hartman, Daniel Vetter, Helge Deller
I didn't bother with any code movement to fix the others, these just
got a bit in the way.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Helge Deller <deller@gmx.de>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Du Cheng <ducheng2@gmail.com>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Claudio Suarez <cssk@net-c.es>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/video/fbdev/core/fbcon.c | 13 +------------
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 39dc18a5de86..2a575620ef59 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -163,18 +163,7 @@ static int fbcon_cursor_noblink;
* Interface used by the world
*/
-static const char *fbcon_startup(void);
-static void fbcon_init(struct vc_data *vc, int init);
-static void fbcon_deinit(struct vc_data *vc);
-static void fbcon_clear(struct vc_data *vc, int sy, int sx, int height,
- int width);
-static void fbcon_putc(struct vc_data *vc, int c, int ypos, int xpos);
-static void fbcon_putcs(struct vc_data *vc, const unsigned short *s,
- int count, int ypos, int xpos);
static void fbcon_clear_margins(struct vc_data *vc, int bottom_only);
-static void fbcon_cursor(struct vc_data *vc, int mode);
-static int fbcon_switch(struct vc_data *vc);
-static int fbcon_blank(struct vc_data *vc, int blank, int mode_switch);
static void fbcon_set_palette(struct vc_data *vc, const unsigned char *table);
/*
@@ -184,8 +173,8 @@ static void fbcon_set_disp(struct fb_info *info, struct fb_var_screeninfo *var,
int unit);
static void fbcon_modechanged(struct fb_info *info);
static void fbcon_set_all_vcs(struct fb_info *info);
-static void fbcon_start(void);
static void fbcon_exit(void);
+
static struct device *fbcon_device;
#ifdef CONFIG_FRAMEBUFFER_CONSOLE_ROTATION
--
2.33.0
^ permalink raw reply related [flat|nested] 241+ messages in thread
* [Intel-gfx] [PATCH 04/21] fbcon: delete a few unneeded forward decl
@ 2022-01-31 21:05 ` Daniel Vetter
0 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-01-31 21:05 UTC (permalink / raw)
To: DRI Development
Cc: linux-fbdev, Thomas Zimmermann, Du Cheng, Tetsuo Handa,
Daniel Vetter, Intel Graphics Development, LKML,
Greg Kroah-Hartman, Daniel Vetter, Helge Deller
I didn't bother with any code movement to fix the others, these just
got a bit in the way.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Helge Deller <deller@gmx.de>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Du Cheng <ducheng2@gmail.com>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Claudio Suarez <cssk@net-c.es>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/video/fbdev/core/fbcon.c | 13 +------------
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 39dc18a5de86..2a575620ef59 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -163,18 +163,7 @@ static int fbcon_cursor_noblink;
* Interface used by the world
*/
-static const char *fbcon_startup(void);
-static void fbcon_init(struct vc_data *vc, int init);
-static void fbcon_deinit(struct vc_data *vc);
-static void fbcon_clear(struct vc_data *vc, int sy, int sx, int height,
- int width);
-static void fbcon_putc(struct vc_data *vc, int c, int ypos, int xpos);
-static void fbcon_putcs(struct vc_data *vc, const unsigned short *s,
- int count, int ypos, int xpos);
static void fbcon_clear_margins(struct vc_data *vc, int bottom_only);
-static void fbcon_cursor(struct vc_data *vc, int mode);
-static int fbcon_switch(struct vc_data *vc);
-static int fbcon_blank(struct vc_data *vc, int blank, int mode_switch);
static void fbcon_set_palette(struct vc_data *vc, const unsigned char *table);
/*
@@ -184,8 +173,8 @@ static void fbcon_set_disp(struct fb_info *info, struct fb_var_screeninfo *var,
int unit);
static void fbcon_modechanged(struct fb_info *info);
static void fbcon_set_all_vcs(struct fb_info *info);
-static void fbcon_start(void);
static void fbcon_exit(void);
+
static struct device *fbcon_device;
#ifdef CONFIG_FRAMEBUFFER_CONSOLE_ROTATION
--
2.33.0
^ permalink raw reply related [flat|nested] 241+ messages in thread
* [PATCH 05/21] fbcon: Introduce wrapper for console->fb_info lookup
2022-01-31 21:05 ` Daniel Vetter
(?)
@ 2022-01-31 21:05 ` Daniel Vetter
-1 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-01-31 21:05 UTC (permalink / raw)
To: DRI Development
Cc: Intel Graphics Development, linux-fbdev, LKML, Daniel Vetter,
Daniel Vetter, Helge Deller, Daniel Vetter, Greg Kroah-Hartman,
Tetsuo Handa, Du Cheng, Claudio Suarez, Thomas Zimmermann
Half of it is protected by console_lock, but the other half is a lot
more awkward: Registration/deregistration of fbdev are serialized, but
we don't really clear out anything in con2fb_map and so there's
potential for use-after free mixups.
First step is to encapsulate the lookup.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Helge Deller <deller@gmx.de>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Du Cheng <ducheng2@gmail.com>
Cc: Claudio Suarez <cssk@net-c.es>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
---
drivers/video/fbdev/core/fbcon.c | 76 ++++++++++++++++++--------------
1 file changed, 44 insertions(+), 32 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 2a575620ef59..8f971de35885 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -110,6 +110,18 @@ static struct fbcon_display fb_display[MAX_NR_CONSOLES];
static signed char con2fb_map[MAX_NR_CONSOLES];
static signed char con2fb_map_boot[MAX_NR_CONSOLES];
+static struct fb_info *fbcon_info_from_console(int console)
+{
+ WARN_CONSOLE_UNLOCKED();
+
+ /*
+ * Note that only con2fb_map is protected by the console lock,
+ * registered_fb is protected by a separate mutex. This lookup can
+ * therefore race.
+ */
+ return registered_fb[con2fb_map[console]];
+}
+
static int logo_lines;
/* logo_shown is an index to vc_cons when >= 0; otherwise follows FBCON_LOGO
enums. */
@@ -197,7 +209,7 @@ static void fbcon_rotate(struct fb_info *info, u32 rotate)
if (!ops || ops->currcon == -1)
return;
- fb_info = registered_fb[con2fb_map[ops->currcon]];
+ fb_info = fbcon_info_from_console(ops->currcon);
if (info == fb_info) {
struct fbcon_display *p = &fb_display[ops->currcon];
@@ -224,7 +236,7 @@ static void fbcon_rotate_all(struct fb_info *info, u32 rotate)
for (i = first_fb_vc; i <= last_fb_vc; i++) {
vc = vc_cons[i].d;
if (!vc || vc->vc_mode != KD_TEXT ||
- registered_fb[con2fb_map[i]] != info)
+ fbcon_info_from_console(i) != info)
continue;
p = &fb_display[vc->vc_num];
@@ -354,7 +366,7 @@ static void fb_flashcursor(struct work_struct *work)
vc = vc_cons[ops->currcon].d;
if (!vc || !con_is_visible(vc) ||
- registered_fb[con2fb_map[vc->vc_num]] != info ||
+ fbcon_info_from_console(vc->vc_num) != info ||
vc->vc_deccm != 1) {
console_unlock();
return;
@@ -789,7 +801,7 @@ static void con2fb_init_display(struct vc_data *vc, struct fb_info *info,
if (show_logo) {
struct vc_data *fg_vc = vc_cons[fg_console].d;
struct fb_info *fg_info =
- registered_fb[con2fb_map[fg_console]];
+ fbcon_info_from_console(fg_console);
fbcon_prepare_logo(fg_vc, fg_info, fg_vc->vc_cols,
fg_vc->vc_rows, fg_vc->vc_cols,
@@ -1012,7 +1024,7 @@ static void fbcon_init(struct vc_data *vc, int init)
if (con2fb_map[vc->vc_num] == -1)
con2fb_map[vc->vc_num] = info_idx;
- info = registered_fb[con2fb_map[vc->vc_num]];
+ info = fbcon_info_from_console(vc->vc_num);
if (logo_shown < 0 && console_loglevel <= CONSOLE_LOGLEVEL_QUIET)
logo_shown = FBCON_LOGO_DONTSHOW;
@@ -1231,7 +1243,7 @@ static void fbcon_deinit(struct vc_data *vc)
static void fbcon_clear(struct vc_data *vc, int sy, int sx, int height,
int width)
{
- struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fb_info *info = fbcon_info_from_console(vc->vc_num);
struct fbcon_ops *ops = info->fbcon_par;
struct fbcon_display *p = &fb_display[vc->vc_num];
@@ -1269,7 +1281,7 @@ static void fbcon_clear(struct vc_data *vc, int sy, int sx, int height,
static void fbcon_putcs(struct vc_data *vc, const unsigned short *s,
int count, int ypos, int xpos)
{
- struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fb_info *info = fbcon_info_from_console(vc->vc_num);
struct fbcon_display *p = &fb_display[vc->vc_num];
struct fbcon_ops *ops = info->fbcon_par;
@@ -1289,7 +1301,7 @@ static void fbcon_putc(struct vc_data *vc, int c, int ypos, int xpos)
static void fbcon_clear_margins(struct vc_data *vc, int bottom_only)
{
- struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fb_info *info = fbcon_info_from_console(vc->vc_num);
struct fbcon_ops *ops = info->fbcon_par;
if (!fbcon_is_inactive(vc, info))
@@ -1298,7 +1310,7 @@ static void fbcon_clear_margins(struct vc_data *vc, int bottom_only)
static void fbcon_cursor(struct vc_data *vc, int mode)
{
- struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fb_info *info = fbcon_info_from_console(vc->vc_num);
struct fbcon_ops *ops = info->fbcon_par;
int c = scr_readw((u16 *) vc->vc_pos);
@@ -1427,7 +1439,7 @@ static void fbcon_redraw_move(struct vc_data *vc, struct fbcon_display *p,
static __inline__ void ywrap_up(struct vc_data *vc, int count)
{
- struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fb_info *info = fbcon_info_from_console(vc->vc_num);
struct fbcon_ops *ops = info->fbcon_par;
struct fbcon_display *p = &fb_display[vc->vc_num];
@@ -1446,7 +1458,7 @@ static __inline__ void ywrap_up(struct vc_data *vc, int count)
static __inline__ void ywrap_down(struct vc_data *vc, int count)
{
- struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fb_info *info = fbcon_info_from_console(vc->vc_num);
struct fbcon_ops *ops = info->fbcon_par;
struct fbcon_display *p = &fb_display[vc->vc_num];
@@ -1465,7 +1477,7 @@ static __inline__ void ywrap_down(struct vc_data *vc, int count)
static __inline__ void ypan_up(struct vc_data *vc, int count)
{
- struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fb_info *info = fbcon_info_from_console(vc->vc_num);
struct fbcon_display *p = &fb_display[vc->vc_num];
struct fbcon_ops *ops = info->fbcon_par;
@@ -1489,7 +1501,7 @@ static __inline__ void ypan_up(struct vc_data *vc, int count)
static __inline__ void ypan_up_redraw(struct vc_data *vc, int t, int count)
{
- struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fb_info *info = fbcon_info_from_console(vc->vc_num);
struct fbcon_ops *ops = info->fbcon_par;
struct fbcon_display *p = &fb_display[vc->vc_num];
@@ -1513,7 +1525,7 @@ static __inline__ void ypan_up_redraw(struct vc_data *vc, int t, int count)
static __inline__ void ypan_down(struct vc_data *vc, int count)
{
- struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fb_info *info = fbcon_info_from_console(vc->vc_num);
struct fbcon_display *p = &fb_display[vc->vc_num];
struct fbcon_ops *ops = info->fbcon_par;
@@ -1537,7 +1549,7 @@ static __inline__ void ypan_down(struct vc_data *vc, int count)
static __inline__ void ypan_down_redraw(struct vc_data *vc, int t, int count)
{
- struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fb_info *info = fbcon_info_from_console(vc->vc_num);
struct fbcon_ops *ops = info->fbcon_par;
struct fbcon_display *p = &fb_display[vc->vc_num];
@@ -1562,7 +1574,7 @@ static __inline__ void ypan_down_redraw(struct vc_data *vc, int t, int count)
static void fbcon_bmove_rec(struct vc_data *vc, struct fbcon_display *p, int sy, int sx,
int dy, int dx, int height, int width, u_int y_break)
{
- struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fb_info *info = fbcon_info_from_console(vc->vc_num);
struct fbcon_ops *ops = info->fbcon_par;
u_int b;
@@ -1604,7 +1616,7 @@ static void fbcon_bmove_rec(struct vc_data *vc, struct fbcon_display *p, int sy,
static void fbcon_bmove(struct vc_data *vc, int sy, int sx, int dy, int dx,
int height, int width)
{
- struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fb_info *info = fbcon_info_from_console(vc->vc_num);
struct fbcon_display *p = &fb_display[vc->vc_num];
if (fbcon_is_inactive(vc, info))
@@ -1733,7 +1745,7 @@ static void fbcon_redraw(struct vc_data *vc, struct fbcon_display *p,
static bool fbcon_scroll(struct vc_data *vc, unsigned int t, unsigned int b,
enum con_scroll dir, unsigned int count)
{
- struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fb_info *info = fbcon_info_from_console(vc->vc_num);
struct fbcon_display *p = &fb_display[vc->vc_num];
#ifdef CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
int scroll_partial = info->flags & FBINFO_PARTIAL_PAN_OK;
@@ -2013,7 +2025,7 @@ static void updatescrollmode(struct fbcon_display *p,
static int fbcon_resize(struct vc_data *vc, unsigned int width,
unsigned int height, unsigned int user)
{
- struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fb_info *info = fbcon_info_from_console(vc->vc_num);
struct fbcon_ops *ops = info->fbcon_par;
struct fbcon_display *p = &fb_display[vc->vc_num];
struct fb_var_screeninfo var = info->var;
@@ -2082,7 +2094,7 @@ static int fbcon_switch(struct vc_data *vc)
struct fb_var_screeninfo var;
int i, ret, prev_console;
- info = registered_fb[con2fb_map[vc->vc_num]];
+ info = fbcon_info_from_console(vc->vc_num);
ops = info->fbcon_par;
if (logo_shown >= 0) {
@@ -2096,7 +2108,7 @@ static int fbcon_switch(struct vc_data *vc)
prev_console = ops->currcon;
if (prev_console != -1)
- old_info = registered_fb[con2fb_map[prev_console]];
+ old_info = fbcon_info_from_console(prev_console);
/*
* FIXME: If we have multiple fbdev's loaded, we need to
* update all info->currcon. Perhaps, we can place this
@@ -2219,7 +2231,7 @@ static void fbcon_generic_blank(struct vc_data *vc, struct fb_info *info,
static int fbcon_blank(struct vc_data *vc, int blank, int mode_switch)
{
- struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fb_info *info = fbcon_info_from_console(vc->vc_num);
struct fbcon_ops *ops = info->fbcon_par;
if (mode_switch) {
@@ -2261,7 +2273,7 @@ static int fbcon_blank(struct vc_data *vc, int blank, int mode_switch)
static int fbcon_debug_enter(struct vc_data *vc)
{
- struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fb_info *info = fbcon_info_from_console(vc->vc_num);
struct fbcon_ops *ops = info->fbcon_par;
ops->save_graphics = ops->graphics;
@@ -2274,7 +2286,7 @@ static int fbcon_debug_enter(struct vc_data *vc)
static int fbcon_debug_leave(struct vc_data *vc)
{
- struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fb_info *info = fbcon_info_from_console(vc->vc_num);
struct fbcon_ops *ops = info->fbcon_par;
ops->graphics = ops->save_graphics;
@@ -2410,7 +2422,7 @@ static void set_vc_hi_font(struct vc_data *vc, bool set)
static int fbcon_do_set_font(struct vc_data *vc, int w, int h, int charcount,
const u8 * data, int userfont)
{
- struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fb_info *info = fbcon_info_from_console(vc->vc_num);
struct fbcon_ops *ops = info->fbcon_par;
struct fbcon_display *p = &fb_display[vc->vc_num];
int resize;
@@ -2464,7 +2476,7 @@ static int fbcon_do_set_font(struct vc_data *vc, int w, int h, int charcount,
static int fbcon_set_font(struct vc_data *vc, struct console_font *font,
unsigned int flags)
{
- struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fb_info *info = fbcon_info_from_console(vc->vc_num);
unsigned charcount = font->charcount;
int w = font->width;
int h = font->height;
@@ -2528,7 +2540,7 @@ static int fbcon_set_font(struct vc_data *vc, struct console_font *font,
static int fbcon_set_def_font(struct vc_data *vc, struct console_font *font, char *name)
{
- struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fb_info *info = fbcon_info_from_console(vc->vc_num);
const struct font_desc *f;
if (!name)
@@ -2552,7 +2564,7 @@ static struct fb_cmap palette_cmap = {
static void fbcon_set_palette(struct vc_data *vc, const unsigned char *table)
{
- struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fb_info *info = fbcon_info_from_console(vc->vc_num);
int i, j, k, depth;
u8 val;
@@ -2668,7 +2680,7 @@ static void fbcon_modechanged(struct fb_info *info)
return;
vc = vc_cons[ops->currcon].d;
if (vc->vc_mode != KD_TEXT ||
- registered_fb[con2fb_map[ops->currcon]] != info)
+ fbcon_info_from_console(ops->currcon) != info)
return;
p = &fb_display[vc->vc_num];
@@ -2708,7 +2720,7 @@ static void fbcon_set_all_vcs(struct fb_info *info)
for (i = first_fb_vc; i <= last_fb_vc; i++) {
vc = vc_cons[i].d;
if (!vc || vc->vc_mode != KD_TEXT ||
- registered_fb[con2fb_map[i]] != info)
+ fbcon_info_from_console(i) != info)
continue;
if (con_is_visible(vc)) {
@@ -2971,7 +2983,7 @@ void fbcon_fb_blanked(struct fb_info *info, int blank)
vc = vc_cons[ops->currcon].d;
if (vc->vc_mode != KD_TEXT ||
- registered_fb[con2fb_map[ops->currcon]] != info)
+ fbcon_info_from_console(ops->currcon) != info)
return;
if (con_is_visible(vc)) {
@@ -2991,7 +3003,7 @@ void fbcon_new_modelist(struct fb_info *info)
const struct fb_videomode *mode;
for (i = first_fb_vc; i <= last_fb_vc; i++) {
- if (registered_fb[con2fb_map[i]] != info)
+ if (fbcon_info_from_console(i) != info)
continue;
if (!fb_display[i].mode)
continue;
--
2.33.0
^ permalink raw reply related [flat|nested] 241+ messages in thread
* [PATCH 05/21] fbcon: Introduce wrapper for console->fb_info lookup
@ 2022-01-31 21:05 ` Daniel Vetter
0 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-01-31 21:05 UTC (permalink / raw)
To: DRI Development
Cc: linux-fbdev, Thomas Zimmermann, Du Cheng, Tetsuo Handa,
Daniel Vetter, Intel Graphics Development, LKML, Claudio Suarez,
Greg Kroah-Hartman, Daniel Vetter, Helge Deller
Half of it is protected by console_lock, but the other half is a lot
more awkward: Registration/deregistration of fbdev are serialized, but
we don't really clear out anything in con2fb_map and so there's
potential for use-after free mixups.
First step is to encapsulate the lookup.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Helge Deller <deller@gmx.de>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Du Cheng <ducheng2@gmail.com>
Cc: Claudio Suarez <cssk@net-c.es>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
---
drivers/video/fbdev/core/fbcon.c | 76 ++++++++++++++++++--------------
1 file changed, 44 insertions(+), 32 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 2a575620ef59..8f971de35885 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -110,6 +110,18 @@ static struct fbcon_display fb_display[MAX_NR_CONSOLES];
static signed char con2fb_map[MAX_NR_CONSOLES];
static signed char con2fb_map_boot[MAX_NR_CONSOLES];
+static struct fb_info *fbcon_info_from_console(int console)
+{
+ WARN_CONSOLE_UNLOCKED();
+
+ /*
+ * Note that only con2fb_map is protected by the console lock,
+ * registered_fb is protected by a separate mutex. This lookup can
+ * therefore race.
+ */
+ return registered_fb[con2fb_map[console]];
+}
+
static int logo_lines;
/* logo_shown is an index to vc_cons when >= 0; otherwise follows FBCON_LOGO
enums. */
@@ -197,7 +209,7 @@ static void fbcon_rotate(struct fb_info *info, u32 rotate)
if (!ops || ops->currcon == -1)
return;
- fb_info = registered_fb[con2fb_map[ops->currcon]];
+ fb_info = fbcon_info_from_console(ops->currcon);
if (info == fb_info) {
struct fbcon_display *p = &fb_display[ops->currcon];
@@ -224,7 +236,7 @@ static void fbcon_rotate_all(struct fb_info *info, u32 rotate)
for (i = first_fb_vc; i <= last_fb_vc; i++) {
vc = vc_cons[i].d;
if (!vc || vc->vc_mode != KD_TEXT ||
- registered_fb[con2fb_map[i]] != info)
+ fbcon_info_from_console(i) != info)
continue;
p = &fb_display[vc->vc_num];
@@ -354,7 +366,7 @@ static void fb_flashcursor(struct work_struct *work)
vc = vc_cons[ops->currcon].d;
if (!vc || !con_is_visible(vc) ||
- registered_fb[con2fb_map[vc->vc_num]] != info ||
+ fbcon_info_from_console(vc->vc_num) != info ||
vc->vc_deccm != 1) {
console_unlock();
return;
@@ -789,7 +801,7 @@ static void con2fb_init_display(struct vc_data *vc, struct fb_info *info,
if (show_logo) {
struct vc_data *fg_vc = vc_cons[fg_console].d;
struct fb_info *fg_info =
- registered_fb[con2fb_map[fg_console]];
+ fbcon_info_from_console(fg_console);
fbcon_prepare_logo(fg_vc, fg_info, fg_vc->vc_cols,
fg_vc->vc_rows, fg_vc->vc_cols,
@@ -1012,7 +1024,7 @@ static void fbcon_init(struct vc_data *vc, int init)
if (con2fb_map[vc->vc_num] == -1)
con2fb_map[vc->vc_num] = info_idx;
- info = registered_fb[con2fb_map[vc->vc_num]];
+ info = fbcon_info_from_console(vc->vc_num);
if (logo_shown < 0 && console_loglevel <= CONSOLE_LOGLEVEL_QUIET)
logo_shown = FBCON_LOGO_DONTSHOW;
@@ -1231,7 +1243,7 @@ static void fbcon_deinit(struct vc_data *vc)
static void fbcon_clear(struct vc_data *vc, int sy, int sx, int height,
int width)
{
- struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fb_info *info = fbcon_info_from_console(vc->vc_num);
struct fbcon_ops *ops = info->fbcon_par;
struct fbcon_display *p = &fb_display[vc->vc_num];
@@ -1269,7 +1281,7 @@ static void fbcon_clear(struct vc_data *vc, int sy, int sx, int height,
static void fbcon_putcs(struct vc_data *vc, const unsigned short *s,
int count, int ypos, int xpos)
{
- struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fb_info *info = fbcon_info_from_console(vc->vc_num);
struct fbcon_display *p = &fb_display[vc->vc_num];
struct fbcon_ops *ops = info->fbcon_par;
@@ -1289,7 +1301,7 @@ static void fbcon_putc(struct vc_data *vc, int c, int ypos, int xpos)
static void fbcon_clear_margins(struct vc_data *vc, int bottom_only)
{
- struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fb_info *info = fbcon_info_from_console(vc->vc_num);
struct fbcon_ops *ops = info->fbcon_par;
if (!fbcon_is_inactive(vc, info))
@@ -1298,7 +1310,7 @@ static void fbcon_clear_margins(struct vc_data *vc, int bottom_only)
static void fbcon_cursor(struct vc_data *vc, int mode)
{
- struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fb_info *info = fbcon_info_from_console(vc->vc_num);
struct fbcon_ops *ops = info->fbcon_par;
int c = scr_readw((u16 *) vc->vc_pos);
@@ -1427,7 +1439,7 @@ static void fbcon_redraw_move(struct vc_data *vc, struct fbcon_display *p,
static __inline__ void ywrap_up(struct vc_data *vc, int count)
{
- struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fb_info *info = fbcon_info_from_console(vc->vc_num);
struct fbcon_ops *ops = info->fbcon_par;
struct fbcon_display *p = &fb_display[vc->vc_num];
@@ -1446,7 +1458,7 @@ static __inline__ void ywrap_up(struct vc_data *vc, int count)
static __inline__ void ywrap_down(struct vc_data *vc, int count)
{
- struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fb_info *info = fbcon_info_from_console(vc->vc_num);
struct fbcon_ops *ops = info->fbcon_par;
struct fbcon_display *p = &fb_display[vc->vc_num];
@@ -1465,7 +1477,7 @@ static __inline__ void ywrap_down(struct vc_data *vc, int count)
static __inline__ void ypan_up(struct vc_data *vc, int count)
{
- struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fb_info *info = fbcon_info_from_console(vc->vc_num);
struct fbcon_display *p = &fb_display[vc->vc_num];
struct fbcon_ops *ops = info->fbcon_par;
@@ -1489,7 +1501,7 @@ static __inline__ void ypan_up(struct vc_data *vc, int count)
static __inline__ void ypan_up_redraw(struct vc_data *vc, int t, int count)
{
- struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fb_info *info = fbcon_info_from_console(vc->vc_num);
struct fbcon_ops *ops = info->fbcon_par;
struct fbcon_display *p = &fb_display[vc->vc_num];
@@ -1513,7 +1525,7 @@ static __inline__ void ypan_up_redraw(struct vc_data *vc, int t, int count)
static __inline__ void ypan_down(struct vc_data *vc, int count)
{
- struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fb_info *info = fbcon_info_from_console(vc->vc_num);
struct fbcon_display *p = &fb_display[vc->vc_num];
struct fbcon_ops *ops = info->fbcon_par;
@@ -1537,7 +1549,7 @@ static __inline__ void ypan_down(struct vc_data *vc, int count)
static __inline__ void ypan_down_redraw(struct vc_data *vc, int t, int count)
{
- struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fb_info *info = fbcon_info_from_console(vc->vc_num);
struct fbcon_ops *ops = info->fbcon_par;
struct fbcon_display *p = &fb_display[vc->vc_num];
@@ -1562,7 +1574,7 @@ static __inline__ void ypan_down_redraw(struct vc_data *vc, int t, int count)
static void fbcon_bmove_rec(struct vc_data *vc, struct fbcon_display *p, int sy, int sx,
int dy, int dx, int height, int width, u_int y_break)
{
- struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fb_info *info = fbcon_info_from_console(vc->vc_num);
struct fbcon_ops *ops = info->fbcon_par;
u_int b;
@@ -1604,7 +1616,7 @@ static void fbcon_bmove_rec(struct vc_data *vc, struct fbcon_display *p, int sy,
static void fbcon_bmove(struct vc_data *vc, int sy, int sx, int dy, int dx,
int height, int width)
{
- struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fb_info *info = fbcon_info_from_console(vc->vc_num);
struct fbcon_display *p = &fb_display[vc->vc_num];
if (fbcon_is_inactive(vc, info))
@@ -1733,7 +1745,7 @@ static void fbcon_redraw(struct vc_data *vc, struct fbcon_display *p,
static bool fbcon_scroll(struct vc_data *vc, unsigned int t, unsigned int b,
enum con_scroll dir, unsigned int count)
{
- struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fb_info *info = fbcon_info_from_console(vc->vc_num);
struct fbcon_display *p = &fb_display[vc->vc_num];
#ifdef CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
int scroll_partial = info->flags & FBINFO_PARTIAL_PAN_OK;
@@ -2013,7 +2025,7 @@ static void updatescrollmode(struct fbcon_display *p,
static int fbcon_resize(struct vc_data *vc, unsigned int width,
unsigned int height, unsigned int user)
{
- struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fb_info *info = fbcon_info_from_console(vc->vc_num);
struct fbcon_ops *ops = info->fbcon_par;
struct fbcon_display *p = &fb_display[vc->vc_num];
struct fb_var_screeninfo var = info->var;
@@ -2082,7 +2094,7 @@ static int fbcon_switch(struct vc_data *vc)
struct fb_var_screeninfo var;
int i, ret, prev_console;
- info = registered_fb[con2fb_map[vc->vc_num]];
+ info = fbcon_info_from_console(vc->vc_num);
ops = info->fbcon_par;
if (logo_shown >= 0) {
@@ -2096,7 +2108,7 @@ static int fbcon_switch(struct vc_data *vc)
prev_console = ops->currcon;
if (prev_console != -1)
- old_info = registered_fb[con2fb_map[prev_console]];
+ old_info = fbcon_info_from_console(prev_console);
/*
* FIXME: If we have multiple fbdev's loaded, we need to
* update all info->currcon. Perhaps, we can place this
@@ -2219,7 +2231,7 @@ static void fbcon_generic_blank(struct vc_data *vc, struct fb_info *info,
static int fbcon_blank(struct vc_data *vc, int blank, int mode_switch)
{
- struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fb_info *info = fbcon_info_from_console(vc->vc_num);
struct fbcon_ops *ops = info->fbcon_par;
if (mode_switch) {
@@ -2261,7 +2273,7 @@ static int fbcon_blank(struct vc_data *vc, int blank, int mode_switch)
static int fbcon_debug_enter(struct vc_data *vc)
{
- struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fb_info *info = fbcon_info_from_console(vc->vc_num);
struct fbcon_ops *ops = info->fbcon_par;
ops->save_graphics = ops->graphics;
@@ -2274,7 +2286,7 @@ static int fbcon_debug_enter(struct vc_data *vc)
static int fbcon_debug_leave(struct vc_data *vc)
{
- struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fb_info *info = fbcon_info_from_console(vc->vc_num);
struct fbcon_ops *ops = info->fbcon_par;
ops->graphics = ops->save_graphics;
@@ -2410,7 +2422,7 @@ static void set_vc_hi_font(struct vc_data *vc, bool set)
static int fbcon_do_set_font(struct vc_data *vc, int w, int h, int charcount,
const u8 * data, int userfont)
{
- struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fb_info *info = fbcon_info_from_console(vc->vc_num);
struct fbcon_ops *ops = info->fbcon_par;
struct fbcon_display *p = &fb_display[vc->vc_num];
int resize;
@@ -2464,7 +2476,7 @@ static int fbcon_do_set_font(struct vc_data *vc, int w, int h, int charcount,
static int fbcon_set_font(struct vc_data *vc, struct console_font *font,
unsigned int flags)
{
- struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fb_info *info = fbcon_info_from_console(vc->vc_num);
unsigned charcount = font->charcount;
int w = font->width;
int h = font->height;
@@ -2528,7 +2540,7 @@ static int fbcon_set_font(struct vc_data *vc, struct console_font *font,
static int fbcon_set_def_font(struct vc_data *vc, struct console_font *font, char *name)
{
- struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fb_info *info = fbcon_info_from_console(vc->vc_num);
const struct font_desc *f;
if (!name)
@@ -2552,7 +2564,7 @@ static struct fb_cmap palette_cmap = {
static void fbcon_set_palette(struct vc_data *vc, const unsigned char *table)
{
- struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fb_info *info = fbcon_info_from_console(vc->vc_num);
int i, j, k, depth;
u8 val;
@@ -2668,7 +2680,7 @@ static void fbcon_modechanged(struct fb_info *info)
return;
vc = vc_cons[ops->currcon].d;
if (vc->vc_mode != KD_TEXT ||
- registered_fb[con2fb_map[ops->currcon]] != info)
+ fbcon_info_from_console(ops->currcon) != info)
return;
p = &fb_display[vc->vc_num];
@@ -2708,7 +2720,7 @@ static void fbcon_set_all_vcs(struct fb_info *info)
for (i = first_fb_vc; i <= last_fb_vc; i++) {
vc = vc_cons[i].d;
if (!vc || vc->vc_mode != KD_TEXT ||
- registered_fb[con2fb_map[i]] != info)
+ fbcon_info_from_console(i) != info)
continue;
if (con_is_visible(vc)) {
@@ -2971,7 +2983,7 @@ void fbcon_fb_blanked(struct fb_info *info, int blank)
vc = vc_cons[ops->currcon].d;
if (vc->vc_mode != KD_TEXT ||
- registered_fb[con2fb_map[ops->currcon]] != info)
+ fbcon_info_from_console(ops->currcon) != info)
return;
if (con_is_visible(vc)) {
@@ -2991,7 +3003,7 @@ void fbcon_new_modelist(struct fb_info *info)
const struct fb_videomode *mode;
for (i = first_fb_vc; i <= last_fb_vc; i++) {
- if (registered_fb[con2fb_map[i]] != info)
+ if (fbcon_info_from_console(i) != info)
continue;
if (!fb_display[i].mode)
continue;
--
2.33.0
^ permalink raw reply related [flat|nested] 241+ messages in thread
* [Intel-gfx] [PATCH 05/21] fbcon: Introduce wrapper for console->fb_info lookup
@ 2022-01-31 21:05 ` Daniel Vetter
0 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-01-31 21:05 UTC (permalink / raw)
To: DRI Development
Cc: linux-fbdev, Thomas Zimmermann, Du Cheng, Tetsuo Handa,
Daniel Vetter, Intel Graphics Development, LKML,
Greg Kroah-Hartman, Daniel Vetter, Helge Deller
Half of it is protected by console_lock, but the other half is a lot
more awkward: Registration/deregistration of fbdev are serialized, but
we don't really clear out anything in con2fb_map and so there's
potential for use-after free mixups.
First step is to encapsulate the lookup.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Helge Deller <deller@gmx.de>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Du Cheng <ducheng2@gmail.com>
Cc: Claudio Suarez <cssk@net-c.es>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
---
drivers/video/fbdev/core/fbcon.c | 76 ++++++++++++++++++--------------
1 file changed, 44 insertions(+), 32 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 2a575620ef59..8f971de35885 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -110,6 +110,18 @@ static struct fbcon_display fb_display[MAX_NR_CONSOLES];
static signed char con2fb_map[MAX_NR_CONSOLES];
static signed char con2fb_map_boot[MAX_NR_CONSOLES];
+static struct fb_info *fbcon_info_from_console(int console)
+{
+ WARN_CONSOLE_UNLOCKED();
+
+ /*
+ * Note that only con2fb_map is protected by the console lock,
+ * registered_fb is protected by a separate mutex. This lookup can
+ * therefore race.
+ */
+ return registered_fb[con2fb_map[console]];
+}
+
static int logo_lines;
/* logo_shown is an index to vc_cons when >= 0; otherwise follows FBCON_LOGO
enums. */
@@ -197,7 +209,7 @@ static void fbcon_rotate(struct fb_info *info, u32 rotate)
if (!ops || ops->currcon == -1)
return;
- fb_info = registered_fb[con2fb_map[ops->currcon]];
+ fb_info = fbcon_info_from_console(ops->currcon);
if (info == fb_info) {
struct fbcon_display *p = &fb_display[ops->currcon];
@@ -224,7 +236,7 @@ static void fbcon_rotate_all(struct fb_info *info, u32 rotate)
for (i = first_fb_vc; i <= last_fb_vc; i++) {
vc = vc_cons[i].d;
if (!vc || vc->vc_mode != KD_TEXT ||
- registered_fb[con2fb_map[i]] != info)
+ fbcon_info_from_console(i) != info)
continue;
p = &fb_display[vc->vc_num];
@@ -354,7 +366,7 @@ static void fb_flashcursor(struct work_struct *work)
vc = vc_cons[ops->currcon].d;
if (!vc || !con_is_visible(vc) ||
- registered_fb[con2fb_map[vc->vc_num]] != info ||
+ fbcon_info_from_console(vc->vc_num) != info ||
vc->vc_deccm != 1) {
console_unlock();
return;
@@ -789,7 +801,7 @@ static void con2fb_init_display(struct vc_data *vc, struct fb_info *info,
if (show_logo) {
struct vc_data *fg_vc = vc_cons[fg_console].d;
struct fb_info *fg_info =
- registered_fb[con2fb_map[fg_console]];
+ fbcon_info_from_console(fg_console);
fbcon_prepare_logo(fg_vc, fg_info, fg_vc->vc_cols,
fg_vc->vc_rows, fg_vc->vc_cols,
@@ -1012,7 +1024,7 @@ static void fbcon_init(struct vc_data *vc, int init)
if (con2fb_map[vc->vc_num] == -1)
con2fb_map[vc->vc_num] = info_idx;
- info = registered_fb[con2fb_map[vc->vc_num]];
+ info = fbcon_info_from_console(vc->vc_num);
if (logo_shown < 0 && console_loglevel <= CONSOLE_LOGLEVEL_QUIET)
logo_shown = FBCON_LOGO_DONTSHOW;
@@ -1231,7 +1243,7 @@ static void fbcon_deinit(struct vc_data *vc)
static void fbcon_clear(struct vc_data *vc, int sy, int sx, int height,
int width)
{
- struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fb_info *info = fbcon_info_from_console(vc->vc_num);
struct fbcon_ops *ops = info->fbcon_par;
struct fbcon_display *p = &fb_display[vc->vc_num];
@@ -1269,7 +1281,7 @@ static void fbcon_clear(struct vc_data *vc, int sy, int sx, int height,
static void fbcon_putcs(struct vc_data *vc, const unsigned short *s,
int count, int ypos, int xpos)
{
- struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fb_info *info = fbcon_info_from_console(vc->vc_num);
struct fbcon_display *p = &fb_display[vc->vc_num];
struct fbcon_ops *ops = info->fbcon_par;
@@ -1289,7 +1301,7 @@ static void fbcon_putc(struct vc_data *vc, int c, int ypos, int xpos)
static void fbcon_clear_margins(struct vc_data *vc, int bottom_only)
{
- struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fb_info *info = fbcon_info_from_console(vc->vc_num);
struct fbcon_ops *ops = info->fbcon_par;
if (!fbcon_is_inactive(vc, info))
@@ -1298,7 +1310,7 @@ static void fbcon_clear_margins(struct vc_data *vc, int bottom_only)
static void fbcon_cursor(struct vc_data *vc, int mode)
{
- struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fb_info *info = fbcon_info_from_console(vc->vc_num);
struct fbcon_ops *ops = info->fbcon_par;
int c = scr_readw((u16 *) vc->vc_pos);
@@ -1427,7 +1439,7 @@ static void fbcon_redraw_move(struct vc_data *vc, struct fbcon_display *p,
static __inline__ void ywrap_up(struct vc_data *vc, int count)
{
- struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fb_info *info = fbcon_info_from_console(vc->vc_num);
struct fbcon_ops *ops = info->fbcon_par;
struct fbcon_display *p = &fb_display[vc->vc_num];
@@ -1446,7 +1458,7 @@ static __inline__ void ywrap_up(struct vc_data *vc, int count)
static __inline__ void ywrap_down(struct vc_data *vc, int count)
{
- struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fb_info *info = fbcon_info_from_console(vc->vc_num);
struct fbcon_ops *ops = info->fbcon_par;
struct fbcon_display *p = &fb_display[vc->vc_num];
@@ -1465,7 +1477,7 @@ static __inline__ void ywrap_down(struct vc_data *vc, int count)
static __inline__ void ypan_up(struct vc_data *vc, int count)
{
- struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fb_info *info = fbcon_info_from_console(vc->vc_num);
struct fbcon_display *p = &fb_display[vc->vc_num];
struct fbcon_ops *ops = info->fbcon_par;
@@ -1489,7 +1501,7 @@ static __inline__ void ypan_up(struct vc_data *vc, int count)
static __inline__ void ypan_up_redraw(struct vc_data *vc, int t, int count)
{
- struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fb_info *info = fbcon_info_from_console(vc->vc_num);
struct fbcon_ops *ops = info->fbcon_par;
struct fbcon_display *p = &fb_display[vc->vc_num];
@@ -1513,7 +1525,7 @@ static __inline__ void ypan_up_redraw(struct vc_data *vc, int t, int count)
static __inline__ void ypan_down(struct vc_data *vc, int count)
{
- struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fb_info *info = fbcon_info_from_console(vc->vc_num);
struct fbcon_display *p = &fb_display[vc->vc_num];
struct fbcon_ops *ops = info->fbcon_par;
@@ -1537,7 +1549,7 @@ static __inline__ void ypan_down(struct vc_data *vc, int count)
static __inline__ void ypan_down_redraw(struct vc_data *vc, int t, int count)
{
- struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fb_info *info = fbcon_info_from_console(vc->vc_num);
struct fbcon_ops *ops = info->fbcon_par;
struct fbcon_display *p = &fb_display[vc->vc_num];
@@ -1562,7 +1574,7 @@ static __inline__ void ypan_down_redraw(struct vc_data *vc, int t, int count)
static void fbcon_bmove_rec(struct vc_data *vc, struct fbcon_display *p, int sy, int sx,
int dy, int dx, int height, int width, u_int y_break)
{
- struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fb_info *info = fbcon_info_from_console(vc->vc_num);
struct fbcon_ops *ops = info->fbcon_par;
u_int b;
@@ -1604,7 +1616,7 @@ static void fbcon_bmove_rec(struct vc_data *vc, struct fbcon_display *p, int sy,
static void fbcon_bmove(struct vc_data *vc, int sy, int sx, int dy, int dx,
int height, int width)
{
- struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fb_info *info = fbcon_info_from_console(vc->vc_num);
struct fbcon_display *p = &fb_display[vc->vc_num];
if (fbcon_is_inactive(vc, info))
@@ -1733,7 +1745,7 @@ static void fbcon_redraw(struct vc_data *vc, struct fbcon_display *p,
static bool fbcon_scroll(struct vc_data *vc, unsigned int t, unsigned int b,
enum con_scroll dir, unsigned int count)
{
- struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fb_info *info = fbcon_info_from_console(vc->vc_num);
struct fbcon_display *p = &fb_display[vc->vc_num];
#ifdef CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
int scroll_partial = info->flags & FBINFO_PARTIAL_PAN_OK;
@@ -2013,7 +2025,7 @@ static void updatescrollmode(struct fbcon_display *p,
static int fbcon_resize(struct vc_data *vc, unsigned int width,
unsigned int height, unsigned int user)
{
- struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fb_info *info = fbcon_info_from_console(vc->vc_num);
struct fbcon_ops *ops = info->fbcon_par;
struct fbcon_display *p = &fb_display[vc->vc_num];
struct fb_var_screeninfo var = info->var;
@@ -2082,7 +2094,7 @@ static int fbcon_switch(struct vc_data *vc)
struct fb_var_screeninfo var;
int i, ret, prev_console;
- info = registered_fb[con2fb_map[vc->vc_num]];
+ info = fbcon_info_from_console(vc->vc_num);
ops = info->fbcon_par;
if (logo_shown >= 0) {
@@ -2096,7 +2108,7 @@ static int fbcon_switch(struct vc_data *vc)
prev_console = ops->currcon;
if (prev_console != -1)
- old_info = registered_fb[con2fb_map[prev_console]];
+ old_info = fbcon_info_from_console(prev_console);
/*
* FIXME: If we have multiple fbdev's loaded, we need to
* update all info->currcon. Perhaps, we can place this
@@ -2219,7 +2231,7 @@ static void fbcon_generic_blank(struct vc_data *vc, struct fb_info *info,
static int fbcon_blank(struct vc_data *vc, int blank, int mode_switch)
{
- struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fb_info *info = fbcon_info_from_console(vc->vc_num);
struct fbcon_ops *ops = info->fbcon_par;
if (mode_switch) {
@@ -2261,7 +2273,7 @@ static int fbcon_blank(struct vc_data *vc, int blank, int mode_switch)
static int fbcon_debug_enter(struct vc_data *vc)
{
- struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fb_info *info = fbcon_info_from_console(vc->vc_num);
struct fbcon_ops *ops = info->fbcon_par;
ops->save_graphics = ops->graphics;
@@ -2274,7 +2286,7 @@ static int fbcon_debug_enter(struct vc_data *vc)
static int fbcon_debug_leave(struct vc_data *vc)
{
- struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fb_info *info = fbcon_info_from_console(vc->vc_num);
struct fbcon_ops *ops = info->fbcon_par;
ops->graphics = ops->save_graphics;
@@ -2410,7 +2422,7 @@ static void set_vc_hi_font(struct vc_data *vc, bool set)
static int fbcon_do_set_font(struct vc_data *vc, int w, int h, int charcount,
const u8 * data, int userfont)
{
- struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fb_info *info = fbcon_info_from_console(vc->vc_num);
struct fbcon_ops *ops = info->fbcon_par;
struct fbcon_display *p = &fb_display[vc->vc_num];
int resize;
@@ -2464,7 +2476,7 @@ static int fbcon_do_set_font(struct vc_data *vc, int w, int h, int charcount,
static int fbcon_set_font(struct vc_data *vc, struct console_font *font,
unsigned int flags)
{
- struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fb_info *info = fbcon_info_from_console(vc->vc_num);
unsigned charcount = font->charcount;
int w = font->width;
int h = font->height;
@@ -2528,7 +2540,7 @@ static int fbcon_set_font(struct vc_data *vc, struct console_font *font,
static int fbcon_set_def_font(struct vc_data *vc, struct console_font *font, char *name)
{
- struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fb_info *info = fbcon_info_from_console(vc->vc_num);
const struct font_desc *f;
if (!name)
@@ -2552,7 +2564,7 @@ static struct fb_cmap palette_cmap = {
static void fbcon_set_palette(struct vc_data *vc, const unsigned char *table)
{
- struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]];
+ struct fb_info *info = fbcon_info_from_console(vc->vc_num);
int i, j, k, depth;
u8 val;
@@ -2668,7 +2680,7 @@ static void fbcon_modechanged(struct fb_info *info)
return;
vc = vc_cons[ops->currcon].d;
if (vc->vc_mode != KD_TEXT ||
- registered_fb[con2fb_map[ops->currcon]] != info)
+ fbcon_info_from_console(ops->currcon) != info)
return;
p = &fb_display[vc->vc_num];
@@ -2708,7 +2720,7 @@ static void fbcon_set_all_vcs(struct fb_info *info)
for (i = first_fb_vc; i <= last_fb_vc; i++) {
vc = vc_cons[i].d;
if (!vc || vc->vc_mode != KD_TEXT ||
- registered_fb[con2fb_map[i]] != info)
+ fbcon_info_from_console(i) != info)
continue;
if (con_is_visible(vc)) {
@@ -2971,7 +2983,7 @@ void fbcon_fb_blanked(struct fb_info *info, int blank)
vc = vc_cons[ops->currcon].d;
if (vc->vc_mode != KD_TEXT ||
- registered_fb[con2fb_map[ops->currcon]] != info)
+ fbcon_info_from_console(ops->currcon) != info)
return;
if (con_is_visible(vc)) {
@@ -2991,7 +3003,7 @@ void fbcon_new_modelist(struct fb_info *info)
const struct fb_videomode *mode;
for (i = first_fb_vc; i <= last_fb_vc; i++) {
- if (registered_fb[con2fb_map[i]] != info)
+ if (fbcon_info_from_console(i) != info)
continue;
if (!fb_display[i].mode)
continue;
--
2.33.0
^ permalink raw reply related [flat|nested] 241+ messages in thread
* [PATCH 06/21] fbcon: delete delayed loading code
2022-01-31 21:05 ` Daniel Vetter
(?)
@ 2022-01-31 21:05 ` Daniel Vetter
-1 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-01-31 21:05 UTC (permalink / raw)
To: DRI Development
Cc: Intel Graphics Development, linux-fbdev, LKML, Daniel Vetter,
Daniel Vetter, Helge Deller, Daniel Vetter, Claudio Suarez,
Greg Kroah-Hartman, Tetsuo Handa, Du Cheng
Before
commit 6104c37094e729f3d4ce65797002112735d49cd1
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Tue Aug 1 17:32:07 2017 +0200
fbcon: Make fbcon a built-time depency for fbdev
it was possible to load fbcon and fbdev drivers in any order, which
means that fbcon init had to handle the case where fbdev drivers where
already registered.
This is no longer possible, hence delete that code.
Note that the exit case is a bit more complex and will be done in a
separate patch.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Helge Deller <deller@gmx.de>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Claudio Suarez <cssk@net-c.es>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Du Cheng <ducheng2@gmail.com>
---
drivers/video/fbdev/core/fbcon.c | 13 +------------
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 8f971de35885..814b648e8f09 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -942,7 +942,7 @@ static const char *fbcon_startup(void)
return display_desc;
/*
* Instead of blindly using registered_fb[0], we use info_idx, set by
- * fb_console_init();
+ * fbcon_fb_registered();
*/
info = registered_fb[info_idx];
if (!info)
@@ -3316,17 +3316,6 @@ static void fbcon_start(void)
return;
}
#endif
-
- if (num_registered_fb) {
- int i;
-
- for_each_registered_fb(i) {
- info_idx = i;
- break;
- }
-
- do_fbcon_takeover(0);
- }
}
static void fbcon_exit(void)
--
2.33.0
^ permalink raw reply related [flat|nested] 241+ messages in thread
* [PATCH 06/21] fbcon: delete delayed loading code
@ 2022-01-31 21:05 ` Daniel Vetter
0 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-01-31 21:05 UTC (permalink / raw)
To: DRI Development
Cc: linux-fbdev, Du Cheng, Tetsuo Handa, Daniel Vetter,
Intel Graphics Development, LKML, Claudio Suarez,
Greg Kroah-Hartman, Daniel Vetter, Helge Deller
Before
commit 6104c37094e729f3d4ce65797002112735d49cd1
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Tue Aug 1 17:32:07 2017 +0200
fbcon: Make fbcon a built-time depency for fbdev
it was possible to load fbcon and fbdev drivers in any order, which
means that fbcon init had to handle the case where fbdev drivers where
already registered.
This is no longer possible, hence delete that code.
Note that the exit case is a bit more complex and will be done in a
separate patch.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Helge Deller <deller@gmx.de>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Claudio Suarez <cssk@net-c.es>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Du Cheng <ducheng2@gmail.com>
---
drivers/video/fbdev/core/fbcon.c | 13 +------------
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 8f971de35885..814b648e8f09 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -942,7 +942,7 @@ static const char *fbcon_startup(void)
return display_desc;
/*
* Instead of blindly using registered_fb[0], we use info_idx, set by
- * fb_console_init();
+ * fbcon_fb_registered();
*/
info = registered_fb[info_idx];
if (!info)
@@ -3316,17 +3316,6 @@ static void fbcon_start(void)
return;
}
#endif
-
- if (num_registered_fb) {
- int i;
-
- for_each_registered_fb(i) {
- info_idx = i;
- break;
- }
-
- do_fbcon_takeover(0);
- }
}
static void fbcon_exit(void)
--
2.33.0
^ permalink raw reply related [flat|nested] 241+ messages in thread
* [Intel-gfx] [PATCH 06/21] fbcon: delete delayed loading code
@ 2022-01-31 21:05 ` Daniel Vetter
0 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-01-31 21:05 UTC (permalink / raw)
To: DRI Development
Cc: linux-fbdev, Du Cheng, Tetsuo Handa, Daniel Vetter,
Intel Graphics Development, LKML, Greg Kroah-Hartman,
Daniel Vetter, Helge Deller
Before
commit 6104c37094e729f3d4ce65797002112735d49cd1
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Tue Aug 1 17:32:07 2017 +0200
fbcon: Make fbcon a built-time depency for fbdev
it was possible to load fbcon and fbdev drivers in any order, which
means that fbcon init had to handle the case where fbdev drivers where
already registered.
This is no longer possible, hence delete that code.
Note that the exit case is a bit more complex and will be done in a
separate patch.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Helge Deller <deller@gmx.de>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Claudio Suarez <cssk@net-c.es>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Du Cheng <ducheng2@gmail.com>
---
drivers/video/fbdev/core/fbcon.c | 13 +------------
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 8f971de35885..814b648e8f09 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -942,7 +942,7 @@ static const char *fbcon_startup(void)
return display_desc;
/*
* Instead of blindly using registered_fb[0], we use info_idx, set by
- * fb_console_init();
+ * fbcon_fb_registered();
*/
info = registered_fb[info_idx];
if (!info)
@@ -3316,17 +3316,6 @@ static void fbcon_start(void)
return;
}
#endif
-
- if (num_registered_fb) {
- int i;
-
- for_each_registered_fb(i) {
- info_idx = i;
- break;
- }
-
- do_fbcon_takeover(0);
- }
}
static void fbcon_exit(void)
--
2.33.0
^ permalink raw reply related [flat|nested] 241+ messages in thread
* [PATCH 07/21] fbdev/sysfs: Fix locking
2022-01-31 21:05 ` Daniel Vetter
(?)
@ 2022-01-31 21:05 ` Daniel Vetter
-1 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-01-31 21:05 UTC (permalink / raw)
To: DRI Development
Cc: Intel Graphics Development, linux-fbdev, LKML, Daniel Vetter,
Daniel Vetter, Helge Deller, Daniel Vetter, Qing Wang,
Sam Ravnborg
fb_set_var requires we hold the fb_info lock. Or at least this now
matches what the ioctl does ...
Note that ps3fb and sh_mobile_lcdcfb are busted in different ways here,
but I will not fix them up.
Also in practice this isn't a big deal, because really variable fbdev
state is actually protected by console_lock (because fbcon just
doesn't bother with lock_fb_info() at all), and lock_fb_info
protecting anything is really just a neat lie. But that's a much
bigger fish to fry.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Helge Deller <deller@gmx.de>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Qing Wang <wangqing@vivo.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
---
drivers/video/fbdev/core/fbsysfs.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/video/fbdev/core/fbsysfs.c b/drivers/video/fbdev/core/fbsysfs.c
index 26892940c213..8c1ee9ecec3d 100644
--- a/drivers/video/fbdev/core/fbsysfs.c
+++ b/drivers/video/fbdev/core/fbsysfs.c
@@ -91,9 +91,11 @@ static int activate(struct fb_info *fb_info, struct fb_var_screeninfo *var)
var->activate |= FB_ACTIVATE_FORCE;
console_lock();
+ lock_fb_info(fb_info);
err = fb_set_var(fb_info, var);
if (!err)
fbcon_update_vcs(fb_info, var->activate & FB_ACTIVATE_ALL);
+ unlock_fb_info(fb_info);
console_unlock();
if (err)
return err;
--
2.33.0
^ permalink raw reply related [flat|nested] 241+ messages in thread
* [PATCH 07/21] fbdev/sysfs: Fix locking
@ 2022-01-31 21:05 ` Daniel Vetter
0 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-01-31 21:05 UTC (permalink / raw)
To: DRI Development
Cc: linux-fbdev, Daniel Vetter, Intel Graphics Development, LKML,
Qing Wang, Daniel Vetter, Sam Ravnborg, Helge Deller
fb_set_var requires we hold the fb_info lock. Or at least this now
matches what the ioctl does ...
Note that ps3fb and sh_mobile_lcdcfb are busted in different ways here,
but I will not fix them up.
Also in practice this isn't a big deal, because really variable fbdev
state is actually protected by console_lock (because fbcon just
doesn't bother with lock_fb_info() at all), and lock_fb_info
protecting anything is really just a neat lie. But that's a much
bigger fish to fry.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Helge Deller <deller@gmx.de>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Qing Wang <wangqing@vivo.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
---
drivers/video/fbdev/core/fbsysfs.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/video/fbdev/core/fbsysfs.c b/drivers/video/fbdev/core/fbsysfs.c
index 26892940c213..8c1ee9ecec3d 100644
--- a/drivers/video/fbdev/core/fbsysfs.c
+++ b/drivers/video/fbdev/core/fbsysfs.c
@@ -91,9 +91,11 @@ static int activate(struct fb_info *fb_info, struct fb_var_screeninfo *var)
var->activate |= FB_ACTIVATE_FORCE;
console_lock();
+ lock_fb_info(fb_info);
err = fb_set_var(fb_info, var);
if (!err)
fbcon_update_vcs(fb_info, var->activate & FB_ACTIVATE_ALL);
+ unlock_fb_info(fb_info);
console_unlock();
if (err)
return err;
--
2.33.0
^ permalink raw reply related [flat|nested] 241+ messages in thread
* [Intel-gfx] [PATCH 07/21] fbdev/sysfs: Fix locking
@ 2022-01-31 21:05 ` Daniel Vetter
0 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-01-31 21:05 UTC (permalink / raw)
To: DRI Development
Cc: linux-fbdev, Daniel Vetter, Intel Graphics Development, LKML,
Qing Wang, Daniel Vetter, Sam Ravnborg, Helge Deller
fb_set_var requires we hold the fb_info lock. Or at least this now
matches what the ioctl does ...
Note that ps3fb and sh_mobile_lcdcfb are busted in different ways here,
but I will not fix them up.
Also in practice this isn't a big deal, because really variable fbdev
state is actually protected by console_lock (because fbcon just
doesn't bother with lock_fb_info() at all), and lock_fb_info
protecting anything is really just a neat lie. But that's a much
bigger fish to fry.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Helge Deller <deller@gmx.de>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Qing Wang <wangqing@vivo.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
---
drivers/video/fbdev/core/fbsysfs.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/video/fbdev/core/fbsysfs.c b/drivers/video/fbdev/core/fbsysfs.c
index 26892940c213..8c1ee9ecec3d 100644
--- a/drivers/video/fbdev/core/fbsysfs.c
+++ b/drivers/video/fbdev/core/fbsysfs.c
@@ -91,9 +91,11 @@ static int activate(struct fb_info *fb_info, struct fb_var_screeninfo *var)
var->activate |= FB_ACTIVATE_FORCE;
console_lock();
+ lock_fb_info(fb_info);
err = fb_set_var(fb_info, var);
if (!err)
fbcon_update_vcs(fb_info, var->activate & FB_ACTIVATE_ALL);
+ unlock_fb_info(fb_info);
console_unlock();
if (err)
return err;
--
2.33.0
^ permalink raw reply related [flat|nested] 241+ messages in thread
* [PATCH 08/21] fbcon: Use delayed work for cursor
2022-01-31 21:05 ` Daniel Vetter
(?)
@ 2022-01-31 21:05 ` Daniel Vetter
-1 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-01-31 21:05 UTC (permalink / raw)
To: DRI Development
Cc: Intel Graphics Development, linux-fbdev, LKML, Daniel Vetter,
Daniel Vetter, Daniel Vetter, Claudio Suarez, Du Cheng,
Thomas Zimmermann, Greg Kroah-Hartman, Tetsuo Handa
Allows us to delete a bunch of hand-rolled stuff. Also to simplify the
code we initialize the cursor_work completely when we allocate the
fbcon_ops structure, instead of trying to cope with console
re-initialization.
The motiviation here is that fbcon code stops using the fb_info.queue,
which helps with locking issues around cleanup and all that in a later
patch.
Also note that this allows us to ditch the hand-rolled work cleanup in
fbcon_exit - we already call fbcon_del_cursor_timer, which takes care
of everything. Plus this was racy anyway.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Claudio Suarez <cssk@net-c.es>
Cc: Du Cheng <ducheng2@gmail.com>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
---
drivers/video/fbdev/core/fbcon.c | 85 +++++++++++++-------------------
drivers/video/fbdev/core/fbcon.h | 4 +-
2 files changed, 35 insertions(+), 54 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 814b648e8f09..affb40658fee 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -348,8 +348,8 @@ static int get_color(struct vc_data *vc, struct fb_info *info,
static void fb_flashcursor(struct work_struct *work)
{
- struct fb_info *info = container_of(work, struct fb_info, queue);
- struct fbcon_ops *ops = info->fbcon_par;
+ struct fbcon_ops *ops = container_of(work, struct fbcon_ops, cursor_work.work);
+ struct fb_info *info;
struct vc_data *vc = NULL;
int c;
int mode;
@@ -362,7 +362,10 @@ static void fb_flashcursor(struct work_struct *work)
if (ret == 0)
return;
- if (ops && ops->currcon != -1)
+ /* protected by console_lock */
+ info = ops->info;
+
+ if (ops->currcon != -1)
vc = vc_cons[ops->currcon].d;
if (!vc || !con_is_visible(vc) ||
@@ -378,42 +381,25 @@ static void fb_flashcursor(struct work_struct *work)
ops->cursor(vc, info, mode, get_color(vc, info, c, 1),
get_color(vc, info, c, 0));
console_unlock();
-}
-static void cursor_timer_handler(struct timer_list *t)
-{
- struct fbcon_ops *ops = from_timer(ops, t, cursor_timer);
- struct fb_info *info = ops->info;
-
- queue_work(system_power_efficient_wq, &info->queue);
- mod_timer(&ops->cursor_timer, jiffies + ops->cur_blink_jiffies);
+ queue_delayed_work(system_power_efficient_wq, &ops->cursor_work,
+ ops->cur_blink_jiffies);
}
-static void fbcon_add_cursor_timer(struct fb_info *info)
+static void fbcon_add_cursor_work(struct fb_info *info)
{
struct fbcon_ops *ops = info->fbcon_par;
- if ((!info->queue.func || info->queue.func == fb_flashcursor) &&
- !(ops->flags & FBCON_FLAGS_CURSOR_TIMER) &&
- !fbcon_cursor_noblink) {
- if (!info->queue.func)
- INIT_WORK(&info->queue, fb_flashcursor);
-
- timer_setup(&ops->cursor_timer, cursor_timer_handler, 0);
- mod_timer(&ops->cursor_timer, jiffies + ops->cur_blink_jiffies);
- ops->flags |= FBCON_FLAGS_CURSOR_TIMER;
- }
+ if (!fbcon_cursor_noblink)
+ queue_delayed_work(system_power_efficient_wq, &ops->cursor_work,
+ ops->cur_blink_jiffies);
}
-static void fbcon_del_cursor_timer(struct fb_info *info)
+static void fbcon_del_cursor_work(struct fb_info *info)
{
struct fbcon_ops *ops = info->fbcon_par;
- if (info->queue.func == fb_flashcursor &&
- ops->flags & FBCON_FLAGS_CURSOR_TIMER) {
- del_timer_sync(&ops->cursor_timer);
- ops->flags &= ~FBCON_FLAGS_CURSOR_TIMER;
- }
+ cancel_delayed_work_sync(&ops->cursor_work);
}
#ifndef MODULE
@@ -712,6 +698,8 @@ static int con2fb_acquire_newinfo(struct vc_data *vc, struct fb_info *info,
ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL);
if (!ops)
err = -ENOMEM;
+
+ INIT_DELAYED_WORK(&ops->cursor_work, fb_flashcursor);
}
if (!err) {
@@ -749,7 +737,7 @@ static int con2fb_release_oldinfo(struct vc_data *vc, struct fb_info *oldinfo,
}
if (!err) {
- fbcon_del_cursor_timer(oldinfo);
+ fbcon_del_cursor_work(oldinfo);
kfree(ops->cursor_state.mask);
kfree(ops->cursor_data);
kfree(ops->cursor_src);
@@ -865,7 +853,7 @@ static int set_con2fb_map(int unit, int newidx, int user)
logo_shown != FBCON_LOGO_DONTSHOW);
if (!found)
- fbcon_add_cursor_timer(info);
+ fbcon_add_cursor_work(info);
con2fb_map_boot[unit] = newidx;
con2fb_init_display(vc, info, unit, show_logo);
}
@@ -962,6 +950,8 @@ static const char *fbcon_startup(void)
return NULL;
}
+ INIT_DELAYED_WORK(&ops->cursor_work, fb_flashcursor);
+
ops->currcon = -1;
ops->graphics = 1;
ops->cur_rotate = -1;
@@ -1004,7 +994,7 @@ static const char *fbcon_startup(void)
info->var.yres,
info->var.bits_per_pixel);
- fbcon_add_cursor_timer(info);
+ fbcon_add_cursor_work(info);
return display_desc;
}
@@ -1194,7 +1184,7 @@ static void fbcon_deinit(struct vc_data *vc)
goto finished;
if (con_is_visible(vc))
- fbcon_del_cursor_timer(info);
+ fbcon_del_cursor_work(info);
ops->flags &= ~FBCON_FLAGS_INIT;
finished:
@@ -1320,9 +1310,9 @@ static void fbcon_cursor(struct vc_data *vc, int mode)
return;
if (vc->vc_cursor_type & CUR_SW)
- fbcon_del_cursor_timer(info);
+ fbcon_del_cursor_work(info);
else
- fbcon_add_cursor_timer(info);
+ fbcon_add_cursor_work(info);
ops->cursor_flash = (mode == CM_ERASE) ? 0 : 1;
@@ -2149,14 +2139,14 @@ static int fbcon_switch(struct vc_data *vc)
}
if (old_info != info)
- fbcon_del_cursor_timer(old_info);
+ fbcon_del_cursor_work(old_info);
}
if (fbcon_is_inactive(vc, info) ||
ops->blank_state != FB_BLANK_UNBLANK)
- fbcon_del_cursor_timer(info);
+ fbcon_del_cursor_work(info);
else
- fbcon_add_cursor_timer(info);
+ fbcon_add_cursor_work(info);
set_blitting_type(vc, info);
ops->cursor_reset = 1;
@@ -2264,9 +2254,9 @@ static int fbcon_blank(struct vc_data *vc, int blank, int mode_switch)
if (mode_switch || fbcon_is_inactive(vc, info) ||
ops->blank_state != FB_BLANK_UNBLANK)
- fbcon_del_cursor_timer(info);
+ fbcon_del_cursor_work(info);
else
- fbcon_add_cursor_timer(info);
+ fbcon_add_cursor_work(info);
return 0;
}
@@ -3198,7 +3188,7 @@ static ssize_t show_cursor_blink(struct device *device,
if (!ops)
goto err;
- blink = (ops->flags & FBCON_FLAGS_CURSOR_TIMER) ? 1 : 0;
+ blink = delayed_work_pending(&ops->cursor_work);
err:
console_unlock();
return snprintf(buf, PAGE_SIZE, "%d\n", blink);
@@ -3227,10 +3217,10 @@ static ssize_t store_cursor_blink(struct device *device,
if (blink) {
fbcon_cursor_noblink = 0;
- fbcon_add_cursor_timer(info);
+ fbcon_add_cursor_work(info);
} else {
fbcon_cursor_noblink = 1;
- fbcon_del_cursor_timer(info);
+ fbcon_del_cursor_work(info);
}
err:
@@ -3331,15 +3321,9 @@ static void fbcon_exit(void)
#endif
for_each_registered_fb(i) {
- int pending = 0;
-
mapped = 0;
info = registered_fb[i];
- if (info->queue.func)
- pending = cancel_work_sync(&info->queue);
- pr_debug("fbcon: %s pending work\n", (pending ? "canceled" : "no"));
-
for (j = first_fb_vc; j <= last_fb_vc; j++) {
if (con2fb_map[j] == i) {
mapped = 1;
@@ -3355,15 +3339,12 @@ static void fbcon_exit(void)
if (info->fbcon_par) {
struct fbcon_ops *ops = info->fbcon_par;
- fbcon_del_cursor_timer(info);
+ fbcon_del_cursor_work(info);
kfree(ops->cursor_src);
kfree(ops->cursor_state.mask);
kfree(info->fbcon_par);
info->fbcon_par = NULL;
}
-
- if (info->queue.func == fb_flashcursor)
- info->queue.func = NULL;
}
}
}
diff --git a/drivers/video/fbdev/core/fbcon.h b/drivers/video/fbdev/core/fbcon.h
index 5246d0f2574b..dce5ce41093e 100644
--- a/drivers/video/fbdev/core/fbcon.h
+++ b/drivers/video/fbdev/core/fbcon.h
@@ -14,11 +14,11 @@
#include <linux/types.h>
#include <linux/vt_buffer.h>
#include <linux/vt_kern.h>
+#include <linux/workqueue.h>
#include <asm/io.h>
#define FBCON_FLAGS_INIT 1
-#define FBCON_FLAGS_CURSOR_TIMER 2
/*
* This is the interface between the low-level console driver and the
@@ -66,7 +66,7 @@ struct fbcon_ops {
int (*update_start)(struct fb_info *info);
int (*rotate_font)(struct fb_info *info, struct vc_data *vc);
struct fb_var_screeninfo var; /* copy of the current fb_var_screeninfo */
- struct timer_list cursor_timer; /* Cursor timer */
+ struct delayed_work cursor_work; /* Cursor timer */
struct fb_cursor cursor_state;
struct fbcon_display *p;
struct fb_info *info;
--
2.33.0
^ permalink raw reply related [flat|nested] 241+ messages in thread
* [PATCH 08/21] fbcon: Use delayed work for cursor
@ 2022-01-31 21:05 ` Daniel Vetter
0 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-01-31 21:05 UTC (permalink / raw)
To: DRI Development
Cc: linux-fbdev, Thomas Zimmermann, Du Cheng, Tetsuo Handa,
Daniel Vetter, Intel Graphics Development, LKML, Claudio Suarez,
Greg Kroah-Hartman, Daniel Vetter
Allows us to delete a bunch of hand-rolled stuff. Also to simplify the
code we initialize the cursor_work completely when we allocate the
fbcon_ops structure, instead of trying to cope with console
re-initialization.
The motiviation here is that fbcon code stops using the fb_info.queue,
which helps with locking issues around cleanup and all that in a later
patch.
Also note that this allows us to ditch the hand-rolled work cleanup in
fbcon_exit - we already call fbcon_del_cursor_timer, which takes care
of everything. Plus this was racy anyway.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Claudio Suarez <cssk@net-c.es>
Cc: Du Cheng <ducheng2@gmail.com>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
---
drivers/video/fbdev/core/fbcon.c | 85 +++++++++++++-------------------
drivers/video/fbdev/core/fbcon.h | 4 +-
2 files changed, 35 insertions(+), 54 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 814b648e8f09..affb40658fee 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -348,8 +348,8 @@ static int get_color(struct vc_data *vc, struct fb_info *info,
static void fb_flashcursor(struct work_struct *work)
{
- struct fb_info *info = container_of(work, struct fb_info, queue);
- struct fbcon_ops *ops = info->fbcon_par;
+ struct fbcon_ops *ops = container_of(work, struct fbcon_ops, cursor_work.work);
+ struct fb_info *info;
struct vc_data *vc = NULL;
int c;
int mode;
@@ -362,7 +362,10 @@ static void fb_flashcursor(struct work_struct *work)
if (ret == 0)
return;
- if (ops && ops->currcon != -1)
+ /* protected by console_lock */
+ info = ops->info;
+
+ if (ops->currcon != -1)
vc = vc_cons[ops->currcon].d;
if (!vc || !con_is_visible(vc) ||
@@ -378,42 +381,25 @@ static void fb_flashcursor(struct work_struct *work)
ops->cursor(vc, info, mode, get_color(vc, info, c, 1),
get_color(vc, info, c, 0));
console_unlock();
-}
-static void cursor_timer_handler(struct timer_list *t)
-{
- struct fbcon_ops *ops = from_timer(ops, t, cursor_timer);
- struct fb_info *info = ops->info;
-
- queue_work(system_power_efficient_wq, &info->queue);
- mod_timer(&ops->cursor_timer, jiffies + ops->cur_blink_jiffies);
+ queue_delayed_work(system_power_efficient_wq, &ops->cursor_work,
+ ops->cur_blink_jiffies);
}
-static void fbcon_add_cursor_timer(struct fb_info *info)
+static void fbcon_add_cursor_work(struct fb_info *info)
{
struct fbcon_ops *ops = info->fbcon_par;
- if ((!info->queue.func || info->queue.func == fb_flashcursor) &&
- !(ops->flags & FBCON_FLAGS_CURSOR_TIMER) &&
- !fbcon_cursor_noblink) {
- if (!info->queue.func)
- INIT_WORK(&info->queue, fb_flashcursor);
-
- timer_setup(&ops->cursor_timer, cursor_timer_handler, 0);
- mod_timer(&ops->cursor_timer, jiffies + ops->cur_blink_jiffies);
- ops->flags |= FBCON_FLAGS_CURSOR_TIMER;
- }
+ if (!fbcon_cursor_noblink)
+ queue_delayed_work(system_power_efficient_wq, &ops->cursor_work,
+ ops->cur_blink_jiffies);
}
-static void fbcon_del_cursor_timer(struct fb_info *info)
+static void fbcon_del_cursor_work(struct fb_info *info)
{
struct fbcon_ops *ops = info->fbcon_par;
- if (info->queue.func == fb_flashcursor &&
- ops->flags & FBCON_FLAGS_CURSOR_TIMER) {
- del_timer_sync(&ops->cursor_timer);
- ops->flags &= ~FBCON_FLAGS_CURSOR_TIMER;
- }
+ cancel_delayed_work_sync(&ops->cursor_work);
}
#ifndef MODULE
@@ -712,6 +698,8 @@ static int con2fb_acquire_newinfo(struct vc_data *vc, struct fb_info *info,
ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL);
if (!ops)
err = -ENOMEM;
+
+ INIT_DELAYED_WORK(&ops->cursor_work, fb_flashcursor);
}
if (!err) {
@@ -749,7 +737,7 @@ static int con2fb_release_oldinfo(struct vc_data *vc, struct fb_info *oldinfo,
}
if (!err) {
- fbcon_del_cursor_timer(oldinfo);
+ fbcon_del_cursor_work(oldinfo);
kfree(ops->cursor_state.mask);
kfree(ops->cursor_data);
kfree(ops->cursor_src);
@@ -865,7 +853,7 @@ static int set_con2fb_map(int unit, int newidx, int user)
logo_shown != FBCON_LOGO_DONTSHOW);
if (!found)
- fbcon_add_cursor_timer(info);
+ fbcon_add_cursor_work(info);
con2fb_map_boot[unit] = newidx;
con2fb_init_display(vc, info, unit, show_logo);
}
@@ -962,6 +950,8 @@ static const char *fbcon_startup(void)
return NULL;
}
+ INIT_DELAYED_WORK(&ops->cursor_work, fb_flashcursor);
+
ops->currcon = -1;
ops->graphics = 1;
ops->cur_rotate = -1;
@@ -1004,7 +994,7 @@ static const char *fbcon_startup(void)
info->var.yres,
info->var.bits_per_pixel);
- fbcon_add_cursor_timer(info);
+ fbcon_add_cursor_work(info);
return display_desc;
}
@@ -1194,7 +1184,7 @@ static void fbcon_deinit(struct vc_data *vc)
goto finished;
if (con_is_visible(vc))
- fbcon_del_cursor_timer(info);
+ fbcon_del_cursor_work(info);
ops->flags &= ~FBCON_FLAGS_INIT;
finished:
@@ -1320,9 +1310,9 @@ static void fbcon_cursor(struct vc_data *vc, int mode)
return;
if (vc->vc_cursor_type & CUR_SW)
- fbcon_del_cursor_timer(info);
+ fbcon_del_cursor_work(info);
else
- fbcon_add_cursor_timer(info);
+ fbcon_add_cursor_work(info);
ops->cursor_flash = (mode == CM_ERASE) ? 0 : 1;
@@ -2149,14 +2139,14 @@ static int fbcon_switch(struct vc_data *vc)
}
if (old_info != info)
- fbcon_del_cursor_timer(old_info);
+ fbcon_del_cursor_work(old_info);
}
if (fbcon_is_inactive(vc, info) ||
ops->blank_state != FB_BLANK_UNBLANK)
- fbcon_del_cursor_timer(info);
+ fbcon_del_cursor_work(info);
else
- fbcon_add_cursor_timer(info);
+ fbcon_add_cursor_work(info);
set_blitting_type(vc, info);
ops->cursor_reset = 1;
@@ -2264,9 +2254,9 @@ static int fbcon_blank(struct vc_data *vc, int blank, int mode_switch)
if (mode_switch || fbcon_is_inactive(vc, info) ||
ops->blank_state != FB_BLANK_UNBLANK)
- fbcon_del_cursor_timer(info);
+ fbcon_del_cursor_work(info);
else
- fbcon_add_cursor_timer(info);
+ fbcon_add_cursor_work(info);
return 0;
}
@@ -3198,7 +3188,7 @@ static ssize_t show_cursor_blink(struct device *device,
if (!ops)
goto err;
- blink = (ops->flags & FBCON_FLAGS_CURSOR_TIMER) ? 1 : 0;
+ blink = delayed_work_pending(&ops->cursor_work);
err:
console_unlock();
return snprintf(buf, PAGE_SIZE, "%d\n", blink);
@@ -3227,10 +3217,10 @@ static ssize_t store_cursor_blink(struct device *device,
if (blink) {
fbcon_cursor_noblink = 0;
- fbcon_add_cursor_timer(info);
+ fbcon_add_cursor_work(info);
} else {
fbcon_cursor_noblink = 1;
- fbcon_del_cursor_timer(info);
+ fbcon_del_cursor_work(info);
}
err:
@@ -3331,15 +3321,9 @@ static void fbcon_exit(void)
#endif
for_each_registered_fb(i) {
- int pending = 0;
-
mapped = 0;
info = registered_fb[i];
- if (info->queue.func)
- pending = cancel_work_sync(&info->queue);
- pr_debug("fbcon: %s pending work\n", (pending ? "canceled" : "no"));
-
for (j = first_fb_vc; j <= last_fb_vc; j++) {
if (con2fb_map[j] == i) {
mapped = 1;
@@ -3355,15 +3339,12 @@ static void fbcon_exit(void)
if (info->fbcon_par) {
struct fbcon_ops *ops = info->fbcon_par;
- fbcon_del_cursor_timer(info);
+ fbcon_del_cursor_work(info);
kfree(ops->cursor_src);
kfree(ops->cursor_state.mask);
kfree(info->fbcon_par);
info->fbcon_par = NULL;
}
-
- if (info->queue.func == fb_flashcursor)
- info->queue.func = NULL;
}
}
}
diff --git a/drivers/video/fbdev/core/fbcon.h b/drivers/video/fbdev/core/fbcon.h
index 5246d0f2574b..dce5ce41093e 100644
--- a/drivers/video/fbdev/core/fbcon.h
+++ b/drivers/video/fbdev/core/fbcon.h
@@ -14,11 +14,11 @@
#include <linux/types.h>
#include <linux/vt_buffer.h>
#include <linux/vt_kern.h>
+#include <linux/workqueue.h>
#include <asm/io.h>
#define FBCON_FLAGS_INIT 1
-#define FBCON_FLAGS_CURSOR_TIMER 2
/*
* This is the interface between the low-level console driver and the
@@ -66,7 +66,7 @@ struct fbcon_ops {
int (*update_start)(struct fb_info *info);
int (*rotate_font)(struct fb_info *info, struct vc_data *vc);
struct fb_var_screeninfo var; /* copy of the current fb_var_screeninfo */
- struct timer_list cursor_timer; /* Cursor timer */
+ struct delayed_work cursor_work; /* Cursor timer */
struct fb_cursor cursor_state;
struct fbcon_display *p;
struct fb_info *info;
--
2.33.0
^ permalink raw reply related [flat|nested] 241+ messages in thread
* [Intel-gfx] [PATCH 08/21] fbcon: Use delayed work for cursor
@ 2022-01-31 21:05 ` Daniel Vetter
0 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-01-31 21:05 UTC (permalink / raw)
To: DRI Development
Cc: linux-fbdev, Thomas Zimmermann, Du Cheng, Tetsuo Handa,
Daniel Vetter, Intel Graphics Development, LKML,
Greg Kroah-Hartman, Daniel Vetter
Allows us to delete a bunch of hand-rolled stuff. Also to simplify the
code we initialize the cursor_work completely when we allocate the
fbcon_ops structure, instead of trying to cope with console
re-initialization.
The motiviation here is that fbcon code stops using the fb_info.queue,
which helps with locking issues around cleanup and all that in a later
patch.
Also note that this allows us to ditch the hand-rolled work cleanup in
fbcon_exit - we already call fbcon_del_cursor_timer, which takes care
of everything. Plus this was racy anyway.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Claudio Suarez <cssk@net-c.es>
Cc: Du Cheng <ducheng2@gmail.com>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
---
drivers/video/fbdev/core/fbcon.c | 85 +++++++++++++-------------------
drivers/video/fbdev/core/fbcon.h | 4 +-
2 files changed, 35 insertions(+), 54 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 814b648e8f09..affb40658fee 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -348,8 +348,8 @@ static int get_color(struct vc_data *vc, struct fb_info *info,
static void fb_flashcursor(struct work_struct *work)
{
- struct fb_info *info = container_of(work, struct fb_info, queue);
- struct fbcon_ops *ops = info->fbcon_par;
+ struct fbcon_ops *ops = container_of(work, struct fbcon_ops, cursor_work.work);
+ struct fb_info *info;
struct vc_data *vc = NULL;
int c;
int mode;
@@ -362,7 +362,10 @@ static void fb_flashcursor(struct work_struct *work)
if (ret == 0)
return;
- if (ops && ops->currcon != -1)
+ /* protected by console_lock */
+ info = ops->info;
+
+ if (ops->currcon != -1)
vc = vc_cons[ops->currcon].d;
if (!vc || !con_is_visible(vc) ||
@@ -378,42 +381,25 @@ static void fb_flashcursor(struct work_struct *work)
ops->cursor(vc, info, mode, get_color(vc, info, c, 1),
get_color(vc, info, c, 0));
console_unlock();
-}
-static void cursor_timer_handler(struct timer_list *t)
-{
- struct fbcon_ops *ops = from_timer(ops, t, cursor_timer);
- struct fb_info *info = ops->info;
-
- queue_work(system_power_efficient_wq, &info->queue);
- mod_timer(&ops->cursor_timer, jiffies + ops->cur_blink_jiffies);
+ queue_delayed_work(system_power_efficient_wq, &ops->cursor_work,
+ ops->cur_blink_jiffies);
}
-static void fbcon_add_cursor_timer(struct fb_info *info)
+static void fbcon_add_cursor_work(struct fb_info *info)
{
struct fbcon_ops *ops = info->fbcon_par;
- if ((!info->queue.func || info->queue.func == fb_flashcursor) &&
- !(ops->flags & FBCON_FLAGS_CURSOR_TIMER) &&
- !fbcon_cursor_noblink) {
- if (!info->queue.func)
- INIT_WORK(&info->queue, fb_flashcursor);
-
- timer_setup(&ops->cursor_timer, cursor_timer_handler, 0);
- mod_timer(&ops->cursor_timer, jiffies + ops->cur_blink_jiffies);
- ops->flags |= FBCON_FLAGS_CURSOR_TIMER;
- }
+ if (!fbcon_cursor_noblink)
+ queue_delayed_work(system_power_efficient_wq, &ops->cursor_work,
+ ops->cur_blink_jiffies);
}
-static void fbcon_del_cursor_timer(struct fb_info *info)
+static void fbcon_del_cursor_work(struct fb_info *info)
{
struct fbcon_ops *ops = info->fbcon_par;
- if (info->queue.func == fb_flashcursor &&
- ops->flags & FBCON_FLAGS_CURSOR_TIMER) {
- del_timer_sync(&ops->cursor_timer);
- ops->flags &= ~FBCON_FLAGS_CURSOR_TIMER;
- }
+ cancel_delayed_work_sync(&ops->cursor_work);
}
#ifndef MODULE
@@ -712,6 +698,8 @@ static int con2fb_acquire_newinfo(struct vc_data *vc, struct fb_info *info,
ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL);
if (!ops)
err = -ENOMEM;
+
+ INIT_DELAYED_WORK(&ops->cursor_work, fb_flashcursor);
}
if (!err) {
@@ -749,7 +737,7 @@ static int con2fb_release_oldinfo(struct vc_data *vc, struct fb_info *oldinfo,
}
if (!err) {
- fbcon_del_cursor_timer(oldinfo);
+ fbcon_del_cursor_work(oldinfo);
kfree(ops->cursor_state.mask);
kfree(ops->cursor_data);
kfree(ops->cursor_src);
@@ -865,7 +853,7 @@ static int set_con2fb_map(int unit, int newidx, int user)
logo_shown != FBCON_LOGO_DONTSHOW);
if (!found)
- fbcon_add_cursor_timer(info);
+ fbcon_add_cursor_work(info);
con2fb_map_boot[unit] = newidx;
con2fb_init_display(vc, info, unit, show_logo);
}
@@ -962,6 +950,8 @@ static const char *fbcon_startup(void)
return NULL;
}
+ INIT_DELAYED_WORK(&ops->cursor_work, fb_flashcursor);
+
ops->currcon = -1;
ops->graphics = 1;
ops->cur_rotate = -1;
@@ -1004,7 +994,7 @@ static const char *fbcon_startup(void)
info->var.yres,
info->var.bits_per_pixel);
- fbcon_add_cursor_timer(info);
+ fbcon_add_cursor_work(info);
return display_desc;
}
@@ -1194,7 +1184,7 @@ static void fbcon_deinit(struct vc_data *vc)
goto finished;
if (con_is_visible(vc))
- fbcon_del_cursor_timer(info);
+ fbcon_del_cursor_work(info);
ops->flags &= ~FBCON_FLAGS_INIT;
finished:
@@ -1320,9 +1310,9 @@ static void fbcon_cursor(struct vc_data *vc, int mode)
return;
if (vc->vc_cursor_type & CUR_SW)
- fbcon_del_cursor_timer(info);
+ fbcon_del_cursor_work(info);
else
- fbcon_add_cursor_timer(info);
+ fbcon_add_cursor_work(info);
ops->cursor_flash = (mode == CM_ERASE) ? 0 : 1;
@@ -2149,14 +2139,14 @@ static int fbcon_switch(struct vc_data *vc)
}
if (old_info != info)
- fbcon_del_cursor_timer(old_info);
+ fbcon_del_cursor_work(old_info);
}
if (fbcon_is_inactive(vc, info) ||
ops->blank_state != FB_BLANK_UNBLANK)
- fbcon_del_cursor_timer(info);
+ fbcon_del_cursor_work(info);
else
- fbcon_add_cursor_timer(info);
+ fbcon_add_cursor_work(info);
set_blitting_type(vc, info);
ops->cursor_reset = 1;
@@ -2264,9 +2254,9 @@ static int fbcon_blank(struct vc_data *vc, int blank, int mode_switch)
if (mode_switch || fbcon_is_inactive(vc, info) ||
ops->blank_state != FB_BLANK_UNBLANK)
- fbcon_del_cursor_timer(info);
+ fbcon_del_cursor_work(info);
else
- fbcon_add_cursor_timer(info);
+ fbcon_add_cursor_work(info);
return 0;
}
@@ -3198,7 +3188,7 @@ static ssize_t show_cursor_blink(struct device *device,
if (!ops)
goto err;
- blink = (ops->flags & FBCON_FLAGS_CURSOR_TIMER) ? 1 : 0;
+ blink = delayed_work_pending(&ops->cursor_work);
err:
console_unlock();
return snprintf(buf, PAGE_SIZE, "%d\n", blink);
@@ -3227,10 +3217,10 @@ static ssize_t store_cursor_blink(struct device *device,
if (blink) {
fbcon_cursor_noblink = 0;
- fbcon_add_cursor_timer(info);
+ fbcon_add_cursor_work(info);
} else {
fbcon_cursor_noblink = 1;
- fbcon_del_cursor_timer(info);
+ fbcon_del_cursor_work(info);
}
err:
@@ -3331,15 +3321,9 @@ static void fbcon_exit(void)
#endif
for_each_registered_fb(i) {
- int pending = 0;
-
mapped = 0;
info = registered_fb[i];
- if (info->queue.func)
- pending = cancel_work_sync(&info->queue);
- pr_debug("fbcon: %s pending work\n", (pending ? "canceled" : "no"));
-
for (j = first_fb_vc; j <= last_fb_vc; j++) {
if (con2fb_map[j] == i) {
mapped = 1;
@@ -3355,15 +3339,12 @@ static void fbcon_exit(void)
if (info->fbcon_par) {
struct fbcon_ops *ops = info->fbcon_par;
- fbcon_del_cursor_timer(info);
+ fbcon_del_cursor_work(info);
kfree(ops->cursor_src);
kfree(ops->cursor_state.mask);
kfree(info->fbcon_par);
info->fbcon_par = NULL;
}
-
- if (info->queue.func == fb_flashcursor)
- info->queue.func = NULL;
}
}
}
diff --git a/drivers/video/fbdev/core/fbcon.h b/drivers/video/fbdev/core/fbcon.h
index 5246d0f2574b..dce5ce41093e 100644
--- a/drivers/video/fbdev/core/fbcon.h
+++ b/drivers/video/fbdev/core/fbcon.h
@@ -14,11 +14,11 @@
#include <linux/types.h>
#include <linux/vt_buffer.h>
#include <linux/vt_kern.h>
+#include <linux/workqueue.h>
#include <asm/io.h>
#define FBCON_FLAGS_INIT 1
-#define FBCON_FLAGS_CURSOR_TIMER 2
/*
* This is the interface between the low-level console driver and the
@@ -66,7 +66,7 @@ struct fbcon_ops {
int (*update_start)(struct fb_info *info);
int (*rotate_font)(struct fb_info *info, struct vc_data *vc);
struct fb_var_screeninfo var; /* copy of the current fb_var_screeninfo */
- struct timer_list cursor_timer; /* Cursor timer */
+ struct delayed_work cursor_work; /* Cursor timer */
struct fb_cursor cursor_state;
struct fbcon_display *p;
struct fb_info *info;
--
2.33.0
^ permalink raw reply related [flat|nested] 241+ messages in thread
* [PATCH 09/21] fbcon: Replace FBCON_FLAGS_INIT with a boolean
2022-01-31 21:05 ` Daniel Vetter
(?)
@ 2022-01-31 21:05 ` Daniel Vetter
-1 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-01-31 21:05 UTC (permalink / raw)
To: DRI Development
Cc: Intel Graphics Development, linux-fbdev, LKML, Daniel Vetter,
Daniel Vetter, Daniel Vetter, Tetsuo Handa, Greg Kroah-Hartman,
Du Cheng, Thomas Zimmermann, Claudio Suarez
It's only one flag and slightly tidier code.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Du Cheng <ducheng2@gmail.com>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Claudio Suarez <cssk@net-c.es>
---
drivers/video/fbdev/core/fbcon.c | 11 +++++------
drivers/video/fbdev/core/fbcon.h | 4 +---
2 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index affb40658fee..fa30e1909164 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -773,7 +773,7 @@ static void con2fb_init_display(struct vc_data *vc, struct fb_info *info,
ops->currcon = fg_console;
- if (info->fbops->fb_set_par && !(ops->flags & FBCON_FLAGS_INIT)) {
+ if (info->fbops->fb_set_par && !ops->initialized) {
ret = info->fbops->fb_set_par(info);
if (ret)
@@ -782,7 +782,7 @@ static void con2fb_init_display(struct vc_data *vc, struct fb_info *info,
"error code %d\n", ret);
}
- ops->flags |= FBCON_FLAGS_INIT;
+ ops->initialized = true;
ops->graphics = 0;
fbcon_set_disp(info, &info->var, unit);
@@ -1101,8 +1101,7 @@ static void fbcon_init(struct vc_data *vc, int init)
* We need to do it in fbcon_init() to prevent screen corruption.
*/
if (con_is_visible(vc) && vc->vc_mode == KD_TEXT) {
- if (info->fbops->fb_set_par &&
- !(ops->flags & FBCON_FLAGS_INIT)) {
+ if (info->fbops->fb_set_par && !ops->initialized) {
ret = info->fbops->fb_set_par(info);
if (ret)
@@ -1111,7 +1110,7 @@ static void fbcon_init(struct vc_data *vc, int init)
"error code %d\n", ret);
}
- ops->flags |= FBCON_FLAGS_INIT;
+ ops->initialized = true;
}
ops->graphics = 0;
@@ -1186,7 +1185,7 @@ static void fbcon_deinit(struct vc_data *vc)
if (con_is_visible(vc))
fbcon_del_cursor_work(info);
- ops->flags &= ~FBCON_FLAGS_INIT;
+ ops->initialized = false;
finished:
fbcon_free_font(p, free_font);
diff --git a/drivers/video/fbdev/core/fbcon.h b/drivers/video/fbdev/core/fbcon.h
index dce5ce41093e..b18d0cbf73b6 100644
--- a/drivers/video/fbdev/core/fbcon.h
+++ b/drivers/video/fbdev/core/fbcon.h
@@ -18,8 +18,6 @@
#include <asm/io.h>
-#define FBCON_FLAGS_INIT 1
-
/*
* This is the interface between the low-level console driver and the
* low-level frame buffer device
@@ -77,7 +75,7 @@ struct fbcon_ops {
int blank_state;
int graphics;
int save_graphics; /* for debug enter/leave */
- int flags;
+ bool initialized;
int rotate;
int cur_rotate;
char *cursor_data;
--
2.33.0
^ permalink raw reply related [flat|nested] 241+ messages in thread
* [PATCH 09/21] fbcon: Replace FBCON_FLAGS_INIT with a boolean
@ 2022-01-31 21:05 ` Daniel Vetter
0 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-01-31 21:05 UTC (permalink / raw)
To: DRI Development
Cc: linux-fbdev, Thomas Zimmermann, Du Cheng, Tetsuo Handa,
Daniel Vetter, Intel Graphics Development, LKML, Claudio Suarez,
Greg Kroah-Hartman, Daniel Vetter
It's only one flag and slightly tidier code.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Du Cheng <ducheng2@gmail.com>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Claudio Suarez <cssk@net-c.es>
---
drivers/video/fbdev/core/fbcon.c | 11 +++++------
drivers/video/fbdev/core/fbcon.h | 4 +---
2 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index affb40658fee..fa30e1909164 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -773,7 +773,7 @@ static void con2fb_init_display(struct vc_data *vc, struct fb_info *info,
ops->currcon = fg_console;
- if (info->fbops->fb_set_par && !(ops->flags & FBCON_FLAGS_INIT)) {
+ if (info->fbops->fb_set_par && !ops->initialized) {
ret = info->fbops->fb_set_par(info);
if (ret)
@@ -782,7 +782,7 @@ static void con2fb_init_display(struct vc_data *vc, struct fb_info *info,
"error code %d\n", ret);
}
- ops->flags |= FBCON_FLAGS_INIT;
+ ops->initialized = true;
ops->graphics = 0;
fbcon_set_disp(info, &info->var, unit);
@@ -1101,8 +1101,7 @@ static void fbcon_init(struct vc_data *vc, int init)
* We need to do it in fbcon_init() to prevent screen corruption.
*/
if (con_is_visible(vc) && vc->vc_mode == KD_TEXT) {
- if (info->fbops->fb_set_par &&
- !(ops->flags & FBCON_FLAGS_INIT)) {
+ if (info->fbops->fb_set_par && !ops->initialized) {
ret = info->fbops->fb_set_par(info);
if (ret)
@@ -1111,7 +1110,7 @@ static void fbcon_init(struct vc_data *vc, int init)
"error code %d\n", ret);
}
- ops->flags |= FBCON_FLAGS_INIT;
+ ops->initialized = true;
}
ops->graphics = 0;
@@ -1186,7 +1185,7 @@ static void fbcon_deinit(struct vc_data *vc)
if (con_is_visible(vc))
fbcon_del_cursor_work(info);
- ops->flags &= ~FBCON_FLAGS_INIT;
+ ops->initialized = false;
finished:
fbcon_free_font(p, free_font);
diff --git a/drivers/video/fbdev/core/fbcon.h b/drivers/video/fbdev/core/fbcon.h
index dce5ce41093e..b18d0cbf73b6 100644
--- a/drivers/video/fbdev/core/fbcon.h
+++ b/drivers/video/fbdev/core/fbcon.h
@@ -18,8 +18,6 @@
#include <asm/io.h>
-#define FBCON_FLAGS_INIT 1
-
/*
* This is the interface between the low-level console driver and the
* low-level frame buffer device
@@ -77,7 +75,7 @@ struct fbcon_ops {
int blank_state;
int graphics;
int save_graphics; /* for debug enter/leave */
- int flags;
+ bool initialized;
int rotate;
int cur_rotate;
char *cursor_data;
--
2.33.0
^ permalink raw reply related [flat|nested] 241+ messages in thread
* [Intel-gfx] [PATCH 09/21] fbcon: Replace FBCON_FLAGS_INIT with a boolean
@ 2022-01-31 21:05 ` Daniel Vetter
0 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-01-31 21:05 UTC (permalink / raw)
To: DRI Development
Cc: linux-fbdev, Thomas Zimmermann, Du Cheng, Tetsuo Handa,
Daniel Vetter, Intel Graphics Development, LKML,
Greg Kroah-Hartman, Daniel Vetter
It's only one flag and slightly tidier code.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Du Cheng <ducheng2@gmail.com>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Claudio Suarez <cssk@net-c.es>
---
drivers/video/fbdev/core/fbcon.c | 11 +++++------
drivers/video/fbdev/core/fbcon.h | 4 +---
2 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index affb40658fee..fa30e1909164 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -773,7 +773,7 @@ static void con2fb_init_display(struct vc_data *vc, struct fb_info *info,
ops->currcon = fg_console;
- if (info->fbops->fb_set_par && !(ops->flags & FBCON_FLAGS_INIT)) {
+ if (info->fbops->fb_set_par && !ops->initialized) {
ret = info->fbops->fb_set_par(info);
if (ret)
@@ -782,7 +782,7 @@ static void con2fb_init_display(struct vc_data *vc, struct fb_info *info,
"error code %d\n", ret);
}
- ops->flags |= FBCON_FLAGS_INIT;
+ ops->initialized = true;
ops->graphics = 0;
fbcon_set_disp(info, &info->var, unit);
@@ -1101,8 +1101,7 @@ static void fbcon_init(struct vc_data *vc, int init)
* We need to do it in fbcon_init() to prevent screen corruption.
*/
if (con_is_visible(vc) && vc->vc_mode == KD_TEXT) {
- if (info->fbops->fb_set_par &&
- !(ops->flags & FBCON_FLAGS_INIT)) {
+ if (info->fbops->fb_set_par && !ops->initialized) {
ret = info->fbops->fb_set_par(info);
if (ret)
@@ -1111,7 +1110,7 @@ static void fbcon_init(struct vc_data *vc, int init)
"error code %d\n", ret);
}
- ops->flags |= FBCON_FLAGS_INIT;
+ ops->initialized = true;
}
ops->graphics = 0;
@@ -1186,7 +1185,7 @@ static void fbcon_deinit(struct vc_data *vc)
if (con_is_visible(vc))
fbcon_del_cursor_work(info);
- ops->flags &= ~FBCON_FLAGS_INIT;
+ ops->initialized = false;
finished:
fbcon_free_font(p, free_font);
diff --git a/drivers/video/fbdev/core/fbcon.h b/drivers/video/fbdev/core/fbcon.h
index dce5ce41093e..b18d0cbf73b6 100644
--- a/drivers/video/fbdev/core/fbcon.h
+++ b/drivers/video/fbdev/core/fbcon.h
@@ -18,8 +18,6 @@
#include <asm/io.h>
-#define FBCON_FLAGS_INIT 1
-
/*
* This is the interface between the low-level console driver and the
* low-level frame buffer device
@@ -77,7 +75,7 @@ struct fbcon_ops {
int blank_state;
int graphics;
int save_graphics; /* for debug enter/leave */
- int flags;
+ bool initialized;
int rotate;
int cur_rotate;
char *cursor_data;
--
2.33.0
^ permalink raw reply related [flat|nested] 241+ messages in thread
* [PATCH 10/21] fb: Delete fb_info->queue
2022-01-31 21:05 ` Daniel Vetter
(?)
@ 2022-01-31 21:05 ` Daniel Vetter
-1 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-01-31 21:05 UTC (permalink / raw)
To: DRI Development
Cc: linux-fbdev, Daniel Vetter, Intel Graphics Development, LKML,
Daniel Vetter, Helge Deller
It was only used by fbcon, and that now switched to its own,
private work.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Helge Deller <deller@gmx.de>
Cc: linux-fbdev@vger.kernel.org
---
include/linux/fb.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 02f362c661c8..a8a00d2ba1f3 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -449,7 +449,6 @@ struct fb_info {
struct fb_var_screeninfo var; /* Current var */
struct fb_fix_screeninfo fix; /* Current fix */
struct fb_monspecs monspecs; /* Current Monitor specs */
- struct work_struct queue; /* Framebuffer event queue */
struct fb_pixmap pixmap; /* Image hardware mapper */
struct fb_pixmap sprite; /* Cursor hardware mapper */
struct fb_cmap cmap; /* Current cmap */
--
2.33.0
^ permalink raw reply related [flat|nested] 241+ messages in thread
* [Intel-gfx] [PATCH 10/21] fb: Delete fb_info->queue
@ 2022-01-31 21:05 ` Daniel Vetter
0 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-01-31 21:05 UTC (permalink / raw)
To: DRI Development
Cc: linux-fbdev, Daniel Vetter, Intel Graphics Development, LKML,
Daniel Vetter, Helge Deller
It was only used by fbcon, and that now switched to its own,
private work.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Helge Deller <deller@gmx.de>
Cc: linux-fbdev@vger.kernel.org
---
include/linux/fb.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 02f362c661c8..a8a00d2ba1f3 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -449,7 +449,6 @@ struct fb_info {
struct fb_var_screeninfo var; /* Current var */
struct fb_fix_screeninfo fix; /* Current fix */
struct fb_monspecs monspecs; /* Current Monitor specs */
- struct work_struct queue; /* Framebuffer event queue */
struct fb_pixmap pixmap; /* Image hardware mapper */
struct fb_pixmap sprite; /* Cursor hardware mapper */
struct fb_cmap cmap; /* Current cmap */
--
2.33.0
^ permalink raw reply related [flat|nested] 241+ messages in thread
* [PATCH 10/21] fb: Delete fb_info->queue
@ 2022-01-31 21:05 ` Daniel Vetter
0 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-01-31 21:05 UTC (permalink / raw)
To: DRI Development
Cc: Intel Graphics Development, linux-fbdev, LKML, Daniel Vetter,
Daniel Vetter, Helge Deller
It was only used by fbcon, and that now switched to its own,
private work.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Helge Deller <deller@gmx.de>
Cc: linux-fbdev@vger.kernel.org
---
include/linux/fb.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 02f362c661c8..a8a00d2ba1f3 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -449,7 +449,6 @@ struct fb_info {
struct fb_var_screeninfo var; /* Current var */
struct fb_fix_screeninfo fix; /* Current fix */
struct fb_monspecs monspecs; /* Current Monitor specs */
- struct work_struct queue; /* Framebuffer event queue */
struct fb_pixmap pixmap; /* Image hardware mapper */
struct fb_pixmap sprite; /* Cursor hardware mapper */
struct fb_cmap cmap; /* Current cmap */
--
2.33.0
^ permalink raw reply related [flat|nested] 241+ messages in thread
* [PATCH 11/21] fbcon: Extract fbcon_open/release helpers
2022-01-31 21:05 ` Daniel Vetter
(?)
@ 2022-01-31 21:05 ` Daniel Vetter
-1 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-01-31 21:05 UTC (permalink / raw)
To: DRI Development
Cc: Intel Graphics Development, linux-fbdev, LKML, Daniel Vetter,
Daniel Vetter, Daniel Vetter, Claudio Suarez, Greg Kroah-Hartman,
Tetsuo Handa, Du Cheng
There's two minor behaviour changes in here:
- in error paths we now consistently call fb_ops->fb_release
- fb_release really can't fail (fbmem.c ignores it too) and there's no
reasonable cleanup we can do anyway.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Claudio Suarez <cssk@net-c.es>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Du Cheng <ducheng2@gmail.com>
---
drivers/video/fbdev/core/fbcon.c | 107 +++++++++++++++----------------
1 file changed, 53 insertions(+), 54 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index fa30e1909164..eea2ee14b64c 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -680,19 +680,37 @@ static int fbcon_invalid_charcount(struct fb_info *info, unsigned charcount)
#endif /* CONFIG_MISC_TILEBLITTING */
+static int fbcon_open(struct fb_info *info)
+{
+ if (!try_module_get(info->fbops->owner))
+ return -ENODEV;
+
+ if (info->fbops->fb_open &&
+ info->fbops->fb_open(info, 0)) {
+ module_put(info->fbops->owner);
+ return -ENODEV;
+ }
+
+ return 0;
+}
+
+static void fbcon_release(struct fb_info *info)
+{
+ if (info->fbops->fb_release)
+ info->fbops->fb_release(info, 0);
+
+ module_put(info->fbops->owner);
+}
static int con2fb_acquire_newinfo(struct vc_data *vc, struct fb_info *info,
int unit, int oldidx)
{
struct fbcon_ops *ops = NULL;
- int err = 0;
-
- if (!try_module_get(info->fbops->owner))
- err = -ENODEV;
+ int err;
- if (!err && info->fbops->fb_open &&
- info->fbops->fb_open(info, 0))
- err = -ENODEV;
+ err = fbcon_open(info);
+ if (err)
+ return err;
if (!err) {
ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL);
@@ -713,7 +731,7 @@ static int con2fb_acquire_newinfo(struct vc_data *vc, struct fb_info *info,
if (err) {
con2fb_map[unit] = oldidx;
- module_put(info->fbops->owner);
+ fbcon_release(info);
}
return err;
@@ -724,45 +742,34 @@ static int con2fb_release_oldinfo(struct vc_data *vc, struct fb_info *oldinfo,
int oldidx, int found)
{
struct fbcon_ops *ops = oldinfo->fbcon_par;
- int err = 0, ret;
+ int ret;
- if (oldinfo->fbops->fb_release &&
- oldinfo->fbops->fb_release(oldinfo, 0)) {
- con2fb_map[unit] = oldidx;
- if (!found && newinfo->fbops->fb_release)
- newinfo->fbops->fb_release(newinfo, 0);
- if (!found)
- module_put(newinfo->fbops->owner);
- err = -ENODEV;
- }
+ fbcon_release(oldinfo);
- if (!err) {
- fbcon_del_cursor_work(oldinfo);
- kfree(ops->cursor_state.mask);
- kfree(ops->cursor_data);
- kfree(ops->cursor_src);
- kfree(ops->fontbuffer);
- kfree(oldinfo->fbcon_par);
- oldinfo->fbcon_par = NULL;
- module_put(oldinfo->fbops->owner);
- /*
- If oldinfo and newinfo are driving the same hardware,
- the fb_release() method of oldinfo may attempt to
- restore the hardware state. This will leave the
- newinfo in an undefined state. Thus, a call to
- fb_set_par() may be needed for the newinfo.
- */
- if (newinfo && newinfo->fbops->fb_set_par) {
- ret = newinfo->fbops->fb_set_par(newinfo);
+ fbcon_del_cursor_work(oldinfo);
+ kfree(ops->cursor_state.mask);
+ kfree(ops->cursor_data);
+ kfree(ops->cursor_src);
+ kfree(ops->fontbuffer);
+ kfree(oldinfo->fbcon_par);
+ oldinfo->fbcon_par = NULL;
+ /*
+ If oldinfo and newinfo are driving the same hardware,
+ the fb_release() method of oldinfo may attempt to
+ restore the hardware state. This will leave the
+ newinfo in an undefined state. Thus, a call to
+ fb_set_par() may be needed for the newinfo.
+ */
+ if (newinfo && newinfo->fbops->fb_set_par) {
+ ret = newinfo->fbops->fb_set_par(newinfo);
- if (ret)
- printk(KERN_ERR "con2fb_release_oldinfo: "
- "detected unhandled fb_set_par error, "
- "error code %d\n", ret);
- }
+ if (ret)
+ printk(KERN_ERR "con2fb_release_oldinfo: "
+ "detected unhandled fb_set_par error, "
+ "error code %d\n", ret);
}
- return err;
+ return 0;
}
static void con2fb_init_display(struct vc_data *vc, struct fb_info *info,
@@ -917,7 +924,6 @@ static const char *fbcon_startup(void)
struct fbcon_display *p = &fb_display[fg_console];
struct vc_data *vc = vc_cons[fg_console].d;
const struct font_desc *font = NULL;
- struct module *owner;
struct fb_info *info = NULL;
struct fbcon_ops *ops;
int rows, cols;
@@ -936,17 +942,12 @@ static const char *fbcon_startup(void)
if (!info)
return NULL;
- owner = info->fbops->owner;
- if (!try_module_get(owner))
+ if (fbcon_open(info))
return NULL;
- if (info->fbops->fb_open && info->fbops->fb_open(info, 0)) {
- module_put(owner);
- return NULL;
- }
ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL);
if (!ops) {
- module_put(owner);
+ fbcon_release(info);
return NULL;
}
@@ -3331,10 +3332,6 @@ static void fbcon_exit(void)
}
if (mapped) {
- if (info->fbops->fb_release)
- info->fbops->fb_release(info, 0);
- module_put(info->fbops->owner);
-
if (info->fbcon_par) {
struct fbcon_ops *ops = info->fbcon_par;
@@ -3344,6 +3341,8 @@ static void fbcon_exit(void)
kfree(info->fbcon_par);
info->fbcon_par = NULL;
}
+
+ fbcon_release(info);
}
}
}
--
2.33.0
^ permalink raw reply related [flat|nested] 241+ messages in thread
* [Intel-gfx] [PATCH 11/21] fbcon: Extract fbcon_open/release helpers
@ 2022-01-31 21:05 ` Daniel Vetter
0 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-01-31 21:05 UTC (permalink / raw)
To: DRI Development
Cc: linux-fbdev, Du Cheng, Tetsuo Handa, Daniel Vetter,
Intel Graphics Development, LKML, Greg Kroah-Hartman,
Daniel Vetter
There's two minor behaviour changes in here:
- in error paths we now consistently call fb_ops->fb_release
- fb_release really can't fail (fbmem.c ignores it too) and there's no
reasonable cleanup we can do anyway.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Claudio Suarez <cssk@net-c.es>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Du Cheng <ducheng2@gmail.com>
---
drivers/video/fbdev/core/fbcon.c | 107 +++++++++++++++----------------
1 file changed, 53 insertions(+), 54 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index fa30e1909164..eea2ee14b64c 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -680,19 +680,37 @@ static int fbcon_invalid_charcount(struct fb_info *info, unsigned charcount)
#endif /* CONFIG_MISC_TILEBLITTING */
+static int fbcon_open(struct fb_info *info)
+{
+ if (!try_module_get(info->fbops->owner))
+ return -ENODEV;
+
+ if (info->fbops->fb_open &&
+ info->fbops->fb_open(info, 0)) {
+ module_put(info->fbops->owner);
+ return -ENODEV;
+ }
+
+ return 0;
+}
+
+static void fbcon_release(struct fb_info *info)
+{
+ if (info->fbops->fb_release)
+ info->fbops->fb_release(info, 0);
+
+ module_put(info->fbops->owner);
+}
static int con2fb_acquire_newinfo(struct vc_data *vc, struct fb_info *info,
int unit, int oldidx)
{
struct fbcon_ops *ops = NULL;
- int err = 0;
-
- if (!try_module_get(info->fbops->owner))
- err = -ENODEV;
+ int err;
- if (!err && info->fbops->fb_open &&
- info->fbops->fb_open(info, 0))
- err = -ENODEV;
+ err = fbcon_open(info);
+ if (err)
+ return err;
if (!err) {
ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL);
@@ -713,7 +731,7 @@ static int con2fb_acquire_newinfo(struct vc_data *vc, struct fb_info *info,
if (err) {
con2fb_map[unit] = oldidx;
- module_put(info->fbops->owner);
+ fbcon_release(info);
}
return err;
@@ -724,45 +742,34 @@ static int con2fb_release_oldinfo(struct vc_data *vc, struct fb_info *oldinfo,
int oldidx, int found)
{
struct fbcon_ops *ops = oldinfo->fbcon_par;
- int err = 0, ret;
+ int ret;
- if (oldinfo->fbops->fb_release &&
- oldinfo->fbops->fb_release(oldinfo, 0)) {
- con2fb_map[unit] = oldidx;
- if (!found && newinfo->fbops->fb_release)
- newinfo->fbops->fb_release(newinfo, 0);
- if (!found)
- module_put(newinfo->fbops->owner);
- err = -ENODEV;
- }
+ fbcon_release(oldinfo);
- if (!err) {
- fbcon_del_cursor_work(oldinfo);
- kfree(ops->cursor_state.mask);
- kfree(ops->cursor_data);
- kfree(ops->cursor_src);
- kfree(ops->fontbuffer);
- kfree(oldinfo->fbcon_par);
- oldinfo->fbcon_par = NULL;
- module_put(oldinfo->fbops->owner);
- /*
- If oldinfo and newinfo are driving the same hardware,
- the fb_release() method of oldinfo may attempt to
- restore the hardware state. This will leave the
- newinfo in an undefined state. Thus, a call to
- fb_set_par() may be needed for the newinfo.
- */
- if (newinfo && newinfo->fbops->fb_set_par) {
- ret = newinfo->fbops->fb_set_par(newinfo);
+ fbcon_del_cursor_work(oldinfo);
+ kfree(ops->cursor_state.mask);
+ kfree(ops->cursor_data);
+ kfree(ops->cursor_src);
+ kfree(ops->fontbuffer);
+ kfree(oldinfo->fbcon_par);
+ oldinfo->fbcon_par = NULL;
+ /*
+ If oldinfo and newinfo are driving the same hardware,
+ the fb_release() method of oldinfo may attempt to
+ restore the hardware state. This will leave the
+ newinfo in an undefined state. Thus, a call to
+ fb_set_par() may be needed for the newinfo.
+ */
+ if (newinfo && newinfo->fbops->fb_set_par) {
+ ret = newinfo->fbops->fb_set_par(newinfo);
- if (ret)
- printk(KERN_ERR "con2fb_release_oldinfo: "
- "detected unhandled fb_set_par error, "
- "error code %d\n", ret);
- }
+ if (ret)
+ printk(KERN_ERR "con2fb_release_oldinfo: "
+ "detected unhandled fb_set_par error, "
+ "error code %d\n", ret);
}
- return err;
+ return 0;
}
static void con2fb_init_display(struct vc_data *vc, struct fb_info *info,
@@ -917,7 +924,6 @@ static const char *fbcon_startup(void)
struct fbcon_display *p = &fb_display[fg_console];
struct vc_data *vc = vc_cons[fg_console].d;
const struct font_desc *font = NULL;
- struct module *owner;
struct fb_info *info = NULL;
struct fbcon_ops *ops;
int rows, cols;
@@ -936,17 +942,12 @@ static const char *fbcon_startup(void)
if (!info)
return NULL;
- owner = info->fbops->owner;
- if (!try_module_get(owner))
+ if (fbcon_open(info))
return NULL;
- if (info->fbops->fb_open && info->fbops->fb_open(info, 0)) {
- module_put(owner);
- return NULL;
- }
ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL);
if (!ops) {
- module_put(owner);
+ fbcon_release(info);
return NULL;
}
@@ -3331,10 +3332,6 @@ static void fbcon_exit(void)
}
if (mapped) {
- if (info->fbops->fb_release)
- info->fbops->fb_release(info, 0);
- module_put(info->fbops->owner);
-
if (info->fbcon_par) {
struct fbcon_ops *ops = info->fbcon_par;
@@ -3344,6 +3341,8 @@ static void fbcon_exit(void)
kfree(info->fbcon_par);
info->fbcon_par = NULL;
}
+
+ fbcon_release(info);
}
}
}
--
2.33.0
^ permalink raw reply related [flat|nested] 241+ messages in thread
* [PATCH 11/21] fbcon: Extract fbcon_open/release helpers
@ 2022-01-31 21:05 ` Daniel Vetter
0 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-01-31 21:05 UTC (permalink / raw)
To: DRI Development
Cc: linux-fbdev, Du Cheng, Tetsuo Handa, Daniel Vetter,
Intel Graphics Development, LKML, Claudio Suarez,
Greg Kroah-Hartman, Daniel Vetter
There's two minor behaviour changes in here:
- in error paths we now consistently call fb_ops->fb_release
- fb_release really can't fail (fbmem.c ignores it too) and there's no
reasonable cleanup we can do anyway.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Claudio Suarez <cssk@net-c.es>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Du Cheng <ducheng2@gmail.com>
---
drivers/video/fbdev/core/fbcon.c | 107 +++++++++++++++----------------
1 file changed, 53 insertions(+), 54 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index fa30e1909164..eea2ee14b64c 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -680,19 +680,37 @@ static int fbcon_invalid_charcount(struct fb_info *info, unsigned charcount)
#endif /* CONFIG_MISC_TILEBLITTING */
+static int fbcon_open(struct fb_info *info)
+{
+ if (!try_module_get(info->fbops->owner))
+ return -ENODEV;
+
+ if (info->fbops->fb_open &&
+ info->fbops->fb_open(info, 0)) {
+ module_put(info->fbops->owner);
+ return -ENODEV;
+ }
+
+ return 0;
+}
+
+static void fbcon_release(struct fb_info *info)
+{
+ if (info->fbops->fb_release)
+ info->fbops->fb_release(info, 0);
+
+ module_put(info->fbops->owner);
+}
static int con2fb_acquire_newinfo(struct vc_data *vc, struct fb_info *info,
int unit, int oldidx)
{
struct fbcon_ops *ops = NULL;
- int err = 0;
-
- if (!try_module_get(info->fbops->owner))
- err = -ENODEV;
+ int err;
- if (!err && info->fbops->fb_open &&
- info->fbops->fb_open(info, 0))
- err = -ENODEV;
+ err = fbcon_open(info);
+ if (err)
+ return err;
if (!err) {
ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL);
@@ -713,7 +731,7 @@ static int con2fb_acquire_newinfo(struct vc_data *vc, struct fb_info *info,
if (err) {
con2fb_map[unit] = oldidx;
- module_put(info->fbops->owner);
+ fbcon_release(info);
}
return err;
@@ -724,45 +742,34 @@ static int con2fb_release_oldinfo(struct vc_data *vc, struct fb_info *oldinfo,
int oldidx, int found)
{
struct fbcon_ops *ops = oldinfo->fbcon_par;
- int err = 0, ret;
+ int ret;
- if (oldinfo->fbops->fb_release &&
- oldinfo->fbops->fb_release(oldinfo, 0)) {
- con2fb_map[unit] = oldidx;
- if (!found && newinfo->fbops->fb_release)
- newinfo->fbops->fb_release(newinfo, 0);
- if (!found)
- module_put(newinfo->fbops->owner);
- err = -ENODEV;
- }
+ fbcon_release(oldinfo);
- if (!err) {
- fbcon_del_cursor_work(oldinfo);
- kfree(ops->cursor_state.mask);
- kfree(ops->cursor_data);
- kfree(ops->cursor_src);
- kfree(ops->fontbuffer);
- kfree(oldinfo->fbcon_par);
- oldinfo->fbcon_par = NULL;
- module_put(oldinfo->fbops->owner);
- /*
- If oldinfo and newinfo are driving the same hardware,
- the fb_release() method of oldinfo may attempt to
- restore the hardware state. This will leave the
- newinfo in an undefined state. Thus, a call to
- fb_set_par() may be needed for the newinfo.
- */
- if (newinfo && newinfo->fbops->fb_set_par) {
- ret = newinfo->fbops->fb_set_par(newinfo);
+ fbcon_del_cursor_work(oldinfo);
+ kfree(ops->cursor_state.mask);
+ kfree(ops->cursor_data);
+ kfree(ops->cursor_src);
+ kfree(ops->fontbuffer);
+ kfree(oldinfo->fbcon_par);
+ oldinfo->fbcon_par = NULL;
+ /*
+ If oldinfo and newinfo are driving the same hardware,
+ the fb_release() method of oldinfo may attempt to
+ restore the hardware state. This will leave the
+ newinfo in an undefined state. Thus, a call to
+ fb_set_par() may be needed for the newinfo.
+ */
+ if (newinfo && newinfo->fbops->fb_set_par) {
+ ret = newinfo->fbops->fb_set_par(newinfo);
- if (ret)
- printk(KERN_ERR "con2fb_release_oldinfo: "
- "detected unhandled fb_set_par error, "
- "error code %d\n", ret);
- }
+ if (ret)
+ printk(KERN_ERR "con2fb_release_oldinfo: "
+ "detected unhandled fb_set_par error, "
+ "error code %d\n", ret);
}
- return err;
+ return 0;
}
static void con2fb_init_display(struct vc_data *vc, struct fb_info *info,
@@ -917,7 +924,6 @@ static const char *fbcon_startup(void)
struct fbcon_display *p = &fb_display[fg_console];
struct vc_data *vc = vc_cons[fg_console].d;
const struct font_desc *font = NULL;
- struct module *owner;
struct fb_info *info = NULL;
struct fbcon_ops *ops;
int rows, cols;
@@ -936,17 +942,12 @@ static const char *fbcon_startup(void)
if (!info)
return NULL;
- owner = info->fbops->owner;
- if (!try_module_get(owner))
+ if (fbcon_open(info))
return NULL;
- if (info->fbops->fb_open && info->fbops->fb_open(info, 0)) {
- module_put(owner);
- return NULL;
- }
ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL);
if (!ops) {
- module_put(owner);
+ fbcon_release(info);
return NULL;
}
@@ -3331,10 +3332,6 @@ static void fbcon_exit(void)
}
if (mapped) {
- if (info->fbops->fb_release)
- info->fbops->fb_release(info, 0);
- module_put(info->fbops->owner);
-
if (info->fbcon_par) {
struct fbcon_ops *ops = info->fbcon_par;
@@ -3344,6 +3341,8 @@ static void fbcon_exit(void)
kfree(info->fbcon_par);
info->fbcon_par = NULL;
}
+
+ fbcon_release(info);
}
}
}
--
2.33.0
^ permalink raw reply related [flat|nested] 241+ messages in thread
* [Intel-gfx] [PATCH 12/21] fbcon: Ditch error handling for con2fb_release_oldinfo
2022-01-31 21:05 ` Daniel Vetter
(?)
@ 2022-01-31 21:05 ` Daniel Vetter
-1 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-01-31 21:05 UTC (permalink / raw)
To: DRI Development
Cc: linux-fbdev, Thomas Zimmermann, Du Cheng, Tetsuo Handa,
Daniel Vetter, Intel Graphics Development, LKML,
Greg Kroah-Hartman, Daniel Vetter
It doesn't ever fail anymore.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Claudio Suarez <cssk@net-c.es>
Cc: Du Cheng <ducheng2@gmail.com>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
---
drivers/video/fbdev/core/fbcon.c | 37 +++++++++++---------------------
1 file changed, 13 insertions(+), 24 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index eea2ee14b64c..b83a5a77d8a8 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -737,9 +737,8 @@ static int con2fb_acquire_newinfo(struct vc_data *vc, struct fb_info *info,
return err;
}
-static int con2fb_release_oldinfo(struct vc_data *vc, struct fb_info *oldinfo,
- struct fb_info *newinfo, int unit,
- int oldidx, int found)
+static void con2fb_release_oldinfo(struct vc_data *vc, struct fb_info *oldinfo,
+ struct fb_info *newinfo)
{
struct fbcon_ops *ops = oldinfo->fbcon_par;
int ret;
@@ -768,8 +767,6 @@ static int con2fb_release_oldinfo(struct vc_data *vc, struct fb_info *oldinfo,
"detected unhandled fb_set_par error, "
"error code %d\n", ret);
}
-
- return 0;
}
static void con2fb_init_display(struct vc_data *vc, struct fb_info *info,
@@ -823,7 +820,7 @@ static int set_con2fb_map(int unit, int newidx, int user)
int oldidx = con2fb_map[unit];
struct fb_info *info = registered_fb[newidx];
struct fb_info *oldinfo = NULL;
- int found, err = 0;
+ int found, err = 0, show_logo;
WARN_CONSOLE_UNLOCKED();
@@ -852,18 +849,15 @@ static int set_con2fb_map(int unit, int newidx, int user)
* fbcon should release it.
*/
if (!err && oldinfo && !search_fb_in_map(oldidx))
- err = con2fb_release_oldinfo(vc, oldinfo, info, unit, oldidx,
- found);
+ con2fb_release_oldinfo(vc, oldinfo, info);
- if (!err) {
- int show_logo = (fg_console == 0 && !user &&
- logo_shown != FBCON_LOGO_DONTSHOW);
+ show_logo = (fg_console == 0 && !user &&
+ logo_shown != FBCON_LOGO_DONTSHOW);
- if (!found)
- fbcon_add_cursor_work(info);
- con2fb_map_boot[unit] = newidx;
- con2fb_init_display(vc, info, unit, show_logo);
- }
+ if (!found)
+ fbcon_add_cursor_work(info);
+ con2fb_map_boot[unit] = newidx;
+ con2fb_init_display(vc, info, unit, show_logo);
if (!search_fb_in_map(info_idx))
info_idx = newidx;
@@ -2786,7 +2780,7 @@ static inline void fbcon_unbind(void) {}
/* called with console_lock held */
void fbcon_fb_unbind(struct fb_info *info)
{
- int i, new_idx = -1, ret = 0;
+ int i, new_idx = -1;
int idx = info->node;
WARN_CONSOLE_UNLOCKED();
@@ -2820,13 +2814,8 @@ void fbcon_fb_unbind(struct fb_info *info)
if (con2fb_map[i] == idx) {
con2fb_map[i] = -1;
if (!search_fb_in_map(idx)) {
- ret = con2fb_release_oldinfo(vc_cons[i].d,
- info, NULL, i,
- idx, 0);
- if (ret) {
- con2fb_map[i] = idx;
- return;
- }
+ con2fb_release_oldinfo(vc_cons[i].d,
+ info, NULL);
}
}
}
--
2.33.0
^ permalink raw reply related [flat|nested] 241+ messages in thread
* [PATCH 12/21] fbcon: Ditch error handling for con2fb_release_oldinfo
@ 2022-01-31 21:05 ` Daniel Vetter
0 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-01-31 21:05 UTC (permalink / raw)
To: DRI Development
Cc: Intel Graphics Development, linux-fbdev, LKML, Daniel Vetter,
Daniel Vetter, Daniel Vetter, Thomas Zimmermann,
Greg Kroah-Hartman, Claudio Suarez, Du Cheng, Tetsuo Handa
It doesn't ever fail anymore.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Claudio Suarez <cssk@net-c.es>
Cc: Du Cheng <ducheng2@gmail.com>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
---
drivers/video/fbdev/core/fbcon.c | 37 +++++++++++---------------------
1 file changed, 13 insertions(+), 24 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index eea2ee14b64c..b83a5a77d8a8 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -737,9 +737,8 @@ static int con2fb_acquire_newinfo(struct vc_data *vc, struct fb_info *info,
return err;
}
-static int con2fb_release_oldinfo(struct vc_data *vc, struct fb_info *oldinfo,
- struct fb_info *newinfo, int unit,
- int oldidx, int found)
+static void con2fb_release_oldinfo(struct vc_data *vc, struct fb_info *oldinfo,
+ struct fb_info *newinfo)
{
struct fbcon_ops *ops = oldinfo->fbcon_par;
int ret;
@@ -768,8 +767,6 @@ static int con2fb_release_oldinfo(struct vc_data *vc, struct fb_info *oldinfo,
"detected unhandled fb_set_par error, "
"error code %d\n", ret);
}
-
- return 0;
}
static void con2fb_init_display(struct vc_data *vc, struct fb_info *info,
@@ -823,7 +820,7 @@ static int set_con2fb_map(int unit, int newidx, int user)
int oldidx = con2fb_map[unit];
struct fb_info *info = registered_fb[newidx];
struct fb_info *oldinfo = NULL;
- int found, err = 0;
+ int found, err = 0, show_logo;
WARN_CONSOLE_UNLOCKED();
@@ -852,18 +849,15 @@ static int set_con2fb_map(int unit, int newidx, int user)
* fbcon should release it.
*/
if (!err && oldinfo && !search_fb_in_map(oldidx))
- err = con2fb_release_oldinfo(vc, oldinfo, info, unit, oldidx,
- found);
+ con2fb_release_oldinfo(vc, oldinfo, info);
- if (!err) {
- int show_logo = (fg_console == 0 && !user &&
- logo_shown != FBCON_LOGO_DONTSHOW);
+ show_logo = (fg_console == 0 && !user &&
+ logo_shown != FBCON_LOGO_DONTSHOW);
- if (!found)
- fbcon_add_cursor_work(info);
- con2fb_map_boot[unit] = newidx;
- con2fb_init_display(vc, info, unit, show_logo);
- }
+ if (!found)
+ fbcon_add_cursor_work(info);
+ con2fb_map_boot[unit] = newidx;
+ con2fb_init_display(vc, info, unit, show_logo);
if (!search_fb_in_map(info_idx))
info_idx = newidx;
@@ -2786,7 +2780,7 @@ static inline void fbcon_unbind(void) {}
/* called with console_lock held */
void fbcon_fb_unbind(struct fb_info *info)
{
- int i, new_idx = -1, ret = 0;
+ int i, new_idx = -1;
int idx = info->node;
WARN_CONSOLE_UNLOCKED();
@@ -2820,13 +2814,8 @@ void fbcon_fb_unbind(struct fb_info *info)
if (con2fb_map[i] == idx) {
con2fb_map[i] = -1;
if (!search_fb_in_map(idx)) {
- ret = con2fb_release_oldinfo(vc_cons[i].d,
- info, NULL, i,
- idx, 0);
- if (ret) {
- con2fb_map[i] = idx;
- return;
- }
+ con2fb_release_oldinfo(vc_cons[i].d,
+ info, NULL);
}
}
}
--
2.33.0
^ permalink raw reply related [flat|nested] 241+ messages in thread
* [PATCH 12/21] fbcon: Ditch error handling for con2fb_release_oldinfo
@ 2022-01-31 21:05 ` Daniel Vetter
0 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-01-31 21:05 UTC (permalink / raw)
To: DRI Development
Cc: linux-fbdev, Thomas Zimmermann, Du Cheng, Tetsuo Handa,
Daniel Vetter, Intel Graphics Development, LKML, Claudio Suarez,
Greg Kroah-Hartman, Daniel Vetter
It doesn't ever fail anymore.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Claudio Suarez <cssk@net-c.es>
Cc: Du Cheng <ducheng2@gmail.com>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
---
drivers/video/fbdev/core/fbcon.c | 37 +++++++++++---------------------
1 file changed, 13 insertions(+), 24 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index eea2ee14b64c..b83a5a77d8a8 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -737,9 +737,8 @@ static int con2fb_acquire_newinfo(struct vc_data *vc, struct fb_info *info,
return err;
}
-static int con2fb_release_oldinfo(struct vc_data *vc, struct fb_info *oldinfo,
- struct fb_info *newinfo, int unit,
- int oldidx, int found)
+static void con2fb_release_oldinfo(struct vc_data *vc, struct fb_info *oldinfo,
+ struct fb_info *newinfo)
{
struct fbcon_ops *ops = oldinfo->fbcon_par;
int ret;
@@ -768,8 +767,6 @@ static int con2fb_release_oldinfo(struct vc_data *vc, struct fb_info *oldinfo,
"detected unhandled fb_set_par error, "
"error code %d\n", ret);
}
-
- return 0;
}
static void con2fb_init_display(struct vc_data *vc, struct fb_info *info,
@@ -823,7 +820,7 @@ static int set_con2fb_map(int unit, int newidx, int user)
int oldidx = con2fb_map[unit];
struct fb_info *info = registered_fb[newidx];
struct fb_info *oldinfo = NULL;
- int found, err = 0;
+ int found, err = 0, show_logo;
WARN_CONSOLE_UNLOCKED();
@@ -852,18 +849,15 @@ static int set_con2fb_map(int unit, int newidx, int user)
* fbcon should release it.
*/
if (!err && oldinfo && !search_fb_in_map(oldidx))
- err = con2fb_release_oldinfo(vc, oldinfo, info, unit, oldidx,
- found);
+ con2fb_release_oldinfo(vc, oldinfo, info);
- if (!err) {
- int show_logo = (fg_console == 0 && !user &&
- logo_shown != FBCON_LOGO_DONTSHOW);
+ show_logo = (fg_console == 0 && !user &&
+ logo_shown != FBCON_LOGO_DONTSHOW);
- if (!found)
- fbcon_add_cursor_work(info);
- con2fb_map_boot[unit] = newidx;
- con2fb_init_display(vc, info, unit, show_logo);
- }
+ if (!found)
+ fbcon_add_cursor_work(info);
+ con2fb_map_boot[unit] = newidx;
+ con2fb_init_display(vc, info, unit, show_logo);
if (!search_fb_in_map(info_idx))
info_idx = newidx;
@@ -2786,7 +2780,7 @@ static inline void fbcon_unbind(void) {}
/* called with console_lock held */
void fbcon_fb_unbind(struct fb_info *info)
{
- int i, new_idx = -1, ret = 0;
+ int i, new_idx = -1;
int idx = info->node;
WARN_CONSOLE_UNLOCKED();
@@ -2820,13 +2814,8 @@ void fbcon_fb_unbind(struct fb_info *info)
if (con2fb_map[i] == idx) {
con2fb_map[i] = -1;
if (!search_fb_in_map(idx)) {
- ret = con2fb_release_oldinfo(vc_cons[i].d,
- info, NULL, i,
- idx, 0);
- if (ret) {
- con2fb_map[i] = idx;
- return;
- }
+ con2fb_release_oldinfo(vc_cons[i].d,
+ info, NULL);
}
}
}
--
2.33.0
^ permalink raw reply related [flat|nested] 241+ messages in thread
* [PATCH 13/21] fbcon: move more common code into fb_open()
2022-01-31 21:05 ` Daniel Vetter
(?)
@ 2022-01-31 21:05 ` Daniel Vetter
-1 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-01-31 21:05 UTC (permalink / raw)
To: DRI Development
Cc: linux-fbdev, Thomas Zimmermann, Du Cheng, Tetsuo Handa,
Daniel Vetter, Intel Graphics Development, LKML, Claudio Suarez,
Greg Kroah-Hartman, Daniel Vetter
No idea why con2fb_acquire_newinfo() initializes much less than
fbcon_startup(), but so be it. From a quick look most of the
un-initialized stuff should be fairly harmless, but who knows.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Claudio Suarez <cssk@net-c.es>
Cc: Du Cheng <ducheng2@gmail.com>
---
drivers/video/fbdev/core/fbcon.c | 74 +++++++++++++-------------------
1 file changed, 31 insertions(+), 43 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index b83a5a77d8a8..5a3391ff038d 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -680,8 +680,18 @@ static int fbcon_invalid_charcount(struct fb_info *info, unsigned charcount)
#endif /* CONFIG_MISC_TILEBLITTING */
+static void fbcon_release(struct fb_info *info)
+{
+ if (info->fbops->fb_release)
+ info->fbops->fb_release(info, 0);
+
+ module_put(info->fbops->owner);
+}
+
static int fbcon_open(struct fb_info *info)
{
+ struct fbcon_ops *ops;
+
if (!try_module_get(info->fbops->owner))
return -ENODEV;
@@ -691,19 +701,22 @@ static int fbcon_open(struct fb_info *info)
return -ENODEV;
}
- return 0;
-}
+ ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL);
+ if (!ops) {
+ fbcon_release(info);
+ return -ENOMEM;
+ }
-static void fbcon_release(struct fb_info *info)
-{
- if (info->fbops->fb_release)
- info->fbops->fb_release(info, 0);
+ INIT_DELAYED_WORK(&ops->cursor_work, fb_flashcursor);
+ ops->info = info;
+ info->fbcon_par = ops;
+ ops->cur_blink_jiffies = HZ / 5;
- module_put(info->fbops->owner);
+ return 0;
}
static int con2fb_acquire_newinfo(struct vc_data *vc, struct fb_info *info,
- int unit, int oldidx)
+ int unit)
{
struct fbcon_ops *ops = NULL;
int err;
@@ -712,27 +725,10 @@ static int con2fb_acquire_newinfo(struct vc_data *vc, struct fb_info *info,
if (err)
return err;
- if (!err) {
- ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL);
- if (!ops)
- err = -ENOMEM;
-
- INIT_DELAYED_WORK(&ops->cursor_work, fb_flashcursor);
- }
-
- if (!err) {
- ops->cur_blink_jiffies = HZ / 5;
- ops->info = info;
- info->fbcon_par = ops;
-
- if (vc)
- set_blitting_type(vc, info);
- }
+ ops = info->fbcon_par;
- if (err) {
- con2fb_map[unit] = oldidx;
- fbcon_release(info);
- }
+ if (vc)
+ set_blitting_type(vc, info);
return err;
}
@@ -840,9 +836,11 @@ static int set_con2fb_map(int unit, int newidx, int user)
found = search_fb_in_map(newidx);
- con2fb_map[unit] = newidx;
- if (!err && !found)
- err = con2fb_acquire_newinfo(vc, info, unit, oldidx);
+ if (!err && !found) {
+ err = con2fb_acquire_newinfo(vc, info, unit);
+ if (!err)
+ con2fb_map[unit] = newidx;
+ }
/*
* If old fb is not mapped to any of the consoles,
@@ -939,20 +937,10 @@ static const char *fbcon_startup(void)
if (fbcon_open(info))
return NULL;
- ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL);
- if (!ops) {
- fbcon_release(info);
- return NULL;
- }
-
- INIT_DELAYED_WORK(&ops->cursor_work, fb_flashcursor);
-
+ ops = info->fbcon_par;
ops->currcon = -1;
ops->graphics = 1;
ops->cur_rotate = -1;
- ops->cur_blink_jiffies = HZ / 5;
- ops->info = info;
- info->fbcon_par = ops;
p->con_rotate = initial_rotation;
if (p->con_rotate == -1)
@@ -1022,7 +1010,7 @@ static void fbcon_init(struct vc_data *vc, int init)
return;
if (!info->fbcon_par)
- con2fb_acquire_newinfo(vc, info, vc->vc_num, -1);
+ con2fb_acquire_newinfo(vc, info, vc->vc_num);
/* If we are not the first console on this
fb, copy the font from that console */
--
2.33.0
^ permalink raw reply related [flat|nested] 241+ messages in thread
* [Intel-gfx] [PATCH 13/21] fbcon: move more common code into fb_open()
@ 2022-01-31 21:05 ` Daniel Vetter
0 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-01-31 21:05 UTC (permalink / raw)
To: DRI Development
Cc: linux-fbdev, Thomas Zimmermann, Du Cheng, Tetsuo Handa,
Daniel Vetter, Intel Graphics Development, LKML,
Greg Kroah-Hartman, Daniel Vetter
No idea why con2fb_acquire_newinfo() initializes much less than
fbcon_startup(), but so be it. From a quick look most of the
un-initialized stuff should be fairly harmless, but who knows.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Claudio Suarez <cssk@net-c.es>
Cc: Du Cheng <ducheng2@gmail.com>
---
drivers/video/fbdev/core/fbcon.c | 74 +++++++++++++-------------------
1 file changed, 31 insertions(+), 43 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index b83a5a77d8a8..5a3391ff038d 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -680,8 +680,18 @@ static int fbcon_invalid_charcount(struct fb_info *info, unsigned charcount)
#endif /* CONFIG_MISC_TILEBLITTING */
+static void fbcon_release(struct fb_info *info)
+{
+ if (info->fbops->fb_release)
+ info->fbops->fb_release(info, 0);
+
+ module_put(info->fbops->owner);
+}
+
static int fbcon_open(struct fb_info *info)
{
+ struct fbcon_ops *ops;
+
if (!try_module_get(info->fbops->owner))
return -ENODEV;
@@ -691,19 +701,22 @@ static int fbcon_open(struct fb_info *info)
return -ENODEV;
}
- return 0;
-}
+ ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL);
+ if (!ops) {
+ fbcon_release(info);
+ return -ENOMEM;
+ }
-static void fbcon_release(struct fb_info *info)
-{
- if (info->fbops->fb_release)
- info->fbops->fb_release(info, 0);
+ INIT_DELAYED_WORK(&ops->cursor_work, fb_flashcursor);
+ ops->info = info;
+ info->fbcon_par = ops;
+ ops->cur_blink_jiffies = HZ / 5;
- module_put(info->fbops->owner);
+ return 0;
}
static int con2fb_acquire_newinfo(struct vc_data *vc, struct fb_info *info,
- int unit, int oldidx)
+ int unit)
{
struct fbcon_ops *ops = NULL;
int err;
@@ -712,27 +725,10 @@ static int con2fb_acquire_newinfo(struct vc_data *vc, struct fb_info *info,
if (err)
return err;
- if (!err) {
- ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL);
- if (!ops)
- err = -ENOMEM;
-
- INIT_DELAYED_WORK(&ops->cursor_work, fb_flashcursor);
- }
-
- if (!err) {
- ops->cur_blink_jiffies = HZ / 5;
- ops->info = info;
- info->fbcon_par = ops;
-
- if (vc)
- set_blitting_type(vc, info);
- }
+ ops = info->fbcon_par;
- if (err) {
- con2fb_map[unit] = oldidx;
- fbcon_release(info);
- }
+ if (vc)
+ set_blitting_type(vc, info);
return err;
}
@@ -840,9 +836,11 @@ static int set_con2fb_map(int unit, int newidx, int user)
found = search_fb_in_map(newidx);
- con2fb_map[unit] = newidx;
- if (!err && !found)
- err = con2fb_acquire_newinfo(vc, info, unit, oldidx);
+ if (!err && !found) {
+ err = con2fb_acquire_newinfo(vc, info, unit);
+ if (!err)
+ con2fb_map[unit] = newidx;
+ }
/*
* If old fb is not mapped to any of the consoles,
@@ -939,20 +937,10 @@ static const char *fbcon_startup(void)
if (fbcon_open(info))
return NULL;
- ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL);
- if (!ops) {
- fbcon_release(info);
- return NULL;
- }
-
- INIT_DELAYED_WORK(&ops->cursor_work, fb_flashcursor);
-
+ ops = info->fbcon_par;
ops->currcon = -1;
ops->graphics = 1;
ops->cur_rotate = -1;
- ops->cur_blink_jiffies = HZ / 5;
- ops->info = info;
- info->fbcon_par = ops;
p->con_rotate = initial_rotation;
if (p->con_rotate == -1)
@@ -1022,7 +1010,7 @@ static void fbcon_init(struct vc_data *vc, int init)
return;
if (!info->fbcon_par)
- con2fb_acquire_newinfo(vc, info, vc->vc_num, -1);
+ con2fb_acquire_newinfo(vc, info, vc->vc_num);
/* If we are not the first console on this
fb, copy the font from that console */
--
2.33.0
^ permalink raw reply related [flat|nested] 241+ messages in thread
* [PATCH 13/21] fbcon: move more common code into fb_open()
@ 2022-01-31 21:05 ` Daniel Vetter
0 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-01-31 21:05 UTC (permalink / raw)
To: DRI Development
Cc: Intel Graphics Development, linux-fbdev, LKML, Daniel Vetter,
Daniel Vetter, Daniel Vetter, Greg Kroah-Hartman, Tetsuo Handa,
Thomas Zimmermann, Claudio Suarez, Du Cheng
No idea why con2fb_acquire_newinfo() initializes much less than
fbcon_startup(), but so be it. From a quick look most of the
un-initialized stuff should be fairly harmless, but who knows.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Claudio Suarez <cssk@net-c.es>
Cc: Du Cheng <ducheng2@gmail.com>
---
drivers/video/fbdev/core/fbcon.c | 74 +++++++++++++-------------------
1 file changed, 31 insertions(+), 43 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index b83a5a77d8a8..5a3391ff038d 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -680,8 +680,18 @@ static int fbcon_invalid_charcount(struct fb_info *info, unsigned charcount)
#endif /* CONFIG_MISC_TILEBLITTING */
+static void fbcon_release(struct fb_info *info)
+{
+ if (info->fbops->fb_release)
+ info->fbops->fb_release(info, 0);
+
+ module_put(info->fbops->owner);
+}
+
static int fbcon_open(struct fb_info *info)
{
+ struct fbcon_ops *ops;
+
if (!try_module_get(info->fbops->owner))
return -ENODEV;
@@ -691,19 +701,22 @@ static int fbcon_open(struct fb_info *info)
return -ENODEV;
}
- return 0;
-}
+ ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL);
+ if (!ops) {
+ fbcon_release(info);
+ return -ENOMEM;
+ }
-static void fbcon_release(struct fb_info *info)
-{
- if (info->fbops->fb_release)
- info->fbops->fb_release(info, 0);
+ INIT_DELAYED_WORK(&ops->cursor_work, fb_flashcursor);
+ ops->info = info;
+ info->fbcon_par = ops;
+ ops->cur_blink_jiffies = HZ / 5;
- module_put(info->fbops->owner);
+ return 0;
}
static int con2fb_acquire_newinfo(struct vc_data *vc, struct fb_info *info,
- int unit, int oldidx)
+ int unit)
{
struct fbcon_ops *ops = NULL;
int err;
@@ -712,27 +725,10 @@ static int con2fb_acquire_newinfo(struct vc_data *vc, struct fb_info *info,
if (err)
return err;
- if (!err) {
- ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL);
- if (!ops)
- err = -ENOMEM;
-
- INIT_DELAYED_WORK(&ops->cursor_work, fb_flashcursor);
- }
-
- if (!err) {
- ops->cur_blink_jiffies = HZ / 5;
- ops->info = info;
- info->fbcon_par = ops;
-
- if (vc)
- set_blitting_type(vc, info);
- }
+ ops = info->fbcon_par;
- if (err) {
- con2fb_map[unit] = oldidx;
- fbcon_release(info);
- }
+ if (vc)
+ set_blitting_type(vc, info);
return err;
}
@@ -840,9 +836,11 @@ static int set_con2fb_map(int unit, int newidx, int user)
found = search_fb_in_map(newidx);
- con2fb_map[unit] = newidx;
- if (!err && !found)
- err = con2fb_acquire_newinfo(vc, info, unit, oldidx);
+ if (!err && !found) {
+ err = con2fb_acquire_newinfo(vc, info, unit);
+ if (!err)
+ con2fb_map[unit] = newidx;
+ }
/*
* If old fb is not mapped to any of the consoles,
@@ -939,20 +937,10 @@ static const char *fbcon_startup(void)
if (fbcon_open(info))
return NULL;
- ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL);
- if (!ops) {
- fbcon_release(info);
- return NULL;
- }
-
- INIT_DELAYED_WORK(&ops->cursor_work, fb_flashcursor);
-
+ ops = info->fbcon_par;
ops->currcon = -1;
ops->graphics = 1;
ops->cur_rotate = -1;
- ops->cur_blink_jiffies = HZ / 5;
- ops->info = info;
- info->fbcon_par = ops;
p->con_rotate = initial_rotation;
if (p->con_rotate == -1)
@@ -1022,7 +1010,7 @@ static void fbcon_init(struct vc_data *vc, int init)
return;
if (!info->fbcon_par)
- con2fb_acquire_newinfo(vc, info, vc->vc_num, -1);
+ con2fb_acquire_newinfo(vc, info, vc->vc_num);
/* If we are not the first console on this
fb, copy the font from that console */
--
2.33.0
^ permalink raw reply related [flat|nested] 241+ messages in thread
* [Intel-gfx] [PATCH 14/21] fbcon: use lock_fb_info in fbcon_open/release
2022-01-31 21:05 ` Daniel Vetter
(?)
@ 2022-01-31 21:05 ` Daniel Vetter
-1 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-01-31 21:05 UTC (permalink / raw)
To: DRI Development
Cc: linux-fbdev, Thomas Zimmermann, Xiyu Yang, Du Cheng,
Tetsuo Handa, Daniel Vetter, Intel Graphics Development,
Zheyu Ma, LKML, Matthew Wilcox, William Kucharski,
Greg Kroah-Hartman, Alex Deucher, Daniel Vetter, Sam Ravnborg,
Zhen Lei
Now we get to the real motiviation, because fbmem.c insists that
that's the right lock for these.
Ofc fbcon.c has a lot more places where it probably should call
lock_fb_info(). But looking at fbmem.c at least most of these seem to
be protected by console_lock() too, which is probably what papers over
any issues.
Note that this means we're shuffling around a bit the locking sections
for some of the console takeover and unbind paths, but not all:
- console binding/unbinding from the console layer never with
lock_fb_info
- unbind (as opposed to unlink) never bother with lock_fb_info
Also the real serialization against set_par and set_pan are still
doing by wrapping the entire ioctl code in console_lock(). So this
shuffling shouldn't be worse than what we had from a "can you trigger
races?" pov, but it's at least clearer.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Claudio Suarez <cssk@net-c.es>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Du Cheng <ducheng2@gmail.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: William Kucharski <william.kucharski@oracle.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Zheyu Ma <zheyuma97@gmail.com>
Cc: Zhen Lei <thunder.leizhen@huawei.com>
Cc: Xiyu Yang <xiyuyang19@fudan.edu.cn>
---
drivers/video/fbdev/core/fbcon.c | 5 +++++
drivers/video/fbdev/core/fbmem.c | 4 ----
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 5a3391ff038d..496bc5f2133e 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -682,8 +682,10 @@ static int fbcon_invalid_charcount(struct fb_info *info, unsigned charcount)
static void fbcon_release(struct fb_info *info)
{
+ lock_fb_info(info);
if (info->fbops->fb_release)
info->fbops->fb_release(info, 0);
+ unlock_fb_info(info);
module_put(info->fbops->owner);
}
@@ -695,11 +697,14 @@ static int fbcon_open(struct fb_info *info)
if (!try_module_get(info->fbops->owner))
return -ENODEV;
+ lock_fb_info(info);
if (info->fbops->fb_open &&
info->fbops->fb_open(info, 0)) {
+ unlock_fb_info(info);
module_put(info->fbops->owner);
return -ENODEV;
}
+ unlock_fb_info(info);
ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL);
if (!ops) {
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 0fa7ede94fa6..fd51d12f2702 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -1653,9 +1653,7 @@ static int do_register_framebuffer(struct fb_info *fb_info)
console_lock();
else
atomic_inc(&ignore_console_lock_warning);
- lock_fb_info(fb_info);
ret = fbcon_fb_registered(fb_info);
- unlock_fb_info(fb_info);
if (!lockless_register_fb)
console_unlock();
@@ -1672,9 +1670,7 @@ static void unbind_console(struct fb_info *fb_info)
return;
console_lock();
- lock_fb_info(fb_info);
fbcon_fb_unbind(fb_info);
- unlock_fb_info(fb_info);
console_unlock();
}
--
2.33.0
^ permalink raw reply related [flat|nested] 241+ messages in thread
* [PATCH 14/21] fbcon: use lock_fb_info in fbcon_open/release
@ 2022-01-31 21:05 ` Daniel Vetter
0 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-01-31 21:05 UTC (permalink / raw)
To: DRI Development
Cc: Intel Graphics Development, linux-fbdev, LKML, Daniel Vetter,
Daniel Vetter, Daniel Vetter, Claudio Suarez, Tetsuo Handa,
Thomas Zimmermann, Greg Kroah-Hartman, Du Cheng, Sam Ravnborg,
Matthew Wilcox, William Kucharski, Alex Deucher, Zheyu Ma,
Zhen Lei, Xiyu Yang
Now we get to the real motiviation, because fbmem.c insists that
that's the right lock for these.
Ofc fbcon.c has a lot more places where it probably should call
lock_fb_info(). But looking at fbmem.c at least most of these seem to
be protected by console_lock() too, which is probably what papers over
any issues.
Note that this means we're shuffling around a bit the locking sections
for some of the console takeover and unbind paths, but not all:
- console binding/unbinding from the console layer never with
lock_fb_info
- unbind (as opposed to unlink) never bother with lock_fb_info
Also the real serialization against set_par and set_pan are still
doing by wrapping the entire ioctl code in console_lock(). So this
shuffling shouldn't be worse than what we had from a "can you trigger
races?" pov, but it's at least clearer.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Claudio Suarez <cssk@net-c.es>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Du Cheng <ducheng2@gmail.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: William Kucharski <william.kucharski@oracle.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Zheyu Ma <zheyuma97@gmail.com>
Cc: Zhen Lei <thunder.leizhen@huawei.com>
Cc: Xiyu Yang <xiyuyang19@fudan.edu.cn>
---
drivers/video/fbdev/core/fbcon.c | 5 +++++
drivers/video/fbdev/core/fbmem.c | 4 ----
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 5a3391ff038d..496bc5f2133e 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -682,8 +682,10 @@ static int fbcon_invalid_charcount(struct fb_info *info, unsigned charcount)
static void fbcon_release(struct fb_info *info)
{
+ lock_fb_info(info);
if (info->fbops->fb_release)
info->fbops->fb_release(info, 0);
+ unlock_fb_info(info);
module_put(info->fbops->owner);
}
@@ -695,11 +697,14 @@ static int fbcon_open(struct fb_info *info)
if (!try_module_get(info->fbops->owner))
return -ENODEV;
+ lock_fb_info(info);
if (info->fbops->fb_open &&
info->fbops->fb_open(info, 0)) {
+ unlock_fb_info(info);
module_put(info->fbops->owner);
return -ENODEV;
}
+ unlock_fb_info(info);
ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL);
if (!ops) {
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 0fa7ede94fa6..fd51d12f2702 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -1653,9 +1653,7 @@ static int do_register_framebuffer(struct fb_info *fb_info)
console_lock();
else
atomic_inc(&ignore_console_lock_warning);
- lock_fb_info(fb_info);
ret = fbcon_fb_registered(fb_info);
- unlock_fb_info(fb_info);
if (!lockless_register_fb)
console_unlock();
@@ -1672,9 +1670,7 @@ static void unbind_console(struct fb_info *fb_info)
return;
console_lock();
- lock_fb_info(fb_info);
fbcon_fb_unbind(fb_info);
- unlock_fb_info(fb_info);
console_unlock();
}
--
2.33.0
^ permalink raw reply related [flat|nested] 241+ messages in thread
* [PATCH 14/21] fbcon: use lock_fb_info in fbcon_open/release
@ 2022-01-31 21:05 ` Daniel Vetter
0 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-01-31 21:05 UTC (permalink / raw)
To: DRI Development
Cc: linux-fbdev, Thomas Zimmermann, Xiyu Yang, Du Cheng,
Tetsuo Handa, Daniel Vetter, Intel Graphics Development,
Zheyu Ma, LKML, Matthew Wilcox, William Kucharski,
Claudio Suarez, Greg Kroah-Hartman, Alex Deucher, Daniel Vetter,
Sam Ravnborg, Zhen Lei
Now we get to the real motiviation, because fbmem.c insists that
that's the right lock for these.
Ofc fbcon.c has a lot more places where it probably should call
lock_fb_info(). But looking at fbmem.c at least most of these seem to
be protected by console_lock() too, which is probably what papers over
any issues.
Note that this means we're shuffling around a bit the locking sections
for some of the console takeover and unbind paths, but not all:
- console binding/unbinding from the console layer never with
lock_fb_info
- unbind (as opposed to unlink) never bother with lock_fb_info
Also the real serialization against set_par and set_pan are still
doing by wrapping the entire ioctl code in console_lock(). So this
shuffling shouldn't be worse than what we had from a "can you trigger
races?" pov, but it's at least clearer.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Claudio Suarez <cssk@net-c.es>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Du Cheng <ducheng2@gmail.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: William Kucharski <william.kucharski@oracle.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Zheyu Ma <zheyuma97@gmail.com>
Cc: Zhen Lei <thunder.leizhen@huawei.com>
Cc: Xiyu Yang <xiyuyang19@fudan.edu.cn>
---
drivers/video/fbdev/core/fbcon.c | 5 +++++
drivers/video/fbdev/core/fbmem.c | 4 ----
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 5a3391ff038d..496bc5f2133e 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -682,8 +682,10 @@ static int fbcon_invalid_charcount(struct fb_info *info, unsigned charcount)
static void fbcon_release(struct fb_info *info)
{
+ lock_fb_info(info);
if (info->fbops->fb_release)
info->fbops->fb_release(info, 0);
+ unlock_fb_info(info);
module_put(info->fbops->owner);
}
@@ -695,11 +697,14 @@ static int fbcon_open(struct fb_info *info)
if (!try_module_get(info->fbops->owner))
return -ENODEV;
+ lock_fb_info(info);
if (info->fbops->fb_open &&
info->fbops->fb_open(info, 0)) {
+ unlock_fb_info(info);
module_put(info->fbops->owner);
return -ENODEV;
}
+ unlock_fb_info(info);
ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL);
if (!ops) {
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 0fa7ede94fa6..fd51d12f2702 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -1653,9 +1653,7 @@ static int do_register_framebuffer(struct fb_info *fb_info)
console_lock();
else
atomic_inc(&ignore_console_lock_warning);
- lock_fb_info(fb_info);
ret = fbcon_fb_registered(fb_info);
- unlock_fb_info(fb_info);
if (!lockless_register_fb)
console_unlock();
@@ -1672,9 +1670,7 @@ static void unbind_console(struct fb_info *fb_info)
return;
console_lock();
- lock_fb_info(fb_info);
fbcon_fb_unbind(fb_info);
- unlock_fb_info(fb_info);
console_unlock();
}
--
2.33.0
^ permalink raw reply related [flat|nested] 241+ messages in thread
* [PATCH 15/21] fbcon: Consistently protect deferred_takeover with console_lock()
2022-01-31 21:05 ` Daniel Vetter
(?)
@ 2022-01-31 21:05 ` Daniel Vetter
-1 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-01-31 21:05 UTC (permalink / raw)
To: DRI Development
Cc: linux-fbdev, Thomas Zimmermann, Du Cheng, Tetsuo Handa,
Daniel Vetter, Intel Graphics Development, LKML, Claudio Suarez,
Daniel Vetter
This shouldn't be a problem in practice since until we've actually
taken over the console there's nothing we've registered with the
console/vt subsystem, so the exit/unbind path that check this can't
do the wrong thing. But it's confusing, so fix it by moving it a tad
later.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Du Cheng <ducheng2@gmail.com>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Claudio Suarez <cssk@net-c.es>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
---
drivers/video/fbdev/core/fbcon.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 496bc5f2133e..11b9f962af6f 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -3247,6 +3247,9 @@ static void fbcon_register_existing_fbs(struct work_struct *work)
console_lock();
+ deferred_takeover = false;
+ logo_shown = FBCON_LOGO_DONTSHOW;
+
for_each_registered_fb(i)
fbcon_fb_registered(registered_fb[i]);
@@ -3264,8 +3267,6 @@ static int fbcon_output_notifier(struct notifier_block *nb,
pr_info("fbcon: Taking over console\n");
dummycon_unregister_output_notifier(&fbcon_output_nb);
- deferred_takeover = false;
- logo_shown = FBCON_LOGO_DONTSHOW;
/* We may get called in atomic context */
schedule_work(&fbcon_deferred_takeover_work);
--
2.33.0
^ permalink raw reply related [flat|nested] 241+ messages in thread
* [Intel-gfx] [PATCH 15/21] fbcon: Consistently protect deferred_takeover with console_lock()
@ 2022-01-31 21:05 ` Daniel Vetter
0 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-01-31 21:05 UTC (permalink / raw)
To: DRI Development
Cc: linux-fbdev, Thomas Zimmermann, Du Cheng, Tetsuo Handa,
Daniel Vetter, Intel Graphics Development, LKML, Daniel Vetter
This shouldn't be a problem in practice since until we've actually
taken over the console there's nothing we've registered with the
console/vt subsystem, so the exit/unbind path that check this can't
do the wrong thing. But it's confusing, so fix it by moving it a tad
later.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Du Cheng <ducheng2@gmail.com>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Claudio Suarez <cssk@net-c.es>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
---
drivers/video/fbdev/core/fbcon.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 496bc5f2133e..11b9f962af6f 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -3247,6 +3247,9 @@ static void fbcon_register_existing_fbs(struct work_struct *work)
console_lock();
+ deferred_takeover = false;
+ logo_shown = FBCON_LOGO_DONTSHOW;
+
for_each_registered_fb(i)
fbcon_fb_registered(registered_fb[i]);
@@ -3264,8 +3267,6 @@ static int fbcon_output_notifier(struct notifier_block *nb,
pr_info("fbcon: Taking over console\n");
dummycon_unregister_output_notifier(&fbcon_output_nb);
- deferred_takeover = false;
- logo_shown = FBCON_LOGO_DONTSHOW;
/* We may get called in atomic context */
schedule_work(&fbcon_deferred_takeover_work);
--
2.33.0
^ permalink raw reply related [flat|nested] 241+ messages in thread
* [PATCH 15/21] fbcon: Consistently protect deferred_takeover with console_lock()
@ 2022-01-31 21:05 ` Daniel Vetter
0 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-01-31 21:05 UTC (permalink / raw)
To: DRI Development
Cc: Intel Graphics Development, linux-fbdev, LKML, Daniel Vetter,
Daniel Vetter, Daniel Vetter, Du Cheng, Tetsuo Handa,
Claudio Suarez, Thomas Zimmermann
This shouldn't be a problem in practice since until we've actually
taken over the console there's nothing we've registered with the
console/vt subsystem, so the exit/unbind path that check this can't
do the wrong thing. But it's confusing, so fix it by moving it a tad
later.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Du Cheng <ducheng2@gmail.com>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Claudio Suarez <cssk@net-c.es>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
---
drivers/video/fbdev/core/fbcon.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 496bc5f2133e..11b9f962af6f 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -3247,6 +3247,9 @@ static void fbcon_register_existing_fbs(struct work_struct *work)
console_lock();
+ deferred_takeover = false;
+ logo_shown = FBCON_LOGO_DONTSHOW;
+
for_each_registered_fb(i)
fbcon_fb_registered(registered_fb[i]);
@@ -3264,8 +3267,6 @@ static int fbcon_output_notifier(struct notifier_block *nb,
pr_info("fbcon: Taking over console\n");
dummycon_unregister_output_notifier(&fbcon_output_nb);
- deferred_takeover = false;
- logo_shown = FBCON_LOGO_DONTSHOW;
/* We may get called in atomic context */
schedule_work(&fbcon_deferred_takeover_work);
--
2.33.0
^ permalink raw reply related [flat|nested] 241+ messages in thread
* [PATCH 16/21] fbcon: Move console_lock for register/unlink/unregister
2022-01-31 21:05 ` Daniel Vetter
(?)
@ 2022-01-31 21:05 ` Daniel Vetter
-1 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-01-31 21:05 UTC (permalink / raw)
To: DRI Development
Cc: linux-fbdev, Thomas Zimmermann, Xiyu Yang, Du Cheng,
Tetsuo Handa, Daniel Vetter, Intel Graphics Development,
Zheyu Ma, LKML, Matthew Wilcox, Claudio Suarez,
Greg Kroah-Hartman, Alex Deucher, Daniel Vetter, Sam Ravnborg,
Zhen Lei, Guenter Roeck
Ideally console_lock becomes an implementation detail of fbcon.c and
doesn't show up anywhere in fbmem.c. We're still pretty far from that,
but at least the register/unregister code is there now.
With this the do_fb_ioctl() handler is the only code in fbmem.c still
calling console_lock().
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Du Cheng <ducheng2@gmail.com>
Cc: Claudio Suarez <cssk@net-c.es>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Zheyu Ma <zheyuma97@gmail.com>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Zhen Lei <thunder.leizhen@huawei.com>
Cc: Xiyu Yang <xiyuyang19@fudan.edu.cn>
---
drivers/video/fbdev/core/fbcon.c | 33 ++++++++++++++++++++++++++------
drivers/video/fbdev/core/fbmem.c | 23 ++--------------------
2 files changed, 29 insertions(+), 27 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 11b9f962af6f..e5e8aaf6f60d 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -2776,10 +2776,12 @@ void fbcon_fb_unbind(struct fb_info *info)
int i, new_idx = -1;
int idx = info->node;
- WARN_CONSOLE_UNLOCKED();
+ console_lock();
- if (!fbcon_has_console_bind)
+ if (!fbcon_has_console_bind) {
+ console_unlock();
return;
+ }
for (i = first_fb_vc; i <= last_fb_vc; i++) {
if (con2fb_map[i] != idx &&
@@ -2814,6 +2816,8 @@ void fbcon_fb_unbind(struct fb_info *info)
}
fbcon_unbind();
}
+
+ console_unlock();
}
/* called with console_lock held */
@@ -2821,10 +2825,12 @@ void fbcon_fb_unregistered(struct fb_info *info)
{
int i, idx;
- WARN_CONSOLE_UNLOCKED();
+ console_lock();
- if (deferred_takeover)
+ if (deferred_takeover) {
+ console_unlock();
return;
+ }
idx = info->node;
for (i = first_fb_vc; i <= last_fb_vc; i++) {
@@ -2853,6 +2859,7 @@ void fbcon_fb_unregistered(struct fb_info *info)
if (!num_registered_fb)
do_unregister_con_driver(&fb_con);
+ console_unlock();
}
void fbcon_remap_all(struct fb_info *info)
@@ -2910,19 +2917,27 @@ static inline void fbcon_select_primary(struct fb_info *info)
}
#endif /* CONFIG_FRAMEBUFFER_DETECT_PRIMARY */
+static bool lockless_register_fb;
+module_param_named_unsafe(lockless_register_fb, lockless_register_fb, bool, 0400);
+MODULE_PARM_DESC(lockless_register_fb,
+ "Lockless framebuffer registration for debugging [default=off]");
+
/* called with console_lock held */
int fbcon_fb_registered(struct fb_info *info)
{
int ret = 0, i, idx;
- WARN_CONSOLE_UNLOCKED();
+ if (!lockless_register_fb)
+ console_lock();
+ else
+ atomic_inc(&ignore_console_lock_warning);
idx = info->node;
fbcon_select_primary(info);
if (deferred_takeover) {
pr_info("fbcon: Deferring console take-over\n");
- return 0;
+ goto out;
}
if (info_idx == -1) {
@@ -2942,6 +2957,12 @@ int fbcon_fb_registered(struct fb_info *info)
}
}
+out:
+ if (!lockless_register_fb)
+ console_unlock();
+ else
+ atomic_dec(&ignore_console_lock_warning);
+
return ret;
}
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index fd51d12f2702..904ef1250677 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -1573,14 +1573,9 @@ static void do_remove_conflicting_framebuffers(struct apertures_struct *a,
}
}
-static bool lockless_register_fb;
-module_param_named_unsafe(lockless_register_fb, lockless_register_fb, bool, 0400);
-MODULE_PARM_DESC(lockless_register_fb,
- "Lockless framebuffer registration for debugging [default=off]");
-
static int do_register_framebuffer(struct fb_info *fb_info)
{
- int i, ret;
+ int i;
struct fb_videomode mode;
if (fb_check_foreignness(fb_info))
@@ -1649,17 +1644,7 @@ static int do_register_framebuffer(struct fb_info *fb_info)
}
#endif
- if (!lockless_register_fb)
- console_lock();
- else
- atomic_inc(&ignore_console_lock_warning);
- ret = fbcon_fb_registered(fb_info);
-
- if (!lockless_register_fb)
- console_unlock();
- else
- atomic_dec(&ignore_console_lock_warning);
- return ret;
+ return fbcon_fb_registered(fb_info);
}
static void unbind_console(struct fb_info *fb_info)
@@ -1669,9 +1654,7 @@ static void unbind_console(struct fb_info *fb_info)
if (WARN_ON(i < 0 || i >= FB_MAX || registered_fb[i] != fb_info))
return;
- console_lock();
fbcon_fb_unbind(fb_info);
- console_unlock();
}
static void unlink_framebuffer(struct fb_info *fb_info)
@@ -1714,9 +1697,7 @@ static void do_unregister_framebuffer(struct fb_info *fb_info)
fb_notifier_call_chain(FB_EVENT_FB_UNREGISTERED, &event);
}
#endif
- console_lock();
fbcon_fb_unregistered(fb_info);
- console_unlock();
/* this may free fb info */
put_fb_info(fb_info);
--
2.33.0
^ permalink raw reply related [flat|nested] 241+ messages in thread
* [Intel-gfx] [PATCH 16/21] fbcon: Move console_lock for register/unlink/unregister
@ 2022-01-31 21:05 ` Daniel Vetter
0 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-01-31 21:05 UTC (permalink / raw)
To: DRI Development
Cc: linux-fbdev, Thomas Zimmermann, Xiyu Yang, Du Cheng,
Tetsuo Handa, Daniel Vetter, Intel Graphics Development,
Zheyu Ma, LKML, Matthew Wilcox, Greg Kroah-Hartman, Alex Deucher,
Daniel Vetter, Sam Ravnborg, Zhen Lei, Guenter Roeck
Ideally console_lock becomes an implementation detail of fbcon.c and
doesn't show up anywhere in fbmem.c. We're still pretty far from that,
but at least the register/unregister code is there now.
With this the do_fb_ioctl() handler is the only code in fbmem.c still
calling console_lock().
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Du Cheng <ducheng2@gmail.com>
Cc: Claudio Suarez <cssk@net-c.es>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Zheyu Ma <zheyuma97@gmail.com>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Zhen Lei <thunder.leizhen@huawei.com>
Cc: Xiyu Yang <xiyuyang19@fudan.edu.cn>
---
drivers/video/fbdev/core/fbcon.c | 33 ++++++++++++++++++++++++++------
drivers/video/fbdev/core/fbmem.c | 23 ++--------------------
2 files changed, 29 insertions(+), 27 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 11b9f962af6f..e5e8aaf6f60d 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -2776,10 +2776,12 @@ void fbcon_fb_unbind(struct fb_info *info)
int i, new_idx = -1;
int idx = info->node;
- WARN_CONSOLE_UNLOCKED();
+ console_lock();
- if (!fbcon_has_console_bind)
+ if (!fbcon_has_console_bind) {
+ console_unlock();
return;
+ }
for (i = first_fb_vc; i <= last_fb_vc; i++) {
if (con2fb_map[i] != idx &&
@@ -2814,6 +2816,8 @@ void fbcon_fb_unbind(struct fb_info *info)
}
fbcon_unbind();
}
+
+ console_unlock();
}
/* called with console_lock held */
@@ -2821,10 +2825,12 @@ void fbcon_fb_unregistered(struct fb_info *info)
{
int i, idx;
- WARN_CONSOLE_UNLOCKED();
+ console_lock();
- if (deferred_takeover)
+ if (deferred_takeover) {
+ console_unlock();
return;
+ }
idx = info->node;
for (i = first_fb_vc; i <= last_fb_vc; i++) {
@@ -2853,6 +2859,7 @@ void fbcon_fb_unregistered(struct fb_info *info)
if (!num_registered_fb)
do_unregister_con_driver(&fb_con);
+ console_unlock();
}
void fbcon_remap_all(struct fb_info *info)
@@ -2910,19 +2917,27 @@ static inline void fbcon_select_primary(struct fb_info *info)
}
#endif /* CONFIG_FRAMEBUFFER_DETECT_PRIMARY */
+static bool lockless_register_fb;
+module_param_named_unsafe(lockless_register_fb, lockless_register_fb, bool, 0400);
+MODULE_PARM_DESC(lockless_register_fb,
+ "Lockless framebuffer registration for debugging [default=off]");
+
/* called with console_lock held */
int fbcon_fb_registered(struct fb_info *info)
{
int ret = 0, i, idx;
- WARN_CONSOLE_UNLOCKED();
+ if (!lockless_register_fb)
+ console_lock();
+ else
+ atomic_inc(&ignore_console_lock_warning);
idx = info->node;
fbcon_select_primary(info);
if (deferred_takeover) {
pr_info("fbcon: Deferring console take-over\n");
- return 0;
+ goto out;
}
if (info_idx == -1) {
@@ -2942,6 +2957,12 @@ int fbcon_fb_registered(struct fb_info *info)
}
}
+out:
+ if (!lockless_register_fb)
+ console_unlock();
+ else
+ atomic_dec(&ignore_console_lock_warning);
+
return ret;
}
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index fd51d12f2702..904ef1250677 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -1573,14 +1573,9 @@ static void do_remove_conflicting_framebuffers(struct apertures_struct *a,
}
}
-static bool lockless_register_fb;
-module_param_named_unsafe(lockless_register_fb, lockless_register_fb, bool, 0400);
-MODULE_PARM_DESC(lockless_register_fb,
- "Lockless framebuffer registration for debugging [default=off]");
-
static int do_register_framebuffer(struct fb_info *fb_info)
{
- int i, ret;
+ int i;
struct fb_videomode mode;
if (fb_check_foreignness(fb_info))
@@ -1649,17 +1644,7 @@ static int do_register_framebuffer(struct fb_info *fb_info)
}
#endif
- if (!lockless_register_fb)
- console_lock();
- else
- atomic_inc(&ignore_console_lock_warning);
- ret = fbcon_fb_registered(fb_info);
-
- if (!lockless_register_fb)
- console_unlock();
- else
- atomic_dec(&ignore_console_lock_warning);
- return ret;
+ return fbcon_fb_registered(fb_info);
}
static void unbind_console(struct fb_info *fb_info)
@@ -1669,9 +1654,7 @@ static void unbind_console(struct fb_info *fb_info)
if (WARN_ON(i < 0 || i >= FB_MAX || registered_fb[i] != fb_info))
return;
- console_lock();
fbcon_fb_unbind(fb_info);
- console_unlock();
}
static void unlink_framebuffer(struct fb_info *fb_info)
@@ -1714,9 +1697,7 @@ static void do_unregister_framebuffer(struct fb_info *fb_info)
fb_notifier_call_chain(FB_EVENT_FB_UNREGISTERED, &event);
}
#endif
- console_lock();
fbcon_fb_unregistered(fb_info);
- console_unlock();
/* this may free fb info */
put_fb_info(fb_info);
--
2.33.0
^ permalink raw reply related [flat|nested] 241+ messages in thread
* [PATCH 16/21] fbcon: Move console_lock for register/unlink/unregister
@ 2022-01-31 21:05 ` Daniel Vetter
0 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-01-31 21:05 UTC (permalink / raw)
To: DRI Development
Cc: Intel Graphics Development, linux-fbdev, LKML, Daniel Vetter,
Daniel Vetter, Daniel Vetter, Thomas Zimmermann, Du Cheng,
Claudio Suarez, Greg Kroah-Hartman, Tetsuo Handa, Matthew Wilcox,
Sam Ravnborg, Zheyu Ma, Guenter Roeck, Alex Deucher, Zhen Lei,
Xiyu Yang
Ideally console_lock becomes an implementation detail of fbcon.c and
doesn't show up anywhere in fbmem.c. We're still pretty far from that,
but at least the register/unregister code is there now.
With this the do_fb_ioctl() handler is the only code in fbmem.c still
calling console_lock().
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Du Cheng <ducheng2@gmail.com>
Cc: Claudio Suarez <cssk@net-c.es>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Zheyu Ma <zheyuma97@gmail.com>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Zhen Lei <thunder.leizhen@huawei.com>
Cc: Xiyu Yang <xiyuyang19@fudan.edu.cn>
---
drivers/video/fbdev/core/fbcon.c | 33 ++++++++++++++++++++++++++------
drivers/video/fbdev/core/fbmem.c | 23 ++--------------------
2 files changed, 29 insertions(+), 27 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 11b9f962af6f..e5e8aaf6f60d 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -2776,10 +2776,12 @@ void fbcon_fb_unbind(struct fb_info *info)
int i, new_idx = -1;
int idx = info->node;
- WARN_CONSOLE_UNLOCKED();
+ console_lock();
- if (!fbcon_has_console_bind)
+ if (!fbcon_has_console_bind) {
+ console_unlock();
return;
+ }
for (i = first_fb_vc; i <= last_fb_vc; i++) {
if (con2fb_map[i] != idx &&
@@ -2814,6 +2816,8 @@ void fbcon_fb_unbind(struct fb_info *info)
}
fbcon_unbind();
}
+
+ console_unlock();
}
/* called with console_lock held */
@@ -2821,10 +2825,12 @@ void fbcon_fb_unregistered(struct fb_info *info)
{
int i, idx;
- WARN_CONSOLE_UNLOCKED();
+ console_lock();
- if (deferred_takeover)
+ if (deferred_takeover) {
+ console_unlock();
return;
+ }
idx = info->node;
for (i = first_fb_vc; i <= last_fb_vc; i++) {
@@ -2853,6 +2859,7 @@ void fbcon_fb_unregistered(struct fb_info *info)
if (!num_registered_fb)
do_unregister_con_driver(&fb_con);
+ console_unlock();
}
void fbcon_remap_all(struct fb_info *info)
@@ -2910,19 +2917,27 @@ static inline void fbcon_select_primary(struct fb_info *info)
}
#endif /* CONFIG_FRAMEBUFFER_DETECT_PRIMARY */
+static bool lockless_register_fb;
+module_param_named_unsafe(lockless_register_fb, lockless_register_fb, bool, 0400);
+MODULE_PARM_DESC(lockless_register_fb,
+ "Lockless framebuffer registration for debugging [default=off]");
+
/* called with console_lock held */
int fbcon_fb_registered(struct fb_info *info)
{
int ret = 0, i, idx;
- WARN_CONSOLE_UNLOCKED();
+ if (!lockless_register_fb)
+ console_lock();
+ else
+ atomic_inc(&ignore_console_lock_warning);
idx = info->node;
fbcon_select_primary(info);
if (deferred_takeover) {
pr_info("fbcon: Deferring console take-over\n");
- return 0;
+ goto out;
}
if (info_idx == -1) {
@@ -2942,6 +2957,12 @@ int fbcon_fb_registered(struct fb_info *info)
}
}
+out:
+ if (!lockless_register_fb)
+ console_unlock();
+ else
+ atomic_dec(&ignore_console_lock_warning);
+
return ret;
}
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index fd51d12f2702..904ef1250677 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -1573,14 +1573,9 @@ static void do_remove_conflicting_framebuffers(struct apertures_struct *a,
}
}
-static bool lockless_register_fb;
-module_param_named_unsafe(lockless_register_fb, lockless_register_fb, bool, 0400);
-MODULE_PARM_DESC(lockless_register_fb,
- "Lockless framebuffer registration for debugging [default=off]");
-
static int do_register_framebuffer(struct fb_info *fb_info)
{
- int i, ret;
+ int i;
struct fb_videomode mode;
if (fb_check_foreignness(fb_info))
@@ -1649,17 +1644,7 @@ static int do_register_framebuffer(struct fb_info *fb_info)
}
#endif
- if (!lockless_register_fb)
- console_lock();
- else
- atomic_inc(&ignore_console_lock_warning);
- ret = fbcon_fb_registered(fb_info);
-
- if (!lockless_register_fb)
- console_unlock();
- else
- atomic_dec(&ignore_console_lock_warning);
- return ret;
+ return fbcon_fb_registered(fb_info);
}
static void unbind_console(struct fb_info *fb_info)
@@ -1669,9 +1654,7 @@ static void unbind_console(struct fb_info *fb_info)
if (WARN_ON(i < 0 || i >= FB_MAX || registered_fb[i] != fb_info))
return;
- console_lock();
fbcon_fb_unbind(fb_info);
- console_unlock();
}
static void unlink_framebuffer(struct fb_info *fb_info)
@@ -1714,9 +1697,7 @@ static void do_unregister_framebuffer(struct fb_info *fb_info)
fb_notifier_call_chain(FB_EVENT_FB_UNREGISTERED, &event);
}
#endif
- console_lock();
fbcon_fb_unregistered(fb_info);
- console_unlock();
/* this may free fb info */
put_fb_info(fb_info);
--
2.33.0
^ permalink raw reply related [flat|nested] 241+ messages in thread
* [PATCH 17/21] fbcon: Move more code into fbcon_release
2022-01-31 21:05 ` Daniel Vetter
(?)
@ 2022-01-31 21:05 ` Daniel Vetter
-1 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-01-31 21:05 UTC (permalink / raw)
To: DRI Development
Cc: linux-fbdev, Du Cheng, Tetsuo Handa, Daniel Vetter,
Intel Graphics Development, LKML, Claudio Suarez,
Greg Kroah-Hartman, Daniel Vetter
con2fb_release_oldinfo() has a bunch more kfree() calls than
fbcon_exit(), but since kfree() on NULL is harmless doing that in both
places should be ok. This is also a bit more symmetric now again with
fbcon_open also allocating the fbcon_ops structure.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Du Cheng <ducheng2@gmail.com>
Cc: Claudio Suarez <cssk@net-c.es>
---
drivers/video/fbdev/core/fbcon.c | 33 +++++++++++++-------------------
1 file changed, 13 insertions(+), 20 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index e5e8aaf6f60d..5c14e24d14a1 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -688,6 +688,18 @@ static void fbcon_release(struct fb_info *info)
unlock_fb_info(info);
module_put(info->fbops->owner);
+
+ if (info->fbcon_par) {
+ struct fbcon_ops *ops = info->fbcon_par;
+
+ fbcon_del_cursor_work(info);
+ kfree(ops->cursor_state.mask);
+ kfree(ops->cursor_data);
+ kfree(ops->cursor_src);
+ kfree(ops->fontbuffer);
+ kfree(info->fbcon_par);
+ info->fbcon_par = NULL;
+ }
}
static int fbcon_open(struct fb_info *info)
@@ -741,18 +753,10 @@ static int con2fb_acquire_newinfo(struct vc_data *vc, struct fb_info *info,
static void con2fb_release_oldinfo(struct vc_data *vc, struct fb_info *oldinfo,
struct fb_info *newinfo)
{
- struct fbcon_ops *ops = oldinfo->fbcon_par;
int ret;
fbcon_release(oldinfo);
- fbcon_del_cursor_work(oldinfo);
- kfree(ops->cursor_state.mask);
- kfree(ops->cursor_data);
- kfree(ops->cursor_src);
- kfree(ops->fontbuffer);
- kfree(oldinfo->fbcon_par);
- oldinfo->fbcon_par = NULL;
/*
If oldinfo and newinfo are driving the same hardware,
the fb_release() method of oldinfo may attempt to
@@ -3335,19 +3339,8 @@ static void fbcon_exit(void)
}
}
- if (mapped) {
- if (info->fbcon_par) {
- struct fbcon_ops *ops = info->fbcon_par;
-
- fbcon_del_cursor_work(info);
- kfree(ops->cursor_src);
- kfree(ops->cursor_state.mask);
- kfree(info->fbcon_par);
- info->fbcon_par = NULL;
- }
-
+ if (mapped)
fbcon_release(info);
- }
}
}
--
2.33.0
^ permalink raw reply related [flat|nested] 241+ messages in thread
* [Intel-gfx] [PATCH 17/21] fbcon: Move more code into fbcon_release
@ 2022-01-31 21:05 ` Daniel Vetter
0 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-01-31 21:05 UTC (permalink / raw)
To: DRI Development
Cc: linux-fbdev, Du Cheng, Tetsuo Handa, Daniel Vetter,
Intel Graphics Development, LKML, Greg Kroah-Hartman,
Daniel Vetter
con2fb_release_oldinfo() has a bunch more kfree() calls than
fbcon_exit(), but since kfree() on NULL is harmless doing that in both
places should be ok. This is also a bit more symmetric now again with
fbcon_open also allocating the fbcon_ops structure.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Du Cheng <ducheng2@gmail.com>
Cc: Claudio Suarez <cssk@net-c.es>
---
drivers/video/fbdev/core/fbcon.c | 33 +++++++++++++-------------------
1 file changed, 13 insertions(+), 20 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index e5e8aaf6f60d..5c14e24d14a1 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -688,6 +688,18 @@ static void fbcon_release(struct fb_info *info)
unlock_fb_info(info);
module_put(info->fbops->owner);
+
+ if (info->fbcon_par) {
+ struct fbcon_ops *ops = info->fbcon_par;
+
+ fbcon_del_cursor_work(info);
+ kfree(ops->cursor_state.mask);
+ kfree(ops->cursor_data);
+ kfree(ops->cursor_src);
+ kfree(ops->fontbuffer);
+ kfree(info->fbcon_par);
+ info->fbcon_par = NULL;
+ }
}
static int fbcon_open(struct fb_info *info)
@@ -741,18 +753,10 @@ static int con2fb_acquire_newinfo(struct vc_data *vc, struct fb_info *info,
static void con2fb_release_oldinfo(struct vc_data *vc, struct fb_info *oldinfo,
struct fb_info *newinfo)
{
- struct fbcon_ops *ops = oldinfo->fbcon_par;
int ret;
fbcon_release(oldinfo);
- fbcon_del_cursor_work(oldinfo);
- kfree(ops->cursor_state.mask);
- kfree(ops->cursor_data);
- kfree(ops->cursor_src);
- kfree(ops->fontbuffer);
- kfree(oldinfo->fbcon_par);
- oldinfo->fbcon_par = NULL;
/*
If oldinfo and newinfo are driving the same hardware,
the fb_release() method of oldinfo may attempt to
@@ -3335,19 +3339,8 @@ static void fbcon_exit(void)
}
}
- if (mapped) {
- if (info->fbcon_par) {
- struct fbcon_ops *ops = info->fbcon_par;
-
- fbcon_del_cursor_work(info);
- kfree(ops->cursor_src);
- kfree(ops->cursor_state.mask);
- kfree(info->fbcon_par);
- info->fbcon_par = NULL;
- }
-
+ if (mapped)
fbcon_release(info);
- }
}
}
--
2.33.0
^ permalink raw reply related [flat|nested] 241+ messages in thread
* [PATCH 17/21] fbcon: Move more code into fbcon_release
@ 2022-01-31 21:05 ` Daniel Vetter
0 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-01-31 21:05 UTC (permalink / raw)
To: DRI Development
Cc: Intel Graphics Development, linux-fbdev, LKML, Daniel Vetter,
Daniel Vetter, Daniel Vetter, Tetsuo Handa, Greg Kroah-Hartman,
Du Cheng, Claudio Suarez
con2fb_release_oldinfo() has a bunch more kfree() calls than
fbcon_exit(), but since kfree() on NULL is harmless doing that in both
places should be ok. This is also a bit more symmetric now again with
fbcon_open also allocating the fbcon_ops structure.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Du Cheng <ducheng2@gmail.com>
Cc: Claudio Suarez <cssk@net-c.es>
---
drivers/video/fbdev/core/fbcon.c | 33 +++++++++++++-------------------
1 file changed, 13 insertions(+), 20 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index e5e8aaf6f60d..5c14e24d14a1 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -688,6 +688,18 @@ static void fbcon_release(struct fb_info *info)
unlock_fb_info(info);
module_put(info->fbops->owner);
+
+ if (info->fbcon_par) {
+ struct fbcon_ops *ops = info->fbcon_par;
+
+ fbcon_del_cursor_work(info);
+ kfree(ops->cursor_state.mask);
+ kfree(ops->cursor_data);
+ kfree(ops->cursor_src);
+ kfree(ops->fontbuffer);
+ kfree(info->fbcon_par);
+ info->fbcon_par = NULL;
+ }
}
static int fbcon_open(struct fb_info *info)
@@ -741,18 +753,10 @@ static int con2fb_acquire_newinfo(struct vc_data *vc, struct fb_info *info,
static void con2fb_release_oldinfo(struct vc_data *vc, struct fb_info *oldinfo,
struct fb_info *newinfo)
{
- struct fbcon_ops *ops = oldinfo->fbcon_par;
int ret;
fbcon_release(oldinfo);
- fbcon_del_cursor_work(oldinfo);
- kfree(ops->cursor_state.mask);
- kfree(ops->cursor_data);
- kfree(ops->cursor_src);
- kfree(ops->fontbuffer);
- kfree(oldinfo->fbcon_par);
- oldinfo->fbcon_par = NULL;
/*
If oldinfo and newinfo are driving the same hardware,
the fb_release() method of oldinfo may attempt to
@@ -3335,19 +3339,8 @@ static void fbcon_exit(void)
}
}
- if (mapped) {
- if (info->fbcon_par) {
- struct fbcon_ops *ops = info->fbcon_par;
-
- fbcon_del_cursor_work(info);
- kfree(ops->cursor_src);
- kfree(ops->cursor_state.mask);
- kfree(info->fbcon_par);
- info->fbcon_par = NULL;
- }
-
+ if (mapped)
fbcon_release(info);
- }
}
}
--
2.33.0
^ permalink raw reply related [flat|nested] 241+ messages in thread
* [PATCH 18/21] fbcon: untangle fbcon_exit
2022-01-31 21:05 ` Daniel Vetter
(?)
@ 2022-01-31 21:05 ` Daniel Vetter
-1 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-01-31 21:05 UTC (permalink / raw)
To: DRI Development
Cc: linux-fbdev, Du Cheng, Tetsuo Handa, Daniel Vetter,
Intel Graphics Development, LKML, Claudio Suarez,
Greg Kroah-Hartman, Daniel Vetter
There's a bunch of confusions going on here:
- The deferred fbcon setup notifier should only be cleaned up from
fb_console_exit(), to be symmetric with fb_console_init()
- We also need to make sure we don't race with the work, which means
temporarily dropping the console lock (or we can deadlock)
- That also means no point in clearing deferred_takeover, we are
unloading everything anyway.
- Finally rename fbcon_exit to fbcon_release_all and move it, since
that's what's it doing when being called from consw->con_deinit
through fbcon_deinit.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Claudio Suarez <cssk@net-c.es>
Cc: Du Cheng <ducheng2@gmail.com>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
---
drivers/video/fbdev/core/fbcon.c | 63 ++++++++++++++++----------------
1 file changed, 32 insertions(+), 31 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 5c14e24d14a1..22581952b4fd 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -185,7 +185,6 @@ static void fbcon_set_disp(struct fb_info *info, struct fb_var_screeninfo *var,
int unit);
static void fbcon_modechanged(struct fb_info *info);
static void fbcon_set_all_vcs(struct fb_info *info);
-static void fbcon_exit(void);
static struct device *fbcon_device;
@@ -1149,6 +1148,27 @@ static void fbcon_free_font(struct fbcon_display *p, bool freefont)
static void set_vc_hi_font(struct vc_data *vc, bool set);
+static void fbcon_release_all(void)
+{
+ struct fb_info *info;
+ int i, j, mapped;
+
+ for_each_registered_fb(i) {
+ mapped = 0;
+ info = registered_fb[i];
+
+ for (j = first_fb_vc; j <= last_fb_vc; j++) {
+ if (con2fb_map[j] == i) {
+ mapped = 1;
+ con2fb_map[j] = -1;
+ }
+ }
+
+ if (mapped)
+ fbcon_release(info);
+ }
+}
+
static void fbcon_deinit(struct vc_data *vc)
{
struct fbcon_display *p = &fb_display[vc->vc_num];
@@ -1188,7 +1208,7 @@ static void fbcon_deinit(struct vc_data *vc)
set_vc_hi_font(vc, false);
if (!con_is_bound(&fb_con))
- fbcon_exit();
+ fbcon_release_all();
if (vc->vc_num == logo_shown)
logo_shown = FBCON_LOGO_CANSHOW;
@@ -3316,34 +3336,6 @@ static void fbcon_start(void)
#endif
}
-static void fbcon_exit(void)
-{
- struct fb_info *info;
- int i, j, mapped;
-
-#ifdef CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER
- if (deferred_takeover) {
- dummycon_unregister_output_notifier(&fbcon_output_nb);
- deferred_takeover = false;
- }
-#endif
-
- for_each_registered_fb(i) {
- mapped = 0;
- info = registered_fb[i];
-
- for (j = first_fb_vc; j <= last_fb_vc; j++) {
- if (con2fb_map[j] == i) {
- mapped = 1;
- con2fb_map[j] = -1;
- }
- }
-
- if (mapped)
- fbcon_release(info);
- }
-}
-
void __init fb_console_init(void)
{
int i;
@@ -3383,10 +3375,19 @@ static void __exit fbcon_deinit_device(void)
void __exit fb_console_exit(void)
{
+#ifdef CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER
+ console_lock();
+ if (deferred_takeover)
+ dummycon_unregister_output_notifier(&fbcon_output_nb);
+ console_unlock();
+
+ cancel_work_sync(&fbcon_deferred_takeover_work);
+#endif
+
console_lock();
fbcon_deinit_device();
device_destroy(fb_class, MKDEV(0, 0));
- fbcon_exit();
+
do_unregister_con_driver(&fb_con);
console_unlock();
}
--
2.33.0
^ permalink raw reply related [flat|nested] 241+ messages in thread
* [Intel-gfx] [PATCH 18/21] fbcon: untangle fbcon_exit
@ 2022-01-31 21:05 ` Daniel Vetter
0 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-01-31 21:05 UTC (permalink / raw)
To: DRI Development
Cc: linux-fbdev, Du Cheng, Tetsuo Handa, Daniel Vetter,
Intel Graphics Development, LKML, Greg Kroah-Hartman,
Daniel Vetter
There's a bunch of confusions going on here:
- The deferred fbcon setup notifier should only be cleaned up from
fb_console_exit(), to be symmetric with fb_console_init()
- We also need to make sure we don't race with the work, which means
temporarily dropping the console lock (or we can deadlock)
- That also means no point in clearing deferred_takeover, we are
unloading everything anyway.
- Finally rename fbcon_exit to fbcon_release_all and move it, since
that's what's it doing when being called from consw->con_deinit
through fbcon_deinit.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Claudio Suarez <cssk@net-c.es>
Cc: Du Cheng <ducheng2@gmail.com>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
---
drivers/video/fbdev/core/fbcon.c | 63 ++++++++++++++++----------------
1 file changed, 32 insertions(+), 31 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 5c14e24d14a1..22581952b4fd 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -185,7 +185,6 @@ static void fbcon_set_disp(struct fb_info *info, struct fb_var_screeninfo *var,
int unit);
static void fbcon_modechanged(struct fb_info *info);
static void fbcon_set_all_vcs(struct fb_info *info);
-static void fbcon_exit(void);
static struct device *fbcon_device;
@@ -1149,6 +1148,27 @@ static void fbcon_free_font(struct fbcon_display *p, bool freefont)
static void set_vc_hi_font(struct vc_data *vc, bool set);
+static void fbcon_release_all(void)
+{
+ struct fb_info *info;
+ int i, j, mapped;
+
+ for_each_registered_fb(i) {
+ mapped = 0;
+ info = registered_fb[i];
+
+ for (j = first_fb_vc; j <= last_fb_vc; j++) {
+ if (con2fb_map[j] == i) {
+ mapped = 1;
+ con2fb_map[j] = -1;
+ }
+ }
+
+ if (mapped)
+ fbcon_release(info);
+ }
+}
+
static void fbcon_deinit(struct vc_data *vc)
{
struct fbcon_display *p = &fb_display[vc->vc_num];
@@ -1188,7 +1208,7 @@ static void fbcon_deinit(struct vc_data *vc)
set_vc_hi_font(vc, false);
if (!con_is_bound(&fb_con))
- fbcon_exit();
+ fbcon_release_all();
if (vc->vc_num == logo_shown)
logo_shown = FBCON_LOGO_CANSHOW;
@@ -3316,34 +3336,6 @@ static void fbcon_start(void)
#endif
}
-static void fbcon_exit(void)
-{
- struct fb_info *info;
- int i, j, mapped;
-
-#ifdef CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER
- if (deferred_takeover) {
- dummycon_unregister_output_notifier(&fbcon_output_nb);
- deferred_takeover = false;
- }
-#endif
-
- for_each_registered_fb(i) {
- mapped = 0;
- info = registered_fb[i];
-
- for (j = first_fb_vc; j <= last_fb_vc; j++) {
- if (con2fb_map[j] == i) {
- mapped = 1;
- con2fb_map[j] = -1;
- }
- }
-
- if (mapped)
- fbcon_release(info);
- }
-}
-
void __init fb_console_init(void)
{
int i;
@@ -3383,10 +3375,19 @@ static void __exit fbcon_deinit_device(void)
void __exit fb_console_exit(void)
{
+#ifdef CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER
+ console_lock();
+ if (deferred_takeover)
+ dummycon_unregister_output_notifier(&fbcon_output_nb);
+ console_unlock();
+
+ cancel_work_sync(&fbcon_deferred_takeover_work);
+#endif
+
console_lock();
fbcon_deinit_device();
device_destroy(fb_class, MKDEV(0, 0));
- fbcon_exit();
+
do_unregister_con_driver(&fb_con);
console_unlock();
}
--
2.33.0
^ permalink raw reply related [flat|nested] 241+ messages in thread
* [PATCH 18/21] fbcon: untangle fbcon_exit
@ 2022-01-31 21:05 ` Daniel Vetter
0 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-01-31 21:05 UTC (permalink / raw)
To: DRI Development
Cc: Intel Graphics Development, linux-fbdev, LKML, Daniel Vetter,
Daniel Vetter, Daniel Vetter, Greg Kroah-Hartman, Claudio Suarez,
Du Cheng, Tetsuo Handa
There's a bunch of confusions going on here:
- The deferred fbcon setup notifier should only be cleaned up from
fb_console_exit(), to be symmetric with fb_console_init()
- We also need to make sure we don't race with the work, which means
temporarily dropping the console lock (or we can deadlock)
- That also means no point in clearing deferred_takeover, we are
unloading everything anyway.
- Finally rename fbcon_exit to fbcon_release_all and move it, since
that's what's it doing when being called from consw->con_deinit
through fbcon_deinit.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Claudio Suarez <cssk@net-c.es>
Cc: Du Cheng <ducheng2@gmail.com>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
---
drivers/video/fbdev/core/fbcon.c | 63 ++++++++++++++++----------------
1 file changed, 32 insertions(+), 31 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 5c14e24d14a1..22581952b4fd 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -185,7 +185,6 @@ static void fbcon_set_disp(struct fb_info *info, struct fb_var_screeninfo *var,
int unit);
static void fbcon_modechanged(struct fb_info *info);
static void fbcon_set_all_vcs(struct fb_info *info);
-static void fbcon_exit(void);
static struct device *fbcon_device;
@@ -1149,6 +1148,27 @@ static void fbcon_free_font(struct fbcon_display *p, bool freefont)
static void set_vc_hi_font(struct vc_data *vc, bool set);
+static void fbcon_release_all(void)
+{
+ struct fb_info *info;
+ int i, j, mapped;
+
+ for_each_registered_fb(i) {
+ mapped = 0;
+ info = registered_fb[i];
+
+ for (j = first_fb_vc; j <= last_fb_vc; j++) {
+ if (con2fb_map[j] == i) {
+ mapped = 1;
+ con2fb_map[j] = -1;
+ }
+ }
+
+ if (mapped)
+ fbcon_release(info);
+ }
+}
+
static void fbcon_deinit(struct vc_data *vc)
{
struct fbcon_display *p = &fb_display[vc->vc_num];
@@ -1188,7 +1208,7 @@ static void fbcon_deinit(struct vc_data *vc)
set_vc_hi_font(vc, false);
if (!con_is_bound(&fb_con))
- fbcon_exit();
+ fbcon_release_all();
if (vc->vc_num == logo_shown)
logo_shown = FBCON_LOGO_CANSHOW;
@@ -3316,34 +3336,6 @@ static void fbcon_start(void)
#endif
}
-static void fbcon_exit(void)
-{
- struct fb_info *info;
- int i, j, mapped;
-
-#ifdef CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER
- if (deferred_takeover) {
- dummycon_unregister_output_notifier(&fbcon_output_nb);
- deferred_takeover = false;
- }
-#endif
-
- for_each_registered_fb(i) {
- mapped = 0;
- info = registered_fb[i];
-
- for (j = first_fb_vc; j <= last_fb_vc; j++) {
- if (con2fb_map[j] == i) {
- mapped = 1;
- con2fb_map[j] = -1;
- }
- }
-
- if (mapped)
- fbcon_release(info);
- }
-}
-
void __init fb_console_init(void)
{
int i;
@@ -3383,10 +3375,19 @@ static void __exit fbcon_deinit_device(void)
void __exit fb_console_exit(void)
{
+#ifdef CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER
+ console_lock();
+ if (deferred_takeover)
+ dummycon_unregister_output_notifier(&fbcon_output_nb);
+ console_unlock();
+
+ cancel_work_sync(&fbcon_deferred_takeover_work);
+#endif
+
console_lock();
fbcon_deinit_device();
device_destroy(fb_class, MKDEV(0, 0));
- fbcon_exit();
+
do_unregister_con_driver(&fb_con);
console_unlock();
}
--
2.33.0
^ permalink raw reply related [flat|nested] 241+ messages in thread
* [PATCH 19/21] fbcon: Maintain a private array of fb_info
2022-01-31 21:05 ` Daniel Vetter
(?)
@ 2022-01-31 21:05 ` Daniel Vetter
-1 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-01-31 21:05 UTC (permalink / raw)
To: DRI Development
Cc: linux-fbdev, Du Cheng, Tetsuo Handa, Daniel Vetter,
Intel Graphics Development, LKML, Claudio Suarez,
Greg Kroah-Hartman, Daniel Vetter
Accessing the one in fbmem.c without taking the right locks is a bad
idea. Instead maintain our own private copy, which is fully protected
by console_lock() (like everything else in fbcon.c). That copy is
serialized through fbcon_fb_registered/unregistered() calls.
Also this means we do not need to hold a full fb_info reference, which
is nice because doing so would mean a refcount loop between the
console and the fb_info. But it's also not nice since it means
console_lock() must be held absolutely everywhere. Well strictly
speaking we could still try to do some refcounting games again by
calling get_fb_info before we drop the console_lock. But things will
get tricky.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Claudio Suarez <cssk@net-c.es>
Cc: Du Cheng <ducheng2@gmail.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/video/fbdev/core/fbcon.c | 82 +++++++++++++++++---------------
1 file changed, 43 insertions(+), 39 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 22581952b4fd..a0ca34b29615 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -86,10 +86,6 @@
* - fbcon state itself is protected by the console_lock, and the code does a
* pretty good job at making sure that lock is held everywhere it's needed.
*
- * - access to the registered_fb array is entirely unprotected. This should use
- * proper object lifetime handling, i.e. get/put_fb_info. This also means
- * switching from indices to proper pointers for fb_info everywhere.
- *
* - fbcon doesn't bother with fb_lock/unlock at all. This is buggy, since it
* means concurrent access to the same fbdev from both fbcon and userspace
* will blow up. To fix this all fbcon calls from fbmem.c need to be moved out
@@ -107,6 +103,13 @@ enum {
static struct fbcon_display fb_display[MAX_NR_CONSOLES];
+struct fb_info *fbcon_registered_fb[FB_MAX];
+int fbcon_num_registered_fb;
+
+#define fbcon_for_each_registered_fb(i) \
+ for (i = 0; WARN_CONSOLE_UNLOCKED(), i < FB_MAX; i++) \
+ if (!fbcon_registered_fb[i]) {} else
+
static signed char con2fb_map[MAX_NR_CONSOLES];
static signed char con2fb_map_boot[MAX_NR_CONSOLES];
@@ -114,12 +117,7 @@ static struct fb_info *fbcon_info_from_console(int console)
{
WARN_CONSOLE_UNLOCKED();
- /*
- * Note that only con2fb_map is protected by the console lock,
- * registered_fb is protected by a separate mutex. This lookup can
- * therefore race.
- */
- return registered_fb[con2fb_map[console]];
+ return fbcon_registered_fb[con2fb_map[console]];
}
static int logo_lines;
@@ -516,7 +514,7 @@ static int do_fbcon_takeover(int show_logo)
{
int err, i;
- if (!num_registered_fb)
+ if (!fbcon_num_registered_fb)
return -ENODEV;
if (!show_logo)
@@ -822,7 +820,7 @@ static int set_con2fb_map(int unit, int newidx, int user)
{
struct vc_data *vc = vc_cons[unit].d;
int oldidx = con2fb_map[unit];
- struct fb_info *info = registered_fb[newidx];
+ struct fb_info *info = fbcon_registered_fb[newidx];
struct fb_info *oldinfo = NULL;
int found, err = 0, show_logo;
@@ -840,7 +838,7 @@ static int set_con2fb_map(int unit, int newidx, int user)
}
if (oldidx != -1)
- oldinfo = registered_fb[oldidx];
+ oldinfo = fbcon_registered_fb[oldidx];
found = search_fb_in_map(newidx);
@@ -932,13 +930,13 @@ static const char *fbcon_startup(void)
* If num_registered_fb is zero, this is a call for the dummy part.
* The frame buffer devices weren't initialized yet.
*/
- if (!num_registered_fb || info_idx == -1)
+ if (!fbcon_num_registered_fb || info_idx == -1)
return display_desc;
/*
* Instead of blindly using registered_fb[0], we use info_idx, set by
* fbcon_fb_registered();
*/
- info = registered_fb[info_idx];
+ info = fbcon_registered_fb[info_idx];
if (!info)
return NULL;
@@ -1153,9 +1151,9 @@ static void fbcon_release_all(void)
struct fb_info *info;
int i, j, mapped;
- for_each_registered_fb(i) {
+ fbcon_for_each_registered_fb(i) {
mapped = 0;
- info = registered_fb[i];
+ info = fbcon_registered_fb[i];
for (j = first_fb_vc; j <= last_fb_vc; j++) {
if (con2fb_map[j] == i) {
@@ -1182,7 +1180,7 @@ static void fbcon_deinit(struct vc_data *vc)
if (idx == -1)
goto finished;
- info = registered_fb[idx];
+ info = fbcon_registered_fb[idx];
if (!info)
goto finished;
@@ -2118,9 +2116,9 @@ static int fbcon_switch(struct vc_data *vc)
*
* info->currcon = vc->vc_num;
*/
- for_each_registered_fb(i) {
- if (registered_fb[i]->fbcon_par) {
- struct fbcon_ops *o = registered_fb[i]->fbcon_par;
+ fbcon_for_each_registered_fb(i) {
+ if (fbcon_registered_fb[i]->fbcon_par) {
+ struct fbcon_ops *o = fbcon_registered_fb[i]->fbcon_par;
o->currcon = vc->vc_num;
}
@@ -2765,7 +2763,7 @@ int fbcon_mode_deleted(struct fb_info *info,
j = con2fb_map[i];
if (j == -1)
continue;
- fb_info = registered_fb[j];
+ fb_info = fbcon_registered_fb[j];
if (fb_info != info)
continue;
p = &fb_display[i];
@@ -2821,7 +2819,7 @@ void fbcon_fb_unbind(struct fb_info *info)
set_con2fb_map(i, new_idx, 0);
}
} else {
- struct fb_info *info = registered_fb[idx];
+ struct fb_info *info = fbcon_registered_fb[idx];
/* This is sort of like set_con2fb_map, except it maps
* the consoles to no device and then releases the
@@ -2851,6 +2849,9 @@ void fbcon_fb_unregistered(struct fb_info *info)
console_lock();
+ fbcon_registered_fb[info->node] = NULL;
+ fbcon_num_registered_fb--;
+
if (deferred_takeover) {
console_unlock();
return;
@@ -2865,7 +2866,7 @@ void fbcon_fb_unregistered(struct fb_info *info)
if (idx == info_idx) {
info_idx = -1;
- for_each_registered_fb(i) {
+ fbcon_for_each_registered_fb(i) {
info_idx = i;
break;
}
@@ -2881,7 +2882,7 @@ void fbcon_fb_unregistered(struct fb_info *info)
if (primary_device == idx)
primary_device = -1;
- if (!num_registered_fb)
+ if (!fbcon_num_registered_fb)
do_unregister_con_driver(&fb_con);
console_unlock();
}
@@ -2956,6 +2957,9 @@ int fbcon_fb_registered(struct fb_info *info)
else
atomic_inc(&ignore_console_lock_warning);
+ fbcon_registered_fb[info->node] = info;
+ fbcon_num_registered_fb++;
+
idx = info->node;
fbcon_select_primary(info);
@@ -3075,9 +3079,9 @@ int fbcon_set_con2fb_map_ioctl(void __user *argp)
return -EINVAL;
if (con2fb.framebuffer >= FB_MAX)
return -EINVAL;
- if (!registered_fb[con2fb.framebuffer])
+ if (!fbcon_registered_fb[con2fb.framebuffer])
request_module("fb%d", con2fb.framebuffer);
- if (!registered_fb[con2fb.framebuffer]) {
+ if (!fbcon_registered_fb[con2fb.framebuffer]) {
return -EINVAL;
}
@@ -3144,10 +3148,10 @@ static ssize_t store_rotate(struct device *device,
console_lock();
idx = con2fb_map[fg_console];
- if (idx == -1 || registered_fb[idx] == NULL)
+ if (idx == -1 || fbcon_registered_fb[idx] == NULL)
goto err;
- info = registered_fb[idx];
+ info = fbcon_registered_fb[idx];
rotate = simple_strtoul(buf, last, 0);
fbcon_rotate(info, rotate);
err:
@@ -3166,10 +3170,10 @@ static ssize_t store_rotate_all(struct device *device,
console_lock();
idx = con2fb_map[fg_console];
- if (idx == -1 || registered_fb[idx] == NULL)
+ if (idx == -1 || fbcon_registered_fb[idx] == NULL)
goto err;
- info = registered_fb[idx];
+ info = fbcon_registered_fb[idx];
rotate = simple_strtoul(buf, last, 0);
fbcon_rotate_all(info, rotate);
err:
@@ -3186,10 +3190,10 @@ static ssize_t show_rotate(struct device *device,
console_lock();
idx = con2fb_map[fg_console];
- if (idx == -1 || registered_fb[idx] == NULL)
+ if (idx == -1 || fbcon_registered_fb[idx] == NULL)
goto err;
- info = registered_fb[idx];
+ info = fbcon_registered_fb[idx];
rotate = fbcon_get_rotate(info);
err:
console_unlock();
@@ -3206,10 +3210,10 @@ static ssize_t show_cursor_blink(struct device *device,
console_lock();
idx = con2fb_map[fg_console];
- if (idx == -1 || registered_fb[idx] == NULL)
+ if (idx == -1 || fbcon_registered_fb[idx] == NULL)
goto err;
- info = registered_fb[idx];
+ info = fbcon_registered_fb[idx];
ops = info->fbcon_par;
if (!ops)
@@ -3232,10 +3236,10 @@ static ssize_t store_cursor_blink(struct device *device,
console_lock();
idx = con2fb_map[fg_console];
- if (idx == -1 || registered_fb[idx] == NULL)
+ if (idx == -1 || fbcon_registered_fb[idx] == NULL)
goto err;
- info = registered_fb[idx];
+ info = fbcon_registered_fb[idx];
if (!info->fbcon_par)
goto err;
@@ -3295,8 +3299,8 @@ static void fbcon_register_existing_fbs(struct work_struct *work)
deferred_takeover = false;
logo_shown = FBCON_LOGO_DONTSHOW;
- for_each_registered_fb(i)
- fbcon_fb_registered(registered_fb[i]);
+ fbcon_for_each_registered_fb(i)
+ fbcon_fb_registered(fbcon_registered_fb[i]);
console_unlock();
}
--
2.33.0
^ permalink raw reply related [flat|nested] 241+ messages in thread
* [Intel-gfx] [PATCH 19/21] fbcon: Maintain a private array of fb_info
@ 2022-01-31 21:05 ` Daniel Vetter
0 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-01-31 21:05 UTC (permalink / raw)
To: DRI Development
Cc: linux-fbdev, Du Cheng, Tetsuo Handa, Daniel Vetter,
Intel Graphics Development, LKML, Greg Kroah-Hartman,
Daniel Vetter
Accessing the one in fbmem.c without taking the right locks is a bad
idea. Instead maintain our own private copy, which is fully protected
by console_lock() (like everything else in fbcon.c). That copy is
serialized through fbcon_fb_registered/unregistered() calls.
Also this means we do not need to hold a full fb_info reference, which
is nice because doing so would mean a refcount loop between the
console and the fb_info. But it's also not nice since it means
console_lock() must be held absolutely everywhere. Well strictly
speaking we could still try to do some refcounting games again by
calling get_fb_info before we drop the console_lock. But things will
get tricky.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Claudio Suarez <cssk@net-c.es>
Cc: Du Cheng <ducheng2@gmail.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/video/fbdev/core/fbcon.c | 82 +++++++++++++++++---------------
1 file changed, 43 insertions(+), 39 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 22581952b4fd..a0ca34b29615 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -86,10 +86,6 @@
* - fbcon state itself is protected by the console_lock, and the code does a
* pretty good job at making sure that lock is held everywhere it's needed.
*
- * - access to the registered_fb array is entirely unprotected. This should use
- * proper object lifetime handling, i.e. get/put_fb_info. This also means
- * switching from indices to proper pointers for fb_info everywhere.
- *
* - fbcon doesn't bother with fb_lock/unlock at all. This is buggy, since it
* means concurrent access to the same fbdev from both fbcon and userspace
* will blow up. To fix this all fbcon calls from fbmem.c need to be moved out
@@ -107,6 +103,13 @@ enum {
static struct fbcon_display fb_display[MAX_NR_CONSOLES];
+struct fb_info *fbcon_registered_fb[FB_MAX];
+int fbcon_num_registered_fb;
+
+#define fbcon_for_each_registered_fb(i) \
+ for (i = 0; WARN_CONSOLE_UNLOCKED(), i < FB_MAX; i++) \
+ if (!fbcon_registered_fb[i]) {} else
+
static signed char con2fb_map[MAX_NR_CONSOLES];
static signed char con2fb_map_boot[MAX_NR_CONSOLES];
@@ -114,12 +117,7 @@ static struct fb_info *fbcon_info_from_console(int console)
{
WARN_CONSOLE_UNLOCKED();
- /*
- * Note that only con2fb_map is protected by the console lock,
- * registered_fb is protected by a separate mutex. This lookup can
- * therefore race.
- */
- return registered_fb[con2fb_map[console]];
+ return fbcon_registered_fb[con2fb_map[console]];
}
static int logo_lines;
@@ -516,7 +514,7 @@ static int do_fbcon_takeover(int show_logo)
{
int err, i;
- if (!num_registered_fb)
+ if (!fbcon_num_registered_fb)
return -ENODEV;
if (!show_logo)
@@ -822,7 +820,7 @@ static int set_con2fb_map(int unit, int newidx, int user)
{
struct vc_data *vc = vc_cons[unit].d;
int oldidx = con2fb_map[unit];
- struct fb_info *info = registered_fb[newidx];
+ struct fb_info *info = fbcon_registered_fb[newidx];
struct fb_info *oldinfo = NULL;
int found, err = 0, show_logo;
@@ -840,7 +838,7 @@ static int set_con2fb_map(int unit, int newidx, int user)
}
if (oldidx != -1)
- oldinfo = registered_fb[oldidx];
+ oldinfo = fbcon_registered_fb[oldidx];
found = search_fb_in_map(newidx);
@@ -932,13 +930,13 @@ static const char *fbcon_startup(void)
* If num_registered_fb is zero, this is a call for the dummy part.
* The frame buffer devices weren't initialized yet.
*/
- if (!num_registered_fb || info_idx == -1)
+ if (!fbcon_num_registered_fb || info_idx == -1)
return display_desc;
/*
* Instead of blindly using registered_fb[0], we use info_idx, set by
* fbcon_fb_registered();
*/
- info = registered_fb[info_idx];
+ info = fbcon_registered_fb[info_idx];
if (!info)
return NULL;
@@ -1153,9 +1151,9 @@ static void fbcon_release_all(void)
struct fb_info *info;
int i, j, mapped;
- for_each_registered_fb(i) {
+ fbcon_for_each_registered_fb(i) {
mapped = 0;
- info = registered_fb[i];
+ info = fbcon_registered_fb[i];
for (j = first_fb_vc; j <= last_fb_vc; j++) {
if (con2fb_map[j] == i) {
@@ -1182,7 +1180,7 @@ static void fbcon_deinit(struct vc_data *vc)
if (idx == -1)
goto finished;
- info = registered_fb[idx];
+ info = fbcon_registered_fb[idx];
if (!info)
goto finished;
@@ -2118,9 +2116,9 @@ static int fbcon_switch(struct vc_data *vc)
*
* info->currcon = vc->vc_num;
*/
- for_each_registered_fb(i) {
- if (registered_fb[i]->fbcon_par) {
- struct fbcon_ops *o = registered_fb[i]->fbcon_par;
+ fbcon_for_each_registered_fb(i) {
+ if (fbcon_registered_fb[i]->fbcon_par) {
+ struct fbcon_ops *o = fbcon_registered_fb[i]->fbcon_par;
o->currcon = vc->vc_num;
}
@@ -2765,7 +2763,7 @@ int fbcon_mode_deleted(struct fb_info *info,
j = con2fb_map[i];
if (j == -1)
continue;
- fb_info = registered_fb[j];
+ fb_info = fbcon_registered_fb[j];
if (fb_info != info)
continue;
p = &fb_display[i];
@@ -2821,7 +2819,7 @@ void fbcon_fb_unbind(struct fb_info *info)
set_con2fb_map(i, new_idx, 0);
}
} else {
- struct fb_info *info = registered_fb[idx];
+ struct fb_info *info = fbcon_registered_fb[idx];
/* This is sort of like set_con2fb_map, except it maps
* the consoles to no device and then releases the
@@ -2851,6 +2849,9 @@ void fbcon_fb_unregistered(struct fb_info *info)
console_lock();
+ fbcon_registered_fb[info->node] = NULL;
+ fbcon_num_registered_fb--;
+
if (deferred_takeover) {
console_unlock();
return;
@@ -2865,7 +2866,7 @@ void fbcon_fb_unregistered(struct fb_info *info)
if (idx == info_idx) {
info_idx = -1;
- for_each_registered_fb(i) {
+ fbcon_for_each_registered_fb(i) {
info_idx = i;
break;
}
@@ -2881,7 +2882,7 @@ void fbcon_fb_unregistered(struct fb_info *info)
if (primary_device == idx)
primary_device = -1;
- if (!num_registered_fb)
+ if (!fbcon_num_registered_fb)
do_unregister_con_driver(&fb_con);
console_unlock();
}
@@ -2956,6 +2957,9 @@ int fbcon_fb_registered(struct fb_info *info)
else
atomic_inc(&ignore_console_lock_warning);
+ fbcon_registered_fb[info->node] = info;
+ fbcon_num_registered_fb++;
+
idx = info->node;
fbcon_select_primary(info);
@@ -3075,9 +3079,9 @@ int fbcon_set_con2fb_map_ioctl(void __user *argp)
return -EINVAL;
if (con2fb.framebuffer >= FB_MAX)
return -EINVAL;
- if (!registered_fb[con2fb.framebuffer])
+ if (!fbcon_registered_fb[con2fb.framebuffer])
request_module("fb%d", con2fb.framebuffer);
- if (!registered_fb[con2fb.framebuffer]) {
+ if (!fbcon_registered_fb[con2fb.framebuffer]) {
return -EINVAL;
}
@@ -3144,10 +3148,10 @@ static ssize_t store_rotate(struct device *device,
console_lock();
idx = con2fb_map[fg_console];
- if (idx == -1 || registered_fb[idx] == NULL)
+ if (idx == -1 || fbcon_registered_fb[idx] == NULL)
goto err;
- info = registered_fb[idx];
+ info = fbcon_registered_fb[idx];
rotate = simple_strtoul(buf, last, 0);
fbcon_rotate(info, rotate);
err:
@@ -3166,10 +3170,10 @@ static ssize_t store_rotate_all(struct device *device,
console_lock();
idx = con2fb_map[fg_console];
- if (idx == -1 || registered_fb[idx] == NULL)
+ if (idx == -1 || fbcon_registered_fb[idx] == NULL)
goto err;
- info = registered_fb[idx];
+ info = fbcon_registered_fb[idx];
rotate = simple_strtoul(buf, last, 0);
fbcon_rotate_all(info, rotate);
err:
@@ -3186,10 +3190,10 @@ static ssize_t show_rotate(struct device *device,
console_lock();
idx = con2fb_map[fg_console];
- if (idx == -1 || registered_fb[idx] == NULL)
+ if (idx == -1 || fbcon_registered_fb[idx] == NULL)
goto err;
- info = registered_fb[idx];
+ info = fbcon_registered_fb[idx];
rotate = fbcon_get_rotate(info);
err:
console_unlock();
@@ -3206,10 +3210,10 @@ static ssize_t show_cursor_blink(struct device *device,
console_lock();
idx = con2fb_map[fg_console];
- if (idx == -1 || registered_fb[idx] == NULL)
+ if (idx == -1 || fbcon_registered_fb[idx] == NULL)
goto err;
- info = registered_fb[idx];
+ info = fbcon_registered_fb[idx];
ops = info->fbcon_par;
if (!ops)
@@ -3232,10 +3236,10 @@ static ssize_t store_cursor_blink(struct device *device,
console_lock();
idx = con2fb_map[fg_console];
- if (idx == -1 || registered_fb[idx] == NULL)
+ if (idx == -1 || fbcon_registered_fb[idx] == NULL)
goto err;
- info = registered_fb[idx];
+ info = fbcon_registered_fb[idx];
if (!info->fbcon_par)
goto err;
@@ -3295,8 +3299,8 @@ static void fbcon_register_existing_fbs(struct work_struct *work)
deferred_takeover = false;
logo_shown = FBCON_LOGO_DONTSHOW;
- for_each_registered_fb(i)
- fbcon_fb_registered(registered_fb[i]);
+ fbcon_for_each_registered_fb(i)
+ fbcon_fb_registered(fbcon_registered_fb[i]);
console_unlock();
}
--
2.33.0
^ permalink raw reply related [flat|nested] 241+ messages in thread
* [PATCH 19/21] fbcon: Maintain a private array of fb_info
@ 2022-01-31 21:05 ` Daniel Vetter
0 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-01-31 21:05 UTC (permalink / raw)
To: DRI Development
Cc: Intel Graphics Development, linux-fbdev, LKML, Daniel Vetter,
Daniel Vetter, Daniel Vetter, Tetsuo Handa, Claudio Suarez,
Du Cheng, Greg Kroah-Hartman
Accessing the one in fbmem.c without taking the right locks is a bad
idea. Instead maintain our own private copy, which is fully protected
by console_lock() (like everything else in fbcon.c). That copy is
serialized through fbcon_fb_registered/unregistered() calls.
Also this means we do not need to hold a full fb_info reference, which
is nice because doing so would mean a refcount loop between the
console and the fb_info. But it's also not nice since it means
console_lock() must be held absolutely everywhere. Well strictly
speaking we could still try to do some refcounting games again by
calling get_fb_info before we drop the console_lock. But things will
get tricky.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Claudio Suarez <cssk@net-c.es>
Cc: Du Cheng <ducheng2@gmail.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/video/fbdev/core/fbcon.c | 82 +++++++++++++++++---------------
1 file changed, 43 insertions(+), 39 deletions(-)
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 22581952b4fd..a0ca34b29615 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -86,10 +86,6 @@
* - fbcon state itself is protected by the console_lock, and the code does a
* pretty good job at making sure that lock is held everywhere it's needed.
*
- * - access to the registered_fb array is entirely unprotected. This should use
- * proper object lifetime handling, i.e. get/put_fb_info. This also means
- * switching from indices to proper pointers for fb_info everywhere.
- *
* - fbcon doesn't bother with fb_lock/unlock at all. This is buggy, since it
* means concurrent access to the same fbdev from both fbcon and userspace
* will blow up. To fix this all fbcon calls from fbmem.c need to be moved out
@@ -107,6 +103,13 @@ enum {
static struct fbcon_display fb_display[MAX_NR_CONSOLES];
+struct fb_info *fbcon_registered_fb[FB_MAX];
+int fbcon_num_registered_fb;
+
+#define fbcon_for_each_registered_fb(i) \
+ for (i = 0; WARN_CONSOLE_UNLOCKED(), i < FB_MAX; i++) \
+ if (!fbcon_registered_fb[i]) {} else
+
static signed char con2fb_map[MAX_NR_CONSOLES];
static signed char con2fb_map_boot[MAX_NR_CONSOLES];
@@ -114,12 +117,7 @@ static struct fb_info *fbcon_info_from_console(int console)
{
WARN_CONSOLE_UNLOCKED();
- /*
- * Note that only con2fb_map is protected by the console lock,
- * registered_fb is protected by a separate mutex. This lookup can
- * therefore race.
- */
- return registered_fb[con2fb_map[console]];
+ return fbcon_registered_fb[con2fb_map[console]];
}
static int logo_lines;
@@ -516,7 +514,7 @@ static int do_fbcon_takeover(int show_logo)
{
int err, i;
- if (!num_registered_fb)
+ if (!fbcon_num_registered_fb)
return -ENODEV;
if (!show_logo)
@@ -822,7 +820,7 @@ static int set_con2fb_map(int unit, int newidx, int user)
{
struct vc_data *vc = vc_cons[unit].d;
int oldidx = con2fb_map[unit];
- struct fb_info *info = registered_fb[newidx];
+ struct fb_info *info = fbcon_registered_fb[newidx];
struct fb_info *oldinfo = NULL;
int found, err = 0, show_logo;
@@ -840,7 +838,7 @@ static int set_con2fb_map(int unit, int newidx, int user)
}
if (oldidx != -1)
- oldinfo = registered_fb[oldidx];
+ oldinfo = fbcon_registered_fb[oldidx];
found = search_fb_in_map(newidx);
@@ -932,13 +930,13 @@ static const char *fbcon_startup(void)
* If num_registered_fb is zero, this is a call for the dummy part.
* The frame buffer devices weren't initialized yet.
*/
- if (!num_registered_fb || info_idx == -1)
+ if (!fbcon_num_registered_fb || info_idx == -1)
return display_desc;
/*
* Instead of blindly using registered_fb[0], we use info_idx, set by
* fbcon_fb_registered();
*/
- info = registered_fb[info_idx];
+ info = fbcon_registered_fb[info_idx];
if (!info)
return NULL;
@@ -1153,9 +1151,9 @@ static void fbcon_release_all(void)
struct fb_info *info;
int i, j, mapped;
- for_each_registered_fb(i) {
+ fbcon_for_each_registered_fb(i) {
mapped = 0;
- info = registered_fb[i];
+ info = fbcon_registered_fb[i];
for (j = first_fb_vc; j <= last_fb_vc; j++) {
if (con2fb_map[j] == i) {
@@ -1182,7 +1180,7 @@ static void fbcon_deinit(struct vc_data *vc)
if (idx == -1)
goto finished;
- info = registered_fb[idx];
+ info = fbcon_registered_fb[idx];
if (!info)
goto finished;
@@ -2118,9 +2116,9 @@ static int fbcon_switch(struct vc_data *vc)
*
* info->currcon = vc->vc_num;
*/
- for_each_registered_fb(i) {
- if (registered_fb[i]->fbcon_par) {
- struct fbcon_ops *o = registered_fb[i]->fbcon_par;
+ fbcon_for_each_registered_fb(i) {
+ if (fbcon_registered_fb[i]->fbcon_par) {
+ struct fbcon_ops *o = fbcon_registered_fb[i]->fbcon_par;
o->currcon = vc->vc_num;
}
@@ -2765,7 +2763,7 @@ int fbcon_mode_deleted(struct fb_info *info,
j = con2fb_map[i];
if (j == -1)
continue;
- fb_info = registered_fb[j];
+ fb_info = fbcon_registered_fb[j];
if (fb_info != info)
continue;
p = &fb_display[i];
@@ -2821,7 +2819,7 @@ void fbcon_fb_unbind(struct fb_info *info)
set_con2fb_map(i, new_idx, 0);
}
} else {
- struct fb_info *info = registered_fb[idx];
+ struct fb_info *info = fbcon_registered_fb[idx];
/* This is sort of like set_con2fb_map, except it maps
* the consoles to no device and then releases the
@@ -2851,6 +2849,9 @@ void fbcon_fb_unregistered(struct fb_info *info)
console_lock();
+ fbcon_registered_fb[info->node] = NULL;
+ fbcon_num_registered_fb--;
+
if (deferred_takeover) {
console_unlock();
return;
@@ -2865,7 +2866,7 @@ void fbcon_fb_unregistered(struct fb_info *info)
if (idx == info_idx) {
info_idx = -1;
- for_each_registered_fb(i) {
+ fbcon_for_each_registered_fb(i) {
info_idx = i;
break;
}
@@ -2881,7 +2882,7 @@ void fbcon_fb_unregistered(struct fb_info *info)
if (primary_device == idx)
primary_device = -1;
- if (!num_registered_fb)
+ if (!fbcon_num_registered_fb)
do_unregister_con_driver(&fb_con);
console_unlock();
}
@@ -2956,6 +2957,9 @@ int fbcon_fb_registered(struct fb_info *info)
else
atomic_inc(&ignore_console_lock_warning);
+ fbcon_registered_fb[info->node] = info;
+ fbcon_num_registered_fb++;
+
idx = info->node;
fbcon_select_primary(info);
@@ -3075,9 +3079,9 @@ int fbcon_set_con2fb_map_ioctl(void __user *argp)
return -EINVAL;
if (con2fb.framebuffer >= FB_MAX)
return -EINVAL;
- if (!registered_fb[con2fb.framebuffer])
+ if (!fbcon_registered_fb[con2fb.framebuffer])
request_module("fb%d", con2fb.framebuffer);
- if (!registered_fb[con2fb.framebuffer]) {
+ if (!fbcon_registered_fb[con2fb.framebuffer]) {
return -EINVAL;
}
@@ -3144,10 +3148,10 @@ static ssize_t store_rotate(struct device *device,
console_lock();
idx = con2fb_map[fg_console];
- if (idx == -1 || registered_fb[idx] == NULL)
+ if (idx == -1 || fbcon_registered_fb[idx] == NULL)
goto err;
- info = registered_fb[idx];
+ info = fbcon_registered_fb[idx];
rotate = simple_strtoul(buf, last, 0);
fbcon_rotate(info, rotate);
err:
@@ -3166,10 +3170,10 @@ static ssize_t store_rotate_all(struct device *device,
console_lock();
idx = con2fb_map[fg_console];
- if (idx == -1 || registered_fb[idx] == NULL)
+ if (idx == -1 || fbcon_registered_fb[idx] == NULL)
goto err;
- info = registered_fb[idx];
+ info = fbcon_registered_fb[idx];
rotate = simple_strtoul(buf, last, 0);
fbcon_rotate_all(info, rotate);
err:
@@ -3186,10 +3190,10 @@ static ssize_t show_rotate(struct device *device,
console_lock();
idx = con2fb_map[fg_console];
- if (idx == -1 || registered_fb[idx] == NULL)
+ if (idx == -1 || fbcon_registered_fb[idx] == NULL)
goto err;
- info = registered_fb[idx];
+ info = fbcon_registered_fb[idx];
rotate = fbcon_get_rotate(info);
err:
console_unlock();
@@ -3206,10 +3210,10 @@ static ssize_t show_cursor_blink(struct device *device,
console_lock();
idx = con2fb_map[fg_console];
- if (idx == -1 || registered_fb[idx] == NULL)
+ if (idx == -1 || fbcon_registered_fb[idx] == NULL)
goto err;
- info = registered_fb[idx];
+ info = fbcon_registered_fb[idx];
ops = info->fbcon_par;
if (!ops)
@@ -3232,10 +3236,10 @@ static ssize_t store_cursor_blink(struct device *device,
console_lock();
idx = con2fb_map[fg_console];
- if (idx == -1 || registered_fb[idx] == NULL)
+ if (idx == -1 || fbcon_registered_fb[idx] == NULL)
goto err;
- info = registered_fb[idx];
+ info = fbcon_registered_fb[idx];
if (!info->fbcon_par)
goto err;
@@ -3295,8 +3299,8 @@ static void fbcon_register_existing_fbs(struct work_struct *work)
deferred_takeover = false;
logo_shown = FBCON_LOGO_DONTSHOW;
- for_each_registered_fb(i)
- fbcon_fb_registered(registered_fb[i]);
+ fbcon_for_each_registered_fb(i)
+ fbcon_fb_registered(fbcon_registered_fb[i]);
console_unlock();
}
--
2.33.0
^ permalink raw reply related [flat|nested] 241+ messages in thread
* [PATCH 20/21] Revert "fbdev: Prevent probing generic drivers if a FB is already registered"
2022-01-31 21:05 ` Daniel Vetter
(?)
@ 2022-01-31 21:05 ` Daniel Vetter
-1 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-01-31 21:05 UTC (permalink / raw)
To: DRI Development
Cc: linux-fbdev, Daniel Vetter, Intel Graphics Development, LKML,
Javier Martinez Canillas, Hans de Goede, Peter Jones,
Thomas Zimmermann, Ilya Trukhanov, Daniel Vetter
This reverts commit fb561bf9abde49f7e00fdbf9ed2ccf2d86cac8ee.
With
commit 27599aacbaefcbf2af7b06b0029459bbf682000d
Author: Thomas Zimmermann <tzimmermann@suse.de>
Date: Tue Jan 25 10:12:18 2022 +0100
fbdev: Hot-unplug firmware fb devices on forced removal
this should be fixed properly and we can remove this somewhat hackish
check here (e.g. this won't catch drm drivers if fbdev emulation isn't
enabled).
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Zack Rusin <zackr@vmware.com>
Cc: Javier Martinez Canillas <javierm@redhat.com>
Cc: Zack Rusin <zackr@vmware.com>
Cc: Hans de Goede <hdegoede@redhat.com>
Cc: Ilya Trukhanov <lahvuun@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Peter Jones <pjones@redhat.com>
Cc: linux-fbdev@vger.kernel.org
---
drivers/video/fbdev/efifb.c | 11 -----------
drivers/video/fbdev/simplefb.c | 11 -----------
2 files changed, 22 deletions(-)
diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
index ea42ba6445b2..edca3703b964 100644
--- a/drivers/video/fbdev/efifb.c
+++ b/drivers/video/fbdev/efifb.c
@@ -351,17 +351,6 @@ static int efifb_probe(struct platform_device *dev)
char *option = NULL;
efi_memory_desc_t md;
- /*
- * Generic drivers must not be registered if a framebuffer exists.
- * If a native driver was probed, the display hardware was already
- * taken and attempting to use the system framebuffer is dangerous.
- */
- if (num_registered_fb > 0) {
- dev_err(&dev->dev,
- "efifb: a framebuffer is already registered\n");
- return -EINVAL;
- }
-
if (screen_info.orig_video_isVGA != VIDEO_TYPE_EFI || pci_dev_disabled)
return -ENODEV;
diff --git a/drivers/video/fbdev/simplefb.c b/drivers/video/fbdev/simplefb.c
index 57541887188b..ee8b4412f7e4 100644
--- a/drivers/video/fbdev/simplefb.c
+++ b/drivers/video/fbdev/simplefb.c
@@ -407,17 +407,6 @@ static int simplefb_probe(struct platform_device *pdev)
struct simplefb_par *par;
struct resource *mem;
- /*
- * Generic drivers must not be registered if a framebuffer exists.
- * If a native driver was probed, the display hardware was already
- * taken and attempting to use the system framebuffer is dangerous.
- */
- if (num_registered_fb > 0) {
- dev_err(&pdev->dev,
- "simplefb: a framebuffer is already registered\n");
- return -EINVAL;
- }
-
if (fb_get_options("simplefb", NULL))
return -ENODEV;
--
2.33.0
^ permalink raw reply related [flat|nested] 241+ messages in thread
* [Intel-gfx] [PATCH 20/21] Revert "fbdev: Prevent probing generic drivers if a FB is already registered"
@ 2022-01-31 21:05 ` Daniel Vetter
0 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-01-31 21:05 UTC (permalink / raw)
To: DRI Development
Cc: linux-fbdev, Daniel Vetter, Intel Graphics Development, LKML,
Javier Martinez Canillas, Peter Jones, Thomas Zimmermann,
Ilya Trukhanov, Daniel Vetter, Zack Rusin
This reverts commit fb561bf9abde49f7e00fdbf9ed2ccf2d86cac8ee.
With
commit 27599aacbaefcbf2af7b06b0029459bbf682000d
Author: Thomas Zimmermann <tzimmermann@suse.de>
Date: Tue Jan 25 10:12:18 2022 +0100
fbdev: Hot-unplug firmware fb devices on forced removal
this should be fixed properly and we can remove this somewhat hackish
check here (e.g. this won't catch drm drivers if fbdev emulation isn't
enabled).
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Zack Rusin <zackr@vmware.com>
Cc: Javier Martinez Canillas <javierm@redhat.com>
Cc: Zack Rusin <zackr@vmware.com>
Cc: Hans de Goede <hdegoede@redhat.com>
Cc: Ilya Trukhanov <lahvuun@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Peter Jones <pjones@redhat.com>
Cc: linux-fbdev@vger.kernel.org
---
drivers/video/fbdev/efifb.c | 11 -----------
drivers/video/fbdev/simplefb.c | 11 -----------
2 files changed, 22 deletions(-)
diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
index ea42ba6445b2..edca3703b964 100644
--- a/drivers/video/fbdev/efifb.c
+++ b/drivers/video/fbdev/efifb.c
@@ -351,17 +351,6 @@ static int efifb_probe(struct platform_device *dev)
char *option = NULL;
efi_memory_desc_t md;
- /*
- * Generic drivers must not be registered if a framebuffer exists.
- * If a native driver was probed, the display hardware was already
- * taken and attempting to use the system framebuffer is dangerous.
- */
- if (num_registered_fb > 0) {
- dev_err(&dev->dev,
- "efifb: a framebuffer is already registered\n");
- return -EINVAL;
- }
-
if (screen_info.orig_video_isVGA != VIDEO_TYPE_EFI || pci_dev_disabled)
return -ENODEV;
diff --git a/drivers/video/fbdev/simplefb.c b/drivers/video/fbdev/simplefb.c
index 57541887188b..ee8b4412f7e4 100644
--- a/drivers/video/fbdev/simplefb.c
+++ b/drivers/video/fbdev/simplefb.c
@@ -407,17 +407,6 @@ static int simplefb_probe(struct platform_device *pdev)
struct simplefb_par *par;
struct resource *mem;
- /*
- * Generic drivers must not be registered if a framebuffer exists.
- * If a native driver was probed, the display hardware was already
- * taken and attempting to use the system framebuffer is dangerous.
- */
- if (num_registered_fb > 0) {
- dev_err(&pdev->dev,
- "simplefb: a framebuffer is already registered\n");
- return -EINVAL;
- }
-
if (fb_get_options("simplefb", NULL))
return -ENODEV;
--
2.33.0
^ permalink raw reply related [flat|nested] 241+ messages in thread
* [PATCH 20/21] Revert "fbdev: Prevent probing generic drivers if a FB is already registered"
@ 2022-01-31 21:05 ` Daniel Vetter
0 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-01-31 21:05 UTC (permalink / raw)
To: DRI Development
Cc: Intel Graphics Development, linux-fbdev, LKML, Daniel Vetter,
Thomas Zimmermann, Zack Rusin, Javier Martinez Canillas,
Hans de Goede, Ilya Trukhanov, Daniel Vetter, Peter Jones
This reverts commit fb561bf9abde49f7e00fdbf9ed2ccf2d86cac8ee.
With
commit 27599aacbaefcbf2af7b06b0029459bbf682000d
Author: Thomas Zimmermann <tzimmermann@suse.de>
Date: Tue Jan 25 10:12:18 2022 +0100
fbdev: Hot-unplug firmware fb devices on forced removal
this should be fixed properly and we can remove this somewhat hackish
check here (e.g. this won't catch drm drivers if fbdev emulation isn't
enabled).
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Zack Rusin <zackr@vmware.com>
Cc: Javier Martinez Canillas <javierm@redhat.com>
Cc: Zack Rusin <zackr@vmware.com>
Cc: Hans de Goede <hdegoede@redhat.com>
Cc: Ilya Trukhanov <lahvuun@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Peter Jones <pjones@redhat.com>
Cc: linux-fbdev@vger.kernel.org
---
drivers/video/fbdev/efifb.c | 11 -----------
drivers/video/fbdev/simplefb.c | 11 -----------
2 files changed, 22 deletions(-)
diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
index ea42ba6445b2..edca3703b964 100644
--- a/drivers/video/fbdev/efifb.c
+++ b/drivers/video/fbdev/efifb.c
@@ -351,17 +351,6 @@ static int efifb_probe(struct platform_device *dev)
char *option = NULL;
efi_memory_desc_t md;
- /*
- * Generic drivers must not be registered if a framebuffer exists.
- * If a native driver was probed, the display hardware was already
- * taken and attempting to use the system framebuffer is dangerous.
- */
- if (num_registered_fb > 0) {
- dev_err(&dev->dev,
- "efifb: a framebuffer is already registered\n");
- return -EINVAL;
- }
-
if (screen_info.orig_video_isVGA != VIDEO_TYPE_EFI || pci_dev_disabled)
return -ENODEV;
diff --git a/drivers/video/fbdev/simplefb.c b/drivers/video/fbdev/simplefb.c
index 57541887188b..ee8b4412f7e4 100644
--- a/drivers/video/fbdev/simplefb.c
+++ b/drivers/video/fbdev/simplefb.c
@@ -407,17 +407,6 @@ static int simplefb_probe(struct platform_device *pdev)
struct simplefb_par *par;
struct resource *mem;
- /*
- * Generic drivers must not be registered if a framebuffer exists.
- * If a native driver was probed, the display hardware was already
- * taken and attempting to use the system framebuffer is dangerous.
- */
- if (num_registered_fb > 0) {
- dev_err(&pdev->dev,
- "simplefb: a framebuffer is already registered\n");
- return -EINVAL;
- }
-
if (fb_get_options("simplefb", NULL))
return -ENODEV;
--
2.33.0
^ permalink raw reply related [flat|nested] 241+ messages in thread
* [PATCH 21/21] fbdev: Make registered_fb[] private to fbmem.c
2022-01-31 21:05 ` Daniel Vetter
(?)
@ 2022-01-31 21:05 ` Daniel Vetter
-1 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-01-31 21:05 UTC (permalink / raw)
To: DRI Development
Cc: Intel Graphics Development, linux-fbdev, LKML, Daniel Vetter,
Jens Frederich, Jon Nettleton, Greg Kroah-Hartman, linux-staging,
Daniel Vetter, Daniel Vetter, Helge Deller, Matthew Wilcox,
Sam Ravnborg, Tetsuo Handa, Zhen Lei, Alex Deucher, Xiyu Yang,
Zheyu Ma, Guenter Roeck
Well except when the olpc dcon fbdev driver is enabled, that thing
digs around in there in rather unfixable ways.
Cc oldc_dcon maintainers as fyi.
Cc: Jens Frederich <jfrederich@gmail.com>
Cc: Jon Nettleton <jon.nettleton@gmail.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-staging@lists.linux.dev
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Helge Deller <deller@gmx.de>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Cc: Zhen Lei <thunder.leizhen@huawei.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Xiyu Yang <xiyuyang19@fudan.edu.cn>
Cc: linux-fbdev@vger.kernel.org
Cc: Zheyu Ma <zheyuma97@gmail.com>
Cc: Guenter Roeck <linux@roeck-us.net>
---
drivers/video/fbdev/core/fbmem.c | 8 ++++++--
include/linux/fb.h | 7 +++----
2 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 904ef1250677..dad6572942fa 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -48,10 +48,14 @@
static DEFINE_MUTEX(registration_lock);
struct fb_info *registered_fb[FB_MAX] __read_mostly;
-EXPORT_SYMBOL(registered_fb);
-
int num_registered_fb __read_mostly;
+#if IS_ENABLED(CONFIG_OLPC_DCON)
+EXPORT_SYMBOL(registered_fb);
EXPORT_SYMBOL(num_registered_fb);
+#endif
+#define for_each_registered_fb(i) \
+ for (i = 0; i < FB_MAX; i++) \
+ if (!registered_fb[i]) {} else
bool fb_center_logo __read_mostly;
diff --git a/include/linux/fb.h b/include/linux/fb.h
index a8a00d2ba1f3..e236817502c2 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -622,16 +622,15 @@ extern int fb_get_color_depth(struct fb_var_screeninfo *var,
extern int fb_get_options(const char *name, char **option);
extern int fb_new_modelist(struct fb_info *info);
+#if IS_ENABLED(CONFIG_OLPC_DCON)
extern struct fb_info *registered_fb[FB_MAX];
+
extern int num_registered_fb;
+#endif
extern bool fb_center_logo;
extern int fb_logo_count;
extern struct class *fb_class;
-#define for_each_registered_fb(i) \
- for (i = 0; i < FB_MAX; i++) \
- if (!registered_fb[i]) {} else
-
static inline void lock_fb_info(struct fb_info *info)
{
mutex_lock(&info->lock);
--
2.33.0
^ permalink raw reply related [flat|nested] 241+ messages in thread
* [PATCH 21/21] fbdev: Make registered_fb[] private to fbmem.c
@ 2022-01-31 21:05 ` Daniel Vetter
0 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-01-31 21:05 UTC (permalink / raw)
To: DRI Development
Cc: linux-fbdev, Zheyu Ma, Xiyu Yang, Jens Frederich, Tetsuo Handa,
Daniel Vetter, Intel Graphics Development, linux-staging, LKML,
Matthew Wilcox, Zhen Lei, Guenter Roeck, Greg Kroah-Hartman,
Alex Deucher, Daniel Vetter, Sam Ravnborg, Jon Nettleton,
Helge Deller
Well except when the olpc dcon fbdev driver is enabled, that thing
digs around in there in rather unfixable ways.
Cc oldc_dcon maintainers as fyi.
Cc: Jens Frederich <jfrederich@gmail.com>
Cc: Jon Nettleton <jon.nettleton@gmail.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-staging@lists.linux.dev
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Helge Deller <deller@gmx.de>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Cc: Zhen Lei <thunder.leizhen@huawei.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Xiyu Yang <xiyuyang19@fudan.edu.cn>
Cc: linux-fbdev@vger.kernel.org
Cc: Zheyu Ma <zheyuma97@gmail.com>
Cc: Guenter Roeck <linux@roeck-us.net>
---
drivers/video/fbdev/core/fbmem.c | 8 ++++++--
include/linux/fb.h | 7 +++----
2 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 904ef1250677..dad6572942fa 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -48,10 +48,14 @@
static DEFINE_MUTEX(registration_lock);
struct fb_info *registered_fb[FB_MAX] __read_mostly;
-EXPORT_SYMBOL(registered_fb);
-
int num_registered_fb __read_mostly;
+#if IS_ENABLED(CONFIG_OLPC_DCON)
+EXPORT_SYMBOL(registered_fb);
EXPORT_SYMBOL(num_registered_fb);
+#endif
+#define for_each_registered_fb(i) \
+ for (i = 0; i < FB_MAX; i++) \
+ if (!registered_fb[i]) {} else
bool fb_center_logo __read_mostly;
diff --git a/include/linux/fb.h b/include/linux/fb.h
index a8a00d2ba1f3..e236817502c2 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -622,16 +622,15 @@ extern int fb_get_color_depth(struct fb_var_screeninfo *var,
extern int fb_get_options(const char *name, char **option);
extern int fb_new_modelist(struct fb_info *info);
+#if IS_ENABLED(CONFIG_OLPC_DCON)
extern struct fb_info *registered_fb[FB_MAX];
+
extern int num_registered_fb;
+#endif
extern bool fb_center_logo;
extern int fb_logo_count;
extern struct class *fb_class;
-#define for_each_registered_fb(i) \
- for (i = 0; i < FB_MAX; i++) \
- if (!registered_fb[i]) {} else
-
static inline void lock_fb_info(struct fb_info *info)
{
mutex_lock(&info->lock);
--
2.33.0
^ permalink raw reply related [flat|nested] 241+ messages in thread
* [Intel-gfx] [PATCH 21/21] fbdev: Make registered_fb[] private to fbmem.c
@ 2022-01-31 21:05 ` Daniel Vetter
0 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-01-31 21:05 UTC (permalink / raw)
To: DRI Development
Cc: linux-fbdev, Zheyu Ma, Xiyu Yang, Jens Frederich, Tetsuo Handa,
Daniel Vetter, Intel Graphics Development, linux-staging, LKML,
Matthew Wilcox, Zhen Lei, Guenter Roeck, Greg Kroah-Hartman,
Alex Deucher, Daniel Vetter, Sam Ravnborg, Jon Nettleton,
Helge Deller
Well except when the olpc dcon fbdev driver is enabled, that thing
digs around in there in rather unfixable ways.
Cc oldc_dcon maintainers as fyi.
Cc: Jens Frederich <jfrederich@gmail.com>
Cc: Jon Nettleton <jon.nettleton@gmail.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-staging@lists.linux.dev
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Helge Deller <deller@gmx.de>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Cc: Zhen Lei <thunder.leizhen@huawei.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Xiyu Yang <xiyuyang19@fudan.edu.cn>
Cc: linux-fbdev@vger.kernel.org
Cc: Zheyu Ma <zheyuma97@gmail.com>
Cc: Guenter Roeck <linux@roeck-us.net>
---
drivers/video/fbdev/core/fbmem.c | 8 ++++++--
include/linux/fb.h | 7 +++----
2 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 904ef1250677..dad6572942fa 100644
--- a/drivers/video/fbdev/core/fbmem.c
+++ b/drivers/video/fbdev/core/fbmem.c
@@ -48,10 +48,14 @@
static DEFINE_MUTEX(registration_lock);
struct fb_info *registered_fb[FB_MAX] __read_mostly;
-EXPORT_SYMBOL(registered_fb);
-
int num_registered_fb __read_mostly;
+#if IS_ENABLED(CONFIG_OLPC_DCON)
+EXPORT_SYMBOL(registered_fb);
EXPORT_SYMBOL(num_registered_fb);
+#endif
+#define for_each_registered_fb(i) \
+ for (i = 0; i < FB_MAX; i++) \
+ if (!registered_fb[i]) {} else
bool fb_center_logo __read_mostly;
diff --git a/include/linux/fb.h b/include/linux/fb.h
index a8a00d2ba1f3..e236817502c2 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -622,16 +622,15 @@ extern int fb_get_color_depth(struct fb_var_screeninfo *var,
extern int fb_get_options(const char *name, char **option);
extern int fb_new_modelist(struct fb_info *info);
+#if IS_ENABLED(CONFIG_OLPC_DCON)
extern struct fb_info *registered_fb[FB_MAX];
+
extern int num_registered_fb;
+#endif
extern bool fb_center_logo;
extern int fb_logo_count;
extern struct class *fb_class;
-#define for_each_registered_fb(i) \
- for (i = 0; i < FB_MAX; i++) \
- if (!registered_fb[i]) {} else
-
static inline void lock_fb_info(struct fb_info *info)
{
mutex_lock(&info->lock);
--
2.33.0
^ permalink raw reply related [flat|nested] 241+ messages in thread
* [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for some fbcon patches, mostly locking
2022-01-31 21:05 ` Daniel Vetter
` (22 preceding siblings ...)
(?)
@ 2022-01-31 21:16 ` Patchwork
-1 siblings, 0 replies; 241+ messages in thread
From: Patchwork @ 2022-01-31 21:16 UTC (permalink / raw)
To: Daniel Vetter; +Cc: intel-gfx
== Series Details ==
Series: some fbcon patches, mostly locking
URL : https://patchwork.freedesktop.org/series/99549/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
8895b11855ce MAINTAINERS: Add entry for fbdev core
-:64: WARNING:MAINTAINERS_STYLE: Misordered MAINTAINERS entry - list 'S:' before 'F:'
#64: FILE: MAINTAINERS:7582:
+F: drivers/video/fbdev/core/
+S: Odd Fixes
-:69: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address mismatch: 'From: Daniel Vetter <daniel.vetter@ffwll.ch>' != 'Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>'
total: 0 errors, 2 warnings, 0 checks, 12 lines checked
9029711bda24 fbcon: Resurrect fbcon accelerated scrolling code
-:24: WARNING:REPEATED_WORD: Possible repeated word: 'warnings'
#24:
And finally to shut up unused parameter warnings warnings the macros
-:27: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line)
#27:
References: https://lore.kernel.org/dri-devel/feea8303-2b83-fc36-972c-4fc8ad723bde@gmx.de/
-:41: WARNING:BAD_SIGN_OFF: Duplicate signature
#41:
Cc: Claudio Suarez <cssk@net-c.es>
-:209: WARNING:INLINE: plain inline is preferred over __inline__
#209: FILE: drivers/video/fbdev/core/fbcon.c:1437:
+static __inline__ void ywrap_up(struct vc_data *vc, int count)
-:228: WARNING:INLINE: plain inline is preferred over __inline__
#228: FILE: drivers/video/fbdev/core/fbcon.c:1456:
+static __inline__ void ywrap_down(struct vc_data *vc, int count)
-:247: WARNING:INLINE: plain inline is preferred over __inline__
#247: FILE: drivers/video/fbdev/core/fbcon.c:1475:
+static __inline__ void ypan_up(struct vc_data *vc, int count)
-:271: WARNING:INLINE: plain inline is preferred over __inline__
#271: FILE: drivers/video/fbdev/core/fbcon.c:1499:
+static __inline__ void ypan_up_redraw(struct vc_data *vc, int t, int count)
-:295: WARNING:INLINE: plain inline is preferred over __inline__
#295: FILE: drivers/video/fbdev/core/fbcon.c:1523:
+static __inline__ void ypan_down(struct vc_data *vc, int count)
-:319: WARNING:INLINE: plain inline is preferred over __inline__
#319: FILE: drivers/video/fbdev/core/fbcon.c:1547:
+static __inline__ void ypan_down_redraw(struct vc_data *vc, int t, int count)
-:409: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#409: FILE: drivers/video/fbdev/core/fbcon.c:1637:
+static void fbcon_redraw_blit(struct vc_data *vc, struct fb_info *info,
+ struct fbcon_display *p, int line, int count, int ycount)
-:429: CHECK:SPACING: spaces preferred around that '-' (ctx:VxV)
#429: FILE: drivers/video/fbdev/core/fbcon.c:1657:
+ line, x, 1, s-start);
^
-:445: CHECK:SPACING: spaces preferred around that '-' (ctx:VxV)
#445: FILE: drivers/video/fbdev/core/fbcon.c:1673:
+ s-start);
^
-:449: CHECK:BRACES: Unbalanced braces around else statement
#449: FILE: drivers/video/fbdev/core/fbcon.c:1677:
+ else {
-:490: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#490: FILE: drivers/video/fbdev/core/fbcon.c:1782:
+ fbcon_redraw_blit(vc, info, p, t, b - t - count,
+ count);
-:492: CHECK:SPACING: No space is necessary after a cast
#492: FILE: drivers/video/fbdev/core/fbcon.c:1784:
+ scr_memsetw((unsigned short *) (vc->vc_origin +
-:500: CHECK:BRACES: braces {} should be used on all arms of this statement
#500: FILE: drivers/video/fbdev/core/fbcon.c:1792:
+ if (b - t - count > 3 * vc->vc_rows >> 2) {
[...]
+ } else if (info->flags & FBINFO_READS_FAST)
[...]
+ else
[...]
-:518: CHECK:BRACES: braces {} should be used on all arms of this statement
#518: FILE: drivers/video/fbdev/core/fbcon.c:1810:
+ if ((p->yscroll + count <=
[...]
+ } else
[...]
-:520: CHECK:LOGICAL_CONTINUATIONS: Logical continuations should be on the previous line
#520: FILE: drivers/video/fbdev/core/fbcon.c:1812:
+ 2 * (p->vrows - vc->vc_rows))
+ && ((!scroll_partial && (b - t == vc->vc_rows))
-:521: CHECK:LOGICAL_CONTINUATIONS: Logical continuations should be on the previous line
#521: FILE: drivers/video/fbdev/core/fbcon.c:1813:
+ && ((!scroll_partial && (b - t == vc->vc_rows))
+ || (scroll_partial
-:522: CHECK:LOGICAL_CONTINUATIONS: Logical continuations should be on the previous line
#522: FILE: drivers/video/fbdev/core/fbcon.c:1814:
+ || (scroll_partial
+ && (b - t - count >
-:530: CHECK:BRACES: Unbalanced braces around else statement
#530: FILE: drivers/video/fbdev/core/fbcon.c:1822:
+ } else
-:536: CHECK:BRACES: braces {} should be used on all arms of this statement
#536: FILE: drivers/video/fbdev/core/fbcon.c:1828:
+ if ((p->yscroll + count <=
[...]
+ } else if (info->flags & FBINFO_READS_FAST)
[...]
+ else
[...]
-:538: CHECK:LOGICAL_CONTINUATIONS: Logical continuations should be on the previous line
#538: FILE: drivers/video/fbdev/core/fbcon.c:1830:
+ 2 * (p->vrows - vc->vc_rows))
+ && ((!scroll_partial && (b - t == vc->vc_rows))
-:539: CHECK:LOGICAL_CONTINUATIONS: Logical continuations should be on the previous line
#539: FILE: drivers/video/fbdev/core/fbcon.c:1831:
+ && ((!scroll_partial && (b - t == vc->vc_rows))
+ || (scroll_partial
-:540: CHECK:LOGICAL_CONTINUATIONS: Logical continuations should be on the previous line
#540: FILE: drivers/video/fbdev/core/fbcon.c:1832:
+ || (scroll_partial
+ && (b - t - count >
-:559: WARNING:INDENTED_LABEL: labels should not be indented
#559: FILE: drivers/video/fbdev/core/fbcon.c:1851:
+ redraw_up:
-:563: CHECK:SPACING: No space is necessary after a cast
#563: FILE: drivers/video/fbdev/core/fbcon.c:1855:
+ scr_memsetw((unsigned short *) (vc->vc_origin +
-:590: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#590: FILE: drivers/video/fbdev/core/fbcon.c:1884:
+ fbcon_redraw_blit(vc, info, p, b - 1, b - t - count,
+ -count);
-:592: CHECK:SPACING: No space is necessary after a cast
#592: FILE: drivers/video/fbdev/core/fbcon.c:1886:
+ scr_memsetw((unsigned short *) (vc->vc_origin +
-:600: CHECK:BRACES: braces {} should be used on all arms of this statement
#600: FILE: drivers/video/fbdev/core/fbcon.c:1894:
+ if (b - t - count > 3 * vc->vc_rows >> 2) {
[...]
+ } else if (info->flags & FBINFO_READS_FAST)
[...]
+ else
[...]
-:618: CHECK:BRACES: braces {} should be used on all arms of this statement
#618: FILE: drivers/video/fbdev/core/fbcon.c:1912:
+ if ((count - p->yscroll <= p->vrows - vc->vc_rows)
[...]
+ } else if (info->flags & FBINFO_READS_FAST)
[...]
+ else
[...]
-:619: CHECK:LOGICAL_CONTINUATIONS: Logical continuations should be on the previous line
#619: FILE: drivers/video/fbdev/core/fbcon.c:1913:
+ if ((count - p->yscroll <= p->vrows - vc->vc_rows)
+ && ((!scroll_partial && (b - t == vc->vc_rows))
-:620: CHECK:LOGICAL_CONTINUATIONS: Logical continuations should be on the previous line
#620: FILE: drivers/video/fbdev/core/fbcon.c:1914:
+ && ((!scroll_partial && (b - t == vc->vc_rows))
+ || (scroll_partial
-:621: CHECK:LOGICAL_CONTINUATIONS: Logical continuations should be on the previous line
#621: FILE: drivers/video/fbdev/core/fbcon.c:1915:
+ || (scroll_partial
+ && (b - t - count >
-:640: CHECK:BRACES: braces {} should be used on all arms of this statement
#640: FILE: drivers/video/fbdev/core/fbcon.c:1934:
+ if ((count - p->yscroll <= p->vrows - vc->vc_rows)
[...]
+ } else
[...]
-:641: CHECK:LOGICAL_CONTINUATIONS: Logical continuations should be on the previous line
#641: FILE: drivers/video/fbdev/core/fbcon.c:1935:
+ if ((count - p->yscroll <= p->vrows - vc->vc_rows)
+ && ((!scroll_partial && (b - t == vc->vc_rows))
-:642: CHECK:LOGICAL_CONTINUATIONS: Logical continuations should be on the previous line
#642: FILE: drivers/video/fbdev/core/fbcon.c:1936:
+ && ((!scroll_partial && (b - t == vc->vc_rows))
+ || (scroll_partial
-:643: CHECK:LOGICAL_CONTINUATIONS: Logical continuations should be on the previous line
#643: FILE: drivers/video/fbdev/core/fbcon.c:1937:
+ || (scroll_partial
+ && (b - t - count >
-:651: CHECK:BRACES: Unbalanced braces around else statement
#651: FILE: drivers/video/fbdev/core/fbcon.c:1945:
+ } else
-:657: WARNING:INDENTED_LABEL: labels should not be indented
#657: FILE: drivers/video/fbdev/core/fbcon.c:1951:
+ redraw_down:
-:661: CHECK:SPACING: No space is necessary after a cast
#661: FILE: drivers/video/fbdev/core/fbcon.c:1955:
+ scr_memsetw((unsigned short *) (vc->vc_origin +
-:673: CHECK:LINE_SPACING: Please don't use multiple blank lines
#673: FILE: drivers/video/fbdev/core/fbcon.c:1967:
+
-:708: WARNING:LEADING_SPACE: please, no spaces at the start of a line
#708: FILE: drivers/video/fbdev/core/fbcon.h:32:
+ u_short scrollmode; /* Scroll Method */$
-:792: CHECK:LINE_SPACING: Please don't use multiple blank lines
#792: FILE: drivers/video/fbdev/core/fbcon_ccw.c:62:
+
-:794: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#794: FILE: drivers/video/fbdev/core/fbcon_ccw.c:64:
+static void ccw_bmove(struct vc_data *vc, struct fb_info *info, int sy,
+ int sx, int dy, int dx, int height, int width)
-:864: CHECK:LINE_SPACING: Please don't use multiple blank lines
#864: FILE: drivers/video/fbdev/core/fbcon_cw.c:47:
+
-:937: ERROR:SPACING: space required after that ',' (ctx:VxV)
#937: FILE: drivers/video/fbdev/core/fbcon_rotate.h:15:
+#define GETVYRES(s,i) ({ \
^
-:937: CHECK:MACRO_ARG_REUSE: Macro argument reuse 's' - possible side-effects?
#937: FILE: drivers/video/fbdev/core/fbcon_rotate.h:15:
+#define GETVYRES(s,i) ({ \
+ (s == SCROLL_REDRAW || s == SCROLL_MOVE) ? \
+ (i)->var.yres : (i)->var.yres_virtual; })
-:937: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 's' may be better as '(s)' to avoid precedence issues
#937: FILE: drivers/video/fbdev/core/fbcon_rotate.h:15:
+#define GETVYRES(s,i) ({ \
+ (s == SCROLL_REDRAW || s == SCROLL_MOVE) ? \
+ (i)->var.yres : (i)->var.yres_virtual; })
-:937: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'i' - possible side-effects?
#937: FILE: drivers/video/fbdev/core/fbcon_rotate.h:15:
+#define GETVYRES(s,i) ({ \
+ (s == SCROLL_REDRAW || s == SCROLL_MOVE) ? \
+ (i)->var.yres : (i)->var.yres_virtual; })
-:938: ERROR:CODE_INDENT: code indent should use tabs where possible
#938: FILE: drivers/video/fbdev/core/fbcon_rotate.h:16:
+ (s == SCROLL_REDRAW || s == SCROLL_MOVE) ? \$
-:938: WARNING:LEADING_SPACE: please, no spaces at the start of a line
#938: FILE: drivers/video/fbdev/core/fbcon_rotate.h:16:
+ (s == SCROLL_REDRAW || s == SCROLL_MOVE) ? \$
-:939: ERROR:CODE_INDENT: code indent should use tabs where possible
#939: FILE: drivers/video/fbdev/core/fbcon_rotate.h:17:
+ (i)->var.yres : (i)->var.yres_virtual; })$
-:939: WARNING:LEADING_SPACE: please, no spaces at the start of a line
#939: FILE: drivers/video/fbdev/core/fbcon_rotate.h:17:
+ (i)->var.yres : (i)->var.yres_virtual; })$
-:941: ERROR:SPACING: space required after that ',' (ctx:VxV)
#941: FILE: drivers/video/fbdev/core/fbcon_rotate.h:19:
+#define GETVXRES(s,i) ({ \
^
-:941: CHECK:MACRO_ARG_REUSE: Macro argument reuse 's' - possible side-effects?
#941: FILE: drivers/video/fbdev/core/fbcon_rotate.h:19:
+#define GETVXRES(s,i) ({ \
+ (s == SCROLL_REDRAW || s == SCROLL_MOVE || !(i)->fix.xpanstep) ? \
+ (i)->var.xres : (i)->var.xres_virtual; })
-:941: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 's' may be better as '(s)' to avoid precedence issues
#941: FILE: drivers/video/fbdev/core/fbcon_rotate.h:19:
+#define GETVXRES(s,i) ({ \
+ (s == SCROLL_REDRAW || s == SCROLL_MOVE || !(i)->fix.xpanstep) ? \
+ (i)->var.xres : (i)->var.xres_virtual; })
-:941: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'i' - possible side-effects?
#941: FILE: drivers/video/fbdev/core/fbcon_rotate.h:19:
+#define GETVXRES(s,i) ({ \
+ (s == SCROLL_REDRAW || s == SCROLL_MOVE || !(i)->fix.xpanstep) ? \
+ (i)->var.xres : (i)->var.xres_virtual; })
-:942: ERROR:CODE_INDENT: code indent should use tabs where possible
#942: FILE: drivers/video/fbdev/core/fbcon_rotate.h:20:
+ (s == SCROLL_REDRAW || s == SCROLL_MOVE || !(i)->fix.xpanstep) ? \$
-:942: WARNING:LEADING_SPACE: please, no spaces at the start of a line
#942: FILE: drivers/video/fbdev/core/fbcon_rotate.h:20:
+ (s == SCROLL_REDRAW || s == SCROLL_MOVE || !(i)->fix.xpanstep) ? \$
-:943: ERROR:CODE_INDENT: code indent should use tabs where possible
#943: FILE: drivers/video/fbdev/core/fbcon_rotate.h:21:
+ (i)->var.xres : (i)->var.xres_virtual; })$
-:943: WARNING:LEADING_SPACE: please, no spaces at the start of a line
#943: FILE: drivers/video/fbdev/core/fbcon_rotate.h:21:
+ (i)->var.xres : (i)->var.xres_virtual; })$
-:956: CHECK:LINE_SPACING: Please don't use multiple blank lines
#956: FILE: drivers/video/fbdev/core/fbcon_rotate.h:34:
+
+
-:968: CHECK:LINE_SPACING: Please don't use multiple blank lines
#968: FILE: drivers/video/fbdev/core/fbcon_ud.c:47:
+
-:1085: WARNING:TYPO_SPELLING: 'acclerated' may be misspelled - perhaps 'accelerated'?
#1085: FILE: drivers/video/fbdev/skeletonfb.c:509:
+ * non acclerated hardware and packed pixel based.
^^^^^^^^^^
-:1105: WARNING:SPACE_BEFORE_TAB: please, no space before tabs
#1105: FILE: drivers/video/fbdev/skeletonfb.c:648:
+^I.fb_fillrect^I= xxxfb_fillrect, ^I/* Needed !!! */$
-:1123: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address mismatch: 'From: Daniel Vetter <daniel.vetter@ffwll.ch>' != 'Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>'
total: 6 errors, 19 warnings, 42 checks, 990 lines checked
a3878d341994 fbcon: Restore fbcon scrolling acceleration
-:6: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ chars of sha1> ("<title line>")' - ie: 'commit 39aead8373b3 ("fbcon: Disable accelerated scrolling")'
#6:
This functionally undoes 39aead8373b3 ("fbcon: Disable accelerated
-:10: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line)
#10:
References: https://lore.kernel.org/dri-devel/feea8303-2b83-fc36-972c-4fc8ad723bde@gmx.de/
-:25: WARNING:BAD_SIGN_OFF: Duplicate signature
#25:
Cc: Claudio Suarez <cssk@net-c.es>
-:109: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address mismatch: 'From: Daniel Vetter <daniel.vetter@ffwll.ch>' != 'Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>'
total: 1 errors, 3 warnings, 0 checks, 70 lines checked
4b1ab7c360e5 fbcon: delete a few unneeded forward decl
-:50: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address mismatch: 'From: Daniel Vetter <daniel.vetter@ffwll.ch>' != 'Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>'
total: 0 errors, 1 warnings, 0 checks, 27 lines checked
482b204b2d72 fbcon: Introduce wrapper for console->fb_info lookup
-:332: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address mismatch: 'From: Daniel Vetter <daniel.vetter@ffwll.ch>' != 'Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>'
total: 0 errors, 1 warnings, 0 checks, 274 lines checked
4c0e3378856f fbcon: delete delayed loading code
-:8: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ chars of sha1> ("<title line>")' - ie: 'commit 6104c37094e7 ("fbcon: Make fbcon a built-time depency for fbdev")'
#8:
commit 6104c37094e729f3d4ce65797002112735d49cd1
-:61: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address mismatch: 'From: Daniel Vetter <daniel.vetter@ffwll.ch>' != 'Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>'
total: 1 errors, 1 warnings, 0 checks, 25 lines checked
6207cb6973bd fbdev/sysfs: Fix locking
-:39: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address mismatch: 'From: Daniel Vetter <daniel.vetter@ffwll.ch>' != 'Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>'
total: 0 errors, 1 warnings, 0 checks, 11 lines checked
ce31c1587b43 fbcon: Use delayed work for cursor
-:281: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address mismatch: 'From: Daniel Vetter <daniel.vetter@ffwll.ch>' != 'Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>'
total: 0 errors, 1 warnings, 0 checks, 229 lines checked
e9dfbdcf4192 fbcon: Replace FBCON_FLAGS_INIT with a boolean
-:87: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address mismatch: 'From: Daniel Vetter <daniel.vetter@ffwll.ch>' != 'Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>'
total: 0 errors, 1 warnings, 0 checks, 57 lines checked
0483ab4cdecb fb: Delete fb_info->queue
-:24: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address mismatch: 'From: Daniel Vetter <daniel.vetter@ffwll.ch>' != 'Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>'
total: 0 errors, 1 warnings, 0 checks, 7 lines checked
4124d814f49e fbcon: Extract fbcon_open/release helpers
-:120: WARNING:BLOCK_COMMENT_STYLE: Block comments use * on subsequent lines
#120: FILE: drivers/video/fbdev/core/fbcon.c:757:
+ /*
+ If oldinfo and newinfo are driving the same hardware,
-:135: WARNING:PREFER_PR_LEVEL: Prefer [subsystem eg: netdev]_err([subsystem]dev, ... then dev_err(dev, ... then pr_err(... to printk(KERN_ERR ...
#135: FILE: drivers/video/fbdev/core/fbcon.c:767:
+ printk(KERN_ERR "con2fb_release_oldinfo: "
-:135: WARNING:EMBEDDED_FUNCTION_NAME: Prefer using '"%s...", __func__' to using 'con2fb_release_oldinfo', this function's name, in a string
#135: FILE: drivers/video/fbdev/core/fbcon.c:767:
+ printk(KERN_ERR "con2fb_release_oldinfo: "
-:192: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address mismatch: 'From: Daniel Vetter <daniel.vetter@ffwll.ch>' != 'Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>'
total: 0 errors, 4 warnings, 0 checks, 164 lines checked
6a6fc4806be7 fbcon: Ditch error handling for con2fb_release_oldinfo
-:100: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address mismatch: 'From: Daniel Vetter <daniel.vetter@ffwll.ch>' != 'Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>'
total: 0 errors, 1 warnings, 0 checks, 75 lines checked
199ad49ede08 fbcon: move more common code into fb_open()
-:47: CHECK:ALLOC_SIZEOF_STRUCT: Prefer kzalloc(sizeof(*ops)...) over kzalloc(sizeof(struct fbcon_ops)...)
#47: FILE: drivers/video/fbdev/core/fbcon.c:704:
+ ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL);
-:148: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address mismatch: 'From: Daniel Vetter <daniel.vetter@ffwll.ch>' != 'Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>'
total: 0 errors, 1 warnings, 1 checks, 121 lines checked
93f1d498d62f fbcon: use lock_fb_info in fbcon_open/release
-:93: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address mismatch: 'From: Daniel Vetter <daniel.vetter@ffwll.ch>' != 'Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>'
total: 0 errors, 1 warnings, 0 checks, 42 lines checked
d73c168f66f2 fbcon: Consistently protect deferred_takeover with console_lock()
-:42: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address mismatch: 'From: Daniel Vetter <daniel.vetter@ffwll.ch>' != 'Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>'
total: 0 errors, 1 warnings, 0 checks, 17 lines checked
4dbf1caeaf85 fbcon: Move console_lock for register/unlink/unregister
-:86: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#86: FILE: drivers/video/fbdev/core/fbcon.c:2923:
+MODULE_PARM_DESC(lockless_register_fb,
+ "Lockless framebuffer registration for debugging [default=off]");
-:180: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address mismatch: 'From: Daniel Vetter <daniel.vetter@ffwll.ch>' != 'Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>'
total: 0 errors, 1 warnings, 1 checks, 135 lines checked
e4f1a224b67c fbcon: Move more code into fbcon_release
-:80: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address mismatch: 'From: Daniel Vetter <daniel.vetter@ffwll.ch>' != 'Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>'
total: 0 errors, 1 warnings, 0 checks, 56 lines checked
b50c29f9b1d2 fbcon: untangle fbcon_exit
-:128: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address mismatch: 'From: Daniel Vetter <daniel.vetter@ffwll.ch>' != 'Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>'
total: 0 errors, 1 warnings, 0 checks, 96 lines checked
8994bd236b87 fbcon: Maintain a private array of fb_info
-:48: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in parentheses
#48: FILE: drivers/video/fbdev/core/fbcon.c:109:
+#define fbcon_for_each_registered_fb(i) \
+ for (i = 0; WARN_CONSOLE_UNLOCKED(), i < FB_MAX; i++) \
+ if (!fbcon_registered_fb[i]) {} else
-:48: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'i' - possible side-effects?
#48: FILE: drivers/video/fbdev/core/fbcon.c:109:
+#define fbcon_for_each_registered_fb(i) \
+ for (i = 0; WARN_CONSOLE_UNLOCKED(), i < FB_MAX; i++) \
+ if (!fbcon_registered_fb[i]) {} else
-:50: ERROR:TRAILING_STATEMENTS: trailing statements should be on next line
#50: FILE: drivers/video/fbdev/core/fbcon.c:111:
+ if (!fbcon_registered_fb[i]) {} else
-:50: WARNING:BRACES: braces {} are not necessary for any arm of this statement
#50: FILE: drivers/video/fbdev/core/fbcon.c:111:
+ if (!fbcon_registered_fb[i]) {} else
[...]
+ if (!fbcon_registered_fb[i]) {} else
[...]
-:210: WARNING:BRACES: braces {} are not necessary for single statement blocks
#210: FILE: drivers/video/fbdev/core/fbcon.c:3084:
+ if (!fbcon_registered_fb[con2fb.framebuffer]) {
return -EINVAL;
}
-:219: CHECK:COMPARISON_TO_NULL: Comparison to NULL could be written "!fbcon_registered_fb[idx]"
#219: FILE: drivers/video/fbdev/core/fbcon.c:3151:
+ if (idx == -1 || fbcon_registered_fb[idx] == NULL)
-:232: CHECK:COMPARISON_TO_NULL: Comparison to NULL could be written "!fbcon_registered_fb[idx]"
#232: FILE: drivers/video/fbdev/core/fbcon.c:3173:
+ if (idx == -1 || fbcon_registered_fb[idx] == NULL)
-:245: CHECK:COMPARISON_TO_NULL: Comparison to NULL could be written "!fbcon_registered_fb[idx]"
#245: FILE: drivers/video/fbdev/core/fbcon.c:3193:
+ if (idx == -1 || fbcon_registered_fb[idx] == NULL)
-:258: CHECK:COMPARISON_TO_NULL: Comparison to NULL could be written "!fbcon_registered_fb[idx]"
#258: FILE: drivers/video/fbdev/core/fbcon.c:3213:
+ if (idx == -1 || fbcon_registered_fb[idx] == NULL)
-:271: CHECK:COMPARISON_TO_NULL: Comparison to NULL could be written "!fbcon_registered_fb[idx]"
#271: FILE: drivers/video/fbdev/core/fbcon.c:3239:
+ if (idx == -1 || fbcon_registered_fb[idx] == NULL)
-:289: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address mismatch: 'From: Daniel Vetter <daniel.vetter@ffwll.ch>' != 'Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>'
total: 2 errors, 3 warnings, 6 checks, 237 lines checked
b19815011a55 Revert "fbdev: Prevent probing generic drivers if a FB is already registered"
-:11: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+ chars of sha1> ("<title line>")' - ie: 'commit 27599aacbaef ("fbdev: Hot-unplug firmware fb devices on forced removal")'
#11:
commit 27599aacbaefcbf2af7b06b0029459bbf682000d
-:24: WARNING:BAD_SIGN_OFF: Duplicate signature
#24:
Cc: Zack Rusin <zackr@vmware.com>
-:74: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address mismatch: 'From: Daniel Vetter <daniel.vetter@ffwll.ch>' != 'Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>'
total: 1 errors, 2 warnings, 0 checks, 34 lines checked
142774bdcb86 fbdev: Make registered_fb[] private to fbmem.c
-:43: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in parentheses
#43: FILE: drivers/video/fbdev/core/fbmem.c:57:
+#define for_each_registered_fb(i) \
+ for (i = 0; i < FB_MAX; i++) \
+ if (!registered_fb[i]) {} else
-:43: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'i' - possible side-effects?
#43: FILE: drivers/video/fbdev/core/fbmem.c:57:
+#define for_each_registered_fb(i) \
+ for (i = 0; i < FB_MAX; i++) \
+ if (!registered_fb[i]) {} else
-:45: ERROR:TRAILING_STATEMENTS: trailing statements should be on next line
#45: FILE: drivers/video/fbdev/core/fbmem.c:59:
+ if (!registered_fb[i]) {} else
-:45: WARNING:BRACES: braces {} are not necessary for any arm of this statement
#45: FILE: drivers/video/fbdev/core/fbmem.c:59:
+ if (!registered_fb[i]) {} else
[...]
+ if (!registered_fb[i]) {} else
[...]
-:72: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address mismatch: 'From: Daniel Vetter <daniel.vetter@ffwll.ch>' != 'Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>'
total: 2 errors, 2 warnings, 1 checks, 35 lines checked
^ permalink raw reply [flat|nested] 241+ messages in thread
* [Intel-gfx] ✗ Fi.CI.SPARSE: warning for some fbcon patches, mostly locking
2022-01-31 21:05 ` Daniel Vetter
` (23 preceding siblings ...)
(?)
@ 2022-01-31 21:19 ` Patchwork
-1 siblings, 0 replies; 241+ messages in thread
From: Patchwork @ 2022-01-31 21:19 UTC (permalink / raw)
To: Daniel Vetter; +Cc: intel-gfx
== Series Details ==
Series: some fbcon patches, mostly locking
URL : https://patchwork.freedesktop.org/series/99549/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
^ permalink raw reply [flat|nested] 241+ messages in thread
* [Intel-gfx] ✗ Fi.CI.BAT: failure for some fbcon patches, mostly locking
2022-01-31 21:05 ` Daniel Vetter
` (24 preceding siblings ...)
(?)
@ 2022-01-31 21:51 ` Patchwork
-1 siblings, 0 replies; 241+ messages in thread
From: Patchwork @ 2022-01-31 21:51 UTC (permalink / raw)
To: Daniel Vetter; +Cc: intel-gfx
[-- Attachment #1: Type: text/plain, Size: 9264 bytes --]
== Series Details ==
Series: some fbcon patches, mostly locking
URL : https://patchwork.freedesktop.org/series/99549/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11166 -> Patchwork_22144
====================================================
Summary
-------
**FAILURE**
Serious unknown changes coming with Patchwork_22144 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_22144, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22144/index.html
Participating hosts (46 -> 44)
------------------------------
Additional (1): fi-pnv-d510
Missing (3): fi-jsl-1 shard-tglu fi-bdw-samus
Possible new issues
-------------------
Here are the unknown changes that may have been introduced in Patchwork_22144:
### IGT changes ###
#### Possible regressions ####
* igt@i915_selftest@live@hangcheck:
- fi-bdw-5557u: NOTRUN -> [INCOMPLETE][1]
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22144/fi-bdw-5557u/igt@i915_selftest@live@hangcheck.html
* igt@i915_selftest@live@reset:
- bat-adlp-4: [PASS][2] -> [DMESG-FAIL][3]
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11166/bat-adlp-4/igt@i915_selftest@live@reset.html
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22144/bat-adlp-4/igt@i915_selftest@live@reset.html
#### Suppressed ####
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live@workarounds:
- {bat-adlp-6}: [PASS][4] -> [DMESG-WARN][5]
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11166/bat-adlp-6/igt@i915_selftest@live@workarounds.html
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22144/bat-adlp-6/igt@i915_selftest@live@workarounds.html
Known issues
------------
Here are the changes found in Patchwork_22144 that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@amdgpu/amd_cs_nop@fork-compute0:
- fi-blb-e6850: NOTRUN -> [SKIP][6] ([fdo#109271]) +17 similar issues
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22144/fi-blb-e6850/igt@amdgpu/amd_cs_nop@fork-compute0.html
* igt@gem_huc_copy@huc-copy:
- fi-skl-6600u: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#2190])
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22144/fi-skl-6600u/igt@gem_huc_copy@huc-copy.html
- fi-pnv-d510: NOTRUN -> [SKIP][8] ([fdo#109271]) +57 similar issues
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22144/fi-pnv-d510/igt@gem_huc_copy@huc-copy.html
* igt@gem_lmem_swapping@verify-random:
- fi-skl-6600u: NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#4613]) +3 similar issues
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22144/fi-skl-6600u/igt@gem_lmem_swapping@verify-random.html
* igt@i915_selftest@live@hangcheck:
- fi-hsw-4770: [PASS][10] -> [INCOMPLETE][11] ([i915#4785])
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11166/fi-hsw-4770/igt@i915_selftest@live@hangcheck.html
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22144/fi-hsw-4770/igt@i915_selftest@live@hangcheck.html
* igt@kms_chamelium@vga-edid-read:
- fi-skl-6600u: NOTRUN -> [SKIP][12] ([fdo#109271] / [fdo#111827]) +8 similar issues
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22144/fi-skl-6600u/igt@kms_chamelium@vga-edid-read.html
- fi-bdw-5557u: NOTRUN -> [SKIP][13] ([fdo#109271] / [fdo#111827]) +8 similar issues
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22144/fi-bdw-5557u/igt@kms_chamelium@vga-edid-read.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-skl-6600u: NOTRUN -> [SKIP][14] ([fdo#109271]) +2 similar issues
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22144/fi-skl-6600u/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy.html
* igt@kms_frontbuffer_tracking@basic:
- fi-cml-u2: [PASS][15] -> [DMESG-WARN][16] ([i915#4269])
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11166/fi-cml-u2/igt@kms_frontbuffer_tracking@basic.html
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22144/fi-cml-u2/igt@kms_frontbuffer_tracking@basic.html
* igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-skl-6600u: NOTRUN -> [SKIP][17] ([fdo#109271] / [i915#533])
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22144/fi-skl-6600u/igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d.html
* igt@kms_psr@cursor_plane_move:
- fi-bdw-5557u: NOTRUN -> [SKIP][18] ([fdo#109271]) +13 similar issues
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22144/fi-bdw-5557u/igt@kms_psr@cursor_plane_move.html
* igt@kms_psr@primary_page_flip:
- fi-skl-6600u: NOTRUN -> [FAIL][19] ([i915#4547])
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22144/fi-skl-6600u/igt@kms_psr@primary_page_flip.html
* igt@runner@aborted:
- fi-hsw-4770: NOTRUN -> [FAIL][20] ([fdo#109271] / [i915#1436] / [i915#4312])
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22144/fi-hsw-4770/igt@runner@aborted.html
- bat-adlp-4: NOTRUN -> [FAIL][21] ([i915#4312])
[21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22144/bat-adlp-4/igt@runner@aborted.html
#### Possible fixes ####
* igt@gem_flink_basic@bad-flink:
- fi-skl-6600u: [INCOMPLETE][22] ([i915#4547]) -> [PASS][23]
[22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11166/fi-skl-6600u/igt@gem_flink_basic@bad-flink.html
[23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22144/fi-skl-6600u/igt@gem_flink_basic@bad-flink.html
* igt@i915_selftest@live@requests:
- fi-blb-e6850: [DMESG-FAIL][24] -> [PASS][25]
[24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11166/fi-blb-e6850/igt@i915_selftest@live@requests.html
[25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22144/fi-blb-e6850/igt@i915_selftest@live@requests.html
#### Warnings ####
* igt@runner@aborted:
- fi-skl-6600u: [FAIL][26] ([i915#2722] / [i915#4312]) -> [FAIL][27] ([i915#4312])
[26]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11166/fi-skl-6600u/igt@runner@aborted.html
[27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22144/fi-skl-6600u/igt@runner@aborted.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
[i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
[i915#2722]: https://gitlab.freedesktop.org/drm/intel/issues/2722
[i915#4269]: https://gitlab.freedesktop.org/drm/intel/issues/4269
[i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
[i915#4547]: https://gitlab.freedesktop.org/drm/intel/issues/4547
[i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
[i915#4785]: https://gitlab.freedesktop.org/drm/intel/issues/4785
[i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533
Build changes
-------------
* Linux: CI_DRM_11166 -> Patchwork_22144
CI-20190529: 20190529
CI_DRM_11166: b53a9df3f283e932b827c328fd165b56b6d3bccb @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_6337: 7c9c034619ef9dbfbfe041fbf3973a1cf1ac7a22 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_22144: 142774bdcb86feaa7515104dd1a0583d2c089944 @ git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
142774bdcb86 fbdev: Make registered_fb[] private to fbmem.c
b19815011a55 Revert "fbdev: Prevent probing generic drivers if a FB is already registered"
8994bd236b87 fbcon: Maintain a private array of fb_info
b50c29f9b1d2 fbcon: untangle fbcon_exit
e4f1a224b67c fbcon: Move more code into fbcon_release
4dbf1caeaf85 fbcon: Move console_lock for register/unlink/unregister
d73c168f66f2 fbcon: Consistently protect deferred_takeover with console_lock()
93f1d498d62f fbcon: use lock_fb_info in fbcon_open/release
199ad49ede08 fbcon: move more common code into fb_open()
6a6fc4806be7 fbcon: Ditch error handling for con2fb_release_oldinfo
4124d814f49e fbcon: Extract fbcon_open/release helpers
0483ab4cdecb fb: Delete fb_info->queue
e9dfbdcf4192 fbcon: Replace FBCON_FLAGS_INIT with a boolean
ce31c1587b43 fbcon: Use delayed work for cursor
6207cb6973bd fbdev/sysfs: Fix locking
4c0e3378856f fbcon: delete delayed loading code
482b204b2d72 fbcon: Introduce wrapper for console->fb_info lookup
4b1ab7c360e5 fbcon: delete a few unneeded forward decl
a3878d341994 fbcon: Restore fbcon scrolling acceleration
9029711bda24 fbcon: Resurrect fbcon accelerated scrolling code
8895b11855ce MAINTAINERS: Add entry for fbdev core
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22144/index.html
[-- Attachment #2: Type: text/html, Size: 11446 bytes --]
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [Intel-gfx] [PATCH 13/21] fbcon: move more common code into fb_open()
2022-01-31 21:05 ` [Intel-gfx] " Daniel Vetter
(?)
@ 2022-01-31 23:31 ` kernel test robot
-1 siblings, 0 replies; 241+ messages in thread
From: kernel test robot @ 2022-01-31 23:31 UTC (permalink / raw)
To: Daniel Vetter, DRI Development
Cc: kbuild-all, linux-fbdev, Thomas Zimmermann, Du Cheng,
Tetsuo Handa, Daniel Vetter, Intel Graphics Development, LKML,
Greg Kroah-Hartman
Hi Daniel,
I love your patch! Perhaps something to improve:
[auto build test WARNING on tegra-drm/drm/tegra/for-next]
[also build test WARNING on drm/drm-next linus/master v5.17-rc2 next-20220131]
[cannot apply to airlied/drm-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url: https://github.com/0day-ci/linux/commits/Daniel-Vetter/some-fbcon-patches-mostly-locking/20220201-050907
base: git://anongit.freedesktop.org/tegra/linux.git drm/tegra/for-next
config: mips-allyesconfig (https://download.01.org/0day-ci/archive/20220201/202202010613.HT19HztX-lkp@intel.com/config)
compiler: mips-linux-gcc (GCC) 11.2.0
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# https://github.com/0day-ci/linux/commit/7a27c0ce71acfa8b67787d298de9836376fcc323
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review Daniel-Vetter/some-fbcon-patches-mostly-locking/20220201-050907
git checkout 7a27c0ce71acfa8b67787d298de9836376fcc323
# save the config file to linux build tree
mkdir build_dir
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross O=build_dir ARCH=mips SHELL=/bin/bash drivers/video/fbdev/core/
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All warnings (new ones prefixed by >>):
drivers/video/fbdev/core/fbcon.c: In function 'con2fb_acquire_newinfo':
>> drivers/video/fbdev/core/fbcon.c:721:27: warning: variable 'ops' set but not used [-Wunused-but-set-variable]
721 | struct fbcon_ops *ops = NULL;
| ^~~
vim +/ops +721 drivers/video/fbdev/core/fbcon.c
^1da177e4c3f415 drivers/video/console/fbcon.c Linus Torvalds 2005-04-16 717
^1da177e4c3f415 drivers/video/console/fbcon.c Linus Torvalds 2005-04-16 718 static int con2fb_acquire_newinfo(struct vc_data *vc, struct fb_info *info,
7a27c0ce71acfa8 drivers/video/fbdev/core/fbcon.c Daniel Vetter 2022-01-31 719 int unit)
^1da177e4c3f415 drivers/video/console/fbcon.c Linus Torvalds 2005-04-16 720 {
^1da177e4c3f415 drivers/video/console/fbcon.c Linus Torvalds 2005-04-16 @721 struct fbcon_ops *ops = NULL;
ba35a78b17408b6 drivers/video/fbdev/core/fbcon.c Daniel Vetter 2022-01-31 722 int err;
^1da177e4c3f415 drivers/video/console/fbcon.c Linus Torvalds 2005-04-16 723
ba35a78b17408b6 drivers/video/fbdev/core/fbcon.c Daniel Vetter 2022-01-31 724 err = fbcon_open(info);
ba35a78b17408b6 drivers/video/fbdev/core/fbcon.c Daniel Vetter 2022-01-31 725 if (err)
ba35a78b17408b6 drivers/video/fbdev/core/fbcon.c Daniel Vetter 2022-01-31 726 return err;
^1da177e4c3f415 drivers/video/console/fbcon.c Linus Torvalds 2005-04-16 727
7a27c0ce71acfa8 drivers/video/fbdev/core/fbcon.c Daniel Vetter 2022-01-31 728 ops = info->fbcon_par;
d1baa4ffa677bf6 drivers/video/console/fbcon.c Antonino A. Daplas 2007-07-17 729
d1baa4ffa677bf6 drivers/video/console/fbcon.c Antonino A. Daplas 2007-07-17 730 if (vc)
b73deed32d08740 drivers/video/console/fbcon.c Antonino A. Daplas 2006-01-09 731 set_blitting_type(vc, info);
^1da177e4c3f415 drivers/video/console/fbcon.c Linus Torvalds 2005-04-16 732
^1da177e4c3f415 drivers/video/console/fbcon.c Linus Torvalds 2005-04-16 733 return err;
^1da177e4c3f415 drivers/video/console/fbcon.c Linus Torvalds 2005-04-16 734 }
^1da177e4c3f415 drivers/video/console/fbcon.c Linus Torvalds 2005-04-16 735
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [Intel-gfx] [PATCH 13/21] fbcon: move more common code into fb_open()
@ 2022-01-31 23:31 ` kernel test robot
0 siblings, 0 replies; 241+ messages in thread
From: kernel test robot @ 2022-01-31 23:31 UTC (permalink / raw)
To: Daniel Vetter, DRI Development
Cc: linux-fbdev, kbuild-all, Du Cheng, Tetsuo Handa, Daniel Vetter,
Intel Graphics Development, LKML, Thomas Zimmermann,
Greg Kroah-Hartman
Hi Daniel,
I love your patch! Perhaps something to improve:
[auto build test WARNING on tegra-drm/drm/tegra/for-next]
[also build test WARNING on drm/drm-next linus/master v5.17-rc2 next-20220131]
[cannot apply to airlied/drm-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url: https://github.com/0day-ci/linux/commits/Daniel-Vetter/some-fbcon-patches-mostly-locking/20220201-050907
base: git://anongit.freedesktop.org/tegra/linux.git drm/tegra/for-next
config: mips-allyesconfig (https://download.01.org/0day-ci/archive/20220201/202202010613.HT19HztX-lkp@intel.com/config)
compiler: mips-linux-gcc (GCC) 11.2.0
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# https://github.com/0day-ci/linux/commit/7a27c0ce71acfa8b67787d298de9836376fcc323
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review Daniel-Vetter/some-fbcon-patches-mostly-locking/20220201-050907
git checkout 7a27c0ce71acfa8b67787d298de9836376fcc323
# save the config file to linux build tree
mkdir build_dir
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross O=build_dir ARCH=mips SHELL=/bin/bash drivers/video/fbdev/core/
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All warnings (new ones prefixed by >>):
drivers/video/fbdev/core/fbcon.c: In function 'con2fb_acquire_newinfo':
>> drivers/video/fbdev/core/fbcon.c:721:27: warning: variable 'ops' set but not used [-Wunused-but-set-variable]
721 | struct fbcon_ops *ops = NULL;
| ^~~
vim +/ops +721 drivers/video/fbdev/core/fbcon.c
^1da177e4c3f415 drivers/video/console/fbcon.c Linus Torvalds 2005-04-16 717
^1da177e4c3f415 drivers/video/console/fbcon.c Linus Torvalds 2005-04-16 718 static int con2fb_acquire_newinfo(struct vc_data *vc, struct fb_info *info,
7a27c0ce71acfa8 drivers/video/fbdev/core/fbcon.c Daniel Vetter 2022-01-31 719 int unit)
^1da177e4c3f415 drivers/video/console/fbcon.c Linus Torvalds 2005-04-16 720 {
^1da177e4c3f415 drivers/video/console/fbcon.c Linus Torvalds 2005-04-16 @721 struct fbcon_ops *ops = NULL;
ba35a78b17408b6 drivers/video/fbdev/core/fbcon.c Daniel Vetter 2022-01-31 722 int err;
^1da177e4c3f415 drivers/video/console/fbcon.c Linus Torvalds 2005-04-16 723
ba35a78b17408b6 drivers/video/fbdev/core/fbcon.c Daniel Vetter 2022-01-31 724 err = fbcon_open(info);
ba35a78b17408b6 drivers/video/fbdev/core/fbcon.c Daniel Vetter 2022-01-31 725 if (err)
ba35a78b17408b6 drivers/video/fbdev/core/fbcon.c Daniel Vetter 2022-01-31 726 return err;
^1da177e4c3f415 drivers/video/console/fbcon.c Linus Torvalds 2005-04-16 727
7a27c0ce71acfa8 drivers/video/fbdev/core/fbcon.c Daniel Vetter 2022-01-31 728 ops = info->fbcon_par;
d1baa4ffa677bf6 drivers/video/console/fbcon.c Antonino A. Daplas 2007-07-17 729
d1baa4ffa677bf6 drivers/video/console/fbcon.c Antonino A. Daplas 2007-07-17 730 if (vc)
b73deed32d08740 drivers/video/console/fbcon.c Antonino A. Daplas 2006-01-09 731 set_blitting_type(vc, info);
^1da177e4c3f415 drivers/video/console/fbcon.c Linus Torvalds 2005-04-16 732
^1da177e4c3f415 drivers/video/console/fbcon.c Linus Torvalds 2005-04-16 733 return err;
^1da177e4c3f415 drivers/video/console/fbcon.c Linus Torvalds 2005-04-16 734 }
^1da177e4c3f415 drivers/video/console/fbcon.c Linus Torvalds 2005-04-16 735
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [Intel-gfx] [PATCH 13/21] fbcon: move more common code into fb_open()
@ 2022-01-31 23:31 ` kernel test robot
0 siblings, 0 replies; 241+ messages in thread
From: kernel test robot @ 2022-01-31 23:31 UTC (permalink / raw)
To: kbuild-all
[-- Attachment #1: Type: text/plain, Size: 4019 bytes --]
Hi Daniel,
I love your patch! Perhaps something to improve:
[auto build test WARNING on tegra-drm/drm/tegra/for-next]
[also build test WARNING on drm/drm-next linus/master v5.17-rc2 next-20220131]
[cannot apply to airlied/drm-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url: https://github.com/0day-ci/linux/commits/Daniel-Vetter/some-fbcon-patches-mostly-locking/20220201-050907
base: git://anongit.freedesktop.org/tegra/linux.git drm/tegra/for-next
config: mips-allyesconfig (https://download.01.org/0day-ci/archive/20220201/202202010613.HT19HztX-lkp(a)intel.com/config)
compiler: mips-linux-gcc (GCC) 11.2.0
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# https://github.com/0day-ci/linux/commit/7a27c0ce71acfa8b67787d298de9836376fcc323
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review Daniel-Vetter/some-fbcon-patches-mostly-locking/20220201-050907
git checkout 7a27c0ce71acfa8b67787d298de9836376fcc323
# save the config file to linux build tree
mkdir build_dir
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross O=build_dir ARCH=mips SHELL=/bin/bash drivers/video/fbdev/core/
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All warnings (new ones prefixed by >>):
drivers/video/fbdev/core/fbcon.c: In function 'con2fb_acquire_newinfo':
>> drivers/video/fbdev/core/fbcon.c:721:27: warning: variable 'ops' set but not used [-Wunused-but-set-variable]
721 | struct fbcon_ops *ops = NULL;
| ^~~
vim +/ops +721 drivers/video/fbdev/core/fbcon.c
^1da177e4c3f415 drivers/video/console/fbcon.c Linus Torvalds 2005-04-16 717
^1da177e4c3f415 drivers/video/console/fbcon.c Linus Torvalds 2005-04-16 718 static int con2fb_acquire_newinfo(struct vc_data *vc, struct fb_info *info,
7a27c0ce71acfa8 drivers/video/fbdev/core/fbcon.c Daniel Vetter 2022-01-31 719 int unit)
^1da177e4c3f415 drivers/video/console/fbcon.c Linus Torvalds 2005-04-16 720 {
^1da177e4c3f415 drivers/video/console/fbcon.c Linus Torvalds 2005-04-16 @721 struct fbcon_ops *ops = NULL;
ba35a78b17408b6 drivers/video/fbdev/core/fbcon.c Daniel Vetter 2022-01-31 722 int err;
^1da177e4c3f415 drivers/video/console/fbcon.c Linus Torvalds 2005-04-16 723
ba35a78b17408b6 drivers/video/fbdev/core/fbcon.c Daniel Vetter 2022-01-31 724 err = fbcon_open(info);
ba35a78b17408b6 drivers/video/fbdev/core/fbcon.c Daniel Vetter 2022-01-31 725 if (err)
ba35a78b17408b6 drivers/video/fbdev/core/fbcon.c Daniel Vetter 2022-01-31 726 return err;
^1da177e4c3f415 drivers/video/console/fbcon.c Linus Torvalds 2005-04-16 727
7a27c0ce71acfa8 drivers/video/fbdev/core/fbcon.c Daniel Vetter 2022-01-31 728 ops = info->fbcon_par;
d1baa4ffa677bf6 drivers/video/console/fbcon.c Antonino A. Daplas 2007-07-17 729
d1baa4ffa677bf6 drivers/video/console/fbcon.c Antonino A. Daplas 2007-07-17 730 if (vc)
b73deed32d08740 drivers/video/console/fbcon.c Antonino A. Daplas 2006-01-09 731 set_blitting_type(vc, info);
^1da177e4c3f415 drivers/video/console/fbcon.c Linus Torvalds 2005-04-16 732
^1da177e4c3f415 drivers/video/console/fbcon.c Linus Torvalds 2005-04-16 733 return err;
^1da177e4c3f415 drivers/video/console/fbcon.c Linus Torvalds 2005-04-16 734 }
^1da177e4c3f415 drivers/video/console/fbcon.c Linus Torvalds 2005-04-16 735
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [Intel-gfx] [PATCH 21/21] fbdev: Make registered_fb[] private to fbmem.c
2022-01-31 21:05 ` Daniel Vetter
(?)
@ 2022-02-01 8:13 ` kernel test robot
-1 siblings, 0 replies; 241+ messages in thread
From: kernel test robot @ 2022-02-01 8:13 UTC (permalink / raw)
To: Daniel Vetter, DRI Development
Cc: kbuild-all, linux-fbdev, Zheyu Ma, Xiyu Yang, Jens Frederich,
Tetsuo Handa, Daniel Vetter, Intel Graphics Development,
linux-staging, LKML
Hi Daniel,
I love your patch! Yet something to improve:
[auto build test ERROR on tegra-drm/drm/tegra/for-next]
[also build test ERROR on drm/drm-next linus/master v5.17-rc2 next-20220131]
[cannot apply to airlied/drm-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url: https://github.com/0day-ci/linux/commits/Daniel-Vetter/some-fbcon-patches-mostly-locking/20220201-050907
base: git://anongit.freedesktop.org/tegra/linux.git drm/tegra/for-next
config: i386-allyesconfig (https://download.01.org/0day-ci/archive/20220201/202202011603.vczWPod7-lkp@intel.com/config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce (this is a W=1 build):
# https://github.com/0day-ci/linux/commit/245da5ab93b17c0cf1521713d5bde655a72efb65
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review Daniel-Vetter/some-fbcon-patches-mostly-locking/20220201-050907
git checkout 245da5ab93b17c0cf1521713d5bde655a72efb65
# save the config file to linux build tree
mkdir build_dir
make W=1 O=build_dir ARCH=i386 SHELL=/bin/bash
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
drivers/staging/olpc_dcon/olpc_dcon.c: In function 'dcon_probe':
>> drivers/staging/olpc_dcon/olpc_dcon.c:605:6: error: 'num_registered_fb' undeclared (first use in this function); did you mean 'WB_registered'?
605 | if (num_registered_fb < 1) {
| ^~~~~~~~~~~~~~~~~
| WB_registered
drivers/staging/olpc_dcon/olpc_dcon.c:605:6: note: each undeclared identifier is reported only once for each function it appears in
>> drivers/staging/olpc_dcon/olpc_dcon.c:610:17: error: 'registered_fb' undeclared (first use in this function)
610 | dcon->fbinfo = registered_fb[0];
| ^~~~~~~~~~~~~
vim +605 drivers/staging/olpc_dcon/olpc_dcon.c
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 584
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 585 static int dcon_probe(struct i2c_client *client, const struct i2c_device_id *id)
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 586 {
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 587 struct dcon_priv *dcon;
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 588 int rc, i, j;
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 589
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 590 if (!pdata)
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 591 return -ENXIO;
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 592
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 593 dcon = kzalloc(sizeof(*dcon), GFP_KERNEL);
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 594 if (!dcon)
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 595 return -ENOMEM;
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 596
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 597 dcon->client = client;
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 598 init_waitqueue_head(&dcon->waitq);
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 599 INIT_WORK(&dcon->switch_source, dcon_source_switch);
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 600 dcon->reboot_nb.notifier_call = dcon_reboot_notify;
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 601 dcon->reboot_nb.priority = -1;
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 602
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 603 i2c_set_clientdata(client, dcon);
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 604
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 @605 if (num_registered_fb < 1) {
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 606 dev_err(&client->dev, "DCON driver requires a registered fb\n");
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 607 rc = -EIO;
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 608 goto einit;
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 609 }
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 @610 dcon->fbinfo = registered_fb[0];
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 611
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 612 rc = dcon_hw_init(dcon, 1);
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 613 if (rc)
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 614 goto einit;
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 615
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 616 /* Add the DCON device */
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 617
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 618 dcon_device = platform_device_alloc("dcon", -1);
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 619
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 620 if (!dcon_device) {
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 621 pr_err("Unable to create the DCON device\n");
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 622 rc = -ENOMEM;
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 623 goto eirq;
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 624 }
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 625 rc = platform_device_add(dcon_device);
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 626 platform_set_drvdata(dcon_device, dcon);
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 627
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 628 if (rc) {
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 629 pr_err("Unable to add the DCON device\n");
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 630 goto edev;
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 631 }
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 632
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 633 for (i = 0; i < ARRAY_SIZE(dcon_device_files); i++) {
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 634 rc = device_create_file(&dcon_device->dev,
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 635 &dcon_device_files[i]);
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 636 if (rc) {
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 637 dev_err(&dcon_device->dev, "Cannot create sysfs file\n");
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 638 goto ecreate;
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 639 }
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 640 }
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 641
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 642 dcon->bl_val = dcon_read(dcon, DCON_REG_BRIGHT) & 0x0F;
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 643
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 644 /* Add the backlight device for the DCON */
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 645 dcon_bl_props.brightness = dcon->bl_val;
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 646 dcon->bl_dev = backlight_device_register("dcon-bl", &dcon_device->dev,
848d9eabcaebf21 Zebulon McCorkle 2017-11-21 647 dcon, &dcon_bl_ops,
848d9eabcaebf21 Zebulon McCorkle 2017-11-21 648 &dcon_bl_props);
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 649 if (IS_ERR(dcon->bl_dev)) {
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 650 dev_err(&client->dev, "cannot register backlight dev (%ld)\n",
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 651 PTR_ERR(dcon->bl_dev));
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 652 dcon->bl_dev = NULL;
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 653 }
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 654
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 655 register_reboot_notifier(&dcon->reboot_nb);
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 656 atomic_notifier_chain_register(&panic_notifier_list, &dcon_panic_nb);
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 657
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 658 return 0;
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 659
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 660 ecreate:
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 661 for (j = 0; j < i; j++)
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 662 device_remove_file(&dcon_device->dev, &dcon_device_files[j]);
4996b4610767064 Jing Xiangfeng 2020-11-20 663 platform_device_del(dcon_device);
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 664 edev:
4996b4610767064 Jing Xiangfeng 2020-11-20 665 platform_device_put(dcon_device);
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 666 dcon_device = NULL;
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 667 eirq:
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 668 free_irq(DCON_IRQ, dcon);
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 669 einit:
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 670 kfree(dcon);
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 671 return rc;
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 672 }
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 673
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [Intel-gfx] [PATCH 21/21] fbdev: Make registered_fb[] private to fbmem.c
@ 2022-02-01 8:13 ` kernel test robot
0 siblings, 0 replies; 241+ messages in thread
From: kernel test robot @ 2022-02-01 8:13 UTC (permalink / raw)
To: Daniel Vetter, DRI Development
Cc: linux-fbdev, linux-staging, kbuild-all, Xiyu Yang,
Jens Frederich, Tetsuo Handa, Daniel Vetter,
Intel Graphics Development, Zheyu Ma, LKML
Hi Daniel,
I love your patch! Yet something to improve:
[auto build test ERROR on tegra-drm/drm/tegra/for-next]
[also build test ERROR on drm/drm-next linus/master v5.17-rc2 next-20220131]
[cannot apply to airlied/drm-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url: https://github.com/0day-ci/linux/commits/Daniel-Vetter/some-fbcon-patches-mostly-locking/20220201-050907
base: git://anongit.freedesktop.org/tegra/linux.git drm/tegra/for-next
config: i386-allyesconfig (https://download.01.org/0day-ci/archive/20220201/202202011603.vczWPod7-lkp@intel.com/config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce (this is a W=1 build):
# https://github.com/0day-ci/linux/commit/245da5ab93b17c0cf1521713d5bde655a72efb65
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review Daniel-Vetter/some-fbcon-patches-mostly-locking/20220201-050907
git checkout 245da5ab93b17c0cf1521713d5bde655a72efb65
# save the config file to linux build tree
mkdir build_dir
make W=1 O=build_dir ARCH=i386 SHELL=/bin/bash
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
drivers/staging/olpc_dcon/olpc_dcon.c: In function 'dcon_probe':
>> drivers/staging/olpc_dcon/olpc_dcon.c:605:6: error: 'num_registered_fb' undeclared (first use in this function); did you mean 'WB_registered'?
605 | if (num_registered_fb < 1) {
| ^~~~~~~~~~~~~~~~~
| WB_registered
drivers/staging/olpc_dcon/olpc_dcon.c:605:6: note: each undeclared identifier is reported only once for each function it appears in
>> drivers/staging/olpc_dcon/olpc_dcon.c:610:17: error: 'registered_fb' undeclared (first use in this function)
610 | dcon->fbinfo = registered_fb[0];
| ^~~~~~~~~~~~~
vim +605 drivers/staging/olpc_dcon/olpc_dcon.c
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 584
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 585 static int dcon_probe(struct i2c_client *client, const struct i2c_device_id *id)
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 586 {
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 587 struct dcon_priv *dcon;
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 588 int rc, i, j;
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 589
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 590 if (!pdata)
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 591 return -ENXIO;
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 592
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 593 dcon = kzalloc(sizeof(*dcon), GFP_KERNEL);
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 594 if (!dcon)
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 595 return -ENOMEM;
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 596
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 597 dcon->client = client;
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 598 init_waitqueue_head(&dcon->waitq);
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 599 INIT_WORK(&dcon->switch_source, dcon_source_switch);
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 600 dcon->reboot_nb.notifier_call = dcon_reboot_notify;
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 601 dcon->reboot_nb.priority = -1;
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 602
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 603 i2c_set_clientdata(client, dcon);
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 604
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 @605 if (num_registered_fb < 1) {
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 606 dev_err(&client->dev, "DCON driver requires a registered fb\n");
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 607 rc = -EIO;
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 608 goto einit;
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 609 }
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 @610 dcon->fbinfo = registered_fb[0];
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 611
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 612 rc = dcon_hw_init(dcon, 1);
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 613 if (rc)
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 614 goto einit;
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 615
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 616 /* Add the DCON device */
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 617
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 618 dcon_device = platform_device_alloc("dcon", -1);
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 619
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 620 if (!dcon_device) {
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 621 pr_err("Unable to create the DCON device\n");
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 622 rc = -ENOMEM;
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 623 goto eirq;
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 624 }
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 625 rc = platform_device_add(dcon_device);
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 626 platform_set_drvdata(dcon_device, dcon);
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 627
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 628 if (rc) {
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 629 pr_err("Unable to add the DCON device\n");
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 630 goto edev;
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 631 }
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 632
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 633 for (i = 0; i < ARRAY_SIZE(dcon_device_files); i++) {
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 634 rc = device_create_file(&dcon_device->dev,
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 635 &dcon_device_files[i]);
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 636 if (rc) {
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 637 dev_err(&dcon_device->dev, "Cannot create sysfs file\n");
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 638 goto ecreate;
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 639 }
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 640 }
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 641
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 642 dcon->bl_val = dcon_read(dcon, DCON_REG_BRIGHT) & 0x0F;
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 643
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 644 /* Add the backlight device for the DCON */
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 645 dcon_bl_props.brightness = dcon->bl_val;
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 646 dcon->bl_dev = backlight_device_register("dcon-bl", &dcon_device->dev,
848d9eabcaebf21 Zebulon McCorkle 2017-11-21 647 dcon, &dcon_bl_ops,
848d9eabcaebf21 Zebulon McCorkle 2017-11-21 648 &dcon_bl_props);
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 649 if (IS_ERR(dcon->bl_dev)) {
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 650 dev_err(&client->dev, "cannot register backlight dev (%ld)\n",
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 651 PTR_ERR(dcon->bl_dev));
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 652 dcon->bl_dev = NULL;
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 653 }
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 654
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 655 register_reboot_notifier(&dcon->reboot_nb);
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 656 atomic_notifier_chain_register(&panic_notifier_list, &dcon_panic_nb);
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 657
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 658 return 0;
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 659
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 660 ecreate:
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 661 for (j = 0; j < i; j++)
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 662 device_remove_file(&dcon_device->dev, &dcon_device_files[j]);
4996b4610767064 Jing Xiangfeng 2020-11-20 663 platform_device_del(dcon_device);
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 664 edev:
4996b4610767064 Jing Xiangfeng 2020-11-20 665 platform_device_put(dcon_device);
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 666 dcon_device = NULL;
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 667 eirq:
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 668 free_irq(DCON_IRQ, dcon);
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 669 einit:
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 670 kfree(dcon);
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 671 return rc;
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 672 }
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 673
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [Intel-gfx] [PATCH 21/21] fbdev: Make registered_fb[] private to fbmem.c
@ 2022-02-01 8:13 ` kernel test robot
0 siblings, 0 replies; 241+ messages in thread
From: kernel test robot @ 2022-02-01 8:13 UTC (permalink / raw)
To: kbuild-all
[-- Attachment #1: Type: text/plain, Size: 9091 bytes --]
Hi Daniel,
I love your patch! Yet something to improve:
[auto build test ERROR on tegra-drm/drm/tegra/for-next]
[also build test ERROR on drm/drm-next linus/master v5.17-rc2 next-20220131]
[cannot apply to airlied/drm-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url: https://github.com/0day-ci/linux/commits/Daniel-Vetter/some-fbcon-patches-mostly-locking/20220201-050907
base: git://anongit.freedesktop.org/tegra/linux.git drm/tegra/for-next
config: i386-allyesconfig (https://download.01.org/0day-ci/archive/20220201/202202011603.vczWPod7-lkp(a)intel.com/config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce (this is a W=1 build):
# https://github.com/0day-ci/linux/commit/245da5ab93b17c0cf1521713d5bde655a72efb65
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review Daniel-Vetter/some-fbcon-patches-mostly-locking/20220201-050907
git checkout 245da5ab93b17c0cf1521713d5bde655a72efb65
# save the config file to linux build tree
mkdir build_dir
make W=1 O=build_dir ARCH=i386 SHELL=/bin/bash
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
drivers/staging/olpc_dcon/olpc_dcon.c: In function 'dcon_probe':
>> drivers/staging/olpc_dcon/olpc_dcon.c:605:6: error: 'num_registered_fb' undeclared (first use in this function); did you mean 'WB_registered'?
605 | if (num_registered_fb < 1) {
| ^~~~~~~~~~~~~~~~~
| WB_registered
drivers/staging/olpc_dcon/olpc_dcon.c:605:6: note: each undeclared identifier is reported only once for each function it appears in
>> drivers/staging/olpc_dcon/olpc_dcon.c:610:17: error: 'registered_fb' undeclared (first use in this function)
610 | dcon->fbinfo = registered_fb[0];
| ^~~~~~~~~~~~~
vim +605 drivers/staging/olpc_dcon/olpc_dcon.c
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 584
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 585 static int dcon_probe(struct i2c_client *client, const struct i2c_device_id *id)
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 586 {
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 587 struct dcon_priv *dcon;
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 588 int rc, i, j;
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 589
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 590 if (!pdata)
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 591 return -ENXIO;
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 592
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 593 dcon = kzalloc(sizeof(*dcon), GFP_KERNEL);
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 594 if (!dcon)
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 595 return -ENOMEM;
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 596
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 597 dcon->client = client;
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 598 init_waitqueue_head(&dcon->waitq);
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 599 INIT_WORK(&dcon->switch_source, dcon_source_switch);
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 600 dcon->reboot_nb.notifier_call = dcon_reboot_notify;
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 601 dcon->reboot_nb.priority = -1;
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 602
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 603 i2c_set_clientdata(client, dcon);
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 604
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 @605 if (num_registered_fb < 1) {
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 606 dev_err(&client->dev, "DCON driver requires a registered fb\n");
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 607 rc = -EIO;
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 608 goto einit;
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 609 }
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 @610 dcon->fbinfo = registered_fb[0];
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 611
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 612 rc = dcon_hw_init(dcon, 1);
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 613 if (rc)
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 614 goto einit;
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 615
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 616 /* Add the DCON device */
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 617
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 618 dcon_device = platform_device_alloc("dcon", -1);
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 619
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 620 if (!dcon_device) {
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 621 pr_err("Unable to create the DCON device\n");
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 622 rc = -ENOMEM;
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 623 goto eirq;
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 624 }
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 625 rc = platform_device_add(dcon_device);
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 626 platform_set_drvdata(dcon_device, dcon);
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 627
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 628 if (rc) {
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 629 pr_err("Unable to add the DCON device\n");
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 630 goto edev;
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 631 }
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 632
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 633 for (i = 0; i < ARRAY_SIZE(dcon_device_files); i++) {
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 634 rc = device_create_file(&dcon_device->dev,
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 635 &dcon_device_files[i]);
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 636 if (rc) {
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 637 dev_err(&dcon_device->dev, "Cannot create sysfs file\n");
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 638 goto ecreate;
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 639 }
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 640 }
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 641
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 642 dcon->bl_val = dcon_read(dcon, DCON_REG_BRIGHT) & 0x0F;
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 643
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 644 /* Add the backlight device for the DCON */
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 645 dcon_bl_props.brightness = dcon->bl_val;
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 646 dcon->bl_dev = backlight_device_register("dcon-bl", &dcon_device->dev,
848d9eabcaebf21 Zebulon McCorkle 2017-11-21 647 dcon, &dcon_bl_ops,
848d9eabcaebf21 Zebulon McCorkle 2017-11-21 648 &dcon_bl_props);
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 649 if (IS_ERR(dcon->bl_dev)) {
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 650 dev_err(&client->dev, "cannot register backlight dev (%ld)\n",
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 651 PTR_ERR(dcon->bl_dev));
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 652 dcon->bl_dev = NULL;
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 653 }
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 654
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 655 register_reboot_notifier(&dcon->reboot_nb);
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 656 atomic_notifier_chain_register(&panic_notifier_list, &dcon_panic_nb);
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 657
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 658 return 0;
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 659
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 660 ecreate:
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 661 for (j = 0; j < i; j++)
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 662 device_remove_file(&dcon_device->dev, &dcon_device_files[j]);
4996b4610767064 Jing Xiangfeng 2020-11-20 663 platform_device_del(dcon_device);
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 664 edev:
4996b4610767064 Jing Xiangfeng 2020-11-20 665 platform_device_put(dcon_device);
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 666 dcon_device = NULL;
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 667 eirq:
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 668 free_irq(DCON_IRQ, dcon);
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 669 einit:
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 670 kfree(dcon);
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 671 return rc;
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 672 }
53c43c5ca13328a Greg Kroah-Hartman 2016-04-04 673
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 03/21] fbcon: Restore fbcon scrolling acceleration
2022-01-31 21:05 ` Daniel Vetter
(?)
@ 2022-02-01 10:16 ` Helge Deller
-1 siblings, 0 replies; 241+ messages in thread
From: Helge Deller @ 2022-02-01 10:16 UTC (permalink / raw)
To: Daniel Vetter, DRI Development
Cc: Intel Graphics Development, linux-fbdev, LKML, stable,
Claudio Suarez, Dave Airlie, Jani Nikula, Linus Torvalds,
Pavel Machek, Sam Ravnborg, Greg Kroah-Hartman,
Javier Martinez Canillas, Tomi Valkeinen, Geert Uytterhoeven,
Thomas Zimmermann, Daniel Vetter, Sven Schnelle, Gerd Hoffmann
On 1/31/22 22:05, Daniel Vetter wrote:
> This functionally undoes 39aead8373b3 ("fbcon: Disable accelerated
> scrolling"), but behind the FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
> option.
you have two trivial copy-n-paste errors in this patch which still prevent the
console acceleration.
> diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
> index 2ff90061c7f3..39dc18a5de86 100644
> --- a/drivers/video/fbdev/core/fbcon.c
> +++ b/drivers/video/fbdev/core/fbcon.c
> @@ -1125,13 +1125,15 @@ static void fbcon_init(struct vc_data *vc, int init)
>
> ops->graphics = 0;
>
> - /*
> - * No more hw acceleration for fbcon.
> - *
> - * FIXME: Garbage collect all the now dead code after sufficient time
> - * has passed.
> - */
> +#ifdef CONFIG_FRAMEBUFFER_CONSOLE_ROTATION
should be:
#ifdef CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
> + if ((info->flags & FBINFO_HWACCEL_COPYAREA) &&
> + !(info->flags & FBINFO_HWACCEL_DISABLED))
> + p->scrollmode = SCROLL_MOVE;
> + else /* default to something safe */
> + p->scrollmode = SCROLL_REDRAW;
> +#else
> p->scrollmode = SCROLL_REDRAW;
> +#endif
>
> /*
> * ++guenther: console.c:vc_allocate() relies on initializing
> @@ -1971,15 +1973,49 @@ static void updatescrollmode(struct fbcon_display *p,
> {
> struct fbcon_ops *ops = info->fbcon_par;
> int fh = vc->vc_font.height;
> + int cap = info->flags;
> + u16 t = 0;
> + int ypan = FBCON_SWAP(ops->rotate, info->fix.ypanstep,
> + info->fix.xpanstep);
> + int ywrap = FBCON_SWAP(ops->rotate, info->fix.ywrapstep, t);
> int yres = FBCON_SWAP(ops->rotate, info->var.yres, info->var.xres);
> int vyres = FBCON_SWAP(ops->rotate, info->var.yres_virtual,
> info->var.xres_virtual);
> + int good_pan = (cap & FBINFO_HWACCEL_YPAN) &&
> + divides(ypan, vc->vc_font.height) && vyres > yres;
> + int good_wrap = (cap & FBINFO_HWACCEL_YWRAP) &&
> + divides(ywrap, vc->vc_font.height) &&
> + divides(vc->vc_font.height, vyres) &&
> + divides(vc->vc_font.height, yres);
> + int reading_fast = cap & FBINFO_READS_FAST;
> + int fast_copyarea = (cap & FBINFO_HWACCEL_COPYAREA) &&
> + !(cap & FBINFO_HWACCEL_DISABLED);
> + int fast_imageblit = (cap & FBINFO_HWACCEL_IMAGEBLIT) &&
> + !(cap & FBINFO_HWACCEL_DISABLED);
>
> p->vrows = vyres/fh;
> if (yres > (fh * (vc->vc_rows + 1)))
> p->vrows -= (yres - (fh * vc->vc_rows)) / fh;
> if ((yres % fh) && (vyres % fh < yres % fh))
> p->vrows--;
> +
> + if (good_wrap || good_pan) {
> + if (reading_fast || fast_copyarea)
> + p->scrollmode = good_wrap ?
> + SCROLL_WRAP_MOVE : SCROLL_PAN_MOVE;
> + else
> + p->scrollmode = good_wrap ? SCROLL_REDRAW :
> + SCROLL_PAN_REDRAW;
> + } else {
> + if (reading_fast || (fast_copyarea && !fast_imageblit))
> + p->scrollmode = SCROLL_MOVE;
> + else
> + p->scrollmode = SCROLL_REDRAW;
> + }
> +
> +#ifndef CONFIG_FRAMEBUFFER_CONSOLE_ROTATION
same here... it needs to be:
#ifdef CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
> + p->scrollmode = SCROLL_REDRAW;
> +#endif
> }
>
> #define PITCH(w) (((w) + 7) >> 3)
>
still reviewing the other patches...
Helge
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 03/21] fbcon: Restore fbcon scrolling acceleration
@ 2022-02-01 10:16 ` Helge Deller
0 siblings, 0 replies; 241+ messages in thread
From: Helge Deller @ 2022-02-01 10:16 UTC (permalink / raw)
To: Daniel Vetter, DRI Development
Cc: linux-fbdev, Thomas Zimmermann, Sam Ravnborg, Daniel Vetter,
Linus Torvalds, Intel Graphics Development, LKML, stable,
Javier Martinez Canillas, Tomi Valkeinen, Claudio Suarez,
Pavel Machek, Greg Kroah-Hartman, Geert Uytterhoeven,
Sven Schnelle, Gerd Hoffmann
On 1/31/22 22:05, Daniel Vetter wrote:
> This functionally undoes 39aead8373b3 ("fbcon: Disable accelerated
> scrolling"), but behind the FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
> option.
you have two trivial copy-n-paste errors in this patch which still prevent the
console acceleration.
> diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
> index 2ff90061c7f3..39dc18a5de86 100644
> --- a/drivers/video/fbdev/core/fbcon.c
> +++ b/drivers/video/fbdev/core/fbcon.c
> @@ -1125,13 +1125,15 @@ static void fbcon_init(struct vc_data *vc, int init)
>
> ops->graphics = 0;
>
> - /*
> - * No more hw acceleration for fbcon.
> - *
> - * FIXME: Garbage collect all the now dead code after sufficient time
> - * has passed.
> - */
> +#ifdef CONFIG_FRAMEBUFFER_CONSOLE_ROTATION
should be:
#ifdef CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
> + if ((info->flags & FBINFO_HWACCEL_COPYAREA) &&
> + !(info->flags & FBINFO_HWACCEL_DISABLED))
> + p->scrollmode = SCROLL_MOVE;
> + else /* default to something safe */
> + p->scrollmode = SCROLL_REDRAW;
> +#else
> p->scrollmode = SCROLL_REDRAW;
> +#endif
>
> /*
> * ++guenther: console.c:vc_allocate() relies on initializing
> @@ -1971,15 +1973,49 @@ static void updatescrollmode(struct fbcon_display *p,
> {
> struct fbcon_ops *ops = info->fbcon_par;
> int fh = vc->vc_font.height;
> + int cap = info->flags;
> + u16 t = 0;
> + int ypan = FBCON_SWAP(ops->rotate, info->fix.ypanstep,
> + info->fix.xpanstep);
> + int ywrap = FBCON_SWAP(ops->rotate, info->fix.ywrapstep, t);
> int yres = FBCON_SWAP(ops->rotate, info->var.yres, info->var.xres);
> int vyres = FBCON_SWAP(ops->rotate, info->var.yres_virtual,
> info->var.xres_virtual);
> + int good_pan = (cap & FBINFO_HWACCEL_YPAN) &&
> + divides(ypan, vc->vc_font.height) && vyres > yres;
> + int good_wrap = (cap & FBINFO_HWACCEL_YWRAP) &&
> + divides(ywrap, vc->vc_font.height) &&
> + divides(vc->vc_font.height, vyres) &&
> + divides(vc->vc_font.height, yres);
> + int reading_fast = cap & FBINFO_READS_FAST;
> + int fast_copyarea = (cap & FBINFO_HWACCEL_COPYAREA) &&
> + !(cap & FBINFO_HWACCEL_DISABLED);
> + int fast_imageblit = (cap & FBINFO_HWACCEL_IMAGEBLIT) &&
> + !(cap & FBINFO_HWACCEL_DISABLED);
>
> p->vrows = vyres/fh;
> if (yres > (fh * (vc->vc_rows + 1)))
> p->vrows -= (yres - (fh * vc->vc_rows)) / fh;
> if ((yres % fh) && (vyres % fh < yres % fh))
> p->vrows--;
> +
> + if (good_wrap || good_pan) {
> + if (reading_fast || fast_copyarea)
> + p->scrollmode = good_wrap ?
> + SCROLL_WRAP_MOVE : SCROLL_PAN_MOVE;
> + else
> + p->scrollmode = good_wrap ? SCROLL_REDRAW :
> + SCROLL_PAN_REDRAW;
> + } else {
> + if (reading_fast || (fast_copyarea && !fast_imageblit))
> + p->scrollmode = SCROLL_MOVE;
> + else
> + p->scrollmode = SCROLL_REDRAW;
> + }
> +
> +#ifndef CONFIG_FRAMEBUFFER_CONSOLE_ROTATION
same here... it needs to be:
#ifdef CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
> + p->scrollmode = SCROLL_REDRAW;
> +#endif
> }
>
> #define PITCH(w) (((w) + 7) >> 3)
>
still reviewing the other patches...
Helge
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [Intel-gfx] [PATCH 03/21] fbcon: Restore fbcon scrolling acceleration
@ 2022-02-01 10:16 ` Helge Deller
0 siblings, 0 replies; 241+ messages in thread
From: Helge Deller @ 2022-02-01 10:16 UTC (permalink / raw)
To: Daniel Vetter, DRI Development
Cc: linux-fbdev, Thomas Zimmermann, Sam Ravnborg, Daniel Vetter,
Linus Torvalds, Intel Graphics Development, LKML, stable,
Javier Martinez Canillas, Tomi Valkeinen, Pavel Machek,
Greg Kroah-Hartman, Geert Uytterhoeven, Dave Airlie,
Sven Schnelle, Gerd Hoffmann
On 1/31/22 22:05, Daniel Vetter wrote:
> This functionally undoes 39aead8373b3 ("fbcon: Disable accelerated
> scrolling"), but behind the FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
> option.
you have two trivial copy-n-paste errors in this patch which still prevent the
console acceleration.
> diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
> index 2ff90061c7f3..39dc18a5de86 100644
> --- a/drivers/video/fbdev/core/fbcon.c
> +++ b/drivers/video/fbdev/core/fbcon.c
> @@ -1125,13 +1125,15 @@ static void fbcon_init(struct vc_data *vc, int init)
>
> ops->graphics = 0;
>
> - /*
> - * No more hw acceleration for fbcon.
> - *
> - * FIXME: Garbage collect all the now dead code after sufficient time
> - * has passed.
> - */
> +#ifdef CONFIG_FRAMEBUFFER_CONSOLE_ROTATION
should be:
#ifdef CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
> + if ((info->flags & FBINFO_HWACCEL_COPYAREA) &&
> + !(info->flags & FBINFO_HWACCEL_DISABLED))
> + p->scrollmode = SCROLL_MOVE;
> + else /* default to something safe */
> + p->scrollmode = SCROLL_REDRAW;
> +#else
> p->scrollmode = SCROLL_REDRAW;
> +#endif
>
> /*
> * ++guenther: console.c:vc_allocate() relies on initializing
> @@ -1971,15 +1973,49 @@ static void updatescrollmode(struct fbcon_display *p,
> {
> struct fbcon_ops *ops = info->fbcon_par;
> int fh = vc->vc_font.height;
> + int cap = info->flags;
> + u16 t = 0;
> + int ypan = FBCON_SWAP(ops->rotate, info->fix.ypanstep,
> + info->fix.xpanstep);
> + int ywrap = FBCON_SWAP(ops->rotate, info->fix.ywrapstep, t);
> int yres = FBCON_SWAP(ops->rotate, info->var.yres, info->var.xres);
> int vyres = FBCON_SWAP(ops->rotate, info->var.yres_virtual,
> info->var.xres_virtual);
> + int good_pan = (cap & FBINFO_HWACCEL_YPAN) &&
> + divides(ypan, vc->vc_font.height) && vyres > yres;
> + int good_wrap = (cap & FBINFO_HWACCEL_YWRAP) &&
> + divides(ywrap, vc->vc_font.height) &&
> + divides(vc->vc_font.height, vyres) &&
> + divides(vc->vc_font.height, yres);
> + int reading_fast = cap & FBINFO_READS_FAST;
> + int fast_copyarea = (cap & FBINFO_HWACCEL_COPYAREA) &&
> + !(cap & FBINFO_HWACCEL_DISABLED);
> + int fast_imageblit = (cap & FBINFO_HWACCEL_IMAGEBLIT) &&
> + !(cap & FBINFO_HWACCEL_DISABLED);
>
> p->vrows = vyres/fh;
> if (yres > (fh * (vc->vc_rows + 1)))
> p->vrows -= (yres - (fh * vc->vc_rows)) / fh;
> if ((yres % fh) && (vyres % fh < yres % fh))
> p->vrows--;
> +
> + if (good_wrap || good_pan) {
> + if (reading_fast || fast_copyarea)
> + p->scrollmode = good_wrap ?
> + SCROLL_WRAP_MOVE : SCROLL_PAN_MOVE;
> + else
> + p->scrollmode = good_wrap ? SCROLL_REDRAW :
> + SCROLL_PAN_REDRAW;
> + } else {
> + if (reading_fast || (fast_copyarea && !fast_imageblit))
> + p->scrollmode = SCROLL_MOVE;
> + else
> + p->scrollmode = SCROLL_REDRAW;
> + }
> +
> +#ifndef CONFIG_FRAMEBUFFER_CONSOLE_ROTATION
same here... it needs to be:
#ifdef CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
> + p->scrollmode = SCROLL_REDRAW;
> +#endif
> }
>
> #define PITCH(w) (((w) + 7) >> 3)
>
still reviewing the other patches...
Helge
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 03/21] fbcon: Restore fbcon scrolling acceleration
2022-02-01 10:16 ` Helge Deller
(?)
@ 2022-02-01 10:17 ` Helge Deller
-1 siblings, 0 replies; 241+ messages in thread
From: Helge Deller @ 2022-02-01 10:17 UTC (permalink / raw)
To: Daniel Vetter, DRI Development
Cc: Intel Graphics Development, linux-fbdev, LKML, stable,
Claudio Suarez, Dave Airlie, Jani Nikula, Linus Torvalds,
Pavel Machek, Sam Ravnborg, Greg Kroah-Hartman,
Javier Martinez Canillas, Tomi Valkeinen, Geert Uytterhoeven,
Thomas Zimmermann, Daniel Vetter, Sven Schnelle, Gerd Hoffmann
On 2/1/22 11:16, Helge Deller wrote:
> On 1/31/22 22:05, Daniel Vetter wrote:
>> This functionally undoes 39aead8373b3 ("fbcon: Disable accelerated
>> scrolling"), but behind the FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
>> option.
>
> you have two trivial copy-n-paste errors in this patch which still prevent the
> console acceleration.
>
>> diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
>> index 2ff90061c7f3..39dc18a5de86 100644
>> --- a/drivers/video/fbdev/core/fbcon.c
>> +++ b/drivers/video/fbdev/core/fbcon.c
>> @@ -1125,13 +1125,15 @@ static void fbcon_init(struct vc_data *vc, int init)
>>
>> ops->graphics = 0;
>>
>> - /*
>> - * No more hw acceleration for fbcon.
>> - *
>> - * FIXME: Garbage collect all the now dead code after sufficient time
>> - * has passed.
>> - */
>> +#ifdef CONFIG_FRAMEBUFFER_CONSOLE_ROTATION
>
> should be:
> #ifdef CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
>
>
>> + if ((info->flags & FBINFO_HWACCEL_COPYAREA) &&
>> + !(info->flags & FBINFO_HWACCEL_DISABLED))
>> + p->scrollmode = SCROLL_MOVE;
>> + else /* default to something safe */
>> + p->scrollmode = SCROLL_REDRAW;
>> +#else
>> p->scrollmode = SCROLL_REDRAW;
>> +#endif
>>
>> /*
>> * ++guenther: console.c:vc_allocate() relies on initializing
>> @@ -1971,15 +1973,49 @@ static void updatescrollmode(struct fbcon_display *p,
>> {
>> struct fbcon_ops *ops = info->fbcon_par;
>> int fh = vc->vc_font.height;
>> + int cap = info->flags;
>> + u16 t = 0;
>> + int ypan = FBCON_SWAP(ops->rotate, info->fix.ypanstep,
>> + info->fix.xpanstep);
>> + int ywrap = FBCON_SWAP(ops->rotate, info->fix.ywrapstep, t);
>> int yres = FBCON_SWAP(ops->rotate, info->var.yres, info->var.xres);
>> int vyres = FBCON_SWAP(ops->rotate, info->var.yres_virtual,
>> info->var.xres_virtual);
>> + int good_pan = (cap & FBINFO_HWACCEL_YPAN) &&
>> + divides(ypan, vc->vc_font.height) && vyres > yres;
>> + int good_wrap = (cap & FBINFO_HWACCEL_YWRAP) &&
>> + divides(ywrap, vc->vc_font.height) &&
>> + divides(vc->vc_font.height, vyres) &&
>> + divides(vc->vc_font.height, yres);
>> + int reading_fast = cap & FBINFO_READS_FAST;
>> + int fast_copyarea = (cap & FBINFO_HWACCEL_COPYAREA) &&
>> + !(cap & FBINFO_HWACCEL_DISABLED);
>> + int fast_imageblit = (cap & FBINFO_HWACCEL_IMAGEBLIT) &&
>> + !(cap & FBINFO_HWACCEL_DISABLED);
>>
>> p->vrows = vyres/fh;
>> if (yres > (fh * (vc->vc_rows + 1)))
>> p->vrows -= (yres - (fh * vc->vc_rows)) / fh;
>> if ((yres % fh) && (vyres % fh < yres % fh))
>> p->vrows--;
>> +
>> + if (good_wrap || good_pan) {
>> + if (reading_fast || fast_copyarea)
>> + p->scrollmode = good_wrap ?
>> + SCROLL_WRAP_MOVE : SCROLL_PAN_MOVE;
>> + else
>> + p->scrollmode = good_wrap ? SCROLL_REDRAW :
>> + SCROLL_PAN_REDRAW;
>> + } else {
>> + if (reading_fast || (fast_copyarea && !fast_imageblit))
>> + p->scrollmode = SCROLL_MOVE;
>> + else
>> + p->scrollmode = SCROLL_REDRAW;
>> + }
>> +
>> +#ifndef CONFIG_FRAMEBUFFER_CONSOLE_ROTATION
>
> same here... it needs to be:
> #ifdef CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
actually:
#ifndef CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
>
>
>> + p->scrollmode = SCROLL_REDRAW;
>> +#endif
>> }
>>
>> #define PITCH(w) (((w) + 7) >> 3)
>>
>
> still reviewing the other patches...
>
> Helge
>
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 03/21] fbcon: Restore fbcon scrolling acceleration
@ 2022-02-01 10:17 ` Helge Deller
0 siblings, 0 replies; 241+ messages in thread
From: Helge Deller @ 2022-02-01 10:17 UTC (permalink / raw)
To: Daniel Vetter, DRI Development
Cc: linux-fbdev, Thomas Zimmermann, Sam Ravnborg, Daniel Vetter,
Linus Torvalds, Intel Graphics Development, LKML, stable,
Javier Martinez Canillas, Tomi Valkeinen, Claudio Suarez,
Pavel Machek, Greg Kroah-Hartman, Geert Uytterhoeven,
Sven Schnelle, Gerd Hoffmann
On 2/1/22 11:16, Helge Deller wrote:
> On 1/31/22 22:05, Daniel Vetter wrote:
>> This functionally undoes 39aead8373b3 ("fbcon: Disable accelerated
>> scrolling"), but behind the FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
>> option.
>
> you have two trivial copy-n-paste errors in this patch which still prevent the
> console acceleration.
>
>> diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
>> index 2ff90061c7f3..39dc18a5de86 100644
>> --- a/drivers/video/fbdev/core/fbcon.c
>> +++ b/drivers/video/fbdev/core/fbcon.c
>> @@ -1125,13 +1125,15 @@ static void fbcon_init(struct vc_data *vc, int init)
>>
>> ops->graphics = 0;
>>
>> - /*
>> - * No more hw acceleration for fbcon.
>> - *
>> - * FIXME: Garbage collect all the now dead code after sufficient time
>> - * has passed.
>> - */
>> +#ifdef CONFIG_FRAMEBUFFER_CONSOLE_ROTATION
>
> should be:
> #ifdef CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
>
>
>> + if ((info->flags & FBINFO_HWACCEL_COPYAREA) &&
>> + !(info->flags & FBINFO_HWACCEL_DISABLED))
>> + p->scrollmode = SCROLL_MOVE;
>> + else /* default to something safe */
>> + p->scrollmode = SCROLL_REDRAW;
>> +#else
>> p->scrollmode = SCROLL_REDRAW;
>> +#endif
>>
>> /*
>> * ++guenther: console.c:vc_allocate() relies on initializing
>> @@ -1971,15 +1973,49 @@ static void updatescrollmode(struct fbcon_display *p,
>> {
>> struct fbcon_ops *ops = info->fbcon_par;
>> int fh = vc->vc_font.height;
>> + int cap = info->flags;
>> + u16 t = 0;
>> + int ypan = FBCON_SWAP(ops->rotate, info->fix.ypanstep,
>> + info->fix.xpanstep);
>> + int ywrap = FBCON_SWAP(ops->rotate, info->fix.ywrapstep, t);
>> int yres = FBCON_SWAP(ops->rotate, info->var.yres, info->var.xres);
>> int vyres = FBCON_SWAP(ops->rotate, info->var.yres_virtual,
>> info->var.xres_virtual);
>> + int good_pan = (cap & FBINFO_HWACCEL_YPAN) &&
>> + divides(ypan, vc->vc_font.height) && vyres > yres;
>> + int good_wrap = (cap & FBINFO_HWACCEL_YWRAP) &&
>> + divides(ywrap, vc->vc_font.height) &&
>> + divides(vc->vc_font.height, vyres) &&
>> + divides(vc->vc_font.height, yres);
>> + int reading_fast = cap & FBINFO_READS_FAST;
>> + int fast_copyarea = (cap & FBINFO_HWACCEL_COPYAREA) &&
>> + !(cap & FBINFO_HWACCEL_DISABLED);
>> + int fast_imageblit = (cap & FBINFO_HWACCEL_IMAGEBLIT) &&
>> + !(cap & FBINFO_HWACCEL_DISABLED);
>>
>> p->vrows = vyres/fh;
>> if (yres > (fh * (vc->vc_rows + 1)))
>> p->vrows -= (yres - (fh * vc->vc_rows)) / fh;
>> if ((yres % fh) && (vyres % fh < yres % fh))
>> p->vrows--;
>> +
>> + if (good_wrap || good_pan) {
>> + if (reading_fast || fast_copyarea)
>> + p->scrollmode = good_wrap ?
>> + SCROLL_WRAP_MOVE : SCROLL_PAN_MOVE;
>> + else
>> + p->scrollmode = good_wrap ? SCROLL_REDRAW :
>> + SCROLL_PAN_REDRAW;
>> + } else {
>> + if (reading_fast || (fast_copyarea && !fast_imageblit))
>> + p->scrollmode = SCROLL_MOVE;
>> + else
>> + p->scrollmode = SCROLL_REDRAW;
>> + }
>> +
>> +#ifndef CONFIG_FRAMEBUFFER_CONSOLE_ROTATION
>
> same here... it needs to be:
> #ifdef CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
actually:
#ifndef CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
>
>
>> + p->scrollmode = SCROLL_REDRAW;
>> +#endif
>> }
>>
>> #define PITCH(w) (((w) + 7) >> 3)
>>
>
> still reviewing the other patches...
>
> Helge
>
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [Intel-gfx] [PATCH 03/21] fbcon: Restore fbcon scrolling acceleration
@ 2022-02-01 10:17 ` Helge Deller
0 siblings, 0 replies; 241+ messages in thread
From: Helge Deller @ 2022-02-01 10:17 UTC (permalink / raw)
To: Daniel Vetter, DRI Development
Cc: linux-fbdev, Thomas Zimmermann, Sam Ravnborg, Daniel Vetter,
Linus Torvalds, Intel Graphics Development, LKML, stable,
Javier Martinez Canillas, Tomi Valkeinen, Pavel Machek,
Greg Kroah-Hartman, Geert Uytterhoeven, Dave Airlie,
Sven Schnelle, Gerd Hoffmann
On 2/1/22 11:16, Helge Deller wrote:
> On 1/31/22 22:05, Daniel Vetter wrote:
>> This functionally undoes 39aead8373b3 ("fbcon: Disable accelerated
>> scrolling"), but behind the FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
>> option.
>
> you have two trivial copy-n-paste errors in this patch which still prevent the
> console acceleration.
>
>> diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
>> index 2ff90061c7f3..39dc18a5de86 100644
>> --- a/drivers/video/fbdev/core/fbcon.c
>> +++ b/drivers/video/fbdev/core/fbcon.c
>> @@ -1125,13 +1125,15 @@ static void fbcon_init(struct vc_data *vc, int init)
>>
>> ops->graphics = 0;
>>
>> - /*
>> - * No more hw acceleration for fbcon.
>> - *
>> - * FIXME: Garbage collect all the now dead code after sufficient time
>> - * has passed.
>> - */
>> +#ifdef CONFIG_FRAMEBUFFER_CONSOLE_ROTATION
>
> should be:
> #ifdef CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
>
>
>> + if ((info->flags & FBINFO_HWACCEL_COPYAREA) &&
>> + !(info->flags & FBINFO_HWACCEL_DISABLED))
>> + p->scrollmode = SCROLL_MOVE;
>> + else /* default to something safe */
>> + p->scrollmode = SCROLL_REDRAW;
>> +#else
>> p->scrollmode = SCROLL_REDRAW;
>> +#endif
>>
>> /*
>> * ++guenther: console.c:vc_allocate() relies on initializing
>> @@ -1971,15 +1973,49 @@ static void updatescrollmode(struct fbcon_display *p,
>> {
>> struct fbcon_ops *ops = info->fbcon_par;
>> int fh = vc->vc_font.height;
>> + int cap = info->flags;
>> + u16 t = 0;
>> + int ypan = FBCON_SWAP(ops->rotate, info->fix.ypanstep,
>> + info->fix.xpanstep);
>> + int ywrap = FBCON_SWAP(ops->rotate, info->fix.ywrapstep, t);
>> int yres = FBCON_SWAP(ops->rotate, info->var.yres, info->var.xres);
>> int vyres = FBCON_SWAP(ops->rotate, info->var.yres_virtual,
>> info->var.xres_virtual);
>> + int good_pan = (cap & FBINFO_HWACCEL_YPAN) &&
>> + divides(ypan, vc->vc_font.height) && vyres > yres;
>> + int good_wrap = (cap & FBINFO_HWACCEL_YWRAP) &&
>> + divides(ywrap, vc->vc_font.height) &&
>> + divides(vc->vc_font.height, vyres) &&
>> + divides(vc->vc_font.height, yres);
>> + int reading_fast = cap & FBINFO_READS_FAST;
>> + int fast_copyarea = (cap & FBINFO_HWACCEL_COPYAREA) &&
>> + !(cap & FBINFO_HWACCEL_DISABLED);
>> + int fast_imageblit = (cap & FBINFO_HWACCEL_IMAGEBLIT) &&
>> + !(cap & FBINFO_HWACCEL_DISABLED);
>>
>> p->vrows = vyres/fh;
>> if (yres > (fh * (vc->vc_rows + 1)))
>> p->vrows -= (yres - (fh * vc->vc_rows)) / fh;
>> if ((yres % fh) && (vyres % fh < yres % fh))
>> p->vrows--;
>> +
>> + if (good_wrap || good_pan) {
>> + if (reading_fast || fast_copyarea)
>> + p->scrollmode = good_wrap ?
>> + SCROLL_WRAP_MOVE : SCROLL_PAN_MOVE;
>> + else
>> + p->scrollmode = good_wrap ? SCROLL_REDRAW :
>> + SCROLL_PAN_REDRAW;
>> + } else {
>> + if (reading_fast || (fast_copyarea && !fast_imageblit))
>> + p->scrollmode = SCROLL_MOVE;
>> + else
>> + p->scrollmode = SCROLL_REDRAW;
>> + }
>> +
>> +#ifndef CONFIG_FRAMEBUFFER_CONSOLE_ROTATION
>
> same here... it needs to be:
> #ifdef CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
actually:
#ifndef CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
>
>
>> + p->scrollmode = SCROLL_REDRAW;
>> +#endif
>> }
>>
>> #define PITCH(w) (((w) + 7) >> 3)
>>
>
> still reviewing the other patches...
>
> Helge
>
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 01/21] MAINTAINERS: Add entry for fbdev core
2022-01-31 21:05 ` Daniel Vetter
(?)
@ 2022-02-01 10:19 ` Thomas Zimmermann
-1 siblings, 0 replies; 241+ messages in thread
From: Thomas Zimmermann @ 2022-02-01 10:19 UTC (permalink / raw)
To: Daniel Vetter, DRI Development
Cc: linux-fbdev, Sam Ravnborg, Daniel Vetter,
Intel Graphics Development, LKML, Javier Martinez Canillas,
Linus Torvalds, Tomi Valkeinen, Claudio Suarez, Gerd Hoffmann,
Pavel Machek, Greg Kroah-Hartman, Geert Uytterhoeven,
Sven Schnelle
[-- Attachment #1.1: Type: text/plain, Size: 3176 bytes --]
Am 31.01.22 um 22:05 schrieb Daniel Vetter:
> Ever since Tomi extracted the core code in 2014 it's been defacto me
> maintaining this, with help from others from dri-devel and sometimes
> Linus (but those are mostly merge conflicts):
>
> $ git shortlog -ns drivers/video/fbdev/core/ | head -n5
> 35 Daniel Vetter
> 23 Linus Torvalds
> 10 Hans de Goede
> 9 Dave Airlie
> 6 Peter Rosin
>
> I think ideally we'd also record that the various firmware fb drivers
> (efifb, vesafb, ...) are also maintained in drm-misc because for the
> past few years the patches have either been to fix handover issues
> with drm drivers, or caused handover issues with drm drivers. So any
> other tree just doesn't make sense. But also, there's plenty of
> outdated MAINTAINER entries for these with people and git trees that
> haven't been active in years, so maybe let's just leave them alone.
> And furthermore distros are now adopting simpledrm as the firmware fb
> driver, so hopefully the need to care about the fbdev firmware drivers
> will go down going forward.
>
> Note that drm-misc is group maintained, I expect that to continue like
> we've done before, so no new expectations that patches all go through
> my hands. That would be silly. This also means I'm happy to put any
> other volunteer's name in the M: line, but otherwise git log says I'm
> the one who's stuck with this.
>
> Cc: Dave Airlie <airlied@gmail.com>
> Cc: Jani Nikula <jani.nikula@linux.intel.com>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: Linux Fbdev development list <linux-fbdev@vger.kernel.org>
> Cc: Pavel Machek <pavel@ucw.cz>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Javier Martinez Canillas <javierm@redhat.com>
> Cc: DRI Development <dri-devel@lists.freedesktop.org>
> Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
> Cc: Claudio Suarez <cssk@net-c.es>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Cc: Geert Uytterhoeven <geert@linux-m68k.org>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Sven Schnelle <svens@stackframe.org>
> Cc: Gerd Hoffmann <kraxel@redhat.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
> ---
> MAINTAINERS | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index ea3e6c914384..49809eaa3096 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -7573,6 +7573,12 @@ S: Maintained
> W: http://floatingpoint.sourceforge.net/emulator/index.html
> F: arch/x86/math-emu/
>
> +FRAMEBUFFER CORE
> +M: Daniel Vetter <daniel@ffwll.ch>
> +F: drivers/video/fbdev/core/
> +S: Odd Fixes
> +T: git git://anongit.freedesktop.org/drm/drm-misc
> +
> FRAMEBUFFER LAYER
> M: Helge Deller <deller@gmx.de>
> L: linux-fbdev@vger.kernel.org
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 01/21] MAINTAINERS: Add entry for fbdev core
@ 2022-02-01 10:19 ` Thomas Zimmermann
0 siblings, 0 replies; 241+ messages in thread
From: Thomas Zimmermann @ 2022-02-01 10:19 UTC (permalink / raw)
To: Daniel Vetter, DRI Development
Cc: linux-fbdev, Sven Schnelle, Linus Torvalds,
Intel Graphics Development, Javier Martinez Canillas,
Geert Uytterhoeven, LKML, Tomi Valkeinen, Claudio Suarez,
Gerd Hoffmann, Pavel Machek, Greg Kroah-Hartman, Daniel Vetter,
Sam Ravnborg
[-- Attachment #1.1: Type: text/plain, Size: 3176 bytes --]
Am 31.01.22 um 22:05 schrieb Daniel Vetter:
> Ever since Tomi extracted the core code in 2014 it's been defacto me
> maintaining this, with help from others from dri-devel and sometimes
> Linus (but those are mostly merge conflicts):
>
> $ git shortlog -ns drivers/video/fbdev/core/ | head -n5
> 35 Daniel Vetter
> 23 Linus Torvalds
> 10 Hans de Goede
> 9 Dave Airlie
> 6 Peter Rosin
>
> I think ideally we'd also record that the various firmware fb drivers
> (efifb, vesafb, ...) are also maintained in drm-misc because for the
> past few years the patches have either been to fix handover issues
> with drm drivers, or caused handover issues with drm drivers. So any
> other tree just doesn't make sense. But also, there's plenty of
> outdated MAINTAINER entries for these with people and git trees that
> haven't been active in years, so maybe let's just leave them alone.
> And furthermore distros are now adopting simpledrm as the firmware fb
> driver, so hopefully the need to care about the fbdev firmware drivers
> will go down going forward.
>
> Note that drm-misc is group maintained, I expect that to continue like
> we've done before, so no new expectations that patches all go through
> my hands. That would be silly. This also means I'm happy to put any
> other volunteer's name in the M: line, but otherwise git log says I'm
> the one who's stuck with this.
>
> Cc: Dave Airlie <airlied@gmail.com>
> Cc: Jani Nikula <jani.nikula@linux.intel.com>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: Linux Fbdev development list <linux-fbdev@vger.kernel.org>
> Cc: Pavel Machek <pavel@ucw.cz>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Javier Martinez Canillas <javierm@redhat.com>
> Cc: DRI Development <dri-devel@lists.freedesktop.org>
> Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
> Cc: Claudio Suarez <cssk@net-c.es>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Cc: Geert Uytterhoeven <geert@linux-m68k.org>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Sven Schnelle <svens@stackframe.org>
> Cc: Gerd Hoffmann <kraxel@redhat.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
> ---
> MAINTAINERS | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index ea3e6c914384..49809eaa3096 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -7573,6 +7573,12 @@ S: Maintained
> W: http://floatingpoint.sourceforge.net/emulator/index.html
> F: arch/x86/math-emu/
>
> +FRAMEBUFFER CORE
> +M: Daniel Vetter <daniel@ffwll.ch>
> +F: drivers/video/fbdev/core/
> +S: Odd Fixes
> +T: git git://anongit.freedesktop.org/drm/drm-misc
> +
> FRAMEBUFFER LAYER
> M: Helge Deller <deller@gmx.de>
> L: linux-fbdev@vger.kernel.org
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [Intel-gfx] [PATCH 01/21] MAINTAINERS: Add entry for fbdev core
@ 2022-02-01 10:19 ` Thomas Zimmermann
0 siblings, 0 replies; 241+ messages in thread
From: Thomas Zimmermann @ 2022-02-01 10:19 UTC (permalink / raw)
To: Daniel Vetter, DRI Development
Cc: linux-fbdev, Sven Schnelle, Linus Torvalds,
Intel Graphics Development, Javier Martinez Canillas,
Geert Uytterhoeven, LKML, Tomi Valkeinen, Gerd Hoffmann,
Pavel Machek, Greg Kroah-Hartman, Daniel Vetter, Sam Ravnborg
[-- Attachment #1.1: Type: text/plain, Size: 3176 bytes --]
Am 31.01.22 um 22:05 schrieb Daniel Vetter:
> Ever since Tomi extracted the core code in 2014 it's been defacto me
> maintaining this, with help from others from dri-devel and sometimes
> Linus (but those are mostly merge conflicts):
>
> $ git shortlog -ns drivers/video/fbdev/core/ | head -n5
> 35 Daniel Vetter
> 23 Linus Torvalds
> 10 Hans de Goede
> 9 Dave Airlie
> 6 Peter Rosin
>
> I think ideally we'd also record that the various firmware fb drivers
> (efifb, vesafb, ...) are also maintained in drm-misc because for the
> past few years the patches have either been to fix handover issues
> with drm drivers, or caused handover issues with drm drivers. So any
> other tree just doesn't make sense. But also, there's plenty of
> outdated MAINTAINER entries for these with people and git trees that
> haven't been active in years, so maybe let's just leave them alone.
> And furthermore distros are now adopting simpledrm as the firmware fb
> driver, so hopefully the need to care about the fbdev firmware drivers
> will go down going forward.
>
> Note that drm-misc is group maintained, I expect that to continue like
> we've done before, so no new expectations that patches all go through
> my hands. That would be silly. This also means I'm happy to put any
> other volunteer's name in the M: line, but otherwise git log says I'm
> the one who's stuck with this.
>
> Cc: Dave Airlie <airlied@gmail.com>
> Cc: Jani Nikula <jani.nikula@linux.intel.com>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: Linux Fbdev development list <linux-fbdev@vger.kernel.org>
> Cc: Pavel Machek <pavel@ucw.cz>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Javier Martinez Canillas <javierm@redhat.com>
> Cc: DRI Development <dri-devel@lists.freedesktop.org>
> Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
> Cc: Claudio Suarez <cssk@net-c.es>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Cc: Geert Uytterhoeven <geert@linux-m68k.org>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Sven Schnelle <svens@stackframe.org>
> Cc: Gerd Hoffmann <kraxel@redhat.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
> ---
> MAINTAINERS | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index ea3e6c914384..49809eaa3096 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -7573,6 +7573,12 @@ S: Maintained
> W: http://floatingpoint.sourceforge.net/emulator/index.html
> F: arch/x86/math-emu/
>
> +FRAMEBUFFER CORE
> +M: Daniel Vetter <daniel@ffwll.ch>
> +F: drivers/video/fbdev/core/
> +S: Odd Fixes
> +T: git git://anongit.freedesktop.org/drm/drm-misc
> +
> FRAMEBUFFER LAYER
> M: Helge Deller <deller@gmx.de>
> L: linux-fbdev@vger.kernel.org
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 01/21] MAINTAINERS: Add entry for fbdev core
2022-01-31 21:05 ` Daniel Vetter
(?)
@ 2022-02-01 10:32 ` Helge Deller
-1 siblings, 0 replies; 241+ messages in thread
From: Helge Deller @ 2022-02-01 10:32 UTC (permalink / raw)
To: Daniel Vetter, DRI Development
Cc: Intel Graphics Development, linux-fbdev, LKML, Dave Airlie,
Jani Nikula, Linus Torvalds, Pavel Machek, Sam Ravnborg,
Greg Kroah-Hartman, Javier Martinez Canillas, Claudio Suarez,
Tomi Valkeinen, Geert Uytterhoeven, Thomas Zimmermann,
Daniel Vetter, Sven Schnelle, Gerd Hoffmann
On 1/31/22 22:05, Daniel Vetter wrote:
> Ever since Tomi extracted the core code in 2014 it's been defacto me
> maintaining this, with help from others from dri-devel and sometimes
> Linus (but those are mostly merge conflicts):
>
> $ git shortlog -ns drivers/video/fbdev/core/ | head -n5
> 35 Daniel Vetter
> 23 Linus Torvalds
> 10 Hans de Goede
> 9 Dave Airlie
> 6 Peter Rosin
>
> I think ideally we'd also record that the various firmware fb drivers
> (efifb, vesafb, ...) are also maintained in drm-misc because for the
> past few years the patches have either been to fix handover issues
> with drm drivers, or caused handover issues with drm drivers. So any
> other tree just doesn't make sense. But also, there's plenty of
> outdated MAINTAINER entries for these with people and git trees that
> haven't been active in years, so maybe let's just leave them alone.
> And furthermore distros are now adopting simpledrm as the firmware fb
> driver, so hopefully the need to care about the fbdev firmware drivers
> will go down going forward.
>
> Note that drm-misc is group maintained, I expect that to continue like
> we've done before, so no new expectations that patches all go through
> my hands. That would be silly. This also means I'm happy to put any
> other volunteer's name in the M: line, but otherwise git log says I'm
> the one who's stuck with this.
Yes, agreed.
Acked-by: Helge Deller <deller@gmx.de>
Since the code is used by drm and existing fbdev drivers,
please just make sure to not break fbdev...
Thanks!
Helge
>
> Cc: Dave Airlie <airlied@gmail.com>
> Cc: Jani Nikula <jani.nikula@linux.intel.com>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: Linux Fbdev development list <linux-fbdev@vger.kernel.org>
> Cc: Pavel Machek <pavel@ucw.cz>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Javier Martinez Canillas <javierm@redhat.com>
> Cc: DRI Development <dri-devel@lists.freedesktop.org>
> Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
> Cc: Claudio Suarez <cssk@net-c.es>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Cc: Geert Uytterhoeven <geert@linux-m68k.org>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Sven Schnelle <svens@stackframe.org>
> Cc: Gerd Hoffmann <kraxel@redhat.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> ---
> MAINTAINERS | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index ea3e6c914384..49809eaa3096 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -7573,6 +7573,12 @@ S: Maintained
> W: http://floatingpoint.sourceforge.net/emulator/index.html
> F: arch/x86/math-emu/
>
> +FRAMEBUFFER CORE
> +M: Daniel Vetter <daniel@ffwll.ch>
> +F: drivers/video/fbdev/core/
> +S: Odd Fixes
> +T: git git://anongit.freedesktop.org/drm/drm-misc
> +
> FRAMEBUFFER LAYER
> M: Helge Deller <deller@gmx.de>
> L: linux-fbdev@vger.kernel.org
>
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 01/21] MAINTAINERS: Add entry for fbdev core
@ 2022-02-01 10:32 ` Helge Deller
0 siblings, 0 replies; 241+ messages in thread
From: Helge Deller @ 2022-02-01 10:32 UTC (permalink / raw)
To: Daniel Vetter, DRI Development
Cc: linux-fbdev, Thomas Zimmermann, Sam Ravnborg, Daniel Vetter,
Intel Graphics Development, LKML, Javier Martinez Canillas,
Tomi Valkeinen, Claudio Suarez, Gerd Hoffmann, Pavel Machek,
Greg Kroah-Hartman, Geert Uytterhoeven, Linus Torvalds,
Sven Schnelle
On 1/31/22 22:05, Daniel Vetter wrote:
> Ever since Tomi extracted the core code in 2014 it's been defacto me
> maintaining this, with help from others from dri-devel and sometimes
> Linus (but those are mostly merge conflicts):
>
> $ git shortlog -ns drivers/video/fbdev/core/ | head -n5
> 35 Daniel Vetter
> 23 Linus Torvalds
> 10 Hans de Goede
> 9 Dave Airlie
> 6 Peter Rosin
>
> I think ideally we'd also record that the various firmware fb drivers
> (efifb, vesafb, ...) are also maintained in drm-misc because for the
> past few years the patches have either been to fix handover issues
> with drm drivers, or caused handover issues with drm drivers. So any
> other tree just doesn't make sense. But also, there's plenty of
> outdated MAINTAINER entries for these with people and git trees that
> haven't been active in years, so maybe let's just leave them alone.
> And furthermore distros are now adopting simpledrm as the firmware fb
> driver, so hopefully the need to care about the fbdev firmware drivers
> will go down going forward.
>
> Note that drm-misc is group maintained, I expect that to continue like
> we've done before, so no new expectations that patches all go through
> my hands. That would be silly. This also means I'm happy to put any
> other volunteer's name in the M: line, but otherwise git log says I'm
> the one who's stuck with this.
Yes, agreed.
Acked-by: Helge Deller <deller@gmx.de>
Since the code is used by drm and existing fbdev drivers,
please just make sure to not break fbdev...
Thanks!
Helge
>
> Cc: Dave Airlie <airlied@gmail.com>
> Cc: Jani Nikula <jani.nikula@linux.intel.com>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: Linux Fbdev development list <linux-fbdev@vger.kernel.org>
> Cc: Pavel Machek <pavel@ucw.cz>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Javier Martinez Canillas <javierm@redhat.com>
> Cc: DRI Development <dri-devel@lists.freedesktop.org>
> Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
> Cc: Claudio Suarez <cssk@net-c.es>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Cc: Geert Uytterhoeven <geert@linux-m68k.org>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Sven Schnelle <svens@stackframe.org>
> Cc: Gerd Hoffmann <kraxel@redhat.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> ---
> MAINTAINERS | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index ea3e6c914384..49809eaa3096 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -7573,6 +7573,12 @@ S: Maintained
> W: http://floatingpoint.sourceforge.net/emulator/index.html
> F: arch/x86/math-emu/
>
> +FRAMEBUFFER CORE
> +M: Daniel Vetter <daniel@ffwll.ch>
> +F: drivers/video/fbdev/core/
> +S: Odd Fixes
> +T: git git://anongit.freedesktop.org/drm/drm-misc
> +
> FRAMEBUFFER LAYER
> M: Helge Deller <deller@gmx.de>
> L: linux-fbdev@vger.kernel.org
>
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [Intel-gfx] [PATCH 01/21] MAINTAINERS: Add entry for fbdev core
@ 2022-02-01 10:32 ` Helge Deller
0 siblings, 0 replies; 241+ messages in thread
From: Helge Deller @ 2022-02-01 10:32 UTC (permalink / raw)
To: Daniel Vetter, DRI Development
Cc: linux-fbdev, Thomas Zimmermann, Sam Ravnborg, Daniel Vetter,
Dave Airlie, Intel Graphics Development, LKML,
Javier Martinez Canillas, Tomi Valkeinen, Gerd Hoffmann,
Pavel Machek, Greg Kroah-Hartman, Geert Uytterhoeven,
Linus Torvalds, Sven Schnelle
On 1/31/22 22:05, Daniel Vetter wrote:
> Ever since Tomi extracted the core code in 2014 it's been defacto me
> maintaining this, with help from others from dri-devel and sometimes
> Linus (but those are mostly merge conflicts):
>
> $ git shortlog -ns drivers/video/fbdev/core/ | head -n5
> 35 Daniel Vetter
> 23 Linus Torvalds
> 10 Hans de Goede
> 9 Dave Airlie
> 6 Peter Rosin
>
> I think ideally we'd also record that the various firmware fb drivers
> (efifb, vesafb, ...) are also maintained in drm-misc because for the
> past few years the patches have either been to fix handover issues
> with drm drivers, or caused handover issues with drm drivers. So any
> other tree just doesn't make sense. But also, there's plenty of
> outdated MAINTAINER entries for these with people and git trees that
> haven't been active in years, so maybe let's just leave them alone.
> And furthermore distros are now adopting simpledrm as the firmware fb
> driver, so hopefully the need to care about the fbdev firmware drivers
> will go down going forward.
>
> Note that drm-misc is group maintained, I expect that to continue like
> we've done before, so no new expectations that patches all go through
> my hands. That would be silly. This also means I'm happy to put any
> other volunteer's name in the M: line, but otherwise git log says I'm
> the one who's stuck with this.
Yes, agreed.
Acked-by: Helge Deller <deller@gmx.de>
Since the code is used by drm and existing fbdev drivers,
please just make sure to not break fbdev...
Thanks!
Helge
>
> Cc: Dave Airlie <airlied@gmail.com>
> Cc: Jani Nikula <jani.nikula@linux.intel.com>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: Linux Fbdev development list <linux-fbdev@vger.kernel.org>
> Cc: Pavel Machek <pavel@ucw.cz>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Javier Martinez Canillas <javierm@redhat.com>
> Cc: DRI Development <dri-devel@lists.freedesktop.org>
> Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
> Cc: Claudio Suarez <cssk@net-c.es>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Cc: Geert Uytterhoeven <geert@linux-m68k.org>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Sven Schnelle <svens@stackframe.org>
> Cc: Gerd Hoffmann <kraxel@redhat.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> ---
> MAINTAINERS | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index ea3e6c914384..49809eaa3096 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -7573,6 +7573,12 @@ S: Maintained
> W: http://floatingpoint.sourceforge.net/emulator/index.html
> F: arch/x86/math-emu/
>
> +FRAMEBUFFER CORE
> +M: Daniel Vetter <daniel@ffwll.ch>
> +F: drivers/video/fbdev/core/
> +S: Odd Fixes
> +T: git git://anongit.freedesktop.org/drm/drm-misc
> +
> FRAMEBUFFER LAYER
> M: Helge Deller <deller@gmx.de>
> L: linux-fbdev@vger.kernel.org
>
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 03/21] fbcon: Restore fbcon scrolling acceleration
2022-02-01 10:16 ` Helge Deller
(?)
@ 2022-02-01 10:36 ` Daniel Vetter
-1 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-02-01 10:36 UTC (permalink / raw)
To: Helge Deller
Cc: DRI Development, Intel Graphics Development, linux-fbdev, LKML,
stable, Claudio Suarez, Dave Airlie, Jani Nikula, Linus Torvalds,
Pavel Machek, Sam Ravnborg, Greg Kroah-Hartman,
Javier Martinez Canillas, Tomi Valkeinen, Geert Uytterhoeven,
Thomas Zimmermann, Daniel Vetter, Sven Schnelle, Gerd Hoffmann
On Tue, Feb 1, 2022 at 11:16 AM Helge Deller <deller@gmx.de> wrote:
>
> On 1/31/22 22:05, Daniel Vetter wrote:
> > This functionally undoes 39aead8373b3 ("fbcon: Disable accelerated
> > scrolling"), but behind the FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
> > option.
>
> you have two trivial copy-n-paste errors in this patch which still prevent the
> console acceleration.
Duh :-(
But before we dig into details I think the big picture would be
better. I honestly don't like the #ifdef pile here that much. I wonder
whether your approach, also with GETVX/YRES adjusted somehow, wouldn't
look cleaner? Like I said in the cover letter I got mostly distracted
with fbcon locking last week, not really with this one here at all, so
maybe going with your 4 (or 2 if we squash them like I did here)
patches is neater?
Cheers, Daniel
>
> > diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
> > index 2ff90061c7f3..39dc18a5de86 100644
> > --- a/drivers/video/fbdev/core/fbcon.c
> > +++ b/drivers/video/fbdev/core/fbcon.c
> > @@ -1125,13 +1125,15 @@ static void fbcon_init(struct vc_data *vc, int init)
> >
> > ops->graphics = 0;
> >
> > - /*
> > - * No more hw acceleration for fbcon.
> > - *
> > - * FIXME: Garbage collect all the now dead code after sufficient time
> > - * has passed.
> > - */
> > +#ifdef CONFIG_FRAMEBUFFER_CONSOLE_ROTATION
>
> should be:
> #ifdef CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
>
>
> > + if ((info->flags & FBINFO_HWACCEL_COPYAREA) &&
> > + !(info->flags & FBINFO_HWACCEL_DISABLED))
> > + p->scrollmode = SCROLL_MOVE;
> > + else /* default to something safe */
> > + p->scrollmode = SCROLL_REDRAW;
> > +#else
> > p->scrollmode = SCROLL_REDRAW;
> > +#endif
> >
> > /*
> > * ++guenther: console.c:vc_allocate() relies on initializing
> > @@ -1971,15 +1973,49 @@ static void updatescrollmode(struct fbcon_display *p,
> > {
> > struct fbcon_ops *ops = info->fbcon_par;
> > int fh = vc->vc_font.height;
> > + int cap = info->flags;
> > + u16 t = 0;
> > + int ypan = FBCON_SWAP(ops->rotate, info->fix.ypanstep,
> > + info->fix.xpanstep);
> > + int ywrap = FBCON_SWAP(ops->rotate, info->fix.ywrapstep, t);
> > int yres = FBCON_SWAP(ops->rotate, info->var.yres, info->var.xres);
> > int vyres = FBCON_SWAP(ops->rotate, info->var.yres_virtual,
> > info->var.xres_virtual);
> > + int good_pan = (cap & FBINFO_HWACCEL_YPAN) &&
> > + divides(ypan, vc->vc_font.height) && vyres > yres;
> > + int good_wrap = (cap & FBINFO_HWACCEL_YWRAP) &&
> > + divides(ywrap, vc->vc_font.height) &&
> > + divides(vc->vc_font.height, vyres) &&
> > + divides(vc->vc_font.height, yres);
> > + int reading_fast = cap & FBINFO_READS_FAST;
> > + int fast_copyarea = (cap & FBINFO_HWACCEL_COPYAREA) &&
> > + !(cap & FBINFO_HWACCEL_DISABLED);
> > + int fast_imageblit = (cap & FBINFO_HWACCEL_IMAGEBLIT) &&
> > + !(cap & FBINFO_HWACCEL_DISABLED);
> >
> > p->vrows = vyres/fh;
> > if (yres > (fh * (vc->vc_rows + 1)))
> > p->vrows -= (yres - (fh * vc->vc_rows)) / fh;
> > if ((yres % fh) && (vyres % fh < yres % fh))
> > p->vrows--;
> > +
> > + if (good_wrap || good_pan) {
> > + if (reading_fast || fast_copyarea)
> > + p->scrollmode = good_wrap ?
> > + SCROLL_WRAP_MOVE : SCROLL_PAN_MOVE;
> > + else
> > + p->scrollmode = good_wrap ? SCROLL_REDRAW :
> > + SCROLL_PAN_REDRAW;
> > + } else {
> > + if (reading_fast || (fast_copyarea && !fast_imageblit))
> > + p->scrollmode = SCROLL_MOVE;
> > + else
> > + p->scrollmode = SCROLL_REDRAW;
> > + }
> > +
> > +#ifndef CONFIG_FRAMEBUFFER_CONSOLE_ROTATION
>
> same here... it needs to be:
> #ifdef CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
>
>
> > + p->scrollmode = SCROLL_REDRAW;
> > +#endif
> > }
> >
> > #define PITCH(w) (((w) + 7) >> 3)
> >
>
> still reviewing the other patches...
>
> Helge
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 03/21] fbcon: Restore fbcon scrolling acceleration
@ 2022-02-01 10:36 ` Daniel Vetter
0 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-02-01 10:36 UTC (permalink / raw)
To: Helge Deller
Cc: linux-fbdev, Thomas Zimmermann, Sam Ravnborg, Daniel Vetter,
Linus Torvalds, Intel Graphics Development, LKML, stable,
Javier Martinez Canillas, Tomi Valkeinen, Claudio Suarez,
DRI Development, Pavel Machek, Greg Kroah-Hartman,
Geert Uytterhoeven, Sven Schnelle, Gerd Hoffmann
On Tue, Feb 1, 2022 at 11:16 AM Helge Deller <deller@gmx.de> wrote:
>
> On 1/31/22 22:05, Daniel Vetter wrote:
> > This functionally undoes 39aead8373b3 ("fbcon: Disable accelerated
> > scrolling"), but behind the FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
> > option.
>
> you have two trivial copy-n-paste errors in this patch which still prevent the
> console acceleration.
Duh :-(
But before we dig into details I think the big picture would be
better. I honestly don't like the #ifdef pile here that much. I wonder
whether your approach, also with GETVX/YRES adjusted somehow, wouldn't
look cleaner? Like I said in the cover letter I got mostly distracted
with fbcon locking last week, not really with this one here at all, so
maybe going with your 4 (or 2 if we squash them like I did here)
patches is neater?
Cheers, Daniel
>
> > diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
> > index 2ff90061c7f3..39dc18a5de86 100644
> > --- a/drivers/video/fbdev/core/fbcon.c
> > +++ b/drivers/video/fbdev/core/fbcon.c
> > @@ -1125,13 +1125,15 @@ static void fbcon_init(struct vc_data *vc, int init)
> >
> > ops->graphics = 0;
> >
> > - /*
> > - * No more hw acceleration for fbcon.
> > - *
> > - * FIXME: Garbage collect all the now dead code after sufficient time
> > - * has passed.
> > - */
> > +#ifdef CONFIG_FRAMEBUFFER_CONSOLE_ROTATION
>
> should be:
> #ifdef CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
>
>
> > + if ((info->flags & FBINFO_HWACCEL_COPYAREA) &&
> > + !(info->flags & FBINFO_HWACCEL_DISABLED))
> > + p->scrollmode = SCROLL_MOVE;
> > + else /* default to something safe */
> > + p->scrollmode = SCROLL_REDRAW;
> > +#else
> > p->scrollmode = SCROLL_REDRAW;
> > +#endif
> >
> > /*
> > * ++guenther: console.c:vc_allocate() relies on initializing
> > @@ -1971,15 +1973,49 @@ static void updatescrollmode(struct fbcon_display *p,
> > {
> > struct fbcon_ops *ops = info->fbcon_par;
> > int fh = vc->vc_font.height;
> > + int cap = info->flags;
> > + u16 t = 0;
> > + int ypan = FBCON_SWAP(ops->rotate, info->fix.ypanstep,
> > + info->fix.xpanstep);
> > + int ywrap = FBCON_SWAP(ops->rotate, info->fix.ywrapstep, t);
> > int yres = FBCON_SWAP(ops->rotate, info->var.yres, info->var.xres);
> > int vyres = FBCON_SWAP(ops->rotate, info->var.yres_virtual,
> > info->var.xres_virtual);
> > + int good_pan = (cap & FBINFO_HWACCEL_YPAN) &&
> > + divides(ypan, vc->vc_font.height) && vyres > yres;
> > + int good_wrap = (cap & FBINFO_HWACCEL_YWRAP) &&
> > + divides(ywrap, vc->vc_font.height) &&
> > + divides(vc->vc_font.height, vyres) &&
> > + divides(vc->vc_font.height, yres);
> > + int reading_fast = cap & FBINFO_READS_FAST;
> > + int fast_copyarea = (cap & FBINFO_HWACCEL_COPYAREA) &&
> > + !(cap & FBINFO_HWACCEL_DISABLED);
> > + int fast_imageblit = (cap & FBINFO_HWACCEL_IMAGEBLIT) &&
> > + !(cap & FBINFO_HWACCEL_DISABLED);
> >
> > p->vrows = vyres/fh;
> > if (yres > (fh * (vc->vc_rows + 1)))
> > p->vrows -= (yres - (fh * vc->vc_rows)) / fh;
> > if ((yres % fh) && (vyres % fh < yres % fh))
> > p->vrows--;
> > +
> > + if (good_wrap || good_pan) {
> > + if (reading_fast || fast_copyarea)
> > + p->scrollmode = good_wrap ?
> > + SCROLL_WRAP_MOVE : SCROLL_PAN_MOVE;
> > + else
> > + p->scrollmode = good_wrap ? SCROLL_REDRAW :
> > + SCROLL_PAN_REDRAW;
> > + } else {
> > + if (reading_fast || (fast_copyarea && !fast_imageblit))
> > + p->scrollmode = SCROLL_MOVE;
> > + else
> > + p->scrollmode = SCROLL_REDRAW;
> > + }
> > +
> > +#ifndef CONFIG_FRAMEBUFFER_CONSOLE_ROTATION
>
> same here... it needs to be:
> #ifdef CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
>
>
> > + p->scrollmode = SCROLL_REDRAW;
> > +#endif
> > }
> >
> > #define PITCH(w) (((w) + 7) >> 3)
> >
>
> still reviewing the other patches...
>
> Helge
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [Intel-gfx] [PATCH 03/21] fbcon: Restore fbcon scrolling acceleration
@ 2022-02-01 10:36 ` Daniel Vetter
0 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-02-01 10:36 UTC (permalink / raw)
To: Helge Deller
Cc: linux-fbdev, Thomas Zimmermann, Sam Ravnborg, Daniel Vetter,
Linus Torvalds, Intel Graphics Development, LKML, stable,
Javier Martinez Canillas, Tomi Valkeinen, DRI Development,
Pavel Machek, Greg Kroah-Hartman, Geert Uytterhoeven,
Dave Airlie, Sven Schnelle, Gerd Hoffmann
On Tue, Feb 1, 2022 at 11:16 AM Helge Deller <deller@gmx.de> wrote:
>
> On 1/31/22 22:05, Daniel Vetter wrote:
> > This functionally undoes 39aead8373b3 ("fbcon: Disable accelerated
> > scrolling"), but behind the FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
> > option.
>
> you have two trivial copy-n-paste errors in this patch which still prevent the
> console acceleration.
Duh :-(
But before we dig into details I think the big picture would be
better. I honestly don't like the #ifdef pile here that much. I wonder
whether your approach, also with GETVX/YRES adjusted somehow, wouldn't
look cleaner? Like I said in the cover letter I got mostly distracted
with fbcon locking last week, not really with this one here at all, so
maybe going with your 4 (or 2 if we squash them like I did here)
patches is neater?
Cheers, Daniel
>
> > diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
> > index 2ff90061c7f3..39dc18a5de86 100644
> > --- a/drivers/video/fbdev/core/fbcon.c
> > +++ b/drivers/video/fbdev/core/fbcon.c
> > @@ -1125,13 +1125,15 @@ static void fbcon_init(struct vc_data *vc, int init)
> >
> > ops->graphics = 0;
> >
> > - /*
> > - * No more hw acceleration for fbcon.
> > - *
> > - * FIXME: Garbage collect all the now dead code after sufficient time
> > - * has passed.
> > - */
> > +#ifdef CONFIG_FRAMEBUFFER_CONSOLE_ROTATION
>
> should be:
> #ifdef CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
>
>
> > + if ((info->flags & FBINFO_HWACCEL_COPYAREA) &&
> > + !(info->flags & FBINFO_HWACCEL_DISABLED))
> > + p->scrollmode = SCROLL_MOVE;
> > + else /* default to something safe */
> > + p->scrollmode = SCROLL_REDRAW;
> > +#else
> > p->scrollmode = SCROLL_REDRAW;
> > +#endif
> >
> > /*
> > * ++guenther: console.c:vc_allocate() relies on initializing
> > @@ -1971,15 +1973,49 @@ static void updatescrollmode(struct fbcon_display *p,
> > {
> > struct fbcon_ops *ops = info->fbcon_par;
> > int fh = vc->vc_font.height;
> > + int cap = info->flags;
> > + u16 t = 0;
> > + int ypan = FBCON_SWAP(ops->rotate, info->fix.ypanstep,
> > + info->fix.xpanstep);
> > + int ywrap = FBCON_SWAP(ops->rotate, info->fix.ywrapstep, t);
> > int yres = FBCON_SWAP(ops->rotate, info->var.yres, info->var.xres);
> > int vyres = FBCON_SWAP(ops->rotate, info->var.yres_virtual,
> > info->var.xres_virtual);
> > + int good_pan = (cap & FBINFO_HWACCEL_YPAN) &&
> > + divides(ypan, vc->vc_font.height) && vyres > yres;
> > + int good_wrap = (cap & FBINFO_HWACCEL_YWRAP) &&
> > + divides(ywrap, vc->vc_font.height) &&
> > + divides(vc->vc_font.height, vyres) &&
> > + divides(vc->vc_font.height, yres);
> > + int reading_fast = cap & FBINFO_READS_FAST;
> > + int fast_copyarea = (cap & FBINFO_HWACCEL_COPYAREA) &&
> > + !(cap & FBINFO_HWACCEL_DISABLED);
> > + int fast_imageblit = (cap & FBINFO_HWACCEL_IMAGEBLIT) &&
> > + !(cap & FBINFO_HWACCEL_DISABLED);
> >
> > p->vrows = vyres/fh;
> > if (yres > (fh * (vc->vc_rows + 1)))
> > p->vrows -= (yres - (fh * vc->vc_rows)) / fh;
> > if ((yres % fh) && (vyres % fh < yres % fh))
> > p->vrows--;
> > +
> > + if (good_wrap || good_pan) {
> > + if (reading_fast || fast_copyarea)
> > + p->scrollmode = good_wrap ?
> > + SCROLL_WRAP_MOVE : SCROLL_PAN_MOVE;
> > + else
> > + p->scrollmode = good_wrap ? SCROLL_REDRAW :
> > + SCROLL_PAN_REDRAW;
> > + } else {
> > + if (reading_fast || (fast_copyarea && !fast_imageblit))
> > + p->scrollmode = SCROLL_MOVE;
> > + else
> > + p->scrollmode = SCROLL_REDRAW;
> > + }
> > +
> > +#ifndef CONFIG_FRAMEBUFFER_CONSOLE_ROTATION
>
> same here... it needs to be:
> #ifdef CONFIG_FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
>
>
> > + p->scrollmode = SCROLL_REDRAW;
> > +#endif
> > }
> >
> > #define PITCH(w) (((w) + 7) >> 3)
> >
>
> still reviewing the other patches...
>
> Helge
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 09/21] fbcon: Replace FBCON_FLAGS_INIT with a boolean
2022-01-31 21:05 ` Daniel Vetter
(?)
@ 2022-02-01 10:37 ` Thomas Zimmermann
-1 siblings, 0 replies; 241+ messages in thread
From: Thomas Zimmermann @ 2022-02-01 10:37 UTC (permalink / raw)
To: Daniel Vetter, DRI Development
Cc: Intel Graphics Development, linux-fbdev, LKML, Daniel Vetter,
Daniel Vetter, Tetsuo Handa, Greg Kroah-Hartman, Du Cheng,
Claudio Suarez
[-- Attachment #1.1: Type: text/plain, Size: 3400 bytes --]
Am 31.01.22 um 22:05 schrieb Daniel Vetter:
> It's only one flag and slightly tidier code.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Du Cheng <ducheng2@gmail.com>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Claudio Suarez <cssk@net-c.es>
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
> ---
> drivers/video/fbdev/core/fbcon.c | 11 +++++------
> drivers/video/fbdev/core/fbcon.h | 4 +---
> 2 files changed, 6 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
> index affb40658fee..fa30e1909164 100644
> --- a/drivers/video/fbdev/core/fbcon.c
> +++ b/drivers/video/fbdev/core/fbcon.c
> @@ -773,7 +773,7 @@ static void con2fb_init_display(struct vc_data *vc, struct fb_info *info,
>
> ops->currcon = fg_console;
>
> - if (info->fbops->fb_set_par && !(ops->flags & FBCON_FLAGS_INIT)) {
> + if (info->fbops->fb_set_par && !ops->initialized) {
> ret = info->fbops->fb_set_par(info);
>
> if (ret)
> @@ -782,7 +782,7 @@ static void con2fb_init_display(struct vc_data *vc, struct fb_info *info,
> "error code %d\n", ret);
> }
>
> - ops->flags |= FBCON_FLAGS_INIT;
> + ops->initialized = true;
> ops->graphics = 0;
> fbcon_set_disp(info, &info->var, unit);
>
> @@ -1101,8 +1101,7 @@ static void fbcon_init(struct vc_data *vc, int init)
> * We need to do it in fbcon_init() to prevent screen corruption.
> */
> if (con_is_visible(vc) && vc->vc_mode == KD_TEXT) {
> - if (info->fbops->fb_set_par &&
> - !(ops->flags & FBCON_FLAGS_INIT)) {
> + if (info->fbops->fb_set_par && !ops->initialized) {
> ret = info->fbops->fb_set_par(info);
>
> if (ret)
> @@ -1111,7 +1110,7 @@ static void fbcon_init(struct vc_data *vc, int init)
> "error code %d\n", ret);
> }
>
> - ops->flags |= FBCON_FLAGS_INIT;
> + ops->initialized = true;
> }
>
> ops->graphics = 0;
> @@ -1186,7 +1185,7 @@ static void fbcon_deinit(struct vc_data *vc)
> if (con_is_visible(vc))
> fbcon_del_cursor_work(info);
>
> - ops->flags &= ~FBCON_FLAGS_INIT;
> + ops->initialized = false;
> finished:
>
> fbcon_free_font(p, free_font);
> diff --git a/drivers/video/fbdev/core/fbcon.h b/drivers/video/fbdev/core/fbcon.h
> index dce5ce41093e..b18d0cbf73b6 100644
> --- a/drivers/video/fbdev/core/fbcon.h
> +++ b/drivers/video/fbdev/core/fbcon.h
> @@ -18,8 +18,6 @@
>
> #include <asm/io.h>
>
> -#define FBCON_FLAGS_INIT 1
> -
> /*
> * This is the interface between the low-level console driver and the
> * low-level frame buffer device
> @@ -77,7 +75,7 @@ struct fbcon_ops {
> int blank_state;
> int graphics;
> int save_graphics; /* for debug enter/leave */
> - int flags;
> + bool initialized;
This will add 3 bytes of padding. Maybe you can put the bool elsewhere.
> int rotate;
> int cur_rotate;
> char *cursor_data;
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 09/21] fbcon: Replace FBCON_FLAGS_INIT with a boolean
@ 2022-02-01 10:37 ` Thomas Zimmermann
0 siblings, 0 replies; 241+ messages in thread
From: Thomas Zimmermann @ 2022-02-01 10:37 UTC (permalink / raw)
To: Daniel Vetter, DRI Development
Cc: linux-fbdev, Du Cheng, Tetsuo Handa, Greg Kroah-Hartman,
Intel Graphics Development, LKML, Claudio Suarez, Daniel Vetter
[-- Attachment #1.1: Type: text/plain, Size: 3400 bytes --]
Am 31.01.22 um 22:05 schrieb Daniel Vetter:
> It's only one flag and slightly tidier code.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Du Cheng <ducheng2@gmail.com>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Claudio Suarez <cssk@net-c.es>
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
> ---
> drivers/video/fbdev/core/fbcon.c | 11 +++++------
> drivers/video/fbdev/core/fbcon.h | 4 +---
> 2 files changed, 6 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
> index affb40658fee..fa30e1909164 100644
> --- a/drivers/video/fbdev/core/fbcon.c
> +++ b/drivers/video/fbdev/core/fbcon.c
> @@ -773,7 +773,7 @@ static void con2fb_init_display(struct vc_data *vc, struct fb_info *info,
>
> ops->currcon = fg_console;
>
> - if (info->fbops->fb_set_par && !(ops->flags & FBCON_FLAGS_INIT)) {
> + if (info->fbops->fb_set_par && !ops->initialized) {
> ret = info->fbops->fb_set_par(info);
>
> if (ret)
> @@ -782,7 +782,7 @@ static void con2fb_init_display(struct vc_data *vc, struct fb_info *info,
> "error code %d\n", ret);
> }
>
> - ops->flags |= FBCON_FLAGS_INIT;
> + ops->initialized = true;
> ops->graphics = 0;
> fbcon_set_disp(info, &info->var, unit);
>
> @@ -1101,8 +1101,7 @@ static void fbcon_init(struct vc_data *vc, int init)
> * We need to do it in fbcon_init() to prevent screen corruption.
> */
> if (con_is_visible(vc) && vc->vc_mode == KD_TEXT) {
> - if (info->fbops->fb_set_par &&
> - !(ops->flags & FBCON_FLAGS_INIT)) {
> + if (info->fbops->fb_set_par && !ops->initialized) {
> ret = info->fbops->fb_set_par(info);
>
> if (ret)
> @@ -1111,7 +1110,7 @@ static void fbcon_init(struct vc_data *vc, int init)
> "error code %d\n", ret);
> }
>
> - ops->flags |= FBCON_FLAGS_INIT;
> + ops->initialized = true;
> }
>
> ops->graphics = 0;
> @@ -1186,7 +1185,7 @@ static void fbcon_deinit(struct vc_data *vc)
> if (con_is_visible(vc))
> fbcon_del_cursor_work(info);
>
> - ops->flags &= ~FBCON_FLAGS_INIT;
> + ops->initialized = false;
> finished:
>
> fbcon_free_font(p, free_font);
> diff --git a/drivers/video/fbdev/core/fbcon.h b/drivers/video/fbdev/core/fbcon.h
> index dce5ce41093e..b18d0cbf73b6 100644
> --- a/drivers/video/fbdev/core/fbcon.h
> +++ b/drivers/video/fbdev/core/fbcon.h
> @@ -18,8 +18,6 @@
>
> #include <asm/io.h>
>
> -#define FBCON_FLAGS_INIT 1
> -
> /*
> * This is the interface between the low-level console driver and the
> * low-level frame buffer device
> @@ -77,7 +75,7 @@ struct fbcon_ops {
> int blank_state;
> int graphics;
> int save_graphics; /* for debug enter/leave */
> - int flags;
> + bool initialized;
This will add 3 bytes of padding. Maybe you can put the bool elsewhere.
> int rotate;
> int cur_rotate;
> char *cursor_data;
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [Intel-gfx] [PATCH 09/21] fbcon: Replace FBCON_FLAGS_INIT with a boolean
@ 2022-02-01 10:37 ` Thomas Zimmermann
0 siblings, 0 replies; 241+ messages in thread
From: Thomas Zimmermann @ 2022-02-01 10:37 UTC (permalink / raw)
To: Daniel Vetter, DRI Development
Cc: linux-fbdev, Du Cheng, Tetsuo Handa, Greg Kroah-Hartman,
Intel Graphics Development, LKML, Daniel Vetter
[-- Attachment #1.1: Type: text/plain, Size: 3400 bytes --]
Am 31.01.22 um 22:05 schrieb Daniel Vetter:
> It's only one flag and slightly tidier code.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Du Cheng <ducheng2@gmail.com>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Claudio Suarez <cssk@net-c.es>
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
> ---
> drivers/video/fbdev/core/fbcon.c | 11 +++++------
> drivers/video/fbdev/core/fbcon.h | 4 +---
> 2 files changed, 6 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
> index affb40658fee..fa30e1909164 100644
> --- a/drivers/video/fbdev/core/fbcon.c
> +++ b/drivers/video/fbdev/core/fbcon.c
> @@ -773,7 +773,7 @@ static void con2fb_init_display(struct vc_data *vc, struct fb_info *info,
>
> ops->currcon = fg_console;
>
> - if (info->fbops->fb_set_par && !(ops->flags & FBCON_FLAGS_INIT)) {
> + if (info->fbops->fb_set_par && !ops->initialized) {
> ret = info->fbops->fb_set_par(info);
>
> if (ret)
> @@ -782,7 +782,7 @@ static void con2fb_init_display(struct vc_data *vc, struct fb_info *info,
> "error code %d\n", ret);
> }
>
> - ops->flags |= FBCON_FLAGS_INIT;
> + ops->initialized = true;
> ops->graphics = 0;
> fbcon_set_disp(info, &info->var, unit);
>
> @@ -1101,8 +1101,7 @@ static void fbcon_init(struct vc_data *vc, int init)
> * We need to do it in fbcon_init() to prevent screen corruption.
> */
> if (con_is_visible(vc) && vc->vc_mode == KD_TEXT) {
> - if (info->fbops->fb_set_par &&
> - !(ops->flags & FBCON_FLAGS_INIT)) {
> + if (info->fbops->fb_set_par && !ops->initialized) {
> ret = info->fbops->fb_set_par(info);
>
> if (ret)
> @@ -1111,7 +1110,7 @@ static void fbcon_init(struct vc_data *vc, int init)
> "error code %d\n", ret);
> }
>
> - ops->flags |= FBCON_FLAGS_INIT;
> + ops->initialized = true;
> }
>
> ops->graphics = 0;
> @@ -1186,7 +1185,7 @@ static void fbcon_deinit(struct vc_data *vc)
> if (con_is_visible(vc))
> fbcon_del_cursor_work(info);
>
> - ops->flags &= ~FBCON_FLAGS_INIT;
> + ops->initialized = false;
> finished:
>
> fbcon_free_font(p, free_font);
> diff --git a/drivers/video/fbdev/core/fbcon.h b/drivers/video/fbdev/core/fbcon.h
> index dce5ce41093e..b18d0cbf73b6 100644
> --- a/drivers/video/fbdev/core/fbcon.h
> +++ b/drivers/video/fbdev/core/fbcon.h
> @@ -18,8 +18,6 @@
>
> #include <asm/io.h>
>
> -#define FBCON_FLAGS_INIT 1
> -
> /*
> * This is the interface between the low-level console driver and the
> * low-level frame buffer device
> @@ -77,7 +75,7 @@ struct fbcon_ops {
> int blank_state;
> int graphics;
> int save_graphics; /* for debug enter/leave */
> - int flags;
> + bool initialized;
This will add 3 bytes of padding. Maybe you can put the bool elsewhere.
> int rotate;
> int cur_rotate;
> char *cursor_data;
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 01/21] MAINTAINERS: Add entry for fbdev core
2022-02-01 10:19 ` Thomas Zimmermann
(?)
@ 2022-02-01 10:45 ` Greg Kroah-Hartman
-1 siblings, 0 replies; 241+ messages in thread
From: Greg Kroah-Hartman @ 2022-02-01 10:45 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: Daniel Vetter, DRI Development, linux-fbdev, Sam Ravnborg,
Daniel Vetter, Intel Graphics Development, LKML,
Javier Martinez Canillas, Linus Torvalds, Tomi Valkeinen,
Claudio Suarez, Gerd Hoffmann, Pavel Machek, Geert Uytterhoeven,
Sven Schnelle
On Tue, Feb 01, 2022 at 11:19:54AM +0100, Thomas Zimmermann wrote:
>
>
> Am 31.01.22 um 22:05 schrieb Daniel Vetter:
> > Ever since Tomi extracted the core code in 2014 it's been defacto me
> > maintaining this, with help from others from dri-devel and sometimes
> > Linus (but those are mostly merge conflicts):
> >
> > $ git shortlog -ns drivers/video/fbdev/core/ | head -n5
> > 35 Daniel Vetter
> > 23 Linus Torvalds
> > 10 Hans de Goede
> > 9 Dave Airlie
> > 6 Peter Rosin
> >
> > I think ideally we'd also record that the various firmware fb drivers
> > (efifb, vesafb, ...) are also maintained in drm-misc because for the
> > past few years the patches have either been to fix handover issues
> > with drm drivers, or caused handover issues with drm drivers. So any
> > other tree just doesn't make sense. But also, there's plenty of
> > outdated MAINTAINER entries for these with people and git trees that
> > haven't been active in years, so maybe let's just leave them alone.
> > And furthermore distros are now adopting simpledrm as the firmware fb
> > driver, so hopefully the need to care about the fbdev firmware drivers
> > will go down going forward.
> >
> > Note that drm-misc is group maintained, I expect that to continue like
> > we've done before, so no new expectations that patches all go through
> > my hands. That would be silly. This also means I'm happy to put any
> > other volunteer's name in the M: line, but otherwise git log says I'm
> > the one who's stuck with this.
> >
> > Cc: Dave Airlie <airlied@gmail.com>
> > Cc: Jani Nikula <jani.nikula@linux.intel.com>
> > Cc: Linus Torvalds <torvalds@linux-foundation.org>
> > Cc: Linux Fbdev development list <linux-fbdev@vger.kernel.org>
> > Cc: Pavel Machek <pavel@ucw.cz>
> > Cc: Sam Ravnborg <sam@ravnborg.org>
> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Cc: Javier Martinez Canillas <javierm@redhat.com>
> > Cc: DRI Development <dri-devel@lists.freedesktop.org>
> > Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
> > Cc: Claudio Suarez <cssk@net-c.es>
> > Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> > Cc: Geert Uytterhoeven <geert@linux-m68k.org>
> > Cc: Thomas Zimmermann <tzimmermann@suse.de>
> > Cc: Daniel Vetter <daniel.vetter@intel.com>
> > Cc: Sven Schnelle <svens@stackframe.org>
> > Cc: Gerd Hoffmann <kraxel@redhat.com>
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
>
> Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 01/21] MAINTAINERS: Add entry for fbdev core
@ 2022-02-01 10:45 ` Greg Kroah-Hartman
0 siblings, 0 replies; 241+ messages in thread
From: Greg Kroah-Hartman @ 2022-02-01 10:45 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: linux-fbdev, Sven Schnelle, Daniel Vetter,
Intel Graphics Development, LKML, DRI Development,
Javier Martinez Canillas, Linus Torvalds, Geert Uytterhoeven,
Tomi Valkeinen, Claudio Suarez, Gerd Hoffmann, Pavel Machek,
Daniel Vetter, Sam Ravnborg
On Tue, Feb 01, 2022 at 11:19:54AM +0100, Thomas Zimmermann wrote:
>
>
> Am 31.01.22 um 22:05 schrieb Daniel Vetter:
> > Ever since Tomi extracted the core code in 2014 it's been defacto me
> > maintaining this, with help from others from dri-devel and sometimes
> > Linus (but those are mostly merge conflicts):
> >
> > $ git shortlog -ns drivers/video/fbdev/core/ | head -n5
> > 35 Daniel Vetter
> > 23 Linus Torvalds
> > 10 Hans de Goede
> > 9 Dave Airlie
> > 6 Peter Rosin
> >
> > I think ideally we'd also record that the various firmware fb drivers
> > (efifb, vesafb, ...) are also maintained in drm-misc because for the
> > past few years the patches have either been to fix handover issues
> > with drm drivers, or caused handover issues with drm drivers. So any
> > other tree just doesn't make sense. But also, there's plenty of
> > outdated MAINTAINER entries for these with people and git trees that
> > haven't been active in years, so maybe let's just leave them alone.
> > And furthermore distros are now adopting simpledrm as the firmware fb
> > driver, so hopefully the need to care about the fbdev firmware drivers
> > will go down going forward.
> >
> > Note that drm-misc is group maintained, I expect that to continue like
> > we've done before, so no new expectations that patches all go through
> > my hands. That would be silly. This also means I'm happy to put any
> > other volunteer's name in the M: line, but otherwise git log says I'm
> > the one who's stuck with this.
> >
> > Cc: Dave Airlie <airlied@gmail.com>
> > Cc: Jani Nikula <jani.nikula@linux.intel.com>
> > Cc: Linus Torvalds <torvalds@linux-foundation.org>
> > Cc: Linux Fbdev development list <linux-fbdev@vger.kernel.org>
> > Cc: Pavel Machek <pavel@ucw.cz>
> > Cc: Sam Ravnborg <sam@ravnborg.org>
> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Cc: Javier Martinez Canillas <javierm@redhat.com>
> > Cc: DRI Development <dri-devel@lists.freedesktop.org>
> > Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
> > Cc: Claudio Suarez <cssk@net-c.es>
> > Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> > Cc: Geert Uytterhoeven <geert@linux-m68k.org>
> > Cc: Thomas Zimmermann <tzimmermann@suse.de>
> > Cc: Daniel Vetter <daniel.vetter@intel.com>
> > Cc: Sven Schnelle <svens@stackframe.org>
> > Cc: Gerd Hoffmann <kraxel@redhat.com>
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
>
> Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [Intel-gfx] [PATCH 01/21] MAINTAINERS: Add entry for fbdev core
@ 2022-02-01 10:45 ` Greg Kroah-Hartman
0 siblings, 0 replies; 241+ messages in thread
From: Greg Kroah-Hartman @ 2022-02-01 10:45 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: linux-fbdev, Sven Schnelle, Daniel Vetter,
Intel Graphics Development, LKML, DRI Development,
Javier Martinez Canillas, Linus Torvalds, Geert Uytterhoeven,
Tomi Valkeinen, Gerd Hoffmann, Pavel Machek, Daniel Vetter,
Sam Ravnborg
On Tue, Feb 01, 2022 at 11:19:54AM +0100, Thomas Zimmermann wrote:
>
>
> Am 31.01.22 um 22:05 schrieb Daniel Vetter:
> > Ever since Tomi extracted the core code in 2014 it's been defacto me
> > maintaining this, with help from others from dri-devel and sometimes
> > Linus (but those are mostly merge conflicts):
> >
> > $ git shortlog -ns drivers/video/fbdev/core/ | head -n5
> > 35 Daniel Vetter
> > 23 Linus Torvalds
> > 10 Hans de Goede
> > 9 Dave Airlie
> > 6 Peter Rosin
> >
> > I think ideally we'd also record that the various firmware fb drivers
> > (efifb, vesafb, ...) are also maintained in drm-misc because for the
> > past few years the patches have either been to fix handover issues
> > with drm drivers, or caused handover issues with drm drivers. So any
> > other tree just doesn't make sense. But also, there's plenty of
> > outdated MAINTAINER entries for these with people and git trees that
> > haven't been active in years, so maybe let's just leave them alone.
> > And furthermore distros are now adopting simpledrm as the firmware fb
> > driver, so hopefully the need to care about the fbdev firmware drivers
> > will go down going forward.
> >
> > Note that drm-misc is group maintained, I expect that to continue like
> > we've done before, so no new expectations that patches all go through
> > my hands. That would be silly. This also means I'm happy to put any
> > other volunteer's name in the M: line, but otherwise git log says I'm
> > the one who's stuck with this.
> >
> > Cc: Dave Airlie <airlied@gmail.com>
> > Cc: Jani Nikula <jani.nikula@linux.intel.com>
> > Cc: Linus Torvalds <torvalds@linux-foundation.org>
> > Cc: Linux Fbdev development list <linux-fbdev@vger.kernel.org>
> > Cc: Pavel Machek <pavel@ucw.cz>
> > Cc: Sam Ravnborg <sam@ravnborg.org>
> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Cc: Javier Martinez Canillas <javierm@redhat.com>
> > Cc: DRI Development <dri-devel@lists.freedesktop.org>
> > Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
> > Cc: Claudio Suarez <cssk@net-c.es>
> > Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> > Cc: Geert Uytterhoeven <geert@linux-m68k.org>
> > Cc: Thomas Zimmermann <tzimmermann@suse.de>
> > Cc: Daniel Vetter <daniel.vetter@intel.com>
> > Cc: Sven Schnelle <svens@stackframe.org>
> > Cc: Gerd Hoffmann <kraxel@redhat.com>
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
>
> Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 03/21] fbcon: Restore fbcon scrolling acceleration
2022-02-01 10:36 ` Daniel Vetter
(?)
@ 2022-02-01 11:01 ` Helge Deller
-1 siblings, 0 replies; 241+ messages in thread
From: Helge Deller @ 2022-02-01 11:01 UTC (permalink / raw)
To: Daniel Vetter
Cc: DRI Development, Intel Graphics Development, linux-fbdev, LKML,
stable, Claudio Suarez, Dave Airlie, Jani Nikula, Linus Torvalds,
Pavel Machek, Sam Ravnborg, Greg Kroah-Hartman,
Javier Martinez Canillas, Tomi Valkeinen, Geert Uytterhoeven,
Thomas Zimmermann, Daniel Vetter, Sven Schnelle, Gerd Hoffmann
On 2/1/22 11:36, Daniel Vetter wrote:
> On Tue, Feb 1, 2022 at 11:16 AM Helge Deller <deller@gmx.de> wrote:
>>
>> On 1/31/22 22:05, Daniel Vetter wrote:
>>> This functionally undoes 39aead8373b3 ("fbcon: Disable accelerated
>>> scrolling"), but behind the FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
>>> option.
>>
>> you have two trivial copy-n-paste errors in this patch which still prevent the
>> console acceleration.
>
> Duh :-(
>
> But before we dig into details I think the big picture would be
> better. I honestly don't like the #ifdef pile here that much.
Me neither.
The ifdefs give a better separation, but prevents that the compiler
checks the various paths when building.
> I wonder whether your approach, also with GETVX/YRES adjusted
> somehow, wouldn't look cleaner?
I think so.
You wouldn't even need to touch GETVX/YRES because the compiler
will optimize/reduce it from
#define GETVYRES(s,i) ({ \
(s == SCROLL_REDRAW || s == SCROLL_MOVE) ? \
(i)->var.yres : (i)->var.yres_virtual; })
to just become:
#define GETVYRES(s,i) ((i)->var.yres)
> Like I said in the cover letter I got mostly distracted with fbcon
> locking last week, not really with this one here at all, so maybe
> going with your 4 (or 2 if we squash them like I did here) patches is
> neater?
The benefit of my patch series was, that it could be easily backported first,
and then cleaned up afterwards. Even a small additional backport patch to disable
the fbcon acceleration for DRM in the old releases would be easy.
But I'm not insisting on backporting the patches, if we find good way forward.
So, either with the 4 (or 2) patches would be OK for me (or even your approach).
Helge
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 03/21] fbcon: Restore fbcon scrolling acceleration
@ 2022-02-01 11:01 ` Helge Deller
0 siblings, 0 replies; 241+ messages in thread
From: Helge Deller @ 2022-02-01 11:01 UTC (permalink / raw)
To: Daniel Vetter
Cc: linux-fbdev, Thomas Zimmermann, Sam Ravnborg, Daniel Vetter,
Linus Torvalds, Intel Graphics Development, LKML, stable,
Javier Martinez Canillas, Tomi Valkeinen, Claudio Suarez,
DRI Development, Pavel Machek, Greg Kroah-Hartman,
Geert Uytterhoeven, Sven Schnelle, Gerd Hoffmann
On 2/1/22 11:36, Daniel Vetter wrote:
> On Tue, Feb 1, 2022 at 11:16 AM Helge Deller <deller@gmx.de> wrote:
>>
>> On 1/31/22 22:05, Daniel Vetter wrote:
>>> This functionally undoes 39aead8373b3 ("fbcon: Disable accelerated
>>> scrolling"), but behind the FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
>>> option.
>>
>> you have two trivial copy-n-paste errors in this patch which still prevent the
>> console acceleration.
>
> Duh :-(
>
> But before we dig into details I think the big picture would be
> better. I honestly don't like the #ifdef pile here that much.
Me neither.
The ifdefs give a better separation, but prevents that the compiler
checks the various paths when building.
> I wonder whether your approach, also with GETVX/YRES adjusted
> somehow, wouldn't look cleaner?
I think so.
You wouldn't even need to touch GETVX/YRES because the compiler
will optimize/reduce it from
#define GETVYRES(s,i) ({ \
(s == SCROLL_REDRAW || s == SCROLL_MOVE) ? \
(i)->var.yres : (i)->var.yres_virtual; })
to just become:
#define GETVYRES(s,i) ((i)->var.yres)
> Like I said in the cover letter I got mostly distracted with fbcon
> locking last week, not really with this one here at all, so maybe
> going with your 4 (or 2 if we squash them like I did here) patches is
> neater?
The benefit of my patch series was, that it could be easily backported first,
and then cleaned up afterwards. Even a small additional backport patch to disable
the fbcon acceleration for DRM in the old releases would be easy.
But I'm not insisting on backporting the patches, if we find good way forward.
So, either with the 4 (or 2) patches would be OK for me (or even your approach).
Helge
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [Intel-gfx] [PATCH 03/21] fbcon: Restore fbcon scrolling acceleration
@ 2022-02-01 11:01 ` Helge Deller
0 siblings, 0 replies; 241+ messages in thread
From: Helge Deller @ 2022-02-01 11:01 UTC (permalink / raw)
To: Daniel Vetter
Cc: linux-fbdev, Thomas Zimmermann, Sam Ravnborg, Daniel Vetter,
Linus Torvalds, Intel Graphics Development, LKML, stable,
Javier Martinez Canillas, Tomi Valkeinen, DRI Development,
Pavel Machek, Greg Kroah-Hartman, Geert Uytterhoeven,
Dave Airlie, Sven Schnelle, Gerd Hoffmann
On 2/1/22 11:36, Daniel Vetter wrote:
> On Tue, Feb 1, 2022 at 11:16 AM Helge Deller <deller@gmx.de> wrote:
>>
>> On 1/31/22 22:05, Daniel Vetter wrote:
>>> This functionally undoes 39aead8373b3 ("fbcon: Disable accelerated
>>> scrolling"), but behind the FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
>>> option.
>>
>> you have two trivial copy-n-paste errors in this patch which still prevent the
>> console acceleration.
>
> Duh :-(
>
> But before we dig into details I think the big picture would be
> better. I honestly don't like the #ifdef pile here that much.
Me neither.
The ifdefs give a better separation, but prevents that the compiler
checks the various paths when building.
> I wonder whether your approach, also with GETVX/YRES adjusted
> somehow, wouldn't look cleaner?
I think so.
You wouldn't even need to touch GETVX/YRES because the compiler
will optimize/reduce it from
#define GETVYRES(s,i) ({ \
(s == SCROLL_REDRAW || s == SCROLL_MOVE) ? \
(i)->var.yres : (i)->var.yres_virtual; })
to just become:
#define GETVYRES(s,i) ((i)->var.yres)
> Like I said in the cover letter I got mostly distracted with fbcon
> locking last week, not really with this one here at all, so maybe
> going with your 4 (or 2 if we squash them like I did here) patches is
> neater?
The benefit of my patch series was, that it could be easily backported first,
and then cleaned up afterwards. Even a small additional backport patch to disable
the fbcon acceleration for DRM in the old releases would be easy.
But I'm not insisting on backporting the patches, if we find good way forward.
So, either with the 4 (or 2) patches would be OK for me (or even your approach).
Helge
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 03/21] fbcon: Restore fbcon scrolling acceleration
2022-02-01 11:01 ` Helge Deller
(?)
@ 2022-02-01 13:45 ` Daniel Vetter
-1 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-02-01 13:45 UTC (permalink / raw)
To: Helge Deller
Cc: DRI Development, Intel Graphics Development, linux-fbdev, LKML,
stable, Claudio Suarez, Dave Airlie, Jani Nikula, Linus Torvalds,
Pavel Machek, Sam Ravnborg, Greg Kroah-Hartman,
Javier Martinez Canillas, Tomi Valkeinen, Geert Uytterhoeven,
Thomas Zimmermann, Daniel Vetter, Sven Schnelle, Gerd Hoffmann
On Tue, Feb 1, 2022 at 12:01 PM Helge Deller <deller@gmx.de> wrote:
> On 2/1/22 11:36, Daniel Vetter wrote:
> > On Tue, Feb 1, 2022 at 11:16 AM Helge Deller <deller@gmx.de> wrote:
> >>
> >> On 1/31/22 22:05, Daniel Vetter wrote:
> >>> This functionally undoes 39aead8373b3 ("fbcon: Disable accelerated
> >>> scrolling"), but behind the FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
> >>> option.
> >>
> >> you have two trivial copy-n-paste errors in this patch which still prevent the
> >> console acceleration.
> >
> > Duh :-(
> >
> > But before we dig into details I think the big picture would be
> > better. I honestly don't like the #ifdef pile here that much.
>
> Me neither.
> The ifdefs give a better separation, but prevents that the compiler
> checks the various paths when building.
>
> > I wonder whether your approach, also with GETVX/YRES adjusted
> > somehow, wouldn't look cleaner?
> I think so.
> You wouldn't even need to touch GETVX/YRES because the compiler
> will optimize/reduce it from
>
> #define GETVYRES(s,i) ({ \
> (s == SCROLL_REDRAW || s == SCROLL_MOVE) ? \
> (i)->var.yres : (i)->var.yres_virtual; })
>
> to just become:
>
> #define GETVYRES(s,i) ((i)->var.yres)
Yeah, but you need to roll out your helper to all the callsites. But
since you #ifdef out info->scrollmode we should catch them all I
guess.
> > Like I said in the cover letter I got mostly distracted with fbcon
> > locking last week, not really with this one here at all, so maybe
> > going with your 4 (or 2 if we squash them like I did here) patches is
> > neater?
>
> The benefit of my patch series was, that it could be easily backported first,
> and then cleaned up afterwards. Even a small additional backport patch to disable
> the fbcon acceleration for DRM in the old releases would be easy.
> But I'm not insisting on backporting the patches, if we find good way forward.
>
> So, either with the 4 (or 2) patches would be OK for me (or even your approach).
The idea behind the squash was that it's then impossible to backport
without the Kconfig, and so we'll only enable this code when people
intentionally want it. Maybe I'm too paranoid?
Anyway, you feel like finishing off your approach? Or should I send
out v2 of this with the issues fixed you spotted? Like I said either
is fine with me.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 03/21] fbcon: Restore fbcon scrolling acceleration
@ 2022-02-01 13:45 ` Daniel Vetter
0 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-02-01 13:45 UTC (permalink / raw)
To: Helge Deller
Cc: linux-fbdev, Thomas Zimmermann, Sam Ravnborg, Daniel Vetter,
Linus Torvalds, Intel Graphics Development, LKML, stable,
Javier Martinez Canillas, Tomi Valkeinen, Claudio Suarez,
DRI Development, Pavel Machek, Greg Kroah-Hartman,
Geert Uytterhoeven, Sven Schnelle, Gerd Hoffmann
On Tue, Feb 1, 2022 at 12:01 PM Helge Deller <deller@gmx.de> wrote:
> On 2/1/22 11:36, Daniel Vetter wrote:
> > On Tue, Feb 1, 2022 at 11:16 AM Helge Deller <deller@gmx.de> wrote:
> >>
> >> On 1/31/22 22:05, Daniel Vetter wrote:
> >>> This functionally undoes 39aead8373b3 ("fbcon: Disable accelerated
> >>> scrolling"), but behind the FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
> >>> option.
> >>
> >> you have two trivial copy-n-paste errors in this patch which still prevent the
> >> console acceleration.
> >
> > Duh :-(
> >
> > But before we dig into details I think the big picture would be
> > better. I honestly don't like the #ifdef pile here that much.
>
> Me neither.
> The ifdefs give a better separation, but prevents that the compiler
> checks the various paths when building.
>
> > I wonder whether your approach, also with GETVX/YRES adjusted
> > somehow, wouldn't look cleaner?
> I think so.
> You wouldn't even need to touch GETVX/YRES because the compiler
> will optimize/reduce it from
>
> #define GETVYRES(s,i) ({ \
> (s == SCROLL_REDRAW || s == SCROLL_MOVE) ? \
> (i)->var.yres : (i)->var.yres_virtual; })
>
> to just become:
>
> #define GETVYRES(s,i) ((i)->var.yres)
Yeah, but you need to roll out your helper to all the callsites. But
since you #ifdef out info->scrollmode we should catch them all I
guess.
> > Like I said in the cover letter I got mostly distracted with fbcon
> > locking last week, not really with this one here at all, so maybe
> > going with your 4 (or 2 if we squash them like I did here) patches is
> > neater?
>
> The benefit of my patch series was, that it could be easily backported first,
> and then cleaned up afterwards. Even a small additional backport patch to disable
> the fbcon acceleration for DRM in the old releases would be easy.
> But I'm not insisting on backporting the patches, if we find good way forward.
>
> So, either with the 4 (or 2) patches would be OK for me (or even your approach).
The idea behind the squash was that it's then impossible to backport
without the Kconfig, and so we'll only enable this code when people
intentionally want it. Maybe I'm too paranoid?
Anyway, you feel like finishing off your approach? Or should I send
out v2 of this with the issues fixed you spotted? Like I said either
is fine with me.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [Intel-gfx] [PATCH 03/21] fbcon: Restore fbcon scrolling acceleration
@ 2022-02-01 13:45 ` Daniel Vetter
0 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-02-01 13:45 UTC (permalink / raw)
To: Helge Deller
Cc: linux-fbdev, Thomas Zimmermann, Sam Ravnborg, Daniel Vetter,
Linus Torvalds, Intel Graphics Development, LKML, stable,
Javier Martinez Canillas, Tomi Valkeinen, DRI Development,
Pavel Machek, Greg Kroah-Hartman, Geert Uytterhoeven,
Dave Airlie, Sven Schnelle, Gerd Hoffmann
On Tue, Feb 1, 2022 at 12:01 PM Helge Deller <deller@gmx.de> wrote:
> On 2/1/22 11:36, Daniel Vetter wrote:
> > On Tue, Feb 1, 2022 at 11:16 AM Helge Deller <deller@gmx.de> wrote:
> >>
> >> On 1/31/22 22:05, Daniel Vetter wrote:
> >>> This functionally undoes 39aead8373b3 ("fbcon: Disable accelerated
> >>> scrolling"), but behind the FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
> >>> option.
> >>
> >> you have two trivial copy-n-paste errors in this patch which still prevent the
> >> console acceleration.
> >
> > Duh :-(
> >
> > But before we dig into details I think the big picture would be
> > better. I honestly don't like the #ifdef pile here that much.
>
> Me neither.
> The ifdefs give a better separation, but prevents that the compiler
> checks the various paths when building.
>
> > I wonder whether your approach, also with GETVX/YRES adjusted
> > somehow, wouldn't look cleaner?
> I think so.
> You wouldn't even need to touch GETVX/YRES because the compiler
> will optimize/reduce it from
>
> #define GETVYRES(s,i) ({ \
> (s == SCROLL_REDRAW || s == SCROLL_MOVE) ? \
> (i)->var.yres : (i)->var.yres_virtual; })
>
> to just become:
>
> #define GETVYRES(s,i) ((i)->var.yres)
Yeah, but you need to roll out your helper to all the callsites. But
since you #ifdef out info->scrollmode we should catch them all I
guess.
> > Like I said in the cover letter I got mostly distracted with fbcon
> > locking last week, not really with this one here at all, so maybe
> > going with your 4 (or 2 if we squash them like I did here) patches is
> > neater?
>
> The benefit of my patch series was, that it could be easily backported first,
> and then cleaned up afterwards. Even a small additional backport patch to disable
> the fbcon acceleration for DRM in the old releases would be easy.
> But I'm not insisting on backporting the patches, if we find good way forward.
>
> So, either with the 4 (or 2) patches would be OK for me (or even your approach).
The idea behind the squash was that it's then impossible to backport
without the Kconfig, and so we'll only enable this code when people
intentionally want it. Maybe I'm too paranoid?
Anyway, you feel like finishing off your approach? Or should I send
out v2 of this with the issues fixed you spotted? Like I said either
is fine with me.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 01/21] MAINTAINERS: Add entry for fbdev core
2022-01-31 21:05 ` Daniel Vetter
(?)
@ 2022-02-01 14:01 ` Javier Martinez Canillas
-1 siblings, 0 replies; 241+ messages in thread
From: Javier Martinez Canillas @ 2022-02-01 14:01 UTC (permalink / raw)
To: Daniel Vetter, DRI Development
Cc: Intel Graphics Development, linux-fbdev, LKML, Dave Airlie,
Jani Nikula, Linus Torvalds, Pavel Machek, Sam Ravnborg,
Greg Kroah-Hartman, Claudio Suarez, Tomi Valkeinen,
Geert Uytterhoeven, Thomas Zimmermann, Daniel Vetter,
Sven Schnelle, Gerd Hoffmann
On 1/31/22 22:05, Daniel Vetter wrote:
> Ever since Tomi extracted the core code in 2014 it's been defacto me
> maintaining this, with help from others from dri-devel and sometimes
> Linus (but those are mostly merge conflicts):
>
> $ git shortlog -ns drivers/video/fbdev/core/ | head -n5
> 35 Daniel Vetter
> 23 Linus Torvalds
> 10 Hans de Goede
> 9 Dave Airlie
> 6 Peter Rosin
>
> I think ideally we'd also record that the various firmware fb drivers
> (efifb, vesafb, ...) are also maintained in drm-misc because for the
> past few years the patches have either been to fix handover issues
> with drm drivers, or caused handover issues with drm drivers. So any
> other tree just doesn't make sense. But also, there's plenty of
> outdated MAINTAINER entries for these with people and git trees that
> haven't been active in years, so maybe let's just leave them alone.
> And furthermore distros are now adopting simpledrm as the firmware fb
> driver, so hopefully the need to care about the fbdev firmware drivers
> will go down going forward.
>
> Note that drm-misc is group maintained, I expect that to continue like
> we've done before, so no new expectations that patches all go through
> my hands. That would be silly. This also means I'm happy to put any
> other volunteer's name in the M: line, but otherwise git log says I'm
> the one who's stuck with this.
>
> Cc: Dave Airlie <airlied@gmail.com>
> Cc: Jani Nikula <jani.nikula@linux.intel.com>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: Linux Fbdev development list <linux-fbdev@vger.kernel.org>
> Cc: Pavel Machek <pavel@ucw.cz>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Javier Martinez Canillas <javierm@redhat.com>
> Cc: DRI Development <dri-devel@lists.freedesktop.org>
> Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
> Cc: Claudio Suarez <cssk@net-c.es>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Cc: Geert Uytterhoeven <geert@linux-m68k.org>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Sven Schnelle <svens@stackframe.org>
> Cc: Gerd Hoffmann <kraxel@redhat.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> ---
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 01/21] MAINTAINERS: Add entry for fbdev core
@ 2022-02-01 14:01 ` Javier Martinez Canillas
0 siblings, 0 replies; 241+ messages in thread
From: Javier Martinez Canillas @ 2022-02-01 14:01 UTC (permalink / raw)
To: Daniel Vetter, DRI Development
Cc: linux-fbdev, Thomas Zimmermann, Sam Ravnborg, Daniel Vetter,
Intel Graphics Development, LKML, Tomi Valkeinen, Claudio Suarez,
Gerd Hoffmann, Pavel Machek, Greg Kroah-Hartman,
Geert Uytterhoeven, Linus Torvalds, Sven Schnelle
On 1/31/22 22:05, Daniel Vetter wrote:
> Ever since Tomi extracted the core code in 2014 it's been defacto me
> maintaining this, with help from others from dri-devel and sometimes
> Linus (but those are mostly merge conflicts):
>
> $ git shortlog -ns drivers/video/fbdev/core/ | head -n5
> 35 Daniel Vetter
> 23 Linus Torvalds
> 10 Hans de Goede
> 9 Dave Airlie
> 6 Peter Rosin
>
> I think ideally we'd also record that the various firmware fb drivers
> (efifb, vesafb, ...) are also maintained in drm-misc because for the
> past few years the patches have either been to fix handover issues
> with drm drivers, or caused handover issues with drm drivers. So any
> other tree just doesn't make sense. But also, there's plenty of
> outdated MAINTAINER entries for these with people and git trees that
> haven't been active in years, so maybe let's just leave them alone.
> And furthermore distros are now adopting simpledrm as the firmware fb
> driver, so hopefully the need to care about the fbdev firmware drivers
> will go down going forward.
>
> Note that drm-misc is group maintained, I expect that to continue like
> we've done before, so no new expectations that patches all go through
> my hands. That would be silly. This also means I'm happy to put any
> other volunteer's name in the M: line, but otherwise git log says I'm
> the one who's stuck with this.
>
> Cc: Dave Airlie <airlied@gmail.com>
> Cc: Jani Nikula <jani.nikula@linux.intel.com>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: Linux Fbdev development list <linux-fbdev@vger.kernel.org>
> Cc: Pavel Machek <pavel@ucw.cz>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Javier Martinez Canillas <javierm@redhat.com>
> Cc: DRI Development <dri-devel@lists.freedesktop.org>
> Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
> Cc: Claudio Suarez <cssk@net-c.es>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Cc: Geert Uytterhoeven <geert@linux-m68k.org>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Sven Schnelle <svens@stackframe.org>
> Cc: Gerd Hoffmann <kraxel@redhat.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> ---
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [Intel-gfx] [PATCH 01/21] MAINTAINERS: Add entry for fbdev core
@ 2022-02-01 14:01 ` Javier Martinez Canillas
0 siblings, 0 replies; 241+ messages in thread
From: Javier Martinez Canillas @ 2022-02-01 14:01 UTC (permalink / raw)
To: Daniel Vetter, DRI Development
Cc: linux-fbdev, Thomas Zimmermann, Sam Ravnborg, Daniel Vetter,
Dave Airlie, Intel Graphics Development, LKML, Tomi Valkeinen,
Gerd Hoffmann, Pavel Machek, Greg Kroah-Hartman,
Geert Uytterhoeven, Linus Torvalds, Sven Schnelle
On 1/31/22 22:05, Daniel Vetter wrote:
> Ever since Tomi extracted the core code in 2014 it's been defacto me
> maintaining this, with help from others from dri-devel and sometimes
> Linus (but those are mostly merge conflicts):
>
> $ git shortlog -ns drivers/video/fbdev/core/ | head -n5
> 35 Daniel Vetter
> 23 Linus Torvalds
> 10 Hans de Goede
> 9 Dave Airlie
> 6 Peter Rosin
>
> I think ideally we'd also record that the various firmware fb drivers
> (efifb, vesafb, ...) are also maintained in drm-misc because for the
> past few years the patches have either been to fix handover issues
> with drm drivers, or caused handover issues with drm drivers. So any
> other tree just doesn't make sense. But also, there's plenty of
> outdated MAINTAINER entries for these with people and git trees that
> haven't been active in years, so maybe let's just leave them alone.
> And furthermore distros are now adopting simpledrm as the firmware fb
> driver, so hopefully the need to care about the fbdev firmware drivers
> will go down going forward.
>
> Note that drm-misc is group maintained, I expect that to continue like
> we've done before, so no new expectations that patches all go through
> my hands. That would be silly. This also means I'm happy to put any
> other volunteer's name in the M: line, but otherwise git log says I'm
> the one who's stuck with this.
>
> Cc: Dave Airlie <airlied@gmail.com>
> Cc: Jani Nikula <jani.nikula@linux.intel.com>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: Linux Fbdev development list <linux-fbdev@vger.kernel.org>
> Cc: Pavel Machek <pavel@ucw.cz>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Javier Martinez Canillas <javierm@redhat.com>
> Cc: DRI Development <dri-devel@lists.freedesktop.org>
> Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
> Cc: Claudio Suarez <cssk@net-c.es>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Cc: Geert Uytterhoeven <geert@linux-m68k.org>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Sven Schnelle <svens@stackframe.org>
> Cc: Gerd Hoffmann <kraxel@redhat.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> ---
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Best regards,
--
Javier Martinez Canillas
Linux Engineering
Red Hat
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 01/21] MAINTAINERS: Add entry for fbdev core
2022-01-31 21:05 ` Daniel Vetter
(?)
@ 2022-02-01 14:47 ` Jani Nikula
-1 siblings, 0 replies; 241+ messages in thread
From: Jani Nikula @ 2022-02-01 14:47 UTC (permalink / raw)
To: Daniel Vetter, DRI Development
Cc: Intel Graphics Development, linux-fbdev, LKML, Daniel Vetter,
Dave Airlie, Linus Torvalds, Pavel Machek, Sam Ravnborg,
Greg Kroah-Hartman, Javier Martinez Canillas, Claudio Suarez,
Tomi Valkeinen, Geert Uytterhoeven, Thomas Zimmermann,
Daniel Vetter, Sven Schnelle, Gerd Hoffmann
On Mon, 31 Jan 2022, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> Ever since Tomi extracted the core code in 2014 it's been defacto me
> maintaining this, with help from others from dri-devel and sometimes
> Linus (but those are mostly merge conflicts):
>
> $ git shortlog -ns drivers/video/fbdev/core/ | head -n5
> 35 Daniel Vetter
> 23 Linus Torvalds
> 10 Hans de Goede
> 9 Dave Airlie
> 6 Peter Rosin
>
> I think ideally we'd also record that the various firmware fb drivers
> (efifb, vesafb, ...) are also maintained in drm-misc because for the
> past few years the patches have either been to fix handover issues
> with drm drivers, or caused handover issues with drm drivers. So any
> other tree just doesn't make sense. But also, there's plenty of
> outdated MAINTAINER entries for these with people and git trees that
> haven't been active in years, so maybe let's just leave them alone.
> And furthermore distros are now adopting simpledrm as the firmware fb
> driver, so hopefully the need to care about the fbdev firmware drivers
> will go down going forward.
>
> Note that drm-misc is group maintained, I expect that to continue like
> we've done before, so no new expectations that patches all go through
> my hands. That would be silly. This also means I'm happy to put any
> other volunteer's name in the M: line, but otherwise git log says I'm
> the one who's stuck with this.
>
> Cc: Dave Airlie <airlied@gmail.com>
> Cc: Jani Nikula <jani.nikula@linux.intel.com>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: Linux Fbdev development list <linux-fbdev@vger.kernel.org>
> Cc: Pavel Machek <pavel@ucw.cz>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Javier Martinez Canillas <javierm@redhat.com>
> Cc: DRI Development <dri-devel@lists.freedesktop.org>
> Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
> Cc: Claudio Suarez <cssk@net-c.es>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Cc: Geert Uytterhoeven <geert@linux-m68k.org>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Sven Schnelle <svens@stackframe.org>
> Cc: Gerd Hoffmann <kraxel@redhat.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
> ---
> MAINTAINERS | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index ea3e6c914384..49809eaa3096 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -7573,6 +7573,12 @@ S: Maintained
> W: http://floatingpoint.sourceforge.net/emulator/index.html
> F: arch/x86/math-emu/
>
> +FRAMEBUFFER CORE
> +M: Daniel Vetter <daniel@ffwll.ch>
> +F: drivers/video/fbdev/core/
> +S: Odd Fixes
> +T: git git://anongit.freedesktop.org/drm/drm-misc
> +
> FRAMEBUFFER LAYER
> M: Helge Deller <deller@gmx.de>
> L: linux-fbdev@vger.kernel.org
--
Jani Nikula, Intel Open Source Graphics Center
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [Intel-gfx] [PATCH 01/21] MAINTAINERS: Add entry for fbdev core
@ 2022-02-01 14:47 ` Jani Nikula
0 siblings, 0 replies; 241+ messages in thread
From: Jani Nikula @ 2022-02-01 14:47 UTC (permalink / raw)
To: Daniel Vetter, DRI Development
Cc: linux-fbdev, Thomas Zimmermann, Sam Ravnborg, Daniel Vetter,
Daniel Vetter, Intel Graphics Development, LKML,
Javier Martinez Canillas, Tomi Valkeinen, Gerd Hoffmann,
Pavel Machek, Greg Kroah-Hartman, Geert Uytterhoeven,
Dave Airlie, Linus Torvalds, Sven Schnelle
On Mon, 31 Jan 2022, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> Ever since Tomi extracted the core code in 2014 it's been defacto me
> maintaining this, with help from others from dri-devel and sometimes
> Linus (but those are mostly merge conflicts):
>
> $ git shortlog -ns drivers/video/fbdev/core/ | head -n5
> 35 Daniel Vetter
> 23 Linus Torvalds
> 10 Hans de Goede
> 9 Dave Airlie
> 6 Peter Rosin
>
> I think ideally we'd also record that the various firmware fb drivers
> (efifb, vesafb, ...) are also maintained in drm-misc because for the
> past few years the patches have either been to fix handover issues
> with drm drivers, or caused handover issues with drm drivers. So any
> other tree just doesn't make sense. But also, there's plenty of
> outdated MAINTAINER entries for these with people and git trees that
> haven't been active in years, so maybe let's just leave them alone.
> And furthermore distros are now adopting simpledrm as the firmware fb
> driver, so hopefully the need to care about the fbdev firmware drivers
> will go down going forward.
>
> Note that drm-misc is group maintained, I expect that to continue like
> we've done before, so no new expectations that patches all go through
> my hands. That would be silly. This also means I'm happy to put any
> other volunteer's name in the M: line, but otherwise git log says I'm
> the one who's stuck with this.
>
> Cc: Dave Airlie <airlied@gmail.com>
> Cc: Jani Nikula <jani.nikula@linux.intel.com>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: Linux Fbdev development list <linux-fbdev@vger.kernel.org>
> Cc: Pavel Machek <pavel@ucw.cz>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Javier Martinez Canillas <javierm@redhat.com>
> Cc: DRI Development <dri-devel@lists.freedesktop.org>
> Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
> Cc: Claudio Suarez <cssk@net-c.es>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Cc: Geert Uytterhoeven <geert@linux-m68k.org>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Sven Schnelle <svens@stackframe.org>
> Cc: Gerd Hoffmann <kraxel@redhat.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
> ---
> MAINTAINERS | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index ea3e6c914384..49809eaa3096 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -7573,6 +7573,12 @@ S: Maintained
> W: http://floatingpoint.sourceforge.net/emulator/index.html
> F: arch/x86/math-emu/
>
> +FRAMEBUFFER CORE
> +M: Daniel Vetter <daniel@ffwll.ch>
> +F: drivers/video/fbdev/core/
> +S: Odd Fixes
> +T: git git://anongit.freedesktop.org/drm/drm-misc
> +
> FRAMEBUFFER LAYER
> M: Helge Deller <deller@gmx.de>
> L: linux-fbdev@vger.kernel.org
--
Jani Nikula, Intel Open Source Graphics Center
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 01/21] MAINTAINERS: Add entry for fbdev core
@ 2022-02-01 14:47 ` Jani Nikula
0 siblings, 0 replies; 241+ messages in thread
From: Jani Nikula @ 2022-02-01 14:47 UTC (permalink / raw)
To: Daniel Vetter, DRI Development
Cc: linux-fbdev, Thomas Zimmermann, Sam Ravnborg, Daniel Vetter,
Daniel Vetter, Intel Graphics Development, LKML,
Javier Martinez Canillas, Tomi Valkeinen, Claudio Suarez,
Gerd Hoffmann, Pavel Machek, Greg Kroah-Hartman,
Geert Uytterhoeven, Linus Torvalds, Sven Schnelle
On Mon, 31 Jan 2022, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> Ever since Tomi extracted the core code in 2014 it's been defacto me
> maintaining this, with help from others from dri-devel and sometimes
> Linus (but those are mostly merge conflicts):
>
> $ git shortlog -ns drivers/video/fbdev/core/ | head -n5
> 35 Daniel Vetter
> 23 Linus Torvalds
> 10 Hans de Goede
> 9 Dave Airlie
> 6 Peter Rosin
>
> I think ideally we'd also record that the various firmware fb drivers
> (efifb, vesafb, ...) are also maintained in drm-misc because for the
> past few years the patches have either been to fix handover issues
> with drm drivers, or caused handover issues with drm drivers. So any
> other tree just doesn't make sense. But also, there's plenty of
> outdated MAINTAINER entries for these with people and git trees that
> haven't been active in years, so maybe let's just leave them alone.
> And furthermore distros are now adopting simpledrm as the firmware fb
> driver, so hopefully the need to care about the fbdev firmware drivers
> will go down going forward.
>
> Note that drm-misc is group maintained, I expect that to continue like
> we've done before, so no new expectations that patches all go through
> my hands. That would be silly. This also means I'm happy to put any
> other volunteer's name in the M: line, but otherwise git log says I'm
> the one who's stuck with this.
>
> Cc: Dave Airlie <airlied@gmail.com>
> Cc: Jani Nikula <jani.nikula@linux.intel.com>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: Linux Fbdev development list <linux-fbdev@vger.kernel.org>
> Cc: Pavel Machek <pavel@ucw.cz>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Javier Martinez Canillas <javierm@redhat.com>
> Cc: DRI Development <dri-devel@lists.freedesktop.org>
> Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
> Cc: Claudio Suarez <cssk@net-c.es>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Cc: Geert Uytterhoeven <geert@linux-m68k.org>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Sven Schnelle <svens@stackframe.org>
> Cc: Gerd Hoffmann <kraxel@redhat.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
> ---
> MAINTAINERS | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index ea3e6c914384..49809eaa3096 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -7573,6 +7573,12 @@ S: Maintained
> W: http://floatingpoint.sourceforge.net/emulator/index.html
> F: arch/x86/math-emu/
>
> +FRAMEBUFFER CORE
> +M: Daniel Vetter <daniel@ffwll.ch>
> +F: drivers/video/fbdev/core/
> +S: Odd Fixes
> +T: git git://anongit.freedesktop.org/drm/drm-misc
> +
> FRAMEBUFFER LAYER
> M: Helge Deller <deller@gmx.de>
> L: linux-fbdev@vger.kernel.org
--
Jani Nikula, Intel Open Source Graphics Center
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 03/21] fbcon: Restore fbcon scrolling acceleration
2022-02-01 13:45 ` Daniel Vetter
(?)
@ 2022-02-01 14:52 ` Helge Deller
-1 siblings, 0 replies; 241+ messages in thread
From: Helge Deller @ 2022-02-01 14:52 UTC (permalink / raw)
To: Daniel Vetter
Cc: DRI Development, Intel Graphics Development, linux-fbdev, LKML,
stable, Claudio Suarez, Dave Airlie, Jani Nikula, Linus Torvalds,
Pavel Machek, Sam Ravnborg, Greg Kroah-Hartman,
Javier Martinez Canillas, Tomi Valkeinen, Geert Uytterhoeven,
Thomas Zimmermann, Daniel Vetter, Sven Schnelle, Gerd Hoffmann
On 2/1/22 14:45, Daniel Vetter wrote:
> On Tue, Feb 1, 2022 at 12:01 PM Helge Deller <deller@gmx.de> wrote:
>> On 2/1/22 11:36, Daniel Vetter wrote:
>>> On Tue, Feb 1, 2022 at 11:16 AM Helge Deller <deller@gmx.de> wrote:
>>>>
>>>> On 1/31/22 22:05, Daniel Vetter wrote:
>>>>> This functionally undoes 39aead8373b3 ("fbcon: Disable accelerated
>>>>> scrolling"), but behind the FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
>>>>> option.
>>>>
>>>> you have two trivial copy-n-paste errors in this patch which still prevent the
>>>> console acceleration.
>>>
>>> Duh :-(
>>>
>>> But before we dig into details I think the big picture would be
>>> better. I honestly don't like the #ifdef pile here that much.
>>
>> Me neither.
>> The ifdefs give a better separation, but prevents that the compiler
>> checks the various paths when building.
>>
>>> I wonder whether your approach, also with GETVX/YRES adjusted
>>> somehow, wouldn't look cleaner?
>> I think so.
>> You wouldn't even need to touch GETVX/YRES because the compiler
>> will optimize/reduce it from
>>
>> #define GETVYRES(s,i) ({ \
>> (s == SCROLL_REDRAW || s == SCROLL_MOVE) ? \
>> (i)->var.yres : (i)->var.yres_virtual; })
>>
>> to just become:
>>
>> #define GETVYRES(s,i) ((i)->var.yres)
>
> Yeah, but you need to roll out your helper to all the callsites. But
> since you #ifdef out info->scrollmode we should catch them all I
> guess.
Right. That was the only reason why I ifdef'ed it out.
Technically we don't need that ifdef.
>>> Like I said in the cover letter I got mostly distracted with fbcon
>>> locking last week, not really with this one here at all, so maybe
>>> going with your 4 (or 2 if we squash them like I did here) patches is
>>> neater?
>>
>> The benefit of my patch series was, that it could be easily backported first,
>> and then cleaned up afterwards. Even a small additional backport patch to disable
>> the fbcon acceleration for DRM in the old releases would be easy.
>> But I'm not insisting on backporting the patches, if we find good way forward.
>>
>> So, either with the 4 (or 2) patches would be OK for me (or even your approach).
>
> The idea behind the squash was that it's then impossible to backport
> without the Kconfig,
Yes, my proposal was to simply revert the 2 patches and immediatly send
the Kconfig patch to disable it again.
> and so we'll only enable this code when people
> intentionally want it. Maybe I'm too paranoid?
I think you are too paranoid :-)
If all patches incl. the Kconfig patch are backported then people shouldn't
do it wrong.
> Anyway, you feel like finishing off your approach? Or should I send
> out v2 of this with the issues fixed you spotted? Like I said either
> is fine with me.
Ok, then let me try to finish my approach until tomorrow, and then you
check if you can and want to add your locking and other patches on top of it.
In the end I leave the decision which approach to take to you.
Ok?
Helge
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 03/21] fbcon: Restore fbcon scrolling acceleration
@ 2022-02-01 14:52 ` Helge Deller
0 siblings, 0 replies; 241+ messages in thread
From: Helge Deller @ 2022-02-01 14:52 UTC (permalink / raw)
To: Daniel Vetter
Cc: linux-fbdev, Thomas Zimmermann, Sam Ravnborg, Daniel Vetter,
Linus Torvalds, Intel Graphics Development, LKML, stable,
Javier Martinez Canillas, Tomi Valkeinen, Claudio Suarez,
DRI Development, Pavel Machek, Greg Kroah-Hartman,
Geert Uytterhoeven, Sven Schnelle, Gerd Hoffmann
On 2/1/22 14:45, Daniel Vetter wrote:
> On Tue, Feb 1, 2022 at 12:01 PM Helge Deller <deller@gmx.de> wrote:
>> On 2/1/22 11:36, Daniel Vetter wrote:
>>> On Tue, Feb 1, 2022 at 11:16 AM Helge Deller <deller@gmx.de> wrote:
>>>>
>>>> On 1/31/22 22:05, Daniel Vetter wrote:
>>>>> This functionally undoes 39aead8373b3 ("fbcon: Disable accelerated
>>>>> scrolling"), but behind the FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
>>>>> option.
>>>>
>>>> you have two trivial copy-n-paste errors in this patch which still prevent the
>>>> console acceleration.
>>>
>>> Duh :-(
>>>
>>> But before we dig into details I think the big picture would be
>>> better. I honestly don't like the #ifdef pile here that much.
>>
>> Me neither.
>> The ifdefs give a better separation, but prevents that the compiler
>> checks the various paths when building.
>>
>>> I wonder whether your approach, also with GETVX/YRES adjusted
>>> somehow, wouldn't look cleaner?
>> I think so.
>> You wouldn't even need to touch GETVX/YRES because the compiler
>> will optimize/reduce it from
>>
>> #define GETVYRES(s,i) ({ \
>> (s == SCROLL_REDRAW || s == SCROLL_MOVE) ? \
>> (i)->var.yres : (i)->var.yres_virtual; })
>>
>> to just become:
>>
>> #define GETVYRES(s,i) ((i)->var.yres)
>
> Yeah, but you need to roll out your helper to all the callsites. But
> since you #ifdef out info->scrollmode we should catch them all I
> guess.
Right. That was the only reason why I ifdef'ed it out.
Technically we don't need that ifdef.
>>> Like I said in the cover letter I got mostly distracted with fbcon
>>> locking last week, not really with this one here at all, so maybe
>>> going with your 4 (or 2 if we squash them like I did here) patches is
>>> neater?
>>
>> The benefit of my patch series was, that it could be easily backported first,
>> and then cleaned up afterwards. Even a small additional backport patch to disable
>> the fbcon acceleration for DRM in the old releases would be easy.
>> But I'm not insisting on backporting the patches, if we find good way forward.
>>
>> So, either with the 4 (or 2) patches would be OK for me (or even your approach).
>
> The idea behind the squash was that it's then impossible to backport
> without the Kconfig,
Yes, my proposal was to simply revert the 2 patches and immediatly send
the Kconfig patch to disable it again.
> and so we'll only enable this code when people
> intentionally want it. Maybe I'm too paranoid?
I think you are too paranoid :-)
If all patches incl. the Kconfig patch are backported then people shouldn't
do it wrong.
> Anyway, you feel like finishing off your approach? Or should I send
> out v2 of this with the issues fixed you spotted? Like I said either
> is fine with me.
Ok, then let me try to finish my approach until tomorrow, and then you
check if you can and want to add your locking and other patches on top of it.
In the end I leave the decision which approach to take to you.
Ok?
Helge
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [Intel-gfx] [PATCH 03/21] fbcon: Restore fbcon scrolling acceleration
@ 2022-02-01 14:52 ` Helge Deller
0 siblings, 0 replies; 241+ messages in thread
From: Helge Deller @ 2022-02-01 14:52 UTC (permalink / raw)
To: Daniel Vetter
Cc: linux-fbdev, Thomas Zimmermann, Sam Ravnborg, Daniel Vetter,
Linus Torvalds, Intel Graphics Development, LKML, stable,
Javier Martinez Canillas, Tomi Valkeinen, DRI Development,
Pavel Machek, Greg Kroah-Hartman, Geert Uytterhoeven,
Dave Airlie, Sven Schnelle, Gerd Hoffmann
On 2/1/22 14:45, Daniel Vetter wrote:
> On Tue, Feb 1, 2022 at 12:01 PM Helge Deller <deller@gmx.de> wrote:
>> On 2/1/22 11:36, Daniel Vetter wrote:
>>> On Tue, Feb 1, 2022 at 11:16 AM Helge Deller <deller@gmx.de> wrote:
>>>>
>>>> On 1/31/22 22:05, Daniel Vetter wrote:
>>>>> This functionally undoes 39aead8373b3 ("fbcon: Disable accelerated
>>>>> scrolling"), but behind the FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
>>>>> option.
>>>>
>>>> you have two trivial copy-n-paste errors in this patch which still prevent the
>>>> console acceleration.
>>>
>>> Duh :-(
>>>
>>> But before we dig into details I think the big picture would be
>>> better. I honestly don't like the #ifdef pile here that much.
>>
>> Me neither.
>> The ifdefs give a better separation, but prevents that the compiler
>> checks the various paths when building.
>>
>>> I wonder whether your approach, also with GETVX/YRES adjusted
>>> somehow, wouldn't look cleaner?
>> I think so.
>> You wouldn't even need to touch GETVX/YRES because the compiler
>> will optimize/reduce it from
>>
>> #define GETVYRES(s,i) ({ \
>> (s == SCROLL_REDRAW || s == SCROLL_MOVE) ? \
>> (i)->var.yres : (i)->var.yres_virtual; })
>>
>> to just become:
>>
>> #define GETVYRES(s,i) ((i)->var.yres)
>
> Yeah, but you need to roll out your helper to all the callsites. But
> since you #ifdef out info->scrollmode we should catch them all I
> guess.
Right. That was the only reason why I ifdef'ed it out.
Technically we don't need that ifdef.
>>> Like I said in the cover letter I got mostly distracted with fbcon
>>> locking last week, not really with this one here at all, so maybe
>>> going with your 4 (or 2 if we squash them like I did here) patches is
>>> neater?
>>
>> The benefit of my patch series was, that it could be easily backported first,
>> and then cleaned up afterwards. Even a small additional backport patch to disable
>> the fbcon acceleration for DRM in the old releases would be easy.
>> But I'm not insisting on backporting the patches, if we find good way forward.
>>
>> So, either with the 4 (or 2) patches would be OK for me (or even your approach).
>
> The idea behind the squash was that it's then impossible to backport
> without the Kconfig,
Yes, my proposal was to simply revert the 2 patches and immediatly send
the Kconfig patch to disable it again.
> and so we'll only enable this code when people
> intentionally want it. Maybe I'm too paranoid?
I think you are too paranoid :-)
If all patches incl. the Kconfig patch are backported then people shouldn't
do it wrong.
> Anyway, you feel like finishing off your approach? Or should I send
> out v2 of this with the issues fixed you spotted? Like I said either
> is fine with me.
Ok, then let me try to finish my approach until tomorrow, and then you
check if you can and want to add your locking and other patches on top of it.
In the end I leave the decision which approach to take to you.
Ok?
Helge
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 01/21] MAINTAINERS: Add entry for fbdev core
2022-01-31 21:05 ` Daniel Vetter
(?)
@ 2022-02-01 14:54 ` Geert Uytterhoeven
-1 siblings, 0 replies; 241+ messages in thread
From: Geert Uytterhoeven @ 2022-02-01 14:54 UTC (permalink / raw)
To: Daniel Vetter
Cc: DRI Development, Intel Graphics Development,
Linux Fbdev development list, LKML, Dave Airlie, Jani Nikula,
Linus Torvalds, Pavel Machek, Sam Ravnborg, Greg Kroah-Hartman,
Javier Martinez Canillas, Claudio Suarez, Tomi Valkeinen,
Thomas Zimmermann, Daniel Vetter, Sven Schnelle, Gerd Hoffmann
On Mon, Jan 31, 2022 at 10:06 PM Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> Ever since Tomi extracted the core code in 2014 it's been defacto me
> maintaining this, with help from others from dri-devel and sometimes
> Linus (but those are mostly merge conflicts):
>
> $ git shortlog -ns drivers/video/fbdev/core/ | head -n5
> 35 Daniel Vetter
> 23 Linus Torvalds
> 10 Hans de Goede
> 9 Dave Airlie
> 6 Peter Rosin
>
> I think ideally we'd also record that the various firmware fb drivers
> (efifb, vesafb, ...) are also maintained in drm-misc because for the
> past few years the patches have either been to fix handover issues
> with drm drivers, or caused handover issues with drm drivers. So any
> other tree just doesn't make sense. But also, there's plenty of
> outdated MAINTAINER entries for these with people and git trees that
> haven't been active in years, so maybe let's just leave them alone.
> And furthermore distros are now adopting simpledrm as the firmware fb
> driver, so hopefully the need to care about the fbdev firmware drivers
> will go down going forward.
>
> Note that drm-misc is group maintained, I expect that to continue like
> we've done before, so no new expectations that patches all go through
> my hands. That would be silly. This also means I'm happy to put any
> other volunteer's name in the M: line, but otherwise git log says I'm
> the one who's stuck with this.
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
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
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 01/21] MAINTAINERS: Add entry for fbdev core
@ 2022-02-01 14:54 ` Geert Uytterhoeven
0 siblings, 0 replies; 241+ messages in thread
From: Geert Uytterhoeven @ 2022-02-01 14:54 UTC (permalink / raw)
To: Daniel Vetter
Cc: Linux Fbdev development list, Thomas Zimmermann, Sam Ravnborg,
Linus Torvalds, Intel Graphics Development, LKML,
Javier Martinez Canillas, Tomi Valkeinen, Claudio Suarez,
DRI Development, Pavel Machek, Greg Kroah-Hartman, Daniel Vetter,
Sven Schnelle, Gerd Hoffmann
On Mon, Jan 31, 2022 at 10:06 PM Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> Ever since Tomi extracted the core code in 2014 it's been defacto me
> maintaining this, with help from others from dri-devel and sometimes
> Linus (but those are mostly merge conflicts):
>
> $ git shortlog -ns drivers/video/fbdev/core/ | head -n5
> 35 Daniel Vetter
> 23 Linus Torvalds
> 10 Hans de Goede
> 9 Dave Airlie
> 6 Peter Rosin
>
> I think ideally we'd also record that the various firmware fb drivers
> (efifb, vesafb, ...) are also maintained in drm-misc because for the
> past few years the patches have either been to fix handover issues
> with drm drivers, or caused handover issues with drm drivers. So any
> other tree just doesn't make sense. But also, there's plenty of
> outdated MAINTAINER entries for these with people and git trees that
> haven't been active in years, so maybe let's just leave them alone.
> And furthermore distros are now adopting simpledrm as the firmware fb
> driver, so hopefully the need to care about the fbdev firmware drivers
> will go down going forward.
>
> Note that drm-misc is group maintained, I expect that to continue like
> we've done before, so no new expectations that patches all go through
> my hands. That would be silly. This also means I'm happy to put any
> other volunteer's name in the M: line, but otherwise git log says I'm
> the one who's stuck with this.
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
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
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [Intel-gfx] [PATCH 01/21] MAINTAINERS: Add entry for fbdev core
@ 2022-02-01 14:54 ` Geert Uytterhoeven
0 siblings, 0 replies; 241+ messages in thread
From: Geert Uytterhoeven @ 2022-02-01 14:54 UTC (permalink / raw)
To: Daniel Vetter
Cc: Linux Fbdev development list, Thomas Zimmermann, Sam Ravnborg,
Linus Torvalds, Intel Graphics Development, LKML,
Javier Martinez Canillas, Tomi Valkeinen, DRI Development,
Pavel Machek, Greg Kroah-Hartman, Daniel Vetter, Dave Airlie,
Sven Schnelle, Gerd Hoffmann
On Mon, Jan 31, 2022 at 10:06 PM Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> Ever since Tomi extracted the core code in 2014 it's been defacto me
> maintaining this, with help from others from dri-devel and sometimes
> Linus (but those are mostly merge conflicts):
>
> $ git shortlog -ns drivers/video/fbdev/core/ | head -n5
> 35 Daniel Vetter
> 23 Linus Torvalds
> 10 Hans de Goede
> 9 Dave Airlie
> 6 Peter Rosin
>
> I think ideally we'd also record that the various firmware fb drivers
> (efifb, vesafb, ...) are also maintained in drm-misc because for the
> past few years the patches have either been to fix handover issues
> with drm drivers, or caused handover issues with drm drivers. So any
> other tree just doesn't make sense. But also, there's plenty of
> outdated MAINTAINER entries for these with people and git trees that
> haven't been active in years, so maybe let's just leave them alone.
> And furthermore distros are now adopting simpledrm as the firmware fb
> driver, so hopefully the need to care about the fbdev firmware drivers
> will go down going forward.
>
> Note that drm-misc is group maintained, I expect that to continue like
> we've done before, so no new expectations that patches all go through
> my hands. That would be silly. This also means I'm happy to put any
> other volunteer's name in the M: line, but otherwise git log says I'm
> the one who's stuck with this.
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
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
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 03/21] fbcon: Restore fbcon scrolling acceleration
2022-02-01 14:52 ` Helge Deller
(?)
@ 2022-02-01 16:30 ` Daniel Vetter
-1 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-02-01 16:30 UTC (permalink / raw)
To: Helge Deller
Cc: DRI Development, Intel Graphics Development, linux-fbdev, LKML,
stable, Claudio Suarez, Dave Airlie, Jani Nikula, Linus Torvalds,
Pavel Machek, Sam Ravnborg, Greg Kroah-Hartman,
Javier Martinez Canillas, Tomi Valkeinen, Geert Uytterhoeven,
Thomas Zimmermann, Daniel Vetter, Sven Schnelle, Gerd Hoffmann
On Tue, Feb 1, 2022 at 3:52 PM Helge Deller <deller@gmx.de> wrote:
>
> On 2/1/22 14:45, Daniel Vetter wrote:
> > On Tue, Feb 1, 2022 at 12:01 PM Helge Deller <deller@gmx.de> wrote:
> >> On 2/1/22 11:36, Daniel Vetter wrote:
> >>> On Tue, Feb 1, 2022 at 11:16 AM Helge Deller <deller@gmx.de> wrote:
> >>>>
> >>>> On 1/31/22 22:05, Daniel Vetter wrote:
> >>>>> This functionally undoes 39aead8373b3 ("fbcon: Disable accelerated
> >>>>> scrolling"), but behind the FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
> >>>>> option.
> >>>>
> >>>> you have two trivial copy-n-paste errors in this patch which still prevent the
> >>>> console acceleration.
> >>>
> >>> Duh :-(
> >>>
> >>> But before we dig into details I think the big picture would be
> >>> better. I honestly don't like the #ifdef pile here that much.
> >>
> >> Me neither.
> >> The ifdefs give a better separation, but prevents that the compiler
> >> checks the various paths when building.
> >>
> >>> I wonder whether your approach, also with GETVX/YRES adjusted
> >>> somehow, wouldn't look cleaner?
> >> I think so.
> >> You wouldn't even need to touch GETVX/YRES because the compiler
> >> will optimize/reduce it from
> >>
> >> #define GETVYRES(s,i) ({ \
> >> (s == SCROLL_REDRAW || s == SCROLL_MOVE) ? \
> >> (i)->var.yres : (i)->var.yres_virtual; })
> >>
> >> to just become:
> >>
> >> #define GETVYRES(s,i) ((i)->var.yres)
> >
> > Yeah, but you need to roll out your helper to all the callsites. But
> > since you #ifdef out info->scrollmode we should catch them all I
> > guess.
>
> Right. That was the only reason why I ifdef'ed it out.
> Technically we don't need that ifdef.
>
> >>> Like I said in the cover letter I got mostly distracted with fbcon
> >>> locking last week, not really with this one here at all, so maybe
> >>> going with your 4 (or 2 if we squash them like I did here) patches is
> >>> neater?
> >>
> >> The benefit of my patch series was, that it could be easily backported first,
> >> and then cleaned up afterwards. Even a small additional backport patch to disable
> >> the fbcon acceleration for DRM in the old releases would be easy.
> >> But I'm not insisting on backporting the patches, if we find good way forward.
> >>
> >> So, either with the 4 (or 2) patches would be OK for me (or even your approach).
> >
> > The idea behind the squash was that it's then impossible to backport
> > without the Kconfig,
>
> Yes, my proposal was to simply revert the 2 patches and immediatly send
> the Kconfig patch to disable it again.
>
> > and so we'll only enable this code when people
> > intentionally want it. Maybe I'm too paranoid?
>
> I think you are too paranoid :-)
> If all patches incl. the Kconfig patch are backported then people shouldn't
> do it wrong.
>
> > Anyway, you feel like finishing off your approach? Or should I send
> > out v2 of this with the issues fixed you spotted? Like I said either
> > is fine with me.
>
> Ok, then let me try to finish my approach until tomorrow, and then you
> check if you can and want to add your locking and other patches on top of it.
> In the end I leave the decision which approach to take to you.
> Ok?
Sounds good, and yeah rough idea is that the maintainers + revert +
Kconfig should go in for rc3 or rc4 if we hit another bump, and the
locking stuff then in for -next (since it needs a backmerge and is
defo tricky stuff).
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 03/21] fbcon: Restore fbcon scrolling acceleration
@ 2022-02-01 16:30 ` Daniel Vetter
0 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-02-01 16:30 UTC (permalink / raw)
To: Helge Deller
Cc: linux-fbdev, Thomas Zimmermann, Sam Ravnborg, Daniel Vetter,
Linus Torvalds, Intel Graphics Development, LKML, stable,
Javier Martinez Canillas, Tomi Valkeinen, Claudio Suarez,
DRI Development, Pavel Machek, Greg Kroah-Hartman,
Geert Uytterhoeven, Sven Schnelle, Gerd Hoffmann
On Tue, Feb 1, 2022 at 3:52 PM Helge Deller <deller@gmx.de> wrote:
>
> On 2/1/22 14:45, Daniel Vetter wrote:
> > On Tue, Feb 1, 2022 at 12:01 PM Helge Deller <deller@gmx.de> wrote:
> >> On 2/1/22 11:36, Daniel Vetter wrote:
> >>> On Tue, Feb 1, 2022 at 11:16 AM Helge Deller <deller@gmx.de> wrote:
> >>>>
> >>>> On 1/31/22 22:05, Daniel Vetter wrote:
> >>>>> This functionally undoes 39aead8373b3 ("fbcon: Disable accelerated
> >>>>> scrolling"), but behind the FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
> >>>>> option.
> >>>>
> >>>> you have two trivial copy-n-paste errors in this patch which still prevent the
> >>>> console acceleration.
> >>>
> >>> Duh :-(
> >>>
> >>> But before we dig into details I think the big picture would be
> >>> better. I honestly don't like the #ifdef pile here that much.
> >>
> >> Me neither.
> >> The ifdefs give a better separation, but prevents that the compiler
> >> checks the various paths when building.
> >>
> >>> I wonder whether your approach, also with GETVX/YRES adjusted
> >>> somehow, wouldn't look cleaner?
> >> I think so.
> >> You wouldn't even need to touch GETVX/YRES because the compiler
> >> will optimize/reduce it from
> >>
> >> #define GETVYRES(s,i) ({ \
> >> (s == SCROLL_REDRAW || s == SCROLL_MOVE) ? \
> >> (i)->var.yres : (i)->var.yres_virtual; })
> >>
> >> to just become:
> >>
> >> #define GETVYRES(s,i) ((i)->var.yres)
> >
> > Yeah, but you need to roll out your helper to all the callsites. But
> > since you #ifdef out info->scrollmode we should catch them all I
> > guess.
>
> Right. That was the only reason why I ifdef'ed it out.
> Technically we don't need that ifdef.
>
> >>> Like I said in the cover letter I got mostly distracted with fbcon
> >>> locking last week, not really with this one here at all, so maybe
> >>> going with your 4 (or 2 if we squash them like I did here) patches is
> >>> neater?
> >>
> >> The benefit of my patch series was, that it could be easily backported first,
> >> and then cleaned up afterwards. Even a small additional backport patch to disable
> >> the fbcon acceleration for DRM in the old releases would be easy.
> >> But I'm not insisting on backporting the patches, if we find good way forward.
> >>
> >> So, either with the 4 (or 2) patches would be OK for me (or even your approach).
> >
> > The idea behind the squash was that it's then impossible to backport
> > without the Kconfig,
>
> Yes, my proposal was to simply revert the 2 patches and immediatly send
> the Kconfig patch to disable it again.
>
> > and so we'll only enable this code when people
> > intentionally want it. Maybe I'm too paranoid?
>
> I think you are too paranoid :-)
> If all patches incl. the Kconfig patch are backported then people shouldn't
> do it wrong.
>
> > Anyway, you feel like finishing off your approach? Or should I send
> > out v2 of this with the issues fixed you spotted? Like I said either
> > is fine with me.
>
> Ok, then let me try to finish my approach until tomorrow, and then you
> check if you can and want to add your locking and other patches on top of it.
> In the end I leave the decision which approach to take to you.
> Ok?
Sounds good, and yeah rough idea is that the maintainers + revert +
Kconfig should go in for rc3 or rc4 if we hit another bump, and the
locking stuff then in for -next (since it needs a backmerge and is
defo tricky stuff).
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [Intel-gfx] [PATCH 03/21] fbcon: Restore fbcon scrolling acceleration
@ 2022-02-01 16:30 ` Daniel Vetter
0 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-02-01 16:30 UTC (permalink / raw)
To: Helge Deller
Cc: linux-fbdev, Thomas Zimmermann, Sam Ravnborg, Daniel Vetter,
Linus Torvalds, Intel Graphics Development, LKML, stable,
Javier Martinez Canillas, Tomi Valkeinen, DRI Development,
Pavel Machek, Greg Kroah-Hartman, Geert Uytterhoeven,
Dave Airlie, Sven Schnelle, Gerd Hoffmann
On Tue, Feb 1, 2022 at 3:52 PM Helge Deller <deller@gmx.de> wrote:
>
> On 2/1/22 14:45, Daniel Vetter wrote:
> > On Tue, Feb 1, 2022 at 12:01 PM Helge Deller <deller@gmx.de> wrote:
> >> On 2/1/22 11:36, Daniel Vetter wrote:
> >>> On Tue, Feb 1, 2022 at 11:16 AM Helge Deller <deller@gmx.de> wrote:
> >>>>
> >>>> On 1/31/22 22:05, Daniel Vetter wrote:
> >>>>> This functionally undoes 39aead8373b3 ("fbcon: Disable accelerated
> >>>>> scrolling"), but behind the FRAMEBUFFER_CONSOLE_LEGACY_ACCELERATION
> >>>>> option.
> >>>>
> >>>> you have two trivial copy-n-paste errors in this patch which still prevent the
> >>>> console acceleration.
> >>>
> >>> Duh :-(
> >>>
> >>> But before we dig into details I think the big picture would be
> >>> better. I honestly don't like the #ifdef pile here that much.
> >>
> >> Me neither.
> >> The ifdefs give a better separation, but prevents that the compiler
> >> checks the various paths when building.
> >>
> >>> I wonder whether your approach, also with GETVX/YRES adjusted
> >>> somehow, wouldn't look cleaner?
> >> I think so.
> >> You wouldn't even need to touch GETVX/YRES because the compiler
> >> will optimize/reduce it from
> >>
> >> #define GETVYRES(s,i) ({ \
> >> (s == SCROLL_REDRAW || s == SCROLL_MOVE) ? \
> >> (i)->var.yres : (i)->var.yres_virtual; })
> >>
> >> to just become:
> >>
> >> #define GETVYRES(s,i) ((i)->var.yres)
> >
> > Yeah, but you need to roll out your helper to all the callsites. But
> > since you #ifdef out info->scrollmode we should catch them all I
> > guess.
>
> Right. That was the only reason why I ifdef'ed it out.
> Technically we don't need that ifdef.
>
> >>> Like I said in the cover letter I got mostly distracted with fbcon
> >>> locking last week, not really with this one here at all, so maybe
> >>> going with your 4 (or 2 if we squash them like I did here) patches is
> >>> neater?
> >>
> >> The benefit of my patch series was, that it could be easily backported first,
> >> and then cleaned up afterwards. Even a small additional backport patch to disable
> >> the fbcon acceleration for DRM in the old releases would be easy.
> >> But I'm not insisting on backporting the patches, if we find good way forward.
> >>
> >> So, either with the 4 (or 2) patches would be OK for me (or even your approach).
> >
> > The idea behind the squash was that it's then impossible to backport
> > without the Kconfig,
>
> Yes, my proposal was to simply revert the 2 patches and immediatly send
> the Kconfig patch to disable it again.
>
> > and so we'll only enable this code when people
> > intentionally want it. Maybe I'm too paranoid?
>
> I think you are too paranoid :-)
> If all patches incl. the Kconfig patch are backported then people shouldn't
> do it wrong.
>
> > Anyway, you feel like finishing off your approach? Or should I send
> > out v2 of this with the issues fixed you spotted? Like I said either
> > is fine with me.
>
> Ok, then let me try to finish my approach until tomorrow, and then you
> check if you can and want to add your locking and other patches on top of it.
> In the end I leave the decision which approach to take to you.
> Ok?
Sounds good, and yeah rough idea is that the maintainers + revert +
Kconfig should go in for rc3 or rc4 if we hit another bump, and the
locking stuff then in for -next (since it needs a backmerge and is
defo tricky stuff).
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 01/21] MAINTAINERS: Add entry for fbdev core
2022-01-31 21:05 ` Daniel Vetter
(?)
@ 2022-02-01 20:47 ` Dave Airlie
-1 siblings, 0 replies; 241+ messages in thread
From: Dave Airlie @ 2022-02-01 20:47 UTC (permalink / raw)
To: Daniel Vetter
Cc: DRI Development, Intel Graphics Development,
Linux Fbdev development list, LKML, Jani Nikula, Linus Torvalds,
Pavel Machek, Sam Ravnborg, Greg Kroah-Hartman,
Javier Martinez Canillas, Claudio Suarez, Tomi Valkeinen,
Geert Uytterhoeven, Thomas Zimmermann, Daniel Vetter,
Sven Schnelle, Gerd Hoffmann
On Tue, 1 Feb 2022 at 07:06, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
>
> Ever since Tomi extracted the core code in 2014 it's been defacto me
> maintaining this, with help from others from dri-devel and sometimes
> Linus (but those are mostly merge conflicts):
>
> $ git shortlog -ns drivers/video/fbdev/core/ | head -n5
> 35 Daniel Vetter
> 23 Linus Torvalds
> 10 Hans de Goede
> 9 Dave Airlie
> 6 Peter Rosin
Acked-by: Dave Airlie <airlied@redhat.com>
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 01/21] MAINTAINERS: Add entry for fbdev core
@ 2022-02-01 20:47 ` Dave Airlie
0 siblings, 0 replies; 241+ messages in thread
From: Dave Airlie @ 2022-02-01 20:47 UTC (permalink / raw)
To: Daniel Vetter
Cc: Linux Fbdev development list, Thomas Zimmermann, Sven Schnelle,
Daniel Vetter, Sam Ravnborg, Intel Graphics Development, LKML,
Javier Martinez Canillas, Tomi Valkeinen, Claudio Suarez,
DRI Development, Pavel Machek, Greg Kroah-Hartman,
Geert Uytterhoeven, Linus Torvalds, Gerd Hoffmann
On Tue, 1 Feb 2022 at 07:06, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
>
> Ever since Tomi extracted the core code in 2014 it's been defacto me
> maintaining this, with help from others from dri-devel and sometimes
> Linus (but those are mostly merge conflicts):
>
> $ git shortlog -ns drivers/video/fbdev/core/ | head -n5
> 35 Daniel Vetter
> 23 Linus Torvalds
> 10 Hans de Goede
> 9 Dave Airlie
> 6 Peter Rosin
Acked-by: Dave Airlie <airlied@redhat.com>
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [Intel-gfx] [PATCH 01/21] MAINTAINERS: Add entry for fbdev core
@ 2022-02-01 20:47 ` Dave Airlie
0 siblings, 0 replies; 241+ messages in thread
From: Dave Airlie @ 2022-02-01 20:47 UTC (permalink / raw)
To: Daniel Vetter
Cc: Linux Fbdev development list, Thomas Zimmermann, Sven Schnelle,
Daniel Vetter, Sam Ravnborg, Intel Graphics Development, LKML,
Javier Martinez Canillas, Tomi Valkeinen, DRI Development,
Pavel Machek, Greg Kroah-Hartman, Geert Uytterhoeven,
Linus Torvalds, Gerd Hoffmann
On Tue, 1 Feb 2022 at 07:06, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
>
> Ever since Tomi extracted the core code in 2014 it's been defacto me
> maintaining this, with help from others from dri-devel and sometimes
> Linus (but those are mostly merge conflicts):
>
> $ git shortlog -ns drivers/video/fbdev/core/ | head -n5
> 35 Daniel Vetter
> 23 Linus Torvalds
> 10 Hans de Goede
> 9 Dave Airlie
> 6 Peter Rosin
Acked-by: Dave Airlie <airlied@redhat.com>
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 01/21] MAINTAINERS: Add entry for fbdev core
2022-01-31 21:05 ` Daniel Vetter
(?)
@ 2022-02-02 11:10 ` Daniel Stone
-1 siblings, 0 replies; 241+ messages in thread
From: Daniel Stone @ 2022-02-02 11:10 UTC (permalink / raw)
To: Daniel Vetter
Cc: DRI Development, linux-fbdev, Thomas Zimmermann, Sam Ravnborg,
Daniel Vetter, Intel Graphics Development, LKML,
Javier Martinez Canillas, Linus Torvalds, Tomi Valkeinen,
Claudio Suarez, Gerd Hoffmann, Pavel Machek, Greg Kroah-Hartman,
Geert Uytterhoeven, Sven Schnelle
On Mon, 31 Jan 2022 at 21:06, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> Ever since Tomi extracted the core code in 2014 it's been defacto me
> maintaining this, with help from others from dri-devel and sometimes
> Linus (but those are mostly merge conflicts):
>
> $ git shortlog -ns drivers/video/fbdev/core/ | head -n5
> 35 Daniel Vetter
> 23 Linus Torvalds
> 10 Hans de Goede
> 9 Dave Airlie
> 6 Peter Rosin
>
> I think ideally we'd also record that the various firmware fb drivers
> (efifb, vesafb, ...) are also maintained in drm-misc because for the
> past few years the patches have either been to fix handover issues
> with drm drivers, or caused handover issues with drm drivers. So any
> other tree just doesn't make sense. But also, there's plenty of
> outdated MAINTAINER entries for these with people and git trees that
> haven't been active in years, so maybe let's just leave them alone.
> And furthermore distros are now adopting simpledrm as the firmware fb
> driver, so hopefully the need to care about the fbdev firmware drivers
> will go down going forward.
>
> Note that drm-misc is group maintained, I expect that to continue like
> we've done before, so no new expectations that patches all go through
> my hands. That would be silly. This also means I'm happy to put any
> other volunteer's name in the M: line, but otherwise git log says I'm
> the one who's stuck with this.
Acked-by: Daniel Stone <daniels@collabora.com>
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [Intel-gfx] [PATCH 01/21] MAINTAINERS: Add entry for fbdev core
@ 2022-02-02 11:10 ` Daniel Stone
0 siblings, 0 replies; 241+ messages in thread
From: Daniel Stone @ 2022-02-02 11:10 UTC (permalink / raw)
To: Daniel Vetter
Cc: linux-fbdev, Pavel Machek, Sven Schnelle, Linus Torvalds,
Intel Graphics Development, LKML, DRI Development,
Javier Martinez Canillas, Geert Uytterhoeven, Tomi Valkeinen,
Gerd Hoffmann, Thomas Zimmermann, Greg Kroah-Hartman,
Daniel Vetter, Sam Ravnborg
On Mon, 31 Jan 2022 at 21:06, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> Ever since Tomi extracted the core code in 2014 it's been defacto me
> maintaining this, with help from others from dri-devel and sometimes
> Linus (but those are mostly merge conflicts):
>
> $ git shortlog -ns drivers/video/fbdev/core/ | head -n5
> 35 Daniel Vetter
> 23 Linus Torvalds
> 10 Hans de Goede
> 9 Dave Airlie
> 6 Peter Rosin
>
> I think ideally we'd also record that the various firmware fb drivers
> (efifb, vesafb, ...) are also maintained in drm-misc because for the
> past few years the patches have either been to fix handover issues
> with drm drivers, or caused handover issues with drm drivers. So any
> other tree just doesn't make sense. But also, there's plenty of
> outdated MAINTAINER entries for these with people and git trees that
> haven't been active in years, so maybe let's just leave them alone.
> And furthermore distros are now adopting simpledrm as the firmware fb
> driver, so hopefully the need to care about the fbdev firmware drivers
> will go down going forward.
>
> Note that drm-misc is group maintained, I expect that to continue like
> we've done before, so no new expectations that patches all go through
> my hands. That would be silly. This also means I'm happy to put any
> other volunteer's name in the M: line, but otherwise git log says I'm
> the one who's stuck with this.
Acked-by: Daniel Stone <daniels@collabora.com>
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 01/21] MAINTAINERS: Add entry for fbdev core
@ 2022-02-02 11:10 ` Daniel Stone
0 siblings, 0 replies; 241+ messages in thread
From: Daniel Stone @ 2022-02-02 11:10 UTC (permalink / raw)
To: Daniel Vetter
Cc: linux-fbdev, Pavel Machek, Sven Schnelle, Linus Torvalds,
Intel Graphics Development, LKML, DRI Development,
Javier Martinez Canillas, Geert Uytterhoeven, Tomi Valkeinen,
Claudio Suarez, Gerd Hoffmann, Thomas Zimmermann,
Greg Kroah-Hartman, Daniel Vetter, Sam Ravnborg
On Mon, 31 Jan 2022 at 21:06, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> Ever since Tomi extracted the core code in 2014 it's been defacto me
> maintaining this, with help from others from dri-devel and sometimes
> Linus (but those are mostly merge conflicts):
>
> $ git shortlog -ns drivers/video/fbdev/core/ | head -n5
> 35 Daniel Vetter
> 23 Linus Torvalds
> 10 Hans de Goede
> 9 Dave Airlie
> 6 Peter Rosin
>
> I think ideally we'd also record that the various firmware fb drivers
> (efifb, vesafb, ...) are also maintained in drm-misc because for the
> past few years the patches have either been to fix handover issues
> with drm drivers, or caused handover issues with drm drivers. So any
> other tree just doesn't make sense. But also, there's plenty of
> outdated MAINTAINER entries for these with people and git trees that
> haven't been active in years, so maybe let's just leave them alone.
> And furthermore distros are now adopting simpledrm as the firmware fb
> driver, so hopefully the need to care about the fbdev firmware drivers
> will go down going forward.
>
> Note that drm-misc is group maintained, I expect that to continue like
> we've done before, so no new expectations that patches all go through
> my hands. That would be silly. This also means I'm happy to put any
> other volunteer's name in the M: line, but otherwise git log says I'm
> the one who's stuck with this.
Acked-by: Daniel Stone <daniels@collabora.com>
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 01/21] MAINTAINERS: Add entry for fbdev core
2022-01-31 21:05 ` Daniel Vetter
(?)
@ 2022-02-02 11:18 ` Tomi Valkeinen
-1 siblings, 0 replies; 241+ messages in thread
From: Tomi Valkeinen @ 2022-02-02 11:18 UTC (permalink / raw)
To: Daniel Vetter, DRI Development
Cc: linux-fbdev, Thomas Zimmermann, Sam Ravnborg, Daniel Vetter,
Intel Graphics Development, LKML, Javier Martinez Canillas,
Linus Torvalds, Tomi Valkeinen, Claudio Suarez, Gerd Hoffmann,
Pavel Machek, Greg Kroah-Hartman, Geert Uytterhoeven,
Sven Schnelle
On 31/01/2022 23:05, Daniel Vetter wrote:
> Ever since Tomi extracted the core code in 2014 it's been defacto me
> maintaining this, with help from others from dri-devel and sometimes
> Linus (but those are mostly merge conflicts):
>
> $ git shortlog -ns drivers/video/fbdev/core/ | head -n5
> 35 Daniel Vetter
> 23 Linus Torvalds
> 10 Hans de Goede
> 9 Dave Airlie
> 6 Peter Rosin
>
> I think ideally we'd also record that the various firmware fb drivers
> (efifb, vesafb, ...) are also maintained in drm-misc because for the
> past few years the patches have either been to fix handover issues
> with drm drivers, or caused handover issues with drm drivers. So any
> other tree just doesn't make sense. But also, there's plenty of
> outdated MAINTAINER entries for these with people and git trees that
> haven't been active in years, so maybe let's just leave them alone.
> And furthermore distros are now adopting simpledrm as the firmware fb
> driver, so hopefully the need to care about the fbdev firmware drivers
> will go down going forward.
>
> Note that drm-misc is group maintained, I expect that to continue like
> we've done before, so no new expectations that patches all go through
> my hands. That would be silly. This also means I'm happy to put any
> other volunteer's name in the M: line, but otherwise git log says I'm
> the one who's stuck with this.
Acked-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Tomi
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 01/21] MAINTAINERS: Add entry for fbdev core
@ 2022-02-02 11:18 ` Tomi Valkeinen
0 siblings, 0 replies; 241+ messages in thread
From: Tomi Valkeinen @ 2022-02-02 11:18 UTC (permalink / raw)
To: Daniel Vetter, DRI Development
Cc: linux-fbdev, Pavel Machek, Sven Schnelle, Linus Torvalds,
Intel Graphics Development, LKML, Geert Uytterhoeven,
Javier Martinez Canillas, Tomi Valkeinen, Claudio Suarez,
Gerd Hoffmann, Thomas Zimmermann, Greg Kroah-Hartman,
Daniel Vetter, Sam Ravnborg
On 31/01/2022 23:05, Daniel Vetter wrote:
> Ever since Tomi extracted the core code in 2014 it's been defacto me
> maintaining this, with help from others from dri-devel and sometimes
> Linus (but those are mostly merge conflicts):
>
> $ git shortlog -ns drivers/video/fbdev/core/ | head -n5
> 35 Daniel Vetter
> 23 Linus Torvalds
> 10 Hans de Goede
> 9 Dave Airlie
> 6 Peter Rosin
>
> I think ideally we'd also record that the various firmware fb drivers
> (efifb, vesafb, ...) are also maintained in drm-misc because for the
> past few years the patches have either been to fix handover issues
> with drm drivers, or caused handover issues with drm drivers. So any
> other tree just doesn't make sense. But also, there's plenty of
> outdated MAINTAINER entries for these with people and git trees that
> haven't been active in years, so maybe let's just leave them alone.
> And furthermore distros are now adopting simpledrm as the firmware fb
> driver, so hopefully the need to care about the fbdev firmware drivers
> will go down going forward.
>
> Note that drm-misc is group maintained, I expect that to continue like
> we've done before, so no new expectations that patches all go through
> my hands. That would be silly. This also means I'm happy to put any
> other volunteer's name in the M: line, but otherwise git log says I'm
> the one who's stuck with this.
Acked-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Tomi
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [Intel-gfx] [PATCH 01/21] MAINTAINERS: Add entry for fbdev core
@ 2022-02-02 11:18 ` Tomi Valkeinen
0 siblings, 0 replies; 241+ messages in thread
From: Tomi Valkeinen @ 2022-02-02 11:18 UTC (permalink / raw)
To: Daniel Vetter, DRI Development
Cc: linux-fbdev, Pavel Machek, Sven Schnelle, Linus Torvalds,
Intel Graphics Development, LKML, Geert Uytterhoeven,
Javier Martinez Canillas, Tomi Valkeinen, Gerd Hoffmann,
Thomas Zimmermann, Greg Kroah-Hartman, Daniel Vetter,
Sam Ravnborg
On 31/01/2022 23:05, Daniel Vetter wrote:
> Ever since Tomi extracted the core code in 2014 it's been defacto me
> maintaining this, with help from others from dri-devel and sometimes
> Linus (but those are mostly merge conflicts):
>
> $ git shortlog -ns drivers/video/fbdev/core/ | head -n5
> 35 Daniel Vetter
> 23 Linus Torvalds
> 10 Hans de Goede
> 9 Dave Airlie
> 6 Peter Rosin
>
> I think ideally we'd also record that the various firmware fb drivers
> (efifb, vesafb, ...) are also maintained in drm-misc because for the
> past few years the patches have either been to fix handover issues
> with drm drivers, or caused handover issues with drm drivers. So any
> other tree just doesn't make sense. But also, there's plenty of
> outdated MAINTAINER entries for these with people and git trees that
> haven't been active in years, so maybe let's just leave them alone.
> And furthermore distros are now adopting simpledrm as the firmware fb
> driver, so hopefully the need to care about the fbdev firmware drivers
> will go down going forward.
>
> Note that drm-misc is group maintained, I expect that to continue like
> we've done before, so no new expectations that patches all go through
> my hands. That would be silly. This also means I'm happy to put any
> other volunteer's name in the M: line, but otherwise git log says I'm
> the one who's stuck with this.
Acked-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Tomi
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 01/21] MAINTAINERS: Add entry for fbdev core
2022-01-31 21:05 ` Daniel Vetter
(?)
@ 2022-02-02 11:31 ` Maxime Ripard
-1 siblings, 0 replies; 241+ messages in thread
From: Maxime Ripard @ 2022-02-02 11:31 UTC (permalink / raw)
To: Daniel Vetter
Cc: DRI Development, linux-fbdev, Thomas Zimmermann, Sam Ravnborg,
Daniel Vetter, Intel Graphics Development, LKML,
Javier Martinez Canillas, Linus Torvalds, Tomi Valkeinen,
Claudio Suarez, Gerd Hoffmann, Pavel Machek, Greg Kroah-Hartman,
Geert Uytterhoeven, Sven Schnelle
On Mon, Jan 31, 2022 at 10:05:32PM +0100, Daniel Vetter wrote:
> Ever since Tomi extracted the core code in 2014 it's been defacto me
> maintaining this, with help from others from dri-devel and sometimes
> Linus (but those are mostly merge conflicts):
>
> $ git shortlog -ns drivers/video/fbdev/core/ | head -n5
> 35 Daniel Vetter
> 23 Linus Torvalds
> 10 Hans de Goede
> 9 Dave Airlie
> 6 Peter Rosin
>
> I think ideally we'd also record that the various firmware fb drivers
> (efifb, vesafb, ...) are also maintained in drm-misc because for the
> past few years the patches have either been to fix handover issues
> with drm drivers, or caused handover issues with drm drivers. So any
> other tree just doesn't make sense. But also, there's plenty of
> outdated MAINTAINER entries for these with people and git trees that
> haven't been active in years, so maybe let's just leave them alone.
> And furthermore distros are now adopting simpledrm as the firmware fb
> driver, so hopefully the need to care about the fbdev firmware drivers
> will go down going forward.
>
> Note that drm-misc is group maintained, I expect that to continue like
> we've done before, so no new expectations that patches all go through
> my hands. That would be silly. This also means I'm happy to put any
> other volunteer's name in the M: line, but otherwise git log says I'm
> the one who's stuck with this.
>
> Cc: Dave Airlie <airlied@gmail.com>
> Cc: Jani Nikula <jani.nikula@linux.intel.com>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: Linux Fbdev development list <linux-fbdev@vger.kernel.org>
> Cc: Pavel Machek <pavel@ucw.cz>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Javier Martinez Canillas <javierm@redhat.com>
> Cc: DRI Development <dri-devel@lists.freedesktop.org>
> Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
> Cc: Claudio Suarez <cssk@net-c.es>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Cc: Geert Uytterhoeven <geert@linux-m68k.org>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Sven Schnelle <svens@stackframe.org>
> Cc: Gerd Hoffmann <kraxel@redhat.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Acked-by: Maxime Ripard <maxime@cerno.tech>
Maxime
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 01/21] MAINTAINERS: Add entry for fbdev core
@ 2022-02-02 11:31 ` Maxime Ripard
0 siblings, 0 replies; 241+ messages in thread
From: Maxime Ripard @ 2022-02-02 11:31 UTC (permalink / raw)
To: Daniel Vetter
Cc: linux-fbdev, Pavel Machek, Sven Schnelle, Linus Torvalds,
Intel Graphics Development, LKML, DRI Development,
Javier Martinez Canillas, Geert Uytterhoeven, Tomi Valkeinen,
Claudio Suarez, Gerd Hoffmann, Thomas Zimmermann,
Greg Kroah-Hartman, Daniel Vetter, Sam Ravnborg
On Mon, Jan 31, 2022 at 10:05:32PM +0100, Daniel Vetter wrote:
> Ever since Tomi extracted the core code in 2014 it's been defacto me
> maintaining this, with help from others from dri-devel and sometimes
> Linus (but those are mostly merge conflicts):
>
> $ git shortlog -ns drivers/video/fbdev/core/ | head -n5
> 35 Daniel Vetter
> 23 Linus Torvalds
> 10 Hans de Goede
> 9 Dave Airlie
> 6 Peter Rosin
>
> I think ideally we'd also record that the various firmware fb drivers
> (efifb, vesafb, ...) are also maintained in drm-misc because for the
> past few years the patches have either been to fix handover issues
> with drm drivers, or caused handover issues with drm drivers. So any
> other tree just doesn't make sense. But also, there's plenty of
> outdated MAINTAINER entries for these with people and git trees that
> haven't been active in years, so maybe let's just leave them alone.
> And furthermore distros are now adopting simpledrm as the firmware fb
> driver, so hopefully the need to care about the fbdev firmware drivers
> will go down going forward.
>
> Note that drm-misc is group maintained, I expect that to continue like
> we've done before, so no new expectations that patches all go through
> my hands. That would be silly. This also means I'm happy to put any
> other volunteer's name in the M: line, but otherwise git log says I'm
> the one who's stuck with this.
>
> Cc: Dave Airlie <airlied@gmail.com>
> Cc: Jani Nikula <jani.nikula@linux.intel.com>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: Linux Fbdev development list <linux-fbdev@vger.kernel.org>
> Cc: Pavel Machek <pavel@ucw.cz>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Javier Martinez Canillas <javierm@redhat.com>
> Cc: DRI Development <dri-devel@lists.freedesktop.org>
> Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
> Cc: Claudio Suarez <cssk@net-c.es>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Cc: Geert Uytterhoeven <geert@linux-m68k.org>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Sven Schnelle <svens@stackframe.org>
> Cc: Gerd Hoffmann <kraxel@redhat.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Acked-by: Maxime Ripard <maxime@cerno.tech>
Maxime
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [Intel-gfx] [PATCH 01/21] MAINTAINERS: Add entry for fbdev core
@ 2022-02-02 11:31 ` Maxime Ripard
0 siblings, 0 replies; 241+ messages in thread
From: Maxime Ripard @ 2022-02-02 11:31 UTC (permalink / raw)
To: Daniel Vetter
Cc: linux-fbdev, Pavel Machek, Sven Schnelle, Linus Torvalds,
Intel Graphics Development, LKML, DRI Development,
Javier Martinez Canillas, Geert Uytterhoeven, Tomi Valkeinen,
Gerd Hoffmann, Thomas Zimmermann, Greg Kroah-Hartman,
Daniel Vetter, Sam Ravnborg
On Mon, Jan 31, 2022 at 10:05:32PM +0100, Daniel Vetter wrote:
> Ever since Tomi extracted the core code in 2014 it's been defacto me
> maintaining this, with help from others from dri-devel and sometimes
> Linus (but those are mostly merge conflicts):
>
> $ git shortlog -ns drivers/video/fbdev/core/ | head -n5
> 35 Daniel Vetter
> 23 Linus Torvalds
> 10 Hans de Goede
> 9 Dave Airlie
> 6 Peter Rosin
>
> I think ideally we'd also record that the various firmware fb drivers
> (efifb, vesafb, ...) are also maintained in drm-misc because for the
> past few years the patches have either been to fix handover issues
> with drm drivers, or caused handover issues with drm drivers. So any
> other tree just doesn't make sense. But also, there's plenty of
> outdated MAINTAINER entries for these with people and git trees that
> haven't been active in years, so maybe let's just leave them alone.
> And furthermore distros are now adopting simpledrm as the firmware fb
> driver, so hopefully the need to care about the fbdev firmware drivers
> will go down going forward.
>
> Note that drm-misc is group maintained, I expect that to continue like
> we've done before, so no new expectations that patches all go through
> my hands. That would be silly. This also means I'm happy to put any
> other volunteer's name in the M: line, but otherwise git log says I'm
> the one who's stuck with this.
>
> Cc: Dave Airlie <airlied@gmail.com>
> Cc: Jani Nikula <jani.nikula@linux.intel.com>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: Linux Fbdev development list <linux-fbdev@vger.kernel.org>
> Cc: Pavel Machek <pavel@ucw.cz>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Javier Martinez Canillas <javierm@redhat.com>
> Cc: DRI Development <dri-devel@lists.freedesktop.org>
> Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
> Cc: Claudio Suarez <cssk@net-c.es>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Cc: Geert Uytterhoeven <geert@linux-m68k.org>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Sven Schnelle <svens@stackframe.org>
> Cc: Gerd Hoffmann <kraxel@redhat.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Acked-by: Maxime Ripard <maxime@cerno.tech>
Maxime
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 01/21] MAINTAINERS: Add entry for fbdev core
2022-02-02 11:31 ` Maxime Ripard
(?)
@ 2022-02-02 13:48 ` Alex Deucher
-1 siblings, 0 replies; 241+ messages in thread
From: Alex Deucher @ 2022-02-02 13:48 UTC (permalink / raw)
To: Maxime Ripard
Cc: Daniel Vetter, open list:EFIFB FRAMEBUFFER DRIVER, Pavel Machek,
Sven Schnelle, Linus Torvalds, Intel Graphics Development, LKML,
DRI Development, Javier Martinez Canillas, Geert Uytterhoeven,
Tomi Valkeinen, Claudio Suarez, Gerd Hoffmann, Thomas Zimmermann,
Greg Kroah-Hartman, Daniel Vetter, Sam Ravnborg
Acked-by: Alex Deucher <alexander.deucher@amd.com>
On Wed, Feb 2, 2022 at 6:31 AM Maxime Ripard <maxime@cerno.tech> wrote:
>
> On Mon, Jan 31, 2022 at 10:05:32PM +0100, Daniel Vetter wrote:
> > Ever since Tomi extracted the core code in 2014 it's been defacto me
> > maintaining this, with help from others from dri-devel and sometimes
> > Linus (but those are mostly merge conflicts):
> >
> > $ git shortlog -ns drivers/video/fbdev/core/ | head -n5
> > 35 Daniel Vetter
> > 23 Linus Torvalds
> > 10 Hans de Goede
> > 9 Dave Airlie
> > 6 Peter Rosin
> >
> > I think ideally we'd also record that the various firmware fb drivers
> > (efifb, vesafb, ...) are also maintained in drm-misc because for the
> > past few years the patches have either been to fix handover issues
> > with drm drivers, or caused handover issues with drm drivers. So any
> > other tree just doesn't make sense. But also, there's plenty of
> > outdated MAINTAINER entries for these with people and git trees that
> > haven't been active in years, so maybe let's just leave them alone.
> > And furthermore distros are now adopting simpledrm as the firmware fb
> > driver, so hopefully the need to care about the fbdev firmware drivers
> > will go down going forward.
> >
> > Note that drm-misc is group maintained, I expect that to continue like
> > we've done before, so no new expectations that patches all go through
> > my hands. That would be silly. This also means I'm happy to put any
> > other volunteer's name in the M: line, but otherwise git log says I'm
> > the one who's stuck with this.
> >
> > Cc: Dave Airlie <airlied@gmail.com>
> > Cc: Jani Nikula <jani.nikula@linux.intel.com>
> > Cc: Linus Torvalds <torvalds@linux-foundation.org>
> > Cc: Linux Fbdev development list <linux-fbdev@vger.kernel.org>
> > Cc: Pavel Machek <pavel@ucw.cz>
> > Cc: Sam Ravnborg <sam@ravnborg.org>
> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Cc: Javier Martinez Canillas <javierm@redhat.com>
> > Cc: DRI Development <dri-devel@lists.freedesktop.org>
> > Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
> > Cc: Claudio Suarez <cssk@net-c.es>
> > Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> > Cc: Geert Uytterhoeven <geert@linux-m68k.org>
> > Cc: Thomas Zimmermann <tzimmermann@suse.de>
> > Cc: Daniel Vetter <daniel.vetter@intel.com>
> > Cc: Sven Schnelle <svens@stackframe.org>
> > Cc: Gerd Hoffmann <kraxel@redhat.com>
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
>
> Acked-by: Maxime Ripard <maxime@cerno.tech>
>
> Maxime
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 01/21] MAINTAINERS: Add entry for fbdev core
@ 2022-02-02 13:48 ` Alex Deucher
0 siblings, 0 replies; 241+ messages in thread
From: Alex Deucher @ 2022-02-02 13:48 UTC (permalink / raw)
To: Maxime Ripard
Cc: open list:EFIFB FRAMEBUFFER DRIVER, Thomas Zimmermann,
Sam Ravnborg, Daniel Vetter, Daniel Vetter, Sven Schnelle, LKML,
DRI Development, Javier Martinez Canillas, Tomi Valkeinen,
Geert Uytterhoeven, Gerd Hoffmann, Pavel Machek,
Greg Kroah-Hartman, Claudio Suarez, Linus Torvalds,
Intel Graphics Development
Acked-by: Alex Deucher <alexander.deucher@amd.com>
On Wed, Feb 2, 2022 at 6:31 AM Maxime Ripard <maxime@cerno.tech> wrote:
>
> On Mon, Jan 31, 2022 at 10:05:32PM +0100, Daniel Vetter wrote:
> > Ever since Tomi extracted the core code in 2014 it's been defacto me
> > maintaining this, with help from others from dri-devel and sometimes
> > Linus (but those are mostly merge conflicts):
> >
> > $ git shortlog -ns drivers/video/fbdev/core/ | head -n5
> > 35 Daniel Vetter
> > 23 Linus Torvalds
> > 10 Hans de Goede
> > 9 Dave Airlie
> > 6 Peter Rosin
> >
> > I think ideally we'd also record that the various firmware fb drivers
> > (efifb, vesafb, ...) are also maintained in drm-misc because for the
> > past few years the patches have either been to fix handover issues
> > with drm drivers, or caused handover issues with drm drivers. So any
> > other tree just doesn't make sense. But also, there's plenty of
> > outdated MAINTAINER entries for these with people and git trees that
> > haven't been active in years, so maybe let's just leave them alone.
> > And furthermore distros are now adopting simpledrm as the firmware fb
> > driver, so hopefully the need to care about the fbdev firmware drivers
> > will go down going forward.
> >
> > Note that drm-misc is group maintained, I expect that to continue like
> > we've done before, so no new expectations that patches all go through
> > my hands. That would be silly. This also means I'm happy to put any
> > other volunteer's name in the M: line, but otherwise git log says I'm
> > the one who's stuck with this.
> >
> > Cc: Dave Airlie <airlied@gmail.com>
> > Cc: Jani Nikula <jani.nikula@linux.intel.com>
> > Cc: Linus Torvalds <torvalds@linux-foundation.org>
> > Cc: Linux Fbdev development list <linux-fbdev@vger.kernel.org>
> > Cc: Pavel Machek <pavel@ucw.cz>
> > Cc: Sam Ravnborg <sam@ravnborg.org>
> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Cc: Javier Martinez Canillas <javierm@redhat.com>
> > Cc: DRI Development <dri-devel@lists.freedesktop.org>
> > Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
> > Cc: Claudio Suarez <cssk@net-c.es>
> > Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> > Cc: Geert Uytterhoeven <geert@linux-m68k.org>
> > Cc: Thomas Zimmermann <tzimmermann@suse.de>
> > Cc: Daniel Vetter <daniel.vetter@intel.com>
> > Cc: Sven Schnelle <svens@stackframe.org>
> > Cc: Gerd Hoffmann <kraxel@redhat.com>
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
>
> Acked-by: Maxime Ripard <maxime@cerno.tech>
>
> Maxime
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [Intel-gfx] [PATCH 01/21] MAINTAINERS: Add entry for fbdev core
@ 2022-02-02 13:48 ` Alex Deucher
0 siblings, 0 replies; 241+ messages in thread
From: Alex Deucher @ 2022-02-02 13:48 UTC (permalink / raw)
To: Maxime Ripard
Cc: open list:EFIFB FRAMEBUFFER DRIVER, Thomas Zimmermann,
Sam Ravnborg, Daniel Vetter, Daniel Vetter, Sven Schnelle, LKML,
DRI Development, Javier Martinez Canillas, Tomi Valkeinen,
Geert Uytterhoeven, Gerd Hoffmann, Pavel Machek,
Greg Kroah-Hartman, Linus Torvalds, Intel Graphics Development
Acked-by: Alex Deucher <alexander.deucher@amd.com>
On Wed, Feb 2, 2022 at 6:31 AM Maxime Ripard <maxime@cerno.tech> wrote:
>
> On Mon, Jan 31, 2022 at 10:05:32PM +0100, Daniel Vetter wrote:
> > Ever since Tomi extracted the core code in 2014 it's been defacto me
> > maintaining this, with help from others from dri-devel and sometimes
> > Linus (but those are mostly merge conflicts):
> >
> > $ git shortlog -ns drivers/video/fbdev/core/ | head -n5
> > 35 Daniel Vetter
> > 23 Linus Torvalds
> > 10 Hans de Goede
> > 9 Dave Airlie
> > 6 Peter Rosin
> >
> > I think ideally we'd also record that the various firmware fb drivers
> > (efifb, vesafb, ...) are also maintained in drm-misc because for the
> > past few years the patches have either been to fix handover issues
> > with drm drivers, or caused handover issues with drm drivers. So any
> > other tree just doesn't make sense. But also, there's plenty of
> > outdated MAINTAINER entries for these with people and git trees that
> > haven't been active in years, so maybe let's just leave them alone.
> > And furthermore distros are now adopting simpledrm as the firmware fb
> > driver, so hopefully the need to care about the fbdev firmware drivers
> > will go down going forward.
> >
> > Note that drm-misc is group maintained, I expect that to continue like
> > we've done before, so no new expectations that patches all go through
> > my hands. That would be silly. This also means I'm happy to put any
> > other volunteer's name in the M: line, but otherwise git log says I'm
> > the one who's stuck with this.
> >
> > Cc: Dave Airlie <airlied@gmail.com>
> > Cc: Jani Nikula <jani.nikula@linux.intel.com>
> > Cc: Linus Torvalds <torvalds@linux-foundation.org>
> > Cc: Linux Fbdev development list <linux-fbdev@vger.kernel.org>
> > Cc: Pavel Machek <pavel@ucw.cz>
> > Cc: Sam Ravnborg <sam@ravnborg.org>
> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Cc: Javier Martinez Canillas <javierm@redhat.com>
> > Cc: DRI Development <dri-devel@lists.freedesktop.org>
> > Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
> > Cc: Claudio Suarez <cssk@net-c.es>
> > Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> > Cc: Geert Uytterhoeven <geert@linux-m68k.org>
> > Cc: Thomas Zimmermann <tzimmermann@suse.de>
> > Cc: Daniel Vetter <daniel.vetter@intel.com>
> > Cc: Sven Schnelle <svens@stackframe.org>
> > Cc: Gerd Hoffmann <kraxel@redhat.com>
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
>
> Acked-by: Maxime Ripard <maxime@cerno.tech>
>
> Maxime
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 09/21] fbcon: Replace FBCON_FLAGS_INIT with a boolean
2022-02-01 10:37 ` Thomas Zimmermann
(?)
@ 2022-02-03 13:47 ` Geert Uytterhoeven
-1 siblings, 0 replies; 241+ messages in thread
From: Geert Uytterhoeven @ 2022-02-03 13:47 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: Daniel Vetter, DRI Development, Intel Graphics Development,
Linux Fbdev development list, LKML, Daniel Vetter, Daniel Vetter,
Tetsuo Handa, Greg Kroah-Hartman, Du Cheng, Claudio Suarez
On Wed, Feb 2, 2022 at 10:25 AM Thomas Zimmermann <tzimmermann@suse.de> wrote:
> Am 31.01.22 um 22:05 schrieb Daniel Vetter:
> > It's only one flag and slightly tidier code.
> >
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > Cc: Daniel Vetter <daniel@ffwll.ch>
> > Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Cc: Du Cheng <ducheng2@gmail.com>
> > Cc: Thomas Zimmermann <tzimmermann@suse.de>
> > Cc: Claudio Suarez <cssk@net-c.es>
>
> Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
> > +++ b/drivers/video/fbdev/core/fbcon.h
> > @@ -18,8 +18,6 @@
> >
> > #include <asm/io.h>
> >
> > -#define FBCON_FLAGS_INIT 1
> > -
> > /*
> > * This is the interface between the low-level console driver and the
> > * low-level frame buffer device
> > @@ -77,7 +75,7 @@ struct fbcon_ops {
> > int blank_state;
> > int graphics;
> > int save_graphics; /* for debug enter/leave */
> > - int flags;
> > + bool initialized;
>
> This will add 3 bytes of padding. Maybe you can put the bool elsewhere.
Several of the int variables are used as boolean flags, too.
Perhaps convert them all to bitfields?
unsigned int initialized : 1;
...
> > int rotate;
> > int cur_rotate;
> > char *cursor_data;
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
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 09/21] fbcon: Replace FBCON_FLAGS_INIT with a boolean
@ 2022-02-03 13:47 ` Geert Uytterhoeven
0 siblings, 0 replies; 241+ messages in thread
From: Geert Uytterhoeven @ 2022-02-03 13:47 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: Linux Fbdev development list, Du Cheng, Tetsuo Handa,
Daniel Vetter, Intel Graphics Development, LKML, DRI Development,
Claudio Suarez, Greg Kroah-Hartman, Daniel Vetter
On Wed, Feb 2, 2022 at 10:25 AM Thomas Zimmermann <tzimmermann@suse.de> wrote:
> Am 31.01.22 um 22:05 schrieb Daniel Vetter:
> > It's only one flag and slightly tidier code.
> >
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > Cc: Daniel Vetter <daniel@ffwll.ch>
> > Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Cc: Du Cheng <ducheng2@gmail.com>
> > Cc: Thomas Zimmermann <tzimmermann@suse.de>
> > Cc: Claudio Suarez <cssk@net-c.es>
>
> Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
> > +++ b/drivers/video/fbdev/core/fbcon.h
> > @@ -18,8 +18,6 @@
> >
> > #include <asm/io.h>
> >
> > -#define FBCON_FLAGS_INIT 1
> > -
> > /*
> > * This is the interface between the low-level console driver and the
> > * low-level frame buffer device
> > @@ -77,7 +75,7 @@ struct fbcon_ops {
> > int blank_state;
> > int graphics;
> > int save_graphics; /* for debug enter/leave */
> > - int flags;
> > + bool initialized;
>
> This will add 3 bytes of padding. Maybe you can put the bool elsewhere.
Several of the int variables are used as boolean flags, too.
Perhaps convert them all to bitfields?
unsigned int initialized : 1;
...
> > int rotate;
> > int cur_rotate;
> > char *cursor_data;
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
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [Intel-gfx] [PATCH 09/21] fbcon: Replace FBCON_FLAGS_INIT with a boolean
@ 2022-02-03 13:47 ` Geert Uytterhoeven
0 siblings, 0 replies; 241+ messages in thread
From: Geert Uytterhoeven @ 2022-02-03 13:47 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: Linux Fbdev development list, Du Cheng, Tetsuo Handa,
Daniel Vetter, Intel Graphics Development, LKML, DRI Development,
Greg Kroah-Hartman, Daniel Vetter
On Wed, Feb 2, 2022 at 10:25 AM Thomas Zimmermann <tzimmermann@suse.de> wrote:
> Am 31.01.22 um 22:05 schrieb Daniel Vetter:
> > It's only one flag and slightly tidier code.
> >
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > Cc: Daniel Vetter <daniel@ffwll.ch>
> > Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Cc: Du Cheng <ducheng2@gmail.com>
> > Cc: Thomas Zimmermann <tzimmermann@suse.de>
> > Cc: Claudio Suarez <cssk@net-c.es>
>
> Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
> > +++ b/drivers/video/fbdev/core/fbcon.h
> > @@ -18,8 +18,6 @@
> >
> > #include <asm/io.h>
> >
> > -#define FBCON_FLAGS_INIT 1
> > -
> > /*
> > * This is the interface between the low-level console driver and the
> > * low-level frame buffer device
> > @@ -77,7 +75,7 @@ struct fbcon_ops {
> > int blank_state;
> > int graphics;
> > int save_graphics; /* for debug enter/leave */
> > - int flags;
> > + bool initialized;
>
> This will add 3 bytes of padding. Maybe you can put the bool elsewhere.
Several of the int variables are used as boolean flags, too.
Perhaps convert them all to bitfields?
unsigned int initialized : 1;
...
> > int rotate;
> > int cur_rotate;
> > char *cursor_data;
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
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 01/21] MAINTAINERS: Add entry for fbdev core
2022-01-31 21:05 ` Daniel Vetter
(?)
@ 2022-02-03 20:25 ` Sam Ravnborg
-1 siblings, 0 replies; 241+ messages in thread
From: Sam Ravnborg @ 2022-02-03 20:25 UTC (permalink / raw)
To: Daniel Vetter
Cc: linux-fbdev, Pavel Machek, Sven Schnelle, Greg Kroah-Hartman,
Intel Graphics Development, LKML, DRI Development,
Javier Martinez Canillas, Geert Uytterhoeven, Tomi Valkeinen,
Claudio Suarez, Gerd Hoffmann, Thomas Zimmermann, Daniel Vetter,
Linus Torvalds
Hi Daniel,
On Mon, Jan 31, 2022 at 10:05:32PM +0100, Daniel Vetter wrote:
> Ever since Tomi extracted the core code in 2014 it's been defacto me
> maintaining this, with help from others from dri-devel and sometimes
> Linus (but those are mostly merge conflicts):
>
> $ git shortlog -ns drivers/video/fbdev/core/ | head -n5
> 35 Daniel Vetter
> 23 Linus Torvalds
> 10 Hans de Goede
> 9 Dave Airlie
> 6 Peter Rosin
>
> I think ideally we'd also record that the various firmware fb drivers
> (efifb, vesafb, ...) are also maintained in drm-misc because for the
> past few years the patches have either been to fix handover issues
> with drm drivers, or caused handover issues with drm drivers. So any
> other tree just doesn't make sense. But also, there's plenty of
> outdated MAINTAINER entries for these with people and git trees that
> haven't been active in years, so maybe let's just leave them alone.
> And furthermore distros are now adopting simpledrm as the firmware fb
> driver, so hopefully the need to care about the fbdev firmware drivers
> will go down going forward.
>
> Note that drm-misc is group maintained, I expect that to continue like
> we've done before, so no new expectations that patches all go through
> my hands. That would be silly. This also means I'm happy to put any
> other volunteer's name in the M: line, but otherwise git log says I'm
> the one who's stuck with this.
>
> Cc: Dave Airlie <airlied@gmail.com>
> Cc: Jani Nikula <jani.nikula@linux.intel.com>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: Linux Fbdev development list <linux-fbdev@vger.kernel.org>
> Cc: Pavel Machek <pavel@ucw.cz>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Javier Martinez Canillas <javierm@redhat.com>
> Cc: DRI Development <dri-devel@lists.freedesktop.org>
> Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
> Cc: Claudio Suarez <cssk@net-c.es>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Cc: Geert Uytterhoeven <geert@linux-m68k.org>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Sven Schnelle <svens@stackframe.org>
> Cc: Gerd Hoffmann <kraxel@redhat.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> ---
> MAINTAINERS | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index ea3e6c914384..49809eaa3096 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -7573,6 +7573,12 @@ S: Maintained
> W: http://floatingpoint.sourceforge.net/emulator/index.html
> F: arch/x86/math-emu/
>
> +FRAMEBUFFER CORE
> +M: Daniel Vetter <daniel@ffwll.ch>
> +F: drivers/video/fbdev/core/
Maybe add:
include/linux/fb.h
include/uapi/linux/fb.h
Both edited within some months - so they see a little changes.
With or without this:
Acked-by: Sam Ravnborg <sam@ravnborg.org>
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [Intel-gfx] [PATCH 01/21] MAINTAINERS: Add entry for fbdev core
@ 2022-02-03 20:25 ` Sam Ravnborg
0 siblings, 0 replies; 241+ messages in thread
From: Sam Ravnborg @ 2022-02-03 20:25 UTC (permalink / raw)
To: Daniel Vetter
Cc: linux-fbdev, Pavel Machek, Sven Schnelle, Greg Kroah-Hartman,
Intel Graphics Development, LKML, DRI Development,
Javier Martinez Canillas, Geert Uytterhoeven, Tomi Valkeinen,
Gerd Hoffmann, Thomas Zimmermann, Daniel Vetter, Linus Torvalds
Hi Daniel,
On Mon, Jan 31, 2022 at 10:05:32PM +0100, Daniel Vetter wrote:
> Ever since Tomi extracted the core code in 2014 it's been defacto me
> maintaining this, with help from others from dri-devel and sometimes
> Linus (but those are mostly merge conflicts):
>
> $ git shortlog -ns drivers/video/fbdev/core/ | head -n5
> 35 Daniel Vetter
> 23 Linus Torvalds
> 10 Hans de Goede
> 9 Dave Airlie
> 6 Peter Rosin
>
> I think ideally we'd also record that the various firmware fb drivers
> (efifb, vesafb, ...) are also maintained in drm-misc because for the
> past few years the patches have either been to fix handover issues
> with drm drivers, or caused handover issues with drm drivers. So any
> other tree just doesn't make sense. But also, there's plenty of
> outdated MAINTAINER entries for these with people and git trees that
> haven't been active in years, so maybe let's just leave them alone.
> And furthermore distros are now adopting simpledrm as the firmware fb
> driver, so hopefully the need to care about the fbdev firmware drivers
> will go down going forward.
>
> Note that drm-misc is group maintained, I expect that to continue like
> we've done before, so no new expectations that patches all go through
> my hands. That would be silly. This also means I'm happy to put any
> other volunteer's name in the M: line, but otherwise git log says I'm
> the one who's stuck with this.
>
> Cc: Dave Airlie <airlied@gmail.com>
> Cc: Jani Nikula <jani.nikula@linux.intel.com>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: Linux Fbdev development list <linux-fbdev@vger.kernel.org>
> Cc: Pavel Machek <pavel@ucw.cz>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Javier Martinez Canillas <javierm@redhat.com>
> Cc: DRI Development <dri-devel@lists.freedesktop.org>
> Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
> Cc: Claudio Suarez <cssk@net-c.es>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Cc: Geert Uytterhoeven <geert@linux-m68k.org>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Sven Schnelle <svens@stackframe.org>
> Cc: Gerd Hoffmann <kraxel@redhat.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> ---
> MAINTAINERS | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index ea3e6c914384..49809eaa3096 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -7573,6 +7573,12 @@ S: Maintained
> W: http://floatingpoint.sourceforge.net/emulator/index.html
> F: arch/x86/math-emu/
>
> +FRAMEBUFFER CORE
> +M: Daniel Vetter <daniel@ffwll.ch>
> +F: drivers/video/fbdev/core/
Maybe add:
include/linux/fb.h
include/uapi/linux/fb.h
Both edited within some months - so they see a little changes.
With or without this:
Acked-by: Sam Ravnborg <sam@ravnborg.org>
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 01/21] MAINTAINERS: Add entry for fbdev core
@ 2022-02-03 20:25 ` Sam Ravnborg
0 siblings, 0 replies; 241+ messages in thread
From: Sam Ravnborg @ 2022-02-03 20:25 UTC (permalink / raw)
To: Daniel Vetter
Cc: DRI Development, linux-fbdev, Thomas Zimmermann, Daniel Vetter,
Intel Graphics Development, LKML, Javier Martinez Canillas,
Linus Torvalds, Tomi Valkeinen, Claudio Suarez, Gerd Hoffmann,
Pavel Machek, Greg Kroah-Hartman, Geert Uytterhoeven,
Sven Schnelle
Hi Daniel,
On Mon, Jan 31, 2022 at 10:05:32PM +0100, Daniel Vetter wrote:
> Ever since Tomi extracted the core code in 2014 it's been defacto me
> maintaining this, with help from others from dri-devel and sometimes
> Linus (but those are mostly merge conflicts):
>
> $ git shortlog -ns drivers/video/fbdev/core/ | head -n5
> 35 Daniel Vetter
> 23 Linus Torvalds
> 10 Hans de Goede
> 9 Dave Airlie
> 6 Peter Rosin
>
> I think ideally we'd also record that the various firmware fb drivers
> (efifb, vesafb, ...) are also maintained in drm-misc because for the
> past few years the patches have either been to fix handover issues
> with drm drivers, or caused handover issues with drm drivers. So any
> other tree just doesn't make sense. But also, there's plenty of
> outdated MAINTAINER entries for these with people and git trees that
> haven't been active in years, so maybe let's just leave them alone.
> And furthermore distros are now adopting simpledrm as the firmware fb
> driver, so hopefully the need to care about the fbdev firmware drivers
> will go down going forward.
>
> Note that drm-misc is group maintained, I expect that to continue like
> we've done before, so no new expectations that patches all go through
> my hands. That would be silly. This also means I'm happy to put any
> other volunteer's name in the M: line, but otherwise git log says I'm
> the one who's stuck with this.
>
> Cc: Dave Airlie <airlied@gmail.com>
> Cc: Jani Nikula <jani.nikula@linux.intel.com>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: Linux Fbdev development list <linux-fbdev@vger.kernel.org>
> Cc: Pavel Machek <pavel@ucw.cz>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Javier Martinez Canillas <javierm@redhat.com>
> Cc: DRI Development <dri-devel@lists.freedesktop.org>
> Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
> Cc: Claudio Suarez <cssk@net-c.es>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Cc: Geert Uytterhoeven <geert@linux-m68k.org>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Sven Schnelle <svens@stackframe.org>
> Cc: Gerd Hoffmann <kraxel@redhat.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> ---
> MAINTAINERS | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index ea3e6c914384..49809eaa3096 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -7573,6 +7573,12 @@ S: Maintained
> W: http://floatingpoint.sourceforge.net/emulator/index.html
> F: arch/x86/math-emu/
>
> +FRAMEBUFFER CORE
> +M: Daniel Vetter <daniel@ffwll.ch>
> +F: drivers/video/fbdev/core/
Maybe add:
include/linux/fb.h
include/uapi/linux/fb.h
Both edited within some months - so they see a little changes.
With or without this:
Acked-by: Sam Ravnborg <sam@ravnborg.org>
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 04/21] fbcon: delete a few unneeded forward decl
2022-01-31 21:05 ` Daniel Vetter
(?)
@ 2022-02-03 20:30 ` Sam Ravnborg
-1 siblings, 0 replies; 241+ messages in thread
From: Sam Ravnborg @ 2022-02-03 20:30 UTC (permalink / raw)
To: Daniel Vetter
Cc: linux-fbdev, Du Cheng, Tetsuo Handa, Greg Kroah-Hartman,
Intel Graphics Development, LKML, DRI Development,
Claudio Suarez, Thomas Zimmermann, Daniel Vetter, Helge Deller
On Mon, Jan 31, 2022 at 10:05:35PM +0100, Daniel Vetter wrote:
> I didn't bother with any code movement to fix the others, these just
> got a bit in the way.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Helge Deller <deller@gmx.de>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Du Cheng <ducheng2@gmail.com>
> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> Cc: Claudio Suarez <cssk@net-c.es>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [Intel-gfx] [PATCH 04/21] fbcon: delete a few unneeded forward decl
@ 2022-02-03 20:30 ` Sam Ravnborg
0 siblings, 0 replies; 241+ messages in thread
From: Sam Ravnborg @ 2022-02-03 20:30 UTC (permalink / raw)
To: Daniel Vetter
Cc: linux-fbdev, Du Cheng, Tetsuo Handa, Greg Kroah-Hartman,
Intel Graphics Development, LKML, DRI Development,
Thomas Zimmermann, Daniel Vetter, Helge Deller
On Mon, Jan 31, 2022 at 10:05:35PM +0100, Daniel Vetter wrote:
> I didn't bother with any code movement to fix the others, these just
> got a bit in the way.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Helge Deller <deller@gmx.de>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Du Cheng <ducheng2@gmail.com>
> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> Cc: Claudio Suarez <cssk@net-c.es>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 04/21] fbcon: delete a few unneeded forward decl
@ 2022-02-03 20:30 ` Sam Ravnborg
0 siblings, 0 replies; 241+ messages in thread
From: Sam Ravnborg @ 2022-02-03 20:30 UTC (permalink / raw)
To: Daniel Vetter
Cc: DRI Development, linux-fbdev, Thomas Zimmermann, Du Cheng,
Tetsuo Handa, Intel Graphics Development, LKML, Claudio Suarez,
Greg Kroah-Hartman, Daniel Vetter, Helge Deller
On Mon, Jan 31, 2022 at 10:05:35PM +0100, Daniel Vetter wrote:
> I didn't bother with any code movement to fix the others, these just
> got a bit in the way.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Helge Deller <deller@gmx.de>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Du Cheng <ducheng2@gmail.com>
> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> Cc: Claudio Suarez <cssk@net-c.es>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 06/21] fbcon: delete delayed loading code
2022-01-31 21:05 ` Daniel Vetter
(?)
@ 2022-02-03 20:45 ` Sam Ravnborg
-1 siblings, 0 replies; 241+ messages in thread
From: Sam Ravnborg @ 2022-02-03 20:45 UTC (permalink / raw)
To: Daniel Vetter
Cc: linux-fbdev, Du Cheng, Tetsuo Handa, Greg Kroah-Hartman,
Intel Graphics Development, LKML, DRI Development,
Claudio Suarez, Daniel Vetter, Helge Deller
Hi Daniel,
On Mon, Jan 31, 2022 at 10:05:37PM +0100, Daniel Vetter wrote:
> Before
>
> commit 6104c37094e729f3d4ce65797002112735d49cd1
> Author: Daniel Vetter <daniel.vetter@ffwll.ch>
> Date: Tue Aug 1 17:32:07 2017 +0200
>
> fbcon: Make fbcon a built-time depency for fbdev
>
> it was possible to load fbcon and fbdev drivers in any order, which
> means that fbcon init had to handle the case where fbdev drivers where
> already registered.
>
> This is no longer possible, hence delete that code.
>
> Note that the exit case is a bit more complex and will be done in a
> separate patch.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Helge Deller <deller@gmx.de>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Cc: Claudio Suarez <cssk@net-c.es>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> Cc: Du Cheng <ducheng2@gmail.com>
> ---
> drivers/video/fbdev/core/fbcon.c | 13 +------------
> 1 file changed, 1 insertion(+), 12 deletions(-)
>
> diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
> index 8f971de35885..814b648e8f09 100644
> --- a/drivers/video/fbdev/core/fbcon.c
> +++ b/drivers/video/fbdev/core/fbcon.c
> @@ -942,7 +942,7 @@ static const char *fbcon_startup(void)
> return display_desc;
> /*
> * Instead of blindly using registered_fb[0], we use info_idx, set by
> - * fb_console_init();
> + * fbcon_fb_registered();
> */
This comment change looks like it does not belong in this patch.
Also, the comment is wrong as info_idx is set in several places.
Like set_con2fb_map(), fbcon_remap_all(), and more.
Though it is not set by fb_console_init - so partly OK.
With the comment adjustment dropped.
Acked-by: Sam Ravnborg <sam@ravnborg.org>
at least the code deletion looked OK, I failed to follow all the logic.
So would be good if someone else could ack it too.
Sam
> info = registered_fb[info_idx];
> if (!info)
> @@ -3316,17 +3316,6 @@ static void fbcon_start(void)
> return;
> }
> #endif
> -
> - if (num_registered_fb) {
> - int i;
> -
> - for_each_registered_fb(i) {
> - info_idx = i;
> - break;
> - }
> -
> - do_fbcon_takeover(0);
> - }
> }
>
> static void fbcon_exit(void)
> --
> 2.33.0
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [Intel-gfx] [PATCH 06/21] fbcon: delete delayed loading code
@ 2022-02-03 20:45 ` Sam Ravnborg
0 siblings, 0 replies; 241+ messages in thread
From: Sam Ravnborg @ 2022-02-03 20:45 UTC (permalink / raw)
To: Daniel Vetter
Cc: linux-fbdev, Du Cheng, Tetsuo Handa, Greg Kroah-Hartman,
Intel Graphics Development, LKML, DRI Development, Daniel Vetter,
Helge Deller
Hi Daniel,
On Mon, Jan 31, 2022 at 10:05:37PM +0100, Daniel Vetter wrote:
> Before
>
> commit 6104c37094e729f3d4ce65797002112735d49cd1
> Author: Daniel Vetter <daniel.vetter@ffwll.ch>
> Date: Tue Aug 1 17:32:07 2017 +0200
>
> fbcon: Make fbcon a built-time depency for fbdev
>
> it was possible to load fbcon and fbdev drivers in any order, which
> means that fbcon init had to handle the case where fbdev drivers where
> already registered.
>
> This is no longer possible, hence delete that code.
>
> Note that the exit case is a bit more complex and will be done in a
> separate patch.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Helge Deller <deller@gmx.de>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Cc: Claudio Suarez <cssk@net-c.es>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> Cc: Du Cheng <ducheng2@gmail.com>
> ---
> drivers/video/fbdev/core/fbcon.c | 13 +------------
> 1 file changed, 1 insertion(+), 12 deletions(-)
>
> diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
> index 8f971de35885..814b648e8f09 100644
> --- a/drivers/video/fbdev/core/fbcon.c
> +++ b/drivers/video/fbdev/core/fbcon.c
> @@ -942,7 +942,7 @@ static const char *fbcon_startup(void)
> return display_desc;
> /*
> * Instead of blindly using registered_fb[0], we use info_idx, set by
> - * fb_console_init();
> + * fbcon_fb_registered();
> */
This comment change looks like it does not belong in this patch.
Also, the comment is wrong as info_idx is set in several places.
Like set_con2fb_map(), fbcon_remap_all(), and more.
Though it is not set by fb_console_init - so partly OK.
With the comment adjustment dropped.
Acked-by: Sam Ravnborg <sam@ravnborg.org>
at least the code deletion looked OK, I failed to follow all the logic.
So would be good if someone else could ack it too.
Sam
> info = registered_fb[info_idx];
> if (!info)
> @@ -3316,17 +3316,6 @@ static void fbcon_start(void)
> return;
> }
> #endif
> -
> - if (num_registered_fb) {
> - int i;
> -
> - for_each_registered_fb(i) {
> - info_idx = i;
> - break;
> - }
> -
> - do_fbcon_takeover(0);
> - }
> }
>
> static void fbcon_exit(void)
> --
> 2.33.0
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 06/21] fbcon: delete delayed loading code
@ 2022-02-03 20:45 ` Sam Ravnborg
0 siblings, 0 replies; 241+ messages in thread
From: Sam Ravnborg @ 2022-02-03 20:45 UTC (permalink / raw)
To: Daniel Vetter
Cc: DRI Development, linux-fbdev, Du Cheng, Tetsuo Handa,
Intel Graphics Development, LKML, Claudio Suarez,
Greg Kroah-Hartman, Daniel Vetter, Helge Deller
Hi Daniel,
On Mon, Jan 31, 2022 at 10:05:37PM +0100, Daniel Vetter wrote:
> Before
>
> commit 6104c37094e729f3d4ce65797002112735d49cd1
> Author: Daniel Vetter <daniel.vetter@ffwll.ch>
> Date: Tue Aug 1 17:32:07 2017 +0200
>
> fbcon: Make fbcon a built-time depency for fbdev
>
> it was possible to load fbcon and fbdev drivers in any order, which
> means that fbcon init had to handle the case where fbdev drivers where
> already registered.
>
> This is no longer possible, hence delete that code.
>
> Note that the exit case is a bit more complex and will be done in a
> separate patch.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Helge Deller <deller@gmx.de>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Cc: Claudio Suarez <cssk@net-c.es>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> Cc: Du Cheng <ducheng2@gmail.com>
> ---
> drivers/video/fbdev/core/fbcon.c | 13 +------------
> 1 file changed, 1 insertion(+), 12 deletions(-)
>
> diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
> index 8f971de35885..814b648e8f09 100644
> --- a/drivers/video/fbdev/core/fbcon.c
> +++ b/drivers/video/fbdev/core/fbcon.c
> @@ -942,7 +942,7 @@ static const char *fbcon_startup(void)
> return display_desc;
> /*
> * Instead of blindly using registered_fb[0], we use info_idx, set by
> - * fb_console_init();
> + * fbcon_fb_registered();
> */
This comment change looks like it does not belong in this patch.
Also, the comment is wrong as info_idx is set in several places.
Like set_con2fb_map(), fbcon_remap_all(), and more.
Though it is not set by fb_console_init - so partly OK.
With the comment adjustment dropped.
Acked-by: Sam Ravnborg <sam@ravnborg.org>
at least the code deletion looked OK, I failed to follow all the logic.
So would be good if someone else could ack it too.
Sam
> info = registered_fb[info_idx];
> if (!info)
> @@ -3316,17 +3316,6 @@ static void fbcon_start(void)
> return;
> }
> #endif
> -
> - if (num_registered_fb) {
> - int i;
> -
> - for_each_registered_fb(i) {
> - info_idx = i;
> - break;
> - }
> -
> - do_fbcon_takeover(0);
> - }
> }
>
> static void fbcon_exit(void)
> --
> 2.33.0
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 11/21] fbcon: Extract fbcon_open/release helpers
2022-01-31 21:05 ` [Intel-gfx] " Daniel Vetter
(?)
@ 2022-02-03 21:15 ` Sam Ravnborg
-1 siblings, 0 replies; 241+ messages in thread
From: Sam Ravnborg @ 2022-02-03 21:15 UTC (permalink / raw)
To: Daniel Vetter
Cc: linux-fbdev, Du Cheng, Tetsuo Handa, Greg Kroah-Hartman,
Intel Graphics Development, LKML, DRI Development,
Claudio Suarez, Daniel Vetter
Hi Daniel,
On Mon, Jan 31, 2022 at 10:05:42PM +0100, Daniel Vetter wrote:
> There's two minor behaviour changes in here:
> - in error paths we now consistently call fb_ops->fb_release
> - fb_release really can't fail (fbmem.c ignores it too) and there's no
> reasonable cleanup we can do anyway.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Cc: Claudio Suarez <cssk@net-c.es>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> Cc: Du Cheng <ducheng2@gmail.com>
> ---
> drivers/video/fbdev/core/fbcon.c | 107 +++++++++++++++----------------
> 1 file changed, 53 insertions(+), 54 deletions(-)
>
> diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
> index fa30e1909164..eea2ee14b64c 100644
> --- a/drivers/video/fbdev/core/fbcon.c
> +++ b/drivers/video/fbdev/core/fbcon.c
> @@ -680,19 +680,37 @@ static int fbcon_invalid_charcount(struct fb_info *info, unsigned charcount)
>
> #endif /* CONFIG_MISC_TILEBLITTING */
>
> +static int fbcon_open(struct fb_info *info)
> +{
> + if (!try_module_get(info->fbops->owner))
> + return -ENODEV;
> +
> + if (info->fbops->fb_open &&
> + info->fbops->fb_open(info, 0)) {
> + module_put(info->fbops->owner);
> + return -ENODEV;
> + }
> +
> + return 0;
> +}
> +
> +static void fbcon_release(struct fb_info *info)
> +{
> + if (info->fbops->fb_release)
> + info->fbops->fb_release(info, 0);
> +
> + module_put(info->fbops->owner);
> +}
>
> static int con2fb_acquire_newinfo(struct vc_data *vc, struct fb_info *info,
> int unit, int oldidx)
> {
> struct fbcon_ops *ops = NULL;
> - int err = 0;
> -
> - if (!try_module_get(info->fbops->owner))
> - err = -ENODEV;
> + int err;
>
> - if (!err && info->fbops->fb_open &&
> - info->fbops->fb_open(info, 0))
> - err = -ENODEV;
> + err = fbcon_open(info);
> + if (err)
> + return err;
>
> if (!err) {
> ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL);
> @@ -713,7 +731,7 @@ static int con2fb_acquire_newinfo(struct vc_data *vc, struct fb_info *info,
>
> if (err) {
> con2fb_map[unit] = oldidx;
> - module_put(info->fbops->owner);
> + fbcon_release(info);
> }
>
> return err;
> @@ -724,45 +742,34 @@ static int con2fb_release_oldinfo(struct vc_data *vc, struct fb_info *oldinfo,
> int oldidx, int found)
> {
> struct fbcon_ops *ops = oldinfo->fbcon_par;
> - int err = 0, ret;
> + int ret;
>
> - if (oldinfo->fbops->fb_release &&
> - oldinfo->fbops->fb_release(oldinfo, 0)) {
> - con2fb_map[unit] = oldidx;
The old code assigns con2fb_map[unit] before is calls
newinfo->fbops->fb_release).
I wonder if there can be any callback to fbcon where the value
of con2fb_map[unit] matters?
> - if (!found && newinfo->fbops->fb_release)
> - newinfo->fbops->fb_release(newinfo, 0);
> - if (!found)
> - module_put(newinfo->fbops->owner);
> - err = -ENODEV;
> - }
> + fbcon_release(oldinfo);
>
> - if (!err) {
> - fbcon_del_cursor_work(oldinfo);
> - kfree(ops->cursor_state.mask);
> - kfree(ops->cursor_data);
> - kfree(ops->cursor_src);
> - kfree(ops->fontbuffer);
> - kfree(oldinfo->fbcon_par);
> - oldinfo->fbcon_par = NULL;
> - module_put(oldinfo->fbops->owner);
> - /*
> - If oldinfo and newinfo are driving the same hardware,
> - the fb_release() method of oldinfo may attempt to
> - restore the hardware state. This will leave the
> - newinfo in an undefined state. Thus, a call to
> - fb_set_par() may be needed for the newinfo.
> - */
> - if (newinfo && newinfo->fbops->fb_set_par) {
> - ret = newinfo->fbops->fb_set_par(newinfo);
> + fbcon_del_cursor_work(oldinfo);
> + kfree(ops->cursor_state.mask);
> + kfree(ops->cursor_data);
> + kfree(ops->cursor_src);
> + kfree(ops->fontbuffer);
> + kfree(oldinfo->fbcon_par);
> + oldinfo->fbcon_par = NULL;
These all look like candidates to stuff into fbcon_release()
That would drop the nice symmetry but make it more consistent.
I think we miss freeing ops->cursor_data in fbcon_exit(),
but I did not follow all the code.
With my ramblings considered the patch is
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Sam
> + /*
> + If oldinfo and newinfo are driving the same hardware,
> + the fb_release() method of oldinfo may attempt to
> + restore the hardware state. This will leave the
> + newinfo in an undefined state. Thus, a call to
> + fb_set_par() may be needed for the newinfo.
> + */
> + if (newinfo && newinfo->fbops->fb_set_par) {
> + ret = newinfo->fbops->fb_set_par(newinfo);
>
> - if (ret)
> - printk(KERN_ERR "con2fb_release_oldinfo: "
> - "detected unhandled fb_set_par error, "
> - "error code %d\n", ret);
> - }
> + if (ret)
> + printk(KERN_ERR "con2fb_release_oldinfo: "
> + "detected unhandled fb_set_par error, "
> + "error code %d\n", ret);
> }
>
> - return err;
> + return 0;
> }
>
> static void con2fb_init_display(struct vc_data *vc, struct fb_info *info,
> @@ -917,7 +924,6 @@ static const char *fbcon_startup(void)
> struct fbcon_display *p = &fb_display[fg_console];
> struct vc_data *vc = vc_cons[fg_console].d;
> const struct font_desc *font = NULL;
> - struct module *owner;
> struct fb_info *info = NULL;
> struct fbcon_ops *ops;
> int rows, cols;
> @@ -936,17 +942,12 @@ static const char *fbcon_startup(void)
> if (!info)
> return NULL;
>
> - owner = info->fbops->owner;
> - if (!try_module_get(owner))
> + if (fbcon_open(info))
> return NULL;
> - if (info->fbops->fb_open && info->fbops->fb_open(info, 0)) {
> - module_put(owner);
> - return NULL;
> - }
>
> ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL);
> if (!ops) {
> - module_put(owner);
> + fbcon_release(info);
> return NULL;
> }
>
> @@ -3331,10 +3332,6 @@ static void fbcon_exit(void)
> }
>
> if (mapped) {
> - if (info->fbops->fb_release)
> - info->fbops->fb_release(info, 0);
> - module_put(info->fbops->owner);
> -
> if (info->fbcon_par) {
> struct fbcon_ops *ops = info->fbcon_par;
>
> @@ -3344,6 +3341,8 @@ static void fbcon_exit(void)
> kfree(info->fbcon_par);
> info->fbcon_par = NULL;
> }
> +
> + fbcon_release(info);
> }
> }
> }
> --
> 2.33.0
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [Intel-gfx] [PATCH 11/21] fbcon: Extract fbcon_open/release helpers
@ 2022-02-03 21:15 ` Sam Ravnborg
0 siblings, 0 replies; 241+ messages in thread
From: Sam Ravnborg @ 2022-02-03 21:15 UTC (permalink / raw)
To: Daniel Vetter
Cc: linux-fbdev, Du Cheng, Tetsuo Handa, Greg Kroah-Hartman,
Intel Graphics Development, LKML, DRI Development, Daniel Vetter
Hi Daniel,
On Mon, Jan 31, 2022 at 10:05:42PM +0100, Daniel Vetter wrote:
> There's two minor behaviour changes in here:
> - in error paths we now consistently call fb_ops->fb_release
> - fb_release really can't fail (fbmem.c ignores it too) and there's no
> reasonable cleanup we can do anyway.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Cc: Claudio Suarez <cssk@net-c.es>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> Cc: Du Cheng <ducheng2@gmail.com>
> ---
> drivers/video/fbdev/core/fbcon.c | 107 +++++++++++++++----------------
> 1 file changed, 53 insertions(+), 54 deletions(-)
>
> diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
> index fa30e1909164..eea2ee14b64c 100644
> --- a/drivers/video/fbdev/core/fbcon.c
> +++ b/drivers/video/fbdev/core/fbcon.c
> @@ -680,19 +680,37 @@ static int fbcon_invalid_charcount(struct fb_info *info, unsigned charcount)
>
> #endif /* CONFIG_MISC_TILEBLITTING */
>
> +static int fbcon_open(struct fb_info *info)
> +{
> + if (!try_module_get(info->fbops->owner))
> + return -ENODEV;
> +
> + if (info->fbops->fb_open &&
> + info->fbops->fb_open(info, 0)) {
> + module_put(info->fbops->owner);
> + return -ENODEV;
> + }
> +
> + return 0;
> +}
> +
> +static void fbcon_release(struct fb_info *info)
> +{
> + if (info->fbops->fb_release)
> + info->fbops->fb_release(info, 0);
> +
> + module_put(info->fbops->owner);
> +}
>
> static int con2fb_acquire_newinfo(struct vc_data *vc, struct fb_info *info,
> int unit, int oldidx)
> {
> struct fbcon_ops *ops = NULL;
> - int err = 0;
> -
> - if (!try_module_get(info->fbops->owner))
> - err = -ENODEV;
> + int err;
>
> - if (!err && info->fbops->fb_open &&
> - info->fbops->fb_open(info, 0))
> - err = -ENODEV;
> + err = fbcon_open(info);
> + if (err)
> + return err;
>
> if (!err) {
> ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL);
> @@ -713,7 +731,7 @@ static int con2fb_acquire_newinfo(struct vc_data *vc, struct fb_info *info,
>
> if (err) {
> con2fb_map[unit] = oldidx;
> - module_put(info->fbops->owner);
> + fbcon_release(info);
> }
>
> return err;
> @@ -724,45 +742,34 @@ static int con2fb_release_oldinfo(struct vc_data *vc, struct fb_info *oldinfo,
> int oldidx, int found)
> {
> struct fbcon_ops *ops = oldinfo->fbcon_par;
> - int err = 0, ret;
> + int ret;
>
> - if (oldinfo->fbops->fb_release &&
> - oldinfo->fbops->fb_release(oldinfo, 0)) {
> - con2fb_map[unit] = oldidx;
The old code assigns con2fb_map[unit] before is calls
newinfo->fbops->fb_release).
I wonder if there can be any callback to fbcon where the value
of con2fb_map[unit] matters?
> - if (!found && newinfo->fbops->fb_release)
> - newinfo->fbops->fb_release(newinfo, 0);
> - if (!found)
> - module_put(newinfo->fbops->owner);
> - err = -ENODEV;
> - }
> + fbcon_release(oldinfo);
>
> - if (!err) {
> - fbcon_del_cursor_work(oldinfo);
> - kfree(ops->cursor_state.mask);
> - kfree(ops->cursor_data);
> - kfree(ops->cursor_src);
> - kfree(ops->fontbuffer);
> - kfree(oldinfo->fbcon_par);
> - oldinfo->fbcon_par = NULL;
> - module_put(oldinfo->fbops->owner);
> - /*
> - If oldinfo and newinfo are driving the same hardware,
> - the fb_release() method of oldinfo may attempt to
> - restore the hardware state. This will leave the
> - newinfo in an undefined state. Thus, a call to
> - fb_set_par() may be needed for the newinfo.
> - */
> - if (newinfo && newinfo->fbops->fb_set_par) {
> - ret = newinfo->fbops->fb_set_par(newinfo);
> + fbcon_del_cursor_work(oldinfo);
> + kfree(ops->cursor_state.mask);
> + kfree(ops->cursor_data);
> + kfree(ops->cursor_src);
> + kfree(ops->fontbuffer);
> + kfree(oldinfo->fbcon_par);
> + oldinfo->fbcon_par = NULL;
These all look like candidates to stuff into fbcon_release()
That would drop the nice symmetry but make it more consistent.
I think we miss freeing ops->cursor_data in fbcon_exit(),
but I did not follow all the code.
With my ramblings considered the patch is
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Sam
> + /*
> + If oldinfo and newinfo are driving the same hardware,
> + the fb_release() method of oldinfo may attempt to
> + restore the hardware state. This will leave the
> + newinfo in an undefined state. Thus, a call to
> + fb_set_par() may be needed for the newinfo.
> + */
> + if (newinfo && newinfo->fbops->fb_set_par) {
> + ret = newinfo->fbops->fb_set_par(newinfo);
>
> - if (ret)
> - printk(KERN_ERR "con2fb_release_oldinfo: "
> - "detected unhandled fb_set_par error, "
> - "error code %d\n", ret);
> - }
> + if (ret)
> + printk(KERN_ERR "con2fb_release_oldinfo: "
> + "detected unhandled fb_set_par error, "
> + "error code %d\n", ret);
> }
>
> - return err;
> + return 0;
> }
>
> static void con2fb_init_display(struct vc_data *vc, struct fb_info *info,
> @@ -917,7 +924,6 @@ static const char *fbcon_startup(void)
> struct fbcon_display *p = &fb_display[fg_console];
> struct vc_data *vc = vc_cons[fg_console].d;
> const struct font_desc *font = NULL;
> - struct module *owner;
> struct fb_info *info = NULL;
> struct fbcon_ops *ops;
> int rows, cols;
> @@ -936,17 +942,12 @@ static const char *fbcon_startup(void)
> if (!info)
> return NULL;
>
> - owner = info->fbops->owner;
> - if (!try_module_get(owner))
> + if (fbcon_open(info))
> return NULL;
> - if (info->fbops->fb_open && info->fbops->fb_open(info, 0)) {
> - module_put(owner);
> - return NULL;
> - }
>
> ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL);
> if (!ops) {
> - module_put(owner);
> + fbcon_release(info);
> return NULL;
> }
>
> @@ -3331,10 +3332,6 @@ static void fbcon_exit(void)
> }
>
> if (mapped) {
> - if (info->fbops->fb_release)
> - info->fbops->fb_release(info, 0);
> - module_put(info->fbops->owner);
> -
> if (info->fbcon_par) {
> struct fbcon_ops *ops = info->fbcon_par;
>
> @@ -3344,6 +3341,8 @@ static void fbcon_exit(void)
> kfree(info->fbcon_par);
> info->fbcon_par = NULL;
> }
> +
> + fbcon_release(info);
> }
> }
> }
> --
> 2.33.0
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 11/21] fbcon: Extract fbcon_open/release helpers
@ 2022-02-03 21:15 ` Sam Ravnborg
0 siblings, 0 replies; 241+ messages in thread
From: Sam Ravnborg @ 2022-02-03 21:15 UTC (permalink / raw)
To: Daniel Vetter
Cc: DRI Development, linux-fbdev, Du Cheng, Tetsuo Handa,
Intel Graphics Development, LKML, Claudio Suarez,
Greg Kroah-Hartman, Daniel Vetter
Hi Daniel,
On Mon, Jan 31, 2022 at 10:05:42PM +0100, Daniel Vetter wrote:
> There's two minor behaviour changes in here:
> - in error paths we now consistently call fb_ops->fb_release
> - fb_release really can't fail (fbmem.c ignores it too) and there's no
> reasonable cleanup we can do anyway.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Cc: Claudio Suarez <cssk@net-c.es>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> Cc: Du Cheng <ducheng2@gmail.com>
> ---
> drivers/video/fbdev/core/fbcon.c | 107 +++++++++++++++----------------
> 1 file changed, 53 insertions(+), 54 deletions(-)
>
> diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
> index fa30e1909164..eea2ee14b64c 100644
> --- a/drivers/video/fbdev/core/fbcon.c
> +++ b/drivers/video/fbdev/core/fbcon.c
> @@ -680,19 +680,37 @@ static int fbcon_invalid_charcount(struct fb_info *info, unsigned charcount)
>
> #endif /* CONFIG_MISC_TILEBLITTING */
>
> +static int fbcon_open(struct fb_info *info)
> +{
> + if (!try_module_get(info->fbops->owner))
> + return -ENODEV;
> +
> + if (info->fbops->fb_open &&
> + info->fbops->fb_open(info, 0)) {
> + module_put(info->fbops->owner);
> + return -ENODEV;
> + }
> +
> + return 0;
> +}
> +
> +static void fbcon_release(struct fb_info *info)
> +{
> + if (info->fbops->fb_release)
> + info->fbops->fb_release(info, 0);
> +
> + module_put(info->fbops->owner);
> +}
>
> static int con2fb_acquire_newinfo(struct vc_data *vc, struct fb_info *info,
> int unit, int oldidx)
> {
> struct fbcon_ops *ops = NULL;
> - int err = 0;
> -
> - if (!try_module_get(info->fbops->owner))
> - err = -ENODEV;
> + int err;
>
> - if (!err && info->fbops->fb_open &&
> - info->fbops->fb_open(info, 0))
> - err = -ENODEV;
> + err = fbcon_open(info);
> + if (err)
> + return err;
>
> if (!err) {
> ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL);
> @@ -713,7 +731,7 @@ static int con2fb_acquire_newinfo(struct vc_data *vc, struct fb_info *info,
>
> if (err) {
> con2fb_map[unit] = oldidx;
> - module_put(info->fbops->owner);
> + fbcon_release(info);
> }
>
> return err;
> @@ -724,45 +742,34 @@ static int con2fb_release_oldinfo(struct vc_data *vc, struct fb_info *oldinfo,
> int oldidx, int found)
> {
> struct fbcon_ops *ops = oldinfo->fbcon_par;
> - int err = 0, ret;
> + int ret;
>
> - if (oldinfo->fbops->fb_release &&
> - oldinfo->fbops->fb_release(oldinfo, 0)) {
> - con2fb_map[unit] = oldidx;
The old code assigns con2fb_map[unit] before is calls
newinfo->fbops->fb_release).
I wonder if there can be any callback to fbcon where the value
of con2fb_map[unit] matters?
> - if (!found && newinfo->fbops->fb_release)
> - newinfo->fbops->fb_release(newinfo, 0);
> - if (!found)
> - module_put(newinfo->fbops->owner);
> - err = -ENODEV;
> - }
> + fbcon_release(oldinfo);
>
> - if (!err) {
> - fbcon_del_cursor_work(oldinfo);
> - kfree(ops->cursor_state.mask);
> - kfree(ops->cursor_data);
> - kfree(ops->cursor_src);
> - kfree(ops->fontbuffer);
> - kfree(oldinfo->fbcon_par);
> - oldinfo->fbcon_par = NULL;
> - module_put(oldinfo->fbops->owner);
> - /*
> - If oldinfo and newinfo are driving the same hardware,
> - the fb_release() method of oldinfo may attempt to
> - restore the hardware state. This will leave the
> - newinfo in an undefined state. Thus, a call to
> - fb_set_par() may be needed for the newinfo.
> - */
> - if (newinfo && newinfo->fbops->fb_set_par) {
> - ret = newinfo->fbops->fb_set_par(newinfo);
> + fbcon_del_cursor_work(oldinfo);
> + kfree(ops->cursor_state.mask);
> + kfree(ops->cursor_data);
> + kfree(ops->cursor_src);
> + kfree(ops->fontbuffer);
> + kfree(oldinfo->fbcon_par);
> + oldinfo->fbcon_par = NULL;
These all look like candidates to stuff into fbcon_release()
That would drop the nice symmetry but make it more consistent.
I think we miss freeing ops->cursor_data in fbcon_exit(),
but I did not follow all the code.
With my ramblings considered the patch is
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Sam
> + /*
> + If oldinfo and newinfo are driving the same hardware,
> + the fb_release() method of oldinfo may attempt to
> + restore the hardware state. This will leave the
> + newinfo in an undefined state. Thus, a call to
> + fb_set_par() may be needed for the newinfo.
> + */
> + if (newinfo && newinfo->fbops->fb_set_par) {
> + ret = newinfo->fbops->fb_set_par(newinfo);
>
> - if (ret)
> - printk(KERN_ERR "con2fb_release_oldinfo: "
> - "detected unhandled fb_set_par error, "
> - "error code %d\n", ret);
> - }
> + if (ret)
> + printk(KERN_ERR "con2fb_release_oldinfo: "
> + "detected unhandled fb_set_par error, "
> + "error code %d\n", ret);
> }
>
> - return err;
> + return 0;
> }
>
> static void con2fb_init_display(struct vc_data *vc, struct fb_info *info,
> @@ -917,7 +924,6 @@ static const char *fbcon_startup(void)
> struct fbcon_display *p = &fb_display[fg_console];
> struct vc_data *vc = vc_cons[fg_console].d;
> const struct font_desc *font = NULL;
> - struct module *owner;
> struct fb_info *info = NULL;
> struct fbcon_ops *ops;
> int rows, cols;
> @@ -936,17 +942,12 @@ static const char *fbcon_startup(void)
> if (!info)
> return NULL;
>
> - owner = info->fbops->owner;
> - if (!try_module_get(owner))
> + if (fbcon_open(info))
> return NULL;
> - if (info->fbops->fb_open && info->fbops->fb_open(info, 0)) {
> - module_put(owner);
> - return NULL;
> - }
>
> ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL);
> if (!ops) {
> - module_put(owner);
> + fbcon_release(info);
> return NULL;
> }
>
> @@ -3331,10 +3332,6 @@ static void fbcon_exit(void)
> }
>
> if (mapped) {
> - if (info->fbops->fb_release)
> - info->fbops->fb_release(info, 0);
> - module_put(info->fbops->owner);
> -
> if (info->fbcon_par) {
> struct fbcon_ops *ops = info->fbcon_par;
>
> @@ -3344,6 +3341,8 @@ static void fbcon_exit(void)
> kfree(info->fbcon_par);
> info->fbcon_par = NULL;
> }
> +
> + fbcon_release(info);
> }
> }
> }
> --
> 2.33.0
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 12/21] fbcon: Ditch error handling for con2fb_release_oldinfo
2022-01-31 21:05 ` Daniel Vetter
(?)
@ 2022-02-03 21:16 ` Sam Ravnborg
-1 siblings, 0 replies; 241+ messages in thread
From: Sam Ravnborg @ 2022-02-03 21:16 UTC (permalink / raw)
To: Daniel Vetter
Cc: linux-fbdev, Du Cheng, Tetsuo Handa, Greg Kroah-Hartman,
Intel Graphics Development, LKML, DRI Development,
Claudio Suarez, Thomas Zimmermann, Daniel Vetter
On Mon, Jan 31, 2022 at 10:05:43PM +0100, Daniel Vetter wrote:
> It doesn't ever fail anymore.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Claudio Suarez <cssk@net-c.es>
> Cc: Du Cheng <ducheng2@gmail.com>
> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [Intel-gfx] [PATCH 12/21] fbcon: Ditch error handling for con2fb_release_oldinfo
@ 2022-02-03 21:16 ` Sam Ravnborg
0 siblings, 0 replies; 241+ messages in thread
From: Sam Ravnborg @ 2022-02-03 21:16 UTC (permalink / raw)
To: Daniel Vetter
Cc: linux-fbdev, Du Cheng, Tetsuo Handa, Greg Kroah-Hartman,
Intel Graphics Development, LKML, DRI Development,
Thomas Zimmermann, Daniel Vetter
On Mon, Jan 31, 2022 at 10:05:43PM +0100, Daniel Vetter wrote:
> It doesn't ever fail anymore.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Claudio Suarez <cssk@net-c.es>
> Cc: Du Cheng <ducheng2@gmail.com>
> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 12/21] fbcon: Ditch error handling for con2fb_release_oldinfo
@ 2022-02-03 21:16 ` Sam Ravnborg
0 siblings, 0 replies; 241+ messages in thread
From: Sam Ravnborg @ 2022-02-03 21:16 UTC (permalink / raw)
To: Daniel Vetter
Cc: DRI Development, linux-fbdev, Thomas Zimmermann, Du Cheng,
Tetsuo Handa, Intel Graphics Development, LKML, Claudio Suarez,
Greg Kroah-Hartman, Daniel Vetter
On Mon, Jan 31, 2022 at 10:05:43PM +0100, Daniel Vetter wrote:
> It doesn't ever fail anymore.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Claudio Suarez <cssk@net-c.es>
> Cc: Du Cheng <ducheng2@gmail.com>
> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 05/21] fbcon: Introduce wrapper for console->fb_info lookup
2022-01-31 21:05 ` Daniel Vetter
(?)
@ 2022-02-03 21:25 ` Sam Ravnborg
-1 siblings, 0 replies; 241+ messages in thread
From: Sam Ravnborg @ 2022-02-03 21:25 UTC (permalink / raw)
To: Daniel Vetter
Cc: linux-fbdev, Du Cheng, Tetsuo Handa, Greg Kroah-Hartman,
Intel Graphics Development, LKML, DRI Development,
Claudio Suarez, Thomas Zimmermann, Daniel Vetter, Helge Deller
On Mon, Jan 31, 2022 at 10:05:36PM +0100, Daniel Vetter wrote:
> Half of it is protected by console_lock, but the other half is a lot
> more awkward: Registration/deregistration of fbdev are serialized, but
> we don't really clear out anything in con2fb_map and so there's
> potential for use-after free mixups.
>
> First step is to encapsulate the lookup.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Helge Deller <deller@gmx.de>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> Cc: Du Cheng <ducheng2@gmail.com>
> Cc: Claudio Suarez <cssk@net-c.es>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [Intel-gfx] [PATCH 05/21] fbcon: Introduce wrapper for console->fb_info lookup
@ 2022-02-03 21:25 ` Sam Ravnborg
0 siblings, 0 replies; 241+ messages in thread
From: Sam Ravnborg @ 2022-02-03 21:25 UTC (permalink / raw)
To: Daniel Vetter
Cc: linux-fbdev, Du Cheng, Tetsuo Handa, Greg Kroah-Hartman,
Intel Graphics Development, LKML, DRI Development,
Thomas Zimmermann, Daniel Vetter, Helge Deller
On Mon, Jan 31, 2022 at 10:05:36PM +0100, Daniel Vetter wrote:
> Half of it is protected by console_lock, but the other half is a lot
> more awkward: Registration/deregistration of fbdev are serialized, but
> we don't really clear out anything in con2fb_map and so there's
> potential for use-after free mixups.
>
> First step is to encapsulate the lookup.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Helge Deller <deller@gmx.de>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> Cc: Du Cheng <ducheng2@gmail.com>
> Cc: Claudio Suarez <cssk@net-c.es>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 05/21] fbcon: Introduce wrapper for console->fb_info lookup
@ 2022-02-03 21:25 ` Sam Ravnborg
0 siblings, 0 replies; 241+ messages in thread
From: Sam Ravnborg @ 2022-02-03 21:25 UTC (permalink / raw)
To: Daniel Vetter
Cc: DRI Development, linux-fbdev, Thomas Zimmermann, Du Cheng,
Tetsuo Handa, Intel Graphics Development, LKML, Claudio Suarez,
Greg Kroah-Hartman, Daniel Vetter, Helge Deller
On Mon, Jan 31, 2022 at 10:05:36PM +0100, Daniel Vetter wrote:
> Half of it is protected by console_lock, but the other half is a lot
> more awkward: Registration/deregistration of fbdev are serialized, but
> we don't really clear out anything in con2fb_map and so there's
> potential for use-after free mixups.
>
> First step is to encapsulate the lookup.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Helge Deller <deller@gmx.de>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> Cc: Du Cheng <ducheng2@gmail.com>
> Cc: Claudio Suarez <cssk@net-c.es>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 07/21] fbdev/sysfs: Fix locking
2022-01-31 21:05 ` Daniel Vetter
(?)
@ 2022-02-03 21:27 ` Sam Ravnborg
-1 siblings, 0 replies; 241+ messages in thread
From: Sam Ravnborg @ 2022-02-03 21:27 UTC (permalink / raw)
To: Daniel Vetter
Cc: linux-fbdev, Intel Graphics Development, LKML, DRI Development,
Qing Wang, Daniel Vetter, Helge Deller
On Mon, Jan 31, 2022 at 10:05:38PM +0100, Daniel Vetter wrote:
> fb_set_var requires we hold the fb_info lock. Or at least this now
> matches what the ioctl does ...
>
> Note that ps3fb and sh_mobile_lcdcfb are busted in different ways here,
> but I will not fix them up.
>
> Also in practice this isn't a big deal, because really variable fbdev
> state is actually protected by console_lock (because fbcon just
> doesn't bother with lock_fb_info() at all), and lock_fb_info
> protecting anything is really just a neat lie. But that's a much
> bigger fish to fry.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Helge Deller <deller@gmx.de>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Cc: Qing Wang <wangqing@vivo.com>
> Cc: Sam Ravnborg <sam@ravnborg.org>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [Intel-gfx] [PATCH 07/21] fbdev/sysfs: Fix locking
@ 2022-02-03 21:27 ` Sam Ravnborg
0 siblings, 0 replies; 241+ messages in thread
From: Sam Ravnborg @ 2022-02-03 21:27 UTC (permalink / raw)
To: Daniel Vetter
Cc: linux-fbdev, Intel Graphics Development, LKML, DRI Development,
Qing Wang, Daniel Vetter, Helge Deller
On Mon, Jan 31, 2022 at 10:05:38PM +0100, Daniel Vetter wrote:
> fb_set_var requires we hold the fb_info lock. Or at least this now
> matches what the ioctl does ...
>
> Note that ps3fb and sh_mobile_lcdcfb are busted in different ways here,
> but I will not fix them up.
>
> Also in practice this isn't a big deal, because really variable fbdev
> state is actually protected by console_lock (because fbcon just
> doesn't bother with lock_fb_info() at all), and lock_fb_info
> protecting anything is really just a neat lie. But that's a much
> bigger fish to fry.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Helge Deller <deller@gmx.de>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Cc: Qing Wang <wangqing@vivo.com>
> Cc: Sam Ravnborg <sam@ravnborg.org>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 07/21] fbdev/sysfs: Fix locking
@ 2022-02-03 21:27 ` Sam Ravnborg
0 siblings, 0 replies; 241+ messages in thread
From: Sam Ravnborg @ 2022-02-03 21:27 UTC (permalink / raw)
To: Daniel Vetter
Cc: DRI Development, linux-fbdev, Intel Graphics Development, LKML,
Qing Wang, Daniel Vetter, Helge Deller
On Mon, Jan 31, 2022 at 10:05:38PM +0100, Daniel Vetter wrote:
> fb_set_var requires we hold the fb_info lock. Or at least this now
> matches what the ioctl does ...
>
> Note that ps3fb and sh_mobile_lcdcfb are busted in different ways here,
> but I will not fix them up.
>
> Also in practice this isn't a big deal, because really variable fbdev
> state is actually protected by console_lock (because fbcon just
> doesn't bother with lock_fb_info() at all), and lock_fb_info
> protecting anything is really just a neat lie. But that's a much
> bigger fish to fry.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Helge Deller <deller@gmx.de>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Cc: Qing Wang <wangqing@vivo.com>
> Cc: Sam Ravnborg <sam@ravnborg.org>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 09/21] fbcon: Replace FBCON_FLAGS_INIT with a boolean
2022-01-31 21:05 ` Daniel Vetter
(?)
@ 2022-02-03 21:30 ` Sam Ravnborg
-1 siblings, 0 replies; 241+ messages in thread
From: Sam Ravnborg @ 2022-02-03 21:30 UTC (permalink / raw)
To: Daniel Vetter
Cc: linux-fbdev, Du Cheng, Tetsuo Handa, Greg Kroah-Hartman,
Intel Graphics Development, LKML, DRI Development,
Claudio Suarez, Thomas Zimmermann, Daniel Vetter
On Mon, Jan 31, 2022 at 10:05:40PM +0100, Daniel Vetter wrote:
> It's only one flag and slightly tidier code.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Du Cheng <ducheng2@gmail.com>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Claudio Suarez <cssk@net-c.es>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Next step is to convert some of the int flags to bool - so it is obvious
this is bool and not an int.
I do not like bitfields for bools when there is no big win in memory
usage - so not fan of that suggestion.
Sam
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [Intel-gfx] [PATCH 09/21] fbcon: Replace FBCON_FLAGS_INIT with a boolean
@ 2022-02-03 21:30 ` Sam Ravnborg
0 siblings, 0 replies; 241+ messages in thread
From: Sam Ravnborg @ 2022-02-03 21:30 UTC (permalink / raw)
To: Daniel Vetter
Cc: linux-fbdev, Du Cheng, Tetsuo Handa, Greg Kroah-Hartman,
Intel Graphics Development, LKML, DRI Development,
Thomas Zimmermann, Daniel Vetter
On Mon, Jan 31, 2022 at 10:05:40PM +0100, Daniel Vetter wrote:
> It's only one flag and slightly tidier code.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Du Cheng <ducheng2@gmail.com>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Claudio Suarez <cssk@net-c.es>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Next step is to convert some of the int flags to bool - so it is obvious
this is bool and not an int.
I do not like bitfields for bools when there is no big win in memory
usage - so not fan of that suggestion.
Sam
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 09/21] fbcon: Replace FBCON_FLAGS_INIT with a boolean
@ 2022-02-03 21:30 ` Sam Ravnborg
0 siblings, 0 replies; 241+ messages in thread
From: Sam Ravnborg @ 2022-02-03 21:30 UTC (permalink / raw)
To: Daniel Vetter
Cc: DRI Development, linux-fbdev, Thomas Zimmermann, Du Cheng,
Tetsuo Handa, Intel Graphics Development, LKML, Claudio Suarez,
Greg Kroah-Hartman, Daniel Vetter
On Mon, Jan 31, 2022 at 10:05:40PM +0100, Daniel Vetter wrote:
> It's only one flag and slightly tidier code.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Du Cheng <ducheng2@gmail.com>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Claudio Suarez <cssk@net-c.es>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Next step is to convert some of the int flags to bool - so it is obvious
this is bool and not an int.
I do not like bitfields for bools when there is no big win in memory
usage - so not fan of that suggestion.
Sam
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 10/21] fb: Delete fb_info->queue
2022-01-31 21:05 ` [Intel-gfx] " Daniel Vetter
(?)
@ 2022-02-03 21:31 ` Sam Ravnborg
-1 siblings, 0 replies; 241+ messages in thread
From: Sam Ravnborg @ 2022-02-03 21:31 UTC (permalink / raw)
To: Daniel Vetter
Cc: linux-fbdev, Helge Deller, LKML, DRI Development, Daniel Vetter,
Intel Graphics Development
On Mon, Jan 31, 2022 at 10:05:41PM +0100, Daniel Vetter wrote:
> It was only used by fbcon, and that now switched to its own,
> private work.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Helge Deller <deller@gmx.de>
> Cc: linux-fbdev@vger.kernel.org
I would merge this with the patch that drops the usage
> ---
> include/linux/fb.h | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/include/linux/fb.h b/include/linux/fb.h
> index 02f362c661c8..a8a00d2ba1f3 100644
> --- a/include/linux/fb.h
> +++ b/include/linux/fb.h
> @@ -449,7 +449,6 @@ struct fb_info {
> struct fb_var_screeninfo var; /* Current var */
> struct fb_fix_screeninfo fix; /* Current fix */
> struct fb_monspecs monspecs; /* Current Monitor specs */
> - struct work_struct queue; /* Framebuffer event queue */
> struct fb_pixmap pixmap; /* Image hardware mapper */
> struct fb_pixmap sprite; /* Cursor hardware mapper */
> struct fb_cmap cmap; /* Current cmap */
> --
> 2.33.0
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [Intel-gfx] [PATCH 10/21] fb: Delete fb_info->queue
@ 2022-02-03 21:31 ` Sam Ravnborg
0 siblings, 0 replies; 241+ messages in thread
From: Sam Ravnborg @ 2022-02-03 21:31 UTC (permalink / raw)
To: Daniel Vetter
Cc: linux-fbdev, Helge Deller, LKML, DRI Development, Daniel Vetter,
Intel Graphics Development
On Mon, Jan 31, 2022 at 10:05:41PM +0100, Daniel Vetter wrote:
> It was only used by fbcon, and that now switched to its own,
> private work.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Helge Deller <deller@gmx.de>
> Cc: linux-fbdev@vger.kernel.org
I would merge this with the patch that drops the usage
> ---
> include/linux/fb.h | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/include/linux/fb.h b/include/linux/fb.h
> index 02f362c661c8..a8a00d2ba1f3 100644
> --- a/include/linux/fb.h
> +++ b/include/linux/fb.h
> @@ -449,7 +449,6 @@ struct fb_info {
> struct fb_var_screeninfo var; /* Current var */
> struct fb_fix_screeninfo fix; /* Current fix */
> struct fb_monspecs monspecs; /* Current Monitor specs */
> - struct work_struct queue; /* Framebuffer event queue */
> struct fb_pixmap pixmap; /* Image hardware mapper */
> struct fb_pixmap sprite; /* Cursor hardware mapper */
> struct fb_cmap cmap; /* Current cmap */
> --
> 2.33.0
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 10/21] fb: Delete fb_info->queue
@ 2022-02-03 21:31 ` Sam Ravnborg
0 siblings, 0 replies; 241+ messages in thread
From: Sam Ravnborg @ 2022-02-03 21:31 UTC (permalink / raw)
To: Daniel Vetter
Cc: DRI Development, linux-fbdev, Intel Graphics Development, LKML,
Daniel Vetter, Helge Deller
On Mon, Jan 31, 2022 at 10:05:41PM +0100, Daniel Vetter wrote:
> It was only used by fbcon, and that now switched to its own,
> private work.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Helge Deller <deller@gmx.de>
> Cc: linux-fbdev@vger.kernel.org
I would merge this with the patch that drops the usage
> ---
> include/linux/fb.h | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/include/linux/fb.h b/include/linux/fb.h
> index 02f362c661c8..a8a00d2ba1f3 100644
> --- a/include/linux/fb.h
> +++ b/include/linux/fb.h
> @@ -449,7 +449,6 @@ struct fb_info {
> struct fb_var_screeninfo var; /* Current var */
> struct fb_fix_screeninfo fix; /* Current fix */
> struct fb_monspecs monspecs; /* Current Monitor specs */
> - struct work_struct queue; /* Framebuffer event queue */
> struct fb_pixmap pixmap; /* Image hardware mapper */
> struct fb_pixmap sprite; /* Cursor hardware mapper */
> struct fb_cmap cmap; /* Current cmap */
> --
> 2.33.0
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [Intel-gfx] [PATCH 11/21] fbcon: Extract fbcon_open/release helpers
2022-02-03 21:15 ` [Intel-gfx] " Sam Ravnborg
@ 2022-02-03 21:32 ` Sam Ravnborg
-1 siblings, 0 replies; 241+ messages in thread
From: Sam Ravnborg @ 2022-02-03 21:32 UTC (permalink / raw)
To: Daniel Vetter
Cc: linux-fbdev, Du Cheng, Tetsuo Handa, Greg Kroah-Hartman,
Intel Graphics Development, LKML, DRI Development, Daniel Vetter
Hi Daniel,
>
> > + kfree(ops->cursor_state.mask);
> > + kfree(ops->cursor_data);
> > + kfree(ops->cursor_src);
> > + kfree(ops->fontbuffer);
> > + kfree(oldinfo->fbcon_par);
> > + oldinfo->fbcon_par = NULL;
> These all look like candidates to stuff into fbcon_release()
> That would drop the nice symmetry but make it more consistent.
>
> I think we miss freeing ops->cursor_data in fbcon_exit(),
> but I did not follow all the code.
We agree as I can see this was done in a later patch.
Sam
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 11/21] fbcon: Extract fbcon_open/release helpers
@ 2022-02-03 21:32 ` Sam Ravnborg
0 siblings, 0 replies; 241+ messages in thread
From: Sam Ravnborg @ 2022-02-03 21:32 UTC (permalink / raw)
To: Daniel Vetter
Cc: linux-fbdev, Du Cheng, Tetsuo Handa, Greg Kroah-Hartman,
Intel Graphics Development, LKML, DRI Development,
Claudio Suarez, Daniel Vetter
Hi Daniel,
>
> > + kfree(ops->cursor_state.mask);
> > + kfree(ops->cursor_data);
> > + kfree(ops->cursor_src);
> > + kfree(ops->fontbuffer);
> > + kfree(oldinfo->fbcon_par);
> > + oldinfo->fbcon_par = NULL;
> These all look like candidates to stuff into fbcon_release()
> That would drop the nice symmetry but make it more consistent.
>
> I think we miss freeing ops->cursor_data in fbcon_exit(),
> but I did not follow all the code.
We agree as I can see this was done in a later patch.
Sam
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 21/21] fbdev: Make registered_fb[] private to fbmem.c
2022-01-31 21:05 ` Daniel Vetter
(?)
@ 2022-02-04 8:30 ` Geert Uytterhoeven
-1 siblings, 0 replies; 241+ messages in thread
From: Geert Uytterhoeven @ 2022-02-04 8:30 UTC (permalink / raw)
To: Daniel Vetter
Cc: DRI Development, Intel Graphics Development,
Linux Fbdev development list, LKML, Jens Frederich,
Jon Nettleton, Greg Kroah-Hartman, linux-staging, Daniel Vetter,
Daniel Vetter, Helge Deller, Matthew Wilcox, Sam Ravnborg,
Tetsuo Handa, Zhen Lei, Alex Deucher, Xiyu Yang, Zheyu Ma,
Guenter Roeck
Hi Daniel,
Thanks for your patch!
On Tue, Feb 1, 2022 at 9:50 PM Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> Well except when the olpc dcon fbdev driver is enabled, that thing
> digs around in there in rather unfixable ways.
Can't the actual frame buffer driver (which one?) used on olpc export
a pointer to its fb_info?
> --- a/drivers/video/fbdev/core/fbmem.c
> +++ b/drivers/video/fbdev/core/fbmem.c
> @@ -48,10 +48,14 @@
> static DEFINE_MUTEX(registration_lock);
>
> struct fb_info *registered_fb[FB_MAX] __read_mostly;
> -EXPORT_SYMBOL(registered_fb);
> -
> int num_registered_fb __read_mostly;
> +#if IS_ENABLED(CONFIG_OLPC_DCON)
CONFIG_FB_OLPC_DCON (everywhere), cfr. the build failure reported
by the robot.
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
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 21/21] fbdev: Make registered_fb[] private to fbmem.c
@ 2022-02-04 8:30 ` Geert Uytterhoeven
0 siblings, 0 replies; 241+ messages in thread
From: Geert Uytterhoeven @ 2022-02-04 8:30 UTC (permalink / raw)
To: Daniel Vetter
Cc: Linux Fbdev development list, Zheyu Ma, Xiyu Yang,
Jens Frederich, Tetsuo Handa, Greg Kroah-Hartman, Jon Nettleton,
linux-staging, LKML, DRI Development, Zhen Lei, Matthew Wilcox,
Helge Deller, Alex Deucher, Daniel Vetter, Sam Ravnborg,
Intel Graphics Development, Guenter Roeck
Hi Daniel,
Thanks for your patch!
On Tue, Feb 1, 2022 at 9:50 PM Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> Well except when the olpc dcon fbdev driver is enabled, that thing
> digs around in there in rather unfixable ways.
Can't the actual frame buffer driver (which one?) used on olpc export
a pointer to its fb_info?
> --- a/drivers/video/fbdev/core/fbmem.c
> +++ b/drivers/video/fbdev/core/fbmem.c
> @@ -48,10 +48,14 @@
> static DEFINE_MUTEX(registration_lock);
>
> struct fb_info *registered_fb[FB_MAX] __read_mostly;
> -EXPORT_SYMBOL(registered_fb);
> -
> int num_registered_fb __read_mostly;
> +#if IS_ENABLED(CONFIG_OLPC_DCON)
CONFIG_FB_OLPC_DCON (everywhere), cfr. the build failure reported
by the robot.
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
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [Intel-gfx] [PATCH 21/21] fbdev: Make registered_fb[] private to fbmem.c
@ 2022-02-04 8:30 ` Geert Uytterhoeven
0 siblings, 0 replies; 241+ messages in thread
From: Geert Uytterhoeven @ 2022-02-04 8:30 UTC (permalink / raw)
To: Daniel Vetter
Cc: Linux Fbdev development list, Zheyu Ma, Xiyu Yang,
Jens Frederich, Tetsuo Handa, Greg Kroah-Hartman, Jon Nettleton,
linux-staging, LKML, DRI Development, Zhen Lei, Matthew Wilcox,
Helge Deller, Alex Deucher, Daniel Vetter, Sam Ravnborg,
Intel Graphics Development, Guenter Roeck
Hi Daniel,
Thanks for your patch!
On Tue, Feb 1, 2022 at 9:50 PM Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> Well except when the olpc dcon fbdev driver is enabled, that thing
> digs around in there in rather unfixable ways.
Can't the actual frame buffer driver (which one?) used on olpc export
a pointer to its fb_info?
> --- a/drivers/video/fbdev/core/fbmem.c
> +++ b/drivers/video/fbdev/core/fbmem.c
> @@ -48,10 +48,14 @@
> static DEFINE_MUTEX(registration_lock);
>
> struct fb_info *registered_fb[FB_MAX] __read_mostly;
> -EXPORT_SYMBOL(registered_fb);
> -
> int num_registered_fb __read_mostly;
> +#if IS_ENABLED(CONFIG_OLPC_DCON)
CONFIG_FB_OLPC_DCON (everywhere), cfr. the build failure reported
by the robot.
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
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 04/21] fbcon: delete a few unneeded forward decl
2022-01-31 21:05 ` Daniel Vetter
(?)
@ 2022-02-04 10:00 ` Geert Uytterhoeven
-1 siblings, 0 replies; 241+ messages in thread
From: Geert Uytterhoeven @ 2022-02-04 10:00 UTC (permalink / raw)
To: Daniel Vetter
Cc: DRI Development, Intel Graphics Development,
Linux Fbdev development list, LKML, Daniel Vetter, Helge Deller,
Daniel Vetter, Thomas Zimmermann, Du Cheng, Tetsuo Handa,
Claudio Suarez, Greg Kroah-Hartman
On Tue, Feb 1, 2022 at 9:50 PM Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> I didn't bother with any code movement to fix the others, these just
> got a bit in the way.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
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
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 04/21] fbcon: delete a few unneeded forward decl
@ 2022-02-04 10:00 ` Geert Uytterhoeven
0 siblings, 0 replies; 241+ messages in thread
From: Geert Uytterhoeven @ 2022-02-04 10:00 UTC (permalink / raw)
To: Daniel Vetter
Cc: Linux Fbdev development list, Thomas Zimmermann, Du Cheng,
Tetsuo Handa, Greg Kroah-Hartman, Intel Graphics Development,
LKML, DRI Development, Claudio Suarez, Daniel Vetter,
Helge Deller
On Tue, Feb 1, 2022 at 9:50 PM Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> I didn't bother with any code movement to fix the others, these just
> got a bit in the way.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
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
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [Intel-gfx] [PATCH 04/21] fbcon: delete a few unneeded forward decl
@ 2022-02-04 10:00 ` Geert Uytterhoeven
0 siblings, 0 replies; 241+ messages in thread
From: Geert Uytterhoeven @ 2022-02-04 10:00 UTC (permalink / raw)
To: Daniel Vetter
Cc: Linux Fbdev development list, Thomas Zimmermann, Du Cheng,
Tetsuo Handa, Greg Kroah-Hartman, Intel Graphics Development,
LKML, DRI Development, Daniel Vetter, Helge Deller
On Tue, Feb 1, 2022 at 9:50 PM Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> I didn't bother with any code movement to fix the others, these just
> got a bit in the way.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org>
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
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 13/21] fbcon: move more common code into fb_open()
2022-01-31 21:05 ` [Intel-gfx] " Daniel Vetter
(?)
@ 2022-02-04 19:35 ` Sam Ravnborg
-1 siblings, 0 replies; 241+ messages in thread
From: Sam Ravnborg @ 2022-02-04 19:35 UTC (permalink / raw)
To: Daniel Vetter
Cc: linux-fbdev, Du Cheng, Tetsuo Handa, Greg Kroah-Hartman,
Intel Graphics Development, LKML, DRI Development,
Claudio Suarez, Thomas Zimmermann, Daniel Vetter
On Mon, Jan 31, 2022 at 10:05:44PM +0100, Daniel Vetter wrote:
> No idea why con2fb_acquire_newinfo() initializes much less than
> fbcon_startup(), but so be it. From a quick look most of the
> un-initialized stuff should be fairly harmless, but who knows.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Claudio Suarez <cssk@net-c.es>
> Cc: Du Cheng <ducheng2@gmail.com>
> ---
> drivers/video/fbdev/core/fbcon.c | 74 +++++++++++++-------------------
> 1 file changed, 31 insertions(+), 43 deletions(-)
>
> diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
> index b83a5a77d8a8..5a3391ff038d 100644
> --- a/drivers/video/fbdev/core/fbcon.c
> +++ b/drivers/video/fbdev/core/fbcon.c
> @@ -680,8 +680,18 @@ static int fbcon_invalid_charcount(struct fb_info *info, unsigned charcount)
>
> #endif /* CONFIG_MISC_TILEBLITTING */
>
> +static void fbcon_release(struct fb_info *info)
> +{
> + if (info->fbops->fb_release)
> + info->fbops->fb_release(info, 0);
> +
> + module_put(info->fbops->owner);
> +}
> +
> static int fbcon_open(struct fb_info *info)
> {
> + struct fbcon_ops *ops;
> +
> if (!try_module_get(info->fbops->owner))
> return -ENODEV;
>
> @@ -691,19 +701,22 @@ static int fbcon_open(struct fb_info *info)
> return -ENODEV;
> }
>
> - return 0;
> -}
> + ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL);
> + if (!ops) {
> + fbcon_release(info);
> + return -ENOMEM;
> + }
>
> -static void fbcon_release(struct fb_info *info)
> -{
> - if (info->fbops->fb_release)
> - info->fbops->fb_release(info, 0);
> + INIT_DELAYED_WORK(&ops->cursor_work, fb_flashcursor);
> + ops->info = info;
> + info->fbcon_par = ops;
> + ops->cur_blink_jiffies = HZ / 5;
>
> - module_put(info->fbops->owner);
> + return 0;
> }
>
> static int con2fb_acquire_newinfo(struct vc_data *vc, struct fb_info *info,
> - int unit, int oldidx)
> + int unit)
> {
> struct fbcon_ops *ops = NULL;
> int err;
> @@ -712,27 +725,10 @@ static int con2fb_acquire_newinfo(struct vc_data *vc, struct fb_info *info,
> if (err)
> return err;
>
> - if (!err) {
> - ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL);
> - if (!ops)
> - err = -ENOMEM;
> -
> - INIT_DELAYED_WORK(&ops->cursor_work, fb_flashcursor);
> - }
> -
> - if (!err) {
> - ops->cur_blink_jiffies = HZ / 5;
> - ops->info = info;
> - info->fbcon_par = ops;
> -
> - if (vc)
> - set_blitting_type(vc, info);
> - }
> + ops = info->fbcon_par;
>
> - if (err) {
> - con2fb_map[unit] = oldidx;
> - fbcon_release(info);
> - }
> + if (vc)
> + set_blitting_type(vc, info);
>
> return err;
> }
> @@ -840,9 +836,11 @@ static int set_con2fb_map(int unit, int newidx, int user)
>
> found = search_fb_in_map(newidx);
>
> - con2fb_map[unit] = newidx;
> - if (!err && !found)
> - err = con2fb_acquire_newinfo(vc, info, unit, oldidx);
> + if (!err && !found) {
> + err = con2fb_acquire_newinfo(vc, info, unit);
> + if (!err)
> + con2fb_map[unit] = newidx;
> + }
This looks like an unintentional change of functionality as con2fb_map[unit] is
only assigned when we do a con2fb_acquire_newinfo().
Staring at the code I could not say it is wrong, but not nice to hide
the change in this patch.
Sam
>
> /*
> * If old fb is not mapped to any of the consoles,
> @@ -939,20 +937,10 @@ static const char *fbcon_startup(void)
> if (fbcon_open(info))
> return NULL;
>
> - ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL);
> - if (!ops) {
> - fbcon_release(info);
> - return NULL;
> - }
> -
> - INIT_DELAYED_WORK(&ops->cursor_work, fb_flashcursor);
> -
> + ops = info->fbcon_par;
> ops->currcon = -1;
> ops->graphics = 1;
> ops->cur_rotate = -1;
> - ops->cur_blink_jiffies = HZ / 5;
> - ops->info = info;
> - info->fbcon_par = ops;
>
> p->con_rotate = initial_rotation;
> if (p->con_rotate == -1)
> @@ -1022,7 +1010,7 @@ static void fbcon_init(struct vc_data *vc, int init)
> return;
>
> if (!info->fbcon_par)
> - con2fb_acquire_newinfo(vc, info, vc->vc_num, -1);
> + con2fb_acquire_newinfo(vc, info, vc->vc_num);
>
> /* If we are not the first console on this
> fb, copy the font from that console */
> --
> 2.33.0
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [Intel-gfx] [PATCH 13/21] fbcon: move more common code into fb_open()
@ 2022-02-04 19:35 ` Sam Ravnborg
0 siblings, 0 replies; 241+ messages in thread
From: Sam Ravnborg @ 2022-02-04 19:35 UTC (permalink / raw)
To: Daniel Vetter
Cc: linux-fbdev, Du Cheng, Tetsuo Handa, Greg Kroah-Hartman,
Intel Graphics Development, LKML, DRI Development,
Thomas Zimmermann, Daniel Vetter
On Mon, Jan 31, 2022 at 10:05:44PM +0100, Daniel Vetter wrote:
> No idea why con2fb_acquire_newinfo() initializes much less than
> fbcon_startup(), but so be it. From a quick look most of the
> un-initialized stuff should be fairly harmless, but who knows.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Claudio Suarez <cssk@net-c.es>
> Cc: Du Cheng <ducheng2@gmail.com>
> ---
> drivers/video/fbdev/core/fbcon.c | 74 +++++++++++++-------------------
> 1 file changed, 31 insertions(+), 43 deletions(-)
>
> diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
> index b83a5a77d8a8..5a3391ff038d 100644
> --- a/drivers/video/fbdev/core/fbcon.c
> +++ b/drivers/video/fbdev/core/fbcon.c
> @@ -680,8 +680,18 @@ static int fbcon_invalid_charcount(struct fb_info *info, unsigned charcount)
>
> #endif /* CONFIG_MISC_TILEBLITTING */
>
> +static void fbcon_release(struct fb_info *info)
> +{
> + if (info->fbops->fb_release)
> + info->fbops->fb_release(info, 0);
> +
> + module_put(info->fbops->owner);
> +}
> +
> static int fbcon_open(struct fb_info *info)
> {
> + struct fbcon_ops *ops;
> +
> if (!try_module_get(info->fbops->owner))
> return -ENODEV;
>
> @@ -691,19 +701,22 @@ static int fbcon_open(struct fb_info *info)
> return -ENODEV;
> }
>
> - return 0;
> -}
> + ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL);
> + if (!ops) {
> + fbcon_release(info);
> + return -ENOMEM;
> + }
>
> -static void fbcon_release(struct fb_info *info)
> -{
> - if (info->fbops->fb_release)
> - info->fbops->fb_release(info, 0);
> + INIT_DELAYED_WORK(&ops->cursor_work, fb_flashcursor);
> + ops->info = info;
> + info->fbcon_par = ops;
> + ops->cur_blink_jiffies = HZ / 5;
>
> - module_put(info->fbops->owner);
> + return 0;
> }
>
> static int con2fb_acquire_newinfo(struct vc_data *vc, struct fb_info *info,
> - int unit, int oldidx)
> + int unit)
> {
> struct fbcon_ops *ops = NULL;
> int err;
> @@ -712,27 +725,10 @@ static int con2fb_acquire_newinfo(struct vc_data *vc, struct fb_info *info,
> if (err)
> return err;
>
> - if (!err) {
> - ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL);
> - if (!ops)
> - err = -ENOMEM;
> -
> - INIT_DELAYED_WORK(&ops->cursor_work, fb_flashcursor);
> - }
> -
> - if (!err) {
> - ops->cur_blink_jiffies = HZ / 5;
> - ops->info = info;
> - info->fbcon_par = ops;
> -
> - if (vc)
> - set_blitting_type(vc, info);
> - }
> + ops = info->fbcon_par;
>
> - if (err) {
> - con2fb_map[unit] = oldidx;
> - fbcon_release(info);
> - }
> + if (vc)
> + set_blitting_type(vc, info);
>
> return err;
> }
> @@ -840,9 +836,11 @@ static int set_con2fb_map(int unit, int newidx, int user)
>
> found = search_fb_in_map(newidx);
>
> - con2fb_map[unit] = newidx;
> - if (!err && !found)
> - err = con2fb_acquire_newinfo(vc, info, unit, oldidx);
> + if (!err && !found) {
> + err = con2fb_acquire_newinfo(vc, info, unit);
> + if (!err)
> + con2fb_map[unit] = newidx;
> + }
This looks like an unintentional change of functionality as con2fb_map[unit] is
only assigned when we do a con2fb_acquire_newinfo().
Staring at the code I could not say it is wrong, but not nice to hide
the change in this patch.
Sam
>
> /*
> * If old fb is not mapped to any of the consoles,
> @@ -939,20 +937,10 @@ static const char *fbcon_startup(void)
> if (fbcon_open(info))
> return NULL;
>
> - ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL);
> - if (!ops) {
> - fbcon_release(info);
> - return NULL;
> - }
> -
> - INIT_DELAYED_WORK(&ops->cursor_work, fb_flashcursor);
> -
> + ops = info->fbcon_par;
> ops->currcon = -1;
> ops->graphics = 1;
> ops->cur_rotate = -1;
> - ops->cur_blink_jiffies = HZ / 5;
> - ops->info = info;
> - info->fbcon_par = ops;
>
> p->con_rotate = initial_rotation;
> if (p->con_rotate == -1)
> @@ -1022,7 +1010,7 @@ static void fbcon_init(struct vc_data *vc, int init)
> return;
>
> if (!info->fbcon_par)
> - con2fb_acquire_newinfo(vc, info, vc->vc_num, -1);
> + con2fb_acquire_newinfo(vc, info, vc->vc_num);
>
> /* If we are not the first console on this
> fb, copy the font from that console */
> --
> 2.33.0
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 13/21] fbcon: move more common code into fb_open()
@ 2022-02-04 19:35 ` Sam Ravnborg
0 siblings, 0 replies; 241+ messages in thread
From: Sam Ravnborg @ 2022-02-04 19:35 UTC (permalink / raw)
To: Daniel Vetter
Cc: DRI Development, linux-fbdev, Thomas Zimmermann, Du Cheng,
Tetsuo Handa, Intel Graphics Development, LKML, Claudio Suarez,
Greg Kroah-Hartman, Daniel Vetter
On Mon, Jan 31, 2022 at 10:05:44PM +0100, Daniel Vetter wrote:
> No idea why con2fb_acquire_newinfo() initializes much less than
> fbcon_startup(), but so be it. From a quick look most of the
> un-initialized stuff should be fairly harmless, but who knows.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Claudio Suarez <cssk@net-c.es>
> Cc: Du Cheng <ducheng2@gmail.com>
> ---
> drivers/video/fbdev/core/fbcon.c | 74 +++++++++++++-------------------
> 1 file changed, 31 insertions(+), 43 deletions(-)
>
> diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
> index b83a5a77d8a8..5a3391ff038d 100644
> --- a/drivers/video/fbdev/core/fbcon.c
> +++ b/drivers/video/fbdev/core/fbcon.c
> @@ -680,8 +680,18 @@ static int fbcon_invalid_charcount(struct fb_info *info, unsigned charcount)
>
> #endif /* CONFIG_MISC_TILEBLITTING */
>
> +static void fbcon_release(struct fb_info *info)
> +{
> + if (info->fbops->fb_release)
> + info->fbops->fb_release(info, 0);
> +
> + module_put(info->fbops->owner);
> +}
> +
> static int fbcon_open(struct fb_info *info)
> {
> + struct fbcon_ops *ops;
> +
> if (!try_module_get(info->fbops->owner))
> return -ENODEV;
>
> @@ -691,19 +701,22 @@ static int fbcon_open(struct fb_info *info)
> return -ENODEV;
> }
>
> - return 0;
> -}
> + ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL);
> + if (!ops) {
> + fbcon_release(info);
> + return -ENOMEM;
> + }
>
> -static void fbcon_release(struct fb_info *info)
> -{
> - if (info->fbops->fb_release)
> - info->fbops->fb_release(info, 0);
> + INIT_DELAYED_WORK(&ops->cursor_work, fb_flashcursor);
> + ops->info = info;
> + info->fbcon_par = ops;
> + ops->cur_blink_jiffies = HZ / 5;
>
> - module_put(info->fbops->owner);
> + return 0;
> }
>
> static int con2fb_acquire_newinfo(struct vc_data *vc, struct fb_info *info,
> - int unit, int oldidx)
> + int unit)
> {
> struct fbcon_ops *ops = NULL;
> int err;
> @@ -712,27 +725,10 @@ static int con2fb_acquire_newinfo(struct vc_data *vc, struct fb_info *info,
> if (err)
> return err;
>
> - if (!err) {
> - ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL);
> - if (!ops)
> - err = -ENOMEM;
> -
> - INIT_DELAYED_WORK(&ops->cursor_work, fb_flashcursor);
> - }
> -
> - if (!err) {
> - ops->cur_blink_jiffies = HZ / 5;
> - ops->info = info;
> - info->fbcon_par = ops;
> -
> - if (vc)
> - set_blitting_type(vc, info);
> - }
> + ops = info->fbcon_par;
>
> - if (err) {
> - con2fb_map[unit] = oldidx;
> - fbcon_release(info);
> - }
> + if (vc)
> + set_blitting_type(vc, info);
>
> return err;
> }
> @@ -840,9 +836,11 @@ static int set_con2fb_map(int unit, int newidx, int user)
>
> found = search_fb_in_map(newidx);
>
> - con2fb_map[unit] = newidx;
> - if (!err && !found)
> - err = con2fb_acquire_newinfo(vc, info, unit, oldidx);
> + if (!err && !found) {
> + err = con2fb_acquire_newinfo(vc, info, unit);
> + if (!err)
> + con2fb_map[unit] = newidx;
> + }
This looks like an unintentional change of functionality as con2fb_map[unit] is
only assigned when we do a con2fb_acquire_newinfo().
Staring at the code I could not say it is wrong, but not nice to hide
the change in this patch.
Sam
>
> /*
> * If old fb is not mapped to any of the consoles,
> @@ -939,20 +937,10 @@ static const char *fbcon_startup(void)
> if (fbcon_open(info))
> return NULL;
>
> - ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL);
> - if (!ops) {
> - fbcon_release(info);
> - return NULL;
> - }
> -
> - INIT_DELAYED_WORK(&ops->cursor_work, fb_flashcursor);
> -
> + ops = info->fbcon_par;
> ops->currcon = -1;
> ops->graphics = 1;
> ops->cur_rotate = -1;
> - ops->cur_blink_jiffies = HZ / 5;
> - ops->info = info;
> - info->fbcon_par = ops;
>
> p->con_rotate = initial_rotation;
> if (p->con_rotate == -1)
> @@ -1022,7 +1010,7 @@ static void fbcon_init(struct vc_data *vc, int init)
> return;
>
> if (!info->fbcon_par)
> - con2fb_acquire_newinfo(vc, info, vc->vc_num, -1);
> + con2fb_acquire_newinfo(vc, info, vc->vc_num);
>
> /* If we are not the first console on this
> fb, copy the font from that console */
> --
> 2.33.0
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 14/21] fbcon: use lock_fb_info in fbcon_open/release
2022-01-31 21:05 ` Daniel Vetter
(?)
@ 2022-02-04 19:39 ` Sam Ravnborg
-1 siblings, 0 replies; 241+ messages in thread
From: Sam Ravnborg @ 2022-02-04 19:39 UTC (permalink / raw)
To: Daniel Vetter
Cc: linux-fbdev, Xiyu Yang, Du Cheng, Tetsuo Handa,
Greg Kroah-Hartman, Intel Graphics Development, Zheyu Ma, LKML,
DRI Development, William Kucharski, Claudio Suarez,
Matthew Wilcox, Thomas Zimmermann, Zhen Lei, Alex Deucher,
Daniel Vetter
On Mon, Jan 31, 2022 at 10:05:45PM +0100, Daniel Vetter wrote:
> Now we get to the real motiviation, because fbmem.c insists that
> that's the right lock for these.
>
> Ofc fbcon.c has a lot more places where it probably should call
> lock_fb_info(). But looking at fbmem.c at least most of these seem to
> be protected by console_lock() too, which is probably what papers over
> any issues.
>
> Note that this means we're shuffling around a bit the locking sections
> for some of the console takeover and unbind paths, but not all:
> - console binding/unbinding from the console layer never with
> lock_fb_info
> - unbind (as opposed to unlink) never bother with lock_fb_info
>
> Also the real serialization against set_par and set_pan are still
> doing by wrapping the entire ioctl code in console_lock(). So this
> shuffling shouldn't be worse than what we had from a "can you trigger
> races?" pov, but it's at least clearer.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Cc: Claudio Suarez <cssk@net-c.es>
> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Du Cheng <ducheng2@gmail.com>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Cc: Matthew Wilcox <willy@infradead.org>
> Cc: William Kucharski <william.kucharski@oracle.com>
> Cc: Alex Deucher <alexander.deucher@amd.com>
> Cc: Zheyu Ma <zheyuma97@gmail.com>
> Cc: Zhen Lei <thunder.leizhen@huawei.com>
> Cc: Xiyu Yang <xiyuyang19@fudan.edu.cn>
Well, the patch does what the commit log says.
Acked-by: Sam Ravnborg <sam@ravnborg.org>
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [Intel-gfx] [PATCH 14/21] fbcon: use lock_fb_info in fbcon_open/release
@ 2022-02-04 19:39 ` Sam Ravnborg
0 siblings, 0 replies; 241+ messages in thread
From: Sam Ravnborg @ 2022-02-04 19:39 UTC (permalink / raw)
To: Daniel Vetter
Cc: linux-fbdev, Xiyu Yang, Du Cheng, Tetsuo Handa,
Greg Kroah-Hartman, Intel Graphics Development, Zheyu Ma, LKML,
DRI Development, William Kucharski, Matthew Wilcox,
Thomas Zimmermann, Zhen Lei, Alex Deucher, Daniel Vetter
On Mon, Jan 31, 2022 at 10:05:45PM +0100, Daniel Vetter wrote:
> Now we get to the real motiviation, because fbmem.c insists that
> that's the right lock for these.
>
> Ofc fbcon.c has a lot more places where it probably should call
> lock_fb_info(). But looking at fbmem.c at least most of these seem to
> be protected by console_lock() too, which is probably what papers over
> any issues.
>
> Note that this means we're shuffling around a bit the locking sections
> for some of the console takeover and unbind paths, but not all:
> - console binding/unbinding from the console layer never with
> lock_fb_info
> - unbind (as opposed to unlink) never bother with lock_fb_info
>
> Also the real serialization against set_par and set_pan are still
> doing by wrapping the entire ioctl code in console_lock(). So this
> shuffling shouldn't be worse than what we had from a "can you trigger
> races?" pov, but it's at least clearer.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Cc: Claudio Suarez <cssk@net-c.es>
> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Du Cheng <ducheng2@gmail.com>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Cc: Matthew Wilcox <willy@infradead.org>
> Cc: William Kucharski <william.kucharski@oracle.com>
> Cc: Alex Deucher <alexander.deucher@amd.com>
> Cc: Zheyu Ma <zheyuma97@gmail.com>
> Cc: Zhen Lei <thunder.leizhen@huawei.com>
> Cc: Xiyu Yang <xiyuyang19@fudan.edu.cn>
Well, the patch does what the commit log says.
Acked-by: Sam Ravnborg <sam@ravnborg.org>
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 14/21] fbcon: use lock_fb_info in fbcon_open/release
@ 2022-02-04 19:39 ` Sam Ravnborg
0 siblings, 0 replies; 241+ messages in thread
From: Sam Ravnborg @ 2022-02-04 19:39 UTC (permalink / raw)
To: Daniel Vetter
Cc: DRI Development, linux-fbdev, Thomas Zimmermann, Xiyu Yang,
Du Cheng, Tetsuo Handa, Intel Graphics Development, Zheyu Ma,
LKML, Matthew Wilcox, William Kucharski, Claudio Suarez,
Greg Kroah-Hartman, Alex Deucher, Daniel Vetter, Zhen Lei
On Mon, Jan 31, 2022 at 10:05:45PM +0100, Daniel Vetter wrote:
> Now we get to the real motiviation, because fbmem.c insists that
> that's the right lock for these.
>
> Ofc fbcon.c has a lot more places where it probably should call
> lock_fb_info(). But looking at fbmem.c at least most of these seem to
> be protected by console_lock() too, which is probably what papers over
> any issues.
>
> Note that this means we're shuffling around a bit the locking sections
> for some of the console takeover and unbind paths, but not all:
> - console binding/unbinding from the console layer never with
> lock_fb_info
> - unbind (as opposed to unlink) never bother with lock_fb_info
>
> Also the real serialization against set_par and set_pan are still
> doing by wrapping the entire ioctl code in console_lock(). So this
> shuffling shouldn't be worse than what we had from a "can you trigger
> races?" pov, but it's at least clearer.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Cc: Claudio Suarez <cssk@net-c.es>
> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Du Cheng <ducheng2@gmail.com>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Cc: Matthew Wilcox <willy@infradead.org>
> Cc: William Kucharski <william.kucharski@oracle.com>
> Cc: Alex Deucher <alexander.deucher@amd.com>
> Cc: Zheyu Ma <zheyuma97@gmail.com>
> Cc: Zhen Lei <thunder.leizhen@huawei.com>
> Cc: Xiyu Yang <xiyuyang19@fudan.edu.cn>
Well, the patch does what the commit log says.
Acked-by: Sam Ravnborg <sam@ravnborg.org>
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 15/21] fbcon: Consistently protect deferred_takeover with console_lock()
2022-01-31 21:05 ` [Intel-gfx] " Daniel Vetter
(?)
@ 2022-02-04 19:45 ` Sam Ravnborg
-1 siblings, 0 replies; 241+ messages in thread
From: Sam Ravnborg @ 2022-02-04 19:45 UTC (permalink / raw)
To: Daniel Vetter
Cc: linux-fbdev, Du Cheng, Tetsuo Handa, Intel Graphics Development,
LKML, DRI Development, Claudio Suarez, Thomas Zimmermann,
Daniel Vetter
On Mon, Jan 31, 2022 at 10:05:46PM +0100, Daniel Vetter wrote:
> This shouldn't be a problem in practice since until we've actually
> taken over the console there's nothing we've registered with the
> console/vt subsystem, so the exit/unbind path that check this can't
> do the wrong thing. But it's confusing, so fix it by moving it a tad
> later.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Cc: Du Cheng <ducheng2@gmail.com>
> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> Cc: Claudio Suarez <cssk@net-c.es>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
It had helped me if the commitlog was explicit that the
deferred_takeover falg is moved to the worker function to reset it as
late as possible.
With the commit log updated:
Acked-by: Sam Ravnborg <sam@ravnborg.org>
> ---
> drivers/video/fbdev/core/fbcon.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
> index 496bc5f2133e..11b9f962af6f 100644
> --- a/drivers/video/fbdev/core/fbcon.c
> +++ b/drivers/video/fbdev/core/fbcon.c
> @@ -3247,6 +3247,9 @@ static void fbcon_register_existing_fbs(struct work_struct *work)
>
> console_lock();
>
> + deferred_takeover = false;
> + logo_shown = FBCON_LOGO_DONTSHOW;
> +
> for_each_registered_fb(i)
> fbcon_fb_registered(registered_fb[i]);
>
> @@ -3264,8 +3267,6 @@ static int fbcon_output_notifier(struct notifier_block *nb,
> pr_info("fbcon: Taking over console\n");
>
> dummycon_unregister_output_notifier(&fbcon_output_nb);
> - deferred_takeover = false;
> - logo_shown = FBCON_LOGO_DONTSHOW;
>
> /* We may get called in atomic context */
> schedule_work(&fbcon_deferred_takeover_work);
> --
> 2.33.0
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [Intel-gfx] [PATCH 15/21] fbcon: Consistently protect deferred_takeover with console_lock()
@ 2022-02-04 19:45 ` Sam Ravnborg
0 siblings, 0 replies; 241+ messages in thread
From: Sam Ravnborg @ 2022-02-04 19:45 UTC (permalink / raw)
To: Daniel Vetter
Cc: linux-fbdev, Du Cheng, Tetsuo Handa, Intel Graphics Development,
LKML, DRI Development, Thomas Zimmermann, Daniel Vetter
On Mon, Jan 31, 2022 at 10:05:46PM +0100, Daniel Vetter wrote:
> This shouldn't be a problem in practice since until we've actually
> taken over the console there's nothing we've registered with the
> console/vt subsystem, so the exit/unbind path that check this can't
> do the wrong thing. But it's confusing, so fix it by moving it a tad
> later.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Cc: Du Cheng <ducheng2@gmail.com>
> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> Cc: Claudio Suarez <cssk@net-c.es>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
It had helped me if the commitlog was explicit that the
deferred_takeover falg is moved to the worker function to reset it as
late as possible.
With the commit log updated:
Acked-by: Sam Ravnborg <sam@ravnborg.org>
> ---
> drivers/video/fbdev/core/fbcon.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
> index 496bc5f2133e..11b9f962af6f 100644
> --- a/drivers/video/fbdev/core/fbcon.c
> +++ b/drivers/video/fbdev/core/fbcon.c
> @@ -3247,6 +3247,9 @@ static void fbcon_register_existing_fbs(struct work_struct *work)
>
> console_lock();
>
> + deferred_takeover = false;
> + logo_shown = FBCON_LOGO_DONTSHOW;
> +
> for_each_registered_fb(i)
> fbcon_fb_registered(registered_fb[i]);
>
> @@ -3264,8 +3267,6 @@ static int fbcon_output_notifier(struct notifier_block *nb,
> pr_info("fbcon: Taking over console\n");
>
> dummycon_unregister_output_notifier(&fbcon_output_nb);
> - deferred_takeover = false;
> - logo_shown = FBCON_LOGO_DONTSHOW;
>
> /* We may get called in atomic context */
> schedule_work(&fbcon_deferred_takeover_work);
> --
> 2.33.0
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 15/21] fbcon: Consistently protect deferred_takeover with console_lock()
@ 2022-02-04 19:45 ` Sam Ravnborg
0 siblings, 0 replies; 241+ messages in thread
From: Sam Ravnborg @ 2022-02-04 19:45 UTC (permalink / raw)
To: Daniel Vetter
Cc: DRI Development, linux-fbdev, Thomas Zimmermann, Du Cheng,
Tetsuo Handa, Intel Graphics Development, LKML, Claudio Suarez,
Daniel Vetter
On Mon, Jan 31, 2022 at 10:05:46PM +0100, Daniel Vetter wrote:
> This shouldn't be a problem in practice since until we've actually
> taken over the console there's nothing we've registered with the
> console/vt subsystem, so the exit/unbind path that check this can't
> do the wrong thing. But it's confusing, so fix it by moving it a tad
> later.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Cc: Du Cheng <ducheng2@gmail.com>
> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> Cc: Claudio Suarez <cssk@net-c.es>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
It had helped me if the commitlog was explicit that the
deferred_takeover falg is moved to the worker function to reset it as
late as possible.
With the commit log updated:
Acked-by: Sam Ravnborg <sam@ravnborg.org>
> ---
> drivers/video/fbdev/core/fbcon.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
> index 496bc5f2133e..11b9f962af6f 100644
> --- a/drivers/video/fbdev/core/fbcon.c
> +++ b/drivers/video/fbdev/core/fbcon.c
> @@ -3247,6 +3247,9 @@ static void fbcon_register_existing_fbs(struct work_struct *work)
>
> console_lock();
>
> + deferred_takeover = false;
> + logo_shown = FBCON_LOGO_DONTSHOW;
> +
> for_each_registered_fb(i)
> fbcon_fb_registered(registered_fb[i]);
>
> @@ -3264,8 +3267,6 @@ static int fbcon_output_notifier(struct notifier_block *nb,
> pr_info("fbcon: Taking over console\n");
>
> dummycon_unregister_output_notifier(&fbcon_output_nb);
> - deferred_takeover = false;
> - logo_shown = FBCON_LOGO_DONTSHOW;
>
> /* We may get called in atomic context */
> schedule_work(&fbcon_deferred_takeover_work);
> --
> 2.33.0
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 16/21] fbcon: Move console_lock for register/unlink/unregister
2022-01-31 21:05 ` [Intel-gfx] " Daniel Vetter
(?)
@ 2022-02-04 19:54 ` Sam Ravnborg
-1 siblings, 0 replies; 241+ messages in thread
From: Sam Ravnborg @ 2022-02-04 19:54 UTC (permalink / raw)
To: Daniel Vetter
Cc: linux-fbdev, Xiyu Yang, Du Cheng, Tetsuo Handa,
Greg Kroah-Hartman, Intel Graphics Development, Zheyu Ma, LKML,
DRI Development, Claudio Suarez, Matthew Wilcox,
Thomas Zimmermann, Zhen Lei, Alex Deucher, Daniel Vetter,
Guenter Roeck
Hi Daniel.
On Mon, Jan 31, 2022 at 10:05:47PM +0100, Daniel Vetter wrote:
> Ideally console_lock becomes an implementation detail of fbcon.c and
> doesn't show up anywhere in fbmem.c. We're still pretty far from that,
> but at least the register/unregister code is there now.
>
> With this the do_fb_ioctl() handler is the only code in fbmem.c still
> calling console_lock().
>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Du Cheng <ducheng2@gmail.com>
> Cc: Claudio Suarez <cssk@net-c.es>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> Cc: Matthew Wilcox <willy@infradead.org>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Cc: Zheyu Ma <zheyuma97@gmail.com>
> Cc: Guenter Roeck <linux@roeck-us.net>
> Cc: Alex Deucher <alexander.deucher@amd.com>
> Cc: Zhen Lei <thunder.leizhen@huawei.com>
> Cc: Xiyu Yang <xiyuyang19@fudan.edu.cn>
Like how lock_console is now almost local to fbcon.
Except the usage outside fbmem + fbcon taht is.
Acked-by: Sam Ravnborg <sam@ravnborg.org>
> ---
> drivers/video/fbdev/core/fbcon.c | 33 ++++++++++++++++++++++++++------
> drivers/video/fbdev/core/fbmem.c | 23 ++--------------------
> 2 files changed, 29 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
> index 11b9f962af6f..e5e8aaf6f60d 100644
> --- a/drivers/video/fbdev/core/fbcon.c
> +++ b/drivers/video/fbdev/core/fbcon.c
> @@ -2776,10 +2776,12 @@ void fbcon_fb_unbind(struct fb_info *info)
> int i, new_idx = -1;
> int idx = info->node;
>
> - WARN_CONSOLE_UNLOCKED();
> + console_lock();
>
> - if (!fbcon_has_console_bind)
> + if (!fbcon_has_console_bind) {
> + console_unlock();
> return;
> + }
>
> for (i = first_fb_vc; i <= last_fb_vc; i++) {
> if (con2fb_map[i] != idx &&
> @@ -2814,6 +2816,8 @@ void fbcon_fb_unbind(struct fb_info *info)
> }
> fbcon_unbind();
> }
> +
> + console_unlock();
> }
>
> /* called with console_lock held */
> @@ -2821,10 +2825,12 @@ void fbcon_fb_unregistered(struct fb_info *info)
> {
> int i, idx;
>
> - WARN_CONSOLE_UNLOCKED();
> + console_lock();
>
> - if (deferred_takeover)
> + if (deferred_takeover) {
> + console_unlock();
> return;
> + }
>
> idx = info->node;
> for (i = first_fb_vc; i <= last_fb_vc; i++) {
> @@ -2853,6 +2859,7 @@ void fbcon_fb_unregistered(struct fb_info *info)
>
> if (!num_registered_fb)
> do_unregister_con_driver(&fb_con);
> + console_unlock();
> }
>
> void fbcon_remap_all(struct fb_info *info)
> @@ -2910,19 +2917,27 @@ static inline void fbcon_select_primary(struct fb_info *info)
> }
> #endif /* CONFIG_FRAMEBUFFER_DETECT_PRIMARY */
>
> +static bool lockless_register_fb;
> +module_param_named_unsafe(lockless_register_fb, lockless_register_fb, bool, 0400);
> +MODULE_PARM_DESC(lockless_register_fb,
> + "Lockless framebuffer registration for debugging [default=off]");
> +
> /* called with console_lock held */
> int fbcon_fb_registered(struct fb_info *info)
> {
> int ret = 0, i, idx;
>
> - WARN_CONSOLE_UNLOCKED();
> + if (!lockless_register_fb)
> + console_lock();
> + else
> + atomic_inc(&ignore_console_lock_warning);
>
> idx = info->node;
> fbcon_select_primary(info);
>
> if (deferred_takeover) {
> pr_info("fbcon: Deferring console take-over\n");
> - return 0;
> + goto out;
> }
>
> if (info_idx == -1) {
> @@ -2942,6 +2957,12 @@ int fbcon_fb_registered(struct fb_info *info)
> }
> }
>
> +out:
> + if (!lockless_register_fb)
> + console_unlock();
> + else
> + atomic_dec(&ignore_console_lock_warning);
> +
> return ret;
> }
>
> diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
> index fd51d12f2702..904ef1250677 100644
> --- a/drivers/video/fbdev/core/fbmem.c
> +++ b/drivers/video/fbdev/core/fbmem.c
> @@ -1573,14 +1573,9 @@ static void do_remove_conflicting_framebuffers(struct apertures_struct *a,
> }
> }
>
> -static bool lockless_register_fb;
> -module_param_named_unsafe(lockless_register_fb, lockless_register_fb, bool, 0400);
> -MODULE_PARM_DESC(lockless_register_fb,
> - "Lockless framebuffer registration for debugging [default=off]");
> -
> static int do_register_framebuffer(struct fb_info *fb_info)
> {
> - int i, ret;
> + int i;
> struct fb_videomode mode;
>
> if (fb_check_foreignness(fb_info))
> @@ -1649,17 +1644,7 @@ static int do_register_framebuffer(struct fb_info *fb_info)
> }
> #endif
>
> - if (!lockless_register_fb)
> - console_lock();
> - else
> - atomic_inc(&ignore_console_lock_warning);
> - ret = fbcon_fb_registered(fb_info);
> -
> - if (!lockless_register_fb)
> - console_unlock();
> - else
> - atomic_dec(&ignore_console_lock_warning);
> - return ret;
> + return fbcon_fb_registered(fb_info);
> }
>
> static void unbind_console(struct fb_info *fb_info)
> @@ -1669,9 +1654,7 @@ static void unbind_console(struct fb_info *fb_info)
> if (WARN_ON(i < 0 || i >= FB_MAX || registered_fb[i] != fb_info))
> return;
>
> - console_lock();
> fbcon_fb_unbind(fb_info);
> - console_unlock();
> }
>
> static void unlink_framebuffer(struct fb_info *fb_info)
> @@ -1714,9 +1697,7 @@ static void do_unregister_framebuffer(struct fb_info *fb_info)
> fb_notifier_call_chain(FB_EVENT_FB_UNREGISTERED, &event);
> }
> #endif
> - console_lock();
> fbcon_fb_unregistered(fb_info);
> - console_unlock();
>
> /* this may free fb info */
> put_fb_info(fb_info);
> --
> 2.33.0
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [Intel-gfx] [PATCH 16/21] fbcon: Move console_lock for register/unlink/unregister
@ 2022-02-04 19:54 ` Sam Ravnborg
0 siblings, 0 replies; 241+ messages in thread
From: Sam Ravnborg @ 2022-02-04 19:54 UTC (permalink / raw)
To: Daniel Vetter
Cc: linux-fbdev, Xiyu Yang, Du Cheng, Tetsuo Handa,
Greg Kroah-Hartman, Intel Graphics Development, Zheyu Ma, LKML,
DRI Development, Matthew Wilcox, Thomas Zimmermann, Zhen Lei,
Alex Deucher, Daniel Vetter, Guenter Roeck
Hi Daniel.
On Mon, Jan 31, 2022 at 10:05:47PM +0100, Daniel Vetter wrote:
> Ideally console_lock becomes an implementation detail of fbcon.c and
> doesn't show up anywhere in fbmem.c. We're still pretty far from that,
> but at least the register/unregister code is there now.
>
> With this the do_fb_ioctl() handler is the only code in fbmem.c still
> calling console_lock().
>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Du Cheng <ducheng2@gmail.com>
> Cc: Claudio Suarez <cssk@net-c.es>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> Cc: Matthew Wilcox <willy@infradead.org>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Cc: Zheyu Ma <zheyuma97@gmail.com>
> Cc: Guenter Roeck <linux@roeck-us.net>
> Cc: Alex Deucher <alexander.deucher@amd.com>
> Cc: Zhen Lei <thunder.leizhen@huawei.com>
> Cc: Xiyu Yang <xiyuyang19@fudan.edu.cn>
Like how lock_console is now almost local to fbcon.
Except the usage outside fbmem + fbcon taht is.
Acked-by: Sam Ravnborg <sam@ravnborg.org>
> ---
> drivers/video/fbdev/core/fbcon.c | 33 ++++++++++++++++++++++++++------
> drivers/video/fbdev/core/fbmem.c | 23 ++--------------------
> 2 files changed, 29 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
> index 11b9f962af6f..e5e8aaf6f60d 100644
> --- a/drivers/video/fbdev/core/fbcon.c
> +++ b/drivers/video/fbdev/core/fbcon.c
> @@ -2776,10 +2776,12 @@ void fbcon_fb_unbind(struct fb_info *info)
> int i, new_idx = -1;
> int idx = info->node;
>
> - WARN_CONSOLE_UNLOCKED();
> + console_lock();
>
> - if (!fbcon_has_console_bind)
> + if (!fbcon_has_console_bind) {
> + console_unlock();
> return;
> + }
>
> for (i = first_fb_vc; i <= last_fb_vc; i++) {
> if (con2fb_map[i] != idx &&
> @@ -2814,6 +2816,8 @@ void fbcon_fb_unbind(struct fb_info *info)
> }
> fbcon_unbind();
> }
> +
> + console_unlock();
> }
>
> /* called with console_lock held */
> @@ -2821,10 +2825,12 @@ void fbcon_fb_unregistered(struct fb_info *info)
> {
> int i, idx;
>
> - WARN_CONSOLE_UNLOCKED();
> + console_lock();
>
> - if (deferred_takeover)
> + if (deferred_takeover) {
> + console_unlock();
> return;
> + }
>
> idx = info->node;
> for (i = first_fb_vc; i <= last_fb_vc; i++) {
> @@ -2853,6 +2859,7 @@ void fbcon_fb_unregistered(struct fb_info *info)
>
> if (!num_registered_fb)
> do_unregister_con_driver(&fb_con);
> + console_unlock();
> }
>
> void fbcon_remap_all(struct fb_info *info)
> @@ -2910,19 +2917,27 @@ static inline void fbcon_select_primary(struct fb_info *info)
> }
> #endif /* CONFIG_FRAMEBUFFER_DETECT_PRIMARY */
>
> +static bool lockless_register_fb;
> +module_param_named_unsafe(lockless_register_fb, lockless_register_fb, bool, 0400);
> +MODULE_PARM_DESC(lockless_register_fb,
> + "Lockless framebuffer registration for debugging [default=off]");
> +
> /* called with console_lock held */
> int fbcon_fb_registered(struct fb_info *info)
> {
> int ret = 0, i, idx;
>
> - WARN_CONSOLE_UNLOCKED();
> + if (!lockless_register_fb)
> + console_lock();
> + else
> + atomic_inc(&ignore_console_lock_warning);
>
> idx = info->node;
> fbcon_select_primary(info);
>
> if (deferred_takeover) {
> pr_info("fbcon: Deferring console take-over\n");
> - return 0;
> + goto out;
> }
>
> if (info_idx == -1) {
> @@ -2942,6 +2957,12 @@ int fbcon_fb_registered(struct fb_info *info)
> }
> }
>
> +out:
> + if (!lockless_register_fb)
> + console_unlock();
> + else
> + atomic_dec(&ignore_console_lock_warning);
> +
> return ret;
> }
>
> diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
> index fd51d12f2702..904ef1250677 100644
> --- a/drivers/video/fbdev/core/fbmem.c
> +++ b/drivers/video/fbdev/core/fbmem.c
> @@ -1573,14 +1573,9 @@ static void do_remove_conflicting_framebuffers(struct apertures_struct *a,
> }
> }
>
> -static bool lockless_register_fb;
> -module_param_named_unsafe(lockless_register_fb, lockless_register_fb, bool, 0400);
> -MODULE_PARM_DESC(lockless_register_fb,
> - "Lockless framebuffer registration for debugging [default=off]");
> -
> static int do_register_framebuffer(struct fb_info *fb_info)
> {
> - int i, ret;
> + int i;
> struct fb_videomode mode;
>
> if (fb_check_foreignness(fb_info))
> @@ -1649,17 +1644,7 @@ static int do_register_framebuffer(struct fb_info *fb_info)
> }
> #endif
>
> - if (!lockless_register_fb)
> - console_lock();
> - else
> - atomic_inc(&ignore_console_lock_warning);
> - ret = fbcon_fb_registered(fb_info);
> -
> - if (!lockless_register_fb)
> - console_unlock();
> - else
> - atomic_dec(&ignore_console_lock_warning);
> - return ret;
> + return fbcon_fb_registered(fb_info);
> }
>
> static void unbind_console(struct fb_info *fb_info)
> @@ -1669,9 +1654,7 @@ static void unbind_console(struct fb_info *fb_info)
> if (WARN_ON(i < 0 || i >= FB_MAX || registered_fb[i] != fb_info))
> return;
>
> - console_lock();
> fbcon_fb_unbind(fb_info);
> - console_unlock();
> }
>
> static void unlink_framebuffer(struct fb_info *fb_info)
> @@ -1714,9 +1697,7 @@ static void do_unregister_framebuffer(struct fb_info *fb_info)
> fb_notifier_call_chain(FB_EVENT_FB_UNREGISTERED, &event);
> }
> #endif
> - console_lock();
> fbcon_fb_unregistered(fb_info);
> - console_unlock();
>
> /* this may free fb info */
> put_fb_info(fb_info);
> --
> 2.33.0
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 16/21] fbcon: Move console_lock for register/unlink/unregister
@ 2022-02-04 19:54 ` Sam Ravnborg
0 siblings, 0 replies; 241+ messages in thread
From: Sam Ravnborg @ 2022-02-04 19:54 UTC (permalink / raw)
To: Daniel Vetter
Cc: DRI Development, linux-fbdev, Thomas Zimmermann, Xiyu Yang,
Du Cheng, Tetsuo Handa, Intel Graphics Development, Zheyu Ma,
LKML, Matthew Wilcox, Claudio Suarez, Greg Kroah-Hartman,
Alex Deucher, Daniel Vetter, Zhen Lei, Guenter Roeck
Hi Daniel.
On Mon, Jan 31, 2022 at 10:05:47PM +0100, Daniel Vetter wrote:
> Ideally console_lock becomes an implementation detail of fbcon.c and
> doesn't show up anywhere in fbmem.c. We're still pretty far from that,
> but at least the register/unregister code is there now.
>
> With this the do_fb_ioctl() handler is the only code in fbmem.c still
> calling console_lock().
>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Du Cheng <ducheng2@gmail.com>
> Cc: Claudio Suarez <cssk@net-c.es>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> Cc: Matthew Wilcox <willy@infradead.org>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Cc: Zheyu Ma <zheyuma97@gmail.com>
> Cc: Guenter Roeck <linux@roeck-us.net>
> Cc: Alex Deucher <alexander.deucher@amd.com>
> Cc: Zhen Lei <thunder.leizhen@huawei.com>
> Cc: Xiyu Yang <xiyuyang19@fudan.edu.cn>
Like how lock_console is now almost local to fbcon.
Except the usage outside fbmem + fbcon taht is.
Acked-by: Sam Ravnborg <sam@ravnborg.org>
> ---
> drivers/video/fbdev/core/fbcon.c | 33 ++++++++++++++++++++++++++------
> drivers/video/fbdev/core/fbmem.c | 23 ++--------------------
> 2 files changed, 29 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
> index 11b9f962af6f..e5e8aaf6f60d 100644
> --- a/drivers/video/fbdev/core/fbcon.c
> +++ b/drivers/video/fbdev/core/fbcon.c
> @@ -2776,10 +2776,12 @@ void fbcon_fb_unbind(struct fb_info *info)
> int i, new_idx = -1;
> int idx = info->node;
>
> - WARN_CONSOLE_UNLOCKED();
> + console_lock();
>
> - if (!fbcon_has_console_bind)
> + if (!fbcon_has_console_bind) {
> + console_unlock();
> return;
> + }
>
> for (i = first_fb_vc; i <= last_fb_vc; i++) {
> if (con2fb_map[i] != idx &&
> @@ -2814,6 +2816,8 @@ void fbcon_fb_unbind(struct fb_info *info)
> }
> fbcon_unbind();
> }
> +
> + console_unlock();
> }
>
> /* called with console_lock held */
> @@ -2821,10 +2825,12 @@ void fbcon_fb_unregistered(struct fb_info *info)
> {
> int i, idx;
>
> - WARN_CONSOLE_UNLOCKED();
> + console_lock();
>
> - if (deferred_takeover)
> + if (deferred_takeover) {
> + console_unlock();
> return;
> + }
>
> idx = info->node;
> for (i = first_fb_vc; i <= last_fb_vc; i++) {
> @@ -2853,6 +2859,7 @@ void fbcon_fb_unregistered(struct fb_info *info)
>
> if (!num_registered_fb)
> do_unregister_con_driver(&fb_con);
> + console_unlock();
> }
>
> void fbcon_remap_all(struct fb_info *info)
> @@ -2910,19 +2917,27 @@ static inline void fbcon_select_primary(struct fb_info *info)
> }
> #endif /* CONFIG_FRAMEBUFFER_DETECT_PRIMARY */
>
> +static bool lockless_register_fb;
> +module_param_named_unsafe(lockless_register_fb, lockless_register_fb, bool, 0400);
> +MODULE_PARM_DESC(lockless_register_fb,
> + "Lockless framebuffer registration for debugging [default=off]");
> +
> /* called with console_lock held */
> int fbcon_fb_registered(struct fb_info *info)
> {
> int ret = 0, i, idx;
>
> - WARN_CONSOLE_UNLOCKED();
> + if (!lockless_register_fb)
> + console_lock();
> + else
> + atomic_inc(&ignore_console_lock_warning);
>
> idx = info->node;
> fbcon_select_primary(info);
>
> if (deferred_takeover) {
> pr_info("fbcon: Deferring console take-over\n");
> - return 0;
> + goto out;
> }
>
> if (info_idx == -1) {
> @@ -2942,6 +2957,12 @@ int fbcon_fb_registered(struct fb_info *info)
> }
> }
>
> +out:
> + if (!lockless_register_fb)
> + console_unlock();
> + else
> + atomic_dec(&ignore_console_lock_warning);
> +
> return ret;
> }
>
> diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
> index fd51d12f2702..904ef1250677 100644
> --- a/drivers/video/fbdev/core/fbmem.c
> +++ b/drivers/video/fbdev/core/fbmem.c
> @@ -1573,14 +1573,9 @@ static void do_remove_conflicting_framebuffers(struct apertures_struct *a,
> }
> }
>
> -static bool lockless_register_fb;
> -module_param_named_unsafe(lockless_register_fb, lockless_register_fb, bool, 0400);
> -MODULE_PARM_DESC(lockless_register_fb,
> - "Lockless framebuffer registration for debugging [default=off]");
> -
> static int do_register_framebuffer(struct fb_info *fb_info)
> {
> - int i, ret;
> + int i;
> struct fb_videomode mode;
>
> if (fb_check_foreignness(fb_info))
> @@ -1649,17 +1644,7 @@ static int do_register_framebuffer(struct fb_info *fb_info)
> }
> #endif
>
> - if (!lockless_register_fb)
> - console_lock();
> - else
> - atomic_inc(&ignore_console_lock_warning);
> - ret = fbcon_fb_registered(fb_info);
> -
> - if (!lockless_register_fb)
> - console_unlock();
> - else
> - atomic_dec(&ignore_console_lock_warning);
> - return ret;
> + return fbcon_fb_registered(fb_info);
> }
>
> static void unbind_console(struct fb_info *fb_info)
> @@ -1669,9 +1654,7 @@ static void unbind_console(struct fb_info *fb_info)
> if (WARN_ON(i < 0 || i >= FB_MAX || registered_fb[i] != fb_info))
> return;
>
> - console_lock();
> fbcon_fb_unbind(fb_info);
> - console_unlock();
> }
>
> static void unlink_framebuffer(struct fb_info *fb_info)
> @@ -1714,9 +1697,7 @@ static void do_unregister_framebuffer(struct fb_info *fb_info)
> fb_notifier_call_chain(FB_EVENT_FB_UNREGISTERED, &event);
> }
> #endif
> - console_lock();
> fbcon_fb_unregistered(fb_info);
> - console_unlock();
>
> /* this may free fb info */
> put_fb_info(fb_info);
> --
> 2.33.0
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 17/21] fbcon: Move more code into fbcon_release
2022-01-31 21:05 ` [Intel-gfx] " Daniel Vetter
(?)
@ 2022-02-04 19:55 ` Sam Ravnborg
-1 siblings, 0 replies; 241+ messages in thread
From: Sam Ravnborg @ 2022-02-04 19:55 UTC (permalink / raw)
To: Daniel Vetter
Cc: linux-fbdev, Du Cheng, Tetsuo Handa, Greg Kroah-Hartman,
Intel Graphics Development, LKML, DRI Development,
Claudio Suarez, Daniel Vetter
On Mon, Jan 31, 2022 at 10:05:48PM +0100, Daniel Vetter wrote:
> con2fb_release_oldinfo() has a bunch more kfree() calls than
> fbcon_exit(), but since kfree() on NULL is harmless doing that in both
> places should be ok. This is also a bit more symmetric now again with
> fbcon_open also allocating the fbcon_ops structure.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Du Cheng <ducheng2@gmail.com>
> Cc: Claudio Suarez <cssk@net-c.es>
Thanks, like I wrote earlier this makes sense.
Acked-by: Sam Ravnborg <sam@ravnborg.org>
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [Intel-gfx] [PATCH 17/21] fbcon: Move more code into fbcon_release
@ 2022-02-04 19:55 ` Sam Ravnborg
0 siblings, 0 replies; 241+ messages in thread
From: Sam Ravnborg @ 2022-02-04 19:55 UTC (permalink / raw)
To: Daniel Vetter
Cc: linux-fbdev, Du Cheng, Tetsuo Handa, Greg Kroah-Hartman,
Intel Graphics Development, LKML, DRI Development, Daniel Vetter
On Mon, Jan 31, 2022 at 10:05:48PM +0100, Daniel Vetter wrote:
> con2fb_release_oldinfo() has a bunch more kfree() calls than
> fbcon_exit(), but since kfree() on NULL is harmless doing that in both
> places should be ok. This is also a bit more symmetric now again with
> fbcon_open also allocating the fbcon_ops structure.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Du Cheng <ducheng2@gmail.com>
> Cc: Claudio Suarez <cssk@net-c.es>
Thanks, like I wrote earlier this makes sense.
Acked-by: Sam Ravnborg <sam@ravnborg.org>
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 17/21] fbcon: Move more code into fbcon_release
@ 2022-02-04 19:55 ` Sam Ravnborg
0 siblings, 0 replies; 241+ messages in thread
From: Sam Ravnborg @ 2022-02-04 19:55 UTC (permalink / raw)
To: Daniel Vetter
Cc: DRI Development, linux-fbdev, Du Cheng, Tetsuo Handa,
Intel Graphics Development, LKML, Claudio Suarez,
Greg Kroah-Hartman, Daniel Vetter
On Mon, Jan 31, 2022 at 10:05:48PM +0100, Daniel Vetter wrote:
> con2fb_release_oldinfo() has a bunch more kfree() calls than
> fbcon_exit(), but since kfree() on NULL is harmless doing that in both
> places should be ok. This is also a bit more symmetric now again with
> fbcon_open also allocating the fbcon_ops structure.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Du Cheng <ducheng2@gmail.com>
> Cc: Claudio Suarez <cssk@net-c.es>
Thanks, like I wrote earlier this makes sense.
Acked-by: Sam Ravnborg <sam@ravnborg.org>
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 18/21] fbcon: untangle fbcon_exit
2022-01-31 21:05 ` [Intel-gfx] " Daniel Vetter
(?)
@ 2022-02-04 20:06 ` Sam Ravnborg
-1 siblings, 0 replies; 241+ messages in thread
From: Sam Ravnborg @ 2022-02-04 20:06 UTC (permalink / raw)
To: Daniel Vetter
Cc: linux-fbdev, Du Cheng, Tetsuo Handa, Greg Kroah-Hartman,
Intel Graphics Development, LKML, DRI Development,
Claudio Suarez, Daniel Vetter
Hi Daniel,
On Mon, Jan 31, 2022 at 10:05:49PM +0100, Daniel Vetter wrote:
> There's a bunch of confusions going on here:
> - The deferred fbcon setup notifier should only be cleaned up from
> fb_console_exit(), to be symmetric with fb_console_init()
> - We also need to make sure we don't race with the work, which means
> temporarily dropping the console lock (or we can deadlock)
> - That also means no point in clearing deferred_takeover, we are
> unloading everything anyway.
> - Finally rename fbcon_exit to fbcon_release_all and move it, since
> that's what's it doing when being called from consw->con_deinit
> through fbcon_deinit.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Claudio Suarez <cssk@net-c.es>
> Cc: Du Cheng <ducheng2@gmail.com>
> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> ---
> drivers/video/fbdev/core/fbcon.c | 63 ++++++++++++++++----------------
> 1 file changed, 32 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
> index 5c14e24d14a1..22581952b4fd 100644
> --- a/drivers/video/fbdev/core/fbcon.c
> +++ b/drivers/video/fbdev/core/fbcon.c
> @@ -185,7 +185,6 @@ static void fbcon_set_disp(struct fb_info *info, struct fb_var_screeninfo *var,
> int unit);
> static void fbcon_modechanged(struct fb_info *info);
> static void fbcon_set_all_vcs(struct fb_info *info);
> -static void fbcon_exit(void);
>
> static struct device *fbcon_device;
>
> @@ -1149,6 +1148,27 @@ static void fbcon_free_font(struct fbcon_display *p, bool freefont)
>
> static void set_vc_hi_font(struct vc_data *vc, bool set);
>
> +static void fbcon_release_all(void)
> +{
> + struct fb_info *info;
> + int i, j, mapped;
> +
> + for_each_registered_fb(i) {
> + mapped = 0;
> + info = registered_fb[i];
> +
> + for (j = first_fb_vc; j <= last_fb_vc; j++) {
> + if (con2fb_map[j] == i) {
> + mapped = 1;
> + con2fb_map[j] = -1;
> + }
> + }
> +
> + if (mapped)
> + fbcon_release(info);
> + }
> +}
> +
> static void fbcon_deinit(struct vc_data *vc)
> {
> struct fbcon_display *p = &fb_display[vc->vc_num];
> @@ -1188,7 +1208,7 @@ static void fbcon_deinit(struct vc_data *vc)
> set_vc_hi_font(vc, false);
>
> if (!con_is_bound(&fb_con))
> - fbcon_exit();
> + fbcon_release_all();
>
> if (vc->vc_num == logo_shown)
> logo_shown = FBCON_LOGO_CANSHOW;
> @@ -3316,34 +3336,6 @@ static void fbcon_start(void)
> #endif
> }
>
> -static void fbcon_exit(void)
> -{
> - struct fb_info *info;
> - int i, j, mapped;
> -
> -#ifdef CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER
> - if (deferred_takeover) {
> - dummycon_unregister_output_notifier(&fbcon_output_nb);
> - deferred_takeover = false;
> - }
> -#endif
> -
> - for_each_registered_fb(i) {
> - mapped = 0;
> - info = registered_fb[i];
> -
> - for (j = first_fb_vc; j <= last_fb_vc; j++) {
> - if (con2fb_map[j] == i) {
> - mapped = 1;
> - con2fb_map[j] = -1;
> - }
> - }
> -
> - if (mapped)
> - fbcon_release(info);
> - }
> -}
> -
> void __init fb_console_init(void)
> {
> int i;
> @@ -3383,10 +3375,19 @@ static void __exit fbcon_deinit_device(void)
>
> void __exit fb_console_exit(void)
> {
> +#ifdef CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER
> + console_lock();
> + if (deferred_takeover)
> + dummycon_unregister_output_notifier(&fbcon_output_nb);
> + console_unlock();
> +
> + cancel_work_sync(&fbcon_deferred_takeover_work);
> +#endif
> +
> console_lock();
> fbcon_deinit_device();
> device_destroy(fb_class, MKDEV(0, 0));
> - fbcon_exit();
> +
We loose the call to fbcon_release_all() here.
We have part of the old fbcon_exit() above, but miss the release parts.
Maybe I missed something obvious?
The rest looks fine.
Sam
> do_unregister_con_driver(&fb_con);
> console_unlock();
> }
> --
> 2.33.0
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [Intel-gfx] [PATCH 18/21] fbcon: untangle fbcon_exit
@ 2022-02-04 20:06 ` Sam Ravnborg
0 siblings, 0 replies; 241+ messages in thread
From: Sam Ravnborg @ 2022-02-04 20:06 UTC (permalink / raw)
To: Daniel Vetter
Cc: linux-fbdev, Du Cheng, Tetsuo Handa, Greg Kroah-Hartman,
Intel Graphics Development, LKML, DRI Development, Daniel Vetter
Hi Daniel,
On Mon, Jan 31, 2022 at 10:05:49PM +0100, Daniel Vetter wrote:
> There's a bunch of confusions going on here:
> - The deferred fbcon setup notifier should only be cleaned up from
> fb_console_exit(), to be symmetric with fb_console_init()
> - We also need to make sure we don't race with the work, which means
> temporarily dropping the console lock (or we can deadlock)
> - That also means no point in clearing deferred_takeover, we are
> unloading everything anyway.
> - Finally rename fbcon_exit to fbcon_release_all and move it, since
> that's what's it doing when being called from consw->con_deinit
> through fbcon_deinit.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Claudio Suarez <cssk@net-c.es>
> Cc: Du Cheng <ducheng2@gmail.com>
> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> ---
> drivers/video/fbdev/core/fbcon.c | 63 ++++++++++++++++----------------
> 1 file changed, 32 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
> index 5c14e24d14a1..22581952b4fd 100644
> --- a/drivers/video/fbdev/core/fbcon.c
> +++ b/drivers/video/fbdev/core/fbcon.c
> @@ -185,7 +185,6 @@ static void fbcon_set_disp(struct fb_info *info, struct fb_var_screeninfo *var,
> int unit);
> static void fbcon_modechanged(struct fb_info *info);
> static void fbcon_set_all_vcs(struct fb_info *info);
> -static void fbcon_exit(void);
>
> static struct device *fbcon_device;
>
> @@ -1149,6 +1148,27 @@ static void fbcon_free_font(struct fbcon_display *p, bool freefont)
>
> static void set_vc_hi_font(struct vc_data *vc, bool set);
>
> +static void fbcon_release_all(void)
> +{
> + struct fb_info *info;
> + int i, j, mapped;
> +
> + for_each_registered_fb(i) {
> + mapped = 0;
> + info = registered_fb[i];
> +
> + for (j = first_fb_vc; j <= last_fb_vc; j++) {
> + if (con2fb_map[j] == i) {
> + mapped = 1;
> + con2fb_map[j] = -1;
> + }
> + }
> +
> + if (mapped)
> + fbcon_release(info);
> + }
> +}
> +
> static void fbcon_deinit(struct vc_data *vc)
> {
> struct fbcon_display *p = &fb_display[vc->vc_num];
> @@ -1188,7 +1208,7 @@ static void fbcon_deinit(struct vc_data *vc)
> set_vc_hi_font(vc, false);
>
> if (!con_is_bound(&fb_con))
> - fbcon_exit();
> + fbcon_release_all();
>
> if (vc->vc_num == logo_shown)
> logo_shown = FBCON_LOGO_CANSHOW;
> @@ -3316,34 +3336,6 @@ static void fbcon_start(void)
> #endif
> }
>
> -static void fbcon_exit(void)
> -{
> - struct fb_info *info;
> - int i, j, mapped;
> -
> -#ifdef CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER
> - if (deferred_takeover) {
> - dummycon_unregister_output_notifier(&fbcon_output_nb);
> - deferred_takeover = false;
> - }
> -#endif
> -
> - for_each_registered_fb(i) {
> - mapped = 0;
> - info = registered_fb[i];
> -
> - for (j = first_fb_vc; j <= last_fb_vc; j++) {
> - if (con2fb_map[j] == i) {
> - mapped = 1;
> - con2fb_map[j] = -1;
> - }
> - }
> -
> - if (mapped)
> - fbcon_release(info);
> - }
> -}
> -
> void __init fb_console_init(void)
> {
> int i;
> @@ -3383,10 +3375,19 @@ static void __exit fbcon_deinit_device(void)
>
> void __exit fb_console_exit(void)
> {
> +#ifdef CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER
> + console_lock();
> + if (deferred_takeover)
> + dummycon_unregister_output_notifier(&fbcon_output_nb);
> + console_unlock();
> +
> + cancel_work_sync(&fbcon_deferred_takeover_work);
> +#endif
> +
> console_lock();
> fbcon_deinit_device();
> device_destroy(fb_class, MKDEV(0, 0));
> - fbcon_exit();
> +
We loose the call to fbcon_release_all() here.
We have part of the old fbcon_exit() above, but miss the release parts.
Maybe I missed something obvious?
The rest looks fine.
Sam
> do_unregister_con_driver(&fb_con);
> console_unlock();
> }
> --
> 2.33.0
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 18/21] fbcon: untangle fbcon_exit
@ 2022-02-04 20:06 ` Sam Ravnborg
0 siblings, 0 replies; 241+ messages in thread
From: Sam Ravnborg @ 2022-02-04 20:06 UTC (permalink / raw)
To: Daniel Vetter
Cc: DRI Development, linux-fbdev, Du Cheng, Tetsuo Handa,
Intel Graphics Development, LKML, Claudio Suarez,
Greg Kroah-Hartman, Daniel Vetter
Hi Daniel,
On Mon, Jan 31, 2022 at 10:05:49PM +0100, Daniel Vetter wrote:
> There's a bunch of confusions going on here:
> - The deferred fbcon setup notifier should only be cleaned up from
> fb_console_exit(), to be symmetric with fb_console_init()
> - We also need to make sure we don't race with the work, which means
> temporarily dropping the console lock (or we can deadlock)
> - That also means no point in clearing deferred_takeover, we are
> unloading everything anyway.
> - Finally rename fbcon_exit to fbcon_release_all and move it, since
> that's what's it doing when being called from consw->con_deinit
> through fbcon_deinit.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Claudio Suarez <cssk@net-c.es>
> Cc: Du Cheng <ducheng2@gmail.com>
> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> ---
> drivers/video/fbdev/core/fbcon.c | 63 ++++++++++++++++----------------
> 1 file changed, 32 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
> index 5c14e24d14a1..22581952b4fd 100644
> --- a/drivers/video/fbdev/core/fbcon.c
> +++ b/drivers/video/fbdev/core/fbcon.c
> @@ -185,7 +185,6 @@ static void fbcon_set_disp(struct fb_info *info, struct fb_var_screeninfo *var,
> int unit);
> static void fbcon_modechanged(struct fb_info *info);
> static void fbcon_set_all_vcs(struct fb_info *info);
> -static void fbcon_exit(void);
>
> static struct device *fbcon_device;
>
> @@ -1149,6 +1148,27 @@ static void fbcon_free_font(struct fbcon_display *p, bool freefont)
>
> static void set_vc_hi_font(struct vc_data *vc, bool set);
>
> +static void fbcon_release_all(void)
> +{
> + struct fb_info *info;
> + int i, j, mapped;
> +
> + for_each_registered_fb(i) {
> + mapped = 0;
> + info = registered_fb[i];
> +
> + for (j = first_fb_vc; j <= last_fb_vc; j++) {
> + if (con2fb_map[j] == i) {
> + mapped = 1;
> + con2fb_map[j] = -1;
> + }
> + }
> +
> + if (mapped)
> + fbcon_release(info);
> + }
> +}
> +
> static void fbcon_deinit(struct vc_data *vc)
> {
> struct fbcon_display *p = &fb_display[vc->vc_num];
> @@ -1188,7 +1208,7 @@ static void fbcon_deinit(struct vc_data *vc)
> set_vc_hi_font(vc, false);
>
> if (!con_is_bound(&fb_con))
> - fbcon_exit();
> + fbcon_release_all();
>
> if (vc->vc_num == logo_shown)
> logo_shown = FBCON_LOGO_CANSHOW;
> @@ -3316,34 +3336,6 @@ static void fbcon_start(void)
> #endif
> }
>
> -static void fbcon_exit(void)
> -{
> - struct fb_info *info;
> - int i, j, mapped;
> -
> -#ifdef CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER
> - if (deferred_takeover) {
> - dummycon_unregister_output_notifier(&fbcon_output_nb);
> - deferred_takeover = false;
> - }
> -#endif
> -
> - for_each_registered_fb(i) {
> - mapped = 0;
> - info = registered_fb[i];
> -
> - for (j = first_fb_vc; j <= last_fb_vc; j++) {
> - if (con2fb_map[j] == i) {
> - mapped = 1;
> - con2fb_map[j] = -1;
> - }
> - }
> -
> - if (mapped)
> - fbcon_release(info);
> - }
> -}
> -
> void __init fb_console_init(void)
> {
> int i;
> @@ -3383,10 +3375,19 @@ static void __exit fbcon_deinit_device(void)
>
> void __exit fb_console_exit(void)
> {
> +#ifdef CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER
> + console_lock();
> + if (deferred_takeover)
> + dummycon_unregister_output_notifier(&fbcon_output_nb);
> + console_unlock();
> +
> + cancel_work_sync(&fbcon_deferred_takeover_work);
> +#endif
> +
> console_lock();
> fbcon_deinit_device();
> device_destroy(fb_class, MKDEV(0, 0));
> - fbcon_exit();
> +
We loose the call to fbcon_release_all() here.
We have part of the old fbcon_exit() above, but miss the release parts.
Maybe I missed something obvious?
The rest looks fine.
Sam
> do_unregister_con_driver(&fb_con);
> console_unlock();
> }
> --
> 2.33.0
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 19/21] fbcon: Maintain a private array of fb_info
2022-01-31 21:05 ` [Intel-gfx] " Daniel Vetter
(?)
@ 2022-02-04 20:15 ` Sam Ravnborg
-1 siblings, 0 replies; 241+ messages in thread
From: Sam Ravnborg @ 2022-02-04 20:15 UTC (permalink / raw)
To: Daniel Vetter
Cc: linux-fbdev, Du Cheng, Tetsuo Handa, Greg Kroah-Hartman,
Intel Graphics Development, LKML, DRI Development,
Claudio Suarez, Daniel Vetter
Hi Daniel,
On Mon, Jan 31, 2022 at 10:05:50PM +0100, Daniel Vetter wrote:
> Accessing the one in fbmem.c without taking the right locks is a bad
> idea. Instead maintain our own private copy, which is fully protected
> by console_lock() (like everything else in fbcon.c). That copy is
> serialized through fbcon_fb_registered/unregistered() calls.
I fail to see why we can make a private copy of registered_fb
just like that - are they not somehow shared between fbcon and fbmem.
So when fbmem updates it, then fbcon will use the entry or such?
I guess I am just ignorant of how registered_fb is used - but please
explain.
Sam
>
> Also this means we do not need to hold a full fb_info reference, which
> is nice because doing so would mean a refcount loop between the
> console and the fb_info. But it's also not nice since it means
> console_lock() must be held absolutely everywhere. Well strictly
> speaking we could still try to do some refcounting games again by
> calling get_fb_info before we drop the console_lock. But things will
> get tricky.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> Cc: Claudio Suarez <cssk@net-c.es>
> Cc: Du Cheng <ducheng2@gmail.com>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
> drivers/video/fbdev/core/fbcon.c | 82 +++++++++++++++++---------------
> 1 file changed, 43 insertions(+), 39 deletions(-)
>
> diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
> index 22581952b4fd..a0ca34b29615 100644
> --- a/drivers/video/fbdev/core/fbcon.c
> +++ b/drivers/video/fbdev/core/fbcon.c
> @@ -86,10 +86,6 @@
> * - fbcon state itself is protected by the console_lock, and the code does a
> * pretty good job at making sure that lock is held everywhere it's needed.
> *
> - * - access to the registered_fb array is entirely unprotected. This should use
> - * proper object lifetime handling, i.e. get/put_fb_info. This also means
> - * switching from indices to proper pointers for fb_info everywhere.
> - *
> * - fbcon doesn't bother with fb_lock/unlock at all. This is buggy, since it
> * means concurrent access to the same fbdev from both fbcon and userspace
> * will blow up. To fix this all fbcon calls from fbmem.c need to be moved out
> @@ -107,6 +103,13 @@ enum {
>
> static struct fbcon_display fb_display[MAX_NR_CONSOLES];
>
> +struct fb_info *fbcon_registered_fb[FB_MAX];
> +int fbcon_num_registered_fb;
> +
> +#define fbcon_for_each_registered_fb(i) \
> + for (i = 0; WARN_CONSOLE_UNLOCKED(), i < FB_MAX; i++) \
> + if (!fbcon_registered_fb[i]) {} else
> +
> static signed char con2fb_map[MAX_NR_CONSOLES];
> static signed char con2fb_map_boot[MAX_NR_CONSOLES];
>
> @@ -114,12 +117,7 @@ static struct fb_info *fbcon_info_from_console(int console)
> {
> WARN_CONSOLE_UNLOCKED();
>
> - /*
> - * Note that only con2fb_map is protected by the console lock,
> - * registered_fb is protected by a separate mutex. This lookup can
> - * therefore race.
> - */
> - return registered_fb[con2fb_map[console]];
> + return fbcon_registered_fb[con2fb_map[console]];
> }
>
> static int logo_lines;
> @@ -516,7 +514,7 @@ static int do_fbcon_takeover(int show_logo)
> {
> int err, i;
>
> - if (!num_registered_fb)
> + if (!fbcon_num_registered_fb)
> return -ENODEV;
>
> if (!show_logo)
> @@ -822,7 +820,7 @@ static int set_con2fb_map(int unit, int newidx, int user)
> {
> struct vc_data *vc = vc_cons[unit].d;
> int oldidx = con2fb_map[unit];
> - struct fb_info *info = registered_fb[newidx];
> + struct fb_info *info = fbcon_registered_fb[newidx];
> struct fb_info *oldinfo = NULL;
> int found, err = 0, show_logo;
>
> @@ -840,7 +838,7 @@ static int set_con2fb_map(int unit, int newidx, int user)
> }
>
> if (oldidx != -1)
> - oldinfo = registered_fb[oldidx];
> + oldinfo = fbcon_registered_fb[oldidx];
>
> found = search_fb_in_map(newidx);
>
> @@ -932,13 +930,13 @@ static const char *fbcon_startup(void)
> * If num_registered_fb is zero, this is a call for the dummy part.
> * The frame buffer devices weren't initialized yet.
> */
> - if (!num_registered_fb || info_idx == -1)
> + if (!fbcon_num_registered_fb || info_idx == -1)
> return display_desc;
> /*
> * Instead of blindly using registered_fb[0], we use info_idx, set by
> * fbcon_fb_registered();
> */
> - info = registered_fb[info_idx];
> + info = fbcon_registered_fb[info_idx];
> if (!info)
> return NULL;
>
> @@ -1153,9 +1151,9 @@ static void fbcon_release_all(void)
> struct fb_info *info;
> int i, j, mapped;
>
> - for_each_registered_fb(i) {
> + fbcon_for_each_registered_fb(i) {
> mapped = 0;
> - info = registered_fb[i];
> + info = fbcon_registered_fb[i];
>
> for (j = first_fb_vc; j <= last_fb_vc; j++) {
> if (con2fb_map[j] == i) {
> @@ -1182,7 +1180,7 @@ static void fbcon_deinit(struct vc_data *vc)
> if (idx == -1)
> goto finished;
>
> - info = registered_fb[idx];
> + info = fbcon_registered_fb[idx];
>
> if (!info)
> goto finished;
> @@ -2118,9 +2116,9 @@ static int fbcon_switch(struct vc_data *vc)
> *
> * info->currcon = vc->vc_num;
> */
> - for_each_registered_fb(i) {
> - if (registered_fb[i]->fbcon_par) {
> - struct fbcon_ops *o = registered_fb[i]->fbcon_par;
> + fbcon_for_each_registered_fb(i) {
> + if (fbcon_registered_fb[i]->fbcon_par) {
> + struct fbcon_ops *o = fbcon_registered_fb[i]->fbcon_par;
>
> o->currcon = vc->vc_num;
> }
> @@ -2765,7 +2763,7 @@ int fbcon_mode_deleted(struct fb_info *info,
> j = con2fb_map[i];
> if (j == -1)
> continue;
> - fb_info = registered_fb[j];
> + fb_info = fbcon_registered_fb[j];
> if (fb_info != info)
> continue;
> p = &fb_display[i];
> @@ -2821,7 +2819,7 @@ void fbcon_fb_unbind(struct fb_info *info)
> set_con2fb_map(i, new_idx, 0);
> }
> } else {
> - struct fb_info *info = registered_fb[idx];
> + struct fb_info *info = fbcon_registered_fb[idx];
>
> /* This is sort of like set_con2fb_map, except it maps
> * the consoles to no device and then releases the
> @@ -2851,6 +2849,9 @@ void fbcon_fb_unregistered(struct fb_info *info)
>
> console_lock();
>
> + fbcon_registered_fb[info->node] = NULL;
> + fbcon_num_registered_fb--;
> +
> if (deferred_takeover) {
> console_unlock();
> return;
> @@ -2865,7 +2866,7 @@ void fbcon_fb_unregistered(struct fb_info *info)
> if (idx == info_idx) {
> info_idx = -1;
>
> - for_each_registered_fb(i) {
> + fbcon_for_each_registered_fb(i) {
> info_idx = i;
> break;
> }
> @@ -2881,7 +2882,7 @@ void fbcon_fb_unregistered(struct fb_info *info)
> if (primary_device == idx)
> primary_device = -1;
>
> - if (!num_registered_fb)
> + if (!fbcon_num_registered_fb)
> do_unregister_con_driver(&fb_con);
> console_unlock();
> }
> @@ -2956,6 +2957,9 @@ int fbcon_fb_registered(struct fb_info *info)
> else
> atomic_inc(&ignore_console_lock_warning);
>
> + fbcon_registered_fb[info->node] = info;
> + fbcon_num_registered_fb++;
> +
> idx = info->node;
> fbcon_select_primary(info);
>
> @@ -3075,9 +3079,9 @@ int fbcon_set_con2fb_map_ioctl(void __user *argp)
> return -EINVAL;
> if (con2fb.framebuffer >= FB_MAX)
> return -EINVAL;
> - if (!registered_fb[con2fb.framebuffer])
> + if (!fbcon_registered_fb[con2fb.framebuffer])
> request_module("fb%d", con2fb.framebuffer);
> - if (!registered_fb[con2fb.framebuffer]) {
> + if (!fbcon_registered_fb[con2fb.framebuffer]) {
> return -EINVAL;
> }
>
> @@ -3144,10 +3148,10 @@ static ssize_t store_rotate(struct device *device,
> console_lock();
> idx = con2fb_map[fg_console];
>
> - if (idx == -1 || registered_fb[idx] == NULL)
> + if (idx == -1 || fbcon_registered_fb[idx] == NULL)
> goto err;
>
> - info = registered_fb[idx];
> + info = fbcon_registered_fb[idx];
> rotate = simple_strtoul(buf, last, 0);
> fbcon_rotate(info, rotate);
> err:
> @@ -3166,10 +3170,10 @@ static ssize_t store_rotate_all(struct device *device,
> console_lock();
> idx = con2fb_map[fg_console];
>
> - if (idx == -1 || registered_fb[idx] == NULL)
> + if (idx == -1 || fbcon_registered_fb[idx] == NULL)
> goto err;
>
> - info = registered_fb[idx];
> + info = fbcon_registered_fb[idx];
> rotate = simple_strtoul(buf, last, 0);
> fbcon_rotate_all(info, rotate);
> err:
> @@ -3186,10 +3190,10 @@ static ssize_t show_rotate(struct device *device,
> console_lock();
> idx = con2fb_map[fg_console];
>
> - if (idx == -1 || registered_fb[idx] == NULL)
> + if (idx == -1 || fbcon_registered_fb[idx] == NULL)
> goto err;
>
> - info = registered_fb[idx];
> + info = fbcon_registered_fb[idx];
> rotate = fbcon_get_rotate(info);
> err:
> console_unlock();
> @@ -3206,10 +3210,10 @@ static ssize_t show_cursor_blink(struct device *device,
> console_lock();
> idx = con2fb_map[fg_console];
>
> - if (idx == -1 || registered_fb[idx] == NULL)
> + if (idx == -1 || fbcon_registered_fb[idx] == NULL)
> goto err;
>
> - info = registered_fb[idx];
> + info = fbcon_registered_fb[idx];
> ops = info->fbcon_par;
>
> if (!ops)
> @@ -3232,10 +3236,10 @@ static ssize_t store_cursor_blink(struct device *device,
> console_lock();
> idx = con2fb_map[fg_console];
>
> - if (idx == -1 || registered_fb[idx] == NULL)
> + if (idx == -1 || fbcon_registered_fb[idx] == NULL)
> goto err;
>
> - info = registered_fb[idx];
> + info = fbcon_registered_fb[idx];
>
> if (!info->fbcon_par)
> goto err;
> @@ -3295,8 +3299,8 @@ static void fbcon_register_existing_fbs(struct work_struct *work)
> deferred_takeover = false;
> logo_shown = FBCON_LOGO_DONTSHOW;
>
> - for_each_registered_fb(i)
> - fbcon_fb_registered(registered_fb[i]);
> + fbcon_for_each_registered_fb(i)
> + fbcon_fb_registered(fbcon_registered_fb[i]);
>
> console_unlock();
> }
> --
> 2.33.0
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [Intel-gfx] [PATCH 19/21] fbcon: Maintain a private array of fb_info
@ 2022-02-04 20:15 ` Sam Ravnborg
0 siblings, 0 replies; 241+ messages in thread
From: Sam Ravnborg @ 2022-02-04 20:15 UTC (permalink / raw)
To: Daniel Vetter
Cc: linux-fbdev, Du Cheng, Tetsuo Handa, Greg Kroah-Hartman,
Intel Graphics Development, LKML, DRI Development, Daniel Vetter
Hi Daniel,
On Mon, Jan 31, 2022 at 10:05:50PM +0100, Daniel Vetter wrote:
> Accessing the one in fbmem.c without taking the right locks is a bad
> idea. Instead maintain our own private copy, which is fully protected
> by console_lock() (like everything else in fbcon.c). That copy is
> serialized through fbcon_fb_registered/unregistered() calls.
I fail to see why we can make a private copy of registered_fb
just like that - are they not somehow shared between fbcon and fbmem.
So when fbmem updates it, then fbcon will use the entry or such?
I guess I am just ignorant of how registered_fb is used - but please
explain.
Sam
>
> Also this means we do not need to hold a full fb_info reference, which
> is nice because doing so would mean a refcount loop between the
> console and the fb_info. But it's also not nice since it means
> console_lock() must be held absolutely everywhere. Well strictly
> speaking we could still try to do some refcounting games again by
> calling get_fb_info before we drop the console_lock. But things will
> get tricky.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> Cc: Claudio Suarez <cssk@net-c.es>
> Cc: Du Cheng <ducheng2@gmail.com>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
> drivers/video/fbdev/core/fbcon.c | 82 +++++++++++++++++---------------
> 1 file changed, 43 insertions(+), 39 deletions(-)
>
> diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
> index 22581952b4fd..a0ca34b29615 100644
> --- a/drivers/video/fbdev/core/fbcon.c
> +++ b/drivers/video/fbdev/core/fbcon.c
> @@ -86,10 +86,6 @@
> * - fbcon state itself is protected by the console_lock, and the code does a
> * pretty good job at making sure that lock is held everywhere it's needed.
> *
> - * - access to the registered_fb array is entirely unprotected. This should use
> - * proper object lifetime handling, i.e. get/put_fb_info. This also means
> - * switching from indices to proper pointers for fb_info everywhere.
> - *
> * - fbcon doesn't bother with fb_lock/unlock at all. This is buggy, since it
> * means concurrent access to the same fbdev from both fbcon and userspace
> * will blow up. To fix this all fbcon calls from fbmem.c need to be moved out
> @@ -107,6 +103,13 @@ enum {
>
> static struct fbcon_display fb_display[MAX_NR_CONSOLES];
>
> +struct fb_info *fbcon_registered_fb[FB_MAX];
> +int fbcon_num_registered_fb;
> +
> +#define fbcon_for_each_registered_fb(i) \
> + for (i = 0; WARN_CONSOLE_UNLOCKED(), i < FB_MAX; i++) \
> + if (!fbcon_registered_fb[i]) {} else
> +
> static signed char con2fb_map[MAX_NR_CONSOLES];
> static signed char con2fb_map_boot[MAX_NR_CONSOLES];
>
> @@ -114,12 +117,7 @@ static struct fb_info *fbcon_info_from_console(int console)
> {
> WARN_CONSOLE_UNLOCKED();
>
> - /*
> - * Note that only con2fb_map is protected by the console lock,
> - * registered_fb is protected by a separate mutex. This lookup can
> - * therefore race.
> - */
> - return registered_fb[con2fb_map[console]];
> + return fbcon_registered_fb[con2fb_map[console]];
> }
>
> static int logo_lines;
> @@ -516,7 +514,7 @@ static int do_fbcon_takeover(int show_logo)
> {
> int err, i;
>
> - if (!num_registered_fb)
> + if (!fbcon_num_registered_fb)
> return -ENODEV;
>
> if (!show_logo)
> @@ -822,7 +820,7 @@ static int set_con2fb_map(int unit, int newidx, int user)
> {
> struct vc_data *vc = vc_cons[unit].d;
> int oldidx = con2fb_map[unit];
> - struct fb_info *info = registered_fb[newidx];
> + struct fb_info *info = fbcon_registered_fb[newidx];
> struct fb_info *oldinfo = NULL;
> int found, err = 0, show_logo;
>
> @@ -840,7 +838,7 @@ static int set_con2fb_map(int unit, int newidx, int user)
> }
>
> if (oldidx != -1)
> - oldinfo = registered_fb[oldidx];
> + oldinfo = fbcon_registered_fb[oldidx];
>
> found = search_fb_in_map(newidx);
>
> @@ -932,13 +930,13 @@ static const char *fbcon_startup(void)
> * If num_registered_fb is zero, this is a call for the dummy part.
> * The frame buffer devices weren't initialized yet.
> */
> - if (!num_registered_fb || info_idx == -1)
> + if (!fbcon_num_registered_fb || info_idx == -1)
> return display_desc;
> /*
> * Instead of blindly using registered_fb[0], we use info_idx, set by
> * fbcon_fb_registered();
> */
> - info = registered_fb[info_idx];
> + info = fbcon_registered_fb[info_idx];
> if (!info)
> return NULL;
>
> @@ -1153,9 +1151,9 @@ static void fbcon_release_all(void)
> struct fb_info *info;
> int i, j, mapped;
>
> - for_each_registered_fb(i) {
> + fbcon_for_each_registered_fb(i) {
> mapped = 0;
> - info = registered_fb[i];
> + info = fbcon_registered_fb[i];
>
> for (j = first_fb_vc; j <= last_fb_vc; j++) {
> if (con2fb_map[j] == i) {
> @@ -1182,7 +1180,7 @@ static void fbcon_deinit(struct vc_data *vc)
> if (idx == -1)
> goto finished;
>
> - info = registered_fb[idx];
> + info = fbcon_registered_fb[idx];
>
> if (!info)
> goto finished;
> @@ -2118,9 +2116,9 @@ static int fbcon_switch(struct vc_data *vc)
> *
> * info->currcon = vc->vc_num;
> */
> - for_each_registered_fb(i) {
> - if (registered_fb[i]->fbcon_par) {
> - struct fbcon_ops *o = registered_fb[i]->fbcon_par;
> + fbcon_for_each_registered_fb(i) {
> + if (fbcon_registered_fb[i]->fbcon_par) {
> + struct fbcon_ops *o = fbcon_registered_fb[i]->fbcon_par;
>
> o->currcon = vc->vc_num;
> }
> @@ -2765,7 +2763,7 @@ int fbcon_mode_deleted(struct fb_info *info,
> j = con2fb_map[i];
> if (j == -1)
> continue;
> - fb_info = registered_fb[j];
> + fb_info = fbcon_registered_fb[j];
> if (fb_info != info)
> continue;
> p = &fb_display[i];
> @@ -2821,7 +2819,7 @@ void fbcon_fb_unbind(struct fb_info *info)
> set_con2fb_map(i, new_idx, 0);
> }
> } else {
> - struct fb_info *info = registered_fb[idx];
> + struct fb_info *info = fbcon_registered_fb[idx];
>
> /* This is sort of like set_con2fb_map, except it maps
> * the consoles to no device and then releases the
> @@ -2851,6 +2849,9 @@ void fbcon_fb_unregistered(struct fb_info *info)
>
> console_lock();
>
> + fbcon_registered_fb[info->node] = NULL;
> + fbcon_num_registered_fb--;
> +
> if (deferred_takeover) {
> console_unlock();
> return;
> @@ -2865,7 +2866,7 @@ void fbcon_fb_unregistered(struct fb_info *info)
> if (idx == info_idx) {
> info_idx = -1;
>
> - for_each_registered_fb(i) {
> + fbcon_for_each_registered_fb(i) {
> info_idx = i;
> break;
> }
> @@ -2881,7 +2882,7 @@ void fbcon_fb_unregistered(struct fb_info *info)
> if (primary_device == idx)
> primary_device = -1;
>
> - if (!num_registered_fb)
> + if (!fbcon_num_registered_fb)
> do_unregister_con_driver(&fb_con);
> console_unlock();
> }
> @@ -2956,6 +2957,9 @@ int fbcon_fb_registered(struct fb_info *info)
> else
> atomic_inc(&ignore_console_lock_warning);
>
> + fbcon_registered_fb[info->node] = info;
> + fbcon_num_registered_fb++;
> +
> idx = info->node;
> fbcon_select_primary(info);
>
> @@ -3075,9 +3079,9 @@ int fbcon_set_con2fb_map_ioctl(void __user *argp)
> return -EINVAL;
> if (con2fb.framebuffer >= FB_MAX)
> return -EINVAL;
> - if (!registered_fb[con2fb.framebuffer])
> + if (!fbcon_registered_fb[con2fb.framebuffer])
> request_module("fb%d", con2fb.framebuffer);
> - if (!registered_fb[con2fb.framebuffer]) {
> + if (!fbcon_registered_fb[con2fb.framebuffer]) {
> return -EINVAL;
> }
>
> @@ -3144,10 +3148,10 @@ static ssize_t store_rotate(struct device *device,
> console_lock();
> idx = con2fb_map[fg_console];
>
> - if (idx == -1 || registered_fb[idx] == NULL)
> + if (idx == -1 || fbcon_registered_fb[idx] == NULL)
> goto err;
>
> - info = registered_fb[idx];
> + info = fbcon_registered_fb[idx];
> rotate = simple_strtoul(buf, last, 0);
> fbcon_rotate(info, rotate);
> err:
> @@ -3166,10 +3170,10 @@ static ssize_t store_rotate_all(struct device *device,
> console_lock();
> idx = con2fb_map[fg_console];
>
> - if (idx == -1 || registered_fb[idx] == NULL)
> + if (idx == -1 || fbcon_registered_fb[idx] == NULL)
> goto err;
>
> - info = registered_fb[idx];
> + info = fbcon_registered_fb[idx];
> rotate = simple_strtoul(buf, last, 0);
> fbcon_rotate_all(info, rotate);
> err:
> @@ -3186,10 +3190,10 @@ static ssize_t show_rotate(struct device *device,
> console_lock();
> idx = con2fb_map[fg_console];
>
> - if (idx == -1 || registered_fb[idx] == NULL)
> + if (idx == -1 || fbcon_registered_fb[idx] == NULL)
> goto err;
>
> - info = registered_fb[idx];
> + info = fbcon_registered_fb[idx];
> rotate = fbcon_get_rotate(info);
> err:
> console_unlock();
> @@ -3206,10 +3210,10 @@ static ssize_t show_cursor_blink(struct device *device,
> console_lock();
> idx = con2fb_map[fg_console];
>
> - if (idx == -1 || registered_fb[idx] == NULL)
> + if (idx == -1 || fbcon_registered_fb[idx] == NULL)
> goto err;
>
> - info = registered_fb[idx];
> + info = fbcon_registered_fb[idx];
> ops = info->fbcon_par;
>
> if (!ops)
> @@ -3232,10 +3236,10 @@ static ssize_t store_cursor_blink(struct device *device,
> console_lock();
> idx = con2fb_map[fg_console];
>
> - if (idx == -1 || registered_fb[idx] == NULL)
> + if (idx == -1 || fbcon_registered_fb[idx] == NULL)
> goto err;
>
> - info = registered_fb[idx];
> + info = fbcon_registered_fb[idx];
>
> if (!info->fbcon_par)
> goto err;
> @@ -3295,8 +3299,8 @@ static void fbcon_register_existing_fbs(struct work_struct *work)
> deferred_takeover = false;
> logo_shown = FBCON_LOGO_DONTSHOW;
>
> - for_each_registered_fb(i)
> - fbcon_fb_registered(registered_fb[i]);
> + fbcon_for_each_registered_fb(i)
> + fbcon_fb_registered(fbcon_registered_fb[i]);
>
> console_unlock();
> }
> --
> 2.33.0
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 19/21] fbcon: Maintain a private array of fb_info
@ 2022-02-04 20:15 ` Sam Ravnborg
0 siblings, 0 replies; 241+ messages in thread
From: Sam Ravnborg @ 2022-02-04 20:15 UTC (permalink / raw)
To: Daniel Vetter
Cc: DRI Development, linux-fbdev, Du Cheng, Tetsuo Handa,
Intel Graphics Development, LKML, Claudio Suarez,
Greg Kroah-Hartman, Daniel Vetter
Hi Daniel,
On Mon, Jan 31, 2022 at 10:05:50PM +0100, Daniel Vetter wrote:
> Accessing the one in fbmem.c without taking the right locks is a bad
> idea. Instead maintain our own private copy, which is fully protected
> by console_lock() (like everything else in fbcon.c). That copy is
> serialized through fbcon_fb_registered/unregistered() calls.
I fail to see why we can make a private copy of registered_fb
just like that - are they not somehow shared between fbcon and fbmem.
So when fbmem updates it, then fbcon will use the entry or such?
I guess I am just ignorant of how registered_fb is used - but please
explain.
Sam
>
> Also this means we do not need to hold a full fb_info reference, which
> is nice because doing so would mean a refcount loop between the
> console and the fb_info. But it's also not nice since it means
> console_lock() must be held absolutely everywhere. Well strictly
> speaking we could still try to do some refcounting games again by
> calling get_fb_info before we drop the console_lock. But things will
> get tricky.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> Cc: Claudio Suarez <cssk@net-c.es>
> Cc: Du Cheng <ducheng2@gmail.com>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
> drivers/video/fbdev/core/fbcon.c | 82 +++++++++++++++++---------------
> 1 file changed, 43 insertions(+), 39 deletions(-)
>
> diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
> index 22581952b4fd..a0ca34b29615 100644
> --- a/drivers/video/fbdev/core/fbcon.c
> +++ b/drivers/video/fbdev/core/fbcon.c
> @@ -86,10 +86,6 @@
> * - fbcon state itself is protected by the console_lock, and the code does a
> * pretty good job at making sure that lock is held everywhere it's needed.
> *
> - * - access to the registered_fb array is entirely unprotected. This should use
> - * proper object lifetime handling, i.e. get/put_fb_info. This also means
> - * switching from indices to proper pointers for fb_info everywhere.
> - *
> * - fbcon doesn't bother with fb_lock/unlock at all. This is buggy, since it
> * means concurrent access to the same fbdev from both fbcon and userspace
> * will blow up. To fix this all fbcon calls from fbmem.c need to be moved out
> @@ -107,6 +103,13 @@ enum {
>
> static struct fbcon_display fb_display[MAX_NR_CONSOLES];
>
> +struct fb_info *fbcon_registered_fb[FB_MAX];
> +int fbcon_num_registered_fb;
> +
> +#define fbcon_for_each_registered_fb(i) \
> + for (i = 0; WARN_CONSOLE_UNLOCKED(), i < FB_MAX; i++) \
> + if (!fbcon_registered_fb[i]) {} else
> +
> static signed char con2fb_map[MAX_NR_CONSOLES];
> static signed char con2fb_map_boot[MAX_NR_CONSOLES];
>
> @@ -114,12 +117,7 @@ static struct fb_info *fbcon_info_from_console(int console)
> {
> WARN_CONSOLE_UNLOCKED();
>
> - /*
> - * Note that only con2fb_map is protected by the console lock,
> - * registered_fb is protected by a separate mutex. This lookup can
> - * therefore race.
> - */
> - return registered_fb[con2fb_map[console]];
> + return fbcon_registered_fb[con2fb_map[console]];
> }
>
> static int logo_lines;
> @@ -516,7 +514,7 @@ static int do_fbcon_takeover(int show_logo)
> {
> int err, i;
>
> - if (!num_registered_fb)
> + if (!fbcon_num_registered_fb)
> return -ENODEV;
>
> if (!show_logo)
> @@ -822,7 +820,7 @@ static int set_con2fb_map(int unit, int newidx, int user)
> {
> struct vc_data *vc = vc_cons[unit].d;
> int oldidx = con2fb_map[unit];
> - struct fb_info *info = registered_fb[newidx];
> + struct fb_info *info = fbcon_registered_fb[newidx];
> struct fb_info *oldinfo = NULL;
> int found, err = 0, show_logo;
>
> @@ -840,7 +838,7 @@ static int set_con2fb_map(int unit, int newidx, int user)
> }
>
> if (oldidx != -1)
> - oldinfo = registered_fb[oldidx];
> + oldinfo = fbcon_registered_fb[oldidx];
>
> found = search_fb_in_map(newidx);
>
> @@ -932,13 +930,13 @@ static const char *fbcon_startup(void)
> * If num_registered_fb is zero, this is a call for the dummy part.
> * The frame buffer devices weren't initialized yet.
> */
> - if (!num_registered_fb || info_idx == -1)
> + if (!fbcon_num_registered_fb || info_idx == -1)
> return display_desc;
> /*
> * Instead of blindly using registered_fb[0], we use info_idx, set by
> * fbcon_fb_registered();
> */
> - info = registered_fb[info_idx];
> + info = fbcon_registered_fb[info_idx];
> if (!info)
> return NULL;
>
> @@ -1153,9 +1151,9 @@ static void fbcon_release_all(void)
> struct fb_info *info;
> int i, j, mapped;
>
> - for_each_registered_fb(i) {
> + fbcon_for_each_registered_fb(i) {
> mapped = 0;
> - info = registered_fb[i];
> + info = fbcon_registered_fb[i];
>
> for (j = first_fb_vc; j <= last_fb_vc; j++) {
> if (con2fb_map[j] == i) {
> @@ -1182,7 +1180,7 @@ static void fbcon_deinit(struct vc_data *vc)
> if (idx == -1)
> goto finished;
>
> - info = registered_fb[idx];
> + info = fbcon_registered_fb[idx];
>
> if (!info)
> goto finished;
> @@ -2118,9 +2116,9 @@ static int fbcon_switch(struct vc_data *vc)
> *
> * info->currcon = vc->vc_num;
> */
> - for_each_registered_fb(i) {
> - if (registered_fb[i]->fbcon_par) {
> - struct fbcon_ops *o = registered_fb[i]->fbcon_par;
> + fbcon_for_each_registered_fb(i) {
> + if (fbcon_registered_fb[i]->fbcon_par) {
> + struct fbcon_ops *o = fbcon_registered_fb[i]->fbcon_par;
>
> o->currcon = vc->vc_num;
> }
> @@ -2765,7 +2763,7 @@ int fbcon_mode_deleted(struct fb_info *info,
> j = con2fb_map[i];
> if (j == -1)
> continue;
> - fb_info = registered_fb[j];
> + fb_info = fbcon_registered_fb[j];
> if (fb_info != info)
> continue;
> p = &fb_display[i];
> @@ -2821,7 +2819,7 @@ void fbcon_fb_unbind(struct fb_info *info)
> set_con2fb_map(i, new_idx, 0);
> }
> } else {
> - struct fb_info *info = registered_fb[idx];
> + struct fb_info *info = fbcon_registered_fb[idx];
>
> /* This is sort of like set_con2fb_map, except it maps
> * the consoles to no device and then releases the
> @@ -2851,6 +2849,9 @@ void fbcon_fb_unregistered(struct fb_info *info)
>
> console_lock();
>
> + fbcon_registered_fb[info->node] = NULL;
> + fbcon_num_registered_fb--;
> +
> if (deferred_takeover) {
> console_unlock();
> return;
> @@ -2865,7 +2866,7 @@ void fbcon_fb_unregistered(struct fb_info *info)
> if (idx == info_idx) {
> info_idx = -1;
>
> - for_each_registered_fb(i) {
> + fbcon_for_each_registered_fb(i) {
> info_idx = i;
> break;
> }
> @@ -2881,7 +2882,7 @@ void fbcon_fb_unregistered(struct fb_info *info)
> if (primary_device == idx)
> primary_device = -1;
>
> - if (!num_registered_fb)
> + if (!fbcon_num_registered_fb)
> do_unregister_con_driver(&fb_con);
> console_unlock();
> }
> @@ -2956,6 +2957,9 @@ int fbcon_fb_registered(struct fb_info *info)
> else
> atomic_inc(&ignore_console_lock_warning);
>
> + fbcon_registered_fb[info->node] = info;
> + fbcon_num_registered_fb++;
> +
> idx = info->node;
> fbcon_select_primary(info);
>
> @@ -3075,9 +3079,9 @@ int fbcon_set_con2fb_map_ioctl(void __user *argp)
> return -EINVAL;
> if (con2fb.framebuffer >= FB_MAX)
> return -EINVAL;
> - if (!registered_fb[con2fb.framebuffer])
> + if (!fbcon_registered_fb[con2fb.framebuffer])
> request_module("fb%d", con2fb.framebuffer);
> - if (!registered_fb[con2fb.framebuffer]) {
> + if (!fbcon_registered_fb[con2fb.framebuffer]) {
> return -EINVAL;
> }
>
> @@ -3144,10 +3148,10 @@ static ssize_t store_rotate(struct device *device,
> console_lock();
> idx = con2fb_map[fg_console];
>
> - if (idx == -1 || registered_fb[idx] == NULL)
> + if (idx == -1 || fbcon_registered_fb[idx] == NULL)
> goto err;
>
> - info = registered_fb[idx];
> + info = fbcon_registered_fb[idx];
> rotate = simple_strtoul(buf, last, 0);
> fbcon_rotate(info, rotate);
> err:
> @@ -3166,10 +3170,10 @@ static ssize_t store_rotate_all(struct device *device,
> console_lock();
> idx = con2fb_map[fg_console];
>
> - if (idx == -1 || registered_fb[idx] == NULL)
> + if (idx == -1 || fbcon_registered_fb[idx] == NULL)
> goto err;
>
> - info = registered_fb[idx];
> + info = fbcon_registered_fb[idx];
> rotate = simple_strtoul(buf, last, 0);
> fbcon_rotate_all(info, rotate);
> err:
> @@ -3186,10 +3190,10 @@ static ssize_t show_rotate(struct device *device,
> console_lock();
> idx = con2fb_map[fg_console];
>
> - if (idx == -1 || registered_fb[idx] == NULL)
> + if (idx == -1 || fbcon_registered_fb[idx] == NULL)
> goto err;
>
> - info = registered_fb[idx];
> + info = fbcon_registered_fb[idx];
> rotate = fbcon_get_rotate(info);
> err:
> console_unlock();
> @@ -3206,10 +3210,10 @@ static ssize_t show_cursor_blink(struct device *device,
> console_lock();
> idx = con2fb_map[fg_console];
>
> - if (idx == -1 || registered_fb[idx] == NULL)
> + if (idx == -1 || fbcon_registered_fb[idx] == NULL)
> goto err;
>
> - info = registered_fb[idx];
> + info = fbcon_registered_fb[idx];
> ops = info->fbcon_par;
>
> if (!ops)
> @@ -3232,10 +3236,10 @@ static ssize_t store_cursor_blink(struct device *device,
> console_lock();
> idx = con2fb_map[fg_console];
>
> - if (idx == -1 || registered_fb[idx] == NULL)
> + if (idx == -1 || fbcon_registered_fb[idx] == NULL)
> goto err;
>
> - info = registered_fb[idx];
> + info = fbcon_registered_fb[idx];
>
> if (!info->fbcon_par)
> goto err;
> @@ -3295,8 +3299,8 @@ static void fbcon_register_existing_fbs(struct work_struct *work)
> deferred_takeover = false;
> logo_shown = FBCON_LOGO_DONTSHOW;
>
> - for_each_registered_fb(i)
> - fbcon_fb_registered(registered_fb[i]);
> + fbcon_for_each_registered_fb(i)
> + fbcon_fb_registered(fbcon_registered_fb[i]);
>
> console_unlock();
> }
> --
> 2.33.0
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 06/21] fbcon: delete delayed loading code
2022-02-03 20:45 ` [Intel-gfx] " Sam Ravnborg
(?)
@ 2022-02-08 13:42 ` Daniel Vetter
-1 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-02-08 13:42 UTC (permalink / raw)
To: Sam Ravnborg
Cc: Daniel Vetter, DRI Development, linux-fbdev, Du Cheng,
Tetsuo Handa, Intel Graphics Development, LKML, Claudio Suarez,
Greg Kroah-Hartman, Daniel Vetter, Helge Deller
On Thu, Feb 03, 2022 at 09:45:29PM +0100, Sam Ravnborg wrote:
> Hi Daniel,
>
> On Mon, Jan 31, 2022 at 10:05:37PM +0100, Daniel Vetter wrote:
> > Before
> >
> > commit 6104c37094e729f3d4ce65797002112735d49cd1
> > Author: Daniel Vetter <daniel.vetter@ffwll.ch>
> > Date: Tue Aug 1 17:32:07 2017 +0200
> >
> > fbcon: Make fbcon a built-time depency for fbdev
> >
> > it was possible to load fbcon and fbdev drivers in any order, which
> > means that fbcon init had to handle the case where fbdev drivers where
> > already registered.
> >
> > This is no longer possible, hence delete that code.
> >
> > Note that the exit case is a bit more complex and will be done in a
> > separate patch.
> >
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > Cc: Helge Deller <deller@gmx.de>
> > Cc: Daniel Vetter <daniel@ffwll.ch>
> > Cc: Claudio Suarez <cssk@net-c.es>
> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> > Cc: Du Cheng <ducheng2@gmail.com>
> > ---
> > drivers/video/fbdev/core/fbcon.c | 13 +------------
> > 1 file changed, 1 insertion(+), 12 deletions(-)
> >
> > diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
> > index 8f971de35885..814b648e8f09 100644
> > --- a/drivers/video/fbdev/core/fbcon.c
> > +++ b/drivers/video/fbdev/core/fbcon.c
> > @@ -942,7 +942,7 @@ static const char *fbcon_startup(void)
> > return display_desc;
> > /*
> > * Instead of blindly using registered_fb[0], we use info_idx, set by
> > - * fb_console_init();
> > + * fbcon_fb_registered();
> > */
> This comment change looks like it does not belong in this patch.
> Also, the comment is wrong as info_idx is set in several places.
> Like set_con2fb_map(), fbcon_remap_all(), and more.
Yeah I can split this out into a separate patch, but I spotted this wrong
comment as part of reviewing this code change here - essentially you have
to check how fb_info for fbcon are registered and fbcon init happens to
validate that deleting the below code is correct.
Ok if I put this explainer into the commit message, or do you want me to
split this out fully?
-Daniel
>
> Though it is not set by fb_console_init - so partly OK.
>
> With the comment adjustment dropped.
> Acked-by: Sam Ravnborg <sam@ravnborg.org>
>
> at least the code deletion looked OK, I failed to follow all the logic.
> So would be good if someone else could ack it too.
>
> Sam
>
>
>
> > info = registered_fb[info_idx];
> > if (!info)
> > @@ -3316,17 +3316,6 @@ static void fbcon_start(void)
> > return;
> > }
> > #endif
> > -
> > - if (num_registered_fb) {
> > - int i;
> > -
> > - for_each_registered_fb(i) {
> > - info_idx = i;
> > - break;
> > - }
> > -
> > - do_fbcon_takeover(0);
> > - }
> > }
> >
> > static void fbcon_exit(void)
> > --
> > 2.33.0
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 06/21] fbcon: delete delayed loading code
@ 2022-02-08 13:42 ` Daniel Vetter
0 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-02-08 13:42 UTC (permalink / raw)
To: Sam Ravnborg
Cc: linux-fbdev, Du Cheng, Tetsuo Handa, Daniel Vetter,
Intel Graphics Development, LKML, DRI Development,
Claudio Suarez, Greg Kroah-Hartman, Daniel Vetter, Helge Deller
On Thu, Feb 03, 2022 at 09:45:29PM +0100, Sam Ravnborg wrote:
> Hi Daniel,
>
> On Mon, Jan 31, 2022 at 10:05:37PM +0100, Daniel Vetter wrote:
> > Before
> >
> > commit 6104c37094e729f3d4ce65797002112735d49cd1
> > Author: Daniel Vetter <daniel.vetter@ffwll.ch>
> > Date: Tue Aug 1 17:32:07 2017 +0200
> >
> > fbcon: Make fbcon a built-time depency for fbdev
> >
> > it was possible to load fbcon and fbdev drivers in any order, which
> > means that fbcon init had to handle the case where fbdev drivers where
> > already registered.
> >
> > This is no longer possible, hence delete that code.
> >
> > Note that the exit case is a bit more complex and will be done in a
> > separate patch.
> >
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > Cc: Helge Deller <deller@gmx.de>
> > Cc: Daniel Vetter <daniel@ffwll.ch>
> > Cc: Claudio Suarez <cssk@net-c.es>
> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> > Cc: Du Cheng <ducheng2@gmail.com>
> > ---
> > drivers/video/fbdev/core/fbcon.c | 13 +------------
> > 1 file changed, 1 insertion(+), 12 deletions(-)
> >
> > diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
> > index 8f971de35885..814b648e8f09 100644
> > --- a/drivers/video/fbdev/core/fbcon.c
> > +++ b/drivers/video/fbdev/core/fbcon.c
> > @@ -942,7 +942,7 @@ static const char *fbcon_startup(void)
> > return display_desc;
> > /*
> > * Instead of blindly using registered_fb[0], we use info_idx, set by
> > - * fb_console_init();
> > + * fbcon_fb_registered();
> > */
> This comment change looks like it does not belong in this patch.
> Also, the comment is wrong as info_idx is set in several places.
> Like set_con2fb_map(), fbcon_remap_all(), and more.
Yeah I can split this out into a separate patch, but I spotted this wrong
comment as part of reviewing this code change here - essentially you have
to check how fb_info for fbcon are registered and fbcon init happens to
validate that deleting the below code is correct.
Ok if I put this explainer into the commit message, or do you want me to
split this out fully?
-Daniel
>
> Though it is not set by fb_console_init - so partly OK.
>
> With the comment adjustment dropped.
> Acked-by: Sam Ravnborg <sam@ravnborg.org>
>
> at least the code deletion looked OK, I failed to follow all the logic.
> So would be good if someone else could ack it too.
>
> Sam
>
>
>
> > info = registered_fb[info_idx];
> > if (!info)
> > @@ -3316,17 +3316,6 @@ static void fbcon_start(void)
> > return;
> > }
> > #endif
> > -
> > - if (num_registered_fb) {
> > - int i;
> > -
> > - for_each_registered_fb(i) {
> > - info_idx = i;
> > - break;
> > - }
> > -
> > - do_fbcon_takeover(0);
> > - }
> > }
> >
> > static void fbcon_exit(void)
> > --
> > 2.33.0
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [Intel-gfx] [PATCH 06/21] fbcon: delete delayed loading code
@ 2022-02-08 13:42 ` Daniel Vetter
0 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-02-08 13:42 UTC (permalink / raw)
To: Sam Ravnborg
Cc: linux-fbdev, Du Cheng, Tetsuo Handa, Daniel Vetter,
Intel Graphics Development, LKML, DRI Development,
Greg Kroah-Hartman, Daniel Vetter, Helge Deller
On Thu, Feb 03, 2022 at 09:45:29PM +0100, Sam Ravnborg wrote:
> Hi Daniel,
>
> On Mon, Jan 31, 2022 at 10:05:37PM +0100, Daniel Vetter wrote:
> > Before
> >
> > commit 6104c37094e729f3d4ce65797002112735d49cd1
> > Author: Daniel Vetter <daniel.vetter@ffwll.ch>
> > Date: Tue Aug 1 17:32:07 2017 +0200
> >
> > fbcon: Make fbcon a built-time depency for fbdev
> >
> > it was possible to load fbcon and fbdev drivers in any order, which
> > means that fbcon init had to handle the case where fbdev drivers where
> > already registered.
> >
> > This is no longer possible, hence delete that code.
> >
> > Note that the exit case is a bit more complex and will be done in a
> > separate patch.
> >
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > Cc: Helge Deller <deller@gmx.de>
> > Cc: Daniel Vetter <daniel@ffwll.ch>
> > Cc: Claudio Suarez <cssk@net-c.es>
> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> > Cc: Du Cheng <ducheng2@gmail.com>
> > ---
> > drivers/video/fbdev/core/fbcon.c | 13 +------------
> > 1 file changed, 1 insertion(+), 12 deletions(-)
> >
> > diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
> > index 8f971de35885..814b648e8f09 100644
> > --- a/drivers/video/fbdev/core/fbcon.c
> > +++ b/drivers/video/fbdev/core/fbcon.c
> > @@ -942,7 +942,7 @@ static const char *fbcon_startup(void)
> > return display_desc;
> > /*
> > * Instead of blindly using registered_fb[0], we use info_idx, set by
> > - * fb_console_init();
> > + * fbcon_fb_registered();
> > */
> This comment change looks like it does not belong in this patch.
> Also, the comment is wrong as info_idx is set in several places.
> Like set_con2fb_map(), fbcon_remap_all(), and more.
Yeah I can split this out into a separate patch, but I spotted this wrong
comment as part of reviewing this code change here - essentially you have
to check how fb_info for fbcon are registered and fbcon init happens to
validate that deleting the below code is correct.
Ok if I put this explainer into the commit message, or do you want me to
split this out fully?
-Daniel
>
> Though it is not set by fb_console_init - so partly OK.
>
> With the comment adjustment dropped.
> Acked-by: Sam Ravnborg <sam@ravnborg.org>
>
> at least the code deletion looked OK, I failed to follow all the logic.
> So would be good if someone else could ack it too.
>
> Sam
>
>
>
> > info = registered_fb[info_idx];
> > if (!info)
> > @@ -3316,17 +3316,6 @@ static void fbcon_start(void)
> > return;
> > }
> > #endif
> > -
> > - if (num_registered_fb) {
> > - int i;
> > -
> > - for_each_registered_fb(i) {
> > - info_idx = i;
> > - break;
> > - }
> > -
> > - do_fbcon_takeover(0);
> > - }
> > }
> >
> > static void fbcon_exit(void)
> > --
> > 2.33.0
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 10/21] fb: Delete fb_info->queue
2022-02-03 21:31 ` [Intel-gfx] " Sam Ravnborg
(?)
@ 2022-02-08 13:46 ` Daniel Vetter
-1 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-02-08 13:46 UTC (permalink / raw)
To: Sam Ravnborg
Cc: Daniel Vetter, DRI Development, linux-fbdev,
Intel Graphics Development, LKML, Daniel Vetter, Helge Deller
On Thu, Feb 03, 2022 at 10:31:00PM +0100, Sam Ravnborg wrote:
> On Mon, Jan 31, 2022 at 10:05:41PM +0100, Daniel Vetter wrote:
> > It was only used by fbcon, and that now switched to its own,
> > private work.
> >
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > Cc: Helge Deller <deller@gmx.de>
> > Cc: linux-fbdev@vger.kernel.org
> I would merge this with the patch that drops the usage
Yeah, but I like to split these out so that if this does break something,
it's much easier to revert. In case I overlooked something somewhere.
It's imo different if the cleanup is directly related to the preceeding
prep work, but this is a generic workqueue, and the cursor logic is rather
unrelated. And if I remember my history digging right, there were actually
other uses of this.
-Daniel
>
> > ---
> > include/linux/fb.h | 1 -
> > 1 file changed, 1 deletion(-)
> >
> > diff --git a/include/linux/fb.h b/include/linux/fb.h
> > index 02f362c661c8..a8a00d2ba1f3 100644
> > --- a/include/linux/fb.h
> > +++ b/include/linux/fb.h
> > @@ -449,7 +449,6 @@ struct fb_info {
> > struct fb_var_screeninfo var; /* Current var */
> > struct fb_fix_screeninfo fix; /* Current fix */
> > struct fb_monspecs monspecs; /* Current Monitor specs */
> > - struct work_struct queue; /* Framebuffer event queue */
> > struct fb_pixmap pixmap; /* Image hardware mapper */
> > struct fb_pixmap sprite; /* Cursor hardware mapper */
> > struct fb_cmap cmap; /* Current cmap */
> > --
> > 2.33.0
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 10/21] fb: Delete fb_info->queue
@ 2022-02-08 13:46 ` Daniel Vetter
0 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-02-08 13:46 UTC (permalink / raw)
To: Sam Ravnborg
Cc: linux-fbdev, Daniel Vetter, Intel Graphics Development, LKML,
DRI Development, Daniel Vetter, Helge Deller
On Thu, Feb 03, 2022 at 10:31:00PM +0100, Sam Ravnborg wrote:
> On Mon, Jan 31, 2022 at 10:05:41PM +0100, Daniel Vetter wrote:
> > It was only used by fbcon, and that now switched to its own,
> > private work.
> >
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > Cc: Helge Deller <deller@gmx.de>
> > Cc: linux-fbdev@vger.kernel.org
> I would merge this with the patch that drops the usage
Yeah, but I like to split these out so that if this does break something,
it's much easier to revert. In case I overlooked something somewhere.
It's imo different if the cleanup is directly related to the preceeding
prep work, but this is a generic workqueue, and the cursor logic is rather
unrelated. And if I remember my history digging right, there were actually
other uses of this.
-Daniel
>
> > ---
> > include/linux/fb.h | 1 -
> > 1 file changed, 1 deletion(-)
> >
> > diff --git a/include/linux/fb.h b/include/linux/fb.h
> > index 02f362c661c8..a8a00d2ba1f3 100644
> > --- a/include/linux/fb.h
> > +++ b/include/linux/fb.h
> > @@ -449,7 +449,6 @@ struct fb_info {
> > struct fb_var_screeninfo var; /* Current var */
> > struct fb_fix_screeninfo fix; /* Current fix */
> > struct fb_monspecs monspecs; /* Current Monitor specs */
> > - struct work_struct queue; /* Framebuffer event queue */
> > struct fb_pixmap pixmap; /* Image hardware mapper */
> > struct fb_pixmap sprite; /* Cursor hardware mapper */
> > struct fb_cmap cmap; /* Current cmap */
> > --
> > 2.33.0
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [Intel-gfx] [PATCH 10/21] fb: Delete fb_info->queue
@ 2022-02-08 13:46 ` Daniel Vetter
0 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-02-08 13:46 UTC (permalink / raw)
To: Sam Ravnborg
Cc: linux-fbdev, Daniel Vetter, Intel Graphics Development, LKML,
DRI Development, Daniel Vetter, Helge Deller
On Thu, Feb 03, 2022 at 10:31:00PM +0100, Sam Ravnborg wrote:
> On Mon, Jan 31, 2022 at 10:05:41PM +0100, Daniel Vetter wrote:
> > It was only used by fbcon, and that now switched to its own,
> > private work.
> >
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > Cc: Helge Deller <deller@gmx.de>
> > Cc: linux-fbdev@vger.kernel.org
> I would merge this with the patch that drops the usage
Yeah, but I like to split these out so that if this does break something,
it's much easier to revert. In case I overlooked something somewhere.
It's imo different if the cleanup is directly related to the preceeding
prep work, but this is a generic workqueue, and the cursor logic is rather
unrelated. And if I remember my history digging right, there were actually
other uses of this.
-Daniel
>
> > ---
> > include/linux/fb.h | 1 -
> > 1 file changed, 1 deletion(-)
> >
> > diff --git a/include/linux/fb.h b/include/linux/fb.h
> > index 02f362c661c8..a8a00d2ba1f3 100644
> > --- a/include/linux/fb.h
> > +++ b/include/linux/fb.h
> > @@ -449,7 +449,6 @@ struct fb_info {
> > struct fb_var_screeninfo var; /* Current var */
> > struct fb_fix_screeninfo fix; /* Current fix */
> > struct fb_monspecs monspecs; /* Current Monitor specs */
> > - struct work_struct queue; /* Framebuffer event queue */
> > struct fb_pixmap pixmap; /* Image hardware mapper */
> > struct fb_pixmap sprite; /* Cursor hardware mapper */
> > struct fb_cmap cmap; /* Current cmap */
> > --
> > 2.33.0
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 11/21] fbcon: Extract fbcon_open/release helpers
2022-02-03 21:15 ` [Intel-gfx] " Sam Ravnborg
(?)
@ 2022-02-08 13:48 ` Daniel Vetter
-1 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-02-08 13:48 UTC (permalink / raw)
To: Sam Ravnborg
Cc: Daniel Vetter, DRI Development, linux-fbdev, Du Cheng,
Tetsuo Handa, Intel Graphics Development, LKML, Claudio Suarez,
Greg Kroah-Hartman, Daniel Vetter
On Thu, Feb 03, 2022 at 10:15:14PM +0100, Sam Ravnborg wrote:
> Hi Daniel,
>
> On Mon, Jan 31, 2022 at 10:05:42PM +0100, Daniel Vetter wrote:
> > There's two minor behaviour changes in here:
> > - in error paths we now consistently call fb_ops->fb_release
> > - fb_release really can't fail (fbmem.c ignores it too) and there's no
> > reasonable cleanup we can do anyway.
> >
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > Cc: Daniel Vetter <daniel@ffwll.ch>
> > Cc: Claudio Suarez <cssk@net-c.es>
> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> > Cc: Du Cheng <ducheng2@gmail.com>
> > ---
> > drivers/video/fbdev/core/fbcon.c | 107 +++++++++++++++----------------
> > 1 file changed, 53 insertions(+), 54 deletions(-)
> >
> > diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
> > index fa30e1909164..eea2ee14b64c 100644
> > --- a/drivers/video/fbdev/core/fbcon.c
> > +++ b/drivers/video/fbdev/core/fbcon.c
> > @@ -680,19 +680,37 @@ static int fbcon_invalid_charcount(struct fb_info *info, unsigned charcount)
> >
> > #endif /* CONFIG_MISC_TILEBLITTING */
> >
> > +static int fbcon_open(struct fb_info *info)
> > +{
> > + if (!try_module_get(info->fbops->owner))
> > + return -ENODEV;
> > +
> > + if (info->fbops->fb_open &&
> > + info->fbops->fb_open(info, 0)) {
> > + module_put(info->fbops->owner);
> > + return -ENODEV;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static void fbcon_release(struct fb_info *info)
> > +{
> > + if (info->fbops->fb_release)
> > + info->fbops->fb_release(info, 0);
> > +
> > + module_put(info->fbops->owner);
> > +}
> >
> > static int con2fb_acquire_newinfo(struct vc_data *vc, struct fb_info *info,
> > int unit, int oldidx)
> > {
> > struct fbcon_ops *ops = NULL;
> > - int err = 0;
> > -
> > - if (!try_module_get(info->fbops->owner))
> > - err = -ENODEV;
> > + int err;
> >
> > - if (!err && info->fbops->fb_open &&
> > - info->fbops->fb_open(info, 0))
> > - err = -ENODEV;
> > + err = fbcon_open(info);
> > + if (err)
> > + return err;
> >
> > if (!err) {
> > ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL);
> > @@ -713,7 +731,7 @@ static int con2fb_acquire_newinfo(struct vc_data *vc, struct fb_info *info,
> >
> > if (err) {
> > con2fb_map[unit] = oldidx;
> > - module_put(info->fbops->owner);
> > + fbcon_release(info);
> > }
> >
> > return err;
> > @@ -724,45 +742,34 @@ static int con2fb_release_oldinfo(struct vc_data *vc, struct fb_info *oldinfo,
> > int oldidx, int found)
> > {
> > struct fbcon_ops *ops = oldinfo->fbcon_par;
> > - int err = 0, ret;
> > + int ret;
> >
> > - if (oldinfo->fbops->fb_release &&
> > - oldinfo->fbops->fb_release(oldinfo, 0)) {
> > - con2fb_map[unit] = oldidx;
> The old code assigns con2fb_map[unit] before is calls
> newinfo->fbops->fb_release).
> I wonder if there can be any callback to fbcon where the value
> of con2fb_map[unit] matters?
It's all protected by console_lock, so other threads cannot see the
inconsistent state.
Essentially everything in fbcon.c is protected by console_lock().
Do you want me to hammer this in somewhere (maybe in the commit message),
or good enough for your ack?
-Daniel
>
>
> > - if (!found && newinfo->fbops->fb_release)
> > - newinfo->fbops->fb_release(newinfo, 0);
> > - if (!found)
> > - module_put(newinfo->fbops->owner);
> > - err = -ENODEV;
> > - }
> > + fbcon_release(oldinfo);
> >
> > - if (!err) {
> > - fbcon_del_cursor_work(oldinfo);
> > - kfree(ops->cursor_state.mask);
> > - kfree(ops->cursor_data);
> > - kfree(ops->cursor_src);
> > - kfree(ops->fontbuffer);
> > - kfree(oldinfo->fbcon_par);
> > - oldinfo->fbcon_par = NULL;
> > - module_put(oldinfo->fbops->owner);
> > - /*
> > - If oldinfo and newinfo are driving the same hardware,
> > - the fb_release() method of oldinfo may attempt to
> > - restore the hardware state. This will leave the
> > - newinfo in an undefined state. Thus, a call to
> > - fb_set_par() may be needed for the newinfo.
> > - */
> > - if (newinfo && newinfo->fbops->fb_set_par) {
> > - ret = newinfo->fbops->fb_set_par(newinfo);
> > + fbcon_del_cursor_work(oldinfo);
>
>
> > + kfree(ops->cursor_state.mask);
> > + kfree(ops->cursor_data);
> > + kfree(ops->cursor_src);
> > + kfree(ops->fontbuffer);
> > + kfree(oldinfo->fbcon_par);
> > + oldinfo->fbcon_par = NULL;
> These all look like candidates to stuff into fbcon_release()
> That would drop the nice symmetry but make it more consistent.
>
> I think we miss freeing ops->cursor_data in fbcon_exit(),
> but I did not follow all the code.
>
> With my ramblings considered the patch is
> Acked-by: Sam Ravnborg <sam@ravnborg.org>
>
> Sam
>
> > + /*
> > + If oldinfo and newinfo are driving the same hardware,
> > + the fb_release() method of oldinfo may attempt to
> > + restore the hardware state. This will leave the
> > + newinfo in an undefined state. Thus, a call to
> > + fb_set_par() may be needed for the newinfo.
> > + */
> > + if (newinfo && newinfo->fbops->fb_set_par) {
> > + ret = newinfo->fbops->fb_set_par(newinfo);
> >
> > - if (ret)
> > - printk(KERN_ERR "con2fb_release_oldinfo: "
> > - "detected unhandled fb_set_par error, "
> > - "error code %d\n", ret);
> > - }
> > + if (ret)
> > + printk(KERN_ERR "con2fb_release_oldinfo: "
> > + "detected unhandled fb_set_par error, "
> > + "error code %d\n", ret);
> > }
> >
> > - return err;
> > + return 0;
> > }
> >
> > static void con2fb_init_display(struct vc_data *vc, struct fb_info *info,
> > @@ -917,7 +924,6 @@ static const char *fbcon_startup(void)
> > struct fbcon_display *p = &fb_display[fg_console];
> > struct vc_data *vc = vc_cons[fg_console].d;
> > const struct font_desc *font = NULL;
> > - struct module *owner;
> > struct fb_info *info = NULL;
> > struct fbcon_ops *ops;
> > int rows, cols;
> > @@ -936,17 +942,12 @@ static const char *fbcon_startup(void)
> > if (!info)
> > return NULL;
> >
> > - owner = info->fbops->owner;
> > - if (!try_module_get(owner))
> > + if (fbcon_open(info))
> > return NULL;
> > - if (info->fbops->fb_open && info->fbops->fb_open(info, 0)) {
> > - module_put(owner);
> > - return NULL;
> > - }
> >
> > ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL);
> > if (!ops) {
> > - module_put(owner);
> > + fbcon_release(info);
> > return NULL;
> > }
> >
> > @@ -3331,10 +3332,6 @@ static void fbcon_exit(void)
> > }
> >
> > if (mapped) {
> > - if (info->fbops->fb_release)
> > - info->fbops->fb_release(info, 0);
> > - module_put(info->fbops->owner);
> > -
> > if (info->fbcon_par) {
> > struct fbcon_ops *ops = info->fbcon_par;
> >
> > @@ -3344,6 +3341,8 @@ static void fbcon_exit(void)
> > kfree(info->fbcon_par);
> > info->fbcon_par = NULL;
> > }
> > +
> > + fbcon_release(info);
> > }
> > }
> > }
> > --
> > 2.33.0
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 11/21] fbcon: Extract fbcon_open/release helpers
@ 2022-02-08 13:48 ` Daniel Vetter
0 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-02-08 13:48 UTC (permalink / raw)
To: Sam Ravnborg
Cc: linux-fbdev, Du Cheng, Tetsuo Handa, Daniel Vetter,
Intel Graphics Development, LKML, DRI Development,
Claudio Suarez, Greg Kroah-Hartman, Daniel Vetter
On Thu, Feb 03, 2022 at 10:15:14PM +0100, Sam Ravnborg wrote:
> Hi Daniel,
>
> On Mon, Jan 31, 2022 at 10:05:42PM +0100, Daniel Vetter wrote:
> > There's two minor behaviour changes in here:
> > - in error paths we now consistently call fb_ops->fb_release
> > - fb_release really can't fail (fbmem.c ignores it too) and there's no
> > reasonable cleanup we can do anyway.
> >
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > Cc: Daniel Vetter <daniel@ffwll.ch>
> > Cc: Claudio Suarez <cssk@net-c.es>
> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> > Cc: Du Cheng <ducheng2@gmail.com>
> > ---
> > drivers/video/fbdev/core/fbcon.c | 107 +++++++++++++++----------------
> > 1 file changed, 53 insertions(+), 54 deletions(-)
> >
> > diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
> > index fa30e1909164..eea2ee14b64c 100644
> > --- a/drivers/video/fbdev/core/fbcon.c
> > +++ b/drivers/video/fbdev/core/fbcon.c
> > @@ -680,19 +680,37 @@ static int fbcon_invalid_charcount(struct fb_info *info, unsigned charcount)
> >
> > #endif /* CONFIG_MISC_TILEBLITTING */
> >
> > +static int fbcon_open(struct fb_info *info)
> > +{
> > + if (!try_module_get(info->fbops->owner))
> > + return -ENODEV;
> > +
> > + if (info->fbops->fb_open &&
> > + info->fbops->fb_open(info, 0)) {
> > + module_put(info->fbops->owner);
> > + return -ENODEV;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static void fbcon_release(struct fb_info *info)
> > +{
> > + if (info->fbops->fb_release)
> > + info->fbops->fb_release(info, 0);
> > +
> > + module_put(info->fbops->owner);
> > +}
> >
> > static int con2fb_acquire_newinfo(struct vc_data *vc, struct fb_info *info,
> > int unit, int oldidx)
> > {
> > struct fbcon_ops *ops = NULL;
> > - int err = 0;
> > -
> > - if (!try_module_get(info->fbops->owner))
> > - err = -ENODEV;
> > + int err;
> >
> > - if (!err && info->fbops->fb_open &&
> > - info->fbops->fb_open(info, 0))
> > - err = -ENODEV;
> > + err = fbcon_open(info);
> > + if (err)
> > + return err;
> >
> > if (!err) {
> > ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL);
> > @@ -713,7 +731,7 @@ static int con2fb_acquire_newinfo(struct vc_data *vc, struct fb_info *info,
> >
> > if (err) {
> > con2fb_map[unit] = oldidx;
> > - module_put(info->fbops->owner);
> > + fbcon_release(info);
> > }
> >
> > return err;
> > @@ -724,45 +742,34 @@ static int con2fb_release_oldinfo(struct vc_data *vc, struct fb_info *oldinfo,
> > int oldidx, int found)
> > {
> > struct fbcon_ops *ops = oldinfo->fbcon_par;
> > - int err = 0, ret;
> > + int ret;
> >
> > - if (oldinfo->fbops->fb_release &&
> > - oldinfo->fbops->fb_release(oldinfo, 0)) {
> > - con2fb_map[unit] = oldidx;
> The old code assigns con2fb_map[unit] before is calls
> newinfo->fbops->fb_release).
> I wonder if there can be any callback to fbcon where the value
> of con2fb_map[unit] matters?
It's all protected by console_lock, so other threads cannot see the
inconsistent state.
Essentially everything in fbcon.c is protected by console_lock().
Do you want me to hammer this in somewhere (maybe in the commit message),
or good enough for your ack?
-Daniel
>
>
> > - if (!found && newinfo->fbops->fb_release)
> > - newinfo->fbops->fb_release(newinfo, 0);
> > - if (!found)
> > - module_put(newinfo->fbops->owner);
> > - err = -ENODEV;
> > - }
> > + fbcon_release(oldinfo);
> >
> > - if (!err) {
> > - fbcon_del_cursor_work(oldinfo);
> > - kfree(ops->cursor_state.mask);
> > - kfree(ops->cursor_data);
> > - kfree(ops->cursor_src);
> > - kfree(ops->fontbuffer);
> > - kfree(oldinfo->fbcon_par);
> > - oldinfo->fbcon_par = NULL;
> > - module_put(oldinfo->fbops->owner);
> > - /*
> > - If oldinfo and newinfo are driving the same hardware,
> > - the fb_release() method of oldinfo may attempt to
> > - restore the hardware state. This will leave the
> > - newinfo in an undefined state. Thus, a call to
> > - fb_set_par() may be needed for the newinfo.
> > - */
> > - if (newinfo && newinfo->fbops->fb_set_par) {
> > - ret = newinfo->fbops->fb_set_par(newinfo);
> > + fbcon_del_cursor_work(oldinfo);
>
>
> > + kfree(ops->cursor_state.mask);
> > + kfree(ops->cursor_data);
> > + kfree(ops->cursor_src);
> > + kfree(ops->fontbuffer);
> > + kfree(oldinfo->fbcon_par);
> > + oldinfo->fbcon_par = NULL;
> These all look like candidates to stuff into fbcon_release()
> That would drop the nice symmetry but make it more consistent.
>
> I think we miss freeing ops->cursor_data in fbcon_exit(),
> but I did not follow all the code.
>
> With my ramblings considered the patch is
> Acked-by: Sam Ravnborg <sam@ravnborg.org>
>
> Sam
>
> > + /*
> > + If oldinfo and newinfo are driving the same hardware,
> > + the fb_release() method of oldinfo may attempt to
> > + restore the hardware state. This will leave the
> > + newinfo in an undefined state. Thus, a call to
> > + fb_set_par() may be needed for the newinfo.
> > + */
> > + if (newinfo && newinfo->fbops->fb_set_par) {
> > + ret = newinfo->fbops->fb_set_par(newinfo);
> >
> > - if (ret)
> > - printk(KERN_ERR "con2fb_release_oldinfo: "
> > - "detected unhandled fb_set_par error, "
> > - "error code %d\n", ret);
> > - }
> > + if (ret)
> > + printk(KERN_ERR "con2fb_release_oldinfo: "
> > + "detected unhandled fb_set_par error, "
> > + "error code %d\n", ret);
> > }
> >
> > - return err;
> > + return 0;
> > }
> >
> > static void con2fb_init_display(struct vc_data *vc, struct fb_info *info,
> > @@ -917,7 +924,6 @@ static const char *fbcon_startup(void)
> > struct fbcon_display *p = &fb_display[fg_console];
> > struct vc_data *vc = vc_cons[fg_console].d;
> > const struct font_desc *font = NULL;
> > - struct module *owner;
> > struct fb_info *info = NULL;
> > struct fbcon_ops *ops;
> > int rows, cols;
> > @@ -936,17 +942,12 @@ static const char *fbcon_startup(void)
> > if (!info)
> > return NULL;
> >
> > - owner = info->fbops->owner;
> > - if (!try_module_get(owner))
> > + if (fbcon_open(info))
> > return NULL;
> > - if (info->fbops->fb_open && info->fbops->fb_open(info, 0)) {
> > - module_put(owner);
> > - return NULL;
> > - }
> >
> > ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL);
> > if (!ops) {
> > - module_put(owner);
> > + fbcon_release(info);
> > return NULL;
> > }
> >
> > @@ -3331,10 +3332,6 @@ static void fbcon_exit(void)
> > }
> >
> > if (mapped) {
> > - if (info->fbops->fb_release)
> > - info->fbops->fb_release(info, 0);
> > - module_put(info->fbops->owner);
> > -
> > if (info->fbcon_par) {
> > struct fbcon_ops *ops = info->fbcon_par;
> >
> > @@ -3344,6 +3341,8 @@ static void fbcon_exit(void)
> > kfree(info->fbcon_par);
> > info->fbcon_par = NULL;
> > }
> > +
> > + fbcon_release(info);
> > }
> > }
> > }
> > --
> > 2.33.0
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [Intel-gfx] [PATCH 11/21] fbcon: Extract fbcon_open/release helpers
@ 2022-02-08 13:48 ` Daniel Vetter
0 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-02-08 13:48 UTC (permalink / raw)
To: Sam Ravnborg
Cc: linux-fbdev, Du Cheng, Tetsuo Handa, Daniel Vetter,
Intel Graphics Development, LKML, DRI Development,
Greg Kroah-Hartman, Daniel Vetter
On Thu, Feb 03, 2022 at 10:15:14PM +0100, Sam Ravnborg wrote:
> Hi Daniel,
>
> On Mon, Jan 31, 2022 at 10:05:42PM +0100, Daniel Vetter wrote:
> > There's two minor behaviour changes in here:
> > - in error paths we now consistently call fb_ops->fb_release
> > - fb_release really can't fail (fbmem.c ignores it too) and there's no
> > reasonable cleanup we can do anyway.
> >
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > Cc: Daniel Vetter <daniel@ffwll.ch>
> > Cc: Claudio Suarez <cssk@net-c.es>
> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> > Cc: Du Cheng <ducheng2@gmail.com>
> > ---
> > drivers/video/fbdev/core/fbcon.c | 107 +++++++++++++++----------------
> > 1 file changed, 53 insertions(+), 54 deletions(-)
> >
> > diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
> > index fa30e1909164..eea2ee14b64c 100644
> > --- a/drivers/video/fbdev/core/fbcon.c
> > +++ b/drivers/video/fbdev/core/fbcon.c
> > @@ -680,19 +680,37 @@ static int fbcon_invalid_charcount(struct fb_info *info, unsigned charcount)
> >
> > #endif /* CONFIG_MISC_TILEBLITTING */
> >
> > +static int fbcon_open(struct fb_info *info)
> > +{
> > + if (!try_module_get(info->fbops->owner))
> > + return -ENODEV;
> > +
> > + if (info->fbops->fb_open &&
> > + info->fbops->fb_open(info, 0)) {
> > + module_put(info->fbops->owner);
> > + return -ENODEV;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static void fbcon_release(struct fb_info *info)
> > +{
> > + if (info->fbops->fb_release)
> > + info->fbops->fb_release(info, 0);
> > +
> > + module_put(info->fbops->owner);
> > +}
> >
> > static int con2fb_acquire_newinfo(struct vc_data *vc, struct fb_info *info,
> > int unit, int oldidx)
> > {
> > struct fbcon_ops *ops = NULL;
> > - int err = 0;
> > -
> > - if (!try_module_get(info->fbops->owner))
> > - err = -ENODEV;
> > + int err;
> >
> > - if (!err && info->fbops->fb_open &&
> > - info->fbops->fb_open(info, 0))
> > - err = -ENODEV;
> > + err = fbcon_open(info);
> > + if (err)
> > + return err;
> >
> > if (!err) {
> > ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL);
> > @@ -713,7 +731,7 @@ static int con2fb_acquire_newinfo(struct vc_data *vc, struct fb_info *info,
> >
> > if (err) {
> > con2fb_map[unit] = oldidx;
> > - module_put(info->fbops->owner);
> > + fbcon_release(info);
> > }
> >
> > return err;
> > @@ -724,45 +742,34 @@ static int con2fb_release_oldinfo(struct vc_data *vc, struct fb_info *oldinfo,
> > int oldidx, int found)
> > {
> > struct fbcon_ops *ops = oldinfo->fbcon_par;
> > - int err = 0, ret;
> > + int ret;
> >
> > - if (oldinfo->fbops->fb_release &&
> > - oldinfo->fbops->fb_release(oldinfo, 0)) {
> > - con2fb_map[unit] = oldidx;
> The old code assigns con2fb_map[unit] before is calls
> newinfo->fbops->fb_release).
> I wonder if there can be any callback to fbcon where the value
> of con2fb_map[unit] matters?
It's all protected by console_lock, so other threads cannot see the
inconsistent state.
Essentially everything in fbcon.c is protected by console_lock().
Do you want me to hammer this in somewhere (maybe in the commit message),
or good enough for your ack?
-Daniel
>
>
> > - if (!found && newinfo->fbops->fb_release)
> > - newinfo->fbops->fb_release(newinfo, 0);
> > - if (!found)
> > - module_put(newinfo->fbops->owner);
> > - err = -ENODEV;
> > - }
> > + fbcon_release(oldinfo);
> >
> > - if (!err) {
> > - fbcon_del_cursor_work(oldinfo);
> > - kfree(ops->cursor_state.mask);
> > - kfree(ops->cursor_data);
> > - kfree(ops->cursor_src);
> > - kfree(ops->fontbuffer);
> > - kfree(oldinfo->fbcon_par);
> > - oldinfo->fbcon_par = NULL;
> > - module_put(oldinfo->fbops->owner);
> > - /*
> > - If oldinfo and newinfo are driving the same hardware,
> > - the fb_release() method of oldinfo may attempt to
> > - restore the hardware state. This will leave the
> > - newinfo in an undefined state. Thus, a call to
> > - fb_set_par() may be needed for the newinfo.
> > - */
> > - if (newinfo && newinfo->fbops->fb_set_par) {
> > - ret = newinfo->fbops->fb_set_par(newinfo);
> > + fbcon_del_cursor_work(oldinfo);
>
>
> > + kfree(ops->cursor_state.mask);
> > + kfree(ops->cursor_data);
> > + kfree(ops->cursor_src);
> > + kfree(ops->fontbuffer);
> > + kfree(oldinfo->fbcon_par);
> > + oldinfo->fbcon_par = NULL;
> These all look like candidates to stuff into fbcon_release()
> That would drop the nice symmetry but make it more consistent.
>
> I think we miss freeing ops->cursor_data in fbcon_exit(),
> but I did not follow all the code.
>
> With my ramblings considered the patch is
> Acked-by: Sam Ravnborg <sam@ravnborg.org>
>
> Sam
>
> > + /*
> > + If oldinfo and newinfo are driving the same hardware,
> > + the fb_release() method of oldinfo may attempt to
> > + restore the hardware state. This will leave the
> > + newinfo in an undefined state. Thus, a call to
> > + fb_set_par() may be needed for the newinfo.
> > + */
> > + if (newinfo && newinfo->fbops->fb_set_par) {
> > + ret = newinfo->fbops->fb_set_par(newinfo);
> >
> > - if (ret)
> > - printk(KERN_ERR "con2fb_release_oldinfo: "
> > - "detected unhandled fb_set_par error, "
> > - "error code %d\n", ret);
> > - }
> > + if (ret)
> > + printk(KERN_ERR "con2fb_release_oldinfo: "
> > + "detected unhandled fb_set_par error, "
> > + "error code %d\n", ret);
> > }
> >
> > - return err;
> > + return 0;
> > }
> >
> > static void con2fb_init_display(struct vc_data *vc, struct fb_info *info,
> > @@ -917,7 +924,6 @@ static const char *fbcon_startup(void)
> > struct fbcon_display *p = &fb_display[fg_console];
> > struct vc_data *vc = vc_cons[fg_console].d;
> > const struct font_desc *font = NULL;
> > - struct module *owner;
> > struct fb_info *info = NULL;
> > struct fbcon_ops *ops;
> > int rows, cols;
> > @@ -936,17 +942,12 @@ static const char *fbcon_startup(void)
> > if (!info)
> > return NULL;
> >
> > - owner = info->fbops->owner;
> > - if (!try_module_get(owner))
> > + if (fbcon_open(info))
> > return NULL;
> > - if (info->fbops->fb_open && info->fbops->fb_open(info, 0)) {
> > - module_put(owner);
> > - return NULL;
> > - }
> >
> > ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL);
> > if (!ops) {
> > - module_put(owner);
> > + fbcon_release(info);
> > return NULL;
> > }
> >
> > @@ -3331,10 +3332,6 @@ static void fbcon_exit(void)
> > }
> >
> > if (mapped) {
> > - if (info->fbops->fb_release)
> > - info->fbops->fb_release(info, 0);
> > - module_put(info->fbops->owner);
> > -
> > if (info->fbcon_par) {
> > struct fbcon_ops *ops = info->fbcon_par;
> >
> > @@ -3344,6 +3341,8 @@ static void fbcon_exit(void)
> > kfree(info->fbcon_par);
> > info->fbcon_par = NULL;
> > }
> > +
> > + fbcon_release(info);
> > }
> > }
> > }
> > --
> > 2.33.0
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 13/21] fbcon: move more common code into fb_open()
2022-02-04 19:35 ` [Intel-gfx] " Sam Ravnborg
(?)
@ 2022-02-08 13:53 ` Daniel Vetter
-1 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-02-08 13:53 UTC (permalink / raw)
To: Sam Ravnborg
Cc: Daniel Vetter, DRI Development, linux-fbdev, Thomas Zimmermann,
Du Cheng, Tetsuo Handa, Intel Graphics Development, LKML,
Claudio Suarez, Greg Kroah-Hartman, Daniel Vetter
On Fri, Feb 04, 2022 at 08:35:31PM +0100, Sam Ravnborg wrote:
> On Mon, Jan 31, 2022 at 10:05:44PM +0100, Daniel Vetter wrote:
> > No idea why con2fb_acquire_newinfo() initializes much less than
> > fbcon_startup(), but so be it. From a quick look most of the
> > un-initialized stuff should be fairly harmless, but who knows.
> >
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > Cc: Daniel Vetter <daniel@ffwll.ch>
> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> > Cc: Thomas Zimmermann <tzimmermann@suse.de>
> > Cc: Claudio Suarez <cssk@net-c.es>
> > Cc: Du Cheng <ducheng2@gmail.com>
> > ---
> > drivers/video/fbdev/core/fbcon.c | 74 +++++++++++++-------------------
> > 1 file changed, 31 insertions(+), 43 deletions(-)
> >
> > diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
> > index b83a5a77d8a8..5a3391ff038d 100644
> > --- a/drivers/video/fbdev/core/fbcon.c
> > +++ b/drivers/video/fbdev/core/fbcon.c
> > @@ -680,8 +680,18 @@ static int fbcon_invalid_charcount(struct fb_info *info, unsigned charcount)
> >
> > #endif /* CONFIG_MISC_TILEBLITTING */
> >
> > +static void fbcon_release(struct fb_info *info)
> > +{
> > + if (info->fbops->fb_release)
> > + info->fbops->fb_release(info, 0);
> > +
> > + module_put(info->fbops->owner);
> > +}
> > +
> > static int fbcon_open(struct fb_info *info)
> > {
> > + struct fbcon_ops *ops;
> > +
> > if (!try_module_get(info->fbops->owner))
> > return -ENODEV;
> >
> > @@ -691,19 +701,22 @@ static int fbcon_open(struct fb_info *info)
> > return -ENODEV;
> > }
> >
> > - return 0;
> > -}
> > + ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL);
> > + if (!ops) {
> > + fbcon_release(info);
> > + return -ENOMEM;
> > + }
> >
> > -static void fbcon_release(struct fb_info *info)
> > -{
> > - if (info->fbops->fb_release)
> > - info->fbops->fb_release(info, 0);
> > + INIT_DELAYED_WORK(&ops->cursor_work, fb_flashcursor);
> > + ops->info = info;
> > + info->fbcon_par = ops;
> > + ops->cur_blink_jiffies = HZ / 5;
> >
> > - module_put(info->fbops->owner);
> > + return 0;
> > }
> >
> > static int con2fb_acquire_newinfo(struct vc_data *vc, struct fb_info *info,
> > - int unit, int oldidx)
> > + int unit)
> > {
> > struct fbcon_ops *ops = NULL;
> > int err;
> > @@ -712,27 +725,10 @@ static int con2fb_acquire_newinfo(struct vc_data *vc, struct fb_info *info,
> > if (err)
> > return err;
> >
> > - if (!err) {
> > - ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL);
> > - if (!ops)
> > - err = -ENOMEM;
> > -
> > - INIT_DELAYED_WORK(&ops->cursor_work, fb_flashcursor);
> > - }
> > -
> > - if (!err) {
> > - ops->cur_blink_jiffies = HZ / 5;
> > - ops->info = info;
> > - info->fbcon_par = ops;
> > -
> > - if (vc)
> > - set_blitting_type(vc, info);
> > - }
> > + ops = info->fbcon_par;
> >
> > - if (err) {
> > - con2fb_map[unit] = oldidx;
> > - fbcon_release(info);
> > - }
> > + if (vc)
> > + set_blitting_type(vc, info);
> >
> > return err;
> > }
> > @@ -840,9 +836,11 @@ static int set_con2fb_map(int unit, int newidx, int user)
> >
> > found = search_fb_in_map(newidx);
> >
> > - con2fb_map[unit] = newidx;
> > - if (!err && !found)
> > - err = con2fb_acquire_newinfo(vc, info, unit, oldidx);
> > + if (!err && !found) {
> > + err = con2fb_acquire_newinfo(vc, info, unit);
> > + if (!err)
> > + con2fb_map[unit] = newidx;
> > + }
> This looks like an unintentional change of functionality as con2fb_map[unit] is
> only assigned when we do a con2fb_acquire_newinfo().
>
> Staring at the code I could not say it is wrong, but not nice to hide
> the change in this patch.
Nope, it's not an unintentional bugfix. The old con2fb_acquire_newinfo did
reset con2fb_map to oldidx upon failure, which I've found to be a most
bizarre calling convention. So this sorts this out.
The reason I smashed this into the same patch is that I had to remove the
fbcon_release call, and so the error handling in there looked even more
funny. But I indeed failed to explain this all in the commit message.
Ack with that explainer, or do you want me to split this out properly?
-Daniel
>
> Sam
>
>
> >
> > /*
> > * If old fb is not mapped to any of the consoles,
> > @@ -939,20 +937,10 @@ static const char *fbcon_startup(void)
> > if (fbcon_open(info))
> > return NULL;
> >
> > - ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL);
> > - if (!ops) {
> > - fbcon_release(info);
> > - return NULL;
> > - }
> > -
> > - INIT_DELAYED_WORK(&ops->cursor_work, fb_flashcursor);
> > -
> > + ops = info->fbcon_par;
> > ops->currcon = -1;
> > ops->graphics = 1;
> > ops->cur_rotate = -1;
> > - ops->cur_blink_jiffies = HZ / 5;
> > - ops->info = info;
> > - info->fbcon_par = ops;
> >
> > p->con_rotate = initial_rotation;
> > if (p->con_rotate == -1)
> > @@ -1022,7 +1010,7 @@ static void fbcon_init(struct vc_data *vc, int init)
> > return;
> >
> > if (!info->fbcon_par)
> > - con2fb_acquire_newinfo(vc, info, vc->vc_num, -1);
> > + con2fb_acquire_newinfo(vc, info, vc->vc_num);
> >
> > /* If we are not the first console on this
> > fb, copy the font from that console */
> > --
> > 2.33.0
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 13/21] fbcon: move more common code into fb_open()
@ 2022-02-08 13:53 ` Daniel Vetter
0 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-02-08 13:53 UTC (permalink / raw)
To: Sam Ravnborg
Cc: linux-fbdev, Du Cheng, Tetsuo Handa, Daniel Vetter,
Intel Graphics Development, LKML, DRI Development,
Claudio Suarez, Thomas Zimmermann, Greg Kroah-Hartman,
Daniel Vetter
On Fri, Feb 04, 2022 at 08:35:31PM +0100, Sam Ravnborg wrote:
> On Mon, Jan 31, 2022 at 10:05:44PM +0100, Daniel Vetter wrote:
> > No idea why con2fb_acquire_newinfo() initializes much less than
> > fbcon_startup(), but so be it. From a quick look most of the
> > un-initialized stuff should be fairly harmless, but who knows.
> >
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > Cc: Daniel Vetter <daniel@ffwll.ch>
> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> > Cc: Thomas Zimmermann <tzimmermann@suse.de>
> > Cc: Claudio Suarez <cssk@net-c.es>
> > Cc: Du Cheng <ducheng2@gmail.com>
> > ---
> > drivers/video/fbdev/core/fbcon.c | 74 +++++++++++++-------------------
> > 1 file changed, 31 insertions(+), 43 deletions(-)
> >
> > diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
> > index b83a5a77d8a8..5a3391ff038d 100644
> > --- a/drivers/video/fbdev/core/fbcon.c
> > +++ b/drivers/video/fbdev/core/fbcon.c
> > @@ -680,8 +680,18 @@ static int fbcon_invalid_charcount(struct fb_info *info, unsigned charcount)
> >
> > #endif /* CONFIG_MISC_TILEBLITTING */
> >
> > +static void fbcon_release(struct fb_info *info)
> > +{
> > + if (info->fbops->fb_release)
> > + info->fbops->fb_release(info, 0);
> > +
> > + module_put(info->fbops->owner);
> > +}
> > +
> > static int fbcon_open(struct fb_info *info)
> > {
> > + struct fbcon_ops *ops;
> > +
> > if (!try_module_get(info->fbops->owner))
> > return -ENODEV;
> >
> > @@ -691,19 +701,22 @@ static int fbcon_open(struct fb_info *info)
> > return -ENODEV;
> > }
> >
> > - return 0;
> > -}
> > + ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL);
> > + if (!ops) {
> > + fbcon_release(info);
> > + return -ENOMEM;
> > + }
> >
> > -static void fbcon_release(struct fb_info *info)
> > -{
> > - if (info->fbops->fb_release)
> > - info->fbops->fb_release(info, 0);
> > + INIT_DELAYED_WORK(&ops->cursor_work, fb_flashcursor);
> > + ops->info = info;
> > + info->fbcon_par = ops;
> > + ops->cur_blink_jiffies = HZ / 5;
> >
> > - module_put(info->fbops->owner);
> > + return 0;
> > }
> >
> > static int con2fb_acquire_newinfo(struct vc_data *vc, struct fb_info *info,
> > - int unit, int oldidx)
> > + int unit)
> > {
> > struct fbcon_ops *ops = NULL;
> > int err;
> > @@ -712,27 +725,10 @@ static int con2fb_acquire_newinfo(struct vc_data *vc, struct fb_info *info,
> > if (err)
> > return err;
> >
> > - if (!err) {
> > - ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL);
> > - if (!ops)
> > - err = -ENOMEM;
> > -
> > - INIT_DELAYED_WORK(&ops->cursor_work, fb_flashcursor);
> > - }
> > -
> > - if (!err) {
> > - ops->cur_blink_jiffies = HZ / 5;
> > - ops->info = info;
> > - info->fbcon_par = ops;
> > -
> > - if (vc)
> > - set_blitting_type(vc, info);
> > - }
> > + ops = info->fbcon_par;
> >
> > - if (err) {
> > - con2fb_map[unit] = oldidx;
> > - fbcon_release(info);
> > - }
> > + if (vc)
> > + set_blitting_type(vc, info);
> >
> > return err;
> > }
> > @@ -840,9 +836,11 @@ static int set_con2fb_map(int unit, int newidx, int user)
> >
> > found = search_fb_in_map(newidx);
> >
> > - con2fb_map[unit] = newidx;
> > - if (!err && !found)
> > - err = con2fb_acquire_newinfo(vc, info, unit, oldidx);
> > + if (!err && !found) {
> > + err = con2fb_acquire_newinfo(vc, info, unit);
> > + if (!err)
> > + con2fb_map[unit] = newidx;
> > + }
> This looks like an unintentional change of functionality as con2fb_map[unit] is
> only assigned when we do a con2fb_acquire_newinfo().
>
> Staring at the code I could not say it is wrong, but not nice to hide
> the change in this patch.
Nope, it's not an unintentional bugfix. The old con2fb_acquire_newinfo did
reset con2fb_map to oldidx upon failure, which I've found to be a most
bizarre calling convention. So this sorts this out.
The reason I smashed this into the same patch is that I had to remove the
fbcon_release call, and so the error handling in there looked even more
funny. But I indeed failed to explain this all in the commit message.
Ack with that explainer, or do you want me to split this out properly?
-Daniel
>
> Sam
>
>
> >
> > /*
> > * If old fb is not mapped to any of the consoles,
> > @@ -939,20 +937,10 @@ static const char *fbcon_startup(void)
> > if (fbcon_open(info))
> > return NULL;
> >
> > - ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL);
> > - if (!ops) {
> > - fbcon_release(info);
> > - return NULL;
> > - }
> > -
> > - INIT_DELAYED_WORK(&ops->cursor_work, fb_flashcursor);
> > -
> > + ops = info->fbcon_par;
> > ops->currcon = -1;
> > ops->graphics = 1;
> > ops->cur_rotate = -1;
> > - ops->cur_blink_jiffies = HZ / 5;
> > - ops->info = info;
> > - info->fbcon_par = ops;
> >
> > p->con_rotate = initial_rotation;
> > if (p->con_rotate == -1)
> > @@ -1022,7 +1010,7 @@ static void fbcon_init(struct vc_data *vc, int init)
> > return;
> >
> > if (!info->fbcon_par)
> > - con2fb_acquire_newinfo(vc, info, vc->vc_num, -1);
> > + con2fb_acquire_newinfo(vc, info, vc->vc_num);
> >
> > /* If we are not the first console on this
> > fb, copy the font from that console */
> > --
> > 2.33.0
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [Intel-gfx] [PATCH 13/21] fbcon: move more common code into fb_open()
@ 2022-02-08 13:53 ` Daniel Vetter
0 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-02-08 13:53 UTC (permalink / raw)
To: Sam Ravnborg
Cc: linux-fbdev, Du Cheng, Tetsuo Handa, Daniel Vetter,
Intel Graphics Development, LKML, DRI Development,
Thomas Zimmermann, Greg Kroah-Hartman, Daniel Vetter
On Fri, Feb 04, 2022 at 08:35:31PM +0100, Sam Ravnborg wrote:
> On Mon, Jan 31, 2022 at 10:05:44PM +0100, Daniel Vetter wrote:
> > No idea why con2fb_acquire_newinfo() initializes much less than
> > fbcon_startup(), but so be it. From a quick look most of the
> > un-initialized stuff should be fairly harmless, but who knows.
> >
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > Cc: Daniel Vetter <daniel@ffwll.ch>
> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> > Cc: Thomas Zimmermann <tzimmermann@suse.de>
> > Cc: Claudio Suarez <cssk@net-c.es>
> > Cc: Du Cheng <ducheng2@gmail.com>
> > ---
> > drivers/video/fbdev/core/fbcon.c | 74 +++++++++++++-------------------
> > 1 file changed, 31 insertions(+), 43 deletions(-)
> >
> > diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
> > index b83a5a77d8a8..5a3391ff038d 100644
> > --- a/drivers/video/fbdev/core/fbcon.c
> > +++ b/drivers/video/fbdev/core/fbcon.c
> > @@ -680,8 +680,18 @@ static int fbcon_invalid_charcount(struct fb_info *info, unsigned charcount)
> >
> > #endif /* CONFIG_MISC_TILEBLITTING */
> >
> > +static void fbcon_release(struct fb_info *info)
> > +{
> > + if (info->fbops->fb_release)
> > + info->fbops->fb_release(info, 0);
> > +
> > + module_put(info->fbops->owner);
> > +}
> > +
> > static int fbcon_open(struct fb_info *info)
> > {
> > + struct fbcon_ops *ops;
> > +
> > if (!try_module_get(info->fbops->owner))
> > return -ENODEV;
> >
> > @@ -691,19 +701,22 @@ static int fbcon_open(struct fb_info *info)
> > return -ENODEV;
> > }
> >
> > - return 0;
> > -}
> > + ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL);
> > + if (!ops) {
> > + fbcon_release(info);
> > + return -ENOMEM;
> > + }
> >
> > -static void fbcon_release(struct fb_info *info)
> > -{
> > - if (info->fbops->fb_release)
> > - info->fbops->fb_release(info, 0);
> > + INIT_DELAYED_WORK(&ops->cursor_work, fb_flashcursor);
> > + ops->info = info;
> > + info->fbcon_par = ops;
> > + ops->cur_blink_jiffies = HZ / 5;
> >
> > - module_put(info->fbops->owner);
> > + return 0;
> > }
> >
> > static int con2fb_acquire_newinfo(struct vc_data *vc, struct fb_info *info,
> > - int unit, int oldidx)
> > + int unit)
> > {
> > struct fbcon_ops *ops = NULL;
> > int err;
> > @@ -712,27 +725,10 @@ static int con2fb_acquire_newinfo(struct vc_data *vc, struct fb_info *info,
> > if (err)
> > return err;
> >
> > - if (!err) {
> > - ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL);
> > - if (!ops)
> > - err = -ENOMEM;
> > -
> > - INIT_DELAYED_WORK(&ops->cursor_work, fb_flashcursor);
> > - }
> > -
> > - if (!err) {
> > - ops->cur_blink_jiffies = HZ / 5;
> > - ops->info = info;
> > - info->fbcon_par = ops;
> > -
> > - if (vc)
> > - set_blitting_type(vc, info);
> > - }
> > + ops = info->fbcon_par;
> >
> > - if (err) {
> > - con2fb_map[unit] = oldidx;
> > - fbcon_release(info);
> > - }
> > + if (vc)
> > + set_blitting_type(vc, info);
> >
> > return err;
> > }
> > @@ -840,9 +836,11 @@ static int set_con2fb_map(int unit, int newidx, int user)
> >
> > found = search_fb_in_map(newidx);
> >
> > - con2fb_map[unit] = newidx;
> > - if (!err && !found)
> > - err = con2fb_acquire_newinfo(vc, info, unit, oldidx);
> > + if (!err && !found) {
> > + err = con2fb_acquire_newinfo(vc, info, unit);
> > + if (!err)
> > + con2fb_map[unit] = newidx;
> > + }
> This looks like an unintentional change of functionality as con2fb_map[unit] is
> only assigned when we do a con2fb_acquire_newinfo().
>
> Staring at the code I could not say it is wrong, but not nice to hide
> the change in this patch.
Nope, it's not an unintentional bugfix. The old con2fb_acquire_newinfo did
reset con2fb_map to oldidx upon failure, which I've found to be a most
bizarre calling convention. So this sorts this out.
The reason I smashed this into the same patch is that I had to remove the
fbcon_release call, and so the error handling in there looked even more
funny. But I indeed failed to explain this all in the commit message.
Ack with that explainer, or do you want me to split this out properly?
-Daniel
>
> Sam
>
>
> >
> > /*
> > * If old fb is not mapped to any of the consoles,
> > @@ -939,20 +937,10 @@ static const char *fbcon_startup(void)
> > if (fbcon_open(info))
> > return NULL;
> >
> > - ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL);
> > - if (!ops) {
> > - fbcon_release(info);
> > - return NULL;
> > - }
> > -
> > - INIT_DELAYED_WORK(&ops->cursor_work, fb_flashcursor);
> > -
> > + ops = info->fbcon_par;
> > ops->currcon = -1;
> > ops->graphics = 1;
> > ops->cur_rotate = -1;
> > - ops->cur_blink_jiffies = HZ / 5;
> > - ops->info = info;
> > - info->fbcon_par = ops;
> >
> > p->con_rotate = initial_rotation;
> > if (p->con_rotate == -1)
> > @@ -1022,7 +1010,7 @@ static void fbcon_init(struct vc_data *vc, int init)
> > return;
> >
> > if (!info->fbcon_par)
> > - con2fb_acquire_newinfo(vc, info, vc->vc_num, -1);
> > + con2fb_acquire_newinfo(vc, info, vc->vc_num);
> >
> > /* If we are not the first console on this
> > fb, copy the font from that console */
> > --
> > 2.33.0
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 16/21] fbcon: Move console_lock for register/unlink/unregister
2022-02-04 19:54 ` [Intel-gfx] " Sam Ravnborg
(?)
@ 2022-02-08 13:56 ` Daniel Vetter
-1 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-02-08 13:56 UTC (permalink / raw)
To: Sam Ravnborg
Cc: Daniel Vetter, DRI Development, linux-fbdev, Thomas Zimmermann,
Xiyu Yang, Du Cheng, Tetsuo Handa, Intel Graphics Development,
Zheyu Ma, LKML, Matthew Wilcox, Claudio Suarez,
Greg Kroah-Hartman, Alex Deucher, Daniel Vetter, Zhen Lei,
Guenter Roeck
On Fri, Feb 04, 2022 at 08:54:24PM +0100, Sam Ravnborg wrote:
> Hi Daniel.
>
> On Mon, Jan 31, 2022 at 10:05:47PM +0100, Daniel Vetter wrote:
> > Ideally console_lock becomes an implementation detail of fbcon.c and
> > doesn't show up anywhere in fbmem.c. We're still pretty far from that,
> > but at least the register/unregister code is there now.
> >
> > With this the do_fb_ioctl() handler is the only code in fbmem.c still
> > calling console_lock().
> >
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > Cc: Daniel Vetter <daniel@ffwll.ch>
> > Cc: Thomas Zimmermann <tzimmermann@suse.de>
> > Cc: Du Cheng <ducheng2@gmail.com>
> > Cc: Claudio Suarez <cssk@net-c.es>
> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> > Cc: Matthew Wilcox <willy@infradead.org>
> > Cc: Sam Ravnborg <sam@ravnborg.org>
> > Cc: Zheyu Ma <zheyuma97@gmail.com>
> > Cc: Guenter Roeck <linux@roeck-us.net>
> > Cc: Alex Deucher <alexander.deucher@amd.com>
> > Cc: Zhen Lei <thunder.leizhen@huawei.com>
> > Cc: Xiyu Yang <xiyuyang19@fudan.edu.cn>
>
> Like how lock_console is now almost local to fbcon.
> Except the usage outside fbmem + fbcon taht is.
Yeah that's the goal. The problem is that moving console_lock for the
remaining fb_pan and fb_set_var calls will mean we need to put
lock_fbinfo() calls into fbcon.c, and right now that's just not
impossible. The FIXME update at the end of the series tries to explain
this a bit more.
-Daniel
>
> Acked-by: Sam Ravnborg <sam@ravnborg.org>
>
> > ---
> > drivers/video/fbdev/core/fbcon.c | 33 ++++++++++++++++++++++++++------
> > drivers/video/fbdev/core/fbmem.c | 23 ++--------------------
> > 2 files changed, 29 insertions(+), 27 deletions(-)
> >
> > diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
> > index 11b9f962af6f..e5e8aaf6f60d 100644
> > --- a/drivers/video/fbdev/core/fbcon.c
> > +++ b/drivers/video/fbdev/core/fbcon.c
> > @@ -2776,10 +2776,12 @@ void fbcon_fb_unbind(struct fb_info *info)
> > int i, new_idx = -1;
> > int idx = info->node;
> >
> > - WARN_CONSOLE_UNLOCKED();
> > + console_lock();
> >
> > - if (!fbcon_has_console_bind)
> > + if (!fbcon_has_console_bind) {
> > + console_unlock();
> > return;
> > + }
> >
> > for (i = first_fb_vc; i <= last_fb_vc; i++) {
> > if (con2fb_map[i] != idx &&
> > @@ -2814,6 +2816,8 @@ void fbcon_fb_unbind(struct fb_info *info)
> > }
> > fbcon_unbind();
> > }
> > +
> > + console_unlock();
> > }
> >
> > /* called with console_lock held */
> > @@ -2821,10 +2825,12 @@ void fbcon_fb_unregistered(struct fb_info *info)
> > {
> > int i, idx;
> >
> > - WARN_CONSOLE_UNLOCKED();
> > + console_lock();
> >
> > - if (deferred_takeover)
> > + if (deferred_takeover) {
> > + console_unlock();
> > return;
> > + }
> >
> > idx = info->node;
> > for (i = first_fb_vc; i <= last_fb_vc; i++) {
> > @@ -2853,6 +2859,7 @@ void fbcon_fb_unregistered(struct fb_info *info)
> >
> > if (!num_registered_fb)
> > do_unregister_con_driver(&fb_con);
> > + console_unlock();
> > }
> >
> > void fbcon_remap_all(struct fb_info *info)
> > @@ -2910,19 +2917,27 @@ static inline void fbcon_select_primary(struct fb_info *info)
> > }
> > #endif /* CONFIG_FRAMEBUFFER_DETECT_PRIMARY */
> >
> > +static bool lockless_register_fb;
> > +module_param_named_unsafe(lockless_register_fb, lockless_register_fb, bool, 0400);
> > +MODULE_PARM_DESC(lockless_register_fb,
> > + "Lockless framebuffer registration for debugging [default=off]");
> > +
> > /* called with console_lock held */
> > int fbcon_fb_registered(struct fb_info *info)
> > {
> > int ret = 0, i, idx;
> >
> > - WARN_CONSOLE_UNLOCKED();
> > + if (!lockless_register_fb)
> > + console_lock();
> > + else
> > + atomic_inc(&ignore_console_lock_warning);
> >
> > idx = info->node;
> > fbcon_select_primary(info);
> >
> > if (deferred_takeover) {
> > pr_info("fbcon: Deferring console take-over\n");
> > - return 0;
> > + goto out;
> > }
> >
> > if (info_idx == -1) {
> > @@ -2942,6 +2957,12 @@ int fbcon_fb_registered(struct fb_info *info)
> > }
> > }
> >
> > +out:
> > + if (!lockless_register_fb)
> > + console_unlock();
> > + else
> > + atomic_dec(&ignore_console_lock_warning);
> > +
> > return ret;
> > }
> >
> > diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
> > index fd51d12f2702..904ef1250677 100644
> > --- a/drivers/video/fbdev/core/fbmem.c
> > +++ b/drivers/video/fbdev/core/fbmem.c
> > @@ -1573,14 +1573,9 @@ static void do_remove_conflicting_framebuffers(struct apertures_struct *a,
> > }
> > }
> >
> > -static bool lockless_register_fb;
> > -module_param_named_unsafe(lockless_register_fb, lockless_register_fb, bool, 0400);
> > -MODULE_PARM_DESC(lockless_register_fb,
> > - "Lockless framebuffer registration for debugging [default=off]");
> > -
> > static int do_register_framebuffer(struct fb_info *fb_info)
> > {
> > - int i, ret;
> > + int i;
> > struct fb_videomode mode;
> >
> > if (fb_check_foreignness(fb_info))
> > @@ -1649,17 +1644,7 @@ static int do_register_framebuffer(struct fb_info *fb_info)
> > }
> > #endif
> >
> > - if (!lockless_register_fb)
> > - console_lock();
> > - else
> > - atomic_inc(&ignore_console_lock_warning);
> > - ret = fbcon_fb_registered(fb_info);
> > -
> > - if (!lockless_register_fb)
> > - console_unlock();
> > - else
> > - atomic_dec(&ignore_console_lock_warning);
> > - return ret;
> > + return fbcon_fb_registered(fb_info);
> > }
> >
> > static void unbind_console(struct fb_info *fb_info)
> > @@ -1669,9 +1654,7 @@ static void unbind_console(struct fb_info *fb_info)
> > if (WARN_ON(i < 0 || i >= FB_MAX || registered_fb[i] != fb_info))
> > return;
> >
> > - console_lock();
> > fbcon_fb_unbind(fb_info);
> > - console_unlock();
> > }
> >
> > static void unlink_framebuffer(struct fb_info *fb_info)
> > @@ -1714,9 +1697,7 @@ static void do_unregister_framebuffer(struct fb_info *fb_info)
> > fb_notifier_call_chain(FB_EVENT_FB_UNREGISTERED, &event);
> > }
> > #endif
> > - console_lock();
> > fbcon_fb_unregistered(fb_info);
> > - console_unlock();
> >
> > /* this may free fb info */
> > put_fb_info(fb_info);
> > --
> > 2.33.0
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 16/21] fbcon: Move console_lock for register/unlink/unregister
@ 2022-02-08 13:56 ` Daniel Vetter
0 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-02-08 13:56 UTC (permalink / raw)
To: Sam Ravnborg
Cc: linux-fbdev, Xiyu Yang, Du Cheng, Tetsuo Handa, Daniel Vetter,
Intel Graphics Development, Zheyu Ma, LKML, DRI Development,
Claudio Suarez, Matthew Wilcox, Thomas Zimmermann,
Greg Kroah-Hartman, Alex Deucher, Daniel Vetter, Zhen Lei,
Guenter Roeck
On Fri, Feb 04, 2022 at 08:54:24PM +0100, Sam Ravnborg wrote:
> Hi Daniel.
>
> On Mon, Jan 31, 2022 at 10:05:47PM +0100, Daniel Vetter wrote:
> > Ideally console_lock becomes an implementation detail of fbcon.c and
> > doesn't show up anywhere in fbmem.c. We're still pretty far from that,
> > but at least the register/unregister code is there now.
> >
> > With this the do_fb_ioctl() handler is the only code in fbmem.c still
> > calling console_lock().
> >
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > Cc: Daniel Vetter <daniel@ffwll.ch>
> > Cc: Thomas Zimmermann <tzimmermann@suse.de>
> > Cc: Du Cheng <ducheng2@gmail.com>
> > Cc: Claudio Suarez <cssk@net-c.es>
> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> > Cc: Matthew Wilcox <willy@infradead.org>
> > Cc: Sam Ravnborg <sam@ravnborg.org>
> > Cc: Zheyu Ma <zheyuma97@gmail.com>
> > Cc: Guenter Roeck <linux@roeck-us.net>
> > Cc: Alex Deucher <alexander.deucher@amd.com>
> > Cc: Zhen Lei <thunder.leizhen@huawei.com>
> > Cc: Xiyu Yang <xiyuyang19@fudan.edu.cn>
>
> Like how lock_console is now almost local to fbcon.
> Except the usage outside fbmem + fbcon taht is.
Yeah that's the goal. The problem is that moving console_lock for the
remaining fb_pan and fb_set_var calls will mean we need to put
lock_fbinfo() calls into fbcon.c, and right now that's just not
impossible. The FIXME update at the end of the series tries to explain
this a bit more.
-Daniel
>
> Acked-by: Sam Ravnborg <sam@ravnborg.org>
>
> > ---
> > drivers/video/fbdev/core/fbcon.c | 33 ++++++++++++++++++++++++++------
> > drivers/video/fbdev/core/fbmem.c | 23 ++--------------------
> > 2 files changed, 29 insertions(+), 27 deletions(-)
> >
> > diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
> > index 11b9f962af6f..e5e8aaf6f60d 100644
> > --- a/drivers/video/fbdev/core/fbcon.c
> > +++ b/drivers/video/fbdev/core/fbcon.c
> > @@ -2776,10 +2776,12 @@ void fbcon_fb_unbind(struct fb_info *info)
> > int i, new_idx = -1;
> > int idx = info->node;
> >
> > - WARN_CONSOLE_UNLOCKED();
> > + console_lock();
> >
> > - if (!fbcon_has_console_bind)
> > + if (!fbcon_has_console_bind) {
> > + console_unlock();
> > return;
> > + }
> >
> > for (i = first_fb_vc; i <= last_fb_vc; i++) {
> > if (con2fb_map[i] != idx &&
> > @@ -2814,6 +2816,8 @@ void fbcon_fb_unbind(struct fb_info *info)
> > }
> > fbcon_unbind();
> > }
> > +
> > + console_unlock();
> > }
> >
> > /* called with console_lock held */
> > @@ -2821,10 +2825,12 @@ void fbcon_fb_unregistered(struct fb_info *info)
> > {
> > int i, idx;
> >
> > - WARN_CONSOLE_UNLOCKED();
> > + console_lock();
> >
> > - if (deferred_takeover)
> > + if (deferred_takeover) {
> > + console_unlock();
> > return;
> > + }
> >
> > idx = info->node;
> > for (i = first_fb_vc; i <= last_fb_vc; i++) {
> > @@ -2853,6 +2859,7 @@ void fbcon_fb_unregistered(struct fb_info *info)
> >
> > if (!num_registered_fb)
> > do_unregister_con_driver(&fb_con);
> > + console_unlock();
> > }
> >
> > void fbcon_remap_all(struct fb_info *info)
> > @@ -2910,19 +2917,27 @@ static inline void fbcon_select_primary(struct fb_info *info)
> > }
> > #endif /* CONFIG_FRAMEBUFFER_DETECT_PRIMARY */
> >
> > +static bool lockless_register_fb;
> > +module_param_named_unsafe(lockless_register_fb, lockless_register_fb, bool, 0400);
> > +MODULE_PARM_DESC(lockless_register_fb,
> > + "Lockless framebuffer registration for debugging [default=off]");
> > +
> > /* called with console_lock held */
> > int fbcon_fb_registered(struct fb_info *info)
> > {
> > int ret = 0, i, idx;
> >
> > - WARN_CONSOLE_UNLOCKED();
> > + if (!lockless_register_fb)
> > + console_lock();
> > + else
> > + atomic_inc(&ignore_console_lock_warning);
> >
> > idx = info->node;
> > fbcon_select_primary(info);
> >
> > if (deferred_takeover) {
> > pr_info("fbcon: Deferring console take-over\n");
> > - return 0;
> > + goto out;
> > }
> >
> > if (info_idx == -1) {
> > @@ -2942,6 +2957,12 @@ int fbcon_fb_registered(struct fb_info *info)
> > }
> > }
> >
> > +out:
> > + if (!lockless_register_fb)
> > + console_unlock();
> > + else
> > + atomic_dec(&ignore_console_lock_warning);
> > +
> > return ret;
> > }
> >
> > diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
> > index fd51d12f2702..904ef1250677 100644
> > --- a/drivers/video/fbdev/core/fbmem.c
> > +++ b/drivers/video/fbdev/core/fbmem.c
> > @@ -1573,14 +1573,9 @@ static void do_remove_conflicting_framebuffers(struct apertures_struct *a,
> > }
> > }
> >
> > -static bool lockless_register_fb;
> > -module_param_named_unsafe(lockless_register_fb, lockless_register_fb, bool, 0400);
> > -MODULE_PARM_DESC(lockless_register_fb,
> > - "Lockless framebuffer registration for debugging [default=off]");
> > -
> > static int do_register_framebuffer(struct fb_info *fb_info)
> > {
> > - int i, ret;
> > + int i;
> > struct fb_videomode mode;
> >
> > if (fb_check_foreignness(fb_info))
> > @@ -1649,17 +1644,7 @@ static int do_register_framebuffer(struct fb_info *fb_info)
> > }
> > #endif
> >
> > - if (!lockless_register_fb)
> > - console_lock();
> > - else
> > - atomic_inc(&ignore_console_lock_warning);
> > - ret = fbcon_fb_registered(fb_info);
> > -
> > - if (!lockless_register_fb)
> > - console_unlock();
> > - else
> > - atomic_dec(&ignore_console_lock_warning);
> > - return ret;
> > + return fbcon_fb_registered(fb_info);
> > }
> >
> > static void unbind_console(struct fb_info *fb_info)
> > @@ -1669,9 +1654,7 @@ static void unbind_console(struct fb_info *fb_info)
> > if (WARN_ON(i < 0 || i >= FB_MAX || registered_fb[i] != fb_info))
> > return;
> >
> > - console_lock();
> > fbcon_fb_unbind(fb_info);
> > - console_unlock();
> > }
> >
> > static void unlink_framebuffer(struct fb_info *fb_info)
> > @@ -1714,9 +1697,7 @@ static void do_unregister_framebuffer(struct fb_info *fb_info)
> > fb_notifier_call_chain(FB_EVENT_FB_UNREGISTERED, &event);
> > }
> > #endif
> > - console_lock();
> > fbcon_fb_unregistered(fb_info);
> > - console_unlock();
> >
> > /* this may free fb info */
> > put_fb_info(fb_info);
> > --
> > 2.33.0
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [Intel-gfx] [PATCH 16/21] fbcon: Move console_lock for register/unlink/unregister
@ 2022-02-08 13:56 ` Daniel Vetter
0 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-02-08 13:56 UTC (permalink / raw)
To: Sam Ravnborg
Cc: linux-fbdev, Xiyu Yang, Du Cheng, Tetsuo Handa, Daniel Vetter,
Intel Graphics Development, Zheyu Ma, LKML, DRI Development,
Matthew Wilcox, Thomas Zimmermann, Greg Kroah-Hartman,
Alex Deucher, Daniel Vetter, Zhen Lei, Guenter Roeck
On Fri, Feb 04, 2022 at 08:54:24PM +0100, Sam Ravnborg wrote:
> Hi Daniel.
>
> On Mon, Jan 31, 2022 at 10:05:47PM +0100, Daniel Vetter wrote:
> > Ideally console_lock becomes an implementation detail of fbcon.c and
> > doesn't show up anywhere in fbmem.c. We're still pretty far from that,
> > but at least the register/unregister code is there now.
> >
> > With this the do_fb_ioctl() handler is the only code in fbmem.c still
> > calling console_lock().
> >
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > Cc: Daniel Vetter <daniel@ffwll.ch>
> > Cc: Thomas Zimmermann <tzimmermann@suse.de>
> > Cc: Du Cheng <ducheng2@gmail.com>
> > Cc: Claudio Suarez <cssk@net-c.es>
> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> > Cc: Matthew Wilcox <willy@infradead.org>
> > Cc: Sam Ravnborg <sam@ravnborg.org>
> > Cc: Zheyu Ma <zheyuma97@gmail.com>
> > Cc: Guenter Roeck <linux@roeck-us.net>
> > Cc: Alex Deucher <alexander.deucher@amd.com>
> > Cc: Zhen Lei <thunder.leizhen@huawei.com>
> > Cc: Xiyu Yang <xiyuyang19@fudan.edu.cn>
>
> Like how lock_console is now almost local to fbcon.
> Except the usage outside fbmem + fbcon taht is.
Yeah that's the goal. The problem is that moving console_lock for the
remaining fb_pan and fb_set_var calls will mean we need to put
lock_fbinfo() calls into fbcon.c, and right now that's just not
impossible. The FIXME update at the end of the series tries to explain
this a bit more.
-Daniel
>
> Acked-by: Sam Ravnborg <sam@ravnborg.org>
>
> > ---
> > drivers/video/fbdev/core/fbcon.c | 33 ++++++++++++++++++++++++++------
> > drivers/video/fbdev/core/fbmem.c | 23 ++--------------------
> > 2 files changed, 29 insertions(+), 27 deletions(-)
> >
> > diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
> > index 11b9f962af6f..e5e8aaf6f60d 100644
> > --- a/drivers/video/fbdev/core/fbcon.c
> > +++ b/drivers/video/fbdev/core/fbcon.c
> > @@ -2776,10 +2776,12 @@ void fbcon_fb_unbind(struct fb_info *info)
> > int i, new_idx = -1;
> > int idx = info->node;
> >
> > - WARN_CONSOLE_UNLOCKED();
> > + console_lock();
> >
> > - if (!fbcon_has_console_bind)
> > + if (!fbcon_has_console_bind) {
> > + console_unlock();
> > return;
> > + }
> >
> > for (i = first_fb_vc; i <= last_fb_vc; i++) {
> > if (con2fb_map[i] != idx &&
> > @@ -2814,6 +2816,8 @@ void fbcon_fb_unbind(struct fb_info *info)
> > }
> > fbcon_unbind();
> > }
> > +
> > + console_unlock();
> > }
> >
> > /* called with console_lock held */
> > @@ -2821,10 +2825,12 @@ void fbcon_fb_unregistered(struct fb_info *info)
> > {
> > int i, idx;
> >
> > - WARN_CONSOLE_UNLOCKED();
> > + console_lock();
> >
> > - if (deferred_takeover)
> > + if (deferred_takeover) {
> > + console_unlock();
> > return;
> > + }
> >
> > idx = info->node;
> > for (i = first_fb_vc; i <= last_fb_vc; i++) {
> > @@ -2853,6 +2859,7 @@ void fbcon_fb_unregistered(struct fb_info *info)
> >
> > if (!num_registered_fb)
> > do_unregister_con_driver(&fb_con);
> > + console_unlock();
> > }
> >
> > void fbcon_remap_all(struct fb_info *info)
> > @@ -2910,19 +2917,27 @@ static inline void fbcon_select_primary(struct fb_info *info)
> > }
> > #endif /* CONFIG_FRAMEBUFFER_DETECT_PRIMARY */
> >
> > +static bool lockless_register_fb;
> > +module_param_named_unsafe(lockless_register_fb, lockless_register_fb, bool, 0400);
> > +MODULE_PARM_DESC(lockless_register_fb,
> > + "Lockless framebuffer registration for debugging [default=off]");
> > +
> > /* called with console_lock held */
> > int fbcon_fb_registered(struct fb_info *info)
> > {
> > int ret = 0, i, idx;
> >
> > - WARN_CONSOLE_UNLOCKED();
> > + if (!lockless_register_fb)
> > + console_lock();
> > + else
> > + atomic_inc(&ignore_console_lock_warning);
> >
> > idx = info->node;
> > fbcon_select_primary(info);
> >
> > if (deferred_takeover) {
> > pr_info("fbcon: Deferring console take-over\n");
> > - return 0;
> > + goto out;
> > }
> >
> > if (info_idx == -1) {
> > @@ -2942,6 +2957,12 @@ int fbcon_fb_registered(struct fb_info *info)
> > }
> > }
> >
> > +out:
> > + if (!lockless_register_fb)
> > + console_unlock();
> > + else
> > + atomic_dec(&ignore_console_lock_warning);
> > +
> > return ret;
> > }
> >
> > diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
> > index fd51d12f2702..904ef1250677 100644
> > --- a/drivers/video/fbdev/core/fbmem.c
> > +++ b/drivers/video/fbdev/core/fbmem.c
> > @@ -1573,14 +1573,9 @@ static void do_remove_conflicting_framebuffers(struct apertures_struct *a,
> > }
> > }
> >
> > -static bool lockless_register_fb;
> > -module_param_named_unsafe(lockless_register_fb, lockless_register_fb, bool, 0400);
> > -MODULE_PARM_DESC(lockless_register_fb,
> > - "Lockless framebuffer registration for debugging [default=off]");
> > -
> > static int do_register_framebuffer(struct fb_info *fb_info)
> > {
> > - int i, ret;
> > + int i;
> > struct fb_videomode mode;
> >
> > if (fb_check_foreignness(fb_info))
> > @@ -1649,17 +1644,7 @@ static int do_register_framebuffer(struct fb_info *fb_info)
> > }
> > #endif
> >
> > - if (!lockless_register_fb)
> > - console_lock();
> > - else
> > - atomic_inc(&ignore_console_lock_warning);
> > - ret = fbcon_fb_registered(fb_info);
> > -
> > - if (!lockless_register_fb)
> > - console_unlock();
> > - else
> > - atomic_dec(&ignore_console_lock_warning);
> > - return ret;
> > + return fbcon_fb_registered(fb_info);
> > }
> >
> > static void unbind_console(struct fb_info *fb_info)
> > @@ -1669,9 +1654,7 @@ static void unbind_console(struct fb_info *fb_info)
> > if (WARN_ON(i < 0 || i >= FB_MAX || registered_fb[i] != fb_info))
> > return;
> >
> > - console_lock();
> > fbcon_fb_unbind(fb_info);
> > - console_unlock();
> > }
> >
> > static void unlink_framebuffer(struct fb_info *fb_info)
> > @@ -1714,9 +1697,7 @@ static void do_unregister_framebuffer(struct fb_info *fb_info)
> > fb_notifier_call_chain(FB_EVENT_FB_UNREGISTERED, &event);
> > }
> > #endif
> > - console_lock();
> > fbcon_fb_unregistered(fb_info);
> > - console_unlock();
> >
> > /* this may free fb info */
> > put_fb_info(fb_info);
> > --
> > 2.33.0
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 18/21] fbcon: untangle fbcon_exit
2022-02-04 20:06 ` [Intel-gfx] " Sam Ravnborg
(?)
@ 2022-02-08 13:58 ` Daniel Vetter
-1 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-02-08 13:58 UTC (permalink / raw)
To: Sam Ravnborg
Cc: Daniel Vetter, DRI Development, linux-fbdev, Du Cheng,
Tetsuo Handa, Intel Graphics Development, LKML, Claudio Suarez,
Greg Kroah-Hartman, Daniel Vetter
On Fri, Feb 04, 2022 at 09:06:38PM +0100, Sam Ravnborg wrote:
> Hi Daniel,
>
> On Mon, Jan 31, 2022 at 10:05:49PM +0100, Daniel Vetter wrote:
> > There's a bunch of confusions going on here:
> > - The deferred fbcon setup notifier should only be cleaned up from
> > fb_console_exit(), to be symmetric with fb_console_init()
> > - We also need to make sure we don't race with the work, which means
> > temporarily dropping the console lock (or we can deadlock)
> > - That also means no point in clearing deferred_takeover, we are
> > unloading everything anyway.
> > - Finally rename fbcon_exit to fbcon_release_all and move it, since
> > that's what's it doing when being called from consw->con_deinit
> > through fbcon_deinit.
> >
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > Cc: Daniel Vetter <daniel@ffwll.ch>
> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Cc: Claudio Suarez <cssk@net-c.es>
> > Cc: Du Cheng <ducheng2@gmail.com>
> > Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> > ---
> > drivers/video/fbdev/core/fbcon.c | 63 ++++++++++++++++----------------
> > 1 file changed, 32 insertions(+), 31 deletions(-)
> >
> > diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
> > index 5c14e24d14a1..22581952b4fd 100644
> > --- a/drivers/video/fbdev/core/fbcon.c
> > +++ b/drivers/video/fbdev/core/fbcon.c
> > @@ -185,7 +185,6 @@ static void fbcon_set_disp(struct fb_info *info, struct fb_var_screeninfo *var,
> > int unit);
> > static void fbcon_modechanged(struct fb_info *info);
> > static void fbcon_set_all_vcs(struct fb_info *info);
> > -static void fbcon_exit(void);
> >
> > static struct device *fbcon_device;
> >
> > @@ -1149,6 +1148,27 @@ static void fbcon_free_font(struct fbcon_display *p, bool freefont)
> >
> > static void set_vc_hi_font(struct vc_data *vc, bool set);
> >
> > +static void fbcon_release_all(void)
> > +{
> > + struct fb_info *info;
> > + int i, j, mapped;
> > +
> > + for_each_registered_fb(i) {
> > + mapped = 0;
> > + info = registered_fb[i];
> > +
> > + for (j = first_fb_vc; j <= last_fb_vc; j++) {
> > + if (con2fb_map[j] == i) {
> > + mapped = 1;
> > + con2fb_map[j] = -1;
> > + }
> > + }
> > +
> > + if (mapped)
> > + fbcon_release(info);
> > + }
> > +}
> > +
> > static void fbcon_deinit(struct vc_data *vc)
> > {
> > struct fbcon_display *p = &fb_display[vc->vc_num];
> > @@ -1188,7 +1208,7 @@ static void fbcon_deinit(struct vc_data *vc)
> > set_vc_hi_font(vc, false);
> >
> > if (!con_is_bound(&fb_con))
> > - fbcon_exit();
> > + fbcon_release_all();
> >
> > if (vc->vc_num == logo_shown)
> > logo_shown = FBCON_LOGO_CANSHOW;
> > @@ -3316,34 +3336,6 @@ static void fbcon_start(void)
> > #endif
> > }
> >
> > -static void fbcon_exit(void)
> > -{
> > - struct fb_info *info;
> > - int i, j, mapped;
> > -
> > -#ifdef CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER
> > - if (deferred_takeover) {
> > - dummycon_unregister_output_notifier(&fbcon_output_nb);
> > - deferred_takeover = false;
> > - }
> > -#endif
> > -
> > - for_each_registered_fb(i) {
> > - mapped = 0;
> > - info = registered_fb[i];
> > -
> > - for (j = first_fb_vc; j <= last_fb_vc; j++) {
> > - if (con2fb_map[j] == i) {
> > - mapped = 1;
> > - con2fb_map[j] = -1;
> > - }
> > - }
> > -
> > - if (mapped)
> > - fbcon_release(info);
> > - }
> > -}
> > -
> > void __init fb_console_init(void)
> > {
> > int i;
> > @@ -3383,10 +3375,19 @@ static void __exit fbcon_deinit_device(void)
> >
> > void __exit fb_console_exit(void)
> > {
> > +#ifdef CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER
> > + console_lock();
> > + if (deferred_takeover)
> > + dummycon_unregister_output_notifier(&fbcon_output_nb);
> > + console_unlock();
> > +
> > + cancel_work_sync(&fbcon_deferred_takeover_work);
> > +#endif
> > +
> > console_lock();
> > fbcon_deinit_device();
> > device_destroy(fb_class, MKDEV(0, 0));
> > - fbcon_exit();
> > +
> We loose the call to fbcon_release_all() here.
> We have part of the old fbcon_exit() above, but miss the release parts.
>
> Maybe I missed something obvious?
Ah yes that's the entire point of this change. The release_all in the
fbcon exit path was only needed when fbcon was a separate module
indepedent from core fb.ko. Which means it was possible to unload fbcon
while having fbdev drivers registered.
But since we've merged them that has become impossible, so by the time the
fb.ko module can be unloaded, there's guaranteed to be no fbdev drivers
left. And hence removing them is pointless.
Ack with that explainer added to the commit message?
-Daniel
>
> The rest looks fine.
>
> Sam
>
> > do_unregister_con_driver(&fb_con);
> > console_unlock();
> > }
> > --
> > 2.33.0
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 18/21] fbcon: untangle fbcon_exit
@ 2022-02-08 13:58 ` Daniel Vetter
0 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-02-08 13:58 UTC (permalink / raw)
To: Sam Ravnborg
Cc: linux-fbdev, Du Cheng, Tetsuo Handa, Daniel Vetter,
Intel Graphics Development, LKML, DRI Development,
Claudio Suarez, Greg Kroah-Hartman, Daniel Vetter
On Fri, Feb 04, 2022 at 09:06:38PM +0100, Sam Ravnborg wrote:
> Hi Daniel,
>
> On Mon, Jan 31, 2022 at 10:05:49PM +0100, Daniel Vetter wrote:
> > There's a bunch of confusions going on here:
> > - The deferred fbcon setup notifier should only be cleaned up from
> > fb_console_exit(), to be symmetric with fb_console_init()
> > - We also need to make sure we don't race with the work, which means
> > temporarily dropping the console lock (or we can deadlock)
> > - That also means no point in clearing deferred_takeover, we are
> > unloading everything anyway.
> > - Finally rename fbcon_exit to fbcon_release_all and move it, since
> > that's what's it doing when being called from consw->con_deinit
> > through fbcon_deinit.
> >
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > Cc: Daniel Vetter <daniel@ffwll.ch>
> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Cc: Claudio Suarez <cssk@net-c.es>
> > Cc: Du Cheng <ducheng2@gmail.com>
> > Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> > ---
> > drivers/video/fbdev/core/fbcon.c | 63 ++++++++++++++++----------------
> > 1 file changed, 32 insertions(+), 31 deletions(-)
> >
> > diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
> > index 5c14e24d14a1..22581952b4fd 100644
> > --- a/drivers/video/fbdev/core/fbcon.c
> > +++ b/drivers/video/fbdev/core/fbcon.c
> > @@ -185,7 +185,6 @@ static void fbcon_set_disp(struct fb_info *info, struct fb_var_screeninfo *var,
> > int unit);
> > static void fbcon_modechanged(struct fb_info *info);
> > static void fbcon_set_all_vcs(struct fb_info *info);
> > -static void fbcon_exit(void);
> >
> > static struct device *fbcon_device;
> >
> > @@ -1149,6 +1148,27 @@ static void fbcon_free_font(struct fbcon_display *p, bool freefont)
> >
> > static void set_vc_hi_font(struct vc_data *vc, bool set);
> >
> > +static void fbcon_release_all(void)
> > +{
> > + struct fb_info *info;
> > + int i, j, mapped;
> > +
> > + for_each_registered_fb(i) {
> > + mapped = 0;
> > + info = registered_fb[i];
> > +
> > + for (j = first_fb_vc; j <= last_fb_vc; j++) {
> > + if (con2fb_map[j] == i) {
> > + mapped = 1;
> > + con2fb_map[j] = -1;
> > + }
> > + }
> > +
> > + if (mapped)
> > + fbcon_release(info);
> > + }
> > +}
> > +
> > static void fbcon_deinit(struct vc_data *vc)
> > {
> > struct fbcon_display *p = &fb_display[vc->vc_num];
> > @@ -1188,7 +1208,7 @@ static void fbcon_deinit(struct vc_data *vc)
> > set_vc_hi_font(vc, false);
> >
> > if (!con_is_bound(&fb_con))
> > - fbcon_exit();
> > + fbcon_release_all();
> >
> > if (vc->vc_num == logo_shown)
> > logo_shown = FBCON_LOGO_CANSHOW;
> > @@ -3316,34 +3336,6 @@ static void fbcon_start(void)
> > #endif
> > }
> >
> > -static void fbcon_exit(void)
> > -{
> > - struct fb_info *info;
> > - int i, j, mapped;
> > -
> > -#ifdef CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER
> > - if (deferred_takeover) {
> > - dummycon_unregister_output_notifier(&fbcon_output_nb);
> > - deferred_takeover = false;
> > - }
> > -#endif
> > -
> > - for_each_registered_fb(i) {
> > - mapped = 0;
> > - info = registered_fb[i];
> > -
> > - for (j = first_fb_vc; j <= last_fb_vc; j++) {
> > - if (con2fb_map[j] == i) {
> > - mapped = 1;
> > - con2fb_map[j] = -1;
> > - }
> > - }
> > -
> > - if (mapped)
> > - fbcon_release(info);
> > - }
> > -}
> > -
> > void __init fb_console_init(void)
> > {
> > int i;
> > @@ -3383,10 +3375,19 @@ static void __exit fbcon_deinit_device(void)
> >
> > void __exit fb_console_exit(void)
> > {
> > +#ifdef CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER
> > + console_lock();
> > + if (deferred_takeover)
> > + dummycon_unregister_output_notifier(&fbcon_output_nb);
> > + console_unlock();
> > +
> > + cancel_work_sync(&fbcon_deferred_takeover_work);
> > +#endif
> > +
> > console_lock();
> > fbcon_deinit_device();
> > device_destroy(fb_class, MKDEV(0, 0));
> > - fbcon_exit();
> > +
> We loose the call to fbcon_release_all() here.
> We have part of the old fbcon_exit() above, but miss the release parts.
>
> Maybe I missed something obvious?
Ah yes that's the entire point of this change. The release_all in the
fbcon exit path was only needed when fbcon was a separate module
indepedent from core fb.ko. Which means it was possible to unload fbcon
while having fbdev drivers registered.
But since we've merged them that has become impossible, so by the time the
fb.ko module can be unloaded, there's guaranteed to be no fbdev drivers
left. And hence removing them is pointless.
Ack with that explainer added to the commit message?
-Daniel
>
> The rest looks fine.
>
> Sam
>
> > do_unregister_con_driver(&fb_con);
> > console_unlock();
> > }
> > --
> > 2.33.0
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [Intel-gfx] [PATCH 18/21] fbcon: untangle fbcon_exit
@ 2022-02-08 13:58 ` Daniel Vetter
0 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-02-08 13:58 UTC (permalink / raw)
To: Sam Ravnborg
Cc: linux-fbdev, Du Cheng, Tetsuo Handa, Daniel Vetter,
Intel Graphics Development, LKML, DRI Development,
Greg Kroah-Hartman, Daniel Vetter
On Fri, Feb 04, 2022 at 09:06:38PM +0100, Sam Ravnborg wrote:
> Hi Daniel,
>
> On Mon, Jan 31, 2022 at 10:05:49PM +0100, Daniel Vetter wrote:
> > There's a bunch of confusions going on here:
> > - The deferred fbcon setup notifier should only be cleaned up from
> > fb_console_exit(), to be symmetric with fb_console_init()
> > - We also need to make sure we don't race with the work, which means
> > temporarily dropping the console lock (or we can deadlock)
> > - That also means no point in clearing deferred_takeover, we are
> > unloading everything anyway.
> > - Finally rename fbcon_exit to fbcon_release_all and move it, since
> > that's what's it doing when being called from consw->con_deinit
> > through fbcon_deinit.
> >
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > Cc: Daniel Vetter <daniel@ffwll.ch>
> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Cc: Claudio Suarez <cssk@net-c.es>
> > Cc: Du Cheng <ducheng2@gmail.com>
> > Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> > ---
> > drivers/video/fbdev/core/fbcon.c | 63 ++++++++++++++++----------------
> > 1 file changed, 32 insertions(+), 31 deletions(-)
> >
> > diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
> > index 5c14e24d14a1..22581952b4fd 100644
> > --- a/drivers/video/fbdev/core/fbcon.c
> > +++ b/drivers/video/fbdev/core/fbcon.c
> > @@ -185,7 +185,6 @@ static void fbcon_set_disp(struct fb_info *info, struct fb_var_screeninfo *var,
> > int unit);
> > static void fbcon_modechanged(struct fb_info *info);
> > static void fbcon_set_all_vcs(struct fb_info *info);
> > -static void fbcon_exit(void);
> >
> > static struct device *fbcon_device;
> >
> > @@ -1149,6 +1148,27 @@ static void fbcon_free_font(struct fbcon_display *p, bool freefont)
> >
> > static void set_vc_hi_font(struct vc_data *vc, bool set);
> >
> > +static void fbcon_release_all(void)
> > +{
> > + struct fb_info *info;
> > + int i, j, mapped;
> > +
> > + for_each_registered_fb(i) {
> > + mapped = 0;
> > + info = registered_fb[i];
> > +
> > + for (j = first_fb_vc; j <= last_fb_vc; j++) {
> > + if (con2fb_map[j] == i) {
> > + mapped = 1;
> > + con2fb_map[j] = -1;
> > + }
> > + }
> > +
> > + if (mapped)
> > + fbcon_release(info);
> > + }
> > +}
> > +
> > static void fbcon_deinit(struct vc_data *vc)
> > {
> > struct fbcon_display *p = &fb_display[vc->vc_num];
> > @@ -1188,7 +1208,7 @@ static void fbcon_deinit(struct vc_data *vc)
> > set_vc_hi_font(vc, false);
> >
> > if (!con_is_bound(&fb_con))
> > - fbcon_exit();
> > + fbcon_release_all();
> >
> > if (vc->vc_num == logo_shown)
> > logo_shown = FBCON_LOGO_CANSHOW;
> > @@ -3316,34 +3336,6 @@ static void fbcon_start(void)
> > #endif
> > }
> >
> > -static void fbcon_exit(void)
> > -{
> > - struct fb_info *info;
> > - int i, j, mapped;
> > -
> > -#ifdef CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER
> > - if (deferred_takeover) {
> > - dummycon_unregister_output_notifier(&fbcon_output_nb);
> > - deferred_takeover = false;
> > - }
> > -#endif
> > -
> > - for_each_registered_fb(i) {
> > - mapped = 0;
> > - info = registered_fb[i];
> > -
> > - for (j = first_fb_vc; j <= last_fb_vc; j++) {
> > - if (con2fb_map[j] == i) {
> > - mapped = 1;
> > - con2fb_map[j] = -1;
> > - }
> > - }
> > -
> > - if (mapped)
> > - fbcon_release(info);
> > - }
> > -}
> > -
> > void __init fb_console_init(void)
> > {
> > int i;
> > @@ -3383,10 +3375,19 @@ static void __exit fbcon_deinit_device(void)
> >
> > void __exit fb_console_exit(void)
> > {
> > +#ifdef CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER
> > + console_lock();
> > + if (deferred_takeover)
> > + dummycon_unregister_output_notifier(&fbcon_output_nb);
> > + console_unlock();
> > +
> > + cancel_work_sync(&fbcon_deferred_takeover_work);
> > +#endif
> > +
> > console_lock();
> > fbcon_deinit_device();
> > device_destroy(fb_class, MKDEV(0, 0));
> > - fbcon_exit();
> > +
> We loose the call to fbcon_release_all() here.
> We have part of the old fbcon_exit() above, but miss the release parts.
>
> Maybe I missed something obvious?
Ah yes that's the entire point of this change. The release_all in the
fbcon exit path was only needed when fbcon was a separate module
indepedent from core fb.ko. Which means it was possible to unload fbcon
while having fbdev drivers registered.
But since we've merged them that has become impossible, so by the time the
fb.ko module can be unloaded, there's guaranteed to be no fbdev drivers
left. And hence removing them is pointless.
Ack with that explainer added to the commit message?
-Daniel
>
> The rest looks fine.
>
> Sam
>
> > do_unregister_con_driver(&fb_con);
> > console_unlock();
> > }
> > --
> > 2.33.0
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 19/21] fbcon: Maintain a private array of fb_info
2022-02-04 20:15 ` [Intel-gfx] " Sam Ravnborg
(?)
@ 2022-02-08 14:03 ` Daniel Vetter
-1 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-02-08 14:03 UTC (permalink / raw)
To: Sam Ravnborg
Cc: Daniel Vetter, DRI Development, linux-fbdev, Du Cheng,
Tetsuo Handa, Intel Graphics Development, LKML, Claudio Suarez,
Greg Kroah-Hartman, Daniel Vetter
On Fri, Feb 04, 2022 at 09:15:40PM +0100, Sam Ravnborg wrote:
> Hi Daniel,
>
> On Mon, Jan 31, 2022 at 10:05:50PM +0100, Daniel Vetter wrote:
> > Accessing the one in fbmem.c without taking the right locks is a bad
> > idea. Instead maintain our own private copy, which is fully protected
> > by console_lock() (like everything else in fbcon.c). That copy is
> > serialized through fbcon_fb_registered/unregistered() calls.
>
> I fail to see why we can make a private copy of registered_fb
> just like that - are they not somehow shared between fbcon and fbmem.
> So when fbmem updates it, then fbcon will use the entry or such?
>
> I guess I am just ignorant of how registered_fb is used - but please
> explain.
The private copy is protected under console_lock, and hence safe to access
from fbcon.c code.
The main registered_fb array is protected by a different mutex, so we
could indeed end up with hilarious corruption because the value is
inconsistent while we try to access it (e.g. we check for !NULL, but later
on gcc decides to reload the value and now it's suddenly become NULL and
we blow up).
The two are synchronized by fbmem.c calling fbcon_register/unregister, so
aside from the different locks if there's no race going on, they will
always be identical.
Other option would be to roll out get_fb_info() to fbcon.c, but since
fbcon.c is fully protected by console_lock that would add complexity in
the code flow that we don't really need. And we'd have to wire fb_info
through all call chains, since the right way to use get_fb_info is to look
it up once and then only drop it when your callback has finished.
Since the current code just assume it's all protected by console_lock and
we never drop that during a callback this would mean major surgery and
essentially refactoring all of fbcon.c to only access the fbcon stuff
through fb_info, i.e. to get rid of _all_ the global arrays we have more
or less. I'm not volunteering for that (despite that really this would be
the right thing to do if we'd have infinite engineering time).
Ack with that explainer added to the commit message?
-Daniel
>
> Sam
>
> >
> > Also this means we do not need to hold a full fb_info reference, which
> > is nice because doing so would mean a refcount loop between the
> > console and the fb_info. But it's also not nice since it means
> > console_lock() must be held absolutely everywhere. Well strictly
> > speaking we could still try to do some refcounting games again by
> > calling get_fb_info before we drop the console_lock. But things will
> > get tricky.
> >
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > Cc: Daniel Vetter <daniel@ffwll.ch>
> > Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> > Cc: Claudio Suarez <cssk@net-c.es>
> > Cc: Du Cheng <ducheng2@gmail.com>
> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > ---
> > drivers/video/fbdev/core/fbcon.c | 82 +++++++++++++++++---------------
> > 1 file changed, 43 insertions(+), 39 deletions(-)
> >
> > diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
> > index 22581952b4fd..a0ca34b29615 100644
> > --- a/drivers/video/fbdev/core/fbcon.c
> > +++ b/drivers/video/fbdev/core/fbcon.c
> > @@ -86,10 +86,6 @@
> > * - fbcon state itself is protected by the console_lock, and the code does a
> > * pretty good job at making sure that lock is held everywhere it's needed.
> > *
> > - * - access to the registered_fb array is entirely unprotected. This should use
> > - * proper object lifetime handling, i.e. get/put_fb_info. This also means
> > - * switching from indices to proper pointers for fb_info everywhere.
> > - *
> > * - fbcon doesn't bother with fb_lock/unlock at all. This is buggy, since it
> > * means concurrent access to the same fbdev from both fbcon and userspace
> > * will blow up. To fix this all fbcon calls from fbmem.c need to be moved out
> > @@ -107,6 +103,13 @@ enum {
> >
> > static struct fbcon_display fb_display[MAX_NR_CONSOLES];
> >
> > +struct fb_info *fbcon_registered_fb[FB_MAX];
> > +int fbcon_num_registered_fb;
> > +
> > +#define fbcon_for_each_registered_fb(i) \
> > + for (i = 0; WARN_CONSOLE_UNLOCKED(), i < FB_MAX; i++) \
> > + if (!fbcon_registered_fb[i]) {} else
> > +
> > static signed char con2fb_map[MAX_NR_CONSOLES];
> > static signed char con2fb_map_boot[MAX_NR_CONSOLES];
> >
> > @@ -114,12 +117,7 @@ static struct fb_info *fbcon_info_from_console(int console)
> > {
> > WARN_CONSOLE_UNLOCKED();
> >
> > - /*
> > - * Note that only con2fb_map is protected by the console lock,
> > - * registered_fb is protected by a separate mutex. This lookup can
> > - * therefore race.
> > - */
> > - return registered_fb[con2fb_map[console]];
> > + return fbcon_registered_fb[con2fb_map[console]];
> > }
> >
> > static int logo_lines;
> > @@ -516,7 +514,7 @@ static int do_fbcon_takeover(int show_logo)
> > {
> > int err, i;
> >
> > - if (!num_registered_fb)
> > + if (!fbcon_num_registered_fb)
> > return -ENODEV;
> >
> > if (!show_logo)
> > @@ -822,7 +820,7 @@ static int set_con2fb_map(int unit, int newidx, int user)
> > {
> > struct vc_data *vc = vc_cons[unit].d;
> > int oldidx = con2fb_map[unit];
> > - struct fb_info *info = registered_fb[newidx];
> > + struct fb_info *info = fbcon_registered_fb[newidx];
> > struct fb_info *oldinfo = NULL;
> > int found, err = 0, show_logo;
> >
> > @@ -840,7 +838,7 @@ static int set_con2fb_map(int unit, int newidx, int user)
> > }
> >
> > if (oldidx != -1)
> > - oldinfo = registered_fb[oldidx];
> > + oldinfo = fbcon_registered_fb[oldidx];
> >
> > found = search_fb_in_map(newidx);
> >
> > @@ -932,13 +930,13 @@ static const char *fbcon_startup(void)
> > * If num_registered_fb is zero, this is a call for the dummy part.
> > * The frame buffer devices weren't initialized yet.
> > */
> > - if (!num_registered_fb || info_idx == -1)
> > + if (!fbcon_num_registered_fb || info_idx == -1)
> > return display_desc;
> > /*
> > * Instead of blindly using registered_fb[0], we use info_idx, set by
> > * fbcon_fb_registered();
> > */
> > - info = registered_fb[info_idx];
> > + info = fbcon_registered_fb[info_idx];
> > if (!info)
> > return NULL;
> >
> > @@ -1153,9 +1151,9 @@ static void fbcon_release_all(void)
> > struct fb_info *info;
> > int i, j, mapped;
> >
> > - for_each_registered_fb(i) {
> > + fbcon_for_each_registered_fb(i) {
> > mapped = 0;
> > - info = registered_fb[i];
> > + info = fbcon_registered_fb[i];
> >
> > for (j = first_fb_vc; j <= last_fb_vc; j++) {
> > if (con2fb_map[j] == i) {
> > @@ -1182,7 +1180,7 @@ static void fbcon_deinit(struct vc_data *vc)
> > if (idx == -1)
> > goto finished;
> >
> > - info = registered_fb[idx];
> > + info = fbcon_registered_fb[idx];
> >
> > if (!info)
> > goto finished;
> > @@ -2118,9 +2116,9 @@ static int fbcon_switch(struct vc_data *vc)
> > *
> > * info->currcon = vc->vc_num;
> > */
> > - for_each_registered_fb(i) {
> > - if (registered_fb[i]->fbcon_par) {
> > - struct fbcon_ops *o = registered_fb[i]->fbcon_par;
> > + fbcon_for_each_registered_fb(i) {
> > + if (fbcon_registered_fb[i]->fbcon_par) {
> > + struct fbcon_ops *o = fbcon_registered_fb[i]->fbcon_par;
> >
> > o->currcon = vc->vc_num;
> > }
> > @@ -2765,7 +2763,7 @@ int fbcon_mode_deleted(struct fb_info *info,
> > j = con2fb_map[i];
> > if (j == -1)
> > continue;
> > - fb_info = registered_fb[j];
> > + fb_info = fbcon_registered_fb[j];
> > if (fb_info != info)
> > continue;
> > p = &fb_display[i];
> > @@ -2821,7 +2819,7 @@ void fbcon_fb_unbind(struct fb_info *info)
> > set_con2fb_map(i, new_idx, 0);
> > }
> > } else {
> > - struct fb_info *info = registered_fb[idx];
> > + struct fb_info *info = fbcon_registered_fb[idx];
> >
> > /* This is sort of like set_con2fb_map, except it maps
> > * the consoles to no device and then releases the
> > @@ -2851,6 +2849,9 @@ void fbcon_fb_unregistered(struct fb_info *info)
> >
> > console_lock();
> >
> > + fbcon_registered_fb[info->node] = NULL;
> > + fbcon_num_registered_fb--;
> > +
> > if (deferred_takeover) {
> > console_unlock();
> > return;
> > @@ -2865,7 +2866,7 @@ void fbcon_fb_unregistered(struct fb_info *info)
> > if (idx == info_idx) {
> > info_idx = -1;
> >
> > - for_each_registered_fb(i) {
> > + fbcon_for_each_registered_fb(i) {
> > info_idx = i;
> > break;
> > }
> > @@ -2881,7 +2882,7 @@ void fbcon_fb_unregistered(struct fb_info *info)
> > if (primary_device == idx)
> > primary_device = -1;
> >
> > - if (!num_registered_fb)
> > + if (!fbcon_num_registered_fb)
> > do_unregister_con_driver(&fb_con);
> > console_unlock();
> > }
> > @@ -2956,6 +2957,9 @@ int fbcon_fb_registered(struct fb_info *info)
> > else
> > atomic_inc(&ignore_console_lock_warning);
> >
> > + fbcon_registered_fb[info->node] = info;
> > + fbcon_num_registered_fb++;
> > +
> > idx = info->node;
> > fbcon_select_primary(info);
> >
> > @@ -3075,9 +3079,9 @@ int fbcon_set_con2fb_map_ioctl(void __user *argp)
> > return -EINVAL;
> > if (con2fb.framebuffer >= FB_MAX)
> > return -EINVAL;
> > - if (!registered_fb[con2fb.framebuffer])
> > + if (!fbcon_registered_fb[con2fb.framebuffer])
> > request_module("fb%d", con2fb.framebuffer);
> > - if (!registered_fb[con2fb.framebuffer]) {
> > + if (!fbcon_registered_fb[con2fb.framebuffer]) {
> > return -EINVAL;
> > }
> >
> > @@ -3144,10 +3148,10 @@ static ssize_t store_rotate(struct device *device,
> > console_lock();
> > idx = con2fb_map[fg_console];
> >
> > - if (idx == -1 || registered_fb[idx] == NULL)
> > + if (idx == -1 || fbcon_registered_fb[idx] == NULL)
> > goto err;
> >
> > - info = registered_fb[idx];
> > + info = fbcon_registered_fb[idx];
> > rotate = simple_strtoul(buf, last, 0);
> > fbcon_rotate(info, rotate);
> > err:
> > @@ -3166,10 +3170,10 @@ static ssize_t store_rotate_all(struct device *device,
> > console_lock();
> > idx = con2fb_map[fg_console];
> >
> > - if (idx == -1 || registered_fb[idx] == NULL)
> > + if (idx == -1 || fbcon_registered_fb[idx] == NULL)
> > goto err;
> >
> > - info = registered_fb[idx];
> > + info = fbcon_registered_fb[idx];
> > rotate = simple_strtoul(buf, last, 0);
> > fbcon_rotate_all(info, rotate);
> > err:
> > @@ -3186,10 +3190,10 @@ static ssize_t show_rotate(struct device *device,
> > console_lock();
> > idx = con2fb_map[fg_console];
> >
> > - if (idx == -1 || registered_fb[idx] == NULL)
> > + if (idx == -1 || fbcon_registered_fb[idx] == NULL)
> > goto err;
> >
> > - info = registered_fb[idx];
> > + info = fbcon_registered_fb[idx];
> > rotate = fbcon_get_rotate(info);
> > err:
> > console_unlock();
> > @@ -3206,10 +3210,10 @@ static ssize_t show_cursor_blink(struct device *device,
> > console_lock();
> > idx = con2fb_map[fg_console];
> >
> > - if (idx == -1 || registered_fb[idx] == NULL)
> > + if (idx == -1 || fbcon_registered_fb[idx] == NULL)
> > goto err;
> >
> > - info = registered_fb[idx];
> > + info = fbcon_registered_fb[idx];
> > ops = info->fbcon_par;
> >
> > if (!ops)
> > @@ -3232,10 +3236,10 @@ static ssize_t store_cursor_blink(struct device *device,
> > console_lock();
> > idx = con2fb_map[fg_console];
> >
> > - if (idx == -1 || registered_fb[idx] == NULL)
> > + if (idx == -1 || fbcon_registered_fb[idx] == NULL)
> > goto err;
> >
> > - info = registered_fb[idx];
> > + info = fbcon_registered_fb[idx];
> >
> > if (!info->fbcon_par)
> > goto err;
> > @@ -3295,8 +3299,8 @@ static void fbcon_register_existing_fbs(struct work_struct *work)
> > deferred_takeover = false;
> > logo_shown = FBCON_LOGO_DONTSHOW;
> >
> > - for_each_registered_fb(i)
> > - fbcon_fb_registered(registered_fb[i]);
> > + fbcon_for_each_registered_fb(i)
> > + fbcon_fb_registered(fbcon_registered_fb[i]);
> >
> > console_unlock();
> > }
> > --
> > 2.33.0
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 19/21] fbcon: Maintain a private array of fb_info
@ 2022-02-08 14:03 ` Daniel Vetter
0 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-02-08 14:03 UTC (permalink / raw)
To: Sam Ravnborg
Cc: linux-fbdev, Du Cheng, Tetsuo Handa, Daniel Vetter,
Intel Graphics Development, LKML, DRI Development,
Claudio Suarez, Greg Kroah-Hartman, Daniel Vetter
On Fri, Feb 04, 2022 at 09:15:40PM +0100, Sam Ravnborg wrote:
> Hi Daniel,
>
> On Mon, Jan 31, 2022 at 10:05:50PM +0100, Daniel Vetter wrote:
> > Accessing the one in fbmem.c without taking the right locks is a bad
> > idea. Instead maintain our own private copy, which is fully protected
> > by console_lock() (like everything else in fbcon.c). That copy is
> > serialized through fbcon_fb_registered/unregistered() calls.
>
> I fail to see why we can make a private copy of registered_fb
> just like that - are they not somehow shared between fbcon and fbmem.
> So when fbmem updates it, then fbcon will use the entry or such?
>
> I guess I am just ignorant of how registered_fb is used - but please
> explain.
The private copy is protected under console_lock, and hence safe to access
from fbcon.c code.
The main registered_fb array is protected by a different mutex, so we
could indeed end up with hilarious corruption because the value is
inconsistent while we try to access it (e.g. we check for !NULL, but later
on gcc decides to reload the value and now it's suddenly become NULL and
we blow up).
The two are synchronized by fbmem.c calling fbcon_register/unregister, so
aside from the different locks if there's no race going on, they will
always be identical.
Other option would be to roll out get_fb_info() to fbcon.c, but since
fbcon.c is fully protected by console_lock that would add complexity in
the code flow that we don't really need. And we'd have to wire fb_info
through all call chains, since the right way to use get_fb_info is to look
it up once and then only drop it when your callback has finished.
Since the current code just assume it's all protected by console_lock and
we never drop that during a callback this would mean major surgery and
essentially refactoring all of fbcon.c to only access the fbcon stuff
through fb_info, i.e. to get rid of _all_ the global arrays we have more
or less. I'm not volunteering for that (despite that really this would be
the right thing to do if we'd have infinite engineering time).
Ack with that explainer added to the commit message?
-Daniel
>
> Sam
>
> >
> > Also this means we do not need to hold a full fb_info reference, which
> > is nice because doing so would mean a refcount loop between the
> > console and the fb_info. But it's also not nice since it means
> > console_lock() must be held absolutely everywhere. Well strictly
> > speaking we could still try to do some refcounting games again by
> > calling get_fb_info before we drop the console_lock. But things will
> > get tricky.
> >
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > Cc: Daniel Vetter <daniel@ffwll.ch>
> > Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> > Cc: Claudio Suarez <cssk@net-c.es>
> > Cc: Du Cheng <ducheng2@gmail.com>
> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > ---
> > drivers/video/fbdev/core/fbcon.c | 82 +++++++++++++++++---------------
> > 1 file changed, 43 insertions(+), 39 deletions(-)
> >
> > diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
> > index 22581952b4fd..a0ca34b29615 100644
> > --- a/drivers/video/fbdev/core/fbcon.c
> > +++ b/drivers/video/fbdev/core/fbcon.c
> > @@ -86,10 +86,6 @@
> > * - fbcon state itself is protected by the console_lock, and the code does a
> > * pretty good job at making sure that lock is held everywhere it's needed.
> > *
> > - * - access to the registered_fb array is entirely unprotected. This should use
> > - * proper object lifetime handling, i.e. get/put_fb_info. This also means
> > - * switching from indices to proper pointers for fb_info everywhere.
> > - *
> > * - fbcon doesn't bother with fb_lock/unlock at all. This is buggy, since it
> > * means concurrent access to the same fbdev from both fbcon and userspace
> > * will blow up. To fix this all fbcon calls from fbmem.c need to be moved out
> > @@ -107,6 +103,13 @@ enum {
> >
> > static struct fbcon_display fb_display[MAX_NR_CONSOLES];
> >
> > +struct fb_info *fbcon_registered_fb[FB_MAX];
> > +int fbcon_num_registered_fb;
> > +
> > +#define fbcon_for_each_registered_fb(i) \
> > + for (i = 0; WARN_CONSOLE_UNLOCKED(), i < FB_MAX; i++) \
> > + if (!fbcon_registered_fb[i]) {} else
> > +
> > static signed char con2fb_map[MAX_NR_CONSOLES];
> > static signed char con2fb_map_boot[MAX_NR_CONSOLES];
> >
> > @@ -114,12 +117,7 @@ static struct fb_info *fbcon_info_from_console(int console)
> > {
> > WARN_CONSOLE_UNLOCKED();
> >
> > - /*
> > - * Note that only con2fb_map is protected by the console lock,
> > - * registered_fb is protected by a separate mutex. This lookup can
> > - * therefore race.
> > - */
> > - return registered_fb[con2fb_map[console]];
> > + return fbcon_registered_fb[con2fb_map[console]];
> > }
> >
> > static int logo_lines;
> > @@ -516,7 +514,7 @@ static int do_fbcon_takeover(int show_logo)
> > {
> > int err, i;
> >
> > - if (!num_registered_fb)
> > + if (!fbcon_num_registered_fb)
> > return -ENODEV;
> >
> > if (!show_logo)
> > @@ -822,7 +820,7 @@ static int set_con2fb_map(int unit, int newidx, int user)
> > {
> > struct vc_data *vc = vc_cons[unit].d;
> > int oldidx = con2fb_map[unit];
> > - struct fb_info *info = registered_fb[newidx];
> > + struct fb_info *info = fbcon_registered_fb[newidx];
> > struct fb_info *oldinfo = NULL;
> > int found, err = 0, show_logo;
> >
> > @@ -840,7 +838,7 @@ static int set_con2fb_map(int unit, int newidx, int user)
> > }
> >
> > if (oldidx != -1)
> > - oldinfo = registered_fb[oldidx];
> > + oldinfo = fbcon_registered_fb[oldidx];
> >
> > found = search_fb_in_map(newidx);
> >
> > @@ -932,13 +930,13 @@ static const char *fbcon_startup(void)
> > * If num_registered_fb is zero, this is a call for the dummy part.
> > * The frame buffer devices weren't initialized yet.
> > */
> > - if (!num_registered_fb || info_idx == -1)
> > + if (!fbcon_num_registered_fb || info_idx == -1)
> > return display_desc;
> > /*
> > * Instead of blindly using registered_fb[0], we use info_idx, set by
> > * fbcon_fb_registered();
> > */
> > - info = registered_fb[info_idx];
> > + info = fbcon_registered_fb[info_idx];
> > if (!info)
> > return NULL;
> >
> > @@ -1153,9 +1151,9 @@ static void fbcon_release_all(void)
> > struct fb_info *info;
> > int i, j, mapped;
> >
> > - for_each_registered_fb(i) {
> > + fbcon_for_each_registered_fb(i) {
> > mapped = 0;
> > - info = registered_fb[i];
> > + info = fbcon_registered_fb[i];
> >
> > for (j = first_fb_vc; j <= last_fb_vc; j++) {
> > if (con2fb_map[j] == i) {
> > @@ -1182,7 +1180,7 @@ static void fbcon_deinit(struct vc_data *vc)
> > if (idx == -1)
> > goto finished;
> >
> > - info = registered_fb[idx];
> > + info = fbcon_registered_fb[idx];
> >
> > if (!info)
> > goto finished;
> > @@ -2118,9 +2116,9 @@ static int fbcon_switch(struct vc_data *vc)
> > *
> > * info->currcon = vc->vc_num;
> > */
> > - for_each_registered_fb(i) {
> > - if (registered_fb[i]->fbcon_par) {
> > - struct fbcon_ops *o = registered_fb[i]->fbcon_par;
> > + fbcon_for_each_registered_fb(i) {
> > + if (fbcon_registered_fb[i]->fbcon_par) {
> > + struct fbcon_ops *o = fbcon_registered_fb[i]->fbcon_par;
> >
> > o->currcon = vc->vc_num;
> > }
> > @@ -2765,7 +2763,7 @@ int fbcon_mode_deleted(struct fb_info *info,
> > j = con2fb_map[i];
> > if (j == -1)
> > continue;
> > - fb_info = registered_fb[j];
> > + fb_info = fbcon_registered_fb[j];
> > if (fb_info != info)
> > continue;
> > p = &fb_display[i];
> > @@ -2821,7 +2819,7 @@ void fbcon_fb_unbind(struct fb_info *info)
> > set_con2fb_map(i, new_idx, 0);
> > }
> > } else {
> > - struct fb_info *info = registered_fb[idx];
> > + struct fb_info *info = fbcon_registered_fb[idx];
> >
> > /* This is sort of like set_con2fb_map, except it maps
> > * the consoles to no device and then releases the
> > @@ -2851,6 +2849,9 @@ void fbcon_fb_unregistered(struct fb_info *info)
> >
> > console_lock();
> >
> > + fbcon_registered_fb[info->node] = NULL;
> > + fbcon_num_registered_fb--;
> > +
> > if (deferred_takeover) {
> > console_unlock();
> > return;
> > @@ -2865,7 +2866,7 @@ void fbcon_fb_unregistered(struct fb_info *info)
> > if (idx == info_idx) {
> > info_idx = -1;
> >
> > - for_each_registered_fb(i) {
> > + fbcon_for_each_registered_fb(i) {
> > info_idx = i;
> > break;
> > }
> > @@ -2881,7 +2882,7 @@ void fbcon_fb_unregistered(struct fb_info *info)
> > if (primary_device == idx)
> > primary_device = -1;
> >
> > - if (!num_registered_fb)
> > + if (!fbcon_num_registered_fb)
> > do_unregister_con_driver(&fb_con);
> > console_unlock();
> > }
> > @@ -2956,6 +2957,9 @@ int fbcon_fb_registered(struct fb_info *info)
> > else
> > atomic_inc(&ignore_console_lock_warning);
> >
> > + fbcon_registered_fb[info->node] = info;
> > + fbcon_num_registered_fb++;
> > +
> > idx = info->node;
> > fbcon_select_primary(info);
> >
> > @@ -3075,9 +3079,9 @@ int fbcon_set_con2fb_map_ioctl(void __user *argp)
> > return -EINVAL;
> > if (con2fb.framebuffer >= FB_MAX)
> > return -EINVAL;
> > - if (!registered_fb[con2fb.framebuffer])
> > + if (!fbcon_registered_fb[con2fb.framebuffer])
> > request_module("fb%d", con2fb.framebuffer);
> > - if (!registered_fb[con2fb.framebuffer]) {
> > + if (!fbcon_registered_fb[con2fb.framebuffer]) {
> > return -EINVAL;
> > }
> >
> > @@ -3144,10 +3148,10 @@ static ssize_t store_rotate(struct device *device,
> > console_lock();
> > idx = con2fb_map[fg_console];
> >
> > - if (idx == -1 || registered_fb[idx] == NULL)
> > + if (idx == -1 || fbcon_registered_fb[idx] == NULL)
> > goto err;
> >
> > - info = registered_fb[idx];
> > + info = fbcon_registered_fb[idx];
> > rotate = simple_strtoul(buf, last, 0);
> > fbcon_rotate(info, rotate);
> > err:
> > @@ -3166,10 +3170,10 @@ static ssize_t store_rotate_all(struct device *device,
> > console_lock();
> > idx = con2fb_map[fg_console];
> >
> > - if (idx == -1 || registered_fb[idx] == NULL)
> > + if (idx == -1 || fbcon_registered_fb[idx] == NULL)
> > goto err;
> >
> > - info = registered_fb[idx];
> > + info = fbcon_registered_fb[idx];
> > rotate = simple_strtoul(buf, last, 0);
> > fbcon_rotate_all(info, rotate);
> > err:
> > @@ -3186,10 +3190,10 @@ static ssize_t show_rotate(struct device *device,
> > console_lock();
> > idx = con2fb_map[fg_console];
> >
> > - if (idx == -1 || registered_fb[idx] == NULL)
> > + if (idx == -1 || fbcon_registered_fb[idx] == NULL)
> > goto err;
> >
> > - info = registered_fb[idx];
> > + info = fbcon_registered_fb[idx];
> > rotate = fbcon_get_rotate(info);
> > err:
> > console_unlock();
> > @@ -3206,10 +3210,10 @@ static ssize_t show_cursor_blink(struct device *device,
> > console_lock();
> > idx = con2fb_map[fg_console];
> >
> > - if (idx == -1 || registered_fb[idx] == NULL)
> > + if (idx == -1 || fbcon_registered_fb[idx] == NULL)
> > goto err;
> >
> > - info = registered_fb[idx];
> > + info = fbcon_registered_fb[idx];
> > ops = info->fbcon_par;
> >
> > if (!ops)
> > @@ -3232,10 +3236,10 @@ static ssize_t store_cursor_blink(struct device *device,
> > console_lock();
> > idx = con2fb_map[fg_console];
> >
> > - if (idx == -1 || registered_fb[idx] == NULL)
> > + if (idx == -1 || fbcon_registered_fb[idx] == NULL)
> > goto err;
> >
> > - info = registered_fb[idx];
> > + info = fbcon_registered_fb[idx];
> >
> > if (!info->fbcon_par)
> > goto err;
> > @@ -3295,8 +3299,8 @@ static void fbcon_register_existing_fbs(struct work_struct *work)
> > deferred_takeover = false;
> > logo_shown = FBCON_LOGO_DONTSHOW;
> >
> > - for_each_registered_fb(i)
> > - fbcon_fb_registered(registered_fb[i]);
> > + fbcon_for_each_registered_fb(i)
> > + fbcon_fb_registered(fbcon_registered_fb[i]);
> >
> > console_unlock();
> > }
> > --
> > 2.33.0
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [Intel-gfx] [PATCH 19/21] fbcon: Maintain a private array of fb_info
@ 2022-02-08 14:03 ` Daniel Vetter
0 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-02-08 14:03 UTC (permalink / raw)
To: Sam Ravnborg
Cc: linux-fbdev, Du Cheng, Tetsuo Handa, Daniel Vetter,
Intel Graphics Development, LKML, DRI Development,
Greg Kroah-Hartman, Daniel Vetter
On Fri, Feb 04, 2022 at 09:15:40PM +0100, Sam Ravnborg wrote:
> Hi Daniel,
>
> On Mon, Jan 31, 2022 at 10:05:50PM +0100, Daniel Vetter wrote:
> > Accessing the one in fbmem.c without taking the right locks is a bad
> > idea. Instead maintain our own private copy, which is fully protected
> > by console_lock() (like everything else in fbcon.c). That copy is
> > serialized through fbcon_fb_registered/unregistered() calls.
>
> I fail to see why we can make a private copy of registered_fb
> just like that - are they not somehow shared between fbcon and fbmem.
> So when fbmem updates it, then fbcon will use the entry or such?
>
> I guess I am just ignorant of how registered_fb is used - but please
> explain.
The private copy is protected under console_lock, and hence safe to access
from fbcon.c code.
The main registered_fb array is protected by a different mutex, so we
could indeed end up with hilarious corruption because the value is
inconsistent while we try to access it (e.g. we check for !NULL, but later
on gcc decides to reload the value and now it's suddenly become NULL and
we blow up).
The two are synchronized by fbmem.c calling fbcon_register/unregister, so
aside from the different locks if there's no race going on, they will
always be identical.
Other option would be to roll out get_fb_info() to fbcon.c, but since
fbcon.c is fully protected by console_lock that would add complexity in
the code flow that we don't really need. And we'd have to wire fb_info
through all call chains, since the right way to use get_fb_info is to look
it up once and then only drop it when your callback has finished.
Since the current code just assume it's all protected by console_lock and
we never drop that during a callback this would mean major surgery and
essentially refactoring all of fbcon.c to only access the fbcon stuff
through fb_info, i.e. to get rid of _all_ the global arrays we have more
or less. I'm not volunteering for that (despite that really this would be
the right thing to do if we'd have infinite engineering time).
Ack with that explainer added to the commit message?
-Daniel
>
> Sam
>
> >
> > Also this means we do not need to hold a full fb_info reference, which
> > is nice because doing so would mean a refcount loop between the
> > console and the fb_info. But it's also not nice since it means
> > console_lock() must be held absolutely everywhere. Well strictly
> > speaking we could still try to do some refcounting games again by
> > calling get_fb_info before we drop the console_lock. But things will
> > get tricky.
> >
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > Cc: Daniel Vetter <daniel@ffwll.ch>
> > Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> > Cc: Claudio Suarez <cssk@net-c.es>
> > Cc: Du Cheng <ducheng2@gmail.com>
> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > ---
> > drivers/video/fbdev/core/fbcon.c | 82 +++++++++++++++++---------------
> > 1 file changed, 43 insertions(+), 39 deletions(-)
> >
> > diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
> > index 22581952b4fd..a0ca34b29615 100644
> > --- a/drivers/video/fbdev/core/fbcon.c
> > +++ b/drivers/video/fbdev/core/fbcon.c
> > @@ -86,10 +86,6 @@
> > * - fbcon state itself is protected by the console_lock, and the code does a
> > * pretty good job at making sure that lock is held everywhere it's needed.
> > *
> > - * - access to the registered_fb array is entirely unprotected. This should use
> > - * proper object lifetime handling, i.e. get/put_fb_info. This also means
> > - * switching from indices to proper pointers for fb_info everywhere.
> > - *
> > * - fbcon doesn't bother with fb_lock/unlock at all. This is buggy, since it
> > * means concurrent access to the same fbdev from both fbcon and userspace
> > * will blow up. To fix this all fbcon calls from fbmem.c need to be moved out
> > @@ -107,6 +103,13 @@ enum {
> >
> > static struct fbcon_display fb_display[MAX_NR_CONSOLES];
> >
> > +struct fb_info *fbcon_registered_fb[FB_MAX];
> > +int fbcon_num_registered_fb;
> > +
> > +#define fbcon_for_each_registered_fb(i) \
> > + for (i = 0; WARN_CONSOLE_UNLOCKED(), i < FB_MAX; i++) \
> > + if (!fbcon_registered_fb[i]) {} else
> > +
> > static signed char con2fb_map[MAX_NR_CONSOLES];
> > static signed char con2fb_map_boot[MAX_NR_CONSOLES];
> >
> > @@ -114,12 +117,7 @@ static struct fb_info *fbcon_info_from_console(int console)
> > {
> > WARN_CONSOLE_UNLOCKED();
> >
> > - /*
> > - * Note that only con2fb_map is protected by the console lock,
> > - * registered_fb is protected by a separate mutex. This lookup can
> > - * therefore race.
> > - */
> > - return registered_fb[con2fb_map[console]];
> > + return fbcon_registered_fb[con2fb_map[console]];
> > }
> >
> > static int logo_lines;
> > @@ -516,7 +514,7 @@ static int do_fbcon_takeover(int show_logo)
> > {
> > int err, i;
> >
> > - if (!num_registered_fb)
> > + if (!fbcon_num_registered_fb)
> > return -ENODEV;
> >
> > if (!show_logo)
> > @@ -822,7 +820,7 @@ static int set_con2fb_map(int unit, int newidx, int user)
> > {
> > struct vc_data *vc = vc_cons[unit].d;
> > int oldidx = con2fb_map[unit];
> > - struct fb_info *info = registered_fb[newidx];
> > + struct fb_info *info = fbcon_registered_fb[newidx];
> > struct fb_info *oldinfo = NULL;
> > int found, err = 0, show_logo;
> >
> > @@ -840,7 +838,7 @@ static int set_con2fb_map(int unit, int newidx, int user)
> > }
> >
> > if (oldidx != -1)
> > - oldinfo = registered_fb[oldidx];
> > + oldinfo = fbcon_registered_fb[oldidx];
> >
> > found = search_fb_in_map(newidx);
> >
> > @@ -932,13 +930,13 @@ static const char *fbcon_startup(void)
> > * If num_registered_fb is zero, this is a call for the dummy part.
> > * The frame buffer devices weren't initialized yet.
> > */
> > - if (!num_registered_fb || info_idx == -1)
> > + if (!fbcon_num_registered_fb || info_idx == -1)
> > return display_desc;
> > /*
> > * Instead of blindly using registered_fb[0], we use info_idx, set by
> > * fbcon_fb_registered();
> > */
> > - info = registered_fb[info_idx];
> > + info = fbcon_registered_fb[info_idx];
> > if (!info)
> > return NULL;
> >
> > @@ -1153,9 +1151,9 @@ static void fbcon_release_all(void)
> > struct fb_info *info;
> > int i, j, mapped;
> >
> > - for_each_registered_fb(i) {
> > + fbcon_for_each_registered_fb(i) {
> > mapped = 0;
> > - info = registered_fb[i];
> > + info = fbcon_registered_fb[i];
> >
> > for (j = first_fb_vc; j <= last_fb_vc; j++) {
> > if (con2fb_map[j] == i) {
> > @@ -1182,7 +1180,7 @@ static void fbcon_deinit(struct vc_data *vc)
> > if (idx == -1)
> > goto finished;
> >
> > - info = registered_fb[idx];
> > + info = fbcon_registered_fb[idx];
> >
> > if (!info)
> > goto finished;
> > @@ -2118,9 +2116,9 @@ static int fbcon_switch(struct vc_data *vc)
> > *
> > * info->currcon = vc->vc_num;
> > */
> > - for_each_registered_fb(i) {
> > - if (registered_fb[i]->fbcon_par) {
> > - struct fbcon_ops *o = registered_fb[i]->fbcon_par;
> > + fbcon_for_each_registered_fb(i) {
> > + if (fbcon_registered_fb[i]->fbcon_par) {
> > + struct fbcon_ops *o = fbcon_registered_fb[i]->fbcon_par;
> >
> > o->currcon = vc->vc_num;
> > }
> > @@ -2765,7 +2763,7 @@ int fbcon_mode_deleted(struct fb_info *info,
> > j = con2fb_map[i];
> > if (j == -1)
> > continue;
> > - fb_info = registered_fb[j];
> > + fb_info = fbcon_registered_fb[j];
> > if (fb_info != info)
> > continue;
> > p = &fb_display[i];
> > @@ -2821,7 +2819,7 @@ void fbcon_fb_unbind(struct fb_info *info)
> > set_con2fb_map(i, new_idx, 0);
> > }
> > } else {
> > - struct fb_info *info = registered_fb[idx];
> > + struct fb_info *info = fbcon_registered_fb[idx];
> >
> > /* This is sort of like set_con2fb_map, except it maps
> > * the consoles to no device and then releases the
> > @@ -2851,6 +2849,9 @@ void fbcon_fb_unregistered(struct fb_info *info)
> >
> > console_lock();
> >
> > + fbcon_registered_fb[info->node] = NULL;
> > + fbcon_num_registered_fb--;
> > +
> > if (deferred_takeover) {
> > console_unlock();
> > return;
> > @@ -2865,7 +2866,7 @@ void fbcon_fb_unregistered(struct fb_info *info)
> > if (idx == info_idx) {
> > info_idx = -1;
> >
> > - for_each_registered_fb(i) {
> > + fbcon_for_each_registered_fb(i) {
> > info_idx = i;
> > break;
> > }
> > @@ -2881,7 +2882,7 @@ void fbcon_fb_unregistered(struct fb_info *info)
> > if (primary_device == idx)
> > primary_device = -1;
> >
> > - if (!num_registered_fb)
> > + if (!fbcon_num_registered_fb)
> > do_unregister_con_driver(&fb_con);
> > console_unlock();
> > }
> > @@ -2956,6 +2957,9 @@ int fbcon_fb_registered(struct fb_info *info)
> > else
> > atomic_inc(&ignore_console_lock_warning);
> >
> > + fbcon_registered_fb[info->node] = info;
> > + fbcon_num_registered_fb++;
> > +
> > idx = info->node;
> > fbcon_select_primary(info);
> >
> > @@ -3075,9 +3079,9 @@ int fbcon_set_con2fb_map_ioctl(void __user *argp)
> > return -EINVAL;
> > if (con2fb.framebuffer >= FB_MAX)
> > return -EINVAL;
> > - if (!registered_fb[con2fb.framebuffer])
> > + if (!fbcon_registered_fb[con2fb.framebuffer])
> > request_module("fb%d", con2fb.framebuffer);
> > - if (!registered_fb[con2fb.framebuffer]) {
> > + if (!fbcon_registered_fb[con2fb.framebuffer]) {
> > return -EINVAL;
> > }
> >
> > @@ -3144,10 +3148,10 @@ static ssize_t store_rotate(struct device *device,
> > console_lock();
> > idx = con2fb_map[fg_console];
> >
> > - if (idx == -1 || registered_fb[idx] == NULL)
> > + if (idx == -1 || fbcon_registered_fb[idx] == NULL)
> > goto err;
> >
> > - info = registered_fb[idx];
> > + info = fbcon_registered_fb[idx];
> > rotate = simple_strtoul(buf, last, 0);
> > fbcon_rotate(info, rotate);
> > err:
> > @@ -3166,10 +3170,10 @@ static ssize_t store_rotate_all(struct device *device,
> > console_lock();
> > idx = con2fb_map[fg_console];
> >
> > - if (idx == -1 || registered_fb[idx] == NULL)
> > + if (idx == -1 || fbcon_registered_fb[idx] == NULL)
> > goto err;
> >
> > - info = registered_fb[idx];
> > + info = fbcon_registered_fb[idx];
> > rotate = simple_strtoul(buf, last, 0);
> > fbcon_rotate_all(info, rotate);
> > err:
> > @@ -3186,10 +3190,10 @@ static ssize_t show_rotate(struct device *device,
> > console_lock();
> > idx = con2fb_map[fg_console];
> >
> > - if (idx == -1 || registered_fb[idx] == NULL)
> > + if (idx == -1 || fbcon_registered_fb[idx] == NULL)
> > goto err;
> >
> > - info = registered_fb[idx];
> > + info = fbcon_registered_fb[idx];
> > rotate = fbcon_get_rotate(info);
> > err:
> > console_unlock();
> > @@ -3206,10 +3210,10 @@ static ssize_t show_cursor_blink(struct device *device,
> > console_lock();
> > idx = con2fb_map[fg_console];
> >
> > - if (idx == -1 || registered_fb[idx] == NULL)
> > + if (idx == -1 || fbcon_registered_fb[idx] == NULL)
> > goto err;
> >
> > - info = registered_fb[idx];
> > + info = fbcon_registered_fb[idx];
> > ops = info->fbcon_par;
> >
> > if (!ops)
> > @@ -3232,10 +3236,10 @@ static ssize_t store_cursor_blink(struct device *device,
> > console_lock();
> > idx = con2fb_map[fg_console];
> >
> > - if (idx == -1 || registered_fb[idx] == NULL)
> > + if (idx == -1 || fbcon_registered_fb[idx] == NULL)
> > goto err;
> >
> > - info = registered_fb[idx];
> > + info = fbcon_registered_fb[idx];
> >
> > if (!info->fbcon_par)
> > goto err;
> > @@ -3295,8 +3299,8 @@ static void fbcon_register_existing_fbs(struct work_struct *work)
> > deferred_takeover = false;
> > logo_shown = FBCON_LOGO_DONTSHOW;
> >
> > - for_each_registered_fb(i)
> > - fbcon_fb_registered(registered_fb[i]);
> > + fbcon_for_each_registered_fb(i)
> > + fbcon_fb_registered(fbcon_registered_fb[i]);
> >
> > console_unlock();
> > }
> > --
> > 2.33.0
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [Intel-gfx] [PATCH 21/21] fbdev: Make registered_fb[] private to fbmem.c
2022-02-04 8:30 ` Geert Uytterhoeven
(?)
@ 2022-02-08 14:04 ` Daniel Vetter
-1 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-02-08 14:04 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Linux Fbdev development list, Zheyu Ma, Guenter Roeck, Xiyu Yang,
Jens Frederich, Tetsuo Handa, Daniel Vetter,
Intel Graphics Development, linux-staging, LKML, DRI Development,
Zhen Lei, Matthew Wilcox, Greg Kroah-Hartman, Alex Deucher,
Daniel Vetter, Sam Ravnborg, Jon Nettleton, Helge Deller
On Fri, Feb 04, 2022 at 09:30:56AM +0100, Geert Uytterhoeven wrote:
> Hi Daniel,
>
> Thanks for your patch!
>
> On Tue, Feb 1, 2022 at 9:50 PM Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> > Well except when the olpc dcon fbdev driver is enabled, that thing
> > digs around in there in rather unfixable ways.
>
> Can't the actual frame buffer driver (which one?) used on olpc export
> a pointer to its fb_info?
Yeah that might be the right thing to do, I'll add that as a stagin TODO
in the next iteration.
>
> > --- a/drivers/video/fbdev/core/fbmem.c
> > +++ b/drivers/video/fbdev/core/fbmem.c
> > @@ -48,10 +48,14 @@
> > static DEFINE_MUTEX(registration_lock);
> >
> > struct fb_info *registered_fb[FB_MAX] __read_mostly;
> > -EXPORT_SYMBOL(registered_fb);
> > -
> > int num_registered_fb __read_mostly;
> > +#if IS_ENABLED(CONFIG_OLPC_DCON)
>
> CONFIG_FB_OLPC_DCON (everywhere), cfr. the build failure reported
> by the robot.
Yeah realized that too and fixed it locally.
Cheers, Daniel
>
> 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
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 21/21] fbdev: Make registered_fb[] private to fbmem.c
@ 2022-02-08 14:04 ` Daniel Vetter
0 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-02-08 14:04 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Daniel Vetter, DRI Development, Intel Graphics Development,
Linux Fbdev development list, LKML, Jens Frederich,
Jon Nettleton, Greg Kroah-Hartman, linux-staging, Daniel Vetter,
Daniel Vetter, Helge Deller, Matthew Wilcox, Sam Ravnborg,
Tetsuo Handa, Zhen Lei, Alex Deucher, Xiyu Yang, Zheyu Ma,
Guenter Roeck
On Fri, Feb 04, 2022 at 09:30:56AM +0100, Geert Uytterhoeven wrote:
> Hi Daniel,
>
> Thanks for your patch!
>
> On Tue, Feb 1, 2022 at 9:50 PM Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> > Well except when the olpc dcon fbdev driver is enabled, that thing
> > digs around in there in rather unfixable ways.
>
> Can't the actual frame buffer driver (which one?) used on olpc export
> a pointer to its fb_info?
Yeah that might be the right thing to do, I'll add that as a stagin TODO
in the next iteration.
>
> > --- a/drivers/video/fbdev/core/fbmem.c
> > +++ b/drivers/video/fbdev/core/fbmem.c
> > @@ -48,10 +48,14 @@
> > static DEFINE_MUTEX(registration_lock);
> >
> > struct fb_info *registered_fb[FB_MAX] __read_mostly;
> > -EXPORT_SYMBOL(registered_fb);
> > -
> > int num_registered_fb __read_mostly;
> > +#if IS_ENABLED(CONFIG_OLPC_DCON)
>
> CONFIG_FB_OLPC_DCON (everywhere), cfr. the build failure reported
> by the robot.
Yeah realized that too and fixed it locally.
Cheers, Daniel
>
> 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
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 21/21] fbdev: Make registered_fb[] private to fbmem.c
@ 2022-02-08 14:04 ` Daniel Vetter
0 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-02-08 14:04 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Linux Fbdev development list, Zheyu Ma, Guenter Roeck, Xiyu Yang,
Jens Frederich, Tetsuo Handa, Daniel Vetter,
Intel Graphics Development, linux-staging, LKML, DRI Development,
Zhen Lei, Matthew Wilcox, Greg Kroah-Hartman, Alex Deucher,
Daniel Vetter, Sam Ravnborg, Jon Nettleton, Helge Deller
On Fri, Feb 04, 2022 at 09:30:56AM +0100, Geert Uytterhoeven wrote:
> Hi Daniel,
>
> Thanks for your patch!
>
> On Tue, Feb 1, 2022 at 9:50 PM Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> > Well except when the olpc dcon fbdev driver is enabled, that thing
> > digs around in there in rather unfixable ways.
>
> Can't the actual frame buffer driver (which one?) used on olpc export
> a pointer to its fb_info?
Yeah that might be the right thing to do, I'll add that as a stagin TODO
in the next iteration.
>
> > --- a/drivers/video/fbdev/core/fbmem.c
> > +++ b/drivers/video/fbdev/core/fbmem.c
> > @@ -48,10 +48,14 @@
> > static DEFINE_MUTEX(registration_lock);
> >
> > struct fb_info *registered_fb[FB_MAX] __read_mostly;
> > -EXPORT_SYMBOL(registered_fb);
> > -
> > int num_registered_fb __read_mostly;
> > +#if IS_ENABLED(CONFIG_OLPC_DCON)
>
> CONFIG_FB_OLPC_DCON (everywhere), cfr. the build failure reported
> by the robot.
Yeah realized that too and fixed it locally.
Cheers, Daniel
>
> 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
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 01/21] MAINTAINERS: Add entry for fbdev core
2022-01-31 21:05 ` Daniel Vetter
(?)
@ 2022-02-08 14:12 ` Daniel Vetter
-1 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-02-08 14:12 UTC (permalink / raw)
To: DRI Development
Cc: Intel Graphics Development, linux-fbdev, LKML, Daniel Vetter,
Dave Airlie, Jani Nikula, Linus Torvalds, Pavel Machek,
Sam Ravnborg, Greg Kroah-Hartman, Javier Martinez Canillas,
Claudio Suarez, Tomi Valkeinen, Geert Uytterhoeven,
Thomas Zimmermann, Daniel Vetter, Sven Schnelle, Gerd Hoffmann
On Mon, Jan 31, 2022 at 10:05:32PM +0100, Daniel Vetter wrote:
> Ever since Tomi extracted the core code in 2014 it's been defacto me
> maintaining this, with help from others from dri-devel and sometimes
> Linus (but those are mostly merge conflicts):
>
> $ git shortlog -ns drivers/video/fbdev/core/ | head -n5
> 35 Daniel Vetter
> 23 Linus Torvalds
> 10 Hans de Goede
> 9 Dave Airlie
> 6 Peter Rosin
>
> I think ideally we'd also record that the various firmware fb drivers
> (efifb, vesafb, ...) are also maintained in drm-misc because for the
> past few years the patches have either been to fix handover issues
> with drm drivers, or caused handover issues with drm drivers. So any
> other tree just doesn't make sense. But also, there's plenty of
> outdated MAINTAINER entries for these with people and git trees that
> haven't been active in years, so maybe let's just leave them alone.
> And furthermore distros are now adopting simpledrm as the firmware fb
> driver, so hopefully the need to care about the fbdev firmware drivers
> will go down going forward.
>
> Note that drm-misc is group maintained, I expect that to continue like
> we've done before, so no new expectations that patches all go through
> my hands. That would be silly. This also means I'm happy to put any
> other volunteer's name in the M: line, but otherwise git log says I'm
> the one who's stuck with this.
>
> Cc: Dave Airlie <airlied@gmail.com>
> Cc: Jani Nikula <jani.nikula@linux.intel.com>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: Linux Fbdev development list <linux-fbdev@vger.kernel.org>
> Cc: Pavel Machek <pavel@ucw.cz>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Javier Martinez Canillas <javierm@redhat.com>
> Cc: DRI Development <dri-devel@lists.freedesktop.org>
> Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
> Cc: Claudio Suarez <cssk@net-c.es>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Cc: Geert Uytterhoeven <geert@linux-m68k.org>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Sven Schnelle <svens@stackframe.org>
> Cc: Gerd Hoffmann <kraxel@redhat.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Merged to drm-misc-fixes with all the acks added.
-Daniel
> ---
> MAINTAINERS | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index ea3e6c914384..49809eaa3096 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -7573,6 +7573,12 @@ S: Maintained
> W: http://floatingpoint.sourceforge.net/emulator/index.html
> F: arch/x86/math-emu/
>
> +FRAMEBUFFER CORE
> +M: Daniel Vetter <daniel@ffwll.ch>
> +F: drivers/video/fbdev/core/
> +S: Odd Fixes
> +T: git git://anongit.freedesktop.org/drm/drm-misc
> +
> FRAMEBUFFER LAYER
> M: Helge Deller <deller@gmx.de>
> L: linux-fbdev@vger.kernel.org
> --
> 2.33.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 01/21] MAINTAINERS: Add entry for fbdev core
@ 2022-02-08 14:12 ` Daniel Vetter
0 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-02-08 14:12 UTC (permalink / raw)
To: DRI Development
Cc: linux-fbdev, Thomas Zimmermann, Sam Ravnborg, Daniel Vetter,
Daniel Vetter, Intel Graphics Development, LKML,
Javier Martinez Canillas, Linus Torvalds, Tomi Valkeinen,
Claudio Suarez, Gerd Hoffmann, Pavel Machek, Greg Kroah-Hartman,
Geert Uytterhoeven, Sven Schnelle
On Mon, Jan 31, 2022 at 10:05:32PM +0100, Daniel Vetter wrote:
> Ever since Tomi extracted the core code in 2014 it's been defacto me
> maintaining this, with help from others from dri-devel and sometimes
> Linus (but those are mostly merge conflicts):
>
> $ git shortlog -ns drivers/video/fbdev/core/ | head -n5
> 35 Daniel Vetter
> 23 Linus Torvalds
> 10 Hans de Goede
> 9 Dave Airlie
> 6 Peter Rosin
>
> I think ideally we'd also record that the various firmware fb drivers
> (efifb, vesafb, ...) are also maintained in drm-misc because for the
> past few years the patches have either been to fix handover issues
> with drm drivers, or caused handover issues with drm drivers. So any
> other tree just doesn't make sense. But also, there's plenty of
> outdated MAINTAINER entries for these with people and git trees that
> haven't been active in years, so maybe let's just leave them alone.
> And furthermore distros are now adopting simpledrm as the firmware fb
> driver, so hopefully the need to care about the fbdev firmware drivers
> will go down going forward.
>
> Note that drm-misc is group maintained, I expect that to continue like
> we've done before, so no new expectations that patches all go through
> my hands. That would be silly. This also means I'm happy to put any
> other volunteer's name in the M: line, but otherwise git log says I'm
> the one who's stuck with this.
>
> Cc: Dave Airlie <airlied@gmail.com>
> Cc: Jani Nikula <jani.nikula@linux.intel.com>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: Linux Fbdev development list <linux-fbdev@vger.kernel.org>
> Cc: Pavel Machek <pavel@ucw.cz>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Javier Martinez Canillas <javierm@redhat.com>
> Cc: DRI Development <dri-devel@lists.freedesktop.org>
> Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
> Cc: Claudio Suarez <cssk@net-c.es>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Cc: Geert Uytterhoeven <geert@linux-m68k.org>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Sven Schnelle <svens@stackframe.org>
> Cc: Gerd Hoffmann <kraxel@redhat.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Merged to drm-misc-fixes with all the acks added.
-Daniel
> ---
> MAINTAINERS | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index ea3e6c914384..49809eaa3096 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -7573,6 +7573,12 @@ S: Maintained
> W: http://floatingpoint.sourceforge.net/emulator/index.html
> F: arch/x86/math-emu/
>
> +FRAMEBUFFER CORE
> +M: Daniel Vetter <daniel@ffwll.ch>
> +F: drivers/video/fbdev/core/
> +S: Odd Fixes
> +T: git git://anongit.freedesktop.org/drm/drm-misc
> +
> FRAMEBUFFER LAYER
> M: Helge Deller <deller@gmx.de>
> L: linux-fbdev@vger.kernel.org
> --
> 2.33.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [Intel-gfx] [PATCH 01/21] MAINTAINERS: Add entry for fbdev core
@ 2022-02-08 14:12 ` Daniel Vetter
0 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-02-08 14:12 UTC (permalink / raw)
To: DRI Development
Cc: linux-fbdev, Thomas Zimmermann, Sam Ravnborg, Daniel Vetter,
Daniel Vetter, Intel Graphics Development, LKML,
Javier Martinez Canillas, Linus Torvalds, Tomi Valkeinen,
Gerd Hoffmann, Pavel Machek, Greg Kroah-Hartman,
Geert Uytterhoeven, Dave Airlie, Sven Schnelle
On Mon, Jan 31, 2022 at 10:05:32PM +0100, Daniel Vetter wrote:
> Ever since Tomi extracted the core code in 2014 it's been defacto me
> maintaining this, with help from others from dri-devel and sometimes
> Linus (but those are mostly merge conflicts):
>
> $ git shortlog -ns drivers/video/fbdev/core/ | head -n5
> 35 Daniel Vetter
> 23 Linus Torvalds
> 10 Hans de Goede
> 9 Dave Airlie
> 6 Peter Rosin
>
> I think ideally we'd also record that the various firmware fb drivers
> (efifb, vesafb, ...) are also maintained in drm-misc because for the
> past few years the patches have either been to fix handover issues
> with drm drivers, or caused handover issues with drm drivers. So any
> other tree just doesn't make sense. But also, there's plenty of
> outdated MAINTAINER entries for these with people and git trees that
> haven't been active in years, so maybe let's just leave them alone.
> And furthermore distros are now adopting simpledrm as the firmware fb
> driver, so hopefully the need to care about the fbdev firmware drivers
> will go down going forward.
>
> Note that drm-misc is group maintained, I expect that to continue like
> we've done before, so no new expectations that patches all go through
> my hands. That would be silly. This also means I'm happy to put any
> other volunteer's name in the M: line, but otherwise git log says I'm
> the one who's stuck with this.
>
> Cc: Dave Airlie <airlied@gmail.com>
> Cc: Jani Nikula <jani.nikula@linux.intel.com>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: Linux Fbdev development list <linux-fbdev@vger.kernel.org>
> Cc: Pavel Machek <pavel@ucw.cz>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Javier Martinez Canillas <javierm@redhat.com>
> Cc: DRI Development <dri-devel@lists.freedesktop.org>
> Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
> Cc: Claudio Suarez <cssk@net-c.es>
> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
> Cc: Geert Uytterhoeven <geert@linux-m68k.org>
> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Sven Schnelle <svens@stackframe.org>
> Cc: Gerd Hoffmann <kraxel@redhat.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Merged to drm-misc-fixes with all the acks added.
-Daniel
> ---
> MAINTAINERS | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index ea3e6c914384..49809eaa3096 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -7573,6 +7573,12 @@ S: Maintained
> W: http://floatingpoint.sourceforge.net/emulator/index.html
> F: arch/x86/math-emu/
>
> +FRAMEBUFFER CORE
> +M: Daniel Vetter <daniel@ffwll.ch>
> +F: drivers/video/fbdev/core/
> +S: Odd Fixes
> +T: git git://anongit.freedesktop.org/drm/drm-misc
> +
> FRAMEBUFFER LAYER
> M: Helge Deller <deller@gmx.de>
> L: linux-fbdev@vger.kernel.org
> --
> 2.33.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 06/21] fbcon: delete delayed loading code
2022-02-08 13:42 ` Daniel Vetter
@ 2022-02-08 18:09 ` Sam Ravnborg
-1 siblings, 0 replies; 241+ messages in thread
From: Sam Ravnborg @ 2022-02-08 18:09 UTC (permalink / raw)
To: DRI Development, linux-fbdev, Du Cheng, Tetsuo Handa,
Intel Graphics Development, LKML, Claudio Suarez,
Greg Kroah-Hartman, Daniel Vetter, Helge Deller
Hi Daniel,
On Tue, Feb 08, 2022 at 02:42:25PM +0100, Daniel Vetter wrote:
> On Thu, Feb 03, 2022 at 09:45:29PM +0100, Sam Ravnborg wrote:
> > Hi Daniel,
> >
> > On Mon, Jan 31, 2022 at 10:05:37PM +0100, Daniel Vetter wrote:
> > > Before
> > >
> > > commit 6104c37094e729f3d4ce65797002112735d49cd1
> > > Author: Daniel Vetter <daniel.vetter@ffwll.ch>
> > > Date: Tue Aug 1 17:32:07 2017 +0200
> > >
> > > fbcon: Make fbcon a built-time depency for fbdev
> > >
> > > it was possible to load fbcon and fbdev drivers in any order, which
> > > means that fbcon init had to handle the case where fbdev drivers where
> > > already registered.
> > >
> > > This is no longer possible, hence delete that code.
> > >
> > > Note that the exit case is a bit more complex and will be done in a
> > > separate patch.
> > >
> > > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > > Cc: Helge Deller <deller@gmx.de>
> > > Cc: Daniel Vetter <daniel@ffwll.ch>
> > > Cc: Claudio Suarez <cssk@net-c.es>
> > > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> > > Cc: Du Cheng <ducheng2@gmail.com>
> > > ---
> > > drivers/video/fbdev/core/fbcon.c | 13 +------------
> > > 1 file changed, 1 insertion(+), 12 deletions(-)
> > >
> > > diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
> > > index 8f971de35885..814b648e8f09 100644
> > > --- a/drivers/video/fbdev/core/fbcon.c
> > > +++ b/drivers/video/fbdev/core/fbcon.c
> > > @@ -942,7 +942,7 @@ static const char *fbcon_startup(void)
> > > return display_desc;
> > > /*
> > > * Instead of blindly using registered_fb[0], we use info_idx, set by
> > > - * fb_console_init();
> > > + * fbcon_fb_registered();
> > > */
> > This comment change looks like it does not belong in this patch.
> > Also, the comment is wrong as info_idx is set in several places.
> > Like set_con2fb_map(), fbcon_remap_all(), and more.
>
> Yeah I can split this out into a separate patch, but I spotted this wrong
> comment as part of reviewing this code change here - essentially you have
> to check how fb_info for fbcon are registered and fbcon init happens to
> validate that deleting the below code is correct.
>
> Ok if I put this explainer into the commit message, or do you want me to
> split this out fully?
Keep it and add my a-b
Sam
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [Intel-gfx] [PATCH 06/21] fbcon: delete delayed loading code
@ 2022-02-08 18:09 ` Sam Ravnborg
0 siblings, 0 replies; 241+ messages in thread
From: Sam Ravnborg @ 2022-02-08 18:09 UTC (permalink / raw)
To: DRI Development, linux-fbdev, Du Cheng, Tetsuo Handa,
Intel Graphics Development, LKML, Claudio Suarez,
Greg Kroah-Hartman, Daniel Vetter, Helge Deller
Hi Daniel,
On Tue, Feb 08, 2022 at 02:42:25PM +0100, Daniel Vetter wrote:
> On Thu, Feb 03, 2022 at 09:45:29PM +0100, Sam Ravnborg wrote:
> > Hi Daniel,
> >
> > On Mon, Jan 31, 2022 at 10:05:37PM +0100, Daniel Vetter wrote:
> > > Before
> > >
> > > commit 6104c37094e729f3d4ce65797002112735d49cd1
> > > Author: Daniel Vetter <daniel.vetter@ffwll.ch>
> > > Date: Tue Aug 1 17:32:07 2017 +0200
> > >
> > > fbcon: Make fbcon a built-time depency for fbdev
> > >
> > > it was possible to load fbcon and fbdev drivers in any order, which
> > > means that fbcon init had to handle the case where fbdev drivers where
> > > already registered.
> > >
> > > This is no longer possible, hence delete that code.
> > >
> > > Note that the exit case is a bit more complex and will be done in a
> > > separate patch.
> > >
> > > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > > Cc: Helge Deller <deller@gmx.de>
> > > Cc: Daniel Vetter <daniel@ffwll.ch>
> > > Cc: Claudio Suarez <cssk@net-c.es>
> > > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> > > Cc: Du Cheng <ducheng2@gmail.com>
> > > ---
> > > drivers/video/fbdev/core/fbcon.c | 13 +------------
> > > 1 file changed, 1 insertion(+), 12 deletions(-)
> > >
> > > diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
> > > index 8f971de35885..814b648e8f09 100644
> > > --- a/drivers/video/fbdev/core/fbcon.c
> > > +++ b/drivers/video/fbdev/core/fbcon.c
> > > @@ -942,7 +942,7 @@ static const char *fbcon_startup(void)
> > > return display_desc;
> > > /*
> > > * Instead of blindly using registered_fb[0], we use info_idx, set by
> > > - * fb_console_init();
> > > + * fbcon_fb_registered();
> > > */
> > This comment change looks like it does not belong in this patch.
> > Also, the comment is wrong as info_idx is set in several places.
> > Like set_con2fb_map(), fbcon_remap_all(), and more.
>
> Yeah I can split this out into a separate patch, but I spotted this wrong
> comment as part of reviewing this code change here - essentially you have
> to check how fb_info for fbcon are registered and fbcon init happens to
> validate that deleting the below code is correct.
>
> Ok if I put this explainer into the commit message, or do you want me to
> split this out fully?
Keep it and add my a-b
Sam
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 10/21] fb: Delete fb_info->queue
2022-02-08 13:46 ` Daniel Vetter
@ 2022-02-08 18:22 ` Sam Ravnborg
-1 siblings, 0 replies; 241+ messages in thread
From: Sam Ravnborg @ 2022-02-08 18:22 UTC (permalink / raw)
To: DRI Development, linux-fbdev, Intel Graphics Development, LKML,
Daniel Vetter, Helge Deller
Hi Daniel,
On Tue, Feb 08, 2022 at 02:46:33PM +0100, Daniel Vetter wrote:
> On Thu, Feb 03, 2022 at 10:31:00PM +0100, Sam Ravnborg wrote:
> > On Mon, Jan 31, 2022 at 10:05:41PM +0100, Daniel Vetter wrote:
> > > It was only used by fbcon, and that now switched to its own,
> > > private work.
> > >
> > > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > > Cc: Helge Deller <deller@gmx.de>
> > > Cc: linux-fbdev@vger.kernel.org
> > I would merge this with the patch that drops the usage
>
> Yeah, but I like to split these out so that if this does break something,
> it's much easier to revert. In case I overlooked something somewhere.
>
> It's imo different if the cleanup is directly related to the preceeding
> prep work, but this is a generic workqueue, and the cursor logic is rather
> unrelated. And if I remember my history digging right, there were actually
> other uses of this.
So you basically say that because in the past there may have been other
users, this deserves a dedicated removal commit.
That works for me too.
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Sam
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [Intel-gfx] [PATCH 10/21] fb: Delete fb_info->queue
@ 2022-02-08 18:22 ` Sam Ravnborg
0 siblings, 0 replies; 241+ messages in thread
From: Sam Ravnborg @ 2022-02-08 18:22 UTC (permalink / raw)
To: DRI Development, linux-fbdev, Intel Graphics Development, LKML,
Daniel Vetter, Helge Deller
Hi Daniel,
On Tue, Feb 08, 2022 at 02:46:33PM +0100, Daniel Vetter wrote:
> On Thu, Feb 03, 2022 at 10:31:00PM +0100, Sam Ravnborg wrote:
> > On Mon, Jan 31, 2022 at 10:05:41PM +0100, Daniel Vetter wrote:
> > > It was only used by fbcon, and that now switched to its own,
> > > private work.
> > >
> > > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > > Cc: Helge Deller <deller@gmx.de>
> > > Cc: linux-fbdev@vger.kernel.org
> > I would merge this with the patch that drops the usage
>
> Yeah, but I like to split these out so that if this does break something,
> it's much easier to revert. In case I overlooked something somewhere.
>
> It's imo different if the cleanup is directly related to the preceeding
> prep work, but this is a generic workqueue, and the cursor logic is rather
> unrelated. And if I remember my history digging right, there were actually
> other uses of this.
So you basically say that because in the past there may have been other
users, this deserves a dedicated removal commit.
That works for me too.
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Sam
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 11/21] fbcon: Extract fbcon_open/release helpers
2022-02-08 13:48 ` Daniel Vetter
@ 2022-02-08 18:24 ` Sam Ravnborg
-1 siblings, 0 replies; 241+ messages in thread
From: Sam Ravnborg @ 2022-02-08 18:24 UTC (permalink / raw)
To: DRI Development, linux-fbdev, Du Cheng, Tetsuo Handa,
Intel Graphics Development, LKML, Claudio Suarez,
Greg Kroah-Hartman, Daniel Vetter
Hi Daniel,
On Tue, Feb 08, 2022 at 02:48:29PM +0100, Daniel Vetter wrote:
> On Thu, Feb 03, 2022 at 10:15:14PM +0100, Sam Ravnborg wrote:
> > Hi Daniel,
> >
> > On Mon, Jan 31, 2022 at 10:05:42PM +0100, Daniel Vetter wrote:
> > > There's two minor behaviour changes in here:
> > > - in error paths we now consistently call fb_ops->fb_release
> > > - fb_release really can't fail (fbmem.c ignores it too) and there's no
> > > reasonable cleanup we can do anyway.
> > >
> > > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > > Cc: Daniel Vetter <daniel@ffwll.ch>
> > > Cc: Claudio Suarez <cssk@net-c.es>
> > > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> > > Cc: Du Cheng <ducheng2@gmail.com>
> > > ---
> > > drivers/video/fbdev/core/fbcon.c | 107 +++++++++++++++----------------
> > > 1 file changed, 53 insertions(+), 54 deletions(-)
> > >
> > > diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
> > > index fa30e1909164..eea2ee14b64c 100644
> > > --- a/drivers/video/fbdev/core/fbcon.c
> > > +++ b/drivers/video/fbdev/core/fbcon.c
> > > @@ -680,19 +680,37 @@ static int fbcon_invalid_charcount(struct fb_info *info, unsigned charcount)
> > >
> > > #endif /* CONFIG_MISC_TILEBLITTING */
> > >
> > > +static int fbcon_open(struct fb_info *info)
> > > +{
> > > + if (!try_module_get(info->fbops->owner))
> > > + return -ENODEV;
> > > +
> > > + if (info->fbops->fb_open &&
> > > + info->fbops->fb_open(info, 0)) {
> > > + module_put(info->fbops->owner);
> > > + return -ENODEV;
> > > + }
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +static void fbcon_release(struct fb_info *info)
> > > +{
> > > + if (info->fbops->fb_release)
> > > + info->fbops->fb_release(info, 0);
> > > +
> > > + module_put(info->fbops->owner);
> > > +}
> > >
> > > static int con2fb_acquire_newinfo(struct vc_data *vc, struct fb_info *info,
> > > int unit, int oldidx)
> > > {
> > > struct fbcon_ops *ops = NULL;
> > > - int err = 0;
> > > -
> > > - if (!try_module_get(info->fbops->owner))
> > > - err = -ENODEV;
> > > + int err;
> > >
> > > - if (!err && info->fbops->fb_open &&
> > > - info->fbops->fb_open(info, 0))
> > > - err = -ENODEV;
> > > + err = fbcon_open(info);
> > > + if (err)
> > > + return err;
> > >
> > > if (!err) {
> > > ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL);
> > > @@ -713,7 +731,7 @@ static int con2fb_acquire_newinfo(struct vc_data *vc, struct fb_info *info,
> > >
> > > if (err) {
> > > con2fb_map[unit] = oldidx;
> > > - module_put(info->fbops->owner);
> > > + fbcon_release(info);
> > > }
> > >
> > > return err;
> > > @@ -724,45 +742,34 @@ static int con2fb_release_oldinfo(struct vc_data *vc, struct fb_info *oldinfo,
> > > int oldidx, int found)
> > > {
> > > struct fbcon_ops *ops = oldinfo->fbcon_par;
> > > - int err = 0, ret;
> > > + int ret;
> > >
> > > - if (oldinfo->fbops->fb_release &&
> > > - oldinfo->fbops->fb_release(oldinfo, 0)) {
> > > - con2fb_map[unit] = oldidx;
> > The old code assigns con2fb_map[unit] before is calls
> > newinfo->fbops->fb_release).
> > I wonder if there can be any callback to fbcon where the value
> > of con2fb_map[unit] matters?
>
> It's all protected by console_lock, so other threads cannot see the
> inconsistent state.
>
> Essentially everything in fbcon.c is protected by console_lock().
>
> Do you want me to hammer this in somewhere (maybe in the commit message),
> or good enough for your ack?
No need to spell it out more.
Add my a-b and apply it.
Sam
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [Intel-gfx] [PATCH 11/21] fbcon: Extract fbcon_open/release helpers
@ 2022-02-08 18:24 ` Sam Ravnborg
0 siblings, 0 replies; 241+ messages in thread
From: Sam Ravnborg @ 2022-02-08 18:24 UTC (permalink / raw)
To: DRI Development, linux-fbdev, Du Cheng, Tetsuo Handa,
Intel Graphics Development, LKML, Claudio Suarez,
Greg Kroah-Hartman, Daniel Vetter
Hi Daniel,
On Tue, Feb 08, 2022 at 02:48:29PM +0100, Daniel Vetter wrote:
> On Thu, Feb 03, 2022 at 10:15:14PM +0100, Sam Ravnborg wrote:
> > Hi Daniel,
> >
> > On Mon, Jan 31, 2022 at 10:05:42PM +0100, Daniel Vetter wrote:
> > > There's two minor behaviour changes in here:
> > > - in error paths we now consistently call fb_ops->fb_release
> > > - fb_release really can't fail (fbmem.c ignores it too) and there's no
> > > reasonable cleanup we can do anyway.
> > >
> > > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > > Cc: Daniel Vetter <daniel@ffwll.ch>
> > > Cc: Claudio Suarez <cssk@net-c.es>
> > > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> > > Cc: Du Cheng <ducheng2@gmail.com>
> > > ---
> > > drivers/video/fbdev/core/fbcon.c | 107 +++++++++++++++----------------
> > > 1 file changed, 53 insertions(+), 54 deletions(-)
> > >
> > > diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
> > > index fa30e1909164..eea2ee14b64c 100644
> > > --- a/drivers/video/fbdev/core/fbcon.c
> > > +++ b/drivers/video/fbdev/core/fbcon.c
> > > @@ -680,19 +680,37 @@ static int fbcon_invalid_charcount(struct fb_info *info, unsigned charcount)
> > >
> > > #endif /* CONFIG_MISC_TILEBLITTING */
> > >
> > > +static int fbcon_open(struct fb_info *info)
> > > +{
> > > + if (!try_module_get(info->fbops->owner))
> > > + return -ENODEV;
> > > +
> > > + if (info->fbops->fb_open &&
> > > + info->fbops->fb_open(info, 0)) {
> > > + module_put(info->fbops->owner);
> > > + return -ENODEV;
> > > + }
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +static void fbcon_release(struct fb_info *info)
> > > +{
> > > + if (info->fbops->fb_release)
> > > + info->fbops->fb_release(info, 0);
> > > +
> > > + module_put(info->fbops->owner);
> > > +}
> > >
> > > static int con2fb_acquire_newinfo(struct vc_data *vc, struct fb_info *info,
> > > int unit, int oldidx)
> > > {
> > > struct fbcon_ops *ops = NULL;
> > > - int err = 0;
> > > -
> > > - if (!try_module_get(info->fbops->owner))
> > > - err = -ENODEV;
> > > + int err;
> > >
> > > - if (!err && info->fbops->fb_open &&
> > > - info->fbops->fb_open(info, 0))
> > > - err = -ENODEV;
> > > + err = fbcon_open(info);
> > > + if (err)
> > > + return err;
> > >
> > > if (!err) {
> > > ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL);
> > > @@ -713,7 +731,7 @@ static int con2fb_acquire_newinfo(struct vc_data *vc, struct fb_info *info,
> > >
> > > if (err) {
> > > con2fb_map[unit] = oldidx;
> > > - module_put(info->fbops->owner);
> > > + fbcon_release(info);
> > > }
> > >
> > > return err;
> > > @@ -724,45 +742,34 @@ static int con2fb_release_oldinfo(struct vc_data *vc, struct fb_info *oldinfo,
> > > int oldidx, int found)
> > > {
> > > struct fbcon_ops *ops = oldinfo->fbcon_par;
> > > - int err = 0, ret;
> > > + int ret;
> > >
> > > - if (oldinfo->fbops->fb_release &&
> > > - oldinfo->fbops->fb_release(oldinfo, 0)) {
> > > - con2fb_map[unit] = oldidx;
> > The old code assigns con2fb_map[unit] before is calls
> > newinfo->fbops->fb_release).
> > I wonder if there can be any callback to fbcon where the value
> > of con2fb_map[unit] matters?
>
> It's all protected by console_lock, so other threads cannot see the
> inconsistent state.
>
> Essentially everything in fbcon.c is protected by console_lock().
>
> Do you want me to hammer this in somewhere (maybe in the commit message),
> or good enough for your ack?
No need to spell it out more.
Add my a-b and apply it.
Sam
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 13/21] fbcon: move more common code into fb_open()
2022-02-08 13:53 ` Daniel Vetter
@ 2022-02-08 18:25 ` Sam Ravnborg
-1 siblings, 0 replies; 241+ messages in thread
From: Sam Ravnborg @ 2022-02-08 18:25 UTC (permalink / raw)
To: DRI Development, linux-fbdev, Thomas Zimmermann, Du Cheng,
Tetsuo Handa, Intel Graphics Development, LKML, Claudio Suarez,
Greg Kroah-Hartman, Daniel Vetter
On Tue, Feb 08, 2022 at 02:53:59PM +0100, Daniel Vetter wrote:
> On Fri, Feb 04, 2022 at 08:35:31PM +0100, Sam Ravnborg wrote:
> > On Mon, Jan 31, 2022 at 10:05:44PM +0100, Daniel Vetter wrote:
> > > No idea why con2fb_acquire_newinfo() initializes much less than
> > > fbcon_startup(), but so be it. From a quick look most of the
> > > un-initialized stuff should be fairly harmless, but who knows.
> > >
> > > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > > Cc: Daniel Vetter <daniel@ffwll.ch>
> > > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> > > Cc: Thomas Zimmermann <tzimmermann@suse.de>
> > > Cc: Claudio Suarez <cssk@net-c.es>
> > > Cc: Du Cheng <ducheng2@gmail.com>
> > > ---
> > > drivers/video/fbdev/core/fbcon.c | 74 +++++++++++++-------------------
> > > 1 file changed, 31 insertions(+), 43 deletions(-)
> > >
> > > diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
> > > index b83a5a77d8a8..5a3391ff038d 100644
> > > --- a/drivers/video/fbdev/core/fbcon.c
> > > +++ b/drivers/video/fbdev/core/fbcon.c
> > > @@ -680,8 +680,18 @@ static int fbcon_invalid_charcount(struct fb_info *info, unsigned charcount)
> > >
> > > #endif /* CONFIG_MISC_TILEBLITTING */
> > >
> > > +static void fbcon_release(struct fb_info *info)
> > > +{
> > > + if (info->fbops->fb_release)
> > > + info->fbops->fb_release(info, 0);
> > > +
> > > + module_put(info->fbops->owner);
> > > +}
> > > +
> > > static int fbcon_open(struct fb_info *info)
> > > {
> > > + struct fbcon_ops *ops;
> > > +
> > > if (!try_module_get(info->fbops->owner))
> > > return -ENODEV;
> > >
> > > @@ -691,19 +701,22 @@ static int fbcon_open(struct fb_info *info)
> > > return -ENODEV;
> > > }
> > >
> > > - return 0;
> > > -}
> > > + ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL);
> > > + if (!ops) {
> > > + fbcon_release(info);
> > > + return -ENOMEM;
> > > + }
> > >
> > > -static void fbcon_release(struct fb_info *info)
> > > -{
> > > - if (info->fbops->fb_release)
> > > - info->fbops->fb_release(info, 0);
> > > + INIT_DELAYED_WORK(&ops->cursor_work, fb_flashcursor);
> > > + ops->info = info;
> > > + info->fbcon_par = ops;
> > > + ops->cur_blink_jiffies = HZ / 5;
> > >
> > > - module_put(info->fbops->owner);
> > > + return 0;
> > > }
> > >
> > > static int con2fb_acquire_newinfo(struct vc_data *vc, struct fb_info *info,
> > > - int unit, int oldidx)
> > > + int unit)
> > > {
> > > struct fbcon_ops *ops = NULL;
> > > int err;
> > > @@ -712,27 +725,10 @@ static int con2fb_acquire_newinfo(struct vc_data *vc, struct fb_info *info,
> > > if (err)
> > > return err;
> > >
> > > - if (!err) {
> > > - ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL);
> > > - if (!ops)
> > > - err = -ENOMEM;
> > > -
> > > - INIT_DELAYED_WORK(&ops->cursor_work, fb_flashcursor);
> > > - }
> > > -
> > > - if (!err) {
> > > - ops->cur_blink_jiffies = HZ / 5;
> > > - ops->info = info;
> > > - info->fbcon_par = ops;
> > > -
> > > - if (vc)
> > > - set_blitting_type(vc, info);
> > > - }
> > > + ops = info->fbcon_par;
> > >
> > > - if (err) {
> > > - con2fb_map[unit] = oldidx;
> > > - fbcon_release(info);
> > > - }
> > > + if (vc)
> > > + set_blitting_type(vc, info);
> > >
> > > return err;
> > > }
> > > @@ -840,9 +836,11 @@ static int set_con2fb_map(int unit, int newidx, int user)
> > >
> > > found = search_fb_in_map(newidx);
> > >
> > > - con2fb_map[unit] = newidx;
> > > - if (!err && !found)
> > > - err = con2fb_acquire_newinfo(vc, info, unit, oldidx);
> > > + if (!err && !found) {
> > > + err = con2fb_acquire_newinfo(vc, info, unit);
> > > + if (!err)
> > > + con2fb_map[unit] = newidx;
> > > + }
> > This looks like an unintentional change of functionality as con2fb_map[unit] is
> > only assigned when we do a con2fb_acquire_newinfo().
> >
> > Staring at the code I could not say it is wrong, but not nice to hide
> > the change in this patch.
>
> Nope, it's not an unintentional bugfix. The old con2fb_acquire_newinfo did
> reset con2fb_map to oldidx upon failure, which I've found to be a most
> bizarre calling convention. So this sorts this out.
>
> The reason I smashed this into the same patch is that I had to remove the
> fbcon_release call, and so the error handling in there looked even more
> funny. But I indeed failed to explain this all in the commit message.
>
> Ack with that explainer, or do you want me to split this out properly?
Please update the commit message, then this patch has my:
Acked-by: Sam Ravnborg <sam@ravnborg.org>
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [Intel-gfx] [PATCH 13/21] fbcon: move more common code into fb_open()
@ 2022-02-08 18:25 ` Sam Ravnborg
0 siblings, 0 replies; 241+ messages in thread
From: Sam Ravnborg @ 2022-02-08 18:25 UTC (permalink / raw)
To: DRI Development, linux-fbdev, Thomas Zimmermann, Du Cheng,
Tetsuo Handa, Intel Graphics Development, LKML, Claudio Suarez,
Greg Kroah-Hartman, Daniel Vetter
On Tue, Feb 08, 2022 at 02:53:59PM +0100, Daniel Vetter wrote:
> On Fri, Feb 04, 2022 at 08:35:31PM +0100, Sam Ravnborg wrote:
> > On Mon, Jan 31, 2022 at 10:05:44PM +0100, Daniel Vetter wrote:
> > > No idea why con2fb_acquire_newinfo() initializes much less than
> > > fbcon_startup(), but so be it. From a quick look most of the
> > > un-initialized stuff should be fairly harmless, but who knows.
> > >
> > > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > > Cc: Daniel Vetter <daniel@ffwll.ch>
> > > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> > > Cc: Thomas Zimmermann <tzimmermann@suse.de>
> > > Cc: Claudio Suarez <cssk@net-c.es>
> > > Cc: Du Cheng <ducheng2@gmail.com>
> > > ---
> > > drivers/video/fbdev/core/fbcon.c | 74 +++++++++++++-------------------
> > > 1 file changed, 31 insertions(+), 43 deletions(-)
> > >
> > > diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
> > > index b83a5a77d8a8..5a3391ff038d 100644
> > > --- a/drivers/video/fbdev/core/fbcon.c
> > > +++ b/drivers/video/fbdev/core/fbcon.c
> > > @@ -680,8 +680,18 @@ static int fbcon_invalid_charcount(struct fb_info *info, unsigned charcount)
> > >
> > > #endif /* CONFIG_MISC_TILEBLITTING */
> > >
> > > +static void fbcon_release(struct fb_info *info)
> > > +{
> > > + if (info->fbops->fb_release)
> > > + info->fbops->fb_release(info, 0);
> > > +
> > > + module_put(info->fbops->owner);
> > > +}
> > > +
> > > static int fbcon_open(struct fb_info *info)
> > > {
> > > + struct fbcon_ops *ops;
> > > +
> > > if (!try_module_get(info->fbops->owner))
> > > return -ENODEV;
> > >
> > > @@ -691,19 +701,22 @@ static int fbcon_open(struct fb_info *info)
> > > return -ENODEV;
> > > }
> > >
> > > - return 0;
> > > -}
> > > + ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL);
> > > + if (!ops) {
> > > + fbcon_release(info);
> > > + return -ENOMEM;
> > > + }
> > >
> > > -static void fbcon_release(struct fb_info *info)
> > > -{
> > > - if (info->fbops->fb_release)
> > > - info->fbops->fb_release(info, 0);
> > > + INIT_DELAYED_WORK(&ops->cursor_work, fb_flashcursor);
> > > + ops->info = info;
> > > + info->fbcon_par = ops;
> > > + ops->cur_blink_jiffies = HZ / 5;
> > >
> > > - module_put(info->fbops->owner);
> > > + return 0;
> > > }
> > >
> > > static int con2fb_acquire_newinfo(struct vc_data *vc, struct fb_info *info,
> > > - int unit, int oldidx)
> > > + int unit)
> > > {
> > > struct fbcon_ops *ops = NULL;
> > > int err;
> > > @@ -712,27 +725,10 @@ static int con2fb_acquire_newinfo(struct vc_data *vc, struct fb_info *info,
> > > if (err)
> > > return err;
> > >
> > > - if (!err) {
> > > - ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL);
> > > - if (!ops)
> > > - err = -ENOMEM;
> > > -
> > > - INIT_DELAYED_WORK(&ops->cursor_work, fb_flashcursor);
> > > - }
> > > -
> > > - if (!err) {
> > > - ops->cur_blink_jiffies = HZ / 5;
> > > - ops->info = info;
> > > - info->fbcon_par = ops;
> > > -
> > > - if (vc)
> > > - set_blitting_type(vc, info);
> > > - }
> > > + ops = info->fbcon_par;
> > >
> > > - if (err) {
> > > - con2fb_map[unit] = oldidx;
> > > - fbcon_release(info);
> > > - }
> > > + if (vc)
> > > + set_blitting_type(vc, info);
> > >
> > > return err;
> > > }
> > > @@ -840,9 +836,11 @@ static int set_con2fb_map(int unit, int newidx, int user)
> > >
> > > found = search_fb_in_map(newidx);
> > >
> > > - con2fb_map[unit] = newidx;
> > > - if (!err && !found)
> > > - err = con2fb_acquire_newinfo(vc, info, unit, oldidx);
> > > + if (!err && !found) {
> > > + err = con2fb_acquire_newinfo(vc, info, unit);
> > > + if (!err)
> > > + con2fb_map[unit] = newidx;
> > > + }
> > This looks like an unintentional change of functionality as con2fb_map[unit] is
> > only assigned when we do a con2fb_acquire_newinfo().
> >
> > Staring at the code I could not say it is wrong, but not nice to hide
> > the change in this patch.
>
> Nope, it's not an unintentional bugfix. The old con2fb_acquire_newinfo did
> reset con2fb_map to oldidx upon failure, which I've found to be a most
> bizarre calling convention. So this sorts this out.
>
> The reason I smashed this into the same patch is that I had to remove the
> fbcon_release call, and so the error handling in there looked even more
> funny. But I indeed failed to explain this all in the commit message.
>
> Ack with that explainer, or do you want me to split this out properly?
Please update the commit message, then this patch has my:
Acked-by: Sam Ravnborg <sam@ravnborg.org>
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 18/21] fbcon: untangle fbcon_exit
2022-02-08 13:58 ` Daniel Vetter
@ 2022-02-08 18:27 ` Sam Ravnborg
-1 siblings, 0 replies; 241+ messages in thread
From: Sam Ravnborg @ 2022-02-08 18:27 UTC (permalink / raw)
To: DRI Development, linux-fbdev, Du Cheng, Tetsuo Handa,
Intel Graphics Development, LKML, Claudio Suarez,
Greg Kroah-Hartman, Daniel Vetter
On Tue, Feb 08, 2022 at 02:58:21PM +0100, Daniel Vetter wrote:
> On Fri, Feb 04, 2022 at 09:06:38PM +0100, Sam Ravnborg wrote:
> > Hi Daniel,
> >
> > On Mon, Jan 31, 2022 at 10:05:49PM +0100, Daniel Vetter wrote:
> > > There's a bunch of confusions going on here:
> > > - The deferred fbcon setup notifier should only be cleaned up from
> > > fb_console_exit(), to be symmetric with fb_console_init()
> > > - We also need to make sure we don't race with the work, which means
> > > temporarily dropping the console lock (or we can deadlock)
> > > - That also means no point in clearing deferred_takeover, we are
> > > unloading everything anyway.
> > > - Finally rename fbcon_exit to fbcon_release_all and move it, since
> > > that's what's it doing when being called from consw->con_deinit
> > > through fbcon_deinit.
> > >
> > > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > > Cc: Daniel Vetter <daniel@ffwll.ch>
> > > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > Cc: Claudio Suarez <cssk@net-c.es>
> > > Cc: Du Cheng <ducheng2@gmail.com>
> > > Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> > > ---
> > > drivers/video/fbdev/core/fbcon.c | 63 ++++++++++++++++----------------
> > > 1 file changed, 32 insertions(+), 31 deletions(-)
> > >
> > > diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
> > > index 5c14e24d14a1..22581952b4fd 100644
> > > --- a/drivers/video/fbdev/core/fbcon.c
> > > +++ b/drivers/video/fbdev/core/fbcon.c
> > > @@ -185,7 +185,6 @@ static void fbcon_set_disp(struct fb_info *info, struct fb_var_screeninfo *var,
> > > int unit);
> > > static void fbcon_modechanged(struct fb_info *info);
> > > static void fbcon_set_all_vcs(struct fb_info *info);
> > > -static void fbcon_exit(void);
> > >
> > > static struct device *fbcon_device;
> > >
> > > @@ -1149,6 +1148,27 @@ static void fbcon_free_font(struct fbcon_display *p, bool freefont)
> > >
> > > static void set_vc_hi_font(struct vc_data *vc, bool set);
> > >
> > > +static void fbcon_release_all(void)
> > > +{
> > > + struct fb_info *info;
> > > + int i, j, mapped;
> > > +
> > > + for_each_registered_fb(i) {
> > > + mapped = 0;
> > > + info = registered_fb[i];
> > > +
> > > + for (j = first_fb_vc; j <= last_fb_vc; j++) {
> > > + if (con2fb_map[j] == i) {
> > > + mapped = 1;
> > > + con2fb_map[j] = -1;
> > > + }
> > > + }
> > > +
> > > + if (mapped)
> > > + fbcon_release(info);
> > > + }
> > > +}
> > > +
> > > static void fbcon_deinit(struct vc_data *vc)
> > > {
> > > struct fbcon_display *p = &fb_display[vc->vc_num];
> > > @@ -1188,7 +1208,7 @@ static void fbcon_deinit(struct vc_data *vc)
> > > set_vc_hi_font(vc, false);
> > >
> > > if (!con_is_bound(&fb_con))
> > > - fbcon_exit();
> > > + fbcon_release_all();
> > >
> > > if (vc->vc_num == logo_shown)
> > > logo_shown = FBCON_LOGO_CANSHOW;
> > > @@ -3316,34 +3336,6 @@ static void fbcon_start(void)
> > > #endif
> > > }
> > >
> > > -static void fbcon_exit(void)
> > > -{
> > > - struct fb_info *info;
> > > - int i, j, mapped;
> > > -
> > > -#ifdef CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER
> > > - if (deferred_takeover) {
> > > - dummycon_unregister_output_notifier(&fbcon_output_nb);
> > > - deferred_takeover = false;
> > > - }
> > > -#endif
> > > -
> > > - for_each_registered_fb(i) {
> > > - mapped = 0;
> > > - info = registered_fb[i];
> > > -
> > > - for (j = first_fb_vc; j <= last_fb_vc; j++) {
> > > - if (con2fb_map[j] == i) {
> > > - mapped = 1;
> > > - con2fb_map[j] = -1;
> > > - }
> > > - }
> > > -
> > > - if (mapped)
> > > - fbcon_release(info);
> > > - }
> > > -}
> > > -
> > > void __init fb_console_init(void)
> > > {
> > > int i;
> > > @@ -3383,10 +3375,19 @@ static void __exit fbcon_deinit_device(void)
> > >
> > > void __exit fb_console_exit(void)
> > > {
> > > +#ifdef CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER
> > > + console_lock();
> > > + if (deferred_takeover)
> > > + dummycon_unregister_output_notifier(&fbcon_output_nb);
> > > + console_unlock();
> > > +
> > > + cancel_work_sync(&fbcon_deferred_takeover_work);
> > > +#endif
> > > +
> > > console_lock();
> > > fbcon_deinit_device();
> > > device_destroy(fb_class, MKDEV(0, 0));
> > > - fbcon_exit();
> > > +
> > We loose the call to fbcon_release_all() here.
> > We have part of the old fbcon_exit() above, but miss the release parts.
> >
> > Maybe I missed something obvious?
>
> Ah yes that's the entire point of this change. The release_all in the
> fbcon exit path was only needed when fbcon was a separate module
> indepedent from core fb.ko. Which means it was possible to unload fbcon
> while having fbdev drivers registered.
>
> But since we've merged them that has become impossible, so by the time the
> fb.ko module can be unloaded, there's guaranteed to be no fbdev drivers
> left. And hence removing them is pointless.
Makes sense, thanks for the explanation.
>
> Ack with that explainer added to the commit message?
Yes, then it is
Acked-by: Sam Ravnborg <sam@ravnborg.org>
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [Intel-gfx] [PATCH 18/21] fbcon: untangle fbcon_exit
@ 2022-02-08 18:27 ` Sam Ravnborg
0 siblings, 0 replies; 241+ messages in thread
From: Sam Ravnborg @ 2022-02-08 18:27 UTC (permalink / raw)
To: DRI Development, linux-fbdev, Du Cheng, Tetsuo Handa,
Intel Graphics Development, LKML, Claudio Suarez,
Greg Kroah-Hartman, Daniel Vetter
On Tue, Feb 08, 2022 at 02:58:21PM +0100, Daniel Vetter wrote:
> On Fri, Feb 04, 2022 at 09:06:38PM +0100, Sam Ravnborg wrote:
> > Hi Daniel,
> >
> > On Mon, Jan 31, 2022 at 10:05:49PM +0100, Daniel Vetter wrote:
> > > There's a bunch of confusions going on here:
> > > - The deferred fbcon setup notifier should only be cleaned up from
> > > fb_console_exit(), to be symmetric with fb_console_init()
> > > - We also need to make sure we don't race with the work, which means
> > > temporarily dropping the console lock (or we can deadlock)
> > > - That also means no point in clearing deferred_takeover, we are
> > > unloading everything anyway.
> > > - Finally rename fbcon_exit to fbcon_release_all and move it, since
> > > that's what's it doing when being called from consw->con_deinit
> > > through fbcon_deinit.
> > >
> > > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > > Cc: Daniel Vetter <daniel@ffwll.ch>
> > > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > Cc: Claudio Suarez <cssk@net-c.es>
> > > Cc: Du Cheng <ducheng2@gmail.com>
> > > Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> > > ---
> > > drivers/video/fbdev/core/fbcon.c | 63 ++++++++++++++++----------------
> > > 1 file changed, 32 insertions(+), 31 deletions(-)
> > >
> > > diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
> > > index 5c14e24d14a1..22581952b4fd 100644
> > > --- a/drivers/video/fbdev/core/fbcon.c
> > > +++ b/drivers/video/fbdev/core/fbcon.c
> > > @@ -185,7 +185,6 @@ static void fbcon_set_disp(struct fb_info *info, struct fb_var_screeninfo *var,
> > > int unit);
> > > static void fbcon_modechanged(struct fb_info *info);
> > > static void fbcon_set_all_vcs(struct fb_info *info);
> > > -static void fbcon_exit(void);
> > >
> > > static struct device *fbcon_device;
> > >
> > > @@ -1149,6 +1148,27 @@ static void fbcon_free_font(struct fbcon_display *p, bool freefont)
> > >
> > > static void set_vc_hi_font(struct vc_data *vc, bool set);
> > >
> > > +static void fbcon_release_all(void)
> > > +{
> > > + struct fb_info *info;
> > > + int i, j, mapped;
> > > +
> > > + for_each_registered_fb(i) {
> > > + mapped = 0;
> > > + info = registered_fb[i];
> > > +
> > > + for (j = first_fb_vc; j <= last_fb_vc; j++) {
> > > + if (con2fb_map[j] == i) {
> > > + mapped = 1;
> > > + con2fb_map[j] = -1;
> > > + }
> > > + }
> > > +
> > > + if (mapped)
> > > + fbcon_release(info);
> > > + }
> > > +}
> > > +
> > > static void fbcon_deinit(struct vc_data *vc)
> > > {
> > > struct fbcon_display *p = &fb_display[vc->vc_num];
> > > @@ -1188,7 +1208,7 @@ static void fbcon_deinit(struct vc_data *vc)
> > > set_vc_hi_font(vc, false);
> > >
> > > if (!con_is_bound(&fb_con))
> > > - fbcon_exit();
> > > + fbcon_release_all();
> > >
> > > if (vc->vc_num == logo_shown)
> > > logo_shown = FBCON_LOGO_CANSHOW;
> > > @@ -3316,34 +3336,6 @@ static void fbcon_start(void)
> > > #endif
> > > }
> > >
> > > -static void fbcon_exit(void)
> > > -{
> > > - struct fb_info *info;
> > > - int i, j, mapped;
> > > -
> > > -#ifdef CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER
> > > - if (deferred_takeover) {
> > > - dummycon_unregister_output_notifier(&fbcon_output_nb);
> > > - deferred_takeover = false;
> > > - }
> > > -#endif
> > > -
> > > - for_each_registered_fb(i) {
> > > - mapped = 0;
> > > - info = registered_fb[i];
> > > -
> > > - for (j = first_fb_vc; j <= last_fb_vc; j++) {
> > > - if (con2fb_map[j] == i) {
> > > - mapped = 1;
> > > - con2fb_map[j] = -1;
> > > - }
> > > - }
> > > -
> > > - if (mapped)
> > > - fbcon_release(info);
> > > - }
> > > -}
> > > -
> > > void __init fb_console_init(void)
> > > {
> > > int i;
> > > @@ -3383,10 +3375,19 @@ static void __exit fbcon_deinit_device(void)
> > >
> > > void __exit fb_console_exit(void)
> > > {
> > > +#ifdef CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER
> > > + console_lock();
> > > + if (deferred_takeover)
> > > + dummycon_unregister_output_notifier(&fbcon_output_nb);
> > > + console_unlock();
> > > +
> > > + cancel_work_sync(&fbcon_deferred_takeover_work);
> > > +#endif
> > > +
> > > console_lock();
> > > fbcon_deinit_device();
> > > device_destroy(fb_class, MKDEV(0, 0));
> > > - fbcon_exit();
> > > +
> > We loose the call to fbcon_release_all() here.
> > We have part of the old fbcon_exit() above, but miss the release parts.
> >
> > Maybe I missed something obvious?
>
> Ah yes that's the entire point of this change. The release_all in the
> fbcon exit path was only needed when fbcon was a separate module
> indepedent from core fb.ko. Which means it was possible to unload fbcon
> while having fbdev drivers registered.
>
> But since we've merged them that has become impossible, so by the time the
> fb.ko module can be unloaded, there's guaranteed to be no fbdev drivers
> left. And hence removing them is pointless.
Makes sense, thanks for the explanation.
>
> Ack with that explainer added to the commit message?
Yes, then it is
Acked-by: Sam Ravnborg <sam@ravnborg.org>
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 19/21] fbcon: Maintain a private array of fb_info
2022-02-08 14:03 ` Daniel Vetter
@ 2022-02-08 18:55 ` Sam Ravnborg
-1 siblings, 0 replies; 241+ messages in thread
From: Sam Ravnborg @ 2022-02-08 18:55 UTC (permalink / raw)
To: DRI Development, linux-fbdev, Du Cheng, Tetsuo Handa,
Intel Graphics Development, LKML, Claudio Suarez,
Greg Kroah-Hartman, Daniel Vetter
Hi Daniel,
On Tue, Feb 08, 2022 at 03:03:28PM +0100, Daniel Vetter wrote:
> On Fri, Feb 04, 2022 at 09:15:40PM +0100, Sam Ravnborg wrote:
> > Hi Daniel,
> >
> > On Mon, Jan 31, 2022 at 10:05:50PM +0100, Daniel Vetter wrote:
> > > Accessing the one in fbmem.c without taking the right locks is a bad
> > > idea. Instead maintain our own private copy, which is fully protected
> > > by console_lock() (like everything else in fbcon.c). That copy is
> > > serialized through fbcon_fb_registered/unregistered() calls.
> >
> > I fail to see why we can make a private copy of registered_fb
> > just like that - are they not somehow shared between fbcon and fbmem.
> > So when fbmem updates it, then fbcon will use the entry or such?
> >
> > I guess I am just ignorant of how registered_fb is used - but please
> > explain.
>
> The private copy is protected under console_lock, and hence safe to access
> from fbcon.c code.
>
> The main registered_fb array is protected by a different mutex, so we
> could indeed end up with hilarious corruption because the value is
> inconsistent while we try to access it (e.g. we check for !NULL, but later
> on gcc decides to reload the value and now it's suddenly become NULL and
> we blow up).
>
> The two are synchronized by fbmem.c calling fbcon_register/unregister, so
> aside from the different locks if there's no race going on, they will
> always be identical.
IT was this part that I missed, and it is already spelled out in the
commit message.
>
> Other option would be to roll out get_fb_info() to fbcon.c, but since
> fbcon.c is fully protected by console_lock that would add complexity in
> the code flow that we don't really need. And we'd have to wire fb_info
> through all call chains, since the right way to use get_fb_info is to look
> it up once and then only drop it when your callback has finished.
>
> Since the current code just assume it's all protected by console_lock and
> we never drop that during a callback this would mean major surgery and
> essentially refactoring all of fbcon.c to only access the fbcon stuff
> through fb_info, i.e. to get rid of _all_ the global arrays we have more
> or less. I'm not volunteering for that (despite that really this would be
> the right thing to do if we'd have infinite engineering time).
>
> Ack with that explainer added to the commit message?
I consider the current commit message fine - it helps when you actually
read it.
Acked-by: Sam Ravnborg <sam@ravnborg.org>
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [Intel-gfx] [PATCH 19/21] fbcon: Maintain a private array of fb_info
@ 2022-02-08 18:55 ` Sam Ravnborg
0 siblings, 0 replies; 241+ messages in thread
From: Sam Ravnborg @ 2022-02-08 18:55 UTC (permalink / raw)
To: DRI Development, linux-fbdev, Du Cheng, Tetsuo Handa,
Intel Graphics Development, LKML, Claudio Suarez,
Greg Kroah-Hartman, Daniel Vetter
Hi Daniel,
On Tue, Feb 08, 2022 at 03:03:28PM +0100, Daniel Vetter wrote:
> On Fri, Feb 04, 2022 at 09:15:40PM +0100, Sam Ravnborg wrote:
> > Hi Daniel,
> >
> > On Mon, Jan 31, 2022 at 10:05:50PM +0100, Daniel Vetter wrote:
> > > Accessing the one in fbmem.c without taking the right locks is a bad
> > > idea. Instead maintain our own private copy, which is fully protected
> > > by console_lock() (like everything else in fbcon.c). That copy is
> > > serialized through fbcon_fb_registered/unregistered() calls.
> >
> > I fail to see why we can make a private copy of registered_fb
> > just like that - are they not somehow shared between fbcon and fbmem.
> > So when fbmem updates it, then fbcon will use the entry or such?
> >
> > I guess I am just ignorant of how registered_fb is used - but please
> > explain.
>
> The private copy is protected under console_lock, and hence safe to access
> from fbcon.c code.
>
> The main registered_fb array is protected by a different mutex, so we
> could indeed end up with hilarious corruption because the value is
> inconsistent while we try to access it (e.g. we check for !NULL, but later
> on gcc decides to reload the value and now it's suddenly become NULL and
> we blow up).
>
> The two are synchronized by fbmem.c calling fbcon_register/unregister, so
> aside from the different locks if there's no race going on, they will
> always be identical.
IT was this part that I missed, and it is already spelled out in the
commit message.
>
> Other option would be to roll out get_fb_info() to fbcon.c, but since
> fbcon.c is fully protected by console_lock that would add complexity in
> the code flow that we don't really need. And we'd have to wire fb_info
> through all call chains, since the right way to use get_fb_info is to look
> it up once and then only drop it when your callback has finished.
>
> Since the current code just assume it's all protected by console_lock and
> we never drop that during a callback this would mean major surgery and
> essentially refactoring all of fbcon.c to only access the fbcon stuff
> through fb_info, i.e. to get rid of _all_ the global arrays we have more
> or less. I'm not volunteering for that (despite that really this would be
> the right thing to do if we'd have infinite engineering time).
>
> Ack with that explainer added to the commit message?
I consider the current commit message fine - it helps when you actually
read it.
Acked-by: Sam Ravnborg <sam@ravnborg.org>
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 21/21] fbdev: Make registered_fb[] private to fbmem.c
2022-01-31 21:05 ` Daniel Vetter
(?)
@ 2022-02-08 19:00 ` Sam Ravnborg
-1 siblings, 0 replies; 241+ messages in thread
From: Sam Ravnborg @ 2022-02-08 19:00 UTC (permalink / raw)
To: Daniel Vetter
Cc: DRI Development, linux-fbdev, Zheyu Ma, Xiyu Yang,
Jens Frederich, Tetsuo Handa, Intel Graphics Development,
linux-staging, LKML, Matthew Wilcox, Zhen Lei, Guenter Roeck,
Greg Kroah-Hartman, Alex Deucher, Daniel Vetter, Jon Nettleton,
Helge Deller
Hi Daniel,
On Mon, Jan 31, 2022 at 10:05:52PM +0100, Daniel Vetter wrote:
> Well except when the olpc dcon fbdev driver is enabled, that thing
> digs around in there in rather unfixable ways.
>
> Cc oldc_dcon maintainers as fyi.
>
> Cc: Jens Frederich <jfrederich@gmail.com>
> Cc: Jon Nettleton <jon.nettleton@gmail.com>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: linux-staging@lists.linux.dev
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Cc: Helge Deller <deller@gmx.de>
> Cc: Matthew Wilcox <willy@infradead.org>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
> Cc: Zhen Lei <thunder.leizhen@huawei.com>
> Cc: Alex Deucher <alexander.deucher@amd.com>
> Cc: Xiyu Yang <xiyuyang19@fudan.edu.cn>
> Cc: linux-fbdev@vger.kernel.org
> Cc: Zheyu Ma <zheyuma97@gmail.com>
> Cc: Guenter Roeck <linux@roeck-us.net>
with the build thingy fixed:
Acked-by: Sam Ravnborg <sam@ravnborg.org>
I do wonder if there is a more clean way to trigger a blank
in the main fbdev driver from the olpc driver.
The current hack is not nice and it would be good to see it gone.
Sam
> ---
> drivers/video/fbdev/core/fbmem.c | 8 ++++++--
> include/linux/fb.h | 7 +++----
> 2 files changed, 9 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
> index 904ef1250677..dad6572942fa 100644
> --- a/drivers/video/fbdev/core/fbmem.c
> +++ b/drivers/video/fbdev/core/fbmem.c
> @@ -48,10 +48,14 @@
> static DEFINE_MUTEX(registration_lock);
>
> struct fb_info *registered_fb[FB_MAX] __read_mostly;
> -EXPORT_SYMBOL(registered_fb);
> -
> int num_registered_fb __read_mostly;
> +#if IS_ENABLED(CONFIG_OLPC_DCON)
> +EXPORT_SYMBOL(registered_fb);
> EXPORT_SYMBOL(num_registered_fb);
> +#endif
> +#define for_each_registered_fb(i) \
> + for (i = 0; i < FB_MAX; i++) \
> + if (!registered_fb[i]) {} else
>
> bool fb_center_logo __read_mostly;
>
> diff --git a/include/linux/fb.h b/include/linux/fb.h
> index a8a00d2ba1f3..e236817502c2 100644
> --- a/include/linux/fb.h
> +++ b/include/linux/fb.h
> @@ -622,16 +622,15 @@ extern int fb_get_color_depth(struct fb_var_screeninfo *var,
> extern int fb_get_options(const char *name, char **option);
> extern int fb_new_modelist(struct fb_info *info);
>
> +#if IS_ENABLED(CONFIG_OLPC_DCON)
> extern struct fb_info *registered_fb[FB_MAX];
> +
> extern int num_registered_fb;
> +#endif
> extern bool fb_center_logo;
> extern int fb_logo_count;
> extern struct class *fb_class;
>
> -#define for_each_registered_fb(i) \
> - for (i = 0; i < FB_MAX; i++) \
> - if (!registered_fb[i]) {} else
> -
> static inline void lock_fb_info(struct fb_info *info)
> {
> mutex_lock(&info->lock);
> --
> 2.33.0
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [Intel-gfx] [PATCH 21/21] fbdev: Make registered_fb[] private to fbmem.c
@ 2022-02-08 19:00 ` Sam Ravnborg
0 siblings, 0 replies; 241+ messages in thread
From: Sam Ravnborg @ 2022-02-08 19:00 UTC (permalink / raw)
To: Daniel Vetter
Cc: linux-fbdev, linux-staging, Xiyu Yang, Jens Frederich,
Tetsuo Handa, Greg Kroah-Hartman, Intel Graphics Development,
Zheyu Ma, LKML, DRI Development, Matthew Wilcox, Helge Deller,
Zhen Lei, Alex Deucher, Daniel Vetter, Jon Nettleton,
Guenter Roeck
Hi Daniel,
On Mon, Jan 31, 2022 at 10:05:52PM +0100, Daniel Vetter wrote:
> Well except when the olpc dcon fbdev driver is enabled, that thing
> digs around in there in rather unfixable ways.
>
> Cc oldc_dcon maintainers as fyi.
>
> Cc: Jens Frederich <jfrederich@gmail.com>
> Cc: Jon Nettleton <jon.nettleton@gmail.com>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: linux-staging@lists.linux.dev
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Cc: Helge Deller <deller@gmx.de>
> Cc: Matthew Wilcox <willy@infradead.org>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
> Cc: Zhen Lei <thunder.leizhen@huawei.com>
> Cc: Alex Deucher <alexander.deucher@amd.com>
> Cc: Xiyu Yang <xiyuyang19@fudan.edu.cn>
> Cc: linux-fbdev@vger.kernel.org
> Cc: Zheyu Ma <zheyuma97@gmail.com>
> Cc: Guenter Roeck <linux@roeck-us.net>
with the build thingy fixed:
Acked-by: Sam Ravnborg <sam@ravnborg.org>
I do wonder if there is a more clean way to trigger a blank
in the main fbdev driver from the olpc driver.
The current hack is not nice and it would be good to see it gone.
Sam
> ---
> drivers/video/fbdev/core/fbmem.c | 8 ++++++--
> include/linux/fb.h | 7 +++----
> 2 files changed, 9 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
> index 904ef1250677..dad6572942fa 100644
> --- a/drivers/video/fbdev/core/fbmem.c
> +++ b/drivers/video/fbdev/core/fbmem.c
> @@ -48,10 +48,14 @@
> static DEFINE_MUTEX(registration_lock);
>
> struct fb_info *registered_fb[FB_MAX] __read_mostly;
> -EXPORT_SYMBOL(registered_fb);
> -
> int num_registered_fb __read_mostly;
> +#if IS_ENABLED(CONFIG_OLPC_DCON)
> +EXPORT_SYMBOL(registered_fb);
> EXPORT_SYMBOL(num_registered_fb);
> +#endif
> +#define for_each_registered_fb(i) \
> + for (i = 0; i < FB_MAX; i++) \
> + if (!registered_fb[i]) {} else
>
> bool fb_center_logo __read_mostly;
>
> diff --git a/include/linux/fb.h b/include/linux/fb.h
> index a8a00d2ba1f3..e236817502c2 100644
> --- a/include/linux/fb.h
> +++ b/include/linux/fb.h
> @@ -622,16 +622,15 @@ extern int fb_get_color_depth(struct fb_var_screeninfo *var,
> extern int fb_get_options(const char *name, char **option);
> extern int fb_new_modelist(struct fb_info *info);
>
> +#if IS_ENABLED(CONFIG_OLPC_DCON)
> extern struct fb_info *registered_fb[FB_MAX];
> +
> extern int num_registered_fb;
> +#endif
> extern bool fb_center_logo;
> extern int fb_logo_count;
> extern struct class *fb_class;
>
> -#define for_each_registered_fb(i) \
> - for (i = 0; i < FB_MAX; i++) \
> - if (!registered_fb[i]) {} else
> -
> static inline void lock_fb_info(struct fb_info *info)
> {
> mutex_lock(&info->lock);
> --
> 2.33.0
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 21/21] fbdev: Make registered_fb[] private to fbmem.c
@ 2022-02-08 19:00 ` Sam Ravnborg
0 siblings, 0 replies; 241+ messages in thread
From: Sam Ravnborg @ 2022-02-08 19:00 UTC (permalink / raw)
To: Daniel Vetter
Cc: linux-fbdev, linux-staging, Xiyu Yang, Jens Frederich,
Tetsuo Handa, Greg Kroah-Hartman, Intel Graphics Development,
Zheyu Ma, LKML, DRI Development, Matthew Wilcox, Helge Deller,
Zhen Lei, Alex Deucher, Daniel Vetter, Jon Nettleton,
Guenter Roeck
Hi Daniel,
On Mon, Jan 31, 2022 at 10:05:52PM +0100, Daniel Vetter wrote:
> Well except when the olpc dcon fbdev driver is enabled, that thing
> digs around in there in rather unfixable ways.
>
> Cc oldc_dcon maintainers as fyi.
>
> Cc: Jens Frederich <jfrederich@gmail.com>
> Cc: Jon Nettleton <jon.nettleton@gmail.com>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: linux-staging@lists.linux.dev
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Cc: Helge Deller <deller@gmx.de>
> Cc: Matthew Wilcox <willy@infradead.org>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
> Cc: Zhen Lei <thunder.leizhen@huawei.com>
> Cc: Alex Deucher <alexander.deucher@amd.com>
> Cc: Xiyu Yang <xiyuyang19@fudan.edu.cn>
> Cc: linux-fbdev@vger.kernel.org
> Cc: Zheyu Ma <zheyuma97@gmail.com>
> Cc: Guenter Roeck <linux@roeck-us.net>
with the build thingy fixed:
Acked-by: Sam Ravnborg <sam@ravnborg.org>
I do wonder if there is a more clean way to trigger a blank
in the main fbdev driver from the olpc driver.
The current hack is not nice and it would be good to see it gone.
Sam
> ---
> drivers/video/fbdev/core/fbmem.c | 8 ++++++--
> include/linux/fb.h | 7 +++----
> 2 files changed, 9 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
> index 904ef1250677..dad6572942fa 100644
> --- a/drivers/video/fbdev/core/fbmem.c
> +++ b/drivers/video/fbdev/core/fbmem.c
> @@ -48,10 +48,14 @@
> static DEFINE_MUTEX(registration_lock);
>
> struct fb_info *registered_fb[FB_MAX] __read_mostly;
> -EXPORT_SYMBOL(registered_fb);
> -
> int num_registered_fb __read_mostly;
> +#if IS_ENABLED(CONFIG_OLPC_DCON)
> +EXPORT_SYMBOL(registered_fb);
> EXPORT_SYMBOL(num_registered_fb);
> +#endif
> +#define for_each_registered_fb(i) \
> + for (i = 0; i < FB_MAX; i++) \
> + if (!registered_fb[i]) {} else
>
> bool fb_center_logo __read_mostly;
>
> diff --git a/include/linux/fb.h b/include/linux/fb.h
> index a8a00d2ba1f3..e236817502c2 100644
> --- a/include/linux/fb.h
> +++ b/include/linux/fb.h
> @@ -622,16 +622,15 @@ extern int fb_get_color_depth(struct fb_var_screeninfo *var,
> extern int fb_get_options(const char *name, char **option);
> extern int fb_new_modelist(struct fb_info *info);
>
> +#if IS_ENABLED(CONFIG_OLPC_DCON)
> extern struct fb_info *registered_fb[FB_MAX];
> +
> extern int num_registered_fb;
> +#endif
> extern bool fb_center_logo;
> extern int fb_logo_count;
> extern struct class *fb_class;
>
> -#define for_each_registered_fb(i) \
> - for (i = 0; i < FB_MAX; i++) \
> - if (!registered_fb[i]) {} else
> -
> static inline void lock_fb_info(struct fb_info *info)
> {
> mutex_lock(&info->lock);
> --
> 2.33.0
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [Intel-gfx] [PATCH 11/21] fbcon: Extract fbcon_open/release helpers
2022-02-08 18:24 ` [Intel-gfx] " Sam Ravnborg
(?)
@ 2022-02-08 19:51 ` Daniel Vetter
-1 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-02-08 19:51 UTC (permalink / raw)
To: Sam Ravnborg
Cc: linux-fbdev, Du Cheng, Tetsuo Handa, Greg Kroah-Hartman,
Intel Graphics Development, LKML, DRI Development,
Claudio Suarez, Daniel Vetter
On Tue, Feb 08, 2022 at 07:24:03PM +0100, Sam Ravnborg wrote:
> Hi Daniel,
>
> On Tue, Feb 08, 2022 at 02:48:29PM +0100, Daniel Vetter wrote:
> > On Thu, Feb 03, 2022 at 10:15:14PM +0100, Sam Ravnborg wrote:
> > > Hi Daniel,
> > >
> > > On Mon, Jan 31, 2022 at 10:05:42PM +0100, Daniel Vetter wrote:
> > > > There's two minor behaviour changes in here:
> > > > - in error paths we now consistently call fb_ops->fb_release
> > > > - fb_release really can't fail (fbmem.c ignores it too) and there's no
> > > > reasonable cleanup we can do anyway.
> > > >
> > > > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > > > Cc: Daniel Vetter <daniel@ffwll.ch>
> > > > Cc: Claudio Suarez <cssk@net-c.es>
> > > > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > > Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> > > > Cc: Du Cheng <ducheng2@gmail.com>
> > > > ---
> > > > drivers/video/fbdev/core/fbcon.c | 107 +++++++++++++++----------------
> > > > 1 file changed, 53 insertions(+), 54 deletions(-)
> > > >
> > > > diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
> > > > index fa30e1909164..eea2ee14b64c 100644
> > > > --- a/drivers/video/fbdev/core/fbcon.c
> > > > +++ b/drivers/video/fbdev/core/fbcon.c
> > > > @@ -680,19 +680,37 @@ static int fbcon_invalid_charcount(struct fb_info *info, unsigned charcount)
> > > >
> > > > #endif /* CONFIG_MISC_TILEBLITTING */
> > > >
> > > > +static int fbcon_open(struct fb_info *info)
> > > > +{
> > > > + if (!try_module_get(info->fbops->owner))
> > > > + return -ENODEV;
> > > > +
> > > > + if (info->fbops->fb_open &&
> > > > + info->fbops->fb_open(info, 0)) {
> > > > + module_put(info->fbops->owner);
> > > > + return -ENODEV;
> > > > + }
> > > > +
> > > > + return 0;
> > > > +}
> > > > +
> > > > +static void fbcon_release(struct fb_info *info)
> > > > +{
> > > > + if (info->fbops->fb_release)
> > > > + info->fbops->fb_release(info, 0);
> > > > +
> > > > + module_put(info->fbops->owner);
> > > > +}
> > > >
> > > > static int con2fb_acquire_newinfo(struct vc_data *vc, struct fb_info *info,
> > > > int unit, int oldidx)
> > > > {
> > > > struct fbcon_ops *ops = NULL;
> > > > - int err = 0;
> > > > -
> > > > - if (!try_module_get(info->fbops->owner))
> > > > - err = -ENODEV;
> > > > + int err;
> > > >
> > > > - if (!err && info->fbops->fb_open &&
> > > > - info->fbops->fb_open(info, 0))
> > > > - err = -ENODEV;
> > > > + err = fbcon_open(info);
> > > > + if (err)
> > > > + return err;
> > > >
> > > > if (!err) {
> > > > ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL);
> > > > @@ -713,7 +731,7 @@ static int con2fb_acquire_newinfo(struct vc_data *vc, struct fb_info *info,
> > > >
> > > > if (err) {
> > > > con2fb_map[unit] = oldidx;
> > > > - module_put(info->fbops->owner);
> > > > + fbcon_release(info);
> > > > }
> > > >
> > > > return err;
> > > > @@ -724,45 +742,34 @@ static int con2fb_release_oldinfo(struct vc_data *vc, struct fb_info *oldinfo,
> > > > int oldidx, int found)
> > > > {
> > > > struct fbcon_ops *ops = oldinfo->fbcon_par;
> > > > - int err = 0, ret;
> > > > + int ret;
> > > >
> > > > - if (oldinfo->fbops->fb_release &&
> > > > - oldinfo->fbops->fb_release(oldinfo, 0)) {
> > > > - con2fb_map[unit] = oldidx;
> > > The old code assigns con2fb_map[unit] before is calls
> > > newinfo->fbops->fb_release).
> > > I wonder if there can be any callback to fbcon where the value
> > > of con2fb_map[unit] matters?
> >
> > It's all protected by console_lock, so other threads cannot see the
> > inconsistent state.
> >
> > Essentially everything in fbcon.c is protected by console_lock().
> >
> > Do you want me to hammer this in somewhere (maybe in the commit message),
> > or good enough for your ack?
>
> No need to spell it out more.
I think this was a very good question, since I had to spend a few minutes
figuring out what exactly and why I've done it too.
So I'll add this explainer, it really should have been in the commit
message!
> Add my a-b and apply it.
Well I need to resend, since there was a minor change due to rebasing on
top of Helge's fbcon scrolling patches instead of mine.
Thanks for your review
-Daniel
>
> Sam
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [Intel-gfx] [PATCH 11/21] fbcon: Extract fbcon_open/release helpers
@ 2022-02-08 19:51 ` Daniel Vetter
0 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-02-08 19:51 UTC (permalink / raw)
To: Sam Ravnborg
Cc: linux-fbdev, Du Cheng, Tetsuo Handa, Greg Kroah-Hartman,
Intel Graphics Development, LKML, DRI Development, Daniel Vetter
On Tue, Feb 08, 2022 at 07:24:03PM +0100, Sam Ravnborg wrote:
> Hi Daniel,
>
> On Tue, Feb 08, 2022 at 02:48:29PM +0100, Daniel Vetter wrote:
> > On Thu, Feb 03, 2022 at 10:15:14PM +0100, Sam Ravnborg wrote:
> > > Hi Daniel,
> > >
> > > On Mon, Jan 31, 2022 at 10:05:42PM +0100, Daniel Vetter wrote:
> > > > There's two minor behaviour changes in here:
> > > > - in error paths we now consistently call fb_ops->fb_release
> > > > - fb_release really can't fail (fbmem.c ignores it too) and there's no
> > > > reasonable cleanup we can do anyway.
> > > >
> > > > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > > > Cc: Daniel Vetter <daniel@ffwll.ch>
> > > > Cc: Claudio Suarez <cssk@net-c.es>
> > > > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > > Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> > > > Cc: Du Cheng <ducheng2@gmail.com>
> > > > ---
> > > > drivers/video/fbdev/core/fbcon.c | 107 +++++++++++++++----------------
> > > > 1 file changed, 53 insertions(+), 54 deletions(-)
> > > >
> > > > diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
> > > > index fa30e1909164..eea2ee14b64c 100644
> > > > --- a/drivers/video/fbdev/core/fbcon.c
> > > > +++ b/drivers/video/fbdev/core/fbcon.c
> > > > @@ -680,19 +680,37 @@ static int fbcon_invalid_charcount(struct fb_info *info, unsigned charcount)
> > > >
> > > > #endif /* CONFIG_MISC_TILEBLITTING */
> > > >
> > > > +static int fbcon_open(struct fb_info *info)
> > > > +{
> > > > + if (!try_module_get(info->fbops->owner))
> > > > + return -ENODEV;
> > > > +
> > > > + if (info->fbops->fb_open &&
> > > > + info->fbops->fb_open(info, 0)) {
> > > > + module_put(info->fbops->owner);
> > > > + return -ENODEV;
> > > > + }
> > > > +
> > > > + return 0;
> > > > +}
> > > > +
> > > > +static void fbcon_release(struct fb_info *info)
> > > > +{
> > > > + if (info->fbops->fb_release)
> > > > + info->fbops->fb_release(info, 0);
> > > > +
> > > > + module_put(info->fbops->owner);
> > > > +}
> > > >
> > > > static int con2fb_acquire_newinfo(struct vc_data *vc, struct fb_info *info,
> > > > int unit, int oldidx)
> > > > {
> > > > struct fbcon_ops *ops = NULL;
> > > > - int err = 0;
> > > > -
> > > > - if (!try_module_get(info->fbops->owner))
> > > > - err = -ENODEV;
> > > > + int err;
> > > >
> > > > - if (!err && info->fbops->fb_open &&
> > > > - info->fbops->fb_open(info, 0))
> > > > - err = -ENODEV;
> > > > + err = fbcon_open(info);
> > > > + if (err)
> > > > + return err;
> > > >
> > > > if (!err) {
> > > > ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL);
> > > > @@ -713,7 +731,7 @@ static int con2fb_acquire_newinfo(struct vc_data *vc, struct fb_info *info,
> > > >
> > > > if (err) {
> > > > con2fb_map[unit] = oldidx;
> > > > - module_put(info->fbops->owner);
> > > > + fbcon_release(info);
> > > > }
> > > >
> > > > return err;
> > > > @@ -724,45 +742,34 @@ static int con2fb_release_oldinfo(struct vc_data *vc, struct fb_info *oldinfo,
> > > > int oldidx, int found)
> > > > {
> > > > struct fbcon_ops *ops = oldinfo->fbcon_par;
> > > > - int err = 0, ret;
> > > > + int ret;
> > > >
> > > > - if (oldinfo->fbops->fb_release &&
> > > > - oldinfo->fbops->fb_release(oldinfo, 0)) {
> > > > - con2fb_map[unit] = oldidx;
> > > The old code assigns con2fb_map[unit] before is calls
> > > newinfo->fbops->fb_release).
> > > I wonder if there can be any callback to fbcon where the value
> > > of con2fb_map[unit] matters?
> >
> > It's all protected by console_lock, so other threads cannot see the
> > inconsistent state.
> >
> > Essentially everything in fbcon.c is protected by console_lock().
> >
> > Do you want me to hammer this in somewhere (maybe in the commit message),
> > or good enough for your ack?
>
> No need to spell it out more.
I think this was a very good question, since I had to spend a few minutes
figuring out what exactly and why I've done it too.
So I'll add this explainer, it really should have been in the commit
message!
> Add my a-b and apply it.
Well I need to resend, since there was a minor change due to rebasing on
top of Helge's fbcon scrolling patches instead of mine.
Thanks for your review
-Daniel
>
> Sam
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [Intel-gfx] [PATCH 11/21] fbcon: Extract fbcon_open/release helpers
@ 2022-02-08 19:51 ` Daniel Vetter
0 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-02-08 19:51 UTC (permalink / raw)
To: Sam Ravnborg
Cc: DRI Development, linux-fbdev, Du Cheng, Tetsuo Handa,
Intel Graphics Development, LKML, Claudio Suarez,
Greg Kroah-Hartman, Daniel Vetter
On Tue, Feb 08, 2022 at 07:24:03PM +0100, Sam Ravnborg wrote:
> Hi Daniel,
>
> On Tue, Feb 08, 2022 at 02:48:29PM +0100, Daniel Vetter wrote:
> > On Thu, Feb 03, 2022 at 10:15:14PM +0100, Sam Ravnborg wrote:
> > > Hi Daniel,
> > >
> > > On Mon, Jan 31, 2022 at 10:05:42PM +0100, Daniel Vetter wrote:
> > > > There's two minor behaviour changes in here:
> > > > - in error paths we now consistently call fb_ops->fb_release
> > > > - fb_release really can't fail (fbmem.c ignores it too) and there's no
> > > > reasonable cleanup we can do anyway.
> > > >
> > > > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > > > Cc: Daniel Vetter <daniel@ffwll.ch>
> > > > Cc: Claudio Suarez <cssk@net-c.es>
> > > > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > > Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> > > > Cc: Du Cheng <ducheng2@gmail.com>
> > > > ---
> > > > drivers/video/fbdev/core/fbcon.c | 107 +++++++++++++++----------------
> > > > 1 file changed, 53 insertions(+), 54 deletions(-)
> > > >
> > > > diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
> > > > index fa30e1909164..eea2ee14b64c 100644
> > > > --- a/drivers/video/fbdev/core/fbcon.c
> > > > +++ b/drivers/video/fbdev/core/fbcon.c
> > > > @@ -680,19 +680,37 @@ static int fbcon_invalid_charcount(struct fb_info *info, unsigned charcount)
> > > >
> > > > #endif /* CONFIG_MISC_TILEBLITTING */
> > > >
> > > > +static int fbcon_open(struct fb_info *info)
> > > > +{
> > > > + if (!try_module_get(info->fbops->owner))
> > > > + return -ENODEV;
> > > > +
> > > > + if (info->fbops->fb_open &&
> > > > + info->fbops->fb_open(info, 0)) {
> > > > + module_put(info->fbops->owner);
> > > > + return -ENODEV;
> > > > + }
> > > > +
> > > > + return 0;
> > > > +}
> > > > +
> > > > +static void fbcon_release(struct fb_info *info)
> > > > +{
> > > > + if (info->fbops->fb_release)
> > > > + info->fbops->fb_release(info, 0);
> > > > +
> > > > + module_put(info->fbops->owner);
> > > > +}
> > > >
> > > > static int con2fb_acquire_newinfo(struct vc_data *vc, struct fb_info *info,
> > > > int unit, int oldidx)
> > > > {
> > > > struct fbcon_ops *ops = NULL;
> > > > - int err = 0;
> > > > -
> > > > - if (!try_module_get(info->fbops->owner))
> > > > - err = -ENODEV;
> > > > + int err;
> > > >
> > > > - if (!err && info->fbops->fb_open &&
> > > > - info->fbops->fb_open(info, 0))
> > > > - err = -ENODEV;
> > > > + err = fbcon_open(info);
> > > > + if (err)
> > > > + return err;
> > > >
> > > > if (!err) {
> > > > ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL);
> > > > @@ -713,7 +731,7 @@ static int con2fb_acquire_newinfo(struct vc_data *vc, struct fb_info *info,
> > > >
> > > > if (err) {
> > > > con2fb_map[unit] = oldidx;
> > > > - module_put(info->fbops->owner);
> > > > + fbcon_release(info);
> > > > }
> > > >
> > > > return err;
> > > > @@ -724,45 +742,34 @@ static int con2fb_release_oldinfo(struct vc_data *vc, struct fb_info *oldinfo,
> > > > int oldidx, int found)
> > > > {
> > > > struct fbcon_ops *ops = oldinfo->fbcon_par;
> > > > - int err = 0, ret;
> > > > + int ret;
> > > >
> > > > - if (oldinfo->fbops->fb_release &&
> > > > - oldinfo->fbops->fb_release(oldinfo, 0)) {
> > > > - con2fb_map[unit] = oldidx;
> > > The old code assigns con2fb_map[unit] before is calls
> > > newinfo->fbops->fb_release).
> > > I wonder if there can be any callback to fbcon where the value
> > > of con2fb_map[unit] matters?
> >
> > It's all protected by console_lock, so other threads cannot see the
> > inconsistent state.
> >
> > Essentially everything in fbcon.c is protected by console_lock().
> >
> > Do you want me to hammer this in somewhere (maybe in the commit message),
> > or good enough for your ack?
>
> No need to spell it out more.
I think this was a very good question, since I had to spend a few minutes
figuring out what exactly and why I've done it too.
So I'll add this explainer, it really should have been in the commit
message!
> Add my a-b and apply it.
Well I need to resend, since there was a minor change due to rebasing on
top of Helge's fbcon scrolling patches instead of mine.
Thanks for your review
-Daniel
>
> Sam
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 21/21] fbdev: Make registered_fb[] private to fbmem.c
2022-02-08 19:00 ` [Intel-gfx] " Sam Ravnborg
(?)
@ 2022-02-08 20:56 ` Daniel Vetter
-1 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-02-08 20:56 UTC (permalink / raw)
To: Sam Ravnborg
Cc: linux-fbdev, linux-staging, Xiyu Yang, Jens Frederich,
Tetsuo Handa, Daniel Vetter, Intel Graphics Development,
Zheyu Ma, LKML, DRI Development, Greg Kroah-Hartman,
Matthew Wilcox, Helge Deller, Zhen Lei, Alex Deucher,
Daniel Vetter, Jon Nettleton, Guenter Roeck
On Tue, Feb 08, 2022 at 08:00:38PM +0100, Sam Ravnborg wrote:
> Hi Daniel,
>
> On Mon, Jan 31, 2022 at 10:05:52PM +0100, Daniel Vetter wrote:
> > Well except when the olpc dcon fbdev driver is enabled, that thing
> > digs around in there in rather unfixable ways.
> >
> > Cc oldc_dcon maintainers as fyi.
> >
> > Cc: Jens Frederich <jfrederich@gmail.com>
> > Cc: Jon Nettleton <jon.nettleton@gmail.com>
> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Cc: linux-staging@lists.linux.dev
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > Cc: Daniel Vetter <daniel@ffwll.ch>
> > Cc: Helge Deller <deller@gmx.de>
> > Cc: Matthew Wilcox <willy@infradead.org>
> > Cc: Sam Ravnborg <sam@ravnborg.org>
> > Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
> > Cc: Zhen Lei <thunder.leizhen@huawei.com>
> > Cc: Alex Deucher <alexander.deucher@amd.com>
> > Cc: Xiyu Yang <xiyuyang19@fudan.edu.cn>
> > Cc: linux-fbdev@vger.kernel.org
> > Cc: Zheyu Ma <zheyuma97@gmail.com>
> > Cc: Guenter Roeck <linux@roeck-us.net>
>
> with the build thingy fixed:
> Acked-by: Sam Ravnborg <sam@ravnborg.org>
>
> I do wonder if there is a more clean way to trigger a blank
> in the main fbdev driver from the olpc driver.
>
> The current hack is not nice and it would be good to see it gone.
Yeah this is just badly engineered. In drm we'd do this with the self
refresh helpers, which pretty much give you this exact functionality, but
in the helpers, while not randomly breaking actual visible behaviour of
the display driver.
Well ok the illusion is not perfect, since if the display is suspended the
next page flip will take a tad longer. But that's it.
I'll also add this to the TODO.
-Daniel
>
> Sam
>
> > ---
> > drivers/video/fbdev/core/fbmem.c | 8 ++++++--
> > include/linux/fb.h | 7 +++----
> > 2 files changed, 9 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
> > index 904ef1250677..dad6572942fa 100644
> > --- a/drivers/video/fbdev/core/fbmem.c
> > +++ b/drivers/video/fbdev/core/fbmem.c
> > @@ -48,10 +48,14 @@
> > static DEFINE_MUTEX(registration_lock);
> >
> > struct fb_info *registered_fb[FB_MAX] __read_mostly;
> > -EXPORT_SYMBOL(registered_fb);
> > -
> > int num_registered_fb __read_mostly;
> > +#if IS_ENABLED(CONFIG_OLPC_DCON)
> > +EXPORT_SYMBOL(registered_fb);
> > EXPORT_SYMBOL(num_registered_fb);
> > +#endif
> > +#define for_each_registered_fb(i) \
> > + for (i = 0; i < FB_MAX; i++) \
> > + if (!registered_fb[i]) {} else
> >
> > bool fb_center_logo __read_mostly;
> >
> > diff --git a/include/linux/fb.h b/include/linux/fb.h
> > index a8a00d2ba1f3..e236817502c2 100644
> > --- a/include/linux/fb.h
> > +++ b/include/linux/fb.h
> > @@ -622,16 +622,15 @@ extern int fb_get_color_depth(struct fb_var_screeninfo *var,
> > extern int fb_get_options(const char *name, char **option);
> > extern int fb_new_modelist(struct fb_info *info);
> >
> > +#if IS_ENABLED(CONFIG_OLPC_DCON)
> > extern struct fb_info *registered_fb[FB_MAX];
> > +
> > extern int num_registered_fb;
> > +#endif
> > extern bool fb_center_logo;
> > extern int fb_logo_count;
> > extern struct class *fb_class;
> >
> > -#define for_each_registered_fb(i) \
> > - for (i = 0; i < FB_MAX; i++) \
> > - if (!registered_fb[i]) {} else
> > -
> > static inline void lock_fb_info(struct fb_info *info)
> > {
> > mutex_lock(&info->lock);
> > --
> > 2.33.0
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [Intel-gfx] [PATCH 21/21] fbdev: Make registered_fb[] private to fbmem.c
@ 2022-02-08 20:56 ` Daniel Vetter
0 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-02-08 20:56 UTC (permalink / raw)
To: Sam Ravnborg
Cc: linux-fbdev, linux-staging, Xiyu Yang, Jens Frederich,
Tetsuo Handa, Daniel Vetter, Intel Graphics Development,
Zheyu Ma, LKML, DRI Development, Greg Kroah-Hartman,
Matthew Wilcox, Helge Deller, Zhen Lei, Alex Deucher,
Daniel Vetter, Jon Nettleton, Guenter Roeck
On Tue, Feb 08, 2022 at 08:00:38PM +0100, Sam Ravnborg wrote:
> Hi Daniel,
>
> On Mon, Jan 31, 2022 at 10:05:52PM +0100, Daniel Vetter wrote:
> > Well except when the olpc dcon fbdev driver is enabled, that thing
> > digs around in there in rather unfixable ways.
> >
> > Cc oldc_dcon maintainers as fyi.
> >
> > Cc: Jens Frederich <jfrederich@gmail.com>
> > Cc: Jon Nettleton <jon.nettleton@gmail.com>
> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Cc: linux-staging@lists.linux.dev
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > Cc: Daniel Vetter <daniel@ffwll.ch>
> > Cc: Helge Deller <deller@gmx.de>
> > Cc: Matthew Wilcox <willy@infradead.org>
> > Cc: Sam Ravnborg <sam@ravnborg.org>
> > Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
> > Cc: Zhen Lei <thunder.leizhen@huawei.com>
> > Cc: Alex Deucher <alexander.deucher@amd.com>
> > Cc: Xiyu Yang <xiyuyang19@fudan.edu.cn>
> > Cc: linux-fbdev@vger.kernel.org
> > Cc: Zheyu Ma <zheyuma97@gmail.com>
> > Cc: Guenter Roeck <linux@roeck-us.net>
>
> with the build thingy fixed:
> Acked-by: Sam Ravnborg <sam@ravnborg.org>
>
> I do wonder if there is a more clean way to trigger a blank
> in the main fbdev driver from the olpc driver.
>
> The current hack is not nice and it would be good to see it gone.
Yeah this is just badly engineered. In drm we'd do this with the self
refresh helpers, which pretty much give you this exact functionality, but
in the helpers, while not randomly breaking actual visible behaviour of
the display driver.
Well ok the illusion is not perfect, since if the display is suspended the
next page flip will take a tad longer. But that's it.
I'll also add this to the TODO.
-Daniel
>
> Sam
>
> > ---
> > drivers/video/fbdev/core/fbmem.c | 8 ++++++--
> > include/linux/fb.h | 7 +++----
> > 2 files changed, 9 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
> > index 904ef1250677..dad6572942fa 100644
> > --- a/drivers/video/fbdev/core/fbmem.c
> > +++ b/drivers/video/fbdev/core/fbmem.c
> > @@ -48,10 +48,14 @@
> > static DEFINE_MUTEX(registration_lock);
> >
> > struct fb_info *registered_fb[FB_MAX] __read_mostly;
> > -EXPORT_SYMBOL(registered_fb);
> > -
> > int num_registered_fb __read_mostly;
> > +#if IS_ENABLED(CONFIG_OLPC_DCON)
> > +EXPORT_SYMBOL(registered_fb);
> > EXPORT_SYMBOL(num_registered_fb);
> > +#endif
> > +#define for_each_registered_fb(i) \
> > + for (i = 0; i < FB_MAX; i++) \
> > + if (!registered_fb[i]) {} else
> >
> > bool fb_center_logo __read_mostly;
> >
> > diff --git a/include/linux/fb.h b/include/linux/fb.h
> > index a8a00d2ba1f3..e236817502c2 100644
> > --- a/include/linux/fb.h
> > +++ b/include/linux/fb.h
> > @@ -622,16 +622,15 @@ extern int fb_get_color_depth(struct fb_var_screeninfo *var,
> > extern int fb_get_options(const char *name, char **option);
> > extern int fb_new_modelist(struct fb_info *info);
> >
> > +#if IS_ENABLED(CONFIG_OLPC_DCON)
> > extern struct fb_info *registered_fb[FB_MAX];
> > +
> > extern int num_registered_fb;
> > +#endif
> > extern bool fb_center_logo;
> > extern int fb_logo_count;
> > extern struct class *fb_class;
> >
> > -#define for_each_registered_fb(i) \
> > - for (i = 0; i < FB_MAX; i++) \
> > - if (!registered_fb[i]) {} else
> > -
> > static inline void lock_fb_info(struct fb_info *info)
> > {
> > mutex_lock(&info->lock);
> > --
> > 2.33.0
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 21/21] fbdev: Make registered_fb[] private to fbmem.c
@ 2022-02-08 20:56 ` Daniel Vetter
0 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-02-08 20:56 UTC (permalink / raw)
To: Sam Ravnborg
Cc: Daniel Vetter, DRI Development, linux-fbdev, Zheyu Ma, Xiyu Yang,
Jens Frederich, Tetsuo Handa, Intel Graphics Development,
linux-staging, LKML, Matthew Wilcox, Zhen Lei, Guenter Roeck,
Greg Kroah-Hartman, Alex Deucher, Daniel Vetter, Jon Nettleton,
Helge Deller
On Tue, Feb 08, 2022 at 08:00:38PM +0100, Sam Ravnborg wrote:
> Hi Daniel,
>
> On Mon, Jan 31, 2022 at 10:05:52PM +0100, Daniel Vetter wrote:
> > Well except when the olpc dcon fbdev driver is enabled, that thing
> > digs around in there in rather unfixable ways.
> >
> > Cc oldc_dcon maintainers as fyi.
> >
> > Cc: Jens Frederich <jfrederich@gmail.com>
> > Cc: Jon Nettleton <jon.nettleton@gmail.com>
> > Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > Cc: linux-staging@lists.linux.dev
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > Cc: Daniel Vetter <daniel@ffwll.ch>
> > Cc: Helge Deller <deller@gmx.de>
> > Cc: Matthew Wilcox <willy@infradead.org>
> > Cc: Sam Ravnborg <sam@ravnborg.org>
> > Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
> > Cc: Zhen Lei <thunder.leizhen@huawei.com>
> > Cc: Alex Deucher <alexander.deucher@amd.com>
> > Cc: Xiyu Yang <xiyuyang19@fudan.edu.cn>
> > Cc: linux-fbdev@vger.kernel.org
> > Cc: Zheyu Ma <zheyuma97@gmail.com>
> > Cc: Guenter Roeck <linux@roeck-us.net>
>
> with the build thingy fixed:
> Acked-by: Sam Ravnborg <sam@ravnborg.org>
>
> I do wonder if there is a more clean way to trigger a blank
> in the main fbdev driver from the olpc driver.
>
> The current hack is not nice and it would be good to see it gone.
Yeah this is just badly engineered. In drm we'd do this with the self
refresh helpers, which pretty much give you this exact functionality, but
in the helpers, while not randomly breaking actual visible behaviour of
the display driver.
Well ok the illusion is not perfect, since if the display is suspended the
next page flip will take a tad longer. But that's it.
I'll also add this to the TODO.
-Daniel
>
> Sam
>
> > ---
> > drivers/video/fbdev/core/fbmem.c | 8 ++++++--
> > include/linux/fb.h | 7 +++----
> > 2 files changed, 9 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
> > index 904ef1250677..dad6572942fa 100644
> > --- a/drivers/video/fbdev/core/fbmem.c
> > +++ b/drivers/video/fbdev/core/fbmem.c
> > @@ -48,10 +48,14 @@
> > static DEFINE_MUTEX(registration_lock);
> >
> > struct fb_info *registered_fb[FB_MAX] __read_mostly;
> > -EXPORT_SYMBOL(registered_fb);
> > -
> > int num_registered_fb __read_mostly;
> > +#if IS_ENABLED(CONFIG_OLPC_DCON)
> > +EXPORT_SYMBOL(registered_fb);
> > EXPORT_SYMBOL(num_registered_fb);
> > +#endif
> > +#define for_each_registered_fb(i) \
> > + for (i = 0; i < FB_MAX; i++) \
> > + if (!registered_fb[i]) {} else
> >
> > bool fb_center_logo __read_mostly;
> >
> > diff --git a/include/linux/fb.h b/include/linux/fb.h
> > index a8a00d2ba1f3..e236817502c2 100644
> > --- a/include/linux/fb.h
> > +++ b/include/linux/fb.h
> > @@ -622,16 +622,15 @@ extern int fb_get_color_depth(struct fb_var_screeninfo *var,
> > extern int fb_get_options(const char *name, char **option);
> > extern int fb_new_modelist(struct fb_info *info);
> >
> > +#if IS_ENABLED(CONFIG_OLPC_DCON)
> > extern struct fb_info *registered_fb[FB_MAX];
> > +
> > extern int num_registered_fb;
> > +#endif
> > extern bool fb_center_logo;
> > extern int fb_logo_count;
> > extern struct class *fb_class;
> >
> > -#define for_each_registered_fb(i) \
> > - for (i = 0; i < FB_MAX; i++) \
> > - if (!registered_fb[i]) {} else
> > -
> > static inline void lock_fb_info(struct fb_info *info)
> > {
> > mutex_lock(&info->lock);
> > --
> > 2.33.0
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [PATCH 21/21] fbdev: Make registered_fb[] private to fbmem.c
2022-02-08 14:04 ` Daniel Vetter
@ 2022-02-08 20:59 ` Daniel Vetter
-1 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-02-08 20:59 UTC (permalink / raw)
To: Geert Uytterhoeven, DRI Development, Intel Graphics Development,
Linux Fbdev development list, LKML, Jens Frederich,
Jon Nettleton, Greg Kroah-Hartman, linux-staging, Daniel Vetter,
Helge Deller, Matthew Wilcox, Sam Ravnborg, Tetsuo Handa,
Zhen Lei, Alex Deucher, Xiyu Yang, Zheyu Ma, Guenter Roeck
On Tue, Feb 08, 2022 at 03:04:51PM +0100, Daniel Vetter wrote:
> On Fri, Feb 04, 2022 at 09:30:56AM +0100, Geert Uytterhoeven wrote:
> > Hi Daniel,
> >
> > Thanks for your patch!
> >
> > On Tue, Feb 1, 2022 at 9:50 PM Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> > > Well except when the olpc dcon fbdev driver is enabled, that thing
> > > digs around in there in rather unfixable ways.
> >
> > Can't the actual frame buffer driver (which one?) used on olpc export
> > a pointer to its fb_info?
>
> Yeah that might be the right thing to do, I'll add that as a stagin TODO
> in the next iteration.
Well I tried to do that and noticed I've done that already in 2019:
commit af1440368837f19ac7d5dec05d929d91308f5a90
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Tue May 28 11:03:03 2019 +0200
staging/olpc_dcon: Add drm conversion to TODO
TODO already explains how this should be done correctly in drm. Well maybe
we should add that stitching the drivers together should be done with
component.c or something like that.
-Daniel
>
> >
> > > --- a/drivers/video/fbdev/core/fbmem.c
> > > +++ b/drivers/video/fbdev/core/fbmem.c
> > > @@ -48,10 +48,14 @@
> > > static DEFINE_MUTEX(registration_lock);
> > >
> > > struct fb_info *registered_fb[FB_MAX] __read_mostly;
> > > -EXPORT_SYMBOL(registered_fb);
> > > -
> > > int num_registered_fb __read_mostly;
> > > +#if IS_ENABLED(CONFIG_OLPC_DCON)
> >
> > CONFIG_FB_OLPC_DCON (everywhere), cfr. the build failure reported
> > by the robot.
>
> Yeah realized that too and fixed it locally.
>
> Cheers, Daniel
>
> >
> > 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
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 241+ messages in thread
* Re: [Intel-gfx] [PATCH 21/21] fbdev: Make registered_fb[] private to fbmem.c
@ 2022-02-08 20:59 ` Daniel Vetter
0 siblings, 0 replies; 241+ messages in thread
From: Daniel Vetter @ 2022-02-08 20:59 UTC (permalink / raw)
To: Geert Uytterhoeven, DRI Development, Intel Graphics Development,
Linux Fbdev development list, LKML, Jens Frederich,
Jon Nettleton, Greg Kroah-Hartman, linux-staging, Daniel Vetter,
Helge Deller, Matthew Wilcox, Sam Ravnborg, Tetsuo Handa,
Zhen Lei, Alex Deucher, Xiyu Yang, Zheyu Ma, Guenter Roeck
On Tue, Feb 08, 2022 at 03:04:51PM +0100, Daniel Vetter wrote:
> On Fri, Feb 04, 2022 at 09:30:56AM +0100, Geert Uytterhoeven wrote:
> > Hi Daniel,
> >
> > Thanks for your patch!
> >
> > On Tue, Feb 1, 2022 at 9:50 PM Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> > > Well except when the olpc dcon fbdev driver is enabled, that thing
> > > digs around in there in rather unfixable ways.
> >
> > Can't the actual frame buffer driver (which one?) used on olpc export
> > a pointer to its fb_info?
>
> Yeah that might be the right thing to do, I'll add that as a stagin TODO
> in the next iteration.
Well I tried to do that and noticed I've done that already in 2019:
commit af1440368837f19ac7d5dec05d929d91308f5a90
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Tue May 28 11:03:03 2019 +0200
staging/olpc_dcon: Add drm conversion to TODO
TODO already explains how this should be done correctly in drm. Well maybe
we should add that stitching the drivers together should be done with
component.c or something like that.
-Daniel
>
> >
> > > --- a/drivers/video/fbdev/core/fbmem.c
> > > +++ b/drivers/video/fbdev/core/fbmem.c
> > > @@ -48,10 +48,14 @@
> > > static DEFINE_MUTEX(registration_lock);
> > >
> > > struct fb_info *registered_fb[FB_MAX] __read_mostly;
> > > -EXPORT_SYMBOL(registered_fb);
> > > -
> > > int num_registered_fb __read_mostly;
> > > +#if IS_ENABLED(CONFIG_OLPC_DCON)
> >
> > CONFIG_FB_OLPC_DCON (everywhere), cfr. the build failure reported
> > by the robot.
>
> Yeah realized that too and fixed it locally.
>
> Cheers, Daniel
>
> >
> > 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
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 241+ messages in thread
end of thread, other threads:[~2022-02-08 22:37 UTC | newest]
Thread overview: 241+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-01-31 21:05 [PATCH 00/21] some fbcon patches, mostly locking Daniel Vetter
2022-01-31 21:05 ` [Intel-gfx] " Daniel Vetter
2022-01-31 21:05 ` Daniel Vetter
2022-01-31 21:05 ` [PATCH 01/21] MAINTAINERS: Add entry for fbdev core Daniel Vetter
2022-01-31 21:05 ` [Intel-gfx] " Daniel Vetter
2022-01-31 21:05 ` Daniel Vetter
2022-02-01 10:19 ` Thomas Zimmermann
2022-02-01 10:19 ` [Intel-gfx] " Thomas Zimmermann
2022-02-01 10:19 ` Thomas Zimmermann
2022-02-01 10:45 ` Greg Kroah-Hartman
2022-02-01 10:45 ` [Intel-gfx] " Greg Kroah-Hartman
2022-02-01 10:45 ` Greg Kroah-Hartman
2022-02-01 10:32 ` Helge Deller
2022-02-01 10:32 ` [Intel-gfx] " Helge Deller
2022-02-01 10:32 ` Helge Deller
2022-02-01 14:01 ` Javier Martinez Canillas
2022-02-01 14:01 ` [Intel-gfx] " Javier Martinez Canillas
2022-02-01 14:01 ` Javier Martinez Canillas
2022-02-01 14:47 ` Jani Nikula
2022-02-01 14:47 ` Jani Nikula
2022-02-01 14:47 ` [Intel-gfx] " Jani Nikula
2022-02-01 14:54 ` Geert Uytterhoeven
2022-02-01 14:54 ` [Intel-gfx] " Geert Uytterhoeven
2022-02-01 14:54 ` Geert Uytterhoeven
2022-02-01 20:47 ` Dave Airlie
2022-02-01 20:47 ` [Intel-gfx] " Dave Airlie
2022-02-01 20:47 ` Dave Airlie
2022-02-02 11:10 ` Daniel Stone
2022-02-02 11:10 ` Daniel Stone
2022-02-02 11:10 ` [Intel-gfx] " Daniel Stone
2022-02-02 11:18 ` Tomi Valkeinen
2022-02-02 11:18 ` [Intel-gfx] " Tomi Valkeinen
2022-02-02 11:18 ` Tomi Valkeinen
2022-02-02 11:31 ` Maxime Ripard
2022-02-02 11:31 ` [Intel-gfx] " Maxime Ripard
2022-02-02 11:31 ` Maxime Ripard
2022-02-02 13:48 ` Alex Deucher
2022-02-02 13:48 ` [Intel-gfx] " Alex Deucher
2022-02-02 13:48 ` Alex Deucher
2022-02-03 20:25 ` Sam Ravnborg
2022-02-03 20:25 ` Sam Ravnborg
2022-02-03 20:25 ` [Intel-gfx] " Sam Ravnborg
2022-02-08 14:12 ` Daniel Vetter
2022-02-08 14:12 ` [Intel-gfx] " Daniel Vetter
2022-02-08 14:12 ` Daniel Vetter
2022-01-31 21:05 ` [PATCH 02/21] fbcon: Resurrect fbcon accelerated scrolling code Daniel Vetter
2022-01-31 21:05 ` [Intel-gfx] " Daniel Vetter
2022-01-31 21:05 ` Daniel Vetter
2022-01-31 21:05 ` [PATCH 03/21] fbcon: Restore fbcon scrolling acceleration Daniel Vetter
2022-01-31 21:05 ` [Intel-gfx] " Daniel Vetter
2022-01-31 21:05 ` Daniel Vetter
2022-02-01 10:16 ` Helge Deller
2022-02-01 10:16 ` [Intel-gfx] " Helge Deller
2022-02-01 10:16 ` Helge Deller
2022-02-01 10:17 ` Helge Deller
2022-02-01 10:17 ` [Intel-gfx] " Helge Deller
2022-02-01 10:17 ` Helge Deller
2022-02-01 10:36 ` Daniel Vetter
2022-02-01 10:36 ` [Intel-gfx] " Daniel Vetter
2022-02-01 10:36 ` Daniel Vetter
2022-02-01 11:01 ` Helge Deller
2022-02-01 11:01 ` [Intel-gfx] " Helge Deller
2022-02-01 11:01 ` Helge Deller
2022-02-01 13:45 ` Daniel Vetter
2022-02-01 13:45 ` [Intel-gfx] " Daniel Vetter
2022-02-01 13:45 ` Daniel Vetter
2022-02-01 14:52 ` Helge Deller
2022-02-01 14:52 ` [Intel-gfx] " Helge Deller
2022-02-01 14:52 ` Helge Deller
2022-02-01 16:30 ` Daniel Vetter
2022-02-01 16:30 ` [Intel-gfx] " Daniel Vetter
2022-02-01 16:30 ` Daniel Vetter
2022-01-31 21:05 ` [PATCH 04/21] fbcon: delete a few unneeded forward decl Daniel Vetter
2022-01-31 21:05 ` [Intel-gfx] " Daniel Vetter
2022-01-31 21:05 ` Daniel Vetter
2022-02-03 20:30 ` Sam Ravnborg
2022-02-03 20:30 ` Sam Ravnborg
2022-02-03 20:30 ` [Intel-gfx] " Sam Ravnborg
2022-02-04 10:00 ` Geert Uytterhoeven
2022-02-04 10:00 ` [Intel-gfx] " Geert Uytterhoeven
2022-02-04 10:00 ` Geert Uytterhoeven
2022-01-31 21:05 ` [PATCH 05/21] fbcon: Introduce wrapper for console->fb_info lookup Daniel Vetter
2022-01-31 21:05 ` [Intel-gfx] " Daniel Vetter
2022-01-31 21:05 ` Daniel Vetter
2022-02-03 21:25 ` Sam Ravnborg
2022-02-03 21:25 ` Sam Ravnborg
2022-02-03 21:25 ` [Intel-gfx] " Sam Ravnborg
2022-01-31 21:05 ` [PATCH 06/21] fbcon: delete delayed loading code Daniel Vetter
2022-01-31 21:05 ` [Intel-gfx] " Daniel Vetter
2022-01-31 21:05 ` Daniel Vetter
2022-02-03 20:45 ` Sam Ravnborg
2022-02-03 20:45 ` Sam Ravnborg
2022-02-03 20:45 ` [Intel-gfx] " Sam Ravnborg
2022-02-08 13:42 ` Daniel Vetter
2022-02-08 13:42 ` [Intel-gfx] " Daniel Vetter
2022-02-08 13:42 ` Daniel Vetter
2022-02-08 18:09 ` Sam Ravnborg
2022-02-08 18:09 ` [Intel-gfx] " Sam Ravnborg
2022-01-31 21:05 ` [PATCH 07/21] fbdev/sysfs: Fix locking Daniel Vetter
2022-01-31 21:05 ` [Intel-gfx] " Daniel Vetter
2022-01-31 21:05 ` Daniel Vetter
2022-02-03 21:27 ` Sam Ravnborg
2022-02-03 21:27 ` Sam Ravnborg
2022-02-03 21:27 ` [Intel-gfx] " Sam Ravnborg
2022-01-31 21:05 ` [PATCH 08/21] fbcon: Use delayed work for cursor Daniel Vetter
2022-01-31 21:05 ` [Intel-gfx] " Daniel Vetter
2022-01-31 21:05 ` Daniel Vetter
2022-01-31 21:05 ` [PATCH 09/21] fbcon: Replace FBCON_FLAGS_INIT with a boolean Daniel Vetter
2022-01-31 21:05 ` [Intel-gfx] " Daniel Vetter
2022-01-31 21:05 ` Daniel Vetter
2022-02-01 10:37 ` Thomas Zimmermann
2022-02-01 10:37 ` [Intel-gfx] " Thomas Zimmermann
2022-02-01 10:37 ` Thomas Zimmermann
2022-02-03 13:47 ` Geert Uytterhoeven
2022-02-03 13:47 ` [Intel-gfx] " Geert Uytterhoeven
2022-02-03 13:47 ` Geert Uytterhoeven
2022-02-03 21:30 ` Sam Ravnborg
2022-02-03 21:30 ` Sam Ravnborg
2022-02-03 21:30 ` [Intel-gfx] " Sam Ravnborg
2022-01-31 21:05 ` [PATCH 10/21] fb: Delete fb_info->queue Daniel Vetter
2022-01-31 21:05 ` Daniel Vetter
2022-01-31 21:05 ` [Intel-gfx] " Daniel Vetter
2022-02-03 21:31 ` Sam Ravnborg
2022-02-03 21:31 ` Sam Ravnborg
2022-02-03 21:31 ` [Intel-gfx] " Sam Ravnborg
2022-02-08 13:46 ` Daniel Vetter
2022-02-08 13:46 ` [Intel-gfx] " Daniel Vetter
2022-02-08 13:46 ` Daniel Vetter
2022-02-08 18:22 ` Sam Ravnborg
2022-02-08 18:22 ` [Intel-gfx] " Sam Ravnborg
2022-01-31 21:05 ` [PATCH 11/21] fbcon: Extract fbcon_open/release helpers Daniel Vetter
2022-01-31 21:05 ` Daniel Vetter
2022-01-31 21:05 ` [Intel-gfx] " Daniel Vetter
2022-02-03 21:15 ` Sam Ravnborg
2022-02-03 21:15 ` Sam Ravnborg
2022-02-03 21:15 ` [Intel-gfx] " Sam Ravnborg
2022-02-03 21:32 ` Sam Ravnborg
2022-02-03 21:32 ` Sam Ravnborg
2022-02-08 13:48 ` Daniel Vetter
2022-02-08 13:48 ` [Intel-gfx] " Daniel Vetter
2022-02-08 13:48 ` Daniel Vetter
2022-02-08 18:24 ` Sam Ravnborg
2022-02-08 18:24 ` [Intel-gfx] " Sam Ravnborg
2022-02-08 19:51 ` Daniel Vetter
2022-02-08 19:51 ` Daniel Vetter
2022-02-08 19:51 ` Daniel Vetter
2022-01-31 21:05 ` [Intel-gfx] [PATCH 12/21] fbcon: Ditch error handling for con2fb_release_oldinfo Daniel Vetter
2022-01-31 21:05 ` Daniel Vetter
2022-01-31 21:05 ` Daniel Vetter
2022-02-03 21:16 ` Sam Ravnborg
2022-02-03 21:16 ` Sam Ravnborg
2022-02-03 21:16 ` [Intel-gfx] " Sam Ravnborg
2022-01-31 21:05 ` [PATCH 13/21] fbcon: move more common code into fb_open() Daniel Vetter
2022-01-31 21:05 ` Daniel Vetter
2022-01-31 21:05 ` [Intel-gfx] " Daniel Vetter
2022-01-31 23:31 ` kernel test robot
2022-01-31 23:31 ` kernel test robot
2022-01-31 23:31 ` kernel test robot
2022-02-04 19:35 ` Sam Ravnborg
2022-02-04 19:35 ` Sam Ravnborg
2022-02-04 19:35 ` [Intel-gfx] " Sam Ravnborg
2022-02-08 13:53 ` Daniel Vetter
2022-02-08 13:53 ` [Intel-gfx] " Daniel Vetter
2022-02-08 13:53 ` Daniel Vetter
2022-02-08 18:25 ` Sam Ravnborg
2022-02-08 18:25 ` [Intel-gfx] " Sam Ravnborg
2022-01-31 21:05 ` [Intel-gfx] [PATCH 14/21] fbcon: use lock_fb_info in fbcon_open/release Daniel Vetter
2022-01-31 21:05 ` Daniel Vetter
2022-01-31 21:05 ` Daniel Vetter
2022-02-04 19:39 ` Sam Ravnborg
2022-02-04 19:39 ` Sam Ravnborg
2022-02-04 19:39 ` [Intel-gfx] " Sam Ravnborg
2022-01-31 21:05 ` [PATCH 15/21] fbcon: Consistently protect deferred_takeover with console_lock() Daniel Vetter
2022-01-31 21:05 ` Daniel Vetter
2022-01-31 21:05 ` [Intel-gfx] " Daniel Vetter
2022-02-04 19:45 ` Sam Ravnborg
2022-02-04 19:45 ` Sam Ravnborg
2022-02-04 19:45 ` [Intel-gfx] " Sam Ravnborg
2022-01-31 21:05 ` [PATCH 16/21] fbcon: Move console_lock for register/unlink/unregister Daniel Vetter
2022-01-31 21:05 ` Daniel Vetter
2022-01-31 21:05 ` [Intel-gfx] " Daniel Vetter
2022-02-04 19:54 ` Sam Ravnborg
2022-02-04 19:54 ` Sam Ravnborg
2022-02-04 19:54 ` [Intel-gfx] " Sam Ravnborg
2022-02-08 13:56 ` Daniel Vetter
2022-02-08 13:56 ` [Intel-gfx] " Daniel Vetter
2022-02-08 13:56 ` Daniel Vetter
2022-01-31 21:05 ` [PATCH 17/21] fbcon: Move more code into fbcon_release Daniel Vetter
2022-01-31 21:05 ` Daniel Vetter
2022-01-31 21:05 ` [Intel-gfx] " Daniel Vetter
2022-02-04 19:55 ` Sam Ravnborg
2022-02-04 19:55 ` Sam Ravnborg
2022-02-04 19:55 ` [Intel-gfx] " Sam Ravnborg
2022-01-31 21:05 ` [PATCH 18/21] fbcon: untangle fbcon_exit Daniel Vetter
2022-01-31 21:05 ` Daniel Vetter
2022-01-31 21:05 ` [Intel-gfx] " Daniel Vetter
2022-02-04 20:06 ` Sam Ravnborg
2022-02-04 20:06 ` Sam Ravnborg
2022-02-04 20:06 ` [Intel-gfx] " Sam Ravnborg
2022-02-08 13:58 ` Daniel Vetter
2022-02-08 13:58 ` [Intel-gfx] " Daniel Vetter
2022-02-08 13:58 ` Daniel Vetter
2022-02-08 18:27 ` Sam Ravnborg
2022-02-08 18:27 ` [Intel-gfx] " Sam Ravnborg
2022-01-31 21:05 ` [PATCH 19/21] fbcon: Maintain a private array of fb_info Daniel Vetter
2022-01-31 21:05 ` Daniel Vetter
2022-01-31 21:05 ` [Intel-gfx] " Daniel Vetter
2022-02-04 20:15 ` Sam Ravnborg
2022-02-04 20:15 ` Sam Ravnborg
2022-02-04 20:15 ` [Intel-gfx] " Sam Ravnborg
2022-02-08 14:03 ` Daniel Vetter
2022-02-08 14:03 ` [Intel-gfx] " Daniel Vetter
2022-02-08 14:03 ` Daniel Vetter
2022-02-08 18:55 ` Sam Ravnborg
2022-02-08 18:55 ` [Intel-gfx] " Sam Ravnborg
2022-01-31 21:05 ` [PATCH 20/21] Revert "fbdev: Prevent probing generic drivers if a FB is already registered" Daniel Vetter
2022-01-31 21:05 ` Daniel Vetter
2022-01-31 21:05 ` [Intel-gfx] " Daniel Vetter
2022-01-31 21:05 ` [PATCH 21/21] fbdev: Make registered_fb[] private to fbmem.c Daniel Vetter
2022-01-31 21:05 ` [Intel-gfx] " Daniel Vetter
2022-01-31 21:05 ` Daniel Vetter
2022-02-01 8:13 ` [Intel-gfx] " kernel test robot
2022-02-01 8:13 ` kernel test robot
2022-02-01 8:13 ` kernel test robot
2022-02-04 8:30 ` Geert Uytterhoeven
2022-02-04 8:30 ` [Intel-gfx] " Geert Uytterhoeven
2022-02-04 8:30 ` Geert Uytterhoeven
2022-02-08 14:04 ` [Intel-gfx] " Daniel Vetter
2022-02-08 14:04 ` Daniel Vetter
2022-02-08 14:04 ` Daniel Vetter
2022-02-08 20:59 ` Daniel Vetter
2022-02-08 20:59 ` [Intel-gfx] " Daniel Vetter
2022-02-08 19:00 ` Sam Ravnborg
2022-02-08 19:00 ` Sam Ravnborg
2022-02-08 19:00 ` [Intel-gfx] " Sam Ravnborg
2022-02-08 20:56 ` Daniel Vetter
2022-02-08 20:56 ` Daniel Vetter
2022-02-08 20:56 ` [Intel-gfx] " Daniel Vetter
2022-01-31 21:16 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for some fbcon patches, mostly locking Patchwork
2022-01-31 21:19 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2022-01-31 21:51 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.