07 Jul, 2010

1 commit


02 Jul, 2010

2 commits


01 Jun, 2010

1 commit


27 Apr, 2010

2 commits


30 Mar, 2010

1 commit

  • …it slab.h inclusion from percpu.h

    percpu.h is included by sched.h and module.h and thus ends up being
    included when building most .c files. percpu.h includes slab.h which
    in turn includes gfp.h making everything defined by the two files
    universally available and complicating inclusion dependencies.

    percpu.h -> slab.h dependency is about to be removed. Prepare for
    this change by updating users of gfp and slab facilities include those
    headers directly instead of assuming availability. As this conversion
    needs to touch large number of source files, the following script is
    used as the basis of conversion.

    http://userweb.kernel.org/~tj/misc/slabh-sweep.py

    The script does the followings.

    * Scan files for gfp and slab usages and update includes such that
    only the necessary includes are there. ie. if only gfp is used,
    gfp.h, if slab is used, slab.h.

    * When the script inserts a new include, it looks at the include
    blocks and try to put the new include such that its order conforms
    to its surrounding. It's put in the include block which contains
    core kernel includes, in the same order that the rest are ordered -
    alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
    doesn't seem to be any matching order.

    * If the script can't find a place to put a new include (mostly
    because the file doesn't have fitting include block), it prints out
    an error message indicating which .h file needs to be added to the
    file.

    The conversion was done in the following steps.

    1. The initial automatic conversion of all .c files updated slightly
    over 4000 files, deleting around 700 includes and adding ~480 gfp.h
    and ~3000 slab.h inclusions. The script emitted errors for ~400
    files.

    2. Each error was manually checked. Some didn't need the inclusion,
    some needed manual addition while adding it to implementation .h or
    embedding .c file was more appropriate for others. This step added
    inclusions to around 150 files.

    3. The script was run again and the output was compared to the edits
    from #2 to make sure no file was left behind.

    4. Several build tests were done and a couple of problems were fixed.
    e.g. lib/decompress_*.c used malloc/free() wrappers around slab
    APIs requiring slab.h to be added manually.

    5. The script was run on all .h files but without automatically
    editing them as sprinkling gfp.h and slab.h inclusions around .h
    files could easily lead to inclusion dependency hell. Most gfp.h
    inclusion directives were ignored as stuff from gfp.h was usually
    wildly available and often used in preprocessor macros. Each
    slab.h inclusion directive was examined and added manually as
    necessary.

    6. percpu.h was updated not to include slab.h.

    7. Build test were done on the following configurations and failures
    were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
    distributed build env didn't work with gcov compiles) and a few
    more options had to be turned off depending on archs to make things
    build (like ipr on powerpc/64 which failed due to missing writeq).

    * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
    * powerpc and powerpc64 SMP allmodconfig
    * sparc and sparc64 SMP allmodconfig
    * ia64 SMP allmodconfig
    * s390 SMP allmodconfig
    * alpha SMP allmodconfig
    * um on x86_64 SMP allmodconfig

    8. percpu.h modifications were reverted so that it could be applied as
    a separate patch and serve as bisection point.

    Given the fact that I had only a couple of failures from tests on step
    6, I'm fairly confident about the coverage of this conversion patch.
    If there is a breakage, it's likely to be something in one of the arch
    headers which should be easily discoverable easily on most builds of
    the specific arch.

    Signed-off-by: Tejun Heo <tj@kernel.org>
    Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>

    Tejun Heo
     

08 Jan, 2010

1 commit


02 Dec, 2009

1 commit

  • In current vblank-wait implementation, if we turn off VGA output,
    drm_wait_vblank will still wait on the disabled pipe until timeout,
    because vblank on the pipe is assumed be enabled. This would cause
    slow system response on some system such as moblin.

    This patch resolve the issue by adding a drm helper function
    drm_vblank_off which explicitly clear vblank_enabled[crtc], wake up
    any waiting queue and save last vblank counter before turning off
    crtc. It also slightly change drm_vblank_get to ensure that we will
    will return immediately if trying to wait on a disabled pipe.

    Signed-off-by: Li Peng
    Reviewed-by: Jesse Barnes
    [anholt: hand-applied for conflicts with overlay changes]
    Signed-off-by: Eric Anholt

    Li Peng
     

18 Nov, 2009

2 commits

  • If we queue a vblank event but miss it, we should return the actual
    sequence number we queued to userspace, so its event handling function
    will know which event to look for.

    Acked-by: Kristian Høgsberg
    Signed-off-by: Jesse Barnes
    Signed-off-by: Dave Airlie

    Jesse Barnes
     
  • This patch adds a new flag to the drmWaitVblank ioctl, which asks the drm
    to return immediately and notify userspace when the specified vblank sequence
    happens by sending an event back on the drm fd.

    The event mechanism works with the other flags supported by the ioctls,
    specifically, the vblank sequence can be specified relatively or absolutely,
    and works for primary and seconday crtc.

    The signal field of the vblank request is used to provide user data,
    which will be sent back to user space in the vblank event.

    Signed-off-by: Kristian Høgsberg
    Reviewed-by: Jesse Barnes
    Signed-off-by: Dave Airlie

    Kristian Høgsberg
     

21 Sep, 2009

