Really just the subset that is needed by efi_console.  Perhaps more will
be added later, for example color support would be useful to implement
efi_cout_set_attribute().

Signed-off-by: Rob Clark <robdclark@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

Content can come to screen via putc() and we cannot always rely on
updates ending with a puts().  This is the case with efi_console output
to vidconsole.  Fixes corruption with Shell.efi.

Signed-off-by: Rob Clark <robdclark@gmail.com>

The use-case is that the thing that loaded u-boot already put a splash
image on screen.  And we want to preserve that until grub boot menu
takes over.

Signed-off-by: Rob Clark <robdclark@gmail.com>

Not really qcom specific, but for now qcom/lk is the one firmware that
is (afaiu) setting up the appropriate dt node for pre-configured
display.  Uses the generic simple-framebuffer DT bindings so this should
be useful on other platforms.

Signed-off-by: Rob Clark <robdclark@gmail.com>

The STM32 LTDC display controller provides a parallel digital RGB and
signals for horizontal, vertical synchronization, Pixel Clock and Data
Enable as output to interface directly to a variety of LCD and TFT panels.

The LTDC main features are:
- 24-bit RGB Parallel Pixel Output, Programmable timings & polarity for
  HSync, VSync and Data Enable.
- 2 layers with Blending, Color Keying, Window position & size,
  Dithering, Background color, Color Look-Up Table (CLUT).
- Supported layer color formats: ARGB8888, RGB888, RGB565, ARGB1555,
  ARGB4444, L8 CLUT, AL44 & AL88

This LTDC driver:
- supports: RGB parallel output with timings & polarity, 1 layer
  in RGB565.
- supports but with hard-coded configurations: blending, window
  position & size (crop), background color.
- does not support yet: rgb888, argb8888, 8-bit clut, dithering.

This LTDC driver is compatible with all stm32 platforms with the
LTDC IP and has been tested on stm32 f746-disco board.

Signed-off-by: Philippe CORNU <philippe.cornu@st.com>

Add a driver for GPIO backlights.
It understands the standard device tree binding.
It can be used with simple-panel when PWM is not necessary.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

Add a config to select individually the driver for PWM backlights.
Manage "depends on" to be backyard compatible.

Signed-off-by: Patrick Delaunay <patrick.delaunay@st.com>

MX6Q/QP IPU operates at 264MHz and MX6DL IPU at 198MHz.

When running a SPL target, which supports multiple MX6 variants we cannot
properly setup the IPU clock frequency via CONFIG_IPUV3_CLK option as
such decision is done in build-time currently.

Remove the CONFIG_IPUV3_CLK option and let the IPU clock frequency be
configured in run-time on mx6.

