Revision tags: v6.6.25, v6.6.24, v6.6.23 |
|
#
176e6626 |
| 07-Feb-2024 |
Christophe Kerello <christophe.kerello@foss.st.com> |
mmc: mmci: stm32: fix DMA API overlapping mappings warning
commit 6b1ba3f9040be5efc4396d86c9752cdc564730be upstream.
Turning on CONFIG_DMA_API_DEBUG_SG results in the following warning:
DMA-API: m
mmc: mmci: stm32: fix DMA API overlapping mappings warning
commit 6b1ba3f9040be5efc4396d86c9752cdc564730be upstream.
Turning on CONFIG_DMA_API_DEBUG_SG results in the following warning:
DMA-API: mmci-pl18x 48220000.mmc: cacheline tracking EEXIST, overlapping mappings aren't supported WARNING: CPU: 1 PID: 51 at kernel/dma/debug.c:568 add_dma_entry+0x234/0x2f4 Modules linked in: CPU: 1 PID: 51 Comm: kworker/1:2 Not tainted 6.1.28 #1 Hardware name: STMicroelectronics STM32MP257F-EV1 Evaluation Board (DT) Workqueue: events_freezable mmc_rescan Call trace: add_dma_entry+0x234/0x2f4 debug_dma_map_sg+0x198/0x350 __dma_map_sg_attrs+0xa0/0x110 dma_map_sg_attrs+0x10/0x2c sdmmc_idma_prep_data+0x80/0xc0 mmci_prep_data+0x38/0x84 mmci_start_data+0x108/0x2dc mmci_request+0xe4/0x190 __mmc_start_request+0x68/0x140 mmc_start_request+0x94/0xc0 mmc_wait_for_req+0x70/0x100 mmc_send_tuning+0x108/0x1ac sdmmc_execute_tuning+0x14c/0x210 mmc_execute_tuning+0x48/0xec mmc_sd_init_uhs_card.part.0+0x208/0x464 mmc_sd_init_card+0x318/0x89c mmc_attach_sd+0xe4/0x180 mmc_rescan+0x244/0x320
DMA API debug brings to light leaking dma-mappings as dma_map_sg and dma_unmap_sg are not correctly balanced.
If an error occurs in mmci_cmd_irq function, only mmci_dma_error function is called and as this API is not managed on stm32 variant, dma_unmap_sg is never called in this error path.
Signed-off-by: Christophe Kerello <christophe.kerello@foss.st.com> Fixes: 46b723dd867d ("mmc: mmci: add stm32 sdmmc variant") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20240207143951.938144-1-christophe.kerello@foss.st.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39, v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35 |
|
#
b1a66593 |
| 20-Jun-2023 |
Ulf Hansson <ulf.hansson@linaro.org> |
mmc: mmci: Add support for SW busy-end timeouts
The ux500 variant doesn't have a HW based timeout to use for busy-end IRQs. To avoid hanging and waiting for the card to stop signaling busy, let's sc
mmc: mmci: Add support for SW busy-end timeouts
The ux500 variant doesn't have a HW based timeout to use for busy-end IRQs. To avoid hanging and waiting for the card to stop signaling busy, let's schedule a delayed work, according to the corresponding cmd->busy_timeout for the command. If the work gets to run, let's kick the IRQ handler to complete the currently running request/command.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Tested-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Link: https://lore.kernel.org/r/20230620091113.33393-1-ulf.hansson@linaro.org
show more ...
|
#
b5c3eb38 |
| 19-Jun-2023 |
Yann Gautier <yann.gautier@foss.st.com> |
mmc: mmci: stm32: add delay block support for STM32MP25
On STM32MP25, the delay block is inside the SoC, and configured through the SYSCFG registers. The algorithm is also different from what was in
mmc: mmci: stm32: add delay block support for STM32MP25
On STM32MP25, the delay block is inside the SoC, and configured through the SYSCFG registers. The algorithm is also different from what was in STM32MP1 chip.
Signed-off-by: Yann Gautier <yann.gautier@foss.st.com> Link: https://lore.kernel.org/r/20230619115120.64474-7-yann.gautier@foss.st.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
#
83efc782 |
| 19-Jun-2023 |
Yann Gautier <yann.gautier@foss.st.com> |
mmc: mmci: stm32: prepare other delay block support
Create an sdmmc_tuning_ops struct to ease support for another delay block peripheral.
Signed-off-by: Yann Gautier <yann.gautier@foss.st.com> Link
mmc: mmci: stm32: prepare other delay block support
Create an sdmmc_tuning_ops struct to ease support for another delay block peripheral.
Signed-off-by: Yann Gautier <yann.gautier@foss.st.com> Link: https://lore.kernel.org/r/20230619115120.64474-6-yann.gautier@foss.st.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
#
27bdc37c |
| 19-Jun-2023 |
Yann Gautier <yann.gautier@foss.st.com> |
mmc: mmci: stm32: manage block gap hardware flow control
In stm32 sdmmc variant revision v3.0, a block gap hardware flow control should be used with bus speed modes SDR104 and HS200. It is enabled b
mmc: mmci: stm32: manage block gap hardware flow control
In stm32 sdmmc variant revision v3.0, a block gap hardware flow control should be used with bus speed modes SDR104 and HS200. It is enabled by writing a non-null value to the new added register MMCI_STM32_FIFOTHRR. The threshold will be 2^(N-1) bytes, so we can use the ffs() function to compute the value N to be written to the register. The threshold used should be the data block size, but must not be bigger than the FIFO size.
Signed-off-by: Yann Gautier <yann.gautier@foss.st.com> Link: https://lore.kernel.org/r/20230619115120.64474-5-yann.gautier@foss.st.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
#
88167e6c |
| 19-Jun-2023 |
Yann Gautier <yann.gautier@foss.st.com> |
mmc: mmci: add stm32_idmabsize_align parameter
The alignment for the IDMA size depends on the peripheral version, it should then be configurable. Add stm32_idmabsize_align in the variant structure.
mmc: mmci: add stm32_idmabsize_align parameter
The alignment for the IDMA size depends on the peripheral version, it should then be configurable. Add stm32_idmabsize_align in the variant structure. And remove now unused (and wrong) MMCI_STM32_IDMABNDT_* macros.
Signed-off-by: Yann Gautier <yann.gautier@foss.st.com> Link: https://lore.kernel.org/r/20230619115120.64474-3-yann.gautier@foss.st.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
Revision tags: v6.1.34 |
|
#
16f2e6c0 |
| 13-Jun-2023 |
Yann Gautier <yann.gautier@foss.st.com> |
mmc: mmci: stm32: set feedback clock when using delay block
The feedback clock is used only for SDR104 & HS200 modes, and when delay block is used (frequency is higher than 50 MHz). The tuning proce
mmc: mmci: stm32: set feedback clock when using delay block
The feedback clock is used only for SDR104 & HS200 modes, and when delay block is used (frequency is higher than 50 MHz). The tuning procedure is then only required for those modes. Skip the procedure for other modes. The setting of this feedback clock is done just after enabling delay block, and before configuring it.
Signed-off-by: Yann Gautier <yann.gautier@foss.st.com> Signed-off-by: Christophe Kerello <christophe.kerello@foss.st.com> Link: https://lore.kernel.org/r/20230613150148.429828-1-yann.gautier@foss.st.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
Revision tags: v6.1.33, v6.1.32, v6.1.31, v6.1.30, v6.1.29, v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, v6.1.23, v6.1.22, v6.1.21, v6.1.20, v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9, v6.1.8, v6.1.7, v6.1.6, v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12, v6.0.11, v6.0.10, v5.15.80, v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77, v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3, v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0, v5.15.71, v5.15.70, v5.15.69, v5.15.68, v5.15.67, v5.15.66, v5.15.65, v5.15.64, v5.15.63, v5.15.62, v5.15.61, v5.15.60, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56, v5.15.55, v5.15.54, v5.15.53, v5.15.52, v5.15.51, v5.15.50, v5.15.49, v5.15.48, v5.15.47, v5.15.46, v5.15.45, v5.15.44, v5.15.43, v5.15.42, v5.18, v5.15.41, v5.15.40, v5.15.39, v5.15.38, v5.15.37, v5.15.36, v5.15.35, v5.15.34, v5.15.33 |
|
#
970dc9c1 |
| 28-Mar-2022 |
Yann Gautier <yann.gautier@foss.st.com> |
mmc: mmci: stm32: use a buffer for unaligned DMA requests
In SDIO mode, the sg list for requests can be unaligned with what the STM32 SDMMC internal DMA can support. In that case, instead of failing
mmc: mmci: stm32: use a buffer for unaligned DMA requests
In SDIO mode, the sg list for requests can be unaligned with what the STM32 SDMMC internal DMA can support. In that case, instead of failing, use a temporary bounce buffer to copy from/to the sg list. This buffer is limited to 1MB. But for that we need to also limit max_req_size to 1MB. It has not shown any throughput penalties for SD-cards or eMMC.
Signed-off-by: Yann Gautier <yann.gautier@foss.st.com> Link: https://lore.kernel.org/r/20220328145114.334577-1-yann.gautier@foss.st.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
Revision tags: v5.15.32, v5.15.31, v5.17, v5.15.30 |
|
#
0d319dd5 |
| 17-Mar-2022 |
Yann Gautier <yann.gautier@foss.st.com> |
mmc: mmci: stm32: correctly check all elements of sg list
Use sg and not data->sg when checking sg list elements. Else only the first element alignment is checked. The last element should be checked
mmc: mmci: stm32: correctly check all elements of sg list
Use sg and not data->sg when checking sg list elements. Else only the first element alignment is checked. The last element should be checked the same way, for_each_sg already set sg to sg_next(sg).
Fixes: 46b723dd867d ("mmc: mmci: add stm32 sdmmc variant") Cc: stable@vger.kernel.org Signed-off-by: Yann Gautier <yann.gautier@foss.st.com> Link: https://lore.kernel.org/r/20220317111944.116148-2-yann.gautier@foss.st.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
Revision tags: v5.15.29, v5.15.28, v5.15.27, v5.15.26, v5.15.25, v5.15.24, v5.15.23, v5.15.22, v5.15.21, v5.15.20, v5.15.19, v5.15.18, v5.15.17, v5.4.173, v5.15.16, v5.15.15, v5.16, v5.15.10, v5.15.9 |
|
#
36240ef8 |
| 15-Dec-2021 |
Yann Gautier <yann.gautier@foss.st.com> |
mmc: mmci: add hs200 support for stm32 sdmmc
Use feedback clock for HS200 mode, as for SDR104. The HS200 mode can be enabled through DT by using mmc-hs200-1_8v. It is possible to use it on STM32MP13
mmc: mmci: add hs200 support for stm32 sdmmc
Use feedback clock for HS200 mode, as for SDR104. The HS200 mode can be enabled through DT by using mmc-hs200-1_8v. It is possible to use it on STM32MP13, but not STM32MP15 platforms.
Signed-off-by: Ludovic Barre <ludovic.barre@foss.st.com> Signed-off-by: Yann Gautier <yann.gautier@foss.st.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20211215141727.4901-5-yann.gautier@foss.st.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
#
ff31ee0a |
| 15-Dec-2021 |
Yann Gautier <yann.gautier@foss.st.com> |
mmc: mmci: stm32: clear DLYB_CR after sending tuning command
During test campaign, and especially after several unbind/bind sequences, it has been seen that the SD-card on SDMMC1 thread could freeze
mmc: mmci: stm32: clear DLYB_CR after sending tuning command
During test campaign, and especially after several unbind/bind sequences, it has been seen that the SD-card on SDMMC1 thread could freeze. The freeze always appear on a CMD23 following a CMD19. Checking SDMMC internal registers shows that the tuning command (CMD19) has failed. The freeze is then due to the delay block involved in the tuning sequence. To correct this, clear the delay block register DLYB_CR register after the tuning commands.
Signed-off-by: Christophe Kerello <christophe.kerello@foss.st.com> Signed-off-by: Yann Gautier <yann.gautier@foss.st.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Fixes: 1103f807a3b9 ("mmc: mmci_sdmmc: Add execute tuning with delay block") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20211215141727.4901-4-yann.gautier@foss.st.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
#
11497ecb |
| 17-Mar-2022 |
Yann Gautier <yann.gautier@foss.st.com> |
mmc: mmci: stm32: correctly check all elements of sg list
commit 0d319dd5a27183b75d984e3dc495248e59f99334 upstream.
Use sg and not data->sg when checking sg list elements. Else only the first eleme
mmc: mmci: stm32: correctly check all elements of sg list
commit 0d319dd5a27183b75d984e3dc495248e59f99334 upstream.
Use sg and not data->sg when checking sg list elements. Else only the first element alignment is checked. The last element should be checked the same way, for_each_sg already set sg to sg_next(sg).
Fixes: 46b723dd867d ("mmc: mmci: add stm32 sdmmc variant") Cc: stable@vger.kernel.org Signed-off-by: Yann Gautier <yann.gautier@foss.st.com> Link: https://lore.kernel.org/r/20220317111944.116148-2-yann.gautier@foss.st.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
c7814569 |
| 15-Dec-2021 |
Yann Gautier <yann.gautier@foss.st.com> |
mmc: mmci: stm32: clear DLYB_CR after sending tuning command
commit ff31ee0a0f471776f67be5e5275c18d17736fc6b upstream.
During test campaign, and especially after several unbind/bind sequences, it h
mmc: mmci: stm32: clear DLYB_CR after sending tuning command
commit ff31ee0a0f471776f67be5e5275c18d17736fc6b upstream.
During test campaign, and especially after several unbind/bind sequences, it has been seen that the SD-card on SDMMC1 thread could freeze. The freeze always appear on a CMD23 following a CMD19. Checking SDMMC internal registers shows that the tuning command (CMD19) has failed. The freeze is then due to the delay block involved in the tuning sequence. To correct this, clear the delay block register DLYB_CR register after the tuning commands.
Signed-off-by: Christophe Kerello <christophe.kerello@foss.st.com> Signed-off-by: Yann Gautier <yann.gautier@foss.st.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Fixes: 1103f807a3b9 ("mmc: mmci_sdmmc: Add execute tuning with delay block") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20211215141727.4901-4-yann.gautier@foss.st.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v5.15.8, v5.15.7, v5.15.6, v5.15.5, v5.15.4, v5.15.3, v5.15.2, v5.15.1, v5.15, v5.14.14, v5.14.13, v5.14.12, v5.14.11, v5.14.10, v5.14.9, v5.14.8, v5.14.7, v5.14.6, v5.10.67, v5.10.66, v5.14.5, v5.14.4, v5.10.65, v5.14.3, v5.10.64, v5.14.2, v5.10.63, v5.14.1, v5.10.62, v5.14, v5.10.61, v5.10.60, v5.10.53, v5.10.52, v5.10.51, v5.10.50, v5.10.49 |
|
#
d8e193f1 |
| 01-Jul-2021 |
Christophe Kerello <christophe.kerello@foss.st.com> |
mmc: mmci: stm32: Check when the voltage switch procedure should be done
If the card has not been power cycled, it may still be using 1.8V signaling. This situation is detected in mmc_sd_init_card f
mmc: mmci: stm32: Check when the voltage switch procedure should be done
If the card has not been power cycled, it may still be using 1.8V signaling. This situation is detected in mmc_sd_init_card function and should be handled in mmci stm32 variant. The host->pwr_reg variable is also correctly protected with spin locks.
Fixes: 94b94a93e355 ("mmc: mmci_sdmmc: Implement signal voltage callbacks") Signed-off-by: Christophe Kerello <christophe.kerello@foss.st.com> Signed-off-by: Yann Gautier <yann.gautier@foss.st.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20210701143353.13188-1-yann.gautier@foss.st.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
#
8f499a90 |
| 01-Jul-2021 |
Christophe Kerello <christophe.kerello@foss.st.com> |
mmc: mmci: stm32: Check when the voltage switch procedure should be done
[ Upstream commit d8e193f13b07e6c0ffaa1a999386f1989f2b4c5e ]
If the card has not been power cycled, it may still be using 1.
mmc: mmci: stm32: Check when the voltage switch procedure should be done
[ Upstream commit d8e193f13b07e6c0ffaa1a999386f1989f2b4c5e ]
If the card has not been power cycled, it may still be using 1.8V signaling. This situation is detected in mmc_sd_init_card function and should be handled in mmci stm32 variant. The host->pwr_reg variable is also correctly protected with spin locks.
Fixes: 94b94a93e355 ("mmc: mmci_sdmmc: Implement signal voltage callbacks") Signed-off-by: Christophe Kerello <christophe.kerello@foss.st.com> Signed-off-by: Yann Gautier <yann.gautier@foss.st.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20210701143353.13188-1-yann.gautier@foss.st.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
Revision tags: v5.13, v5.10.46, v5.10.43, v5.10.42, v5.10.41, v5.10.40, v5.10.39, v5.4.119, v5.10.36, v5.10.35, v5.10.34, v5.4.116, v5.10.33, v5.12, v5.10.32, v5.10.31, v5.10.30, v5.10.27, v5.10.26, v5.10.25, v5.10.24, v5.10.23, v5.10.22, v5.10.21, v5.10.20, v5.10.19, v5.4.101, v5.10.18, v5.10.17, v5.11, v5.10.16, v5.10.15, v5.10.14, v5.10, v5.8.17, v5.8.16, v5.8.15, v5.9, v5.8.14, v5.8.13, v5.8.12, v5.8.11, v5.8.10, v5.8.9, v5.8.8, v5.8.7, v5.8.6, v5.4.62, v5.8.5, v5.8.4, v5.4.61, v5.8.3, v5.4.60, v5.8.2, v5.4.59, v5.8.1, v5.4.58, v5.4.57, v5.4.56, v5.8, v5.7.12, v5.4.55, v5.7.11, v5.4.54, v5.7.10, v5.4.53, v5.4.52, v5.7.9, v5.7.8, v5.4.51, v5.4.50, v5.7.7, v5.4.49, v5.7.6, v5.7.5, v5.4.48, v5.7.4, v5.7.3, v5.4.47, v5.4.46, v5.7.2, v5.4.45, v5.7.1, v5.4.44, v5.7, v5.4.43 |
|
#
942d5e7b |
| 26-May-2020 |
Ludovic Barre <ludovic.barre@st.com> |
mmc: mmci_sdmmc: fix DMA API warning max segment size
Turning on CONFIG_DMA_API_DEBUG_SG results in the following warning: WARNING: CPU: 1 PID: 85 at kernel/dma/debug.c:1302 debug_dma_map_sg+0x2a0/0
mmc: mmci_sdmmc: fix DMA API warning max segment size
Turning on CONFIG_DMA_API_DEBUG_SG results in the following warning: WARNING: CPU: 1 PID: 85 at kernel/dma/debug.c:1302 debug_dma_map_sg+0x2a0/0x3cc mmci-pl18x 58005000.sdmmc: DMA-API: mapping sg segment longer than device claims to support [len=126976] [max=65536]
dma api debug checks and compares the segment size to dma_get_max_seg_size (dev->dma_parms->max_segment_size), the sdmmc variant has an internal DMA and should define its max_segment_size constraint to avoid this warning.
This Patch defines the dev->dma_parms->max_segment_size with the constraint already set for mmc core (host->mmc->max_seg_size).
Signed-off-by: Ludovic Barre <ludovic.barre@st.com> Link: https://lore.kernel.org/r/20200526155103.12514-3-ludovic.barre@st.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
#
fe8d33bd |
| 26-May-2020 |
Ludovic Barre <ludovic.barre@st.com> |
mmc: mmci_sdmmc: fix DMA API warning overlapping mappings
Turning on CONFIG_DMA_API_DEBUG_SG results in the following warning: WARNING: CPU: 1 PID: 20 at kernel/dma/debug.c:500 add_dma_entry+0x16c/0
mmc: mmci_sdmmc: fix DMA API warning overlapping mappings
Turning on CONFIG_DMA_API_DEBUG_SG results in the following warning: WARNING: CPU: 1 PID: 20 at kernel/dma/debug.c:500 add_dma_entry+0x16c/0x17c DMA-API: exceeded 7 overlapping mappings of cacheline 0x031d2645 Modules linked in: CPU: 1 PID: 20 Comm: kworker/1:1 Not tainted 5.5.0-rc2-00021-gdeda30999c2b-dirty #49 Hardware name: STM32 (Device Tree Support) Workqueue: events_freezable mmc_rescan [<c03138c0>] (unwind_backtrace) from [<c030d760>] (show_stack+0x10/0x14) [<c030d760>] (show_stack) from [<c0f2eb28>] (dump_stack+0xc0/0xd4) [<c0f2eb28>] (dump_stack) from [<c034a14c>] (__warn+0xd0/0xf8) [<c034a14c>] (__warn) from [<c034a530>] (warn_slowpath_fmt+0x94/0xb8) [<c034a530>] (warn_slowpath_fmt) from [<c03bca0c>] (add_dma_entry+0x16c/0x17c) [<c03bca0c>] (add_dma_entry) from [<c03bdf54>] (debug_dma_map_sg+0xe4/0x3d4) [<c03bdf54>] (debug_dma_map_sg) from [<c0d09244>] (sdmmc_idma_prep_data+0x94/0xf8) [<c0d09244>] (sdmmc_idma_prep_data) from [<c0d05a2c>] (mmci_prep_data+0x2c/0xb0) [<c0d05a2c>] (mmci_prep_data) from [<c0d073ec>] (mmci_start_data+0x134/0x2f0) [<c0d073ec>] (mmci_start_data) from [<c0d078d0>] (mmci_request+0xe8/0x154) [<c0d078d0>] (mmci_request) from [<c0cecb44>] (mmc_start_request+0x94/0xbc)
DMA api debug brings to light leaking dma-mappings, dma_map_sg and dma_unmap_sg are not correctly balanced.
If a request is prepared, the dma_map/unmap are done in asynchronous call pre_req (prep_data) and post_req (unprep_data). In this case the dma-mapping is right balanced.
But if the request was not prepared, the data->host_cookie is define to zero and the dma_map/unmap must be done in the request. The dma_map is called by mmci_dma_start (prep_data), but there is no dma_unmap in this case.
This patch adds dma_unmap_sg when the dma is finalized and the data cookie is zero (request not prepared).
Signed-off-by: Ludovic Barre <ludovic.barre@st.com> Link: https://lore.kernel.org/r/20200526155103.12514-2-ludovic.barre@st.com Fixes: 46b723dd867d ("mmc: mmci: add stm32 sdmmc variant") Cc: stable@vger.kernel.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
Revision tags: v5.4.42, v5.4.41, v5.4.40, v5.4.39, v5.4.38, v5.4.37, v5.4.36, v5.4.35, v5.4.34 |
|
#
33ba6fec |
| 20-Apr-2020 |
Ludovic Barre <ludovic.barre@st.com> |
mmc: mmci_sdmmc: fix power on issue due to pwr_reg initialization
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-cyc
mmc: mmci_sdmmc: fix power on issue due to pwr_reg initialization
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.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
Revision tags: v5.4.33, v5.4.32, v5.4.31, v5.4.30, v5.4.29, v5.6 |
|
#
d4a384cb |
| 25-Mar-2020 |
Ludovic Barre <ludovic.barre@st.com> |
mmc: mmci_sdmmc: Fix clear busyd0end irq flag
The busyd0 line transition can be very fast. The busy request may be completed by busy_d0end, without waiting for the busy_d0 steps. Therefore, clear th
mmc: mmci_sdmmc: Fix clear busyd0end irq flag
The busyd0 line transition can be very fast. The busy request may be completed by busy_d0end, without waiting for the busy_d0 steps. Therefore, clear the busyd0end irq flag, even if no busy_status.
Fixes: 0e68de6aa7b1 ("mmc: mmci: sdmmc: add busy_complete callback") Cc: stable@vger.kernel.org Signed-off-by: Ludovic Barre <ludovic.barre@st.com> Link: https://lore.kernel.org/r/20200325143409.13005-2-ludovic.barre@st.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
Revision tags: v5.4.28, v5.4.27, v5.4.26, v5.4.25, v5.4.24, v5.4.23, v5.4.22, v5.4.21, v5.4.20, v5.4.19, v5.4.18, v5.4.17, v5.4.16 |
|
#
94b94a93 |
| 28-Jan-2020 |
Ludovic Barre <ludovic.barre@st.com> |
mmc: mmci_sdmmc: Implement signal voltage callbacks
To prepare the voltage switch procedure, the VSWITCHEN bit must be set before sending the CMD11. To confirm completion of voltage switch, the VSWE
mmc: mmci_sdmmc: Implement signal voltage callbacks
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 <ludovic.barre@st.com> Link: https://lore.kernel.org/r/20200128090636.13689-9-ludovic.barre@st.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
#
1103f807 |
| 28-Jan-2020 |
Ludovic Barre <ludovic.barre@st.com> |
mmc: mmci_sdmmc: Add execute tuning with delay block
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.
mmc: mmci_sdmmc: Add execute tuning with delay block
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 <ludovic.barre@st.com> Link: https://lore.kernel.org/r/20200128090636.13689-7-ludovic.barre@st.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
#
bdbf9faf |
| 28-Jan-2020 |
Ludovic Barre <ludovic.barre@st.com> |
mmc: mmci_sdmmc: Rename sdmmc_priv struct to sdmmc_idma
This patch renames sdmmc_priv struct to sdmmc_idma which is assigned to host->dma_priv.
Signed-off-by: Ludovic Barre <ludovic.barre@st.com> L
mmc: mmci_sdmmc: Rename sdmmc_priv struct to sdmmc_idma
This patch renames sdmmc_priv struct to sdmmc_idma which is assigned to host->dma_priv.
Signed-off-by: Ludovic Barre <ludovic.barre@st.com> Link: https://lore.kernel.org/r/20200128090636.13689-3-ludovic.barre@st.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
#
127e6e98 |
| 28-Jan-2020 |
Ludovic Barre <ludovic.barre@st.com> |
mmc: mmci_sdmmc: Replace sg_dma_xxx macros
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 valida
mmc: mmci_sdmmc: Replace sg_dma_xxx macros
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: Ludovic Barre <ludovic.barre@st.com> Link: https://lore.kernel.org/r/20200128090636.13689-2-ludovic.barre@st.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
Revision tags: v5.5, v5.4.15, v5.4.14, v5.4.13, v5.4.12, v5.4.11, v5.4.10, v5.4.9, v5.4.8, v5.4.7, v5.4.6, v5.4.5, v5.4.4, v5.4.3, v5.3.15, v5.4.2, v5.4.1, v5.3.14, v5.4, v5.3.13, v5.3.12, v5.3.11, v5.3.10, v5.3.9, v5.3.8, v5.3.7, v5.3.6 |
|
#
61a14e52 |
| 09-Oct-2019 |
Ben Dooks <ben.dooks@codethink.co.uk> |
mmc: mmci: stm32: make sdmmc_idma_validate_data static
Make sdmmc_idma_validate_data to avoid the following warning from sparse:
drivers/mmc/host/mmci_stm32_sdmmc.c:28:5: warning: symbol 'sdmmc_idm
mmc: mmci: stm32: make sdmmc_idma_validate_data static
Make sdmmc_idma_validate_data to avoid the following warning from sparse:
drivers/mmc/host/mmci_stm32_sdmmc.c:28:5: warning: symbol 'sdmmc_idma_validate_data' was not declared. Should it be static?
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
#
0e68de6a |
| 08-Oct-2019 |
Ludovic Barre <ludovic.barre@st.com> |
mmc: mmci: sdmmc: add busy_complete callback
This patch adds a specific busy_complete callback for sdmmc variant.
sdmmc has 2 status flags: -busyd0: This is a hardware status flag (inverted value o
mmc: mmci: sdmmc: add busy_complete callback
This patch adds a specific busy_complete callback for sdmmc variant.
sdmmc has 2 status flags: -busyd0: This is a hardware status flag (inverted value of d0 line). it does not generate an interrupt. -busyd0end: This indicates only end of busy following a CMD response. On busy to Not busy changes, an interrupt is generated (if unmask) and BUSYD0END status flag is set. Status flag is cleared by writing corresponding interrupt clear bit in MMCICLEAR.
The legacy busy completion has no dedicated interrupt for the end of busy, so it's must monitor step by step the busy progression. On sdmmc variant, this procedure is not needed, it's just need to wait the busyd0end interrupt.
Signed-off-by: Ludovic Barre <ludovic.barre@st.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|