1. 05 12月, 2016 3 次提交
  2. 29 11月, 2016 6 次提交
    • L
      mmc: block: delete packed command support · 03d640ae
      Linus Walleij 提交于
      I've had it with this code now.
      
      The packed command support is a complex hurdle in the MMC/SD block
      layer, around 500+ lines of code which was introduced in 2013 in
      
      commit ce39f9d1 ("mmc: support packed write command for eMMC4.5
      devices")
      commit abd9ac14 ("mmc: add packed command feature of eMMC4.5")
      
      ...and since then it has been rotting. The original author of the
      code has disappeared from the community and the mail address is
      bouncing.
      
      For the code to be exercised the host must flag that it supports
      packed commands, so in mmc_blk_prep_packed_list() which is called for
      every single request, the following construction appears:
      
      u8 max_packed_rw = 0;
      
      if ((rq_data_dir(cur) == WRITE) &&
          mmc_host_packed_wr(card->host))
              max_packed_rw = card->ext_csd.max_packed_writes;
      
      if (max_packed_rw == 0)
          goto no_packed;
      
      This has the following logical deductions:
      
      - Only WRITE commands can really be packed, so the solution is
        only half-done: we support packed WRITE but not packed READ.
        The packed command support has not been finalized by supporting
        reads in three years!
      
      - mmc_host_packed_wr() is just a static inline that checks
        host->caps2 & MMC_CAP2_PACKED_WR. The problem with this is
        that NO upstream host sets this capability flag! No driver
        in the kernel is using it, and we can't test it. Packed
        command may be supported in out-of-tree code, but I doubt
        it. I doubt that the code is even working anymore due to
        other refactorings in the MMC block layer, who would
        notice if patches affecting it broke packed commands?
        No one.
      
      - There is no Device Tree binding or code to mark a host as
        supporting packed read or write commands, just this flag
        in caps2, so for sure there are not any DT systems using
        it either.
      
      It has other problems as well: mmc_blk_prep_packed_list() is
      speculatively picking requests out of the request queue with
      blk_fetch_request() making the MMC/SD stack harder to convert
      to the multiqueue block layer. By this we get rid of an
      obstacle.
      
      The way I see it this is just cruft littering the MMC/SD
      stack.
      
      Cc: Namjae Jeon <namjae.jeon@samsung.com>
      Cc: Maya Erez <qca_merez@qca.qualcomm.com>
      Acked-by: NJaehoon Chung <jh80.chung@samsung.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      03d640ae
    • L
      mmc: delete is_first_req parameter from pre-request callback · d3c6aac3
      Linus Walleij 提交于
      The void (*pre_req) callback in the struct mmc_host_ops vtable
      is passing an argument "is_first_req" indicating whether this is
      the first request or not.
      
      None of the in-kernel users use this parameter: instead, since
      they all just do variants of dma_map* they use the DMA cookie
      to indicate whether a pre* callback has already been done for
      a request when they decide how to handle it.
      
      Delete the parameter from the callback and all users, as it is
      just pointless cruft.
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      Acked-by: NJaehoon Chung <jh80.chung@samsung.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      d3c6aac3
    • J
      mmc: dw_mmc: use the cookie's enum values for post/pre_req() · a4cc7eb4
      Jaehoon Chung 提交于
      This patch removed the meaningless value. Instead, use the cookie's enum
      values for executing correctly.
      Signed-off-by: NJaehoon Chung <jh80.chung@samsung.com>
      Tested-by: NHeiko Stuebner <heiko@sntech.de>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      a4cc7eb4
    • S
      mmc: core: Add helper to see if a host can be retuned · c820af5f
      Simon Horman 提交于
      This is in preparation for restoring saved tuning parameters
      when resuming the TMIO driver.
      Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>
      Acked-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
      Tested-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      c820af5f
    • L
      mmc: core: use enum mmc_blk_status properly · 8e8b3f51
      Linus Walleij 提交于
      There were several instances of code using the
      enum mmc_blk_status by arbitrarily converting it to an int and
      throwing it around to different functions. This makes the code
      hard to understand to may give rise to strange errors.
      
      Especially the function prototype mmc_start_req() had to be
      modified to take a pointer to an enum mmc_blk_status and the
      function pointer .err_check() inside struct mmc_async_req
      needed to return an enum mmc_blk_status.
      
      In every case: instead of assigning the block layer error code
      to an int, use the enum, also change the signature of all
      functions actually passing this enum to use the enum.
      
      To make it possible to use the enum everywhere applicable, move
      it to <linux/mmc/core.h> so that all code actually using it can
      also see it.
      
      An interesting case was encountered in the MMC test code which
      did not return a enum mmc_blk_status at all in the .err_check
      function supposed to check whether asynchronous requests worked
      or not: instead it returned a normal -ERROR or even the test
      frameworks internal error codes.
      
      The test code would also pass on enum mmc_blk_status codes as
      error codes inside the test code instead of converting them
      to the local RESULT_* codes.
      
      I have tried to fix all instances properly and run some tests
      on the result.
      
      Cc: Chunyan Zhang <zhang.chunyan@linaro.org>
      Cc: Baolin Wang <baolin.wang@linaro.org>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      8e8b3f51
    • S
      mmc: core: expose the capability of gpio card detect · 50fcbbbb
      Shawn Lin 提交于
      Add new helper API mmc_can_gpio_cd for slot-gpio to make
      host drivers know whether it supports gpio card detect.
      Signed-off-by: NShawn Lin <shawn.lin@rock-chips.com>
      Signed-off-by: NJaehoon Chung <jh80.chung@samsung.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      50fcbbbb
  3. 27 9月, 2016 4 次提交
    • W
      mmc: add define for R1 response without CRC · 51b50c96
      Wolfram Sang 提交于
      The core uses it for polling. Give drivers a proper define handle this
      case like for other response types.
      Signed-off-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      51b50c96
    • A
      mmc: core: Add support for sending commands during data transfer · 5163af5a
      Adrian Hunter 提交于
      A host controller driver exposes its capability using caps flag
      MMC_CAP_CMD_DURING_TFR. A driver with that capability can accept requests
      that are marked mrq->cap_cmd_during_tfr = true. Then the driver informs the
      upper layers when the command line is available for further commands by
      calling mmc_command_done(). Because of that, the driver will not then
      automatically send STOP commands, and it is the responsibility of the upper
      layer to send a STOP command if it is required.
      
      For requests submitted through the mmc_wait_for_req() interface, the caller
      sets mrq->cap_cmd_during_tfr = true which causes mmc_wait_for_req() in fact
      not to wait. The caller can then send commands that do not use the data
      lines. Finally the caller can wait for the transfer to complete by calling
      mmc_wait_for_req_done() which is now exported.
      
      For requests submitted through the mmc_start_req() interface, the caller
      again sets mrq->cap_cmd_during_tfr = true, but mmc_start_req() anyway does
      not wait. The caller can then send commands that do not use the data
      lines. Finally the caller can wait for the transfer to complete in the
      normal way i.e. calling mmc_start_req() again.
      
      Irrespective of how a cap_cmd_during_tfr request is started,
      mmc_is_req_done() can be called if the upper layer needs to determine if
      the request is done. However the appropriate waiting function (either
      mmc_wait_for_req_done() or mmc_start_req()) must still be called.
      
      The implementation consists primarily of a new completion
      mrq->cmd_completion which notifies when the command line is available for
      further commands. That completion is completed by mmc_command_done().
      When there is an ongoing data transfer, calls to mmc_wait_for_req() will
      automatically wait on that completion, so the caller does not have to do
      anything special.
      
      Note, in the case of errors, the driver may call mmc_request_done() without
      calling mmc_command_done() because mmc_request_done() always calls
      mmc_command_done().
      Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      5163af5a
    • G
      mmc: dw_mmc: add reset support to dwmmc host controller · d6786fef
      Guodong Xu 提交于
      Dwmmc host controller may in unknown state when entering kernel boot. One
      example is when booting from eMMC, bootloader need initialize MMC host
      controller into some state so it can read. In order to make sure MMC host
      controller in a clean initial state, this reset support is added.
      
      With this patch, a 'resets' property can be added into dw_mmc device
      tree node. The hardware logic is: dwmmc host controller IP receives a reset
      signal from a 'reset provider' (eg. power management unit). The 'resets'
      property points to this reset signal. So, during dwmmc driver probe,
      it can use this signal to reset itself.
      
      Refer to [1] for more information.
      
      [1] Documentation/devicetree/bindings/reset/reset.txt
      Signed-off-by: NGuodong Xu <guodong.xu@linaro.org>
      Signed-off-by: NXinwei Kong <kong.kongxinwei@hisilicon.com>
      Signed-off-by: NZhangfei Gao <zhangfei.gao@linaro.org>
      Reviewed-by: NShawn Lin <shawn.lin@rock-chips.com>
      Signed-off-by: NJaehoon Chung <jh80.chung@samsung.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      d6786fef
    • U
      mmc: sd: Export SD Status via “ssr” device attribute · 5275a652
      Uri Yanai 提交于
      The SD Status register contains several important fields related to the
      SD Card proprietary features.
      Those fields may be used by user space applications for vendor specific
      usage.
      None of those fields are exported today by the driver to user space.
      In this patch, we are reading the SD Status register and exporting
      (using MMC_DEV_ATTR) the SD Status register to the user space.
      Signed-off-by: NUri Yanai <uri.yanai@sandisk.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      5275a652
  4. 09 9月, 2016 1 次提交
  5. 25 7月, 2016 6 次提交
  6. 17 5月, 2016 1 次提交
    • A
      mmc: core: Add a facility to "pause" re-tuning · 7ff27609
      Adrian Hunter 提交于
      Re-tuning is not possible when switched to the RPMB
      partition.  However re-tuning should not be needed
      if re-tuning is done immediately before switching,
      a small set of operations is done, and then we
      immediately switch back to the main partition.
      
      To ensure that re-tuning can't be done for a short
      while, add a facility to "pause" re-tuning.
      
      The existing facility to hold / release re-tuning
      is used but it also flags re-tuning as needed to cause
      re-tuning before the next command (which will be the
      switch to RPMB).
      
      We also need to "unpause" in the recovery path, which
      is catered for by adding it to mmc_retune_disable().
      Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      7ff27609
  7. 12 5月, 2016 1 次提交
  8. 02 5月, 2016 6 次提交
  9. 29 2月, 2016 4 次提交
  10. 06 1月, 2016 1 次提交
  11. 22 12月, 2015 4 次提交
  12. 27 10月, 2015 1 次提交
    • C
      mmc: mmc: extend the mmc_send_tuning() · 9979dbe5
      Chaotian Jing 提交于
      The mmc_execute_tuning() has already prepared the opcode,
      there is no need to prepare it again at mmc_send_tuning(),
      and, there is a BUG of mmc_send_tuning() to determine the opcode
      by bus width, assume eMMC was running at HS200, 4bit mode,
      then the mmc_send_tuning() will overwrite the opcode from CMD21
      to CMD19, then got error.
      
      in addition, extend an argument of "cmd_error" to allow getting
      if there was cmd error when tune response.
      Signed-off-by: NChaotian Jing <chaotian.jing@mediatek.com>
      [Ulf: Rebased patch]
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      9979dbe5
  13. 26 10月, 2015 2 次提交
    • S
      mmc: dw_mmc: Add external dma interface support · 3fc7eaef
      Shawn Lin 提交于
      DesignWare MMC Controller can supports two types of DMA
      mode: external dma and internal dma. We get a RK312x platform
      integrated dw_mmc and ARM pl330 dma controller. This patch add
      edmac ops to support these platforms. I've tested it on RK31xx
      platform with edmac mode and RK3288 platform with idmac mode.
      Signed-off-by: NShawn Lin <shawn.lin@rock-chips.com>
      Signed-off-by: NJaehoon Chung <jh80.chung@samsung.com>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      3fc7eaef
    • D
      mmc: core: Add mmc_regulator_set_vqmmc() · 2086f801
      Douglas Anderson 提交于
      This adds logic to the MMC core to set VQMMC.  This is expected to be
      called by MMC drivers like dw_mmc as part of (or instead of) their
      start_signal_voltage_switch() callback.
      
      A few notes:
      
      * When setting the signal voltage to 3.3V we do our best to make VQMMC
        and VMMC match.  It's been reported that this makes some old cards
        happy since they were tested back in the day before UHS when VQMMC
        and VMMC were provided by the same regulator.  A nice side effect of
        this is that we don't end up on the hairy edge of VQMMC (2.7V),
        which some EEs claim is a little too close to the minimum for
        comfort.
        This is done in two steps. At first we try to find a VQMMC within
        a 0.3V tolerance of VMMC and if this is not supported by the
        supplying regulator we try to find a suitable voltage within the
        whole 2.7V-3.6V area of the spec.
      
      * The two step approach is currently necessary, as the used
        regulator_set_voltage_triplet(min, target, max) uses a simple
        implementation that just tries two basic steps:
      	regulator_set_voltage(target, max);
      	regulator_set_voltage(min, target);
        So with only one step with 2.7-3.6V borders, if a suitable voltage
        is a bit below VMMC, we would directly get the lowest 2.7V
        which some boards (like Rockchips) don't like at all.
      
      * When setting the signal voltage to 1.8V or 1.2V we aim for that
        specific voltage instead of picking the lowest one in the range.
      
      * We very purposely don't print errors in mmc_regulator_set_vqmmc().
        There are cases where the MMC core will try several different
        voltages and we don't want to pollute the logs.
      Signed-off-by: NDouglas Anderson <dianders@chromium.org>
      Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
      Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      2086f801