aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/bridge
AgeCommit message (Collapse)AuthorFilesLines
2024-06-10drm/bridge: samsung-dsim: Set P divider based on min/max of fin pllAdam Ford1-2/+2
The P divider should be set based on the min and max values of the fin pll which may vary between different platforms. These ranges are defined per platform, but hard-coded values were used instead which resulted in a smaller range available on the i.MX8M[MNP] than what was possible. As noted by Frieder, there are descripencies between the reference manuals of the Mini, Nano and Plus, so I reached out to my NXP rep and got the following response regarding the varing notes in the documentation. "Yes it is definitely wrong, the one that is part of the NOTE in MIPI_DPHY_M_PLLPMS register table against PMS_P, PMS_M and PMS_S is not correct. I will report this to Doc team, the one customer should be take into account is the Table 13-40 DPHY PLL Parameters and the Note above." With this patch, the clock rates now match the values used in NXP's downstream kernel. Fixes: 846307185f0f ("drm/bridge: samsung-dsim: update PLL reference clock") Signed-off-by: Adam Ford <[email protected]> Reviewed-by: Frieder Schrempf <[email protected]> Tested-by: Frieder Schrempf <[email protected]> Reviewed-by: Marek Vasut <[email protected]> Tested-by: Marek Szyprowski <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-10drm/bridge: tc358767: Check if fully initialized before signalling HPD event ↵Marek Vasut1-1/+1
via IRQ Make sure the connector is fully initialized before signalling any HPD events via drm_kms_helper_hotplug_event(), otherwise this may lead to NULL pointer dereference. Signed-off-by: Marek Vasut <[email protected]> Reviewed-by: Robert Foss <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-10drm/bridge: tc358767: Fix comment in tc_edp_mode_validMarek Vasut1-1/+1
Fix comment copy-paste error in tc_edp_mode_valid(), this function is validating DP/eDP clock, not DPI clock frequency. Update the comment to match. No functional change. Signed-off-by: Marek Vasut <[email protected]> Reviewed-by: Robert Foss <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-10drm/bridge/panel: Fix runtime warning on panel bridge releaseAdam Miotk1-2/+5
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 <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-10drm/bridge: add missing MODULE_DESCRIPTION() macrosJeff Johnson4-0/+4
make allmodconfig && make W=1 C=1 reports: WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/gpu/drm/bridge/lontium-lt9611.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/gpu/drm/bridge/lontium-lt9611uxc.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/gpu/drm/bridge/sil-sii8620.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/gpu/drm/bridge/sii9234.o Add the missing invocations of the MODULE_DESCRIPTION() macro. Signed-off-by: Jeff Johnson <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-04drm/bridge: analogix_dp: don't adjust further when clock recovery succeededLucas Stach1-29/+26
Take a early return from the clock recovery training when the sink reports CR_DONE for all lanes. There is no point in trying to adjust the link parameters further. Signed-off-by: Lucas Stach <[email protected]> Reviewed-by: Robert Foss <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-04drm/bridge: analogix_dp: simplify analogix_dp_{set/get}_lane_link_training ↵Wyon Bi3-207/+26
helpers There is no need for separate functions for each lane, as we can deduct the register offset to read/write from the lane index. Signed-off-by: Wyon Bi <[email protected]> Signed-off-by: Lucas Stach <[email protected]> Reviewed-by: Robert Foss <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-06-04drm/bridge: analogix_dp: properly handle zero sized AUX transactionsLucas Stach1-4/+1
Address only transactions without any data are valid and should not be flagged as short transactions. Simply return the message size when no transaction errors occured. CC: [email protected] Signed-off-by: Lucas Stach <[email protected]> Reviewed-by: Robert Foss <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-05-27drm/bridge: analogix_dp: convert to struct drm_edidJani Nikula1-7/+8
Prefer the struct drm_edid based functions for reading the EDID and updating the connector. Reviewed-by: Dmitry Baryshkov <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/6f3bd1233a0922551761666f0c96c3766e3c5f96.1715691257.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <[email protected]>
2024-05-27Merge drm/drm-next into drm-misc-nextMaxime Ripard7-34/+35
Let's start the new release cycle. Signed-off-by: Maxime Ripard <[email protected]>
2024-05-24Merge tag 'drm-next-2024-05-25' of https://gitlab.freedesktop.org/drm/kernelLinus Torvalds1-1/+2
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
2024-05-22drm/bridge: it6505: fix hibernate to resume no display issueKuro Chung1-24/+49
When the system power resumes, the TTL input of IT6505 may experience some noise before the video signal stabilizes, necessitating a video reset. This patch is implemented to prevent a loop of video error interrupts, which can occur when a video reset in the video FIFO error interrupt triggers another such interrupt. The patch processes the SCDT and FIFO error interrupts simultaneously and ignores any video FIFO error interrupts caused by a video reset. Fixes: b5c84a9edcd4 ("drm/bridge: add it6505 driver") Signed-off-by: Kuro Chung <[email protected]> Signed-off-by: Hermes Wu <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-05-21drm/bridge: tc358767: Enable FRMSYNC timing generatorMarek Vasut1-3/+20
TC9595 datasheet Video Path0 Control (VPCTRL0) Register bit FRMSYNC description says "This bit should be disabled only in video mode transmission where Host transmits video timing together with video data and where pixel clock source is from DSI clock." . This driver always sources pixel clock from external xtal, therefore the FRMSYNC bit must always be enabled, enable it. This fixes an actual issue with DSI-to-DPI mode, where the display would randomly show subtle pixel flickering, or wobble, or shimmering. This is visible on solid gray color, but the degree of the shimmering differs between boots, which makes it hard to debug. There is a caveat to the FRMSYNC and this bridge pixel PLL, which can only generate pixel clock with limited accuracy, it may therefore be necessary to reduce the HFP to fit into line length of input pixel data, to avoid any possible overflows, which make the output video look striped horizontally. Signed-off-by: Marek Vasut <[email protected]> Reviewed-by: Robert Foss <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-05-20Merge tag 'i2c-for-6.10-rc1' of ↵Linus Torvalds1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux 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() ...
2024-05-20drm/bridge: adv7511: Attach next bridge without creating connectorLiu Ying1-1/+2
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 <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Robert Foss <[email protected]> Acked-by: Sui Jingfeng <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]>
2024-05-13drm/bridge: anx7625: use struct drm_edid moreJani Nikula2-17/+19
Prefer struct drm_edid based functions over struct edid. Signed-off-by: Jani Nikula <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/1d1290829fa463237b560c43e77170a986186031.1715347488.git.jani.nikula@intel.com
2024-05-13drm/bridge/analogix/anx78xx: switch to struct drm_edidJani Nikula1-11/+12
Prefer struct drm_edid based functions over struct edid. Signed-off-by: Jani Nikula <[email protected]> Reviewed-by: Robert Foss <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/035c7c31a3e096625a69eb4657c1727da4021a62.1715347488.git.jani.nikula@intel.com
2024-05-13drm/bridge/analogix/anx6345: switch to struct drm_edidJani Nikula1-8/+7
Prefer struct drm_edid based functions over struct edid. Signed-off-by: Jani Nikula <[email protected]> Reviewed-by: Robert Foss <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/74b2f00e17b2614b44955cf0cbae270f3c31d91a.1715347488.git.jani.nikula@intel.com
2024-05-13drm/bridge: analogix: Remove redundant checks on existence of bridge->encoderSui Jingfeng4-25/+0
The checks on the existence of bridge->encoder in the implementation of drm_bridge_funcs::attach() is not necessary, as it has already been checked in the drm_bridge_attach() function call by previous bridge or KMS driver. The drm_bridge_attach() will quit with a negative error code returned if it fails for some reasons, hence, it is guaranteed that the .encoder member of the drm_bridge instance is not NULL when various bridge attach functions are called. Remove the redundant checking codes "if (!bridge->encoder) { ... }". Reviewed-by: Laurent Pinchart <[email protected]> Signed-off-by: Sui Jingfeng <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-05-13drm/bridge: imx: Remove redundant checks on existence of bridge->encoderSui Jingfeng4-20/+0
The checks on the existence of bridge->encoder in the implementation of drm_bridge_funcs::attach() is not necessary, as it has already been checked in the drm_bridge_attach() function call by previous bridge or KMS driver. The drm_bridge_attach() will quit with a negative error code returned if it fails for some reasons, hence, it is guaranteed that the .encoder member of the drm_bridge instance is not NULL when various i.MX specific bridge attach functions are called. Remove the redundant checking codes "if (!bridge->encoder) { ... }". Reviewed-by: Laurent Pinchart <[email protected]> Signed-off-by: Sui Jingfeng <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-05-13drm/bridge: lt9611uxc: Remove a redundant check on existence of bridge->encoderSui Jingfeng1-5/+0
In the lt9611uxc_connector_init() function, the check on the existence of bridge->encoder is not necessary, as it has already been checked in the drm_bridge_attach() function. And the check on the drm bridge core happens before check in the implementation. Hence, it is guaranteed that the .encoder member of the struct drm_bridge is not NULL when lt9611uxc_connector_init() function get called. Remove the redundant checking codes "if (!bridge->encoder) { ... }". Reviewed-by: Laurent Pinchart <[email protected]> Signed-off-by: Sui Jingfeng <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-05-13drm/bridge: synopsys: dw-mipi-dsi: Remove a redundant check on existence of ↵Sui Jingfeng1-5/+0
bridge->encoder In the dw_mipi_dsi_bridge_attach() function, the check on the existence of bridge->encoder is not necessary, as it has already been checked in the drm_bridge_attach() function invocked by previous bridge or KMS driver. The previous drm_bridge_attach() will quit with a negative error code returned if it fails for some reasons, hence, it is guaranteed that the .encoder member of the struct drm_bridge is not NULL when dw_mipi_dsi_bridge_attach() function gets called. Remove the redundant checking codes "if (!bridge->encoder) { ... }". Reviewed-by: Laurent Pinchart <[email protected]> Signed-off-by: Sui Jingfeng <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-05-13drm/bridge: megachips-stdpxxxx-ge-b850v3-fw: Remove a redundant check on ↵Sui Jingfeng1-5/+0
existence of bridge->encoder In the ge_b850v3_lvds_create_connector function, the check on the existence of bridge->encoder is not necessary, as it has already been checked in the drm_bridge_attach() function called by upstream bridge or driver. Hence, it is guaranteed that the .encoder member of the drm_bridge instance is not NULL when cdns_mhdp_connector_init() function get called. Remove the redundant checking codes "if (!bridge->encoder) { ... }". Reviewed-by: Laurent Pinchart <[email protected]> Signed-off-by: Sui Jingfeng <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-05-13drm/bridge: cdns-mhdp8546: Remove a redundant check on existence of ↵Sui Jingfeng1-5/+0
bridge->encoder In the cdns_mhdp_connector_init() function, the check on the existence of bridge->encoder is not necessary, as it has already been checked in the drm_bridge_attach() function. As the cdns_mhdp_connector_init() is only called by cdns_mhdp_attach(), it is guaranteed that the .encoder member of the struct drm_bridge is not NULL when cdns_mhdp_attach() gets called. Remove the redundant checking codes "if (!bridge->encoder) { ... }". Reviewed-by: Laurent Pinchart <[email protected]> Signed-off-by: Sui Jingfeng <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-05-13drm/bridge: adv7511: Remove a redundant check on existence of bridge->encoderSui Jingfeng1-5/+0
In the adv7511_connector_init() function, the check on the existence of bridge->encoder is not necessary. As it has already been checked in the drm_bridge_attach() which happens prior to the adv7511_bridge_attach() get called. Also note that the adv7511_connector_init() is only called by adv7511_bridge_attach(). Hence, it is guaranteed that the .encoder member of the drm_bridge instance is not NULL when adv7511_connector_init() get called. Remove the redundant checking codes "if (!bridge->encoder) { ... }". Reviewed-by: Laurent Pinchart <[email protected]> Signed-off-by: Sui Jingfeng <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-05-13drm/bridge: it6505: Remove a redundant check on existence of bridge->encoderSui Jingfeng1-5/+0
In it6505_bridge_attach(), the check on the existence of 'bridge->encoder' is not necessary, as it has already been checked in the drm_bridge_attach() which happens prior to it6505_bridge_attach() get called. Note that the it6505_bridge_attach() will only be called by .attach() of the previous bridge or KMS driver. The previous drm_bridge_attach() will quit with a negative error code returned if it fails for some reasons. Hence, it is guaranteed that the .encoder member of the drm_bridge instance is not NULL when it6505_bridge_attach() function get called. Remove the redundant checking codes "if (!bridge->encoder) { ... }". Reviewed-by: Laurent Pinchart <[email protected]> Signed-off-by: Sui Jingfeng <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-05-13drm/bridge: panel: Remove a redundant check on existence of bridge->encoderSui Jingfeng1-5/+0
Because the existence of 'bridge->encoder' has already been checked before the panel_bridge_attach() function get called, and the drm_bridge_attach() will quit with a negative error code returned if it fails for some reasons. Hence, it is guaranteed that the .encoder member of the drm_bridge instance is not NULL when panel_bridge_attach() function get called. Remove the redundant checking codes "if (!bridge->encoder) { ... }". Reviewed-by: Laurent Pinchart <[email protected]> Signed-off-by: Sui Jingfeng <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-05-13drm/bridge: nxp-ptn3460: Remove a redundant check on existence of ↵Sui Jingfeng1-5/+0
bridge->encoder Because the existence of 'bridge->encoder' has already been checked before the ptn3460_bridge_attach() function get called, and drm_bridge_attach() will quit with a negative error code returned if it fails for some reasons. Hence, it is guaranteed that the .encoder member of the drm_bridge instance is not NULL when the ptn3460_bridge_attach() function get called. Remove the redundant checking codes "if (!bridge->encoder) { ... }". Reviewed-by: Laurent Pinchart <[email protected]> Signed-off-by: Sui Jingfeng <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-05-13drm/bridge: tfp410: Remove a redundant check on existence of bridge->encoderSui Jingfeng1-5/+0
Because the existence of bridge->encoder has already been checked before the simple_bridge_attach() function get called, And drm_bridge_attach() will quit with a negative error code returned if it fails for some reasons. Hence, it is guaranteed that the .encoder member of the drm_bridge instance is not NULL when the tfp410_attach() function get called. Remove the redundant checking codes "if (!bridge->encoder) { ... }". Reviewed-by: Laurent Pinchart <[email protected]> Signed-off-by: Sui Jingfeng <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-05-13drm/bridge: simple-bridge: Remove a redundant check on existence of ↵Sui Jingfeng1-5/+0
bridge->encoder Because the existence of 'bridge->encoder' has already been checked before the simple_bridge_attach() function get called, and drm_bridge_attach() will quit with a negative error code returned if it fails for some reasons. Hence, it is guaranteed that the .encoder member of the drm_bridge instance is not NULL when the simple_bridge_attach() get called. Remove the redundant checking codes "if (!bridge->encoder) { ... }". Reviewed-by: Laurent Pinchart <[email protected]> Signed-off-by: Sui Jingfeng <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-05-13i2c: mux: Remove class argument from i2c_mux_add_adapter()Heiner Kallweit1-1/+1
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 <[email protected]> Reviewed-by: Thomas Zimmermann <[email protected]> Acked-by: Peter Rosin <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Acked-by: Jonathan Cameron <[email protected]> Acked-by: Rob Herring (Arm) <[email protected]> Signed-off-by: Wolfram Sang <[email protected]>
2024-05-02Revert "drm/bridge: ti-sn65dsi83: Fix enable error path"Luca Ceresoli1-1/+0
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 <[email protected]> Signed-off-by: Luca Ceresoli <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 2940ee03b23281071620dda1d790cd644dabd394) Signed-off-by: Maarten Lankhorst <[email protected]>
2024-05-02Revert "drm: Make drivers depends on DRM_DW_HDMI"Geert Uytterhoeven1-2/+2
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 <[email protected]> Acked-by: Arnd Bergmann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/bd93d43b07f8ed6368119f4a5ddac2ee80debe53.1713780345.git.geert+renesas@glider.be Signed-off-by: Maxime Ripard <[email protected]>
2024-05-02Revert "drm: Switch DRM_DISPLAY_HELPER to depends on"Geert Uytterhoeven4-11/+11
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 <[email protected]> Acked-by: Arnd Bergmann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/1ba76cc4d96a8afefff5d1bc42fb1e1329c5da68.1713780345.git.geert+renesas@glider.be Signed-off-by: Maxime Ripard <[email protected]>
2024-05-02Revert "drm: Switch DRM_DISPLAY_DP_AUX_BUS to depends on"Geert Uytterhoeven2-4/+4
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 <[email protected]> Acked-by: Arnd Bergmann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/79824fec01eb9ab0673b9409f9b39cc8b5cc338d.1713780345.git.geert+renesas@glider.be Signed-off-by: Maxime Ripard <[email protected]>
2024-05-02Revert "drm: Switch DRM_DISPLAY_DP_HELPER to depends on"Geert Uytterhoeven3-9/+9
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 <[email protected]> Acked-by: Arnd Bergmann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/89ac456805746b6d0c888f10c5120b11aacd3319.1713780345.git.geert+renesas@glider.be Signed-off-by: Maxime Ripard <[email protected]>
2024-05-02Revert "drm: Switch DRM_DISPLAY_HDCP_HELPER to depends on"Geert Uytterhoeven3-3/+3
This reverts commit 3166e7e6d935caaef07605a5c90773fbf9ffeaf4, 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 <[email protected]> Acked-by: Arnd Bergmann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/a40e70a0abd3d841c23c107d452a43fdd70ef37a.1713780345.git.geert+renesas@glider.be Signed-off-by: Maxime Ripard <[email protected]>
2024-05-02Revert "drm: Switch DRM_DISPLAY_HDMI_HELPER to depends on"Geert Uytterhoeven1-1/+1
This reverts commit f6d2dc03fa8546b284dd8c1af027d9fac5725921, 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 <[email protected]> Acked-by: Arnd Bergmann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/bd288a5943dab8609f2d1f2bf413595a61df727a.1713780345.git.geert+renesas@glider.be Signed-off-by: Maxime Ripard <[email protected]>
2024-05-02Revert "drm/bridge: dw-hdmi: Make DRM_DW_HDMI selectable"Geert Uytterhoeven1-1/+1
This reverts commit 0209df3b4731516fe77638bfc52ba2e9629c67cd, as the commit it fixes (which is BTW not the commit in the Fixes: tag!) will be reverted, too. Signed-off-by: Geert Uytterhoeven <[email protected]> Acked-by: Arnd Bergmann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/b2d1a7a765e4af249f4c450383de6e8422647e2e.1713780345.git.geert+renesas@glider.be Signed-off-by: Maxime Ripard <[email protected]>
2024-05-02Revert "drm: fix DRM_DISPLAY_DP_HELPER dependencies, part 2"Geert Uytterhoeven1-1/+1
This reverts commit a57e191ebbaa0363dbf352cc37447c2230573e29, as the commits it fixes will be reverted, too. Signed-off-by: Geert Uytterhoeven <[email protected]> Acked-by: Arnd Bergmann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/37216404c77b4c677d3b3a80d12d6d4447a3f3a0.1713780345.git.geert+renesas@glider.be Signed-off-by: Maxime Ripard <[email protected]>
2024-04-29Revert "drm/bridge: ti-sn65dsi83: Fix enable error path"Luca Ceresoli1-1/+0
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 <[email protected]> Signed-off-by: Luca Ceresoli <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-25drm/print: drop include debugfs.h and include where neededJani Nikula2-0/+3
Surprisingly many places depend on debugfs.h to be included via drm_print.h. Fix them. v3: Also fix armada, ite-it6505, imagination, msm, sti, vc4, and xe v2: Also fix ivpu and vmwgfx Reviewed-by: Andrzej Hajda <[email protected]> Acked-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Acked-by: Dmitry Baryshkov <[email protected]> # drm/msm Acked-by: Matt Coster <[email protected]> # drm/imagination Acked-by: Alex Deucher <[email protected]> Acked-by: Lucas De Marchi <[email protected]> Acked-by: Robert Foss <[email protected]> #drm/bridge Reviewed-by: Lyude Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Jani Nikula <[email protected]>
2024-04-25drm/bridge: imx: Fix unmet depenency for PHY_FSL_SAMSUNG_HDMI_PHYAdam Ford1-2/+2
When enabling i.MX8MP DWC HDMI driver, it automatically selects PHY_FSL_SAMSUNG_HDMI_PHY, since it wont' work without the phy. This may cause some Kconfig warnings during various build tests. Fix this by implying the phy instead of selecting the phy. To prevent this from happening with the DRM_IMX8MP_HDMI_PVI, also imply it instead of selecting it. Fixes: 1f36d634670d ("drm/bridge: imx: add bridge wrapper driver for i.MX8MP DWC HDMI") Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Signed-off-by: Adam Ford <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-24drm/bridge: tc358764: drop driver owner assignmentKrzysztof Kozlowski1-1/+0
Core in mipi_dsi_driver_register() already sets the .owner, so driver does not need to. Signed-off-by: Krzysztof Kozlowski <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]>
2024-04-24drm/bridge: chipone-icn6211: drop driver owner assignmentKrzysztof Kozlowski1-1/+0
Core in mipi_dsi_driver_register() already sets the .owner, so driver does not need to. Signed-off-by: Krzysztof Kozlowski <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]>
2024-04-24drm/bridge: adv7511: make it honour next bridge in DTDmitry Baryshkov2-0/+13
DT bindings for adv7511 and adv7533 bridges specify HDMI output to be present at the port@1. This allows board DT to add e.g. HDMI connector nodes or any other next chained bridge. Make adv7511 driver discover that bridge and attach it to the chain. Signed-off-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-23drm/bridge: tc358775: Configure hs_rate and lp_rateTony Lindgren1-0/+13
The hs_rate and lp_rate may be used by the dsi host for timing calculations. The tc358775 has a maximum bit rate of 1 Gbps/lane, tc358765 has maximurate of 800 Mbps per lane. Reviewed-by: Michael Walle <[email protected]> Signed-off-by: Tony Lindgren <[email protected]> Reviewed-by: Robert Foss <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-23drm/bridge: tc358775: Add support for tc358765Tony Lindgren1-4/+22
The tc358775 bridge is pin compatible with earlier tc358765 according to the tc358774xbg_datasheet_en_20190118.pdf documentation. Compared to the tc358765, the tc358775 supports a STBY GPIO and higher data rates. The tc358765 has a register bit for video event mode vs video pulse mode. We must set it to video event mode for the LCD output to work, and on the tc358775, this bit no longer exists. Looks like the registers seem to match otherwise based on a quick glance comparing the defines to the earlier Android kernel tc358765 driver. Reviewed-by: Michael Walle <[email protected]> Signed-off-by: Tony Lindgren <[email protected]> Reviewed-by: Robert Foss <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-23drm/bridge: tc358775: Enable pre_enable_prev_first flagTony Lindgren1-0/+1
Set pre_enable_prev_first to ensure the previous bridge is enabled first. Reviewed-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Michael Walle <[email protected]> Tested-by: Michael Walle <[email protected]> Signed-off-by: Tony Lindgren <[email protected]> Reviewed-by: Robert Foss <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-04-23drm/bridge: tc358775: Add burst and low-power modesTony Lindgren1-1/+2
Burst and low-power modes are supported both for tc358765 and tc358775. Reviewed-by: Michael Walle <[email protected]> Tested-by: Michael Walle <[email protected]> Signed-off-by: Tony Lindgren <[email protected]> Reviewed-by: Robert Foss <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Powered by cgit, Gruvboxed by Blaster4385.