The last set of rebases had dropped the 'grf' field from the common
rk_vop.  Add this back to un-break the build (and driver).
Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>

This commit enables the RK3399 HDMI TX, which is very similar to the
one found on the RK3288.  As requested by Simon, this splits the HDMI
driver into a SOC-specific portion (rk3399_hdmi.c, rk3288_hdmi.c) and
a common portion (rk_hdmi.c).

Note that the I2C communication for reading the EDID works well with
the default settings, but does not with the alternate settings used on
the RK3288... this configuration aspect is reflected by the driverdata
for the RK3399 driver.

Having some sort of DTS-based configuration for the regulator
dependencies would be nice for the future, but for now we simply use
lists of regulator names (also via driverdata) that we probe.
Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

To prepare for the addition of RK3399 HDMI support, the HDMI driver is
refactored and broken into a chip-specific and a generic part.  This
change adds the internal interfaces, makes common/reusable functions
externally visible and splits the RK3288 driver into a separate file.

For the probing of regulators, we reuse the infrastructure created
during the VOP refactoring... i.e. we simply call into the helper
function defined for the VOP.
Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

The Linux driver now supports higher mpixelclock settings.
Add these to rockchip_phy_config[] and rockchip_mpll_cfg[].
Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

This commit adds a driver for the RK3399 VOPs capable and all the
necessary plumbing to feed the HDMI encoder. For the VOP-big, this
correctly tracks the ability to feed 10bit RGB data to the encoder.
Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

To prepare for adding the RK3399 VOP driver (which shares most of its
registers and config logic with the RK3228 VOP), this change refactors
the driver and splits the RK3288-specific driver off.

The changes in detail are:
- introduces a data-structure for chip-specific drivers to register
  features/callbacks with the common driver: at this time, this is
  limited to a callback for setting the pin polarities (between the
  VOP and the encoder modules) and a flag to signal 10bit RGB
  capability
- refactors the probing of regulators into a helper function that
  can take a list of regulator names to probe and autoset
- moves the priv data-structure into a (common) header file to be
  used by the chip-specific drivers to provide base addresses to
  the common driver
- uses a callback into the chip-specific driver to set pin polarities
  (replacing the direct register accesses previously used)
- splits enabling the output (towards an encoder) into a separate
  help function withint the common driver
Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

This introduces two new Kconfig options that configure the maximum
allowable framebuffer size (i.e. the memory reservation/allocation for
the framebuffer):
 - VIDEO_ROCKCHIP_MAX_XRES
 - VIDEO_ROCKCHIP_MAX_YRES
The resulting memory allocation will cover 4 byte per pixel for these
resolutions.
Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

For consistency sake (and as we are about to add new options to this
file), reformat the help for VIDEO_ROCKCHIP.
Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

