The R-Car3 SDHI should set these two bits in DMA_MODE register according
to the specification, to indicate 64bit bus width. No other bus width
options are permitted and the default value is 0, which is incorrect.
Set the bits accordingly.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
We use 'priv' for private data but often use 'platdata' for platform data.
We can't really use 'pdata' since that is ambiguous (it could mean private
or platform data).
Rename some of the latter variables to end with 'plat' for consistency.
Signed-off-by: Simon Glass <sjg@chromium.org>
This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.
Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.
Signed-off-by: Simon Glass <sjg@chromium.org>
The r8a774a1 is compatible with the generic rcar-gen3-sdhi controller.
This patch adds the compatibilty flag, to support the SDHI controller.
Signed-off-by: Adam Ford <aford173@gmail.com>
Implement get_b_max() for the Renesas R-Car SDHI controller driver, limit
the b_max per hardware capabilities such that select Gen2 controllers have
16bit block transfer limit, the rest has 32bit block transfer limit and on
Gen3, the block transfer limit on addresses above the 32bit boundary is set
to 1/4 of the malloc area.
Originally, on Gen3, the block transfers above the 32bit area were limited
to PIO only, which resulted in (R8A7795 Salvator-X , HS200 eMMC):
=> time mmc read 0x0000000700000000 0 0x10000
time: 0.151 seconds
=> time mmc read 0x0000000700000000 0 0x100000
time: 11.090 seconds
with bounce buffer in place and b_max adjustment in place:
=> time mmc read 0x0000000700000000 0 0x10000
time: 0.156 seconds
=> time mmc read 0x0000000700000000 0 0x100000
time: 2.349 seconds
Note that the bounce buffer does mallocate and free the bounce buffer
for every transfer. Experiment which removes this results in further
increase of read speed, from 2.349s to 2.156s per 512 MiB of data,
which is not such a significant improvement anymore. It might however
be interesting to have bounce buffer directly in the MMC core or even
block core.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Peng Fan <peng.fan@nxp.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
The R-Car SDHI DMA controller has various restrictions. To work around
those restrictions without falling back to PIO, implement bounce buffer
with custom alignment check function which tests for those limitations.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Peng Fan <peng.fan@nxp.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
At present dm/device.h includes the linux-compatible features. This
requires including linux/compat.h which in turn includes a lot of headers.
One of these is malloc.h which we thus end up including in every file in
U-Boot. Apart from the inefficiency of this, it is problematic for sandbox
which needs to use the system malloc() in some files.
Move the compatibility features into a separate header file.
Signed-off-by: Simon Glass <sjg@chromium.org>
Instead of using single fixed value for the calibration offset,
add tables which dynamically adjust this per calibration code
from the SCC.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Some of the tuning taps produce suboptimal results. Add code
which skips those "bad" taps.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Check SCC for errors after check command if applicable and
optionally adjust the bus skew settings accordingly.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Disable the auto-retuning in HS400 mode in favor of manual calibration.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Adjust the TMPPORT3 offsets according to the latest information
from the chip vendor.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Adjust the DT2FF offsets in HS400 according to latest information
from the chip vendor.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
The M3W up to ES1.2 uses 4 tuning taps for HS400, make it so.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Retain the SMPCMP value from last calibration in private data.
This will be later used for skipping bad taps.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Retain the tap number from last calibration in private data. This
will be later used for SCC error checking after each command.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
It's quite hard to figure out time units for various function that have
timeout parameters. This leads to possible errors when one forgets to
convert ms to us, for example. Let's rename those parameters
correspondingly to 'timeout_us' and 'timeout_ms' to prevent such issues
further.
While at it, add time units info as comments to struct mmc fields.
This commit doesn't change the behavior, only renames parameters names.
Buildman should report no changes at all.
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Igor Opaniuk <igor.opaniuk@gmail.com>
Since Gen3 SDHI has an internal DS signal AC-spec violation in HS400 mode,
CRC-error may occur in read command in HS400 mode. This phoenomenon occurs
at low/high temperature.
To fix this, after completion of HS400 tuning, enable manual calibration.
However, Gen3 M3 Ver.1.2 or earlier and H3 1.x does not support HS400.
These SoC forcibly use HS200 mode by SoC attribute.
The DT adjustment of the tuning parameters is not supported until the
DT property names become clear.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Adapted from a patch by Takeshi Saito <takeshi.saito.xv@renesas.com>
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Cc: Peng Fan <peng.fan@nxp.com>
Clean up the whitespaces in macros, no functional change.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Cc: Peng Fan <peng.fan@nxp.com>
According to latest specification rev.0026 and after confirmation with
HW engineer, the DTCNTL register TAPNUM field must be set to 8 even on
H3 ES2.0 SoC. Make it so.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
The DT2FF register must be configured differently for HS400 mode
and for HS200/SDR104 mode. Configure the DT2FF register according
to the recommended datasheet settings for each mode.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Different versions of the SDHI core use either bit 17 or bit 20 for the
DTRAEND indication, which can differ even between SoC revisions. Make
the DTRAEND bit position part of the driver private data, so that the
probe function can set this accordingly. Set this to 20 on Socionext
SoCs and either 17 or 20 on Renesas SoCs, depending on the SoC.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Add support for the HS400 mode to SDHI driver. This uses the up-tune
mechanism from already supported HS200 tuning.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Move the tap_pos variable, which is the HS200/HS400/SDR104 calibration
offset, into private data, so it can be passed around. This is done in
preparation for the HS400 mode, which needs to adjust this value.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Filter out HS400 support on SoCs where HS400 is not supported yet.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Switch the driver to using clk_get_rate()/clk_set_rate() instead of
caching the mclk frequency in it's private data. This is required on
the SDHI variant of the controller, where the upstream mclk need to
be adjusted when using UHS modes.
Platforms which do not support clock framework or do not support it
in eg. SPL default to 100 MHz clock.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
---
V2: - Fix build on certain platforms using SPL without clock framework
V3: - Turn clk_get_rate into a callback and fill it as needed on both
renesas and socionext platforms
It is perfectly fine to write th DTCNTL TAP count and enable the
SCC sampling clock operation in the same write.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
When the bus switches to 1.8V mode of operation, it is necessary to
verify that the card correctly initiated and completed the voltage
switch. This is done by reading out the state of DATA0 line.
This patch implement support for reading out the state of the DATA0
line, so the MMC core code can correctly switch to 1.8V mode.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Make sure to clear HS400 configuration when resetting the SCC block.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Add check to avoid touching the SCC tuning registers in case the IP
doesn't support them or if the support isn't in place yet.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
The dev_get_priv(dev) is used twice in the probe function.
Replace the second invocation with priv variable.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Add new compatible to the Uniphier SD driver for R8A77990 E3 SoC.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
When U-Boot started using SPDX tags we were among the early adopters and
there weren't a lot of other examples to borrow from. So we picked the
area of the file that usually had a full license text and replaced it
with an appropriate SPDX-License-Identifier: entry. Since then, the
Linux Kernel has adopted SPDX tags and they place it as the very first
line in a file (except where shebangs are used, then it's second line)
and with slightly different comment styles than us.
In part due to community overlap, in part due to better tag visibility
and in part for other minor reasons, switch over to that style.
This commit changes all instances where we have a single declared
license in the tag as both the before and after are identical in tag
contents. There's also a few places where I found we did not have a tag
and have introduced one.
Signed-off-by: Tom Rini <trini@konsulko.com>
I need to differentiate the clock handling for uniphier-sd. Move it
to each driver's probe function from the tmio common code so that
renesas-sdhi will not be affected.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Synchronize the naming with Linux, call the common code TMIO.
No functional change.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Jaehoon Chung <jh80.chung@samsung.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
The IP requires some time to recuperate after the IO pin
properties were changed. Add a delay to assure this.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Jaehoon Chung <jh80.chung@samsung.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Add code for PHY tuning required for SDR104/HS200 support on Renesas RCar.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Jaehoon Chung <jh80.chung@samsung.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Add a quirk to identify that the controller is Renesas RCar variant
of the Matsushita SD IP and another quirk indicating it can support
Renesas RCar HS200/HS400/SDR104 modes.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Jaehoon Chung <jh80.chung@samsung.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
The Renesas RCar Gen2 chips have a mix of 32bit and 16bit variants
of the IP. There is no DT property which allows discerning those,
so what Linux does is it checks the size of the register area and
if it is 0x100, the IP is 16bit, otherwise the IP is 32bit. Handle
the distinction the same way.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Jaehoon Chung <jh80.chung@samsung.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Certain instances of the SD IP require more elaborate digging
in the DT to figure out which variant of the SD IP is in use.
Allow explicit passing of the quirks into the probe function.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Jaehoon Chung <jh80.chung@samsung.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Factor out common code from the uniphier SD driver, change the prefix
of the functions from uniphier_sd_ to matsu_sd_ and create separate
renesas-sdhi.c driver. Thus far, all the code is still compiled when
CONFIG_UNIPHIER_MMC is selected and there is no functional change.
This patch is a preparation for further split of the SoC specific
parts of the Matsushita SD driver, used both on Uniphier and R-Car.
Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Jaehoon Chung <jh80.chung@samsung.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
