- 31 Mar, 2021 1 commit
-
-
Ankit Nautiyal authored
Currently the FRL training mode (Concurrent, Sequential) and training type (Normal, Extended) are not defined properly and are passed as bool values in drm_helpers for pcon configuration for FRL training. This patch: -Add register masks for Sequential and Normal FRL training options. -Fixes the drm_helpers for FRL Training configuration to use the appropriate masks. -Modifies the calls to the above drm_helpers in i915/intel_dp as per the above change. v2: Re-used the register masks for these options, instead of enum. (Ville) Signed-off-by:
Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by:
Maxime Ripard <mripard@kernel.org> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210323112422.1211-2-ankit.k.nautiyal@intel.com
-
- 29 Mar, 2021 33 commits
-
-
Imre Deak authored
Add selftests to test the POT stride padding functionality added in the previous patch. Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
-
Imre Deak authored
An upcoming platform has a restriction that the FB stride must be power-of-two aligned. To support framebuffer layouts that are not in this layout add a logic that pads the tile rows to the POT aligned size. The HW won't read the padding PTEs, so these don't have to point to an allocated address, or even have their valid flag set. So use a NULL PTE instead for instance the scratch page, which is simple and keeps the SG table compact. v2: - Simplify plane_view_dst_stride(). (Ville) - Pass pitch_tiles as unsigned int. v3: - Drop unintentional s/plane_state->rotation/plane_config->rotation/ change. Signed-off-by:
-
Imre Deak authored
An upcoming patch adds a new dst_stride field to the intel_remapped_plane_info struct, so for clarity rename the current stride field to src_stride. Signed-off-by:
-
Imre Deak authored
Always use the modified copy of the intel_remapped_plane_info variables. An upcoming patch updates the dst_stride field in these copies after which we can't use the original versions. v2: Init view in igt_vma_rotate_remap() when declaring it. (Ville) Signed-off-by:
-
Imre Deak authored
Save some place in the GTT VMAs by using a u16 instead of unsigned int to store the view dimensions. The maximum FB stride is 256kB which is 4096 tiles in the worst case (yf-tiles), the maximum FB height is 16k pixels, which is 16384 tiles in the worst case (linear 4x1 tiled FB). v2: - Fix worst case tile height formula in commit log. (Ville) - Add an assign_chk_ovf helper to simplify the related assignments. v3: - Enclose params of the assign_chk_ovf macro in parentheses. Signed-off-by:
-
Imre Deak authored
Factor out to a new function the logic to calculate the FB remapping parameters both during creating the FB and when flipping to it. v2: - Keep stride next to offset calculation. (Ville) - Enclose check_array_bounds macro arguments in parentheses. v3: - Rebase on top of the struct intel_fb_view refactoring. Signed-off-by:
-
Imre Deak authored
Instead of copying separately the GTT remapped and color plane view info from the FB to the plane state, do this by copying the whole intel_fb_view struct. For this we make sure the FB view state is fully inited (that is also including the view type) already during FB creation, so this init is not required during atomic check time. This also means the we don't need to reset the unused color plane info during atomic check, as these are already reset during FB creation. I noticed that initial FBs will only work atm if they are page aligned (which BIOS most probably always ensures), but add a comment to sanitize this part once. Also we won't disable the plane if get_initial_plane_config() failed for some reason (for instance due to unsupported rotation), add a TODO: comment for this too. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Imre Deak authored
Instead of special casing getting the pitch for the normal view, store it during FB creation to the FB normal view struct and retrieve it from there during atomic check, as it's done for the rotated view. A follow-up patch does the same for a new FB remapped view. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Imre Deak authored
To allow the simplification of FB/plane view computation in the follow-up patches, unify the corresponding state in the intel_framebuffer and intel_plane_state structs into a new intel_fb_view struct. This adds some overhead to intel_framebuffer as the rotated view will have now space for 4 color planes instead of the required 2 and it'll also contain the unused offset for each color_plane info. Imo this is an acceptable trade-off to get a simplified way of the remap computation. Use the new intel_fb_view struct for the FB normal view as well, so (in the follow-up patches) we can remove the special casing for normal view calculation wrt. the calculation of remapped/rotated views. This also adds an overhead to the intel_framebuffer struct, as the gtt remap info and per-color plane offset/pitch is not required for the normal view, but imo this is an acceptable trade-off as above. The per-color plane pitch filed will be used by a follow-up patch, so we can retrieve the pitch for each view in the same way. No functional changes in this patch. v2: - Make the patch have _no functional change_. (fix skl_check_nv12_aux_surface() and skl_check_main_surface()). - s/i915_color_plane_view::pitch/stride/ (Ville) Suggested-by:
-
Imre Deak authored
Factor out to a new function the logic to calculate an FB plane's normal-view size. Instead of using intel_remapped_plane_info, which is related only to remapping, add a helper to get the tile pitch and rows for an FB plane, so these helpers can be used both by the normal size calculation and the remapping code. Also add a new fb_plane_view_dims struct in which we can pass around the view (either FB plane or plane source) and tile dimensions conveniently to functions calculating further view parameters. v2: - Add back the +1 tile adjustment for x!=0 in calc_plane_normal_size(). (Ville) - s/pages/tiles/ in calc_plane_normal_size(). (Ville) - Add a helper for the plane view width calculation. (Ville) - Return tiles as unsigned int from calc_plane_normal_size(). Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Imre Deak authored
Factor out to a new function the logic to convert the FB plane x/y values to a tile size based offset and new x/y relative to this offset. This makes intel_fill_fb_info() and intel_plane_remap_gtt() somewhat more readable. Signed-off-by:
-
Imre Deak authored
Factor out to a new function the logic to convert the FB plane offset to x/y and check the validity of x/y, with the goal to make intel_fill_fb_info() more readable. v2: Use &fb->base instead of a drm_fb alias. (Ville) Signed-off-by:
-
Imre Deak authored
Rename dev_priv to i915 in the intel_fb.[ch] files. Signed-off-by:
-
Imre Deak authored
After the previous patch we can unexport intel_fb_check_stride(), which isn't needed by intel_display.c. Signed-off-by:
-
Imre Deak authored
Move the FB plane specific functions from intel_display.c to intel_fb.c. There's more functions like this, but I leave moving those as well for a follow up, and for now moving only the ones needed by the end of this patchset (adding support for padding tile-rows in an FB GGTT view). Signed-off-by:
-
Imre Deak authored
Move the FB plane specific function from intel_sprite.c to intel_fb.c Signed-off-by:
-
Imre Deak authored
Move is_surface_linear() to intel_fb.c and export it from here, also removing the duplicate definitions of it. Signed-off-by:
-
Imre Deak authored
Move the FB plane related functions from skl_universal_plane.c to intel_fb.c. Signed-off-by:
-
Imre Deak authored
Start collecting all the FB plane related functions into a new intel_fb.c file. v2: Drop display/ part of header includes. (Ville) Signed-off-by:
-
Imre Deak authored
This probably doesn't cause an issue, since the code checks the view type dependent size of the views before comparing them, but let's follow the practice to bzero the whole struct when initializing it. v2: Use {} instead of { } struct intializer. (Ville) Signed-off-by: -
Imre Deak authored
This probably doesn't cause an issue, since the code checks the view type dependent size of the views before comparing them, but let's follow the practice to bzero the whole struct when initializing it. Signed-off-by:
-
Imre Deak authored
The expected/found values were swapped in a debug message, fix this up. Signed-off-by:
-
Imre Deak authored
An inner scope version of err shadows the variable in the outer scope, and err doesn't get set after a failure, fix these. Signed-off-by:
-
Imre Deak authored
The HW plane state is cleared and inited after we store the rotation to it, so store it instead to the uapi state to match what we do with all other plane state until intel_plane_copy_uapi_to_hw_state() is called. Rotation for initial FBs is not supported atm, but let's still fix the plane state setup here. While at it remove the redundant intel_state->uapi.src/dst init, which will be done in intel_plane_copy_uapi_to_hw_state(). v2: Remove redundant intel_state->uapi.src/dst init. (Ville) Signed-off-by:
-
Wan Jiabing authored
struct drm_i915_private, struct intel_crtc_state and struct intel_crtc is declared twice. Remove the duplicate. Reviewed-by:
José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
Wan Jiabing <wanjiabing@vivo.com> Signed-off-by:
-
Ville Syrjälä authored
The dbuf bandwidth calculations don't need the planes to be added to the state. Each plane's data rate has already been precalculated and stored in the crtc state, and that with the dbuf slice usage for each plane is all the dbuf bandwidth code needs to figure out what the minimum cdclk is. What we're trying to do here is make sure each plane recalculates its minimum cdclk (ie. plane->min_cdclk()) on those platforms where the number of active planes affects the result of said calculation. Nothing to do with any dbuf cdclk requirements. Not sure if we had stuff in slightly different order or what, but at least in the current scheme this is not necessary. Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by:
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
-
Jani Nikula authored
Matter of taste. Match the prefix for everything else related to steppings. No functional changes. Reviewed-by:
-
Jani Nikula authored
Matter of taste. Step matches the enums. Reviewed-by:
-
Jani Nikula authored
Matter of taste. STEP matches the enums. Reviewed-by:
-
Jani Nikula authored
This changes the way revids not present in the array are handled: - For gaps in the array, the next present revid is used. - For revids beyond the array, the new STEP_FUTURE is used instead of the last revid in the array. In both cases, we'll get debug logging of what's going on. v2: Rename stepping->step Reviewed-by:
-
Jani Nikula authored
Add new symbolic names for revision ids, and convert KBL revids to use them via the new stepping check macros. This also fixes theoretical out of bounds access to kbl_revids array. v3: upgrade dbg to warn on unknown revid (José) v2: Rename stepping->step Reviewed-by:
-
Jani Nikula authored
Add new runtime info field for stepping. Add new helpers for accessing them. As we'll be switching platforms over to the new scheme incrementally, check for non-initialized steppings. In case a platform does not have separate display and gt steppings, it's okay to use a common shorthand. However, in this case the display stepping must not be initialized, and gt stepping is the single point of truth. v3: Remove IS_STEP() (José) v2: Rename stepping->step Reviewed-by:
-
Jani Nikula authored
gt/intel_workarounds.c is decidedly the wrong place for handling stepping info. Add new intel_step.[ch] for the data, and move the stepping arrays there. No functional changes. v2: Rename stepping->step Reviewed-by:
Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
-
- 26 Mar, 2021 1 commit
-
-
Ville Syrjälä authored
Accidentally transposed the arguments to skl_plane_wm_level() which is causing us to mistakenly think that the plane watermarks have/have not changed when the opposite may be true. Swap the arguments so this actually works. The other uses of this look OK. Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Fixes: 2871b2fd ("drm/i915: Fix TGL+ plane SAGV watermark programming") Signed-off-by:
-
- 24 Mar, 2021 2 commits
-
-
Kai Vehmanen authored
Update logic to program AUD_FREQ_CNTRL register based on new guidance. Earlier this register was configured by BIOS and driver discovered the value at init. This is no longer recommended and instead driver should set the values based on the hardware revision. Add the recommended values for all supported hardware. This change applies for all GEN12+ hardware. For TGL, some special case handling is needed to not break existing systems. Extend the debug print to also include values of the register as written by BIOS. This can help debug rare cases where BIOS has configured the link settings to incorrect values. Bspec: 49279 Signed-off-by:
Kai Vehmanen <kai.vehmanen@linux.intel.com> Reviewed-by:
Uma Shankar <uma.shankar@intel.com> Signed-off-by:
-
Imre Deak authored
To optimize some task deferring it until runtime resume unless someone holds a runtime PM reference (because in this case the task can be done w/o the overhead of runtime resume), we have to use the runtime PM get-if-active logic: If the runtime PM usage count is 0 (and so get-if-in-use would return false) the runtime suspend handler is not necessarily called yet (it could be just pending), so the device is not necessarily powered down, and so the runtime resume handler is not guaranteed to be called. The fence revocation depends on the above deferral, so add a get-if-active helper and use it during fence revocation. v2: - Add code comment explaining the fence reg programming deferral logic to i915_vma_revoke_fence(). (Chris) - Add Cc: stable and Fixes: tags. (Chris) - Fix the function docbook comment. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: <stable@vger.kernel.org> # v4.12+ Fixes: 181df2d4 ("drm/i915: Take rpm wakelock for releasing the fence on unbind") Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
- 23 Mar, 2021 3 commits
-
-
Matt Roper authored
GLK has always been a bit of a special case since it reports INTEL_GEN() as 9, but has version 10 display IP. Now we can properly represent the display version as 10 and simplify the display generation tests throughout the display code. Aside from manually adding the version to the glk_info structure, the rest of this patch is generated with a Coccinelle semantic patch. Note that we also need to switch any code that matches gen10 today but *not* GLK to be CNL-specific: @@ expression dev_priv; @@ - DISPLAY_VER(dev_priv) > 9 + DISPLAY_VER(dev_priv) >= 10 @@ expression dev_priv, E; @@ ( - DISPLAY_VER(dev_priv) >= 10 && E + (DISPLAY_VER(dev_priv) >= 11 || IS_CANNONLAKE(dev_priv)) && E | - DISPLAY_VER(dev_priv) >= 10 + DISPLAY_VER(dev_priv) >= 11 || IS_CANNONLAKE(dev_priv) | - IS_DISPLAY_RANGE(dev_priv, 10, E) + IS_DISPLAY_RANGE(dev_priv, 11, E) || IS_CANNONLAKE(dev_priv) ) @@ expression dev_priv, E, E2; @@ ( - (IS_CANNONLAKE(dev_priv) || IS_GEMINILAKE(dev_priv)) + IS_DISPLAY_VER(dev_priv, 10) | - E || IS_CANNONLAKE(dev_priv) || IS_GEMINILAKE(dev_priv) + E || IS_DISPLAY_VER(dev_priv, 10) | - (IS_GEMINILAKE(dev_priv) || IS_CANNONLAKE(dev_priv)) + IS_DISPLAY_VER(dev_priv, 10) | - IS_GEMINILAKE(dev_priv) || E || IS_CANNONLAKE(dev_priv) + E || IS_DISPLAY_VER(dev_priv, 10) | - E || IS_GEMINILAKE(dev_priv) || E2 || IS_CANNONLAKE(dev_priv) + E || E2 || IS_DISPLAY_VER(dev_priv, 10) | - (IS_DISPLAY_VER(dev_priv, 10) || IS_GEMINILAKE(dev_priv)) + IS_DISPLAY_VER(dev_priv, 10) | - (IS_GEMINILAKE(dev_priv) || IS_DISPLAY_VER(dev_priv, 10)) + IS_DISPLAY_VER(dev_priv, 10) ) @@ expression dev_priv; @@ - (IS_DISPLAY_VER(dev_priv, 9) && !IS_GEMINILAKE(dev_priv)) + IS_DISPLAY_VER(dev_priv, 9) @@ expression dev_priv; @@ ( - !(DISPLAY_VER(dev_priv) >= 11 || IS_DISPLAY_VER(dev_priv, 10)) + DISPLAY_VER(dev_priv) < 10 | - (DISPLAY_VER(dev_priv) >= 11 || IS_DISPLAY_VER(dev_priv, 10)) + DISPLAY_VER(dev_priv) >= 10 ) @@ expression dev_priv, E; @@ - E || DISPLAY_VER(dev_priv) >= 11 || IS_DISPLAY_VER(dev_priv, 10) + E || DISPLAY_VER(dev_priv) >= 10 @@ expression dev_priv, E; @@ - (IS_DISPLAY_RANGE(dev_priv, 11, E) || IS_DISPLAY_VER(dev_priv, 10)) + IS_DISPLAY_RANGE(dev_priv, 10, E) @@ expression dev_priv; @@ ( - DISPLAY_VER(dev_priv) >= 11 || IS_CANNONLAKE(dev_priv) || IS_GEN9_LP(dev_priv) + DISPLAY_VER(dev_priv) >= 10 || IS_GEN9_LP(dev_priv) | - IS_GEN9_LP(dev_priv) || DISPLAY_VER(dev_priv) >= 11 || IS_CANNONLAKE(dev_priv) + IS_GEN9_LP(dev_priv) || DISPLAY_VER(dev_priv) >= 10 ) @@ expression dev_priv, E; @@ - !(DISPLAY_VER(dev_priv) >= E) + DISPLAY_VER(dev_priv) < E v2: - Convert gen10 conditions that don't include GLK into CNL conditions. (Ville) v3: - Rework coccinelle rules so that "ver>=10" turns into "ver>=11||is_cnl." (Ville) v3.1: - Manually re-add the ".display.version = 10" to glk_info after regenerating patch via Coccinelle. v4: - Also apply cocci rules to intel_pm.c and i915_irq.c! (CI) Cc: Ville Syrjälä <ville.syrjala@intel.com> Signed-off-by:Matt Roper <matthew.d.roper@intel.com> Reviewed-by:
-
Matt Roper authored
Convert the display-specific usage of INTEL_GEN, while leaving the non-display usage as-is for now. In the near-future we'll probably want to think about moving display interrupt handling to its own file under the display/ directory. v2: - Use new IS_DISPLAY_VER() macro. Signed-off-by:
-
Matt Roper authored
Although most of the code in this file is display-related (watermarks), there's some functions that are not (e.g., clock gating). Thus we need to do the conversions to DISPLAY_VER() manually here rather than using Coccinelle. In the near-future we'll probably want to think about moving watermark logic out of intel_pm.c and into watermark-specific files under the display/ directory. v2: - Use new IS_DISPLAY_VER macro where appropriate. Signed-off-by:
-
