1. 25 5月, 2011 2 次提交
    • P
      mmc: sdhci: Add pre and post reset processing for chip specific reset · 393c1a34
      Philip Rakity 提交于
      Marvell pxa controllers have private registers that may need to be
      modified before and after a reset is done.
      
      For example, the SD reset operation, RESET_ALL, will reset the private
      registers to their default state.  This will cause the clock adjustment
      registers that may have been programmed to have incorrect values.
      
      RESET_DATA sometimes needs to be delayed before the reset is done
      (depending on SoC) to enable any transactions being handled by the
      SDIO card to be completed.  Needed in pre SD 3.0 silicon to handle
      clock gating.
      
      Implement hooks to allow this to happen.
      Signed-off-by: NPhilip Rakity <prakity@marvell.com>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      393c1a34
    • M
      mmc: sdhci: work around broken dma boundary behavior · f6a03cbf
      Mikko Vinni 提交于
      Some SD host controllers (noticed on an integrated JMicron SD reader on an
      HP Pavilion dv5-1250eo laptop) don't update the dma address register before
      signaling a dma interrupt due to a dma boundary. Update the register
      manually to the next boundary (by default 512KiB), at which the transfer
      stopped.
      
      As long as each transfer is at most 512KiB in size (guaranteed by a BUG_ON
      in sdhci_prepare_data()) and the boundary is kept at the default value,
      this fix is needed at most once per transfer. Smaller boundaries are taken
      care of by counting the transferred bytes.
      
      Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=28462Signed-off-by: NMikko Vinni <mmvinni@yahoo.com>
      Signed-off-by: NChris Ball <cjb@laptop.org>
      f6a03cbf
  2. 25 3月, 2011 1 次提交
  3. 09 1月, 2011 2 次提交
  4. 23 11月, 2010 1 次提交
  5. 08 11月, 2010 1 次提交
  6. 23 10月, 2010 6 次提交
  7. 21 8月, 2010 1 次提交
  8. 11 8月, 2010 5 次提交
  9. 28 5月, 2010 4 次提交
  10. 18 12月, 2009 1 次提交
  11. 23 9月, 2009 2 次提交
  12. 30 7月, 2009 1 次提交
    • A
      sdhci: get rid of "frequency too high" flood when using eSDHC · a9e58f25
      Anton Vorontsov 提交于
      Since commit 8dfd0374 ("MMC core: limit
      minimum initialization frequency to 400kHz") MMC core checks for minimum
      frequency, and that causes following messages flood when using eSDHC
      controllers:
      
        ...
        mmc0: Minimum clock frequency too high for identification mode
        mmc0: Minimum clock frequency too high for identification mode
        ...
      
      The warnings are legitimate, since if we'd use 133 MHz clocks for standard
      SDHCI controllers, we'd not able to scale frequency down to 400 kHz.
      
      But eSDHC controllers have a non-standard SD clock management, so we can
      divide clock by 256 * 16, not just 256.
      
      This patch introduces get_min_clock() callback for sdhci core and
      implements it for sdhci-of driver, and thus fixes the issue.
      Signed-off-by: NAnton Vorontsov <avorontsov@ru.mvista.com>
      Cc: Matt Fleming <matt@console-pimps.org>
      Cc: Ian Molton <ian@mnementh.co.uk>
      Cc: "Roberto A. Foglietta" <roberto.foglietta@gmail.com>
      Cc: Pierre Ossman <drzeus@drzeus.cx>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a9e58f25
  13. 22 6月, 2009 3 次提交
  14. 14 6月, 2009 1 次提交
  15. 04 5月, 2009 1 次提交
  16. 25 3月, 2009 8 次提交