linux-stable.git/drivers/gpu/drm/bridge, branch v6.10

drm/bridge/panel: Fix runtime warning on panel bridge release

2024-06-10T11:22:05+00:00

Device managed panel bridge wrappers are created by calling to
drm_panel_bridge_add_typed() and registering a release handler for
clean-up when the device gets unbound.

Since the memory for this bridge is also managed and linked to the panel
device, the release function should not try to free that memory.
Moreover, the call to devm_kfree() inside drm_panel_bridge_remove() will
fail in this case and emit a warning because the panel bridge resource
is no longer on the device resources list (it has been removed from
there before the call to release handlers).

Fixes: 67022227ffb1 ("drm/bridge: Add a devm_ allocator for panel bridge.")
Signed-off-by: Adam Miotk 
Signed-off-by: Maxime Ripard 
Link: https://patchwork.freedesktop.org/patch/msgid/20240610102739.139852-1-adam.miotk@arm.com

Merge tag 'drm-next-2024-05-25' of https://gitlab.freedesktop.org/drm/kernel

2024-05-25T00:28:02+00:00

Pull drm fixes from Dave Airlie:
 "Some fixes for the end of the merge window, mostly amdgpu and panthor,
  with one nouveau uAPI change that fixes a bad decision we made a few
  months back.

  nouveau:
   - fix bo metadata uAPI for vm bind

  panthor:
   - Fixes for panthor's heap logical block.
   - Reset on unrecoverable fault
   - Fix VM references.
   - Reset fix.

  xlnx:
   - xlnx compile and doc fixes.

  amdgpu:
   - Handle vbios table integrated info v2.3

  amdkfd:
   - Handle duplicate BOs in reserve_bo_and_cond_vms
   - Handle memory limitations on small APUs

  dp/mst:
   - MST null deref fix.

  bridge:
   - Don't let next bridge create connector in adv7511 to make probe
     work"

* tag 'drm-next-2024-05-25' of https://gitlab.freedesktop.org/drm/kernel:
  drm/amdgpu/atomfirmware: add intergrated info v2.3 table
  drm/mst: Fix NULL pointer dereference at drm_dp_add_payload_part2
  drm/amdkfd: Let VRAM allocations go to GTT domain on small APUs
  drm/amdkfd: handle duplicate BOs in reserve_bo_and_cond_vms
  drm/bridge: adv7511: Attach next bridge without creating connector
  drm/buddy: Fix the warn on's during force merge
  drm/nouveau: use tile_mode and pte_kind for VM_BIND bo allocations
  drm/panthor: Call panthor_sched_post_reset() even if the reset failed
  drm/panthor: Reset the FW VM to NULL on unplug
  drm/panthor: Keep a ref to the VM at the panthor_kernel_bo level
  drm/panthor: Force an immediate reset on unrecoverable faults
  drm/panthor: Document drm_panthor_tiler_heap_destroy::handle validity constraints
  drm/panthor: Fix an off-by-one in the heap context retrieval logic
  drm/panthor: Relax the constraints on the tiler chunk size
  drm/panthor: Make sure the tiler initial/max chunks are consistent
  drm/panthor: Fix tiler OOM handling to allow incremental rendering
  drm: xlnx: zynqmp_dpsub: Fix compilation error
  drm: xlnx: zynqmp_dpsub: Fix few function comments

Merge tag 'i2c-for-6.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux

2024-05-20T15:55:18+00:00

Pull i2c updates from Wolfram Sang:
 "i2c core removes an argument from the i2c_mux_add_adapter() call to
  further deprecate class based I2C device instantiation. All users are
  converted, too.

  Other that that, Andi collected a number if I2C host driver patches.
  Those merges have their own description"

* tag 'i2c-for-6.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: (72 commits)
  power: supply: sbs-manager: Remove class argument from i2c_mux_add_adapter()
  i2c: mux: Remove class argument from i2c_mux_add_adapter()
  i2c: synquacer: Fix an error handling path in synquacer_i2c_probe()
  i2c: acpi: Unbind mux adapters before delete
  i2c: designware: Replace MODULE_ALIAS() with MODULE_DEVICE_TABLE()
  i2c: pxa: use 'time_left' variable with wait_event_timeout()
  i2c: s3c2410: use 'time_left' variable with wait_event_timeout()
  i2c: rk3x: use 'time_left' variable with wait_event_timeout()
  i2c: qcom-geni: use 'time_left' variable with wait_for_completion_timeout()
  i2c: jz4780: use 'time_left' variable with wait_for_completion_timeout()
  i2c: synquacer: use 'time_left' variable with wait_for_completion_timeout()
  i2c: stm32f7: use 'time_left' variable with wait_for_completion_timeout()
  i2c: stm32f4: use 'time_left' variable with wait_for_completion_timeout()
  i2c: st: use 'time_left' variable with wait_for_completion_timeout()
  i2c: omap: use 'time_left' variable with wait_for_completion_timeout()
  i2c: imx-lpi2c: use 'time_left' variable with wait_for_completion_timeout()
  i2c: hix5hd2: use 'time_left' variable with wait_for_completion_timeout()
  i2c: exynos5: use 'time_left' variable with wait_for_completion_timeout()
  i2c: digicolor: use 'time_left' variable with wait_for_completion_timeout()
  i2c: amd-mp2-plat: use 'time_left' variable with wait_for_completion_timeout()
  ...

drm/bridge: adv7511: Attach next bridge without creating connector

2024-05-19T21:23:23+00:00

The connector is created by either this ADV7511 bridge driver or
any DRM device driver/previous bridge driver, so this ADV7511
bridge driver should not let the next bridge driver create connector.

If the next bridge is a HDMI connector, the next bridge driver
would fail to attach bridge from display_connector_attach() without
the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag.

