linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Johan Hovold <johan@kernel.org>
To: Abel Vesa <abel.vesa@linaro.org>
Cc: "Andy Gross" <agross@kernel.org>,
	"Bjorn Andersson" <andersson@kernel.org>,
	"Konrad Dybcio" <konrad.dybcio@linaro.org>,
	"Lorenzo Pieralisi" <lorenzo.pieralisi@arm.com>,
	"Rob Herring" <robh@kernel.org>,
	"Krzysztof Wilczyński" <kw@linux.com>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>,
	"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
	"vkoul@kernel.org" <vkoul@kernel.org>,
	"Kishon Vijay Abraham I" <kishon@kernel.org>,
	"Manivannan Sadhasivam" <mani@kernel.org>,
	linux-arm-msm@vger.kernel.org, linux-pci@vger.kernel.org,
	linux-phy@lists.infradead.org, devicetree@vger.kernel.org,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"Neil Armstrong" <neil.armstrong@linaro.org>,
	"Dmitry Baryshkov" <dmitry.baryshkov@linaro.org>
Subject: Re: [PATCH v4 08/12] phy: qcom-qmp-pcie: Add support for SM8550 g3x2 and g4x2 PCIEs
Date: Mon, 23 Jan 2023 16:03:48 +0100	[thread overview]
Message-ID: <Y86h1FDuHFu3mImq@hovoldconsulting.com> (raw)
In-Reply-To: <20230119140453.3942340-9-abel.vesa@linaro.org>

On Thu, Jan 19, 2023 at 04:04:49PM +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.
> 
> 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 v3 of this patchset is:
> https://lore.kernel.org/all/20230118005328.2378792-1-abel.vesa@linaro.org/
> 
> 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 | 365 +++++++++++++++++++++++
>  1 file changed, 365 insertions(+)
> 
> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
> index bffb9e138715..48d179d8d8d6 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_gen4x2_pcie_serdes_ln_shrd_tbl[] = {

Perhaps you can drop the '_serdes' infix here as it is mostly redundant
and not included in the names of the other tables/resources.

> +	QMP_PHY_INIT_CFG(QSERDES_V6_LN_SHRD_RXCLK_DIV2_CTRL, 0x01),
> +	QMP_PHY_INIT_CFG(QSERDES_V6_LN_SHRD_RX_Q_EN_RATES, 0xe),
> +	QMP_PHY_INIT_CFG(QSERDES_V6_LN_SHRD_DFE_DAC_ENABLE1, 0x00),
> +	QMP_PHY_INIT_CFG(QSERDES_V6_LN_SHRD_TX_ADAPT_POST_THRESH1, 0x00),
> +	QMP_PHY_INIT_CFG(QSERDES_V6_LN_SHRD_TX_ADAPT_POST_THRESH2, 0x1f),
> +	QMP_PHY_INIT_CFG(QSERDES_V6_LN_SHRD_RX_MODE_RATE_0_1_B0, 0x12),
> +	QMP_PHY_INIT_CFG(QSERDES_V6_LN_SHRD_RX_MODE_RATE_0_1_B1, 0x12),
> +	QMP_PHY_INIT_CFG(QSERDES_V6_LN_SHRD_RX_MODE_RATE_0_1_B2, 0xdb),
> +	QMP_PHY_INIT_CFG(QSERDES_V6_LN_SHRD_RX_MODE_RATE_0_1_B3, 0x9a),
> +	QMP_PHY_INIT_CFG(QSERDES_V6_LN_SHRD_RX_MODE_RATE_0_1_B4, 0x38),
> +	QMP_PHY_INIT_CFG(QSERDES_V6_LN_SHRD_RX_MODE_RATE_0_1_B5, 0xb6),
> +	QMP_PHY_INIT_CFG(QSERDES_V6_LN_SHRD_RX_MODE_RATE_0_1_B6, 0x64),
> +	QMP_PHY_INIT_CFG(QSERDES_V6_LN_SHRD_RX_MARG_COARSE_THRESH1_RATE210, 0x1f),
> +	QMP_PHY_INIT_CFG(QSERDES_V6_LN_SHRD_RX_MARG_COARSE_THRESH1_RATE3, 0x1f),
> +	QMP_PHY_INIT_CFG(QSERDES_V6_LN_SHRD_RX_MARG_COARSE_THRESH2_RATE210, 0x1f),
> +	QMP_PHY_INIT_CFG(QSERDES_V6_LN_SHRD_RX_MARG_COARSE_THRESH2_RATE3, 0x1f),
> +	QMP_PHY_INIT_CFG(QSERDES_V6_LN_SHRD_RX_MARG_COARSE_THRESH3_RATE210, 0x1f),
> +	QMP_PHY_INIT_CFG(QSERDES_V6_LN_SHRD_RX_MARG_COARSE_THRESH3_RATE3, 0x1f),
> +	QMP_PHY_INIT_CFG(QSERDES_V6_LN_SHRD_RX_MARG_COARSE_THRESH4_RATE3, 0x1f),
> +	QMP_PHY_INIT_CFG(QSERDES_V6_LN_SHRD_RX_MARG_COARSE_THRESH5_RATE3, 0x1f),
> +	QMP_PHY_INIT_CFG(QSERDES_V6_LN_SHRD_RX_MARG_COARSE_THRESH6_RATE3, 0x1f),
> +};
> +
> +static const struct qmp_phy_init_tbl sm8550_qmp_gen4x2_pcie_tx_tbl[] = {
> +	QMP_PHY_INIT_CFG(QSERDES_V6_20_TX_RES_CODE_LANE_OFFSET_TX, 0x1d),
> +	QMP_PHY_INIT_CFG(QSERDES_V6_20_TX_RES_CODE_LANE_OFFSET_RX, 0x03),
> +	QMP_PHY_INIT_CFG(QSERDES_V6_20_TX_LANE_MODE_1, 0x01),
> +	QMP_PHY_INIT_CFG(QSERDES_V6_20_TX_LANE_MODE_2, 0x00),
> +	QMP_PHY_INIT_CFG(QSERDES_V6_20_TX_LANE_MODE_3, 0x51),
> +	QMP_PHY_INIT_CFG(QSERDES_V6_20_TX_TRAN_DRVR_EMP_EN, 0x34),
> +};

