21 May, 2013

2 commits


30 Apr, 2013

1 commit

  • The early console implementations are the same all over the place. Move
    the print function to kernel/printk and get rid of the copies.

    [akpm@linux-foundation.org: arch/mips/kernel/early_printk.c needs kernel.h for va_list]
    [paul.gortmaker@windriver.com: sh4: make the bios early console support depend on EARLY_PRINTK]
    Signed-off-by: Thomas Gleixner
    Signed-off-by: Paul Gortmaker
    Cc: Russell King
    Acked-by: Mike Frysinger
    Cc: Michal Simek
    Cc: Ralf Baechle
    Cc: Benjamin Herrenschmidt
    Cc: Paul Mundt
    Cc: "David S. Miller"
    Cc: Chris Metcalf
    Cc: Richard Weinberger
    Reviewed-by: Ingo Molnar
    Tested-by: Paul Gortmaker
    Cc: Geert Uytterhoeven
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Thomas Gleixner
     

26 Feb, 2013

1 commit

  • Pull drm merge from Dave Airlie:
    "Highlights:

    - TI LCD controller KMS driver

    - TI OMAP KMS driver merged from staging

    - drop gma500 stub driver

    - the fbcon locking fixes

    - the vgacon dirty like zebra fix.

    - open firmware videomode and hdmi common code helpers

    - major locking rework for kms object handling - pageflip/cursor
    won't block on polling anymore!

    - fbcon helper and prime helper cleanups

    - i915: all over the map, haswell power well enhancements, valleyview
    macro horrors cleaned up, killing lots of legacy GTT code,

    - radeon: CS ioctl unification, deprecated UMS support, gpu reset
    rework, VM fixes

    - nouveau: reworked thermal code, external dp/tmds encoder support
    (anx9805), fences sleep instead of polling,

    - exynos: all over the driver fixes."

    Lovely conflict in radeon/evergreen_cs.c between commit de0babd60d8d
    ("drm/radeon: enforce use of radeon_get_ib_value when reading user cmd")
    and the new changes that modified that evergreen_dma_cs_parse()
    function.

    * 'drm-next' of git://people.freedesktop.org/~airlied/linux: (508 commits)
    drm/tilcdc: only build on arm
    drm/i915: Revert hdmi HDP pin checks
    drm/tegra: Add list of framebuffers to debugfs
    drm/tegra: Fix color expansion
    drm/tegra: Split DC_CMD_STATE_CONTROL register write
    drm/tegra: Implement page-flipping support
    drm/tegra: Implement VBLANK support
    drm/tegra: Implement .mode_set_base()
    drm/tegra: Add plane support
    drm/tegra: Remove bogus tegra_framebuffer structure
    drm: Add consistency check for page-flipping
    drm/radeon: Use generic HDMI infoframe helpers
    drm/tegra: Use generic HDMI infoframe helpers
    drm: Add EDID helper documentation
    drm: Add HDMI infoframe helpers
    video: Add generic HDMI infoframe helpers
    drm: Add some missing forward declarations
    drm: Move mode tables to drm_edid.c
    drm: Remove duplicate drm_mode_cea_vic()
    gma500: Fix n, m1 and m2 clock limits for sdvo and lvds
    ...

    Linus Torvalds
     

08 Feb, 2013

2 commits

  • I've still got lockdep warnings even after Alan's patch, and it seems that
    yet more band aids are required to paper over similar paths for
    unbind_con_driver() and unregister_con_driver(). After this hack, lockdep
    warnings are finally gone.

    Signed-off-by: Takashi Iwai
    Cc: Alan Cox
    Cc: Florian Tobias Schandinat
    Cc: Jiri Kosina
    Cc: stable
    Tested-by: Sedat Dilek
    Signed-off-by: Andrew Morton
    Signed-off-by: Dave Airlie

    Takashi Iwai
     
  • Adjust the console layer to allow a take over call where the caller
    already holds the locks. Make the fb layer lock in order.

    This is partly a band aid, the fb layer is terminally confused about the
    locking rules it uses for its notifiers it seems.

    [akpm@linux-foundation.org: remove stray non-ascii char, tidy comment]
    [akpm@linux-foundation.org: export do_take_over_console()]
    [airlied: cleanup another non-ascii char]
    Signed-off-by: Alan Cox
    Cc: Florian Tobias Schandinat
    Cc: Stephen Rothwell
    Cc: Jiri Kosina
    Cc: stable
    Tested-by: Sedat Dilek
    Reviewed-by: Daniel Vetter
    Signed-off-by: Andrew Morton
    Signed-off-by: Dave Airlie

    Alan Cox
     

