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

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

> _______________________________________________
> Linux-mediatek mailing list
> Linux-mediatek@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2019-12-31  4:23 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 [this message]
2019-12-31  7:44           ` Stanley Chu
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=1577766179.13164.24.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).