OMAP4 and OMAP3 HSMMC IP registers differ by 0x100 offset.
Adding the offset to platform_device resource structure
increments the start address for every insmod operation.
MMC command fails on re-insertion as module due to incorrect register
base.  Fix this by updating the ioremap base address only.
Signed-off-by: NBalaji T K <balajitk@ti.com>
Signed-off-by: NVenkatraman S <svenkatr@ti.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

This will delete some boilerplate code, no functional changes.
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NVenkatraman S <svenkatr@ti.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

If we put probe() on __init section, that will never work for multiple
module insertions/removals.

In order to make it work properly, move probe to __devinit section and
use platform_driver_register() instead of platform_driver_probe().
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NVenkatraman S <svenkatr@ti.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

A bunch of non-functional cleanups to the omap_hsmmc driver.

It basically decreases indentation level, drop unneded dereferences
and drop unneded accesses to the platform_device structure.
Signed-off-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NVenkatraman S <svenkatr@ti.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Call context save api after enabling runtime pm to make sure that
register access in context save api happens with clk enabled.
Signed-off-by: NBalaji T K <balajitk@ti.com>
Signed-off-by: NVenkatraman S <svenkatr@ti.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

pm_runtime_put_sync instead of autosuspend pm runtime API
because iounmap(host->base) follows immediately.
Reported-by: NRajendra Nayak <rnayak@ti.com>
Signed-off-by: NBalaji T K <balajitk@ti.com>
Signed-off-by: NVenkatraman S <svenkatr@ti.com>
Cc: <stable@vger.kernel.org>
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>

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>

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>

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>

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>

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>

As the card-detect irq handler just schedules work to be done by a
thread, we can use request_threaded_irq to do much of the work for
us.  This means that interrupts which arrive by handle_nested_irq
actually work.
Reviewed-by: NFelipe Balbi <balbi@ti.com>
Tested-by: NGrazvydas Ignotas <notasas@gmail.com>
Signed-off-by: NNeilBrown <neilb@suse.de>
Acked-by: NKishore Kadiyala <kishorek.kadiyala@gmail.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

MMC master clock rate can vary for each instance of the MMC controller
on the device. Use clk_get_rate instead to get the value.
Signed-off-by: NBalaji TK  <balajitk@ti.com>
Reviewed-by: NVenkatraman S <svenkatr@ti.com>
Tested-by: NHebbar, Gururaja <gururaja.hebbar@ti.com>
Acked-by: NSantosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Add pm_caps field to omap2_hsmmc_info and omap_mmc_slot_data
structs, so we will be able to indicate mmc pm capabilities
in the board file.
Signed-off-by: NEliad Peller <eliad@wizery.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

When an mmc card has the MMC_PM_KEEP_POWER flag, it shouldn't
be powered off on suspend (and thus doesn't have to be powered-on
on resume)

While on it, change the suspend flow a bit, to make it a bit
easier to follow.
Signed-off-by: NEliad Peller <eliad@wizery.com>
Acked-by: NChris Ball <cjb@laptop.org>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Reported by Russell King:
mmcblk0: error -84 transferring data, sector 149201, nr 64,
cmd response 0x900, card status 0xb00
mmcblk0: retrying using single block read

WARNING: at lib/dma-debug.c:811 check_unmap
omap_hsmmc omap_hsmmc.0: DMA-API: device driver tries to free DMA memory
it has not allocated [device address=0x0000000080933000] [size=20480 bytes]

In case of an error dma_unmap() is issued in omap_hsmmc_dma_cleanup()
and then again in omap_hsmmc_post_req(). Resolve this by clearing the
host_cookie to indicate there is no DMA mapped memory to unmap.
Signed-off-by: NPer Forlin <per.forlin@linaro.org>
Tested-by: NBalaji T K <balajitk@ti.com>
Tested-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NChris Ball <cjb@laptop.org>

When device data indicates that multiple block reads are not supported
on a given HSMMC controller instance, log a message to the console, and
pass the appropriate MMC capability flag to the MMC core.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Dave Hylands <dhylands@gmail.com>
Tested-by: NSteve Sakoman <sakoman@gmail.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Go through the driver's set_power() functions rather than
calling regulator_enable/disable() directly because otherwise
pbias configuration for MMC1 is not done.
Signed-off-by: NAdrian Hunter <adrian.hunter@nokia.com>
Acked-by: NBalaji T K <balajitk@ti.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

All the files using printk function for displaying kernel messages
in the mmc driver have been replaced with corresponding macro.
Signed-off-by: NGirish K S <girish.shivananjappa@linaro.org>
Signed-off-by: NChris Ball <cjb@laptop.org>

Since commit [e58aa3d2: genirq: Run irq handlers with interrupts
disabled], we run all interrupt handlers with interrupts disabled
and we even check and yell when an interrupt handler returns with
interrupts enabled (see commit [b738a50a: genirq: Warn when handler
enables interrupts]).

So now this flag is a NOOP and can be removed.
Signed-off-by: NYong Zhang <yong.zhang0@gmail.com>
Acked-by: NKishore Kadiyala <kishore.kadiyala@ti.com>
Acked-by: NGuennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: NChris Ball <cjb@laptop.org>

In the case of an I/O error, the DMA will have been cleaned up in
the MMC interrupt and the request structure pointer will be null.

In that case, it is essential to check if the DMA is over before
dereferencing host->mrq->data.
Signed-off-by: NAdrian Hunter <adrian.hunter@nokia.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

