10:10lucaceresoli: lumag: if you manage to have a look at https://lore.kernel.org/lkml/20260507-drm-bridge-alloc-getput-panel_or_bridge-v5-3-472b913b5cb7@bootlin.com/ 10:11lucaceresoli: it would be great if you could comment on the remark in the sashiko review: "Could the assignment of hdmi->next_bridge happen too late here?"
10:11lucaceresoli: https://sashiko.dev/#/patchset/20260507-drm-bridge-alloc-getput-panel_or_bridge-v5-0-472b913b5cb7%40bootlin.com 10:12lucaceresoli: The lifetime of the involved components is not clear to me, so I cannot say whether the issue pointed by sashiko is valid or not
12:51tzimmermann: why do we still have DRM_IOCTL_WAIT_VBLANK ? isn't that only for user-space drivers?
13:03MrCooper: no
13:04MrCooper: it's there because it's used
13:09tzimmermann: MrCooper. sure. i'm just surprised
13:09MrCooper: why? :)
13:10tzimmermann: i'd expect userspace to leave vblank sync entirely to the kernel. userspace would only send new page flips inregular intervals
13:14MrCooper: tzimmermann: it's needed to know the latest vblank timings before doing a flip
13:15MrCooper: e.g. after an idle period
13:16MrCooper: the longer since the last flip, the less accurate extrapolation based on refresh rate becomes
13:17tzimmermann: ok. i thought this was entirely done with events like DRM_EVENT_VBLANK and DRM_EVENT_PAGE_FLIP_COMPLETE
13:17MrCooper: DRM_IOCTL_WAIT_VBLANK is what triggers DRM_EVENT_VBLANK
13:18tzimmermann: oh, ok
13:18MrCooper: what I described above works without events or blocking though, the ioctl can directly return the latest timings
13:20tzimmermann: that's what happens when drm_wait_vblank_is_query() == true in the kernel?
13:25MrCooper: yes
13:27tzimmermann: oh, makes sense.
13:27tzimmermann: thanks
13:33MrCooper: no worries
13:35MrCooper: (if anyone wonders about the weird DRM_IOCTL_WAIT_VBLANK UAPI, 24-years-ago me was just learning about that stuff :)
13:38tzimmermann: sima, i've investigated the vblank-timers-for-everyone-by-default idea, but it turns out to be quite invasive. yet you wanted a flag that disables the vblank ioctl, right? that should be considerably easier
13:38sima: tzimmermann, I'm honestly not sure what's best here ...
13:38sima: it's just that exposing the vblank ioctl when we fake this stuff entirely feels icky
13:39sima: least because there's big drivers like agx and nvidia blob that also don't expose the vblank stuff
13:42tzimmermann: i see. it's not yet too late to disable the vblank ioctl for fake vblanks, I think. but i wonder if some compositors would fall back to the old behavior of spiking cpu loads
13:42sima: so userspace should be able to cope
13:43sima: tzimmermann, well if they do, then they'll also fail on the nvidia blob, which a lot more people seem to care about
13:43sima: but yeah, really not sure
13:59MrCooper: tzimmermann: the vblank ioctls shouldn't matter for spiking CPU loads, rather it matters that atomic commits don't complete at a higher rate than the CRTC mode refresh rate
14:00tzimmermann: MrCooper, ok
14:01tzimmermann: for reference, we've had vblank timers for a long time in vmwgfx and amdgpu already
14:02tzimmermann: i'll investigate using a simple flag for disabling the ioctl. with that in place, we can use vblank timers where necessary without commiting to a uapi change
15:12MoeIcenowy: tzimmermann: saying about DRM_IOCTL_WAIT_VBLANK, the implementation of that ioctl in drm_fb_helper is hardcoding to wait on crtc0
15:13MoeIcenowy: and you duplicated this hardcode in drm_fb_helper_fb_dirty(), which isn't a rarely-used codepath...
15:13MoeIcenowy: it seems that this is why I got WARN_ON on drm/loongson in my setup (because the internal LCD of my 3A4000+7A1000 laptop is on crtc 1)