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 > > > > > > > > > > > > > -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
