00:22 KarenTheDorf: Hazematman: I went back to before that merge request and same behaviour on resize.
00:23 KarenTheDorf: Also on latest main branch, so I'll file it as an issue
07:02 sima: tnt, I guess we need to allocate the tile64 modifier to sort this out?
07:22 mripard: lumag: the fwnode reference count discussion is kind of separate to me, so you can merge the whole thing
07:23 tnt: sima: yes, that'd be the first step :)
07:23 lumag: mripard, ack. My plan is to get 1-3 into drm-misc-next, then ask robclark to merge it into msm-next and then push patches on top of it to msm-next. This way I can send patches for other HDMI bridges without waiting for a backmerge.
07:24 tnt: ATM it seems that Tile64 is rarely used but if https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29244 is merged, then it becomes the default for Arc so anything exporting dmabuf will end up with that format and the modifier should reflect that.
07:24 lumag: mripard, for fwnode I understand your concerns, but I don't see a good resultion. Maybe i915 people can look at reworking their code.
07:25 mripard: lumag: sounds like a plan
07:26 mripard: and yeah, I think we'll need to, I was hoping for Hans to reply
08:15 mripard: lumag: \o/
08:15 mripard: thanks a lot for that work
08:16 lumag: mripard, n/p, it was a pleasure. It helped me to clean up the driver.
08:16 lumag: So, kudos goes to you for the framework code.
08:49 sima: mripard, devm_ for a struct drm_bridge sounds extremely wrong to me, but I guess I'm not going to dig into this
08:50 sima: probably should be drmm for static bridges, and then when we start hotplugging I'll just run away screaming :-P
08:50 mripard: sima: I would agree, but what are you referring to ? :)
08:50 sima: oh just the bugfix you've merged recently for panel bridge
08:53 mripard: which commit id?
08:55 mripard: panels are a shitshow here anyway, since they get registered without access to the drm_device so you can't use anything but devm_* allocations (or kmalloc in probe, kfree in remove, which is pretty much the same)
08:56 sima: uh that sounds like we should refcount them ...
08:58 mripard: yeah, it would be a good idea indeed
08:58 sima: mripard, [PATCH] drm/bridge/panel: Fix runtime warning on panel bridge release
08:59 sima: mripard, yeah essentially I guess both drm_bridge and drm_panel really should have been full blown struct dev things
08:59 sima: but then we'd probably never have gotten anywhere
09:23 mripard: sima: by full blown struct dev thing you mean being part of their own bus?
09:24 sima: hm maybe not
09:24 mripard: because I think with refcounting we can have a pretty neat solution without too much trouble
09:24 sima: but it does start to smell like reinventing parts of the driver model a bit ...
09:24 sima: yeah kref is defo the incremental thing
09:25 mripard: in drm_panel_init, init the reference count, put it back at remove, and of_drm_find_panel takes one
09:45 Hazematman: <KarenTheDorf> "Also on latest main branch, so I..." <- Thanks! If it didn't happen after you reverted my change I'm not quite sure of the cause. I'll check out the issue later though with all the details and I can do some debugging to see if I have any other ideas about what could be wrong
15:11 sima: mripard, just realized that large chunks of the bridge/panel lifetime issues should be sorted with device_link_add
15:11 sima: which we still don't have
15:20 mripard: sima: I was wondering if we don't miss a module_get somewhere
15:20 mripard: like, if you remove the panel module, then what?
15:20 sima: mripard, module_get only ensures the binary is around
15:20 sima: device_link_add ensures the actual driver sticks around
15:20 sima: so much better, because it also covers any other reason for that driver unbinding
15:21 sima: not just module unload
15:21 mripard: does it?
15:22 mripard: I thought it was just about ordering?
15:22 sima: go into the driver's sysfs, unbind it manually
15:22 sima: need to set the right flags iirc
15:22 sima: so that any unbind of that driver forces all dependent drivers to get unloaded first
15:23 mripard: I think it's just wiser to step away from that discussion and play dead :D
15:23 mripard: looks like a whole tank of worms
15:24 sima: understatement
15:25 sima: but the problem doesn't become easier if we hand roll a shitty ill-specified version of these in bridge/panel framework
15:25 sima: so for now the status quo is that some drivers put this in their driver code, making a subsytem wide conversion even trickier
15:26 sima: plus there's still drivers using at least bridges with component.c, which handles this but differently
15:26 sima: or well, part of the device_link problem space
15:38 lumag: sima, we have been hitting the bridge disappearance for a few cycles. It's pretty easy to hit it if there is a significant amount of time between probe() and attach().
15:39 sima: lumag, oh on loading? that's more surprising ...
16:00 lumag: sima: yes, on load / probe. Especially if the bridge is registered, other driver gets a reference, then a bridge disappears thanks to -EPROBE_DEFER
16:02 sima: ugh
16:02 sima: lumag, so that's for bridge drivers which register the bridge, but then have further stuff which might cause an abort of the probe?
16:04 sima: device_link should help, but only against a remove, not an aborted probe of the bridge driver
16:04 lumag: sima, that's how we hit that. But the general feeling is that the whole bridge-to-bridge interface might be improved
16:04 sima: yeah if you register a bridge and then abort, there's a race
16:05 sima: and device_link can't plug that
16:53 conchuod: If Tomeu Vizoso is in here, your email address from the rockchip npu series is bouncing.
16:54 conchuod: "tomeu.vizoso@tomeuvizoso.net: The email account that you tried to reach does not exist"
17:07 tomeu: yeah, I managed to misstype my own email...
21:25 karolherbst: did anybody here ever looked into implementing PIPE_CAP_QUERY_TIMESTAMP for v3d?
23:20 zmike: tarceri: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6691