[PATCH] drm/ast: Don't check new mode if CRTC is being disabled

[Thomas Zimmermann]

Hi

Am 04.05.20 um 17:31 schrieb Daniel Vetter:
> On Mon, May 04, 2020 at 02:07:22PM +0200, Thomas Zimmermann wrote:
>> Hi Emil
>>
>> Am 01.05.20 um 15:20 schrieb Emil Velikov:
>>> Hi Thomas,
>>>
>>> Couple of fly-by ideas/suggestions.
>>>
>>> On Thu, 30 Apr 2020 at 10:13, Thomas Zimmermann <tzimmermann at suse.de> wrote:
>>>>
>>>> Suspending failed because there's no mode if the CRTC is being
>>>> disabled. Early-out in this case. This fixes runtime PM for ast.
>>>>
>>>> Signed-off-by: Thomas Zimmermann <tzimmermann at suse.de>
>>>> ---
>>>>  drivers/gpu/drm/ast/ast_mode.c | 3 +++
>>>>  1 file changed, 3 insertions(+)
>>>>
>>>> diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
>>>> index 7a9f20a2fd303..089b7d9a0cf3f 100644
>>>> --- a/drivers/gpu/drm/ast/ast_mode.c
>>>> +++ b/drivers/gpu/drm/ast/ast_mode.c
>>>> @@ -801,6 +801,9 @@ static int ast_crtc_helper_atomic_check(struct drm_crtc *crtc,
>>>>                 return -EINVAL;
>>> Unrelated:
>>> This feels quite dirty. If AST1180 does not support atomic modeset
>>> simply remove the DRIVER_ATOMIC bit.
>>> You can do that at runtime, via drm_device::driver_features in say,
>>> ast_detect_chip()?
>>
>> The line you commented on dates back to non-atomic modesetting, but I
>> don't know what the story behind AST1180 is. It is explicitly disabled
>> in the list of PCI IDs, but the driver has plenty of code for it. It
>> looks as if the chip can only do pageflipping with a pre-set video mode.
>>
>> As it is right now, the AST1180 code could probably be deleted entirely.
>>
>>>
>>> The drm_driver::driver_features is immutable, or it ought to be.
>>>
>>>>         }
>>>>
>>>> +       if (!state->enable)
>>>> +               return 0; /* no checks required if CRTC is being disabled */
>>>> +
>>> I cannot think of a reason why a driver would need to perform
>>> crtc_atomic_check, if the crtc is being disabled.
>>> Can you spot any? If not, this should be better served in core, which
>>> calls this callback.
>>> Correct?
>> Ast is a bit of a special case, because it tests the incoming mode
>> against a list of re-defined modes. With the crtc being disabled, the
>> incoming mode is 0 in all fields. Obviously that's not a valid mode, and
>> we need that additional test here.
>>
>> In the general case, I'd see 'crtc check' as part of the larger atomic
>> infrastructure. I can imagine that configurations require the CRTC to be
>> enabled before other HW blocks work. So a driver might have a reason to
>> run crtc's check even for disabled crtcs (at least to verify that the
>> crtc is not disabled). I don't think this can be handled in the core easily.
> 
> Jumping out of ->atomic_check callbacks when stuff is all off is fairly
> standard pattern. So much standard that I'm kinda wondering whether we
> shouldn't just make it the default in atomic helpers - so many drivers
> forget to do it and break in funny ways.

If there comes a driver that really must handle the 'disable case' in
its check handler, such a change would be hard to revert. Removing the
check from the DRM core could regress drivers that depend on the new
semantics.

Best regards
Thomas

> -Daniel
> 
>>
>> Best regards
>> Thomas
>>
>>>
>>> HTH
>>> -Emil
>>> _______________________________________________
>>> dri-devel mailing list
>>> dri-devel at lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>>>
>>
>> -- 
>> Thomas Zimmermann
>> Graphics Driver Developer
>> SUSE Software Solutions Germany GmbH
>> Maxfeldstr. 5, 90409 Nürnberg, Germany
>> (HRB 36809, AG Nürnberg)
>> Geschäftsführer: Felix Imendörffer
>>
> 
> 
> 
> 
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> 

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20200506/96b11675/attachment-0001.sig>