refi64 has quit [Remote host closed the connection]
refi64 has joined #asahi-dev
mmarchini has joined #asahi-dev
refi64 has quit []
refi64 has joined #asahi-dev
phiologe has joined #asahi-dev
kov has quit [Quit: Coyote finally caught me]
PhilippvK has quit [Ping timeout: 480 seconds]
axboe has quit [Quit: leaving]
the_lanetly_052___ has joined #asahi-dev
<marcan>
rkjnsn: it does 300-600 IOPS, which is still slow
<marcan>
depending on the machine, apparently?
<marcan>
I got 350 on an M1 Max lol
<marcan>
axboe: nice :)
<marcan>
axboe: wait, shouldn't that be F_FULL*F*SYNC on the patch? did you compile test it? :-)
<marcan>
oh, jannau already mentioned it
<_jannau_>
and already fixed and tested in fio master
yuyichao_ has joined #asahi-dev
Major_Biscuit has joined #asahi-dev
yuyichao has quit [Ping timeout: 480 seconds]
MajorBiscuit has joined #asahi-dev
Major_Biscuit has quit [Ping timeout: 480 seconds]
the_lanetly_052___ has quit [Ping timeout: 480 seconds]
kov has joined #asahi-dev
bps has joined #asahi-dev
kloenk has quit [Remote host closed the connection]
roxfan2 has joined #asahi-dev
roxfan has quit [Ping timeout: 480 seconds]
axboe has joined #asahi-dev
<axboe>
t log
<axboe>
sorry, jumpy touchpad...
<landscape15[m]>
In order to test out latest power management features, do I need to use smc/work branch?
<_jannau_>
spmi/work
<_jannau_>
sven: is it expected that dart_map_pages() just maps to the end of a l2 table? the imac vram/framebuffer is huge
<sven>
no, that sounds like a bug
<sven>
iirc io-pgtbl writes the number of mapped pages to one of its arguments
<sven>
I probably don't check that
<_jannau_>
it writes the mapped size
<sven>
I'm not sure what io-pgtbl is supposed to do but having that as an output sounds like it's not guaranteed to always map everything
<_jannau_>
so dart_map_pages would be responsible for looping
<sven>
possibly. i'm just guessing from the API here :D
<sven>
could also be a bug in there. I'd ask robin and the iommu list
<_jannau_>
it has basicly the same api as io-pgtbl. I'll check the decumention tonight.
<sven>
looks like it's intended though, check e.g. __iommu_map
<sven>
it calls __iommu_map_pages in a loop until it has mapped everything
<_jannau_>
handling that for the resrved regions myself is not a problem but I had the cma alloc of the framebuffer fail as well
<_jannau_>
ok, the cma alloc might be a different problem then
<sven>
cma sounds wrong when we have an iommu
<sven>
oh.. wait.. is that thing inside drm that is just called cma but actually just uses the coherent dma api?
<_jannau_>
probably, I haven't looked yet, it's called cma in drm's debug output
<sven>
yeah, i think it's probably cma-in-name-only then
<landscape15[m]>
jannau: thanks. Is there a plan to merge it in smc/work then? Or maybe they will remain separated
<sven>
cma is only required when you really need physically contiguous memory. once you have an iommu you can just stich discontiguous pages together for the both the CPU and the device
<sven>
but for what I believe are historic reasons there's a thing inside drm that calls itself cma_something_something but actually just uses the coherent dma api which makes everything work fine with iommus
<alyssa>
oh i actually know this one
<alyssa>
_jannau_: sven is correct
<alyssa>
the contiguous memory allocator in DRM was designed for physically contiguous allocations, for devices without an IOMMU
<alyssa>
however it uses the DMA API for everything
<alyssa>
and DMA uses the underlying IOMMU API if the device has an IOMMU
<alyssa>
which means DRM's CMA works fine if you have an IOMMU ...
<alyssa>
... but instead of allocating physically contiguous buffers, it allocates _device virtual address_ contiguous buffers
<alyssa>
of course, that is exactly what you want for IOMMU-ful display hardware where you specify a single framebuffer VA (as opposed to a list of pages)
<alyssa>
we all agreed that CMA should probably be renamed in DRM, but that it's too much effort and we'd rather bite the noobies because we're mean kernel hackers
<sven>
ohhh... does that thing use map_sg while assuming that it'll only get a single output?
<sven>
if you're using a 4K kernel with our lovely 16K IOMMU that's not guaranteed to be true anymore
<alyssa>
osti
<kov>
landscape15[m], afaik spmi/work includes smc/work already (you can search for the top commit messages from smc/work on spmi/work to verify)