Not sure anyone cares about this information. I suppose most people
would just look at /proc/interrupts instead.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
irq_received is used as a boolean in i965_irq_handler(), so make it
bool. This also makes i965_irq_handler() closer to i915_irq_handler().
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewd-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Add intel_hpd_irq_uninstall() which will cancel the hotplug re-enable
timer.
Also s/i915_reenable_hotplug_timer_func/intel_hpd_irq_reenable/
Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Function ironlake_wait_panel_off should just wait for the power off
delay, while function ironlake_wait_panel_power_cycle should wait for
the panel cycle (that's required after we turn the panel off, before
we enable it again).
The problem is that, currently, ironlake_wait_panel_off is waiting not
just for the panel to be off, but also for the power cycle delay and
the backlight off delay. This function relies on the PP_STATUS bits
3:0, which are not documented and not supposed to be used. A quick
analysis of the values we get while waiting quickly shows that power
off is reached while bits 3:0 are still 0x1, and the time it takes to
become 0x0 is the power cycle delay.
On my system with backlight off delay of 200ms, power down delay of
50ms and power cycle delay of 500ms, this is what I get:
- Start waiting with value 0x80000008, timestamp 6.429364.
- Jumps to 0xa0000003, timestamp 6.431360 (time waited: 0.001996)
- Jumps to 0xa0000002, timestamp 6.631277 (time waited: 0.201913)
- Jumps to 0x08000001, timestamp 6.681258 (time waited: 0.251894)
- Jumps to 0x00000000, timestamp 7.192012 (time waited: 0.762648)
As you can see, ironlake_wait_panel_off is sleeping 760ms instead of
the expected 50ms: the first 200ms matches the backlight off delay
(which we should already have waited for!), then the 50ms for the real
panel off delay, then the 500ms for the panel power cycle.
This patch makes is look just at bits 31 and 29:28, which will ignore
the panel power cycle.
And just to be clear: this saves 500ms on my system every time we
disable the panel. But we can still save 200ms more (the backlight off
delay) on the next patches.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuougseek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
I like how the macros are nicely column-aligned, so we can properly
compare what each macro waits for, but a column full of zeroes doesn't
really help anything: it just makes the lines bigger, and they're
already way past 80 columns. I imagine this column was used in the
past, but IMHO now we can get rid of it.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
They now also work on vlv, which has the regs somewhere else. And
daring a glance into the looking glass it seems like this
functionality will continue to work the same for the next few hardware
platforms.
So it's better to just remove that misleading prefix and have a bit
shorter code for better readability.
The only exceptions are the panel/backlight functions shared with
intel_ddi.c, those get an intel_ prefix.
While at it make the vdd_on/off functions static.
And one straggler was missing the edp_ in the name, so make everything
neatly OCD.
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The eDP spec defines some points where after you do action A, you have
to wait some time before action B. The thing is that in our driver
action B does not happen exactly after action A, but we still use
msleep() calls directly. What this patch does is that we record the
timestamp of when action A happened, then, just before action B, we
look at how much time has passed and only sleep the remaining amount
needed.
With this change, I am able to save about 5-20ms (out of the total
200ms) of the backlight_off delay and completely skip the 1ms
backlight_on delay. The 600ms vdd_off delay doesn't happen during
normal usage anymore due to a previous patch.
v2: - Rename ironlake_wait_jiffies_delay to intel_wait_until_after and
move it to intel_display.c
- Fix the msleep call: diff is in jiffies
v3: - Use "tmp_jiffies" so we don't need to worry about the value of
"jiffies" advancing while we're doing the math.
v4: - Rename function again.
- Move function to i915_drv.h.
- Store last_power_cycle at edp_panel_off too.
- Use msecs_to_jiffies_timeout, then replace the msleep with an
open-coded version that avoids the extra +1 jiffy.
- Try to add units to every variable name so we don't confuse
jiffies with milliseconds.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Our driver has two different ways of waiting for panel power
sequencing delays. One of these ways is through
ironlake_wait_panel_status, which implicitly uses the values written
to our registers. The other way is through the functions that call
intel_wait_until_after, and on this case we do direct msleep() calls
on the intel_dp->xxx_delay variables.
Function intel_dp_init_panel_power_sequencer is responsible for
initializing the _delay variables and deciding which values we need to
write to the registers, but it does not write these values to the
registers. Only at intel_dp_init_panel_power_sequencer_registers we
actually do this write.
Then problem is that when we call intel_dp_i2c_init, we will get some
I2C calls, which will trigger a VDD enable, which will make use of the
panel power sequencing registers and the _delay variables, so we need
to have both ready by this time. Today, when this happens, the _delay
variables are zero (because they were not computed) and the panel
power sequence registers contain whatever values were written by the
BIOS (which are usually correct).
What this patch does is to make sure that function
intel_dp_init_panel_power_sequencer is called earlier, so by the time
we call intel_dp_i2c_init, the _delay variables will already be
initialized. The actual registers won't contain their final values,
but at least they will contain the values set by the BIOS.
The good side is that we were reading the values, but were not using
them for anything (because we were just skipping the msleep(0) calls),
so this "fix" shouldn't fix any real existing bugs. I was only able to
identify the problem because I added some debug code to check how much
time time we were saving with my previous patch.
Regression introduced by:
commit ed92f0b239
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date: Wed Jun 12 17:27:24 2013 -0300
drm/i915: extract intel_edp_init_connector
v2: - Rewrite commit message.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This was forgotten in
commit 565ee3897f
Author: Jani Nikula <jani.nikula@intel.com>
Date: Wed Nov 13 12:56:29 2013 +0200
drm/i915: do not save/restore backlight registers in KMS
Since the confusion was likely due to the duplicated definition for
this pci config register, let's unify that, too.
Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Atm, we don't print these events for all platforms and for VLV/G4X we
also print them for DP AUX completion events which is unnecessary spam.
Fix both issues.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Those are two distinct concepts. Just use a comment to remind us to
remove that W/A at some point.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
crtc->new_config is only relevant for pipes that are going to be active
post-modeset. Set the pointer to NULL for all pipes that are going to
be disabled. This is done to help catch bugs where some piece of code
would go looking at crtc->new_config even if the data there is stale.
v2: Clear new_config in disable_crtc_nofb() too (Imre)
Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If the first modeset operation fails, we will attempt to restore the
previous configuration that we read out from the hardware. But as we
don't yet reconstruct the framebuffer information, we end up calling
the modeset code with an enabled crtc but with fb==NULL. This will
lead to an oops within the modeset code.
Check for NULL fb when restoring the configuration, and instead of
oopsing simply disable the pipe.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
On VLV we need to compute the new cdclk before we've updated the current
state. The code achieved that in a somewhat complex way. Now that we
have new_enabled and new_config, we can simplify the code quite a bit.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Add a new_config pointer to intel_crtc which will point to the new pipe
config for said crtc while intel_crtc.config will still contain the old
config during first parts of the modeset operation. This is a step
towards having the entire new state available during the compute phase,
so that we can make accurate decisions about global resource usage.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Add 'new_enabled' to intel_crtc and precompute it alongside new_encoder
and new_crtc. This will allow making decisions about shared resources
that are affected by the set of active pipes, before we've clobbered
anything for real.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This reverts commit 446f254566.
I've left the masking in the pageflip code since that seems to be some
useful piece of preemptive robustness.
Iirc I've merged this patch under the assumption that the BIOS leaves
some random gunk in the lower bits and gets unhappy if we trample on
them. We have quite a few case like this, so this made sense.
Now I've just learned that there's actual hardware features bits in
the low 12 bits, and the kernel needs to preserve them to allow a
userspace blob to do its job. Given Dave Airlie's clear stance on
userspace blob drivers I've quickly chatted with him and he doesn't
seem too happy. So let's revert this.
If there are indeed bits that we must preserve in this range then we
can ressurrect this patch, but with proper documentation for those
bits supplied. And we probably also need to think a bit about
interactions with our driver.
Cc: Armin Reese <armin.c.reese@intel.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Dave Airlie <airlied@linux.ie>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The head number of a given display controller is fixed in hardware and
required to program outputs appropriately. Relying on the driver probe
order to determine this number will not work, since that could yield a
situation where the second head was probed first and would be assigned
head number 0 instead of 1.
By explicitly specifying the head number in the device tree, it is no
longer necessary to rely on these assumptions. As a fallback, if the
property isn't available, derive the head number from the display
controller node's position in the device tree. That's somewhat more
reliable than the previous default but not a proper solution.
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Add new definitions for hotplug live status bits for VLV2 since they're
in reverse order from the gen4x ones.
Changelog:
- Restored gen4 bit definitions
- Added new definitions for VLV2
- Added platform check for IS_VALLEYVIEW() in dp_detect to use the correct
bit defintions
- Replaced a lost trailing brace for the added switch()
Signed-off-by: Todd Previte <tprevite@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73951
[danvet: Switch to _VLV postfix instead of prefix and regroupg
comments again so that the g4x warning is right next to those defines.
Also add a _G4X suffix for those special ones. Also cc stable.]
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Also make nv_lockvgac work for nv50+ devices. This should fix
IO_CONDITION and related VBIOS opcodes that read/write the crtc regs.
See https://bugs.freedesktop.org/show_bug.cgi?id=60680
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Not holding the mutex potentially causes corruption of the kernel
channel when page flipping.
Cc: stable@vger.kernel.org #3.13
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Seen on Titan. NFI what the condition to switch this on is yet, and,
hardcoding it to on currently causes master to report unknown intr
with a mask of 0x08002000.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Still essentially a struct of magic values with magic names and unknown
purposes. But, we will shortly need to be able to mix and match bits of
the previous and next configurations to do a transition reclock, as such,
we can no longer directly use the vbios data with any ease.
This is probably nicer anyway in the long run, for a few reasons.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Compute code in mesa triggers one of these, hanging the engine. Let's
at least ack the request for now to avoid the hang.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Some firmware images may be large (64K), so using kmalloc memory is
inappropriate for them. Use vmalloc instead, to avoid high-order
allocation failures.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: stable@vger.kernel.org
Now that nouveau_bo.c can handle sync when it actually needs to, we can
remove this and avoid a double semaphore acquire when syncing in the
command submission path.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Moves bo's to TTM_PL_TT for BAR mapping, to hide tiling from user.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Commit de7b7d59d5 introduced tiled GART, but a linear copy is
still performed. This may result in errors on eviction, fix it by
checking tiling from memtype.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Cc: stable@vger.kernel.org #3.10+
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Pretty much everywhere had to make the decision which to use, so it
makes a lot more sense to just have one entrypoint decide the path
to take instead.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
When the mode is set with 16bpp on QEMU, the output gets totally broken.
The culprit is the bogus register values set for 16bpp, which was likely
copied from from a wrong place.
Addresses https://bugzilla.novell.com/show_bug.cgi?id=799216
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: David Airlie <airlied@linux.ie>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Commit 8116188fde ("nouveau/acpi: hook up to the MXM method for mux
switching.") broke the build on non-x86 architectures due to the new
dependency on MXM and MXM being an x86 platform driver.
It built previously since the vga switcheroo registration routines were
zereod out on !X86. The code was built in but unused.
This patch makes all of the DSM code depend on CONFIG_VGA_SWITCHEROO,
allowing it to build on non-x86 and shrinking the module size as well.
[rdunlap@infradead.org: fix build eror when VGA_SWITCHEROO is not enabled]
Signed-off-by: Jeff Mahoney <jeffm@suse.com>
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: David Airlie <airlied@linux.ie>
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Nothing's changed here; we just need to bump the generation check.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Since an old pageflip will keep its scanout buffer object pinned until
it has executed its unpin task on the common workqueue, we can clog up
our GGTT with stale pinned objects. As we cannot flush those workqueues
without dropping our locks, we have to resort to falling back to
userspace and telling them to repeat the operation in order to have a
chance to run our workqueues and free up the required memory. If we
fail, then we are forced to report ENOSPC back to userspace causing the
operation to fail and best-case scenario is that it introduces temporary
corruption.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jon Bloomfield <jon.bloomfield@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
On older generations (gen2, gen3) the GPU requires fences for many
operations, such as blits. The display hardware also requires fences for
scanouts and this leads to a situation where an arbitrary number of
fences may be pinned by old scanouts following a pageflip but before we
have executed the unpin workqueue. This is unpredictable by userspace
and leads to random EDEADLK when submitting an otherwise benign
execbuffer. However, we can detect when we have an outstanding flip and
so cause userspace to wait upon their completion before finally
declaring that the system is starved of fences. This is really no worse
than forcing the GPU to stall waiting for older execbuffer to retire and
release their fences before we can reallocate them for the next
execbuffer.
v2: move the test for a pending fb unpin to a common routine for
later reuse during eviction
Reported-and-tested-by: dimon@gmx.net
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73696
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jon Bloomfield <jon.bloomfield@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Atm after a failed link training we disable the DP port. This can happen
during a modeset-enable or a DP link re-establishment. The latter can be
a problem and we shouldn't disable the DP port, see the previous patch for
the reasoning. In the former case the right thing would be to disable
the DP port, but also the rest of the pipe.
As a stop-gap solution leave the DP port enabled in both cases. It is an
improvement on its own (avoiding HW lock ups) and the proper solution
for the first case requires a bigger change, so let's keep that on the
TODO list.
v2:
- fix explanation of change impact (Chris)
Suggested-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Currently if the DP link is lost (either because of a hot unplug, or
failed link status check) we disable the DP port, but leave the rest
of the pipe running. This is incompatible with the modeset disabling
sequence of some platforms/configurations. At least this is the case for
DP ports on the CPU as opposed to PCH.
Atm we'll also get a warning when we do a modeset disable after the
above link lost event, since we expect the DP port to be enabled at this
point (see the bugzilla ticket for the related dmesg).
Note that with this patch we'll still end up disabling the port, thanks
to the HPD uevent and subsequent modeset disable.
See also the next patch fixing the other half of this issue.
Solution suggested by Ville.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70570
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
My 855gm doesn't register the intel backlight but it still ends up
calling the backlight code to enable/disable the backlight via the
LVDS code. This leads to some WARNs due to backlight.max being 0.
Let's have intel_panel_enable_backlight() and intel_panel_disable_backlight()
check whether there's a backlight present or not.
Also move the backlight.present check from asle_set_backlight() into
intel_panel_set_backlight() for some extra symmetry.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Fix typo possibly leading to timed out DP aux transactions on ports C,D.
Introduced in:
Commmit 4aeebd7443
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Thu Oct 31 09:53:36 2013 +0100
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=72210
Signed off-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We need to defer the free request until the object/vma is capable of
being freed - or else we have a problem when we try to destroy the
context.
The exact same issue is described and fixed here:
commit e20780439b
Author: Ben Widawsky <ben@bwidawsk.net>
Date: Fri Dec 6 14:11:22 2013 -0800
drm/i915: Defer request freeing
I had this fix previously, but decided not to keep it for some reason I
can no longer remember.
gem_reset_stats is a really good test at hitting the problem.
For the inquisitive:
[ 170.516392] ------------[ cut here ]------------
[ 170.517227] WARNING: CPU: 1 PID: 105 at drivers/gpu/drm/drm_mm.c:578 drm_mm_takedown+0x2e/0x30 [drm]()
[ 170.518064] Memory manager not clean during takedown.
[ 170.518941] CPU: 1 PID: 105 Comm: kworker/1:1 Not tainted 3.13.0-rc4-BEN+ #28
[ 170.519787] Hardware name: Hewlett-Packard HP EliteBook 8470p/179B, BIOS 68ICF Ver. F.02 04/27/2012
[ 170.520662] Call Trace:
[ 170.521517] [<ffffffff814f0589>] dump_stack+0x4e/0x7a
[ 170.522373] [<ffffffff81049e6d>] warn_slowpath_common+0x7d/0xa0
[ 170.523227] [<ffffffff81049edc>] warn_slowpath_fmt+0x4c/0x50
[ 170.524079] [<ffffffffa06c414e>] drm_mm_takedown+0x2e/0x30 [drm]
[ 170.524934] [<ffffffffa07213f3>] gen6_ppgtt_cleanup+0x23/0x110
[i915]
[ 170.525777] [<ffffffffa07837ed>] ppgtt_release.part.5+0x24/0x29
[i915]
[ 170.526603] [<ffffffffa071aaa5>] i915_gem_context_free+0x195/0x1a0
[i915]
[ 170.527423] [<ffffffffa071189d>] i915_gem_free_request+0x9d/0xb0
[i915]
[ 170.528247] [<ffffffffa0718af9>] i915_gem_reset+0x1f9/0x3f0 [i915]
[ 170.529065] [<ffffffffa0700cce>] i915_reset+0x4e/0x180 [i915]
[ 170.529870] [<ffffffffa070829d>] i915_error_work_func+0xcd/0x120
[i915]
[ 170.530666] [<ffffffff8106c13a>] process_one_work+0x1fa/0x6d0
[ 170.531453] [<ffffffff8106c0d8>] ? process_one_work+0x198/0x6d0
[ 170.532230] [<ffffffff8106c72b>] worker_thread+0x11b/0x3a0
[ 170.532996] [<ffffffff8106c610>] ? process_one_work+0x6d0/0x6d0
[ 170.533771] [<ffffffff810743ef>] kthread+0xff/0x120
[ 170.534548] [<ffffffff810742f0>] ? insert_kthread_work+0x80/0x80
[ 170.535322] [<ffffffff814f97ac>] ret_from_fork+0x7c/0xb0
[ 170.536089] [<ffffffff810742f0>] ? insert_kthread_work+0x80/0x80
[ 170.536847] ---[ end trace 3d4c12892e42d58f ]---
v2: Whitespace fix. (Chris)
Note: This is a bug that only hits the ppgtt topic branch but I've
figured that doing the request cleanup in this order is generally the
right thing to do.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Add a code comment to clarify what's actually going on since
the lifetime rules aroung ppgtt cleanup are ... fuzzy a best atm. Also
add a note about why we need this.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The opregion notification for runtime suspend is currently D1, not D3.
Signed-off-by: Kristen Carlson Accardi <kristen@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It ought to work ok in 3.14. We have some fun stuff coming after that,
but all the basics are in place now and seem relatively stable.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Acked by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This is user-triggerable and hence we should not allow it to spam
dmesg. Also, it upsets the nice dmesg tracking piglit does.
Note that this is just extra debugging information, mostly
unwanted, in case of a hang and that there is a separate message to the
user giving instructions on how to report a bug for a GPU hang.
v2: Add note as suggests in Chris' reply.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=72740
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
A couple patches in the upcoming rework of semaphores will break if
semaphores are toggled by the user at various times. Since the code
cleanups there seem to be an overall win, and toggling semaphores at
runtime is not a terribly useful thing to do, simply make the module
parameter read-only.
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The ring will emit too many if semaphores are disabled since we do not
add the correct number to num_dwords anymore.
This was introduced:
commit 52ed23253b
Author: Ben Widawsky <benjamin.widawsky@intel.com>
Date: Mon Dec 16 20:50:38 2013 -0800
drm/i915: Don't emit mbox updates without semaphores
FWIW, the bug was fixed later in the series.
/me hangs head in shame.
Daniel: Also note that we should have merged the read-only semaphore
modparam before this patch.
Reported-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
While trying to find a random -EINVAL from a failing test, I noticed we
had a few hard to follow return values.
The first two hunks in this patch replace completely useless
initialization of ret. The last several hunks help to distinguish
between altering 'return ret' and 'return <ERROR>'
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Here's the vblank timestamp pull request you wanted.
I addressed the few bugs that Mario pointed out and added
the r-bs.
As it has been a while since I made the changes, I gave it a
quick spin on a few different i915 machines. Fortunately
everything still seems to be fine.
* 'drm-vbl-timestamp' of git://gitorious.org/vsyrjala/linux:
drm/i915: Add a kludge for DSL incrementing too late and ISR not working
drm/radeon: Move the early vblank IRQ fixup to radeon_get_crtc_scanoutpos()
drm: Pass 'flags' from the caller to .get_scanout_position()
drm: Fix vblank timestamping constants for interlaced modes
drm/i915: Fix scanoutpos calculations for interlaced modes
drm: Change {pixel,line,frame}dur_ns from s64 to int
drm: Use crtc_clock in drm_calc_timestamping_constants()
drm/radeon: Populate crtc_clock in radeon_atom_get_tv_timings()
drm: Simplify the math in drm_calc_timestamping_constants()
drm: Improve drm_calc_timestamping_constants() documentation
drm/i915: Call drm_calc_timestamping_constants() earlier
drm/i915: Kill hwmode save/restore
drm: Pass the display mode to drm_calc_vbltimestamp_from_scanoutpos()
drm: Pass the display mode to drm_calc_timestamping_constants()
Some straggling drm core patches
* 'topic/core-stuff' of git://people.freedesktop.org/~danvet/drm-intel:
drm/gem: Always initialize the gem object in object_init
drm/edid: Populate picture aspect ratio for CEA modes
drm/edid: parse the list of additional 3D modes
drm/edid: split VIC display mode lookup into a separate function
drm: Make the connector mode_valid() vfunc return a drm_mode_status enum
Just a single fix for sparse/smatch warnings introduced by the previous
vmwgfx-next pull.
* 'vmwgfx-next' of git://people.freedesktop.org/~thomash/linux:
drm/vmwgfx: Fix recently introduced sparse / smatch warnings and errors
At least drm/i915 expects that the obj->dev pointer is set even in
failure paths. Specifically when the shmem initialization fails we
call i915_gem_object_free which needs to deref obj->base.dev to get at
the slab pointer in the device private structure. And the shmem
allocation can easily fail when userspace is hitting open file limits.
Doing the structure init even when the shmem file allocation fails
prevents this Oops.
This is a regression from
commit 89c8233f82
Author: David Herrmann <dh.herrmann@gmail.com>
Date: Thu Jul 11 11:56:32 2013 +0200
drm/gem: simplify object initialization
v2: Add regression note which Chris supplied.
Testcase: igt/gem_fd_exhaustion
Reported-and-Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
References: http://lists.freedesktop.org/archives/intel-gfx/2014-January/038433.html
Cc: stable@vger.kernel.org
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Cc: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It seems this got dropped when we merged UVD support
last year. Add this back now.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
We need to set the engine bit to select the ME and
also set the full cache bit. Should help stability
on TN and cayman.
V2: fix up surface sync in ib execute as well
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Mclk switching doesn't seem to work reliably on these
cards. Most RV770 boards specify the same mclk for all
performance levels anyway so in most cases, this has
no affect.
Bug:
https://bugs.freedesktop.org/show_bug.cgi?id=73067
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
If the ss percentage is 0 or we are using external ss,
just bail when enabling ss. We disable it explicitly
earlier in the modeset already.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This is needed for reporting the max GPU engine clock
in OpenCL. This just reports the max possible engine
clock, it does not take into account current conditions
that may limit that clock.
v2: fix query number for merge with 3.13
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Adding picture aspect ratio for CEA modes based on CEA-861D Table 3 or
CEA-861E Table 4. This is useful for filling up the detail in AVI
infoframe.
v2: Ville's review comments incorporated
Added picture aspect ratio as part of edid_cea_modes instead of DRM_MODE
Signed-off-by: Vandana Kannan <vandana.kannan@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
According to the DP 1.1 spec, the sink must power
up within 1ms. Noticed while reviewing Thierry's
drm/dp patches.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
As per the DP1.2 spec. Noticed while reviewing
Thierry's drm/dp patches. Also bump native aux
retries to 7 for consistency.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This is the preferred flushing method on CIK.
Note, this only works on the PFP so the engine bit must be
set.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Parse 2D_VIC_order_X and 3D_Structure_X from the list at the end of the
HDMI Vendor Specific Data Block.
v2: Use an offset value depending on 3D_Multi_present and add
detail_present. (Ville Syrjälä)
v3: Make sure the list is parsed even if 3D_Structure_ALL/MASK is not
present. (Ville Syrjälä)
Fix one length check and remove another. (Ville Syrjälä)
Signed-off-by: Thomas Wood <thomas.wood@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Thomas Wood <thomas.wood@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
On pre-PCH platforms ISR doesn't seem to be an actual ISR, at least as
far as display interrupts are concerned. Instead it sort of looks like
some ISR bits just directly reflect the corresponding bit from PIPESTAT.
The bit appears in the ISR only if the PIPESTAT interrupt is enabled. So
in that sense it sort of looks a bit like the south interrupt scheme on
PCH platforms. So it goes something a bit like this:
PIPESTAT.status & PIPESTAT.enable -> ISR -> IMR -> IIR -> IER -> actual
interrupt
In any case that means the intel_pipe_in_vblank_locked() doesn't actually
work for pre-PCH platforms. As a last resort, add a similar kludge as radeon
has that fixes things up if we got called from the vblank interrupt,
but the scanline counter value indicates that we're not quite there yet.
We know that the scanline counter increments at hsync but is otherwise
accurate, so we can limit the kludge to the line just prior to vblank
start, instead of the relative distance that radeon uses.
Reviewed-by: mario.kleiner.de@gmail.com
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
i915 doesn't need this kludge for most platforms. Although we do
appear to need something similar on certain platforms, but we can
be more accurate when we apply the adjustment since we know exactly
why the scanline counter doesn't always quite match the vblank
status.
Also the current code doesn't handle interlaced modes correctly,
and we already deal with interlaced modes in i915 code.
So let's just move the current code to radeon_get_crtc_scanoutpos()
since that's why it was added. For i915 we'll add a more finely
targeted variant.
v2: Fix vpos vs. *vpos bug (Mario)
Reviewed-by: mario.kleiner.de@gmail.com
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Preparation for moving the early vblank IRQ logic into
radeon_get_crtc_scanoutpos().
v2: Fix radeon_drv.c compile warning (Mario)
Reviewed-by: mario.kleiner.de@gmail.com
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
We're currently miscalculating the line and pixel durations for
interlaced modes. crtc_htotal and crtc_vtotal are the full frame
timings, and so is crtc_clock, so we can compute the line
and pixel durations from those w/o any extra adjustments. But
we actually want framedur_ns to be the field, not frame, duration,
so we must divide it by two.
This should make the scanout based vblank timestamp corrections
work correctly with interlaced modes, at least for i915. It all
depends whether we keep the field or frame timings in the display
mode crtc_ timings.
v2: Preserve halve->half typo fix that happened in the meantine
Reviewed-by: mario.kleiner.de@gmail.com
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
The scanline counter counts lines in the current field, not the entire
frame. But the crtc_ timings are the values for the entire frame. Divide
the vertical timings by 2 to make them match the scanline counter.
The rounding was carefully chosen to make it do the right thing wrt. the
observed scanline counter and ISR vblank bit behaviour.
Reviewed-by: mario.kleiner.de@gmail.com
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Using s64 for the timestamping constants is wasteful. Signed 32bit
integers get us a range of over +-2 seconds. Presuming that no-one
wants to a vrefresh rate less than 0.5, we can switch to using int
for the timestamping constants. We save a few bytes in drm_crtc and
avoid a bunch of 64bit math.
Reviewed-by: mario.kleiner.de@gmail.com
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
drm_calc_timestamping_constants() computes the pixel/line/frame
durations based on the crtc_ timing values. The corresponding pixel
clock is in mode->crtc_clock, so we need to use that instead of
mode->clock.
This should fix drm_calc_timestamping_constants() for frame packing
stereo modes.
Reviewed-by: mario.kleiner.de@gmail.com
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
crtc_clock is now supposed to be the actual pixel clock corresponding to
the other crtc_ timing values. Populate crtc_clock appropriately in
radeon_atom_get_tv_timings().
This was the only obvious place where we frob with the crtc_ timigns
directly instead of calling drm_mode_set_crtcinfo() which would also
update crtc_clock.
Reviewed-by: mario.kleiner.de@gmail.com
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
drm_calc_timestamping_constants() makes the math more complex
than necessary.
- multipying the dotclock by 1000 is pointless, just makes all the
numbers bigger
- div64_u64() is also pointless, div_u64 is enough
- pixeldur_ns doesn't need any 64bit math
Reviewed-by: mario.kleiner.de@gmail.com
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Move the long blurp to into the body of the comment, leaving only
a short summary line at the top.
Reviewed-by: mario.kleiner.de@gmail.com
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Update the pixel/line/frame duration information when we switch to the
new pipe config. This will keep the timestamping constants in better
sync with the real hardware state.
Reviewed-by: mario.kleiner.de@gmail.com
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
drm core no longer uses crtc->hwmode, and neither does i915, so we can totally ignore it
in i915.
Reviewed-by: mario.kleiner.de@gmail.com
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Rather than using crtc->hwmode, just pass the relevant mode to
drm_calc_vbltimestamp_from_scanoutpos(). This removes the last hwmode
usage from core drm.
Reviewed-by: mario.kleiner.de@gmail.com
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
We don't really use hwmode anymore in i915, so eliminating its use
from the core code seems prudent. Just pass the appropriate mode
to drm_calc_timestamping_constants().
Reviewed-by: mario.kleiner.de@gmail.com
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Since commit 61b365a505 ("drm/nouveau: populate master subdev pointer
only when fully constructed"), the nouveau_mxm(bios) call will return
NULL, since it's still being called from the constructor. Instead, pass
the mxm pointer via the unused data field.
See https://bugs.freedesktop.org/show_bug.cgi?id=73791
Reported-by: Andreas Reis <andreas.reis@gmail.com>
Tested-by: Andreas Reis <andreas.reis@gmail.com>
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Dave Airlie <airlied@linux.ie>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
drm-intel-next-2014-01-10:
- final bits for runtime D3 on Haswell from Paul (now enabled fully)
- parse the backlight modulation freq information in the VBT from Jani
(but not yet used)
- more watermark improvements from Ville for ilk-ivb and bdw
- bugfixes for fastboot from Jesse
- watermark fix for i830M (but not yet everything)
- vlv vga hotplug w/a (Imre)
- piles of other small improvements, cleanups and fixes all over
Note that the pull request includes a backmerge of the last drm-fixes
pulled into Linus' tree - things where getting a bit too messy. So the
shortlog also contains a bunch of patches from Linus tree. Please yell if
you want me to frob it for you a bit.
* 'drm-intel-next' of git://people.freedesktop.org/~danvet/drm-intel: (609 commits)
drm/i915/bdw: make sure south port interrupts are enabled properly v2
drm/i915: Include more information in disabled hotplug interrupt warning
drm/i915: Only complain about a rogue hotplug IRQ after disabling
drm/i915: Only WARN about a stuck hotplug irq ONCE
drm/i915: s/hotplugt_status_gen4/hotplug_status_g4x/
Pull request of 2014-01-17
Pull request for 3.14. One not so urgent fix, One huge device update.
The pull request corresponds to the patches sent out on dri-devel, except:
[PATCH 02/33], review tag typo pointed out by Matt Turner.
[PATCH 04/33], dropped. The new surface formats are never used.
The upcoming vmware svga2 hardware version 11 will introduce the concept
of "guest backed objects" or -resources. The device will in principle
get all
of its memory from the guest, which has big advantages from the device
point of view.
This means that vmwgfx contexts, shaders and surfaces need to be backed
by guest memory in the form of buffer objects called MOBs, presumably
short for MemoryOBjects, which are bound to the device in a special way.
This patch series introduces guest backed object support. Some new IOCTLs
are added to allocate these new guest backed object, and to optionally
provide
them with a backing MOB.
There is an update to the gallium driver that comes with this update, and
it will be pushed in the near timeframe presumably to a separate mesa branch
before merged to master.
* tag 'vmwgfx-next-2014-01-17' of git://people.freedesktop.org/~thomash/linux: (33 commits)
drm/vmwgfx: Invalidate surface on non-readback unbind
drm/vmwgfx: Silence the device command verifier
drm/vmwgfx: Implement 64-bit Otable- and MOB binding v2
drm/vmwgfx: Fix surface framebuffer check for guest-backed surfaces
drm/vmwgfx: Update otable definitions
drm/vmwgfx: Use the linux DMA api also for MOBs
drm/vmwgfx: Ditch the vmw_dummy_query_bo_prepare function
drm/vmwgfx: Persistent tracking of context bindings
drm/vmwgfx: Track context bindings and scrub them upon exiting execbuf
drm/vmwgfx: Block the BIND_SHADERCONSTS command
drm/vmwgfx: Add a parameter to get max MOB memory size
drm/vmwgfx: Implement a buffer object synccpu ioctl.
drm/vmwgfx: Make sure that the multisampling is off
drm/vmwgfx: Extend the command verifier to handle guest-backed on / off
drm/vmwgfx: Fix up the vmwgfx_drv.h header for new files
drm/vmwgfx: Enable 3D for new hardware version
drm/vmwgfx: Add new unused (by user-space) commands to the verifier
drm/vmwgfx: Validate guest-backed shader const commands
drm/vmwgfx: Add guest-backed shaders
drm/vmwgfx: Hook up guest-backed surfaces
...
Fixes error messages in vmware.log
Signed-off-by: Jakob Bornecrantz <jakob@vmware.com>
Reviewed-by: Michael Banack <banackm@vmware.com>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
The device and kernel module disagrees about the command length of
some commands. More pack attributes might be needed.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Adds the relevant commands to the device interface header and
implements 64-bit binding for 64 bit VMs.
v2: Uppercase command IDs, Correctly use also 64 bit page tables.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
With guest-backed surfaces, surface->sizes == NULL, causing a kernel oops.
Use the base_size member instead.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Combine it with vmw_dummy_query_bo_create, and also make sure
we use tryreserve when reserving the bo to avoid any lockdep warnings
We are sure the tryreserve will always succeed since we are
the only users at that point.
In addition, allow the vmw_bo_pin function to pin/unpin system memory.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
Only scrub context bindings when a bound resource is destroyed, or when
the MOB backing the context is unbound.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Zack Rusin <zackr@vmware.com>
The device is no longer capable of scrubbing context bindings of resources
that are bound when destroyed.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
This ioctl enables inter-process synchronization of buffer objects,
which is needed for mesa Guest-Backed objects.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
By default SVGA device creates nonmaskable multisampling surfaces, in
which case multisampleCount of 1 means: the first quality setting
of nonmaskable multisampling surface. Lets change it to make sure
that the backends know that multisampling is really off.
Signed-off-by: Zack Rusin <zackr@vmware.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Make sure we disallow commands if the device doesn't support them.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Zack Rusin <zackr@vmware.com>
Contexts are managed by the kernel only, so disable access to GB
context commands from user-space
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Zack Ruzin <zackr@vmware.com>
When the backing store buffer is evicted, Issue a readback from the
resources and notify the resources that they are no longer bound to
a valid backing store.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Zack Rusin <zackr@vmware.com>
Perform a translation of legacy query commands should they occur
in the command stream.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Zack Rusin <zackr@vmware.com>
Also do basic consistency checking.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Zack Rusin <zackr@vmware.com>
To bind a buffer object as a MOB, just validate it as a MOB
memory type. We are reusing the GMRID manager, although we create a new
instance of it to manage MOB ids and tomake sure we don't exceed
the maximum amount of MOB pages.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Implement MOB setup, binding and unbinding, but don't hook up to
TTM yet.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Zack Rusin <zackr@vmware.com>
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Zack Rusin <zackr@vmware.com>
Conflicts:
drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c
In the future, Scanout buffers need not be backed by VRAM and
the two definitions will differ.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Zack Rusin <zackr@vmware.com>
With dma compliance / IOMMU support added to the driver in kernel 3.13,
the dma addresses can exceed 44 bits, which is what we support in
32-bit mode and with GMR1.
So in 32-bit mode and optionally in 64-bit mode, restrict the dma
addresses to 44 bits, and strip the old GMR1 code.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
Cc: stable@vger.kernel.org
Conflicts are getting out of hand, and now we have to shuffle even
more in -next which was also shuffled in -fixes (the call for
drm_mode_config_reset needs to move yet again).
So do a proper backmerge. I wanted to wait with this for the 3.13
relaese, but alas let's just do this now.
Conflicts:
drivers/gpu/drm/i915/i915_reg.h
drivers/gpu/drm/i915/intel_ddi.c
drivers/gpu/drm/i915/intel_display.c
drivers/gpu/drm/i915/intel_pm.c
Besides the conflict around the forcewake get/put (where we chaged the
called function in -fixes and added a new parameter in -next) code all
the current conflicts are of the adjacent lines changed type.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In some cases we enter the cursor code with file_priv = NULL causing an oops,
we also can try to unpin something that isn't pinned, and this is a good fix for it.
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
Single regression fix for nouveau
* 'drm-nouveau-next' of git://git.freedesktop.org/git/nouveau/linux-2.6:
drm/nouveau: fix null ptr dereferences on some boards
Regression from "device: populate master subdev pointer only when fully
constructed"
Reported-by: Bob Gleitsmann <rjgleits@bellsouth.net>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This stashes away the EDID data so that the sysfs per-connector file
"edid" can display it. Without this change, the "edid" file is always
empty.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
When a panel advertises one or more modes, they are used exclusively.
Other methods for obtaining the mode, such as DDC as used for HDMI or
binary EDID blobs embedded in the DT, are ignored. The panel drivers
should be providing this functionality if they want to expose it as
well.
Signed-off-by: Thierry Reding <treding@nvidia.com>
The mask of possible CRTCs that an output (DRM encoder) can be attached
to is relative to the position within the DRM device's list of CRTCs.
Deferred probing can cause this to not match the pipe number associated
with a CRTC. Use the newly introduced drm_crtc_mask() to compute the
mask by looking up the proper index of the given CRTC in the list.
Signed-off-by: Thierry Reding <treding@nvidia.com>
The intel_encoder_crtc_ok() is a duplicate of the drm_encoder_crtc_ok()
function that used to be only available in the DRM CRTC helpers. It has
recently been moved to the core, so the duplicate can now be dropped.
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Using the new drm_crtc_mask() function, drm_encoder_crtc_ok() can now be
written in a significantly shorter way, so it can be moved to a header
file and be made static inline.
Signed-off-by: Thierry Reding <treding@nvidia.com>
The encoder possible_crtcs mask identifies which CRTCs can be bound to
a particular encoder. Each bit from bit 0 defines an index in the list
of CRTCs held in the DRM mode_config crtc_list. Rather than having
drivers trying to track the position of their CRTCs in the list, expose
the code which already exists for calculating the appropriate mask bit
for a CRTC.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
[treding@nvidia.com: add drm_crtc_index(), move to core]
Signed-off-by: Thierry Reding <treding@nvidia.com>
devm_ioremap_resource() does sanity checks on the given resource. No
need to duplicate this in the driver.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Reviewed-by: Terje Bergstrom <tbergstrom@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Fix build error: qxl uses crc32 functions so it needs to select
CRC32.
Also use angle quotes around a kernel header file name.
drivers/built-in.o: In function `qxl_display_read_client_monitors_config':
(.text+0x19d754): undefined reference to `crc32_le'
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Include appropriate header file drm/r128/r128_drv.h in
drm/r128/r128_ioc32.c because function r128_compat_ioctl() has its
prototype declaration in the header file.
This eliminates the following warning in drm/r128/r128_ioc32.c:
drivers/gpu/drm/r128/r128_ioc32.c:196:6: warning: no previous prototype for ‘r128_compat_ioctl’ [-Wmissing-prototypes]
Signed-off-by: Rashika Kheria <rashika.kheria@gmail.com>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Mark function as static because it is not used outside the file
drm/via/via_drv.c.
This eliminates the following warning in drm/via/via_drv.c:
drivers/gpu/drm/via/via_drv.c:49:6: warning: no previous prototype for ‘via_driver_postclose’ [-Wmissing-prototypes]
Signed-off-by: Rashika Kheria <rashika.kheria@gmail.com>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Mark function as static because it is not used outside the file
drm/sis/sis_drv.c.
This eliminates the following warning in drm/sis/sis_drv.c:
drivers/gpu/drm/sis/sis_drv.c:97:6: warning: no previous prototype for ‘sis_driver_postclose’ [-Wmissing-prototypes]
Signed-off-by: Rashika Kheria <rashika.kheria@gmail.com>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Mark function qxl_device_init() as static in drm/qxl/qxl_kms.c because
it is not used outside this file.
This eliminates the following warning in drm/qxl/qxl_kms.c:
drivers/gpu/drm/qxl/qxl_kms.c:118:5: warning: no previous prototype for ‘qxl_device_init’ [-Wmissing-prototypes]
Signed-off-by: Rashika Kheria <rashika.kheria@gmail.com>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Include appropriate header file drivers/gpu/drm/mga/mga_drv.h in
drm/mga/mga_ioc32.c because function mga_compat_ioctl() has its
prototype declaration in the header file.
This eliminates the following warning in drm/mga/mga_ioc32.c:
drivers/gpu/drm/mga/mga_ioc32.c:207:6: warning: no previous prototype for ‘mga_compat_ioctl’ [-Wmissing-prototypes]
Signed-off-by: Rashika Kheria <rashika.kheria@gmail.com>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Mark functions mgag200_ttm_global_release(),
mgag200_ttm_bo_is_mgag200_bo() and mgag200_ttm_tt_create() as static in
drm/mgag200/mgag200_ttm.c because they are not used outside this file.
This eliminates the following warning in drm/mgag200/mgag200_ttm.c:
drivers/gpu/drm/mgag200/mgag200_ttm.c:84:1: warning: no previous prototype for ‘mgag200_ttm_global_release’ [-Wmissing-prototypes]
drivers/gpu/drm/mgag200/mgag200_ttm.c:105:6: warning: no previous prototype for ‘mgag200_ttm_bo_is_mgag200_bo’ [-Wmissing-prototypes]
drivers/gpu/drm/mgag200/mgag200_ttm.c:211:16: warning: no previous prototype for ‘mgag200_ttm_tt_create’ [-Wmissing-prototypes]
Signed-off-by: Rashika Kheria <rashika.kheria@gmail.com>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Mark functions mga_set_start_address(), mga_encoder_destroy() and
mga_connector_best_encoder() as static in drm/mgag200/mgag200_mode.c
because they are not used outside this file.
This eliminates the following warnings in drm/mgag200/mgag200_mode.c:
drivers/gpu/drm/mgag200/mgag200_mode.c:694:6: warning: no previous
prototype for ‘mga_set_start_address’ [-Wmissing-prototypes]
drivers/gpu/drm/mgag200/mgag200_mode.c:1401:6: warning: no previous
prototype for ‘mga_encoder_destroy’ [-Wmissing-prototypes]
drivers/gpu/drm/mgag200/mgag200_mode.c:1561:21: warning: no previous
prototype for ‘mga_connector_best_encoder’ [-Wmissing-prototypes]
Signed-off-by: Rashika Kheria <rashika.kheria@gmail.com>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Mark function mgag200_bo_unref() as static in drm/mgag200/mgag200_main.c
because it is not used outside this file.
This eliminates the following warning in drm/mgag200/mgag200_main.c:
drivers/gpu/drm/mgag200/mgag200_main.c:313:6: warning: no previous prototype for ‘mgag200_bo_unref’ [-Wmissing-prototypes]
Signed-off-by: Rashika Kheria <rashika.kheria@gmail.com>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Mark functions cirrus_ttm_global_release(), cirrus_ttm_bo_is_cirrus_bo()
and cirrus_ttm_tt_create() as static in drm/cirrus/cirrus_ttm.c because
they are not used outside this file. Remove unused function
cirrus_bo_unpin() from drm/cirrus/cirrus_ttm.c.
This eliminates the following warnings in drm/cirrus/cirrus_ttm.c:
drivers/gpu/drm/cirrus/cirrus_ttm.c:84:1: warning: no previous prototype for ‘cirrus_ttm_global_release’ [-Wmissing-prototypes]
drivers/gpu/drm/cirrus/cirrus_ttm.c:105:6: warning: no previous prototype for ‘cirrus_ttm_bo_is_cirrus_bo’ [-Wmissing-prototypes]
drivers/gpu/drm/cirrus/cirrus_ttm.c:211:16: warning: no previous prototype for ‘cirrus_ttm_tt_create’ [-Wmissing-prototypes]
drivers/gpu/drm/cirrus/cirrus_ttm.c:378:5: warning: no previous prototype for ‘cirrus_bo_unpin’ [-Wmissing-prototypes]
Signed-off-by: Rashika Kheria <rashika.kheria@gmail.com>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Mark functions cirrus_set_start_address(), cirrus_encoder_destroy(),
cirrus_vga_get_modes() and cirrus_connector_best_encoder() as static in
drm/cirrus/cirrus_mode.c because they are not used outside this file.
This eliminates the following warnings in drm/cirrus/cirrus_mode.c:
drivers/gpu/drm/cirrus/cirrus_mode.c:105:6: warning: no previous
prototype for ‘cirrus_set_start_address’ [-Wmissing-prototypes]
drivers/gpu/drm/cirrus/cirrus_mode.c:456:6: warning: no previous
prototype for ‘cirrus_encoder_destroy’ [-Wmissing-prototypes]
drivers/gpu/drm/cirrus/cirrus_mode.c:495:5: warning: no previous
prototype for ‘cirrus_vga_get_modes’ [-Wmissing-prototypes]
drivers/gpu/drm/cirrus/cirrus_mode.c:512:21: warning: no previous
prototype for ‘cirrus_connector_best_encoder’ [-Wmissing-prototypes]
Signed-off-by: Rashika Kheria <rashika.kheria@gmail.com>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Mark function cirrus_bo_unref() as static in drm/cirrus/cirrus_main.c
because it is not used outside this file.
This eliminates the following warning in drm/cirrus/cirrus_main.c:
drivers/gpu/drm/cirrus/cirrus_main.c:258:6: warning: no previous
prototype for ‘cirrus_bo_unref’ [-Wmissing-prototypes]
Signed-off-by: Rashika Kheria <rashika.kheria@gmail.com>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Mark functions ast_ttm_global_release(), ast_ttm_bo_is_ast_bo() and
ast_ttm_tt_create() as static in drm/ast/ast_ttm.c because they are not
used outside this file.
This eliminates the following warnings in drm/ast/ast_ttm.c:
drivers/gpu/drm/ast/ast_ttm.c:84:1: warning: no previous prototype for
‘ast_ttm_global_release’ [-Wmissing-prototypes]
drivers/gpu/drm/ast/ast_ttm.c:105:6: warning: no previous prototype for
‘ast_ttm_bo_is_ast_bo’ [-Wmissing-prototypes]
drivers/gpu/drm/ast/ast_ttm.c:211:16: warning: no previous prototype for
‘ast_ttm_tt_create’ [-Wmissing-prototypes]
Signed-off-by: Rashika Kheria <rashika.kheria@gmail.com>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Mark functions ast_set_sync_reg(), ast_set_dac_reg(),
ast_set_start_address_crt1(), ast_crtc_init(), ast_encoder_init(),
ast_connector_init(), ast_cursor_init(), ast_cursor_fini(),
ast_show_cursor() and ast_hide_cursor() as static in drm/ast/ast_mode.c
because they are not used outside this file.
This eliminates the following warning in drm/ast/ast_mode.c:
drivers/gpu/drm/ast/ast_mode.c:407:6: warning: no previous prototype for
‘ast_set_sync_reg’ [-Wmissing-prototypes]
drivers/gpu/drm/ast/ast_mode.c:418:6: warning: no previous prototype for
‘ast_set_dac_reg’ [-Wmissing-prototypes]
drivers/gpu/drm/ast/ast_mode.c:430:6: warning: no previous prototype for
‘ast_set_start_address_crt1’ [-Wmissing-prototypes]
drivers/gpu/drm/ast/ast_mode.c:626:5: warning: no previous prototype for
‘ast_crtc_init’ [-Wmissing-prototypes]
drivers/gpu/drm/ast/ast_mode.c:713:5: warning: no previous prototype for
‘ast_encoder_init’ [-Wmissing-prototypes]
drivers/gpu/drm/ast/ast_mode.c:780:5: warning: no previous prototype for
‘ast_connector_init’ [-Wmissing-prototypes]
drivers/gpu/drm/ast/ast_mode.c:813:5: warning: no previous prototype for
‘ast_cursor_init’ [-Wmissing-prototypes]
drivers/gpu/drm/ast/ast_mode.c:850:6: warning: no previous prototype for
‘ast_cursor_fini’ [-Wmissing-prototypes]
drivers/gpu/drm/ast/ast_mode.c:968:6: warning: no previous prototype for
‘ast_show_cursor’ [-Wmissing-prototypes]
drivers/gpu/drm/ast/ast_mode.c:979:6: warning: no previous prototype for
‘ast_hide_cursor’ [-Wmissing-prototypes]
Signed-off-by: Rashika Kheria <rashika.kheria@gmail.com>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Mark function ast_bo_unref() as static because it is not used outside
file ast_main.c and remove unused function ast_get_max_dclk() in
ast_main.c.
This eliminates the following warning in drm/ast/ast_main.c:
drivers/gpu/drm/ast/ast_main.c:192:10: warning: no previous prototype
for ‘ast_get_max_dclk’ [-Wmissing-prototypes]
drivers/gpu/drm/ast/ast_main.c:452:6: warning: no previous prototype for
‘ast_bo_unref’ [-Wmissing-prototypes]
Signed-off-by: Rashika Kheria <rashika.kheria@gmail.com>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Include appropriate header file include/drm/drm_usb.h in drm/drm_usb.c
because functions drm_get_usb_dev(), drm_usb_init() and drm_usb_exit()
have their prototype declarations in the header file.
This eliminates the following warning in drm/drm_usb.c:
drivers/gpu/drm/drm_usb.c:5:5: warning: no previous prototype for
‘drm_get_usb_dev’ [-Wmissing-prototypes]
drivers/gpu/drm/drm_usb.c:61:5: warning: no previous prototype for
‘drm_usb_init’ [-Wmissing-prototypes]
drivers/gpu/drm/drm_usb.c:75:6: warning: no previous prototype for
‘drm_usb_exit’ [-Wmissing-prototypes]
Signed-off-by: Rashika Kheria <rashika.kheria@gmail.com>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Acked-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This reverts commit 3fbd6439e4.
This caused some strange booting lockup issues on an Intel G33
belonging to Daniel Vetter, very unusual, I was hoping Daniel
would track this down, but it looks like instead I'll have to hack
a different fix for -next.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Black screen fixes, one for hsw+bdw each and a regression fix for
locking+load detection.
* tag 'drm-intel-fixes-2014-01-13' of git://people.freedesktop.org/~danvet/drm-intel:
drm/i915/bdw: make sure south port interrupts are enabled properly v2
drm/i915: Don't grab crtc mutexes in intel_modeset_gem_init()
drm/i915: fix DDI PLLs HW state readout code
This was hidden in a generic void * dev->mm_private. But only ever
used for gem. But thanks to this fake generic pretension no one
noticed that Rob's drm drivers are now all broken.
So just give the offset manager a type pointer and fix up msm, omapdrm
and tilcdc.
v2: Fixup compile fail.
v3: Fixup rebase fail that David spotted.
Cc: David Herrmann <dh.herrmann@gmail.com>
Cc: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Anyway, nothing big here, Three more code cleanup patches from Rashika
Kheria, and one TTM/vmwgfx patch from me that tightens security around TTM
objects enough for them to opened using prime objects from render nodes:
Previously any client could access a shared buffer using the "name", also
without actually opening it. Now a reference is required, and for render nodes
such a reference is intended to only be obtainable using a prime fd.
vmwgfx-next 2014-01-13 pull request
* tag 'vmwgfx-next-2014-01-13' of git://people.freedesktop.org/~thomash/linux:
drivers: gpu: Mark functions as static in vmwgfx_fence.c
drivers: gpu: Mark functions as static in vmwgfx_buffer.c
drivers: gpu: Mark functions as static in vmwgfx_kms.c
drm/ttm: ttm object security fixes for render nodes
Some code cleanup by Rashika Keria,
VM stuff for ttm:
-Use PFNMAP instead of MIXEDMAP where possible for performance
-Refuse to fault imported pages, an initial step to support dma-bufs
better from within TTM.
-Correctly set page mapping and -index members. These are needed in various
places in the vm subsystem that we are not using yet, but plan to use soonish:
For example unmap-mapping-range keeping COW pages, and dirty tracking
fbdefio style, but also for PCI memory.
ttm-next 2013-01-14 pull request
* tag 'ttm-next-2014-01-13' of git://people.freedesktop.org/~thomash/linux:
drivers: gpu: Remove unused function in ttm_lock.c
drivers: gpu: Mark function as static in ttm_bo_util.c
drivers: gpu: Mark function as static in ttm_bo.c
drm/ttm: Correctly set page mapping and -index members
drm/ttm: Refuse to fault (prime-) imported pages
drm/ttm: Use VM_PFNMAP for shared bo maps
Xorg fbdev driver requires smem_start/smem_len, otherwise
it tries to map 0 bytes as video memory.
Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=856760
Signed-off-by: Martin Koegler <martin.koegler@chello.at>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This pull request adds an anon file for exynos specific mmaper
to resolve potential a dead lock issue pointed out by Al Viro,
and fixes build break of drm-next.
* 'exynos-drm-next' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos:
drm/exynos: fix build error caused by removed drm core macros
drm/exynos: use a new anon file for exynos gem mmaper
This is the drm-next pull for radeon for 3.14. Highlights include:
- dpm rework which fixes some issues and allows us to enable dpm by
default on CIK parts
- enable clockgating on CIK parts
- pci config reset. This is a bus-level chip reset that can be more
reliable than soft reset in certain cases. Disabled by default. Enable
with the hard_reset module option.
- big endian rptr/wrptr update fixes
- lots of debugfs improvements
- some driver cleanup patches from Rashika Kheria
- bug fixes
* 'drm-next-3.14-wip' of git://people.freedesktop.org/~agd5f/linux: (50 commits)
drm/radeon: implement pci config reset for CIK (v3)
drm/radeon: implement pci config reset for SI (v2)
drm/radeon: implement pci config reset for evergreen/cayman (v2)
drm/radeon: implement pci config reset for r6xx/7xx (v3)
drm/radeon: add pci config hard reset
drm/radeon: add hard_reset module parameter
drm/radeon: skip colorbuffer checking if COLOR_INFO.FORMAT is set to INVALID
radeon/pm: Guard access to rdev->pm.power_state array
drivers: gpu: Move prototype declarations to header file radeon_mode.h from radeon_atombios.c and radeon_combios.c
drivers: gpu: Move prototype declaration to header file radeon_mode.h
drm/radeon: move com/atombios scratch reg functions to radeon_mode.h
drm/radeon/dpm: make some functions static for TN
drm/radeon/dpm: make some functions static for sumo
drm/radeon/dpm: make some functions static for CI
drivers: gpu: Include appropriate header file in ci_smc.c
drivers: gpu: Move prototype declaration to header file radeon_mode.h from atombios_i2c.c
drivers: gpu: Include appropriate header file in si_smc.c and remove prototype declaration from header file sislands_smc.h
drivers: gpu: Add static keyword to the definition of KMS_INVALID_IOCTL in radeon_kms.c
drivers: gpu: Mark function as static in r600_hdmi.c
drivers: gpu: Mark function as static in radeon_gem.c
...
MSM tree from Rob.
* 'msm-next' of git://people.freedesktop.org/~robclark/linux:
drm/msm: add a330/apq8x74
drm/msm: add mdp5/apq8x74
drm/msm: add hdmi support for apq8x74/mdp5
drm/msm: move irq utils to mdp_kms
drm/msm: split out msm_kms.h
drm/msm: mdp4_format -> mdp_format
drm/msm: resync generated headers
drm/msm: move mdp4 -> mdp/mdp4
drm/msm: add support for msm8060ab/bstem
drm/msm: add support for non-IOMMU systems
drm/msm: fix bus scaling
drm/msm: add missing MODULE_FIRMWARE()s
drm/msm: COMPILE_TEST support
We were apparently relying on the defaults on BDW, which resulted in no
hotplug or AUX interrupts. So be sure to call the ibx_irq_preinstall to
enable all interrupts.
v2: use preinstall instead of redundant SDIER write
References: https://bugs.freedesktop.org/show_bug.cgi?id=72834
References: https://bugs.freedesktop.org/show_bug.cgi?id=72833
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Daniel thought that this was an opportune moment to include which pins
and bits ended up being stuck in the WARN.
Suggested-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Disabling the hotplug IRQ is a two-step process. First, inside the IRQ
handler we mark the rogue hotplug pin for disabling. Then later in the
hotplug worker, we actually disable the hotplug pin. So we should not
WARN about the rogue hotplug IRQ being sent until after we have
completed disabling the pin.
References: https://bugzilla.redhat.com/show_bug.cgi?id=1051170
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It seems that hardware that is broken enough to emit a hotplug IRQ even
though the pin is surposedly disable, will do so indefinitely.
Note: There's a good chance the underlying issue has been fixed with
commit 0ce99f749b
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Fri Jul 26 11:27:49 2013 +0200
drm/i915: fix gen4 digital port hotplug definitions
References: https://bugzilla.redhat.com/show_bug.cgi?id=1051170
Link: https://bugzilla.redhat.com/attachment.cgi?id=847786
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Add note about the potential fix.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We specifically exclude original gen4 (i.e. i965g/gm), so update the
naming for consistency. Spotted while reviewing related code due to a
report from Jesse about byt needing again different values.
v2: g4x, not gm45 since this also applies to the desktop version.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It's an accident waiting to happen.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
INSTPM is a masked register so use the _MASKED_BIT_{ENABLE,DISABLE}
macros when enabling/disabling self-refresh on 915GM.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
There's no LVDS port on 830M so don't go reading the LVDS control
register.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
PFIT_CONTROL doesn't exist on 830M, so avoid reading it in
i9xx_get_pfit_config().
Also assume that only mobile gen2/3 chipsets have a panel fitter. This
matches the documentation, but I didn't have real hardware to verify.
Gen4 docmentation is a bit inconsistent, but experimenetation on my
LPT machine suggests that the panel fitter is available on non-mobile
gen4 platforms. At least on this machine panel fitter appears works
just fine even on VGA output.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Many of the fields from Gen6 have gone away for vlv. Strip all those
fields that are not relevent and try to update fields that we care
about. This patch give information about current RP & RC status and
individual Wells.
v2: Move Render & Media Well status to separate lines (Ville)
Signed-off-by: Deepak S <deepak.s@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
VGA detection requires the reference clock to be on, so make sure this
is the case.
This fixes VGA hotplug/manual detection where all pipes are off and so
we would normally disable all clocks.
v2:
- Instead of disabling PSR clock gating, force the reference clock on
through the DPLL_A register. (Kin Chan S <kin.s.chan@intel.com>)
v3:
- Move enabling of the clock to intel_reset_dpio() and use the DPLL_B
register instead, where we already have a similar tweak for the CRI
clock. (Ville)
Reported-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
intel_init_dpio() isn't called during resume, so we won't set the CRI
clock enable bit during that time. Move the enabling to
intel_reset_dpio() instead.
Note that the HW reset value for this bit is 1, so probably this patch
won't make any difference. We should still make the setting explicit,
since BIOS could change things under us.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The WA is mentioned in HSW's GAMMA_MODE register documentation, but
not on on BDW's documentation, so let's assume it is not needed there.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
That we can use for debugging purposes.
v2: Use designated initializers for the 'names' array (Paulo Zanoni,
Jani Nikula).
Add a check in case the array has a hole (which can now remain
unnoticed with designated initializers) (Jani Nikula)
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> (for v1)
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In some cases we have more than 1 connector associated to an encoder
(e.g., SDVO, Haswell DP/HDMI) and we can only set a mode for one of
these connectors. If we only allowed modesets for connected connectors
we would never need this patch, but since we do allow modeset for
disconnected connectors we may see user space trying to set modes on
the two connectors attached to the same encoder, so we need to forbid
that.
This problem can be reproduced by running the following
intel-gpu-tools test case:
./kms_setmode --run-subtest clone-exclusive-crtc
Thanks to Daniel Vetter for providing a version of this patch on
pastebin.
Credits-to: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
So shuffle the checks around a bit. Also give all the structs and
functions proper prefixes: i830_ for the dual-pipe mobile platforms
and i845_ for the two single-pipe desktop platforms.
Note that the max fifo value isn't actually correct for the i830M, but
since we don't frob the fifo split we don't actually need it. This is
different for some gen3 devices where we need the full fifo for self
refresh mode.
Cc: Thomas Richter <richter@rus.uni-stuttgart.de>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
My OCD just couldn't let this slide. Spotted while reviewing Ville's
patch to only flip planes when we have FBC.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Looks like 830M doesn't quite like it when you try to move a plane from
one pipe to another. It seems that the plane's old pipe has to be active
even if the plane is already disabled, otherwise the relevant register
just won't accept new values.
The following commit:
commit 1f1c2e2468
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Thu Nov 28 17:30:01 2013 +0200
drm/i915: Swap primary planes on gen2 for FBC
caused a regression on 830M. It will attempt to swap the planes when the
driver is loaded, but at that time only pipe A might be active, so plane
A gets disabled, but plane B won't get enabled since pipe B is not
active when we try to move the plane over to pipe A.
There's no reason to swap planes on 830M since it doesn't support
FBC. Change the logic a bit to limit the plane swapping to platforms
which actually support FBC. This should avoid getting a black screen on
830M.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When the pipe A force quirk is applied the code will attempt to grab
a crtc mutex during intel_modeset_setup_hw_state(). If we're already
holding all crtc mutexes this will obviously deadlock every time.
So instead of using drm_modeset_lock_all() just grab the
mode_config.mutex. This is enough to avoid the unlocked mutex warnings
from certain lower level functions.
The regression was introduced in:
commit 0274766428
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Mon Dec 2 11:08:06 2013 +0200
drm/i915: Take modeset locks around intel_modeset_setup_hw_state()
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: stable@vger.kernel.org
[danvet: Add cc: stable since the offending commit has that, too.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Freeing a request triggers the destruction of the context. This needs to
occur after all objects are themselves unbound from the context, and so
the free request needs to occur after the object release during retire.
This tidies up
commit e20780439b
Author: Ben Widawsky <ben@bwidawsk.net>
Date: Fri Dec 6 14:11:22 2013 -0800
drm/i915: Defer request freeing
by simply swapping the order of operations rather than introducing
further complexity - as noted during review.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The initialized flag is used to specify a context has been initialized
and it's context is safe to load, ie. the 3d state is setup properly.
With full PPGTT, we emit the address space loads during context switch
and this currently marks a context as initialized. With full PPGTT
patches, if a client first emits a batch to !RCS, then later, RCS, the
code will mistake the context as initialized and try to reload an
uninitialized context.
1. context 1 blit // context marked as initialized, but isn't
2. context 1 render // loads random state from step 2
It is really easy to hit this with a planned upcoming patch which makes
default context reuse possible.
NOTE: This should only effect full PPGTT branches, ie. current
drm-intel-nightly.
Thanks to Chris for helping me track this down.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Simplify the failure scenario in the commit message according
to Chris' review a bit.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This was an accidental "ABI" change introduced during PPGTT:
commit 0eea67eb26
Author: Ben Widawsky <ben@bwidawsk.net>
Date: Fri Dec 6 14:11:19 2013 -0800
drm/i915: Create a per file_priv default context
The failure test application actually tests the return type. The other
option is to simply change the test.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
A regression in the topic/ppgtt branch introduce in
commit 87d60b63e0
Author: Ben Widawsky <ben@bwidawsk.net>
Date: Fri Dec 6 14:11:29 2013 -0800
drm/i915: Add PPGTT dumper
The issue is that we're missing the definitions for the seq_file
functions and hence compilation fails.
v2: Just include the right header instead of splattering #ifdefs all
over the place (Chris).
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Reported-by: Antti Koskipaa <antti.koskipaa@linux.intel.com>
Cc: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Add support for adreno 330. Not too much different, just a few
differences in initial configuration plus setting OCMEM base.
Userspace support is already in upstream mesa.
Note that the existing DT code is simply using the bindings from
downstream android kernel, to simplify porting of this driver to
existing devices. These do not constitute any committed/stable
DT ABI. The addition of proper DT bindings will be a subsequent
patch, at which point (as best as possible) I will try to support
either upstream bindings or what is found in downstream android
kernel, so that existing device DT files can be used.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Add support for the new MDP5 display controller block. The mapping
between parts of the display controller and KMS is:
plane -> PIPE{RGBn,VIGn} \
crtc -> LM (layer mixer) |-> MDP "device"
encoder -> INTF /
connector -> HDMI/DSI/eDP/etc --> other device(s)
Unlike MDP4, it appears we can get by with a single encoder, rather
than needing a different implementation for DTV, DSI, etc. (Ie. the
register interface is same, just different bases.)
Also unlike MDP4, all the IRQs for other blocks (HDMI, DSI, etc) are
routed through MDP.
And finally, MDP5 has this "Shared Memory Pool" (called "SMP"), from
which blocks need to be allocated to the active pipes based on fetch
stride.
Signed-off-by: Rob Clark <robdclark@gmail.com>
The HDMI block is basically the same between older SoC's with mdp4
display controller, and newer ones with mdp5.
So mostly this consists of better abstracting out the different sets of
regulators, clks, etc. In particular, for regulators and clks we can
split it up by what is needed for hot plug detect to work, and what is
needed to light up the display.
Also, 8x74 has a new phy.. a very simple one, but split out into a
different mmio space. And with mdp5, the irq is shared with mdp, so we
don't directly register our own irq handler.
Signed-off-by: Rob Clark <robdclark@gmail.com>
This can be shared between mdp4 and mdp5. Both use the same set of
parameters to describe the format to the hw.
Signed-off-by: Rob Clark <robdclark@gmail.com>
There are some little bits and pieces that mdp4 and mdp5 can share, so
move things around so that we can have both in a common parent
directory.
Signed-off-by: Rob Clark <robdclark@gmail.com>
This adds the necessary configuration for the APQ8060A SoC (dual-core
krait + a320 gpu) as found on the bstem board.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Add a VRAM carveout that is used for systems which do not have an IOMMU.
The VRAM carveout uses CMA. The arch code must setup a CMA pool for the
device (preferrably in highmem.. a 256m-512m VRAM pool in lowmem is not
cool). The user can configure the VRAM pool size using msm.vram module
param.
Technically, the abstraction of IOMMU behind msm_mmu is not strictly
needed, but it simplifies the GEM code a bit, and will be useful later
when I add support for a2xx devices with GPUMMU, so I decided to keep
this part.
It appears to be possible to configure the GPU to restrict access to
addresses within the VRAM pool, but this is not done yet. So for now
the GPU will refuse to load if there is no sort of mmu. Once address
based limits are supported and tested to confirm that we aren't giving
the GPU access to arbitrary memory, this restriction can be lifted
Signed-off-by: Rob Clark <robdclark@gmail.com>
This got a bit broken with original patches when re-arranging things to
move dependencies on mach-msm inside #ifndef OF.
Signed-off-by: Rob Clark <robdclark@gmail.com>
Enable use of DT for DMM/Tiler.
Originally worked on by Andy Gross <andygro@gmail.com>
Cc: Andy Gross <andygro@gmail.com>
Cc: DRI Development <dri-devel@lists.freedesktop.org>
Signed-off-by: Archit Taneja <archit@ti.com>
[tomi.valkeinen@ti.com: use of_match_ptr()]
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
The current dev_unload order uninits the irqs too early.
In the current sequence, it's possible that a crtc queues work(apply_worker)
to display a buffer, which registers to omap_crtc_apply_irq to notfiy the
completion of the configuration we applied.
Calling drm_vblank_cleanup and omap_drm_irq_uninstall here causes the crtc's
apply handler to never get called, which results in an incorrect state of the
apply_irq.registered parameter.
This condition occurs where there is no mode set via omapdrm, and dev_lastclose
tries to set a default fb mode via drm_fb_helper_restore_fbdev_mode. The apply
work scheduled by restore_fbdev_mode is very close in time to the disabling of
the irq handler, and hence leads to a race condition. We move the irq cleanup
at the end of the unload sequence to prevent this.
Also, the call to flush_workqueue is removed since it's called internally by
destroy_workqueue.
Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Currently, an encoder is disabled only when an apply work is queued for the
corresponding crtc. This works fine for the paths where userspace explicitly
disables crtc, this results in disabling the omapdss device in the crtc's
pre_apply function.
However, when the omapdrm module is removed, there is no work queued to ensure
that the encoder is disabled. This can result in an enabled omapdss device when
removing omapdrm. omapdss is left in an inconsistent state, and that prevents us
from using that omapdss device being used again.
Disable enabled encoders in omap_encoder_destroy, we could consider a better
place for doing this later.
Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
At omapdrm probe, we install manager ops and connect omapdss devices. This
needs to be undone when omapdrm module is removed so that omapdss is in a
clean state. This ensures that we can re-insert omapdrm module, or some other
module which uses omapdss(like omapfb/omap_vout).
Currently, omapdrm's remove neither uninstalls manager ops, or disconnects
omapdss devices. We make sure that this is done in pdev_remove.
omapdrm establishes connections for omap_dss_device devices when probed. It
should also be responsible to disconnect the devices. Keeping the devices
connected can prevent the panel driver modules from unloading, it also causes
issues when we try to remove or re-insert omapdrm module.
Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
With the omapdss device model changes. omapdrm is required to call dssdriver's
connect() op to register a panel. This is currently done in omap_modeset_init()
A call to connect() can fail if the omapdss panels or the encoders(HDMI/DPI)
they connect to have some resource(like regulators, I2C adapter) missing. If
this happens, the correct approach is to defer omapdrm's probe.
omapdrm currently ignores those panels which return a non zero value when
connected. This could result in omapdrm ignoring all panels on an omap board.
The right approach would be for omapdrm to request for probe deferral when a
panel's connect op returns -EPROBE_DEFER.
In order to do this, we need to call connect() much earlier during omapdrm's
probe to prevent too many things are already done by then. We now connect the
panels during pdev_probe(), before anything else is initialized, so that we
don't need to undo too many things if a defer was requested.
Now when we enter omap_modeset_init(), we have a set of panels that have been
connected. We now proceed with registering only those panels that are already
connected.
A special case has to be considered when no panels are available to connect when
omapdrm probes. In this case too, we defer probe and expect that a panel will be
available to connect the next time.
Checking whether the panel has a driver or whether it has get_timing/read_edid
ops in omap_modeset_init() are redundant with the new display model. These can
be removed since a dssdev device will always have a driver associated with it,
and all dssdev drivers have a get_timings op.
This will mainly fix cases when omapdrm is built-in the kernel, since that's
generally where resources like regulators or I2C are unavailable because of
probe order dependencies.
In particular this fixes boot with omapdrm built-in on an omap4 panda ES board.
The regulators used by HDMI(provided by I2C based TWL regulators) aren't
initialized because I2C isn't initialized, I2C isn't initialized as it's pins
are not configured because pinctrl is yet to probe.
Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
omapdrm (un)registers irqs inside an irq handler. The problem is that
the (un)register function uses dispc_runtime_get/put() to enable the
clocks, and those functions are not irq safe by default.
This was kind of fixed in 48664b21ae
(OMAPDSS: DISPC: set irq_safe for runtime PM), which makes dispc's
runtime calls irq-safe.
However, using pm_runtime_irq_safe in dispc makes the parent of dispc,
dss, always enabled, effectively preventing PM for the whole DSS module.
This patch makes omapdrm behave better by adding new irq (un)register
functions that do not use dispc_runtime_get/put, and using those
functions in interrupt context. Thus we can make dispc again
non-irq-safe, allowing proper PM.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Rob Clark <robdclark@gmail.com>
pci config reset is a low level reset that resets
the entire chip from the bus interface. It can
be more reliable if soft reset fails.
v2: fix rebase
v3: hide behind module parameter
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
pci config reset is a low level reset that resets
the entire chip from the bus interface. It can
be more reliable if soft reset fails.
v2: hide behind module parameter
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
pci config reset is a low level reset that resets
the entire chip from the bus interface. It can
be more reliable if soft reset fails.
v2: put behind module parameter
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
pci config reset is a low level reset that resets
the entire chip from the bus interface. It can
be more reliable if soft reset fails.
There's not much information still available on
r6xx, so r6xx is based on guess-work.
v2: put behind module parameter
v3: add IGP check
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
This is used to hard reset the asic. If a soft
reset is not able to reset things, a hard reset
can be used.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Enabling this parameter enables pci config reset,
aka hard reset, which is a bus level chip reset.
In some cases this works more reliably than a soft
reset. Disabled by default.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
LPT does have PCH refclk, but it's different form the IBX/CPT/PPT one
and doesn't use the same structs. It is wrong to have a message saying
that "LPT does not has PCH refclk" (sic). While at it, signal that we
only want this function on IBX/CPT/PPT by renaming it and adding a
WARN.
On HSW we also print "0 shared PLLs initialized", but we *do* have
shared PLLs on HSW (LCPLL, WRPLL, SPLL) and we *do* initialize them.
We just don't use "struct intel_shared_dpll". So remove the debug
message.
In the future we may want to rename all that "intel shared pll" code
to "ibx shared pll", but I'll leave this to another patch.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This fixes a bug which was causing rejections of valid GPU commands
from userspace.
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
It's never allocated on systems without an ATOMBIOS or COMBIOS ROM.
Should fix an oops I encountered while resetting the GPU after a lockup
on my PowerBook with an RV350.
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
The Chunghwa CLAA101WA01A is a 10.1" 1366x768 panel, which can be
supported by the simple panel driver.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The Samsung LNT101NT05 10.1" WXVGA panel can be supported by the simple panel
driver.
Cc: linux-fbdev@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: David Airlie <airlied@linux.ie>
Signed-off-by: Marc Dietrich <marvin24@gmx.de>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Properly zero the refcounts and crtc->ddi_pll_set so the previous HW
state doesn't affect the result of reading the current HW state.
This fixes WARNs about WRPLL refcount if we have an HDMI monitor on
HSW and then suspend/resume.
Cc: stable@vger.kernel.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=64379
Tested-by: Qingshuai Tian <qingshuai.tian@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
According to Art, we don't have a way to read back the state reliably at
runtime, through the control reg or the mailbox, at least not without risking
disabling it again. So drop the readout and checking on BDW.
v2: drop TODO comment (Paulo)
move POSTING_READ of control reg under HSW branch in disable (Paulo)
always report IPS as enabled on BDW (Paulo)
References: https://bugs.freedesktop.org/show_bug.cgi?id=71906
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Mark functions as static because they are not used outside the file
drm/vmwgfx/vmwgfx_fence.c.
This eliminates the following warnings in drm/vmwgfx/vmwgfx_fence.c:
drivers/gpu/drm/vmwgfx/vmwgfx_fence.c:274:6: warning: no previous prototype for ‘vmw_fences_perform_actions’ [-Wmissing-prototypes]
drivers/gpu/drm/vmwgfx/vmwgfx_fence.c:900:6: warning: no previous prototype for ‘vmw_fence_obj_add_action’ [-Wmissing-prototypes]
drivers/gpu/drm/vmwgfx/vmwgfx_fence.c:996:5: warning: no previous prototype for ‘vmw_event_fence_action_create’ [-Wmissing-prototypes]
Signed-off-by: Rashika Kheria <rashika.kheria@gmail.com>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
Mark functions as static because they are not used outside the file
drm/vmwgfx/vmwgfx_buffer.c.
This eliminates the following warnings in drm/vmwgfx/vmwgfx_buffer.c:
drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c:520:16: warning: no previous prototype for ‘vmw_ttm_tt_create’ [-Wmissing-prototypes]
drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c:549:5: warning: no previous prototype for ‘vmw_invalidate_caches’ [-Wmissing-prototypes]
drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c:554:5: warning: no previous prototype for ‘vmw_init_mem_type’ [-Wmissing-prototypes]
drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c:592:6: warning: no previous prototype for ‘vmw_evict_flags’ [-Wmissing-prototypes]
Signed-off-by: Rashika Kheria <rashika.kheria@gmail.com>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
Mark functions as static because they are not used outside the file
drm/vmwgfx/vmwgfx_kms.c.
This eliminates the following warnings in drm/vmwgfx/vmwgfx_kms.c:
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c:43:6: warning: no previous prototype for ‘vmw_clip_cliprects’ [-Wmissing-prototypes]
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c:426:6: warning: no previous prototype for ‘vmw_framebuffer_surface_destroy’ [-Wmissing-prototypes]
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c:592:5: warning: no previous prototype for ‘vmw_framebuffer_surface_dirty’ [-Wmissing-prototypes]
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c:757:6: warning: no previous prototype for ‘vmw_framebuffer_dmabuf_destroy’ [-Wmissing-prototypes]
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c:943:5: warning: no previous prototype for ‘vmw_framebuffer_dmabuf_dirty’ [-Wmissing-prototypes]
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c:1666:5: warning: no previous prototype for ‘vmw_du_update_layout’ [-Wmissing-prototypes]
Signed-off-by: Rashika Kheria <rashika.kheria@gmail.com>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
Remove unused function ttm_write_lock_downgrade() from
drm/ttm/ttm_lock.c.
This eliminates the following warning in drm/ttm/ttm_lock.c:
drivers/gpu/drm/ttm/ttm_lock.c:189:6: warning: no previous prototype for ‘ttm_write_lock_downgrade’ [-Wmissing-prototypes]
Signed-off-by: Rashika Kheria <rashika.kheria@gmail.com>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Mark functions as static because they are not used outside the file
drm/ttm/ttm_bo_util.c.
This eliminates the following warnings in drm/ttm/ttm_bo_util.c:
drivers/gpu/drm/ttm/ttm_bo_util.c:190:5: warning: no previous prototype for ‘ttm_mem_reg_ioremap’ [-Wmissing-prototypes]
drivers/gpu/drm/ttm/ttm_bo_util.c:222:6: warning: no previous prototype for ‘ttm_mem_reg_iounmap’ [-Wmissing-prototypes]
Signed-off-by: Rashika Kheria <rashika.kheria@gmail.com>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Mark function as static because it is not used outside file
drm/ttm/ttm_bo.c.
This eliminates the following warning in drm/ttm/ttm_bo.c:
drivers/gpu/drm/ttm/ttm_bo.c:960:5: warning: no previous prototype for ‘ttm_bo_move_buffer’ [-Wmissing-prototypes]
Signed-off-by: Rashika Kheria <rashika.kheria@gmail.com>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
This was introduced in:
commit 7c4a395ff8
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Wed Oct 9 19:17:56 2013 +0300
drm/i915: Don't re-compute pipe watermarks except for the affected pipe
and I missed fixing it in:
commit fec8cba306
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date: Wed Nov 27 11:10:26 2013 -0800
drm/i915: use crtc_htotal in watermark calculations to match fastboot v2
It's needed for ILK+ platforms to fastboot without crashing on a divide
by 0 after a DPMS on action.
Note: Ville mentioned in his review that this confusion seems to go
down to the original introduction of this code in
commit 801bcfffbb
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date: Fri May 31 10:08:35 2013 -0300
drm/i915: properly set HSW WM_PIPE registers
So it seems to have been missed both in the fastboot patch and in the
3d mode suppport (where only crtc_htotal reflects the real pipe
width).
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Add note based on Ville's review.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When a client looks up a ttm object, don't look it up through the device hash
table, but rather from the file hash table. That makes sure that the client
has indeed put a reference on the object, or in gem terms, has opened
the object; either using prime or using the global "name".
To avoid a performance loss, make sure the file hash table entries can be
looked up from under an RCU lock, and as a consequence, replace the rwlock
with a spinlock, since we never need to take it in read mode only anymore.
Finally add a ttm object lookup function for the device hash table, that is
intended to be used when we put a ref object on a base object or, in gem terms,
when we open the object.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
Needed for some vm operations; most notably unmap_mapping_range() with
even_cows = 0.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
This is illegal for at least two reasons:
1) While it may work on some platforms / iommus, obtaining page pointers from
mapped sg-lists is illegal, since the DMA API allows page pointer information
to be destroyed in the sg mapping process.
2) TTM has no way of determining the linear kernel map caching state of the
underlying pages. PTEs with conflicting caching state pointing to the same
pfn is not allowed.
TTM operations touching pages of imported sg-tables should be redirected through
the proper dma-buf operations.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Acked-by: Daniel Vetter <daniel@ffwll.ch>
VM_PFNMAP is faster than VM_MIXEDMAP due to reduced page administration so
use it for shared maps where we don't have any Copy-On-Write pages. For
private maps, we continue to use VM_MIXEDMAP.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
misc fixes for nouveau, one more msi rearm, regression fix for old bioses
crash and leak fixes.
* 'drm-nouveau-next' of git://anongit.freedesktop.org/nouveau/linux-2.6:
drm/nouveau/nouveau: fix memory leak in nouveau_crtc_page_flip()
drm/nouveau/bios: fix offset calculation for BMPv1 bioses
drm/nouveau: return offset of allocated notifier
drm/nouveau/bios: make jump conditional
drm/nvce/mc: fix msi rearm on GF114
drm/nvc0/gr: fix mthd data submission
drm/nouveau: populate master subdev pointer only when fully constructed
When fastbooting, we read out the pipe timings early on, and then in a
panel fitted config, disable the fitter later. But we weren't updating
the pipe src h/w, which meant the mouse cursor was clipped to the
pfitted size rather than the native size set later. Fix that up so the
cursor is visible in the new mode.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Otherwise we won't check the state until the next DPMS transition, which
may never happen.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Fix a memory leak in the nouveau_crtc_page_flip() error handling path.
Signed-off-by: Christian Engelmayer <cengelma@gmx.at>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The only BIOS on record that needs the 14 offset has a bios major
version 2 but BMP version 1.01. Another bunch of BIOSes that need the 18
offset have BMP version 2.01 or 5.01 or higher. So instead of looking at the
bios major version, look at the BMP version. BIOSes with BMP version 0
do not contain a detectable script, so always return 0 for them.
See https://bugs.freedesktop.org/show_bug.cgi?id=68835
Reported-by: Mauro Molinari <mauromol@tiscali.it>
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Avoid duplicating the same piece of code several times by separating
the watemark vfunc setup from the init_clock_gating vfunc setup on PCH
platforms.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We forgot to intialize the watermark vfuncs for BDW, and hence the
watermarks were never updated.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Looks like I forgot to update the ILK/SNB/IVB watermark patches to deal
with BDW. Add the relevant BDW checks to make sure we take the HSW
codepaths on BDW as well.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Move prototype declarations of functions radeon_get_encoder_enum() and
radeon_link_encoder_connector() to header file drm/radeon/radeon_mode.h
because they are used by more than one file.
This eliminates the following warnings in drm/radeon/radeon_encoders.c:
drivers/gpu/drm/radeon/radeon_encoders.c:86:1: warning: no previous prototype for ‘radeon_get_encoder_enum’ [-Wmissing-prototypes]
drivers/gpu/drm/radeon/radeon_encoders.c:162:1: warning: no previous prototype for ‘radeon_link_encoder_connector’ [-Wmissing-prototypes]
Signed-off-by: Rashika Kheria <rashika.kheria@gmail.com>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Move prototype declaration of functions radeon_add_atom_connector() and
radeon_add_legacy_connector() to header file drm/radeon/radeon_mode.h
because they are used by more than one file.
This eliminates the following warning in drm/radeon/radeon_connectors.c:
drivers/gpu/drm/radeon/radeon_connectors.c:1588:1: warning: no previous prototype for ‘radeon_add_atom_connector’ [-Wmissing-prototypes]
drivers/gpu/drm/radeon/radeon_connectors.c:2020:1: warning: no previous prototype for ‘radeon_add_legacy_connector’ [-Wmissing-prototypes]
Signed-off-by: Rashika Kheria <rashika.kheria@gmail.com>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
fixes warnings with -Wmissing-prototypes
Based on initial patches from Rashika Kheria.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: Rashika Kheria <rashika.kheria@gmail.com>
Noticed by Rashika Kheria and cherry-picked from
her larger patch set.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: Rashika Kheria <rashika.kheria@gmail.com>
Noticed by Rashika Kheria and cherry-picked from
her larger patch set.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: Rashika Kheria <rashika.kheria@gmail.com>
Noticed by Rashika Kheria and cherry-picked from
her larger patch set.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: Rashika Kheria <rashika.kheria@gmail.com>
Include header file drm/radeon/ci_dpm.h in drm/radeon/ci_smc.c because
it uses function declared in the header file.
This eliminates the following warnings in drm/radeon/ci_smc.c:
drivers/gpu/drm/radeon/ci_smc.c:46:5: warning: no previous prototype for ‘ci_copy_bytes_to_smc’ [-Wmissing-prototypes]
drivers/gpu/drm/radeon/ci_smc.c:113:6: warning: no previous prototype for ‘ci_start_smc’ [-Wmissing-prototypes]
drivers/gpu/drm/radeon/ci_smc.c:121:6: warning: no previous prototype for ‘ci_reset_smc’ [-Wmissing-prototypes]
drivers/gpu/drm/radeon/ci_smc.c:129:5: warning: no previous prototype for ‘ci_program_jump_on_start’ [-Wmissing-prototypes]
drivers/gpu/drm/radeon/ci_smc.c:136:6: warning: no previous prototype for ‘ci_stop_smc_clock’ [-Wmissing-prototypes]
drivers/gpu/drm/radeon/ci_smc.c:145:6: warning: no previous prototype for ‘ci_start_smc_clock’ [-Wmissing-prototypes]
drivers/gpu/drm/radeon/ci_smc.c:154:6: warning: no previous prototype for ‘ci_is_smc_running’ [-Wmissing-prototypes]
drivers/gpu/drm/radeon/ci_smc.c:165:14: warning: no previous prototype for ‘ci_send_msg_to_smc’ [-Wmissing-prototypes]
drivers/gpu/drm/radeon/ci_smc.c:186:14: warning: no previous prototype for ‘ci_wait_for_smc_inactive’ [-Wmissing-prototypes]
drivers/gpu/drm/radeon/ci_smc.c:204:5: warning: no previous prototype for ‘ci_load_smc_ucode’ [-Wmissing-prototypes]
drivers/gpu/drm/radeon/ci_smc.c:251:5: warning: no previous prototype for ‘ci_read_smc_sram_dword’ [-Wmissing-prototypes]
drivers/gpu/drm/radeon/ci_smc.c:266:5: warning: no previous prototype for ‘ci_write_smc_sram_dword’ [-Wmissing-prototypes]
Signed-off-by: Rashika Kheria <rashika.kheria@gmail.com>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Move prototype declaration of function radeon_atom_copy_swap() to header
file drm/radeon/radeon_mode.h because it is used by more than one file.
This eliminates the following warnings in drm/radeon/atombios_dp.c:
drivers/gpu/drm/radeon/atombios_dp.c:53:6: warning: no previous prototype for ‘radeon_atom_copy_swap’ [-Wmissing-prototypes]
Signed-off-by: Rashika Kheria <rashika.kheria@gmail.com>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Include header file gpu/drm/radeon/sislands_smc.h in drm/radeon/si_smc.c
because it uses function declared in the header file.
Remove prototype declaration of function si_set_smc_sram_address() from
drm/radeon/sislands_smc.h because the function is used only in one file
where it is declared static already.
This eliminates the following warnings in drm/radeon/si_smc.c:
drivers/gpu/drm/radeon/si_smc.c:46:5: warning: no previous prototype for ‘si_copy_bytes_to_smc’ [-Wmissing-prototypes]
drivers/gpu/drm/radeon/si_smc.c:112:6: warning: no previous prototype for ‘si_start_smc’ [-Wmissing-prototypes]
drivers/gpu/drm/radeon/si_smc.c:121:6: warning: no previous prototype for ‘si_reset_smc’ [-Wmissing-prototypes]
drivers/gpu/drm/radeon/si_smc.c:135:5: warning: no previous prototype for ‘si_program_jump_on_start’ [-Wmissing-prototypes]
drivers/gpu/drm/radeon/si_smc.c:142:6: warning: no previous prototype for ‘si_stop_smc_clock’ [-Wmissing-prototypes]
drivers/gpu/drm/radeon/si_smc.c:151:6: warning: no previous prototype for ‘si_start_smc_clock’ [-Wmissing-prototypes]
drivers/gpu/drm/radeon/si_smc.c:160:6: warning: no previous prototype for ‘si_is_smc_running’ [-Wmissing-prototypes]
drivers/gpu/drm/radeon/si_smc.c:171:14: warning: no previous prototype for ‘si_send_msg_to_smc’ [-Wmissing-prototypes]
drivers/gpu/drm/radeon/si_smc.c:192:14: warning: no previous prototype for ‘si_wait_for_smc_inactive’ [-Wmissing-prototypes]
drivers/gpu/drm/radeon/si_smc.c:210:5: warning: no previous prototype for ‘si_load_smc_ucode’ [-Wmissing-prototypes]
drivers/gpu/drm/radeon/si_smc.c:269:5: warning: no previous prototype for ‘si_read_smc_sram_dword’ [-Wmissing-prototypes]
drivers/gpu/drm/radeon/si_smc.c:284:5: warning: no previous prototype for ‘si_write_smc_sram_dword’ [-Wmissing-prototypes]
Signed-off-by: Rashika Kheria <rashika.kheria@gmail.com>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Add static keyword to the definition of KMS_INVALID_IOCTL(name) in
radeon_kms.c because the functions passed to it as arguments are not
used anywhere else.
This eliminates the following warnings in drm/radeon/radeon_kms.c:
drivers/gpu/drm/radeon/radeon_kms.c:719:1: warning: no previous prototype for ‘radeon_cp_init_kms’ [-Wmissing-prototypes]
drivers/gpu/drm/radeon/radeon_kms.c:720:1: warning: no previous prototype for ‘radeon_cp_start_kms’ [-Wmissing-prototypes]
drivers/gpu/drm/radeon/radeon_kms.c:721:1: warning: no previous prototype for ‘radeon_cp_stop_kms’ [-Wmissing-prototypes]
drivers/gpu/drm/radeon/radeon_kms.c:722:1: warning: no previous prototype for ‘radeon_cp_reset_kms’ [-Wmissing-prototypes]
drivers/gpu/drm/radeon/radeon_kms.c:723:1: warning: no previous prototype for ‘radeon_cp_idle_kms’ [-Wmissing-prototypes]
drivers/gpu/drm/radeon/radeon_kms.c:724:1: warning: no previous prototype for ‘radeon_cp_resume_kms’ [-Wmissing-prototypes]
drivers/gpu/drm/radeon/radeon_kms.c:725:1: warning: no previous prototype for ‘radeon_engine_reset_kms’ [-Wmissing-prototypes]
drivers/gpu/drm/radeon/radeon_kms.c:726:1: warning: no previous prototype for ‘radeon_fullscreen_kms’ [-Wmissing-prototypes]
drivers/gpu/drm/radeon/radeon_kms.c:727:1: warning: no previous prototype for ‘radeon_cp_swap_kms’ [-Wmissing-prototypes]
drivers/gpu/drm/radeon/radeon_kms.c:728:1: warning: no previous rototype for ‘radeon_cp_clear_kms’ [-Wmissing-prototypes]
drivers/gpu/drm/radeon/radeon_kms.c:729:1: warning: no previous prototype for ‘radeon_cp_vertex_kms’ [-Wmissing-prototypes]
drivers/gpu/drm/radeon/radeon_kms.c:730:1: warning: no previous rototype for ‘radeon_cp_indices_kms’ [-Wmissing-prototypes]
drivers/gpu/drm/radeon/radeon_kms.c:731:1: warning: no previous prototype for ‘radeon_cp_texture_kms’ [-Wmissing-prototypes]
drivers/gpu/drm/radeon/radeon_kms.c:732:1: warning: no previous prototype for ‘radeon_cp_stipple_kms’ [-Wmissing-prototypes]
drivers/gpu/drm/radeon/radeon_kms.c:733:1: warning: no previous prototype for ‘radeon_cp_indirect_kms’ [-Wmissing-prototypes]
drivers/gpu/drm/radeon/radeon_kms.c:734:1: warning: no previous prototype for ‘radeon_cp_vertex2_kms’ [-Wmissing-prototypes]
drivers/gpu/drm/radeon/radeon_kms.c:735:1: warning: no previous prototype for ‘radeon_cp_cmdbuf_kms’ [-Wmissing-prototypes]
drivers/gpu/drm/radeon/radeon_kms.c:736:1: warning: no previous prototype for ‘radeon_cp_getparam_kms’ [-Wmissing-prototypes]
drivers/gpu/drm/radeon/radeon_kms.c:737:1: warning: no previous prototype for ‘radeon_cp_flip_kms’ [-Wmissing-prototypes]
drivers/gpu/drm/radeon/radeon_kms.c:738:1: warning: no previous prototype for ‘radeon_mem_alloc_kms’ [-Wmissing-prototypes]
drivers/gpu/drm/radeon/radeon_kms.c:739:1: warning: no previous prototype for ‘radeon_mem_free_kms’ [-Wmissing-prototypes]
drivers/gpu/drm/radeon/radeon_kms.c:740:1: warning: no previous rototype for ‘radeon_mem_init_heap_kms’ [-Wmissing-prototypes]
drivers/gpu/drm/radeon/radeon_kms.c:741:1: warning: no previous rototype for ‘radeon_irq_emit_kms’ [-Wmissing-prototypes]
drivers/gpu/drm/radeon/radeon_kms.c:742:1: warning: no previous prototype for ‘radeon_irq_wait_kms’ [-Wmissing-prototypes]
drivers/gpu/drm/radeon/radeon_kms.c:743:1: warning: no previous rototype for ‘radeon_cp_setparam_kms’ [-Wmissing-prototypes]
drivers/gpu/drm/radeon/radeon_kms.c:744:1: warning: no previous prototype for ‘radeon_surface_alloc_kms’ [-Wmissing-prototypes]
drivers/gpu/drm/radeon/radeon_kms.c:745:1: warning: no previous prototype for ‘radeon_surface_free_kms’ [-Wmissing-prototypes]
Signed-off-by: Rashika Kheria <rashika.kheria@gmail.com>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Mark function r600_audio_set_dto() as static in drm/radeon/r600_hdmi.c
because it is not used outside this file.
This eliminates the following warning in drm/radeon/r600_hdmi.c:
drivers/gpu/drm/radeon/r600_hdmi.c:253:6: warning: no previous prototype for ‘r600_audio_set_dto’ [-Wmissing-prototypes]
Signed-off-by: Rashika Kheria <rashika.kheria@gmail.com>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Mark function radeon_gem_set_domain() as static in
drm/radeon/radeon_gem.c because it is not used outside this file.
This eliminates the following warning in drm/radeon/radeon_gem.c:
drivers/gpu/drm/radeon/radeon_gem.c:89:5: warning: no previous prototype for ‘radeon_gem_set_domain’ [-Wmissing-prototypes]
Signed-off-by: Rashika Kheria <rashika.kheria@gmail.com>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Mark function radeon_info_ioctl() as static in drm/radeon/radeon_kms.c
because it is not used outside this file.
This eliminates the following warning in drm/radeon/radeon_kms.c:
drivers/gpu/drm/radeon/radeon_kms.c:194:5: warning: no previous prototype for ‘radeon_info_ioctl’ [-Wmissing-prototypes]
Signed-off-by: Rashika Kheria <rashika.kheria@gmail.com>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Mark functions radeon_doorbell_init() and radeon_doorbell_fini() as
static in drm/radeon/radeon_device.c because they are not used outside
this file.
This eliminates the following warning in drm/radeon/radeon_device.c:
drivers/gpu/drm/radeon/radeon_device.c:252:5: warning: no previous prototype for ‘radeon_doorbell_init’ [-Wmissing-prototypes]
drivers/gpu/drm/radeon/radeon_device.c:281:6: warning: no previous prototype for ‘radeon_doorbell_fini’ [-Wmissing-prototypes]
Signed-off-by: Rashika Kheria <rashika.kheria@gmail.com>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Mark function radeon_bo_clear_va() as static in
drm/radeon/radeon_object.c because it is not used outside this file.
This eliminates the following warning in drm/radeon/radeon_object.c:
drivers/gpu/drm/radeon/radeon_object.c:49:6: warning: no previous prototype for ‘radeon_bo_clear_va’ [-Wmissing-prototypes]
Signed-off-by: Rashika Kheria <rashika.kheria@gmail.com>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The hw i2c engines are disabled by default as the
current implementation is still experimental. Print
a warning when users enable it so that it's obvious
when the option is enabled.
v2: check for non-0 rather than 1
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Cc: stable@vger.kernel.org
We're iterating over the CPU transcoders, so check for the correct
power domain.
This fixes many "unclaimed register" error messages.
This can be reproduced by the IGT test mentioned below, but we still
get a FAIL when we run it.
Testcase: igt/kms_lip/flip-vs-panning-vs-hang
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In very rare cases (such as a memory failure stress test) it is possible
to fill the entire ring without emitting a request. Under this
circumstance, the outstanding request is flushed and waited upon. After
space on the ring is cleared, we return to emitting the new command -
except that we just cleared the seqno allocated for this operation and
trigger the sanity check that a request is only ever emitted with a
valid seqno. The fix is to rearrange the code to make sure the
allocation of the seqno for this operation is after any required flushes
of outstanding operations.
The bug exists since the preallocation was introduced in
commit 9d7730914f
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Tue Nov 27 16:22:52 2012 +0000
drm/i915: Preallocate next seqno before touching the ring
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Multiple definitions show up multiple times in modinfo output.
There's already an identical one in i915_drv.c along with other MODULE_*
definitions, so drop the lone one in intel_fbdev.c.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
DRM_HZ and DRM_WAKEUP macros are removed, but they still remained.
So this patch fixes build errors by replacing the macros.
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
This patch resolves potential deadlock issue that can be incurred
by changing file->f_op and filp->private_data to exynos specific
mapper ops and gem object temporarily.
To resolve this issue, this patch creates a new anon file dedicated
to exynos specific mmaper, and making it used instead of existing one.
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Without this fix the ioctls silently succeeded (but actually did
nothing).
It makes all the code which calls into this function way too confusing.
v2: Fix destroy IOCTL as well
v3: Clarify the other two callers of i915_gem_context_get() to never
check for NULL. (Mika)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=72903
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Testcase: igt/gem_ctx_exec/basic
[danvet: Fix up the commit message and actually bother to mention the
testcase this fixes.]
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The bug from gen6_ppgtt_insert_entries() was replicated into
gen8_ppgtt_insert_entries(). This applies the fix for the OOPS from the
previous patch to the gen8 routine.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Ben Widawsky <benjamin.widawsky@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The iommu and gfx on Ironlake do not like each other and require a
big hammer to prevent hard machine hangs. In
commit 5c0422878f
Author: Ben Widawsky <ben@bwidawsk.net>
Date: Mon Oct 17 15:51:55 2011 -0700
drm/i915: ILK + VT-d workaround
we added the workaround, but never emitted any debug message that it was
active. Doing so should help identify known performance regressions.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This fixes a hang in VBIOS scripts of the form "condition; jump".
The jump used to always be executed, while now it will only be
executed if the condition is true.
See https://bugs.freedesktop.org/show_bug.cgi?id=72943
Reported-by: Darcy Brás da Silva <dardevelin@cidadecool.com>
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: stable@vger.kernel.org
If the initial data element is 0, it will never be written, even
though the value from the previous method may be there.
Signed-off-by: Kelly Doran <kel.p.doran@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Mark function cdv_intel_fixed_panel_mode() as static in
drm/gma500/cdv_intel_dp.c because it is not used outside this file.
This eliminates the following warning in drm/gma500/cdv_intel_dp.c:
drivers/gpu/drm/gma500/cdv_intel_dp.c:680:6: warning: no previous prototype for ‘cdv_intel_fixed_panel_mode’ [-Wmissing-prototypes]
Signed-off-by: Rashika Kheria <rashika.kheria@gmail.com>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
My Acer 8510TZ stops displaying anything when X starts with Linus' current
tree. I bisected it down to commit ee1452d745.
This patch reverts commit ee1452d745.
After the revert, everything works as before.
Signed-off-by: Alexander van Heukelum <heukelum@fastmail.fm>
Reported-by: Dylan Borg <borgdylan@hotmail.com> (for a Acer Extensa 5635Z)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
gem_gtt_cpu_tlb seems to indicate that it is needed.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=72869
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Since get_pid_task() grabs a reference on the task_struct, we have to drop the
refcount after reading that task's comm name. Use pid_task() with RCU instead.
Also, avoid directly reading like pid_task()->comm because
pid_task() will return NULL if the task have already exit()ed.
This patch fixes both problems.
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
- VGA switcheroo was broken for some users as a result of the ACPI-based
PCI hotplug (ACPIPHP) changes in 3.12, because some previously ignored
hotplug events started to be handled. The fix causes them to be
ignored again.
- There are two more issues related to cpufreq's suspend/resume handling
changes from the 3.12 cycle addressed by Viresh Kumar's fixes.
- intel_pstate triggers a divide error in a timer function if the P-state
information it needs is missing during initialization. This leads to
kernel panics on nested KVM clients and is fixed by failing the
initialization cleanly in those cases.
- PCI initalization code changes during the 3.9 cycle uncovered BIOS
issues related to ACPI wakeup notifications (some BIOSes send them
for devices that aren't supposed to support ACPI wakeup). Work around
them by installing an ACPI wakeup notify handler for all PCI devices
with ACPI support.
- The Calxeda cpuilde driver's probe function is tagged as __init, which
is incorrect and causes a section mismatch to occur during build. Fix
from Andre Przywara removes the __init tag from there.
- During the 3.12 cycle ACPIPHP started to print warnings about missing
_ADR for devices that legitimately don't have it. Fix from Toshi Kani
makes it only print the warnings where they make sense.
/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iQIcBAABCAAGBQJSxrJgAAoJEILEb/54YlRxRPkP/ifzrrVhdzqXIEy44b93JeDx
oSmZW6yTO51GZlDx2bjt6CGJcIUDC4ExYV6S2tB44/DL19CYdIxi7oBaXtUvzGRs
oZ6B1wfvKOIxZ0RQguaGd1uerQU304CGwUXu/jpRZ/UuZZFKq5Uts6O3bilGzCfR
Y+MUH+qECwdBXaFHUISdWFsa3lxj0U0kglszh+DsxwS4gy/pLbCu5fKLgHLuNNQC
hhEEToQ6uF4o8hbkGJvgUPo3V3aUSXObgvJh4ntP09YE1AEJScLB4wKmqL0zN8Qj
pbBf1WC5OpGXv8zGM9ErrY64YaKA36uhJvOi6RtBGLbG+pYM6E6IM9zNf4Ku+T79
JNEulpq27aEx2JghNSgMFYQZEOGTH+q24iXZdZlOIvqWpMymATlqP/gAQQIpg3VC
OIIdocMFRsbgwFXf41uyUqs458fg5xREz5k6geWZeyriM45wFShR+JnMopQWc5OB
a3sbcWUShFBL1T0pqYR4SDLDvH4NdEP2NKO2jlqMXUewLXsVRRt/42etGoe0rI3C
cMWPQq7z0GNN+NboUviqwHdxUKqONWGt+pd/3u8FI/Y1IlXEeXQYGawhSu81uCpT
5gLaKDkwOrCSwOw68Msuod0Cce6TnoTowi6hP2aAEu8mDJwQY+toqA3+CPoO8nty
DdhZjP1afEgsVVyjErX4
=LXh0
-----END PGP SIGNATURE-----
Merge tag 'pm+acpi-3.13-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull ACPI and PM fixes and new device IDs from Rafael Wysocki:
"These commits, except for one, are regression fixes and the remaining
one fixes a divide error leading to a kernel panic. The majority of
the regressions fixed here were introduced during the 3.12 cycle, one
of them is from this cycle and one is older.
Specifics:
- VGA switcheroo was broken for some users as a result of the
ACPI-based PCI hotplug (ACPIPHP) changes in 3.12, because some
previously ignored hotplug events started to be handled. The fix
causes them to be ignored again.
- There are two more issues related to cpufreq's suspend/resume
handling changes from the 3.12 cycle addressed by Viresh Kumar's
fixes.
- intel_pstate triggers a divide error in a timer function if the
P-state information it needs is missing during initialization.
This leads to kernel panics on nested KVM clients and is fixed by
failing the initialization cleanly in those cases.
- PCI initalization code changes during the 3.9 cycle uncovered BIOS
issues related to ACPI wakeup notifications (some BIOSes send them
for devices that aren't supposed to support ACPI wakeup). Work
around them by installing an ACPI wakeup notify handler for all PCI
devices with ACPI support.
- The Calxeda cpuilde driver's probe function is tagged as __init,
which is incorrect and causes a section mismatch to occur during
build. Fix from Andre Przywara removes the __init tag from there.
- During the 3.12 cycle ACPIPHP started to print warnings about
missing _ADR for devices that legitimately don't have it. Fix from
Toshi Kani makes it only print the warnings where they make sense"
* tag 'pm+acpi-3.13-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
ACPIPHP / radeon / nouveau: Fix VGA switcheroo problem related to hotplug
intel_pstate: Fail initialization if P-state information is missing
ARM/cpuidle: remove __init tag from Calxeda cpuidle probe function
PCI / ACPI: Install wakeup notify handlers for all PCI devs with ACPI
cpufreq: preserve user_policy across suspend/resume
cpufreq: Clean up after a failing light-weight initialization
ACPI / PCI / hotplug: Avoid warning when _ADR not present
* acpi-pci-pm:
PCI / ACPI: Install wakeup notify handlers for all PCI devs with ACPI
* acpi-pci-hotplug:
ACPIPHP / radeon / nouveau: Fix VGA switcheroo problem related to hotplug
ACPI / PCI / hotplug: Avoid warning when _ADR not present
The changes in the ACPI-based PCI hotplug (ACPIPHP) subsystem made
during the 3.12 development cycle uncovered a problem with VGA
switcheroo that on some systems, when the device-specific method
(ATPX in the radeon case, _DSM in the nouveau case) is used to turn
off the discrete graphics, the BIOS generates ACPI hotplug events for
that device and those events cause ACPIPHP to attempt to remove the
device from the system (they are events for a device that was present
previously and is not present any more, so that's what should be done
according to the spec). Then, the system stops functioning correctly.
Since the hotplug events in question were simply silently ignored
previously, the least intrusive way to address that problem is to
make ACPIPHP ignore them again. For this purpose, introduce a new
ACPI device flag, no_hotplug, and modify ACPIPHP to ignore hotplug
events for PCI devices whose ACPI companions have that flag set.
Next, make the radeon and nouveau switcheroo detection code set the
no_hotplug flag for the discrete graphics' ACPI companion.
Fixes: bbd34fcdd1 (ACPI / hotplug / PCI: Register all devices under the given bridge)
References: https://bugzilla.kernel.org/show_bug.cgi?id=61891
References: https://bugzilla.kernel.org/show_bug.cgi?id=64891
Reported-and-tested-by: Mike Lothian <mike@fireburn.co.uk>
Reported-and-tested-by: <madcatx@atlas.cz>
Reported-and-tested-by: Joaquín Aramendía <samsagax@gmail.com>
Cc: Alex Deucher <alexdeucher@gmail.com>
Cc: Dave Airlie <airlied@linux.ie>
Cc: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: 3.12+ <stable@vger.kernel.org> # 3.12+
Fill in asic family specific versions rather than
using the generic version. This lets us handle asic
specific differences more easily. In this case, we
disable sw swapping of the rtpr writeback value on
r6xx+ since the hw does it for us. Fixes bogus
rptr readback on BE systems.
v2: remove missed cpu_to_le32(), add comments
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Enable coarse grained clockgating. This works properly now
that smc is initialized earlier than the rlc and cp.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Enable coarse grained clockgating on CIK dGPUs. This
works properly now that smc is initialized earlier than
the rlc and cp.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
We need more control over the ordering of dpm init with
respect to the rest of the asic. Specifically, the SMC
has to be initialized before the rlc and cg/pg. The pm
code currently initializes late in the driver, but we need
it to happen much earlier so move pm handling into the asic
specific callbacks.
This makes dpm more reliable and makes clockgating work
properly on CIK parts and should help on SI parts as well.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Right now it's called right after enable, but after
reworking the dpm init order, it will get called later
to accomodate loading the smc early, but enabling
thermal interrupts and block powergating later after
the ring tests are complete.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Make sure interrupts are enabled
before we enable thermal interrupts.
Also, don't powergate uvd, etc. until after
the ring tests.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Make sure interrupts are enabled
before we enable thermal interrupts.
Also, don't powergate uvd until after
the ring tests.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Need to wait to enable cg and pg until after
ring tests. Also make sure interrupts are enabled
before we enable thermal interrupts.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Need to wait to enable cg and pg until after
ring tests. Also make sure interrupts are enabled
before we enable thermal interrupts.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Certain features need to be enabled after ring tests
(e.g., powergating, etc.). Add a function pointer
to split out late enable features.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
We need to reorder the driver init sequence to better accomodate
dpm which needs to be loaded earlier in the init sequence. Move
fw init up so that it's available for dpm init.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Ville Syrjälä