All of lore.kernel.org
 help / color / mirror / Atom feed
From: Avri Altman <Avri.Altman@wdc.com>
To: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: John Stultz <john.stultz@linaro.org>,
	Andy Gross <agross@kernel.org>,
	Linus Walleij <linus.walleij@linaro.org>,
	Rob Herring <robh+dt@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Pedro Sousa <pedrom.sousa@synopsys.com>,
	"James E.J. Bottomley" <jejb@linux.ibm.com>,
	"Martin K. Petersen" <martin.petersen@oracle.com>,
	"linux-arm-msm@vger.kernel.org" <linux-arm-msm@vger.kernel.org>,
	"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>
Subject: RE: [PATCH 0/3] (Qualcomm) UFS device reset support
Date: Wed, 5 Jun 2019 09:32:32 +0000	[thread overview]
Message-ID: <SN6PR04MB492521B7D2DB6F3462EDB7D9FC160@SN6PR04MB4925.namprd04.prod.outlook.com> (raw)
In-Reply-To: <20190605060154.GJ22737@tuxbook-pro>

> 
> On Tue 04 Jun 22:50 PDT 2019, Avri Altman wrote:
> 
> > Hi,
> >
> > >
> > > On Tue, Jun 4, 2019 at 12:22 AM Bjorn Andersson
> > > <bjorn.andersson@linaro.org> wrote:
> > > >
> > > > This series exposes the ufs_reset line as a gpio, adds support for ufshcd to
> > > > acquire and toggle this and then adds this to SDM845 MTP.
> > > >
> > > > Bjorn Andersson (3):
> > > >   pinctrl: qcom: sdm845: Expose ufs_reset as gpio
> > > >   scsi: ufs: Allow resetting the UFS device
> > > >   arm64: dts: qcom: sdm845-mtp: Specify UFS device-reset GPIO
> > >
> > > Adding similar change as in sdm845-mtp to the not yet upstream
> > > blueline dts, I validated this allows my micron UFS pixel3 to boot.
> > >
> > > Tested-by: John Stultz <john.stultz@linaro.org>
> > Maybe ufs_hba_variant_ops would be the proper place to add this?
> >
> 
> Are you saying that these memories only need a reset when they are
> paired with the Qualcomm host controller?
ufs_hba_variant_ops is for vendors to implement their own vops,
and as you can see, many of them do.
Adding hw_reset to that template seems like the proper way
to do what you are doing.

Thanks,
Avri
> 
> The way it's implemented it here is that the device-reset GPIO is
> optional and only if you specify it we'll toggle the reset. So if your
> board design has a UFS memory that requires a reset pulse during
> initialization you specify this, regardless of which vendor your SoC
> comes from.
> 
> Regards,
> Bjorn

  reply	other threads:[~2019-06-05  9:32 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-04  7:19 [PATCH 0/3] (Qualcomm) UFS device reset support Bjorn Andersson
2019-06-04  7:19 ` Bjorn Andersson
2019-06-04  7:19 ` [PATCH 1/3] pinctrl: qcom: sdm845: Expose ufs_reset as gpio Bjorn Andersson
2019-06-07 21:26   ` Linus Walleij
2019-06-07 21:26     ` Linus Walleij
2019-06-04  7:20 ` [PATCH 2/3] scsi: ufs: Allow resetting the UFS device Bjorn Andersson
2019-06-04  7:53   ` Marc Gonzalez
2019-06-04 22:14     ` Bjorn Andersson
2019-06-07 10:41     ` Alim Akhtar
2019-06-07 18:27       ` Bjorn Andersson
2019-06-04  8:13   ` [EXT] " Bean Huo (beanhuo)
2019-06-04 18:10     ` John Stultz
2019-06-04 22:30     ` Bjorn Andersson
2019-06-05 21:17       ` Bean Huo (beanhuo)
2019-06-04 15:25   ` Stephen Boyd
2019-06-04 22:20     ` Bjorn Andersson
2019-06-04  7:20 ` [PATCH 3/3] arm64: dts: qcom: sdm845-mtp: Specify UFS device-reset GPIO Bjorn Andersson
2019-06-04 16:22   ` Stephen Boyd
2019-06-04 22:09     ` Bjorn Andersson
2019-06-07 22:20   ` Linus Walleij
2019-06-07 22:20     ` Linus Walleij
2019-06-04 22:00 ` [PATCH 0/3] (Qualcomm) UFS device reset support John Stultz
2019-06-05  5:50   ` Avri Altman
2019-06-05  6:01     ` Bjorn Andersson
2019-06-05  9:32       ` Avri Altman [this message]
2019-06-06  0:39         ` Bjorn Andersson
2019-06-06  6:32           ` Avri Altman
2019-06-06  7:09             ` 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=SN6PR04MB492521B7D2DB6F3462EDB7D9FC160@SN6PR04MB4925.namprd04.prod.outlook.com \
    --to=avri.altman@wdc.com \
    --cc=agross@kernel.org \
    --cc=bjorn.andersson@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=jejb@linux.ibm.com \
    --cc=john.stultz@linaro.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-gpio@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 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.