- 25 Jul, 2016 40 commits
-
-
Seung-Woo Kim authored
This patch removes following UBSAN warnings in dw_mci_setup_bus(). UBSAN: Undefined behaviour in drivers/mmc/host/dw_mmc.c:1102:14 shift exponent 250 is too large for 32-bit type 'unsigned int' Call trace: [<ffffff90080908a8>] dump_backtrace+0x0/0x380 [<ffffff9008090c3c>] show_stack+0x14/0x20 [<ffffff90087457b8>] dump_stack+0xe0/0x120 [<ffffff90087b1360>] ubsan_epilogue+0x18/0x68 [<ffffff90087b1a94>] __ubsan_handle_shift_out_of_bounds+0x18c/0x1bc [<ffffff9008d89cb8>] dw_mci_setup_bus+0x3a0/0x438 [...] UBSAN: Undefined behaviour in drivers/mmc/host/dw_mmc.c:1132:27 shift exponent 250 is too large for 32-bit type 'unsigned int' Call trace: [<ffffff90080908a8>] dump_backtrace+0x0/0x380 [<ffffff9008090c3c>] show_stack+0x14/0x20 [<ffffff90087457b8>] dump_stack+0xe0/0x120 [<ffffff90087b1360>] ubsan_epilogue+0x18/0x68 [<ffffff90087b1a94>] __ubsan_handle_shift_out_of_bounds+0x18c/0x1bc [<ffffff9008d89c9c>] dw_mci_setup_bus+0x384/0x438 [...] The warnings are caused because of bit shift which is used to filter spamming message for CONFIG_MMC_CLKGATE, but the config is already removed. So this patch just removes the shift. Signed-off-by:
Seung-Woo Kim <sw0312.kim@samsung.com> Signed-off-by:
Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org>
-
Doug Anderson authored
According to the DesignWare state machine description, after we get a "response error" or "response CRC error" we move into data transfer mode. That means that we don't necessarily need to special case trying to deal with the failure right away. We can wait until we are notified that the data transfer is complete (with or without errors) and then we can deal with the failure. It may sound strange to defer dealing with a command that we know will fail anyway, but this appears to fix a bug. During tuning (CMD19) on a specific card on an rk3288-based system, we found that we could get a "response CRC error". Sending the stop command after the "response CRC error" would then throw the system into a confused state causing all future tuning phases to report failure. When in the confused state, the controller would show these (hex codes are interrupt status register): CMD ERR: 0x00000046 (cmd=19) CMD ERR: 0x0000004e (cmd=12) DATA ERR: 0x00000208 DATA ERR: 0x0000020c CMD ERR: 0x00000104 (cmd=19) CMD ERR: 0x00000104 (cmd=12) DATA ERR: 0x00000208 DATA ERR: 0x0000020c ... ... It is inherently difficult to deal with the complexity of trying to correctly send a stop command while a data transfer is taking place since you need to deal with different corner cases caused by the fact that the data transfer could complete (with errors or without errors) during various places in sending the stop command (dw_mci_stop_dma, send_stop_abort, etc) Instead of adding a bunch of extra complexity to deal with this, it seems much simpler to just use the more straightforward (and less error-prone) path of letting the data transfer finish. There shouldn't be any huge benefit to sending the stop command slightly earlier, anyway. Signed-off-by:
Doug Anderson <dianders@chromium.org> Signed-off-by:
Enric Balletbo i Serra <enric.balletbo@collabora.com> Cc: Alim Akhtar <alim.akhtar@gmail.com> Signed-off-by:
-
Ben Dooks authored
The IDMAC_SET_BUFFER1_SIZE() macro modifies des1, but does not check if the value being passed is big or little endian desptire the des1 field being marked as __le32. Fix the issue by ensuring the values are changed from the cpu endian to the descriptor endian by using cpu_to_le32. Spotted whilst doing big endian conversion work on Exynos, and stops the mmc worker thread from stalling. Signed-off-by:
Ben Dooks <ben.dooks@codethink.co.uk> Reviewed-by:
Shawn Lin <shawn.lin@rock-chips.com> Tested-by:
-
Doug Anderson authored
The dw_mmc driver enables HLE errors as part of DW_MCI_ERROR_FLAGS but nothing in the interrupt handler actually handles them and ACKs them. That means that if we ever get an HLE error we'll just keep getting interrupts and we'll wedge things. We really don't expect HLE errors but if we ever get them we shouldn't silently ignore them. Note that I have seen HLE errors while constantly ejecting and inserting cards (ejecting while inserting, etc). Signed-off-by:
-
Jérôme Forissier authored
Enables RPMB support for the on-board eMMC of the HiKey board as well as for eMMC modules connected to the microSD slot. Signed-off-by:
Jerome Forissier <jerome.forissier@linaro.org> Signed-off-by:
-
Shawn Lin authored
The main reason to add this check is to avoid unnecessary mmc_request like the on-going cmd and the corresponding sbc if the card is removed. Although we have already checked this in dw_mci_handle_cd for runtime usage of sd card and dw_mci_init_slot for noremovable devices, but there is a timing gap before it really calls dw_mci_get_cd as mmc_detect_change needs some delay here. Another gain here is that we could save some checkings of card status after sd card been removed. Signed-off-by:
-
Shawn Lin authored
dw_mci_get_cd have already dealt with these for both of internal card-detect and gpio card-detect. Signed-off-by:
-
Ulf Hansson authored
The current value means an mdelay(1) may execute up to 10000000 times, which translates to around ~2.8 hours. This is probably not what the orignal author had in mind. Let's instead use 10s, which is the same value sh_mmcif is using for other timeouts. Signed-off-by: -
Ulf Hansson authored
The sh_mmcif driver is already using a 10s request timeout. Let's also inform the mmc core about this value, as there are situations when it needs to know about it. Signed-off-by: -
Ulf Hansson authored
The sh_mmcif explicity checks for certain commands to decide when to enable HW busy detection. Instead, it should only check the response type as it tells if busy detection is needed. In this way, the mmc core also gets full control whether it thinks busy detection should be done or not. In some specific scenarios, like for ERASE and STOP commands it may decide to fall back to use a CMD13 to poll the card status instead. Signed-off-by: -
Ulf Hansson authored
Enable the capabilities which tells the mmc core to prevent sending SD and SDIO commands during card initialization. In this way, we can also remove the validation of non-supported commands in the ->request() callback. Signed-off-by: -
Ulf Hansson authored
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: -
Colin Ian King authored
trivial fix to spelling mistake in dev_err message Signed-off-by:
Colin Ian King <colin.king@canonical.com> Acked-by:
Adrian Hunter <adrian.hunter@intel.com> Signed-off-by:
-
Chuanxiao Dong authored
sdhci_dumpregs is used to dump registers when error happens. Thus it should use pr_err instead of pr_debug to show more information about the hardware. Signed-off-by:
Chuanxiao Dong <chuanxiao.dong@intel.com> [Fix whitespace and checkpatch warnings] Signed-off-by:
-
Jaehoon Chung authored
In linux/mmc/host.h, mmc_card_is_removable() is already defined. It should be maintainted more easier than now. Signed-off-by:
-
Douglas Anderson authored
The "phyctrl_frqsel" is described in the Arasan datasheet [1] as "the frequency range of DLL operation". Although the Rockchip variant of this PHY has different ranges than the reference Arasan PHY it appears as if the functionality is similar. We should set this phyctrl field properly. Note: as per Rockchip engineers, apparently the "phyctrl_frqsel" is actually only useful in HS200 / HS400 modes even though the DLL itself it used for some purposes in all modes. See the discussion in the earlier change in this series: ("mmc: sdhci-of-arasan: Always power the PHY off/on when clock changes"). In any case, it shouldn't hurt to set this always. Note that this change should allow boards to run at HS200 / HS400 speed modes while running at 100 MHz or 150 MHz. In fact, running HS400 at 150 MHz (giving 300 MB/s) is the main motivation of this series, since performance is still good but signal integrity problems are less prevelant at 150 MHz. [1]: https://arasan.com/wp-content/media/eMMC-5-1-Total-Solution_Rev-1-3.pdfSigned-off-by:Kishon Vijay Abraham I <kishon@ti.com> Reviewed-by:
Heiko Stuebner <heiko@sntech.de> Signed-off-by:
-
Douglas Anderson authored
There's no reason to store the return value of rockchip_emmc_phy_power() in a variable nor to check it. Just return it. Signed-off-by:
-
Douglas Anderson authored
As of an earlier change in this series ("Documentation: mmc: sdhci-of-arasan: Add ability to export card clock") the SDHCI driver used on Rockchip SoCs can now expose its clock. Let's now specify that the PHY can use it. Letting the PHY get access to this clock means it can adjust phyctrl_frqsel field appropriately. Although the Rockchip PHY appears slightly different than the reference Arasan one, you can see that the Arasan datasheet [1] had it defined as: Select the frequency range of DLL operation: 3b'000 => 200MHz to 170 MHz 3b'001 => 170MHz to 140 MHz 3b'010 => 140MHz to 110 MHz 3b'011 => 110MHz to 80MHz 3b'100 => 80MHz to 50 MHz 3b'101 => 275Mhz to 250MHz 3b'110 => 250MHz to 225MHz 3b'111 => 225MHz to 200MHz On the Rockchip version of the PHY we have less granularity but the idea is the same. [1]: https://arasan.com/wp-content/media/eMMC-5-1-Total-Solution_Rev-1-3.pdfSigned-off-by:Rob Herring <robh@kernel.org> Reviewed-by:
-
Douglas Anderson authored
Some SD/eMMC PHYs (like the PHY from Arasan that is designed to work with arasan,sdhci-5.1) need to know the card clock in order to function properly. Let's add the ability to expose this clock. Any PHY that needs to know the clock rate can add a reference and query the clock rate. At the moment we register a CLK_GET_RATE_NOCACHE clock that simply allows querying the clock. This allows us to be less intrusive with regards to the main SDHCI driver, which has complex logic for adjusting the SD clock. Right now we always fully power cycle the PHY when the clock changes and that gives the PHY a good chance to query our clock. Signed-off-by:
-
Douglas Anderson authored
Some SD/eMMC PHYs (like the PHY from Arasan that is designed to work with arasan,sdhci-5.1) need to know the card clock frequency in order to function properly. Physically in a SoC this clock is exported from the SDHCI IP block to the PHY IP block and the PHY needs to know the speed. Let's export the SDHCI card clock using a standard device tree mechanism so that the PHY can get access to it and query the card clock frequency. Signed-off-by:
-
Douglas Anderson authored
In the the earlier change in this series ("Documentation: mmc: sdhci-of-arasan: Add soc-ctl-syscon for corecfg regs") we can see the mechansim for specifying a syscon to properly set corecfg registers in sdhci-of-arasan. Now let's use this mechanism to properly set corecfg_baseclkfreq on rk3399. >From [1] the corecfg_baseclkfreq is supposed to be set to: Base Clock Frequency for SD Clock. This is the frequency of the xin_clk. This is a relatively easy thing to do. Note that we assume that xin_clk is not dynamic and we can check the clock at probe time. If any real devices have a dynamic xin_clk future patches could register for notifiers for the clock. At the moment, setting corecfg_baseclkfreq is only supported for rk3399 since we need a specific map for each implementation. The code is written in a generic way that should make this easy to extend to other SoCs. Note that a specific compatible string for rk3399 is already in use and so we add that to the table to match rk3399. [1]: https://arasan.com/wp-content/media/eMMC-5-1-Total-Solution_Rev-1-3.pdfSigned-off-by: -
Douglas Anderson authored
As can be seen in Arasan's datasheet [1] there are several "corecfg" settings in their SDHCI IP Block that are supposed to be controlled by software. Although the datasheet referenced is a bit vague about how to access corecfg, in Figure 5 you can see that for Arasan's PHY (a separate component than their SDHCI component) they describe the "phyctrl" registers as being "FROM SOC CTL REG", implying that it's up to the licensee of the Arasan IP block to implement these registers. It seems sane to assume that the "corecfg" registers in their SDHCI IP block works in a similar way for all licensees of the IP Block. Device tree has a model that allows a device to get a reference to random registers located elsewhere in the SoC: sysctl. Let's leverage this model and allow adding a sysctl reference to access the control registers for the Arasan SDHCI PHYs. Having a reference to the control registers doesn't do much for us on its own since the Arasan spec doesn't specify how these corecfg values are laid out in memory. In the SDHCI driver we'll need a map detailing where each corecfg can be found in each implementation. This map can be found using the primary compatible string of the SDHCI device. In that spirit, document that existing rk3399 device trees already have a specific compatible string, though up to now they've always been relying on the driver supporting the generic. Note that since existing devices seem to work fairly well as-is, we'll list the syscon reference as "optional", but it's likely that we'll run into much fewer problems if we can actually set the proper values in the syscon, so it is strongly suggested that any SoCs where we have a map to set the corecfg also include a reference to the syscon. [1]: https://arasan.com/wp-content/media/eMMC-5-1-Total-Solution_Rev-1-3.pdfSigned-off-by:
-
Douglas Anderson authored
In commit 802ac39a ("mmc: sdhci-of-arasan: fix set_clock when a phy is supported") we added code to power the PHY off and on whenever the clock was changed but we avoided doing the power cycle code when the clock was low speed. Let's now do it always. Although there may be other reasons for power cycling the PHY when the clock changes, one of the main reasons is that we need to give the DLL a chance to re-lock with the new clock. One of the things that the DLL is for is tuning the Receive Clock in HS200 mode and STRB in HS400 mode. Thus it is clear that we should make sure we power cycle the PHY (and wait for the DLL to lock) when we know we'll be in one of these two speed modes. That's what the original code did, though it used the clock rate rather than the speed mode. However, even in speed modes other than HS200,/HS400 the DLL is used for something since it can be clearly observed that the PHY doesn't function properly if you leave the DLL off. Although it appears less important to power cycle the PHY and wait for the DLL to lock when not in HS200/HS400 modes (no bugs were reported), it still seems wise to let the locking always happen nevertheless. Note: as part of this, we make sure that we never try to turn the PHY on when the clock is off (when the clock rate is 0). The PHY cannot work when the clock is off since its DLL can't lock. This change requires ("phy: rockchip-emmc: Increase lock time allowance") and will cause problems if picked without that change. Signed-off-by:
-
Douglas Anderson authored
Previous PHY code waited a fixed amount of time for the DLL to lock at power on time. Unfortunately, the time for the DLL to lock is actually a bit more dynamic and can be longer if the card clock is slower. Instead of waiting a fixed 30 us, let's now dynamically wait until the lock bit gets set. We'll wait up to 10 ms which should be OK even if the card clock is at the super slow 100 kHz. On its own, this change makes the PHY power on code a little more robust. Before this change the PHY was relying on the eMMC code to make sure the PHY was only powered on when the card clock was set to at least 50 MHz before, though this reliance wasn't documented anywhere. This change will be even more useful in future changes where we actually need to be able to wait for a DLL lock at slower clock speeds. Signed-off-by:
-
Brian Norris authored
Some of the spacing was wrong (spaces instead of tabs), and due to longer entries added later, the columns weren't aligned. Let's get everything consistent. Signed-off-by:
Brian Norris <briannorris@chromium.org> Signed-off-by:
-
Brian Norris authored
The output tap delay controls helps maintain the hold requirements for eMMC. The exact value is dependent on the SoC and other factors, though it isn't really an exact science. But the default of 0 is not very good, as it doesn't give the eMMC much hold time, so let's bump up to 4 (approx 90 degree phase?). If we need to configure this any further (e.g., based on board or speed factors), we may need to consider a device tree representation. Suggested-by:
-
Shawn Lin authored
Signal integrity analysis has suggested we set these values. Do this in power_on(), so that they get reconfigured after suspend/resume. Signed-off-by:
-
Shawn Lin authored
According to the databook, 10.2us is the max time for dll to be ready to work. However in testing, some chips need 20us for dll to be ready. This patch adds some extra margin for dllrdy to be ready, fixing our -ETIMEDOUT issues. Signed-off-by:
-
Al Cooper authored
Add SDHCI driver for Broadcom BRCMSTB SoCs. This driver works with all ARM based SoCs and the 7425, 7429 and 7435 MIPS based SoCs. The driver disables all UHS speed modes by default and relies on the Device Tree node properties to enable these modes for SoC/Board combinations that support them. Signed-off-by:
Al Cooper <alcooperx@gmail.com> Acked-by:
-
Al Cooper authored
The example includes the properties required to enable UHS modes. Signed-off-by:
-
Adrian Hunter authored
Apparently a cut-and-paste error, 'do_data_tag' is using 'brq' for data size even though 'brq' has not been set up. Instead use blk_rq_sectors(). Signed-off-by:
-
Pratibhasagar V authored
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:
-
Peter Griffin authored
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:
-
Gwendal Grignou authored
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:
-
Stefan Wahren authored
The sdhci-bcm2835 is no more needed since it has been replaced by sdhci-iproc. Signed-off-by:
Stefan Wahren <stefan.wahren@i2se.com> Acked-by:
Eric Anholt <eric@anholt.net> Signed-off-by:
-
Stefan Wahren authored
The sdhci-iproc also supports bcm2835. So this binding is obsolete. Signed-off-by:
Stephen Warren <swarren@wwwdotorg.org> Signed-off-by:
-
Ziyuan Xu authored
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:
-
Chaotian Jing authored
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:
-
Chaotian Jing authored
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 authored
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:
-
