[Scilab-users] Xcos electrical simulation returns error "make: *** [Makelib:131: clean] Error 127"

[asd fgh]

Hello,

I am trying to run the 'RLC circuit' simulation which is in the 
demonstrations>xcos>electrical systems menu. But I am getting the following 
error in the console:
__
Main Modelica : 
C:\Users\monis\AppData\Local\Temp\SCI_TMP_11304_24317\RLC_Modelica_im.mo

 Flat Modelica : 
C:\Users\monis\AppData\Local\Temp\SCI_TMP_11304_24317\RLC_Modelica_imf.mo
 Simulation C code 
:C:\Users\monis\AppData\Local\Temp\SCI_TMP_11304_24317\RLC_Modelica_im.c
   Generate a loader file
   Generate a Makefile
   Running the Makefile
   Compilation of RLC_Modelica_im.obj
   Building shared library (be patient)

  "del *.bak"
  "/usr/bin/bash: line 1: del: command not found"
  "make: *** [Makelib:131: clean] Error 127"

  "sorry compiling problem"
  "ilib_compile: Error while executing Makelib."

  "c_pass1: build the modelica meta-block failed"

  "xcos_simulate: Error during block parameters update."
__

I am getting this error only for electrical systems other xcos systems are 
working fine. I was able to run electrical simulations without any problem a 
few weeks ago so I am not sure why it stopped working. I tried uninstalling and 
reinstalling Scilab but it didn't help. I am using Scilab 2024.0.0 and my 
operating system is Windows 11.
Any help would be appreciated.

Thank you,
Monish


This email and any attachments are intended solely for the use of the 
individual or entity to whom it is addressed and may be confidential and/or 
privileged.

If you are not one of the named recipients or have received this email in error,

(i) you should not read, disclose, or copy it,

(ii) please notify sender of your receipt by reply email and delete this email 
and all attachments,

(iii) Dassault Systèmes does not accept or assume any liability or 
responsibility for any use of or reliance on this email.


Please be informed that your personal data are processed according to our data 
privacy policy as described on our website. Should you have any questions 
related to personal data protection, please contact 3DS Data Protection Officer 
https://www.3ds.com/privacy-policy/contact/

___
users mailing list - users@lists.scilab.org
Click here to unsubscribe: 
https://lists.scilab.org/mailman/listinfo/users

[ED] La UDL - Uboldo Disc League indoor tournament

[ASD Frasba dal Lac via Eurodisc]

Who wants to play outdoor ultimate in mid-january in northern Italy?!
Exactly...

NO ONE!

After 20 years of activity, Frasba is organizing its first proper indoor
tournament and even we continue to ask ourselves why we didn't do it before.

You are all invited to join us and make this first edition memorable!

 WHEN
13th - 14th January 2024

 WHERE
Centro sportivo Rugbiolandia 2 - Via Alessandro Manzoni, 251, 21040 Uboldo
(VA)

 FORMAT
Indoor 5vs5 loose mixed tournament (1-2 women on the line)
Up to 12 teams (at least 8 players per team)

 COSTS
- team fee = 50 €
- player fee = 30 € (gadget + party + gym space for sleeping + breakfast
included)
- extra: lunches 7€ - dinner 15€ (to be reserved after registration)

REGISTRATION
Register here before 20/12/2023:
https://docs.google.com/forms/d/e/1FAIpQLSff0630EPhwIHCfauG9mmCYgU0wpybBshO-7ZovcnCHH9SJ-w/viewform

*⚠️ For those who register by December 8th, special gift included.*

朗 During the tournament there will also be a demonstration of Wheelchair
Ultimate and the opportunity to play Disc Golf.
ℹ️ INFO

FACEBOOK EVENT:
https://www.facebook.com/events/s/la-udl-uboldo-disc-league/335306542619549/

See you at the gym! ;-)

kinto and Frasba dal Lac

___
EuroDisc mailing list
eurodisc@eurodisc.email
https://eurodisc.email/mailman/listinfo/eurodisc
https://frisbeesport.de/thgries/disc/eurodisc.html

[Discover] [Bug 472673] New: Discover se cierra al iniciar

[asd]

https://bugs.kde.org/show_bug.cgi?id=472673

Bug ID: 472673
   Summary: Discover se cierra al iniciar
Classification: Applications
   Product: Discover
   Version: 5.27.5
  Platform: Debian stable
OS: Linux
Status: REPORTED
  Keywords: drkonqi
  Severity: crash
  Priority: NOR
 Component: discover
  Assignee: plasma-b...@kde.org
  Reporter: masdruba...@gmail.com
CC: aleix...@kde.org
  Target Milestone: ---

Application: plasma-discover (5.27.5)

Qt Version: 5.15.8
Frameworks Version: 5.103.0
Operating System: Linux 6.1.0-10-amd64 x86_64
Windowing System: Wayland
Distribution: Debian GNU/Linux 12 (bookworm)
DrKonqi: 5.27.5 [CoredumpBackend]

-- Information about the crash:
Al iniciar Discover para actualizar se cierra inmediatamente sin explicación.

The crash can be reproduced sometimes.

-- Backtrace:
Application: Discover (plasma-discover), signal: Segmentation fault

   PID: 3454 (plasma-discover)
   UID: 1000 (narsiteo)
   GID: 1000 (narsiteo)
Signal: 11 (SEGV)
 Timestamp: Wed 2023-07-26 09:06:27 CST (2min 56s ago)
  Command Line: /usr/bin/plasma-discover
Executable: /usr/bin/plasma-discover
 Control Group:
/user.slice/user-1000.slice/user@1000.service/app.slice/app-\x2fusr\x2fbin\x2fplasma\x2ddiscover-24dc05c5487b4d9a8aa0c5de4ed83130.scope
  Unit: user@1000.service
 User Unit:
app-\x2fusr\x2fbin\x2fplasma\x2ddiscover-24dc05c5487b4d9a8aa0c5de4ed83130.scope
 Slice: user-1000.slice
 Owner UID: 1000 (narsiteo)
   Boot ID: a335c74dfe2a4ac3915266bde931d04a
Machine ID: 4b4f1674bb2e4a868f839d2ebda69950
  Hostname: mmyguest
   Storage:
/var/lib/systemd/coredump/core.plasma-discover.1000.a335c74dfe2a4ac3915266bde931d04a.3454.169038398700.zst
(present)
  Size on Disk: 35.4M
   Message: Process 3454 (plasma-discover) of user 1000 dumped core.

Module libsystemd.so.0 from deb systemd-252.11-1~deb12u1.amd64
Module libudev.so.1 from deb systemd-252.11-1~deb12u1.amd64
Stack trace of thread 3454:
#0  0x7f2e546a9ccc n/a (libc.so.6 + 0x8accc)
#1  0x7f2e5465aef2 raise (libc.so.6 + 0x3bef2)
#2  0x7f2e56abb83d _ZN6KCrash19defaultCrashHandlerEi
(libKF5Crash.so.5 + 0x583d)
#3  0x7f2e5465af90 n/a (libc.so.6 + 0x3bf90)
#4  0x7f2e54ae8a3d n/a (libQt5Core.so.5 + 0x2e8a3d)
#5  0x7f2e56cf03b2
_ZN13ResultsStream14resourcesFoundERK7QVectorIP16AbstractResourceE
(libDiscoverCommon.so + 0x2a3b2)
#6  0x7f2e2de544d0 n/a (packagekit-backend.so + 0x264d0)
#7  0x7f2e2de4e588 n/a (packagekit-backend.so + 0x20588)
#8  0x7f2e54add6f0 _ZN7QObject5eventEP6QEvent
(libQt5Core.so.5 + 0x2dd6f0)
#9  0x7f2e56562fae
_ZN19QApplicationPrivate13notify_helperEP7QObjectP6QEvent (libQt5Widgets.so.5 +
0x162fae)
#10 0x7f2e54ab16f8
_ZN16QCoreApplication15notifyInternal2EP7QObjectP6QEvent (libQt5Core.so.5 +
0x2b16f8)
#11 0x7f2e54ab4681
_ZN23QCoreApplicationPrivate16sendPostedEventsEP7QObjectiP11QThreadData
(libQt5Core.so.5 + 0x2b4681)
#12 0x7f2e54b0a153 n/a (libQt5Core.so.5 + 0x30a153)
#13 0x7f2e5331e7a9 g_main_context_dispatch
(libglib-2.0.so.0 + 0x547a9)
#14 0x7f2e5331ea38 n/a (libglib-2.0.so.0 + 0x54a38)
#15 0x7f2e5331eacc g_main_context_iteration
(libglib-2.0.so.0 + 0x54acc)
#16 0x7f2e54b09836
_ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE
(libQt5Core.so.5 + 0x309836)
#17 0x7f2e54ab017b
_ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE (libQt5Core.so.5 +
0x2b017b)
#18 0x7f2e54ab82d6 _ZN16QCoreApplication4execEv
(libQt5Core.so.5 + 0x2b82d6)
#19 0x5632e7cc32a7 n/a (plasma-discover + 0x182a7)
#20 0x7f2e5464618a n/a (libc.so.6 + 0x2718a)
#21 0x7f2e54646245 __libc_start_main (libc.so.6 + 0x27245)
#22 0x5632e7cc3811 n/a (plasma-discover + 0x18811)

Stack trace of thread 4032:
#0  0x7f2e5471b0f6 ppoll (libc.so.6 + 0xfc0f6)
#1  0x7f2e54b05949 _Z12qt_safe_pollP6pollfdmPK8timespec
(libQt5Core.so.5 + 0x305949)
#2  0x7f2e54352763 n/a (libQt5Network.so.5 + 0xfc763)
#3  0x7f2e54350522 n/a (libQt5Network.so.5 + 0xfa522)
#4  0x7f2e54341e84 _ZN15QAbstractSocket16waitForReadyReadEi
(libQt5Network.so.5 + 0xebe84)
#5  0x7f2e56b15b8a n/a (libKF5KIOCore.so.5 + 0x53b8a)
#6  0x7f2e56b5efeb _ZN3KIO9SlaveBase12dispatchLoopEv
(libKF5KIOCore.so.5 + 0x9cfeb)
 

Re: [PATCH v20 1/2] scsi: ufs: Enable power management for wlun

[Asutosh Das (asd)]

On 4/19/2021 11:37 AM, Adrian Hunter wrote:

On 16/04/21 10:49 pm, Asutosh Das wrote:


Co-developed-by: Can Guo 
Signed-off-by: Can Guo 
Signed-off-by: Asutosh Das 
---


I came across 3 issues while testing.  See comments below.


Hi Adrian
Thanks for the comments.




@@ -5794,7 +5839,7 @@ static void ufshcd_err_handling_unprepare(struct ufs_hba 
*hba)
if (ufshcd_is_clkscaling_supported(hba))
ufshcd_clk_scaling_suspend(hba, false);
ufshcd_clear_ua_wluns(hba);


ufshcd_clear_ua_wluns() deadlocks trying to clear UFS_UPIU_RPMB_WLUN
if sdev_rpmb is suspended and sdev_ufs_device is suspending.
e.g. ufshcd_wl_suspend() is waiting on host_sem while ufshcd_err_handler()
is running, at which point sdev_rpmb has already suspended.


Umm, I didn't understand this deadlock.
When you say, sdev_rpmb is suspended, does it mean runtime_suspended?
sdev_ufs_device is suspending - this can't be runtime_suspending, while 
ufshcd_err_handling_unprepare is running.


If you've a call-stack of this deadlock, please can you share it with 
me. I'll also try to reproduce this.


I'll address the other comments in the next version.


Thank you!


-   pm_runtime_put(hba->dev);
+   ufshcd_rpm_put(hba);
  }





+void ufshcd_resume_complete(struct device *dev)
+{


--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
Linux Foundation Collaborative Project

Re: [PATCH v18 1/2] scsi: ufs: Enable power management for wlun

[Asutosh Das (asd)]

On 4/15/2021 4:11 PM, Bart Van Assche wrote:

On 4/14/21 11:58 AM, Asutosh Das wrote:

[ ... ]



Hi Bart,
Thanks for the comments. I will fix the comments in the next version.


The following code is executed before ufshcd_async_scan() is called:

dev = hba->dev;
[ ... ]
/* Hold auto suspend until async scan completes */
pm_runtime_get_sync(dev);

That would only keep the hba runtime resumed. At this point of time the 
luns are not detected yet.

and the following code occurs in ufshcd_add_lus():

pm_runtime_put_sync(hba->dev);

Isn't that sufficient to postpone enabling of runtime PM until LUN
scanning has finished? Or in other words, is adding a
pm_runtime_get_noresume() call in ufshcd_slave_configure() really necessary?

Yes, because the supplier (device wlun) may be suspended otherwise in 
scsi_sysfs_add_sdev().

@@ -4979,15 +5035,9 @@ ufshcd_transfer_rsp_status(struct ufs_hba *hba, struct 
ufshcd_lrb *lrbp)
 */
if (!hba->pm_op_in_progress &&
!ufshcd_eh_in_progress(hba) &&
-   ufshcd_is_exception_event(lrbp->ucd_rsp_ptr) &&
-   schedule_work(>eeh_work)) {
-   /*
-* Prevent suspend once eeh_work is scheduled
-* to avoid deadlock between ufshcd_suspend
-* and exception event handler.
-*/
-   pm_runtime_get_noresume(hba->dev);
-   }
+   ufshcd_is_exception_event(lrbp->ucd_rsp_ptr))
+   /* Flushed in suspend */
+   schedule_work(>eeh_work);


What makes it safe to leave out the above pm_runtime_get_noresume() call?

The __ufshcd_wl_suspend() would flush this work so that it doesn't run 
after suspend.

Thanks,

Bart.




--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
Linux Foundation Collaborative Project

Re: [PATCH v17 1/2] scsi: ufs: Enable power management for wlun

[Asutosh Das (asd)]

On 4/9/2021 3:07 AM, Adrian Hunter wrote:

On 9/04/21 5:27 am, Daejun Park wrote:

Hi Asutosh Das,


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.

Co-developed-by: Can Guo 
Signed-off-by: Can Guo 
Signed-off-by: Asutosh Das 
---
drivers/scsi/ufs/cdns-pltfrm.c |   2 +
drivers/scsi/ufs/tc-dwc-g210-pci.c |   2 +
drivers/scsi/ufs/ufs-debugfs.c |   6 +-
drivers/scsi/ufs/ufs-debugfs.h |   2 +-
drivers/scsi/ufs/ufs-exynos.c  |   2 +
drivers/scsi/ufs/ufs-hisi.c|   2 +
drivers/scsi/ufs/ufs-mediatek.c|  12 +-
drivers/scsi/ufs/ufs-qcom.c|   2 +
drivers/scsi/ufs/ufs_bsg.c |   6 +-
drivers/scsi/ufs/ufshcd-pci.c  |  36 +--
drivers/scsi/ufs/ufshcd.c  | 642 ++---
drivers/scsi/ufs/ufshcd.h  |   6 +
include/trace/events/ufs.h |  20 ++
13 files changed, 509 insertions(+), 231 deletions(-)


In this patch, you changed pm_runtime_{get, put}_sync to scsi_autopm_{get, 
put}_device.
But, scsi_autopm_get_device() calls pm_runtime_put_sync() in case of error
of pm_runtime_get_sync(). So, pm_runtime_put_sync() can be called twice if
scsi_autopm_get_device has error.


Also it might be tidy to make wrappers e.g.

static inline int ufshcd_rpm_get_sync(struct ufs_hba *hba)
{
 return pm_runtime_get_sync(>sdev_ufs_device->sdev_gendev);
}

static inline int ufshcd_rpm_put(struct ufs_hba *hba)

{
 return pm_runtime_put(>sdev_ufs_device->sdev_gendev);
}

static inline int ufshcd_rpm_put_sync(struct ufs_hba *hba)
{
 return pm_runtime_put_sync(>sdev_ufs_device->sdev_gendev);
}

And also consider matching: e.g.

pm_runtime_put(hba->dev) to  ufshcd_rpm_put(hba)
pm_runtime_put_sync(hba->dev)to  ufshcd_rpm_put_sync(hba)





Ok, I'll push the changes shortly.

--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
Linux Foundation Collaborative Project

Re: [PATCH v15 1/2] scsi: ufs: Enable power management for wlun

[Asutosh Das (asd)]

On 4/7/2021 3:21 AM, Adrian Hunter wrote:

On 6/04/21 8:52 pm, 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.

Co-developed-by: Can Guo 
Signed-off-by: Can Guo 
Signed-off-by: Asutosh Das 
---


v15 seems to be missing the updates to ufs_debugfs_get/put_user_access
that were in v14:


@@ -60,14 +60,14 @@ __acquires(>host_sem)
up(>host_sem);
return -EBUSY;
}
-   pm_runtime_get_sync(hba->dev);
+   scsi_autopm_get_device(hba->sdev_ufs_device);
return 0;
  }
  
  static void ufs_debugfs_put_user_access(struct ufs_hba *hba)

  __releases(>host_sem)
  {
-   pm_runtime_put_sync(hba->dev);
+   scsi_autopm_put_device(hba->sdev_ufs_device);
up(>host_sem);
  }
  


Also from last comments, the issue below:




