chadmed has quit [Remote host closed the connection]
chadmed has joined #asahi-dev
aleasto has joined #asahi-dev
<marcan>
maz: works now, wasn't really much to do other than poke the right SMC GPIOs to enable the devices... I'll bisect out my patches to see what's really necessary
<marcan>
I did run into a bizarro problem, though. read8/read16 from the SD card reader does not work, it returns all FF. But from the WLAN chip it does.
<marcan>
you'd *think* that's just a chip quirk, but Linux already has support for this specific chip and it doesn't work around it... so either the chip revision in these machines is bugged or this only happens on this platform?
<marcan>
it's weird
<marcan>
other than that we also need platform quirks for the SD reader (CD/WP pin polarities), which means yet another OF PCIe device node :-)
<maz>
almost feels like it needs another enable to make it visible (all Fs is usually 'no device here')
<marcan>
but 32-bit reads do work
<marcan>
as do all size writes
<marcan>
this isn't the first time I see this crap in an SDHC host, but it's weird that it's reads only and apparently nobody hits this on other platforms?
<sven>
and i thought that old sdhc on the wii was already cursed
<marcan>
sven: the wii sdhc had this problem too :D
<marcan>
*and* the byte order swap
<sven>
yeah, i still have a trauma from writing that driver and making random sd cards work :D
<marcan>
:D
<marcan>
I will say after I poked the CD/WP polarity bits (which I ghidra'd because faking it in the HV and diffing would be a bit silly just to find two bits...) and worked around the read8/16 thing, it worked fine
<marcan>
not sure about the read8/16 override; I'd love to find someone with one of these things in another machine to find out if it works and if any revision registers say anything interesting
<marcan>
though it shouldn't really hurt to do unconditionally
<marcan>
apple's driver is for multiple SDHC chips and unconditionally uses 32-bit reads/writes for everything
<marcan>
also this problem also happens in osx
<marcan>
(otherwise I'd just find what it does differently)
psykose has quit [Remote host closed the connection]
rkt has joined #asahi-dev
Dcow has joined #asahi-dev
Dcow has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
Dcow has joined #asahi-dev
psykose has joined #asahi-dev
<arnd>
marcan: there are standard properties for inverted wp/cd signals, as documented in Documentation/devicetree/bindings/mmc/mmc-controller.yaml, and I think there is a helper function to parse those
psykose has quit [Remote host closed the connection]
psykose has joined #asahi-dev
<marcan>
ah, cool, I was wondering about that (hadn't looked yet)
<marcan>
should be an easy patch then
kettenis has quit [Quit: Lost terminal]
kettenis has joined #asahi-dev
<kettenis>
marcan: that sdhc/pcie behaviour is really weird
<marcan>
it is
<arnd>
marcan: is it reading the wrong byte (e.g. some byteswap gone wrong), or is it always 0xff for any address?
<marcan>
always 0xff/0xffff for any address
<marcan>
all 8-bit and 16-bit reads
<marcan>
32-bit works fine, any size *writes* work fine
<marcan>
which is bizarre, usually writes are what break first
<marcan>
(byte enables gone wrong)
Dcow has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
<arnd>
marcan: for testing the read_b/read_w change, it shouldn't be hard to find the right person: I see that akashi worked on https://www.spinics.net/lists/linux-mmc/msg61479.html, I can ask him about it when I see him on IRC, and apparently the Ben Chuang from Genesys is active on the driver as well
<j_ey>
marcan: also I had a go at rewriting the SPI driver, it seems to work, but probably would be good to explore some of the registers a bit more to make sure theyre really doing as expected. not sure if I will continue too much with it, if not, you could maybe use it as a starting point
<sven>
i also need to get back and at least clean rtkit up a bit
<kettenis>
don't want to tell you what to work on, but the rtkit stuff is a fairly basic building block, hint, hint
<sven>
:P
<j_ey>
cant have nvme without it!
<kettenis>
getting the DT bindings sorted out will take some back and forth still
<sven>
i think the tricky parts are "do we want/need a separate SART node" and "do we want/need a separate RTKit firmware node"
<sven>
i think we had some discussion about the rtkit node and decided that we don't really need a node for those
<sven>
but it's been a while
<kettenis>
indeed; defenitely more than a memory halt-time ago for me ;)
<sven>
yup :D
<kettenis>
s/halt/half/
<kettenis>
I fear it depends on how the SMC functionality is going to be split out over multiple drivers and whether that needs multiple DT nodes
<j_ey>
yeah, that's something I don't really understand
<sven>
i think most SMC commands can only be done in serial because they use the same shared memory area
<j_ey>
sven: how do other drivers like hwmon or whatever interact with the smc though?
<sven>
unclear. but that wouldn't change if we need an rtkit node
<sven>
we would only need one if we had multiple SMC-based drivers that all talk to rtkit directly
<sven>
(which might still be required, i don't really know what SMC does but at least so far i suspect that we will have a single RTKit client)
<kettenis>
it provides quite a wide variety of functionality, i.e. GPIO, powerdown, sensors
<kettenis>
traditionally those are handled by separate drivers
<kettenis>
but as stated above, these all depend on the same shared memory
<marcan>
sven: macos always seems to serialize SMC commands
<marcan>
I've never seen it overlap them scrolling through the HV logs
<marcan>
so I'd do the same
<marcan>
also, uh, I ran into a weird thing where the first command issued after init returns garbage? (low 32 bits of init result end up in high bits?)
<sven>
but I did see some weird thing where only the first gpio read is successful
<sven>
and read after that always returned zero
<marcan>
either way, we wouldn't have multiple SMC drivers on top of RTKit
<marcan>
what we *could* have is one SMC driver that provides the K/V interface
<marcan>
and then other drivers that talk to *that*
<sven>
until I did I write to _any_ gpio
<marcan>
I did see that too
<marcan>
with the m1n1 driver I made today
<sven>
I feel like we should really only have a single rtkit client for each coproc that may then provide an interface for multiple drivers if necessary
<marcan>
yes, exactly
<marcan>
there is no sane way of muxing stuff over the mailbox
<marcan>
one advantage of doing the SMC driver with sub-drivers on top is you could reload the subdrivers with impunity
<marcan>
while reloading SMC needs an SMC restart or at least a clean shutdown, if we can even do that
<sven>
At least so far smc also seems like the only candidate for multiple drivers anyway
<marcan>
yeah
<kettenis>
yeah
<marcan>
it'd be a bespoke interface
<marcan>
could just be a bunch of sub-nodes of SMC, not declared as a bus
<marcan>
then SMC just does the scan
<marcan>
that would allow us to have different compatibles for different features
<marcan>
and enable/disable things depending on the device config
<kettenis>
I think there are examples in Linux for "MFD"s that don't have a node in the DT for each separate function
<marcan>
sure, but why not have a node?
<marcan>
I mean a sub-node
<marcan>
it's not much different from e.g. some of the power management schemes used on other SoCs
<kettenis>
the hard problem is to come up with a meaningful subdividion ;)
<kettenis>
the spmi pmu has a similar issue of course
rkt has left #asahi-dev [#asahi-dev]
<marcan>
well, there are some obvious ones like GPIO, BMIC
<kettenis>
BMIC?
<marcan>
battery management
<kettenis>
is there actually something to control in that area?
<marcan>
reading levels/status at least
<marcan>
but usually there are at least some controls
Dcow has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…]
Dcow has joined #asahi-dev
Dcow has quit [Ping timeout: 480 seconds]
gpanders[m]1 is now known as gpanders
gpanders has quit [Quit: Reconnecting]
gpanders has joined #asahi-dev
gpanders has quit []
gpanders has joined #asahi-dev
yuyichao has quit [Ping timeout: 480 seconds]
yuyichao has joined #asahi-dev
waagrr has quit [Read error: Connection reset by peer]
waagrr has joined #asahi-dev
vx^ has quit [Quit: :)~]
vx^ has joined #asahi-dev
X-Scale` has joined #asahi-dev
X-Scale has quit [Ping timeout: 480 seconds]
___nick___ has joined #asahi-dev
___nick___ has quit []
___nick___ has joined #asahi-dev
aleasto has quit [Quit: Konversation terminated!]
aleasto has joined #asahi-dev
X-Scale has joined #asahi-dev
X-Scale` has quit [Ping timeout: 480 seconds]
aleasto has quit [Ping timeout: 480 seconds]
aleasto has joined #asahi-dev
squags has joined #asahi-dev
squags has quit [Ping timeout: 480 seconds]
___nick___ has quit []
___nick___ has joined #asahi-dev
squags has joined #asahi-dev
jacoxon has joined #asahi-dev
squags has quit [Ping timeout: 480 seconds]
squags has joined #asahi-dev
<kettenis>
00000005c1800500 3135302a 67612a2a ...
<kettenis>
the tell-tale signs of some Synopsys DesignWare "IP"
<kettenis>
(just something that caught my eye when I watched today's youtube stream)
___nick___ has quit [Ping timeout: 480 seconds]
squags has quit [Remote host closed the connection]