An error occurred fetching the project authors.
- 09 Jul, 2018 1 commit
-
-
Stefan Agner authored
If pinctrl nodes for 100/200MHz are missing, the controller should not select any mode which need signal frequencies 100MHz or higher. To prevent such speed modes the driver currently uses the quirk flag SDHCI_QUIRK2_NO_1_8_V. This works nicely for SD cards since 1.8V signaling is required for all faster modes and slower modes use 3.3V signaling only. However, there are eMMC modes which use 1.8V signaling and run below 100MHz, e.g. DDR52 at 1.8V. With using SDHCI_QUIRK2_NO_1_8_V this mode is prevented. When using a fixed 1.8V regulator as vqmmc-supply the stack has no valid mode to use. In this tenuous situation the kernel continuously prints voltage switching errors: mmc1: Switching to 3.3V signalling voltage failed Avoid using SDHCI_QUIRK2_NO_1_8_V and prevent faster modes by altering the SDHCI capability register. With that the stack is able to select 1.8V modes even if no faster pinctrl states are available: # cat /sys/kernel/debug/mmc1/ios ... timing spec: 8 (mmc DDR52) signal voltage: 1 (1.80 V) ... Link: http://lkml.kernel.org/r/20180628081331.13051-1-stefan@agner.chSigned-off-by:
Stefan Agner <stefan@agner.ch> Fixes: ad93220d ("mmc: sdhci-esdhc-imx: change pinctrl state according to uhs mode") Cc: <stable@vger.kernel.org> # v4.13+ Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org>
-
- 02 May, 2018 1 commit
-
-
Andrew Gabbasov authored
While performing R/W access in PIO mode, the common SDHCI driver checks the buffer ready status once per whole block processing. That is, after getting an appropriate interrupt, or checking an appropriate status bit, the driver makes buffer accesses for the whole block size (e.g. 128 reads for 512 bytes block). This is done in accordance with SD Host Controller Specification. At the same time, the Ultra Secured Digital Host Controller (uSDHC), used in i.MX6 (and, probably, earlier i.MX series too), uses a separate Watermark Levels register, controlling the amount of data or space available when raising status bit or interrupt. For default watermark setting of 16 words, the controller expects (and guarantees) no more than 16 buffer accesses after raising buffer ready status bit and generating an appropriate interrupt. If the driver tries to access the whole block size, it will get incorrect data at the end, and a new interrupt will appear later, when the driver already doesn't expect it. This happens sometimes, more likely on low frequencies, e.g. when reading EXT_CSD at MMC card initialization phase (which makes that initialization fail). Such behavior of i.MX uSDHC seems to be non-compliant to SDHCI Specification, but this is the way it works now. In order not to rewrite the SDHCI driver PIO mode access logic, the IMX specific driver can just set the watermark level to default block size (128 words or 512 bytes), so that the controller behavior will be consistent to generic specification. This patch does this for PIO mode accesses only, restoring default values for DMA accesses to avoid any possible side effects from performance point of view. Signed-off-by:
Andrew Gabbasov <andrew_gabbasov@mentor.com> Signed-off-by:
Harish Jenny K N <harish_kandiga@mentor.com> Acked-by:
Adrian Hunter <adrian.hunter@intel.com> Signed-off-by:
-
- 15 Jan, 2018 1 commit
-
-
Benoît Thébaudeau authored
Commit 5143c953 ("mmc: sdhci-esdhc-imx: Allow all supported prescaler values") made it possible to set SYSCTL.SDCLKFS to 0 in SDR mode, thus bypassing the SD clock frequency prescaler, in order to be able to get higher SD clock frequencies in some contexts. However, that commit missed the fact that this value is illegal on the eSDHCv3 instance of the i.MX53. This seems to be the only exception on i.MX, this value being legal even for the eSDHCv2 instances of the i.MX53. Fix this issue by changing the minimum prescaler value if the i.MX53 eSDHCv3 is detected. According to the i.MX53 reference manual, if DLLCTRL[10] can be set, then the controller is eSDHCv3, else it is eSDHCv2. This commit fixes the following issue, which was preventing the i.MX53 Loco (IMX53QSB) board from booting Linux 4.15.0-rc5: [ 1.882668] mmcblk1: error -84 transferring data, sector 2048, nr 8, cmd response 0x900, card status 0xc00 [ 2.002255] mmcblk1: error -84 transferring data, sector 2050, nr 6, cmd response 0x900, card status 0xc00 [ 12.645056] mmc1: Timeout waiting for hardware interrupt. [ 12.650473] mmc1: sdhci: ============ SDHCI REGISTER DUMP =========== [ 12.656921] mmc1: sdhci: Sys addr: 0x00000000 | Version: 0x00001201 [ 12.663366] mmc1: sdhci: Blk size: 0x00000004 | Blk cnt: 0x00000000 [ 12.669813] mmc1: sdhci: Argument: 0x00000000 | Trn mode: 0x00000013 [ 12.676258] mmc1: sdhci: Present: 0x01f8028f | Host ctl: 0x00000013 [ 12.682703] mmc1: sdhci: Power: 0x00000002 | Blk gap: 0x00000000 [ 12.689148] mmc1: sdhci: Wake-up: 0x00000000 | Clock: 0x0000003f [ 12.695594] mmc1: sdhci: Timeout: 0x0000008e | Int stat: 0x00000000 [ 12.702039] mmc1: sdhci: Int enab: 0x107f004b | Sig enab: 0x107f004b [ 12.708485] mmc1: sdhci: AC12 err: 0x00000000 | Slot int: 0x00001201 [ 12.714930] mmc1: sdhci: Caps: 0x07eb0000 | Caps_1: 0x08100810 [ 12.721375] mmc1: sdhci: Cmd: 0x0000163a | Max curr: 0x00000000 [ 12.727821] mmc1: sdhci: Resp[0]: 0x00000920 | Resp[1]: 0x00000000 [ 12.734265] mmc1: sdhci: Resp[2]: 0x00000000 | Resp[3]: 0x00000000 [ 12.740709] mmc1: sdhci: Host ctl2: 0x00000000 [ 12.745157] mmc1: sdhci: ADMA Err: 0x00000001 | ADMA Ptr: 0xc8049200 [ 12.751601] mmc1: sdhci: ============================================ [ 12.758110] print_req_error: I/O error, dev mmcblk1, sector 2050 [ 12.764135] Buffer I/O error on dev mmcblk1p1, logical block 0, lost sync page write [ 12.775163] EXT4-fs (mmcblk1p1): mounted filesystem without journal. Opts: (null) [ 12.782746] VFS: Mounted root (ext4 filesystem) on device 179:9. [ 12.789151] mmcblk1: response CRC error sending SET_BLOCK_COUNT command, card status 0x900 Signed-off-by:
Benoît Thébaudeau <benoit.thebaudeau.dev@gmail.com> Reported-by:
Wladimir J. van der Laan <laanwj@gmail.com> Tested-by:
-
- 09 Jan, 2018 3 commits
-
-
Michael Trimarchi authored
mmc clock can be stopped during runtime suspend and restart during runtime resume if the sdio irq is not enabled. Stop sdio clock reduce EMI of the device when the bus is not in use. Signed-off-by:
Michael Trimarchi <michael@amarulasolutions.com> Signed-off-by:
-
Michael Trimarchi authored
runtime_resume() should re-enable the clocks in reverse order comparing with runtime_suspend() Signed-off-by:
-
Michael Trimarchi authored
We need to return in case of error even if the actual implementation of sdhci_runtime_suspend_host always return 0. We don't want to power down the clock and the assuption is that the sdhci_runtime_suspend_host always let the system consistent in case of failure Signed-off-by:
-
- 20 Jun, 2017 5 commits
-
-
Benoît Thébaudeau authored
The SDHCI_QUIRK_NO_MULTIBLOCK quirk was used as a workaround for the ENGcm07207 erratum. However, it caused excruciatingly slow SD transfers (300 kB/s on average), and this erratum actually does not imply that multiple-block transfers are not supported, so this was overkill. The suggested workaround for this erratum is to set SYSCTL.RSTA, but the simple DAT line software reset (which resets the DMA circuit among others) triggered by sdhci_finish_data() in case of errors seems to be sufficient. Indeed, generating errors in a controlled manner on i.MX25 using the FEVT register right in the middle of read data transfers without this quirk shows that nothing is written to the buffer by the eSDHC past CMD12, and no extra Auto CMD12 is sent with AC12EN set, so the data transfers on AHB are properly aborted. For write data transfers, neither extra data nor extra Auto CMD12 is sent, as expected. Moreover, after intensive stress tests on i.MX25, removing SDHCI_QUIRK_NO_MULTIBLOCK seems to be safe. SDHCI_QUIRK_BROKEN_ADMA has nothing to do with ENGcm07207, so set ESDHC_FLAG_ERR004536 for the devices that had ESDHC_FLAG_ENGCM07207 set in order to continue getting SDHCI_QUIRK_BROKEN_ADMA. Signed-off-by:
Benoît Thébaudeau <benoit@wsystem.com> Acked-by:
Fabio Estevam <fabio.estevam@nxp.com> Signed-off-by:
-
Benoît Thébaudeau authored
On i.MX, SYSCTL.SDCLKFS may always be set to 0 in order to make the SD clock frequency prescaler divide by 1 in SDR mode, even with the eSDHC. The previous minimum prescaler value of 2 in SDR mode with the eSDHC was a code remnant from PowerPC, which actually has this limitation on earlier revisions. In DDR mode, the prescaler can divide by up to 512. The maximum SD clock frequency in High Speed mode is 50 MHz. On i.MX25, this change makes it possible to get 48 MHz from the USB PLL (240 MHz / 5 / 1) instead of only 40 MHz from the USB PLL (240 MHz / 3 / 2) or 33.25 MHz from the AHB clock (133 MHz / 2 / 2). Signed-off-by:
-
Benoît Thébaudeau authored
On i.MX25, the eSDHC DAT line software reset (SYSCTL.RSTD) unexpectedly clears at least the data transfer width (PROCTL.DTW), which then results in data CRC errors. This behavior is not documented, but it has actually been observed. Consequently, the DAT line software resets triggered by sdhci.c in case of errors caused unrecoverable errors. Fix this by making sure that the DAT line software reset does not alter the Host Control register. This behavior being undocumented, it may also be present on other i.MX SoCs, so apply this fix for the whole i.MX family. Signed-off-by:
-
Benoît Thébaudeau authored
Fix various English mistakes and typos in comments and in printed strings. Signed-off-by:
-
Fabio Estevam authored
clk_prepare_enable() may fail, so we should better check its return value and propagate it in the case of error. Signed-off-by:
-
- 24 Apr, 2017 2 commits
-
-
Haibo Chen authored
USDHC tuning circuit should be reset before every time card enumeration or re-enumeration. SD3.0 card need tuning. For SDR104 card, when system suspend in standby mode, and then resume back, the IO timing is still SDR104(tuned) which may result in card re-enumeration fail in low card speed(400khz) for some cards. And we did meet the issue that in certain probability, SDR104 card meet mmc command CRC/Timeout error when send CMD2 during mmc bus resume. This patch reset the tuning circuit when the ios timing is MMC_TIMING_LEGACY/MMC_TIMING_MMC_HS/MMC_TIMING_SD_HS, which means both mmc_power_up() and mmc_power_off() will reset the tuning circuit. Signed-off-by:
Haibo Chen <haibo.chen@nxp.com> Acked-by:
Dong Aisheng <aisheng.dong@nxp.com> Acked-by:
-
Adrian Hunter authored
Devices might save and restore tuning values so that re-tuning might not be needed after a pm transition. Let drivers decide by pushing the mmc_retune_needed() logic down to them. Signed-off-by:
Ludovic Desroches <ludovic.desroches@microchip.com>
-
- 20 Apr, 2017 1 commit
-
-
Haibo Chen authored
Currently for DDR50 card, it need tuning in default. We meet tuning fail issue for DDR50 card and some data CRC error when DDR50 sd card works. This is because the default pad I/O drive strength can't make sure DDR50 card work stable. So increase the pad I/O drive strength for DDR50 card, and use pins_100mhz. This fixes DDR50 card support for IMX since DDR50 tuning was enabled from commit 9faac7b9 ("mmc: sdhci: enable tuning for DDR50") Tested-and-reported-by:
Tim Harvey <tharvey@gateworks.com> Signed-off-by:
-
- 13 Oct, 2016 1 commit
-
-
Aaron Brice authored
- The DMA error interrupt bit is in a different position as compared to the sdhci standard. This is accounted for in many cases, but not handled in the case of clearing the INT_STATUS register by writing a 1 to that location. - The HOST_CONTROL register is very different as compared to the sdhci standard. This is accounted for in the write case, but not when read back out (which it is in the sdhci code). Signed-off-by:
Dave Russell <david.russell@datasoft.com> Signed-off-by:
Aaron Brice <aaron.brice@datasoft.com> Acked-by:
-
- 26 Sep, 2016 2 commits
-
-
Haibo Chen authored
i.MX USDHC Reference Manual has a mistake, for the register SYS_CTRL, the DTOCV(bit 19~16) means the data timeout counter value. When DTOCV is set to 0xF, it means SDCLK << 29, not SDCLK << 28. Signed-off-by:
-
Haibo Chen authored
Now, when call esdhc_set_timeout() to set the data timeout counter value, IPP_RST_N(bit 23) is wrongly affected. This patch add a mask to avoid this. Signed-off-by:
-
- 29 Jul, 2016 2 commits
-
-
Ulf Hansson authored
To prepare to make the sdhci_pltfm_suspend|resume() static functions, move sdhci-esdhc-imx over to use the sdhci_suspend|resume_host(). Signed-off-by:
-
Ulf Hansson authored
The system PM callbacks isn't used unless CONFIG_PM_SLEEP is set, thus it triggers a compiler warning about unused functions. Avoid this by changing from CONFIG_PM to CONFIG_PM_SLEEP. Reported-by:
Arnd Bergmann <arnd@arndb.de> Fixes: b70d0b3b5b29 ("mmc: sdhci-esdhc-imx: add esdhc specific suspend resume callback") Cc: Dong Aisheng <aisheng.dong@nxp.com> Signed-off-by:
-
- 25 Jul, 2016 12 commits
-
-
Dong Aisheng authored
The tuning bits like FBCLK_SEL, SMP_CLK_SEL and DLY_CELL which affects timing may have already been set by ROM if booting from SD3.0 mode like SDR104. Let's clear it first during driver probe before doing the new card enumeration to avoid working on the wrong timing. Note that tuning bits are dynamical settings which may need to be kept during MMC_PM_KEEP_POWER suspend, so we did not put them into hwinit function. Signed-off-by:
-
Dong Aisheng authored
sdhci_esdhc_imx_hwinit() includes all basic hw intialization. Calling it after resume to re-initialize hw in case its state is already lost in low power mode. Signed-off-by:
-
Dong Aisheng authored
Move tuning static configuration into basic hwinit function. Tuning configuration may also be lost in low power mode, so need restore in hwinit(). Acked-by:
-
Dong Aisheng authored
Move all hw related static initializations into a separate function which helps concentrate the hw related initialization code. And that function could also be called by other places later as a basic hw state restore. e.g. suspend/resume where the hw state is possible to lost due to low power mode. Signed-off-by:
-
Dong Aisheng authored
When enable DDR, the clock factor definition is changed. e.g. original 200Mhz will become 100Mhz once MIX_CTRL_DDREN bit is set So we need to update the clock setting then the strobe dll can lock the correct clock rate. Additionally we also need disable the clock before locking strobe dll. Acked-by:
-
Dong Aisheng authored
Indicating hw auto retuning support for mx6qdl in the fake caps_1 register and enable auto retuning in post_tuning process after tuning completes. Acked-by:
-
Dong Aisheng authored
Enable HW auto retuning when set SDHCI_CTRL_EXEC_TUNING and clear it when clear SDHCI_CTRL_TUNED_CLK. Acked-by:
-
Dong Aisheng authored
The delay cells of some SoCs may have less delay per one cell, for such SoCs, user could set the start delay cell point to bypass the first a few meaningless tuning commands. Acked-by:
-
Dong Aisheng authored
Disable DLL delay line settings explicitly during driver initialization in case ROM/uBoot had set an invalid delay. e.g. MX6DL ROM has set the default delay line(DLLCTRL) to 0x1000021, the uSDHC clock timing will become marginal when works on DDR mode due to default delay and will possibly see CRC errors in case the board is not perfectly designed on the eMMC chip layout. Acked-by:
-
Dong Aisheng authored
Currently, we config the watermark_level register only in probe. This will cause the mmc write operation timeout issue after system resume back in LPSR mode. Because in LPSR mode, after system resume back, the watermark_level register(0x44) changes to 0x08000880, which set the write watermark level as 0, and set the read watermark level as 128. This value is incorrect. This patch restores the setting of watermark level register after system resume back. Signed-off-by:
-
Dong Aisheng authored
It will be used for platform specific suspend/resume state save/restore work for some low power mode like Mega/Fast or LPSR mode. Acked-by:
-
Dong Aisheng authored
The driver has already implemented the private .set_timeout() callback for common SDHCI code to do correct timeout value setting, it does not need call sdhci_calc_timeout(), so this quirk actually is not working. Remove it now. Acked-by:
-
- 27 May, 2016 1 commit
-
-
Arnd Bergmann authored
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:Linus Torvalds <torvalds@linux-foundation.org>
-
- 29 Feb, 2016 1 commit
-
-
Jisheng Zhang authored
Commit 0e748234 ("mmc: sdhci: Add size for caller in init+register") allows users of sdhci_pltfm to allocate private space in calls to sdhci_pltfm_init+sdhci_pltfm_register. This patch migrates the sdhci esdhc-imx driver to this allocation. Signed-off-by:
Jisheng Zhang <jszhang@marvell.com> Acked-by:
-
- 22 Dec, 2015 1 commit
-
-
Haibo Chen authored
Here we use '|=' to set the tuning-step, but before that, we should clear the tuning-step, otherwise we could got the wrong setting. Signed-off-by:
Haibo Chen <haibo.chen@freescale.com> Acked-by:
Dong Aisheng <aisheng.dong@freescale.com> Signed-off-by:
-
- 27 Oct, 2015 1 commit
-
-
Chaotian Jing authored
The mmc_execute_tuning() has already prepared the opcode, there is no need to prepare it again at mmc_send_tuning(), and, there is a BUG of mmc_send_tuning() to determine the opcode by bus width, assume eMMC was running at HS200, 4bit mode, then the mmc_send_tuning() will overwrite the opcode from CMD21 to CMD19, then got error. in addition, extend an argument of "cmd_error" to allow getting if there was cmd error when tune response. Signed-off-by:
Chaotian Jing <chaotian.jing@mediatek.com> [Ulf: Rebased patch] Signed-off-by:
-
- 27 Aug, 2015 4 commits
-
-
Haibo Chen authored
By default, for all imx SoC types, the watermark level is 16, and the burst length is 8. But if the SDIO/SD/MMC I/O speed is fast enough, this default watermark level and burst length will be the performance bottleneck. For example, i.MX7D support eMMC HS400 mode, this mode can run in 8 bit, 200MHZ DDR mode. So the I/O speed improve a lot compare to SD3.0. The default burst length is 8, if we don't change this value, in HS400 mode, when we do eMMC read operation, we can find that the clock signal will stop for a period of time. This means the speed of data moving on AHB bus is slower than I/O speed. So we should improve the speed of data moving on AHB bus. This patch set the default burst length as 16, and set the default watermark level as 64. The test result is the clock signal has no stop during the eMMC HS400 operation. Signed-off-by:
-
Haibo Chen authored
Currently we find that if a usdhc is choosed to boot system, then ROM code will set the burst length enable bit of this usdhc as 0. This will make performance drop a lot if this usdhc's burst length is configed. So this patch set back the burst_length_enable bit as 1, which is the default value, and means burst length is enabled for INCR. Signed-off-by:
-
Haibo Chen authored
tuning-step is the delay cell steps in tuning procedure. The default value of tuning-step is 1. Some boards or cards need another value to pass the tuning procedure. For example, imx7d-sdb board need the tuning-step value as 2, otherwise it can't pass the tuning procedure. So this patch add the tuning-step setting in driver, so that user can set the tuning-step value in dts. Signed-off-by:
-
Haibo Chen authored
The imx7d usdhc is derived from imx6sx, the difference is that imx7d support HS400. So introduce a new compatible string for imx7d and add HS400 support for imx7d usdhc. Signed-off-by:
-
- 24 Jul, 2015 1 commit
-
-
Dong Aisheng authored
After commit 8d86e4fc ("mmc: sdhci-esdhc-imx: Call mmc_of_parse()"), it's not used anymore. Signed-off-by:
Johan Derycke <johan.derycke@barco.com> Signed-off-by:
-
