1. 25 5月, 2011 5 次提交
    • A
      mmc: sd: add support for uhs bus speed mode selection · 49c468fc
      Arindam Nath 提交于
      This patch adds support for setting UHS-I bus speed mode during UHS-I
      initialization procedure. Since both the host and card can support
      more than one bus speed, we select the highest speed based on both of
      their capabilities. First we set the bus speed mode for the card using
      CMD6 mode 1, and then we program the host controller to support the
      required speed mode. We also set High Speed Enable in case one of the
      UHS-I modes is selected. We take care to reset SD clock before setting
      UHS mode in the Host Control2 register, and then re-enable it as per
      the Host Controller spec v3.00. We then set the clock frequency for
      the UHS-I mode selected.
      
      Tested by Zhangfei Gao with a Toshiba uhs card and general hs card,
      on mmp2 in SDMA mode.
      Signed-off-by: NArindam Nath <arindam.nath@amd.com>
      Reviewed-by: NPhilip Rakity <prakity@marvell.com>
      Tested-by: NPhilip Rakity <prakity@marvell.com>
      Acked-by: NZhangfei Gao <zhangfei.gao@marvell.com>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      49c468fc
    • A
      mmc: sd: add support for driver type selection · d6d50a15
      Arindam Nath 提交于
      This patch adds support for setting driver strength during UHS-I
      initialization procedure. Since UHS-I cards set S18A (bit 24) in
      response to ACMD41, we use this as a base for UHS-I initialization.
      We modify the parameter list of mmc_sd_get_cid() so that we can
      save the ROCR from ACMD41 to check whether bit 24 is set.
      
      We decide whether the Host Controller supports A, C, or D driver
      type depending on the Capabilities register. Driver type B is
      suported by default. We then set the appropriate driver type for
      the card using CMD6 mode 1. As per Host Controller spec v3.00, we
      set driver type for the host only if Preset Value Enable in the
      Host Control2 register is not set. SDHCI_HOST_CONTROL has been
      renamed to SDHCI_HOST_CONTROL1 to conform to the spec.
      
      Tested by Zhangfei Gao with a Toshiba uhs card and general hs card,
      on mmp2 in SDMA mode.
      Signed-off-by: NArindam Nath <arindam.nath@amd.com>
      Reviewed-by: NPhilip Rakity <prakity@marvell.com>
      Tested-by: NPhilip Rakity <prakity@marvell.com>
      Acked-by: NZhangfei Gao <zhangfei.gao@marvell.com>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      d6d50a15
    • A
      mmc: sd: add support for signal voltage switch procedure · f2119df6
      Arindam Nath 提交于
      Host Controller v3.00 adds another Capabilities register. Apart
      from other things, this new register indicates whether the Host
      Controller supports SDR50, SDR104, and DDR50 UHS-I modes. The spec
      doesn't mention about explicit support for SDR12 and SDR25 UHS-I
      modes, so the Host Controller v3.00 should support them by default.
      Also if the controller supports SDR104 mode, it will also support
      SDR50 mode as well. So depending on the host support, we set the
      corresponding MMC_CAP_* flags. One more new register. Host Control2
      is added in v3.00, which is used during Signal Voltage Switch
      procedure described below.
      
      Since as per v3.00 spec, UHS-I supported hosts should set S18R
      to 1, we set S18R (bit 24) of OCR before sending ACMD41. We also
      need to set XPC (bit 28) of OCR in case the host can supply >150mA.
      This support is indicated by the Maximum Current Capabilities
      register of the Host Controller.
      
      If the response of ACMD41 has both CCS and S18A set, we start the
      signal voltage switch procedure, which if successfull, will switch
      the card from 3.3V signalling to 1.8V signalling. Signal voltage
      switch procedure adds support for a new command CMD11 in the
      Physical Layer Spec v3.01. As part of this procedure, we need to
      set 1.8V Signalling Enable (bit 3) of Host Control2 register, which
      if remains set after 5ms, means the switch to 1.8V signalling is
      successfull. Otherwise, we clear bit 24 of OCR and retry the
      initialization sequence. When we remove the card, and insert the
      same or another card, we need to make sure that we start with 3.3V
      signalling voltage. So we call mmc_set_signal_voltage() with
      MMC_SIGNAL_VOLTAGE_330 set so that we are back to 3.3V signalling
      voltage before we actually start initializing the card.
      
      Tested by Zhangfei Gao with a Toshiba uhs card and general hs card,
      on mmp2 in SDMA mode.
      Signed-off-by: NArindam Nath <arindam.nath@amd.com>
      Reviewed-by: NPhilip Rakity <prakity@marvell.com>
      Tested-by: NPhilip Rakity <prakity@marvell.com>
      Acked-by: NZhangfei Gao <zhangfei.gao@marvell.com>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      f2119df6
    • O
      mmc: do not switch to 1-bit mode if not required · 6b93d01f
      Ohad Ben-Cohen 提交于
      6b5eda36 followed SDIO spec part E1 section 8, which states that
      in case SDIO interrupts are being used to wake up a suspended host,
      then it is required to switch to 1-bit mode before stopping the clock.
      
      Before switching to 1-bit mode (or back to 4-bit mode on resume),
      make sure that SDIO interrupts are really being used to wake the host.
      
      This is helpful for devices which have an external irq line (e.g.
      wl1271), and do not use SDIO interrupts to wake up the host.
      
      In this case, switching to 1-bit mode (and back to 4-bit mode on resume)
      is not necessary.
      Reported-by: NEliad Peller <eliad@wizery.com>
      Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      6b93d01f
    • O
      mmc: mmc_card_keep_power cleanups · a5e9425d
      Ohad Ben-Cohen 提交于
      mmc_card_is_powered_resumed is a mouthful; instead, simply use
      mmc_card_keep_power, which also better explains the purpose of
      the macro.
      
      Employ mmc_card_keep_power() where possible.
      Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      a5e9425d
  2. 28 4月, 2011 1 次提交
  3. 09 1月, 2011 4 次提交
    • A
      mmc: Test bus-width for old MMC devices · 22113efd
      Aries Lee 提交于
      Some old MMC devices fail with the 4/8 bits the driver tries to use
      exclusively.  This patch adds a test for the given bus setup and falls
      back to the lower bit mode (until 1-bit mode) when the test fails.
      
      [Major rework and refactoring by tiwai]
      [Quirk addition and many fixes by prakity]
      Signed-off-by: NAries Lee <arieslee@jmicron.com>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      Signed-off-by: NPhilip Rakity <prakity@marvell.com>
      Tested-by: NPhilip Rakity <prakity@marvell.com>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      22113efd
    • O
      mmc: sdio: don't reinitialize nonremovable powered-resumed cards · 080bc977
      Ohad Ben-Cohen 提交于
      Upon system resume, SDIO core must reinitialize cards that were
      powered off during suspend.
      
      If the card had its power kept during suspend (and thus it is
      'powered-resumed'), SDIO core performs only a limited reinitializing,
      mainly needed to make sure that the card wasn't removed/replaced.
      
      If a __nonremovable__ card is powered-resumed, we can safely skip the
      reinitializing phase.
      
      Note: 9b966aae (mmc: sdio: fully reconfigure oldcard on resume) removed
      the bus width reconfiguration since mmc_sdio_init_card already does it.
      It is brought back now in case mmc_sdio_init_card is skipped.
      Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      080bc977
    • T
      mmc: Add support for JMicron 388 SD/MMC controller · 8f230f45
      Takashi Iwai 提交于
      JMicron 388 SD/MMC combo controller supports the 1.8V low-voltage for
      SD, but MMC doesn't work with the low-voltage, resulting in an error
      at probing.
      
      This patch adds the support for multiple voltage mask per device type,
      so that SD works with 1.8V while MMC forces 3.3V.  Here new ocr_avail_*
      fields for each device are introduced, so that the actual OCR mask is
      switched dynamically.
      
      Also, the restriction of low-voltage in core/sd.c is removed when the
      bit is allowed explicitly via ocr_avail_sd mask.
      
      This patch was rewritten from scratch based on Aries' original code.
      Signed-off-by: NAries Lee <arieslee@jmicron.com>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      Reviewed-by: NChris Ball <cjb@laptop.org>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      8f230f45
    • L
      mmc: Aggressive clock gating framework · 04566831
      Linus Walleij 提交于
      This patch modifies the MMC core code to optionally call the set_ios()
      operation on the driver with the clock frequency set to 0 (gate) after
      a grace period of at least 8 MCLK cycles, then restore it (ungate)
      before any new request. This gives the driver the option to shut down
      the MCI clock to the MMC/SD card when the clock frequency is 0, i.e.
      the core has stated that the MCI clock does not need to be generated.
      
      It is inspired by existing clock gating code found in the OMAP and
      Atmel drivers and brings this up to the host abstraction.  Gating is
      performed before and after any MMC request.
      
      This patchset implements this for the MMCI/PL180 MMC/SD host controller,
      but it should be simple to switch OMAP/Atmel over to using this instead.
      
      mmc_set_{gated,ungated}() add variable protection to the state holders
      for the clock gating code.  This is particularly important when ordinary
      .set_ios() calls would race with the .set_ios() call resulting from a
      delayed gate operation.
      Signed-off-by: NLinus Walleij <linus.walleij@stericsson.com>
      Reviewed-by: NChris Ball <cjb@laptop.org>
      Tested-by: NChris Ball <cjb@laptop.org>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      04566831
  4. 20 11月, 2010 1 次提交
    • O
      mmc: sdio: fix runtime PM anomalies by introducing MMC_CAP_POWER_OFF_CARD · ed919b01
      Ohad Ben-Cohen 提交于
      Some board/card/host configurations are not capable of powering off the
      card after boot.
      
      To support such configurations, and to allow smoother transition to
      runtime PM behavior, MMC_CAP_POWER_OFF_CARD is added, so hosts need to
      explicitly indicate whether it's OK to power off their cards after boot.
      
      SDIO core will enable runtime PM for a card only if that cap is set.
      As a result, the card will be powered down after boot, and will only
      be powered up again when a driver is loaded (and then it's up to the
      driver to decide whether power will be kept or not).
      
      This will prevent sdio_bus_probe() failures with setups that do not
      support powering off the card.
      Reported-and-tested-by: NDaniel Drake <dsd@laptop.org>
      Reported-and-tested-by: NArnd Hannemann <arnd@arndnet.de>
      Signed-off-by: NOhad Ben-Cohen <ohad@wizery.com>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      ed919b01
  5. 23 10月, 2010 8 次提交
  6. 12 8月, 2010 1 次提交
    • A
      mmc: add erase, secure erase, trim and secure trim operations · dfe86cba
      Adrian Hunter 提交于
      SD/MMC cards tend to support an erase operation.  In addition, eMMC v4.4
      cards can support secure erase, trim and secure trim operations that are
      all variants of the basic erase command.
      
      SD/MMC device attributes "erase_size" and "preferred_erase_size" have been
      added.
      
      "erase_size" is the minimum size, in bytes, of an erase operation.  For
      MMC, "erase_size" is the erase group size reported by the card.  Note that
      "erase_size" does not apply to trim or secure trim operations where the
      minimum size is always one 512 byte sector.  For SD, "erase_size" is 512
      if the card is block-addressed, 0 otherwise.
      
      SD/MMC cards can erase an arbitrarily large area up to and
      including the whole card.  When erasing a large area it may
      be desirable to do it in smaller chunks for three reasons:
      
          1. A single erase command will make all other I/O on the card
             wait.  This is not a problem if the whole card is being erased, but
             erasing one partition will make I/O for another partition on the
             same card wait for the duration of the erase - which could be a
             several minutes.
      
          2. To be able to inform the user of erase progress.
      
          3. The erase timeout becomes too large to be very useful.
             Because the erase timeout contains a margin which is multiplied by
             the size of the erase area, the value can end up being several
             minutes for large areas.
      
      "erase_size" is not the most efficient unit to erase (especially for SD
      where it is just one sector), hence "preferred_erase_size" provides a good
      chunk size for erasing large areas.
      
      For MMC, "preferred_erase_size" is the high-capacity erase size if a card
      specifies one, otherwise it is based on the capacity of the card.
      
      For SD, "preferred_erase_size" is the allocation unit size specified by
      the card.
      
      "preferred_erase_size" is in bytes.
      Signed-off-by: NAdrian Hunter <adrian.hunter@nokia.com>
      Acked-by: NJens Axboe <axboe@kernel.dk>
      Cc: Kyungmin Park <kmpark@infradead.org>
      Cc: Madhusudhan Chikkature <madhu.cr@ti.com>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Ben Gardiner <bengardiner@nanometrics.ca>
      Cc: <linux-mmc@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      dfe86cba
  7. 11 8月, 2010 1 次提交
    • M
      mmc: fix all hangs related to mmc/sd card insert/removal during suspend/resume · 4c2ef25f
      Maxim Levitsky 提交于
      If you don't use CONFIG_MMC_UNSAFE_RESUME, as soon as you attempt to
      suspend, the card will be removed, therefore this patch doesn't change the
      behavior of this option.
      
      However the removal will be done by pm notifier, which runs while
      userspace is still not frozen and thus can freely use del_gendisk, without
      the risk of deadlock which would happen otherwise.
      
      Card detect workqueue is now disabled while userspace is frozen, Therefore
      if you do use CONFIG_MMC_UNSAFE_RESUME, and remove the card during
      suspend, the removal will be detected as soon as userspace is unfrozen,
      again at the moment it is safe to call del_gendisk.
      
      Tested with and without CONFIG_MMC_UNSAFE_RESUME with suspend and hibernate.
      
      [akpm@linux-foundation.org: clean up function prototype]
      [akpm@linux-foundation.org: fix CONFIG_PM-n linkage, small cleanups]
      [akpm@linux-foundation.org: coding-style fixes]
      Signed-off-by: NMaxim Levitsky <maximlevitsky@gmail.com>
      Cc: David Brownell <david-b@pacbell.net>
      Cc: Alan Stern <stern@rowland.harvard.edu>
      Cc: <linux-mmc@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      4c2ef25f
  8. 28 5月, 2010 1 次提交
  9. 14 4月, 2010 1 次提交
    • D
      ARM: MXC: mxcmmc: work around a bug in the SDHC busy line handling · 3fcb027d
      Daniel Mack 提交于
      MX3 SoCs have a silicon bug which corrupts CRC calculation of
      multi-block transfers when connected SDIO peripheral doesn't drive the
      BUSY line as required by the specs.
      
      One way to prevent this is to only allow 1-bit transfers.
      
      Another way is playing tricks with the DMA engine, but this isn't
      mainline yet. So for now, we live with the performance drawback of 1-bit
      transfers until a nicer solution is found.
      
      This patch introduces a new host controller callback 'init_card' which
      is for now only called from mmc_sdio_init_card().
      Signed-off-by: NDaniel Mack <daniel@caiaq.de>
      Cc: Sascha Hauer <s.hauer@pengutronix.de>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Volker Ernst <volker.ernst@txtr.com>
      Cc: Jiri Kosina <jkosina@suse.cz>
      Cc: Michał Mirosław <mirqus@gmail.com>
      Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
      3fcb027d
  10. 07 3月, 2010 1 次提交
    • N
      sdio: introduce API for special power management features · da68c4eb
      Nicolas Pitre 提交于
      This patch series provides the core changes needed to allow SDIO cards to
      remain powered and active while the host system is suspended, and let them
      wake up the host system when needed.  This is used to implement
      wake-on-lan with SDIO wireless cards at the moment.  Patches to add that
      support to the libertas driver will be posted separately.
      
      This patch:
      
      Some SDIO cards have the ability to keep on running autonomously when the
      host system is suspended, and wake it up when needed.  This however
      requires that the host controller preserve power to the card, and
      configure itself appropriately for wake-up.
      
      There is however 4 layers of abstractions involved: the host controller
      driver, the MMC core code, the SDIO card management code, and the actual
      SDIO function driver.  To make things simple and manageable, host drivers
      must advertise their PM capabilities with a feature bitmask, then function
      drivers can query and set those features from their suspend method.  Then
      each layer in the suspend call chain is expected to act upon those bits
      accordingly.
      
      [akpm@linux-foundation.org: fix typo in comment]
      Signed-off-by: NNicolas Pitre <nico@marvell.com>
      Cc: <linux-mmc@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      da68c4eb
  11. 12 10月, 2009 1 次提交
  12. 23 9月, 2009 5 次提交
  13. 31 3月, 2009 1 次提交
  14. 01 1月, 2009 1 次提交
  15. 09 11月, 2008 1 次提交
  16. 12 10月, 2008 1 次提交
  17. 27 7月, 2008 1 次提交
  18. 15 7月, 2008 3 次提交
    • P
      mmc: remove multiwrite capability · 23af6039
      Pierre Ossman 提交于
      Relax requirements on host controllers and only require that they do not
      report a transfer count than is larger than the actual one (i.e. a lower
      value is okay). This is how many other parts of the kernel behaves so
      upper layers should already be prepared to handle that scenario. This
      gives us a performance boost on MMC cards.
      Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>
      23af6039
    • A
      mmc: change .get_ro() callback semantics · 08f80bb5
      Anton Vorontsov 提交于
      Now get_ro() callback must return 0/1 values for its logical states, and
      negative errno values in case of error. If particular host instance doesn't
      support RO/WP switch, it should return -ENOSYS.
      
      This patch changes some hosts in two ways:
      
      1. Now functions should be smart to not return negative values in
         "RO asserted" case (particularly gpio_ calls could return negative
         values for the outermost GPIOs).
      
         Also, board code usually passes get_ro() callbacks that directly return
         gpioreg & bit result, so at91_mci, imxmmc, pxamci and mmc_spi's get_ro()
         handlers need take special care when returning platform's values to the
         mmc core.
      
      2. In case of host instance didn't implement get_ro() callback, it should
         really return -ENOSYS and let the mmc core decide what to do about it
         (mmc core thinks the same way as the hosts, so it isn't functional
         change).
      Signed-off-by: NAnton Vorontsov <avorontsov@ru.mvista.com>
      Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>
      08f80bb5
    • A
      mmc: add support for card-detection polling · 28f52482
      Anton Vorontsov 提交于
      Some hosts (and boards that use mmc_spi) do not use interrupts on the CD
      line, so they can't trigger mmc_detect_change. We want to poll the card
      and see if there was a change. 1 second poll interval seems resonable.
      
      This patch also implements .get_cd() host operation, that could be used
      by the hosts that are able to report card-detect status without need to
      talk MMC.
      Signed-off-by: NAnton Vorontsov <avorontsov@ru.mvista.com>
      Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>
      28f52482
  19. 13 12月, 2007 1 次提交
  20. 24 9月, 2007 1 次提交