The maximum value PA_SaveConfigTime is 250 (10us) but this is not enough
for some vendors. Gear switch from PWM to HS may fail even with this
max. PA_SaveConfigTime. Gear switch can be issued by host controller as
an error recovery and any software delay will not help on this case so
we need to increase PA_SaveConfigTime to >32us as per vendor
recommendation. This change adds a quirk to increase the
PA_SaveConfigTime parameter.
Reviewed-by: Venkat Gopalakrishnan <venkatg@codeaurora.org>
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
The UFS HCI v2.1 includes a few additional registers. This change
updates the HCI register, the UFS version register content and the
Interrupt Status register.
Signed-off-by: Yaniv Gardi <ygardi@codeaurora.org>
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
We would by default like to run in FAST/SLOW mode instead
of FASTAUTO/SLOWAUTO mode for performance reasons. This
change sets the default speed mode to FAST/SLOW mode.
Reviewed-by: Venkat Gopalakrishnan <venkatg@codeaurora.org>
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Consider following sequence of events:
1. UFS is runtime suspended, link_state = Hibern8, device_state = sleep
2. System goes into system suspend, ufshcd_system_suspend() brings both
link and device to active state and then puts the device in Power_Down
state and link in OFF state.
3. System resumes at some later point in time, ufshcd_system_resume()
doesn't do anything as UFS state is runtime suspended. Note that link
is still on OFF state and device is in Power_Down state.
4. Now system again goes into suspend without any UFS accesses before it.
ufshcd_system_suspend() again brings both link and device to active
state and then puts the device in Power_Down state and link if OFF
state. But it's unnecessary to bring the link & device in active state
as both link and device are already in desired low power states. This
change fixes this issue by adding proper state checks in
ufshcd_system_suspend().
Reviewed-by: Gilad Broner <gbroner@codeaurora.org>
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
The condition in which error message is printed out was incorrect and
resulted error message only if retries exhausted.
But retries happens only if DME command is a peer command, and thus
DME commands which are not peer commands and fail are not printed out.
This change fixes this issue.
Signed-off-by: Yaniv Gardi <ygardi@codeaurora.org>
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
The PHY_ADAPTER_ERROR status register indicates PHY lane errors
reported by the M-PHY layer. In some occasions the controller
can recover from such errors. When the error is not recoverable,
a stuck DB error will occur. Since the stuck DB error is spotted
separately, no action other than clearing the register is necessary.
Signed-off-by: Dolev Raviv <draviv@codeaurora.org>
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
If we issue the link startup to the device while its UniPro state is
LinkDown (and device state is sleep/power-down) then link startup
will not move the device state to Active. Device will only move to
active state if the link starup is issued when its UniPro state is
LinkUp. So in this case, we would have to issue the link startup 2
times to make sure that device moves to active state.
Reviewed-by: Gilad Broner <gbroner@codeaurora.org>
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Some UFS devices require host PA_TACTIVATE to be higher than
device PA_TACTIVATE otherwise it may get stuck during hibern8 sequence.
This change allows this by using quirk.
Reviewed-by: Venkat Gopalakrishnan <venkatg@codeaurora.org>
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
It is found thats UFS device may take longer than 30ms to respond to
query requests and in this case we might run into following scenario:
1. UFS host SW sends a query request to UFS device to read an attribute
value. SW uses tag #31 for this purpose.
2. UFS host SW waits for 30ms to get the query response (and doorbell
to be cleared by UFS host HW).
3. UFS device doesn't respond back within 30ms hence UFS host SW times
out waiting for the query response.
4. UFS host SW clears the tag#31 from UTRLCLR register.
5. UFS host SW waits until UFS host HW to clear tag#31 from the doorbell
register.
6. UFS host SW retries the same query request on same tag#31 (sends a query
request to device to read an attribute value).
7. UFS host HW gets the query response from the device but this was
intended as a query response for the 1st query request sent (step-1).
8. Now UFS device sends another query response to host (for query request
sent @step-6).
Now there are 2 issues that could happen with above scenario:
1. UFS device should have actually responded back with only one query
response but it is found that device may respond back with 2 query
responses.
2. If UFS device responds back with 2 resposes on same tag, host HW/SW
behaviour isn't predictable.
To avoid running into above scenario, we would basically allow device
to take longer (upto 1.5 seconds) for query response.
Reviewed-by: Gilad Broner <gbroner@codeaurora.org>
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
While reading variable size descriptors (like string descriptor), some UFS
devices may report the "LENGTH" (field in "Transaction Specific fields" of
Query Response UPIU) same as what was requested in Query Request UPIU
instead of reporting the actual size of the variable size descriptor.
Although it's safe to ignore the "LENGTH" field for variable size
descriptors as we can always derive the length of the descriptor from
the descriptor header fields. Hence this change impose the length match
check only for fixed size descriptors (for which we always request the
correct size as part of Query Request UPIU).
Reviewed-by: Venkat Gopalakrishnan <venkatg@codeaurora.org>
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
When sending query to the device, the index of the failure
is additional useful information that should be printed out as it
might specify the logical unit (LU) where the error occurred.
Signed-off-by: Yaniv Gardi <ygardi@codeaurora.org>
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Some of the queries might fail during init. To avoid
system failure, we add retry mechanism to issue queries
several times.
Signed-off-by: Dolev Raviv <draviv@codeaurora.org>
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Some UFS host controllers may think granularities of PRDT length and
offset as bytes, not double words.
Signed-off-by: Kiwoong Kim <kwmad.kim@samsung.com>
Reviewed-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Add a new ufshcd_state, indicats that an err handler may get to run
immediately. Use UFSHCD_STATE_ERROR here looks not literaly correct.
Signed-off-by: Zang Leigang <zangleigang@hisilicon.com>
Reviewed-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Some UFS host controller may need to configure some things around
hibern8 enter/exit
Signed-off-by: Kiwoong Kim <kwmad.kim@samsung.com>
Reviewed-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Some UFS host controller may need to configure some things before any
task management request is issued
Signed-off-by: Kiwoong Kim <kwmad.kim@samsung.com>
Reviewed-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Some UFS host controller may need to configure some things before any
transfer request is issued.
Signed-off-by: Kiwoong Kim <kwmad.kim@samsung.com>
Reviewed-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
This patch uses the resource-managed to add the devfreq device. This
function will make it easy to handle the devfreq device.
- struct devfreq *devm_devfreq_add_device(struct device *dev,
struct devfreq_dev_profile *profile,
const char *governor_name,
void *data);
Cc: Vinayak Holikatti <vinholikatti@gmail.com>
Cc: James E.J. Bottomley <jejb@linux.vnet.ibm.com>
Cc: Martin K. Petersen <martin.petersen@oracle.com>
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Reviewed-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
When we are resuming the UFS device rails in HPM mode, we are first
powering on the VCC rail while VCCQ and VCCQ2 rails still being in LPM
mode. Some UFS devices may take VCC on event as hint that host wants UFS
device to be resumed and may start drawing more power from the
VCCQ/VCCQ2 rails (while they are still in LPM mode) causing voltage drop
on these rails. This change fixes this issue by bringing VCCQ & VCCQ2
rails out of LPM before powering on VCC rail.
Reviewed-by: Venkat Gopalakrishnan <venkatg@codeaurora.org>
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Currently clock scaling is suspended only after the host and device are
put in low power mode but we should avoid clock scaling running after
UFS link is put in low power mode (hibern8). This change suspends clock
scaling before putting host/device in low power mode.
Reviewed-by: Sahitya Tummala <stummala@codeaurora.org>
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
If ufshcd pltfrm/pci driver's probe fails for some reason then ensure
that scsi host is released to avoid memory leak but managed memory
allocations (via devm_* calls) need not to be freed explicitly on probe
failure as memory allocated with these functions is automatically freed
on driver detach.
Reviewed-by: Sahitya Tummala <stummala@codeaurora.org>
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
UFS devfreq clock scaling work may require clocks to be ON if it need to
execute some UFS commands hence it may request for clock hold before
issuing the command. But if UFS clock gating work is already running in
parallel, ungate work would end up waiting for the clock gating work to
finish and as clock gating work would also wait for the clock scaling
work to finish, we would enter in deadlock state. Here is the call trace
during this deadlock state:
Workqueue: devfreq_wq devfreq_monitor
__switch_to
__schedule
schedule
schedule_timeout
wait_for_common
wait_for_completion
flush_work
ufshcd_hold
ufshcd_send_uic_cmd
ufshcd_dme_get_attr
ufs_qcom_set_dme_vs_core_clk_ctrl_clear_div
ufs_qcom_clk_scale_notify
ufshcd_scale_clks
ufshcd_devfreq_target
update_devfreq
devfreq_monitor
process_one_work
worker_thread
kthread
ret_from_fork
Workqueue: events ufshcd_gate_work
__switch_to
__schedule
schedule
schedule_preempt_disabled
__mutex_lock_slowpath
mutex_lock
devfreq_monitor_suspend
devfreq_simple_ondemand_handler
devfreq_suspend_device
ufshcd_gate_work
process_one_work
worker_thread
kthread
ret_from_fork
Workqueue: events ufshcd_ungate_work
__switch_to
__schedule
schedule
schedule_timeout
wait_for_common
wait_for_completion
flush_work
__cancel_work_timer
cancel_delayed_work_sync
ufshcd_ungate_work
process_one_work
worker_thread
kthread
ret_from_fork
This change fixes this deadlock by doing this in devfreq work (devfreq_wq):
Try cancelling clock gating work. If we are able to cancel gating work
or it wasn't scheduled, hold the clock reference count until scaling is
in progress. If gate work is already running in parallel, let's skip
the frequecy scaling at this time and it will be retried once next scaling
window expires.
Reviewed-by: Sahitya Tummala <stummala@codeaurora.org>
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
In a case where gate work is called as part of cancel work from ungate
path the clk state would be marked as REQ_CLKS_ON. There is no point
gating the clocks and then end up turning them ON immediately in ungate
work, save time by skipping the gate work and change the clk state to
CLKS_ON as they are not turned off yet.
Signed-off-by: Venkat Gopalakrishnan <venkatg@codeaurora.org>
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
The ungate work turns on the clock before it exits hibern8, if the link
was put in hibern8 during clock gating work. There occurs a race
condition when clock scaling work calls ufshcd_hold() to make sure low
power states cannot be entered, but that returns by checking only
whether the clocks are on. This causes the clock scaling work to issue
UIC commands when the link is in hibern8 causing failures. Make sure we
exit hibern8 state before returning from ufshcd_hold().
Callstacks for race condition:
ufshcd_scale_gear
ufshcd_devfreq_scale
ufshcd_devfreq_target
update_devfreq
devfreq_monitor
process_one_work
worker_thread
kthread
ret_from_fork
ufshcd_uic_hibern8_exit
ufshcd_ungate_work
process_one_work
worker_thread
kthread
ret_from_fork
Signed-off-by: Venkat Gopalakrishnan <venkatg@codeaurora.org>
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
In case the power configuration fails, skip further processing of the
probing function and return immediately. This has 2 reasons:
1. Don't allow the UFS to continue running in PWM
2. Avoid multiple calls to pm_runtime_put_sync() when not in error
handling or power management contexts
Signed-off-by: Dov Levenglick <dovl@codeaurora.org>
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
During runtime resume operation, clock scaling may get indirectly
resumed via call to ufshcd_set_dev_pwr_mode(): Start/Stop Unit command
times out and SCSI error handling ultimately calls the host reset
handler to recover, during which clock scaling is resumed. Error case
exit path of runtime resume will disable clocks. As clock scaling was
already resumed, it will get scheduled later on and try to access UFS
registers while clocks are disabled, resulting in unclocked register
access.
Signed-off-by: Gilad Broner <gbroner@codeaurora.org>
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
According to UFS device specification, sense data can be only 18 bytes
long, this change makes the changes accordingly.
Signed-off-by: Gilad Broner <gbroner@codeaurora.org>
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Add a write memory barrier to make sure descriptors prepared are
actually written to memory before ringing the doorbell. We have also
added the write memory barrier after ringing the doorbell register so
that controller sees the new request immediately.
Signed-off-by: Gilad Broner <gbroner@codeaurora.org>
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
In this change there are a few fixes of possible NULL pointer access and
possible access to index that exceeds array boundaries.
Signed-off-by: Yaniv Gardi <ygardi@codeaurora.org>
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Vendor specific setup_clocks callback may require the clocks managed by
ufshcd driver to be ON. So if the vendor specific setup_clocks callback
is called while the required clocks are turned off, it could result into
unclocked register access.
To prevent possible unclock register access, this change adds one more
argument to setup_clocks callback to let it know whether it is called
pre/post the clock changes by core driver.
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Reviewed-by: Kiwoong Kim <kwmad.kim@samsung.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Fix to return a negative error code from the error handling case instead
of 0, as done elsewhere in this function.
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Reviewed-by: Subhash Jadavani <subhashj@codeaurora.org>
Reviewed-by: Kiwoong Kim <kwmad.kim@samsung.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Some devices have problems handling a Query UPIU with Data Segment
set. Only set it for WRITE DESCRIPTOR commands.
[mkp: updated patch description]
Signed-off-by: Zang Leigang <zangleigang@hisilicon.com>
Reviewed-by: Subhash Jadavani <subhashj@codeaurora.org>
Reviewed-by: Kiwoong Kim <kwmad.kim@samsung.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
When any UFS host controller receives a TM(Task Management) response
from a UFS device, UFS driver has been recognize like receiving a
message of "Task Management Function Complete"(00h) in all cases, so
far. That means there is no pending task for a tag of the TM request
sent before in the UFS device. That's because the byte offset 6 in TM
response which has been used to get a TM service response so far
represents just whether or not a TM transmission passes.
Regarding UFS spec, the correct byte offset to get TM service response
is 15, not 6.
I tested that UFS driver responds properly for the TM response from a
UFS device with an reference board with exynos8890, as follow: No
pending task -> Task Management Function Complete (00h) Pending task ->
Task Management Function Succeeded (08h)
[mkp: applied by hand]
Signed-off-by: Kiwoong Kim <kwmad.kim@samsung.com>
Signed-off-by: HeonGwang Chu <hg.chu@samsung.com>
Tested-by: : Kiwoong Kim <kwmad.kim@samsung.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
I modified a string as described in UFS spec as follow: umpcrs -> upmcrs.
[mkp: applied by hand]
Signed-off-by: Kiwoong Kim <kwmad.kim@samsung.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
When buff_ascii kmalloc failed, there is no need to call kfree, it
should return -ENOMEM directly, this patch fixes it.
Signed-off-by: Tiezhu Yang <kernelpatch@126.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Add UFS 2.0 support to the UFS core driver.
Signed-off-by: Joao Pinto <jpinto@synopsys.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Tomas Winkler <tomas.winkler@intel.com>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
We put the UFS device in sleep state & UFS link in hibern8 state during
runtime suspend. After this we put all the UFS rails in low power
modes immediately but it seems some devices may still draw more than
sleep current from UFS rails (especially from VCCQ rail) at-least for
500us.
To avoid this situation, this change adds 2ms delay before putting
these UFS rails in LPM mode.
Reviewed-by: Gilad Broner <gbroner@codeaurora.org>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: Yaniv Gardi <ygardi@codeaurora.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Currently when we try to put the link in off/disabled state during
suspend, it seems link is not being kept in low power mode.
This patch fixes the issue by putting the link in hibern8 first
(so device also puts the link in low power mode) and then stop the
host controller.
Reviewed-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: Yaniv Gardi <ygardi@codeaurora.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Optimal values of local UniPro parameters like PA_Hibern8Time &
PA_TActivate can help reduce the hibern8 exit latency. If both host and
device supports UniPro ver1.6 or later, these parameters will be
automatically tuned during link startup itself. But if either host or
device doesn't support UniPro ver 1.6 or later, we have to manually
tune them. But to keep manual tuning logic simple, we will only do
manual tuning if local unipro version doesn't support ver1.6 or later.
Reviewed-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: Yaniv Gardi <ygardi@codeaurora.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
We are seeing that some devices are raising the urgent bkops exception
events even when BKOPS status doesn't indicate performace impacted or
critical. Handle these device by determining their urgent bkops status
at runtime.
Reviewed-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: Yaniv Gardi <ygardi@codeaurora.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Query commands have 100ms timeout and it may timeout if they are
issued in parallel to ongoing read/write SCSI commands, this change
adds the retry (max: 10) in case command timeouts.
Reviewed-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: Yaniv Gardi <ygardi@codeaurora.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Some vendor's UFS device sends back to back NACs for the DL data frames
causing the host controller to raise the DFES error status. Sometimes
such UFS devices send back to back NAC without waiting for new
retransmitted DL frame from the host and in such cases it might be
possible the Host UniPro goes into bad state without raising the DFES
error interrupt. If this happens then all the pending commands would
timeout only after respective SW command (which is generally too
large).
This change workarounds such device behaviour like this:
- As soon as SW sees the DL NAC error, it would schedule the error
handler
- Error handler would sleep for 50ms to see if there any fatal errors
raised by UFS controller.
- If there are fatal errors then SW does normal error recovery.
- If there are no fatal errors then SW sends the NOP command to
device to check if link is alive.
- If NOP command times out, SW does normal error recovery
- If NOP command succeed, skip the error handling.
If DL NAC error is seen multiple times with some vendor's UFS devices
then enable this quirk to initiate quick error recovery and also
silence related error logs to reduce spamming of kernel logs.
Reviewed-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: Yaniv Gardi <ygardi@codeaurora.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
UFS driver's error handler forcefully tries to clear all the pending
requests. For each pending request in the queue, it waits 1 sec for it
to get cleared. If we have multiple requests in the queue then it's
possible that we might end up waiting for those many seconds before
resetting the host. But note that resetting host would any way clear
all the pending requests from the hardware. Hence this change skips
the forceful clear of the pending requests if we are anyway going to
reset the host (for fatal errors).
Reviewed-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: Yaniv Gardi <ygardi@codeaurora.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Some UFS devices don't require VCCQ rail for device operations hence
this change adds support to recognize such devices and remove vote for
the unused VCCQ rail.
Reviewed-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: Yaniv Gardi <ygardi@codeaurora.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Currently we use the host quirks mechanism in order to
handle both device and host controller quirks.
In order to support various of UFS devices we should separate
handling the device quirks from the host controller's.
Reviewed-by: Gilad Broner <gbroner@codeaurora.org>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Raviv Shvili <rshvili@codeaurora.org>
Signed-off-by: Yaniv Gardi <ygardi@codeaurora.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
This change adds support to read device descriptor and string descriptor
from a UFS device
Reviewed-by: Gilad Broner <gbroner@codeaurora.org>
Reviewed-by: Hannes Reinecke <hare@suse.com>
Signed-off-by: Raviv Shvili <rshvili@codeaurora.org>
Signed-off-by: Yaniv Gardi <ygardi@codeaurora.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Sometimes due to hw issues it takes some time to the
host controller register to update. In order to verify the register
has updated, a polling is done until its value is set.
In addition the functions ufshcd_hba_stop() and
ufshcd_wait_for_register() was updated with an additional input
parameter, indicating the timeout between reads will
be done by sleeping or spinning the cpu.
Reviewed-by: Hannes Reinecke <hare@suse.com>
Signed-off-by: Raviv Shvili <rshvili@codeaurora.org>
Signed-off-by: Yaniv Gardi <ygardi@codeaurora.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
A race condition exists between request requeueing and scsi layer
error handling:
When UFS driver queuecommand returns a busy status for a request,
it will be requeued and its tag will be freed and set to -1.
At the same time it is possible that the request will timeout and
scsi layer will start error handling for it. The scsi layer reuses
the request and its tag to send error related commands to the device,
however its tag is no longer valid.
As this request was never really sent to the device, there is no
point to start error handling with the device.
Implement the scsi error handling timeout callback and bypass SCSI
error handling for request that were not actually sent to the device.
For such requests simply reset the block layer timer. Otherwise, let
SCSI layer perform the usual error handling.
Reviewed-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Gilad Broner <gbroner@codeaurora.org>
Signed-off-by: Yaniv Gardi <ygardi@codeaurora.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
When control reaches to Linux UFS driver during UFS boot mode, UFS host
controller interrupt status/enable registers may have left over
settings.
In order to avoid any spurious interrupts due to these left overs,
it's important to clear these interrupt status/enable registers before
enabling UFS interrupt handling.
Reviewed-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: Yaniv Gardi <ygardi@codeaurora.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Different platform may have different number of lanes
for the UFS link.
Add parameter to device tree specifying how many lanes
should be configured for the UFS link.
Reviewed-by: Hannes Reinecke <hare@suse.de>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Gilad Broner <gbroner@codeaurora.org>
Signed-off-by: Yaniv Gardi <ygardi@codeaurora.org>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
