An error occurred fetching the project authors.
- 17 Feb, 2016 1 commit
-
-
Rodrigo Vivi authored
This will give us flexibility to enable PSR by default independently so issues and corner cases in one platform won't affect others were we have it working properly. Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 01 Feb, 2016 3 commits
-
-
Rodrigo Vivi authored
Unfortunately we don't know all panels and platforms out there and we found internal prototypes without VBT proper set but where only link in standby worked well. So, before enable PSR by default let's instrument the PSR parameter in a way that we can identify different panels out there that might require or work better with link standby mode. It is also useful to say that for backward compatibility I'm not changing the meaning of this flag. So "0" still means disabled and "1" means enabled with full support and maximum power savings. v2: Use positive value instead of negative for different operation mode as suggested by Daniel. v3: As Paulo suggested use 2 to force link standby and 3 to force link fully on. Also split the link_standby introduction in a separated patch. v4: Use DRM_ERROR for link off request on platforms that don't support and Remove the quirk promise. Cc: Jani Nikula <jani.nikula@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
-
Rodrigo Vivi authored
Link standby support has been deprecated with 'commit 89251b17 ("drm/i915: PSR: deprecate link_standby support for core platforms.")' The reason for that is that main link in full off offers more power savings and on HSW and BDW implementations on source side had known bugs with link standby. However that same HSD report only mentions BDW and HSW and tells that a fix was going to new platforms. Since on Skylake link standby didn't cause the bad blank flickering screens seen on HSW and BDW let's respect VBT again for this and future platforms. Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
-
Rodrigo Vivi authored
Current code not just block link_standby for non DDI platforms but also block PSR from work on other ports B/C/D/E. So, besides change any behaviour let's just fix the mess a bit here and reuse HSW check to block the other ports and reduce the second if only to link stadnby request. Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
-
- 12 Dec, 2015 1 commit
-
-
Rodrigo Vivi authored
This bit is also reserved on Skylake. Actually the only platform that supports this is Haswell, so let's fix this logic and apply this link entry time only for the platform that supports it, i.e. Haswell. This also changes the style to let more clear platform differences outside the reg write. We would probably catch this case sooner if separated, or not... Signed-off-by:
-
- 10 Dec, 2015 1 commit
-
-
Wayne Boyer authored
The cherryview device shares many characteristics with the valleyview device. When support was added to the driver for cherryview, the corresponding device info structure included .is_valleyview = 1. This is not correct and leads to some confusion. This patch changes .is_valleyview to .is_cherryview in the cherryview device info structure and simplifies the IS_CHERRYVIEW macro. Then where appropriate, instances of IS_VALLEYVIEW are replaced with IS_VALLEYVIEW || IS_CHERRYVIEW or equivalent. v2: Use IS_VALLEYVIEW || IS_CHERRYVIEW instead of defining a new macro. Also add followup patches to fix issues discovered during the first review. (Ville) v3: Fix some style issues and one gen check. Remove CRT related changes as CRT is not supported on CHV. (Imre, Ville) v4: Make a few more optimizations. (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:Wayne Boyer <wayne.boyer@intel.com> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by:
Jani Nikula <jani.nikula@intel.com>
-
- 07 Dec, 2015 1 commit
-
-
Rodrigo Vivi authored
'commit 97173eaf ("drm/i915: PSR: Increase idle_frames")' was a mistake. The special case it tried to cover was already being covered by the DP_PSR_NO_TRAIN_ON_EXIT. So this ended up duplicated. So, instead of reverting that let's take this opportunity and unify the idle_frame definition in a single place so we standardize the access and avoid room for that same mistake again. Few changes with this patch: 1. Instead of just respecting the VBT we set a global minumum with max(). So we are sure that we will avoid corner cases in case VBT is doing something we don't understand. 2. Instead of minimum 5 we use 6. When introducing the idle_frames += 4 case we considered that minimum was 2. All because the off-by-one issue. v2: Unified idle_frame definition. Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
-
- 24 Nov, 2015 4 commits
-
-
Rodrigo Vivi authored
It is not a bad idea to disable the PSR feature on Sink when we are disabling on the Source. v2: Move dpcd write inside mutex protected area as suggested by Sonika. Cc: Sonika Jindal <sonika.jindal@intel.com> Suggested-by:
Sonika Jindal <sonika.jindal@intel.com> Signed-off-by:
-
Rodrigo Vivi authored
When we introduced PSR we let LPSP masked allowing us to get PSR independently from the audio runtime PM. However in one of the attempts to get PSR enabled by default one user reported one specific case where he would miss screen updates if scrolling the firefox in a Gnome environment when i915 runtime pm was enabled. So for this specific case that (I could never create an i-g-t test case) we decided to remove the LPSP mask and let HW tracking taking care of this case. The mask got removed later by my commit 09108b90 ("drm/i915: PSR: Remove Low Power HW tracking mask.") So we started depending on audio driver again, what is bad. With previous commit "drm/i915: PSR: Let's rely more on frontbuffer tracking." we transfered the PSR exit responsability totally to SW frontbuffer tracking. So now can safelly shut off a bit the HW tracking, or at least this case that makes us to depend on other drivers. v2: Update commit message since this patch by itself doesn't solve the bugzilla entries. v3: Another attempt to improve commit message. Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Tested-by:
Brian Norris <briannorris@chromium.org> Signed-off-by:
-
Rodrigo Vivi authored
The ultimate goal here is to remove the dependency we currently have on audio driver power to get PSR working. Since with audio driver runtime PM disabled the Hardware tracking believes graphics is fully active and prevent PSR Entry, or in other words continuously exit PSR. So, the idea is to transfer the PSR exit responsability from the HW tracking to the SW tracking (frontbuffer tracking), who is really mature right now. However with LPSP masked out there might be cases where we could miss exit from HW tracking since it can be relying on this, like a specific case reported at our mailing list who user reported he would miss screen updates if scrolling firefox in a Gnome environment when i915 runtimepm was enabled. So before masking out LPSP again to make us independent from the audio driver we need to make sure that all our cases are coverred from the frontbuffer tracking perspective, where the flush means invalidate and flush. Without this patch for HSW, BDW and SKL we just do the invalidate part when the flush wasn't originated by a page flip because we were trusting the HW tracking for the flip case. So let's rely more on frontbuffer tracking and do the invalidation regardless the origin as expected for all platforms. v2: Improve commit message as suggested by Paulo. v3: Another attempt to let commit message more clear. Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
-
Rodrigo Vivi authored
Commit (89251b17) intended to remove this line and let only one DP_PSR_EN_CFG set, but it was wrong and this call is now duplicated at the code. Also "& ~DP_PSR_MAIN_LINK_ACTIVE" doesn't do anything at all. It was like that since I introduced this call but probably the idea was to be informative and make clear statement that we were not using the link standby. So it is better to remove this one here and let the code a bit cleaner. v2: Improve commit message as requested by Paulo. Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Tested-by:
-
- 18 Nov, 2015 5 commits
-
-
Rodrigo Vivi authored
On the commit 3301d409 ("drm/i915: PSR: Fix DP_PSR_NO_TRAIN_ON_EXIT logic")' we already had identified that DP_PSR_NO_TRAIN_ON_EXIT doesn't mean we shouldn't send TPS patterns, however we start sending the minimal TP1 as possible and no TP2. For most of the panels this is ok, but we found a reported case where this is not true and panel keeps frozen without updating the screen for a while. We could just get this case after patch "PSR: Don't Skip aux handshake on DP_PSR_NO_TRAIN_ON_EXIT." is applied since that one fix the hard freeze on this kind of panels. Reference: https://bugs.freedesktop.org/show_bug.cgi?id=91436#c19 Cc: Ivan Mitev <ivan.mitev@gmail.com> Signed-off-by:
Durgadoss R <durgadoss.r@intel.com> Signed-off-by:
-
Rodrigo Vivi authored
Since the beginning there is a confusion on the meaning of this bit. A previous patch had identified this already and fixed it partially: 'commit 3301d409 ("drm/i915: PSR: Fix DP_PSR_NO_TRAIN_ON_EXIT logic") 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 or to skip aux handshake. This patch fixes the hard freeze reported. Reference: https://bugs.freedesktop.org/show_bug.cgi?id=91436 Reference: https://bugs.freedesktop.org/show_bug.cgi?id=91437 Cc: Ivan Mitev <ivan.mitev@gmail.com> Signed-off-by:
-
Rodrigo Vivi authored
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 authored
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:
-
Ville Syrjälä authored
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: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
-
- 16 Nov, 2015 3 commits
-
-
Ville Syrjälä authored
v2: Split up the ctl vs. data reg handling like in the normal AUX code Signed-off-by:
-
Ville Syrjälä authored
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:
-
Ville Syrjälä authored
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:
-
- 13 Oct, 2015 1 commit
-
-
Ville Syrjälä authored
Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
- 05 Aug, 2015 1 commit
-
-
Rodrigo Vivi authored
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:
-
- 09 Jul, 2015 3 commits
-
-
Rodrigo Vivi authored
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 authored
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 authored
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:
-
- 23 Jun, 2015 2 commits
-
-
Daniel Vetter authored
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:
Daniel Vetter <daniel.vetter@intel.com>
-
Daniel Vetter authored
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:
-
- 14 Apr, 2015 4 commits
-
-
Rodrigo Vivi authored
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 authored
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 authored
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 authored
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:
-
- 07 Apr, 2015 1 commit
-
-
Sonika Jindal authored
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:
-
- 30 Mar, 2015 1 commit
-
-
Durgadoss R authored
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:
-
- 26 Mar, 2015 1 commit
-
-
Rodrigo Vivi authored
psr.active is being unset out of the if so this here is useless and duplicated. Signed-off-by:
-
- 28 Jan, 2015 1 commit
-
-
Sonika Jindal authored
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:
-
- 27 Jan, 2015 2 commits
-
-
Ander Conselvan de Oliveira authored
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:
-
Ander Conselvan de Oliveira authored
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:
-
- 15 Jan, 2015 4 commits
-
-
Rodrigo Vivi authored
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 authored
Let's respect vbt full_link (link_standby) on source side as well. Signed-off-by:
-
Rodrigo Vivi authored
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 authored
These conditions applies only to Haswell and we were also checking for them on Valleyview/Cherryview. Signed-off-by:
-
