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

[Bish, Jim]

On Mon, 2015-07-13 at 11:05 +0200, Daniel Vetter wrote:
> 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

if you have dr. HDMI device you can set custom EDID in slots 6 and 7 -
works great for this type of exercise with no additional necessary to
try out.

Jim