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

John Stultz john.stultz at linaro.org
Thu Aug 23 17:42:58 UTC 2018


On Thu, Aug 23, 2018 at 10:24 AM, Ville Syrjälä
<ville.syrjala at linux.intel.com> 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 at linaro.org> 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


More information about the dri-devel mailing list