19 Jan, 2013

1 commit

  • The option allows you to remove TTY and compile without errors. This
    saves space on systems that won't support TTY interfaces anyway.
    bloat-o-meter output is below.

    The bulk of this patch consists of Kconfig changes adding "depends on
    TTY" to various serial devices and similar drivers that require the TTY
    layer. Ideally, these dependencies would occur on a common intermediate
    symbol such as SERIO, but most drivers "select SERIO" rather than
    "depends on SERIO", and "select" does not respect dependencies.

    bloat-o-meter output comparing our previous minimal to new minimal by
    removing TTY. The list is filtered to not show removed entries with awk
    '$3 != "-"' as the list was very long.

    add/remove: 0/226 grow/shrink: 2/14 up/down: 6/-35356 (-35350)
    function old new delta
    chr_dev_init 166 170 +4
    allow_signal 80 82 +2
    static.__warned 143 142 -1
    disallow_signal 63 62 -1
    __set_special_pids 95 94 -1
    unregister_console 126 121 -5
    start_kernel 546 541 -5
    register_console 593 588 -5
    copy_from_user 45 40 -5
    sys_setsid 128 120 -8
    sys_vhangup 32 19 -13
    do_exit 1543 1526 -17
    bitmap_zero 60 40 -20
    arch_local_irq_save 137 117 -20
    release_task 674 652 -22
    static.spin_unlock_irqrestore 308 260 -48

    Signed-off-by: Joe Millenbach
    Reviewed-by: Jamey Sharp
    Reviewed-by: Josh Triplett
    Signed-off-by: Greg Kroah-Hartman

    Joe Millenbach
     

12 Oct, 2012

1 commit

  • The con_debug_leave/con_debug_enter functions are stubbed out
    by defining them to (0), which causes harmless build warnings.
    Using proper inline functions is the normal way to deal with
    this.

    Without this patch, building the ARM bcm2835_defconfig results in:

    drivers/tty/serial/kgdboc.c: In function 'kgdboc_pre_exp_handler':
    drivers/tty/serial/kgdboc.c:279:3: warning: statement with no effect [-Wunused-value]
    drivers/tty/serial/kgdboc.c: In function 'kgdboc_post_exp_handler':
    drivers/tty/serial/kgdboc.c:293:3: warning: statement with no effect [-Wunused-value]

    Signed-off-by: Arnd Bergmann
    Cc: Anton Vorontsov
    Cc: Greg Kroah-Hartman
    Signed-off-by: Jason Wessel

    Arnd Bergmann
     

13 Jan, 2012

1 commit


26 Jan, 2011

1 commit

  • The -rt patches change the console_semaphore to console_mutex. As a
    result, a quite large chunk of the patches changes all
    acquire/release_console_sem() to acquire/release_console_mutex()

    This commit makes things use more neutral function names which dont make
    implications about the underlying lock.

    The only real change is the return value of console_trylock which is
    inverted from try_acquire_console_sem()

    This patch also paves the way to switching console_sem from a semaphore to
    a mutex.

    [akpm@linux-foundation.org: coding-style fixes]
    [akpm@linux-foundation.org: make console_trylock return 1 on success, per Geert]
    Signed-off-by: Torben Hohn
    Cc: Thomas Gleixner
    Cc: Greg KH
    Cc: Ingo Molnar
    Cc: Geert Uytterhoeven
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Torben Hohn
     

17 Dec, 2010

