01 Apr, 2006

40 commits

  • The monochrome->color expansion routine that handles bitmaps which have
    (widths % 8) != 0 (slow_imageblit) produces corrupt characters in big-endian.
    This is caused by a bogus bit test in slow_imageblit().

    Fix.

    This patch may deserve to go to the stable tree. The code has already been
    well tested in little-endian machines. It's only in big-endian where there is
    uncertainty and Herbert confirmed that this is the correct way to go.

    It should not introduce regressions.

    Signed-off-by: Antonino Daplas
    Acked-by: Herbert Poetzl
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Antonino A. Daplas
     
  • Fixes for the pxafb driver:

    * Return -EINVAL for resolutions that are too large as per framebuffer
    driver policy.

    * Increase the error timeout for disabling the LCD controller. The current
    timeout is sometimes too short on the Sharp Zaurus Cxx00 hardware and an
    extra delay in an error path shouldn't pose any problems.

    * Fix a dev reference which causes a compile error when DEBUG is defined.

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

    Richard Purdie
     
  • Generalise the Corgi backlight driver by moving the default intensity and
    limit mask settings into the platform specific data structure. This enables
    the driver to support other Zaurus hardware, specifically the SL-6000x (Tosa)
    model.

    Also change the spinlock to a mutex (the spinlock is overkill).

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

    Richard Purdie
     
  • Updates to the HP Jornada 680 Backlight driver:

    - Correct the suspend/resume functions so the driver compiles
    (SUSPEND_POWER_DOWN/RESUME_POWER_ON no longer exist).

    - Convert the driver to match the recent platform device changes.

    - Replace the unsafe static struct platform_device with dynamic allocation.

    - Convert the driver to the new backlight code.

    This has not been tested on a device due to lack of hardware but wouldn't
    compile beforehand.

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

    Richard Purdie
     
  • Backlight class attributes are currently easy to implement incorrectly.
    Moving certain handling into the backlight core prevents this whilst at the
    same time makes the drivers simpler and consistent. The following changes are
    included:

    The brightness attribute only sets and reads the brightness variable in the
    backlight_properties structure.

    The power attribute only sets and reads the power variable in the
    backlight_properties structure.

    Any framebuffer blanking events change a variable fb_blank in the
    backlight_properties structure.

    The backlight driver has only two functions to implement. One function is
    called when any of the above properties change (to update the backlight
    brightness), the second is called to return the current backlight brightness
    value. A new attribute "actual_brightness" is added to return this brightness
    as determined by the driver having combined all the above factors (and any
    driver/device specific factors).

    Additionally, the backlight core takes care of checking the maximum brightness
    is not exceeded and of turning off the backlight before device removal.

    The corgi backlight driver is updated to reflect these changes.

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

    Richard Purdie
     
  • Add acceleration support in w100fb.c (i.e. ATI Imageons) for the copyarea and
    fillrect operations.

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

    Alberto Mardegan
     
  • The current display was not saved during initialization. This leads to hard
    to track console corruption, such as a misplaced cursor, which is correctible
    by switching consoles. Fix this minor bug.

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

    Antonino A. Daplas
     
  • It is very common to hash a dentry and then to call lookup. If we take fs
    specific hash functions into account the full hash logic can get ugly.
    Further full_name_hash as an inline function is almost 100 bytes on x86 so
    having a non-inline choice in some cases can measurably decrease code size.

    Signed-off-by: Eric W. Biederman
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Eric W. Biederman
     
  • Simplifies the code, reduces the need for 4 pid hash tables, and makes the
    code more capable.

    In the discussions I had with Oleg it was felt that to a large extent the
    cleanup itself justified the work. With struct pid being dynamically
    allocated meant we could create the hash table entry when the pid was
    allocated and free the hash table entry when the pid was freed. Instead of
    playing with the hash lists when ever a process would attach or detach to a
    process.

    For myself the fact that it gave what my previous task_ref patch gave for free
    with simpler code was a big win. The problem is that if you hold a reference
    to struct task_struct you lock in 10K of low memory. If you do that in a user
    controllable way like /proc does, with an unprivileged but hostile user space
    application with typical resource limits of 1000 fds and 100 processes I can
    trigger the OOM killer by consuming all of low memory with task structs, on a
    machine wight 1GB of low memory.

    If I instead hold a reference to struct pid which holds a pointer to my
    task_struct, I don't suffer from that problem because struct pid is 2 orders
    of magnitude smaller. In fact struct pid is small enough that most other
    kernel data structures dwarf it, so simply limiting the number of referring
    data structures is enough to prevent exhaustion of low memory.

    This splits the current struct pid into two structures, struct pid and struct
    pid_link, and reduces our number of hash tables from PIDTYPE_MAX to just one.
    struct pid_link is the per process linkage into the hash tables and lives in
    struct task_struct. struct pid is given an indepedent lifetime, and holds
    pointers to each of the pid types.

    The independent life of struct pid simplifies attach_pid, and detach_pid,
    because we are always manipulating the list of pids and not the hash table.
    In addition in giving struct pid an indpendent life it makes the concept much
    more powerful.

    Kernel data structures can now embed a struct pid * instead of a pid_t and
    not suffer from pid wrap around problems or from keeping unnecessarily
    large amounts of memory allocated.

    Signed-off-by: Eric W. Biederman
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Eric W. Biederman
     
  • A big problem with rcu protected data structures that are also reference
    counted is that you must jump through several hoops to increase the reference
    count. I think someone finally implemented atomic_inc_not_zero(&count) to
    automate the common case. Unfortunately this means you must special case the
    rcu access case.

    When data structures are only visible via rcu in a manner that is not
    determined by the reference count on the object (i.e. tasks are visible until
    their zombies are reaped) there is a much simpler technique we can employ.
    Simply delaying the decrement of the reference count until the rcu interval is
    over.

    What that means is that the proc code that looks up a task and later
    wants to sleep can now do:

    rcu_read_lock();
    task = find_task_by_pid(some_pid);
    if (task) {
    get_task_struct(task);
    }
    rcu_read_unlock();

    The effect on the rest of the kernel is that put_task_struct becomes cheaper
    and immediate, and in the case where the task has been reaped it frees the
    task immediate instead of unnecessarily waiting an until the rcu interval is
    over.

    Cleanup of task_struct does not happen when its reference count drops to
    zero, instead cleanup happens when release_task is called. Tasks can only
    be looked up via rcu before release_task is called. All rcu protected
    members of task_struct are freed by release_task.

    Therefore we can move call_rcu from put_task_struct into release_task. And
    we can modify release_task to not immediately release the reference count
    but instead have it call put_task_struct from the function it gives to
    call_rcu.

    The end result:

    - get_task_struct is safe in an rcu context where we have just looked
    up the task.

    - put_task_struct() simplifies into its old pre rcu self.

    This reorganization also makes put_task_struct uncallable from modules as
    it is not exported but it does not appear to be called from any modules so
    this should not be an issue, and is trivially fixed.

    Signed-off-by: Eric W. Biederman
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Eric W. Biederman
     
  • proc_check_chroot() does the check in a very unintuitive way (keeping a
    copy of the argument, then modifying the argument), and has uncommented
    sideeffects.

    Signed-off-by: Herbert Poetzl
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Herbert Poetzl
     
  • This just got nuked in mainline. Bring it back because Eric's patches use it.

    Cc: "Eric W. Biederman"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andrew Morton
     
  • The core problem: setsid fails if it is called by init. The effect in 2.6.16
    and the earlier kernels that have this problem is that if you do a "ps -j 1 or
    ps -ej 1" you will see that init and several of it's children have process
    group and session == 0. Instead of process group == session == 1. Despite
    init calling setsid.

    The reason it fails is that daemonize calls set_special_pids(1,1) on kernel
    threads that are launched before /sbin/init is called.

    The only remaining effect in that current->signal->leader == 0 for init
    instead of 1. And the setsid call fails. No one has noticed because
    /sbin/init does not check the return value of setsid.

    In 2.4 where we don't have the pidhash table, and daemonize doesn't exist
    setsid actually works for init.

    I care a lot about pid == 1 not being a special case that we leave broken,
    because of the container/jail work that I am doing.

    - Carefully allow init (pid == 1) to call setsid despite the kernel using
    its session.

    - Use find_task_by_pid instead of find_pid because find_pid taking a
    pidtype is going away.

    Signed-off-by: Eric W. Biederman
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Eric W. Biederman
     
  • The futex timeval is not checked for correctness. The change does not
    break existing applications as the timeval is supplied by glibc (and glibc
    always passes a correct value), but the glibc-internal tests for this
    functionality fail.

    Signed-off-by: Thomas Gleixner
    Signed-off-by: Ingo Molnar
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Thomas Gleixner
     
  • To increase the strength of SCHED_BATCH as a scheduling hint we can
    activate batch tasks on the expired array since by definition they are
    latency insensitive tasks.

    Signed-off-by: Con Kolivas
    Acked-by: Ingo Molnar
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Con Kolivas
     
  • On runqueue time is used to elevate priority in schedule().

    In the code it currently requeues tasks even if their priority is not
    elevated, which would end up placing them at the end of their runqueue
    array effectively delaying them instead of improving their priority.

    Bug spotted by Mike Galbraith

    This patch removes this requeueing.

    Signed-off-by: Con Kolivas
    Acked-by: Ingo Molnar
    Cc: Mike Galbraith
    Cc: Nick Piggin
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Con Kolivas
     
  • Tasks waiting in SLEEP_NONINTERACTIVE state can now get to best priority so
    they need to be included in the idle detection code.

    Signed-off-by: Con Kolivas
    Acked-by: Ingo Molnar
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Con Kolivas
     
  • We watch for tasks that sleep extended periods and don't allow one single
    prolonged sleep period from elevating priority to maximum bonus to prevent cpu
    bound tasks from getting high priority with single long sleeps. There is a
    bug in the current code that also penalises tasks that already have high
    priority. Correct that bug.

    Signed-off-by: Con Kolivas
    Acked-by: Ingo Molnar
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Con Kolivas
     
  • Alterations to the pipe code in the kernel made it possible for relative
    starvation to occur with tasks that slept waiting on a pipe getting unfair
    priority bonuses even if they were otherwise fully cpu bound so the
    TASK_NONINTERACTIVE flag was introduced which prevented any change to
    sleep_avg while sleeping waiting on a pipe. This change also leads to the
    converse though, preventing any priority boost from occurring in truly
    interactive tasks that wait on pipes.

    Convert the TASK_NONINTERACTIVE flag to set sleep_type to SLEEP_NONINTERACTIVE
    which will allow a linear bonus to priority based on sleep time thus allowing
    interactive tasks to get high priority if they sleep enough.

    Signed-off-by: Con Kolivas
    Acked-by: Ingo Molnar
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Con Kolivas
     
  • The activated flag in task_struct is used to track different sleep types and
    its usage is somewhat obfuscated. Convert the variable to an enum with more
    descriptive names without altering the function.

    Signed-off-by: Con Kolivas
    Acked-by: Ingo Molnar
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Con Kolivas
     
  • Currently, count_active_tasks() calls both nr_running() &
    nr_interruptible(). Each of these functions does a "for_each_cpu" & reads
    values from the runqueue of each cpu. Although this is not a lot of
    instructions, each runqueue may be located on different node. Depending on
    the architecture, a unique TLB entry may be required to access each
    runqueue.

    Since there may be more runqueues than cpu TLB entries, a scan of all
    runqueues can trash the TLB. Each memory reference incurs a TLB miss &
    refill.

    In addition, the runqueue cacheline that contains nr_running &
    nr_uninterruptible may be evicted from the cache between the two passes.
    This causes unnecessary cache misses.

    Combining nr_running() & nr_interruptible() into a single function
    substantially reduces the TLB & cache misses on large systems. This should
    have no measureable effect on smaller systems.

    On a 128p IA64 system running a memory stress workload, the new function
    reduced the overhead of calc_load() from 605 usec/call to 324 usec/call.

    Signed-off-by: Jack Steiner
    Acked-by: Ingo Molnar
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jack Steiner
     
  • It seems that run_hrtimer_queue() is calling get_softirq_time() more
    often than it needs to.

    With this patch, it only calls get_softirq_time() if there's a
    pending timer.

    Signed-off-by: Dimitri Sivanich
    Signed-off-by: Thomas Gleixner
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Dimitri Sivanich
     
  • Replace the nanosleep private sleeper functionality by the generic hrtimer
    sleeper.

    Signed-off-by: Thomas Gleixner
    Signed-off-by: Ingo Molnar
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Thomas Gleixner
     
  • The removal of the data field in the hrtimer structure enforces the
    embedding of the timer into another data structure. nanosleep now uses a
    private implementation of the most common used timer callback function
    (simple task wakeup).

    In order to avoid the reimplentation of such functionality all over the
    place a generic hrtimer_sleeper functionality is created.

    Signed-off-by: Thomas Gleixner
    Signed-off-by: Ingo Molnar
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Thomas Gleixner
     
  • Add an LED trigger for IDE disk activity to the ide-disk driver.

    Signed-off-by: Richard Purdie
    Acked-by: Bartlomiej Zolnierkiewicz
    Cc: Alan Cox
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Richard Purdie
     
  • Ensure ide-taskfile.c calls any driver specific end_request function if
    present.

    Signed-off-by: Richard Purdie
    Cc: Alan Cox
    Acked-by: Bartlomiej Zolnierkiewicz
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Richard Purdie
     
  • Cc: Russell King
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Richard Purdie
     
  • Adds LED drivers for LEDs found on the Sharp Zaurus c6000 model (tosa).

    Signed-off-by: Dirk Opfer
    Signed-off-by: Richard Purdie
    Cc: Russell King
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Dirk Opfer
     
  • NEW_LEDS support for ixp4xx boards where LEDs are connected to the GPIO lines.

    This includes a new generic ixp4xx driver (leds-ixp4xx-gpio.c name
    "IXP4XX-GPIO-LED")

    Signed-off-by: John Bowler
    Signed-off-by: Richard Purdie
    Cc: Russell King
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    John Bowler
     
  • Adds an LED driver for LEDs exported by the Sharp LOCOMO chip as found on some
    models of Sharp Zaurus.

    Signed-off-by: Richard Purdie
    Cc: Russell King
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Richard Purdie
     
  • Adds LED drivers for LEDs found on the Sharp Zaurus c7x0 (corgi, shepherd,
    husky) and cxx00 (akita, spitz, borzoi) models.

    Signed-off-by: Richard Purdie
    Cc: Russell King
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Richard Purdie
     
  • Add an LED trigger for the charger status as found on the Sharp Zaurus series
    of devices.

    Signed-off-by: Richard Purdie
    Acked-by: Pavel Machek
    Cc: Russell King
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Richard Purdie
     
  • Add an example of a complex LED trigger in the form of a generic timer which
    triggers the LED its attached to at a user specified frequency and duty cycle.

    Signed-off-by: Richard Purdie
    Cc: Russell King
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Richard Purdie
     
  • Add support for LED triggers to the LED subsystem. "Triggers" are events
    which change the state of an LED. Two kinds of trigger are available, simple
    ones which can be added to exising code with minimum disruption and complex
    ones for implementing new or more complex functionality.

    Signed-off-by: Richard Purdie
    Cc: Russell King
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Richard Purdie
     
  • Add the foundations of a new LEDs subsystem. This patch adds a class which
    presents LED devices within sysfs and allows their brightness to be
    controlled.

    Signed-off-by: Richard Purdie
    Cc: Russell King
    Cc: Greg KH
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Richard Purdie
     
  • The LED class/subsystem takes John Lenz's work and extends and alters it to
    give what I think should be a fairly universal LED implementation.

    The series consists of several logical units:

    * LED Core + Class implementation
    * LED Trigger Core implementation
    * LED timer trigger (example of a complex trigger)
    * LED device drivers for corgi, spitz and tosa Zaurus models
    * LED device driver for locomo LEDs
    * LED device driver for ARM ixp4xx LEDs
    * Zaurus charging LED trigger
    * IDE disk activity LED trigger
    * NAND MTD activity LED trigger

    Why?
    ====

    LEDs are really simple devices usually amounting to a GPIO that can be turned
    on and off so why do we need all this code? On handheld or embedded devices
    they're an important part of an often limited user interface. Both users and
    developers want to be able to control and configure what the LED does and the
    number of different things they'd potentially want the LED to show is large.

    A subsystem is needed to try and provide all this different functionality in
    an architecture independent, simple but complete, generic and scalable manner.

    The alternative is for everyone to implement just what they need hidden away
    in different corners of the kernel source tree and to provide an inconsistent
    interface to userspace.

    Other Implementations
    =====================

    I'm aware of the existing arm led implementation. Currently the new subsystem
    and the arm code can coexist quite happily. Its up to the arm community to
    decide whether this new interface is acceptable to them. As far as I can see,
    the new interface can do everything the existing arm implementation can with
    the advantage that the new code is architecture independent and much more
    generic, configurable and scalable.

    I'm prepared to make the conversion to the LED subsystem (or assist with it)
    if appropriate.

    Implementation Details
    ======================

    I've stripped a lot of code out of John's original LED class. Colours were
    removed as LED colour is now part of the device name. Multiple colours are to
    be handled as multiple led devices. This means you get full control over each
    colour. I also removed the LED hardware timer code as the generic timer isn't
    going to add much overhead and is just as useful. I also decided to have the
    LED core track the current LED status (to ease suspend/resume handling)
    removing the need for brightness_get implementations in the LED drivers.

    An underlying design philosophy is simplicity. The aim is to keep a small
    amount of code giving as much functionality as possible.

    The major new idea is the led "trigger". A trigger is a source of led events.
    Triggers can either be simple or complex. A simple trigger isn't
    configurable and is designed to slot into existing subsystems with minimal
    additional code. Examples are the ide-disk, nand-disk and zaurus-charging
    triggers. With leds disabled, the code optimises away. Examples are
    nand-disk and ide-disk.

    Complex triggers whilst available to all LEDs have LED specific parameters and
    work on a per LED basis. The timer trigger is an example.

    You can change triggers in a similar manner to the way an IO scheduler is
    chosen (via /sys/class/leds/somedevice/trigger).

    So far there are only a handful of examples but it should easy to add further
    LED triggers without too much interference into other subsystems.

    Known Issues
    ============

    The LED Trigger core cannot be a module as the simple trigger functions would
    cause nightmare dependency issues. I see this as a minor issue compared to
    the benefits the simple trigger functionality brings. The rest of the LED
    subsystem can be modular.

    Some leds can be programmed to flash in hardware. As this isn't a generic LED
    device property, I think this should be exported as a device specific sysfs
    attribute rather than part of the class if this functionality is required (eg.
    to keep the led flashing whilst the device is suspended).

    Future Development
    ==================

    At the moment, a trigger can't be created specifically for a single LED.
    There are a number of cases where a trigger might only be mappable to a
    particular LED. The addition of triggers provided by the LED driver should
    cover this option and be possible to add without breaking the current
    interface.

    A CPU activity trigger similar to that found in the arm led implementation
    should be trivial to add.

    This patch:

    Add some brief documentation of the design decisions behind the LED class and
    how it appears to users.

    Signed-off-by: Richard Purdie
    Cc: Russell King
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Richard Purdie
     
  • One of the LEDs driver files wants to use this.

    Probably drivers/mtd/maps/ipaq-flash.c wants to convert as well - right now
    it'll be tainting the kernel.

    Cc: David Woodhouse
    Cc: Thomas Gleixner
    Cc: John Bowler
    Cc: "'Richard Purdie'"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andrew Morton
     
  • Add TIOCL_GETKMSGREDIRECT needed by the userland suspend tool to get the
    current value of kmsg_redirect from the kernel so that it can save it and
    restore it after resume.

    Signed-off-by: Rafael J. Wysocki
    Acked-by: Pavel Machek
    Cc: Michael Kerrisk
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Rafael J. Wysocki
     
  • Fix a few memory leaks in drivers/isdn/sc/ioctl.c::sc_ioctl()

    Signed-off-by: Jesper Juhl
    Acked-by: Karsten Keil
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jesper Juhl
     
  • Delete two useless kmalloc wrappers and use kmalloc/kzalloc. Some weird
    NULL checks are also simplified.

    Signed-off-by: Tobias Klauser
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Tobias Klauser