This resolves a panic on FreeBSD which was caused by trying
to re-initialize the swap lock. It's just much easier to
initialize all of the locks at load time. It should also
ensure that the vblank structures are available earlier.
Remove the unused (and broken) "in vblank" code now that the core has
been fixed to use a counter while interrupts are enabled. Also make the
vblank pipe get/set ioctls into dumb stub functions, since with the new
code we can no longer let userspace control whether vblank interrupts
are enabled, or the core code will misbehave.
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>
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>
With the interrupt enable/disable using only the mask register, it was wrong
to use the enable register to detect which pipes had vblank detection
turned on. Also, as we keep a local copy of the mask register around, and
MSI machines smack the hardware during the interrupt handler, it is more
efficient and more correct to use the local copy.
It would be nice if one day the DRM driver was the canonical source for
register definitions and core macros. To that end, this patch cleans things up
quite a bit, removing redundant definitions (some with different names
referring to the same register) and generally tidying up the header file.
Noting that the interrupt mask register was more reliable than the interrupt
enable register for managing interrupts in user_irq_on/user_irq_off, this
patch replaces the remaining IER frobbing with IMR instead.
The test which exposes IER related failures is:
$ glxgears & glxgears & glxgears
(reposition the glxgears windows away from the upper left corner)
$ while :; do x11perf -rect100 -reps 800 -repeat 1; sleep 1; done &
$ while :; do runoa; runet; done &
Lots of conflicts, seems to load ok, but I'm sure some bugs snuck in.
Conflicts:
linux-core/drmP.h
linux-core/drm_lock.c
linux-core/i915_gem.c
shared-core/drm.h
shared-core/i915_dma.c
shared-core/i915_drv.h
shared-core/i915_irq.c
The interrupt identity register must be writen before any work occurs lest
we drop an interrupt on the floor. This patch just shuffles code around to
make sure that IIR is written as early as possible.
In the short-circuit code for the breadcrumb already being new enough, we
need to update the sarea_priv copy of the breadcrumb just as if we had
waited. Otherwise userland error checking will notice that we returned
too early based on its wrong information, and call wait_irq again (leading
to spinning until someone else comes along and updates the sarea_priv).
This bug was hidden when we had interrupt masking disabled, such as in
master, since the interrupt handler would update sarea_priv.
This was insufficient once we started masking interrupts to only when someone
was waiting for them (and would thus retire requests themselves). It was
replaced by the retire_timer.
Use new GEM based ring buffer initialization. Still need to init GEM & use it
for framebuffer allocation etc.
Conflicts:
shared-core/i915_dma.c
shared-core/i915_drv.h
This requires that the X Server use the execbuf interface for buffer
submission, as it no longer has direct access to the ring. This is
therefore a flag day for the gem interface.
This also adds enter/leavevt ioctls for use by the X Server. These would
get stubbed out in a modesetting implementation, but are required while
in an environment where the device's state is only managed by the DRM while
X has the VT.
Okay we have crtc, encoder and connectors.
No more outputs exposed beyond driver internals
I've broken intel tv connector stuff.
Really for TV we should have one TV connector, with a sub property for the
type of signal been driven over it
Use subclassing from the drivers to allocate the objects. This saves
two objects being allocated for each crtc/output and generally makes
exit paths cleaner.
This splits a lot of the core modesetting code out into a file of
helper functions, that are only called from themselves and/or the driver.
The driver gets called into more often or can call these functions from itself
if it is a helper using driver.
I've broken framebuffer resize doing this but I didn't like the API for that
in any case.
Robert Noland
Jesse Barnes
Dave Airlie
Eric Anholt
Kristian Høgsberg
Dave Airlie
Jesse Barnes
Hong Liu
Jesse Barnes
Keith Packard
Jesse Barnes
Jesse Barnes
Alan Hourihane