Commit graph

131 commits

Author SHA1 Message Date
Chaotian Jing
9979dbe515 mmc: mmc: extend the mmc_send_tuning()
The mmc_execute_tuning() has already prepared the opcode,
there is no need to prepare it again at mmc_send_tuning(),
and, there is a BUG of mmc_send_tuning() to determine the opcode
by bus width, assume eMMC was running at HS200, 4bit mode,
then the mmc_send_tuning() will overwrite the opcode from CMD21
to CMD19, then got error.

in addition, extend an argument of "cmd_error" to allow getting
if there was cmd error when tune response.

Signed-off-by: Chaotian Jing <chaotian.jing@mediatek.com>
[Ulf: Rebased patch]
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2015-10-27 10:38:41 +01:00
Haibo Chen
e31e67cf25 mmc: sdhci-esdhc-imx: change default watermark level and burst length
By default, for all imx SoC types, the watermark level is 16, and the
burst length is 8. But if the SDIO/SD/MMC I/O speed is fast enough,
this default watermark level and burst length will be the performance
bottleneck.

For example, i.MX7D support eMMC HS400 mode, this mode can run in 8 bit,
200MHZ DDR mode. So the I/O speed improve a lot compare to SD3.0.
The default burst length is 8, if we don't change this value, in
HS400 mode, when we do eMMC read operation, we can find that the
clock signal will stop for a period of time. This means the speed
of data moving on AHB bus is slower than I/O speed. So we should
improve the speed of data moving on AHB bus.

This patch set the default burst length as 16, and set the default
watermark level as 64. The test result is the clock signal has
no stop during the eMMC HS400 operation.

Signed-off-by: Haibo Chen <haibo.chen@freescale.com>
Acked-by: Dong Aisheng <aisheng.dong@freescale.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2015-08-27 14:50:51 +02:00
Haibo Chen
fd44954e77 mmc: sdhci-esdhc-imx: set back the burst_length_enable bit to 1
Currently we find that if a usdhc is choosed to boot system, then ROM
code will set the burst length enable bit of this usdhc as 0.

This will make performance drop a lot if this usdhc's burst length is
configed. So this patch set back the burst_length_enable bit as 1,
which is the default value, and means burst length is enabled for INCR.

Signed-off-by: Haibo Chen <haibo.chen@freescale.com>
Acked-by: Dong Aisheng <aisheng.dong@freescale.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2015-08-27 14:50:51 +02:00
Haibo Chen
d407e30ba6 mmc: sdhci-esdhc-imx: add tuning-step setting support
tuning-step is the delay cell steps in tuning procedure. The default value
of tuning-step is 1. Some boards or cards need another value to pass the
tuning procedure. For example, imx7d-sdb board need the tuning-step value
as 2, otherwise it can't pass the tuning procedure.

So this patch add the tuning-step setting in driver, so that user can set
the tuning-step value in dts.

Signed-off-by: Haibo Chen <haibo.chen@freescale.com>
Acked-by: Dong Aisheng <aisheng.dong@freescale.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2015-08-27 14:50:50 +02:00
Haibo Chen
28b07674f2 mmc: sdhci-esdhc-imx: add imx7d support and support HS400
The imx7d usdhc is derived from imx6sx, the difference is that
imx7d support HS400.

So introduce a new compatible string for imx7d and add HS400
support for imx7d usdhc.

Signed-off-by: Haibo Chen <haibo.chen@freescale.com>
Acked-by: Dong Aisheng <aisheng.dong@freescale.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2015-08-27 14:50:50 +02:00
Dong Aisheng
a3bd4f989f mmc: sdhci-esdhc-imx: clear f_max in boarddata
After commit 8d86e4fccc ("mmc: sdhci-esdhc-imx: Call mmc_of_parse()"),
it's not used anymore.

Signed-off-by: Dong Aisheng <aisheng.dong@freescale.com>
Reviewed-by: Johan Derycke <johan.derycke@barco.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2015-07-24 10:18:38 +02:00
Dong Aisheng
2e05d66b6b mmc: sdhci-esdhc-imx: remove duplicated dts parsing
After commit 8d86e4fccc ("mmc: sdhci-esdhc-imx: Call mmc_of_parse()"),
we do not need those duplicated parsing anymore.

Note: fsl,cd-controller is also deleted due to the driver does
not support controller card detection anymore after switch to runtime pm.
And there's no user of it right now in device tree.

wp-gpios is kept because we're still support fsl,wp-controller,
so we need a way to check if it's gpio wp or controller wp.

Signed-off-by: Dong Aisheng <aisheng.dong@freescale.com>
Reviewed-by: Johan Derycke <johan.derycke@barco.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2015-07-24 10:18:38 +02:00
Dong Aisheng
91fa425287 mmc: sdhci-esdhc-imx: move all non dt probe code into one function
This is an incremental fix of commit
e62bd351b("mmc: sdhci-esdhc-imx: Do not break platform data boards").

After commit 8d86e4fccc ("mmc: sdhci-esdhc-imx: Call mmc_of_parse()"),
we do not need to run the check of boarddata->wp_type/cd_type/max_bus_width
again for dt platform since those are already handled by mmc_of_parse().

Current code only exclude the checking of wp_type for dt platform which
does not make sense.

This patch moves all non dt probe code into one function.
Besides, since we only support SD3.0/eMMC HS200 for dt platform, the
support_vsel checking and ultra high speed pinctrl state are also merged
into sdhci_esdhc_imx_probe_dt.

Then we have two separately probe function for dt and non dt type.
This can make the driver probe more clearly.

Signed-off-by: Dong Aisheng <aisheng.dong@freescale.com>
Reviewed-by: Johan Derycke <johan.derycke@barco.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2015-07-24 10:18:37 +02:00
Dong Aisheng
4800e87a2e mmc: sdhci-esdhc-imx: fix cd regression for dt platform
Current card detect probe process is that when driver finds a valid
ESDHC_CD_GPIO, it will clear the quirk SDHCI_QUIRK_BROKEN_CARD_DETECTION
which is set by default for all esdhc/usdhc controllers.
Then host driver will know there's a valid card detect function.

Commit 8d86e4fccc ("mmc: sdhci-esdhc-imx: Call mmc_of_parse()")
breaks GPIO CD function for dt platform that it will return directly
when find ESDHC_CD_GPIO for dt platform which result in the later wrongly
to keep SDHCI_QUIRK_BROKEN_CARD_DETECTION for all dt platforms.
Then MMC_CAP_NEEDS_POLL will be used instead even there's a valid
GPIO card detect.

This patch adds back this function and follows the original approach to
clear the quirk if find an valid CD GPIO for dt platforms.

Fixes: 8d86e4fccc ("mmc: sdhci-esdhc-imx: Call mmc_of_parse()")
Signed-off-by: Dong Aisheng <aisheng.dong@freescale.com>
Reviewed-by: Johan Derycke <johan.derycke@barco.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2015-07-24 10:18:37 +02:00
Dong Aisheng
4245afff8b mmc: sdhci-esdhc-imx: add quirk SDHCI_QUIRK2_BROKEN_HS200 for imx6qdl
The iMX6Q/DL can not support HS200 mode while iMX6SL and iMX6SX can,
so introduce a new flag to distinguish them.

