- 27 Mar, 2012 40 commits
-
-
Guennadi Liakhovetski authored
Purely cosmetic readability improvement, no functional change. Signed-off-by:
Guennadi Liakhovetski <g.liakhovetski@gmx.de> Signed-off-by:
Chris Ball <cjb@laptop.org>
-
Guennadi Liakhovetski authored
Currently if a platform wants to implement a non-standard card-detection method, it would need to call tmio_mmc_cd_wakeup(), which is an inline function, calling mmc_detect_change(). For this the platform would have to link mmc_core statically into the kernel, losing the ability to build it as a module. This patch adds a callback to the sh_mobile_sdhi driver, which eliminates this dependency. Signed-off-by:
Magnus Damm <damm@opensource.se> Signed-off-by:
-
Bastian Hecht authored
Some boards need a preliminary setup stage to prepare the sdhi controller. Signed-off-by:
Bastian Hecht <hechtb@gmail.com> Signed-off-by:
-
Guennadi Liakhovetski authored
Signed-off-by:
-
Guennadi Liakhovetski authored
On sh-mobile platforms the MMC clock frequency for the TMIO MMC unit is obtained from the same clock, as the one, that runtime power-manages the controller. The SDHI glue code has to access that clock directly, bypassing the runtime PM framework, to get its frequency, but it shouldn't enable or disable it. Signed-off-by:
-
Guennadi Liakhovetski authored
The sdio_irq_enabled member of struct tmio_mmc_host is a left-over from the previously removed SDIO IRQ workaround. It is no longer needed and can now be removed too. Signed-off-by:
-
Guennadi Liakhovetski authored
The controller power status flag does not have to be accessed from the hot-plug detection code any more, it can now be removed from the platform data and put in the controller private struct. Signed-off-by:
-
Guennadi Liakhovetski authored
To use TMIO MMC driver ability to interface to the generic MMC GPIO card hotplug detection helper, the SDHI driver has to pass the GPIO number from its own platform data. Signed-off-by:
-
Guennadi Liakhovetski authored
If the platform specifies the TMIO_MMC_HAS_COLD_CD flag, use the generic MMC GPIO card hotplug helper. Signed-off-by:
-
Guennadi Liakhovetski authored
The condition, whether we have to use the native TMIO card hotplug detection interrupt, is rather complex, it is better to only calculate it once and store in the private data. Signed-off-by:
-
Guennadi Liakhovetski authored
Calculate the IRQ number, using gpio_to_irq() and use fixed flags: trigger on both edges. This makes two out of four arguments of the mmc_cd_gpio_request() function redundant. Signed-off-by:
-
Alexander Stein authored
Signed-off-by:
Alexander Stein <alexander.stein@systec-electronic.com> Signed-off-by:
-
Alexander Stein authored
When using MSI it is possible that a new MSI is sent while an earlier MSI is currently handled. In this case SDHCI_INT_STATUS only contains SDHCI_INT_RESPONSE and the ISR would not be called again. But at the end of the ISR SDHCI_INT_DATA_END is now also pending which would be ignored. Fix this by rereading the interrupt flags in the ISR until no interrupt we care is pending. Signed-off-by:
Adrian Hunter <adrian.hunter@intel.com> Signed-off-by:
-
Alexander Stein authored
Signed-off-by:
-
Jaehoon Chung authored
Someone could use send_hpi_cmd() on a card that doesn't advertise support for HPI. Then maybe didn't work fine. Because card->ext_csd.hpi_cmd didn't set. So if card didn't support hpi, return the warning message. And CMD12's flags is MMC_RSP_R1B. Signed-off-by:
Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by:
Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by:
-
Ido Yariv authored
For small size non-dma sdio transactions, it is sometimes better to poll the mmc host and avoid interrupts altogether. Polling lowers the number of interrupts and context switches. Tests have shown that for small transactions, only a few polling iterations are needed, so this is worth while. Signed-off-by:
Ido Yariv <ido@wizery.com> Tested-by:
Rajashekhara, Sudhakar <sudhakar.raj@ti.com> Signed-off-by:
-
Ido Yariv authored
The davinci mmc interrupt handler fills the fifo, as long as the DXRDY or DRRDY bits are set in the status register. If interrupts fire during this loop, they will be handled by the handler, but the interrupt controller will still buffer these. As a result, the handler will be called again to serve these needlessly. In order to avoid these spurious interrupts, keep interrupts masked while filling the fifo. Signed-off-by:
-
Rajendra Nayak authored
When booting with Device tree, the omap_hsmmc driver does not program the pbias cell (inside OMAP control module) during a regulator voltage change. In case of non-dt boot, this is handled using callbacks from within platform_data and implemented in machine code. To be able to do this with device tree, without invoking any machine code, a OMAP control module driver is needed which is yet missing. The pbias cell is used to provide a 1.8v or 3.0v reference to the mmc/sd/sdio1 interface supporting both 1.8v and 3.0v voltages. Until a OMAP control module driver is available to handle this, when booting with a device tree blob, never change the regulator voltage which might then require a pbias cell re-program. There are 2 instances where in the mmc regulator voltage can be changed. -1- when the regulator is turned OFF. -2- when attempting a switch to 1.8v from 3.0v for dual volt cards This patch avoids a voltage change in both cases when booting from device tree, and hence compromises on power savings. Once the OMAP control module driver is available and hsmmc driver is modified to then do pbias programming even when booting with device tree, these limitaions can be removed to achieve better power savings. Signed-off-by:
Rajendra Nayak <rnayak@ti.com> Tested-by:
Balaji T K <balajitk@ti.com> Signed-off-by:
-
Rajendra Nayak authored
Define dt bindings for the ti-omap-hsmmc, and adapt the driver to extract data (which was earlier passed as platform_data) from device tree. Signed-off-by:
Rob Herring <rob.herring@calxeda.com> Signed-off-by:
-
Adrian Hunter authored
SDIO is powered separately from the host controller, so the card can remain on while the host controller is powered off during suspend. Signed-off-by:
-
Adrian Hunter authored
Add quirk SDHCI_QUIRK2_HOST_OFF_CARD_ON to cater for the case when the card keeps power during suspend but the host controller does not i.e. the card power is not controlled by the host controller. In that case, the controller must be fully reset on resume. Signed-off-by:
-
Adrian Hunter authored
Signed-off-by:
-
Adrian Hunter authored
Let drivers specify the use of high-capacity erase size. Signed-off-by:
-
Rajendra Nayak authored
Convert all instances of pr_* prints within the driver to instead use dev_* prints. Reported-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
-
Shimoda, Yoshihiro authored
The MMC_GEN_CMD (CMD56) doesn't need to check busy signal. So, the patch fixes the setting. Signed-off-by:
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by:
-
Subhash Jadavani authored
This patch fixes following issues when HS200 is enabled: 1. If executing_tuning() host ops is called without mmc_host_clk_hold(), card clocks might get turned off (if MMC_CLK_GATING is enabled) while execute_tuning() is in progress. So this patch makes sure that execute_tuning() is called with mmc_host_clk_hold(). 2. If host timing mode is set to HS200 mode, there should not be any communication with the card until execute_tuning() is completed. But there is a chance that CMD6 might be sent to enable set HPI_EN (of HPI_MGMT field in EXT_CSD) before execute_tuning() is called. So this patch moves this operation after execute_tuning() is completed. Signed-off-by:
Subhash Jadavani <subhashj@codeaurora.org> Reviewed-by: girish.shivananjappa@linaro.org Signed-off-by:
-
Tony Lindgren authored
Otherwise we can get following warning when re-loading the omap_hsmmc driver module when gpio_twl4030 module is not loaded: omap_hsmmc omap_hsmmc.0: Unbalanced pm_runtime_enable! omap_hsmmc omap_hsmmc.0: Unable to grab MMC CD IRQ omap_hsmmc: probe of omap_hsmmc.0 failed with error -22 Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
Ulf Hansson authored
Make sure mmc_start_req cancels the prepared job, if the request was prevented to be started due to the card has been removed. This bug was introduced in commit: mmc: allow upper layers to know immediately if card has been removed Signed-off-by:
Ulf Hansson <ulf.hansson@stericsson.com> Reviewed-by:
Per Forlin <per.forlin@stericsson.com> Tested-by:
-
Adrian Hunter authored
Most parts of the enable / disable API are no longer used and can be removed. Signed-off-by:
Venkatraman S <svenkatr@ti.com> Tested-by:
-
Shiraz Hashim authored
Signed-off-by:
Shiraz Hashim <shiraz.hashim@st.com> Signed-off-by:
-
Guennadi Liakhovetski authored
If TMIO MMC is used in polling mode, or the card is non-removable, or card-detection is performed, using an external interrupt, there is no need to enable controller native card hotplug interrupts. Signed-off-by:
-
Rajendra Nayak authored
MMC1 is not the only instance that can be used/wired for SD. So remove this assumption from the driver. Now that all the mmc id based usage is removed, get rid of all the DEVID defines and also the 'id' field from the omap_hsmmc_host structure. Signed-off-by:
-
Rajendra Nayak authored
Now that omap_hsmmc_set_power() already has a check to return 0 if !host->vcc, it seems like it can be used even on MMC4 instead of the dummy omap_hsmmc_4_set_power(). This also helps get rid of all the host->id based check to populate the right function for on-chip/external level shifting and use omap_hsmmc_set_power() for all MMC modules. Signed-off-by:
-
Rajendra Nayak authored
Use omap_hsmmc_235_set_poweri() (now renamed as omap_hsmmc_set_power()) for MMC1 instance as well and get rid of omap_hsmmc_1_set_power() completely. omap_hsmmc_235_set_power() seems to be implemented as a superset of omap_hsmmc_1_set_power() with additional functionality implemented based on additional checks and hence should just work for MMC1 as well. Signed-off-by:
-
Balaji T K authored
Use OMAP_HSMMC_SUPPORTS_DUAL_VOLT flag instead of host->id for identifying SD bus voltage capabilities. Signed-off-by:
-
Balaji T K authored
set_sleep seems to be unused in omap_hsmmc driver. so get rid of it. Signed-off-by:
-
Balaji T K authored
Git rid of hardcoded tx/rx DMA channels based on pdev->id and use platform_get_resource_byname() to retrieve them instead. Signed-off-by:
-
Ulf Hansson authored
To prevent I/O as soon as possible at card removal, a new detect work is re-scheduled without a delay to let a rescan remove the card device as soon as possible. Additionally, MMC_CAP2_DETECT_ON_ERR can now be used to handle "slowly" removed cards that a scheduled detect work did not detect as removed. To prevent further I/O requests for these lingering removed cards, check if card has been removed and then schedule a detect work to properly remove it. Signed-off-by:
Namjae Jeon <linkinjeon@gmail.com> Acked-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Seungwon Jeon authored
3ec7699d3bb1b0ee7 ("mmc: dw_mmc: Add support for pre_req and post_req") broke non-IDMAC DMA, because dw_mci_pre_dma_transfer() is valid only if using internal DMA. In case of using other DMA it returns -ENOSYS. It prevents the DMA operations. This patch makes dw_mci_pre_dma_transfer() effective in all DMA cases again. Reported-by:James Hogan <james@albanarts.com> Signed-off-by:
Seungwon Jeon <tgih.jun@samsung.com> Reviewed-by:
James Hogan <james.hogan@imgtec.com> Signed-off-by:
-
Jaehoon Chung authored
When disable CONFIG_MMC_DW_IDMAC, can see the compiler error. Because in dw_mci_post_req(), called the dw_mci_get_dma_dir(). But that function is in #ifdef CONFIG_MMC_DW_IDMAC. I think that function is generic function. Not need the CONFIG_MMC_DW_IDMAC. Signed-off-by:
-
