[PATCH v5 1/2] drm/bridge: Add Cadence DSI driver

[Boris Brezillon]

Hi Tomi,

On Mon, 29 Jan 2018 16:29:21 +0200
Tomi Valkeinen <tomi.valkeinen at ti.com> 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