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: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: NChris Ball <cjb@laptop.org>

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: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: NChris Ball <cjb@laptop.org>

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: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: NChris Ball <cjb@laptop.org>

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: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: NChris Ball <cjb@laptop.org>

If the platform specifies the TMIO_MMC_HAS_COLD_CD flag, use the generic
MMC GPIO card hotplug helper.
Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: NChris Ball <cjb@laptop.org>

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: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: NChris Ball <cjb@laptop.org>

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: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: NChris Ball <cjb@laptop.org>

Signed-off-by: NAlexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

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: NAlexander Stein <alexander.stein@systec-electronic.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Signed-off-by: NAlexander Stein <alexander.stein@systec-electronic.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

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: NJaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

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: NIdo Yariv <ido@wizery.com>
Tested-by: NRajashekhara, Sudhakar <sudhakar.raj@ti.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

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: NIdo Yariv <ido@wizery.com>
Tested-by: NRajashekhara, Sudhakar <sudhakar.raj@ti.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

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: NRajendra Nayak <rnayak@ti.com>
Tested-by: NBalaji T K <balajitk@ti.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

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: NRajendra Nayak <rnayak@ti.com>
Acked-by: NRob Herring <rob.herring@calxeda.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

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: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

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: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Let drivers specify the use of high-capacity erase size.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Convert all instances of pr_* prints within the driver
to instead use dev_* prints.
Reported-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NRajendra Nayak <rnayak@ti.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

The MMC_GEN_CMD (CMD56) doesn't need to check busy signal.
So, the patch fixes the setting.
Signed-off-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

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: NSubhash Jadavani <subhashj@codeaurora.org>
Reviewed-by: girish.shivananjappa@linaro.org
Signed-off-by: NChris Ball <cjb@laptop.org>

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: NTony Lindgren <tony@atomide.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

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: NUlf Hansson <ulf.hansson@stericsson.com>
Reviewed-by: NPer Forlin <per.forlin@stericsson.com>
Tested-by: NJaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Most parts of the enable / disable API are no longer used and
can be removed.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Tested-by: NVenkatraman S <svenkatr@ti.com>
Tested-by: NJaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Signed-off-by: NShiraz Hashim <shiraz.hashim@st.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

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: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: NChris Ball <cjb@laptop.org>

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: NRajendra Nayak <rnayak@ti.com>
Tested-by: NVenkatraman S <svenkatr@ti.com>
Tested-by: NBalaji T K <balajitk@ti.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

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: NRajendra Nayak <rnayak@ti.com>
Tested-by: NVenkatraman S <svenkatr@ti.com>
Tested-by: NBalaji T K <balajitk@ti.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

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: NRajendra Nayak <rnayak@ti.com>
Tested-by: NVenkatraman S <svenkatr@ti.com>
Tested-by: NBalaji T K <balajitk@ti.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Use OMAP_HSMMC_SUPPORTS_DUAL_VOLT flag instead of host->id
for identifying SD bus voltage capabilities.
Signed-off-by: NBalaji T K <balajitk@ti.com>
Signed-off-by: NRajendra Nayak <rnayak@ti.com>
Tested-by: NVenkatraman S <svenkatr@ti.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

set_sleep seems to be unused in omap_hsmmc driver. so get rid of it.
Signed-off-by: NBalaji T K <balajitk@ti.com>
Signed-off-by: NRajendra Nayak <rnayak@ti.com>
Tested-by: NVenkatraman S <svenkatr@ti.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

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: NBalaji T K <balajitk@ti.com>
Signed-off-by: NRajendra Nayak <rnayak@ti.com>
Tested-by: NVenkatraman S <svenkatr@ti.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

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: NUlf Hansson <ulf.hansson@stericsson.com>
Reviewed-by: NNamjae Jeon <linkinjeon@gmail.com>
Acked-by: NLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

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: NJames Hogan <james@albanarts.com>
Signed-off-by: NSeungwon Jeon <tgih.jun@samsung.com>
Reviewed-by: NNamjae Jeon <linkinjeon@gmail.com>
Acked-by: NJames Hogan <james.hogan@imgtec.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

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: NJaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Acked-by: NSeungwon Jeon <tgih.jun@samsung.com>
Acked-by: NJames Hogan <james.hogan@imgtec.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

External circuitry like level shifters may limit the maximum operation
speed of the hsmmc controller. Add a field to struct omap2_hsmmc_info
so boards can adjust the setting on demand.
Signed-off-by: NDaniel Mack <zonque@gmail.com>
Acked-by: NTony Lindgren <tony@atomide.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Signed-off-by: NLudovic Desroches <ludovic.desroches@atmel.com>
Signed-off-by: NNicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

In CLKENA register, can support 16-SD card clocks.
If support correctly, must shift with slot-id.
Signed-off-by: NJaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Acked-by: NWill Newton <will.newton@imgtec.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

SD card read was failing (data crc error) on some cards at
maximum possible frequency on P1010 (CCB frequency set to 400MHz).
Some clock deviations are also observed at this frequency.
Hence reduced the mmc clock freq.
Signed-off-by: NPriyanka Jain <Priyanka.Jain@freescale.com>
Singed-off-by: NJerry Huang <Chang-Ming.Huang@freescale.com>
Acked-by: NAnton Vorontsov <cbouatmailru@gmail.com>
Signed-off-by: NChris Ball <cjb@laptop.org>