Linux/DRA756: Linux Support & Examples for Writeback Pipeline in DSS

Thomas Brown

Part Number: DRA756

Tool/software: Linux

I have an application based on Debian using Wayland & QT for graphical applications.

So far I have been able to create an application which uses the DSS blender to overlay graphics onto a video stream and send out through the HDMI interface.

This is one of our key use cases and it works fine, however I am stuck on how our second use case can be enabled;

In this use case we require three of of the four available video pipelines in the DSS as input to the blender.

 - HMI

 - Video feed

 - Gfx overlays

We need to overlay the graphics onto the video and loop this back through the Writeback pipeline before running H.264 and storing as an mp4 file.  We also need to concurrently send out the HMI onto the HDMI interface.

Firstly I'd just like confirmation that the Writeback Pipeline is enabled in the Linux kernel drivers.

Secondly I'd just like to request any examples of how such a pipeline should be created OR just some general pointers on where to begin.

Much Appreciated.

Tom Brown

over 8 years ago

0 Anand Balagopalakrishnan over 8 years ago

TI__Expert 5130 points

Hi Tom,

Yes, DSS writeback pipeline is supported as part of PSDKLA release 3.02.
processors.wiki.ti.com/.../Category:Processor_SDK_Linux_Automotive

Based on the use case, you are looking at using DSS writeback in frame capture mode.

Sample application for using the writeback is available here:
github.com/.../wbtest.cpp

Regards,
Anand

0 Thomas Brown over 8 years ago in reply to Anand Balagopalakrishnan

TI__Expert 5225 points

Thanks Anand, I have a follow up question on how to setup the DTB for this:

We have a screen connected to the HDMI PHY of the Display Subsystem. For live view, we want to output to the screen the video from the camera with overlays and UI on top. We are mapping:

Plane 1 for video to hdmi
Plane 2 for UI to hdmi
Plane 3 for overlays to hdmi

and connecting them to the crtc associated with the HDMI.

For recording, we want to capture the output of the camera with overlays on top while the UI is displayed on the HDMI. In the device tree, we have added a panel to dpi3. From userspace we can see the two crtcs. We want to do:

Plane 1 for video to dpi3
Plane 2 for overlays to dpi3
Plane 0 for UI to hdmi

However, when we added the panel to dpi3, plane 0 is the primary for crtc 0 (HDMI) and plane 1 is the primary for crtc 1 (dpi3) and we can't change them. See the output of kmsprint -l:

Connector 0 (27) HDMI-A-1 (connected)
Connector 1 (31) Unknown-1 (connected)
Encoder 0 (26) TMDS
Encoder 1 (30) TMDS
Crtc 0 (29) 1280x768 80.159 1280/64/136/200 768/1/3/23 60 (60.02)
Crtc 1 (33) 1920x1080 30.000 1920/1/1/1 1080/1/1/1 14 (14.41)
Plane 0 (28) fb-id: 47 (crtcs: 0) 0,0 1280x768 -> 0,0 1280x768 (RG16 RX12 XR12 RA12 AR12 XR15 AR15 RG24 RX24 XR24 RA24 AR24)
Plane 1 (32) fb-id: 45 (crtcs: 1) 0,0 1920x1080 -> 0,0 1920x1080 (RG16 RX12 XR12 RA12 AR12 XR15 AR15 RG24 RX24 XR24 RA24 AR24 NV12 YUYV UYVY)
Plane 2 (34) (crtcs: 0 1) 0,0 0x0 -> 0,0 0x0 (RG16 RX12 XR12 RA12 AR12 XR15 AR15 RG24 RX24 XR24 RA24 AR24 NV12 YUYV UYVY)
Plane 3 (35) (crtcs: 0 1) 0,0 0x0 -> 0,0 0x0 (RG16 RX12 XR12 RA12 AR12 XR15 AR15 RG24 RX24 XR24 RA24 AR24 NV12 YUYV UYVY)
FB 47 1280x768
FB 45 1920x1080

Therefore, we can't do recording any more, as Plane 0 can't do video and plane 1 can only be used with crtc1 (dpi3).

Is it possible to tell omapdrm to make plane 0 be the primary for the dpi3 output and plane 1 the primary for HDMI?

Find below an excerpt of our device tree with the dss changes:

/ {
aliases {
display0 = &fake_panel;
display1 = &hdmi0;
};

fake_panel: connector@2 {
compatible = "panel-dpi";
label = "internal";

panel-timing {
hactive = <1920>;
vactive = <1080>;
clock-frequency = <30000000>;

hfront-porch = <1>;
hback-porch = <1>;
hsync-len = <1>;

vfront-porch = <1>;
vback-porch = <1>;
vsync-len = <1>;
};

port@lcd3 {
internal_panel_in: endpoint {
remote-endpoint = <&dpi3_out>;
};
};
};

hdmi0: connector@1 {
compatible = "hdmi-connector";
label = "hdmi";

port {
hdmi_connector_in: endpoint {
remote-endpoint = <&hdmi_out>;
};
};
};
};

&dss {
status = "ok";
vdda_video-supply = <®ulator_j6_1v8pll>;

port {
dpi3_out: endpoint@0 {
remote-endpoint = <&internal_panel_in>;
data-lines = <24>;
};
};
};

