summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/i915/intel_pm.c
AgeCommit message (Collapse)AuthorFilesLines
2013-11-20drm/i915: Fix gen3 self-refresh watermarksDaniel Vetter1-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>
2013-11-16Partially revert "drm/i915: tune the RC6 threshold for stability"Daniel Vetter1-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>
2013-11-08drm/i915/bdw: WaSingleSubspanDispatchOnAALinesAndPointsBen Widawsky1-0/+3
Implement WaSingleSubspanDispatchOnAALinesAndPoints BDW-A workaround. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-11-08drm/i915/bdw: conservative SBE VUE cache modeBen Widawsky1-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>
2013-11-08drm/i915/bdw: Limit SDE poly depth FIFO to 2Ben Widawsky1-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>
2013-11-08drm/i915/bdw: Sampler power bypass disableBen Widawsky1-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>
2013-11-08ddrm/i915/bdw: Disable centroid pixel perf optimizationBen Widawsky1-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>
2013-11-08drm/i915/bdw: BWGTLB clock gate disableBen Widawsky1-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>
2013-11-08drm/i915/bdw: Implement edp PSR workaroundsBen Widawsky1-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>
2013-11-08drm/i915/bdw: Create a separate BDW rps enableBen Widawsky1-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>
2013-11-08drm/i915/bdw: Use HSW formula for ring freq scalingBen Widawsky1-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>
2013-11-08drm/i915/bdw: Add Broadwell display FIFO limitsVille Syrjälä1-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>
2013-11-08drm/i915/bdw: Implement WaSwitchSolVfFArbitrationPriorityBen Widawsky1-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>
2013-11-08drm/i915/bdw: Broadwell also has the "power down well"Paulo Zanoni1-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>
2013-11-08drm/i915/bdw: Clock gating initBen Widawsky1-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>
2013-11-04Merge tag 'v3.12' into drm-intel-nextDaniel Vetter1-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>
2013-10-31drm/i915: add back checking for i915_disable_power_wellImre Deak1-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>
2013-10-29drm/i915: rename i915_init_power_well to init_power_domains_initImre Deak1-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>
2013-10-27drm/i915: remove device field from struct power_wellImre Deak1-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>
2013-10-27drm/i915: use power get/put instead of set for power on after initImre Deak1-36/+1
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>
2013-10-27drm/i915: prepare for multiple power wellsImre Deak1-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>
2013-10-27drm/i915: Remove WaFbcDisableDpfcClockGating on HSWBen Widawsky1-10/+0
Production HSW does not need it. I confirmed this with Art. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-10-27drm/i915: Remove WaFbcDisableDpfcClockGating on IVBBen Widawsky1-10/+0
Production IVB does not need it. I confirmed this with Art. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-10-27drm/i915: Convert straggling MCHBAR registersBen Widawsky1-1/+1
All our registers which are written through the MCHBAR are defined descriptively as an offset to the MCHBAR. We had 3 outliers here. Convert these as well so all registers which are offsets are MCHBAR can be easily identified/found within the code. With this, convert DCLK to also follow this format. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-10-21drm/i915: change power_well->lock to be mutexImre Deak1-13/+13
There is no hard need for this to be a spin lock, as we don't take these locks in irq context from anywhere. An upcoming patch will add calls to punit read/write functions from within regions protected by this lock and those functions need a mutex in turn. As a solution for that convert the spin lock to be a mutex. 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>
2013-10-21drm/i915: factor out is_always_on_domainImre Deak1-54/+30
It is just cleaner this way and makes it easier to add support for other HW generations with always-on power wells powering a different set of domains. 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>
2013-10-21drm/i915: Print RC6 info less oftenBen Widawsky1-11/+43
Since we use intel_enable_rc6() now for more than just when we're enabling RC6, we'll see this message many times, and it is just confusing. As an example, calc_residency calls this function whenever poked via sysfs. This leaves the impression in dmesg that we're constantly re-enabling RC6. While at it, move the defines and description from drv.h to intel_pm.c, since these are only ever used in that code. 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>
2013-10-15drm/i915: Check 5/6 DDB split only when sprites are enabledVille Syrjälä1-1/+2
Using the 5/6 DDB split make sense only when sprites are enabled. So check that before we waste any cycles computing the merged watermarks with the 5/6 DDB split. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-10-15drm/i915: Rename ilk_check_wm to ilk_validate_wm_levelVille Syrjälä1-5/+5
Makes the behaviour of the function more clear. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-10-15drm/i915: Rename ilk_wm_max to ilk_compute_wm_maximumsVille Syrjälä1-8/+8
Makes the intention more clear. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-10-15drm/i915: Remove a somewhat silly debug print from watermark codeVille Syrjälä1-2/+0
This debug print just adds overhead to the watermark merging process, and doesn't really give enough information to be useful. Just kill and let's add something much better a bit later. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-10-15drm/i915: Init HSW watermark tracking in intel_modeset_setup_hw_state()Ville Syrjälä1-26/+76
Fill out the HSW watermark s/w tracking structures with the current hardware state in intel_modeset_setup_hw_state(). This allows us to skip the HW state readback during watermark programming and just use the values we keep around in dev_priv->wm. Reduces the overhead of the watermark programming quite a bit. v2: s/init_wm/wm_get_hw_state Remove stale comment about sprites Make DDB partitioning readout safer Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> [danvet: Fix whitespace fail.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-10-15drm/i915: Improve watermark dirtyness checksVille Syrjälä1-18/+80
Currently hsw_write_vm_values() may write to certain watermark registers needlessly. For instance if only, say, LP3 changes, the current code will again disable all LP1+ watermarks even though only LP3 needs to be reconfigured. Add an easy to read function that will compute the dirtyness of the watermarks, and use that information to further optimize the watermark programming. v2: Disable LP1+ watermarks around changing LP0 watermarks for Paulo Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-10-15drm/i915: Store current watermark state in dev_priv->wmVille Syrjälä1-31/+15
To make it easier to check what watermark updates are actually necessary, keep copies of the relevant bits that match the current hardware state. Also add DDB partitioning into hsw_wm_values as that's another piece of state we want to track. We don't read out the hardware state on init yet, so we can't really start using this yet, but it will be used later. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> [danvet: Paulo asked for a comment around the memcmp to say that we depend upon zero-initializing the entire structures due to padding. But a later patch in this series removes the memcmp again. So this is ok as-is.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-10-15drm/i915: Kill fbc_wm_enabled from intel_wm_configVille Syrjälä1-1/+0
The fbc_wm_enabled member in intel_wm_config is useless for the time being. The original idea for it was that we'd pre-compute it and so that the WM merging process could know whether it needs to worry about FBC watermarks at all. But we don't have a convenient way to pre-check for the possibility of FBC being used. intel_update_fbc() should be split up for that. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-10-15drm/i915: Refactor wm_lp to level calculationVille Syrjälä1-1/+7
On HSW the LP1,LP2,LP3 levels are either 1,2,3 or 1,3,4. We make the conversion from LPn to to the level at one point current. Later we're going to do it in a few places, so move it to a separate function. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-10-15drm/i915: Check 5/6 DDB split only when sprites are enabledVille Syrjälä1-1/+1
Using the 5/6 DDB split make sense only when sprites are enabled. So check that before we waste any cycles computing the merged watermarks with the 5/6 DDB split. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-10-15drm/i915: Move some computations out from hsw_compute_wm_parameters()Ville Syrjälä1-19/+14
Move the watermark max computations into haswell_update_wm(). This allows keeping the 1/2 vs. 5/6 split code in one place, and avoid having to pass around so many things. We also save a bit of stack space by only requiring one copy of struct hsw_wm_maximums. Also move the intel_wm_config out from hsw_compute_wm_parameters() and pass it it. We'll have some need for it in haswell_update_wm() later. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-10-15drm/i915: Use intel_pipe_wm in hsw_find_best_resultsVille Syrjälä1-21/+21
Let's try to keep using the intermediate intel_pipe_wm representation for as long as possible. It avoids subtle knowledge about the internals of the hardware registers when trying to choose the best watermark configuration. While at it replace the memset() w/ zero initialization. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-10-15drm/i915: Move LP1+ watermark merging out from hsw_compute_wm_results()Ville Syrjälä1-9/+10
I want to convert hsw_find_best_result() to use intel_pipe_wm, so we need to move the merging to happen outside hsw_compute_wm_results(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-10-15drm/i915: Don't re-compute pipe watermarks except for the affected pipeVille Syrjälä1-39/+28
No point in re-computing the watermarks for all pipes, when only one pipe has changed. The watermarks stored under intel_crtc.wm.active are still valid for the other pipes. We just need to redo the merging. We can also skip the merge/update procedure completely if the new watermarks for the affected pipe come out unchanged. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-10-15drm/i915: Add intel_pipe_wm and prepare for watermark pre-computeVille Syrjälä1-76/+116
Introduce a new struct intel_pipe_wm which contains all the watermarks for a single pipe. Use it to unify the LP0 and LP1+ watermark computations so that we can just iterate through the watermark levels neatly and call ilk_compute_wm_level() for each. Also add another tool ilk_wm_merge() that merges the LP1+ watermarks from all pipes. For that, embed one intel_pipe_wm inside intel_crtc that contains the currently valid watermarks for each pipe. This is mainly preparatory work for pre-computing the watermarks for each pipe and merging them at a later time. For now the merging still happens immediately. v2: Add some comments about level 0 DDB split and intel_wm_config Add WARN_ON for level 0 being disabled s/lp_wm/merged Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-10-15drm/i915: disable LVDS clock gating on CPT v2Jesse Barnes1-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>
2013-10-11drm/i915: Avoid tweaking RPS before it is enabledChris Wilson1-10/+16
As we delay the initial RPS enabling (upon boot and after resume), there is a chance that we may start to render and trigger RPS boosts before we set up the punit. Any changes we make could result in inconsistent hardware state, with a danger of causing undefined behaviour. However, as the boosting is a optional tweak to RPS, we can simply ignore it whilst RPS is not yet enabled. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-10-10drm/i915: Rename primary_disabled to primary_enabledVille Syrjälä1-1/+1
Let's try to avoid these confusing negated booleans. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-10-10drm/i915: Use the real cpu max frequency for ring scalingBen Widawsky1-6/+11
The policy's max frequency is not equal to the CPU's max frequency. The ring frequency is derived from the CPU frequency, and not the policy frequency. One example of how this may differ through sysfs. If the sysfs max frequency is modified, that will be used for the max ring frequency calculation. (/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq). As far as I know, no current governor uses anything but max as the default, but in theory, they could. Similarly distributions might set policy as part of their init process. It's ideal to use the real frequency because when we're currently scaled up on the GPU. In this case we likely want to race to idle, and using a less than max ring frequency is non-optimal for this situation. AFAIK, this patch should have no impact on a majority of people. This behavior hasn't been changed since it was first introduced: commit 23b2f8bb92feb83127679c53633def32d3108e70 Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Tue Jun 28 13:04:16 2011 -0700 drm/i915: load a ring frequency scaling table v3 CC: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-10-10drm/i915: Rename intel_flush_display_plane to intel_flush_primary_planeVille Syrjälä1-1/+1
The intel_flush_primary_plane name actually tells us which plane we're talking about. Also reorganize the internals a bit and add a missing POSTING_READ() to make sure the hardware has seen the changes by the time we return from the function. 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>
2013-10-10Merge remote-tracking branch 'airlied/drm-next' into drm-intel-nextDaniel Vetter1-1/+1
The conflict in intel_drv.h tripped me up a bit since a patch in dinq moves all the functions around, but another one in drm-next removes a single function. So I'ev figured backing this into a backmerge would be good. i915_dma.c is just adjacent lines changed, nothing nefarious there. Conflicts: drivers/gpu/drm/i915/i915_dma.c drivers/gpu/drm/i915/intel_drv.h Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-10-09drm: Collect per-crtc vblank stuff to a structVille Syrjälä1-1/+1
drm_vblank_init() is too ugly. Make it a bit easier on the eye by collecting all the per-crtc vblank counters, timestamps etc. to a structure and just allocate an array of those. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2013-10-03drm/i915: Tweak RPS thresholds to more aggressively downclockChris Wilson1-33/+104
After applying wait-boost we often find ourselves stuck at higher clocks than required. The current threshold value requires the GPU to be continuously and completely idle for 313ms before it is dropped by one bin. Conversely, we require the GPU to be busy for an average of 90% over a 84ms period before we upclock. So the current thresholds almost never downclock the GPU, and respond very slowly to sudden demands for more power. It is easy to observe that we currently lock into the wrong bin and both underperform in benchmarks and consume more power than optimal (just by repeating the task and measuring the different results). An alternative approach, as discussed in the bspec, is to use a continuous threshold for upclocking, and an average value for downclocking. This is good for quickly detecting and reacting to state changes within a frame, however it fails with the common throttling method of waiting upon the outstanding frame - at least it is difficult to choose a threshold that works well at 15,000fps and at 60fps. So continue to use average busy/idle loads to determine frequency change. v2: Use 3 power zones to keep frequencies low in steady-state mostly idle (e.g. scrolling, interactive 2D drawing), and frequencies high for demanding games. In between those end-states, we use a fast-reclocking algorithm to converge more quickly on the desired bin. v3: Bug fixes - make sure we reset adj after switching power zones. v4: Tune - drop the continuous busy thresholds as it prevents us from choosing the right frequency for glxgears style swap benchmarks. Instead the goal is to be able to find the right clocks irrespective of the wait-boost. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Kenneth Graunke <kenneth@whitecape.org> Cc: Stéphane Marchesin <stephane.marchesin@gmail.com> Cc: Owen Taylor <otaylor@redhat.com> Cc: "Meng, Mengmeng" <mengmeng.meng@intel.com> Cc: "Zhuang, Lena" <lena.zhuang@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
generated by cgit v1.2.3 (git 2.39.0) at 2025-08-03 15:38:18 +0300