On Tue, Jan 17, 2023 at 11:26:58AM +0200, Dmitry Baryshkov wrote: > On 17/01/2023 04:58, Bjorn Andersson wrote: > > On Tue, Jan 17, 2023 at 02:37:27AM +0000, Bryan O'Donoghue wrote: > > > 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. > > > > > > > Correct, the registration of QMP as a typec_switch and typec_mux and > > handling of respective notification remains open and should (by design) > > be independent of the TCPM implementation. > > > > In particular the orientation switching is an itch worth scratching at > > this time. But when the DPU becomes capable of producing 4k@60 output it > > would obviously be nice to have the whole shebang :) > > Did you try it with the wide planes patchset at [1]? I was able to get > stable 4k@30 on RB3 (being limited only by the DSI-HDMI bridge). > > [1] https://lore.kernel.org/linux-arm-msm/20221229191856.3508092-1-dmitry.baryshkov@xxxxxxxxxx/ > I have not done so, as the patches I had for switching to 4-lane DP output needs to be rewritten since the refactoring. I had no problem doing 4k@30 prior to your efforts, so I'm interested in validating the changes you've made. Thanks, Bjorn > -- > With best wishes > Dmitry >
