Re: [PATCH] drm/i915: Check for a change in fb size, and reconfigure the pipe

["Ville Syrjälä" <ville.syrjala@linux.intel.com>]

On Tue, Nov 13, 2012 at 01:33:37PM +0000, Chris Wilson wrote:
> On Tue, 13 Nov 2012 15:15:55 +0200, Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> > On Tue, Nov 13, 2012 at 12:48:11PM +0000, Chris Wilson wrote:
> > > On Tue, 13 Nov 2012 14:42:36 +0200, Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> > > > On Tue, Nov 13, 2012 at 12:15:10PM +0000, Chris Wilson wrote:
> > > > > In the slightly unusual case where the pipe is programmed to the same
> > > > > modeline, but the framebuffer is a new size, we need to resetup the
> > > > > panel fitter as appropriate and this requires a full modeset. This can
> > > > > only occur currently as part of the BIOS takeover where there are
> > > > > slightly different semantics governing how the panel fitter and
> > > > > framebuffer is programmed relative to the modeline.
> > > > 
> > > > Hmm. I don't get it. Why would the framebuffer size affect the panel
> > > > fitter configuration?
> > > 
> > > The BIOS uses fb->(width,height) to program PIPESRC, we use
> > > mode->[hv]display. The BIOS's semantics makes more sense
> > 
> > I don't think so. That would make panning impossible.
> 
> True. The issue really appears that we recreate the mode using the crtc
> values and assume that the reverse mapping works. Further issues arise
> if we want to recover any offsets in a multiple output configuration. I
> will just have to double-check that the BIOS configuration matches our
> usage.
> 
> And I whole-heartedly agree with separating the display mode from the
> plane configuration, I guess you have something planned along those
> lines already ;-)

Well, I have some ideas in my head, but so far I haven't found the time
to do the work. Originally I was thinking that I'd try to combine this
work with the atomic mode setting, but I fear that if I keep piling on
more changes, it'll never be ready.

-- 
Ville Syrjälä
Intel OTC