- 08 May, 2015 40 commits
-
-
Ander Conselvan de Oliveira authored
The function intel_modeset_compute_config() needs to eventually become part of atomic_check(). At that point, all the affected crtcs need to be in the atomic state with the new values. So move the logic of adding crtc states out of that function. v2: Set crtc_state->enable in all cases. (Ander) Signed-off-by:
Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ander Conselvan de Oliveira authored
This should make the conversion to atomic easier, by splitting the initialization of the atomic state from the logic that decides if a modeset is needed. Signed-off-by:
-
Ander Conselvan de Oliveira authored
Simplifies looping over connector states a bit. Signed-off-by:
-
Ander Conselvan de Oliveira authored
Use the helpers introduced by the commit below to properly initialize the duplicated states. commit f5e7840b Author: Thierry Reding <treding@nvidia.com> Date: Wed Jan 28 14:54:32 2015 +0100 drm/atomic: Add helpers for state-subclassing drivers Signed-off-by:
-
Ander Conselvan de Oliveira authored
This is not necessary after the below commit. commit a0211bb4 Author: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Date: Mon Mar 30 14:05:43 2015 +0300 drm/atomic: Don't try to free a NULL state Signed-off-by:
-
Maarten Lankhorst authored
This makes disabling planes more explicit. Signed-off-by:
-
Maarten Lankhorst authored
To make it clear that it isn't called during crtc enable. Signed-off-by:
-
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:
-
