summaryrefslogtreecommitdiffstats
path: root/drivers/mmc/core
Commit message (Collapse)AuthorAgeFilesLines
...
* mmc: core: use enum mmc_blk_status properlyLinus Walleij2016-11-291-17/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There were several instances of code using the enum mmc_blk_status by arbitrarily converting it to an int and throwing it around to different functions. This makes the code hard to understand to may give rise to strange errors. Especially the function prototype mmc_start_req() had to be modified to take a pointer to an enum mmc_blk_status and the function pointer .err_check() inside struct mmc_async_req needed to return an enum mmc_blk_status. In every case: instead of assigning the block layer error code to an int, use the enum, also change the signature of all functions actually passing this enum to use the enum. To make it possible to use the enum everywhere applicable, move it to <linux/mmc/core.h> so that all code actually using it can also see it. An interesting case was encountered in the MMC test code which did not return a enum mmc_blk_status at all in the .err_check function supposed to check whether asynchronous requests worked or not: instead it returned a normal -ERROR or even the test frameworks internal error codes. The test code would also pass on enum mmc_blk_status codes as error codes inside the test code instead of converting them to the local RESULT_* codes. I have tried to fix all instances properly and run some tests on the result. Cc: Chunyan Zhang <zhang.chunyan@linaro.org> Cc: Baolin Wang <baolin.wang@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: core: Don't power off the card when starting the hostUlf Hansson2016-11-291-5/+4
| | | | | | | | | | | | | | | | | | | | | | | The MMC_CAP2_NO_PRESCAN_POWERUP was invented to avoid running the power up sequence, mmc_power_up(), during ->probe() of the mmc host driver, but instead defer this to the mmc detect work. This is especially useful for those hosts that suffers from a long initialization time, as this time would otherwise add up to the total boot time. However, due to the introduction of runtime PM of mmc host devices in the mmc core, this behaviour changed a bit. More precisely, it caused the mmc core to runtime resume the host device during ->probe() of the host driver. In cases like the rtsx_usb_sdmmc, runtime resuming the device may be costly and thus affecting the total boot time. To improve this behaviour when using MMC_CAP2_NO_PRESCAN_POWERUP, let's postpone also calling mmc_power_off() when starting the host. This change allows the mmc core to avoid runtime resuming the device, as it don't need to claim the host for that execution path. Cc: Ritesh Raj Sarraf <rrs@researchut.com> Cc: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: core: expose the capability of gpio card detectShawn Lin2016-11-291-0/+8
| | | | | | | | | Add new helper API mmc_can_gpio_cd for slot-gpio to make host drivers know whether it supports gpio card detect. Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: core: Don't use ->card_busy() and CMD13 in combination when pollingUlf Hansson2016-11-291-16/+14
| | | | | | | | | | | | | | | | | When polling for busy after sending a MMC_SWITCH command, both the optional ->card_busy() callback and CMD13 are being used in conjunction. This doesn't make sense. Instead it's more reasonable to rely solely on the ->card_busy() callback when it exists. Let's change that and instead use the CMD13 as a fall-back. In this way we avoid sending CMD13, unless it's really needed. Within this context, let's also take the opportunity to make some additional clean-ups and clarifications to the related code. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Acked-by: Jaehoon Chung <jh80.chung@samsung.com> Tested-by: Jaehoon Chung <jh80.chung@samsung.com>
* mmc: core: Factor out code related to polling in __mmc_switch()Ulf Hansson2016-11-291-49/+59
| | | | | | | | | In yet another step of cleaning up __mmc_switch(), let's factor out the code that deals with card busy polling. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Acked-by: Jaehoon Chung <jh80.chung@samsung.com> Tested-by: Jaehoon Chung <jh80.chung@samsung.com>
* mmc: core: Clarify code which deals with polling in __mmc_switch()Ulf Hansson2016-11-291-21/+18
| | | | | | | | | | | | | The __mmc_switch() deserves a clean-up. In this step, let's move some code outside of the do-while loop, which deal deals with the card busy polling. This change simplifies the code in that sense that it becomes easier to follow what is being executed during card busy polling, but it also gives a better understanding for when polling isn't done. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Acked-by: Jaehoon Chung <jh80.chung@samsung.com> Tested-by: Jaehoon Chung <jh80.chung@samsung.com>
* mmc: core: Make mmc_switch_status() available for mmc coreUlf Hansson2016-11-293-15/+15
| | | | | | | | | | | | | | Following changes needs mmc_switch_status() to be available both from mmc.c and mmc_ops.c. Allow that by moving its implementation to mmc_ops.c and make it available via mmc_ops.h. Moving mmc_switch_status() to mmc_ops.c, also enables us to turn mmc_switch_status_error() into static function. So let's take the opportunity to change this as well. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Acked-by: Jaehoon Chung <jh80.chung@samsung.com> Tested-by: Jaehoon Chung <jh80.chung@samsung.com>
* mmc: mmc: Use 500ms as the default generic CMD6 timeoutUlf Hansson2016-11-071-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the eMMC 4.51 version of the spec, an EXT_CSD field called GENERIC_CMD6_TIME[248] was added. This allows cards to specify the maximum time it may need to move out from its busy state, when a CMD6 command has been sent. In cases when the card is compliant to versions < 4.51 of the eMMC spec, obviously the core needs to use a fall-back value for this timeout, which currently is set to 10 minutes. This value is completely in the wrong range and importantly in some cases it causes a card initialization to take more than 10 minute to complete. Earlier this scenario was avoided as the mmc core used CMD13 to poll the card, to find out when it stopped signaling busy. Commit 08573eaf1a70 ("mmc: mmc: do not use CMD13 to get status after speed mode switch") changed this behavior. Instead of reverting that commit, which would cause other issues, let's instead start by picking a simple solution for the problem, by using a 500ms default generic CMD6 timeout. The reason for using exactly 500ms, comes from observations that shows it's quite common for cards to specify 250ms. 500ms is two times that value so likely it should be enough for most cards. Cc: <stable@vger.kernel.org> # v4.8+ Fixes: 08573eaf1a70 ("mmc: mmc: do not use CMD13 to get status after speed mode switch") Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Tested-by: Stephen Boyd <sboyd@codeaurora.org> Tested-by: Linus Walleij <linus.walleij@linaro.org>
* mmc: core: changes frequency to hs_max_dtr when selecting hs400esShawn Lin2016-10-101-0/+2
| | | | | | | | | | | | | | | Per JESD84-B51 P49, Host need to change frequency to <=52MHz after setting HS_TIMING to 0x1, and host may changes frequency to <= 200MHz after setting HS_TIMING to 0x3. That means the card expects the clock rate to increase from the current used f_init (which is less than 400KHz, but still being less than 52MHz) to 52MHz, otherwise we find some eMMC devices significantly report failure when sending status. Reported-by: Xiao Yao <xiaoyao@rock-chips.com> Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: core: switch to 1V8 or 1V2 for hs400es modeShawn Lin2016-10-101-0/+10
| | | | | | | | | | | | | | | When introducing hs400es, I didn't notice that we haven't switched voltage to 1V2 or 1V8 for it. That happens to work as the first controller claiming to support hs400es, arasan(5.1), which is designed to only support 1V8. So the voltage is fixed to 1V8. But it actually is wrong, and will not fit for other host controllers. Let's fix it. Fixes: commit 81ac2af65793ecf ("mmc: core: implement enhanced strobe support") Cc: <stable@vger.kernel.org> Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: core: don't try to switch block size for dual rate modeZiyuan Xu2016-09-261-1/+2
| | | | | | | | | | Per spec, block size should always be 512 bytes for dual rate mode, so any attempts to switch the block size under dual rate mode should be neglected. Signed-off-by: Ziyuan Xu <xzy.xu@rock-chips.com> Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: core: Add support for sending commands during data transferAdrian Hunter2016-09-261-6/+89
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A host controller driver exposes its capability using caps flag MMC_CAP_CMD_DURING_TFR. A driver with that capability can accept requests that are marked mrq->cap_cmd_during_tfr = true. Then the driver informs the upper layers when the command line is available for further commands by calling mmc_command_done(). Because of that, the driver will not then automatically send STOP commands, and it is the responsibility of the upper layer to send a STOP command if it is required. For requests submitted through the mmc_wait_for_req() interface, the caller sets mrq->cap_cmd_during_tfr = true which causes mmc_wait_for_req() in fact not to wait. The caller can then send commands that do not use the data lines. Finally the caller can wait for the transfer to complete by calling mmc_wait_for_req_done() which is now exported. For requests submitted through the mmc_start_req() interface, the caller again sets mrq->cap_cmd_during_tfr = true, but mmc_start_req() anyway does not wait. The caller can then send commands that do not use the data lines. Finally the caller can wait for the transfer to complete in the normal way i.e. calling mmc_start_req() again. Irrespective of how a cap_cmd_during_tfr request is started, mmc_is_req_done() can be called if the upper layer needs to determine if the request is done. However the appropriate waiting function (either mmc_wait_for_req_done() or mmc_start_req()) must still be called. The implementation consists primarily of a new completion mrq->cmd_completion which notifies when the command line is available for further commands. That completion is completed by mmc_command_done(). When there is an ongoing data transfer, calls to mmc_wait_for_req() will automatically wait on that completion, so the caller does not have to do anything special. Note, in the case of errors, the driver may call mmc_request_done() without calling mmc_command_done() because mmc_request_done() always calls mmc_command_done(). Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: core: Optimize the mmc erase size alignmentBaolin Wang2016-09-261-8/+26
| | | | | | | | | | In most cases the 'card->erase_size' is power of 2, then the round_up/down() function is more efficient than '%' operation when the 'card->erase_size' is power of 2. Signed-off-by: Baolin Wang <baolin.wang@linaro.org> Tested-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: core: Factor out the alignment of erase sizeBaolin Wang2016-09-261-16/+32
| | | | | | | | | | In order to clean up the mmc_erase() function and do some optimization for erase size alignment, factor out the guts of erase size alignment into mmc_align_erase_size() function. Signed-off-by: Baolin Wang <baolin.wang@linaro.org> Tested-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: core: Use a default maximum erase timeoutUlf Hansson2016-09-261-7/+10
| | | | | | | | | | | | | | | | In cases when the host->max_busy_timeout isn't specified, the calculated number of maximum discard sectors defaults to UINT_MAX. This may cause a too long timeout for a discard request. Avoid this by using a default maximum erase timeout of 60s, used when we calculate the maximum number of sectors that are allowed to be discarded per request. Do note that the minimum number of sectors to be discarded is still at least one "preferred erase size". Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>
* mmc: sdio: deploy error handling instead of triggering BUG_ONShawn Lin2016-09-262-23/+33
| | | | | | | | | | | | | | | | | | | | | | When using mmc_io_rw_extended, it's intent to avoid null pointer of card and invalid func number. But actually it didn't prevent that as the seg_size already use the card. Currently the wrapper function sdio_io_rw_ext_helper already use card before calling mmc_io_rw_extended, so we should move this check to there. As to the func number, it was token from '(ocr & 0x70000000) >> 28' which should be enough to guarantee that it won't be larger than 7. But we should prevent the caller like wifi drivers modify this value. So let's move this check into sdio_io_rw_ext_helper either. Also we remove the BUG_ON for mmc_send_io_op_cond since all possible paths calling this function are protected by checking the arguments in advance. After deploying these changes, we could not see any panic within SDIO API even if func drivers abuse the SDIO func APIs. Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: core: Add error message when switching fails in mmc_select_hs()Jungseung Lee2016-09-261-4/+5
| | | | | | | | | | | | | The switch failure message in mmc_select_timing() had been removed since that is invalid: commit 0400ed0a083a ("mmc: core: remove the invalid message in mmc_select_timing") Now, in the case when mmc_select_hs() return error in mmc_select_timing(), there is nothing to print failure message. Let's make for mmc_select_hs() print message itself in the failure case. Signed-off-by: Jungseung Lee <js07.lee@samsung.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: sd: Export SD Status via “ssr” device attributeUri Yanai2016-09-261-18/+19
| | | | | | | | | | | | | The SD Status register contains several important fields related to the SD Card proprietary features. Those fields may be used by user space applications for vendor specific usage. None of those fields are exported today by the driver to user space. In this patch, we are reading the SD Status register and exporting (using MMC_DEV_ATTR) the SD Status register to the user space. Signed-off-by: Uri Yanai <uri.yanai@sandisk.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: pwrseq-simple: Add an optional post-power-on-delayHans de Goede2016-09-261-0/+9
| | | | | | | | | | | | Some devices need a while to boot their firmware after providing clks / de-asserting resets before they are ready to receive sdio commands. This commits adds a post-power-on-delay-ms devicetree property to mmc-pwrseq-simple for use with such devices. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: Change the max discard sectors and erase response when HW busy detectBaolin Wang2016-07-251-10/+50
| | | | | | | | | | | | | | | When mmc host HW supports busy signalling (using R1B as response), don't use the host->max_busy_timeout as the limitation when deciding the max discard sectors, which we inform the generic BLOCK layer about. Instead, let's use at least one preferred erase size as the max discard sectors. In cases when the host controller supports HW busy signalling and the timeout for the erase operation doesn't exceed the max_busy_timeout, we keep the R1B response, otherwise we prevent the host from doing HW busy detection by converting to a R1 response. Signed-off-by: Baolin Wang <baolin.wang@linaro.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: core: Extend sysfs with DSR registerBojan Prtvar2016-07-252-0/+34
| | | | | | | | Export DSR register through sysfs same as we did for the CID, CSD and OCR registers. Signed-off-by: Bojan Prtvar <prtvar.b@gmail.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: core: expose MMC_CAP2_NO_* to dtShawn Lin2016-07-251-0/+6
| | | | | | | | | The reason for why we expose these to dt is that some of the controller is unable to send special cmd type due to the hw limitation. Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: core: Extend sysfs with OCR registerBojan Prtvar2016-07-252-0/+4
| | | | | | | | | Registers CID and CSD are already exported through sysfs so let's make this interface complete by adding missing OCR register. Signed-off-by: Bojan Prtvar <prtvar.b@gmail.com> Reviewed-by: Wolfram Sang <wsa@the-dreams.de> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: core: Allow hosts to specify non-support for MMC commandsShawn Lin2016-07-251-2/+3
| | | | | | | | | | | | Host drivers which needs to valdiate for non-supported MMC commands and returnn error code for such requests. To improve and simplify the behaviour, let's invent MMC_CAP2_NO_MMC which these host drivers can set to tell the mmc core to skip sending MMC commands during card initialization. Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: core: Allow hosts to specify non-support for SD commandsUlf Hansson2016-07-251-3/+6
| | | | | | | | | | | There are host drivers which needs to valdiate for non-supported SD commands and returnn error code for such requests. To improve and simplify the behaviour, let's invent MMC_CAP2_NO_SD which these host drivers can set to tell the mmc core to skip sending SD commands during card initialization. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: core: Disable HPI for certain Hynix eMMC cardsPratibhasagar V2016-07-252-3/+22
| | | | | | | | | | | | | | Certain Hynix eMMC 4.41 cards might get broken when HPI feature is used and hence this patch disables the HPI feature for such buggy cards. As some of the other features like BKOPs/Cache/Sanitize are dependent on HPI feature, those features would also get disabled if HPI is disabled. Signed-off-by: Pratibhasagar V <pratibha@codeaurora.org> Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org> [gdavis: Forward port and cleanup] Signed-off-by: George G. Davis <george_davis@mentor.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: core: Only change mode if mmc_select_bus_width() is successfulPeter Griffin2016-07-251-2/+2
| | | | | | | | | mmc_select_bus_width() returns bus width (4 or 8) on success or zero if unsupported. So only change mode if setting the bus width is successful. Signed-off-by: Peter Griffin <peter.griffin@linaro.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: Set pref erase size based on sizeGwendal Grignou2016-07-251-7/+5
| | | | | | | | | | | | | If available, eMMC stack uses HC_ERASE_GRP_SIZE as the preferred erase size. As some high capacity eMMC (64MB) reports this size to 512kB, the discard operations end up taking very long time. Improve the behaviour by instead calculating the preferred erase size based on the eMMC size. In this way the discard operations becomes faster. Signed-off-by: Gwendal Grignou <gwendal@chromium.org> [Ulf: Updated changelog and improved comment in code] Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: mmc: Fix HS switch failure in mmc_select_hs400()Ziyuan Xu2016-07-251-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | To slove the issue which was found on gru board for hs400. [ 4.616946] sdhci: Secure Digital Host Controller Interface driver [ 4.623135] sdhci: Copyright(c) Pierre Ossman [ 4.722575] sdhci-pltfm: SDHCI platform and OF driver helper [ 4.730962] sdhci-arasan fe330000.sdhci: No vmmc regulator found [ 4.737444] sdhci-arasan fe330000.sdhci: No vqmmc regulator found [ 4.774930] mmc0: SDHCI controller on fe330000.sdhci [fe330000.sdhci] using ADMA [ 4.980295] mmc0: switch to high-speed from hs200 failed, err:-84 [ 4.986487] mmc0: error -84 whilst initialising MMC card We should change HS400 mode selection timing to meet JEDEC specification. The JEDEC 5.1 said that change the frequency to <= 52MHZ after HS_TIMING switch. Refer to section 6.6.2.3 "HS400" timing mode selection: Set the "Timing Interface" parameter in the HS_TIMING[185] field of the Extended CSD register to 0x1 to switch to High Speed mode and then set the clock frequency to a value not greater than 52MHZ. Signed-off-by: Ziyuan Xu <xzy.xu@rock-chips.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: mmc: fix switch timeout issue caused by jiffies precisionChaotian Jing2016-07-251-1/+1
| | | | | | | | | with CONFIG_HZ=100, the precision of jiffies is 10ms, and the generic_cmd6_time of some card is also 10ms. then, may be current time is only 5ms, but already timed out caused by jiffies precision. Signed-off-by: Chaotian Jing <chaotian.jing@mediatek.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: mmc: do not use CMD13 to get status after speed mode switchChaotian Jing2016-07-251-68/+47
| | | | | | | | | | | | | Per JEDEC spec, it is not recommended to use CMD13 to get card status after speed mode switch. below are two reason about this: 1. CMD13 cannot be guaranteed due to the asynchronous operation. Therefore it is not recommended to use CMD13 to check busy completion of the timing change indication. 2. After switch to HS200, CMD13 will get response of 0x800, and even the busy signal gets de-asserted, the response of CMD13 is aslo 0x800. Signed-off-by: Chaotian Jing <chaotian.jing@mediatek.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: mmc: Use ->card_busy() to detect busy cards in __mmc_switch()Chaotian Jing2016-07-251-9/+16
| | | | | | | | | Some MMC hosts do not support MMC_CAP_WAIT_WHILE_BUSY, but implements the ->card_busy() callback. In such cases, extend __mmc_switch() to use this method to check card status after switch command. Signed-off-by: Chaotian Jing <chaotian.jing@mediatek.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: debugfs: add HS400 enhanced strobe descriptionShawn Lin2016-07-251-1/+2
| | | | | | | | | | | | We introduce HS400 with enhanced strobe function, so we need to add it for debug show. Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Tested-by: Douglas Anderson <dianders@chromium.org> Tested-by: Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: core: implement enhanced strobe supportShawn Lin2016-07-253-3/+93
| | | | | | | | | | | | | | | | | Controllers use data strobe line to latch data from devices under hs400 mode, but not for cmd line. So since emmc 5.1, JEDEC introduces enhanced strobe mode for latching cmd response from emmc devices to host controllers. This new feature is optional, so it depends both on device's cap and host's cap to decide whether to use it or not. Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com> Tested-by: Douglas Anderson <dianders@chromium.org> Tested-by: Jaehoon Chung <jh80.chung@samsung.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: core: add mmc-hs400-enhanced-strobe supportShawn Lin2016-07-251-0/+2
| | | | | | | | | | | | This patch introduce mmc-hs400-enhanced-strobe for platforms which want to enable enhanced strobe function from DT if the mmc host controller claims to support enhanced strobe. Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Tested-by: Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: fix mmc mode selection for HS-DDR and higherChen-Yu Tsai2016-06-021-2/+2
| | | | | | | | | | | | | | | | | | | | When IS_ERR_VALUE was removed from the mmc core code, it was replaced with a simple not-zero check. This does not work, as the value checked is the return value for mmc_select_bus_width, which returns the set bit width on success. This made eMMC modes higher than HS-DDR unusable. Fix this by checking for a positive return value instead. Fixes: 287980e49ffc ("remove lots of IS_ERR_VALUE abuses") Cc: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Chen-Yu Tsai <wens@csie.org> Acked-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Acked-by: Jaehoon Chung <jh80.chung@samsung.com> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com> Tested-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* remove lots of IS_ERR_VALUE abusesArnd Bergmann2016-05-271-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Most users of IS_ERR_VALUE() in the kernel are wrong, as they pass an 'int' into a function that takes an 'unsigned long' argument. This happens to work because the type is sign-extended on 64-bit architectures before it gets converted into an unsigned type. However, anything that passes an 'unsigned short' or 'unsigned int' argument into IS_ERR_VALUE() is guaranteed to be broken, as are 8-bit integers and types that are wider than 'unsigned long'. Andrzej Hajda has already fixed a lot of the worst abusers that were causing actual bugs, but it would be nice to prevent any users that are not passing 'unsigned long' arguments. This patch changes all users of IS_ERR_VALUE() that I could find on 32-bit ARM randconfig builds and x86 allmodconfig. For the moment, this doesn't change the definition of IS_ERR_VALUE() because there are probably still architecture specific users elsewhere. Almost all the warnings I got are for files that are better off using 'if (err)' or 'if (err < 0)'. The only legitimate user I could find that we get a warning for is the (32-bit only) freescale fman driver, so I did not remove the IS_ERR_VALUE() there but changed the type to 'unsigned long'. For 9pfs, I just worked around one user whose calling conventions are so obscure that I did not dare change the behavior. I was using this definition for testing: #define IS_ERR_VALUE(x) ((unsigned long*)NULL == (typeof (x)*)NULL && \ unlikely((unsigned long long)(x) >= (unsigned long long)(typeof(x))-MAX_ERRNO)) which ends up making all 16-bit or wider types work correctly with the most plausible interpretation of what IS_ERR_VALUE() was supposed to return according to its users, but also causes a compile-time warning for any users that do not pass an 'unsigned long' argument. I suggested this approach earlier this year, but back then we ended up deciding to just fix the users that are obviously broken. After the initial warning that caused me to get involved in the discussion (fs/gfs2/dir.c) showed up again in the mainline kernel, Linus asked me to send the whole thing again. [ Updated the 9p parts as per Al Viro - Linus ] Signed-off-by: Arnd Bergmann <arnd@arndb.de> Cc: Andrzej Hajda <a.hajda@samsung.com> Cc: Andrew Morton <akpm@linux-foundation.org> Link: https://lkml.org/lkml/2016/1/7/363 Link: https://lkml.org/lkml/2016/5/27/486 Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> # For nvmem part Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* mmc: longer timeout for long read time quirkMatt Gumbel2016-05-231-2/+2
| | | | | | | | | | | | | | | | | | 008GE0 Toshiba mmc in some Intel Baytrail tablets responds to MMC_SEND_EXT_CSD in 450-600ms. This patch will... () Increase the long read time quirk timeout from 300ms to 600ms. Original author of that quirk says 300ms was only a guess and that the number may need to be raised in the future. () Add this specific MMC to the quirk Signed-off-by: Matt Gumbel <matthew.k.gumbel@intel.com> Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: core: Add a facility to "pause" re-tuningAdrian Hunter2016-05-171-0/+24
| | | | | | | | | | | | | | | | | | | | | | Re-tuning is not possible when switched to the RPMB partition. However re-tuning should not be needed if re-tuning is done immediately before switching, a small set of operations is done, and then we immediately switch back to the main partition. To ensure that re-tuning can't be done for a short while, add a facility to "pause" re-tuning. The existing facility to hold / release re-tuning is used but it also flags re-tuning as needed to cause re-tuning before the next command (which will be the switch to RPMB). We also need to "unpause" in the recovery path, which is catered for by adding it to mmc_retune_disable(). Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: mmc: Fix partition switch timeout for some eMMCsAdrian Hunter2016-05-161-0/+7
| | | | | | | | | | | | | | | | | | | | | | Some eMMCs set the partition switch timeout too low. Now typically eMMCs are considered a critical component (e.g. because they store the root file system) and consequently are expected to be reliable. Thus we can neglect the use case where eMMCs can't switch reliably and we might want a lower timeout to facilitate speedy recovery. Although we could employ a quirk for the cards that are affected (if we could identify them all), as described above, there is little benefit to having a low timeout, so instead simply set a minimum timeout. The minimum is set to 300ms somewhat arbitrarily - the examples that have been seen had a timeout of 10ms but were sometimes taking 60-70ms. Cc: stable@vger.kernel.org Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: sdio: fall back to SDIO 1.0 for broken 1.1 cardsWolfram Sang2016-05-161-1/+6
| | | | | | | | | | | I have two SDIO WLAN cards which specify being SDIO Rev. 1.1 cards but their FUNCE tuple reports the smaller size of a Rev 1.0 card. So, enforce 1.0 on these cards to avoid reading the not present registers. They are not really used anyhow. My cards initialize properly after this patch. Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: core: remove the invalid message in mmc_select_timingDong Aisheng2016-05-101-9/+1
| | | | | | | | | | | | | | | | | | mmc_select_hs200() and mmc_select_hs() will keep the timing as before if switch fails. So it's meaningless to print the failed switched mode outside based on the current host timing. Furthermore, the original print is wrong, it should be: pr_warn("%s: switch to %s failed\n", mmc_hostname(card->host), mmc_card_hs(card) ? "high-speed" : (mmc_card_hs200(card) ? "hs200" : "")); Since we already have error message in mmc_select_hs200(), simply remove it outside. Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: core: fix using wrong io voltage if mmc_select_hs200 failsDong Aisheng2016-05-101-3/+9
| | | | | | | | | | | | | | | Currently MMC core will keep going if HS200/HS timing switch failed with -EBADMSG error by the assumption that the old timing is still valid. However, for mmc_select_hs200 case, the signal voltage may have already been switched. If the timing switch failed, we should fall back to the old voltage in case the card is continue run with legacy timing. If fall back signal voltage failed, we explicitly report an EIO error to force retry during the next power cycle. Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: mmc: Attempt to flush cache before resetAdrian Hunter2016-05-041-0/+6
| | | | | | | | | | | CMD0 or hardware reset may invalidate the cache, so it needs to be flushed before reset. In the case of recovery, we can't expect flushing the cache to work always, but have a go and ignore errors. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: core: Convert from IDR to IDA for host indexesUlf Hansson2016-05-021-8/+14
| | | | | | As IDA is more lightweight than IDR, let's convert to use that instead. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: core: drop unnecessary bit checkingMasahiro Yamada2016-05-021-2/+3
| | | | | | | | | | This if-block is going to call mmc_card_set_blockaddr(), so mmc_card_blockaddr() right before it is redundant. I am fixing the block comment style while I am here. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: pwrseq: convert to proper platform deviceSrinivas Kandagatla2016-05-026-129/+177
| | | | | | | | | | | | | | | | | | | simple-pwrseq and emmc-pwrseq drivers rely on platform_device structure from of_find_device_by_node(), this works mostly. But, as there is no driver associated with this devices, cases like default/init pinctrl setup would never be performed by pwrseq. This becomes problem when the gpios used in pwrseq require pinctrl setup. Currently most of the common pinctrl setup is done in drivers/base/pinctrl.c by pinctrl_bind_pins(). There are two ways to solve this issue on either convert pwrseq drivers to a proper platform drivers or copy the exact code from pcintrl_bind_pins(). I prefer converting pwrseq to proper drivers so that other cases like setting up clks/parents from dt would also be possible. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: pwrseq_emmc: add to_pwrseq_emmc() macroSrinivas Kandagatla2016-05-021-4/+4
| | | | | | | This patch adds to_pwrseq_emmc() macro to make the code more readable. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: pwrseq_simple: add to_pwrseq_simple() macroSrinivas Kandagatla2016-05-021-8/+6
| | | | | | | This patch adds to_pwrseq_simple() macro to make the code more readable. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: core: Do regular power cycle when lacking eMMC HW reset supportGwendal Grignou2016-05-022-15/+14
| | | | | | | | | | | | | | | The eMMC HW reset may be implemented either via the host ops ->hw_reset() callback or through DT and the eMMC pwrseq. Additionally some eMMC cards don't support HW reset. To allow a reset to be done for the different combinations of mmc hosts and eMMC/MMC cards, let's implement a fallback via trying a regular power cycle. This improves the mmc block layer retry mechanism of failing I/O requests. Signed-off-by: Gwendal Grignou <gwendal@chromium.org> [Ulf: Rewrote changelog] Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
OpenPOWER on IntegriCloud