- 26 Nov, 2014 38 commits
-
-
Vincent Yang authored
Voltage Switch Procedure This patch is to fix an issue found on mb86s7x platforms. [symptom] There are some UHS-1 SD memory cards sometimes cannot be detected correctly, e.g., Transcend 600x SDXC 64GB UHS-1 memory card. During Signal Voltage Switch Procedure, failure to switch is indicated by the card holding DAT[3:0] low. [analysis] According to SD Host Controller Simplified Specification Version 3.00 chapter 3.6.1, the Signal Voltage Switch Procedure should be: (1) Check S18A; (2) Issue CMD11; (3) Check CMD 11 response; (4) Stop providing SD clock; (5) Check DAT[3:0] should be 0000b; (6) Set 1.8V Signal Enable; (7) Wait 5ms; (8) Check 1.8V Signal Enable; (9) Provide SD Clock; (10) Wait 1ms; (11) Check DAT[3:0] should be 1111b; (12) error handling With CONFIG_MMC_CLKGATE=y, sometimes there is one more gating/un-gating SD clock between (2) and (3). In this case, some UHS-1 SD cards will hold DAT[3:0] 0000b at (11) and thus fails Signal Voltage Switch Procedure. [solution] By mmc_host_clk_hold() before CMD11, the additional gating/un-gating SD clock between (2) and (3) can be prevented and thus no failure at (11). It has been verified with many UHS-1 SD cards on mb86s7x platforms and works correctly. Signed-off-by: Vincent Yang <Vincent.Yang@tw.fujitsu.com> Reviewed-by: Johan Rudholm <jrudholm@gmail.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Fabio Estevam authored
clk_prepare_enable() may fail and in this case we should propagate the error. Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Fabio Estevam authored
If platform_get_irq() fails, it is better to propagate the real error value instead of a 'fake' one. Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Fabio Estevam authored
devm_ioremap_resource() already checks if 'iores' is NULL or not, so we can skip this manual check. While at it, move platform_get_resource() closer to devm_ioremap_resource() for better readability. Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Andrew Bresticker authored
Add support for the DW MMC host found on the Imagination Pistachio SoC. Like the DW MMC hosts found on SOCFPGA and Rockchip SoCs, the DW MMC host on Pistachio requires the use of SDMMC_CMD_USE_HOLD_REG. Signed-off-by: Andrew Bresticker <abrestic@chromium.org> Reviewed-by: Doug Anderson <dianders@chromium.org> Acked-by: Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Fabio Estevam authored
By using SIMPLE_DEV_PM_OPS we can make the code smaller and cleaner. Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Fabio Estevam authored
Instead of registering the irq name with the driver's name, it's better to pass the device name so that we have a more explicit indication as to what mmc instance the irq is related: $ cat /proc/interrupts CPU0 ... 26: 6 - 96 80010000.ssp Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
James Hogan authored
Commit f1d2736c (mmc: dw_mmc: control card read threshold) added dw_mci_ctrl_rd_thld() with an unconditional write to the CDTHRCTL register at offset 0x100. However before version 240a, the FIFO region started at 0x100, so the write messes with the FIFO and completely breaks the driver. If the version id < 240A, return early from dw_mci_ctl_rd_thld() so as not to hit this problem. Fixes: f1d2736c (mmc: dw_mmc: control card read threshold) Signed-off-by: James Hogan <james.hogan@imgtec.com> Cc: <stable@vger.kernel.org> # v3.13+ Acked-by: Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Dan Carpenter authored
We check for NULL pointers after dereferencing so it's too late. Oddly enough, Smatch misses this code but complains about the caller passing NULL pointers to this function: drivers/mmc/host/toshsd.c:389 toshsd_irq() error: we previously assumed 'host->cmd' could be null (see line 349) Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
ludovic.desroches@atmel.com authored
All boards with a dma controller have DT support so using dma_request_slave_channel_compat is no more needed. Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Addy Ke authored
The bit of sdio interrupt is 16 in designware implementation, but it is 24 on Rockchip SoCs.This patch add sdio_id0 for the number of slot0 in the SDIO interrupt registers. Signed-off-by: Addy Ke <addy.ke@rock-chips.com> Reviewed-by: Doug Anderson <dianders@chromium.org> Acked-by: Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Andrew Lunn authored
In order to use the mvsdio driver for sdio, it has been necessary to use a module parameter to disable DMA so to force PIO is used. It is then possible to use wireless LAN devices like mwifiex found on topkick and mirabox. However, accessing an MMC SD card does work with DMA. Investigation has shown that MMC block device accesses are always aligned to 64 byte boundaries, where as transfers from mwifiex are rarely more than word aligned. It has also been determined that card to host transfers work with DMA for SDIO devices, but host to card transfers with DMA have problems. This patch extends the current checks for buffers which are not word aligned or multiple of words. All host to card transfers which are not 64 byte aligned are now also performed via PIO. This should not affect the performance of SD cards, but allow sdio devices to work out of the box, and they are likely to be more efficient since DMA will be used for card to host transfers. Tested on mirabox for wifi via mwifiex Tested on 370 RD for file systems on an SD card. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Ben Hutchings authored
Currently the driver imposes a limit of 256 total minor numbers, apparently based on the historic Unix/Linux limit. This is quite restrictive, particularly if we raise the maximum number of partitions per card to 256 to match sd. In order to make the full minor number space available we would have to replace the static dev_use and name_use arrays with struct ida. But we can at least allow use of 256 cards rather than just 256 minors, with only a small change. Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Alim Akhtar authored
There are upcoming ARM64 SoCs with dw_mmc host controller. Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
NeilBrown authored
mmc_sdio_power_restore() calls mmc_send_if_cond(host, host->card->ocr); ret = mmc_send_io_op_cond(host, 0, NULL); between mmc_go_idle() and mmc_sdio_init_card(). mmc_sdio_resume() needs to as well, else my libertas sdio wifi device doesn't resume properly from suspend. Signed-off-by: NeilBrown <neilb@suse.de> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
NeilBrown authored
As we are restoring power to a known card, it makes sense to use the 'ocr' value known for the card rather than the generic one for the host interface. This matches the use of card->ocr passed to mmc_power_up in mmc_sdio_runtime_resume (just before mmc_sdio_power_restore is called), and the value passed to mmc_sdio_init_card() a little later in mmc_sdio_power_restore(). Suggested-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: NeilBrown <neilb@suse.de> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Ondrej Zary authored
This patch resurrects an old never-finished driver for Toshiba PCI SD controllers found in some older Toshiba laptops (such as Portege R100): 02:0d.0 System peripheral [0880]: Toshiba America Info Systems SD TypA Controller [1179:0805] (rev 05) The code is fixed, cleaned up and successfully tested with SD, SDHC, SDXC and MMC cards on Portege R100. (MMC cards don't even work in Windows!) SDIO probably does not work (don't have any SDIO card). The hardware is slow (around 2 MB/s - same in Windows) because it does not support bus mastering (busmaster enable bit cannot be set in PCI control reg). Also the card clock is limited to 16MHz (33MHz PCI clock divided by 2). Signed-off-by: Ondrej Zary <linux@rainbow-software.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Abhilash Kesavan authored
The Exynos7 has a DWMMC controller (v2.70a) which is different from prior versions. This patch adds new compatible strings for exynos7. This patch also fixes the CLKSEL register offset on exynos7. Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com> Signed-off-by: Yuvaraj Kumar C D <yuvaraj.cd@samsung.com> Tested-by: Vivek Gautam <gautam.vivek@samsung.com> Acked-by: Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Johan Rudholm authored
mmc_do_hw_reset(), mmc_power_up() and mmc_power_off() all set similar initial values for bus_mode, bus_width, chip_select and timing. Let's make this handling simpler and more consistent by sticking them together in a common function. This will introduce small changes in behavior in the following places: mmc_power_off(): For SPI hosts, explicitly set bus_mode = MMC_BUSMODE_PUSHPULL and chip_select = MMC_CS_HIGH, before we left them as they were. For non-SPI hosts, set bus_mode = MMC_BUSMODE_PUSHPULL instead of MMC_BUSMODE_OPENDRAIN as before. These two changes should not be a problem since the device will be powered off anyway. mmc_do_hw_reset(): Always set bus_mode = MMC_BUSMODE_PUSHPULL, as required by SD/SDIO cards. MMC cards require MMC_BUSMODE_OPENDRAIN, but this is taken care of by mmc_init_card() and mmc_attach_mmc(). Signed-off-by: Johan Rudholm <johanru@axis.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Andreas Fenkart authored
omap_hsmmc only supports one slot. So slot id is always zero, and slot id was never used in the callbacks anyway Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Andreas Fenkart <afenkart@gmail.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Andreas Fenkart authored
These callbacks are set during driver probe and not from the platform init, -- evtl. they had been for oamp 1/2 -- for omap3 they are local functions of the driver. These indirection could be dropped altogether in favor of regular function calls TODO Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Andreas Fenkart <afenkart@gmail.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Andreas Fenkart authored
this is needed when installing callbacks in the host struct and not in the platform data, e.g. cover detect irq should be stored in omap_hsmmc_host and not platform data Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Andreas Fenkart <afenkart@gmail.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Andreas Fenkart authored
omap_hsmmc supports only one slot per controller, see OMAP_MMC_MAX_SLOTS. This unnecessary indirection leads to confusion in the omap_hsmmc driver. For example the card_detect callback is not installed by platform code but from the driver probe function. So it should be a field of omap_hsmmc_host. But since it is declared under the platform slot while the drivers struct omap_hsmmc_host has no slot abstraction, this looks like a bug, especially when not familiar that this driver only supports 1 slot anyway. Either we should add a slot abstraction to omap_hsmmc_host or remove it from the platform data struct. Removed since slot multiplexing is an un-implemented feature Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Andreas Fenkart <afenkart@gmail.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Andreas Fenkart authored
trigger of this callback has been removed in 0a82e06eAcked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Andreas Fenkart <afenkart@gmail.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Andreas Fenkart authored
these fields are never read, probably an unimplemented feature or superseded by pm_runtime Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Andreas Fenkart <afenkart@gmail.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Andreas Fenkart authored
these callbacks are not set, probably legacy omap 1/2 features Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Andreas Fenkart <afenkart@gmail.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Andreas Fenkart authored
platform data is built from omap2_hsmmc_info, remove all fields that are never set in omap_hsmmc_info, hence never copied to platform data. Note that the omap_hsmmc driver is not affected by this patch those fields were completely unused. Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Andreas Fenkart <afenkart@gmail.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Andreas Fenkart authored
- omap mmc driver supports multiplexing, omap_mmc_hs doesn't this leads to one of the major confusions in the omap_hsmmc driver - platform data should be read-only for the driver most callbacks are not set by the omap3 platform init code while still required. So they are set from the driver probe function, which is against the paradigm that platform-data should not be modified by the driver typical examples are card_detect, read_only callbacks un-bundling by searching for driver name \"omap_hsmmc in the arch/arm folder. omap_hsmmc_platform_data is not initialized directly, but from omap2_hsmmc_info, which is defined in a separate header file not touched by this patch hwmod includes platform headers to declare features of the platform. All the declared features are prefixed OMAP_HSMMC. There is no need to include platform header from hwmod other except for feature defines Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Andreas Fenkart <afenkart@gmail.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Andreas Fenkart authored
Only a few files really need that platform header. When later splitting omap_mmc_platform_data into omap_mmc and omap_mmc_hs, those files declaring an hs mmc platform data will have to change the platform include, which is a good sanity check. Also removing omap242x_init_mmc, which is not used anywhere, checked with grep. Signed-off-by: Andreas Fenkart <afenkart@gmail.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Wenyou Yang authored
Amend the atmel mci pin controller to optionally take a pin control handle and set the state of the pins to: - "default" on boot, resume and before performing an transfer. - "sleep" on suspend(). This should make it possible to optimize energy usage for the pins both for the suspend/resume cycle. Signed-off-by: Wenyou Yang <wenyou.yang@atmel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Adrian Hunter authored
MMC core already has support for HS400. Add HS400 support to SDHCI driver. The SDHC Standard specification does not define HS400 so consequently HS400 support is non-standard. However HS400 is not selected without the host controller setting the corresponding capability flags so host controllers not yet supporting HS400 will not be affected. To support that, a quirk SDHCI_QUIRK2_CAPS_BIT63_FOR_HS400 is introduced to enable the use of capabilities register reserved bit-63 to indicate HS400 support. Because HS400 is non-standard for SDHCI, it is possible that different vendors will do things in different ways. However HS200 support faced the same issue but currently there is only one solution. As such, no attempt has been made to provide for alternate HS400 solutions except for SDHCI_QUIRK2_CAPS_BIT63_FOR_HS400. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Adrian Hunter authored
1.2V HS200 mode capability is cleared if there is not a voltage regulator that supports 1.2V. Do the same for 1.2V HS400 mode. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Adrian Hunter authored
supply.vqmmc is used with the IS_ERR macro which means the value must be valid or an error code. NULL is neither, so replace with ERR_PTR(-EINVAL). Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Adrian Hunter authored
SDHCI_CTRL_HS_SDR200 is unused. Remove it. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Prabu Thangamuthu authored
Synopsys DW_MMC IP core supports Internal DMA Controller with 64-bit address mode from IP version 2.70a onwards. Updated the driver to support IDMAC 64-bit addressing mode. Signed-off-by: Prabu Thangamuthu <prabu.t@synopsys.com> Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com> Acked-by: Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Vincent Wan authored
AMD SD controller supports the SDR104 mode, but caps2 can not be promoted to support hs200 for eMMC. Signed-off-by: Vincent Wan <vincent.wan@amd.com> Signed-off-by: Wan Zongshun <mcuos.com@gmail.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Vincent Wan authored
This patch is to enable the quirk for AMD sdhci requiring transfer mode register need to be cleared for commands without data Signed-off-by: Vincent Wan <vincent.wan@amd.com> Signed-off-by: Wan Zongshun <mcuos.com@gmail.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Vincent Wan authored
SDHC controller in AMD chipsets require SDHC transfer mode register to be cleared for commands without data. The issue was uncovered during testing eMMC cards on KB/ML based platforms Signed-off-by: Vincent Wan <vincent.wan@amd.com> Signed-off-by: Wan Zongshun <mcuos.com@gmail.com> Signed-off-by: Arindam Nath <arindam.nath@amd.com> Tested-by: Vikram B <vikram.b@amd.com> Tested-by: Raghavendra Swamy <raghavendra.swamy@amd.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
- 10 Nov, 2014 2 commits
-
-
Johan Rudholm authored
Signed-off-by: Johan Rudholm <johanru@axis.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-
Mark Brown authored
It is possible that we may fail to set the clock rate, if we do so then log the failure and don't bother reprogramming the IP. Signed-off-by: Mark Brown <broonie@linaro.org> Acked-by: Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
-