<maz>
kettenis: marcan: what service does the SMC gpio provide to the RC?
<maz>
(not going to be online much in the coming days, but trying to keep an eye on this)
<kettenis>
maz: the SMC controls the GPIO that provides power to some of the PCIe devices that are connected to the RC
<kettenis>
wifi/bluetooth on all machines, but also SD card on the new machines I believe
<maz>
kettenis: ah. no power, no link, no love.
<kettenis>
right
<kettenis>
at least that is what it looks like to me
<kettenis>
to me it looks similar to how the hifive unmatched riscv64 board behaves
<sven>
marcan: just make sure to use rtkit from nvme/dev or that asahi-new-nvme branch once you tackle SMC.
<sven>
i had to change the api a bit and it even parses that crash log now ;)
<kettenis>
arch/riscv/boot/dts/sifive/fu740-c000.dtsi has a pwren-gpios property next to the reset-gpios property for this purpose
<kettenis>
my u-boot currently does power on the wifi, but this probably is something that Linux should do
<sven>
those gp?? keys could also use some more reverse engineering
<maz>
kettenis: agreed on both fronts. the pwren-gpios in the sifive binding looks strikingly similar, and Linux should definitely wiggle this pin if present in the DT. we need to work out timings (I doubt power-on is instantaneous).
Dcow has quit [Read error: Connection reset by peer]
Dcow__ has joined #asahi-dev
<marcan>
sven: yeah, I'll merge it in once I'm done with this T2 mess
<marcan>
maz: if that hifive approach sounds good to you, I'll go with that then (plus something for timings)
<rusty-nail[m]>
Is there anyway I could merge touchpad and Wi-Fi branches to try on a intel t2 MacBook Pro 2019?
<_jannau_>
rusty-nail[m]: touchpad changes will not work on T2 yet
<rusty-nail[m]>
I do apologize in upfront if this is a stupid/dumb question to be made in here or anywhere else
<rusty-nail[m]>
_jannau_: Ok, thanks for answering so fast! As you said yet, it will work in the future? By the way, thanks for the awesome work you’re doing
<_jannau_>
I started splitting the driver into ACPI (to be used on T2) and Open Firmware (to be used on M1) variants. that should be ready soon-ish
<rusty-nail[m]>
That sounds awesome….I would like very much to be able to help….I’ll keep studying, maybe some day I can contribute in some manner…again…thanks for everything!
Gaspare has quit [Quit: Gaspare]
<_jannau_>
rusty-nail[m]: does the keyboard backlight control with current driver work on your macbook?
<rusty-nail[m]>
yes, it works. Using the control on the touchbar
<rusty-nail[m]>
but im using a patched kernel and the apple-bce module
<rusty-nail[m]>
if it matters, my macbook is the macbookpro15,3
<jannau>
oh, I was not aware that T2 macbooks use something else to connect keyboard and trackpad. I assume they present as USB devices? which driver is used for the trackpad? bcm5974?
<rusty-nail[m]>
the apple-bce do expose the usbdevices, as far as i can see in my dmesg it does use the bcm5947
<rusty-nail[m]>
if useful for anything here is my full dmesg
<rusty-nail[m]>
t2 is the one who controls keyboard, touchpad, touchbar and sound if not more...
<jannau>
the trackpad could be supported by hid-magicmouse after my changes (after adding vendor and product id). the rest of changes don't apply to t2 macs
thasti has joined #asahi-dev
<rusty-nail[m]>
That sounds good, t2 Macs will be able to benefit from your force feedback implementation as long as Apple-bce is installed. My understanding is correct?
Gaspare has joined #asahi-dev
Major_Biscuit has quit []
MajorBiscuit has joined #asahi-dev
<tpw_rules>
kettenis: thanks for the review. even minor-er nit: the comment fits within 80 columns just fine if you use smaller tabs :) but i will reflow with 8 in mind next time.
<kettenis>
also, it seems your mailer corrupts the diff
<kettenis>
I recommend using git send-mail to send patches
<tpw_rules>
what is wrong with it?
<tpw_rules>
oh, it removed the spaces at the start of the lines
<tpw_rules>
should i send it as v2? or reply to the existing one? or just notes for next time?
Gaspare has quit [Quit: Gaspare]
<kettenis>
if you make changes it should be v2
<kettenis>
otherwise it should be a RESEND
<tpw_rules>
is wrapping the comment enough of a change to do v2?
<tpw_rules>
yes, apparently
<kettenis>
yes
<marcan>
rusty-nail[m]: wifi is not done on T2
<marcan>
I'm trying to figure out firmware selection
<marcan>
spent all day trying to read the OTP on a BCM4364 and failing
<rusty-nail[m]>
thats a shame, please, let me know if there is anything i can be useful with
<marcan>
in principle the patches should work as is if you disable the OTP codepath and manually pick the right firmware, but the entire point of this exercise is not having to do that
<rusty-nail[m]>
i understand. And btw, your work is impressive. Love to watch, i do admire a lot
<marcan>
thanks :)
<marcan>
too bad it doesn't apply to x86... I really wish I had a hypervisor like m1n1 here, that would've probably given me the answer in minutes :p
<j`ey>
where did the OTP addresses come from, for the other chips?
<marcan>
ghidra :p
<j`ey>
oh :)
<marcan>
but indeed as Redecorating[m] hypothesized, the core was wrong
<marcan>
it's *supposed* to be at 0x800 in chipcommon on that one
<marcan>
... but it isn't
<marcan>
or if it is it's blank
<marcan>
this is corroborated by a bunch of references to this in that android driver I found (which also parses OTP for different reasons)
<marcan>
I found a way to dump SROM via index/value, which is apparently related, but that doesn't contain the apple info
<marcan>
and there's an "otp instead" bit and flipping it on just causes read commands to never complete
<marcan>
and yet I finally found the OTP readback code in the apple driver and there's nothing special there
<marcan>
OTOH I'm looking at the arm64 driver... maybe I should look at the x86 one...
<marcan>
anyway, more tomorrow, sleep now
suricato_ has joined #asahi-dev
suricato has quit [Ping timeout: 480 seconds]
<tpw_rules>
what is the status of the stuff necessary for running userspace with 4k pages?