ChanServ changed the topic of #asahi-dev to: Asahi Linux: porting Linux to Apple Silicon macs | General development | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Logs: https://alx.sh/l/asahi-dev
sirn has quit [Server closed connection]
sirn has joined #asahi-dev
yuyichao has quit [Ping timeout: 480 seconds]
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
user982492 has joined #asahi-dev
user982492 has quit []
Dcow[m] has quit [Server closed connection]
Dcow[m]1 has joined #asahi-dev
ianlienfa[m] has quit [Server closed connection]
ianlienfa[m] has joined #asahi-dev
jeh[m] has quit [Server closed connection]
jeh[m] has joined #asahi-dev
SocioProphet[m] has quit [Server closed connection]
SocioProphet[m] has joined #asahi-dev
yuyichao has joined #asahi-dev
IvanMaksimovic[m] has quit [Server closed connection]
IvanMaksimovic[m] has joined #asahi-dev
user982492 has joined #asahi-dev
Emantor has quit [Quit: ZNC - http://znc.in]
Emantor has joined #asahi-dev
phiologe has joined #asahi-dev
PhilippvK has quit [Ping timeout: 480 seconds]
drwhax[m]1 has quit [Server closed connection]
drwhax[m]1 has joined #asahi-dev
l3k[m] has quit [Server closed connection]
l3k[m] has joined #asahi-dev
RianSouzaSantos[m] has quit [Server closed connection]
RianSouzaSantos[m] has joined #asahi-dev
kov has quit [Quit: Coyote finally caught me]
kov has joined #asahi-dev
mini has quit [Server closed connection]
mini has joined #asahi-dev
ybk[m] has quit [Server closed connection]
ybk[m] has joined #asahi-dev
josipknezovic[m] has quit [Server closed connection]
josipknezovic[m] has joined #asahi-dev
NotHere[m] has quit [Server closed connection]
NotHere[m] has joined #asahi-dev
rethematrix[m] has quit [Server closed connection]
rethematrix[m] has joined #asahi-dev
Rhys[m]12 has quit [Server closed connection]
Rhys[m]12 has joined #asahi-dev
blasty has quit [Server closed connection]
blasty has joined #asahi-dev
chengsun_ has quit [Server closed connection]
chengsun has joined #asahi-dev
kit_ty_kate has quit [Server closed connection]
kit_ty_kate has joined #asahi-dev
akemin_dayo has quit [Server closed connection]
akemin_dayo has joined #asahi-dev
M0x8FF[m] has quit [Server closed connection]
M0x8FF[m] has joined #asahi-dev
DarkShadow44 has quit [Server closed connection]
DarkShadow44 has joined #asahi-dev
krirogn[m] has quit [Server closed connection]
krirogn[m] has joined #asahi-dev
NightsOnly[m] has quit [Server closed connection]
NightsOnly[m] has joined #asahi-dev
kenzie35 has quit []
vup has quit [Server closed connection]
c10l3 has quit [Server closed connection]
c10l3 has joined #asahi-dev
kenzie35 has joined #asahi-dev
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
dhewg has quit [Server closed connection]
dhewg has joined #asahi-dev
milek7_ has joined #asahi-dev
milek7 has quit [Server closed connection]
bisko has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
the_lanetly_052 has quit [Ping timeout: 480 seconds]
perigoso[m] has quit [Server closed connection]
perigoso[m] has joined #asahi-dev
nsklaus_ has quit [Quit: Textual IRC Client: www.textualapp.com]
DanielHuisman[m] has quit [Server closed connection]
DanielHuisman[m] has joined #asahi-dev
Liam[m] has quit [Server closed connection]
Liam[m] has joined #asahi-dev
Ferluci[m] has quit [Server closed connection]
Ferluci[m] has joined #asahi-dev
DanStrong[m] has quit [Server closed connection]
DanStrong[m] has joined #asahi-dev
pulpy_orange2[m] has quit [Server closed connection]
pulpy_orange2[m] has joined #asahi-dev
retonlage[m] has quit [Server closed connection]
retonlage[m] has joined #asahi-dev
YichaoYu[m] has quit [Server closed connection]
YichaoYu[m] has joined #asahi-dev
mtjzh has joined #asahi-dev
CDFH has quit [Server closed connection]
mtjzh has quit [Remote host closed the connection]
<jannau> marcan: have you already thought about how to interact with arch linux? I'm wondering what I shall do about the broken rust package with 16k page size
<marcan> there's going to be a bunch of breakage due to 16K pages, yes; my plan is to not care for the first release so we can gather up everything that's broken :-)
mtjzh has joined #asahi-dev
<jannau> issue is that the x86 PKGBUILD uses jemalloc and jemalloc seems to assume that the build page size is the page size on the target
<marcan> yeah, jemalloc again...
<jannau> it has config option to specify a page size (as far as I understand it still works if the actual page size is smaller)
<marcan> yeah, makes sense
<j`ey> jannau: the iommu patch seems to be tested relatively well, why not just use that
<marcan> tbh we can probably just get ALARM to override that for us
<jannau> I could ceate a pull request for alarm's PKGBUILD repo but I was wondering if they already know that there will be an influx of users with a CPU with 16k page size
<marcan> I have talked with them, but I don't remember if I emphasized the 16K issue
<marcan> need to check my mail again :)
<marcan> I can follow up though
<alyssa> what happened to sven's 4k patches
mtjzh has quit [Ping timeout: 480 seconds]
<j`ey> to be revived at some point
<jannau> j`ey: I fear if we start that way it will be hard to convince people that packages should be fixed for 16k
<sven> they work fine but need some work to be accepted upstream and i've kinda abandoned them because nvme was more interesting
<kettenis> alyssa: you stopped kicking sven ;)
<sven> yeah, or that :D
<jannau> marcan: thanks
<j`ey> jannau: I suppose
<alyssa> jannau: fair enough tbh
<sven> in other news, the regs inside the phy-atc nodes in the ADT are a big mess. they have some entries that are e.g. 0xa4 byes long :/
<kettenis> so now sven ahs abandoned nvme because atc is more interesting ;)
<sven> :D
<j`ey> Ad infinitum
<sven> i'm just waiting for marcan to confirm that the rtkit library is in a good shape and for axboe (he's one of the nvme maintainers) to look into sharing tags across both queues to submit it
mtjzh has joined #asahi-dev
ChaosPrincess has quit [Quit: WeeChat 3.4]
ChaosPrincess has joined #asahi-dev
mtjzh has quit [Ping timeout: 480 seconds]
vup has joined #asahi-dev
mtjzh has joined #asahi-dev
mtjzh has quit [Ping timeout: 480 seconds]
mtjzh has joined #asahi-dev
mtjzh has quit [Ping timeout: 480 seconds]
mtjzh has joined #asahi-dev
mtjzh has quit [Ping timeout: 480 seconds]
mtjzh has joined #asahi-dev
mtjzh has quit [Ping timeout: 480 seconds]
mtjzh has joined #asahi-dev
mtjzh has quit [Ping timeout: 480 seconds]
bisko has joined #asahi-dev
mtjzh has joined #asahi-dev
axboe has joined #asahi-dev
<axboe> starting to look at adding a cpufreq driver
<axboe> all I got so far is the m1n1 cpufreq entry, does anything else exist describing the pstate values?
<j`ey> but I know that marcan wanted to rewrite it for some reason
<axboe> ah shoot, didn't find anything
<axboe> thanks, that's very useful
user982492 has joined #asahi-dev
<jannau> I think based on this branch https://github.com/AsahiLinux/linux/tree/cpufreq/v1
<axboe> looks like it, yes
mtjzh has quit [Ping timeout: 480 seconds]
axboe has quit [Quit: leaving]
bisko has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
mtjzh has joined #asahi-dev
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
user982492 has joined #asahi-dev
mtjzh has quit [Ping timeout: 480 seconds]
user982492 has quit []
user982492 has joined #asahi-dev
user982492 has quit []
user982492 has joined #asahi-dev
user982492 has quit []
axboe has joined #asahi-dev
<axboe> well that failed miserably, lol
eragon has joined #asahi-dev
<axboe> will take a look later today when I've got some more time to fiddle with this
mtjzh has joined #asahi-dev
<jannau> axboe: seems to work if you yank the mcc
<jannau> axboe: your disabled cpu core might cause troubles
mtjzh has quit [Remote host closed the connection]
mtjzh has joined #asahi-dev
<jannau> axboe: https://paste.debian.net/1230690/ fixes it for me
<axboe> jannau: was considering that it might be because p7..p8 aren't here
<axboe> jannau: will give that a shot!
axboe has quit [Quit: brb]
<jannau> maybe not system was not really stable
axboe has joined #asahi-dev
<axboe> jannau: yep booted with that, let's see...
mtjzh has quit [Remote host closed the connection]
<axboe> anyone noticed that irq/101-0-003a ends up in D state after charger has been plugged/unplugged?
<axboe> oot@m1:~# cat /proc/462/stack
<axboe> [<0>] pasemi_smb_waitready+0x40/0xe0
<axboe> [<0>] __i2c_transfer+0x164/0x7a0
<axboe> [<0>] msleep+0x2c/0x3c
<axboe> [<0>] pasemi_i2c_xfer+0x134/0x1c0
<axboe> [<0>] i2c_transfer+0x5c/0xf4
<axboe> [<0>] regmap_i2c_read+0x58/0xa0
<axboe> [<0>] _regmap_raw_read+0xdc/0x2cc
<axboe> [<0>] regmap_raw_read+0x190/0x27c
<axboe> [<0>] tps6598x_block_read+0x44/0xc0 [tps6598x]
<axboe> [<0>] cd321x_interrupt+0x40/0x250 [tps6598x]
<axboe> [<0>] irq_thread_fn+0x28/0x94
<axboe> [<0>] irq_thread+0x150/0x27c
<axboe> [<0>] kthread+0x108/0x110
<axboe> [<0>] ret_from_fork+0x10/0x20
<axboe> (scaling does seem to work fine now, fwiw)
mtjzh has joined #asahi-dev
<axboe> this should certainly help the battery time, was running fully clocked up before
axboe has quit [Quit: brb]
<sven> that interrupt comes from the usb pd controller
axboe has joined #asahi-dev
<jannau> my instalility with mcc was apparently caused by using "apple,num-channels = <8>;" for the m1 max
<jannau> powertop is not made for 10 cores with 16 pstates
<axboe> jannau: heh indeed
<jannau> still not stable, might be related to "nvme-apple 393cc0000.nvme: I/O 32(aq:0) timeout: completion polled"
user982492 has joined #asahi-dev
mtjzh has quit [Remote host closed the connection]
<jannau> seen 4 times with I/O 8(aq:0), I/O 24(aq:0) and I/O 32(aq:0)
<axboe> missed interrypt
<axboe> I haven't seen that here
<jannau> axboe: are you using the magsafe connector for charging? I can't reproduce it here
<axboe> jannau: nope, usb-c
<axboe> jannau: happens here every time, fwiw
mtjzh has joined #asahi-dev
<jannau> ack, reproduced with usb-c
<jannau> doesn't happen with the magsafe charger
<axboe> ah
<axboe> (usb-c is more convenient for me, as other laptops in the house can use it too...)
<axboe> haven't even tried the included charger yet :)
mtjzh has quit [Ping timeout: 480 seconds]
<sven> does it get stuck in that D state? it's waiting for an i2c transaction to finish there
<sven> or does the interrupt just keep firing?
<axboe> sven: it does
<axboe> I can try and debug it, only visible thing is that it sits in D all the time
<axboe> but it's doing 1 msec sleeps there and timing out after 10 tries, so retries must be coming from elsewhere
<sven> my first guess was that we don't ack the interrupt in cd321x_interrupt correctly but I don't see how yet
<sven> cd321x is that usb pd chip and there should be a "plug event" firing
<sven> but we handle that one correctly
<jannau> it appears to be a read and not a write. maybe the same problem as in m1n1 with not using Repeat-Start
<sven> i don't think the i2c transaction it the problem. it should timeout and complain if it was
<sven> huh, m1n1 has #define CD3218B12_IRQ_WIDTH 9 but the kernel driver effectively only considers 8 bytes
<jannau> yes
<sven> hrm, but that shouldn't matter since we hand over to linux with all irqs in that chip disabled
<jannau> I was thinking of that as well, I think the data sheet has only 8 bytes and apple's variant
<jannau> has one additional one
<jannau> don't we restore the state anymore?
<sven> i think only when running something in the hypervisor
<sven> looks like i can't easily convinced my mac mini to "charge" from a usb-c port :D
<sven> and just plugging in a normal cable doesn't seem to trigger that here
<jannau> we don't disable the tps irqs for the direct payload boot as we do not init usb at all
<sven> can anyone of you boot with tps6598 trace events enabled?
<sven> something like tp_printk trace_event=tps6598:* in the bootargs should work
bpye4 has joined #asahi-dev
bpye has quit [Ping timeout: 480 seconds]
bpye4 is now known as bpye
<axboe> sven: sure, I can try that
<jannau> sven: full of empty "cd321x_irq: event="
<axboe> sven: I enabled ftrace, so I can just do it from there
<axboe> looks like jannau beat me to it
<jannau> it is 'trace_event=tps6598x:*'
<axboe> ls
<axboe> cd321x_irq filter tps6598x_irq tps6598x_status
<axboe> enable tps6598x_data_status tps6598x_power_status
<axboe> which ones do you want?
<sven> alright. unhandled interrupt then
<sven> I was looking for the cd321x_irq
<axboe> so we're not really stuck, we just keep doing that read path and needing at least one loop
<axboe> hence I see it in msleep() all the time
<sven> I think so
<sven> and it doesn’t trigger the spurious irq detection because i2c is just too slow
mtjzh has joined #asahi-dev
<axboe> if event == 0, should we still clear ints?
amw has quit [Ping timeout: 480 seconds]
<sven> the public data sheet claims the irq will only trigger when event is not zero
<axboe> I'll give it a spin...
<sven> this irq is also shared across all tps chips. But I think we have them all declared in the device tree
<sven> yeah, it can’t hurt to try..
axboe has quit [Quit: rebooting]
axboe has joined #asahi-dev
<axboe> ok let's try
<axboe> same
<axboe> irq/101-0-003a-378 [005] ..... 68.054988: cd321x_irq: event=
<axboe> tons of these, like jannau saw too
<axboe> every 0.012s
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<axboe> does it need the status reg read too? I should find the documentation :)
axboe has quit []
amw has joined #asahi-dev
mtjzh has quit [Ping timeout: 480 seconds]
axboe has joined #asahi-dev
<sven> the interrupts are changed in the apple-variant but many other things are the same
<axboe> no difference
<sven> wait… why does only one interrupt thread do that?
<sven> there should be a few that all trigger in the same interrupt
<sven> *on
mtjzh has joined #asahi-dev
user982492 has joined #asahi-dev
mtjzh has quit [Ping timeout: 480 seconds]
<sven> okay, shot in the dark: do your USB ports work more than once? is the dwc3 controller running dual mode?
<axboe> sven: haven't used usb yet...
<axboe> how do I check the dwc3?
<jannau> the problem seems to be that interrupts for the other ports are disabled
<axboe> dmesg | grep -i dwc 0.003s
<axboe> [ 1.828663] dwc3 702280000.usb: Adding to iommu group 2
<axboe> [ 1.828728] dwc3 702280000.usb: Configuration mismatch. dr_mode forced to host
<axboe> [ 1.875628] dwc3 b02280000.usb: Adding to iommu group 3
<axboe> [ 1.875752] dwc3 b02280000.usb: Configuration mismatch. dr_mode forced to host
<axboe> [ 1.913059] dwc3 f02280000.usb: Adding to iommu group 4
<axboe> [ 1.913114] dwc3 f02280000.usb: Configuration mismatch. dr_mode forced to host
<sven> okay, I wonder if the cd321x chips probe correctly if the dwc3 is in host mode only
<jannau> if I comment the type-c connectors in the dts all four cd321x have interrupts enabled
<sven> that explains the “empty” irq status
<sven> the other tps gets that “plug event” and pulls the irq line low but the kernel only checks the MagSafe tps one and doesn’t see any interrupts there
<sven> I wonder why they are disabled though
mtjzh has joined #asahi-dev
<sven> the probe function writes the irq mask pretty early and has lots of failure paths that don’t clean it up afterwards
<axboe> sven: that's it
mtjzh has quit [Ping timeout: 480 seconds]
<axboe> sven: ^^ fixes it
<jannau> fwnode_usb_role_switch_get() fails
<axboe> alternatively, enable mask could be moved
<axboe> but proves your theory at least
<sven> nice :)
<sven> jannau: probably because the dwc3 controller was forced to host mode which will also break usb hot plug with the current workaround
<sven> jannau: actually, usb/role.h has a stub for that function when !IS_ENABLED(CONFIG_USB_ROLE_SWITCH)
<sven> hrm, but that would always fail then
<jannau> fails with -EPROBE_DEFER
kenzie35 has quit []
<sven> that's fine the first time if it probed dwc3 before the cd321x
<sven> either way, axboe's interrupt mask fix is a good idea anyway
kenzie35 has joined #asahi-dev
<jannau> yes, not a problem in mainline due to the missing usb nodes
<jannau> it returns -EPROBE_DEFER 7 times after dwc3 is probed, once before
mtjzh has joined #asahi-dev
mtjzh has quit [Ping timeout: 480 seconds]
mtjzh has joined #asahi-dev
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]