1 commit

  • VGA arb requires DRM support for non-kms drivers, to turn on/off
    irqs when disabling the mem/io regions.

    VGA arb requires KMS support for GPUs where we can turn off VGA
    decoding. Currently we know how to do this for intel and radeon
    kms drivers, which allows them to be removed from the arbiter.

    This patch comes from Fedora rawhide kernel.

    Signed-off-by: Dave Airlie

    Dave Airlie
     

09 Aug, 2009

1 commit

  • Some applications/hardware combinations are triggering the message "failed to
    acquire vblank counter" to be issued up to 20 times a second, which makes it
    both useless and dangerous, as this may hide other important messages.
    This changes makes it only appear when people are debugging.

    Signed-off-by: Paul Rolland
    Reviewed-by: Jesse Barnes
    Lost-twice-by: Dave Airlie
    Signed-off-by: Dave Airlie

    Paul Rolland
     

19 Jun, 2009

1 commit


04 Jun, 2009

1 commit

  • allocating devname in the i915 driver was a hack originally and I
    forgot to figure out how to do this properly back then.

    So this is the cleaner version that just picks devname or driver name
    in the irq code.

    It removes the devname allocs from the i915 driver.

    Signed-off-by: Dave Airlie

    Dave Airlie
     

25 Feb, 2009

1 commit


08 Feb, 2009

1 commit

  • In dc1336ff4fe08ae7cfe8301bfd7f0b2cfd31d20a (set vblank enable flag correctly
    across IRQ uninstall), we made sure drivers that uninstall their interrupt
    handler set the vblank enabled flag correctly, so that when interrupts are
    re-enabled, vblank interrupts & counts work as expected. However I missed the
    last_vblank field: it needs to be updated as well, otherwise, at the next
    drm_update_vblank_count we'll end up comparing a current count to a stale
    one (the last one captured by the disable function), which may trigger the
    wraparound handling, leading to a jumpy counter and hangs in drm_wait_vblank.

    The jumpy counter can prevent the DRM_WAIT_ON from returning success if the
    difference between the current count and the requested count is greater than
    2^23, leading to timeouts or hangs, if the ioctl is restarted in a loop (as
    is the case in libdrm < 2.4.4).

    Signed-off-by: Jesse Barnes
    Acked-by: Michel Dänzer
    Tested-by: Timo Aaltonen
    Signed-off-by: Dave Airlie

    Jesse Barnes
     

28 Jan, 2009

1 commit

  • Schedule a vblank signal, kill the process, and we'll go walking over freed
    memory. Given that no open-source userland exists using this, nor have I
    ever heard of a consumer, just let this code die.

    Signed-off-by: Eric Anholt
    Requested-by: Linus Torvalds
    Acked-by: Dave Airlie
    Signed-off-by: Linus Torvalds

    Eric Anholt
     

11 Jan, 2009

1 commit

  • In the absence of kernel mode setting, many drivers disable IRQs across VT
    switch. The core DRM vblank code is missing a check for this case however;
    even after IRQ disable, the vblank code will still have the vblank_enabled
    flag set, so unless we track the fact that they're disabled at IRQ uninstall
    time, when we VT switch back in we won't actually re-enable them, which means
    any apps waiting on vblank before the switch will hang.

    This patch does that and also adds a sanity check to the wait condition to
    look for the irq_enabled flag in general, as well as adding a wakeup to the
    IRQ uninstall path.

    Fixes fdo bug #18879 with compiz hangs at VT switch.

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

    Jesse Barnes
     

29 Dec, 2008

2 commits

  • Signed-off-by: Eric Anholt
    Signed-off-by: Dave Airlie

    Eric Anholt
     
  • 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
     

25 Nov, 2008

1 commit


11 Nov, 2008

1 commit


23 Oct, 2008

1 commit


18 Oct, 2008

3 commits

  • Like the last patch but adds a macro to get at the irq value instead of
    dereferencing pdev directly. Should make things easier for the BSD guys and
    if we ever support non-PCI devices.

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

    Jesse Barnes
     
  • Previously, drivers supporting vblank interrupt waits would run the interrupt
    all the time, or all the time that any 3d client was running, preventing the
    CPU from sleeping for long when the system was otherwise idle. Now, interrupts
    are disabled any time that no client is waiting on a vblank event. The new
    method uses vblank counters on the chipsets when the interrupts are turned
    off, rather than counting interrupts, so that we can continue to present
    accurate vblank numbers.

    Co-author: Michel Dänzer
    Signed-off-by: Jesse Barnes
    Signed-off-by: Eric Anholt
    Signed-off-by: Dave Airlie

    Jesse Barnes
     
  • Previous attempts at interrupt mitigation had been foiled by i915_wait_irq's
    failure to update the sarea seqno value when the status page indicated that
    the seqno had already been passed. MSI support has been seen to cut CPU
    costs by up to 40% in some workloads by avoiding other expensive interrupt
    handlers for frequent graphics interrupts.

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

    Eric Anholt
     

25 Aug, 2008

1 commit


14 Jul, 2008

1 commit

  • With the coming of kernel based modesetting and the memory manager stuff,
    the everything in one directory approach was getting very ugly and
    starting to be unmanageable.

    This restructures the drm along the lines of other kernel components.

    It creates a drivers/gpu/drm directory and moves the hw drivers into
    subdirectores. It moves the includes into an include/drm, and
    sets up the unifdef for the userspace headers we should be exporting.

    Signed-off-by: Dave Airlie

    Dave Airlie