Shawn Lin [Fri, 11 Mar 2016 16:35:45 +0000 (00:35 +0800)]
mmc: core: remove redundant memset of mmc_decode_cid
When initializing sd or sdio card, we get struct mmc_card
from mmc_alloc_card which allocates it by kzalloc. So we don't
need another memset while decoding cid.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Brian Norris [Mon, 7 Mar 2016 23:36:39 +0000 (15:36 -0800)]
mmc: of_mmc_spi: fix unused warning
drivers/mmc/host/of_mmc_spi.c: In function 'mmc_spi_get_pdata':
drivers/mmc/host/of_mmc_spi.c:77:6: warning: variable 'ret' set but not used [-Wunused-but-set-variable]
int ret = -EINVAL;
^
Signed-off-by: Brian Norris <computersforpeace@gmail.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Shawn Lin [Mon, 7 Mar 2016 15:39:19 +0000 (23:39 +0800)]
mmc: sdhci-of-arasan: add phy support for sdhci-of-arasan
This patch adds Generic PHY access for sdhci-of-arasan. Driver
can get PHY handler from dt-binding, and power-on/init the PHY.
Currently, it's just mandatory for arasan,sdhci-5.1.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Adrian Hunter [Mon, 7 Mar 2016 11:33:55 +0000 (13:33 +0200)]
mmc: sdhci: Fix override of timeout clk wrt max_busy_timeout
Normally the timeout clock frequency is read from the capabilities
register. It is also possible to set the value prior to calling
sdhci_add_host() in which case that value will override the
capabilities register value. However that was being done after
calculating max_busy_timeout so that max_busy_timeout was being
calculated using the wrong value of timeout_clk.
Fix that by moving the override before max_busy_timeout is
calculated.
The result is that the max_busy_timeout and max_discard
increase for BSW devices so that, for example, the time for
mkfs.ext4 on a 64GB eMMC drops from about 1 minute 40 seconds
to about 20 seconds.
Note, in the future, the capabilities setting will be tidied up
and this override won't be used anymore. However this fix is
needed for stable.
Philip Elcan [Thu, 3 Mar 2016 16:38:46 +0000 (11:38 -0500)]
mmc: sdhci-acpi: add QCOM controllers
This adds the HIDs for Qualcomm Technologies Inc SDHC
controllers:
QCOM8051: non-removable device that does not support 1.8v
QCOM8052: non-removable device that does support 1.8v
Signed-off-by: Philip Elcan <pelcan@codeaurora.org> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Lucas Stach [Mon, 29 Feb 2016 20:56:25 +0000 (21:56 +0100)]
mmc: tegra: implement memcomp pad calibration
The Tegra30+ SDMMC module has memcomp pads that are used to
automatically find and set the correct drive strength settings to
the sdmmc pads. The calibration needs to be manually kicked off
when the card signal voltage is changed, after the card clock is
supplied again.
Signed-off-by: Lucas Stach <dev@lynxeye.de> Acked-by: Adrian Hunter <adrian.hunter@intel.com>
[Ulf: Rebased to fix a trivial compile error] Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Nicolas Boichat [Thu, 3 Mar 2016 10:19:45 +0000 (18:19 +0800)]
mmc: mediatek: Use mmc_regulator_set_vqmmc in start_signal_voltage_switch
We've introduced a new helper in the MMC core:
mmc_regulator_set_vqmmc(). Let's use this in mtk-sd. Using this new
helper has some advantages:
1. We get the mmc_regulator_set_vqmmc() behavior of trying to match
VQMMC and VMMC when the signal voltage is 3.3V. This ensures max
compatibility.
2. We get rid of a few more warnings when probing unsupported
voltages.
3. We get rid of some non-mediatek specific code in mtk-sd.
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Nicolas Boichat [Thu, 3 Mar 2016 10:19:44 +0000 (18:19 +0800)]
mmc: mediatek: Change signal voltage error to dev_dbg()
In commit ceae98f20e36 ("mmc: core: Try other signal levels
during power up") we can see that there are times when it's
valid to try several signal voltages. Don't print an ugly
error in the logs when that happens.
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Simon Horman [Wed, 24 Feb 2016 02:39:33 +0000 (11:39 +0900)]
mmc: sh_mmcif, tmio: Use ARCH_RENESAS
Make use of ARCH_RENESAS in place of ARCH_SHMOBILE.
This is part of an ongoing process to migrate from ARCH_SHMOBILE to
ARCH_RENESAS the motivation for which being that RENESAS seems to be a more
appropriate name than SHMOBILE for the majority of Renesas ARM based SoCs.
Lucas Stach [Mon, 29 Feb 2016 20:56:24 +0000 (21:56 +0100)]
mmc: tegra: properly disable card clock
The new code to do the clock rate setting externally to the SDMMC
module has a shortcut to not propagate changes with a 0 rate to
the CAR by simply bailing out. This breaks proper cutting of the
card clock. Fix it by directly calling the correct sdhci function.
# dmesg | grep mmc
mmc_spi spi32766.0: SD/MMC host mmc0, no WP, no poweroff, cd polling
mmc0: host does not support reading read-only switch, assuming write-enable
mmc0: new SDHC card on SPI
mmcblk0: mmc0:0000 SU04G 3.69 GiB
mmcblk0: p1
With this patch applied the "cd polling" portion above disappears.
Jon Hunter [Fri, 26 Feb 2016 09:34:17 +0000 (09:34 +0000)]
mmc: tegra: Disable UHS-I modes for tegra114
SD card support for Tegra114 started failing after commit a8e326a911d3
("mmc: tegra: implement module external clock change") was merged. This
commit was part of a series to enable UHS-I modes for Tegra. To
workaround this problem for now, disable UHS-I modes for Tegra114 by
separating the soc data structures for Tegra114 and Tegra124 so that
UHS-I is still enabled for Tegra124 but not Tegra114.
Jisheng Zhang [Tue, 16 Feb 2016 13:08:31 +0000 (21:08 +0800)]
mmc: sdhci-pltfm: remove priv variable from sdhci_pltfm_host
Now all clients migration to use sdhci_pltfm_init for private
allocation is done and there's no users of the priv variable, so we can
remove it from the sdhci_pltfm_host structure.
Jisheng Zhang [Tue, 16 Feb 2016 13:08:29 +0000 (21:08 +0800)]
mmc: sdhci-tegra: use sdhci_pltfm_init for private allocation
Commit 0e748234293f ("mmc: sdhci: Add size for caller in init+register")
allows users of sdhci_pltfm to allocate private space in calls to
sdhci_pltfm_init+sdhci_pltfm_register. This patch migrates sdhci-tegra
to this allocation.
Jisheng Zhang [Tue, 16 Feb 2016 13:08:28 +0000 (21:08 +0800)]
mmc: sdhci-st: use sdhci_pltfm_init for private allocation
Commit 0e748234293f ("mmc: sdhci: Add size for caller in init+register")
allows users of sdhci_pltfm to allocate private space in calls to
sdhci_pltfm_init+sdhci_pltfm_register. This patch migrates sdhci-st
to this allocation.
Jisheng Zhang [Tue, 16 Feb 2016 13:08:27 +0000 (21:08 +0800)]
mmc: sdhci-pxav3: use sdhci_pltfm_init for private allocation
Commit 0e748234293f ("mmc: sdhci: Add size for caller in init+register")
allows users of sdhci_pltfm to allocate private space in calls to
sdhci_pltfm_init+sdhci_pltfm_register. This patch migrates sdhci-pxav3
to this allocation.
Jisheng Zhang [Tue, 16 Feb 2016 13:08:26 +0000 (21:08 +0800)]
mmc: sdhci-of-esdhc: use sdhci_pltfm_init for private allocation
Commit 0e748234293f ("mmc: sdhci: Add size for caller in init+register")
allows users of sdhci_pltfm to allocate private space in calls to
sdhci_pltfm_init+sdhci_pltfm_register. This patch migrates the
sdhci-of-esdhc driver to this allocation.
Jisheng Zhang [Tue, 16 Feb 2016 13:08:25 +0000 (21:08 +0800)]
mmc: sdhci-of-at91: use sdhci_pltfm_init for private allocation
Commit 0e748234293f ("mmc: sdhci: Add size for caller in init+register")
allows users of sdhci_pltfm to allocate private space in calls to
sdhci_pltfm_init+sdhci_pltfm_register. This patch migrates the
sdhci-of-at91 driver to this allocation.
Jisheng Zhang [Tue, 16 Feb 2016 13:08:24 +0000 (21:08 +0800)]
mmc: sdhci-of-arasan: use sdhci_pltfm_init for private allocation
Commit 0e748234293f ("mmc: sdhci: Add size for caller in init+register")
allows users of sdhci_pltfm to allocate private space in calls to
sdhci_pltfm_init+sdhci_pltfm_register. This patch migrates the
sdhci-of-arasan driver to this allocation.
Jisheng Zhang [Tue, 16 Feb 2016 13:08:23 +0000 (21:08 +0800)]
mmc: sdhci-of-arasan: fix clk issue in sdhci_arasan_remove()
sdhci_pltfm_unregister() could operate host's registers, it will cause
problems if the clk is already disabled and unprepared. Fix this issue
by moving the clk_disable_unprepare() call to the end of remove
function.
Jisheng Zhang [Tue, 16 Feb 2016 13:08:22 +0000 (21:08 +0800)]
mmc: sdhci-msm: use sdhci_pltfm_init for private allocation
Commit 0e748234293f ("mmc: sdhci: Add size for caller in init+register")
allows users of sdhci_pltfm to allocate private space in calls to
sdhci_pltfm_init+sdhci_pltfm_register. This patch migrates sdhci-msm
to this allocation.
Jisheng Zhang [Tue, 16 Feb 2016 13:08:21 +0000 (21:08 +0800)]
mmc: sdhci-msm: factorise sdhci_msm_pdata outisde of sdhci_msm_host
There's no need to allocate one sdhci_msm_pdata for each sdhci_msm_host.
This patch removes the sdhci_msm_pdata member from sdhci_msm_host and
uses one static global sdhci_msm_pdata for all sdhci msm hosts. It also
marks sdhci_msm_ops as const.
Jisheng Zhang [Tue, 16 Feb 2016 13:08:20 +0000 (21:08 +0800)]
mmc: sdhci-esdhc-imx: use sdhci_pltfm_init for private allocation
Commit 0e748234293f ("mmc: sdhci: Add size for caller in init+register")
allows users of sdhci_pltfm to allocate private space in calls to
sdhci_pltfm_init+sdhci_pltfm_register. This patch migrates the sdhci
esdhc-imx driver to this allocation.
Jisheng Zhang [Tue, 16 Feb 2016 13:08:19 +0000 (21:08 +0800)]
mmc: sdhci-bcm2835: use sdhci_pltfm_init for private allocation
Commit 0e748234293f ("mmc: sdhci: Add size for caller in init+register")
allows users of sdhci_pltfm to allocate private space in calls to
sdhci_pltfm_init+sdhci_pltfm_register. This patch migrates sdhci-bcm2835
to this allocation.
Signed-off-by: Jisheng Zhang <jszhang@marvell.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Acked-by: Eric Anholt <eric@anholt.net> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Wolfram Sang [Mon, 15 Feb 2016 15:01:48 +0000 (16:01 +0100)]
mmc: sdhi: Add r8a7795 support
Registers are 64bit apart, so we refactor bus_shift handling a little and set
it based on the DT compatible. Also, EXT_ACC is different. It has been tested
on a Salvator-X (Gen3) and, to check for regressions, on a Lager (Gen2).
Signed-off-by: Ai Kyuse <ai.kyuse.uw@renesas.com> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Russell King [Tue, 26 Jan 2016 13:41:20 +0000 (13:41 +0000)]
mmc: sdhci: further code simplication
Further simplify the code in sdhci_prepare_data() - we don't set
SDHCI_REQ_USE_DMA anywhere else in the driver, so there is no
need to set it, and then immediately test it.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Russell King [Tue, 26 Jan 2016 13:41:14 +0000 (13:41 +0000)]
mmc: sdhci: consolidate the DMA/ADMA size/address quicks
Rather than scanning the scatterlist multiple times for each quirk,
scan it once, checking for each possible quirk. This should be
cheaper due to the length and offset members commonly sharing the
same cache line than scanning the scatterlist multiple times.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Russell King [Tue, 26 Jan 2016 13:40:42 +0000 (13:40 +0000)]
mmc: sdhci: cleanup DMA un-mapping
The patch "mmc: sdhci: plug DMA mapping leak on error" added
un-mapping logic to sdhci_tasklet_finish() where it is always
called, thereby preventing the mapping leaking.
Consequently the un-mapping code in sdhci_finish_data() is no
longer needed. Remove it.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
[ Split from original "mmc: sdhci: plug DMA mapping leak on error" patch ] Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Russell King [Tue, 26 Jan 2016 13:40:37 +0000 (13:40 +0000)]
mmc: sdhci: clean up host cookie handling
Commit d31911b9374a ("mmc: sdhci: fix dma memory leak in sdhci_pre_req()")
added a complicated method to manage the DMA map state for the data
transfer, but this complexity is not required.
There are three states:
* Unmapped
* Mapped by sdhci_pre_req()
* Mapped by sdhci_prepare_data()
sdhci_prepare_data() needs to know when the data buffers have been
successfully mapped by sdhci_pre_req(), and if so, there is no need to
map them a second time.
When we come to tear down the mapping, we want to know whether
sdhci_post_req() will be called (which is determined by sdhci_pre_req()
having been previously called) so that we can postpone the unmap
operation.
Hence, it makes sense to simply record when the successful DMA map
happened (via COOKIE_PRE_MAPPED vs COOKIE_MAPPED) rather than having
the complex mechanics involving COOKIE_MAPPED vs COOKIE_GIVEN.
If a mapping is created by sdhci_prepare_data(), we must tear it down
ourselves, without waiting for sdhci_post_req() (hence, the new
COOKIE_MAPPED case). If the mapping is created by sdhci_pre_req()
then sdhci_post_req() is responsible for tearing the mapping down.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Russell King [Tue, 26 Jan 2016 13:40:22 +0000 (13:40 +0000)]
mmc: sdhci: factor out sdhci_pre_dma_transfer() from sdhci_adma_table_pre()
In sdhci_prepare_data(), when SDHCI_REQ_USE_DMA is set, there are two
paths that prepare the data buffers for transfer. One is when
SDHCI_USE_ADMA is set, and is located inside sdhci_adma_table_pre().
The other is when SDHCI_USE_ADMA is clear, in the else clause of the
above.
Factor out the call to sdhci_pre_dma_transfer() along with its error
checking.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Russell King [Tue, 26 Jan 2016 13:40:11 +0000 (13:40 +0000)]
mmc: sdhci: factor out common DMA cleanup in sdhci_finish_data()
sdhci_finish_data() has two paths which result in identical DMA cleanup.
One is when SDHCI_USE_ADMA is clear, and the other is just before when
SDHCI_USE_ADMA is set, and is performed within sdhci_adma_table_post().
Simplify the code by removing the 'else' and eliminating the duplicate
inside sdhci_adma_table_post().
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Russell King [Tue, 26 Jan 2016 13:40:06 +0000 (13:40 +0000)]
mmc: sdhci: avoid walking SG list for writes
If we are writing data to the card, there is no point in walking the
scatterlist to find out if there are any unaligned entries; this is a
needless waste of CPU cycles. Avoid this by checking for a non-read
tranfer first.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Russell King [Tue, 26 Jan 2016 13:39:55 +0000 (13:39 +0000)]
mmc: sdhci: allocate alignment and DMA descriptor buffer together
Allocate both the alignment and DMA descriptor buffers together. The
size of the alignment buffer will always be aligned to the hosts
required alignment, which gives appropriate alignment to the DMA
descriptors.
We have a maximum of 128 segments, and a maximum alignment of 64 bits.
This gives a maximum alignment buffer size of 1024 bytes.
The DMA descriptors are a maximum of 12 bytes, and we allocate 128 * 2
+ 1 of these, which gives a maximum DMA descriptor buffer size of 3084
bytes.
This means the allocation for a 4K page sized system will be an order-1
allocation, since the resulting overall size is 4108. This is more
prone to failure than page-sized allocations, but since this allocation
commonly occurs at startup, the chances of failure are small.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
[ Changed to check ADMA table alignment ] Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Russell King [Tue, 26 Jan 2016 13:41:04 +0000 (13:41 +0000)]
mmc: sdhci: fix data timeout (part 2)
The calculation for the timeout based on the number of card clocks is
incorrect. The calculation assumed:
timeout in microseconds = clock cycles / clock in Hz
which is clearly a several orders of magnitude wrong. Fix this by
multiplying the clock cycles by 1000000 prior to dividing by the Hz
based clock. Also, as per part 1, ensure that the division rounds
up.
As this needs 64-bit math via do_div(), avoid it if the clock cycles
is zero.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Cc: stable@vger.kernel.org # v3.15+ Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Russell King [Tue, 26 Jan 2016 13:40:58 +0000 (13:40 +0000)]
mmc: sdhci: fix data timeout (part 1)
The data timeout gives the minimum amount of time that should be
waited before timing out if no data is received from the card.
Simply dividing the nanosecond part by 1000 does not give this
required guarantee, since such a division rounds down. Use
DIV_ROUND_UP() to give the desired timeout.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Cc: stable@vger.kernel.org # v3.15+ Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Russell King [Tue, 26 Jan 2016 13:40:53 +0000 (13:40 +0000)]
mmc: sdhci: further fix for DMA unmapping in sdhci_post_req()
sdhci_post_req() exists to unmap a previously mapped but already
finished request, while the next request is in progress. However, the
state of the SDHCI_REQ_USE_DMA flag depends on the last submitted
request.
This means we can end up clearing the flag due to a quirk, which then
means that sdhci_post_req() fails to unmap the DMA buffer, potentially
leading to data corruption.
We can safely ignore the SDHCI_REQ_USE_DMA here, as testing
data->host_cookie is entirely sufficient.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
[ Re-based to apply as a separate fix ] Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Cc: stable@vger.kernel.org # v4.5+ Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Commit 1140011ee9d9 ("mmc: sdhci-pxav3: Modify clock settings for the
SDR50 and DDR50 modes") broke any chance of the SDR50 or DDR50 modes
being used.
The commit claims that SDR50 and DDR50 require clock adjustments in
the SDIO3 Configuration register, which is located via the "conf-sdio3"
resource. However, when this resource is given, we fail to read the
host capabilities 1 register, resulting in host->caps1 being zero.
Hence, both SDHCI_SUPPORT_SDR50 and SDHCI_SUPPORT_DDR50 bits remain
zero, disabling the SDR50 and DDR50 modes.
The underlying idea in this function appears to be to read the device
capabilities, modify them, and set SDHCI_QUIRK_MISSING_CAPS to cause
our modified capabilities to be used. Implement exactly that.
Fixes: 1140011ee9d9 ("mmc: sdhci-pxav3: Modify clock settings for the SDR50 and DDR50 modes") Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Cc: stable@vger.kernel.org # v4.5+ Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Russell King [Tue, 26 Jan 2016 13:40:42 +0000 (13:40 +0000)]
mmc: sdhci: plug DMA mapping leak on error
If we terminate a command early, we fail to properly clean up the DMA
mappings for the data part of the request. Put this clean up to the
tasklet, which is the common path for finishing a request so we always
clean up after ourselves.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
[ Split original patch so that it now contains only the fix ] Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Cc: stable@vger.kernel.org # v4.5+ Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Russell King [Tue, 26 Jan 2016 13:39:50 +0000 (13:39 +0000)]
mmc: sdhci: avoid unnecessary mapping/unmapping of align buffer
Unnecessarily mapping and unmapping the align buffer for SD cards is
expensive: performance measurements on iMX6 show that this gives a hit
of 10% on hdparm buffered disk reads.
MMC/SD card IO comes from the mm/vfs which gives us page based IO, so
for this case, the align buffer is not going to be used. However, we
still map and unmap this buffer.
Eliminate this by switching the align buffer to be a DMA coherent
buffer, which needs no DMA maintenance to access the buffer.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Cc: stable@vger.kernel.org # v4.5+ Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
When we get a response CRC error on a command, it means that the
response we received back from the card was not correct. It does not
mean that the card did not receive the command correctly. If the
command is one which initiates a data transfer, the card can enter the
data transfer state, and start sending data.
Moreover, if the request contained a data phase, we do not clean this
up, and this results in the driver triggering DMA API debug warnings,
and also creates a race condition in the driver, between running the
finish_tasklet and the data transfer interrupts, which can trigger a
"Got data interrupt" state dump.
Fix this by handing a response CRC error slightly differently: record
the failure of the data initiating command, but allow the remainder of
the request to be processed normally. This is safe as core MMC checks
the status of all commands and data transfer phases of the request.
If the card does not initiate a data transfer, then we should time out
according to the data transfer parameters.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
[ Fix missing parenthesis around bitwise-AND expression, and tweak subject ] Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Cc: stable@vger.kernel.org # v4.5+ Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Ulf Hansson [Thu, 11 Feb 2016 14:14:59 +0000 (15:14 +0100)]
MAINTAINERS: mmc: Add Adrian Hunter as the maintainer for SDHCI
up the maintainer role for SDHCI. I am very pleased that Adrian Hunter
volunteered and accepted the challenge!
The SDHCI code is currently in quite poor quality, but we have agreed on
a way forward to try to reach a point where the SDHCI core becomes more of
a set of library functions. Each SDHCI driver variant can then decide
which functions to use and allows it to implement variant specific code,
without needing to also change SDHCI core code.
In the end we aim to get better optimized and maintainable code.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Al Cooper [Wed, 10 Feb 2016 20:25:39 +0000 (15:25 -0500)]
mmc: sdhci: Allow CAPS check for SDHCI_CAN_64BIT to use overridden caps
sdhci_add_host() allows the Host Controller Capability registers
to be supplied by the calling driver by using
SDHCI_QUIRK_MISSING_CAPS, but the check for the Capabilities bit
SDHCI_CAN_64BIT doesn't use the applied value and instead reads
the Host register directly. This change uses the supplied "caps"
register instead of reading the host register.
This change will allow a calling driver to simply clear the
SDHCI_CAN_64BIT bit in "caps" to handle some cases of
SDHCI_QUIRK2_BROKEN_64_BIT_DMA.
Signed-off-by: Al Cooper <alcooperx@gmail.com> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Shawn Lin [Tue, 26 Jan 2016 00:43:36 +0000 (08:43 +0800)]
mmc: dw_mmc: remove repetitive clear interrupt
dw_mci_probe clear interrupts and disable all interrupts firstly.
While it clear interrupt again before enable some interrupts. We
can't see any reason to clear it twice here, so remove the second one.
dw_mmc already use mmc_of_parse to get "broken-cd" property,
but it considered "broken-cd" to be a quirk in its driver. We
don't need this quirk here, and just take what we need from
mmc->caps.
Shawn Lin [Thu, 14 Jan 2016 01:08:02 +0000 (09:08 +0800)]
mmc: dw_mmc: add hw_reset support
This patch implement hw_reset function for DesignWare
MMC controller. By adding this feature, mmc blk can
do some basic recovery.
Set the following resets:
software reset – BMOD[0] for IDMAC only
DMA reset - CTRL[2]
FIFO reset - CTRL[1] bits
Program the CARD_RESET register with a value of 0 for the bit
corresponding to the card number; This programming asserts the
RST_n signal and resets the card. After a minimum of 1 ?s, de-asserts the
RST_n signal and takes the card out of reset. The application can program
a new CMD only after a minimum of 200 us
This implementation can be easily tested by cutting off->On vmmc
while doing data accessing in background to simulate that case.
Jaehoon Chung [Thu, 21 Jan 2016 02:01:06 +0000 (11:01 +0900)]
mmc: dw_mmc: remove the prepare_command hook
This patch removes the prepare_command hook from entire dw_mmc driver.
Now, almost all SoCs are using by default, except Exynos.
It seems that dwmmc controller is using unnecessary hook.
To know whether needs to set this bit or not,
add the DW_MMC_CARD_NO_USE_HOLD bit.
If some SoCs need to disable this in future, just set the
DW_MMC_CARD_NO_USE_HOLD bit.
set_bit(DW_MMC_CARD_NO_USE_HOLD, &slot->flags),
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com> Tested-by: Shawn Lin <shawn.lin@rock-chips.com> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Russell King [Fri, 29 Jan 2016 09:44:00 +0000 (09:44 +0000)]
mmc: block: shut up "retrying because a re-tune was needed" message
Re-tuning is part of standard requirements for the higher speed SD
card protocols, and is not an error when this occurs. When we retry
a command due to a retune, we should not print a message to the
kernel log.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Russell King [Fri, 29 Jan 2016 09:43:55 +0000 (09:43 +0000)]
mmc: core: improve mmc_of_parse_voltage() to return better status
Improve mmc_of_parse_voltage()'s return values so that drivers can tell
whether a voltage-range specification was present, and whether it has
been successfully parsed, or there was an error while parsing.
We return a negative errno when parsing fails, zero if no voltage-range
specification is present, or one if a voltage-range specification is
successfully parsed.
No users need modifying as no users check the return value.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Russell King [Fri, 29 Jan 2016 09:43:50 +0000 (09:43 +0000)]
mmc: core: shut up "voltage-ranges unspecified" pr_info()
Each time a driver such as sdhci-esdhc-imx is probed, we get a info
printk complaining that the DT voltage-ranges property has not been
specified.
However, the DT binding specifically says that the voltage-ranges
property is optional. That means we should not be complaining that
DT hasn't specified this property: by indicating that it's optional,
it is valid not to have the property in DT.
Silence the warning if the property is missing.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Wolfram Sang [Tue, 19 Jan 2016 11:32:58 +0000 (12:32 +0100)]
mmc: tmio: disable clock before changing it
Rcar2 & 3 docs state that for going to and coming from the 0xff setting,
the clock must first be disabled before the DIV bits are changed.
Instead of tracking this, let's just do this unconditionally.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Wolfram Sang [Tue, 19 Jan 2016 11:32:58 +0000 (12:32 +0100)]
mmc: tmio: refactor set_clock a little
Some of the indentation made the code awful to read. Fix that. Also,
introduce defines instead of magic hex values. Note that this includes
one change: We mask out know 0xff instead of 0x1ff. But 0x100 has always
been the clock enable bit. It doesn't make any sense to set it depending
on the clock calculation. Update copyright notices, too. I'll be working
on those files some more in the future.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Wolfram Sang [Fri, 22 Jan 2016 14:51:59 +0000 (15:51 +0100)]
mmc: tmio_dma: remove debug messages with little information
When compiling the driver with CONFIG_MMC_DEBUG set, I got build
warnings. They have been 'fixed' meanwhile. However, because these debug
messages look random anyhow (some duplicate information printed etc),
let's just drop them and rather re-add something consistent if that
should ever be needed.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Jaehoon Chung [Mon, 1 Feb 2016 12:07:36 +0000 (21:07 +0900)]
mmc: block: don't use the OR operation for flag of data
After removed the MMC_DATA_STREAM, only two flags are remained.
(MMC_DATA_READ and MMC_DATA_WRITE)
The flags of READ and WRITE can't be used together.
That's why it doesn't need to use "OR' operation.
Chen-Yu Tsai [Fri, 29 Jan 2016 17:21:48 +0000 (01:21 +0800)]
mmc: sunxi: Enable eMMC HS-DDR (MMC_CAP_1_8V_DDR) support
Now that clock delay settings for 8 bit DDR are correct, and vqmmc
support is available, we can enable MMC_CAP_1_8V_DDR support. This
enables MMC HS-DDR at up to 52 MHz, even if signal voltage switching
is not available.
Signed-off-by: Chen-Yu Tsai <wens@csie.org> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Chen-Yu Tsai [Fri, 29 Jan 2016 17:21:47 +0000 (01:21 +0800)]
mmc: sunxi: Support 8 bit eMMC DDR transfer modes
Allwinner's MMC controller needs to run at double the card clock rate
for 8 bit DDR transfer modes. Interestingly, this is not needed for
4 bit DDR transfers.
Different clock delays are needed for 8 bit eMMC DDR, due to the
increased module clock rate. For the A80 though, the same values for
4 bit and 8 bit are shared. The new values for the other SoCs were from
A83T user manual's "new timing mode" default values, which describes
them in clock phase, rather than delay periods. These values were used
without any modification. They may not be correct, but they work.
Signed-off-by: Chen-Yu Tsai <wens@csie.org> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Chen-Yu Tsai [Fri, 29 Jan 2016 17:21:46 +0000 (01:21 +0800)]
mmc: sunxi: Support MMC_DDR52 timing modes
DDR transfer modes include UHS-1 DDR50 and MMC HS-DDR (or MMC_DDR52).
Consider MMC_DDR52 when setting clock delays.
Since MMC high speed mode goes up to 52 MHz instead of 50 MHz for SD,
and this number is visible in the capability macro, increase the
clock rate upper limit to 52 MHz.
Signed-off-by: Chen-Yu Tsai <wens@csie.org> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Wolfram Sang [Fri, 29 Jan 2016 08:27:50 +0000 (09:27 +0100)]
mmc: sanitize 'bus width' in debug output
The bus width is sometimes the actual bus width, and sometimes indices
to different arrays encoding the bus width. In my debugging case "2"
could mean 8-bit as well as 4-bit, which was extremly confusing. Let's
use the human-readable actual bus width in all places.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Stefan Wahren [Wed, 27 Jan 2016 22:25:42 +0000 (22:25 +0000)]
mmc: DT: sdhci-iproc: add bcm2835 compatible
Since sdhci-iproc can support bcm2835 we need add the
compatible string to the binding.
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com> Acked-by: Scott Branden <sbranden@broadcom.com> Acked-by: Eric Anholt <eric@anholt.net> Acked-by: Rob Herring <robh@kernel.org> Acked-by: Scott Branden <sbranden@broadcom.com> Acked-by: Stephen Warren <swarren@wwwdotorg.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Stefan Wahren [Wed, 27 Jan 2016 22:25:41 +0000 (22:25 +0000)]
mmc: sdhci-iproc: add bcm2835 support
Scott Branden from Broadcom said that the BCM2835 eMMC IP core is
very similar to IPROC and share most of the quirks. So use this driver
instead of separate one.
The sdhci-iproc contains a better workaround for the clock domain
crossing problem which doesn't need any delays. This results in a
better write performance.
Btw we get the rid of the SDHCI_CAPABILITIES hack in the sdhci_readl
function.
Suggested-by: Scott Branden <sbranden@broadcom.com> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com> Acked-by: Eric Anholt <eric@anholt.net> Acked-by: Scott Branden <sbranden@broadcom.com> Acked-by: Stephen Warren <swarren@wwwdotorg.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Stefan Wahren [Wed, 27 Jan 2016 22:25:40 +0000 (22:25 +0000)]
mmc: sdhci-iproc: define MMC caps in platform data
This patch moves the definition of the MMC capabilities
from the probe function into iproc platform data. After
that we are able to add support for another platform more
easily.
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com> Suggested-by: Stephen Warren <swarren@wwwdotorg.org> Acked-by: Scott Branden <sbranden@broadcom.com> Acked-by: Stephen Warren <swarren@wwwdotorg.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
When DT based probing is used but the DMA request fails, the
driver will print uninitialized stack data from the rx_req
and tx_req variables, as indicated by this warning:
drivers/mmc/host/omap_hsmmc.c: In function 'omap_hsmmc_probe':
drivers/mmc/host/omap_hsmmc.c:2162:3: warning: 'rx_req' may be used uninitialized in this function [-Wmaybe-uninitialized]
dev_err(mmc_dev(host->mmc), "unable to obtain RX DMA engine channel %u\n", rx_req);
This removes the DMA request line number from the warning, which
is the easiest solution and won't hurt us any more as we are
planning to remove the legacy code path anyway.
Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Tony Lindgren <tony@atomide.com> Reviewed-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>