1. 26 Oct, 2015 5 commits
    • Douglas Anderson's avatar
      mmc: core: Add mmc_regulator_set_vqmmc() · 2086f801
      Douglas Anderson authored
      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: default avatarDouglas Anderson <dianders@chromium.org>
      Signed-off-by: default avatarHeiko Stuebner <heiko@sntech.de>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      2086f801
    • Heiko Stuebner's avatar
      mmc: core: move ocr-bit to voltage translation into separate function · 310c805e
      Heiko Stuebner authored
      We will shortly need the calculation of an ocr-bit to the actual
      voltage in a second place too, so move it from mmc_regulator_set_ocr
      to a common function mmc_ocrbitnum_to_vdd to make that possible.
      Signed-off-by: default avatarHeiko Stuebner <heiko@sntech.de>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      310c805e
    • Ulf Hansson's avatar
      mmc: core: Remove MMC_CLKGATE · 9eadcc05
      Ulf Hansson authored
      MMC_CLKGATE was once invented to save power by gating the bus clock at
      request inactivity. At that time it served its purpose. The modern way to
      deal with power saving for these scenarios, is by using runtime PM.
      
      Nowadays, several host drivers have deployed runtime PM, but for those
      that haven't and which still cares power saving at request inactivity,
      it's certainly time to deploy runtime PM as it has been around for several
      years now.
      
      To simplify code to mmc core and thus decrease maintenance efforts, this
      patch removes all code related to MMC_CLKGATE.
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Reviewed-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      9eadcc05
    • Hans de Goede's avatar
      mmc: Wait for card_busy before starting sdio requests · 5d3f6ef0
      Hans de Goede authored
      Some sdio wifi chips will not work properly if we try to start new
      sdio-rw requests while the device is signalling that it is busy.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      5d3f6ef0
    • Ulf Hansson's avatar
      mmc: core: Keep host claimed while invoking mmc_power_off|up() · 8d1ffc8c
      Ulf Hansson authored
      As mmc_claim_host() invokes pm_runtime_get_sync() for the mmc host device,
      it's important that the host is kept claimed for *all* accesses to it via
      the host_ops callbacks.
      
      In some code paths for SDIO, particularly related to the PM support,
      mmc_power_off|up() is invoked without keeping the host claimed. Let's fix
      these.
      
      Moreover, mmc_start|stop_host() also invokes mmc_power_off|up() without
      claiming the host, let's fix these as well.
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Acked-by: default avatarKishon Vijay Abraham I <kishon@ti.com>
      8d1ffc8c
  2. 30 Sep, 2015 1 commit
  3. 31 Aug, 2015 1 commit
    • Jialing Fu's avatar
      mmc: core: fix race condition in mmc_wait_data_done · 71f8a4b8
      Jialing Fu authored
      The following panic is captured in ker3.14, but the issue still exists
      in latest kernel.
      ---------------------------------------------------------------------
      [   20.738217] c0 3136 (Compiler) Unable to handle kernel NULL pointer dereference
      at virtual address 00000578
      ......
      [   20.738499] c0 3136 (Compiler) PC is at _raw_spin_lock_irqsave+0x24/0x60
      [   20.738527] c0 3136 (Compiler) LR is at _raw_spin_lock_irqsave+0x20/0x60
      [   20.740134] c0 3136 (Compiler) Call trace:
      [   20.740165] c0 3136 (Compiler) [<ffffffc0008ee900>] _raw_spin_lock_irqsave+0x24/0x60
      [   20.740200] c0 3136 (Compiler) [<ffffffc0000dd024>] __wake_up+0x1c/0x54
      [   20.740230] c0 3136 (Compiler) [<ffffffc000639414>] mmc_wait_data_done+0x28/0x34
      [   20.740262] c0 3136 (Compiler) [<ffffffc0006391a0>] mmc_request_done+0xa4/0x220
      [   20.740314] c0 3136 (Compiler) [<ffffffc000656894>] sdhci_tasklet_finish+0xac/0x264
      [   20.740352] c0 3136 (Compiler) [<ffffffc0000a2b58>] tasklet_action+0xa0/0x158
      [   20.740382] c0 3136 (Compiler) [<ffffffc0000a2078>] __do_softirq+0x10c/0x2e4
      [   20.740411] c0 3136 (Compiler) [<ffffffc0000a24bc>] irq_exit+0x8c/0xc0
      [   20.740439] c0 3136 (Compiler) [<ffffffc00008489c>] handle_IRQ+0x48/0xac
      [   20.740469] c0 3136 (Compiler) [<ffffffc000081428>] gic_handle_irq+0x38/0x7c
      ----------------------------------------------------------------------
      Because in SMP, "mrq" has race condition between below two paths:
      path1: CPU0: <tasklet context>
        static void mmc_wait_data_done(struct mmc_request *mrq)
        {
           mrq->host->context_info.is_done_rcv = true;
           //
           // If CPU0 has just finished "is_done_rcv = true" in path1, and at
           // this moment, IRQ or ICache line missing happens in CPU0.
           // What happens in CPU1 (path2)?
           //
           // If the mmcqd thread in CPU1(path2) hasn't entered to sleep mode:
           // path2 would have chance to break from wait_event_interruptible
           // in mmc_wait_for_data_req_done and continue to run for next
           // mmc_request (mmc_blk_rw_rq_prep).
           //
           // Within mmc_blk_rq_prep, mrq is cleared to 0.
           // If below line still gets host from "mrq" as the result of
           // compiler, the panic happens as we traced.
           wake_up_interruptible(&mrq->host->context_info.wait);
        }
      
      path2: CPU1: <The mmcqd thread runs mmc_queue_thread>
        static int mmc_wait_for_data_req_done(...
        {
           ...
           while (1) {
                 wait_event_interruptible(context_info->wait,
                         (context_info->is_done_rcv ||
                          context_info->is_new_req));
           	   static void mmc_blk_rw_rq_prep(...
                 {
                 ...
                 memset(brq, 0, sizeof(struct mmc_blk_request));
      
      This issue happens very coincidentally; however adding mdelay(1) in
      mmc_wait_data_done as below could duplicate it easily.
      
         static void mmc_wait_data_done(struct mmc_request *mrq)
         {
           mrq->host->context_info.is_done_rcv = true;
      +    mdelay(1);
           wake_up_interruptible(&mrq->host->context_info.wait);
          }
      
      At runtime, IRQ or ICache line missing may just happen at the same place
      of the mdelay(1).
      
      This patch gets the mmc_context_info at the beginning of function, it can
      avoid this race condition.
      Signed-off-by: default avatarJialing Fu <jlfu@marvell.com>
      Tested-by: default avatarShawn Lin <shawn.lin@rock-chips.com>
      Fixes: 2220eedf ("mmc: fix async request mechanism ....")
      Signed-off-by: default avatarShawn Lin <shawn.lin@rock-chips.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      71f8a4b8
  4. 27 Aug, 2015 2 commits
  5. 17 Aug, 2015 1 commit
  6. 01 Jun, 2015 9 commits
  7. 04 May, 2015 1 commit
  8. 31 Mar, 2015 1 commit
    • Ulf Hansson's avatar
      mmc: core: Enable runtime PM management of host devices · 9250aea7
      Ulf Hansson authored
      Currently those host drivers which have deployed runtime PM, deals with
      the runtime PM reference counting entirely by themselves.
      
      Since host drivers don't know when the core will send the next request
      through some of the host_ops callbacks, they need to handle runtime PM
      get/put between each an every request.
      
      In quite many cases this has some negative effects, since it leads to a
      high frequency of scheduled runtime PM suspend operations. That due to
      the runtime PM reference count will normally reach zero in-between
      every request.
      
      We can decrease that frequency, by enabling the core to deal with
      runtime PM reference counting of the host device. Since the core often
      knows that it will send a seqeunce of requests, it makes sense for it
      to keep a runtime PM reference count during these periods.
      
      More exactly, let's increase the runtime PM reference count by invoking
      pm_runtime_get_sync() from __mmc_claim_host(). Restore that action by
      invoking pm_runtime_mark_last_busy() and pm_runtime_put_autosuspend()
      in mmc_release_host(). In this way a runtime PM reference count will be
      kept during the complete cycle of a claim -> release host.
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Acked-by: default avatarAdrian Hunter <adrian.hunter@intel.com>
      Acked-by: default avatarKonstantin Dorfman <kdorfman@codeaurora.org>
      9250aea7
  9. 27 Mar, 2015 1 commit
  10. 03 Feb, 2015 1 commit
    • Ulf Hansson's avatar
      mmc: core: Invoke mmc_pwrseq_post_power_on() prior MMC_POWER_ON state · 4febb7e2
      Ulf Hansson authored
      Host drivers have different ways to sends their "init stream" to the
      card. Some need to do it as part of a request, some do it from the
      ->set_ios() callback in the MMC_POWER_ON state and some don't send an
      "init stream" at all.
      
      To be able to use the reset GPIOs from the simple MMC power sequence
      provider, the card need to be powered and the "init stream" must not
      have been sent.
      
      To cope with these requirements, invoke mmc_pwrseq_post_power_on()
      prior we change the state to MMC_POWER_ON in mmc_power_up().
      
      Host drivers shall perform power up operations in the MMC_POWER_UP
      state. Unfortunate three hosts (au1xmmc, cb710-mmc and toshsd) don't
      conform to this expectation. Instead those ignore the MMC_POWER_UP
      state and delays their power up operations to the MMC_POWER_ON state.
      
      Those hosts needs to change their behavior to enable proper support for
      the simple MMC power sequence provider.
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Reviewed-by: default avatarJavier Martinez Canillas <javier.martinez@collabora.co.uk>
      Tested-by: default avatarJavier Martinez Canillas <javier.martinez@collabora.co.uk>
      4febb7e2
  11. 29 Jan, 2015 1 commit
  12. 28 Jan, 2015 1 commit
    • Ulf Hansson's avatar
      mmc: core: Initial support for MMC power sequences · 3aa8793f
      Ulf Hansson authored
      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: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Tested-by: default avatarJavier Martinez Canillas <javier.martinez@collabora.co.uk>
      Reviewed-by: default avatarJavier Martinez Canillas <javier.martinez@collabora.co.uk>
      3aa8793f
  13. 19 Jan, 2015 5 commits
  14. 26 Nov, 2014 2 commits
    • Vincent Yang's avatar
      mmc: core: hold SD Clock before CMD11 during Signal · c6eb5880
      Vincent Yang authored
      Voltage Switch Procedure
      
      This patch is to fix an issue found on mb86s7x platforms.
      
      [symptom]
      There are some UHS-1 SD memory cards sometimes cannot be detected correctly,
      e.g., Transcend 600x SDXC 64GB UHS-1 memory card.
      During Signal Voltage Switch Procedure, failure to switch is indicated
      by the card holding DAT[3:0] low.
      
      [analysis]
      According to SD Host Controller Simplified Specification Version 3.00
      chapter 3.6.1, the Signal Voltage Switch Procedure should be:
      (1) Check S18A; (2) Issue CMD11; (3) Check CMD 11 response;
      (4) Stop providing SD clock; (5) Check DAT[3:0] should be 0000b;
      (6) Set 1.8V Signal Enable; (7) Wait 5ms; (8) Check 1.8V Signal Enable;
      (9) Provide SD Clock; (10) Wait 1ms; (11) Check DAT[3:0] should be 1111b;
      (12) error handling
      
      With CONFIG_MMC_CLKGATE=y, sometimes there is one more gating/un-gating
      SD clock between (2) and (3). In this case, some UHS-1 SD cards will hold
      DAT[3:0] 0000b at (11) and thus fails Signal Voltage Switch Procedure.
      
      [solution]
      By mmc_host_clk_hold() before CMD11, the additional gating/un-gating
      SD clock between (2) and (3) can be prevented and thus no failure at (11).
      It has been verified with many UHS-1 SD cards on mb86s7x platforms and
      works correctly.
      Signed-off-by: default avatarVincent Yang <Vincent.Yang@tw.fujitsu.com>
      Reviewed-by: default avatarJohan Rudholm <jrudholm@gmail.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      c6eb5880
    • Johan Rudholm's avatar
      mmc: core: consistent handling of initial values · 2d079c43
      Johan Rudholm authored
      mmc_do_hw_reset(), mmc_power_up() and mmc_power_off() all set similar
      initial values for bus_mode, bus_width, chip_select and timing. Let's
      make this handling simpler and more consistent by sticking them
      together in a common function. This will introduce small changes in
      behavior in the following places:
      
      mmc_power_off():
      
        For SPI hosts, explicitly set bus_mode = MMC_BUSMODE_PUSHPULL and
        chip_select = MMC_CS_HIGH, before we left them as they were.
      
        For non-SPI hosts, set bus_mode = MMC_BUSMODE_PUSHPULL instead of
        MMC_BUSMODE_OPENDRAIN as before.
      
        These two changes should not be a problem since the device will be
        powered off anyway.
      
      mmc_do_hw_reset():
      
        Always set bus_mode = MMC_BUSMODE_PUSHPULL, as required by SD/SDIO
        cards. MMC cards require MMC_BUSMODE_OPENDRAIN, but this is taken
        care of by mmc_init_card() and mmc_attach_mmc().
      Signed-off-by: default avatarJohan Rudholm <johanru@axis.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      2d079c43
  15. 10 Nov, 2014 5 commits
    • Johan Rudholm's avatar
      ad89fcb2
    • Ulf Hansson's avatar
      mmc: core: Use mmc_get_ext_csd() instead of mmc_send_ext_csd() · b2cada73
      Ulf Hansson authored
      By using mmc_get_ext_csd() in favor of mmc_send_ext_csd, we decrease
      code duplication.
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      b2cada73
    • Srinivas Kandagatla's avatar
      mmc: core: fix prepared requests while doing bkops · 64b12a68
      Srinivas Kandagatla authored
      While starting the bkops the previously prepared request should be canceled
      and restarted after the bkops. As the prepared resource might already
      setup the dma channels and ready to be started. Now with the arrival of bkops
      request this prepared request can be serviced ONLY after the bkops. So
      holding on to the prepared request in the host driver is confusing at
      this point in time, so it makes sense to cleanup such dangling requests and
      reissue this request once bkops is done.
      Canceling the prepared request would give opportunity to the host drivers
      to perform cleanup on the prepared request.
      
      Without this patch host drivers like mmci gets confused when a blocking
      request like send_ext_csd(CMD8) is issued while there is already a prepared
      request. With the help of this patch, the driver can better manage such
      blocking requests and cleanup the prepared requests which are not started yet.
      
      Without this patch I hit below crash on Qualcomm APQ8064 based IFC6410 board
      with mmci host driver.
      
      mmci-pl18x 12400000.sdcc: error during DMA transfer!
      Unable to handle kernel paging request at virtual address 40000000
      pgd = c0204000
      [40000000] *pgd=00000000
      Internal error: Oops: 805 [#1] SMP ARM
      Modules linked in: ipv6 ath6kl_sdio ath6kl_core
      CPU: 0 PID: 0 Comm: swapper/0 Tainted: G        W      3.17.0-rc7-linaro-multi-v7 #1
      task: c0c9d7e0 ti: c0c92000 task.ti: c0c92000
      PC is at v7_dma_inv_range+0x34/0x4c
      LR is at __dma_page_dev_to_cpu+0x80/0x100
      pc : [<c021efc0>]    lr : [<c021af18>]    psr: 400f0193
      sp : c0c93e20  ip : c0c9a478  fp : c08ea538
      r10: c0c9f548  r9 : 00000002  r8 : e97d9000
      r7 : 00000200  r6 : c0c9d504  r5 : c0db0880  r4 : 00000000
      r3 : 0000003f  r2 : 00000040  r1 : 40000200  r0 : 40000000
      Flags: nZcv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
      Control: 10c5787d  Table: a9ef406a  DAC: 00000015
      Process swapper/0 (pid: 0, stack limit = 0xc0c92250)
      Stack: (0xc0c93e20 to 0xc0c94000)
      3e20: c021f058 e9a17178 e9a171bc e99dfd6c 00000001 00000001 e995de10 00000002
      3e40: 00000000 c021b574 00000000 c04bc4a4 00000000 e9b49ac0 c0ce6e6c e99dfda4
      3e60: 00000088 e9810780 c0d8291c c072ea58 00000000 c072d3fc 00000000 c072f534
      3e80: 00000000 e9b49ac0 00000100 c0c9a444 00000088 c072f6b4 c072f5d4 e9d40080
      3ea0: e98107dc 00000000 00000000 c0280a60 00000000 7d55bf61 e9810780 e98107dc
      3ec0: 00000000 f0002000 c0d460e8 c0d460e8 c0c92000 c0280b60 e9810780 c0ce7190
      3ee0: 00000000 c028369c c02835f4 00000088 00000088 c0280278 c0c8ec70 c020f080
      3f00: f000200c c0c9a958 c0c93f28 c02088e4 c04bd630 c04bd5bc 200f0013 ffffffff
      3f20: c0c93f5c c0212800 00000001 a987c000 c0c93f3c c04bd574 00000000 0000015b
      3f40: ea7a0e40 00000000 c0d460e8 c0d460e8 c0c92000 c08ea538 29b12000 c0c93f70
      3f60: c04bd630 c04bd5bc 200f0013 ffffffff c04bd574 c071bd24 7d50c9b4 c0719a44
      3f80: 7d50c9b4 0000015b c0c9a498 c0c92028 c0c9a498 c0c9a4fc ea7a0e40 c0c8ee38
      3fa0: c0d460e8 c0276198 00000000 c0d8291a 00000000 c0c9a400 00000000 c0be0bc4
      3fc0: ffffffff ffffffff c0be05f8 00000000 00000000 c0c533d8 c0d82ed4 c0c9a47c
      3fe0: c0c533d4 c0c9e870 8020406a 511f06f0 00000000 80208074 00000000 00000000
      [<c021efc0>] (v7_dma_inv_range) from [<c021af18>] (__dma_page_dev_to_cpu+0x80/0x100)
      [<c021af18>] (__dma_page_dev_to_cpu) from [<c021b574>] (arm_dma_unmap_sg+0x5c/0x84)
      [<c021b574>] (arm_dma_unmap_sg) from [<c072ea58>] (mmci_dma_unmap.isra.16+0x60/0x74)
      [<c072ea58>] (mmci_dma_unmap.isra.16) from [<c072f534>] (mmci_data_irq+0x1fc/0x29c)
      [<c072f534>] (mmci_data_irq) from [<c072f6b4>] (mmci_irq+0xe0/0x114)
      [<c072f6b4>] (mmci_irq) from [<c0280a60>] (handle_irq_event_percpu+0x78/0x134)
      [<c0280a60>] (handle_irq_event_percpu) from [<c0280b60>] (handle_irq_event+0x44/0x64)
      [<c0280b60>] (handle_irq_event) from [<c028369c>] (handle_fasteoi_irq+0xa8/0x1a8)
      [<c028369c>] (handle_fasteoi_irq) from [<c0280278>] (generic_handle_irq+0x2c/0x3c)
      [<c0280278>] (generic_handle_irq) from [<c020f080>] (handle_IRQ+0x40/0x90)
      [<c020f080>] (handle_IRQ) from [<c02088e4>] (gic_handle_irq+0x38/0x68)
      [<c02088e4>] (gic_handle_irq) from [<c0212800>] (__irq_svc+0x40/0x54)
      Exception stack(0xc0c93f28 to 0xc0c93f70)
      3f20:                   00000001 a987c000 c0c93f3c c04bd574 00000000 0000015b
      3f40: ea7a0e40 00000000 c0d460e8 c0d460e8 c0c92000 c08ea538 29b12000 c0c93f70
      3f60: c04bd630 c04bd5bc 200f0013 ffffffff
      [<c0212800>] (__irq_svc) from [<c04bd5bc>] (msm_cpu_pm_enter_sleep+0x48/0x4c)
      [<c04bd5bc>] (msm_cpu_pm_enter_sleep) from [<c071bd24>] (qcom_lpm_enter_spc+0x20/0x2c)
      [<c071bd24>] (qcom_lpm_enter_spc) from [<c0719a44>] (cpuidle_enter_state+0x44/0xf0)
      [<c0719a44>] (cpuidle_enter_state) from [<c0276198>] (cpu_startup_entry+0x1f4/0x238)
      [<c0276198>] (cpu_startup_entry) from [<c0be0bc4>] (start_kernel+0x384/0x390)
      Code: 1e070f3e e1110003 e1c11003 1e071f3e (ee070f36)
      ---[ end trace cf6cb3f6432c9834 ]---
      Kernel panic - not syncing: Fatal exception in interrupt
      Reported-by: default avatarNicolas Dechesne <nicolas.dechesne@linaro.org>
      Signed-off-by: default avatarSrinivas Kandagatla <srinivas.kandagatla@linaro.org>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      64b12a68
    • Andrew Gabbasov's avatar
      mmc: core: Add debug message for SET_BLOCK_COUNT result · fc75b708
      Andrew Gabbasov authored
      The debug messages with commands execution results, that are printed
      after processing the request, do not include results of sbc (set block count)
      part of request. Add the debug message for that part too.
      Signed-off-by: default avatarAndrew Gabbasov <andrew_gabbasov@mentor.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      fc75b708
    • Andrew Gabbasov's avatar
      mmc: core: Initialize SET_BLOCK_COUNT request fields · cce411e6
      Andrew Gabbasov authored
      Some request fields are initialized just before request processing
      for sanity purposes. This is done for command, data, and stop parts
      of the request, but not for sbc (set block count) part. Add such
      initialization for that part too.
      Signed-off-by: default avatarAndrew Gabbasov <andrew_gabbasov@mentor.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      cce411e6
  16. 29 Sep, 2014 1 commit
  17. 24 Sep, 2014 2 commits