- 29 May, 2015 20 commits
-
-
Ville Syrjälä authored
Implement cdclk extraction for g33, 965gm and g4x platforms. The details came from configdb. Sadly there isn't anything there for other gen3/gen4 chipsets. So far I've tested this on one ELK where it gave me a HPLL VCO of 5333 MHz and cdclk of 444 MHz which seems perfectly sane for this machine. v2: Rebased to the latest v3: Rebased to the latest Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Mika Kahola <mika.kahola@intel.com> Acked-by:
Damien Lespiau <damien.lespiau@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
It seems 852GM/GMV uses a different HPLLCC encoding than the other 85x platforms. For 852GM/GMV cdclk is always 133MHz. Try to detect that using the PCI revision (sinc the device ID seems useless for that). I'm not at all sure this is a good idea, but according to the specs it should work. v2: Rebased to the latest v3: Rebased to the latest Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v1) Signed-off-by:
-
Ville Syrjälä authored
Actually read the HPLLCC register insted of assuming it's 0. Fix the HPLLCC bit definitions and all the missing ones from the 852GME spec. 852GME, 854 and 855 all seem to match the same HPLLC encoding even though only some of the values are valid is some of the platforms. v2: Rebased to the latest v3: Rebased to the latest Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v1) Signed-off-by:
-
Tvrtko Ursulin authored
Printing it for PPGTT VMAs only adds noise since we have defined view types are only applicable for GGTT. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by:
-
Damien Lespiau authored
The orignal code started by storing the actual central frequency (in Hz, using a uint64_t) in a uint32_t which codes for the register value. That can't be right. Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
-
Damien Lespiau authored
Those functions were the only one in existence when they were introduced. We now know they are only valid for HSW/BDW. Signed-off-by:
-
Damien Lespiau authored
abs_diff() properly protects its parameters, so no need for the outer () here. Signed-off-by:
-
Damien Lespiau authored
div_u64() can be either a inline function or a define, but in either case it's safe to provide expressions as parameters without outer () around them. Signed-off-by:
-
Damien Lespiau authored
This part doesn't depend on how we compute the DPLL dividers (p and p0/p1/p2) and can be reused even if we change the algorithm to do so. (something that is planned for a followup patch) Signed-off-by:
-
Damien Lespiau authored
We can coalesce the WARN() condition with the WARN() itself and, as we are returning early, we can de-intent the rest of the function. Signed-off-by:
-
Damien Lespiau authored
At the moment, even if we fail to find a suitable divider, we'll still try to set the mode with bogus parameters. Just fail the modeset if we can't generate the frequency. Signed-off-by:
-
Damien Lespiau authored
This helps debugging. Signed-off-by:
-
Damien Lespiau authored
Right now, when finishing the cycle with odd dividers without finding a suitable candidate, we end up in an infinite loop. Make sure to break in that case. Signed-off-by:
-
Jani Nikula authored
Not needed or used. Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Jani Nikula authored
The hotplug callbacks for DP and DDI effectively did nothing. Remove them. Signed-off-by:
-
Jani Nikula authored
There are plenty of hotplug related fields in struct drm_i915_private scattered all around. Group them under one hotplug struct. Clean up naming while at it. No functional changes. Signed-off-by:
-
Jani Nikula authored
Continue to loop early if there's nothing to do. No functional changes. Signed-off-by:
-
Jani Nikula authored
Move dp aux irq handling within the same branch instead of duplicating the conditions. No functional changes. Signed-off-by:
-
Jani Nikula authored
Bail out early if nothing to do. No functional changes. Signed-off-by:
-
David Weinehall authored
Export a new context parameter that can be set/queried through the context_{get,set}param ioctls. This parameter is passed as a context flag and decides whether or not a GPU address mapping is allowed to be made at address zero. The default is to allow such mappings. Signed-off-by:David Weinehall <david.weinehall@intel.com> Acked-by:
"Zou, Nanhai" <nanhai.zou@intel.com> Signed-off-by:
-
- 28 May, 2015 7 commits
-
-
Paulo Zanoni authored
This commit is the "sink CRC" version of: commit 8c740dce Author: Paulo Zanoni <paulo.r.zanoni@intel.com> Date: Fri Oct 17 18:42:03 2014 -0300 drm/i915: disable IPS while getting the pipe CRCs. For some unknown reason, when IPS gets enabled, the sink CRC changes. Since hsw_enable_ips() doesn't really guarantee to enable IPS (it depends on package C-states), we can't really predict if IPS is enabled or disabled while running our CRC tests, so let's just completely disable IPS while sink CRCs are being used. If we find a way to make IPS not change the pipe CRC result, we may want to fix IPS and then revert this patch (and 8c740dce too). While this doesn't happen, let's merge this patch, so the IGT tests relying on sink CRCs can work properly. This was discovered while developing a new IGT test, which will probably be called kms_frontbuffer_tracking. Testcase: igt/kms_frontbuffer_tracking (not on upstream IGT yet) Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Daniel Vetter authored
It's totally broken, and since commit d328c9d7 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Fri Apr 10 16:22:37 2015 +0200 drm/i915: Select starting pipe bpp irrespective or the primary plane the kernel will try to use it even for the common rgb888 framebuffers. Ville has patches to fix it all up properly, but unfortunately they're stuck in review limbo. And since the 4.2 feature cutoff has passed we need to somehow handle this regression. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Paulo Zanoni <przanoni@gmail.com> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com>
-
Ville Syrjälä authored
chv_enable_pll() doesn't need to hold sb_lock for the entire duration of the function. Drop the lock as soon as possible. valleyview_set_cdclk() does a potential lock+unlock+lock+unlock cycle with sb_lock. Grab the lock a few lines earlier so we can make do with a single lock+unlock cycle always. Signed-off-by:
-
Ville Syrjälä authored
Rename dpio_lock to sb_lock to inform the reader that its primary purpose is to protect the sideband mailbox rather than some DPIO state. Signed-off-by:
-
Ville Syrjälä authored
The primary plane frobbing was removed from the sprite code in commit ecce87ea Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Date: Tue Apr 21 17:12:50 2015 +0300 drm/i915: Remove implicitly disabling primary plane for now but the intel_flush_primary_plane() calls were left behind. Replace them with straight forward POSTING_READ() of the sprite surface address register. The other user of intel_flush_primary_plane() is g4x_disable_trickle_feed() where we can just inline the steps directly. This allows intel_flush_primary_plane() to be killed off. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
-
Ville Syrjälä authored
Expecting CHV power wells to be just an extended versions of the VLV power wells, a bunch of commented out power wells were added in anticipation when Punit folks would implement it all. Turns out they never did, and instead CHV has fewer power wells than VLV. Rip out all the #if 0'ed junk that's not needed. v2: Rename the "pipe-a" well to "display" to match VLV Clarify the pipe A power well relationship to pipes B and C (Deepak) Reviewed-by:Deepak S <deepak.s@linux.intel.com> Signed-off-by:
-
Ville Syrjälä authored
Not sure which LDO programming sequence delay should be used for the CHV PHY, but the spec says that 600ns is "Used by default for initial bringup", and the BIOS seems to use that, so let's do the same. Reviewed-by:
-
- 27 May, 2015 1 commit
-
-
Michel Thierry authored
commit 53292cdb ("drm/i915: Workaround to avoid lite restore with HEAD==TAIL") added a check for req0 != null which is unnecessary. The only way req0 could be null is if the list was empty, and this is already addressed at the beginning of execlists_context_unqueue(). Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Michel Thierry <michel.thierry@intel.com> Reviewed-by:
-
- 26 May, 2015 3 commits
-
-
Chris Wilson authored
In commit 1854d5ca Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Tue Apr 7 16:20:32 2015 +0100 drm/i915: Deminish contribution of wait-boosting from clients we removed an atomic timer based check for allowing waitboosting and moved it below the mutex taken during RPS. However, that mutex can be held for long periods of time on Vallyview/Cherryview as communication with the PCU is slow. As clients may frequently wait for results (e.g. such as tranform feedback) we introduced contention between the client and the RPS worker. We can take advantage of the RPS worker, by switching the wait boost decision to use spin locks and defer the actual reclocking to the worker. Fixes a regression of up to 45% on Baytrail and Baswell! v2 (Daniel): - Use max_freq_softlimit instead of the not-yet-merged boost frequency. - Don't inject a fake irq into the boost work, instead treat client_boost as just another legit waker. v3: Drop the now unused mask (Chris). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90112 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (v1) Signed-off-by:
-
Damien Lespiau authored
It was reported that this comment was confusing, and indeed it is. v2: (one year later!) Add the range for the DRM_I915_* iotcl defines (Daniel) Signed-off-by: -
Daniel Vetter authored
This reverts commit 118182e9. It's causing too much trouble when compile-testing for non-i915 folks. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
- 22 May, 2015 7 commits
-
-
Daniel Vetter authored
Signed-off-by: -
Chris Wilson authored
As Daniel commented on commit b7ffe1362c5f468b853223acc9268804aa92afc8 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Mon Apr 27 13:41:24 2015 +0100 drm/i915: Free RPS boosts for all laggards it is better to be explicit when sharing hardcoded values such as throttle/boost timeouts. Make it so! Signed-off-by:Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Chris Wilson authored
After allocating from the slab cache, we then need to free the request back into the slab cache upon error (and not call kfree as that leads to eventual memory corruption). Fixes regression from commit efab6d8d Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Tue Apr 7 16:20:57 2015 +0100 drm/i915: Use a separate slab for requests Signed-off-by:
-
Chandra Konduru authored
There is a mplayer video failure reported with xv. This is because there is a request to do both plane scaling and colorkey. Because skl hw doesn't support plane scaling and colorkey at the same time, request is failed which is expected behavior. To make xv operate, this patch allows colorkey continue to work without using scaler. Then behavior would be similar to platforms without plane scaler support. Signed-off-by:
Chandra Konduru <chandra.konduru@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90449 [danvet: change can_scale to bool as requested by Ville.] Reviewed-by:
-
Ville Syrjälä authored
GTT caching was disabled by default on gen8 due to not working with big pages. Some information suggests that it got fixed, but still GTT caching has been left disabled by default. Or could be it just meant that the default was changed to off, and hence the problem got solved. Enable GTT caching in the hopes of some performance increase. Whether or not the big pages issue has been fixed is irrelevant at this stage since we don't use big pages. This gives me a 1-2% improvement in xonotic on my BSW. Haven't tried BDW, but supposedly it has larger TLBs so might not benefit as much. On HSW GTT caching is enabled by default. Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
Ville Syrjälä authored
GEN8_L3SQCREG1 isn't saved in the context (verified by going through a context dump), and so we shouldn't be using the ring w/a code to initialize it. Also Bspec explicitly talks about MMIO and writing it with the CPU. Additionally there's another w/a WaTempDisableDOPClkGating:bdw which tells us to disable DOP clock gating around the GEN8_L3SQCREG1 write to make sure everyone notices the change. So let's do that as well. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Ville Syrjälä authored
We're not using ilk_init_lp_watermarks() on BDW for some reason. Probably due to the BDW patches and the relevant WM patches landing roughlly at the same time. Fix it up. Signed-off-by:
-
- 21 May, 2015 2 commits
-
-
Ville Syrjälä authored
Bspec says we should disable the FDI RX/TX before disabling the PCH ports. Do so. Signed-off-by:
-
Ville Syrjälä authored
Follow the BSpec sequence for the CRT port as well on PCH platforms, ie. disable the pipe before the port. Didn't bother looking at DDI in detail yet, so leave that one be even though the CRT is a PCH port there. Signed-off-by:
-
