On Mon, Sep 02, 2013 at 10:05:26PM +0300, Ville Syrjälä wrote: > On Mon, Sep 02, 2013 at 08:39:45PM +0200, Daniel Vetter wrote: > > On Mon, Sep 02, 2013 at 09:13:30PM +0300, ville.syrjala@xxxxxxxxxxxxxxx wrote: > > > From: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> > > > > > > The pixel clock should come from adjusted_mode not requested_mode. > > > In this case the two should be the same as we don't currently > > > overwrite the clock in the case of HDMI. But let's make the code > > > safe against such things happening in the future. > > > > > > Signed-off-by: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> > > > > Atm only the encoder overrides the adjusted_mode at all, so I think I > > prefer the current code flow as clearer ... > > And I'd atually prefer to kill requested_mode. It's confusing. > > Only hdisplay/vdisplay are always valid. Well even that's not true > as can be seen from my double wide series. > > The clock and timings can be trusted only at the very beginning of the > compute config step. And at that point adjusted_mode contains the exact > same information. Also apart from the clock, we never use the other > timings from requested_mode, so keeping the whole thing around seems > more or less pointless. Ok, count me slightly convinced. I agree that after the pipe config compute stage the only thing we can rely on is h/vdisplay (it's also the only thing we actually cross-check). So I guess ditching config->requested_mode is a good goal. If you throw a patch on top to add a bit of documentation for the adjusted_mode and the pipe_src_h|w fields I'll even be happy ;-) Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