1 commit

  • tty: add 'active' sysfs attribute to tty0 and console device

    Userspace can query the actual virtual console, and the configured
    console devices behind /dev/tt0 and /dev/console.

    The last entry in the list of devices is the active device, analog
    to the console= kernel command line option.

    The attribute supports poll(), which is raised when the virtual
    console is changed or /dev/console is reconfigured.

    Signed-off-by: Kay Sievers
    Signed-off-by: Greg Kroah-Hartman

    index 0000000..b138b66

    Kay Sievers
     

17 Nov, 2010

1 commit


07 Aug, 2010

1 commit

  • A regression of building without CONFIG_HW_CONSOLE was introduced with
    commit b45cfba4e9005d64d419718e7ff7f7cab44c1994 (vt,console,kdb:
    implement atomic console enter/leave functions).

    ERROR: "con_debug_enter" [drivers/serial/kgdboc.ko] undefined!
    ERROR: "vc_cons" [drivers/serial/kgdboc.ko] undefined!
    ERROR: "fg_console" [drivers/serial/kgdboc.ko] undefined!
    ERROR: "con_debug_leave" [drivers/serial/kgdboc.ko] undefined!

    When there is no HW console the con_debug_enter and con_debug_leave
    functions should have no code.

    Signed-off-by: Jason Wessel
    CC: Jesse Barnes
    Reported-by: Randy Dunlap

    Jason Wessel
     

05 Aug, 2010

1 commit


25 Mar, 2009

1 commit

  • During bootup performance tracing I noticed many occurrences of
    vca* device creation and removal, leading to the usual userspace
    uevent processing, which are, in this case, rather pointless.

    A simple test showing the kernel timing (not including all the
    work userspace has to do), gives us these numbers:
    $ time for i in `seq 1000`; do echo a > /dev/tty2; done
    real 0m1.142s
    user 0m0.015s
    sys 0m0.540s

    If we move the hook for the vcs* driver core devices from the
    tty "binding" to the vc allocation/deallocation, which is what
    the vcs* devices represent, we get the following numbers:
    $ time for i in `seq 1000`; do echo a > /dev/tty2; done
    real 0m0.152s
    user 0m0.030s
    sys 0m0.072s

    Cc: Alan Cox
    Signed-off-by: Kay Sievers
    Signed-off-by: Greg Kroah-Hartman

    Kay Sievers
     

29 Dec, 2008

1 commit

  • Add mode setting support to the DRM layer.

    This is a fairly big chunk of work that allows DRM drivers to provide
    full output control and configuration capabilities to userspace. It was
    motivated by several factors:
    - the fb layer's APIs aren't suited for anything but simple
    configurations
    - coordination between the fb layer, DRM layer, and various userspace
    drivers is poor to non-existent (radeonfb excepted)
    - user level mode setting drivers makes displaying panic & oops
    messages more difficult
    - suspend/resume of graphics state is possible in many more
    configurations with kernel level support

    This commit just adds the core DRM part of the mode setting APIs.
    Driver specific commits using these new structure and APIs will follow.

    Co-authors: Jesse Barnes , Jakob Bornecrantz
    Contributors: Alan Hourihane , Maarten Maathuis

    Signed-off-by: Jesse Barnes
    Signed-off-by: Eric Anholt
    Signed-off-by: Dave Airlie

    Dave Airlie
     

27 May, 2008

1 commit

  • Without console= arguments on the kernel command line, the first
    console to register becomes enabled and the preferred console (the one
    behind /dev/console). This is normally tty (assuming
    CONFIG_VT_CONSOLE is enabled, which it commonly is).

    This is okay as long tty is a useful console. But unless we have the
    PV framebuffer, and it is enabled for this domain, tty0 in domU is
    merely a dummy. In that case, we want the preferred console to be the
    Xen console hvc0, and we want it without having to fiddle with the
    kernel command line. Commit b8c2d3dfbc117dff26058fbac316b8acfc2cb5f7
    did that for us.

    Since we now have the PV framebuffer, we want to enable and prefer tty
    again, but only when PVFB is enabled. But even then we still want to
    enable the Xen console as well.

    Problem: when tty registers, we can't yet know whether the PVFB is
    enabled. By the time we can know (xenstore is up), the console setup
    game is over.

    Solution: enable console tty by default, but keep hvc as the preferred
    console. Change the preferred console to tty when PVFB probes
    successfully, unless we've been given console kernel parameters.

    Signed-off-by: Markus Armbruster
    Signed-off-by: Jeremy Fitzhardinge
    Signed-off-by: Thomas Gleixner

    Markus Armbruster
     

