wait_for_bit callers use the 32 bit LE version
Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
Reviewed-by: Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Reviewed-by: Jagan Teki <jagan@openedev.com>
flags member of struct timing was not initialized,
this took to unpredictable behaviour of display flags,
such DISPLAY_FLAGS_HSYNC_HIGH instead of _LOW etc.
Init timing->flags = 0
Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Reviewed-by: Jagan Teki <jagan@openedev.com>
The LCDC IP-core an be feed from several clock sources, one of those is
a dedicated DPLL for generating a dividable base-clock for this IP-core.
The TRM specifies the maximum input frequency for the LCCD with 200 MHz,
so we must not exceed this value with the PLL frequency (which can lock
much higher).
This patch tries every combination of multipliers and divisors of the
PLL and the IP-core itself for getting as near as possible the the
requested panel->pxl_clk.
Signed-off-by: Hannes Schmelzer <oe5hpm@oevsv.at>
Reviewed-by: Anatolij Gustschin <agust@denx.de>
The calculation of left space for version string is not correct, should
use VIDEO_COLS not VIDEO_LINE_LEN / 2, otherwise we will get larger space
than actual have and cause string to overlay logo picture.
Also current version string display only supports two lines words at max.
This also causes overlay when the LCD pixel column size is not enough.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Tested-by: Anatolij Gustschin <agust@denx.de>
The clk_set_rate function dereferences the clk pointer without
checking whether it is NULL. This may cause problem when clk is NULL.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Anatolij Gustschin <agust@denx.de>
These are actually different bits, and since some monitors (Benq BL2420PT)
have modes with different HSYNC and VSYNC polarity, we should set them
independently
Tested on Pine64-LTS with Benq BL2420PT monitor.
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Reviewed-by: Anatolij Gustschin <agust@denx.de>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Reviewed-by: Jagan Teki <jagan@openedev.com>
Add support for setting up SimpleFB for LCD display output in DE2
SimpleFB setup code.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Reviewed-by: Jagan Teki <jagan@openedev.com>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
When HDMI is not initialized (e.g. no monitor is plugged), the current
SimpleFB code will still create a broken SimpleFB node.
Detect whether HDMI is initialized when creating SimpleFB node.
Fixes: be5b96f0e4 ("sunxi: setup simplefb for Allwinner DE2")
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Reviewed-by: Jagan Teki <jagan@openedev.com>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Resort to malloc_cache_aligned() rather than malloc() which also removes
'CACHE: Misaligned operation at range' warnings.
Signed-off-by: Niko Mauno <niko.mauno@vaisala.com>
Extend DE2 driver with LCD support. Tested on Pinebook which is based
on A64 and has ANX6345 eDP bridge with eDP panel connected to it.
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
[agust: rebased v5 on u-boot-video/master]
Signed-off-by: Anatolij Gustschin <agust@denx.de>
This is a eDP bridge similar to ANX9804, it allows to connect eDP panels
to the chips that can output only parallel signal
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
[agust: fixed most checkpatch errors/warnings]
Signed-off-by: Anatolij Gustschin <agust@denx.de>
This header will be used in anx6345 driver
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
[agust: moved header to drivers/video]
Signed-off-by: Anatolij Gustschin <agust@denx.de>
Add an operation to read EDID, since bridge may have ability to read
EDID from the panel that is connected to it, for example LCD<->eDP bridge.
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
As the support of EFI boot on Allwinner H3 is broken, we still need to
use simplefb to pass the framebuffer to Linux.
Add code to setup simplefb for Allwinner DE2 driver.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Add an option to indicate that the video driver should setup a SimpleFB
node that passes the video framebuffer initialized by U-Boot to the
operating system kernel.
Currently only the Allwinner DE driver uses this option, and the
definition of this option in the sunxi-common.h config header is
converted to an imply of this option from CONFIG_VIDEO_SUNXI.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
As the DE2 simplefb setup code can also benefit from the simplefb match
code, extract it to a new source file.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
U-Boot widely uses error() as a bit noisier variant of printf().
This macro causes name conflict with the following line in
include/linux/compiler-gcc.h:
# define __compiletime_error(message) __attribute__((error(message)))
This prevents us from using __compiletime_error(), and makes it
difficult to fully sync BUILD_BUG macros with Linux. (Notice
Linux's BUILD_BUG_ON_MSG is implemented by using compiletime_assert().)
Let's convert error() into now treewide-available pr_err().
Done with the help of Coccinelle, excluing tools/ directory.
The semantic patch I used is as follows:
// <smpl>
@@@@
-error
+pr_err
(...)
// </smpl>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
[trini: Re-run Coccinelle]
Signed-off-by: Tom Rini <trini@konsulko.com>
Note that this doesn't differentiate (due to lack of information in
video_priv) between different possible component orders for 32bpp.
But the main user at this point is efi_loader, and GOP expects xBGR
so any video drivers that this is incorrect for already have problems.
(Also, conveniently, this matches what simple-framebuffer bindings
expect for kernels that use the simple-framebuffer DT binding to
take over the bootloader display.)
Signed-off-by: Rob Clark <robdclark@gmail.com>
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 1d20170467, reversing
changes made to 6aee2ab68c.
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>
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
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>
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: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Simon 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: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Simon 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: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Simon 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: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Simon 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: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Simon 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: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Simon 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: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Acked-by: Simon Glass <sjg@chromium.org>
At present devices use a simple integer offset to record the device tree
node associated with the device. In preparation for supporting a live
device tree, which uses a node pointer instead, refactor existing code to
access this field through an inline function.
Signed-off-by: Simon Glass <sjg@chromium.org>
It is good practice to include common.h as the first header. This ensures
that required features like the DECLARE_GLOBAL_DATA_PTR macro,
configuration options and common types are available.
Fix up some files which currently don't do this. This is necessary because
driver model will soon start using global data and configuration in the
dm/read.h header file, included via dm.h. The gd->fdt_blob value will be
used to access the device tree and CONFIG options will be used to
determine whether to support inline functions in the header file.
Signed-off-by: Simon Glass <sjg@chromium.org>
These support the flat device tree. We want to use the dev_read_..()
prefix for functions that support both flat tree and live tree. So rename
the existing functions to avoid confusion.
In the end we will have:
1. dev_read_addr...() - works on devices, supports flat/live tree
2. devfdt_get_addr...() - current functions, flat tree only
3. of_get_address() etc. - new functions, live tree only
All drivers will be written to use 1. That function will in turn call
either 2 or 3 depending on whether the flat or live tree is in use.
Note this involves changing some dead code - the imx_lpi2c.c file.
Signed-off-by: Simon Glass <sjg@chromium.org>
Newer SoCs use same TV encoder unit. Split it out so it can be reused
with new DM video driver.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Reviewed-by: Simon Glass <sjg@chromium.org>
Due to a typo, the 24 bit-per-pixel configuration ends in 24BMP
instead of 24BPP. This change renames it throughout the source tree
for consistency and to make moving these options into Kconfig easier
and less error-prone.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Hannes Schmelzer <hannes.schmelzer@br-automation.com>
Instead of having drivers/video/rockchip/Kconfig point outside of its
hierarchy for dw_hdmi.o, we should use a configuration-option to
include the Designware HDMI support.
This change introduces a new config option (not to be selected via
menuconfig, but to be selected from a dependent video driver's
configuration option) that enables dw_hdmi.o and selects it whenever
the HDMI support for Rockchip SoCs is selected.
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Some DVI monitors don't work in HDMI mode. Set it only if edid data
explicitly states that it is supported.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Reviewed-by: Simon Glass <sjg@chromium.org>
The variables SEQ_SWRESET, SEQ_ELVSS_ON, SEQ_TEMP_SWIRE, SEQ_APON and
SEQ_SLPIN are unreferenced, drop.
Cc: Anatolij Gustschin <agust@denx.de>
Signed-off-by: Tom Rini <trini@konsulko.com>
plat->size here is used to reserve frame buffer space befor relocation.
our mipi panel use 24 bitwidth, and vop require 32bit align. So the frame
buffer size should be at least 1920*1200*32/8.
Signed-off-by: Eric Gao <eric.gao@rock-chips.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Because the bitwidth is different for different display mode, so we need
to set them according to demand.
Signed-off-by: Eric Gao <eric.gao@rock-chips.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add mipi display mode for rk3399 vop, so that we can use mipi panel
for display.
Signed-off-by: Eric Gao <eric.gao@rock-chips.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
It's caused by the difference of clk_set_rate function implement between
rk3288 andd rk3399.
clk_set_rate() of rk3288 return 0 in normal condition.
clk_set_rate() of rk3399 return input parameter in normal condition.
So check clk_set_rate's return value by IS_ERR_VALUE.
Signed-off-by: Eric Gao <eric.gao@rock-chips.com>
Modify Makefile for rockchip video driver according to Kconfig, so that
source code will not be compiled if not needed.
Signed-off-by: Eric Gao <eric.gao@rock-chips.com>
Acked-by: Simon Glass <sjg@chromium.org>
1. add Kconfig for rockchip video driver, so that video port can be
selected as needed.
2. move VIDEO_ROCKCHIP option to new Kconfig for concision.
Signed-off-by: Eric Gao <eric.gao@rock-chips.com>
Acked-by: Simon Glass <sjg@chromium.org>
Drop indenting in Kconfig:
Signed-off-by: Simon Glass <sjg@chromium.org>
Adjust the video driver to work with driver model and move over existing
baords. There is no need to keep the old code.
We can also drop setting of CONFIG_FB_ADDR since driver model doesn't have
this problem.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Anatolij Gustschin <agust@denx.de>
Add a function to set the video parameters to the msg handler and remove
it from the video driver.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Anatolij Gustschin <agust@denx.de>
Add a function to get the video size to the msg handler and remove it from
the video driver.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: Anatolij Gustschin <agust@denx.de>
This converts the following to Kconfig:
CONFIG_SYS_WHITE_ON_BLACK
Signed-off-by: Simon Glass <sjg@chromium.org>
[trini: Make this default y on various SoCs]
Signed-off-by: Tom Rini <trini@konsulko.com>
This commit adds support for HDMI output.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Reviewed-by: Simon Glass <sjg@chromium.org>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
This is needed for HDMI, which will be added later.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Video driver for older Allwinner SoCs uses cfb console framework which
in turn uses struct ctfb_res_modes to hold timing informations. However,
DM video framework uses different structure - struct display_timing.
It makes more sense to convert lcdc to use new timing structure because
all new drivers should use DM video framework and older drivers might be
rewritten to use new framework too.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
TCON unit has similar layout and functionality also on newer SoCs. This
commit splits out TCON code for easier reuse later.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>