- 08 May, 2015 40 commits
-
-
Ander Conselvan de Oliveira authored
Replace the commit output state function with a simple swap of states. Note that we still need to reconcile the legacy state after the swap, since there are still code that relies on those. Also note that even though changes to the state of a crtc different than the one passed as an argument to __intel_set_mode() will be saved, the modeset logic still deals with only one crtc. 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
Use lower level calls to better integrate with the modeset code and allow a full state swap in a follow up patch. Signed-off-by:
-
Ander Conselvan de Oliveira authored
When a new pipe_config is calculated, the fields related to shared dplls are reset, under the assumption that they will be recalculated as part of the modeset, which is true with the current state of the code. As we convert to atomic, however, it will be possible to calculate a new pipe_config and skip the modeset. In that case, after the state swap we still want the shared dplls to be preserved. Signed-off-by:
-
Ander Conselvan de Oliveira authored
To match the behavior of ->atomic_commit(). Signed-off-by:
-
Ander Conselvan de Oliveira authored
Replace the drivers own logic for computing mode_changed, active_changed and planes_changed flags with the check_modeset() atomic helper. Since that function needs to compare the crtc's new mode with the current, this patch also moves the set up of crtc_state->mode earlier in the call chain. Note that for the call to check_plane() to work properly, we need to check new plane state against new crtc state. But since we still use the plane update helper, which doesn't have a full atomic state, we need to hack around that in intel_plane_atomic_check(). Signed-off-by:
-
Ander Conselvan de Oliveira authored
So the i915 driver can use the same logic for setting mode and active changed flags, without having to implement encoder helpers and the mode_fixup() callback. Cc: dri-devel@lists.freedestkop.org Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Ander Conselvan de Oliveira authored
In a follow up patch the function that computes mode changes will be replaced with the one from the atomic helpers. To preserve the behavior of legacy modeset forcing DPMS on, that function will need to detect a change in the active state of the crtc, so that has to be kept up to date. Signed-off-by:
-
Ander Conselvan de Oliveira authored
This is no longer necessary since we only update the staged config on successfull modeset. The new configuration is stored in an atomic state struct which is freed in case of failure. Signed-off-by:
-
Ander Conselvan de Oliveira authored
The logic that stages the state before the modeset was still updating first the old staged config and then populating the atomic state based on that. Change this to use only the atomic state. Note that now the staged config is updated in the function intel_modeset_commit_output_state(). This is done so that the modeset check and the force restore path in the hw state read out code continue to work. Signed-off-by:
-
Ander Conselvan de Oliveira authored
Add a helper function to make the code slightly more readable. Signed-off-by:
-
Ander Conselvan de Oliveira authored
Call intel_set_mode() uncondionally from intel_crtc_set_config(), since the former function is now properly wired to ignore all the modesets if the mode_changed and active_changed flags are false in crtc_state. Signed-off-by:
-
Ander Conselvan de Oliveira authored
Use the atomic state instead. Signed-off-by:
-
Ander Conselvan de Oliveira authored
Use the similar fields in crtc_state instead, so that this code can be moved to our future implementation of atomic_check(). Signed-off-by:
-
Ander Conselvan de Oliveira authored
We don't need to pass it down the call chain anymore now that the plane state is set up properly. Signed-off-by:
-
Ander Conselvan de Oliveira authored
Add the primary plane state to the legacy modeset atomic state and use it when configuring the primary plane in __intel_set_mode(). This is a first step towards merging the flip path in intel_crtc_set_config() and __intel_set_mode(). v2: Set crtc to NULL if fb is NULL. (Maarten) Signed-off-by:
-
Ander Conselvan de Oliveira authored
The modeset code is now properly divided in two phases, so that it only changes hardware state if it succeeds, so there's no ill-effect that needs to be undone on failure anymore. Signed-off-by:
-
Ander Conselvan de Oliveira authored
The remaining parts of the failure path could only be reached if the allocation of crtc_state_copy would fail. In that case, there is nothing to undo, so just get rid of the label for error handling and return an error code immediately. We also always allocate a pipe_config, even if the pipe is being disabled, so the remaining part of what was the error/done case can be simplified a little too. v2: Ignore return value from drm_plane_helper_update(). (Ander) Signed-off-by:
-
Ander Conselvan de Oliveira authored
The first function calls done in that function can still cause changes to the atomic state and may fail. This should eventually be part of our atomic check function, while the rest of the code in __intel_set_mode() is the commit hook. So this makes the legacy mode set more atomic-y. Signed-off-by:
-
Ander Conselvan de Oliveira authored
There's no way that function can fail after it sets crtc->mode anymore, so there's no need to save the old mode for the failure case. Signed-off-by:
-
Ander Conselvan de Oliveira authored
Set the mode_changed field on the crtc_states and use that instead. Note that even though this patch doesn't completely replace the logic in intel_modeset_affected_pipes(), that logic was never fully used to its full extent. Since the commit mentioned below, modeset_pipes and prepare_pipes would only contain at most the pipe for which the set_crtc ioctl was called. We can grow back that logic when the time comes. commit b6c5164d Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Fri Apr 12 18:48:43 2013 +0200 drm/i915: Fixup Oops in the pipe config computation v2: Don't set mode_changed unconditionally for modeset_crtc. (Ander) Check for needs_modeset() before trying to allocate a PLL. (Ander) Only call .crtc_enable() for pipes that were disabled. (Maarten) Signed-off-by:
-
Ander Conselvan de Oliveira authored
With the current implementation of intel_modeset_affected_pipes(), if a pipe will be enabled then it is in modeset_pipes. We'll remove that mask in a follow up patch, but want to preserve this behavior, so just make that explicit. Signed-off-by:
-
Ander Conselvan de Oliveira authored
The code in intel_modeset_pipe_config() still needs changes before it can calculate more than just one pipe_config, and pretending it can will only make those changes more difficult. Signed-off-by:
-
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 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:
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:
-
