All of lore.kernel.org
 help / color / mirror / Atom feed
From: Can Guo <cang@codeaurora.org>
To: Vinod Koul <vkoul@kernel.org>
Cc: Asutosh Das <asutoshd@codeaurora.org>,
	Kishon Vijay Abraham I <kishon@ti.com>,
	linux-arm-msm@vger.kernel.org,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	Andy Gross <agross@kernel.org>,
	Jeffrey Hugo <jeffrey.l.hugo@gmail.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/4] phy: qcom-qmp: Add optional SW reset
Date: Fri, 20 Dec 2019 14:00:20 +0800	[thread overview]
Message-ID: <e55185eda9d7dcbce80a671e630449ea@codeaurora.org> (raw)
In-Reply-To: <20191220042427.GE2536@vkoul-mobl>

On 2019-12-20 12:24, Vinod Koul wrote:
> On 20-12-19, 08:49, cang@codeaurora.org wrote:
>> On 2019-12-20 08:22, cang@codeaurora.org wrote:
>> > On 2019-12-19 23:04, Vinod Koul wrote:
>> > > For V4 QMP UFS Phy, we need to assert reset bits, configure the phy
>> > > and
>> > > then deassert it, so add optional has_sw_reset flag and use that to
>> > > configure the QPHY_SW_RESET register.
>> > >
>> > > Signed-off-by: Vinod Koul <vkoul@kernel.org>
>> > > ---
>> > >  drivers/phy/qualcomm/phy-qcom-qmp.c | 10 ++++++++++
>> > >  1 file changed, 10 insertions(+)
>> > >
>> > > diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c
>> > > b/drivers/phy/qualcomm/phy-qcom-qmp.c
>> > > index 06f971ca518e..80304b7cd895 100644
>> > > --- a/drivers/phy/qualcomm/phy-qcom-qmp.c
>> > > +++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
>> > > @@ -1023,6 +1023,9 @@ struct qmp_phy_cfg {
>> > >
>> > >  	/* true, if PCS block has no separate SW_RESET register */
>> > >  	bool no_pcs_sw_reset;
>> > > +
>> > > +	/* true if sw reset needs to be invoked */
>> > > +	bool has_sw_reset;
>> > >  };
>> > >
>> > >  /**
>> > > @@ -1391,6 +1394,7 @@ static const struct qmp_phy_cfg
>> > > sm8150_ufsphy_cfg = {
>> > >
>> > >  	.is_dual_lane_phy	= true,
>> > >  	.no_pcs_sw_reset	= true,
>> > > +	.has_sw_reset		= true,
>> > >  };
>> > >
>> > >  static void qcom_qmp_phy_configure(void __iomem *base,
>> > > @@ -1475,6 +1479,9 @@ static int qcom_qmp_phy_com_init(struct
>> > > qmp_phy *qphy)
>> > >  			     SW_USB3PHY_RESET_MUX | SW_USB3PHY_RESET);
>> > >  	}
>> > >
>> > > +	if (cfg->has_sw_reset)
>> > > +		qphy_setbits(serdes, cfg->regs[QPHY_SW_RESET], SW_RESET);
>> > > +
>> >
>> > Are you sure you want to set this in the serdes register? QPHY_SW_RESET
>> > is in its pcs register.
>> >
>> > >  	if (cfg->has_phy_com_ctrl)
>> > >  		qphy_setbits(serdes, cfg->regs[QPHY_COM_POWER_DOWN_CONTROL],
>> > >  			     SW_PWRDN);
>> > > @@ -1651,6 +1658,9 @@ static int qcom_qmp_phy_enable(struct phy *phy)
>> > >  	if (cfg->has_phy_dp_com_ctrl)
>> > >  		qphy_clrbits(dp_com, QPHY_V3_DP_COM_SW_RESET, SW_RESET);
>> > >
>> > > +	if (cfg->has_sw_reset)
>> > > +		qphy_clrbits(pcs, cfg->regs[QPHY_SW_RESET], SW_RESET);
>> > > +
>> >
>> > Yet you are clearing it from pcs register.
> 
> updated now, will send v2
> 
>> >
>> > Regards,
>> > Can Guo
>> >
>> > >  	/* start SerDes and Phy-Coding-Sublayer */
>> > >  	qphy_setbits(pcs, cfg->regs[QPHY_START_CTRL], cfg->start_ctrl);
>> 
>> I thought your change would be like this
>> 
>> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c
>> b/drivers/phy/qualcomm/phy-qcom-qmp.c
>> index 8e642a6..a4ab4b7 100755
>> --- a/drivers/phy/qualcomm/phy-qcom-qmp.c
>> +++ b/drivers/phy/qualcomm/phy-qcom-qmp.c
>> @@ -166,6 +166,7 @@ static const unsigned int 
>> sdm845_ufsphy_regs_layout[] =
>> {
>>  };
>> 
>>  static const unsigned int sm8150_ufsphy_regs_layout[] = {
>> +       [QPHY_SW_RESET]                 = 0x08,
>>         [QPHY_START_CTRL]               = 0x00,
>>         [QPHY_PCS_READY_STATUS]         = 0x180,
>>  };
>> @@ -1390,7 +1391,6 @@ static const struct qmp_phy_cfg 
>> sm8150_ufsphy_cfg = {
>>         .pwrdn_ctrl             = SW_PWRDN,
>> 
>>         .is_dual_lane_phy       = true,
>> -       .no_pcs_sw_reset        = true,
>>  };
>> 
>>  static void qcom_qmp_phy_configure(void __iomem *base,
>> @@ -1475,6 +1475,9 @@ static int qcom_qmp_phy_com_init(struct qmp_phy 
>> *qphy)
>>                              SW_USB3PHY_RESET_MUX | SW_USB3PHY_RESET);
>>         }
>> 
>> +       if ((cfg->type == PHY_TYPE_UFS) && (!cfg->no_pcs_sw_reset))
>> +               qphy_setbits(pcs, cfg->regs[QPHY_SW_RESET], SW_RESET);
> 
> Well am not sure if no_pcs_sw_reset would do this and side effect on
> other phys (somehow older ones dont seem to need this). That was the
> reason for a new flag and to be used for specific instances
> 
> Thanks

