The RAM_ROCKCHIP_DEBUG can be used only if DEBUG_UART is
available.
The next commit introduces changes in definition of debug
uart functions, so that DEBUG_UART is required to be defined
in order to initialize uart and use print functions.

Signed-off-by: Lukasz Czechowski <lukasz.czechowski@thaumatec.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>

This patch cleans the vendor code of DDR initialization up, converts the
driver to fit in DM framework and use a firmware[1] packaged by binman to
ship PHY configuration.

Currently the driver is only capable of initializing the controller to
work with dual-rank 3733MHz LPDDR4, which is shipped by 16GiB variants
of LicheePi 4A boards and I could test with. Support for other
configurations could be easily added later.

Link: https://github.com/ziyao233/th1520-firmware # [1]
Signed-off-by: Yao Zi <ziyao@disroot.org>
Reviewed-by: Leo Yu-Chi Liang <ycliang@andestech.com>

Add ddr driver for rk3576 to get the ram capacity.

Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

Add support for reading DRAM size information from PMUGRF os_reg18 reg.

Compared to most Rockchip SoCs the RK3528 use os_reg18 for DRAM info,
instead of os_reg2.

Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>

Currently in j721e_init.c we check which firewalls to remove using
the board configuration (e.g CONFIG_TARGET_J721E_R5_EVM). We do this
as J721e and J7200 have different IP and firewalls but use the same
SoC definition (SOC_K3_J721E) even though they are different SoCs.

The idea was they would be similar enough that they both could use
the same SoC config to help with common code sharing. Board checks
would then be used differentiate.

This has grown far too messy to maintain any more, especially now
that there is more than one board using J721e (EVM, SK, Beagle AI64).
As differentiation is done based on board, every one of these boards
would have to have checks added for them. Instead let's split J7200
support out from J721e like how normal new SoC support is done.

This patch touches several subsystems and could not be split much better
as when we add SOC_K3_J7200 we want to make use of it in all spots that
once used the combined SOC_K3_J721E so we can turn off SOC_K3_J721E when
building for J7200 boards.

Signed-off-by: Andrew Davis <afd@ti.com>

Pass DBSC5 udevice and MODEMR0 register values to board specific
function dbsc5_get_board_data(). The board specific implementation
of dbsc5_get_board_data() can return struct renesas_dbsc5_board_config
which matches the board based on the content of MODEMR0 or content
of DT accessible via the udevice.

Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>

Extract wait for completion code from dbsc5_send_dbcmd2() into
new separate function dbsc5_wait_dbwait(). This extracted code
can be used to implement MR register read in the future.

Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>

Update dbsc5_send_dbcmd2() such that it takes multiple parameters
instead of one magic register content value. These parameters are
used to form the same resulting register value internally in the
dbsc5_send_dbcmd2() function, but from well defined input constants.
The new input constants are the operation code, channel, rank, and
operation argument. The argument is operation code specific, therefore
it is still a 16-bit magic number, but the rest of the arguments are
now split up. No functional change.

Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>

Remove leading space before dbsc5_ddr_setval_all_ch() , no functional change.

Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>

Rename dbsc5_ddr_register_read() to dbsc5_ddr_register_mr27_mr57_read()
and dbsc5_ddr_register_set() to dbsc5_ddr_register_mr28_set() to make
it clear what those functions really do. No functional change.

Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>