From: Stanley Chu <stanley.chu@mediatek.com>
To: Can Guo <cang@codeaurora.org>
Cc: alim.akhtar@samsung.com, beanhuo@micron.com, bvanassche@acm.org,
linux-scsi@vger.kernel.org, peter.wang@mediatek.com,
cc.chou@mediatek.com, andy.teng@mediatek.com, jejb@linux.ibm.com,
chun-hung.wu@mediatek.com, ron.hsu@mediatek.com,
avri.altman@wdc.com, linux-mediatek@lists.infradead.org,
linux-scsi-owner@vger.kernel.org, matthias.bgg@gmail.com,
linux-arm-kernel@lists.infradead.org, martin.petersen@oracle.com,
kuohong.wang@mediatek.com, linux-kernel@vger.kernel.org,
stable@vger.kernel.org, subhashj@codeaurora.org,
pedrom.sousa@synopsys.com, asutoshd@codeaurora.org
Subject: Re: [PATCH v1 1/2] scsi: ufs: set device as default active power mode during initialization only
Date: Thu, 2 Jan 2020 14:38:44 +0800 [thread overview]
Message-ID: <1577947124.13164.75.camel@mtkswgap22> (raw)
In-Reply-To: <44393ed9ff3ba9878bae838307e7eec0@codeaurora.org>
Hi Can,
On Tue, 2019-12-31 at 16:35 +0800, Can Guo wrote:
> Hi Stanley,
>
> I missed this mail before I hit send. In current code, as per my
> understanding,
> UFS device's power state should be Active after ufshcd_link_startup()
> returns.
> If I am wrong, please feel free to correct me.
>
Yes, this assumption of ufshcd_probe_hba() is true so I will drop this
patch.
Thanks for remind.
> Due to you are almost trying to revert commit 7caf489b99a42a, I am just
> wondering
> if you encounter failure/error caused by it.
Yes, we actually have some doubts from the commit message of "scsi: ufs:
issue link startup 2 times if device isn't active"
If we configured system suspend as device=PowerDown/Link=LinkDown mode,
during resume, the 1st link startup will be successful, and after that
device could be accessed normally so it shall be already in Active power
mode. We did not find devices which need twice linkup for normal work.
And because the 1st linkup is OK, the forced 2nd linkup by commit "scsi:
ufs: issue link startup 2 times if device isn't active" leads to link
lost and finally the 3rd linkup is made again by retry mechanism in
ufshcd_link_startup() and be successful. So a linkup performance issue
is introduced here: We actually need one-time linkup only but finally
got 3 linkup operations.
According to the UFS spec, all reset types (including POR and Host
UniPro Warm Reset which both may happen in above configurations) other
than LU reset, UFS device power mode shall return to Sleep mode or
Active mode depending on bInitPowerMode, by default, it's Active mode.
So we are curious that why enforcing twice linkup is necessary here?
Could you kindly help us clarify this?
If anything wrong in above description, please feel free to correct me.
>
> Happy new year to you too!
>
> Thanks,
>
> Can Guo
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
next prev parent reply other threads:[~2020-01-02 6:38 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
2019-12-31 8:35 ` Can Guo
2020-01-02 6:38 ` Stanley Chu [this message]
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=1577947124.13164.75.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=cc.chou@mediatek.com \
--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=ron.hsu@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).