thelounge7571340 has quit [Remote host closed the connection]
Etrien_ has joined #asahi-dev
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
Etrien has quit [Ping timeout: 480 seconds]
Etrien_ has quit [Read error: Connection reset by peer]
Etrien has joined #asahi-dev
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
<marcan>
I've reverse engineered custom ISAs before, it's not terribly hard once you can load your own code and get some output from it
<marcan>
(radeon F32)
<marcan>
single stepping helps too
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
user982492 has joined #asahi-dev
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
kenzie7 has quit []
kenzie7 has joined #asahi-dev
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
chengsun has quit [Quit: Quit]
chengsun has joined #asahi-dev
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
<chadmed>
num_codecs is no longer present in snd_soc_pcm_runtime as of 6.1...
Etrien_ has joined #asahi-dev
<povik>
chadmed: yes, you have to go through dai_link, so ->dai_link->num_codecs
<chadmed>
that only gives me 3 codecs, which i guess makes sense since the speaker array is across two cpu links
<chadmed>
so im just thinking of a smart way to handle that
<povik>
it should be equivalent
<chadmed>
so it would be fine to just do * 2 across one dai_link?
<chadmed>
that was my first thought i just didnt want to make that assumption without checking first
<povik>
no, that's not fine
Etrien has quit [Ping timeout: 480 seconds]
<povik>
i thought you were suspecting ->dai_link->num_codecs is not the same as what was in ->num_codecs
<povik>
it should
<povik>
chadmed: you are trying to get to the channel number/
<chadmed>
yeah the only thing is getting it out of hw params still gives me 8 since it creates enough to consume the entire clock, so what im trying to do is constrain the fe on startup based on the number of codecs the backend its connected to is comprised of
<chadmed>
but, num_codecs in dai_link on the backend is 3, which is wrong
<povik>
you probably want to save the max channel number in parse_of, use that in startup of fe
<povik>
and don't worry about the runtime fe/be connections
Etrien_ has quit [Read error: Connection reset by peer]
Etrien has joined #asahi-dev
SSJ_GZ has joined #asahi-dev
nepeat has quit [Ping timeout: 480 seconds]
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
<chadmed>
well that was relatively painless
<povik>
as it's supposed to be ;)
pjakobsson has quit []
chipxxx has joined #asahi-dev
pjakobsson has joined #asahi-dev
chip_x has quit [Ping timeout: 480 seconds]
<marcan>
jannau: I want to merge DCP today, just doing some cleanup first
<_jannau_>
ok, I won't have time before tonight CEST. not a problem if it goes in as is
<marcan>
does anyone know what the kernel policy is re sparse and drivers that will only ever run in same-endian platforms?
<marcan>
there's a lot of test robot spam about mixing endianness types, but I get the feeling the solution here isn't to add a truckload of dummy endian conversions to drivers which are guaranteed to never need them
<marcan>
maybe just not use __leXX types at all? but that feels wrong in its own way
<sven>
so the previous problem was that I messed up the afk dp->ap call handling. looks like now I also broke the ringbuffer handling itself :D
<sven>
marcan: I kinda like the __leXX types because that way it's obvious when some buffer is sent across to some other processor vs. when it's just some internal data structure
<marcan>
yeah, exactly
<marcan>
but then we need to use cpu_to_le16 etc everywhere or else sparse complains
<marcan>
which seems like more noise than anything on drivers for SoC devices
<marcan>
sometimes it's questionable... I'm adding those to spi-hid-apple-core because there's a chance a crazy person exists that will try to connect a modern Apple SPI trackpad to a PowerBook or something
<sven>
yeah, same for bluetooth. who knows if there's someone crazy enough to connect that pcie card to big endian machine with a pcie bus
<chadmed>
pushed to audio-stuff on my local branch, feedback welcome :)
<marcan>
oh come on sparse
<marcan>
drivers/soc/apple/dockchannel.c:229:25: sparse: sparse: cast removes address space '__iomem' of expression
<marcan>
if (IS_ERR(dockchannel->config_base))
<marcan>
return (void *)dockchannel->config_base;
<marcan>
well yeah duh, it's an ERR_PTR now
<marcan>
... I have no idea what the right way to shut it up here is, short of converting through an int and back which is dumb
<sven>
huh, bluetooth just disappeared from patchwork *sigh*
<sven>
guess i'll rebase and send another version later today
<j`ey>
IOMEM_ERR_PTR :P
<marcan>
oh, __force
<marcan>
j`ey: yeah but I need to cast it :p
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
pjakobsson has quit [Remote host closed the connection]
pjakobsson has joined #asahi-dev
chadmed_ has joined #asahi-dev
davido has joined #asahi-dev
davido is now known as capta1nt0ad
nepeat has joined #asahi-dev
King_In0 has joined #asahi-dev
King_InuYasha has quit [Read error: Connection reset by peer]
capta1nt0ad has quit [Quit: Konversation terminated!]
capta1nt0ad has joined #asahi-dev
capta1nt0ad has quit []
<sven>
huh, so my code sets the write pointer from 0xc80 to 0xd40 but in the tracer it looks like DCP tries to read past that for some reason from 0xd40 to 0xd80 and sets the read pointer to 0xd80 then and continues to increment it by 0x10 until it eventually crashes
capta1nt0ad has joined #asahi-dev
chadmed_ has quit [Quit: Konversation terminated!]
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
capta1nt0ad has quit [Quit: Konversation terminated!]
capta1nt0ad has joined #asahi-dev
<marcan>
sven: did you get the wrapping behavior correct?
<marcan>
it has this thing where if a message doesn't fit at the tail of the buffer, you're supposed to just have the header there and then the header again at 0
<sven>
it doesn’t even wrap yet
<marcan>
sven: maybe the message size is off and it uses that to advance the ring?
capta1nt0ad has quit [Quit: Konversation terminated!]
capta1nt0ad has joined #asahi-dev
capta1nt0ad has quit [Quit: Konversation terminated!]
capta1nt0ad has joined #asahi-dev
kov has quit [Quit: Coyote finally caught me]
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
chadmed_ has joined #asahi-dev
<chadmed_>
povik: https://tpaste.us/pnVx <-- frontends opening with zero channels before being populated
<povik>
i need to see that print
<chadmed_>
dev_info(rtd->dev, "Starting FE with %d channels", fe_chans); fe_chans being the number of channels from rtd->dpcm->hw_params
<chadmed_>
opening the frontend in .startup while it is in this state results in an -EINVAL regardless
<povik>
yeah, i don't think you should be looking into hw_params at *that* stage
<povik>
you may as well consider it uninitialized
<chadmed_>
yeah but the problem is that .startup tries opening it while its in that state to set the constraint
<chadmed_>
which returns the -EINVAL and tears the frontend down until you reload the module
<chadmed_>
which is why i gated that behind waiting for it to have some channels associated with it
<povik>
i mean you can't be looking into hw_params from .startup callback
<povik>
so that print doesn't mean anything
<povik>
the -EINVAL was probably because there was zero intersection of the applied constraints
<povik>
so it knew at that point already the configuration is invalid
<povik>
could it be because you were constraining headphones to 6 channels?
<povik>
or rather the primary frontend, it gets a <2 channels constraint from MCA because of slots
<chadmed_>
thats what im thinking, which is why i now have the constraint gated behind if (fe_chans > ma->max_channels)
<povik>
that's still not okay
<povik>
you should apply an upper bound constraint, as i said
<povik>
that fe_chans is meaningless, by .startup stage the PCM doesn't yet have a fixed number of channels
<jannau>
marcan: notchless modes are missing in dcp, I have code for that but I haven't figured out why it breaks fbcon, results black console but X and wayland compositors are working as expected
<sven>
atcphy.py + linux dcp driver
<sven>
time to get rid of atcphy.py and move that into atcphy.c now :)
<j`ey>
sven: so atchphy.py just runs before linux boots for now?
<jannau>
sven: \o/ any changes in apple_drv / iomfb required?
<sven>
nope
<sven>
just doing the dptx stuff correctly and then everything works
<povik>
cool
<chadmed>
ok all fixed! sorry for all the silly errors, its been a long day
<chadmed>
i also realised that the IRs would have sounded like crap for anyone who didnt know to force PW to resample everything to 96khz, so the config fragment now does that
<marcan>
j`ey: rust is supposed to be 0, that's why it's a base (and there is no lina)
<jannau>
marcan: if you test dcp a t8103 laptop would be a good target to start. the imac comes back from dpms/sleep with minimal brightness. If that happens on m1 air and pro 13" as well we to look into display brightness control
capta1nt0ad has quit [Quit: Konversation terminated!]
<jannau>
I think brightness control requires set_block_dcp() calls (I suspect either calibration or temperature data) and then set property calls with numeric IDs which at least differ betwee m1 (imac) and m1 max (macbook pro 14")
<j`ey>
marcan: ah, git rev-parse --verify "bases/$name" changed to git rev-parse --verify "$ROOT/bases/$name" and now I get: 210-gpu 0
chadmed has quit [Remote host closed the connection]
<povik>
chadmed: no worries. the commit message isn't perfect but we can pick it up all the same
<povik>
once the time comes i will squash it into base macaudio commit for upstream submission, is that okay by you?
<marcan>
j`ey: whoops, that was a mistake
<marcan>
fixed
<marcan>
jannau: someone reported random brightness lowering on closing certain WMs
<marcan>
jannau: well, it times out on RTKit boot on an M1 Air, so not a good start :p
<marcan>
let me see what's up
<_jannau_>
with lina's gpu branch? the dcp branch in there might trigger the dpms code path on ending WMs
<_jannau_>
marcan: check dcp-dart first
<marcan>
no, it's just dead, it's the dart I think
<marcan>
with my merge
<marcan>
I may have screwed up some patch
<_jannau_>
I was replying to the random brightness lowering
<marcan>
ah, that was someone else with lina's old branch, yeah
<marcan>
I think I had an old m1n1, it came up now but black screen
<marcan>
this might just be brightness=0?
<marcan>
I don't see backlight leak
<marcan>
[ 2.573136] apple-drm soc:display-subsystem: [drm] Cannot find any crtc or sizes
<marcan>
is that supposed to happen?
<marcan>
it seems to detect a hotplug and set mode after that
<sven>
jannau: fwiw, parser.c leaks memory for about every parse_string call right now
<_jannau_>
marcan: no, that's not supposed to happen
<_jannau_>
sven: complain to alyssa. I'll fix it
<sven>
:D
<sven>
wasn't complaining, just something I noticed while reading the code :)
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
<marcan>
I'm getting random SMC command timeouts when running dmesg in a hypervisor console, and I don't know why but I suspect mailbox again
<sven>
we should really just drop that thing
<sven>
it's just silly how much issue we have with that should be a irq handler with a MMIO read in a loop + a function that does a single MMIO write
<sven>
*issues
<marcan>
yeah...
<marcan>
_jannau_: yes, the backlight definitely turns off when DCP loads
<marcan>
but also those errors
<sven>
jannau: you can also drop all dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32)) since 32bit is the default dma mask anyway
<_jannau_>
marcan: I don't see that on j314c or j457. is dcp turing the backlight off or is it simpldedrm on unload?
<_jannau_>
have you tested it on a mac mini?
<marcan>
okay yeah it works now
<marcan>
the backlight stuff was always intended to go away with DCP
<_jannau_>
simpledrm was turning the backlight off?
<marcan>
yes
<marcan>
and possibly breaking dcp
<marcan>
the idea was always to remove the backlight stuff when we introduce DCP
<marcan>
it's incompatible by definition
<marcan>
I'm going to make it a separate kconfig for backlight support and make them mutually exclusive
<marcan>
since we intend to have two kernels but just config changes, not DT changes
<_jannau_>
seems to cause no problems on j314c
<marcan>
entirely possible DCP manages that gpio on j314c and not j313
<marcan>
either way this was always a bad idea
<marcan>
the backlight thing was always a hack
<marcan>
only usable without DCP
<marcan>
_jannau_: are you sure the brightness control problems aren't just due to the same conflict?
<marcan>
_jannau_: nah, indeed after dpms it comes back at min
<marcan>
so yeah, we need brightness control
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
kov has joined #asahi-dev
Dementor has quit [Remote host closed the connection]
Dementor has joined #asahi-dev
<marcan>
want to hear some good news?
<marcan>
POWER_SUPPLY_CURRENT_NOW=-233000
<marcan>
POWER_SUPPLY_TIME_TO_EMPTY_NOW=65280
<marcan>
POWER_SUPPLY_CURRENT_NOW=-137000
<marcan>
POWER_SUPPLY_TIME_TO_EMPTY_NOW=110040
<marcan>
DCP gives us 70% better idle (and by extension s2idle) battery life.
<marcan>
told you.
<j`ey>
yay
<veloek>
That's awesome! :)
<Dementor>
marcan, awesome work !!
<marcan>
>30h on M1 MBA right now
<marcan>
I sure hope people don't complain ;)
<marcan>
not as good as macOS yet but better than anything x86, that's for sure
<marcan>
anyway, pushed another kernel batch with a config to disable the backlight stuff if DCP is compiled in
<Dementor>
marcan, you know people will complain but 30h on M1 MBA is really good !
<jannau>
I wonder how that looks on the 14/16" macbooks pros but I guess most additional powerdraw (if any) there is the the backlight and 120Hz display refresh which we currently do not use
<mps>
would these latest merge work with second stage m1n1 1.1.6
<_jannau_>
don't do that then. I thought I prevented that with completions but I haven't stress tested it
<sven>
ok :D
<sven>
can't even reproduce it easily
<sven>
it also breaks forever when it needs to switch the link rate but that's kinda expected since I fake all that atm
<marcan>
don't make me ask Lina to rewrite DCP in Rust... :p
<sven>
that certainly would've made this entire AFK stuff less horrible...
<marcan>
(seriously though, this needs to be actually reliable/stable for us to push it to users, not just in light testing but abuse too)
<sven>
the dpalt stuff needs a lot more work anyway
<sven>
but it seems to be great to break regular dcp code as well ;)
<sven>
(and mailbox ofc)
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
<_jannau_>
I'm proably far too optimistic with the timeout duration and don't have a good idea what to do when the completion timeouts and dcp hasn't crashed
<sven>
hrm, this "channel depth" thing confuses me
<_jannau_>
dcp crash on swap calls if there is already ongoing communication. drm more or less guarantees that there are no concurrent calls but we porbably should use a mutex
<_jannau_>
axboe: I might have broken M1 Pro
<_jannau_>
marcan: I guess we have to use different dcpext tables for t6000 and t6001/2 in m1n1
<marcan>
_jannau_: or just not return an error
<marcan>
(which is what I just did)
<marcan>
it failed trying to map the dcpext4 carveout, so it sounds like it would only work on Ultra? unless the Max iBoot also has the Ultra regions (but then the Pro one has the Max ones?)
<_jannau_>
hmm, region -id-127 is dcpext4, why is it looking for that at all
<marcan>
because you're looking for all DCPs
<marcan>
you return without error when the alias is missing
<marcan>
so it just keeps going
<_jannau_>
do I access the carveout before virifying the alias exists?
<marcan>
yes
<marcan>
you should probably actually return an error on missing alias, and just have the calling code not propagate it and break the loop
<marcan>
or that
<_jannau_>
it works then only by accident on the m1 max
<marcan>
lol
<marcan>
I added a quick fix to not propagate the error for now
<marcan>
but yes, you should probably just reorder the code
<marcan>
PRs welcome etc :)
<_jannau_>
i.e. it has enough carvouts to not fail
<marcan>
I expect those IDs to be reserved for DCP anyway
<marcan>
but I guess the Max has all the Ultra ones for whatever reason
<_jannau_>
the fdt reserved memory node label, might be also used for the node name
<marcan>
I guess that means it's not :)
<marcan>
_jannau_: so should I schedule a stream to work out brightness control, or do you want to look at that yourself? :)
<marcan>
(otherwise it's going to be the PSCI thing next I guess?)
<_jannau_>
how fast do we want to have brightness control? I suspect some binary reversing could be helpful (which I haven't started with according to policy)
<_jannau_>
from a tracing standpoint brighness control looks opague
<_jannau_>
there is a set property call with a numeric id which looks like it is brightness control
<_jannau_>
but just repeating those calls does not work or crashes dcp
<_jannau_>
also it looked like dcp issues brightness related callbacks before that call
<marcan>
_jannau_: we can't ship DCP until this is in, so...
<marcan>
there's a pile of backlight calibration data in the ADT
<marcan>
_jannau_: it sounds like we probably need to upload some/all that data and then just set the backlight property, probably?
<_jannau_>
strings on the firmware suggests it's afk calls which I don't see in macos tracing so maybe iboot does that already
<marcan>
could be (since iboot has to set the backlight already)
<marcan>
so then maybe it's just something dumb
* marcan
installs macOS 12.3 on the MBA
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
King_In0 has quit []
<marcan>
null: I'm certainly fine with non-UEFI if you think we can specify exactly what the call semantics should be cleanly (especially re the MMU)
<marcan>
ISTR that back in the day that was considered and the conclusion was we'd be reinventing UEFI, but it's been a while
King_InuYasha has joined #asahi-dev
<marcan>
(and yes, this is for the ML at some point, but it also doesn't hurt to have a PoC and it's not like we haven't shipped dozens of those to our users already, and changed them 3 times each, much to kettenis' chagrin :p)
<marcan>
so I'm very interested in what you think a first approximation take should be like and I'd be happy to run with that and see how it goes
<null>
marcan: I don't recall the discussions for the "reinventing UEFI" part, but I think there's been a lot of point-to-point conversions between people and not necessarily a single joined up story
<marcan>
yeah, I agree
<null>
... so I might just have missed that
<marcan>
and it's also been long enough to be worth having a proper discussion anew anyway
<marcan>
but what's your take on it?
<null>
A first approximation would be spin-table with a cpu-return-address or similar to do hotplug, specified a bit like the ePAPR spin-table (which arm64's spin-table is a not-quite-clone of), but I'll admit I haven't thought much about idle rather than hotplug
<marcan>
yeah, we'd need something for idle, but also that doesn't really work power-wise unless we come up with a signaling mechanism more refined than "just spin on a wfe"
<null>
Mhmm, that is a fair point
<marcan>
I think regardless of whether UEFI is in the mix or not, we're going to end up reinventing PSCI poorly...
<marcan>
not that I'm opposed to doing "PSCI, but simpler" if you think it's the way to go, but it's going to have to be some kind of call-based interface at some point
<null>
I think wahatever we do we'll end up reinventing PSCI; I just don't want us to be under the illusion that what we're making is PSCI, since there are big differences in a number of areas
<marcan>
what are the major differences?
<null>
If that has to go thourhg UEFI runtime services then my main concern would be that it is plumbed separately from PSCI, even if it's PSCI-inspired
<marcan>
I think if it's not going to be PSCI, and it's going to be via runtime services, then we might as well drop the layer and just call it a bespoke UEFI protocol
<marcan>
but my impression was that people were really dead set on PSCI as the One True Way, hence the idea of tunneling it via UEFI
<marcan>
if you think there's room for something other than spin-table and psci that isn't just a version of either, then that changes the situation
<null>
This is a bit difficult to write-up since there's a number of overlapping concerns, and I need to think for a bit to get the concepts in order
<marcan>
yeah
<marcan>
also re MMU off, that *works* but performance of these things with caches off is pretty abysmal, FWIW
<null>
mhm
<j`ey>
marcan: for idle or cpu off/on.. does that matter?
<marcan>
might be okay for just a cpuidle trampoline though, that doesn't have to touch RAM other than for the GPR save/restore...
<marcan>
but I imagine the overhead is probably measurable
<null>
For the *conduit*, HVC/SMC vs UEFI: HVC/SMC are easy to do in any kernel context, but UEFI means we have to mess with TTBRs, and use a lot more infrastrucure, which ends up interacting with things like lockdep/rcu/context-tracking more painfully, and will need a lot of thought. That's definitely an ML disucssion
<marcan>
yeah
<marcan>
I wonder if it would make sense to just have it "integrate" into the kernel
<marcan>
require that the entire runtime thing is position-independent, and provide a descriptor of what MMIO/RAM regions it wants mapped. kernel makes sure those are mapped, fills in the pointers, maps it in kernel space, then just calls it
<null>
For the "one true way", I understand and agree with the principle that PSCI *should* be the one way, and we don't want any more implementations than strictly necessary. If we need a generic PSCI analogue for systems without EL2 I'm ok with that, and would prefer that we don't articifically try to force that into PSCI, but others seem to have different views there
<marcan>
(some inspiration from coprocessor mapping stuff there)
<marcan>
then you wouldn't have to mess with TTBRs
<null>
Maybe, but then you have to always have that mapped, and for things like control flow integrity we don't really want to have FW-provided pages mapped executable all the time
<marcan>
yeah, you'd need to play tricks to unmap it sometimes
<null>
I guess my major point of contention here is "pretending this is PSCI"; if this is a "PSCI-like, but separate" UEFI runtime service, I'm not opposoed to that. That way we can manage the distinct parts (e.g. all the conduit subtleties above) separately and more manageably
<marcan>
sure, and I'd be perfectly fine with "PSCI-inspired but simpler UEFI runtime protocol"
<null>
Cool :)
<null>
I'm afraid I need to disappear shortly, but I can reply to things tomorrow and/or follow up on the list
<marcan>
yeah, I need to get some sleep too
<null>
Oh yes, I forgot which timezone you were in!
<marcan>
any particular lists I should CC if I start this?
<marcan>
(l-a-k, lkml, asahi, anything else?)
<null>
I reckon just linux-arm-kernel would be good, with Ard Biesheuvel, Will Deacon, Catalin Marinas, and myselfg
<marcan>
cool. I assume maz might also be interested, and the usual suspects from around here
<null>
Yes
<marcan>
got it, I'll see if I can type something up tomorrow
<null>
Cool; have a good evening!
<marcan>
thanks! you have a good day :)
<maz>
marcan: yup, count me in.
<marcan>
kettenis, j`ey, sven, jannau, anyone else? I assume everyone's subscribed to asahi@ anyway, but let me know if you're explicitly interested
<maz>
I'm not on asahi@ (too many MLs...)
<null>
Oh, now I re-read the above, to clarify: the set I listed was a "please include" rather than "please limit to"
<marcan>
hey, it's pretty low traffic (so far) :p
<marcan>
null: yeah, I read it correctly :)
<marcan>
don't think we need a secret cabal to bikeshed a PSCI alternative :p
<sven>
bikesheds need as many people as possible anyway!
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
thelounge7571340 has quit [Remote host closed the connection]
nela has quit [Ping timeout: 480 seconds]
nela has joined #asahi-dev
philm has joined #asahi-dev
jluthra_ has quit [Remote host closed the connection]
jluthra_ has joined #asahi-dev
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
<jannau>
lol, fbcon with dcp works only accidentially on the macbook pro 14/16". due to the notchless framebuffer none of the modes match in size and and it sets the preferred 120Hz mode
MajorBiscuit has joined #asahi-dev
<jannau>
if dcp offers notchless modes too, fbcon selects 60 Hz since it matches the boot mode (60 Hz is assumed default), this requires a modeset and fails somehow
<jannau>
not sure yet if fbcon or dcp is to blame for that
<jannau>
hmm, still broken with 120Hz simpledrm, issue seems to be that the atomic_modeset has no changed flags set if drm debug is to be trusted
ad0 has joined #asahi-dev
ad0 is now known as ad1
capta1nt0ad has joined #asahi-dev
<kettenis>
sorry, travelling for $DAYJOB so I wasn't around this afternoon
<kettenis>
but to me the whole point about the idea of having a UEFI conduit for PSCI is that you could have the MMU *on*
<kettenis>
and that the same conditions under which you'd make EFI runtime calls would apply to PSCI calls
<kettenis>
also, whatever regions are needed for the code to function would part of the UEFI memory map
<kettenis>
if the actual code that implements the PSCI calls would live in m1n1, we'd still need a way to communicate this through the device tree
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
<jannau>
sigh, I see nothing wrong with the notchless framebuffer from fbcon
<ChaosPrincess>
acpi has a thing called platform runtime mechanism, which is basically doing what we want - calling into firmware w/o going to another exception level. Maybe we can reuse that, but hook it up with the device tree instead of acpi?
MajorBiscuit has quit [Read error: No route to host]
<kettenis>
that PRM stuff reads as typical ACPI stuff; overdesigned and yet woefully underspecified at the same time
<kettenis>
and besides that, we don't have (and as far as I'm concerned won't have) ACPI on these systems
Etrien has quit [Ping timeout: 480 seconds]
Etrien_ has quit [Read error: Connection reset by peer]
Etrien has joined #asahi-dev
<ChaosPrincess>
yes, that is correct, but you can use the binary abi, while putting the acpi table goop in device tree instead
SSJ_GZ has quit [Ping timeout: 480 seconds]
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
roblg has joined #asahi-dev
roblg has quit [Quit: Page closed]
nicolas17 has joined #asahi-dev
<jannau>
lol, fbcon and dcp apparently have conflicting ideas where the framebuffer is. the mapped physical memory in dart-dcp is just back. verified with proxy memsets
<jannau>
no idea where fbcon thinks its framebuffer is
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]