- 24 Feb, 2013 21 commits
-
-
Sascha Hauer authored
The 8bit in the function name is misleading. When set, it will be used to set the bus width, regardless of whether 8bit or another bus width is requested, so change the function name to platform_bus_width. Signed-off-by:
Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by:
Shawn Guo <shawn.guo@linaro.org> Tested-by:
Dirk Behme <dirk.behme@de.bosch.com> Signed-off-by:
Chris Ball <cjb@laptop.org>
-
Shawn Guo authored
SDHCI core will try to use Auto CMD23 for mmc card. Currently, we will see the following message with mmc card on usdhc due to the lacking of Auto CMD23 support in the driver. $ mmc0: new high speed MMC card at address 0001 mmcblk1: mmc0:0001 MMC02G 1.87 GiB mmcblk1: error -84 transferring data, sector 0, nr 8, cmd response 0x900, card status 0xb00 mmcblk1: retrying using single block read mmcblk1: Enable Auto CMD23 support for usdhc so that mmc card can work in multiple block mode. Signed-off-by:
-
Shawn Guo authored
It's another violation to SDHC spec that software reset on usdhc does not reset MIX_CTRL register. Have to do it manually, otherwise the preserving of the register bits (e.g. AC23EN) may cause mmc card fail to be initialized. Signed-off-by:
-
Shawn Guo authored
The combining of SDHCI_TRANSFER_MODE and SDHCI_COMMAND writes is only required for esdhc, but not necessarily for usdhc. Different from esdhc where the bits for transfer mode and command are all in the same register CMD_XFR_TYP, usdhc has a newly introduced register MIX_CTRL to hold transfer mode bits. So it makes more sense to separate transfer mode from command write for usdhc. Signed-off-by:
-
Maya Erez authored
Cache control is an eMMC feature and in therefore should be part of MMC's bus resume operations, performed in mmc_suspend, rather than in the generic mmc_suspend_host(). Signed-off-by:
Maya Erez <merez@codeaurora.org> Acked-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
-
Seungwon Jeon authored
Add maintainer entry for the Synopsys DW host driver which is used in various SOC including EXYNOS series. As Will Newton will no longer be able to take care of dw_mmc*, I and Jaehoon Chung are willing to maintain it. Signed-off-by:
Seungwon Jeon <tgih.jun@samsung.com> Signed-off-by:
Jaehoon Chung <jh80.chung@samsung.com> Acked-by:
Will Newton <will.newton@imgtec.com> Signed-off-by:
-
Fabio Estevam authored
3f175a6e5 (mmc: sdhci-esdhc-imx: remove ESDHC_CD_GPIO handling from IO accessory) introduced the following build warnings: drivers/mmc/host/sdhci-esdhc-imx.c:149:30: warning: unused variable 'boarddata' [-Wunused-variable] drivers/mmc/host/sdhci-esdhc-imx.c:181:30: warning: unused variable 'boarddata' [-Wunused-variable] Remove the unused variables. Signed-off-by:
Fabio Estevam <fabio.estevam@freescale.com> Acked-by:
-
Guennadi Liakhovetski authored
The file Documentation/devicetree/bindings/mmc/mmc.txt is common for all MMC host drivers. Use a generic MMC host reference instead of an SDHCI left-over. Signed-off-by:
Guennadi Liakhovetski <g.liakhovetski@gmx.de> Signed-off-by:
-
Shawn Guo authored
Rename esdhc local definitions with ESDHC_ rather than SDHCI_ prefix, so that we can distinguish them from SDHCI core definitions from name. A couple of bit fields are also changed use shift for consistency and better readability. Signed-off-by:
-
Shawn Guo authored
SDHCI_CTRL_D3CD is not a standard SDHCI_HOST_CONTROL, so there is no need to check it in SDHCI_HOST_CONTROL write at all. Remove it. Signed-off-by:
-
Shawn Guo authored
When commit 95a2482a (mmc: sdhci-esdhc-imx: add basic imx6q usdhc support) works around host version issue on imx6q, it gets the register address fixup "reg ^= 2" lost for imx25/35/51/53 esdhc. Thus, the controller version on these SoCs is wrongly identified as v1 while it's actually v2. Add the address fixup back and take a different approach to correct imx6q host version, so that the host version read gets back to work for all SoCs. Signed-off-by:
-
Tony Prisk authored
With the __devinit/__devexit attributes having been removed, this __exitp attribute causes an unused function warning and should be removed as well. Signed-off-by:
Tony Prisk <linux@prisktech.co.nz> Signed-off-by:
-
Doug Anderson authored
The original quirk was added in the change 'mmc: dw_mmc: add quirk to indicate missing write protect line'. The original quirk was added at a controller level even though each slot has its own write protect (so the quirk should be at the slot level). A recent change (mmc: dw_mmc: Add "disable-wp" device tree property) added a slot-level quirk and support for the quirk directly to dw_mmc. Signed-off-by:
Doug Anderson <dianders@chromium.org> Acked-by:
Olof Johansson <olof@lixom.net> Signed-off-by:
-
Doug Anderson authored
On some SoCs (like exynos5250) you need to use an external GPIO for write protect. Add support for wp-gpios to the core dw_mmc driver since it could be useful across multiple SoCs. With this change I am able to make use of the write protect for the external SD slot on exynos5250-snow. Signed-off-by:
-
Doug Anderson authored
The exynos code claimed the write protect with devm_gpio_request() but never did anything with it. That meant that anyone using a write protect GPIO would effectively be write protected all the time. The handling for wp-gpios belongs in the main dw_mmc driver and has been moved there. Signed-off-by:
-
Doug Anderson authored
The next change will remove the code from the dw_mmc-exynos that added the DW_MCI_QUIRK_NO_WRITE_PROTECT. Keep existing functionality of having no write protect pin on smdk5250 by adding the disable-wp property. Signed-off-by:
-
Doug Anderson authored
The "disable-wp" property is used to specify that a given SD card slot doesn't have a concept of write protect. This eliminates the need for special case code for SD slots that should never be write protected (like a micro SD slot or a dev board). The dw_mmc driver is special in needing to specify "disable-wp" because the lack of a "wp-gpios" property means to use the special purpose write protect line. On some other mmc devices the lack of "wp-gpios" means that write protect should be disabled. Signed-off-by:
-
Zhang, YiX X authored
The right value is 54 according to eMMC 4.5 specification. Signed-off-by:
ZhangYi <yix.x.zhang@intel.com> Signed-off-by:
-
Fabio Estevam authored
Fixes the following warning when building with W=1 option: drivers/mmc/host/mxs-mmc.c: In function 'mxs_mmc_adtc': drivers/mmc/host/mxs-mmc.c:401:2: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] The warning happens because 'i' is used in 'for_each_sg(sgl, sg, sg_len, i)' and should be made unsigned. Signed-off-by:
Marek Vasut <marex@denx.de> Signed-off-by:
-
Fabio Estevam authored
Add an entry for MODULE_ALIAS(). Signed-off-by:
-
Thomas Petazzoni authored
On many Marvell SoCs, the pins used for the SDIO interface are part of the MPP pins, that are muxable pins. In order to get the muxing of those pins correct, this commit integrates the mvsdio driver with the pinctrl infrastructure by calling devm_pinctrl_get_select_default() during ->probe(). Note that we permit this function to fail because not all Marvell platforms have yet been fully converted to using the pinctrl infrastructure. Signed-off-by:
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by:
Andrew Lunn <andrew@lunn.ch> Tested-by:
Stefan Peter <s.peter@mpl.ch> Tested-by:
Florian Fainelli <florian@openwrt.org> Signed-off-by:
Jason Cooper <jason@lakedaemon.net> Signed-off-by:
-
- 11 Feb, 2013 19 commits
-
-
Thomas Petazzoni authored
This patch adds a simple Device Tree binding for the mvsdio driver, as well as the necessary documentation for it. Compatibility with non-DT platforms is preserved, by keeping the platform_data based initialization. We introduce a small difference between non-DT and DT platforms: DT platforms are required to provide a clocks = <...> property, which the driver uses to get the frequency of the clock that goes to the SDIO IP. The behaviour on non-DT platforms is kept unchanged: a clock reference is not mandatory, but the clock frequency must be passed in the "clock" field of the mvsdio_platform_data structure. Signed-off-by:
-
Thomas Petazzoni authored
The MMC core subsystem provides in drivers/mmc/core/slot-gpio.c a nice set of helper functions to simplify the management of the card detect GPIO in MMC host drivers. This patch migrates the mvsdio driver to using those helpers, which will make the ->probe() code simpler, and therefore ease the process of adding a Device Tree binding for this driver. Signed-off-by:
-
Thomas Petazzoni authored
The MMC core subsystem provides in drivers/mmc/core/slot-gpio.c a nice set of helper functions to simplify the management of the write protect GPIO in MMC host drivers. This patch migrates the mvsdio driver to using those helpers, which will make the ->probe() code simpler, and therefore ease the process of adding a Device Tree binding for this driver. Signed-off-by:
-
Shawn Guo authored
With commit 9444e07 (mmc: remove unncessary mmc_gpio_free_cd() call from slot-gpio users) in place, the ESDHC_CD_GPIO handling in IO accessories becomes unnecessary. Remove it. Signed-off-by:
-
Andy Shevchenko authored
There are three places where same piece of code is used. Let's split it to a separate function. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
Kevin Liu authored
[cjb: The MMP3 architecture requires a registered interrupt to retire wfi when waking from suspend.] Signed-off-by:
Jialing Fu <jlfu@marvell.com> Signed-off-by:
Kevin Liu <kliu5@marvell.com> Signed-off-by:
-
Kevin Liu authored
Don't disable SD Host IRQ during suspend if it is wake up source. Enable wakeup event during suspend. Signed-off-by:
-
Kevin Liu authored
Current code missed disabling interrupts before free irq which is shared. Notice below comments for function free_irq (kernel/irq/manage.c): On a shared IRQ the caller must ensure the interrupt is disabled on the card it drives before calling this function. Original code has below issue during suspend/resume when multiple SD hosts share the same IRQ: 1. Assume there are two hosts (host1 for emmc while host2 for sd) share the same mmc irq. 2. When system suspend, host2 will be suspended before host1. So the sequence is below: step1: irq handler for host2 removed -> step2: irq handler for host1 removed and irq disabled -> ... system suspended ... ... system resumed ... step3: irq enabled and the irq handler for host1 restored -> step4: irq handler for host2 restored 3. So there is the buggy time slot that the irq is enabled but the irq handler for host2 is removed. Then host2 interrupt can be triggered but can't be handled at that moment. Signed-off-by:
-
Stephen Warren authored
Add a very simple driver for the BCM2835 SoC, which is used in the Raspberry Pi board. Signed-off-by:
Stephen Warren <swarren@wwwdotorg.org> Signed-off-by:
-
Konstantin Dorfman authored
When current request is running on the bus and if next request fetched by mmcqd is NULL, mmc context (mmcqd thread) gets blocked until the current request completes. This means that if new request comes in while the mmcqd thread is blocked, this new request can not be prepared in parallel to current ongoing request. This may result in delaying the new request execution and increase it's latency. This change allows to wake up the MMC thread on new request arrival. Now once the MMC thread is woken up, a new request can be fetched and prepared in parallel to the current running request which means this new request can be started immediately after the current running request completes. With this change read throughput is improved by 16%. Signed-off-by:
Konstantin Dorfman <kdorfman@codeaurora.org> Reviewed-by:
-
Seungwon Jeon authored
Unlike normal r/w request, special requests(discard, flush) is finished with a one-time issue_fn. Request change to mqrq_prev makes unnecessary call. Signed-off-by:
-
Guennadi Liakhovetski authored
The classical way to process IRQs is read out the status, ack all triggered IRQs, possibly mask them, then process them. Follow this simple procesure instead of the current complex custom algorithm. Signed-off-by:
-
Teppei Kamijou authored
Make error reporting in the driver more verbose. This patch is based on an earlier work by Teppei Kamijou, but we try to not add any new error messages to the log in the normal case to avoid confusing the user, and also add a few more dev_dbg() calls. Signed-off-by:
Teppei Kamijou <teppei.kamijou.yb@renesas.com> Signed-off-by:
Shinya Kuribayashi <shinya.kuribayashi.px@renesas.com> [g.liakhovetski@gmx.de: avoid producing new errors in normal case] Signed-off-by:
-
Guennadi Liakhovetski authored
The INT_BUFWEN IRQ often arrives with other bits set too. If they are not cleared, an additional IRQ can be triggered, sometimes also after the MMC request has already been completed. This leads to block I/O errors. Earlier Teppei Kamijou also observed these additional interrupts and proposed to explicitly wait for them. This patch chooses an alternative approach of clearing all active bits immediately, when processing the main interrupt. Reported-by:
-
Guennadi Liakhovetski authored
DMA completion can be signalled from the DMA callback and from the error handler. If both are called, the completion struct can enter an inconsistent state. To prevent this move completion initialisation immediately before activating DMA. Signed-off-by:
-
Guennadi Liakhovetski authored
If a command execution has produced an error, it has to be reset as a part of the error handling. Signed-off-by:
-
Guennadi Liakhovetski authored
Oopses have been observed on SMP in the sh-mmcif IRQ thread, when the two IRQ threads run simultaneously on two CPUs. Also take care to guard the timeout work and the DMA completion callback from possible NULL-pointer dereferences and races. Signed-off-by:
-
Guennadi Liakhovetski authored
Use "return condition" instead of "if (condition) return true; return false" in functions, returning bool. Signed-off-by:
-
Teppei Kamijou authored
If a DMA transaction fails, terminate all outstanding DMA transfers and unmap buffers. Signed-off-by:
-
