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 5f52c35529
("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>
The RZ/G1C (a.k.a. R8A77470) comes with three SDHI interfaces,
SDHI0 and SDHI2 are compatible with the R-Car Gen2 SDHIs, SDHI1
is compatible with R-Car Gen3 SDHIs and it can be used as
eMMC as well. This patch adds driver compatibility, and makes
sure both drivers get compiled for the R8A77470.
Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Reviewed-by: Biju Das <biju.das@bp.renesas.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Fix warning when running with CONFIG_DMA_API_DEBUG_SG=y by allocating a
device_dma_parameters structure and filling in the max segment size. The
size used is the result of a discussion with Renesas hardware engineers
and unfortunately not found in the datasheet.
renesas_sdhi_internal_dmac ee140000.sd: DMA-API: mapping sg segment
longer than device claims to support [len=126976] [max=65536]
Reported-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
[wsa: simplified some logic after validating intended dma_parms life cycle
and added comment]
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
I have encountered an interrupt storm during the eMMC chip probing (and
the chip finally didn't get detected). It turned out that U-Boot left
the SDHI DMA interrupts enabled while the Linux driver didn't use those.
Masking those interrupts in renesas_sdhi_internal_dmac_request_dma() gets
rid of both issues...
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Fixes: 2a68ea7896 ("mmc: renesas-sdhi: add support for R-Car Gen3 SDHI DMAC")
Cc: stable@vger.kernel.org # v4.14+
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
This patch is fixes an issue that the SDHI_INTERNAL_DMAC_RX_IN_USE
flag cannot be cleared because tmio_mmc_core sets the host->data
to NULL before the tmio_mmc_core calls tmio_mmc_abort_dma().
So, this patch clears the SDHI_INTERNAL_DMAC_RX_IN_USE in
the renesas_sdhi_internal_dmac_abort_dma() anyway. This doesn't
cause any side effects.
Fixes: 0cbc94daa5 ("mmc: renesas_sdhi_internal_dmac: limit DMA RX for old SoCs")
Cc: <stable@vger.kernel.org> # v4.17+
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
This reverts commit e060d376cc ("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 2ad1db059b ("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>
Sometimes sg->offset is not used for buffer addresses allocated by
dma_map_sg(), so alignment checks should be done on the allocated buffer
addresses. Delete the alignment check for sg->offset that is done before
dma_map_sg(). Instead, it performs the alignment check for
sg->dma_address after dma_map_sg().
Signed-off-by: Masaharu Hayakawa <masaharu.hayakawa.ry@renesas.com>
[Niklas: broke this commit in two and tidied small style issue]
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
[rebased to mmc/next]
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>
Instead of directly accessing the members of struct scatterlist use the
helpers mmc_get_dma_dir() and sg_dma_address() in
renesas_sdhi_internal_dmac_start_dma(). Based on previous work by
Masaharu Hayakawa.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
[rebased to mmc/next]
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>
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>
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>
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>
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>
Implement fallback compatibility strings for R-Car Gen 1, 2 and 3.
In the case of Renesas R-Car hardware we know that there are generations of
SoCs, f.e. Gen 1 and 2. But beyond that its not clear what the relationship
between IP blocks might be. For example, I believe that r8a7790 is older
than r8a7791 but that doesn't imply that the latter is a descendant of the
former or vice versa.
We can, however, by examining the documentation and behaviour of the
hardware at run-time observe that the current driver implementation appears
to be compatible with the IP blocks on SoCs within a given generation.
For the above reasons and convenience when enabling new SoCs a
per-generation fallback compatibility string scheme is being adopted for
drivers for Renesas SoCs.
Also, improve readability by listing the shmobile fallback compatibility
string after the more-specific compatibility strings they provide a
fallback for.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
There is one SDHI instance on Gen2 which does not have the CBSY bit.
So, turn CBSY usage into an extra flag and set it accordingly. This has
the additional advantage that we can also set it for other incarnations
later.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Tested-by: Chris Brandt <Chris.Brandt@renesas.com>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
The structure renesas_sdhi_internal_dmac_dma_ops is only passed as
the second argument to renesas_sdhi_probe, which is const, so
renesas_sdhi_internal_dmac_dma_ops can be const too.
Done with the help of Coccinelle.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Provide a whitelist for Gen3 SoC ES versions for both the SYS DMAC and
internal DMAC variants of the SDHI driver. This is to allow drivers to
only initialise for Gen3 SoC ES versions for which they are the appropriate
DMAC implementation. Currently internal DMAC is the appropriate
implementation for all supported Gen3 SoC ES versions.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
