[RFC v2 2/2] dt-bindings: mipi-dsi: Add dual-channel DSI related info

[Heiko Stuebner]

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
> >
> >
> >
> >
> >
> 
> 
>