Revision tags: v6.6.25, v6.6.24, v6.6.23, 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 |
|
#
80c602b1 |
| 27-Jul-2023 |
Yangtao Li <frank.li@vivo.com> |
mmc: renesas_sdhi: Convert to platform remove callback returning void
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do e
mmc: renesas_sdhi: Convert to platform remove callback returning void
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void.
Trivially convert this driver from always returning zero in the remove callback to the void returning variant.
Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Yangtao Li <frank.li@vivo.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20230727070051.17778-56-frank.li@vivo.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
Revision tags: v6.1.42, v6.1.41, v6.1.40, v6.1.39 |
|
#
c62da8a8 |
| 18-Jul-2023 |
Rob Herring <robh@kernel.org> |
mmc: Explicitly include correct DT includes
The DT of_device.h and of_platform.h date back to the separate of_platform_bus_type before it as merged into the regular platform bus. As part of that mer
mmc: Explicitly include correct DT includes
The DT of_device.h and of_platform.h date back to the separate of_platform_bus_type before it as merged into the regular platform bus. As part of that merge prepping Arm DT support 13 years ago, they "temporarily" include each other. They also include platform_device.h and of.h. As a result, there's a pretty much random mix of those include files used throughout the tree. In order to detangle these headers and replace the implicit includes with struct declarations, users need to explicitly include the correct includes.
Signed-off-by: Rob Herring <robh@kernel.org> Acked-by: Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/20230718143054.1065288-1-robh@kernel.org Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
Revision tags: v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35, v6.1.34, 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 |
|
#
43c487c2 |
| 02-Nov-2022 |
Wolfram Sang <wsa+renesas@sang-engineering.com> |
mmc: tmio: remove 'alignment_shift' from platform data
There is only one alignment shift for one type of Renesas SDHI. Encode it directly in its DMA driver to reduce complexity and ease further simp
mmc: tmio: remove 'alignment_shift' from platform data
There is only one alignment shift for one type of Renesas SDHI. Encode it directly in its DMA driver to reduce complexity and ease further simplifications.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Link: https://lore.kernel.org/r/20221102125430.28466-3-wsa+renesas@sang-engineering.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
#
8840e1c1 |
| 02-Nov-2022 |
Wolfram Sang <wsa+renesas@sang-engineering.com> |
mmc: tmio: remove tmio_mmc_k(un)map_atomic helpers
After a8402aed8ca5 ("mmc: tmio_mmc_core: Remove local_irq_{save,restore}() around k[un]map_atomic()") and ac91578a6812 ("mmc: tmio_mmc_core: Replac
mmc: tmio: remove tmio_mmc_k(un)map_atomic helpers
After a8402aed8ca5 ("mmc: tmio_mmc_core: Remove local_irq_{save,restore}() around k[un]map_atomic()") and ac91578a6812 ("mmc: tmio_mmc_core: Replace kmap_atomic() with kmap_local_page()"), the helpers contain just a single call. Putting it directly in the code makes it actually more readable. More so, because we now avoid the 'offset' calculation when mapping/unmapping and just use it when we need it in the copy routines.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Link: https://lore.kernel.org/r/20221102125430.28466-2-wsa+renesas@sang-engineering.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
Revision tags: 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 |
|
#
14c9825f |
| 05-Oct-2022 |
Adrian Hunter <adrian.hunter@intel.com> |
mmc: tmio_mmc_core: Remove local_irq_{save,restore}() around k[un]map_atomic()
A long time ago the kmap_atomic API required a slot to be provided which risked the possibility that other code might u
mmc: tmio_mmc_core: Remove local_irq_{save,restore}() around k[un]map_atomic()
A long time ago the kmap_atomic API required a slot to be provided which risked the possibility that other code might use the same slot at the same time. Disabling interrupts prevented the possibility of an interrupt handler doing that. However, that went away with commit 3e4d3af501cc ("mm: stack based kmap_atomic()").
When the second argument to kmap_atomic was removed by commit 482fce997e14 ("mmc: remove the second argument of k[un]map_atomic()"), local_irq_{save,restore}() should have been removed also.
Remove it now.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Link: https://lore.kernel.org/r/20221005101951.3165-12-adrian.hunter@intel.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
Revision tags: 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, v5.15.32, v5.15.31, v5.17, v5.15.30, 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, 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 |
|
#
71b7597c |
| 29-Jul-2021 |
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> |
mmc: renesas_sdhi: Refactor renesas_sdhi_probe()
Refactor renesas_sdhi_probe() to avoid increasing numbers of sdhi_quirks_match[] entry when we add other stable SoCs like r8a779m*.
Note that the sd
mmc: renesas_sdhi: Refactor renesas_sdhi_probe()
Refactor renesas_sdhi_probe() to avoid increasing numbers of sdhi_quirks_match[] entry when we add other stable SoCs like r8a779m*.
Note that the sdhi_quirks_match[] is only needed on renesas_sdhi_internal_dmac.c so that of_data of renesas_sdhi_sys_dmac.c keeps as-is.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Link: https://lore.kernel.org/r/20210729103234.480743-1-yoshihiro.shimoda.uh@renesas.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
Revision tags: v5.10.53, v5.10.52, v5.10.51, v5.10.50, v5.10.49, v5.13, v5.10.46 |
|
#
2fc2628a |
| 23-Jun-2021 |
Wolfram Sang <wsa+renesas@sang-engineering.com> |
mmc: renesas_sdhi_sys_dmac: use proper DMAENGINE API for termination
dmaengine_terminate_all() is deprecated in favor of explicitly saying if it should be sync or async. Here, we want dmaengine_term
mmc: renesas_sdhi_sys_dmac: use proper DMAENGINE API for termination
dmaengine_terminate_all() is deprecated in favor of explicitly saying if it should be sync or async. Here, we want dmaengine_terminate_sync() because there is no other synchronization code in the driver to handle an async case.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Link: https://lore.kernel.org/r/20210623095734.3046-2-wsa+renesas@sang-engineering.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
Revision tags: 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 |
|
#
87e985ae |
| 09-Apr-2021 |
Wolfram Sang <wsa+renesas@sang-engineering.com> |
mmc: renesas_sdhi: enable WAIT_WHILE_BUSY
Now that we got the timeout handling in the driver correct, we can use this capability to avoid polling via the MMC core.
Signed-off-by: Wolfram Sang <wsa+
mmc: renesas_sdhi: enable WAIT_WHILE_BUSY
Now that we got the timeout handling in the driver correct, we can use this capability to avoid polling via the MMC core.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Tested-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Link: https://lore.kernel.org/r/20210409094606.4317-1-wsa+renesas@sang-engineering.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
Revision tags: 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 |
|
#
7320915c |
| 03-Sep-2020 |
Douglas Anderson <dianders@chromium.org> |
mmc: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in v4.14
This is like commit 3d3451124f3d ("mmc: sdhci-msm: Prefer asynchronous probe") but applied to a whole pile of drivers. This batc
mmc: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in v4.14
This is like commit 3d3451124f3d ("mmc: sdhci-msm: Prefer asynchronous probe") but applied to a whole pile of drivers. This batch converts the drivers that appeared to be around in the v4.14 timeframe.
Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com> # SDHI drivers Link: https://lore.kernel.org/r/20200903162412.3.Id1ff21470f08f427aedd0a6535dcd83ccc56b278@changeid Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
Revision tags: 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, 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, v5.4.33, v5.4.32, v5.4.31, v5.4.30, v5.4.29, v5.6, 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, 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, v5.3.5, v5.3.4, v5.3.3, v5.3.2, v5.3.1, v5.3, v5.2.14, v5.3-rc8, v5.2.13, v5.2.12, v5.2.11, v5.2.10 |
|
#
bb716606 |
| 20-Aug-2019 |
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> |
mmc: renesas_sdhi_sys_dmac: Remove all R-Car Gen3 SoCs
All R-Car Gen3 SoCs with any ES version cannot use this DMAC actually. So, this patch removes the compatibles of R-Car Gen3 SoCs from renesas_s
mmc: renesas_sdhi_sys_dmac: Remove all R-Car Gen3 SoCs
All R-Car Gen3 SoCs with any ES version cannot use this DMAC actually. So, this patch removes the compatibles of R-Car Gen3 SoCs from renesas_sdhi_sys_dmac_of_match. Since the previous code has an empty whitelist to prevent probing of R-Car Gen3 SoCs, no behavior changes.
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
Revision tags: v5.2.9, v5.2.8, v5.2.7, v5.2.6, v5.2.5, v5.2.4, v5.2.3, v5.2.2, v5.2.1, v5.2, v5.1.16, v5.1.15, v5.1.14, v5.1.13, v5.1.12, v5.1.11, v5.1.10, v5.1.9, v5.1.8, v5.1.7, v5.1.6, v5.1.5, v5.1.4, v5.1.3, v5.1.2, v5.1.1, v5.0.14, v5.1, v5.0.13, v5.0.12, v5.0.11, v5.0.10, v5.0.9, v5.0.8, v5.0.7, v5.0.6, v5.0.5, v5.0.4, v5.0.3 |
|
#
2a55c1ea |
| 14-Mar-2019 |
Wolfram Sang <wsa+renesas@sang-engineering.com> |
mmc: renesas_sdhi: prevent overflow for max_req_size
max_req_size is calculated by 'max_blk_size * max_blk_count' in the TMIO core. So, specifying U32_MAX as max_blk_count will overflow this calcula
mmc: renesas_sdhi: prevent overflow for max_req_size
max_req_size is calculated by 'max_blk_size * max_blk_count' in the TMIO core. So, specifying U32_MAX as max_blk_count will overflow this calculation. It will cause no harm in practice because the immense high number will overflow into another immense high number. However, it is not good coding practice, so calculate max_blk_count so that max_req_size will fit into unsigned int on ARM32/64.
Thanks to the Renesas BSP team for the bug report!
Reported-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
#
f49bdcde |
| 14-Mar-2019 |
Wolfram Sang <wsa+renesas@sang-engineering.com> |
mmc: renesas_sdhi: update copyright information
Mostly year updates, but one addition as well.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Simon Horman <horms+renesa
mmc: renesas_sdhi: update copyright information
Mostly year updates, but one addition as well.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
Revision tags: v4.19.29, v5.0.2, v4.19.28, v5.0.1, v4.19.27, v5.0, v4.19.26, v4.19.25 |
|
#
5603731a |
| 21-Feb-2019 |
Takeshi Saito <takeshi.saito.xv@renesas.com> |
mmc: tmio: fix access width of Block Count Register
In R-Car Gen2 or later, the maximum number of transfer blocks are changed from 0xFFFF to 0xFFFFFFFF. Therefore, Block Count Register should use io
mmc: tmio: fix access width of Block Count Register
In R-Car Gen2 or later, the maximum number of transfer blocks are changed from 0xFFFF to 0xFFFFFFFF. Therefore, Block Count Register should use iowrite32().
If another system (U-boot, Hypervisor OS, etc) uses bit[31:16], this value will not be cleared. So, SD/MMC card initialization fails.
So, check for the bigger register and use apropriate write. Also, mark the register as extended on Gen2.
Signed-off-by: Takeshi Saito <takeshi.saito.xv@renesas.com> [wsa: use max_blk_count in if(), add Gen2, update commit message] Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Cc: stable@kernel.org Reviewed-by: Simon Horman <horms+renesas@verge.net.au> [Ulf: Fixed build error] Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
Revision tags: v4.19.24, v4.19.23, v4.19.22, v4.19.21, v4.19.20, v4.19.19, v4.19.18, v4.19.17, v4.19.16, v4.19.15, v4.19.14, v4.19.13, v4.19.12, v4.19.11, v4.19.10, v4.19.9, v4.19.8, v4.19.7, v4.19.6 |
|
#
2c907f05 |
| 28-Nov-2018 |
Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> |
mmc: renesas_sdhi: align compatibility properties for H3 and M3-W
It was though all ES revisions of H3 and M3-W SoCs required the TMIO_MMC_HAVE_4TAP_HS400 flag. Recent datasheet updates tells us thi
mmc: renesas_sdhi: align compatibility properties for H3 and M3-W
It was though all ES revisions of H3 and M3-W SoCs required the TMIO_MMC_HAVE_4TAP_HS400 flag. Recent datasheet updates tells us this is not true, only early ES revisions of the SoC do.
Since quirk matching based on ES revisions is now used to handle the flag it's possible to align all Gen3 compatibility properties. This will allow later ES revisions of H3 and M3-W to use the correct 8-tap HS400 mode.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
Revision tags: v4.19.5, v4.19.4, v4.18.20, v4.19.3, v4.18.19, v4.19.2, v4.18.18, v4.18.17, v4.19.1, v4.19, v4.18.16, v4.18.15, v4.18.14 |
|
#
d3dd5db0 |
| 12-Oct-2018 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
mmc: tmio: simplify the DMA mode test
host->chan_{rx,tx} represents the DMA capability of the platform. Even if DMA is supported, there are cases where we want to use PIO, for example, data length i
mmc: tmio: simplify the DMA mode test
host->chan_{rx,tx} represents the DMA capability of the platform. Even if DMA is supported, there are cases where we want to use PIO, for example, data length is short enough as commit 5f52c3552946 ("mmc: tmio: use PIO for short transfers") mentioned.
Regarding the hardware control flow, we are interested in whether DMA is currently enabled or not, instead of whether the platform has the DMA capability.
Hence, the several conditionals in tmio_mmc_core.c end up with checking host->chan_{rx,tx} and !host->force_pio. This is not nice.
Let's flip the flag host->force_pio into host->dma_on.
host->dma_on represents whether the DMA is currently enabled or not. This flag is set false in the beginning of each command, then should be set true by tmio_mmc_start_dma() when the DMA is turned on.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
Revision tags: v4.18.13, v4.18.12, v4.18.11, v4.18.10, v4.18.9, v4.18.7, v4.18.6, v4.18.5, v4.17.18, v4.18.4 |
|
#
f707079d |
| 21-Aug-2018 |
Wolfram Sang <wsa+renesas@sang-engineering.com> |
mmc: use SPDX identifier for Renesas drivers
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Ulf Hansson <ulf.han
mmc: use SPDX identifier for Renesas drivers
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
#
2ea15030 |
| 11-Sep-2018 |
Wolfram Sang <wsa+renesas@sang-engineering.com> |
mmc: sdhi: sys_dmac: check for all Gen3 types when whitelisting
Fixes: 26eb2607fa28 ("mmc: renesas_sdhi: add eMMC HS400 mode support") Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
mmc: sdhi: sys_dmac: check for all Gen3 types when whitelisting
Fixes: 26eb2607fa28 ("mmc: renesas_sdhi: add eMMC HS400 mode support") Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
Revision tags: v4.18.3, v4.17.17, v4.18.2, v4.17.16, v4.17.15, v4.18.1, v4.18, v4.17.14, v4.17.13, v4.17.12, v4.17.11, v4.17.10, v4.17.9, v4.17.8, v4.17.7, v4.17.6, v4.17.5, v4.17.4, v4.17.3 |
|
#
26eb2607 |
| 18-Jun-2018 |
Masaharu Hayakawa <masaharu.hayakawa.ry@renesas.com> |
mmc: renesas_sdhi: add eMMC HS400 mode support
This patch adds processing for selecting HS400 mode.
Signed-off-by: Masaharu Hayakawa <masaharu.hayakawa.ry@renesas.com> Signed-off-by: Simon Horman <
mmc: renesas_sdhi: add eMMC HS400 mode support
This patch adds processing for selecting HS400 mode.
Signed-off-by: Masaharu Hayakawa <masaharu.hayakawa.ry@renesas.com> Signed-off-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
Revision tags: v4.17.2, v4.17.1, v4.17 |
|
#
ef5332c1 |
| 01-Jun-2018 |
Wolfram Sang <wsa+renesas@sang-engineering.com> |
mmc: renesas_sdhi: really fix WP logic regressions
This reverts commit e060d376cc61 ("mmc: renesas_sdhi: fix WP detection") and adds some code to really fix the regressions.
It was missed so far th
mmc: renesas_sdhi: really fix WP logic regressions
This reverts commit e060d376cc61 ("mmc: renesas_sdhi: fix WP detection") and adds some code to really fix the regressions.
It was missed so far that Renesas R-Car instantiations of SDHI chose to disable internal WP and used the existence of "wp-gpios" to en/disable WP at all.
With the first refactoring by Yamada-san with commit 2ad1db059b9a ("mmc: renesas_sdhi: use MMC_CAP2_NO_WRITE_PROTECT instead of TMIO own flag"), WP was always disabled even when GPIOs were present. With Wolfram's first fix which gets now reverted, GPIOs were honored. But when not available, the fallback was to internal WP and not to disabled WP. This caused wrong WP status on uSD card slots.
Restore the old behaviour now. By default, WP is disabled. When a GPIO is found, the GPIO re-enables WP. We will think about possible better ways to handle this in the future.
Tested on a previously regressing Renesas Lager board (H2) and a still working Renesas Salvator-X board (M3-W).
Reported-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Cc: stable@vger.kernel.org # v4.17+ Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
Revision tags: v4.16 |
|
#
e060d376 |
| 05-Mar-2018 |
Wolfram Sang <wsa+renesas@sang-engineering.com> |
mmc: renesas_sdhi: fix WP detection
Commit "mmc: renesas_sdhi: use MMC_CAP2_NO_WRITE_PROTECT instead of TMIO own flag" activated MMC_CAP2_NO_WRITE_PROTECT for Renesas SDHI which incorrectly disabled
mmc: renesas_sdhi: fix WP detection
Commit "mmc: renesas_sdhi: use MMC_CAP2_NO_WRITE_PROTECT instead of TMIO own flag" activated MMC_CAP2_NO_WRITE_PROTECT for Renesas SDHI which incorrectly disabled WP altogether instead of only disabling the internal mechanism. Since the whole WP handling has been reworked, we can simply disable this capability to re-enable WP GPIOs.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
Revision tags: v4.15 |
|
#
b12a7a28 |
| 17-Jan-2018 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
mmc: tmio: move TMIO_MASK_{READOP, WRITEOP} handling to correct place
As far as I tested the IP on UniPhier SoCs, TMIO_STAT_{RXRDY,TXRQ} are asserted for DMA mode as well as for PIO. I need to disa
mmc: tmio: move TMIO_MASK_{READOP, WRITEOP} handling to correct place
As far as I tested the IP on UniPhier SoCs, TMIO_STAT_{RXRDY,TXRQ} are asserted for DMA mode as well as for PIO. I need to disable the those IRQs in dma_ops->start hook, otherwise the DMA transfer fails with the following error message: PIO IRQ in DMA mode!
Renesas chips are the same cases since I see their dma_ops->start hooks explicitly clear TMIO_STAT_{RXRDY,TXRQ} (with nice comment!).
If we do this sanity check in TMIO MMC core, RXRDY/TXRQ handling should be entirely moved to the core. tmio_mmc_cmd_irq() will be a suitable place to disable them.
The probe function sets TMIO_MASK_{READOP,WRITEOP} but this is odd.
/* Unmask the IRQs we want to know about */ if (!_host->chan_rx) irq_mask |= TMIO_MASK_READOP; if (!_host->chan_tx) irq_mask |= TMIO_MASK_WRITEOP;
At this point, _host->{chan_rx,chan_tx} are _always_ NULL because tmio_mmc_request_dma() is called after this code. Consequently, TMIO_MASK_{READOP,WRITEOP} are set here whether DMA is used or not. Remove this pointless code.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
show more ...
|
#
2ad1db05 |
| 17-Jan-2018 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
mmc: renesas_sdhi: use MMC_CAP2_NO_WRITE_PROTECT instead of TMIO own flag
TMIO_MMC_WRPROTECT_DISABLE is equivalent to MMC_CAP2_NO_WRITE_PROTECT.
The flag is propagated as follows: renesas_sd
mmc: renesas_sdhi: use MMC_CAP2_NO_WRITE_PROTECT instead of TMIO own flag
TMIO_MMC_WRPROTECT_DISABLE is equivalent to MMC_CAP2_NO_WRITE_PROTECT.
The flag is propagated as follows: renesas_sdhi_of_data::capabilities2 -> tmio_mmc_data::capabilities2 -> mmc_host::caps2
Only the difference is the TMIO_... makes tmio_mmc_get_ro() return 0 (i.e. it does not affect mmc_gpio_get_ro() at all), while MMC_CAP2_... returns 0 before calling ->get_ro() hook (i.e. it affects both IP own logic and GPIO detection).
The TMIO MMC drivers do not set-up gpio_ro by themselves. Only the possibility, if any, would be DT specifies "wp-gpios" property, and gpio_ro is set by mmc_gpiod_request_ro() called from mmc_of_parse(). However, it does not make sense to specify "wp-gpios" property and TMIO_MMC_WRPROTECT_DISABLE at the same time.
I checked under arch/arm/boot/dts/ and arch/arm64/boot/dts/renesas/, and I did not see any Renesas boards with "wp-gpios". So, this conversion should be safe.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
show more ...
|
#
b8155d3f |
| 09-Jan-2018 |
Dan Carpenter <dan.carpenter@oracle.com> |
mmc: tmio, renesas_sdhi: Remove unneeded NULL check
The inconsistent NULL checking in this function causes static checker warnings.
drivers/mmc/host/renesas_sdhi_sys_dmac.c:360 renesas_sdhi_sys
mmc: tmio, renesas_sdhi: Remove unneeded NULL check
The inconsistent NULL checking in this function causes static checker warnings.
drivers/mmc/host/renesas_sdhi_sys_dmac.c:360 renesas_sdhi_sys_dmac_issue_tasklet_fn() error: we previously assumed 'host' could be null (see line 351)
On reviewing this code, "host" can't ever be NULL so we can just remove the check.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
#
90d95106 |
| 24-Nov-2017 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
mmc: tmio, renesas_sdhi: move Renesas-specific DMA data to renesas_sdhi.h
struct tmio_mmc_host has "dma_dataend" and "dma_complete", but in fact, they are Renesas private data. Move them to renesas
mmc: tmio, renesas_sdhi: move Renesas-specific DMA data to renesas_sdhi.h
struct tmio_mmc_host has "dma_dataend" and "dma_complete", but in fact, they are Renesas private data. Move them to renesas_sdhi.h
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
#
058db286 |
| 24-Nov-2017 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
mmc: tmio, renesas_sdhi: move struct tmio_mmc_dma to renesas_sdhi.h
struct tmio_mmc_dma looks like TMIO core data, but in fact, Renesas private data. Move it to renesas_sdhi.h (probably, it is bett
mmc: tmio, renesas_sdhi: move struct tmio_mmc_dma to renesas_sdhi.h
struct tmio_mmc_dma looks like TMIO core data, but in fact, Renesas private data. Move it to renesas_sdhi.h (probably, it is better to rename it to renesas_sdhi_dma, or squash it into struct renesas_sdhi).
I also moved struct renesas_sdhi and host_to_priv() to that header because they are necessary to convert the tmio_mmc_host pointer into the renesas_sdhi pointer.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|