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

  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
  

On 13.01.2023 05: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.
> 
For the series:

Tested-by: Konrad Dybcio <konrad.dybcio@linaro.org> # SM8350 PDX215

Thanks a lot for working on this!

One thing, /sys/class/power_supply/qcom-battmgr-usb/input_current_limit
is stuck at zero and so is the current_now as a result (the voltage
readout is 5V + some noise, so that looks good), but I don't see any
SET paths for it in the driver, so I suppose that's what the firmware
default is?

Konrad

> 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
>
  

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 ?

---
bod
  

On Fri, Jan 13, 2023 at 03:56:59PM +0100, Konrad Dybcio wrote:
> 
> 
> On 13.01.2023 05: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.
> > 
> For the series:
> 
> Tested-by: Konrad Dybcio <konrad.dybcio@linaro.org> # SM8350 PDX215
> 
> Thanks a lot for working on this!
> 

Thank you for testing it :)

> One thing, /sys/class/power_supply/qcom-battmgr-usb/input_current_limit
> is stuck at zero and so is the current_now as a result (the voltage
> readout is 5V + some noise, so that looks good), but I don't see any
> SET paths for it in the driver, so I suppose that's what the firmware
> default is?
> 

I have not experimented with adjusting any configuration in this initial
set, but there are a few knobs that could/should be introduced on top of
this.

That said, I believe input_current_limit should somehow come from the
USB stack, rather than user space?

Regards,
Bjorn
  

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).

I have been experimenting with UCSI in the past, but my goal for this
series was to support external displays on my desktop (laptop...), but
through some experiments I've wired the connectors to dwc3 in order to
get usb_role_switch working. Neil has been looking at this in more
detail lately though.

Regards,
Bjorn
  

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
  

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 :)

Regards,
Bjorn

> Thanks for the explanation.
> 
> ---
> bod
>
  

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/
  

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

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
>