08:09 mlankhorst: drm-tip is broken?
08:09 mlankhorst: drivers/gpu/drm/panel/panel-auo-a030jtn01.c:203:9: error: ‘panel’ undeclared (first use in this function)
08:12 tzimmermann: mlankhorst, a number of panel drivers appear to have build issues
08:13 tzimmermann: apparently came with v6.15-rc1
08:13 tzimmermann: maybe an incorrect merge
08:17 mlankhorst: Yeah, did someone attempt to fix it yet? it's breaking CI
08:21 tzimmermann: mlankhorst: there's "drm/panel: Use refcounted allocation in place of devm_kzalloc()" on dri-devel
08:21 tzimmermann: with some discussion
08:41 jani: ugh, at least three patches in the series with build failures, and nobody built it once before it was merged? not great
08:42 jani: not to mention testing
08:52 Lynne: is there any way to force or at least coerce rdna3 into buffering BDA loads?
08:53 Lynne: most of the time in my shader is spent simply waiting for the buffer load to finish, according to rgp
08:55 Lynne: I can load everything I need upfront in a 32-byte array, but then nvidia perf almost halves as their hardware seems to cache just fine
09:25 gnuiyl: mripard: Anything more needed to do for https://patchwork.freedesktop.org/series/135786/#rev8 ? If no, can you please help push patch 1-13?
09:37 jani: jfalempe: tzimmermann: saw the #if defined discussion from yesterday. maybe consider using IS_ENABLED() to simplify. #if IS_ENABLED(CONFIG_OF) && (IS_ENABLED(CONFIG_COMMON_CLK) || IS_ENABLED(CONFIG_REGULARTOR))
09:38 jani: I'd go so far as to say checks for CONFIG_ macros should *always* use IS_ENABLED() instead of #ifdef or #if defined
10:23 kj2: I was working on a Crucible benchmark but started hitting linking errors like `crtstuff.c:(.text+0x76): relocation truncated to fit: R_X86_64_PC32 against `.bss'` where I think it's starting to hit the limit of the distance between some sections
10:25 kj2: All tests and benchmarks seems to be linked together into the single executable so I was thinking of maybe separating things. Thought I'd ask here before trying to do that in case people have objections
10:46 javierm: tzimmermann: I just reviewed the Sitronix ST7571 driver. Please chime in if I said anything that's wrong there
10:48 tzimmermann: didn'i ack it already :/
10:49 tzimmermann: javierm ^
10:49 javierm: tzimmermann: yes, you did and that's why I'm pointing it out
10:49 tzimmermann: i cannot say much about the bindings, but the other pathces have my r-b
10:51 javierm: tzimmermann: it's OK if you want to merge it as as. But IMO it needs some changes
10:51 javierm: *as is
10:52 tzimmermann: javierm, thanks for the additional reivew. those are quite a number of good points
10:53 javierm: tzimmermann: you are welcome
10:54 javierm: tzimmermann: the only comment that I was not 100% sure was the last one about the lifecycle
10:55 javierm: but IIRC from our previous conversations and posted fixes, we need both a .remove and .shutdown handlers
10:56 javierm: to do drm_dev_unplug() + drm_atomic_helper_shutdown() and drm_atomic_helper_shutdown() respectively
11:02 tzimmermann: javierm, thanks for the efidrm module review BTW
11:08 javierm: tzimmermann: yw
11:13 tzimmermann: the recent change to ssh.gitlab has destroyed my setup
11:14 tzimmermann: so i ran 'dim setup' to start anew
11:14 tzimmermann: doing 'dim rebuild-tip' returns 'Branch setup for the integration repo is borked'
11:14 tzimmermann: any ideas?
12:16 jani: auch
12:16 jani: the problem with 'dim setup' is that people run it maybe once per several years. there's no incentive to polish it
12:18 jani: tzimmermann: nightly.conf needs an update to ssh URLs, and I guess it also needs a mechanism to migrate
12:23 jani: I wonder if this could Just Work http://paste.debian.net/1368248/
12:32 jani: sadly, no. but I also don't understand why it isn't working :(
12:32 jani: Host gitlab.freedesktop.org
12:32 jani: Hostname ssh.gitlab.freedesktop.org
12:32 jani: that's what I added to my .ssh/config and moved on, but obviously dim setup should do better
12:46 tzimmermann: jani, thanks for the help. i'll see what i can do
12:47 jani: tzimmermann: I wonder why we use the plain git@gitlab.freedesktop.org:drm/tip.git style at all. IIUC that could be ssh://git@gitlab.freedesktop.org/drm/tip.git with the protocol clearly stated
12:48 jani: I've also been getting sporadic permission denied errors from gitlab recently
13:02 demarchi: tzimmermann: that was fixed last week
13:03 demarchi: tzimmermann: do you have latest maintainer-tools checkout?
13:04 demarchi: tzimmermann: oops, it helps if I actually merge the MR
13:04 demarchi: https://gitlab.freedesktop.org/drm/maintainer-tools/-/merge_requests/75
13:05 demarchi: just did. Quick local fix if you don't want to setup it again: cd drm-tip; git checkout -B drm-tip drm-tip/drm-tip
13:09 jani: demarchi: that's not enough though because of the SSH url change
13:10 demarchi: jani: it is if you also added the .ssh/config change
13:10 demarchi: s/change/setting
13:10 tzimmermann: demarchi, thanks. i'll try that
13:10 jani: demarchi: yes, with that it is, but arguably we shouldn't rely on that
13:10 tzimmermann: i do have the workaround for .ssh/config BTW.
13:11 jani: demarchi: and we had people internally who saw the issues with ssh change, tried dim setup, and that didn't fix it
13:11 demarchi: jani: agreed... I was going to look on the nightly.conf yesterday, but got busy with other stuff
13:11 jfalempe: jani: in the end, tzimmermann found a way to remove this code, so no need for complex #if this time.
13:11 jani: jfalempe: oh good
13:12 demarchi: jani: looking at your diff... it seems it would work
13:12 demarchi: jani: did you try that already?
13:12 jani: demarchi: I tried it and it changed stuff but it didn't work
13:13 jani: I got distracted, dunno what gives
13:13 demarchi: `git remove -v` should answer if it changed it all
13:14 tzimmermann: demarchi, jani, manually setting drm-tip did the job. thanks!
13:17 demarchi: jani: we could move the ssh:// to be the first, so we have this prompt:
13:17 demarchi: drm-rerere $ dim ub
13:17 demarchi: Update drm to new ssh://git@ssh.gitlab.freedesktop.org/drm/kernel.git? (y/N)
13:18 jani: right
13:18 demarchi: maybe also remove the one with no protocol in it?
13:19 demarchi: the only possible breakage I may think.... it may break people's setup if they have a insteadOf in git config
13:25 demarchi: jani: on top of your diff... https://dpaste.com/3FAJZTWXQ
13:25 demarchi: that worked for me
13:30 jani: demarchi: that basically drops all git@ssh.gitlab.freedesktop.org:drm/tip.git style urls, but I guess they should still work, and if the user has them configured, I think it's going to break
13:31 demarchi: it still has the ssh://git@ style as the first one
13:31 jani: by providing a lot of flexibility we've created a monster
13:31 jani: demarchi: but does dim take that into account when trying to find the remote name based on the URL?
13:32 demarchi: jani: I always thought "why are we not using google's repo" to sync the repos
13:32 demarchi: jani: yes, it's in the old_urls
13:32 demarchi: if the remote is configured with anything that matches an entry in the old_urls array, it will suggest to change to the first from the current array
13:32 jani: demarchi: d'oh, too many levels of abstraction with this diff on top of diff :)
13:33 jani: demarchi: want to send a patch? I don't think we do MR's for drm-rerere
13:33 demarchi: the only breakage I can imagine is if people have git's insteadOf entries in their conf and match explicitly on git@, without ssh://
13:34 demarchi: jani: but we could leave the git@ without protocol too if you think it's risky
13:34 jani: nah, break it and require people to put in the protocl ;)
13:34 jani: *if* it even breaks
13:34 demarchi: it's not very common to see people using insteadOf
13:35 demarchi: I actually used sometimes to redirect git:// to https://, because of silly company proxies
13:36 demarchi: jani: do I add your s-o-b too?
13:36 jani: demarchi: I don't care
13:36 jani: not exactly copyright worthy either
13:47 demarchi: jani: alright, done
14:00 jani: demarchi: thanks! I also had a lightbulb moment and figured out what my issue was
14:02 jani: I had the IdentityFile set for gitlab.freedesktop.org but not for ssh.gitlab.freedesktop.org, so it ended up using the wrong key
14:12 demarchi: jani: yeah... i use *.gitlab.freedesktop.org
14:13 demarchi: in my .ssh/config to set the username and identityfile
14:19 javierm: tzimmermann: as mentioned before, I may be wrong with the .remove and .shutdown i2c driver callbacks
14:19 javierm: if that's the case, I should fix my drivers because I've both currently and calling the aformentioned drm helpers
14:20 javierm: tzimmermann: it would be great if you can comment on the thread since you are quite familiar with these objects lifecycles
14:49 tzimmermann: javierm, i think it only needs the unplug call
14:49 tzimmermann: after that, the shutdown doesn't do anything
14:50 tzimmermann: technically it's then disabled, but that appears pointless
14:51 tzimmermann: for shutdown, it might do shutdown, i think
17:48 demarchi: jani: however the fix to the nightly.conf assumes people can still fetch drm-rerere
17:48 demarchi: otherwise they will simply see it block
17:49 jani: demarchi: true, but same is true for updating maintainer-tools
17:49 demarchi: yep
17:50 jani: mmh, okay, some people might have maintainer tools cloned via https
17:51 jani: but I don't think we can reasonably automate everything
17:51 demarchi: jani: I think moving all the repos to be via https by default would make sense
17:52 jani: how does that work with pushing nowadays?
17:52 demarchi: because 1) it's possible to setup push via https and 2) most people set up the environment before becoming a committer
17:55 demarchi: jani: it's on gitlab settings
17:55 demarchi: I think here... https://gitlab.freedesktop.org/-/user_settings/personal_access_tokens
19:24 dj-death: alyssa: you didn't find any nir_lower_tex shortcomings then?
19:24 dj-death: alyssa: for maintenance8
19:26 alyssa: dj-death: not for agx anyway
19:26 alyssa: but I see what your issue is, I'm just spread very thin right now
19:38 dj-death: alyssa: no worries
19:38 dj-death: we're likely the only ones in that situation I think