Signed-off-by: Dong Aisheng <aisheng.dong@freescale.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2015-06-01 09:07:18 +02:00
Dong Aisheng
913d4951a5 mmc: sdhci-esdhc-imx: add imx6sx support
The imx6sx usdhc is derived from imx6sl, the difference is minor.
imx6sx have the errata ESDHC_FLAG_ERR004536 fixed.
So introduce a new compatible string for imx6sx to distinguish them.

Signed-off-by: Dong Aisheng <b29396@freescale.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2015-06-01 09:07:17 +02:00
Dong Aisheng
18094430d6 mmc: sdhci-esdhc-imx: add ADMA Length Mismatch errata fix
The uSDHC has an ADMA Length Mismatch errata ERR004536 which may
cause ADMA work abnormally. The errata has already been fixed for
i.MX6Q TO1.2 and i.MX6DL TO1.1 by enable the bit 7 in 0x6c register.
Unfortunately this fix is not included in i.MX6SL.
So we disable ADMA for i.MX6SL and use SDMA instead.

Signed-off-by: Dong Aisheng <aisheng.dong@freescale.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2015-06-01 09:07:16 +02:00
Dong Aisheng
b7321042aa mmc: sdhci-esdhc-imx: usdhc does not have missing card interrupt issue
The usdhc does not have missing card interrupt issue, so don't execute
workaround for usdhc.

Signed-off-by: Dong Aisheng <aisheng.dong@freescale.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2015-06-01 09:07:16 +02:00
Dong Aisheng
915be485bd mmc: sdhci-esdhc-imx: merge the same register check into one place
In esdhc_writel_le() function, there's duplicated checking of the same
register as follows:
"if (unlikely(reg == SDHCI_INT_ENABLE || reg == SDHCI_SIGNAL_ENABLE))".
Merge them into one and remove the duplicated one.

Signed-off-by: Dong Aisheng <aisheng.dong@freescale.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2015-06-01 09:07:15 +02:00
Fabio Estevam
7ccddeb08a mmc: sdhci-esdhc-imx: Do not break platform data boards
The only user of this driver that has not been converted to fully
device tree is the i.MX35 SoC.

There is a i.MX35-based board (mach-pcm043.c) that uses platform data
to pass wp_gpio and cd_gpio information.

Commit 8d86e4fccc ("mmc: sdhci-esdhc-imx: Call mmc_of_parse()")
broke the platform data case by removing mmc_gpio_request_ro() and
mmc_gpio_request_cd(), so restore the functionality for the non-dt
case.

Also, restore the check for ESDHC_CD_CONTROLLER so that we can still
support the "fsl,cd-controller" property.

Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2015-06-01 09:07:01 +02:00
Fabio Estevam
1506411927 mmc: sdhci-esdhc-imx: Move mmc_of_parse() to the dt probe
mmc_of_parse() should be placed inside sdhci_esdhc_imx_probe_dt() as it
suits only for the dt case.

Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2015-06-01 09:07:00 +02:00
Krzysztof Kozlowski
f8cbf461f9 mmc: sdhci-imx: Constify platform_device_id
The platform_device_id is not modified by the driver and core uses it as
const.

Signed-off-by: Krzysztof Kozlowski <k.kozlowski.k@gmail.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2015-06-01 09:06:51 +02:00
Wolfram Sang
035ff831cd mmc: host: sdhci-esdhc-imx: fix broken email address
My Pengutronix address is not valid anymore, redirect people to the Pengutronix
kernel team.

Reported-by: Harald Geyer <harald@ccbib.org>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Acked-by: Robert Schwebel <r.schwebel@pengutronix.de>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2015-05-25 09:20:07 +02:00
Fabio Estevam
8d86e4fccc mmc: sdhci-esdhc-imx: Call mmc_of_parse()
Currently it is not possible to use 'mmc-pwrseq-simple' property with this
driver because mmc_of_parse() is never called.

mmc_of_parse() calls mmc_pwrseq_alloc() that manages MMC power sequence and
allows passing GPIOs in the devicetree to properly power/reset the Wifi
chipset.

When using mmc_of_parse() we no longer need to have custom code to request
card-detect and write-protect pins, as this can now be handled by the mmc
core.

Tested on a imx6sl-warp board where BT/Wifi is functional and also on a
imx6q-sabresd.

Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2015-04-09 09:14:41 +02:00
Sascha Hauer
07bf2b54cd mmc: sdhci-esdhc-imx: support voltage-range property
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2015-03-25 09:46:35 +01:00
Dan Carpenter
eeed7026b4 mmc: sdhci-esdhc-imx: silence a false curly braces warning
Static checkers suggest that probably we intended to put curly braces
around the writel() to make it part of the else path.  But, I think
actually the indenting is off and the code works fine as is.

The stray tab was introduced in 0322191e62 ('mmc: sdhci-esdhc-imx: add
sd3.0 SDR clock tuning support')

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Dong Aisheng <b29396@freescale.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2015-03-23 14:13:39 +01:00
Ulf Hansson
77903c01d8 mmc: sdhci-esdhc-imx: Fixup runtime PM conditions during ->probe()
By configure runtime PM prior we enable the use of it, we close the gap
for strange and unhandled conditions. Moreover it makes us rely on the
driver core, after finalized ->probe(), to request an inactive device
to become runtime PM idle/suspended, which earlier potentially could
happen already at pm_runtime_set_autosuspend_delay().

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2015-01-19 09:56:22 +01:00
Ulf Hansson
0b41436840 mmc: sdhci-esdhc-imx: Fixup ->remove()
Since sdhci_remove_host() access the device, we need to make sure it's
runtime PM resumed.

To handle clock gating properly in remove, we first have to make sure
the clocks are ungated.

To fix both these issues, by invoking pm_runtime_get_sync() early in
->remove() callback. Later once we disabled runtime PM, we can restore
the usage count.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2015-01-19 09:56:21 +01:00
Linus Torvalds
92a578b064 ACPI and power management updates for 3.19-rc1
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).
 
 /
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v2.0.22 (GNU/Linux)
 
 iQIcBAABCAAGBQJUhj6JAAoJEILEb/54YlRxTM4P/j5g5SfqvY0QKsn7sR7MGZ6v
 nsgCBhJAqTw3ocNC7EAs8z9h2GWy1KbKpakKYWAh9Fs1yZoey7tFSlcv/Rgjlp70
 uU5sDQHtpE9mHKiymdsowiQuWgpl962L4k+k8hUslhlvgk1PvVbpajR6OqG8G+pD
 asuIW9eh1APNkLyXmRJ3ZPomzs0VmRdZJ0NEs0lKX9mJskqEvxPIwdaxq3iaJq9B
 Fo0J345zUDcJnxWblDRdHlOigCimglElfN5qJwaC4KpwUKuBvLRKbp4f69+wfT0c
 kYFiR29X5KjJ2kLfP/wKsLyuDCYYXRq3tCia5M1tAqOjZ+UA89H/GDftx/5lntmv
 qUlBa35VfdS1SX4HyApZitOHiLgo+It/hl8Z9bJnhyVw66NxmMQ8JYN2imb8Lhqh
 XCLR7BxLTah82AapLJuQ0ZDHPzZqMPG2veC2vAzRMYzVijict/p4Y2+qBqONltER
 4rs9uRVn+hamX33lCLg8BEN8zqlnT3rJFIgGaKjq/wXHAU/zpE9CjOrKMQcAg9+s
 t51XMNPwypHMAYyGVhEL89ImjXnXxBkLRuquhlmEpvQchIhR+mR3dLsarGn7da44
 WPIQJXzcsojXczcwwfqsJCR4I1FTFyQIW+UNh02GkDRgRovQqo+Jk762U7vQwqH+
 LBdhvVaS1VW4v+FWXEoZ
 =5dox
 -----END PGP SIGNATURE-----

