aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/i915/intel_psr.c (follow)
AgeCommit message (Collapse)AuthorFilesLines
2015-11-18drm/i915: Reduce PSR re-activation time for VLV/CHV.Rodrigo Vivi1-2/+1
With 'commit 30886c5a ("drm/i915: VLV/CHV PSR: Increase wait delay time before active PSR.")' we fixed a blank screen when first activation was happening immediately after PSR being enabled. There we gave more time for idleness by increasing the delay between re-activating sequences. However, commit "drm/i915: Delay first PSR activation." delay the first activation in a better way keeping a good PSR residency. So, we can now reduce the delay on re-enable. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Durgadoss R <durgadoss.r@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-11-18drm/i915: Delay first PSR activation.Rodrigo Vivi1-2/+16
When debuging the frozen screen caused by HW tracking with low power state I noticed that if we keep moving the mouse non stop you will miss the screen updates for a while. At least until we stop moving the mouse for a small time and move again. The actual enabling should happen immediately after Display Port enabling sequence finished with links trained and everything enabled. However we face many issues when enabling PSR right after a modeset. On VLV/CHV we face blank screens on this scenario and on HSW+ we face a recoverable frozen screen, at least until next exit-activate sequence. Another workaround for the same issue here would be to increase re-enable idle time from 100 to 500 as we did for VLV/CHV. However this patch workaround this issue in a better way since it doesn't reduce PSR residency and also allow us to reduce the delay time between re-enables at least on VLV/CHV. This is also important to make the sysfs toggle working properly. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Durgadoss R <durgadoss.r@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-11-18drm/i915: Type safe register read/writeVille Syrjälä1-6/+6
Make I915_READ and I915_WRITE more type safe by wrapping the register offset in a struct. This should eliminate most of the fumbles we've had with misplaced parens. This only takes care of normal mmio registers. We could extend the idea to other register types and define each with its own struct. That way you wouldn't be able to accidentally pass the wrong thing to a specific register access function. The gpio_reg setup is probably the ugliest thing left. But I figure I'd just leave it for now, and wait for some divine inspiration to strike before making it nice. As for the generated code, it's actually a bit better sometimes. Eg. looking at i915_irq_handler(), we can see the following change: lea 0x70024(%rdx,%rax,1),%r9d mov $0x1,%edx - movslq %r9d,%r9 - mov %r9,%rsi - mov %r9,-0x58(%rbp) - callq *0xd8(%rbx) + mov %r9d,%esi + mov %r9d,-0x48(%rbp) callq *0xd8(%rbx) So previously gcc thought the register offset might be signed and decided to sign extend it, just in case. The rest appears to be mostly just minor shuffling of instructions. v2: i915_mmio_reg_{offset,equal,valid}() helpers added s/_REG/_MMIO/ in the register defines mo more switch statements left to worry about ring_emit stuff got sorted in a prep patch cmd parser, lrc context and w/a batch buildup also in prep patch vgpu stuff cleaned up and moved to a prep patch all other unrelated changes split out v3: Rebased due to BXT DSI/BLC, MOCS, etc. v4: Rebased due to churn, s/i915_mmio_reg_t/i915_reg_t/ Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1447853606-2751-1-git-send-email-ville.syrjala@linux.intel.com
2015-11-16drm/i915: Model PSR AUX register selection more like the normal AUX codeVille Syrjälä1-6/+21
v2: Split up the ctl vs. data reg handling like in the normal AUX code Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1447266856-30249-8-git-send-email-ville.syrjala@linux.intel.com
2015-11-16drm/i915: Add dev_priv->psr_mmio_baseVille Syrjälä1-12/+15
Drop the EDP_PSR_BASE() thing, and just stick the PSR register offset under dev_priv, like we for DSI and GPIO for example. TODO: could probably move a bunch of this kind of stuff into the device info instead... v2: Drop the spurious whitespace change (Jani) Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1447266856-30249-7-git-send-email-ville.syrjala@linux.intel.com
2015-11-16drm/i915: Parametrize AUX registersVille Syrjälä1-2/+3
v2: Keep some MISSING_CASE() stuff (Jani) s/-1/-PIPE_B/ in the register macro Fix typo in patch subject v3: Use PORT_B registers for invalid ports in g4x_aux_ctl_reg() (Jani) v4: Reorder patches (Chris) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> (v3) Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v3) Link: http://patchwork.freedesktop.org/patch/msgid/1447266856-30249-4-git-send-email-ville.syrjala@linux.intel.com
2015-10-13drm/i915: Parametrize HSW video DIP data registersVille Syrjälä1-8/+10
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>
2015-08-05drm/i915: VLV/CHV PSR: Increase wait delay time before active PSR.Rodrigo Vivi1-1/+2
Since active function on VLV immediately activate PSR let's give more time for idleness. Different from core platforms where we have idle_frames count. Also kms_psr_sink_crc now is automated and always get this: [drm:intel_enable_pipe] enabling pipe A [drm:intel_edp_backlight_on] [drm:intel_panel_enable_backlight] pipe [drm:intel_panel_enable_backlight] pipe A [drm:intel_panel_actually_set_backlight] set backlight PWM = 7812 PSR gets enabled somewhere here after backlight. [drm:intel_get_hpd_pins] hotplug event received, stat 0x00000000, dig 0x0 [drm:vlv_pipe_set_fifo_size] Pipe A FIFO split 511 / 511 / 511 [drm:vlv_update_wm] Setting FIFO watermarks - A: plane=391, cursor=63, sp PSR gets flushed around here by intel_atomic_commit [drm:vlv_pipe_set_fifo_size] Pipe A FIFO split 511 / 511 / 511 [drm:vlv_update_wm] Setting FIFO watermarks - A: plane=391, cursor=63, sp [drm:intel_set_memory_cxsr] memory self-refresh is enabled [drm:intel_connector_check_state] [CONNECTOR:39:eDP-1] [drm:check_encoder_state] [ENCODER:30:DAC-30] [drm:check_encoder_state] [ENCODER:31:TMDS-31] [drm:check_encoder_state] [ENCODER:36:TMDS-36] [drm:check_encoder_state] [ENCODER:38:TMDS-38] [drm:check_crtc_state] [CRTC:21] [drm:check_crtc_state] [CRTC:26] [drm:intel_psr_activate [i915]] *ERROR* PSR Active [drm:intel_get_hpd_pins] hotplug event received, stat 0x00000000, dig 0x [drm:intel_set_cpu_fifo_underrun_reporting [i915]] *ERROR* pipe A underrun [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO Underrun. It is true that in a product we won't keep disabling and enabling planes so frequently, but for safeness let's stay conservative. It is also true that 500ms is an etternity. But PSR is anyway a power saving feature for idle scenario. So if it is idle feature stays on and 500ms to get it reanabled is not that insane. v2: Rebase over intel_psr.c and fix typo. v3: Revival: Manual tests indicated that this is needed. With a short delay there is a huge risk of getting blank screens when planes are being enabled. v4: Revival 2 with reasonable delay. 1/2 sec instead of 5. VBT is 10 sec but actually time for link training what we aren't doing, but with only 100 sec in some cases kms_psr_sink_crc manual was showing blank screen, so let's use this for now. Also changed comment by a FIXME. v5: Rebase after a long time, remove FIXME and update comment above. v6: msecs_to_jiffies is already on delay. remove duplication. v7: use msecs_to_jiffies on schedule_delayed_work call. Reviewed-by: Durgadoss R <durgadoss.r@intel.com> (v4) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: shuang.he@intel.com) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-07-09drm/i915: PSR: Increase idle_framesRodrigo Vivi1-2/+5
Idle frames the number of identical frames needed before panel can enter PSR. There are some panels that requires up to minimum of 4 idle frames available on the market. For these cases usually VBT should be used to configure the number of idle frames, but unfortunately this isn't always true and VBT isn't being set at all. Let's trust VBT when it is set + 1 and use minimum of 4 + 1 when VBT isn't set. "+1" covers the "of-by-one" case. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-07-09drm/i915: PSR: Remove Low Power HW tracking mask.Rodrigo Vivi1-1/+1
By Spec we should only mask memup and hotplug detection for hardware tracking cases. However we always masked LPSP because with power well always enabled on audio PSR was never being activated and residency was always zeroed. Apparently audio driver is tying power well management and runtime PM for some reason. But with audio runtime PM working or with audio completely out of picture we should remove this mask, otherwise we have a high risk of miss screen updates as faced by Matthew. WARNING: With this patch if snd_intel_hda driver is running and not releasing power well properly PSR will constant Exit and Performance Counter will be 0. But the best thing of this patch is that with one more HW tracking working the risks of missed blank screen are minimized at most. This affects just core platforms where PSR exit are also helped by HW tracking: Haswell, Broadwell and Skylake for now. v2: Fix commit message explanation. It has nothing to do with runtime PM on i915 as previously advertised. Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-07-09drm/i915: PSR: Flush means invalidate + flushRodrigo Vivi1-19/+21
Since flush actually means invalidate + flush we need to force psr exit on PSR flush. On Core platforms there is no way to disable hw tracking and do the pure sw tracking so we simulate it by fully disable psr and reschedule a enable back. So a good idea is to minimize sequential disable/enable in cases we know that HW tracking like when flush has been originated by a flip. Also flip had just invalidated it already. It also uses origin to minimize the a bit the amount of disable/enabled, mainly when flip already had invalidated. With this patch in place it is possible to do a flush on dirty areas properly in a following patch. v2: Remove duplicated exit on HSW+Sprites as pointed out by Paulo. Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-06-24drm/i915/psr: Restrict single-shot updates to the PSR pipeDaniel Vetter1-9/+13
The frontbuffer code gives us accurate information about activity, let's use it. Again this should avoid unecessary updates when multiple screens are on. Also realign function paramaters, I couldn't resist that bit of OCD. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Durgadoss R <durgadoss.r@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2015-06-24drm/i915/psr: Restrict buffer tracking to the PSR pipeDaniel Vetter1-4/+7
The current code tracks business across all pipes, but we're only really interested in the one pipe DRRS is enabled on. Fairly tiny optimization, but something I noticed while reading the code. But it might matter a bit when e.g. showing a video or something only on the external screen, while the panel is kept static. Also regroup the code slightly: First compute new bitmasks, then take appropriate actions. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Durgadoss R <durgadoss.r@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2015-04-14drm/i915: PSR VLV: Add single frame update.Rodrigo Vivi1-0/+42
According to spec: "In PSR HW or SW mode, SW set this bit before writing registers for a flip. It will be self-clear when it gets to the PSR active state." Some versions of spec mention that this is needed when in "Persistent mode" but define it as same as "SW mode". Since this fix the page flip case let's assume this is exactly what we need. Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-04-14drm/i915: PSR: deprecate link_standby support for core platforms.Rodrigo Vivi1-16/+10
On Haswell and Broadwell with link in standby when exit event happens between vblank and VSC packet, PSR exit on panel but DPA transmitter still sends black pixel. When this condition hits, panel will intermittently display black frame. The known W/A for this case involve the of single_frame update that isn't supported on Haswell and to be supported on Broadwell 3 other workarounds would be required. So it is better and safe to just deprecate link_standby for now. Also, link fully off saves more power than link_standby and afwk no OEM is requesting link standby on VBT. There is no reason for that. For Skylake let's just consider it behaves like Broadwell until we prove otherwise. v2: Fix commit message (Durga). v3: Fix conflict with PSR2. Reference: HSD: bdwgfx/1912559 Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Durgadoss R <durgadoss.r@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-04-14drm/i915: PSR: Fix DP_PSR_NO_TRAIN_ON_EXIT logicRodrigo Vivi1-4/+9
Since the beginning there is a missunderstanding on the meaning of this dpcd bit. This bit shouldn't indicate whether to use link standby or not, but just be used to configure TP1, TP2 and TP3 times and tell hw aux should be skiped since HW is the responsible one. Even with help of frontbuffer tracking, HW is still fully responsible for PSR exit logic with/without DP training. DP_PSR_NO_TRAIN_ON_EXIT means the source doesn't need to do the training, but it doesn't tell to avoid TP patterns, so we will send minimal TP1 and avoid TP2. It also means that sink itself can take up to 5 idle frames for training. 6 in our case since we might be off by 1. So we also increment idle_frames by 4 here. v2: Fix and improve commit message (Durga). v3: Use minimal TP1 time avoiding TP2 and increase idle frame. Cc: Durgadoss R <durgadoss.r@intel.com> Cc: Arthur Runyan <arthur.j.runyan@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Durgadoss R <durgadoss.r@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-04-14drm/i915: PSR: Remove wrong LINK_DISABLE.Rodrigo Vivi1-2/+1
This wrong logic and useless define came from first versions and came along with all rework. Just now I notice how ugly, wrong and useless this is. val is already defined as 0 anyway and logic is completelly wrong and useless. So let's starting the link_standby fix with this cleaning. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Durgadoss R <durgadoss.r@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-04-07drm/i915/skl: Enabling PSR2 SU with frame syncSonika Jindal1-1/+37
We make use of HW tracking for Selective update region and enable frame sync on sink. We use hardware's hardcoded data values for frame sync and GTC. v2: Add 3200x2000 resolution restriction with PSR2, move psr2_support to i915_psr struct, add aux_frame_sync to independently control aux frame sync, rename the TP2 TIME macro for 2500us (Rodrigo, Siva) v3: Moving the resolution restriction to intel_psr_enable so that we check it only once(Durga) Cc: Durgadoss R <durgadoss.r@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Sonika Jindal <sonika.jindal@intel.com> Reviewed-by: Durgadoss R <durgadoss.r@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-03-30drm/i915: PSR: Keep sink state consistent with sourceDurgadoss R1-1/+1
BSpec recommends to keep the main link state consistent between the source and the sink. As per that, update the main link state in sink DPCD register to 'active', for Valleyview based platforms. Signed-off-by: Durgadoss R <durgadoss.r@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Tested-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-03-26drm/i915: Remove duplicated psr.active unsetRodrigo Vivi1-2/+0
psr.active is being unset out of the if so this here is useless and duplicated. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-01-28drm/i915/skl: Enabling PSR on SkylakeSonika Jindal1-2/+24
Mainly taking care of some register offsets, otherwise things are similar to hsw. Also, programming ddi aux to use hardcoded values for psr data select. v2: introduce EDP_PSR_AUX_BASE macro (Chris) v3: Moving to HW tracking for SKL+ platforms, so activating source psr during psr_enabling and then avoiding psr entries and exits for each frontbuffer updates. v4: Using SKL DDI AUX regs instead of changing PSR_AUX regs definition (Rodrigo) Signed-off-by: Sonika Jindal <sonika.jindal@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> [danvet: Drop the hunks to short-circuit sw tracking: We'd need to push this down one level, and I don't fully trust the test coverage yet to do so. So much prefer we pick a whitelist approach for the cases we know work correctly.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-01-27drm/i915: Make intel_crtc->config a pointerAnder Conselvan de Oliveira1-4/+4
To match the semantics of drm_crtc->state, which this will eventually become. The allocation of the memory for config will be fixed in a followup patch. By adding the extra _config field to intel_crtc it was possible to generate this entire patch with the cocci script below. @@ @@ struct intel_crtc { ... -struct intel_crtc_state config; +struct intel_crtc_state _config; +struct intel_crtc_state *config; ... } @@ struct intel_crtc *crtc; @@ -memset(&crtc->config, 0, sizeof(crtc->config)); +memset(crtc->config, 0, sizeof(*crtc->config)); @@ @@ __intel_set_mode(...) { <... -to_intel_crtc(crtc)->config = *pipe_config; +(*(to_intel_crtc(crtc)->config)) = *pipe_config; ...> } @@ @@ intel_crtc_init(...) { ... WARN_ON(drm_crtc_index(&intel_crtc->base) != intel_crtc->pipe); +intel_crtc->config = &intel_crtc->_config; return; ... } @@ struct intel_crtc *crtc; @@ -&crtc->config +crtc->config @@ struct intel_crtc *crtc; identifier member; @@ -crtc->config.member +crtc->config->member @@ expression E; @@ -&(to_intel_crtc(E)->config) +to_intel_crtc(E)->config @@ expression E; identifier member; @@ -to_intel_crtc(E)->config.member +to_intel_crtc(E)->config->member v2: Clarify manual changes by splitting them into another patch. (Matt) Improve cocci script to generate even more of the changes. (Ander) Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-01-27drm/i915: Embedded struct drm_crtc_state in intel_crtc_stateAnder Conselvan de Oliveira1-1/+1
And get rid of the duplicate mode structures. This patch was generated with the following semantic patch: @@ @@ struct intel_crtc_state { +struct drm_crtc_state base; + ... -struct drm_display_mode requested_mode; -struct drm_display_mode adjusted_mode; ... } @@ struct intel_crtc_state *state; @@ -state->adjusted_mode +state->base.adjusted_mode @@ struct intel_crtc_state *state; @@ -state->requested_mode +state->base.mode @@ struct intel_crtc_state state; @@ -state.adjusted_mode +state.base.adjusted_mode @@ struct intel_crtc_state state; @@ -state.requested_mode +state.base.mode @@ struct drm_crtc *crtc; @@ -to_intel_crtc(crtc)->config.adjusted_mode +to_intel_crtc(crtc)->config.base.adjusted_mode @@ identifier member; expression E; @@ -PIPE_CONF_CHECK_FLAGS(adjusted_mode.member, E); +PIPE_CONF_CHECK_FLAGS(base.adjusted_mode.member, E); @@ identifier member; @@ -PIPE_CONF_CHECK_I(adjusted_mode.member); +PIPE_CONF_CHECK_I(base.adjusted_mode.member); @@ identifier member; @@ -PIPE_CONF_CHECK_CLOCK_FUZZY(adjusted_mode.member); +PIPE_CONF_CHECK_CLOCK_FUZZY(base.adjusted_mode.member); v2: Completely generate the patch with cocci. (Ander) Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-01-15drm/i915: group link_standby setup and let this info visible everywhere.Rodrigo Vivi1-10/+9
No functional changes on this patch. Just grouping the link_standy decision to avoid miss any change. Also making this info available everywhere which will help to decide when to use vbt's tp time on following patch. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Durgadoss R <durgadoss.r@intel.com> [danvet: Slight editing of the commit message which was one huge run-on sentence.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-01-15drm/i915: Add missing vbt check.Rodrigo Vivi1-1/+1
Let's respect vbt full_link (link_standby) on source side as well. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Durgadoss R <durgadoss.r@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-01-15drm/i915: PSR HSW/BDW: Fix inverted logic at sink main_link_active bit.Rodrigo Vivi1-2/+2
We have only two possible states with so many names and combinations that might be confusing. 1 - Main link active / enabled / stand by / on 2 - Main link disabled / off / full off Let's start organizing it by fixing a inverted logic when setting the sink bit. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Durgadoss R <durgadoss.r@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-01-15drm/i915: PSR VLV/CHV: Remove condition checks that only applies to Haswell.Rodrigo Vivi1-8/+5
These conditions applies only to Haswell and we were also checking for them on Valleyview/Cherryview. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Durgadoss R <durgadoss.r@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-01-15drm/i915: VLV/CHV PSR needs to exit PSR on every flush.Rodrigo Vivi1-4/+2
ON these platforms we don't have hardware tracking working for any case. So we need to fake this on software by forcing psr to exit on every flush. Manual tests indicated this was needed. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Durgadoss R <durgadoss.r@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-12-03drm/i915: VLV/CHV PSR Software timer modeRodrigo Vivi1-13/+84
This patch introduces exit/activate functions for PSR on VLV+. Since on VLV+ HW cannot track frame updates and force PSR exit let's use fully SW tracking available. v2: Rebase over intel_psr.c; Remove Single Frame update transitioning from state 3 to 5 directly; Fake a software invalidation for sprites and cursor so we don't miss any screen update; v3: As pointed out by Durgadoss msecs_to_jiffies used on wait_for only uses int, so let's use 1 instead. Althought the 1/4 of this is needed for the transition let's use 1 for simplicity; Also fix comments as suggested by Durgadoss Cc: Durgadoss R <durgadoss.r@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Durgadoss R <durgadoss.r@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-12-03drm/i915: PSR VLV/CHV: Introduce setup, enable and disable functionsRodrigo Vivi1-25/+130
The biggest difference from HSW/BDW PSR here is that VLV enable_source function enables PSR but let it in Inactive state. So it might be called on early stage along with setup and enable_sink ones. v2: Rebase over intel_psr.c; Remove docs from static functions; Merge vlv_psr_active_on_pipe; Timeout for psr transition is 250us; Remove SRC_TRASMITTER_STATE; v3: Rebase after is_psr_enabled function got removed; Get SRC_TRANSMITTER_STATE back to be on the safe side since default for panels is to require link training on exit when main link off; As pointed out by Durgadoss msecs_to_jiffies used on wait_for only uses int, so let's use 1 instead. Althought the 1/4 of this is needed for the transition let's use 1 for simplicity; Cc: Durgadoss R <durgadoss.r@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Durgadoss R <durgadoss.r@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-12-03drm/i915: Remove intel_psr_is_enabled function.Rodrigo Vivi1-10/+0
This function was in use to check if PSR feature got enabled. However on HSW and BDW we currently force psr exit by disabling EDP_PSR_ENABLE bit at EDP_PSR_CTL(dev). So this function was actually returning the active/inactive state that is different from the enable/disable meaning and had the risk of false negative. But anyway this check with DRRS was dangerous, since DRRS could try to get enabled before PSR gets there. So let's just remove it for now. A proper synchronization mechanism must be implemented later probably using pipe config. Cc: Daniel Vetter <daniel@ffwll.ch> Reviewed-by: Durgadoss R <durgadoss.r@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-12-03drm/i915: remove PSR BDW single frame update.Rodrigo Vivi1-1/+0
Single frame update is a feature available on BDW for PSR that allows Source to send Sink only one frame and get it updated. Usually useful when page flipping. However with our frontbuffer tracking where we force psr exit on flips we don't need this feature. Also after it got added here many workaround was added to documentation to mask some bits when using single frame update. So the safest thing is to just stop using it. v2: Rebase after removing skip aux one and fixing typo on commit message. Reviewed-by: Durgadoss R <durgadoss.r@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-12-03drm/i915: PSR get full link off x standby from VBTRodrigo Vivi1-1/+1
OEMs can specify if full_link might be always enabled, i.e. only_standby over VBT. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Durgadoss R <durgadoss.r@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-12-03drm/i915: HSW/BDW PSR Set idle_frames = VBT + 1Rodrigo Vivi1-1/+6
Let's use VBT + 1 now we parse it. v2: fix subject v3: rebase over intel_psr and without counting on previous fix Cc: Arthur Runyan <arthur.j.runyan@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Durgadoss R <durgadoss.r@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-17drm/i915: Add PSR docbookRodrigo Vivi1-0/+73
Let's document PSR a bit. No functional changes. v2: Add actual DocBook entry and accept Daniel's improvements. Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-11-17drm/i915: Introduce intel_psr.cRodrigo Vivi1-0/+408
No functional changes. Just cleaning and reorganizing it. v2: Rebase it puting it to begin of psr rework. This helps to blame easily at least latest changes. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>