mbox series

[00/13] usb: typec: qcom-pmic-typec: enable support for PMI632 PMIC

Message ID 20240113-pmi632-typec-v1-0-de7dfd459353@linaro.org
Headers show
Series usb: typec: qcom-pmic-typec: enable support for PMI632 PMIC | expand

Message

Dmitry Baryshkov Jan. 13, 2024, 5:42 a.m. UTC
The Qualcomm PMI632 PMIC (found on Qualcomm Robotics RB2 platform)
doesn't support USB Power Delivery. However this PMIC still supports
handling of the Type-C port (orientation detection, etc). Reuse exiting
qcom-pmic-typec driver to support Type-C related functionality of this
PMIC. Use this to enable USB-C connector support on the RB2 platform.

Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
---
Dmitry Baryshkov (12):
      dt-bindings: regulator: qcom,usb-vbus-regulator: add support for PMI632
      dt-bindings: usb: qcom,pmic-typec: add support for the PMI632 block
      dt-bindings: phy: qcom,msm8998-qmp-usb3-phy: split from sc8280xp PHY schema
      dt-bindings: phy: qcom,msm8998-qmp-usb3-phy: support USB-C data
      usb: typec: qcom-pmic-typec: allow different implementations for the PD PHY
      usb: typec: qcom-pmic-typec: add support for PMI632 PMIC
      phy: qcom: qmp-usb: split USB-C PHY driver
      phy: qcom: qmp-usb: drop dual-lane handling
      phy: qcom: qmp-usbc: drop single lane handling
      phy: qcom: qmp-usbc: add support for the Type-C handling
      arm64: dts: qcom: pmi632: define USB-C related blocks
      arm64: dts: qcom: qrb4210-rb2: enable USB-C port handling

Vladimir Zapolskiy (1):
      arm64: dts: qcom: sm6115: drop pipe clock selection

 .../bindings/phy/qcom,msm8998-qmp-usb3-phy.yaml    |  171 +++
 .../phy/qcom,sc8280xp-qmp-usb3-uni-phy.yaml        |   22 -
 .../regulator/qcom,usb-vbus-regulator.yaml         |    9 +-
 .../devicetree/bindings/usb/qcom,pmic-typec.yaml   |   28 +-
 arch/arm64/boot/dts/qcom/pmi632.dtsi               |   29 +
 arch/arm64/boot/dts/qcom/qrb4210-rb2.dts           |   60 +-
 arch/arm64/boot/dts/qcom/sm6115.dtsi               |   39 +-
 drivers/phy/qualcomm/Makefile                      |    2 +-
 drivers/phy/qualcomm/phy-qcom-qmp-usb.c            |  323 +-----
 drivers/phy/qualcomm/phy-qcom-qmp-usbc.c           | 1202 ++++++++++++++++++++
 drivers/usb/typec/tcpm/qcom/Makefile               |    3 +-
 drivers/usb/typec/tcpm/qcom/qcom_pmic_typec.c      |  126 +-
 drivers/usb/typec/tcpm/qcom/qcom_pmic_typec.h      |   25 +
 .../usb/typec/tcpm/qcom/qcom_pmic_typec_pdphy.c    |  155 ++-
 .../usb/typec/tcpm/qcom/qcom_pmic_typec_pdphy.h    |   92 +-
 .../typec/tcpm/qcom/qcom_pmic_typec_pdphy_stub.c   |   67 ++
 drivers/usb/typec/tcpm/qcom/qcom_pmic_typec_port.h |    4 +-
 17 files changed, 1805 insertions(+), 552 deletions(-)
---
base-commit: 9e21984d62c56a0f6d1fc6f76b646212cfd7fe88
change-id: 20240112-pmi632-typec-4c7533092387

Best regards,

Comments

Konrad Dybcio Jan. 13, 2024, 10:46 a.m. UTC | #1
On 13.01.2024 06:42, Dmitry Baryshkov wrote:
> Now as all dual-lane PHYs have been migrated to a new driver, drop
> support for dual lanes configuration. If the PHY uses two lanes for USB,
> it is symthom that it should use either a combo USB+DP or a USB-C PHY
> driver.
> 
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> ---

[...]

