marcan changed the topic of #asahi to: Asahi Linux: porting Linux to Apple Silicon macs | General project discussion | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Topics: #asahi-dev #asahi-re #asahi-gpu #asahi-offtopic | Keep things on topic | Logs: https://alx.sh/l/asahi
klaus has quit [Ping timeout: 240 seconds]
raster has quit [Quit: Gettin' stinky!]
DarkShadow44 has quit [Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net]
DarkShadow44 has joined #asahi
bgianf has quit [Remote host closed the connection]
ephe_meral1 has quit [Ping timeout: 246 seconds]
klaus has joined #asahi
klaus has quit [Ping timeout: 252 seconds]
odmir has quit [Remote host closed the connection]
odmir has joined #asahi
odmir has quit [Ping timeout: 240 seconds]
klaus has joined #asahi
bgianf has joined #asahi
klaus has quit [Ping timeout: 246 seconds]
odmir has joined #asahi
Emantor has quit [Quit: ZNC - http://znc.in]
Emantor has joined #asahi
klaus has joined #asahi
klaus has quit [Ping timeout: 246 seconds]
odmir has quit [Remote host closed the connection]
odmir has joined #asahi
klaus has joined #asahi
klaus has quit [Ping timeout: 240 seconds]
klaus has joined #asahi
klaus has quit [Ping timeout: 240 seconds]
Necrosporus has quit [Ping timeout: 252 seconds]
robinp has quit [Read error: Connection reset by peer]
robinp has joined #asahi
odmir has quit [Remote host closed the connection]
Necrosporus has joined #asahi
phiologe has quit [Ping timeout: 250 seconds]
phiologe has joined #asahi
klaus has joined #asahi
klaus has quit [Ping timeout: 246 seconds]
marvin24 has quit [Ping timeout: 250 seconds]
marvin24 has joined #asahi
klaus has joined #asahi
klaus has quit [Ping timeout: 252 seconds]
mxw39 has quit [Ping timeout: 240 seconds]
mxw39 has joined #asahi
method_ has joined #asahi
klaus has joined #asahi
klaus has quit [Ping timeout: 246 seconds]
maknho____ has joined #asahi
maknho___ has quit [Ping timeout: 240 seconds]
klaus has joined #asahi
klaus has quit [Ping timeout: 240 seconds]
klaus has joined #asahi
klaus has quit [Ping timeout: 240 seconds]
klaus has joined #asahi
klaus has quit [Ping timeout: 268 seconds]
<method_> why does klaus keep doing that
klaus has joined #asahi
klaus has quit [Ping timeout: 252 seconds]
<ar> marcan: just wondering, will you apply for a pid from openmoko, use something random, or actually buy your own vid?
<marcan> ar: you joined late, I sent a PR for a PID request earlier in the stream
<ar> oh
<method_> Hey marcan, since you're online and sent a message recently I felt its a good time to ask, Is it alright if I use a bot that relays message to / from discord I wrote, I keep it private to myself of course
<method_> Just asking because I use discord a lot more than irc, and forget to check my client often
<marcan> if it's private it's ok
<marcan> that's just a funny bouncer
<method_> Yeah pretty much, it makes it much easier for me to interact
<method_> I'm actually quite proud of it, I wrote it from scratch myself ^.^
<method_> First time I've tackled such a project
VinDuv has joined #asahi
klaus has joined #asahi
vlixa has quit [Remote host closed the connection]
jeffmiw_ has joined #asahi
jeffmiw_ has quit [Client Quit]
Chainsaw has joined #asahi
<marcan> ok, USB is done and hooked up to the proxy, and I made Linux boot work properly with it, shutting down and such
<marcan> (so the host doesn't see a dead USB device)
<marcan> sven: ^^
<marcan> so you can now do linux.py --tty /dev/<some uart> with M1N1DEVICE=/dev/ttyACM0 (the m1n1 ACM device)
<marcan> it's all still backwards compatible with ancient versions. I want to see how long I can get away with my old installed m1n1 that doesn't even support the MMU :)
<marcan> (well, it's not actually backwards compatible at the protocol level, but proxy.py tries the new way before falling back to the old way)
<sven> very nice :-)
<marcan> fixed some fail in USB too (it wasn't actually kicking tx/rx properly, same issue we had with the UART in linux)
<marcan> and applied for a proper PID for us
<sven> yeah, i at least know two or three parts in my usb code that weren't exactly compliant to the spec
<marcan> fixed some spec issues too, yeah
<sven> :-)
<marcan> there are still unimplemented requests but I added a few
<sven> yeah, i just did the minimum required to get it to work on mac os and linux
<sven> luckily they are used to horrible usb devices ;)
<marcan> lol
<marcan> you had the endpoint constant defines backwards btw :p
<marcan> 0x80 is IN
<sven> ouch :D
<sven> it worked though, didn't it? :P
<marcan> yes, for bulk, because there are both anyway
<marcan> I was very confused about the interrupt endpoint which you claimed was OUT :p
<sven> lol
<marcan> but then showed up as IN
<marcan> I initialize the interrupt EP now, otherwise the host keeps retrying
<marcan> I never send anything, it just needs to be there and NAK
<marcan> (not stall)
<marcan> and same with bulk in, you were sending ZLPs all the time which spams the bus
<sven> OSError: [Errno 16] Resource busy: '/dev/tty.debug-console'
<sven> huh
<marcan> uh, are you using --tty with the same device as M1N1DEVICE?
<sven> no :)
<marcan> did you boot with debug enabled? :p
<sven> something's weird, let me try to figure out what's going on
<sven> ah, duh. wrong /dev node
<sven> it's /dev/cu.debug-console
vimal has quit [Ping timeout: 260 seconds]
maknho____ has quit [Ping timeout: 252 seconds]
maknho____ has joined #asahi
<sven> marcan: you forgot to run make format, there's a spurious whiteline in main.c now :P
<marcan> whaaa
<marcan> *force pushes*
<marcan> nobody saw anything
<sven> riiight :P
<sven> now i wonder how iboot detects usb reconnects then
raster has joined #asahi
<marcan> sven: reconnects work fine for me
<marcan> :-)
<sven> really?
<marcan> yup
<sven> thats's... weird
<sven> they don't work for me
<marcan> wait, what happens when you try?
<sven> nothing
<sven> the usb device doesn't show up again
<sven> and i never see any USBRst or USBConnected events
<marcan> HA
<marcan> yeah okay
<marcan> repro'd
<marcan> the problem isn't dwc, it's the TI chip
<marcan> *dwc* handles reconnects fine
<sven> yeah, that's what i figured
<sven> i can manually force a reconnect on the dwc side
<marcan> but my cable breaks out only D+/D- to the USB end
<marcan> so "reconnect" for me means only the USB link, not VBUS
<sven> ohhhh
<marcan> I bet I know what this is; I bet the TI chip does not bring up the DFU mode by default
<marcan> sec
<sven> this also happens when i bring up the phy in host mode
<sven> and then use linux's xhci driver
<sven> the first connection to a port works
<sven> but nothing afterwards
<marcan> actually, not sure, something about my vdm stuff is broken right now
<marcan> not getting replies
totebagel has quit [Quit: Leaving]
<marcan> ok, it's not the pin mapping; doing it doesn't fix it
vlixa has joined #asahi
<sven> yeah, it's something strange
<sven> even bringing up the TI chip with that special apple command doesn't help
<sven> it does enable the PD negotiation stuff though
<sven> my best bet still is that it somehow relies on interrupts from the TI chip :/
<sven> which we could poll as well but ugh...
Bublik_ has quit [Ping timeout: 252 seconds]
Bublik_ has joined #asahi
ephe_meral1 has joined #asahi
<marcan> sven: I wonder if there is a VBUS pin going to the dwc?
<sven> i've looked at the whole dwc register space using RegMonitor and I didn't see any interesting bits flip when connecting a usb cable
<sven> i didn't look at the atc-phy space though
<kettenis> just pushed a rebase of the pcie branch
<sven> hrm. wait. maybe i just found a bit that's flipped
<sven> it's not part of the known dwc3 range though i think
<marcan> sven: in iphone schematics at least, there is a VBUS_DETECT pin on the soc
<sven> 0x502200024 starts at 0xa2000042, then goes to 0xa1000042 after i connect the cable and then finally to 0xa0000042 when i disconnect the cable again
<sven> but it just stays there then if i connect it again
<marcan> sven: does it work again if you re-init the phy and such?
<sven> marcan: i mean.. it works if i just manually force the dwc3 part to reinit the device even without touching the phy
<marcan> huh
<sven> yeah
<sven> it's weird
<marcan> *something* has to change then
<sven> yup
<sven> just not sure what that it yet
<kettenis> addressed sven's comments on the pce pull request
<kettenis> so that might be ready to be merged
<sven> lgtm :)
<kettenis> been thinking a bit about the pcie dt-bindings
<kettenis> apcie is somewhat unique in that is a RC with three integrated ports
odmir has joined #asahi
<kettenis> amost all other pcie RCs that Linux supports in DT mode have only a single port
<kettenis> so that raises the question where to put properties like reset-gpios and max-link-speed
<marcan> I thought the three instances were largely unique; what's shared?
Chainsaw has quit [Remote host closed the connection]
<kettenis> config space!
<kettenis> (and I'm talking about the RC that has the onboard devices, not the Thunderbolt stuff)
<arnd> kettenis: are you sure we actually need these properties? Do you ever need to configure the link speed or trigger a reset using gpio?
<kettenis> We (or at least u-boot) needs the reset gpios
<kettenis> my current understanding is that max-link-speed isn't strictly necessary
<kettenis> would be merely an optimization to not try the higher link speeds on peripherals that don't support them
<kettenis> it seems the SoC supports pci gen4, but the peripherals are gen3 (wifi) gen2 (xhci) and gen1 (ethernet)
<kettenis> it also seems that the SoC supports clkreq (no surprise for what's essentially a phone SoC)
<kettenis> but the refclk-always-on-2 property in the corellium tree suggests that clkreq may not be supported for the ethernet device
<arnd> Is the link speed set through standard pcie registers, or a hardware specific phy driver?
<arnd> my hope was that this would all be part of what m1n1 can do before u-boot does the bus scan
<kettenis> looks like it is special glue logic like on most/all dwc pcie controllers
<kettenis> corellium has some code dealing with the link speed that uses a max-speed-2 property
<arnd> a lot of the server chips actually use dw-pcie implementations, but all the phy handling is done in firmware before it gets handed off to the OS
<kettenis> bringing up the links could be moved in m1n1, but then you'd lose the ability to turn them off for suspend
<kettenis> that's something most server SoCs don't worry about...
<kettenis> if we can express all this using proprties from the standard pci-bus binding I don't see why we shouldn't
<arnd> right
<arnd> which implies using the dw-pcie driver plus some hardware glue, right?
<kettenis> if my reading of the pci-bus.yaml schema is correct it is allowed to have reset-gpios and max-link-speed on pci-pci bridge nodes
<kettenis> not sure if using the dw-pcie driver code in linux makes a lot of sense as there is very little actual logic that you'd be able to re-use
<kettenis> but I guess that's up to whoever is going to write the linux driver
<arnd> that makes sense, since you can have nested buses. I think part of the problem is the the DT bindings for PCI largely go back to the pre-pcie days where a lot of things worked differently, and that the dw-pcie hardware in particular only normally implements a single port rather than a root complex
<arnd> It might be helpful to look at what the older Marvell PCIe driver does, since that emulates a root complex with multiple ports on top of hardware that is somewhat similar to the separate dw-pcie ports
<arnd> so I think the the mvebu pcie binding reflects the root complex that does not actually exist in hardware
<arnd> But since it seems that Apple actually implemented a proper root complex with multiple ports, we wouldn't need to emulate one here, just adjust the Linux driver to properly deal with multiple ports
<kettenis> right; the example I found of a RC with actual ports is the "old" tegra20 one
<kettenis> that is an example of how it could be done
<kettenis> needs some msi-related properties added to it, but maz already had a suggestion for that
<kettenis> the "pci@2,0" node will be needed anyway to add the child device node for the ethernet controller such that we can stick the "local-mac-address" property there
<arnd> right, it seems that the binding is not actually the problem here, it's more a question of how to convince the linux dw-pcie driver to handle it correctly
<arnd> kettenis: is the u-boot driver for dw-pcie derived from the Linux driver?
<kettenis> not as far as I can tell
<kettenis> currently there are seperate standalone drivers for all the dwc variants u-boot supports
<kettenis> I've seen a patch series to unify them in some way
<kettenis> but even then I think you end up with 90% of the code being overrides
<arnd> that might actually help here. In the Linux driver, the common code for dw-pcie makes the assumption that port==root_complex==host_bridge, unlike the tegra driver you found and the mvebu driver that fakes a root complex
<arnd> Not sure how much this needs to be reworked, but if we need to introduce the concept of actual ports, the dw_pcie 'struct pcie_port' probably needs to be split into the port specific bits and those that are shared for the root complex
<arnd> or possibly just renamed if it turns out that everything in there is common to all ports
<arnd> There is already a 'struct dw_pcie' that is looks like it should represent the root complex, but it contains a single 'struct pcie_port', along with members that should be port specific (num_lanes, link_gen, ...), while the 'struct pcie_port' seems to only have members that should be part of the root complex
<kettenis> everything upside down
<arnd> I suppose the current split exists in order to separate endpoint from host most
<arnd> 'dw_pcie' contains the information for both modes, while 'pcie_port' only contains the bits that are specific to host mode
<kettenis> so as far as I can tell, Apple didn't integrate the DesignWare ATU
<kettenis> that means almost all code in pcie-designware.c would be unused
<kettenis> the interrupt code is also completely different
<kettenis> and ECAM is properly implemented
<kettenis> so most if pcie-designware-host.c is useless as well
<kettenis> at that point you might as well pretend it isn't designware at all ;)
<arnd> kettenis: so what is left beyond what the generic pcie host support gives us? only suspend mode, or something beyond that?
<kettenis> and beside the msi support?
<kettenis> there is an issue that the wifi chip needs to be powered on
<kettenis> this done by sending commands to the SMC
<arnd> MSI doesn't have to be done in the pci host bridge driver, I think it's usually done in there because it shares the register space, but in this case there are no registers for MSI
<kettenis> there are registers for MSI
<kettenis> so really that has to be handled by the host bridge driver
<arnd> what do the registers do? I think when I read the corellium driver a while back, it didn't touch any registers for MSI, just passed everything down to the AIC
<kettenis> host ridge registers need to be initiaized to make that happen
<arnd> but isn't that someting that could be done in m1n1 or u-boot rather than having the OS know about it?
<kettenis> you still have to have something that mappes an MSI vector number to an AIC vector number
<kettenis> corellium modelled the wifi power control using some sort of emulated GPIO
<kettenis> but it may make more sense to make it a power domain
<kettenis> I didn't find a precedent for hardware that needs to explicitly power on a pcie device
<marcan> arnd: will poke around nvme next btw (now that I can load kernels fast :))
<arnd> kettenis: does the wifi device show up at all if you don't enable the power? As long as the driver can bind to the device, it can read a custom property to do whatever is necessary
<arnd> if the power needs to be enabled first, we may have to add the equivalent of drivers/mmc/core/pwrseq.c for pci
<arnd> kettenis: regarding the MSI mapping, I'm aware that this needs to be done somewhere, but as I said that does not involve registers, so it could be outside of the PCI host bridge driver if that ends up being easier
klaus has quit [Ping timeout: 252 seconds]
klaus has joined #asahi
choozy has joined #asahi
<kettenis> arnd: the device doesn't show up at all if you don't power it up
artemist has joined #asahi
<arnd> ok, I see
<kettenis> judging from the ADT contents, the SMC is involved in power management and wakeup
<kettenis> so maybe having the SMC manage thing indepently from pcie is an option
<arnd> any idea if macos toggles it at runtime? if not, it's probably enough again to have u-boot turn it on before starting Linux
<arnd> if we decide that it is needed, then a copy of Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.yaml for PCI should work
vimal has joined #asahi
<arnd> MMC currently has a generic "simple" power sequencing driver that handle almost all devices, plus two device specific ones for those that are not as easily abstracted
<arnd> compliant MMC/SDIO devices shouldn't need any of those, but it's fairly common to have to kick an SDIO device in some for (clock-enable, reset, regulator, ...) before it can be probed
<arnd> In theory, SDIO is not different from USB or PCI here, but I don't recall it being needed on these so far
<kettenis> no clue about what osx does, but it appears to be a simple on/off toggle
<kettenis> not sure why the corellium folks came up with code that supports somewhat more complicated power sequencing
<arnd> it probably comes down to how much power we can save by turning it off then, compared to just doing the regular PCIe ASPM
<arnd> if the power savings are not substantial, I'd just turn it on during boot
<arnd> or is this possibly needed for RFKILL functionality?
<arnd> (i.e. airplane mode)
<arnd> In that case, I suspect it could be modeled as a platform specific rfkill device, as long as pcie hotplug works correctly to bring it back up
odmir has quit [Remote host closed the connection]
<kettenis> right, I'll see if I can figure out what happens if I turn it on after booting OpenBSD
odmir has joined #asahi
<kettenis> the root ports don't advertise native pcie hutplug support though
odmir has quit [Ping timeout: 240 seconds]
odmir has joined #asahi
m42uko has quit [Quit: Leaving.]
m42uko has joined #asahi
<pipcet[m]> so I was looking for the most trivial device in my MacBook Pro's ADT, and I think I found it: I've figured out enough about the keyboard backlight PWM for it to be useful, I think; I can control it from m1n1 or Linux now, no driver code yet though
<marcan> arnd: I don't want to waste time on PM stuff until I know that there are savings worth having
<marcan> i.e. until I sit down with a power meter
<marcan> pipcet[m]: nice :)
<pipcet[m]> the built-in power metering/energy budgeting looks fairly sophisticated (plus there are all those temperature sensors), so maybe we don't need that meter...
Chainsaw has joined #asahi
maknho____ has quit [Ping timeout: 265 seconds]
maknho____ has joined #asahi
<marcan> if we can figure it out, definitely
<marcan> is that in-soc only, or does it include external parts?
<marcan> I'd probably still want to cross-check with external metering just to be sure we understand it though :)
<pipcet[m]> probably a good idea. No idea about the hardware side of it, I just saw it in the device tree (and I think it was mentioned in the Corellium code or docs somewhere...)
jeffmiw has quit [Read error: Connection reset by peer]
odmir has quit [Remote host closed the connection]
LucasTorrobaHenn has joined #asahi
odmir has joined #asahi
odmir has quit [Ping timeout: 240 seconds]
maknho____ has quit [Quit: WeeChat 2.3]
maknho has joined #asahi
<pipcet[m]> does anyone happen to know which API keyboard backlights are supposed to use? pwm-leds or pwm-backlight?
jeffmiw has joined #asahi
<opticron> dang, I used to know this
odmir has joined #asahi
<jannau> pipcet[m]: I'd say backlight is for displays, existing keyboard backlight seem to use led_classdev
<pipcet[m]> makes sense
<pipcet[m]> so what about the touchbar thingy? I think that has a separate backlight ...
<kettenis> #define LED_FUNCTION_KBD_BACKLIGHT "kbd_backlight"
VinDuv has quit [Quit: Leaving.]
odmir has quit [Ping timeout: 240 seconds]
<kettenis> pipcet[m]: "apple,fpwm-s5l8920x"
<kettenis> that suggests this is another hardware block that survises from when Apple used Samsung SoCs in their phones
<kettenis> dis you check pwm-samsung.c?
<pipcet[m]> I had a quick look at pwm-* and they seemed different, but I'll have another look at that one...
<kettenis> registers match if the backlight uses channel 1
<pipcet[m]> not really?
<pipcet[m]> there's certainly no prescaler in +0x00 that affects anything, and +0x08 doesn't show anything in the bits corresponding to channel 1.
<pipcet[m]> +0x10 isn't writable, either
odmir has joined #asahi
vlixa has quit [Remote host closed the connection]
choozy has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
ephe_meral1 has quit [Ping timeout: 252 seconds]
vlixa has joined #asahi
odmir has quit [Ping timeout: 268 seconds]
Caloludr has quit [Quit: Textual IRC Client: www.textualapp.com]
Caloludr has joined #asahi
odmir has joined #asahi
jeffmiw_ has joined #asahi
odmir has quit [Remote host closed the connection]
odmir has joined #asahi
vlixa has quit [Remote host closed the connection]
vlixa has joined #asahi
jeffmiw_ has quit [Remote host closed the connection]