- 08 Aug, 2014 37 commits
-
-
Rodrigo Vivi authored
With this bit enabled, HW changes the color when compressing frames for debug purposes. ALthough the simple way to enable a single bit is over intel_reg_write, this value is overwriten on next update_fbc so depending on the workload it is not possible to set this bit with intel-gpu-tools. So this patch introduces a persistent way to enable false color over debugfs. v2: Use DEFINE_SIMPLE_ATTRIBUTE as Daniel suggested v3: (Ville) only do false color for IVB+ since according to spec bit is MBZ before IVB. v4: We don't have FBC on valleyview nor on cherryview (Ben) v5: s/!HAS_PCH_SPLIT/!HAS_FBC (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:Ben Widawsky <ben@bwidawsk.net> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Daniel Vetter authored
I'm not really that insisting on checkpath compliance, but ragged function paramter alignment does get me. Please adjust your editor to just do this for you. Cc: Shobhit Kumar <shobhit.kumar@intel.com> Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: -
Shobhit Kumar authored
v2: Updated the error log as suggested by Imre Signed-off-by:
Shobhit Kumar <shobhit.kumar@intel.com> Reviewed-by:
Imre Deak <imre.deak@intel.com> Signed-off-by:
-
Ville Syrjälä authored
CHV display PHY registes have two swing margin/deemph settings. Make it clear which ones we're using. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
Ville Syrjälä authored
CHV was forgotten the intel_{dp,hdmi}_prepare() were introduced (or the chv patches were still in flight?). Call these when enabling the ports. Things tend to work much better when we actually write something to the port registers :) Signed-off-by: -
Ville Syrjälä authored
Split chv_update_pll() into two parts ala: commit bdd4b6a6 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Apr 24 23:55:11 2014 +0200 drm/i915: Extract vlv_prepare_pll Signed-off-by:
-
Ville Syrjälä authored
We enable the DPLL refclock already when bringing up the cmnlane power well, so also leave it on when otherwise disabling the DPLL. Signed-off-by:
-
Ville Syrjälä authored
Punit seems a bit WIP still. Disable cdclk changes until we have hardware where it works. Signed-off-by:
-
Ville Syrjälä authored
Looks like the Punit is supposed to support the 400MHz cdclk directly on chv, so we don't need the vlv tricks. FIXME: Punit doesn't seem ready for this yet on current hw Signed-off-by:
-
Paulo Zanoni authored
Since we started using intel_runtime_pm_disable_interrupts() at normal (non-runtime) suspend/resume, we had to remove a WARN from ironlake_disable_display_irq to avoid a case where we were doing the correct thing and the WARN was not really needed. The problem is that the WARN was useful in other cases, and its removal can hide some bugs that we would catch automatically. To be able to add back the WARN, we have to call intel_crtc_control() before interrupts are disabled, which is what this patch currently does. Also notice that Ville's patch from the Watermarks series "drm/i915: Leave interrupts enabled while disabling crtcs during suspend" also did a change that's equivalent to the one we're doing on this patch, with the exception that its original patch, when applied to the current tree, procduces a WARN. Related commits: commit daa390e5ee45cc051d6bf37b296901f2f92b002d Author: Jesse Barnes <jbarnes@virtuousgeek.org> drm/i915: don't warn if IRQs are disabled when shutting down display IRQs commit e11aa362 Author: Jesse Barnes <jbarnes@virtuousgeek.org> drm/i915: use runtime irq suspend/resume in freeze/thaw Note that the function part of this patch has already been done in commit 0e32b39c Author: Dave Airlie <airlied@redhat.com> Date: Fri May 2 14:02:48 2014 +1000 drm/i915: add DP 1.2 MST support (v0.7) with the fixup commit 09b64267 Author: Dave Airlie <airlied@redhat.com> Date: Wed Jul 23 14:25:24 2014 +1000 drm/i915: don't suspend gt until after we disable irqs and display (v2) so all that's left from Paulo's patch is reinstating the WARNING. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by:
-
Daniel Vetter authored
Turns out we were again way too naive and optimistic, of course things will change. Signed-off-by:
Damien Lespiau <damien.lespiau@intel.com> Signed-off-by:
-
Damien Lespiau authored
This is only going to get worse, so split it now to avoid adding more cases to the if/else ladder. Suggested-by:
-
Damien Lespiau authored
Signed-off-by:
-
Damien Lespiau authored
We'll need a different algorithm to select the shared DPLL. Signed-off-by:
-
Damien Lespiau authored
Since the run-time PM on DPMS series, this function has an outdated comment. Refresh it a bit. Signed-off-by:
-
Damien Lespiau authored
Future platform will use config->ddi_pll_sel in a different way. Signed-off-by:
-
Damien Lespiau authored
So we can easily provide an alternate implementation in the future. Signed-off-by:
-
Damien Lespiau authored
Future platform will slightly change that. Signed-off-by:
-
Damien Lespiau authored
Signed-off-by:
-
Damien Lespiau authored
Not all those fields are valid on a given platform. Make it explicit. Unions could also be used, but were cluttering some code paths with if/else ladders. v2: Don't use anonymous unions (Daniel) Signed-off-by:
-
Ville Syrjälä authored
CHV supports DP training pattern 3. Add the required stuff. Signed-off-by:
-
Ville Syrjälä authored
Split some WM debug prints to multiple lines. This shouldn't hurt grappability since the important part is at the start and the rest is just repeated stuff for each pipe. Signed-off-by:
-
Rafael Barbalho authored
According to the specifications bit 6 is actually valid in the stride register. Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Rafael Barbalho <rafael.barbalho@intel.com> Reviewed-by:
-
Ville Syrjälä authored
Add the TX wells for port D. The Punit subsystem numbers are a total guess at this time. Also I'm not sure these even exist. Certainly the Punit in current hardware doesn't deal with these. Signed-off-by:
-
Ville Syrjälä authored
Add the TX wells for ports B and C just like on VLV. Again Punit doesn't seem ready (or the wells don't even exist anymore) so leave it iffed out. Signed-off-by:
-
Ville Syrjälä authored
CHV has a power well for each pipe. Add the code to deal with them. The Punit in current hardware doesn't seem ready for this yet, so leave it iffed out. Signed-off-by:
-
Ville Syrjälä authored
Not sure if it's still there since chv has per-pipe power wells. At least with current Punit this doesn't work. Also the display irq handling would need to be adjusted for pipe C. So leave the code iffed out for now. Signed-off-by:
-
Ville Syrjälä authored
Both VLV and CHV handle the cmnreset stuff in the power well code now, so intel_reset_dpio() is no longer needed. Signed-off-by:
-
Ville Syrjälä authored
CHV has two display PHYs so there are also two cmnlane power wells. Add the approriate code to power the wells up/down. Like on VLV we do the cmnreset assert/deassert and the DPLL refclock enabling at approriate times. This code actually works on my bsw. Signed-off-by:
-
Ville Syrjälä authored
Add chv_power_wells[] so we can start to build up the power well support for chv. Just the "always on" well there initialy. Signed-off-by:
-
Ville Syrjälä authored
Share the waitqueue that drm_irq uses when performing the vblank evade trick for atomic pipe updates. v2: Keep intel_pipe_handle_vblank() (Chris) Suggested-by:
Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
-
Ville Syrjälä authored
Add a small static inline helper to grab the vblank wait queue based on the drm_crtc. This is useful for drivers to do internal vblank waits using wait_event() & co. v2: Pimp commit message (Daniel) Add kernel doc (Daniel) Suggested-by: -
Vandana Kannan authored
Adding relevant read out comparison code, in check_crtc_state, for the new member of crtc_config, dp_m2_n2, which was introduced to store link_m_n values for a DP downclock mode (if available). Suggested by Daniel. v2: Changed patch title. Daniel's review comments incorporated. Added relevant state readout code for M2_N2. dp_m2_n2 comparison to be done only when high RR is not in use (This is because alternate m_n register programming will be done only when low RR is being used). v3: Modified call to get_m2_n2 which had dp_m_n as param by mistake. Compare dp_m_n and dp_m2_n2 for gen 7 and below. compare the structures based on DRRS state for gen 8 and above. Save and restore M2 N2 registers for gen 7 and below v4: For Gen>=8, check M_N registers against dp_m_n and dp_m2_n2 as there is only one set of M_N registers v5: Removed the chunk which saves and restores M2_N2 registers. Modified get_m_n() to get M2_N2 registers as well. Modified the macro which compares hw.dp_m_n against sw.dp_m2_n2/sw.dp_m_n for gen > 8. v6: Added check to compare dp_m2_n2 only when DRRS is enabled v7: Modified drrs check to use has_drrs v8: Add has_drrs check before reading M2_N2 registers Signed-off-by:
Vandana Kannan <vandana.kannan@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
Vandana Kannan authored
For Gen < 8, set M2_N2 registers on every mode set. This is required to make sure M2_N2 registers are set during boot, resume from sleep for cross- checking the state. The register is set only if DRRS is supported. v2: Patch rebased v3: Daniel's review comments - Removed HAS_DRRS(dev) and added bool has_drrs to pipe_config to track drrs support v4: Jesse's review comments - Made changes to set m2_n2 in intel_dp_set_m_n() Signed-off-by:
-
Rodrigo Vivi authored
This reverts commit 521e62e4. Although POST_SYNC brought a bit of stability to Semaphores on BDW it didn't solved all issues and some hungs can still occour when semaphores are enabled on BDW. Also some sloweness can be found on some igt tests, althoguth it apparently doesn't affect real workloads. Besides that, no real performance gain was found on our tests with different and even multiple workloads. Let's disable it again for now. At least until we are sure it is safe to re-enable it. Signed-off-by:
-
Jiri Kosina authored
Withtout this, ring initialization fails reliabily during resume with [drm:init_ring_common] *ERROR* render ring initialization failed ctl 0001f001 head ffffff8804 tail 00000000 start 000e4000 This is not a complete fix, but it is verified to make the ring initialization failures during resume much less likely. We were not able to root-cause this bug (likely HW-specific to Gen4 chips) yet. This is therefore used as a ducttape before problem is fully understood and proper fix created, so that people don't suffer from completely unusable systems in the meantime. The discussion and debugging is happening at https://bugs.freedesktop.org/show_bug.cgi?id=76554Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Cc: stable@vger.kernel.org Signed-off-by:
-
Rafael Barbalho authored
This particular nasty presented itself while trying to register the intelfb device (intel_fbdev.c). During the process of registering the device the driver will disable the crtc via i9xx_crtc_disable. These will also disable the panel using the generic mipi panel functions in dsi_mod_vbt_generic.c. The stale MIPI generic data sequence pointers would cause a crash within those functions. However, all of this is happening while console_lock is held from do_register_framebuffer inside fbcon.c. Which means that you got kernel log and just the device appearing to reboot/hang for no apparent reason. The fault started from the FB_EVENT_FB_REGISTERED event using the fb_notifier_call_chain call in fbcon.c. This regression has been introduced in commit d3b542fc Author: Shobhit Kumar <shobhit.kumar@intel.com> Date: Mon Apr 14 11:00:34 2014 +0530 drm/i915: Add parsing support for new MIPI blocks in VBT Cc: Shobhit Kumar <shobhit.kumar@intel.com> Signed-off-by:
-
- 07 Aug, 2014 3 commits
-
-
Deepak S authored
We might be leaving the PGU Frequency (and thus vnn) high during the suspend. Flusing the delayed work queue should take care of this. Signed-off-by:
Deepak S <deepak.s@linux.intel.com> Signed-off-by:
-
Rodrigo Vivi authored
BDW has many other Display Engine interrupts and GT interrupts registers. Collecting it properly on gpu_error_state. On debugfs all was properly listed already but besides we were also listing old DEIER and GTIER that doesn't exist on BDW anymore. This was causing unclaimed register messages v2: Fix small issues of first version and don't read DEIER regs when pipe's power well is disabled v3: bikeshed accepted: use enum pipe pipe instead of int i for pipe interection v4: Ben notice previous version was checking for display_power_enabled without using propper locks. Using _unlocked version isn't reliable and we cannot get this registers when power well is off. So let's avoid getting all DE_IER per pipe for now. If someone think this is an useful information it can be added later. v5: Ben: put back debugfs stuff that might be coverred by pm_get and use gen >= 8 trying to predict future. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81701 Cc: Ben Widawsky <ben@bwidawsk.net> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: -
Mika Kuoppala authored
If the actual head has progressed forward inside a batch (request), don't accumulate hangcheck score. As the hangcheck score in increased only by acthd jumping backwards, the result is that we only declare an active batch as stuck if it is trapped inside a loop. Or that the looping will dominate the batch progression so that it overcomes the bonus that forward progress gives. v2: Improved commit message (Chris Wilson) Signed-off-by:
Mika Kuoppala <mika.kuoppala@intel.com> [danvet: s/active_loop/active (loop)/ as requested by Chris.] Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
