1. 22 12月, 2015 4 次提交
    • A
      mmc: sdhci: 64-bit DMA actually has 4-byte alignment · 04a5ae6f
      Adrian Hunter 提交于
      The version 3.00 SDHCI spec. was a bit unclear about the
      required data alignment for 64-bit DMA, whereas the version
      4.10 spec. uses different language and indicates that only
      4-byte alignment is required rather than the 8-byte alignment
      currently implemented.  That make no difference to SD and EMMC
      which invariably transfer data in sector-aligned blocks.
      However with SDIO, it results in using more DMA descriptors
      than necessary.  Theoretically that slows DMA slightly although
      DMA is not the limiting factor for throughput, so there is no
      discernable impact on performance.  Nevertheless, the driver
      should follw the spec unless there is good reason not to, so
      this patch corrects the alignment criterion.
      
      There is a more complicated criterion for the DMA descriptor
      table itself.  However the table is allocated by dma_alloc_coherent()
      which allocates pages (i.e. aligned to a page boundary).
      For simplicity just check it is 8-byte aligned, but add a comment
      that some Intel controllers actually require 8-byte alignment
      even when using 32-bit DMA.
      Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      04a5ae6f
    • A
      mmc: sdhci: Fix DMA descriptor with zero data length · 347ea32d
      Adrian Hunter 提交于
      SDHCI has built-in DMA called ADMA2.  ADMA2 uses a descriptor
      table to define DMA scatter-gather.  Each desciptor can specify
      a data length up to 65536 bytes, however the length field is
      only 16-bits so zero means 65536.  Consequently, putting zero
      when the size is zero must not be allowed.  This patch fixes
      one case where zero data length could be set inadvertently.
      
      The problem happens because unaligned data gets split and the
      code did not consider that the remaining aligned portion might
      be zero length.  That case really only happens for SDIO because
      SD and eMMC cards transfer blocks that are invariably sector-
      aligned.  For SDIO, access to function registers is done by
      data transfer (CMD53) when the register is bigger than 1 byte.
      Generally registers are 4 bytes but 2-byte registers are possible.
      So DMA of 4 bytes or less can happen.  When 32-bit DMA is used,
      the data alignment must be 4, so 4-byte transfers won't casue a
      problem, but a 2-byte transfer could.  However with the introduction
      of 64-bit DMA, the data alignment for 64-bit DMA was made 8 bytes,
      so all 4-byte transfers not on 8-byte boundaries get "split" into
      a 4-byte chunk and a 0-byte chunk, thereby hitting the bug.
      
      In fact, a closer look at the SDHCI specs indicates that only the
      descriptor table requires 8-byte alignment for 64-bit DMA.  That
      will be dealt with in a separate patch, but the potential for a
      2-byte access remains, so this fix is needed anyway.
      Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
      Cc: stable@vger.kernel.org # v3.19+
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      347ea32d
    • A
      mmc: sdhci: Do not BUG on invalid vdd · 9d5de93f
      Adrian Hunter 提交于
      The driver may not be able to set the power correctly but that
      is not a reason to BUG().
      Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
      Reviewed-by: NVenu Byravarasu <vbyravarasu@nvidia.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      9d5de93f
    • M
      mmc: sdhci: Fix strings broken across multiple lines · 2e4456f0
      Marek Vasut 提交于
      This is a trivial patch which fixes printed strings split across two
      or more lines in the source. I tried to grep for some error output*,
      but I couldn't find it easily because it was broken across multiple
      lines. This patch makes my life easier.
      
      * in particular "Timeout waiting for hardware interrupt."
      Signed-off-by: NMarek Vasut <marex@denx.de>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      2e4456f0
  2. 26 10月, 2015 2 次提交
  3. 09 10月, 2015 1 次提交
  4. 27 8月, 2015 2 次提交
    • J
      mmc: sdhci: also get preset value and driver type for MMC_DDR52 · 0dafa60e
      Jisheng Zhang 提交于
      commit bb8175a8 ("mmc: sdhci: clarify DDR timing mode between
      SD-UHS and eMMC") added MMC_DDR52 as eMMC's DDR mode to be
      distinguished from SD-UHS, but it missed setting driver type for
      MMC_DDR52 timing mode.
      
      So sometimes we get the following error on Marvell BG2Q DMP board:
      
      [    1.559598] mmcblk0: error -84 transferring data, sector 0, nr 8, cmd
      response 0x900, card status 0xb00
      [    1.569314] mmcblk0: retrying using single block read
      [    1.575676] mmcblk0: error -84 transferring data, sector 2, nr 6, cmd
      response 0x900, card status 0x0
      [    1.585202] blk_update_request: I/O error, dev mmcblk0, sector 2
      [    1.591818] mmcblk0: error -84 transferring data, sector 3, nr 5, cmd
      response 0x900, card status 0x0
      [    1.601341] blk_update_request: I/O error, dev mmcblk0, sector 3
      
      This patches fixes this by adding the missing driver type setting.
      
      Fixes: bb8175a8 ("mmc: sdhci: clarify DDR timing mode ...")
      Signed-off-by: NJisheng Zhang <jszhang@marvell.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      0dafa60e
    • H
      mmc: sdhci: fix dma memory leak in sdhci_pre_req() · d31911b9
      Haibo Chen 提交于
      Currently one mrq->data maybe execute dma_map_sg() twice
      when mmc subsystem prepare over one new request, and the
      following log show up:
      	sdhci[sdhci_pre_dma_transfer] invalid cookie: 24, next-cookie 25
      
      In this condition, mrq->date map a dma-memory(1) in sdhci_pre_req
      for the first time, and map another dma-memory(2) in sdhci_prepare_data
      for the second time. But driver only unmap the dma-memory(2), and
      dma-memory(1) never unmapped, which cause the dma memory leak issue.
      
      This patch use another method to map the dma memory for the mrq->data
      which can fix this dma memory leak issue.
      
      Fixes: 348487cb ("mmc: sdhci: use pipeline mmc requests to improve performance")
      Reported-and-tested-by: NJiri Slaby <jslaby@suse.cz>
      Signed-off-by: NHaibo Chen <haibo.chen@freescale.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      d31911b9
  5. 24 8月, 2015 1 次提交
  6. 17 8月, 2015 4 次提交
  7. 24 7月, 2015 2 次提交
  8. 16 6月, 2015 1 次提交
    • J
      mmc: sdhci: fix low memory corruption · 62a7f368
      Jiri Slaby 提交于
      When dma mapping (dma_map_sg) fails in sdhci_pre_dma_transfer, -EINVAL
      is returned. There are 3 callers of sdhci_pre_dma_transfer:
      * sdhci_pre_req and sdhci_adma_table_pre: handle negative return
      * sdhci_prepare_data: handles 0 (error) and "else" (good) only
      
      sdhci_prepare_data is therefore broken. When it receives -EINVAL from
      sdhci_pre_dma_transfer, it assumes 1 sg mapping was mapped. Later,
      this non-existent mapping with address 0 is kmap'ped and written to:
      Corrupted low memory at ffff880000001000 (1000 phys) = 22b7d67df2f6d1cf
      Corrupted low memory at ffff880000001008 (1008 phys) = 63848a5216b7dd95
      Corrupted low memory at ffff880000001010 (1010 phys) = 330eb7ddef39e427
      Corrupted low memory at ffff880000001018 (1018 phys) = 8017ac7295039bda
      Corrupted low memory at ffff880000001020 (1020 phys) = 8ce039eac119074f
      ...
      
      So teach sdhci_prepare_data to understand negative return values from
      sdhci_pre_dma_transfer and disable DMA in that case, as well as for
      zero.
      
      It was introduced in 348487cb (mmc:
      sdhci: use pipeline mmc requests to improve performance). The commit
      seems to be suspicious also by assigning host->sg_count both in
      sdhci_pre_dma_transfer and sdhci_adma_table_pre.
      Signed-off-by: NJiri Slaby <jslaby@suse.cz>
      Cc: stable@vger.kernel.org # 4.0+
      Fixes: 348487cb
      Cc: Ulf Hansson <ulf.hansson@linaro.org>
      Cc: Haibo Chen <haibo.chen@freescale.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      62a7f368
  9. 08 6月, 2015 1 次提交
    • U
      mmc: sdhci: Restore behavior while creating OCR mask · 5fd26c7e
      Ulf Hansson 提交于
      Commit 3a48edc4 ("mmc: sdhci: Use mmc core regulator infrastucture")
      changed the behavior for how to assign the ocr_avail mask for the mmc
      host. More precisely it started to mask the bits instead of assigning
      them.
      
      Restore the behavior, but also make it clear that an OCR mask created
      from an external regulator overrides the other ones. The OCR mask is
      determined by one of the following with this priority:
      
      1. Supported ranges of external regulator if one supplies VDD
      2. Host OCR mask if set by the driver (based on DT properties)
      3. The capabilities reported by the controller itself
      
      Fixes: 3a48edc4 ("mmc: sdhci: Use mmc core regulator infrastucture")
      Cc: Tim Kryger <tim.kryger@gmail.com>
      Reported-by: NYangbo Lu <yangbo.lu@freescale.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      Reviewed-by: NTim Kryger <tim.kryger@gmail.com>
      5fd26c7e
  10. 01 6月, 2015 4 次提交
  11. 23 3月, 2015 3 次提交
  12. 29 1月, 2015 1 次提交
  13. 20 1月, 2015 3 次提交
  14. 19 1月, 2015 4 次提交
    • M
      mmc: host: sdhci: Added a space before ( · c63705e1
      Mohammad Jamal 提交于
      This patch solves the coding style issue by adding a space
      before (
      Signed-off-by: NMohammad Jamal <md.jamalmohiuddin@gmail.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      c63705e1
    • A
      mmc: sdhci: Always init buf_ready_int · 250fb7b4
      Adrian Hunter 提交于
      There is no point making the initialization
      of buf_ready_int conditional on host version.
      Simplify by just doing it always. Note that
      the other conditional initializations will be
      removed when the new way of doing re-tuning
      is taken into use.
      Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      250fb7b4
    • H
      mmc: sdhci: use pipeline mmc requests to improve performance · 348487cb
      Haibo Chen 提交于
      This patch is based on the patches by Per Forlin, Tony Lin and Ryan QIAN.
      
      This patch complete the API 'post_req' and 'pre_req' in sdhci host side,
      
      Test Env:
      1. i.MX6Q-SABREAUTO board, CPU @ 996MHz, use ADMA in uSDHC controller.
      2. Test command:
      		$ echo 1 > /proc/sys/vm/drop_caches
      	write to sd card:
      		$ dd if=/dev/zero of=/dev/mmcblk0 bs=1M count=2000 conv=fsync
      	read the sd card:
      		$ dd if=/dev/mmcblk0 of=/dev/null bs=1M count=2000
      
      3. TOSHIBA 16GB SD3.0 card, running at 4 bit, SDR104 @ 198MHZ
      	Performance with and without this patch:
            -------------------------------------------------
      	  |                    | read speed | write speed |
      	  |------------------------------------------------
      	  | with this patch    | ~76.7 MB/s |  ~23.3 MB/s |
      	  |------------------------------------------------
      	  |without this patch  | ~60.5 MB/s |  ~22.5 MB/s |
      	  -------------------------------------------------
      
      4. SanDisk 8GB SD3.0 card, running at 4 bit, DDR50 @ 50MHZ
      	Performance with and without this patch:
            -------------------------------------------------
      	  |                    | read speed | write speed |
      	  |------------------------------------------------
      	  | with this patch    | ~40.5 MB/s |  ~15.6 MB/s |
      	  |------------------------------------------------
      	  |without this patch  | ~36.1 MB/s |  ~14.1 MB/s |
      	  -------------------------------------------------
      
      5. Kingston 8GB SD2.0 card, running at 4 bit, High-speed @ 50MHZ
      	Performance with and without this patch:
            -------------------------------------------------
      	  |                    | read speed | write speed |
      	  |------------------------------------------------
      	  | with this patch    | ~22.7 MB/s |  ~8.2 MB/s  |
      	  |------------------------------------------------
      	  |without this patch  | ~21.3 MB/s |  ~8.0 MB/s  |
      	  -------------------------------------------------
      
      6. About eMMC, Sandisk 8GB eMMC on i.MX6DL-sabresd board, CPU @ 792MHZ,
         eMMC running at 8 bit, DDR52 @ 52MHZ.
      	Performance with and without this patch:
            -------------------------------------------------
      	  |                    | read speed | write speed |
      	  |------------------------------------------------
      	  | with this patch    | ~37.3 MB/s |  ~10.5 MB/s |
      	  |------------------------------------------------
      	  |without this patch  | ~33.4 MB/s |  ~10.5 MB/s |
      	  -------------------------------------------------
      Signed-off-by: NHaibo Chen <haibo.chen@freescale.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      348487cb
    • A
      mmc: sdhci: Remove redundant ADMA page boundary warnings · 2070d805
      Andrew Gabbasov 提交于
      The bounce buffer, used for misaligned bytes for ADMA access,
      resides wholly within the (align_sz)-aligned word, just by construction.
      The page addresses are aligned to (align_sz), either for 4 or 8 bytes
      alignment, so that the aligned word resides wholly within a single page
      and can't cross the page boundary. So, the bounce buffer can't cross
      the page boundary too. That's why the warnings are never hit, and can
      be safely removed.
      Signed-off-by: NAndrew Gabbasov <andrew_gabbasov@mentor.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      2070d805
  15. 14 1月, 2015 1 次提交
  16. 12 1月, 2015 5 次提交
    • K
      mmc: sdhci: Fix sleep in atomic after inserting SD card · 2836766a
      Krzysztof Kozlowski 提交于
      Sleep in atomic context happened on Trats2 board after inserting or
      removing SD card because mmc_gpio_get_cd() was called under spin lock.
      
      Fix this by moving card detection earlier, before acquiring spin lock.
      The mmc_gpio_get_cd() call does not have to be protected by spin lock
      because it does not access any sdhci internal data.
      The sdhci_do_get_cd() call access host flags (SDHCI_DEVICE_DEAD). After
      moving it out side of spin lock it could theoretically race with driver
      removal but still there is no actual protection against manual card
      eject.
      
      Dmesg after inserting SD card:
      [   41.663414] BUG: sleeping function called from invalid context at drivers/gpio/gpiolib.c:1511
      [   41.670469] in_atomic(): 1, irqs_disabled(): 128, pid: 30, name: kworker/u8:1
      [   41.677580] INFO: lockdep is turned off.
      [   41.681486] irq event stamp: 61972
      [   41.684872] hardirqs last  enabled at (61971): [<c0490ee0>] _raw_spin_unlock_irq+0x24/0x5c
      [   41.693118] hardirqs last disabled at (61972): [<c04907ac>] _raw_spin_lock_irq+0x18/0x54
      [   41.701190] softirqs last  enabled at (61648): [<c0026fd4>] __do_softirq+0x234/0x2c8
      [   41.708914] softirqs last disabled at (61631): [<c00273a0>] irq_exit+0xd0/0x114
      [   41.716206] Preemption disabled at:[<  (null)>]   (null)
      [   41.721500]
      [   41.722985] CPU: 3 PID: 30 Comm: kworker/u8:1 Tainted: G        W      3.18.0-rc5-next-20141121 #883
      [   41.732111] Workqueue: kmmcd mmc_rescan
      [   41.735945] [<c0014d2c>] (unwind_backtrace) from [<c0011c80>] (show_stack+0x10/0x14)
      [   41.743661] [<c0011c80>] (show_stack) from [<c0489d14>] (dump_stack+0x70/0xbc)
      [   41.750867] [<c0489d14>] (dump_stack) from [<c0228b74>] (gpiod_get_raw_value_cansleep+0x18/0x30)
      [   41.759628] [<c0228b74>] (gpiod_get_raw_value_cansleep) from [<c03646e8>] (mmc_gpio_get_cd+0x38/0x58)
      [   41.768821] [<c03646e8>] (mmc_gpio_get_cd) from [<c036d378>] (sdhci_request+0x50/0x1a4)
      [   41.776808] [<c036d378>] (sdhci_request) from [<c0357934>] (mmc_start_request+0x138/0x268)
      [   41.785051] [<c0357934>] (mmc_start_request) from [<c0357cc8>] (mmc_wait_for_req+0x58/0x1a0)
      [   41.793469] [<c0357cc8>] (mmc_wait_for_req) from [<c0357e68>] (mmc_wait_for_cmd+0x58/0x78)
      [   41.801714] [<c0357e68>] (mmc_wait_for_cmd) from [<c0361c00>] (mmc_io_rw_direct_host+0x98/0x124)
      [   41.810480] [<c0361c00>] (mmc_io_rw_direct_host) from [<c03620f8>] (sdio_reset+0x2c/0x64)
      [   41.818641] [<c03620f8>] (sdio_reset) from [<c035a3d8>] (mmc_rescan+0x254/0x2e4)
      [   41.826028] [<c035a3d8>] (mmc_rescan) from [<c003a0e0>] (process_one_work+0x180/0x3f4)
      [   41.833920] [<c003a0e0>] (process_one_work) from [<c003a3bc>] (worker_thread+0x34/0x4b0)
      [   41.841991] [<c003a3bc>] (worker_thread) from [<c003fed8>] (kthread+0xe4/0x104)
      [   41.849285] [<c003fed8>] (kthread) from [<c000f268>] (ret_from_fork+0x14/0x2c)
      [   42.038276] mmc0: new high speed SDHC card at address 1234
      Signed-off-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
      Fixes: 94144a46 ("mmc: sdhci: add get_cd() implementation")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      2836766a
    • A
      mmc: sdhci: Disable re-tuning for HS400 · b5540ce1
      Adrian Hunter 提交于
      Re-tuning for HS400 mode must be done in HS200
      mode. Currently there is no support for that.
      That needs to be reflected in the code.
      Specifically, if tuning is executed in HS400 mode
      then return an error, and do not start the
      tuning timer if HS200 tuning is being done prior
      to switching to HS400.
      
      Note that periodic re-tuning is not expected
      to be needed for HS400 but re-tuning is still
      needed after the host controller has lost power.
      In the case of suspend/resume that is not necessary
      because the card is fully re-initialised. That
      just leaves runtime suspend/resume with no support
      for HS400 re-tuning.
      Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      b5540ce1
    • A
      mmc: sdhci: Simplify use of tuning timer · 38e40bf5
      Adrian Hunter 提交于
      The tuning timer is always used if the tuning mode
      is 1 and there is a tuning count, irrespective of
      whether this is the first call, or any subsequent
      call. Consequently the logic to start the timer
      can be simplified.
      Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
      Reviewed-by: NAaron Lu <aaron.lu@intel.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      38e40bf5
    • A
      mmc: sdhci: Add out_unlock to sdhci_execute_tuning · d519c863
      Adrian Hunter 提交于
      A 'goto' can be used to save duplicating unlocking
      and returning.
      Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
      Reviewed-by: NAaron Lu <aaron.lu@intel.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      d519c863
    • A
      mmc: sdhci: Tuning should not change max_blk_count · ac00531d
      Adrian Hunter 提交于
      Re-tuning requires that the maximum data length
      is limited to 4MiB. The code currently changes
      max_blk_count in an attempt to achieve that.
      This is wrong because max_blk_count is a different
      limit, but it is also un-necessary because
      max_req_size is 512KiB anyway. Consequently, the
      changes to max_blk_count are removed and the
      comment for max_req_size adjusted accordingly.
      The comment is also tweaked to show that the 512KiB
      limit is a SDMA limit not an ADMA limit.
      Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
      Reviewed-by: NAaron Lu <aaron.lu@intel.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      ac00531d
  17. 05 12月, 2014 1 次提交