Re: [PATCH 4/8] drm/tidss: Add support for Dual Link LVDS Bus Format
From: Tomi Valkeinen
Date: Tue Aug 09 2022 - 02:28:44 EST
Hi,
On 09/08/2022 08:58, Aradhya Bhatia wrote:
Hi Tomi,
On 28-Jul-22 17:15, Tomi Valkeinen wrote:
On 28/07/2022 14:03, Tomi Valkeinen wrote:
On 19/07/2022 11:08, Aradhya Bhatia wrote:
The 2 OLDI TXes in the AM625 SoC can be synced together to output a 2K
resolution video.
Add support in the driver for the discovery of such a dual mode
connection on the OLDI video port, using the values of "ti,oldi-mode"
property.
Signed-off-by: Aradhya Bhatia <a-bhatia1@xxxxxx>
---
drivers/gpu/drm/tidss/tidss_dispc.c | 39
+++++++++++++++++++++--------
1 file changed, 28 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/tidss/tidss_dispc.c
b/drivers/gpu/drm/tidss/tidss_dispc.c
index add725fa682b..fb1fdecfc83a 100644
--- a/drivers/gpu/drm/tidss/tidss_dispc.c
+++ b/drivers/gpu/drm/tidss/tidss_dispc.c
@@ -853,25 +853,36 @@ void dispc_set_irqenable(struct dispc_device
*dispc, dispc_irq_t mask)
}
}
-enum dispc_oldi_mode_reg_val { SPWG_18 = 0, JEIDA_24 = 1, SPWG_24 =
2 };
+enum dispc_oldi_mode_reg_val {
+ SPWG_18 = 0,
+ JEIDA_24 = 1,
+ SPWG_24 = 2,
+ DL_SPWG_18 = 4,
+ DL_JEIDA_24 = 5,
+ DL_SPWG_24 = 6,
+};
struct dispc_bus_format {
u32 bus_fmt;
u32 data_width;
bool is_oldi_fmt;
+ bool is_dual_link;
enum dispc_oldi_mode_reg_val oldi_mode_reg_val;
};
static const struct dispc_bus_format dispc_bus_formats[] = {
- { MEDIA_BUS_FMT_RGB444_1X12, 12, false, 0 },
- { MEDIA_BUS_FMT_RGB565_1X16, 16, false, 0 },
- { MEDIA_BUS_FMT_RGB666_1X18, 18, false, 0 },
- { MEDIA_BUS_FMT_RGB888_1X24, 24, false, 0 },
- { MEDIA_BUS_FMT_RGB101010_1X30, 30, false, 0 },
- { MEDIA_BUS_FMT_RGB121212_1X36, 36, false, 0 },
- { MEDIA_BUS_FMT_RGB666_1X7X3_SPWG, 18, true, SPWG_18 },
- { MEDIA_BUS_FMT_RGB888_1X7X4_SPWG, 24, true, SPWG_24 },
- { MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA, 24, true, JEIDA_24 },
+ { MEDIA_BUS_FMT_RGB444_1X12, 12, false, false, 0 },
+ { MEDIA_BUS_FMT_RGB565_1X16, 16, false, false, 0 },
+ { MEDIA_BUS_FMT_RGB666_1X18, 18, false, false, 0 },
+ { MEDIA_BUS_FMT_RGB888_1X24, 24, false, false, 0 },
+ { MEDIA_BUS_FMT_RGB101010_1X30, 30, false, false, 0 },
+ { MEDIA_BUS_FMT_RGB121212_1X36, 36, false, false, 0 },
+ { MEDIA_BUS_FMT_RGB666_1X7X3_SPWG, 18, true, false, SPWG_18 },
+ { MEDIA_BUS_FMT_RGB888_1X7X4_SPWG, 24, true, false, SPWG_24 },
+ { MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA, 24, true, false,
JEIDA_24 },
+ { MEDIA_BUS_FMT_RGB666_1X7X3_SPWG, 18, true, true,
DL_SPWG_18 },
+ { MEDIA_BUS_FMT_RGB888_1X7X4_SPWG, 24, true, true,
DL_SPWG_24 },
+ { MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA, 24, true, true,
DL_JEIDA_24 },
};
So the dual link sends two pixels per clock, right? Are there panel
or bridge drivers that support this? My initial thought was that it
should be a new bus format.
Looks like we have drm bridges supporting dual link, and they use the
"normal" bus format. Did you have a look at them? They require two
port nodes for dual link, and use the existence of the second one to
decide if dual link is used or not.
The above edits were not for adding a new bus format for dual link
connections. I added them in order to be able to write the correct OLDI
config values in the register.
There are also lvds helpers in drm_of.c. I didn't look closely, but it
looked to me that the helpers can tell you if the ports are connected
to a dual link bridge. If not, you could fall back to cloning. This
way no extra properties are needed. But you will need to add a port
node, which I think you need to add anyway for cloning.
I have now seen drm_of.c and examples (renesas' rcar lvds) that use the
apis that drm_of.c is offering. In those cases, the OLDI TXes are being
modeled as separate devices, which is not the case with the tidss' OLDI
TXes. Since the only few OLDI registers are in the DSS address space,
they were just being configured through the tidss driver.
I think it's irrelevant (in the bigger picture) whether the TXes are
separate devices, single device or part of some other device. Or why do
you think it matters?
Even in DT, the dss port (for OLDI) connects to the panel port's
endpoint directly. Even in cases of dual link or cloning, it's only a
singular remote-to-endpoint connection between the (OLDI) VP and the
panel port. Hence the requirement of the properties in the earlier
patches of the series.
Sorry, I don't follow. If you use cloning, you have two TX outputs,
going to two panels, right? So you need two panel DT nodes, and those
would connect to two OLDI TX ports in the DSS.
Afaics the existing dual link bridge/panel drivers also use two ports
for the connection, so to use the dual link you need two ports in the DSS.
I admit I'm not familiar with LVDS dual link, but it's not clear to me
how you see the dual OLDI TX being used with other drivers if you have
only one port. What kind of setups have you tested?
The use of lvds helper functions does not seem feasible in this case,
because even they read DT properties to determine the dual link
connection and those properties need to be a part of a lvds bridge
device.
Can you elaborate a bit more why the DRM helpers couldn't be used here?
I have also been considering the idea of implementing a new device
driver for the OLDI TXes, not unlike the renesas' one. That way the
driver could have the properties and the lvds helper functions at their
disposal. I am just slightly unsure if that would allow space for any
conflicts because of the shared register space.
No, I don't think new devices are needed here.
Tomi