Am Dienstag, 3. Juli 2018, 19:07:02 CEST schrieb Andrzej Hajda:
On 18.06.2018 12:28, Heiko Stuebner wrote:
From: Nickey Yang nickey.yang@rock-chips.com
Allow to also drive a slave dw-mipi-dsi controller in a dual-dsi setup. This will require additional implementation-specific code to look up the slave instance and do specific setup. Also will probably need code in the specific crtcs as dual-dsi does not equal two separate dsi outputs.
To activate, the implementation-specific code should set the slave using dw_mipi_dsi_set_slave() before calling __dw_mipi_dsi_bind().
v2:
- expect real interface number of lanes
- keep links to both master and slave
I did not see the whole driver/pipeline, but it seems the point of this patch is to perform the same work on the slave as on the master in case of dual mode. I think DSI should not be a place for it, DSI masters usually are stupid devices from display stack PoV, they just convert video streams, in dual mode also. In this case the panel and/or crtc adds complications so they should be responsible for handling it. Panel should:
- register its both mipi interfaces with proper mode_flags (maybe some
dual-mode indication flags should be added if necessary),
- register drm_panel for both interfaces (it requires change in
drm_panel api), and provide video mode timings.
- in case it needs perform transfers perform it to master/slave/both
interfaces according to its needs,
I am not sure about DRM pipeline, it should model, maybe it could be done this way: CRTC -->ENCODER0(dsi master) --> CONNECTOR0 (panel interface 0) |---> ENCODER1(dsi slave) --> CONNECTOR1 (panel interface 1)
But I am not sure if it is not reserved only for mirroring.
For me more tempting solution is to create meta-encoder-connector let's call it dual-encoder (maybe it could be even generic), which is visible to userspace as single pipeline and encapsulates both dsi bridges/panel inputs. So its every callback will be translated usually to sequence of callbacks to 1st and 2nd dsi, or in case of get_modes it should return mode which represent sum of modes in both panels. Maybe it looks more complicated, but it can be more universal - you can use it with different bridges/panels even two single-panels if necessary.
Of course I do not see the whole picture, or I can be just wrong, or just freaking purist :). If there are arguments against my vision please provide them. I am also not strongly against your solution, I just want to show alternatives, which could be better/more generic.
I cannot really claim to know the correct way to go forward, as these drm-internals are still very much unknown land for me, but current thought points I had on this:
- strawman argument ;-) : this is the same way tegra handles dual-dsi in its ganged mode ... also with regards to panel handling With Thierry helming both panels and the tegra dual-dsi change
- while the panel may expose two DSI data interfaces, there is still only one power-sequence and also only one init-command sequence. So I don't think you can really handle a dual-dsi panels as two fully separate panels, creating instead the need for both panel-instances to work together
- Right now we have two data-points on dual-something voodoo (tegra+rockchip) So for me it sounds hard to design something generic that survives the first non-dsi use-case.
The devicetree binding (see cover-letter) should be pretty stable, as a panel like this will need to be bound to one of the two dsi controllers so nothing hinders code changes later on if the need for a more generic solution comes up.
Heiko