06:46tjaalton: eric_engestrom: hi, are you planning to release 25.0.2 today?
06:51K900: Now that Gitlab is back up, may I bump https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33890 :)
06:59mupuf: K900: ci fairy still needs work AFAIK
07:12benjaminl: https://maintenance.gitlab.freedesktop.org/ suggests yes
07:56tzimmermann: what's the status of the gitlab migration? can/shall i send a PR this week?
07:57HdkR: https://maintenance.gitlab.freedesktop.org/ It's moving
07:57HdkR: `Currently planned outage: 2025-03-16 -> 2025-03-22` Outage range hasn't changed
07:58tzimmermann: looks good already
07:59tzimmermann: i guess i can also wait a bit longer. i don't have critical fixes
08:19tomba: I'm a bit confused about the modes in different places. In drm_display_mode we have the normal timings and crtc_* timings. And then we have mode and adjusted_mode. My bridge needs to adjust the input timings, so I think the bridge should do it in atomic_check, and change adjusted_mode->clock. The crtc also needs to change the clock, depending on what clock can actually be achieved. I think crtc's mode_fixup() is the right place (or
08:19tomba: atomic_check?), but it's not clear to me if it should change adjusted_mode->clock or adjusted_mode->crtc_clock. And in atomic check/enable, should the crtc use clock or crtc_clock to set the clock rate.
08:20tomba: In the bridge's atomic_enable, I believe crtc->state->adjusted_mode->crtc_clock should be used (and hope that it's what was requested in bridge's atomic_check)
08:21tomba: Overall I just feel that I'm not sure what specific timing to look at in all these different places, and what to modify if needed. Is there any good example anywhere?
08:26tomba: Also, who's responsible for updating the crtc_* values. I assume the crtc driver needs to do that... in... atomic_check?
08:56eric_engestrom: tjaalton: I'm checking with the gitlab admins to see when it's safe to make the release :)
09:01mripard: tomba: to answer your last question, drm_mode_set_crtcinfo() sets the crtc_* values
09:02mripard: for the rest, adjusted_mode is indeed the one to modify in atomic_check, but it's pretty clunky when multiple components have to modify it
09:02mripard: what are you trying to do?
09:04tomba: mripard: well, for one, I just want to make sure this bridge and crtc driver use the right values. but ultimately the issue here is that the (dsi) bridge has requirements for the incoming pclk, but on the other hand the crtc can't provide just any clock, so it should use clk_round_rate to update the rate (somewhere) to the real one.
09:06tjaalton: eric_engestrom: ack, thanks
09:10eric_engestrom: tjaalton: heard back, it should be fine, so I'll make the release in a few hours (about to be busy for a couple hours) :)
09:11tjaalton: excellent :)
09:14mripard: tomba: I think that's one of the things where bridges in general fall short. We don't have an easy way to align clock rates along devices in DRM, and the extra abstraction provided by bridges make it harder to implement an ad-hoc function
09:14mripard: do you have a specific thread / issue where this is discussed?
09:17tomba: mripard: no, just a local WIP branch. the DSI PLL has a rather coarse grained resolution, and at the moment the driver doesn't support fine tuning the timings based on the pclk-byteclk difference (although even if it did, it could still fail). But, in this particular case, the crtc can provide very exact clock rates, so I think this gets more or less solved for now by just making the bridge ask for a crtc clock that matches the DSI
09:17tomba: clock.
09:18tomba: And I have that working, but I just felt a bit uncomfortable as I wasn't sure if I'm modifying and looking at the right values, from all those different options where we have the mode.
09:20mripard: I've been wondering for a while how we can solve that, we have a similar problem for panels pixel clocks for example.
09:20mripard: but yeah, the framework isn't going to help you there, you're on your own :)
09:23tomba: mripard: thanks, just the answer I wanted! ;)
13:13tzimmermann: sima, airlied, can you please merge last week's PR of drm-misc-next-fixes
13:22tjaalton: eric_engestrom: might be a bit too late, but if 9447de5d could be picked for 25.0 that would help a bit with #12823, the rest hasn't landed in master yet
13:23eric_engestrom: tjaalton: I was about to start, perfect timing ^^
13:23eric_engestrom:looks
13:23tjaalton: nice
13:23eric_engestrom: oh yeah that's a very trivial commit, I'm including it :)
14:01tjaalton: great, one less thing to patch :)
18:24jljusten: eric_engestrom: hey, was 0e648a238e2 ("intel/dev: Add BMG PCI IDs (0xe210, 0xe215, 0xe216)") missed for cherry-picking to 25.0?
19:36mdnavare_: Hi Does anyone know why drm_mode.h has two HDMI types #define DRM_MODE_CONNECTOR_HDMIA 11
19:36mdnavare_: #define DRM_MODE_CONNECTOR_HDMIB 12
19:37eric_engestrom: jljusten: ah sorry about that! I just looked at it, and it has two `backport-to:` lines and there's currently a bug where only the first one applies, and I have a local script that I use as a workaround for now (because the proper fix requires a bunch of rewriting) and I had a bug in that script... so yeah ^^'
19:37eric_engestrom: anyway, it's now in the branch and will be in the next release, 25.0.3 :)
19:43jannau: mdnavare_: https://en.wikipedia.org/wiki/HDMI#Connectors
19:56mdnavare_: Ok great that helps thank you so much @jannau
20:29jljusten: eric_engestrom: Yeah, I was trying to figure out what was preferred. I would have preferred "24.3, 25.0", but for some reason I thought maybe two lines were preferred by the script.
20:32jljusten: eric_engestrom: https://docs.mesa3d.org/submittingpatches.html#the-stable-tag says "Multiple Backport-to: lines are allowed.", but doesn't mention including multiple versions on one line, so I thought multiple lines were preferred.
20:33jljusten: but, why not just make the preferred method be a single Backport-to line with multiple versions?