1. 01 Dec, 2018 2 commits
  2. 06 Aug, 2018 1 commit
  3. 30 May, 2018 1 commit
  4. 03 Feb, 2018 1 commit
  5. 21 Nov, 2017 1 commit
  6. 10 Nov, 2015 1 commit
  7. 09 Nov, 2015 4 commits
  8. 02 Jun, 2015 5 commits
  9. 10 Apr, 2015 1 commit
  10. 09 Mar, 2015 1 commit
  11. 09 Jan, 2015 1 commit
  12. 26 Nov, 2014 2 commits
  13. 24 Nov, 2014 2 commits
  14. 20 Nov, 2014 4 commits
  15. 12 Nov, 2014 6 commits
  16. 01 Oct, 2014 7 commits
    • Dolev Raviv's avatar
      ufs: definitions for phy interface · e785060e
      Dolev Raviv authored
      
      
      - Adding some of the definitions missing in unipro.h, including power
        enumeration.
      - Read Modify Write Line helper function
      - Indication for the type of suspend
      Signed-off-by: default avatarDolev Raviv <draviv@codeaurora.org>
      Signed-off-by: default avatarSubhash Jadavani <subhashj@codeaurora.org>
      Signed-off-by: default avatarYaniv Gardi <ygardi@codeaurora.org>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      e785060e
    • Subhash Jadavani's avatar
      ufs: tune bkops while power managment events · 374a246e
      Subhash Jadavani authored
      
      
      Add capability to control the auto bkops during suspend.
      If host explicitly enables the auto bkops (background operation) on device
      then only device would perform the bkops on its own. If auto bkops is not
      enabled explicitly and if the device reaches to state where it must do
      background operation, device would raise the urgent bkops exception event
      to host and then host will enable the auto bkops on device. This patch
      adds the option to choose whether auto bkops should be enabled during
      runtime suspend or not. Since we don't want to keep the device active to
      perform the non critical bkops, host will enable urgent bkops only.
      
      Keep auto-bkops enabled after resume if urgent bkops needed.
      If device bkops status shows that its in critical need of executing
      background operations, host should allow the device to continue doing
      background operations.
      Signed-off-by: default avatarSubhash Jadavani <subhashj@codeaurora.org>
      Signed-off-by: default avatarDolev Raviv <draviv@codeaurora.org>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      374a246e
    • Sahitya Tummala's avatar
      ufs: Add support for clock scaling using devfreq framework · 856b3483
      Sahitya Tummala authored
      
      
      The clocks for UFS device will be managed by generic DVFS (Dynamic
      Voltage and Frequency Scaling) framework within kernel. This devfreq
      framework works with different governors to scale the clocks. By default,
      UFS devices uses simple_ondemand governor which scales the clocks up if
      the load is more than upthreshold and scales down if the load is less than
      downthreshold.
      Signed-off-by: default avatarSahitya Tummala <stummala@codeaurora.org>
      Signed-off-by: default avatarDolev Raviv <draviv@codeaurora.org>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      856b3483
    • Sahitya Tummala's avatar
      ufs: Add support for clock gating · 1ab27c9c
      Sahitya Tummala authored
      
      
      The UFS controller clocks can be gated after certain period of
      inactivity, which is typically less than runtime suspend timeout.
      In addition to clocks the link will also be put into Hibern8 mode
      to save more power.
      
      The clock gating can be turned on by enabling the capability
      UFSHCD_CAP_CLK_GATING. To enable entering into Hibern8 mode as part of
      clock gating, set the capability UFSHCD_CAP_HIBERN8_WITH_CLK_GATING.
      
      The tracing events for clock gating can be enabled through debugfs as:
      echo 1 > /sys/kernel/debug/tracing/events/ufs/ufshcd_clk_gating/enable
      cat /sys/kernel/debug/tracing/trace_pipe
      Signed-off-by: default avatarSahitya Tummala <stummala@codeaurora.org>
      Signed-off-by: default avatarDolev Raviv <draviv@codeaurora.org>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      1ab27c9c
    • Dolev Raviv's avatar
      ufs: refactor configuring power mode · 7eb584db
      Dolev Raviv authored
      
      
      Sometimes, the device shall report its maximum power and speed
      capabilities, but we might not wish to configure it to use those
      maximum capabilities.
      This change adds support for the vendor specific host driver to
      implement power change notify callback.
      
      To enable configuring different power modes (number of lanes,
      gear number and fast/slow modes) it is necessary to split the
      configuration stage from the stage that reads the device max power mode.
      In addition, it is not required to read the configuration more than
      once, thus the configuration is stored after reading it once.
      Signed-off-by: default avatarDolev Raviv <draviv@codeaurora.org>
      Signed-off-by: default avatarYaniv Gardi <ygardi@codeaurora.org>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      7eb584db
    • Subhash Jadavani's avatar
      ufs: add UFS power management support · 57d104c1
      Subhash Jadavani authored
      
      
      This patch adds support for UFS device and UniPro link power management
      during runtime/system PM.
      
      Main idea is to define multiple UFS low power levels based on UFS device
      and UFS link power states. This would allow any specific platform or pci
      driver to choose the best suited low power level during runtime and
      system suspend based on their power goals.
      
      bkops handlig:
      To put the UFS device in sleep state when bkops is disabled, first query
      the bkops status from the device and enable bkops on device only if
      device needs time to perform the bkops.
      
      START_STOP handling:
      Before sending START_STOP_UNIT to the device well-known logical unit
      (w-lun) to make sure that the device w-lun unit attention condition is
      cleared.
      
      Write protection:
      UFS device specification allows LUs to be write protected, either
      permanently or power on write protected. If any LU is power on write
      protected and if the card is power cycled (by powering off VCCQ and/or
      VCC rails), LU's write protect status would be lost. So this means those
      LUs can be written now. To ensures that UFS device is power cycled only
      if the power on protect is not set for any of the LUs, check if power on
      write protect is set and if device is in sleep/power-off state & link in
      inactive state (Hibern8 or OFF state).
      If none of the Logical Units on UFS device is power on write protected
      then all UFS device power rails (VCC, VCCQ & VCCQ2) can be turned off if
      UFS device is in power-off state and UFS link is in OFF state. But current
      implementation would disable all device power rails even if UFS link is
      not in OFF state.
      
      Low power mode:
      If UFS link is in OFF state then UFS host controller can be power collapsed
      to avoid leakage current from it. Note that if UFS host controller is power
      collapsed, full UFS reinitialization will be required on resume to
      re-establish the link between host and device.
      Signed-off-by: default avatarSubhash Jadavani <subhashj@codeaurora.org>
      Signed-off-by: default avatarDolev Raviv <draviv@codeaurora.org>
      Signed-off-by: default avatarSujit Reddy Thumma <sthumma@codeaurora.org>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      57d104c1
    • Subhash Jadavani's avatar
      ufs: introduce well known logical unit in ufs · 0ce147d4
      Subhash Jadavani authored
      
      
      UFS device may have standard LUs and LUN id could be from 0x00 to 0x7F.
      UFS device specification use "Peripheral Device Addressing Format"
      (SCSI SAM-5) for standard LUs.
      
      UFS device may also have the Well Known LUs (also referred as W-LU) which
      again could be from 0x00 to 0x7F. For W-LUs, UFS device specification only
      allows the "Extended Addressing Format" (SCSI SAM-5) which means the W-LUNs
      would start from 0xC100 onwards.
      
      This means max. LUN number reported from UFS device could be 0xC17F hence
      this patch advertise the "max_lun" as 0xC17F which will allow SCSI mid
      layer to detect the W-LUs as well.
      
      But once the W-LUs are detected, UFSHCD driver may get the commands with
      SCSI LUN id upto 0xC17F but UPIU LUN id field is only 8-bit wide so it
      requires the mapping of SCSI LUN id to UPIU LUN id. This patch also add
      support for this mapping.
      Signed-off-by: default avatarSubhash Jadavani <subhashj@codeaurora.org>
      Signed-off-by: default avatarDolev Raviv <draviv@codeaurora.org>
      Signed-off-by: default avatarSujit Reddy Thumma <sthumma@codeaurora.org>
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      0ce147d4