As stated by the eMMC 5.0 specification, a chip should not be rejected
only because of the revision stated in the EXT_CSD_REV field of the
EXT_CSD register.
Remove the control on this value, the control of the CSD_STRUCTURE field
should be sufficient to reject future incompatible changes.
Signed-off-by: Romain Izard <romain.izard.pro@gmail.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
This patch adds HS400 mode support for eMMC5.0 device. HS400 mode is high
speed DDR interface timing from HS200. Clock frequency is up to 200MHz
and only 8-bit bus width is supported. In addition, tuning process of
HS200 is required to synchronize the command response on the CMD line
because CMD input timing for HS400 mode is the same as HS200 mode.
Signed-off-by: Seungwon Jeon <tgih.jun@samsung.com>
Reviewed-by: Jackey Shen <jackey.shen@amd.com>
Tested-by: Jaehoon Chung <jh80.chung@samsung.com>
Acked-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>
Current implementation for bus speed mode selection is too
complicated. This patch is to simplify the codes and remove
some duplicate parts.
The following changes are including:
* Adds functions for each mode selection(HS, HS-DDR, HS200 and etc)
* Rearranged the mode selection sequence with supported device type
* Adds maximum speed for HS200 mode(hs200_max_dtr)
* Adds field definition for HS_TIMING of EXT_CSD
Signed-off-by: Seungwon Jeon <tgih.jun@samsung.com>
Tested-by: Jaehoon Chung <jh80.chung@samsung.com>
Acked-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>
Power class is changed once only after selection of bus modes
including speed and bus-width finishes finally.
Signed-off-by: Seungwon Jeon <tgih.jun@samsung.com>
Tested-by: Jaehoon Chung <jh80.chung@samsung.com>
Acked-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>
Device types which are supported by both host and device can be
identified when EXT_CSD is read. There is no need to check host's
capability anymore.
Signed-off-by: Seungwon Jeon <tgih.jun@samsung.com>
Tested-by: Jaehoon Chung <jh80.chung@samsung.com>
Acked-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>
Timing mode identifier has same role and can take the place
of speed mode. This change removes all related speed mode.
Signed-off-by: Seungwon Jeon <tgih.jun@samsung.com>
Tested-by: Jaehoon Chung <jh80.chung@samsung.com>
Acked-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>
Use new ATTRIBUTE_GROUPS macro to declare attribute groups.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>
When sending the sleep command for host drivers supporting
MMC_CAP_WAIT_WHILE_BUSY, we need to confirm that max_busy_timeout is
big enough comparing to the sleep timeout specified from card's
EXT_CSD. If this isn't case, we use a R1 response instead of R1B and
fallback to use a delay instead.
Do note that a max_busy_timeout set to zero by the host, is interpreted
as it can cope with whatever timeout the mmc core provides it with.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>
Conform to the eMMC spec and use the CMD6 generic timeout from the
EXT_CSD register, when switching to HS200 mode.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>
Instead of handle specific adaptations, releated to certain switch
operations, inside __mmc_switch, push this to be handled by the caller
instead.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>
There are no reason to why the use of a non-volatile internal eMMC
cache should be controlled by a host cap. Instead let's just enable it
if the eMMC card supports it.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: Seungwon Jeon <tgih.jun@samsung.com>
Signed-off-by: Chris Ball <chris@printf.net>
Earlier we disabled the cache during suspend, which meant a flush was
internally at the eMMC performed as well.
To simplify code we can make use of the mmc_flush_cache(), during mmc
suspend, which makes the mmc_cache_ctrl() redundant so then we can
remove it.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: Seungwon Jeon <tgih.jun@samsung.com>
Signed-off-by: Chris Ball <chris@printf.net>
There are no active users of this host capability. The primary reason
for adding this cap was due to a bug in ux500 boot loader code, which
is not a relevant issue any more. So, let's remove it.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>
Invoking system suspend or shutdown without using the Kconfig option
MMC_UNSAFE_RESUME, did trigger an ungraceful power cut of the card.
To improve the situation, change the behavior to always make use of the
available bus_ops callbacks that handles system suspend and shutdown
properly.
By changing the behavior MMC_UNSAFE_RESUME becomes redundant, so lets's
remove it.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>
The MMC_CAP_UHS_DDR50 must work on 1.8v.
However, the eMMC DDR mode can work on either 1.8v or 3.3v and
should not depend on UHS_DDR50.
So get rid of this limitation to let controller without 1.8v
signal voltage support can also work for eMMC DDR mode if it claims.
Signed-off-by: Dong Aisheng <b29396@freescale.com>
Acked-by: Shawn Guo <shawn.guo@linaro.org>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
In some environments it is to prefer to postpone the resume of the card
device until runtime_resume is being carried out, since it will mean a
signficant decrease of the total system resume time.
The reason of the decreased resume time is simply because of the actual
re-initalization of the card, which typically takes hundreds of
milliseconds, is performed outside the resume sequence and wont thus
affect it.
For removable card, the detect work tries to re-detect the card to make
sure it is still present, as a part of that sequence the card will also
be runtime_resumed and thus also fully resumed.
For a non-removable card, typically a mmc blk request will trigger a
runtime_resume and thus fully resume the card. This also means the
first request will likely suffer from an inital latency since the
re-initialization of the card needs to be performed.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
The card device is considered as in-active after it has been suspended.
To prevent any further runtime PM requests in suspend state, we then
disable runtime PM.
After the card device has been resumed, we shall consider it as active,
like we also do after a probe sequence. When resumed, we can safely
enable runtime PM again.
This will make sure the PM core can request the card device to go to
in-active state after a resume has been completed. Previously we had to
wait for new pm_runtime_get->pm_runtime_put cycle to be executed.
Additionally, once a resume has been carried out, update the last busy
mark. At the moment this will have no effect but if the PM core will
respect autosuspend enabled devices, when it directly triggers a
runtime_suspend from a runtime_idle, it will mean the card device will
be scheduled for a delayed runtime_suspend instead of done immediately.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
Commit "mmc: core: Push common suspend|resume code into each bus_ops"
moved the responsibility for doing mmc_power_up|off into each
suspend/resume bus_ops. When using MMC_CAP_AGGRESSIVE_PM, through the
runtime callbacks, calls to mmc_power_up|off became redundant.
When removing them, we are also able to remove the calls to
mmc_claim|release_host, thus simplifing code a bit more.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
By adding a card state that records if it is suspended or resumed, we
can accept asyncronus suspend/resume requests for the mmc and sd
bus_ops.
MMC_CAP_AGGRESSIVE_PM, will at request inactivity through the runtime
bus_ops callbacks, execute a suspend of the the card. In the state were
this has been done, we can receive a suspend request for the mmc bus,
which for sd and mmc forced the card to active state by a
pm_runtime_get_sync. In other words, the card was resumed and then
immediately suspended again, completely unnecessary.
Since the suspend/resume bus_ops callbacks for sd and mmc are now
capable of handling asynchronous requests, we no longer need to force
the card to active state before executing suspend. Evidently preventing
the above sequence for MMC_CAP_AGGRESSIVE_PM.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
Since mmc_select_voltage now only gets called from the attach sequence,
it makes sense to move the out of spec validations of the card ocr into
this function.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
According to eMMC/SD/SDIO specs, the VDD (VCC) voltage level must be
maintained during the initialization sequence. If we want/need to tune
the voltage level, a complete power cycle of the card must be executed.
Most host drivers conforms to the specifications by only allowing to
change VDD voltage level at the MMC_POWER_UP state, but some also cares
about MMC_POWER_ON state, which they should'nt. This patch will not
break those drivers, but they could clean up code to better reflect
what is expected from the protocol layer.
A big re-work of the mmc_select_voltage function is done to only change
VDD voltage level if the host supports MMC_CAP2_FULL_PWR_CYCLE.
Otherwise only validation of the host and card ocr mask will be done.
A very nice side-effect of this patch is that we now don't need to
reset the negotiated ocr mask at the mmc_power_off function, since now
it will actually reflect the present voltage level, which safely can be
used at the next power up and re-initialization. Moreover, we then only
need to execute mmc_select_voltage from the attach sequence.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
The negotiated ocr mask is directly related to the card. Once a card
gets removed, the mask shall be dropped. By moving the cache of the ocr
mask from the host struct to the card struct we have accomplished this.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
As a step to fixup the setup of the negotiated ocr mask, we need the
mmc_power_up|cycle functions to take the ocr as a parameter.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
Some switch operations like poweroff notify, shall according to the
spec not be followed by any other new commands. For these cases and
when the host does'nt support MMC_CAP_WAIT_WHILE_BUSY, we must not
send status commands to poll for busy detection. Instead wait for
the stated timeout from the EXT_CSD before completing the request.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
The field containing the production date in the CID register only uses
4 bits to encode the year, starting from 1997 in the original standard.
In 2013, the production year field contains 0, and the kernel reports a
1997 production date.
The eMMC 4.51 specification adds a new interpretation rule. For all
devices implementing the 4.41 specification or later, the production
year field will be interpreted as a value between 2010 and 2025, with
0 corresponding to 2013.
Signed-off-by: Romain Izard <romain.izard.pro@gmail.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
MMC_CAP2_FULL_PWR_CYCLE shall be set by host drivers which are able to
do a complete power cycle of the card. In the eMMC case that includes
both vcc and vccq.
This CAP is providing the protocol layer with important information,
needed to take optimized decisions during card initialization and in
the suspend/resume sequence.
MMC_CAP2_POWEROFF_NOTIFY is replaced by MMC_CAP2_FULL_PWR_CYCLE, since
it makes sense to use a wider scope for it.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
In suspend mode it is important to save power. If the host is able to
cut buth vcc and vccq, the MMC_CAP2_POWEROFF_NOTIFY shall be set. It
will mean the card will be completely powered down at suspend and the
power off notification cmd will be sent prior power down.
It seems common not being able to cut both vcc and vccq for a host. In
this situation we issue the sleep cmd in favor of the power off
notification cmd, to save more power.
While maintainng the above policy, we also want to make use of the
power off notification in the shutdown sequence, even in the case were
the host has not set MMC_CAP2_POWEROFF_NOTIFY, since we know vcc and
vccq will regardless be cut.
We accomplish this by always enabling the power off notification byte
in the EXT_CSD and issue the power off notification when either
MMC_CAP2_POWEROFF_NOTIFY is set or we are executing a shutdown.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
The shutdown sequence of an (e)MMC is very similar to a suspend. We
re-use the suspend function and tell it we are not in suspend context.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
Depending on the context of the operation while powering down the card,
either POWER_OFF_NOTIFY_SHORT or POWER_OFF_NOTIFY_LONG will be used. In
suspend context a short timeout is preferred while a long timeout would
be acceptable in a shutdown/hibernation context.
We add a new parameter to the mmc_suspend function so we can provide an
indication of what notification type to use.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
By moving code from the mmc_suspend|resume_host down into each
.suspend|resume bus_ops callback, we get a more flexible solution.
Some nice side effects are that we get a better understanding of each
bus_ops suspend|resume sequence and the common code don't have to take
care of specific corner cases, especially for the SDIO case.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Tested-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
With the new eMMC5.1 spec, there is a new EXT_CSD register with
the revision number(EXT_CSD_REV) 7. This patch updates the check
for ext-csd.rev number as 7.
Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
Signed-off-by: Yuvaraj Kumar C D <yuvaraj.cd@samsung.com>
Reviewed-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
Use the saved values in card->ext_csd when selecting power class.
By doing this the power class will be selected even if mmc_init_card
is called with oldcard != NULL, which is the case after a suspend/resume.
Today ext_csd is NULL if mmc_init_card is called with oldcard != NULL
and power class will not be selected.
According to the eMMC specification the POWER_CLASS value is reset after
power failure, H/W reset assertion and any CMD0 reset.
Signed-off-by: Fredrik Soderstedt <fredrik.soderstedt@stericsson.com>
Reviewed-by: Johan Rudholm <jrudholm@gmail.com>
Acked By: Girish K S <girish.shivananjappa@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
The mmc_card_sleep|awake APIs are not being used since the support is
already properly encapsulated within the suspend sequence. Sleep|awake
command is also specific for eMMC.
We remove the sleep|awake bus_ops, the mmc_card_sleep|awake APIs and
move the code into the mmc specific core instead. This also includes
the mmc ops function, mmc_sleepawake. All releated functions have then
become static and we have got far less code to maintain.
Additionally this patch also simplifies the code from mmc_sleepawake,
since it is only used to put the card to sleep and not awake.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
Aggressive power management is suitable when saving power is
essential. At request inactivity timeout, aka pm runtime
autosuspend timeout, the card will be suspended.
Once a new request arrives, the card will be re-initalized and
thus the first request will suffer from a latency. This latency
is card-specific, experiments has shown in general that SD-cards
has quite poor initialization time, around 300ms-1100ms. eMMC is
not surprisingly far better but still a couple of hundreds of ms
has been observed.
Except for the request latency, it is important to know that
suspending the card will also prevent the card from executing
internal house-keeping operations in idle mode. This could mean
degradation in performance.
To use this feature make sure the request inactivity timeout is
chosen carefully. This has not been done as a part of this patch.
Enable this feature by using host cap MMC_CAP_AGGRESSIVE_PM and
by setting CONFIG_MMC_UNSAFE_RESUME.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
Once the mmc blkdevice is being probed, runtime pm will be enabled.
By using runtime autosuspend, the power save operations can be done
when request inactivity occurs for a certain time. Right now the
selected timeout value is set to 3 s. Obviously this value will likely
need to be configurable somehow since it needs to be trimmed depending
on the power save algorithm.
For SD-combo cards, we are still leaving the enablement of runtime PM
to the SDIO init sequence since it depends on the capabilities of the
SDIO func driver.
Moreover, when the blk device is being suspended, we make sure the device
will be runtime resumed. The reason for doing this is that we want the
host suspend sequence to be unaware of any runtime power save operations
done for the card in this phase. Thus it can just handle the suspend as
the card is fully powered from a runtime perspective.
Finally, this patch prepares to make it possible to move BKOPS handling
into the runtime callbacks for the mmc bus_ops. Thus IDLE BKOPS can be
accomplished.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
Move mmc suspend specific operations to be executed from the .suspend
callback in the mmc bus_ops. This simplifies the mmc_suspend_host
function which is supposed to handle nothing but common suspend tasks.
Since eMMC can be considered non-removable there are no need to check
for ongoing bkops at PM_SUSPEND_PREPARE notification so remove it.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
PARTITION_SUPPORT needs to be set before doing the compare on version
number so the bit width test does not get invalid data. Before this
patch, a Sandisk iNAND eMMC card would detect 1-bit width although
the hardware supports 4-bit.
Only affects old emmc devices - pre 4.4 devices.
Reported-by: Elad Yi <elad.yi@gmail.com>
Signed-off-by: Philip Rakity <prakity@yahoo.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
The JEDEC MMC v4 spec defines a new PRV value in place of the original
fwrev and hwrev specified in v1. We can expose this in the kernel to enable
user space to more easily determine the product revision of a given MMC.
Signed-off-by: Bernie Thompson <bhthompson@chromium.org>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
This patch adds packed command feature of eMMC4.5. The maximum number
for packing read (or write) is offered and exception event relevant to
packed command which is used for error handling is enabled. If host
wants to use this feature, MMC_CAP2_PACKED_CMD should be set.
Signed-off-by: Seungwon Jeon <tgih.jun@samsung.com>
Reviewed-by: Maya Erez <merez@codeaurora.org>
Reviewed-by: Subhash Jadavani <subhashj@codeaurora.org>
Reviewed-by: Namjae Jeon <linkinjeon@gmail.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
Allow callers to access the start_signal_voltage_switch host_ops
member without going through any cmd11 logic. This is mostly a
preparation for the following signal voltage switch patch.
Also, reset ios.signal_voltage to its original value if
start_signal_voltage_switch fails.
Signed-off-by: Johan Rudholm <johan.rudholm@stericsson.com>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Tested-by: Wei WANG <wei_wang@realsil.com.cn>
Signed-off-by: Chris Ball <cjb@laptop.org>
SET_BLOCK_COUNT CMD23 is needed for all access to RPMB partition. If
block count is not set by CMD23, all subsequent read/write commands fail
as per eMMC specification. So, If the host does not support CMD23, do not
expose RPMB partition.
Accessing RPMB partition can cause hang / huge delay for hosts which do
not support CMD23.
Signed-off-by: Balaji T K <balajitk@ti.com>
Reported-and-Tested-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
Cache control is an eMMC feature and in therefore should be
part of MMC's bus resume operations, performed in mmc_suspend,
rather than in the generic mmc_suspend_host().
Signed-off-by: Maya Erez <merez@codeaurora.org>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
If "caps2" host capabilities does not indicate support for MMC
HS200, don't allow clock speeds >52MHz. Currently, for MMC, the
clock speed is set to the lesser of the max speed the eMMC module
supports (card->ext_csd.hs_max_dtr) or the max base clock of the
host controller (host->f_max based on BASE_CLK_FREQ in the host
CAPS register). This means that a host controller that doesn't
support HS200 mode but has a base clock of 100MHz and an eMMC module
that supports HS200 speeds will end up using a 100MHz clock.
Signed-off-by: Al Cooper <alcooperx@gmail.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
Following JEDEC standard, if the mmc supports RPMB partition,
a new interface is created and exposed via /dev/block.
Users will be able to access RPMB partition using standard
mmc IOCTL commands.
Signed-off-by: Alex Macro <alex.macro@stericsson.com>
Signed-off-by: Loic Pallardy <loic.pallardy@stericsson.com>
Reviewed-by: Namjae Jeon <linkinjeon@gmail.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Johan Rudholm <johan.rudholm@stericsson.com>
Acked-by: Krishna Konda <kkonda@codeaurora.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
There are discrepancies with regards to how MMC capabilities
are carried throughout the subsystem. Let's standardise them
to eliminate any confusion.
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
This patch fixes up the broken suspend sequence for eMMC with sleep
support. Additionally it reworks the eMMC4.5 Power Off Notification
feature so it fits together with the existing sleep feature.
The CMD0 based re-initialization of the eMMC at resume is re-introduced
to maintain compatiblity for devices using sleep.
A host shall use MMC_CAP2_POWEROFF_NOTIFY to enable the Power Off
Notification feature. We might be able to remove this cap later on,
if we think that Power Off Notification always is preferred over
sleep, even if the host is not able to cut the eMMC VCCQ power.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Saugata Das <saugata.das@linaro.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
Enable eMMC background operations (BKOPS) feature.
If URGENT_BKOPS is set after a response, note that BKOPS are required.
Immediately run BKOPS if required. Read/write operations should be
requested during BKOPS(LEVEL-1), then issue HPI to interrupt the
ongoing BKOPS and service the foreground operation.
(This patch only controls the LEVEL2/3.)
When repeating the writing 1GB data, at a certain time, performance is
decreased. At that time, card triggers the Level-3 or Level-2. After
running bkops, performance is recovered.
Future considerations:
* Check BKOPS_LEVEL=1 and start BKOPS in a preventive manner.
* Interrupt ongoing BKOPS before powering off the card.
* How do we get BKOPS_STATUS value (periodically send ext_csd command)?
* If using periodic bkops, also consider runtime_pm control.
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Konstantin Dorfman <kdorfman@codeaurora.org>
Reviewed-by: Maya Erez <merez@codeaurora.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
Add a call to mmc_set_signal_voltage() to set signal voltage to 3.3v in
mmc_power_up so that we do not need to touch signal voltage setting in
mmc/sd/sdio init functions and rescan function.
For mmc/sd cards, when doing a suspend/resume cycle, consider the unsafe
resume case, the card will lose its power and when powered on again, we
will set signal voltage to 3.3v in mmc_power_up before its resume function
gets called, which will re-init the card.
And for sdio cards, when doing a suspend/resume cycle, consider the unsafe
resume case, the card will either lose its power or not depending on if it
wants to wakeup the host. If power is not maintained, it is the same case as
mmc/sd cards. If power is maintained, mmc_power_up will not be called and
the card's signal voltage will remain at the last setting.
Signed-off-by: Aaron Lu <aaron.lu@amd.com>
Tested-by: Venkatraman S <svenkatr@ti.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
Romain Izard