>  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_serdes;
> +	int ln_shrd_serdes_num;
>  	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 */

Add a hyphen between 'no' and 'CSR' to make it a bit more readable.

> +	const char * const *nocsr_reset_list;
> +	int num_nocsr_resets;
>  	/* regulators to be requested */
>  	const char * const *vreg_list;
>  	int num_vregs;
> @@ -1569,6 +1803,9 @@ struct qmp_phy_cfg {
>  
>  	bool skip_start_delay;
>  
> +	/* true, if PHY has lane shared serdes table */
> +	bool has_ln_shrd_serdes_tbl;
> +

Can't you just check the table pointer directly?

>  	/* QMP PHY pipe clock interface rate */
>  	unsigned long pipe_clock_rate;
>  };
> @@ -1580,6 +1817,7 @@ struct qmp_pcie {
>  	bool tcsr_4ln_config;
>  
>  	void __iomem *serdes;
> +	void __iomem *ln_shrd_serdes;

Drop '_serdes'.

>  	void __iomem *pcs;
>  	void __iomem *pcs_misc;
>  	void __iomem *tx;
> @@ -1594,6 +1832,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 +1887,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 +1900,10 @@ static const char * const sdm845_pciephy_reset_l[] = {
>  	"phy",
>  };
>  
> +static const char * const sm8550_pciephy_nocsr_reset_l[] = {
> +	"nocsr",
> +};
> +
>  static const struct qmp_pcie_offsets qmp_pcie_offsets_v5 = {
>  	.serdes		= 0,
>  	.pcs		= 0x0200,
> @@ -1667,6 +1914,17 @@ static const struct qmp_pcie_offsets qmp_pcie_offsets_v5 = {
>  	.rx2		= 0x1800,
>  };
>  
> +static const struct qmp_pcie_offsets qmp_pcie_offsets_v6_20 = {
> +	.tx		= 0x0,
> +	.rx		= 0x0200,
> +	.tx2		= 0x0800,
> +	.rx2		= 0x0a00,
> +	.ln_shrd	= 0x0e00,
> +	.serdes		= 0x1000,
> +	.pcs		= 0x1200,
> +	.pcs_misc	= 0x1400,
> +};

I did not notice before, but perhaps you should use the order from the
struct definition instead of sorting by offset. That should make it
easier to spot SoC differences, missing fields, etc.

> +
>  static const struct qmp_phy_cfg ipq8074_pciephy_cfg = {
>  	.lanes			= 1,
>  

> @@ -2262,6 +2583,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_serdes = qmp->ln_shrd_serdes;

ln_shrd should do.

>  	void __iomem *tx = qmp->tx;
>  	void __iomem *rx = qmp->rx;
>  	void __iomem *tx2 = qmp->tx2;
> @@ -2289,6 +2611,10 @@ 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);
>  	}
> +
> +	if (cfg->has_ln_shrd_serdes_tbl)

So you could check tbls->ln_shrd here, or just call unconditionally as
qmp_pcie_configure() already handles that.

> +		qmp_pcie_configure(ln_shrd_serdes, tbls->ln_shrd_serdes,
> +				       tbls->ln_shrd_serdes_num);
>  }
>  
>  static int qmp_pcie_init(struct phy *phy)
> @@ -2309,6 +2635,14 @@ 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_disable_regulators;
> +		}
> +	}
> +
>  	usleep_range(200, 300);
>  
>  	ret = reset_control_bulk_deassert(cfg->num_resets, qmp->resets);

Should you really leave the reset asserted on errors here and below?

> @@ -2370,6 +2704,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;
> +		}
> +	}

