| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
These are actually fbcon ioctls which just happen to be exposed
through /dev/fb*. They completely ignore which fb_info they're called
on, and I think the userspace tool even hardcodes to /dev/fb0.
Hence just forward the entire thing to fbcon.c wholesale.
Note that this patch drops the fb_lock/unlock on the set side. Since
the ioctl can operate on any fb (as passed in through
con2fb.framebuffer) this is bogus. Also note that fbcon.c in general
never calls fb_lock on anything, so this has been badly broken
already.
With this the last user of the fbcon notifier callback is gone, and we
can garbage collect that too.
v2: add missing uaccess.h include (alpha fails to compile otherwise),
reported by kbuild.
v3: Remember to also drop the #defines (Maarten)
v4: Add the static inline to dummy functions.
Signed-off-by: Daniel Vetter <[email protected]>
Reviewed-by: Sam Ravnborg <[email protected]>
Reviewed-by: Maarten Lankhorst <[email protected]>
Cc: Maarten Lankhorst <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: Bartlomiej Zolnierkiewicz <[email protected]>
Cc: Hans de Goede <[email protected]>
Cc: Yisheng Xie <[email protected]>
Cc: "Michał Mirosław" <[email protected]>
Cc: Peter Rosin <[email protected]>
Cc: Mikulas Patocka <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
While at it, clean up the interface a bit and push the console locking
into fbcon.c.
v2: Remove now outdated comment (Lukas).
v3: Forgot to add static inline to the dummy function.
Acked-by: Lukas Wunner <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Reviewed-by: Sam Ravnborg <[email protected]>
Reviewed-by: Maarten Lankhorst <[email protected]>
Cc: Lukas Wunner <[email protected]>
Cc: David Airlie <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: Maarten Lankhorst <[email protected]>
Cc: Maxime Ripard <[email protected]>
Cc: Sean Paul <[email protected]>
Cc: Bartlomiej Zolnierkiewicz <[email protected]>
Cc: Hans de Goede <[email protected]>
Cc: Yisheng Xie <[email protected]>
Cc: [email protected]
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Create a new wrapper function for this, feels like there's some
refactoring room here between the two modes.
v2: backlight notifier is also interested in the mode change event,
it calls lcd->set_mode, of which there are 3 implementations. Thanks
to Maarten for spotting this. So we keep that. We can ditch the differentiation
between mode change and all mode changes (because backlight notifier
doesn't care), and we can drop the FBINFO_MISC_USEREVENT stuff too,
because that's just to prevent recursion between fbmem.c and fbcon.c.
While at it flatten the control flow a bit.
v3: Need to add a static inline to the dummy function.
v4: Add missing #include <fbcon.h> to sh_mob (Sam).
Cc: Sam Ravnborg <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Reviewed-by: Sam Ravnborg <[email protected]>
Reviewed-by: Maarten Lankhorst <[email protected]>
Acked-by: Daniel Thompson <[email protected]>
Cc: Maarten Lankhorst <[email protected]>
Cc: Lee Jones <[email protected]>
Cc: Daniel Thompson <[email protected]>
Cc: Jingoo Han <[email protected]>
Cc: Bartlomiej Zolnierkiewicz <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: Hans de Goede <[email protected]>
Cc: Yisheng Xie <[email protected]>
Cc: "Michał Mirosław" <[email protected]>
Cc: Peter Rosin <[email protected]>
Cc: Mikulas Patocka <[email protected]>
Cc: [email protected]
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
This reverts commit 994efacdf9a087b52f71e620b58dfa526b0cf928.
The justification is that if hw blanking fails (i.e. fbops->fb_blank)
fails, then we still want to shut down the backlight. Which is exactly
_not_ what fb_blank() does and so rather inconsistent if we end up
with different behaviour between fbcon and direct fbdev usage. Given
that the entire notifier maze is getting in the way anyway I figured
it's simplest to revert this not well justified commit.
v2: Add static inline to the dummy version.
Cc: Richard Purdie <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Reviewed-by: Sam Ravnborg <[email protected]>
Reviewed-by: Maarten Lankhorst <[email protected]>
Acked-by: Daniel Thompson <[email protected]>
Cc: Lee Jones <[email protected]>
Cc: Daniel Thompson <[email protected]>
Cc: Jingoo Han <[email protected]>
Cc: Bartlomiej Zolnierkiewicz <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: Hans de Goede <[email protected]>
Cc: Yisheng Xie <[email protected]>
Cc: [email protected]
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Pretty simple case really.
v2: Forgot to remove a break;
v3: Add static inline to the dummy versions.
Signed-off-by: Daniel Vetter <[email protected]>
Reviewed-by: Sam Ravnborg <[email protected]>
Reviewed-by: Maarten Lankhorst <[email protected]>
Cc: Bartlomiej Zolnierkiewicz <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: Hans de Goede <[email protected]>
Cc: "Steven Rostedt (VMware)" <[email protected]>
Cc: Prarit Bhargava <[email protected]>
Cc: Kees Cook <[email protected]>
Cc: Yisheng Xie <[email protected]>
Cc: "Michał Mirosław" <[email protected]>
Cc: Peter Rosin <[email protected]>
Cc: Mikulas Patocka <[email protected]>
Cc: [email protected]
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
I'm not entirely clear on what new_modelist actually does, it seems
exclusively for a sysfs interface. Which in the end does amount to a
normal fb_set_par to check the mode, but then takes a different path
in both fbmem.c and fbcon.c.
I have no idea why these 2 paths are different, but then I also don't
really want to find out. So just do the simple conversion to a direct
function call.
v2: static inline for the dummy versions, I forgot.
Signed-off-by: Daniel Vetter <[email protected]>
Reviewed-by: Sam Ravnborg <[email protected]>
Reviewed-by: Maarten Lankhorst <[email protected]>
Cc: Bartlomiej Zolnierkiewicz <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: Hans de Goede <[email protected]>
Cc: Mikulas Patocka <[email protected]>
Cc: Sergey Senozhatsky <[email protected]>
Cc: Kees Cook <[email protected]>
Cc: Peter Rosin <[email protected]>
Cc: Yisheng Xie <[email protected]>
Cc: "Michał Mirosław" <[email protected]>
Cc: [email protected]
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
With the sh_mobile notifier removed we can just directly call the
fbcon code here.
v2: Remove now unused local variable.
v3: fixup !CONFIG_FRAMEBUFFER_CONSOLE, noticed by kbuild
Signed-off-by: Daniel Vetter <[email protected]>
Reviewed-by: Sam Ravnborg <[email protected]>
Reviewed-by: Maarten Lankhorst <[email protected]>
Cc: Bartlomiej Zolnierkiewicz <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: Hans de Goede <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: Prarit Bhargava <[email protected]>
Cc: Kees Cook <[email protected]>
Cc: Konstantin Khorenko <[email protected]>
Cc: Yisheng Xie <[email protected]>
Cc: "Michał Mirosław" <[email protected]>
Cc: Peter Rosin <[email protected]>
Cc: Mikulas Patocka <[email protected]>
Cc: [email protected]
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Also remove the error return value. That's all errors for either
driver bugs (trying to unbind something that isn't bound), or errors
of the new driver that will take over.
There's nothing the outgoing driver can do about this anyway, so
switch over to void.
Signed-off-by: Daniel Vetter <[email protected]>
Reviewed-by: Sam Ravnborg <[email protected]>
Reviewed-by: Maarten Lankhorst <[email protected]>
Cc: Bartlomiej Zolnierkiewicz <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: Hans de Goede <[email protected]>
Cc: Sergey Senozhatsky <[email protected]>
Cc: Peter Rosin <[email protected]>
Cc: Kees Cook <[email protected]>
Cc: Konstantin Khorenko <[email protected]>
Cc: Yisheng Xie <[email protected]>
Cc: "Michał Mirosław" <[email protected]>
Cc: Mikulas Patocka <[email protected]>
Cc: Thomas Zimmermann <[email protected]>
Cc: [email protected]
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
With
commit 6104c37094e729f3d4ce65797002112735d49cd1
Author: Daniel Vetter <[email protected]>
Date: Tue Aug 1 17:32:07 2017 +0200
fbcon: Make fbcon a built-time depency for fbdev
we have a static dependency between fbcon and fbdev, and we can
replace the indirection through the notifier chain with a function
call.
v2: Sam Ravnborg noticed that mach-pxa/am200epd.c has a notifier too,
and listens to this.
...
Looking at the code it seems to wait for some fb to show up, so that
it can get the framebuffer base address from the fb_info struct. I
suspect his is some firmware fbdev. Then it uses that information to
let the real fbdev driver (metronomefb.c by the looks) get at the
framebuffer memory.
This doesn't looke like it's easy to fix (except by deleting the
entire thing, seems untouched since 2008, we might be able to get away
with that), so let's just stuff a few #ifdef into fb.h and fbmem.c and
cry over them for a bit.
Signed-off-by: Daniel Vetter <[email protected]>
Reviewed-by: Sam Ravnborg <[email protected]>
Reviewed-by: Maarten Lankhorst <[email protected]>
Cc: Bartlomiej Zolnierkiewicz <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: Hans de Goede <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: "Noralf Trønnes" <[email protected]>
Cc: Yisheng Xie <[email protected]>
Cc: Peter Rosin <[email protected]>
Cc: "Michał Mirosław" <[email protected]>
Cc: Thomas Zimmermann <[email protected]>
Cc: Mikulas Patocka <[email protected]>
Cc: [email protected]
Cc: Daniel Mack <[email protected]>
Cc: Haojian Zhuang <[email protected]>
Cc: Robert Jarzmik <[email protected]>
Cc: Konstantin Khorenko <[email protected]>
Cc: Prarit Bhargava <[email protected]>
Cc: Gerd Hoffmann <[email protected]>
Cc: Steve Sakoman <[email protected]>
Cc: Steve Sakoman <[email protected]>
Cc: [email protected]
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
The newly introduced fb_console_init/exit declarations have a
dummy alternative that is marked 'static' in the header but not
inline, leading to a warning whenever the header gets included:
In file included from drivers/video/fbdev/core/fbmem.c:35:0:
include/linux/fbcon.h:9:13: error: 'fb_console_exit' defined but not used [-Werror=unused-function]
This adds the intended 'inline'.
Fixes: 6104c37094e7 ("fbcon: Make fbcon a built-time depency for fbdev")
Signed-off-by: Arnd Bergmann <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Cc: Sean Paul <[email protected]>
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
|
|
There's a bunch of folks who're trying to make printk less
contended and faster, but there's a problem: printk uses the
console_lock, and the console lock has become the BKL for all things
fbdev/fbcon, which in turn pulled in half the drm subsystem under that
lock. That's awkward.
There reasons for that is probably just a historical accident:
- fbcon is a runtime option of fbdev, i.e. at runtime you can pick
whether your fbdev driver instances are used as kernel consoles.
Unfortunately this wasn't implemented with some module option, but
through some module loading magic: As long as you don't load
fbcon.ko, there's no fbdev console support, but loading it (in any
order wrt fbdev drivers) will create console instances for all fbdev
drivers.
- This was implemented through a notifier chain. fbcon.ko enumerates
all fbdev instances at load time and also registers itself as
listener in the fbdev notifier. The fbdev core tries to register new
fbdev instances with fbcon using the notifier.
- On top of that the modifier chain is also used at runtime by the
fbdev subsystem to e.g. control backlights for panels.
- The problem is that the notifier puts a mutex locking context
between fbdev and fbcon, which mixes up the locking contexts for
both the runtime usage and the register time usage to notify fbcon.
And at runtime fbcon (through the fbdev core) might call into the
notifier from a printk critical section while console_lock is held.
- This means console_lock must be an outer lock for the entire fbdev
subsystem, which also means it must be acquired when registering a
new framebuffer driver as the outermost lock since we might call
into fbcon (through the notifier) which would result in a locking
inversion if fbcon would acquire the console_lock from its notifier
callback (which it needs to register the console).
- console_lock can be held anywhere, since printk can be called
anywhere, and through the above story, plus drm/kms being an fbdev
driver, we pull in a shocking amount of locking hiercharchy
underneath the console_lock. Which makes cleaning up printk really
hard (not even splitting console_lock into an rwsem is all that
useful due to this).
There's various ways to address this, but the cleanest would be to
make fbcon a compile-time option, where fbdev directly calls the fbcon
register functions from register_framebuffer, or dummy static inline
versions if fbcon is disabled. Maybe augmented with a runtime knob to
disable fbcon, if that's needed (for debugging perhaps).
But this could break some users who rely on the magic "loading
fbcon.ko enables/disables fbdev framebuffers at runtime" thing, even
if that's unlikely. Hence we must be careful:
1. Create a compile-time dependency between fbcon and fbdev in the
least minimal way. This is what this patch does.
2. Wait at least 1 year to give possible users time to scream about
how we broke their setup. Unlikely, since all distros make fbcon
compile-in, and embedded platforms only compile stuff they know they
need anyway. But still.
3. Convert the notifier to direct functions calls, with dummy static
inlines if fbcon is disabled. We'll still need the fb notifier for the
other uses (like backlights), but we can probably move it into the fb
core (atm it must be built-into vmlinux).
4. Push console_lock down the call-chain, until it is down in
console_register again.
5. Finally start to clean up and rework the printk/console locking.
For context of this saga see
commit 50e244cc793d511b86adea24972f3a7264cae114
Author: Alan Cox <[email protected]>
Date: Fri Jan 25 10:28:15 2013 +1000
fb: rework locking to fix lock ordering on takeover
plus the pile of commits on top that tried to make this all work
without terminally upsetting lockdep. We've uncovered all this when
console_lock lockdep annotations where added in
commit daee779718a319ff9f83e1ba3339334ac650bb22
Author: Daniel Vetter <[email protected]>
Date: Sat Sep 22 19:52:11 2012 +0200
console: implement lockdep support for console_lock
On the patch itself:
- Switch CONFIG_FRAMEBUFFER_CONSOLE to be a boolean, using the overall
CONFIG_FB tristate to decided whether it should be a module or
built-in.
- At first I thought I could force the build depency with just a dummy
symbol that fbcon.ko exports and fb.ko uses. But that leads to a
module depency cycle (it works fine when built-in).
Since this tight binding is the entire goal the simplest solution is
to move all the fbcon modules (and there's a bunch of optinal
source-files which are each modules of their own, for no good
reason) into the overall fb.ko core module. That's a bit more than
what I would have liked to do in this patch, but oh well.
Signed-off-by: Daniel Vetter <[email protected]>
Cc: Alan Cox <[email protected]>
Cc: Sergey Senozhatsky <[email protected]>
Cc: Steven Rostedt <[email protected]>
Reviewed-by: Sean Paul <[email protected]>
Signed-off-by: Bartlomiej Zolnierkiewicz <[email protected]>
|