Commit graph

22 commits

Author SHA1 Message Date
Adrian Hunter
f0c393e210 mmc: sdio: Use mmc_pre_req() / mmc_post_req()
SDHCI changed from using a tasklet to finish requests, to using an IRQ
thread i.e. commit c07a48c265 ("mmc: sdhci: Remove finish_tasklet").
Because this increased the latency to complete requests, a preparatory
change was made to complete the request from the IRQ handler if
possible i.e. commit 19d2f695f4 ("mmc: sdhci: Call mmc_request_done()
from IRQ handler if possible").  That alleviated the situation for MMC
block devices because the MMC block driver makes use of mmc_pre_req()
and mmc_post_req() so that successful requests are completed in the IRQ
handler and any DMA unmapping is handled separately in mmc_post_req().
However SDIO was still affected, and an example has been reported with
up to 20% degradation in performance.

Looking at SDIO I/O helper functions, sdio_io_rw_ext_helper() appeared
to be a possible candidate for making use of asynchronous requests
within its I/O loops, but analysis revealed that these loops almost
never iterate more than once, so the complexity of the change would not
be warrented.

Instead, mmc_pre_req() and mmc_post_req() are added before and after I/O
submission (mmc_wait_for_req) in mmc_io_rw_extended().  This still has
the potential benefit of reducing the duration of interrupt handlers, as
well as addressing the latency issue for SDHCI.  It also seems a more
reasonable solution than forcing drivers to do everything in the IRQ
handler.

Reported-by: Dmitry Osipenko <digetx@gmail.com>
Fixes: c07a48c265 ("mmc: sdhci: Remove finish_tasklet")
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Tested-by: Dmitry Osipenko <digetx@gmail.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20200903082007.18715-1-adrian.hunter@intel.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2020-09-07 08:57:44 +02:00
Thomas Gleixner
2874c5fd28 treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 152
Based on 1 normalized pattern(s):

  this program is free software you can redistribute it and or modify
  it under the terms of the gnu general public license as published by
  the free software foundation either version 2 of the license or at
  your option any later version

extracted by the scancode license scanner the SPDX license identifier

  GPL-2.0-or-later

has been chosen to replace the boilerplate/reference in 3029 file(s).

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Allison Randal <allison@lohutok.net>
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190527070032.746973796@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-05-30 11:26:32 -07:00
Heiner Kallweit
7aceaf566e mmc: sdio: improve mmc_io_rw_extended
Improve mmc_io_rw_extended a little:
- using DIV_ROUND_UP achieves the same but is better readable
- simplify code by using sg_set_buf
- simplify one statement by using -= operator

Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2017-04-24 21:41:42 +02:00
Masahiro Yamada
c7836d1593 mmc: use empty initializer list to zero-clear structures
In the MMC subsystem, we see such initializers that only clears the
first member explicitly.

For example,

  struct mmc_request mrq = {NULL};

sets the first member (.sbc) to NULL explicitly.  However, this is
an unstable form because we may insert a non-pointer member at the
top of the struct mmc_request in the future. (if we do so, the
compiler will spit warnings.)

So, using a designated initializer is preferred coding style.  The
expression above is equivalent to:

  struct mmc_request mrq = { .sbc = NULL };

Of course, this does not express our intention.  We want to fill
all struct members with zeros.  Please note struct members are
implicitly zero-cleared unless otherwise specified in the initializer.

After all, the most reasonable (and stable) form is:

  struct mmc_request mrq = {};

Do likewise for mmc_command, mmc_data as well.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2017-02-13 13:19:54 +01:00
Shawn Lin
923dff8737 mmc: sdio: deploy error handling instead of triggering BUG_ON
When using mmc_io_rw_extended, it's intent to avoid null
pointer of card and invalid func number. But actually it
didn't prevent that as the seg_size already use the card.
Currently the wrapper function sdio_io_rw_ext_helper already
use card before calling mmc_io_rw_extended, so we should move
this check to there. As to the func number, it was token from
'(ocr & 0x70000000) >> 28' which should be enough to guarantee
that it won't be larger than 7. But we should prevent the
caller like wifi drivers modify this value. So let's move this
check into sdio_io_rw_ext_helper either.

Also we remove the BUG_ON for mmc_send_io_op_cond since all
possible paths calling this function are protected by checking
the arguments in advance. After deploying these changes, we
could not see any panic within SDIO API even if func drivers
abuse the SDIO func APIs.

Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-09-26 21:31:15 +02:00
Masahiro Yamada
0899e74193 mmc: remove unnecessary assignment statements before return
Variable assignment just before return is redundant.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-02-29 11:02:47 +01:00
Kyoungil Kim
968a64ea63 mmc: sdio: Use multiple scatter/gather list
Before this patch, we always used only single sg entry for SDIO transfer.
This patch switches to using multiple sg entries. In the case of dwmci,
it supports only up to 4KB size per single sg entry. So if we want to
transfer more than 4KB, we should send more than 1 command.

When we tested before applying this patch, it took around 335 us for
5K(5120) bytes transfer with dwmci controller. After applying this patch,
it takes 242 us for 5K bytes. So this patch makes around 38% performance
improvement for 5K bytes transfer. If the transfer size is bigger, then
the performance improvement ratio will be increased.

Signed-off-by: Kyoungil Kim <ki0351.kim@samsung.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
2012-12-06 13:54:43 -05:00
Stefan Nilsson XK
052d81da6e mmc: sdio: Fix to support any block size optimally
This patch allows any block size to be set on the SDIO link,
and still have an arbitrary sized packet (adjusted in size by
using sdio_align_size) transferred in an optimal way
(preferably one transfer).

Previously if the block size was larger than the default of
512 bytes and the transfer size was exactly one block size
(possibly thanks to using sdio_align_size to get an optimal
transfer size), it was sent as a number of byte transfers instead
of one block transfer. Also if the number of blocks was
(max_blocks * N) + 1, the tranfer would be conducted with a number
of blocks and finished off with a number of byte transfers.

When doing this change it was also possible to break out the quirk
for broken byte mode in a much cleaner way, and collect the logic of
when to do byte or block transfer in one function instead of two.

Signed-off-by: Stefan Nilsson XK <stefan.xk.nilsson@stericsson.com>
Signed-off-by: Ulf Hansson <ulf.hansson@stericsson.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
2012-01-11 23:58:40 -05:00
Stefan Nilsson XK
9a0da648ff mmc: sdio: Workaround for dev with broken CMD53
Adds a quirk which can be turned on for SDIO devices that do not support
512 byte requests in byte mode during CMD53. These requests will always
be sent in block mode instead.

This patch also enables this quirk for ST-Ericsson CW1200 WLAN device.

Signed-off-by: Stefan Nilsson XK <stefan.xk.nilsson@stericsson.com>
Signed-off-by: Ulf HANSSON <ulf.hansson@stericsson.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
2011-10-26 16:32:02 -04:00
Venkatraman S
ad5fd97288 mmc: fix integer assignments to pointer
Fix the sparse warning output "warning: Using plain integer as NULL pointer"

Signed-off-by: Venkatraman S <svenkatr@ti.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
2011-10-26 15:43:35 -04:00
Chris Ball
24f5b53ba0 mmc: initialize struct mmc_request at declaration time
Converts from:
	struct mmc_request mrq;
	memset(&mrq, 0, sizeof(struct mmc_request));

to:
	struct mmc_request mrq = {0};

because it's shorter, as performant, and easier to work out whether
initialization has happened.

Signed-off-by: Chris Ball <cjb@laptop.org>
2011-05-24 21:02:01 -04:00
Chris Ball
a61ad2b49b mmc: initialize struct mmc_data at declaration time
Converts from:
	struct mmc_data data;
	memset(&data, 0, sizeof(struct mmc_data));

to:
	struct mmc_data data = {0};

because it's shorter, as performant, and easier to work out whether
initialization has happened.

Signed-off-by: Chris Ball <cjb@laptop.org>
2011-05-24 21:01:56 -04:00
Chris Ball
1278dba167 mmc: initialize struct mmc_command at declaration time
Converts from:
	struct mmc_command cmd;
	memset(&cmd, 0, sizeof(struct mmc_command));

to:
	struct mmc_command cmd = {0};

because it's shorter, as performant, and easier to work out whether
initialization has happened.

Signed-off-by: Chris Ball <cjb@laptop.org>
2011-05-24 21:01:52 -04:00
Albert Herranz
516a824222 sdio: recognize io card without powercycle
SDIO Simplified Specification V2.00 states that it is strongly recommended
that the host executes either a power reset or issues a CMD52 (I/O Reset)
to re-initialize an I/O only card or the I/O portion of a combo card.
Additionally, the CMD52 must be issued first because it cannot be issued
after a CMD0.

With this patch the Nintendo Wii SDIO-based WLAN card is detected after a
system reset, without requiring a complete system powercycle.

Signed-off-by: Albert Herranz <albert_herranz@yahoo.es>
Cc: <linux-mmc@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-03-12 15:52:28 -08:00
Pierre Ossman
be6f19fc24 sdio: check that addresses are within the address space
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
2009-03-24 21:30:00 +01:00
Adrian Bunk
e70aa3fac1 mmc: sdio_ops.c should #include "sdio_ops.h"
Every file should include the headers containing the externs for its
global functions.

Signed-off-by: Adrian Bunk <bunk@kernel.org>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
2008-04-18 20:05:33 +02:00
Adrian Bunk
87ae9afdca cleanup asm/scatterlist.h includes
Not architecture specific code should not #include <asm/scatterlist.h>.

This patch therefore either replaces them with
#include <linux/scatterlist.h> or simply removes them if they were
unused.

Signed-off-by: Adrian Bunk <bunk@kernel.org>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
2007-11-02 08:47:06 +01:00
David Brownell
af51715079 MMC core learns about SPI
Teach the MMC/SD/SDIO core about using SPI mode.

 - Use mmc_host_is_spi() so enumeration works through SPI signaling
   and protocols, not just the native versions.

 - Provide the SPI response type flags with each request issued,
   including requests from the new lock/unlock code.

 - Understand that cmd->resp[0] and mmc_get_status() results for SPI
   return different values than for "native" MMC/SD protocol; this
   affects resetting, checking card lock status, and some others.

 - Understand that some commands act a bit differently ... notably:
     * OP_COND command doesn't return the OCR
     * APP_CMD status doesn't have an R1_APP_CMD analogue

Those changes required some new and updated primitives:

 - Provide utilities to access two SPI-only requests, and one
   request that wasn't previously needed:
     * mmc_spi_read_ocr() ... SPI only
     * mmc_spi_set_crc() ... SPI only (override by module parm)
     * mmc_send_cid() ... for use without broadcast mode

 - Updated internal routines:
     * Previous mmc_send_csd() modified into mmc_send_cxd_native();
       it uses native "R2" responses, which include 16 bytes of data.
     * Previous mmc_send_ext_csd() becomes new mmc_send_cxd_data()
       helper for command-and-data access
     * Bugfix to that mmc_send_cxd_data() code:  dma-to-stack is
       unsafe/nonportable, so kmalloc a bounce buffer instead.

 - Modified mmc_send_ext_csd() now uses mmc_send_cxd_data() helper

 - Modified mmc_send_csd(), and new mmc_spi_send_cid(), routines use
   those helper routines based on whether they're native or SPI

The newest categories of cards supported by the MMC stack aren't expected
to work yet with SPI:  MMC or SD cards with over 4GB data, and SDIO.
All those cards support SPI mode, so eventually they should work too.

Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
2007-09-23 21:51:30 +02:00
David Vrabel
eb65946892 sdio: extend sdio_readsb() and friends to handle any length of buffer
Extend sdio_readsb(), sdio_writesb(), sdio_memcpy_fromio(), and
sdio_memcpy_toio() to handle any length of buffer by splitting the transfer
into several IO_RW_EXTENDED commands. Typically, a transfer would be split
into a single block mode transfer followed by a byte mode transfer for the
remainder but we also handle lack of block mode support and the block size
being greater than 512 (the maximum byte mode transfer size).

host->max_seg_size <= host->max_req_size so there's no need to check both
when determining the maximum data size for a single command.

Signed-off-by: David Vrabel <david.vrabel@csr.com>
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
2007-09-23 21:21:32 +02:00
Pierre Ossman
112c9db91e sdio: support IO_RW_EXTENDED
Support the multi-byte transfer operation, including handlers for
common operations like writel()/readl().

Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
2007-09-23 21:09:34 +02:00
Pierre Ossman
b2bcc798bb mmc: implement SDIO IO_RW_DIRECT operation
Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
2007-09-23 19:42:37 +02:00
Pierre Ossman
5c4e6f1301 mmc: detect SDIO cards
Really basic init sequence for SDIO cards.

Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
2007-09-23 19:40:07 +02:00