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@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 > > 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