Is this the documented reset sequence? To keep the nocsr reset asserted
from init() to power_on() and during programming of the PHY registers?

What if power_on() is never called, etc? (I know we always call
power_on() after init() currently, but that may change.)

Could you explain a bit how this reset is supposed work and be used?

> +
>  	/* Pull PHY out of reset state */
>  	qphy_clrbits(pcs, cfg->regs[QPHY_SW_RESET], SW_RESET);
>  
> @@ -2503,6 +2845,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");

hyphen after 'no'

> +	}
> +
>  	return 0;
>  }
>  
> @@ -2713,6 +3070,8 @@ static int qmp_pcie_parse_dt(struct qmp_pcie *qmp)
>  	qmp->pcs_misc = base + offs->pcs_misc;
>  	qmp->tx = base + offs->tx;
>  	qmp->rx = base + offs->rx;
> +	if (cfg->has_ln_shrd_serdes_tbl)
> +		qmp->ln_shrd_serdes = base + offs->ln_shrd;

Odd placement here in between tx/rx and tx2/rx2.

Doesn't hurt setting the pointer whenever this block exists, so perhaps
just do

	if (offs->ln_shrd)
		qmp->ln_shrd = base + offs->ln_shrd;

and move this after the port_b initialisation (e.g. to follow the order
in the offset struct and programming sequence above)?

>  
>  	if (cfg->lanes >= 2) {
>  		qmp->tx2 = base + offs->tx2;

Johan

  reply	other threads:[~2023-01-23 15:03 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-19 14:04 [PATCH v4 00/12] sm8550: Add PCIe HC and PHY support Abel Vesa
2023-01-19 14:04 ` [PATCH v4 01/12] dt-bindings: phy: Add QMP PCIe PHY comptible for SM8550 Abel Vesa
2023-01-22 14:09   ` Krzysztof Kozlowski
2023-01-19 14:04 ` [PATCH v4 02/12] phy: qcom-qmp: pcs: Add v6 register offsets Abel Vesa
2023-01-19 14:04 ` [PATCH v4 03/12] phy: qcom-qmp: pcs: Add v6.20 " Abel Vesa
2023-01-19 14:04 ` [PATCH v4 04/12] phy: qcom-qmp: pcs-pcie: Add v6 " Abel Vesa
2023-01-19 14:04 ` [PATCH v4 05/12] phy: qcom-qmp: pcs-pcie: Add v6.20 " Abel Vesa
2023-01-19 14:04 ` [PATCH v4 06/12] phy: qcom-qmp: qserdes-txrx: " Abel Vesa
2023-01-19 14:04 ` [PATCH v4 07/12] phy: qcom-qmp: qserdes-lane-shared: Add v6 " Abel Vesa
2023-01-19 14:04 ` [PATCH v4 08/12] phy: qcom-qmp-pcie: Add support for SM8550 g3x2 and g4x2 PCIEs Abel Vesa
2023-01-23 15:03   ` Johan Hovold [this message]
2023-01-23 19:42     ` Abel Vesa
2023-01-19 14:04 ` [PATCH v4 09/12] dt-bindings: PCI: qcom: Add SM8550 compatible Abel Vesa
2023-01-22 14:10   ` Krzysztof Kozlowski
2023-01-23 10:44     ` Abel Vesa
2023-01-23 11:03       ` Krzysztof Kozlowski
2023-01-19 14:04 ` [PATCH v4 10/12] PCI: qcom: Add SM8550 PCIe support Abel Vesa
2023-01-19 14:21   ` Manivannan Sadhasivam
2023-01-19 15:35     ` Abel Vesa
2023-01-23  8:27       ` Johan Hovold
2023-01-19 14:04 ` [PATCH v4 11/12] arm64: dts: qcom: sm8550: Add PCIe PHYs and controllers nodes Abel Vesa
2023-01-23  8:51   ` Johan Hovold
2023-01-23 12:39     ` Abel Vesa
2023-01-23 13:11       ` Abel Vesa
2023-01-23 14:17         ` Johan Hovold
2023-01-23 14:16       ` Johan Hovold
2023-01-23 14:24         ` Johan Hovold
2023-01-19 14:04 ` [PATCH v4 12/12] arm64: dts: qcom: sm8550-mtp: " Abel Vesa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y86h1FDuHFu3mImq@hovoldconsulting.com \
    --to=johan@kernel.org \
    --cc=abel.vesa@linaro.org \
    --cc=agross@kernel.org \
    --cc=andersson@kernel.org \
    --cc=bhelgaas@google.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dmitry.baryshkov@linaro.org \
    --cc=kishon@kernel.org \
    --cc=konrad.dybcio@linaro.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=kw@linux.com \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-phy@lists.infradead.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=lpieralisi@kernel.org \
    --cc=mani@kernel.org \
    --cc=neil.armstrong@linaro.org \
    --cc=robh@kernel.org \
    --cc=vkoul@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).