When enabling CONFIG_DISPLAY_ROCKCHIP_HDMI, compile-time warning for
the following implicitly defined functions are raised due to a missing
include directive:

  drivers/video/rockchip/rk_hdmi.c: In function 'rk_hdmi_probe':
  drivers/video/rockchip/rk_hdmi.c:150:2: warning: implicit declaration of function 'rk_setreg' [-Wimplicit-function-declaration]
    rk_setreg(&priv->grf->soc_con6, 1 << 15);
    ^~~~~~~~~
  drivers/video/rockchip/rk_hdmi.c:153:2: warning: implicit declaration of function 'rk_clrsetreg' [-Wimplicit-function-declaration]
    rk_clrsetreg(&priv->grf->soc_con6, 1 << 4,
    ^~~~~~~~~~~~

This change fixes this by including <asm/hardware.h> in rk_hdmi.c.
Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>
Acked-by: NSimon Glass <sjg@chromium.org>

Add the compatible "rockchip,rk3328-xhci" in match table
for rk3328 to probe xhci controller. Use fixed regulator
to control the voltage of vbus and turn off vbus when
usb stop.
Signed-off-by: NMeng Dongyang <daniel.meng@rock-chips.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

RV1108 is embedded with an ARM Cortex-A7 single core and a DSP core
from Rockchip. It is designed for varies application scenario such
as car DVR, sports DV, secure camera and UAV camera.
Signed-off-by: NAndy Yan <andy.yan@rock-chips.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

Add clock driver support for Rockchip rv1108 soc
Signed-off-by: NAndy Yan <andy.yan@rock-chips.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

Add pinctrl support for Rockchip rv1108 soc
Signed-off-by: NAndy Yan <andy.yan@rock-chips.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

In rk3328, some function pin may have more than one choice, and muxed
with more than one IO, for example, the UART2 controller IO,
TX and RX, have 3 choice(setting in com_iomux):
- M0 which mux with GPIO1A0/GPIO1A1
- M1 which mux with GPIO2A0/GPIO2A1
- usb2phy which mux with USB2.0 DP/DM pin.

We should not decide which group to use in pinctrl driver,
for it may be different in different board, it should goes to board
file, and the pinctrl file should setting correct iomux depends on
the com_iomux value.
Signed-off-by: NKever Yang <kever.yang@rock-chips.com>
Acked-by: NSimon Glass <sjg@chromium.org>

Move GRF register bit definition into GRF header file, remove
'GRF_' prefix and add 'GPIOmXn_' as prefix for bit meaning.
Signed-off-by: NKever Yang <kever.yang@rock-chips.com>
Acked-by: NSimon Glass <sjg@chromium.org>

U-Boot prefer to use MASKs with SHIFT embeded, clean the Macro
definition in grf header file and pinctrl driver.
Signed-off-by: NKever Yang <kever.yang@rock-chips.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

- hclk/pclk_div range　should use '<=' instead of '<'
- use GPLL for pd_bus clock source
- pd_bus HCLK/PCLK clock rate should not bigger than ACLK
Signed-off-by: NKever Yang <kever.yang@rock-chips.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

Embeded the shift in mask MACRO definition in cru header file
and clock driver.
Signed-off-by: NKever Yang <kever.yang@rock-chips.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

Add sysreset driver to reset rk3368 SOC.
Signed-off-by: NAndy Yan <andy.yan@rock-chips.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

Add driver to support iomux setup for the most commonly
used peripherals on rk3368.
Signed-off-by: NAndy Yan <andy.yan@rock-chips.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

Add driver to setup the various PLLs and peripheral
clocks on the RK3368.
Signed-off-by: NAndy Yan <andy.yan@rock-chips.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

Since priv->init_voltage is an unsigned integer it can never be
negative.  So the current code fails to detect a missing
'regulator-init-microvolt' property and instead misconfigures the
PWM device.  Fix this by making the relevant members of
'struct pwm_regulator_info' signed integers.
Signed-off-by: NMark Kettenis <kettenis@openbsd.org>

Till now get_ldo_reg did a return &rk808_ldo[num - 1]; to return
the ldo register offset but didn't take into account that its
calling functions already created the ldo as ldo = dev->driver_data - 1.

This resulted in the setting for ldo8 writing to the register of ldo7
and so on. So fix this and get the correct ldo register data.
Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
Acked-by: NSimon Glass <sjg@chromium.org>

This adds a simple driver for reading the efuse block of the RK3399.
It should be easy enough to add drivers for other devices (e.g. the
RK3328, RK3368, etc.) by passing the device details via driver_data.

Unlike the kernel driver (using the nvmem subsystem), we don't expose
the efuse as multiple named cells, but rather as a linear memory that
can be read using misc_read(...).

The primary use case (as of today) is the generation of a 'serial#'
(and a 'cpuid#') environment variable for the RK3399-Q7 (Puma)
system-on-module.

Note that this adds a debug-only (i.e. only if DEBUG is defined)
command 'rk3399_dump_efuses' that dumps the efuse block's content.
N.B.: The name 'rk3399_dump_efuses' was intentionally chosen to
      include a SoC-name (together with a comment in the function) to
      remind whoever adds support for additional SoCs that this
      function currently makes assumptions regarding the size of the
      fuse-box based on the RK3399. The hope is that the function is
      adjusted to reflect any changes resulting from generalising the
      driver for multiple SoCs and is then renamed.
Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

The rk8xx_priv structure need to allocate for driver, or else
it will cause data abort when CPU access it.

This is a bug fix for below patch set:
https://www.mail-archive.com/u-boot@lists.denx.de/msg247345.htmlSigned-off-by: NKever Yang <kever.yang@rock-chips.com>
Acked-by: NSimon Glass <sjg@chromium.org>

If CONFIG_CLK flag is not set, compilation raises the
following error message:

drivers/ram/stm32_sdram.c: In function 'stm32_fmc_probe':
drivers/ram/stm32_sdram.c:154:2: error: 'ret' undeclared (first use in this function)
  ret = stm32_sdram_init(dev);
Signed-off-by: NPatrice Chotard <patrice.chotard@st.com>
cc: Vikas Manocha <vikas.manocha@st.com>

This deassert counter allow to manage "shared" reset lines
encountered in some specific case. On STiH410 SoC, DWC3,
EHCI and OHCI are all using a respective PHY, but all of
these PHYs shared a "global" reset.

Currently, during command "usb stop", all host controller are
stopped (XHCI, EHCI and OHCI). XHCI is first shutdowned, which
means that PHY global reset is asserted. Then EHCI is shutdowned,
but its PHY reset has already been asserted which make handshake()
call failed in ehci_shutdown().

This counter allows to really assert a reset lines only when the
"last" user is asserting it.
Signed-off-by: NPatrice Chotard <patrice.chotard@st.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>

We should not have an arch-specific header file in common.h. Adjust the
board files a little so it is not needed, and drop it.
Signed-off-by: NSimon Glass <sjg@chromium.org>

The declarations should not be in common.h. Move them to the arch-specific
headers.
Signed-off-by: NSimon Glass <sjg@chromium.org>
[trini: Fixup thinko defined(FSL_LSCH3) -> defined(CONFIG_FSL_LSCH3)]
Signed-off-by: NTom Rini <trini@konsulko.com>

Rather than relying on common.h to provide this include, which is going
away at some point, include it explicitly in each file.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NTom Rini <trini@konsulko.com>

This is dead code now. Drop it.
Signed-off-by: NSimon Glass <sjg@chromium.org>

This is not used anymore. Drop it.
Signed-off-by: NSimon Glass <sjg@chromium.org>

This is not used anymore. Drop it.
Signed-off-by: NSimon Glass <sjg@chromium.org>

This is no-longer used in U-Boot. Drop it.
Signed-off-by: NSimon Glass <sjg@chromium.org>
Reviewed-by: NJaehoon Chung <jh80.chung@samsung.com>

This is no longer used in U-Boot. Drop it.
Signed-off-by: NSimon Glass <sjg@chromium.org>

This should not be in common.h - remove it and update the only file that
needs it.
Signed-off-by: NSimon Glass <sjg@chromium.org>

We used to have opencoded ehci_readl()/writel() which required no
external functions to be called.

Now with attempt to switch to generic readl()/writel() accessors
we see a missing declaration of those accessors in ehci-ppc4xx.
Something like that happens if applied
http://patchwork.ozlabs.org/patch/726714/:
--------------------------------->8---------------------------
  CC      drivers/usb/host/ehci-pci.o
In file included from drivers/usb/host/ehci-pci.c:14:0:
drivers/usb/host/ehci-pci.c: In function 'ehci_pci_init':
drivers/usb/host/ehci.h:108:36: warning: implicit declaration of function 'readl' [-Wimplicit-function-declaration]
 #define ehci_readl(x)  cpu_to_le32(readl(x))
                                    ^
drivers/usb/host/ehci.h:23:26: note: in definition of macro 'HC_LENGTH'
 #define HC_LENGTH(p)  (((p) >> 0) & 0x00ff)
                          ^
include/linux/byteorder/generic.h:89:21: note: in expansion of macro '__cpu_to_le32'
 #define cpu_to_le32 __cpu_to_le32
                     ^~~~~~~~~~~~~
drivers/usb/host/ehci-pci.c:33:14: note: in expansion of macro 'ehci_readl'
    HC_LENGTH(ehci_readl(&hccr->cr_capbase)));
              ^~~~~~~~~~
