On 17/01/2023 02:32, Bjorn Andersson wrote:
On Fri, Jan 13, 2023 at 05:10:17PM +0000, Bryan O'Donoghue wrote:
On 13/01/2023 04:11, Bjorn Andersson wrote:
This implements the base PMIC GLINK driver, a power_supply driver and a
driver for the USB Type-C altmode protocol. This has been tested and
shown to provide battery information, USB Type-C switch and mux requests
and DisplayPort notifications on SC8180X, SC8280XP and SM8350.
Bjorn Andersson (4):
dt-bindings: soc: qcom: Introduce PMIC GLINK binding
soc: qcom: pmic_glink: Introduce base PMIC GLINK driver
soc: qcom: pmic_glink: Introduce altmode support
power: supply: Introduce Qualcomm PMIC GLINK power supply
.../bindings/soc/qcom/qcom,pmic-glink.yaml | 102 ++
drivers/power/supply/Kconfig | 9 +
drivers/power/supply/Makefile | 1 +
drivers/power/supply/qcom_battmgr.c | 1421 +++++++++++++++++
drivers/soc/qcom/Kconfig | 15 +
drivers/soc/qcom/Makefile | 2 +
drivers/soc/qcom/pmic_glink.c | 336 ++++
drivers/soc/qcom/pmic_glink_altmode.c | 477 ++++++
include/linux/soc/qcom/pmic_glink.h | 32 +
9 files changed, 2395 insertions(+)
create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml
create mode 100644 drivers/power/supply/qcom_battmgr.c
create mode 100644 drivers/soc/qcom/pmic_glink.c
create mode 100644 drivers/soc/qcom/pmic_glink_altmode.c
create mode 100644 include/linux/soc/qcom/pmic_glink.h
How does the USB PHY and a USB redriver fit into this ?
Is the host supposed to manage both/neither ? Is the DSP responsible for
configuring the PHY lanes and the turnaround on orientation switch ?
As indicated above, the firmware deals with battery management and USB
Type-C handling.
The battery/power management is handled by the battmgr implementation,
exposing the various properties through a set of power_supply objects.
The USB Type-C handling comes in two forms. The "altmode" protocol
handles DisplayPort notifications - plug detect, orientation and mode
switches. The other part of the USB implementation exposes UCSI.
The altmode implementation provides two things:
- A drm_bridge, per connector, which can be tied (of_graph) to a
DisplayPort instance, and will invoke HPD notifications on the
drm_bridge, based on notification messages thereof.
- Acquire typec_switch and typec_mux handles through the of_graph and
signal the remotes when notifications of state changes occur. Linking
this to the FSA4480, is sufficient to get USB/DP combo (2+2 lanes)
working on e.g. SM8350 HDK.
Work in progress patches also exists for teaching QMP about
orientation switching of the SS lines, but it seems this needs to be
rebased onto the refactored QMP driver.
I also have patches for QMP to make it switch USB/DP combo -> 4-lane
DP, which allow 4k support without DSC, unfortunately switch back to
USB has not been fully reliable, so this requires some more work
(downstream involves DWC3 here as well, to reprogram the PHY).
Oki doki that makes sense and is pretty much in-line with what I thought.
We still have a bunch of typec-mux and phy work to do even with
adsp/glink doing the TCPM.
Thanks for the explanation.
---
bod