There are a few places with the same functionality. This patch creates
two functions omap_hsmmc_set_bus_width() and omap_hsmmc_set_bus_mode()
to do the job.
Signed-off-by: NAndy Shevchenko <ext-andriy.shevchenko@nokia.com>
Signed-off-by: NAdrian Hunter <adrian.hunter@nokia.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

There are two pieces of code which are similar, but not the same.
Each of them contains a bug.

The SYSCTL register should be read before writing to it in
omap_hsmmc_context_restore() to retain the state of the reserved bits.

Before setting the clock divisor and DTO bits the value from the SYSCTL
register should be masked properly. We were lucky to have no problems
with DTO bits. So, make sure we have clear DTO bits properly in
omap_hsmmc_set_ios().

Additionally get rid of msleep(1). The actual time is rarely higher
than 30us on OMAP 3630.

The resulting pieces of code are refactored into the
omap_hsmmc_set_clock() function.
Signed-off-by: NAndy Shevchenko <ext-andriy.shevchenko@nokia.com>
Signed-off-by: NAdrian Hunter <adrian.hunter@nokia.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

There is similar code in two functions which enable the clock.  Refactor
this code to omap_hsmmc_start_clock(). Re-use omap_hsmmc_stop_clock() in
omap_hsmmc_context_restore() as well.
Signed-off-by: NAndy Shevchenko <ext-andriy.shevchenko@nokia.com>
Signed-off-by: NAdrian Hunter <adrian.hunter@nokia.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

There are two places where the same calculations are done.
Let's split them into a separate function.

In addition, simplify by using the DIV_ROUND_UP kernel macro.
Signed-off-by: NAndy Shevchenko <ext-andriy.shevchenko@nokia.com>
Signed-off-by: NAdrian Hunter <adrian.hunter@nokia.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Move the min and max frequency constants to the definition block in
the source file.
Signed-off-by: NAndy Shevchenko <ext-andriy.shevchenko@nokia.com>
Signed-off-by: NAdrian Hunter <adrian.hunter@nokia.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

CERR and BADA were in the wrong place and there are only
32 not 35.
Signed-off-by: NAdrian Hunter <adrian.hunter@nokia.com>
Reviewed-by: NVenkatraman S <svenkatr@ti.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

After runtime conversion to handle clk, iclk node is not used.
However fclk node is still used to get clock rate.
Signed-off-by: NBalaji T K <balajitk@ti.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

* Add runtime pm support to HSMMC host controller.
* Use runtime pm API to enable/disable HSMMC clock.
* Use runtime autosuspend APIs to enable auto suspend delay.

Based on OMAP HSMMC runtime implementation by Kevin Hilman and
Kishore Kadiyala.
Signed-off-by: NBalaji T K <balajitk@ti.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

lazy_disable framework in OMAP HSMMC manages multiple low power states and
card is powered off after inactivity time of 8 seconds.  Based on previous
discussion on the list, card power (regulator) handling (when to power
OFF/ON) should ideally be handled by core layer.  Remove usage of lazy
disable to allow core layer _only_ to handle card power.  With the removal
of lazy disable framework, MMC regulators are left ON until MMC_POWER_OFF
via set_ios.
Signed-off-by: NBalaji T K <balajitk@ti.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

pre_req() runs dma_map_sg(), post_req() runs dma_unmap_sg.  If not calling
pre_req() before omap_hsmmc_request(), dma_map_sg will be issued before
starting the transfer.  It is optional to use pre_req().  If issuing
pre_req(), post_req() must be called as well.
Signed-off-by: NPer Forlin <per.forlin@linaro.org>
Reviewed-by: NVenkatraman S <svenkatr@ti.com>
Tested-by: NSourav Poddar <sourav.poddar@ti.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

Don't use the returned sg_len from dma_map_sg() as inparameter
to dma_unmap_sg(). Use the original sg_len for both dma_map_sg
and dma_unmap_sg according to the documentation in DMA-API.txt.
Signed-off-by: NPer Forlin <per.forlin@linaro.org>
Reviewed-by: NVenkatraman S <svenkatr@ti.com>
Signed-off-by: NChris Ball <cjb@laptop.org>

The OMAP HSMMC driver uses an ocr_mask to determine the list of voltages
supported by the card. It populates this mask based on the list of
voltages supported by the regulator that supplies the voltage.

Commit 64be9782 (omap4 hsmmc: Update ocr mask for MMC2 for regulator
to use) passed a fixed ocr_mask from the OMAP4 SDP board file to limit
the voltage to 2.9-3.0 Volts, and updated the driver to use this mask
if provided, instead of using the regulator's supported voltages.

However the commit is buggy - the ocr_mask is overridden by the
regulator's capabilities anyway. Fix this.

(The bug shows up when a system-wide suspend is attempted on the OMAP4
SDP/Blaze platforms. The eMMC card comes up at 3V, but drops to 1.65V
after the system resumes).
Signed-off-by: NAnand Gadiyar <gadiyar@ti.com>
Acked-by: NBalaji T K <balajitk@ti.com>
Acked-by: NVenkatraman S <svenkatr@ti.com>
Tested-by: NKishore Kadiyala <kishore.kadiyala@ti.com>
Signed-off-by: NSourav Poddar <sourav.poddar@ti.com>
Signed-off-by: NChris Ball <cjb@laptop.org>