07:24 MrCooper: DemiMarie: AFAIK pinning VRAM for P2PDMA should work
07:24 DemiMarie: MrCooper: even though it is a FOLL_LONGTERM pin?
07:25 MrCooper: don't know anything about that, just from a dma-buf & DRM PoV it should work, AMD have P2PDMA working (between GPUs)
07:30 DemiMarie: with upstream drivers?
07:31 MrCooper: yep
07:32 DemiMarie: nice
07:34 DemiMarie: The reason I am so surprised is that if it worked with RDMA, I would expect that it would be much easier to support Xen than it actually has been.
07:42 MrCooper: I don't know if it works with RDMA specifically
07:58 DemiMarie: Ack
07:58 DemiMarie: Xen has the annoying problem that it currently has no MMU notifier integration
08:31 pepp: DemiMarie: Xen's main problem is the lack of MMU notifier indeed
08:32 DemiMarie: pepp: at Xen Project Summit 2024, one of the Xen maintainers gave an ACK to implementing that, so patches that add MMU notifier support should be upstreamable
08:33 DemiMarie: Hypervisor changes are required but should also be upstreamable.
08:33 pepp: DemiMarie: yep
08:36 DemiMarie: pepp: anywhere I can follow work being done?
08:37 MrCooper: pepp: out of curiosity, do you have P2PDMA working with RDMA?
08:37 pepp: DemiMarie: for Xen? I don't think patches were sent upstream yet, but I'm not working on this
08:39 DemiMarie: pepp: I'll take WIP patches right now. Turns out that Wayland passthrough needs this, even with software rendering.
08:40 pepp: MrCooper: sorry, I'm not familiar with RDMA
08:45 pepp: DemiMarie: as I said, I'm not working on Xen patches... plus I'm not sure what you mean by "Wayland passthrough needs this"?
08:46 DemiMarie: pepp: crosvm supports guests connecting to a Wayland compositor on the host. This requires blob resources to be able to render anything.
08:47 DemiMarie: pepp: I see. I was not sure what you meant by “this”.
08:51 pepp: unrelated topic: would non-amdgpu drivers be interested in adding a new drm_ioctl_flags indicating "this ioctl doesn't use the GPU"?
08:51 pepp: the purpose is: if the GPU is not used, then no need to resume it if it's suspended.
08:52 pepp: (https://lists.freedesktop.org/archives/amd-gfx/2024-June/110110.html for context)
09:16 DemiMarie: Less power consumption is always nice
09:55 MrCooper: yep, and no multi-second delay when starting apps which don't actually need a secondary GPU
10:45 tzimmermann: javierm, hi. take a look at this patch: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8084a5b589299bd74b114d894e214a2dd4879c96
10:55 javierm: tzimmermann: I'm looking at now, the efifb_fix.smem_start |= ext_lfb_base part is covered by efifb_overlaps_pci_range()
10:56 javierm: the efifb_fix.smem_start = bar_resource->start + bar_offset I don't see it being handled by sysfb_efi
10:56 tzimmermann: javierm, the code i removed stored a pci_dev in the variable efifb_pci_dev
10:56 tzimmermann: and later uses it
10:56 tzimmermann: but it does not hold a reference to that instance
10:56 tzimmermann: i.e., get_device()
10:57 tzimmermann: in priciple, the pci dev could have been removed and the pointer is then dangling
10:58 tzimmermann: i assume this never happens because all this happens during boot, when devices are not hot-unplugged
10:58 tzimmermann: i reimplemented that logic in generic screen_info files in https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=78aa89d1dfba1e3cf4a2e053afa3b4c4ec622371
10:59 tzimmermann: unfortunately, i took the code at face value and didn't add proper ref counting either
10:59 javierm: tzimmermann: oh, I see
10:59 tzimmermann: should we add this?
11:04 javierm: tzimmermann: and when the put_device() would happen?
11:05 tzimmermann: the screen_info code tracks the device. the sysfb code later calls screen_info_apply_fixups() to update the global screen_info from the tracked data. thats where the put_device() would happen
11:06 javierm: tzimmermann: right. Yes, that makes sense to me
11:06 tzimmermann: and the whole tracking code is only required by sysfb.c. so the tracking code would be moved to sysfb. so when there's a get_device() there's also a put_device()
11:07 tzimmermann: and if sysfb has been disabled, no tracking is required anyway (hence no get/put pair)
11:07 javierm: tzimmermann: yeah, agreed
11:07 tzimmermann: ok, great. i'll prepare a patch
11:08 javierm: tzimmermann: great, thanks!
15:44 jhugo: sima: airlied Would like to bring your attention to https://lore.kernel.org/all/6f59552d-d7a3-5e05-3465-e707c1b7eaf2@quicinc.com/ which is discussing moving a misc driver to accel
15:45 sima: jhugo, eh fastrpc is grandfathered in and I kinda don't want to look at it
15:46 sima: the current driver at least
15:46 jhugo: sima: disappointing, but fair.
15:46 sima: jhugo, pick the battles and all that
15:46 sima: but very much appreciated you bringing up accel, but maybe more a long-term thing
15:47 sima: and yeah, fastrpc is one of the reasons why I've added a dma_buf regex match to MAINTAINERS
15:47 sima: but it slipped through, can't really undo it
15:47 sima: hence why I'm a bit "it is what it is" here
15:47 sima: jhugo, if you think it's useful, I can reply on the thread though
15:47 jhugo: sima: True. Maybe a short reply saying that you don't expect it to move today, but would like to see it move in that direction?
15:48 sima: will do
15:48 javierm: sima: I've a locking question and unfortunately I don't who else besides you could ask :)
15:49 sima: bring it on
15:49 javierm: sima: https://lists.freedesktop.org/archives/dri-devel/2024-June/459121.html
15:49 sima: I think the brain is back to at least semi-working :-P
15:49 javierm: :)
15:49 javierm: sima: am I correct on what I said there ?
15:50 javierm: mixing regmap, DRM and panic handling locking made my head explode but I know that you will have the correct answer
15:50 jhugo: sima: Thanks. I think that will help focus the current thread to an immediate resolution
15:54 javierm: sima: hmm, although I'm probably missing drm_dev_{enter,exit}() in the flush panic handlers
15:54 sima: javierm, raw spinlock isn't good enough for panic
15:54 sima: unless you trylock
15:55 sima: hm
15:55 sima: yeah, only trylock of raw spinlock, everything else is not allowed
15:59 javierm: sima: Ok. And for normal operation, do I need to keep the regmap lock?
15:59 javierm: I don't think so since the DRM core will already handle the sync for the KMS objects right ?
16:00 javierm: sima: because if that's the case, then I could just disable it and on DRM panic there won't be any lock tried to be held
16:04 sima: javierm, maybe
16:04 sima: like I don't know what you're all protecting with that regmap lock
16:05 baltmansuite: in reality only mutual exclusion or mutual inclusion ways are done with the access indirection, that requires the least of states, so addition becomes every power where the bits are both in is squared, so 73 in on both addition operands means it's answer is 74, and the non common value gets just added to it, but with subtract common part is zero and non-common parts smaller value gets.
16:05 baltmansuite: subtracted from bigger, i remember it was taught in secondary school logics subjects. Hence there is different polderan access indirection table for subtract, 128-129=-1 128-64=64 129-129=0 and 129-64=65, only 64's need to get eliminated. That works easy. Now there is 65 accesses done instead of 64. so there is 64 128 192...64*64 in first bank all of those values yielding zero, and 65 66
16:05 baltmansuite: 67 68...., so access is asymmetric we recap how polderan worked now, it puts index+value+2*distancefrom_const to subtrahand and , the access number times constant to the minuend, ah fuckers would not understand anyhow i code it myself, you are just trashcoders, it's immense trash what you do, such pigs should be cooked into meat and fed to dogs for example DemiMarie's pork has excess
16:05 baltmansuite: fat and poison in it. It munches big Macs behind qubeos computer, and releases excrements to the channel, absolute cryptic nonsense.
16:05 javierm: sima: the regmap core protects the register map basically, but I believe that is mostly useful if the regmap is shared across drivers
16:06 javierm: sima: let's say a MFD driver (for a PMIC or whatever) that defines the regmap and passes it to both a regulator and RTC drivers
16:06 javierm: this is pretty common when one have a multi-function IP block where the same register map needs to be shared by different drivers
16:07 javierm: sima: thanks, I'll ask broonie. Too many subsystems and locks involved for my Friday evening :)
16:14 sima: javierm, I guess it also depends upon how you get at your registers
16:15 sima: like mmio really shouldn't need any locking
16:15 sima: but if you have anything where you need more, it gets funny
16:16 sima: like if your regmap is behind an i2c, you pretty much can't do panic handling
16:16 sima: at least until i2c has learned about panic locking with a raw spinlock
16:17 sima: javierm, some git grep says these are either behind i2c or spi
16:17 sima: so ... not yet ready for panic at a rather fundamental level I think
16:17 sima: iirc those buses also have uapi interfaces, so really can't just chug the locking and yolo
16:23 javierm: sima: but even the regmap lock won't protect the device register from concurrent accesses if someone has both a kernel and user-space driver for the same I2C device
16:23 sima: javierm, yeah but there's also i2c locking
16:23 javierm: sima: that serialization should be handled by the I2C core
16:23 sima: so if you nuke the regmap one, you'll still splat :-)
16:24 javierm: sima: oh, yes. I was just talking about the regmap lock
16:24 sima: because i2c has that locking
16:24 javierm: sima: need to then look at the other layers of the onion :)
16:24 sima: what you need is a raw spinlock in the lowest i2c level to protect against the panic case
16:24 sima: which is uber fun if you're i2c buses are nesting
16:24 sima: also, you can only have 1 raw spinlocks in our entire regmap chain
16:25 sima: and then you need special panic code which a) takes that raw spinlock b) does no other locking at all
16:25 sima: your looking at a cross-subsystem deep locking drilling exercise here, I'm afraid
16:26 sima: panic handling is really, really hard
16:26 javierm: sima: leaving the DRM panic patch/discussion aside, I believe that I could just disable the regmap locking safely since is not really needed
16:26 sima: yeah that might be
16:26 javierm: sima: in other words, there can't be concurrect calls to the struct drm_plane_funcs .update_plane handlers for the same plane right ?
16:26 sima: nope
16:27 javierm: sima: awesome. I'll disable that then
16:27 javierm: sima: but I'll just park the DRM panic patch then, until I understand how the locking for I2C and SPI core works for the IRQ context case (and if is even possible)
16:28 sima: javierm, you need nmi context for panic
16:28 sima: irq isn't enough
16:28 javierm: sima: right
16:28 javierm: now I'm surprised that the DRM panic patch even works on this driver :)
16:29 Calandracas: anybody know the status of asahi in upstream mesa? this suggests that only m1 is currently supported: https://docs.mesa3d.org/drivers/asahi.html
16:29 javierm: sima: thanks again for your insights
16:30 sima: javierm, locking can work surprisingly well, until you run out of luck
16:30 javierm: sima: yeah
16:30 sima: javierm, but testing it with debugfs should splat in lockdep, because you nest non-rawspinlock within a raw spinlock
16:31 sima: would be nice if we could annotate it somehow that even raw_spinlock would splat, so that you're really only limited to raw_spintrylock
16:37 sima: javierm, dropped a summary of our discussion onto dri-devel
16:38 javierm: sima: perfect, I really appreciate that!
16:38 javierm: it was fun still to see jfalempe DRM panic on this silly panel :D
16:39 javierm: and also made me realize that I could just drop the regmap lock since is not needed for this driver
16:39 sima: yeah, nice pic on fedi :-)
16:39 javierm: :)
16:40 sima: airlied, https://lore.kernel.org/dri-devel/595563de-234f-49be-b807-c9ebaa758fc1@sirena.org.uk/ dim didn't catch it?
16:40 sima: or you're too used to ignoring those :-P
16:42 sima: lumag, sorry for the late replies on the panel shutdown discussion, maybe we should have the next round here on irc since I'm not sure where communication (or my understanding) fails ...
16:43 lumag: sima, I think it was mostly dianders .
16:44 lumag: sima, When you pointed out to the devlinks, I thought that we might be able to use the same approach to solve our bridge runtime stuff, but it seems we can not.
16:50 sima: lumag, should be the same issue, but bridges are a lot more messy since a bunch of drivers still use component.c for bridges
16:51 sima: and some drivers use device links already (just in their driver code, manually) for bridges iirc
16:52 lumag: sima, msm uses components for "root" bridges.
16:52 lumag: maybe we should stop doing that.
16:53 sima: uh yeah iirc those cases are the reason why adding device links to bridges has become really messy
16:53 sima: and people gave up on all the past attempts :-/
16:53 sima: forgot what the issue was
17:04 sima: lumag, also I more meant the discussion around how to fix the bogus panel shutdown warnings
17:06 lumag: sima, yes, I think that was also dianders's topic
17:07 sima: lumag, oh right I mixed up the names with the writeback discussion
17:07 lumag: sima, n/p
17:07 sima: dianders, ping me here so we stop confusing us :-)
17:08 sima:bad at this sometimes ...
17:09 lumag: sima, for writeback, as you have mentioned it, do you have any comments / suggestions / ideas on the 'queue +1 job' uAPI?
17:12 lumag: sima, using a single CRTC to drive both screen output and a writeback is a saviour, especially on resource-constrained devices.
17:12 sima: oops wanted to, but forgot
17:12 sima: typing now
17:14 lumag: thanks!
17:18 sima: lumag, sent
17:37 lumag: sima, thanks!
17:37 lumag: That's really an interesting approach
17:39 sima: well it's how this entire thing was designed almost a decade ago, just like ... didn't yet get there
17:40 lumag: :-D
17:40 sima: but I think if we limit to a) only commits where needs_modeset(crtc) == false and where that also holds for the previous commit
17:40 sima: and we audit drivers to not look at obj->state pointer for those paths, we should be fairly close now
17:41 sima: maybe an explicit opt-int flag on the atomic ioctl, so that we can keep the EBUSY checking as-is
17:41 sima: and then maybe a max queue parameter, since some hw can in some cases enqueue into hw directly
17:42 sima: but maybe in practice we don't want more than 2, because with more you get into the headache of having to cancel them if something has changed
17:44 sima: and my gut feeling says it's not really more work, because it's fundamentally all the same races you need to fix
17:44 sima: difference just whether you fix them fundamentally at the state struct level, or add-hoc just for the writeback commit
17:45 lumag: two should be more than enough, as a starter point.
17:45 lumag: and definitely an opt-in IMHO
17:46 sima: oh yeah, we can't fix all drivers
17:46 sima: it's more how much of an opt-in it should be
17:47 sima: oh atomic's 10th birthday (per upstream merge date) is next month already
17:48 sima: ah now, that was a random patch date, it's in November this year
17:51 dianders: sima / lumag: Sorry, I was AFK for a bit but I'm here now. There's honestly nothing really urgent about the drm shutdown stuff and I almost feel like in-person would be better. Any chance you guys will be in Vienna in Sept? I plan to be at ELC and LPC.
17:53 lumag: dianders, I have a talk at OSS/EU and even if my proposal for LPC isn't accepted I plan to stay.
17:53 sima: dianders, I should submit my lpc talk this evening ...
17:54 sima: so kinda plan to, but not yet definite (don't have a ticket, so if the talk doesn't make it it's maybe a sponsor ticket or maybe I'll skip)
17:54 sima: hm no sponsor ticket, intel's not on the list
17:55 dianders: lumag / sima: Sounds good. I'm happy to table the discussion until then, or just drop it. Honestly the only reason I submitted the patch is that I got talked into playing janitor and trying to help clean up some of the mess around enable/prepare. I'm already many layers deep into yak shaving and I'm happy to leave the rest of the yaks alone...
17:56 sima: dianders, well I think fixing the bogus warning should be doable, but we seem to confuse each another a bit
17:56 sima: doable without the explicit list I mean
18:01 dianders: sima: hmmm, so you're saying that:
18:01 dianders: 1. Say that DRM modeset drivers are responsible for adding a devicelink such that they get a shutdown() call before the panel's shutdown() call.
18:01 dianders: 2. In the panel driver shutdown, add a warning if the panel hasn't already been turned off.
18:01 dianders: ...but you still can't necessarily detect broken drm modeset drivers, right? If you have a DRM modeset driver that doesn't have the device links and _also_ doesn't call drm_atomic_helper_shutdown() then the panel warning won't fire at all, right?
18:07 lumag: dianders: check for the .shutdown callback just by reviewing existing drivers?
18:07 lumag: and documenting that it is mandatory
18:08 sima: no to 2, I think that's impossible to add unless we add the device link to the panel code and hence guarantee it's there for everyone
18:08 sima: let me type up the diff
18:09 lumag: dianders, also, there might be a lengthy bridge chain between the drm device / driver and the panel.
18:09 lumag: So all bridges should get devlinks
18:10 lumag: Maybe this can be handled in the automated way in drm_bridge_attach ?
18:10 sima: yeah we need devlinks all the way
18:10 sima: at which point you run into the complication of bridges that are handled with component
18:11 sima: and into all the various duct-tapes that drivers added meanwhile, like their own devlinks
18:11 sima: and much worse
18:11 dianders: Sure, if we can do it in drm_bridge_attach() that'd be nice. I'm still worried that it's going to cause consternation somewhere along the way due to someone thinking that the order is wrong, but I'd be more than happy if someone wanted to figure out how to get that working...
18:12 sima: dianders, https://paste.debian.net/hidden/67fbf789/ this is the "shut up false warnings" stop-gap patch I had in mind
18:13 sima: doesn't compile, forgot to downcast :-)
18:16 dianders: sima: LOL, sure. I guess then we'd just leave that code there basically "forever", or you have some way to know when we could finally delete it?
18:16 sima: dianders, whenever someone fixed up all the driver (hopefully with device_link)
18:17 sima: drm is full of this kind of "oops we made a mistake, but need to keep existing crap working" stuff
18:17 dianders: sima: sure, but if we knew people had fixed up all drivers (by calling drm_atomic_helper_shutdown() properly) we could also delete it.
18:18 dianders: Will it be easier to know that all drivers have device_link than that all drivers call drm_atomic_helper_shutdown() properly?
18:18 sima: dianders, yeah but reality in a subsystem with a 100+ drivers is sometimes just a bit disappointing
18:18 sima: dianders, if we add it to bridge/panel code, yes
18:18 dianders: sima: OK, fair enough.
18:19 sima: well probably more step 0: endless screaming to figure out all the trapdoors 1: merge device_link automagic code to bridge (maybe can rely on panel-bridge for panels?)
18:19 dianders: sima: I'd be OK with a patch like the one you propose and then when someone solves the device link problem then we can delete it...
18:19 sima: 2: wait a few releases because inevitable we've missed a few corners and broke a few things
18:19 sima: 3: delete crufty compat hacks
18:19 sima: we have cases in drm where this is taking longer than 10 years
18:20 lumag: sima: that sounds like a plan for DRM_BRIDGE_ATTACH_NO_CONNECTOR, but we are still not there
18:20 sima: dianders, yup, that's pretty much what I suggested we go for
18:20 sima: lumag, yeah
18:20 dianders: sima: sure. you want to post an official patch, or you want me to?
18:20 sima: dianders, maybe check that all the docs are updated and todo.rst has a good entry for this mess, as a bonus patch
18:21 sima: dianders, would be happy to ack yours, you put in plenty more time into this than me already
18:21 sima: plus this was just my "this should work" idea, I didn't think it through :-P
18:21 sima: nor test it
18:22 dianders: sima: I don't really care about my name on it, but sure. Let me try to write something up. I don't think it'll take too long for that. There's already a big TODO so it's mostly just updating it.
18:22 sima: aye thanks
18:25 lumag: sima, speaking about msm :-D What's the problem with components? I can probably look into dropping their usage for our on-chip bridges, but I'd like to understand the actual problem.
18:25 sima: lumag, iirc components.c only solves the load-order issue
18:25 sima: doesn't add any devlinks
18:25 lumag: it doesn't
18:26 sima: and iirc at least some versions of devlinks where then fighting with component.c over the load ordering fun
18:26 lumag: But the devlinks should be there already because of the graph links
18:26 sima: yeah, but for pm stuff you need to upgrade them
18:26 lumag: But they are circular devlinks, which are immediately broken
18:26 lumag: I see.
18:27 sima: plus way back when this happened I'm not sure the devlinks for load ordering from the dt links was merged into upstream already
18:27 sima: iirc that bikeshed finally got resolved later
18:27 sima: and yeah I think the fun was that we ended up with circular dependencies or something and the driver couldn't load anymore
18:28 sima: there was I think also issues about when to add the devlink and when to remove the pm part of it
18:28 sima: but all very vague
18:28 lumag: I see, thanks
18:28 sima: in a way you want the load order devlink when you first try to find the bridge/panel through of
18:28 sima: but the pm links should only exist between attach and detach of the bridge
18:29 sima: also I think the pm core code didn't have yet enough flags for the exact devlink we needed, and some gaps
18:29 sima: like maybe only used for rpm not for system pm actions like suspend/resume
18:30 sima: it was all a mess tbh, but I thought we've gotten like 90% and then everyone gave up and declared the problem Too Hard
18:30 sima: but was probably the usual "last 10% is 90% of the effort" case ...
18:30 sima: lumag, tldr; I guess if you can make automatic pm devlinks in drm_bridge work for msm somehow we should have a real chance to merge this
18:31 sima: since I think msm covers a lot of the pitfalls already
18:31 sima: worst case we need a DRM_BRIDGE_ATTACH_NO_DEVLINK flag I guess
18:31 lumag: rofl
18:32 lumag: At least it's better than NO_CONNECTOR flag.
18:32 lumag: NO_DEVLINK shows what needs to be fixed.
18:32 sima: yeah
18:32 sima: but we might be even worse of and need the explicit opt-in
18:33 sima: but if we can get away with the explicit opt-out for bridge pm devlinks then I think it's a roaring success and we should just party for a year or something
18:34 lumag: sima, I'd hate the opt-in here.
18:35 lumag: We have it with DRM_BRIDGE_ATTACH_NO_CONNECTOR and it's really not so easy to review all the leftovers
18:36 sima: lumag, yeah, but NO_CONNECTOR needs both updated consumers and bridge drivers, so it's nxm hard
18:36 sima: devlinks hopefully only need consumer-side audit
18:36 sima: unless stuff like the simple-panel shutdown hacks have spread to many places ...
18:36 lumag: sima, my point is that if we have a migration plan, it must be fairly easy to find all the outstanding drivers.
18:37 sima: lumag, yeah, ideally
18:37 sima: reality is sometimes disappointing non-ideal though
18:49 lumag: :D
18:50 lumag: sima, hopefully last question for today:
18:50 lumag: sima, jhugo regarding fastrpc. Does drivers/accel/ require drm_accel.h API?
18:50 lumag: (to end up the fastrpc story and let me forget about it for quite a while)
18:50 sima: imo yes
18:51 sima: like habanalabs is the exception that proves the rule, because that was all a very messy 3 years and a lot of looking away and compromising was needed to get somewhere less awkward
18:51 jhugo: For something new, yes. Habana did come over and convert. I'm not sure that is really a "model" for others to follow
18:52 sima: plus habanalabs then switched over anyway since they control the userspace of their customers enough
18:52 sima: yeah all very special exception case
18:53 lumag: sima, jhugo so it should be come-over-and-convert or stay-away-and-hide?
18:54 lumag: sorry
18:54 lumag: either - or
18:54 sima: submit-new-driver-once-fastrpc-is-outdated imo
18:55 jhugo: I suspect "accel fastrpc" is going to be vastly different than the "misc fastrpc". Both will need to exist, sadly
18:55 sima: like if it's an entire driver rewrite in misc/fastrpc for new hw it should probably just be a new accel driver for that hw
18:55 sima: like we continue to have large amounts of overlap between fbdev and drm display drivers in terms of supported hw
18:56 sima: and distros just don't care, because they don't compile any of the old code
18:56 lumag: no, it's an evolution. The same driver works for all the hardware since 2016
18:56 jhugo: Yeah, Qcom could even pick a generation of hardware to break the interface. Its happened before (smd -> glink)
18:56 sima: yeah that too
18:56 lumag: jhugo, rofl.
18:56 sima: I meant more from an upstream pov, if the driver becomes unreconizeable it starts to smell a bit much like "we're just avoiding drivers/accel and its rules"
18:57 sima: and that point I guess I'll start asking the really annoying questions :-)
18:57 lumag: well, it already does a bit.
18:58 sima: lumag, yeah so if the rename is to prep the codebase for massive expansion, then ... maybe time for the annoying questions already?
18:58 lumag: That's why at some point calebccff pointed out strange patch series
18:58 lumag: I don't have resources for that :-(
18:59 lumag: So far we started being annoying by doing reviews.
19:00 lumag: But anyway, I think I got your idea.
19:00 lumag: or your point
19:01 sima: uh that other patch series is fun ...
19:02 sima: lumag, patches 2&3 sound a bit like the current driver is essentially dysfunctional
19:02 sima: so if current upstream was never useful, we can just git rm the entire pile and start fresh
19:03 lumag: sima, it is working
19:04 sima: yeah but that entire "get capabilities from dsp" seems to be extremely broken as-is
19:04 sima: read 4x too little from hw, then only copied tiny part to userspace
19:04 sima: doesn't sound like "it works" to me
19:07 lumag: sima, it was passing 4 extra bytes, not 4x
19:08 lumag: And it's might be that the call is not used in simple loads.
19:08 lumag: Because at least I've been building and testing the apps on several platforms.
19:08 lumag: But the real issue is not on the kernel side.
19:09 sima: yeah the userspace is probably blobby to no end :-)
19:12 lumag: The whole story requires a daemon, toolchain and some libs / glue code and the shell binary blob to be executed on the DSP. The daemon has been ported from Android, you can guess about its style and simplicity to read it. The official toolchain isn't open-source, but there exists an open-source toolchain by Qualcomm. The rest is closed-source.
19:13 lumag: So it's not all-blobs
19:17 sima: yeah ...
19:18 sima: the other question is also how much you really run random workloads on that thing
19:18 sima: which is kinda the accel/drm use-case, and where the runtime+compiler requirement comes from
19:18 sima: if it's just an essentially fixed-function dsp, then the blobs are a lot more just like firmware
19:21 lumag: sima, fixed-function is a non-fastrpc case. fastrpc is used to offload user-written code
19:22 lumag: There are additional restrictions (some DSPs can accept only the 'signed' code, while other allow actually user-written code)
19:23 sima: hm yeah that's a more clearly accel
19:24 lumag: Yep
19:24 lumag: The 'fixed-function' code lives in drivers/rpmsg, drivers/soc/qcom sound/soc/qcom/
19:25 lumag: That's why I proposed moving to drivers/accel/
19:54 jenatali: Hm, what happened with this a630 runner? https://gitlab.freedesktop.org/mesa/mesa/-/jobs/60211631
19:55 airlied: sima: oh wow too use to ignoring them, the missing Sob should probably get elevated above the missing links
19:55 airlied: I might reset drm-next since it's the last pull
19:58 sima: airlied, dim shouldn't complain about missing Link: tags for stuff in merges ...
19:58 sima: but maybe it broke somewhere
19:59 sima: airlied, the missing review it'll complain about, maybe that's the one you're seeing?
19:59 sima: we could filter that out too
20:01 sima: airlied, just did a test-run, it doesn't complain about missing Link: here, only about a pile of missing sob and one missing review
20:02 sima: airlied, https://paste.debian.net/hidden/38361c67/ this should shut up missing review on pulls, but not sure that's a good idea since for e.g. -misc topic branch prs we want that check
20:04 sima: airlied, anyway for this much missing sob I think a hard-reset is in order
20:06 airlied: sima: yes just hard reset it now
20:07 airlied: sima: ah maybe it's missing review on non-misc trees I see a lot off and my brain auto parses out
20:07 DemiMarie: Does userspace that doesn't use all of the hardware features meet the open userspace requirement?
20:07 airlied: probably need to make missing sob ultra fatal
20:08 DemiMarie: Fail the push?
20:08 airlied: if we could enforce everyone to use our tooling :-P
20:09 DemiMarie: Packaging it for all the distros would help
20:09 DemiMarie: I meant server-side, though.
20:24 airlied: mlankhorst: were you meant to dequeue misc-fixes?
20:24 airlied: granted there's only one in there, but it's marked for stable etc
23:55 DavidHeidelberg: I don't use zink, but getting: "MESA: error: ZINK: failed to load libvulkan.so.1" + "libEGL warning: egl: failed to create dri2 screen" :(