The documentation for struct phy state that "The content of the
structure is managed solely by the PHY API and PHY drivers".
Change to use the generic_phy_valid() helper to check if phy is valid.
Fixes: b7d8d40346 ("video: rockchip: dw_mipi_dsi: Fix external phy existence check")
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
This just needs some extra clocks enabled, and different registers
configured. Copied from Linux, just like the original submitter
of this driver did for rk3568.
Tested on Pinephone Pro.
Signed-off-by: Ondrej Jirman <megi@xff.cz>
Cc: Anatolij Gustschin <agust@denx.de>
Cc: Simon Glass <sjg@chromium.org>
Cc: Philipp Tomsich <philipp.tomsich@vrull.eu>
Cc: Kever Yang <kever.yang@rock-chips.com>
Cc: Chris Morgan <macromorgan@hotmail.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Use proper register base and access method to access GRF registers.
GRF registers start at a completely different base, and need special
access method, that sets the change mask in the 16 MSBs.
Signed-off-by: Ondrej Jirman <megi@xff.cz>
If phy is not defined in DT (eg. on rk3399), generic_phy_get_by_name
will return -ENODATA. Handle that case correctly.
Signed-off-by: Ondrej Jirman <megi@xff.cz>
pllref_clk is unused after being retrieved. fin needs to be set
to dsi->ref clock's rate for the following calculation to work.
Otherwise fin is undefined, and calculation return bogus number
based on undefined variable.
Signed-off-by: Ondrej Jirman <megi@xff.cz>
&priv->phy is always true. Compiler warns about this loudly.
Use a propper check for phy device allocation. Without this fix
using this driver with SoC that doesn't use external phy (eg. RK3399)
doesn't work.
Signed-off-by: Ondrej Jirman <megi@xff.cz>
The fdt_addr_t and phys_addr_t size have been decoupled. A 32bit CPU
can expect 64-bit data from the device tree parser, so use
dev_read_addr_ptr instead of the dev_read_addr function in the
various files in the drivers directory that cast to a pointer.
As we are there also streamline the error response to -EINVAL on return.
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
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 <macromorgan@hotmail.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
In the current rk3288.dtsi file the compatible string for
the DisplayPort(DP) node ends with "edp". The string in the
binding ends with "dp" which conflicts with "cdn-dp" as a
search term. Add "rk3288-dp" as compare string to select
vop_id.
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org> # chromebook-jerry
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
The rk3288/RK3399 DT synced from Linux contains some different
compatible strings in the mipi node then origanal used in U-boot.
Allow both options to be backwards compatible and to be able
to handle recent rk3288.dtsi and rk3399.dtsi files.
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
The rk3288 DT synced from Linux contains some different
properties in the edp node then origanal used in U-boot.
Allow both options to be backwards compatible and to be able
to handle recent rk3288.dtsi files.
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
In order to ensure that the VOP registers are in correct state,
add missing support for the VOP reset lines found in the device-tree
Signed-off-by: Arnaud Patard <arnaud.patard@rtp-net.org>
Tested-by: Peter Robinson <pbrobinson@gmail.com>
In order to ensure that the eDP registers are in correct state,
add missing support for the eDP reset lines found in the device-tree.
Signed-off-by: Arnaud Patard <arnaud.patard@rtp-net.org>
Tested-by: Peter Robinson <pbrobinson@gmail.com>
The debug string printing the device name, framebuffer address and of node
is using %lu as format for the framebuffer address, which is not so nice.
Change it to %lx.
Signed-off-by: Arnaud Patard <arnaud.patard@rtp-net.org>
Tested-by: Peter Robinson <pbrobinson@gmail.com>
When booting with EFI and graphics, the memory used for framebuffer
has to be reserved, otherwise it may leads to kernel memory
overwrite.
Signed-off-by: Arnaud Patard <arnaud.patard@rtp-net.org>
Tested-by: Peter Robinson <pbrobinson@gmail.com>
According to linux commit "drm/rockchip: analogix_dp: add rk3399 eDP
support" (82872e42bb1501dd9e60ca430f4bae45a469aa64), rk3288 and rk3399
eDP IPs are nearly the same, the difference is in the grf register
(SOC_CON6 versus SOC_CON20). So, change the code to use the right
register on each IP.
The clocks don't seem to be the same, the eDP clock is not at index 1
on rk3399, so don't try changing the clock at index 1 to rate 0 on
rk3399.
Signed-off-by: Arnaud Patard <arnaud.patard@rtp-net.org>
Tested-by: Peter Robinson <pbrobinson@gmail.com>
The current code is using an hard coded enum and the of node reg value of
endpoint to find out if the endpoint is mipi/hdmi/lvds/edp/dp. The order
is different between rk3288, rk3399 vop little, rk3399 vop big.
A possible solution would be to make sure that the rk3288.dtsi and
rk3399.dtsi files have "expected" reg value or an other solution is
to find the kind of endpoint by comparing the endpoint compatible value.
This patch is implementing the more flexible second solution.
Signed-off-by: Arnaud Patard <arnaud.patard@rtp-net.org>
Tested-by: Peter Robinson <pbrobinson@gmail.com>
Move this out of the common header and include it only where needed. In
a number of cases this requires adding "struct udevice;" to avoid adding
another large header or in other cases replacing / adding missing header
files that had been pulled in, very indirectly. Finally, we have a few
cases where we did not need to include <asm/global_data.h> at all, so
remove that include.
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
At present ofnode is present in the device even if it is never used. With
of-platdata this field is not used, so can be removed. In preparation for
this, change the access to go through inline functions.
Signed-off-by: Simon Glass <sjg@chromium.org>
This name is far too long. Rename it to remove the 'data' bits. This makes
it consistent with the platdata->plat rename.
Signed-off-by: Simon Glass <sjg@chromium.org>
We use 'priv' for private data but often use 'platdata' for platform data.
We can't really use 'pdata' since that is ambiguous (it could mean private
or platform data).
Rename some of the latter variables to end with 'plat' for consistency.
Signed-off-by: Simon Glass <sjg@chromium.org>
This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.
Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.
Signed-off-by: Simon Glass <sjg@chromium.org>
Like, rk3399 the rk3288 also supports 4K resolution.
So, enable it for rk3288 with HDMI platforms.
Right now, rockchip video drivers are supporting for rk3288,
rk3399 SoC families, so mark the 4K resolution by default
if it's an HDMI video out.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Cc: Anatolij Gustschin <agust@denx.de>
Reviewed-by: Kever Yang<kever.yang@rock-chips.com>
Found this by comparing it to the coreboot driver, a form of this call
was introduced there in their commit b9a7877568cf ("rockchip/*: refactor
edp driver"). This is copy-pasted from U-Boot's link_train_cr() slightly
above it.
Without this on a gru-kevin chromebook, I have:
clock recovery at voltage 0 pre-emphasis 0
requested signal parameters: lane 0 voltage 0.4V pre_emph 3.5dB
requested signal parameters: lane 1 voltage 0.4V pre_emph 3.5dB
requested signal parameters: lane 2 voltage 0.4V pre_emph 3.5dB
requested signal parameters: lane 3 voltage 0.4V pre_emph 3.5dB
using signal parameters: voltage 0.4V pre_emph 3.5dB
requested signal parameters: lane 0 voltage 0.4V pre_emph 3.5dB
requested signal parameters: lane 1 voltage 0.4V pre_emph 3.5dB
requested signal parameters: lane 2 voltage 0.4V pre_emph 3.5dB
requested signal parameters: lane 3 voltage 0.4V pre_emph 3.5dB
using signal parameters: voltage 0.4V pre_emph 3.5dB
requested signal parameters: lane 0 voltage 0.4V pre_emph 3.5dB
requested signal parameters: lane 1 voltage 0.4V pre_emph 3.5dB
requested signal parameters: lane 2 voltage 0.4V pre_emph 3.5dB
requested signal parameters: lane 3 voltage 0.4V pre_emph 3.5dB
using signal parameters: voltage 0.4V pre_emph 3.5dB
requested signal parameters: lane 0 voltage 0.4V pre_emph 3.5dB
requested signal parameters: lane 1 voltage 0.4V pre_emph 3.5dB
requested signal parameters: lane 2 voltage 0.4V pre_emph 3.5dB
requested signal parameters: lane 3 voltage 0.4V pre_emph 3.5dB
using signal parameters: voltage 0.4V pre_emph 3.5dB
requested signal parameters: lane 0 voltage 0.4V pre_emph 3.5dB
requested signal parameters: lane 1 voltage 0.4V pre_emph 3.5dB
requested signal parameters: lane 2 voltage 0.4V pre_emph 3.5dB
requested signal parameters: lane 3 voltage 0.4V pre_emph 3.5dB
using signal parameters: voltage 0.4V pre_emph 3.5dB
channel eq failed, ret=-5
link train failed!
rk_vop_probe() Device failed: ret=-5
With this, it looks like training succeeds:
clock recovery at voltage 0 pre-emphasis 0
requested signal parameters: lane 0 voltage 0.4V pre_emph 3.5dB
requested signal parameters: lane 1 voltage 0.4V pre_emph 3.5dB
requested signal parameters: lane 2 voltage 0.4V pre_emph 3.5dB
requested signal parameters: lane 3 voltage 0.4V pre_emph 3.5dB
using signal parameters: voltage 0.4V pre_emph 3.5dB
requested signal parameters: lane 0 voltage 0.4V pre_emph 6dB
requested signal parameters: lane 1 voltage 0.4V pre_emph 6dB
requested signal parameters: lane 2 voltage 0.4V pre_emph 6dB
requested signal parameters: lane 3 voltage 0.4V pre_emph 6dB
using signal parameters: voltage 0.4V pre_emph 6dB
requested signal parameters: lane 0 voltage 0.4V pre_emph 0dB
requested signal parameters: lane 1 voltage 0.4V pre_emph 0dB
requested signal parameters: lane 2 voltage 0.4V pre_emph 0dB
requested signal parameters: lane 3 voltage 0.4V pre_emph 0dB
using signal parameters: voltage 0.4V pre_emph 0dB
channel eq at voltage 0 pre-emphasis 0
config video failed
rk_vop_probe() Device failed: ret=-110
The "config video failed" error also goes away when I disable higher
log levels, and it claims to have successfully probed the device.
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Kever Yang<kever.yang@rock-chips.com>
When using OF_PLATDATA, the bind process between devices and drivers
is performed trying to match compatible string with driver names.
However driver names are not strictly defined, and also there are different
names used when declaring a driver with U_BOOT_DRIVER, the name of the
symbol used in the linker list and the used in the struct driver_info.
In order to make things a bit more clear, rename the drivers names. This
will also help for further OF_PLATDATA improvements, such as checking
for valid driver names.
Signed-off-by: Walter Lozano <walter.lozano@collabora.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add a fix for sandbox of-platdata to avoid using an invalid ANSI colour:
Signed-off-by: Simon Glass <sjg@chromium.org>
3480 is not valid XRES, use 3840 as default.
Fixes: 05c65a82c3 ("video: rockchip: Support 4K resolution for rk3399, HDMI")
Signed-off-by: Anatolij Gustschin <agust@denx.de>
Cc: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Tested-by: Jagan Teki <jagan@amarulasolutions.com> # roc-rk3399-pc
The EDP_LCDC_SEL bit has to be set correctly to select vop0 or
vop1, but so far we have set it in both conditions, which is not
correct.
Can someone verify this is the correct way round? vop1 -> set,
vop0 -> clear?
Signed-off-by: Patrick Wildt <patrick@blueri.se>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Use ofnode_ or dev_ APIs instead of fdt_ and fdtdec_ APIs so that the
driver can support live DT.
Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Use ofnode_decode_display_timing() instead of
fdtdec_decode_display_timing() to parse display timing, so that we can
support live DT.
Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The rk_edp.c and rk_lvds.c files reference rk_setreg which is declared in
hardware.h so include it so the drivers build. Adjust rk_lvds.c so
includes are in alphabetical order while updating.
Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
Reviewed-by: Anatolij Gustschin <agust@denx.de>
Tested-by: Vagrant Cascadian <vagrant@debian.org>
The default resolution for rockchip display is 1920x1080
which failed to work on 4K HDMI out displays on rk3399.
So, mark the default resolution as 3480x2160 for rk3399
HDMI out.
This would work all the hdmi display resolutions till
4K.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Tested-by: Peter Robinson <pbrobinson@gmail.com>
VOP display endpoint pipeline configuration differs
between rk3288 vs rk3399.
These VOP pipeline configuration depends on how the
different display interfaces connected in sequence to
IN and OUT ports like for,
RK3288:
vopb_out: port {
#address-cells = <1>;
#size-cells = <0>;
vopb_out_edp: endpoint@0 {
reg = <0>;
remote-endpoint = <&edp_in_vopb>;
};
vopb_out_hdmi: endpoint@1 {
reg = <1>;
remote-endpoint = <&hdmi_in_vopb>;
};
vopb_out_lvds: endpoint@2 {
reg = <2>;
remote-endpoint = <&lvds_in_vopb>;
};
vopb_out_mipi: endpoint@3 {
reg = <3>;
remote-endpoint = <&mipi_in_vopb>;
};
};
RK3399:
vopb_out: port {
#address-cells = <1>;
#size-cells = <0>;
vopb_out_edp: endpoint@0 {
reg = <0>;
remote-endpoint = <&edp_in_vopb>;
};
vopb_out_mipi: endpoint@1 {
reg = <1>;
remote-endpoint = <&mipi_in_vopb>;
};
vopb_out_hdmi: endpoint@2 {
reg = <2>;
remote-endpoint = <&hdmi_in_vopb>;
};
vopb_out_mipi1: endpoint@3 {
reg = <3>;
remote-endpoint = <&mipi1_in_vopb>;
};
vopb_out_dp: endpoint@4 {
reg = <4>;
remote-endpoint = <&dp_in_vopb>;
};
};
here, HDMI interface has endpoint 1 in rk3288 and 2 in rk3399.
The rockchip vop driver often depends on this determined endpoint
number and stored in vop_mode. So based on this vop_mode the bpp
and pin polarity would configure on detected display interface.
Since, the existing driver using rk3288 vop mode settings enabling
the same will result wrong display interface configuration for rk3399.
Add the patch for fixing these vop modes for rk3399.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Tested-by: Peter Robinson <pbrobinson@gmail.com>
At present dm/device.h includes the linux-compatible features. This
requires including linux/compat.h which in turn includes a lot of headers.
One of these is malloc.h which we thus end up including in every file in
U-Boot. Apart from the inefficiency of this, it is problematic for sandbox
which needs to use the system malloc() in some files.
Move the compatibility features into a separate header file.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present devres.h is included in all files that include dm.h but few
make use of it. Also this pulls in linux/compat which adds several more
headers. Drop the automatic inclusion and require files to include devres
themselves. This provides a good indication of which files use devres.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Anatolij Gustschin <agust@denx.de>
Few of the rockchip family SoC atleast rk3288,
rk3399 are sharing some cru register bits so
adding common code between these SoC families
would require to include both cru include files
that indeed resulting function declarations error.
So, create a common cru include as cru.h then
include the rk3399 arch cru include file and move
the common cru register bit definitions into it.
The rest of rockchip cru files will add it in future.
Reviewed-by: Kever Yang <kever.yang@rock-chips.com>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Add support for the ddc-i2c-bus device tree property which allows
for using an external i2c master for reading the display's EDID.
Signed-off-by: Niklas Schulze <me@jns.io>
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: Niklas Schulze <me@jns.io>
Cc: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Kever Yang <Kever.yang@rock-chips.com>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Rockchip use 'arch-rockchip' instead of arch-$(SOC) as common
header file path, so that we can get the correct path directly.
Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
