<minute>
narmstrong: do you think it is possible at all and what is blocking it? anything i could look into?
<narmstrong>
minute: it must be possible, but there’s 0 documentation and no good source for reference, and I have 0 time to look into it, first step would be to make this use case work using an amlogic’s kernel and dump all registers
<narmstrong>
Then we can try to replicate on upstream
<minute>
narmstrong: ah, i see... what is the unknown part, some kind of muxing?
<minute>
i mean, hdmi and dsi work separately, but do they both need a resource that would be a conflict at the moment, like a pixel clock or display engine?
<narmstrong>
It’s on the pixel generation part (crtc & planes) the hdmi/dsi part won’t change, so the work it to understand how to enable the second vpp/viu and set the mux to forward the pixels to the hdmi or dsi encoders
<narmstrong>
A key register is VPU_VIU_VENC_MUX_CTRL
<narmstrong>
Where is connects the encoders to VIU1 and VIU2
<narmstrong>
The clock goes from the encoder to the pixel generator, so the actual hdmi and dsi code won’t change since we already support clocking for HDMI and dsi at the same time
<narmstrong>
So we must figure how vpp2 and viu2 works (like is there separate planes or shared planes, separate or shared scalers), the power domains clocks to enable, and the corresponding drm plumbing to expose a second crtc and setup VPU_VIU_VENC_MUX_CTRL accordingly
<minute>
narmstrong: ok, thank you, that's a good explanation