> -	if (cfg->lanes >= 2) {
> -		qmp->tx2 = devm_of_iomap(dev, np, 3, NULL);
> -		if (IS_ERR(qmp->tx2))
> -			return PTR_ERR(qmp->tx2);
> -
> -		qmp->rx2 = devm_of_iomap(dev, np, 4, NULL);
> -		if (IS_ERR(qmp->rx2))
> -			return PTR_ERR(qmp->rx2);
> -
> -		qmp->pcs_misc = devm_of_iomap(dev, np, 5, NULL);
> -	} else {
> -		qmp->pcs_misc = devm_of_iomap(dev, np, 3, NULL);
> -	}
> +	qmp->pcs_misc = devm_of_iomap(dev, np, 3, NULL);
>  
>  	if (IS_ERR(qmp->pcs_misc)) {
Since you may need a new revision, you can remove the neline
above to get a nice

ret = ...
if (ret)
	...

equivalent while at it

Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>

Konrad
Konrad Dybcio Jan. 13, 2024, 10:48 a.m. UTC | #2
On 13.01.2024 06:42, Dmitry Baryshkov wrote:
> The USB-C PHYs on the msm8998, QCM2290 and SM6115 platforms use special
> register to control which lanes of the Type-C port are used for the
> SuperSpeed USB connection. Mimic the qmp-combo driver and handle this
> register.
> 
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> ---

[...]

> +#if IS_ENABLED(CONFIG_TYPEC)

I understand some people may want their USB to work without TC compiled
in, but it looks funky to have a "USB-C PHY" with optional USB-C support..

Should we just depend on it in kconfig?

Konrad
Dmitry Baryshkov Jan. 13, 2024, 2:20 p.m. UTC | #3
On Sat, 13 Jan 2024 at 12:52, Konrad Dybcio <konrad.dybcio@linaro.org> wrote:
>
> On 13.01.2024 06:42, Dmitry Baryshkov wrote:
> > Plug in USB-C related bits and pieces to enable USB role switching and
> > USB-C orientation handling for the Qualcomm RB2 board.
> >
> > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> > ---
> >  arch/arm64/boot/dts/qcom/qrb4210-rb2.dts | 62 ++++++++++++++++++++++++++++++++
> >  arch/arm64/boot/dts/qcom/sm6115.dtsi     | 38 ++++++++++++++++++++
> >  2 files changed, 100 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/qcom/qrb4210-rb2.dts b/arch/arm64/boot/dts/qcom/qrb4210-rb2.dts
> > index 52f31f3166c2..a96e3afb65bc 100644
> > --- a/arch/arm64/boot/dts/qcom/qrb4210-rb2.dts
> > +++ b/arch/arm64/boot/dts/qcom/qrb4210-rb2.dts
> > @@ -6,8 +6,10 @@
> >  /dts-v1/;
> >
> >  #include <dt-bindings/leds/common.h>
> > +#include <dt-bindings/usb/pd.h>
> >  #include "sm4250.dtsi"
> >  #include "pm6125.dtsi"
> > +#include "pmi632.dtsi"
> >
> >  / {
> >       model = "Qualcomm Technologies, Inc. QRB4210 RB2";
> > @@ -256,6 +258,53 @@ kypd_vol_up_n: kypd-vol-up-n-state {
> >       };
> >  };
> >
> > +&pmi632_typec {
> > +     status = "okay";
> > +
> > +     connector {
> > +             compatible = "usb-c-connector";
> > +
> > +             power-role = "dual";
> > +             data-role = "dual";
> > +             self-powered;
> > +
> > +             source-pdos = <PDO_FIXED(5000, 3000,
> > +                                      PDO_FIXED_DUAL_ROLE |
> > +                                      PDO_FIXED_USB_COMM |
> > +                                      PDO_FIXED_DATA_SWAP)>;
> > +             sink-pdos = <PDO_FIXED(5000, 500,
> > +                                      PDO_FIXED_DUAL_ROLE |
> > +                                      PDO_FIXED_USB_COMM |
> > +                                      PDO_FIXED_DATA_SWAP)>;
> > +             op-sink-microwatt = <10000000>;
> So RB2 can provide 15 watts over the USB-C port, consume 2.5 but
> requires 10? That doesn't make a whole lot of sense..
>
> Unless I'm reading this wrong..

Let me double-check the properties and the docs before answering.

>
> > +&usb_dwc3 {
> > +     usb-role-switch;
>
> Since this is a dual-role controller, I think this could live in the SoC

Sure. Should we update other boards too?

> DT
>
> > +};
> > +
> > +&usb_dwc3_hs {
> > +     remote-endpoint = <&pmi632_hs_in>;
> > +};
> > +
> >  &usb_hsphy {
> >       vdd-supply = <&vreg_l4a_0p9>;
> >       vdda-pll-supply = <&vreg_l12a_1p8>;
> > @@ -618,10 +675,15 @@ &usb_hsphy {
> >  &usb_qmpphy {
> >       vdda-phy-supply = <&vreg_l4a_0p9>;
> >       vdda-pll-supply = <&vreg_l12a_1p8>;
> > +     orientation-switch;
>
> Similarly, if this doesn't kaboom w/ our implementation too much, the
> PHY itself has orientation detection capabilities
>
> Konrad
Konrad Dybcio Jan. 13, 2024, 2:48 p.m. UTC | #4
On 13.01.2024 15:15, Dmitry Baryshkov wrote:
> On Sat, 13 Jan 2024 at 12:42, Konrad Dybcio <konrad.dybcio@linaro.org> wrote:
>>
>> On 13.01.2024 06:42, Dmitry Baryshkov wrote:
>>> In preparation to adding Type-C handling for MSM8998, QCM2290 and SM6115
>>> platforms, create new QMP USB-C PHY driver by splitting mentioned
>>> platforms to a separate file. In future it will also be extended with
>>> support for the DisplayPort handling. It will also be reused later for
>>> such platforms as SDM660, SM6125, SM6150.
>>>
>>> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
>>> ---
>>
>> [...]
>>
>>
>>> +#include "phy-qcom-qmp.h"
>>> +#include "phy-qcom-qmp-pcs-misc-v3.h"
>>> +
>>> +/* QPHY_SW_RESET bit */
>>> +#define SW_RESET                             BIT(0)
>>> +/* QPHY_POWER_DOWN_CONTROL */
>>> +#define SW_PWRDN                             BIT(0)
>>
>> Most / all of these defines could probably live in a header file.
> 
> For this (and several other comments), see
> https://lore.kernel.org/linux-arm-msm/20240109-phy-qmp-merge-common-v1-0-572899a14318@linaro.org/

So, I'd assume the plan is to land these two series in parallel and
then submit a cleanup to this one? Sounds ok then!

Konrad