- 08 May, 2015 40 commits
-
-
Maarten Lankhorst authored
To make it clear that it isn't called during crtc enable. Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by:
Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Maarten Lankhorst authored
They're the same code, so why not? Signed-off-by:
-
Maarten Lankhorst authored
This was an optimization from way back before we had primary plane support to be able to disable the primary plane. But with primary plane support userspace can tell the kernel this directly, so there's no big need for this any more. And it's getting in the way of the atomic conversion. If need be we can resurrect this later on properly again. Signed-off-by:
-
Maarten Lankhorst authored
This allows disabling all planes affecting a crtc without caring what type it is. Signed-off-by:
-
Maarten Lankhorst authored
This is used by the next commit to disable all planes on a crtc without caring what type it is. Signed-off-by:
-
Maarten Lankhorst authored
Some of the flags that were used are still useful when transitioning to atomic, so keep those around for now. This removes some of the complications of crtc->primary_enabled, making it easier to remove. Signed-off-by:
-
Todd Previte authored
This patch adds 3 debugfs files for handling Displayport compliance testing and supercedes the previous patches that implemented debugfs support for compliance testing. Those patches were: - [PATCH 04/17] drm/i915: Add debugfs functions for Displayport compliance testing - [PATCH 08/17] drm/i915: Add new debugfs file for Displayport compliance test control - [PATCH 09/17] drm/i915: Add debugfs write and test param parsing functions for DP test control This new patch simplifies the debugfs implementation by places a single test control value into an individual file. Each file is readable by the usersapce application and the test_active file is writable to indicate to the kernel when userspace has completed its portion of the test sequence. Replacing the previous files simplifies operation and speeds response time for the user app, as it is required to poll on the test_active file in order to determine when it needs to begin its operations. V2: - Updated the test active variable name to match the change in the initial patch of the series V3: - Added a fix in the test_active_write function to prevent a NULL pointer dereference if the encoder on the connector is invalid Signed-off-by:Todd Previte <tprevite@gmail.com> Reviewed-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
-
Todd Previte authored
Updates the EDID compliance test function to perform the analyze and react to the EDID data read as a result of a hot plug event. The results of this analysis are handed off to userspace so that the userspace app can set the display mode appropriately for the test result/response. The compliance_test_active flag now appears at the end of the individual test handling functions. This is so that the kernel-side operations can be completed without the risk of interruption from the userspace app that is polling on that flag. V2: - Addressed mailing list feedback - Removed excess debug messages - Removed extraneous comments - Fixed formatting issues (line length > 80) - Updated the debug message in compute_edid_checksum to output hex values instead of decimal V3: - Addressed more list feedback - Added the test_active flag to the autotest function - Removed test_active flag from handler - Added failsafe check on the compliance test active flag at the end of the test handler - Fixed checkpatch.pl issues V4: - Removed the checksum computation function and its use as it has been rendered superfluous by changes to the core DRM EDID functions - Updated to use the raw header corruption detection mechanism - Moved the declaration of the test_data variable here V5: - Update test active flag variable name to match the change in the first patch of the series. - Relocated the test active flag declaration and initialization to this patch V6: - Updated to use the new flag for raw EDID header corruption - Removed the extra EDID read from the autotest function - Added the edid_checksum variable to struct intel_dp so that the autotest function can write it to the sink device - Moved the update to the hpd_pulse function to another patch - Removed extraneous constants V7: - Fixed erroneous placement of the checksum assignment. In some cases such as when the EDID read fails and is NULL, this causes a NULL ptr dereference in the kernel. Bad news. Fixed now. V8: - Updated to support the kfree() on the EDID data added previously V9: - Updated for the long_hpd flag propagation V10: - Updated to use actual checksum from the EDID read that occurs during normal hot plug path execution - Removed variables from intel_dp struct that are no longer needed - Updated the patch subject to more closely match the nature and contents of the patch - Fixed formatting problem (long line) V11: - Removed extra debug messages - Updated comments to be more informative - Removed extra variable V12: - Removed the 4 bit offset of the resolution setting in compliance data - Changed to DRM_DEBUG_KMS instead of DRM_DEBUG_DRIVER Signed-off-by:
-
Todd Previte authored
Displayport compliance test 4.2.2.6 requires that a source device be capable of detecting a corrupt EDID. The test specification states that the sink device sets up the EDID with an invalid checksum. To do this, the sink sets up an invalid EDID header, expecting the source device to generate the checksum and compare it to the value stored in the last byte of the block data. Unfortunately, the DRM EDID reading and parsing functions are actually too good in this case; the header is fixed before the checksum is computed and thus the test never sees the invalid checksum. This results in a failure to pass the compliance test. To correct this issue, when the EDID code detects that the header is invalid, a flag is set to indicate that the EDID is corrupted. In this case, it sets edid_corrupt flag and continues with its fix-up code. This flag is also set in the case of a more seriously damaged header (fixup score less than the threshold). For consistency, the edid_corrupt flag is also set when the checksum is invalid as well. V2: - Removed the static bool global - Added a bool to the drm_connector struct to reaplce the static one for holding the status of raw edid header corruption detection - Modified the function signature of the is_valid function to take an additional parameter to store the corruption detected value - Fixed the other callers of the above is_valid function V3: - Updated the commit message to be more clear about what and why this patch does what it does. - Added comment in code to clarify the operations there - Removed compliance variable and check_link_status update; those have been moved to a later patch - Removed variable assignment from the bottom of the test handler V4: - Removed i915 tag from subject line as the patch is not i915-specific V5: - Moved code causing a compilation error to this patch where the variable is actually declared - Maintained blank lines / spacing so as to not contaminate the patch V6: - Removed extra debug messages - Added documentation to for the added parameter on drm_edid_block_valid - Fixed more whitespace issues in check_link_status - Added a clear of the header_corrupt flag to the end of the test handler in intel_dp.c - Changed the usage of the new function prototype in several places to use NULL where it is not needed by compliance testing V7: - Updated to account for long_pulse flag propagation V8: - Removed clearing of header_corrupt flag from the test handler in intel_dp.c - Added clearing of header_corrupt flag in the drm_edid_block_valid function V9: - Renamed header_corrupt flag to edid_corrupt to more accurately reflect its value and purpose - Updated commit message V10: - Updated for versioning and patch swizzle - Revised the title to more accurately reflect the nature and contents of the patch - Fixed formatting/whitespace problems - Added set flag when computed checksum is invalid Signed-off-by:
Dave Airlie <airlied@redhat.com> Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Reviewed-by:
-
Nick Hoath authored
Note that we also need this for skl. Signed-off-by:
Nick Hoath <nicholas.hoath@intel.com> Reviewed-by:
Imre Deak <imre.deak@intel.com> [danvet: Note that we also need this for skl, requested by Imre.] Signed-off-by:
-
Damien Lespiau authored
Robert noticed that the FF_SLICE_CS_CHICKEN2 offset was wrong. Ooops. Ville noticed that the write was wrong since FF_SLICE_CS_CHICKEN2 is a masked register. Re-oops. A wonder if went through 2 people while having roughly a bug per line... The problem was introduced in the original patch: commit 2caa3b26 Author: Damien Lespiau <damien.lespiau@intel.com> Date: Mon Feb 9 19:33:20 2015 +0000 drm/i915/skl: Implement WaDisableChickenBitTSGBarrierAckForFFSliceCS v2: Also fix the register write (Ville) Reported-by:
Robert Beckett <robert.beckett@intel.com> Reported-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Robert Beckett <robert.beckett@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Nick Hoath <nicholas.hoath@intel.com> Signed-off-by:
Damien Lespiau <damien.lespiau@intel.com> Reviewed-by:
-
Ville Syrjälä authored
Do a POSTING_READ() between the DBUF_CTL register write and the udelay() to make sure we really wait after the register write has happened. Spotted while reviewing Damien's SKL cdclk patch which had the POSTING_READ()s. Cc: Imre Deak <imre.deak@intel.com> Signed-off-by:
-
Ville Syrjälä authored
Replace the hardcoded 9 with a call to intel_freq_opcode(450). Signed-off-by:
-
Sonika Jindal authored
This provides an option to override the value set by VBT for selecting edp Vswing Pre-emph setting table. v2: Adding comment about this being a temporary workaround and making the parameter read-only (Jani) v3: Changing mode to 0400 instead of 0 (Jani) https://bugs.freedesktop.org/show_bug.cgi?id=89554Signed-off-by:
Sonika Jindal <sonika.jindal@intel.com> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Nick Hoath authored
Note that we also need this for skl. Signed-off-by:
-
Ville Syrjälä authored
Use POSTING_READ() in intel_sdvo_write_sdvox() as appropriate. Signed-off-by:
-
Vandana Kannan authored
Enabling BLC on BXT. Includes register definition, and new functions for BXT. In BXT, there are 2 sets of registers for BLC. Until there is clarity about which set would be effective, set 1 is being used. This would have to be re-visited if there is any change or when 2 LFPs are enabled on BXT. This patch enables brightness change which would be effected by use of hot-keys or sysfs entry. TODO:- BLC implementation will have to re-visited when 1. there is clarity about which set of registers has to be used and when. 2. CDCLK frequency is changed v2: Jani's review comments - Modified comment in i915_reg.h - Renamed register defintions - Removed definition of duty cycle max. Not required now and its not 64-bit. v3: - Rebase on top of VLV/CHV backlight changes, in particuliar bxt_set_backlight() now has a different prototype (Damien) Reviewed-by:Vandana Kannan <vandana.kannan@intel.com> Signed-off-by:
-
Mika Kuoppala authored
wa_batchbuffer is part of some error states. Make sure it is freed. Signed-off-by:
Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by:
-
Jani Nikula authored
We should no longer enter the codec enable/disable functions in question with port A anyway, but to err on the safe side, keep the warnings. Just bail out early without messing with the registers. Signed-off-by:
Sivakumar Thulasimani <sivakumar.thulasimani@intel.com> Signed-off-by:
-
Damien Lespiau authored
The specs tell us to ungate PG1 and Misc I/O at display init. We'll use the PLLS power domain to ensure those two power wells are up. Signed-off-by:
-
Damien Lespiau authored
Signed-off-by:
-
Damien Lespiau authored
Let's keep that list sorted! Signed-off-by:
-
Damien Lespiau authored
Signed-off-by:
-
Damien Lespiau authored
Signed-off-by:
-
Michel Thierry authored
The patch 69876bed: "drm/i915/gen8: page directories rework allocation" added an overflow warning, but the mask had an extra 0. Use less typo-prone option suggested by Dave instead, to check for (start + length) >= 0x100000000ULL. This check will be unnecessary after gen8_alloc_va_range handles more than 4 PDPs (48b addressing). v2: Really check for 32b overflow (Ville) Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Cc: Dave Gordon <david.s.gordon@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Michel Thierry <michel.thierry@intel.com> Signed-off-by:
-
Mika Kuoppala authored
Unbinding doesn't always lead to unconditional destruction of vma. This destruction avoidance happens if vma is part of execbuffer relocation list or if vma is being considered for eviction in i915_gem_evict_something(). For those other users, mark the vma unbound so that the correct state of this vma is preserved. Reported-by:
Chris Wilson <chris@chris-wilson.co.ok> Cc: Chris Wilson <chris@chris-wilson.co.ok> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Jani Nikula authored
Because they can be. Signed-off-by:
-
Mika Kahola authored
This patch adds DP link training optimization by reusing the previously trained values. v2: - rebase V3: - rebase V4: - when HPD long pulse is received, the flag is cleared that indicates if DP link training is required or not (based on Sivakumar's comment) Signed-off-by:
Mika Kahola <mika.kahola@intel.com> Reviewed-by:
-
Mika Kahola authored
This is a first of series patches that optimize DP link training. The first patch is for eDP only where we reuse the previously trained link training values from cache i.e. voltage swing and pre-emphasis levels. In case we are not able to train the link by reusing the known values, the link training parameters are set to zero and training is restarted. V2: - flag that indicates if DP link is trained and valid renamed from 'link_trained' to 'train_set_valid' - removed routine 'intel_dp_reuse_link_train' V3: - rebased against the latest drm-intel-nightly V4: - removed HPD long pulse handling for eDP case to clear the flag that indicates to reuse the current link training parameters. (based on Sivakumar's comment) Signed-off-by:
-
Deepak S authored
Based on the spec, Setting up static BIAS for GPU to improve the rps performace. v2: rename reg defn to match spec. (Ville) v3: Updated bias setting for chv (Deepak) Signed-off-by:
Deepak S <deepak.s@linux.intel.com> Reviewed-by:
-
Dan Carpenter authored
We switched from calling i915_gem_alloc_context_obj() to calling i915_gem_alloc_object() so the error handling needs to be updated to check for NULL instead of IS_ERR(). Fixes: 149c86e7 ('drm/i915: Allocate context objects from stolen') Signed-off-by:
-
Chris Wilson authored
This is the wrong layer to apply an arbitrary restriction and the wrong error code (object too large!). If we do want to prevent large offsets being return to the user on 32bit systems (to hide bugs in userspace), you want to restrict the drm_mm range manager instead. This first tells userspace about the correct size of the GTT they can use (so they don't try and overallocate object or batches), and fixes the eviction logic to avoid the eventual and *guaranteed* error. Fixes regression in commit d7b2633d Author: Michel Thierry <michel.thierry@intel.com> Date: Wed Apr 8 12:13:34 2015 +0100 drm/i915/gen8: Dynamic page table allocations Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Michel Thierry <michel.thierry@intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Chris Wilson authored
Expose some more of our internal RPS bookkeeping for debugging. Signed-off-by:
-
Fabian Frederick authored
Inspired by scripts/coccinelle/api/err_cast.cocci Signed-off-by:
Fabian Frederick <fabf@skynet.be> Reviewed-by:
-
Joonas Lahtinen authored
Do not to clear mappings outside the allocated VMA under any circumstances. Only clear the smaller of VMA or object page count. This is required to allow creating partial object VMAs which in turn are needed for partial GGTT views. Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by:
-
Todd Previte authored
Due to changes in the driver and to support Displayport compliance testing, the test request and sink IRQ logic has been relocated from intel_dp_check_link_status to intel_dp_detect. This is because the bulk of the compliance tests that set the TEST_REQUEST bit in the DEVICE_IRQ field of the DPCD issue a long pulse / hot plug event to signify the start of the test. Currently, for a long pulse, intel_dp_check_link_status is not called for a long HPD pulse, so if test requests come in, they cannot be detected by the driver. Once located in the intel_dp_detect, in the regular hot plug event path, proper detection of Displayport compliance test requests occurs which then invokes the test handler to support them. Additionally, this places compliance testing in the normal operational paths, eliminating as much special case code as possible. The only change in intel_dp_check_link_status with this patch is that when the IRQ is the result of a test request from the sink, the test handler is not invoked during the short pulse path. Short pulse test requests are for a particular variety of tests (mainly link training) that will be implemented in the future. Once those tests are available, the test request handler will be called from here as well. V2: - Rewored the commit message to be more clear about the content and intent of this patch - Restore IRQ detection logic to intel_dp_check_link_status(). Continue to detect and clear sink IRQs in the short pulse case. Ignore test requests in the short pulses for now since they are for future test implementations. Signed-off-by:
-
Suketu Shah authored
Enable runtime PM for Skylake platform v2: After adding dmc ver 1.0 support rebased on top of nightly. (Animesh) Issue: VIZ-2819 Signed-off-by:
A.Sunil Kamath <sunil.kamath@intel.com> Signed-off-by:
Suketu Shah <suketu.j.shah@intel.com> Signed-off-by:
Animesh Manna <animesh.manna@intel.com> Reviewed-by:
-
Suketu Shah authored
Warn if the conditions to enter or exit DC6 are not satisfied such as support for runtime PM, state of power well, CSR loading etc. v2: Removed camelcase in functions and variables. v3: Do some minimal check to assert if CSR program is not loaded. v4: 1] Correct the check for backlight-disabling in assert_can_enable_dc6(). 2] Check csr.loaded = false before disabling DC6 and simplify other checks. v5: 1] Remove checks for DC5 state from assert_can_enable_dc6 function as DC5 is no longer enabled before enabling DC6. 2] Correct the check for CSR-loading in assert_can_disable_dc6 function as CSR must be loaded for context restore to happen on DC6 disabling. v6: 1] It's okay to explicitly disable DC6 during driver-load/resume even though it might already be disabled and so don't warn about it. v7: Rebase to latest. v8: Sqashed the patch from Imre - [PATCH] drm/i915/skl: avoid false CSR fw not loaded WARN during driver load/resume v9: After adding dmc ver 1.0 support rebased on top of nightly. (Animesh) v10: During initialization added a early return before disabling DC5. (Animesh) Issue: VIZ-2819 Signed-off-by:
-
A.Sunil Kamath authored
This patch just implements the basic enable and disable functions of DC6 state which is needed for SKL platform. Its important to load SKL CSR program before calling enable. DC6 is a deeper power saving state where hardware dynamically disables power well 0 and saves the associated registers. DC6 can be entered when software allows it, the conditions for DC5 are met, and the PCU allows DC6. DC6 cannot be used if the backlight is being driven from the display utility pin. Its better to configure display engine to have power well 2 disabled before getting into DC6 enable function. Hence rpm framework will ensure to check status of power well 2 and DC5 before calling skl_enable_dc6. v2: Replace HAS_ with IS_ check as per Daniel's review comments v3: Cleared the bits dc5/dc6 enable of DC_STATE_EN register before setting them as per Satheesh's review comments. v4: No need to call gen9_disable_dc5 inside enable sequence of DC6, as its already take care above. v5: call POSTING_READ for every write to a register to ensure that its written immediately. Call intel_prepare_ddi during DC6 exit as it's required on low-power exit. v6: Protect DC6-enabling-disabling functionality with locks to synchronize with CSR-loading code. v7: Remove grabbing CSR-related mutex in skl_enable/disable_dc6 functions as deferred DC5-enabling functionality is now removed. v8: Remove 'Disabling DC5' from the debug comment during DC6 enabling as when DC6 is allowed, DC5 is not programmed at all. v9: - Rebase to latest. - Move all DC6-related functions from intel_display.c to intel_runtime_pm.c. v10: After adding dmc ver 1.0 support rebased on top of nightly. (Animesh) Issue: VIZ-2819 Signed-off-by: -
Suketu Shah authored
Add triggers for DC6 as per details provided in skl_enable_dc6 and skl_disable_dc6 implementations. Also Call POSTING_READ for every write to a register to ensure it is written to immediately v1: Remove POSTING_READ and intel_prepare_ddi calls as they've been added in previous patches. v2: 1] Remove check for backlight disabled as it should be the case by that time. 2] Mark DC5 as disabled when enabling DC6. 3] Return from DC5-disabling function early if DC5 is already be disabled which can happen due to DC6-enabling earlier. 3] Ensure CSR firmware is loaded after resume from DC6 as corresponding memory contents won't be retained after runtime-suspend. 4] Ensure that CSR isn't identified as loaded before CSR-loading program is called during runtime-resume. v3: Rebase to latest Modified as per review comments from Imre and after discussion with Art: 1] DC6 should be preferably enabled when PG2 is disabled by SW as the check for PG1 being disabled is taken of by HW to enter DC6, and disabled when PG2 is enabled respectively. This helps save more power, especially in the case when display is disabled but GT is enabled. Accordingly, replacing DC5 trigger sequence with DC6 for SKL. 2] DC6 could be enabled from intel_runtime_suspend() function, if DC5 is already enabled. 3] Move CSR-load-status setting code from intel_runtime_suspend function to a new function. v4: 1] Enable/disable DC6 only when toggling the power-well using a newly defined macro ENABLE_DC6. v5: 1] Load CSR on system resume too as firmware may be lost on system suspend preventing enabling DC5, DC6. 2] DDI buffers shouldn't be programmed during driver-load/resume as it's already done during modeset initialization then and also that the encoder list is still uninitialized by then. Therefore, call intel_prepare_ddi function right after disabling DC6 but outside skl_disable_dc6 function and not during driver-load/resume. v6: 1] Rebase to latest. 2] Move SKL_ENABLE_DC6 macro definition from intel_display.c to intel_runtime_pm.c. v7: 1) Refactored the code for removing the warning got from checkpatch. 2) After adding dmc ver 1.0 support rebased on top of nightly. (Animesh) v8: - Reverted the changes done in v7. - Removed the condition check in skl_prepare_resune(). (Animesh) Issue: VIZ-2819 Signed-off-by:
-
