<blazra[m]>
j`ey: I have played a bit with the PWM control register bits (for the keyboard backlight) and I think that bit2 is stopping the counter and then you can start just one PWM period using bit9 (like a single-shot mode).
<blazra[m]>
Maybe we can add these to the list of bits we "know" what they do :D
<blazra[m]>
Although I am not sure if any of this is actually useful for a driver which controls keyboard backlight.
e1eph4nt has joined #asahi-dev
e1eph4nt has quit [Ping timeout: 480 seconds]
off^ has joined #asahi-dev
e1eph4nt has joined #asahi-dev
e1eph4nt has quit [Ping timeout: 480 seconds]
e1eph4nt has joined #asahi-dev
e1eph4nt has quit [Ping timeout: 480 seconds]
e1eph4nt has joined #asahi-dev
e1eph4nt has quit [Ping timeout: 480 seconds]
skipwich has quit [Quit: DISCONNECT]
skipwich has joined #asahi-dev
e1eph4nt has joined #asahi-dev
e1eph4nt has quit [Ping timeout: 480 seconds]
<marcan>
blazra[m]: excellent! it's not useful for a keyboard, but documenting bits is important since it means our understanding of the hardware is more complete and we avoid magic numbers :)
e1eph4nt has joined #asahi-dev
atipls has joined #asahi-dev
chadmed_ has joined #asahi-dev
atipls has quit [Remote host closed the connection]
atipls has joined #asahi-dev
eshmaki has joined #asahi-dev
CatDentures has joined #asahi-dev
atipls has quit [Quit: My laptop probably went to sleep.]
e1eph4nt has quit [Ping timeout: 480 seconds]
e1eph4nt has joined #asahi-dev
e1eph4nt has quit [Ping timeout: 480 seconds]
e1eph4nt has joined #asahi-dev
e1eph4nt has quit [Ping timeout: 480 seconds]
e1eph4nt has joined #asahi-dev
e1eph4nt has quit [Ping timeout: 480 seconds]
Glanzmann has quit [Quit: leaving]
e1eph4nt has joined #asahi-dev
the_lanetly_052__ has joined #asahi-dev
chadmed_ has quit [Quit: Konversation terminated!]
duban has quit [Quit: I'm out]
duban has joined #asahi-dev
<j`ey>
blazra[m]: nice!
<j`ey>
blazra[m]: if you find out anything else let me know!
<povik>
could BIT(10) we a blanket invert?
<povik>
s/we/be
<dottedmag>
blazra[m]: I wouldn't be surprised if this is just a copy-paste from, say, iphone buzzer
e1eph4nt has quit [Ping timeout: 480 seconds]
<blazra[m]>
povik: I don't know what that means exactly. However, bit(10) works only in single-shot mode - it didn't do anything in continuous. But maybe it needs reload using bit(5)? I don't know. I can try again after work.
<povik>
i mean, does that simply invert the pwm output
<povik>
but it seems like it doesn't from what you write
<povik>
mimochodem, zdravím!
<blazra[m]>
taky zdravím :D
<rmk>
marcan: I've just spotted some other issues in the gpio irq code - there's a few places where X > MAX_GPIO is tested to determine whether X is a valid gpio number - I believe they should be >= MAX_GPIO, since the range is 0..63 with 64 being excluded.
<marcan>
rmk: good catch
<rmk>
oh and good morning :)
<marcan>
good morning :)
<marcan>
queuing up some local system maintenance to run while I go into kernel merge mode
AnushervonTabarov[m] has quit [Quit: Client limit exceeded: 20000]
* rmk
keeps typing "macsec" rather than "macsmc"... clearly I've spent too much time in networking stuff recently :/
e1eph4nt has joined #asahi-dev
<marcan>
oof
<marcan>
incidentally, I'm not a super fan of the name, but "applesmc" was taken and I couldn't come up with anything better
<marcan>
even though it's kind of backwards, since "applesmc" only works on Macs while macsmc could hypothetically work on iOS devices
<rmk>
I don't think we should care about it too much at this point
<rmk>
I mean, it's more important to try to get this upstream so that mainline gains functionality on these platforms
the_lanetly_052__ has quit [Ping timeout: 480 seconds]
<marcan>
of course, just commenting :)
<marcan>
macsmc works
e1eph4nt has quit [Ping timeout: 480 seconds]
<j`ey>
what tree/subsystem does this go through? arnd's?
e1eph4nt has joined #asahi-dev
<rmk>
I think it'll go through LinusW's gpio tree
leitao has joined #asahi-dev
<rmk>
kettenis: how big a problem would it be if we merged the SMC sub-nodes so they were all under the main "smc" node? Could OpenBSD check for the presence of e.g. the "gpio" node and if it's not present, just use the "smc" node?
<kettenis>
we could, but it requires a 6 month transition period
<kettenis>
also, I think it is a bad idea
<kettenis>
the current binding nicely splits hardware description (main node) from the firmware-provided functionality (sub-nodes)
<kettenis>
the problem is that the smc gpio is needed for wifi
<marcan>
yeah, I don't like the idea of merging everything into one node
<marcan>
while it's true that it's all "the same hardware", it is an mfd after all, and it makes sense to split off individual pieces of functionality into individual nodes in my opinion
<marcan>
think of it as "firmware services"
<marcan>
worth noting that macos *doesn't* do this and their device tree is a mess ;)
<kettenis>
if there are good technical reasons for doing this I have no issues with changing openbsd and coming up with some sort of transition mechanism for asahi/openbsd
<marcan>
but they have that arbitrary function call mechanism that lets them hack around stuff instead of thinking about how to provide proper bindings
<marcan>
also, there is one extra detail: node absence can be used to gate probing, for things where that makes sense
<marcan>
so I would very much prefer subnodes + compatibles over just merging everything
<marcan>
also, there *is* a hardware angle
<marcan>
gpio right now is master PMU GPIO
<kettenis>
robh's motivation seemed to be that the subnodes nly contained one or two properties
<marcan>
the slave PMU also has GPIO and SMC exposes a couple pins there. we don't implement that since I don't think we'll ever need it on current machines, but if we ever do, that should be a separate gpio node
<kettenis>
but gpio may get the interrupt-related properties
<marcan>
and then we have two gpio nodes
<rmk>
I don't see number of properties should have a bearing on how something is described
<marcan>
yeah, I even have some empty nodes IIRC in the MTP binding since they describe HID interfaces
<kettenis>
marcan: right I saw some hints for a "second" gpio controller in the list of enumerated keys
<marcan>
yup, that's the second PMU
CatDentures has quit [Quit: Konversation terminated!]
<marcan>
different key prefix, so different driver instance makes sense IMO
<marcan>
instead of trying to add a dimension or something
<marcan>
not going to bother until we need it, but we have to consider the possibility
<marcan>
#1201: gP18 = (ui32, 0xf0) 862549252
<marcan>
#1202: gP19 = (ui32, 0xf0) 862549252
<marcan>
#1203: gP1a = (ui32, 0xf0) 862549252
<marcan>
#1205: gp0b = (ui32, 0xf0) 862549252
<marcan>
#1204: gp08 = (ui32, 0xf0) 862549252
<marcan>
#1206: gp0e = (ui32, 0xf0) 862549252
<marcan>
gP?? is MPMU, gp?? is SPMU
<marcan>
(apple terminology fwiw)
CatDentures has joined #asahi-dev
<marcan>
rmk: re compatibles, one thing to consider is how this will probe on non-OF platforms
<marcan>
right now the idea is that the services shared with x86 machines (e.g. hwmon) wouldn't have a hard requirement on a DT node, and we just check at probe time whether they exist in the SMC
<marcan>
as long as we can hard-code a list of compatibles (or some similar logic) to trigger probing on non-OF platforms that works for me
<sven>
pretty sure I’ve seen stuff like that in various places
<sven>
not exactly the same but the last thing I saw was in the typec subsystem: something created graph connections between fake fwnodes to make the core happy
<rmk>
marcan: one point Rob missed is that the reason it works today is that module autoloading and binding has mechanisms outside of firmware to do it - with platform drivers, that's driver name to device name matching and modaliases that can match
<marcan>
yup, that all works with mfd already without compatibles
<marcan>
that was how I designed it :)
<marcan>
(and that approach works on x86 too)
<marcan>
I made a point to build everything practical as modules on our arch images (though macsmc-gpio and deps aren't because that's a hard dep of the framebuffer via backlight-gpios, but all the other smc sub-drivers are)
<marcan>
(that fb dep will go away once DCP is in and we stop supporting/depending on dumb GPIO backlight support
<marcan>
)
leitao has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
c10l has quit [Quit: Bye o/]
c10l has joined #asahi-dev
jluthra has quit [Remote host closed the connection]
jluthra has joined #asahi-dev
leitao has joined #asahi-dev
<marcan>
aside: confirmed that btcoex is reproducibly terrible with my Sony earbuds, and the code I wrote yesterday doesn't fix it (maybe helps a bit?)
<marcan>
so, more research needed :p
e1eph4nt has quit [Ping timeout: 480 seconds]
<sven>
maybe it actually needs something on the bt side as well then?
<sven>
i should update that BT tracer with that new pcie tracer you wrote
<ar>
marcan: on different (non apple) hardware, my worst btcoex experience was with sony headphones on ldac codec (chosen only because of bandwidth usage/bitrate in this case) while wifi was in ap mode on 2.4GHz radio
<marcan>
sven: yeah, I was wondering. but I also need to make sure I didn't screw the wifi side up nor miss anything :)
<marcan>
ar: ha, good point. it's LDAC that does it, why my speakers were okay
<marcan>
it's about as bad as the speakers on SBC, maybe a bit worse
<marcan>
on LDAC it just dies, completely, when the wifi is on 2.4
<marcan>
I wonder if Apple does anything special in LDAC mode (do they even support it?)
<ar>
afaik ios/macos don't support ldac
<marcan>
hmm
<marcan>
SBC is still worse than the speakers so that would still be a usable test
CatDentures has quit [Quit: Konversation terminated!]
CatDentures has joined #asahi-dev
e1eph4nt has joined #asahi-dev
skrzyp has quit [Remote host closed the connection]
<povik>
ah, great, it can take an archive directly off github
<povik>
not sure how github feels being a CDN for everything
<mps>
iirc there is separate ucm PKGBUILD for gru-kevin chromebook on alarm
<mps>
maybe it could be used as template for asahi UCM
<povik>
the UCM itself i have written for mini already, now i should extrapolate
<jannau>
an asahi specific ucm pkg would be easier to handle. no race for the highest package version when the alarm pkg is updated
<povik>
i think it's the only sane option until the kernel driver is upstream
<povik>
then the ucm should head upstream too
<mps>
+1
<povik>
jannau: or had you in mind some patch/overlay as an alternative?
<jannau>
and the package manager should handle file collision gracefully once the configs are moved to upstream
<jannau>
povik: I had an overlay in mind which would only contain the asahi specific files
<povik>
ah, you mean not forking the package, but an additional package with the asahi configs
<povik>
right
<jannau>
yes
<jannau>
so an
<jannau>
alsa-ucm-conf-asahi which contains just the asahi configs
<mps>
I'll do same for alpine
<jannau>
if it depends on something in alsa-ucm-conf it should just depend on the package
<povik>
sounds good to me
<povik>
it does depend on the top dispatch configs in alsa-ucm-conf
<povik>
they refer to lower-level configs based on card models
<povik>
that is some speed on the smc v2 patchset
<povik>
it's not even an hour old and there's a whole bunch of tags on it
<povik>
rmk: do you do upstreaming-as-a-service? :p
<j`ey>
audio probably isnt a priority :P
<povik>
:(
leitao has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<rmk>
povik: Oracle has asked me to help you guys get this stuff upstream - ultimately, they want Oracle Linux running on the M1, so eventually that also means their UEK kernels as well. That's what is behind my involvement with this effort.
CatDentures has quit [Ping timeout: 480 seconds]
atipls has quit [Quit: My laptop probably went to sleep.]
leitao has joined #asahi-dev
leitao has quit []
<povik>
ah, interesting
<povik>
i thought it's your personal initiative
<povik>
nice that you are getting paid for it then
jim has joined #asahi-dev
leitao has joined #asahi-dev
<sven>
hah, nice!
e1eph4nt has quit [Ping timeout: 480 seconds]
jim has quit [Quit: Konversation terminated!]
off^ has quit [Remote host closed the connection]
leitao has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<rmk>
that's a common requirement for netdev (which is one reason why I have more patches in my tree for phylink than I can get into mainline...)
<marcan>
as is reverse christmas tree, as I found
<marcan>
(and the funny comment style)
<marcan>
netdev seems to be rather special
<rmk>
netdev is special, it has its own different rules
<marcan>
I'm working on wifi right now, so I was thinking of finally resubmitting this soon (with even more stuff tacked on, but maybe in chunks this time *sigh*)
<rmk>
davem, being the second Linux developer, has a lot of say on how networking is treated
<rmk>
or at least I think he was the 2nd.
<rmk>
it's annoying that it's different, but...
<marcan>
unfortunately, special snowflake rules really don't help people who want to contribute...
<marcan>
anyway, I have a meeting in 5 minutes ;)
<rmk>
so, were all the review comments from that submission addressed, or do I need to go through the last submission?
<rmk>
me too. it's not the same meeting is it? I hope not, its supposed to be a 1:1 :D
<marcan>
I *think* it was all addressed and the review tags applied. At least I have everything marked as done here.
<marcan>
I hope not! :D
<marcan>
anyway, feel free to submit up to 4378 if you want
<rmk>
ok, let me see what happens when I resubmit it in a bit.
<marcan>
don't bother with the dt changes of course, since that depends on the pcie power thing
<marcan>
I'll be redoing that next
<marcan>
since yesterday I discovered how to put these chips to sleep finally :)
<kettenis>
hah
<marcan>
and we already had a discussion on how to do the power-enable stuff (differently to how it's done now)
<kettenis>
note that according to the leaked schematics the gpio actually control an internal regulator
<kettenis>
so modelling it as a PCIe voltage rail (if that is the proper terminology) would be kinda wrong...
leitao has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
leitao has joined #asahi-dev
e1eph4nt has quit [Ping timeout: 480 seconds]
e1eph4nt has joined #asahi-dev
<rmk>
marcan: that BUG_ON() in brcmf_fw_add_macaddr() probably ought to be cleaned up, that causes a checkpatch to complain, and will get picked up by netdev folk (patchwork runs checkpatch on submissions and flags stuff)
<rmk>
maybe also scnprintf() rather than snprintf() for the number of characters actually written to the buffer?
<rmk>
but I think the question is - why must snprintf() return exactly BRCMF_FW_MACADDR_LEN characters?
leitao has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<marcan>
rmk: because the nvram buffer is sized to be able to hold exactly that many extra characters for the MAC address (in the worst case), and either way the format string should be constant length, so any discrepancy there means someone introduced a bug
<marcan>
it's impossible for that BUG_ON to fire unless someone screwed up the code later
<marcan>
I added that after a review discussion with our friend Andy where he claimed the existing code was somehow error-prone
leitao has joined #asahi-dev
leitao has quit [Remote host closed the connection]
<marcan>
nobody else commented on that, so if you want to drop the BUG_ON, I don't care; it wasn't in v2 either
<rmk>
oh dear
leitao has joined #asahi-dev
<rmk>
yea, BUG_ON() is generally not a great idea, because it panics the kernel, and if it were to fire, it means users struggle to know why their kernel doesn't boot!
<rmk>
and Linus T doesn't like it being used as an assert() replacement
<marcan>
yeah, that was a BUG_ON() basically because if it fires someone did something very wrong with that driver
<marcan>
but feel free to remove it or replace it with something else
<marcan>
(to be fair, he had some actual useful feedback that patch series - this wasn't one of them, though)
leitao has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]