1. 28 4月, 2011 1 次提交
  2. 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
  3. 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
  4. 23 10月, 2010 8 次提交
  5. 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
  6. 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
  7. 28 5月, 2010 1 次提交
  8. 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
  9. 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
  10. 12 10月, 2009 1 次提交
  11. 23 9月, 2009 5 次提交
  12. 31 3月, 2009 1 次提交
  13. 01 1月, 2009 1 次提交
  14. 09 11月, 2008 1 次提交
  15. 12 10月, 2008 1 次提交
  16. 27 7月, 2008 1 次提交
  17. 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
  18. 13 12月, 2007 1 次提交
  19. 24 9月, 2007 4 次提交
  20. 23 9月, 2007 1 次提交
  21. 01 5月, 2007 1 次提交
    • P
      MMC: Fix handling of low-voltage cards · 55556da0
      Philip Langdale 提交于
      Fix handling of low voltage MMC cards.
      
      The latest MMC and SD specs both agree that support for
      low-voltage operations is indicated by bit 7 in the OCR.
      The MMC spec states that the low voltage range is
      1.65-1.95V while the SD spec leaves the actual voltage
      range undefined - meaning that there is still no such
      thing as a low voltage SD card.
      
      However, an old Sandisk spec implied that bits 7.0
      represented voltages below 2.0V in 1V or 0.5V increments,
      and the code was accordingly written with that expectation.
      
      This confusion meant that host drivers attempting to support
      the typical low voltage (1.8V) would set the wrong bits in
      the host OCR mask (usually bits 5 and/or 6) resulting in the
      the low voltage mode never being used.
      
      This change corrects the low voltage range and adds sanity
      checks on the reserved bits (0-6) and for SD cards that
      claim to support low-voltage operations.
      Signed-off-by: NPhilip Langdale <philipl@overt.org>
      Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>
      55556da0