+#ifdef CONFIG_PM_SLEEP
+static int ufshcd_wl_poweroff(struct device *dev)
+{
+   ufshcd_wl_shutdown(dev);


This turned out to be wrong.  This is a PM op and SCSI has already
quiesced the sdev's.  All that is needed is:

__ufshcd_wl_suspend(hba, UFS_SHUTDOWN_PM);



Yikes! Thanks, let me fix this and push the correct series.

-asd

--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
Linux Foundation Collaborative Project

Re: [PATCH v14 1/2] scsi: ufs: Enable power management for wlun

[Asutosh Das (asd)]

On 3/31/2021 11:19 AM, Adrian Hunter wrote:

On 31/03/21 1:31 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.

Co-developed-by: Can Guo 
Signed-off-by: Can Guo 
Signed-off-by: Asutosh Das 
---



Hi Adrian
Thanks for the comments.

Looks good but still doesn't seem to based on the latest tree.


Umm, it's based on the below:
git://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git
Branch: refs/heads/for-next

The top most change is e27f3c8 on 27th March'21.
Which tree are you referring to that'd be latest?


Also came across the issue below:




+#ifdef CONFIG_PM_SLEEP
+static int ufshcd_wl_poweroff(struct device *dev)
+{
+   ufshcd_wl_shutdown(dev);


This turned out to be wrong.  This is a PM op and SCSI has already
quiesced the sdev's.  All that is needed isOk. I'll fix it in the next version.




__ufshcd_wl_suspend(hba, UFS_SHUTDOWN_PM);


+   return 0;
+}
+#endif



--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
Linux Foundation Collaborative Project

Re: [PATCH V2 2/3] scsi: ufs: add a vops to configure VCC voltage level

[Asutosh Das (asd)]

On 3/21/2021 2:57 PM, Nitin Rawat wrote:

Add a vops to configure VCC voltage VCC voltage level
for platform supporting both ufs2.x and ufs 3.x devices.

Suggested-by: Stanley Chu 
Suggested-by: Asutosh Das 
Suggested-by: Bjorn Andersson 
Signed-off-by: Nitin Rawat 
Signed-off-by: Veerabhadrarao Badiganti 
---
  drivers/scsi/ufs/ufshcd.c |  4 
  drivers/scsi/ufs/ufshcd.h | 10 ++
  2 files changed, 14 insertions(+)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 633ca8e..5bfe987 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -7763,6 +7763,10 @@ static int ufshcd_add_lus(struct ufs_hba *hba)
goto out;

ufshcd_clear_ua_wluns(hba);
+   if (ufshcd_vops_setup_vcc_regulators(hba))
This would be invoked even for platforms that don't support both 2.x and 
3.x and don't need to set the voltages in the driver.
I guess platforms that support both 2.x and 3.x and can't set the 
regulator voltages from dts due to different voltage requirements of 2.x 
and 3.x, should request the driver to set the voltages. And the driver 
may do so after determining the device version.



+   dev_err(hba->dev,
+   "%s: Failed to set the VCC regulator values, continue with 
2.7v\n",
+   __func__);

/* Initialize devfreq after UFS device is detected */
if (ufshcd_is_clkscaling_supported(hba)) {
diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
index 0db796a..8f0945d 100644
--- a/drivers/scsi/ufs/ufshcd.h
+++ b/drivers/scsi/ufs/ufshcd.h
@@ -324,6 +324,7 @@ struct ufs_pwr_mode_info {
   * @device_reset: called to issue a reset pulse on the UFS device
   * @program_key: program or evict an inline encryption key
   * @event_notify: called to notify important events
+ * @setup_vcc_regulators : update vcc regulator level
   */
  struct ufs_hba_variant_ops {
const char *name;
@@ -360,6 +361,7 @@ struct ufs_hba_variant_ops {
   const union ufs_crypto_cfg_entry *cfg, int slot);
void(*event_notify)(struct ufs_hba *hba,
enum ufs_event_type evt, void *data);
+   int(*setup_vcc_regulators)(struct ufs_hba *hba);
  };

  /* clock gating state  */
@@ -1269,6 +1271,14 @@ static inline void 
ufshcd_vops_config_scaling_param(struct ufs_hba *hba,
hba->vops->config_scaling_param(hba, profile, data);
  }

+static inline int ufshcd_vops_setup_vcc_regulators(struct ufs_hba *hba)
+{
+   if (hba->vops && hba->vops->setup_vcc_regulators)
+   return hba->vops->setup_vcc_regulators(hba);
+
+   return 0;
+}
+
  extern struct ufs_pm_lvl_states ufs_pm_lvl_states[];

  /*
--
2.7.4




--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
Linux Foundation Collaborative Project

Re: [PATCH v12 1/2] scsi: ufs: Enable power management for wlun

[Asutosh Das (asd)]

On 3/23/2021 12:19 PM, Adrian Hunter wrote:

On 23/03/21 5:13 pm, Asutosh Das (asd) wrote:

On 3/22/2021 11:12 PM, Adrian Hunter wrote:

On 22/03/21 9:53 pm, Asutosh Das (asd) wrote:

On 3/19/2021 10:47 AM, Adrian Hunter wrote:

On 19/03/21 2:35 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 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.

Co-developed-by: Can Guo 
Signed-off-by: Can Guo 
Signed-off-by: Asutosh Das 


I have some more comments that may help straighten things out.

Also please look at ufs_debugfs_get_user_access() and
ufs_debugfs_put_user_access() that now need to scsi_autopm_get/put_device
sdev_ufs_device.

It would also be good if you could re-base on linux-next.



Hi Adrian
Thanks for the comments.

I agree moving the code to wlun probe and other changes.
But it looks to me that it may not fully solve the issue.

Please let me explain my understanding on this:

(Please refer to the logs in v10)
scsi_autopm_*() are invoked on a sdev.
pm_runtime_get_suppliers()/rpm_put_suppliers() are on the supplier device.

For the device wlun:
  slave_configure():
  - doesn't set the rpm_autosuspend
  - pm_runtime_getnoresume()
  scsi_sysfs_add_sdev():
  - pm_runtime_forbid()
  - scsi_autopm_get_device()
  - device_add()
  - ufshcd_wl_probe()
  - scsi_autopm_put_device()

For all other scsi devices:
  slave_alloc():
  - ufshcd_setup_links()
Say all link_add: pm_runtime_put(>sdev_ufs_device->sdev_gendev);


With DL_FLAG_RPM_ACTIVE, links will 'get' not 'put'


I'm referring to the pm_runtime_put(sdev_ufs_device) after all the links are 
setup, that you suggested to add.


Ok


  slave_configure():
  - set rpm_autosuspend
  scsi_sysfs_add_sdev():
  - scsi_autopm_get_device()
  - device_add() -> schedules an async probe()
  - scsi_autopm_put_device() - (1)

Now the rpm_put_suppliers() can be invoked *after* pm_runtime_get_suppliers() 
of the async probe(), since both are running in different contexts.


Only if the sd device suspends.


Correct. What'd stop the sd device from suspending?
We should be stopping the sd device from suspending here - imho.




Hi Adrian,
Thanks for the comments.


You mean for performance reasons.  That is something we can
look at, but let's get it working first.

Not for performance reasons. I meant to say that this issue can be fixed 
if we stop the sd devices from suspending until the sd_probe() is completed.



In that case, the usage_count of supplier would be decremented until rpm_active 
of this link becomes 1.


Right, because the sd device suspended.


Now the pm_runtime_get_suppliers() expects the link_active to be more than 1.


Not sure what you mean here. pm_runtime_*put*_suppliers() won't do anything if 
the link count is 1.

I'm referring to the logs that I pasted before:
[    6.941267][    T7] scsi 0:0:0:4: rpm_put_suppliers: [BEF] Supp 
(0:0:0:49488) usage_count: 4 rpm_active: 3

-- T196 Context comes in while T7 is running --
[    6.941466][  T196] scsi 0:0:0:4: pm_runtime_get_suppliers: (0:0:0:49488): 
supp: usage_count: 5 rpm_active: 4
--

[    7.788397][    T7] scsi 0:0:0:4: rpm_put_suppliers: [AFT] Supp 
(0:0:0:49488) usage_count: 2 rpm_active: 1

I meant to say that, if the rpm_put_suppliers() is invoked after the 
pm_runtime_get_suppliers() as is seen above then the link_active may become 1 
even *after* pm_runtime_get_suppliers() is invoked.

I'm referring to the pm_runtime_get_suppliers() invoked from:
driver_probe_device() - say for, sd 0:0:0:x
 |- pm_runtime_get_suppliers() - for

Re: [PATCH v12 1/2] scsi: ufs: Enable power management for wlun

[Asutosh Das (asd)]

On 3/22/2021 11:12 PM, Adrian Hunter wrote:

On 22/03/21 9:53 pm, Asutosh Das (asd) wrote:

On 3/19/2021 10:47 AM, Adrian Hunter wrote:

On 19/03/21 2:35 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 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.

Co-developed-by: Can Guo 
Signed-off-by: Can Guo 
Signed-off-by: Asutosh Das 


I have some more comments that may help straighten things out.

Also please look at ufs_debugfs_get_user_access() and
ufs_debugfs_put_user_access() that now need to scsi_autopm_get/put_device
sdev_ufs_device.

It would also be good if you could re-base on linux-next.



Hi Adrian
Thanks for the comments.

I agree moving the code to wlun probe and other changes.
But it looks to me that it may not fully solve the issue.

Please let me explain my understanding on this:

(Please refer to the logs in v10)
scsi_autopm_*() are invoked on a sdev.
pm_runtime_get_suppliers()/rpm_put_suppliers() are on the supplier device.

For the device wlun:
 slave_configure():
     - doesn't set the rpm_autosuspend
     - pm_runtime_getnoresume()
 scsi_sysfs_add_sdev():
     - pm_runtime_forbid()
     - scsi_autopm_get_device()
     - device_add()
     - ufshcd_wl_probe()
     - scsi_autopm_put_device()

For all other scsi devices:
 slave_alloc():
     - ufshcd_setup_links()
Say all link_add: pm_runtime_put(>sdev_ufs_device->sdev_gendev);


With DL_FLAG_RPM_ACTIVE, links will 'get' not 'put'

I'm referring to the pm_runtime_put(sdev_ufs_device) after all the links 
are setup, that you suggested to add.

 slave_configure():
     - set rpm_autosuspend
 scsi_sysfs_add_sdev():
     - scsi_autopm_get_device()
     - device_add() -> schedules an async probe()
     - scsi_autopm_put_device() - (1)

Now the rpm_put_suppliers() can be invoked *after* pm_runtime_get_suppliers() 
of the async probe(), since both are running in different contexts.


Only if the sd device suspends.


Correct. What'd stop the sd device from suspending?
We should be stopping the sd device from suspending here - imho.


In that case, the usage_count of supplier would be decremented until rpm_active 
of this link becomes 1.


Right, because the sd device suspended.


Now the pm_runtime_get_suppliers() expects the link_active to be more than 1.


Not sure what you mean here. pm_runtime_*put*_suppliers() won't do anything if 
the link count is 1.

I'm referring to the logs that I pasted before:
[6.941267][T7] scsi 0:0:0:4: rpm_put_suppliers: [BEF] Supp 
(0:0:0:49488) usage_count: 4 rpm_active: 3


-- T196 Context comes in while T7 is running --
[6.941466][  T196] scsi 0:0:0:4: pm_runtime_get_suppliers: 
(0:0:0:49488): supp: usage_count: 5 rpm_active: 4

--

[7.788397][T7] scsi 0:0:0:4: rpm_put_suppliers: [AFT] Supp 
(0:0:0:49488) usage_count: 2 rpm_active: 1


I meant to say that, if the rpm_put_suppliers() is invoked after the 
pm_runtime_get_suppliers() as is seen above then the link_active may 
become 1 even *after* pm_runtime_get_suppliers() is invoked.


I'm referring to the pm_runtime_get_suppliers() invoked from:
driver_probe_device() - say for, sd 0:0:0:x
|- pm_runtime_get_suppliers() - for sd 0:0:0:49488



Now then, there comes a time, that when sd_probe() schedules a suspend, the 
supplier usage_count becomes 0 and the link_active becomes 1.
And the supplier suspends before the consumer.


sd probe first resumes the sd device which will resume the supplier.

Correct, but it'd again schedule a suspend (since autosuspend is enabled 
now) at the end of the sd_probe().
Thereafter, pm_runtime_put_suppliers()

Re: [PATCH v12 1/2] scsi: ufs: Enable power management for wlun

[Asutosh Das (asd)]

On 3/19/2021 10:47 AM, Adrian Hunter wrote:

On 19/03/21 2:35 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 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.

Co-developed-by: Can Guo 
Signed-off-by: Can Guo 
Signed-off-by: Asutosh Das 


I have some more comments that may help straighten things out.

Also please look at ufs_debugfs_get_user_access() and
ufs_debugfs_put_user_access() that now need to scsi_autopm_get/put_device
sdev_ufs_device.

It would also be good if you could re-base on linux-next.



Hi Adrian
Thanks for the comments.

I agree moving the code to wlun probe and other changes.
But it looks to me that it may not fully solve the issue.

Please let me explain my understanding on this:

(Please refer to the logs in v10)
scsi_autopm_*() are invoked on a sdev.
pm_runtime_get_suppliers()/rpm_put_suppliers() are on the supplier device.

For the device wlun:
slave_configure():
- doesn't set the rpm_autosuspend
- pm_runtime_getnoresume()
scsi_sysfs_add_sdev():
- pm_runtime_forbid()
- scsi_autopm_get_device()
- device_add()
- ufshcd_wl_probe()
- scsi_autopm_put_device()

For all other scsi devices:
slave_alloc():
- ufshcd_setup_links()
Say all link_add: pm_runtime_put(>sdev_ufs_device->sdev_gendev);
slave_configure():
- set rpm_autosuspend
scsi_sysfs_add_sdev():
- scsi_autopm_get_device()
- device_add() -> schedules an async probe()
- scsi_autopm_put_device() - (1)

Now the rpm_put_suppliers() can be invoked *after* 
pm_runtime_get_suppliers() of the async probe(), since both are running 
in different contexts.
In that case, the usage_count of supplier would be decremented until 
rpm_active of this link becomes 1.
Now the pm_runtime_get_suppliers() expects the link_active to be more 
than 1.
Now then, there comes a time, that when sd_probe() schedules a suspend, 
the supplier usage_count becomes 0 and the link_active becomes 1.

And the supplier suspends before the consumer.

So I was wondering, what'd make sure that the pm_runtime_get_suppliers() 
from driver_probe_device() is invoked after scsi_autopm_put_device() (1) 
finishes the rpm_put_suppliers().


Am not sure if I'm missing something in this.
Do you think, the current changes alone can fix the above issue?

-asd


---
  drivers/scsi/ufs/cdns-pltfrm.c |   2 +
  drivers/scsi/ufs/tc-dwc-g210-pci.c |   2 +
  drivers/scsi/ufs/ufs-debugfs.c |   2 +-
  drivers/scsi/ufs/ufs-debugfs.h |   2 +-
  drivers/scsi/ufs/ufs-exynos.c  |   2 +
  drivers/scsi/ufs/ufs-hisi.c|   2 +
  drivers/scsi/ufs/ufs-mediatek.c|  12 +-
  drivers/scsi/ufs/ufs-qcom.c|   2 +
  drivers/scsi/ufs/ufs_bsg.c |   6 +-
  drivers/scsi/ufs/ufshcd-pci.c  |  36 +--
  drivers/scsi/ufs/ufshcd.c  | 622 ++---
  drivers/scsi/ufs/ufshcd.h  |   6 +
  include/trace/events/ufs.h |  20 ++
  13 files changed, 491 insertions(+), 225 deletions(-)

diff --git a/drivers/scsi/ufs/cdns-pltfrm.c b/drivers/scsi/ufs/cdns-pltfrm.c
index 149391f..3e70c23 100644
--- a/drivers/scsi/ufs/cdns-pltfrm.c
+++ b/drivers/scsi/ufs/cdns-pltfrm.c
@@ -319,6 +319,8 @@ static const struct dev_pm_ops cdns_ufs_dev_pm_ops = {
.runtime_suspend = ufshcd_pltfrm_runtime_suspend,
.runtime_resume  = ufshcd_pltfrm_runtime_resume,
.runtime_idle= ufshcd_pltfrm_runtime_idle,
+   .prepare = ufshcd_suspend_prepare,
+   .complete   = ufshcd_resume_complete,
  };
  
  static struct platform_driver cdns_ufs_pltf

Re: [PATCH v12 1/2] scsi: ufs: Enable power management for wlun

[Asutosh Das (asd)]

On 3/18/2021 8:12 PM, Bart Van Assche wrote:

On 3/18/21 5:35 PM, 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 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().



Hi Bart,
Thanks for the review comments.


What is the role of the WLUN during runtime suspend and why does a
command need to be sent to the WLUN during runtime suspend? Although it
is possible to derive this from the source code, please explain this in
the patch description.


Ok. Will explain it in the next version.


What does the acronym SSU stand for? This doesn't seem like a commonly
used kernel acronym to me so please expand that acronym.


START STOP UNIT.
Anyway, I'll expand it in the next version.


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.


That's an interesting solution.


-void __exit ufs_debugfs_exit(void)
+void ufs_debugfs_exit(void)


Is the above change related to the rest of this patch?


Yes, it's used to handle an error in ufshcd_core_init() function.


  static struct platform_driver ufs_qcom_pltform = {
diff --git a/drivers/scsi/ufs/ufs_bsg.c b/drivers/scsi/ufs/ufs_bsg.c
index 5b2bc1a..cbb5a90 100644
--- a/drivers/scsi/ufs/ufs_bsg.c
+++ b/drivers/scsi/ufs/ufs_bsg.c
@@ -97,7 +97,7 @@ static int ufs_bsg_request(struct bsg_job *job)
  
  	bsg_reply->reply_payload_rcv_len = 0;
  
-	pm_runtime_get_sync(hba->dev);

+   scsi_autopm_get_device(hba->sdev_ufs_device);


Can the pm_runtime_get_sync() to scsi_autopm_get_device() changes be
moved into a separate patch?


I guess so. But then this patch would have issues when used independently.


+static inline bool is_rpmb_wlun(struct scsi_device *sdev)
+{
+   return (sdev->lun == ufshcd_upiu_wlun_to_scsi_wlun(UFS_UPIU_RPMB_WLUN));
+}


Has this patch been verified with checkpatch? Checkpatch should have
reported the following for the above code:

return is not a function, parentheses are not required


Yes, it has been verified. But I didn't see any error reports.
Below is the o/p of checkpatch:

$ ./scripts/checkpatch.pl /tmp/up/ufs-pm-v12/*
--
/tmp/up/ufs-pm-v12/-cover-letter.patch
--
WARNING: Possible unwrapped commit description (prefer a maximum 75 
chars per line)

#107:
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
Linux Foundation Collaborative Project.


total: 0 errors, 1 warnings, 0 lines checked

NOTE: For some of the reported defects, checkpatch may be able to
  mechanically convert to the typical style using --fix or 
--fix-inplace.


/tmp/up/ufs-pm-v12/-cover-letter.patch has style problems, please 
review.

---
/tmp/up/ufs-pm-v12/0001-scsi-ufs-Enable-power-management-for-wlun.patch
---
total: 0 errors, 0 warnings, 1180 lines checked

/tmp/up/ufs-pm-v12/0001-scsi-ufs-Enable-power-management-for-wlun.patch 
has no obvious style problems and is ready for submission.

-
/tmp/up/ufs-pm-v12/0002-ufs-sysfs-Resume-the-proper-scsi-device.patch
-
total: 0 errors, 0 warnings, 91 lines checked

/tmp/up/ufs-pm-v12/0002-ufs-sysfs-Resume-the-proper-scsi-device.patch 
has no obvious style problems and is ready for submission.


NOTE: If any of the errors are false positives, please report
  them to the maintainer, see CHECKPATCH in MAINTAINERS.



+static inline bool is_device_wlun(struct scsi_device *sdev)
+{
+   return (sdev->lun ==
+   ufshcd_upiu_wlun_to_scsi_wlun(UFS_UPIU_UFS_DEVICE_WLUN));
+}


Same comment here.


/*
-* Don't assume anything of pm_runtime_get_sync(), if
+* Don't assume anything of resume, if
 * resume fails, irq and clocks can be OFF, and powers
 * can be OFF or in LPM.
 */


Please make better use of the horizontal space in the above comment by
making comment lines longer.


Ok Sure.


Thanks,

Bart.



-asd

--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
Linux Foundation Collaborative Project

Re: [PATCH v10 1/2] scsi: ufs: Enable power management for wlun

[Asutosh Das (asd)]

On 3/18/2021 12:16 PM, Adrian Hunter wrote:

On 18/03/21 7:58 pm, Asutosh Das (asd) wrote:

On 3/18/2021 10:54 AM, Rafael J. Wysocki wrote:

On Thu, Mar 18, 2021 at 6:33 PM Asutosh Das (asd)
 wrote:


On 3/18/2021 7:00 AM, Rafael J. Wysocki wrote:

On Wed, Mar 17, 2021 at 7:37 AM Adrian Hunter  wrote:


On 16/03/21 10:35 pm, Asutosh Das (asd) wrote:

On 3/16/2021 12:48 AM, Adrian Hunter wrote:

On 16/03/21 12:22 am, Asutosh Das (asd) wrote:

On 3/14/2021 1:11 AM, Adrian Hunter wrote:

On 10/03/21 5:04 am, Asutosh Das (asd) wrote:

On 3/9/2021 7:56 AM, Asutosh Das (asd) wrote:

On 3/8/2021 9:17 AM, Rafael J. Wysocki wrote:

On Mon, Mar 8, 2021 at 5:21 PM Rafael J. Wysocki  wrote:


On Sat, Mar 6, 2021 at 5:17 PM Alan Stern  wrote:


On Fri, Mar 05, 2021 at 06:54:24PM -0800, Asutosh Das (asd) wrote:


Now during my testing I see a weird issue sometimes (1 in 7).
Scenario - bootups

Issue:
The supplier 'ufs_device_wlun 0:0:0:49488' goes into runtime suspend even
when one/more of its consumers are in RPM_ACTIVE state.

*Log:
[   10.056379][  T206] sd 0:0:0:1: [sdb] Synchronizing SCSI cache
[   10.062497][  T113] sd 0:0:0:5: [sdf] Synchronizing SCSI cache
[   10.356600][   T32] sd 0:0:0:7: [sdh] Synchronizing SCSI cache
[   10.362944][  T174] sd 0:0:0:3: [sdd] Synchronizing SCSI cache
[   10.696627][   T83] sd 0:0:0:2: [sdc] Synchronizing SCSI cache
[   10.704562][  T170] sd 0:0:0:6: [sdg] Synchronizing SCSI cache
[   10.980602][    T5] sd 0:0:0:0: [sda] Synchronizing SCSI cache

/** Printing all the consumer nodes of supplier **/
[   10.987327][    T5] ufs_device_wlun 0:0:0:49488: usage-count @ suspend: 0
<-- this is the usage_count
[   10.994440][    T5] ufs_rpmb_wlun 0:0:0:49476: PM state - 2
[   11.000402][    T5] scsi 0:0:0:49456: PM state - 2
[   11.005453][    T5] sd 0:0:0:0: PM state - 2
[   11.009958][    T5] sd 0:0:0:1: PM state - 2
[   11.014469][    T5] sd 0:0:0:2: PM state - 2
[   11.019072][    T5] sd 0:0:0:3: PM state - 2
[   11.023595][    T5] sd 0:0:0:4: PM state - 0 << RPM_ACTIVE
[   11.353298][    T5] sd 0:0:0:5: PM state - 2
[   11.357726][    T5] sd 0:0:0:6: PM state - 2
[   11.362155][    T5] sd 0:0:0:7: PM state - 2
[   11.366584][    T5] ufshcd-qcom 1d84000.ufshc: __ufshcd_wl_suspend - 8709
[   11.374366][    T5] ufs_device_wlun 0:0:0:49488: __ufshcd_wl_suspend -
(0) has rpm_active flags


Do you mean that rpm_active of the link between the consumer and the
supplier is greater than 0 at this point and the consumer is


I mean is rpm_active of the link greater than 1 (because 1 means "no
active references to the supplier")?

Hi Rafael:
No - it is not greater than 1.

I'm trying to understand what's going on in it; will update when I've something.




RPM_ACTIVE, but the supplier suspends successfully nevertheless?


[   11.383376][    T5] ufs_device_wlun 0:0:0:49488:
ufshcd_wl_runtime_suspend <-- Supplier suspends fine.
[   12.977318][  T174] sd 0:0:0:4: [sde] Synchronizing SCSI cache

And the the suspend of sde is stuck now:
schedule+0x9c/0xe0
schedule_timeout+0x40/0x128
io_schedule_timeout+0x44/0x68
wait_for_common_io+0x7c/0x100
wait_for_completion_io+0x14/0x20
blk_execute_rq+0x90/0xcc
__scsi_execute+0x104/0x1c4
sd_sync_cache+0xf8/0x2a0
sd_suspend_common+0x74/0x11c
sd_suspend_runtime+0x14/0x20
scsi_runtime_suspend+0x64/0x94
__rpm_callback+0x80/0x2a4
rpm_suspend+0x308/0x614
pm_runtime_work+0x98/0xa8

I added 'DL_FLAG_RPM_ACTIVE' while creating links.
    if (hba->sdev_ufs_device) {
    link = device_link_add(>sdev_gendev,
    >sdev_ufs_device->sdev_gendev,
   DL_FLAG_PM_RUNTIME|DL_FLAG_RPM_ACTIVE);
I didn't expect this to resolve the issue anyway and it didn't.

Another interesting point here is when I resume any of the above suspended
consumers, it all goes back to normal, which is kind of expected. I tried
resuming the consumer and the supplier is resumed and the supplier is
suspended when all the consumers are suspended.

Any pointers on this issue please?

@Bart/@Alan - Do you've any pointers please?


It's very noticeable that although you seem to have isolated a bug in
the power management subsystem (supplier goes into runtime suspend
even when one of its consumers is still active), you did not CC the
power management maintainer or mailing list.

I have added the appropriate CC's.


Thanks Alan!





Hello
I & Can (thanks CanG) debugged this further:

Looks like this issue can occur if the sd probe is asynchronous.

Essentially, the sd_probe() is done asynchronously and driver_probe_device() 
invokes pm_runtime_get_suppliers() before invoking sd_probe().

But scsi_probe_and_add_lun() runs in a separate context.
So the scsi_autopm_put_device() invoked from scsi_scan_host() context reduces the 
link->rpm_active to 1. And sd_probe() invokes scsi_autopm_put_device() and starts 
a timer. And then driver_probe_device() invoked from __device_atta

Re: [PATCH v11 1/2] scsi: ufs: Enable power management for wlun

[Asutosh Das (asd)]

On 3/15/2021 7:29 AM, Adrian Hunter wrote:

On 12/03/21 12:19 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 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.


I haven't had time to try to reproduce the device-links issue, but
there are a couple of comments below, in addition to the suggestions
here:

https://lore.kernel.org/linux-scsi/b13086f3-eea1-51a7-2117-579d520f2...@intel.com/


Thanks.
I think even if the race in pm framework is fixed, the 
scsi_sysfs_add_sdev() can race with sd_probe().
IIUC that's because scsi_sysfs_add_sdev() schedules an async probe for 
the sd device and then invokes scsi_autopm_put_device().



Also, there are still ufshcd_err_handling_prepare()/unprepare()
and ufshcd_recover_pm_error(), that look like they need attention
e.g. to use scsi_autopm_get/put_device(hba->sdev_ufs_device)


Sure will address this.





Co-developed-by: Can Guo 
Signed-off-by: Can Guo 
Signed-off-by: Asutosh Das 
---
  drivers/scsi/ufs/cdns-pltfrm.c |   2 +
  drivers/scsi/ufs/tc-dwc-g210-pci.c |   2 +
  drivers/scsi/ufs/ufs-debugfs.c |   5 +
  drivers/scsi/ufs/ufs-debugfs.h |   2 +
  drivers/scsi/ufs/ufs-exynos.c  |   2 +
  drivers/scsi/ufs/ufs-hisi.c|   2 +
  drivers/scsi/ufs/ufs-mediatek.c|   2 +
  drivers/scsi/ufs/ufs-qcom.c|   2 +
  drivers/scsi/ufs/ufs_bsg.c |   6 +-
  drivers/scsi/ufs/ufshcd-pci.c  |  36 +--
  drivers/scsi/ufs/ufshcd.c  | 616 ++---
  drivers/scsi/ufs/ufshcd.h  |   7 +
  include/trace/events/ufs.h |  20 ++
  13 files changed, 498 insertions(+), 206 deletions(-)

diff --git a/drivers/scsi/ufs/cdns-pltfrm.c b/drivers/scsi/ufs/cdns-pltfrm.c
index 149391f..3e70c23 100644
--- a/drivers/scsi/ufs/cdns-pltfrm.c
+++ b/drivers/scsi/ufs/cdns-pltfrm.c
@@ -319,6 +319,8 @@ static const struct dev_pm_ops cdns_ufs_dev_pm_ops = {
.runtime_suspend = ufshcd_pltfrm_runtime_suspend,
.runtime_resume  = ufshcd_pltfrm_runtime_resume,
.runtime_idle= ufshcd_pltfrm_runtime_idle,
+   .prepare = ufshcd_suspend_prepare,
+   .complete   = ufshcd_resume_complete,
  };
  
  static struct platform_driver cdns_ufs_pltfrm_driver = {

diff --git a/drivers/scsi/ufs/tc-dwc-g210-pci.c 
b/drivers/scsi/ufs/tc-dwc-g210-pci.c
index 67a6a61..b01db12 100644
--- a/drivers/scsi/ufs/tc-dwc-g210-pci.c
+++ b/drivers/scsi/ufs/tc-dwc-g210-pci.c
@@ -148,6 +148,8 @@ static const struct dev_pm_ops tc_dwc_g210_pci_pm_ops = {
.runtime_suspend = tc_dwc_g210_pci_runtime_suspend,
.runtime_resume  = tc_dwc_g210_pci_runtime_resume,
.runtime_idle= tc_dwc_g210_pci_runtime_idle,
+   .prepare = ufshcd_suspend_prepare,
+   .complete   = ufshcd_resume_complete,
  };
  
  static const struct pci_device_id tc_dwc_g210_pci_tbl[] = {

diff --git a/drivers/scsi/ufs/ufs-debugfs.c b/drivers/scsi/ufs/ufs-debugfs.c
index dee98dc..f8ce2eb 100644
--- a/drivers/scsi/ufs/ufs-debugfs.c
+++ b/drivers/scsi/ufs/ufs-debugfs.c
@@ -54,3 +54,8 @@ void ufs_debugfs_hba_exit(struct ufs_hba *hba)
  {
debugfs_remove_recursive(hba->debugfs_root);
  }
+
+void ufs_debugfs_eh_exit(void)
+{
+   debugfs_remove_recursive(ufs_debugfs_root);
+}


This is the same as ufs_debugfs_exit() without __exit so why not
remove __exit from ufs_debugfs_exit() and use that instead?


Will change it.


diff --git a/drivers/scsi/ufs/ufs-debugfs.h b/drivers/scsi/ufs/ufs-debugfs.h
index f35b39c..3fce5a0 100644
--- a/drivers/scsi/ufs/ufs-debugfs.h
+++ b/drivers/scsi/ufs/ufs-debugfs.h
@@ -12,11 +12,13 @@ void __init ufs_debugfs_init(void);
  void __exit ufs_debugfs_exit(void);
  void ufs_debugfs_hba_init(struct ufs_hba *hba);
  void ufs_debugfs_hba_exit(struct 

Re: [PATCH v10 1/2] scsi: ufs: Enable power management for wlun

[Asutosh Das (asd)]

On 3/18/2021 10:54 AM, Rafael J. Wysocki wrote:

On Thu, Mar 18, 2021 at 6:33 PM Asutosh Das (asd)
 wrote:


On 3/18/2021 7:00 AM, Rafael J. Wysocki wrote:

On Wed, Mar 17, 2021 at 7:37 AM Adrian Hunter  wrote:


On 16/03/21 10:35 pm, Asutosh Das (asd) wrote:

On 3/16/2021 12:48 AM, Adrian Hunter wrote:

On 16/03/21 12:22 am, Asutosh Das (asd) wrote:

On 3/14/2021 1:11 AM, Adrian Hunter wrote:

On 10/03/21 5:04 am, Asutosh Das (asd) wrote:

On 3/9/2021 7:56 AM, Asutosh Das (asd) wrote:

On 3/8/2021 9:17 AM, Rafael J. Wysocki wrote:

On Mon, Mar 8, 2021 at 5:21 PM Rafael J. Wysocki  wrote:


On Sat, Mar 6, 2021 at 5:17 PM Alan Stern  wrote:


On Fri, Mar 05, 2021 at 06:54:24PM -0800, Asutosh Das (asd) wrote:


Now during my testing I see a weird issue sometimes (1 in 7).
Scenario - bootups

Issue:
The supplier 'ufs_device_wlun 0:0:0:49488' goes into runtime suspend even
when one/more of its consumers are in RPM_ACTIVE state.

*Log:
[   10.056379][  T206] sd 0:0:0:1: [sdb] Synchronizing SCSI cache
[   10.062497][  T113] sd 0:0:0:5: [sdf] Synchronizing SCSI cache
[   10.356600][   T32] sd 0:0:0:7: [sdh] Synchronizing SCSI cache
[   10.362944][  T174] sd 0:0:0:3: [sdd] Synchronizing SCSI cache
[   10.696627][   T83] sd 0:0:0:2: [sdc] Synchronizing SCSI cache
[   10.704562][  T170] sd 0:0:0:6: [sdg] Synchronizing SCSI cache
[   10.980602][T5] sd 0:0:0:0: [sda] Synchronizing SCSI cache

/** Printing all the consumer nodes of supplier **/
[   10.987327][T5] ufs_device_wlun 0:0:0:49488: usage-count @ suspend: 0
<-- this is the usage_count
[   10.994440][T5] ufs_rpmb_wlun 0:0:0:49476: PM state - 2
[   11.000402][T5] scsi 0:0:0:49456: PM state - 2
[   11.005453][T5] sd 0:0:0:0: PM state - 2
[   11.009958][T5] sd 0:0:0:1: PM state - 2
[   11.014469][T5] sd 0:0:0:2: PM state - 2
[   11.019072][T5] sd 0:0:0:3: PM state - 2
[   11.023595][T5] sd 0:0:0:4: PM state - 0 << RPM_ACTIVE
[   11.353298][T5] sd 0:0:0:5: PM state - 2
[   11.357726][T5] sd 0:0:0:6: PM state - 2
[   11.362155][T5] sd 0:0:0:7: PM state - 2
[   11.366584][T5] ufshcd-qcom 1d84000.ufshc: __ufshcd_wl_suspend - 8709
[   11.374366][T5] ufs_device_wlun 0:0:0:49488: __ufshcd_wl_suspend -
(0) has rpm_active flags


Do you mean that rpm_active of the link between the consumer and the
supplier is greater than 0 at this point and the consumer is


I mean is rpm_active of the link greater than 1 (because 1 means "no
active references to the supplier")?

Hi Rafael:
No - it is not greater than 1.

I'm trying to understand what's going on in it; will update when I've something.




RPM_ACTIVE, but the supplier suspends successfully nevertheless?


[   11.383376][T5] ufs_device_wlun 0:0:0:49488:
ufshcd_wl_runtime_suspend <-- Supplier suspends fine.
[   12.977318][  T174] sd 0:0:0:4: [sde] Synchronizing SCSI cache

And the the suspend of sde is stuck now:
schedule+0x9c/0xe0
schedule_timeout+0x40/0x128
io_schedule_timeout+0x44/0x68
wait_for_common_io+0x7c/0x100
wait_for_completion_io+0x14/0x20
blk_execute_rq+0x90/0xcc
__scsi_execute+0x104/0x1c4
sd_sync_cache+0xf8/0x2a0
sd_suspend_common+0x74/0x11c
sd_suspend_runtime+0x14/0x20
scsi_runtime_suspend+0x64/0x94
__rpm_callback+0x80/0x2a4
rpm_suspend+0x308/0x614
pm_runtime_work+0x98/0xa8

I added 'DL_FLAG_RPM_ACTIVE' while creating links.
   if (hba->sdev_ufs_device) {
   link = device_link_add(>sdev_gendev,
   >sdev_ufs_device->sdev_gendev,
  DL_FLAG_PM_RUNTIME|DL_FLAG_RPM_ACTIVE);
I didn't expect this to resolve the issue anyway and it didn't.

Another interesting point here is when I resume any of the above suspended
consumers, it all goes back to normal, which is kind of expected. I tried
resuming the consumer and the supplier is resumed and the supplier is
suspended when all the consumers are suspended.

Any pointers on this issue please?

@Bart/@Alan - Do you've any pointers please?


It's very noticeable that although you seem to have isolated a bug in
the power management subsystem (supplier goes into runtime suspend
even when one of its consumers is still active), you did not CC the
power management maintainer or mailing list.

I have added the appropriate CC's.


Thanks Alan!





Hello
I & Can (thanks CanG) debugged this further:

Looks like this issue can occur if the sd probe is asynchronous.

Essentially, the sd_probe() is done asynchronously and driver_probe_device() 
invokes pm_runtime_get_suppliers() before invoking sd_probe().

But scsi_probe_and_add_lun() runs in a separate context.
So the scsi_autopm_put_device() invoked from scsi_scan_host() context reduces the 
link->rpm_active to 1. And sd_probe() invokes scsi_autopm_put_device() and starts 
a timer. And then driver_probe_device() invoked from __device_attach_async_helper 
context reduces the link->rpm_active to 1 thus enabling the supplier to suspend 
b

Re: [PATCH v10 1/2] scsi: ufs: Enable power management for wlun

[Asutosh Das (asd)]

On 3/18/2021 7:00 AM, Rafael J. Wysocki wrote:

On Wed, Mar 17, 2021 at 7:37 AM Adrian Hunter  wrote:


On 16/03/21 10:35 pm, Asutosh Das (asd) wrote:

On 3/16/2021 12:48 AM, Adrian Hunter wrote:

On 16/03/21 12:22 am, Asutosh Das (asd) wrote:

On 3/14/2021 1:11 AM, Adrian Hunter wrote:

On 10/03/21 5:04 am, Asutosh Das (asd) wrote:

On 3/9/2021 7:56 AM, Asutosh Das (asd) wrote:

On 3/8/2021 9:17 AM, Rafael J. Wysocki wrote:

On Mon, Mar 8, 2021 at 5:21 PM Rafael J. Wysocki  wrote:


On Sat, Mar 6, 2021 at 5:17 PM Alan Stern  wrote:


On Fri, Mar 05, 2021 at 06:54:24PM -0800, Asutosh Das (asd) wrote:


Now during my testing I see a weird issue sometimes (1 in 7).
Scenario - bootups

Issue:
The supplier 'ufs_device_wlun 0:0:0:49488' goes into runtime suspend even
when one/more of its consumers are in RPM_ACTIVE state.

*Log:
[   10.056379][  T206] sd 0:0:0:1: [sdb] Synchronizing SCSI cache
[   10.062497][  T113] sd 0:0:0:5: [sdf] Synchronizing SCSI cache
[   10.356600][   T32] sd 0:0:0:7: [sdh] Synchronizing SCSI cache
[   10.362944][  T174] sd 0:0:0:3: [sdd] Synchronizing SCSI cache
[   10.696627][   T83] sd 0:0:0:2: [sdc] Synchronizing SCSI cache
[   10.704562][  T170] sd 0:0:0:6: [sdg] Synchronizing SCSI cache
[   10.980602][T5] sd 0:0:0:0: [sda] Synchronizing SCSI cache

/** Printing all the consumer nodes of supplier **/
[   10.987327][T5] ufs_device_wlun 0:0:0:49488: usage-count @ suspend: 0
<-- this is the usage_count
[   10.994440][T5] ufs_rpmb_wlun 0:0:0:49476: PM state - 2
[   11.000402][T5] scsi 0:0:0:49456: PM state - 2
[   11.005453][T5] sd 0:0:0:0: PM state - 2
[   11.009958][T5] sd 0:0:0:1: PM state - 2
[   11.014469][T5] sd 0:0:0:2: PM state - 2
[   11.019072][T5] sd 0:0:0:3: PM state - 2
[   11.023595][T5] sd 0:0:0:4: PM state - 0 << RPM_ACTIVE
[   11.353298][T5] sd 0:0:0:5: PM state - 2
[   11.357726][T5] sd 0:0:0:6: PM state - 2
[   11.362155][T5] sd 0:0:0:7: PM state - 2
[   11.366584][T5] ufshcd-qcom 1d84000.ufshc: __ufshcd_wl_suspend - 8709
[   11.374366][T5] ufs_device_wlun 0:0:0:49488: __ufshcd_wl_suspend -
(0) has rpm_active flags


Do you mean that rpm_active of the link between the consumer and the
supplier is greater than 0 at this point and the consumer is


I mean is rpm_active of the link greater than 1 (because 1 means "no
active references to the supplier")?

Hi Rafael:
No - it is not greater than 1.

I'm trying to understand what's going on in it; will update when I've something.




RPM_ACTIVE, but the supplier suspends successfully nevertheless?


[   11.383376][T5] ufs_device_wlun 0:0:0:49488:
ufshcd_wl_runtime_suspend <-- Supplier suspends fine.
[   12.977318][  T174] sd 0:0:0:4: [sde] Synchronizing SCSI cache

And the the suspend of sde is stuck now:
schedule+0x9c/0xe0
schedule_timeout+0x40/0x128
io_schedule_timeout+0x44/0x68
wait_for_common_io+0x7c/0x100
wait_for_completion_io+0x14/0x20
blk_execute_rq+0x90/0xcc
__scsi_execute+0x104/0x1c4
sd_sync_cache+0xf8/0x2a0
sd_suspend_common+0x74/0x11c
sd_suspend_runtime+0x14/0x20
scsi_runtime_suspend+0x64/0x94
__rpm_callback+0x80/0x2a4
rpm_suspend+0x308/0x614
pm_runtime_work+0x98/0xa8

I added 'DL_FLAG_RPM_ACTIVE' while creating links.
  if (hba->sdev_ufs_device) {
  link = device_link_add(>sdev_gendev,
  >sdev_ufs_device->sdev_gendev,
 DL_FLAG_PM_RUNTIME|DL_FLAG_RPM_ACTIVE);
I didn't expect this to resolve the issue anyway and it didn't.

Another interesting point here is when I resume any of the above suspended
consumers, it all goes back to normal, which is kind of expected. I tried
resuming the consumer and the supplier is resumed and the supplier is
suspended when all the consumers are suspended.

Any pointers on this issue please?

@Bart/@Alan - Do you've any pointers please?


It's very noticeable that although you seem to have isolated a bug in
the power management subsystem (supplier goes into runtime suspend
even when one of its consumers is still active), you did not CC the
power management maintainer or mailing list.

I have added the appropriate CC's.


Thanks Alan!





Hello
I & Can (thanks CanG) debugged this further:

Looks like this issue can occur if the sd probe is asynchronous.

Essentially, the sd_probe() is done asynchronously and driver_probe_device() 
invokes pm_runtime_get_suppliers() before invoking sd_probe().

But scsi_probe_and_add_lun() runs in a separate context.
So the scsi_autopm_put_device() invoked from scsi_scan_host() context reduces the 
link->rpm_active to 1. And sd_probe() invokes scsi_autopm_put_device() and starts 
a timer. And then driver_probe_device() invoked from __device_attach_async_helper 
context reduces the link->rpm_active to 1 thus enabling the supplier to suspend 
before the consumer suspends.

So if:
Context T1:
[1] scsi_probe_and_add_lun()
[2]|- scsi_autopm_put_device()

Re: [PATCH v10 1/2] scsi: ufs: Enable power management for wlun

[Asutosh Das (asd)]

On 3/16/2021 12:48 AM, Adrian Hunter wrote:

On 16/03/21 12:22 am, Asutosh Das (asd) wrote:

On 3/14/2021 1:11 AM, Adrian Hunter wrote:

On 10/03/21 5:04 am, Asutosh Das (asd) wrote:

On 3/9/2021 7:56 AM, Asutosh Das (asd) wrote:

On 3/8/2021 9:17 AM, Rafael J. Wysocki wrote:

On Mon, Mar 8, 2021 at 5:21 PM Rafael J. Wysocki  wrote:


On Sat, Mar 6, 2021 at 5:17 PM Alan Stern  wrote:


On Fri, Mar 05, 2021 at 06:54:24PM -0800, Asutosh Das (asd) wrote:


Now during my testing I see a weird issue sometimes (1 in 7).
Scenario - bootups

Issue:
The supplier 'ufs_device_wlun 0:0:0:49488' goes into runtime suspend even
when one/more of its consumers are in RPM_ACTIVE state.

*Log:
[   10.056379][  T206] sd 0:0:0:1: [sdb] Synchronizing SCSI cache
[   10.062497][  T113] sd 0:0:0:5: [sdf] Synchronizing SCSI cache
[   10.356600][   T32] sd 0:0:0:7: [sdh] Synchronizing SCSI cache
[   10.362944][  T174] sd 0:0:0:3: [sdd] Synchronizing SCSI cache
[   10.696627][   T83] sd 0:0:0:2: [sdc] Synchronizing SCSI cache
[   10.704562][  T170] sd 0:0:0:6: [sdg] Synchronizing SCSI cache
[   10.980602][    T5] sd 0:0:0:0: [sda] Synchronizing SCSI cache

/** Printing all the consumer nodes of supplier **/
[   10.987327][    T5] ufs_device_wlun 0:0:0:49488: usage-count @ suspend: 0
<-- this is the usage_count
[   10.994440][    T5] ufs_rpmb_wlun 0:0:0:49476: PM state - 2
[   11.000402][    T5] scsi 0:0:0:49456: PM state - 2
[   11.005453][    T5] sd 0:0:0:0: PM state - 2
[   11.009958][    T5] sd 0:0:0:1: PM state - 2
[   11.014469][    T5] sd 0:0:0:2: PM state - 2
[   11.019072][    T5] sd 0:0:0:3: PM state - 2
[   11.023595][    T5] sd 0:0:0:4: PM state - 0 << RPM_ACTIVE
[   11.353298][    T5] sd 0:0:0:5: PM state - 2
[   11.357726][    T5] sd 0:0:0:6: PM state - 2
[   11.362155][    T5] sd 0:0:0:7: PM state - 2
[   11.366584][    T5] ufshcd-qcom 1d84000.ufshc: __ufshcd_wl_suspend - 8709
[   11.374366][    T5] ufs_device_wlun 0:0:0:49488: __ufshcd_wl_suspend -
(0) has rpm_active flags


Do you mean that rpm_active of the link between the consumer and the
supplier is greater than 0 at this point and the consumer is


I mean is rpm_active of the link greater than 1 (because 1 means "no
active references to the supplier")?

Hi Rafael:
No - it is not greater than 1.

I'm trying to understand what's going on in it; will update when I've something.




RPM_ACTIVE, but the supplier suspends successfully nevertheless?


[   11.383376][    T5] ufs_device_wlun 0:0:0:49488:
ufshcd_wl_runtime_suspend <-- Supplier suspends fine.
[   12.977318][  T174] sd 0:0:0:4: [sde] Synchronizing SCSI cache

And the the suspend of sde is stuck now:
schedule+0x9c/0xe0
schedule_timeout+0x40/0x128
io_schedule_timeout+0x44/0x68
wait_for_common_io+0x7c/0x100
wait_for_completion_io+0x14/0x20
blk_execute_rq+0x90/0xcc
__scsi_execute+0x104/0x1c4
sd_sync_cache+0xf8/0x2a0
sd_suspend_common+0x74/0x11c
sd_suspend_runtime+0x14/0x20
scsi_runtime_suspend+0x64/0x94
__rpm_callback+0x80/0x2a4
rpm_suspend+0x308/0x614
pm_runtime_work+0x98/0xa8

I added 'DL_FLAG_RPM_ACTIVE' while creating links.
     if (hba->sdev_ufs_device) {
     link = device_link_add(>sdev_gendev,
     >sdev_ufs_device->sdev_gendev,
    DL_FLAG_PM_RUNTIME|DL_FLAG_RPM_ACTIVE);
I didn't expect this to resolve the issue anyway and it didn't.

Another interesting point here is when I resume any of the above suspended
consumers, it all goes back to normal, which is kind of expected. I tried
resuming the consumer and the supplier is resumed and the supplier is
suspended when all the consumers are suspended.

Any pointers on this issue please?

@Bart/@Alan - Do you've any pointers please?


It's very noticeable that although you seem to have isolated a bug in
the power management subsystem (supplier goes into runtime suspend
even when one of its consumers is still active), you did not CC the
power management maintainer or mailing list.

I have added the appropriate CC's.


Thanks Alan!





Hello
I & Can (thanks CanG) debugged this further:

Looks like this issue can occur if the sd probe is asynchronous.

Essentially, the sd_probe() is done asynchronously and driver_probe_device() 
invokes pm_runtime_get_suppliers() before invoking sd_probe().

But scsi_probe_and_add_lun() runs in a separate context.
So the scsi_autopm_put_device() invoked from scsi_scan_host() context reduces the 
link->rpm_active to 1. And sd_probe() invokes scsi_autopm_put_device() and starts 
a timer. And then driver_probe_device() invoked from __device_attach_async_helper 
context reduces the link->rpm_active to 1 thus enabling the supplier to suspend 
before the consumer suspends.

So if:
Context T1:
[1] scsi_probe_and_add_lun()
[2]    |- scsi_autopm_put_device() - reduce the link->rpm_active to 1

Context T2:
__device_attach_async_helper()
  |- driver_probe_device()
  |- sd_probe()
In between [1]

Re: [PATCH v11 1/2] scsi: ufs: Enable power management for wlun

[Asutosh Das (asd)]

On 3/15/2021 7:29 AM, Adrian Hunter wrote:

On 12/03/21 12:19 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 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.


I haven't had time to try to reproduce the device-links issue, but
there are a couple of comments below, in addition to the suggestions
here:

https://lore.kernel.org/linux-scsi/b13086f3-eea1-51a7-2117-579d520f2...@intel.com/

Also, there are still ufshcd_err_handling_prepare()/unprepare()
and ufshcd_recover_pm_error(), that look like they need attention
e.g. to use scsi_autopm_get/put_device(hba->sdev_ufs_device)



Hi Adrian,
Thanks for the suggestions and review.

Sorry I'd missed this mail.

Let me go through it and I'll get back.



Co-developed-by: Can Guo 
Signed-off-by: Can Guo 
Signed-off-by: Asutosh Das 
---
  drivers/scsi/ufs/cdns-pltfrm.c |   2 +
  drivers/scsi/ufs/tc-dwc-g210-pci.c |   2 +
  drivers/scsi/ufs/ufs-debugfs.c |   5 +
  drivers/scsi/ufs/ufs-debugfs.h |   2 +
  drivers/scsi/ufs/ufs-exynos.c  |   2 +
  drivers/scsi/ufs/ufs-hisi.c|   2 +
  drivers/scsi/ufs/ufs-mediatek.c|   2 +
  drivers/scsi/ufs/ufs-qcom.c|   2 +
  drivers/scsi/ufs/ufs_bsg.c |   6 +-
  drivers/scsi/ufs/ufshcd-pci.c  |  36 +--
  drivers/scsi/ufs/ufshcd.c  | 616 ++---
  drivers/scsi/ufs/ufshcd.h  |   7 +
  include/trace/events/ufs.h |  20 ++
  13 files changed, 498 insertions(+), 206 deletions(-)

diff --git a/drivers/scsi/ufs/cdns-pltfrm.c b/drivers/scsi/ufs/cdns-pltfrm.c
index 149391f..3e70c23 100644
--- a/drivers/scsi/ufs/cdns-pltfrm.c
+++ b/drivers/scsi/ufs/cdns-pltfrm.c
@@ -319,6 +319,8 @@ static const struct dev_pm_ops cdns_ufs_dev_pm_ops = {
.runtime_suspend = ufshcd_pltfrm_runtime_suspend,
.runtime_resume  = ufshcd_pltfrm_runtime_resume,
.runtime_idle= ufshcd_pltfrm_runtime_idle,
+   .prepare = ufshcd_suspend_prepare,
+   .complete   = ufshcd_resume_complete,
  };
  
  static struct platform_driver cdns_ufs_pltfrm_driver = {

diff --git a/drivers/scsi/ufs/tc-dwc-g210-pci.c 
b/drivers/scsi/ufs/tc-dwc-g210-pci.c
index 67a6a61..b01db12 100644
--- a/drivers/scsi/ufs/tc-dwc-g210-pci.c
+++ b/drivers/scsi/ufs/tc-dwc-g210-pci.c
@@ -148,6 +148,8 @@ static const struct dev_pm_ops tc_dwc_g210_pci_pm_ops = {
.runtime_suspend = tc_dwc_g210_pci_runtime_suspend,
.runtime_resume  = tc_dwc_g210_pci_runtime_resume,
.runtime_idle= tc_dwc_g210_pci_runtime_idle,
+   .prepare = ufshcd_suspend_prepare,
+   .complete   = ufshcd_resume_complete,
  };
  
  static const struct pci_device_id tc_dwc_g210_pci_tbl[] = {

diff --git a/drivers/scsi/ufs/ufs-debugfs.c b/drivers/scsi/ufs/ufs-debugfs.c
index dee98dc..f8ce2eb 100644
--- a/drivers/scsi/ufs/ufs-debugfs.c
+++ b/drivers/scsi/ufs/ufs-debugfs.c
@@ -54,3 +54,8 @@ void ufs_debugfs_hba_exit(struct ufs_hba *hba)
  {
debugfs_remove_recursive(hba->debugfs_root);
  }
+
+void ufs_debugfs_eh_exit(void)
+{
+   debugfs_remove_recursive(ufs_debugfs_root);
+}


This is the same as ufs_debugfs_exit() without __exit so why not
remove __exit from ufs_debugfs_exit() and use that instead?


diff --git a/drivers/scsi/ufs/ufs-debugfs.h b/drivers/scsi/ufs/ufs-debugfs.h
index f35b39c..3fce5a0 100644
--- a/drivers/scsi/ufs/ufs-debugfs.h
+++ b/drivers/scsi/ufs/ufs-debugfs.h
@@ -12,11 +12,13 @@ void __init ufs_debugfs_init(void);
  void __exit ufs_debugfs_exit(void);
  void ufs_debugfs_hba_init(struct ufs_hba *hba);
  void ufs_debugfs_hba_exit(struct ufs_hba *hba);
+void ufs_debugfs_eh_exit(void);
  #else
  static inline void ufs_debugfs_init(void) {}
  static inline void ufs_debugfs_exit(void) {}
  static inline void 

Re: [PATCH v10 1/2] scsi: ufs: Enable power management for wlun

[Asutosh Das (asd)]

On 3/14/2021 1:11 AM, Adrian Hunter wrote:

On 10/03/21 5:04 am, Asutosh Das (asd) wrote:

On 3/9/2021 7:56 AM, Asutosh Das (asd) wrote:

On 3/8/2021 9:17 AM, Rafael J. Wysocki wrote:

On Mon, Mar 8, 2021 at 5:21 PM Rafael J. Wysocki  wrote:


On Sat, Mar 6, 2021 at 5:17 PM Alan Stern  wrote:


On Fri, Mar 05, 2021 at 06:54:24PM -0800, Asutosh Das (asd) wrote:


Now during my testing I see a weird issue sometimes (1 in 7).
Scenario - bootups

Issue:
The supplier 'ufs_device_wlun 0:0:0:49488' goes into runtime suspend even
when one/more of its consumers are in RPM_ACTIVE state.

*Log:
[   10.056379][  T206] sd 0:0:0:1: [sdb] Synchronizing SCSI cache
[   10.062497][  T113] sd 0:0:0:5: [sdf] Synchronizing SCSI cache
[   10.356600][   T32] sd 0:0:0:7: [sdh] Synchronizing SCSI cache
[   10.362944][  T174] sd 0:0:0:3: [sdd] Synchronizing SCSI cache
[   10.696627][   T83] sd 0:0:0:2: [sdc] Synchronizing SCSI cache
[   10.704562][  T170] sd 0:0:0:6: [sdg] Synchronizing SCSI cache
[   10.980602][    T5] sd 0:0:0:0: [sda] Synchronizing SCSI cache

/** Printing all the consumer nodes of supplier **/
[   10.987327][    T5] ufs_device_wlun 0:0:0:49488: usage-count @ suspend: 0
<-- this is the usage_count
[   10.994440][    T5] ufs_rpmb_wlun 0:0:0:49476: PM state - 2
[   11.000402][    T5] scsi 0:0:0:49456: PM state - 2
[   11.005453][    T5] sd 0:0:0:0: PM state - 2
[   11.009958][    T5] sd 0:0:0:1: PM state - 2
[   11.014469][    T5] sd 0:0:0:2: PM state - 2
[   11.019072][    T5] sd 0:0:0:3: PM state - 2
[   11.023595][    T5] sd 0:0:0:4: PM state - 0 << RPM_ACTIVE
[   11.353298][    T5] sd 0:0:0:5: PM state - 2
[   11.357726][    T5] sd 0:0:0:6: PM state - 2
[   11.362155][    T5] sd 0:0:0:7: PM state - 2
[   11.366584][    T5] ufshcd-qcom 1d84000.ufshc: __ufshcd_wl_suspend - 8709
[   11.374366][    T5] ufs_device_wlun 0:0:0:49488: __ufshcd_wl_suspend -
(0) has rpm_active flags


Do you mean that rpm_active of the link between the consumer and the
supplier is greater than 0 at this point and the consumer is


I mean is rpm_active of the link greater than 1 (because 1 means "no
active references to the supplier")?

Hi Rafael:
No - it is not greater than 1.

I'm trying to understand what's going on in it; will update when I've something.




RPM_ACTIVE, but the supplier suspends successfully nevertheless?


[   11.383376][    T5] ufs_device_wlun 0:0:0:49488:
ufshcd_wl_runtime_suspend <-- Supplier suspends fine.
[   12.977318][  T174] sd 0:0:0:4: [sde] Synchronizing SCSI cache

And the the suspend of sde is stuck now:
schedule+0x9c/0xe0
schedule_timeout+0x40/0x128
io_schedule_timeout+0x44/0x68
wait_for_common_io+0x7c/0x100
wait_for_completion_io+0x14/0x20
blk_execute_rq+0x90/0xcc
__scsi_execute+0x104/0x1c4
sd_sync_cache+0xf8/0x2a0
sd_suspend_common+0x74/0x11c
sd_suspend_runtime+0x14/0x20
scsi_runtime_suspend+0x64/0x94
__rpm_callback+0x80/0x2a4
rpm_suspend+0x308/0x614
pm_runtime_work+0x98/0xa8

I added 'DL_FLAG_RPM_ACTIVE' while creating links.
    if (hba->sdev_ufs_device) {
    link = device_link_add(>sdev_gendev,
    >sdev_ufs_device->sdev_gendev,
   DL_FLAG_PM_RUNTIME|DL_FLAG_RPM_ACTIVE);
I didn't expect this to resolve the issue anyway and it didn't.

Another interesting point here is when I resume any of the above suspended
consumers, it all goes back to normal, which is kind of expected. I tried
resuming the consumer and the supplier is resumed and the supplier is
suspended when all the consumers are suspended.

Any pointers on this issue please?

@Bart/@Alan - Do you've any pointers please?


It's very noticeable that although you seem to have isolated a bug in
the power management subsystem (supplier goes into runtime suspend
even when one of its consumers is still active), you did not CC the
power management maintainer or mailing list.

I have added the appropriate CC's.


Thanks Alan!





Hello
I & Can (thanks CanG) debugged this further:

Looks like this issue can occur if the sd probe is asynchronous.

Essentially, the sd_probe() is done asynchronously and driver_probe_device() 
invokes pm_runtime_get_suppliers() before invoking sd_probe().

But scsi_probe_and_add_lun() runs in a separate context.
So the scsi_autopm_put_device() invoked from scsi_scan_host() context reduces the 
link->rpm_active to 1. And sd_probe() invokes scsi_autopm_put_device() and starts 
a timer. And then driver_probe_device() invoked from __device_attach_async_helper 
context reduces the link->rpm_active to 1 thus enabling the supplier to suspend 
before the consumer suspends.

So if:
Context T1:
[1] scsi_probe_and_add_lun()
[2]    |- scsi_autopm_put_device() - reduce the link->rpm_active to 1

Context T2:
__device_attach_async_helper()
 |- driver_probe_device()
     |- sd_probe()
In between [1] and [2] say, driver_probe_device() -> sd_probe() is invoked in a 
separate context from __dev

Re: [PATCH v10 1/2] scsi: ufs: Enable power management for wlun

[Asutosh Das (asd)]

On 3/10/2021 8:27 AM, Alan Stern wrote:

On Tue, Mar 09, 2021 at 08:04:53PM -0800, Asutosh Das (asd) wrote:

On 3/9/2021 7:14 PM, Alan Stern wrote:

On Tue, Mar 09, 2021 at 07:04:34PM -0800, Asutosh Das (asd) wrote:

Hello
I & Can (thanks CanG) debugged this further:

Looks like this issue can occur if the sd probe is asynchronous.

Essentially, the sd_probe() is done asynchronously and driver_probe_device()
invokes pm_runtime_get_suppliers() before invoking sd_probe().

But scsi_probe_and_add_lun() runs in a separate context.
So the scsi_autopm_put_device() invoked from scsi_scan_host() context
reduces the link->rpm_active to 1. And sd_probe() invokes
scsi_autopm_put_device() and starts a timer. And then driver_probe_device()
invoked from __device_attach_async_helper context reduces the
link->rpm_active to 1 thus enabling the supplier to suspend before the
consumer suspends.



I don't see a way around this. Please let me know if you
(@Alan/@Bart/@Adrian) have any thoughts on this.


How about changing the SCSI core so that it does a runtime_get before
starting an async probe, and the async probe routine does a
runtime_put when it is finished?  In other words, don't allow a device
to go into runtime suspend while it is waiting to be probed.

I don't think that would be too intrusive.

Alan Stern



Hi Alan
Thanks for the suggestion.

Am trying to understand:

Do you mean something like this:

int scsi_sysfs_add_sdev(struct scsi_device *sdev)
{

scsi_autopm_get_device(sdev);
pm_runtime_get_noresume(>sdev_gendev);
[...]
scsi_autopm_put_device(sdev);
[...]
}

static int sd_probe(struct device *dev)
{
[...]
pm_runtime_put_noidle(dev);
scsi_autopm_put_device(sdp);
[...]
}

This may work (I'm limited by my imagination in scsi layer :) ).


I'm not sure about this.  To be honest, I did not read the entirety of
your last message; it had way too much detail.  THere's a time and place
for that, but when you're brainstorming to figure out the underlying
cause of a problem and come up with a strategy to fix it, you want to
concentrate on the overall picture, not the details.

As I understand the situation, you've get a SCSI target with multiple
logical units, let's say A and B, and you need to make sure that A never
goes into runtime suspend unless B is already suspended.  In other
words, B always has to suspend before A and resume after A.

To do this, you register a device link with A as the supplier and B as
the consumer.  Then the PM core takes care of the ordering for you.

But I don't understand when you set up the device link.  If the timing
is wrong then, thanks to async SCSI probing, you may have a situation
where A is registered before B and before the link is set up.  Then
there's temporarily nothing to stop A from suspending before B.

You also need to prevent each device from suspending before it is
probed.  That's the easy part I was trying to address before (although
it may not be so easy if the drivers are in loadable modules and not
present in the kernel).

You need to think through these issues before proposing actual changes.


But the pm_runtime_put_noidle() would have to be added to all registered
scsi_driver{}, perhaps? Or may be I can check for sdp->type?


Like this; it's too early to worry about this sort of thing.

Alan Stern


Hi Alan
Thanks. Understood.

I will check the details and see if I can come up with something.
I'll propose an alternate fix otherwise and drop this change altogether.

Thanks!
-asd

--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
Linux Foundation Collaborative Project

Re: [PATCH v10 1/2] scsi: ufs: Enable power management for wlun

[Asutosh Das (asd)]

On 3/9/2021 7:14 PM, Alan Stern wrote:

On Tue, Mar 09, 2021 at 07:04:34PM -0800, Asutosh Das (asd) wrote:

Hello
I & Can (thanks CanG) debugged this further:

Looks like this issue can occur if the sd probe is asynchronous.

Essentially, the sd_probe() is done asynchronously and driver_probe_device()
invokes pm_runtime_get_suppliers() before invoking sd_probe().

But scsi_probe_and_add_lun() runs in a separate context.
So the scsi_autopm_put_device() invoked from scsi_scan_host() context
reduces the link->rpm_active to 1. And sd_probe() invokes
scsi_autopm_put_device() and starts a timer. And then driver_probe_device()
invoked from __device_attach_async_helper context reduces the
link->rpm_active to 1 thus enabling the supplier to suspend before the
consumer suspends.



I don't see a way around this. Please let me know if you
(@Alan/@Bart/@Adrian) have any thoughts on this.


How about changing the SCSI core so that it does a runtime_get before
starting an async probe, and the async probe routine does a
runtime_put when it is finished?  In other words, don't allow a device
to go into runtime suspend while it is waiting to be probed.

I don't think that would be too intrusive.

Alan Stern



Hi Alan
Thanks for the suggestion.

Am trying to understand:

Do you mean something like this:

int scsi_sysfs_add_sdev(struct scsi_device *sdev)
{

scsi_autopm_get_device(sdev);
pm_runtime_get_noresume(>sdev_gendev);
[...]
scsi_autopm_put_device(sdev);
[...]
}

static int sd_probe(struct device *dev)
{
[...]
pm_runtime_put_noidle(dev);
scsi_autopm_put_device(sdp);
[...]
}

This may work (I'm limited by my imagination in scsi layer :) ).

But the pm_runtime_put_noidle() would have to be added to all registered 
scsi_driver{}, perhaps? Or may be I can check for sdp->type?


-asd

--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
Linux Foundation Collaborative Project

Re: [PATCH v10 1/2] scsi: ufs: Enable power management for wlun

[Asutosh Das (asd)]

On 3/9/2021 7:56 AM, Asutosh Das (asd) wrote:

On 3/8/2021 9:17 AM, Rafael J. Wysocki wrote:
On Mon, Mar 8, 2021 at 5:21 PM Rafael J. Wysocki  
wrote:


On Sat, Mar 6, 2021 at 5:17 PM Alan Stern  
wrote:


On Fri, Mar 05, 2021 at 06:54:24PM -0800, Asutosh Das (asd) wrote:


Now during my testing I see a weird issue sometimes (1 in 7).
Scenario - bootups

Issue:
The supplier 'ufs_device_wlun 0:0:0:49488' goes into runtime 
suspend even

when one/more of its consumers are in RPM_ACTIVE state.

*Log:
[   10.056379][  T206] sd 0:0:0:1: [sdb] Synchronizing SCSI cache
[   10.062497][  T113] sd 0:0:0:5: [sdf] Synchronizing SCSI cache
[   10.356600][   T32] sd 0:0:0:7: [sdh] Synchronizing SCSI cache
[   10.362944][  T174] sd 0:0:0:3: [sdd] Synchronizing SCSI cache
[   10.696627][   T83] sd 0:0:0:2: [sdc] Synchronizing SCSI cache
[   10.704562][  T170] sd 0:0:0:6: [sdg] Synchronizing SCSI cache
[   10.980602][    T5] sd 0:0:0:0: [sda] Synchronizing SCSI cache

/** Printing all the consumer nodes of supplier **/
[   10.987327][    T5] ufs_device_wlun 0:0:0:49488: usage-count @ 
suspend: 0

<-- this is the usage_count
[   10.994440][    T5] ufs_rpmb_wlun 0:0:0:49476: PM state - 2
[   11.000402][    T5] scsi 0:0:0:49456: PM state - 2
[   11.005453][    T5] sd 0:0:0:0: PM state - 2
[   11.009958][    T5] sd 0:0:0:1: PM state - 2
[   11.014469][    T5] sd 0:0:0:2: PM state - 2
[   11.019072][    T5] sd 0:0:0:3: PM state - 2
[   11.023595][    T5] sd 0:0:0:4: PM state - 0 << RPM_ACTIVE
[   11.353298][    T5] sd 0:0:0:5: PM state - 2
[   11.357726][    T5] sd 0:0:0:6: PM state - 2
[   11.362155][    T5] sd 0:0:0:7: PM state - 2
[   11.366584][    T5] ufshcd-qcom 1d84000.ufshc: 
__ufshcd_wl_suspend - 8709
[   11.374366][    T5] ufs_device_wlun 0:0:0:49488: 
__ufshcd_wl_suspend -

(0) has rpm_active flags


Do you mean that rpm_active of the link between the consumer and the
supplier is greater than 0 at this point and the consumer is


I mean is rpm_active of the link greater than 1 (because 1 means "no
active references to the supplier")?

Hi Rafael:
No - it is not greater than 1.

I'm trying to understand what's going on in it; will update when I've 
something.





RPM_ACTIVE, but the supplier suspends successfully nevertheless?


[   11.383376][    T5] ufs_device_wlun 0:0:0:49488:
ufshcd_wl_runtime_suspend <-- Supplier suspends fine.
[   12.977318][  T174] sd 0:0:0:4: [sde] Synchronizing SCSI cache

And the the suspend of sde is stuck now:
schedule+0x9c/0xe0
schedule_timeout+0x40/0x128
io_schedule_timeout+0x44/0x68
wait_for_common_io+0x7c/0x100
wait_for_completion_io+0x14/0x20
blk_execute_rq+0x90/0xcc
__scsi_execute+0x104/0x1c4
sd_sync_cache+0xf8/0x2a0
sd_suspend_common+0x74/0x11c
sd_suspend_runtime+0x14/0x20
scsi_runtime_suspend+0x64/0x94
__rpm_callback+0x80/0x2a4
rpm_suspend+0x308/0x614
pm_runtime_work+0x98/0xa8

I added 'DL_FLAG_RPM_ACTIVE' while creating links.
   if (hba->sdev_ufs_device) {
   link = device_link_add(>sdev_gendev,
   >sdev_ufs_device->sdev_gendev,
  
DL_FLAG_PM_RUNTIME|DL_FLAG_RPM_ACTIVE);

I didn't expect this to resolve the issue anyway and it didn't.

Another interesting point here is when I resume any of the above 
suspended
consumers, it all goes back to normal, which is kind of expected. I 
tried

resuming the consumer and the supplier is resumed and the supplier is
suspended when all the consumers are suspended.

Any pointers on this issue please?

@Bart/@Alan - Do you've any pointers please?


It's very noticeable that although you seem to have isolated a bug in
the power management subsystem (supplier goes into runtime suspend
even when one of its consumers is still active), you did not CC the
power management maintainer or mailing list.

I have added the appropriate CC's.


Thanks Alan!





Hello
I & Can (thanks CanG) debugged this further:

Looks like this issue can occur if the sd probe is asynchronous.

Essentially, the sd_probe() is done asynchronously and 
driver_probe_device() invokes pm_runtime_get_suppliers() before invoking 
sd_probe().


But scsi_probe_and_add_lun() runs in a separate context.
So the scsi_autopm_put_device() invoked from scsi_scan_host() context 
reduces the link->rpm_active to 1. And sd_probe() invokes 
scsi_autopm_put_device() and starts a timer. And then 
driver_probe_device() invoked from __device_attach_async_helper context 
reduces the link->rpm_active to 1 thus enabling the supplier to suspend 
before the consumer suspends.


So if:
Context T1:
[1] scsi_probe_and_add_lun()
[2] |- scsi_autopm_put_device() - reduce the link->rpm_active to 1

Context T2:
__device_attach_async_helper()
|- driver_probe_device()
|- sd_probe()
In between [1] and [2] say, driver_probe_device() -> sd_probe() is 
invoked in a separate context from __device_attach_async_helper().
The driver_probe_device() -> pm_runtime_g

Re: [PATCH v10 1/2] scsi: ufs: Enable power management for wlun

[Asutosh Das (asd)]

On 3/8/2021 9:17 AM, Rafael J. Wysocki wrote:

On Mon, Mar 8, 2021 at 5:21 PM Rafael J. Wysocki  wrote:


On Sat, Mar 6, 2021 at 5:17 PM Alan Stern  wrote:


On Fri, Mar 05, 2021 at 06:54:24PM -0800, Asutosh Das (asd) wrote:


Now during my testing I see a weird issue sometimes (1 in 7).
Scenario - bootups

Issue:
The supplier 'ufs_device_wlun 0:0:0:49488' goes into runtime suspend even
when one/more of its consumers are in RPM_ACTIVE state.

*Log:
[   10.056379][  T206] sd 0:0:0:1: [sdb] Synchronizing SCSI cache
[   10.062497][  T113] sd 0:0:0:5: [sdf] Synchronizing SCSI cache
[   10.356600][   T32] sd 0:0:0:7: [sdh] Synchronizing SCSI cache
[   10.362944][  T174] sd 0:0:0:3: [sdd] Synchronizing SCSI cache
[   10.696627][   T83] sd 0:0:0:2: [sdc] Synchronizing SCSI cache
[   10.704562][  T170] sd 0:0:0:6: [sdg] Synchronizing SCSI cache
[   10.980602][T5] sd 0:0:0:0: [sda] Synchronizing SCSI cache

/** Printing all the consumer nodes of supplier **/
[   10.987327][T5] ufs_device_wlun 0:0:0:49488: usage-count @ suspend: 0
<-- this is the usage_count
[   10.994440][T5] ufs_rpmb_wlun 0:0:0:49476: PM state - 2
[   11.000402][T5] scsi 0:0:0:49456: PM state - 2
[   11.005453][T5] sd 0:0:0:0: PM state - 2
[   11.009958][T5] sd 0:0:0:1: PM state - 2
[   11.014469][T5] sd 0:0:0:2: PM state - 2
[   11.019072][T5] sd 0:0:0:3: PM state - 2
[   11.023595][T5] sd 0:0:0:4: PM state - 0 << RPM_ACTIVE
[   11.353298][T5] sd 0:0:0:5: PM state - 2
[   11.357726][T5] sd 0:0:0:6: PM state - 2
[   11.362155][T5] sd 0:0:0:7: PM state - 2
[   11.366584][T5] ufshcd-qcom 1d84000.ufshc: __ufshcd_wl_suspend - 8709
[   11.374366][T5] ufs_device_wlun 0:0:0:49488: __ufshcd_wl_suspend -
(0) has rpm_active flags


Do you mean that rpm_active of the link between the consumer and the
supplier is greater than 0 at this point and the consumer is


I mean is rpm_active of the link greater than 1 (because 1 means "no
active references to the supplier")?

Hi Rafael:
No - it is not greater than 1.

I'm trying to understand what's going on in it; will update when I've 
something.





RPM_ACTIVE, but the supplier suspends successfully nevertheless?


[   11.383376][T5] ufs_device_wlun 0:0:0:49488:
ufshcd_wl_runtime_suspend <-- Supplier suspends fine.
[   12.977318][  T174] sd 0:0:0:4: [sde] Synchronizing SCSI cache

And the the suspend of sde is stuck now:
schedule+0x9c/0xe0
schedule_timeout+0x40/0x128
io_schedule_timeout+0x44/0x68
wait_for_common_io+0x7c/0x100
wait_for_completion_io+0x14/0x20
blk_execute_rq+0x90/0xcc
__scsi_execute+0x104/0x1c4
sd_sync_cache+0xf8/0x2a0
sd_suspend_common+0x74/0x11c
sd_suspend_runtime+0x14/0x20
scsi_runtime_suspend+0x64/0x94
__rpm_callback+0x80/0x2a4
rpm_suspend+0x308/0x614
pm_runtime_work+0x98/0xa8

I added 'DL_FLAG_RPM_ACTIVE' while creating links.
   if (hba->sdev_ufs_device) {
   link = device_link_add(>sdev_gendev,
   >sdev_ufs_device->sdev_gendev,
  DL_FLAG_PM_RUNTIME|DL_FLAG_RPM_ACTIVE);
I didn't expect this to resolve the issue anyway and it didn't.

Another interesting point here is when I resume any of the above suspended
consumers, it all goes back to normal, which is kind of expected. I tried
resuming the consumer and the supplier is resumed and the supplier is
suspended when all the consumers are suspended.

Any pointers on this issue please?

@Bart/@Alan - Do you've any pointers please?


It's very noticeable that although you seem to have isolated a bug in
the power management subsystem (supplier goes into runtime suspend
even when one of its consumers is still active), you did not CC the
power management maintainer or mailing list.

I have added the appropriate CC's.


Thanks Alan!



--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
Linux Foundation Collaborative Project

Re: [PATCH v10 1/2] scsi: ufs: Enable power management for wlun

[Asutosh Das (asd)]

On 3/4/2021 7:35 AM, Adrian Hunter wrote:

On 3/03/21 12:52 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 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.

Co-developed-by: Can Guo 
Signed-off-by: Can Guo 
Signed-off-by: Asutosh Das 


It looks good, but still a few further comments below.

Also, do you think ufshcd_err_handling_prepare()/unprepare()
need changes?  And ufshcd_recover_pm_error()?

And maybe ufshcd_auto_hibern8_update() when it is called from ufs_sysfs.c?


Hi Adrian
Sure, I'll fix it in the next version.

Now during my testing I see a weird issue sometimes (1 in 7).
Scenario - bootups

Issue:
The supplier 'ufs_device_wlun 0:0:0:49488' goes into runtime suspend 
even when one/more of its consumers are in RPM_ACTIVE state.


*Log:
[   10.056379][  T206] sd 0:0:0:1: [sdb] Synchronizing SCSI cache
[   10.062497][  T113] sd 0:0:0:5: [sdf] Synchronizing SCSI cache
[   10.356600][   T32] sd 0:0:0:7: [sdh] Synchronizing SCSI cache
[   10.362944][  T174] sd 0:0:0:3: [sdd] Synchronizing SCSI cache
[   10.696627][   T83] sd 0:0:0:2: [sdc] Synchronizing SCSI cache
[   10.704562][  T170] sd 0:0:0:6: [sdg] Synchronizing SCSI cache
[   10.980602][T5] sd 0:0:0:0: [sda] Synchronizing SCSI cache

/** Printing all the consumer nodes of supplier **/
[   10.987327][T5] ufs_device_wlun 0:0:0:49488: usage-count @ 
suspend: 0 <-- this is the usage_count

[   10.994440][T5] ufs_rpmb_wlun 0:0:0:49476: PM state - 2
[   11.000402][T5] scsi 0:0:0:49456: PM state - 2
[   11.005453][T5] sd 0:0:0:0: PM state - 2
[   11.009958][T5] sd 0:0:0:1: PM state - 2
[   11.014469][T5] sd 0:0:0:2: PM state - 2
[   11.019072][T5] sd 0:0:0:3: PM state - 2
[   11.023595][T5] sd 0:0:0:4: PM state - 0 << RPM_ACTIVE
[   11.353298][T5] sd 0:0:0:5: PM state - 2
[   11.357726][T5] sd 0:0:0:6: PM state - 2
[   11.362155][T5] sd 0:0:0:7: PM state - 2
[   11.366584][T5] ufshcd-qcom 1d84000.ufshc: __ufshcd_wl_suspend - 8709
[   11.374366][T5] ufs_device_wlun 0:0:0:49488: __ufshcd_wl_suspend 
- (0) has rpm_active flags
[   11.383376][T5] ufs_device_wlun 0:0:0:49488: 
ufshcd_wl_runtime_suspend <-- Supplier suspends fine.

[   12.977318][  T174] sd 0:0:0:4: [sde] Synchronizing SCSI cache

And the the suspend of sde is stuck now:
schedule+0x9c/0xe0
schedule_timeout+0x40/0x128
io_schedule_timeout+0x44/0x68
wait_for_common_io+0x7c/0x100
wait_for_completion_io+0x14/0x20
blk_execute_rq+0x90/0xcc
__scsi_execute+0x104/0x1c4
sd_sync_cache+0xf8/0x2a0
sd_suspend_common+0x74/0x11c
sd_suspend_runtime+0x14/0x20
scsi_runtime_suspend+0x64/0x94
__rpm_callback+0x80/0x2a4
rpm_suspend+0x308/0x614
pm_runtime_work+0x98/0xa8

I added 'DL_FLAG_RPM_ACTIVE' while creating links.
  if (hba->sdev_ufs_device) {
  link = device_link_add(>sdev_gendev,
  >sdev_ufs_device->sdev_gendev,
 DL_FLAG_PM_RUNTIME|DL_FLAG_RPM_ACTIVE);
I didn't expect this to resolve the issue anyway and it didn't.

Another interesting point here is when I resume any of the above 
suspended consumers, it all goes back to normal, which is kind of 
expected. I tried resuming the consumer and the supplier is resumed and 
the supplier is suspended when all the consumers are suspended.


Any pointers on this issue please?

@Bart/@Alan - Do you've any pointers please?

Thanks,
AsutoshD





---
  drivers/scsi/ufs/cdns-pltfrm.c |   2 +
  drivers/scsi/ufs/tc-dwc-g210-pci.c |   2 +
  drivers/scsi/ufs/ufs-exynos.c  |   2 +
  drivers/scsi/ufs/ufs-hisi.c|   2 +
  drivers/scsi/ufs/ufs-mediatek.c|   2 +
  drivers/scsi/ufs/ufs-qcom.c|   2 +
  drivers/scsi/ufs/ufs_bsg.c |   6 +-
  drivers/scsi/ufs/ufshcd-pci.c  |  32 

Re: [PATCH v1] scsi: ufs-mediatek: Enable UFSHCI_QUIRK_SKIP_MANUAL_WB_FLUSH_CTRL

[Asutosh Das (asd)]

On 12/24/2020 5:47 AM, Stanley Chu wrote:

Hi Avri, Bean,

On Thu, 2020-12-24 at 13:01 +0100, Bean Huo wrote:

On Thu, 2020-12-24 at 11:03 +, Avri Altman wrote:

Do you see any substantial benefit of having
fWriteBoosterBufferFlushEn
disabled?


1. The definition of fWriteBoosterBufferFlushEn is that host allows
device to do flush in anytime after fWriteBoosterBufferFlushEn is
set as
on. This is not what we want.

Just Like BKOP, We do not want flush happening beyond host's
expected
timing that device performance may be "randomly" dropped.


Explicit flush takes place only when the device is idle:
if fWriteBoosterBufferFlushEn is set, the device is idle, and before
h8 received.
If a request arrives, the flush operation should be halted.
So no performance degradation is expected.


Hi Stanley

Avri's comment is correct, fWriteBoosterBufferFlushEn==1, device will
flush only when it is in idle, once there is new incoming request, the
flush will be suspended. You should be very careful when you want to
skip this stetting of this flag.


Very appreciate your the clarification.

However similar to "Background Operations Termination Latency", while
the next request comes, device may need some time to suspend on-going
flush operations. This delay may "randomly" degrade the performance
right?



Have you actually seen this happening? I've not come across any random 
performance degradation concerns, hence asking.


From what I've observed is the handling of WB buffer flush depends on 
how flash vendors implement it. Some vendors that I've seen just create 
a separate WB buffer in an instant. I don't know the intricacies of 
their implementation, but I guess the new WB buffer handles the requests 
while the previous one is being flushed.
Anyway, for Qualcomm platforms we plan to have 
fWriteBoosterBufferFlushEn=1 by default.



Since the configuration, i.e., enable
fWriteBoosterBufferFlushDuringHibernate only with
fWriteBoosterBufferFlushEn disabled, has been applied in many of our
mass-produced products these yeas, we would like to keep it unless the
new setting has obvious benefits.

Thanks,
Stanley Chu



Bean






--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
Linux Foundation Collaborative Project

Re: [PATCH v2 2/2] scsi: ufs: Uninline ufshcd_vops_device_reset function

[Asutosh Das (asd)]

On 12/8/2020 5:56 AM, Stanley Chu wrote:

Since more and more statements showing up in ufshcd_vops_device_reset(),
uninline it to allow compiler making possibly better optimization.

Signed-off-by: Stanley Chu 
---


Reviewed-by: Asutosh Das 


  drivers/scsi/ufs/ufshcd.c | 27 ++-
  drivers/scsi/ufs/ufshcd.h | 19 +--
  2 files changed, 27 insertions(+), 19 deletions(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index c1c401b2b69d..b2ca1a6ad426 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -580,6 +580,23 @@ static void ufshcd_print_pwr_info(struct ufs_hba *hba)
 hba->pwr_info.hs_rate);
  }
  
+static void ufshcd_device_reset(struct ufs_hba *hba)

+{
+   int err;
+
+   err = ufshcd_vops_device_reset(hba);
+
+   if (!err) {
+   ufshcd_set_ufs_dev_active(hba);
+   if (ufshcd_is_wb_allowed(hba)) {
+   hba->wb_enabled = false;
+   hba->wb_buf_flush_enabled = false;
+   }
+   }
+   if (err != -EOPNOTSUPP)
+   ufshcd_update_evt_hist(hba, UFS_EVT_DEV_RESET, err);
+}
+
  void ufshcd_delay_us(unsigned long us, unsigned long tolerance)
  {
if (!us)
@@ -3932,7 +3949,7 @@ int ufshcd_link_recovery(struct ufs_hba *hba)
spin_unlock_irqrestore(hba->host->host_lock, flags);
  
  	/* Reset the attached device */

-   ufshcd_vops_device_reset(hba);
+   ufshcd_device_reset(hba);
  
  	ret = ufshcd_host_reset_and_restore(hba);
  
@@ -6933,7 +6950,7 @@ static int ufshcd_reset_and_restore(struct ufs_hba *hba)
  
  	do {

/* Reset the attached device */
-   ufshcd_vops_device_reset(hba);
+   ufshcd_device_reset(hba);
  
  		err = ufshcd_host_reset_and_restore(hba);

} while (err && --retries);
@@ -8712,7 +8729,7 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum 
ufs_pm_op pm_op)
 * further below.
 */
if (ufshcd_is_ufs_dev_deepsleep(hba)) {
-   ufshcd_vops_device_reset(hba);
+   ufshcd_device_reset(hba);
WARN_ON(!ufshcd_is_link_off(hba));
}
if (ufshcd_is_link_hibern8(hba) && !ufshcd_uic_hibern8_exit(hba))
@@ -8722,7 +8739,7 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum 
ufs_pm_op pm_op)
  set_dev_active:
/* Can also get here needing to exit DeepSleep */
if (ufshcd_is_ufs_dev_deepsleep(hba)) {
-   ufshcd_vops_device_reset(hba);
+   ufshcd_device_reset(hba);
ufshcd_host_reset_and_restore(hba);
}
if (!ufshcd_set_dev_pwr_mode(hba, UFS_ACTIVE_PWR_MODE))
@@ -9321,7 +9338,7 @@ int ufshcd_init(struct ufs_hba *hba, void __iomem 
*mmio_base, unsigned int irq)
}
  
  	/* Reset the attached device */

-   ufshcd_vops_device_reset(hba);
+   ufshcd_device_reset(hba);
  
  	ufshcd_init_crypto(hba);
  
diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h

index 36d367eb8139..9bb5f0ed4124 100644
--- a/drivers/scsi/ufs/ufshcd.h
+++ b/drivers/scsi/ufs/ufshcd.h
@@ -1216,21 +1216,12 @@ static inline void ufshcd_vops_dbg_register_dump(struct 
ufs_hba *hba)
hba->vops->dbg_register_dump(hba);
  }
  
-static inline void ufshcd_vops_device_reset(struct ufs_hba *hba)

+static inline int ufshcd_vops_device_reset(struct ufs_hba *hba)
  {
-   if (hba->vops && hba->vops->device_reset) {
-   int err = hba->vops->device_reset(hba);
-
-   if (!err) {
-   ufshcd_set_ufs_dev_active(hba);
-   if (ufshcd_is_wb_allowed(hba)) {
-   hba->wb_enabled = false;
-   hba->wb_buf_flush_enabled = false;
-   }
-   }
-   if (err != -EOPNOTSUPP)
-   ufshcd_update_evt_hist(hba, UFS_EVT_DEV_RESET, err);
-   }
+   if (hba->vops && hba->vops->device_reset)
+   return hba->vops->device_reset(hba);
+
+   return -EOPNOTSUPP;
  }
  
  static inline void ufshcd_vops_config_scaling_param(struct ufs_hba *hba,





--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
Linux Foundation Collaborative Project

Re: [PATCH v1 0/3] Refine error history and introduce notify_event vop

[Asutosh Das (asd)]

On 11/25/2020 9:38 PM, Stanley Chu wrote:

Hi,
This series refines error history functions and introduce a new notify_event 
vop to allow vendor to get notified of important events.

Stanley Chu (3):
   scsi: ufs: Add error history for abort event in UFS Device W-LUN
   scsi: ufs: Refine error history functions
   scsi: ufs: Introduce notify_event variant function

  drivers/scsi/ufs/ufshcd.c | 122 ++
  drivers/scsi/ufs/ufshcd.h |  82 -
  2 files changed, 112 insertions(+), 92 deletions(-)



Hi Stanley,

Reviewed-by: Asutosh Das 

Please add to the series.


--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
Linux Foundation Collaborative Project

Re: [PATCH 1/3] scsi: ufs: Add "wb_on" sysfs node to control WB on/off

[Asutosh Das (asd)]

On 12/2/2020 8:20 AM, Bean Huo wrote:

On Mon, 2020-11-30 at 15:19 -0800, Asutosh Das (asd) wrote:

+ return -EINVAL;
+
+ pm_runtime_get_sync(hba->dev);
+ res = ufshcd_wb_ctrl(hba, wb_enable);


Say, a platform supports clock-scaling and this bit is toggled.
The control goes into ufshcd_wb_ctrl for both this sysfs and
clock-scaling contexts. The clock-scaling context passes all checks
and
blocks on waiting for this wb control to be disabled and then tries
to
enable wb when it's already disabled. Perhaps that's a race there?


Hi Asutosh
Appreciate your review.
There is only inconsistent problem between clock-scaling and sysfs,
since hba->dev_cmd.lock can garantee there is only one can change
fWriteBoosterEn. But this is only happening on user willfully wants to
control WB through sysfs even they know the platform supports clock-
scaling.

Since this is for the platform which doesn't support clock-scaling, I
think based on your comments, it should be acceptable for you like
this:


Or a synchronization primitive b/w the 2 contexts would work just as 
well. However, I don't have an issue if the user is denied toggling of 
wb anyway. LGTM.





+static ssize_t wb_on_store(struct device *dev, struct device_attribute
*attr,
+  const char *buf, size_t count)
+{
+   struct ufs_hba *hba = dev_get_drvdata(dev);
+   unsigned int wb_enable;
+   ssize_t res;
+
+   if (ufshcd_is_clkscaling_supported(hba)) {
+  dev_err(dev, "supports dynamic clk scaling, control WB
+   through sysfs is not allowed!");
+  return -EOPNOTSUPP;
+   }
+   if (!ufshcd_is_wb_allowed(hba))
+   return -EOPNOTSUPP;
+
+   if (kstrtouint(buf, 0, _enable))
+   return -EINVAL;
+
+   if (wb_enable != 0 && wb_enable != 1)
+   return -EINVAL;
+
+   pm_runtime_get_sync(hba->dev);
+   res = ufshcd_wb_ctrl(hba, wb_enable);
+   pm_runtime_put_sync(hba->dev);
+
+   return res < 0 ? res : count;
+}

thanks,
Bean





--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
Linux Foundation Collaborative Project

Re: [PATCH v3 1/2] scsi: ufs: Refactor ufshcd_setup_clocks() to remove skip_ref_clk

[Asutosh Das (asd)]

On 11/30/2020 7:11 PM, Can Guo wrote:

On 2020-12-01 07:01, Asutosh Das (asd) wrote:

On 11/25/2020 6:01 PM, Can Guo wrote:
Remove the param skip_ref_clk from __ufshcd_setup_clocks(), but keep 
a flag
in struct ufs_clk_info to tell whether a clock can be disabled or not 
while

the link is active.

Reviewed-by: Hongwu Su
Reviewed-by: Bean Huo 
Reviewed-by: Stanley Chu 
Signed-off-by: Can Guo 
---
  drivers/scsi/ufs/ufshcd-pltfrm.c |  2 ++
  drivers/scsi/ufs/ufshcd.c    | 29 +
  drivers/scsi/ufs/ufshcd.h    |  3 +++
  3 files changed, 14 insertions(+), 20 deletions(-)

diff --git a/drivers/scsi/ufs/ufshcd-pltfrm.c 
b/drivers/scsi/ufs/ufshcd-pltfrm.c

index 3db0af6..873ef14 100644
--- a/drivers/scsi/ufs/ufshcd-pltfrm.c
+++ b/drivers/scsi/ufs/ufshcd-pltfrm.c
@@ -92,6 +92,8 @@ static int ufshcd_parse_clock_info(struct ufs_hba 
*hba)

  clki->min_freq = clkfreq[i];
  clki->max_freq = clkfreq[i+1];
  clki->name = kstrdup(name, GFP_KERNEL);
+    if (!strcmp(name, "ref_clk"))
+    clki->keep_link_active = true;
  dev_dbg(dev, "%s: min %u max %u name %s\n", "freq-table-hz",
  clki->min_freq, clki->max_freq, clki->name);
  list_add_tail(>list, >clk_list_head);
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index a7857f6..44254c9 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -221,8 +221,6 @@ static int ufshcd_eh_host_reset_handler(struct 
scsi_cmnd *cmd);

  static int ufshcd_clear_tm_cmd(struct ufs_hba *hba, int tag);
  static void ufshcd_hba_exit(struct ufs_hba *hba);
  static int ufshcd_probe_hba(struct ufs_hba *hba, bool async);
-static int __ufshcd_setup_clocks(struct ufs_hba *hba, bool on,
- bool skip_ref_clk);
  static int ufshcd_setup_clocks(struct ufs_hba *hba, bool on);
  static int ufshcd_uic_hibern8_enter(struct ufs_hba *hba);
  static inline void ufshcd_add_delay_before_dme_cmd(struct ufs_hba 
*hba);
@@ -1707,11 +1705,7 @@ static void ufshcd_gate_work(struct 
work_struct *work)

    ufshcd_disable_irq(hba);
  -    if (!ufshcd_is_link_active(hba))
-    ufshcd_setup_clocks(hba, false);
-    else
-    /* If link is active, device ref_clk can't be switched off */
-    __ufshcd_setup_clocks(hba, false, true);
+    ufshcd_setup_clocks(hba, false);
    /*
   * In case you are here to cancel this work the gating state
@@ -7990,8 +7984,7 @@ static int ufshcd_init_hba_vreg(struct ufs_hba 
*hba)

  return 0;
  }
  -static int __ufshcd_setup_clocks(struct ufs_hba *hba, bool on,
-    bool skip_ref_clk)
+static int ufshcd_setup_clocks(struct ufs_hba *hba, bool on)
  {
  int ret = 0;
  struct ufs_clk_info *clki;
@@ -8009,7 +8002,12 @@ static int __ufshcd_setup_clocks(struct 
ufs_hba *hba, bool on,

    list_for_each_entry(clki, head, list) {
  if (!IS_ERR_OR_NULL(clki->clk)) {
-    if (skip_ref_clk && !strcmp(clki->name, "ref_clk"))
+    /*
+ * Don't disable clocks which are needed
+ * to keep the link active.
+ */
+    if (ufshcd_is_link_active(hba) &&
+    clki->keep_link_active)
  continue;
    clk_state_changed = on ^ clki->enabled;
@@ -8054,11 +8052,6 @@ static int __ufshcd_setup_clocks(struct 
ufs_hba *hba, bool on,

  return ret;
  }
  -static int ufshcd_setup_clocks(struct ufs_hba *hba, bool on)
-{
-    return  __ufshcd_setup_clocks(hba, on, false);
-}
-
  static int ufshcd_init_clocks(struct ufs_hba *hba)
  {
  int ret = 0;
@@ -8577,11 +8570,7 @@ static int ufshcd_suspend(struct ufs_hba *hba, 
enum ufs_pm_op pm_op)

   */
  ufshcd_disable_irq(hba);
  -    if (!ufshcd_is_link_active(hba))
-    ufshcd_setup_clocks(hba, false);
-    else
-    /* If link is active, device ref_clk can't be switched off */
-    __ufshcd_setup_clocks(hba, false, true);
+    ufshcd_setup_clocks(hba, false);
    if (ufshcd_is_clkgating_allowed(hba)) {
  hba->clk_gating.state = CLKS_OFF;
diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
index 66e5338..6f0f2d4 100644
--- a/drivers/scsi/ufs/ufshcd.h
+++ b/drivers/scsi/ufs/ufshcd.h
@@ -229,6 +229,8 @@ struct ufs_dev_cmd {
   * @max_freq: maximum frequency supported by the clock
   * @min_freq: min frequency that can be used for clock scaling
   * @curr_freq: indicates the current frequency that it is set to
+ * @keep_link_active: indicates that the clk should not be disabled if
+  link is active
   * @enabled: variable to check against multiple enable/disable
   */
  struct ufs_clk_info {
@@ -238,6 +240,7 @@ struct ufs_clk_info {
  u32 max_freq;
  u32 min_freq;
  u32 curr_freq;
+    bool keep_link_active;


Nitpick - How about 'always-on' instead of 'keep_link_active'?


Hi Asutosh,

B

Re: [PATCH v2] scsi: ufs: Remove pre-defined initial voltage values of device powers

[Asutosh Das (asd)]

On 11/30/2020 10:51 PM, Stanley Chu wrote:

UFS specficication allows different VCC configurations for UFS devices,
for example,
(1). 2.70V - 3.60V (Activated by default in UFS core driver)
(2). 1.70V - 1.95V (Activated if "vcc-supply-1p8" is declared in
   device tree)
(3). 2.40V - 2.70V (Supported since UFS 3.x)

With the introduction of UFS 3.x products, an issue is happening that
UFS driver will use wrong "min_uV-max_uV" values to configure the
voltage of VCC regulator on UFU 3.x products with the configuration (3)
used.

To solve this issue, we simply remove pre-defined initial VCC voltage
values in UFS core driver with below reasons,

1. UFS specifications do not define how to detect the VCC configuration
supported by attached device.

2. Device tree already supports standard regulator properties.

Therefore VCC voltage shall be defined correctly in device tree, and
shall not changed by UFS driver. What UFS driver needs to do is simply
enable or disable the VCC regulator only.

Similar change is applied to VCCQ and VCCQ2 as well.

Note that we keep struct ufs_vreg unchanged. This is allow vendors to
configure proper min_uV and max_uV of any regulators to make
regulator_set_voltage() works during regulator toggling flow.
Without specific vendor configurations, min_uV and max_uV will be NULL
by default and UFS core driver will enable or disable the regulator
only without adjusting its voltage.

Reviewed-by: Bjorn Andersson 
Signed-off-by: Stanley Chu 
---


Reviewed-by: Asutosh Das 


  drivers/scsi/ufs/ufshcd-pltfrm.c | 16 
  1 file changed, 16 deletions(-)

diff --git a/drivers/scsi/ufs/ufshcd-pltfrm.c b/drivers/scsi/ufs/ufshcd-pltfrm.c
index a6f76399b3ae..09e2f04bf4f6 100644
--- a/drivers/scsi/ufs/ufshcd-pltfrm.c
+++ b/drivers/scsi/ufs/ufshcd-pltfrm.c
@@ -133,22 +133,6 @@ static int ufshcd_populate_vreg(struct device *dev, const 
char *name,
vreg->max_uA = 0;
}
  
-	if (!strcmp(name, "vcc")) {

-   if (of_property_read_bool(np, "vcc-supply-1p8")) {
-   vreg->min_uV = UFS_VREG_VCC_1P8_MIN_UV;
-   vreg->max_uV = UFS_VREG_VCC_1P8_MAX_UV;
-   } else {
-   vreg->min_uV = UFS_VREG_VCC_MIN_UV;
-   vreg->max_uV = UFS_VREG_VCC_MAX_UV;
-   }
-   } else if (!strcmp(name, "vccq")) {
-   vreg->min_uV = UFS_VREG_VCCQ_MIN_UV;
-   vreg->max_uV = UFS_VREG_VCCQ_MAX_UV;
-   } else if (!strcmp(name, "vccq2")) {
-   vreg->min_uV = UFS_VREG_VCCQ2_MIN_UV;
-   vreg->max_uV = UFS_VREG_VCCQ2_MAX_UV;
-   }
-
goto out;
  
  out:





--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
Linux Foundation Collaborative Project

Re: [RFC PATCH v1] scsi: ufs: Remove pre-defined initial VCC voltage values

[Asutosh Das (asd)]

On 11/30/2020 6:53 PM, Bjorn Andersson wrote:

On Mon 30 Nov 17:54 CST 2020, Asutosh Das (asd) wrote:


On 11/30/2020 3:14 PM, Bjorn Andersson wrote:

On Mon 30 Nov 16:51 CST 2020, Asutosh Das (asd) wrote:


On 11/30/2020 1:16 AM, Stanley Chu wrote:

UFS specficication allows different VCC configurations for UFS devices,
for example,
(1). 2.70V - 3.60V (By default)
(2). 1.70V - 1.95V (Activated if "vcc-supply-1p8" is declared in
 device tree)
(3). 2.40V - 2.70V (Supported since UFS 3.x)

With the introduction of UFS 3.x products, an issue is happening that
UFS driver will use wrong "min_uV/max_uV" configuration to toggle VCC
regulator on UFU 3.x products with VCC configuration (3) used.

To solve this issue, we simply remove pre-defined initial VCC voltage
values in UFS driver with below reasons,

1. UFS specifications do not define how to detect the VCC configuration
  supported by attached device.

2. Device tree already supports standard regulator properties.

Therefore VCC voltage shall be defined correctly in device tree, and
shall not be changed by UFS driver. What UFS driver needs to do is simply
enabling or disabling the VCC regulator only.

This is a RFC conceptional patch. Please help review this and feel
free to feedback any ideas. Once this concept is accepted, and then
I would post a more completed patch series to fix this issue.

Signed-off-by: Stanley Chu 
---
drivers/scsi/ufs/ufshcd-pltfrm.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)

diff --git a/drivers/scsi/ufs/ufshcd-pltfrm.c b/drivers/scsi/ufs/ufshcd-pltfrm.c
index a6f76399b3ae..3965be03c136 100644
--- a/drivers/scsi/ufs/ufshcd-pltfrm.c
+++ b/drivers/scsi/ufs/ufshcd-pltfrm.c
@@ -133,15 +133,7 @@ static int ufshcd_populate_vreg(struct device *dev, const 
char *name,
vreg->max_uA = 0;
}
-   if (!strcmp(name, "vcc")) {
-   if (of_property_read_bool(np, "vcc-supply-1p8")) {
-   vreg->min_uV = UFS_VREG_VCC_1P8_MIN_UV;
-   vreg->max_uV = UFS_VREG_VCC_1P8_MAX_UV;
-   } else {
-   vreg->min_uV = UFS_VREG_VCC_MIN_UV;
-   vreg->max_uV = UFS_VREG_VCC_MAX_UV;
-   }
-   } else if (!strcmp(name, "vccq")) {
+   if (!strcmp(name, "vccq")) {
vreg->min_uV = UFS_VREG_VCCQ_MIN_UV;
vreg->max_uV = UFS_VREG_VCCQ_MAX_UV;
} else if (!strcmp(name, "vccq2")) {



Hi Stanley

Thanks for the patch. Bao (nguyenb) was also working towards something
similar.
Would it be possible for you to take into account the scenario in which the
same platform supports both 2.x and 3.x UFS devices?

These've different voltage requirements, 2.4v-3.6v.
I'm not sure if standard dts regulator properties can support this.



What is the actual voltage requirement for these devices and how does
the software know what voltage to pick in this range?

Regards,
Bjorn


-asd


--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
Linux Foundation Collaborative Project


For platforms that support both 2.x (2.7v-3.6v) and 3.x (2.4v-2.7v), the
voltage requirements (Vcc) are 2.4v-3.6v. The software initializes the ufs
device at 2.95v & reads the version and if the device is 3.x, it may do the
following:
- Set the device power mode to SLEEP
- Disable the Vcc
- Enable the Vcc and set it to 2.5v
- Set the device power mode to ACTIVE

All of the above may be done at HS-G1 & moved to max supported gear based on
the device version, perhaps?

Am open to other ideas though.



But that means that for a board where we don't know (don't want to know)
if we have a 2.x or 3.x device we need to set:

   regulator-min-microvolt = <2.4V>
   regulator-max-microvolt = <3.6V>

And the 2.5V and the two ranges should be hard coded into the ufshcd (in
particular if they come from the specification).

For devices with only 2.x or 3.x devices, regulator-{min,max}-microvolt
should be adjusted accordingly.

Note that driving the regulators outside these ranges will either damage
the hardware or cause it to misbehave, so these values should be defined
in the board.dts anyways.

Also note that regulator_set_voltage(2.4V, 3.6V) won't give you "a
voltage between 2.4V and 3.6V, it will most likely give either 2.4V or
any more specific voltage that we've specified in the board file because
the regulator happens to be shared with some other consumer and changing
it in runtime would be bad.

Regards,
Bjorn



Understood.
I also understand that assumptions on the regulator limits in the driver 
is a bad idea. I'm not sure how it's designed, but I should think the 
power-grid design should take care of regulator sharing; if it's being 
shared and the platform supports both 2.x and 3.x. Perhaps, such 
platforms be iden

Re: [RFC PATCH v1] scsi: ufs: Remove pre-defined initial VCC voltage values

[Asutosh Das (asd)]

On 11/30/2020 5:25 PM, Stanley Chu wrote:

On Mon, 2020-11-30 at 15:54 -0800, Asutosh Das (asd) wrote:

On 11/30/2020 3:14 PM, Bjorn Andersson wrote:

On Mon 30 Nov 16:51 CST 2020, Asutosh Das (asd) wrote:


On 11/30/2020 1:16 AM, Stanley Chu wrote:

UFS specficication allows different VCC configurations for UFS devices,
for example,
(1). 2.70V - 3.60V (By default)
(2). 1.70V - 1.95V (Activated if "vcc-supply-1p8" is declared in
 device tree)
(3). 2.40V - 2.70V (Supported since UFS 3.x)

With the introduction of UFS 3.x products, an issue is happening that
UFS driver will use wrong "min_uV/max_uV" configuration to toggle VCC
regulator on UFU 3.x products with VCC configuration (3) used.

To solve this issue, we simply remove pre-defined initial VCC voltage
values in UFS driver with below reasons,

1. UFS specifications do not define how to detect the VCC configuration
  supported by attached device.

2. Device tree already supports standard regulator properties.

Therefore VCC voltage shall be defined correctly in device tree, and
shall not be changed by UFS driver. What UFS driver needs to do is simply
enabling or disabling the VCC regulator only.

This is a RFC conceptional patch. Please help review this and feel
free to feedback any ideas. Once this concept is accepted, and then
I would post a more completed patch series to fix this issue.

Signed-off-by: Stanley Chu 
---
drivers/scsi/ufs/ufshcd-pltfrm.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)

diff --git a/drivers/scsi/ufs/ufshcd-pltfrm.c b/drivers/scsi/ufs/ufshcd-pltfrm.c
index a6f76399b3ae..3965be03c136 100644
--- a/drivers/scsi/ufs/ufshcd-pltfrm.c
+++ b/drivers/scsi/ufs/ufshcd-pltfrm.c
@@ -133,15 +133,7 @@ static int ufshcd_populate_vreg(struct device *dev, const 
char *name,
vreg->max_uA = 0;
}
-   if (!strcmp(name, "vcc")) {
-   if (of_property_read_bool(np, "vcc-supply-1p8")) {
-   vreg->min_uV = UFS_VREG_VCC_1P8_MIN_UV;
-   vreg->max_uV = UFS_VREG_VCC_1P8_MAX_UV;
-   } else {
-   vreg->min_uV = UFS_VREG_VCC_MIN_UV;
-   vreg->max_uV = UFS_VREG_VCC_MAX_UV;
-   }
-   } else if (!strcmp(name, "vccq")) {
+   if (!strcmp(name, "vccq")) {
vreg->min_uV = UFS_VREG_VCCQ_MIN_UV;
vreg->max_uV = UFS_VREG_VCCQ_MAX_UV;
} else if (!strcmp(name, "vccq2")) {



Hi Stanley

Thanks for the patch. Bao (nguyenb) was also working towards something
similar.
Would it be possible for you to take into account the scenario in which the
same platform supports both 2.x and 3.x UFS devices?

These've different voltage requirements, 2.4v-3.6v.
I'm not sure if standard dts regulator properties can support this.



What is the actual voltage requirement for these devices and how does
the software know what voltage to pick in this range?

Regards,
Bjorn


-asd


--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
Linux Foundation Collaborative Project


For platforms that support both 2.x (2.7v-3.6v) and 3.x (2.4v-2.7v), the
voltage requirements (Vcc) are 2.4v-3.6v. The software initializes the
ufs device at 2.95v & reads the version and if the device is 3.x, it may
do the following:
- Set the device power mode to SLEEP
- Disable the Vcc
- Enable the Vcc and set it to 2.5v
- Set the device power mode to ACTIVE

All of the above may be done at HS-G1 & moved to max supported gear
based on the device version, perhaps?


Hi Asutosh,

Thanks for sharing this idea.

1. I did not see above flow defined in UFS specifications, please
correct me if I was wrong.

2. For above flow, the concern is that I am not sure if all devices
supporting VCC (2.4v - 2.7v) can accept higher voltage, say 2.95v, for
version detection.

3. For version detection, another concern is that I am not sure if all
3.x devices support VCC (2.4v - 2.7v) only, or in other words, I am not
sure if all 2.x devices support VCC (2.7v - 3.6v) only. The above rule
will break any devices not obeying this "conventions".

For platforms that support both 2.x (2.7v-3.6v) and 3.x (2.4v-2.7v),

It would be good for UFS drivers detecting the correct voltage if the
protocol is well-defined in specifications. Until that day, any
"non-standard" way may be better implemented in vendor's ops?

If the vop concept works on your platform, we could still keep struct
ufs_vreg and allow vendors to configure proper min_uV and max_uV to make
regulator_set_voltage() works during VCC toggling flow. Without specific
vendor configurations, min_uV and max_uV would be NULL by default and
UFS core driver will only enable/disasble VCC regulator only without
adjusting its voltage.



I think this would work. Do you plan to implement t

Re: [PATCH v3 2/3] scsi: ufs: Fix a racing problem between ufshcd_abort and eh_work

[Asutosh Das (asd)]

On 11/16/2020 11:04 PM, Can Guo wrote:

In current task abort routine, if task abort happens to the device W-LU,
the code directly jumps to ufshcd_eh_host_reset_handler() to perform a
full reset and restore then returns FAIL or SUCCESS. Commands sent to the
device W-LU are most likely the SSU cmds sent during UFS PM operations. If
such SSU cmd enters task abort routine, when ufshcd_eh_host_reset_handler()
flushes eh_work, there will be racing because err_handler is serialized
with any PM operations.

Since the main idea of aborting one cmd to the device W-LU is to perform
a full reset and restore, in order to resolve the racing problem, we merely
clean up the lrb taken by this cmd, queue the eh_work and abort the cmd.
Since the cmd has been aborted, the PM operation which sends the cmd simply
errors out, thus err_handler will not be blocked by ongoing PM operations
and err_handler can also recover PM error if any, which comes as another
benefit of this change.

Because such cmd is aborted even before it is actually cleared from HW, set
the lrb->in_use flag to prevent subsequent cmds, including SCSI cmds and
dev cmds, from taking the lrb released by this cmd. Flag lrb->in_use shall
evetually be cleared in __ufshcd_transfer_req_compl() invoked by the full
reset and restore from err_handler.

Signed-off-by: Can Guo 
---


Reviewed-by: Asutosh Das 


  drivers/scsi/ufs/ufshcd.c | 55 ---
  drivers/scsi/ufs/ufshcd.h |  2 ++
  2 files changed, 45 insertions(+), 12 deletions(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 7e764e8..cd7394e 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -2539,6 +2539,14 @@ static int ufshcd_queuecommand(struct Scsi_Host *host, 
struct scsi_cmnd *cmd)
(hba->clk_gating.state != CLKS_ON));
  
  	lrbp = >lrb[tag];

+   if (unlikely(lrbp->in_use)) {
+   if (hba->pm_op_in_progress)
+   set_host_byte(cmd, DID_BAD_TARGET);
+   else
+   err = SCSI_MLQUEUE_HOST_BUSY;
+   ufshcd_release(hba);
+   goto out;
+   }
  
  	WARN_ON(lrbp->cmd);

lrbp->cmd = cmd;
@@ -2781,6 +2789,11 @@ static int ufshcd_exec_dev_cmd(struct ufs_hba *hba,
  
  	init_completion();

lrbp = >lrb[tag];
+   if (unlikely(lrbp->in_use)) {
+   err = -EBUSY;
+   goto out;
+   }
+
WARN_ON(lrbp->cmd);
err = ufshcd_compose_dev_cmd(hba, lrbp, cmd_type, tag);
if (unlikely(err))
@@ -2797,6 +2810,7 @@ static int ufshcd_exec_dev_cmd(struct ufs_hba *hba,
  
  	err = ufshcd_wait_for_dev_cmd(hba, lrbp, timeout);
  
+out:

ufshcd_add_query_upiu_trace(hba, tag,
err ? "query_complete_err" : "query_complete");
  
@@ -4932,6 +4946,7 @@ static void __ufshcd_transfer_req_compl(struct ufs_hba *hba,
  
  	for_each_set_bit(index, _reqs, hba->nutrs) {

lrbp = >lrb[index];
+   lrbp->in_use = false;
lrbp->compl_time_stamp = ktime_get();
cmd = lrbp->cmd;
if (cmd) {
@@ -6374,8 +6389,12 @@ static int ufshcd_issue_devman_upiu_cmd(struct ufs_hba 
*hba,
  
  	init_completion();

lrbp = >lrb[tag];
-   WARN_ON(lrbp->cmd);
+   if (unlikely(lrbp->in_use)) {
+   err = -EBUSY;
+   goto out;
+   }
  
+	WARN_ON(lrbp->cmd);

lrbp->cmd = NULL;
lrbp->sense_bufflen = 0;
lrbp->sense_buffer = NULL;
@@ -6447,6 +6466,7 @@ static int ufshcd_issue_devman_upiu_cmd(struct ufs_hba 
*hba,
}
}
  
+out:

blk_put_request(req);
  out_unlock:
up_read(>clk_scaling_lock);
@@ -6696,16 +6716,6 @@ static int ufshcd_abort(struct scsi_cmnd *cmd)
BUG();
}
  
-	/*

-* Task abort to the device W-LUN is illegal. When this command
-* will fail, due to spec violation, scsi err handling next step
-* will be to send LU reset which, again, is a spec violation.
-* To avoid these unnecessary/illegal step we skip to the last error
-* handling stage: reset and restore.
-*/
-   if (lrbp->lun == UFS_UPIU_UFS_DEVICE_WLUN)
-   return ufshcd_eh_host_reset_handler(cmd);
-
ufshcd_hold(hba, false);
reg = ufshcd_readl(hba, REG_UTP_TRANSFER_REQ_DOOR_BELL);
/* If command is already aborted/completed, return SUCCESS */
@@ -6726,7 +6736,7 @@ static int ufshcd_abort(struct scsi_cmnd *cmd)
 * to reduce repeated printouts. For other aborted requests only print
 * basic details.
 */
-   scsi_print_command(hba->lrb[tag].cmd);
+   scsi_print_command(cmd);
if (!hba->req_abort_count) {
ufshcd_update_reg_hist(>ufs_stats.task_abort, 0);
ufshcd_print_host_regs(hba);
@@ -6745,6 +6755,27 @@ static int ufshcd_abort(struct scsi_cmnd *cmd)
goto 

Re: [PATCH v3 1/3] scsi: ufs: Serialize eh_work with system PM events and async scan

[Asutosh Das (asd)]

On 11/16/2020 11:04 PM, Can Guo wrote:

Serialize eh_work with system PM events and async scan to make sure eh_work
does not run in parallel with them.

Signed-off-by: Can Guo 
---


Reviewed-by: Asutosh Das 


  drivers/scsi/ufs/ufshcd.c | 64 +--
  drivers/scsi/ufs/ufshcd.h |  1 +
  2 files changed, 41 insertions(+), 24 deletions(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 1d8134e..7e764e8 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -5597,7 +5597,9 @@ static inline void ufshcd_schedule_eh_work(struct ufs_hba 
*hba)
  static void ufshcd_err_handling_prepare(struct ufs_hba *hba)
  {
pm_runtime_get_sync(hba->dev);
-   if (pm_runtime_suspended(hba->dev)) {
+   if (pm_runtime_status_suspended(hba->dev) || hba->is_sys_suspended) {
+   enum ufs_pm_op pm_op;
+
/*
 * Don't assume anything of pm_runtime_get_sync(), if
 * resume fails, irq and clocks can be OFF, and powers
@@ -5612,7 +5614,8 @@ static void ufshcd_err_handling_prepare(struct ufs_hba 
*hba)
if (!ufshcd_is_clkgating_allowed(hba))
ufshcd_setup_clocks(hba, true);
ufshcd_release(hba);
-   ufshcd_vops_resume(hba, UFS_RUNTIME_PM);
+   pm_op = hba->is_sys_suspended ? UFS_RUNTIME_PM : UFS_SYSTEM_PM;
+   ufshcd_vops_resume(hba, pm_op);
} else {
ufshcd_hold(hba, false);
if (hba->clk_scaling.is_allowed) {
@@ -5633,7 +5636,7 @@ static void ufshcd_err_handling_unprepare(struct ufs_hba 
*hba)
  
  static inline bool ufshcd_err_handling_should_stop(struct ufs_hba *hba)

  {
-   return (hba->ufshcd_state == UFSHCD_STATE_ERROR ||
+   return (!hba->is_powered || hba->ufshcd_state == UFSHCD_STATE_ERROR ||
(!(hba->saved_err || hba->saved_uic_err || hba->force_reset ||
ufshcd_is_link_broken(hba;
  }
@@ -5646,6 +5649,7 @@ static void ufshcd_recover_pm_error(struct ufs_hba *hba)
struct request_queue *q;
int ret;
  
+	hba->is_sys_suspended = false;

/*
 * Set RPM status of hba device to RPM_ACTIVE,
 * this also clears its runtime error.
@@ -5704,11 +5708,13 @@ static void ufshcd_err_handler(struct work_struct *work)
  
  	hba = container_of(work, struct ufs_hba, eh_work);
  
+	down(>eh_sem);

spin_lock_irqsave(hba->host->host_lock, flags);
if (ufshcd_err_handling_should_stop(hba)) {
if (hba->ufshcd_state != UFSHCD_STATE_ERROR)
hba->ufshcd_state = UFSHCD_STATE_OPERATIONAL;
spin_unlock_irqrestore(hba->host->host_lock, flags);
+   up(>eh_sem);
return;
}
ufshcd_set_eh_in_progress(hba);
@@ -5716,20 +5722,18 @@ static void ufshcd_err_handler(struct work_struct *work)
ufshcd_err_handling_prepare(hba);
spin_lock_irqsave(hba->host->host_lock, flags);
ufshcd_scsi_block_requests(hba);
-   /*
-* A full reset and restore might have happened after preparation
-* is finished, double check whether we should stop.
-*/
-   if (ufshcd_err_handling_should_stop(hba)) {
-   if (hba->ufshcd_state != UFSHCD_STATE_ERROR)
-   hba->ufshcd_state = UFSHCD_STATE_OPERATIONAL;
-   goto out;
-   }
hba->ufshcd_state = UFSHCD_STATE_RESET;
  
  	/* Complete requests that have door-bell cleared by h/w */

ufshcd_complete_requests(hba);
  
+	/*

+* A full reset and restore might have happened after preparation
+* is finished, double check whether we should stop.
+*/
+   if (ufshcd_err_handling_should_stop(hba))
+   goto skip_err_handling;
+
if (hba->dev_quirks & UFS_DEVICE_QUIRK_RECOVERY_FROM_DL_NAC_ERRORS) {
bool ret;
  
@@ -5737,17 +5741,10 @@ static void ufshcd_err_handler(struct work_struct *work)

/* release the lock as ufshcd_quirk_dl_nac_errors() may sleep */
ret = ufshcd_quirk_dl_nac_errors(hba);
spin_lock_irqsave(hba->host->host_lock, flags);
-   if (!ret && !hba->force_reset && ufshcd_is_link_active(hba))
+   if (!ret && ufshcd_err_handling_should_stop(hba))
goto skip_err_handling;
}
  
-	if (hba->force_reset || ufshcd_is_link_broken(hba) ||

-   ufshcd_is_saved_err_fatal(hba) ||
-   ((hba->saved_err & UIC_ERROR) &&
-(hba->saved_uic_err & (UFSHCD_UIC_DL_NAC_RECEIVED_ERROR |
-   UFSHCD_UIC_DL_TCx_REPLAY_ERROR
-   needs_reset = true;
-
if ((hba->saved_err & (INT_FATAL_ERRORS | UFSHCD_UIC_HIBERN8_MASK)) ||
(hba->saved_uic_err &&
 (hba->saved_uic_err != UFSHCD_UIC_PA_GENERIC_ERROR))) {
@@ -5767,8 

Re: [PATCH v3 2/2] scsi: ufs-qcom: Keep core_clk_unipro ON while link is active

[Asutosh Das (asd)]

On 11/25/2020 6:01 PM, Can Guo wrote:

If we want to disable clocks to save power but still keep the link active,
core_clk_unipro, as same as ref_clk, should not be the one being disabled.

Reviewed-by: Hongwu Su
Signed-off-by: Can Guo 
---


Reviewed-by: Asutosh Das 


  drivers/scsi/ufs/ufs-qcom.c | 6 ++
  1 file changed, 6 insertions(+)

diff --git a/drivers/scsi/ufs/ufs-qcom.c b/drivers/scsi/ufs/ufs-qcom.c
index f9d6ef3..8a7fc62 100644
--- a/drivers/scsi/ufs/ufs-qcom.c
+++ b/drivers/scsi/ufs/ufs-qcom.c
@@ -977,6 +977,7 @@ static int ufs_qcom_init(struct ufs_hba *hba)
struct platform_device *pdev = to_platform_device(dev);
struct ufs_qcom_host *host;
struct resource *res;
+   struct ufs_clk_info *clki;
  
  	if (strlen(android_boot_dev) && strcmp(android_boot_dev, dev_name(dev)))

return -ENODEV;
@@ -1075,6 +1076,11 @@ static int ufs_qcom_init(struct ufs_hba *hba)
}
}
  
+	list_for_each_entry(clki, >clk_list_head, list) {

+   if (!strcmp(clki->name, "core_clk_unipro"))
+   clki->keep_link_active = true;
+   }
+
err = ufs_qcom_init_lane_clks(host);
if (err)
goto out_variant_clear;




--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
Linux Foundation Collaborative Project

Re: [RFC PATCH v1] scsi: ufs: Remove pre-defined initial VCC voltage values

[Asutosh Das (asd)]

On 11/30/2020 3:14 PM, Bjorn Andersson wrote:

On Mon 30 Nov 16:51 CST 2020, Asutosh Das (asd) wrote:


On 11/30/2020 1:16 AM, Stanley Chu wrote:

UFS specficication allows different VCC configurations for UFS devices,
for example,
(1). 2.70V - 3.60V (By default)
(2). 1.70V - 1.95V (Activated if "vcc-supply-1p8" is declared in
device tree)
(3). 2.40V - 2.70V (Supported since UFS 3.x)

With the introduction of UFS 3.x products, an issue is happening that
UFS driver will use wrong "min_uV/max_uV" configuration to toggle VCC
regulator on UFU 3.x products with VCC configuration (3) used.

To solve this issue, we simply remove pre-defined initial VCC voltage
values in UFS driver with below reasons,

1. UFS specifications do not define how to detect the VCC configuration
 supported by attached device.

2. Device tree already supports standard regulator properties.

Therefore VCC voltage shall be defined correctly in device tree, and
shall not be changed by UFS driver. What UFS driver needs to do is simply
enabling or disabling the VCC regulator only.

This is a RFC conceptional patch. Please help review this and feel
free to feedback any ideas. Once this concept is accepted, and then
I would post a more completed patch series to fix this issue.

Signed-off-by: Stanley Chu 
---
   drivers/scsi/ufs/ufshcd-pltfrm.c | 10 +-
   1 file changed, 1 insertion(+), 9 deletions(-)

diff --git a/drivers/scsi/ufs/ufshcd-pltfrm.c b/drivers/scsi/ufs/ufshcd-pltfrm.c
index a6f76399b3ae..3965be03c136 100644
--- a/drivers/scsi/ufs/ufshcd-pltfrm.c
+++ b/drivers/scsi/ufs/ufshcd-pltfrm.c
@@ -133,15 +133,7 @@ static int ufshcd_populate_vreg(struct device *dev, const 
char *name,
vreg->max_uA = 0;
}
-   if (!strcmp(name, "vcc")) {
-   if (of_property_read_bool(np, "vcc-supply-1p8")) {
-   vreg->min_uV = UFS_VREG_VCC_1P8_MIN_UV;
-   vreg->max_uV = UFS_VREG_VCC_1P8_MAX_UV;
-   } else {
-   vreg->min_uV = UFS_VREG_VCC_MIN_UV;
-   vreg->max_uV = UFS_VREG_VCC_MAX_UV;
-   }
-   } else if (!strcmp(name, "vccq")) {
+   if (!strcmp(name, "vccq")) {
vreg->min_uV = UFS_VREG_VCCQ_MIN_UV;
vreg->max_uV = UFS_VREG_VCCQ_MAX_UV;
} else if (!strcmp(name, "vccq2")) {



Hi Stanley

Thanks for the patch. Bao (nguyenb) was also working towards something
similar.
Would it be possible for you to take into account the scenario in which the
same platform supports both 2.x and 3.x UFS devices?

These've different voltage requirements, 2.4v-3.6v.
I'm not sure if standard dts regulator properties can support this.



What is the actual voltage requirement for these devices and how does
the software know what voltage to pick in this range?

Regards,
Bjorn


-asd


--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
Linux Foundation Collaborative Project


For platforms that support both 2.x (2.7v-3.6v) and 3.x (2.4v-2.7v), the 
voltage requirements (Vcc) are 2.4v-3.6v. The software initializes the 
ufs device at 2.95v & reads the version and if the device is 3.x, it may 
do the following:

- Set the device power mode to SLEEP
- Disable the Vcc
- Enable the Vcc and set it to 2.5v
- Set the device power mode to ACTIVE

All of the above may be done at HS-G1 & moved to max supported gear 
based on the device version, perhaps?


Am open to other ideas though.

-asd

--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
Linux Foundation Collaborative Project

Re: [PATCH 1/3] scsi: ufs: Add "wb_on" sysfs node to control WB on/off

[Asutosh Das (asd)]

On 11/30/2020 10:11 AM, Bean Huo wrote:

From: Bean Huo 

Currently we let UFS WriteBooster driver use clock scaling
up/down to set WB on/off, for the platform which doesn't
support UFSHCD_CAP_CLK_SCALING, WB will be always on. Provide
a sysfs attribute to enable/disable WB during runtime.

Signed-off-by: Bean Huo 
---
  drivers/scsi/ufs/ufs-sysfs.c | 33 +
  drivers/scsi/ufs/ufshcd.c|  3 +--
  drivers/scsi/ufs/ufshcd.h|  2 ++
  3 files changed, 36 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/ufs/ufs-sysfs.c b/drivers/scsi/ufs/ufs-sysfs.c
index 08e72b7eef6a..e41d8eb779ec 100644
--- a/drivers/scsi/ufs/ufs-sysfs.c
+++ b/drivers/scsi/ufs/ufs-sysfs.c
@@ -189,6 +189,37 @@ static ssize_t auto_hibern8_store(struct device *dev,
return count;
  }
  
+static ssize_t wb_on_show(struct device *dev, struct device_attribute *attr,

+ char *buf)
+{
+   struct ufs_hba *hba = dev_get_drvdata(dev);
+
+   return scnprintf(buf, PAGE_SIZE, "%d\n", hba->wb_enabled);
+}
+
+static ssize_t wb_on_store(struct device *dev, struct device_attribute *attr,
+  const char *buf, size_t count)
+{
+   struct ufs_hba *hba = dev_get_drvdata(dev);
+   unsigned int wb_enable;
+   ssize_t res;
+
+   if (!ufshcd_is_wb_allowed(hba))
+   return -EOPNOTSUPP;
+
+   if (kstrtouint(buf, 0, _enable))
+   return -EINVAL;
+
+   if (wb_enable != 0 && wb_enable != 1)
+   return -EINVAL;
+
+   pm_runtime_get_sync(hba->dev);
+   res = ufshcd_wb_ctrl(hba, wb_enable);


Say, a platform supports clock-scaling and this bit is toggled.
The control goes into ufshcd_wb_ctrl for both this sysfs and 
clock-scaling contexts. The clock-scaling context passes all checks and 
blocks on waiting for this wb control to be disabled and then tries to 
enable wb when it's already disabled. Perhaps that's a race there?



+   pm_runtime_put_sync(hba->dev);
+
+   return res < 0 ? res : count;
+}
+
  static DEVICE_ATTR_RW(rpm_lvl);
  static DEVICE_ATTR_RO(rpm_target_dev_state);
  static DEVICE_ATTR_RO(rpm_target_link_state);
@@ -196,6 +227,7 @@ static DEVICE_ATTR_RW(spm_lvl);
  static DEVICE_ATTR_RO(spm_target_dev_state);
  static DEVICE_ATTR_RO(spm_target_link_state);
  static DEVICE_ATTR_RW(auto_hibern8);
+static DEVICE_ATTR_RW(wb_on);
  
  static struct attribute *ufs_sysfs_ufshcd_attrs[] = {

_attr_rpm_lvl.attr,
@@ -205,6 +237,7 @@ static struct attribute *ufs_sysfs_ufshcd_attrs[] = {
_attr_spm_target_dev_state.attr,
_attr_spm_target_link_state.attr,
_attr_auto_hibern8.attr,
+   _attr_wb_on.attr,
NULL
  };
  
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c

index d169db41ee16..639ba9d1ccbb 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -247,7 +247,6 @@ static inline int ufshcd_config_vreg_hpm(struct ufs_hba 
*hba,
  static int ufshcd_try_to_abort_task(struct ufs_hba *hba, int tag);
  static int ufshcd_wb_buf_flush_enable(struct ufs_hba *hba);
  static int ufshcd_wb_buf_flush_disable(struct ufs_hba *hba);
-static int ufshcd_wb_ctrl(struct ufs_hba *hba, bool enable);
  static int ufshcd_wb_toggle_flush_during_h8(struct ufs_hba *hba, bool set);
  static inline void ufshcd_wb_toggle_flush(struct ufs_hba *hba, bool enable);
  static void ufshcd_hba_vreg_set_lpm(struct ufs_hba *hba);
@@ -5299,7 +5298,7 @@ static void ufshcd_bkops_exception_event_handler(struct 
ufs_hba *hba)
__func__, err);
  }
  
-static int ufshcd_wb_ctrl(struct ufs_hba *hba, bool enable)

+int ufshcd_wb_ctrl(struct ufs_hba *hba, bool enable)
  {
int ret;
u8 index;
diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
index d0b68df07eef..c7bb61a4e484 100644
--- a/drivers/scsi/ufs/ufshcd.h
+++ b/drivers/scsi/ufs/ufshcd.h
@@ -1067,6 +1067,8 @@ int ufshcd_exec_raw_upiu_cmd(struct ufs_hba *hba,
 u8 *desc_buff, int *buff_len,
 enum query_opcode desc_op);
  
+int ufshcd_wb_ctrl(struct ufs_hba *hba, bool enable);

+
  /* Wrapper functions for safely calling variant operations */
  static inline const char *ufshcd_get_var_name(struct ufs_hba *hba)
  {




--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
Linux Foundation Collaborative Project

Re: [PATCH v3 1/2] scsi: ufs: Refactor ufshcd_setup_clocks() to remove skip_ref_clk

[Asutosh Das (asd)]

On 11/25/2020 6:01 PM, Can Guo wrote:

Remove the param skip_ref_clk from __ufshcd_setup_clocks(), but keep a flag
in struct ufs_clk_info to tell whether a clock can be disabled or not while
the link is active.

Reviewed-by: Hongwu Su
Reviewed-by: Bean Huo 
Reviewed-by: Stanley Chu 
Signed-off-by: Can Guo 
---
  drivers/scsi/ufs/ufshcd-pltfrm.c |  2 ++
  drivers/scsi/ufs/ufshcd.c| 29 +
  drivers/scsi/ufs/ufshcd.h|  3 +++
  3 files changed, 14 insertions(+), 20 deletions(-)

diff --git a/drivers/scsi/ufs/ufshcd-pltfrm.c b/drivers/scsi/ufs/ufshcd-pltfrm.c
index 3db0af6..873ef14 100644
--- a/drivers/scsi/ufs/ufshcd-pltfrm.c
+++ b/drivers/scsi/ufs/ufshcd-pltfrm.c
@@ -92,6 +92,8 @@ static int ufshcd_parse_clock_info(struct ufs_hba *hba)
clki->min_freq = clkfreq[i];
clki->max_freq = clkfreq[i+1];
clki->name = kstrdup(name, GFP_KERNEL);
+   if (!strcmp(name, "ref_clk"))
+   clki->keep_link_active = true;
dev_dbg(dev, "%s: min %u max %u name %s\n", "freq-table-hz",
clki->min_freq, clki->max_freq, clki->name);
list_add_tail(>list, >clk_list_head);
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index a7857f6..44254c9 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -221,8 +221,6 @@ static int ufshcd_eh_host_reset_handler(struct scsi_cmnd 
*cmd);
  static int ufshcd_clear_tm_cmd(struct ufs_hba *hba, int tag);
  static void ufshcd_hba_exit(struct ufs_hba *hba);
  static int ufshcd_probe_hba(struct ufs_hba *hba, bool async);
-static int __ufshcd_setup_clocks(struct ufs_hba *hba, bool on,
-bool skip_ref_clk);
  static int ufshcd_setup_clocks(struct ufs_hba *hba, bool on);
  static int ufshcd_uic_hibern8_enter(struct ufs_hba *hba);
  static inline void ufshcd_add_delay_before_dme_cmd(struct ufs_hba *hba);
@@ -1707,11 +1705,7 @@ static void ufshcd_gate_work(struct work_struct *work)
  
  	ufshcd_disable_irq(hba);
  
-	if (!ufshcd_is_link_active(hba))

-   ufshcd_setup_clocks(hba, false);
-   else
-   /* If link is active, device ref_clk can't be switched off */
-   __ufshcd_setup_clocks(hba, false, true);
+   ufshcd_setup_clocks(hba, false);
  
  	/*

 * In case you are here to cancel this work the gating state
@@ -7990,8 +7984,7 @@ static int ufshcd_init_hba_vreg(struct ufs_hba *hba)
return 0;
  }
  
-static int __ufshcd_setup_clocks(struct ufs_hba *hba, bool on,

-   bool skip_ref_clk)
+static int ufshcd_setup_clocks(struct ufs_hba *hba, bool on)
  {
int ret = 0;
struct ufs_clk_info *clki;
@@ -8009,7 +8002,12 @@ static int __ufshcd_setup_clocks(struct ufs_hba *hba, 
bool on,
  
  	list_for_each_entry(clki, head, list) {

if (!IS_ERR_OR_NULL(clki->clk)) {
-   if (skip_ref_clk && !strcmp(clki->name, "ref_clk"))
+   /*
+* Don't disable clocks which are needed
+* to keep the link active.
+*/
+   if (ufshcd_is_link_active(hba) &&
+   clki->keep_link_active)
continue;
  
  			clk_state_changed = on ^ clki->enabled;

@@ -8054,11 +8052,6 @@ static int __ufshcd_setup_clocks(struct ufs_hba *hba, 
bool on,
return ret;
  }
  
-static int ufshcd_setup_clocks(struct ufs_hba *hba, bool on)

-{
-   return  __ufshcd_setup_clocks(hba, on, false);
-}
-
  static int ufshcd_init_clocks(struct ufs_hba *hba)
  {
int ret = 0;
@@ -8577,11 +8570,7 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum 
ufs_pm_op pm_op)
 */
ufshcd_disable_irq(hba);
  
-	if (!ufshcd_is_link_active(hba))

-   ufshcd_setup_clocks(hba, false);
-   else
-   /* If link is active, device ref_clk can't be switched off */
-   __ufshcd_setup_clocks(hba, false, true);
+   ufshcd_setup_clocks(hba, false);
  
  	if (ufshcd_is_clkgating_allowed(hba)) {

hba->clk_gating.state = CLKS_OFF;
diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
index 66e5338..6f0f2d4 100644
--- a/drivers/scsi/ufs/ufshcd.h
+++ b/drivers/scsi/ufs/ufshcd.h
@@ -229,6 +229,8 @@ struct ufs_dev_cmd {
   * @max_freq: maximum frequency supported by the clock
   * @min_freq: min frequency that can be used for clock scaling
   * @curr_freq: indicates the current frequency that it is set to
+ * @keep_link_active: indicates that the clk should not be disabled if
+ link is active
   * @enabled: variable to check against multiple enable/disable
   */
  struct ufs_clk_info {
@@ -238,6 +240,7 @@ struct ufs_clk_info {
u32 max_freq;
u32 min_freq;
u32 curr_freq;
+   bool keep_link_active;

Re: [PATCH 1/1] scsi: ufs: Remove scale down gear hard code

[Asutosh Das (asd)]

On 11/26/2020 5:58 PM, Can Guo wrote:

Instead of making the scale down gear a hard code, make it a member of
ufs_clk_scaling struct.

Signed-off-by: Can Guo 
---


Reviewed-by: Asutosh Das 


  drivers/scsi/ufs/ufshcd.c | 12 +++-
  drivers/scsi/ufs/ufshcd.h |  2 ++
  2 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 44254c9..1789df3 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -1100,7 +1100,6 @@ static int ufshcd_wait_for_doorbell_clr(struct ufs_hba 
*hba,
   */
  static int ufshcd_scale_gear(struct ufs_hba *hba, bool scale_up)
  {
-   #define UFS_MIN_GEAR_TO_SCALE_DOWN  UFS_HS_G1
int ret = 0;
struct ufs_pa_layer_attr new_pwr_info;
  
@@ -,16 +1110,16 @@ static int ufshcd_scale_gear(struct ufs_hba *hba, bool scale_up)

memcpy(_pwr_info, >pwr_info,
   sizeof(struct ufs_pa_layer_attr));
  
-		if (hba->pwr_info.gear_tx > UFS_MIN_GEAR_TO_SCALE_DOWN

-   || hba->pwr_info.gear_rx > UFS_MIN_GEAR_TO_SCALE_DOWN) {
+   if (hba->pwr_info.gear_tx > hba->clk_scaling.min_gear ||
+   hba->pwr_info.gear_rx > hba->clk_scaling.min_gear) {
/* save the current power mode */
memcpy(>clk_scaling.saved_pwr_info.info,
>pwr_info,
sizeof(struct ufs_pa_layer_attr));
  
  			/* scale down gear */

-   new_pwr_info.gear_tx = UFS_MIN_GEAR_TO_SCALE_DOWN;
-   new_pwr_info.gear_rx = UFS_MIN_GEAR_TO_SCALE_DOWN;
+   new_pwr_info.gear_tx = hba->clk_scaling.min_gear;
+   new_pwr_info.gear_rx = hba->clk_scaling.min_gear;
}
}
  
@@ -1824,6 +1823,9 @@ static void ufshcd_init_clk_scaling(struct ufs_hba *hba)

if (!ufshcd_is_clkscaling_supported(hba))
return;
  
+	if (!hba->clk_scaling.min_gear)

+   hba->clk_scaling.min_gear = UFS_HS_G1;
+
INIT_WORK(>clk_scaling.suspend_work,
  ufshcd_clk_scaling_suspend_work);
INIT_WORK(>clk_scaling.resume_work,
diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
index 6f0f2d4..bdab23e 100644
--- a/drivers/scsi/ufs/ufshcd.h
+++ b/drivers/scsi/ufs/ufshcd.h
@@ -385,6 +385,7 @@ struct ufs_saved_pwr_info {
   * @workq: workqueue to schedule devfreq suspend/resume work
   * @suspend_work: worker to suspend devfreq
   * @resume_work: worker to resume devfreq
+ * @min_gear: lowest HS gear to scale down to
   * @is_allowed: tracks if scaling is currently allowed or not
   * @is_busy_started: tracks if busy period has started or not
   * @is_suspended: tracks if devfreq is suspended or not
@@ -399,6 +400,7 @@ struct ufs_clk_scaling {
struct workqueue_struct *workq;
struct work_struct suspend_work;
struct work_struct resume_work;
+   u32 min_gear;
bool is_allowed;
bool is_busy_started;
bool is_suspended;




--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
Linux Foundation Collaborative Project

Re: [RFC PATCH v1] scsi: ufs: Remove pre-defined initial VCC voltage values

[Asutosh Das (asd)]

On 11/30/2020 1:16 AM, Stanley Chu wrote:

UFS specficication allows different VCC configurations for UFS devices,
for example,
(1). 2.70V - 3.60V (By default)
(2). 1.70V - 1.95V (Activated if "vcc-supply-1p8" is declared in
   device tree)
(3). 2.40V - 2.70V (Supported since UFS 3.x)

With the introduction of UFS 3.x products, an issue is happening that
UFS driver will use wrong "min_uV/max_uV" configuration to toggle VCC
regulator on UFU 3.x products with VCC configuration (3) used.

To solve this issue, we simply remove pre-defined initial VCC voltage
values in UFS driver with below reasons,

1. UFS specifications do not define how to detect the VCC configuration
supported by attached device.

2. Device tree already supports standard regulator properties.

Therefore VCC voltage shall be defined correctly in device tree, and
shall not be changed by UFS driver. What UFS driver needs to do is simply
enabling or disabling the VCC regulator only.

This is a RFC conceptional patch. Please help review this and feel
free to feedback any ideas. Once this concept is accepted, and then
I would post a more completed patch series to fix this issue.

Signed-off-by: Stanley Chu 
---
  drivers/scsi/ufs/ufshcd-pltfrm.c | 10 +-
  1 file changed, 1 insertion(+), 9 deletions(-)

diff --git a/drivers/scsi/ufs/ufshcd-pltfrm.c b/drivers/scsi/ufs/ufshcd-pltfrm.c
index a6f76399b3ae..3965be03c136 100644
--- a/drivers/scsi/ufs/ufshcd-pltfrm.c
+++ b/drivers/scsi/ufs/ufshcd-pltfrm.c
@@ -133,15 +133,7 @@ static int ufshcd_populate_vreg(struct device *dev, const 
char *name,
vreg->max_uA = 0;
}
  
-	if (!strcmp(name, "vcc")) {

-   if (of_property_read_bool(np, "vcc-supply-1p8")) {
-   vreg->min_uV = UFS_VREG_VCC_1P8_MIN_UV;
-   vreg->max_uV = UFS_VREG_VCC_1P8_MAX_UV;
-   } else {
-   vreg->min_uV = UFS_VREG_VCC_MIN_UV;
-   vreg->max_uV = UFS_VREG_VCC_MAX_UV;
-   }
-   } else if (!strcmp(name, "vccq")) {
+   if (!strcmp(name, "vccq")) {
vreg->min_uV = UFS_VREG_VCCQ_MIN_UV;
vreg->max_uV = UFS_VREG_VCCQ_MAX_UV;
} else if (!strcmp(name, "vccq2")) {



Hi Stanley

Thanks for the patch. Bao (nguyenb) was also working towards something 
similar.
Would it be possible for you to take into account the scenario in which 
the same platform supports both 2.x and 3.x UFS devices?


These've different voltage requirements, 2.4v-3.6v.
I'm not sure if standard dts regulator properties can support this.

-asd


--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
Linux Foundation Collaborative Project

Re: [PATCH v3 3/3] scsi: ufs: Print host regs in IRQ handler when AH8 error happens

[Asutosh Das (asd)]

On 11/16/2020 11:04 PM, Can Guo wrote:

When AH8 error happens, all the regs and states are dumped in err handler.
Sometime we need to look into host regs right after AH8 error happens,
which is before leaving the IRQ handler.

Signed-off-by: Can Guo 
---


Reviewed-by: Asutosh Das 


  drivers/scsi/ufs/ufshcd.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index cd7394e..a7857f6 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -6057,7 +6057,8 @@ static irqreturn_t ufshcd_check_errors(struct ufs_hba 
*hba)
hba->saved_uic_err |= hba->uic_error;
  
  		/* dump controller state before resetting */

-   if ((hba->saved_err & (INT_FATAL_ERRORS)) ||
+   if ((hba->saved_err &
+(INT_FATAL_ERRORS | UFSHCD_UIC_HIBERN8_MASK)) ||
(hba->saved_uic_err &&
 (hba->saved_uic_err != UFSHCD_UIC_PA_GENERIC_ERROR))) {
dev_err(hba->dev, "%s: saved_err 0x%x saved_uic_err 
0x%x\n",




--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
Linux Foundation Collaborative Project

Re: [PATCH v1 1/2] scsi: ufs: Fix unbalanced scsi_block_reqs_cnt caused by ufshcd_hold()

[Asutosh Das (asd)]

On 11/2/2020 10:24 PM, Can Guo wrote:

The scsi_block_reqs_cnt increased in ufshcd_hold() is supposed to be
decreased back in ufshcd_ungate_work() in a paired way. However, if
specific ufshcd_hold/release sequences are met, it is possible that
scsi_block_reqs_cnt is increased twice but only one ungate work is
queued. To make sure scsi_block_reqs_cnt is handled by ufshcd_hold() and
ufshcd_ungate_work() in a paired way, increase it only if queue_work()
returns true.

Signed-off-by: Can Guo 
Reviewed-by: Hongwu Su 
---


Reviewed-by: Asutosh Das 


  drivers/scsi/ufs/ufshcd.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 847f355..efa7d86 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -1634,12 +1634,12 @@ int ufshcd_hold(struct ufs_hba *hba, bool async)
 */
/* fallthrough */
case CLKS_OFF:
-   ufshcd_scsi_block_requests(hba);
hba->clk_gating.state = REQ_CLKS_ON;
trace_ufshcd_clk_gating(dev_name(hba->dev),
hba->clk_gating.state);
-   queue_work(hba->clk_gating.clk_gating_workq,
-  >clk_gating.ungate_work);
+   if (queue_work(hba->clk_gating.clk_gating_workq,
+  >clk_gating.ungate_work))
+   ufshcd_scsi_block_requests(hba);
/*
 * fall through to check if we should wait for this
 * work to be done or not.




--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
Linux Foundation Collaborative Project

Re: [PATCH v2 1/1] scsi: ufs: Fix unexpected values get from ufshcd_read_desc_param()

[Asutosh Das (asd)]

On 10/21/2020 10:59 PM, Can Guo wrote:

Since WB feature has been added, WB related sysfs entries can be accessed
even when an UFS device does not support WB feature. In that case, the
descriptors which are not supported by the UFS device may be wrongly
reported when they are accessed from their corrsponding sysfs entries.
Fix it by adding a sanity check of parameter offset against the actual
decriptor length.

Signed-off-by: Can Guo 
---


Reviewed-by: Asutosh Das 


  drivers/scsi/ufs/ufshcd.c | 24 +++-
  1 file changed, 15 insertions(+), 9 deletions(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index a2ebcc8..aeec10d 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -3184,13 +3184,19 @@ int ufshcd_read_desc_param(struct ufs_hba *hba,
/* Get the length of descriptor */
ufshcd_map_desc_id_to_length(hba, desc_id, _len);
if (!buff_len) {
-   dev_err(hba->dev, "%s: Failed to get desc length", __func__);
+   dev_err(hba->dev, "%s: Failed to get desc length\n", __func__);
+   return -EINVAL;
+   }
+
+   if (param_offset >= buff_len) {
+   dev_err(hba->dev, "%s: Invalid offset 0x%x in descriptor IDN 0x%x, 
length 0x%x\n",
+   __func__, param_offset, desc_id, buff_len);
return -EINVAL;
}
  
  	/* Check whether we need temp memory */

if (param_offset != 0 || param_size < buff_len) {
-   desc_buf = kmalloc(buff_len, GFP_KERNEL);
+   desc_buf = kzalloc(buff_len, GFP_KERNEL);
if (!desc_buf)
return -ENOMEM;
} else {
@@ -3204,14 +3210,14 @@ int ufshcd_read_desc_param(struct ufs_hba *hba,
desc_buf, _len);
  
  	if (ret) {

-   dev_err(hba->dev, "%s: Failed reading descriptor. desc_id %d, 
desc_index %d, param_offset %d, ret %d",
+   dev_err(hba->dev, "%s: Failed reading descriptor. desc_id %d, 
desc_index %d, param_offset %d, ret %d\n",
__func__, desc_id, desc_index, param_offset, ret);
goto out;
}
  
  	/* Sanity check */

if (desc_buf[QUERY_DESC_DESC_TYPE_OFFSET] != desc_id) {
-   dev_err(hba->dev, "%s: invalid desc_id %d in descriptor header",
+   dev_err(hba->dev, "%s: invalid desc_id %d in descriptor 
header\n",
__func__, desc_buf[QUERY_DESC_DESC_TYPE_OFFSET]);
ret = -EINVAL;
goto out;
@@ -3221,12 +3227,12 @@ int ufshcd_read_desc_param(struct ufs_hba *hba,
buff_len = desc_buf[QUERY_DESC_LENGTH_OFFSET];
ufshcd_update_desc_length(hba, desc_id, desc_index, buff_len);
  
-	/* Check wherher we will not copy more data, than available */

-   if (is_kmalloc && (param_offset + param_size) > buff_len)
-   param_size = buff_len - param_offset;
-
-   if (is_kmalloc)
+   if (is_kmalloc) {
+   /* Make sure we don't copy more data than available */
+   if (param_offset + param_size > buff_len)
+   param_size = buff_len - param_offset;
memcpy(param_read_buf, _buf[param_offset], param_size);
+   }
  out:
if (is_kmalloc)
kfree(desc_buf);




--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
Linux Foundation Collaborative Project

Re: [PATCH v2] scsi: ufshcd: fix missing destroy_workqueue()

[Asutosh Das (asd)]

On 11/9/2020 11:42 PM, Qinglang Miao wrote:

Add the missing destroy_workqueue() before return from
ufshcd_init in the error handling case as well as in
ufshcd_remove.

Fixes: 4db7a2360597 ("scsi: ufs: Fix concurrency of error handler and other error 
recovery paths")
Suggested-by: Avri Altman 
Signed-off-by: Qinglang Miao 
---


Reviewed-by: Asutosh Das 


  v2: consider missing destroy_workqueue ufshcd_remove either.

  drivers/scsi/ufs/ufshcd.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index b8f573a02713..adbdda4f556b 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -8906,6 +8906,7 @@ void ufshcd_remove(struct ufs_hba *hba)
blk_mq_free_tag_set(>tmf_tag_set);
blk_cleanup_queue(hba->cmd_queue);
scsi_remove_host(hba->host);
+   destroy_workqueue(hba->eh_wq);
/* disable interrupts */
ufshcd_disable_intr(hba, hba->intr_mask);
ufshcd_hba_stop(hba);
@@ -9206,6 +9207,7 @@ int ufshcd_init(struct ufs_hba *hba, void __iomem 
*mmio_base, unsigned int irq)
  exit_gating:
ufshcd_exit_clk_scaling(hba);
ufshcd_exit_clk_gating(hba);
+   destroy_workqueue(hba->eh_wq);
  out_disable:
hba->is_irq_enabled = false;
ufshcd_hba_exit(hba);




--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
Linux Foundation Collaborative Project

Re: [PATCH V4 1/2] scsi: ufs: Add DeepSleep feature

[Asutosh Das (asd)]

On 11/3/2020 6:14 AM, Adrian Hunter wrote:

DeepSleep is a UFS v3.1 feature that achieves the lowest power consumption
of the device, apart from power off.

In DeepSleep mode, no commands are accepted, and the only way to exit is
using a hardware reset or power cycle.

This patch assumes that if a power cycle was an option, then power off
would be preferable, so only exit via a hardware reset is supported.

Drivers that wish to support DeepSleep need to set a new capability flag
UFSHCD_CAP_DEEPSLEEP and provide a hardware reset via the existing
  ->device_reset() callback.

It is assumed that UFS devices with wspecversion >= 0x310 support
DeepSleep.

Signed-off-by: Adrian Hunter 
---


Reviewed-by: Asutosh Das 



  Documentation/ABI/testing/sysfs-driver-ufs | 34 +++
  drivers/scsi/ufs/ufs-sysfs.c   |  7 
  drivers/scsi/ufs/ufs.h |  1 +
  drivers/scsi/ufs/ufshcd.c  | 39 --
  drivers/scsi/ufs/ufshcd.h  | 17 +-
  include/trace/events/ufs.h |  3 +-
  6 files changed, 83 insertions(+), 18 deletions(-)

diff --git a/Documentation/ABI/testing/sysfs-driver-ufs 
b/Documentation/ABI/testing/sysfs-driver-ufs
index adc0d0e91607..e77fa784d6d8 100644
--- a/Documentation/ABI/testing/sysfs-driver-ufs
+++ b/Documentation/ABI/testing/sysfs-driver-ufs
@@ -916,21 +916,24 @@ Date: September 2014
  Contact:  Subhash Jadavani 
  Description:  This entry could be used to set or show the UFS device
runtime power management level. The current driver
-   implementation supports 6 levels with next target states:
+   implementation supports 7 levels with next target states:
  
  		==  

-   0   an UFS device will stay active, an UIC link will
+   0   UFS device will stay active, UIC link will
stay active
-   1   an UFS device will stay active, an UIC link will
+   1   UFS device will stay active, UIC link will
hibernate
-   2   an UFS device will moved to sleep, an UIC link will
+   2   UFS device will be moved to sleep, UIC link will
stay active
-   3   an UFS device will moved to sleep, an UIC link will
+   3   UFS device will be moved to sleep, UIC link will
hibernate
-   4   an UFS device will be powered off, an UIC link will
+   4   UFS device will be powered off, UIC link will
hibernate
-   5   an UFS device will be powered off, an UIC link will
+   5   UFS device will be powered off, UIC link will
be powered off
+   6   UFS device will be moved to deep sleep, UIC link
+   will be powered off. Note, deep sleep might not be
+   supported in which case this value will not be accepted
==  
  
  What:		/sys/bus/platform/drivers/ufshcd/*/rpm_target_dev_state

@@ -954,21 +957,24 @@ Date: September 2014
  Contact:  Subhash Jadavani 
  Description:  This entry could be used to set or show the UFS device
system power management level. The current driver
-   implementation supports 6 levels with next target states:
+   implementation supports 7 levels with next target states:
  
  		==  

-   0   an UFS device will stay active, an UIC link will
+   0   UFS device will stay active, UIC link will
stay active
-   1   an UFS device will stay active, an UIC link will
+   1   UFS device will stay active, UIC link will
hibernate
-   2   an UFS device will moved to sleep, an UIC link will
+   2   UFS device will be moved to sleep, UIC link will
stay active
-   3   an UFS device will moved to sleep, an UIC link will
+   3   UFS device will be moved to sleep, UIC link will
hibernate
-   4   an UFS device will be powered off, an UIC link will
+   4   UFS device will be powered off, UIC link will
hibernate
-   5   an UFS device will be powered off, an UIC link will
+   5   UFS device will be powered off, UIC link will
be powered off
+   6   UFS device will be moved to deep sleep, UIC link
+   will be powered off. Note, deep sleep might not be
+   supported in which case this value will not be accepted
==  
  
  What:		/sys/bus/platform/drivers/ufshcd/*/spm_target_dev_state

diff --git 

Re: [PATCH V4 2/2] scsi: ufs: Allow an error return value from ->device_reset()

[Asutosh Das (asd)]

On 11/3/2020 6:14 AM, Adrian Hunter wrote:

It is simpler for drivers to provide a ->device_reset() callback
irrespective of whether the GPIO, or firmware interface necessary to do the
reset, is discovered during probe.

Change ->device_reset() to return an error code.  Drivers that provide
the callback, but do not do the reset operation should return -EOPNOTSUPP.

Signed-off-by: Adrian Hunter 


Reviewed-by: Asutosh Das 


---
  drivers/scsi/ufs/ufs-mediatek.c |  4 +++-
  drivers/scsi/ufs/ufs-qcom.c |  6 --
  drivers/scsi/ufs/ufshcd.h   | 11 +++
  3 files changed, 14 insertions(+), 7 deletions(-)

diff --git a/drivers/scsi/ufs/ufs-mediatek.c b/drivers/scsi/ufs/ufs-mediatek.c
index 8df73bc2f8cb..914a827a93ee 100644
--- a/drivers/scsi/ufs/ufs-mediatek.c
+++ b/drivers/scsi/ufs/ufs-mediatek.c
@@ -743,7 +743,7 @@ static int ufs_mtk_link_startup_notify(struct ufs_hba *hba,
return ret;
  }
  
-static void ufs_mtk_device_reset(struct ufs_hba *hba)

+static int ufs_mtk_device_reset(struct ufs_hba *hba)
  {
struct arm_smccc_res res;
  
@@ -764,6 +764,8 @@ static void ufs_mtk_device_reset(struct ufs_hba *hba)

usleep_range(1, 15000);
  
  	dev_info(hba->dev, "device reset done\n");

+
+   return 0;
  }
  
  static int ufs_mtk_link_set_hpm(struct ufs_hba *hba)

diff --git a/drivers/scsi/ufs/ufs-qcom.c b/drivers/scsi/ufs/ufs-qcom.c
index 9a19c6d15d3b..357c3b49321d 100644
--- a/drivers/scsi/ufs/ufs-qcom.c
+++ b/drivers/scsi/ufs/ufs-qcom.c
@@ -1422,13 +1422,13 @@ static void ufs_qcom_dump_dbg_regs(struct ufs_hba *hba)
   *
   * Toggles the (optional) reset line to reset the attached device.
   */
-static void ufs_qcom_device_reset(struct ufs_hba *hba)
+static int ufs_qcom_device_reset(struct ufs_hba *hba)
  {
struct ufs_qcom_host *host = ufshcd_get_variant(hba);
  
  	/* reset gpio is optional */

if (!host->device_reset)
-   return;
+   return -EOPNOTSUPP;
  
  	/*

 * The UFS device shall detect reset pulses of 1us, sleep for 10us to
@@ -1439,6 +1439,8 @@ static void ufs_qcom_device_reset(struct ufs_hba *hba)
  
  	gpiod_set_value_cansleep(host->device_reset, 0);

usleep_range(10, 15);
+
+   return 0;
  }
  
  #if IS_ENABLED(CONFIG_DEVFREQ_GOV_SIMPLE_ONDEMAND)

diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
index 213be0667b59..5191d87f6263 100644
--- a/drivers/scsi/ufs/ufshcd.h
+++ b/drivers/scsi/ufs/ufshcd.h
@@ -323,7 +323,7 @@ struct ufs_hba_variant_ops {
int (*resume)(struct ufs_hba *, enum ufs_pm_op);
void(*dbg_register_dump)(struct ufs_hba *hba);
int (*phy_initialization)(struct ufs_hba *);
-   void(*device_reset)(struct ufs_hba *hba);
+   int (*device_reset)(struct ufs_hba *hba);
void(*config_scaling_param)(struct ufs_hba *hba,
struct devfreq_dev_profile *profile,
void *data);
@@ -1207,9 +1207,12 @@ static inline void ufshcd_vops_dbg_register_dump(struct 
ufs_hba *hba)
  static inline void ufshcd_vops_device_reset(struct ufs_hba *hba)
  {
if (hba->vops && hba->vops->device_reset) {
-   hba->vops->device_reset(hba);
-   ufshcd_set_ufs_dev_active(hba);
-   ufshcd_update_reg_hist(>ufs_stats.dev_reset, 0);
+   int err = hba->vops->device_reset(hba);
+
+   if (!err)
+   ufshcd_set_ufs_dev_active(hba);
+   if (err != -EOPNOTSUPP)
+   ufshcd_update_reg_hist(>ufs_stats.dev_reset, err);
}
  }
  




--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
Linux Foundation Collaborative Project

Re: [PATCH v9 7/9] scsi: ufs: Move dumps in IRQ handler to error handler

[Asutosh Das (asd)]

On 8/3/2020 2:04 AM, Can Guo wrote:

Sometime dumps in IRQ handler are heavy enough to cause system stability
issues, move them to error handler and only print basic host regs here.

Signed-off-by: Can Guo 
Reviewed-by: Bean Huo 
---


Reviewed-by: Asutosh Das 


  drivers/scsi/ufs/ufshcd.c | 23 +++
  1 file changed, 15 insertions(+), 8 deletions(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 6a10003..a79fbbd 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -5696,6 +5696,19 @@ static void ufshcd_err_handler(struct work_struct *work)
UFSHCD_UIC_DL_TCx_REPLAY_ERROR
needs_reset = true;
  
+	if (hba->saved_err & (INT_FATAL_ERRORS | UIC_ERROR |

+ UFSHCD_UIC_HIBERN8_MASK)) {
+   bool pr_prdt = !!(hba->saved_err & SYSTEM_BUS_FATAL_ERROR);
+
+   spin_unlock_irqrestore(hba->host->host_lock, flags);
+   ufshcd_print_host_state(hba);
+   ufshcd_print_pwr_info(hba);
+   ufshcd_print_host_regs(hba);
+   ufshcd_print_tmrs(hba, hba->outstanding_tasks);
+   ufshcd_print_trs(hba, hba->outstanding_reqs, pr_prdt);
+   spin_lock_irqsave(hba->host->host_lock, flags);
+   }
+
/*
 * if host reset is required then skip clearing the pending
 * transfers forcefully because they will get cleared during
@@ -5915,18 +5928,12 @@ static irqreturn_t ufshcd_check_errors(struct ufs_hba 
*hba)
  
  		/* dump controller state before resetting */

if (hba->saved_err & (INT_FATAL_ERRORS | UIC_ERROR)) {
-   bool pr_prdt = !!(hba->saved_err &
-   SYSTEM_BUS_FATAL_ERROR);
-
dev_err(hba->dev, "%s: saved_err 0x%x saved_uic_err 
0x%x\n",
__func__, hba->saved_err,
hba->saved_uic_err);
-
-   ufshcd_print_host_regs(hba);
+   ufshcd_dump_regs(hba, 0, UFSHCI_REG_SPACE_SIZE,
+"host_regs: ");
ufshcd_print_pwr_info(hba);
-   ufshcd_print_tmrs(hba, hba->outstanding_tasks);
-   ufshcd_print_trs(hba, hba->outstanding_reqs,
-   pr_prdt);
}
ufshcd_schedule_eh_work(hba);
retval |= IRQ_HANDLED;




--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
Linux Foundation Collaborative Project

Re: [PATCH v7 7/8] scsi: ufs: Move dumps in IRQ handler to error handler

[Asutosh Das (asd)]

On 7/29/2020 6:02 AM, Can Guo wrote:

Hi Asutosh,

On 2020-07-29 02:06, Asutosh Das (asd) wrote:

On 7/27/2020 10:00 PM, Can Guo wrote:

Sometime dumps in IRQ handler are heavy enough to cause system stability
issues, move them to error handler.

Signed-off-by: Can Guo 
---
  drivers/scsi/ufs/ufshcd.c | 31 +++
  1 file changed, 15 insertions(+), 16 deletions(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index c480823..b2bafa3 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -5682,6 +5682,21 @@ static void ufshcd_err_handler(struct 
work_struct *work)

  UFSHCD_UIC_DL_TCx_REPLAY_ERROR
  needs_reset = true;
  +    if (hba->saved_err & (INT_FATAL_ERRORS | UIC_ERROR |
+  UFSHCD_UIC_HIBERN8_MASK)) {
+    bool pr_prdt = !!(hba->saved_err & SYSTEM_BUS_FATAL_ERROR);
+
+    dev_err(hba->dev, "%s: saved_err 0x%x saved_uic_err 0x%x\n",
+    __func__, hba->saved_err, hba->saved_uic_err);
+    spin_unlock_irqrestore(hba->host->host_lock, flags);
+    ufshcd_print_host_state(hba);
+    ufshcd_print_pwr_info(hba);
+    ufshcd_print_host_regs(hba);
+    ufshcd_print_tmrs(hba, hba->outstanding_tasks);
+    ufshcd_print_trs(hba, hba->outstanding_reqs, pr_prdt);
+    spin_lock_irqsave(hba->host->host_lock, flags);
+    }
+
  /*
   * if host reset is required then skip clearing the pending
   * transfers forcefully because they will get cleared during
@@ -5900,22 +5915,6 @@ static irqreturn_t ufshcd_check_errors(struct 
ufs_hba *hba)

    /* block commands from scsi mid-layer */
  ufshcd_scsi_block_requests(hba);
-
-    /* dump controller state before resetting */
-    if (hba->saved_err & (INT_FATAL_ERRORS | UIC_ERROR)) {
-    bool pr_prdt = !!(hba->saved_err &
-    SYSTEM_BUS_FATAL_ERROR);
-
-    dev_err(hba->dev, "%s: saved_err 0x%x saved_uic_err 
0x%x\n",

-    __func__, hba->saved_err,
-    hba->saved_uic_err);
-
-    ufshcd_print_host_regs(hba);
-    ufshcd_print_pwr_info(hba);

How about keep the above prints and move the tmrs and trs to eh?
Sometimes in system instability, the eh may not get a chance to run
even. Still the above prints would provide some clues.


Here is the IRQ handler, ufshcd_print_host_regs() is sometime heavy
enough to cause stability issues during my fault injection test, since
it prints host regs, reg's history, crypto debug infos plus prints
from vops_dump.

How about just printing host regs and reg history here? Most time, these
infos are enough.


That'd work too.


Thanks,

Can Guo.


-    ufshcd_print_tmrs(hba, hba->outstanding_tasks);
-    ufshcd_print_trs(hba, hba->outstanding_reqs,
-    pr_prdt);
-    }
  ufshcd_schedule_eh_work(hba);
  retval |= IRQ_HANDLED;
  }




--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
Linux Foundation Collaborative Project

Re: [PATCH v7 7/8] scsi: ufs: Move dumps in IRQ handler to error handler

[Asutosh Das (asd)]

On 7/27/2020 10:00 PM, Can Guo wrote:

Sometime dumps in IRQ handler are heavy enough to cause system stability
issues, move them to error handler.

Signed-off-by: Can Guo 
---
  drivers/scsi/ufs/ufshcd.c | 31 +++
  1 file changed, 15 insertions(+), 16 deletions(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index c480823..b2bafa3 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -5682,6 +5682,21 @@ static void ufshcd_err_handler(struct work_struct *work)
UFSHCD_UIC_DL_TCx_REPLAY_ERROR
needs_reset = true;
  
+	if (hba->saved_err & (INT_FATAL_ERRORS | UIC_ERROR |

+ UFSHCD_UIC_HIBERN8_MASK)) {
+   bool pr_prdt = !!(hba->saved_err & SYSTEM_BUS_FATAL_ERROR);
+
+   dev_err(hba->dev, "%s: saved_err 0x%x saved_uic_err 0x%x\n",
+   __func__, hba->saved_err, hba->saved_uic_err);
+   spin_unlock_irqrestore(hba->host->host_lock, flags);
+   ufshcd_print_host_state(hba);
+   ufshcd_print_pwr_info(hba);
+   ufshcd_print_host_regs(hba);
+   ufshcd_print_tmrs(hba, hba->outstanding_tasks);
+   ufshcd_print_trs(hba, hba->outstanding_reqs, pr_prdt);
+   spin_lock_irqsave(hba->host->host_lock, flags);
+   }
+
/*
 * if host reset is required then skip clearing the pending
 * transfers forcefully because they will get cleared during
@@ -5900,22 +5915,6 @@ static irqreturn_t ufshcd_check_errors(struct ufs_hba 
*hba)
  
  		/* block commands from scsi mid-layer */

ufshcd_scsi_block_requests(hba);
-
-   /* dump controller state before resetting */
-   if (hba->saved_err & (INT_FATAL_ERRORS | UIC_ERROR)) {
-   bool pr_prdt = !!(hba->saved_err &
-   SYSTEM_BUS_FATAL_ERROR);
-
-   dev_err(hba->dev, "%s: saved_err 0x%x saved_uic_err 
0x%x\n",
-   __func__, hba->saved_err,
-   hba->saved_uic_err);
-
-   ufshcd_print_host_regs(hba);
-   ufshcd_print_pwr_info(hba);

How about keep the above prints and move the tmrs and trs to eh?
Sometimes in system instability, the eh may not get a chance to run 
even. Still the above prints would provide some clues.

-   ufshcd_print_tmrs(hba, hba->outstanding_tasks);
-   ufshcd_print_trs(hba, hba->outstanding_reqs,
-   pr_prdt);
-   }
ufshcd_schedule_eh_work(hba);
retval |= IRQ_HANDLED;
}




--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
Linux Foundation Collaborative Project

Re: [PATCH v7 4/8] scsi: ufs: Add some debug infos to ufshcd_print_host_state

[Asutosh Das (asd)]

On 7/27/2020 10:00 PM, Can Guo wrote:

The infos of the last interrupt status and its timestamp are very helpful
when debug system stability issues, e.g. IRQ starvation, so add them to
ufshcd_print_host_state. Meanwhile, UFS device infos like model name and
its FW version also come in handy during debug. In addition, this change
makes cleanup to some prints in ufshcd_print_host_regs as similar prints
are already available in ufshcd_print_host_state.

Signed-off-by: Can Guo 
Reviewed-by: Avri Altman 


Reviewed-by: Asutosh Das 


---
  drivers/scsi/ufs/ufshcd.c | 31 ++-
  drivers/scsi/ufs/ufshcd.h |  5 +
  2 files changed, 23 insertions(+), 13 deletions(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 99bd3e4..eda4dc6 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -411,15 +411,6 @@ static void ufshcd_print_err_hist(struct ufs_hba *hba,
  static void ufshcd_print_host_regs(struct ufs_hba *hba)
  {
ufshcd_dump_regs(hba, 0, UFSHCI_REG_SPACE_SIZE, "host_regs: ");
-   dev_err(hba->dev, "hba->ufs_version = 0x%x, hba->capabilities = 0x%x\n",
-   hba->ufs_version, hba->capabilities);
-   dev_err(hba->dev,
-   "hba->outstanding_reqs = 0x%x, hba->outstanding_tasks = 0x%x\n",
-   (u32)hba->outstanding_reqs, (u32)hba->outstanding_tasks);
-   dev_err(hba->dev,
-   "last_hibern8_exit_tstamp at %lld us, hibern8_exit_cnt = %d\n",
-   ktime_to_us(hba->ufs_stats.last_hibern8_exit_tstamp),
-   hba->ufs_stats.hibern8_exit_cnt);
  
  	ufshcd_print_err_hist(hba, >ufs_stats.pa_err, "pa_err");

ufshcd_print_err_hist(hba, >ufs_stats.dl_err, "dl_err");
@@ -438,8 +429,6 @@ static void ufshcd_print_host_regs(struct ufs_hba *hba)
ufshcd_print_err_hist(hba, >ufs_stats.host_reset, "host_reset");
ufshcd_print_err_hist(hba, >ufs_stats.task_abort, "task_abort");
  
-	ufshcd_print_clk_freqs(hba);

-
ufshcd_vops_dbg_register_dump(hba);
  }
  
@@ -499,6 +488,8 @@ static void ufshcd_print_tmrs(struct ufs_hba *hba, unsigned long bitmap)
  
  static void ufshcd_print_host_state(struct ufs_hba *hba)

  {
+   struct scsi_device *sdev_ufs = hba->sdev_ufs_device;
+
dev_err(hba->dev, "UFS Host state=%d\n", hba->ufshcd_state);
dev_err(hba->dev, "outstanding reqs=0x%lx tasks=0x%lx\n",
hba->outstanding_reqs, hba->outstanding_tasks);
@@ -511,12 +502,24 @@ static void ufshcd_print_host_state(struct ufs_hba *hba)
dev_err(hba->dev, "Auto BKOPS=%d, Host self-block=%d\n",
hba->auto_bkops_enabled, hba->host->host_self_blocked);
dev_err(hba->dev, "Clk gate=%d\n", hba->clk_gating.state);
+   dev_err(hba->dev,
+   "last_hibern8_exit_tstamp at %lld us, hibern8_exit_cnt=%d\n",
+   ktime_to_us(hba->ufs_stats.last_hibern8_exit_tstamp),
+   hba->ufs_stats.hibern8_exit_cnt);
+   dev_err(hba->dev, "last intr at %lld us, last intr status=0x%x\n",
+   ktime_to_us(hba->ufs_stats.last_intr_ts),
+   hba->ufs_stats.last_intr_status);
dev_err(hba->dev, "error handling flags=0x%x, req. abort count=%d\n",
hba->eh_flags, hba->req_abort_count);
-   dev_err(hba->dev, "Host capabilities=0x%x, caps=0x%x\n",
-   hba->capabilities, hba->caps);
+   dev_err(hba->dev, "hba->ufs_version=0x%x, Host capabilities=0x%x, 
caps=0x%x\n",
+   hba->ufs_version, hba->capabilities, hba->caps);
dev_err(hba->dev, "quirks=0x%x, dev. quirks=0x%x\n", hba->quirks,
hba->dev_quirks);
+   if (sdev_ufs)
+   dev_err(hba->dev, "UFS dev info: %.8s %.16s rev %.4s\n",
+   sdev_ufs->vendor, sdev_ufs->model, sdev_ufs->rev);
+
+   ufshcd_print_clk_freqs(hba);
  }
  
  /**

@@ -5951,6 +5954,8 @@ static irqreturn_t ufshcd_intr(int irq, void *__hba)
  
  	spin_lock(hba->host->host_lock);

intr_status = ufshcd_readl(hba, REG_INTERRUPT_STATUS);
+   hba->ufs_stats.last_intr_status = intr_status;
+   hba->ufs_stats.last_intr_ts = ktime_get();
  
  	/*

 * There could be max of hba->nutrs reqs in flight and in worst case
diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
index 656c069..5b2cdaf 100644
--- a/drivers/scsi/ufs/ufshcd.h
+++ b/drivers/scsi/ufs/ufshcd.h
@@ -406,6 +406,8 @@ struct ufs_err_reg_hist {
  
  /**

   * struct ufs_stats - keeps usage/err statistics
+ * @last_intr_status: record the last interrupt status.
+ * @last_intr_ts: record the last interrupt timestamp.
   * @hibern8_exit_cnt: Counter to keep track of number of exits,
   *reset this after link-startup.
   * @last_hibern8_exit_tstamp: Set time after the hibern8 exit.
@@ -425,6 +427,9 @@ struct ufs_err_reg_hist {
   * @tsk_abort: tracks task abort events
   */
  struct ufs_stats {
+   u32 last_intr_status;
+   ktime_t last_intr_ts;
+
 

Re: [PATCH v2] scsi: ufs: Disable WriteBooster capability in non-supported UFS device

[Asutosh Das (asd)]

On 6/24/2020 12:41 AM, Stanley Chu wrote:

If UFS device is not qualified to enter the detection of WriteBooster
probing by disallowed UFS version or device quirks, then WriteBooster
capability in host shall be disabled to prevent any WriteBooster
operations in the future.

Fixes: 3d17b9b5ab11 ("scsi: ufs: Add write booster feature support")
Signed-off-by: Stanley Chu 
---
  drivers/scsi/ufs/ufshcd.c | 35 +++
  1 file changed, 19 insertions(+), 16 deletions(-)


Reviewed-by: Asutosh Das 



diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index f173ad1bd79f..c62bd47beeaa 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -6847,21 +6847,31 @@ static int ufshcd_scsi_add_wlus(struct ufs_hba *hba)
  
  static void ufshcd_wb_probe(struct ufs_hba *hba, u8 *desc_buf)

  {
+   struct ufs_dev_info *dev_info = >dev_info;
u8 lun;
u32 d_lu_wb_buf_alloc;
  
  	if (!ufshcd_is_wb_allowed(hba))

return;
+   /*
+* Probe WB only for UFS-2.2 and UFS-3.1 (and later) devices or
+* UFS devices with quirk UFS_DEVICE_QUIRK_SUPPORT_EXTENDED_FEATURES
+* enabled
+*/
+   if (!(dev_info->wspecversion >= 0x310 ||
+ dev_info->wspecversion == 0x220 ||
+(hba->dev_quirks & UFS_DEVICE_QUIRK_SUPPORT_EXTENDED_FEATURES)))
+   goto wb_disabled;
  
  	if (hba->desc_size[QUERY_DESC_IDN_DEVICE] <

DEVICE_DESC_PARAM_EXT_UFS_FEATURE_SUP + 4)
goto wb_disabled;
  
-	hba->dev_info.d_ext_ufs_feature_sup =

+   dev_info->d_ext_ufs_feature_sup =
get_unaligned_be32(desc_buf +
   DEVICE_DESC_PARAM_EXT_UFS_FEATURE_SUP);
  
-	if (!(hba->dev_info.d_ext_ufs_feature_sup & UFS_DEV_WRITE_BOOSTER_SUP))

+   if (!(dev_info->d_ext_ufs_feature_sup & UFS_DEV_WRITE_BOOSTER_SUP))
goto wb_disabled;
  
  	/*

@@ -6870,17 +6880,17 @@ static void ufshcd_wb_probe(struct ufs_hba *hba, u8 
*desc_buf)
 * a max of 1 lun would have wb buffer configured.
 * Now only shared buffer mode is supported.
 */
-   hba->dev_info.b_wb_buffer_type =
+   dev_info->b_wb_buffer_type =
desc_buf[DEVICE_DESC_PARAM_WB_TYPE];
  
-	hba->dev_info.b_presrv_uspc_en =

+   dev_info->b_presrv_uspc_en =
desc_buf[DEVICE_DESC_PARAM_WB_PRESRV_USRSPC_EN];
  
-	if (hba->dev_info.b_wb_buffer_type == WB_BUF_MODE_SHARED) {

-   hba->dev_info.d_wb_alloc_units =
+   if (dev_info->b_wb_buffer_type == WB_BUF_MODE_SHARED) {
+   dev_info->d_wb_alloc_units =
get_unaligned_be32(desc_buf +
   DEVICE_DESC_PARAM_WB_SHARED_ALLOC_UNITS);
-   if (!hba->dev_info.d_wb_alloc_units)
+   if (!dev_info->d_wb_alloc_units)
goto wb_disabled;
} else {
for (lun = 0; lun < UFS_UPIU_MAX_WB_LUN_ID; lun++) {
@@ -6891,7 +6901,7 @@ static void ufshcd_wb_probe(struct ufs_hba *hba, u8 
*desc_buf)
(u8 *)_lu_wb_buf_alloc,
sizeof(d_lu_wb_buf_alloc));
if (d_lu_wb_buf_alloc) {
-   hba->dev_info.wb_dedicated_lu = lun;
+   dev_info->wb_dedicated_lu = lun;
break;
}
}
@@ -6977,14 +6987,7 @@ static int ufs_get_device_desc(struct ufs_hba *hba)
  
  	ufs_fixup_device_setup(hba);
  
-	/*

-* Probe WB only for UFS-3.1 devices or UFS devices with quirk
-* UFS_DEVICE_QUIRK_SUPPORT_EXTENDED_FEATURES enabled
-*/
-   if (dev_info->wspecversion >= 0x310 ||
-   dev_info->wspecversion == 0x220 ||
-   (hba->dev_quirks & UFS_DEVICE_QUIRK_SUPPORT_EXTENDED_FEATURES))
-   ufshcd_wb_probe(hba, desc_buf);
+   ufshcd_wb_probe(hba, desc_buf);
  
  	/*

 * ufshcd_read_string_desc returns size of the string




--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
Linux Foundation Collaborative Project

Re: [PATCH v4 0/4] scsi: ufs: Fix WriteBooster and cleanup UFS driver

[Asutosh Das (asd)]

On 5/22/2020 1:32 AM, Stanley Chu wrote:

Hi,

This patch set fixes some WriteBooster issues and do small cleanup in UFS driver

v3 -> v4
   - Squash patch [4] and [5] (Asutosh)
   - Fix commit message in patch [4]

v2 -> v3
   - Introduce patch [5] to fix possible VCC power drain during runtime suspend 
(Asutosh)

v1 -> v2
   - Remove dummy new line in patch [4] (Asutosh)
   - Add more limitation to allow WriteBooster flush during Hibern8 in 
runtime-suspend. Now the device power mode is kept as Active power mode only if 
link is put in Hibern8 or Auto-Hibern8 is enabled during runtime-suspend 
(Asutosh)

Stanley Chu (4):
   scsi: ufs: Remove unnecessary memset for dev_info
   scsi: ufs: Allow WriteBooster on UFS 2.2 devices
   scsi: ufs: Fix index of attributes query for WriteBooster feature
   scsi: ufs: Fix WriteBooster flush during runtime suspend

  drivers/scsi/ufs/ufs-sysfs.c | 13 -
  drivers/scsi/ufs/ufs.h   |  2 +-
  drivers/scsi/ufs/ufshcd.c| 99 +---
  drivers/scsi/ufs/ufshcd.h|  3 +-
  4 files changed, 82 insertions(+), 35 deletions(-)



This set looks good to me.

Reviewed-by: Asutosh Das 

--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
Linux Foundation Collaborative Project

Re: [PATCH v2 1/3] scsi: ufshcd: Update the set frequency to devfreq

[Asutosh Das (asd)]

Hi Jeffrey
On 5/25/2020 3:19 PM, Jeffrey Hugo wrote:

On Wed, Mar 25, 2020 at 12:29 PM Asutosh Das  wrote:


Currently, the frequency that devfreq provides the
driver to set always leads the clocks to be scaled up.
Hence, round the clock-rate to the nearest frequency
before deciding to scale.

Also update the devfreq statistics of current frequency.

Signed-off-by: Asutosh Das 


This change appears to cause issues for the Lenovo Miix 630, as
identified by git bisect.



Thanks for reporting this.


On 5.6-final, My boot log looks normal.  On 5.7-rc7, the Lenovo Miix
630 rarely boots, usually stuck in some kind of infinite printk loop.

If I disable some of the UFS logging, I can capture this from the
logs, as soon as UFS inits -

[4.353860] ufshcd-qcom 1da4000.ufshc: ufshcd_intr: Unhandled
interrupt 0x
[4.359605] ufshcd-qcom 1da4000.ufshc: ufshcd_intr: Unhandled
interrupt 0x
[4.365412] ufshcd-qcom 1da4000.ufshc: ufshcd_check_errors:
saved_err 0x4 saved_uic_err 0x2
[4.371121] ufshcd-qcom 1da4000.ufshc: hba->ufs_version = 0x210,
hba->capabilities = 0x1587001f
[4.376846] ufshcd-qcom 1da4000.ufshc: hba->outstanding_reqs =
0x10, hba->outstanding_tasks = 0x0
[4.382636] ufshcd-qcom 1da4000.ufshc: last_hibern8_exit_tstamp at
0 us, hibern8_exit_cnt = 0
[4.388368] ufshcd-qcom 1da4000.ufshc: No record of pa_err
[4.394001] ufshcd-qcom 1da4000.ufshc: dl_err[0] = 0x8001 at 3873626 us
[4.399577] ufshcd-qcom 1da4000.ufshc: No record of nl_err
[4.405053] ufshcd-qcom 1da4000.ufshc: No record of tl_err
[4.410464] ufshcd-qcom 1da4000.ufshc: No record of dme_err
[4.415747] ufshcd-qcom 1da4000.ufshc: No record of auto_hibern8_err
[4.420950] ufshcd-qcom 1da4000.ufshc: No record of fatal_err
[4.426013] ufshcd-qcom 1da4000.ufshc: No record of link_startup_fail
[4.430950] ufshcd-qcom 1da4000.ufshc: No record of resume_fail
[4.435786] ufshcd-qcom 1da4000.ufshc: No record of suspend_fail
[4.440538] ufshcd-qcom 1da4000.ufshc: dev_reset[0] = 0x0 at 3031009 us
[4.445199] ufshcd-qcom 1da4000.ufshc: No record of host_reset
[4.449750] ufshcd-qcom 1da4000.ufshc: No record of task_abort
[4.454214] ufshcd-qcom 1da4000.ufshc: clk: core_clk, rate: 5000
[4.458590] ufshcd-qcom 1da4000.ufshc: clk: core_clk_unipro, rate: 3750

I don't understand how this change is breaking things, but it clearly is for me.

What kind of additional data would be useful to get to the bottom of this?



++

Let me take a look and get back on this.

--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
Linux Foundation Collaborative Project

Re: [PATCH v4 2/2] scsi: ufs-qcom: enter and exit hibern8 during clock scaling

[Asutosh Das (asd)]

Hi Avri,

On 5/20/2020 2:33 PM, Avri Altman wrote:

Hi,




Qualcomm controller needs to be in hibern8 before scaling clocks.
This change puts the controller in hibern8 state before scaling
and brings it out after scaling of clocks.

Signed-off-by: Asutosh Das 


I guess that your previous versions are pretty far back - ,
I noticed a comment by Pedro, so you might want to resend this series.


Ok.


What happens if the pre-change is successful,
but you are not getting to the post change because, e.g. ufshcd_set_clk_freq 
failed?


I agree. Let me check this.


Also, this piece of code is ~5 years old, so you might want to elaborate on how 
come hibernation is now needed.

Thanks,
Avri



Thanks for the review. Hibernation was needed since long actually.
I guess it was never pushed upstream.

Thanks,
-asd

--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
Linux Foundation Collaborative Project

Re: [PATCH v3 2/2] scsi: ufs-qcom: enter and exit hibern8 during clock scaling

[Asutosh Das (asd)]

Hi Pedro,

On 11/11/2019 7:54 AM, Pedro Sousa wrote:

Hi Asutosh,

Please check comments.

Sorry for missing out on this and thanks for your review.



-Original Message-
From: Asutosh Das 
Sent: Wednesday, October 23, 2019 5:49 PM
To: c...@codeaurora.org; rna...@codeaurora.org; vinholika...@gmail.com; 
j...@linux.vnet.ibm.com; martin.peter...@oracle.com
Cc: linux-s...@vger.kernel.org; kernel-t...@android.com; sarava...@google.com; saly...@google.com; Asutosh Das 
; Andy Gross ; Alim Akhtar ; Avri Altman 
; Pedro Sousa ; James E.J. Bottomley ; 
open list:ARM/QUALCOMM SUPPORT ; open list 
Subject: [PATCH v3 2/2] scsi: ufs-qcom: enter and exit hibern8 during clock 
scaling

Qualcomm controller needs to be in hibern8 before scaling clocks.
This change puts the controller in hibern8 state before scaling
and brings it out after scaling of clocks.

Signed-off-by: Asutosh Das 
---
  drivers/scsi/ufs/ufs-qcom.c | 12 +++-
  1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/ufs/ufs-qcom.c b/drivers/scsi/ufs/ufs-qcom.c
index a5b7148..55b1de5 100644
--- a/drivers/scsi/ufs/ufs-qcom.c
+++ b/drivers/scsi/ufs/ufs-qcom.c
@@ -1305,18 +1305,27 @@ static int ufs_qcom_clk_scale_notify(struct ufs_hba 
*hba,
int err = 0;
  
  	if (status == PRE_CHANGE) {

+   err = ufshcd_uic_hibern8_enter(hba);
+   if (err)
+   return err;
if (scale_up)
err = ufs_qcom_clk_scale_up_pre_change(hba);
else
err = ufs_qcom_clk_scale_down_pre_change(hba);
+   if (err)
+   ufshcd_uic_hibern8_exit(hba);
+
} else {
if (scale_up)
err = ufs_qcom_clk_scale_up_post_change(hba);
else
err = ufs_qcom_clk_scale_down_post_change(hba);
  
-		if (err || !dev_req_params)

+
+   if (err || !dev_req_params) {
+   ufshcd_uic_hibern8_exit(hba);
goto out;
+   }
  
  		ufs_qcom_cfg_timers(hba,

dev_req_params->gear_rx,
@@ -1324,6 +1333,7 @@ static int ufs_qcom_clk_scale_notify(struct ufs_hba *hba,
dev_req_params->hs_rate,
false);
ufs_qcom_update_bus_bw_vote(host);
+   ufshcd_uic_hibern8_exit(hba);

Here you are creating the possibility of returning a success even if hibern8 
exit fails.
If hibern8 exit fails the ufs recovery will be triggered and "err" variable 
will not get updated
in this function, how is this handled? Did you tested this possibility?

}
  
  out:





Yes - I agree with your comment. The error should be propagated from 
this function correctly to the caller. I'll push another version.


--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
Linux Foundation Collaborative Project

Re: [PATCH v3 5/5] scsi: ufs: Fix possible VCC power drain during runtime suspend

[Asutosh Das (asd)]

Hi Stanley,

On 5/16/2020 10:46 AM, Stanley Chu wrote:

The commit "scsi: ufs: Fix WriteBooster flush during runtime
suspend" promises essential resource, i.e., for UFS devices doing
WriteBooster buffer flush and Auto BKOPs. However if device
finishes its job but not resumed for a very long time, system
will have unnecessary power drain because VCC is still supplied.

To fix this, a method to recheck the threshold of keeping VCC
supply is required. However, the threshold recheck needs to
re-activate the link because the decision depends on the device
status.

Introduce a delayed work to force runtime resume after a certain
delay during runtime suspend. This makes threshold recheck simpler
which will be done in the next runtime-suspend.

Signed-off-by: Stanley Chu 
---


Is there a reason to have this code as a separate patch?
[1] Commit: "scsi: ufs: Fix WriteBooster flush during runtime suspend" 
introduces 'keep_curr_dev_pwr_mode' and the very next change (this one) 
removes it.

Do you think this change and [1] should be merged?


  drivers/scsi/ufs/ufs.h|  1 +
  drivers/scsi/ufs/ufshcd.c | 43 ++-
  drivers/scsi/ufs/ufshcd.h |  1 +
  3 files changed, 40 insertions(+), 5 deletions(-)

diff --git a/drivers/scsi/ufs/ufs.h b/drivers/scsi/ufs/ufs.h
index db07eedfed96..c70845d41449 100644
--- a/drivers/scsi/ufs/ufs.h
+++ b/drivers/scsi/ufs/ufs.h
@@ -574,6 +574,7 @@ struct ufs_dev_info {
u32 d_ext_ufs_feature_sup;
u8 b_wb_buffer_type;
u32 d_wb_alloc_units;
+   bool b_rpm_dev_flush_capable;
u8 b_presrv_uspc_en;
  };
  
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c

index f4f2c7b5ab0a..a137553f9b41 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -94,6 +94,9 @@
  /* default delay of autosuspend: 2000 ms */
  #define RPM_AUTOSUSPEND_DELAY_MS 2000
  
+/* Default delay of RPM device flush delayed work */

+#define RPM_DEV_FLUSH_RECHECK_WORK_DELAY_MS 5000
+
  /* Default value of wait time before gating device ref clock */
  #define UFSHCD_REF_CLK_GATING_WAIT_US 0xFF /* microsecs */
  
@@ -5310,7 +5313,7 @@ static bool ufshcd_wb_presrv_usrspc_keep_vcc_on(struct ufs_hba *hba,

return false;
  }
  
-static bool ufshcd_wb_keep_vcc_on(struct ufs_hba *hba)

+static bool ufshcd_wb_need_flush(struct ufs_hba *hba)
  {
int ret;
u32 avail_buf;
@@ -5348,6 +5351,21 @@ static bool ufshcd_wb_keep_vcc_on(struct ufs_hba *hba)
return ufshcd_wb_presrv_usrspc_keep_vcc_on(hba, avail_buf);
  }
  
+static void ufshcd_rpm_dev_flush_recheck_work(struct work_struct *work)

+{
+   struct ufs_hba *hba = container_of(to_delayed_work(work),
+  struct ufs_hba,
+  rpm_dev_flush_recheck_work);
+   /*
+* To prevent unnecessary VCC power drain after device finishes
+* WriteBooster buffer flush or Auto BKOPs, force runtime resume
+* after a certain delay to recheck the threshold by next runtime
+* supsend.
+*/
+   pm_runtime_get_sync(hba->dev);
+   pm_runtime_put_sync(hba->dev);
+}
+
  /**
   * ufshcd_exception_event_handler - handle exceptions raised by device
   * @work: pointer to work data
@@ -8164,7 +8182,6 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum 
ufs_pm_op pm_op)
enum ufs_pm_level pm_lvl;
enum ufs_dev_pwr_mode req_dev_pwr_mode;
enum uic_link_state req_link_state;
-   bool keep_curr_dev_pwr_mode = false;
  
  	hba->pm_op_in_progress = 1;

if (!ufshcd_is_shutdown_pm(pm_op)) {
@@ -8224,11 +8241,12 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum 
ufs_pm_op pm_op)
 * Hibern8, keep device power mode as "active power mode"
 * and VCC supply.
 */
-   keep_curr_dev_pwr_mode = hba->auto_bkops_enabled ||
+   hba->dev_info.b_rpm_dev_flush_capable =
+   hba->auto_bkops_enabled ||
(((req_link_state == UIC_LINK_HIBERN8_STATE) ||
((req_link_state == UIC_LINK_ACTIVE_STATE) &&
ufshcd_is_auto_hibern8_enabled(hba))) &&
-   ufshcd_wb_keep_vcc_on(hba));
+   ufshcd_wb_need_flush(hba));
}
  
  	if (req_dev_pwr_mode != hba->curr_dev_pwr_mode) {

@@ -8238,7 +8256,7 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum 
ufs_pm_op pm_op)
ufshcd_disable_auto_bkops(hba);
}
  
-		if (!keep_curr_dev_pwr_mode) {

+   if (!hba->dev_info.b_rpm_dev_flush_capable) {
ret = ufshcd_set_dev_pwr_mode(hba, req_dev_pwr_mode);
if (ret)
goto enable_gating;
@@ -8295,9 +8313,16 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum 
ufs_pm_op pm_op)
if (hba->clk_scaling.is_allowed)

Re: [PATCH v2 4/4] scsi: ufs: Fix WriteBooster flush during runtime suspend

[Asutosh Das (asd)]

On 5/14/2020 8:01 AM, Stanley Chu wrote:

Currently UFS host driver promises VCC supply if UFS device
needs to do WriteBooster flush during runtime suspend.

However the UFS specification mentions,

"While the flushing operation is in progress, the device is
in Active power mode."

Therefore UFS host driver needs to promise more: Keep UFS
device as "Active power mode", otherwise UFS device shall not
do any flush if device enters Sleep or PowerDown power mode.

Fix this by not changing device power mode if WriteBooster
flush is required in ufshcd_suspend().

Signed-off-by: Stanley Chu 
---
  drivers/scsi/ufs/ufs.h|  1 -
  drivers/scsi/ufs/ufshcd.c | 42 ---
  2 files changed, 22 insertions(+), 21 deletions(-)

diff --git a/drivers/scsi/ufs/ufs.h b/drivers/scsi/ufs/ufs.h
index b3135344ab3f..9e4bc2e97ada 100644
--- a/drivers/scsi/ufs/ufs.h
+++ b/drivers/scsi/ufs/ufs.h
@@ -577,7 +577,6 @@ struct ufs_dev_info {
u32 d_ext_ufs_feature_sup;
u8 b_wb_buffer_type;
u32 d_wb_alloc_units;
-   bool keep_vcc_on;
u8 b_presrv_uspc_en;
  };
  
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c

index 169a3379e468..b9f7744ca2b4 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -8101,8 +8101,7 @@ static void ufshcd_vreg_set_lpm(struct ufs_hba *hba)
!hba->dev_info.is_lu_power_on_wp) {
ufshcd_setup_vreg(hba, false);
} else if (!ufshcd_is_ufs_dev_active(hba)) {
-   if (!hba->dev_info.keep_vcc_on)
-   ufshcd_toggle_vreg(hba->dev, hba->vreg_info.vcc, false);
+   ufshcd_toggle_vreg(hba->dev, hba->vreg_info.vcc, false);
if (!ufshcd_is_link_active(hba)) {
ufshcd_config_vreg_lpm(hba, hba->vreg_info.vccq);
ufshcd_config_vreg_lpm(hba, hba->vreg_info.vccq2);
@@ -8172,6 +8171,7 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum 
ufs_pm_op pm_op)
enum ufs_pm_level pm_lvl;
enum ufs_dev_pwr_mode req_dev_pwr_mode;
enum uic_link_state req_link_state;
+   bool keep_curr_dev_pwr_mode = false;
  
  	hba->pm_op_in_progress = 1;

if (!ufshcd_is_shutdown_pm(pm_op)) {
@@ -8227,27 +8227,29 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum 
ufs_pm_op pm_op)
ufshcd_disable_auto_bkops(hba);
}
/*
-* With wb enabled, if the bkops is enabled or if the
-* configured WB type is 70% full, keep vcc ON
-* for the device to flush the wb buffer
+* If device needs to do BKOP or WB buffer flush during
+* Hibern8, keep device power mode as "active power mode"
+* and VCC supply.
 */
-   if ((hba->auto_bkops_enabled && ufshcd_is_wb_allowed(hba)) ||
-   ufshcd_wb_keep_vcc_on(hba))
-   hba->dev_info.keep_vcc_on = true;
-   else
-   hba->dev_info.keep_vcc_on = false;
-   } else {
-   hba->dev_info.keep_vcc_on = false;
+   keep_curr_dev_pwr_mode = hba->auto_bkops_enabled ||
+   (((req_link_state == UIC_LINK_HIBERN8_STATE) ||
+   ((req_link_state == UIC_LINK_ACTIVE_STATE) &&
+   ufshcd_is_auto_hibern8_enabled(hba))) &&
+   ufshcd_wb_keep_vcc_on(hba));
}
  

This looks fine.
But I still think the delayed check of flush status should be done to 
turn-off Vcc when flush is complete.



-   if ((req_dev_pwr_mode != hba->curr_dev_pwr_mode) &&
-   ((ufshcd_is_runtime_pm(pm_op) && !hba->auto_bkops_enabled) ||
-   !ufshcd_is_runtime_pm(pm_op))) {
-   /* ensure that bkops is disabled */
-   ufshcd_disable_auto_bkops(hba);
-   ret = ufshcd_set_dev_pwr_mode(hba, req_dev_pwr_mode);
-   if (ret)
-   goto enable_gating;
+   if (req_dev_pwr_mode != hba->curr_dev_pwr_mode) {
+   if ((ufshcd_is_runtime_pm(pm_op) && !hba->auto_bkops_enabled) ||
+   !ufshcd_is_runtime_pm(pm_op)) {
+   /* ensure that bkops is disabled */
+   ufshcd_disable_auto_bkops(hba);
+   }
+
+   if (!keep_curr_dev_pwr_mode) {
+   ret = ufshcd_set_dev_pwr_mode(hba, req_dev_pwr_mode);
+   if (ret)
+   goto enable_gating;
+   }
}
  
  	flush_work(>eeh_work);





--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
Linux Foundation Collaborative Project

Re: [PATCH v1 4/4] scsi: ufs: Fix WriteBooster flush during runtime suspend

[Asutosh Das (asd)]

On 5/14/2020 7:49 AM, Stanley Chu wrote:

Hi Asutosh,

On Thu, 2020-05-14 at 10:23 +0800, Stanley Chu wrote:

Hi Asutosh,

On Wed, 2020-05-13 at 12:31 -0700, Asutosh Das (asd) wrote:

On 5/12/2020 3:47 AM, Stanley Chu wrote:

Currently UFS host driver promises VCC supply if UFS device
needs to do WriteBooster flush during runtime suspend.

However the UFS specification mentions,

"While the flushing operation is in progress, the device is
in Active power mode."

Therefore UFS host driver needs to promise more: Keep UFS
device as "Active power mode", otherwise UFS device shall not
do any flush if device enters Sleep or PowerDown power mode.

Fix this by not changing device power mode if WriteBooster
flush is required in ufshcd_suspend().

Signed-off-by: Stanley Chu 
---
   drivers/scsi/ufs/ufs.h|  1 -
   drivers/scsi/ufs/ufshcd.c | 39 +++
   2 files changed, 19 insertions(+), 21 deletions(-)

diff --git a/drivers/scsi/ufs/ufs.h b/drivers/scsi/ufs/ufs.h
index b3135344ab3f..9e4bc2e97ada 100644
--- a/drivers/scsi/ufs/ufs.h
+++ b/drivers/scsi/ufs/ufs.h
@@ -577,7 +577,6 @@ struct ufs_dev_info {
u32 d_ext_ufs_feature_sup;
u8 b_wb_buffer_type;
u32 d_wb_alloc_units;
-   bool keep_vcc_on;
u8 b_presrv_uspc_en;
   };
   
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c

index 169a3379e468..2d0aff8ac260 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -8101,8 +8101,7 @@ static void ufshcd_vreg_set_lpm(struct ufs_hba *hba)
!hba->dev_info.is_lu_power_on_wp) {
ufshcd_setup_vreg(hba, false);
} else if (!ufshcd_is_ufs_dev_active(hba)) {
-   if (!hba->dev_info.keep_vcc_on)
-   ufshcd_toggle_vreg(hba->dev, hba->vreg_info.vcc, false);
+   ufshcd_toggle_vreg(hba->dev, hba->vreg_info.vcc, false);
if (!ufshcd_is_link_active(hba)) {
ufshcd_config_vreg_lpm(hba, hba->vreg_info.vccq);
ufshcd_config_vreg_lpm(hba, hba->vreg_info.vccq2);
@@ -8172,6 +8171,7 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum 
ufs_pm_op pm_op)
enum ufs_pm_level pm_lvl;
enum ufs_dev_pwr_mode req_dev_pwr_mode;
enum uic_link_state req_link_state;
+   bool keep_curr_dev_pwr_mode = false;
   
   	hba->pm_op_in_progress = 1;

if (!ufshcd_is_shutdown_pm(pm_op)) {
@@ -8226,28 +8226,27 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum 
ufs_pm_op pm_op)
/* make sure that auto bkops is disabled */
ufshcd_disable_auto_bkops(hba);
}
+

Unnecessary newline, perhaps?


Yap, I will remove it in next version.


/*
-* With wb enabled, if the bkops is enabled or if the
-* configured WB type is 70% full, keep vcc ON
-* for the device to flush the wb buffer
+* If device needs to do BKOP or WB buffer flush, keep device
+* power mode as "active power mode" and its VCC supply.
 */
-   if ((hba->auto_bkops_enabled && ufshcd_is_wb_allowed(hba)) ||
-   ufshcd_wb_keep_vcc_on(hba))
-   hba->dev_info.keep_vcc_on = true;
-   else
-   hba->dev_info.keep_vcc_on = false;
-   } else {
-   hba->dev_info.keep_vcc_on = false;
+   keep_curr_dev_pwr_mode = hba->auto_bkops_enabled ||
+   ufshcd_wb_keep_vcc_on(hba);

Should the device be in UFS_ACTIVE_PWR_MODE to perform auto-bkops?

Also, is it needed to keep the device in UFS_ACTIVE_PWR_MODE , if flush
on hibern8 is enabled and the link is being put to hibern8 mode during
runtime-suspend? Perhaps that should also be factored in here?


Both auto-bkops and WriteBooster flush during Hibern8 need device power
mode to be "Active Power Mode".

For auto-bkops, the spec mentions,

"If the background operations enable bit is set and the device is in
Active power mode or Idle power mode, then the device is allowed to
execute any internal operations."

For WriteBooster flush during Hibern8, the spec mentions,

"While the flushing operation is in progress, the device is in Active
power mode."

Therefore here we can use an unified "keep_curr_dev_pwr_mode" to
indicate the same requirements of above both features.

Besides, both operations may access flash array inside UFS device thus
VCC supply shall be also kept.

Before this patch, the original code will keep device power mode (stay
in Active Power Mode) if hba->auto_bkops_enabled is set as true during
runtime-suspend with UFSHCD_CAP_AUTO_BKOPS_SUSPEND capability is
enabled. This patch will not change this decision, just add
"WriteBooster flush during Hibern8"

Re: [PATCH v1 4/4] scsi: ufs: Fix WriteBooster flush during runtime suspend

[Asutosh Das (asd)]

On 5/12/2020 3:47 AM, Stanley Chu wrote:

Currently UFS host driver promises VCC supply if UFS device
needs to do WriteBooster flush during runtime suspend.

However the UFS specification mentions,

"While the flushing operation is in progress, the device is
in Active power mode."

Therefore UFS host driver needs to promise more: Keep UFS
device as "Active power mode", otherwise UFS device shall not
do any flush if device enters Sleep or PowerDown power mode.

Fix this by not changing device power mode if WriteBooster
flush is required in ufshcd_suspend().

Signed-off-by: Stanley Chu 
---
  drivers/scsi/ufs/ufs.h|  1 -
  drivers/scsi/ufs/ufshcd.c | 39 +++
  2 files changed, 19 insertions(+), 21 deletions(-)

diff --git a/drivers/scsi/ufs/ufs.h b/drivers/scsi/ufs/ufs.h
index b3135344ab3f..9e4bc2e97ada 100644
--- a/drivers/scsi/ufs/ufs.h
+++ b/drivers/scsi/ufs/ufs.h
@@ -577,7 +577,6 @@ struct ufs_dev_info {
u32 d_ext_ufs_feature_sup;
u8 b_wb_buffer_type;
u32 d_wb_alloc_units;
-   bool keep_vcc_on;
u8 b_presrv_uspc_en;
  };
  
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c

index 169a3379e468..2d0aff8ac260 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -8101,8 +8101,7 @@ static void ufshcd_vreg_set_lpm(struct ufs_hba *hba)
!hba->dev_info.is_lu_power_on_wp) {
ufshcd_setup_vreg(hba, false);
} else if (!ufshcd_is_ufs_dev_active(hba)) {
-   if (!hba->dev_info.keep_vcc_on)
-   ufshcd_toggle_vreg(hba->dev, hba->vreg_info.vcc, false);
+   ufshcd_toggle_vreg(hba->dev, hba->vreg_info.vcc, false);
if (!ufshcd_is_link_active(hba)) {
ufshcd_config_vreg_lpm(hba, hba->vreg_info.vccq);
ufshcd_config_vreg_lpm(hba, hba->vreg_info.vccq2);
@@ -8172,6 +8171,7 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum 
ufs_pm_op pm_op)
enum ufs_pm_level pm_lvl;
enum ufs_dev_pwr_mode req_dev_pwr_mode;
enum uic_link_state req_link_state;
+   bool keep_curr_dev_pwr_mode = false;
  
  	hba->pm_op_in_progress = 1;

if (!ufshcd_is_shutdown_pm(pm_op)) {
@@ -8226,28 +8226,27 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum 
ufs_pm_op pm_op)
/* make sure that auto bkops is disabled */
ufshcd_disable_auto_bkops(hba);
}
+

Unnecessary newline, perhaps?

/*
-* With wb enabled, if the bkops is enabled or if the
-* configured WB type is 70% full, keep vcc ON
-* for the device to flush the wb buffer
+* If device needs to do BKOP or WB buffer flush, keep device
+* power mode as "active power mode" and its VCC supply.
 */
-   if ((hba->auto_bkops_enabled && ufshcd_is_wb_allowed(hba)) ||
-   ufshcd_wb_keep_vcc_on(hba))
-   hba->dev_info.keep_vcc_on = true;
-   else
-   hba->dev_info.keep_vcc_on = false;
-   } else {
-   hba->dev_info.keep_vcc_on = false;
+   keep_curr_dev_pwr_mode = hba->auto_bkops_enabled ||
+   ufshcd_wb_keep_vcc_on(hba);

Should the device be in UFS_ACTIVE_PWR_MODE to perform auto-bkops?

Also, is it needed to keep the device in UFS_ACTIVE_PWR_MODE , if flush 
on hibern8 is enabled and the link is being put to hibern8 mode during 
runtime-suspend? Perhaps that should also be factored in here?

}
  
-	if ((req_dev_pwr_mode != hba->curr_dev_pwr_mode) &&

-   ((ufshcd_is_runtime_pm(pm_op) && !hba->auto_bkops_enabled) ||
-   !ufshcd_is_runtime_pm(pm_op))) {
-   /* ensure that bkops is disabled */
-   ufshcd_disable_auto_bkops(hba);
-   ret = ufshcd_set_dev_pwr_mode(hba, req_dev_pwr_mode);
-   if (ret)
-   goto enable_gating;
+   if (req_dev_pwr_mode != hba->curr_dev_pwr_mode) {
+   if ((ufshcd_is_runtime_pm(pm_op) && !hba->auto_bkops_enabled) ||
+   !ufshcd_is_runtime_pm(pm_op)) {
+   /* ensure that bkops is disabled */
+   ufshcd_disable_auto_bkops(hba);
+   }
+
+   if (!keep_curr_dev_pwr_mode) {
+   ret = ufshcd_set_dev_pwr_mode(hba, req_dev_pwr_mode);


Now, when the WB buffer is completely flushed out, the device should be 
put back into UFS_SLEEP_PWR_MODE or UFS_POWERDOWN_PWR_MODE. Say, the 
device buffer has to be flushed and during runtime-suspend, the device 
is put to UFS_ACTIVE_PWR_MODE and Vcc is kept ON; the device doesn't 
resume nor does the system enters suspend for a very long time, and with 
AH8 and hibern8 disabled, there will be an unnecessary power drain for 
that much time.


How about a periodic interval 

Re: [PATCH v2 4/4] scsi: ufs-mediatek: customize WriteBooster flush policy

[Asutosh Das (asd)]

On 5/12/2020 9:21 AM, Martin K. Petersen wrote:


Hi Asutosh!


Patchset looks good to me.

Reviewed-by: Asutosh Das 


When you want to approve an entire series, please respond to the cover
letter email. Otherwise the kernel.org tooling will only record the tag
for the individual patch you are responding to. In this case only patch
4 got tagged as reviewed in patchwork.



Hi Martin
Sure - I'll keep this in mind.

Thanks,
Asutosh

--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
Linux Foundation Collaborative Project

Re: [PATCH v1 4/4] scsi: ufs: Fix WriteBooster flush during runtime suspend

[Asutosh Das (asd)]

Hi Stanley,

On 5/12/2020 3:47 AM, Stanley Chu wrote:

Currently UFS host driver promises VCC supply if UFS device
needs to do WriteBooster flush during runtime suspend.

However the UFS specification mentions,

"While the flushing operation is in progress, the device is
in Active power mode."

Therefore UFS host driver needs to promise more: Keep UFS
device as "Active power mode", otherwise UFS device shall not
do any flush if device enters Sleep or PowerDown power mode.

Fix this by not changing device power mode if WriteBooster
flush is required in ufshcd_suspend().

Signed-off-by: Stanley Chu 
---
  drivers/scsi/ufs/ufs.h|  1 -
  drivers/scsi/ufs/ufshcd.c | 39 +++
  2 files changed, 19 insertions(+), 21 deletions(-)

diff --git a/drivers/scsi/ufs/ufs.h b/drivers/scsi/ufs/ufs.h
index b3135344ab3f..9e4bc2e97ada 100644
--- a/drivers/scsi/ufs/ufs.h
+++ b/drivers/scsi/ufs/ufs.h
@@ -577,7 +577,6 @@ struct ufs_dev_info {
u32 d_ext_ufs_feature_sup;
u8 b_wb_buffer_type;
u32 d_wb_alloc_units;
-   bool keep_vcc_on;
u8 b_presrv_uspc_en;
  };
  
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c

index 169a3379e468..2d0aff8ac260 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -8101,8 +8101,7 @@ static void ufshcd_vreg_set_lpm(struct ufs_hba *hba)
!hba->dev_info.is_lu_power_on_wp) {
ufshcd_setup_vreg(hba, false);
} else if (!ufshcd_is_ufs_dev_active(hba)) {
-   if (!hba->dev_info.keep_vcc_on)
-   ufshcd_toggle_vreg(hba->dev, hba->vreg_info.vcc, false);
+   ufshcd_toggle_vreg(hba->dev, hba->vreg_info.vcc, false);
if (!ufshcd_is_link_active(hba)) {
ufshcd_config_vreg_lpm(hba, hba->vreg_info.vccq);
ufshcd_config_vreg_lpm(hba, hba->vreg_info.vccq2);
@@ -8172,6 +8171,7 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum 
ufs_pm_op pm_op)
enum ufs_pm_level pm_lvl;
enum ufs_dev_pwr_mode req_dev_pwr_mode;
enum uic_link_state req_link_state;
+   bool keep_curr_dev_pwr_mode = false;
  
  	hba->pm_op_in_progress = 1;

if (!ufshcd_is_shutdown_pm(pm_op)) {
@@ -8226,28 +8226,27 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum 
ufs_pm_op pm_op)
/* make sure that auto bkops is disabled */
ufshcd_disable_auto_bkops(hba);
}
+
/*
-* With wb enabled, if the bkops is enabled or if the
-* configured WB type is 70% full, keep vcc ON
-* for the device to flush the wb buffer
+* If device needs to do BKOP or WB buffer flush, keep device
+* power mode as "active power mode" and its VCC supply.
 */
-   if ((hba->auto_bkops_enabled && ufshcd_is_wb_allowed(hba)) ||
-   ufshcd_wb_keep_vcc_on(hba))
-   hba->dev_info.keep_vcc_on = true;
-   else
-   hba->dev_info.keep_vcc_on = false;
-   } else {
-   hba->dev_info.keep_vcc_on = false;
+   keep_curr_dev_pwr_mode = hba->auto_bkops_enabled ||
+   ufshcd_wb_keep_vcc_on(hba);
}
  
-	if ((req_dev_pwr_mode != hba->curr_dev_pwr_mode) &&

-   ((ufshcd_is_runtime_pm(pm_op) && !hba->auto_bkops_enabled) ||
-   !ufshcd_is_runtime_pm(pm_op))) {
-   /* ensure that bkops is disabled */
-   ufshcd_disable_auto_bkops(hba);
-   ret = ufshcd_set_dev_pwr_mode(hba, req_dev_pwr_mode);
-   if (ret)
-   goto enable_gating;
+   if (req_dev_pwr_mode != hba->curr_dev_pwr_mode) {
+   if ((ufshcd_is_runtime_pm(pm_op) && !hba->auto_bkops_enabled) ||
+   !ufshcd_is_runtime_pm(pm_op)) {
+   /* ensure that bkops is disabled */
+   ufshcd_disable_auto_bkops(hba);
+   }
+
+   if (!keep_curr_dev_pwr_mode) {
+   ret = ufshcd_set_dev_pwr_mode(hba, req_dev_pwr_mode);
+   if (ret)
+   goto enable_gating;
+   }
}
  
  	flush_work(>eeh_work);




Can you please confirm that you've tested and found that with the 
previous code, the flush operation in the device was not happening.


If so, please can you let me know the test-case that you ran to figure 
this out.


I'd like to verify this at my end.

--
Thanks,
-asd

--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
Linux Foundation Collaborative Project

Re: [PATCH v2 4/4] scsi: ufs-mediatek: customize WriteBooster flush policy

[Asutosh Das (asd)]

On 5/9/2020 2:37 AM, Stanley Chu wrote:

Change the WriteBooster policy to keep VCC on during
runtime suspend if available WriteBooster buffer is less
than 80%.

Signed-off-by: Stanley Chu 
---
  drivers/scsi/ufs/ufs-mediatek.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/scsi/ufs/ufs-mediatek.c b/drivers/scsi/ufs/ufs-mediatek.c
index 56620f7d88ce..94e97701f456 100644
--- a/drivers/scsi/ufs/ufs-mediatek.c
+++ b/drivers/scsi/ufs/ufs-mediatek.c
@@ -271,6 +271,7 @@ static int ufs_mtk_init(struct ufs_hba *hba)
  
  	/* Enable WriteBooster */

hba->caps |= UFSHCD_CAP_WB_EN;
+   hba->vps->wb_flush_threshold = UFS_WB_BUF_REMAIN_PERCENT(80);
  
  	/*

 * ufshcd_vops_init() is invoked after



Patchset looks good to me.

Reviewed-by: Asutosh Das 


--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
Linux Foundation Collaborative Project

Re: [PATCH v1 3/5] scsi: ufs: customize flush threshold for WriteBooster

[Asutosh Das (asd)]

On 5/8/2020 10:15 AM, Stanley Chu wrote:

Allow flush threshold for WriteBooster to be customizable by
vendors. To achieve this, make the value as a variable in struct
ufs_hba first.

Signed-off-by: Stanley Chu 
---
  drivers/scsi/ufs/ufshcd.c | 6 --
  drivers/scsi/ufs/ufshcd.h | 1 +
  2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index cdacbe6378a1..9a0ce6550c2f 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -5301,8 +5301,8 @@ static bool ufshcd_wb_presrv_usrspc_keep_vcc_on(struct 
ufs_hba *hba,
 cur_buf);
return false;
}
-   /* Let it continue to flush when >60% full */
-   if (avail_buf < UFS_WB_40_PERCENT_BUF_REMAIN)
+   /* Let it continue to flush when available buffer exceeds threshold */
+   if (avail_buf < hba->vps->wb_flush_threshold)
return true;
  
  	return false;

@@ -6839,6 +6839,7 @@ static void ufshcd_wb_probe(struct ufs_hba *hba, u8 
*desc_buf)
if (!d_lu_wb_buf_alloc)
goto wb_disabled;
}
+

Is this newline needed?


return;
  
  wb_disabled:

@@ -7462,6 +7463,7 @@ static const struct attribute_group 
*ufshcd_driver_groups[] = {
  
  static struct ufs_hba_variant_params ufs_hba_vps = {

.hba_enable_delay_us= 1000,
+   .wb_flush_threshold = UFS_WB_40_PERCENT_BUF_REMAIN,
.devfreq_profile.polling_ms = 100,
.devfreq_profile.target = ufshcd_devfreq_target,
.devfreq_profile.get_dev_status = ufshcd_devfreq_get_dev_status,
diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
index f7bdf52ba8b0..e3dfb48e669e 100644
--- a/drivers/scsi/ufs/ufshcd.h
+++ b/drivers/scsi/ufs/ufshcd.h
@@ -570,6 +570,7 @@ struct ufs_hba_variant_params {
struct devfreq_dev_profile devfreq_profile;
struct devfreq_simple_ondemand_data ondemand_data;
u16 hba_enable_delay_us;
+   u32 wb_flush_threshold;
  };
  
  /**




Patch[3] & [4] may be combined into a single patch perhaps?
Patch[4] just redoes what [3] did in a different way, so might as well 
just do what patch[4] does right away.



--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
Linux Foundation Collaborative Project

Re: [PATCH v8 8/8] scsi: ufs: cleanup WriteBooster feature

[Asutosh Das (asd)]

On 5/8/2020 1:01 AM, Stanley Chu wrote:

Small cleanup as below items,

1. Use ufshcd_is_wb_allowed() directly instead of ufshcd_wb_sup()
since ufshcd_wb_sup() just returns the result of
ufshcd_is_wb_allowed().

2. In ufshcd_suspend(), "else if (!ufshcd_is_runtime_pm(pm_op))
can be simplified to "else" since both have the same meaning.

This patch does not change any functionality.

Signed-off-by: Stanley Chu 
Reviewed-by: Avri Altman 
---


The whole series looks good to me.

Reviewed-by: Asutosh Das 


  drivers/scsi/ufs/ufshcd.c | 20 +++-
  1 file changed, 7 insertions(+), 13 deletions(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index b6a0d77d47ac..426073a518ef 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -253,7 +253,6 @@ static int ufshcd_scale_clks(struct ufs_hba *hba, bool 
scale_up);
  static irqreturn_t ufshcd_intr(int irq, void *__hba);
  static int ufshcd_change_power_mode(struct ufs_hba *hba,
 struct ufs_pa_layer_attr *pwr_mode);
-static bool ufshcd_wb_sup(struct ufs_hba *hba);
  static int ufshcd_wb_buf_flush_enable(struct ufs_hba *hba);
  static int ufshcd_wb_buf_flush_disable(struct ufs_hba *hba);
  static int ufshcd_wb_ctrl(struct ufs_hba *hba, bool enable);
@@ -285,7 +284,7 @@ static inline void ufshcd_wb_config(struct ufs_hba *hba)
  {
int ret;
  
-	if (!ufshcd_wb_sup(hba))

+   if (!ufshcd_is_wb_allowed(hba))
return;
  
  	ret = ufshcd_wb_ctrl(hba, true);

@@ -5197,18 +5196,13 @@ static void ufshcd_bkops_exception_event_handler(struct 
ufs_hba *hba)
__func__, err);
  }
  
-static bool ufshcd_wb_sup(struct ufs_hba *hba)

-{
-   return ufshcd_is_wb_allowed(hba);
-}
-
  static int ufshcd_wb_ctrl(struct ufs_hba *hba, bool enable)
  {
int ret;
u8 index;
enum query_opcode opcode;
  
-	if (!ufshcd_wb_sup(hba))

+   if (!ufshcd_is_wb_allowed(hba))
return 0;
  
  	if (!(enable ^ hba->wb_enabled))

@@ -5264,7 +5258,7 @@ static int ufshcd_wb_buf_flush_enable(struct ufs_hba *hba)
int ret;
u8 index;
  
-	if (!ufshcd_wb_sup(hba) || hba->wb_buf_flush_enabled)

+   if (!ufshcd_is_wb_allowed(hba) || hba->wb_buf_flush_enabled)
return 0;
  
  	index = ufshcd_wb_get_flag_index(hba);

@@ -5286,7 +5280,7 @@ static int ufshcd_wb_buf_flush_disable(struct ufs_hba 
*hba)
int ret;
u8 index;
  
-	if (!ufshcd_wb_sup(hba) || !hba->wb_buf_flush_enabled)

+   if (!ufshcd_is_wb_allowed(hba) || !hba->wb_buf_flush_enabled)
return 0;
  
  	index = ufshcd_wb_get_flag_index(hba);

@@ -5336,7 +5330,7 @@ static bool ufshcd_wb_keep_vcc_on(struct ufs_hba *hba)
int ret;
u32 avail_buf;
  
-	if (!ufshcd_wb_sup(hba))

+   if (!ufshcd_is_wb_allowed(hba))
return false;
/*
 * The ufs device needs the vcc to be ON to flush.
@@ -8235,12 +8229,12 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum 
ufs_pm_op pm_op)
 * configured WB type is 70% full, keep vcc ON
 * for the device to flush the wb buffer
 */
-   if ((hba->auto_bkops_enabled && ufshcd_wb_sup(hba)) ||
+   if ((hba->auto_bkops_enabled && ufshcd_is_wb_allowed(hba)) ||
ufshcd_wb_keep_vcc_on(hba))
hba->dev_info.keep_vcc_on = true;
else
hba->dev_info.keep_vcc_on = false;
-   } else if (!ufshcd_is_runtime_pm(pm_op)) {
+   } else {
hba->dev_info.keep_vcc_on = false;
}
  




--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
Linux Foundation Collaborative Project

debian-www@lists.debian.org

[asd asd]

1. Agencja Reklamowa Logoworld, Konin, Poland
2. Commercial
3. https://logoworld.pl
4. We are running Debian on one of our workstation. We decided to work on
Debian because we find it very usefull and handy.

Re: [PATCH 1/2] mmc: cqhci: replace NUM_SLOTS with cq_host->num_slots

[Asutosh Das (asd)]

On 2/8/2019 8:07 AM, Ritesh Harjani wrote:

Hi Alamy,

On 2/8/2019 1:00 AM, Alamy Liu wrote:

It says in B.2.1 in the JESD84-B51.pdf (I don't have JESD84-B51A.pdf):

/The TDL is located in a memory location known to the CQE, and is
comprised of up to 32 fixed-size slots. Each slot is comprised of
one Task Descriptor and one Transfer Descriptor./


So if the IP has 16 slots, it should still meet the specification. 
Then the configuration could be moved to DTS, maybe:


cqhci-slotnum = <16>;

cqhci-dcmd-slotno = <15>;


Does your IP defines this as 16 slots & DCMD slot to be 15?
Because if there is a deviation then IP may also define num_slots by 
using some reserved registers.
Also in JESD84-B51.pdf, specific slot no. is used extensively for 
defining policies(like in case of DCMD & CQCFG), so in that case 
defining via DT may not be that helpful.
Unless there is no other way in your IP to determine the num_slots 
except going via DT?


Let others also provide an opinion here.

Regards
Ritesh




Please comment.

Regards,
Alamy



On Thu, Jan 31, 2019 at 1:34 AM Adrian Hunter > wrote:


On 14/01/19 9:17 PM, Alamy Liu wrote:
> Prevent to use fixed value (NUM_SLOTS) after it had been determined
> and saved in a variable (cq_host->num_slots).

num_slots is always 32 (i.e. NUM_SLOTS) so why not go the other
way and get
rid of num_slots and just use NUM_SLOTS?

>
> Signed-off-by: Alamy Liu mailto:alamy@gmail.com>>
> ---
>  drivers/mmc/host/cqhci.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/host/cqhci.c b/drivers/mmc/host/cqhci.c
> index 159270e947..26d63594b7 100644
> --- a/drivers/mmc/host/cqhci.c
> +++ b/drivers/mmc/host/cqhci.c
> @@ -699,7 +699,7 @@ static void cqhci_error_irq(struct mmc_host
*mmc, u32 status, int cmd_error,
>                * The only way to guarantee forward progress is
to mark at
>                * least one task in error, so if none is
indicated, pick one.
>                */
> -             for (tag = 0; tag < NUM_SLOTS; tag++) {
> +             for (tag = 0; tag < cq_host->num_slots; tag++) {
>                       slot = _host->slot[tag];
>                       if (!slot->mrq)
>                               continue;
>

Is it worth exploring to tie up the TDL memory allocations with the 
queue-depth? Because the queue-depth may vary with vendor; in most host 
controllers the slot size is 32. And since memory allocations are done 
on the basis of host slot size there's unused slots in the case of card 
advertising less than 32 queue-depth.

The tricky part would be the DCMD handling though.

In the IP in question, what slot is assigned to DCMD?


--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
Linux Foundation Collaborative Project

Re: [ 1/1] scsi: qcom-ufs: Add support for bus voting using ICB framework

[Asutosh Das (asd)]

On 1/24/2019 10:22 PM, Evan Green wrote:

On Wed, Jan 23, 2019 at 11:02 PM Asutosh Das  wrote:


Adapt to the new ICB framework for bus bandwidth voting.

This requires the source/destination port ids.
Also this requires a tuple of values.

The tuple is for two different paths - from UFS master
to BIMC slave. The other is from CPU master to UFS slave.
This tuple consists of the average and peak bandwidth.

Signed-off-by: Asutosh Das 
---
  .../devicetree/bindings/ufs/ufshcd-pltfrm.txt  |  12 ++
  drivers/scsi/ufs/ufs-qcom.c| 234 -
  drivers/scsi/ufs/ufs-qcom.h|  20 ++
  3 files changed, 218 insertions(+), 48 deletions(-)

diff --git a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt 
b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
index a99ed55..94249ef 100644
--- a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
+++ b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
@@ -45,6 +45,18 @@ Optional properties:
  Note: If above properties are not defined it can be assumed that the supply
  regulators or clocks are always on.

+* Following bus parameters are required:
+interconnects
+interconnect-names
+- Please refer to Documentation/devicetree/bindings/interconnect/
+  for more details on the above.
+qcom,msm-bus,name - string describing the bus path
+qcom,msm-bus,num-cases - number of configurations in which ufs can operate in
+qcom,msm-bus,num-paths - number of paths to vote for
+qcom,msm-bus,vectors-KBps - Takes a tuple ,  (2 tuples for 2 
num-paths)
+   The number of these entries *must* be same as
+   num-cases.


I think we can do away with all of the qcom* ones, right? This should
be achievable with just interconnects and interconnect-names.

Let me give that a bit more thought - though I'm not sure how that'd work.



Also, is this patch based on a downstream tree? I don't recognize a
lot of the context. We'll need a patch that's based on an upstream
tree.

This was developed on the internal Chrome AU and ported to ufs-next.
Let me check internally on this anyway.



I'll wait to review the rest of the patch until rev 2, since it's hard
to reason about the patch with all the downstream stuff in there.
-Evan



Hi Evan - thanks for the comments.

-asd

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
Linux Foundation Collaborative Project

Re: [ 1/1] scsi: qcom-ufs: Add support for bus voting using ICB framework

[Asutosh Das (asd)]

   mem_err = true;
+   dev_err(dev, "Error: Failed to alloc mem for 
vectors\n");
+   goto err;
+   }
+
+   for (j = 0; j < num_paths; j++) {
+   int idx = ((i * num_paths) + j) * 2;
+
+   usecase[i].vec[j].ab = (uint64_t)
+   be32_to_cpu(vec_arr[idx]);
+   usecase[i].vec[j].ib = (uint64_t)
+   be32_to_cpu(vec_arr[idx + 1]);
+   }
+   }
+
+   qsd->usecase = usecase;
+   return qsd;
+err:
+   if (mem_err) {
+   for (; i > 0; i--)
+   kfree(usecase[i].vec);
+       }
+   return NULL;
+}


We wouldn't need all the above DT parsing if we add a sdm845 bandwidth
usecase table. Could you give it a try?
Replied above - Please let me know if you've any suggestions on how else 
to handle this, as it can change with targets.




Thanks,
Georgi



Hi Georgi - thanks for the comments.
Replied to your comments inline.

-asd

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
Linux Foundation Collaborative Project

[Qemu-devel] [Bug 1703506] Re: SMT not supported by QEMU on AMD Ryzen CPU

[asd fghjkl]

I got it to work:
sudo nano /etc/modprobe.d/kvm.conf
add "options kvm ignore_msrs=1" (without quotes)
reboot

Then changing "-machine q35" to "-machine pc" kept it from crashing
randomly.

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1703506

Title:
  SMT not supported by QEMU on AMD Ryzen CPU

Status in QEMU:
  New

Bug description:
  HyperThreading/SMT is supported by AMD Ryzen CPUs but results in this
  message when setting the topology to threads=2:

  qemu-system-x86_64: AMD CPU doesn't support hyperthreading. Please
  configure -smp options properly.

  Checking in a Windows 10 guest reveals that SMT is not enabled, and
  from what I understand, QEMU converts the topology from threads to
  cores internally on AMD CPUs. This appears to cause performance
  problems in the guest perhaps because programs are assuming that these
  threads are actual cores.

  Software: Linux 4.12, qemu 2.9.0 host with KVM enabled, Windows 10 pro
  guest

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1703506/+subscriptions

[Qemu-devel] [Bug 1703506] Re: SMT not supported by QEMU on AMD Ryzen CPU

[asd fghjkl]

Error I see in terminal:
AMD CPU doesn't support hyperthreading. Please configure -smp options properly.

Error I see in my windows 10 vm:
SYSTEM THREAD EXCEPTION NOT HANDLED

I am unable to use Qemu at all. Serious problem.

CPU: AMD Ryzen 5 1600X Six-Core Processor × 6

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1703506

Title:
  SMT not supported by QEMU on AMD Ryzen CPU

Status in QEMU:
  New

Bug description:
  HyperThreading/SMT is supported by AMD Ryzen CPUs but results in this
  message when setting the topology to threads=2:

  qemu-system-x86_64: AMD CPU doesn't support hyperthreading. Please
  configure -smp options properly.

  Checking in a Windows 10 guest reveals that SMT is not enabled, and
  from what I understand, QEMU converts the topology from threads to
  cores internally on AMD CPUs. This appears to cause performance
  problems in the guest perhaps because programs are assuming that these
  threads are actual cores.

  Software: Linux 4.12, qemu 2.9.0 host with KVM enabled, Windows 10 pro
  guest

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1703506/+subscriptions

Re: [PATCH 1/4] scsi: ufs: add quirk to fix mishandling utrlclr/utmrlclr

[Asutosh Das (asd)]

On 5/6/2018 3:44 PM, Alim Akhtar wrote:

In the right behavior, setting the bit to '0' indicates clear and
'1' indicates no change. If host controller handles this the other way,
UFSHCI_QUIRK_BROKEN_REQ_LIST_CLR can be used.

Signed-off-by: Seungwon Jeon 
Signed-off-by: Alim Akhtar 
---
  drivers/scsi/ufs/ufshcd.c | 21 +++--
  drivers/scsi/ufs/ufshcd.h |  5 +
  2 files changed, 24 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 00e7905..9898ce5 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -675,7 +675,24 @@ static inline void ufshcd_put_tm_slot(struct ufs_hba *hba, 
int slot)
   */
  static inline void ufshcd_utrl_clear(struct ufs_hba *hba, u32 pos)
  {
-   ufshcd_writel(hba, ~(1 << pos), REG_UTP_TRANSFER_REQ_LIST_CLEAR);
+   if (hba->quirks & UFSHCI_QUIRK_BROKEN_REQ_LIST_CLR)
+   ufshcd_writel(hba, (1 << pos), REG_UTP_TRANSFER_REQ_LIST_CLEAR);
+   else
+   ufshcd_writel(hba, ~(1 << pos),
+   REG_UTP_TRANSFER_REQ_LIST_CLEAR);
+}
+
+/**
+ * ufshcd_utmrl_clear - Clear a bit in UTRMLCLR register
+ * @hba: per adapter instance
+ * @pos: position of the bit to be cleared
+ */
+static inline void ufshcd_utmrl_clear(struct ufs_hba *hba, u32 pos)
+{
+   if (hba->quirks & UFSHCI_QUIRK_BROKEN_REQ_LIST_CLR)
+   ufshcd_writel(hba, (1 << pos), REG_UTP_TASK_REQ_LIST_CLEAR);
+   else
+   ufshcd_writel(hba, ~(1 << pos), REG_UTP_TASK_REQ_LIST_CLEAR);
  }
  
  /**

@@ -5398,7 +5415,7 @@ static int ufshcd_clear_tm_cmd(struct ufs_hba *hba, int 
tag)
goto out;
  
  	spin_lock_irqsave(hba->host->host_lock, flags);

-   ufshcd_writel(hba, ~(1 << tag), REG_UTP_TASK_REQ_LIST_CLEAR);
+   ufshcd_utmrl_clear(hba, tag);
spin_unlock_irqrestore(hba->host->host_lock, flags);
  
  	/* poll for max. 1 sec to clear door bell register by h/w */

diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
index 8110dcd..43035f8 100644
--- a/drivers/scsi/ufs/ufshcd.h
+++ b/drivers/scsi/ufs/ufshcd.h
@@ -595,6 +595,11 @@ struct ufs_hba {
 */
#define UFSHCD_QUIRK_PRDT_BYTE_GRAN 0x80
  
+	/*

+* Cleaer handling for transfer/task request list is just opposite.
+*/

Spell check - should be 'Clear'

+   #define UFSHCI_QUIRK_BROKEN_REQ_LIST_CLR0x100
+
unsigned int quirks;/* Deviations from standard UFSHCI spec. */
  
  	/* Device deviations from standard UFS device spec. */




Looks good to me, except the spell-check.

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
Linux Foundation Collaborative Project

Re: [PATCH 1/4] scsi: ufs: add quirk to fix mishandling utrlclr/utmrlclr

[Asutosh Das (asd)]

On 5/6/2018 3:44 PM, Alim Akhtar wrote:

In the right behavior, setting the bit to '0' indicates clear and
'1' indicates no change. If host controller handles this the other way,
UFSHCI_QUIRK_BROKEN_REQ_LIST_CLR can be used.

Signed-off-by: Seungwon Jeon 
Signed-off-by: Alim Akhtar 
---
  drivers/scsi/ufs/ufshcd.c | 21 +++--
  drivers/scsi/ufs/ufshcd.h |  5 +
  2 files changed, 24 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 00e7905..9898ce5 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -675,7 +675,24 @@ static inline void ufshcd_put_tm_slot(struct ufs_hba *hba, 
int slot)
   */
  static inline void ufshcd_utrl_clear(struct ufs_hba *hba, u32 pos)
  {
-   ufshcd_writel(hba, ~(1 << pos), REG_UTP_TRANSFER_REQ_LIST_CLEAR);
+   if (hba->quirks & UFSHCI_QUIRK_BROKEN_REQ_LIST_CLR)
+   ufshcd_writel(hba, (1 << pos), REG_UTP_TRANSFER_REQ_LIST_CLEAR);
+   else
+   ufshcd_writel(hba, ~(1 << pos),
+   REG_UTP_TRANSFER_REQ_LIST_CLEAR);
+}
+
+/**
+ * ufshcd_utmrl_clear - Clear a bit in UTRMLCLR register
+ * @hba: per adapter instance
+ * @pos: position of the bit to be cleared
+ */
+static inline void ufshcd_utmrl_clear(struct ufs_hba *hba, u32 pos)
+{
+   if (hba->quirks & UFSHCI_QUIRK_BROKEN_REQ_LIST_CLR)
+   ufshcd_writel(hba, (1 << pos), REG_UTP_TASK_REQ_LIST_CLEAR);
+   else
+   ufshcd_writel(hba, ~(1 << pos), REG_UTP_TASK_REQ_LIST_CLEAR);
  }
  
  /**

@@ -5398,7 +5415,7 @@ static int ufshcd_clear_tm_cmd(struct ufs_hba *hba, int 
tag)
goto out;
  
  	spin_lock_irqsave(hba->host->host_lock, flags);

-   ufshcd_writel(hba, ~(1 << tag), REG_UTP_TASK_REQ_LIST_CLEAR);
+   ufshcd_utmrl_clear(hba, tag);
spin_unlock_irqrestore(hba->host->host_lock, flags);
  
  	/* poll for max. 1 sec to clear door bell register by h/w */

diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
index 8110dcd..43035f8 100644
--- a/drivers/scsi/ufs/ufshcd.h
+++ b/drivers/scsi/ufs/ufshcd.h
@@ -595,6 +595,11 @@ struct ufs_hba {
 */
#define UFSHCD_QUIRK_PRDT_BYTE_GRAN 0x80
  
+	/*

+* Cleaer handling for transfer/task request list is just opposite.
+*/

Spell check - should be 'Clear'

+   #define UFSHCI_QUIRK_BROKEN_REQ_LIST_CLR0x100
+
unsigned int quirks;/* Deviations from standard UFSHCI spec. */
  
  	/* Device deviations from standard UFS device spec. */




Looks good to me, except the spell-check.

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
Linux Foundation Collaborative Project

Re: [PATCH 1/4] scsi: ufs: add quirk to fix mishandling utrlclr/utmrlclr

[Asutosh Das (asd)]

On 5/6/2018 3:44 PM, Alim Akhtar wrote:

In the right behavior, setting the bit to '0' indicates clear and
'1' indicates no change. If host controller handles this the other way,
UFSHCI_QUIRK_BROKEN_REQ_LIST_CLR can be used.

Signed-off-by: Seungwon Jeon 
Signed-off-by: Alim Akhtar 
---
  drivers/scsi/ufs/ufshcd.c | 21 +++--
  drivers/scsi/ufs/ufshcd.h |  5 +
  2 files changed, 24 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 00e7905..9898ce5 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -675,7 +675,24 @@ static inline void ufshcd_put_tm_slot(struct ufs_hba *hba, 
int slot)
   */
  static inline void ufshcd_utrl_clear(struct ufs_hba *hba, u32 pos)
  {
-   ufshcd_writel(hba, ~(1 << pos), REG_UTP_TRANSFER_REQ_LIST_CLEAR);
+   if (hba->quirks & UFSHCI_QUIRK_BROKEN_REQ_LIST_CLR)
+   ufshcd_writel(hba, (1 << pos), REG_UTP_TRANSFER_REQ_LIST_CLEAR);
+   else
+   ufshcd_writel(hba, ~(1 << pos),
+   REG_UTP_TRANSFER_REQ_LIST_CLEAR);
+}
+
+/**
+ * ufshcd_utmrl_clear - Clear a bit in UTRMLCLR register
+ * @hba: per adapter instance
+ * @pos: position of the bit to be cleared
+ */
+static inline void ufshcd_utmrl_clear(struct ufs_hba *hba, u32 pos)
+{
+   if (hba->quirks & UFSHCI_QUIRK_BROKEN_REQ_LIST_CLR)
+   ufshcd_writel(hba, (1 << pos), REG_UTP_TASK_REQ_LIST_CLEAR);
+   else
+   ufshcd_writel(hba, ~(1 << pos), REG_UTP_TASK_REQ_LIST_CLEAR);
  }
  
  /**

@@ -5398,7 +5415,7 @@ static int ufshcd_clear_tm_cmd(struct ufs_hba *hba, int 
tag)
goto out;
  
  	spin_lock_irqsave(hba->host->host_lock, flags);

-   ufshcd_writel(hba, ~(1 << tag), REG_UTP_TASK_REQ_LIST_CLEAR);
+   ufshcd_utmrl_clear(hba, tag);
spin_unlock_irqrestore(hba->host->host_lock, flags);
  
  	/* poll for max. 1 sec to clear door bell register by h/w */

diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
index 8110dcd..43035f8 100644
--- a/drivers/scsi/ufs/ufshcd.h
+++ b/drivers/scsi/ufs/ufshcd.h
@@ -595,6 +595,11 @@ struct ufs_hba {
 */
#define UFSHCD_QUIRK_PRDT_BYTE_GRAN 0x80
  
+	/*

+* Cleaer handling for transfer/task request list is just opposite.
+*/

Spell check - should be 'Clear'

+   #define UFSHCI_QUIRK_BROKEN_REQ_LIST_CLR0x100
+
unsigned int quirks;/* Deviations from standard UFSHCI spec. */
  
  	/* Device deviations from standard UFS device spec. */




Looks good to me, except the spell-check.

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
Linux Foundation Collaborative Project

[jira] [Created] (WEEX-246) weex 文档中部分链接地址not found

[asd-kk (JIRA)]

asd-kk created WEEX-246:
---

 Summary: weex 文档中部分链接地址not found
 Key: WEEX-246
 URL: https://issues.apache.org/jira/browse/WEEX-246
 Project: Weex
  Issue Type: Bug
Reporter: asd-kk
Assignee: Adam Feng






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [PATCH 9/9] scsi: ufs: Add clock ungating to a separate workqueue

[Asutosh Das (asd)]

On 2/24/2018 5:27 AM, Miguel Ojeda wrote:

On Wed, Feb 21, 2018 at 5:56 AM, Asutosh Das <asuto...@codeaurora.org> wrote:

From: Vijay Viswanath <vvisw...@codeaurora.org>

UFS driver can receive a request during memory reclaim by kswapd.
So when ufs driver puts the ungate work in queue, and if there are no
idle workers, kthreadd is invoked to create a new kworker. Since
kswapd task holds a mutex which kthreadd also needs, this can cause
a deadlock situation. So ungate work must be done in a separate
work queue with WQ__RECLAIM flag enabled.Such a workqueue will have


WQ_MEM_RECLAIM here. Also space after dot.


a rescue thread which will be called when the above deadlock
condition is possible.

Signed-off-by: Vijay Viswanath <vvisw...@codeaurora.org>
Signed-off-by: Can Guo <c...@codeaurora.org>
Signed-off-by: Asutosh Das <asuto...@codeaurora.org>
---
  drivers/scsi/ufs/ufshcd.c | 10 +-
  drivers/scsi/ufs/ufshcd.h |  1 +
  2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 6541e1d..bb3382a 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -1503,7 +1503,8 @@ int ufshcd_hold(struct ufs_hba *hba, bool async)
 hba->clk_gating.state = REQ_CLKS_ON;
 trace_ufshcd_clk_gating(dev_name(hba->dev),
 hba->clk_gating.state);
-   schedule_work(>clk_gating.ungate_work);
+   queue_work(hba->clk_gating.clk_gating_workq,
+  >clk_gating.ungate_work);
 /*
  * fall through to check if we should wait for this
  * work to be done or not.
@@ -1689,6 +1690,8 @@ static ssize_t ufshcd_clkgate_enable_store(struct device 
*dev,

  static void ufshcd_init_clk_gating(struct ufs_hba *hba)
  {
+   char wq_name[sizeof("ufs_clk_gating_00")];
+
 if (!ufshcd_is_clkgating_allowed(hba))
 return;

@@ -1696,6 +1699,10 @@ static void ufshcd_init_clk_gating(struct ufs_hba *hba)
 INIT_DELAYED_WORK(>clk_gating.gate_work, ufshcd_gate_work);
 INIT_WORK(>clk_gating.ungate_work, ufshcd_ungate_work);

+   snprintf(wq_name, ARRAY_SIZE(wq_name), "ufs_clk_gating_%d",
+hba->host->host_no);
+   hba->clk_gating.clk_gating_workq = 
create_singlethread_workqueue(wq_name);


Shouldn't this be alloc_ordered_workqueue() with WQ_MEM_RECLAIM then?
(create_singlethread_workqueue() and friends are deprecated).

Cheers,
Miguel


+
 hba->clk_gating.is_enabled = true;

 hba->clk_gating.delay_attr.show = ufshcd_clkgate_delay_show;
@@ -1723,6 +1730,7 @@ static void ufshcd_exit_clk_gating(struct ufs_hba *hba)
 device_remove_file(hba->dev, >clk_gating.enable_attr);
 cancel_work_sync(>clk_gating.ungate_work);
 cancel_delayed_work_sync(>clk_gating.gate_work);
+   destroy_workqueue(hba->clk_gating.clk_gating_workq);
  }

  /* Must be called with host lock acquired */
diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
index 4385741..570c33e 100644
--- a/drivers/scsi/ufs/ufshcd.h
+++ b/drivers/scsi/ufs/ufshcd.h
@@ -361,6 +361,7 @@ struct ufs_clk_gating {
 struct device_attribute enable_attr;
 bool is_enabled;
 int active_reqs;
+   struct workqueue_struct *clk_gating_workq;
  };

  struct ufs_saved_pwr_info {
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project.



Hi Miguel
Thanks for the review.

I'll check this and put up the changes in v2.


-asd

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
Linux Foundation Collaborative Project

Re: [PATCH 9/9] scsi: ufs: Add clock ungating to a separate workqueue

[Asutosh Das (asd)]

On 2/24/2018 5:27 AM, Miguel Ojeda wrote:

On Wed, Feb 21, 2018 at 5:56 AM, Asutosh Das  wrote:

From: Vijay Viswanath 

UFS driver can receive a request during memory reclaim by kswapd.
So when ufs driver puts the ungate work in queue, and if there are no
idle workers, kthreadd is invoked to create a new kworker. Since
kswapd task holds a mutex which kthreadd also needs, this can cause
a deadlock situation. So ungate work must be done in a separate
work queue with WQ__RECLAIM flag enabled.Such a workqueue will have


WQ_MEM_RECLAIM here. Also space after dot.


a rescue thread which will be called when the above deadlock
condition is possible.

Signed-off-by: Vijay Viswanath 
Signed-off-by: Can Guo 
Signed-off-by: Asutosh Das 
---
  drivers/scsi/ufs/ufshcd.c | 10 +-
  drivers/scsi/ufs/ufshcd.h |  1 +
  2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 6541e1d..bb3382a 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -1503,7 +1503,8 @@ int ufshcd_hold(struct ufs_hba *hba, bool async)
 hba->clk_gating.state = REQ_CLKS_ON;
 trace_ufshcd_clk_gating(dev_name(hba->dev),
 hba->clk_gating.state);
-   schedule_work(>clk_gating.ungate_work);
+   queue_work(hba->clk_gating.clk_gating_workq,
+  >clk_gating.ungate_work);
 /*
  * fall through to check if we should wait for this
  * work to be done or not.
@@ -1689,6 +1690,8 @@ static ssize_t ufshcd_clkgate_enable_store(struct device 
*dev,

  static void ufshcd_init_clk_gating(struct ufs_hba *hba)
  {
+   char wq_name[sizeof("ufs_clk_gating_00")];
+
 if (!ufshcd_is_clkgating_allowed(hba))
 return;

@@ -1696,6 +1699,10 @@ static void ufshcd_init_clk_gating(struct ufs_hba *hba)
 INIT_DELAYED_WORK(>clk_gating.gate_work, ufshcd_gate_work);
 INIT_WORK(>clk_gating.ungate_work, ufshcd_ungate_work);

+   snprintf(wq_name, ARRAY_SIZE(wq_name), "ufs_clk_gating_%d",
+hba->host->host_no);
+   hba->clk_gating.clk_gating_workq = 
create_singlethread_workqueue(wq_name);


Shouldn't this be alloc_ordered_workqueue() with WQ_MEM_RECLAIM then?
(create_singlethread_workqueue() and friends are deprecated).

Cheers,
Miguel


+
 hba->clk_gating.is_enabled = true;

 hba->clk_gating.delay_attr.show = ufshcd_clkgate_delay_show;
@@ -1723,6 +1730,7 @@ static void ufshcd_exit_clk_gating(struct ufs_hba *hba)
 device_remove_file(hba->dev, >clk_gating.enable_attr);
 cancel_work_sync(>clk_gating.ungate_work);
 cancel_delayed_work_sync(>clk_gating.gate_work);
+   destroy_workqueue(hba->clk_gating.clk_gating_workq);
  }

  /* Must be called with host lock acquired */
diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
index 4385741..570c33e 100644
--- a/drivers/scsi/ufs/ufshcd.h
+++ b/drivers/scsi/ufs/ufshcd.h
@@ -361,6 +361,7 @@ struct ufs_clk_gating {
 struct device_attribute enable_attr;
 bool is_enabled;
 int active_reqs;
+   struct workqueue_struct *clk_gating_workq;
  };

  struct ufs_saved_pwr_info {
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project.



Hi Miguel
Thanks for the review.

I'll check this and put up the changes in v2.


-asd

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
Linux Foundation Collaborative Project

Re: [PATCH 9/9] scsi: ufs: Add clock ungating to a separate workqueue

[Asutosh Das (asd)]

On 2/24/2018 5:27 AM, Miguel Ojeda wrote:

On Wed, Feb 21, 2018 at 5:56 AM, Asutosh Das <asuto...@codeaurora.org> wrote:

From: Vijay Viswanath <vvisw...@codeaurora.org>

UFS driver can receive a request during memory reclaim by kswapd.
So when ufs driver puts the ungate work in queue, and if there are no
idle workers, kthreadd is invoked to create a new kworker. Since
kswapd task holds a mutex which kthreadd also needs, this can cause
a deadlock situation. So ungate work must be done in a separate
work queue with WQ__RECLAIM flag enabled.Such a workqueue will have


WQ_MEM_RECLAIM here. Also space after dot.


a rescue thread which will be called when the above deadlock
condition is possible.

Signed-off-by: Vijay Viswanath <vvisw...@codeaurora.org>
Signed-off-by: Can Guo <c...@codeaurora.org>
Signed-off-by: Asutosh Das <asuto...@codeaurora.org>
---
  drivers/scsi/ufs/ufshcd.c | 10 +-
  drivers/scsi/ufs/ufshcd.h |  1 +
  2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 6541e1d..bb3382a 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -1503,7 +1503,8 @@ int ufshcd_hold(struct ufs_hba *hba, bool async)
 hba->clk_gating.state = REQ_CLKS_ON;
 trace_ufshcd_clk_gating(dev_name(hba->dev),
 hba->clk_gating.state);
-   schedule_work(>clk_gating.ungate_work);
+   queue_work(hba->clk_gating.clk_gating_workq,
+  >clk_gating.ungate_work);
 /*
  * fall through to check if we should wait for this
  * work to be done or not.
@@ -1689,6 +1690,8 @@ static ssize_t ufshcd_clkgate_enable_store(struct device 
*dev,

  static void ufshcd_init_clk_gating(struct ufs_hba *hba)
  {
+   char wq_name[sizeof("ufs_clk_gating_00")];
+
 if (!ufshcd_is_clkgating_allowed(hba))
 return;

@@ -1696,6 +1699,10 @@ static void ufshcd_init_clk_gating(struct ufs_hba *hba)
 INIT_DELAYED_WORK(>clk_gating.gate_work, ufshcd_gate_work);
 INIT_WORK(>clk_gating.ungate_work, ufshcd_ungate_work);

+   snprintf(wq_name, ARRAY_SIZE(wq_name), "ufs_clk_gating_%d",
+hba->host->host_no);
+   hba->clk_gating.clk_gating_workq = 
create_singlethread_workqueue(wq_name);


Shouldn't this be alloc_ordered_workqueue() with WQ_MEM_RECLAIM then?
(create_singlethread_workqueue() and friends are deprecated).

Cheers,
Miguel


+
 hba->clk_gating.is_enabled = true;

 hba->clk_gating.delay_attr.show = ufshcd_clkgate_delay_show;
@@ -1723,6 +1730,7 @@ static void ufshcd_exit_clk_gating(struct ufs_hba *hba)
 device_remove_file(hba->dev, >clk_gating.enable_attr);
 cancel_work_sync(>clk_gating.ungate_work);
 cancel_delayed_work_sync(>clk_gating.gate_work);
+   destroy_workqueue(hba->clk_gating.clk_gating_workq);
  }

  /* Must be called with host lock acquired */
diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
index 4385741..570c33e 100644
--- a/drivers/scsi/ufs/ufshcd.h
+++ b/drivers/scsi/ufs/ufshcd.h
@@ -361,6 +361,7 @@ struct ufs_clk_gating {
 struct device_attribute enable_attr;
 bool is_enabled;
 int active_reqs;
+   struct workqueue_struct *clk_gating_workq;
  };

  struct ufs_saved_pwr_info {
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project.



Hi Miguel
Thanks for the review.

I'll check this and put up the changes in v2.


-asd

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
Linux Foundation Collaborative Project

Re: [PATCH 1/9] scsi: ufs: Allowing power mode change

[Asutosh Das (asd)]

On 2/23/2018 10:40 AM, Kyuho Choi wrote:

Hi Asutosh,

I've simple question in below.

On 2/21/18, Asutosh Das <asuto...@codeaurora.org> wrote:

From: Yaniv Gardi <yga...@codeaurora.org>

Due to M-PHY issues, moving from HS to any other mode or gear or
even Hibern8 causes some un-predicted behavior of the device.
This patch fixes this issues.

Signed-off-by: Yaniv Gardi <yga...@codeaurora.org>
Signed-off-by: Subhash Jadavani <subha...@codeaurora.org>
Signed-off-by: Can Guo <c...@codeaurora.org>
Signed-off-by: Asutosh Das <asuto...@codeaurora.org>
---
  drivers/scsi/ufs/ufshcd.c | 6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 011c336..d74d529 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -4167,9 +4167,13 @@ static int ufshcd_link_startup(struct ufs_hba *hba)
goto out;
} while (ret && retries--);

-   if (ret)
+   if (ret) {
/* failed to get the link up... retire */
goto out;
+   } else {
+   ufshcd_dme_set(hba, UIC_ARG_MIB(TX_LCC_ENABLE), 0);
+   ufshcd_dme_set(hba, UIC_ARG_MIB(TX_LCC_ENABLE), 1);
+   }



Every ufs host has same issue and affected?.


if (link_startup_again) {
link_startup_again = false;
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center,
Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project.



Hi Choi
Thanks for the review.

No - I can't say if every host has the same issue. However, I get your 
point. It could be done with a quirk.


I'll fix this in v2 after collating all the comments from the rest of 
the patches.


-asd

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
Linux Foundation Collaborative Project

Re: [PATCH 1/9] scsi: ufs: Allowing power mode change

[Asutosh Das (asd)]

On 2/23/2018 10:40 AM, Kyuho Choi wrote:

Hi Asutosh,

I've simple question in below.

On 2/21/18, Asutosh Das  wrote:

From: Yaniv Gardi 

Due to M-PHY issues, moving from HS to any other mode or gear or
even Hibern8 causes some un-predicted behavior of the device.
This patch fixes this issues.

Signed-off-by: Yaniv Gardi 
Signed-off-by: Subhash Jadavani 
Signed-off-by: Can Guo 
Signed-off-by: Asutosh Das 
---
  drivers/scsi/ufs/ufshcd.c | 6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 011c336..d74d529 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -4167,9 +4167,13 @@ static int ufshcd_link_startup(struct ufs_hba *hba)
goto out;
} while (ret && retries--);

-   if (ret)
+   if (ret) {
/* failed to get the link up... retire */
goto out;
+   } else {
+   ufshcd_dme_set(hba, UIC_ARG_MIB(TX_LCC_ENABLE), 0);
+   ufshcd_dme_set(hba, UIC_ARG_MIB(TX_LCC_ENABLE), 1);
+   }



Every ufs host has same issue and affected?.


if (link_startup_again) {
link_startup_again = false;
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center,
Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project.



Hi Choi
Thanks for the review.

No - I can't say if every host has the same issue. However, I get your 
point. It could be done with a quirk.


I'll fix this in v2 after collating all the comments from the rest of 
the patches.


-asd

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
Linux Foundation Collaborative Project

Re: [PATCH 1/9] scsi: ufs: Allowing power mode change

[Asutosh Das (asd)]

On 2/23/2018 10:40 AM, Kyuho Choi wrote:

Hi Asutosh,

I've simple question in below.

On 2/21/18, Asutosh Das <asuto...@codeaurora.org> wrote:

From: Yaniv Gardi <yga...@codeaurora.org>

Due to M-PHY issues, moving from HS to any other mode or gear or
even Hibern8 causes some un-predicted behavior of the device.
This patch fixes this issues.

Signed-off-by: Yaniv Gardi <yga...@codeaurora.org>
Signed-off-by: Subhash Jadavani <subha...@codeaurora.org>
Signed-off-by: Can Guo <c...@codeaurora.org>
Signed-off-by: Asutosh Das <asuto...@codeaurora.org>
---
  drivers/scsi/ufs/ufshcd.c | 6 +-
  1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 011c336..d74d529 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -4167,9 +4167,13 @@ static int ufshcd_link_startup(struct ufs_hba *hba)
goto out;
} while (ret && retries--);

-   if (ret)
+   if (ret) {
/* failed to get the link up... retire */
goto out;
+   } else {
+   ufshcd_dme_set(hba, UIC_ARG_MIB(TX_LCC_ENABLE), 0);
+   ufshcd_dme_set(hba, UIC_ARG_MIB(TX_LCC_ENABLE), 1);
+   }



Every ufs host has same issue and affected?.


if (link_startup_again) {
link_startup_again = false;
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center,
Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project.



Hi Choi
Thanks for the review.

No - I can't say if every host has the same issue. However, I get your 
point. It could be done with a quirk.


I'll fix this in v2 after collating all the comments from the rest of 
the patches.


-asd

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
Linux Foundation Collaborative Project

Re: [PATCH 5/9] scsi: ufs: add reference counting for scsi block requests

[Asutosh Das (asd)]

a);
pm_runtime_put_sync(hba->dev);
  }
@@ -5299,7 +5329,7 @@ static void ufshcd_check_errors(struct ufs_hba
*hba)
/* handle fatal errors only when link is functional */
if (hba->ufshcd_state == UFSHCD_STATE_OPERATIONAL) {
/* block commands from scsi mid-layer */
-   scsi_block_requests(hba->host);
+   __ufshcd_scsi_block_requests(hba);

hba->ufshcd_state =
UFSHCD_STATE_EH_SCHEDULED;

diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h index
7a2dad3..4385741 100644
--- a/drivers/scsi/ufs/ufshcd.h
+++ b/drivers/scsi/ufs/ufshcd.h
@@ -498,6 +498,7 @@ struct ufs_stats {
   * @urgent_bkops_lvl: keeps track of urgent bkops level for device
   * @is_urgent_bkops_lvl_checked: keeps track if the urgent bkops level for
   *  device is known or not.
+ * @scsi_block_reqs_cnt: reference counting for scsi block requests
   */
  struct ufs_hba {
void __iomem *mmio_base;
@@ -690,6 +691,7 @@ struct ufs_hba {

struct rw_semaphore clk_scaling_lock;
struct ufs_desc_size desc_size;
+   int scsi_block_reqs_cnt;
  };

  /* Returns true if clocks can be gated. Otherwise false */ @@ -862,6 +864,9
@@ int ufshcd_map_desc_id_to_length(struct ufs_hba *hba, enum
desc_idn desc_id,

  u32 ufshcd_get_local_unipro_ver(struct ufs_hba *hba);

+void ufshcd_scsi_block_requests(struct ufs_hba *hba); void
+ufshcd_scsi_unblock_requests(struct ufs_hba *hba);
+
  /* Wrapper functions for safely calling variant operations */  static inline
const char *ufshcd_get_var_name(struct ufs_hba *hba)  {
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center,
Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project.


1. The atomic variable and operations could be used for the reference counting.
  This will allow to avoid usage of the locks.
2. Why are the ufshcd_scsi_block_requests/ ufshcd_scsi_unblock_requests
 functions not defined as static? They are not used outside ufshcd.c.

Regards
Stanislav


Hi
Thanks. Let me check this and get back.
I'll wait for comments on the other patches before posting a v2.

-asd

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
Linux Foundation Collaborative Project

Re: [PATCH 5/9] scsi: ufs: add reference counting for scsi block requests

[Asutosh Das (asd)]

a);
pm_runtime_put_sync(hba->dev);
  }
@@ -5299,7 +5329,7 @@ static void ufshcd_check_errors(struct ufs_hba
*hba)
/* handle fatal errors only when link is functional */
if (hba->ufshcd_state == UFSHCD_STATE_OPERATIONAL) {
/* block commands from scsi mid-layer */
-   scsi_block_requests(hba->host);
+   __ufshcd_scsi_block_requests(hba);

hba->ufshcd_state =
UFSHCD_STATE_EH_SCHEDULED;

diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h index
7a2dad3..4385741 100644
--- a/drivers/scsi/ufs/ufshcd.h
+++ b/drivers/scsi/ufs/ufshcd.h
@@ -498,6 +498,7 @@ struct ufs_stats {
   * @urgent_bkops_lvl: keeps track of urgent bkops level for device
   * @is_urgent_bkops_lvl_checked: keeps track if the urgent bkops level for
   *  device is known or not.
+ * @scsi_block_reqs_cnt: reference counting for scsi block requests
   */
  struct ufs_hba {
void __iomem *mmio_base;
@@ -690,6 +691,7 @@ struct ufs_hba {

struct rw_semaphore clk_scaling_lock;
struct ufs_desc_size desc_size;
+   int scsi_block_reqs_cnt;
  };

  /* Returns true if clocks can be gated. Otherwise false */ @@ -862,6 +864,9
@@ int ufshcd_map_desc_id_to_length(struct ufs_hba *hba, enum
desc_idn desc_id,

  u32 ufshcd_get_local_unipro_ver(struct ufs_hba *hba);

+void ufshcd_scsi_block_requests(struct ufs_hba *hba); void
+ufshcd_scsi_unblock_requests(struct ufs_hba *hba);
+
  /* Wrapper functions for safely calling variant operations */  static inline
const char *ufshcd_get_var_name(struct ufs_hba *hba)  {
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center,
Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project.


1. The atomic variable and operations could be used for the reference counting.
  This will allow to avoid usage of the locks.
2. Why are the ufshcd_scsi_block_requests/ ufshcd_scsi_unblock_requests
 functions not defined as static? They are not used outside ufshcd.c.

Regards
Stanislav


Hi
Thanks. Let me check this and get back.
I'll wait for comments on the other patches before posting a v2.

-asd

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
Linux Foundation Collaborative Project

Re: [PATCH 5/9] scsi: ufs: add reference counting for scsi block requests

[Asutosh Das (asd)]

link is functional */
if (hba->ufshcd_state == UFSHCD_STATE_OPERATIONAL) {
/* block commands from scsi mid-layer */
-   scsi_block_requests(hba->host);
+   __ufshcd_scsi_block_requests(hba);

hba->ufshcd_state =
UFSHCD_STATE_EH_SCHEDULED;

diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h index
7a2dad3..4385741 100644
--- a/drivers/scsi/ufs/ufshcd.h
+++ b/drivers/scsi/ufs/ufshcd.h
@@ -498,6 +498,7 @@ struct ufs_stats {
   * @urgent_bkops_lvl: keeps track of urgent bkops level for device
   * @is_urgent_bkops_lvl_checked: keeps track if the urgent bkops level for
   *  device is known or not.
+ * @scsi_block_reqs_cnt: reference counting for scsi block requests
   */
  struct ufs_hba {
void __iomem *mmio_base;
@@ -690,6 +691,7 @@ struct ufs_hba {

struct rw_semaphore clk_scaling_lock;
struct ufs_desc_size desc_size;
+   int scsi_block_reqs_cnt;
  };

  /* Returns true if clocks can be gated. Otherwise false */ @@ -862,6 +864,9
@@ int ufshcd_map_desc_id_to_length(struct ufs_hba *hba, enum
desc_idn desc_id,

  u32 ufshcd_get_local_unipro_ver(struct ufs_hba *hba);

+void ufshcd_scsi_block_requests(struct ufs_hba *hba); void
+ufshcd_scsi_unblock_requests(struct ufs_hba *hba);
+
  /* Wrapper functions for safely calling variant operations */  static inline
const char *ufshcd_get_var_name(struct ufs_hba *hba)  {
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center,
Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a
Linux Foundation Collaborative Project.


1. The atomic variable and operations could be used for the reference counting.
  This will allow to avoid usage of the locks.
2. Why are the ufshcd_scsi_block_requests/ ufshcd_scsi_unblock_requests
 functions not defined as static? They are not used outside ufshcd.c.

Regards
Stanislav


Hi
Thanks. Let me check this and get back.
I'll wait for comments on the other patches before posting a v2.

-asd

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
Linux Foundation Collaborative Project

Re: [PATCH 1/1] scsi: ufs: make sure all interrupts are processed

[Asutosh Das (asd)]

On 2/2/2018 8:53 AM, Asutosh Das (asd) wrote:

On 1/31/2018 1:09 PM, Avri Altman wrote:

Hi,
Can you elaborate how this can even happen?
Isn't the interrupt aggregation capability should attend for those cases?

Thanks,
Avri


-Original Message-
From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-
ow...@vger.kernel.org] On Behalf Of Asutosh Das
Sent: Tuesday, January 30, 2018 6:54 AM
To: subha...@codeaurora.org; c...@codeaurora.org;
vivek.gau...@codeaurora.org; rna...@codeaurora.org;
vinholika...@gmail.com; j...@linux.vnet.ibm.com;
martin.peter...@oracle.com
Cc: linux-s...@vger.kernel.org; Venkat Gopalakrishnan
<venk...@codeaurora.org>; Asutosh Das <asuto...@codeaurora.org>; open
list <linux-kernel@vger.kernel.org>
Subject: [PATCH 1/1] scsi: ufs: make sure all interrupts are processed

From: Venkat Gopalakrishnan <venk...@codeaurora.org>

As multiple requests are submitted to the ufs host controller in 
parallel there
could be instances where the command completion interrupt arrives 
later for a
request that is already processed earlier as the corresponding 
doorbell was
cleared when handling the previous interrupt. Read the interrupt 
status in a
loop after processing the received interrupt to catch such interrupts 
and handle

it.

Signed-off-by: Venkat Gopalakrishnan <venk...@codeaurora.org>
Signed-off-by: Asutosh Das <asuto...@codeaurora.org>
---
  drivers/scsi/ufs/ufshcd.c | 27 +++
  1 file changed, 19 insertions(+), 8 deletions(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c index
8af2af3..58d81de 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -5357,19 +5357,30 @@ static irqreturn_t ufshcd_intr(int irq, void 
*__hba)

  u32 intr_status, enabled_intr_status;
  irqreturn_t retval = IRQ_NONE;
  struct ufs_hba *hba = __hba;
+    int retries = hba->nutrs;

  spin_lock(hba->host->host_lock);
  intr_status = ufshcd_readl(hba, REG_INTERRUPT_STATUS);
-    enabled_intr_status =
-    intr_status & ufshcd_readl(hba, REG_INTERRUPT_ENABLE);

-    if (intr_status)
-    ufshcd_writel(hba, intr_status, REG_INTERRUPT_STATUS);
+    /*
+ * There could be max of hba->nutrs reqs in flight and in worst 
case

+ * if the reqs get finished 1 by 1 after the interrupt status is
+ * read, make sure we handle them by checking the interrupt status
+ * again in a loop until we process all of the reqs before 
returning.

+ */
+    do {
+    enabled_intr_status =
+    intr_status & ufshcd_readl(hba,
REG_INTERRUPT_ENABLE);
+    if (intr_status)
+    ufshcd_writel(hba, intr_status,
REG_INTERRUPT_STATUS);
+    if (enabled_intr_status) {
+    ufshcd_sl_intr(hba, enabled_intr_status);
+    retval = IRQ_HANDLED;
+    }
+
+    intr_status = ufshcd_readl(hba, REG_INTERRUPT_STATUS);
+    } while (intr_status && --retries);

-    if (enabled_intr_status) {
-    ufshcd_sl_intr(hba, enabled_intr_status);
-    retval = IRQ_HANDLED;
-    }
  spin_unlock(hba->host->host_lock);
  return retval;
  }
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center,
Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
Linux

Foundation Collaborative Project.




Hi
yes - interrupt aggregation makes sense here. But there were some 
performance concerns with it; well, I don't have the data to back that 
up now though.

However, I can code it up and check it.
Will post it in some time.

-asd


Hi Avri,
I went through the UFS HCI - v2.1 spec. Specifically, in sec 7.2.3 it 
explicitly mentions that the software should determine if new TRs were 
completed since the interrupt status was last read/cleared. This step is 
independent of aggregation.


So I think the above implementation makes sense. Please let me know if I 
understood your concern correctly.


-asd

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
Linux Foundation Collaborative Project

Re: [PATCH 1/1] scsi: ufs: make sure all interrupts are processed

[Asutosh Das (asd)]

On 2/2/2018 8:53 AM, Asutosh Das (asd) wrote:

On 1/31/2018 1:09 PM, Avri Altman wrote:

Hi,
Can you elaborate how this can even happen?
Isn't the interrupt aggregation capability should attend for those cases?

Thanks,
Avri


-Original Message-
From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-
ow...@vger.kernel.org] On Behalf Of Asutosh Das
Sent: Tuesday, January 30, 2018 6:54 AM
To: subha...@codeaurora.org; c...@codeaurora.org;
vivek.gau...@codeaurora.org; rna...@codeaurora.org;
vinholika...@gmail.com; j...@linux.vnet.ibm.com;
martin.peter...@oracle.com
Cc: linux-scsi@vger.kernel.org; Venkat Gopalakrishnan
<venk...@codeaurora.org>; Asutosh Das <asuto...@codeaurora.org>; open
list <linux-ker...@vger.kernel.org>
Subject: [PATCH 1/1] scsi: ufs: make sure all interrupts are processed

From: Venkat Gopalakrishnan <venk...@codeaurora.org>

As multiple requests are submitted to the ufs host controller in 
parallel there
could be instances where the command completion interrupt arrives 
later for a
request that is already processed earlier as the corresponding 
doorbell was
cleared when handling the previous interrupt. Read the interrupt 
status in a
loop after processing the received interrupt to catch such interrupts 
and handle

it.

Signed-off-by: Venkat Gopalakrishnan <venk...@codeaurora.org>
Signed-off-by: Asutosh Das <asuto...@codeaurora.org>
---
  drivers/scsi/ufs/ufshcd.c | 27 +++
  1 file changed, 19 insertions(+), 8 deletions(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c index
8af2af3..58d81de 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -5357,19 +5357,30 @@ static irqreturn_t ufshcd_intr(int irq, void 
*__hba)

  u32 intr_status, enabled_intr_status;
  irqreturn_t retval = IRQ_NONE;
  struct ufs_hba *hba = __hba;
+    int retries = hba->nutrs;

  spin_lock(hba->host->host_lock);
  intr_status = ufshcd_readl(hba, REG_INTERRUPT_STATUS);
-    enabled_intr_status =
-    intr_status & ufshcd_readl(hba, REG_INTERRUPT_ENABLE);

-    if (intr_status)
-    ufshcd_writel(hba, intr_status, REG_INTERRUPT_STATUS);
+    /*
+ * There could be max of hba->nutrs reqs in flight and in worst 
case

+ * if the reqs get finished 1 by 1 after the interrupt status is
+ * read, make sure we handle them by checking the interrupt status
+ * again in a loop until we process all of the reqs before 
returning.

+ */
+    do {
+    enabled_intr_status =
+    intr_status & ufshcd_readl(hba,
REG_INTERRUPT_ENABLE);
+    if (intr_status)
+    ufshcd_writel(hba, intr_status,
REG_INTERRUPT_STATUS);
+    if (enabled_intr_status) {
+    ufshcd_sl_intr(hba, enabled_intr_status);
+    retval = IRQ_HANDLED;
+    }
+
+    intr_status = ufshcd_readl(hba, REG_INTERRUPT_STATUS);
+    } while (intr_status && --retries);

-    if (enabled_intr_status) {
-    ufshcd_sl_intr(hba, enabled_intr_status);
-    retval = IRQ_HANDLED;
-    }
  spin_unlock(hba->host->host_lock);
  return retval;
  }
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center,
Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
Linux

Foundation Collaborative Project.




Hi
yes - interrupt aggregation makes sense here. But there were some 
performance concerns with it; well, I don't have the data to back that 
up now though.

However, I can code it up and check it.
Will post it in some time.

-asd


Hi Avri,
I went through the UFS HCI - v2.1 spec. Specifically, in sec 7.2.3 it 
explicitly mentions that the software should determine if new TRs were 
completed since the interrupt status was last read/cleared. This step is 
independent of aggregation.


So I think the above implementation makes sense. Please let me know if I 
understood your concern correctly.


-asd

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
Linux Foundation Collaborative Project

Re: [PATCH 1/1] scsi: ufs: make sure all interrupts are processed

[Asutosh Das (asd)]

On 2/2/2018 8:53 AM, Asutosh Das (asd) wrote:

On 1/31/2018 1:09 PM, Avri Altman wrote:

Hi,
Can you elaborate how this can even happen?
Isn't the interrupt aggregation capability should attend for those cases?

Thanks,
Avri


-Original Message-
From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-
ow...@vger.kernel.org] On Behalf Of Asutosh Das
Sent: Tuesday, January 30, 2018 6:54 AM
To: subha...@codeaurora.org; c...@codeaurora.org;
vivek.gau...@codeaurora.org; rna...@codeaurora.org;
vinholika...@gmail.com; j...@linux.vnet.ibm.com;
martin.peter...@oracle.com
Cc: linux-s...@vger.kernel.org; Venkat Gopalakrishnan
; Asutosh Das ; open
list 
Subject: [PATCH 1/1] scsi: ufs: make sure all interrupts are processed

From: Venkat Gopalakrishnan 

As multiple requests are submitted to the ufs host controller in 
parallel there
could be instances where the command completion interrupt arrives 
later for a
request that is already processed earlier as the corresponding 
doorbell was
cleared when handling the previous interrupt. Read the interrupt 
status in a
loop after processing the received interrupt to catch such interrupts 
and handle

it.

Signed-off-by: Venkat Gopalakrishnan 
Signed-off-by: Asutosh Das 
---
  drivers/scsi/ufs/ufshcd.c | 27 +++
  1 file changed, 19 insertions(+), 8 deletions(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c index
8af2af3..58d81de 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -5357,19 +5357,30 @@ static irqreturn_t ufshcd_intr(int irq, void 
*__hba)

  u32 intr_status, enabled_intr_status;
  irqreturn_t retval = IRQ_NONE;
  struct ufs_hba *hba = __hba;
+    int retries = hba->nutrs;

  spin_lock(hba->host->host_lock);
  intr_status = ufshcd_readl(hba, REG_INTERRUPT_STATUS);
-    enabled_intr_status =
-    intr_status & ufshcd_readl(hba, REG_INTERRUPT_ENABLE);

-    if (intr_status)
-    ufshcd_writel(hba, intr_status, REG_INTERRUPT_STATUS);
+    /*
+ * There could be max of hba->nutrs reqs in flight and in worst 
case

+ * if the reqs get finished 1 by 1 after the interrupt status is
+ * read, make sure we handle them by checking the interrupt status
+ * again in a loop until we process all of the reqs before 
returning.

+ */
+    do {
+    enabled_intr_status =
+    intr_status & ufshcd_readl(hba,
REG_INTERRUPT_ENABLE);
+    if (intr_status)
+    ufshcd_writel(hba, intr_status,
REG_INTERRUPT_STATUS);
+    if (enabled_intr_status) {
+    ufshcd_sl_intr(hba, enabled_intr_status);
+    retval = IRQ_HANDLED;
+    }
+
+    intr_status = ufshcd_readl(hba, REG_INTERRUPT_STATUS);
+    } while (intr_status && --retries);

-    if (enabled_intr_status) {
-    ufshcd_sl_intr(hba, enabled_intr_status);
-    retval = IRQ_HANDLED;
-    }
  spin_unlock(hba->host->host_lock);
  return retval;
  }
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center,
Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
Linux

Foundation Collaborative Project.




Hi
yes - interrupt aggregation makes sense here. But there were some 
performance concerns with it; well, I don't have the data to back that 
up now though.

However, I can code it up and check it.
Will post it in some time.

-asd


Hi Avri,
I went through the UFS HCI - v2.1 spec. Specifically, in sec 7.2.3 it 
explicitly mentions that the software should determine if new TRs were 
completed since the interrupt status was last read/cleared. This step is 
independent of aggregation.


So I think the above implementation makes sense. Please let me know if I 
understood your concern correctly.


-asd

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
Linux Foundation Collaborative Project

Re: [PATCH 1/1] scsi: ufs: make sure all interrupts are processed

[Asutosh Das (asd)]

On 1/31/2018 1:09 PM, Avri Altman wrote:

Hi,
Can you elaborate how this can even happen?
Isn't the interrupt aggregation capability should attend for those cases?

Thanks,
Avri


-Original Message-
From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-
ow...@vger.kernel.org] On Behalf Of Asutosh Das
Sent: Tuesday, January 30, 2018 6:54 AM
To: subha...@codeaurora.org; c...@codeaurora.org;
vivek.gau...@codeaurora.org; rna...@codeaurora.org;
vinholika...@gmail.com; j...@linux.vnet.ibm.com;
martin.peter...@oracle.com
Cc: linux-s...@vger.kernel.org; Venkat Gopalakrishnan
<venk...@codeaurora.org>; Asutosh Das <asuto...@codeaurora.org>; open
list <linux-kernel@vger.kernel.org>
Subject: [PATCH 1/1] scsi: ufs: make sure all interrupts are processed

From: Venkat Gopalakrishnan <venk...@codeaurora.org>

As multiple requests are submitted to the ufs host controller in parallel there
could be instances where the command completion interrupt arrives later for a
request that is already processed earlier as the corresponding doorbell was
cleared when handling the previous interrupt. Read the interrupt status in a
loop after processing the received interrupt to catch such interrupts and handle
it.

Signed-off-by: Venkat Gopalakrishnan <venk...@codeaurora.org>
Signed-off-by: Asutosh Das <asuto...@codeaurora.org>
---
  drivers/scsi/ufs/ufshcd.c | 27 +++
  1 file changed, 19 insertions(+), 8 deletions(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c index
8af2af3..58d81de 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -5357,19 +5357,30 @@ static irqreturn_t ufshcd_intr(int irq, void *__hba)
u32 intr_status, enabled_intr_status;
irqreturn_t retval = IRQ_NONE;
struct ufs_hba *hba = __hba;
+   int retries = hba->nutrs;

spin_lock(hba->host->host_lock);
intr_status = ufshcd_readl(hba, REG_INTERRUPT_STATUS);
-   enabled_intr_status =
-   intr_status & ufshcd_readl(hba, REG_INTERRUPT_ENABLE);

-   if (intr_status)
-   ufshcd_writel(hba, intr_status, REG_INTERRUPT_STATUS);
+   /*
+* There could be max of hba->nutrs reqs in flight and in worst case
+* if the reqs get finished 1 by 1 after the interrupt status is
+* read, make sure we handle them by checking the interrupt status
+* again in a loop until we process all of the reqs before returning.
+*/
+   do {
+   enabled_intr_status =
+   intr_status & ufshcd_readl(hba,
REG_INTERRUPT_ENABLE);
+   if (intr_status)
+   ufshcd_writel(hba, intr_status,
REG_INTERRUPT_STATUS);
+   if (enabled_intr_status) {
+   ufshcd_sl_intr(hba, enabled_intr_status);
+   retval = IRQ_HANDLED;
+   }
+
+   intr_status = ufshcd_readl(hba, REG_INTERRUPT_STATUS);
+   } while (intr_status && --retries);

-   if (enabled_intr_status) {
-   ufshcd_sl_intr(hba, enabled_intr_status);
-   retval = IRQ_HANDLED;
-   }
spin_unlock(hba->host->host_lock);
return retval;
  }
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center,
Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project.




Hi
yes - interrupt aggregation makes sense here. But there were some 
performance concerns with it; well, I don't have the data to back that 
up now though.

However, I can code it up and check it.
Will post it in some time.

-asd

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
Linux Foundation Collaborative Project

Re: [PATCH 1/1] scsi: ufs: make sure all interrupts are processed

[Asutosh Das (asd)]

On 1/31/2018 1:09 PM, Avri Altman wrote:

Hi,
Can you elaborate how this can even happen?
Isn't the interrupt aggregation capability should attend for those cases?

Thanks,
Avri


-Original Message-
From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-
ow...@vger.kernel.org] On Behalf Of Asutosh Das
Sent: Tuesday, January 30, 2018 6:54 AM
To: subha...@codeaurora.org; c...@codeaurora.org;
vivek.gau...@codeaurora.org; rna...@codeaurora.org;
vinholika...@gmail.com; j...@linux.vnet.ibm.com;
martin.peter...@oracle.com
Cc: linux-s...@vger.kernel.org; Venkat Gopalakrishnan
; Asutosh Das ; open
list 
Subject: [PATCH 1/1] scsi: ufs: make sure all interrupts are processed

From: Venkat Gopalakrishnan 

As multiple requests are submitted to the ufs host controller in parallel there
could be instances where the command completion interrupt arrives later for a
request that is already processed earlier as the corresponding doorbell was
cleared when handling the previous interrupt. Read the interrupt status in a
loop after processing the received interrupt to catch such interrupts and handle
it.

Signed-off-by: Venkat Gopalakrishnan 
Signed-off-by: Asutosh Das 
---
  drivers/scsi/ufs/ufshcd.c | 27 +++
  1 file changed, 19 insertions(+), 8 deletions(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c index
8af2af3..58d81de 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -5357,19 +5357,30 @@ static irqreturn_t ufshcd_intr(int irq, void *__hba)
u32 intr_status, enabled_intr_status;
irqreturn_t retval = IRQ_NONE;
struct ufs_hba *hba = __hba;
+   int retries = hba->nutrs;

spin_lock(hba->host->host_lock);
intr_status = ufshcd_readl(hba, REG_INTERRUPT_STATUS);
-   enabled_intr_status =
-   intr_status & ufshcd_readl(hba, REG_INTERRUPT_ENABLE);

-   if (intr_status)
-   ufshcd_writel(hba, intr_status, REG_INTERRUPT_STATUS);
+   /*
+* There could be max of hba->nutrs reqs in flight and in worst case
+* if the reqs get finished 1 by 1 after the interrupt status is
+* read, make sure we handle them by checking the interrupt status
+* again in a loop until we process all of the reqs before returning.
+*/
+   do {
+   enabled_intr_status =
+   intr_status & ufshcd_readl(hba,
REG_INTERRUPT_ENABLE);
+   if (intr_status)
+   ufshcd_writel(hba, intr_status,
REG_INTERRUPT_STATUS);
+   if (enabled_intr_status) {
+   ufshcd_sl_intr(hba, enabled_intr_status);
+   retval = IRQ_HANDLED;
+   }
+
+   intr_status = ufshcd_readl(hba, REG_INTERRUPT_STATUS);
+   } while (intr_status && --retries);

-   if (enabled_intr_status) {
-   ufshcd_sl_intr(hba, enabled_intr_status);
-   retval = IRQ_HANDLED;
-   }
spin_unlock(hba->host->host_lock);
return retval;
  }
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center,
Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project.




Hi
yes - interrupt aggregation makes sense here. But there were some 
performance concerns with it; well, I don't have the data to back that 
up now though.

However, I can code it up and check it.
Will post it in some time.

-asd

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
Linux Foundation Collaborative Project

Re: [PATCH 1/1] scsi: ufs: make sure all interrupts are processed

[Asutosh Das (asd)]

On 1/31/2018 1:09 PM, Avri Altman wrote:

Hi,
Can you elaborate how this can even happen?
Isn't the interrupt aggregation capability should attend for those cases?

Thanks,
Avri


-Original Message-
From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-
ow...@vger.kernel.org] On Behalf Of Asutosh Das
Sent: Tuesday, January 30, 2018 6:54 AM
To: subha...@codeaurora.org; c...@codeaurora.org;
vivek.gau...@codeaurora.org; rna...@codeaurora.org;
vinholika...@gmail.com; j...@linux.vnet.ibm.com;
martin.peter...@oracle.com
Cc: linux-scsi@vger.kernel.org; Venkat Gopalakrishnan
<venk...@codeaurora.org>; Asutosh Das <asuto...@codeaurora.org>; open
list <linux-ker...@vger.kernel.org>
Subject: [PATCH 1/1] scsi: ufs: make sure all interrupts are processed

From: Venkat Gopalakrishnan <venk...@codeaurora.org>

As multiple requests are submitted to the ufs host controller in parallel there
could be instances where the command completion interrupt arrives later for a
request that is already processed earlier as the corresponding doorbell was
cleared when handling the previous interrupt. Read the interrupt status in a
loop after processing the received interrupt to catch such interrupts and handle
it.

Signed-off-by: Venkat Gopalakrishnan <venk...@codeaurora.org>
Signed-off-by: Asutosh Das <asuto...@codeaurora.org>
---
  drivers/scsi/ufs/ufshcd.c | 27 +++
  1 file changed, 19 insertions(+), 8 deletions(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c index
8af2af3..58d81de 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -5357,19 +5357,30 @@ static irqreturn_t ufshcd_intr(int irq, void *__hba)
u32 intr_status, enabled_intr_status;
irqreturn_t retval = IRQ_NONE;
struct ufs_hba *hba = __hba;
+   int retries = hba->nutrs;

spin_lock(hba->host->host_lock);
intr_status = ufshcd_readl(hba, REG_INTERRUPT_STATUS);
-   enabled_intr_status =
-   intr_status & ufshcd_readl(hba, REG_INTERRUPT_ENABLE);

-   if (intr_status)
-   ufshcd_writel(hba, intr_status, REG_INTERRUPT_STATUS);
+   /*
+* There could be max of hba->nutrs reqs in flight and in worst case
+* if the reqs get finished 1 by 1 after the interrupt status is
+* read, make sure we handle them by checking the interrupt status
+* again in a loop until we process all of the reqs before returning.
+*/
+   do {
+   enabled_intr_status =
+   intr_status & ufshcd_readl(hba,
REG_INTERRUPT_ENABLE);
+   if (intr_status)
+   ufshcd_writel(hba, intr_status,
REG_INTERRUPT_STATUS);
+   if (enabled_intr_status) {
+   ufshcd_sl_intr(hba, enabled_intr_status);
+   retval = IRQ_HANDLED;
+   }
+
+   intr_status = ufshcd_readl(hba, REG_INTERRUPT_STATUS);
+   } while (intr_status && --retries);

-   if (enabled_intr_status) {
-   ufshcd_sl_intr(hba, enabled_intr_status);
-   retval = IRQ_HANDLED;
-   }
spin_unlock(hba->host->host_lock);
return retval;
  }
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center,
Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project.




Hi
yes - interrupt aggregation makes sense here. But there were some 
performance concerns with it; well, I don't have the data to back that 
up now though.

However, I can code it up and check it.
Will post it in some time.

-asd

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
Linux Foundation Collaborative Project

Re: [PATCH 1/1] scsi: ufs-qcom: remove broken hci version quirk

[Asutosh Das (asd)]

On 1/30/2018 11:33 AM, Vivek Gautam wrote:

Hi Asutosh,


On 1/30/2018 10:11 AM, Asutosh Das wrote:

From: Subhash Jadavani 

UFSHCD_QUIRK_BROKEN_UFS_HCI_VERSION is only applicable for QCOM UFS host
controller version 2.x.y and this has been fixed from version 3.x.y
onwards, hence this change removes this quirk for version 3.x.y onwards.

Signed-off-by: Subhash Jadavani 
Signed-off-by: Asutosh Das 
---


This patch and all other ufs patches that you have posted recently,
do they all fall under one 'ufs-qcom fixes' patch series for fixes that
we would want to do?
If it is so, then please club them together in a series, so that
it's easy for reviewers and maintainers to review, and keep track
of all the patches that can get-in after the reviews.
If they belong to two or more separate patch-series then please
create such patch series.
It's difficult to read through a lot of [PATCH 1/1] ... patch.

Sure Vivek - Makes sense. Will resend it.



Regards
Vivek


  drivers/scsi/ufs/ufs-qcom.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/ufs/ufs-qcom.c b/drivers/scsi/ufs/ufs-qcom.c
index 2b38db2..221820a 100644
--- a/drivers/scsi/ufs/ufs-qcom.c
+++ b/drivers/scsi/ufs/ufs-qcom.c
@@ -1098,7 +1098,7 @@ static void ufs_qcom_advertise_quirks(struct 
ufs_hba *hba)

  hba->quirks |= UFSHCD_QUIRK_BROKEN_LCC;
  }
-    if (host->hw_ver.major >= 0x2) {
+    if (host->hw_ver.major == 0x2) {
  hba->quirks |= UFSHCD_QUIRK_BROKEN_UFS_HCI_VERSION;
  if (!ufs_qcom_cap_qunipro(host))





--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
Linux Foundation Collaborative Project

Re: [PATCH 1/1] scsi: ufs-qcom: remove broken hci version quirk

[Asutosh Das (asd)]

On 1/30/2018 11:33 AM, Vivek Gautam wrote:

Hi Asutosh,


On 1/30/2018 10:11 AM, Asutosh Das wrote:

From: Subhash Jadavani 

UFSHCD_QUIRK_BROKEN_UFS_HCI_VERSION is only applicable for QCOM UFS host
controller version 2.x.y and this has been fixed from version 3.x.y
onwards, hence this change removes this quirk for version 3.x.y onwards.

Signed-off-by: Subhash Jadavani 
Signed-off-by: Asutosh Das 
---


This patch and all other ufs patches that you have posted recently,
do they all fall under one 'ufs-qcom fixes' patch series for fixes that
we would want to do?
If it is so, then please club them together in a series, so that
it's easy for reviewers and maintainers to review, and keep track
of all the patches that can get-in after the reviews.
If they belong to two or more separate patch-series then please
create such patch series.
It's difficult to read through a lot of [PATCH 1/1] ... patch.

Sure Vivek - Makes sense. Will resend it.



Regards
Vivek


  drivers/scsi/ufs/ufs-qcom.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/ufs/ufs-qcom.c b/drivers/scsi/ufs/ufs-qcom.c
index 2b38db2..221820a 100644
--- a/drivers/scsi/ufs/ufs-qcom.c
+++ b/drivers/scsi/ufs/ufs-qcom.c
@@ -1098,7 +1098,7 @@ static void ufs_qcom_advertise_quirks(struct 
ufs_hba *hba)

  hba->quirks |= UFSHCD_QUIRK_BROKEN_LCC;
  }
-    if (host->hw_ver.major >= 0x2) {
+    if (host->hw_ver.major == 0x2) {
  hba->quirks |= UFSHCD_QUIRK_BROKEN_UFS_HCI_VERSION;
  if (!ufs_qcom_cap_qunipro(host))





--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
Linux Foundation Collaborative Project

Re: [PATCH 1/1] scsi: ufs-qcom: remove broken hci version quirk

[Asutosh Das (asd)]

On 1/30/2018 11:33 AM, Vivek Gautam wrote:

Hi Asutosh,


On 1/30/2018 10:11 AM, Asutosh Das wrote:

From: Subhash Jadavani 

UFSHCD_QUIRK_BROKEN_UFS_HCI_VERSION is only applicable for QCOM UFS host
controller version 2.x.y and this has been fixed from version 3.x.y
onwards, hence this change removes this quirk for version 3.x.y onwards.

Signed-off-by: Subhash Jadavani 
Signed-off-by: Asutosh Das 
---


This patch and all other ufs patches that you have posted recently,
do they all fall under one 'ufs-qcom fixes' patch series for fixes that
we would want to do?
If it is so, then please club them together in a series, so that
it's easy for reviewers and maintainers to review, and keep track
of all the patches that can get-in after the reviews.
If they belong to two or more separate patch-series then please
create such patch series.
It's difficult to read through a lot of [PATCH 1/1] ... patch.

Sure Vivek - Makes sense. Will resend it.



Regards
Vivek


  drivers/scsi/ufs/ufs-qcom.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/ufs/ufs-qcom.c b/drivers/scsi/ufs/ufs-qcom.c
index 2b38db2..221820a 100644
--- a/drivers/scsi/ufs/ufs-qcom.c
+++ b/drivers/scsi/ufs/ufs-qcom.c
@@ -1098,7 +1098,7 @@ static void ufs_qcom_advertise_quirks(struct 
ufs_hba *hba)

  hba->quirks |= UFSHCD_QUIRK_BROKEN_LCC;
  }
-    if (host->hw_ver.major >= 0x2) {
+    if (host->hw_ver.major == 0x2) {
  hba->quirks |= UFSHCD_QUIRK_BROKEN_UFS_HCI_VERSION;
  if (!ufs_qcom_cap_qunipro(host))





--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
Linux Foundation Collaborative Project

[jira] [Created] (ACE-629) asd

[asd palkon (JIRA)]

asd palkon created ACE-629:
--

 Summary: asd
 Key: ACE-629
 URL: https://issues.apache.org/jira/browse/ACE-629
 Project: ACE
  Issue Type: New Feature
Reporter: asd palkon
Priority: Minor
 Attachments: asu.txt





--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: [PATCH 0/5] qcom-ufs: phy/hcd: Refactor phy initialization code

[Asutosh Das (asd)]

Vivek,

On 8/11/2017 12:42 PM, Vivek Gautam wrote:

On Fri, Aug 11, 2017 at 5:33 AM, Martin K. Petersen
<martin.peter...@oracle.com> wrote:


Vivek,


Can you kindly review this patch series (for UFS controller changes)
and consider giving your Ack so that Kishon can pull in the series
through phy tree.


SCSI piece looks OK.


Thank you Martin for your review.


Would still like Subhash to review the rest.


Subhash is on vacation with limited access to emails. I will ask
his team to take a look.


Looks good to me.

regards
Vivek



--
Martin K. Petersen  Oracle Linux Engineering
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html






--
Asutosh Das (asd)
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
Linux Foundation Collaborative Project

Re: [PATCH 0/5] qcom-ufs: phy/hcd: Refactor phy initialization code

[Asutosh Das (asd)]

Vivek,

On 8/11/2017 12:42 PM, Vivek Gautam wrote:

On Fri, Aug 11, 2017 at 5:33 AM, Martin K. Petersen
 wrote:


Vivek,


Can you kindly review this patch series (for UFS controller changes)
and consider giving your Ack so that Kishon can pull in the series
through phy tree.


SCSI piece looks OK.


Thank you Martin for your review.


Would still like Subhash to review the rest.


Subhash is on vacation with limited access to emails. I will ask
his team to take a look.


Looks good to me.

regards
Vivek



--
Martin K. Petersen  Oracle Linux Engineering
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html






--
Asutosh Das (asd)
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
Linux Foundation Collaborative Project

Re: [PATCH 0/5] qcom-ufs: phy/hcd: Refactor phy initialization code

[Asutosh Das (asd)]

Vivek,

On 8/11/2017 12:42 PM, Vivek Gautam wrote:

On Fri, Aug 11, 2017 at 5:33 AM, Martin K. Petersen
<martin.peter...@oracle.com> wrote:


Vivek,


Can you kindly review this patch series (for UFS controller changes)
and consider giving your Ack so that Kishon can pull in the series
through phy tree.


SCSI piece looks OK.


Thank you Martin for your review.


Would still like Subhash to review the rest.


Subhash is on vacation with limited access to emails. I will ask
his team to take a look.


Looks good to me.

regards
Vivek



--
Martin K. Petersen  Oracle Linux Engineering
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html






--
Asutosh Das (asd)
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
Linux Foundation Collaborative Project

RE: reelect cluster_leader

[TED ASD Nakabayashi Minoru]

I am sorry.
Please ignore this email.

I will send another e-mail account.

Best Regards,


-Original Message-
From: TED ASD Nakabayashi Minoru 
Sent: Monday, July 10, 2017 12:14 PM
To: riak-users@lists.basho.com
Cc: TED ASD Nakabayashi Minoru
Subject: reelect cluster_leader

Hello,

I am facing issue #685 using Riak KV 2.1.3.
https://github.com/basho/riak/issues/685

I am supposing reelect a cluster_leader might be the workaround.
Does anyone know how to reelect a cluster_leader by riak attach ?
I used to doing exit(riak_repl2_leader:helper_pid(), reelect) in 1.4.x.





___
riak-users mailing list
riak-users@lists.basho.com
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com

reelect cluster_leader

[TED ASD Nakabayashi Minoru]

Hello,

I am facing issue #685 using Riak KV 2.1.3.
https://github.com/basho/riak/issues/685

I am supposing reelect a cluster_leader might be the workaround.
Does anyone know how to reelect a cluster_leader by riak attach ?
I used to doing exit(riak_repl2_leader:helper_pid(), reelect) in 1.4.x.





___
riak-users mailing list
riak-users@lists.basho.com
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com

Re: [ufs]: [scsi]: BUG: spinlock recursion on CPU#4

[Asutosh Das (asd)]

On 6/1/2017 7:32 PM, Bart Van Assche wrote:

On Thu, 2017-06-01 at 12:28 +0530, Asutosh Das (asd) wrote:

Please can you check if this is actually a bug and my understanding is
correct.


Hello Asutosh,

Spinlock recursion is always a bug. With what kernel version did you encounter
this? Was it with a kernel from kernel.org, a distro kernel or an Android 
kernel?
Have you already tried to reproduce this with kernel debugging enabled? Enabling
CONFIG_DEBUG_SPINLOCK and CONFIG_PROVE_LOCKING should provide more detailed
information.

Bart.



Hello Bart,
Thanks.

It's on 4.4 and its an Android kernel.

No - I haven't tried it out yet. I could get some clues from the 
call-stack itself, like I explained before. I can try these configs 
though. While I do that, I'd like to know your thoughts on my analysis. 
Do you think with the current data, it makes sense?


--
Asutosh.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a 
Linux Foundation Collaborative Project