[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a36d111e-ef7f-9f9b-6f6a-692a9980103a@codeaurora.org>
Date: Tue, 17 Dec 2019 15:25:27 -0800
From: "Asutosh Das (asd)" <asutoshd@...eaurora.org>
To: Stanley Chu <stanley.chu@...iatek.com>, linux-scsi@...r.kernel.org,
martin.petersen@...cle.com, avri.altman@....com,
alim.akhtar@...sung.com, pedrom.sousa@...opsys.com,
jejb@...ux.ibm.com, matthias.bgg@...il.com
Cc: linux-mediatek@...ts.infradead.org,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
beanhuo@...ron.com, kuohong.wang@...iatek.com,
peter.wang@...iatek.com, chun-hung.wu@...iatek.com,
andy.teng@...iatek.com
Subject: Re: [PATCH v1 2/2] scsi: ufs: disable interrupt during clock-gating
On 12/7/2019 4:22 AM, Stanley Chu wrote:
> Similar to suspend, ufshcd interrupt can be disabled since
> there won't be any host controller transaction expected till
> clocks ungated.
>
> Signed-off-by: Stanley Chu <stanley.chu@...iatek.com>
> ---
> drivers/scsi/ufs/ufshcd.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
> index f80bd4e811cb..5de105e82c32 100644
> --- a/drivers/scsi/ufs/ufshcd.c
> +++ b/drivers/scsi/ufs/ufshcd.c
> @@ -1490,6 +1490,8 @@ static void ufshcd_ungate_work(struct work_struct *work)
> spin_unlock_irqrestore(hba->host->host_lock, flags);
> ufshcd_setup_clocks(hba, true);
>
> + ufshcd_enable_irq(hba);
> +
> /* Exit from hibern8 */
> if (ufshcd_can_hibern8_during_gating(hba)) {
> /* Prevent gating in this path */
> @@ -1636,6 +1638,8 @@ static void ufshcd_gate_work(struct work_struct *work)
> ufshcd_set_link_hibern8(hba);
> }
>
> + ufshcd_disable_irq(hba);
> +
> if (!ufshcd_is_link_active(hba))
> ufshcd_setup_clocks(hba, false);
> else
>
Hi,
Does this save significant power? I see that gate/ungate of clocks
happen far too frequently than suspend/resume.
Have you considered how much latency this would add to the
gating/ungating path?
-asd
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
Linux Foundation Collaborative Project
Powered by blists - more mailing lists