30 Apr, 2008

1 commit

  • This adds a minimalistic braille screen reader support. This is meant to
    be used by blind people e.g. on boot failures or when / cannot be mounted
    etc and thus the userland screen readers can not work.

    [akpm@linux-foundation.org: fix exports]
    Signed-off-by: Samuel Thibault
    Cc: Jiri Kosina
    Cc: Dmitry Torokhov
    Acked-by: Alan Cox
    Cc: Randy Dunlap
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Samuel Thibault
     

19 Oct, 2007

1 commit

  • Currently, there's a CONFIG_DISABLE_CONSOLE_SUSPEND that allows one to stop
    the serial console from being suspended when the rest of the machine goes
    to sleep. This is incredibly useful for debugging power management-related
    things; however, having it as a compile-time option has proved to be
    incredibly inconvenient for us (OLPC). There are plenty of times that we
    want serial console to not suspend, but for the most part we'd like serial
    console to be suspended.

    This drops CONFIG_DISABLE_CONSOLE_SUSPEND, and replaces it with a kernel
    boot parameter (no_console_suspend). By default, the serial console will
    be suspended along with the rest of the system; by passing
    'no_console_suspend' to the kernel during boot, serial console will remain
    alive during suspend.

    For now, this is pretty serial console specific; further fixes could be
    applied to make this work for things like netconsole.

    Signed-off-by: Andres Salomon
    Acked-by: "Rafael J. Wysocki"
    Acked-by: Pavel Machek
    Cc: Nigel Cunningham
    Cc: Russell King
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andres Salomon
     

17 Oct, 2007

1 commit

  • Various console drivers are able to resize the screen via the con_resize()
    hook. This hook is also visible in userspace via the TIOCWINSZ, VT_RESIZE and
    VT_RESIZEX ioctl's. One particular utility, SVGATextMode, expects that
    con_resize() of the VGA console will always return success even if the
    resulting screen is not compatible with the hardware. However, this
    particular behavior of the VGA console, as reported in Kernel Bugzilla Bug
    7513, can cause undefined behavior if the user starts with a console size
    larger than 80x25.

    To work around this problem, add an extra parameter to con_resize(). This
    parameter is ignored by drivers except for vgacon. If this parameter is
    non-zero, then the resize request came from a VT_RESIZE or VT_RESIZEX ioctl
    and vgacon will always return success. If this parameter is zero, vgacon will
    return -EINVAL if the requested size is not compatible with the hardware. The
    latter is the more correct behavior.

    With this change, SVGATextMode should still work correctly while in-kernel and
    stty resize calls can expect correct behavior from vgacon.

    Signed-off-by: Antonino Daplas
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Antonino A. Daplas
     

17 Jul, 2007

