[Intel-gfx] [PATCH v5 4/8] drm/cma-helper: Use the generic fbdev emulation

Daniel Vetter daniel at ffwll.ch
Thu Aug 23 08:09:50 UTC 2018


On Thu, Aug 23, 2018 at 10:46:15AM +0300, Laurent Pinchart wrote:
> Hi John,
> 
> On Thursday, 23 August 2018 07:14:08 EEST John Stultz wrote:
> > On Mon, Aug 20, 2018 at 11:44 PM, John Stultz 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.
> 
> Possibly slightly out of topic, but we're in 2018, is there any plan to make 
> SurfaceFlinger move away from FBDEV ?

Is surfaceflinger really using direct fbdev still (maybe for boot-up)? Or
is this just an artifact of the mali blob hwcomposer backend?
-Daniel

> 
> > 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.
> > 
> > So it seems like we might need to multiply the max_height by the
> > overalloc factor when we are checking it in
> > drm_internal_framebuffer_create?
> > 
> > Does that approach sound sane, or would folks prefer something different?
> 
> -- 
> Regards,
> 
> Laurent Pinchart
> 
> 
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


More information about the Intel-gfx mailing list