- 24 Mar, 2020 40 commits
-
-
Faiz Abbas authored
According to latest AM65x Data Manual[1], a different output tap delay value is recommended for all speed modes. Therefore, replace the ti,otap-del-sel binding with one ti,otap-del-sel- for each MMC/SD speed mode. [1] http://www.ti.com/lit/gpn/am6526Signed-off-by:
Faiz Abbas <faiz_abbas@ti.com> Link: https://lore.kernel.org/r/20200108150920.14547-2-faiz_abbas@ti.comSigned-off-by:
Ulf Hansson <ulf.hansson@linaro.org>
-
Baolin Wang authored
Add missing MODULE_LICENSE() and MODULE_DESCRIPTION() in hsq driver to fix below warning when compiling the hsq as a module. "WARNING: modpost: missing MODULE_LICENSE() in drivers/mmc/host/mmc_hsq.o". Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
Baolin Wang <baolin.wang7@gmail.com> Link: https://lore.kernel.org/r/98ce471185f037fce57520763621590588766381.1582161803.git.baolin.wang7@gmail.comSigned-off-by:
-
Ludovic Barre authored
This patch adds a sdmmc variant revision 2.0. This revision is backward compatible with 1.1, but adds DMA linked list support. Signed-off-by:
Ludovic Barre <ludovic.barre@st.com> Link: https://lore.kernel.org/r/20200128090636.13689-10-ludovic.barre@st.comSigned-off-by:
-
Ludovic Barre authored
To prepare the voltage switch procedure, the VSWITCHEN bit must be set before sending the CMD11. To confirm completion of voltage switch, the VSWEND flag must be checked. Signed-off-by:
-
Ludovic Barre authored
A variant may need to define some actions before and after a voltage switch. This patch adds 2 callbacks to manage signal voltage switch in the struct mmci_host_ops. ->pre_sig_volt_switch() allows to prepare a signal voltage switch before sending the SD_SWITCH_VOLTAGE command (CMD11). ->post_sig_volt_switch callback allows specific actions to be executed, after the I/O signal voltage level has been changed. Signed-off-by:
-
Ludovic Barre authored
The hardware delay block is used to align the sampling clock on the data received by SDMMC. It is mandatory for SDMMC to support the SDR104 mode. The delay block is used to generate an output clock which is dephased from the input clock. The phase of the output clock must be programmed by the execute tuning interface. Signed-off-by:
-
Ludovic Barre authored
To support the sdr104 mode, the sdmmc variant has a hardware delay block to manage the clock phase when sampling data received by the card. This patch adds a second base register (optional) for sdmmc delay block. Signed-off-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20200128090636.13689-6-ludovic.barre@st.comSigned-off-by:
-
Ludovic Barre authored
In variant init function, some references may be allocated for variant specific usage. Add a private void* to mmci_host struct allows at variant functions to access on this references by mmci_host structure. Signed-off-by:
-
Ludovic Barre authored
The variant init function may need to add a mmc_host_ops, for example to add the execute_tuning support if this feature is available. This patch adds mmc_host_ops pointer in mmci struct. Signed-off-by:
-
Ludovic Barre authored
This patch renames sdmmc_priv struct to sdmmc_idma which is assigned to host->dma_priv. Signed-off-by:
-
Ludovic Barre authored
sg_dma_xxx should be used after a dma_map_sg call has been done to get bus addresses of each of the SG entries and their lengths. But mmci_host_ops validate_data can be called before dma_map_sg. This patch replaces theses macros by sg->offset and sg->length which are always defined. Signed-off-by:
-
Ulf Hansson authored
In case the host specify a max_busy_timeout, we need to validate that the needed timeout for the HPI command conforms to that requirement. If that's not the case, let's convert from a R1B response to a R1 response, as to instruct the host to avoid HW busy detection. Additionally, when R1B is used we must also inform the host about the busy timeout for the command, so let's do that via updating cmd.busy_timeout. Finally, when R1B is used and in case the host supports HW busy detection, there should be no need for doing polling, so then skip that. Signed-off-by:
-
Ulf Hansson authored
Rather than open coding the polling loop in mmc_interrupt_hpi(), let's convert to use mmc_poll_for_busy(). Note that, moving to mmc_poll_for_busy() for HPI also improves the behaviour according to below. - Adds support for polling via the optional ->card_busy() host ops. - Require R1_READY_FOR_DATA to be set in the CMD13 response before exiting the polling loop. - Adds a throttling mechanism to avoid CPU hogging when polling. Signed-off-by:
-
Ulf Hansson authored
The 'u32 *status' is unused by the caller, so let's drop it. Signed-off-by:
-
Ulf Hansson authored
Rather than open coding the polling loop in mmc_do_erase(), let's convert to use mmc_poll_for_busy(). To allow a slightly different error parsing during polling, compared to the __mmc_switch() case, a new in-parameter to mmc_poll_for_busy() is needed, but other than that the conversion is straight forward. Besides addressing the open coding issue, moving to mmc_poll_for_busy() for erase/trim/discard improves the behaviour according to below. - Adds support for polling via the optional ->card_busy() host ops. - Returns zero to indicate success when the final polling attempt finds the card non-busy, even if the timeout expired. - Exits the polling loop when state moves to R1_STATE_TRAN, rather than when leaving R1_STATE_PRG. - Decreases the starting range for throttling to 32-64us. Signed-off-by:
-
Ulf Hansson authored
Through mmc_poll_for_busy() a CMD13 may be sent to get the status of the (e)MMC card. If the state of the card is R1_STATE_PRG, the card is considered as being busy, which means we continue to poll with CMD13. This seems to be sufficient, but it's also unnecessary fragile, as it means a new command/request could potentially be sent to the card when it's in an unknown state. To try to improve the situation, but also to move towards a more consistent CMD13 polling behaviour in the mmc core, let's deploy the same policy we use for regular I/O write requests. In other words, let's check that card returns to the R1_STATE_TRAN and that the R1_READY_FOR_DATA bit is set in the CMD13 response, before exiting the polling loop. Note that, potentially this changed behaviour could lead to unnecessary waiting for the timeout to expire, if the card for some reason, moves to an unexpected error state. However, as we bail out from the polling loop when R1_SWITCH_ERROR bit is set or when the CMD13 fails, this shouldn't be an issue. Signed-off-by:
-
Ulf Hansson authored
To allow subsequent changes to re-use the code from the static function mmc_blk_in_tran_state(), let's move it to a public header. While at it, let's also rename it to mmc_ready_for_data(), as to try to better describe its purpose. Signed-off-by:
-
Ulf Hansson authored
To make the code more readable, move the part that gets the busy status of the card out into a separate function, mmc_busy_status(). Then call it from mmc_poll_for_busy(). Signed-off-by:
-
Ulf Hansson authored
The use_busy_signal in-parameter is set true by all callers of __mmc_switch(), hence it's redundant so drop it. Signed-off-by:
-
Ulf Hansson authored
To simplify code, let's extend mmc_switch_status() to cope with needs addressed in __mmc_switch_status(). Then move all users to the updated mmc_switch_status() API and drop __mmc_switch_status() altogether. Signed-off-by:
-
Ulf Hansson authored
The last user of MMC_OPS_TIMEOUT_MS was recently removed, however the define stayed around. Let's remove it. Signed-off-by:
-
Ulf Hansson authored
In mmc_poll_for_busy() we loop continuously, either by sending a CMD13 or by invoking the ->card_busy() host ops, as to detect when the card stops signaling busy. This behaviour is problematic as it may cause CPU hogging, especially when the busy signal time reaches beyond a few ms. Let's fix the issue by adding a throttling mechanism, that inserts a usleep_range() in between the polling attempts. The sleep range starts at 32-64us, but increases for each loop by a factor of 2, up until the range reaches ~32-64ms. In this way, we are able to keep the loop fine-grained enough for short busy signaling times, while also not hogging the CPU for longer times. Note that, this change is inspired by the similar throttling mechanism that we already use for mmc_do_erase(). Reported-by:
Michał Mirosław <mirq-linux@rere.qmqm.pl> Signed-off-by:
-
Baolin Wang authored
Add software queue support to improve the performance. Signed-off-by:
Baolin Wang <baolin.wang@linaro.org> Signed-off-by:
-
Baolin Wang authored
When using the host software queue, it will trigger the next request in irq handler without a context switch. But the sdhci_request() can not be called in interrupt context when using host software queue for some host drivers, due to the get_cd() ops can be sleepable. But for some host drivers, such as Spreadtrum host driver, the card is nonremovable, so the get_cd() ops is not sleepable, which means we can complete the data request and trigger the next request in irq handler to remove the context switch for the Spreadtrum host driver. As suggested by Adrian, we should introduce a request_atomic() API to indicate that a request can be called in interrupt context to remove the context switch when using mmc host software queue. But this should be done in another thread to convert the users of mmc host software queue. Thus we can introduce a variable in struct sdhci_host to indicate that we will always to defer to complete requests when using the host software queue. Suggested-by:
Adrian Hunter <adrian.hunter@intel.com> Signed-off-by:
-
Baolin Wang authored
Add request_done ops for struct sdhci_ops as a preparation in case some host controllers have different method to complete one request, such as supporting request completion of MMC software queue. Suggested-by:
-
Baolin Wang authored
Enable the MMC host software queue for the SD card if the host controller supports the MMC host software queue. On my Spreadtrum platform, I did not see any obvious performance changes in 4K block size when changing to use hsq for the SD cards, I think the reason is the SD card works at a low speed on my platform, and most of time is spent in the hardware. But we can see some obvious improvements when enabling the packed request based on hsq, that's why we still add hsq support for the SD cards. Signed-off-by:
-
Baolin Wang authored
Now the MMC read/write stack will always wait for previous request is completed by mmc_blk_rw_wait(), before sending a new request to hardware, or queue a work to complete request, that will bring context switching overhead and spend some extra time to poll the card for busy completion for I/O writes via sending CMD13, especially for high I/O per second rates, to affect the IO performance. Thus this patch introduces MMC software queue interface based on the hardware command queue engine's interfaces, which is similar with the hardware command queue engine's idea, that can remove the context switching. Moreover we set the default queue depth as 64 for software queue, which allows more requests to be prepared, merged and inserted into IO scheduler to improve performance, but we only allow 2 requests in flight, that is enough to let the irq handler always trigger the next request without a context switch, as well as avoiding a long latency. Moreover the host controller should support HW busy detection for I/O operations when enabling the host software queue. That means, the host controller must not complete a data transfer request, until after the card stops signals busy. From the fio testing data in cover letter, we can see the software queue can improve some performance with 4K block size, increasing about 16% for random read, increasing about 90% for random write, though no obvious improvement for sequential read and write. Moreover we can expand the software queue interface to support MMC packed request or packed command in future. Reviewed-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Ritesh Harjani authored
SDHC core with new 14lpp and later tech DLL should not enable PWRSAVE_DLL since such controller's internal gating cannot meet following MCLK requirement: When MCLK is gated OFF, it is not gated for less than 0.5us and MCLK must be switched on for at-least 1us before DATA starts coming. Adding support for this requirement. Signed-off-by:
Ritesh Harjani <riteshh@codeaurora.org> Signed-off-by:
Veerabhadrarao Badiganti <vbadigan@codeaurora.org> Reviewed-by:
Can Guo <cang@codeaurora.org> Acked-by:
-
Manish Narani authored
This patch removes quirk which indicates a broken base clock. This was making the kernel report wrong base clock of ~187MHz instead of 200MHz even as the measurement on the hardware was showing 200MHz. Signed-off-by:
Manish Narani <manish.narani@xilinx.com> Acked-by:
-
Manish Narani authored
The DLL resets are required while executing the auto tuning procedure in ZynqMP. This patch adds code to support the same. Signed-off-by:
-
Manish Narani authored
SD DLL resets are required for some of the operations on ZynqMP platform. Add DLL reset support in ZynqMP firmware driver for SD DLL reset. Signed-off-by:
Michal Simek <michal.simek@xilinx.com> Link: https://lore.kernel.org/r/1579602095-30060-3-git-send-email-manish.narani@xilinx.comSigned-off-by:
-
Manish Narani authored
The Tap Delay setup ioctl was not added to valid list due to which it may fail to set Tap Delays for SD. This patch fixes the same. Signed-off-by:
-
Wolfram Sang authored
After various refactoring, we can populate the mmc_ops callbacks directly and don't need to have wrappers for them anymore. Signed-off-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by:
Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Reviewed-by:
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Link: https://lore.kernel.org/r/20200129203709.30493-7-wsa+renesas@sang-engineering.comSigned-off-by:
-
Wolfram Sang authored
TAPs are Renesas SDHI specific. Now that we moved all handling to the SDHI core, we can also move the definitions from the TMIO struct to the SDHI one. Signed-off-by:
-
Wolfram Sang authored
Currently, select_tuning() is called after RPM resume. But select_tuning() needs some additional function calls to work correctly. Instead of reimplementing the whole postprocessing, just enforce retuning. Signed-off-by:
-
Wolfram Sang authored
check_scc_error() is too Renesas specific. Let's just call it check_retune() to make it also easier understandable what it does. Only a rename, no functional change. Signed-off-by:
-
Wolfram Sang authored
When the tap array in the driver is too low, this is not a warning but an error. Also _once is not helpful, we should make sure it is prominently in the logs. It is safe to do this because this will only show up during SoC enablement when we a new SoCs needs more taps (if that ever will happen). Signed-off-by:
-
Wolfram Sang authored
Move Renesas specific code for executing the tuning with a SCC into the SDHI driver and leave only a generic call in the TMIO driver. Simplify the code a little by removing init_tuning() and prepare_tuning() callbacks. The latter is directly folded into the new execute_tuning() callbacks. Signed-off-by:
-
Wolfram Sang authored
Use increasing BIT numbers consistently and remove some superfluous comments. Signed-off-by:
-
Wolfram Sang authored
HW engineers say that automatic tap correction cannot be used for HS400 in all R-Car Gen3 SoCs. So, check for that SDHI variant and disable it when HS400 is about to be enabled. Reviewed-by:
-
