SSJ_GZ has quit [Read error: Connection reset by peer]
SSJ_GZ has joined #asahi-dev
SSJ_GZ has quit [Ping timeout: 480 seconds]
DragoonAethis has quit [Quit: hej-hej!]
DragoonAethis has joined #asahi-dev
thelounge7571340 has quit [Read error: Connection reset by peer]
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
thelounge7571340 has joined #asahi-dev
dmmcf has joined #asahi-dev
thelounge7571340 has quit [Read error: Connection reset by peer]
thelounge7571340 has joined #asahi-dev
chadmed has quit [Remote host closed the connection]
dmmcf has quit [Quit: dmmcf]
kov has quit [Quit: Coyote finally caught me]
thelounge7571340 has quit [Remote host closed the connection]
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
thelounge7571340 has joined #asahi-dev
SSJ_GZ has joined #asahi-dev
<jannau>
marcan: I've still haven't heard anything from Joerg. he handled some iommu fixes yesterday. I would take the dart t6k dt binding commit and reply to it that you will merge since you have dt changes which depend on it for verification (if you want to prepare/send) your pull request today
thelounge7571340 has quit [Read error: Connection reset by peer]
<marcan>
arnd: There are 3 patches in that tree starting from v6.0-rc1, two of them are code, one is the binding (all for the same thing). I can base the DT series on that point and send you a pull for that and you can merge it in, or I can just do the DT series and then the checker will complain until both branches are merged...
tdamdspurlt^ has joined #asahi-dev
<marcan>
and ha, the binding for apple,aic.yaml is wrong and says fiq-index instead of apple,fiq-index is wrong. that needs to be fixed, but it looks like that has been there forever? I guess the dt checker started catching that recently?
<_jannau_>
marcan: that's fixed and in 6.0-rc6
<marcan>
ah, good, couldn't find the patch
<arnd>
marcan: I'm confused now, which binding patch is this? I don't want to merge large chunks of the asoc tree, so rebasing on top of that would not work unless the patches are right on top of rc1
<marcan>
the 3 patches are in fact right on top of rc1
<arnd>
is the binding the first one?
<marcan>
it's just the binding patch went in last, so the 2 code patches are in that tree
<marcan>
ah but hold on, looks like for-6.1 was rebased? I got those commits from the hashes as they were applied to for-next, but that might not work now...
<marcan>
let me check if they're proper parents of for-6.1
<marcan>
ah, they are
<marcan>
so what I said still stands: I can rebase on that point and that history is in what's going into for-6.1, so it'll merge cleanly
<marcan>
but it does mean pulling in the 2 code patches since they came first
<marcan>
6ed462d1c11675064 in the above tree fwiw
<marcan>
otherwise, we can punt the MCA part of the DTs to next cycle
thelounge7571340 has quit [Remote host closed the connection]
thelounge7571340 has joined #asahi-dev
<marcan>
arnd: let me know what works best for you
<arnd>
marcan: I'll take the branch without the binding patch then. The warning does not show up in a plain allmodconfig build, and the driver change is a bit larger than what I'm comfortable with having in the dt branch
<arnd>
I sometimes merge in smaller dependencies outside of arch/*/boots/dts/* when there is a strong reason, but otherwise try to keep the arm/dt branch having only dt changes to ensure that there are no incompatible binding changes
<marcan>
got it, I'll just send you the DT series then. There is also that FIQ fix that is in -rc6, but that was a longstanding problem anyway, not a regression.
<arnd>
ideally you should try to do the binding changes before code changes in another branch, so you can just merge in the binding commits (on top of rc1) into the dts branch
<povik>
marcan: don't forget the ADMAC reset series then
<povik>
ah, that's on me maybe? how did i order them?
<povik>
broonie reordered them, because i threw one patch into the series that wasn't for him
<marcan>
I didn't see that, but I think I don't have the reset patches in bits/? (only the binding/dt changes)
<marcan>
I do see a bunch of this though:
<marcan>
[ 12.105159] apple-mca 39b600000.mca: ASoC: error at snd_soc_dai_hw_params on mca-pcm-1: -22
<marcan>
[ 12.106198] Secondary: ASoC: error at __soc_pcm_hw_params on Secondary: -22
<marcan>
[ 12.107021] Secondary: ASoC: error at dpcm_fe_dai_hw_params on Secondary: -22
<_jannau_>
think those are expected with disabled speakers
<marcan>
ah, ok
<povik>
yes, if you are opening a subdevice with no route, essentially
<marcan>
povik: I assume your reset series supersedes dmaengine: apple-admac: Pull shared reset control?
<povik>
it does
thelounge7571340 has quit [Remote host closed the connection]
<povik>
that was before i realized i can do pulses on shared resets still
<povik>
before i thought the reset subsystem can only do asserts/deasserts on shared resets
<marcan>
ok, added that and fixed the resulting conflict, merging again
<povik>
thanks
thelounge7571340 has joined #asahi-dev
<marcan>
smoke test looks good; pushed everything to asahi-wip.
<marcan>
arnd: how much in a rush are you? I can send the pull now, or push a kernel out to -dev and let folks test it a couple days first to make sure the series as merged is good
<arnd>
marcan: I still have a bit of a backlog to handle first, no need to send it right away
<marcan>
ack, expect it this weekend then
<marcan>
thanks for the help :)
<arnd>
marcan: is it in linux-next already?
<marcan>
I don't think linux-next pulls us?
<marcan>
I don't actually know how we get into linux-next :)
<arnd>
ah, I see. You may want to email Stephen Rothwell <sfr@canb.auug.org.au> cc lkml then to give a URL to add to linux-next.
<marcan>
I see!
<arnd>
most platform maintainers have their tree added to linux-next, which gives a little wider CI testing from all the bots before I pull the contents
<marcan>
yeah, that makes sense
<marcan>
I guess I should keep a for-next branch I merge trees with patches into then
<arnd>
yes, that also documents nicely what you plan to send me, which can come in handy when I look at the contents early, or for other folks that are interested
<marcan>
cool, makes sense!
<arnd>
most trees have some variant of "for-next" and an an additional "fixes" branch, with the latter being for stuff that should get in before the merge window but could also benefit from linux-next testing
<marcan>
ah, right, I'll make a (trivial) fixes branch too and mention it then
<marcan>
(well, I already had one, I'll just fast forward it so it's more obvious it's all merged already)
Major_Biscuit has quit []
MajorBiscuit has joined #asahi-dev
<marcan>
email sent :)
<marcan>
asahi-6.0-rc6-1 tagged and pushed, that's my prior smoketest plus the reset fix change (assuming it works, about to find out with a proper kernel package now)
<zzywysm_>
marcan: why does asahi-wip have hundreds of seemingly non-asahi-related, vaguely sound-ish commits on top of it?
<j`ey>
bits/070-audio
<_jannau_>
1it contains sound/for-6.1 for mca dt-binding dependency
<zzywysm_>
ah, thanks
<_jannau_>
also replaces the audio bits with the ones already queued for 6.1
<sven>
huh, does dcp.py crash DCP for anyone?
<_jannau_>
before displaying anything?
<sven>
yeah
<_jannau_>
it has no teardown code
thelounge7571340 has quit [Remote host closed the connection]
<_jannau_>
on dcp or dcpext0?
<_jannau_>
mac mini?
<sven>
dcp0 on mac mini
<_jannau_>
it didn't when I created the pull request
<sven>
wait.. it worked now I think
<sven>
and it also complains about "[syslog] * [PmgrService.cpp:319][AFK]_pmgrConfigVideoClock Failed to configure video clock freq= 74250000" it seems
<sven>
okay.. it sometimes crashes for some reason :/
<sven>
looks like it reliably crashes when I have the cable already connected during boot
<sven>
looks like "[syslog] * [nifiedPipeline.cpp:6553]set_digital_out_mode returned 80000104" is the actual error
<sven>
(for dcpext)
<jannau>
works for me with chainloaded m1n1 but not with the not that old installed m1n1
<jannau>
I guess it crashes because we continue after the set_digital_out_mode() error
<sven>
no
<sven>
regular dcp.py crashes
<sven>
using regular dcp
<sven>
even when chainloading m1n1 before
<sven>
but maybe my installed m1n1 is much too old
<jannau>
ah, I overread the dcpext
<sven>
both dcp (sucessful) and dcpext (fails set_digital_out_mode) complain about "[syslog] * [PmgrService.cpp:319][AFK]_pmgrConfigVideoClock Failed to configure video clock freq= 74250000"
<sven>
so that video clock thing is probably a red herring
<jannau>
does the installed m1n1 already shuts dcp down after configuring the display?
<sven>
I think so. it prints "TTY> display: Sleeping DCP (external)"
<sven>
and "TTY> pmgr: resetting device 0.DISP0_CPU0"
<jannau>
no "Failed to configure video clock freq=" here for dcp
<sven>
weird
<sven>
maybe it's something in this strange dp -> hdmi -> usb3 chain
<sven>
oh, i dunno if you need to enable extra debug for that message
<jannau>
I don't know why I thought it was already merged
<jannau>
ok, I'm not
<sven>
I merged it into my branch
<sven>
ah
<alyssa>
why don't any key bindings work for me in firefox now ..
<alyssa>
works after a restart, oh well
<jannau>
extended logging works now and I get "_pmgrConfigVideoClock Failed to configure video clock freq= 74250000" but it still works, even for an uninitilized display
<jannau>
dcp still doesn't work for you? did you revert the changes to rt_bandwidth_setup_ap for dcp\
skrzyp has quit [Quit: -help]
<sven>
it works if I don’t have anything plugged in during boot
<alyssa>
dcp0 doesn't work?
<jannau>
that could be a hint that your installed m1n1 is too old
<sven>
yeah, could be. I also don’t care too much
<alyssa>
m1n1 has a half-life of a few momnths, you know
<sven>
just wanted to compare DCP vs dcpext
<alyssa>
:p
<alyssa>
sven: also, what OS/firmware version are you on?
<sven>
who knows
<sven>
I think I updated at the last major release
<alyssa>
that matters a lot, dcp versioning is very picky.
<alyssa>
I think 12.3 is what we support these days for dcp
<sven>
yeah, I think I have that
<alyssa>
OK
thelounge7571340 has quit [Remote host closed the connection]
<jannau>
12.3 is "system-firmware-version = iBoot-7459.101.2"
<sven>
will check tomorrow, DCP annoyed me enough for today ;)
thelounge7571340 has joined #asahi-dev
gladiac has quit [Quit: k thx bye]
thelounge7571340 has quit [Ping timeout: 480 seconds]
CME has quit [Ping timeout: 480 seconds]
Glanzmann has joined #asahi-dev
<Glanzmann>
marcan: If we're supposed to test the rebase, than my rcu hangs are gone, but I have no sound on the mini with the new kernel: dmesg: https://pbot.rmdir.de/BwoepFUZlYzjxF-0dLOStg if not disregard.
Glanzmann has quit [Quit: EOF]
<marcan>
sven: the problem with those error codes is a lot of them are highly overloaded, so it may or may not help find the place in the firmware, but you can certainly try
<marcan>
the firmware is, uh, variable
<marcan>
C++ so lots of vtables I'm too lazy to trace
<marcan>
but you can usually find thingsd
<marcan>
I did work out that dcp.system.system.setProperty thing from firmware only
<sven>
highly overloaded doesn’t sound like fun :/
<povik>
Glanzmann: you should enable cs42l83
<povik>
still a weird error you get
<povik>
[ 2.346125] cs42l42 2-0048: ASoC: error at snd_soc_component_update_bits on cs42l42.2-0048 for register: [0x00001208] -6