Commit Graph

649829 Commits

Author SHA1 Message Date
Linus Walleij
74f5ba357c mmc: block: rename mmc_active to areq
The mmc_active member of struct mmc_queue_req has a very
confusing name: this is certainly not always "active", it is
the asynchronous request associated by the mmc_queue_req
but it is not guaranteed to be "active" in any sense, such
as being running on the host.

Simply rename this member to "areq".

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2017-02-13 13:20:59 +01:00
Linus Walleij
b2928e1049 mmc: block: refactor mmc_blk_rw_try_restart()
The mmc_blk_rw_start_new() was named after the label inside
mmc_blk_issue_rw_rq() but is really a confusing name for this
function: what it does is to try to restart the latest issued
command on the host and card of the current MMC queue.

So rename it mmc_blk_rw_try_restart() that reflects what it
is doing and at this point also refactore the function to
treat the removed card as an exception and just exit if this
happens and run on in the function if that is not happening.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2017-02-13 13:20:58 +01:00
Linus Walleij
c3399ef55d mmc: core: rename mmc_start_req() to *areq()
With the coexisting __mmc_start_request(), mmc_start_request()
and __mmc_start_req() it is a bit confusing that mmc_start_req()
actually does not start a normal request, but an asynchronous
request.

Rename it to mmc_start_areq() to make it explicit what the
function is doing, also fix the kerneldoc for this function
while we're at it.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2017-02-13 13:20:58 +01:00
Linus Walleij
acd8dbd64a mmc: block: rename rqc and req
In the function mmc_blk_issue_rw_rq() the new request coming in
from the block layer is called "rqc" and the old request that
was potentially just returned back from the asynchronous
mechanism is called "req".

This is really confusing when trying to analyze and understand
the code, it becomes a perceptual nightmare to me. Maybe others
have better parserheads but it is not working for me.

Rename "rqc" to "new_req" and "req" to "old_req" to reflect what
is semantically going on into the syntax.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2017-02-13 13:20:57 +01:00
Linus Walleij
db435505b5 mmc: block: inline the command abort and start new goto:s
The goto statements sprinkled over the mmc_blk_issue_rw_rq()
function has grown over the years and makes the code pretty hard
to read.

Inline the calls such that:

goto cmd_abort; ->
mmc_blk_rw_cmd_abort(card, req);
mmc_blk_rw_start_new(mq, card, rqc);
return;

goto start_new_req; ->
mmc_blk_rw_start_new(mq, card, rqc);
return;

