All of lore.kernel.org
 help / color / mirror / Atom feed
From: Can Guo <cang@codeaurora.org>
To: Bean Huo <huobean@gmail.com>
Cc: asutoshd@codeaurora.org, nguyenb@codeaurora.org,
	hongwus@codeaurora.org, rnayak@codeaurora.org,
	linux-scsi@vger.kernel.org, kernel-team@android.com,
	saravanak@google.com, salyzyn@google.com,
	Alim Akhtar <alim.akhtar@samsung.com>,
	Avri Altman <avri.altman@wdc.com>,
	"James E.J. Bottomley" <jejb@linux.ibm.com>,
	"Martin K. Petersen" <martin.petersen@oracle.com>,
	Stanley Chu <stanley.chu@mediatek.com>,
	Bean Huo <beanhuo@micron.com>,
	Bart Van Assche <bvanassche@acm.org>,
	Satya Tangirala <satyat@google.com>,
	open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/2] scsi: ufs: Protect some contexts from unexpected clock scaling
Date: Fri, 11 Dec 2020 19:13:01 +0800	[thread overview]
Message-ID: <cecf35ca445e175aacb1c2942a74951e@codeaurora.org> (raw)
In-Reply-To: <48363aee8a746a43440f86f620d9d2e0@codeaurora.org>

On 2020-12-11 09:36, Can Guo wrote:
> On 2020-12-11 01:34, Bean Huo wrote:
>> Hi Can
>> 
>> On Wed, 2020-12-09 at 05:35 -0800, Can Guo wrote:
>>> 
>>> 
>>> @@ -1160,6 +1166,7 @@ static void
>>> ufshcd_clock_scaling_unprepare(struct ufs_hba *hba)
>>>  {
>>>  	up_write(&hba->clk_scaling_lock);
>>>  	ufshcd_scsi_unblock_requests(hba);
>>> +	ufshcd_release(hba);
>>>  }
>>> 
>>>  /**
>>> @@ -1175,12 +1182,9 @@ static int ufshcd_devfreq_scale(struct ufs_hba
>>> *hba, bool scale_up)
>>>  {
>>>  	int ret = 0;
>>> 
>>> -	/* let's not get into low power until clock scaling is
>>> completed */
>>> -	ufshcd_hold(hba, false);
>>> -
>>>  	ret = ufshcd_clock_scaling_prepare(hba);
>>>  	if (ret)
>>> -		goto out;
>>> +		return ret;
>>> 
>>>  	/* scale down the gear before scaling down clocks */
>>>  	if (!scale_up) {
>>> @@ -1212,8 +1216,6 @@ static int ufshcd_devfreq_scale(struct ufs_hba
>>> *hba, bool scale_up)
>>> 
>>>  out_unprepare:
>>>  	ufshcd_clock_scaling_unprepare(hba);
>>> -out:
>>> -	ufshcd_release(hba);
>>>  	return ret;
>>>  }
>> 
>> I didn't understand why moving ufshcd_hold/ufshcd_release into
>> ufshcd_clock_scaling_prepare()/ufshcd_clock_scaling_unprepare().
>> 
>> 
>>> 
>>> @@ -1294,15 +1296,8 @@ static int ufshcd_devfreq_target(struct device
>>> *dev,
>>>  	}
>>>  	spin_unlock_irqrestore(hba->host->host_lock, irq_flags);
>>> 
>>> -	pm_runtime_get_noresume(hba->dev);
>>> -	if (!pm_runtime_active(hba->dev)) {
>>> -		pm_runtime_put_noidle(hba->dev);
>>> -		ret = -EAGAIN;
>>> -		goto out;
>>> -	}
>>>  	start = ktime_get();
>>>  	ret = ufshcd_devfreq_scale(hba, scale_up);
>>> -	pm_runtime_put(hba->dev);
>>> 
>> 
>> which branch are you working on?  I didn't see this part codes in the
>> branch 5.11/scsi-queue and 5.11/scsi-staging.
>> 
>> Bean
> 
> As I mentioned in my cover-letter, this is based on 5.11/scsi-fixes.
> These codes came from one of my earlier changes, but since this change
> can cover the old change's functionality, so I removed the codes.
> 
> Can Guo.

Hi Bean,

Sorry for the typo, it is branch 5.10/scsi-fixes.

Thanks,

Can Guo.

  reply	other threads:[~2020-12-11 11:15 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-09 13:35 [PATCH v2 0/2] Two changes related with UFS clock scaling Can Guo
2020-12-09 13:35 ` [PATCH 1/2] scsi: ufs: Protect some contexts from unexpected " Can Guo
2020-12-10 17:34   ` Bean Huo
2020-12-11  1:09     ` Can Guo
2020-12-11  1:36     ` Can Guo
2020-12-11 11:13       ` Can Guo [this message]
2020-12-09 13:35 ` [PATCH 2/2] scsi: ufs: Clean up ufshcd_exit_clk_scaling/gating() Can Guo
2020-12-10 18:03   ` Bean Huo
2020-12-11  1:11     ` Can Guo

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=cecf35ca445e175aacb1c2942a74951e@codeaurora.org \
    --to=cang@codeaurora.org \
    --cc=alim.akhtar@samsung.com \
    --cc=asutoshd@codeaurora.org \
    --cc=avri.altman@wdc.com \
    --cc=beanhuo@micron.com \
    --cc=bvanassche@acm.org \
    --cc=hongwus@codeaurora.org \
    --cc=huobean@gmail.com \
    --cc=jejb@linux.ibm.com \
    --cc=kernel-team@android.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=nguyenb@codeaurora.org \
    --cc=rnayak@codeaurora.org \
    --cc=salyzyn@google.com \
    --cc=saravanak@google.com \
    --cc=satyat@google.com \
    --cc=stanley.chu@mediatek.com \
    /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.