- 14 Nov, 2014 40 commits
-
-
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:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
Satheeshakrishna M <satheeshakrishna.m@intel.com> Signed-off-by:
Damien Lespiau <damien.lespiau@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
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:
Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-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:
Ville Syrjälä <ville.syrjala@linux.intel.com> 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:
Mika Kuoppala <mika.kuoppala@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: -
Ville Syrjälä authored
On VLV/CHV both pipes A and B have their own backlight control registers. In order to correctly read out the current hardware state at init we need to know which pipe is driving the eDP port. Pass that information down from the eDP init code into the backlight code. To determine the correct pipe we first look at which pipe is currently configured in the port control register, if that look invalid we look at which pipe's PPS is currently controlling the port, and if that too looks invalid we just assume pipe A. Signed-off-by:
-
Ville Syrjälä authored
If the connector would have an encoder but the encoder didn't have a crtc we might dereference a NULL crtc here. I suppose that should never happen due to intel_sanitize_encoder(), but let's be a bit paranoid print a warning if we ever hit this and return INVALID_PIPE to the caller. Signed-off-by:
-
Ville Syrjälä authored
On VLV/CHV when the display is off, we can't read out the current backlight level from the hardware since we have no pipe to do so. Currently we end up reading a bigus register due to passing INVALID_PIPE to VLV_BLC_PWM_CTL(). Skip the entire .get_backlight() call if the backlight isn't enabled according to backlight.enabled. This problem can be reproduced simply by reading the backlight device actual_brightness file while the display is off. Cc: Jani Nikula <jani.nikula@intel.com> Suggested-by:
-
Ville Syrjälä authored
VLV/CHV have backlight controls only on pipes A and B. Bail out without touching registers that don't exist, and print a warning. Signed-off-by:
-
Chris Wilson authored
Currently objects for which the hardware needs a contiguous physical address are allocated a shadow backing storage to satisfy the contraint. This shadow buffer is not wired into the normal obj->pages and so the physical object is incoherent with accesses via the GPU, GTT and CPU. By setting up the appropriate scatter-gather table, we can allow userspace to access the physical object via either a GTT mmaping of or by rendering into the GEM bo. However, keeping the CPU mmap of the shmemfs backing storage coherent with the contiguous shadow is not yet possible. Fortuituously, CPU mmaps of objects requiring physical addresses are not expected to be coherent anyway. This allows the physical constraint of the GEM object to be transparent to userspace and allow it to efficiently render into or update them via the GTT and GPU. v2: Fix leak of pci handle spotted by Ville v3: Remove the now duplicate call to detach_phys_object during free. v4: Wait for rendering before pwrite. As this patch makes it possible to render into the phys object, we should make it correct as well! Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Imre Deak authored
Paulo noticed that we don't support RPS on GEN9 yet, so WARN for and ignore any RPS interrupts on that platform. Signed-off-by:
Imre Deak <imre.deak@intel.com> Signed-off-by:
-
Imre Deak authored
The logical place for these functions is in i915_irq.c next to the rest of PM interrupt handling functions. No functional change. Signed-off-by:
-
Imre Deak authored
The GEN6 and GEN8 versions differ only in the PM IIR and IER register addresses and that on GEN8 we need to keep the GEN8_PMINTR_REDIRECT_TO_NON_DISP PM interrupt unmasked. Abstract away these 3 things in the GEN6 versions of the helpers and use them everywhere. No functional change. Signed-off-by:
-
Imre Deak authored
After the previous patch the GEN8 RPS handler became very similar to the GEN6 version, so unify the two functions. No functional change. Signed-off-by:
-
Imre Deak authored
The helpers to enable/disable PM IRQs for GEN6 and GEN8 are the same except for the PM interrupt mask register, so abstract away this register in the GEN6 versions and use these everywhere. No functional change. Signed-off-by:
-
Arun Siluvery authored
+WaForceEnableNonCoherent:chv +WaHdcDisableFetchWhenMasked:chv For: VIZ-4090 Signed-off-by:
-
Arun Siluvery authored
WaDisablePartialInstShootdown:chv and WaDisableThreadStallDopClockGating:chv are related to the same register so combine them. Signed-off-by:
-
Arun Siluvery authored
-WaDisableDopClockGating:chv -WaDisableSamplerPowerBypass:chv -WaDisableGunitClockGating:chv -WaDisableFfDopClockGating:chv -WaDisableDopClockGating:chv v2: Remove pre-production WA instead of restricting them based on revision id (Ville) For: VIZ-4090 Signed-off-by:
-
Paulo Zanoni authored
Commit "drm/i915: create a prepare phase for sprite plane updates" changed the old_obj pointer we use when committing sprite planes, which caused a WARN() and a BUG() to be triggered. Later, commit "drm/i915: use intel_fb_obj() macros to assign gem objects" introduced the same problem to function intel_commit_sprite_plane(). Regression introduced by: commit ec82cb793c9224e0692eed904f43490cf70e8258 Author: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Date: Fri Oct 24 14:51:32 2014 +0100 drm/i915: create a prepare phase for sprite plane updates and: commit 77cde952 Author: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Date: Fri Oct 24 14:51:33 2014 +0100 drm/i915: use intel_fb_obj() macros to assign gem objects Credits to Imre Deak for pointing out the exact lines that were wrong. v2: Also fix intel_commit_sprite_plane() (Ville) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85634 Testcase: igt/pm_rpm/legacy-planes Testcase: igt/pm_rpm/legacy-planes-dpms Testcase: igt/pm_rpm/universal-planes Testcase: igt/pm_rpm/universal-planes-dpms Credits-to: Imre Deak <imre.deak@intel.com> Cc: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: -
Daniele Ceraolo Spurio authored
- ppgtt init/release: these tracepoints are useful for observing the creation and destruction of Full PPGTTs. - ctx create/free: we can use the ctx_free trace in combination with the ppgtt_release one to be sure that the ppgtt doesn't stay alive for too long after the ctx is destroyed. ctx_create is there for simmetry - switch_mm: important point in the lifetime of the vm v4: add DOC information v5: pull the DOC in drm.tmpl v6: clean ppgtt init/release traces + add ctx create/free and switch_mm tracepoints (Chris) v7: drop execlist_submit_context tracepoint Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by:
-
Jani Nikula authored
The Baseline_ELD_Len field does not include ELD Header Block size. From High Definition Audio Specification, Revision 1.0a: The header block is a fixed size of 4 bytes. The baseline block is variable size in multiple of 4 bytes, and its size is defined in the header block Baseline_ELD_Len field (in number of DWords). Do not include the header size in Baseline_ELD_Len field. Fix all known users of eld[2]. While at it, switch to DIV_ROUND_UP instead of open coding it. Signed-off-by:
Ben Skeggs <bskeggs@redhat.com> Reviewed-by:
Dave Airlie <airlied@linux.ie> [danvet: Fix compile fail in nouveau.] Signed-off-by:
-
Alexey Khoroshilov authored
Since a8bb6818 __intel_framebuffer_create() is called with struct_mutex held, so it should use drm_gem_object_unreference() instead of drm_gem_object_unreference_unlocked(). Found by Linux Driver Verification project (linuxtesting.org). This regression has been introduced in commit a8bb6818 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Mon Feb 10 18:00:39 2014 +0100 drm/i915: Fix error path leak in fbdev fb allocation Signed-off-by:
Alexey Khoroshilov <khoroshilov@ispras.ru> Signed-off-by:
-
Bob Paauwe authored
Use the new pipe config values to calculate the updated pll dividers. This regression was introduced in commit 0dbdf89f27b17ae1eceed6782c2917f74cbb5d59 Author: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Date: Wed Oct 29 11:32:33 2014 +0200 drm/i915: Add infrastructure for choosing DPLLs before disabling crtcs and commit 00d958817dd3daaa452c221387ddaf23d1e4c06f Author: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Date: Wed Oct 29 11:32:36 2014 +0200 drm/i915: Covert remaining platforms to choose DPLLS before disabling CRTCs v2: Use intel_pipe_will_have_type() to look at new configuration - Ander Signed-off-by:Bob Paauwe <bob.j.paauwe@intel.com> CC: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Tested-by:
-
