- 23 Jul, 2014 33 commits
-
-
Jesse Barnes authored
After this point, we'll modify it with the runtime routines. Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Jesse Barnes authored
Before we've installed the handler, we can set this and avoid confusing init code that then thinks IRQs are enabled and spews complaints everywhere. Signed-off-by:
-
Jesse Barnes authored
Now that we use the runtime IRQ enable/disable functions in our suspend path, we can simply check the pm._irqs_disabled flag everywhere. So rename it to catch the users, and add an inline for it to make the checks clear everywhere. Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
-
Jesse Barnes authored
This was always the case on our suspend path, but it was recently exposed by the change to use our runtime IRQ disable routine rather than the full DRM IRQ disable. Keep the warning on the enable side, as that really would indicate a bug. Signed-off-by:
-
Paulo Zanoni authored
Move it from hsw_power_well_post_enable() (intel_pm.c) to i915_irq.c so we can reuse the nice IRQ macros we have there. The main difference is that now we're going to check if the IIR register is non-zero when we try to re-enable the interrupts. Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Paulo Zanoni authored
So don't write it, otherwise we will trigger unclaimed register errors. Testcase: igt/pm_rpm/rte Signed-off-by:
-
Paulo Zanoni authored
If we enable unclaimed register reporting on Gen 8, we will discover that the IRQ registers for pipes B and C are also on the power well, so writes to them when the power well is disabled result in unclaimed register errors. Also, hsw_power_well_post_enable() already takes care of re-enabling them once the power well is enabled. Testcase: igt/pm_rpm/rte Signed-off-by:
-
Daniel Vetter authored
Traditionally we use genX_ for GT/render stuff and the codenames for display stuff. But the gt and pm interrupt handling functions on gen5/6+ stuck out as exceptions, so convert them. Looking at the diff this nicely realigns our ducks since almost all the callers are already platform-specific functions following the genX_ pattern. Spotted while reviewing some internal rps patches. No function change in this patch. Acked-by:
Damien Lespiau <damien.lespiau@intel.com> Signed-off-by:
-
Damien Lespiau authored
Signed-off-by:
-
Chris Wilson authored
During the range invalidate, we walk the list of buffers associated with the mmu_notifer and find the ones that overlap the range. An optimisation is made to speed up the iteration by assuming the previous iter is still valid whilst the tree is unmodified. This exposes a bug when a range invalidate is triggered after we have just created the mmu_notifier, but before attaching any buffers. In that case, we presume we have an unmodified list and start walking from the last iter which is NULL. Oops. The easiest fix is then to initialise the serial of the tree to 1. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Reviewed-by:
Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Testecase: igt/gem_userptr_blts/stress-mm Signed-off-by:
-
Chris Wilson authored
Whilst waiting to obtain our locks for the last resort shrinking before an oom, we check whether or not a fatal signal was pending. If there was, we do not need to keep waiting as the oom will be aborted. Signed-off-by:
-
Damien Lespiau authored
In the future, we'll need the height of the fb to fetch from memory for WM computation. Signed-off-by:
-
Damien Lespiau authored
No need to list all the platforms explicitly. The prefix is a bit inconsistent since we usually pick gen8_ for GT related functions. But this anti-pattern is already established with snb, so material for a different patch. Cc: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by:
-
Vandana Kannan authored
Updated drm documentation to include desscription of aspect ratio property. v2: Updated aspect ratio specific documentation on top of the HTML table created. Signed-off-by:
Vandana Kannan <vandana.kannan@intel.com> Cc: Sagar Kamble <sagar.a.kamble@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
Sagar Kamble <sagar.a.kamble@intel.com> Acked-by:
Dave Airlie <airlied@gmail.com> Signed-off-by:
-
Vandana Kannan authored
Create and attach the drm property to set aspect ratio. If there is no user specified value, then PAR_NONE/Automatic option is set by default. User can select aspect ratio 4:3 or 16:9. The aspect ratio selected by user would come into effect with a mode set. v2: Modified switch case to include aspect ratio enum changes v3: Modified the patch according the change in the earlier patch to return errno in case property creation fails. With this change, property will be attached only if creation is successful Signed-off-by:
-
Vandana Kannan authored
In case user has specified an input for aspect ratio through the property, then the user space value for PAR would take preference over the value from CEA mode list. v2: Thierry's review comments. - Modified the comment "Populate..." as per review comments v3: Thierry's review comments. - Modified the comment to block comment format. Signed-off-by:
Thierry Reding <treding@nvidia.com> Acked-by:
-
Vandana Kannan authored
Added a property to enable user space to set aspect ratio. This patch contains declaration of the property and code to create the property. v2: Thierry's review comments. - Made aspect ratio enum generic instead of HDMI/CEA specfic - Removed usage of temporary aspect_ratio variable v3: Thierry's review comments. - Fixed indentation v4: Thierry's review comments. - Return ENOMEM when property creation fails Signed-off-by:
-
Deepak S authored
Drop WaGsvBringDownFreq on CHV. When in RC6 requesting the min freq should be fine to bring the voltage down. Signed-off-by:
Deepak S <deepak.s@linux.intel.com> Reviewed-by:
-
Paulo Zanoni authored
We already call intel_display_power_get, which will get a power domain, and every power domain should get a runtime PM reference, which will wake up the machine. v2: - Also touch intel_crt_detect() (Ville). Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> [danvet: Fixup commit message as spotted by Ville.] Signed-off-by:
-
Deepak S authored
We might be leaving the GPU Frequency (and thus vnn) high during the suspend. Force gt to move to lowest freq while suspending. v2: Fixed typo in commit message (Deepak) v3: Force gt to lowest freq in suspend_gt_powersave (Daniel) v4: Add GPU min freq set _after_ we've cancelled the rps works (Daniel) Signed-off-by:
-
Chris Wilson authored
Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Rodrigo Vivi authored
Panel Self Refresh is an eDP power saving feature specified by VESA's eDP v1.3, that allows some panel componets to shutdown while you still see static images on the screen. Besides being supported on the platform it must be supported by the eDP panel itself. Now that we have the propper frontbuffer tracking support and correct locks on place we can enabled this feature by default. Signed-off-by:
-
Daniel Vetter authored
We only need to check for this in psr_enable, everything else is already protect by the dev_priv->psr.enabled checks. Those need the psr locking, but these functions are called infrequent enough that the locking overhead is negligible. Suggested by Chris Wilson. Reviewed-by:
-
Daniel Vetter authored
Add busy_frontbuffer_bits and locking. Reviewed-by:
-
Daniel Vetter authored
I've tried to split this up, but all the changes are so tightly related that I didn't find a good way to do this without breaking bisecting. Essentially this completely changes how psr is glued into the overall driver, and there's not much you can do to soften such a paradigm change. - Use frontbuffer tracking bits stuff to separate disable and re-enable. - Don't re-check everything in the psr work. We have now accurate tracking for everything, so no need to check for sprites or tiling really. Allows us to ditch tons of locks. - That in turn allows us to properly cancel the work in the disable function - no more deadlocks. - Add a check for HSW sprites and force a flush. Apparently the hardware doesn't forward the flushing when updating the sprite base address. We can do the same trick everywhere else we have such issues, e.g. on baytrail with ... everything. - Don't re-enable psr with a delay in psr_exit. It really must be turned off forever if we detect a gtt write. At least with the current frontbuffer render tracking. Userspace can do a busy ioctl call or no-op pageflip to re-enable psr. - Drop redundant checks for crtc and crtc->active - now that they're only called from enable this is guaranteed. - Fix up the hsw port check. eDP can also happen on port D, but the issue is exactly that it doesn't work there. So an || check is wrong. - We still schedule the psr work with a delay. The frontbuffer flushing interface mandates that we upload the next full frame, so need to wait a bit. Once we have single-shot frame uploads we can do better here. v2: Don't enable psr initially, rely upon the fb flush of the initial plane setup for that. Gives us more unified code flow and makes the crtc enable sequence less a special case. v3: s/psr_exit/psr_invalidate/ for consistency v4: Fixup whitespace. v5: Correctly bail out of psr_invalidate/flush when dev_priv->psr.enabled is NULL. Spotted by Rodrigo. v6: - Only schedule work when there's work to do. Fixes WARNINGs reported by Rodrigo. - Comments Chris requested to clarify the code. v7: Fix conflict on rebase (Rodrigo) Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
Daniel Vetter authored
It's not really optional to have locking ... The ugly part is how much locking the psr work needs since it has to recheck everything. Which is way too much. But we need to ditch the psr work in it's current form anyway and implement proper frontbuffer tracking. The other nasty bit that had to go was the delayed work cancle in psr_exit. Which means a bunch of races just became a bit more likely, but mea culpa. v2: Fixup HAS_PSR checks, resulting in uninitialized mutex issues. Reviewed-by:
-
Daniel Vetter authored
We need to make sure that no one else is using this in the enable function and also that the work item hasn't raced with the disabled function. v2: Improve bisectability by moving one hunk to an earlier patch. v3: added missing dev_priv declaration (Rodrigo) Reviewed-by:
-
Daniel Vetter authored
Make sure we track the sw side (psr.active) correctly and WARN everywhere it might get out of sync with the hw. v2: Fixup WARN_ON logic inversion, reported by Rodrigo. Reviewed-by:
-
Daniel Vetter authored
It's disabled already except when we've raced. Reviewed-by:
-
Daniel Vetter authored
Trying to fish that one out through looping is a bit a locking nightmare. So just set it and use it in the work struct. v2: - Don't Oops in psr_work, spotted by Rodrigo. - Fix compile warning. Reviewed-by:
-
Daniel Vetter authored
Can't review this right now due to lack of DRRS code. Reviewed-by:
-
Daniel Vetter authored
Due to runtime pm and system s/r we need to restore hw state every time we enable a pipe again. Hence trying to avoid that is just pointless book-keeping which Rodrigo then tried to work around by manually adding psr_setup calls to our resume code. Much simpler to just remove code instead. v2: Properly bail out of psr exit if psr isn't enabled. Spotted by Rodrigo. Reviewed-by:
-
Borun Fu authored
On VLV, after i915_pm_suspend display power wells are staying power ungated. So, after initiating mem sleep "echo mem > /sys/power/state" Display is staing D0 State. There might be better way/place to power gate these wells. Also, we need to make sure that if wells are power gated due to DPMS OFF sequence, they need not be turned off by i915_pm_suspend again. v2: Extracted helper for intel_crtc_disable and power gating CRTC power wells. [Daniel] Cc: Imre Deak <imre.deak@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Jani Nikula <jani.nikula@linux.intel.com> Change-Id: I34c80da66aa24c423a5576c68aa1f3a8d0f43848 Signed-off-by:
Borun Fu <borun.fu@intel.com> Signed-off-by:
-
- 12 Jul, 2014 2 commits
-
-
Fengguang Wu authored
CC: Deepak S <deepak.s@linux.intel.com> CC: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Fengguang Wu <fengguang.wu@intel.com> Signed-off-by:
-
Mika Kuoppala authored
The register to read cz count is different from vlv. Also the counts returned from CCK_CTL1 for BSW are (ticks in 30ns - 1). czcount_30ns of value 1 is a special case for 320Mhz. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80703Suggested-by:
Mika Kuoppala <mika.kuoppala@intel.com> Tested-by:
Guo Jinxian <jinxianx.guo@intel.com> Reviewed-by:
-
- 11 Jul, 2014 5 commits
-
-
Sagar Kamble authored
Cc: damien.lespiau@intel.com Cc: daniel.vetter@ffwll.ch Cc: ville.syrjala@linux.intel.com Signed-off-by:
Dave Airlie <airlied@linux.ie> Signed-off-by:
-
Sagar Kamble authored
These property descriptions were kept as placeholder. Removing them for simplicity. Cc: damien.lespiau@intel.com Cc: daniel.vetter@ffwll.ch Cc: ville.syrjala@linux.intel.com Signed-off-by:
-
Ville Syrjälä authored
drm_rotation_simplify() can be used to eliminate unsupported rotation flags. It will check if any unsupported flags are present, and if so it will modify the rotation to an alternate form by adding 180 degrees to rotation angle, and flipping the reflect x and y bits. The hope is that this identity transform will eliminate the unsupported flags. Of course that might not result in any more supported rotation, so the caller is still responsible for checking the result afterwards. Cc: dri-devel@lists.freedesktop.org Signed-off-by:
Imre Deak <imre.deak@intel.com> Acked-by:
-
Ville Syrjälä authored
Add some helper functions to move drm_rects between different rotated coordinate spaces. One function does the forward transform and another does the inverse. Cc: dri-devel@lists.freedesktop.org Signed-off-by:
-
Ville Syrjälä authored
Use the new drm_mode_create_rotation_property() in omapdrm. Cc: dri-devel@lists.freedesktop.org Signed-off-by:
Rob Clark <robdclark@gmail.com> Reviewed-by:
-
