- 09 May, 2016 4 commits
-
-
Ville Syrjälä authored
Add a helper which aids in the identification of DP dual mode (aka. DP++) adaptors. There are several types of adaptors specified: type 1 DVI, type 1 HDMI, type 2 DVI, type 2 HDMI Type 1 adaptors have a max TMDS clock limit of 165MHz, type 2 adaptors may go as high as 300MHz and they provide a register informing the source device what the actual limit is. Supposedly also type 1 adaptors may optionally implement this register. This TMDS clock limit is the main reason why we need to identify these adaptors. Type 1 adaptors provide access to their internal registers and the sink DDC bus through I2C. Type 2 adaptors provide this access both via I2C and I2C-over-AUX. A type 2 source device may choose to implement either of these methods. If a source device implements the I2C-over-AUX method, then the driver will obviously need specific support for such adaptors since the port is driven like an HDMI port, but DDC communication happes over the AUX channel. This helper should be enough to identify the adaptor type (some type 1 DVI adaptors may be a slight exception) and the maximum TMDS clock limit. Another feature that may be available is control over the TMDS output buffers on the adaptor, possibly allowing for some power saving when the TMDS link is down. Other user controllable features that may be available in the adaptors are downstream i2c bus speed control when using i2c-over-aux, and some control over the CEC pin. I chose not to provide any helper functions for those since I have no use for them in i915 at this time. The rest of the registers in the adaptor are mostly just information, eg. IEEE OUI, hardware and firmware revision, etc. v2: Pass adaptor type to helper functions to ease driver implementation Fix a bunch of typoes (Paulo) Add DRM_DP_DUAL_MODE_UNKNOWN for the case where we don't (yet) know the type (Paulo) Reject 0x00 and 0xff DP_DUAL_MODE_MAX_TMDS_CLOCK values (Paulo) Adjust drm_dp_dual_mode_detect() type2 vs. type1 detection to ease future LSPCON enabling Remove the unused DP_DUAL_MODE_LAST_RESERVED define v3: Fix kernel doc function argument descriptions (Jani) s/NONE/UNKNOWN/ in drm_dp_dual_mode_detect() docs Add kernel doc for enum drm_dp_dual_mode_type Actually build the docs Fix more typoes v4: Adjust code indentation of type2 adaptor detection (Shashank) Add debug messages for failurs cases (Shashank) v5: EXPORT_SYMBOL(drm_dp_dual_mode_read) (Paulo) Cc: stable@vger.kernel.org Cc: Tore Anderson <tore@fud.no> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Shashank Sharma <shashank.sharma@intel.com> Signed-off-by:Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Shashank Sharma <shashank.sharma@intel.com> (v4) Link: http://patchwork.freedesktop.org/patch/msgid/1462542412-25533-1-git-send-email-ville.syrjala@linux.intel.com
-
Maarten Lankhorst authored
This makes it easier to debug issues like https://bugs.freedesktop.org/show_bug.cgi?id=93477Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Chris Wilson <|chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/843f4327-1574-cf8e-0776-adbb0d58c2c0@mblankhorst.nlReviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Daniel Vetter authored
This reverts commit 3543995a. I mixed up maintainers and thought Linus' ack was for the mfd tree. But Lee Jones (the real maintainer) wants to merge this through the mfd tree, so revert here. Cc: Lee Jones <lee.jones@linaro.org> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com>
-
Kenneth Graunke authored
Allowing register copies where the source and destination are both whitelisted should be safe, and is useful. For example, Mesa uses this to load the command streamer math registers with data from the pipeline statistics counters. v2: Reject writes to OACONTROL (and reads as well :( Signed-off-by:
Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> # v1 Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1462521014-13595-1-git-send-email-chris@chris-wilson.co.uk
-
- 08 May, 2016 1 commit
-
-
Daniel Vetter authored
Signed-off-by:
-
- 05 May, 2016 3 commits
-
-
Rodrigo Vivi authored
Version 1.01. This firmware is made for Kabylake platform so it doesn't need the stepping workaround that we had before. v2: Rebased on top of latest nightly with min version required change. v3: With right CSR_VERSION (Patrik). Cc: Christophe Prigent <christophe.prigent@intel.com> Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Reviewed-by: Ben Widawsky <benjamin.widawsky@intel.com> (v1) Signed-off-by:Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Link: http://patchwork.freedesktop.org/patch/msgid/1461707991-15336-1-git-send-email-rodrigo.vivi@intel.com
-
Chris Wilson authored
As i915_ppgtt_init() is not used outside of i915_gem_gtt.c we can make it static. Signed-off-by:
Matthew Auld <matthew.auld@intel.com>
-
Chris Wilson authored
If the command parser is not active, then it is appropriate to report it as operating at version 0 as no higher mode is supported. This greatly simplifies userspace querying for the command parser as we then do not need to second guess when it will be active (a mixture of module parameters and generational support, which may change over time). v2: s/comand/command/ misspelling in comment Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
-
- 04 May, 2016 3 commits
-
-
Daniel Vetter authored
LPT is pch, so might run into the fdi bandwidth constraint (especially since it has only 2 lanes). But right now we just force pipe_bpp back to 24, resulting in a nice loop (which we bail out with a loud WARN_ON). Fix this. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> References: https://bugs.freedesktop.org/show_bug.cgi?id=93477Signed-off-by:
-
Matthew Auld authored
Only has one user and is nothing more than a shim on top of i915_vma_unbind, so let's just get rid of it. Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Suggested-by:
-
Tvrtko Ursulin authored
They use dev_priv exclusively so pass it in instead of dev for smaller source and binary. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by:
-
- 03 May, 2016 5 commits
-
-
Lyude authored
Right now MST audio is causing too many kernel panics to really keep around in the kernel. On top of that, even after fixing said panics it's still basically non-functional (at least on all the setups I've tested it on). Revert until we have a proper solution for this. This reverts commit 3d52ccf5. Signed-off-by:
Lyude <cpaul@redhat.com> Fixes: 3d52ccf5 ("drm/i915: start adding dp mst audio") Cc: stable@vger.kernel.org Signed-off-by:
-
Ville Syrjälä authored
GPIO lookup tables are supposed to be zero terminated. Let's do that and avoid accidentally walking off the end. Cc: Shobhit Kumar <shobhit.kumar@intel.com> Cc: Samuel Ortiz <sameo@linux.intel.com> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Alexandre Courbot <gnurou@gmail.com> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Lee Jones <lee.jones@linaro.org> Cc: stable@vger.kernel.org Fixes: 61dd2ca2 ("mfd: intel_soc_pmic_core: Add lookup table for Panel Control as GPIO signal") Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
Thierry Reding <treding@nvidia.com> Acked-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Imre Deak authored
While browsing BSpec I bumped into a note saying we need to tune these values based on actual measurements done after initial enabling. I've checked that it indeed improves things on BXT. I haven't checked this on CHV, but here it is if someone wants to give it a go. v2: - Add note about the discrepancy wrt. to the spec in the formula calculating the credit encodings. (Mika, Ville) - Move the WA comment to the new function. (Ville) v3: - Keep the comment about the SQC WA in the caller. (Ville) CC: Ville Syrjälä <ville.syrjala@linux.intel.com> CC: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
-
Imre Deak authored
No need for hard-coding the register value, the corresponding fields are defined properly in BSpec. No functional change. v2: - Rebased on BXT L3 SQC tuning patch merged meanwhile. CC: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Imre Deak authored
BSpec requires us to wait ~100 clocks before re-enabling clock gating, so make sure we do this. CC: stable@vger.kernel.org CC: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
- 02 May, 2016 4 commits
-
-
Deepak M authored
These fields in VBT indicates the PWM source which is used and also the controller number. v2 by Jani: check for out of bounds access, some renames, change default type, etc. v3 by Jani: s/INTEL_BACKLIGHT_CABC/INTEL_BACKLIGHT_DSI_DCS/ Signed-off-by:
Deepak M <m.deepak@intel.com> Signed-off-by:
-
Praveen Paneri authored
i915_gem_shrink() will scan the bound list only if device is not suspended but in OOM failure scenario it becomes absolutely necessary to release as much memory as possible. Also in allocation failure from vmap address space, it is incumbent on the Driver to reap all its vmaps. So, adding rpm get/put in i915_gem_shrinker_oom() and i915_gem_shrinker_vmap() to ensure shrinking of bound objects as well. Signed-off-by:
Praveen Paneri <praveen.paneri@intel.com> Reviewed-by:
-
Praveen Paneri authored
When the system is running low on memory, gem shrinker is invoked. In this process objects will be unbounded from GTT and unbinding process will require access to GTT(GTTADR) and also to fence register potentially. That requires a resume of gfx device, if suspended, in the shrinker path. Considering the power leakage due to intermediate resume, perform unbinding operation only if device is already runtime active. v2: Use newly implemented intel_runtime_pm_get_if_in_use (Chris) Signed-off-by:
Akash Goel <akash.goel@intel.com> Signed-off-by:
-
Jani Nikula authored
The LVDS border enable is independent from the panel fitter. Move the readout of the "border bits" from i9xx_get_pfit_config() to intel_lvds_get_config(), where it will be read if LVDS is enabled even if the panel fitter is not. This fixes the state checker warning: [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in gmch_pfit.lvds_border_bits (expected 0x00008000, found 0x00000000) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: drm-intel-fixes@lists.freedesktop.org Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87632Reviewed-by:
Sitsofe Wheeler <sitsofe@yahoo.com> Signed-off-by:
-
- 29 Apr, 2016 19 commits
-
-
Chris Wilson authored
We have sufficient evidence from igt to support that semaphores are in a working state. Enabling semaphores now for legacy provides a better comparison of execlists against legacy ring submission. Signed-off-by:
-
Chris Wilson authored
When the engine idles waiting upon a semaphore, it loses its pagetables and we must reload them before executing the batch. v2: Restrict w/a to non-RCS rings (RCS works correctly apparently). Signed-off-by:
-
Chris Wilson authored
In order for the MI_SEMAPHORE_SIGNAL command to wait until after the pipecontrol writing the signal value is complete, we have to pause the CS inside the PIPE_CONTROL with the CS_STALL bit. Signed-off-by:
-
Chris Wilson authored
With the introduction of a distinct engine->id vs the hardware id, we need to fix up the value we use for selecting the target engine when signaling a semaphore. Note that these values can be merged with engine->guc_id. Fixes: de1add36Signed-off-by:
-
Chris Wilson authored
The i915.enable_ppgtt option depends upon the state of i915.enable_execlists option - so we need to sanitize execlists first. Signed-off-by:
-
Chris Wilson authored
For legacy ringbuffer mode, we need the new ordered breadcrumb emission tried and tested on execlists in order to avoid the dreaded "missed interrupt" syndrome. A secondary advantage of the execlists method is that it writes to an arbitrary address, useful if one wants to write a breadcrumb elsewhere. This fix is taken from commit 7c17d377 (drm/i915: Use ordered seqno write interrupt generation on gen8+ execlists). Signed-off-by:
-
Chris Wilson authored
At the start of request emission, we flush some space for the request, estimating the typical size for the request body. The common tail is now much larger than the typical body, so we can shrink the flush substantially. Signed-off-by:
-
Chris Wilson authored
At the start of request emission, we flush some space for the request, estimating the typical size for the request body. The tail is now much larger than the typical body, so we can shrink the flush slightly. Signed-off-by:
-
Chris Wilson authored
With 5 rings and a flush, we need 192 bytes of space to emit the breadcrumb and semaphores. However, we need some spare room the size of the single largest packet (36 dwords, 144 bytes) to accommodate wraparound giving a grand total of 336 bytes Signed-off-by:
-
Ander Conselvan de Oliveira authored
This moves the last phy specific code from the encoders to the phy specific file. Signed-off-by:
Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by:
Jim Bride <jim.bride@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1461761065-21195-11-git-send-email-ander.conselvan.de.oliveira@intel.com
-
Ander Conselvan de Oliveira authored
The phy code in vlv_pre_enable_dp() and vlv_hdmi_pre_enable() is exectly the same, so extract it to intel_dpio_phy.c. Signed-off-by:
-
Ander Conselvan de Oliveira authored
The code used by the DP and HDMI paths was very similar, so make them share it. Note that this removes the write to signal level registers from the HDMI pre pll enable path, but that's OK since those are set in vlv_hdmi_pre_enable() function. Signed-off-by:
-
Ander Conselvan de Oliveira authored
The logic for setting signal levels is used for both HDMI and DP with small variations. But it is similar enough to put behind a function called from the encoders. v2: Remove unrelated MST changes due to rebase fumble. (Jim Bride) Fix typo in the commit message. (Jim Bride) v3: Really fix the typo. (Jim) Cc: Jim Bride <jim.bride@linux.intel.com> Signed-off-by: -
Ander Conselvan de Oliveira authored
The exact same code was used by HDMI and DP encoders, so move it to intel_dpio_phy.c. v2: Fix typo in the commit message. (Jim Bride) v3: Call the new function chv_phy_post_pll_disable() instead of chv_phy_post_disable(), as it should be called after the pll is disabled. (Ville) Cc: Jim Bride <jim.bride@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: -
Ander Conselvan de Oliveira authored
The only difference between the DP and HDMI versions was the lane count. Since lane_count is now set appropriately for HDMI too, get rid of the duplication and move this to intel_dpio_phy.c v2: Don't move comments about 2nd common lane staying alive. (Ville) Signed-off-by:
-
Ander Conselvan de Oliveira authored
The same logic is used for DP and HDMI so move it to intel_dpio_phy.c. v2: Rebase Signed-off-by:
-
Ander Conselvan de Oliveira authored
The function chv_data_lane_soft_reset() was duplicated in DP and HDMI code. Move it to intel_dpio_phy.c. Signed-off-by:
-
Ander Conselvan de Oliveira authored
The code for programming voltage swing and emphasis was duplicated between DP and HDMI code. Move that to a new file, intel_dpio_phy.c. v2: Keep the "Use 800mV-0dB" comment in the HDMI code. (Ville) Signed-off-by:
-
Ander Conselvan de Oliveira authored
Set the lane count for HDMI to 4. This will make it easier to unduplicate CHV phy code. This also fixes the the soft reset programming for HDMI with CHV. After commit a8f327fb ("drm/i915: Clean up CHV lane soft reset programming"), it wouldn't set the right bits for PCS23 since it relied on a lane count that was never set. v2: Set lane_count in *_get_config() to please state checker. (0day) v3: Set lane_count for DDI in DVI mode too. (CI) v4: Add note about CHV soft lane reset. (Ander) Fixes: a8f327fb ("drm/i915: Clean up CHV lane soft reset programming") Signed-off-by:
-
- 28 Apr, 2016 1 commit
-
-
Ville Syrjälä authored
The comment about GMBUSFREQ is confused. The spec actually explains the 4MHz thing perfectly by noting that the 4MHz divider values is actually just bits [9:2] not [9:0], hence the divide by 1000 correct. Replace the confused note with a quote from the spec, and eliminate the duplicated comment that snuck in. Signed-off-by:
Mika Kahola <mika.kahola@intel.com>
-