Reported-by: Eric Nelson <eric@nelint.com>
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Reviewed-by: Eric Nelson <eric@nelint.com>
Reviewed-by: Stefano Babic <sbabic@denx.de>
[agust: fixed #endif in cgtqmx6eval.h]
Signed-off-by: Anatolij Gustschin <agust@denx.de>

Boards can skip display interface init using board_video_skip().
If display interface was not initialized (e.g. no ipuv3 framebuffer
registered or IPU clock disabled), booting Linux stops due to the
crash in IPU shutdown function, when accessing IPU registers.
Check IPU clock and skip shutdown if clock is not enabled.

Signed-off-by: Anatolij Gustschin <agust@denx.de>

This reverts commit 1d201704, reversing
changes made to 6aee2ab6.

The mxc_ipuv3_fb.c changes introduce build failures on some targets.

Signed-off-by: Tom Rini <trini@konsulko.com>

Boards can skip display interface init using board_video_skip().
If display interface was not initialized (e.g. no ipuv3 framebuffer
registered or IPU clock disabled), booting Linux stops due to the
crash in IPU shutdown function, when accessing IPU registers.
Check IPU clock and skip shutdown if clock is not enabled.

Signed-off-by: Anatolij Gustschin <agust@denx.de>

We are now using an env_ prefix for environment functions. Rename these
two functions for consistency. Also add function comments in common.h.

Quite a few places use getenv() in a condition context, provoking a
warning from checkpatch. These are fixed up in this patch also.

Suggested-by: Wolfgang Denk <wd@denx.de>
Signed-off-by: Simon Glass <sjg@chromium.org>

Signed-off-by: Eric Gao <eric.gao@rock-chips.com>
Acked-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>

Add rk3288 soc specific driver for mipi dsi.

Signed-off-by: Eric Gao <eric.gao@rock-chips.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Acked-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>

Add Makefile item for soc specific driver for rk3399 mipi dsi.

Signed-off-by: Eric Gao <eric.gao@rock-chips.com>
Acked-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>

To compatible with different rockchip soc, we split the mipi dirver into
common and soc specific parts, and all the soc share the common
functions from common driver part.

Signed-off-by: Eric Gao <eric.gao@rock-chips.com>
Acked-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
[agust: fix build breakage and warnings]
Signed-off-by: Anatolij Gustschin <agust@denx.de>

This is not used in U-Boot.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>

This is not used in U-Boot.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>

This is not used in U-Boot.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>

This is not used in U-Boot.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>

Update these drives to support a live device tree.

Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Anatolij Gustschin <agust@denx.de>
Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Tested-on: Beaver, Jetson-TK1
Tested-by: Stephen Warren <swarren@nvidia.com>

Change is consistent with other SOCs and it is in preparation
for adding SOMs. SOC's related files are moved from cpu/ to
mach-imx/<SOC>.

This change is also coherent with the structure in kernel.

Signed-off-by: Stefano Babic <sbabic@denx.de>

CC: Fabio Estevam <fabio.estevam@nxp.com>
CC: Akshay Bhat <akshaybhat@timesys.com>
CC: Ken Lin <Ken.Lin@advantech.com.tw>
CC: Marek Vasut <marek.vasut@gmail.com>
CC: Heiko Schocher <hs@denx.de>
CC: "Sébastien Szymanski" <sebastien.szymanski@armadeus.com>
CC: Christian Gmeiner <christian.gmeiner@gmail.com>
CC: Stefan Roese <sr@denx.de>
CC: Patrick Bruenn <p.bruenn@beckhoff.com>
CC: Troy Kisky <troy.kisky@boundarydevices.com>
CC: Nikita Kiryanov <nikita@compulab.co.il>
CC: Otavio Salvador <otavio@ossystems.com.br>
CC: "Eric Bénard" <eric@eukrea.com>
CC: Jagan Teki <jagan@amarulasolutions.com>
CC: Ye Li <ye.li@nxp.com>
CC: Peng Fan <peng.fan@nxp.com>
CC: Adrian Alonso <adrian.alonso@nxp.com>
CC: Alison Wang <b18965@freescale.com>
CC: Tim Harvey <tharvey@gateworks.com>
CC: Martin Donnelly <martin.donnelly@ge.com>
CC: Marcin Niestroj <m.niestroj@grinn-global.com>
CC: Lukasz Majewski <lukma@denx.de>
CC: Adam Ford <aford173@gmail.com>
CC: "Albert ARIBAUD (3ADEV)" <albert.aribaud@3adev.fr>
CC: Boris Brezillon <boris.brezillon@free-electrons.com>
CC: Soeren Moch <smoch@web.de>
CC: Richard Hu <richard.hu@technexion.com>
CC: Wig Cheng <wig.cheng@technexion.com>
CC: Vanessa Maegima <vanessa.maegima@nxp.com>
CC: Max Krummenacher <max.krummenacher@toradex.com>
CC: Stefan Agner <stefan.agner@toradex.com>
CC: Markus Niebel <Markus.Niebel@tq-group.com>
CC: Breno Lima <breno.lima@nxp.com>
CC: Francesco Montefoschi <francesco.montefoschi@udoo.org>
CC: Jaehoon Chung <jh80.chung@samsung.com>
CC: Scott Wood <oss@buserror.net>
CC: Joe Hershberger <joe.hershberger@ni.com>
CC: Anatolij Gustschin <agust@denx.de>
CC: Simon Glass <sjg@chromium.org>
CC: "Andrew F. Davis" <afd@ti.com>
CC: "Łukasz Majewski" <l.majewski@samsung.com>
CC: Patrice Chotard <patrice.chotard@st.com>
CC: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
CC: Hans de Goede <hdegoede@redhat.com>
CC: Masahiro Yamada <yamada.masahiro@socionext.com>
CC: Stephen Warren <swarren@nvidia.com>
CC: Andre Przywara <andre.przywara@arm.com>
CC: "Álvaro Fernández Rojas" <noltari@gmail.com>
CC: York Sun <york.sun@nxp.com>
CC: Xiaoliang Yang <xiaoliang.yang@nxp.com>
CC: Chen-Yu Tsai <wens@csie.org>
CC: George McCollister <george.mccollister@gmail.com>
CC: Sven Ebenfeld <sven.ebenfeld@gmail.com>
CC: Filip Brozovic <fbrozovic@gmail.com>
CC: Petr Kulhavy <brain@jikos.cz>
CC: Eric Nelson <eric@nelint.com>
CC: Bai Ping <ping.bai@nxp.com>
CC: Anson Huang <Anson.Huang@nxp.com>
CC: Sanchayan Maity <maitysanchayan@gmail.com>
CC: Lokesh Vutla <lokeshvutla@ti.com>
CC: Patrick Delaunay <patrick.delaunay@st.com>
CC: Gary Bisson <gary.bisson@boundarydevices.com>
CC: Alexander Graf <agraf@suse.de>
CC: u-boot@lists.denx.de
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>

Add some debugging to show when the backlight is enabled.

Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Anatolij Gustschin <agust@denx.de>
Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Tested-on: Beaver, Jetson-TK1

Update this driver to support a live device tree.

Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Anatolij Gustschin <agust@denx.de>
Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Tested-on: Beaver, Jetson-TK1

We should sync the display (e.g. flush cache) when backspace is pressed
to ensure that the character is erased correctly.

Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Anatolij Gustschin <agust@denx.de>
Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Tested-on: Beaver, Jetson-TK1

Calculate the time taken to set up the LCD.

Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Tested-on: Beaver, Jetson-TK1

Modify format type for debug message.

Signed-off-by: Eric Gao <eric.gao@rock-chips.com>

Some address relevant varibable is defined originally as u64. To
compatible with arm32, this patch change them to uintptr_t type.

Signed-off-by: Eric Gao <eric.gao@rock-chips.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

AVR32 is gone. It's already more than two years for no support in Buildroot,
even longer there is no support in GCC (last version is heavily patched 4.2.4).

Linux kernel v4.12 got rid of it (and v4.11 didn't build successfully).

There is no good point to keep this support in U-Boot either.

Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Heiko Schocher <hs@denx.de>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

There was for long time no activity in the 8xx area.
We need to go further and convert to Kconfig, but it
turned out, nobody is interested anymore in 8xx,
so remove it (with a heavy heart, knowing that I remove
here the root of U-Boot).

Signed-off-by: Heiko Schocher <hs@denx.de>

On reset the standby bit is clear, but if U-Boot is chain-loaded from
another boot loader it may be set. Clear it before starting up video so
that it works correctly.

Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Anatolij Gustschin <agust@denx.de>
Squashed in 'rockchip: video: fix taking the VOP device out of standby':
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>

Add remove() methods for EDP and VOP so that U-Boot can shut down the
video on exit. This avoids leaving DMA running while booting Linux which
can cause problems if Linux uses the frame buffer for something else.

It also makes it clear what is needed to shut down video.

While we are here, make rkvop_enable() static.

Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Anatolij Gustschin <agust@denx.de>
Squashed in 'rockchip: video: fix taking the VOP device out of standby':
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>

If U-Boot is the secondary boot loader, or has been run from itself, the
SOR may already be powered up. Powering it up again causes a hang, so
detect this situation and skip it.

Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Anatolij Gustschin <agust@denx.de>

Documents the externally visible functions shared between the VOP
drivers for the RK3288 and RK3399.

Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

Documents the externally visible functions shared between the HDMI
drivers for the RK3288 and RK3399.

Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

Fix the warning,
 ---8<---
CACHE: Misaligned operation at range [3fdffff0, 3fdffffc]
 ---<8---

Signed-off-by: Wenyou Yang <wenyou.yang@atmel.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

Extend DE2 driver with support for TVE driver, which will be added in
next commit. TVE unit expects data to be in YUV format, so CSC support
is also added here.

Note that HDMI driver has higher priority, so TV out is not probed if
HDMI monitor is detected.

Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

In order to avoid future confusion with similary named files, rename
tve.c to tve_common.c. New name better represents the fact that this file
holds code which can be and will be shared between multiple drivers.

Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

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: Philipp 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: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>