03:07 <marcan> jannau: yeah, so we still need a completion or something at some point to block until DCP is properly up

03:07 <marcan> nicolas17: yes, it only affected DCP, so you can expect oversaturated red again :p

03:07 <marcan> that's the native colorspace

03:08 <marcan> DCP has been doing sRGB, but that's a waste of a default; until we get both options exposed (which will require matrix gooeiness for 10-bit due to the wide gamut weirdness) it makes more sense to just expose native and let people who care do their own color management IMO

03:08 <marcan> we can't do 10-bit sRGB without either new colorspace/userspace support (ew) or matrix weirdness to compensate

03:09 <marcan> but also in general fewer conversion steps are preferred, so native is better and should result in less banding/quantization issues, and just let userspace deal with a single color correction step

03:10 <marcan> at some point we'll figure out the ICC profiles to do this all properly, feel free to look into that if you're interested

03:10 <marcan> I'm curious how good ICC support is in KDE/Wayland these days

03:10 <marcan> IIRC macOS has the ICC profiles stashed somewhere in plain view and I imagine those are intended to output at the native colorspace

03:11 <marcan> practically: I think the only actual use case for non-native colorspaces in DCP is for video playback and such, where you're feeding in frames straight from a video decoder / scaler engine and bypassing the GPU (and normal ICC processing)

03:16 <marcan> jannau: pushed dcp/sleep (blindly rebased, not compile tested)

09:39 <eiln> finally got time to work on this again

09:39 <eiln> so ane's DMA channels expect a continuous iova block

09:40 <eiln> i'm using the raw iommu api to 1) allocate iova block 2) walk down gem pages and iommu_map() each page

09:40 <eiln> haven't ported the dmaengine part yet so can't really test but seems to work

09:41 <eiln> unsure on a couple things though

09:41 <eiln> 1) is vm-size a legitimate limit i need a carveout for? there's a vm-base which is bogus so i think it's also bogus?

09:42 <eiln> 2) should i reserve the (unused lol) segment-ranges?

09:42 <eiln> 3) whether to hard-code the "neural" quirks?

09:42 <eiln> for reference the dma architecture seems like a modded version of arm's:

09:42 <eiln> https://developer.arm.com/documentation/102420/0200/Functional-description/Functional-blocks-/DMA-controller

09:43 <eiln> basically the "Command channel" and "Weight channel" equivalent work @ 64 gran but the rest are PAGE_SIZE (technically tile size == page size)

09:43 <eiln> the "command stream" is tiny and unaligned so what macos likes to do is to pack the weights directly after the cmd

09:43 <eiln> order doesn't affect function ofc but idk if it's worth the effort to separate and track the dma types

09:44 <eiln> i'd need a "neural network" abstraction and yada yada

09:44 <eiln> arm's kernel module uses a crazy complex allocator model

09:44 <eiln> https://github.com/ARM-software/ethos-n-driver-stack/blob/main/kernel-module/ethosn_dma_iommu.c

09:44 <eiln> where each buffer type has its own allocator device

09:44 <eiln> https://github.com/ARM-software/ethos-n-driver-stack/blob/main/kernel-module/juno-r2-ethosn-smmu.dts

09:45 <eiln> i think it's too far but i could be wrong

09:45 <eiln> oh also attached power domains aren't called when dart's probed and dart probes before i can

09:47 <eiln> so pds are hacked as always-on to prevent unauth access (can't figure out why tho)

09:50 <sven> looks like that thing requires a different iommu for each allocation type, you shouldn’t need that

09:57 <jannau> I suspect vm-size in the ADT is just a configured limit. I haven't looked at vm-base. the only device with an non zero vm-base is dcp on m2 and it's probbaly fine to ignore for now since the managed iommu domain allocates iova top down

09:59 <sven> iirc we already allocate above vm-size for pcie and possibly dwc3

09:59 <sven> it very much sounds like a software limit only

10:01 <jannau> for dcp/disp0 on t8103/t600x as well. vm-size is iirc 0xFC000000 but we start allocating at the top of the 32-bit address space

10:02 <eiln> pio-vm-base is nonzero but not used (actually the whole pio thing i don't really get)

10:04 <eiln> yeah i'll use the 32b space too

17:24 <marcan> eiln: vm-base/vm-size is usually about the ASC

18:46 <tpw_rules> marcan: do you have the mesa releases tagged or something? i am looking through some of the older PKGBUILDs for mesa-asahi-edge and seeing commits which are not pulled down directly by a "git clone" of the repository, e.g. 08ff98967079a2e43a04f11fc646eef51a9103f1. concerned that they might be eligible for garbage collection