summaryrefslogtreecommitdiffstats
path: root/drivers/mmc/host/sdhci.h
Commit message (Collapse)AuthorAgeFilesLines
* mmc: sdhci: add quirk SDHCI_QUIRK2_NEED_DELAY_AFTER_INT_CLK_RSTludovic.desroches@atmel.com2015-10-081-0/+5
| | | | | | | | | | | | | The Atmel sdhci device needs a new quirk. sdhci_set_clock set the Clock Control Register to 0 before computing the new value and writing it. It disables the internal clock which causes a reset mecanism. If we write the new value before this reset mecanism is done, it will prevent the stabilisation of the internal clock, so a delay is needed. This delay is about 2-3 cycles of the base clock. To be safe, a 1 ms delay is used. Signed-off-by: Ludovic Desroches <ludovic.desroches@atmel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: sdhci: fix dma memory leak in sdhci_pre_req()Haibo Chen2015-08-271-4/+4
| | | | | | | | | | | | | | | | | | | | Currently one mrq->data maybe execute dma_map_sg() twice when mmc subsystem prepare over one new request, and the following log show up: sdhci[sdhci_pre_dma_transfer] invalid cookie: 24, next-cookie 25 In this condition, mrq->date map a dma-memory(1) in sdhci_pre_req for the first time, and map another dma-memory(2) in sdhci_prepare_data for the second time. But driver only unmap the dma-memory(2), and dma-memory(1) never unmapped, which cause the dma memory leak issue. This patch use another method to map the dma memory for the mrq->data which can fix this dma memory leak issue. Fixes: 348487cb28e6 ("mmc: sdhci: use pipeline mmc requests to improve performance") Reported-and-tested-by: Jiri Slaby <jslaby@suse.cz> Signed-off-by: Haibo Chen <haibo.chen@freescale.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: sdhci: add quirk SDHCI_QUIRK_CLOCK_DIV_ZERO_BROKENSuneel Garapati2015-08-171-0/+2
| | | | | | | | adds quirk for controllers whose clock divider zero is broken, sdhci_set_clock function will incorporate this modification. Signed-off-by: Suneel Garapati <suneel.garapati@xilinx.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: sdhci: Add a callback to select drive strengthAdrian Hunter2015-06-011-0/+4
| | | | | | | | Add a callbak to let host drivers select drive strength. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: sdhci: Change to new way of doing re-tuningAdrian Hunter2015-06-011-3/+0
| | | | | | | | | | | | | Make use of mmc core support for re-tuning instead of doing it all in the sdhci driver. This patch also changes to flag the need for re-tuning always after runtime suspend when tuning has been used at initialization. Previously it was only done if the re-tuning timer was in use. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: sdhci: Remove the sdhci exported header fileUlf Hansson2015-03-231-1/+202
| | | | | | | | | | Since there no users of the struct sdhci_host, but the shdci host drivers themselves, let's move the definition of it to the local sdhci header. The exported sdhci header then becomes empty, so let's remove it. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: sdhci: add a voltage switch callback functionVincent Yang2015-01-201-0/+1
| | | | | | | | | | This patch adds a callback function to do controller-specific actions when switching voltages. It is a preparation and will be used by Fujitsu SDHCI controller f_sdh30 driver. Signed-off-by: Vincent Yang <Vincent.Yang@tw.fujitsu.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* Merge tag 'pm+acpi-3.19-rc1' of ↵Linus Torvalds2014-12-101-3/+0
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull ACPI and power management updates from Rafael Wysocki: "This time we have some more new material than we used to have during the last couple of development cycles. The most important part of it to me is the introduction of a unified interface for accessing device properties provided by platform firmware. It works with Device Trees and ACPI in a uniform way and drivers using it need not worry about where the properties come from as long as the platform firmware (either DT or ACPI) makes them available. It covers both devices and "bare" device node objects without struct device representation as that turns out to be necessary in some cases. This has been in the works for quite a few months (and development cycles) and has been approved by all of the relevant maintainers. On top of that, some drivers are switched over to the new interface (at25, leds-gpio, gpio_keys_polled) and some additional changes are made to the core GPIO subsystem to allow device drivers to manipulate GPIOs in the "canonical" way on platforms that provide GPIO information in their ACPI tables, but don't assign names to GPIO lines (in which case the driver needs to do that on the basis of what it knows about the device in question). That also has been approved by the GPIO core maintainers and the rfkill driver is now going to use it. Second is support for hardware P-states in the intel_pstate driver. It uses CPUID to detect whether or not the feature is supported by the processor in which case it will be enabled by default. However, it can be disabled entirely from the kernel command line if necessary. Next is support for a platform firmware interface based on ACPI operation regions used by the PMIC (Power Management Integrated Circuit) chips on the Intel Baytrail-T and Baytrail-T-CR platforms. That interface is used for manipulating power resources and for thermal management: sensor temperature reporting, trip point setting and so on. Also the ACPI core is now going to support the _DEP configuration information in a limited way. Basically, _DEP it supposed to reflect off-the-hierarchy dependencies between devices which may be very indirect, like when AML for one device accesses locations in an operation region handled by another device's driver (usually, the device depended on this way is a serial bus or GPIO controller). The support added this time is sufficient to make the ACPI battery driver work on Asus T100A, but it is general enough to be able to cover some other use cases in the future. Finally, we have a new cpufreq driver for the Loongson1B processor. In addition to the above, there are fixes and cleanups all over the place as usual and a traditional ACPICA update to a recent upstream release. As far as the fixes go, the ACPI LPSS (Low-power Subsystem) driver for Intel platforms should be able to handle power management of the DMA engine correctly, the cpufreq-dt driver should interact with the thermal subsystem in a better way and the ACPI backlight driver should handle some more corner cases, among other things. On top of the ACPICA update there are fixes for race conditions in the ACPICA's interrupt handling code which might lead to some random and strange looking failures on some systems. In the cleanups department the most visible part is the series of commits targeted at getting rid of the CONFIG_PM_RUNTIME configuration option. That was triggered by a discussion regarding the generic power domains code during which we realized that trying to support certain combinations of PM config options was painful and not really worth it, because nobody would use them in production anyway. For this reason, we decided to make CONFIG_PM_SLEEP select CONFIG_PM_RUNTIME and that lead to the conclusion that the latter became redundant and CONFIG_PM could be used instead of it. The material here makes that replacement in a major part of the tree, but there will be at least one more batch of that in the second part of the merge window. Specifics: - Support for retrieving device properties information from ACPI _DSD device configuration objects and a unified device properties interface for device drivers (and subsystems) on top of that. As stated above, this works with Device Trees and ACPI and allows device drivers to be written in a platform firmware (DT or ACPI) agnostic way. The at25, leds-gpio and gpio_keys_polled drivers are now going to use this new interface and the GPIO subsystem is additionally modified to allow device drivers to assign names to GPIO resources returned by ACPI _CRS objects (in case _DSD is not present or does not provide the expected data). The changes in this set are mostly from Mika Westerberg, Rafael J Wysocki, Aaron Lu, and Darren Hart with some fixes from others (Fabio Estevam, Geert Uytterhoeven). - Support for Hardware Managed Performance States (HWP) as described in Volume 3, section 14.4, of the Intel SDM in the intel_pstate driver. CPUID is used to detect whether or not the feature is supported by the processor. If supported, it will be enabled automatically unless the intel_pstate=no_hwp switch is present in the kernel command line. From Dirk Brandewie. - New Intel Broadwell-H ID for intel_pstate (Dirk Brandewie). - Support for firmware interface based on ACPI operation regions used by the PMIC chips on the Intel Baytrail-T and Baytrail-T-CR platforms for power resource control and thermal management (Aaron Lu). - Limited support for retrieving off-the-hierarchy dependencies between devices from ACPI _DEP device configuration objects and deferred probing support for the ACPI battery driver based on the _DEP information to make that driver work on Asus T100A (Lan Tianyu). - New cpufreq driver for the Loongson1B processor (Kelvin Cheung). - ACPICA update to upstream revision 20141107 which only affects tools (Bob Moore). - Fixes for race conditions in the ACPICA's interrupt handling code and in the ACPI code related to system suspend and resume (Lv Zheng and Rafael J Wysocki). - ACPI core fix for an RCU-related issue in the ioremap() regions management code that slowed down significantly after CPUs had been allowed to enter idle states even if they'd had RCU callbakcs queued and triggered some problems in certain proprietary graphics driver (and elsewhere). The fix replaces synchronize_rcu() in that code with synchronize_rcu_expedited() which makes the issue go away. From Konstantin Khlebnikov. - ACPI LPSS (Low-Power Subsystem) driver fix to handle power management of the DMA engine included into the LPSS correctly. The problem is that the DMA engine doesn't have ACPI PM support of its own and it simply is turned off when the last LPSS device having ACPI PM support goes into D3cold. To work around that, the PM domain used by the ACPI LPSS driver is redesigned so at least one device with ACPI PM support will be on as long as the DMA engine is in use. From Andy Shevchenko. - ACPI backlight driver fix to avoid using it on "Win8-compatible" systems where it doesn't work and where it was used by default by mistake (Aaron Lu). - Assorted minor ACPI core fixes and cleanups from Tomasz Nowicki, Sudeep Holla, Huang Rui, Hanjun Guo, Fabian Frederick, and Ashwin Chaugule (mostly related to the upcoming ARM64 support). - Intel RAPL (Running Average Power Limit) power capping driver fixes and improvements including new processor IDs (Jacob Pan). - Generic power domains modification to power up domains after attaching devices to them to meet the expectations of device drivers and bus types assuming devices to be accessible at probe time (Ulf Hansson). - Preliminary support for controlling device clocks from the generic power domains core code and modifications of the ARM/shmobile platform to use that feature (Ulf Hansson). - Assorted minor fixes and cleanups of the generic power domains core code (Ulf Hansson, Geert Uytterhoeven). - Assorted minor fixes and cleanups of the device clocks control code in the PM core (Geert Uytterhoeven, Grygorii Strashko). - Consolidation of device power management Kconfig options by making CONFIG_PM_SLEEP select CONFIG_PM_RUNTIME and removing the latter which is now redundant (Rafael J Wysocki and Kevin Hilman). That is the first batch of the changes needed for this purpose. - Core device runtime power management support code cleanup related to the execution of callbacks (Andrzej Hajda). - cpuidle ARM support improvements (Lorenzo Pieralisi). - cpuidle cleanup related to the CPUIDLE_FLAG_TIME_VALID flag and a new MAINTAINERS entry for ARM Exynos cpuidle (Daniel Lezcano and Bartlomiej Zolnierkiewicz). - New cpufreq driver callback (->ready) to be executed when the cpufreq core is ready to use a given policy object and cpufreq-dt driver modification to use that callback for cooling device registration (Viresh Kumar). - cpufreq core fixes and cleanups (Viresh Kumar, Vince Hsu, James Geboski, Tomeu Vizoso). - Assorted fixes and cleanups in the cpufreq-pcc, intel_pstate, cpufreq-dt, pxa2xx cpufreq drivers (Lenny Szubowicz, Ethan Zhao, Stefan Wahren, Petr Cvek). - OPP (Operating Performance Points) framework modification to allow OPPs to be removed too and update of a few cpufreq drivers (cpufreq-dt, exynos5440, imx6q, cpufreq) to remove OPPs (added during initialization) on driver removal (Viresh Kumar). - Hibernation core fixes and cleanups (Tina Ruchandani and Markus Elfring). - PM Kconfig fix related to CPU power management (Pankaj Dubey). - cpupower tool fix (Prarit Bhargava)" * tag 'pm+acpi-3.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (120 commits) i2c-omap / PM: Drop CONFIG_PM_RUNTIME from i2c-omap.c dmaengine / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM tools: cpupower: fix return checks for sysfs_get_idlestate_count() drivers: sh / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM e1000e / igb / PM: Eliminate CONFIG_PM_RUNTIME MMC / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM MFD / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM misc / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM media / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM input / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM leds: leds-gpio: Fix multiple instances registration without 'label' property iio / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM hsi / OMAP / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM i2c-hid / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM drm / exynos / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM gpio / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM hwrandom / exynos / PM: Use CONFIG_PM in #ifdef block / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM USB / PM: Drop CONFIG_PM_RUNTIME from the USB core PM: Merge the SET*_RUNTIME_PM_OPS() macros ...
| * MMC / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PMRafael J. Wysocki2014-12-051-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | After commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME if PM_SLEEP is selected) PM_RUNTIME is always set if PM is set, so #ifdef blocks depending on CONFIG_PM_RUNTIME may now be changed to depend on CONFIG_PM. Replace CONFIG_PM_RUNTIME with CONFIG_PM everywhere under drivers/mmc/. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
* | mmc: sdhci: Add HS400 support to SDHCI driverAdrian Hunter2014-11-261-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | MMC core already has support for HS400. Add HS400 support to SDHCI driver. The SDHC Standard specification does not define HS400 so consequently HS400 support is non-standard. However HS400 is not selected without the host controller setting the corresponding capability flags so host controllers not yet supporting HS400 will not be affected. To support that, a quirk SDHCI_QUIRK2_CAPS_BIT63_FOR_HS400 is introduced to enable the use of capabilities register reserved bit-63 to indicate HS400 support. Because HS400 is non-standard for SDHCI, it is possible that different vendors will do things in different ways. However HS200 support faced the same issue but currently there is only one solution. As such, no attempt has been made to provide for alternate HS400 solutions except for SDHCI_QUIRK2_CAPS_BIT63_FOR_HS400. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* | mmc: sdhci: Remove unused SDHCI_CTRL_HS_SDR200Adrian Hunter2014-11-261-1/+0
| | | | | | | | | | | | | | SDHCI_CTRL_HS_SDR200 is unused. Remove it. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* | mmc: sdhci: Add 64-bit ADMA supportAdrian Hunter2014-11-101-0/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add 64-bit ADMA support including: - add 64-bit ADMA descriptor - add SDHCI_USE_64_BIT_DMA flag - set upper 32-bits of DMA addresses - ability to select 64-bit ADMA - ability to use 64-bit ADMA sizes and alignment - display "ADMA 64-bit" when host is added It is assumed that a 64-bit capable device has set a 64-bit DMA mask and *must* do 64-bit DMA. A driver has the opportunity to change that during the first call to ->enable_dma(). Similarly SDHCI_QUIRK2_BROKEN_64_BIT_DMA must be left to the drivers to implement. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* | mmc: sdhci: Define ADMA descriptor structureAdrian Hunter2014-11-101-0/+7
| | | | | | | | | | | | | | | | Define the ADMA descriptor structure instead of using manual offsets and casts. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* | mmc: sdhci: Define ADMA constantsAdrian Hunter2014-11-101-0/+10
| | | | | | | | | | | | | | | | Define all the ADMA constants instead of having numbers scattered throughout the code. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* | mmc: sdhci: Define maximum segmentsAdrian Hunter2014-11-101-0/+6
|/ | | | | | | | | Define the maximum number of segments instead of having the constant 128 appearing in the code in various places. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: sdhci: execute tuning when device is not busyYi Sun2014-09-241-0/+1
| | | | | | | | We find tuning timeout because of the secure erase operation lasts too long, so don't do tuning when device is busy. Signed-off-by: Yi Sun <yi.y.sun@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: sdhci: add platform set_timeout hookAisheng Dong2014-09-091-0/+2
| | | | | | | | | | | | | | | | Currently the common code assume 0xE is the maximum timeout counter value and use it to write into the timeout counter register. However, it's fairly possible that some other SoCs may have different max timeout register value. That means 0xE may be incorrect and becomes meaningless. It's also possible that other platforms has different timeout calculation algorithm. To be flexible, this patch provides a .set_timeout hook for those platforms to set the timeout on their way if they need. Reviewed-by: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Dong Aisheng <b29396@freescale.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: sdhci: add platform get_max_timeout_count hookAisheng Dong2014-09-091-0/+1
| | | | | | | | | | | | | | | Currently the max timeout count is hardcode to 1 << 27 for calcuate the max_busy_timeout, however, for some platforms the max timeout count may not be 1 << 27, e.g. i.MX uSDHC is 1 << 28. Thus 1 << 27 is not correct for such platform. It is also possible that other platforms may have different values. To be flexible, we add a get_max_timeout_count hook to get the correct maximum timeout value for these platforms. Reviewed-by: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Dong Aisheng <b29396@freescale.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
* mmc: sdhci: remove platform_suspend/platform_resume callbacksRussell King2014-05-221-2/+0
| | | | | | | | | | | The only user (sdhci-of-esdhc) no longer uses these callbacks, so lets remove them to discourage any further use. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Tested-by: Markus Pargmann <mpa@pengutronix.de> Tested-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Chris Ball <chris@printf.net>
* mmc: sdhci: convert sdhci_set_uhs_signaling() into a library functionRussell King2014-05-221-0/+1
| | | | | | | | | | | | Add sdhci_set_uhs_signaling() and always call the set_uhs_signaling method. This avoids quirks being added into sdhci_set_uhs_signaling(). Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Tested-by: Markus Pargmann <mpa@pengutronix.de> Tested-by: Stephen Warren <swarren@nvidia.com> [Ulf Hansson] Resolved conflict Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Chris Ball <chris@printf.net>
* mmc: sdhci: set_uhs_signaling() need not return a valueRussell King2014-05-221-1/+1
| | | | | | | | | | | | | | | The set_uhs_signaling() method gives the impression that it can fail, but anything returned from the method is entirely ignored by the sdhci driver. So returning failure has no effect. So, kill the idea that it's possible for this to return an error by removing the returned value. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Tested-by: Markus Pargmann <mpa@pengutronix.de> Tested-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Chris Ball <chris@printf.net>
* mmc: sdhci: convert sdhci_set_clock() into a library functionRussell King2014-05-221-0/+1
| | | | | | | | Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Tested-by: Markus Pargmann <mpa@pengutronix.de> Tested-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Chris Ball <chris@printf.net>
* mmc: sdhci: convert reset into a library functionRussell King2014-05-221-2/+2
| | | | | | | | | | | | | Rather than having platform_reset_enter/platform_reset_exit methods, turn the core of the reset handling into a library function which platforms can call at the appropriate moment in their (new) reset method. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Tested-by: Markus Pargmann <mpa@pengutronix.de> Tested-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Chris Ball <chris@printf.net>
* mmc: sdhci: convert generic bus width setup to library functionRussell King2014-05-221-2/+3
| | | | | | | | Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Tested-by: Markus Pargmann <mpa@pengutronix.de> Tested-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Chris Ball <chris@printf.net>
* mmc: sdhci: allow sdio interrupts while sdhci runtime suspendedRussell King2014-05-221-0/+5
| | | | | | | | | | | | | Allow SDIO interrupts to be received while the SDHCI host is runtime suspended. We do this by leaving the AHB clock enabled while the host is runtime suspended so we can access the SDHCI registers, and so read and raise the SDIO card interrupt. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Tested-by: Markus Pargmann <mpa@pengutronix.de> Tested-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Chris Ball <chris@printf.net>
* mmc: sdhci: allow platform access of sdhci_send_commandDong Aisheng2013-09-261-0/+2
| | | | | | | | It helps for platform code to use it send tuning commands. Signed-off-by: Dong Aisheng <b29396@freescale.com> Acked-by: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Chris Ball <cjb@laptop.org>
* mmc: sdhci: add hooks for platform specific tuningDong Aisheng2013-09-261-0/+1
| | | | | | | | | | | | | | | | | | | | The tuning of some platforms may not follow the standard host control spec v3.0, e.g. Freescale uSDHC on i.MX6Q/DL. Add a hook here to allow execute platform specific tuning instead of standard host controller tuning. The hook only replaces the tuning process, so it's placed after tuning checking and before the real tuning process. Some notes for the tuning hook: 1) it needs handle lock itself if it wants to access host controller according platform specific implementation. 2) do not need to handle runtime pm since it executes with runtime pm get already. Signed-off-by: Dong Aisheng <b29396@freescale.com> Acked-by: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Chris Ball <cjb@laptop.org>
* mmc: sdhci: add card_event callback to sdhciChristian Daudt2013-07-051-0/+1
| | | | | | | | Add a card_event callback to sdhci so that clients can provide their own card_event to be called when card_detect is triggered. Signed-off-by: Christian Daudt <csd@broadcom.com> Signed-off-by: Chris Ball <cjb@laptop.org>
* mmc: sdhci: enhance preset value functionKevin Liu2013-02-241-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 4d55c5a1 ("mmc: sdhci: enable preset value after uhs initialization") added preset value support and enabled it by default during sd card init. Below are the enhancements introduced by this patch: 1. In current code, preset value is enabled after setting clock finished, which means the clock is manually set by driver firstly and then suddenly switched to preset value at this point. So the first setting is useless and unnecessary. What's more, the first clock setting may differ from the preset one. The better way is enable preset value just after switch to UHS mode so the preset value can take effect immediately. So move preset value enable from mmc_sd_init_card to sdhci_set_ios which will be called during set timing. 2. In current code, preset value is disabled at the beginning of mmc_attach_sd. It's too late since low freq (400khz) should be set in mmc_power_up. So move preset value disable to sdhci_set_ios which will be called during power up. 3. host->clock and ios->drv_type should also be updated according to the preset value if it's enabled. Current code missed this. 4. This patch also introduce a quirk to disable preset value in case preset value doesn't work. This patch has been verified on sdhci-pxav3 platform with both preset enabled and disabled. Signed-off-by: Kevin Liu <kliu5@marvell.com> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Chris Ball <cjb@laptop.org>
* mmc: sdhci: rename platform_8bit_width to platform_bus_widthSascha Hauer2013-02-241-1/+1
| | | | | | | | | | | | The 8bit in the function name is misleading. When set, it will be used to set the bus width, regardless of whether 8bit or another bus width is requested, so change the function name to platform_bus_width. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Shawn Guo <shawn.guo@linaro.org> Tested-by: Dirk Behme <dirk.behme@de.bosch.com> Signed-off-by: Chris Ball <cjb@laptop.org>
* mmc: eSDHC: Recover from ADMA errorsHaijun Zhang2012-12-061-1/+4
| | | | | | | | | | | | | | | | A-003500: False ADMA Error might be reported when ADMA is used for multiple block read command with Stop at Block Gap. If PROCTL[SABGREQ] is set when the particular block's data is received by the System side logic before entire block (with CRC) data is received by the SD side logic, and also if ADMA descriptor line is fetched at the same time, then DMA engine might report false ADMA error. eSDHC might not be able to Continue (PROCTL[CREQ]=1) after Stop at Block Gap. This issue will impact the eSDHC IP VVN2.3. Signed-off-by: Haijun Zhang <Haijun.Zhang@freescale.com> Signed-off-by: Jerry Huang <Chang-Ming.Huang@freescale.com> Acked-by: Anton Vorontsov <cbouatmailru@gmail.com> Signed-off-by: Chris Ball <cjb@laptop.org>
* mmc: sdhci-of-esdhc: disable CMD23 for some Freescale SoCsJerry Huang2012-11-071-0/+1
| | | | | | | | | | | | | CMD23 causes lots of errors in kernel on some freescale SoCs (P1020, P1021, P1022, P1024, P1025 and P4080) when MMC card used, which is because these controllers does not support CMD23, even on the SoCs which declares CMD23 is supported. Therefore, we'll not use CMD23. Signed-off-by: Jerry Huang <Chang-Ming.Huang@freescale.com> Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com> Acked-by: Anton Vorontsov <cbouatmailru@gmail.com> Signed-off-by: Chris Ball <cjb@laptop.org>
* mmc: sdhci: if MAX_CURRENT is 0, try getting current from regulatorPhilip Rakity2012-07-211-0/+1
| | | | | | | | | | | | The sd host controller spec indicates the the MAX_CURRENT value may be returned as 0. In this case other methods need to be used to return the current. If 0 is returned and there is a regulator, ask the regulator for how much current is available. Signed-off-by: Philip Rakity <prakity@marvell.com> Signed-off-by: Mark F. Brown <mark.brown314@gmail.com> Reviewed-by: Aaron Lu <aaron.lu@amd.com> Signed-off-by: Chris Ball <cjb@laptop.org>
* mmc: sdhci: Add platform suspend/resume hooks.Chris Ball2012-03-251-0/+2
| | | | | | | Some platforms require saving/restoring registers across suspend/resume; this hook allows them to do that inside their driver. Signed-off-by: Chris Ball <cjb@laptop.org>
* mmc: host: Adds support for eMMC 4.5 HS200 modeGirish K S2012-01-121-0/+1
| | | | | | | | | This patch adds support for the HS200 mode on the host side. Also enables the tuning feature required when the HS200 mode is selected. Signed-off-by: Girish K S <girish.shivananjappa@linaro.org> Signed-off-by: Chris Ball <cjb@laptop.org>
* mmc: sdhci: remove "state" argument from sdhci_suspend_hostManuel Lauss2011-12-191-1/+1
| | | | | | | | | Drop the "state" argument from sdhci_suspend_host. Its only user is the PCI glue; this allows to move all SDHCI glues to use dev_pm_ops instead. Signed-off-by: Manuel Lauss <manuel.lauss@googlemail.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Chris Ball <cjb@laptop.org>
* mmc: sdhci-pci: add runtime pm supportAdrian Hunter2011-10-261-0/+5
| | | | | | | | | | | | | Ths patch allows runtime PM for sdhci-pci, runtime suspending after inactivity of 50ms and ensuring runtime resume before SDHC registers are accessed. During runtime suspend, interrupts are masked. The host controller state is restored at runtime resume. For Medfield, the host controller's card detect mechanism is supplanted by an always-on GPIO which provides for card detect wake-up. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Chris Ball <cjb@laptop.org>
* mmc: sdhci: add eMMC hardware reset supportAdrian Hunter2011-10-261-1/+1
| | | | | | | | Add an SDHCI operation for hardware reset and connect it to the host controller operation. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Chris Ball <cjb@laptop.org>
* mmc: sdhci: Auto-CMD23 support.Andrei Warkentin2011-05-251-0/+2
| | | | | | | | Enables Auto-CMD23 support where available (SDHCI 3.0 controllers) Signed-off-by: Andrei Warkentin <andreiw@motorola.com> Tested-by: Arindam Nath <arindam.nath@amd.com> Signed-off-by: Chris Ball <cjb@laptop.org>
* mmc: sdhci: Implement MMC_CAP_CMD23 for SDHCI.Andrei Warkentin2011-05-251-1/+1
| | | | | | | | Implements support for multiblock transfers bounded by SET_BLOCK_COUNT (CMD23). Signed-off-by: Andrei Warkentin <andreiw@motorola.com> Signed-off-by: Chris Ball <cjb@laptop.org>
* mmc: sdhci: add hooks for setting UHS in platform specific codePhilip Rakity2011-05-241-0/+2
| | | | | | | | | Allow platform specific code to set UHS registers if implementation requires speciial platform specific handling Signed-off-by: Philip Rakity <prakity@marvell.com> Reviewed-by: Arindam Nath <arindam.nath@amd.com> Signed-off-by: Chris Ball <cjb@laptop.org>
* mmc: sdhci: add support for retuning mode 1Arindam Nath2011-05-241-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | Host Controller v3.00 can support retuning modes 1,2 or 3 depending on the bits 46-47 of the Capabilities register. Also, the timer count for retuning is indicated by bits 40-43 of the same register. We initialize timer_list for retuning the first time we execute tuning procedure. This condition is indicated by SDHCI_NEEDS_RETUNING not being set. Since retuning mode 1 sets a limit of 4MB on the maximum data length, we set max_blk_count appropriately. Once the tuning timer expires, we set SDHCI_NEEDS_RETUNING flag, and if the flag is set, we execute tuning procedure before sending the next command. We need to restore mmc_request structure after executing retuning procedure since host->mrq is used inside the procedure to send CMD19. We also disable and re-enable this flag during suspend and resume respectively, as per the spec v3.00. Tested by Zhangfei Gao with a Toshiba uhs card and general hs card, on mmp2 in SDMA mode. Signed-off-by: Arindam Nath <arindam.nath@amd.com> Reviewed-by: Philip Rakity <prakity@marvell.com> Tested-by: Philip Rakity <prakity@marvell.com> Acked-by: Zhangfei Gao <zhangfei.gao@marvell.com> Signed-off-by: Chris Ball <cjb@laptop.org>
* mmc: sdhci: add support for programmable clock modeArindam Nath2011-05-241-0/+3
| | | | | | | | | | | | | | | | | | | | | | | Host Controller v3.00 supports programmable clock mode as an optional feature. The support for this mode is indicated by non-zero value in bits 48-55 of the Capabilities register. If supported, the actual value of Clock Multiplier is one more than the value provided in the bit fields. We only set Clock Generator Select (bit 5) and SDCLK Frequency Select (bits 8-15) of the Clock Control register in case Preset Value Enable is not set, otherwise these fields are automatically set by the Host Controller based on the UHS mode selected. Also, since the maximum and minimum clock frequency in this mode can be (Base Clock * Clock Mul) and (Base Clock * Clock Mul)/1024 respectively, f_max and f_min have been recalculated to reflect this change. Tested by Zhangfei Gao with a Toshiba uhs card and general hs card, on mmp2 in SDMA mode. Signed-off-by: Arindam Nath <arindam.nath@amd.com> Reviewed-by: Philip Rakity <prakity@marvell.com> Tested-by: Philip Rakity <prakity@marvell.com> Acked-by: Zhangfei Gao <zhangfei.gao@marvell.com> Signed-off-by: Chris Ball <cjb@laptop.org>
* mmc: sd: add support for tuning during uhs initializationArindam Nath2011-05-241-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Host Controller needs tuning during initialization to operate SDR50 and SDR104 UHS-I cards. Whether SDR50 mode actually needs tuning is indicated by bit 45 of the Host Controller Capabilities register. A new command CMD19 has been defined in the Physical Layer spec v3.01 to request the card to send tuning pattern. We enable Buffer Read Ready interrupt at the very begining of tuning procedure, because that is the only interrupt generated by the Host Controller during tuning. We program the block size to 64 in the Block Size register. We make sure that DMA Enable and Multi Block Select in the Transfer Mode register are set to 0 before actually sending CMD19. The tuning block is sent by the card to the Host Controller using DAT lines, so we set Data Present Select (bit 5) in the Command register. The Host Controller is responsible for doing the verfication of tuning block sent by the card at the hardware level. After sending CMD19, we wait for Buffer Read Ready interrupt. In case we don't receive an interrupt after the specified timeout value, we fall back on fixed sampling clock by setting Execute Tuning (bit 6) and Sampling Clock Select (bit 7) of Host Control2 register to 0. Before exiting the tuning procedure, we disable Buffer Read Ready interrupt and re-enable other interrupts. Tested by Zhangfei Gao with a Toshiba uhs card and general hs card, on mmp2 in SDMA mode. Signed-off-by: Arindam Nath <arindam.nath@amd.com> Reviewed-by: Philip Rakity <prakity@marvell.com> Tested-by: Philip Rakity <prakity@marvell.com> Acked-by: Zhangfei Gao <zhangfei.gao@marvell.com> Signed-off-by: Chris Ball <cjb@laptop.org>
* mmc: sd: add support for uhs bus speed mode selectionArindam Nath2011-05-241-0/+6
| | | | | | | | | | | | | | | | | | | | | | This patch adds support for setting UHS-I bus speed mode during UHS-I initialization procedure. Since both the host and card can support more than one bus speed, we select the highest speed based on both of their capabilities. First we set the bus speed mode for the card using CMD6 mode 1, and then we program the host controller to support the required speed mode. We also set High Speed Enable in case one of the UHS-I modes is selected. We take care to reset SD clock before setting UHS mode in the Host Control2 register, and then re-enable it as per the Host Controller spec v3.00. We then set the clock frequency for the UHS-I mode selected. Tested by Zhangfei Gao with a Toshiba uhs card and general hs card, on mmp2 in SDMA mode. Signed-off-by: Arindam Nath <arindam.nath@amd.com> Reviewed-by: Philip Rakity <prakity@marvell.com> Tested-by: Philip Rakity <prakity@marvell.com> Acked-by: Zhangfei Gao <zhangfei.gao@marvell.com> Signed-off-by: Chris Ball <cjb@laptop.org>
* mmc: sd: add support for driver type selectionArindam Nath2011-05-241-1/+10
| | | | | | | | | | | | | | | | | | | | | | | | | This patch adds support for setting driver strength during UHS-I initialization procedure. Since UHS-I cards set S18A (bit 24) in response to ACMD41, we use this as a base for UHS-I initialization. We modify the parameter list of mmc_sd_get_cid() so that we can save the ROCR from ACMD41 to check whether bit 24 is set. We decide whether the Host Controller supports A, C, or D driver type depending on the Capabilities register. Driver type B is suported by default. We then set the appropriate driver type for the card using CMD6 mode 1. As per Host Controller spec v3.00, we set driver type for the host only if Preset Value Enable in the Host Control2 register is not set. SDHCI_HOST_CONTROL has been renamed to SDHCI_HOST_CONTROL1 to conform to the spec. Tested by Zhangfei Gao with a Toshiba uhs card and general hs card, on mmp2 in SDMA mode. Signed-off-by: Arindam Nath <arindam.nath@amd.com> Reviewed-by: Philip Rakity <prakity@marvell.com> Tested-by: Philip Rakity <prakity@marvell.com> Acked-by: Zhangfei Gao <zhangfei.gao@marvell.com> Signed-off-by: Chris Ball <cjb@laptop.org>
* mmc: sd: add support for signal voltage switch procedureArindam Nath2011-05-241-2/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Host Controller v3.00 adds another Capabilities register. Apart from other things, this new register indicates whether the Host Controller supports SDR50, SDR104, and DDR50 UHS-I modes. The spec doesn't mention about explicit support for SDR12 and SDR25 UHS-I modes, so the Host Controller v3.00 should support them by default. Also if the controller supports SDR104 mode, it will also support SDR50 mode as well. So depending on the host support, we set the corresponding MMC_CAP_* flags. One more new register. Host Control2 is added in v3.00, which is used during Signal Voltage Switch procedure described below. Since as per v3.00 spec, UHS-I supported hosts should set S18R to 1, we set S18R (bit 24) of OCR before sending ACMD41. We also need to set XPC (bit 28) of OCR in case the host can supply >150mA. This support is indicated by the Maximum Current Capabilities register of the Host Controller. If the response of ACMD41 has both CCS and S18A set, we start the signal voltage switch procedure, which if successfull, will switch the card from 3.3V signalling to 1.8V signalling. Signal voltage switch procedure adds support for a new command CMD11 in the Physical Layer Spec v3.01. As part of this procedure, we need to set 1.8V Signalling Enable (bit 3) of Host Control2 register, which if remains set after 5ms, means the switch to 1.8V signalling is successfull. Otherwise, we clear bit 24 of OCR and retry the initialization sequence. When we remove the card, and insert the same or another card, we need to make sure that we start with 3.3V signalling voltage. So we call mmc_set_signal_voltage() with MMC_SIGNAL_VOLTAGE_330 set so that we are back to 3.3V signalling voltage before we actually start initializing the card. Tested by Zhangfei Gao with a Toshiba uhs card and general hs card, on mmp2 in SDMA mode. Signed-off-by: Arindam Nath <arindam.nath@amd.com> Reviewed-by: Philip Rakity <prakity@marvell.com> Tested-by: Philip Rakity <prakity@marvell.com> Acked-by: Zhangfei Gao <zhangfei.gao@marvell.com> Signed-off-by: Chris Ball <cjb@laptop.org>
* mmc: sdhci: Add pre and post reset processing for chip specific resetPhilip Rakity2011-05-241-0/+2
| | | | | | | | | | | | | | | | | | | Marvell pxa controllers have private registers that may need to be modified before and after a reset is done. For example, the SD reset operation, RESET_ALL, will reset the private registers to their default state. This will cause the clock adjustment registers that may have been programmed to have incorrect values. RESET_DATA sometimes needs to be delayed before the reset is done (depending on SoC) to enable any transactions being handled by the SDIO card to be completed. Needed in pre SD 3.0 silicon to handle clock gating. Implement hooks to allow this to happen. Signed-off-by: Philip Rakity <prakity@marvell.com> Signed-off-by: Chris Ball <cjb@laptop.org>
* mmc: sdhci: work around broken dma boundary behaviorMikko Vinni2011-05-241-0/+6
| | | | | | | | | | | | | | | | | | Some SD host controllers (noticed on an integrated JMicron SD reader on an HP Pavilion dv5-1250eo laptop) don't update the dma address register before signaling a dma interrupt due to a dma boundary. Update the register manually to the next boundary (by default 512KiB), at which the transfer stopped. As long as each transfer is at most 512KiB in size (guaranteed by a BUG_ON in sdhci_prepare_data()) and the boundary is kept at the default value, this fix is needed at most once per transfer. Smaller boundaries are taken care of by counting the transferred bytes. Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=28462 Signed-off-by: Mikko Vinni <mmvinni@yahoo.com> Signed-off-by: Chris Ball <cjb@laptop.org>
* mmc: sdhci: add the abort CMDTYPE bits definitionRichard Zhu2011-03-251-0/+1
| | | | | | | Add the abort CMDTYPE bits definition of command register (offset 0xE) Signed-off-by: Richard Zhu <Hong-Xing.Zhu@freescale.com> Signed-off-by: Chris Ball <cjb@laptop.org>
OpenPOWER on IntegriCloud