| Age | Commit message (Collapse) | Author |
|---|
|
Add some branch prediction hints.
|
|
BO lock fixes.
|
|
Move unfenced checking into idle checking.
Never time out while waiting for software events like unmapped or unfenced.
|
|
|
|
|
|
Use the new TV property creation routine and fixup the set_property code
to actually do a mode set call when properties change.
|
|
It needs to take arguments from the caller about supported TV formats,
so declare it in drm_crtc.h and export it.
|
|
Cleanup some random cruft left over from the initial port.
|
|
Start i at -1 so that the masking works right.
|
|
Some fields had snuck into the drm_output structure. Put them back and
fill in more stuff from the EDID block.
|
|
Now that we can allocate load detect pipes, we can perform TV out load
detection correctly. Call the new routines and enable proper TV
detection.
|
|
TV out needs to do load detection, which means we have to find an
available pipe to use for the detection. Port over the pipe reservation
code for this purpose.
|
|
|
|
the event for these older kernels.
|
|
Put off registering new outputs with sysfs until they're properly configured,
or we may get duplicates if the type hasn't been set yet (as is the case with
SDVO initialization). This also means moving de-registration into the cleanup
function instead of output destroy, since the latter occurs during the normal
course of setup when an output isn't found (and therefore not registered with
sysfs yet.
|
|
into modesetting-101
|
|
This patch ties outputs, output properties and hotplug events into the
DRM core. Each output has a corresponding directory under the primary
DRM device (usually card0) containing dpms, edid, modes, and connection
status files.
New hotplug change events occur when outputs are added or hotplug events
are detected.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This fixes a problem where the wrong bo->fence_type was reported, and
also saves some memory space.
[bo core] export the drm_bo_fill_rep_arg function.
|
|
|
|
|
|
using contexts for this is bad for multiple masters
|
|
|
|
into modesetting-101
|
|
|
|
Fix that got left out after the intel-post-reloc merge.
|
|
this may not survive long - just need something for testing
|
|
When a master is exiting, make sure we clean it up and not the currently
in charge master.
|
|
When destroying DRI sarea, make sure you use the master associated with the
sarea and not the one currently in charge
|
|
This is the correct fix for the RS690 and hopefully the dma coherent work.
For now we limit everybody to a 32-bit DMA mask but it is possible for
RS690 to use a 40-bit DMA mask for the GART table itself,
and the PCIE cards can use 40-bits for the table entries.
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
|
|
|
|
doesn't fix anything but just making it consistent
|
|
|
|
The i915_vblank_swap() function schedules an automatic buffer swap
upon receipt of the vertical sync interrupt. Such an operation is
lengthy so it can't be allowed to happen in normal interrupt context,
thus the DRM implements this by scheduling the work in a kernel
softirq-scheduled tasklet. In order for the buffer swap to work
safely, the DRM's central lock must be taken, via a call to
drm_lock_take() located in drivers/char/drm/drm_irq.c within the
function drm_locked_tasklet_func(). The lock-taking logic uses a
non-interrupt-blocking spinlock to implement the manipulations needed
to take the lock. This semantic would be safe if all attempts to use
the spinlock only happen from process context. However this buffer
swap happens from softirq context which is really a form of interrupt
context. Thus we have an unsafe situation, in that
drm_locked_tasklet_func() can block on a spinlock already taken by a
thread in process context which will never get scheduled again because
of the blocked softirq tasklet. This wedges the kernel hard.
To trigger this bug, run a dual-head cloned mode configuration which
uses the i915 drm, then execute an opengl application which
synchronizes buffer swaps against the vertical sync interrupt. In my
testing, a lockup always results after running anywhere from 5 minutes
to an hour and a half. I believe dual-head is needed to really
trigger the problem because then the vertical sync interrupt handling
is no longer predictable (due to being interrupt-sourced from two
different heads running at different speeds). This raises the
probability of the tasklet trying to run while the userspace DRI is
doing things to the GPU (and manipulating the DRM lock).
The fix is to change the relevant spinlock semantics to be the
interrupt-blocking form. After this change I am no longer able to
trigger the lockup; the longest test run so far was 20 hours (test
stopped after that point).
Note: I have examined the places where this spinlock is being
employed; all are reasonably short bounded sequences and should be
suitable for interrupts being blocked without impacting overall kernel
interrupt response latency.
Signed-off-by: Mike Isely <isely@pobox.com>
|
|
|
|
Conflicts:
linux-core/drm_compat.c
linux-core/drm_compat.h
linux-core/drm_ttm.c
shared-core/i915_dma.c
Bump driver minor to 13 due to introduction of new
relocation type.
|
|
modesetting-101
Conflicts:
shared-core/i915_dma.c
shared-core/i915_drv.h
shared-core/i915_irq.c
|
