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@xxxxxxxxxxxxxxx wrote: > > > > > From: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> > > > > > > > > > > Since > > > > > commit e62925567c7926e78bc8ca976cde5c28ea265a49 > > > > > Author: Vandana Kannan <vandana.kannan@xxxxxxxxx> > > > > > 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@xxxxxxxxx> > > > > > Cc: Imre Deak <imre.deak@xxxxxxxxx> > > > > > Signed-off-by: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> > > > > > > > > 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
