This driver is used for MDIO muxes driven over I2C.  This is currently
used on Freescale LS1028A QDS board, on which the physical MDIO MUX is
controlled by an on-board FPGA which in turn is configured through I2C.
Signed-off-by: NAlex Marginean <alexm.osslist@gmail.com>
Acked-by: NJoe Hershberger <joe.hershberger@ni.com>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>

Using 'phy_connect' instead of 'phy_find_by_mask' and 'phy_connect_dev'
both deduplicates code and adds support for 'fixed-link'.
Signed-off-by: NSimon Goldschmidt <simon.k.r.goldschmidt@gmail.com>
Acked-by: NJoe Hershberger <joe.hershberger@ni.com>

SGMII 2500 as supported on NXP SoCs requires AN to be disabled, handle
this case in the enetc sgmii init code.
Signed-off-by: NAlex Marginean <alexm.osslist@gmail.com>
Acked-by: NJoe Hershberger <joe.hershberger@ni.com>

Ethernet interfaces using serial protocols go through the serdes block
integrated in the SoC.  This is accessed over dedicated internal MDIOs
which are part of the Ethernet PCI functions.  Set up serdes at _start,
along with other protocol specific port/MAC configuration.
MDIO code is shared with enetc_mdio, read/write functions are exported
from fsl_enetc_mdio for this reason.
Signed-off-by: NAlex Marginean <alexm.osslist@gmail.com>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>
Acked-by: NJoe Hershberger <joe.hershberger@ni.com>

Adds a driver for the MDIO interface currently integrated in LS1028A SoC.
This MDIO interface is shared by multiple ethernet interfaces and is
presented as a stand-alone PCI function on the SoC ECAM.
Ethernet has a functional dependency on MDIO, for simplicity there is a
single config option for both.
Signed-off-by: NAlex Marginean <alexm.osslist@gmail.com>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>
Acked-by: NJoe Hershberger <joe.hershberger@ni.com>

Adds a driver for NXP ENETC ethernet controller currently integrated in
LS1028A.  ENETC is a fairly straight-forward BD ring device and interfaces
are presented as PCI EPs on the SoC ECAM.
Signed-off-by: NCatalin Horghidan <catalin.horghidan@nxp.com>
Signed-off-by: NAlex Marginean <alexm.osslist@gmail.com>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>
Acked-by: NJoe Hershberger <joe.hershberger@ni.com>

Add support of STM32MP1 rtc driver.
Enable it for basic and trusted configurations.
Signed-off-by: NBenjamin Gaignard <benjamin.gaignard@st.com>

Add RTCAPB and RTC clock support.
Signed-off-by: NBenjamin Gaignard <benjamin.gaignard@st.com>
Signed-off-by: NPatrick Delaunay <patrick.delaunay@st.com>

"st,stm32-qspi" is no more used, remove it.
Signed-off-by: NPatrice Chotard <patrice.chotard@st.com>

This patch introduces support of Cortex-M4 remote processor for STM32
MCU and MPU families.
Signed-off-by: NLoic Pallardy <loic.pallardy@st.com>
Signed-off-by: NFabien Dessenne <fabien.dessenne@st.com>

The current implementation supports only binary file load.
Add helpers to support ELF32 format (sanity check, and load).
Note that since an ELF32 image is built for the remote processor, the
load function uses the device_to_virt ops to translate the addresses.
Implement a basic translation for sandbox_testproc.

Add related tests. Test result:
=> ut dm remoteproc_elf
Test: dm_test_remoteproc_elf: remoteproc.c
Test: dm_test_remoteproc_elf: remoteproc.c (flat tree)
Failures: 0
Signed-off-by: NLoic Pallardy <loic.pallardy@st.com>
Signed-off-by: NFabien Dessenne <fabien.dessenne@st.com>
Reviewed-by: NLokesh Vutla <lokeshvutla@ti.com>

Add the following functions to translate DMA address to CPU address:
- dev_translate_dma_address()
- ofnode_translate_dma_address()
- of_translate_dma_address()
- fdt_translate_dma_address()
These functions work the same way as xxx_translate_address(), with the
difference that the translation relies on the "dma-ranges" property
instead of the "ranges" property.

Add related test. Test report:
=> ut dm fdt_translation
Test: dm_test_fdt_translation: test-fdt.c
Test: dm_test_fdt_translation: test-fdt.c (flat tree)
Failures: 0
Signed-off-by: NFabien Dessenne <fabien.dessenne@st.com>

This patch fix mmc driver abort caused by below patch:
3d296365 mmc: sdhci: Add support for sdhci-caps-mask

