On my 865G machine, it seems the CPU will receive interrupt before
irq_postinstall is called. This will cause kernel oops because vblank is not
inited at that time. Clear interrupt status before install seems fixing this
problem.
Signed-off-by: Hong Liu <hong.liu@intel.com>
The batchbuffer submission paths were fixed to use the 965-specific command,
but the vblank tasklet was not. When the older version is sent, the 965 will
lock up.
My 965GM gets interrupts stuck when using the old PIPE_VBLANK interrupt.
Switch to the PIPE_EVENT interrupt mechanism, and set the PIPE*STAT
registers to use START_VBLANK on 965 and VBLANK on previous chips.
We need to return an accurate vblank count to the callers of
->get_vblank_counter, and in the Intel case the actual frame count
register isn't udpated until the next active line is displayed, so we
need to return one more than the frame count register if we're currently
in a vblank period.
However, none of the various ways of doing this is working yet, so
disable the logic for now. This may result in a few missed events, but
should fix the hangs some people have seen due to the current code
tripping the wraparound logic in drm_update_vblank_count.
The frame count registers don't increment until the start of the next
frame, so make sure we return an incremented count if called during the
actual vblank period.
Ack the IRQs correctly (PIPExSTAT first followed by IIR). Don't read
vblank counter registers on disabled pipes (might hang otherwise). And
deal with flipped pipe/plane mappings if present.
As DRM_DEBUG macro already prints out the __FUNCTION__ string (see
drivers/char/drm/drmP.h), it is not worth doing this again. At some
other places the ending "\n" was added.
airlied:- I cleaned up a few that this patch missed also
If drmMinor >= 6, the intel DDX driver will enable vblank events on both
pipes. If drmMinor >= 10 on pre-965 chipsets, the intel DDX driver will
swap the pipe<->plane mapping to allow for framebuffer compression on
laptop screens. This means the secondary vblank counter (corresponding
to pipe B) will be incremented when vblank interrupts occur.
Now Mesa waits for vblank events on whichever plane has a greater
portion of the displayed window. So it will happly ask to wait for the
primary counter even though that one won't increment.
So we can fix this in either the DDX driver, Mesa or the kernel (though
I thought we already had several times).
Since current (and previous) userspace assumes it's talking about a pipe
== plane situation and now uses planes when talking to the kernel, we
should probably just hide the mapping details there (indeed they already
are hidden there for vblank swaps), which this patch does.
So as far as userland is concerned, whether we call things planes or
pipes is irrelevant, as long as kernel developers understand that
userland hands them planes and they have to figure out which pipe that
corresponds to (which will typically be the same on 965+ hardware and
reversed on pre-965 mobile chips).
Conflicts:
linux-core/drmP.h
linux-core/drm_drv.c
linux-core/drm_irq.c
shared-core/i915_drv.h
shared-core/i915_irq.c
shared-core/mga_drv.h
shared-core/mga_irq.c
shared-core/radeon_drv.h
shared-core/radeon_irq.c
Merge in the latest master bits and update the remaining drivers (except
mach64 which math_b is working on). Also remove the 9xx hack from the i915
driver; it seems to be correct.
Conflicts:
linux-core/drmP.h
linux-core/drm_bo.c
linux-core/drm_drv.c
linux-core/drm_objects.h
shared-core/drm.h
shared-core/i915_dma.c
shared-core/i915_drv.h
shared-core/i915_irq.c
Mostly removing typedefs that snuck into the modesetting code and
updating to the latest TTM APIs. As of today, the i915 driver builds,
but there are likely to be problems, so debugging and bugfixes will
come next.
We can figure out which pipe a given plane is mapped to by looking at the
display control registers instead of tracking it in a new SAREA private field.
If this becomes a performance problem, we could move to an ioctl based solution
by adding a new parameter for the DDX to set (defaulting to the old behavior if
the param was never set of course).
This mod makes the SAREA track plane to pipe mappings and corrects the name of
the plane info variables (they were mislabeled as pipe info since until now all
code assumed a direct mapping between planes and pipes).
It also updates the flip ioctl argument to take a set of planes rather than
pipes, since planes are flipped while pipes generate vblank events.
The data is now in kernel space, copied in/out as appropriate according to the
This results in DRM_COPY_{TO,FROM}_USER going away, and error paths to deal
with those failures. This also means that XFree86 4.2.0 support for i810 DRM
is lost.
As a fallout, replace filp storage with file_priv storage for "unique
identifier of a client" all over the DRM. There is a 1:1 mapping, so this
should be a noop. This could be a minor performance improvement, as everything
on Linux dereferenced filp to get file_priv anyway, while only the mmap ioctls
went the other direction.
This was used to make all ioctl handlers return -errno on linux and errno on
*BSD. Instead, just return -errno in shared code, and flip sign on return from
shared code to *BSD code.
- use a timer for disabling vblank events to avoid enable/disable calls too
often
- make i915 work with pre-965 chips again (would like to structure this
better, but this hack works on my test system)
- use correct refcount variable in get/put routines
- extract counter update from drm_vblank_get
- make signal handling callback per-crtc
- update interrupt handling logic, drivers should use drm_handle_vblank
- move wakeup and counter update logic to new drm_handle_vblank routine
- fixup usage of get/put in light of counter update extraction
- fix longstanding bug in signal code, update pending counter only
*after* we're sure we'll setup signal handling
i915_driver_irq_postinstall was forcing vblank interrupts to pipe A when
called with vblank interrupts disabled. This caused vblank interrupts to be
accidentally re-enabled when VT switching the X server. Instead, start the
driver with vblank interrupts enabled on pipe A to support older X servers,
but then leave control over the state to the X server if it is able to do so.
Always use dev_priv->sarea_priv->pf_current_page directly. This allows clients
to modify it as well while they hold the HW lock, e.g. in order to sync pages
between pipes.
Unfortunately, emitting asynchronous flips during vertical blank results in
tearing. So we have to wait for the previous vertical blank and emit a
synchronous flip.
Previously, if there were several buffer swaps scheduled for the same vertical
blank, all but the first blit emitted stood a chance of exhibiting tearing. In
order to avoid this, split the blits along slices of each output top to bottom.
This fixes issues on X server startup with versions of xf86-video-intel that
enable the IRQ before they have a context ID.
(cherry picked from 7af93dd984 commit)
It looks like 'after a while', I915REG_INT_IDENTITY_R for some reason always has
VSYNC_PIPEB_FLAG set in the interrupt handler, even though pipe B is disabled.
So we only increase dev->vbl_received if the corresponding bit is also set in
dev->vblank_pipe.
(cherry picked from 881ba56992 commit)
Initialize it to default value if it hasn't been set by the X server yet.
In i915_vblank_pipe_set(), only update dev_priv->vblank_pipe and call
i915_enable_interrupt() if the argument passed from userspace is valid to avoid
corrupting dev_priv->vblank_pipe on invalid arguments.
(cherry picked from 87c57cba1a commit)
Handle relative as well as absolute target sequence numbers.
Return error if target sequence has already passed, so userspace can deal with
this situation as it sees fit.
On success, return the sequence number of the vertical blank when the buffer
swap is expected to take place.
Also add DRM_IOCTL_I915_VBLANK_SWAP definition for userspace code that may want
to use ioctl() instead of drmCommandWriteRead().
(cherry picked from d5a0f10751 commit)
This uses the core facility to schedule a driver callback that will be called
ASAP after the given vertical blank interrupt with the HW lock held.
(cherry picked from 257771fa29 commit)
When the vertical blank interrupt is enabled for both pipes, pipe A is
considered primary and pipe B secondary. When it's only enabled for one pipe,
it's always considered primary for backwards compatibility.
(cherry picked from 0c7d7f4361 commit)
It looks like 'after a while', I915REG_INT_IDENTITY_R for some reason always has
VSYNC_PIPEB_FLAG set in the interrupt handler, even though pipe B is disabled.
So we only increase dev->vbl_received if the corresponding bit is also set in
dev->vblank_pipe.
Initialize it to default value if it hasn't been set by the X server yet.
In i915_vblank_pipe_set(), only update dev_priv->vblank_pipe and call
i915_enable_interrupt() if the argument passed from userspace is valid to avoid
corrupting dev_priv->vblank_pipe on invalid arguments.
Handle relative as well as absolute target sequence numbers.
Return error if target sequence has already passed, so userspace can deal with
this situation as it sees fit.
On success, return the sequence number of the vertical blank when the buffer
swap is expected to take place.
Also add DRM_IOCTL_I915_VBLANK_SWAP definition for userspace code that may want
to use ioctl() instead of drmCommandWriteRead().
When the vertical blank interrupt is enabled for both pipes, pipe A is
considered primary and pipe B secondary. When it's only enabled for one pipe,
it's always considered primary for backwards compatibility.
Change the fence object interface somewhat to allow some more flexibility.
Make list IOCTLS really restartable.
Try to avoid busy-waits in the kernel using immediate return to user-space with an -EAGAIN.
Hong Liu
Keith Packard
Jesse Barnes
Alan Hourihane
Dave Airlie
Zou Nan hai
Dave Airlie
Kristian Høgsberg
Jakob Bornecrantz
Jesse Barnes
Márton Németh
Li Zefan
Dave Airlie
Thomas Hellstrom
Jesse Barnes
Jesse Barnes
Michel Dänzer
Eric Anholt
Alan Hourihane
Thomas Gleixner
Keith Packard