The code here is confusing due to large blocks which are #ifdefed out.
Add a function phase_sdram_init() which returns whether SDRAM init
should happen in the current phase, using that as needed to control the
code flow.
This increases code size by about 500 bytes in SPL when the cache is on,
since it must call the rather large rockchip_sdram_size() function.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present gd->ram_size is 0 in SPL, meaning that it is not possible to
enable the cache. Correct this by always populating the RAM size
correctly.
This increases code size by about 500 bytes in SPL, since it must call
the rather large rockchip_sdram_size() function.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
As part of bringing the master branch back in to next, we need to allow
for all of these changes to exist here.
Reported-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>
When bringing in the series 'arm: dts: am62-beagleplay: Fix Beagleplay
Ethernet"' I failed to notice that b4 noticed it was based on next and
so took that as the base commit and merged that part of next to master.
This reverts commit c8ffd1356d, reversing
changes made to 2ee6f3a5f7.
Reported-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>
The different macros use writel which is defined in asm/io.h, so let's
include the header so users of hardware.h do not need to include
asm/io.h as well.
While at it, remove asm/io.h includes wherever
asm/arch-rockchip/hardware.h is included already.
Cc: Quentin Schulz <foss+uboot@0leil.net>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
The fdt_addr_t and phys_addr_t size have been decoupled.
A 32bit CPU can expect 64-bit data from the device tree parser,
so convert regmap_init_mem_plat() input to handel both. The
syscon class driver also makes use of the regmap_init_mem_plat()
function, but has no way of knowing the format of the
device-specific platform data. In case of odd reg structures other
then that the syscon class driver assumes the regmap must be
filled in the individual syscon driver before pre-probe.
Also fix the ARRAY_SIZE divider in the syscon class driver.
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
For 2 GB LPDDR4 single-rank RAM with 16 rows, the Rockchip ddr init bin
prints:
"Bus Width=32 Col=10 Bank=8 Row=16 CS=1 Die Bus-Width=16 Size=2048MB"
U-Boot TPL prints:
"BW=32 Col=10 Bk=8 CS0 Row=16/15 CS=1 Die BW=16 Size=2048MB"
Add missing high row detection so that U-Boot TPL prints Row=16, same as
the Rockchip ddr init bin:
"BW=32 Col=10 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=2048MB"
Signed-off-by: Jonathan Liu <net147@gmail.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
A condition in the rk3399 RAM initialization code used the old
CONFIG_RAM_RK3399_LPDDR4 constant name. This commit changes the
condition to use the correct CONFIG_RAM_ROCKCHIP_LPDDR4 constant.
Reviewed-by: Simon Glass <sjg@chromium.org>
DDR chip capacity is computed based on GRF split in some
Rockchip SoC's like PX30 and RV1126.
Add split argument in ddr print info so-that the respective
ddr driver will pass the grf split.
Signed-off-by: YouMin Chen <cym@rock-chips.com>
Signed-off-by: Jagan Teki <jagan@edgeble.ai>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
We have common ddr types in rockchip or in general. So use
the common ddr type names instead of per Rockchip SoC to
avoid confusion.
The respective ddr type names will use on the associated
ddr SoC driver as these drivers are built per SoC at a time.
Signed-off-by: Jagan Teki <jagan@edgeble.ai>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
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>
Currently the default initialisation frequency is 50MHz. Although
this does appear to be suitable for some LPDDR4 RAM chips, training at
this low frequency has been seen to cause Column errors, leading to
Capacity check errors on others.
Here we force RAM initialisation to happen at 400MHz before ramping up
to the final value running value of 800MHz after everything has been
successfully configured.
Link: https://lore.kernel.org/u-boot/Yo4v3jUeHXTovjOH@google.com/
Suggested-by: YouMin Chen <cym@rock-chips.com>
Signed-off-by: Lee Jones <lee@kernel.org>
Tested-by: Xavier Drudis Ferran <xdrudis@tinet.cat>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Tested-by: Michal Suchánek <msuchanek@suse.de>
Frequency changes to 400MHz are presently reported as:
lpddr4_set_rate_0: change freq to 400000000 mhz 0, 1
This is obviously wrong by 6 orders of magnitude.
Ensure frequency changes are reported accurately.
Signed-off-by: Lee Jones <lee@kernel.org>
Tested-by: Xavier Drudis Ferran <xdrudis@tinet.cat>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Functions pointed to by this op pointer can return non-zero values
indicating an error. Ensure any error value is propagated back up the
call-chain.
Signed-off-by: Lee Jones <lee@kernel.org>
Tested-by: Xavier Drudis Ferran <xdrudis@tinet.cat>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Only add the dram channel when we finally setup it successfully at the
last step.
Signed-off-by: Han Pengfei <pengphei@foxmail.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
This is actually a misnomer now, since the phandle info may contain
a driver_info index or a udevice index. Rename it to use the word
'phandle', which seems more accurate. Add a comment while we are here.
Also add a test for this function.
Signed-off-by: Simon Glass <sjg@chromium.org>
Convert some of these occurences to C code, where it is easy to do. This
should help encourage this approach to be used in new code.
Signed-off-by: Simon Glass <sjg@chromium.org>
Now that we have a 'positive' Kconfig option, use this instead of the
negative one, which is harder to understand.
Signed-off-by: Simon Glass <sjg@chromium.org>
This name is far too long. Rename it to remove the 'data' bits. This makes
it consistent with the platdata->plat rename.
Signed-off-by: Simon Glass <sjg@chromium.org>
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>
Right now all these debug statements are printing on the
console to make sure proper dram initialization happens.
Mark them into RAM_ROCKCHIP_DEBUG would be more meaningful
and work like before since the RAM_ROCKCHIP_DEBUG is by
default yet.
No functionality changes.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
stride debug is already present in sdram_common.c via
RAM_ROCKCHIP_DEBUG.
So, drop the redundant debug stride code in rk3399 driver.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
In the current implementation, when dtoc parses a dtb to generate a struct
platdata it converts the information related to linked nodes as pointers
to struct platdata of destination nodes. By doing this, it makes
difficult to get pointer to udevices created based on these
information.
This patch extends dtoc to use struct driver_info when populating
information about linked nodes, which makes it easier to later get
the devices created. In this context, reimplement functions like
clk_get_by_index_platdata() which made use of the previous approach.
Signed-off-by: Walter Lozano <walter.lozano@collabora.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Few of the rockchip family SoC atleast rk3288,
rk3399 are sharing some cru register bits so
adding common code between these SoC families
would require to include both cru include files
that indeed resulting function declarations error.
So, create a common cru include as cru.h then
include the rk3399 arch cru include file and move
the common cru register bit definitions into it.
The rest of rockchip cru files will add it in future.
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
In the RK3399 DRAM driver, the function set_ds_odt() supports operating
in two different modes, selected by the ctl_phy_reg argument: when true,
the function reads and writes directly from the DRAM registers, accessed
through "chan->pctl->denali_*"; when false, the function reads and
writes from an array, accessed through "params->pctl_regs.denali_*",
which is written to DRAM registers at a later time.
However, phy_config_io(), which is called by set_ds_odt() to do a subset
of its register operations, operates directly on DRAM registers at all
times. This means that it reads incorrect values (and writes new values
prematurely) when ctl_phy_reg in set_ds_odt() is false. Fix this by
passing in the address of the registers to work with.
This prevents an "Invalid DRV value" error in the SPL debug log and
(presumably) results in a more correct end state. See the following logs
from a RK3399 NanoPi M4 board (4GB LPDDR3):
Before:
sdram_init() Starting SDRAM initialization...
phy_io_config() Invalid DRV value.
phy_io_config() Invalid DRV value.
sdram_init() sdram_init: data trained for rank 2, ch 0
phy_io_config() Invalid DRV value.
phy_io_config() Invalid DRV value.
sdram_init() sdram_init: data trained for rank 2, ch 1
Channel 0: LPDDR3, 933MHz
BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB
Channel 1: LPDDR3, 933MHz
BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB
256B stride
256B stride
sdram_init() Finish SDRAM initialization...
After:
sdram_init() Starting SDRAM initialization...
sdram_init() sdram_init: data trained for rank 2, ch 0
sdram_init() sdram_init: data trained for rank 2, ch 1
Channel 0: LPDDR3, 933MHz
BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB
Channel 1: LPDDR3, 933MHz
BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB
256B stride
256B stride
sdram_init() Finish SDRAM initialization...
Signed-off-by: Thomas Hebb <tommyhebb@gmail.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
There are some code different with rockchip vendor code which may lead
to different bugs, including:
1) Fix setting error about LPDDR3 dram size ODT.
2) Set phy io speed to 0x2.
3) Fix setting error about phy_pad_fdbk_drive.
4) Fix setting error about PI_WDQLVL_VREF_EN
Signed-off-by: YouMin Chen <cym@rock-chips.com>
Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Update the calculation of the stride to support all the DRAM case.
Signed-off-by: YouMin Chen <cym@rock-chips.com>
Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
The io setting are updated after some bugfix in different rk3399 boards,
sync the code from vendor.
Signed-off-by: YouMin Chen <cym@rock-chips.com>
Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Add capacity detect for rk3399 so that the driver able to detect the
capacity automatically.
Signed-off-by: YouMin Chen <cym@rock-chips.com>
Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Clean up the sdram_init to keep sync with rockchip source code.
Signed-off-by: YouMin Chen <cym@rock-chips.com>
Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Clean up rk3399 dram driver source code for more readable.
Signed-off-by: YouMin Chen <cym@rock-chips.com>
Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
For there are some structures and functions are common for all rockchip SoCs,
migrate to use the common code so that we can clean up reduandent codes.
Signed-off-by: YouMin Chen <cym@rock-chips.com>
Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
rename sdram_common.c in arch/arm/mach-rockchip to sdram.c;
so that we can use the file name sdram_common.c in dram driver for
better understand the code;
clean the related file who has use the header file at the same time.
Signed-off-by: YouMin Chen <cym@rock-chips.com>
Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
We need to store all the ram related cap/map info back to register
for each channel after all the init has been done in case some of register
was reset during the process.
Signed-off-by: YouMin Chen <cym@rock-chips.com>
Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Unlike rest of dram type chips, LPDDR4 initialization start
with at board selected frequency (say 50MHz) and then it
switches into 400MHz and 800MHz simultaneously to make the
proper sequence work on each channel with associated training.
The lpddr4 set rate sequnce will follow by setting lpddr4
- dq out
- ca odt
- MR3
- MR12
- MR14
registers sets in sequential order.
Here is sameple log about LPDDR4-100 init sequence in Rockpro64:
Channel 0: LPDDR4, 50MHz
BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB
Channel 1: LPDDR4, 50MHz
BW=32 Col=10 Bk=8 CS0 Row=15 CS1 Row=15 CS=2 Die BW=16 Size=2048MB
256B stride
channel 0 training pass
channel 1 training pass
change freq to 400 MHz 0, 1
channel 0 training pass
channel 1 training pass
change freq to 800 MHz 1, 0
This patch add support to this init sequence via lpddr4 set rate
by taking sdram timing parameters from 400, 800 .inc files.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Signed-off-by: YouMin Chen <cym@rock-chips.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
(Fix travis error, use one ret instead of ret[2] in set_ctrl)
Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
DDR set rate can be even required for lpddr4 and we
need to keep the lpddr4 code to compile only for relevant
boards which do support lpddr4.
For this requirement, and for code readability handle
data training via sdram_rk3399_ops with .set_rate and
same will update in future while supporting lpddr4 code.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Kever Yang <Kever.yang@rock-chips.com>
Like data training in other sdram types, mr detection need
to taken care for lpddr4 with looped rank and associated
channel to make sure the proper configuration held.
Once the mr detection successful for active and configured
rank with channel number, the same can later reused during
actual LPDDR4 initialization.
So, add code to support for it.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Signed-off-by: YouMin Chen <cym@rock-chips.com>
Reviewed-by: Kever Yang <Kever.yang@rock-chips.com>
data training can be even required for lpddr4 and we
need to keep the lpddr4 code to compile only for relevant
boards which do support lpddr4.
For this requirement, and for code readability handle
data training via sdram_rk3399_ops and same will update
in future while supporting lpddr4 code.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Kever Yang <Kever.yang@rock-chips.com>
data training is using chan_info as first argument with
channel number as second argument instead of that use
dram_info as first argument so-that we can get the
chan_info at data training definition.
This was the argument handling is meaningful, readable
and it would help to add similar data training for
lpddr4 in future.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Kever Yang <Kever.yang@rock-chips.com>
