Re: [PATCH v2 0/4] soc: qcom: Introduce PMIC GLINK

[Dmitry Baryshkov <dmitry.baryshkov@linaro.org>]

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@linaro.org/

-- 
With best wishes
Dmitry