13:44 <phh> has someone enabled mipi/dsi video output on rk3288 mainline kernel?

13:45 <phh> I feel like I don't have the proper syntax, mostly nothing appears in the logs or in /sys

13:45 <phh> [ 1.103269] rockchip-drm display-subsystem: bound ff960000.mipi (ops 0xc0e3afc8)

13:45 <phh> [ 1.171846] rockchip-drm display-subsystem: fb0: frame buffer device

13:45 <phh> [ 1.123240] rockchip-drm display-subsystem: No connectors reported connected with modes

13:45 <phh> that's mostly all I get

13:45 <phh> (that's 4.9-rc2)

13:46 <phh> here is what my dts looks like: http://pastebin.com/bqML12e1 (it's a big mash-up of things I've seen at various places)

13:58 <ayaka> phh, you can't access the fb to output video

13:58 <ayaka> you must using it through the drm, like xserver

13:59 <ayaka> or those panel are registered as a subsystem of drm

13:59 <phh> HDMI can but not mipi?

14:09 <mmind00> phh: so far I personally haven't seen any dsi devices, but I guess as a start just sprinkle some printks throughout the dsi driver, because "no connectors" means no encoder driver (hdmi, dsi, etc) reported a connected device, so the dsi encoder driver maybe has trouble finding the panel

14:24 <phh> that's weird... having hdmi enabled changes the behaviour

14:24 <phh> with hdmi disabled, fbdev is 1024x768, with hdmi enabled not connected, it goes to panel's resolution (1920x1200)

14:25 <phh> though I get an error when hdmi is enabled: dw-mipi-dsi ff960000.mipi: failed to wait for phy clk lane stop state

14:26 <phh> right the return value of dw_mipi_dsi_phy_init() isn't checked, so it won't prevent detection

14:28 <mmind00> phh: 1024x768 is some sort of default when no display is detected at all

14:32 <phh> yup that's what I guessed, but I don't understand why with hdmi it can attach but not without it

14:40 <mmind00> phh: you're also seeing something on the DSI display in that case?

14:41 <phh> I have to fight with backlight first, because I can answer :s

14:41 <phh> s/because/before/

14:41 <mmind00> phh: what I'd guess is more, drm finds the hdmi display and sets the resolution to that size ... still ignoring the dsi display

14:42 <phh> mmind00: setting it to 1920x1200 would be weird

14:42 <phh> mmind00: ok, so yes the DSI display does work in that case

14:43 <mmind00> i.e. when building the drm device, it probes each encoder and collects the modes on each, thus in your case I still think it only saw the hdmi display alone again

14:47 <phh> ok, so the video output is cloned on both output

14:48 <phh> and the resolution of the frambuffer is either hdmi's resolution if hdmi is plugged on boot, else it's the resolution of the integrated panel

14:53 <phh> so everything looks ok, except that it doesn't init when there is no hdmi. I guess it's a bug in dw-mipi-dsi.c

14:55 <phh> or it's not really a bug and it's like ayaka mentioned

15:43 <mmind00> phh: nope ... it's either (1) hdmi resolution, (2) dsi resolution, (3) some merger betweeen both (minimal supported or so), (4) 1024x768 if _no_ display is found at all

22:48 <phh> what's the current status of mali support on recent kernels? do some people backport mali kernel drivers?