summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/i915/intel_pm.c
Commit message (Collapse)AuthorAgeFilesLines
* drm/i915: Make pin count per VMABen Widawsky2013-12-181-3/+3
| | | | | Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* Merge tag 'v3.13-rc3' into drm-intel-next-queuedDaniel Vetter2013-12-091-2/+2
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Linux 3.13-rc3 I need a backmerge for two reasons: - For merging the ppgtt patches from Ben I need to pull in the bdw support. - We now have duplicated calls to intel_uncore_forcewake_reset in the setup code to due 2 different patches merged into -next and 3.13. The conflict is silen so I need the merge to be able to apply Deepak's fixup patch. Conflicts: drivers/gpu/drm/i915/intel_display.c Trivial conflict, it doesn't even show up in the merge diff. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Fix gen3 self-refresh watermarksDaniel Vetter2013-11-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This regression has been introduced in commit 4fe8590a921d0b2e36e542dbfa89a8c5993f5a3f Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Wed Sep 4 18:25:22 2013 +0300 drm/i915: Use adjusted_mode appropriately when computing watermarks I guess we should renable the enabled local variable into something a notch more descriptive, but that's something for -next. The effect on my i945gme netbook is pretty severe amounts of underruns - usually the very first pixel gets used for the entire screeen. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * Partially revert "drm/i915: tune the RC6 threshold for stability"Daniel Vetter2013-11-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 351aa5666d02062b52329bcfe4bcf9d1f882fba9. It breaks rc6 on at least one snb machine. Since we don't yet have a report for ivb let's keep it there for now. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71656 Cc: Stéphane Marchesin <marcheu@chromium.org> Cc: erik@vontaene.de Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: Reorganize FBC function pointer initializaitionVille Syrjälä2013-12-041-9/+7Star
| | | | | | | | | | | | | | | | | | Initialize the FBC vfuncs on gen2 and gen3 chipsets. Also make a clean split for gen7+ vs. gen5+ vfunc initialization. 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>
* | drm/i915: Fix FBC1 plane checks for gen2Ville Syrjälä2013-12-041-3/+3
| | | | | | | | | | | | | | | | | | On gen2 and gen3 chipsets FBC is supported only on plane A. Fix (and simplify) the plane checks in intel_update_fbc() accordingly. 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>
* | drm/i915: add intel_display_power_enabled_sw() for use in atomic ctxImre Deak2013-11-281-8/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Atm we call intel_display_power_enabled() from i915_capture_error_state() in IRQ context and then take a mutex. To fix this add a new intel_display_power_enabled_sw() which returns the domain state based on software tracking as opposed to reading the actual HW state. Since we use domain_use_count for this without locking on the reader side make sure we increase the counter only after enabling all required power wells and decrease it before disabling any of these power wells. Regression introduced in commit 1b02383464b4a915627ef3b8fd0ad7f07168c54c Author: Imre Deak <imre.deak@intel.com> Date:   Tue Sep 24 16:17:09 2013 +0300     drm/i915: support for multiple power wells Note that atm we depend on the value returned by intel_display_power_enabled_sw() in i915_capture_error_state() to avoid unclaimed register access reports. This was never guaranteed though, since another thread can disable the power concurrently. If this is a problem we need another explicit way to disable the reporting during error captures. v2: - remove barriers as the caller can't depend on the value returned from i915_capture_error_state_sw() anyway (Ville) - dump the state of pipe/transcoder power domain state (Daniel) Reported-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915/vlv: use parallel context restore when coming out of RC6Jesse Barnes2013-11-281-1/+1
| | | | | | | | | | | | | | | | | | | | Setting this bit restores all ring contexts in parallel rather than serially. Matches current BWG recommendations. Tested-by: "Meng, Mengmeng" <mengmeng.meng@intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Deepak S <deepak.s@inel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915/vlv: use a lower RC6 timeout on VLVJesse Barnes2013-11-281-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | We use timeout mode, and we need to lower the timeout to get good RC6 residency when loads are running. This gets me from 0% residency during glxgears to 77%, which is a pretty good improvement. This value also matches the current BWG recommentations. Tested-by: "Meng, Mengmeng" <mengmeng.meng@intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Deepak S <deepak.s@inel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915/vlv: Valleyview support for forcewake Individual power wells.Deepak S2013-11-281-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Split vlv force wake routines to help individually control Media/Render well based on the register access. We've seen power savings in the lower sub-1W range on workloads that only need on of the power wells, e.g. glbenchmark, media playback Note: The same split isn't there for the forcewake queue, only the forcwake domains are split. Signed-off-by: Deepak S <deepak.s@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> [danvet: Rebase on top of the removed forcewake hack in the ring irq get/put code and add a note to add Deepak's answer to Chris question.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: Add power well arguments to force wake routines.Deepak S2013-11-281-8/+11
| | | | | | | | | | | | | | | | | | | | | | | | Added power well arguments to all the force wake routines to help us individually control power well based on the scenario. Signed-off-by: Deepak S <deepak.s@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> [danvet: Resolve conflict with the removed forcewake hack and drop one spurious hunk Jesse noticed.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: add a debugfs entry for power domain infoImre Deak2013-11-261-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a debugfs entry showing the use-count for all power domains of each power well. v3: address comments from Paulo: - simplify power_domain_str() by using a switch table - move power_well::domain_count to power_domains - WARN_ON decrementing a 0 refcount Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Paulo Zanoni <paulo.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: add a default always-on power wellImre Deak2013-11-261-19/+9Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | So far we distinguished platforms without a dynamic power well with the HAS_POWER_WELL macro and for such platforms we didn't call any power domain functions. Instead of doing this check we can add an always-on power well for these platforms and call the power domain functions unconditionally. For always-on power wells we only increase/decrease their refcounts, otherwise they are nop. This makes high level driver code more readable and as a bonus provides some idea of the current power domains state for all platforms (once the relevant debugfs entry is added). v3: rename intel_power_wells to i9xx_always_on_power_well (Paulo) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Paulo Zanoni <paulo.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: don't do BDW/HSW specific powerdomains init on other platformsImre Deak2013-11-261-0/+3
| | | | | | | | | | | | Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Paulo Zanoni <paulo.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: add always-on power wells instead of special casing themImre Deak2013-11-261-28/+13Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of using a separate function to check whether a power domain is is always on, add an always-on power well covering all these power domains and do the usual get/put on these unconditionally. Since we don't assign a .set handler for these the get/put won't have any effect besides the adjusted refcount. This makes the code more readable and provides debug info also on the use of always-on power wells (once the relevant debugfs entry is added.) v3: make is_always_on to be bool instead of a bit field (Paulo) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Paulo Zanoni <paulo.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: support for multiple power wellsImre Deak2013-11-261-17/+99
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | HW generations so far had only one always-on power well and optionally one dynamic power well. Upcoming HW gens may have multiple dynamic power wells, so add some infrastructure to support them. The idea is to keep the existing power domain API used by the rest of the driver and create a mapping between these power domains and the underlying power wells. This mapping can differ from one HW to another but high level driver code doesn't need to know about this. Through the existing get/put API it would just ask for a given power domain and the power domain framework would make sure the relevant power wells get enabled in the right order. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Paulo Zanoni <paulo.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: add audio power domainImre Deak2013-11-261-8/+2Star
| | | | | | | | | | | | | | | | | | This way the code is simpler and can also be used for other platforms where the audio power domain->power well mapping is different. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Paulo Zanoni <paulo.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: Don't set the fence number in DPFC_CTL on SNBVille Syrjälä2013-11-251-1/+3
| | | | | | | | | | | | | | | | | | | | | | SNB has another register where the actual FBC CPU fence number is stored. The documenation explicitly states that the fence number in DPFC_CTL must be 0 on SNB. And in fact when it's not zero, the GTT tracking simply doesn't work. 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>
* | drm/i915: Use plane_name() in gen7_enable_fbc()Ville Syrjälä2013-11-211-1/+1
| | | | | | | | | | | | | | | | | | All the other .enable_fbc() funcs use plane_name(). Make gen7_enable_fbc() do the same. 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>
* | Merge branch 'backlight-rework' into drm-intel-next-queuedDaniel Vetter2013-11-151-13/+169
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull in Jani's backlight rework branch. This was merged through a separate branch to be able to sort out the Broadwell conflicts properly before pulling it into the main development branch. Conflicts: drivers/gpu/drm/i915/intel_display.c Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915/bdw: PIPE_[BC] I[ME]R moved to powerwellBen Widawsky2013-11-141-1/+17
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The pipe B and pipe C interrupt mask and enable registers are now part of the pipe, so disabling the pipe power wells will lost the contests of the registers. Art totally debugged this one! v2: Use the irq_lock to clarify code, and prevent future bugs (Daniel) Cc: Art Runyan <arthur.j.runyan@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> [danvet: Make sparse happy.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915/bdw: WaSingleSubspanDispatchOnAALinesAndPointsBen Widawsky2013-11-081-0/+3
| | | | | | | | | | | | | | | | | | Implement WaSingleSubspanDispatchOnAALinesAndPoints BDW-A workaround. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915/bdw: conservative SBE VUE cache modeBen Widawsky2013-11-081-0/+3
| | | | | | | | | | | | | | | | | | Hold vertex data in cache until last reference BDW-A workaround Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915/bdw: Limit SDE poly depth FIFO to 2Ben Widawsky2013-11-081-0/+3
| | | | | | | | | | | | | | | | | | BDW-A workaround BDW Bug #1899155 Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915/bdw: Sampler power bypass disableBen Widawsky2013-11-081-0/+2
| | | | | | | | | | | | | | | | | | BDW-A workaround. BDW Bug #1899812 Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * ddrm/i915/bdw: Disable centroid pixel perf optimizationBen Widawsky2013-11-081-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | BDW-A workaround BDW Bug #1899532 v2: WARN on when not using preliminary HW support Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Jesse Barnes <jbarnes@virtuosugeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915/bdw: BWGTLB clock gate disableBen Widawsky2013-11-081-0/+2
| | | | | | | | | | | | Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Jesse Barnes <jbarnes@virtuosugeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915/bdw: Implement edp PSR workaroundsBen Widawsky2013-11-081-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This implements a workaround for PSR dealing with some vblank issue. WaPsrDPAMaskVBlankInSRD && WaPsrDPRSUnmaskVBlankInSRD v2: forgot to git add bogus whitespace fix v3: Update with workaround names. Use for_each_pipe() and CHICKEN_PIPESL_1(pipe) macro (Ville) Cc: Art Runyan <arthur.j.runyan@intel.com> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Jesse Barnes <jbarnes@virtuosugeek.org> [danvet: Kill redundant IS_BDW check and remove the copious amount of uneeded lines added.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915/bdw: Create a separate BDW rps enableBen Widawsky2013-11-081-0/+75
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is mostly what we have for HSW with the exceptions of: no writes: GEN6_RC1_WAKE_RATE_LIMIT GEN6_RC6pp_WAKE_RATE_LIMIT GEN6_RC1e_THRESHOLD GEN6_RC6p_THRESHOLD GEN6_RC6pp_THRESHOLD GEN6_RP_DOWN_TIMEOUT - use 1s instead of 1.28s Don't try to overclock, or program ring/IA frequency tables since we don't quite have sufficient docs yet. NOTE: These values do not reflect the changes made recently by Chris. Since we have no evidence yet what the proper way to tweak for this platform is, I think it is good to go, and can be optimized by Chris, or whomever, later. Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> [danvet: Drop spurious hunk and drop TODO - having per-platform rps register frobbing code is in my opinion preferred, now that all the infrastructure functions are extracted.] Reviewed-by: Jesse Barnes <jbarnes@virtuosugeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915/bdw: Use HSW formula for ring freq scalingBen Widawsky2013-11-081-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current formula we use for HSW is not what is in current docs. However, changing to the HSW formula on my HSW does not improve power usage, and decreases performance by about 5% in limited xonotic testing. For gen8, until we know otherwise, or run experiments, let's use the HSW formula - which should be the same used in the Windows driver (and thus help make an apples-applies comparison) on gen8. v2: Use >= 8 instead of > 7 to be consistent with all other gen checks. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> (v1) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915/bdw: Add Broadwell display FIFO limitsVille Syrjälä2013-11-081-9/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | Broadwell has bigger display FIFOs than Haswell. Otherwise the two are very similar. v2: Fix FBC WM_LP shift for BDW v3: Rebase on top of the big Haswell wm rework. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v2) Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915/bdw: Implement WaSwitchSolVfFArbitrationPriorityBen Widawsky2013-11-081-0/+6
| | | | | | | | | | | | | | | | GEN8 also needs this workaround. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> [danvet: Add a generic comment that we need to recheck all these w/a.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915/bdw: Broadwell also has the "power down well"Paulo Zanoni2013-11-081-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Just like Haswell, but with the small twist that the panel fitter for pipe A is now also in the always-on power well. v2: Use the new HAS_POWER_WELL macro. v3: Rebase on top of intel_using_power_well patches. v4: This time actually update the PFIT check correctly so that the pipe A pfit is in the always-on domain. v5: Rebase on top of the VGA power domain addition. v6: Rebase on top of the new power domain infrastructure. Also pimp the commit message a bit while at it. v7: Use IS_BROADWELL instead of IS_GEN8 (Ville). Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> (v1) Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915/bdw: Clock gating initBen Widawsky2013-11-081-0/+11
| | | | | | | | | | | | | | | | | | | | Clock gating init is really a catch all function for registers we need to write early in loading the driver. Atm just the bare metal stuff we need, more will surely come. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: Kill vlv_update_rps_cur_delay()Ville Syrjälä2013-11-071-27/+0Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Polling to make sure the current GPU frequency matches the last requested frequency should not be necessay, and if there's some throttling involved, the two might not match anyway. Since we're still seeing this trigger occasionally, and it just introduces a rather pointless 10 ms delay, it seems like better to kill it off. 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>
* | drm/i915: Initialise min/max frequencies before updating RPS registersChris Wilson2013-11-071-14/+5Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The RPS register writing routines use the current value of min/max to set certain limits and interrupt gating. If we set those afterwards, we risk setting up the hw incorrectly and losing power management events, and worse, trigger some internal assertions. Reorder the calling sequences to be correct, and remove the then unrequired clamping from inside set_rps(). And for a bonus, fix the bug of calling gen6_set_rps() from Valleyview. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> CC: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915/vlv: Workaround a punit issue in DDR data rate for 1333.Chon Ming Lee2013-11-071-6/+1Star
| | | | | | | | | | | | | | | | | | | | | | | | For DDR data rate reporting by Punit in PUNIT_GPU_FREQ_STS, the actual data encoding is 00b=800, 01b=1066, 10b=1333, 11b=1333. Some premium VLV sku will get the DDR_DATA_RATE set as 11. As a result, the turbo frequency reporting will be incorrect without this workaround. Signed-off-by: Chon Ming Lee <chon.ming.lee@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: Pass dev_priv to vlv_gpu_freq() and vlv_freq_opcode()Ville Syrjälä2013-11-061-22/+16Star
| | | | | | | | | | | | | | | | | | We'll be looking at more than just mem_freq from dev_priv, so just pass the whole thing. 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>
* | drm/i915: Improve vlv_gpu_freq() and vlv_freq_opcode()Ville Syrjälä2013-11-061-23/+12Star
| | | | | | | | | | | | | | | | | | | | | | We're currently miscalculating the VLV graphics clock a little bit. This is caused by rounding the step to integer MHz, which does not match reality. Change the formula to match the GUnit HAS to give more accurate answers. 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>
* | drm/i915/vlv: fixup DDR freq detection per Punit specJesse Barnes2013-11-051-3/+10
| | | | | | | | | | | | | | | | | | | | Either the docs were wrong or the values have changed since the old days before we had wheels. Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: move VLV DDR freq fetch into init_clock_gatingJesse Barnes2013-11-051-13/+18
|/ | | | | | | We don't want it delayed with the RPS work. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* Merge tag 'v3.12' into drm-intel-nextDaniel Vetter2013-11-041-1/+8
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I want to merge in the new Broadwell support as a late hw enabling pull request. But since the internal branch was based upon our drm-intel-nightly integration branch I need to resolve all the oustanding conflicts in drm/i915 with a backmerge to make the 60+ patches apply properly. We'll propably have some fun because Linus will come up with a slightly different merge solution. Conflicts: drivers/gpu/drm/i915/i915_dma.c drivers/gpu/drm/i915/i915_drv.c drivers/gpu/drm/i915/intel_crt.c drivers/gpu/drm/i915/intel_ddi.c drivers/gpu/drm/i915/intel_display.c drivers/gpu/drm/i915/intel_dp.c drivers/gpu/drm/i915/intel_drv.h All rather simple adjacent lines changed or partial backports from -next to -fixes, with the exception of the thaw code in i915_dma.c. That one needed a bit of shuffling to restore the intent. Oh and the massive header file reordering in intel_drv.h is a bit trouble. But not much. v2: Also don't forget the fixup for the silent conflict that results in compile fail ... Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: disable LVDS clock gating on CPT v2Jesse Barnes2013-10-151-1/+3
| | | | | | | | | | | | | | | | | | | | | | Needed to prevent display corruption in high res panels. v2: use correct unit names (Rodrigo) Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Tested-by: Ulrich Drepper <drepper@gmail.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915/hsw: Disable L3 caching of atomic memory operations.Francisco Jerez2013-10-031-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Otherwise using any atomic memory operation will lock up the GPU due to a Haswell hardware bug. v2: Use the _MASKED_BIT_ENABLE macro. Drop drm parameter definition. Signed-off-by: Francisco Jerez <currojerez@riseup.net> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: <stable@vger.kernel.org> [danvet: Fix checkpatch fail.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: fix rps.vlv_work initializationImre Deak2013-10-011-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | During driver loading we are initializing rps.vlv_work in valleyview_enable_rps() via the rps.delayed_resume_work delayed work. This is too late since we are using vlv_work already via i915_driver_load()->intel_uncore_sanitize()-> intel_disable_gt_powersave(). This at least leads to the following kernel warning: INFO: trying to register non-static key. the code is fine but needs lockdep annotation. turning off the locking correctness validator. Fix this by initialzing vlv_work before we call intel_uncore_sanitize(). The regression was introduced in commit 7dcd2677ea912573d9ed4bcd629b0023b2d11505 Author: Konstantin Khlebnikov <khlebnikov@openvz.org> Date: Wed Jul 17 10:22:58 2013 +0400 drm/i915: fix long-standing SNB regression in power consumption after resume though there was no good reason to initialize the static vlv_work from another delayed work to begin with (especially since this will happen multiple times). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=69397 Tested-by: shui yangwei <yangweix.shui@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: add back checking for i915_disable_power_wellImre Deak2013-10-311-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In commit 6efdf354ddb186c6604d1692075421e8d2c740e9 Author: Imre Deak <imre.deak@intel.com> Date: Wed Oct 16 17:25:52 2013 +0300 the check for i915_disable_power_well flag was removed by overlook, so add it back now. Reported-by: Paulo Zanoni <paulo.zanoni@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: rename i915_init_power_well to init_power_domains_initImre Deak2013-10-291-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Similarly rename the other related functions in the power domain interface. Higher level driver code calling these functions knows only about power domains, not the underlying power wells which may be different on different platforms. Also these functions really init/cleanup/resume power domains and only through that all related power wells, so rename them accordingly. Note that I left i915_{request,release}_power_well as is, since that really changes the state only of a single power well (and is HSW specific). It should also get a better name once we make it more generic by controlling things through a new audio power domain. v4: - use intel prefix instead of i915 everywhere (Paulo) - use a $prefix_$block_$action format (Daniel) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: remove device field from struct power_wellImre Deak2013-10-271-9/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | The only real need for this field was in i915_{request,release}_power_well, but there we can get at it by a container_of magic. Also since in the future we'll have multiple power wells each with its own power_well struct it makes sense to remove the field from there where it'd be just redundancy. Suggested-by: Paulo Zanoni <paulo.zanoni@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: use power get/put instead of set for power on after initImre Deak2013-10-271-36/+1Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently we make sure that all power domains are enabled during driver init and turn off unneded ones only after the first modeset. Similarly during suspend we enable all power domains, which will remain on through the following resume until the first modeset. This logic is supported by intel_set_power_well() in the power domain framework. It would be nice to simplify the API, so that we only have get/put functions and make it more explicit on the higher level how this "power well on during init" logic works. This will make it also easier if in the future we want to shorten the time the power wells are on. For this add a new device private flag tracking whether we have the power wells on because of init/suspend and use only intel_display_power_get()/put(). As nothing else uses intel_set_power_well() we can remove it. This also fixes commit 6efdf354ddb186c6604d1692075421e8d2c740e9 Author: Imre Deak <imre.deak@intel.com> Date: Wed Oct 16 17:25:52 2013 +0300 drm/i915: enable only the needed power domains during modeset where removing intel_set_power_well() resulted in not releasing the reference on the power well that was taken during init and thus leaving the power well on all the time. Regression reported by Paulo. v2: - move the init_power_on flag to the power_domains struct (Daniel) v3: - add note about this being a regression fix too (Paulo) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: prepare for multiple power wellsImre Deak2013-10-271-21/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | In the future we'll need to support multiple power wells, so prepare for that here. Create a new power domains struct which contains all power domain/well specific fields. Since we'll have one lock protecting all power wells, move power_well->lock to the new struct too. No functional change. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Paulo Zanoni <paulo.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
generated by cgit v1.2.3-55-g7522 (git 2.39.0) at 2024-07-08 15:21:24 +0200