--------------------------------->8---------------------------

This the same fix as we have for "ehci-ppc4xx" in
83cb46c2 "ehci-ppc4xx: Prepare for usage of readl()/writel() accessors".
Signed-off-by: NAlexey Brodkin <abrodkin@synopsys.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
Cc: Marek Vasut <marex@denx.de>
Cc: Stefan Roese <sr@denx.de>

The offset was applied to write, but not read, now its applied to
both.
Signed-off-by: NPhil Edworthy <phil.edworthy@renesas.com>

On MIPS systems DMA isn't coherent with the CPU caches unless an IOCU is
present. When there is no IOCU we need to writeback or invalidate the
data caches at appropriate points. Perform this cache maintenance in
the pch_gbe driver which is used on the MIPS Boston development board.
Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>
Tested-by: NBin Meng <bmeng.cn@gmail.com>
Signed-off-by: NDaniel Schwierzeck <daniel.schwierzeck@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>
Acked-by: NJoe Hershberger <joe.hershberger@ni.com>

Use the virt_to_bus & bus_to_virt functions rather than phys_to_bus &
bus_to_phys, since the addresses accessed by the CPU will be virtual
rather than physical. On MIPS physical & virtual addresses differ as we
use virtual addresses in kseg0, and attempting to use physical addresses
directly caused problems as they're in the user segment which would be
mapped via the uninitialised TLB.
Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
Signed-off-by: NDaniel Schwierzeck <daniel.schwierzeck@gmail.com>
Reviewed-by: NBin Meng <bmeng.cn@gmail.com>
Tested-by: NBin Meng <bmeng.cn@gmail.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>
Acked-by: NJoe Hershberger <joe.hershberger@ni.com>