renesas/master bisection: igt-kms-rockchip.kms_vblank.pipe-A-wait-forked on rk3399-gru-kevin

Michel Dänzer michel.daenzer at mailbox.org
Wed Jan 4 09:11:46 UTC 2023


On 1/4/23 03:11, Brian Norris wrote:
> On Tue, Jan 03, 2023 at 07:04:00PM +0100, Michel Dänzer wrote:
>> On 12/21/22 23:02, Brian Norris wrote:
> 
>>> 3. leave vblank enabled even in the presence of PSR
> 
> I'm leaning toward this.

If this means vblank interrupts will arrive as expected even while in PSR, that may be the ideal solution indeed.


>> 5. Go/stay out of PSR while vblank interrupts are enabled (probably want to make sure vblankoffdelay is set up such that vblank interrupts are disabled ASAP)
> 
> That seems not extremely nice, to waste power. Based on the earlier
> downstream implementation (which left vblank interrupts enabled), I'd
> wager there's a much larger power win from PSR (on the display-transport
> and memory-bandwidth costs), relative to the power cost of vblank
> interrupts.
> 
> Also, messing with vblankoffdelay sounds likely to trigger the races
> mentioned in the drm_vblank.c kerneldoc.

Not sure how likely that is, quite a few drivers are setting dev->vblank_disable_immediate = true.

With that, vblank interrupts should generally be enabled only while there are screen updates as well[0], in which case PSR shouldn't be possible anyway.

[0] There may be user space which uses the vblank ioctls even while there are no screen updates though, which would prevent PSR in this case.


>>> [1] Or is it? I don't really know the DRM_IOCTL_WAIT_VBLANK ABI
>>>     contract in the presence of PSR, but I believe the upstream PSR
>>>     support has always worked this way. I could imagine
>>>     DRM_IOCTL_WAIT_VBLANK users might not love seeing EINVAL here
>>>     though.
>>
>> Yeah, that's pretty likely to cause issues with existing real-world user space.
> 
> OK. Any hints as to what kind of user space uses this?

I don't have any specific example, just thinking about how user space could respond to the vblank ioctls returning an error, and it would seem to be generally either of:

* Just run non-throttled, which might negate any energy savings from PSR
* Fail to work altogether


> I'm in part simply curious, but I'm also wondering what the
> error-handling and reliability (e.g., what if vblanks don't come?)
> expectations might be in practice.

If vblank events never come, user space might freeze.


-- 
Earthling Michel Dänzer            |                  https://redhat.com
Libre software enthusiast          |         Mesa and Xwayland developer



More information about the dri-devel mailing list