| Message ID | 20230203081807.2248625-1-abel.vesa@linaro.org |
|---|---|
| Headers | show |
| Series | sm8550: Add PCIe HC and PHY support | expand |
On Fri, Feb 03, 2023 at 10:18:03AM +0200, Abel Vesa wrote: > Add the SM8550 both g4 and g3 configurations. In addition, there is a > new "lane shared" table that needs to be configured for g4, along with > the No-CSR list of resets. Could you add a comment about the new nocsr reset and how it is used here? > Co-developed-by: Neil Armstrong <neil.armstrong@linaro.org> > Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> > Signed-off-by: Abel Vesa <abel.vesa@linaro.org> > Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> > --- > > This patchset relies on the following patchset: > https://lore.kernel.org/all/20230117224148.1914627-1-abel.vesa@linaro.org/ > > The v6 of this patch is: > https://lore.kernel.org/all/20230202123902.3831491-9-abel.vesa@linaro.org/ > > Changes since v6: > * none > > Changes since v5: > * renmaed the no-CSR reset to "phy_nocsr" as discussed off-list with > Bjorn and Johan > > Changes since v4: > * dropped _serdes infix from ln_shrd table name and from every ln_shrd > variable name > * added hyphen between "no CSR" in both places > * dropped has_ln_shrd_serdes_tbl > * reordered qmp_pcie_offsets_v6_20 by struct members > * added rollback for no-CSR reset in qmp_pcie_init fail path > * moved ln_shrd offset calculation after port_b > > Changes since v3: > * added Dmitry's R-b tag > > Changes since v2: > * none > > Changes since v1: > * split all the offsets into separate patches, like Vinod suggested > > > drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 367 ++++++++++++++++++++++- > 1 file changed, 365 insertions(+), 2 deletions(-) > > diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c > index 907f3f236f05..ff6c0b526fde 100644 > --- a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c > +++ b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c > @@ -1506,6 +1506,234 @@ static const struct qmp_phy_init_tbl sm8450_qmp_gen4x2_pcie_ep_pcs_misc_tbl[] = > QMP_PHY_INIT_CFG(QPHY_V5_20_PCS_PCIE_OSC_DTCT_MODE2_CONFIG5, 0x08), > }; > > +static const struct qmp_phy_init_tbl sm8550_qmp_gen3x2_pcie_serdes_tbl[] = { > + QMP_PHY_INIT_CFG(QSERDES_V6_COM_SSC_EN_CENTER, 0x01), > + QMP_PHY_INIT_CFG(QSERDES_V6_COM_SSC_PER1, 0x62), > + QMP_PHY_INIT_CFG(QSERDES_V6_COM_SSC_PER2, 0x02), > + QMP_PHY_INIT_CFG(QSERDES_V6_COM_SSC_STEP_SIZE1_MODE0, 0xf8), > + QMP_PHY_INIT_CFG(QSERDES_V6_COM_SSC_STEP_SIZE2_MODE0, 0x01), > + QMP_PHY_INIT_CFG(QSERDES_V6_COM_SSC_STEP_SIZE1_MODE1, 0x93), > + QMP_PHY_INIT_CFG(QSERDES_V6_COM_SSC_STEP_SIZE2_MODE1, 0x01), > + QMP_PHY_INIT_CFG(QSERDES_V6_COM_CLK_ENABLE1, 0x90), > + QMP_PHY_INIT_CFG(QSERDES_V6_COM_SYS_CLK_CTRL, 0x82), > + QMP_PHY_INIT_CFG(QSERDES_V6_COM_PLL_IVCO, 0x07), > + QMP_PHY_INIT_CFG(QSERDES_V6_COM_CP_CTRL_MODE0, 0x02), > + QMP_PHY_INIT_CFG(QSERDES_V6_COM_CP_CTRL_MODE1, 0x02), > + QMP_PHY_INIT_CFG(QSERDES_V6_COM_PLL_RCTRL_MODE0, 0x16), > + QMP_PHY_INIT_CFG(QSERDES_V6_COM_PLL_RCTRL_MODE1, 0x16), > + QMP_PHY_INIT_CFG(QSERDES_V6_COM_PLL_CCTRL_MODE0, 0x36), > + QMP_PHY_INIT_CFG(QSERDES_V6_COM_PLL_CCTRL_MODE1, 0x36), > + QMP_PHY_INIT_CFG(QSERDES_V6_COM_SYSCLK_EN_SEL, 0x08), > + QMP_PHY_INIT_CFG(QSERDES_V6_COM_BG_TIMER, 0x0a), > + QMP_PHY_INIT_CFG(QSERDES_V6_COM_LOCK_CMP_EN, 0x42), > + QMP_PHY_INIT_CFG(QSERDES_V6_COM_LOCK_CMP1_MODE0, 0x04), > + QMP_PHY_INIT_CFG(QSERDES_V6_COM_LOCK_CMP2_MODE0, 0x0d), > + QMP_PHY_INIT_CFG(QSERDES_V6_COM_LOCK_CMP1_MODE1, 0x0a), > + QMP_PHY_INIT_CFG(QSERDES_V6_COM_LOCK_CMP2_MODE1, 0x1a), > + QMP_PHY_INIT_CFG(QSERDES_V6_COM_DEC_START_MODE0, 0x41), > + QMP_PHY_INIT_CFG(QSERDES_V6_COM_DEC_START_MODE1, 0x34), > + QMP_PHY_INIT_CFG(QSERDES_V6_COM_DIV_FRAC_START1_MODE0, 0xab), > + QMP_PHY_INIT_CFG(QSERDES_V6_COM_DIV_FRAC_START2_MODE0, 0xaa), > + QMP_PHY_INIT_CFG(QSERDES_V6_COM_DIV_FRAC_START3_MODE0, 0x01), > + QMP_PHY_INIT_CFG(QSERDES_V6_COM_DIV_FRAC_START1_MODE1, 0x55), > + QMP_PHY_INIT_CFG(QSERDES_V6_COM_DIV_FRAC_START2_MODE1, 0x55), > + QMP_PHY_INIT_CFG(QSERDES_V6_COM_DIV_FRAC_START3_MODE1, 0x01), > + QMP_PHY_INIT_CFG(QSERDES_V6_COM_VCO_TUNE_MAP, 0x14), > + QMP_PHY_INIT_CFG(QSERDES_V6_COM_CLK_SELECT, 0x34), > + QMP_PHY_INIT_CFG(QSERDES_V6_COM_HSCLK_SEL_1, 0x01), > + QMP_PHY_INIT_CFG(QSERDES_V6_COM_CORECLK_DIV_MODE1, 0x04), > + QMP_PHY_INIT_CFG(QSERDES_V6_COM_CMN_CONFIG_1, 0x16), > + QMP_PHY_INIT_CFG(QSERDES_V6_COM_ADDITIONAL_MISC_3, 0x0f), > + QMP_PHY_INIT_CFG(QSERDES_V6_COM_CORE_CLK_EN, 0xa0), > +}; [...] > struct qmp_pcie_offsets { > u16 serdes; > u16 pcs; > @@ -1514,11 +1742,14 @@ struct qmp_pcie_offsets { > u16 rx; > u16 tx2; > u16 rx2; > + u16 ln_shrd; > }; > > struct qmp_phy_cfg_tbls { > const struct qmp_phy_init_tbl *serdes; > int serdes_num; > + const struct qmp_phy_init_tbl *ln_shrd; > + int ln_shrd_num; Perhaps move after rx2 to reflect the 6.20 offsets. > const struct qmp_phy_init_tbl *tx; > int tx_num; > const struct qmp_phy_init_tbl *rx; > @@ -1556,6 +1787,9 @@ struct qmp_phy_cfg { > /* resets to be requested */ > const char * const *reset_list; > int num_resets; > + /* no-CSR resets to be requested */ > + const char * const *nocsr_reset_list; > + int num_nocsr_resets; > /* regulators to be requested */ > const char * const *vreg_list; > int num_vregs; > @@ -1580,6 +1814,7 @@ struct qmp_pcie { > bool tcsr_4ln_config; > > void __iomem *serdes; > + void __iomem *ln_shrd; Perhaps move after rx2 to reflect the 6.20 offsets. > void __iomem *pcs; > void __iomem *pcs_misc; > void __iomem *tx; > @@ -1594,6 +1829,7 @@ struct qmp_pcie { > int num_pipe_clks; > > struct reset_control_bulk_data *resets; > + struct reset_control_bulk_data *nocsr_resets; > struct regulator_bulk_data *vregs; > > struct phy *phy; > @@ -1648,6 +1884,10 @@ static const char * const qmp_phy_vreg_l[] = { > "vdda-phy", "vdda-pll", > }; > > +static const char * const sm8550_qmp_phy_vreg_l[] = { > + "vdda-phy", "vdda-pll", "vdda-qref", > +}; > + > /* list of resets */ > static const char * const ipq8074_pciephy_reset_l[] = { > "phy", "common", > @@ -1657,6 +1897,10 @@ static const char * const sdm845_pciephy_reset_l[] = { > "phy", > }; > > +static const char * const sm8550_pciephy_nocsr_reset_l[] = { > + "phy_nocsr", > +}; > + > static const struct qmp_pcie_offsets qmp_pcie_offsets_v5 = { > .serdes = 0, > .pcs = 0x0200, > @@ -1667,6 +1911,17 @@ static const struct qmp_pcie_offsets qmp_pcie_offsets_v5 = { > .rx2 = 0x1800, > }; > > +static const struct qmp_pcie_offsets qmp_pcie_offsets_v6_20 = { > + .serdes = 0x1000, > + .pcs = 0x1200, > + .pcs_misc = 0x1400, > + .tx = 0x0, nit: Maybe pad this one to four digits too now. > + .rx = 0x0200, > + .tx2 = 0x0800, > + .rx2 = 0x0a00, > + .ln_shrd = 0x0e00, > +}; > + > static const struct qmp_phy_cfg ipq8074_pciephy_cfg = { > .lanes = 1, > > @@ -2214,6 +2469,68 @@ static const struct qmp_phy_cfg sm8450_qmp_gen4x2_pciephy_cfg = { > .phy_status = PHYSTATUS_4_20, > }; > > +static const struct qmp_phy_cfg sm8550_qmp_gen3x2_pciephy_cfg = { > + .lanes = 2, > + > + .offsets = &qmp_pcie_offsets_v5, Did you really intend to use the v5 offsets here? It seems you use v6.20 defines in the tables below. This may work but it looks a little strange and does not match how we name and use these resources for the other SoCs (e.g. reusing structures and defines from older IP revisions is fine, but not necessarily the other way round). I assume this means that the gen3 PHY is really is really v5 and using a subset of the v6.20 defines happens to works as they are in fact identical with respect to that subset? As you have dedicated gen3x2 tables, perhaps those should use the v5 defines? And at least add a comment about this in the commit message. > + > + .tbls = { > + .serdes = sm8550_qmp_gen3x2_pcie_serdes_tbl, > + .serdes_num = ARRAY_SIZE(sm8550_qmp_gen3x2_pcie_serdes_tbl), > + .tx = sm8550_qmp_gen3x2_pcie_tx_tbl, > + .tx_num = ARRAY_SIZE(sm8550_qmp_gen3x2_pcie_tx_tbl), > + .rx = sm8550_qmp_gen3x2_pcie_rx_tbl, > + .rx_num = ARRAY_SIZE(sm8550_qmp_gen3x2_pcie_rx_tbl), > + .pcs = sm8550_qmp_gen3x2_pcie_pcs_tbl, > + .pcs_num = ARRAY_SIZE(sm8550_qmp_gen3x2_pcie_pcs_tbl), > + .pcs_misc = sm8550_qmp_gen3x2_pcie_pcs_misc_tbl, > + .pcs_misc_num = ARRAY_SIZE(sm8550_qmp_gen3x2_pcie_pcs_misc_tbl), > + }, > + .clk_list = sc8280xp_pciephy_clk_l, > + .num_clks = ARRAY_SIZE(sc8280xp_pciephy_clk_l), > + .reset_list = sdm845_pciephy_reset_l, > + .num_resets = ARRAY_SIZE(sdm845_pciephy_reset_l), > + .vreg_list = qmp_phy_vreg_l, > + .num_vregs = ARRAY_SIZE(qmp_phy_vreg_l), > + .regs = pciephy_v5_regs_layout, > + > + .pwrdn_ctrl = SW_PWRDN | REFCLK_DRV_DSBL, > + .phy_status = PHYSTATUS, > +}; > + > +static const struct qmp_phy_cfg sm8550_qmp_gen4x2_pciephy_cfg = { > + .lanes = 2, > + > + .offsets = &qmp_pcie_offsets_v6_20, > + > + .tbls = { > + .serdes = sm8550_qmp_gen4x2_pcie_serdes_tbl, > + .serdes_num = ARRAY_SIZE(sm8550_qmp_gen4x2_pcie_serdes_tbl), > + .ln_shrd = sm8550_qmp_gen4x2_pcie_ln_shrd_tbl, > + .ln_shrd_num = ARRAY_SIZE(sm8550_qmp_gen4x2_pcie_ln_shrd_tbl), > + .tx = sm8550_qmp_gen4x2_pcie_tx_tbl, > + .tx_num = ARRAY_SIZE(sm8550_qmp_gen4x2_pcie_tx_tbl), > + .rx = sm8550_qmp_gen4x2_pcie_rx_tbl, > + .rx_num = ARRAY_SIZE(sm8550_qmp_gen4x2_pcie_rx_tbl), > + .pcs = sm8550_qmp_gen4x2_pcie_pcs_tbl, > + .pcs_num = ARRAY_SIZE(sm8550_qmp_gen4x2_pcie_pcs_tbl), > + .pcs_misc = sm8550_qmp_gen4x2_pcie_pcs_misc_tbl, > + .pcs_misc_num = ARRAY_SIZE(sm8550_qmp_gen4x2_pcie_pcs_misc_tbl), > + }, > + .clk_list = sc8280xp_pciephy_clk_l, > + .num_clks = ARRAY_SIZE(sc8280xp_pciephy_clk_l), > + .reset_list = sdm845_pciephy_reset_l, > + .num_resets = ARRAY_SIZE(sdm845_pciephy_reset_l), > + .nocsr_reset_list = sm8550_pciephy_nocsr_reset_l, > + .num_nocsr_resets = ARRAY_SIZE(sm8550_pciephy_nocsr_reset_l), > + .vreg_list = sm8550_qmp_phy_vreg_l, > + .num_vregs = ARRAY_SIZE(sm8550_qmp_phy_vreg_l), > + .regs = pciephy_v5_regs_layout, > + > + .pwrdn_ctrl = SW_PWRDN | REFCLK_DRV_DSBL, > + .phy_status = PHYSTATUS_4_20, > +}; > + > static void qmp_pcie_configure_lane(void __iomem *base, > const struct qmp_phy_init_tbl tbl[], > int num, > @@ -2262,6 +2579,7 @@ static void qmp_pcie_init_registers(struct qmp_pcie *qmp, const struct qmp_phy_c > { > const struct qmp_phy_cfg *cfg = qmp->cfg; > void __iomem *serdes = qmp->serdes; > + void __iomem *ln_shrd = qmp->ln_shrd; Move last here (after pcs_misc)? > void __iomem *tx = qmp->tx; > void __iomem *rx = qmp->rx; > void __iomem *tx2 = qmp->tx2; > @@ -2289,6 +2607,8 @@ static void qmp_pcie_init_registers(struct qmp_pcie *qmp, const struct qmp_phy_c > qmp_pcie_configure(serdes, cfg->serdes_4ln_tbl, cfg->serdes_4ln_num); > qmp_pcie_init_port_b(qmp, tbls); > } > + > + qmp_pcie_configure(ln_shrd, tbls->ln_shrd, tbls->ln_shrd_num); > } > > static int qmp_pcie_init(struct phy *phy) > @@ -2309,20 +2629,31 @@ static int qmp_pcie_init(struct phy *phy) > goto err_disable_regulators; > } > > + if (qmp->nocsr_resets) { > + ret = reset_control_bulk_assert(cfg->num_nocsr_resets, qmp->nocsr_resets); > + if (ret) { > + dev_err(qmp->dev, "no-csr reset assert failed\n"); > + goto err_assert_reset; > + } > + } > + > usleep_range(200, 300); > > ret = reset_control_bulk_deassert(cfg->num_resets, qmp->resets); > if (ret) { > dev_err(qmp->dev, "reset deassert failed\n"); > - goto err_disable_regulators; > + goto err_assert_nocsr_reset; > } > > ret = clk_bulk_prepare_enable(cfg->num_clks, qmp->clks); > if (ret) > - goto err_assert_reset; > + goto err_assert_nocsr_reset; > > return 0; > > +err_assert_nocsr_reset: > + if (qmp->nocsr_resets) > + reset_control_bulk_assert(cfg->num_resets, qmp->resets); > err_assert_reset: > reset_control_bulk_assert(cfg->num_resets, qmp->resets); > err_disable_regulators: > @@ -2370,6 +2701,14 @@ static int qmp_pcie_power_on(struct phy *phy) > if (ret) > return ret; > > + if (qmp->nocsr_resets) { > + ret = reset_control_bulk_deassert(cfg->num_nocsr_resets, qmp->nocsr_resets); > + if (ret) { > + dev_err(qmp->dev, "no-csr reset deassert failed\n"); > + goto err_disable_pipe_clk; > + } > + } > + > /* Pull PHY out of reset state */ > qphy_clrbits(pcs, cfg->regs[QPHY_SW_RESET], SW_RESET); > > @@ -2503,6 +2842,21 @@ static int qmp_pcie_reset_init(struct qmp_pcie *qmp) > if (ret) > return dev_err_probe(dev, ret, "failed to get resets\n"); > > + if (cfg->nocsr_reset_list) { > + qmp->nocsr_resets = devm_kcalloc(dev, cfg->num_nocsr_resets, > + sizeof(*qmp->nocsr_resets), GFP_KERNEL); > + if (!qmp->nocsr_resets) > + return -ENOMEM; > + > + for (i = 0; i < cfg->num_nocsr_resets; i++) > + qmp->nocsr_resets[i].id = cfg->nocsr_reset_list[i]; > + > + ret = devm_reset_control_bulk_get_exclusive(dev, cfg->num_nocsr_resets, > + qmp->nocsr_resets); > + if (ret) > + return dev_err_probe(dev, ret, "failed to get no-CSR resets\n"); nit: you now use lower case 'no-csr' everywhere else. Using the bulk API for this when we don't currently expect there to ever be more than one nocsr reset seems like overkill, and also as the nocsr reset is special and is managed differently during the power on sequence. If so this could just be a flag in the gen4 PHY config and the "phy_nocsr" name could be hard coded here. On the other hand, the bulk API allows for treating resets as optional, but you don't currently use that above (e.g. by calling bulk_assert unconditionally). > + } > + > return 0; > } Johan
On Fri, Feb 03, 2023 at 10:18:05AM +0200, Abel Vesa wrote: > Add compatible for both PCIe found on SM8550. > Also add the cnoc_pcie_sf_axi clock needed by the SM8550. nit: You're now also adding 'noc_aggr' > Signed-off-by: Abel Vesa <abel.vesa@linaro.org> > Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> > Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> > --- > > The v6 of this patchset is: > https://lore.kernel.org/all/20230202123902.3831491-11-abel.vesa@linaro.org/ > > Changes since v6: > * none > > Changes since v5: > * none > > Changes since v4: > * added Mani's R-b tag > > Changes since v3: > * renamed cnoc_pcie_sf_axi to cnoc_sf_axi > > Changes since v2: > * none > > Changes since v1: > * changed the subject line prefix for the patch to match the history, > like Bjorn Helgaas suggested. > * added Konrad's R-b tag > > drivers/pci/controller/dwc/pcie-qcom.c | 25 ++++++++++++++----------- > 1 file changed, 14 insertions(+), 11 deletions(-) > > diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controller/dwc/pcie-qcom.c > index a232b04af048..6a70c9c6f98d 100644 > --- a/drivers/pci/controller/dwc/pcie-qcom.c > +++ b/drivers/pci/controller/dwc/pcie-qcom.c > @@ -182,10 +182,10 @@ struct qcom_pcie_resources_2_3_3 { > > /* 6 clocks typically, 7 for sm8250 */ > struct qcom_pcie_resources_2_7_0 { > - struct clk_bulk_data clks[12]; > + struct clk_bulk_data clks[14]; > int num_clks; > struct regulator_bulk_data supplies[2]; > - struct reset_control *pci_reset; > + struct reset_control *rst; Please name this one 'reset' or 'resets' (e.g. to avoid hard to parse things like res->rst below). > }; > > struct qcom_pcie_resources_2_9_0 { > @@ -1177,9 +1177,9 @@ static int qcom_pcie_get_resources_2_7_0(struct qcom_pcie *pcie) > unsigned int idx; > int ret; > > - res->pci_reset = devm_reset_control_get_exclusive(dev, "pci"); > - if (IS_ERR(res->pci_reset)) > - return PTR_ERR(res->pci_reset); > + res->rst = devm_reset_control_array_get_exclusive(dev); > + if (IS_ERR(res->rst)) > + return PTR_ERR(res->rst); So the reset array implementation apparently both asserts and deasserts the resets in the order specified in DT (i.e. does not deassert in reverse order). Is that ok also for the new "pci" and "link_down" resets? > res->supplies[0].supply = "vdda"; > res->supplies[1].supply = "vddpe-3v3"; > @@ -1205,9 +1205,11 @@ static int qcom_pcie_get_resources_2_7_0(struct qcom_pcie *pcie) > res->clks[idx++].id = "ddrss_sf_tbu"; > res->clks[idx++].id = "aggre0"; > res->clks[idx++].id = "aggre1"; > + res->clks[idx++].id = "noc_aggr"; > res->clks[idx++].id = "noc_aggr_4"; > res->clks[idx++].id = "noc_aggr_south_sf"; > res->clks[idx++].id = "cnoc_qx"; > + res->clks[idx++].id = "cnoc_sf_axi"; > > num_opt_clks = idx - num_clks; > res->num_clks = idx; > @@ -1237,17 +1239,17 @@ static int qcom_pcie_init_2_7_0(struct qcom_pcie *pcie) > if (ret < 0) > goto err_disable_regulators; > > - ret = reset_control_assert(res->pci_reset); > - if (ret < 0) { > - dev_err(dev, "cannot assert pci reset\n"); > + ret = reset_control_assert(res->rst); > + if (ret) { > + dev_err(dev, "reset assert failed (%d)\n", ret); > goto err_disable_clocks; > } > > usleep_range(1000, 1500); > > - ret = reset_control_deassert(res->pci_reset); > - if (ret < 0) { > - dev_err(dev, "cannot deassert pci reset\n"); > + ret = reset_control_deassert(res->rst); > + if (ret) { > + dev_err(dev, "reset deassert failed (%d)\n", ret); > goto err_disable_clocks; > } Johan
On Fri, Feb 03, 2023 at 10:18:06AM +0200, Abel Vesa wrote: > Add PCIe controllers and PHY nodes. > > Signed-off-by: Abel Vesa <abel.vesa@linaro.org> Looks good to me know: Reviewed-by: Johan Hovold <johan+linaro@kernel.org>
On Fri, Feb 03, 2023 at 10:18:07AM +0200, Abel Vesa wrote: > Enable PCIe controllers and PHYs nodes on SM8550 MTP board. > > Co-developed-by: Neil Armstrong <neil.armstrong@linaro.org> > Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> > Signed-off-by: Abel Vesa <abel.vesa@linaro.org> > --- > +&pcie_1_phy_aux_clk { > + clock-frequency = <1000>; > +}; > + > +&pcie0 { > + wake-gpios = <&tlmm 96 GPIO_ACTIVE_HIGH>; > + perst-gpios = <&tlmm 94 GPIO_ACTIVE_LOW>; > + > + pinctrl-names = "default"; > + pinctrl-0 = <&pcie0_default_state>; > + > + status = "okay"; > +}; > + > +&pcie0_phy { > + vdda-phy-supply = <&vreg_l1e_0p88>; > + vdda-pll-supply = <&vreg_l3e_1p2>; Super nit: add newline for consistency. > + status = "okay"; > +}; > + > +&pcie1 { > + wake-gpios = <&tlmm 99 GPIO_ACTIVE_HIGH>; > + perst-gpios = <&tlmm 97 GPIO_ACTIVE_LOW>; Neither controller needs the new enable gpio? > + > + pinctrl-names = "default"; > + pinctrl-0 = <&pcie1_default_state>; > + > + status = "okay"; > +}; > + > +&pcie1_phy { > + vdda-phy-supply = <&vreg_l3c_0p91>; > + vdda-pll-supply = <&vreg_l3e_1p2>; > + vdda-qref-supply = <&vreg_l1e_0p88>; > + > + status = "okay"; > +}; > + > &pm8550_gpios { > sdc2_card_det_n: sdc2-card-det-state { > pins = "gpio12"; Johan
On 23-02-03 10:56:31, Johan Hovold wrote: > On Fri, Feb 03, 2023 at 10:18:07AM +0200, Abel Vesa wrote: > > Enable PCIe controllers and PHYs nodes on SM8550 MTP board. > > > > Co-developed-by: Neil Armstrong <neil.armstrong@linaro.org> > > Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> > > Signed-off-by: Abel Vesa <abel.vesa@linaro.org> > > --- > > > +&pcie_1_phy_aux_clk { > > + clock-frequency = <1000>; > > +}; > > + > > +&pcie0 { > > + wake-gpios = <&tlmm 96 GPIO_ACTIVE_HIGH>; > > + perst-gpios = <&tlmm 94 GPIO_ACTIVE_LOW>; > > + > > + pinctrl-names = "default"; > > + pinctrl-0 = <&pcie0_default_state>; > > + > > + status = "okay"; > > +}; > > + > > +&pcie0_phy { > > + vdda-phy-supply = <&vreg_l1e_0p88>; > > + vdda-pll-supply = <&vreg_l3e_1p2>; > > Super nit: add newline for consistency. > > > + status = "okay"; > > +}; > > + > > +&pcie1 { > > + wake-gpios = <&tlmm 99 GPIO_ACTIVE_HIGH>; > > + perst-gpios = <&tlmm 97 GPIO_ACTIVE_LOW>; > > Neither controller needs the new enable gpio? Nope, none of the controllers need it. > > > + > > + pinctrl-names = "default"; > > + pinctrl-0 = <&pcie1_default_state>; > > + > > + status = "okay"; > > +}; > > + > > +&pcie1_phy { > > + vdda-phy-supply = <&vreg_l3c_0p91>; > > + vdda-pll-supply = <&vreg_l3e_1p2>; > > + vdda-qref-supply = <&vreg_l1e_0p88>; > > + > > + status = "okay"; > > +}; > > + > > &pm8550_gpios { > > sdc2_card_det_n: sdc2-card-det-state { > > pins = "gpio12"; > > Johan
On 23-02-03 10:33:14, Johan Hovold wrote: > On Fri, Feb 03, 2023 at 10:18:03AM +0200, Abel Vesa wrote: > > Add the SM8550 both g4 and g3 configurations. In addition, there is a > > new "lane shared" table that needs to be configured for g4, along with > > the No-CSR list of resets. > > Could you add a comment about the new nocsr reset and how it is used > here? > > > Co-developed-by: Neil Armstrong <neil.armstrong@linaro.org> > > Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> > > Signed-off-by: Abel Vesa <abel.vesa@linaro.org> > > Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> > > --- > > > > This patchset relies on the following patchset: > > https://lore.kernel.org/all/20230117224148.1914627-1-abel.vesa@linaro.org/ > > > > The v6 of this patch is: > > https://lore.kernel.org/all/20230202123902.3831491-9-abel.vesa@linaro.org/ > > > > Changes since v6: > > * none > > > > Changes since v5: > > * renmaed the no-CSR reset to "phy_nocsr" as discussed off-list with > > Bjorn and Johan > > > > Changes since v4: > > * dropped _serdes infix from ln_shrd table name and from every ln_shrd > > variable name > > * added hyphen between "no CSR" in both places > > * dropped has_ln_shrd_serdes_tbl > > * reordered qmp_pcie_offsets_v6_20 by struct members > > * added rollback for no-CSR reset in qmp_pcie_init fail path > > * moved ln_shrd offset calculation after port_b > > > > Changes since v3: > > * added Dmitry's R-b tag > > > > Changes since v2: > > * none > > > > Changes since v1: > > * split all the offsets into separate patches, like Vinod suggested > > > > > > drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 367 ++++++++++++++++++++++- > > 1 file changed, 365 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c > > index 907f3f236f05..ff6c0b526fde 100644 > > --- a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c > > +++ b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c > > @@ -1506,6 +1506,234 @@ static const struct qmp_phy_init_tbl sm8450_qmp_gen4x2_pcie_ep_pcs_misc_tbl[] = > > QMP_PHY_INIT_CFG(QPHY_V5_20_PCS_PCIE_OSC_DTCT_MODE2_CONFIG5, 0x08), > > }; > [...] > > > > > @@ -2214,6 +2469,68 @@ static const struct qmp_phy_cfg sm8450_qmp_gen4x2_pciephy_cfg = { > > .phy_status = PHYSTATUS_4_20, > > }; > > > > +static const struct qmp_phy_cfg sm8550_qmp_gen3x2_pciephy_cfg = { > > + .lanes = 2, > > + > > + .offsets = &qmp_pcie_offsets_v5, > > Did you really intend to use the v5 offsets here? It seems you use v6.20 > defines in the tables below. This may work but it looks a little strange > and does not match how we name and use these resources for the other > SoCs (e.g. reusing structures and defines from older IP revisions is > fine, but not necessarily the other way round). So here is what is happening here. The actual IP block version is 6 for the g3x2. The offsets of the tables are the same as on v5, but the actual offsets of some of the registers within those tables are entirely different. Now, if you compare the PCS PCIe offsets (v5 vs v6) you'll notice that all v6 registers currently added are the same as v5 (both names and values). With that in mind, we still need to keep the v6 offsets for the case when a new register, that might not be in v5, might be added later on. As for the table offsets, since they look the same we should probably not add a dedicated v6 one. > > I assume this means that the gen3 PHY is really is really v5 and using > a subset of the v6.20 defines happens to works as they are in fact > identical with respect to that subset? > > As you have dedicated gen3x2 tables, perhaps those should use the v5 > defines? > > And at least add a comment about this in the commit message. > > > + > > + .tbls = { > > + .serdes = sm8550_qmp_gen3x2_pcie_serdes_tbl, > > + .serdes_num = ARRAY_SIZE(sm8550_qmp_gen3x2_pcie_serdes_tbl), > > + .tx = sm8550_qmp_gen3x2_pcie_tx_tbl, > > + .tx_num = ARRAY_SIZE(sm8550_qmp_gen3x2_pcie_tx_tbl), > > + .rx = sm8550_qmp_gen3x2_pcie_rx_tbl, > > + .rx_num = ARRAY_SIZE(sm8550_qmp_gen3x2_pcie_rx_tbl), > > + .pcs = sm8550_qmp_gen3x2_pcie_pcs_tbl, > > + .pcs_num = ARRAY_SIZE(sm8550_qmp_gen3x2_pcie_pcs_tbl), > > + .pcs_misc = sm8550_qmp_gen3x2_pcie_pcs_misc_tbl, > > + .pcs_misc_num = ARRAY_SIZE(sm8550_qmp_gen3x2_pcie_pcs_misc_tbl), > > + }, > > + .clk_list = sc8280xp_pciephy_clk_l, > > + .num_clks = ARRAY_SIZE(sc8280xp_pciephy_clk_l), > > + .reset_list = sdm845_pciephy_reset_l, > > + .num_resets = ARRAY_SIZE(sdm845_pciephy_reset_l), > > + .vreg_list = qmp_phy_vreg_l, > > + .num_vregs = ARRAY_SIZE(qmp_phy_vreg_l), > > + .regs = pciephy_v5_regs_layout, > > + > > + .pwrdn_ctrl = SW_PWRDN | REFCLK_DRV_DSBL, > > + .phy_status = PHYSTATUS, > > +}; > > + [...]
On 23-02-03 10:49:24, Johan Hovold wrote: > On Fri, Feb 03, 2023 at 10:18:05AM +0200, Abel Vesa wrote: > > Add compatible for both PCIe found on SM8550. > > Also add the cnoc_pcie_sf_axi clock needed by the SM8550. > > nit: You're now also adding 'noc_aggr' > > > Signed-off-by: Abel Vesa <abel.vesa@linaro.org> > > Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> > > Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> > > --- > > > > The v6 of this patchset is: > > https://lore.kernel.org/all/20230202123902.3831491-11-abel.vesa@linaro.org/ > > > > Changes since v6: > > * none > > > > Changes since v5: > > * none > > > > Changes since v4: > > * added Mani's R-b tag > > > > Changes since v3: > > * renamed cnoc_pcie_sf_axi to cnoc_sf_axi > > > > Changes since v2: > > * none > > > > Changes since v1: > > * changed the subject line prefix for the patch to match the history, > > like Bjorn Helgaas suggested. > > * added Konrad's R-b tag > > > > drivers/pci/controller/dwc/pcie-qcom.c | 25 ++++++++++++++----------- > > 1 file changed, 14 insertions(+), 11 deletions(-) > > > > diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controller/dwc/pcie-qcom.c > > index a232b04af048..6a70c9c6f98d 100644 > > --- a/drivers/pci/controller/dwc/pcie-qcom.c > > +++ b/drivers/pci/controller/dwc/pcie-qcom.c > > @@ -182,10 +182,10 @@ struct qcom_pcie_resources_2_3_3 { > > > > /* 6 clocks typically, 7 for sm8250 */ > > struct qcom_pcie_resources_2_7_0 { > > - struct clk_bulk_data clks[12]; > > + struct clk_bulk_data clks[14]; > > int num_clks; > > struct regulator_bulk_data supplies[2]; > > - struct reset_control *pci_reset; > > + struct reset_control *rst; > > Please name this one 'reset' or 'resets' (e.g. to avoid hard to parse > things like res->rst below). Well, it would then be inconsitent with 2_3_3 and 2_9_0, which both use rst. > > > }; > > > > struct qcom_pcie_resources_2_9_0 { > > @@ -1177,9 +1177,9 @@ static int qcom_pcie_get_resources_2_7_0(struct qcom_pcie *pcie) > > unsigned int idx; > > int ret; > > > > - res->pci_reset = devm_reset_control_get_exclusive(dev, "pci"); > > - if (IS_ERR(res->pci_reset)) > > - return PTR_ERR(res->pci_reset); > > + res->rst = devm_reset_control_array_get_exclusive(dev); > > + if (IS_ERR(res->rst)) > > + return PTR_ERR(res->rst); > > So the reset array implementation apparently both asserts and deasserts > the resets in the order specified in DT (i.e. does not deassert in > reverse order). > > Is that ok also for the new "pci" and "link_down" resets? According to the HPG, yes, this is perfectly fine. It specifically says to assert the pcie reset and then continues saying to assert the link_down reset. > > > res->supplies[0].supply = "vdda"; > > res->supplies[1].supply = "vddpe-3v3"; > > @@ -1205,9 +1205,11 @@ static int qcom_pcie_get_resources_2_7_0(struct qcom_pcie *pcie) > > res->clks[idx++].id = "ddrss_sf_tbu"; > > res->clks[idx++].id = "aggre0"; > > res->clks[idx++].id = "aggre1"; > > + res->clks[idx++].id = "noc_aggr"; > > res->clks[idx++].id = "noc_aggr_4"; > > res->clks[idx++].id = "noc_aggr_south_sf"; > > res->clks[idx++].id = "cnoc_qx"; > > + res->clks[idx++].id = "cnoc_sf_axi"; > > > > num_opt_clks = idx - num_clks; > > res->num_clks = idx; > > @@ -1237,17 +1239,17 @@ static int qcom_pcie_init_2_7_0(struct qcom_pcie *pcie) > > if (ret < 0) > > goto err_disable_regulators; > > > > - ret = reset_control_assert(res->pci_reset); > > - if (ret < 0) { > > - dev_err(dev, "cannot assert pci reset\n"); > > + ret = reset_control_assert(res->rst); > > + if (ret) { > > + dev_err(dev, "reset assert failed (%d)\n", ret); > > goto err_disable_clocks; > > } > > > > usleep_range(1000, 1500); > > > > - ret = reset_control_deassert(res->pci_reset); > > - if (ret < 0) { > > - dev_err(dev, "cannot deassert pci reset\n"); > > + ret = reset_control_deassert(res->rst); > > + if (ret) { > > + dev_err(dev, "reset deassert failed (%d)\n", ret); > > goto err_disable_clocks; > > } > > Johan
On Mon, Feb 06, 2023 at 04:05:02PM +0200, Abel Vesa wrote: > On 23-02-03 10:33:14, Johan Hovold wrote: > > On Fri, Feb 03, 2023 at 10:18:03AM +0200, Abel Vesa wrote: > > > Add the SM8550 both g4 and g3 configurations. In addition, there is a > > > new "lane shared" table that needs to be configured for g4, along with > > > the No-CSR list of resets. > > > > Could you add a comment about the new nocsr reset and how it is used > > here? > > > > > Co-developed-by: Neil Armstrong <neil.armstrong@linaro.org> > > > Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> > > > Signed-off-by: Abel Vesa <abel.vesa@linaro.org> > > > Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> > > > --- > > > > > > This patchset relies on the following patchset: > > > https://lore.kernel.org/all/20230117224148.1914627-1-abel.vesa@linaro.org/ > > > > > > The v6 of this patch is: > > > https://lore.kernel.org/all/20230202123902.3831491-9-abel.vesa@linaro.org/ > > > > > > Changes since v6: > > > * none > > > > > > Changes since v5: > > > * renmaed the no-CSR reset to "phy_nocsr" as discussed off-list with > > > Bjorn and Johan > > > > > > Changes since v4: > > > * dropped _serdes infix from ln_shrd table name and from every ln_shrd > > > variable name > > > * added hyphen between "no CSR" in both places > > > * dropped has_ln_shrd_serdes_tbl > > > * reordered qmp_pcie_offsets_v6_20 by struct members > > > * added rollback for no-CSR reset in qmp_pcie_init fail path > > > * moved ln_shrd offset calculation after port_b > > > > > > Changes since v3: > > > * added Dmitry's R-b tag > > > > > > Changes since v2: > > > * none > > > > > > Changes since v1: > > > * split all the offsets into separate patches, like Vinod suggested > > > > > > > > > drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 367 ++++++++++++++++++++++- > > > 1 file changed, 365 insertions(+), 2 deletions(-) > > > > > > diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c > > > index 907f3f236f05..ff6c0b526fde 100644 > > > --- a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c > > > +++ b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c > > > @@ -1506,6 +1506,234 @@ static const struct qmp_phy_init_tbl sm8450_qmp_gen4x2_pcie_ep_pcs_misc_tbl[] = > > > QMP_PHY_INIT_CFG(QPHY_V5_20_PCS_PCIE_OSC_DTCT_MODE2_CONFIG5, 0x08), > > > }; > > > [...] > > > > > > > > @@ -2214,6 +2469,68 @@ static const struct qmp_phy_cfg sm8450_qmp_gen4x2_pciephy_cfg = { > > > .phy_status = PHYSTATUS_4_20, > > > }; > > > > > > +static const struct qmp_phy_cfg sm8550_qmp_gen3x2_pciephy_cfg = { > > > + .lanes = 2, > > > + > > > + .offsets = &qmp_pcie_offsets_v5, > > > > Did you really intend to use the v5 offsets here? It seems you use v6.20 > > defines in the tables below. This may work but it looks a little strange > > and does not match how we name and use these resources for the other > > SoCs (e.g. reusing structures and defines from older IP revisions is > > fine, but not necessarily the other way round). > > So here is what is happening here. The actual IP block version is 6 for > the g3x2. The offsets of the tables are the same as on v5, but the > actual offsets of some of the registers within those tables are > entirely different. Now, if you compare the PCS PCIe offsets (v5 vs v6) > you'll notice that all v6 registers currently added are the same as v5 > (both names and values). With that in mind, we still need to keep the v6 > offsets for the case when a new register, that might not be in v5, might > be added later on. As for the table offsets, since they look the same we > should probably not add a dedicated v6 one. Ok, makes sense. Johan
On Mon, Feb 06, 2023 at 05:11:01PM +0200, Abel Vesa wrote: > On 23-02-03 10:49:24, Johan Hovold wrote: > > On Fri, Feb 03, 2023 at 10:18:05AM +0200, Abel Vesa wrote: > > > Add compatible for both PCIe found on SM8550. > > > Also add the cnoc_pcie_sf_axi clock needed by the SM8550. > > > > nit: You're now also adding 'noc_aggr' > > > > > Signed-off-by: Abel Vesa <abel.vesa@linaro.org> > > > Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> > > > Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> > > > --- > > > @@ -182,10 +182,10 @@ struct qcom_pcie_resources_2_3_3 { > > > > > > /* 6 clocks typically, 7 for sm8250 */ > > > struct qcom_pcie_resources_2_7_0 { > > > - struct clk_bulk_data clks[12]; > > > + struct clk_bulk_data clks[14]; > > > int num_clks; > > > struct regulator_bulk_data supplies[2]; > > > - struct reset_control *pci_reset; > > > + struct reset_control *rst; > > > > Please name this one 'reset' or 'resets' (e.g. to avoid hard to parse > > things like res->rst below). > > Well, it would then be inconsitent with 2_3_3 and 2_9_0, which both use > rst. Yeah, I saw that. Fortunately these resources are completely independent, but whatever. > > > }; > > > > > > struct qcom_pcie_resources_2_9_0 { > > > @@ -1177,9 +1177,9 @@ static int qcom_pcie_get_resources_2_7_0(struct qcom_pcie *pcie) > > > unsigned int idx; > > > int ret; > > > > > > - res->pci_reset = devm_reset_control_get_exclusive(dev, "pci"); > > > - if (IS_ERR(res->pci_reset)) > > > - return PTR_ERR(res->pci_reset); > > > + res->rst = devm_reset_control_array_get_exclusive(dev); > > > + if (IS_ERR(res->rst)) > > > + return PTR_ERR(res->rst); > > > > So the reset array implementation apparently both asserts and deasserts > > the resets in the order specified in DT (i.e. does not deassert in > > reverse order). > > > > Is that ok also for the new "pci" and "link_down" resets? > > According to the HPG, yes, this is perfectly fine. It specifically says > to assert the pcie reset and then continues saying to assert the > link_down reset. Ok, but that doesn't really say anything about whether it's ok to *deassert* them in the same order, which was what I asked about. Johan
On 23-02-08 17:40:03, Johan Hovold wrote: > On Mon, Feb 06, 2023 at 05:11:01PM +0200, Abel Vesa wrote: > > On 23-02-03 10:49:24, Johan Hovold wrote: > > > On Fri, Feb 03, 2023 at 10:18:05AM +0200, Abel Vesa wrote: > > > > Add compatible for both PCIe found on SM8550. > > > > Also add the cnoc_pcie_sf_axi clock needed by the SM8550. > > > > > > nit: You're now also adding 'noc_aggr' > > > > > > > Signed-off-by: Abel Vesa <abel.vesa@linaro.org> > > > > Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> > > > > Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> > > > > --- > > > > > @@ -182,10 +182,10 @@ struct qcom_pcie_resources_2_3_3 { > > > > > > > > /* 6 clocks typically, 7 for sm8250 */ > > > > struct qcom_pcie_resources_2_7_0 { > > > > - struct clk_bulk_data clks[12]; > > > > + struct clk_bulk_data clks[14]; > > > > int num_clks; > > > > struct regulator_bulk_data supplies[2]; > > > > - struct reset_control *pci_reset; > > > > + struct reset_control *rst; > > > > > > Please name this one 'reset' or 'resets' (e.g. to avoid hard to parse > > > things like res->rst below). > > > > Well, it would then be inconsitent with 2_3_3 and 2_9_0, which both use > > rst. > > Yeah, I saw that. Fortunately these resources are completely > independent, but whatever. Will do it in the next version then. > > > > > }; > > > > > > > > struct qcom_pcie_resources_2_9_0 { > > > > @@ -1177,9 +1177,9 @@ static int qcom_pcie_get_resources_2_7_0(struct qcom_pcie *pcie) > > > > unsigned int idx; > > > > int ret; > > > > > > > > - res->pci_reset = devm_reset_control_get_exclusive(dev, "pci"); > > > > - if (IS_ERR(res->pci_reset)) > > > > - return PTR_ERR(res->pci_reset); > > > > + res->rst = devm_reset_control_array_get_exclusive(dev); > > > > + if (IS_ERR(res->rst)) > > > > + return PTR_ERR(res->rst); > > > > > > So the reset array implementation apparently both asserts and deasserts > > > the resets in the order specified in DT (i.e. does not deassert in > > > reverse order). > > > > > > Is that ok also for the new "pci" and "link_down" resets? > > > > According to the HPG, yes, this is perfectly fine. It specifically says > > to assert the pcie reset and then continues saying to assert the > > link_down reset. > > Ok, but that doesn't really say anything about whether it's ok to > *deassert* them in the same order, which was what I asked about. Actually, what I wanted to say is that the HPG says something like this: "assert pcie reset, then assert link_down" and then at the end it literaly repeats the same phrase. > > Johan
On 23-02-08 19:10:17, Abel Vesa wrote: > On 23-02-08 17:40:03, Johan Hovold wrote: > > On Mon, Feb 06, 2023 at 05:11:01PM +0200, Abel Vesa wrote: > > > On 23-02-03 10:49:24, Johan Hovold wrote: > > > > On Fri, Feb 03, 2023 at 10:18:05AM +0200, Abel Vesa wrote: > > > > > Add compatible for both PCIe found on SM8550. > > > > > Also add the cnoc_pcie_sf_axi clock needed by the SM8550. > > > > > > > > nit: You're now also adding 'noc_aggr' > > > > > > > > > Signed-off-by: Abel Vesa <abel.vesa@linaro.org> > > > > > Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> > > > > > Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> > > > > > --- > > > > > > > @@ -182,10 +182,10 @@ struct qcom_pcie_resources_2_3_3 { > > > > > > > > > > /* 6 clocks typically, 7 for sm8250 */ > > > > > struct qcom_pcie_resources_2_7_0 { > > > > > - struct clk_bulk_data clks[12]; > > > > > + struct clk_bulk_data clks[14]; > > > > > int num_clks; > > > > > struct regulator_bulk_data supplies[2]; > > > > > - struct reset_control *pci_reset; > > > > > + struct reset_control *rst; > > > > > > > > Please name this one 'reset' or 'resets' (e.g. to avoid hard to parse > > > > things like res->rst below). > > > > > > Well, it would then be inconsitent with 2_3_3 and 2_9_0, which both use > > > rst. > > > > Yeah, I saw that. Fortunately these resources are completely > > independent, but whatever. > > Will do it in the next version then. > > > > > > > > }; > > > > > > > > > > struct qcom_pcie_resources_2_9_0 { > > > > > @@ -1177,9 +1177,9 @@ static int qcom_pcie_get_resources_2_7_0(struct qcom_pcie *pcie) > > > > > unsigned int idx; > > > > > int ret; > > > > > > > > > > - res->pci_reset = devm_reset_control_get_exclusive(dev, "pci"); > > > > > - if (IS_ERR(res->pci_reset)) > > > > > - return PTR_ERR(res->pci_reset); > > > > > + res->rst = devm_reset_control_array_get_exclusive(dev); > > > > > + if (IS_ERR(res->rst)) > > > > > + return PTR_ERR(res->rst); > > > > > > > > So the reset array implementation apparently both asserts and deasserts > > > > the resets in the order specified in DT (i.e. does not deassert in > > > > reverse order). > > > > > > > > Is that ok also for the new "pci" and "link_down" resets? > > > > > > According to the HPG, yes, this is perfectly fine. It specifically says > > > to assert the pcie reset and then continues saying to assert the > > > link_down reset. > > > > Ok, but that doesn't really say anything about whether it's ok to > > *deassert* them in the same order, which was what I asked about. > > Actually, what I wanted to say is that the HPG says something like this: > > "assert pcie reset, then assert link_down" > > and then at the end it literaly repeats the same phrase. but uses deassert instead of assert ... > > > > > > > > > Johan
On Wed, Feb 08, 2023 at 07:11:08PM +0200, Abel Vesa wrote: > On 23-02-08 19:10:17, Abel Vesa wrote: > > On 23-02-08 17:40:03, Johan Hovold wrote: > > > On Mon, Feb 06, 2023 at 05:11:01PM +0200, Abel Vesa wrote: > > > > On 23-02-03 10:49:24, Johan Hovold wrote: > > > > > On Fri, Feb 03, 2023 at 10:18:05AM +0200, Abel Vesa wrote: > > > > > > Add compatible for both PCIe found on SM8550. > > > > > > Also add the cnoc_pcie_sf_axi clock needed by the SM8550. > > > > > > > > > > nit: You're now also adding 'noc_aggr' > > > > > > > > > > > Signed-off-by: Abel Vesa <abel.vesa@linaro.org> > > > > > > Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> > > > > > > Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> > > > > > > --- > > > > > > > > > @@ -182,10 +182,10 @@ struct qcom_pcie_resources_2_3_3 { > > > > > > > > > > > > /* 6 clocks typically, 7 for sm8250 */ > > > > > > struct qcom_pcie_resources_2_7_0 { > > > > > > - struct clk_bulk_data clks[12]; > > > > > > + struct clk_bulk_data clks[14]; > > > > > > int num_clks; > > > > > > struct regulator_bulk_data supplies[2]; > > > > > > - struct reset_control *pci_reset; > > > > > > + struct reset_control *rst; > > > > > > > > > > Please name this one 'reset' or 'resets' (e.g. to avoid hard to parse > > > > > things like res->rst below). > > > > > > > > Well, it would then be inconsitent with 2_3_3 and 2_9_0, which both use > > > > rst. > > > > > > Yeah, I saw that. Fortunately these resources are completely > > > independent, but whatever. > > > > Will do it in the next version then. Or just leave it as is. > > > > > > }; > > > > > > > > > > > > struct qcom_pcie_resources_2_9_0 { > > > > > > @@ -1177,9 +1177,9 @@ static int qcom_pcie_get_resources_2_7_0(struct qcom_pcie *pcie) > > > > > > unsigned int idx; > > > > > > int ret; > > > > > > > > > > > > - res->pci_reset = devm_reset_control_get_exclusive(dev, "pci"); > > > > > > - if (IS_ERR(res->pci_reset)) > > > > > > - return PTR_ERR(res->pci_reset); > > > > > > + res->rst = devm_reset_control_array_get_exclusive(dev); > > > > > > + if (IS_ERR(res->rst)) > > > > > > + return PTR_ERR(res->rst); > > > > > > > > > > So the reset array implementation apparently both asserts and deasserts > > > > > the resets in the order specified in DT (i.e. does not deassert in > > > > > reverse order). > > > > > > > > > > Is that ok also for the new "pci" and "link_down" resets? > > > > > > > > According to the HPG, yes, this is perfectly fine. It specifically says > > > > to assert the pcie reset and then continues saying to assert the > > > > link_down reset. > > > > > > Ok, but that doesn't really say anything about whether it's ok to > > > *deassert* them in the same order, which was what I asked about. > > > > Actually, what I wanted to say is that the HPG says something like this: > > > > "assert pcie reset, then assert link_down" > > > > and then at the end it literaly repeats the same phrase. > > but uses deassert instead of assert ... Ok, then it seems to match the implementation. Thanks for clarifying. Johan