Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5 |
|
#
6c0f21f8 |
| 07-Dec-2023 |
Neil Armstrong <neil.armstrong@linaro.org> |
drm/msm/dp: Add DisplayPort controller for SM8650
[ Upstream commit 1b2d98bdd7b7c64265732f5f0dace4c52c9ba8a8 ]
The Qualcomm SM8650 platform comes with a DisplayPort controller with a different base
drm/msm/dp: Add DisplayPort controller for SM8650
[ Upstream commit 1b2d98bdd7b7c64265732f5f0dace4c52c9ba8a8 ]
The Qualcomm SM8650 platform comes with a DisplayPort controller with a different base offset than the previous SM8550 SoC, add support for this in the DisplayPort driver.
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/571132/ Link: https://lore.kernel.org/r/20231207-topic-sm8650-upstream-dp-v1-2-b762c06965bb@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
Revision tags: v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39, v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35, v6.1.34 |
|
#
fa0048a4 |
| 12-Jun-2023 |
Bjorn Andersson <quic_bjorande@quicinc.com> |
drm/msm/dp: Free resources after unregistering them
The DP component's unbind operation walks through the submodules to unregister and clean things up. But if the unbind happens because the DP contr
drm/msm/dp: Free resources after unregistering them
The DP component's unbind operation walks through the submodules to unregister and clean things up. But if the unbind happens because the DP controller itself is being removed, all the memory for those submodules has just been freed.
Change the order of these operations to avoid the many use-after-free that otherwise happens in this code path.
Fixes: c943b4948b58 ("drm/msm/dp: add displayPort driver support") Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/542166/ Link: https://lore.kernel.org/r/20230612220259.1884381-1-quic_bjorande@quicinc.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
show more ...
|
#
a7bfb2ad |
| 12-Jun-2023 |
Bjorn Andersson <quic_bjorande@quicinc.com> |
drm/msm/dp: Drop aux devices together with DP controller
Using devres to depopulate the aux bus made sure that upon a probe deferral the EDP panel device would be destroyed and recreated upon next a
drm/msm/dp: Drop aux devices together with DP controller
Using devres to depopulate the aux bus made sure that upon a probe deferral the EDP panel device would be destroyed and recreated upon next attempt.
But the struct device which the devres is tied to is the DPUs (drm_dev->dev), which may be happen after the DP controller is torn down.
Indications of this can be seen in the commonly seen EDID-hexdump full of zeros in the log, or the occasional/rare KASAN fault where the panel's attempt to read the EDID information causes a use after free on DP resources.
It's tempting to move the devres to the DP controller's struct device, but the resources used by the device(s) on the aux bus are explicitly torn down in the error path. The KASAN-reported use-after-free also remains, as the DP aux "module" explicitly frees its devres-allocated memory in this code path.
As such, explicitly depopulate the aux bus in the error path, and in the component unbind path, to avoid these issues.
Fixes: 2b57f726611e ("drm/msm/dp: fix aux-bus EP lifetime") Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Patchwork: https://patchwork.freedesktop.org/patch/542163/ Link: https://lore.kernel.org/r/20230612220106.1884039-1-quic_bjorande@quicinc.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
show more ...
|
Revision tags: v6.1.33, v6.1.32, v6.1.31, v6.1.30 |
|
#
a8e981ac |
| 23-May-2023 |
Kuogee Hsieh <quic_khsieh@quicinc.com> |
drm/msm/dp: enable HDP plugin/unplugged interrupts at hpd_enable/disable
The internal_hpd flag is set to true by dp_bridge_hpd_enable() and set to false by dp_bridge_hpd_disable() to handle GPIO pin
drm/msm/dp: enable HDP plugin/unplugged interrupts at hpd_enable/disable
The internal_hpd flag is set to true by dp_bridge_hpd_enable() and set to false by dp_bridge_hpd_disable() to handle GPIO pinmuxed into DP controller case. HDP related interrupts can not be enabled until internal_hpd is set to true. At current implementation dp_display_config_hpd() will initialize DP host controller first followed by enabling HDP related interrupts if internal_hpd was true at that time. Enable HDP related interrupts depends on internal_hpd status may leave system with DP driver host is in running state but without HDP related interrupts being enabled. This will prevent external display from being detected. Eliminated this dependency by moving HDP related interrupts enable/disable be done at dp_bridge_hpd_enable/disable() directly regardless of internal_hpd status.
Changes in V3: -- dp_catalog_ctrl_hpd_enable() and dp_catalog_ctrl_hpd_disable() -- rewording ocmmit text
Changes in V4: -- replace dp_display_config_hpd() with dp_display_host_start() -- move enable_irq() at dp_display_host_start();
Changes in V5: -- replace dp_display_host_start() with dp_display_host_init()
Changes in V6: -- squash remove enable_irq() and disable_irq()
Fixes: cd198caddea7 ("drm/msm/dp: Rely on hpd_enable/disable callbacks") Signed-off-by: Kuogee Hsieh <quic_khsieh@quicinc.com> Tested-by: Leonard Lausen <leonard@lausen.nl> # on sc7180 lazor Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Bjorn Andersson <andersson@kernel.org> Tested-by: Bjorn Andersson <andersson@kernel.org> Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Link: https://lore.kernel.org/r/1684878756-17830-1-git-send-email-quic_khsieh@quicinc.com Signed-off-by: Rob Clark <robdclark@chromium.org>
show more ...
|
#
1c5f6051 |
| 20-May-2023 |
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> |
drm/msm/dp: remove most of usbpd-related remains
Remove most of remains of downstream usbpd code. Mainline kernel uses different approach for managing Type-C / USB-PD, so this remains unused.
Signe
drm/msm/dp: remove most of usbpd-related remains
Remove most of remains of downstream usbpd code. Mainline kernel uses different approach for managing Type-C / USB-PD, so this remains unused.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Bjorn Andersson <andersson@kernel.org> Patchwork: https://patchwork.freedesktop.org/patch/538270/ Link: https://lore.kernel.org/r/20230520182050.4014143-1-dmitry.baryshkov@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
show more ...
|
Revision tags: v6.1.29, v6.1.28, v6.1.27 |
|
#
b78c7727 |
| 27-Apr-2023 |
Abhinav Kumar <quic_abhinavk@quicinc.com> |
drm/msm/dp: add module parameter for PSR
On sc7280 where eDP is the primary display, PSR is causing IGT breakage even for basic test cases like kms_atomic and kms_atomic_transition. Most often the i
drm/msm/dp: add module parameter for PSR
On sc7280 where eDP is the primary display, PSR is causing IGT breakage even for basic test cases like kms_atomic and kms_atomic_transition. Most often the issue starts with below stack so providing that as reference
Call trace: dpu_encoder_assign_crtc+0x64/0x6c dpu_crtc_enable+0x188/0x204 drm_atomic_helper_commit_modeset_enables+0xc0/0x274 msm_atomic_commit_tail+0x1a8/0x68c commit_tail+0xb0/0x160 drm_atomic_helper_commit+0x11c/0x124 drm_atomic_commit+0xb0/0xdc drm_atomic_connector_commit_dpms+0xf4/0x110 drm_mode_obj_set_property_ioctl+0x16c/0x3b0 drm_connector_property_set_ioctl+0x4c/0x74 drm_ioctl_kernel+0xec/0x15c drm_ioctl+0x264/0x408 __arm64_sys_ioctl+0x9c/0xd4 invoke_syscall+0x4c/0x110 el0_svc_common+0x94/0xfc do_el0_svc+0x3c/0xb0 el0_svc+0x2c/0x7c el0t_64_sync_handler+0x48/0x114 el0t_64_sync+0x190/0x194 ---[ end trace 0000000000000000 ]--- [drm-dp] dp_ctrl_push_idle: PUSH_IDLE pattern timedout
Other basic use-cases still seem to work fine hence add a a module parameter to allow toggling psr enable/disable till PSR related issues are hashed out with IGT.
Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Acked-by: Rob Clark <robdclark@gmail.com> Patchwork: https://patchwork.freedesktop.org/patch/534420/ Link: https://lore.kernel.org/r/20230427232848.5200-1-quic_abhinavk@quicinc.com Signed-off-by: Rob Clark <robdclark@chromium.org>
show more ...
|
Revision tags: v6.1.26, v6.3 |
|
#
85c63628 |
| 21-Apr-2023 |
Srinivas Kandagatla <srinivas.kandagatla@linaro.org> |
drm/msm/dp: unregister audio driver during unbind
while binding the code always registers a audio driver, however there is no corresponding unregistration done in unbind. This leads to multiple redu
drm/msm/dp: unregister audio driver during unbind
while binding the code always registers a audio driver, however there is no corresponding unregistration done in unbind. This leads to multiple redundant audio platform devices if dp_display_bind and dp_display_unbind happens multiple times during startup. On X13s platform this resulted in 6 to 9 audio codec device instead of just 3 codec devices for 3 dp ports.
Fix this by unregistering codecs on unbind.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Fixes: d13e36d7d222 ("drm/msm/dp: add audio support for Display Port on MSM") Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Patchwork: https://patchwork.freedesktop.org/patch/533324/ Link: https://lore.kernel.org/r/20230421145657.12186-1-srinivas.kandagatla@linaro.org Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
show more ...
|
Revision tags: v6.1.25, v6.1.24, v6.1.23, v6.1.22, v6.1.21, v6.1.20, v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9 |
|
#
bfc12020 |
| 26-Jan-2023 |
Douglas Anderson <dianders@chromium.org> |
drm/msm/dp: Return IRQ_NONE for unhandled interrupts
If our interrupt handler gets called and we don't really handle the interrupt then we should return IRQ_NONE. The current interrupt handler didn'
drm/msm/dp: Return IRQ_NONE for unhandled interrupts
If our interrupt handler gets called and we don't really handle the interrupt then we should return IRQ_NONE. The current interrupt handler didn't do this, so let's fix it.
NOTE: for some of the cases it's clear that we should return IRQ_NONE and some cases it's clear that we should return IRQ_HANDLED. However, there are a few that fall somewhere in between. Specifically, the documentation for when to return IRQ_NONE vs. IRQ_HANDLED is probably best spelled out in the commit message of commit d9e4ad5badf4 ("Document that IRQ_NONE should be returned when IRQ not actually handled"). That commit makes it clear that we should return IRQ_HANDLED if we've done something to make the interrupt stop happening.
The case where it's unclear is, for instance, in dp_aux_isr() after we've read the interrupt using dp_catalog_aux_get_irq() and confirmed that "isr" is non-zero. The function dp_catalog_aux_get_irq() not only reads the interrupts but it also "ack"s all the interrupts that are returned. For an "unknown" interrupt this has a very good chance of actually stopping the interrupt from happening. That would mean we've identified that it's our device and done something to stop them from happening and should return IRQ_HANDLED. Specifically, it should be noted that most interrupts that need "ack"ing are ones that are one-time events and doing an "ack" is enough to clear them. However, since these interrupts are unknown then, by definition, it's unknown if "ack"ing them is truly enough to clear them. It's possible that we also need to remove the original source of the interrupt. In this case, IRQ_NONE would be a better choice.
Given that returning an occasional IRQ_NONE isn't the absolute end of the world, however, let's choose that course of action. The IRQ framework will forgive a few IRQ_NONE returns now and again (and it won't even log them, which is why we have to log them ourselves). This means that if we _do_ end hitting an interrupt where "ack"ing isn't enough the kernel will eventually detect the problem and shut our device down.
Signed-off-by: Douglas Anderson <dianders@chromium.org> Tested-by: Kuogee Hsieh <quic_khsieh@quicinc.com> Reviewed-by: Kuogee Hsieh <quic_khsieh@quicinc.com> Patchwork: https://patchwork.freedesktop.org/patch/520660/ Link: https://lore.kernel.org/r/20230126170745.v2.2.I2d7aec2fadb9c237cd0090a47d6a8ba2054bf0f8@changeid [DB: reformatted commit message to make checkpatch happy] Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
show more ...
|
#
05d00135 |
| 02-Mar-2023 |
Vinod Polimera <quic_vpolimer@quicinc.com> |
drm/msm/dp: use the eDP bridge ops to validate eDP modes
The eDP and DP interfaces shared the bridge operations and the eDP specific changes were implemented under is_edp check. To add psr support f
drm/msm/dp: use the eDP bridge ops to validate eDP modes
The eDP and DP interfaces shared the bridge operations and the eDP specific changes were implemented under is_edp check. To add psr support for eDP, we started using a new set of eDP bridge ops. We are moving the eDP specific code in the dp_bridge_mode_valid function to a new eDP function, edp_bridge_mode_valid under the eDP bridge ops.
Signed-off-by: Sankeerth Billakanti <quic_sbillaka@quicinc.com> Signed-off-by: Vinod Polimera <quic_vpolimer@quicinc.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/524736/ Link: https://lore.kernel.org/r/1677774797-31063-11-git-send-email-quic_vpolimer@quicinc.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
show more ...
|
#
cd779808 |
| 02-Mar-2023 |
Vinod Polimera <quic_vpolimer@quicinc.com> |
drm/msm/dp: Add basic PSR support for eDP
Add support for basic panel self refresh (PSR) feature for eDP. Add a new interface to set PSR state in the sink from DPU. Program the eDP controller to iss
drm/msm/dp: Add basic PSR support for eDP
Add support for basic panel self refresh (PSR) feature for eDP. Add a new interface to set PSR state in the sink from DPU. Program the eDP controller to issue PSR enter and exit SDP to the sink.
Signed-off-by: Sankeerth Billakanti <quic_sbillaka@quicinc.com> Signed-off-by: Vinod Polimera <quic_vpolimer@quicinc.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/524734/ Link: https://lore.kernel.org/r/1677774797-31063-10-git-send-email-quic_vpolimer@quicinc.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
show more ...
|
#
cdfd0e62 |
| 02-Mar-2023 |
Vinod Polimera <quic_vpolimer@quicinc.com> |
drm/msm/dp: use atomic callbacks for DP bridge ops
Use atomic variants for DP bridge callback functions so that the atomic state can be accessed in the interface drivers. The atomic state will help
drm/msm/dp: use atomic callbacks for DP bridge ops
Use atomic variants for DP bridge callback functions so that the atomic state can be accessed in the interface drivers. The atomic state will help the driver find out if the display is in self refresh state.
Signed-off-by: Sankeerth Billakanti <quic_sbillaka@quicinc.com> Signed-off-by: Vinod Polimera <quic_vpolimer@quicinc.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Patchwork: https://patchwork.freedesktop.org/patch/524731/ Link: https://lore.kernel.org/r/1677774797-31063-9-git-send-email-quic_vpolimer@quicinc.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
show more ...
|
Revision tags: v6.1.8, v6.1.7 |
|
#
e17af1c9 |
| 17-Jan-2023 |
Bjorn Andersson <quic_bjorande@quicinc.com> |
drm/msm/dp: Remove INIT_SETUP delay
During initalization of the DisplayPort controller an EV_HPD_INIT_SETUP event is generated, but with a delay of 100 units. This delay existed to circumvent bug in
drm/msm/dp: Remove INIT_SETUP delay
During initalization of the DisplayPort controller an EV_HPD_INIT_SETUP event is generated, but with a delay of 100 units. This delay existed to circumvent bug in the QMP combo PHY driver, where if the DP part was powered up before USB, the common properties would not be properly initialized - and USB wouldn't work.
This issue was resolved in the recent refactoring of the QMP driver, so it's now possible to remove this delay.
While there is still a timing dependency in the current implementation, test indicates that it's now possible to boot with an external display on USB Type-C and have the display power up, without disconnecting and reconnecting the cable.
Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com> Reviewed-by: Kuogee Hsieh <quic_khsieh@quicinc.com> Patchwork: https://patchwork.freedesktop.org/patch/518729/ Link: https://lore.kernel.org/r/20230117172951.2748456-1-quic_bjorande@quicinc.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
show more ...
|
Revision tags: v6.1.6, v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16 |
|
#
0e7f2705 |
| 27-Dec-2022 |
Kuogee Hsieh <quic_khsieh@quicinc.com> |
drm/msm/dp: add support of max dp link rate
By default, HBR2 (5.4G) is the max link rate be supported. This patch uses the actual limit specified by DT and removes the artificial limitation to 5.4 G
drm/msm/dp: add support of max dp link rate
By default, HBR2 (5.4G) is the max link rate be supported. This patch uses the actual limit specified by DT and removes the artificial limitation to 5.4 Gbps. Supporting HBR3 is a consequence of that.
Changes in v2: -- add max link rate from dtsi
Changes in v3: -- parser max_data_lanes and max_dp_link_rate from dp_out endpoint
Changes in v4: -- delete unnecessary pr_err
Changes in v5: -- split parser function into different patch
Changes in v9: -- revised commit test
Changes in v13: -- repalced "properity" with "property"
Signed-off-by: Kuogee Hsieh <quic_khsieh@quicinc.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/516097/ Link: https://lore.kernel.org/r/1672163103-31254-6-git-send-email-quic_khsieh@quicinc.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
show more ...
|
Revision tags: v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12 |
|
#
542b37ef |
| 07-Dec-2022 |
Bjorn Andersson <bjorn.andersson@linaro.org> |
drm/msm/dp: Implement hpd_notify()
The DisplayPort controller's hot-plug mechanism is based on pinmuxing a physical signal on a GPIO pin into the controller. This is not always possible, either beca
drm/msm/dp: Implement hpd_notify()
The DisplayPort controller's hot-plug mechanism is based on pinmuxing a physical signal on a GPIO pin into the controller. This is not always possible, either because there aren't dedicated GPIOs available or because the hot-plug signal is a virtual notification, in cases such as USB Type-C.
For these cases, by implementing the hpd_notify() callback for the DisplayPort controller's drm_bridge, a downstream drm_bridge (next_bridge) can be used to track and signal the connection status changes.
This makes it possible to use downstream drm_bridges such as display-connector or any virtual mechanism, as long as they are implemented as a drm_bridge.
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> [bjorn: Drop connector->fwnode assignment and dev from struct msm_dp] Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Kuogee Hsieh <quic_khsieh@quicinc.com> Patchwork: https://patchwork.freedesktop.org/patch/514410/ Link: https://lore.kernel.org/r/20221207220012.16529-10-quic_bjorande@quicinc.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
show more ...
|
#
cd198cad |
| 07-Dec-2022 |
Bjorn Andersson <bjorn.andersson@linaro.org> |
drm/msm/dp: Rely on hpd_enable/disable callbacks
The DisplayPort controller's internal HPD interrupt handling is used for cases where the HPD signal is connected to a GPIO which is pinmuxed into the
drm/msm/dp: Rely on hpd_enable/disable callbacks
The DisplayPort controller's internal HPD interrupt handling is used for cases where the HPD signal is connected to a GPIO which is pinmuxed into the DisplayPort controller. In other configurations the HPD notification might be delivered by the DRM framework from an associated bridge.
This difference is not appropriately represented by the "is_edp" boolean, but is properly represented by the frameworks invocation of the hpd_enable() and hpd_disable() callbacks. Switch the current condition to rely on these callbacks instead.
This ensures appropriate handling of the three cases; no bridge connected, a bridge without DRM_BRIDGE_OP_HPD and a bridge with DRM_BRIDGE_OP_HPD.
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Kuogee Hsieh <quic_khsieh@quicinc.com> Patchwork: https://patchwork.freedesktop.org/patch/514414/ Link: https://lore.kernel.org/r/20221207220012.16529-9-quic_bjorande@quicinc.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
show more ...
|
#
fa33f2aa |
| 07-Dec-2022 |
Bjorn Andersson <bjorn.andersson@linaro.org> |
drm/msm/dp: Add SDM845 DisplayPort instance
The Qualcomm SDM845 platform has a single DisplayPort controller, with the same design as SC7180, so add support for this by reusing the SC7180 definition
drm/msm/dp: Add SDM845 DisplayPort instance
The Qualcomm SDM845 platform has a single DisplayPort controller, with the same design as SC7180, so add support for this by reusing the SC7180 definition.
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com> Reviewed-by: Kuogee Hsieh <quic_khsieh@quicinc.com> Patchwork: https://patchwork.freedesktop.org/patch/514395/ Link: https://lore.kernel.org/r/20221207220012.16529-8-quic_bjorande@quicinc.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
show more ...
|
#
5bd69fd1 |
| 07-Dec-2022 |
Bjorn Andersson <bjorn.andersson@linaro.org> |
drm/msm/dp: Add DP and EDP compatibles for SC8280XP
The SC8280XP platform has four DisplayPort controllers, per MDSS instance, all with widebus support.
The first two are defined to be DisplayPort
drm/msm/dp: Add DP and EDP compatibles for SC8280XP
The SC8280XP platform has four DisplayPort controllers, per MDSS instance, all with widebus support.
The first two are defined to be DisplayPort only, while the latter pair (of each instance) can be either DisplayPort or Embedded DisplayPort. The two sets are tied to the possible compatibels.
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com> Reviewed-by: Kuogee Hsieh <quic_khsieh@quicinc.com> Patchwork: https://patchwork.freedesktop.org/patch/514394/ Link: https://lore.kernel.org/r/20221207220012.16529-7-quic_bjorande@quicinc.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
show more ...
|
#
5d417b40 |
| 07-Dec-2022 |
Bjorn Andersson <bjorn.andersson@linaro.org> |
drm/msm/dp: Stop using DP id as index in desc
In the SC8280XP platform there are two identical MDSS instances, each with the same set of DisplayPort instances, at different addresses.
By not relyin
drm/msm/dp: Stop using DP id as index in desc
In the SC8280XP platform there are two identical MDSS instances, each with the same set of DisplayPort instances, at different addresses.
By not relying on the index to define the instance id it's possible to describe them both in the same table and hence have a single compatible.
While at it, flatten the cfg/desc structure so that the match data is just an array of descs.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com> Reviewed-by: Kuogee Hsieh <quic_khsieh@quicinc.com> Patchwork: https://patchwork.freedesktop.org/patch/514397/ Link: https://lore.kernel.org/r/20221207220012.16529-6-quic_bjorande@quicinc.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
show more ...
|
Revision tags: v6.0.11, v6.0.10, v5.15.80, v6.0.9, v5.15.79, v6.0.8, v5.15.78 |
|
#
b2a1c5ca |
| 07-Nov-2022 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm/msm: Use drm_mode_copy()
struct drm_display_mode embeds a list head, so overwriting the full struct with another one will corrupt the list (if the destination mode is on a list). Use drm_mode_co
drm/msm: Use drm_mode_copy()
struct drm_display_mode embeds a list head, so overwriting the full struct with another one will corrupt the list (if the destination mode is on a list). Use drm_mode_copy() instead which explicitly preserves the list head of the destination mode.
Even if we know the destination mode is not on any list using drm_mode_copy() seems decent as it sets a good example. Bad examples of not using it might eventually get copied into code where preserving the list head actually matters.
Obviously one case not covered here is when the mode itself is embedded in a larger structure and the whole structure is copied. But if we are careful when copying into modes embedded in structures I think we can be a little more reassured that bogus list heads haven't been propagated in.
@is_mode_copy@ @@ drm_mode_copy(...) { ... }
@depends on !is_mode_copy@ struct drm_display_mode *mode; expression E, S; @@ ( - *mode = E + drm_mode_copy(mode, &E) | - memcpy(mode, E, S) + drm_mode_copy(mode, E) )
@depends on !is_mode_copy@ struct drm_display_mode mode; expression E; @@ ( - mode = E + drm_mode_copy(&mode, &E) | - memcpy(&mode, E, S) + drm_mode_copy(&mode, E) )
@@ struct drm_display_mode *mode; @@ - &*mode + mode
Cc: Rob Clark <robdclark@gmail.com> Cc: Sean Paul <sean@poorly.run> Cc: Abhinav Kumar <quic_abhinavk@quicinc.com> Cc: linux-arm-msm@vger.kernel.org Cc: freedreno@lists.freedesktop.org Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221107192545.9896-5-ville.syrjala@linux.intel.com
show more ...
|
Revision tags: v6.0.7, v5.15.77, v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3, v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0, v5.15.71, v5.15.70, v5.15.69, v5.15.68 |
|
#
f94eff09 |
| 13-Sep-2022 |
Johan Hovold <johan+linaro@kernel.org> |
drm/msm/dp: drop modeset sanity checks
Drop the overly defensive modeset sanity checks of function parameters which have already been checked or used by the callers.
Reviewed-by: Dmitry Baryshkov <
drm/msm/dp: drop modeset sanity checks
Drop the overly defensive modeset sanity checks of function parameters which have already been checked or used by the callers.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Tested-by: Kuogee Hsieh <quic_khsieh@quicinc.com> Reviewed-by: Kuogee Hsieh <quic_khsieh@quicinc.com> Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Patchwork: https://patchwork.freedesktop.org/patch/502674/ Link: https://lore.kernel.org/r/20220913085320.8577-10-johan+linaro@kernel.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
show more ...
|
#
16194958 |
| 13-Sep-2022 |
Johan Hovold <johan+linaro@kernel.org> |
drm/msm/dp: fix bridge lifetime
Device-managed resources allocated post component bind must be tied to the lifetime of the aggregate DRM device or they will not necessarily be released when binding
drm/msm/dp: fix bridge lifetime
Device-managed resources allocated post component bind must be tied to the lifetime of the aggregate DRM device or they will not necessarily be released when binding of the aggregate device is deferred.
This can lead resource leaks or failure to bind the aggregate device when binding is later retried and a second attempt to allocate the resources is made.
For the DP bridges, previously allocated bridges will leak on probe deferral.
Fix this by amending the DP parser interface and tying the lifetime of the bridge device to the DRM device rather than DP platform device.
Fixes: c3bf8e21b38a ("drm/msm/dp: Add eDP support via aux_bus") Cc: stable@vger.kernel.org # 5.19 Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Tested-by: Kuogee Hsieh <quic_khsieh@quicinc.com> Reviewed-by: Kuogee Hsieh <quic_khsieh@quicinc.com> Patchwork: https://patchwork.freedesktop.org/patch/502667/ Link: https://lore.kernel.org/r/20220913085320.8577-8-johan+linaro@kernel.org Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
show more ...
|
#
2b57f726 |
| 13-Sep-2022 |
Johan Hovold <johan+linaro@kernel.org> |
drm/msm/dp: fix aux-bus EP lifetime
Device-managed resources allocated post component bind must be tied to the lifetime of the aggregate DRM device or they will not necessarily be released when bind
drm/msm/dp: fix aux-bus EP lifetime
Device-managed resources allocated post component bind must be tied to the lifetime of the aggregate DRM device or they will not necessarily be released when binding of the aggregate device is deferred.
This can lead resource leaks or failure to bind the aggregate device when binding is later retried and a second attempt to allocate the resources is made.
For the DP aux-bus, an attempt to populate the bus a second time will simply fail ("DP AUX EP device already populated").
Fix this by tying the lifetime of the EP device to the DRM device rather than DP controller platform device.
Fixes: c3bf8e21b38a ("drm/msm/dp: Add eDP support via aux_bus") Cc: stable@vger.kernel.org # 5.19 Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Tested-by: Kuogee Hsieh <quic_khsieh@quicinc.com> Reviewed-by: Kuogee Hsieh <quic_khsieh@quicinc.com> Patchwork: https://patchwork.freedesktop.org/patch/502672/ Link: https://lore.kernel.org/r/20220913085320.8577-7-johan+linaro@kernel.org Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
show more ...
|
#
a79343dc |
| 13-Sep-2022 |
Johan Hovold <johan+linaro@kernel.org> |
drm/msm/dp: fix IRQ lifetime
Device-managed resources allocated post component bind must be tied to the lifetime of the aggregate DRM device or they will not necessarily be released when binding of
drm/msm/dp: fix IRQ lifetime
Device-managed resources allocated post component bind must be tied to the lifetime of the aggregate DRM device or they will not necessarily be released when binding of the aggregate device is deferred.
This is specifically true for the DP IRQ, which will otherwise remain requested so that the next bind attempt fails when requesting the IRQ a second time.
Since commit c3bf8e21b38a ("drm/msm/dp: Add eDP support via aux_bus") this can happen when the aux-bus panel driver has not yet been loaded so that probe is deferred.
Fix this by tying the device-managed lifetime of the DP IRQ to the DRM device so that it is released when bind fails.
Fixes: c943b4948b58 ("drm/msm/dp: add displayPort driver support") Cc: stable@vger.kernel.org # 5.10 Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Tested-by: Kuogee Hsieh <quic_khsieh@quicinc.com> Reviewed-by: Kuogee Hsieh <quic_khsieh@quicinc.com> Patchwork: https://patchwork.freedesktop.org/patch/502679/ Link: https://lore.kernel.org/r/20220913085320.8577-6-johan+linaro@kernel.org Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
show more ...
|
#
74466e46 |
| 13-Sep-2022 |
Johan Hovold <johan+linaro@kernel.org> |
drm/msm/dp: fix memory corruption with too many bridges
Add the missing sanity check on the bridge counter to avoid corrupting data beyond the fixed-sized bridge array in case there are ever more th
drm/msm/dp: fix memory corruption with too many bridges
Add the missing sanity check on the bridge counter to avoid corrupting data beyond the fixed-sized bridge array in case there are ever more than eight bridges.
Fixes: 8a3b4c17f863 ("drm/msm/dp: employ bridge mechanism for display enable and disable") Cc: stable@vger.kernel.org # 5.17 Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Tested-by: Kuogee Hsieh <quic_khsieh@quicinc.com> Reviewed-by: Kuogee Hsieh <quic_khsieh@quicinc.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/502664/ Link: https://lore.kernel.org/r/20220913085320.8577-3-johan+linaro@kernel.org Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
show more ...
|
Revision tags: v5.15.67, v5.15.66, v5.15.65, v5.15.64, v5.15.63, v5.15.62, v5.15.61, v5.15.60, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56, v5.15.55, v5.15.54, v5.15.53, v5.15.52, v5.15.51, v5.15.50, v5.15.49 |
|
#
ff46c2c4 |
| 17-Jun-2022 |
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> |
drm/msm/dp: remove dp_display_en/disable prototypes and data argument
Remove unused dp_display_en/disable prototypes. While we are at it, remove extra 'data' argument that is unused.
Signed-off-by:
drm/msm/dp: remove dp_display_en/disable prototypes and data argument
Remove unused dp_display_en/disable prototypes. While we are at it, remove extra 'data' argument that is unused.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Kuogee Hsieh <quic_khsieh@quicinc.com> Patchwork: https://patchwork.freedesktop.org/patch/490104/ Link: https://lore.kernel.org/r/20220617232434.1139950-3-dmitry.baryshkov@linaro.org Signed-off-by: Rob Clark <robdclark@chromium.org>
show more ...
|