Doug / smarc-fsl-linux-kernel

26 Sep, 2006

1 commit

27 Jun, 2006

1 commit

  • 3e795de76   [PATCH] VT binding: Add binding/unbinding support for the VT console ... Browse Code »

    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

  • 76a8ad293   [PATCH] Make printk work for really early debugging ... Browse Code »

    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

  • 1da177e4c   Linux-2.6.12-rc2 ... Browse Code »

    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