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

[Daniel Vetter]

On Mon, Jul 13, 2015 at 05:32:14PM +0000, Bish, Jim wrote:
> 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.

The idea is to be able to run the testsuite with bare-bones machines and
no need to send each developer a special piece of hw for each type of
output. I know that there are tons of hw solutions for these testing
problems, they don't seem to scale well enough.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch