summaryrefslogtreecommitdiff
path: root/tools/perf/lib/Documentation/tutorial/git@git.tavy.me:linux.git
diff options
context:
space:
mode:
authorKonrad Dybcio <konrad.dybcio@oss.qualcomm.com>2025-10-27 14:02:14 +0100
committerBjorn Andersson <andersson@kernel.org>2026-01-07 12:41:46 -0600
commit0539c5a6fdef1b274112638aa5aa722b1df5e711 (patch)
treee66bd05935d6c25e8a9d792faf3418f816b70b0f /tools/perf/lib/Documentation/tutorial/git@git.tavy.me:linux.git
parent42f2799124a4d0081b0c8c50980e37769e8d6880 (diff)
soc: qcom: pmic_glink_altmode: Consume TBT3/USB4 mode notifications
Some compute SoCs support additional operation modes, extending the existing set of USB3/safe/DP-alt-mode. The firmware performs all the necessary handshakes for us and there is no room for error on that level (i.e. the sequences will match what happens on Windows). The trade-off with that approach is that the received notifications trim some of the PDO/EUDO data (particularly the cable/plug parts), offering a set of similar-in-nature-but-not-the-same indicators. In an attempt to remedy this, I reconstructed some of it, so that the connected mux/retimer drivers can continue to behave as expected. Add support for parsing the aforementioned data coming from PMIC_GLINK and passing it on to the various Type-C components. Reviewed-by: Jack Pham <jack.pham@oss.qualcomm.com> Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251027-topic-pg_altmode_usb4-v1-1-2931a3ecc146@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Diffstat (limited to 'tools/perf/lib/Documentation/tutorial/git@git.tavy.me:linux.git')
0 files changed, 0 insertions, 0 deletions