| Age | Commit message (Collapse) | Author |
|---|
|
The current code uses the hw vblank counter exclusively, which can lead
to wakeups during the active period rather than during the vblank period
if the hw counter counts displayed frames rather than vblank periods.
This change coverts the code over to using the counter while interrupts
are enabled, fixing that issue. It also includes a couple of related
changes: one to not enable the new enable/disable behavior until the
modeset ioctl is called (to preserve old client behavior) and another to
account for lost events due to mode setting with the new counter scheme.
BSD will require similar changes to its drm_irq.c code, but they should
be straightforward.
|
|
|
|
The current code can sleep in an interrupt handler, that is bad. So
instead if we can't grab the lock, flag it and run the tasklet on
unlock.
Signed-off-by: Robert Noland <rnoland@2hip.net>
|
|
bus_dmamem_alloc.
|
|
modifications to make it work correctly on my test hardware (altered the
backlight write function, made it enable the legacy backlight controller
interrupts on mobile hardware, sorted the interrupt function so we don't
get an excessive number of vblank interrupts). This lets the backlight
keys on my T61 work properly, though there's a 750msec or so delay
between the request and the brightness actually changing - this sounds
awfully like the hardware spinning waiting for a status flag to become
ready, but as far as I can tell they're all set correctly. If anyone can
figure out what's wrong here, it'd be nice to know.
Some of the functions are still stubs and just tell the hardware that
the request was successful. These can be filled in as kernel modesetting
gets integrated. I think it's worth getting this in anyway, since it's
required for backlight control to work properly on some new platforms.
Signed-off-by: Matthew Garrett <mjg@redhat.com>
|
|
|
|
|
|
|
|
One of our systems has been returning 0xffffffff from all MCHBAR reads, which
means we'll need to figure out why, or add an alternate detection method.
|
|
|
|
Various chips have exciting interactions between the CPU and the GPU's
different ways of accessing interleaved memory, so we need some kernel
assistance in determining how it works.
Only fully tested on GM965 so far.
|
|
|
|
|
|
|
|
They fell through the cracks in 86accbcb.
|
|
|
|
Conflicts:
linux-core/drmP.h
linux-core/drm_drv.c
linux-core/drm_stub.c
linux-core/i915_drv.c
linux-core/i915_gem.c
shared-core/i915_drv.h
shared-core/i915_irq.c
|
|
|
|
|
|
|
|
|
|
definitions.
|
|
definitions
|
|
|
|
- This should avoid switching crtc's when going to fbcon.
|
|
|
|
+ modeprint changes.
- All things are now called _id when they are id's.
- modeprint now accepts driver name as first argument.
|
|
|
|
|
|
- Otherwise userspace has no idea of the meaning.
|
|
- These facilitate DVI-I and tv-out that can drive multiple types of signals.
|
|
not needed, hotplug will work just as well hopefully.
|
|
|
|
|
|
with enabled
|
|
|
|
|
|
|
|
|
|
blob is a blob not a connector
|
|
|
|
|
|
|
|
|
|
Signed-off-by: Zhenyu Wang <zhenyu.z.wang@intel.com>
|
|
- There is one fb, used for as many outputs as possible.
- Eventually smaller screens will be scaled to see the full console, but for the moment this'll do.
|
|
|
|
When scheduled swaps occur, we need to blit between front & back buffers. I
the buffers are tiled, we need to set the appropriate XY_SRC_COPY tile bit,
only on 965 chips, since it will cause corruption on pre-965 (e.g. 945).
Bug reported by and fix tested by Tomas Janousek <tomi@nomi.cz>.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
|
This reverts commit 727d4f1d1667e43b3558bd5f6ed6dc2cd9c29401, somehow git
deleted the symlink and replaced it with the file.
|
|
When scheduled swaps occur, we need to blit between front & back buffers. If
the buffers are tiled, we need to set the appropriate XY_SRC_COPY tile bit, but
only on 965 chips, since it will cause corruption on pre-965 (e.g. 945).
Bug reported by and fix tested by Tomas Janousek <tomi@nomi.cz>.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
