- 08 Aug, 2014 40 commits
-
-
Jesse Barnes authored
sanitize_enable_ppgtt is the function that checks all the conditions, honoring a forced ppgtt status or doing auto-detect as necessary. Just make sure it returns the right value in all cases and use that in the macros instead of the confusing intel_enable_ppgtt() function. Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> [danvet: Don't reenable full ppgtt through the backdoor.] Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
Replace the semi-funky cmnlane assert/deassert macros with something a bit more conventional. Also protect the macro arguments properly (also for PHY_POWERGOOD()). Reviewed-by:
Rafael Barbalho <rafael.barbalho@intel.com> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Ville Syrjälä authored
It looks like frobbing the cmnreset line on pne PHY disturbs the other PHY on chv. The result is a black screen. On HDMI it's just a flash of black, but DP usually falls over and can't get back up. As a workaround set up the power domains so that both common lane wells power up and down together. I also tried leaving the cmnreset deasserted even the if the power well goes down but that didn't seem acceptable to the PHY. Reviewed-by:
-
Ville Syrjälä authored
CHV has a third pipe so we need to compute the watermarks for its planes. Add cherryview_update_wm() to do just that. v2: Rebase on top of Imre's cxsr changes v3: Pass crtc to vlv_update_drain_latency() Reviewed-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
-
Gajanan Bhat authored
Instead of looping through all CRTCs, update DDL for current CRTC for which watermark is being updated. CHV is confirmed to have precision of 32/64 which is same as VLV. Reviewed-by:
Imre Deak <imre.deak@intel.com> Signed-off-by:
Gajanan Bhat <gajanan.bhat@intel.com> Signed-off-by:
-
Ville Syrjälä authored
The VLV/CHV DDL registers are uniform, and neatly enough the register offsets are sane so we can easily unify them to a single set of defines and just pass the pipe as the parameter to compute the register offset. Note that we now fill out the drain latency for pipe C on CHV which we didn't do before. The rest of the pipe C watermarks are still untouched but that will be remedied later by adding a proper cherryview_update_wm() function. v2: Add a note about CHV pipe C changes (Paulo) Reviewed-by:
-
Ville Syrjälä authored
Add defines for all the watermark registers on modernish gmch platforms. VLV has increased the number of bits available for certain watermaks so expand the masks appropriately. Also vlv and chv have added some extra FW registers. Not sure what happened on chv because a new register called FW9 is now at the offset where FW7 was on vlv, while FW7 and FW8 (another new register) have been moved off somewhere else. Oh well, well just need two defines for FW7 then. v2: Fix DSPHOWM1 offset (Paulo) Reviewed-by:
-
Sonika Jindal authored
Reset rotation property to 0. v2: Resetting after disabling the plane Signed-off-by:
Sonika Jindal <sonika.jindal@intel.com> Reviewed-by:
Dave Airlie <airlied@gmail.com> Signed-off-by:
-
Ville Syrjälä authored
Sprite planes support 180 degree rotation. The lower layers are now in place, so hook in the standard rotation property to expose the feature to the users. v2: Moving rotation_property to mode_config Cc: dri-devel@lists.freedesktop.org Signed-off-by:
-
Sonika Jindal authored
Signed-off-by:
-
Ville Syrjälä authored
Propagate the error from intel_update_plane() up through intel_plane_restore() to the caller. This will be used for rollback purposes when setting properties fails. Cc: dri-devel@lists.freedesktop.org Signed-off-by:
-
Ville Syrjälä authored
The sprite planes (in fact all display planes starting from gen4) support 180 degree rotation. Add the relevant low level bits to the sprite code to make use of that feature. The upper layers are not yet plugged in. v2: HSW handles the rotated buffer offset automagically v3: BDW also handles the rotated buffer offset automagically Testcase: igt/kms_rotation_crc Cc: dri-devel@lists.freedesktop.org Signed-off-by:
Sagar Kamble <sagar.a.kamble@intel.com> Reviewed-by:
-
Damien Lespiau authored
Following the established idom, let's provide a macro to iterate through the encoders. spatch helps, once more, for the substitution: @@ iterator name list_for_each_entry; iterator name for_each_intel_encoder; struct intel_encoder * encoder; struct drm_device * dev; @@ -list_for_each_entry(encoder, &dev->mode_config.encoder_list, base.head) { +for_each_intel_encoder(dev, encoder) { ... } I also modified a few call sites by hand where a pointer to mode_config was directly used (to avoid overflowing 80 chars). Signed-off-by:Damien Lespiau <damien.lespiau@intel.com> [danvet: Wrap paramters correctly in the macro and remove spurious space checkpatch noticed.] Signed-off-by:
-
Damien Lespiau authored
While those messages are interesting, there aren't _that_ interesting. We don't need them in the kernel logs by default. Signed-off-by:
-
Paulo Zanoni authored
cat i915_reg.h | sort | uniq -d | grep define Signed-off-by:
-
Damien Lespiau authored
We used to carry a default HDMI value in entry 9, but this entry got removed for both HSW and BDW. Signed-off-by:
-
Damien Lespiau authored
We always write entries 0 to 8 from the DDI translation tables and then entry 9 for HDMI/DVI with the help of the VBT. We then don't need the failsafe HDMI entry in the DP/eDP/FDI tables. Signed-off-by:
-
Damien Lespiau authored
Among the changes, the tables has only 10 entries instead of 12 on HSW and the index the the 800mV/0dB entry has changed. Signed-off-by:
-
Damien Lespiau authored
The knowledge about the HDMI/DVI DDI translation table was scattered around. - info->hdmi_level_shift was initialized with 6, the index of the 800 mV, 0dB translation - A check on the VBT value was done to ensure it wasn't overflowing the translation table (< 0xC) - The actual programming was done in intel_ddi.c As we need to change that knowledge for Broadwell, let's gather everything into one place. Signed-off-by: -
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:
-
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:
-
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ä 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: -
Daniel Vetter authored
Turns out we were again way too naive and optimistic, of course things will change. 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:
-
