thelounge7571340 has quit [Remote host closed the connection]
Dcow has quit [Ping timeout: 480 seconds]
Dcow has joined #asahi-dev
Dcow has quit [Ping timeout: 480 seconds]
kettenis has joined #asahi-dev
<marcan>
rmk: no, I was hoping to get this sorted out before trying to figure out how to do a T2 one (or for someone else to work on that from t2linux)
<marcan>
but I think we're well past the point where it's worth arguing with lee just for the sake of replacing a for loop calling platform_device_register
<marcan>
and I have no confidence left that we will find a solution that he finds acceptable that doesn't annoy *me* as the author and maintainer of this particular driver
<marcan>
he clearly has his own ideas about what being an mfd means, and they do not fit this particular combination of hardware platforms
<marcan>
and I'm not going to make a mess of the code (putting the core into header files, what? that's supposed to be for inlining for performance, not because someone doesn't like the code in their tree)
<marcan>
just to appease him
Dcow has joined #asahi-dev
<marcan>
in the end if we end up with everything split up weirdly, that will just mean more reviews and more acks to coordinate and honestly I don't really want to deal with him any more
<marcan>
so let's just drop the mfd dependency and stay in platform
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
chadmed has quit [Quit: Konversation terminated!]
Dcow has quit [Ping timeout: 480 seconds]
chadmed has joined #asahi-dev
Dcow has joined #asahi-dev
Dcow has quit [Ping timeout: 480 seconds]
Dcow has joined #asahi-dev
Dcow has quit [Ping timeout: 480 seconds]
Dcow has joined #asahi-dev
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
Dcow has quit [Ping timeout: 480 seconds]
ccs1 has joined #asahi-dev
Dcow has joined #asahi-dev
ccs1_ has joined #asahi-dev
Dcow has quit [Ping timeout: 480 seconds]
ccs1 has quit [Ping timeout: 480 seconds]
ccs1_ is now known as ccs1
nicolas17 has quit [Quit: Konversation terminated!]
Dcow has joined #asahi-dev
Dcow has quit [Ping timeout: 480 seconds]
Dcow has joined #asahi-dev
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
Dcow has quit [Ping timeout: 480 seconds]
Dcow has joined #asahi-dev
Dcow has quit [Ping timeout: 480 seconds]
SSJ_GZ has joined #asahi-dev
Dcow has joined #asahi-dev
ccs1 has quit [Ping timeout: 480 seconds]
Dcow has quit [Ping timeout: 480 seconds]
snowcra5h has joined #asahi-dev
<snowcra5h>
:o
Amulet has joined #asahi-dev
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
SSJ_GZ has quit [Ping timeout: 480 seconds]
Dcow has joined #asahi-dev
ajv009 has joined #asahi-dev
Dcow has quit [Ping timeout: 480 seconds]
Dcow has joined #asahi-dev
Dcow has quit [Ping timeout: 480 seconds]
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
Dcow has joined #asahi-dev
Dcow has quit [Ping timeout: 480 seconds]
Dcow has joined #asahi-dev
ccs1 has joined #asahi-dev
Dcow has quit [Ping timeout: 480 seconds]
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
kettenis has quit [Remote host closed the connection]
kettenis has joined #asahi-dev
mps has quit [Ping timeout: 480 seconds]
ccs1 has quit [Ping timeout: 480 seconds]
Dcow has joined #asahi-dev
Dcow has quit [Ping timeout: 480 seconds]
SSJ_GZ has joined #asahi-dev
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
Dcow has joined #asahi-dev
Dcow has quit [Ping timeout: 480 seconds]
Dcow has joined #asahi-dev
kujeger has joined #asahi-dev
mps has joined #asahi-dev
Dcow has quit [Ping timeout: 480 seconds]
Dcow has joined #asahi-dev
bluetail3 has joined #asahi-dev
bluetail3 has quit []
bluetail has quit [Ping timeout: 480 seconds]
bluetail3 has joined #asahi-dev
bluetail3 is now known as bluetail
bluetail has quit []
bluetail3 has joined #asahi-dev
bluetail3 is now known as bluetail
Dcow has quit [Ping timeout: 480 seconds]
Dcow has joined #asahi-dev
thelounge7571340 has joined #asahi-dev
psykose has quit [Ping timeout: 480 seconds]
psykose has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
Dcow has quit [Ping timeout: 480 seconds]
Dcow has joined #asahi-dev
Dcow has quit [Ping timeout: 480 seconds]
Dcow has joined #asahi-dev
bisko has joined #asahi-dev
bisko has quit [Ping timeout: 480 seconds]
bisko has joined #asahi-dev
MajorBiscuit has joined #asahi-dev
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
yuyichao_ has joined #asahi-dev
yuyichao has quit [Ping timeout: 480 seconds]
<sven>
okay, oob hpd forwarding to drm works when I represent the connection using the of graph bindings
<sven>
hotplug works exactly once, probably because I don’t know how to shut the previous connection down yet :D
ajv009 has quit [Ping timeout: 480 seconds]
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
bisko has quit [Remote host closed the connection]
bisko has joined #asahi-dev
r0ni has joined #asahi-dev
espo has quit [Remote host closed the connection]
bisko has quit [Remote host closed the connection]
bisko has joined #asahi-dev
<chadmed>
looks like Viresh doesn't want opp_parse_supplies() to return anything valid without a microvolt property since that breaks some consumers of the regulator struct
<chadmed>
so next angle of attack is taking opp-microwatt out of the regulator nonsense entirely
<chadmed>
why it was added to all of that is a mystery to me since it was added specifically for platforms that do not express their regulators in the DT...
<chadmed>
s/DT/opp table/
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Read error: Connection reset by peer]
<marcan>
yeah... heh
<marcan>
chadmed: bad engineering in kernel land is not uncommon :p
<marcan>
good thing is we can fix it
<marcan>
chadmed: "I have included your patch in my series now, cc'd you." did he change his mind?
<sven>
the only truly bad thing i've seen is mailbox *sigh*
<sven>
everything else i've seen usually is just "design decisions taken years/decades ago that aren't valid anymore and haven't been cleaned up yet"
<marcan>
sven: there's quite a bit of "this one thing was done in a dumb way recently without thinking about it, and needs to be redone"
<marcan>
that happens all over the place
<marcan>
especially once things get more than 1 consumer
<marcan>
but yeah, mailbox is... special :(
<sven>
yeah, writing something for x and then realizing it doesn't work for y happens all the time
<sven>
but well... mailbox *sigh*
<chadmed>
marcan: no, that patch series does not change the behaviour of that code path at all. it just shuffles stuff around
<marcan>
oh, fair
<chadmed>
yeah he needs to delete the stuff in the commit message about it fixing AS, see my reply to 5/5
<marcan>
so wait, the patch description says it does allow opp-microwatt alone?
<marcan>
ahh
<marcan>
ok
<marcan>
5/5?
<chadmed>
i replied to the 5th message in that patch series
<chadmed>
ah my bad i thought you were talking about viresh's new patch series
<marcan>
ah, that didn't go out to asahi@ or me
<marcan>
chadmed: let's see what he replies, might just be confusion
<marcan>
it doesn't make sense he'd name the series like that and then not do it
<marcan>
in other news, I just had an IRC chat with Lee, looks like we resolved the MFD issue (cc rmk)
<marcan>
smc_core is going into mfd/ (named macsmc at that point)
<marcan>
rmk: do you want to work this out or should I take over and let you rest a bit from this one? :)
<marcan>
if you have a most recent tree with review comments, I can take care of merging it with whatever and resubmitting
<marcan>
(I think you've done enough to help with this one, but I won't stop you if you want to see it through the end ;))
<rmk>
marcan: let me send you the patches - which will probably be a little later today.
<rmk>
I think we're almost there with gpio-macsmc + dt binding (I need to drop the t8103 specific compatible there)
<rmk>
I haven't sent another version of that because I was hoping to get a way forward for the macsmc bits
<marcan>
got it
<marcan>
no rush, I should spend what's left of today drafting a progress report (finally)
<rmk>
I'm happy to try switching it to a platform device though.
<rmk>
and yes, I do think that pushing that stuff into a header file really isn't a good idea (I think I said as much in my email with the patch)
<rmk>
personally, I think your code structure is correct and clean, and I don't entirely understand where Lee is coming from, so I think that switching it to a platform device is the best way forward at this point.
ashi has joined #asahi-dev
<rmk>
I would encourage the Intel backend to be written though - which I think would've helped the case to show why the code is structured this way.
ccs1 has joined #asahi-dev
<rmk>
please bear in mind that we've had code in the past that people have been pushy to get merged, but the result has been rather incomplete because the bits that make use of that code never end up being merged.
<rmk>
(I've got quite a few patches like that which introduce various helpers for phylink - network stuff - but I'm refraining from pushing them without the corresponding users, which can be a pain when the helper gets used in a diverse range of places in networking code
<marcan>
rmk: I think you missed that I just talked with Lee, we're going with mfd
<marcan>
we had an IRC chat
<rmk>
oh, great.
<marcan>
he agreed to my proposal of moving smc_core into mfd/ and keeping smc_rtkit in platform/
<marcan>
so no real changes vs. what we have now other than renaming/moving some bits
<rmk>
ok, I thought he was against that, but if he's not then that's a simple solution
<marcan>
he picked it as the "least bad" solution :)
<rmk>
good thing I kept these tweaks as patches on top :)
<marcan>
:)
<marcan>
anyway, glad we could get it resolved in the end
<rmk>
ok, let me do that move and resubmit... I think we'll have to move the smc.h into linux/mfd/macsmc.h
<marcan>
he also mentioned the smc cells stuff should be one line per cell
<marcan>
and yes, he also agreed with that
<marcan>
the mfd driver should be called macsmc (no core at that point)
<sven>
hah, so inserting/removing the HDMI side of the type-c->hdmi adapter works. for some reason inserting/removing the type-c side breaks something though and dcpext ends up complaining about "device busy timeout"
<marcan>
smc_rtkit I think can stay named like that in platform/apple, though macsmc_rtkit would work too if you think it's better
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
<rmk>
if we're going to call the mfd part macsmc, I think renaming to macsmc_rtkit is probably sensible to make it clear that it's apple mac stuff
<marcan>
yeah, I think its location in the tree implies that but the module wouldn't, so that's fair
<marcan>
macsmc_ all the way
<marcan>
(I was hoping for someone to have some opinion on this; the original naming was inconsistent and I wasn't sure what to do about it, so thank you :p)
<marcan>
for the legacy backend I *could* pull out a positively ancient and slow as molasses Mac Mini I have lying around, or borrow a friend's old MBP. but it's entirely possible none of the current subdevice drivers will actually be useful on those platforms as-is (the big one that should work for all 3 is hwmon, not written yet, and maybe some hid/input stuff could be shared too?)
bisko has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<marcan>
the T2 Macs with the ACPI backend are the bridge between both worlds, I think they can use more of the M1 subdevice work
<marcan>
but the only T2 I have semi-access to is a friend's main machine, so I can only borrow it for this stuff sporadically (and in particular right now probably not until next year)
bisko has joined #asahi-dev
<sven>
lol, if i just remove the dcp disconnect handling dcp gets very confused when I remove/insert the type-c plug and just connect again, tries to set the link rate 2-3 times but finally works again :D
<_jannau_>
sven: quite possible that we have forward hpd explicitly to dcpext. is there anything interesting in a macos trace for an unplug?
<sven>
I already do that
<sven>
it's one of those dptx epic calls which essentially trigger HPD
<sven>
my "hpd no longer asserted" code just doesn't work correctly
<sven>
and dcpext gets a bit confused if I just skip that
<sven>
this still works surprisingly well though with all of the displays and adapters i have
<sven>
(except the thunderbolt dock ofc :-()
<marcan>
jannau: in particular fan control is what I meant for the older machines, I don't see that there (and also all those keys need to be in the DT for DT platforms, or we need to just autodiscover somehow and shrug for non-DT platforms)
<chadmed>
marcan: is the cpufreq driver supposed to try and init multiple times per cpu?
<chadmed>
there was actually one issue with viresh's patch, but now with that fixed cpufreq tries to add multiple opp tables per cpu which causes the new parsing stuff to error out since an opp table already exists
<ChaosPrincess>
Is the smc interface same on t2 and pre-t2 macs?
<chadmed>
actually disregard idk whats causing this
<marcan>
ChaosPrincess: no
bisko has joined #asahi-dev
lkron has joined #asahi-dev
Dcow has quit [Remote host closed the connection]
Dcow has joined #asahi-dev
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
Dcow has quit [Remote host closed the connection]
Dcow has joined #asahi-dev
cylm has joined #asahi-dev
bisko has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
cylm_ has joined #asahi-dev
cylm has quit [Ping timeout: 480 seconds]
ajv009 has joined #asahi-dev
ccs1 has quit [Ping timeout: 480 seconds]
bisko has joined #asahi-dev
MajorBiscuit has quit [Ping timeout: 480 seconds]
thelounge7571340 has joined #asahi-dev
bluetail2 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
bisko has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
bisko has joined #asahi-dev
bluetail has quit [Ping timeout: 480 seconds]
bluetail2 is now known as bluetail
ccs1 has joined #asahi-dev
<zzywysm>
chadmed: i wonder if the issue in the viresh patches was that the tester didn't update their dtbs properly after applying it?
amarioguy2 has joined #asahi-dev
<j`ey>
zzywysm: chadmed is james c
<zzywysm>
ah
<zzywysm>
did you update the dtbs in m1n1 before testing, james? :D
nicolas17 has joined #asahi-dev
<rmk>
marcan: I'm wondering what to do about the other MFD cells, the ones we currently don't have a compatible against yet... we'll need to fix those up eventually, so should we drop those and add them when merging the driver(s)... ?
<rmk>
if I make up compatibles for them now, I can see complaints about missing binding documentation being the next hold-up.
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]
bisko has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<sven>
urgh.. looks like there's still a delay missing *somewhere* :(
bisko has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
amarioguy2 has quit [Ping timeout: 480 seconds]
<jannau>
still the tuneables? have you looked into using gpiola to trace macos' timing?
lamlam has joined #asahi-dev
<sven>
no idea, it’s just that removing/inserting the type c side breaks everything right now
<sven>
but if I sleep after each reg write in atcphy it works again
ajv009 has quit [Ping timeout: 480 seconds]
<lamlam>
i finally booted the ane
<lamlam>
i know the following explanation is subpar but i'm just excited to share bear with me (3am here haha) https://bashify.io/images/C4Cn1D
<lamlam>
starting from the first block (b1XXXXX): anecpu bootstraps by writing 10001bfc into L2C_ERR_STS, then L2C_ERR_ADR (26b10008, same mmio range), and then some other HID impls. the 4 regs starting with ce across 16 & 17 are 24hz clocks. the 2nd block (b4XXXXX) is the actual asc base i believe. controller is @ +44 & idle/wfi status @ +48, which is a similar layout to https://github.com/AsahiLinux/docs/wiki/HW:ASC, but none of the vals are.
<lamlam>
init call is a single write32 of 0x10 to the controller after all the dart/vmem mapping/power data stuff. this wfi status is where i was stuck at.
<lamlam>
gpio regs are 4c-64 in the 3rd block (b84XXXX). init/deinit communication uses these. init protocol is done by zeroing out these regs (+ some tunables), to which the anecpu should write back a "magic" number of 0x8042006 in the last gpio.
<lamlam>
magic number means the fw successfully allocated ipc channels: 1st reg (7) is the # of chans, and 2nd (f340) is the size, 4th is heap size etc. now i can make it work for me :P
<lamlam>
turns out all i needed were some sneaky tunables.
<lamlam>
i'll clean this up & document it, hopefully it can make it to the asahi repos.
<lamlam>
i have been consistently hitting the magic number since, but currently i'm relying on ~400 unknown numbers to fill the dpe regs (dynamic power estimation, the last reg actually). i can account for other parts though.
lethalnyan has joined #asahi-dev
lethalbit has quit [Read error: Connection reset by peer]
thelounge7571340 has joined #asahi-dev
thelounge7571340 has quit [Remote host closed the connection]