- 28 Sep, 2020 7 commits
-
-
Karthik B S authored
Add the details of the implementation of asynchronous flips for i915. v7: -Rebased. v8: -Rebased. v9: -Rebased. v10: Move all documentation changes to this patch. (Ville) Signed-off-by:
Karthik B S <karthik.b.s@intel.com> Signed-off-by:
Vandita Kulkarni <vandita.kulkarni@intel.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Karthik B S authored
In Gen 9 and Gen 10 platforms, async address update enable bit is double buffered. Due to this, during the transition from async flip to sync flip we have to wait until this bit is updated before continuing with the normal commit for sync flip. v9: -Rename skl_toggle_async_sync() to skl_disable_async_flip_wa(). (Ville) -Place the declarations appropriately as per need. (Ville) -Take the lock before the reg read. (Ville) -Fix comment and formatting. (Ville) -Use IS_GEN_RANGE() for gen check. (Ville) -Move skl_disable_async_flip_wa() to intel_pre_plane_update(). (Ville) v10: -Rebased. Signed-off-by: -
Karthik B S authored
This hook is added to avoid writing other plane registers in case of async flips, so that we do not write the double buffered registers during async surface address update. v7: -Plane ctl needs bits from skl_plane_ctl_crtc as well. (Ville) -Add a vfunc for skl_program_async_surface_address and call it from intel_update_plane. (Ville) v8: -Rebased. v9: -Use if-else instead of return in intel_update_plane(). (Ville) -Rename 'program_async_surface_address' to 'async_flip'. (Ville) v10: -Check if async_flip hook is present before calling it. Otherwise it will OOPS during legacy cursor updates. (Ville) v11: -Rename skl_program_async_surface_address(). (Ville) Signed-off-by: -
Karthik B S authored
Since the flip done event will be sent in the flip_done_handler, no need to add the event to the list and delay it for later. v2: -Moved the async check above vblank_get as it was causing issues for PSR. v3: -No need to wait for vblank to pass, as this wait was causing a 16ms delay once every few flips. v4: -Rebased. v5: -Rebased. v6: -Rebased. v7: -No need of irq disable if we are not doing vblank evade. (Ville) v8: -Rebased. v9: -Move the return in intel_pipe_update_end before tracepoint. (Ville) v10: Rebased. Signed-off-by: -
Karthik B S authored
If flip is requested on any other plane, reject it. Make sure there is no change in fbc, offset and framebuffer modifiers when async flip is requested. If any of these are modified, reject async flip. v2: -Replace DRM_ERROR (Paulo) -Add check for changes in OFFSET, FBC, RC(Paulo) v3: -Removed TODO as benchmarking tests have been run now. v4: -Added more state checks for async flip (Ville) -Moved intel_atomic_check_async to the end of intel_atomic_check as the plane checks needs to pass before this. (Ville) -Removed crtc_state->enable_fbc check. (Ville) -Set the I915_MODE_FLAG_GET_SCANLINE_FROM_TIMESTAMP flag for async flip case as scanline counter is not reliable here. v5: -Fix typo and other check patch errors seen in CI in 'intel_atomic_check_async' function. v6: -Don't call intel_atomic_check_async multiple times. (Ville) -Remove the check for n_planes in intel_atomic_check_async -Added documentation for async flips. (Paulo) v7: -Replace 'intel_plane' with 'plane'. (Ville) -Replace all uapi.foo as hw.foo. (Ville) -Do not use intel_wm_need_update function. (Ville) -Add destination coordinate check. (Ville) -Do not allow async flip with linear buffer on older hw as it has issues with this. (Ville) -Remove break after intel_atomic_check_async. (Ville) v8: -Rebased. v9: -Replace DRM_DEBUG_KMS with drm_dbg_kms(). (Ville) -Fix comment formatting. (Ville) -Remove gen specific checks. (Ville) -Remove irrelevant FB size check. (Ville) -Add missing stride check. (Ville) -Use drm_rect_equals() instead of individual checks. (Ville) -Call intel_atomic_check_async before state dump. (Ville) v10: -Fix the checkpatch errors seen on CI. v11: -Use const for all plane/crtc states. (Ville) -Use 'switch' instead of 'if' for modifier check. (Ville) -Move documentation changes to a single patch. (Ville) Signed-off-by: -
Karthik B S authored
Set the Async Address Update Enable bit in plane ctl when async flip is requested. v2: -Move the Async flip enablement to individual patch (Paulo) v3: -Rebased. v4: -Add separate plane hook for async flip case (Ville) v5: -Rebased. v6: -Move the plane hook to separate patch. (Paulo) -Remove the early return in skl_plane_ctl. (Paulo) v7: -Move async address update enable to skl_plane_ctl_crtc() (Ville) v8: -Rebased. v9: -Rebased. v10: -Rebased. Signed-off-by: -
Karthik B S authored
Add enable/disable flip done functions and the flip done handler function which handles the flip done interrupt. Enable the flip done interrupt in IER. Enable flip done function is called before writing the surface address register as the write to this register triggers the flip done interrupt Flip done handler is used to send the page flip event as soon as the surface address is written as per the requirement of async flips. The interrupt is disabled after the event is sent. v2: -Change function name from icl_* to skl_* (Paulo) -Move flip handler to this patch (Paulo) -Remove vblank_put() (Paulo) -Enable flip done interrupt for gen9+ only (Paulo) -Enable flip done interrupt in power_well_post_enable hook (Paulo) -Removed the event check in flip done handler to handle async flips without pageflip events. v3: -Move skl_disable_flip_done out of interrupt handler (Paulo) -Make the pending vblank event NULL in the beginning of flip_done_handler to remove sporadic WARN_ON that is seen. v4: -Calculate timestamps using flip done time stamp and current timestamp for async flips (Ville) v5: -Fix the sparse warning by making the function 'g4x_get_flip_counter' static.(Reported-by: kernel test robot <lkp@intel.com>) -Fix the typo in commit message. v6: -Revert back to old time stamping code. -Remove the break while calling skl_enable_flip_done. (Paulo) v7: -Rebased. v8: -Rebased. v9: -Use struct drm_i915_private *i915 in new code. (Ville) -Use intel_crtc instead of drm_crtc. (Ville) -Do not mix the flip done and vblank hooks. (Ville) v10: -Rebased. Signed-off-by:
-
- 24 Sep, 2020 5 commits
-
-
Ville Syrjälä authored
When validating a "YCbCr 4:2:0 only" mode we must take into account the fact that we're going to be outputting YCbCr 4:2:0 or 4:4:4 (when a DP->HDMI protocol converter is doing the 4:2:0 downsampling). For YCbCr 4:4:4 the minimum output bpc is 8, for YCbCr 4:2:0 it'll be half that. The currently hardcoded 6bpc is only correct for RGB 4:4:4, which we will never use with these kinds of modes. Figure out what we're going to output and use the correct min bpp value to validate whether the link has sufficient bandwidth. Signed-off-by:
Manasi Navare <manasi.d.navare@intel.com> Reviewed-by:
-
Ville Syrjälä authored
Pass the output_format directly to intel_dp_{min,output}_bpp() rather than passing in the crtc_state and digging out the output_format inside the functions. This will allow us to reuse the functions for mode validation purposes. Signed-off-by: -
Ville Syrjälä authored
Refactor the output_format calculation into a helper so that we can reuse it for mode validation as well. Signed-off-by:
-
Ramalingam C authored
When roll over detected for seq_num_m, we shouldn't continue with stream management with rolled over value. So we are terminating the stream management retry, on roll over of the seq_num_m. v2: using drm_dbg_kms instead of DRM_DEBUG_KMS [Anshuman] v3: dev_priv is used as i915 [JaniN] v4: roll over is detected at the start of the stream management. Signed-off-by:
Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com> [v3] Tested-by:
Anshuman Gupta <anshuman.gupta@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200923132435.17039-3-anshuman.gupta@intel.com
-
Ramalingam C authored
As per the HDCP2.2 compliance test 1B-10 expectation, when stream management for a repeater fails, we retry thrice and when it fails in all retries, HDCP2.2 reauthentication aborted at kernel. v2: seq_num_m++ is extended for steam management failures too.[Anshuman] v3: use drm_dbg_kms instead of DRM_DEBUG_KMS [Anshuman] v4: dev_priv is used as i915 [JaniN] v5: Few improvisements are done [Sean] Signed-off-by:
-
- 22 Sep, 2020 2 commits
-
-
Mauro Carvalho Chehab authored
The name of the argument is different, causing those warnings: ./drivers/gpu/drm/drm_edid.c:3754: warning: Function parameter or member 'video_code' not described in 'drm_display_mode_from_cea_vic' ./drivers/gpu/drm/drm_edid.c:3754: warning: Excess function parameter 'vic' description in 'drm_display_mode_from_cea_vic' Fixes: 7af655bc ("drm/dp: Add drm_dp_downstream_mode()") Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by:
Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200922175357.42998-3-lyude@redhat.com
-
Mauro Carvalho Chehab authored
As warned by kernel-doc: ./drivers/gpu/drm/drm_dp_helper.c:385: warning: Function parameter or member 'type' not described in 'drm_dp_downstream_is_type' ./drivers/gpu/drm/drm_dp_helper.c:886: warning: Function parameter or member 'dev' not described in 'drm_dp_downstream_mode' Some function parameters weren't documented. Fixes: 38784f6f ("drm/dp: Add helpers to identify downstream facing port types") Signed-off-by:
-
- 17 Sep, 2020 22 commits
-
-
Rodrigo Vivi authored
Signed-off-by:Rodrigo Vivi <rodrigo.vivi@intel.com>
-
Swathi Dhanavanthri authored
This workaround applies to all TGL and RKL steppings. Signed-off-by:
Swathi Dhanavanthri <swathi.dhanavanthri@intel.com> Reviewed-by:
José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200911221158.4700-1-swathi.dhanavanthri@intel.com
-
Ville Syrjälä authored
Since we now have proper old and new cdclk state we no longer need to keep this flag to indicate that the force min cdclk has changed. Instead just check if the old vs. new value are different. Signed-off-by:
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
-
Ville Syrjälä authored
With the dbuf code mostly converted over to the new global state handling we can remove the leftovers of the old global state stuff. Signed-off-by:
-
Ville Syrjälä authored
For platforms that can't do native 4:2:0 outout we may still be able to do it by getting the DP->HDMI protocol converter to perform the 4:4:4->4:2:0 downsamling for us. In this case we have to configure our hardware to output YCbCr 4:4:4, which we've already hooked up so all we need to do is flip the switch. Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
Add helpers to determine whether the DFP supports YCbCr 4:2:0 passthrough or YCbCr 4:4:4->4:2:0 conversion. v2: Add kdocs (Lyude) Signed-off-by:
-
Ville Syrjälä authored
Account for the TMDS clock limits declared by the DFP when determining what color depth we're going to use. v2: Drop the reference to DP++ dongle since it's not handled here Signed-off-by:
-
Ville Syrjälä authored
Pull the "do we want to enable audio?" computation into a small helper to make intel_hdmi_compute_config() less messy. Will make it easier to add more checks for this later (eg. we should actually be checking at the hblank is long enough for audio transmission). Signed-off-by:
-
Ville Syrjälä authored
Use drm_dp_downstream_mode() to get a suitable mode for downstream facing ports which don't have an EDID. Signed-off-by:
-
Ville Syrjälä authored
The downstream facing port caps in the DPCD can give us a hint as to what kind of display mode the sink can use if it doesn't have an EDID. Use that information to pick a suitable mode. v2: Use Returns: for kdoc (Lyude) Add kdocs for drm_display_mode_from_cea_vic() (Lyude) Signed-off-by: -
Ville Syrjälä authored
DP 1.3 adds some extra control knobs for DP->HDMI protocol conversion. Let's use that to configure the "HDMI mode" (ie. infoframes vs. not) based on the capabilities of the sink. Signed-off-by:
-
Ville Syrjälä authored
Use the new helpers to extract the TMDS clock limits from the downstream facing port and check them in .mode_valid(). TODO: we should check these in .compute_config() too to eg. determine if we can do deep color on the HDMI side or not Signed-off-by:
-
Ville Syrjälä authored
Add helpers to get the TMDS clock limits for HDMI/DVI downstream facing ports. Signed-off-by:
-
Ville Syrjälä authored
Move the downstream facing port dotclock check into a new function (intel_dp_mode_valid_downstream()) so that we have a nice future place where we can collect other related checks. Signed-off-by:
-
Ville Syrjälä authored
We want to differentiate between the DFP dotclock and TMDS clock limits. Let's convert the current thing to just give us the dotclock limit. v2: Use Returns: for kdoc (Lyude) Fix up nouveau code too Signed-off-by: -
Ville Syrjälä authored
Deal with more cases in drm_dp_downstream_max_bpc(): - DPCD 1.0 -> assume 8bpc for non-DP - DPCD 1.1+ DP (or DP++ with DP sink) -> allow anything - DPCD 1.1+ TMDS -> check the caps, assume 8bpc if the value is crap - anything else -> assume 8bpc v2: Use Returns: for kdoc (Lyude) Signed-off-by:
-
Ville Syrjälä authored
Add a few helpers to let us better identify which kind of DFP we're dealing with. v2: Use Returns: for kdoc (Lyude) Signed-off-by:
-
Ville Syrjälä authored
Stash the downstream facing port max bpc away during intel_dp_set_edid(). We'll soon need the EDID in there so we can't figure this out so easily during .compute_config() anymore. Signed-off-by:
-
Ville Syrjälä authored
Our definitions for the DPCD DFP capabilities are lacking. Add the missing bits. Signed-off-by:
-
Ville Syrjälä authored
DP 1.3 and 1.4 introduced some new registers for DP->HDMI protocol converters. Define those. Signed-off-by:
-
Ville Syrjälä authored
Non-HDMI sinks shouldn't be sent infoframes. Check for that when using LSPCON. FIXME: How do we turn off infoframes once enabled? Do we even have to? Signed-off-by: -
Ville Syrjälä authored
It helps when the logs have a dump of the DFP capabilities. v2: Move the dumping to the new helper Signed-off-by:
-
- 16 Sep, 2020 2 commits
-
-
Chris Wilson authored
Since we store a pointer to the fake iommu device that is allocated on the stack, as soon as we leave the function it goes out of scope and any future dereference is undefined behaviour. Just in case we may need to look at the fake iommu device after initialiation, move the allocation from the stack into the data. Fixes: 01b9d4e2 ("iommu/vt-d: Use dev_iommu_priv_get/set()") Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200916105022.28316-2-chris@chris-wilson.co.uk
-
Chris Wilson authored
Just in case the caller passes in 0 for both slow&fast timeouts, make sure we initialise the stack value returned. Add an assert so that we don't make the mistake of passing 0 timeouts for the wait. drivers/gpu/drm/i915/intel_uncore.c:2011 __intel_wait_for_register_fw() error: uninitialized symbol 'reg_value'. References: 3f649ab7 ("treewide: Remove uninitialized_var() usage") Signed-off-by:
-
- 15 Sep, 2020 2 commits
-
-
Anusha Srivatsa authored
We currenty check for platform at multiple parts in the driver to grab the correct PLL. Let us begin to centralize it through a helper function. v2: s/intel_get_pll_enable_reg()/intel_combo_pll_enable_reg() (Ville) v3: Clean up combo_pll_disable() (Rodrigo) v4: s/dev_priv/i915 (Jani) Move static and return type to the same line( Ville, Jani) Suggested-by:
Matt Roper <matthew.d.roper@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
Anusha Srivatsa <anusha.srivatsa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200914175703.15024-1-anusha.srivatsa@intel.comReviewed-by:
-
Ville Syrjälä authored
No point in assigning the function return value to a local variable if we're just going to use it the one time. Signed-off-by:
-
