I've verified that it doesn't break our existing code, but I'm in the process of rebasing my atomic enabling patch series onto drm-next along with this. I should be able to get this done by tomorrow morning.
________________________________________
From: Maarten Lankhorst <maarten.lankhorst@xxxxxxxxxxxxxxx>
Sent: Thursday, February 9, 2017 4:29:49 AM
To: Sinclair Yeh
Cc: Thomas Hellstrom; Daniel Vetter; Matt Roper; Daniel Vetter; intel-gfx@xxxxxxxxxxxxxxxxxxxxx; dri-devel@xxxxxxxxxxxxxxxxxxxxx; Daniel Vetter
Subject: Re: [PATCH 4/4] drm: Resurrect atomic rmfb code, v2
Op 26-01-17 om 19:39 schreef Sinclair Yeh:
> On Thu, Jan 26, 2017 at 10:55:51AM +0100, Maarten Lankhorst wrote:
>> Op 25-01-17 om 19:05 schreef Sinclair Yeh:
>>> On Wed, Jan 25, 2017 at 09:36:36AM +0100, Maarten Lankhorst wrote:
>>>> Op 25-01-17 om 09:09 schreef Thomas Hellstrom:
>>>>> On 01/25/2017 05:54 AM, Daniel Vetter wrote:
>>>>>> On Tue, Jan 24, 2017 at 01:44:54PM -0800, Matt Roper wrote:
>>>>>>> On Wed, Jan 11, 2017 at 05:15:47PM +0100, Daniel Vetter wrote:
>>>>>>>> On Thu, Dec 15, 2016 at 03:29:45PM +0100, Maarten Lankhorst wrote:
>>>>>>>>> From: Daniel Vetter <daniel.vetter@xxxxxxxx>
>>>>>>>>>
>>>>>>>>> This was somehow lost between v3 and the merged version in Maarten's
>>>>>>>>> patch merged as:
>>>>>>>>>
>>>>>>>>> commit f2d580b9a8149735cbc4b59c4a8df60173658140
>>>>>>>>> Author: Maarten Lankhorst <maarten.lankhorst@xxxxxxxxxxxxxxx>
>>>>>>>>> Date: Wed May 4 14:38:26 2016 +0200
>>>>>>>>>
>>>>>>>>> drm/core: Do not preserve framebuffer on rmfb, v4.
>>>>>>>>>
>>>>>>>>> Actual code copied from Maarten's patch, but with the slight change to
>>>>>>>>> just use dev->mode_config.funcs->atomic_commit to decide whether to
>>>>>>>>> use the atomic path or not.
>>>>>>>>>
>>>>>>>>> v2:
>>>>>>>>> - Remove plane->fb assignment, done by drm_atomic_clean_old_fb.
>>>>>>>>> - Add WARN_ON when atomic_remove_fb fails.
>>>>>>>>> - Always call drm_atomic_state_put.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Daniel Vetter <daniel.vetter@xxxxxxxxx>
>>>>>>>>> Signed-off-by: Daniel Vetter <daniel.vetter@xxxxxxxx>
>>>>>>>>> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@xxxxxxxxxxxxxxx>
>>>>>>>> Would be great if someone else could r-b this, I've proven pretty well
>>>>>>>> that I don't understand the complexity here :(
>>>>>>>> -Daniel
>>>>>>> It looks like this will change the behavior slightly in that rmfb will
>>>>>>> cause primary planes to be disabled, but no longer cause the entire CRTC
>>>>>>> to be turned off. You'll probably want to note that in the commit
>>>>>>> message, along with the justification on why this is okay ABI-wise.
>>>>>>>
>>>>>>> I know that 13803132818c ("drm/core: Preserve the framebuffer after
>>>>>>> removing it.") was initially trying to not only leave the CRTC on, but
>>>>>>> also preserve the framebuffer and leave the planes on; that wound up
>>>>>>> causing some kind of regression for vmwgfx, but I'm unclear on the
>>>>>>> details there. I'd suggest getting an Ack from one of the vmware guys
>>>>>>> to ensure that the less drastic change in behavior here won't cause them
>>>>>>> any problems.
>>>>> The vmware Xorg driver is currently relying on rmfb to turn all attached
>>>>> crtcs off. Even if we were to fix that in the Xorg driver now, older
>>>>> Xorgs with newer kernels still would break.
>>>> Is it allowed for vmwgfx to keep the crtc enabled, but the primary plane disabled?
>>>>
>>>> If so, when vmwgfx is eventually converted to atomic then we need to special-case rmfb for them somehow.
>>> FYI, we are in the process of converting things to atomic. This may happen
>>> around 4.12
>>>
>> Will the driver allow the crtc to be enabled without primary plane?
> Give me a few days to get back to you. I'm reworking some patches right now.
>
>
Any update on this?
~Maarten
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
