02 Nov, 2017

1 commit

  • Many source files in the tree are missing licensing information, which
    makes it harder for compliance tools to determine the correct license.

    By default all files without license information are under the default
    license of the kernel, which is GPL version 2.

    Update the files which contain no license information with the 'GPL-2.0'
    SPDX license identifier. The SPDX identifier is a legally binding
    shorthand, which can be used instead of the full boiler plate text.

    This patch is based on work done by Thomas Gleixner and Kate Stewart and
    Philippe Ombredanne.

    How this work was done:

    Patches were generated and checked against linux-4.14-rc6 for a subset of
    the use cases:
    - file had no licensing information it it.
    - file was a */uapi/* one with no licensing information in it,
    - file was a */uapi/* one with existing licensing information,

    Further patches will be generated in subsequent months to fix up cases
    where non-standard license headers were used, and references to license
    had to be inferred by heuristics based on keywords.

    The analysis to determine which SPDX License Identifier to be applied to
    a file was done in a spreadsheet of side by side results from of the
    output of two independent scanners (ScanCode & Windriver) producing SPDX
    tag:value files created by Philippe Ombredanne. Philippe prepared the
    base worksheet, and did an initial spot review of a few 1000 files.

    The 4.13 kernel was the starting point of the analysis with 60,537 files
    assessed. Kate Stewart did a file by file comparison of the scanner
    results in the spreadsheet to determine which SPDX license identifier(s)
    to be applied to the file. She confirmed any determination that was not
    immediately clear with lawyers working with the Linux Foundation.

    Criteria used to select files for SPDX license identifier tagging was:
    - Files considered eligible had to be source code files.
    - Make and config files were included as candidates if they contained >5
    lines of source
    - File already had some variant of a license header in it (even if
    Reviewed-by: Philippe Ombredanne
    Reviewed-by: Thomas Gleixner
    Signed-off-by: Greg Kroah-Hartman

    Greg Kroah-Hartman
     

01 Aug, 2017

1 commit

  • Instead check info->ops->owner, which amounts to the same.

    Spotted because I want to remove the pile of broken and cargo-culted
    fb_info->flags assignments in drm drivers.

    Signed-off-by: Daniel Vetter
    Reviewed-by: Sean Paul
    Signed-off-by: Bartlomiej Zolnierkiewicz

    Daniel Vetter
     

02 May, 2016

1 commit

  • Export fb_deferred_io_mmap so drivers can change vma->vm_page_prot.
    When the framebuffer memory is allocated using dma_alloc_writecombine()
    instead of vmalloc(), I get cache syncing problems on ARM.
    This solves it:

    static int drm_fbdev_cma_deferred_io_mmap(struct fb_info *info,
    struct vm_area_struct *vma)
    {
    fb_deferred_io_mmap(info, vma);
    vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);

    return 0;
    }

    Could this have been done in the core?
    Drivers that don't set (struct fb_ops *)->fb_mmap, gets a call to
    fb_pgprotect() at the end of the default fb_mmap implementation
    (drivers/video/fbdev/core/fbmem.c). This is an architecture specific
    function that on many platforms uses pgprot_writecombine(), but not on
    all. And looking at some of the fb_mmap implementations, some of them
    sets vm_page_prot to nocache for instance, so I think the safest bet is
    to do this in the driver and not in the fbdev core. And we can't call
    fb_pgprotect() from fb_deferred_io_mmap() either because we don't have
    access to the file pointer that powerpc needs.

    Signed-off-by: Noralf Trønnes
    Acked-by: Tomi Valkeinen
    Signed-off-by: Daniel Vetter
    Link: http://patchwork.freedesktop.org/patch/msgid/1461856717-6476-5-git-send-email-noralf@tronnes.org

    Noralf Trønnes
     

26 Feb, 2016

1 commit

  • The fb_rotate method in struct fb_ops is never actually invoked, and
    it's been that way in the entire history of git (in fact, the last
    occurrence of the string '->fb_rotate' vanished over 10 years ago,
    with b4d8aea6d6, and that merely tested whether the callback
    existed). So remove some dead code and make struct fb_obs a little
    smaller.

    Signed-off-by: Rasmus Villemoes
    Signed-off-by: Tomi Valkeinen

    Rasmus Villemoes
     

15 Dec, 2015

1 commit

  • There's no point in having support for framebuffer notifications
    is CONFIG_FB is disabled. This commit adds the necessary stubs
    for code to link properly when CONFIG_FB=n and moves fb-notify.o
    to be built only when CONFIG_FB=y.

    Signed-off-by: Ezequiel Garcia
    Signed-off-by: Tomi Valkeinen

    Ezequiel Garcia
     

11 Nov, 2015

1 commit

  • Pull drm updates from Dave Airlie:
    "I Was Almost Tempted To Capitalise Every Word, but then I decided I
    couldn't read it myself!

    I've also got one pull request for the sti driver outstanding. It
    relied on a commit in Greg's tree and I didn't find out in time, that
    commit is in your tree now so I might send that along once this is
    merged.

    I also had the accidental misfortune to have access to a Skylake on my
    desk for a few days, and I've had to encourage Intel to try harder,
    which seems to be happening now.

    Here is the main drm-next pull request for 4.4.

    Highlights:

    New driver:
    vc4 driver for the Rasberry Pi VPU.
    (From Eric Anholt at Broadcom.)

    Core:
    Atomic fbdev support
    Atomic helpers for runtime pm
    dp/aux i2c STATUS_UPDATE handling
    struct_mutex usage cleanups.
    Generic of probing support.

    Documentation:
    Kerneldoc for VGA switcheroo code.
    Rename to gpu instead of drm to reflect scope.

    i915:
    Skylake GuC firmware fixes
    HPD A support
    VBT backlight fallbacks
    Fastboot by default for some systems
    FBC work
    BXT/SKL workarounds
    Skylake deeper sleep state fixes

    amdgpu:
    Enable GPU scheduler by default
    New atombios opcodes
    GPUVM debugging options
    Stoney support.
    Fencing cleanups.

    radeon:
    More efficient CS checking

    nouveau:
    gk20a instance memory handling improvements.
    Improved PGOB detection and GK107 support
    Kepler GDDR5 PLL statbility improvement
    G8x/GT2xx reclock improvements
    new userspace API compatiblity fixes.

    virtio-gpu:
    Add 3D support - qemu 2.5 has it merged for it's gtk backend.

    msm:
    Initial msm88896 (snapdragon 8200)

    exynos:
    HDMI cleanups
    Enable mixer driver byt default
    Add DECON-TV support

    vmwgfx:
    Move to using memremap + fixes.

    rcar-du:
    Add support for R8A7793/4 DU

    armada:
    Remove support for non-component mode
    Improved plane handling
    Power savings while in DPMS off.

    tda998x:
    Remove unused slave encoder support
    Use more HDMI helpers
    Fix EDID read handling

    dwhdmi:
    Interlace video mode support for ipu-v3/dw_hdmi
    Hotplug state fixes
    Audio driver integration

    imx:
    More color formats support.

    tegra:
    Minor fixes/improvements"

    [ Merge fixup: remove unused variable 'dev' that had all uses removed in
    commit 4e270f088011: "drm/gem: Drop struct_mutex requirement from
    drm_gem_mmap_obj" ]

    * 'drm-next' of git://people.freedesktop.org/~airlied/linux: (764 commits)
    drm/vmwgfx: Relax irq locking somewhat
    drm/vmwgfx: Properly flush cursor updates and page-flips
    drm/i915/skl: disable display side power well support for now
    drm/i915: Extend DSL readout fix to BDW and SKL.
    drm/i915: Do graphics device reset under forcewake
    drm/i915: Skip fence installation for objects with rotated views (v4)
    vga_switcheroo: Drop client power state VGA_SWITCHEROO_INIT
    drm/amdgpu: group together common fence implementation
    drm/amdgpu: remove AMDGPU_FENCE_OWNER_MOVE
    drm/amdgpu: remove now unused fence functions
    drm/amdgpu: fix fence fallback check
    drm/amdgpu: fix stoping the scheduler timeout
    drm/amdgpu: cleanup on error in amdgpu_cs_ioctl()
    drm/i915: Fix locking around GuC firmware load
    drm/amdgpu: update Fiji's Golden setting
    drm/amdgpu: update Fiji's rev id
    drm/amdgpu: extract common code in vi_common_early_init
    drm/amd/scheduler: don't oops on failure to load
    drm/amdgpu: don't oops on failure to load (v2)
    drm/amdgpu: don't VT switch on suspend
    ...

    Linus Torvalds
     

14 Oct, 2015

1 commit

  • Some drivers use member screen_base of struct fb_info to store non-
    __iomem pointers, creating the need for ugly __force typecasts to
    avoid sparse warnings. This adds an alternate pointer without the
    __iomem qualifyer for this use.

    Signed-off-by: Lars Svensson
    Signed-off-by: Greg Kroah-Hartman

    Lars Svensson
     

25 Sep, 2015

1 commit

  • Currently everyone and their dog has their own favourite spelling
    for vga_switcheroo. This makes it hard to grep dmesg for log entries
    relating to vga_switcheroo. It also makes it hard to find related
    source files in the tree.

    vga_switcheroo.c uses pr_fmt "vga_switcheroo". Use that everywhere.

    Signed-off-by: Lukas Wunner
    Signed-off-by: Daniel Vetter

    Lukas Wunner
     

20 Aug, 2015

1 commit

  • CEA defines 64 modes, indexed from 1 to 64. modedb has cea_modes arrays,
    which contains 64 entries. However, the code uses the CEA indices
    directly, i.e. the first mode is at cea_modes[1]. This means the array
    is one too short.

    This does not cause references to uninitialized memory as the code in
    fbmon only allows indexes up to 63, and the cea_modes does not contain
    an entry for the mode 64 so it could not be used in any case.

    However, the code contains a check 'if (idx > ARRAY_SIZE(cea_modes)',
    and while that check is a no-op as at that point idx cannot be >= 63, it
    upsets static checkers.

    Fix this by increasing the cea_array size to be 65, and change the code
    to allow mode 64.

    Signed-off-by: Tomi Valkeinen
    Reported-by: Dan Carpenter

    Tomi Valkeinen
     

15 Jan, 2015

2 commits


01 Jul, 2014

1 commit


02 May, 2014

1 commit

  • Silence the warning when building with -Wsign-compare when fb.h is
    included:

    include/linux/fb.h: In function ‘__fb_pad_aligned_buffer’:
    include/linux/fb.h:650:17: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
    for (j = 0; j < s_pitch; j++)
    ^

    Signed-off-by: Brian W Hart
    Signed-off-by: Tomi Valkeinen

    Brian W Hart
     

22 Apr, 2014

1 commit


18 Dec, 2013

1 commit


29 Oct, 2013

1 commit


27 Jun, 2013

1 commit

  • drm_get_connector_name now returns a const value, which causes the following
    compilation warning:

    drivers/gpu/drm/drm_fb_helper.c: In function ‘drm_fb_helper_parse_command_line’:
    drivers/gpu/drm/drm_fb_helper.c:127:3: warning: passing argument 1 of ‘fb_get_options’ discards ‘const’ qualifier from pointer target type [enabled by default]
    In file included from drivers/gpu/drm/drm_fb_helper.c:35:0:
    include/linux/fb.h:627:12: note: expected ‘char *’ but argument is of type ‘const char *’

    As fb_get_options uses its name argument as read only, make it const. This
    fixes the aforementioned compilation warning.

    Signed-off-by: Vincent Stehlé
    Cc: Jean-Christophe Plagniol-Villard
    Cc: Tomi Valkeinen
    Cc: Dave Airlie
    Cc: trivial@kernel.org
    Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD

    Vincent Stehlé
     

20 Feb, 2013

1 commit


24 Jan, 2013

2 commits

  • Add helper to get fb_videomode from devicetree.

    Signed-off-by: Steffen Trumtrar
    Reviewed-by: Thierry Reding
    Acked-by: Thierry Reding
    Tested-by: Thierry Reding
    Tested-by: Philipp Zabel
    Reviewed-by: Laurent Pinchart
    Acked-by: Laurent Pinchart
    Tested-by: Afzal Mohammed
    Tested-by: Rob Clark
    Tested-by: Leela Krishna Amudala

    Steffen Trumtrar
     
  • Add a function to convert from the generic videomode to a fb_videomode.

    Signed-off-by: Steffen Trumtrar
    Reviewed-by: Thierry Reding
    Acked-by: Thierry Reding
    Tested-by: Thierry Reding
    Tested-by: Philipp Zabel
    Reviewed-by: Laurent Pinchart
    Acked-by: Laurent Pinchart
    Tested-by: Afzal Mohammed
    Tested-by: Rob Clark
    Tested-by: Leela Krishna Amudala

    Steffen Trumtrar
     

13 Oct, 2012

1 commit


02 Jun, 2012

1 commit

  • Pull fbdev updates from Florian Tobias Schandinat:
    - driver for AUO-K1900 and AUO-K1901 epaper controller
    - large updates for OMAP (e.g. decouple HDMI audio and video)
    - some updates for Exynos and SH Mobile
    - various other small fixes and cleanups

    * tag 'fbdev-updates-for-3.5' of git://github.com/schandinat/linux-2.6: (130 commits)
    video: bfin_adv7393fb: Fix cleanup code
    video: exynos_dp: reduce delay time when configuring video setting
    video: exynos_dp: move sw reset prioir to enabling sw defined function
    video: exynos_dp: use devm_ functions
    fb: handle NULL pointers in framebuffer release
    OMAPDSS: HDMI: OMAP4: Update IRQ flags for the HPD IRQ request
    OMAPDSS: Apply VENC timings even if panel is disabled
    OMAPDSS: VENC/DISPC: Delay dividing Y resolution for managers connected to VENC
    OMAPDSS: DISPC: Support rotation through TILER
    OMAPDSS: VRFB: remove compiler warnings when CONFIG_BUG=n
    OMAPFB: remove compiler warnings when CONFIG_BUG=n
    OMAPDSS: remove compiler warnings when CONFIG_BUG=n
    OMAPDSS: DISPC: fix usage of dispc_ovl_set_accu_uv
    OMAPDSS: use DSI_FIFO_BUG workaround only for manual update displays
    OMAPDSS: DSI: Support command mode interleaving during video mode blanking periods
    OMAPDSS: DISPC: Update Accumulator configuration for chroma plane
    drivers/video: fsl-diu-fb: don't initialize the THRESHOLDS registers
    video: exynos mipi dsi: support reverse panel type
    video: exynos mipi dsi: Properly interpret the interrupt source flags
    video: exynos mipi dsi: Avoid races in probe()
    ...

    Linus Torvalds
     

30 May, 2012

1 commit

  • Add FB_EARLY_EVENT_BLANK and FB_R_EARLY_EVENT_BLANK event mode supports.
    first, fb_notifier_call_chain() is called with FB_EARLY_EVENT_BLANK and
    fb_blank() of specific fb driver is called and then
    fb_notifier_call_chain() is called with FB_EVENT_BLANK again at
    fb_blank(). and if fb_blank() was failed then fb_nitifier_call_chain()
    would be called with FB_R_EARLY_EVENT_BLANK to revert the previous
    effects.

    Signed-off-by: Inki Dae
    Signed-off-by: Kyungmin Park
    Cc: Lars-Peter Clausen
    Acked-by: Florian Tobias Schandinat
    Cc: Richard Purdie
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Inki Dae
     

30 Apr, 2012

1 commit

  • With this optional callback the driver is notified when the first page
    is entered into the pagelist and a new deferred_io call is scheduled.

    A possible use-case for this is runtime-pm. In the first_io call
    pm_runtime_get()
    could be called, which starts an asynchronous runtime_resume of the
    device. In the deferred_io callback a call to
    pm_runtime_barrier()
    makes the sure, the device is resumed by then and a
    pm_runtime_put()
    may put the device back to sleep.

    Also, some SoCs may use the runtime-pm system to determine if they
    are able to enter deeper idle states. Therefore it is necessary to
    keep the use-count from the first written page until the conclusion
    of the screen update, to prevent the system from going to sleep before
    completing the pending update.

    Two users of defio were using kmalloc to allocate the structure.
    These allocations are changed to kzalloc, to prevent uninitialised
    .first_io members in those drivers.

    Signed-off-by: Heiko Stübner
    Signed-off-by: Florian Tobias Schandinat

    Heiko Stübner
     

25 Mar, 2012

1 commit

  • Pull avoidance patches from Paul Gortmaker:
    "Nearly every subsystem has some kind of header with a proto like:

    void foo(struct device *dev);

    and yet there is no reason for most of these guys to care about the
    sub fields within the device struct. This allows us to significantly
    reduce the scope of headers including headers. For this instance, a
    reduction of about 40% is achieved by replacing the include with the
    simple fact that the device is some kind of a struct.

    Unlike the much larger module.h cleanup, this one is simply two
    commits. One to fix the implicit users, and then one
    to delete the device.h includes from the linux/include/ dir wherever
    possible."

    * tag 'device-for-3.4' of git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux:
    device.h: audit and cleanup users in main include dir
    device.h: cleanup users outside of linux/include (C files)

    Linus Torvalds
     

16 Mar, 2012

1 commit

  • The header includes a lot of stuff, and
    it in turn gets a lot of use just for the basic "struct device"
    which appears so often.

    Clean up the users as follows:

    1) For those headers only needing "struct device" as a pointer
    in fcn args, replace the include with exactly that.

    2) For headers not really using anything from device.h, simply
    delete the include altogether.

    3) For headers relying on getting device.h implicitly before
    being included themselves, now explicitly include device.h

    4) For files in which doing #1 or #2 uncovers an implicit
    dependency on some other header, fix by explicitly adding
    the required header(s).

    Any C files that were implicitly relying on device.h to be
    present have already been dealt with in advance.

    Total removals from #1 and #2: 51. Total additions coming
    from #3: 9. Total other implicit dependencies from #4: 7.

    As of 3.3-rc1, there were 110, so a net removal of 42 gives
    about a 38% reduction in device.h presence in include/*

    Signed-off-by: Paul Gortmaker

    Paul Gortmaker
     

15 Mar, 2012

1 commit

  • The USB graphics card driver delays the unregistering of the framebuffer
    device to a workqueue, which breaks the userspace visible remove uevent
    sequence. Recent userspace tools started to support USB graphics card
    hotplug out-of-the-box and rely on proper events sent by the kernel.

    The framebuffer device is a direct child of the USB interface which is
    removed immediately after the USB .disconnect() callback. But the fb device
    in /sys stays around until its final cleanup, at a time where all the parent
    devices have been removed already.

    To work around that, we remove the sysfs fb device directly in the USB
    .disconnect() callback and leave only the cleanup of the internal fb
    data to the delayed work.

    Before:
    add /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2 (usb)
    add /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0 (usb)
    add /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0/graphics/fb0 (graphics)
    remove /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0 (usb)
    remove /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2 (usb)
    remove /2-1.2:1.0/graphics/fb0 (graphics)

    After:
    add /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2 (usb)
    add /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0 (usb)
    add /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0/graphics/fb1 (graphics)
    remove /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0/graphics/fb1 (graphics)
    remove /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0 (usb)
    remove /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2 (usb)

    Cc: stable@vger.kernel.org
    Tested-by: Bernie Thompson
    Acked-by: Bernie Thompson
    Signed-off-by: Kay Sievers
    Signed-off-by: Florian Tobias Schandinat

    Kay Sievers
     

20 Dec, 2011

1 commit


21 Jul, 2011

1 commit

  • Btrfs needs to be able to control how filemap_write_and_wait_range() is called
    in fsync to make it less of a painful operation, so push down taking i_mutex and
    the calling of filemap_write_and_wait() down into the ->fsync() handlers. Some
    file systems can drop taking the i_mutex altogether it seems, like ext3 and
    ocfs2. For correctness sake I just pushed everything down in all cases to make
    sure that we keep the current behavior the same for everybody, and then each
    individual fs maintainer can make up their mind about what to do from there.
    Thanks,

    Acked-by: Jan Kara
    Signed-off-by: Josef Bacik
    Signed-off-by: Al Viro

    Josef Bacik
     

12 May, 2011

1 commit

  • This just adds the refcount and the new registration lock logic. It
    does not (for example) actually change the read/write/ioctl routines to
    actually use the frame buffer that was opened: those function still end
    up alway susing whatever the current frame buffer is at the time of the
    call.

    Without this, if something holds the frame buffer open over a
    framebuffer switch, the close() operation after the switch will access a
    fb_info that has been free'd by the unregistering of the old frame
    buffer.

    (The read/write/ioctl operations will normally not cause problems,
    because they will - illogically - pick up the new fbcon instead. But a
    switch that happens just as one of those is going on might see problems
    too, the window is just much smaller: one individual op rather than the
    whole open-close sequence.)

    This use-after-free is apparently fairly easily triggered by the Ubuntu
    11.04 boot sequence.

    Acked-by: Tim Gardner
    Tested-by: Daniel J Blueman
    Tested-by: Anca Emanuel
    Cc: Bruno Prémont
    Cc: Alan Cox
    Cc: Paul Mundt
    Cc: Dave Airlie
    Cc: Andy Whitcroft
    Signed-off-by: Linus Torvalds

    Linus Torvalds
     

31 Mar, 2011

1 commit


17 Mar, 2011

1 commit

  • change from original version -- by advice of Paul Mundt
    1. remove videomemorysize definitions
    2. remove unifb_enable and unifb_setup
    3. use dev_warn instead of printk in fb driver
    4. remove judgement for FB_ACCEL_PUV3_UNIGFX
    5. adjust clk_get and clk_set_rate calls
    6. add resources definitions
    7. remove unifb_option
    8. adjust register for platform_device
    9. adjust unifb_ops position and unifb_regs assignment position

    Signed-off-by: Guan Xuetao
    Acked-by: Arnd Bergmann

    GuanXuetao
     

22 Dec, 2010

1 commit


17 Nov, 2010

1 commit

  • There is an integer overflow in fb_set_user_cmap() because cmap->len * 2
    can wrap. It's basically harmless. Your terminal will be messed up
    until you type reset.

    This patch does three things to fix the bug.

    First, it checks the return value of fb_copy_cmap() in fb_alloc_cmap().
    That is enough to fix address the overflow.

    Second it checks for the integer overflow in fb_set_user_cmap().

    Lastly I wanted to cap "cmap->len" in fb_set_user_cmap() much lower
    because it gets used to determine the size of allocation. Unfortunately
    no one knows what the limit should be. Instead what this patch does
    is makes the allocation happen with GFP_KERNEL instead of GFP_ATOMIC
    and lets the kmalloc() decide what values of cmap->len are reasonable.
    To do this, the patch introduces a function called fb_alloc_cmap_gfp()
    which is like fb_alloc_cmap() except that it takes a GFP flag.

    Signed-off-by: Dan Carpenter
    Signed-off-by: Paul Mundt

    Dan Carpenter
     

15 Nov, 2010

2 commits


28 Oct, 2010

1 commit

  • fb_{read,write} access the framebuffer using lots of fb_{read,write}l's
    but don't check that the file position is aligned which can cause problems
    on some architectures which do not support unaligned accesses.

    Since the operations are essentially memcpy_{from,to}io, new
    fb_memcpy_{from,to}fb macros have been defined and these are used instead.

    For Sparc, fb_{read,write} macros use sbus_{read,write}, so this defines
    new sbus_memcpy_{from,to}io functions the same as memcpy_{from,to}io but
    using sbus_{read,write}b instead of {read,write}b.

    Signed-off-by: James Hogan
    Acked-by: David S. Miller
    Acked-by: Florian Tobias Schandinat
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    James Hogan
     

11 Aug, 2010

1 commit

  • Jesse's initial patch commit said:

    "At panic time (i.e. when oops_in_progress is set) we should try a bit
    harder to update the screen and make sure output gets to the VT, since
    some drivers are capable of flipping back to it.

    So make sure we try to unblank and update the display if called from a
    panic context."

    I've enhanced this to add a flag to the vc that console layer can set to
    indicate they want this behaviour to occur. This also adds support to
    fbcon for that flag and adds an fb flag for drivers to indicate they want
    to use the support. It enables this for KMS drivers.

    Signed-off-by: Dave Airlie
    Signed-off-by: Jesse Barnes
    Acked-by: James Simmons
    Cc: Alan Cox
    Signed-off-by: Andrew Morton
    Signed-off-by: Greg Kroah-Hartman

    Jesse Barnes
     

05 Aug, 2010

1 commit

  • Add fb ops to handle enter/exit of the kernel debugger. If present, the
    fb core will register them with KGDB and they'll be called when the
    debugger is entered and exited. The new functions are responsible for
    switching to an appropriate debug framebuffer and restoring the
    interrupted state at exit time.

    Signed-off-by: Jesse Barnes
    Signed-off-by: Jason Wessel

    Jesse Barnes
     

20 Jul, 2010

1 commit