<marcan>
maz: ahaha. so I tried setting PORT_LOGIC_SPEED_CHANGE in m1n1 and that didn't work.
<marcan>
then I added some printfs around it and it worked.
<marcan>
... looks like it wants a ~1ms delay before it. sigh. what's this about...
<marcan>
ok, yeah, the write doesn't stick; looks like we need a delay after starting up the port before touching the config regs (which might mean we weren't even applying the tunables properly either...)
<marcan>
yeah, we were missing polling one bit, sigh
chadmed has quit [Remote host closed the connection]
VinDuv has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
VinDuv has joined #asahi-dev
King_InuYasha has quit [Ping timeout: 480 seconds]
<maz>
marcan: does this require any change in the u-boot/Linux/OpenBSD drivers, or can you keep that in m1n1?
ar has quit [Ping timeout: 480 seconds]
ar has joined #asahi-dev
<marcan>
maz: this is all in m1n1, already pushed. And since this makes PORT_LOGIC_SPEED_CHANGE unnecessary, if we decide to not care about max speed caps or to put that code in m1n1 too, we can drop the patch I sent entirely
<landscape15[m]>
Has anyone managed to run OpenBSD quite well?
<j_ey>
yes kettenis
<landscape15[m]>
j_ey: thanks! It’s good to know that you don’t need to rewrite all the kernel.
<j_ey>
landscape15[m]: just like linux didnt need a rewrite!
<marcan>
sven et al: I think I'm going to rename that t6k bringup branch (which isn't really any more) to something more generic
* sven
doesn't use that branch anyway
<marcan>
since that's basically my "stuff sane enough to be on the way upstream to varying degrees" branch
<marcan>
well, I want people to use it :-)
<sven>
i think jannau has a sane collection of patches like that somewhere as well
<kettenis>
the current u-boot device trees are based on that branch
<landscape15[m]>
j_ey: So I suppose m1n1 does the hard job. I’m going to test it on my new 13” when I’ll get it.
<kettenis>
with some extras thrown in for bits where I have (somewhat) sande openbsd drivers ;)
<marcan>
:)
<kettenis>
s/sande/sane/
<jn>
marcan: is it suitably enough for linux-next to be renamed for-next?
<jn>
(because that's a familiar name)
<marcan>
it's not quite for-next, it's not submission-quality stuff only
<marcan>
it's more like devel
<jn>
i see
<marcan>
I rebase it frequently as things get merged
<marcan>
for-next doesn't really make sense for us because we don't have a subsystem tree; instead I have things under asahi-soc/ that I send arnd_, but that's mostly DT/misc fixes, not drivers
<marcan>
I wonder if there's some kind of name between "for-next" and "devel" that's appropriate...
<kettenis>
"integration"
<sven>
we'll have a (boring) subsystem tree for rtkit and sart eventually i guess
<marcan>
not sure what the upstreaming path for those is actually
<sven>
sart probably together with nvme because it's really only used there
<sven>
dunno about the rtkit stuff
<sven>
it unfortunately doesn't really fit into the remoteproc system
<marcan>
kettenis: I like the meaning but dang that's long :-)
<marcan>
eh, what if I just call it 'asahi'
<kettenis>
works for me ;)
<marcan>
it's probably going to evolve into the kernel branch we ship to people sooner or later anyway (in bleeding edge packages)
<landscape15[m]>
marcan: what is “asahi” branch for?
<marcan>
things I actually want people to test :p
<marcan>
i.e. code that is either on the way upstream or being developed with that goal, that is good enough for people to test and use
<marcan>
basically an integration of everything people are working on
<sven>
hm, guess I should also add power-domains to that binding
<marcan>
please do :)
<marcan>
_jannau_: I think I got everything into asahi, want to take a look
<marcan>
?
<jannau>
marcan: looks good. thanks
<jannau>
is it to early to make asahi the default branch for AsahiLinux/linux?
<marcan>
jannau: I just did :)
<marcan>
had the same idea :p
yuyichao has quit [Ping timeout: 480 seconds]
yuyichao has joined #asahi-dev
Gaspare has joined #asahi-dev
robher_ has quit []
robher has joined #asahi-dev
<marcan>
arnd_: I'm a bit confused about what path the PMGR driver should take upstream. It's under drivers/soc, which doesn't have anyone in charge of it at the top level AIUI. Linus Walleij acked it.
<arnd_>
marcan: send it to soc@kernel.org, but separately from the DT changes
<marcan>
ack, do you want all the related DT changes (bindings changes to add power-domains props, instantiating PMGR & adding domains) together in a DT pull along with other DT changes, and just the driver separately?
<marcan>
(I'm guessing the bindings for PMGR itself would go with the driver)
the_lanetly_052 has joined #asahi-dev
<marcan>
(in that case, there's a dependency, so I guess I should stack the branches in the right order as usual?)
aleasto has joined #asahi-dev
<marcan>
also nobody reviewed the actual DT change yet (in particular v3 adds *all* the domains...)
<sven>
i'll grab it from the list and take a look this evening
<marcan>
cool, thanks!
<marcan>
arnd_: ^^
<arnd_>
marcan: yes, all the DT changes should come together, separately from the driver changes
<arnd_>
the idea is that each half should be regression-free and tested without the other half, to ensure that there are no incompatible binding changes
<arnd_>
obviously any added features may only become available once both branches are merged
<kettenis>
marcan, sven: dr_mode changed from "host" to "otg" on the asahi branch and that makes u-boot unhappy
the_lanetly_052 has quit [Ping timeout: 480 seconds]
<marcan>
arnd_: I'm mostly wondering about the DT checker; if that is to pass then all the bindings changes should come along with the DT changes, and the driver would be completely separated from its related binding changes. is that what you expect?
<marcan>
kettenis: *points at _jannau_*
<sven>
the default dr_mode should be otg anyway
<sven>
we can just drop that from the DT but that also sounds like a bug in u-boot
<arnd_>
marcan: that is usually the easiest way, the alternatives are to have the dt binding patch first, using the same commit for both branches, or to do it over more than one merge window
<arnd_>
some subsystem maintainers prefer the binding changes to go in with the driver, obviously I don't care if I merge both branches anyway
<marcan>
cool, I'll split it out like that and send it tomorrow then :)
<marcan>
thanks!
<kettenis>
sven: having those ports default to otg instead of host doesn't make sense to me on these machines
<sven>
i'll have to check those node again anyway, but iirc there was another property for the default mode
<kettenis>
role-switch-default-mode = "host";
<kettenis>
but u-boot defenitely doesn't look at that
<sven>
as i said, i think the default mode for dr_mode is otg anyway so we can just drop that from the DT if that helps
<sven>
i think i just put something in those node that made it work for now. i'll have to re-check them once the drd3 maintainer comments on that dumb reset quirk anyway
Gaspare has quit [Quit: Gaspare]
<kettenis>
that seems to work
<kettenis>
those dwc3 nodes have not yet been sumitted upstream isn't it?
<sven>
nope
<sven>
we kinda need to know how this dumb reset quirks looks like in the end. though i guess i could submit the binding + DT changes separately from that
<kettenis>
I think so; the ports are usable as-is
<kettenis>
anyway, it would be great you and/or jannau could remove that dr_mode property such that we don't run into this issue again later
<kettenis>
I suppose I'd need to implement support for the hpm chip in u-boot to get role switching to work properly?
<sven>
only if you want to react to role switch notifications from that chip
<sven>
in linux you can also write to some sysfs node to trigger a role switch and that works even without support for that hpm chip
<sven>
(as long as m1n1 initialized it with that SSPS command)
<kettenis>
ah, so adding support for the role-switch-default-mode property is what I need then
aleasto has quit [Quit: Konversation terminated!]
aleasto has joined #asahi-dev
as400 has left #asahi-dev [#asahi-dev]
___nick___ has joined #asahi-dev
___nick___ has quit []
___nick___ has joined #asahi-dev
<povik>
this won't work with interrupt-parent=<&pinctrl>, or will it?