Received: by 2002:a05:6a10:17d3:0:0:0:0 with SMTP id hz19csp197758pxb; Fri, 16 Apr 2021 03:24:05 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzkH5H/DzaPUqPjEr3PY5jsNUJ4+LTQZ0KbG9NQ4TpeKQsFEY0XeO4husdSpXwZxNkbDU25 X-Received: by 2002:a17:906:fca1:: with SMTP id qw1mr7561748ejb.478.1618568644978; Fri, 16 Apr 2021 03:24:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1618568644; cv=none; d=google.com; s=arc-20160816; b=Hcdobmvg06Zg6K31yltInibvSS51yvFuKoEt4PHJusWGTna2VdqCP25Xvos1eRiK8a MN0UeVKpOG8B637ID5j2kpwTjMOUbfUJ4O/wTPkCAnRLxw1K8WubZSGGhTb9QBMda746 EFutry7s3OTIJpOdg4C8v1QK53JHE9O/S39EdrSxUg4hkBuNBokolwpYV+BPbhj2ivjh 1ES49Tph3+c0vkSrlnViMnkfmt3F7FiqZ16N8f4qgQ+qtPJwhLHl6CPw97qZIKv3wIho j3/pfeLVlnNRiqHkQ2d8Iz1WKXKMzRUCTKA71y4pVOxLkeet7dRE6arQU+yAmEDfrDpr WyBg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:organization :from:references:cc:to:subject:ironport-sdr:ironport-sdr; bh=TxiyJSGM/f4gXdgVEErKSxpSxs9YkxRZ/vyj2Uebt+M=; b=N9p/t+DYuXOyZD7fIkEvIkcdCcSOGuAyF600JuMKbGYSoIZAUnkTKLYQbkX3lhgpcG qQEaiCIHUHi7uaOfAF6t4KnR0616cdgozAo4oa3lU7J825uWlh1R8s5juisF0POGURTh O8ZgWylE06Kxh6eI45MNPPxb1/LthC9gRf0c+vdvlZ3MwD4XJHoMviC9LU9sSacdMBmk F4NTqUNqJsh3JLzkFlFrYeIi16g8ZE8WQn2R5YdcFXJ2fINzPKli5iXpLdthafBeu6Qs toyGUaD2T6s8fSBRLSew6H6U4s9/Jkh02DKi0fdKu4fEpLRZprKlXip0x8R573GVbVBu 8BDw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id i8si4775992edc.591.2021.04.16.03.23.41; Fri, 16 Apr 2021 03:24:04 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240110AbhDPJXO (ORCPT + 99 others); Fri, 16 Apr 2021 05:23:14 -0400 Received: from mga17.intel.com ([192.55.52.151]:58379 "EHLO mga17.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234312AbhDPJXN (ORCPT ); Fri, 16 Apr 2021 05:23:13 -0400 IronPort-SDR: WJS2rHIfUiPN7+MZwZZVyM1jvMgSkm79nbKMpLwQWe0I6KQdjqtnYQjerC0zTcOq5DX7JOwJLp udv25I3wnf1A== X-IronPort-AV: E=McAfee;i="6200,9189,9955"; a="175122145" X-IronPort-AV: E=Sophos;i="5.82,226,1613462400"; d="scan'208";a="175122145" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Apr 2021 02:22:49 -0700 IronPort-SDR: LTD0pPovf9LjGKkamh7GgF4XV/IKF+D+L90RasUrL15smP1ANlzLBKOzFST/j8Nljx+LMCUYWA hnVETrRrlDAQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.82,226,1613462400"; d="scan'208";a="461914819" Received: from ahunter-desktop.fi.intel.com (HELO [10.237.72.174]) ([10.237.72.174]) by orsmga001.jf.intel.com with ESMTP; 16 Apr 2021 02:22:40 -0700 Subject: Re: [PATCH v19 1/2] scsi: ufs: Enable power management for wlun To: Asutosh Das , cang@codeaurora.org, martin.petersen@oracle.com, linux-scsi@vger.kernel.org Cc: linux-arm-msm@vger.kernel.org, Alim Akhtar , Avri Altman , "James E.J. Bottomley" , Krzysztof Kozlowski , Stanley Chu , Andy Gross , Bjorn Andersson , Steven Rostedt , Ingo Molnar , Matthias Brugger , Lee Jones , Bean Huo , Kiwoong Kim , Colin Ian King , Yue Hu , Wei Yongjun , "Gustavo A. R. Silva" , Dinghao Liu , Jaegeuk Kim , Satya Tangirala , open list , "moderated list:ARM/SAMSUNG S3C, S5P AND EXYNOS ARM ARCHITECTURES" , "open list:ARM/SAMSUNG S3C, S5P AND EXYNOS ARM ARCHITECTURES" , "moderated list:UNIVERSAL FLASH STORAGE HOST CONTROLLER DRIVER..." References: <48ab92db5b0d3c11b8357f0faa99a4473465099d.1618529652.git.asutoshd@codeaurora.org> From: Adrian Hunter Organization: Intel Finland Oy, Registered Address: PL 281, 00181 Helsinki, Business Identity Code: 0357606 - 4, Domiciled in Helsinki Message-ID: Date: Fri, 16 Apr 2021 12:22:52 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <48ab92db5b0d3c11b8357f0faa99a4473465099d.1618529652.git.asutoshd@codeaurora.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 16/04/21 2:36 am, Asutosh Das wrote: > During runtime-suspend of ufs host, the scsi devices are > already suspended and so are the queues associated with them. > But the ufs host sends SSU (START_STOP_UNIT) to wlun > during its runtime-suspend. > During the process blk_queue_enter checks if the queue is not in > suspended state. If so, it waits for the queue to resume, and never > comes out of it. > The commit > (d55d15a33: scsi: block: Do not accept any requests while suspended) > adds the check if the queue is in suspended state in blk_queue_enter(). > > Call trace: > __switch_to+0x174/0x2c4 > __schedule+0x478/0x764 > schedule+0x9c/0xe0 > blk_queue_enter+0x158/0x228 > blk_mq_alloc_request+0x40/0xa4 > blk_get_request+0x2c/0x70 > __scsi_execute+0x60/0x1c4 > ufshcd_set_dev_pwr_mode+0x124/0x1e4 > ufshcd_suspend+0x208/0x83c > ufshcd_runtime_suspend+0x40/0x154 > ufshcd_pltfrm_runtime_suspend+0x14/0x20 > pm_generic_runtime_suspend+0x28/0x3c > __rpm_callback+0x80/0x2a4 > rpm_suspend+0x308/0x614 > rpm_idle+0x158/0x228 > pm_runtime_work+0x84/0xac > process_one_work+0x1f0/0x470 > worker_thread+0x26c/0x4c8 > kthread+0x13c/0x320 > ret_from_fork+0x10/0x18 > > Fix this by registering ufs device wlun as a scsi driver and > registering it for block runtime-pm. Also make this as a > supplier for all other luns. That way, this device wlun > suspends after all the consumers and resumes after > hba resumes. > This also registers a new scsi driver for rpmb wlun. > This new driver is mostly used to clear rpmb uac. > With this design, the driver would always be runtime resumed > before system suspend. I thought some more about that and I think we can still support allowing runtime suspend to work with system suspend, without too much difficulty. See ufshcd_suspend_prepare() below. > > Fixed smatch warnings: > Reported-by: kernel test robot > Reported-by: Dan Carpenter > > Co-developed-by: Can Guo > Signed-off-by: Can Guo > Signed-off-by: Asutosh Das > --- > -static int ufshcd_resume(struct ufs_hba *hba, enum ufs_pm_op pm_op) > +static int __ufshcd_wl_resume(struct ufs_hba *hba, enum ufs_pm_op pm_op) > { > int ret; > - enum uic_link_state old_link_state; > + enum uic_link_state old_link_state = hba->uic_link_state; > > - hba->pm_op_in_progress = 1; > - old_link_state = hba->uic_link_state; > - > - ufshcd_hba_vreg_set_hpm(hba); > - ret = ufshcd_vreg_set_hpm(hba); > - if (ret) > - goto out; > - > - /* Make sure clocks are enabled before accessing controller */ > - ret = ufshcd_setup_clocks(hba, true); > - if (ret) > - goto disable_vreg; > - > - /* enable the host irq as host controller would be active soon */ > - ufshcd_enable_irq(hba); > + hba->pm_op_in_progress = true; > > /* > * Call vendor specific resume callback. As these callbacks may access > @@ -8868,7 +8858,7 @@ static int ufshcd_resume(struct ufs_hba *hba, enum ufs_pm_op pm_op) > */ > ret = ufshcd_vops_resume(hba, pm_op); > if (ret) > - goto disable_irq_and_vops_clks; > + goto out; > > /* For DeepSleep, the only supported option is to have the link off */ > WARN_ON(ufshcd_is_ufs_dev_deepsleep(hba) && !ufshcd_is_link_off(hba)); > @@ -8916,42 +8906,219 @@ static int ufshcd_resume(struct ufs_hba *hba, enum ufs_pm_op pm_op) > if (hba->ee_usr_mask) > ufshcd_write_ee_control(hba); > > - hba->clk_gating.is_suspended = false; > - > if (ufshcd_is_clkscaling_supported(hba)) > - ufshcd_clk_scaling_suspend(hba, false); > - > - /* Enable Auto-Hibernate if configured */ > - ufshcd_auto_hibern8_enable(hba); > + ufshcd_resume_clkscaling(hba); This still doesn't look right. ufshcd_resume_clkscaling() doesn't update hba->clk_scaling.is_allowed whereas ufshcd_clk_scaling_suspend() does. > > if (hba->dev_info.b_rpm_dev_flush_capable) { > hba->dev_info.b_rpm_dev_flush_capable = false; > cancel_delayed_work(&hba->rpm_dev_flush_recheck_work); > } > > - ufshcd_clear_ua_wluns(hba); > - > - /* Schedule clock gating in case of no access to UFS device yet */ > - ufshcd_release(hba); > - > + /* Enable Auto-Hibernate if configured */ > + ufshcd_auto_hibern8_enable(hba); > goto out; > > set_old_link_state: > ufshcd_link_state_transition(hba, old_link_state, 0); > vendor_suspend: > ufshcd_vops_suspend(hba, pm_op); > -disable_irq_and_vops_clks: > +out: > + if (ret) > + ufshcd_update_evt_hist(hba, UFS_EVT_WL_RES_ERR, (u32)ret); > + hba->clk_gating.is_suspended = false; > + ufshcd_release(hba); > + hba->pm_op_in_progress = false; > + return ret; > +} > +void ufshcd_resume_complete(struct device *dev) > +{ > + struct ufs_hba *hba = dev_get_drvdata(dev); > + > + ufshcd_rpm_put(hba); > +} > +EXPORT_SYMBOL_GPL(ufshcd_resume_complete); > + > +int ufshcd_suspend_prepare(struct device *dev) > +{ > + struct ufs_hba *hba = dev_get_drvdata(dev); > + > + /* > + * SCSI assumes that runtime-pm and system-pm for scsi drivers > + * are same. And it doesn't wake up the device for system-suspend > + * if it's runtime suspended. But ufs doesn't follow that. > + * The rpm-lvl and spm-lvl can be different in ufs. > + * Force it to honor system-suspend. > + * Refer ufshcd_resume_complete() > + */ > + ufshcd_rpm_get_sync(hba); > + > + return 0; > +} I think we can support allowing runtime suspend to work with system suspend. ufshcd_resume_complete() remains the same, and ufshcd_suspend_prepare() is like this: /* * SCSI assumes that runtime-pm and system-pm for scsi drivers are same, and it * doesn't wake up the device for system-suspend if it's runtime suspended. * However UFS doesn't follow that. The rpm-lvl and spm-lvl can be different in * UFS, so special care is needed. * Refer also ufshcd_resume_complete() */ int ufshcd_suspend_prepare(struct device *dev) { struct ufs_hba *hba = dev_get_drvdata(dev); struct device *ufs_dev = &hba->sdev_ufs_device->sdev_gendev; enum ufs_dev_pwr_mode spm_pwr_mode; enum uic_link_state spm_link_state; unsigned long flags; bool rpm_state_ok; /* * First prevent runtime suspend. Note this does not prevent runtime * resume e.g. pm_runtime_get_sync() will still do the right thing. */ pm_runtime_get_noresume(ufs_dev); /* Now check if the rpm state is ok to use for spm */ spin_lock_irqsave(&ufs_dev->power.lock, flags); spm_pwr_mode = ufs_get_pm_lvl_to_dev_pwr_mode(hba->spm_lvl); spm_link_state = ufs_get_pm_lvl_to_link_pwr_state(hba->spm_lvl); rpm_state_ok = pm_runtime_suspended(ufs_dev) && hba->curr_dev_pwr_mode == spm_pwr_mode && hba->uic_link_state == spm_link_state && !hba->dev_info.b_rpm_dev_flush_capable; spin_unlock_irqrestore(&ufs_dev->power.lock, flags); /* If is isn't, do a runtime resume */ if (!rpm_state_ok) pm_runtime_resume(ufs_dev); return 0; }