[Intel-gfx] [PATCH] drm/i915: Adjust BXT HDMI port clock limits

[Daniel Vetter]

On Fri, Jul 10, 2015 at 02:27:48PM +0100, Damien Lespiau wrote:
> On Fri, Jul 10, 2015 at 04:21:27PM +0300, Ville Syrjälä wrote:
> > On Fri, Jul 10, 2015 at 02:18:57PM +0100, Damien Lespiau wrote:
> > > On Fri, Jul 10, 2015 at 04:09:42PM +0300, Imre Deak wrote:
> > > > On ma, 2015-07-06 at 14:44 +0300, ville.syrjala at linux.intel.com wrote:
> > > > > From: Ville Syrjälä <ville.syrjala at linux.intel.com>
> > > > > 
> > > > > Since
> > > > >  commit e62925567c7926e78bc8ca976cde5c28ea265a49
> > > > >  Author: Vandana Kannan <vandana.kannan at intel.com>
> > > > >  Date:   Wed Jul 1 17:02:57 2015 +0530
> > > > > 
> > > > >     drm/i915/bxt: BUNs related to port PLL
> > > > > 
> > > > > BXT DPLL can now generate frequencies in the 216-223 MHz range.
> > > > > Adjust the HDMI port clock checks to account for the reduced range
> > > > > of invalid frequencies.
> > > > > 
> > > > > Cc: Vandana Kannan <vandana.kannan at intel.com>
> > > > > Cc: Imre Deak <imre.deak at intel.com>
> > > > > Signed-off-by: Ville Syrjälä <ville.syrjala at linux.intel.com>
> > > > 
> > > > Ville wrote a tool for CHV that calculates the valid frequencies based
> > > > on the algorithm in the kernel. With the help of that I verified that
> > > > this matches the list of target frequencies bxt_find_best_dpll() will
> > > > accept, so:
> > > 
> > > Could we have that tool in i-g-t?
> > 
> > We could lift all the .find_dpll routines from the kernel into i-g-t.
> > The only real concern is that we'll forget to update the i-g-t copies
> > when changing the kernel. But I guess it would still be easier to just
> > update them slightly when noticing that rather than having to lift them
> > from the kernel all over again.
> 
> Right, while not ideal, I think having something in i-g-t, even if it
> diverges slightly (but then we can remind the patch author to update the
> i-g-t tool during review) is still better than not having that code
> around at all.

Another way to check this would be to inject EDIDs with hand-rolled
timings that increment in small steps. Then we can try modesets on all the
unfiltered ones vs. just manually adding it with addmode. If any mode gets
filtered inconsistently in the mode list parsing compared to modeset code
that would be a bug.

Unfortunately the hdmi injection stuff isn't ready yet. I'll create a jira
for this idea.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch