- 08 Dec, 2023 2 commits
-
-
Ville Syrjälä authored
Since the plane_state variable is declared outside the scaler_users loop in intel_atomic_setup_scalers(), and it's never reset back to NULL inside the loop we may end up calling intel_atomic_setup_scaler() with a non-NULL plane state for the pipe scaling case. That is bad because intel_atomic_setup_scaler() determines whether we are doing plane scaling or pipe scaling based on plane_state!=NULL. The end result is that we may miscalculate the scaler mode for pipe scaling. The hardware becomes somewhat upset if we end up in this situation when scanning out a planar format on a SDR plane. We end up programming the pipe scaler into planar mode as well, and the result is a screenfull of garbage. Fix the situation by making sure we pass the correct plane_state==NULL when calculating the scaler mode for pipe scaling. Cc: stable@vger.kernel.org Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231207193441.20206-2-ville.syrjala@linux.intel.comReviewed-by:
Jani Nikula <jani.nikula@intel.com>
-
Ville Syrjälä authored
On ADL+ the hardware automagically calculates the CCS AUX surface stride from the main surface stride, so when remapping we can't really play a lot of tricks with the main surface stride, or else the AUX surface stride would get miscalculated and no longer match the actual data layout in memory. Supposedly we could remap in 256 main surface tile units (AUX page(4096)/cachline(64)*4(4x1 main surface tiles per AUX cacheline)=256 main surface tiles), but the extra complexity is probably not worth the hassle. So let's just make sure our mapping stride is calculated from the full framebuffer stride (instead of the framebuffer width). This way the stride we program into PLANE_STRIDE will be the original framebuffer stride, and thus there will be no change to the AUX stride/layout. Cc: stable@vger.kernel.org Cc: Imre Deak <imre.deak@intel.com> Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Signed-off-by:
Imre Deak <imre.deak@intel.com>
-
- 07 Dec, 2023 7 commits
-
-
Jouni Högander authored
Xe needs intel_fb_bo_framebuffer_fini for taking care of unpinning the fb and taking reference. In i915 this can be empty. Also move intel_frontbuffer_get to be done after intel_fb_bo_framebuffer_init to have reasonable sequences: intel_fb_bo_framebuffer_init intel_frontbuffer_get ... intel_frontbuffer_put intel_fb_bo_framebuffer_fini v2: Empty function instead of define Signed-off-by:
Jouni Högander <jouni.hogander@intel.com> Reviewed-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231207083451.2184562-1-jouni.hogander@intel.com
-
Maarten Lankhorst authored
Works better for xe like that. obj is no longer const. Signed-off-by:
-
Jani Nikula authored
Octal permissions are preferred over the symbolics ones. Signed-off-by:
-
Jani Nikula authored
Prefer struct intel_connector over struct drm_connector, and unify the declarations in the fops. Signed-off-by:
-
Jani Nikula authored
Prefer struct intel_connector over struct drm_connector. Signed-off-by:
-
Jani Nikula authored
Reduce the duplication. Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231205121545.2338665-1-jani.nikula@intel.com
-
Luca Coelho authored
The uncore code may not always be available (e.g. when we build the display code with Xe), so we can't always rely on having the uncore's spinlock. To handle this, split the spin_lock/unlock_irqsave/restore() into spin_lock/unlock() followed by a call to local_irq_save/restore() and create wrapper functions for locking and unlocking the uncore's spinlock. In these functions, we have a condition check and only actually try to lock/unlock the spinlock when I915 is defined, and thus uncore is available. This keeps the ifdefs contained in these new functions and all such logic inside the display code. Cc: Tvrtko Ursulin <tvrto.ursulin@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
Luca Coelho <luciano.coelho@intel.com> Reviewed-by:
-
- 05 Dec, 2023 1 commit
-
-
Ville Syrjälä authored
plane_view_scanout_stride() currently assumes that we had to pad the mapping stride with dummy pages in order to align it. But that is not the case if the original fb stride exceeds the aligned stride used to populate the remapped view, which is calculated from the user specified framebuffer width rather than the user specified framebuffer stride. Ignore the original fb stride in this case and just stick to the POT aligned stride. Getting this wrong will cause the plane to fetch the wrong data, and can lead to fault errors if the page tables at the bogus location aren't even populated. TODO: figure out if this is OK for CCS, or if we should instead increase the width of the view to cover the entire user specified fb stride instead... Cc: Imre Deak <imre.deak@intel.com> Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Signed-off-by:
Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
-
- 04 Dec, 2023 7 commits
-
-
Hans de Goede authored
soc_gpio_set_value() already uses devm_gpiod_get(), lets be consistent and use devm_gpiod_get() for all GPIOs. This allows removing the intel_dsi_vbt_gpio_cleanup() function, which only function was to put the GPIO-descriptors. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Reviewed-by:
Andy Shevchenko <andy@kernel.org> Acked-by:
-
Andy Shevchenko authored
The driver uses math.h and not util_macros.h. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by:
-
Jani Nikula authored
The code is fine, really, but tweak it to get rid of the sparse warning: drivers/gpu/drm/i915/selftests/i915_syncmap.c:80:54: warning: dubious: x | !y Signed-off-by:
-
Jouni Högander authored
We are preparing for Xe driver. Backing object implementation is differing between i915 and Xe. Split i915 specific code into separate source file built only for i915. v9: - Use ERR_CAST v8: - return original error code from intel_fb_bo_lookup_valid_bo on failure v7: - drop #include <drm/drm_plane.h> - s/user_mode_cmd/mode_cmd/ - Use passed i915 pointer instead of to_i915(obj->base.dev) v6: Add missing intel_fb_bo.[ch] v5: - Keep drm_any_plane_has_format check in intel_fb.c - Use mode_cmd instead of user_mode_cmd for intel_fb_bo_lookup_valid_bo v4: Move drm_any_plane_has_format check into intel_fb_bo.c v3: Fix failure handling in intel_framebuffer_init v2: Couple of fixes to error value handling Signed-off-by:
-
Jouni Högander authored
Lookup_modifier is returning INTEL_PLANE_CAP_TILING_4 on invalid fb_modifier value. Use lookup_modifier_or_null in intel_fb_modifier_to_tiling and return I915_TILING_NONE in case lookup_modifier_or_null returns null. Signed-off-by:
-
Jouni Högander authored
We are about to split i915 specific code from intel_fb.c. Convert intel_fb_modifier_to_tiling as non-static to allow calling it from split code. Signed-off-by:
-
Jouni Högander authored
We are preparing for Xe driver. I915 and Xe object implementation are differing. Do not use i915_gem_object->base directly. Instead use intel_bo_to_drm_bo. Also use drm_gem_object_put instead of i915_gem_object_put. This should be ok as i915_gem_object_put is really just doing __drm_gem_object_put. Signed-off-by:
-
- 01 Dec, 2023 5 commits
-
-
Jouni Högander authored
We are preparing for Xe driver. I915 and Xe object implementation are differing. Do not use i915_gem_object->base directly. Instead use intel_bo_to_drm_bo. Signed-off-by:
Vinod Govindapillai <vinod.govindapillai@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231115090719.3210079-3-jouni.hogander@intel.com
-
Jouni Högander authored
Split out code from intel_fbdev that can not be share between i915 and xe. Create new i915 specific source/header file intel_fbdev_fb.[ch] which contains this code. Signed-off-by:
-
Mika Kahola authored
With TBT-ALT mode we are not programming C20 chip PLL's and hence we don't need to check state verification. We don't need to program DP link signal levels i.e.pre-emphasis and voltage swing either. This patch fixes dmesg errors like this one "[drm] ERROR PHY F Write 0c06 failed after 3 retries." Signed-off-by:
Mika Kahola <mika.kahola@intel.com> Reviewed-by:
Gustavo Sousa <gustavo.sousa@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231129122221.1109084-1-mika.kahola@intel.com
-
Jani Nikula authored
Avoid bool/int mismatches in state checker macros. Signed-off-by:
-
Jani Nikula authored
Don't treat bools as integers. v2: Rebase Signed-off-by:
-
- 29 Nov, 2023 10 commits
-
-
Clint Taylor authored
DDC pin mapping for DGFX cards uses direct VBT pin mapping Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
Clint Taylor <clinton.a.taylor@intel.com> Reviewed-by:
Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231128190329.1335562-1-lucas.demarchi@intel.comSigned-off-by:
-
Balasubramani Vivekanandan authored
WAs 14011508470, 14011503030 were applied on IP versions beyond which they are applicable. Fixed the IP version checks for these workarounds. Signed-off-by:
Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
-
heminhong authored
Current, the dewake_scanline variable is defined as unsigned int, an unsigned int variable that is always greater than or equal to 0. when _intel_dsb_commit function is called by intel_dsb_commit function, the dewake_scanline variable may have an int value. So the dewake_scanline variable is necessary to defined as an int. Fixes: f83b94d2 ("drm/i915/dsb: Use DEwake to combat PkgC latency") Reported-by:
kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202310052201.AnVbpgPr-lkp@intel.com/ Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Uma Shankar <uma.shankar@intel.com> Signed-off-by:
heminhong <heminhong@kylinos.cn> Reviewed-by:
-
Rahul Rameshbabu authored
Dump the iir value in hex when the interrupt is unexpected. Link: https://gitlab.freedesktop.org/drm/intel/-/issues/9652#note_2178501 Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by:
Rahul Rameshbabu <sergeantsagara@protonmail.com> Reviewed-by:
Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Signed-off-by:
-
Ville Syrjälä authored
Use the >= and < operators for the DISPLAY_VER checks everywhere. This is what most of the code does, but especially recently random pieces of code have started doing this differently for no good reason. Conversion done with the following cocci: @find@ expression i915; constant ver; @@ ( DISPLAY_VER(i915) <= ver | DISPLAY_VER(i915) > ver ) @script:python inc@ old_ver << find.ver; new_ver; @@ coccinelle.new_ver = str(int(old_ver) + 1) @@ expression find.i915; constant find.ver; identifier inc.new_ver; @@ ( - DISPLAY_VER(i915) <= ver + DISPLAY_VER(i915) < new_ver | - DISPLAY_VER(i915) > ver + DISPLAY_VER(i915) >= new_ver ) Signed-off-by:
-
Ville Syrjälä authored
We have no bigjoiner support in the MST code, so .mode_valid() pretending otherwise is just going to result black screens for users. Reject any mode that needs the joiner. Cc: stable@vger.kernel.org Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Fixes: d51f25eb ("drm/i915: Add DSC support to MST path") Signed-off-by:
-
Ville Syrjälä authored
.mode_valid_ctx() returns an errno, not the mode status. Fix the code to do the right thing. Cc: stable@vger.kernel.org Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Fixes: d51f25eb ("drm/i915: Add DSC support to MST path") Signed-off-by:
-
Ville Syrjälä authored
Apparently some BXT/GLK systems have DSI panels whose timings don't agree with the normal cpu transcoder hblank>=32 limitation. This is perhaps fine as there are no specific hblank/etc. limits listed for the BXT/GLK DSI transcoders. Move those checks out from the global intel_mode_valid() into into connector specific .mode_valid() hooks, skipping BXT/GLK DSI connectors. We'll leave the basic [hv]display/[hv]total checks in intel_mode_valid() as those seem like sensible upper limits regardless of the transcoder used. Cc: stable@vger.kernel.org Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9720 Fixes: 8f4b1068 ("drm/i915: Check some transcoder timing minimum limits") Signed-off-by:
-
Ville Syrjälä authored
Currently no one can figure out what the PSR code is doing since we're including any of it in the basic state dump. Add at least the bare minimum there. v2: Also dump has_panel_replay (Jouni) Cc: Jouni Högander <jouni.hogander@intel.com> Signed-off-by:
-
Vinod Govindapillai authored
In earlier versions, FBC was restricted if PSR2 is enabled. From xe2lpd onwards no such restrictions are needed anymore. HSD: 14014305387 Signed-off-by:
-
- 27 Nov, 2023 2 commits
-
-
Jouni Högander authored
Currently we are enabling selective fetch for all planes that are visible. This is suboptimal as we might be fetching for memory for planes that are not part of selective update. Fix this by adding proper handling for disabling plane selective fetch: If plane previously part of selective update is now not part of update: Add it into updated planes and let the plane configuration to disable selective fetch for it. v3: Checkpatch warnings fixed v2: - Add setting sel_fetch_area->y1/y2 to -1 - Remove setting again local sel_fetch_area variable Signed-off-by:
-
Jouni Högander authored
Currently selective fetch configuration for planes is implemented in psr code. More suitable place for this code is where everything else is configured for planes -> move it into skl_universal_plane.c and intel_cursor.c. This also allows us to drop hooks for cursor handling. v3: Checkpatch warnings fixed v2: Removed setting sel_fetch_area->y1/y2 as -1 Signed-off-by:
-
- 24 Nov, 2023 2 commits
-
-
Ville Syrjälä authored
Adding ad-hoc debug prints all over the place is not good. Move the SDP split debug spew into the proper place (state dumper). Signed-off-by:
-
Ville Syrjälä authored
Print the pipe name in ascii rather than hex. Signed-off-by:
-
- 23 Nov, 2023 4 commits
-
-
Ville Syrjälä authored
The current implementation of change_lut_val_precision() is just a convoluted way of shifting by 8. Implement the proper rounding by just using drm_color_lut_extract() and intel_color_lut_pack() like everyone else does. And as the uapi can't handle >=1.0 values but the hardware can we need to clamp the results appropriately in the readout path. Signed-off-by:
-
Ville Syrjälä authored
Use min() instead of clamp() since the color values involved are unsigned. No functional changes. Signed-off-by:
-
Ville Syrjälä authored
drm_color_lut_extract() rounding was changed to follow the OpenGL int<->float conversion rules. Adjust intel_color_lut_pack() to match. Signed-off-by:
-
Ville Syrjälä authored
The current implementation of drm_color_lut_extract() generates weird results. Eg. if we go through all the values for 16->8bpc conversion we see the following pattern: in out (count) 0 - 7f -> 0 (128) 80 - 17f -> 1 (256) 180 - 27f -> 2 (256) 280 - 37f -> 3 (256) ... fb80 - fc7f -> fc (256) fc80 - fd7f -> fd (256) fd80 - fe7f -> fe (256) fe80 - ffff -> ff (384) So less values map to 0 and more values map 0xff, which doesn't seem particularly great. To get just the same number of input values to map to the same output values we'd just need to drop the rounding entrirely. But perhaps a better idea would be to follow the OpenGL int<->float conversion rules, in which case we get the following results: in out (count) 0 - 80 -> 0 (129) 81 - 181 -> 1 (257) 182 - 282 -> 2 (257) 283 - 383 -> 3 (257) ... fc7c - fd7c -> fc (257) fd7d - fe7d -> fd (257) fe7e - ff7e -> fe (257) ff7f - ffff -> ff (129) Note that since the divisor is constant the compiler is able to optimize away the integer division in most cases. The only exception is the _ULL() case on 32bit architectures since that gets emitted as inline asm via do_div() and thus the compiler doesn't get to optimize it. Signed-off-by:
Maxime Ripard <mripard@kernel.org>
-
