1. 23 9月, 2009 1 次提交
  2. 27 7月, 2008 2 次提交
    • H
      mmc: Add per-card debugfs support · f4b7f927
      Haavard Skinnemoen 提交于
      For each card successfully added to the bus, create a subdirectory under
      the host's debugfs root with information about the card.
      
      At the moment, only a single file is added to the card directory for
      all cards: "state". It reflects the "state" field in struct mmc_card,
      indicating whether the card is present, readonly, etc.
      
      For MMC and SD cards (not SDIO), another file is added: "status".
      Reading this file will ask the card about its current status and
      return it. This can be useful if the card just refuses to respond to
      any commands, which might indicate that the card state is not what the
      MMC core thinks it is (due to a missing stop command, for example.)
      Signed-off-by: NHaavard Skinnemoen <haavard.skinnemoen@atmel.com>
      Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>
      f4b7f927
    • H
      mmc: Export internal host state through debugfs · 6edd8ee6
      Haavard Skinnemoen 提交于
      When CONFIG_DEBUG_FS is set, create a few files under /sys/kernel/debug
      containing information about an mmc host's internal state. Currently,
      just a single file is created, "ios", which contains information about
      the current operating parameters for the bus (clock speed, bus width,
      etc.)
      
      Host drivers can add additional files and directories under the host's
      root directory by passing the debugfs_root field in struct mmc_host as
      the 'parent' parameter to debugfs_create_*.
      Signed-off-by: NHaavard Skinnemoen <haavard.skinnemoen@atmel.com>
      Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>
      6edd8ee6
  3. 19 4月, 2008 1 次提交
  4. 23 3月, 2008 1 次提交
  5. 24 9月, 2007 1 次提交
    • D
      MMC core learns about SPI · af517150
      David Brownell 提交于
      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: NDavid Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>
      af517150
  6. 26 7月, 2007 1 次提交
  7. 10 7月, 2007 2 次提交
  8. 01 5月, 2007 4 次提交
    • P
      mmc: support unsafe resume of cards · 6abaa0c9
      Pierre Ossman 提交于
      Since many have the system root on MMC/SD we must allow some foot
      shooting when it comes to resume.
      
      We cannot detect if a card is removed and reinserted during suspend,
      so the safe approach would be to assume it was, avoiding potential
      filesystem corruption. This will of course not work if you cannot
      release the card before suspend.
      
      This commit adds a compile time option that makes the MMC layer
      assume the card wasn't touched if it is redetected upon resume.
      Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>
      6abaa0c9
    • P
      mmc: add bus handler · 7ea239d9
      Pierre Ossman 提交于
      Delegate protocol handling to "bus handlers". This allows the core to
      just handle the task of arbitrating the bus. Initialisation and
      pampering of cards is now done by the different bus handlers.
      
      This design also allows MMC and SD (and later SDIO) to be more cleanly
      separated, allowing easier maintenance.
      Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>
      7ea239d9
    • P
      mmc: Separate out protocol ops · da7fbe58
      Pierre Ossman 提交于
      Move protocol operations and definitions into their own files
      in an effort to separate protocol handling and bus
      arbitration more clearly.
      Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>
      da7fbe58
    • P
      mmc: Move core functions to subdir · aaac1b47
      Pierre Ossman 提交于
      Create a "core" subdirectory to house the central bus handling
      functions.
      Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>
      aaac1b47
  9. 22 11月, 2006 1 次提交
  10. 04 10月, 2006 1 次提交
    • P
      [PATCH] mmc: use own work queue · 7104e2d5
      Pierre Ossman 提交于
      The MMC layer uses the standard work queue for doing card detection.  As this
      queue is shared with other crucial subsystems, the effects of a long (and
      perhaps buggy) detection can cause the system to be unusable.  E.g.  the
      keyboard stops working while the detection routine is running.
      
      The solution is to add a specific mmc work queue to run the detection code in.
      This is similar to how other subsystems handle detection (a full kernel
      thread is the most common theme).
      Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>
      Cc: Russell King <rmk@arm.linux.org.uk>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      7104e2d5
  11. 19 8月, 2005 1 次提交
  12. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4