Hi Tomi, On Mon, 29 Jan 2018 16:29:21 +0200 Tomi Valkeinen <tomi.valkeinen@xxxxxx> wrote: > On 18/01/18 15:43, Boris Brezillon wrote: > > Add a driver for Cadence DPI -> DSI bridge. > > > > This driver only support a subset of Cadence DSI bridge capabilities. > > > > Here is a non-exhaustive list of missing features: > > * burst mode > > * DPHY init/configuration steps > > * support for additional input interfaces (SDI input) > > I think it would be good to have a list of features that are supported > and tested, and perhaps a word about the development setup you have. > > One thing that slightly worries me are the DPHY and input pixel clock > rates. Now the code expects that those values match perfectly, which is > not the case in real life. So what's the accepted difference, and is > there something in the registers to program differently depending on the > diff? Just had a quick chat with Simon, and it seems some of the bits I was setting were already activating the HSYNC/VSYNC recovery mechanism: * VID_IGNORE_MISS_VSYNC: recover the case where pixel clock runs slower than TX byte clk * the engine already handles the other case (pixel clock runs faster than TX byte clk) automatically (or maybe this is configured with the RECOVERY_MODE() field, I'm not sure) Simon, don't hesitate to provide more information or correct me if I'm wrong. Note that the TX byte clk should be configured to match the DPI pixel clock, which means we should refuse any config where the variation is too big to be recovered. Anyway, we still don't have a way to configure the PLL rate (which is driving the TX byte clk), so there's not much I can do about that right now. > > Another thing is that the mode->crtc_clock is in kHz, I wonder if that > rounding can cause miscalculations in the above code. Do we really have modes exposing pixel clks not aligned on a Khz? I know the display controller can adjust the timings, but then, the variation caused by the Khz approx should not be that big (999Khz / 10+MHz < 1/10000), and anyway, that's what the DRM framework manipulates... Regards, Boris -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
