1. 22 Jul, 2012 3 commits
  2. 21 Jul, 2012 33 commits
  3. 11 Jul, 2012 4 commits
    • Chris Ball's avatar
      mmc: dt: Add reg/interrupts to mmc.txt for clarity. · ed3efc1c
      Chris Ball authored
      Even though these aren't parsed by the MMC driver, make clear that
      they're required by the OF core.  (Also, a few typo fixes.)
      Signed-off-by: default avatarChris Ball <cjb@laptop.org>
      ed3efc1c
    • Chris Ball's avatar
      mmc: dt: Deduplicate binding docs by referencing mmc.txt · 4efafee0
      Chris Ball authored
      Now that we have common bindings for MMC, rewrite the individual
      bindings to inherit from mmc.txt and describe their differences.
      Acked-by: default avatarStephen Warren <swarren@wwwdotorg.org>
      Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarChris Ball <cjb@laptop.org>
      4efafee0
    • Chris Ball's avatar
      mmc: core: Export regulator_* functions as GPL · 45a6b32e
      Chris Ball authored
      The regulator API functions we're wrapping are exported as GPL, so our
      wrappers for the same functions should be too.
      Reported-by: default avatarGuennadi Liakhovetski <g.liakhovetski@gmx.de>
      Signed-off-by: default avatarChris Ball <cjb@laptop.org>
      45a6b32e
    • Subhash Jadavani's avatar
      mmc: block: replace __blk_end_request() with blk_end_request() · ecf8b5d0
      Subhash Jadavani authored
      For completing any block request, MMC block driver is calling:
      	spin_lock_irq(queue)
      	__blk_end_request()
      	spin_unlock_irq(queue)
      
      But if we analyze the sources of latency in kernel using ftrace,
      __blk_end_request() function at times may take up to 6.5ms with
      spinlock held and irq disabled.
      
      __blk_end_request() calls couple of functions and ftrace output
      shows that blk_update_bidi_request() function is almost taking 6ms.
      There are 2 function to end the current request: ___blk_end_request()
      and blk_end_request(). Both these functions do same thing except
      that blk_end_request() function doesn't take up the spinlock
      while calling the blk_update_bidi_request().
      
      This patch replaces all __blk_end_request() calls with
      blk_end_request() and __blk_end_request_all() calls with
      blk_end_request_all().
      
      Testing done: 20 process concurrent read/write on sd card
      and eMMC. Ran this test for almost a day on multicore system
      and no errors observed.
      
      This change is not meant for improving MMC throughput; it's basically
      about becoming fair to other threads/interrupts in the system. By
      holding spin lock and interrupts disabled for longer duration, we
      won't allow other threads/interrupts to run at all.  Actually slight
      performance degradation at file system level can be expected as we
      are not holding the spin lock during blk_update_bidi_request() which
      means our mmcqd thread may get preempted for other high priority
      thread or any interrupt in the system.
      
      These are performance numbers (100MB file write) with eMMC running
      in DDR mode:
      
      Without this patch:
      	Name of the Test   Value   Unit
      	LMDD Read Test     53.79   MBPS
      	LMDD Write Test    18.86   MBPS
      	IOZONE  Read Test  51.65   MBPS
      	IOZONE  Write Test 24.36   MBPS
      
      With this patch:
      	Name of the Test    Value  Unit
      	LMDD Read Test      52.94  MBPS
      	LMDD Write Test     16.70  MBPS
      	IOZONE  Read Test   52.08  MBPS
      	IOZONE  Write Test  23.29  MBPS
      
      Read numbers are fine. Write numbers are bit down (especially LMDD
      write), may be because write requests normally have large transfer
      size and which means there are chances that while mmcq is executing
      blk_update_bidi_request(), it may get interrupted by interrupts or
      other high priority thread.
      Signed-off-by: default avatarSubhash Jadavani <subhashj@codeaurora.org>
      Reviewed-by: default avatarNamjae Jeon <linkinjeon@gmail.com>
      Signed-off-by: default avatarChris Ball <cjb@laptop.org>
      ecf8b5d0