On Thu, Aug 23, 2018 at 10:24 AM, Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> wrote: > On Wed, Aug 22, 2018 at 09:14:08PM -0700, John Stultz wrote: >> On Mon, Aug 20, 2018 at 11:44 PM, John Stultz <john.stultz@xxxxxxxxxx> wrote: >> > Hey Noralf, all, >> > I've been digging for a bit on the regression that this patch has >> > tripped on the HiKey board as reported here: >> > https://lkml.org/lkml/2018/8/16/81 >> > >> > The first issue was that the kirin driver was setting >> > mode_config.max_width/height = 2048, which was causing errors as the >> > the requested resolution was 1920x2160 (due to surfaceflinger >> > requesting y*2 for page flipping). >> >> Hey Noralf, >> Sorry, I know your probably sick of me. But I just wanted to circle >> around on this little bit. So part of the issue I found earlier, was >> that I'm running w/ CONFIG_DRM_FBDEV_OVERALLOC=200, to support >> Surfaceflinger's request for page flipping. This is what makes the Y >> resolution 2160, which runs afoul of the new max_height check of 2048 >> in the generic code. >> >> I was checking with Xinliang, who know the kirin display hardware, >> about the max_height being set to 2048 to ensure bumping it up wasn't >> a problem, but he said 2048x2048 was unfortunately not arbitrary, and >> that was the hard limit of the display hardware. However, with >> overalloc, the 1920x2160 res fbdev should still be ok, as only >> 1920x1080 is actually displayed at one time. > > I recently tried to clarify that max_width/height are simply the max > framebuffer dimensions supported by the driver. So it's perfectly legal > for a driver to declare max_height as something big that can't be > scanned out in its entirety by a single plane. For i915 I'm currently > working on bumping these limits to 32k-1 regardless of the hardware > scanout limitations. > > So if you're already running with a framebuffer height >2048 and it > works then it would seem to me that you could just bump this limit in > the driver. Ok. I'm fine with this as long as its not going to cause further trouble. thanks -john _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