After the patch sdhci_setup_cfg() access to host->mmc->dev,
so we have to do init before make the call to the function()
Signed-off-by: NKever Yang <kever.yang@rock-chips.com>

The RK3288 HDMI driver's rk3288_hdmi_enable() currently lacks a call to
dw_hdmi_enable(). Thus, the HDMI output never gets enabled.
Signed-off-by: NNiklas Schulze <me@jns.io>
Cc: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: NKever Yang <Kever.yang@rock-chips.com>
Reviewed-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>

Use system api for udelay instead of vendor defined api,
and rockchip_udelay() will be removed.
Signed-off-by: NKever 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: NJagan Teki <jagan@amarulasolutions.com>
Signed-off-by: NYouMin Chen <cym@rock-chips.com>
Reviewed-by: NKever Yang <kever.yang@rock-chips.com>
(Fix travis error, use one ret instead of ret[2] in set_ctrl)
Signed-off-by: NKever 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: NJagan Teki <jagan@amarulasolutions.com>
Reviewed-by: NKever Yang <Kever.yang@rock-chips.com>

LPDDR4 initialization start with at board selected frequency
and then it switches into 400MHz and 800MHz simultaneously to
make the proper sequence work on each channel with associated
training.

So, add LPDDR4-800 timings inc file in driver area so-that
these timings will take during LPDDR4 initialization phase.
Signed-off-by: NJagan Teki <jagan@amarulasolutions.com>
Signed-off-by: NYouMin Chen <cym@rock-chips.com>
Reviewed-by: NKever Yang <Kever.yang@rock-chips.com>

LPDDR4 initialization start with at board selected frequency
and then it switches into 400MHz and 800MHz simultaneously to
make the proper sequence work on each channel with associated
training.

So, add LPDDR4-400 timings inc file in driver area so-that
these timings will take during LPDDR4 initialization phase.
Signed-off-by: NJagan Teki <jagan@amarulasolutions.com>
Signed-off-by: NYouMin Chen <cym@rock-chips.com>
Reviewed-by: NKever Yang <Kever.yang@rock-chips.com>

Add support for setting 400MHz ddr clock.
Signed-off-by: NJagan Teki <jagan@amarulasolutions.com>
Signed-off-by: NYouMin Chen <cym@rock-chips.com>
Reviewed-by: NKever Yang <Kever.yang@rock-chips.com>

Add support for setting 50MHz ddr clock.
Signed-off-by: NJagan Teki <jagan@amarulasolutions.com>
Signed-off-by: NYouMin Chen <cym@rock-chips.com>
Reviewed-by: NKever 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: NJagan Teki <jagan@amarulasolutions.com>
Signed-off-by: NYouMin Chen <cym@rock-chips.com>
Reviewed-by: NKever 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: NJagan Teki <jagan@amarulasolutions.com>
Reviewed-by: NKever 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: NJagan Teki <jagan@amarulasolutions.com>
Reviewed-by: NKever Yang <Kever.yang@rock-chips.com>

Update vref_mode_ac for lpddr4 based on VDDQ/3/2=16.8%
Signed-off-by: NJagan Teki <jagan@amarulasolutions.com>
Signed-off-by: NYouMin Chen <cym@rock-chips.com>
Reviewed-by: NKever Yang <Kever.yang@rock-chips.com>

The mode_sel on lpddr4 value is depending on IO settings
of rd_vref.

Add support for it.
Signed-off-by: NJagan Teki <jagan@amarulasolutions.com>
Signed-off-by: NYouMin Chen <cym@rock-chips.com>

The vref_mode_dq, vref_value_dq on lpddr4 value is depending
on IO settings of rd_vref.

Add support for it.
Signed-off-by: NJagan Teki <jagan@amarulasolutions.com>
Signed-off-by: NYouMin Chen <cym@rock-chips.com>
Reviewed-by: NKever Yang <Kever.yang@rock-chips.com>

For base.odt 1 the lpddr4 tsel_rd_en value is depending
on IO settings of rd_odt_en.

Add support for it.
Signed-off-by: NJagan Teki <jagan@amarulasolutions.com>
Signed-off-by: NYouMin Chen <cym@rock-chips.com>
Reviewed-by: NKever Yang <Kever.yang@rock-chips.com>

CTL 145, 146, 159, 160 registers are used to configure
soc odt on rk3399.

These soc odt values are updated from CS0_MR22_VAL and
CS1_MR22_VAL and for lpddr4 these values ORed with
tsel_rd_select_n.
Signed-off-by: NJagan Teki <jagan@amarulasolutions.com>
Signed-off-by: NYouMin Chen <cym@rock-chips.com>

tsel contrl clock drives are required to configure PHY
929, 939 controls drive settings.

Add support for these control clock for all dramtype
sdrams.