&hdmi {
status = "ok";
vdda-supply = <®ulator_j6_1v8phy>;
pinctrl-names = "default";
pinctrl-0 = <&hdmi_pins>;

port {
hdmi_out: endpoint {
lanes = <1 0 3 2 5 4 7 6>; /* reverse polarity */
remote-endpoint = <&hdmi_connector_in>;
};
};
};

0 Venkat Mandela over 8 years ago in reply to Thomas Brown

TI__Expert 5970 points

Hi,

Can you try swapping the order of the displays in dts?

aliases {

display1 = &fake_panel;

display0 = &hdmi0;

};

root@dra7xx-evm:~# kmsprint -l
Connector 0 (32) HDMI-A-1 (connected)
Connector 1 (36) Unknown-1 (connected)
Encoder 0 (31) TMDS
Encoder 1 (35) TMDS
Crtc 0 (34) 1280x720 74.250 1280/110/40/220 720/5/5/20 60 (60.00)
Crtc 1 (38) 1280x800 68.930 1280/48/32/48 800/4/4/8 60 (60.00)
Plane 0 (33) fb-id: 43 0,0 1280x720 -> 0,0 1280x720 (RG16 RX12 XR12 RA12 AR12 XR15 AR15 RG24 RX24 XR24 RA24 AR24)
Plane 1 (37) fb-id: 43 0,0 1280x800 -> 0,0 1280x800 (RG16 RX12 XR12 RA12 AR12 XR15 AR15 RG24 RX24 XR24 RA24 AR24 NV12
 YUYV UYVY)
Plane 2 (39) 0,0 0x0 -> 0,0 0x0 (RG16 RX12 XR12 RA12 AR12 XR15 AR15 RG24 RX24 XR24 RA24 AR24 NV12 YUYV UYVY)
Plane 3 (40) 0,0 0x0 -> 0,0 0x0 (RG16 RX12 XR12 RA12 AR12 XR15 AR15 RG24 RX24 XR24 RA24 AR24 NV12 YUYV UYVY)
FB 43 1280x800
FB 43 1280x800

regards,

Venkat

0 Thomas Brown over 8 years ago in reply to Venkat Mandela

TI__Expert 5225 points

Hi Venkat.

This suggestion hasn't worked. Please see reply:

We have tried your proposal, but it does not change anything. This is the output of "kmsprint -l" (compiled from github, which includes the available crtcs for each plane):

Connector 0 (27) HDMI-A-1 (connected)
Connector 1 (31) Unknown-1 (connected)
Encoder 0 (26) TMDS
Encoder 1 (30) TMDS
Crtc 0 (29) 1280x768@79.500 79.500 1280/64/128/192 768/3/10/17 0 (59.87)
Crtc 1 (33) 1920x1080 30.000 1920/1/1/1 1080/1/1/1 14 (14.41)
Plane 0 (28) fb-id: 45 (crtcs: 0) 0,0 1280x768 -> 0,0 1280x768 (RG16 RX12 XR12 RA12 AR12 XR15 AR15 RG24 RX24 XR24 RA24 AR24)
Plane 1 (32) fb-id: 44 (crtcs: 1) 0,0 1920x1080 -> 0,0 1920x1080 (RG16 RX12 XR12 RA12 AR12 XR15 AR15 RG24 RX24 XR24 RA24 AR24 NV12 YUYV UYVY)
Plane 2 (34) (crtcs: 0 1) 0,0 0x0 -> 0,0 0x0 (RG16 RX12 XR12 RA12 AR12 XR15 AR15 RG24 RX24 XR24 RA24 AR24 NV12 YUYV UYVY)
Plane 3 (35) (crtcs: 0 1) 0,0 0x0 -> 0,0 0x0 (RG16 RX12 XR12 RA12 AR12 XR15 AR15 RG24 RX24 XR24 RA24 AR24 NV12 YUYV UYVY)
FB 45 1280x768
FB 44 1920x1080

As you can see, the HDMI connector can only use planes 0, 2 and 3. You can get the same information using modetest from libdrm. For live view we want a video stream with overlays and UI on top, but plane 0 can't do video. What we want is HDMI to be able to use planes 1, 2 and 3.

We think that the order in which connectors are assigned primary planes is defined in drivers/gpu/drm/omapdrm/omap_drv.c:omap_modeset_init(). This follows the order in which omap_dss_devices are added to panel_list: the order in which hdmi and panel-dpi call omapdss_register_display(). In our system, hdmic_probe() is called before panel_dpi_probe(), so the HDMI gets plane 0 as primary and panel-dpi gets plane 1 as primary.

Our question is whether TI provides a way for assigning primary planes to crtcs, or if there is an alternative way of achieving what we want: Fake connector with plane 0 as primary and HDMI with plane 1 as primary.

Regards,
Tom

0 Venkat Mandela over 8 years ago in reply to Thomas Brown

TI__Expert 5970 points

>> Our question is whether TI provides a way for assigning primary planes to crtcs, or if there is an alternative way of achieving what we want: Fake connector with plane 0 as primary and HDMI with plane 1 as primary.

Not in K4.4 but possibly in K4.9. I will check if there is an alternate way for K4.4.

regards,
Venkat

Processors

Processors forum

Linux/DRA756: Linux Support & Examples for Writeback Pipeline in DSS