- 04 Apr, 2013 2 commits
-
-
Kevin Liu authored
sdhci_pltfm_init can set host->ops and host->quirks if sdhci_pltfm_data is transfered as arguments. Then no need to set them manually in sdhci_pxav3_probe. Signed-off-by:
Kevin Liu <kliu5@marvell.com> Acked-by:
Haojian Zhuang <haojian.zhuang@gmail.com> Signed-off-by:
Chris Ball <cjb@laptop.org>
-
Seungwon Jeon authored
mci_writew causes a failure of fifo access for 64-bit. mci_writeq is correct. Signed-off-by:
Seungwon Jeon <tgih.jun@samsung.com> Acked-by:
Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by:
-
- 22 Mar, 2013 35 commits
-
-
Thomas Petazzoni authored
The mvsdio driver was already using some dev_*() functions to print some messages, but still using pr_*() functions for some others. This patch converts all messages to use dev_*() functions. Many of the pr_*() function calls were printing the output of mmc_hostname() to preprend the message with an identifier for the device. Since the dev_*() functions do that automatically, this patch also gets rid of those string prefixes. Signed-off-by:
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by:
-
Thomas Petazzoni authored
Ralph Droms <rdroms@gmail.com> reported that 3.9-rc was breaking the SDIO interface on his Sheevaplug platform, and that the recent changes to the mvsdio driver are responsible for this breakage. Precisely, the regression has been introduced by 07728b77 (mmc: mvsdio: use slot-gpio for card detect gpio). After investigation, is turns out that the Sheevaplug does not have any "card detect" GPIO, and the Sheevaplug has not been converted to the Device Tree. Therefore, the Sheevaplug board code does not define a value for the .gpio_card_detect field of the mvsdio_platform_data structure, which means that its value is 0. Unfortunately, gpio_is_valid() considers 0 as a valid GPIO, and therefore calls mmc_gpio_request_cd(), which fails and makes the entire probing of the driver fail. In fact, in the previous mvsdio code, before the Device Tree binding was introduced, 0 was not considered as a valid GPIO. Therefore, this fix revert back to this behavior in the non-DT case, by setting the gpio_card_detect and gpio_write_protect local variables to -EINVAL when the corresponding fields of the mvsdio_platform_data structure are set to zero (i.e, left undefined). Of course, it prevents to use GPIO 0 as a card detect or write protect GPIO, but it was a defiency of the previous non-DT code, and the fix moving forward is to convert platforms to the Device Tree. The problem has been reproduced successfully on the Kirkwood-based Marvell DB-88F6281-BP Development Board (that doesn't use the Device Tree) and the fix has proven to work properly, after of course removing the gpio_card_detect field of the mvsdio_platform_data instance for this board. Reported-by:
Ralph Droms <rdroms@gmail.com> Tested-by:
-
Barry Song authored
This patch adds the new driver for CSR SiRF SoCs: SiRFprimaII: unicore ARM Cortex-A9 SiRFatlas6: unicore ARM Cortex-A9 SiRFmarco: dual core ARM Cortex-A9 SMP Signed-off-by:
Barry Song <Baohua.Song@csr.com> Signed-off-by:
Bin Shi <Bin.Shi@csr.com> Acked-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Seungwon Jeon authored
For normal request mmc_blk_issue_rq is called twice with asynchronous transfer(cur and prev). Host's claim and release can be done in each mmc_blk_issue_rq. However, Special request is currently excluded in asynchronous transfer. After special request is finished, if there is no new request, mmc_release_host won't be called in mmc_blk_issue_rq. The problem is founded during mmc_suspend. [<c0541124>] (__schedule+0x0/0x78c) from [<c05419e8>] (schedule+0x38/0x78) [<c05419b0>] (schedule+0x0/0x78) from [<c03a843c>] (__mmc_claim_host+0xac/0x1b4) [<c03a8390>] (__mmc_claim_host+0x0/0x1b4) from [<c03ac98c>] (mmc_suspend+0x28/0x9c) [<c03ac964>] (mmc_suspend+0x0/0x9c) from [<c03aad24>] (mmc_suspend_host+0xb4/0x194) ... Reported-by:
Johan Rudholm <jrudholm@gmail.com> Signed-off-by:
Johan Rudholm <johan.rudholm@stericsson.com> Signed-off-by:
-
Sergey Yanovich authored
MMC hosts are added asynchronously. We need to wait until detect returns to avoid failed root filesystem mounts. VFS: Cannot open root device "mmcblk0p1" or unknown-block(0,0): error -6 Please append a correct "root=" boot option; here are the available partitions: mmc0: host does not support reading read-only switch. assuming write-enable. 1f00 256 mtdblock0 (driver?) 1f01 256 mtdblock1 (driver?) 1f02 2560 mtdblock2 mmc0: new SDHC card at address b368 (driver?) 1f03 29696 mtdblock3 (driver?) 1f04 16384 mtdblock4 mmcblk0: mmc0:b368 USD 3.72 GiB (driver?) mmcblk0: p1 b300 3910656 mmcblk0 driver: mmcblk b301 3906560 mmcblk0p1 00000000-01 Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) Signed-off-by:
Sergey Yanovich <ynvich@gmail.com> Signed-off-by:
-
Lars-Peter Clausen authored
Basically all drivers can have sdhci_ops struct const, but almost none do. This patch constifies all sdhci_ops struct declarations where possible. The patch was auto-generated with the following coccinelle semantic patch: // <smpl> @r1@ identifier ops; identifier fld; @@ ops.fld = ...; @disable optional_qualifier@ identifier ops != r1.ops; @@ static +const struct sdhci_ops ops = { ... }; // </smpl> Signed-off-by:Lars-Peter Clausen <lars@metafoo.de> Acked-by:
Shawn Guo <shawn.guo@linaro.org> Signed-off-by:
-
Lars-Peter Clausen authored
All users of the sdhci_ops struct in the sdhci core already treat it as const. The sdhci-pltfm code itself never actually looks at the ops field of the sdhci_pltfm_data struct and merely passes it on to the sdhci core, so make we can make it const in the sdhci_pltfm_data struct as well. This allows us to declare sdhci_ops structs as const in drivers using the sdhci-pltfm helper code. Signed-off-by:
-
Lars-Peter Clausen authored
The sdhci_pltfm_data struct is never modified within the sdhci_pltfm module. So make the pdata parameter to sdhci_pltfm_init and sdhci_pltfm_register const. This allows drivers to declare their sdhci_pltfm_data struct as const. This patch also makes the sdhci_pltfm_data declarations const where possible. Signed-off-by:
-
Johan Hovold authored
Fix regression introduced by commit 796211b7 ("mmc: atmel-mci: add pdc support and runtime capabilities detection") which removed the need for CONFIG_MMC_ATMELMCI_DMA but kept the Kconfig-entry as well as the compile guards around dma_release_channel() in remove(). Consequently, DMA is always enabled (if supported), but the DMA-channel is not released on module unload unless the DMA-config option is selected. Remove the no longer used CONFIG_MMC_ATMELMCI_DMA option completely. Signed-off-by:
Johan Hovold <jhovold@gmail.com> Acked-by:
Ludovic Desroches <ludovic.desroches@atmel.com> Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Dongjin Kim authored
This patch adds the compatible string for MSHC controller of Exynos4412. And exynos5250_dwmmc_caps is renamed to exynos_dwmmc_caps, since it has the capabilities of common features supported by Exynos4 and Exynos5. Signed-off-by:
Dongjin Kim <tobetter@gmail.com> Acked-by:
-
Sachin Kamat authored
'dw_mci_exynos_match' is always compiled in. Hence of_match_ptr is not required. Signed-off-by:
Sachin Kamat <sachin.kamat@linaro.org> Acked-by:
-
Silviu-Mihai Popescu authored
Use resource_size() instead of explicit calculation. This was found via make coccicheck. Signed-off-by:
Silviu-Mihai Popescu <silviupopescu1990@gmail.com> Signed-off-by:
-
Markos Chandras authored
Commit f9c2a0dc "mmc: dw_mmc: Fix PIO mode with support of highmem" introduced a regression since v3.2 making the mmc_test hang on test #13 with a "Data starvation by host timeout" interrupt. This is because, sg_mapping_iter is used to iterate through the data which spans on multiple pages. The problem is detected on unaligned data submission where the code previously checked for !(sg_next(host->sg)) which is true because we only have a single scatter/gather list which then expands to multiple pages. Therefore, the driver incorrectly assumed that this was the last list item and submitted unaligned data to the mmc device. This overflowed the FIFO on the device before all the data were written to it. The code was fixed to only submit unaligned data when we are handling the last sg_miter item by checking whether we reached the desired data length or not. The patch was tested against mmc_test and all the tests passed. Signed-off-by:
Markos Chandras <markos.chandras@imgtec.com> Acked-by:
-
Markos Chandras authored
Previously, it was possible to add either 0 bytes or add nbytes twice if we broke out of the outer loop and then carry on to the "done" label. This is now fixed by adding the transferred bytes right after the pull/pop operation Signed-off-by:
-
Markos Chandras authored
There is no reason to loop when handling an interrupt. The "if" clauses will handle all of them sequentially. This also eliminates the extra loop we used to take with no pending interrupts and we ended up breaking out of the while loop. Signed-off-by:
-
James Hogan authored
host->data_offset is initialised at the end of the probe function depending on the VERID register, and is used for PIO operations. Move this initialisation earlier, before IRQs or slots are initialised, to be sure that PIO won't occur prior to host->data_offset being initialised. Signed-off-by:
James Hogan <james.hogan@imgtec.com> Acked-by:
-
James Hogan authored
Call the setpower platform callback in response to set_ios with ios->power_mode == MMC_POWER_UP or MMC_POWER_OFF, instead of from the card detect work function. This appears to fix a problem I have where a card stuck in a funny state doesn't get properly cleared by the power being turned off, presumably due to lack of power sequencing. This resulted in the following log messages after boot: mmc0: error -110 whilst initialising SD card mmc_host mmc0: Bus speed (slot 0) = 99840000Hz (slot req 300000Hz, actual 298922HZ div = 167) mmc0: error -110 whilst initialising SD card mmc_host mmc0: Bus speed (slot 0) = 99840000Hz (slot req 200000Hz, actual 199680HZ div = 250) mmc0: error -110 whilst initialising SD card mmc_host mmc0: Bus speed (slot 0) = 99840000Hz (slot req 195765Hz, actual 195764HZ div = 255) mmc0: error -110 whilst initialising SD card mmc_host mmc0: Bus speed (slot 0) = 99840000Hz (slot req 400000Hz, actual 399360HZ div = 125) mmc0: error -110 whilst initialising SD card mmc_host mmc0: Bus speed (slot 0) = 99840000Hz (slot req 300000Hz, actual 298922HZ div = 167) Signed-off-by:
-
Chris Ball authored
Fixes: /git/arm-soc/drivers/mmc/host/sdhci.c: In function 'sdhci_add_host': /git/arm-soc/drivers/mmc/host/sdhci.c:2910:19: warning: ignoring return value of 'regulator_enable', declared with attribute warn_unused_result [-Wunused-result] Reported-by:
-
Alexandru Gheorghiu authored
Used resource_size function instead of explicit computation. Patch found using coccinelle. Signed-off-by:
Alexandru Gheorghiu <gheorghiuandru@gmail.com> Signed-off-by:
-
Wei Yongjun authored
The variable 'mmc' is initialized but never used, so remove it. Signed-off-by:
Wei Yongjun <yongjun_wei@trendmicro.com.cn> Acked-by:
Tony Prisk <linux@prisktech.co.nz> Signed-off-by:
-
Chunhe Lan authored
This patch fixes timeout problems on t4240's sdhci controller: mmc0: Too large timeout requested for CMD25! mmc0: Too large timeout requested for CMD25! mmc0: Too large timeout requested for CMD25! Signed-off-by:
Chunhe Lan <Chunhe.Lan@freescale.com> Signed-off-by:
-
Wei WANG authored
For some Realtek card readers, the power up sequence can only be executed when power has been turned off fully. So the rtsx host should not start power up sequence again when set_ios been called if the power has been turned on. Signed-off-by:
Wei WANG <wei_wang@realsil.com.cn> Signed-off-by:
-
Thomas Abraham authored
With device core now able to setup the default pin configuration, the call to devm_pinctrl_get_select_default can be removed. And the pin configuration code based on the deprecated Samsung specific gpio bindings is also removed. Signed-off-by:
Thomas Abraham <thomas.abraham@linaro.org> Acked-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Jingoo Han authored
This patch uses module_platform_driver_probe() macro which makes the code smaller and simpler. Signed-off-by:
Jingoo Han <jg1.han@samsung.com> Signed-off-by:
-
Jingoo Han authored
This patch uses module_platform_driver_probe() macro which makes the code smaller and simpler. Signed-off-by:
-
Aaron Lu authored
ACPI spec 5 defined the _ADR encoding for sdio bus as: High word - slot number (0 based) Low word - function number This patch adds support for binding sdio function device with acpi node, and if successful, involve acpi into its power management. Signed-off-by:
Aaron Lu <aaron.lu@intel.com> Reviewed-by:
Adrian Hunter <adrian.hunter@intel.com> Signed-off-by:
-
Kevin Liu authored
1. mmc_rescan will call get_cd to know whether the card is present before mmc_rescan_try_freq to avoid useless trials during card removal or start host is called when card is not present. 2. get_cd needs to be checked to resolve slow card removal issue. Signed-off-by:
-
Kevin Liu authored
Function _mmc_detect_card_removed will be called to know whether the card is still present when host->bus_ops->detect is called. In current code, the return value of this function generally only depend on the result of sending cmd13 to card, which may not safe for card with detection support like slot gpio detection. Because the communication status between host and card may out of sync with the detect status if remove the card slowly or hands shake during the process. The direct reason is the async between card detect switch and card/slot pad contaction in hardware, which is defined by spec. The spec define card insert/remove sequence as below (both standard size SD card and MicroSD card have the same sequence): "Part 1 Standard Size SD Card Mechanical Addendum Ver4.00 Final, Appendix C: Card Detection Switch" (Take normally open type as example) a)SD card insertion sequence: The card detection switch should be turned on after all SD card contact pads are connected to the host connector contact pads. b)SD removal sequence: The card detection switch should be turned off when the SD card is just going to be removed and before any SD card contact pad is disconnected from the host connector contact pad. Below is the sequence when this issue occur (Take slot gpio detection as example and remove the card slowly during the process): 1. gpio level changed and card detect interrupt triggered. 2. mmc_rescan was launched. 3. the card pads were still contacted with the slot pads because of slow removal. So _mmc_detect_card_removed and mmc_rescan think card was still present (cmd13 succeed). 4. card pads were discontacted from the card slot pads. So the card was actually removed finally but the card removal event has been missed by system. The interval length between step 1 and step 4 depends on the card removal speed. If it's longer than the detect work schedule delay which is 200ms, this issue will likely happen. This patch add the card detect status check in function _mmc_detect_card_removed if cmd13 check succeed and host->ops->get_cd provided. If get_cd detect no card present then schedule another detect work 200ms later. Signed-off-by:
Philip Rakity <prakity@nvidia.com> Acked-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
-
Bernie Thompson authored
The JEDEC MMC v4 spec defines a new PRV value in place of the original fwrev and hwrev specified in v1. We can expose this in the kernel to enable user space to more easily determine the product revision of a given MMC. Signed-off-by:
Bernie Thompson <bhthompson@chromium.org> Reviewed-by:
-
Manjunathappa, Prakash authored
Do not return probe failure with missing DMA resources, allow driver to work in PIO mode. Tested on da850-evm by mounting partition followed by file creation and deletion. Signed-off-by:
Manjunathappa, Prakash <prakash.pm@ti.com> Tested-by:
Sekhar Nori <nsekhar@ti.com> Signed-off-by:
-
Hyeonsu Kim authored
In the legacy code, driver clear not only UHS_REG 16 bit also 0-15bit. If we use UHS-1 mode spec card like SDR50, SDR104. UHS_REG 0-15 should be set by 1 according to slot id. In this case, legacy code can cause problems. In particular, UHS_REG consists of DDR_REG[31:16] and VOLT_REG[15:0]. Before adjusting this patch, bit[15:0] is always cleared. Signed-off-by:
Hyeonsu Kim <hyeonsu.kim@samsung.com> Acked-by:
-
Kyoungil Kim authored
In dwc manual, the below contents are described: "During end of packet, interrupt is not generated if threshold programming is larger than any remaining data. It is responsibility of host to read remaining bytes on seeing Data Transfer Done interrupt" We also have seen the data cannot be read fully when "sg_miter->length" is less than FIFO size. Signed-off-by:
Kyoungil Kim <ki0351.kim@samsung.com> Signed-off-by:
-
Jaehoon Chung authored
Check the result of mmc_add_host() and return the value. Signed-off-by:
-
Jingoo Han authored
Use devm_clk_get() rather than clk_get() to make cleanup paths more simple. Signed-off-by:
-
Jan Luebbe authored
If the CD/WP-GPIOs are not provided by the SoC's GPIO controller, we need to handle the case where omap_hsmmc is probed earlier than the GPIO controller chosen in the device tree. Fix this by checking the return value of of_get_named_gpio against -EPROBE_DEFER and passing it through to the probe function. Signed-off-by:
Jan Luebbe <jlu@pengutronix.de> Acked-by:
Balaji T K <balajitk@ti.com> Signed-off-by:
-
- 19 Mar, 2013 2 commits
-
-
Joseph Lo authored
Updating the sdhci-tegra driver to use mmc_of_parse to support standard MMC DT bindings. Then we can remove the redundant code that already support in generic MMC core. Signed-off-by:
Joseph Lo <josephl@nvidia.com> Tested-by:
Thierry Reding <thierry.reding@avionic-design.de> Signed-off-by:
Stephen Warren <swarren@nvidia.com> Signed-off-by:
-
Chris Ball authored
Merge tag 'tegra-for-3.10-fixes-for-mmc' of git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra into mmc-next ARM: tegra: DT-related fixes needed by the MMC tree In order to convert the Tegra MMC driver to using mmc_of_parse(), some bugs in the Tegra device-tree content need to be fixed first; it's currently wrong but unused, and mmc_of_parse() causes that data to be used for the first time.
-
- 12 Mar, 2013 1 commit
-
-
Sachin Kamat authored
Silences the following sparse warning: drivers/mmc/host/dw_mmc-exynos.c:218:5: warning: symbol 'dw_mci_exynos_probe' was not declared. Should it be static? Signed-off-by:
-
