- 14 Nov, 2014 40 commits
-
-
Ville Syrjälä authored
Throw away the hand rolled display irq setup code on chv, and instead just call vlv_display_irq_postinstall() and vlv_display_irq_uninstall(). Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
Pull the vlv display irq uninstall code into a separate function, for eventual sharing with chv. Signed-off-by:
-
Damien Lespiau authored
Running the driver without execlists and hence PPGTT (either aliasing or full) isn't a supported configuration on gen9+. Signed-off-by:
Damien Lespiau <damien.lespiau@intel.com> Signed-off-by:
-
Damien Lespiau authored
intel_ddi.c:955:41: sparse: constant 8400000000 is so big it is long intel_ddi.c:955:53: sparse: constant 9000000000 is so big it is long intel_ddi.c:955:65: sparse: constant 9600000000 is so big it is long intel_ddi.c:1028:23: sparse: constant 9600000000 is so big it is long intel_ddi.c:1031:23: sparse: constant 9000000000 is so big it is long intel_ddi.c:1034:23: sparse: constant 8400000000 is so big it is long Signed-off-by:
kbuild test robot <fengguang.wu@intel.com> Signed-off-by:
-
Damien Lespiau authored
Given the history, there's some chance we'll keep the same WM code for a bit (previously, we were able to reuse the same WM code from ILK to BDW, so that sounds like a fair assumption). Signed-off-by:
-
Tvrtko Ursulin authored
Write and reads following the block changed use engine specific use counters and unless that is matched here force wake use counting goes bad. Same force wake is attempted to be taken twice which leads to at least time outs. NOTE: Depending on feedback from hardware designers it may not be necessary to grab force wakes on Gen9 here. But for Gen8 it is needed due to a race between RC6 and ELSP writes. v2: Added blitter force wake engine and made more future proof. Added commit note. Reviewed-by:Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by:
-
Damien Lespiau authored
Ville found out that the DATA1 register exists since SNB with some scarce apparitions in the specs throughout the times. In his own words: Also according to Bspec the mailbox data1 register already existed since snb. The hsw cdclk change sequence also mentions that it should be set to 0, but eg. the bdw IPS sequence doesn't mention it. I guess in theory some pcode command might cause it to be clobbered, so I'm thinking we should just explicitly set it to 0 for all platforms in the pcode read/write functions Reviewed-by:
-
Michael H. Nguyen authored
The LRC increased in size on gen9. Make sure we return the right size in get_lr_context_size() v2. Corrected the size, should be 22 pages. I unintentionally mailed out a test patch w/ size equaling 23 pages. Reviewed-by:
Michael H. Nguyen <michael.h.nguyen@intel.com> Signed-off-by:
-
Jesse Barnes authored
Use the new AUX port irq bits where needed. v2: Rebase on top of upstream changes v3: Rebase on top of Oscar change to write IIR as soon as possible (Damien) v4: Rebase on top of the for_each_pipe() change adding dev_priv as first argument (Damien) Reviewed-by:Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
Jesse Barnes authored
This moved around on SKL, so we need to make sure we read/write the correct regs. v2: fixup WIN_POS offsets (Paulo) zero out WIN_POS reg at disable time (Paulo) Reviewed-by:Jesse Barnes <jbarnes@virtuougseek.org> Signed-off-by:
-
Damien Lespiau authored
A few bits have changed in MI_DISPLAY_FLIP to accomodate the new planes. DE_RRMR seems to have kept its plane flip bits backward compatible. v2: Rebase on top of nightly v3: Rebase on top of nightly (minor conflict in i915_reg.h) v4: Remove code that is now part of intel_crtc_page_flip() Don't use BUG() in default: Use intel_crtc->unpin_work->gtt_offset (Paulo) Reviewed-by: -
Vandana Kannan authored
The eDP WA to stop link train based on port type is for HSW/BDW, not required for SKL+. Suggested by Satheesh v2: Simplified the check befoe stop_link_train. Suggested by Satheesh. v3: stop_link_train need not be called from intel_enable_ddi for gen >= 9 Suggested-by:
Satheeshakrishna M <satheeshakrishna.m@intel.com> Reviewed-by:
Vandana Kannan <vandana.kannan@intel.com> Cc: Satheeshakrishna M <satheeshakrishna.m@intel.com> Signed-off-by:
-
Damien Lespiau authored
v2: rebase on top of the hw state flattening. Reviewed-by:
-
Satheeshakrishna M authored
This patch implements SKL DPLL programming that includes: - DPLL allocation - wide range PLL calculation and programming - DP link rate programming - DDI to DPLL mapping v2: Incorporated following changes - Added vfunc for function required outside - Fixed multiple comments in WRPLL calculation v3: - Fix the DCO computation - Move the initialization up to not clobber the computed values - Use the correct macro for DP link rate programming. - Use wait_for() to wait for the PLL locked bit v4: Rebase on top of nigthly (Damien) v5: A few code cleanups in the WRPLL computation (Damien) - Use uint32_t when possible - Use abs_diff() in the WRPLL computation - Make the 64bits divisions use div64_u64() - Fix typo in dco_central_feq_deviation (freq) - Replace the chain of breaks with a goto v6: Port of the patch to work on top of the shared DPLLs (Damien) v7: Don't try to handle eDP in ddi_pll_select() (Damien) v8: Modified as per review comments from Paulo (Satheesh) v9: Rebase on top of Ander's clock computation staging work for atomic (Damien) Reviewed-by: -
Satheeshakrishna M authored
Skylake deprecates the usage of PORT_CLK_SEL and we are advised to use the new DPLL_CRTL2 for the DDI->PLL mapping. v2: Modified as per review comments Reviewed-by:
-
Satheeshakrishna M authored
On skylake, DPLL 1, 2 and 3 can be used for DP and HDMI. The shared dpll framework allows us to share those DPLLs among DDIs when possible. The most tricky part is to provide a DPLL state that can be easily compared. DPLL_CRTL1 is shared by all the DPLLs, 6 bits each. The per-dpll crtl1 field of the hw state is then normalized to be the same value if 2 DPLLs do indeed have identical values for those 6 bits. v2: Port the code to the shared DPLL infrastructure (Damien) v3: Rebase on top of Ander's clock computation staging work for atomic (Damien) Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> (v2) Signed-off-by: Satheeshakrishna M <satheeshakrishna.m@intel.com> (v1) Signed-off-by:
-
Satheeshakrishna M authored
Modify the implementation to query DPLL attached to a SKL port. v2: Rebase on top of the run-time PM on DPMS series (Damien) v3: Modified as per review comments from Paulo Reviewed-by:
-
Satheeshakrishna M authored
v2: Fixup compilation due to the removal of the intel_ddi_dpll_id enum. And add a fixme about the abuse of pipe_config here. v3: Rebase on top of the hsw_ddi_clock_get() rename (Damien) v4: Modified as per review comments from Paulo Reviewed-by:
-
Satheeshakrishna M authored
Determine programmed cd clock for SKL. v2: Fix the LCPLL1 enable warning logic v3: Rebase over the hsw pll rework. v4: Rebase on top of the per-platform split (Damien) v5: Modified as per review comments from Paulo Reviewed-by:
-
Satheeshakrishna M authored
Adding structure/enum for SKL clocking implementation. v2: Addressed Damien's comment - Removed internal structure from this header file v3: Stove this into the generic intel_dpll_id enum and give them the established DPLL_ID_ prefixes. (Daniel) v4: - We'll only try to share DPLL1/2/3, leaving DPLL0 to eDP - Use SKL in the skylake shared DPLL names - Re-add the skl_dpll enum (Damien) v5: Remove SKL_DPLL_NONE (Daniel) v6: Modified as per review comments from Paulo Reviewed-by: -
Satheeshakrishna M authored
This patch defines the necessary SKL registers for implementing the new clocking mechanism. v2: Addressed review comments by Damien - Added code comment - Introduced enum for WRPLL values v3: Rebase on top of nightly (minor conflict in i915_reg.h) v4: Use 0x, not 0X (Ville) v5: Modified as per review comments from Paulo Reviewed-by:
-
Jesse Barnes authored
Some machines may have a broken VBT or no VBT at all, but we still want to use SSC there. So check for it and keep it enabled if we see it already on. Based on an earlier fix from Kristian. v2: honor modparam if set too (Daniel) read out at init time and store for panel_use_ssc() use (Jesse) v3: trust BIOS configuration over VBT like we do for DP (Jani) Reported-by:Kristian Høgsberg <hoegsberg@gmail.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Daniel Vetter authored
This has been invalidated in commit 24f3a8cf Author: Akash Goel <akash.goel@intel.com> Date: Tue Jun 17 10:59:42 2014 +0530 drm/i915: Added write-enable pte bit supportt But despite that it's in the diff context no one noticed :( Cc: Akash Goel <akash.goel@intel.com> Cc: Imre Deak <imre.deak@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com>
-
Jani Nikula authored
Use the same conditions, group by features, add comments. Signed-off-by:
-
Jani Nikula authored
This is not used within the driver, and merely saving/restoring these registers isn't going to do any good anyway. In fact, it's possible it's actively harmful. Any code enabling the feature should handle this completely in the regular platform specific enable/disable backlight functions. Signed-off-by:
-
Jani Nikula authored
AFAICT i9xx_pfit_disable() on the GMCH display crtc disable path in i9xx_crtc_disable() will always disable the panel fitter by writing 0 to PFIT_CONTROL. The register save will always save/restore 0. Also we completely recompue both in intel_gmch_panel_fitting so there's no way we depend upon leftover bits. Move the PFIT_CONTROL and PFIT_PGM_RATIOS save/restore to UMS code. While at it, save/restore them both under the same conditions. Signed-off-by:
-
Jani Nikula authored
The block was added for spin_lock_irqsave flags, but since the locking was converted to spin_lock_irq variant, the block is no longer needed. Signed-off-by:
-
Jani Nikula authored
Since RSTDBYCTL is only saved on non-KMS path in within i915_save_state, move the restore in i915_restore_state for symmetry. Signed-off-by:
-
Jani Nikula authored
Don't save the panel power sequencer register on vlv/chv for two simple reasons. First, these are the wrong registers to save to begin with. Second, they are not restored anyway. Signed-off-by:
-
Mika Kuoppala authored
As per latest pm guide, we need to do this also on past hsw. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
-
Michel Thierry authored
Following the legacy ring submission example, update the ring->init_context() hook to support the execlist submission mode. v2: update to use the new workaround macros and cleanup unused code. This takes care of both bdw and chv workarounds. v2.1: Add missing call to init_context() during deferred context creation. v3: Split init_context (emit) in legacy/lrc modes. For lrc, get the ringbuf from the context (Mika/Daniel). v4: Merge init_context interfaces back, the legacy mode only needs the ring, but the lrc mode needs the ring and context (Mika). Issue: VIZ-4092 Issue: GMIN-3475 Change-Id: Ie3d093b2542ab0e2a44b90460533e2f979788d6c Cc: Deepak S <deepak.s@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
Michel Thierry <michel.thierry@intel.com> Signed-off-by:
Arun Siluvery <arun.siluvery@linux.intel.com> Reviewed-by:
-
Ville Syrjälä authored
When reading a CCK register we should obviously read it from CCK not Punit. This problem has been present ever since this of code was introduced in commit 67c3bf6f Author: Deepak S <deepak.s@linux.intel.com> Date: Thu Jul 10 13:16:24 2014 +0530 drm/i915: populate mem_freq/cz_clock for chv The problem was raised during review by Mika [1] but somehow slipped through the cracks, and the patch got applied with the problem unfixed. [1] http://lists.freedesktop.org/archives/intel-gfx/2014-July/048937.html Cc: Deepak S <deepak.s@linux.intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by:
Deepak S <deepak.s@linux.intel.com> Signed-off-by:
-
Neil Roberts authored
The predicate source registers are needed to implement conditional rendering without stalling. The two source registers are used to load the previous values of the PS_DEPTH_COUNT register saved from PIPE_CONTROL commands. These can then be compared and used to set the predicate enable bit via the MI_PREDICATE command. The command parser version number is increased to 2 to make it easier to detect the new functionality in user space. Signed-off-by:
Neil Roberts <neil@linux.intel.com> Reviewed-by: Brad Volkin <bradley.d.volkin@intel.com> (v1) Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> (v1) Signed-off-by:
-
Jesse Barnes authored
This only affects the fastboot path as-is. In that case, we simply need to make sure that we update the pipe size at the first mode set. Rather than putting it off until we decide to flip (if indeed we do end up flipping), update the pipe size as appropriate a bit earlier in the set_config call. This sets us up for better pipe tracking in later patches. Signed-off-by:
Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Signed-off-by:
-
Jesse Barnes authored
If these change (e.g. after a modeset following a fastboot), we need to do a full mode set. v2: - put under pipe_config check so we don't deref a null state (Jesse) Signed-off-by:
-
Jesse Barnes authored
This is useful for checking things later. v2: - fix hsw infoframe enabled check (Ander) Signed-off-by:
-
Jesse Barnes authored
This will allow us to consult more info before deciding whether to flip or do a full mode set. v2: - don't use uninitialized or incorrect pipe masks in set_config failure path (Ander) v3: - fixup for pipe_config changes in compute_config (Jesse) v4: - drop spurious hunk in force restore path (Ander) Signed-off-by: -
Jesse Barnes authored
This allows us to calculate the full pipe config before we do any mode setting work. v2: - clarify comments about global vs. per-crtc mode set (Ander) - clean up unnecessary pipe_config = NULL setting (Ander) v3: - fix pipe_config handling (alloc in compute_config, free in set_mode) (Jesse) - fix arg order in set_mode (Jesse) - fix failure path of set_config (Ander) Signed-off-by:
-
Ville Syrjälä authored
Now that the backlight device no longer gets registered too early we should be able to drop most of the INVALID_PIPE checks from the backlight code. The only exceptio is the opregion stuff where we may (in theory at least) get a request from the BIOS already during driver init as soon as the backlight setup has been done. In which case we can still get the INVALID_PIPE from intel_get_pipe_from_connector(). So leave that check in place, and add a comment explaining why. For the rest, if we still manage to get here with INVALID_PIPE on VLV/CHV we will now get a WARN from the lower level functions and can then actually investigate further. v2: Leave the check in the BIOS related code (Jani) Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Ville Syrjälä authored
Currently we register the backlight device as soon as we register the connector. That means we can get backlight requests from userspace already before reading out the current modeset hardware state. That means we don't yet know the current crtc->encoder->connector mapping, which causes problems for VLV/CHV which need to know the current pipe in order to figure out which BLC registers to poke. Currently we just ignore such requests fairly deep in the backlight code which means the backlight device brightness property will get out of sync with our backlight.level and the actual hardware state. Fix the problem by delaying the backlight device registration until the entire modeset init has been performed. And we also move the backlight unregisteration to happen as the first thing during the modeset cleanup so that we also won't be bothered with userspace backlight requested during teardown. This is a real world problem on machines using systemd, because systemd, for some reason, wants to restore the backlight to the level it used last time. And that happens as soon as it sees the backlight device appearing in the system. Sometimes the userspace access makes it through before the modeset init, sometimes not. v2: Do not lie to the user in the debug prints (Jani) Include connector name in the prints (Jani) Fix a typo in the commit message (Jani) Reviewed-by:
-
