- 03 Apr, 2014 5 commits
-
-
Ville Syrjälä authored
DPIO reads from groups/broadcast register offsets for PCS and TX return all 1's. If that result gets used for something we'll probably end up doing something wrong. So warn when that happens. FIXME there might be some registers where all 1's is a valid value, so ideally we should check the register offset instead... Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Jesse Barnes <jbarnes@virtuousgeek.org> [danvet: copypaste the FIXME comment into the code.] Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
There's no point in hiding the DP M/N setup in the update_pll functions. Just move it to the mode_set function. Signed-off-by:
-
Ville Syrjälä authored
Iterate over all the PDP registers instead of just printing PDP0 four times in gen8 PPGTT debugfs info. Signed-off-by:
Ben Widawsky <ben@bwidawsk.net> Signed-off-by:
-
Daniel Vetter authored
Our validation guys want to have a positive proof that the gfx driver is indeed using VT-d, since setting up a gfx stack, especially in early bring-up and by people not versed in linux gfx is a bit tricky. So provide just that. Cc: David Woodhouse <dwmw2@infradead.org> Signed-off-by: -
Daniel Vetter authored
VTd has a few too many "outright disable the damn thing" workarounds accumulated and for validation we want a simple knob to make sure we disable them all. Since this is for bdw+ validation and atm we don't have any workarounds for bdw this option currently does nothing. So currently this is just a placeholder to make sure reality will match with the documented process for our validation people. v2: Fix up param description (Jani). v3: Actually git add ... Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: David Woodhouse <dwmw2@infradead.org> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
- 02 Apr, 2014 10 commits
-
-
Paulo Zanoni authored
If I boot my Broadwell machine to X on a system with Mesa Gallium llvmpipe instead of i965, then kill X and try to run pm_pc8.c, when we disable PC8 and call gen6_update_ring_freq(), we will get stuck on an infinite loop because the frequencies are zero and the variables are unsigned. This happens because we never ran any batch, so we did not enable RC6, so the variables are zero. If I run gem_exec_nop before running pm_pc8, everything works as expected because gem_exec_nop makes RC6 be enabled. This commit should prevent the infinite loop, which IMHO is already a good reason to be merged, but it is not the proper fix to the "RC6 is not being enabled" problem. Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
-
Paulo Zanoni authored
Because if we keep the current code, we'll get tons of WARNs on Broadwell, since the code is Haswell-specific. We could have also added a Broadwell-specific code there, but it's not really needed since we never disable LCPLL with the hotplug interrupts still enabled. So keep the easy-and-simple-to-maintain solution until we actually need something else. Signed-off-by:
-
Akash Goel authored
This patch Enables the bit for TLB invalidate in GFX Mode register for Gen7. According to bspec, When enabled this bit limits the invalidation of the TLB only to batch buffer boundaries, to pipe_control commands which have the TLB invalidation bit set and sync flushes. If disabled, the TLB caches are flushed for every full flush of the pipeline. Tested only on vlv platform. Chris has tested on ivb and hsw platforms. v2: Adding the explicit enabling of this bit for all Gen7 platforms instead of only vlv (Chris) 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:
-
Jani Nikula authored
Drop the cast from the pointer diff to fix: drivers/gpu/drm/i915/i915_cmd_parser.c:405:4: warning: format '%td' expects argument of type 'ptrdiff_t', but argument 5 has type 'long unsigned int' [-Wformat] While at it, use %u for u32. Reported-by:
Randy Dunlap <rdunlap@infradead.org> Signed-off-by:
-
Brad Volkin authored
There is some thought that the data from the performance counters enabled via OACONTROL should only be available to the process that enabled counting. To limit snooping, require that any batch buffer which sets OACONTROL to a non-zero value also sets it back to 0 before the end of the batch. This requires limiting OACONTROL writes to happen via MI_LOAD_REGISTER_IMM so that we can access the value being written. This should be in line with the expected use case for writing OACONTROL. v2: Drop an unnecessary '? true : false' Cc: Kenneth Graunke <kenneth@whitecape.org> Signed-off-by:
Brad Volkin <bradley.d.volkin@intel.com> Reviewed-by:
Kenneth Graunke <kenneth@whitecape.org> Signed-off-by:
-
Brad Volkin authored
This brings the code a little more in line with kernel coding style. Signed-off-by:
-
Brad Volkin authored
As suggested during review, this makes it much more obvious when the tables are not sorted. Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by:
-
Zhenyu Wang authored
Signed-off-by:
Zhenyu Wang <zhenyuw@linux.intel.com> Reviewed-by:
-
Ben Widawsky authored
For error state, like the recent modification to ACTHD, FADD also gets an upper dword. This is useful for debug to make sure the fetch address and head are similar. Signed-off-by:
-
Ville Syrjälä authored
BSpec seems to tell us we need the MI_ARB_ON_OFF w/a around MI_SET_CONTEXT on gen8. Signed-off-by:
-
- 01 Apr, 2014 25 commits
-
-
Paulo Zanoni authored
This sould be enough. v2: BDW should also run hsw_runtime_resume (Ben). Signed-off-by:
Imre Deak <imre.deak@intel.com> Signed-off-by:
-
Paulo Zanoni authored
That's what the spec said! And HSW needs it through pcode (you can only read it through MCHBAR), so create hsw_write_dcomp to abstract the weirdness. Signed-off-by:
-
Paulo Zanoni authored
Now that PC8 is part of runtime PM, the check is useless. Signed-off-by:
-
Paulo Zanoni authored
Just because I have a SNB machine and I can easily test it. Signed-off-by:
-
Paulo Zanoni authored
We're adding runtime suspend support to more platforms, so organize the code in a way that all a new platform needs to do is to add its own gen-specific functions. Also rename the i915_ functions to intel_ to make it clear that it's the top level one, not something that just runs on i915 platforms. Signed-off-by:
-
Paulo Zanoni authored
Now that we don't keep the hotplug interrupts enabled anymore, we can kill the regsave struct and just cal the normal IRQ preinstall, postinstall and uninstall functions. This makes it easier to add runtime PM support to non-HSW platforms. The only downside is in case we get a request to update interrupts while they are disabled, won't be able to update the regsave struct. But this should never happen anyway, so we're not losing too much. v2: - Rebase. v3: - Rebase. v4: - Rebase. Signed-off-by:
-
Paulo Zanoni authored
We should only enable interrupts at postinstall. And now on ILK/SNB/IVB/HSW the irq_preinstall and irq_postinstall functions leave the hardware in the same state. Signed-off-by:
-
Paulo Zanoni authored
So we can merge all the common code from postinstall and uninstall. v2: - Rebase. - While at it, remove useless { and }. Signed-off-by: -
Paulo Zanoni authored
To merge the common code of ironlake_irq_preinstall and ironlake_irq_uninstall. We should also probably do something about that HSWSTAM write on a later commit. Signed-off-by:
-
Paulo Zanoni authored
Missing from gen8_irq_uninstall. Reviewed-by:
-
Paulo Zanoni authored
After the latest changes, ibx_irq_preinstall and ibx_irq_uninstall are the same, so remove one of the copies and rename the other to ibx_irq_reset (since we're using the "reset" name for things which are called both at preinstall and uninstall). v2: - Rebase. Signed-off-by:
-
Paulo Zanoni authored
On the preinstall stage we should just disable all the interrupts, but we currently enable all the south display interrupts due to the way we touch SDEIER at the IRQ handlers (note: they are still masked and our IRQ handler is disabled). Instead of doing that, let's make the preinstall stage just disable all the south interrupts, and do the proper interrupt dance/ordering at the postinstall stage, including an assert to check if everything is behaving as expected. Signed-off-by:
-
Paulo Zanoni authored
After all, we call ibx_irq_preinstall from gen8_irq_preinstall. v2: - Rebase. Reviewed-by:
-
Paulo Zanoni authored
Just like ibx_irq_preinstall. We'll call this from somewhere else in the next patch. Reviewed-by:
-
Paulo Zanoni authored
The duplicate was at an _uninstall function, so rename it to gen5_gt_irq_reset. v2: - Rebase. Signed-off-by:
-
Paulo Zanoni authored
Same as SERR_INT and the other IIR registers: reset on preinstall/uninstall and WARN for non-zero values at postinstall. This one also doesn't need double-clear. v2: - Remove the is_zero assertion (Ben). Reviewed-by:
-
Paulo Zanoni authored
The SERR_INT register is very similar to the other IIR registers, so let's zero it at preinstall/uninstall and WARN for a non-zero value at postinstall, just like we do with the other IIR registers. For this one, there's no need to double-clear since it can't store more than one interrupt. v2: - Remove the is_zero assertion (Ben). Reviewed-by:
-
Paulo Zanoni authored
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 authored
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 authored
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 authored
It's the only thing missing, apparently. v2: - Fix typo (Ben). Reviewed-by:
-
Paulo Zanoni authored
Same as the _INIT macro: the goal is to reuse the GEN8 macros, but there are still some slight differences. v2: - Rebase. Reviewed-by:
-
Paulo Zanoni authored
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 authored
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:
-
Paulo Zanoni authored
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:
-
