marcan changed the topic of #asahi to: Asahi Linux: porting Linux to Apple Silicon macs | General project discussion | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Topics: #asahi-dev #asahi-re #asahi-gpu #asahi-stream #asahi-offtopic | Keep things on topic | Logs: https://alx.sh/l/asahi
linearcannon has quit [Read error: Connection reset by peer]
gladiac is now known as Guest6046
gladiac has joined #asahi
Guest6046 has quit [Ping timeout: 480 seconds]
linearcannon has joined #asahi
gabuscus has quit [Read error: Connection reset by peer]
gabuscus has joined #asahi
<marcan>
going to stream spme pmgr/clock driver stuff in a bit, see #asahi-stream :)
bps has joined #asahi
<maz>
sven: do PCI devices see IOVAs in the low 4GB range? I seem to remember they do, right?
<sven>
yeah
<maz>
so what guarantees that we never provide an endpoint with the MSI doorbell as something to DMA from/to?
<maz>
(I fear I know the answer to that question)
<sven>
unless you setup dma-ranges to excluse the msi page in the pcie node only luck
<sven>
unless the iommu framework can figure out the msi doorbell somehow, but i don't think so
<maz>
sven: that's what I thought. I seem to remember there was something to exclude some MSI ranges because HiSilicon messed up their SMMU across several generations. Time to poke Robin...
<sven>
there's a get_resv_regions that the iommu driver can implement
<marcan>
95% is clock gates, which at this point might also be power gates for all I know
<marcan>
because they aren't really called clock gates, and often the power gates reference the same IDs
<marcan>
they are called "power states"
<marcan>
the actual power gates register range is almost untouched, I saw macos poke like... 3
<marcan>
and I don't know what they are
<marcan>
in reality pmgr is surprisingly quiet post-boot
<sven>
huh
<marcan>
I could only see actual power state changes with something obvious like pulling up a video that enables the video decoder
<sven>
so it's all hardware magic (or coprocessors) doing the power stuff?
<marcan>
it's starting to sound like that
<kettenis_>
did you try suspending the machine?
<marcan>
yes (which crashes the HV, but definitely pokes a pile of state regs)
<marcan>
and there's things like the power states for the CPUs represent the currently running CPUs, but they obviously aren't turned on *that way*
<marcan>
so there is clearly abstraction going on
<marcan>
i.e. we know we don't need to touch this to spin up cores, yet the ps regs for each CPU and the clusters overall accurately represent the current state of what CPUs have been spun up
<marcan>
it looks like this is a relatively high level abstraction for what power/idle state a given device is in (most of which only have 2 states)
<marcan>
and now I wonder if clocks is the right abstraction in linux for this, though it might be the best we can do for now
<marcan>
they also use this device concept to trigger voltage/performance states for some devices
<marcan>
e.g. any SoC block requiring high performance can put the whole SoC power domain into a higher voltage state
<marcan>
(that's the "everything but gpu/cpu" domain basically)
<marcan>
I still don't know how clocks are controlled, what regs they map to
<marcan>
I only found like 4 proper cross-refs from the devices table to clocks, everything else is null, which is bizarre
<marcan>
maybe this is also all automagic stuff controlled by the pmu or something...
<maz>
marcan: this looks a bit like the voting system that most qualcomm SoCs implement (you can vote on the power state of a block, and the HW aggregates the votes to satisfy the independent requirements within the physical constraints).
<kettenis_>
so you're thinking one of the coprocessors is repsonding to the bits we twiddle by doing tha actual power/clock management?
<marcan>
I'm not sure if there's "voting" here per se, at the hw level
<marcan>
I know multiple devices in the ADT reference the same power rails to set a voltage
<marcan>
so that could be done in software
<marcan>
kettenis_: yeah, possibly
<j_ey>
maz: shame about the powermetrics segfault :D
<marcan>
lol yeah
<sven>
there's also a clock-frequencies and clock-frequencies-regs property in PMGR iirc, but running grep on XNU and all kernel extensions doesn't find _any_ reference to the regs one
<marcan>
well, that might be a good reason to implement SMP in the HV
<marcan>
the PMP firmware definitely talks SPMI and ooooh here are the strings of the perf counters I was not finding in the ADT
<marcan>
this is pretty small though, it looks like it could be mainly sampling, not control, but I'm not sure
aleasto has quit [Quit: Konversation terminated!]
simjnd has quit [Remote host closed the connection]