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