aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/i915/intel_pm.c
Commit message (Collapse)AuthorAge
...
| * | Revert "drm/i915/vlv: fixup DDR freq detection per Punit spec"Deepak S2014-04-04
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As per the inputs provided by hardware team we still use DDR Rates as 0,1=800, 2=1066, 3=1333. With this change, Turbo freqs used on current machines matches. This reverts commit f64a28a7c5ab2fc342326de9e126acf3cc0f91d6. commit f64a28a7c5ab2fc342326de9e126acf3cc0f91d6 Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Mon Nov 4 16:07:00 2013 -0800 drm/i915/vlv: fixup DDR freq detection per Punit spec v2: Add reference to previous commit which changed this. (Daniel) Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Deepak S <deepak.s@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: fix WARNs when reading DDI state while suspendedPaulo Zanoni2014-04-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * drm/i915: vlv: reserve the GT power context only once during driver initImre Deak2014-04-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * drm/i915: prefer struct drm_i915_private to drm_i915_private_tJani Nikula2014-03-31
| | | | | | | | | | | | | | | | | | 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>
| * drm/i915: Mask PM/RPS interrupt generation based on activityChris Wilson2014-03-31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * drm/i915: Refactor gen6_set_rpsChris Wilson2014-03-31
| | | | | | | | | | | | | | | | | | | | | | | | 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>
| * Revert "drm/i915: Disable/Enable PM Intrrupts based on the current freq."Chris Wilson2014-03-31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 2754436913b94626a5414d82f0996489628c513d. 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>
| * drm/i915/bdw: Implement Wa4x4STCOptimizationDisable:bdwDamien Lespiau2014-03-28
| | | | | | | | | | | | | | | | | | | | | | | | 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>
| * drm/i915: Compute WM for current cursor sizeChris Wilson2014-03-28
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * drm/i915: Track the enabled PM interrupts in dev_priv.Deepak S2014-03-28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Merge tag 'drm-intel-next-2014-03-21' of ↵Dave Airlie2014-04-02
|\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://anongit.freedesktop.org/drm-intel into drm-next - Inherit/reuse firmwar framebuffers (for real this time) from Jesse, less flicker for fastbooting. - More flexible cloning for hdmi (Ville). - Some PPGTT fixes from Ben. - Ring init fixes from Naresh Kumar. - set_cache_level regression fixes for the vma conversion from Ville&Chris. - Conversion to the new dp aux helpers (Jani). - Unification of runtime pm with pc8 support from Paulo, prep work for runtime pm on other platforms than HSW. - Larger cursor sizes (Sagar Kamble). - Piles of improvements and fixes all over, as usual. * tag 'drm-intel-next-2014-03-21' of git://anongit.freedesktop.org/drm-intel: (75 commits) drm/i915: Include a note about the dangers of I915_READ64/I915_WRITE64 drm/i915/sdvo: fix questionable return value check drm/i915: Fix unsafe loop iteration over vma whilst unbinding them drm/i915: Enabling 128x128 and 256x256 ARGB Cursor Support drm/i915: Print how many objects are shared in per-process stats drm/i915: Per-process stats work better when evaluated per-process drm/i915: remove rps local variables drm/i915: Remove extraneous MMIO for RPS drm/i915: Rename and comment all the RPS *stuff* drm/i915: Store the HW min frequency as min_freq drm/i915: Fix coding style for RPS drm/i915: Reorganize the overclock code drm/i915: init pm.suspended earlier drm/i915: update the PC8 and runtime PM documentation drm/i915: rename __hsw_do_{en, dis}able_pc8 drm/i915: kill struct i915_package_c8 drm/i915: move pc8.irqs_disabled to pm.irqs_disabled drm/i915: remove dev_priv->pc8.enabled drm/i915: don't get/put PC8 when getting/putting power wells drm/i915: make intel_aux_display_runtime_get get runtime PM, not PC8 ... Conflicts: drivers/gpu/drm/i915/intel_display.c drivers/gpu/drm/i915/intel_dp.c
| * drm/i915: remove rps local variablesBen Widawsky2014-03-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * drm/i915: Rename and comment all the RPS *stuff*Ben Widawsky2014-03-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * drm/i915: Store the HW min frequency as min_freqBen Widawsky2014-03-20
| | | | | | | | | | | | | | | | | | 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>
| * drm/i915: Reorganize the overclock codeBen Widawsky2014-03-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * drm/i915: init pm.suspended earlierPaulo Zanoni2014-03-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * drm/i915: kill struct i915_package_c8Paulo Zanoni2014-03-19
| | | | | | | | | | | | | | | | | | | | | | 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>
| * drm/i915: move pc8.irqs_disabled to pm.irqs_disabledPaulo Zanoni2014-03-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * drm/i915: remove dev_priv->pc8.enabledPaulo Zanoni2014-03-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * drm/i915: don't get/put PC8 when getting/putting power wellsPaulo Zanoni2014-03-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * drm/i915: make intel_aux_display_runtime_get get runtime PM, not PC8Paulo Zanoni2014-03-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * drm/i915: kill pc8.disable_countPaulo Zanoni2014-03-19
| | | | | | | | | | | | | | | | | | 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>
| * drm/i915: remove dev_priv->pc8.requirements_metPaulo Zanoni2014-03-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * drm/i915: get/put runtime PM when we get/put a power domainPaulo Zanoni2014-03-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * drm/i915: make PC8 be part of runtime PM suspend/resumePaulo Zanoni2014-03-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * drm/i915: Rename intel_setup_wm_latency() to ilk_setup_wm_latency()Damien Lespiau2014-03-18
| | | | | | | | | | | | | | 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>
| * Merge tag 'v3.14-rc6' into drm-intel-next-queuedDaniel Vetter2014-03-10
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | drm: Replace crtc fb with primary plane fb (v3)Matt Roper2014-04-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now that CRTC's have a primary plane, there's no need to track the framebuffer in the CRTC. Replace all references to the CRTC fb with the primary plane's fb. This patch was generated by the Coccinelle semantic patching tool using the following rules: @@ struct drm_crtc C; @@ - (C).fb + C.primary->fb @@ struct drm_crtc *C; @@ - (C)->fb + C->primary->fb v3: Generate patch via coccinelle. Actual removal of crtc->fb has been moved to a subsequent patch. v2: Fixup several lingering crtc->fb instances that were missed in the first patch iteration. [Rob Clark] Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Rob Clark <robdclark@gmail.com>
* | | drm/i915: Restrict plane loops to only operate on overlay planes (v2)Matt Roper2014-04-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Ensure that existing driver loops over all planes do not change behavior when we begin adding new types of planes (primary and cursor) to the DRM plane list in future patches. v2: Switch to using drm_for_each_legacy_plane() Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org> Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
* | | Merge tag 'v3.14-rc7' into drm-nextDave Airlie2014-03-18
|\ \ \ | |/ / |/| / | |/ | | | | Linux 3.14-rc7 Backmerge to help out Intel guys.
| * drm/i915: vlv: reserve GT power context earlyImre Deak2014-03-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | We reserve the space for the power context in stolen memory at a fixed address from a delayed work. This races with the subsequent driver init/resume code which could allocate something at that address, so the reservation for the power context fails. Reserve the space up-front, so this can't happen. This also adds a missing struct_mutex lock around the stolen allocation, which wasn't taken in the delayed work path. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: stable@vger.kernel.org Signed-off-by: Jani Nikula <jani.nikula@intel.com>
* | drm/i915: Avoid div by zero when pixel clock is largeVille Syrjälä2014-03-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | drm/i915: power domains: add vlv power wellsImre Deak2014-03-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | drm/i915: sanity check power well sw state against hw stateImre Deak2014-03-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | drm/i915: factor out reset_vblank_counterImre Deak2014-03-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | drm/i915: add port power domainsImre Deak2014-03-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | drm/i915: add noop power well handlers instead of NULL checking themImre Deak2014-03-07
| | | | | | | | | | | | | | | | | | 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>
* | drm/i915: split power well 'set' handler to separate enable/disable/sync_hwImre Deak2014-03-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | drm/i915: add init power domain to always-on power wellsImre Deak2014-03-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | drm/i915: move power domain macros to intel_pm.cImre Deak2014-03-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | drm/i915: fold in __intel_power_well_get/put functionsImre Deak2014-03-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | drm/i915: Unify CHICKEN_PIPESL_1 register definitionsVille Syrjälä2014-03-05
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* | drm/i915: Use RMW to update chicken bits in gen7_enable_fbc()Ville Syrjälä2014-03-05
| | | | | | | | | | | | | | | | | | | | | | 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>
* | drm/i915: Don't clobber CHICKEN_PIPESL_1 on BDWVille Syrjälä2014-03-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | drm/i915: Replace a few for_each_pipe(i) by for_each_pipe(pipe)Damien Lespiau2014-03-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Consistency throughout the code base is good and remove some room for mistakes (as explained in the "drm/i915: Use a pipe variable to cycle through the pipes" commit) So, let's replace the for_each_pipe(i) occurences by for_each_pipe(pipe) when it's reasonable and practical to do so (eg. when there isn't another pipe variable already). Suggested-by: Chris Wilson <chris@chris-wilson.co.uk> 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/i915: Implement WaDisableSDEUnitClockGating:bdwVille Syrjälä2014-03-05
| | | | | | | | | | | | Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: Disable semaphore wait event idle message on BDWVille Syrjälä2014-03-05
| | | | | | | | | | | | | | | | | | According to BSpec we need to always set this magic bit in ring buffer mode. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: Add thread stall DOP clock gating workaround on Broadwell.Kenneth Graunke2014-03-05
| | | | | | | | | | | | | | | | | | | | | | Ben and I believe this will be necessary on production hardware. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> [danvet: Shuffle lines to group all ROW_CHICKEN writes and add a cautious comment that this might not be needed on production hw.] Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: Add a partial instruction shootdown workaround on Broadwell.Kenneth Graunke2014-03-05
| | | | | | | | | | | | | | | | | | | | | | I believe this will be necessary on production hardware. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> [danvet: Fix whitespace fail spotted by checkpatch. Also add missing :bdw w/a tag that Ville spotted.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: kill dev_priv->pc8.gpu_idlePaulo Zanoni2014-03-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since the addition of dev_priv->mm.busy, there's no more need for dev_priv->pc8.gpu_idle, so kill it. Notice that when you remove gpu_idle, hsw_package_c8_gpu_idle and hsw_package_c8_gpu_busy become identical to hsw_enable_package_c8 and hsw_disable_package_c8, so just use them. Also, when we boot the machine, dev_priv->mm.busy initially considers the machine as idle. This is opposed to dev_priv->pc8.gpu_idle, which considered it busy. So dev_priv->pc8.disable_count has to be initalized to 1 now. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
generated by cgit v1.2.2 (git 2.25.0) at 2025-08-09 03:07:34 -0400