Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 10 11月, 2014 4 次提交
    • D
      mmc: sdhci-esdhc-imx: don't exit in case of no pinctrl states · cd529af7
      由 Dirk Behme 提交于 
      The commit ad93220d ("mmc: sdhci-esdhc-imx: change pinctrl state
according to uhs mode") exits the probe in case there are no valid
pinctrl states found.

As there are configurations doing the pin mux properly in the boot
loader, don't exit. Just warn, but go on in case if there are no
pinctrl states in the device tree.
Signed-off-by: NDirk Behme <dirk.behme@de.bosch.com>
Signed-off-by: NAndrew Gabbasov <andrew_gabbasov@mentor.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      cd529af7
    • M
      mmc: mxcmmc: fix the default value for available voltages into mxcmci_probe · 18a09806
      由 Matteo Facchinetti 提交于 
      If available voltages are not given, mmc_regulator_get_supply() function
returns 0 and mxcmmc driver doesn't set a value for ocr_avail mask.

In accordance with the comment in platform_data/mmc-mxcmmc.h,
fix it, assuming MMC_VDD_32_33 | MMC_VDD_33_34 as default value.
Signed-off-by: NMatteo Facchinetti <matteo.facchinetti@sirius-es.it>
Reviewed-by: NSascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      18a09806
    • M
      mmc: mxcmmc: fix race condition when dma finish a data transfer · adfa5703
      由 Matteo Facchinetti 提交于 
      During a read of data block using dma, driver might have two ways to finish to read
and free the resources:
1) checking STATUS_DATA_TRANS_DONE mask, in the mxcmci_irq() routine
   (pending to mmc irq)
2) mxmmc driver, registers also a mxcmci_dma_callback() and when transfer is finished,
   dma driver calls this callback. (pending to dma irq)
Both ways are concurrent with each other.

Race condition happens when following events occur:
/* (1) mxcmci driver start data transfer */
         158.418970: mpc_dma_execute: mpc_dma_execute(): will_access_peripheral start cid=31
         158.418976: mpc_dma_issue_pending <-mxcmci_request
         158.418983: mxcmci_start_cmd <-mxcmci_request
/* (2) mxcmci driver receive mmc irq */
         158.419656: mxcmci_irq <-handle_irq_event_percpu
         158.419692: mxcmci_read_response <-mxcmci_irq
/* (3) mxcmci driver checks that transfer is complete and call mxcmci_finish_data() */
         158.419726: mxcmci_data_done <-mxcmci_irq
         158.419729: mxcmci_finish_data <-mxcmci_data_done
         158.419733: dma_direct_unmap_sg <-mxcmci_finish_data
         158.419736: mxcmci_swap_buffers.isra.24 <-mxcmci_finish_data
         158.419762: mxcmci_read_response <-mxcmci_data_done
/* (4) mxcmci driver (no dma): send stop command */
         158.419765: mxcmci_start_cmd <-mxcmci_data_done
/* (5) mxcmci driver (no dma): receive the stop command irq response */
         158.419782: mxcmci_irq <-handle_irq_event_percpu
         158.419812: mxcmci_read_response <-mxcmci_irq
         158.419843: mxcmci_finish_request <-mxcmci_irq
/* (6) dma driver: receive dma irq (finish data transfer) related by request on step 1 */
         158.419853: mpc_dma_irq <-handle_irq_event_percpu
         158.420001: mpc_dma_irq_process <-mpc_dma_irq
         158.420004: mpc_dma_irq_process <-mpc_dma_irq
/* (7) dma driver: start dma tasklet to finish the dma irq handling */
         158.420008: mpc_dma_irq_process: mpc_dma_irq_process(): completed ch:31
/* (8) mxcmci driver: start next data transfer using dma */
         158.420174: mxcmci_request <-mmc_start_req
         158.420182: dma_direct_map_sg <-mxcmci_request
         158.420192: mpc_dma_prep_slave_sg <-mxcmci_request
/* (9) dma driver: schedule irq tasklet and execute mxcmci dma driver callback */
         158.420250: mpc_dma_tasklet <-tasklet_action
         158.420254: mpc_dma_process_completed <-tasklet_action
         158.420267: mxcmci_dma_callback <-mpc_dma_process_completed
