- 17 Dec, 2018 39 commits
-
-
Faiz Abbas authored
The TRM (SPRUIC2C - January 2017 - Revised May 2018 [1]) forbids assertion of data reset while tuning is happening. Implement a platform specific callback that takes care of this condition. [1] http://www.ti.com/lit/pdf/spruic2 Section 25.5.1.2.4 Acked-by:
Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by:
Faiz Abbas <faiz_abbas@ti.com> Acked-by:
Adrian Hunter <adrian.hunter@intel.com> Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org>
-
Ezequiel Garcia authored
As reported by Aaro, the JZ4740 MMC driver throws a warning when the kernel is built without preemption (CONFIG_PREEMPT_NONE=y). [ 16.461094] jz4740-mmc 13450000.mmc: [jz4740_mmc_prepare_dma_data] invalid cookie: data->host_cookie 567 host->next_data.cookie 568 [ 16.473120] jz4740-mmc 13450000.mmc: [jz4740_mmc_prepare_dma_data] invalid cookie: data->host_cookie 568 host->next_data.cookie 569 [ 16.485144] jz4740-mmc 13450000.mmc: [jz4740_mmc_prepare_dma_data] invalid cookie: data->host_cookie 569 host->next_data.cookie 570 [ 16.497170] jz4740-mmc 13450000.mmc: [jz4740_mmc_prepare_dma_data] invalid cookie: data->host_cookie 570 host->next_data.cookie 571 The problem seems to be related to how pre_req/post_req is implemented. Currently, it seems the driver expects jz4740_mmc_prepare_dma_data() to be called with monotonically increasing host_cookie values, which is wrong. Moreover, the implementation is overly complicated, keeping track of unneeded "next cookie" state. So, instead of attempting to fix the current pre_req/post_req implementation, this commit refactors the driver, dropping the state, following other drivers such as dw_mmc and sdhci. Cc: Paul Cercueil <paul@crapouillou.net> Cc: Mathieu Malaterre <malat@debian.org> Reported-by:
Aaro Koskinen <aaro.koskinen@iki.fi> Signed-off-by:
Ezequiel Garcia <ezequiel@collabora.com> Tested-by:
-
Ludovic Barre authored
Refer to "4.15 set block count command" of sd specification: Host needs to issue CMD12 if any error is detected in the CMD18 and CMD25 operations. In sbc case, the data->stop is fill by framework. Signed-off-by:
Ludovic Barre <ludovic.barre@st.com> Tested-by:
-
Wolfram Sang authored
If we use it this way, people should know about it. Also, replace true/false with nonzero/zero because the flag is not strictly a bool anymore. Signed-off-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
-
Wolfram Sang authored
Some variants (namely Renesas SDHI) have bits in the STATS and IRQ_MASK registers which are 'always 1' and should be written as such. Introduce a seperate mask for this and apply it whenever such a register is written. Signed-off-by:
Simon Horman <horms+renesas@verge.net.au> Reviewed-by:
Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Signed-off-by:
-
Niklas Söderlund authored
The Renesas BSP confirms that H3 ES1.x and M3-W ES1.[012] do not properly support HS400. Add a quirk to indicate this and disable HS400 in the MMC capabilities if the quirk is set. Signed-off-by:
-
Niklas Söderlund authored
It was though all ES revisions of H3 and M3-W SoCs required the TMIO_MMC_HAVE_4TAP_HS400 flag. Recent datasheet updates tells us this is not true, only early ES revisions of the SoC do. Since quirk matching based on ES revisions is now used to handle the flag it's possible to align all Gen3 compatibility properties. This will allow later ES revisions of H3 and M3-W to use the correct 8-tap HS400 mode. Signed-off-by:
-
Niklas Söderlund authored
Latest datasheet makes it clear that not all ES revisions of the H3 and M3-W have the 4-tap HS400 mode quirk, currently the quirk is set unconditionally for these two SoCs. Prepare to handle the quirk based on SoC revision instead of compatibility value by using soc_device_match() and set the TMIO_MMC_HAVE_4TAP_HS400 flag explicitly. The reason for adding a new quirks struct instead of just a flag is that looking ahead it seems more quirks needs to be handled in a SoC revision basis. Signed-off-by:
-
Niklas Söderlund authored
The initial value of the interrupt mask register may be different from the H/W manual at the startup of the kernel by setting from the bootloader. Since the error interrupts may be unmasked, the driver sets initial value. The initial value is only known for R-Car Gen2 and Gen3 platforms so limit the initialization to those platforms. Based on work from Masaharu Hayakawa. Signed-off-by:
-
Niklas Söderlund authored
SD / MMC did not operate properly when suspend transition failed. Because the SCC was not reset at resume, issue of the command failed. Call the host specific reset function and reset the hardware in order to add reset of SCC. This change also fixes tuning on some stubborn cards on Gen2. Based on work from Masaharu Hayakawa. Signed-off-by:
-
Niklas Söderlund authored
On runtime power management resume, the host clock needs to be enabled before calling tmio_mmc_reset. If the mmc device has a power domain entry, the host clock is enabled via genpd_runtime_resume, running before tmio_mmc_host_runtime_resume. If the mmc device has no power domain entry, however, genpd_runtime_resume is not called. This patch changes tmio_mmc_host_runtime_resume to enable the host clock before calling tmio_mmc_reset. Based on work from Masaharu Hayakawa. Signed-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by:
-
Wolfram Sang authored
The only user was converted to fill a sbc command which is the proper way to do it because of AutoCMD23 feature of some hosts. Signed-off-by:
Clément Péron <peron.clem@gmail.com> Reviewed-by:
Avri Altman <avri.altman@wdc.com> Reviewed-by:
-
Stefan Wahren authored
In case dmaengine_prep_slave_sg fails we need to call dma_unmap_sg. Signed-off-by:
Stefan Wahren <stefan.wahren@i2se.com> Acked-by:
Eric Anholt <eric@anholt.net> Signed-off-by:
-
Stefan Wahren authored
There are two variables len within bcm2835_prepare_dma. So rename the result of dma_map_sg to sg_len. While we are at this add a bail out to simplify the following change. Signed-off-by:
-
Stefan Wahren authored
It's better to make sure that the timeout work is really terminated before calling mmc_request_done. Signed-off-by:
-
Stefan Wahren authored
There are two accesses on the data requests which are not protected by the mutex. So fix this accordingly. Signed-off-by:
-
Stefan Wahren authored
We need to release the slave DMA channel during driver unload. Signed-off-by:
-
Phil Elwell authored
If the user issues an "mmc extcsd read", the SD controller receives what it thinks is a SEND_IF_COND command with an unexpected data block. The resulting operations leave the FSM stuck in READWAIT, a state which persists until the MMC framework resets the controller, by which point the root filesystem is likely to have been unmounted. A less heavyweight solution is to detect the condition and nudge the FSM by asserting the (self-clearing) FORCE_DATA_MODE bit. Link: https://github.com/raspberrypi/linux/issues/2728Signed-off-by:
Phil Elwell <phil@raspberrypi.org> Signed-off-by:
-
Michal Suchanek authored
The bcm2835 mmc host tends to lock up for unknown reason so reset it on timeout. The upper mmc block layer tries retransimitting with single blocks which tends to work out after a long wait. This is better than giving up and leaving the machine broken for no obvious reason. Fixes: 660fc733 ("mmc: bcm2835: Add new driver for the sdhost controller.") Signed-off-by:
Michal Suchanek <msuchanek@suse.de> Signed-off-by:
-
Linus Walleij authored
Simplify things by making the i.MX SDHCI driver just use slot GPIO with descriptors instead of passing around the global GPIO numbers that we want to get rid of. As it turns out, just one single board is using the platform data to pass in GPIOs numbers for CD and WP, so we augment this to use a machine descriptor table instead. Cc: Shawn Guo <shawnguo@kernel.org> Cc: Sascha Hauer <s.hauer@pengutronix.de> Cc: Pengutronix Kernel Team <kernel@pengutronix.de> Cc: Fabio Estevam <fabio.estevam@nxp.com> Cc: NXP Linux Team <linux-imx@nxp.com> Cc: Bartosz Golaszewski <brgl@bgdev.pl> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Reviewed-by:
Dong Aisheng <aisheng.dong@nxp.com> Signed-off-by:
-
Linus Walleij authored
The power GPIO line is passed with inversion flags and all from the platform data. Switch to using an optional GPIO descriptor and use this to switch the power. Augment the only boardfile to pass in the proper "power" descriptor in the GPIO descriptor machine table instead. As the GPIO handling is now much simpler, we can cut down on some overhead code. Cc: Paul Cercueil <paul@crapouillou.net> Cc: linux-mips@linux-mips.org Signed-off-by:
Paul Burton <paul.burton@mips.com> Signed-off-by:
-
Linus Walleij authored
Modifty the JZ4740 driver to retrieve card detect and write protect GPIO pins from GPIO descriptors instead of hard-coded global numbers. Augment the only board file using this in the process and cut down on passed in platform data. Preserve the code setting the caps2 flags for CD and WP as active low or high since the slot GPIO code currently ignores the gpiolib polarity inversion semantice and uses the raw accessors to read the GPIO lines, but set the right polarity flags in the descriptor table for jz4740. Cc: Paul Cercueil <paul@crapouillou.net> Cc: linux-mips@linux-mips.org Signed-off-by:
-
Linus Walleij authored
The use of string pointers in the MMC slot GPIO context is pretty dubious, allocating some 2*len extra bytes for each label of the ro and wp pins. Tidy this up using kasprintf() with dynamic allocation of labels for these strings. Signed-off-by:
-
Veerabhadrarao Badiganti authored
On few SDHCI-MSM controllers, the host controller's clock tuning circuit may go out of sync if controller clocks are gated which eventually will result in data CRC, command CRC/timeout errors. To overcome this h/w limitation, the DLL needs to be re-initialized and restored with its old settings once clocks are ungated. Signed-off-by:
Veerabhadrarao Badiganti <vbadigan@codeaurora.org> Reviewed-by:
Evan Green <evgreen@chromium.org> Signed-off-by:
-
Veerabhadrarao Badiganti authored
Add SoC-specific compatible strings for qcom-sdhci controller. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Adrian Hunter authored
If the host controller supports auto-commands then enable the auto-command error interrupt and handle it. In the case of auto-CMD23, the error is treated the same as manual CMD23 error. In the case of auto-CMD12, commands-during-transfer are not permitted, so the error handling is treated the same as a data error. Signed-off-by:
-
Adrian Hunter authored
The SDHCI_ACMD12_ERR register is used for auto-CMD23 and auto-CMD12 errors, as is the SDHCI_INT_ACMD12ERR interrupt bit. Rename them to SDHCI_AUTO_CMD_STATUS and SDHCI_INT_AUTO_CMD_ERR respectively. Signed-off-by:
-
Adrian Hunter authored
Existing data command CRC error handling is non-standard and does not work with some Intel host controllers. Specifically, the assumption that the host controller will continue operating normally after the error interrupt, is not valid. Change the driver to handle the error in the same manner as a data CRC error, taking care to ensure that the data line reset is done for single or multi-block transfers, and it is done before unmapping DMA. Signed-off-by:
-
Stefan Wahren authored
Adopt the SPDX license identifier headers to ease license compliance management. Cc: Phil Elwell <phil@raspberrypi.org> Signed-off-by:
-
Marek Vasut authored
Whitelist R8A77990 E3 SoC in the SDHI driver. The SDHI core present in the SoC is an 8tap variant of the Gen3 SDHI core. Signed-off-by:
Marek Vasut <marek.vasut+renesas@gmail.com> Cc: Geert Uytterhoeven <geert+renesas@glider.be> Cc: Simon Horman <horms+renesas@verge.net.au> Cc: Wolfram Sang <wsa@the-dreams.de> Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Cc: Ulf Hansson <ulf.hansson@linaro.org> Cc: linux-renesas-soc@vger.kernel.org Reviewed-by:
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Reviewed-by:
-
Masaharu Hayakawa authored
The manual does not contain information that a wait is needed in the tuning process, this might be a leftover from early development. Removing the wait don't have any effect on operation so delete the wait to shorten the initialization time. Signed-off-by:
Masaharu Hayakawa <masaharu.hayakawa.ry@renesas.com> Signed-off-by:
Takeshi Saito <takeshi.saito.xv@renesas.com> [Niklas: fixup commit message] Signed-off-by:
-
Niklas Söderlund authored
The driver sets an incorrect clock and depends on the clock driver knowledge of this incorrect setting to still set a 200Mhz SDn clock. Instead of spreading the workaround between the two drivers the clock driver should be made aware of the ES versions where the special clock handling is needed no need to keep this workaround in the SDHI driver. Signed-off-by:
-
Masahiro Yamada authored
The reason of including <linux/bitops.h> here is just for BIT() and GENMASK() macros. Since commit 8bd9cb51 ("locking/atomics, asm-generic: Move some macros from <linux/bitops.h> to a new <linux/bits.h> file"), <linux/bits.h> is enough for such compile-time macros. Signed-off-by:
-
Chunyan Zhang authored
The function sdhci_allocate_bounce_buffer() always return zero at present, so there's no need to have a return value, that will also make error path easier. CC: Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
Chunyan Zhang <zhang.chunyan@linaro.org> Reviewed-by:
-
Chris Brandt authored
Document support for the RZ/A2 (R7S9210) SoC. Signed-off-by:
Chris Brandt <chris.brandt@renesas.com> Reviewed-by:
-
Chris Brandt authored
The SDHI/MMC controller in the RZ/A2 is almost the same as R-Car gen3, but with some minor differences. Signed-off-by:
-
A.s. Dong authored
Add imx8qxp compatible string Cc: Rob Herring <robh+dt@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Ulf Hansson <ulf.hansson@linaro.org> Cc: linux-serial@vger.kernel.org Cc: devicetree@vger.kernel.org Cc: linux-mmc@vger.kernel.org Cc: Haibo Chen <haibo.chen@nxp.com> Signed-off-by:
-
Jonas Danielsson authored
On our AT91SAM9260 board we use the same sdio bus for wifi and for the sd card slot. This caused the atmel-mci to give the following splat on the serial console: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 538 at drivers/mmc/host/atmel-mci.c:859 atmci_send_command+0x24/0x44 Modules linked in: CPU: 0 PID: 538 Comm: mmcqd/0 Not tainted 4.14.76 #14 Hardware name: Atmel AT91SAM9 [<c000fccc>] (unwind_backtrace) from [<c000d3dc>] (show_stack+0x10/0x14) [<c000d3dc>] (show_stack) from [<c0017644>] (__warn+0xd8/0xf4) [<c0017644>] (__warn) from [<c0017704>] (warn_slowpath_null+0x1c/0x24) [<c0017704>] (warn_slowpath_null) from [<c033bb9c>] (atmci_send_command+0x24/0x44) [<c033bb9c>] (atmci_send_command) from [<c033e984>] (atmci_start_request+0x1f4/0x2dc) [<c033e984>] (atmci_start_request) from [<c033f3b4>] (atmci_request+0xf0/0x164) [<c033f3b4>] (atmci_request) from [<c0327108>] (mmc_start_request+0x280/0x2d0) [<c0327108>] (mmc_start_request) from [<c032800c>] (mmc_start_areq+0x230/0x330) [<c032800c>] (mmc_start_areq) from [<c03366f8>] (mmc_blk_issue_rw_rq+0xc4/0x310) [<c03366f8>] (mmc_blk_issue_rw_rq) from [<c03372c4>] (mmc_blk_issue_rq+0x118/0x5ac) [<c03372c4>] (mmc_blk_issue_rq) from [<c033781c>] (mmc_queue_thread+0xc4/0x118) [<c033781c>] (mmc_queue_thread) from [<c002daf8>] (kthread+0x100/0x118) [<c002daf8>] (kthread) from [<c000a580>] (ret_from_fork+0x14/0x34) ---[ end trace 594371ddfa284bd6 ]--- This is: WARN_ON(host->cmd); This was fixed on our board by letting atmci_request_end determine what state we are in. Instead of unconditionally setting it to STATE_IDLE on STATE_END_REQUEST. Signed-off-by:
Jonas Danielsson <jonas@orbital-systems.com> Signed-off-by:
-
Liming Sun authored
This commit removes the unnecessary of-node check since the dw_mci_bluefield_match[] structure has only one entry. Signed-off-by:
Liming Sun <lsun@mellanox.com> Signed-off-by:
-
- 16 Dec, 2018 1 commit
-
-
Linus Torvalds authored
-
