25 Jul, 2016

2 commits


31 Mar, 2016

1 commit


26 Oct, 2015

1 commit

  • MMC_CLKGATE was once invented to save power by gating the bus clock at
    request inactivity. At that time it served its purpose. The modern way to
    deal with power saving for these scenarios, is by using runtime PM.

    Nowadays, several host drivers have deployed runtime PM, but for those
    that haven't and which still cares power saving at request inactivity,
    it's certainly time to deploy runtime PM as it has been around for several
    years now.

    To simplify code to mmc core and thus decrease maintenance efforts, this
    patch removes all code related to MMC_CLKGATE.

    Signed-off-by: Ulf Hansson
    Reviewed-by: Linus Walleij

    Ulf Hansson
     

23 Mar, 2013

1 commit

  • The JEDEC MMC v4 spec defines a new PRV value in place of the original
    fwrev and hwrev specified in v1. We can expose this in the kernel to enable
    user space to more easily determine the product revision of a given MMC.

    Signed-off-by: Bernie Thompson
    Reviewed-by: Ulf Hansson
    Signed-off-by: Chris Ball

    Bernie Thompson
     

07 Dec, 2012

1 commit


12 Jan, 2012

3 commits

  • c31b50e (mmc: core: Use delayed work in clock gating framework,
    2011-11-14) missed a few things during review:

    o A useless pr_info()

    o milliseconds was written as two words

    o The sysfs file had units in its output

    Fix all three problems.

    Signed-off-by: Stephen Boyd
    Cc: Sujit Reddy Thumma
    Signed-off-by: Chris Ball

    Stephen Boyd
     
  • Enable boot partitions to be read-only locked until next power on via
    a sysfs entry. There will be one sysfs entry for each boot partition:

    /sys/block/mmcblkXbootY/ro_lock_until_next_power_on

    Each boot partition is locked by writing 1 to its file.

    Signed-off-by: Johan Rudholm
    Signed-off-by: John Beckett
    Signed-off-by: Chris Ball

    Johan Rudholm
     
  • Current clock gating framework disables the MCI clock as soon as the
    request is completed and enables it when a request arrives. This aggressive
    clock gating framework, when enabled, cause following issues:

    When there are back-to-back requests from the Queue layer, we unnecessarily
    end up disabling and enabling the clocks between these requests since 8MCLK
    clock cycles is a very short duration compared to the time delay between
    back to back requests reaching the MMC layer. This overhead can effect the
    overall performance depending on how long the clock enable and disable
    calls take which is platform dependent. For example on some platforms we
    can have clock control not on the local processor, but on a different
    subsystem and the time taken to perform the clock enable/disable can add
    significant overhead.

    Also if the host controller driver decides to disable the host clock too
    when mmc_set_ios function is called with ios.clock=0, it adds additional
    delay and it is highly possible that the next request had already arrived
    and unnecessarily blocked in enabling the clocks. This is seen frequently
    when the processor is executing at high speeds and in multi-core platforms
    thus reduces the overall throughput compared to if clock gating is
    disabled.

    Fix this by delaying turning off the clocks by posting request on
    delayed workqueue. Also cancel the unscheduled pending work, if any,
    when there is access to card.

    sysfs entry is provided to tune the delay as needed, default
    value set to 200ms.

    Signed-off-by: Sujit Reddy Thumma
    Acked-by: Linus Walleij
    Signed-off-by: Chris Ball

    Sujit Reddy Thumma
     

21 Jul, 2011

1 commit


25 May, 2011

1 commit


12 Aug, 2010

1 commit

  • 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: Adrian Hunter
    Acked-by: Jens Axboe
    Cc: Kyungmin Park
    Cc: Madhusudhan Chikkature
    Cc: Christoph Hellwig
    Cc: Ben Gardiner
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Adrian Hunter