It should already be masked and disabled and zeroed at the preinstall
and uninstall stages. Also, the current code just writes to IIR once,
and this is not a guarantee that it will be cleared, so it's wrong
anyway.
The whole reason for the paranoia is that we're going to start calling
the IRQ preinstall/postinstall/uninstall from the runtime PM
callbacks, so we need to make sure everything is behaving as expected.
v2: - Change the original DRM_ERROR to WARN and clear IIR in case it's
not zero (Ben).
- Improve commit message (Daniel).
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
And the equivalent GEN8_IRQ_INIT_NDX macro. These macros are for the
postinstall functions. The next patch will improve this macro.
v2: - Adjust to the new POSTING_READ scheme (Ben).
Reviewed-by: Ben Widawsky <ben@bwidawsk.net> (v1)
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The IRQ_INIT and IRQ_FINI macros are basically the same thing, with
the exception that IRQ_FINI doesn't properly clear IIR twice and
doesn't have as many POSTING_READs as IRQ_INIT. So rename the INIT
macro to IRQ_RESET and use it everywhere.
v2: - Fix error in the commit message (Chris).
- Adjust to the new POSTING_READ scheme (Ben).
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It's the only thing missing, apparently.
v2: - Fix typo (Ben).
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Same as the _INIT macro: the goal is to reuse the GEN8 macros, but
there are still some slight differences.
v2: - Rebase.
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
And rename it to GEN5_IRQ_INIT.
We have discussed doing equivalent changes on July 2013, and I even
sent a patch series for this: "[PATCH 00/15] Unify interrupt register
init/reset". Now that the BDW code was merged, I have one more
argument in favor of these changes.
Here's what really changes with the Gen 5 IRQ init code:
- We now clear the IIR registers at preinstall (they are also
cleared at postinstall, but we will change that later).
- We have an additional POSTING_READ at the IMR register.
v2: - Fix typo in commit message.
- Add POSTING_READ calls to the macros (Ben, Daniel, Jani).
Reviewed-by: Ben Widawsky <ben@bwidawsk.net> (v1)
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This interrupt gets initialized with a different IER value, so it was
not using the macro. The problem is that we plan to modify the macro
to make it do additional things, and we want the SDE interrupts
updated too. So let's make sure we call the macro, then, after it, we
do the necessary SDE-specific changes.
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The goal is to reuse the GEN8 macros, but a few changes are needed, so
let's make things easier to review.
I could also use these macros on older code, but since I plan to
change how the interrupts are initialized, we'll risk breaking the
older code in the next commits, so I'll leave this out for now.
v2: - Rebase.
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This patch reads the DRRS support and Mode type from VBT fields.
The read information will be stored in VBT struct during BIOS
parsing. The above functionality is needed for decision making
whether DRRS feature is supported in i915 driver for eDP panels.
This information helps us decide if seamless DRRS can be done
at runtime to support certain power saving features. This patch
was tested by setting necessary bit in VBT struct and merging
the new VBT with system BIOS so that we can read the value.
v2: Incorporated review comments from Chris Wilson
Removed "intel_" as a prefix for DRRS specific declarations.
v3: Incorporated Jani's review comments
Removed function which deducts drrs mode from panel_type. Modified some
print statements. Made changes to use DRRS_NOT_SUPPORTED as 0 instead of -1.
v4: Incorporated Jani's review comments.
Modifications around setting vbt drrs_type.
Signed-off-by: Pradeep Bhat <pradeep.bhat@intel.com>
Signed-off-by: Vandana Kannan <vandana.kannan@intel.com>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
[danvet: Drop the misleading/redundant comment about the added drrs
field in the vbt struct as discussed with Jani on irc.]
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Pull all the gmch platform hotplug interrupt handling into one
function.
v2: Move the IIR check to the caller
s/drm_i915_private_t/struct drm_i915_private/
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Add posting read comment suggested by Chris.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We have a need for duplicated parsing of the RP_STATE_CAPS register (and
the setting of the associated fields). To reuse some code, we can
extract the function into a simple helper.
This patch also addresses the fact that we missed doing this for gen8,
something we should have done anyway.
This could be two patches, one to extract, and one to add gen8, but it's
trivial enough that I think one is fine. I will accept a request to
split it. Please notice the fix addressed by v2 below.
Valleyview is left untouched because it is different.
v2: Logically rebased on top of
commit dd0a1aa19b
Author: Jeff McGee <jeff.mcgee@intel.com>
Date: Tue Feb 4 11:32:31 2014 -0600
drm/i915: Restore rps/rc6 on reset
Note with the above change the fix for gen8 is also handled (which was
not the case in Jeff's original patch).
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Programming it outside of the rp0-rp1 range is considered a programming
error. Since we do not know that the previous value would actually be in
the range, program something we've read from the hardware, and therefore
know will work.
This is potentially an issue for platforms whose ranges are outside the
norms given in the programming guide (ie. early silicon)
v2: Use RP1 instead of RPn
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Split the post_disable hooks for DP to g4x and vlv variants. We'll
need another variant soon, so this should make it look a bit cleaner.
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>
These were apparently meant to protect the SAREA which only has
room for two pipes, but things clearly went a bit wonky when
first the .update_plane() hooks were split up and then pipe C
got introduced.
The checks actually protecting the SAREA live in
intel_crtc_update_sarea() these days, so the checks in the primary
plane update hooks are just historical leftovers which are to be
eliminated.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Progess according to the deprecation plan laid out in
commit b30324adaf
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Wed Nov 13 22:11:25 2013 +0100
drm/i915: Deprecated UMS support
and disable UMS for 3.16. Note that it has been over 5 years since the
last UMS-supporting piece of userspace was released.
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
There are no longer users of drm_i915_private_t. Drop the typedef. Good
riddance.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Chris Wilson <chris@chris-wislon.co.uk>
[danvet: Add the hunk in i915_cmd_parser.c here which had to be
relocated to the how this was merged.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The reg_read whitelist has a gen bitmask to code the gens we're allowing
the register to be read on. Until now, it was a literal, but we can be
a bit more expressive.
To ease the review, a small test program:
$ cat bit-range.c
#include <stdio.h>
#include <stdint.h>
#define U32_C(x) x ## U
#define GENMASK(h, l) (((U32_C(1) << ((h) - (l) + 1)) - 1) << (l))
#define GEN_RANGE(l, h) GENMASK(h, l)
int main(int argc, char **argv)
{
printf("0x%08x\n", GEN_RANGE(1, 1));
printf("0x%08x\n", GEN_RANGE(1, 2));
printf("0x%08x\n", GEN_RANGE(4, 4));
printf("0x%08x\n", GEN_RANGE(4, 5));
printf("0x%08x\n", GEN_RANGE(1, 31));
printf("0x%08x\n", GEN_RANGE(4, 8));
return 0;
}
$ ./bit-range
0x00000002
0x00000006
0x00000010
0x00000030
0xfffffffe
0x000001f0
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>
Let's change the i915_cur_delayinfo to i915_frequency_info to be in sync
with new RPS naming convention.
v2: Add "i915_frequency_info" as debugfs interface name (Ben)
Signed-off-by: Deepak S <deepak.s@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
These defines are only used in intel_uncore.c.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
That function isn't used outside this file anymore.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
DRM_DEBUG_KMS includes printing the function name.
Signed-off-by: Christoph Jaeger <christophjaeger@linux.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Those values are, global, only used in one function and already stored
in mode_config.cursor_{width,height}.
As a result, this initialization code has been moved from the
crtc_init() function to the global modeset_init() one.
I also renamed CURSOR_{WIDTH,HEIGHT} to MAX_CURSOR_{WIDTH,HEIGHT} to be
more accurate about what these value really are.
Cc: Sagar Kamble <sagar.a.kamble@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Besides D0 device state we need the proper power wells to be on on
some platforms, so get the port power domain reference instead of an RPM
reference.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Antti Koskipää <antti.koskipaa@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Instead of reading out the CD clock rate from the HW at each modeset, do
this only during driver init and resume and use the cached value during
modeset. This moves things towards a state where the sw and hw side
setup is separated. It's also needed for VLV RPM, where we don't put
device into D0 state until modeset_global_resources is called and thus
can't access any display/gfx registers.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Antti Koskipää <antti.koskipaa@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When trying to determine whether RPS is working as intended, more
information is better. In particular, what interrupts are being
generated and the various thresholds for generating them.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Deepak S <deepak.s@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Mesa needs to be able to write OACONTROL in order to expose the
Observability Architecture's performance counters via OpenGL.
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
[danvet: Add comment that this is just a temporary work-around and
that we need to check more things before we can allow OACONTROL writes
for real everywhere.]
[danvet 2: Squash in fixup to avoid a DRM_ERROR due to unsorted reg
list, spotted by Jani.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
So userspace can query the kernel for command parser support.
v2: Add i915_cmd_parser_get_version(), history log, and kerneldoc
OTC-Tracker: AXIA-4631
Change-Id: I58af650db9f6753c2dcac9c54ab432fd31db302f
Signed-off-by: Brad Volkin <bradley.d.volkin@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
PIPE_CONTROL and MI_FLUSH_DW have bits that would write to the
hardware status page. The driver stores request tracking info
there, so don't let userspace overwrite it.
v2: trailing comma fix, rebased
Signed-off-by: Brad Volkin <bradley.d.volkin@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Various commands that access memory have a bit to determine whether
the graphics address specified in the command should use the GGTT or
PPGTT for translation. These checks ensure that the bit indicates
PPGTT translation.
Most of these checks use the existing bit-checking infrastructure.
The PIPE_CONTROL and MI_FLUSH_DW commands, however, are multi-function
commands. The GGTT/PPGTT bit is only relevant for certain uses of the
command. As such, this change also extends the bit-checking code to
include a "condition" mask and offset. If the condition mask is non-zero
then the parser only performs the bit check when the bits specified by
the condition mask/offset are also non-zero.
NOTE: At this point in the series PPGTT must be enabled for the parser
to work correctly. If it's not enabled, userspace will not be setting
the PPGTT bits the way the parser requires. VLV is the only platform
where this is a problem, so at this point, we disable parsing for VLV.
v2: whitespace and trailing commas fixes, rebased
OTC-Tracker: AXIA-4631
Change-Id: I3f4c76b6734f1956ec47e698230f97d0998ff92b
Signed-off-by: Brad Volkin <bradley.d.volkin@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
[danvet: Drop the unecessary cast Jani spotted.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The driver leaves most interrupts masked during normal operation,
so there would have to be additional work to enable userspace to
safely request/receive an interrupt.
v2: trailing commas, rebased
Signed-off-by: Brad Volkin <bradley.d.volkin@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
MI_STORE_REGISTER_MEM, MI_LOAD_REGISTER_MEM, and MI_LOAD_REGISTER_IMM
commands allow userspace access to registers. Only certain registers
should be allowed for such access, so enable checking for those commands.
Each ring gets its own register whitelist.
MI_LOAD_REGISTER_REG on HSW also allows register access but is currently
unused by userspace components. Leave it rejected.
PIPE_CONTROL and MEDIA_VFE_STATE allow register access based on certain
bits being set. Reject those as well.
v2: trailing commas, rebased
OTC-Tracker: AXIA-4631
Change-Id: Ie614a2f0eb2e5917de809e5a17957175d24cc44f
Signed-off-by: Brad Volkin <bradley.d.volkin@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
These are used to implement scanline waits in the X server.
v2: Use #defines instead of magic numbers
Signed-off-by: Brad Volkin <bradley.d.volkin@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
These registers are currently used by mesa for blitting,
transform feedback extensions, and performance monitoring
extensions.
v2: REG64 macro
Signed-off-by: Brad Volkin <bradley.d.volkin@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The Intel DDX uses these to implement scanline waits in the X server.
Signed-off-by: Brad Volkin <bradley.d.volkin@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The spec defines most of these commands as privileged. A few others,
like the semaphore mbox command and some display commands, are also
reserved for the driver's use. Subsequent patches relax some of
these restrictions.
v2: Rebased
Signed-off-by: Brad Volkin <bradley.d.volkin@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Add command tables defining irregular length commands for each ring.
This requires a few new command opcode definitions.
v2: Whitespace adjustment in command definitions, sparse fix for !F
OTC-Tracker: AXIA-4631
Change-Id: I064bceb457e15f46928058352afe76d918c58ef5
Signed-off-by: Brad Volkin <bradley.d.volkin@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When PPGTT was disabled by default, the patch also prevented the user
from overriding this behavior via module parameter. Being able to test
this on arbitrary kernels is extremely beneficial to track down the
remaining bugs. The patch that prevented this was:
commit 93a25a9e2d
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Thu Mar 6 09:40:43 2014 +0100
drm/i915: Disable full ppgtt by default
By default PPGTT is set to -1. 0 means off, 1 means aliasing only, 2
means full, all other values are reserved.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This file contains all necessary defines, prototypes and typesdefs for
manipulating GEN graphics address translation (this does not include the
legacy AGP driver)
Reiterating the comment in the header,
"Please try to maintain the following order within this file unless it
makes sense to do otherwise. From top to bottom:
1. typedefs
2. #defines, and macros
3. structure definitions
4. function prototypes
Within each section, please try to order by generation in ascending
order, from top to bottom (ie. GEN6 on the top, GEN8 on the bottom)."
I've made some minor cleanups, and fixed a couple of typos while here -
but there should be no functional changes.
The purpose of the patch is to reduce clutter in our main header file,
making room for new growth, and make documentation of our interfaces
easier by splitting things out.
With a little more work, like making i915_gtt a pointer, we could
potentially completely isolate this header from i915_drv.h. At the
moment however, I don't think it's worth the effort.
Personally, I would have liked to put the PTE encoding functions in this
file too, but I didn't want to rock the boat too much.
A similar patch has been in use on my machine for some time. This exact
patch though has only been compile tested.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Extract all this logic into a new helper function
semaphore_wait_to_signaller_ring because:
- The current code has way too much magic.
- The current code doesn't look at bi16, which encodes VECS signallers
on HSW. Those are just added after the fact, so can't be encoded in
a neat formula.
- The current logic can't blow up since it limits its value range
sufficiently, but that's a bit too tricky to rely on in my opinion.
Especially when we start to add bdw support.
- I'm not a big fan of the explicit ring->semaphore_register list, but
I think it's more robust to use the same mapping both when
constructing the semaphore commands and when decoding them.
- Finally add a FIXME comment about lack of broadwell support here,
like in the earlier ipehr semaphore cmd detection function.
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Ben Widawsky <ben@bwidawsk.net>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
[danvet: Actually drop the untrue claim in the commit message Chris
pointed out.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Currently not an issue since we don't emit sempahores, but better
not forget about those.
As a little prep work extract the ipehr decoding for cleaner control
flow. And apply a bit of polish.
Cc: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The documentation calls this GFX_MODE bit "Flush TLB invalidate Mode".
However, that is not a good name for an enable bit as it doesn't make it
clear what is enabled. An even worse name is GFX_TLB_INVALIDATE_ALWAYS
as enabling that bit actually prevents the TLB from being invalidated at
every flush. This leads to great confusion when reading code and
proposed patches. To get around this try to bake in what is enabled by
setting the bit and call it GFX_TLB_INVALIDATE_EXPLICIT.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: "Gupta, Sourab" <sourab.gupta@intel.com>
Acked-by: "Gupta, Sourab" <sourab.gupta@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Because gen6_gt_force_wake_{get,put} should already be responsible for
getting/putting runtime PM. If we keep these calls, debugfs will not
be testing the get/put calls of the forcewake functions.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If runtime PM is enabled and we unset all modes, we will runtime
suspend after __intel_set_mode() , then function
intel_modeset_check_state() will try to read the HW state while it is
suspended and trigger lots of WARNs because it shouldn't be reading
registers.
So on this patch we make intel_ddi_connector_get_hw_state() return
false in case the power domain is disabled, and we also make
intel_display_power_enabled() return false in case the device is
suspended. Notice that we can't just use
intel_display_power_enabled_sw() because while the driver is being
initialized the power domain refcounts are not reflecting the real
state of the hardware.
Just for reference, I have previously published an alternate patch for
this problem, called "drm/i915: get runtime PM at intel_set_mode".
Testcase: igt/pm_pc8
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
At i915_display_info, don't call cursor_position() for a disabled
CRTC, since the CRTC may be on a powered down pipe, and this will
cause "Unclaimed register before interrupt" error messages.
Testcase: igt/pm_pc8/debugfs-read
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Otherwise we may get some WARNs complaining that we're reading a
register while we're suspended.
Testcase: igt/pm_pc8/debugfs-read
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
To avoid WARNs when we call it.
Testcase: igt/pm_pc8/reg-read-ioctl
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75693
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
So far force_wake_timer was only used by gen6_gt_force_wake_put. Since
we always had balanced gen6_gt_force_wake_get/put calls, we could
guarantee balanced calls to intel_runtime_pm_get/put.
Commit 8232644ccf, "drm/i915: Convert
the forcewake worker into a timer func" started scheduling the
force_wake_timer at gen6_read, which resulted in an unbalanced
runtime_pm refcount.
So this commit just reverts to the old behavior until we can find a
proper way to used delayed force_wake from the register read/write
macros without leaving the runtime_pm refcounts unbalanced and without
runtime suspending the driver while forcewake is active.
Testcase: igt/pm_pc8/rte
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76544
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Atm we reserve/allocate and free the power context during GT power
enable/disable time. There is no need to do this, we can reserve/allocate
the buffer once during driver loading and free it during driver cleanup.
The re-reservation can also fail in case the driver previously manages to
allocate something on the given fixed address.
The buffer isn't exepected to move even if allocated by the BIOS, for
safety add an assert to check this assumption.
This also fixed a bug for Ville, where re-reserving the context failed
during a GPU reset (I assume because something else got allocated on its
fixed address).
Tested-by: Ville Syrjälä <ville.syrjala@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>
- Device PM QoS support for latency tolerance constraints on systems with
hardware interfaces allowing such constraints to be specified. That is
necessary to prevent hardware-driven power management from becoming
overly aggressive on some systems and to prevent power management
features leading to excessive latencies from being used in some cases.
- Consolidation of the handling of ACPI hotplug notifications for device
objects. This causes all device hotplug notifications to go through
the root notify handler (that was executed for all of them anyway
before) that propagates them to individual subsystems, if necessary,
by executing callbacks provided by those subsystems (those callbacks
are associated with struct acpi_device objects during device
enumeration). As a result, the code in question becomes both smaller
in size and more straightforward and all of those changes should not
affect users.
- ACPICA update, including fixes related to the handling of _PRT in cases
when it is broken and the addition of "Windows 2013" to the list of
supported "features" for _OSI (which is necessary to support systems
that work incorrectly or don't even boot without it). Changes from
Bob Moore and Lv Zheng.
- Consolidation of ACPI _OST handling from Jiang Liu.
- ACPI battery and AC fixes allowing unusual system configurations to
be handled by that code from Alexander Mezin.
- New device IDs for the ACPI LPSS driver from Chiau Ee Chew.
- ACPI fan and thermal optimizations related to system suspend and resume
from Aaron Lu.
- Cleanups related to ACPI video from Jean Delvare.
- Assorted ACPI fixes and cleanups from Al Stone, Hanjun Guo, Lan Tianyu,
Paul Bolle, Tomasz Nowicki.
- Intel RAPL (Running Average Power Limits) driver cleanups from Jacob Pan.
- intel_pstate fixes and cleanups from Dirk Brandewie.
- cpufreq fixes related to system suspend/resume handling from Viresh Kumar.
- cpufreq core fixes and cleanups from Viresh Kumar, Stratos Karafotis,
Saravana Kannan, Rashika Kheria, Joe Perches.
- cpufreq drivers updates from Viresh Kumar, Zhuoyu Zhang, Rob Herring.
- cpuidle fixes related to the menu governor from Tuukka Tikkanen.
- cpuidle fix related to coupled CPUs handling from Paul Burton.
- Asynchronous execution of all device suspend and resume callbacks,
except for ->prepare and ->complete, during system suspend and resume
from Chuansheng Liu.
- Delayed resuming of runtime-suspended devices during system suspend for
the PCI bus type and ACPI PM domain.
- New set of PM helper routines to allow device runtime PM callbacks to
be used during system suspend and resume more easily from Ulf Hansson.
- Assorted fixes and cleanups in the PM core from Geert Uytterhoeven,
Prabhakar Lad, Philipp Zabel, Rashika Kheria, Sebastian Capella.
- devfreq fix from Saravana Kannan.
/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAABCAAGBQJTLgB1AAoJEILEb/54YlRxfs4P/35fIu9h8ClNWUPXqi3nlGIt
yMyumKvF1VdsOKLbjTtFq6B3UOlhqDijYTCQd7Xt7X8ONTk/ND9ec2t/5xGkSdUI
q46fa0qZXeqUn0Kt2t+kl6tgVQOkDj94aNlEh+7Ya3Uu6WYDDfmZtOBOFAMk6D8l
ND4rHJpX+eUsRLBrcxaUxxdD8AW5guGcPKyeyzsXv1bY1BZnpLFrZ3PhuI5dn2CL
L/zmk3A+wG6+ZlQxnwDdrKa3E6uhRSIDeF0vI4Byspa1wi5zXknJG2J7MoQ9JEE9
VQpBXlqach5wgXqJ8PAqAeaB6Ie26/F7PYG8r446zKw/5UUtdNUx+0dkjQ7Mz8Tu
ajuVxfwrrPhZeQqmVBxlH5Gg7Ez2KBKEfDxTdRnzI7FoA7PE5XDcg3kO64bhj8LJ
yugnV/ToU9wMztZnPC7CoGPwUgxMJvr9LwmxS4aeKcVUBES05eg0vS3lwdZMgqkV
iO0QkWTmhZ952qZCqZxbh0JqaaX8Wgx2kpX2tf1G2GJqLMZco289bLh6njNT+8CH
EzdQKYYyn6G6+Qg2M0f/6So3qU17x9XtE4ZBWQdGDpqYOGZhjZAOs/VnB1Ysw/K3
cDBzswlJd0CyyUps9B+qbf49OpbWVwl5kKeuHUuPxugEVryhpSp9AuG+tNil74Sj
JuGTGR4fyFjDBX5cvAPm
=ywR6
-----END PGP SIGNATURE-----
Merge tag 'pm+acpi-3.15-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull ACPI and power management updates from Rafael Wysocki:
"The majority of this material spent some time in linux-next, some of
it even several weeks. There are a few relatively fresh commits in
it, but they are mostly fixes and simple cleanups.
ACPI took the lead this time, both in terms of the number of commits
and the number of modified lines of code, cpufreq follows and there
are a few changes in the PM core and in cpuidle too.
A new feature that already got some LWN.net's attention is the device
PM QoS extension allowing latency tolerance requirements to be
propagated from leaf devices to their ancestors with hardware
interfaces for specifying latency tolerance. That should help systems
with hardware-driven power management to avoid going too far with it
in cases when there are latency tolerance constraints.
There also are some significant changes in the ACPI core related to
the way in which hotplug notifications are handled. They affect PCI
hotplug (ACPIPHP) and the ACPI dock station code too. The bottom line
is that all those notification now go through the root notify handler
and are propagated to the interested subsystems by means of callbacks
instead of having to install a notify handler for each device object
that we can potentially get hotplug notifications for.
In addition to that ACPICA will now advertise "Windows 2013"
compatibility for _OSI, because some systems out there don't work
correctly if that is not done (some of them don't even boot).
On the system suspend side of things, all of the device suspend and
resume callbacks, except for ->prepare() and ->complete(), are now
going to be executed asynchronously as that turns out to speed up
system suspend and resume on some platforms quite significantly and we
have a few more optimizations in that area.
Apart from that, there are some new device IDs and fixes and cleanups
all over. In particular, the system suspend and resume handling by
cpufreq should be improved and the cpuidle menu governor should be a
bit more robust now.
Specifics:
- Device PM QoS support for latency tolerance constraints on systems
with hardware interfaces allowing such constraints to be specified.
That is necessary to prevent hardware-driven power management from
becoming overly aggressive on some systems and to prevent power
management features leading to excessive latencies from being used
in some cases.
- Consolidation of the handling of ACPI hotplug notifications for
device objects. This causes all device hotplug notifications to go
through the root notify handler (that was executed for all of them
anyway before) that propagates them to individual subsystems, if
necessary, by executing callbacks provided by those subsystems
(those callbacks are associated with struct acpi_device objects
during device enumeration). As a result, the code in question
becomes both smaller in size and more straightforward and all of
those changes should not affect users.
- ACPICA update, including fixes related to the handling of _PRT in
cases when it is broken and the addition of "Windows 2013" to the
list of supported "features" for _OSI (which is necessary to
support systems that work incorrectly or don't even boot without
it). Changes from Bob Moore and Lv Zheng.
- Consolidation of ACPI _OST handling from Jiang Liu.
- ACPI battery and AC fixes allowing unusual system configurations to
be handled by that code from Alexander Mezin.
- New device IDs for the ACPI LPSS driver from Chiau Ee Chew.
- ACPI fan and thermal optimizations related to system suspend and
resume from Aaron Lu.
- Cleanups related to ACPI video from Jean Delvare.
- Assorted ACPI fixes and cleanups from Al Stone, Hanjun Guo, Lan
Tianyu, Paul Bolle, Tomasz Nowicki.
- Intel RAPL (Running Average Power Limits) driver cleanups from
Jacob Pan.
- intel_pstate fixes and cleanups from Dirk Brandewie.
- cpufreq fixes related to system suspend/resume handling from Viresh
Kumar.
- cpufreq core fixes and cleanups from Viresh Kumar, Stratos
Karafotis, Saravana Kannan, Rashika Kheria, Joe Perches.
- cpufreq drivers updates from Viresh Kumar, Zhuoyu Zhang, Rob
Herring.
- cpuidle fixes related to the menu governor from Tuukka Tikkanen.
- cpuidle fix related to coupled CPUs handling from Paul Burton.
- Asynchronous execution of all device suspend and resume callbacks,
except for ->prepare and ->complete, during system suspend and
resume from Chuansheng Liu.
- Delayed resuming of runtime-suspended devices during system suspend
for the PCI bus type and ACPI PM domain.
- New set of PM helper routines to allow device runtime PM callbacks
to be used during system suspend and resume more easily from Ulf
Hansson.
- Assorted fixes and cleanups in the PM core from Geert Uytterhoeven,
Prabhakar Lad, Philipp Zabel, Rashika Kheria, Sebastian Capella.
- devfreq fix from Saravana Kannan"
* tag 'pm+acpi-3.15-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (162 commits)
PM / devfreq: Rewrite devfreq_update_status() to fix multiple bugs
PM / sleep: Correct whitespace errors in <linux/pm.h>
intel_pstate: Set core to min P state during core offline
cpufreq: Add stop CPU callback to cpufreq_driver interface
cpufreq: Remove unnecessary braces
cpufreq: Fix checkpatch errors and warnings
cpufreq: powerpc: add cpufreq transition latency for FSL e500mc SoCs
MAINTAINERS: Reorder maintainer addresses for PM and ACPI
PM / Runtime: Update runtime_idle() documentation for return value meaning
video / output: Drop display output class support
fujitsu-laptop: Drop unneeded include
acer-wmi: Stop selecting VIDEO_OUTPUT_CONTROL
ACPI / gpu / drm: Stop selecting VIDEO_OUTPUT_CONTROL
ACPI / video: fix ACPI_VIDEO dependencies
cpufreq: remove unused notifier: CPUFREQ_{SUSPENDCHANGE|RESUMECHANGE}
cpufreq: Do not allow ->setpolicy drivers to provide ->target
cpufreq: arm_big_little: set 'physical_cluster' for each CPU
cpufreq: arm_big_little: make vexpress driver depend on bL core driver
ACPI / button: Add ACPI Button event via netlink routine
ACPI: Remove duplicate definitions of PREFIX
...
Remove the rest of the references to drm_i915_private_t. No functional
changes.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
[danvet: Drop hunk in i915_cmd_parser.c]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Also drop any unnecessary casts. No functional changes.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Also drop any unnecessary casts. No functional changes.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The speculation is that we can conserve more power by masking off
the interrupts at source (PMINTRMSK) rather than filtering them by the
up/down thresholds (RPINTLIM). We can select which events we know will
be active based on the current frequency versus our imposed range, i.e.
if at minimum, we know we will not want to generate any more
down-interrupts and vice versa.
v2: We only need the TIMEOUT when above min frequency.
v3: Tweak VLV at the same time
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Deepak S <deepak.s@linux.intel.com>
Reviewed-by:Deepak S <deepak.s@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
What used to be a short-circuit now needs to adjust interrupt masking in
response to user requests for changing the min/max allowed frequencies.
This is currently done by a special case and early return, but the next
patch adds another common action to take, so refactor the code to reduce
duplication.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by:Deepak S <deepak.s@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This reverts commit 2754436913.
Conflicts:
drivers/gpu/drm/i915/i915_irq.c
The partial application of interrupt masking without regard to other
pathways for adjusting the RPS frequency results in completely disabling
the PM interrupts. This leads to excessive power consumption as the GPU
is kept at max clocks (until the failsafe mechanism fires of explicitly
downclocking the GPU when all requests are idle). Or equally as bad for
the UX, the GPU is kept at minimum clocks and prevented from upclocking
in response to a requirement for more power.
Testcase: pm_rps/blocking
Cc: Deepak S <deepak.s@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by:Deepak S <deepak.s@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If vsyncshift comes out as negative, add one htotal to it to get the
corresponding positive value.
This is rather theoretical as it would require a mode where the
hsync+back porch is very long and the active+front porch very short.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
PIPECONF_INTERLACE_W_FIELD_INDICATION is only meant to be used for sdvo
since it implies a slightly weird vsync shift of htotal/2. For everything
else we should use PIPECONF_INTERLACE_W_SYNC_SHIFT and let the value in
the VSYNCSHIFT register take effect.
The only exception is gen3 simply because VSYNCSHIFT didn't exist yet.
Gen2 doesn't support interlaced modes at all, so we can drop the
explicit gen2 checks.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When interlaced sdvo output is used, vsyncshift should supposedly
be (htotal-1)/2. In reality PIPECONF/TRANSCONF will override it by
using the legacy vsyncshift interlace mode which causes the hardware
to ignore the VSYNCSHIFT register.
The only odd thing here is that on PCH platforms we program the
VSYNCSHIFT on both CPU and PCH, and it's not entirely clear if both
sides have to agree on the value or not. On the CPU side there's no
way to override the value via PIPECONF anymore, so if we want to make
the CPU side agree with the PCH side, we should probably program the
approriate value into VSYNCSHIFT manually. So let's do that, but for
now leave the PCH side to still use the legacy interlace mode in
TRANSCONF.
We can also drop the gen2 check since gen2 doesn't support interlaced
modes at all.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This makes HDMI testers happier on VLV platforms. It may be that we
need it for any non-SVO platform, but I don't have any tests to back
that up, so I'm leaving other pre-ILK platforms alone for now.
Tested-by: "Clint Taylor <clinton.a.taylor@intel.com>"
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74964
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We want future generations to at least attempt to use all features, so
restrict the stolen memory disabling when vt-d is enabled to the
latest generation we have reports for. Which is a HSW per the original
report.
Also once we get a bit a hold of some of the mysterious framebuffer in
stolen memory issues that still haunt bugzilla, we should probably
drop this hack again and see what happens.
This was introduced in
commit 0f4706d274
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Tue Mar 18 14:50:50 2014 +0200
drm/i915: Disable stolen memory when DMAR is active
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: David Woodhouse <dwmw2@infradead.org>
References: https://bugs.freedesktop.org/show_bug.cgi?id=68535
Acked-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJTOOOnAAoJEHm+PkMAQRiGsBAH/2PAOL3TbOG6tEedxQrTwsr2
muRIRTVWawjT8/npbHupxGnAyAVdmdffBHpmCmcftKdKNryT3YZW8/JWoYc+WSlo
3vTDJHDOYAe6yCBjjhYwcu150THBQdOymOi5mbbclo0XWYG18jd3+abYprRH6SiD
XqNSzYqoiv91JHBAWKBIpo1cyRDuwoM7+jZ7gX41r2800EL7loY3e08cPDDNU6HA
CKaLXMwLwYTefE+Wnr+4UUr08NbNBbBUKLUSXVqKKIpd+MtbyhV1SnWzz8VQSkag
K/uzsnGnE7nrqoepMSx3nXxzOWxUSY2EMbwhEjaKK4xBq9C9pzv3sG/o2/IyopU=
=Nuom
-----END PGP SIGNATURE-----
Merge tag 'v3.14' into drm-intel-next-queued
Linux 3.14
The vt-d w/a merged late in 3.14-rc needs a bit of fine-tuning, hence
backmerge.
Conflicts:
drivers/gpu/drm/i915/i915_gem_gtt.c
drivers/gpu/drm/i915/intel_ddi.c
drivers/gpu/drm/i915/intel_dp.c
All trivial adjacent lines changed type conflicts, so trivial git
doesn't even show them in the merg commit.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This is *not* bisected, but the likely regression is
commit c35614380d
Author: Zhao Yakui <yakui.zhao@intel.com>
Date: Tue Nov 24 09:48:48 2009 +0800
drm/i915: Don't set up the TV port if it isn't in the BIOS table.
The commit does not check for all TV device types that might be present
in the VBT, disabling TV out for the missing ones. Add composite
S-video.
Reported-and-tested-by: Matthew Khouzam <matthew.khouzam@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73362
Cc: stable@vger.kernel.org
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Broadwell introduces large address spaces, greater than 32bits in width.
These require that we then store and print 64bit values. If we were to
zero pad them out to 16 hexadecimal places, we have to carefully count
the leading zeroes - which is easy to make a mistake. Conversely, if we
do not zero pad out to 16, but keep it padding to 8 hexadecimal places,
it is very easy to miss an address that is actually larger than 4GiB. A
suggested compromise is to insert a space between the upper and lower
dwords of the address so that we can continue with our accustom 32bit
parser. (Alternatively, we could do the equivalent in our userspace
decoder.)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
As Broadwell has an increased virtual address size, it requires more
than 32 bits to store offsets into its address space. This includes the
debug registers to track the current HEAD of the individual rings, which
may be anywhere within the per-process address spaces. In order to find
the full location, we need to read the high bits from a second register.
We then also need to expand our storage to keep track of the larger
address.
v2: Carefully read the two registers to catch wraparound between
the reads.
v3: Use a WARN_ON rather than loop indefinitely on an unstable
register read.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ben Widawsky <benjamin.widawsky@intel.com>
Cc: Timo Aaltonen <tjaalton@ubuntu.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Drop spurious hunk which conflicted.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Not implementing this W/A can lead to hangs.
Cc: Ben Widawsky <benjamin.widawsky@intel.com>
Cc: Rafael Barbalho <rafael.barbalho@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It apparently blows up on some machines. This functionally reverts
commit 828c79087c
Author: Ben Widawsky <benjamin.widawsky@intel.com>
Date: Wed Oct 16 09:21:30 2013 -0700
drm/i915: Disable GGTT PTEs on GEN6+ suspend
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=64841
Reported-and-Tested-by: Brad Jackson <bjackson0971@gmail.com>
Cc: stable@vger.kernel.org
Cc: Takashi Iwai <tiwai@suse.de>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Todd Previte <tprevite@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
If the cursor width is changed, we may need to recompute our WM to
prevent untold flickering. We hope that the registers are flushed on the
same vblank to prevent underruns...
Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: Sagar Kamble <sagar.a.kamble@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Now that we can use different cursor size, we can not hardcode 64 pixels
as the cursor width anymore.
v2: Apply to 965gm/g4x paths as well
Cc: Damien Lespiau <damien.lespiau@intel.com>
Cc: Sagar Kamble <sagar.a.kamble@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This patch Removes the VS_TIMER_DISPATCH bit enable in MI MODE reg for
platforms > Gen6.
VS_TIMER_DISPATCH bit enable was earlier required as a part of
WA 'WaTimedSingleVertexDispatch', which is now applicable only to
platforms < Gen7.
v2: Enhancing the scope of the patch to full Gen7 (Chris)
v3: Modifying the WA condition to the cover the applicable platforms,
and adding the WA name in comments. (Ville)
Signed-off-by: Akash Goel <akash.goel@intel.com>
Signed-off-by: Sourab Gupta <sourab.gupta@intel.com>
Tested-by: Chris Wilson <chris@chris-wilson.co.uk> # ivb, hsw -Chris
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When we use different rps events for different platforms or due to wa,
we might end up needing this logic in a lot of places. Instead of
this let's use a variable in dev_priv to track the enabled PM
interrupts.
v2: Initialize pm_rps_events in intel_irq_init() (Ville).
Signed-off-by: Deepak S <deepak.s@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
[danvet: Frob the commit message a bit since the English was a bit too
garbled ;-) ]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Since
commit 5c673b60a9
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Fri Mar 7 20:34:46 2014 +0100
drm/i915: Don't enable display error interrupts from the start
we don't enable underrun interrupts any more at takeover time.
Unfortunately I've forgotten to also adjust the sw-side tracking.
Since the code assumes that disabled pipes have underrun reporting
enabled set the disable flag only on all pipes which are active at
takeover time. Without this underrun reporting wasn't enabled
correctly on the first modeset. Note that for fastboot this is another
piece of state that needs to be fixed up by enabling the underrung
reporting after watermarks have beend fixed up.
On ivb/hsw an additional effect of this regression was that also all
cpu crc reporting stopped working since the master error interrupt it
shared across all pipes and sources.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76150
[danvet: Augment the code comment and polish the commit message a bit,
as discussed with Jani.]
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Tested-by: lu hua <huax.lu@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
There's an entire pile of issues in here:
- Use the main RING_HEAD register, not ACTHD. ACTHD points at the gtt
offset of the batch buffer when a batch is executed. Semaphores are
always emitted to the main ring, so we always want to look at that.
- Mask the obtained HEAD pointer with the actual ring size, which is
much smaller. Together with the above issue this resulted us in
trying to dereference a pointer way outside of the ring mmio
mapping. The resulting invalid access in interrupt context
(hangcheck is executed from timers) lead to a full blown kernel
panic. The fbcon panic handler then tried to frob our driver harder,
resulting in a full machine hang at least on my snb here where I've
stumbled over this.
- Handle ring wrapping correctly and be a bit more explicit about how
many dwords we're scanning. We probably should also scan more than
just 4 ...
- Space out some of teh computations for readability.
This reduces hard-hangs on my snb here. Mika and QA both say that it
doesn't completel remove them, but at least for me it's a clear
improvement in stability.
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Ben Widawsky <ben@bwidawsk.net>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
References: https://bugs.freedesktop.org/show_bug.cgi?id=74100
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
With the recent addition of locking checks in
commit 62ff94a549
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
AuthorDate: Thu Jan 23 22:18:47 2014 +0100
drm/crtc-helper: remove LOCKING from kerneldoc
drm_add_edid_modes started to WARN about the mode_config.mutex not
being held in the lvds and dp initialization code.
Now since this is init code locking is fairly redudant if it wouldn't
be for the drm core registering sysfs files a bit early. And the
locking WARNINGs nicely enforce that indeed all access to the mode
lists are properly protected. And a full audit shows that only i915
and gma500 touch the modes lists at init time.
Hence I've opted to wrap up this entire mode detection sequence for
fixed panels with the mode_config mutex for both lvds and edp outputs.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
/ssd/git/drm-next/drivers/gpu/drm/i915/i915_cmd_parser.c: In function ‘i915_parse_cmds’:
/ssd/git/drm-next/drivers/gpu/drm/i915/i915_cmd_parser.c:405:4: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 5 has type ‘int’ [-Wformat=]
DRM_DEBUG_DRIVER("CMD: Command length exceeds batch length: 0x%08X length=%d batchlen=%ld\n",
^
Signed-off-by: Dave Airlie <airlied@redhat.com>
There are only a few users of the DRM_LOG_KMS() macro. We can simplify
the DRM code a bit by replacing them by DRM_DEBUG_KMS().
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
It apparently blows up on some machines. This functionally reverts
commit 828c79087c
Author: Ben Widawsky <benjamin.widawsky@intel.com>
Date: Wed Oct 16 09:21:30 2013 -0700
drm/i915: Disable GGTT PTEs on GEN6+ suspend
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=64841
Reported-and-Tested-by: Brad Jackson <bjackson0971@gmail.com>
Cc: stable@vger.kernel.org
Cc: Takashi Iwai <tiwai@suse.de>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Todd Previte <tprevite@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
With the recent addition of locking checks in
commit 62ff94a549
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
AuthorDate: Thu Jan 23 22:18:47 2014 +0100
drm/crtc-helper: remove LOCKING from kerneldoc
drm_add_edid_modes started to WARN about the mode_config.mutex not
being held in the lvds and dp initialization code.
Now since this is init code locking is fairly redudant if it wouldn't
be for the drm core registering sysfs files a bit early. And the
locking WARNINGs nicely enforce that indeed all access to the mode
lists are properly protected. And a full audit shows that only i915
and gma500 touch the modes lists at init time.
Hence I've opted to wrap up this entire mode detection sequence for
fixed panels with the mode_config mutex for both lvds and edp outputs.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
It is important that the user is fully aware that the seemingly atomic
read/write of a 64-bit value from MMIO space, may in fact be 2 separate
operations of 32-bits. This can lead to hilarity, such as
commit d18b961903
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Wed Jul 10 13:36:23 2013 +0100
drm/i915: Fix incoherence with fence updates on Sandybridge+
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
intel_sdvo_get_trained_inputs() returns a bool, check the status
accordingly.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
On non-LLC platforms, when changing the cache level of an object, we may
need to unbind it so that prefetching across page boundaries does not
cross into a different memory domain. This requires us to unbind
conflicting vma, but we did so iterating over the objects vma in an
unsafe manner (as the list was being modified as we iterated).
The regression was introduced in
commit 3089c6f239
Author: Ben Widawsky <ben@bwidawsk.net>
Date: Wed Jul 31 17:00:03 2013 -0700
drm/i915: make caching operate on all address spaces
apparently as far back as v3.12-rc1, but it has only just begun to
trigger real world bug reports.
Reported-and-tested-by: Nikolay Martynov <mar.kolya@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76384
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ben Widawsky <ben@bwidawsk.net>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
With this patch we allow larger cursor planes of sizes 128x128
and 256x256.
v2: Added more precise check on size while setting cursor plane.
v3: Changes related to restructuring cursor size restrictions
and DRM_DEBUG usage.
v4: Indentation related changes for setting cursor control and
implementing DRM_CAP_CURSOR_WIDTH and DRM_CAP_CURSOR_HEIGHT
Testcase: igt/kms_cursor_crc
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: David Airlie <airlied@linux.ie>
Cc: dri-devel@lists.freedesktop.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: G, Pallavi <pallavi.g@intel.com>
Signed-off-by: Sagar Kamble <sagar.a.kamble@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The point of this measure is to gauge why a process has a lot of gem
objects in uses and why. Especially for compositors it's interesting
to know whether it's a leak of private objects or just a lot of use
from buffers shared with clients.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
[danvet: Add a bit of commit message flesh to address Ben's comment.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The idea of printing objects used by each process is to judge how each
process is using them. This means that we need to evaluate whether the
object is bound for that particular process, rather than just whether it
is bound into the global GTT.
v2: Restore the non-full-ppgtt path for simplicity as we may not even
create vma with older hardware.
v3: Tweak handling of global entries and default context entries.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ben Widawsky <benjamin.widawsky@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
With the renamed RPS struct members, it's easier to skip the local
variables which no longer clarify anything, and if anything just make
the code harder to read.
The real motivation for this patch is actually the next patch, which
attempts to consolidate some of the functionality.
Cc: Jeff McGee <jeff.mcgee@intel.com>
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>
The values created at initialization must always exist to use the
interface. Reading them again is confusing, and pointless.
More cleanups are coming in the next patch. Since I am not 100% certain,
moreover on BYT, (though I am extremely close to that) that there is no
need to leave the MMIO here, I wanted to make it a separate patch for
the bisectable 'just-in-case'
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>
The names of the struct members for RPS are stupid. Every time I need to
do anything in this code I have to spend a significant amount of time to
remember what it all means. By renaming the variables (and adding the
comments) I hope to clear up the situation. Indeed doing this make some
upcoming patches more readable.
I've avoided ILK because it's possible that the naming used for Ironlake
matches what is in the docs. I believe the ILK power docs were never
published, and I am too lazy to dig them up.
v2: leave rp0, and rp1 in the names. It is useful to have these limits
available at times. min_freq and max_freq (which may be equal to rp0, or
rp1 depending on the platform) represent the actual HW min and max.
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>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
this leaves a temporarily awkward min_delay (the soft limit) with the
new min_freq (the hardware limit). It's fixed in the next patch.
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>
Introduced:
commit b8a5ff8d7c
Author: Jeff McGee <jeff.mcgee@intel.com>
Date: Tue Feb 4 11:37:01 2014 -0600
drm/i915: Update rps interrupt limits
Cc: Jeff McGee <jeff.mcgee@intel.com>
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>
The existing code (which I changed last) was very convoluted. I believe
it was attempting to skip the overclock portion if the previous pcode
write failed. When I last touched the code, I was preserving this
behavior. There is some benefit to doing it that way in that if the
first pcode access fails, the later is likely invalid.
Having a bit more confidence in my understanding of how things work, I
now feel it's better to have clear, readable, code than to try to skip
over this one operation in an unusual case.
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>
ACPI_VIDEO no longer depends on VIDEO_OUTPUT_CONTROL, so drivers which
want to select ACPI_VIDEO no longer have to select
VIDEO_OUTPUT_CONTROL.
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Function intel_init_runtime_pm is supposed to start allowing runtime
PM from that point, but it's called very late on the driver
initialization code, to prevent the driver from trying to suspend
while still initializing. The problem is that variables are accessed
earlier than that, so initalize them at intel_pm_setup, which is
supposed to be the correct place.
Notice that this shouldn't fix any specific bugs because dev_priv is
zeroed when allocated, so the value is already correct right from the
start.
v2: - Rebase.
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>
Now that PC8 got much simpler, there are less things to document.
Also, runtime PM already has a nice documentation, so we don't need to
re-explain it on our driver.
v2: - Rebase.
- Fix typo (Jesse).
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>
After we removed all the intermediate abstractions, we can rename
these functions to just hsw_{en,dis}able_pc8.
v2: - Rebase.
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>
The only remaining field of the struct was the lock, which was
useless.
v2: - Rebase.
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>
When other platforms add runtime PM support they will also need to
disable interrupts, so move the variable to the runtime PM struct.
Also notice that the longer-term goal is to completely kill the
regsave struct, and I even have patches for that.
v2: - Rebase.
v3: - Rebase.
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>
It was just being used on debugfs and on a WARN inside
hsw_set_power_well. But now that we PC8 is part of runtime PM and we
get/put runtime PM when we get/put any power domain, we shouldn't need
the WARN anymore.
v2: - Rebase.
v3: - Rebase.
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>
Because we already get/put runtime PM every time we get/put any power
domain, and now PC8 and runtime PM are the same thing.
With this, we can also now kill the hsw_{en,dis}able_package_c8
functions.
v2: - Rebase.
v3: - Rebase.
v4: - Rebase.
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>
Because we merged the PC8 and runtime PM features, so calling
intel_runtime_pm_get now has the same meaning, and we plan to just
remove hsw_disable_package_c8 for this exact reason.
My first patch tried to completely kill
intel_aux_display_runtime_get/put, because I was assuming that whoever
needed more than just runtime PM would have to get the appropriate
power domain instead of that, but it seems some people still want the
intel_aux_display_runtime_get abstraction, so keep it until someone
else tries to replace it with the more-standard power domain calls.
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>
We already get runtime PM references, and PC8 is now part of runtime
PM, so this is enough.
v2: - Rebase.
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>
After the latest changes, the indirection is useless.
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>
Since after the latest patches it's only being used to prevent
getting/putting the runtime PM refcount.
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>
... instead of PC8 references. Now that both are the same thing and we
are killing PC8, just get the runtime PM reference.
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>
The requirements_met variable was used to track two things: enabled
CRTCs and the power well. After the latest chagnes, we get a runtime
PM reference whenever we get any of the power domains, and we get
power domains when we enable CRTCs or the power well, so we should
already be covered, not needing this specific tracking.
v2: - Rebase.
v3: - Rebase.
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>
Any power domain will require the HW to be in PCI D0 state, so just do
the simple thing.
Dear maintainer: since intel_display_power_put() and
intel_display_power_get() are almost identical, git-am has failed
apply the patch on my local machine once: it added both chunks to
put(), instead of one chunk to get() and another to put(). When you
apply this patch to your tree, please check if it is correct.
v2: - Add the warning above.
v3: - Rebase.
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Currently, when our driver becomes idle for i915.pc8_timeout (default:
5s) we enable PC8, so we save some power, but not everything we can.
Then, while PC8 is enabled, if we stay idle for more
autosuspend_delay_ms (default: 10s) we'll enter runtime PM and put the
graphics device in D3 state, saving even more power. The two features
are separate things with increasing levels of power savings, but if we
disable PC8 we'll never get into D3.
While from the modularity point of view it would be nice to keep these
features as separate, we have reasons to merge them:
- We are not aware of anybody wanting a "PC8 without D3" environment.
- If we keep both features as separate, we'll have to to test both
PC8 and PC8+D3 code paths. We're already having a major pain to
make QA do automated testing of just one thing, testing both paths
will cost even more.
- Only Haswell+ supports PC8, so if we want to add runtime PM support
to, for example, IVB, we'll have to copy some code from the PC8
feature to runtime PM, so merging both features as a single thing
will make it easier for enabling runtime PM on other platforms.
This patch only does the very basic steps required to have PC8 and
runtime PM merged on a single feature: the next patches will take care
of cleaning up everything.
v2: - Rebase.
v3: - Rebase.
- Fully remove the deprecated i915 params since Daniel doesn't
consider them as part of the ABI.
v4: - Rebase.
- Fix typo in the commit message.
v5: - Rebase, again.
- Add a huge comment explaining the different forcewake usage
(Chris, Daniel).
- Use open-coded forcewake functions (Daniel).
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>
When we merge PC8 and runtime PM, these new functions are going to be
called by the runtime suspend/resume functions, and their callers are
going to be removed.
v2: - Rebase
Reviewed-by: Imre Deak <imre.deak@intel.com> (v1)
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Conflicts:
drivers/gpu/drm/i915/intel_dp.c
A bit a mess with reverts which differe in details between -fixes and
-next and some other unrelated shuffling.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The name 'update_plane' was used both for the primary plane functions in
intel_display.c and the sprite/overlay functions in intel_sprite.c.
Rename the primary plane functions to 'update_primary_plane' to avoid
confusion.
On a similar note, intel_display.c already had a function called
intel_disable_primary_plane() that programs the hardware to disable a
pipe's primary plane. When we hook up primary planes through the DRM
plane interface, one of the natural handler names will be
intel_primary_plane_disable(), which is very similar. To avoid
confusion, rename the existing intel_disable_primary_plane() to
intel_disable_primary_hw_plane() to make the two names a little more
distinct.
Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
[danvet: Fix up conflicts.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
So don't try to allocate and program it, we're only fooling ourselves.
Reported-by: "Chang, Junxiao" <junxiao.chang@intel.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Junxiao Chang <junxiao.chang@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Apparently it is wiped out from under us, and we get some really fun
caching artifacts upon resume (it seems to be WB for all types by
default).
Reported-by: James Ausmus <james.ausmus@intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Tested-by: James Ausmus <james.ausmus@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76113
Tested-by: Timo Aaltonen <timo.aaltonen@canonical.com>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We have reports of heavy screen corruption if we try to use the stolen
memory reserved by the BIOS whilst the DMA-Remapper is active. This
quirk may be only specific to a few machines or BIOSes, but first lets
apply the big hammer and always disable use of stolen memory when DMAR
is active.
v2 by Jani: Rebase on -fixes, only look at intel_iommu_gfx_mapped.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68535
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
This reverts
commit dff392dbd2
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date: Fri Dec 6 17:32:41 2013 -0200
drm/i915: don't touch the VDD when disabling the panel
which didn't take into account
commit 6cb49835da
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Sun May 20 17:14:50 2012 +0200
drm/i915: enable vdd when switching off the eDP panel
and
commit 35a38556d9
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Sun Aug 12 22:17:14 2012 +0200
drm/i915: reorder edp disabling to fix ivb MacBook Air
Unsurprisingly, various MacBooks failed.
Effectively the same has already been done in drm-intel-next-queued.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74628
Tested-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The TP_printk() should never dereference any pointers, because the ring
buffer can be read at some unknown time in the future. If a device no
longer exists, it can cause a kernel oops. This also makes this
event useless when saving the ring buffer in userspaces tools such as
perf and trace-cmd.
The i915_gem_evict_vm dereferences the vm pointer which may also not
exist when the ring buffer is read sometime in the future.
Link: http://lkml.kernel.org/r/1395095198-20034-3-git-send-email-artagnon@gmail.com
Reported-by: Ramkumar Ramachandra <artagnon@gmail.com>
Cc: stable@vger.kernel.org # 3.13+
Fixes: bcccff847d "drm/i915: trace vm eviction instead of everything"
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
[danvet: Try to make it actually compile]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When compiling on 32bits, I have the following warning:
drivers/gpu/drm/i915/i915_cmd_parser.c:405:4: warning: format ‘%ld’
expects argument of type ‘long int’, but argument 7 has type ‘int’
[-Wformat=]
DRM_DEBUG_DRIVER("CMD: Command length exceeds batch length: 0x%08X
length=%d batchlen=%ld\n",
The ptrdiff_t type has its own modifier: 't'.
Cc: Brad Volkin <bradley.d.volkin@intel.com>
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Brad Volkin <bradley.d.volkin@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This function is only used on ILK+, so rename it accordingly.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This is a small follow-up fix to the series of eDP VDD back and forth
we've had recently. This is effectively a combined revert of three
commits:
commit 2c2894f698fffd8ff53e1e1d3834f9e1035b1f39
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date: Fri Mar 7 20:05:20 2014 -0300
drm/i915: properly disable the VDD when disabling the panel
commit b3064154df
Author: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Date: Tue Mar 4 00:42:44 2014 +0100
drm/i915: Don't just say it, actually force edp vdd
commit dff392dbd2
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date: Fri Dec 6 17:32:41 2013 -0200
drm/i915: don't touch the VDD when disabling the panel
which shows that we're pretty close back to where we started
already. The first two were basically reverting the last, but missing
the WARN. Add that back. We also OCD the intel_ prefix back to
intel_edp_panel_vdd_on() which was lost somewhere in between. The circle
closes.
For future reference, "drm/i915: don't touch the VDD when disabling the
panel" failed to take into account
commit 6cb49835da
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Sun May 20 17:14:50 2012 +0200
drm/i915: enable vdd when switching off the eDP panel
and
commit 35a38556d9
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Sun Aug 12 22:17:14 2012 +0200
drm/i915: reorder edp disabling to fix ivb MacBook Air
Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Without this the new drv_suspend/forcewake subtest I've created
doesn't result in immediately visible failures.
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Ben Widawsky <ben@bwidawsk.net>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
I have been seeing this for a long time, but ignored it because it's
typically not terribly important. Recently, I really needed this info,
and it was garbage. Proof that I should have fixed it sooner. Originally
wrong from:
commit 6c7a01ec37
Author: Ben Widawsky <benjamin.widawsky@intel.com>
Date: Thu Jan 30 00:19:40 2014 -0800
drm/i915: Capture PPGTT info on error capture
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>
Commit b3064154df tried to revert commit
dff392dbd2, but wasn't complete, which
resulted in regressions on Haswell. So this commit should fix
b3064154df by undoing what it did and
providing an actual complete revert of
dff392dbd2.
Fixes regression introduced by:
commit b3064154df
Author: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Date: Tue Mar 4 00:42:44 2014 +0100
drm/i915: Don't just say it, actually force edp vdd
Testcase: igt/pm_pc8
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Tested-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We used to have per file descriptor hang stats for the
i915_get_reset_stats_ioctl() and for default context banning.
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
made having separate hangstats in file_private redundant
as i915_hw_context already contained hangstats. So
commit c482972a08
Author: Ben Widawsky <benjamin.widawsky@intel.com>
Date: Fri Dec 6 14:11:20 2013 -0800
drm/i915: Piggy back hangstats off of contexts
consolidated the hangstats and enabled further improvements.
commit 44e2c0705a
Author: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Date: Thu Jan 30 16:01:15 2014 +0200
drm/i915: Use i915_hw_context to set reset stats
tried to reap full benefits of consolidation but fell short
as we never 'switch' to the fake private context on gens
that don't have hw_contexts, so request->ctx remained NULL
on those.
Fix this by 'switching' to fake context so that when
request is submitted to ring, proper context gets assigned
to it.
Testcase: igt/drv_hangman
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76055
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This is a regression introduced in
commit 0294ae7b44
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Thu Mar 13 12:00:29 2014 +0000
drm/i915: Consolidate forcewake resetting to a single function
The reordered setup sequence ended up calling del_timer_sync before
the timer was set up correctly, resulting in endless hilarity when
loading the driver.
Compared to Ben's patch (which moved around the setup_timer call to
sanitize_early) this moves the sanitize_early call around in the
driver load call. This way we avoid calling setup_timer again in the
resume code (where we also call sanitize_early).
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Ben Widawsky <benjamin.widawsky@intel.com>
Tested-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76242
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The functionality remains largerly the same. The main difference is that
i2c-over-aux defer timeouts are increased to be safe for all use cases
instead of depending on DP device type and properties.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Do a slight rearrangement of the switch to prep for follow-up.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Functionality remains largely the same as before.
Note that the retry loops and native reply handling all moved into the
core drm helper functions now.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
[danvet: Fix up the stray ; Rodrigo spotted in his review and add a
note to the commit message to answer Rodrigo's question in his review.]
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This is prep work for conversion to generic drm i2c-over-aux helpers
where we won't have the function to do this at.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Introduce _edp_panel_vdd_on() that returns true if the call enabled vdd,
and a matching disable is needed. Keep edp_panel_vdd_on() as a helper
for when it is expected the vdd is off.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This is the 3rd respin of the drm-anon patches. They allow module unloading, use
the pin_fs_* helpers recommended by Al and are rebased on top of drm-next. Note
that there are minor conflicts with the "drm-minor" branch.
* 'drm-next' of git://people.freedesktop.org/~dvdhrm/linux:
drm: init TTM dev_mapping in ttm_bo_device_init()
drm: use anon-inode instead of relying on cdevs
drm: add pseudo filesystem for shared inodes
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJTJlUvAAoJEHm+PkMAQRiGOhYH/1I+Bc7N7Rjr6QQAtBIy0GPC
XMqSE/gpgxlvRneQbQsvTUlPnWRhgzLGendT9HFKawkaQ0UNuZdRVyBHGFmpuED8
RlbicVVuuEZabrxEnCd7UPvYvEyK5pLIFpCRs5B+ManB1qLki2Ar03ymH1NRxOde
edmPbSUFo2aONITrEBm7tqT3cShTmBaDGP/zU0TNDMNrpVVDbHZolSNu2z4xOTa5
GqAOEbluLQ6jP3yxWur/V3Lk3W7pB6TabfX4o6UZu0F3iFnJxRMIzHXrI3o4yLTj
HEwmB3npfc8DIUk4oik7RkN+aqxDcdg/rBLQD63+xxt6zCkP+0q16brC0R67qWE=
=n9Ml
-----END PGP SIGNATURE-----
Merge tag 'v3.14-rc7' into drm-next
Linux 3.14-rc7
Backmerge to help out Intel guys.
Conflicts:
drivers/gpu/drm/i915/Makefile
Makefile cleanup in drm-intel-next conflicts with a build-fix to move
intel_opregion under CONFIG_ACPI.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
DRM drivers share a common address_space across all character-devices of a
single DRM device. This allows simple buffer eviction and mapping-control.
However, DRM core currently waits for the first ->open() on any char-dev
to mark the underlying inode as backing inode of the device. This delayed
initialization causes ugly conditions all over the place:
if (dev->dev_mapping)
do_sth();
To avoid delayed initialization and to stop reusing the inode of the
char-dev, we allocate an anonymous inode for each DRM device and reset
filp->f_mapping to it on ->open().
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
We have two paths that try to reset the forcewake registers back to
known good values, with slightly different semantics and levels of
paranoia. Combine the two by passing a parameter to either restore the
forcewake status or to clear our bookkeeping, and raise the paranoia
level to max.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
It's been in there since forever, and no one cared. Doesn't put a too
good light onto our bug handling and QA efforts really ...
References: https://bugs.freedesktop.org/attachment.cgi?id=90970
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Now that we regularly defer the forcewake dance to a timer func, it is
likely to fire after we disable the device during suspend. This
generates an oops as we detect inconsistency in the hardware state. So
before suspend, we want to complete the outstanding dance and generally
sanitize the registers before handing back to the BIOS.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When we change the cache_level for an object we need to make sure
we don't put differing types of snoopable memory too close to each
other on non-LLC machines.
Currently i915_gem_object_set_cache_level() will stop looking when
it finds just one vma that has such a conflict. Drop the bogus break
statement to make sure it will unbind all vmas which need to be moved
around to avoid the conflict.
I suppose this is a theoretical issue as currently we don't enable
ppgtt on non-LLC machines, so each object can only have one vma.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We will call ppgtt_bind_vma() with flags != 0, so the WARN_ON(flags)
is bogus. Kill it.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
While wandering in the spec, I noticed that BDW removes those 2 bits
from INSTPM. I couldn't find any direct way to invalidate the TLB (ie
without the ring working already). Maybe someone will be more lucky.
At least, we now know we may be a problem.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We need to enable interrupt processing before all the modeset
state is set up. But that means we can fall over when we get a pipe
underrun. This shouldn't happen as long as the bios works correctly
but as usual this turns out to be wishful thinking.
So disable error interrupts at irq install time and rely on the
re-enabling code in the modeset functions to take care of this.
Note that due to the SDE interrupt handling race we must
uncondtionally enable all interrupt sources in SDEIER, hence no need
to enable the SERR bit specifically.
On gmch platforms we don't have an explicit enable/mask bit for fifo
underruns. Fixing this up would require a bit of software tracking,
hence is material for a separate patch. To make this possible we need
to switch all gmch platforms to the new pipestat interrupt handling
scheme Imre implemented for vlv, and then also add a safe form of sw
state checking to __cpu_fifo_underrun_reporting_enabled a bit.
v2: Also handle the ilk/snb cpu fifo underrun bits accordingly.
Spotted by Ville.
v3: Also handle the south interrupt underrun bits on ibx. Again
spotted by Ville.
Reported-by: Rob Clark <robdclark@gmail.com>
Cc: Rob Clark <robdclark@gmail.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: stable@vger.kernel.org
Tested-by: 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>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
I have the occasional absent cursor on i845 and I want to know why.
This should help by revealing the last known cursor state.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The display interrupts changed on BDW, so the current ILK-HSW specific
code in ilk_pipe_in_vblank_locked() doesn't work there. Add the required
bits for BDW, and while at it, change the existing code to use nicer
looking vblank status bit macros.
Also remove the now stale __raw_i915_read16() definition which was
left over from the failed gen2 ISR experiment.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73962
Tested-by: Lu Hua <huax.lu@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
We don't need to hold struct_mutex all through intel_pipe_set_base(),
just need to hold it while pinning/unpinning the buffers.
So reduce the struct_mutext usage in intel_pipe_set_base() just like we
did for the sprite code in:
commit 82284b6bec
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Tue Oct 1 18:02:12 2013 +0300
drm/i915: Reduce the time we hold struct mutex in sprite update_plane code
The FBC and PSR locking is still entirely fubar. That stuff was
previouly done while holding struct_mutex, so leave it there for now.
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>
On HSW the scanline counter seems to behave differently depending on
the output type. eDP on port A does what you would expect an the normal
+1 fixup is sufficient to cover it. But on HDMI outputs we seem to need
a +2 fixup. Just assume we always need the +2 fixup and accept the
slight inaccuracy on eDP.
This fixes a regression introduced in:
commit 8072bfa604
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date: Mon Oct 28 21:22:52 2013 +0200
drm/radeon: Move the early vblank IRQ fixup to radeon_get_crtc_scanoutpos()
That commit removed the heuristic that tried to fix up the timestamps
for vblank interrupts that fire a bit too early. Since then the vblank
timestamp code would treat some vblank interrupts as spurious since the
scanline counter would indicate that vblank_start wasn't reached yet.
That in turn lead to incorrect vblank event sequence numbers being
reported to userspace, which lead to unsteady framerate in applications
such as XBMC which uses them for timing purposes.
v2: Remember to call ilk_pipe_in_vblank_locked() on HSW too (Mika)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75725
Tested-by: bugzilla1@gmx.com
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Based on Bspec the command parser must be stopped prior to
issuing sync flush. This should be done by the caller of
intel_ring_setup_status_page. Patch adds a warning if it is
not done.
v2: rebased based on new patch (wait for ring to become idle)
Signed-off-by: Naresh Kumar Kachhi <naresh.kumar.kachhi@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
make sure we wait for rings to become idle once they are
disabled. In case of timeout print an error message
Signed-off-by: Naresh Kumar Kachhi <naresh.kumar.kachhi@intel.com>
[danvet: Frob patch as suggested by Chris.]
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Rings should be idle before issuing sync_flush
(in intel_ring_setup_status_page). This patch moves the ring
disabling before doing the HW status page setup.
Signed-off-by: Naresh Kumar Kachhi <naresh.kumar.kachhi@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Our code allows have a PPGTT that is smaller than the maximum size for
GEN6-GEN7. Though I don't think this actually ever occurs, the code may
as well work properly and more importantly look correct by using the
variable size instead of the HW max.
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>
I'm not clear if the hardware is still subject to the same prefetching
issues that made us use a scratch page in the first place. In either
case, we're using garbage with the current code (we will end up using
offset 0).
This may be the cause of our current gem_cpu_reloc regression with
PPGTT. I cannot test it at the moment.
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>
Introduced in
commit e0e33f8ff6f0b6d286afc314802be4993341bd47
Author: Imre Deak <imre.deak@intel.com>
Date: Tue Mar 4 19:23:07 2014 +0200
The impact was luckily minimal, due to the extra check we do against a
software pipestat IRQ mask.
Caught by Fengguang's 0-day tester.
Cc: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
BSpec is a bit unclear whether HDMI+HDMI cloning should work on g4x.
Tests on real hardware say that it does. Since g4x can't send
infoframes to more than one HDMI port anyway, we don't lose anything
by allow it.
For PCH platforms BSpec explicitly forbids HDMI+HDMI cloning.
Whether HDMI+HDMI cloning might also work on VLV is a bit unclear, but
since we'd at least lose the capability of sending infoframes to more
than one cloned HDMI port, it doesn't seem like a good idea to allow it.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73850
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
HDMI+VGA cloning should be supported on all platforms. The only real
obstacle is the 1.5x clock adjustment for 12bpc HDMI, but that is now
taken care of, so we can allow HDMI+VGA cloning.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73850
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When cloning HDMI with other output types, we can't use 12bpc since the
clocks for the other encoder types would be off. So have
intel_hdmi_compute_config() check if there are other encoders besides
HDMI being fed from the same pipe, and if so, pick 8bpc insted if 12bpc.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJTHSaRAAoJEHm+PkMAQRiG7G8IAJHElwFDNSQE7Y9MmbicrAMG
kfjhBtBpTaVrJKQXegCNUwDaLLyC4oLIxDheW84oPXbrEGDLqPtBov/hrcFkHVr4
lh/ZYk02nYtcfpN0JnL/Yj2oKHVmBWs0vFlM7StSFsJCj10DoCVQQdmAJ8XODTPo
CXMapk+UikTX1TlIO8+B5toyl3R1OqPmW211UV1vQVLKy66hu+MKVN/V+/EyopL0
1jO81EDpaRaeIJh1/okcyUoIq9pqLkAWNpeQ7uyXZ+Sfivt9RXwLYKmAB3lP20Hc
ZMIIoHSCyYRFjxLlQvt02bA9nY4wTY7YN5kZ2kk65y7TFfhcGsCw1Sc69iyCoKs=
=CJcA
-----END PGP SIGNATURE-----
Merge tag 'v3.14-rc6' into drm-intel-next-queued
Linux 3.14-rc6
I need the hdmi/dvi-dual link fixes in 3.14 to avoid ugly conflicts
when merging Ville's new hdmi cloning support into my -next tree
Conflicts:
drivers/gpu/drm/i915/Makefile
drivers/gpu/drm/i915/intel_dp.c
Makefile cleanup conflicts with an acpi build fix, intel_dp.c is
trivial.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Currently we allow encoders to indicate whether they can be part of a
cloned set with just one flag. That's not flexible enough to describe
the actual hardware capabilities. Instead make it a bitmask of encoder
types with which the current encoder can be cloned.
For now we set the bitmask to allow DVO+DVO and DVO+VGA, which should
match what the old boolean flag allowed. We will add some more cloning
options in the future.
Note that this patch also removes the encoder.possible_clones setting
from encoder setup code - we compute this dynamically.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com>
[danvet: Add Ville's explanation why removing the encoder
possible_clones is save.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
When adding new gunk, _always_ think of a good place. Start/end
usually just means that this didn't happen, and on top of that results
in needless conflicts with other patches doing the same.
Introduced in
commit 62d5d69b49
Author: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Date: Tue Feb 25 17:11:28 2014 +0200
drm/i915: Add suspend count to error state
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The stolen allocator objects loudly if the caller requests a zero-sized
object. This is a useful verbose check as in most cases the request
should have been pruned much early. Here we just want to silently return
before attempting the allocation.
Regression from
commit 484b41dd70
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date: Fri Mar 7 08:57:55 2014 -0800
drm/i915: remove early fb allocation dependency on CONFIG_FB v2
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75963
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
During KMS takeover, we try to capture the current configuration and
preserve it across our initialisation. For a variety of reasons, we may
fail this, for example if the current mode was using the legacy VGA
plane. Under such circumstances, we discard the fb in the plane config
and tried to find a matching fb on another CRTC. This obviously also
failed, leaving the plane config fb dangling, pointing to the freed block.
Regression from
commit 484b41dd70
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date: Fri Mar 7 08:57:55 2014 -0800
drm/i915: remove early fb allocation dependency on CONFIG_FB v2
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75963
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
By stuffing the fb allocation into the crtc, we get mode set lifetime
refcounting for free, but have to handle the initial pin & fence
slightly differently. It also means we can move the shared fb handling
into the core rather than leaving it out in the fbdev code.
v2: null out crtc->fb on error (Daniel)
take fbdev fb ref and remove unused error path (Daniel)
Requested-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Retrieve current framebuffer config info from the regs and create an fb
object for the buffer the BIOS or boot loader left us. This should
allow for smooth transitions to userspace apps once we finish the
initial configuration construction.
v2: check for non-native modes and adjust (Jesse)
fixup aperture and cmap frees (Imre)
use unlocked unref if init_bios fails (Jesse)
fix curly brace around DSPADDR check (Imre)
comment failure path for pin_and_fence (Imre)
v3: fixup fixup of aperture frees (Chris)
v4: update to current bits (locking & pin_and_fence hack) (Jesse)
v5: move fb config fetch to display code (Jesse)
re-order hw state readout on initial load to suit fb inherit (Jesse)
re-add pin_and_fence in fbdev code to make sure we refcount properly (Je
v6: rename to plane_config (Daniel)
check for valid object when initializing BIOS fb (Jesse)
split from plane_config readout and other display changes (Jesse)
drop use_bios_fb option (Chris)
update comments (Jesse)
rework fbdev_init_bios for clarity (Jesse)
drop fb obj ref under lock (Chris)
v7: use fb object from plane_config instead (Ville)
take ref on fb object (Jesse)
v8: put under i915_fastboot option (Jesse)
fix fb ptr checking (Jesse)
inform drm_fb_helper if we fail to enable a connector (Jesse)
drop unnecessary enabled[] modifications in failure cases (Chris)
split from BIOS connector config readout (Daniel)
don't memset the fb buffer if preallocated (Chris)
alloc ifbdev up front and pass to init_bios (Chris)
check for bad ifbdev in restore_mode too (Chris)
v9: fix up !fastboot bpp setting (Jesse)
fix up !fastboot helper alloc (Jesse)
make sure BIOS fb is sufficient for biggest active pipe (Jesse)
v10:fix up size calculation for proposed fbs (Chris)
go back to two pass pipe fb assignment (Chris)
add warning for active pipes w/o fbs (Chris)
clean up num_pipes checks in fbdev_init and fbdev_restore_mode (Chris)
move i915.fastboot into fbdev_init (Chris)
v11:make BIOS connector config usage unconditional (Daniel)
v12:fix up fb vs pipe size checking (Chris)
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This should allow BIOS fb inheritance to work on ILK+ machines too.
v2: handle tiled BIOS fbs (Kristian)
split out common bits (Jesse)
v3: alloc fb obj out in _init
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Read out the current plane configuration at init time into a new
plane_config structure. This allows us to track any existing
framebuffers attached to the plane and potentially re-use them in our
fbdev code for a smooth handoff.
v2: update for new pitch_for_width function (Jesse)
comment how get_plane_config works with shared fbs (Jesse)
v3: s/ARGB/XRGB (Ville)
use pipesrc width/height (Ville)
fix fourcc comment (Bob)
use drm_format_plane_cpp (Ville)
v4: use fb for tracking fb data object (Ville)
v5: fix up gen2 pitch limits (Ville)
v6: read out stride as well (Daniel)
v7: split out init ordering changes (Daniel)
don't fetch config if !CONFIG_FB
v8: use proper height in get_plane_config (Chris)
v9: fix CONFIG_FB check for modular configs (Jani)
v10: add comment about stolen allocation stomping
v11: drop hw state readout hunk (Daniel)
v12: handle tiled BIOS fbs (Kristian)
pull out common bits (Jesse)
v13: move fb obj alloc out to _init
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Early at init time, we can try to read out the plane config structure
and try to preserve it if possible.
v2: alloc fb obj at init time after fetching plane config
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We don't always want to write into main memory with pwrite. The shmem
fast path in particular is used for memory that is cacheable - under
such circumstances forcing the cache eviction is undesirable. As we will
always flush the cache when targeting incoherent buffers, we can rely on
that second pass to apply the cache coherency rules and so benefit from
in-cache copies otherwise.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Brad Volkin <bradley.d.volkin@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We used to lock individual pages inside the buffer object and so needed
to update the page flags every time. However, we now pin the pages into
the object for the duration of the pwrite/pread (and hopefully much
longer) and so we can forgo the flag updates until we release all the
pages.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Brad Volkin <bradley.d.volkin@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris suggested to split things up a bit into the different parts of
the driver and also sort it all correctly, with the hope that we're
trying to organize things a bit better eventually. It should also
help newcomers to orient themselves a bit better.
v2:
- Move intel_pm.c to the core - to make things perfect we should split
out the modeset related pm features (psr/fbc) into a separate file.
Maybe something Rodrigo can do once the PSR patches have settled.
- Split the modesetting sections into core and encoders/outputs.
intel_ddi.c is a bit funky since it has core hsw+ support and ddi
output support. Whatever.
v3: Failed to git add ...
v4: Really go ocd, i.e. spelling fix in a comment from Jani.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The command parser scans batch buffers submitted via execbuffer ioctls before
the driver submits them to hardware. At a high level, it looks for several
things:
1) Commands which are explicitly defined as privileged or which should only be
used by the kernel driver. The parser generally rejects such commands, with
the provision that it may allow some from the drm master process.
2) Commands which access registers. To support correct/enhanced userspace
functionality, particularly certain OpenGL extensions, the parser provides a
whitelist of registers which userspace may safely access (for both normal and
drm master processes).
3) Commands which access privileged memory (i.e. GGTT, HWS page, etc). The
parser always rejects such commands.
See the overview comment in the source for more details.
This patch only implements the logic. Subsequent patches will build the tables
that drive the parser.
v2: Don't set the secure bit if the parser succeeds
Fail harder during init
Makefile cleanup
Kerneldoc cleanup
Clarify module param description
Convert ints to bools in a few places
Move client/subclient defs to i915_reg.h
Remove the bits_count field
OTC-Tracker: AXIA-4631
Change-Id: I50b98c71c6655893291c78a2d1b8954577b37a30
Signed-off-by: Brad Volkin <bradley.d.volkin@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
[danvet: Appease checkpatch.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The command parser is going to need the same synchronization and
setup logic, so factor it out for reuse.
v2: Add a check that the object is backed by shmem
Signed-off-by: Brad Volkin <bradley.d.volkin@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Make sure the line_time_us isn't zero in the gmch watermarks code as
that would cause a div by zero. This can be triggered by specifying
a very fast pixel clock for the mode.
At some point we should probably just switch over to using the same
math we use on PCH platforms which avoids such intermediate rounded
results.
Also we should verify the user provided mode much more rigorously.
At the moment we accept pretty much anything.
Note that "very fast mode" here means above 74.25 GHz.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Add Ville's clarification of what "very fast" means.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Based on an early draft from Jesse.
Add support for powering on/off the dynamic power wells on VLV by
registering its display and dpio dynamic power wells with the power
domain framework.
For now power on all PHY TX lanes regardless of the actual lane
configuration. Later this can be optimized when the PHY side setup
enables only the required lanes. Atm, it enables all lanes in all
cases.
v2:
- undef function local COND macro after its last use (Ville)
- Take dev_priv->irq_lock around the whole sequence of
intel_set_cpu_fifo_underrun_reporting_nolock() and
valleyview_disable_display_irqs(). They are short and releasing
the lock in between only makes proving correctness more difficult.
- sanitize local var names in vlv_power_well_enabled()
v3:
- rebase on latest -nightly
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Resolve conflict due to my changes in the previous patch.
Also throw in an assert_spin_locked for safety. And finally appease
checkpatch.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Needed by the next patch, wanting to set the underrun reporting as part
of a bigger dev_priv->irq_lock'ed sequence.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Use more customary __ prefix instead of _nolock postfix.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We'll need to disable/re-enable the display-side IRQs when turning
off/on the VLV display power well. Factor out the helper functions
for this. For now keep the display IRQs enabled by default, so the
functionality doesn't change. This will be changed to enable/disable
the IRQs on-demand when adding support for VLV power wells in an
upcoming patch.
v2:
- take the irq spin lock for the whole enable/disable sequence as
these can be called with interrupts enabled
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Suggested by Daniel.
v2:
- sanitize the state checking condition, the original was rather
confusing (partly due to the unfortunate naming of
i915.disable_power_well) (Ville)
- simpler message+backtrace generation by using WARN instead of WARN_ON
(Ville)
- check if always-on power wells are truly on all the time
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We need to do the same for other platforms in upcoming patches.
v2:
- s/p/pipe (Ville)
- Call the new helper with the vbl_lock already held. The part it
protects is short, so releasing it between pipes only makes proving
correctness more difficult.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Resolve conflict with Damien's s/p/pipe/ change.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
In the upcoming patches we'll need to access the rest of the fields in
the punit power gating register, so prepare for that.
v2:
- add doc reference for the power well subsystem IDs (Jesse)
- remove IDs for non-existant DPIO_RX[23] subsystems (Jesse)
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This is a left-over from
commit b7e634cc8d
Author: Imre Deak <imre.deak@intel.com>
Date: Tue Feb 4 21:35:45 2014 +0200
drm/i915: vlv: don't unmask IIR[DISPLAY_PIPE_A/B_VBLANK] interrupt
where we stopped unmasking the vblank IRQs, but left them enabled in the
IER register. Disable them in IER too.
v2:
- remove comment becoming stale after this change (Ville)
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
We can read out the pipe HW state only if the required power domain is
on. If not we consider the pipe to be off.
v2:
- no change
v3:
- push down the power domain checks into the specific crtc
get_pipe_config handlers (Daniel)
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Appease checkpatch.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Since the encoder is tied to its port, we need to make sure the power
domain for that port is on before reading out the encoder HW state.
Note that this also covers also all connector get_hw_state handlers,
since all those just call the corresponding encoder get_hw_state
handler, which checks - after this change - for all power domains
the connector needs.
v2:
- no change
v3:
- push down the power domain checks into the specific encoder
get_hw_state handlers (Daniel)
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
The connector detect and get_mode handlers need to access the port
specific HW blocks to read the EDID etc. Get/put the port power domains
around these handlers.
v2:
- get port power domain for HDMI too (Ville)
- get port power domain for the DP,HDMI audio detect handlers (Jesse)
- Leave the intel_runtime_pm_get/put in the DP detect function in place.
Instead of just removing them, these should be moved to the appropriate
power_well enable/disable handlers. We can do this after Paulo's
'Merge PC8 with runtime PM, v2' patchset.
v3:
- rebased on latest -nightly
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Parts that poke port specific HW blocks like the encoder HW state
readout or connector hotplug detect code need a way to check whether
required power domains are on or enable/disable these. For this purpose
add a set of power domains that refer to the port HW blocks. Get the
proper port power domains during modeset.
For now when requesting the power domain for a DDI port get it for a 4
lane configuration. This can be optimized later to request only the 2
lane power domain, when proper support is added on the VLV PHY side for
this. Atm, the PHY setup code assumes a 4 lane config in all cases.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reading code free of special cases wins over the small overhead of
calling a noop handler. Suggested by Jesse.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Split the 'set' power well handler into an 'enable', 'disable' and
'sync_hw' handler. This maps more conveniently to higher level
operations, for example it allows us to push the hsw package c8 handling
into the corresponding hsw/bdw enable/disable handlers and the hsw BIOS
hand-over setting into the hsw/bdw sync_hw handler.
No functional change.
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Appease checkpatch's whitespace complaints.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Whenever we request a power domain it has to guarantee that all HW
resources are enabled that are needed to access a HW register associated
with that power domain. In case a register is on an always-on power well
this won't result in turning on a power well, but it may require
enabling some other HW resource. One such resource is the HSW/BDW device
D0 state that is required for all register accesses and thus for all
power wells/power domains.
So far the init power domain (guaranteeing access to all HW registers)
was part of the default i9xx always-on power well, but not the HSW/BDW
always-on power wells. Add the domain to the latter power wells too.
Atm, all the always-on power wells have noop handlers, so this doesn't
change the functionality.
v2:
- clarify semantics of always-on power wells (Paulo)
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
These macros are used only locally, so move them to the .c file.
No functional change.
v2:
- add init power domain to always-on power wells in the following
- separate - patch (Paulo)
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
There are too many oustanding issues:
- Fence handling in the current code is broken. There's a patch series
from me, but it's blocked on and extended review (which includes
writing the testcases).
- IOMMU mapping handling is broken, we need to properly refcount it -
currently it gets destroyed when the first vma is unbound, so way
too early.
- There's a pending reset issue on snb. Since Mika's reset work and
full ppgtt have been pulled in in separate branches and ended up
intermittingly breaking each another it's unclear who's the exact
culprit here.
- We still have persistent evidince of crazy recursion bugs through
vma_unbind and ppgtt_relase, e.g.
https://bugs.freedesktop.org/show_bug.cgi?id=73383
This issue (and a few others meanwhile resolved) have blocked our
performance measuring/tuning group since 3 months.
- Secure batch dispatching is broken. This is blocking Brad Volkin's
command checker work since 3 months.
All these issues are confirmed to only happen when full ppgtt is
enabled, falling back to aliasing ppgtt resolves them. But even
aliasing ppgtt itself still has a regression:
- We currently unconditionally bind objects into the aliasing ppgtt,
which means all priviledged objects like ringbuffers are visible to
unpriviledged access again. On top of that this also breaks the
command checker for aliasing ppgtt, since it can't hide the
validated batch any more.
Furthermore topic/full-ppgtt has never been reviewed:
- Lifetime rules around vma unbinding/release are unclear, resulting
into this awesome hack called ppgtt_release. Which seems to take the
blame for most of the recursion fallout.
- Context/ring init works different on gpu reset than anywhere else.
Such differeneces have in the past always lead to really hard to
track down bugs.
- Aliasing ppgtt is treated in a bunch of places as a real address
space, but it isn't - the real address space is always the global
gtt in that case. This results in a bit a mess between contexts and
ppgtt object, further complication the context/ppgtt/vma lifetime
rules.
- We don't have any docs describing the overall concepts introduced
with full ppgtt. A short, concise overview describing vmas and some
of the strange bits around them (like the unbound vmas used by
execbuf, or the new binding rules) really is needed.
Note that a lot of the post topic/full-ppgtt merge fallout has already
been addressed, this entire list here of 10 issues really only contains
the still outstanding issues.
Finally the 3.15 merge window is approaching and I think we need to
use the remaining time to ensure that our fallback option of using
aliasing ppgtt is in solid shape. Hence I think it's time to throw the
switch. While at it demote the helper from static inline status
because really.
Cc: Ben Widawsky <ben@bwidawsk.net>
Cc: Dave Airlie <airlied@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
These functions will be needed by the valleyview specific power well
update functionality added in an upcoming patch, so move them earlier.
No functional change.
v2:
- no change
v3:
- rebase on latest -nightly
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v2)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
These functions are used only by a single call site and are simple
enough to just fold them in.
Note that in later patches the parts folded in here are further
simplified as we'll remove hsw_{disable,enable}_package_c8 and the NULL
check of the power well enable/disable handlers. All this means that at
the end intel_display_power_get/put() becomes more understandable as we
don't need to jump between two functions when reading the code.
No functional change.
v2:
- clarify the rational for the change (Chris)
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| has a higher precedence than ?. Therefore, the calculation doesn't do
at all what you would expect. Thanks to Ken for convincing me that this
was indeed the issue. Send me back to C programmer school, please.
I'm sort of surprised PSR was continuing to work for people. It should
be broken IMO (and it was broken for me, but I had assumed it never
worked).
Regression from:
commit ed8546ac1f
Author: Ben Widawsky <benjamin.widawsky@intel.com>
Date: Mon Nov 4 22:45:05 2013 -0800
drm/i915/bdw: Support eDP PSR
Cc: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Cc: Kenneth Graunke <kenneth.w.graunke@intel.com>
Cc: Art Runyan <arthur.j.runyan@intel.com>
Reported-by: "Kumar, Kiran S" <kiran.s.kumar@intel.com>
Cc: stable@vger.kernel.org [v3.13+]
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
We have two names for the same register CHICKEN_PIPESL_1 and
HSW_PIPE_SLICE_CHICKEN_1. Unify it to just one.
Also rename the FBCQ disable bit to resemble the name we've
given to a similar bit on earlier platforms.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
gen7_enable_fbc() may write to some registers which we've already
touched, so use RMW so that we don't undo any previous updates.
Also note that we implemnt WaFbcAsynchFlipDisableFbcQueue:bdw.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Misplaced parens cause us to totally clobber the CHICKEN_PIPESL_1
registers with 0xffffffff. Move the parens to the correct place
to avoid this.
In particular this caused bit 30 of said registers to be set, which
caused the sprite CSC to produce incorrect results.
Cc: stable@vger.kernel.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=72220
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
... it's this time of the year again. Originally we've frobbed this to
fix up some regressions, but maybe our DP code improved sufficiently
now that we can dare to do again what the spec recommends.
This reverts
commit 2514bc510d
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date: Thu Jun 21 15:13:50 2012 -0700
drm/i915: prefer wide & slow to fast & narrow in DP configs
I'm pretty sure I'll regret this patch, but otoh I expect we won't
make progress here without poking the devil occasionally.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73694
Cc: peter@colberg.org
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Tested-by: Itai BEN YAACOV <candeb@free.fr>
Tested-by: David En <d.engraf@arcor.de>
Reported-and-Tested-by: Marcus Bergner <marcusbergner@gmail.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
As we now have intel_uncore_forcewake_reset() no need
to do explicit put after reset.
v2: rebase
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
While reading some code, out of boredom, stumbled on a tiny tiny fix.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
