On Mon, Sep 02, 2013 at 08:51:41PM +0200, Daniel Vetter wrote: > On Mon, Sep 02, 2013 at 09:24:26PM +0300, ville.syrjala@xxxxxxxxxxxxxxx wrote: > > From: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> > > > > We don't want to try to push the hardware beyond it's capabilities, > > so check the pixel clock against the display core clock limit. Do > > it for pre-gen4 for now since that's where we alread have the double > > wide pixel clock limit check. > > > > Let's assume that when double wide mode is enabled the max > > pixel clock limit is also doubled. > > > > FIXME: panel fitter downscaling probably affects the limit on > > non-pch platforms too, so we'd need another version of > > ilk_pipe_pixel_rate() to figure that out. > > > > FIXME: should check the limits on all platforms. Also sprites > > affect the max allowed pixel rate on some platforms, so we need > > to eventually tie all the planes and pipes into one check in > > the future. But we need plane state pre-compute before that can > > happen. > > > > Signed-off-by: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> > > --- > > drivers/gpu/drm/i915/intel_display.c | 8 +++++++- > > 1 file changed, 7 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c > > index ea33468..040e0ef 100644 > > --- a/drivers/gpu/drm/i915/intel_display.c > > +++ b/drivers/gpu/drm/i915/intel_display.c > > @@ -4140,6 +4140,7 @@ static int intel_crtc_compute_config(struct intel_crtc *crtc, > > return -EINVAL; > > } > > > > + /* FIXME should check pixel clock limits on all platforms */ > > We do by failing to find the pll. The fun is to move all that code into > the pipe computation stage. Are you 100% sure the PLL algorithm can never give you a clock that exceeds the display core clock? Looking at the functions to calculate the core clock, there is an awful lot of variation there already, and we don't even have those functions filled out for modern platforms. > The second part of the fun is that on newer > platforms dotclock limits are all encoder specific, so we need to shovel > them into encoder callbacks anyway. > > I don't know whether there are any additional pixel clock limits on top of > what the plls can handle, but at least I haven't spotted them yet ... The display core clock is the big one. We have to check it for other platforms too eventually since the limit depends on a bunch of factors. For example on ILK/SNB we need to check whether there's one or two sprites enabled, are they using RGB or YUV, are they scaled, and if so by how much? Obviouly we can't do all that until we can pre-compute the state of all planes. So actually we may need some more steps in the process. Something like this: 1) adjust timings 2) calculate PLL settings to get the real clock 3) check double wide etc. that depends on the clock 4) compute plane config 5) check core clock and other plane related global limits But I don't mind dropping this one now, and revisiting the issue with a bigger hammer in the future. -- Ville Syrjälä Intel OTC _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
