thevar1able has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
aleasto has quit [Remote host closed the connection]
KDDLB has quit [Server closed connection]
KDDLB has joined #asahi-dev
user982492 has joined #asahi-dev
tbodt_ has quit [Server closed connection]
tbodt has joined #asahi-dev
thevar1able has joined #asahi-dev
thevar1able has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
thevar1able has joined #asahi-dev
thevar1able has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
thevar1able has joined #asahi-dev
yamii has quit [Quit: WeeChat 3.3]
aead has quit [Server closed connection]
aead has joined #asahi-dev
user982492 has joined #asahi-dev
thevar1able has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
jbowen has quit [Quit: leaving]
Method has quit [Server closed connection]
Method has joined #asahi-dev
skipwich has quit [Server closed connection]
skipwich has joined #asahi-dev
emptynine has quit [Server closed connection]
emptynine has joined #asahi-dev
nafod has quit [Server closed connection]
nafod has joined #asahi-dev
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
thevar1able has joined #asahi-dev
user982492 has joined #asahi-dev
krbtgt has quit [Server closed connection]
krbtgt has joined #asahi-dev
tmlind has quit [Server closed connection]
tmlind has joined #asahi-dev
opticron has quit [Server closed connection]
opticron has joined #asahi-dev
PhilippvK has joined #asahi-dev
phiologe has quit [Ping timeout: 480 seconds]
kov has quit [Quit: Coyote finally caught me]
kov has joined #asahi-dev
rbenua has quit [Server closed connection]
rbenua has joined #asahi-dev
gruetzkopf has quit [Server closed connection]
gruetzkopf has joined #asahi-dev
balrog has quit [Server closed connection]
balrog has joined #asahi-dev
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
thevar1able has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
TheFirst has quit [Server closed connection]
TheFirst has joined #asahi-dev
jeffmiw has quit [Remote host closed the connection]
jeffmiw has joined #asahi-dev
linuxgemini has quit [Server closed connection]
linuxgemini has joined #asahi-dev
akemin_dayo has quit [Ping timeout: 480 seconds]
Chinese_soup has joined #asahi-dev
<jannau>
the dcp crashlog buffer is in one of the carveout-memory-map regions. I don't see a mapping of carveout regions to devices in the ADT
thevar1able has joined #asahi-dev
esden has joined #asahi-dev
thevar1able has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
aleasto has joined #asahi-dev
<marcan>
the carveout-memory-map regions include all of RAM :-)
<marcan>
so we need something else
<marcan>
I guess at the very least we could just say "outside the main RAM area" or something...
<jannau>
ugh, I just looked at the carveouts at the top of the memory. the crashlog buffer is in a 3 megabyte carveout so that would be fine if the ADT would tell to which device nodes a carveout belongs
<sven>
looks good, is_iomem should be set from the driver though. DCP never needs it but SMC always needs
<sven>
It’s different from who owns the buffers
<sven>
It’s just to check if we need to use memcpy_fromio instead of memcpy
<sven>
rtkit.c itself doesn’t need to care who owns the buffer I think
akemin_dayo has joined #asahi-dev
<jannau>
it cares in apple_rtkit_memcpy()
<sven>
no
<sven>
it doesn’t care who owns the buffers
<sven>
it cares if the buffer is iomem (MMIO) or normal RAM
<jannau>
ah right
<sven>
DCP has the crashlog buffer as owned by rtkit but the rest owned by Linux but both are normal RAM
<jannau>
I currently use ioremap_wc for the dcp crashlog, mostly since I'm drowned in noise when looking how to map carveout memory
<sven>
ah, right. take a look at alyssa’s locked dart hacks
<sven>
she also has to
<sven>
she also has to map carve out memory somewhre
<jannau>
memremap, that was too simple. I need anther flag to track the ownership then
<jannau>
the drivers care on destroy and rtkit only replies for AP owned buffers
<sven>
hm, true
<jannau>
and we don't need an is_iomem flag, we can infer that from bfr->iomem != NULL
philpax_ has quit [Server closed connection]
philpax_ has joined #asahi-dev
<alyssa>
jannau: fwiw I don't know if memremap is 'correct'
<alyssa>
but it works
<alyssa>
(correct in the sense of passing code review, not in the sense of working)
<kettenis>
what matters is what memeory attributes the other side uses
jabashque_ has quit [Server closed connection]
jabashque_ has joined #asahi-dev
<kettenis>
in particular whether it is mapped cachable or non-cachable
<kettenis>
do we know what memory attributes macOS uses for these buffers?
tardyp has quit [Server closed connection]
tardyp has joined #asahi-dev
<sven>
jannau: true
<sven>
kettenis: for the DCP ones the same as RAM
<sven>
and for SMC the same as MMIO (nGnRE or whatever non-pcie uses)
<jannau>
are you sure it is not uncached like the framebuffer for dcp?
<kettenis>
yeah, SMC has to use nGnRnE
<sven>
50:50 chance I chose the wrong mode ;)
<sven>
jannau: I’d have to double check but the frame buffer is the only thing that’s special iirc
<sven>
isn’t the frame buffer also mapped through the disp0 dart instead?
<kettenis>
the SoC tends to be completely cache-coherent, so Normal WB is plausible
<kettenis>
if you get it wrong, you might not immediately see what the other side writes into the buffer
<jannau>
I don't think we will ever see it in this case as we should read the crashlog buffer only once (at most) and never write
psykose has quit [Remote host closed the connection]
<sven>
I’d be surprised if that’s one isn’t just normal RAM
psykose has joined #asahi-dev
<marcan>
the framebuffer has to be mapped non-cacheable because while the SoC is cache-coherent, apparently that coherency does not come with realtime guarantees
<marcan>
so on t6000 the memory controller throws a hissy fit if you end up with framebuffer cache lines in CPU cache (even though it still works)
<marcan>
that's why m1n1 switched to uncached and a shadow copy
<marcan>
I imagine the GPU will have some way to blast out framebuffers as write-through so that doesn't happen there
<marcan>
but I think Normal WB is likely to be fine for any ASC comms via carveouts
<unrelentingtech>
and all I did for amdgpu was make `ioremap_nocache`, `ioremap_wt` and `ioremap` all map as device-nGnRnE.. (which, yeah, probably wt shouldn't be, but whatever)