Add that flag to drm_bridge_attach() function call in
adv7511_bridge_attach() to fix the issue.

This fixes the issue where the HDMI connector bridge fails to attach
to the previous ADV7535 bridge on i.MX8MP EVK platform:

[    2.216442] [drm:drm_bridge_attach] *ERROR* failed to attach bridge /hdmi-connector to encoder None-37: -22
[    2.220675] mmc1: SDHCI controller on 30b50000.mmc [30b50000.mmc] using ADMA
[    2.226262] [drm:drm_bridge_attach] *ERROR* failed to attach bridge /soc@0/bus@30800000/i2c@30a30000/hdmi@3d to encoder None-37: -22
[    2.245204] [drm:drm_bridge_attach] *ERROR* failed to attach bridge /soc@0/bus@32c00000/dsi@32e60000 to encoder None-37: -22
[    2.256445] imx-lcdif 32e80000.display-controller: error -EINVAL: Failed to attach bridge for endpoint0
[    2.265850] imx-lcdif 32e80000.display-controller: error -EINVAL: Cannot connect bridge
[    2.274009] imx-lcdif 32e80000.display-controller: probe with driver imx-lcdif failed with error -22

Fixes: 14b3cdbd0e5b ("drm/bridge: adv7511: make it honour next bridge in DT")
Signed-off-by: Liu Ying 
Reviewed-by: Dmitry Baryshkov 
Reviewed-by: Robert Foss 
Acked-by: Sui Jingfeng 
Reviewed-by: Laurent Pinchart 
Link: https://patchwork.freedesktop.org/patch/msgid/20240513080243.3952292-1-victor.liu@nxp.com
Signed-off-by: Dmitry Baryshkov

i2c: mux: Remove class argument from i2c_mux_add_adapter()

2024-05-13T14:13:19+00:00

99a741aa7a2d ("i2c: mux: gpio: remove support for class-based device
instantiation") removed the last call to i2c_mux_add_adapter() with a
non-null class argument. Therefore the class argument can be removed.

Note: Class-based device instantiation is a legacy mechanism which
shouldn't be used in new code, so we can rule out that this argument
may be needed again in the future.

Signed-off-by: Heiner Kallweit 
Reviewed-by: Thomas Zimmermann 
Acked-by: Peter Rosin 
Reviewed-by: Laurent Pinchart 
Acked-by: Jonathan Cameron 
Acked-by: Rob Herring (Arm) 
Signed-off-by: Wolfram Sang

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

2024-05-02T21:40:13+00:00

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

Revert "drm: Make drivers depends on DRM_DW_HDMI"

2024-05-02T15:59:59+00:00

This reverts commit c0e0f139354c01e0213204e4a96e7076e5a3e396, as helper
code should always be selected by the driver that needs it, for the
convenience of the final user configuring a kernel.

The user who configures a kernel should not need to know which helpers
are needed for the driver he is interested in.  Making a driver depend
on helper code means that the user needs to know which helpers to enable
first, which is very user-unfriendly.

Signed-off-by: Geert Uytterhoeven 
Acked-by: Arnd Bergmann 
Link: https://patchwork.freedesktop.org/patch/msgid/bd93d43b07f8ed6368119f4a5ddac2ee80debe53.1713780345.git.geert+renesas@glider.be
Signed-off-by: Maxime Ripard

Revert "drm: Switch DRM_DISPLAY_HELPER to depends on"

2024-05-02T15:58:23+00:00

This reverts commit e075e496f516bf92bc0cbaf94d64e8d4a6b58321, as helper
code should always be selected by the driver that needs it, for the
convenience of the final user configuring a kernel.

The user who configures a kernel should not need to know which helpers
are needed for the driver he is interested in.  Making a driver depend
on helper code means that the user needs to know which helpers to enable
first, which is very user-unfriendly.

Signed-off-by: Geert Uytterhoeven 
Acked-by: Arnd Bergmann 
Link: https://patchwork.freedesktop.org/patch/msgid/1ba76cc4d96a8afefff5d1bc42fb1e1329c5da68.1713780345.git.geert+renesas@glider.be
Signed-off-by: Maxime Ripard

Revert "drm: Switch DRM_DISPLAY_DP_AUX_BUS to depends on"

2024-05-02T15:58:22+00:00

This reverts commit 4d15125d7fe637f401e64e33c99513adf6586fdd, as helper
code should always be selected by the driver that needs it, for the
convenience of the final user configuring a kernel.

The user who configures a kernel should not need to know which helpers
are needed for the driver he is interested in.  Making a driver depend
on helper code means that the user needs to know which helpers to enable
first, which is very user-unfriendly.

Signed-off-by: Geert Uytterhoeven 
Acked-by: Arnd Bergmann 
Link: https://patchwork.freedesktop.org/patch/msgid/79824fec01eb9ab0673b9409f9b39cc8b5cc338d.1713780345.git.geert+renesas@glider.be
Signed-off-by: Maxime Ripard

Revert "drm: Switch DRM_DISPLAY_DP_HELPER to depends on"

2024-05-02T15:58:21+00:00

This reverts commit 0323287de87d7e6e9c22c57d7440aa353a2298d0, as helper
code should always be selected by the driver that needs it, for the
convenience of the final user configuring a kernel.

The user who configures a kernel should not need to know which helpers
are needed for the driver he is interested in.  Making a driver depend
on helper code means that the user needs to know which helpers to enable
first, which is very user-unfriendly.

Signed-off-by: Geert Uytterhoeven 
Acked-by: Arnd Bergmann 
Link: https://patchwork.freedesktop.org/patch/msgid/89ac456805746b6d0c888f10c5120b11aacd3319.1713780345.git.geert+renesas@glider.be
Signed-off-by: Maxime Ripard