summaryrefslogtreecommitdiffstats
path: root/arch/arm/mach-omap2/hsmmc.c
AgeCommit message (Collapse)Author
2013-05-30ARM: OMAP2+: Remove omap4 pdata from hsmmc.cTony Lindgren
This is no longer needed as omap4 is now booted using device tree. Signed-off-by: Tony Lindgren <tony@atomide.com>
2013-01-26ARM: OMAP2+: omap_device: remove obsolete pm_lats and early_device codePaul Walmsley
Remove now-obsolete code from arch/arm/mach-omap2/omap_device.c. This mostly consists of removing the first attempt at device PM latency handling. This was never really used, has been replaced by the common dev_pm_qos code, and needs to go away as part of the DT conversion. Also, the early platform_device creation code has been removed, as it appears to be unused. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Kevin Hilman <khilman@deeprootsystems.com>
2012-11-02ARM: OMAP: Remove unnecessary mach and plat includesTony Lindgren
Now mach/hardware.h is empty for omap2+ and can be removed except for plat-omap/dmtimer.c for omap1. Also the include of mach/irqs.h can now be removed for shared plat-omap/i2c.c as it's no longer needed. Signed-off-by: Tony Lindgren <tony@atomide.com>
2012-10-18ARM: OMAP: Split plat/cpu.h into local soc.h for mach-omap1 and mach-omap2Tony Lindgren
We want to remove plat/cpu.h. To do this, let's first split it to private soc.h to mach-omap1 and mach-omap2. We have to keep plat/cpu.h around until the remaining drivers are fixed, so let's include the local soc.h in plat/cpu.h and for drivers still including plat/cpu.h. Once the drivers are fixed not to include plat/cpu.h, we can remove the file. This is needed for the ARM common zImage support. [tony@atomide.com: updated to not print a warning] Signed-off-by: Tony Lindgren <tony@atomide.com>
2012-10-18ARM: OMAP: Make plat/omap-pm.h local to mach-omap2Tony Lindgren
We must move this for ARM common zImage support. Note that neither drivers/media/rc/ir-rx51.c or drivers/media/platform/omap3isp/ispvideo.c need to include omap-pm.h, so this patch removes the include for those files. Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Mauro Carvalho Chehab <mchehab@infradead.org> Cc: Timo Kokkonen <timo.t.kokkonen@iki.fi> Cc: linux-media@vger.kernel.org Signed-off-by: Tony Lindgren <tony@atomide.com>
2012-10-17ARM: OMAP: Make omap_device local to mach-omap2Tony Lindgren
Let's make omap_device local to mach-omap2 for ARM common zImage support. Signed-off-by: Tony Lindgren <tony@atomide.com>
2012-10-15ARM: OMAP: Split plat/mmc.h into local headers and platform_dataTony Lindgren
We need to remove this from plat for ARM common zImage support. Also remove includes not needed by the omap_hsmmc.c driver. Cc: linux-mmc@vger.kernel.org Acked-by: Chris Ball <cjb@laptop.org> Acked-by: Venkatraman S <svenkatr@ti.com> [tony@atomide.com: fold in removal of unused driver includes] Signed-off-by: Tony Lindgren <tony@atomide.com>
2012-10-08ARM: OMAP: hsmmc: fix return value check in omap_hsmmc_init_one()Wei Yongjun
In case of error, the function omap_device_alloc() returns ERR_PTR() not NULL pointer. The NULL test in the return value check should be replaced with IS_ERR(). dpatch engine is used to auto generated this patch. (https://github.com/weiyj/dpatch) Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn> Signed-off-by: Tony Lindgren <tony@atomide.com>
2012-09-20ARM: OMAP1: Make plat/mux.h omap1 onlyTony Lindgren
We are moving omap2+ to use the device tree based pinctrl-single.c and will be removing the old mux framework. This will remove the omap1 specific parts from plat-omap. Acked-by: Felipe Balbi <balbi@ti.com> Cc: Grant Likely <grant.likely@secretlab.ca> Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Richard Purdie <rpurdie@rpsys.net> Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: linux-usb@vger.kernel.org Cc: linux-pcmcia@lists.infradead.org Cc: spi-devel-general@lists.sourceforge.net Signed-off-by: Tony Lindgren <tony@atomide.com>
2012-09-12ARM: OMAP: Move gpio.h to include/linux/platform_dataTony Lindgren
This way we can remove includes of plat/gpio.h which won't work with the single zImage support. Note that we also remove the cpu_class_is_omap2() check in gpio-omap.c as the drivers should not call it as we need to make it local to arch/arm/mach-omap2 for single zImage support. While at it, arrange the related includes in the standard way. Cc: Grant Likely <grant.likely@secretlab.ca> Cc: linux-mtd@lists.infradead.org Cc: alsa-devel@alsa-project.org Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Tony Lindgren <tony@atomide.com>
2012-07-31ARM: omap: remove mmc platform data dma_mask and initializationRussell King
DMAengine uses the DMA engine device structure when mapping/unmapping memory for DMA, so the MMC devices do not need their DMA masks initialized (this reflects hardware: the MMC device is not the device doing DMA.) Tested-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2012-05-10ARM: OMAP: AM35xx: convert 3517 detection/flags to AM35xxKevin Hilman
Currently cpu_is_omap3517() actually detects any device in the AM35x family (3517 and no-SGX version 3505.) To make it more clear what is being detected, convert the names from 3517 to AM35xx. This adds a new soc_is_am35xx() which duplicates the cpu_is_omap3517(). In order to avoid cross-tree dependencies with clock-tree changes, cpu_is_omap3517() is left until the clock changes are merged, at which point cpu_is_omap3517() will be completely removed. Acked-by: Vaibhav Hiremath <hvaibhav@ti.com> Tested-by: Vaibhav Hiremath <hvaibhav@ti.com> Tested-by: Mark A. Greer <mgreer@animalcreek.com> Signed-off-by: Kevin Hilman <khilman@ti.com> [tony@atomide.com: change to use soc_is_omap instead] Signed-off-by: Tony Lindgren <tony@atomide.com>
2012-05-10ARM: OMAP: AM35xx: remove redunant cpu_is checks for AM3505Kevin Hilman
There are several checks for AM35x devices done using if (cpu_is_omap3517() || cpu_is_omap3505()) However, since the 3505 is just a 3517 without an SGX, the 3505 check is redundant because cpu_is_omap3517() will always be true whenever cpu_is_omap3505() is true. From <plat/cpu.h>: #define cpu_is_omap3505() (cpu_is_omap3517() && !omap3_has_sgx()) Therefore, remove the redunant 3505 checks. This helps move towards removal of SoC detection that depends on specific IP detection. Acked-by: Vaibhav Hiremath <hvaibhav@ti.com> Tested-by: Vaibhav Hiremath <hvaibhav@ti.com> Tested-by: Mark A. Greer <mgreer@animalcreek.com> Signed-off-by: Kevin Hilman <khilman@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2012-04-04ARM: OMAP3xxx: HSMMC: avoid erratum workaround when transceiver is attachedGrazvydas Ignotas
If transceiver is attached to a MMC host of ES2.1 OMAP35xx, it seems 2.1.1.128 erratum doesn't apply and there is no data corruption, probably because of different signal timing. The workaround for this erratum disables multiblock reads, which causes dramatic loss of performance (over 75% slower), so avoid it when transceiver is present. Cc: Paul Walmsley <paul@pwsan.com> Signed-off-by: Grazvydas Ignotas <notasas@gmail.com> [paul@pwsan.com: edited commit message slightly] Signed-off-by: Paul Walmsley <paul@pwsan.com>
2012-03-28Merge tag 'mmc-merge-for-3.4-rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc Pull MMC updates from Chris Ball: Core: * Support for MMC 4.5 Data Tag feature -- we tag REQ_META, so devices that support Data Tag will provide increased throughput for metadata. * Faster detection of card removal on I/O errors. Drivers: * dw_mmc now supports eMMC Power Off Notify, has PCI support, and implements pre_req and post_req for asynchronous requests. * omap_hsmmc now supports device tree. * esdhc now has power management support. * sdhci-tegra now supports Tegra30 devices. * sdhci-spear now supports hibernation. * tmio_mmc now supports using a GPIO for card detection. * Intel PCH now supports 8-bit bus transfers. * tag 'mmc-merge-for-3.4-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc: (53 commits) mmc: sh_mmcif: simplify bitmask macros mmc: sh_mobile_sdhi: support modular mmc-core with non-standard hotplug mmc: sh_mobile_sdhi: add a callback for board specific init code mmc: tmio: cosmetic: prettify the tmio_mmc_set_ios() function mmc: sh_mobile_sdhi: do not manage PM clocks manually mmc: tmio_mmc: remove unused sdio_irq_enabled flag mmc: tmio_mmc: power status flag doesn't have to be exposed in platform data mmc: sh_mobile_sdhi: pass card hotplug GPIO number to TMIO MMC mmc: tmio_mmc: support the generic MMC GPIO card hotplug helper mmc: tmio: calculate the native hotplug condition only once mmc: simplify mmc_cd_gpio_request() by removing two parameters mmc: sdhci-pci: allow 8-bit bus width for Intel PCH mmc: sdhci: check interrupt flags in ISR again mmc: sdhci-pci: Add MSI support mmc: core: warn when card doesn't support HPI mmc: davinci: Poll status for small size transfers mmc: davinci: Eliminate spurious interrupts mmc: omap_hsmmc: Avoid a regulator voltage change with dt mmc: omap_hsmmc: Convert hsmmc driver to use device tree mmc: sdhci-pci: add SDHCI_QUIRK2_HOST_OFF_CARD_ON for Medfield SDIO ...
2012-03-27ARM: OMAP: hsmmc: add max_freq fieldDaniel Mack
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: Daniel Mack <zonque@gmail.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Chris Ball <cjb@laptop.org>
2012-03-07ARM: OMAP2+: Fix section warnings for hsmmc_init_oneTony Lindgren
Otherwise we can get the following error depending on the compiler: WARNING: arch/arm/mach-omap2/built-in.o(.text+0xafe0): Section mismatch in reference from the function omap_hsmmc_init_one() to the function .init.text:omap_hsmmc_pdata_init() The function omap_hsmmc_init_one() references the function __init omap_hsmmc_pdata_init(). This is often because omap_hsmmc_init_one lacks a __init annotation or the annotation of omap_hsmmc_pdata_init is wrong. Signed-off-by: Tony Lindgren <tony@atomide.com>
2012-02-24ARM: OMAP2+: Mark omap_hsmmc_init and omap_mux related functions as __initTony Lindgren
Now that omap hsmmc init is split into two functions, it's safe to mark omap_hsmmc_init and omap_mux related functions to __init. This basically reverts the following fixes for the case where TWL was compiled as a module: a98f77b (ARM: omap: fix section mismatch warning for sdp3430_twl_gpio_setup()) 8930b4e (ARM: omap: fix section mismatch warnings in mux.c caused by hsmmc.c) Additionally it fixes up the remaining section warnings for all callers of omap_mux functions. Cc: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Tony Lindgren <tony@atomide.com>
2012-02-20ARM: OMAP2+: Split omap2_hsmmc_init() to properly support I2C GPIO pinsTony Lindgren
Otherwise omap_device_build() and omap_mux related functions can't be marked as __init when twl is build as a module. If a board is using GPIO pins or regulators configured by an external chip, such as TWL PMIC on I2C bus, the board must mark those MMC controllers as deferred. Additionally both omap_hsmmc_init() and omap_hsmmc_late_init() must be called by the board. For MMC controllers using internal GPIO pins for card detect and regulators the slots don't need to be marked deferred. In this case calling omap_hsmmc_init() is sufficient. Only mark the MMC slots using gpio_cd or gpio_wd as deferred as noted by Igor Grinberg <grinberg@compulab.co.il>. Note that this patch does not change the behaviour for board-4430sdp.c board-omap4panda.c. These boards wrongly rely on the omap_hsmmc.c init function callback to configure the PMIC GPIO interrupt lines on external chip. If the PMIC interrupt lines are not configured during init, they will fail. Reported-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Rajendra Nayak <rnayak@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2012-02-20ARM: OMAP: Fix kernel panic with HSMMC when twl4030_gpio is a moduleTony Lindgren
On some omaps twl4030_gpio has a callback to try to initialize the MMC controller. If twl4030_gpio is compiled as a module, bad things can happen because the callback function starts calling functions that are supposed to be marked __init: Kernel panic - not syncing: Attempted to kill the idle task! twl4030_gpio twl4030_gpio: can't dispatch IRQs from modules gpiochip_add: registered GPIOs 192 to 209 on device: twl4030 Unable to handle kernel paging request at virtual address b82a4c74 ... Additionally if this does not fail, warnings are produced about trying to register the MMC multiple times. Fix this by removing __init from omap_mux_get_by_name, and add checks if omap2_hsmmc_init() is getting called more than once. Note that this will get fixed properly later on by splitting omap2_hsmmc_init into two functions. Reported-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Tony Lindgren <tony@atomide.com>
2012-02-13ARM: omap: fix section mismatch warning for sdp3430_twl_gpio_setup()Russell King
WARNING: arch/arm/mach-omap2/built-in.o(.text+0xd0f0): Section mismatch in reference from the function sdp3430_twl_gpio_setup() to the function .init.text:omap2_hsmmc_init() The function sdp3430_twl_gpio_setup() references the function __init omap2_hsmmc_init(). This is often because sdp3430_twl_gpio_setup lacks a __init annotation or the annotation of omap2_hsmmc_init is wrong. sdp3430_twl_gpio_setup() is called via platform data from the gpio-twl4030 module, which can be inserted and removed at runtime. This makes sdp3430_twl_gpio_setup() callable at runtime, and prevents it being marked with an __init annotation. As it calls omap2_hsmmc_init() unconditionally, the only resolution to this warning is to remove the __init markings from omap2_hsmmc_init() and its called functions. This addresses the functions in hsmmc.c. Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2012-01-26ARM: OMAP: fix MMC2 loopback clock handlingGrazvydas Ignotas
Currently MMC2 setup code can only enable loopback clock and relies on reset value for boards that need to have it disabled. This causes a problem with certain bootloaders that always enable that clock, resulting with unwanted bootloader dependencies. Fix this by making it disable the clock if board data says so. Signed-off-by: Grazvydas Ignotas <notasas@gmail.com> Acked-by: Igor Grinberg <grinberg@compulab.co.il> Signed-off-by: Tony Lindgren <tony@atomide.com>
2012-01-26ARM: OMAP: fix erroneous mmc2 clock change on mmc3 setupGrazvydas Ignotas
hsmmc23_before_set_reg() can set MMCSDIO2ADPCLKISEL bit, which enables internal clock for MMC2. Currently this function is also called by code handling MMC3, and if .internal_clock is set in platform data (by default it currently is), it will set MMCSDIO2ADPCLKISEL for MMC2 instead of MMC3 (MMC3 doesn't have such bit so nothing actually needs to be done). This breaks 2nd SD slot on pandora. Fix this by changing hsmmc23_before_set_reg() to only handle MMC2. Note that this removes .remux() call for MMC3, but no board currently needs it and it's also not called for MMC4 and MMC5. Signed-off-by: Grazvydas Ignotas <notasas@gmail.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-12-09ARM: OMAP: hsmmc: Support for AM3517 MMC1 voltagesAbhilash K V
This patch fixes the following error message which appears while intializing MMC1 on the AM3517 EVM base-board: mmc0: host doesn't support card's voltages mmc0: error -22 whilst initialising SD card The ocr_mask, which enumerates the volatges supported by the MMC card was not being indicated before, assuming that a separate Vcc regulator maybe another controllable regulator driver would be doing this. This patch statically specifies a subset of the voltages supported by the MMC driver, which are provided by the current fixed voltage regulator on AM3517 EVM. Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com> Signed-off-by: Abhilash K V <abhilash.kv@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-12-09ARM: OMAP: hsmmc: Add support for non-OMAP pinsThomas Weber
The Devkit8000 uses a TWL4030 pin for card detection. Thats why the error: _omap_mux_init_gpio: Could not set gpio192 occurs. This patch checks that the pin is on OMAP before calling omap_mux_init_gpio. Signed-off-by: Thomas Weber <weber@corscience.de> [tony@atomide.com: updated comments] Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-12-09ARM: OMAP: hsmmc: Add support for MMC 2 setup for AM35xIgor Grinberg
AM35x MMC 2 controller has internal clock loopback setting which cannot be utilized without this patch and thus SDIO devices connected to this controller and depend on this setting will fail to initialize. Signed-off-by: Igor Grinberg <grinberg@compulab.co.il> [tony@atomide.com: updated comments] Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-12-08ARM: OMAP: hsmmc: add pm_caps fieldEliad Peller
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: Eliad Peller <eliad@wizery.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-11-04ARM: OMAP4: hsmmc: configure SDMMC1_DR0 properlyBalaji T K
Fix the typo, instead it should be SDMMC1 USBC1 is not related to MMC1 I/Os Signed-off-by: Balaji T K <balajitk@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-11-04ARM: OMAP4: hsmmc: Fix Pbias configuration on regulator OFFBalaji T K
MMC1 data line IO's are powered down in before set regulator function. IO's should not be powered ON when regulator is OFF. Keep the IO's in power pown mode after regulator OFF otherwise VMODE_ERROR interrupt is generated due to mismatch in input (regulator) voltage and MMC IO drive voltage. Delete incorrect comments which are not applicable for OMAP4. Signed-off-by: Balaji T K <balajitk@ti.com> Signed-off-by: Kishore Kadiyala <kishore.kadiyala@ti.com> Reported-by: Viswanath Puttagunta <vishp@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-10-04ARM: OMAP2+: devices: Remove all omap_device_pm_latency structuresBenoit Cousson
Remove all these duplicated structures since a default one is now available. Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Kevin Hilman <khilman@ti.com>
2011-10-04Merge branches 'cleanup-part3', 'voltage', 'dmtimer' and 'l3' into dt-baseTony Lindgren
2011-09-30ARM: OMAP4: MMC: fix power and audio issue, decouple USBC1 from MMC1Bryan Buckley
Remove OMAP4_USBC1_ICUSB_PWRDNZ_MASK during enable/disable PWRDNZ mode for MMC1_PBIAS and associated extended-drain MMC1 I/O cell. This is in accordance with the control module programming guide. This fixes a bug where if trying to use gpio_98 or gpio_99 and MMC1 at the same time the GPIO signal will be affected by a changing SDMMC1_VDDS. Software must keep MMC1_PBIAS cell and MMC1_IO cell PWRDNZ signals low whenever SDMMC1_VDDS ramps up/down or changes for cell protection purposes. MMC1 is based on SDMMC1_VDDS whereas USBC1 is based on SIM_VDDS therefore they can operate independently. Signed-off-by: Bryan Buckley <bryan.buckley@ti.com> Acked-by: Kishore Kadiyala <kishore.kadiyala@ti.com> Tested-by: Balaji T K <balajitk@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-09-15OMAP: omap_device: when building return platform_device instead of omap_deviceKevin Hilman
All of the device init and device driver interaction with omap_device is done using platform_device pointers. To make this more explicit, have omap_device return a platform_device pointer instead of an omap_device pointer. All current users of the omap_device pointer were only using it to get at the platform_device pointer or struct device pointer, so fixing all of the users was trivial. This also makes it more difficult for device init code to directly access members of struct omap_device, and allows for easier changing of omap_device internals. Cc: Paul Walmsley <paul@pwsan.com> Signed-off-by: Kevin Hilman <khilman@ti.com>
2011-07-04omap: HSMMC: Fix GPIO muxingSilesh C V
Use generic gpio call to check the validity of the gpio. Note that this includes gpio 0 also which was missing before. Signed-off-by: Silesh C V <silesh@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-06-01ARM: OMAP4: MMC: increase delay for pbiasBalaji T K
4 micro seconds is not enough for PBIAS if MMC regulator is enabled from MMC regulator OFF. Increase the delay for PBIAS to stabilize. Wait for PBIAS and timeout if not. Resolves MMC/SD failure on OMAP4 "Pbias Voltage is not same as LDO" Signed-off-by: Balaji T K <balajitk@ti.com> Acked-by: Kishore Kadiyala <kishore.kadiyala@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-06-01ARM: OMAP4: MMC: no regulator off during probe for eMMCBalaji T K
eMMC does not handle power off when not in sleep state, Skip regulator disable during probe when eMMC is not in known state - state left by bootloader. Resolves eMMC failure on OMAP4 mmc0: error -110 whilst initialising MMC card Signed-off-by: Balaji T K <balajitk@ti.com> Tested-by: Kishore Kadiyala <kishore.kadiyala@ti.com> Acked-by: Kishore Kadiyala <kishore.kadiyala@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-03-31Fix common misspellingsLucas De Marchi
Fixes generated by 'codespell' and manually reviewed. Signed-off-by: Lucas De Marchi <lucas.demarchi@profusion.mobi>
2011-03-01OMAP: hsmmc: Rename the device and driverKishore Kadiyala
Modifying the device & driver name from "mmci-omap-hs" to "omap_hsmmc". Signed-off-by: Kishore Kadiyala <kishore.kadiyala@ti.com> Acked-by: Benoit Cousson<b-cousson@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-03-01OMAP: adapt hsmmc to hwmod frameworkKishore Kadiyala
OMAP2420 platform consists of mmc block as in omap1 and not the hsmmc block as present in omap2430, omap3, omap4 platforms. Removing all base address macro defines except keeping one for OMAP2420 and adapting only hsmmc device registration and driver to hwmod framework. Changes involves: 1) Remove controller reset in devices.c which is taken care of by hwmod framework. 2) Using omap-device layer to register device and utilizing data from hwmod data file for base address, dma channel number, Irq_number, device attribute. 3) Update the driver to use dev_attr to find whether controller supports dual volt cards Signed-off-by: Paul Walmsley <paul@pwsan.com> Signed-off-by: Kishore Kadiyala <kishore.kadiyala@ti.com> Reviewed-by: Balaji T K <balajitk@ti.com> Cc: Benoit Cousson <b-cousson@ti.com> CC: Kevin Hilman <khilman@deeprootsystems.com> Cc: Tony Lindgren <tony@atomide.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-03-01OMAP: hsmmc: Move mux configuration to hsmmc.cKishore Kadiyala
Moving the definition of mux setting API from devices.c to hsmmc.c and renaming it from "omap2_mmc_mux" to "omap_hsmmc_mux". Also calling "omap_hsmmc_mux" from omap2_hsmmc_init. Signed-off-by: Kishore Kadiyala <kishore.kadiyala@ti.com> Cc: Chris Ball <cjb@laptop.org Cc: Tony Lindgren <tony@atomide.com Signed-off-by: Tony Lindgren <tony@atomide.com>
2011-02-22OMAP: hsmmc: Enable MMC4 and MMC5 on OMAP4 platformsKishore Kadiyala
OMAP4 supports up to 5 MMC controllers, but only 3 of these were initialized. MMC5 is used by wl12xx chip. So initialize MMC4 and MMC5. Signed-off-by: Kishore Kadiyala <kishore.kadiyala@ti.com> Signed-off-by: Panduranga Mallireddy <panduranga_mallireddy@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2010-10-08OMAP: control: move plat-omap/control.h to mach-omap2/control.hPaul Walmsley
Only OMAP2+ platforms have the System Control Module (SCM) IP block. In the past, we've kept the SCM header file in plat-omap. This has led to abuse - device drivers including it; includes being added that create implicit dependencies on OMAP2+ builds; etc. In response, move the SCM headers into mach-omap2/. As part of this, remove the direct SCM access from the OMAP UDC driver. It was clearly broken. The UDC code needs an indepth review for use on OMAP2+ chips. Signed-off-by: Paul Walmsley <paul@pwsan.com> Cc: Cory Maccarrone <darkstar6262@gmail.com> Cc: Kyungmin Park <kyungmin.park@samsung.com>
2010-10-01omap4 hsmmc: Register offset handlingkishore kadiyala
In OMAP4, as per new PM programming model, the legacy registers which were there in OMAP3 are all shifted by 0x100 while new one's are added from offset 0 to 0x10. For OMAP4, the register offset appending of 0x100 done in devices.c currently, is moved to driver file.This change fits in for current implementation as well as once the driver undergoes hwmod adaptation. Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Madhusudhan Chikkature <madhu.cr@ti.com> Cc: Adrian Hunter <adrian.hunter@nokia.com> Cc: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Kishore Kadiyala <kishore.kadiyala@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2010-10-01OMAP4 ES2: HSMMC soft reset changeMadhusudhan Chikkature
The omap4 es2 hsmmc has a updated soft reset logic.After the reset is issued monitor a 0->1 transition first. The reset of CMD or DATA lines is complete only after a 0->1->0 transition of SRC or SRD bits. Signed-off-by: Madhusudhan Chikkature <madhu.cr@ti.com> Tested-by: Anand Gadiyar <gadiyar@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2010-09-27Merge branch 'omap4_and_sdrc_2.6.27' of git://git.pwsan.com/linux-2.6 into ↵Tony Lindgren
omap-for-linus
2010-09-27omap4: control: Fix the control module register accessesSantosh Shilimkar
This patch has multiple fixes together. To ensure that git bisect work across commits, all changes are clubbed together 1. Move the common control base address to control core 2. Remove the manually coeded defines and use the ones from headers. 3. Fix the the status register define in id.c for OMAP4 4. Fix all the register define in hsmmc.c 5. Use the control pad accessor API for omap4 hsmmc register accesses Signed-off-by: Benoit Cousson <b-cousson@ti.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: Paul Walmsley <paul@pwsan.com>
2010-09-27omap: mmc: extended to pass host capabilities from board fileSukumar Ghorai
wires variable is renamed, extended and this single variable to be used to pass the platform capabilities, e.g DDR mode. Also removed the hardcoded value was using as bus-width. Signed-off-by: Sukumar Ghorai <s-ghorai@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2010-08-11omap: pandora: pass wl1251 information to SDIO coreGrazvydas Ignotas
Pandora has TI WL1251 attached on MMC3, which is non-standard SDIO chip. Make use MMC_QUIRK_NONSTD_SDIO to tell SDIO core about it. Signed-off-by: Grazvydas Ignotas <notasas@gmail.com> Cc: Adrian Hunter <adrian.hunter@nokia.com> Cc: Tony Lindgren <tony@atomide.com> Cc: Bob Copeland <me@bobcopeland.com> Cc: Kalle Valo <kvalo@adurom.com> Cc: Madhusudhan Chikkature <madhu.cr@ti.com> Cc: Kishore Kadiyala <kishore.kadiyala@ti.com> Cc: Russell King <linux@arm.linux.org.uk> Cc: <linux-mmc@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-05-20omap4: Adding PBIAS Configuration for MMC1 Controllerkishore kadiyala
In OMAP4, MMC1 PBIAS and its associated IO is software-controlled by CONTROL_PBIAS and CONTROL_MMC1 registers. This patch adds PBIAS configuration for MMC1 Controller during power-ON and power-OFF of regulator. Signed-off-by: Kishore Kadiyala <kishore.kadiyala@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2010-05-20omap: hsmmc: fix the hsmmc driver for am3517stanley.miao
AM3517 don't have the register OMAP343X_CONTROL_PBIAS_LITE and the regulators like "vmmc", so we set a noop "set_power" function for it. Signed-off-by: Stanley.Miao <stanley.miao@windriver.com> Signed-off-by: Tony Lindgren <tony@atomide.com>