aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/msm/dsi/dsi_manager.c
AgeCommit message (Collapse)AuthorFilesLines
2024-06-24drm/msm/dsi: parse vsync source from device treeDmitry Baryshkov1-0/+5
Allow board's device tree to specify the vsync source (aka TE source). If the property is omitted, the display controller driver will use the default setting. Reviewed-by: Abhinav Kumar <[email protected]> [DB: fixed clearing of return value if there is no TE property] Signed-off-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Marijn Suijten <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/598740/ Link: https://lore.kernel.org/r/[email protected]
2024-04-22drm/msm/dsi: simplify connector creationDmitry Baryshkov1-23/+18
Instead of having two functions, msm_dsi_manager_bridge_init() and msm_dsi_manager_ext_bridge_init(), merge them into msm_dsi_manager_connector_init(), moving drm_bridge_attach() to be called from the bridge's attach callback (as most other bridges do). Signed-off-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/582212/ Link: https://lore.kernel.org/r/[email protected]
2024-04-22drm/msm/dsi: move next bridge acquisition to dsi_bindDmitry Baryshkov1-7/+1
Currently the MSM DSI driver looks for the next bridge during msm_dsi_modeset_init(). If the bridge is not registered at that point, this might result in -EPROBE_DEFER, which can be problematic that late during the device probe process. Move next bridge acquisition to the dsi_bind state so that probe deferral is returned as early as possible. Signed-off-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/582210/ Link: https://lore.kernel.org/r/[email protected]
2024-04-22drm/msm/dsi: remove the drm_bridge_attach fallbackDmitry Baryshkov1-25/+11
All the bridges that are being used with the MSM DSI hosts have been converted to support DRM_BRIDGE_ATTACH_NO_CONNECTOR. Drop the fallback code and require DRM_BRIDGE_ATTACH_NO_CONNECTOR to be supported by the downstream bridges. Signed-off-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/582209/ Link: https://lore.kernel.org/r/[email protected]
2024-02-11drm/msm/dsi: remove msm_dsi::encoderDmitry Baryshkov1-5/+3
There is no need anymore to stop the drm_encoder instance in struct msm_dsi. Remove corresponding field. Signed-off-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/561697/ Link: https://lore.kernel.org/r/[email protected]
2024-02-11drm/msm/dsi: stop calling set_split_displayDmitry Baryshkov1-35/+0
Since the commit 8b03ad30e314 ("drm/msm/dsi: Use one connector for dual DSI mode"), the second DSI host in the bonded pair will not be associated with the encoder and will not get the bridges, thus making condition in msm_dsi_manager_set_split_display() always false. Technically that change broke bonded DSI support in the MDP5 driver. But since nobody complained in the last 5.5 years, it seems that nobody cares enough. Drop the msm_dsi_manager_set_split_display() completely and stop calling the set_split_display() KMS callback. Also remove the msm_dsi::external_bridge field which was only used by the mentioned function. Signed-off-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/561695/ Link: https://lore.kernel.org/r/[email protected]
2024-02-11drm/msm/dsi: drop msm_dsi_device_connected() functionDmitry Baryshkov1-5/+0
Since the commit 8f59ee9a570c ("drm/msm/dsi: Adjust probe order") the DSI hosts are not bound through the component framework if the DSI driver wasn't attached to the DSI device connected to this host. Afterwards, if there is no bridge (including the panel bridge) created for the DSI device then devm_drm_of_get_bridge() will return an error, also making msm_dsi_manager_ext_bridge_init() and thus DSI modesetting init fail. This way there can be no 'unconnected' MSM DSI bridges. Remove the msm_dsi_device_connected() function. Signed-off-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/561692/ Link: https://lore.kernel.org/r/[email protected]
2024-02-11drm/msm/dsi: do not store internal bridge pointerDmitry Baryshkov1-11/+8
Since the driver was switched to devm_drm_bridge_add(), there is no need anymore to store the created bridge instance in struct msm_dsi. Drop this field and pass data directly. Signed-off-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/561693/ Link: https://lore.kernel.org/r/[email protected]
2023-10-12drm/msm/dsi: use correct lifetime device for devm_drm_bridge_addDmitry Baryshkov1-1/+1
The lifetime of the created drm_bridge is attached to the drm_device rather than the DSI's platform_device. Use correct lifetime for devm_drm_bridge_add() call. Fixes: 5f403fd7d5c2 ("drm/msm/dsi: switch to devm_drm_bridge_add()") Signed-off-by: Dmitry Baryshkov <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/562200/ Link: https://lore.kernel.org/r/[email protected]
2023-10-09drm/msm/dsi: switch to devm_drm_bridge_add()Dmitry Baryshkov1-20/+10
Make MSM DSI driver use devm_drm_bridge_add() instead of plain drm_bridge_add(). As the driver doesn't require any additional cleanup, stop adding created bridge to the priv->bridges array. Reviewed-by: Rob Clark <[email protected]> Signed-off-by: Dmitry Baryshkov <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/561636/ Signed-off-by: Rob Clark <[email protected]>
2023-05-21drm/msm/dsi: More properly handle errors in regards to dsi_mgr_bridge_power_on()Douglas Anderson1-6/+26
In commit 7d8e9a90509f ("drm/msm/dsi: move DSI host powerup to modeset time") the error handling with regards to dsi_mgr_bridge_power_on() got a bit worse. Specifically if we failed to power the bridge on then nothing would really notice. The modeset function couldn't return an error and thus we'd blindly go forward and try to do the pre-enable. In commit ec7981e6c614 ("drm/msm/dsi: don't powerup at modeset time for parade-ps8640") we added a special case to move the powerup back to pre-enable time for ps8640. When we did that, we didn't try to recover the old/better error handling just for ps8640. In the patch ("drm/msm/dsi: Stop unconditionally powering up DSI hosts at modeset") we've now moved the powering up back to exclusively being during pre-enable. That means we can add the better error handling back in, so let's do it. To do so we'll add a new function dsi_mgr_bridge_power_off() that's matches how errors were handled prior to commit 7d8e9a90509f ("drm/msm/dsi: move DSI host powerup to modeset time"). NOTE: Now that we have dsi_mgr_bridge_power_off(), it feels as if we should be calling it in dsi_mgr_bridge_post_disable(). That would make some sense, but doing so would change the current behavior and thus should be a separate patch. Specifically: * dsi_mgr_bridge_post_disable() always calls dsi_mgr_phy_disable() even in the slave-DSI case of bonded DSI. We'd need to add special handling for this if it's truly needed. * dsi_mgr_bridge_post_disable() calls msm_dsi_phy_pll_save_state() midway through the poweroff. * dsi_mgr_bridge_post_disable() has a different order of some of the poweroffs / IRQ disables. For now we'll leave dsi_mgr_bridge_post_disable() alone. Signed-off-by: Douglas Anderson <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/521059/ Link: https://lore.kernel.org/r/20230131141756.RFT.v2.3.I3c87b53c4ab61a7d5e05f601a4eb44c7e3809a01@changeid Signed-off-by: Dmitry Baryshkov <[email protected]>
2023-05-21drm/msm/dsi: Stop unconditionally powering up DSI hosts at modesetDouglas Anderson1-37/+1
In commit 7d8e9a90509f ("drm/msm/dsi: move DSI host powerup to modeset time"), we moved powering up DSI hosts to modeset time. This wasn't because it was an elegant design, but there were no better options. That commit actually ended up breaking ps8640, and thus was born commit ec7981e6c614 ("drm/msm/dsi: don't powerup at modeset time for parade-ps8640") as a temporary hack to un-break ps8640 by moving it to the old way of doing things. It turns out that ps8640 _really_ doesn't like its pre_enable() function to be called after dsi_mgr_bridge_power_on(). Specifically (from experimentation, not because I have any inside knowledge), it looks like the assertion of "RST#" in the ps8640 runtime resume handler seems like it's not allowed to happen after dsi_mgr_bridge_power_on() Recently, Dave Stevenson's series landed allowing bridges some control over pre_enable ordering. The meaty commit for our purposes is commit 4fb912e5e190 ("drm/bridge: Introduce pre_enable_prev_first to alter bridge init order"). As documented by that series, if a bridge doesn't set "pre_enable_prev_first" then we should use the old ordering. Now that we have the commit ("drm/bridge: tc358762: Set pre_enable_prev_first") we can go back to the old ordering, which also allows us to remove the ps8640 special case. One last note is that even without reverting commit 7d8e9a90509f ("drm/msm/dsi: move DSI host powerup to modeset time"), if you _just_ revert the ps8640 special case and try it out then it doesn't seem to fail anymore. I spent time bisecting / debugging this and it turns out to be mostly luck, so we still want this patch to make sure it's solid. Specifically the reason it sorta works these days is because we implemented wait_hpd_asserted() in ps8640 now, plus the magic of "pm_runtime" autosuspend. The fact that we have wait_hpd_asserted() implemented means that we actually power the bridge chip up just a wee bit earlier and then the bridge happens to stay on because of autosuspend and thus ends up powered before dsi_mgr_bridge_power_on(). Cc: Dave Stevenson <[email protected]> Cc: Dmitry Baryshkov <[email protected]> Cc: Abhinav Kumar <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/521058/ Link: https://lore.kernel.org/r/20230131141756.RFT.v2.2.I4cfeab9d0e07e98ead23dd0736ab4461e6c69002@changeid Signed-off-by: Dmitry Baryshkov <[email protected]>
2023-01-26drm/msm/dsi: properly handle the case of empty OPP table in ↵Dmitry Baryshkov1-9/+10
dsi_mgr_bridge_mode_valid It was left unnoticed during the review that even if there is no OPP table in device tree, one will be created by a call to the function devm_pm_opp_set_clkname(). This leads to dsi_mgr_bridge_mode_valid() rejecting all modes if DT contains no OPP table for the DSI host. Rework dsi_mgr_bridge_mode_valid() to handle this case by actually checking that the table is populated with frequency entries before returning an error. Fixes: 8328041b8c82 ("drm/msm/dsi: implement opp table based check for dsi_mgr_bridge_mode_valid()") Signed-off-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/520076/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]>
2023-01-22drm/msm/dsi: implement opp table based check for dsi_mgr_bridge_mode_valid()Abhinav Kumar1-0/+19
Currently there is no protection against a user trying to set an unsupported mode on DSI. Implement a check based on the opp table whether the byte clock for the mode can be supported by validating whether an opp table entry exists. For devices which have not added opp table support yet, skip this check otherwise it will break bootup on those devices. changes in v3: - make the comment shorter - handle all errors except ENODEV Closes: https://gitlab.freedesktop.org/drm/msm/-/issues/15 Reported-by: Rob Clark <[email protected]> Signed-off-by: Abhinav Kumar <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/518008/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]>
2022-09-18drm/msm/dsi: switch to DRM_PANEL_BRIDGEDmitry Baryshkov1-252/+31
Currently the DSI driver has two separate paths: one if the next device in a chain is a bridge and another one if the panel is connected directly to the DSI host. Simplify the code path by using panel-bridge driver (already selected in Kconfig) and dropping support for handling the panel directly. Signed-off-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/493608/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Rob Clark <[email protected]>
2022-09-18drm/msm/dsi: Remove the unneeded result variableye xingchen1-4/+1
Return the value msm_dsi_phy_enable() directly instead of storing it in another redundant variable. Reported-by: Zeal Robot <[email protected]> Signed-off-by: ye xingchen <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/499621/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Rob Clark <[email protected]>
2022-05-20Merge tag 'msm-next-5.19-fixes' of ↵Dave Airlie1-1/+31
https://gitlab.freedesktop.org/abhinavk/msm into drm-next 5.19 fixes for msm-next - Limiting WB modes to max sspp linewidth - Fixing the supported rotations to add 180 back for IGT - Fix to handle pm_runtime_get_sync() errors to avoid unclocked access in the bind() path for dpu driver - Fix the irq_free() without request issue which was a big-time hitter in the CI-runs. Signed-off-by: Abhinav Kumar <[email protected]> Signed-off-by: Dave Airlie <[email protected]> From: Abhinav Kumar <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-05-18drm/msm/dsi: don't powerup at modeset time for parade-ps8640Douglas Anderson1-1/+31
Commit 7d8e9a90509f ("drm/msm/dsi: move DSI host powerup to modeset time") caused sc7180 Chromebooks that use the parade-ps8640 bridge chip to fail to turn the display back on after it turns off. Unfortunately, it doesn't look easy to fix the parade-ps8640 driver to handle the new power sequence. The Linux driver has almost nothing in it and most of the logic for this bridge chip is in black-box firmware that the bridge chip uses. Also unfortunately, reverting the patch will break "tc358762". The long term solution here is probably Dave Stevenson's series [1] that would give more flexibility. However, that is likely not a quick fix. For the short term, we'll look at the compatible of the next bridge in the chain and go back to the old way for the Parade PS8640 bridge chip. If it's found that other bridge chips also need this workaround then we can add them to the list or consider inverting the condition. However, the hope is that the framework will not take too much longer to land and we won't have to add anything other than ps8640 here. [1] https://lore.kernel.org/r/[email protected] Fixes: 7d8e9a90509f ("drm/msm/dsi: move DSI host powerup to modeset time") Suggested-by: Rob Clark <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Link: https://lore.kernel.org/r/20220513131504.v5.1.Ia196e35ad985059e77b038a41662faae9e26f411@changeid Signed-off-by: Rob Clark <[email protected]>
2022-05-11Merge tag 'drm-msm-next-2022-05-09' of ↵Dave Airlie1-0/+15
https://gitlab.freedesktop.org/drm/msm into drm-next - Fourcc modifier for tiled but not compressed layouts - Support for userspace allocated IOVA (GPU virtual address) - Devfreq clamp_to_idle fix - DPU: DSC (Display Stream Compression) support - DPU: inline rotation support on SC7280 - DPU: update DP timings to follow vendor recommendations - DP, DPU: add support for wide bus (on newer chipsets) - DP: eDP support - Merge DPU1 and MDP5 MDSS driver, make dpu/mdp device the master component - MDSS: optionally reset the IP block at the bootup to drop bootloader state - Properly register and unregister internal bridges in the DRM framework - Complete DPU IRQ cleanup - DP: conversion to use drm_bridge and drm_bridge_connector - eDP: drop old eDP parts again - DPU: writeback support - Misc small fixes Signed-off-by: Dave Airlie <[email protected]> From: Rob Clark <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/CAF6AEGvJCr_1D8d0dgmyQC5HD4gmXeZw=bFV_CNCfceZbpMxRw@mail.gmail.com
2022-04-26drm/msm/dsi: add mode valid callback for dsi_mgrVinod Koul1-0/+12
Add a mode valid callback for dsi_mgr for checking mode being valid in case of DSC. For DSC the height and width needs to be multiple of slice, so we check that here Reviewed-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Signed-off-by: Vinod Koul <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/480930/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]>
2022-04-26drm/msm: properly add and remove internal bridgesDmitry Baryshkov1-0/+3
Add calls to drm_bridge_add()/drm_bridge_remove() DRM bridges created by the driver. This fixes the following warning. WARNING: CPU: 0 PID: 1 at kernel/locking/mutex.c:579 __mutex_lock+0x840/0x9f4 DEBUG_LOCKS_WARN_ON(lock->magic != lock) Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.18.0-rc1-00002-g3054695a0d27-dirty #55 Hardware name: Generic DT based system unwind_backtrace from show_stack+0x10/0x14 show_stack from dump_stack_lvl+0x58/0x70 dump_stack_lvl from __warn+0xc8/0x1e8 __warn from warn_slowpath_fmt+0x78/0xa8 warn_slowpath_fmt from __mutex_lock+0x840/0x9f4 __mutex_lock from mutex_lock_nested+0x1c/0x24 mutex_lock_nested from drm_bridge_hpd_enable+0x2c/0x84 drm_bridge_hpd_enable from msm_hdmi_modeset_init+0xc0/0x21c msm_hdmi_modeset_init from mdp4_kms_init+0x53c/0x90c mdp4_kms_init from msm_drm_bind+0x514/0x698 msm_drm_bind from try_to_bring_up_aggregate_device+0x160/0x1bc try_to_bring_up_aggregate_device from component_master_add_with_match+0xc4/0xf8 component_master_add_with_match from msm_pdev_probe+0x274/0x350 msm_pdev_probe from platform_probe+0x5c/0xbc platform_probe from really_probe.part.0+0x9c/0x290 really_probe.part.0 from __driver_probe_device+0xa8/0x13c __driver_probe_device from driver_probe_device+0x34/0x10c driver_probe_device from __driver_attach+0xbc/0x178 __driver_attach from bus_for_each_dev+0x74/0xc0 bus_for_each_dev from bus_add_driver+0x160/0x1e4 bus_add_driver from driver_register+0x88/0x118 driver_register from do_one_initcall+0x6c/0x334 do_one_initcall from kernel_init_freeable+0x1bc/0x220 kernel_init_freeable from kernel_init+0x18/0x12c kernel_init from ret_from_fork+0x14/0x2c Fixes: 3d3f8b1f8b62 ("drm/bridge: make bridge registration independent of drm flow") Reported-by: kernel test robot <[email protected]> Signed-off-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Stephen Boyd <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/481778/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]>
2022-04-11drm/msm/dsi: Use connector directly in msm_dsi_manager_connector_init()Stephen Boyd1-1/+1
The member 'msm_dsi->connector' isn't assigned until msm_dsi_manager_connector_init() returns (see msm_dsi_modeset_init() and how it assigns the return value). Therefore this pointer is going to be NULL here. Let's use 'connector' which is what was intended. Cc: Dmitry Baryshkov <[email protected]> Cc: Sean Paul <[email protected]> Fixes: 6d5e78406991 ("drm/msm/dsi: Move dsi panel init into modeset init path") Signed-off-by: Stephen Boyd <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/478693/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Rob Clark <[email protected]>
2022-02-19Merge branches 'msm-next-lumag-core', 'msm-next-lumag-dpu', ↵Dmitry Baryshkov1-12/+31
'msm-next-lumag-dp', 'msm-next-lumag-dsi', 'msm-next-lumag-hdmi' and 'msm-next-lumag-mdp5' into msm-next-lumag
2022-02-18drm/msm/dsi: move DSI host powerup to modeset timeDmitry Baryshkov1-12/+31
The DSI subsystem does not fully fall into the pre-enable/enable system of callbacks, since typically DSI device bridge drivers expect to be able to communicate with DSI devices at the pre-enable() callback. The reason is that for some DSI hosts enabling the video stream would prevent other drivers from sending DSI commands. For example see the panel-bridge driver, which does drm_panel_prepare() from the pre_enable() callback (which would be called before our pre_enable() callback, resulting in panel preparation failures as the link is not yet ready). Therewere several attempts to solve this issue, but currently the best approach is to power up the DSI link from the mode_set() callback, allowing next bridge/panel to use DSI transfers in the pre_enable() time. Follow this approach. Signed-off-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]>
2022-02-18drm/msm: reduce usage of round_pixclk callbackDmitry Baryshkov1-22/+0
The round_pixclk() callback returns different rate only on MDP4 in HDMI (DTV) case. Stop using this callback in other cases to simplify mode_valid callbacks. Signed-off-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Stephen Boyd <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]>
2021-12-08drm/msm/dsi: fix initialization in the bonded DSI caseDmitry Baryshkov1-17/+0
Commit 739b4e7756d3 ("drm/msm/dsi: Fix an error code in msm_dsi_modeset_init()") changed msm_dsi_modeset_init() to return an error code in case msm_dsi_manager_validate_current_config() returns false. However this is not an error case, but a slave DSI of the bonded DSI link. In this case msm_dsi_modeset_init() should return 0, but just skip connector and bridge initialization. To reduce possible confusion, drop the msm_dsi_manager_validate_current_config() function, and specif 'bonded && !master' condition directly in the msm_dsi_modeset_init(). Fixes: 739b4e7756d3 ("drm/msm/dsi: Fix an error code in msm_dsi_modeset_init()") Signed-off-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Rob Clark <[email protected]>
2021-12-06Merge remote-tracking branch 'drm/drm-next' into msm-next-stagingRob Clark1-3/+3
Backmerge drm-next to pull in: 8f59ee9a570c ("drm/msm/dsi: Adjust probe order") Signed-off-by: Rob Clark <[email protected]>
2021-11-28drm/msm/dsi: stop setting clock parents manuallyDmitry Baryshkov1-9/+2
There is no reason to set clock parents manually, use device tree to assign DSI/display clock parents to DSI PHY clocks. Dropping this manual setup allows us to drop repeating code and to move registration of hw clock providers to generic place. Signed-off-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Rob Clark <[email protected]>
2021-11-28drm/msm/dsi: untangle cphy setting from the src pll settingDmitry Baryshkov1-0/+3
Move DPHY/CPHY setting from msm_dsi_host_set_src_pll() to new function msm_dsi_host_set_phy_mode(). Signed-off-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Rob Clark <[email protected]>
2021-11-18Merge drm/drm-next into drm-misc-nextThomas Zimmermann1-13/+53
Backmerging from drm/drm-next for v5.16-rc1. Signed-off-by: Thomas Zimmermann <[email protected]>
2021-10-27drm/msm/dsi: Adjust probe orderRob Clark1-3/+3
Switch to the documented order dsi-host vs bridge probe. Tested-by: Amit Pundir <[email protected]> Tested-by: Caleb Connolly <[email protected]> Tested-by: John Stultz <[email protected]> Signed-off-by: Rob Clark <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2021-10-15drm/msm/dsi: do not enable irq handler before powering up the hostDmitry Baryshkov1-0/+16
The DSI host might be left in some state by the bootloader. If this state generates an IRQ, it might hang the system by holding the interrupt line before the driver sets up the DSI host to the known state. Move the request_irq into msm_dsi_host_init and pass IRQF_NO_AUTOEN to it. Call enable/disable_irq after msm_dsi_host_power_on/_off() functions, so that we can be sure that the interrupt is delivered when the host is in the known state. It is not possible to defer the interrupt enablement to a later point, because drm_panel_prepare might need to communicate with the panel over the DSI link and that requires working interrupt. Fixes: a689554ba6ed ("drm/msm: Initial add DSI connector support") Signed-off-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Rob Clark <[email protected]>
2021-10-15drm/msm/dsi: Support NO_CONNECTOR bridgesRob Clark1-13/+37
For now, since we have a mix of bridges which support this flag, which which do *not* support this flag, or work both ways, try it once with NO_CONNECTOR and then fall back to the old way if that doesn't work. Eventually we can drop the fallback path. v2: Add missing drm_connector_attach_encoder() so display actually comes up when the bridge properly handles the NO_CONNECTOR flag Signed-off-by: Rob Clark <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Rob Clark <[email protected]>
2021-08-10drm/msm/dsi: add continuous clock support for 7nm PHYDmitry Baryshkov1-2/+2
Unlike previous generations, 7nm PHYs are required to collaborate with the host for continuos clock mode. Add changes neccessary to enable continuous clock mode in the 7nm DSI PHYs. Signed-off-by: Dmitry Baryshkov <[email protected]> Link: https://lore.kernel.org/r/[email protected] [Fix merge conflict, and $description typo] Signed-off-by: Rob Clark <[email protected]>
2021-08-07drm/msm/dsi: stop calling set_encoder_mode callbackDmitry Baryshkov1-12/+0
None of the display drivers now implement set_encoder_mode callback. Stop calling it from the modeset init code. Signed-off-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Bjorn Andersson <[email protected]> Signed-off-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Rob Clark <[email protected]>
2021-08-07drm/msm/dsi: add three helper functionsDmitry Baryshkov1-8/+11
Add three helper functions to be used by display drivers for setting up encoders. Signed-off-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Bjorn Andersson <[email protected]> Signed-off-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Rob Clark <[email protected]>
2021-08-07drm/msm/dsi: rename dual DSI to bonded DSIDmitry Baryshkov1-52/+51
We are preparing to support two independent DSI hosts in the DSI/DPU code. To remove possible confusion (as both configurations can be referenced as dual DSI) let's rename old "dual DSI" (two DSI hosts driving single device, with clocks being locked) to "bonded DSI". Signed-off-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Bjorn Andersson <[email protected]> [DB: add one extra hunk added by one previous patches] Signed-off-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Rob Clark <[email protected]>
2021-08-07drm/msm/dsi: add support for dsi test pattern generatorAbhinav Kumar1-0/+13
During board bringups its useful to have a DSI test pattern generator to isolate a DPU vs a DSI issue and focus on the relevant hardware block. To facilitate this, add an API which triggers the DSI controller test pattern. The expected output is a rectangular checkered pattern. This has been validated on a single DSI video mode panel by calling it right after drm_panel_enable() which is also the ideal location to use this as the DSI host and the panel have been initialized by then. Further validation on dual DSI and command mode panel is pending. If there are any fix ups needed for those, it shall be applied on top of this change. Changes in v2: - generate the new dsi.xml.h and update the bitfield names Signed-off-by: Abhinav Kumar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Stephen Boyd <[email protected]> Signed-off-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Rob Clark <[email protected]>
2021-08-07drm/msm/dsi: drop msm_dsi_phy_get_shared_timingsDmitry Baryshkov1-2/+1
Instead of fetching shared timing through an extra function call, get them directly from msm_dsi_phy_enable. Signed-off-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Rob Clark <[email protected]>
2021-06-23drm/msm/dsi: do not enable PHYs when called for the slave DSI interfaceDmitry Baryshkov1-4/+4
Move the call to dsi_mgr_phy_enable after checking whether the DSI interface is slave, so that PHY enablement happens together with the host enablement. Signed-off-by: Dmitry Baryshkov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Rob Clark <[email protected]>
2021-06-23drm/msm/dsi: print error code when MIPI DSI host registration failsDmitry Baryshkov1-2/+2
In order to ease debugging of DSI host registration issues, print return code of dsi_mgr_setup_components(). Signed-off-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Signed-off-by: Rob Clark <[email protected]>
2021-04-07drm/msm/dsi: stop passing src_pll_id to the phy_enable callDmitry Baryshkov1-6/+5
Phy driver already knows the source PLL id basing on the set usecase and the current PLL id. Stop passing it to the phy_enable call. As a reminder, dsi manager will always use DSI 0 as a clock master in a slave mode, so PLL 0 is always a clocksource for DSI 0 and it is always a clocksource for DSI 1 too unless DSI 1 is used in the standalone mode. Signed-off-by: Dmitry Baryshkov <[email protected]> Tested-by: Stephen Boyd <[email protected]> # on sc7180 lazor Reviewed-by: Abhinav Kumar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Rob Clark <[email protected]>
2021-04-07drm/msm/dsi: make save/restore_state phy-level functionsDmitry Baryshkov1-4/+2
Morph msm_dsi_pll_save/restore_state() into msm_dsi_phy_save/restore_state(), thus removing last bits of knowledge about msm_dsi_pll from dsi_manager. Signed-off-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Tested-by: Stephen Boyd <[email protected]> # on sc7180 lazor Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Rob Clark <[email protected]>
2021-04-07drm/msm/dsi: push provided clocks handling into a generic codeDmitry Baryshkov1-10/+3
All MSM DSI PHYs provide two clocks: byte and pixel ones. Register/unregister provided clocks from the generic place, removing boilerplate code from all MSM DSI PHY drivers. Signed-off-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Abhinav Kumar <[email protected]> Tested-by: Stephen Boyd <[email protected]> # on sc7180 lazor Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Rob Clark <[email protected]>
2020-08-08drm: Remove unnecessary drm_panel_attach and drm_panel_detachJoe Perches1-1/+0
These functions are now empty and no longer useful so remove the functions and their uses. Signed-off-by: Joe Perches <[email protected]> Cc: Bernard Zhao <[email protected]> Cc: Maarten Lankhorst <[email protected]> Cc: Maxime Ripard <[email protected]>, Cc: Thomas Zimmermann <[email protected]> Cc: Thierry Reding <[email protected]> Cc: David Airlie <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Linus Walleij <[email protected]> Cc: Icenowy Zheng <[email protected]>, Cc: Jagan Teki <[email protected]> Cc: Laurent Pinchart <[email protected]> Cc: Robert Chiras <[email protected]> Cc: [email protected], Cc: [email protected] Cc: [email protected] Signed-off-by: Sam Ravnborg <[email protected]> # Fixed build and a few warnings Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-03-11Merge v5.6-rc5 into drm-nextDave Airlie1-1/+6
Requested my mripard for some misc patches that need this as a base. Signed-off-by: Dave Airlie <[email protected]>
2020-02-26drm/bridge: Extend bridge API to disable connector creationLaurent Pinchart1-2/+2
Most bridge drivers create a DRM connector to model the connector at the output of the bridge. This model is historical and has worked pretty well so far, but causes several issues: - It prevents supporting more complex display pipelines where DRM connector operations are split over multiple components. For instance a pipeline with a bridge connected to the DDC signals to read EDID data, and another one connected to the HPD signal to detect connection and disconnection, will not be possible to support through this model. - It requires every bridge driver to implement similar connector handling code, resulting in code duplication. - It assumes that a bridge will either be wired to a connector or to another bridge, but doesn't support bridges that can be used in both positions very well (although there is some ad-hoc support for this in the analogix_dp bridge driver). In order to solve these issues, ownership of the connector should be moved to the display controller driver (where it can be implemented using helpers provided by the core). Extend the bridge API to allow disabling connector creation in bridge drivers as a first step towards the new model. The new flags argument to the bridge .attach() operation allows instructing the bridge driver to skip creating a connector. Unconditionally set the new flags argument to 0 for now to keep the existing behaviour, and modify all existing bridge drivers to return an error when connector creation is not requested as they don't support this feature yet. The change is based on the following semantic patch, with manual review and edits. @ rule1 @ identifier funcs; identifier fn; @@ struct drm_bridge_funcs funcs = { ..., .attach = fn }; @ depends on rule1 @ identifier rule1.fn; identifier bridge; statement S, S1; @@ int fn( struct drm_bridge *bridge + , enum drm_bridge_attach_flags flags ) { ... when != S + if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR) { + DRM_ERROR("Fix bridge driver to make connector optional!"); + return -EINVAL; + } + S1 ... } @ depends on rule1 @ identifier rule1.fn; identifier bridge, flags; expression E1, E2, E3; @@ int fn( struct drm_bridge *bridge, enum drm_bridge_attach_flags flags ) { <... drm_bridge_attach(E1, E2, E3 + , flags ) ...> } @@ expression E1, E2, E3; @@ drm_bridge_attach(E1, E2, E3 + , 0 ) Signed-off-by: Laurent Pinchart <[email protected]> Reviewed-by: Boris Brezillon <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Reviewed-by: Tomi Valkeinen <[email protected]> Tested-by: Sebastian Reichel <[email protected]> Reviewed-by: Sebastian Reichel <[email protected]> Acked-by: Daniel Vetter <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2020-02-13drm/msm/dsi: save pll state before dsi host is powered offHarigovindan P1-0/+5
Save pll state before dsi host is powered off. Without this change some register values gets resetted. Signed-off-by: Harigovindan P <[email protected]> Signed-off-by: Rob Clark <[email protected]>
2020-02-11drm: msm: Fix return type of dsi_mgr_connector_mode_valid for kCFIJohn Stultz1-1/+1
I was hitting kCFI crashes when building with clang, and after some digging finally narrowed it down to the dsi_mgr_connector_mode_valid() function being implemented as returning an int, instead of an enum drm_mode_status. This patch fixes it, and appeases the opaque word of the kCFI gods (seriously, clang inlining everything makes the kCFI backtraces only really rough estimates of where things went wrong). Thanks as always to Sami for his help narrowing this down. Cc: Rob Clark <[email protected]> Cc: Sean Paul <[email protected]> Cc: Sami Tolvanen <[email protected]> Cc: Todd Kjos <[email protected]> Cc: Alistair Delva <[email protected]> Cc: Amit Pundir <[email protected]> Cc: Sumit Semwal <[email protected]> Cc: [email protected] Cc: [email protected] Signed-off-by: John Stultz <[email protected]> Reviewed-by: Nick Desaulniers <[email protected]> Tested-by: Amit Pundir <[email protected]> Signed-off-by: Rob Clark <[email protected]>
2020-01-20Merge tag 'drm-msm-next-2020-01-14' of ↵Dave Airlie1-21/+41
https://gitlab.freedesktop.org/drm/msm into drm-next + sc7180 display + DSI support + a618 (sc7180) support + more UBWC (bandwidth compression) support + various cleanups to handle devices that use vs don't use zap fw, etc + usual random cleanups and fixes Signed-off-by: Dave Airlie <[email protected]> From: Rob Clark <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/ <CAF6AEGvv03ifuP0tp7-dmqZtr1iS=s8Vc=az8BNGtEoSMD-dkw@mail.gmail.com
Powered by cgit, Gruvboxed by Blaster4385.