According to the HW team, for some reason the normal clock select code
picks what appears to be a perfectly valid 375KHz SD card clock, based
on the CAR clock source and SDMMC1 controller register settings (CAR =
408MHz PLLP0 divided by 68 for 6MHz, then a SD Clock Control register
divisor of 16 = 375KHz). But the resulting SD card clock, as measured by
the HW team, is 700KHz, which is out-of-spec. So the WAR is to use the
values given in the TRM PLLP table to generate a 400KHz SD-clock (CAR
clock of 24.7MHz, SD Clock Control divisor of 62) only for SDMMC1 on
T210 when the requested clock is <= 400KHz. Note that as far as I can
tell, the other requests for clocks in the Tegra MMC driver result in
valid SD clocks.
Signed-off-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
As per the T210 TRM, when running at 3.3v, the SDMMC1 tap/trim and
autocal values need to be set to condition the signals correctly before
talking to the SD-card. This is the same as what's being done in CBoot,
but it gets reset when the SDMMC1 HW is soft-reset during SD driver
init, so needs to be repeated here. Also set autocal and tap/trim for
SDMMC3, although no T210 boards use it for SD-card at this time.
Signed-off-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
At present devres.h is included in all files that include dm.h but few
make use of it. Also this pulls in linux/compat which adds several more
headers. Drop the automatic inclusion and require files to include devres
themselves. This provides a good indication of which files use devres.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Anatolij Gustschin <agust@denx.de>
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>
We have a large number of places where while we historically referenced
gd in the code we no longer do, as well as cases where the code added
that line "just in case" during development and never dropped it.
Signed-off-by: Tom Rini <trini@konsulko.com>
Update the tegra mmc driver to support a live device tree.
Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Tested-on: Beaver, Jetson-TK1
Tested-by: Stephen Warren <swarren@nvidia.com>
The driver currently does not reset bit 5 of the hostctl register even if
the MMC stack requests it. Then means that once a bus width of 8 is
selected it is not possible to change it back to 1. This breaks
'mmc rescan' which needs to start off with a bus width of 1.
The problem was surfaced by enabling CONFIG_DM_MMC_OPS on tegra. Without
this option the MMC stack fully reinits the driver on a 'mmc rescan'.
But with this option driver model does not re-probe a driver once it has
been probed once.
Fix the driver to honour the request.
Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Peter Chubb <peter.chubb@data61.csiro.au>
Tested-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
Enable CONFIG_DM_MMC_OPS and CONFIG_BLK for all Tegra devices. This moves
Tegra to use driver model fully for MMC.
Signed-off-by: Simon Glass <sjg@chromium.org>
These support the flat device tree. We want to use the dev_read_..()
prefix for functions that support both flat tree and live tree. So rename
the existing functions to avoid confusion.
In the end we will have:
1. dev_read_addr...() - works on devices, supports flat/live tree
2. devfdt_get_addr...() - current functions, flat tree only
3. of_get_address() etc. - new functions, live tree only
All drivers will be written to use 1. That function will in turn call
either 2 or 3 depending on whether the flat or live tree is in use.
Note this involves changing some dead code - the imx_lpi2c.c file.
Signed-off-by: Simon Glass <sjg@chromium.org>
This header includes things that are needed to make driver build. Adjust
existing users to include that always, even if other dm/ includes are
present
Signed-off-by: Simon Glass <sjg@chromium.org>
Introduce CONFIG_TEGRA124_MMC_DISABLE_EXT_LOOPBACK to disable the external clock
loopback and use the internal one on SDMMC3 as per the SDMMC_VENDOR_MISC_CNTRL_0
register's SDMMC_SPARE1 bits being set to 0xfffd according to the TRM.
Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Acked-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Marcel Ziswiler <marcel@ziswiler.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
At present devices use a simple integer offset to record the device tree
node associated with the device. In preparation for supporting a live
device tree, which uses a node pointer instead, refactor existing code to
access this field through an inline function.
Signed-off-by: Simon Glass <sjg@chromium.org>
Now that the standard clock/reset APIs are available for all Tegra SoCs,
convert the MMC driver to use them exclusively, and remove any references
to the custom Tegra-specific APIs.
Cc: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
Convert the Tegra MMC driver to DM_MMC. Support for non-DM is removed
to avoid ifdefs in the code. DM_MMC is now enabled for all Tegra builds.
Cc: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
(swarren, fixed some NULL pointer dereferences, removed extraneous
changes, rebased on various other changes, removed non-DM support etc.)
Signed-off-by: Stephen Warren <swarren@nvidia.com>
struct mmc_host is a Tegra-specific structure, but the name implies it's
something defined by core MMC code, which is confusing. Rename it to
struct tegra_mmc_priv to make its purpose more obvious. The new name is
also more appropriate for a DM driver private data structure, which will
be relevant later in this series.
Nothing needs access to this type except the MMC driver itself. Move the
definition into the driver C file.
Make sure all Tegra MMC functions are named tegra_mmc_*. Even though
they're all static, it's useful to have good naming so that symbol tables
are easy to interpret. A few functions aren't renamed by this patch since
they'll be deleted by a subsequent patch in this series.
Cc: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
The MMC driver will soon be converted to use standard clock/reset APIs,
and so the periph_id field in the MMC device priv struct will disappear.
Rework the implementation of pad_init_mmc() to rely on this; using the
device register address is a much more direct test anyway.
Cc: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
pad_init_mmc() is performing an SoC-specific operation, using registers
within the MMC controller. There's no reason to implement this code
outside the MMC driver, so move it inside the driver.
Cc: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
The Tegra MMC driver currently honors "sdhci" entries in /aliases. The
MMC core however uses "mmc" entries in /aliases. This difference will be
relevant once the Tegra MMC driver is converted to DM, and the MMC core
handles alias lookups. To avoid issues during that conversion, fix the
Tegra MMC driver and all Tegra DTs to use the same alias name as the MMC
core does.
Cc: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
The Tegra SDHCI binding dictates that the reseet name for the Tegra SDHCI
clock be "sdhci" not "sdmmc", and that the clock is accessed by index
rather than by name. Fix the Tegra186 DT and MMC driver to honor this.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
Tegra186 supports the new standard clock and reset APIs. Older Tegra SoCs
still use custom APIs. Enhance the Tegra MMC driver so that it can operate
with either set of APIs.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>
Use the generic error number instead of specific error number.
If use the generic error number, it can debug more easier.
Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Minkyu Kang <mk7.kang@samsung.com>
Tegra186's MMC controller needs to be explicitly identified. Add another
compatible value for it.
Tegra186 will use an entirely different clock/reset control mechanism to
existing chips, and will use standard clock/reset APIs rather than the
existing Tegra-specific custom APIs. The driver support for that isn't
ready yet, so simply disable all clock/reset usage if compiling for
Tegra186. This must happen at compile time rather than run-time since the
custom APIs won't even be compiled in on Tegra186. In the long term, the
plan would be to convert the existing custom APIs to standard APIs and get
rid of the ifdefs completely.
The system's main eMMC will work without any clock/reset support, since
the firmware will have already initialized the controller in order to
load U-Boot. Hence the driver is useful even in this apparently crippled
state.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
We have flipped CONFIG_SPL_DISABLE_OF_CONTROL. We have cleansing
devices, $(SPL_) and CONFIG_IS_ENABLED(), so we are ready to clear
away the ugly logic in include/fdtdec.h:
#ifdef CONFIG_OF_CONTROL
# if defined(CONFIG_SPL_BUILD) && !defined(SPL_OF_CONTROL)
# define OF_CONTROL 0
# else
# define OF_CONTROL 1
# endif
#else
# define OF_CONTROL 0
#endif
Now CONFIG_IS_ENABLED(OF_CONTROL) is the substitute. It refers to
CONFIG_OF_CONTROL for U-boot proper and CONFIG_SPL_OF_CONTROL for
SPL.
Also, we no longer have to cancel CONFIG_OF_CONTROL in
include/config_uncmd_spl.h and scripts/Makefile.spl.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Derived from Tegra124, modified as appropriate during T210
board bringup. Cleaned up debug statements to conserve
string space, too. This also adds misc 64-bit changes
from Thierry Reding/Stephen Warren.
Signed-off-by: Tom Warren <twarren@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
If the mmc device is non-removable (as indicated by the device tree), set
the flag so that users of the device know.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Joe Hershberger <joe.hershberger@ni.com>
High capacity support is not a host capability, but a device capability
that is queried via the OCR. The flag in the operating conditions
request argument can just be set unconditionally. This matches the Linux
implementation.
[panto] Hand merged and renumbering MMC_MODE_DDR_52MHz.
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
Cc: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
During rigorous testing of our latest update infrastructure I came
across quite consistent timeouts on certain eMMC parts (e.g. Hynix
H26M21001ECR) when writing big (e.g. in excess of 400 MB) file system
images:
MMC write: dev # 0, block # 40960, count 944128 ...
mmc_send_cmd_bounced: MMC Timeout
Interrupt status 0x00000001
Interrupt status enable 0xdfff003b
Interrupt signal enable 0xdfff0002
Present status 0x01870106
mmc write failed
Comparing the various data sheets I came across the following timeout
specification:
Secure Erase/TRIM Timeout=300ms*2*10=6000ms
Unfortunately empirical testing still failed albeit much more rarely.
Increasing the timeout to 8000ms made it finally disappear entirely.
This patch allows us writing various eMMC parts without seeing any
further issues.
Signed-off-by: Marcel Ziswiler <marcel@ziswiler.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
If CONFIG_API is ever to be enabled on Tegra, this define must be set,
since api/api_storage.c uses it.
A couple of annoyting things about CONFIG_SYS_MMC_MAX_DEVICE
1) It isn't documented in README. The same is true for a lot of similar
defines used by api_storage.c.
2) It doesn't represent MAX_DEVICE but rather NUM_DEVICES, since the
valid values are 0..n-1 not 0..n.
However, I this patch does not address those shortcomings.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
The way that struct mmc was implemented was a bit of a mess;
configuration and internal state all jumbled up in a single structure.
On top of that the way initialization is done with mmc_register leads
to a lot of duplicated code in drivers.
Typically the initialization got something like this in every driver.
struct mmc *mmc = malloc(sizeof(struct mmc));
memset(mmc, 0, sizeof(struct mmc);
/* fill in fields of mmc struct */
/* store private data pointer */
mmc_register(mmc);
By using the new mmc_create call one just passes an mmc config struct
and an optional private data pointer like this:
struct mmc = mmc_create(&cfg, priv);
All in tree drivers have been updated to the new form, and expect
mmc_register to go away before long.
Changes since v1:
* Use calloc instead of manually calling memset.
* Mark mmc_register as deprecated.
Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com>
Using an array is pointless; even more pointless (and scary) is using
sprintf to fill it without a format string.
Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com>
Remove the in-structure ops and put them in mmc_ops with
a constant pointer to it.
This makes the mmc structure smaller as well as conserving
code space (in theory).
All in-tree drivers are converted as well; this is done in a
single patch in order to not break git bisect.
Changes since V1:
Fix compilation b0rked issue on omap platforms where OMAP_GPIO was
not set.
Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com>
Tegra124's MMC controller is very similar to earlier SoC generations,
and can be supported by the same driver.
However, there are some non-backwards-compatible HW differences, and
hence a new DT compatible value must be used to describe the HW. This
patch updates the driver to support that new compatible value.
That said, the HW differences are only relevant when enabling certain
high-performance transfer modes. Since the driver is currently very
simple and doesn't enable those modes, we don't actually need to address
any of these HW differences in the code yet, hence the simple nature of
this patch.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Pantelis Antoniou <panto@antoniou-consulting.com>
Tested-by: Thierry Reding <treding@nvidia.com>
Acked-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Warren <twarren@nvidia.com>
Tegra30 requires the SD Bus Voltage & Power bits be set in the SD
Power Control register. Tegra20 works w/o them set, but do it anyway
for those SoCs as it's part of the SD spec. Also call a common
board pad init routine (pad_init_mmc) in mmc_reset(), used by
Tegra30 only for now.
Note that Tegra20 SD/MMC HW differs enough from Tegra20 that a
new compatible entry is used in the fdt compat_names/id tables.
Signed-off-by: Tom Warren <twarren@nvidia.com>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
tegra_mmc_init() now parses the DT info for bus width, WP/CD GPIOs, etc.
Tested on Seaboard, fully functional.
Tamonten boards (medcom-wide, plutux, and tec) use a different/new
dtsi file w/common settings.
Signed-off-by: Tom Warren <twarren@nvidia.com>
Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
Tegra's MMC driver does DMA, and hence needs cache-aligned buffers. In
some cases (e.g. user load commands) this cannot be guaranteed by callers
of the MMC APIs. To solve this, modify the Tegra MMC driver to use the
new bounce_buffer_*() APIs.
Note: Ideally, all U-Boot code will always provide address- and size-
aligned buffers, so a bounce buffer will only ever be needed for user-
supplied buffers (e.g. load commands). Ensuring this removes the need
for performance-sucking bounce buffer cache management and memcpy()s.
The one known exception at present is the SCR buffer in sd_change_freq(),
which is only 8 bytes long. Solving this requires enhancing struct
mmc_data to know the difference between buffer size and transferred data
size, or forcing all callers of mmc_send_cmd() to have allocated buffers
using ALLOC_CACHE_ALIGN_BUFFER(), which while true in this case, is not
enforced in any way at present, and so cannot be assumed by the core MMC
code.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Andy Fleming <afleming@freescale.com>
If a board has all 8 data lines routed, the SD/MMC controller can still
operate in 4-bit (or presumably even 1-bit) mode. Adjust Tegra's MMC
driver to report the 4-bit capability even for 8-bit slots.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Tom Warren <twarren@nvidia.com>
The move is pretty straight-forward. ap20.h and tegra20.h were renamed to ap.h and tegra.h.
Some files remain in arch-tegra20 but 'include' a file in 'arch-tegra' with #defines & structs
that will be common between T20 and T30 HW. HW-specific #defines, etc. stay in the 'arch-tegra20'
'root' file.
All boards build OK w/MAKEALL -s tegra20. Checkpatch.pl runs clean. Seaboard works OK.
Signed-off-by: Tom Warren <twarren@nvidia.com>
Convert TEGRA20_ defines to either TEGRA_ or NV_PA_ where appropriate.
Convert tegra20_ source file and function names to tegra_, also.
Upcoming Tegra30 port will use common code/defines/names where possible.
Signed-off-by: Tom Warren <twarren@nvidia.com>
Acked-by: Stephen Warren <swarren@nvidia.com>
This is make naming consistent with the kernel and devicetree and in
preparation of pulling out the common tegra20 code.
Signed-off-by: Allen Martin <amartin@nvidia.com>
Acked-by: Stephen Warren <swarren@wwwdotorg.org>
Tested-by: Thierry Reding <thierry.reding@avionic-design.de>
Signed-off-by: Tom Warren <twarren@nvidia.com>
In anticipation of Tegra3 support, continue removing/renaming
Tegra2-specific files. No functional changes (yet).
Updated copyrights to 2012.
Signed-off-by: Tom Warren <twarren@nvidia.com>