/* ERROR!!! (10) mxcmci driver callback works on dma data related to the step 1
                 that is already finished */
         158.420271: mxcmci_data_done <-mpc_dma_process_completed
         158.420273: mxcmci_finish_data <-mxcmci_data_done
/* ERROR!!! (11) mxcmci driver: clear data that should be used by step 8 and
                 send an other mmc stop command (already sended on step 4) */
         158.420276: dma_direct_unmap_sg <-mxcmci_finish_data
         158.420279: mxcmci_swap_buffers.isra.24 <-mxcmci_finish_data
         158.420330: mxcmci_read_response <-mxcmci_data_done
         158.420333: mxcmci_start_cmd <-mxcmci_data_done
         158.420338: dma_run_dependencies <-mpc_dma_process_completed
...
...
...
         168.474223: mxcmci_watchdog <-call_timer_fn
         168.474236: mxcmci_watchdog: mxcmci_watchdog
         168.474397: mpc_dma_device_control <-mxcmci_watchdog

In accordance with the other drivers that using the dma engine,
fix it, leaving *only* to dma driver the complete control to
ending the read operation.

Removing STATUS_READ_OP_DONE event activation, has as effect
to force mxcmci driver to handle the finish data transfer only
by mxcmci dma callback.
Signed-off-by: NMatteo Facchinetti <matteo.facchinetti@sirius-es.it>
Acked-by: NSascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      adfa5703
    • P
      mmc: sdhci-pci-o2micro: Fix Dell E5440 issue · 6380ea09
      由 Peter Guo 提交于 
      Fix Dell E5440 when reboot Linux, can't find o2micro sd host chip issue.

Fixes: 01acf691 (mmc: sdhci-pci: add support of O2Micro/BayHubTech SD hosts)
Signed-off-by: NPeter Guo <peter.guo@bayhubtech.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      6380ea09
  3. 06 10月, 2014 3 次提交
  5. 03 10月, 2014 8 次提交
  7. 02 10月, 2014 1 次提交
  9. 29 9月, 2014 1 次提交
    • A
      mmc: atmel-mci: fix mismatched section on atmci_cleanup_slot · 5fef365b
      由 Arnd Bergmann 提交于 
      As of 528bc780 ("mmc: atmel-mci: Release mmc resources on failure in probe"),
the atmci_probe() function calls atmci_cleanup_slot in the failure path.

This causes a new warning whenever the driver is built:

WARNING: drivers/mmc/host/built-in.o(.init.text+0xa04): Section mismatch in reference from the function atmci_probe() to the function .exit.text:atmci_cleanup_slot()
The function __init atmci_probe() references
a function __exit atmci_cleanup_slot().

Gcc correctly warns about this function getting dropped in the link stage
for the built-in case, which would cause undefined behavior when this error
path is hit. The solution is to simply drop the __exit annotation.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Fixes: 528bc780 ("mmc: atmel-mci: Release mmc resources on failure in probe")
Acked-by: NLudovic Desroches <ludovic.desroches@atmel.com>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      5fef365b
  11. 24 9月, 2014 5 次提交
  13. 23 9月, 2014 3 次提交
    • S
      mmc: Consolidate emmc tuning blocks · 48d11e06
      由 Stephen Boyd 提交于 
      The same tuning block exists in the dw_mmc h.c and sdhci-msm.c
files. Move these into mmc.c so that they can be shared across
drivers.
Reported-by: NJaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      48d11e06
    • S
      mmc: sdhci-msm: Make tuning block table endian agnostic · ffed1b94
      由 Stephen Boyd 提交于 
      If we're tuning on a big-endian CPU we'll never determine we properly
tuned the device because we compare the data we received from the
controller with a table that assumes the CPU is little-endian.
Change the table to be an array of bytes instead of 32-bit words
so we can use memcmp() without needing to byte-swap every word
depending on the endianess of the CPU.