Thse control clock drives are configure via tsel_ckcs_select_p
and tsel_ckcs_select_n variables.

tsel_ckcs_select_n is PHY_DRV_ODT_34_3 value where as
tsel_ckcs_select_p is retrived from IO settings for lpddr4
and rest uses PHY_DRV_ODT_34_3.
Signed-off-by: NJagan Teki <jagan@amarulasolutions.com>
Signed-off-by: NYouMin Chen <cym@rock-chips.com>
Reviewed-by: NKever Yang <Kever.yang@rock-chips.com>

Now we have IO settings available for all supported sdram
frequencies, so retrieve these IO settings and make used
for LPDDR4 ds odt configuration.
Signed-off-by: NJagan Teki <jagan@amarulasolutions.com>
Signed-off-by: NYouMin Chen <cym@rock-chips.com>

Add IO settings for dram ctl and phy.

IO settings are useful for configuring ctl, phy odt, vref,
mr5, mode select and other needed input output operations
for lpddr4 or any other dramtype sdram.

Right now, this patch added IO setting for all supported
sdram frequencies.
Signed-off-by: NJagan Teki <jagan@amarulasolutions.com>
Signed-off-by: NYouMin Chen <cym@rock-chips.com>
Reviewed-by: NKever Yang <Kever.yang@rock-chips.com>

The hardware for LPDDR4 with
- CLK0P/N connect to lower 16-bits
- CLK1P/N connect to higher 16-bits

and usually dfi dram clk is configured via CLK1P/N, so
disabling dfi dram clk will disable the CLK1P/N as well.

So, add patch to not to disable dfi dram clk for lpddr4,
with rank 1.
Signed-off-by: NJagan Teki <jagan@amarulasolutions.com>
Signed-off-by: NYouMin Chen <cym@rock-chips.com>
Reviewed-by: NKever Yang <Kever.yang@rock-chips.com>

tsel write ca_p and ca_n values need to write on PHY 544, 672
and 800 to configure ds odt.

Configure the same PHY register for lpddr4 would require a mask
value of (300 << 8).

Add support for it.
Signed-off-by: NJagan Teki <jagan@amarulasolutions.com>
Signed-off-by: NYouMin Chen <cym@rock-chips.com>
Reviewed-by: NKever Yang <Kever.yang@rock-chips.com>

Assign desired cs_map values for lpddr4 during set memory map.

Initial cs_map values is based on the sdram parameters, so
the same will adjusted based dramtype as LPDDR4.
Signed-off-by: NJagan Teki <jagan@amarulasolutions.com>
Signed-off-by: NYouMin Chen <cym@rock-chips.com>

Configure PHY RX_CM_INPUT for lpddr4 during phy IO config.
Signed-off-by: NJagan Teki <jagan@amarulasolutions.com>
Signed-off-by: NYouMin Chen <cym@rock-chips.com>
Reviewed-by: NKever Yang <Kever.yang@rock-chips.com>

Configure SLEWP_EN, SLEWN_EN for lpddr4 during phy IO config.
Signed-off-by: NJagan Teki <jagan@amarulasolutions.com>
Signed-off-by: NYouMin Chen <cym@rock-chips.com>

Configure BOOSTP_EN, BOOSTN_EN for lpddr4 during phy IO config.
Signed-off-by: NJagan Teki <jagan@amarulasolutions.com>
Signed-off-by: NYouMin Chen <cym@rock-chips.com>
Reviewed-by: NKever Yang <Kever.yang@rock-chips.com>

PHY_898, PHY_919 would require to configure PHY LP4 boot
pll control and ca for lpddr4.

So, configure the same in pctl_cfg for LPDDR4.
Signed-off-by: NJagan Teki <jagan@amarulasolutions.com>
Signed-off-by: NYouMin Chen <cym@rock-chips.com>
Reviewed-by: NKever Yang <Kever.yang@rock-chips.com>

It is possible in lpddr4 dram, where both the channels would
start at same time with ZQ Cal Start. If it uses ZQ Call start
then it will use RZQ.

For example LPDDR4 366 Dual-Die, Quad-Channel Package, RZQ maybe
connect to both channel. If ZQ Cal Start at the same time,
it will use the same RZQ.

It is not a problem of using RZQ in both the channels, but can not
use at the same time.

So, to avoid this, we have an option of dram tINIT3 value for
increasing the frequency for channel 1.

This patch increase the available tINIT3 with existing running
dram frequency.
Signed-off-by: NJagan Teki <jagan@amarulasolutions.com>
Signed-off-by: NYouMin Chen <cym@rock-chips.com>
Reviewed-by: NKever Yang <Kever.yang@rock-chips.com>