linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stanley Chu <stanley.chu@mediatek.com>
To: Can Guo <cang@codeaurora.org>
Cc: <linux-scsi-owner@vger.kernel.org>, <linux-scsi@vger.kernel.org>,
	<martin.petersen@oracle.com>, <subhashj@codeaurora.org>,
	<jejb@linux.ibm.com>, <chun-hung.wu@mediatek.com>,
	<kuohong.wang@mediatek.com>, <linux-kernel@vger.kernel.org>,
	<stable@vger.kernel.org>, <avri.altman@wdc.com>,
	<linux-mediatek@lists.infradead.org>, <peter.wang@mediatek.com>,
	<alim.akhtar@samsung.com>, <andy.teng@mediatek.com>,
	<matthias.bgg@gmail.com>, <beanhuo@micron.com>,
	<pedrom.sousa@synopsys.com>, <bvanassche@acm.org>,
	<linux-arm-kernel@lists.infradead.org>, <asutoshd@codeaurora.org>
Subject: Re: [PATCH v1 1/2] scsi: ufs: set device as default active power mode during initialization only
Date: Tue, 31 Dec 2019 15:44:50 +0800	[thread overview]
Message-ID: <1577778290.13164.45.camel@mtkswgap22> (raw)
In-Reply-To: <1577766179.13164.24.camel@mtkswgap22>

Hi Can,

On Tue, 2019-12-31 at 12:22 +0800, Stanley Chu wrote:
> Hi Can,
> 
> 
> > Hi Stanley,
> > 
> > I see skipping ufshcd_set_ufs_dev_active() in ufshcd_probe_hba()
> > if it is called from ufshcd_resume() path is the purpose here.
> > 
> > If so, then ufshcd_set_dev_pwr_mode() would be called, meaning
> > SSU command will be sent. Why is this SSU command needed to be
> > sent after a full host reset and restore? Is ufshcd_probe_hba()
> > not enough to make UFS device fully functional?
> 
> After resume (for both runtime resume and system resume), device power
> mode shall be back to "Active" to service incoming requests.
> 
> I see two cases need device power mode transition during resume flow
> 1. Device Power Mode = Sleep
> 2. Device Power Mode = PowerDown
> 
> For 1, ufshcd_probe_hba() is not invoked during resume flow,
> hba->curr_dev_pwr_mode = SLEEP, thus ufshcd_resume() can invoke
> ufshcd_set_dev_pwr_mode() to change device power mode.
> 
> For 2, ufshcd_probe_hba() is invoked during resume flow, before this
> fix, hba->curr_dev_pwr_mode will be set to ACTIVE (note that only this
> flag is set as ACTIVE, but device may be still in PowerDown state if
> device power is not fully shutdown or device HW reset is not executed
> before resume), in the end, ufshcd_resume() will not invoke
> ufshcd_set_dev_pwr_mode() to send SSU command to make device change back
> to Active power mode.
> 
> But if device is fully reset before resume (not by current mainstream
> driver), device can be already in "Active" power mode after power on
> again during resume flow. In this case, it is OK to set
> hba->curr_dev_pwr_mode as ACTIVE in ufshcd_probe_hba() and SSU command
> is not necessary.
> 
> Thanks,
> Stanley

I think currently the assumption in ufshcd_probe_hba() that "device
shall be already in Active power mode" makes sense because many device
commands will be sent to device in ufshcd_probe_hba() but device is not
promised to handle those commands in PowerDown power mode according to
UFS spec. 

So, maybe always ensuring device being Active power mode before leaving
ufshcd_probe_hba() is more reasonable. If so, I will drop this patch
first.

Thanks so much for your reviews.

Happy new year!

Thanks,
Stanley




  reply	other threads:[~2019-12-31  7:45 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-30  8:12 [PATCH v1 0/2] scsi: ufs: fix device power mode during PM flow Stanley Chu
2019-12-30  8:12 ` [PATCH v1 1/2] scsi: ufs: set device as default active power mode during initialization only Stanley Chu
2019-12-30 23:24   ` asutoshd
2019-12-31  1:07     ` Stanley Chu
2019-12-31  2:13       ` Can Guo
2019-12-31  4:22         ` Stanley Chu
2019-12-31  7:44           ` Stanley Chu [this message]
2019-12-31  8:35             ` Can Guo
2020-01-02  6:38               ` Stanley Chu
2020-01-03  1:51                 ` Can Guo
2020-01-03  5:28                   ` Can Guo
2020-01-17  7:57                     ` Stanley Chu
2020-01-05  7:55                 ` Avri Altman
2019-12-31  8:05           ` Can Guo
2019-12-30  8:12 ` [PATCH v1 2/2] scsi: ufs: remove link_startup_again flow in ufshcd_link_startup Stanley Chu

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=1577778290.13164.45.camel@mtkswgap22 \
    --to=stanley.chu@mediatek.com \
    --cc=alim.akhtar@samsung.com \
    --cc=andy.teng@mediatek.com \
    --cc=asutoshd@codeaurora.org \
    --cc=avri.altman@wdc.com \
    --cc=beanhuo@micron.com \
    --cc=bvanassche@acm.org \
    --cc=cang@codeaurora.org \
    --cc=chun-hung.wu@mediatek.com \
    --cc=jejb@linux.ibm.com \
    --cc=kuohong.wang@mediatek.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=linux-scsi-owner@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=matthias.bgg@gmail.com \
    --cc=pedrom.sousa@synopsys.com \
    --cc=peter.wang@mediatek.com \
    --cc=stable@vger.kernel.org \
    --cc=subhashj@codeaurora.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).