This reverts commit e060d376cc61 ("mmc: renesas_sdhi: fix WP detection")
and adds some code to really fix the regressions.
It was missed so far that Renesas R-Car instantiations of SDHI chose to
disable internal WP and used the existence of "wp-gpios" to en/disable
WP at all.
With the first refactoring by Yamada-san with commit 2ad1db059b9a ("mmc:
renesas_sdhi: use MMC_CAP2_NO_WRITE_PROTECT instead of TMIO own flag"),
WP was always disabled even when GPIOs were present. With Wolfram's
first fix which gets now reverted, GPIOs were honored. But when not
available, the fallback was to internal WP and not to disabled WP. This
caused wrong WP status on uSD card slots.
Restore the old behaviour now. By default, WP is disabled. When a GPIO
is found, the GPIO re-enables WP. We will think about possible better
ways to handle this in the future.
Tested on a previously regressing Renesas Lager board (H2) and a still
working Renesas Salvator-X board (M3-W).
Ulf Hansson [Thu, 31 May 2018 10:16:04 +0000 (12:16 +0200)]
mmc: mvsdio: Respect card busy time out from mmc core
Instead of using a hardcoded timeout of 5 * HZ jiffies, let's respect the
command busy timeout provided by the mmc core. This make the used timeout
more reliable.
Georgi Djakov [Wed, 30 May 2018 14:43:35 +0000 (17:43 +0300)]
mmc: sdhci-msm: Remove NO_CARD_NO_RESET quirk
Now we have a proper implementation for the power irq handling and this
quirk is not needed anymore. In fact, it is causing card detection delays
on apq8096 platforms and the following error is displayed:
sdhci_msm 74a4900.sdhci: mmc0: pwr_irq for req: (4) timed out
The quirk is forcing the controller to retain 1.8V signalling on the slot
even when a new card is inserted, which is not correct. The proper behavior
would be to reset the controller in order to start with 3.3V signaling.
Fixes: c0309b3803fe ("mmc: sdhci-msm: Add sdhci msm register write APIs which wait for pwr irq") Suggested-by: Vijay Viswanath <vviswana@codeaurora.org> Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Arnd Bergmann [Tue, 29 May 2018 10:30:35 +0000 (12:30 +0200)]
mmc: mxmmc: include linux/highmem.h
The highmem conversion caused a build error in some configurations:
drivers/mmc/host/mxcmmc.c: In function 'mxcmci_transfer_data':
drivers/mmc/host/mxcmmc.c:622:10: error: implicit declaration of function 'kmap_atomic'; did you mean 'in_atomic'? [-Werror=implicit-function-declaration]
Arnd Bergmann [Fri, 25 May 2018 21:07:42 +0000 (23:07 +0200)]
mmc: sunxi: mark PM functions as __maybe_unused
The newly added runtime-pm functions cause a harmless warning
when CONFIG_PM is disabled:
drivers/mmc/host/sunxi-mmc.c:1452:12: error: 'sunxi_mmc_runtime_suspend' defined but not used [-Werror=unused-function]
static int sunxi_mmc_runtime_suspend(struct device *dev)
^~~~~~~~~~~~~~~~~~~~~~~~~
drivers/mmc/host/sunxi-mmc.c:1435:12: error: 'sunxi_mmc_runtime_resume' defined but not used [-Werror=unused-function]
static int sunxi_mmc_runtime_resume(struct device *dev)
This marks them as __maybe_unused to shut up the warning.
Martin Hicks [Mon, 28 May 2018 11:23:04 +0000 (13:23 +0200)]
mmc: Throttle calls to MMC_SEND_STATUS during mmc_do_erase()
This drastically reduces the rate at which the MMC_SEND_STATUS cmd polls
for completion of the MMC Erase operation. The patch does this by adding
a backoff sleep that starts by sleeping for short intervals (128-256us),
and ramps up to sleeping for 32-64ms.
Even on very quickly completing erase operations, the loop iterates a few
times, so not too much extra latency is added to these commands.
For long running discard operarations, like a full-device secure discard,
this change drops the interrupt rates on my single-core NXP I.MX6UL from
45000/s to about 20/s, and greatly improves system responsiveness.
Signed-off-by: Martin Hicks <mort@bork.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Evan Green [Fri, 25 May 2018 19:25:23 +0000 (12:25 -0700)]
mmc: Allow non-sleeping GPIO cd
This change uses the appropriate _cansleep or non-sleeping API for
reading GPIO card detect state. This allows users with GPIOs that
never sleep to avoid a warning when certain quirks are present.
The sdhci controller has an SDHCI_QUIRK_NO_CARD_NO_RESET, which
indicates that a controller will not reset properly if no card is
inserted. With this quirk enabled, mmc_get_cd_gpio is called in
several places with a spinlock held and interrupts disabled.
gpiod_get_raw_value_cansleep is not happy with this situation,
and throws out a warning.
For boards that a) use controllers that have this quirk, and b) wire
card detect up to a GPIO that doesn't sleep, this is a spurious warning.
This change silences that warning, at the cost of pushing this problem
down to users that have sleeping GPIOs and controllers with this quirk.
Signed-off-by: Evan Green <evgreen@chromium.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Ulf Hansson [Tue, 22 May 2018 14:26:26 +0000 (16:26 +0200)]
mmc: core: Move calls to ->prepare_hs400_tuning() closer to mmc code
Move the calls to ->prepare_hs400_tuning(), from mmc_retune() into
mmc_hs400_to_hs200(), as it better belongs there, rather than being generic
to all type of cards.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
Shawn Lin [Thu, 17 May 2018 07:47:42 +0000 (15:47 +0800)]
mmc: block: Don't switch to the same partition type in mmc_blk_remove()
It's pointless to switch and trace partition type if the current
selected device partition is the same with that one. Moreover, cycled
claiming host associated with mmc_blk_part_switch() could make
mmc_blk_remove() end up waiting for grabbing the context if it's
occupied, which lead requests could still hit the low-level drivers,
if an asynchronous unbind for host drivers happened, as the card hasn't
been set removed in the remove path.
So a simple dd in background:
dd if=/dev/mmcblk0 of=/dev/null bs=512k count=100000 &
and doing unbind then:
echo fe320000.dwmmc > /sys/bus/platform/drivers/dwmmc_rockchip/unbind
could make the console stuck for quite a while depending on the
numbers of requests.
Suggested-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Corneliu Doban [Fri, 18 May 2018 22:03:57 +0000 (15:03 -0700)]
mmc: sdhci-iproc: add SDHCI_QUIRK2_HOST_OFF_CARD_ON for cygnus
The SDHCI_QUIRK2_HOST_OFF_CARD_ON is needed for the driver to
properly reset the host controller (reset all) on initialization
after exiting deep sleep.
Signed-off-by: Corneliu Doban <corneliu.doban@broadcom.com> Signed-off-by: Scott Branden <scott.branden@broadcom.com> Reviewed-by: Ray Jui <ray.jui@broadcom.com> Reviewed-by: Srinath Mannam <srinath.mannam@broadcom.com> Fixes: c833e92bbb60 ("mmc: sdhci-iproc: support standard byte register accesses") Cc: stable@vger.kernel.org # v4.10+ Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Corneliu Doban [Fri, 18 May 2018 22:03:56 +0000 (15:03 -0700)]
mmc: sdhci-iproc: fix 32bit writes for TRANSFER_MODE register
When the host controller accepts only 32bit writes, the value of the
16bit TRANSFER_MODE register, that has the same 32bit address as the
16bit COMMAND register, needs to be saved and it will be written
in a 32bit write together with the command as this will trigger the
host to send the command on the SD interface.
When sending the tuning command, TRANSFER_MODE is written and then
sdhci_set_transfer_mode reads it back to clear AUTO_CMD12 bit and
write it again resulting in wrong value to be written because the
initial write value was saved in a shadow and the read-back returned
a wrong value, from the register.
Fix sdhci_iproc_readw to return the saved value of TRANSFER_MODE
when a saved value exist.
Same fix for read of BLOCK_SIZE and BLOCK_COUNT registers, that are
saved for a different reason, although a scenario that will cause the
mentioned problem on this registers is not probable.
Srinath Mannam [Fri, 18 May 2018 22:03:55 +0000 (15:03 -0700)]
mmc: sdhci-iproc: remove hard coded mmc cap 1.8v
Remove hard coded mmc cap 1.8v from platform data as it is board specific.
The 1.8v DDR mmc caps can be enabled using DTS property for those
boards that support it.
Fixes: b17b4ab8ce38 ("mmc: sdhci-iproc: define MMC caps in platform data") Signed-off-by: Srinath Mannam <srinath.mannam@broadcom.com> Signed-off-by: Scott Branden <scott.branden@broadcom.com> Reviewed-by: Ray Jui <ray.jui@broadcom.com> Cc: stable@vger.kernel.org # v4.8+ Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Mathieu Malaterre [Wed, 16 May 2018 19:20:20 +0000 (21:20 +0200)]
mmc: block: propagate correct returned value in mmc_rpmb_ioctl
In commit 97548575bef3 ("mmc: block: Convert RPMB to a character device") a
new function `mmc_rpmb_ioctl` was added. The final return is simply
returning a value of `0` instead of propagating the correct return code.
Discovered during a compilation with W=1, silence the following gcc warning
drivers/mmc/core/block.c:2470:6: warning: variable ‘ret’ set but not used
[-Wunused-but-set-variable]
Signed-off-by: Mathieu Malaterre <malat@debian.org> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> Fixes: 97548575bef3 ("mmc: block: Convert RPMB to a character device") Cc: stable@vger.kernel.org # v4.15+ Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Jerome Brunet [Tue, 15 May 2018 09:57:48 +0000 (11:57 +0200)]
mmc: meson-gx: add device reset
Trigger the reset line of the mmc controller while probing, if available.
The reset should be optional for now, at least until all related DT nodes
have the reset property.
Shawn Lin [Tue, 8 May 2018 01:04:20 +0000 (09:04 +0800)]
mmc: core: add tunable delay waiting for power to be stable
The hard-coded 10ms delay in mmc_power_up came from
commit 79bccc5aefb4 ("mmc: increase power up delay"), which said "The TI
controller on Toshiba Tecra M5 needs more time to power up or the cards
will init incorrectly or not at all." But it's too engineering solution
for a special board but force all platforms to wait for that long time,
especially painful for mmc_power_up for eMMC when booting.
However, it's added since 2009, and we can't tell if other platforms
benefit from it. But in practise, the modern hardware are most likely to
have a stable power supply with 1ms after setting it for no matter PMIC
or discrete power. And more importnatly, most regulators implement the
callback of ->set_voltage_time_sel() for regulator core to wait for
specific period of time for the power supply to be stable, which means
once regulator_set_voltage_* return, the power should reach the the
minimum voltage that works for initialization. Of course, if there
are some other ways for host to power the card, we should allow them
to argue a suitable delay as well.
With this patch, we could assign the delay from firmware, or we could
assigne it via ->set_ios() callback from host drivers.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Shawn Lin [Tue, 8 May 2018 01:04:19 +0000 (09:04 +0800)]
Documentation: mmc: addtional description for post-power-on-delay-ms
post-power-on-delay-ms woule be reused to substitute the hard-coded 10ms
delay waiting for power supply to be stable, specificed by individual
platform/board. Default to 10ms as before, if no available.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Aapo Vienamo [Fri, 4 May 2018 09:20:53 +0000 (12:20 +0300)]
mmc: tegra: remove redundant return statement
A redundant return statement is removed from
tegra_sdhci_set_uhs_signaling(). The function returns void and the
return does not affect the control flow of the function.
Let's implement the ->sw_reset() bus ops to allow SDIO func drivers, in
particular, to make a SW reset without doing a full power cycle of the SDIO
card.
mmc: core: Export a function mmc_sw_reset() to allow soft reset of cards
It's rather common that a firmware is loaded into an SDIO func device
memory, by the corresponding SDIO func driver during ->probe() time.
However, to actually start running the new firmware, sometimes a soft reset
(no power cycle) and a re-initialization of the card is needed. This is for
example the case with the Espressif ESP8089 WiFi chips, when connected to
an SDIO interface.
To cope with this scenario, let's add a new exported function,
mmc_sw_reset(), which may be called when a soft reset and re-initialization
of the card are needed.
The mmc_sw_reset() is implemented on top of a new bus ops callback, similar
to how the mmc_hw_reset() has been implemented.
mmc: core: Rename ->reset() bus ops to ->hw_reset()
The bus ops ->reset() executes a full HW reset of the card, as the calling
function mmc_hw_reset() also indicates by its name. Let's convert to follow
the similar names, for both the bus ops callback and for the corresponding
bus ops functions, as to clarify the purpose of code.
Ulf Hansson [Mon, 11 May 2015 14:46:47 +0000 (16:46 +0200)]
mmc: core: Re-factor some code for SDIO re-initialization
The mmc_sdio_init_card() function has a couple of callers. In the
re-initialization cases, some additional reset commands are issued before
mmc_sdio_init_card() is called. As these additional reset commands are the
same, let's move these into a new static function, mmc_sdio_reinit_card()
and call mmc_sdio_init_card() from there. In this way we avoid the open
coding.
Shawn Lin [Tue, 24 Apr 2018 00:42:57 +0000 (08:42 +0800)]
mmc: core: Add tunable delay before detecting card after card is inserted
Allow to use tunable delay before detecting card after card is inserted,
which either comes from firmware node, or comes from debounce value
passed on to mmc_gpiod_request_cd(). If the platform doesn't support
debounce, then we fall back to use the debounce period as the delay,
otherwise, it behaves the same as before that a HW debounce(if set) plus
a 200ms hardcode delay before detecting the card.
cd-gpios uses a fixed delay, 200ms, before detecting card after the card
is inserted. 200ms doesn't work for some platforms, so some host drivers
added their own properties for parsing that from DT, for instance,
dw_mmc and pxamci. That being said, it should also be tunable when using
cd-gpios.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Kishon Vijay Abraham I [Fri, 27 Apr 2018 11:47:23 +0000 (17:17 +0530)]
mmc: sdhci-omap: Get IODelay values for 3.3v DDR mode
commit 8d20b2eae6c47b095523 ("mmc: sdhci_omap: Add support to set
IODELAY values") stored IODelay values for all MM/SD modes
in pinctrl_state structure member of sdhci_omap_host. However for
DDR mode it gets IODelay values only for 1.8v DDR mode. Since some of
the platforms which uses sdhci-omap has IO lines connected to 3.3v,
get IODelay values for 3.3v DDR mode.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Kishon Vijay Abraham I [Fri, 27 Apr 2018 11:47:21 +0000 (17:17 +0530)]
mmc: sdhci-omap: Add sdhci_omap specific ops for enable_sdio_irq
Add sdhci_omap_enable_sdio_irq to set CTPL and CLKEXTFREE bits in
MMCHS_CON register required to detect asynchronous card interrupt
on DAT[1].
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Kishon Vijay Abraham I [Fri, 27 Apr 2018 11:47:20 +0000 (17:17 +0530)]
mmc: sdhci-omap: Add support for MMC/SD controller in k2g SoC
Add support for the new compatible added specifically to support
k2g's MMC/SD controller.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Kishon Vijay Abraham I [Fri, 27 Apr 2018 11:47:19 +0000 (17:17 +0530)]
dt-bindings: sdhci-omap: Add K2G specific binding
Add binding for the TI's sdhci-omap controller present in K2G.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Reviewed-by: Rob Herring <robh@kernel.org> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Kishon Vijay Abraham I [Fri, 27 Apr 2018 11:47:18 +0000 (17:17 +0530)]
mmc: sdhci-omap: Workaround for Errata i834
Errata i834 in AM572x Sitara Processors Silicon Revision 2.0, 1.1
(SPRZ429K July 2014–Revised March 2017 [1]) mentions the maximum
obtainable timeout through MMC host controller is 700ms. And for
commands taking longer than 700ms, hardware timeout should be
disabled and software timeout should be used.
The workaround for Errata i834 can be achieved by adding
SDHCI_QUIRK2_DISABLE_HW_TIMEOUT quirk in sdhci-omap.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Kishon Vijay Abraham I [Fri, 27 Apr 2018 11:47:17 +0000 (17:17 +0530)]
mmc: sdhci: Program a relatively accurate SW timeout value
sdhci has a 10 second timeout to catch devices that stop responding.
In the case of quirk SDHCI_QUIRK2_DISABLE_HW_TIMEOUT, instead of
programming 10 second arbitrary value, calculate the total time it would
take for the entire transfer to happen and program the timeout value
accordingly.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Adrian Hunter [Fri, 27 Apr 2018 11:47:16 +0000 (17:17 +0530)]
mmc: sdhci: Factor out target_timeout calculation
Factor out the target_timeout calculation so it can be re-used.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Adrian Hunter [Fri, 27 Apr 2018 11:47:15 +0000 (17:17 +0530)]
mmc: sdhci: Add quirk to disable HW timeout
Add quirk to disable HW timeout if the requested timeout is more than the
maximum obtainable timeout.
Also, if the quirk is set and ->get_max_timeout_count() is not implemented,
max_busy_timeout is set to zero.
Based-on-patch-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Kishon Vijay Abraham I [Fri, 27 Apr 2018 11:47:14 +0000 (17:17 +0530)]
mmc: sdhci: Disable 1.8v modes (HS200/HS400/UHS) if controller can't support 1.8v
The SDHCI controller in a SoC might support HS200/HS400 (indicated
using mmc-hs200-1_8v/mmc-hs400-1_8v dt property), but if the board is
modeled such that the IO lines are not connected to 1.8v then
HS200/HS400 cannot be supported. Disable HS200/HS400 if the board
does not have 1.8v connected to the IO lines. Also Disable DDR/UHS in 1.8v
if the IO lines are not connected to 1.8v.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Kishon Vijay Abraham I [Fri, 27 Apr 2018 11:47:13 +0000 (17:17 +0530)]
mmc: sdhci-omap: Invoke sdhci_get_of_property to read sdhci dt properties
Invoke sdhci_get_of_property defined in sdhci-pltfm.c to read
sdhci specific properties from dt node.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Kishon Vijay Abraham I [Fri, 27 Apr 2018 11:47:12 +0000 (17:17 +0530)]
mmc: sdhci-omap: Workaround for Errata i843
Errata i843 in AM572x Sitara Processors Silicon Revision 2.0, 1.1
(SPRZ429K July 2014–Revised March 2017 [1]) mentions
PG 1.0/1.1 silicon has limitations w.r.t frequencies at which MMC1/2/3
can operate.
Use soc_device_match() to identify rev 1.0/1.1 silicon and
override mmc->f_max according to the errata workaround.
"max-frequency" dt property cannot be used since the device
tree is added for rev 2.0 silicon.
soc_device_match() is also used in order to get the IODelay values
for rev 1.0/1.1 silicon.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Kishon Vijay Abraham I [Fri, 27 Apr 2018 11:47:11 +0000 (17:17 +0530)]
mmc: sdhci-omap: Remove setting ADMA capability in driver
sdhci can directly get ADMA capability from MMCHS_CAPA register.
Remove explicitly setting ADMA here as some instances might not have
ADMA enabled. (sdhci_read_caps() is also removed from here since
sdhci_setup_host() invokes it).
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Acked-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Kishon Vijay Abraham I [Fri, 27 Apr 2018 11:47:10 +0000 (17:17 +0530)]
mmc: sdhci-omap: Fix when capabilities are obtained from SDHCI_CAPABILITIES reg
sdhci_omap_config_iodelay_pinctrl_state() requires caps and caps2 to be
initialized (speed mode capabilities like UHS/HS200) before it is
invoked. While mmc_of_parse() initializes caps/caps2 if capabilities is
populated in device tree, it will remain uninitialized for capabilities
obtained from SDHCI_CAPABILITIES register.
Fix sdhci_omap_config_iodelay_pinctrl_state() to be used even while
getting the capabilities from SDHCI_CAPABILITIES register by invoking
sdhci_setup_host() before sdhci_omap_config_iodelay_pinctrl_state().
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Acked-by: Tony Lindgren <tony@atomide.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Thomas Gleixner [Tue, 24 Apr 2018 16:40:49 +0000 (18:40 +0200)]
mmc: mmci: Remove bogus local_irq_save()
On !RT interrupt runs with interrupts disabled. On RT it's in a
thread, so no need to disable interrupts at all.
Remove the local_irq_save() invocation.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Andrew Gabbasov [Tue, 17 Apr 2018 13:15:12 +0000 (18:45 +0530)]
mmc: sdhci-esdhc-imx: Set maximum watermark levels for PIO access
While performing R/W access in PIO mode, the common SDHCI driver checks
the buffer ready status once per whole block processing. That is, after
getting an appropriate interrupt, or checking an appropriate status bit,
the driver makes buffer accesses for the whole block size (e.g. 128 reads
for 512 bytes block). This is done in accordance with SD Host Controller
Specification.
At the same time, the Ultra Secured Digital Host Controller (uSDHC), used
in i.MX6 (and, probably, earlier i.MX series too), uses a separate
Watermark Levels register, controlling the amount of data or space
available when raising status bit or interrupt. For default watermark
setting of 16 words, the controller expects (and guarantees) no more
than 16 buffer accesses after raising buffer ready status bit and
generating an appropriate interrupt. If the driver tries to access the
whole block size, it will get incorrect data at the end, and a new
interrupt will appear later, when the driver already doesn't expect it.
This happens sometimes, more likely on low frequencies, e.g. when
reading EXT_CSD at MMC card initialization phase
(which makes that initialization fail).
Such behavior of i.MX uSDHC seems to be non-compliant
to SDHCI Specification, but this is the way it works now.
In order not to rewrite the SDHCI driver PIO mode access logic,
the IMX specific driver can just set the watermark level to default
block size (128 words or 512 bytes), so that the controller behavior
will be consistent to generic specification. This patch does this
for PIO mode accesses only, restoring default values for DMA accesses
to avoid any possible side effects from performance point of view.
Signed-off-by: Andrew Gabbasov <andrew_gabbasov@mentor.com> Signed-off-by: Harish Jenny K N <harish_kandiga@mentor.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The PADs for SD card are dual-voltage that support 3v/1.8v. Those PADs
have a control signal (io_pad_pwr_switch/mode18 ) that indicates
whether the PAD works in 3v or 1.8v.
SDHC core on msm platforms should have IO_PAD_PWR_SWITCH bit set/unset
based on actual voltage used for IO lines. So when power irq is
triggered for io high or io low, the driver should check the voltages
supported and set the pad accordingly.
mmc: sdhci-msm: Add support to store supported vdd-io voltages
During probe check whether the vdd-io regulator of sdhc platform device
can support 1.8V and 3V and store this information as a capability of
platform device.
Signed-off-by: Vijay Viswanath <vviswana@codeaurora.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Gustavo A. R. Silva [Thu, 19 Apr 2018 15:59:58 +0000 (10:59 -0500)]
mmc: sdhci-cadence: fix logically and structurally dead code
Currently, the code block inside the for loop will never execute more than
once, because the function returns immediately after the first iteration,
hence the execution of the code at the second iteration is structurally
dead and, code at line 281: return 0; is never reached.
Fix this by checking _ret_ before return.
Addresses-Coverity-ID: 1468009 ("Logically dead code")
Addresses-Coverity-ID: 1468002 ("Structurally dead code") Suggested-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Acked-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Sergei Shtylyov [Mon, 16 Apr 2018 18:30:02 +0000 (21:30 +0300)]
mmc: dt: tmio_mmc: document R8A77980 bindings
Document the R-Car V3H (R8A77980) SoC in the Renesas SDHI bindings.
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
Wolfram Sang [Wed, 18 Apr 2018 18:21:00 +0000 (20:21 +0200)]
mmc: renesas_sdhi_internal_dmac: use more generic whitelisting
Whitelisting every ES version does not scale. So, we whitelist whole
SoCs independent of ES version. If we need specific handling for an ES
version, we put it to the front, so it will be matched first.
mmc: renesas_sdhi: Fix alignment check of sg buffer
Sometimes sg->offset is not used for buffer addresses allocated by
dma_map_sg(), so alignment checks should be done on the allocated buffer
addresses. Delete the alignment check for sg->offset that is done before
dma_map_sg(). Instead, it performs the alignment check for
sg->dma_address after dma_map_sg().
Signed-off-by: Masaharu Hayakawa <masaharu.hayakawa.ry@renesas.com>
[Niklas: broke this commit in two and tidied small style issue] Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
[rebased to mmc/next] Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
mmc: renesas_sdhi: use helpers to access struct scatterlist members
Instead of directly accessing the members of struct scatterlist use the
helpers mmc_get_dma_dir() and sg_dma_address() in
renesas_sdhi_internal_dmac_start_dma(). Based on previous work by
Masaharu Hayakawa.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
[rebased to mmc/next] Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
mmc: sdhci-pci: Avoid 3.3V signaling on some NI 904x
On some NI 904x devices, using 3.3V signaling for extended periods of
time will physically damage the pads connected to the SDHC, eventually
causing complete failure of the controller. To work around this,
require that we avoid 3.3V signaling.
Signed-off-by: Kyle Roeschley <kyle.roeschley@ni.com> Signed-off-by: Jennifer Dahm <jennifer.dahm@ni.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Some SD host controllers cannot handle extended use of 3.3V signaling.
To accommodate these controllers, add a capability that requires us to
negotiate the voltage down from 3.3V during card initialization.
mmc: Remove depends on HAS_DMA in case of platform dependency
Remove dependencies on HAS_DMA where a Kconfig symbol depends on another
symbol that implies HAS_DMA, and, optionally, on "|| COMPILE_TEST".
In most cases this other symbol is an architecture or platform specific
symbol, or PCI.
Generic symbols and drivers without platform dependencies keep their
dependencies on HAS_DMA, to prevent compiling subsystems or drivers that
cannot work anyway.
This simplifies the dependencies, and allows to improve compile-testing.
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by: Mark Brown <broonie@kernel.org> Acked-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Maxime Ripard [Mon, 16 Apr 2018 14:23:05 +0000 (16:23 +0200)]
mmc: sunxi: Drop the init / reset of the controller from set_ios
Our set_ios hook is, when the card is power up or down, either doing a full
init or put our controller back into a reset mode.
Since we're also doing that in our runtime_pm hooks, and at possibly much
more often, we can drop it from the set_ios, and either rely on our
runtime_pm hooks or our probe to do it.
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Maxime Ripard [Mon, 16 Apr 2018 14:23:04 +0000 (16:23 +0200)]
mmc: sunxi: Add runtime_pm support
So far, even if our card was not in use, we didn't shut down our MMC
controller, which meant that it was still active and clocking the bus.
While this obviously means that we could save some power there, it also
creates issues when it comes to EMC control since we'll have a perfect peak
at the card clock rate.
Let's implement runtime_pm with autosuspend so that we will shut down the
controller when it's not been in use for quite some time.
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
mmc: core: sdio: Set SDIO clock of SDR104 to 150MHz for Marvell 8887 chip
This patch uses limit clock rate quirk to reduce clock rate
for "SDR104" mode on IMX side for Marvell 8887
WiFi + Bluetooth chip side, as Marvell does not recommend
to use SDIO at the speed of higher than 150MHz.
Signed-off-by: Diwakar Sharma <diwakar.sharma@in.bosch.com> Signed-off-by: Harish Jenny K N <harish_kandiga@mentor.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
mmc: core: Add a new quirk for limiting clock rate
This patch adds a quirk to limit clock rate which
can be used to reduce the SDIO clock rate for some
chips with broken UHS.
Signed-off-by: Harish Jenny K N <harish_kandiga@mentor.com> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Shawn Lin [Thu, 5 Apr 2018 10:31:42 +0000 (18:31 +0800)]
mmc: dw_mmc: fix misleading comment in dw_mci_rk3288_set_ios
DDR52 with 8-bit mode should be handled in a different way when
requesting ciu_clk. However DDR50 is used for SDMMC/SDIO and
could never be possible with 8-bit mode. It's trival but misleading.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Masahiro Yamada [Tue, 27 Mar 2018 09:29:53 +0000 (18:29 +0900)]
mmc: sdhci-cadence: send tune request twice to work around errata
Cadence sent out an errata report to their customers of this IP.
This errata is not so severe, but the tune request should be sent
twice to avoid the potential issue.
Quote from the report:
Problem Summary
---------------
The IP6116 SD/eMMC PHY design has a timing issue on receive data path.
This issue may lead to an incorrect values of read/write pointers of
the synchronization FIFO. Such a situation can happen at the SDR104
and HS200 tuning procedure when the PHY is requested to change a phase
of sampling clock when moving to the next tuning iteration.
Workarounds
-----------
The following are valid workarounds to resolve the issue:
1. In eMMC mode, software sends tune request twice instead of once at
each iteration. This means that the clock phase is not changed on
the second request so there is no potential for clock instability.
2. In SD mode, software must not use the hardware tuning and instead
perform an almost identical procedure to eMMC, using the HRS34 Tune
Force register.
Nan Li [Tue, 3 Apr 2018 10:06:51 +0000 (18:06 +0800)]
mmc: meson: update doc to support Meson-AXG platform
Explicitly update the docomentation to support the Meson-AXG platform.
Signed-off-by: Nan Li <nan.li@amlogic.com> Signed-off-by: Yixun Lan <yixun.lan@amlogic.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Acked-by: Kevin Hilman <khilman@baylibre.com>
Nan Li [Tue, 3 Apr 2018 10:06:50 +0000 (18:06 +0800)]
mmc: meson-axg: add support for the Meson-AXG platform
Introduce the compatible data to cover the register offset & mask
change of the eMMC controller in Amlogic's Meson-AXG SoC.
Signed-off-by: Nan Li <nan.li@amlogic.com> Signed-off-by: Yixun Lan <yixun.lan@amlogic.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Acked-by: Kevin Hilman <khilman@baylibre.com>
Nan Li [Tue, 3 Apr 2018 10:06:49 +0000 (18:06 +0800)]
mmc: dt-bindings: update bindings doc to support Meson-AXG SoC
Update the documentation to list support for Meson-AXG SoC explicitly.
The new binding string is necessary since this SoC introduce a few
IP difference comparing to previous old generation.
Signed-off-by: Nan Li <nan.li@amlogic.com> Signed-off-by: Yixun Lan <yixun.lan@amlogic.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Acked-by: Kevin Hilman <khilman@baylibre.com>
Andrew Gabbasov [Tue, 27 Feb 2018 11:33:49 +0000 (17:03 +0530)]
mmc: card: Don't show eMMC RPMB and BOOT areas in /proc/partitions
Since RPMB area is accessible via special ioctl only and boot areas
are unlikely to contain any partitions, exclude them all from listing
in /proc/partitions. This will hide them from various user-level
software (e.g. fdisk), thus avoiding unnecessary access attempts.
Signed-off-by: Andrew Gabbasov <andrew_gabbasov@mentor.com> Signed-off-by: Harish Jenny K N <harish_kandiga@mentor.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Alex Smith [Wed, 28 Mar 2018 21:00:51 +0000 (18:00 -0300)]
mmc: jz4740: Add support for the JZ4780
Add support for the JZ4780 MMC controller to the jz47xx_mmc driver. There
are a few minor differences from the 4740 to the 4780 that need to be
handled, but otherwise the controllers behave the same. The IREG and IMASK
registers are expanded to 32 bits. Additionally, some error conditions are
now reported in both STATUS and IREG. Writing IREG before reading STATUS
causes the bits in STATUS to be cleared, so STATUS must be read first to
ensure we see and report error conditions correctly.
Signed-off-by: Alex Smith <alex.smith@imgtec.com> Signed-off-by: Paul Cercueil <paul@crapouillou.net> Tested-by: Mathieu Malaterre <malat@debian.org> Signed-off-by: Ezequiel Garcia <ezequiel@collabora.co.uk> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
projects / users / willy / linux.git / log