kernel.git/drivers/gpu/drm/msm/dp, branch linux-6.3.y

drm/msm/dp: Free resources after unregistering them

2023-07-11T17:39:43Z

[ Upstream commit fa0048a4b1fa7a50c8b0e514f5b428abdf69a6f8 ] 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 Reviewed-by: Dmitry Baryshkov 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 Signed-off-by: Sasha Levin

drm/msm/dp: Drop aux devices together with DP controller

2023-07-11T17:39:43Z

[ Upstream commit a7bfb2ad2184a1fba78be35209b6019aa8cc8d4d ] 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 Reviewed-by: Dmitry Baryshkov Reviewed-by: Douglas Anderson 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 Signed-off-by: Sasha Levin

drm/msm/dp: unregister audio driver during unbind

2023-05-24T16:30:12Z

[ Upstream commit 85c636284cb63b7740b4ae98881ace92158068d3 ] 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 Fixes: d13e36d7d222 ("drm/msm/dp: add audio support for Display Port on MSM") Reviewed-by: Abhinav Kumar 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 Signed-off-by: Sasha Levin

drm/msm/dp: Clean up handling of DP AUX interrupts

2023-05-24T16:30:03Z

[ Upstream commit b20566cdef05cd40d95f10869d2a7646f48b1bbe ] The DP AUX interrupt handling was a bit of a mess. * There were two functions (one for "native" transfers and one for "i2c" transfers) that were quite similar. It was hard to say how many of the differences between the two functions were on purpose and how many of them were just an accident of how they were coded. * Each function sometimes used "else if" to test for error bits and sometimes didn't and again it was hard to say if this was on purpose or just an accident. * The two functions wouldn't notice whether "unknown" bits were set. For instance, there seems to be a bit "DP_INTR_PLL_UNLOCKED" and if it was set there would be no indication. * The two functions wouldn't notice if more than one error was set. Let's fix this by being more consistent / explicit about what we're doing. By design this could cause different handling for AUX transfers, though I'm not actually aware of any bug fixed as a result of this patch (this patch was created because we simply noticed how odd the old code was by code inspection). Specific notes here: 1. In the old native transfer case if we got "done + wrong address" we'd ignore the "wrong address" (because of the "else if"). Now we won't. 2. In the old native transfer case if we got "done + timeout" we'd ignore the "timeout" (because of the "else if"). Now we won't. 3. In the old native transfer case we'd see "nack_defer" and translate it to the error number for "nack". This differed from the i2c transfer case where "nack_defer" was given the error number for "nack_defer". This 100% can't matter because the only user of this error number treats "nack defer" the same as "nack", so it's clear that the difference between the "native" and "i2c" was pointless here. 4. In the old i2c transfer case if we got "done" plus any error besides "nack" or "defer" then we'd ignore the error. Now we don't. 5. If there is more than one error signaled by the hardware it's possible that we'll report a different one than we used to. I don't know if this matters. If someone is aware of a case this matters we should document it and change the code to make it explicit. 6. One quirk we keep (I don't know if this is important) is that in the i2c transfer case if we see "done + defer" we report that as a "nack". That seemed too intentional in the old code to just drop. After this change we will add extra logging, including: * A warning if we see more than one error bit set. * A warning if we see an unexpected interrupt. * A warning if we get an AUX transfer interrupt when shouldn't. It actually turns out that as a result of this change then at boot we sometimes see an error: [drm:dp_aux_isr] *ERROR* Unexpected DP AUX IRQ 0x01000000 when not busy That means that, during init, we are seeing DP_INTR_PLL_UNLOCKED. For now I'm going to say that leaving this error reported in the logs is OK-ish and hopefully it will encourage someone to track down what's going on at init time. One last note here is that this change renames one of the interrupt bits. The bit named "i2c done" clearly was used for native transfers being done too, so I renamed it to indicate this. Signed-off-by: Douglas Anderson Tested-by: Kuogee Hsieh Reviewed-by: Kuogee Hsieh Patchwork: https://patchwork.freedesktop.org/patch/520658/ Link: https://lore.kernel.org/r/20230126170745.v2.1.I90ffed3ddd21e818ae534f820cb4d6d8638859ab@changeid Signed-off-by: Dmitry Baryshkov Signed-off-by: Sasha Levin

Merge branch 'msm-next-lumag' into HEAD

2023-01-22T20:43:59Z

Merge display-related changes targeting Qualcomm DRM MSM driver. Notable changes: DPU, DSI, MDSS: - Support for SM8350, SM8450 SM8550 and SC8280XP platform Core: - Added bindings for SM8150 (driver support already present) DPU: - Partial support for DSC on SM8150 and SM8250 - Fixed color transformation matrix being lost on suspend/resume DP: - Support for DP on SDM845 and SC8280XP platforms - HPD fixes - Support for limiting DP link rate via DT property, this enables support for HBR3 rates. DSI: - Validate display modes according to the DSI OPP table - DSI PHY support for the SM6375 platform - Fixed byte intf clock selection for 14nm PHYs MDP5: - Schema conversion to YAML Misc fixes as usual Signed-off-by: Dmitry Baryshkov Signed-off-by: Dmitry Baryshkov

drm/msm/dp: Remove INIT_SETUP delay

2023-01-18T01:45:14Z

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 Reviewed-by: Kuogee Hsieh 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

drm/msm/dp: add support of max dp link rate

2023-01-09T01:06:44Z

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 Reviewed-by: Dmitry Baryshkov 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

drm/msm/dp: Add capability to parser and retrieve max DP link supported rate from link-frequencies property of dp_out endpoint

2023-01-09T01:06:44Z

Changes in v6: -- second patch after split parser patch into two patches Changes in v7: -- without checking cnt against DP_MAX_NUM_DP_LANES to retrieve link rate Changes in v9: -- separate parser link-frequencies out of data-lanes Changes in v10: -- add dp_parser_link_frequencies() Changes in v11: -- return 0 if(!endpoint) Changes in v12: -- replace khz with kbytes at dp_parser.h Changes in v14: -- replace "parser" with "parse" at commit subject -- use do_div() for 64 bits division Signed-off-by: Kuogee Hsieh Reviewed-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/516100/ Link: https://lore.kernel.org/r/1672163103-31254-5-git-send-email-quic_khsieh@quicinc.com Signed-off-by: Dmitry Baryshkov

drm/msm/dp: parse data-lanes as property of dp_out endpoint

2023-01-09T01:06:44Z

Add capability to parser data-lanes as property of dp_out endpoint. Also retain the original capability to parser data-lanes as property of mdss_dp node to handle legacy case. Changes in v6: -- first patch after split parser patch into two Changes in v7: -- check "data-lanes" from endpoint first Changes in v14: -- replace "parser" with "parse" at commit subject -- add matching brackets at dp_parser_misc() Changes in v15: -- concise dp_parser_misc() Signed-off-by: Kuogee Hsieh Reviewed-by: Dmitry Baryshkov Patchwork: https://patchwork.freedesktop.org/patch/516096/ Link: https://lore.kernel.org/r/1672163103-31254-4-git-send-email-quic_khsieh@quicinc.com Signed-off-by: Dmitry Baryshkov

drm/msm/dp: Implement hpd_notify()

2023-01-09T01:06:43Z

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: Drop connector->fwnode assignment and dev from struct msm_dp] Signed-off-by: Bjorn Andersson Reviewed-by: Dmitry Baryshkov Reviewed-by: Kuogee Hsieh 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