- 28 May, 2020 40 commits
-
-
Ulf Hansson authored
Using a fixed 3s polling timeout for all commands with R1B responses is a bit problematic. For some commands it means waiting longer than needed for the polling to be aborted, which may not a big issue, but still. For other commands, like for an erase (CMD38), may require longer timeouts than 3s. In these cases, we may end up treating the command as it failed, while it just needed some more time to complete successfully. Fix the problem by respecting the cmd->busy_timeout, which is provided by the mmc core. Cc: Jonathan Neuschäfer <j.neuschaefer@gmx.net> Cc: Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Link: https://lore.kernel.org/r/20200414161413.3036-19-ulf.hansson@linaro.org
-
Ulf Hansson authored
Clarify the use of r1b_timeout, by renaming it to MMC_SPI_R1B_TIMEOUT_MS and by dropping the corresponding confusing comment about it. Additionally, let's also add a new define, MMC_SPI_INIT_TIMEOUT_MS and use it during the initialization. Even if these two defines are given the same value, the split makes it easier to understand them. Cc: Jonathan Neuschäfer <j.neuschaefer@gmx.net> Cc: Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Ulf Hansson authored
Using a fixed 1s timeout for all commands (and data transfers) is a bit problematic. For some commands it means waiting longer than needed for the timer to expire, which may not a big issue, but still. For other commands, like for an erase (CMD38) that uses a R1B response, may require longer timeouts than 1s. In these cases, we may end up treating the command as it failed, while it just needed some more time to complete successfully. Fix the problem by respecting the cmd->busy_timeout, which is provided by the mmc core. Cc: Bruce Chang <brucechang@via.com.tw> Cc: Harald Welte <HaraldWelte@viatech.com> Signed-off-by:
-
Ulf Hansson authored
Some commands uses R1B responses, which means the card may assert the DAT0 line to signal busy for a period of time, after it has received the command. The mmc core normally specifies the busy period for the command in the cmd->busy_timeout. Ideally the driver should respect it, but that requires quite some update of the code, so let's defer that to someone with the HW at hand. Instead, let's inform the mmc core about the maximum supported busy timeout in ->max_busy_timeout during ->probe(). This value corresponds to the fixed 1s timeout used by tifm_sd. In this way, we let the mmc core validate the needed timeout, which may lead to that it converts from a R1B into a R1 response and then use CMD13 to poll for busy completion. In other words, this change enables support for commands with longer busy periods than 1s, like erase (CMD38) for example. Cc: Alex Dubov <oakad@yahoo.com> Signed-off-by:
-
Ulf Hansson authored
The in-parameter timeout is always set to TRANSFER_TIMEOUT by the callers of sdricoh_query_status(), hence let's drop it. Cc: Sascha Sommer <saschasommer@freenet.de> Signed-off-by:
-
Ulf Hansson authored
Move MMC_APP_CMD specific handling to be managed by sdricoh_mmc_cmd(), as this makes the code a bit cleaner. Cc: Sascha Sommer <saschasommer@freenet.de> Signed-off-by:
-
Ulf Hansson authored
Cc: Sascha Sommer <saschasommer@freenet.de> Signed-off-by:
-
Ulf Hansson authored
Cc: Sascha Sommer <saschasommer@freenet.de> Signed-off-by:
-
Ulf Hansson authored
For commands that doesn't involve to prepare a data transfer, owl-mmc is using a fixed 30s response timeout. This is a bit problematic. For some commands it means waiting longer than needed for the completion to expire, which may not a big issue, but still. For other commands, like for an erase (CMD38) that uses a R1B response, may require longer timeouts than 30s. In these cases, we may end up treating the command as it failed, while it just needed some more time to complete successfully. Fix the problem by respecting the cmd->busy_timeout, which is provided by the mmc core. Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by:
-
Ulf Hansson authored
Some commands uses R1B responses, which means the card may assert the DAT0 line to signal busy for a period of time, after it has received the command. The mmc core normally specifies the busy period for the command in the cmd->busy_timeout. Ideally the driver should respect it, but that requires quite some update of the code, so let's defer that to someone with the HW at hand. Instead, let's inform the mmc core about the maximum supported busy timeout in ->max_busy_timeout during ->probe(). This value corresponds to the fixed 5s timeout used by jz4740. In this way, we let the mmc core validate the needed timeout, which may lead to that it converts from a R1B into a R1 response and then use CMD13 to poll for busy completion. In other words, this change enables support for commands with longer busy periods than 5s, like erase (CMD38) for example. Cc: Paul Cercueil <paul@crapouillou.net> Signed-off-by:
-
Zou Wei authored
Fix the following sparse warning: drivers/mmc/host/sdhci-pci-o2micro.c:497:6: warning: symbol 'sdhci_pci_o2_set_clock' was not declared. Should it be static? drivers/mmc/host/sdhci-pci-o2micro.c:512:5: warning: symbol 'sdhci_pci_o2_probe_slot' was not declared. Should it be static? drivers/mmc/host/sdhci-pci-o2micro.c:581:5: warning: symbol 'sdhci_pci_o2_probe' was not declared. Should it be static? drivers/mmc/host/sdhci-pci-o2micro.c:786:5: warning: symbol 'sdhci_pci_o2_resume' was not declared. Should it be static? Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Zou Wei <zou_wei@huawei.com> Acked-by:
Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/1587624199-96926-1-git-send-email-zou_wei@huawei.comSigned-off-by:
-
Zou Wei authored
Fixes coccicheck warning: drivers/mmc/core/debugfs.c:222:0-23: WARNING: mmc_clock_fops should be defined with DEFINE_DEBUGFS_ATTRIBUTE Use DEFINE_DEBUGFS_ATTRIBUTE rather than DEFINE_SIMPLE_ATTRIBUTE for debugfs files Fixes: 703aae3d ("mmc: add a file to debugfs for changing host clock at runtime") Fixes: a04c50aa ("mmc: core: no need to check return value of debugfs_create functions") Reported-by:
-
Masahiro Yamada authored
If sdhci-of-at91.c is compiled without CONFIG_HAVE_CLK, the line caps1 |= FIELD_PREP(SDHCI_CLOCK_MUL_MASK, clk_mul); ... emits "FIELD_PREP: value too large for the field" warning. The compiler seems to decide clk_mul is constant (unsigned int)-1, because clk_get_rate() returns 0 when CONFIG_HAVE_CLK is disabled. Add HAVE_CLK to the depenency since this driver does not work without the clock APIs anyway. Reported-by:
Randy Dunlap <rdunlap@infradead.org> Suggested-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Link: https://lore.kernel.org/r/20200422153401.7913-1-yamada.masahiro@socionext.comSigned-off-by:
-
Wolfram Sang authored
After TAP refactorization, we can use 'unsigned int' for two more variables because all the calculations work on this type now. Signed-off-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by:
Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Link: https://lore.kernel.org/r/20200420170230.9091-1-wsa+renesas@sang-engineering.comSigned-off-by:
-
Ludovic Barre authored
This patch fix a power-on issue, and avoid to retry the power sequence. In power off sequence: sdmmc must set pwr_reg in "power-cycle" state (value 0x2), to prevent the card from being supplied through the signal lines (all the lines are driven low). In power on sequence: when the power is stable, sdmmc must set pwr_reg in "power-off" state (value 0x0) to drive all signal to high before to set "power-on". To avoid writing the same value to the power register several times, this register is cached by the pwr_reg variable. At probe pwr_reg is initialized to 0 by kzalloc of mmc_alloc_host. Like pwr_reg value is 0 at probing, the power on sequence fail because the "power-off" state is not writes (value 0x0) and the lines remain drive to low. This patch initializes "pwr_reg" variable with power register value. This it done in sdmmc variant init to not disturb default mmci behavior. Signed-off-by:
Ludovic Barre <ludovic.barre@st.com> Link: https://lore.kernel.org/r/20200420161831.5043-1-ludovic.barre@st.comSigned-off-by:
-
Rajendra Nayak authored
On some qualcomm SoCs we need to vote on a performance state of a power domain depending on the clock rates. Hence move to using OPP api to set the clock rate and performance state specified in the OPP table. On platforms without an OPP table, dev_pm_opp_set_rate() is eqvivalent to clk_set_rate() Signed-off-by:
Rajendra Nayak <rnayak@codeaurora.org> Link: https://lore.kernel.org/r/1587132279-27659-10-git-send-email-rnayak@codeaurora.orgSigned-off-by:
-
Ulf Hansson authored
Using a fixed 1s timeout for all commands is a bit problematic. For some commands it means waiting longer than needed for the timeout to expire, which may not a big issue, but still. For other commands, like for an erase (CMD38) that uses a R1B response, may require longer timeouts than 1s. In these cases, we may end up treating the command as it failed, while it just needed some more time to complete successfully. Fix the problem by respecting the cmd->busy_timeout, which is provided by the mmc core. Cc: Rui Miguel Silva <rmfrfs@gmail.com> Cc: Johan Hovold <johan@kernel.org> Cc: Alex Elder <elder@kernel.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: greybus-dev@lists.linaro.org Signed-off-by:
Rui Miguel Silva <rmfrfs@gmail.com> Acked-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20200414161413.3036-20-ulf.hansson@linaro.orgSigned-off-by:
-
Ulf Hansson authored
Some commands uses R1B responses, which means the card may assert the DAT0 line to signal busy for a period of time, after it has received the command. The mmc core normally specifies the busy period for the command in the cmd->busy_timeout. Ideally the driver should respect it, but that requires quite some update of the code, so let's defer that to someone with the HW at hand. Instead, let's inform the mmc core about the maximum supported busy timeout in ->max_busy_timeout during ->probe(). This value corresponds to the fixed 4s timeout used by usdhi6rol0. In this way, we let the mmc core validate the needed timeout, which may lead to that it converts from a R1B into a R1 response and then use CMD13 to poll for busy completion. In other words, this change enables support for commands with longer busy periods than 4s, like erase (CMD38) for example. Cc: Jesper Nilsson <jesper.nilsson@axis.com> Cc: Lars Persson <lars.persson@axis.com> Signed-off-by:
Jesper Nilsson <jesper.nilsson@axis.com> Link: https://lore.kernel.org/r/20200414161413.3036-6-ulf.hansson@linaro.orgSigned-off-by:
-
Ulf Hansson authored
Using a fixed 2s timeout for all commands is a bit problematic. For some commands it means waiting longer than needed for the timer to expire, which may not a big issue, but still. For other commands, like for an erase (CMD38) that uses a R1B response, may require longer timeouts than 2s. In these cases, we may end up treating the command as it failed, while it just needed some more time to complete successfully. Fix the problem by respecting the cmd->busy_timeout, which is provided by the mmc core. Cc: Ludovic Desroches <ludovic.desroches@microchip.com> Cc: Nicolas Ferre <nicolas.ferre@microchip.com> Signed-off-by:
Ludovic Desroches <ludovic.desroches@microchip.com> Link: https://lore.kernel.org/r/20200414161413.3036-4-ulf.hansson@linaro.orgSigned-off-by:
-
Ulf Hansson authored
Setting the timer on a per request basis, is rather limiting as the timer really depends on what commands that is to be sent as part of the request. Therefore improve the behaviour by programming the timer per command basis instead. Cc: Ludovic Desroches <ludovic.desroches@microchip.com> Cc: Nicolas Ferre <nicolas.ferre@microchip.com> Signed-off-by:
-
Ulf Hansson authored
When atmci_request_end() is about to finish a request for one slot, there is a possibility that there is new request queued for another slot. If this turns out to be the case, the new request is started and the timer is re-programmed for it. Although, a few lines below in atmci_request_end(), this timer becomes deleted, likely corresponding to the other recently completed request. This looks wrong, so let's fix it. Cc: Ludovic Desroches <ludovic.desroches@microchip.com> Cc: Nicolas Ferre <nicolas.ferre@microchip.com> Signed-off-by:
-
Veerabhadrarao Badiganti authored
ADMA_ERR_SIZE_EN bit of VENDOR_SPECIFIC_FUNC register controls ADMA length mismatch error interrupt. Enable it by default. And update all bit shift defines with BIT macro. Signed-off-by:
Veerabhadrarao Badiganti <vbadigan@codeaurora.org> Acked-by:
-
Veerabhadrarao Badiganti authored
sdhci-msm can support auto cmd12. So enable SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12 quirk. Signed-off-by:
-
Haibo Chen authored
When use one SDIO wifi which enable the runtime PM feature on i.MX6SX, we meet system hang. This hang happened during the usdhc runtime resume, in sdhci_init(), when call the sdhci_set_default_irqs. One interrupt (SDHCI_INT_CARD_INT) triggered just after the host->ier update and before the write of register SDHCI_SIGNAL_ENABLE. So in sdhci_irq, it will skip the call of sdio_signal_irq() because current host->ier do not set the SDHCI_INT_CARD_INT. So this SDIO wifi interrupt always keep triggered, let the system stuck in irq handle, can't response any other thread. This patch add spin lock for the sdhci_set_default_irqs to fix this issue. Signed-off-by:
Haibo Chen <haibo.chen@nxp.com> Acked-by:
-
Baolin Wang authored
Implement the request_atomic() API for nonremovable cards, that means we can submit next request in the irq hard handler context to reduce latency. Moreover factor out the AUTO CMD23 checking into a separate function to reduce duplicate code. Signed-off-by:
Baolin Wang <baolin.wang7@gmail.com> Acked-by:
-
Baolin Wang authored
Implement the request_atomic() ops for the sdhci driver to process one request in the atomic context if the card is nonremovable. Moreover, we should return BUSY flag if controller has not released the inhibit bits to allow HSQ trying to send request again in non-atomic context. Suggested-by:
-
Baolin Wang authored
The SD host controller can process one request in the atomic context if the card is nonremovable, which means we can submit next request in the irq hard handler when using the MMC host software queue to reduce the latency. Thus this patch adds a new API request_atomic() for the host controller, as well as adding support for host software queue to submit a request by the new request_atomic() API. Moreover there is an unusual case that the card is busy when trying to send a command, and we can not polling the card status in interrupt context by using request_atomic() to dispatch requests. Thus we should queue a work to try again in the non-atomic context in case the host releases the busy signal later. Suggested-by:
-
Adrian Hunter authored
Spending time under spinlock increases IRQ latencies and also response times because preemption is disabled. sdhci_send_command() waits up to 10 ms under spinlock for inhibit bits to clear. In general inhibit bits will not be set, but there may be corner cases, especially in the face of errors, where waiting helps. There might also be dysfunctional hardware that needs the waiting. So retain the legacy behaviour but do not wait for inhibit bits while under spinlock. Instead adjust the logic to enable waiting while not under spinlock. That is mostly straight forward, but in the interrupt handler it requires deferring an "inhibited" command to the IRQ thread where sleeping is allowed. Signed-off-by:
-
Adrian Hunter authored
In preparation for further changes, tidy sdhci_request() a bit. Signed-off-by:
-
Adrian Hunter authored
sdhci_finish_data() is defined before it is referenced, so forward declaration is not necessary. Signed-off-by:
-
Adrian Hunter authored
sdhci_send_command() has not been used outside of sdhci.c for many years. Stop exporting it. Signed-off-by:
-
Adrian Hunter authored
Add 2 helper functions to make the use of the auto-CMD23 flag more readable. Signed-off-by:
-
Jisheng Zhang authored
Use the well defined HIGH_SPEED_BUS_SPEED macro in mmc_sd_switch_hs() to make code more readable. Signed-off-by:
Jisheng Zhang <Jisheng.Zhang@synaptics.com> Link: https://lore.kernel.org/r/20200410145643.630b0731@xhacker.debianSigned-off-by:
-
Marek Vasut authored
Instead of reimplementing the logic in mmc_regulator_set_vqmmc(), use the mmc code function directly. This also allows us to fix a related issue on STM32MP1, when a voltage switch of 1.8V is done for the eMMC, but the current level is already set to 1.8V. More precisely, in this scenario the call to the ->post_sig_volt_switch() hangs, indefinitely waiting for the voltage switch to complete. Fix this problem by checking if mmc_regulator_set_vqmmc() returned 1 and then skip invoking the callback. Signed-off-by:
Marek Vasut <marex@denx.de> Link: https://lore.kernel.org/r/20200416163649.336967-3-marex@denx.de [Ulf: Updated the commit message] Signed-off-by:
-
Marek Vasut authored
Adjust mmc_regulator_set_vqmmc() to return 1 if the voltage switch was skipped because the regulator voltage was already correct. This allows drivers to detect such condition and possibly skip various voltage switching extras. Signed-off-by:
-
Marek Vasut authored
Patch all drivers which use mmc_regulator_set_vqmmc() and prepare them for the fact that mmc_regulator_set_vqmmc() can return a value > 0, which would happen if the signal voltage switch did NOT happen, because the voltage was already set correctly. Signed-off-by:
-
Nathan Chancellor authored
Clang warns: drivers/mmc/host/sdhci-of-arasan.c:784:9: warning: variable 'ret' is uninitialized when used here [-Wuninitialized] return ret; ^~~ drivers/mmc/host/sdhci-of-arasan.c:738:9: note: initialize the variable 'ret' to silence this warning int ret; ^ = 0 drivers/mmc/host/sdhci-of-arasan.c:860:9: warning: variable 'ret' is uninitialized when used here [-Wuninitialized] return ret; ^~~ drivers/mmc/host/sdhci-of-arasan.c:810:9: note: initialize the variable 'ret' to silence this warning int ret; ^ = 0 2 warnings generated. This looks like a copy paste error. Neither function has handling that needs ret so just remove it and return 0 directly. Link: https://github.com/ClangBuiltLinux/linux/issues/996Reported-by:kernelci.org bot <bot@kernelci.org> Signed-off-by:
Nathan Chancellor <natechancellor@gmail.com> Reviewed-by:
Nick Desaulniers <ndesaulniers@google.com> Link: https://lore.kernel.org/r/20200416182402.16858-1-natechancellor@gmail.comSigned-off-by:
-
Wolfram Sang authored
No need to call platform_get_resource twice when we still have the pointer from before. Also, use '%pa' for a resource_size_t pointer. Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be>
-
Wolfram Sang authored
When tuning HS400, if all TAPS are good, we can utilize the SMPCMP register to select the optimal TAP. For that, we populate a second bitmap with SMPCMP results and query it in case the regular bitmap is full (= all good). Signed-off-by:
Masaharu Hayakawa <masaharu.hayakawa.ry@renesas.com> Signed-off-by:
Takeshi Saito <takeshi.saito.xv@renesas.com> Signed-off-by:
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Tested-by:
-
Wolfram Sang authored
The comment and the define about how TAPs are selected were confusing to me because the good TAP was only valid if it was bigger than a *_MAX_* value. Rename the define and adapt the comment to what really happens. Signed-off-by:
-
