2005-04-16 22:20:36 +00:00
|
|
|
/*
|
|
|
|
* linux/drivers/video/fbmem.c
|
|
|
|
*
|
|
|
|
* Copyright (C) 1994 Martin Schaller
|
|
|
|
*
|
|
|
|
* 2001 - Documented with DocBook
|
|
|
|
* - Brad Douglas <brad@neruo.com>
|
|
|
|
*
|
|
|
|
* This file is subject to the terms and conditions of the GNU General Public
|
|
|
|
* License. See the file COPYING in the main directory of this archive
|
|
|
|
* for more details.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/console.h>
|
2023-09-07 08:52:06 +00:00
|
|
|
#include <linux/export.h>
|
2007-07-17 11:05:27 +00:00
|
|
|
#include <linux/fb.h>
|
fbcon: Make fbcon a built-time depency for fbdev
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 <alan@linux.intel.com>
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 <daniel.vetter@ffwll.ch>
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 <daniel.vetter@intel.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
2017-08-01 15:32:07 +00:00
|
|
|
#include <linux/fbcon.h>
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2022-11-11 13:30:24 +00:00
|
|
|
#include <video/nomodeset.h>
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2023-06-13 11:07:09 +00:00
|
|
|
#include "fb_internal.h"
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
/*
|
|
|
|
* Frame buffer device initialization and setup routines
|
|
|
|
*/
|
|
|
|
|
|
|
|
#define FBPIXMAPSIZE (1024 * 8)
|
|
|
|
|
2023-06-13 11:07:12 +00:00
|
|
|
struct class *fb_class;
|
|
|
|
|
2023-06-13 11:07:10 +00:00
|
|
|
DEFINE_MUTEX(registration_lock);
|
2006-12-08 10:40:29 +00:00
|
|
|
struct fb_info *registered_fb[FB_MAX] __read_mostly;
|
|
|
|
int num_registered_fb __read_mostly;
|
2022-07-25 07:54:00 +00:00
|
|
|
#define for_each_registered_fb(i) \
|
|
|
|
for (i = 0; i < FB_MAX; i++) \
|
|
|
|
if (!registered_fb[i]) {} else
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2023-06-13 11:07:11 +00:00
|
|
|
struct fb_info *get_fb_info(unsigned int idx)
|
2011-05-11 21:49:36 +00:00
|
|
|
{
|
|
|
|
struct fb_info *fb_info;
|
|
|
|
|
|
|
|
if (idx >= FB_MAX)
|
|
|
|
return ERR_PTR(-ENODEV);
|
|
|
|
|
|
|
|
mutex_lock(®istration_lock);
|
|
|
|
fb_info = registered_fb[idx];
|
|
|
|
if (fb_info)
|
2021-07-19 05:59:45 +00:00
|
|
|
refcount_inc(&fb_info->count);
|
2011-05-11 21:49:36 +00:00
|
|
|
mutex_unlock(®istration_lock);
|
|
|
|
|
|
|
|
return fb_info;
|
|
|
|
}
|
|
|
|
|
2023-06-13 11:07:11 +00:00
|
|
|
void put_fb_info(struct fb_info *fb_info)
|
2011-05-11 21:49:36 +00:00
|
|
|
{
|
2021-07-19 05:59:45 +00:00
|
|
|
if (!refcount_dec_and_test(&fb_info->count))
|
2011-05-11 21:49:36 +00:00
|
|
|
return;
|
|
|
|
if (fb_info->fbops->fb_destroy)
|
|
|
|
fb_info->fbops->fb_destroy(fb_info);
|
|
|
|
}
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
/*
|
|
|
|
* Helpers
|
|
|
|
*/
|
|
|
|
|
2005-09-09 20:04:37 +00:00
|
|
|
int fb_get_color_depth(struct fb_var_screeninfo *var,
|
|
|
|
struct fb_fix_screeninfo *fix)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2005-09-09 20:04:37 +00:00
|
|
|
int depth = 0;
|
|
|
|
|
|
|
|
if (fix->visual == FB_VISUAL_MONO01 ||
|
|
|
|
fix->visual == FB_VISUAL_MONO10)
|
|
|
|
depth = 1;
|
|
|
|
else {
|
|
|
|
if (var->green.length == var->blue.length &&
|
|
|
|
var->green.length == var->red.length &&
|
|
|
|
var->green.offset == var->blue.offset &&
|
|
|
|
var->green.offset == var->red.offset)
|
|
|
|
depth = var->green.length;
|
|
|
|
else
|
|
|
|
depth = var->green.length + var->red.length +
|
|
|
|
var->blue.length;
|
|
|
|
}
|
|
|
|
|
|
|
|
return depth;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(fb_get_color_depth);
|
|
|
|
|
|
|
|
/*
|
2005-06-22 00:16:58 +00:00
|
|
|
* Data padding functions.
|
2005-04-16 22:20:36 +00:00
|
|
|
*/
|
2005-06-22 00:17:07 +00:00
|
|
|
void fb_pad_aligned_buffer(u8 *dst, u32 d_pitch, u8 *src, u32 s_pitch, u32 height)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2005-09-09 20:10:04 +00:00
|
|
|
__fb_pad_aligned_buffer(dst, d_pitch, src, s_pitch, height);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
2005-06-22 00:17:07 +00:00
|
|
|
EXPORT_SYMBOL(fb_pad_aligned_buffer);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2005-06-22 00:17:07 +00:00
|
|
|
void fb_pad_unaligned_buffer(u8 *dst, u32 d_pitch, u8 *src, u32 idx, u32 height,
|
|
|
|
u32 shift_high, u32 shift_low, u32 mod)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
|
|
|
u8 mask = (u8) (0xfff << shift_high), tmp;
|
|
|
|
int i, j;
|
|
|
|
|
|
|
|
for (i = height; i--; ) {
|
|
|
|
for (j = 0; j < idx; j++) {
|
|
|
|
tmp = dst[j];
|
|
|
|
tmp &= mask;
|
|
|
|
tmp |= *src >> shift_low;
|
|
|
|
dst[j] = tmp;
|
|
|
|
tmp = *src << shift_high;
|
|
|
|
dst[j+1] = tmp;
|
|
|
|
src++;
|
|
|
|
}
|
|
|
|
tmp = dst[idx];
|
|
|
|
tmp &= mask;
|
|
|
|
tmp |= *src >> shift_low;
|
|
|
|
dst[idx] = tmp;
|
|
|
|
if (shift_high < mod) {
|
|
|
|
tmp = *src << shift_high;
|
|
|
|
dst[idx+1] = tmp;
|
|
|
|
}
|
|
|
|
src++;
|
|
|
|
dst += d_pitch;
|
|
|
|
}
|
|
|
|
}
|
2005-06-22 00:17:07 +00:00
|
|
|
EXPORT_SYMBOL(fb_pad_unaligned_buffer);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* we need to lock this section since fb_cursor
|
|
|
|
* may use fb_imageblit()
|
|
|
|
*/
|
|
|
|
char* fb_get_buffer_offset(struct fb_info *info, struct fb_pixmap *buf, u32 size)
|
|
|
|
{
|
|
|
|
u32 align = buf->buf_align - 1, offset;
|
|
|
|
char *addr = buf->addr;
|
|
|
|
|
|
|
|
/* If IO mapped, we need to sync before access, no sharing of
|
|
|
|
* the pixmap is done
|
|
|
|
*/
|
|
|
|
if (buf->flags & FB_PIXMAP_IO) {
|
|
|
|
if (info->fbops->fb_sync && (buf->flags & FB_PIXMAP_SYNC))
|
|
|
|
info->fbops->fb_sync(info);
|
|
|
|
return addr;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* See if we fit in the remaining pixmap space */
|
|
|
|
offset = buf->offset + align;
|
|
|
|
offset &= ~align;
|
|
|
|
if (offset + size > buf->size) {
|
|
|
|
/* We do not fit. In order to be able to re-use the buffer,
|
|
|
|
* we must ensure no asynchronous DMA'ing or whatever operation
|
|
|
|
* is in progress, we sync for that.
|
|
|
|
*/
|
|
|
|
if (info->fbops->fb_sync && (buf->flags & FB_PIXMAP_SYNC))
|
|
|
|
info->fbops->fb_sync(info);
|
|
|
|
offset = 0;
|
|
|
|
}
|
|
|
|
buf->offset = offset + size;
|
|
|
|
addr += offset;
|
|
|
|
|
|
|
|
return addr;
|
|
|
|
}
|
2013-08-15 14:12:55 +00:00
|
|
|
EXPORT_SYMBOL(fb_get_buffer_offset);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
int
|
|
|
|
fb_pan_display(struct fb_info *info, struct fb_var_screeninfo *var)
|
|
|
|
{
|
2005-12-13 06:17:17 +00:00
|
|
|
struct fb_fix_screeninfo *fix = &info->fix;
|
2008-07-24 04:31:28 +00:00
|
|
|
unsigned int yres = info->var.yres;
|
|
|
|
int err = 0;
|
2005-12-13 06:17:17 +00:00
|
|
|
|
|
|
|
if (var->yoffset > 0) {
|
|
|
|
if (var->vmode & FB_VMODE_YWRAP) {
|
|
|
|
if (!fix->ywrapstep || (var->yoffset % fix->ywrapstep))
|
|
|
|
err = -EINVAL;
|
|
|
|
else
|
|
|
|
yres = 0;
|
|
|
|
} else if (!fix->ypanstep || (var->yoffset % fix->ypanstep))
|
|
|
|
err = -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (var->xoffset > 0 && (!fix->xpanstep ||
|
|
|
|
(var->xoffset % fix->xpanstep)))
|
|
|
|
err = -EINVAL;
|
|
|
|
|
2008-07-24 04:31:28 +00:00
|
|
|
if (err || !info->fbops->fb_pan_display ||
|
2009-09-22 23:47:41 +00:00
|
|
|
var->yoffset > info->var.yres_virtual - yres ||
|
|
|
|
var->xoffset > info->var.xres_virtual - info->var.xres)
|
2005-12-13 06:17:17 +00:00
|
|
|
return -EINVAL;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
if ((err = info->fbops->fb_pan_display(var, info)))
|
|
|
|
return err;
|
2010-10-27 22:33:27 +00:00
|
|
|
info->var.xoffset = var->xoffset;
|
|
|
|
info->var.yoffset = var->yoffset;
|
|
|
|
if (var->vmode & FB_VMODE_YWRAP)
|
|
|
|
info->var.vmode |= FB_VMODE_YWRAP;
|
|
|
|
else
|
|
|
|
info->var.vmode &= ~FB_VMODE_YWRAP;
|
|
|
|
return 0;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
2013-08-15 14:12:55 +00:00
|
|
|
EXPORT_SYMBOL(fb_pan_display);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2007-05-08 07:39:37 +00:00
|
|
|
static int fb_check_caps(struct fb_info *info, struct fb_var_screeninfo *var,
|
|
|
|
u32 activate)
|
|
|
|
{
|
|
|
|
struct fb_blit_caps caps, fbcaps;
|
|
|
|
int err = 0;
|
|
|
|
|
|
|
|
memset(&caps, 0, sizeof(caps));
|
|
|
|
memset(&fbcaps, 0, sizeof(fbcaps));
|
|
|
|
caps.flags = (activate & FB_ACTIVATE_ALL) ? 1 : 0;
|
2019-05-28 09:02:54 +00:00
|
|
|
fbcon_get_requirement(info, &caps);
|
2007-05-08 07:39:37 +00:00
|
|
|
info->fbops->fb_get_caps(info, &fbcaps, var);
|
|
|
|
|
2024-03-16 00:10:21 +00:00
|
|
|
if (!bitmap_subset(caps.x, fbcaps.x, FB_MAX_BLIT_WIDTH) ||
|
|
|
|
!bitmap_subset(caps.y, fbcaps.y, FB_MAX_BLIT_HEIGHT) ||
|
2007-05-08 07:39:37 +00:00
|
|
|
(fbcaps.len < caps.len))
|
|
|
|
err = -EINVAL;
|
|
|
|
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
int
|
|
|
|
fb_set_var(struct fb_info *info, struct fb_var_screeninfo *var)
|
|
|
|
{
|
2007-05-08 07:39:52 +00:00
|
|
|
int ret = 0;
|
2019-05-28 09:02:58 +00:00
|
|
|
u32 activate;
|
|
|
|
struct fb_var_screeninfo old_var;
|
|
|
|
struct fb_videomode mode;
|
2019-05-28 09:02:59 +00:00
|
|
|
struct fb_event event;
|
2021-09-08 10:27:49 +00:00
|
|
|
u32 unused;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
if (var->activate & FB_ACTIVATE_INV_MODE) {
|
|
|
|
struct fb_videomode mode1, mode2;
|
|
|
|
|
|
|
|
fb_var_to_videomode(&mode1, var);
|
|
|
|
fb_var_to_videomode(&mode2, &info->var);
|
|
|
|
/* make sure we don't delete the videomode of current var */
|
|
|
|
ret = fb_mode_is_equal(&mode1, &mode2);
|
2021-07-12 08:55:44 +00:00
|
|
|
if (!ret) {
|
|
|
|
ret = fbcon_mode_deleted(info, &mode1);
|
|
|
|
if (!ret)
|
|
|
|
fb_delete_videomode(&mode1, &info->modelist);
|
|
|
|
}
|
2007-05-08 07:39:52 +00:00
|
|
|
|
2019-05-28 09:02:58 +00:00
|
|
|
return ret ? -EINVAL : 0;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
2019-05-28 09:02:58 +00:00
|
|
|
if (!(var->activate & FB_ACTIVATE_FORCE) &&
|
|
|
|
!memcmp(&info->var, var, sizeof(struct fb_var_screeninfo)))
|
|
|
|
return 0;
|
2007-05-08 07:39:22 +00:00
|
|
|
|
2019-05-28 09:02:58 +00:00
|
|
|
activate = var->activate;
|
2011-12-13 13:02:26 +00:00
|
|
|
|
2019-05-28 09:02:58 +00:00
|
|
|
/* When using FOURCC mode, make sure the red, green, blue and
|
|
|
|
* transp fields are set to 0.
|
|
|
|
*/
|
|
|
|
if ((info->fix.capabilities & FB_CAP_FOURCC) &&
|
|
|
|
var->grayscale > 1) {
|
|
|
|
if (var->red.offset || var->green.offset ||
|
|
|
|
var->blue.offset || var->transp.offset ||
|
|
|
|
var->red.length || var->green.length ||
|
|
|
|
var->blue.length || var->transp.length ||
|
|
|
|
var->red.msb_right || var->green.msb_right ||
|
|
|
|
var->blue.msb_right || var->transp.msb_right)
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2019-05-28 09:02:58 +00:00
|
|
|
if (!info->fbops->fb_check_var) {
|
|
|
|
*var = info->var;
|
|
|
|
return 0;
|
|
|
|
}
|
2007-05-08 07:39:52 +00:00
|
|
|
|
2020-07-07 19:26:03 +00:00
|
|
|
/* bitfill_aligned() assumes that it's at least 8x8 */
|
|
|
|
if (var->xres < 8 || var->yres < 8)
|
|
|
|
return -EINVAL;
|
|
|
|
|
2021-09-08 10:27:49 +00:00
|
|
|
/* Too huge resolution causes multiplication overflow. */
|
|
|
|
if (check_mul_overflow(var->xres, var->yres, &unused) ||
|
|
|
|
check_mul_overflow(var->xres_virtual, var->yres_virtual, &unused))
|
|
|
|
return -EINVAL;
|
|
|
|
|
2019-05-28 09:02:58 +00:00
|
|
|
ret = info->fbops->fb_check_var(var, info);
|
|
|
|
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2022-06-29 13:53:55 +00:00
|
|
|
/* verify that virtual resolution >= physical resolution */
|
|
|
|
if (var->xres_virtual < var->xres ||
|
|
|
|
var->yres_virtual < var->yres) {
|
|
|
|
pr_warn("WARNING: fbcon: Driver '%s' missed to adjust virtual screen size (%ux%u vs. %ux%u)\n",
|
|
|
|
info->fix.id,
|
|
|
|
var->xres_virtual, var->yres_virtual,
|
|
|
|
var->xres, var->yres);
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2019-05-28 09:02:58 +00:00
|
|
|
if ((var->activate & FB_ACTIVATE_MASK) != FB_ACTIVATE_NOW)
|
|
|
|
return 0;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2019-05-28 09:02:58 +00:00
|
|
|
if (info->fbops->fb_get_caps) {
|
|
|
|
ret = fb_check_caps(info, var, activate);
|
2007-05-08 07:39:37 +00:00
|
|
|
|
2019-05-28 09:02:58 +00:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
}
|
2007-05-08 07:39:37 +00:00
|
|
|
|
2019-05-28 09:02:58 +00:00
|
|
|
old_var = info->var;
|
|
|
|
info->var = *var;
|
2007-05-08 07:39:37 +00:00
|
|
|
|
2019-05-28 09:02:58 +00:00
|
|
|
if (info->fbops->fb_set_par) {
|
|
|
|
ret = info->fbops->fb_set_par(info);
|
2009-09-22 23:47:44 +00:00
|
|
|
|
2019-05-28 09:02:58 +00:00
|
|
|
if (ret) {
|
|
|
|
info->var = old_var;
|
|
|
|
printk(KERN_WARNING "detected "
|
|
|
|
"fb_set_par error, "
|
|
|
|
"error code: %d\n", ret);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2019-05-28 09:02:58 +00:00
|
|
|
fb_pan_display(info, &info->var);
|
|
|
|
fb_set_cmap(&info->cmap, info);
|
|
|
|
fb_var_to_videomode(&mode, &info->var);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2019-05-28 09:02:58 +00:00
|
|
|
if (info->modelist.prev && info->modelist.next &&
|
|
|
|
!list_empty(&info->modelist))
|
|
|
|
ret = fb_add_videomode(&mode, &info->modelist);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2019-05-28 09:02:59 +00:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2019-05-28 09:02:59 +00:00
|
|
|
event.info = info;
|
|
|
|
event.data = &mode;
|
|
|
|
fb_notifier_call_chain(FB_EVENT_MODE_CHANGE, &event);
|
|
|
|
|
|
|
|
return 0;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
2013-08-15 14:12:55 +00:00
|
|
|
EXPORT_SYMBOL(fb_set_var);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
int
|
|
|
|
fb_blank(struct fb_info *info, int blank)
|
2020-07-29 13:41:44 +00:00
|
|
|
{
|
2012-05-29 22:07:12 +00:00
|
|
|
struct fb_event event;
|
2019-07-25 14:32:24 +00:00
|
|
|
int ret = -EINVAL;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2019-12-18 03:00:25 +00:00
|
|
|
if (blank > FB_BLANK_POWERDOWN)
|
|
|
|
blank = FB_BLANK_POWERDOWN;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2012-05-29 22:07:12 +00:00
|
|
|
event.info = info;
|
|
|
|
event.data = ␣
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
if (info->fbops->fb_blank)
|
2019-12-18 03:00:25 +00:00
|
|
|
ret = info->fbops->fb_blank(blank, info);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2012-05-29 22:07:12 +00:00
|
|
|
if (!ret)
|
2006-07-30 10:04:17 +00:00
|
|
|
fb_notifier_call_chain(FB_EVENT_BLANK, &event);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2019-12-18 03:00:25 +00:00
|
|
|
return ret;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
2013-08-15 14:12:55 +00:00
|
|
|
EXPORT_SYMBOL(fb_blank);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2008-04-28 09:14:49 +00:00
|
|
|
static int fb_check_foreignness(struct fb_info *fi)
|
|
|
|
{
|
|
|
|
const bool foreign_endian = fi->flags & FBINFO_FOREIGN_ENDIAN;
|
|
|
|
|
|
|
|
fi->flags &= ~FBINFO_FOREIGN_ENDIAN;
|
|
|
|
|
|
|
|
#ifdef __BIG_ENDIAN
|
|
|
|
fi->flags |= foreign_endian ? 0 : FBINFO_BE_MATH;
|
|
|
|
#else
|
|
|
|
fi->flags |= foreign_endian ? FBINFO_BE_MATH : 0;
|
|
|
|
#endif /* __BIG_ENDIAN */
|
|
|
|
|
|
|
|
if (fi->flags & FBINFO_BE_MATH && !fb_be_math(fi)) {
|
|
|
|
pr_err("%s: enable CONFIG_FB_BIG_ENDIAN to "
|
|
|
|
"support this framebuffer\n", fi->fix.id);
|
|
|
|
return -ENOSYS;
|
|
|
|
} else if (!(fi->flags & FBINFO_BE_MATH) && fb_be_math(fi)) {
|
|
|
|
pr_err("%s: enable CONFIG_FB_LITTLE_ENDIAN to "
|
|
|
|
"support this framebuffer\n", fi->fix.id);
|
|
|
|
return -ENOSYS;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
fbmem: fix remove_conflicting_framebuffers races
When a register_framebuffer() call results in us removing old
conflicting framebuffers, the new registration_lock doesn't protect that
situation. And we can't just add the same locking to the function,
because these functions call each other: register_framebuffer() calls
remove_conflicting_framebuffers, which in turn calls
unregister_framebuffer for any conflicting entry.
In order to fix it, this just creates wrapper functions around all three
functions and makes the versions that actually do the work be called
"do_xxx()", leaving just the wrapper that gets the lock and calls the
worker function.
So the rule becomes simply that "do_xxxx()" has to be called with the
lock held, and now do_register_framebuffer() can just call
do_remove_conflicting_framebuffers(), and that in turn can call
_do_unregister_framebuffer(), and there is no deadlock, and we can hold
the registration lock over the whole sequence, fixing the races.
It also makes error cases simpler, and fixes one situation where we
would return from unregister_framebuffer() without releasing the lock,
pointed out by Bruno Prémont.
Tested-by: Bruno Prémont <bonbons@linux-vserver.org>
Tested-by: Anca Emanuel <anca.emanuel@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-05-13 23:16:41 +00:00
|
|
|
static int do_register_framebuffer(struct fb_info *fb_info)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2022-04-05 21:03:32 +00:00
|
|
|
int i;
|
2005-09-09 20:09:58 +00:00
|
|
|
struct fb_videomode mode;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2008-04-28 09:14:49 +00:00
|
|
|
if (fb_check_foreignness(fb_info))
|
|
|
|
return -ENOSYS;
|
|
|
|
|
2011-05-14 10:24:15 +00:00
|
|
|
if (num_registered_fb == FB_MAX)
|
|
|
|
return -ENXIO;
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
num_registered_fb++;
|
|
|
|
for (i = 0 ; i < FB_MAX; i++)
|
|
|
|
if (!registered_fb[i])
|
|
|
|
break;
|
|
|
|
fb_info->node = i;
|
2021-07-19 05:59:45 +00:00
|
|
|
refcount_set(&fb_info->count, 1);
|
2009-07-08 16:20:11 +00:00
|
|
|
mutex_init(&fb_info->lock);
|
|
|
|
mutex_init(&fb_info->mm_lock);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2023-06-13 11:07:09 +00:00
|
|
|
fb_device_create(fb_info);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
if (fb_info->pixmap.addr == NULL) {
|
|
|
|
fb_info->pixmap.addr = kmalloc(FBPIXMAPSIZE, GFP_KERNEL);
|
|
|
|
if (fb_info->pixmap.addr) {
|
|
|
|
fb_info->pixmap.size = FBPIXMAPSIZE;
|
|
|
|
fb_info->pixmap.buf_align = 1;
|
|
|
|
fb_info->pixmap.scan_align = 1;
|
2005-06-22 00:17:08 +00:00
|
|
|
fb_info->pixmap.access_align = 32;
|
2005-04-16 22:20:36 +00:00
|
|
|
fb_info->pixmap.flags = FB_PIXMAP_DEFAULT;
|
|
|
|
}
|
2020-07-29 13:41:44 +00:00
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
fb_info->pixmap.offset = 0;
|
|
|
|
|
2024-03-16 00:10:21 +00:00
|
|
|
if (bitmap_empty(fb_info->pixmap.blit_x, FB_MAX_BLIT_WIDTH))
|
|
|
|
bitmap_fill(fb_info->pixmap.blit_x, FB_MAX_BLIT_WIDTH);
|
2007-05-08 07:39:09 +00:00
|
|
|
|
2024-03-16 00:10:21 +00:00
|
|
|
if (bitmap_empty(fb_info->pixmap.blit_y, FB_MAX_BLIT_HEIGHT))
|
|
|
|
bitmap_fill(fb_info->pixmap.blit_y, FB_MAX_BLIT_HEIGHT);
|
2007-05-08 07:39:09 +00:00
|
|
|
|
2005-09-09 20:09:58 +00:00
|
|
|
if (!fb_info->modelist.prev || !fb_info->modelist.next)
|
2005-04-16 22:20:36 +00:00
|
|
|
INIT_LIST_HEAD(&fb_info->modelist);
|
|
|
|
|
2013-02-04 13:37:21 +00:00
|
|
|
if (fb_info->skip_vt_switch)
|
2023-06-13 11:07:07 +00:00
|
|
|
pm_vt_switch_required(fb_info->device, false);
|
2013-02-04 13:37:21 +00:00
|
|
|
else
|
2023-06-13 11:07:07 +00:00
|
|
|
pm_vt_switch_required(fb_info->device, true);
|
2013-02-04 13:37:21 +00:00
|
|
|
|
2005-09-09 20:09:58 +00:00
|
|
|
fb_var_to_videomode(&mode, &fb_info->var);
|
|
|
|
fb_add_videomode(&mode, &fb_info->modelist);
|
2005-04-16 22:20:36 +00:00
|
|
|
registered_fb[i] = fb_info;
|
|
|
|
|
2019-05-28 09:02:41 +00:00
|
|
|
#ifdef CONFIG_GUMSTIX_AM200EPD
|
|
|
|
{
|
|
|
|
struct fb_event event;
|
|
|
|
event.info = fb_info;
|
|
|
|
fb_notifier_call_chain(FB_EVENT_FB_REGISTERED, &event);
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2022-04-05 21:03:32 +00:00
|
|
|
return fbcon_fb_registered(fb_info);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
2019-05-28 09:02:49 +00:00
|
|
|
static void unbind_console(struct fb_info *fb_info)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
fb: fix lost console when the user unplugs a USB adapter
I have a USB display adapter using the udlfb driver and I use it on an ARM
board that doesn't have any graphics card. When I plug the adapter in, the
console is properly displayed, however when I unplug and re-plug the
adapter, the console is not displayed and I can't access it until I reboot
the board.
The reason is this:
When the adapter is unplugged, dlfb_usb_disconnect calls
unlink_framebuffer, then it waits until the reference count drops to zero
and then it deallocates the framebuffer. However, the console that is
attached to the framebuffer device keeps the reference count non-zero, so
the framebuffer device is never destroyed. When the USB adapter is plugged
again, it creates a new device /dev/fb1 and the console is not attached to
it.
This patch fixes the bug by unbinding the console from unlink_framebuffer.
The code to unbind the console is moved from do_unregister_framebuffer to
a function unbind_console. When the console is unbound, the reference
count drops to zero and the udlfb driver frees the framebuffer. When the
adapter is plugged back, a new framebuffer is created and the console is
attached to it.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Bernie Thompson <bernie@plugable.com>
Cc: Ladislav Michl <ladis@linux-mips.org>
Cc: stable@vger.kernel.org
[b.zolnierkie: preserve old behavior for do_unregister_framebuffer()]
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
2018-07-25 13:41:54 +00:00
|
|
|
int i = fb_info->node;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2019-05-28 09:02:49 +00:00
|
|
|
if (WARN_ON(i < 0 || i >= FB_MAX || registered_fb[i] != fb_info))
|
|
|
|
return;
|
2009-04-13 21:39:39 +00:00
|
|
|
|
2019-05-28 09:02:48 +00:00
|
|
|
fbcon_fb_unbind(fb_info);
|
fb: fix lost console when the user unplugs a USB adapter
I have a USB display adapter using the udlfb driver and I use it on an ARM
board that doesn't have any graphics card. When I plug the adapter in, the
console is properly displayed, however when I unplug and re-plug the
adapter, the console is not displayed and I can't access it until I reboot
the board.
The reason is this:
When the adapter is unplugged, dlfb_usb_disconnect calls
unlink_framebuffer, then it waits until the reference count drops to zero
and then it deallocates the framebuffer. However, the console that is
attached to the framebuffer device keeps the reference count non-zero, so
the framebuffer device is never destroyed. When the USB adapter is plugged
again, it creates a new device /dev/fb1 and the console is not attached to
it.
This patch fixes the bug by unbinding the console from unlink_framebuffer.
The code to unbind the console is moved from do_unregister_framebuffer to
a function unbind_console. When the console is unbound, the reference
count drops to zero and the udlfb driver frees the framebuffer. When the
adapter is plugged back, a new framebuffer is created and the console is
attached to it.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Bernie Thompson <bernie@plugable.com>
Cc: Ladislav Michl <ladis@linux-mips.org>
Cc: stable@vger.kernel.org
[b.zolnierkie: preserve old behavior for do_unregister_framebuffer()]
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
2018-07-25 13:41:54 +00:00
|
|
|
}
|
|
|
|
|
2019-11-14 12:51:06 +00:00
|
|
|
static void unlink_framebuffer(struct fb_info *fb_info)
|
fb: fix lost console when the user unplugs a USB adapter
I have a USB display adapter using the udlfb driver and I use it on an ARM
board that doesn't have any graphics card. When I plug the adapter in, the
console is properly displayed, however when I unplug and re-plug the
adapter, the console is not displayed and I can't access it until I reboot
the board.
The reason is this:
When the adapter is unplugged, dlfb_usb_disconnect calls
unlink_framebuffer, then it waits until the reference count drops to zero
and then it deallocates the framebuffer. However, the console that is
attached to the framebuffer device keeps the reference count non-zero, so
the framebuffer device is never destroyed. When the USB adapter is plugged
again, it creates a new device /dev/fb1 and the console is not attached to
it.
This patch fixes the bug by unbinding the console from unlink_framebuffer.
The code to unbind the console is moved from do_unregister_framebuffer to
a function unbind_console. When the console is unbound, the reference
count drops to zero and the udlfb driver frees the framebuffer. When the
adapter is plugged back, a new framebuffer is created and the console is
attached to it.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Bernie Thompson <bernie@plugable.com>
Cc: Ladislav Michl <ladis@linux-mips.org>
Cc: stable@vger.kernel.org
[b.zolnierkie: preserve old behavior for do_unregister_framebuffer()]
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
2018-07-25 13:41:54 +00:00
|
|
|
{
|
2019-05-28 09:02:50 +00:00
|
|
|
int i;
|
|
|
|
|
|
|
|
i = fb_info->node;
|
|
|
|
if (WARN_ON(i < 0 || i >= FB_MAX || registered_fb[i] != fb_info))
|
|
|
|
return;
|
|
|
|
|
2023-06-13 11:07:09 +00:00
|
|
|
fb_device_destroy(fb_info);
|
2023-06-13 11:07:07 +00:00
|
|
|
pm_vt_switch_unregister(fb_info->device);
|
2019-05-28 09:02:50 +00:00
|
|
|
unbind_console(fb_info);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void do_unregister_framebuffer(struct fb_info *fb_info)
|
|
|
|
{
|
|
|
|
unlink_framebuffer(fb_info);
|
2006-06-26 07:27:09 +00:00
|
|
|
if (fb_info->pixmap.addr &&
|
2021-10-10 06:42:28 +00:00
|
|
|
(fb_info->pixmap.flags & FB_PIXMAP_DEFAULT)) {
|
2005-04-16 22:20:36 +00:00
|
|
|
kfree(fb_info->pixmap.addr);
|
2021-10-10 06:42:28 +00:00
|
|
|
fb_info->pixmap.addr = NULL;
|
|
|
|
}
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
fb_destroy_modelist(&fb_info->modelist);
|
fb: fix lost console when the user unplugs a USB adapter
I have a USB display adapter using the udlfb driver and I use it on an ARM
board that doesn't have any graphics card. When I plug the adapter in, the
console is properly displayed, however when I unplug and re-plug the
adapter, the console is not displayed and I can't access it until I reboot
the board.
The reason is this:
When the adapter is unplugged, dlfb_usb_disconnect calls
unlink_framebuffer, then it waits until the reference count drops to zero
and then it deallocates the framebuffer. However, the console that is
attached to the framebuffer device keeps the reference count non-zero, so
the framebuffer device is never destroyed. When the USB adapter is plugged
again, it creates a new device /dev/fb1 and the console is not attached to
it.
This patch fixes the bug by unbinding the console from unlink_framebuffer.
The code to unbind the console is moved from do_unregister_framebuffer to
a function unbind_console. When the console is unbound, the reference
count drops to zero and the udlfb driver frees the framebuffer. When the
adapter is plugged back, a new framebuffer is created and the console is
attached to it.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Bernie Thompson <bernie@plugable.com>
Cc: Ladislav Michl <ladis@linux-mips.org>
Cc: stable@vger.kernel.org
[b.zolnierkie: preserve old behavior for do_unregister_framebuffer()]
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
2018-07-25 13:41:54 +00:00
|
|
|
registered_fb[fb_info->node] = NULL;
|
2005-04-16 22:20:36 +00:00
|
|
|
num_registered_fb--;
|
2019-05-28 09:02:41 +00:00
|
|
|
#ifdef CONFIG_GUMSTIX_AM200EPD
|
|
|
|
{
|
|
|
|
struct fb_event event;
|
|
|
|
event.info = fb_info;
|
|
|
|
fb_notifier_call_chain(FB_EVENT_FB_UNREGISTERED, &event);
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
fbcon_fb_unregistered(fb_info);
|
2009-06-16 22:34:38 +00:00
|
|
|
|
|
|
|
/* this may free fb info */
|
2011-05-11 21:49:36 +00:00
|
|
|
put_fb_info(fb_info);
|
fbmem: fix remove_conflicting_framebuffers races
When a register_framebuffer() call results in us removing old
conflicting framebuffers, the new registration_lock doesn't protect that
situation. And we can't just add the same locking to the function,
because these functions call each other: register_framebuffer() calls
remove_conflicting_framebuffers, which in turn calls
unregister_framebuffer for any conflicting entry.
In order to fix it, this just creates wrapper functions around all three
functions and makes the versions that actually do the work be called
"do_xxx()", leaving just the wrapper that gets the lock and calls the
worker function.
So the rule becomes simply that "do_xxxx()" has to be called with the
lock held, and now do_register_framebuffer() can just call
do_remove_conflicting_framebuffers(), and that in turn can call
_do_unregister_framebuffer(), and there is no deadlock, and we can hold
the registration lock over the whole sequence, fixing the races.
It also makes error cases simpler, and fixes one situation where we
would return from unregister_framebuffer() without releasing the lock,
pointed out by Bruno Prémont.
Tested-by: Bruno Prémont <bonbons@linux-vserver.org>
Tested-by: Anca Emanuel <anca.emanuel@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-05-13 23:16:41 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* register_framebuffer - registers a frame buffer device
|
|
|
|
* @fb_info: frame buffer info structure
|
|
|
|
*
|
|
|
|
* Registers a frame buffer device @fb_info.
|
|
|
|
*
|
|
|
|
* Returns negative errno on error, or zero for success.
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
int
|
|
|
|
register_framebuffer(struct fb_info *fb_info)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
mutex_lock(®istration_lock);
|
|
|
|
ret = do_register_framebuffer(fb_info);
|
|
|
|
mutex_unlock(®istration_lock);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
2013-08-15 14:12:55 +00:00
|
|
|
EXPORT_SYMBOL(register_framebuffer);
|
fbmem: fix remove_conflicting_framebuffers races
When a register_framebuffer() call results in us removing old
conflicting framebuffers, the new registration_lock doesn't protect that
situation. And we can't just add the same locking to the function,
because these functions call each other: register_framebuffer() calls
remove_conflicting_framebuffers, which in turn calls
unregister_framebuffer for any conflicting entry.
In order to fix it, this just creates wrapper functions around all three
functions and makes the versions that actually do the work be called
"do_xxx()", leaving just the wrapper that gets the lock and calls the
worker function.
So the rule becomes simply that "do_xxxx()" has to be called with the
lock held, and now do_register_framebuffer() can just call
do_remove_conflicting_framebuffers(), and that in turn can call
_do_unregister_framebuffer(), and there is no deadlock, and we can hold
the registration lock over the whole sequence, fixing the races.
It also makes error cases simpler, and fixes one situation where we
would return from unregister_framebuffer() without releasing the lock,
pointed out by Bruno Prémont.
Tested-by: Bruno Prémont <bonbons@linux-vserver.org>
Tested-by: Anca Emanuel <anca.emanuel@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-05-13 23:16:41 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* unregister_framebuffer - releases a frame buffer device
|
|
|
|
* @fb_info: frame buffer info structure
|
|
|
|
*
|
|
|
|
* Unregisters a frame buffer device @fb_info.
|
|
|
|
*
|
|
|
|
* Returns negative errno on error, or zero for success.
|
|
|
|
*
|
|
|
|
* This function will also notify the framebuffer console
|
|
|
|
* to release the driver.
|
|
|
|
*
|
|
|
|
* This is meant to be called within a driver's module_exit()
|
|
|
|
* function. If this is called outside module_exit(), ensure
|
|
|
|
* that the driver implements fb_open() and fb_release() to
|
|
|
|
* check that no processes are using the device.
|
|
|
|
*/
|
2019-05-28 09:02:49 +00:00
|
|
|
void
|
fbmem: fix remove_conflicting_framebuffers races
When a register_framebuffer() call results in us removing old
conflicting framebuffers, the new registration_lock doesn't protect that
situation. And we can't just add the same locking to the function,
because these functions call each other: register_framebuffer() calls
remove_conflicting_framebuffers, which in turn calls
unregister_framebuffer for any conflicting entry.
In order to fix it, this just creates wrapper functions around all three
functions and makes the versions that actually do the work be called
"do_xxx()", leaving just the wrapper that gets the lock and calls the
worker function.
So the rule becomes simply that "do_xxxx()" has to be called with the
lock held, and now do_register_framebuffer() can just call
do_remove_conflicting_framebuffers(), and that in turn can call
_do_unregister_framebuffer(), and there is no deadlock, and we can hold
the registration lock over the whole sequence, fixing the races.
It also makes error cases simpler, and fixes one situation where we
would return from unregister_framebuffer() without releasing the lock,
pointed out by Bruno Prémont.
Tested-by: Bruno Prémont <bonbons@linux-vserver.org>
Tested-by: Anca Emanuel <anca.emanuel@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-05-13 23:16:41 +00:00
|
|
|
unregister_framebuffer(struct fb_info *fb_info)
|
|
|
|
{
|
2022-05-11 11:30:39 +00:00
|
|
|
mutex_lock(®istration_lock);
|
2019-05-28 09:02:49 +00:00
|
|
|
do_unregister_framebuffer(fb_info);
|
2022-05-11 11:30:39 +00:00
|
|
|
mutex_unlock(®istration_lock);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
2013-08-15 14:12:55 +00:00
|
|
|
EXPORT_SYMBOL(unregister_framebuffer);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* fb_set_suspend - low level driver signals suspend
|
|
|
|
* @info: framebuffer affected
|
|
|
|
* @state: 0 = resuming, !=0 = suspending
|
|
|
|
*
|
|
|
|
* This is meant to be used by low level drivers to
|
|
|
|
* signal suspend/resume to the core & clients.
|
|
|
|
* It must be called with the console semaphore held
|
|
|
|
*/
|
|
|
|
void fb_set_suspend(struct fb_info *info, int state)
|
|
|
|
{
|
2019-05-28 09:02:33 +00:00
|
|
|
WARN_CONSOLE_UNLOCKED();
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
if (state) {
|
2019-05-28 09:02:52 +00:00
|
|
|
fbcon_suspended(info);
|
2005-04-16 22:20:36 +00:00
|
|
|
info->state = FBINFO_STATE_SUSPENDED;
|
|
|
|
} else {
|
|
|
|
info->state = FBINFO_STATE_RUNNING;
|
2019-05-28 09:02:52 +00:00
|
|
|
fbcon_resumed(info);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
}
|
2013-08-15 14:12:55 +00:00
|
|
|
EXPORT_SYMBOL(fb_set_suspend);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2023-06-13 11:07:12 +00:00
|
|
|
static int __init fbmem_init(void)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2016-05-03 02:22:27 +00:00
|
|
|
int ret;
|
|
|
|
|
2023-06-13 11:07:12 +00:00
|
|
|
fb_class = class_create("graphics");
|
|
|
|
if (IS_ERR(fb_class)) {
|
|
|
|
ret = PTR_ERR(fb_class);
|
|
|
|
pr_err("Unable to create fb class; errno = %d\n", ret);
|
|
|
|
goto err_fb_class;
|
|
|
|
}
|
|
|
|
|
2023-06-13 11:07:10 +00:00
|
|
|
ret = fb_init_procfs();
|
|
|
|
if (ret)
|
2023-06-13 11:07:12 +00:00
|
|
|
goto err_class_destroy;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2023-06-13 11:07:11 +00:00
|
|
|
ret = fb_register_chrdev();
|
|
|
|
if (ret)
|
2023-06-13 11:07:12 +00:00
|
|
|
goto err_fb_cleanup_procfs;
|
fbcon: Make fbcon a built-time depency for fbdev
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 <alan@linux.intel.com>
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 <daniel.vetter@ffwll.ch>
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 <daniel.vetter@intel.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
2017-08-01 15:32:07 +00:00
|
|
|
|
|
|
|
fb_console_init();
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
return 0;
|
2016-05-03 02:22:27 +00:00
|
|
|
|
2023-06-13 11:07:12 +00:00
|
|
|
err_fb_cleanup_procfs:
|
2023-06-13 11:07:10 +00:00
|
|
|
fb_cleanup_procfs();
|
2023-06-13 11:07:12 +00:00
|
|
|
err_class_destroy:
|
|
|
|
class_destroy(fb_class);
|
|
|
|
err_fb_class:
|
|
|
|
fb_class = NULL;
|
2016-05-03 02:22:27 +00:00
|
|
|
return ret;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
#ifdef MODULE
|
2023-06-13 11:07:12 +00:00
|
|
|
static void __exit fbmem_exit(void)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
fbcon: Make fbcon a built-time depency for fbdev
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 <alan@linux.intel.com>
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 <daniel.vetter@ffwll.ch>
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 <daniel.vetter@intel.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
2017-08-01 15:32:07 +00:00
|
|
|
fb_console_exit();
|
2023-06-13 11:07:12 +00:00
|
|
|
fb_unregister_chrdev();
|
2023-06-13 11:07:10 +00:00
|
|
|
fb_cleanup_procfs();
|
2005-03-23 18:01:41 +00:00
|
|
|
class_destroy(fb_class);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
2023-06-13 11:07:12 +00:00
|
|
|
module_init(fbmem_init);
|
2005-04-16 22:20:36 +00:00
|
|
|
module_exit(fbmem_exit);
|
|
|
|
MODULE_LICENSE("GPL");
|
|
|
|
MODULE_DESCRIPTION("Framebuffer base");
|
|
|
|
#else
|
|
|
|
subsys_initcall(fbmem_init);
|
|
|
|
#endif
|
|
|
|
|
|
|
|
int fb_new_modelist(struct fb_info *info)
|
|
|
|
{
|
|
|
|
struct fb_var_screeninfo var = info->var;
|
|
|
|
struct list_head *pos, *n;
|
|
|
|
struct fb_modelist *modelist;
|
|
|
|
struct fb_videomode *m, mode;
|
2019-06-24 22:37:24 +00:00
|
|
|
int err;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
list_for_each_safe(pos, n, &info->modelist) {
|
|
|
|
modelist = list_entry(pos, struct fb_modelist, list);
|
|
|
|
m = &modelist->mode;
|
|
|
|
fb_videomode_to_var(&var, m);
|
|
|
|
var.activate = FB_ACTIVATE_TEST;
|
|
|
|
err = fb_set_var(info, &var);
|
|
|
|
fb_var_to_videomode(&mode, &var);
|
|
|
|
if (err || !fb_mode_is_equal(m, &mode)) {
|
|
|
|
list_del(pos);
|
|
|
|
kfree(pos);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-05-28 09:02:53 +00:00
|
|
|
if (list_empty(&info->modelist))
|
|
|
|
return 1;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2019-05-28 09:02:53 +00:00
|
|
|
fbcon_new_modelist(info);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2019-05-28 09:02:53 +00:00
|
|
|
return 0;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
2022-11-11 13:30:24 +00:00
|
|
|
bool fb_modesetting_disabled(const char *drvname)
|
|
|
|
{
|
|
|
|
bool fwonly = video_firmware_drivers_only();
|
|
|
|
|
|
|
|
if (fwonly)
|
|
|
|
pr_warn("Driver %s not loading because of nomodeset parameter\n",
|
|
|
|
drvname);
|
|
|
|
|
|
|
|
return fwonly;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL(fb_modesetting_disabled);
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
MODULE_LICENSE("GPL");
|