| Age | Commit message (Collapse) | Author |
|
Add support for Rockchip RK3328 VOP.
Require VOP cleanup before handoff to Linux by writing reset values to
WIN registers. Without this Linux VOP trigger page fault as below
[ 0.752016] Loading compiled-in X.509 certificates
[ 0.787796] inno_hdmi_phy_rk3328_clk_recalc_rate: parent 24000000
[ 0.788391] inno-hdmi-phy ff430000.phy: inno_hdmi_phy_rk3328_clk_recalc_rate rate 148500000 vco 148500000
[ 0.798353] rockchip-drm display-subsystem: bound ff370000.vop (ops vop_component_ops)
[ 0.799403] dwhdmi-rockchip ff3c0000.hdmi: supply avdd-0v9 not found, using dummy regulator
[ 0.800288] rk_iommu ff373f00.iommu: Enable stall request timed out, status: 0x00004b
[ 0.801131] dwhdmi-rockchip ff3c0000.hdmi: supply avdd-1v8 not found, using dummy regulator
[ 0.802056] rk_iommu ff373f00.iommu: Disable paging request timed out, status: 0x00004b
[ 0.803233] dwhdmi-rockchip ff3c0000.hdmi: Detected HDMI TX controller v2.11a with HDCP (inno_dw_hdmi_phy2)
[ 0.805355] dwhdmi-rockchip ff3c0000.hdmi: registered DesignWare HDMI I2C bus driver
[ 0.808769] rockchip-drm display-subsystem: bound ff3c0000.hdmi (ops dw_hdmi_rockchip_ops)
[ 0.810869] [drm] Initialized rockchip 1.0.0 20140818 for display-subsystem on minor 0
Signed-off-by: Jagan Teki <[email protected]>
|
|
Add Rockchip RK3328 HDMI Out driver.
Signed-off-by: Jagan Teki <[email protected]>
|
|
Add support for DSI Host controller on Rockchip RK3568. This driver
is heavily based on the Rockchip dw_mipi_dsi_rockchip.c driver in
Linux and the stm32_dsi.c driver in U-Boot. It should be easy to add
support for other SoCs as the only missing component from the mainline
driver is setting the VOP big or VOP little (which the rk3568 does
not have).
Driver was tested for use in sending commands to a DSI panel in order
to obtain the panel ID.
Signed-off-by: Chris Morgan <[email protected]>
Reviewed-by: Kever Yang <[email protected]>
|
|
When U-Boot started using SPDX tags we were among the early adopters and
there weren't a lot of other examples to borrow from. So we picked the
area of the file that usually had a full license text and replaced it
with an appropriate SPDX-License-Identifier: entry. Since then, the
Linux Kernel has adopted SPDX tags and they place it as the very first
line in a file (except where shebangs are used, then it's second line)
and with slightly different comment styles than us.
In part due to community overlap, in part due to better tag visibility
and in part for other minor reasons, switch over to that style.
This commit changes all instances where we have a single declared
license in the tag as both the before and after are identical in tag
contents. There's also a few places where I found we did not have a tag
and have introduced one.
Signed-off-by: Tom Rini <[email protected]>
|
|
Signed-off-by: Eric Gao <[email protected]>
Acked-by: Philipp Tomsich <[email protected]>
Reviewed-by: Philipp Tomsich <[email protected]>
|
|
Add Makefile item for soc specific driver for rk3399 mipi dsi.
Signed-off-by: Eric Gao <[email protected]>
Acked-by: Philipp Tomsich <[email protected]>
Reviewed-by: Philipp Tomsich <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
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 <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Add basic driver for mipi display on rockchip soc platform.
Signed-off-by: Eric Gao <[email protected]>
Acked-by: Simon Glass <[email protected]>
|
|
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 <[email protected]>
Acked-by: Simon Glass <[email protected]>
|
|
Designware HDMI controller and phy are used in other SoCs as well. Split
out platform independent code.
DW HDMI has 8 bit registers but they can be represented as 32 bit
registers as well. Add support to select access mode.
EDID reading code use reading by blocks which is not supported by other
SoCs in general. Make it more general using byte by byte approach, which
is also used in Linux driver.
Finally, not all DW HDMI controllers are accompanied with DW HDMI phy.
Support custom phys by making controller code independent from phy code.
Signed-off-by: Jernej Skrabec <[email protected]>
Tested-by: Nickey Yang <[email protected]>
Reviewed-by: Simon Glass <[email protected]>
|
|
Some Rockchip SoCs support LVDS output. Add a display driver for this so
that these displays can be used on supported boards.
Signed-off-by: Jacob Chen <[email protected]>
Acked-by: Simon Glass <[email protected]>
|
|
Some rockchip SoCs include video output (VOP). Add a driver to support this.
It can output via a display driver (UCLASS_DISPLAY) and currently HDMI and
eDP are supported.
Signed-off-by: Simon Glass <[email protected]>
|
|
Some Rockchip SoCs support embedded DisplayPort output. Add a display driver
for this so that these displays can be used on supported boards.
Signed-off-by: Simon Glass <[email protected]>
|
|
Some Rockchip SoCs support HDMI output. Add a display driver for this so
that these displays can be used on supported boards.
Unfortunately this driver is not fully functional. It cannot reliably read
EDID information over HDMI. This seems to be due to the clocks being
incorrect - the I2C bus speed appears to be up to 100x slower than the
clock settings indicate. The root cause may be in the clock logic.
Signed-off-by: Simon Glass <[email protected]>
|