The Rockchip DSI driver was separate till now, not using the common
bridge driver that was introduced a bit later. So this series migrates
over to use that common bridge driver and then also adds support for
dual-dsi to both the bridge and Rockchip glue code.
The bridge-migration itself is v8 based on Nickeys earlier
work, but adapted to current kernels and with a new split between probe
and bind, so that we do not create and drop the dsi-host on each deferred
bind attempt.
The dual-dsi setup follows the port description introduced by Archit [0],
in that the panel defines two input ports that get connected to both
dsi-controllers instances. So on Gru-Scarlett this looks for example
like:
&mipi_dsi {
status = "okay";
clock-master;
ports {
mipi_out: port@1 {
reg = <1>;
mipi_out_panel: endpoint {
remote-endpoint = <&mipi_in_panel>;
};
};
};
mipi_panel: panel@0 {
/* 2 different panels are used, compatibles are in dts files */
reg = <0>;
backlight = <&backlight>;
enable-gpios = <&gpio4 25 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <&display_rst_l>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
mipi_in_panel: endpoint {
remote-endpoint = <&mipi_out_panel>;
};
};
port@1 {
reg = <1>;
mipi1_in_panel: endpoint@1 {
remote-endpoint = <&mipi1_out_panel>;
};
};
};
};
};
&mipi_dsi1 {
status = "okay";
ports {
mipi1_out: port@1 {
reg = <1>;
mipi1_out_panel: endpoint {
remote-endpoint = <&mipi1_in_panel>;
};
};
};
};
The driver internal setup is pretty similar to what tegra does with
its ganged-mode [1][2]. Here a new helper function allows to traverse
the devicetree from one controller port through the panel to find
another dsi-controller using that same panel. This way we don't need
a special phandle-property to link the controllers together.
Looking at the tegra-code it seems that it expects the panel to just
declare 4 lanes which then get assigned to each dsi instance, where
ours currently declares 8 which then get divided in the dual-case.
I think both have merrit, so I guess I'll let people with more clue
decide that ;-) .
For the CRTC it is still one single display to handle, only with
an additional switch that enables the dual-dsi output.
For practical purposes it is possible to just pick half the series
(till patch 5) to get the migration to the bridge driver first,
so that we can get rid of the dw-dsi copy in the Rockchip driver.
[0] https://patchwork.kernel.org/patch/10172381/
[1] https://lkml.org/lkml/2014/8/5/396
[2] https://patchwork.kernel.org/patch/5075161/
Heiko Stuebner (5):
drm/bridge/synopsys: dsi: move mipi_dsi_host_unregister to
__dw_mipi_dsi_remove
drm/bridge/synopsys: dsi: don't call __dw_mipi_dsi_probe from
dw_mipi_dsi_bind
drm/bridge/synopsys: dsi: defer probing if panel not available in
bridge-attach
drm/dsi: add helper function to find the second host in a dual-dsi
setup
drm/rockchip: dsi: add dual mipi support
Nickey Yang (3):
dt-bindings: display: rockchip: update DSI controller
drm/rockchip: dsi: migrate to use dw-mipi-dsi bridge driver
drm/bridge/synopsys: dsi: add dual-dsi support
.../display/rockchip/dw_mipi_dsi_rockchip.txt | 23 +-
drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 115 +-
drivers/gpu/drm/drm_mipi_dsi.c | 56 +
drivers/gpu/drm/rockchip/Kconfig | 2 +-
drivers/gpu/drm/rockchip/Makefile | 2 +-
.../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 1001 ++++++++++++
drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 1349 -----------------
drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 2 +-
drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 3 +-
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 3 +
drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 4 +
drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 1 +
include/drm/bridge/dw_mipi_dsi.h | 6 +-
include/drm/drm_mipi_dsi.h | 2 +
14 files changed, 1188 insertions(+), 1381 deletions(-)
create mode 100644 drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
delete mode 100644 drivers/gpu/drm/rockchip/dw-mipi-dsi.c
--
2.17.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