Hi Vinod,

That is why I added the check as cfg->type == PHY_TYPE_UFS, meaning this
change will only apply to UFS.
FYI, start from 8150(include 8150), QPHY_SW_RESET is present in PHY's
PCS register. no_pcs_sw_reset = TRUE should only be given to 845 and 
older
targets, like 8998, because they don't have this QPHY_SW_RESET in PHY's
register per their design, that's why they leverage the reset control
provided by UFS controller.

Thanks,
Can Guo.

  reply	other threads:[~2019-12-20  6:00 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-19 15:04 [PATCH 0/4] phy: qcom-qmp: Fixes and updates for sm8150 Vinod Koul
2019-12-19 15:04 ` [PATCH 1/4] phy: qcom-qmp: Increase the phy init timeout Vinod Koul
2019-12-19 15:29   ` Jeffrey Hugo
2019-12-19 15:40     ` Vinod Koul
2019-12-20  2:08   ` Bjorn Andersson
2019-12-20  4:21     ` Vinod Koul
2019-12-19 15:04 ` [PATCH 2/4] phy: qcom-qmp: Use register defines Vinod Koul
2019-12-19 15:30   ` Jeffrey Hugo
2019-12-20  0:44   ` cang
2019-12-20  4:22     ` Vinod Koul
2019-12-19 15:04 ` [PATCH 3/4] phy: qcom-qmp: Add optional SW reset Vinod Koul
2019-12-19 15:31   ` Jeffrey Hugo
2019-12-20  0:22   ` cang
2019-12-20  0:49     ` cang
2019-12-20  4:24       ` Vinod Koul
2019-12-20  6:00         ` Can Guo [this message]
2019-12-20  7:10           ` Vinod Koul
2019-12-20  7:41             ` Can Guo
2019-12-20  7:53               ` Vinod Koul
2019-12-23  9:00                 ` Manu Gautam
2019-12-23  9:02       ` Manu Gautam
2019-12-19 15:04 ` [PATCH 4/4] phy: qcom-qmp: remove duplicate powerdown write Vinod Koul
2019-12-19 15:31   ` Jeffrey Hugo
2019-12-20  1:30   ` Can Guo

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=e55185eda9d7dcbce80a671e630449ea@codeaurora.org \
    --to=cang@codeaurora.org \
    --cc=agross@kernel.org \
    --cc=asutoshd@codeaurora.org \
    --cc=bjorn.andersson@linaro.org \
    --cc=jeffrey.l.hugo@gmail.com \
    --cc=kishon@ti.com \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.