linux-arm-msm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bjorn Andersson <bjorn.andersson@linaro.org>
To: Alim Akhtar <alim.akhtar@samsung.com>
Cc: Avri Altman <avri.altman@wdc.com>,
	Pedro Sousa <pedrom.sousa@synopsys.com>,
	"James E.J. Bottomley" <jejb@linux.ibm.com>,
	"Martin K. Petersen" <martin.petersen@oracle.com>,
	Rob Herring <robh+dt@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Andy Gross <agross@kernel.org>,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-msm@vger.kernel.org, linux-scsi@vger.kernel.org
Subject: Re: [PATCH v3 1/3] scsi: ufs: Introduce vops for resetting device
Date: Tue, 25 Jun 2019 20:45:29 -0700	[thread overview]
Message-ID: <20190626034529.GE24205@tuxbook-pro> (raw)
In-Reply-To: <ad1c2a2a-91d6-25ce-9dfb-3b386b572ee2@samsung.com>

On Tue 25 Jun 05:41 PDT 2019, Alim Akhtar wrote:

> Hi Bjorn,
> Are you planning to address Bean's comment on patch#2 and want to 
> re-spin this series?
> I am ok with taking this patch as it is and take a Softreset patch as a 
> separate patch.
> 

I still intend to attempt to implement a softreset "fallback", per
Bean's suggestion - just haven't found the time yet. But I would be
happy to see these patches merged in the meantime, as they do resolve
the issue of failing to being up the UFS link on a significant number of
Qualcomm devices.


I think it's best if you take patch 1 and 2 through your tree and we
take the dts patch through the Qualcomm/arm-soc tree.

Thanks,
Bjorn

> On 6/8/19 10:34 AM, Bjorn Andersson wrote:
> > Some UFS memory devices needs their reset line toggled in order to get
> > them into a good state for initialization. Provide a new vops to allow
> > the platform driver to implement this operation.
> > 
> > Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> > ---
> feel free to add
> Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com>
> > 
> > Changes since v2:
> > - New patch, to allow moving implementation to platform driver
> > 
> >   drivers/scsi/ufs/ufshcd.c | 6 ++++++
> >   drivers/scsi/ufs/ufshcd.h | 8 ++++++++
> >   2 files changed, 14 insertions(+)
> > 
> > diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
> > index 04d3686511c8..ee895a625456 100644
> > --- a/drivers/scsi/ufs/ufshcd.c
> > +++ b/drivers/scsi/ufs/ufshcd.c
> > @@ -6191,6 +6191,9 @@ static int ufshcd_reset_and_restore(struct ufs_hba *hba)
> >   	int retries = MAX_HOST_RESET_RETRIES;
> >   
> >   	do {
> > +		/* Reset the attached device */
> > +		ufshcd_vops_device_reset(hba);
> > +
> >   		err = ufshcd_host_reset_and_restore(hba);
> >   	} while (err && --retries);
> >   
> > @@ -8322,6 +8325,9 @@ int ufshcd_init(struct ufs_hba *hba, void __iomem *mmio_base, unsigned int irq)
> >   		goto exit_gating;
> >   	}
> >   
> > +	/* Reset the attached device */
> > +	ufshcd_vops_device_reset(hba);
> > +
> >   	/* Host controller enable */
> >   	err = ufshcd_hba_enable(hba);
> >   	if (err) {
> > diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
> > index 994d73d03207..cd8139052ed6 100644
> > --- a/drivers/scsi/ufs/ufshcd.h
> > +++ b/drivers/scsi/ufs/ufshcd.h
> > @@ -298,6 +298,7 @@ struct ufs_pwr_mode_info {
> >    * @resume: called during host controller PM callback
> >    * @dbg_register_dump: used to dump controller debug information
> >    * @phy_initialization: used to initialize phys
> > + * @device_reset: called to issue a reset pulse on the UFS device
> >    */
> >   struct ufs_hba_variant_ops {
> >   	const char *name;
> > @@ -326,6 +327,7 @@ struct ufs_hba_variant_ops {
> >   	int     (*resume)(struct ufs_hba *, enum ufs_pm_op);
> >   	void	(*dbg_register_dump)(struct ufs_hba *hba);
> >   	int	(*phy_initialization)(struct ufs_hba *);
> > +	void	(*device_reset)(struct ufs_hba *);
> >   };
> >   
> >   /* clock gating state  */
> > @@ -1045,6 +1047,12 @@ static inline void ufshcd_vops_dbg_register_dump(struct ufs_hba *hba)
> >   		hba->vops->dbg_register_dump(hba);
> >   }
> >   
> > +static inline void ufshcd_vops_device_reset(struct ufs_hba *hba)
> > +{
> > +	if (hba->vops && hba->vops->device_reset)
> > +		hba->vops->device_reset(hba);
> > +}
> > +
> >   extern struct ufs_pm_lvl_states ufs_pm_lvl_states[];
> >   
> >   /*
> > 

  reply	other threads:[~2019-06-26  3:48 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-08  5:04 [PATCH v3 0/3] Qualcomm UFS device reset support Bjorn Andersson
2019-06-08  5:04 ` [PATCH v3 1/3] scsi: ufs: Introduce vops for resetting device Bjorn Andersson
2019-06-25 12:41   ` Alim Akhtar
2019-06-26  3:45     ` Bjorn Andersson [this message]
2019-06-08  5:04 ` [PATCH v3 2/3] scsi: ufs-qcom: Implement device_reset vops Bjorn Andersson
2019-06-11 16:08   ` [EXT] " Bean Huo (beanhuo)
2019-06-12  6:31     ` Bjorn Andersson
2019-06-14  7:42       ` Bean Huo (beanhuo)
2019-06-08  5:04 ` [PATCH v3 3/3] arm64: dts: qcom: sdm845-mtp: Specify UFS device-reset GPIO Bjorn Andersson

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=20190626034529.GE24205@tuxbook-pro \
    --to=bjorn.andersson@linaro.org \
    --cc=agross@kernel.org \
    --cc=alim.akhtar@samsung.com \
    --cc=avri.altman@wdc.com \
    --cc=devicetree@vger.kernel.org \
    --cc=jejb@linux.ibm.com \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=martin.petersen@oracle.com \
    --cc=pedrom.sousa@synopsys.com \
    --cc=robh+dt@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).