- 13 Dec, 2023 7 commits
-
-
Ville Syrjälä authored
The cdclk->voltage_level if ladders are hard to read, especially as they're written the other way around compared to how bspec lists the limits. Let's rewrite them to use simple arrays that gives us the max cdclk for each voltage level. v2: Bump the jsl/ehl max cdclk in the table to 652.8 MHz to accommodate JSL machines in CI that boot with high cdclk Reviewed-by:Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231211221759.29725-1-ville.syrjala@linux.intel.com
-
Ville Syrjälä authored
Currently we have a hardcoded assumption that the cdclk divider (2*cd2x divider) is always 2 when squashing is used. While that is true for all current platforms it might not hold in the future. So eliminate the assumption and calculate the correct divider from the other parameters. v2: s/cd2x divider/cdclk divider/ (Gustavo) s/clock/unsquashed_cdclk/ (Gustavo) Reviewed-by: -
Ville Syrjälä authored
Replace the slightly magic 'size = 16' with a bit more descriptive name. We'll have another user for this value later on. Signed-off-by:
-
Ville Syrjälä authored
cdclk_pll_is_unknown() used ~0 when checking for the "VCO is unknown" value, but the assignment uses -1. They are the same in the end, but let's use the same ~0 form on both sides for consistency. Signed-off-by:
-
Ville Syrjälä authored
Currently async flips are busted when bigjoiner is in use. As a short term fix simply reject async flips in that case. Cc: stable@vger.kernel.org Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9769Signed-off-by:
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
-
Mika Kahola authored
When going through the disconnection flow we don't need to wait for PHY readiness and hence we can skip the wait part. For disabling the function returns false as an indicator that the power is not enabled. After all, we are not even using the return value when Type-C is disconnecting. v2: Cleanup for increased readibility (Imre) BSpec: 65380 For VLK-53734 Signed-off-by:
Mika Kahola <mika.kahola@intel.com> Reviewed-by:
Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231212115130.485911-1-mika.kahola@intel.com
-
Ankit Nautiyal authored
Currently we get bigjoiner config after the dsc get config, during HW readout. Since dsc_get_config now uses bigjoiner flags/pipes to compute DSC PPS parameter pic_width, this results in a state mismatch when Bigjoiner and DSC are used together. So call get bigjoiner config before calling dsc get config function. Fixes: 8b70b569 ("drm/i915/vdsc: Fill the intel_dsc_get_pps_config function") Cc: Suraj Kandpal <suraj.kandpal@intel.com> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Cc: Animesh Manna <animesh.manna@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by:
Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by:
Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231122064627.905828-1-ankit.k.nautiyal@intel.com
-
- 11 Dec, 2023 2 commits
-
-
Andrzej Hajda authored
Cursor size reduction is not supported since MTL. Signed-off-by:
Andrzej Hajda <andrzej.hajda@intel.com> Reviewed-by:
Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231124-cur_size_reduction-v1-1-30495dba475f@intel.com
-
Jani Nikula authored
The eDP 1.5 spec adds a clarification for eDP 1.4x: > For eDP v1.4x, if the Source device chooses the Main-Link rate by way > of DPCD 00100h, the Sink device shall ignore DPCD 00115h[2:0]. We write 0 to DP_LINK_BW_SET (DPCD 100h) even when using DP_LINK_RATE_SET (DPCD 114h). Stop doing that, as it can cause the panel to ignore the rate set method. Moreover, 0 is a reserved value for DP_LINK_BW_SET, and should not be used. v2: Improve the comments (Ville) Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9081Tested-by:
Animesh Manna <animesh.manna@intel.com> Reviewed-by:
Uma Shankar <uma.shankar@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231205180551.2476228-1-jani.nikula@intel.com
-
- 09 Dec, 2023 2 commits
-
-
Ville Syrjälä authored
Since flip_done_handler() is always called from the irq handler we can skip the irqsave/restore dance. Signed-off-by:
Arun R Murthy <arun.r.murthy@intel.com>
-
Ville Syrjälä authored
Assuming crtc->state is pointing at the correct thing for the async flip commit is nonsense. If we had already queued up multiple commits this would point at the very lates crtc state even if the older commits hadn't even happened yet. Instead properly stage/arm the event like we do for async flips. Since we don't need to arm multiple of these at the same time we don't need a list like the normal vblank even processing uses. Signed-off-by:
-
- 08 Dec, 2023 12 commits
-
-
Radhakrishna Sripada authored
With the cleanup of the misleading clock value to avoid extra calculations to convert between link_bit_rate and clock, use one standard "clock" field for the c20 pll which works with crtc_state->port_clock field. Cc: Clint Taylor <clinton.a.taylor@intel.com> Cc: Mika Kahola <mika.kahola@intel.com> Signed-off-by:
Radhakrishna Sripada <radhakrishna.sripada@intel.com> Reviewed-by:
-
Radhakrishna Sripada authored
The field link_bit_rate serves as the actual clock value for the C20 pll_state structure. Remove the misleading clock field. The subsequent patch would rename the link_bit_rate as the clock field. Cc: Clint Taylor <clinton.a.taylor@intel.com> Cc: Mika Kahola <mika.kahola@intel.com> Signed-off-by:
-
Radhakrishna Sripada authored
In C20 pll_state link_bit_rate and clock fields are bit redundant. Since many of the helpers assume the clock values, which are different from link_bit_rate for dp2.0, convert the helpers to use the numbers that are compatible with link_bit_rate. Currently link_bit_rate is compatible with crtc_state->port_clock. The function intel_c20pll_calc_port_clock returns the number which is compatible with crtc_state->port_clock. In order to avoid extra conversions b/ween clock and link_bit_rate, remove "clock" field from the C20 pll_state and then rename "link_bit_rate" as "clock". While at it rely on crtc_state->port_clock during C20 Pll programming. Cc: Clint Taylor <clinton.a.taylor@intel.com> Cc: Mika Kahola <mika.kahola@intel.com> Signed-off-by:
-
Ville Syrjälä authored
Neither 'tv_mode' or 'color_conversion' can be NULL, so drop the pointless checks. Signed-off-by:
-
Ville Syrjälä authored
Use standard variable name 'crtc_state' instead of 'cstate'. Signed-off-by:
-
Ville Syrjälä authored
intel_get_frame_time_us() is never called with a NULL crtc_state so drop the redundant check. Signed-off-by:
-
Ville Syrjälä authored
intel_fb_uses_dpt() should not be called with a NULL fb, so drop the check. Signed-off-by:
-
Ville Syrjälä authored
intel_crtc_active() is never called with a NULL crtc. Drop the redundant NULL check. Signed-off-by:
-
Ville Syrjälä authored
intel_bios_get_dsc_params() is only called from gen11_dsi_dsc_compute_config() and it always passes a non-NULL crtc_state in. Drop the redundant check. Signed-off-by:
-
Ville Syrjälä authored
intel_dsc_pps_read() is rather convoluted. Make it legible. Signed-off-by:
-
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ä 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:
-
- 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:
-
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 2 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:
-
