Re: [git pull] drm for 4.19-rc1

[Daniel Vetter]

On Fri, Aug 17, 2018 at 12:22 AM, John Stultz <john.stultz@xxxxxxxxxx> wrote:
> On Thu, Aug 16, 2018 at 3:16 PM, Daniel Vetter <daniel@xxxxxxxx> wrote:
>> On Thu, Aug 16, 2018 at 11:21 PM, John Stultz <john.stultz@xxxxxxxxxx> wrote:
>>> On Thu, Aug 16, 2018 at 1:46 PM, Daniel Vetter <daniel@xxxxxxxx> wrote:
>>>> You happen to have set drm_fb_overalloc respectively
>>>> CONFIG_DRM_FBDEV_OVERALLOC? Was added so that mali blob can pageflip,
>>>> would explain what's going on at least.
>>>
>>> Yep. CONFIG_DRM_FBDEV_OVERALLOC is set to 200.
>>
>> So ->max_height is indeed the limit (or should be, minus driver bugs)
>> for framebuffers. That's enforced in drm_framebuffer_create_internal
>> for everything (both ioctl and should also for all internal callers),
>> except the cma helpers never made sure this is correct. So I'd call
>> this a bugfix.
>
> Sure.  I'm really not sure where the max_height=2048 comes from (and
> if its the real limitation or a vendor guessed value - the hikey960
> driver I have uses the same), but yea, the old code wasn't checking
> it.

So in a way the limit is not entirely correct, since it's enforced for
drm_framebuffer, not for the underlying memory object. Assuming you
keep alignment correct (which is not exposed to userspace) you can
overallocate that and scan the drm_framebuffer over it. But the fbdev
helpers don't do that.

We also don't have separate limits for fb sizes and max scanout.
Though the later is supposed to be filtered in the various mode_valid
callbacks, not through max_*.

>> Now the question is whether the fbdev page-flipping actually worked on
>> older kernels for you or not ...
>
> It sure seems to work ok with the changes reverted.   Any suggestion
> on how to check this?

No idea. I didn't type a testcase for it, wasn't my feature :-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch