linux-stable.git/drivers/mmc/core, branch v4.10.2

mmc: core: fix multi-bit bus width without high-speed mode

2017-02-14T07:50:10+00:00

Commit 577fb13199b1 ("mmc: rework selection of bus speed mode")
refactored bus width selection code to mmc_select_bus_width().

However, it also altered the behavior to not call the selection code in
non-high-speed modes anymore.

This causes 1-bit mode to always be used when the high-speed mode is not
enabled, even though 4-bit and 8-bit bus are valid bus widths in the
backwards-compatibility (legacy) mode as well (see e.g. 5.3.2 Bus Speed
Modes in JEDEC 84-B50). This results in a significant regression in
transfer speeds.

Fix the code to allow 4-bit and 8-bit widths even without high-speed
mode, as before.

Tested with a Zynq-7000 PicoZed 7020 board.

Fixes: 577fb13199b1 ("mmc: rework selection of bus speed mode")
Signed-off-by: Anssi Hannula 
Cc: 
Signed-off-by: Ulf Hansson

mmc: core: Restore parts of the polling policy when switch to HS/HS DDR

2017-01-16T15:17:42+00:00

Regressions for not being able to detect an eMMC HS DDR mode card has been
reported for the sdhci-esdhc-imx driver, but potentially other sdhci
variants may suffer from the similar problem.

The commit e173f8911f09 ("mmc: core: Update CMD13 polling policy when
switch to HS DDR mode"), is causing the problem. It seems that change moved
one step to far, regarding changing the host's timing before polling for a
busy card.

To fix this, let's move back to the behaviour when the host's timing is
updated after the polling, but before the switch status is fetched and
validated.

In cases when polling with CMD13, we keep validating the switch status at
each attempt. However, to align with the other card busy detections
mechanism, let's fetch and validate the switch status also after the host's
timing is updated.

Reported-by: Clemens Gruber 
Reported-by: Gary Bisson 
Fixes: e173f8911f09 ("mmc: core: Update CMD13 polling policy when switch..")
Cc: Shawn Lin 
Cc: Dong Aisheng 
Cc: Haibo Chen 
Signed-off-by: Ulf Hansson 
Tested-by: Clemens Gruber 
Tested-by: Jagan Teki 
Reviewed-by: Shawn Lin 
Tested-by: Haibo Chen 
Reviewed-by: Dong Aisheng

Replace with globally

2016-12-24T19:46:01+00:00

This was entirely automated, using the script by Al:

  PATT='^[[:blank:]]*#[[:blank:]]*include[[:blank:]]*'
  sed -i -e "s!$PATT!#include !" \
        $(git grep -l "$PATT"|grep -v ^include/linux/uaccess.h)

to do the replacement at the end of the merge window.

Requested-by: Al Viro 
Signed-off-by: Linus Torvalds

mmc: sd: Meet alignment requirements for raw_ssr DMA

2016-12-21T07:34:30+00:00

The mmc_read_ssr() function results in DMA to the raw_ssr member of
struct mmc_card, which is not guaranteed to be cache line aligned & thus
might not meet the requirements set out in Documentation/DMA-API.txt:

  Warnings:  Memory coherency operates at a granularity called the cache
  line width.  In order for memory mapped by this API to operate
  correctly, the mapped region must begin exactly on a cache line
  boundary and end exactly on one (to prevent two separately mapped
  regions from sharing a single cache line).  Since the cache line size
  may not be known at compile time, the API will not enforce this
  requirement.  Therefore, it is recommended that driver writers who
  don't take special care to determine the cache line size at run time
  only map virtual regions that begin and end on page boundaries (which
  are guaranteed also to be cache line boundaries).

On some systems where DMA is non-coherent this can lead to us losing
data that shares cache lines with the raw_ssr array.

Fix this by kmalloc'ing a temporary buffer to perform DMA into. kmalloc
will ensure the buffer is suitably aligned, allowing the DMA to be
performed without any loss of data.

Signed-off-by: Paul Burton 
Fixes: 5275a652d296 ("mmc: sd: Export SD Status via “ssr” device attribute")
Cc: 
Signed-off-by: Ulf Hansson

mmc: core: Further fix thread wake-up

2016-12-20T10:55:04+00:00

Commit e0097cf5f2f1 ("mmc: queue: Fix queue thread wake-up") did not go far
enough. mmc_wait_for_data_req_done() still contains some problems and can
be further simplified.  First it should not touch
context_info->is_waiting_last_req because that is a wake-up control used by
the owner of the context. Secondly, it should always return when one of its
wake-up conditions is met because, again, that is contolled by the owner of
the context.

While the current block driver does not have an issue, these problems were
exposed during testing of the Software Command Queue patches.

Fixes: e0097cf5f2f1 ("mmc: queue: Fix queue thread wake-up")
Signed-off-by: Adrian Hunter 
Tested-by: Harjani Ritesh 
Signed-off-by: Ulf Hansson

Merge tag 'mmc-v4.10-2' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc

2016-12-14T18:55:56+00:00

Pull another MMC update from Ulf Hansson:
 "Here's a second pull request for MMC for v4.10.

  As a matter of fact it's only one change that moves some mmc files
  around. I thought it was a good idea to get this into v4.10, as it
  gives us a nice and fresh base for v4.11. Summary:

  MMC core:

   - Move files from the card directory to the core directory to enable
     future clean-ups of the generic mmc header files and interfaces"

* tag 'mmc-v4.10-2' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc:
  mmc: block: Move files to core

mmc: block: Move files to core

2016-12-12T15:30:05+00:00

Once upon a time it made sense to keep the mmc block device driver and its
related code, in its own directory called card. Over time, more an more
functions/structures have become shared through generic mmc header files,
between the core and the card directory. In other words, the relationship
between them has become closer.

By sharing functions/structures via generic header files, it becomes easy
for outside users to abuse them. In a way to avoid that from happen, let's
move the files from card directory into the core directory, as it enables
us to move definitions of functions/structures into mmc core specific
header files.

Note, this is only the first step in providing a cleaner mmc interface for
outside users. Following changes will do the actual cleanup, as that is not
part of this change.

Signed-off-by: Ulf Hansson 
Reviewed-by: Linus Walleij

mmc: mmc: Introduce mmc_abort_tuning()

2016-12-05T13:16:22+00:00

If a tuning command times out, the card could still be processing it, which
will cause problems for recovery. The eMMC specification says that CMD12
can be used to stop CMD21, so add a function that does that.

Signed-off-by: Adrian Hunter 
Signed-off-by: Ulf Hansson

mmc: mmc: Relax checking for switch errors after HS200 switch

2016-12-05T13:15:46+00:00

The JEDEC specification indicates CMD13 can be used after a HS200 switch
to check for errors. However in practice some boards experience CRC errors
in the CMD13 response. Consequently, for HS200, CRC errors are not a
reliable way to know the switch failed. If there really is a problem, we
would expect tuning will fail and the result ends up the same. So change
the error condition to ignore CRC errors in that case.

Signed-off-by: Adrian Hunter 
Acked-by: Jaehoon Chung 
Reviewed-by: Shawn Lin 
Signed-off-by: Ulf Hansson

mmc: core: remove BUG_ONs from core.c

2016-12-05T09:31:11+00:00

BUG_ONs doesn't help anything except for stop the system from
running. If it occurs, it implies we should deploy proper error
handling for that. So this patch is gonna discard these meaningless
BUG_ONs and deploy error handling if needed.

Signed-off-by: Shawn Lin 
Signed-off-by: Ulf Hansson