<jannau>
I tried using a cpufreq instance per die but that did not work. Could be easily my fault. I did not look into why it failed as I was doing something else
thelounge7571340 has quit [Remote host closed the connection]
thelounge7571340 has joined #asahi-dev
povik has joined #asahi-dev
andersonwatts3562[m] has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
thelounge7571340 has joined #asahi-dev
amarioguy2 has joined #asahi-dev
amarioguy has quit [Ping timeout: 480 seconds]
MajorBiscuit has joined #asahi-dev
<andersonwatts3562[m]>
"I'll help 10individuals how to earn $30k in 72 hours from the crypto market. But you will pay me 10% commission when you receive your profit. if interested send me a direct message via WhatsApp by asking me HOW for more details on how to get started
andersonwatts3562[m] was kicked from #asahi-dev by ChanServ [You are not permitted on this channel]
tobhe has quit [Ping timeout: 480 seconds]
thelounge7571340 has quit [Remote host closed the connection]
thelounge7571340 has joined #asahi-dev
roxfan2 has joined #asahi-dev
roxfan has quit [Ping timeout: 480 seconds]
chipxxx has joined #asahi-dev
chipxxx has quit [Remote host closed the connection]
chipxxx has joined #asahi-dev
tobhe has joined #asahi-dev
amarioguy2 has quit [Quit: Leaving]
thelounge7571340 has quit [Remote host closed the connection]
<marcan>
jannau: you can only have a single cpufreq instance, that's why it's done the way it is with all clusters in one device
<marcan>
it's stupid and honestly should not be bound in the DT like that, the DT should just have clusters and the cpufreq driver should pick them all up, but that's not how current cpufreq drivers do it...
<marcan>
(ping robher, any opinions about this? cases where the Linux model demands a single driver instance for what logically are completely independent pieces of hardware?)
thelounge7571340 has joined #asahi-dev
<marcan>
either way, the answer for the current DT model/driver is to put cpufreq outside of either die bus. could be in a third, shared/common bus.
amarioguy has joined #asahi-dev
Soroush has quit []
Soroush has joined #asahi-dev
amarioguy has quit [Remote host closed the connection]
amarioguy has joined #asahi-dev
chadmed has quit [Remote host closed the connection]
kov has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
thelounge7571340 has joined #asahi-dev
<robher>
marcan: Fix the OS? cpufreq has always been problematic though often that's because it's more a virtual device on top of other drivers.
thelounge7571340 has quit [Remote host closed the connection]
thelounge7571340 has joined #asahi-dev
<marcan>
robher: yeah, and cpufreq-dt sort of does it right, but only works for devices with low-level clock/etc drivers (I tried that approach, was shot down and honestly wasn't a good match)
<marcan>
but cpufreq-dt does probe magic behind the scenes
<marcan>
so the question is, how should this be represented in the DT? conceptually, the hardware is a cpufreq instance per CPU cluster, and they're independent
<marcan>
but then Linux needs to probe them all as a single driver
<marcan>
driver/device instance
<marcan>
and we also need to describe the mapping between CPUs and cpufreq clusters
<marcan>
if we want to keep the "virtual device / physical devices" model, then there could be a top-level cpufreq instance (with no reg) with phandles to the individual cluster devices (which have a reg) and then just make the latter not probe by default, or probe as separate drivers but do nothing other than mmap IO and store it as driver data for the top-level device to reference?
<marcan>
(note: parent/child device model doesn't really work for the multi-die devices we have, assuming we don't want to pull this entirely outside of the die bus nodes, since the top-level cpufreq node has to span clusters on both dies)
<robher>
marcan: The performance-domain binding can do the mapping.
<marcan>
oh, that one's news to me. neat, mediatek uses it.
<marcan>
ok, so then that just leaves the question of how to break this up into multiple cluster nodes as it ought to be represented, instead of one magic single device
<marcan>
cpufreq-mediatek-hw.yaml is basically what we do today, other than not using that generic binding (which I wasn't aware of)
<robher>
marcan: For a virtual device, no need to put in DT. Just need the initcall to create platform device based on of_machine_is_compatible() and then it's probe can iterate over nodes by compatible.
<marcan>
of_machine_is_compatible, as in looking for apple stuff?
<robher>
right
<marcan>
huh, didn't know that was the recommended approach
<marcan>
so we'd just have our driver match on apple,arm-platform and then look for the cluster nodes (and bail if it finds none that it can handle, which is what would happen on as-yet unsupported platforms, or if it sees mixed compatibles since that'd be weird)
<marcan>
robher: does that make sense? if so, I can do that I think, for v3 (I think it was v3 :))
<robher>
marcan: Yeah, I think so.
<marcan>
cool! the last pending thing we had in the prior submission was the cpu->perf domain binding, which was nonstandard, so I think fixing that plus breaking up clusters will solve all remaining issues.
thelounge7571340 has quit [Remote host closed the connection]
thelounge7571340 has joined #asahi-dev
Gaspare has joined #asahi-dev
<sven>
[cpu4] [DCPTracer@/arm-io/dcpext] [mcdp29xx] [dcpav-service-epic0] < group 4 command 4
<sven>
uhhh...
<sven>
i guess the mcdp29xx endpoint in trace_dcp is mislabeled?
<marcan>
sven: I think it's mcdp29xx in some devices, but also more generally the dcpav stuff?
<marcan>
as in, mcdp29xx is one implementation of dcpav
<sven>
ah, could be
<marcan>
or something like that
<marcan>
the inheritance hierarchy is a bit confusing
<sven>
i'm starting to get a better understanding of that
<sven>
but the whole thing is very very weird in general
<sven>
that thing seems to do a lot of crap actually
<sven>
so [dptx] has [dcpdp-controller-epic0] and [dcpav-controller-epic0]. [epicep2a] has [dcpdptx-port-epic0] and [dcpdptx-port-epic1]
<sven>
epicep2a is something like dcpdptx then i guess.
<sven>
where did these names originally come from btw?
<marcan>
I think I got them either from the advertisement messages or from some rtkit ep name thing? I can't remember...
<sven>
hrm, ok. i'll probably go ahead and rename a few at least in the tracer then so that they make more sense
<sven>
it wouldn't surprise me if the names we have were made up apple. fit to the entire mess the rest of DCP is
<sven>
*by apple
* sven
should've cleaned up his code earlier
gladiac has quit [Quit: k thx bye]
thelounge7571340 has quit [Remote host closed the connection]
thelounge7571340 has joined #asahi-dev
chipxxx has quit [Read error: Connection reset by peer]
<marcan>
sven: please feel free to clean up / hack on that as much as you want
<sven>
I still wonder how “I’ll just bring thunderbolt up” ended with me reversing this dumb DCP IPC crap :D
<kettenis>
poor sven
<kettenis>
marcan: I read something about switching the firmware archive from tar to cpio in the backlog?
<kettenis>
that would be somewhat problematic for OpenBSD as we don't have cpio support on the installation media
<kettenis>
btw, I did some investigation on the DIT feature (data independent timing) that Apple implements
<kettenis>
did some benchmarking with "openssl speed" running a performance core and could not find any speed differences that are statistically significant
<marcan>
kettenis: interesting, I thought cpio was pretty universal (and it's very simple)
<kettenis>
well, our installation media are stripped down quite a bit
<kettenis>
for some architectures we still provide 1.44M floppy images ;)
<marcan>
I don't think that will be necessary for ARM64 ;)
<kettenis>
no kidding
<kettenis>
if switching to cpio has real benefits to you guys, I'll look at what needs to be done to include cpio support
<kettenis>
currently the makefile logic that disables it isn't architecture-specific
<_jannau_>
it makes it very easy to provide firmware in the initramfs since linux supports concatenated cpio archives
<_jannau_>
and that makes it easy to update the firmware in the rotfs. the initramfs can update it before it switches to os root
<_jannau_>
I'm using that since a few days for development and it works in practice. that is of course independent of what we do with normal installed systems. I can always repackage the firmware
<_jannau_>
I use it as well to inject matching kernel modules
<marcan>
could just keep the firmware in RAM too, and never put it in the rootfs (which also helps avoid accidental re-distribution by users)
<marcan>
kettenis: I suspect a polyglot ustar+cpio archive (that doesn't duplicate the data) can be done that would be accepted by both bsdtar and linux's cpio code, though I'm not sure if we want to push for such an abomination :D
<marcan>
I don't think it can be done fully compliant with both formats by spec, but probably with actual implementations
<kettenis>
probably not worth it
<kettenis>
firmware in RAM is an interesting idea, but would of course need driver support and probably DT binding changes
<_jannau_>
I assumed it ment copying the firmware into a tmpfs instead of the root fs
<marcan>
yeah, I meant moving the initramfs firmware into a tmpfs instead of the real rootfs
<kettenis>
not sure how you'd make that work across OSes
<marcan>
that would be a OS-specific thing
<marcan>
the firmware is just a CPIO archive in the ESP; linux bootloaders would load it as an additional initramfs and the main initramfs would handle the copying to a tmpfs mount. for BSD, up to you what you do :)
<marcan>
for the OS-independent portion the only change is the switch to cpio
<marcan>
and I would also have both versions for a while so as to not break your current installers of course, we have enough ESP space for that
<kettenis>
right
<kettenis>
OpenBSD 7.2 is pretty much done, so yes, if we can keep the tar file until OpenBSD 7.3 is released that would be good
<marcan>
yeah, I can keep it as long as necessary, no problem
thelounge7571340 has quit [Remote host closed the connection]
<marcan>
one nice thing is that cpio is mildly less annoying to parse than tar, so if u-boot needs to grow support for this to pull xHCI firmware (for full USB port support on those Macs that have asmedia controllers) it could do that, instead of having to extract that separately.
<mps>
I agree with kettenis
<mps>
though alpine have cpio by default
<marcan>
of course that's preconditioned on you getting PCIe xHCI support in first ;)
<kettenis>
yeah, I need to get back to that ;)
<kettenis>
having a proper dma mapping API in u-boot turns out to be rather painful :(
thelounge7571340 has joined #asahi-dev
<marcan>
:(
<marcan>
kettenis: btw, for the cpio version, we'd use the /lib/firmware prefix since it gets loaded directly by the kernel (so filenames as lib/firmware/foo). would that be a significant issue for you?
Gaspare has quit [Quit: Gaspare]
<marcan>
(could also go with something generic like vendorfw/ and put a symlink in the initramfs; just something other than the current tarbomb)
<kettenis>
an absolute path would be painful I think
<marcan>
not absolute, just adding at least one extra directory level
<kettenis>
don't think that would be a problem
<marcan>
it's implicitly absolute as loaded by Linux
<marcan>
I'm leaning towards (/)vendorfw/, since then we could symlink /lib/firmware/vendor to /vendorfw and add that to the kernel load list as I discussed (and it's nice and neutral)
<mps>
marcan: what if distro/installation doesn't use initramfs
<marcan>
and different distros might want to use /lib/firmware or /lib/firmware/vendor or something else and this gives them that choice
<marcan>
mps: shrug? then do it the same way you do it now with the tar
<mps>
marcan: ok, tar or cpio doesn't matter
<marcan>
the advantage of the initramfs is you don't have to play games with driver load order
<mps>
yes, I know pro and cons of using initramfs
<marcan>
if you don't have an initramfs then you absolutely need to ensure that e.g. xhci-pci is not built in, which therefore implies that your distro can't support USB keyboards (or USB anything) until the rootfs loads at least udev, and obviously can't support root-on-USB either with the same kernel
<marcan>
if that's a problem for you, get an initramfs ;)
<mps>
marcan: I have it working without initramfs fine and on usb stick also
<sven>
oh god, it does hdcp shit. i hope i can just disable that somehow
<marcan>
no you don't, not with asmedia ports
<marcan>
and it never will
<marcan>
because that needs firmware
<mps>
ah, didn't know about asmedia
MajorBiscuit has quit [Ping timeout: 480 seconds]
<mps>
thanks for info
<marcan>
(and if you don't provide firmware before the driver loads, it will fail to probe, and those machines will be stuck without USB on those ports)
<marcan>
so barring some horrible hackery with /sys/foo/bind, if you want asmedia support and usb boot support, you need an initramfs
<mps>
for now it works, will see later to add initramfs to usb media image
<mps>
(experience from chromebooks where initramfs is inconvenient)