2 commits

  • Remove the obviously unnecessary includes of under the
    include/linux/ directory, and fix the couple errors that are introduced as
    a result of that.

    Signed-off-by: Robert P. J. Day
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Robert P. J. Day
     
  • Beacuse SERIAL_PORT_DFNS is removed from include/asm-i386/serial.h and
    include/asm-x86_64/serial.h. the serial8250_ports need to be probed late in
    serial initializing stage. the console_init=>serial8250_console_init=>
    register_console=>serial8250_console_setup will return -ENDEV, and console
    ttyS0 can not be enabled at that time. need to wait till uart_add_one_port in
    drivers/serial/serial_core.c to call register_console to get console ttyS0.
    that is too late.

    Make early_uart to use early_param, so uart console can be used earlier. Make
    it to be bootconsole with CON_BOOT flag, so can use console handover feature.
    and it will switch to corresponding normal serial console automatically.

    new command line will be:
    console=uart8250,io,0x3f8,9600n8
    console=uart8250,mmio,0xff5e0000,115200n8
    or
    earlycon=uart8250,io,0x3f8,9600n8
    earlycon=uart8250,mmio,0xff5e0000,115200n8

    it will print in very early stage:
    Early serial console at I/O port 0x3f8 (options '9600n8')
    console [uart0] enabled
    later for console it will print:
    console handover: boot [uart0] -> real [ttyS0]

    Signed-off-by:
    Cc: Andi Kleen
    Cc: Bjorn Helgaas
    Cc: Russell King
    Cc: Gerd Hoffmann
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Yinghai Lu
     

09 May, 2007

2 commits


12 Feb, 2007

1 commit


03 Oct, 2006

1 commit


26 Sep, 2006

1 commit


27 Jun, 2006

1 commit

  • The framebuffer console is now able to dynamically bind and unbind from the VT
    console layer. Due to the way the VT console layer works, the drivers
    themselves decide when to bind or unbind. However, it was decided that
    binding must be controlled, not by the drivers themselves, but by the VT
    console layer. With this, dynamic binding is possible for all VT console
    drivers, not just fbcon.

    Thus, the VT console layer will impose the following to all VT console
    drivers:

    - all registered VT console drivers will be entered in a private list
    - drivers can register themselves to the VT console layer, but they cannot
    decide when to bind or unbind. (Exception: To maintain backwards
    compatibility, take_over_console() will automatically bind the driver after
    registration.)
    - drivers can remove themselves from the list by unregistering from the VT
    console layer. A prerequisite for unregistration is that the driver must not
    be bound.

    The following functions are new in the vt.c:

    register_con_driver() - public function, this function adds the VT console
    driver to an internal list maintained by the VT console

    bind_con_driver() - private function, it binds the driver to the console

    take_over_console() is changed to call register_con_driver() followed by a
    bind_con_driver(). This is the only time drivers can decide when to bind to
    the VT layer. This is to maintain backwards compatibility.

    unbind_con_driver() - private function, it unbinds the driver from its
    console. The vacated consoles will be taken over by the default boot console
    driver.

    unregister_con_driver() - public function, removes the driver from the
    internal list maintained by the VT console. It will only succeed if the
    driver is currently unbound.

    con_is_bound() checks if the driver is currently bound or not

    give_up_console() is just a wrapper to unregister_con_driver().

    There are also 3 additional functions meant to be called only by the tty layer
    for sysfs control:

    vt_bind() - calls bind_con_driver()
    vt_unbind() - calls unbind_con_driver()
    vt_show_drivers() - shows the list of registered drivers

    Most VT console drivers will continue to work as is, but might have problems
    when unbinding or binding which should be fixable with minimal changes.

    Signed-off-by: Antonino Daplas
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Antonino A. Daplas
     

26 Jun, 2006

1 commit

  • Currently printk is no use for early debugging because it refuses to
    actually print anything to the console unless
    cpu_online(smp_processor_id()) is true.

    The stated explanation is that console drivers may require per-cpu
    resources, or otherwise barf, because the system is not yet setup
    correctly. Fair enough.

    However some console drivers might be quite happy running early during
    boot, in fact we have one, and so it'd be nice if printk understood that.

    So I added a flag (which I would have called CON_BOOT, but that's taken)
    called CON_ANYTIME, which indicates that a console is happy to be called
    anytime, even if the cpu is not yet online.

    Tested on a Power 5 machine, with both a CON_ANYTIME driver and a bogus
    console driver that BUG()s if called while offline. No problems AFAICT.
    Built for i386 UP & SMP.

    Signed-off-by: Michael Ellerman
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Michael Ellerman
     

20 Jun, 2006

1 commit


17 Apr, 2005

1 commit

  • Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds