- 08 Aug, 2014 40 commits
-
-
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:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
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:
Imre Deak <imre.deak@intel.com> 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:
Rodrigo Vivi <rodrigo.vivi@intel.com> 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:
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: -
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:
-
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:
-