Merge tag 'pm+acpi-3.19-rc1' of 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
  ...
2014-12-10 21:17:00 -08:00
Ulf Hansson
d178532689 mmc: sdhci-esdhc-imx: Convert to mmc_send_tuning()
Instead of having a local function taking care of sending the tuning
command, let's use the common mmc_send_tuning() API provided by the mmc
core. In this way the request will be handled as any other request by
sdhci core.

As an effect of this change, the pm_runtime_get_sync() call at
esdhc_prepare_tuning() isn't needed any more.

This patch will also introduce another change in behavior, since before
the response pattern to the tuning command wasn't verified by
sdhci-esdhc-imx. The mmc_send_tuning() does that.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Tested-by: Dong Aisheng <b29396@freescale.com>
Acked-by: Dong Aisheng <b29396@freescale.com>
2014-12-08 09:20:47 +01:00
Rafael J. Wysocki
162d6f9800 MMC / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
After commit b2b49ccbdd (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>
2014-12-05 03:05:33 +01:00
Dirk Behme
cd529af7ee mmc: sdhci-esdhc-imx: don't exit in case of no pinctrl states
The commit ad93220de7 ("mmc: sdhci-esdhc-imx: change pinctrl state
according to uhs mode") exits the probe in case there are no valid
pinctrl states found.

As there are configurations doing the pin mux properly in the boot
loader, don't exit. Just warn, but go on in case if there are no
pinctrl states in the device tree.

Signed-off-by: Dirk Behme <dirk.behme@de.bosch.com>
Signed-off-by: Andrew Gabbasov <andrew_gabbasov@mentor.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2014-11-10 12:40:26 +01:00
Aisheng Dong
e33eb8e281 mmc: sdhci-esdhc-imx: set the correct max timeout value for uSDHC
The default sdhci driver write 0xE into timeout counter register to
set the maximum timeout. The value is not correct for uSDHC since the
max counter value for uSDHC is 0xF.
Instead of using common timeout code in sdhci, we implement esdhc_set_timeout
to handle the difference between eSDHC and uSDHC.

Currently we simply set the max timeout value as before.
But in the future, we probably may implement IMX specific timeout
setting algorithm and use suitable timeout for different CMDs.

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>
2014-09-09 13:59:21 +02:00
Aisheng Dong
10fd0ad967 mmc: sdhci-esdhc-imx: fix incorrect max timeout cout for uSDHC
The default sdhci code use the 1 << 27 as the max timeout counter to
to calculate the max_busy_timeout, however it's not correct for uSDHC
since its the max counter is 1 << 28.
Implement esdhc_get_max_timeout_cout to handle it correctly.

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>
2014-09-09 13:59:20 +02:00
Peter Griffin
2137f5d3b8 mmc: remove .owner field for drivers using module_platform_driver
This patch removes the superflous .owner field for drivers which
use the module_platform_driver API, as this is overriden in
platform_driver_register anyway.

Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2014-09-09 13:59:04 +02:00
Aisheng Dong
69f5bf38f9 mmc: sdhci-esdhc-imx: fix mmc ddr mode regression issue
It's caused by the platform driver was still using MMC_TIMING_UHS_DDR50
for MMC DDR mode which needs update too.

Reported-by: Fabio Estevam <fabio.estevam@freescale.com>
Reported-by: Shawn Guo <shawn.guo@freescale.com>
Signed-off-by: Dong Aisheng <b29396@freescale.com>
Tested-by: Fabio Estevam <fabio.estevam@freescale.com>
[Ulf Hansson] Resolved conflict
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>
2014-05-22 08:40:45 -04:00
Russell King
850a29b859 mmc: sdhci-esdhc-imx: remove emulation of uhs_mode
We no longer need to emulate the uhs_mode field of the host control2
register - the main sdhci driver never reads this back to evaluate
the current mode as it caches the current mode instead.

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>
2014-05-22 08:33:27 -04:00
Russell King
13e645012d mmc: sdhci: set_uhs_signaling() need not return a value
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>
2014-05-22 07:26:34 -04:00
Russell King
cb399da401 mmc: sdhci-esdhc-imx: fix lockdep splat upon tuning
=================================
[ INFO: inconsistent lock state ]
3.14.0-rc1+ #490 Not tainted
---------------------------------
inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
kworker/u8:0/6 [HC0[0]:SC0[0]:HE1:SE1] takes:
 (&(&host->lock)->rlock#2){?.-...}, at: [<c04b57a4>] esdhc_send_tuning_cmd+0x104/0x14c
{IN-HARDIRQ-W} state was registered at:
  [<c00652fc>] mark_lock+0x15c/0x6f8
  [<c0066354>] __lock_acquire+0xabc/0x1ca0
  [<c0067ad8>] lock_acquire+0xa0/0x130
  [<c0697a44>] _raw_spin_lock+0x34/0x44
  [<c04b0dbc>] sdhci_irq+0x20/0xa40
  [<c0071b1c>] handle_irq_event_percpu+0x74/0x284
  [<c0071d70>] handle_irq_event+0x44/0x64
  [<c0074db8>] handle_fasteoi_irq+0xac/0x140
  [<c007147c>] generic_handle_irq+0x28/0x38
  [<c000efd4>] handle_IRQ+0x40/0x98
  [<c0008584>] gic_handle_irq+0x30/0x64
  [<c0013144>] __irq_svc+0x44/0x58
  [<c0028fc8>] irq_exit+0xc0/0x120
  [<c000efd8>] handle_IRQ+0x44/0x98
  [<c0008584>] gic_handle_irq+0x30/0x64
  [<c0013144>] __irq_svc+0x44/0x58
  [<c068f398>] printk+0x3c/0x44
  [<c03191d0>] _regulator_get+0x1b4/0x1e0
  [<c031924c>] regulator_get+0x18/0x1c
  [<c049fbc4>] mmc_add_host+0x30/0x1c0
  [<c04b2e10>] sdhci_add_host+0x804/0xbbc
  [<c04b5318>] sdhci_esdhc_imx_probe+0x380/0x674
  [<c036d530>] platform_drv_probe+0x20/0x50
  [<c036b948>] driver_probe_device+0x120/0x234
  [<c036baf8>] __driver_attach+0x9c/0xa0
  [<c036a04c>] bus_for_each_dev+0x5c/0x90
  [<c036b418>] driver_attach+0x24/0x28
  [<c036b018>] bus_add_driver+0xe4/0x1d8
  [<c036c1b0>] driver_register+0x80/0xfc
  [<c036ce28>] __platform_driver_register+0x50/0x64
  [<c093706c>] sdhci_esdhc_imx_driver_init+0x18/0x20
  [<c0008834>] do_one_initcall+0x3c/0x164
  [<c0901c94>] kernel_init_freeable+0x104/0x1d0
  [<c068c45c>] kernel_init+0x10/0x118
  [<c000e768>] ret_from_fork+0x14/0x2c
irq event stamp: 5933
hardirqs last  enabled at (5933): [<c069813c>] _raw_spin_unlock_irqrestore+0x38/0x4c
hardirqs last disabled at (5932): [<c0697b04>] _raw_spin_lock_irqsave+0x24/0x60
softirqs last  enabled at (5914): [<c0028ba0>] __do_softirq+0x260/0x360
softirqs last disabled at (5909): [<c0028fc8>] irq_exit+0xc0/0x120

other info that might help us debug this:
 Possible unsafe locking scenario:

       CPU0
       ----
  lock(&(&host->lock)->rlock#2);
  <Interrupt>
    lock(&(&host->lock)->rlock#2);

 *** DEADLOCK ***

2 locks held by kworker/u8:0/6:
 #0:  (kmmcd){.+.+.+}, at: [<c003d890>] process_one_work+0x134/0x4e8
 #1:  ((&(&host->detect)->work)){+.+.+.}, at: [<c003d890>] process_one_work+0x134/0x4e8

stack backtrace:
CPU: 2 PID: 6 Comm: kworker/u8:0 Not tainted 3.14.0-rc1+ #490
Workqueue: kmmcd mmc_rescan
Backtrace:
[<c00124a0>] (dump_backtrace) from [<c0012640>] (show_stack+0x18/0x1c)
[<c0012628>] (show_stack) from [<c069164c>] (dump_stack+0x70/0x8c)
[<c06915dc>] (dump_stack) from [<c068f080>] (print_usage_bug+0x274/0x2e4)
[<c068ee0c>] (print_usage_bug) from [<c0065774>] (mark_lock+0x5d4/0x6f8)
[<c00651a0>] (mark_lock) from [<c0065e6c>] (__lock_acquire+0x5d4/0x1ca0)
[<c0065898>] (__lock_acquire) from [<c0067ad8>] (lock_acquire+0xa0/0x130)
[<c0067a38>] (lock_acquire) from [<c0697a44>] (_raw_spin_lock+0x34/0x44)
[<c0697a10>] (_raw_spin_lock) from [<c04b57a4>] (esdhc_send_tuning_cmd+0x104/0x14c)
[<c04b56a0>] (esdhc_send_tuning_cmd) from [<c04b582c>] (esdhc_executing_tuning+0x40/0x100)
[<c04b57ec>] (esdhc_executing_tuning) from [<c04afa54>] (sdhci_execute_tuning+0xcc/0x754)
[<c04af988>] (sdhci_execute_tuning) from [<c04a4684>] (mmc_sd_init_card+0x65c/0x694)
[<c04a4028>] (mmc_sd_init_card) from [<c04a48f0>] (mmc_attach_sd+0xb0/0x184)
[<c04a4840>] (mmc_attach_sd) from [<c049eb28>] (mmc_rescan+0x26c/0x2e8)
[<c049e8bc>] (mmc_rescan) from [<c003d914>] (process_one_work+0x1b8/0x4e8)
[<c003d75c>] (process_one_work) from [<c003e090>] (worker_thread+0x13c/0x3f8)
[<c003df54>] (worker_thread) from [<c00449bc>] (kthread+0xcc/0xe8)
[<c00448f0>] (kthread) from [<c000e768>] (ret_from_fork+0x14/0x2c)

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>
2014-05-22 07:26:33 -04:00
Russell King
10cf496300 mmc: sdhci-esdhc-imx: comment runtime_pm_get_sync() in esdhc_prepare_tuning()
It is far from obvious what this is doing, and it looks like it's an
unbalanced runtime_pm_get() call.  However, the put is inside
sdhci_tasklet_finish(), so it's not unbalanced at all.  This should
be documented so people know what's going on here.  Do so.

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>
2014-05-22 07:26:33 -04:00
Russell King
9d2fc80fb1 mmc: sdhci-esdhc-imx: avoid DMA to kernel stack
sdhci-esdhc-imx tries to DMA to the kernel stack when tuning the
interface, which causes dma-debug to complain.  Fix this by kmallocing
a buffer to hold the received tuning pattern.

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>
2014-05-22 07:26:32 -04:00
Russell King
1650d0c71a mmc: sdhci: move setting mmc->actual_clock into set_clock handlers
Move the setting of mmc->actual_clock to zero into the set_clock
handlers themselves.  This will allow us to clean up the calling
logic for the set_clock() method, and turn sdhci_set_clock() into
a library function.

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>
2014-05-22 07:26:31 -04:00
Russell King
373073efd0 mmc: sdhci: move setting host->clock into sdhci_do_set_ios()
We don't need implementations to do this, since the only time it's
necessary is when we change the clock, and the only place that happens
is in sdhci_do_set_ios().  So, move it there, and remove it from the
iMX platform backend.

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>
2014-05-22 07:26:31 -04:00
Russell King
0718e59ae2 mmc: sdhci: move FSL ESDHC reset handling quirk into esdhc code
The Freescale esdhc driver is the only driver which needs the interrupt
registers restored after a reset.  Move this quirk to be part of the
ESDHC driver implementation.

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>
2014-05-22 07:26:28 -04:00
Russell King
03231f9b78 mmc: sdhci: convert reset into a library function
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>
2014-05-22 07:26:28 -04:00
Russell King
2317f56c05 mmc: sdhci: convert generic bus width setup to library function
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>
2014-05-22 07:26:27 -04:00
Russell King
be138554a7 mmc: sdhci: allow sdio interrupts while sdhci runtime suspended
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>
2014-05-22 07:26:26 -04:00
Dong Aisheng
a7f2be94be mmc: sdhci-esdhc-imx: fix warning during module remove function
Since the clock is managed by runtime pm currently, we do not need
disable it again during driver remove function, or it will cause
clock disable count mismatch issue since the clocks have already been disabled.

The issue can be simply reproduced by unbind the devices via sysfs.
mx6slevk:/sys/bus/platform/drivers/sdhci-esdhc-imx# echo 2194000.usdhc > unbind
mmc1: card aaaa removed
------------[ cut here ]------------
WARNING: CPU: 0 PID: 657 at drivers/clk/clk.c:842 __clk_disable+0x68/0x88()
Modules linked in:
CPU: 0 PID: 657 Comm: sh Not tainted 3.13.0-rc1+ #285
Backtrace:
[<80012160>] (dump_backtrace+0x0/0x10c) from [<80012438>] (show_stack+0x18/0x1c)
 r6:80481370 r5:00000000 r4:8088ecc8 r3:00000000
[<80012420>] (show_stack+0x0/0x1c) from [<80616b14>] (dump_stack+0x84/0x9c)
[<80616a90>] (dump_stack+0x0/0x9c) from [<80027158>] (warn_slowpath_common+0x70/0x94)
 r5:00000009 r4:00000000
[<800270e8>] (warn_slowpath_common+0x0/0x94) from [<80027220>] (warn_slowpath_null+0x24/0x2c)
 r8:bec4ff78 r7:0000000e r6:bf91d800 r5:bf81d080 r4:bf81d080
[<800271fc>] (warn_slowpath_null+0x0/0x2c) from [<80481370>] (__clk_disable+0x68/0x88)
[<80481308>] (__clk_disable+0x0/0x88) from [<8048148c>] (clk_disable+0x20/0x2c)
 r4:200f0113 r3:bf95ec00
[<8048146c>] (clk_disable+0x0/0x2c) from [<80463bd8>] (sdhci_esdhc_imx_remove+0x64/0xa4)
 r5:bf81d080 r4:bfabb010
[<80463b74>] (sdhci_esdhc_imx_remove+0x0/0xa4) from [<8032e82c>] (platform_drv_remove+0x20/0x24)
 r6:808ae0e0 r5:808ae0e0 r4:bf91d810 r3:80463b74
[<8032e80c>] (platform_drv_remove+0x0/0x24) from [<8032d010>] (__device_release_driver+0x78/0xd0)
[<8032cf98>] (__device_release_driver+0x0/0xd0) from [<8032d090>] (device_release_driver+0x28/0x34)
 r5:bf91d810 r4:bf91d844
[<8032d068>] (device_release_driver+0x0/0x34) from [<8032c0c8>] (unbind_store+0x80/0xc4)
 r5:bf91d810 r4:80899ba0
[<8032c048>] (unbind_store+0x0/0xc4) from [<8032b648>] (drv_attr_store+0x28/0x34)
 r7:bed73100 r6:0000000e r5:00000000 r4:8032b620
[<8032b620>] (drv_attr_store+0x0/0x34) from [<80140580>] (sysfs_write_file+0x1b0/0x1e4)
[<801403d0>] (sysfs_write_file+0x0/0x1e4) from [<800dcda0>] (vfs_write+0xb4/0x190)
[<800dccec>] (vfs_write+0x0/0x190) from [<800dd3e4>] (SyS_write+0x44/0x80)
 r9:0000000e r8:00000000 r7:01a00408 r6:bf3b1c00 r5:00000000
r4:00000000
[<800dd3a0>] (SyS_write+0x0/0x80) from [<8000e900>] (ret_fast_syscall+0x0/0x48)
 r9:bec4e000 r8:8000eac4 r7:00000004 r6:76f5fb40 r5:01a00408
r4:0000000e
---[ end trace a0897d268e6233b2 ]---

If without runtime pm, we just run as before to match the clock enable
in probe function.

Signed-off-by: Dong Aisheng <b29396@freescale.com>
Acked-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Chris Ball <chris@printf.net>
2014-01-13 14:02:39 -05:00
Dong Aisheng
a974862fae mmc: sdhci-esdhc-imx: fix access hardirq-unsafe lock in atomic context
Sometimes we may meet the following lockdep issue.
The root cause is .set_clock callback is executed with spin_lock_irqsave
in sdhci_do_set_ios. However, the IMX set_clock callback will try to access
clk_get_rate which is using a mutex lock.

The fix avoids access mutex in .set_clock callback by initializing the
pltfm_host->clock at probe time and use it later instead of calling
clk_get_rate again in atomic context.

[ INFO: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected ]
3.13.0-rc1+ #285 Not tainted
------------------------------------------------------
kworker/u8:1/29 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
 (prepare_lock){+.+...}, at: [<80480b08>] clk_prepare_lock+0x44/0xe4

and this task is already holding:
 (&(&host->lock)->rlock#2){-.-...}, at: [<804611f4>] sdhci_do_set_ios+0x20/0x720
which would create a new lock dependency:
 (&(&host->lock)->rlock#2){-.-...} -> (prepare_lock){+.+...}

but this new dependency connects a HARDIRQ-irq-safe lock:
 (&(&host->lock)->rlock#2){-.-...}
... which became HARDIRQ-irq-safe at:
  [<8005f030>] mark_lock+0x140/0x6ac
  [<80060760>] __lock_acquire+0xb30/0x1cbc
  [<800620d0>] lock_acquire+0x70/0x84
  [<8061d2f0>] _raw_spin_lock+0x30/0x40
  [<80460668>] sdhci_irq+0x24/0xa68
  [<8006b1d4>] handle_irq_event_percpu+0x54/0x18c
  [<8006b350>] handle_irq_event+0x44/0x64
  [<8006e50c>] handle_fasteoi_irq+0xa0/0x170
  [<8006a8f0>] generic_handle_irq+0x30/0x44
  [<8000f238>] handle_IRQ+0x54/0xbc
  [<8000864c>] gic_handle_irq+0x30/0x64
  [<80013024>] __irq_svc+0x44/0x5c
  [<80614c58>] printk+0x38/0x40
  [<804622a8>] sdhci_add_host+0x844/0xbcc
  [<80464948>] sdhci_esdhc_imx_probe+0x378/0x67c
  [<8032ee88>] platform_drv_probe+0x20/0x50
  [<8032d48c>] driver_probe_device+0x118/0x234
  [<8032d690>] __driver_attach+0x9c/0xa0
  [<8032b89c>] bus_for_each_dev+0x68/0x9c
  [<8032cf44>] driver_attach+0x20/0x28
  [<8032cbc8>] bus_add_driver+0x148/0x1f4
  [<8032dce0>] driver_register+0x80/0x100
  [<8032ee54>] __platform_driver_register+0x50/0x64
  [<8084b094>] sdhci_esdhc_imx_driver_init+0x18/0x20
  [<80008980>] do_one_initcall+0x108/0x16c
  [<8081cca4>] kernel_init_freeable+0x10c/0x1d0
  [<80611c50>] kernel_init+0x10/0x120
  [<8000e9c8>] ret_from_fork+0x14/0x2c

to a HARDIRQ-irq-unsafe lock:
 (prepare_lock){+.+...}
... which became HARDIRQ-irq-unsafe at:
...  [<8005f030>] mark_lock+0x140/0x6ac
  [<8005f604>] mark_held_locks+0x68/0x12c
  [<8005f780>] trace_hardirqs_on_caller+0xb8/0x1d8
  [<8005f8b4>] trace_hardirqs_on+0x14/0x18
  [<8061a130>] mutex_trylock+0x180/0x20c
  [<80480ad8>] clk_prepare_lock+0x14/0xe4
  [<804816a4>] clk_notifier_register+0x28/0xf0
  [<80015120>] twd_clk_init+0x50/0x68
  [<80008980>] do_one_initcall+0x108/0x16c
  [<8081cca4>] kernel_init_freeable+0x10c/0x1d0
  [<80611c50>] kernel_init+0x10/0x120
  [<8000e9c8>] ret_from_fork+0x14/0x2c

other info that might help us debug this:

 Possible interrupt unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(prepare_lock);
                               local_irq_disable();
                               lock(&(&host->lock)->rlock#2);
                               lock(prepare_lock);
  <Interrupt>
    lock(&(&host->lock)->rlock#2);

 *** DEADLOCK ***

3 locks held by kworker/u8:1/29:
 #0:  (kmmcd){.+.+.+}, at: [<8003db18>] process_one_work+0x128/0x468
 #1:  ((&(&host->detect)->work)){+.+.+.}, at: [<8003db18>] process_one_work+0x128/0x468
 #2:  (&(&host->lock)->rlock#2){-.-...}, at: [<804611f4>] sdhci_do_set_ios+0x20/0x720

the dependencies between HARDIRQ-irq-safe lock and the holding lock:
-> (&(&host->lock)->rlock#2){-.-...} ops: 330 {
   IN-HARDIRQ-W at:
                    [<8005f030>] mark_lock+0x140/0x6ac
                    [<80060760>] __lock_acquire+0xb30/0x1cbc
                    [<800620d0>] lock_acquire+0x70/0x84
                    [<8061d2f0>] _raw_spin_lock+0x30/0x40
                    [<80460668>] sdhci_irq+0x24/0xa68
                    [<8006b1d4>] handle_irq_event_percpu+0x54/0x18c
                    [<8006b350>] handle_irq_event+0x44/0x64
                    [<8006e50c>] handle_fasteoi_irq+0xa0/0x170
                    [<8006a8f0>] generic_handle_irq+0x30/0x44
                    [<8000f238>] handle_IRQ+0x54/0xbc
                    [<8000864c>] gic_handle_irq+0x30/0x64
                    [<80013024>] __irq_svc+0x44/0x5c
                    [<80614c58>] printk+0x38/0x40
                    [<804622a8>] sdhci_add_host+0x844/0xbcc
                    [<80464948>] sdhci_esdhc_imx_probe+0x378/0x67c
                    [<8032ee88>] platform_drv_probe+0x20/0x50
                    [<8032d48c>] driver_probe_device+0x118/0x234
                    [<8032d690>] __driver_attach+0x9c/0xa0
                    [<8032b89c>] bus_for_each_dev+0x68/0x9c
                    [<8032cf44>] driver_attach+0x20/0x28
                    [<8032cbc8>] bus_add_driver+0x148/0x1f4
                    [<8032dce0>] driver_register+0x80/0x100
                    [<8032ee54>] __platform_driver_register+0x50/0x64
                    [<8084b094>] sdhci_esdhc_imx_driver_init+0x18/0x20
                    [<80008980>] do_one_initcall+0x108/0x16c
                    [<8081cca4>] kernel_init_freeable+0x10c/0x1d0
                    [<80611c50>] kernel_init+0x10/0x120
                    [<8000e9c8>] ret_from_fork+0x14/0x2c
   IN-SOFTIRQ-W at:
                    [<8005f030>] mark_lock+0x140/0x6ac
                    [<80060204>] __lock_acquire+0x5d4/0x1cbc
                    [<800620d0>] lock_acquire+0x70/0x84
                    [<8061d40c>] _raw_spin_lock_irqsave+0x40/0x54
                    [<8045e4a4>] sdhci_tasklet_finish+0x1c/0x120
                    [<8002b538>] tasklet_action+0xa0/0x15c
                    [<8002b778>] __do_softirq+0x118/0x290
                    [<8002bcf4>] irq_exit+0xb4/0x10c
                    [<8000f240>] handle_IRQ+0x5c/0xbc
                    [<8000864c>] gic_handle_irq+0x30/0x64
                    [<80013024>] __irq_svc+0x44/0x5c
                    [<80614c58>] printk+0x38/0x40
                    [<804622a8>] sdhci_add_host+0x844/0xbcc
                    [<80464948>] sdhci_esdhc_imx_probe+0x378/0x67c
                    [<8032ee88>] platform_drv_probe+0x20/0x50
                    [<8032d48c>] driver_probe_device+0x118/0x234
                    [<8032d690>] __driver_attach+0x9c/0xa0
                    [<8032b89c>] bus_for_each_dev+0x68/0x9c
                    [<8032cf44>] driver_attach+0x20/0x28
                    [<8032cbc8>] bus_add_driver+0x148/0x1f4
                    [<8032dce0>] driver_register+0x80/0x100
                    [<8032ee54>] __platform_driver_register+0x50/0x64
                    [<8084b094>] sdhci_esdhc_imx_driver_init+0x18/0x20
                    [<80008980>] do_one_initcall+0x108/0x16c
                    [<8081cca4>] kernel_init_freeable+0x10c/0x1d0
                    [<80611c50>] kernel_init+0x10/0x120
                    [<8000e9c8>] ret_from_fork+0x14/0x2c
   INITIAL USE at:
                   [<8005f030>] mark_lock+0x140/0x6ac
                   [<8005ff0c>] __lock_acquire+0x2dc/0x1cbc
                   [<800620d0>] lock_acquire+0x70/0x84
                   [<8061d40c>] _raw_spin_lock_irqsave+0x40/0x54
                   [<804611f4>] sdhci_do_set_ios+0x20/0x720
                   [<80461924>] sdhci_set_ios+0x30/0x3c
                   [<8044cea0>] mmc_power_up+0x6c/0xd0
                   [<8044dac4>] mmc_start_host+0x60/0x70
                   [<8044eb3c>] mmc_add_host+0x60/0x88
                   [<8046225c>] sdhci_add_host+0x7f8/0xbcc
                   [<80464948>] sdhci_esdhc_imx_probe+0x378/0x67c
                   [<8032ee88>] platform_drv_probe+0x20/0x50
                   [<8032d48c>] driver_probe_device+0x118/0x234
                   [<8032d690>] __driver_attach+0x9c/0xa0
                   [<8032b89c>] bus_for_each_dev+0x68/0x9c
                   [<8032cf44>] driver_attach+0x20/0x28
                   [<8032cbc8>] bus_add_driver+0x148/0x1f4
                   [<8032dce0>] driver_register+0x80/0x100
                   [<8032ee54>] __platform_driver_register+0x50/0x64
                   [<8084b094>] sdhci_esdhc_imx_driver_init+0x18/0x20
                   [<80008980>] do_one_initcall+0x108/0x16c
                   [<8081cca4>] kernel_init_freeable+0x10c/0x1d0
                   [<80611c50>] kernel_init+0x10/0x120
                   [<8000e9c8>] ret_from_fork+0x14/0x2c
 }
 ... key      at: [<80e040e8>] __key.26952+0x0/0x8
 ... acquired at:
   [<8005eb60>] check_usage+0x3d0/0x5c0
   [<8005edac>] check_irq_usage+0x5c/0xb8
   [<80060d38>] __lock_acquire+0x1108/0x1cbc
   [<800620d0>] lock_acquire+0x70/0x84
   [<8061a210>] mutex_lock_nested+0x54/0x3c0
   [<80480b08>] clk_prepare_lock+0x44/0xe4
   [<8048188c>] clk_get_rate+0x14/0x64
   [<8046374c>] esdhc_pltfm_set_clock+0x20/0x2a4
   [<8045d70c>] sdhci_set_clock+0x4c/0x498
   [<80461518>] sdhci_do_set_ios+0x344/0x720
   [<80461924>] sdhci_set_ios+0x30/0x3c
   [<8044c390>] __mmc_set_clock+0x44/0x60
   [<8044cd4c>] mmc_set_clock+0x10/0x14
   [<8044f8f4>] mmc_init_card+0x1b4/0x1520
   [<80450f00>] mmc_attach_mmc+0xb4/0x194
   [<8044da08>] mmc_rescan+0x294/0x2f0
   [<8003db94>] process_one_work+0x1a4/0x468
   [<8003e850>] worker_thread+0x118/0x3e0
   [<80044de0>] kthread+0xd4/0xf0
   [<8000e9c8>] ret_from_fork+0x14/0x2c

the dependencies between the lock to be acquired and HARDIRQ-irq-unsafe lock:
-> (prepare_lock){+.+...} ops: 395 {
   HARDIRQ-ON-W at:
                    [<8005f030>] mark_lock+0x140/0x6ac
                    [<8005f604>] mark_held_locks+0x68/0x12c
                    [<8005f780>] trace_hardirqs_on_caller+0xb8/0x1d8
                    [<8005f8b4>] trace_hardirqs_on+0x14/0x18
                    [<8061a130>] mutex_trylock+0x180/0x20c
                    [<80480ad8>] clk_prepare_lock+0x14/0xe4
                    [<804816a4>] clk_notifier_register+0x28/0xf0
                    [<80015120>] twd_clk_init+0x50/0x68
                    [<80008980>] do_one_initcall+0x108/0x16c
                    [<8081cca4>] kernel_init_freeable+0x10c/0x1d0
                    [<80611c50>] kernel_init+0x10/0x120
                    [<8000e9c8>] ret_from_fork+0x14/0x2c
   SOFTIRQ-ON-W at:
                    [<8005f030>] mark_lock+0x140/0x6ac
                    [<8005f604>] mark_held_locks+0x68/0x12c
                    [<8005f7c8>] trace_hardirqs_on_caller+0x100/0x1d8
                    [<8005f8b4>] trace_hardirqs_on+0x14/0x18
                    [<8061a130>] mutex_trylock+0x180/0x20c
                    [<80480ad8>] clk_prepare_lock+0x14/0xe4
                    [<804816a4>] clk_notifier_register+0x28/0xf0
                    [<80015120>] twd_clk_init+0x50/0x68
                    [<80008980>] do_one_initcall+0x108/0x16c
                    [<8081cca4>] kernel_init_freeable+0x10c/0x1d0
                    [<80611c50>] kernel_init+0x10/0x120
                    [<8000e9c8>] ret_from_fork+0x14/0x2c
   INITIAL USE at:
                   [<8005f030>] mark_lock+0x140/0x6ac
                   [<8005ff0c>] __lock_acquire+0x2dc/0x1cbc
                   [<800620d0>] lock_acquire+0x70/0x84
                   [<8061a0c8>] mutex_trylock+0x118/0x20c
                   [<80480ad8>] clk_prepare_lock+0x14/0xe4
                   [<80482af8>] __clk_init+0x1c/0x45c
                   [<8048306c>] _clk_register+0xd0/0x170
                   [<80483148>] clk_register+0x3c/0x7c
                   [<80483b4c>] clk_register_fixed_rate+0x88/0xd8
                   [<80483c04>] of_fixed_clk_setup+0x68/0x94
                   [<8084c6fc>] of_clk_init+0x44/0x68
                   [<808202b0>] time_init+0x2c/0x38
                   [<8081ca14>] start_kernel+0x1e4/0x368
                   [<10008074>] 0x10008074
 }
 ... key      at: [<808afebc>] prepare_lock+0x38/0x48
 ... acquired at:
   [<8005eb94>] check_usage+0x404/0x5c0
   [<8005edac>] check_irq_usage+0x5c/0xb8
   [<80060d38>] __lock_acquire+0x1108/0x1cbc
   [<800620d0>] lock_acquire+0x70/0x84
   [<8061a210>] mutex_lock_nested+0x54/0x3c0
   [<80480b08>] clk_prepare_lock+0x44/0xe4
   [<8048188c>] clk_get_rate+0x14/0x64
   [<8046374c>] esdhc_pltfm_set_clock+0x20/0x2a4
   [<8045d70c>] sdhci_set_clock+0x4c/0x498
   [<80461518>] sdhci_do_set_ios+0x344/0x720
   [<80461924>] sdhci_set_ios+0x30/0x3c
   [<8044c390>] __mmc_set_clock+0x44/0x60
   [<8044cd4c>] mmc_set_clock+0x10/0x14
   [<8044f8f4>] mmc_init_card+0x1b4/0x1520
   [<80450f00>] mmc_attach_mmc+0xb4/0x194
   [<8044da08>] mmc_rescan+0x294/0x2f0
   [<8003db94>] process_one_work+0x1a4/0x468
   [<8003e850>] worker_thread+0x118/0x3e0
   [<80044de0>] kthread+0xd4/0xf0
   [<8000e9c8>] ret_from_fork+0x14/0x2c

stack backtrace:
CPU: 2 PID: 29 Comm: kworker/u8:1 Not tainted 3.13.0-rc1+ #285
Workqueue: kmmcd mmc_rescan
Backtrace:
[<80012160>] (dump_backtrace+0x0/0x10c) from [<80012438>] (show_stack+0x18/0x1c)
 r6:00000000 r5:00000000 r4:8088ecc8 r3:bfa11200
[<80012420>] (show_stack+0x0/0x1c) from [<80616b14>] (dump_stack+0x84/0x9c)
[<80616a90>] (dump_stack+0x0/0x9c) from [<8005ebb4>] (check_usage+0x424/0x5c0)
 r5:80979940 r4:bfa29b44
[<8005e790>] (check_usage+0x0/0x5c0) from [<8005edac>] (check_irq_usage+0x5c/0xb8)
[<8005ed50>] (check_irq_usage+0x0/0xb8) from [<80060d38>] (__lock_acquire+0x1108/0x1cbc)
 r8:bfa115e8 r7:80df9884 r6:80dafa9c r5:00000003 r4:bfa115d0
[<8005fc30>] (__lock_acquire+0x0/0x1cbc) from [<800620d0>] (lock_acquire+0x70/0x84)
[<80062060>] (lock_acquire+0x0/0x84) from [<8061a210>] (mutex_lock_nested+0x54/0x3c0)
 r7:bfa11200 r6:80dafa9c r5:00000000 r4:80480b08
[<8061a1bc>] (mutex_lock_nested+0x0/0x3c0) from [<80480b08>] (clk_prepare_lock+0x44/0xe4)
[<80480ac4>] (clk_prepare_lock+0x0/0xe4) from [<8048188c>] (clk_get_rate+0x14/0x64)
 r6:03197500 r5:bf0e9aa8 r4:bf827400 r3:808ae128
[<80481878>] (clk_get_rate+0x0/0x64) from [<8046374c>] (esdhc_pltfm_set_clock+0x20/0x2a4)
 r5:bf0e9aa8 r4:bf0e9c40
[<8046372c>] (esdhc_pltfm_set_clock+0x0/0x2a4) from [<8045d70c>] (sdhci_set_clock+0x4c/0x498)
[<8045d6c0>] (sdhci_set_clock+0x0/0x498) from [<80461518>] (sdhci_do_set_ios+0x344/0x720)
 r8:0000003b r7:20000113 r6:bf0e9d68 r5:bf0e9aa8 r4:bf0e9c40
r3:00000000
[<804611d4>] (sdhci_do_set_ios+0x0/0x720) from [<80461924>] (sdhci_set_ios+0x30/0x3c)
 r9:00000004 r8:bf131000 r7:bf131048 r6:00000000 r5:bf0e9aa8
r4:bf0e9800
[<804618f4>] (sdhci_set_ios+0x0/0x3c) from [<8044c390>] (__mmc_set_clock+0x44/0x60)
 r5:03197500 r4:bf0e9800
[<8044c34c>] (__mmc_set_clock+0x0/0x60) from [<8044cd4c>] (mmc_set_clock+0x10/0x14)
 r5:00000000 r4:bf0e9800
[<8044cd3c>] (mmc_set_clock+0x0/0x14) from [<8044f8f4>] (mmc_init_card+0x1b4/0x1520)
[<8044f740>] (mmc_init_card+0x0/0x1520) from [<80450f00>] (mmc_attach_mmc+0xb4/0x194)
[<80450e4c>] (mmc_attach_mmc+0x0/0x194) from [<8044da08>] (mmc_rescan+0x294/0x2f0)
 r5:8065f358 r4:bf0e9af8
[<8044d774>] (mmc_rescan+0x0/0x2f0) from [<8003db94>] (process_one_work+0x1a4/0x468)
 r8:00000000 r7:bfa29eb0 r6:bf80dc00 r5:bf0e9af8 r4:bf9e3f00
r3:8044d774
[<8003d9f0>] (process_one_work+0x0/0x468) from [<8003e850>] (worker_thread+0x118/0x3e0)
[<8003e738>] (worker_thread+0x0/0x3e0) from [<80044de0>] (kthread+0xd4/0xf0)
[<80044d0c>] (kthread+0x0/0xf0) from [<8000e9c8>] (ret_from_fork+0x14/0x2c)
 r7:00000000 r6:00000000 r5:80044d0c r4:bf9e7f00

Fixes: 0ddf03c mmc: esdhc-imx: parse max-frequency from devicetree
Signed-off-by: Dong Aisheng <b29396@freescale.com>
Acked-by: Shawn Guo <shawn.guo@linaro.org>
Tested-by: Philippe De Muyter <phdm@macqel.be>
Cc: stable <stable@vger.kernel.org> # 3.13
Signed-off-by: Chris Ball <chris@printf.net>
2014-01-13 14:02:38 -05:00
Fabio Estevam
a50145f925 mmc: sdhci-esdhc-imx: Use NULL instead of zero
Fix the following sparse warning:

drivers/mmc/host/sdhci-esdhc-imx.c:617:35: warning: Using plain integer as NULL pointer

Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Cc: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
2014-01-13 12:48:14 -05:00
Dong Aisheng
89d7e5c131 mmc: sdhci-esdhc-imx: add runtime pm support
The root clock will be disabled in runtime pm to save power.

Signed-off-by: Dong Aisheng <b29396@freescale.com>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
2014-01-13 12:48:09 -05:00
Dong Aisheng
ce090a4eb9 mmc: sdhci-esdhc-imx: fix runtime pm unbalance issue
Since we're using common esdhc_send_command for tuning commands and
the core code will call pm_runtime_put after command is finished.
So we add a pm_runtime_get_sync here to get the balance.

Signed-off-by: Dong Aisheng <b29396@freescale.com>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
2014-01-13 12:48:09 -05:00
Dong Aisheng
8b2bb0adce mmc: esdhc-imx: clearing SDHCI_CTRL_EXEC_TUNING should not affect other bits
Current code will clear all turning related bits like ESDHC_STD_TUNING_EN
and ESDHC_MIX_CTRL_FBCLK_SEL when clear SDHCI_CTRL_EXEC_TUNING.
This may cause the card which has already passed the turning to become
unwork since the turning status lost.
We observed this failure when enable runtime pm.

BTW, imx needs to enable ESDHC_MIX_CTRL_FBCLK_SEL bit for turned clock.
The FBCLK_SEL will be cleared when SDHCI_CTRL_TUNED_CLK is cleared
and SDHCI_CTRL_EXEC_TUNING is not set.
This is used in case we change to another normal card from a UHS card
in the same slot. FBCLK_SEL is not needed for normal card.

After that, SDHCI_CTRL_EXEC_TUNING will only affect ESDHC_MIX_CTRL_EXE_TUNE.
Clearing it does not affect the turned card to remain working on UHS mode.

Signed-off-by: Dong Aisheng <b29396@freescale.com>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
2014-01-13 12:48:08 -05:00
Dong Aisheng
d131a71c95 mmc: sdhci-esdhc-imx: tuning bits should not be cleared during reset
We should not clear tuning bits during reset or the SD3.0/eMMC4.5 card
working on UHS mode may not work after reset since the former tuning
settings was lost.

Signed-off-by: Dong Aisheng <b29396@freescale.com>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
2014-01-13 12:48:07 -05:00
Dong Aisheng
429a5b45fe mmc: sdhci-esdhc-imx: add eMMC HS200 mode support
Add support for eMMC 4.5 cards to work on hs200 mode.

Signed-off-by: Dong Aisheng <b29396@freescale.com>
Acked-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
2014-01-13 12:48:06 -05:00