Hi Andrzej et all,
just so we don't discuss in a theoretic way much longer I've just sent a RFC with my current state of work for the dw-mipi-dsi dual-dsi support - aka the old "let code speak" ;-)
I've found a somewhat nice way to get from one dsi-controller node to the node of the other dual-dsi part via separate ports as well. So no more hackery with endpoints and I can just follow Archit's dual-dsi binding text.
Am Freitag, 8. Juni 2018, 10:47:05 CEST schrieb Andrzej Hajda:
On 08.06.2018 00:50, Heiko Stuebner wrote:
Am Donnerstag, 7. Juni 2018, 23:10:20 CEST schrieb Brian Norris:
Hi,
I only have a little bit to add, but Heiko did solicit my opinion.
yep ... and I realized that I am/was way to attached to my (working) endpoint-based thingy to really appreciate the other arguments ;-)
And your DSI-related writings below, did provide some new thought- directions for me, so thanks for that.
[...]
On Thu, Jun 07, 2018 at 03:25:18PM +0200, Heiko Stuebner wrote:
Am Donnerstag, 7. Juni 2018, 12:39:03 CEST schrieb Andrzej Hajda:
On 07.06.2018 01:08, Heiko Stuebner wrote:
Also the crtc<->dsi interaction is quite a bit of handling-different between one crtc talking to 2 DSIs or 2 crtc talking to the 2 DSIs separately.
That's probably the bigger key: to treat them as completely separate ports means that you get separate CRTCs, IIUC (I'll admit, I'm still a bit rusty on navigating some DRM concepts).
One thing I realized with your mention of DSI maxing out at 4 lanes is, that this makes it easy to detect the existence of a dual-dsi situation ... simply when the device reports 8 lanes. (via of_find_mipi_dsi_device_by_node presumably)
Hmm, device has two DSI interfaces, on each it has 4 lanes, so it report 4 lanes.
Ok ... that is what Tegra seems to do as well. The panel reporting 4 lanes, and this gettings assigned to each of the two dsi controllers. So I'll need to change that in my v2 as well.
There is different problem with current implementation of panel lookup code - drm_panel is identified by device_node of physical device, as a result there can be only one panel per device. I think proper identification should be by device_node of OF graph port, or by pair: device_node of physical device and port number (practically it is the same). I think fixing it should not be a big deal.
Right now in my RFC it seems to work without needing changes to panel types or identification, so I guess we can discuss changes you would like to see over there.
Heiko
As a dual-dsi situation requires a clock-master property in one, both master and slave also would be able to determine their master or slave status, thus the global dual-dsi config could be done by the master (GRF stuff in the Rockchip case)
The only thing that makes my head explode now, is how to make the slave actually react to settings sent to the master in a sane way.
Wouldn't be enough if the panel passes different bus info on DSI0 and DSI1?
Regards Andrzej
But that is a drm-specific implementation-detail, I guess ;-) . And hopefully someone might have a great idea how this could be done better than in my current implementation.
Heiko