1. 01 6月, 2015 3 次提交
    • L
      mmc: dt: Allow to specify that no write protect signal is present · 19f44246
      Lars-Peter Clausen 提交于
      Allow to specify in the device-tree that no physical write-protect signal
      is connected to a particular instance of a MMC controller. Setting the
      property will cause the core will assume that the SD card is always
      read-write.
      
      The name for the new property is 'disable-wp' and was chosen based on the
      property with the same function from the Synopsys designware mobile storage
      host controller DT bindings specification.
      Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
      Cc: Rob Herring <robh+dt@kernel.org>
      Cc: Pawel Moll <pawel.moll@arm.com>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
      Cc: Kumar Gala <galak@codeaurora.org>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      19f44246
    • A
      mmc: core: Add support for HS400 re-tuning · 6376f69d
      Adrian Hunter 提交于
      HS400 re-tuning must be done in HS200 mode. Add
      the ability to switch from HS400 mode to HS200
      mode before re-tuning and switch back to HS400
      after re-tuning.
      Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      6376f69d
    • A
      mmc: host: Add facility to support re-tuning · dfa13ebb
      Adrian Hunter 提交于
      Currently, there is core support for tuning during
      initialization. There can also be a need to re-tune
      periodically (e.g. sdhci) or to re-tune after the
      host controller is powered off (e.g. after PM
      runtime suspend / resume) or to re-tune in response
      to CRC errors.
      
      The main requirements for re-tuning are:
        - ability to enable / disable re-tuning
        - ability to flag that re-tuning is needed
        - ability to re-tune before any request
        - ability to hold off re-tuning if the card is busy
        - ability to hold off re-tuning if re-tuning is in
        progress
        - ability to run a re-tuning timer
      
      To support those requirements 7 members are added to struct
      mmc_host:
      
        unsigned int		can_retune:1;	/* re-tuning can be used */
        unsigned int		doing_retune:1;	/* re-tuning in progress */
        unsigned int		retune_now:1;   /* do re-tuning at next req */
        int			need_retune;	/* re-tuning is needed */
        int			hold_retune;	/* hold off re-tuning */
        unsigned int		retune_period;  /* re-tuning period in secs */
        struct timer_list	retune_timer;	/* for periodic re-tuning */
      
      need_retune is an integer so it can be set without needing
      synchronization. hold_retune is a integer to allow nesting.
      
      Various simple functions are provided to set / clear those
      variables.
      
      Subsequent patches take those functions into use.
      Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      dfa13ebb
  2. 28 1月, 2015 1 次提交
    • U
      mmc: core: Initial support for MMC power sequences · 3aa8793f
      Ulf Hansson 提交于
      System on chip designs may specify a specific MMC power sequence. To
      successfully detect an (e)MMC/SD/SDIO card, that power sequence must
      be followed while initializing the card.
      
      To be able to handle these SOC specific power sequences, let's add a
      MMC power sequence interface. It provides the following functions to
      help the mmc core to deal with these power sequences.
      
      mmc_pwrseq_alloc() - Invoked from mmc_of_parse(), to initialize data.
      mmc_pwrseq_pre_power_on()- Invoked in the beginning of mmc_power_up().
      mmc_pwrseq_post_power_on()- Invoked at the end in mmc_power_up().
      mmc_pwrseq_power_off()- Invoked from mmc_power_off().
      mmc_pwrseq_free() - Invoked from mmc_free_host(), to free data.
      
      Each MMC power sequence provider will be responsible to implement a set
      of callbacks. These callbacks mirrors the functions above.
      
      This patch adds the skeleton, following patches will extend the core of
      the MMC power sequence and add support for a specific simple MMC power
      sequence.
      
      Do note, since the mmc_pwrseq_alloc() is invoked from mmc_of_parse(),
      host drivers needs to make use of this API to enable the support for
      MMC power sequences. Moreover the MMC power sequence support depends on
      CONFIG_OF.
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      Tested-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk>
      Reviewed-by: NJavier Martinez Canillas <javier.martinez@collabora.co.uk>
      3aa8793f
  3. 19 1月, 2015 3 次提交
  4. 05 11月, 2014 1 次提交
    • K
      mmc: core: fix card detection regression · a31b0c6c
      Kristina Martsenko 提交于
      Since commit 89168b48 ("mmc: core: restore detect line inversion
      semantics"), the SD card on i.MX28 (and possibly other) devices isn't
      detected and booting stops at:
      
      [    4.120617] Waiting for root device /dev/mmcblk0p3...
      
      This is caused by the MMC_CAP2_CD_ACTIVE_HIGH flag being set incorrectly
      when the host controller doesn't use a GPIO for card detection (but
      instead uses a dedicated pin). In this case mmc_gpiod_request_cd() will
      return before assigning to the gpio_invert variable, leaving the
      variable uninitialized. The variable then gets used to set the flag.
      This patch fixes the issue by making sure gpio_invert is set to false
      when a GPIO isn't used. After this patch, i.MX28 boots fine.
      
      The MMC_CAP2_RO_ACTIVE_HIGH (write protect) flag is also set incorrectly
      for the exact same reason (it uses the same uninitialized variable), so
      this patch fixes that too.
      
      Fixes: 89168b48 ("mmc: core: restore detect line inversion semantics")
      Reported-by: NStefan Wahren <stefan.wahren@i2se.com>
      Signed-off-by: NKristina Martšenko <kristina.martsenko@gmail.com>
      Tested-by: NFabio Estevam <fabio.estevam@freescale.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      a31b0c6c
  5. 02 10月, 2014 1 次提交
  6. 09 9月, 2014 2 次提交
  7. 13 5月, 2014 1 次提交
  8. 10 3月, 2014 1 次提交
  9. 23 2月, 2014 3 次提交
  10. 25 8月, 2013 1 次提交
  11. 28 6月, 2013 1 次提交
  12. 27 6月, 2013 1 次提交
  13. 28 2月, 2013 1 次提交
  14. 25 2月, 2013 2 次提交
  15. 21 8月, 2012 1 次提交
    • T
      workqueue: deprecate system_nrt[_freezable]_wq · 3b07e9ca
      Tejun Heo 提交于
      system_nrt[_freezable]_wq are now spurious.  Mark them deprecated and
      convert all users to system[_freezable]_wq.
      
      If you're cc'd and wondering what's going on: Now all workqueues are
      non-reentrant, so there's no reason to use system_nrt[_freezable]_wq.
      Please use system[_freezable]_wq instead.
      
      This patch doesn't make any functional difference.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Acked-By: NLai Jiangshan <laijs@cn.fujitsu.com>
      
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: David Airlie <airlied@linux.ie>
      Cc: Jiri Kosina <jkosina@suse.cz>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
      Cc: David Howells <dhowells@redhat.com>
      3b07e9ca
  16. 21 7月, 2012 3 次提交
  17. 28 3月, 2012 1 次提交
  18. 05 3月, 2012 1 次提交
  19. 12 1月, 2012 2 次提交
    • S
      mmc: core: Fixup delayed work clock gating patch · 4137e504
      Stephen Boyd 提交于
      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: NStephen Boyd <sboyd@codeaurora.org>
      Cc: Sujit Reddy Thumma <sthumma@codeaurora.org>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      4137e504
    • S
      mmc: core: Use delayed work in clock gating framework · 597dd9d7
      Sujit Reddy Thumma 提交于
      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: NSujit Reddy Thumma <sthumma@codeaurora.org>
      Acked-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      597dd9d7
  20. 20 12月, 2011 1 次提交
  21. 01 11月, 2011 1 次提交
  22. 27 10月, 2011 1 次提交
    • D
      mmc: enable runtime PM by default · 08da834a
      Daniel Drake 提交于
      Now that we have improved the runtime power management powerup/powerdown
      code, we believe that MMC_CAP_POWER_OFF_CARD is no longer necessary:
      runtime PM should now work everywhere.
      
      The only hard evidence for introducing MMC_CAP_POWER_OFF_CARD was the
      Marvell sd8686 wifi chip, which was believed to require external gpio
      manipulation which wasn't supported by some boards.
      
      After further investigation it was realized (and confirmed by Marvell
      folks) that sd8686 requirements can be fulfilled by changing the reset
      sequence itself, even if no external gpio is manipulated.
      
      For further information, see the following thread:
      http://www.mail-archive.com/linux-mmc@vger.kernel.org/msg04289.html
      
      Enable this trivially for a release or two. If no problems are reported,
      we will follow up with a more extensive patch to remove this flag
      altogether. If problems are reported, we can look at whitelist/blacklist
      possibilities as before.
      Signed-off-by: NDaniel Drake <dsd@laptop.org>
      Acked-by: NOhad Ben-Cohen <ohad@wizery.com>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      08da834a
  23. 01 9月, 2011 2 次提交
  24. 25 5月, 2011 1 次提交
  25. 16 5月, 2011 1 次提交
  26. 28 4月, 2011 1 次提交
  27. 16 3月, 2011 1 次提交
  28. 09 1月, 2011 1 次提交