After this it is more clear how we exit the do {} while
loop in this function, and it gets possible to split the
code apart.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2017-02-13 13:20:57 +01:00
Heiner Kallweit
a04848c75b mmc: core: switch to ida_simple_ functions in block.c
ida code in block.c can be significantly simplified by switching to
the ida_simple_ functions.

Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2017-02-13 13:20:56 +01:00
Ravikumar Kattekola
a53210f56d mmc: host: omap_hsmmc: avoid possible overflow of timeout value
Fixes: a45c6cb816 ("[ARM] 5369/1: omap mmc: Add new omap
hsmmc controller for 2430 and 34xx, v3")

when using really large timeout (up to 4*60*1000 ms for bkops)
there is a possibility of data overflow using
unsigned int so use 64 bit unsigned long long.

Signed-off-by: Ravikumar Kattekola <rk@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2017-02-13 13:20:55 +01:00
Kishon Vijay Abraham I
8cc9a3e73d mmc: host: omap_hsmmc: use generic_cmd6_time to program timeout value for CMD6
commit e2bf08d643 ("omap_hsmmc: set a large data timeout for
commands with busy signal") sets an arbitrary timeout value (100ms) for
commands like CMD6 (MMC SWITCH). However extended CSD register defined
in the eMMC standard has a field for GENERIC_CMD6_TIME which indicates
the default maximum timeout for a SWITCH command.
Use busy_timeout of cmd structure (populated with GENERIC_CMD6_TIME
in the case of SWITCH command) to program the data timeout value in
omap_hsmmc driver.
SWITCH command to turn the cache on took more than 100ms to complete
with MICRON eMMC card present in AM572x IDK REV 1.3A resulting in
timeout and failed enumeration. It is fixed here by programming the
timeout with the value advertised in GENERIC_CMD6_TIME.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Ravikumar Kattekola <rk@ti.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2017-02-13 13:20:55 +01:00
Ravikumar Kattekola
24380dd4f8 mmc: host: omap_hsmmc: reset cmd line on ceb error
When CEB (command end bit error) occurs
reset CMD line to avoid system ending up in
erroneous state.
While command line is reset for CTO and CCRC errors,
it's not done for CEB error. Fix it here.

Reviewed-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Ravikumar Kattekola <rk@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2017-02-13 13:20:54 +01:00
Maxime Ripard
3d33cb5ad5 dt-bindings: mmc: sunxi: Document A64 eMMC compatible
We introduced recently a new compatible to deal with the A64 eMMC
controller, let's document its binding.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: Chen-Yu Tsai <wens@csie.org>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2017-02-13 13:20:54 +01:00
Shawn Lin
ce69e2fea0 mmc: dw_mmc: silent verbose log when calling from PM context
When deploying runtime PM, it's quite verbose to print the
log of ios setting. Also it's useless to print it from system
PM as it should be the same with booting time. We also have
sysfs to get all these information from ios attribute, so let's
skip this print from PM context.

Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2017-02-13 13:20:53 +01:00
Linus Walleij
e13934bdf4 mmc: core/mmci: restore pre/post_req behaviour
commit 64b12a68a9
"mmc: core: fix prepared requests while doing bkops"
is fixing a bug in the wrong way. A bug in the MMCI
device driver is fixed by amending the MMC core.

Thinking about it: what the pre- and post-callbacks
are doing is to essentially map and unmap SG lists
for DMA transfers. Why would we not be able to do that
just because a BKOPS command is sent inbetween?
Having to unprepare/prepare the next asynchronous
request for DMA seems wrong.

Looking the backtrace in that commit we can see what
the real problem actually is:

mmci_data_irq() is calling mmci_dma_unmap() twice
which is goung to call arm_dma_unmap_sg() twice
and v7_dma_inv_range() twice for the same sglist
and that will crash.

This happens because a request is prepared, then
a BKOPS is sent. The IRQ completing the BKOPS command
goes through mmci_data_irq() and thinks that a DMA
operation has just been completed because
dma_inprogress() reports true. It then proceeds to
unmap the sglist.

But that was wrong! dma_inprogress() should NOT be
true because no DMA was actually in progress! We had
just prepared the sglist, and the DMA channel
dma_current has been configured, but NOT started!

Because of this, the sglist is already unmapped when
we get our actual data completion IRQ, and we are
unmapping the sglist once more, and we get this crash.

Therefore, we need to revert this solution pushing
the problem to the core and causing problems, and
instead augment the implementation such that
dma_inprogress() only reports true if some DMA has
actually been started.

After this we can keep the request prepared during the
BKOPS and we need not unprepare/reprepare it.

Fixes: 64b12a68a9 ("mmc: core: fix prepared requests while doing bkops")
Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Tested-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2017-02-13 13:20:52 +01:00
Maxime Ripard
43c15e962c mmc: sunxi: Add more debug informations
Add a bit more debug messages that can be helpful when debugging the clock
setup.

Also fill the actual_clock field in struct mmc_host to report properly the
current frequency in debugfs.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Tested-by: Florian Vaussard <florian.vaussard@heig-vd.ch>
Acked-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2017-02-13 13:20:52 +01:00
Maxime Ripard
4fb3ce07ea mmc: sunxi: Add EMMC (MMC2) controller compatible
The MMC2 controller on the A64 is kind of a special beast.

While the general controller design is the same than the other MMC
controllers in the SoC, it also has a bunch of features and changes that
prevent it to be driven in the same way.

It has for example a different bus width limit, a different maximum
frequency, and, for some reason, the maximum buffer size of a DMA
descriptor.

Add a new compatible specifically for this controller.

Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Tested-by: Florian Vaussard <florian.vaussard@heig-vd.ch>
Acked-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2017-02-13 13:20:51 +01:00
Maxime Ripard
16e821e3ba mmc: sunxi: Mask DATA0 when updating the clock
The A64 MMC controllers need DATA0 to be masked while updating the clock,
otherwise any subsequent command will result in a timeout.

It's not really clear at this point what DATA0 is exactly, but this
behaviour is present in Allwinner's tree, and has been suggested by
Allwinner engineers as fixes for the timeout.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Tested-by: Florian Vaussard <florian.vaussard@heig-vd.ch>
Acked-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2017-02-13 13:20:51 +01:00
Maxime Ripard
9a37e53e45 mmc: sunxi: Enable the new timings for the A64 MMC controllers
The A64 MMC controllers need to set a "new timings" bit when a new rate is
set.

The actual meaning of that bit is not clear yet, but not setting it leads
to some corner-case issues, like the CMD53 failing, which is used to
implement SDIO packet aggregation.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Tested-by: Florian Vaussard <florian.vaussard@heig-vd.ch>
Acked-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2017-02-13 13:20:50 +01:00
Maxime Ripard
860fdf89b9 mmc: sunxi: Always set signal delay to 0 for A64
Experience have shown that the using the  autocalibration could severely
degrade the performances of the MMC bus.

Allwinner is using in its BSP a delay set to 0 for all the modes but HS400.
Remove the calibration code for now, and add comments to document our
findings.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Tested-by: Florian Vaussard <florian.vaussard@heig-vd.ch>
Acked-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2017-02-13 13:20:49 +01:00
Maxime Ripard
9479074e93 mmc: sunxi: Gate the clock when rate is 0
The MMC core assumes that the code will gate the clock when the bus
frequency is set to 0, which we've been ignoring so far.

Handle that.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Tested-by: Florian Vaussard <florian.vaussard@heig-vd.ch>
Acked-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2017-02-13 13:20:49 +01:00
Maxime Ripard
39cc281fb7 mmc: sunxi: Fix clock frequency change sequence
The SD specification documents that the clock frequency should only be
changed once gated (Section 3.2.3 - SD Clock Frequency Change Sequence).

The current code first modifies the parent clock, gates it and then
modifies the internal divider. This means that since the parent clock rate
might be changed, the bus clock might be changed as well before it is
gated, which breaks the specification.

Move the gating before the parent rate modification.

Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Tested-by: Florian Vaussard <florian.vaussard@heig-vd.ch>
Acked-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2017-02-13 13:20:48 +01:00
Heiner Kallweit
1ed2171944 mmc: core: fix error path in mmc_host_alloc
Properly reverse everything if mmc_gpio_alloc(host) fails.

Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2017-02-13 13:20:48 +01:00
Heiner Kallweit
7413d1f509 mmc: core: simplify ida handling
ida handling can be simplified by switching to the ida_simple_
functions.

Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2017-02-13 13:20:47 +01:00
Ritesh Harjani
543c576d1b mmc: sdhci-msm: Remove unnecessary comments of CDC init sequence
This removes CDC init sequence comments which are
not useful anyway.

Signed-off-by: Ritesh Harjani <riteshh@codeaurora.org>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2017-02-13 13:20:46 +01:00
Ritesh Harjani
4436c53599 mmc: sdhci-msm: Remove platform_execute_tuning from sdhci_msm_ops
platform_execute_tuning should not really exist as it does not
do anything useful.

So remove this ops and directly plug sdhci_msm_execute_tuning
with mmc_host_ops.

Also in case of HS400 tuning clear SDHCI_HS400_TUNING flag once
HS400 related mode selection is done.

Signed-off-by: Ritesh Harjani <riteshh@codeaurora.org>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2017-02-13 13:20:46 +01:00
Ulf Hansson
fb00f196fc mmc: core: Extend mmc_of_parse() to check for mmc-ddr-3_3v
When mmc_of_parse() finds the binding, it sets the mmc cap,
MMC_CAP_3_3V_DDR, which informs the core whether eMMC DDR at 3.3V I/O is
supported by the mmc host.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>
Tested-by: Jan Glauber <jglauber@cavium.com>
Tested-by: Stefan Wahren <stefan.wahren@i2se.com>
2017-02-13 13:20:45 +01:00
Ulf Hansson
41efc76e0c mmc: dt: Document binding for eMMC DDR 3.3V I/O voltage support
Cc: <devicetree@vger.kernel.org>
Cc: Rob Herring <robh@kernel.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>
Tested-by: Jan Glauber <jglauber@cavium.com>
Tested-by: Stefan Wahren <stefan.wahren@i2se.com>
Acked-by: Rob Herring <robh@kernel.org>
2017-02-13 13:20:45 +01:00
Ulf Hansson
20f921bb01 mmc: core: Invent MMC_CAP_3_3V_DDR
According the JEDEC specification an eMMC card supporting 1.8V vccq in DDR
mode should also be capable of 3.3V. However, it's been reported that some
mmc hosts supports 3.3V, but not 1.8V.

Currently the mmc core implements an error handling when the host fails to
set 1.8V for vccq, by falling back to 3.3V. Unfortunate, this seems to be
insufficient for some mmc hosts. To enable these to use eMMC DDR mode let's
invent a new mmc cap, MMC_CAP_3_3V_DDR, which tells whether they support
the eMMC 3.3V DDR mode.

In case MMC_CAP_3_3V_DDR is set, but not MMC_CAP_1_8V_DDR, let's change to
remain on the 3.3V, as it's the default voltage level for vccq, set by the
earlier power up sequence.

As this change introduces MMC_CAP_3_3V_DDR, let's take the opportunity to
do some re-formatting of the related defines in the header file.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>
Tested-by: Jan Glauber <jglauber@cavium.com>
Tested-by: Stefan Wahren <stefan.wahren@i2se.com>
2017-02-13 13:20:44 +01:00
Ulf Hansson
4e74b6b3c6 mmc: core: Rename __mmc_set_signal_voltage() to mmc_set_signal_voltage()
Earlier the mmc_set_signal_voltage() existed, but since it has been renamed
to mmc_set_uhs_voltage(), we can now use that name instead.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>
Tested-by: Jan Glauber <jglauber@cavium.com>
Tested-by: Stefan Wahren <stefan.wahren@i2se.com>
2017-02-13 13:20:43 +01:00
Ulf Hansson
2ed573b603 mmc: core: Clarify usage of mmc_set_signal_voltage()
The mmc_set_signal_voltage() function is used for SD/SDIO when switching to
1.8V for UHS mode. To clarify this let's do the following changes.

- We are always providing MMC_SIGNAL_VOLTAGE_180 as the signal_voltage
  parameter to the function. Then, let's just remove the parameter as it
  serves no purpose.
- Rename the function to mmc_set_uhs_voltage().

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>
Tested-by: Jan Glauber <jglauber@cavium.com>
Tested-by: Stefan Wahren <stefan.wahren@i2se.com>
2017-02-13 13:20:43 +01:00
Ulf Hansson
a44efa4796 mmc: core: Remove redundant code in mmc_set_signal_voltage()
The mmc_set_signal_voltage() function is used for SD/SDIO when switching to
1.8V for UHS mode. Therefore let's remove the redundant code dealing with
MMC_SIGNAL_VOLTAGE_330.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>
Tested-by: Jan Glauber <jglauber@cavium.com>
Tested-by: Stefan Wahren <stefan.wahren@i2se.com>
2017-02-13 13:20:42 +01:00
Chris Brandt
62a4cdead5 mmc: sh_mobile_sdhi: explain clock bindings
In the case of a single clock source, you don't need names. However,
if the controller has 2 clock sources, you need to name them correctly
so the driver can find the 2nd one. The 2nd clock is for the internal
card detect logic.

Signed-off-by: Chris Brandt <chris.brandt@renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Acked-by: Rob Herring <robh@kernel.org>
2017-02-13 13:20:42 +01:00
Chris Brandt
34a1654706 mmc: sh_mobile_sdhi: add support for 2 clocks
Some controllers have 2 clock sources instead of 1. The 2nd clock
is for the internal card detect logic and must be enabled/disabled
along with the main core clock for proper operation.

Signed-off-by: Chris Brandt <chris.brandt@renesas.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2017-02-13 13:20:41 +01:00
Kevin Hilman
dc012058d7 mmc: meson: cleanup stray debug messages
Cleanup some debug prints that cause needless noise
during normal usage.

Signed-off-by: Kevin Hilman <khilman@baylibre.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2017-02-13 13:20:40 +01:00
Linus Walleij
df06158896 mmc: block: stop passing around pointless return values
The mmc_blk_issue_rq() function is called in exactly one place
in queue.c and there the return value is ignored. So the
functions called from that function that also meticulously
return 0/1 do so for no good reason.

Error reporting on the asynchronous requests are done upward to
the block layer when the requests are eventually completed or
fail, which may happen during the flow of the mmc_blk_issue_*
functions directly (for "special commands") or later, when an
asynchronous read/write request is completed.

The issuing functions do not give rise to errors on their own,
and there is nothing to return back to the caller in queue.c.
Drop all return values and make the function return void.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2017-02-13 13:20:40 +01:00
Linus Walleij
7d552a4808 mmc: block: introduce new_areq and old_areq
Recycling the same variable in an x=x+1 fashion may seem
clever here but it makes the code terse and hard to follow
for humans. Introduce a new_areq and old_areq variable so
we see what is going on.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2017-02-13 13:20:39 +01:00
Linus Walleij
da0dbaffe3 mmc: block: inline command abortions
Setting rqc to NULL followed by a goto to cmd_abort is just a way
to do unconditional abort without starting any new command.
Inline the calls to mmc_blk_rw_cmd_abort() and return immediately
in those cases.

Add some comments to the code flow so it is clear that this is
where the asynchronous requests come back in and the result of
them gets handled.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2017-02-13 13:20:39 +01:00
Linus Walleij
6fb85d6583 mmc: block: do not assign mq_rq when aborting command
The code in mmc_blk_issue_rq_rq() aborts a command if the request
is not properly aligned on large sectors. As part of the path
jumping out, it assigns the local variable mq_rq reflecting
a MMC queue request to the current MMC queue request, which is
confusing since the variable is not used after this jump.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2017-02-13 13:20:38 +01:00
Linus Walleij
efb5a05e70 mmc: block: break out mmc_blk_rw_start_new()
As a step toward breaking apart the very complex function
mmc_blk_issue_rw_rq() we break out the code to start a new
request.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2017-02-13 13:20:38 +01:00
Linus Walleij
4e1f780032 mmc: block: break out mmc_blk_rw_cmd_abort()
As a first step toward breaking apart the very complex function
mmc_blk_issue_rw_rq() we break out the command abort code.
This code assumes "ret" is != 0 and then repeatedly hammers
blk_end_request() until the request to the block layer to end
the request succeeds.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2017-02-13 13:20:37 +01:00
Jaehoon Chung
e64aae82ea mmc: sdhci-s3c: use the bitops API for bit operation
Use the bitops API instead of shifting directly.

Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2017-02-13 13:20:36 +01:00
Jaehoon Chung
57f8324501 mmc: sdhci-s3c: remove the sdhci-s3c-regs header file
Remove the sdhci-s3c-regs.h file.
Instead, it located those defined values into sdhci-s3c.c.

Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2017-02-13 13:20:36 +01:00
Wolfram Sang
ee28981535 mmc: tmio: discard obsolete SDIO irqs before enabling irqs
Before enabling SDIO irqs, clear the status bit, so we discard old and
stale interrupts. Needed to get two wireless cards working. Use the
newly introduced macro in all places.

Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2017-02-13 13:20:35 +01:00
Wolfram Sang
20dd03734c mmc: host: tmio: SDIO_STATUS_QUIRK is rather SDIO_STATUS_SETBITS
QUIRK sounds like there is something wrong, but actually there are just
some bits which need to be 1. Rename it to be more clear.

Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2017-02-13 13:20:34 +01:00
Wolfram Sang
e4f38eb18a mmc: host: tmio: refactor calls to sdio irq
tmio_mmc_sdio_irq() is not used as a seperate irq handler anymore, so we
can make it similar to the other irq helper functions, namely:

* only give the host as argument function which is what it really needs
* prefix function name with __

Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Acked-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2017-02-13 13:20:34 +01:00
Matt Ranostay
de19b4c928 mmc: pwrseq: add support for Marvell SD8787 chip
Allow power sequencing for the Marvell SD8787 Wifi/BT chip.
This can be abstracted to other chipsets if needed in the future.

Cc: Tony Lindgren <tony@atomide.com>
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Matt Ranostay <matt@ranostay.consulting>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2017-02-13 13:20:33 +01:00
Matt Ranostay
e3fffc1f0b devicetree: document new marvell-8xxx and pwrseq-sd8787 options
Cc: Rob Herring <robh@kernel.org>
Cc: devicetree@vger.kernel.org
Signed-off-by: Matt Ranostay <matt@ranostay.consulting>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: Rob Herring <robh@kernel.org>
2017-02-13 13:20:33 +01:00
Wolfram Sang
dfcba5ffca mmc: host: tmio: disable clocks when unbinding
Create a helper function to disable clocks and use it in remove(), too.
Now, clk_summary in debugfs reports the clocks as disabled and
unprepared after unbinding.

Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2017-02-13 13:20:32 +01:00
Ritesh Harjani
44bf23128f mmc: sdhci-msm: Provide enhanced_strobe mode feature support
This provides enhanced_strobe mode feature support in sdhci-msm
driver.

Signed-off-by: Ritesh Harjani <riteshh@codeaurora.org>
Tested-by: Jeremy McNicoll <jeremymc@redhat.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2017-02-13 13:20:31 +01:00
Ritesh Harjani
d7507aa1b9 mmc: sdhci-msm: Make HS400 tuning follow as per recommeneded HW sequence
During tuning execution for HS400 mode, HW sequence recommends
to select MCLK_SEL/2(0x3) in VENDOR_SPEC & sdhc msm clock at GCC
to be 400MHZ (nearest supported clk). Add this change in tuning
sequence during HS400 tuning.

Signed-off-by: Ritesh Harjani <riteshh@codeaurora.org>
Tested-by: Jeremy McNicoll <jeremymc@redhat.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2017-02-13 13:20:31 +01:00
Ritesh Harjani
8a8fa8797c mmc: sdhci: Clear SDHCI_HS400_TUNING flag after platform_execute_tuning
Clear SDHCI_HS400_TUNING flag after platform_execute_tuning
so that platform_execute_tuning may use it if needed.

Signed-off-by: Ritesh Harjani <riteshh@codeaurora.org>
Tested-by: Jeremy McNicoll <jeremymc@redhat.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2017-02-13 13:20:30 +01:00
Subhash Jadavani
083c9aa0ad mmc: sdhci-msm: configure CORE_CSR_CDC_DELAY_CFG to recommended value
Program CORE_CSR_CDC_DELAY_CFG for hardware recommended 1.25ns delay.
We may see data CRC errors if it's programmed for any other delay
value.

Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Signed-off-by: Ritesh Harjani <riteshh@codeaurora.org>
Tested-by: Jeremy McNicoll <jeremymc@redhat.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2017-02-13 13:20:30 +01:00