At this point, the remaining places where we have a symbol that is
defined as CONFIG_... are in fairly odd locations. While as much dead
code has been removed as possible, some of these locations are simply
less obvious at first. In other cases, this code is used, but was
defined in such a way as to have been missed by earlier checks. Perform
a rename of all such remaining symbols to be CFG_... rather than
CONFIG_...
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The rest of the unmigrated CONFIG symbols in the CONFIG_SYS_SDRAM
namespace do not easily transition to Kconfig. In many cases they likely
should come from the device tree instead. Move these out of CONFIG
namespace and in to CFG namespace.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Placing Unicode control codes <U+0080><U+0093> in the middle of a comment
does not make much sense. Let's get rid of all Unicode in
drivers/ram/octeon/octeon3_lmc.c.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Stefan Roese <sr@denx.de>
default n/no doesn't need to be specified. It is default option anyway.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
[trini: Rework FSP_USE_UPD portion]
Signed-off-by: Tom Rini <trini@konsulko.com>
It is a pain to have to specify the value 10 in each call. Add a new
dectoul() function and update the code to use it.
Signed-off-by: Simon Glass <sjg@chromium.org>
With the newly added headers and their restructuring (which macro is
defined where), some changes in the already existing Octeon files are
necessary. This patch makes the necessary changes.
Signed-off-by: Stefan Roese <sr@denx.de>
Move this out of the common header and include it only where needed. In
a number of cases this requires adding "struct udevice;" to avoid adding
another large header or in other cases replacing / adding missing header
files that had been pulled in, very indirectly. Finally, we have a few
cases where we did not need to include <asm/global_data.h> at all, so
remove that include.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.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>
This Octeon 3 DDR driver is ported from the 2013 Cavium / Marvell U-Boot
repository. It currently supports DDR4 on Octeon 3. It can be later
extended to support also DDR3 and Octeon 2 platforms.
Part 3 includes the DIMM SPD handling code and the Kconfig / Makefile
integration.
Signed-off-by: Aaron Williams <awilliams@marvell.com>
Signed-off-by: Stefan Roese <sr@denx.de>
This Octeon 3 DDR driver is ported from the 2013 Cavium / Marvell U-Boot
repository. It currently supports DDR4 on Octeon 3. It can be later
extended to support also DDR3 and Octeon 2 platforms.
Part 2 includes the very complex Octeon 3 DDR4 configuration
Signed-off-by: Aaron Williams <awilliams@marvell.com>
Signed-off-by: Stefan Roese <sr@denx.de>
This Octeon 3 DDR driver is ported from the 2013 Cavium / Marvell U-Boot
repository. It currently supports DDR4 on Octeon 3. It can be later
extended to support also DDR3 and Octeon 2 platforms.
Part 1 adds the base U-Boot RAM driver, which will be instantiated by
the DT based probing.
Signed-off-by: Aaron Williams <awilliams@marvell.com>
Signed-off-by: Stefan Roese <sr@denx.de>
