05:31 MoeIcenowy: wens: are you going to refresh mt8173 gpu patchset?
06:20 wens: MoeIcenowy: does it not apply now?
06:20 wens: if support for that old core isn't going to be added, respinning the series isn't going to help
06:23 MoeIcenowy: wens: it does not apply well
06:23 MoeIcenowy: mainly because the binding changed
06:23 MoeIcenowy: (and someone even added another gx6250 for renesas
06:24 MoeIcenowy: and the driver is now matching a generic "img,img-rogue" compatible, which should remove the need of driver-specific patch in that patchset
06:25 MoeIcenowy: I am trying to rebase and test it
06:25 MoeIcenowy: kernel build passed, and then I found `depthchargectl` boom...
06:26 MoeIcenowy: (because of updating python
06:30 wens: oh, I have a script that takes the FIT image from the kernel, signs it and writes to disk in the B partition, and runs cgpt to update the flags
06:31 wens: anyway, I can take a look
06:31 wens: but I assume on the userspace side nothing has changed
06:40 MoeIcenowy: well I think more BRNs will be reported
06:40 MoeIcenowy: but things at least run to some extent
06:58 MoeIcenowy: wens: I delegated all my knowledge of depthcharge boot partition to depthcharge-tools
06:58 MoeIcenowy: and then I found when it's broken by python upgrade I can do nothing :-(
07:40 MoeIcenowy: wens: hacked up depthchargectl, and got GPU FW up
07:54 MoeIcenowy: got glmark2 running on Zink on PowerVR (with my testing branch with Mesa !38810)
07:54 MoeIcenowy: (on MT8173
07:56 MoeIcenowy: VenomousSteam81: wens: I rebased the 8173 gpu patchset onto v7.0-rc3: https://github.com/Icenowy/linux/tree/v7.0-mt8173-pvr
07:56 MoeIcenowy: commits w/ My SoB is changed by me
07:57 tomba: Hi DRM maintainers, pinging again on https://lore.kernel.org/all/20260128-xilinx-formats-v8-0-9ea8adb70269%40ideasonboard.com/ . Can I get an ack or have it merged? Or should I just send a pull req?
07:58 tzimmermann: tomba, that link says "message id not found"
08:00 MoeIcenowy: VenomousSteam81: wens: oh I forgot to say drm/imagination now has a GPU model number allowlist module paremeter, powervr.exp_hw_support=1 will be needed for 8173
08:00 tomba: tzimmermann: huh.. hmm... is it that %40 in the middle... It's a direct copy paste from my firefox. the message id is "20260128-xilinx-formats-v8-0-9ea8adb70269@ideasonboard.com"
08:01 tzimmermann: right. works now
08:01 tomba: tzimmermann: interesting. I can't open the link from irc either, as somehow the %40 gets converted to %2540 when I click the link.
08:02 emersion: works for me
08:02 tzimmermann: same here. i replaced %2540 with @
08:02 tomba: tzimmermann: eh... copy pasting the link from irc (hexchat) works. clicking the link on hexchat doesn't. hexchat bug? which client are you using?
08:02 emersion: do you have maintainer reviews for the xlnx parts?
08:03 tzimmermann: hexchat + firefox
08:03 tomba: emersion: I'm a maintainer, but Laurent has Rb'd the series who is also a maintainer. so yes.
08:04 tzimmermann: when addig a new DRM format constant. how does one obtain the 4-character code?
08:04 emersion: roll a dice
08:05 emersion: I can try to have a look at the core patches (I'm not a maintainer, but I'm a drm-misc committer)
08:05 tzimmermann: emersion, so everyone's free to pick a sequence?
08:06 emersion: yeah, we try to keep things consistent with existing codes but it's pretty much arbitrary
08:07 tzimmermann: and these codes are drm-only then? there's no other software/standard/community to consider?
08:08 emersion: correct
08:08 tzimmermann: emersion, thanks
08:09 tzimmermann: mripard, mlankhorst, can we get https://lore.kernel.org/dri-devel/20260309081503.67123-1-tzimmermann@suse.de/ into drm-misc-fixes quickly? so that mail stop bouncing?
08:10 tomba: yes, v4l2 has different codes. so e.g. libcamera has its list of format infos, which contains separate fourcc codes for drm and v4l2.
08:12 tzimmermann: i see. i always wonderde how that is being handled
08:14 mripard: tzimmermann: yeah, ack
08:18 glehmann: dj-death: load_global_constant can be an access flag, and effectively already is the same as ACCESS_NON_WRITEABLE | ACCESS_CAN_REORDER
08:19 glehmann: imo it should be deleted, but nir maintenance is always annoying work
08:31 biju: mripard: Can we merge https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/fb797a70108f3fda83fde6dea30bee4be7d5df8b to drm-misc-next, it is landed in 7.0.rc3, linux-next but not in drm-misc-next?
08:31 tzimmermann: thanks, mripard
08:37 mripard: biju: how can it be in 7.0 and linux-next but not drm-misc?
08:39 wens: mripard: it's in drm-misc-fixes
08:39 wens: a merge of drm-misc-fixes into drm-misc-next is needed
08:42 biju: mripard: The patch was applied to drm-misc-fixes which landed in linux-next, your pull request made it to 7.0.rc3.
08:43 biju: as wens said still a merge of drm-misc-fixes into drm-misc-next is needed
09:07 mripard: airlied: ^ can you merge 7.0-rc3 in drm-next so we can backmerge drm-next ?
09:55 mripard: sima: hi, can you merge 7.0-rc3 in drm-next so we can backmerge drm-next ? biju would need it for rcar
10:00 sima: mripard, there's no rcar chances in -rc3 since -rc2 (which is already in drm-next)?
10:01 sima: and otherwise I'm only spotting ttm changes and a kerneldoc fix
10:01 sima: so probably too sleepy still, but I'm a bit confused
10:02 sima: if it's something outside of drm I'd like to note that
10:08 mripard: sima: sorry, not rcar but https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/fb797a70108f3fda83fde6dea30bee4be7d5df8b
10:09 mripard: aka, the other renesas driver
10:09 sima: ah yes, that makes sense
10:11 sima: hm git rerere failed real bad
10:47 sima: mripard, done
13:58 mareko: does Mesa allow code using the Apache 2.0 license?
14:19 glehmann: I think all new code should be MIT?
14:36 mareko: we some Apache 2.0 code in Mesa
15:44 glehmann: mareko: can you take a quick look at the (new) first commit in https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40323 please?