uboot-phytec

ram: rk3399: don't assume phy_io_config() uses real regs

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>