linux-stable.git/drivers/gpu, branch v6.1.93

drm/i915/guc: avoid FIELD_PREP warning

2024-06-12T09:03:58+00:00

[ Upstream commit d4f36db62396b73bed383c0b6e48d36278cafa78 ]

With gcc-7 and earlier, there are lots of warnings like

In file included from :0:0:
In function '__guc_context_policy_add_priority.isra.66',
    inlined from '__guc_context_set_prio.isra.67' at drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:3292:3,
    inlined from 'guc_context_set_prio' at drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:3320:2:
include/linux/compiler_types.h:399:38: error: call to '__compiletime_assert_631' declared with attribute error: FIELD_PREP: mask is not constant
  _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__)
                                      ^
...
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:2422:3: note: in expansion of macro 'FIELD_PREP'
   FIELD_PREP(GUC_KLV_0_KEY, GUC_CONTEXT_POLICIES_KLV_ID_##id) | \
   ^~~~~~~~~~

Make sure that GUC_KLV_0_KEY is an unsigned value to avoid the warning.

Fixes: 77b6f79df66e ("drm/i915/guc: Update to GuC version 69.0.3")
Signed-off-by: Arnd Bergmann 
Reviewed-by: Michal Wajdeczko 
Signed-off-by: Julia Filipchuk 
Signed-off-by: John Harrison 
Link: https://patchwork.freedesktop.org/patch/msgid/20240430164809.482131-1-julia.filipchuk@intel.com
(cherry picked from commit 364e039827ef628c650c21c1afe1c54d9c3296d9)
Signed-off-by: Jani Nikula 
Signed-off-by: Sasha Levin

drm/msm/a6xx: Avoid a nullptr dereference when speedbin setting fails

2024-06-12T09:03:49+00:00

[ Upstream commit 46d4efcccc688cbacdd70a238bedca510acaa8e4 ]

Calling a6xx_destroy() before adreno_gpu_init() leads to a null pointer
dereference on:

msm_gpu_cleanup() : platform_set_drvdata(gpu->pdev, NULL);

as gpu->pdev is only assigned in:

a6xx_gpu_init()
|_ adreno_gpu_init
    |_ msm_gpu_init()

Instead of relying on handwavy null checks down the cleanup chain,
explicitly de-allocate the LLC data and free a6xx_gpu instead.

Fixes: 76efc2453d0e ("drm/msm/gpu: Fix crash during system suspend after unbind")
Signed-off-by: Konrad Dybcio 
Patchwork: https://patchwork.freedesktop.org/patch/588919/
Signed-off-by: Rob Clark 
Signed-off-by: Sasha Levin

drm/msm: Enable clamp_to_idle for 7c3

2024-06-12T09:03:49+00:00

[ Upstream commit 2c1b7748100e2e40155722589201f24c23ae5d53 ]

This was overlooked.

Signed-off-by: Rob Clark 
Reviewed-by: Douglas Anderson 
Reviewed-by: Chia-I Wu 
Patchwork: https://patchwork.freedesktop.org/patch/511693/
Link: https://lore.kernel.org/r/20221115155535.1615278-1-robdclark@gmail.com
Stable-dep-of: 46d4efcccc68 ("drm/msm/a6xx: Avoid a nullptr dereference when speedbin setting fails")
Signed-off-by: Sasha Levin

Revert "drm/bridge: ti-sn65dsi83: Fix enable error path"

2024-06-12T09:03:48+00:00

[ Upstream commit ad81feb5b6f1f5461641706376dcf7a9914ed2e7 ]

This reverts commit 8a91b29f1f50ce7742cdbe5cf11d17f128511f3f.

The regulator_disable() added by the original commit solves one kind of
regulator imbalance but adds another one as it allows the regulator to be
disabled one more time than it is enabled in the following scenario:

 1. Start video pipeline -> sn65dsi83_atomic_pre_enable -> regulator_enable
 2. PLL lock fails -> regulator_disable
 3. Stop video pipeline -> sn65dsi83_atomic_disable -> regulator_disable

The reason is clear from the code flow, which looks like this (after
removing unrelated code):

  static void sn65dsi83_atomic_pre_enable()
  {
      regulator_enable(ctx->vcc);

      if (PLL failed locking) {
          regulator_disable(ctx->vcc);  <---- added by patch being reverted
          return;
      }
  }

  static void sn65dsi83_atomic_disable()
  {
      regulator_disable(ctx->vcc);
  }

The use case for introducing the additional regulator_disable() was
removing the module for debugging (see link below for the discussion). If
the module is removed after a .atomic_pre_enable, i.e. with an active
pipeline from the DRM point of view, .atomic_disable is not called and thus
the regulator would not be disabled.

According to the discussion however there is no actual use case for
removing the module with an active pipeline, except for
debugging/development.

On the other hand, the occurrence of a PLL lock failure is possible due to
any physical reason (e.g. a temporary hardware failure for electrical
reasons) so handling it gracefully should be supported. As there is no way
for .atomic[_pre]_enable to report an error to the core, the only clean way
to support it is calling regulator_disabled() only in .atomic_disable,
unconditionally, as it was before.

Link: https://lore.kernel.org/all/15244220.uLZWGnKmhe@steina-w/
Fixes: 8a91b29f1f50 ("drm/bridge: ti-sn65dsi83: Fix enable error path")
Reviewed-by: Alexander Stein 
Signed-off-by: Luca Ceresoli 
Signed-off-by: Robert Foss 
Link: https://patchwork.freedesktop.org/patch/msgid/20240426122259.46808-1-luca.ceresoli@bootlin.com
(cherry picked from commit 2940ee03b23281071620dda1d790cd644dabd394)
Signed-off-by: Maarten Lankhorst 
Signed-off-by: Sasha Levin

drm/bridge: tc358775: fix support for jeida-18 and jeida-24

2024-06-12T09:03:46+00:00

[ Upstream commit 30ea09a182cb37c4921b9d477ed18107befe6d78 ]

The bridge always uses 24bpp internally. Therefore, for jeida-18
mapping we need to discard the lowest two bits for each channel and thus
starting with LV_[RGB]2. jeida-24 has the same mapping but uses four
lanes instead of three, with the forth pair transmitting the lowest two
bits of each channel. Thus, the mapping between jeida-18 and jeida-24
is actually the same, except that one channel is turned off (by
selecting the RGB666 format in VPCTRL).

While at it, remove the bogus comment about the hardware default because
the default is overwritten in any case.

Tested with a jeida-18 display (Evervision VGG644804).

Fixes: b26975593b17 ("display/drm/bridge: TC358775 DSI/LVDS driver")
Signed-off-by: Michael Walle 
Signed-off-by: Tony Lindgren 
Reviewed-by: Robert Foss 
Signed-off-by: Robert Foss 
Link: https://patchwork.freedesktop.org/patch/msgid/20240225062008.33191-5-tony@atomide.com
Signed-off-by: Sasha Levin

drm/mediatek: dp: Fix mtk_dp_aux_transfer return value

2024-06-12T09:03:46+00:00

[ Upstream commit 8431fff9e0f3fc1c5844cf99a73b49b63ceed481 ]

In case there is no DP device attached to the port the
transfer function should return IO error, similar to what
other drivers do.
In case EAGAIN is returned then any read from /dev/drm_dp_aux
device ends up in an infinite loop as the upper layers
constantly repeats the transfer request.

Fixes: f70ac097a2cf ("drm/mediatek: Add MT8195 Embedded DisplayPort driver")
Signed-off-by: Wojciech Macek 
Reviewed-by: AngeloGioacchino Del Regno 
Reviewed-by: CK Hu 
Link: https://patchwork.kernel.org/project/dri-devel/patch/20240417103819.990512-1-wmacek@chromium.org/
Signed-off-by: Chun-Kuang Hu 
Signed-off-by: Sasha Levin

drm/mediatek: dp: Add support for embedded DisplayPort aux-bus

2024-06-12T09:03:46+00:00

[ Upstream commit caf2ae486742f6a93ca676bbebdfacfd34e4966d ]

For the eDP case we can support using aux-bus on MediaTek DP: this
gives us the possibility to declare our panel as generic "panel-edp"
which will automatically configure the timings and available modes
via the EDID that we read from it.

To do this, move the panel parsing at the end of the probe function
so that the hardware is initialized beforehand and also initialize
the DPTX AUX block and power both on as, when we populate the
aux-bus, the panel driver will trigger an EDID read to perform
panel detection.

Last but not least, since now the AUX transfers can happen in the
separated aux-bus, it was necessary to add an exclusion for the
cable_plugged_in check in `mtk_dp_aux_transfer()` and the easiest
way to do this is to simply ignore checking that when the bridge
type is eDP.

Signed-off-by: AngeloGioacchino Del Regno 
Tested-by: Chen-Yu Tsai 
Reviewed-by: Alexandre Mergnat 
Reviewed-by: CK Hu 
Link: https://patchwork.kernel.org/project/dri-devel/patch/20230725073234.55892-10-angelogioacchino.delregno@collabora.com/
Signed-off-by: Chun-Kuang Hu 
Stable-dep-of: 8431fff9e0f3 ("drm/mediatek: dp: Fix mtk_dp_aux_transfer return value")
Signed-off-by: Sasha Levin

drm/mediatek: dp: Move PHY registration to new function

2024-06-12T09:03:45+00:00

[ Upstream commit 18ccc237cf646f93e25b802e5cca0788f4f48b39 ]

In preparation for adding support for eDP, move the PHY registration
code to a new mtk_dp_register_phy() function for better readability.

This commit brings no functional changes.

Signed-off-by: AngeloGioacchino Del Regno 
Tested-by: Chen-Yu Tsai 
Reviewed-by: Alexandre Mergnat 
Reviewed-by: CK Hu 
Link: https://patchwork.kernel.org/project/dri-devel/patch/20230725073234.55892-9-angelogioacchino.delregno@collabora.com/
Signed-off-by: Chun-Kuang Hu 
Stable-dep-of: 8431fff9e0f3 ("drm/mediatek: dp: Fix mtk_dp_aux_transfer return value")
Signed-off-by: Sasha Levin

drm/msm/dpu: Always flush the slave INTF on the CTL

2024-06-12T09:03:45+00:00

[ Upstream commit 2b938c3ab0a69ec6ea587bbf6fc2aec3db4a8736 ]

As we can clearly see in a downstream kernel [1], flushing the slave INTF
is skipped /only if/ the PPSPLIT topology is active.

However, when DPU was originally submitted to mainline PPSPLIT was no
longer part of it (seems to have been ripped out before submission), but
this clause was incorrectly ported from the original SDE driver.  Given
that there is no support for PPSPLIT (currently), flushing the slave
INTF should /never/ be skipped (as the `if (ppsplit && !master) goto
skip;` clause downstream never becomes true).

[1]: https://git.codelinaro.org/clo/la/platform/vendor/opensource/display-drivers/-/blob/display-kernel.lnx.5.4.r1-rel/msm/sde/sde_encoder_phys_cmd.c?ref_type=heads#L1131-1139

Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
Signed-off-by: Marijn Suijten 
Reviewed-by: Dmitry Baryshkov 
Patchwork: https://patchwork.freedesktop.org/patch/589901/
Link: https://lore.kernel.org/r/20240417-drm-msm-initial-dualpipe-dsc-fixes-v1-3-78ae3ee9a697@somainline.org
Signed-off-by: Dmitry Baryshkov 
Signed-off-by: Sasha Levin

drm/msm/dsi: Print dual-DSI-adjusted pclk instead of original mode pclk

2024-06-12T09:03:45+00:00

[ Upstream commit f12e0e12524a34bf145f7b80122e653ffe3d130a ]

When dual-DSI (bonded DSI) was added in commit ed9976a09b48
("drm/msm/dsi: adjust dsi timing for dual dsi mode") some DBG() prints
were not updated, leading to print the original mode->clock rather
than the adjusted (typically the mode clock divided by two, though more
recently also adjusted for DSC compression) msm_host->pixel_clk_rate
which is passed to clk_set_rate() just below.  Fix that by printing the
actual pixel_clk_rate that is being set.

Fixes: ed9976a09b48 ("drm/msm/dsi: adjust dsi timing for dual dsi mode")
Signed-off-by: Marijn Suijten 
Reviewed-by: Dmitry Baryshkov 
Patchwork: https://patchwork.freedesktop.org/patch/589896/
Link: https://lore.kernel.org/r/20240417-drm-msm-initial-dualpipe-dsc-fixes-v1-1-78ae3ee9a697@somainline.org
Signed-off-by: Dmitry Baryshkov 
Signed-off-by: Sasha Levin