1. 23 3月, 2015 1 次提交
  2. 20 1月, 2015 2 次提交
  3. 19 1月, 2015 1 次提交
    • 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
  4. 12 1月, 2015 1 次提交
    • 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
  5. 26 11月, 2014 2 次提交
  6. 10 11月, 2014 4 次提交
  7. 03 10月, 2014 1 次提交
  8. 09 9月, 2014 1 次提交
    • C
      mmc: sdhci: handle busy-end interrupt during command · e99783a4
      Chanho Min 提交于
      It is fully legal for a controller to start handling busy-end interrupt
      before it has signaled that the command has completed. So make sure
      we do things in the proper order, Or it results that command interrupt
      is ignored so it can cause unexpected operations. This is founded at some
      toshiba emmc with the bellow warning.
      
      "mmc0: Got command interrupt 0x00000001 even though
      no command operation was in progress."
      
      This issue has been also reported by Youssef TRIKI:
      It is not specific to Toshiba devices, and happens with eMMC devices
      as well as SD card which support Auto-CMD12 rather than CMD23.
      
      Also, similar patch is submitted by:
      Gwendal Grignou <gwendal@chromium.org>
      
      Changes since v1:
       Fixed conflict with the next of git.linaro.org/people/ulf.hansson/mmc.git
       and Tested if issue is fixed again.
      Signed-off-by: NHankyung Yu <hankyung.yu@lge.com>
      Signed-off-by: NChanho Min <chanho.min@lge.com>
      Tested-by: NYoussef TRIKI <youssef.triki@st.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      e99783a4
  9. 09 7月, 2014 1 次提交
  10. 22 5月, 2014 7 次提交
  11. 23 2月, 2014 1 次提交
  12. 14 1月, 2014 1 次提交
  13. 26 8月, 2013 1 次提交
  14. 06 7月, 2013 1 次提交
    • O
      mmc: esdhc: Fix bug when writing to SDHCI_HOST_CONTROL register · dcaff04d
      Oded Gabbay 提交于
      The P2020 has a non-standard implementation of the SDHCI_HOST_CONTROL
      register. This patch adds a QUIRK in the SDHCI header to signal that
      a host controller has a non-standard SDHCI_HOST_CONTROL register. The
      patch adds a check to the function esdhc_writeb in file
      sdhci-of-esdhc.c, where it checks if the write is done to the
      SDHCI_HOST_CONTROL register and th host has the above mentioned QUIRK,
      then the function simply returns instead of writing to the register.
      The patch also detects if the processor is P2020 (by looking in dev
      tree) and if so, adds the QUIRK to the host->quirk2
      Signed-off-by: NOded Gabbay <ogabbay@advaoptical.com>
      Reviewed-by: NAnton Vorontsov <anton@enomsg.org>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      dcaff04d
  15. 28 6月, 2013 1 次提交
  16. 27 5月, 2013 1 次提交
  17. 25 2月, 2013 1 次提交
    • K
      mmc: sdhci: enhance preset value function · 52983382
      Kevin Liu 提交于
      4d55c5a1 ("mmc: sdhci: enable preset value after uhs initialization")
      added preset value support and enabled it by default during sd card init.
      
      Below are the enhancements introduced by this patch:
      
      1. In current code, preset value is enabled after setting clock finished,
      which means the clock is manually set by driver firstly and then suddenly
      switched to preset value at this point. So the first setting is useless
      and unnecessary. What's more, the first clock setting may differ from the
      preset one.  The better way is enable preset value just after switch to
      UHS mode so the preset value can take effect immediately. So move preset
      value enable from mmc_sd_init_card to sdhci_set_ios which will be called
      during set timing.
      
      2. In current code, preset value is disabled at the beginning of
      mmc_attach_sd.  It's too late since low freq (400khz) should be set in
      mmc_power_up.  So move preset value disable to sdhci_set_ios which will
      be called during power up.
      
      3. host->clock and ios->drv_type should also be updated according to the
      preset value if it's enabled. Current code missed this.
      
      4. This patch also introduce a quirk to disable preset value in case
      preset value doesn't work.
      
      This patch has been verified on sdhci-pxav3 platform with both preset
      enabled and disabled.
      Signed-off-by: NKevin Liu <kliu5@marvell.com>
      Reviewed-by: NUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      52983382
  18. 07 12月, 2012 2 次提交
    • D
      mmc: sdhci: add quirk for lack of 1.8v support · 6a66180a
      Daniel Drake 提交于
      The OLPC XO-1.75 laptop includes a SDHCI controller which is 1.8v
      capable, and it truthfully reports so in its capabilities. This
      alternate voltage is used for driving new "UHS-I" SD cards at their
      full speed.
      
      However, what the controller doesn't know is that the motherboard
      physically doesn't have a 1.8v supply available.
      
      Add a quirk so that systems such as this one can override disable
      1.8v support, adding support for UHS-I cards (by running them at
      3.3v).
      
      This avoids a problem where the system would first try to run the
      card at 1.8v, fail, and then not be able to fully reset the card
      to retry at the normal 3.3v voltage.
      
      This is more appropriate than using the MISSING_CAPS quirk, which
      is intended for cases where the SDHCI controller is actually lying
      about its capabilities, and would force us to somehow override both
      caps words from another source.
      Signed-off-by: NDaniel Drake <dsd@laptop.org>
      Reviewed-by: NPhilip Rakity <prakity@nvidia.com>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      6a66180a
    • L
      mmc: Standardise capability type · 5f1a4dd0
      Lee Jones 提交于
      There are discrepancies with regards to how MMC capabilities
      are carried throughout the subsystem. Let's standardise them
      to eliminate any confusion.
      Signed-off-by: NLee Jones <lee.jones@linaro.org>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      5f1a4dd0
  19. 08 11月, 2012 1 次提交
  20. 05 9月, 2012 1 次提交
  21. 23 7月, 2012 2 次提交
    • A
      mmc: sdhci: Introduce new flag SDHCI_USING_RETUNING_TIMER · 973905fe
      Aaron Lu 提交于
      Add a new flag of SDHCI_USING_RETUNING_TIMER to represent if the host
      is using a retuning timer for the card inserted.
      
      This flag is set when the host does tuning the first time for the card
      and the host's retuning mode is 1. This flag is used afterwards whenever
      needs to decide if the host is currently using a retuning timer.
      
      This flag is cleared when the card is removed in sdhci_reinit.
      
      The set/clear of the flag and the start/stop of the retuning timer is
      associated with the card's init/remove time, so there is no need to
      touch it when the host is to be removed as at that time the card should
      have already been removed.
      Signed-off-by: NAaron Lu <aaron.lu@amd.com>
      Reviewed-by: NGirish K S <girish.shivananjappa@linaro.org>
      Reviewed-by: NPhilip Rakity <prakity@marvell.com>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      973905fe
    • P
      mmc: sdhci: Allow caps[1] to be set via SDHCI_QUIRK_MISSING_CAPS · bd6a8c30
      Philip Rakity 提交于
      Currently only the capability_0 register can be set if
      SDHCI_QUIRK_MISSING_CAPS is defined.  This is a problem when
      the capability_1 register also needs changing.  Use the quirk
      SDHCI_QUIRK_MISSING_CAPS to allow both registers to be set.
      
      Redefining caps[1] is useful when the board design does not
      support 1.8v vccq so UHS modes are not available.  The code that
      calls sdhci_add_host can then detect this condition and adjust
      the caps so the UHS mode will not be attempted on UHS cards.
      Signed-off-by: NPhilip Rakity <prakity@marvell.com>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      bd6a8c30
  22. 06 4月, 2012 2 次提交
  23. 28 3月, 2012 1 次提交
  24. 13 1月, 2012 1 次提交
  25. 12 1月, 2012 1 次提交
  26. 27 10月, 2011 1 次提交
    • A
      mmc: sdhci-pci: add runtime pm support · 66fd8ad5
      Adrian Hunter 提交于
      Ths patch allows runtime PM for sdhci-pci, runtime suspending after
      inactivity of 50ms and ensuring runtime resume before SDHC registers
      are accessed.  During runtime suspend, interrupts are masked.
      The host controller state is restored at runtime resume.
      
      For Medfield, the host controller's card detect mechanism is
      supplanted by an always-on GPIO which provides for card detect wake-up.
      Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      66fd8ad5