Cc: Asutosh Das <asutoshd@codeaurora.org>
Cc: Venkat Gopalakrishnan <venkatg@codeaurora.org>
Reviewed-by: NGeorgi Djakov <gdjakov@mm-sol.com>
Fixes: 415b5a75 "mmc: sdhci-msm: Add platform_execute_tuning implementation"
Signed-off-by: NStephen Boyd <sboyd@codeaurora.org>
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      ffed1b94
    • S
      mmc: don't request CD IRQ until mmc_start_host() · d4d11449
      由 Stephen Warren 提交于 
      As soon as the CD IRQ is requested, it can trigger, since it's an
externally controlled event. If it does, delayed_work host->detect will
be scheduled.

Many host controller probe()s are roughly structured as:

*_probe() {
    host = sdhci_pltfm_init();
    mmc_of_parse(host->mmc);
    rc = sdhci_add_host(host);
    if (rc) {
        sdhci_pltfm_free();
        return rc;
    }

In 3.17, CD IRQs can are enabled quite early via *_probe() ->
mmc_of_parse() -> mmc_gpio_request_cd() -> mmc_gpiod_request_cd_irq().

Note that in linux-next, mmc_of_parse() calls mmc_gpio*d*_request_cd()
rather than mmc_gpio_request_cd(), and mmc_gpio*d*_request_cd() doesn't
call mmc_gpiod_request_cd_irq(). However, this issue still exists if
mmc_gpio_request_cd() is called directly before mmc_start_host().

sdhci_add_host() may fail part way through (e.g. due to deferred
probe for a vmmc regulator), and sdhci_pltfm_free() does nothing to
unrequest the CD IRQ nor cancel the delayed_work. sdhci_pltfm_free() is
coded to assume that if sdhci_add_host() failed, then the delayed_work
cannot (or should not) have been triggered.

This can lead to the following with CONFIG_DEBUG_OBJECTS_* enabled, when
kfree(host) is eventually called inside sdhci_pltfm_free():

WARNING: CPU: 2 PID: 6 at lib/debugobjects.c:263 debug_print_object+0x8c/0xb4()
ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x18

The object being complained about is host->detect.

There's no need to request the CD IRQ so early; mmc_start_host() already
requests it. For most SDHCI hosts at least, the typical call path that
does this is: *_probe() -> sdhci_add_host() -> mmc_add_host() ->
mmc_start_host(). Therefore, remove the call to mmc_gpiod_request_cd_irq()
from mmc_gpio_request_cd(). This also matches mmc_gpio*d*_request_cd(),
which already doesn't call mmc_gpiod_request_cd_irq().

However, some host controller drivers call mmc_gpio_request_cd() after
mmc_start_host() has already been called, and assume that this will also
call mmc_gpiod_request_cd_irq(). Update those drivers to explicitly call
mmc_gpiod_request_cd_irq() themselves. Ideally, these drivers should be
modified to move their call to mmc_gpio_request_cd() before their call
to mmc_add_host(). However that's too large a change for stable.

This solves the problem (eliminates the kernel error message above),
since it guarantees that the IRQ can't trigger before mmc_start_host()
is called.

The critical point here is that once sdhci_add_host() calls
mmc_add_host() -> mmc_start_host(), sdhci_add_host() is coded not to
fail. In other words, if there's a chance that mmc_start_host() may have
been called, and CD IRQs triggered, and the delayed_work scheduled,
sdhci_add_host() won't fail, and so cleanup is no longer via
sdhci_pltfm_free() (which doesn't free the IRQ or cancel the work queue)
but instead must be via sdhci_remove_host(), which calls mmc_remove_host()
-> mmc_stop_host(), which does free the IRQ and cancel the work queue.

CC: Russell King <linux@arm.linux.org.uk>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Alexandre Courbot <acourbot@nvidia.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
Cc: <stable@vger.kernel.org> # v3.15+
Signed-off-by: NUlf Hansson <ulf.hansson@linaro.org>
      d4d11449
  15. 20 9月, 2014 2 次提交
  17. 19 9月, 2014 1 次提交
  19. 10 9月, 2014 3 次提交
  21. 09 9月, 2014 9 次提交