Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20221130081430.67831-1-luca.weiss@fairphone.com>
 <20221130081430.67831-2-luca.weiss@fairphone.com> <Y6xP4YRAp68TfxFi@hovoldconsulting.com>
 <Y8BIX+js1ircJyb9@matsya> <cf968a25-02f7-d402-530b-eb379b707e54@linaro.org> <CPR2LS3SJQ3I.Z7UY505COG3@otso>
In-Reply-To: <CPR2LS3SJQ3I.Z7UY505COG3@otso>
From:   Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date:   Fri, 13 Jan 2023 15:01:41 +0200
Message-ID: <CAA8EJpoOMMALHz7ysft6KvQaYhGWPD+xZiUjOTrC8CA_y81n-w@mail.gmail.com>
Subject: Re: [PATCH v3 2/3] phy: qcom-qmp-combo: Add config for SM6350
To:     Luca Weiss <luca.weiss@fairphone.com>
Cc:     Vinod Koul <vkoul@kernel.org>, Johan Hovold <johan@kernel.org>,
        linux-arm-msm@vger.kernel.org,
        ~postmarketos/upstreaming@lists.sr.ht, phone-devel@vger.kernel.org,
        Andy Gross <agross@kernel.org>,
        Bjorn Andersson <andersson@kernel.org>,
        Konrad Dybcio <konrad.dybcio@linaro.org>,
        Kishon Vijay Abraham I <kishon@kernel.org>,
        linux-phy@lists.infradead.org, linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Fri, 13 Jan 2023 at 14:44, Luca Weiss <luca.weiss@fairphone.com> wrote:
>
> Hi Dmitry,
>
> On Thu Jan 12, 2023 at 8:33 PM CET, Dmitry Baryshkov wrote:
> > On 12/01/2023 19:50, Vinod Koul wrote:
> > > On 28-12-22, 15:17, Johan Hovold wrote:
> > >> Luca, Vinod,
> > >>
> > >> On Wed, Nov 30, 2022 at 09:14:28AM +0100, Luca Weiss wrote:
> > >>> Add the tables and config for the combo phy found on SM6350.
> > >>>
> > >>> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
> > >>> ---
> > >>> Changes since v2:
> > >>> * Drop dp_txa/dp_txb changes, not required
> > >>> * Fix dp_dp_phy offset
> > >>>
> > >>>   drivers/phy/qualcomm/phy-qcom-qmp-combo.c | 126 ++++++++++++++++++++++
> > >>>   1 file changed, 126 insertions(+)
> > >>>
> > >>> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-combo.c b/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
> > >>> index 77052c66cf70..6ac0c68269dc 100644
> > >>> --- a/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
> > >>> +++ b/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
> > >>
> > >>> @@ -975,6 +1039,19 @@ static const char * const sc7180_usb3phy_reset_l[] = {
> > >>>           "phy",
> > >>>   };
> > >>>
> > >>> +static const struct qmp_combo_offsets qmp_combo_offsets_v3 = {
> > >>> + .com            = 0x0000,
> > >>> + .txa            = 0x1200,
> > >>> + .rxa            = 0x1400,
> > >>> + .txb            = 0x1600,
> > >>> + .rxb            = 0x1800,
> > >>> + .usb3_serdes    = 0x1000,
> > >>> + .usb3_pcs_misc  = 0x1a00,
> > >>> + .usb3_pcs       = 0x1c00,
> > >>> + .dp_serdes      = 0x1000,
> > >>
> > >> I would have expected this to be 0x2000 as that's what the older
> > >> platforms have been using for the dp serdes table so far. Without access
> > >> to any documentation it's hard to tell whether everyone's just been
> > >> cargo-culting all along or if there's actually something there at offset
> > >> 0x2000.
> >
> > usb3_serdes is 0x1000, so dp_serdes equal to 0x1000 is definitely an typo.
> >
> > Judging from the downstream dtsi, the DP PHY starts at offset 0x2000. So
> > dp_serdes is equal to 0x2000, dp_phy = 0x2a00, ln_tx1 = 0x2200, ln_tx2 =
> > 0x2600.
>
> Can you share how you got to the 0x2000 offset? You can see my
> (potentially wrong) reasoning for 0x1000 a few messages ago[0].
>
> The only 0x2000-something I could find now while looking at it again is
> "#define USB3_DP_PHY_DP_DP_PHY_PD_CTL 0x2a18" which becomes
> USB3_DP_DP_PHY_PD_CTL in the driver but this is seemingly not used at
> all in my msm-4.19 tree.

Quite simple: see [1]. DP_PLL is at +0x2000

[1] https://android.googlesource.com/kernel/msm-extra/devicetree/+/refs/heads/android-msm-bramble-4.19-android11-qpr1/qcom/lagoon-sde-pll.dtsi#27

Anyway, having DP serdes at the space as USB3 serdes would mean that
one would be setting USB3 PLL when trying to enable DP. So I could
have said even w/o looking at the dtsi that dp serdes can _not_ be at
0x1000.

>
> Also if you have any idea on how to test it at runtime without actually
> having to get all the type-C functionality up I'd be happy to try that.
> Unfortunately I believe there's still quite some bits missing to
> actually get DP out via the USB-C port - which I imagine would trigger
> the PHY setup.

Unfortunately, I don't have a recipe to test this.

>
> [0] https://lore.kernel.org/linux-arm-msm/CPDIYQ3SSY3E.I0Y0NMIED0WO@otso/
>
> Regards
> Luca


-- 
With best wishes
Dmitry