bad argument if(tmp)... in check_free_hole
fix oops: kernel BUG at drivers/gpu/drm/drm_mm.c:305!
[airlied: excellent, this was my task for today].
Signed-off-by: Krzysztof Kolasa <kkolasa@winsoft.pl>
Reviewed-by: Chris wilson <chris@chris-wilson.co.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Some additional radeon fixes for 4.0
* 'drm-fixes-4.0' of git://people.freedesktop.org/~agd5f/linux:
drm/radeon: drop setting UPLL to sleep mode
drm/radeon: fix wait to actually occur after the signaling callback
A couple of fixes for vmwgfx.
* 'vmwgfx-fixes-4.0' of git://people.freedesktop.org/~thomash/linux:
drm/vmwgfx: Fix an issue with the device losing its irq line on module unload
drm/vmwgfx: Correctly NULLify dma buffer pointer on failure
drm/vmwgfx: Reorder device takedown somewhat
drm/vmwgfx: Fix a couple of lock dependency violations
More i915 fixes, three out of four are fixes to old bugs, cc: stable.
* tag 'drm-intel-fixes-2015-03-12' of git://anongit.freedesktop.org/drm-intel:
drm/i915: Prevent TLB error on first execution on SNB
drm/i915: Do both mt and gen6 style forcewake reset on ivb probe
drm/i915: Make WAIT_IOCTL negative timeouts be indefinite again
drm/i915: use in_interrupt() not in_irq() to check context
Starting with commit b4b55cda58
("x86/PCI: Refine the way to release PCI IRQ resources")
the device lost its irq resource on module unload. While that's ok and
apparently intentional, the driver never got the resource back on module load
The code apparently wants drivers to disable the pci device at pci device
driver removal, so lets do that. That fixes the issue.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
cppcheck on lines 917 and 977 show an ineffective assignment
to the dma buffer pointer:
[drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c:917]:
[drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c:977]:
(warning) Assignment of function parameter has no effect
outside the function. Did you forget dereferencing it?
On a successful DMA buffer lookup, the dma buffer pointer is
assigned, however, on failure it currently is left in an
undefined state.
The original intention in the error exit path was to nullify
the pointer on an error (which the original code failed to
do properly). This patch fixes this also ensures all failure
paths nullify the buffer pointer on the error return.
Fortunately the callers to vmw_translate_mob_ptr and
vmw_translate_guest_ptr are checking on a return status and not
on the dma buffer pointer, so the original code worked.
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Colin Ian King <colin.king@canonical.com>
To take down the MOB and GMR memory types, the driver may have to issue
fence objects and thus make sure that the fence manager is taken down
after those memory types.
Reorder device init accordingly.
Cc: <stable@vger.kernel.org>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Sinclair Yeh <syeh@vmware.com>
Experimental lockdep annotation added to the TTM lock has unveiled a
couple of lock dependency violations in the vmwgfx driver. In both
cases it turns out that the device_private::reservation_sem is not
needed so the offending code is moved out of that lock.
Cc: <stable@vger.kernel.org>
Acked-by: Sinclair Yeh <syeh@vmware.com>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Long ago I found that I was getting sporadic errors when booting SNB,
with the symptom being that the first batch died with IPEHR != *ACTHD,
typically caused by the TLB being invalid. These magically disappeared
if I held the forcewake during the entire ring initialisation sequence.
(It can probably be shortened to a short critical section, but the whole
initialisation is full of register writes and so we would be taking and
releasing forcewake almost continually, and so holding it over the
entire sequence will probably be a net win!)
Note some of the kernels I encounted the issue already had the deferred
forcewake release, so it is still relevant.
I know that there have been a few other reports with similar failure
conditions on SNB, I think such as
References: https://bugs.freedesktop.org/show_bug.cgi?id=80913
v2: Wrap i915_gem_init_hw() with its own security blanket as we take
that path following resume and reset.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
commit 05a2fb157e ("drm/i915: Consolidate forcewake code")
failed to take into account that we have used to reset both
the gen6 style and the multithreaded style forcewake registers.
This is due to fact that ivb can use either, depending on how the
bios has set up the machine.
Mimic the old semantics before we have determined the correct variety
and reset both before the ecobus probe.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Huang Ying <ying.huang@intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The kernel in_irq() function tests for hard-IRQ context only, so if a
system is run with the kernel 'threadirqs' option selected, the test in
intel_check_page_flip() generates lots of warnings, because then it gets
called in soft-IRQ context.
We can instead use in_interrupt() which allows for either type of
interrupt, while still detecting and complaining about misuse of the
page flip code if it is ever called from non-interrupt context.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89321
Signed-off-by: Dave Gordon <david.s.gordon@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
With drm-next, we can get a backtrace from sleeping
with mutex detection.
this is due to the callback checking the txmsg state taking
the mutex, which can cause a sleep inside a sleep,
Daniel went over it and was happy we could drop this mutex
in this case.
Signed-off-by: Dave Airlie <airlied@redhat.com>
The internal framebuffers we create to remap legacy cursor ioctls to
plane operations for the universal plane support shouldn't be linke to
the file like normal userspace framebuffers. This bug goes back to the
original universal cursor plane support introduced in
commit 161d0dc1dc
Author: Matt Roper <matthew.d.roper@intel.com>
Date: Tue Jun 10 08:28:10 2014 -0700
drm: Support legacy cursor ioctls via universal planes when possible (v4)
The isn't too disastrous since fbs are small, we only create one when the
cursor bo gets changed and ultimately they'll be reaped when the window
server restarts.
Conceptually we'd want to just pass NULL for file_priv when creating it,
but the driver needs the file to lookup the underlying buffer object for
cursor id. Instead let's move the file_priv linking out of
add_framebuffer_internal() into the addfb ioctl implementation, which is
the only place it is needed. And also rename the function for a more
accurate since it only creates the fb, but doesn't add it anywhere.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> (fix & commit msg)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (provider of lipstick)
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Rob Clark <robdclark@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
two fixes, both cc'd stable.
* tag 'drm-intel-fixes-2015-03-05' of git://anongit.freedesktop.org/drm-intel:
drm/i915: gen4: work around hang during hibernation
drm/i915: Check for driver readyness before handling an underrun interrupt
Fixup some fallout of the fallout of atomic dpms, few mdp5 cursor
fixes, fix a leak in error path, and some fixes for kexec
* 'msm-fixes-4.0' of git://people.freedesktop.org/~robclark/linux:
drm/msm: kexec fixes
drm/msm/mdp5: fix cursor blending
drm/msm/mdp5: fix cursor ROI
drm/msm/atomic: Don't leak atomic commit object when commit fails
drm/msm/mdp5: Avoid flushing registers when CRTC is disabled
drm/msm: update generated headers (add 6th lm.base entry)
drm/msm/mdp5: fixup "drm/msm: fix fallout of atomic dpms changes"
In kexec environment, we are more likely to encounter irq's already
enabled from previous environment. At which point we find that writes
to disable/clear pending irq's are slightly less than useless without
first enabling clocks.
TODO: full blown state read-in so kexec'd kernel can inherit the mode
already setup.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Seems like we just want BLEND_EN and not BLEND_TRANSP_EN (setting the
latter results in black pixels in the cursor image treated as
transparent).
Signed-off-by: Rob Clark <robdclark@gmail.com>
If cursor is set near the edge of the screen, it is not valid to use the
new cursor width/height as the ROI dimensions. Split out the ROI calc
and use it both cursor_set and cursor_move.
Signed-off-by: Rob Clark <robdclark@gmail.com>
If the atomic commit fails due to completion wait interruption the
atomic commit object is not freed and is thus leaked. Free it.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Rob Clark <robdclark@gmail.com>
When a CRTC is disabled, no CTL is allocated to it (CRTC->ctl == NULL);
in that case we should not try to FLUSH registers and do nothing instead.
This can happen when we try to move a cursor but the CRTC's CTL
(CONTROL) has not been allocated yet (inactive CRTC).
It can also happens when we .atomic_check()/.atomic_flush() on a
disabled CRTC.
A CTL needs to be kept as long as the CRTC is alive. Releasing it
after the last VBlank is safer than in .atomic_flush().
Signed-off-by: Stephane Viau <sviau@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
Some target have up to 6 layer mixers (LM).
Let the header file access the last LM's base address.
Signed-off-by: Stephane Viau <sviau@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
