- 23 Mar, 2016 8 commits
-
-
Ander Conselvan de Oliveira authored
Remove the clock calculation from ironlake_crtc_compute_clock() when the encoder compute_config() already set one. The value was just thrown away in that case. Note that the previously set clock is not validated against the limits anymore. That is ok since the fixed clocks from DP and SDVO are within the supported range, so the call to ironlake_compute_clocks() would never fail in that case. v2: Add note about not checking fixed clocks agains limits. (Maarten) Signed-off-by:
Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1458576016-30348-7-git-send-email-ander.conselvan.de.oliveira@intel.com
-
Ander Conselvan de Oliveira authored
Check has_reduced_clock only once when setting dpll_hw_state, making the code slightly more readable. Signed-off-by:
-
Ander Conselvan de Oliveira authored
The call to dev_priv->display.find_dpll() is already in platform specific code, so avoid the extra detour. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Ander Conselvan de Oliveira authored
The function intel_ironlake_limit() is only called by the crtc compute clock path. By merging it into ironlake_compute_clocks(), the code gets clearer, since there's no more if-ladders to follow. Signed-off-by:
-
Ander Conselvan de Oliveira authored
A previous patch made ironlake_get_refclk() very simple, so merge it into its only caller. Signed-off-by:
-
Ander Conselvan de Oliveira authored
LVDS is not cloneable, so the check is unnecessary. Removing it makes the code neater. v2: Remove checks from GMCH code too, not only ILK+. (Ville) Signed-off-by:
-
Ander Conselvan de Oliveira authored
The wait for other gens was added in commit 564ed191 ("drm/i915: gmch: fix stuck primary plane due to memory self-refresh mode") since that's necessary when disabling cxsr. However, cxsr disabling was later moved to intel_pre_disable_primary() in commit 87d4300a ("drm/i915: Move intel_(pre_disable/post_enable)_primary to intel_display.c, and use it there.") and that function got its own vblank wait for cxsr in commit 262cd2e1 ("drm/i915: CHV DDR DVFS support and another watermark rewrite"). So remove the extra vblank wait from i9xx_crtc_distable(). Cc: Kalyan Kondapally <kalyan.kondapally@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1458634284-6080-1-git-send-email-ander.conselvan.de.oliveira@intel.com
-
Mika Kuoppala authored
Commit d15d7538 ("drm/i915: Tune down init error message due to failure injection") added i915_load_error message to failure path on device initialization. The message is printed after the device is freed. And as the message printing helper uses the device structure, this leads to use after free. Spotted by Kasan. Cc: Imre Deak <imre.deak@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1458721906-10625-1-git-send-email-mika.kuoppala@intel.com
-
- 22 Mar, 2016 5 commits
-
-
Shashank Sharma authored
This patch contains following changes: 1. Add BXT MIPI display address base. 2. Call dsi_init from display_setup function. v2: Rebased on latest nightly branch v3 by Jani: init dsi after ddi Signed-off-by:
Shashank Sharma <shashank.sharma@intel.com> Signed-off-by:
Uma Shankar <uma.shankar@intel.com> Acked-by:
Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1458640910-5338-1-git-send-email-jani.nikula@intel.com
-
Imre Deak authored
Joonas and Daniel remarked that our debugging output should stay compatible with the core DRM's debug facility. The recently added __i915_printk() would output debug messages even if debugging is completely disabled via the drm.debug option. To fix this make __i915_printk behave the same as DRM_DEBUG_DRIVER in this case. CC: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> CC: Daniel Vetter <daniel.vetter@ffwll.ch> CC: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
-
Matt Roper authored
At the end of an atomic commit, we currently wait for vblanks to complete, call put() on the various runtime PM references, and then try to optimize our watermarks (on platforms that need two-step watermark programming). This can lead to watermark registers being programmed while the power well is powered down. We need to wait until after watermark optimization is complete before dropping our runtime power references. Note that in the future the watermark optimization is probably going to move to an asynchronous workqueue task that happens at some arbitrary point after vblank. When we make that change, we'll no longer necessarily be operating under the power reference held here, so we'll need to wrap the watermark register programmin in a call to intel_runtime_pm_get_if_in_use() or similar. Cc: arun.siluvery@linux.intel.com Cc: ville.syrjala@linux.intel.com Cc: maarten.lankhorst@linux.intel.com Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94349 Fixes: ed4a6a7c ("drm/i915: Add two-stage ILK-style watermark programming (v11)") Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
-
arun.siluvery@linux.intel.com authored
In preparation for engine reset, the wedged argument of i915_handle_error() is extended to reflect as a mask of engines that are hung. This is further passed down to error state capture functions which are also updated. Engine reset recovery mechanism uses this mask and schedules recovery work for those particular engines. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by:
Tomas Elf <tomas.elf@intel.com> Signed-off-by:
Arun Siluvery <arun.siluvery@linux.intel.com> Reviewed-by:
-
Tomas Elf authored
Initialize hangcheck struct during driver load. Since we do the same after recovering from a reset, this is extracted into a helper function. v2: remove redundant hangcheck init during load as this is done when engines are initialized (Chris) Cc: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by:
-
- 21 Mar, 2016 16 commits
-
-
Lionel Landwerlin authored
Patch based on a previous series by Shashank Sharma. v2: Update contributors v3: Refactor degamma/gamma LUTs load into a single function v4: Remove unused variable Signed-off-by:
Kumar, Kiran S <kiran.s.kumar@intel.com> Signed-off-by:
Kausal Malladi <kausalmalladi@gmail.com> Signed-off-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by:
-
Lionel Landwerlin authored
Patch based on a previous series by Shashank Sharma. v2: Do not read GAMMA_MODE register to figure what mode we're in v3: Program PREC_PAL_GC_MAX to clamp pixel values > 1.0 Add documentation on how the Broadcast RGB property is affected by CTM v4: Update contributors v5: Refactor degamma/gamma LUTs load into a single function v6: Fix missing intel_crtc variable (bisect issue) v7: Fix & simplify limited range matrix multiplication (Matt Roper's comment) Signed-off-by: -
Lionel Landwerlin authored
Implement Daniel Stone's recommendation to not read registers to infer the hardware's state. v2: Read GAMMA_MODE register value at init (Matt Roper's comment) v3: Read GAMMA_MODE register in intel_modeset_readout_hw_state along with other registers (Matt Roper's comment). v4: Mask GAMMA_MODE register with interesting bits when reading Signed-off-by: -
Lionel Landwerlin authored
The moves a couple of functions programming the gamma LUT and CSC units into their own file. On generations prior to Haswell there is only a gamma LUT. From haswell on there is also a new enhanced color correction unit that isn't used yet. This is why we need to set the GAMMA_MODE register, either we're using the legacy 8bits LUT or enhanced LUTs (of 10 or 12bits). The CSC unit is only available from Haswell on. We also need to make a special case for CherryView which is recognized as a gen 8 but doesn't have the same enhanced color correction unit from Haswell on. v2: Fix access to GAMMA_MODE register on older generations than Haswell (from Matt Roper's comments) Signed-off-by: -
Jani Nikula authored
BXT isn't as limited as BYT and CHT regarding DSI pipes and ports. Reviewed-by:
-
Jani Nikula authored
No functional changes. Reviewed-by:
-
Jani Nikula authored
The BXT display connections have DSI transcoders A and C that can be muxed to any pipe, not unlike the eDP transcoder. Add the notion of DSI transcoders. The "normal" transcoders A, B and C are not used with BXT DSI, so care must be taken to avoid accessing those registers with DSI transcoders in the hardware state readout, modeset, and generally everywhere. v2: addressing comments by Ville: - rename the dsi get config function to hsw_get_dsi_transcoder_state - rebase onto the higher level split of pipe/transcoder functions - use more has_dsi_encoder as we can now because of the above, with no need to look at the transcoder so much - rename IS_DSI_TRANSCODER to transcoder_is_dsi - use the above a bit more instead of comparing to < TRANSCODER_EDP Reviewed-by:
-
Jani Nikula authored
Makes it neater to add the same for DSI transcoder. No functional changes. v2: rename to hsw_get_transcoder_state and add a comment about grabbing power reference (Ville) Reviewed-by: -
Jani Nikula authored
Prep work for DSI transcoders. No functional changes. v2: call split functions at a higher level (Ville) Reviewed-by:
-
Jani Nikula authored
Prep work for DSI transcoders. No functional changes. v2: call split functions at a higher level (Ville) Reviewed-by:
-
Jesse Barnes authored
Some configs use the P2X type but some use a P3X type PCH, so add that to the detect_pch function so things work correctly. Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by:
Allen Kay <allen.m.kay@intel.com> Signed-off-by:
-
Jordan Justen authored
Signed-off-by:
Jordan Justen <jordan.l.justen@intel.com> Reviewed-by:
Francisco Jerez <currojerez@riseup.net> Signed-off-by:
-
Jordan Justen authored
This is needed for the Mesa Vulkan driver on Haswell. Signed-off-by:
-
Jordan Justen authored
Now that we can whitelist registers only on Haswell, move HSW_SCRATCH1 and HSW_ROW_CHICKEN3 into a separate Haswell only table. Signed-off-by:
-
Jordan Justen authored
For Haswell, we will want another table of registers while retaining the large common table of whitelisted registers shared by all gen7 devices. Signed-off-by:
-
Jordan Justen authored
This is needed for the Mesa Vulkan driver on Haswell. Signed-off-by:
-
- 18 Mar, 2016 9 commits
-
-
Imre Deak authored
Atm, in case failure injection forces an error the subsequent "*ERROR* failed to init modeset" error message will make automated tests (CI) report this event as a breakage even though the event is expected. To fix this print the error message with debug log level in this case. While at it print the error message for any init failure and change it to """ Device initialization failed (errno) Please file a bug at https://bugs.freedesktop.org/enter_bug.cgi?product=DRI against DRM/Intel providing the dmesg log by booting with drm.debug=0xf """ and export a helper printing error messages using this same format. A follow-up patch will convert all uses of DRM_ERROR reporting a user facing problem to use this new helper instead. v2: - Include the problematic error message in the commit log, add a request to file an fdo bug to the message (Chris) v3: - Include the new error message too in the commit log, make the fdo link more precise and print part of the message with info log level (Chris) v4: (Chris) - Use dev_printk instead of DRM_ERROR/INFO and use NOTICE instead of INFO loglevel - Export a helper for printing user facing error messages v5: - Keep the DRM_ERROR message prefix used by piglit-igt/CI to filter relevant dmesg lines - Use dev_notice(), instead of dev_printk(KERN_NOTICE,...) v6: - Print the fdo bug link only once (Chris) CC: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Chris Wilson authored
Throughout the code base, we use u32 for offsets into the global GTT. If we ever see any hardware with a larger GGTT, then we run the real risk of silent corruption. So test for our assumption up front so that we have a nice reminder should the time come when it fails. Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> [Rebased and changed 1ull -> 1ULL, cut 80 char line] Reviewed-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by:
-
Joonas Lahtinen authored
Use less pointers with the probing code, making it much less confusing to read. Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by:
-
Joonas Lahtinen authored
Refer to Global GTT consistently as GGTT, thus rename dev_priv->gtt to dev_priv->ggtt and struct i915_gtt to struct i915_ggtt. Fix a couple of whitespace problems while at it. v2: - Fix a typo in commit message. Reviewed-by:
-
Joonas Lahtinen authored
Reference variable value from pointer, not assumed pointer destination. Since: commit c44ef60e Author: Mika Kuoppala <mika.kuoppala@linux.intel.com> Date: Thu Jun 25 18:35:05 2015 +0300 drm/i915/gtt: Allow >= 4GB sizes for vm. Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by:
-
Tim Gore authored
This allows writes to EU flow control registers. Together with SIP code from the user-mode driver this resolves a hang seen in some pre-emption scenarios. Note that this patch is just the kernel mode part of this workaround. v2. Oops, add FLOW_CONTROL_ENABLE macro to i915_reg.h. Signed-off-by:
Tim Gore <tim.gore@intel.com> Reviewed-by:
-
Tvrtko Ursulin authored
By reading the CSB (slow MMIO accesses) into a temporary local buffer we can decrease the duration of holding the execlist lock. Main advantage is that during heavy batch buffer submission we reduce the execlist lock contention, which should decrease the latency and CPU usage between the submitting userspace process and interrupt handling. Downside is that we need to grab and relase the forcewake twice, but as the below numbers will show this is completely hidden by the primary gains. Testing with "gem_latency -n 100" (submit batch buffers with a hundred nops each) shows more than doubling of the throughput and more than halving of the dispatch latency, overall latency and CPU time spend in the submitting process. Submitting empty batches ("gem_latency -n 0") does not seem significantly affected by this change with throughput and CPU time improving by half a percent, and overall latency worsening by the same amount. Above tests were done in a hundred runs on a big core Broadwell. v2: * Overflow protection to local CSB buffer. * Use closer dev_priv in execlists_submit_requests. (Chris Wilson) v3: Rebase. v4: Added commend about irq needed to be disabled in execlists_submit_request. (Chris Wilson) Signed-off-by: -
Tvrtko Ursulin authored
Where we have a request we can use req->i915 directly instead of going through the engine and device. Coccinelle script: @@ function f; identifier r; @@ f(..., struct drm_i915_gem_request *r, ...) { ... - engine->dev->dev_private + r->i915 ... } @@ struct drm_i915_gem_request *req; @@ ( req-> - engine->dev->dev_private + i915 ) Signed-off-by: -
Tvrtko Ursulin authored
Signed-off-by:
-
- 17 Mar, 2016 2 commits
-
-
Imre Deak authored
Add support for forcing an error at selected places in the driver. As an example add 4 options to fail during driver loading. Requested by Chris. v2: - Add fault point for modeset initialization - Print debug message when injecting an error v3: - Rename inject_fault to inject_load_failure, rename the related macros and helper accordingly (Chris) - Use a counter instead of a mask to identify the failure point (Daniel) - Mark the module option as _unsafe and keep i915_params ordered (Joonas) v4: - Rebase on latest -nightly v5: - Use DRM_INFO instead of DRM_DEBUG_DRIVER, making it clearer in CI reports that a following error message is expected (IRC r-b from Chris on v5) CC: Chris Wilson <chris@chris-wilson.co.uk> CC: Daniel Vetter <daniel.vetter@ffwll.ch> CC: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by:
-
Imre Deak authored
Move the cleanup of the power domain HW state on the error path to the same function where the corresponding init call was called from. I noticed this problem when loading the module with load failure injection enabled, making i915_load_modeset_init() fail. CC: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
