marcan changed the topic of #asahi-dev to: Asahi Linux: porting Linux to Apple Silicon macs | Non-development talk: #asahi | General development | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Logs: https://alx.sh/l/asahi-dev
e1eph4nt has quit [Ping timeout: 480 seconds]
e1eph4nt has joined #asahi-dev
derzahl has quit [Ping timeout: 480 seconds]
derzahl has joined #asahi-dev
e1eph4nt has quit [Ping timeout: 480 seconds]
amarioguy has quit [Remote host closed the connection]
amarioguy has joined #asahi-dev
e1eph4nt has joined #asahi-dev
derzahl has quit [Ping timeout: 480 seconds]
derzahl has joined #asahi-dev
derzahl has quit [Ping timeout: 480 seconds]
Rui has quit []
e1eph4nt has quit [Ping timeout: 480 seconds]
derzahl has joined #asahi-dev
e1eph4nt has joined #asahi-dev
dmmcf has joined #asahi-dev
dmmcf has quit [Quit: dmmcf]
coolshaurya has quit [Quit: Client limit exceeded: 20000]
davrosm1_2 has joined #asahi-dev
bluetail215140 has quit []
bluetail215140 has joined #asahi-dev
e1eph4nt has quit [Ping timeout: 480 seconds]
davrosm1_2 has quit [Remote host closed the connection]
davrosm1_2 has joined #asahi-dev
e1eph4nt has joined #asahi-dev
davrosm1_2 has quit []
derzahl has quit [Ping timeout: 480 seconds]
derzahl has joined #asahi-dev
e1eph4nt has quit [Ping timeout: 480 seconds]
e1eph4nt has joined #asahi-dev
davrosm1_2 has joined #asahi-dev
davrosm1_2 has quit []
davrosm1_2 has joined #asahi-dev
davrosm1_2 has quit []
davrosm1_2 has joined #asahi-dev
davrosm1_2 has quit []
davrosm1_2 has joined #asahi-dev
davrosm1_2 has quit []
davrosm1_2 has joined #asahi-dev
e1eph4nt has quit [Ping timeout: 480 seconds]
davrosm1_2 has quit [Quit: This computer has gone to sleep]
kloenk has quit [Remote host closed the connection]
kloenk has joined #asahi-dev
e1eph4nt has joined #asahi-dev
derzahl has quit [Ping timeout: 480 seconds]
e1eph4nt has quit [Ping timeout: 480 seconds]
e1eph4nt has joined #asahi-dev
davrosm1_2 has joined #asahi-dev
davrosm1_2 has quit []
kloenk has quit [Remote host closed the connection]
kloenk has joined #asahi-dev
e1eph4nt has quit [Ping timeout: 480 seconds]
e1eph4nt has joined #asahi-dev
<kettenis> rmk: I'll comment from an OpenBSD/U-Boot perspective today
davrosm1_2 has joined #asahi-dev
davrosm1_2 has quit []
davrosm1_2 has joined #asahi-dev
davrosm1_2 has quit []
davrosm1_2 has joined #asahi-dev
davrosm1_2 has quit []
Race has joined #asahi-dev
jluthra_ has quit [Remote host closed the connection]
jluthra_ has joined #asahi-dev
davrosm1_2 has joined #asahi-dev
<rmk> someone needs to explain this:
<rmk> > > + ret = apple_smc_rw_u32(smcgp->smc, key, CMD_IRQ_MODE, &val);
<rmk> > > + return (!ret) ? GPIO_LINE_DIRECTION_IN : GPIO_LINE_DIRECTION_OUT;
<rmk> > What is the meaning of val in this case?
<rmk> it looks to me like a bug.
davrosm1_2 has quit []
<rmk> ah, helps to read the code comments... I wonder why Andy didn't
e1eph4nt has quit [Ping timeout: 480 seconds]
davrosm1_2 has joined #asahi-dev
davrosm1_2 has quit []
davrosm1_2 has joined #asahi-dev
davrosm1_2 has quit []
davrosm1_2 has joined #asahi-dev
davrosm1_2 has quit []
davrosm1_2 has joined #asahi-dev
davrosm1_2 has quit []
davrosm1_2 has joined #asahi-dev
davrosm1_2 has quit []
davrosm1_2 has joined #asahi-dev
davrosm1_2 has quit []
davrosm1_2 has joined #asahi-dev
davrosm1_2 has quit []
<rmk> is there a reason that the child nodes of the smc device don't have compatibles? from what I can see, having compatibles would make the code easier and avoid stuff such as: pdev->dev.of_node = of_get_child_by_name(pdev->dev.parent->of_node, "gpio"); in the child drivers.
davrosm1_2 has joined #asahi-dev
davrosm1_2 has quit []
e1eph4nt has joined #asahi-dev
e1eph4nt has quit [Ping timeout: 480 seconds]
davrosm1_2 has joined #asahi-dev
davrosm1_2 has quit []
e1eph4nt has joined #asahi-dev
davrosm1_2 has joined #asahi-dev
davrosm1_2 has quit []
e1eph4nt has quit [Ping timeout: 480 seconds]
e1eph4nt has joined #asahi-dev
e1eph4nt has quit [Ping timeout: 480 seconds]
ChaosPrincess has quit [Quit: WeeChat 3.5]
ChaosPrincess has joined #asahi-dev
e1eph4nt has joined #asahi-dev
<rmk> I think a decision also needs to be reached about the %p4ch printf specifier and the smc_key thing (both points brought up by Andy)
<rmk> maybe rather than typedefing a u32 as smc_key, what about struct { char key[4]; } ? That can then be printed using "%.4s".
<rmk> that's legal, because the precision is specified to limit the number of characters written, and it's permitted for the null byte to be absent
<kettenis> rmk; mfd device are weird in that respect, some use compatibles, some rely on named nodes
<povik> rmk: that would print the key in reverse on little-endian (see the thread, hopefully you can make sense of it even though i didn't reply to all at one point)
akspecs_ has quit [Remote host closed the connection]
akspecs has joined #asahi-dev
e1eph4nt has quit [Ping timeout: 481 seconds]
e1eph4nt has joined #asahi-dev
derzahl has joined #asahi-dev
Race has quit [Ping timeout: 480 seconds]
gabuscus_ has quit [Ping timeout: 480 seconds]
gabuscus has joined #asahi-dev
derzahl has quit [Ping timeout: 480 seconds]
e1eph4nt has quit [Ping timeout: 480 seconds]
e1eph4nt has joined #asahi-dev
derzahl 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
arawat[m] has quit [Quit: Client limit exceeded: 20000]
<rmk> kettenis: I think you're about to get a "DT describes the hardware" response :(
<kettenis> the SMC is largely software ;)
tanty has quit [Remote host closed the connection]
tanty has joined #asahi-dev
<kettenis> anyway, many thanks for pushing this forward
<rmk> I'll continue looking at it next week while I'm on the boat (still need to pack the m1 mini)
e1eph4nt has quit [Ping timeout: 480 seconds]
pabloscloud[m] has left #asahi-dev [#asahi-dev]
e1eph4nt has joined #asahi-dev
bisko has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<sven> marcan: oh dear... i'm looking into this dp alt mode dcp thing and I only realized just how cursed the entire DCP protocol is now
e1eph4nt has quit [Ping timeout: 480 seconds]
e1eph4nt has joined #asahi-dev
<marcan> sven: lol
<marcan> rmk: I'll go over the discussion on sunday if that's okay
<sven> seriously… who came up with this crap
<sven> Pretty sure DCP does some magic though. I’ve copied macOS MMIO pokes completely and the dptx clock didn’t come up
<jannau> sven: dpxbar trace for a thunderbolt 3 display: https://gist.github.com/jannau/836902d87f115d03c635eeb128b834c9 as far as I can see nothing interesting
<sven> It selected dpin0, that confirms those are for tunneling :)
e1eph4nt has quit [Ping timeout: 480 seconds]
e1eph4nt has joined #asahi-dev
<heli0s[m]> Some of the new Macs have a feature for detection of impedence of connected headphones, in order to provide more or less voltage to the headphone jack, as described here: https://support.apple.com/en-us/HT212856
<heli0s[m]> The question is - is this controlled by firmware? If so, would it be possible to manually select one of the high and low voltage modes in software?
<heli0s[m]> I lurk around but haven't been able to infer if any knowledge of this was found while reverse engineering the audio part.
<marcan> it's controlled by the driver
<marcan> povik already implemented that stuff I think
<povik> this is measuring the impedance from within m1n1
<povik> the high-voltage mode on the codec are controlled by the driver
<povik> the wip linux driver doesn't control it yet
<povik> it can be a knob in alsamixer
mactheknife[m] has joined #asahi-dev
<heli0s[m]> Thank you for the replies. That's excellent work.
<povik> so yes, it should be possible to manually select the mode
<povik> probably the driver will select its best guess based on impedance when the headphones are plugged in
<povik> and it can be overridden from userspace later
<povik> and there can be another read-only knob with the impedance :p
<povik> so the mode policy could be left out of the kernel driver completely
<povik> but then there's the N audio servers problem
<heli0s[m]> I was asking because I was reading in audio forums that the high voltage mode was only ever active for very high impedence headphones.
<heli0s[m]> As far as I know, you're limited to the auto-selection in macOS.
<heli0s[m]> For headphones that have high impedence that doesn't quite reach the watermark defined by Apple, this could be another advantage for Asahi Linux.
* sven hates DCP
* povik 's thoughts are with sven
e1eph4nt has quit [Ping timeout: 480 seconds]
<as400[m]> sven: entire it nowadays is a crap. Even those databases that store your money in a bank are major crap. But I didn't know that a firmware that runs on bare metal cpus are crap too. It's creepy...
<sven> dunno about the firmware itself, but the IPC protocol is pretty insane
e1eph4nt has joined #asahi-dev
Glanzmann has quit [Ping timeout: 480 seconds]
<as400[m]> sven: win with the protocol may be your next child you never expected. Like the famous 4k patch :)
roxfan has quit [Ping timeout: 480 seconds]
kloenk has quit [Remote host closed the connection]
kloenk has joined #asahi-dev
jeffmiw has joined #asahi-dev
e1eph4nt has quit [Ping timeout: 480 seconds]
roxfan has joined #asahi-dev
e1eph4nt has joined #asahi-dev
<jeffmiw> some update on the hwmon yak to shave: got a first version with 100 Temp sensors, for those interested https://github.com/jfbortolotti/linux/tree/hwmon_smc, output sample on mba m1 : https://borto.fr/nextcloud/s/qPqKKjCzWLEyiQja
<jeffmiw> I will continue to work on it, looking at current/voltage/power. I updated the wiki yaks to shave page.
<jeffmiw> All feedbacks are more than welcome
<jeffmiw> all dev done from my M1 mba :)
<jeffmiw> even if it is getting warm to hot...
<povik> good!
<povik> > Temp CHARGER, BETWEEN INDUCTOR AND MOSFETS(TCHP)
<povik> where are the strings like that from? adt?
nela has quit [Ping timeout: 480 seconds]
<jeffmiw> this is coming from marcan's list of smc keys
<jeffmiw> 21:15 <marcan> very little is from macos/fieldtest, they have few actual references in the software
<povik> ah, just curious, thanks
<jeffmiw> so marcan will be able to elaborate more than me on how he came with that, I'm curious too :). I used it as a reference
Manouchehri has quit [Quit: Connection closed for inactivity]
nela has joined #asahi-dev
<povik> jeffmiw: i get 'file not found' on the link with output sample
<jeffmiw> humm and with this one: https://borto.fr/nextcloud/s/qPqKKjCzWLEyiQj
<povik> better
<povik> what do i run to get an output like that?
<jeffmiw> sensors
<povik> -/bin/sh: sensors: not found
<povik> crap
<povik> let's rebuild the rootfs then
<jeffmiw> pacman -S extra/lm_sensors
<povik> if only
<jeffmiw> which model are you using ?
<povik> this is some static initramfs i am running
<povik> j314
<jeffmiw> let me know how it goes
<povik> should in a moment
<jeffmiw> I will be interested to see the output of the m1n1 proxyclient/experiments/smc.py on this machine to compare to j313
<jeffmiw> for now, smc temp sensors are hard coded based on what I see on j313 but may move some of this in some DT at some point
<jeffmiw> just as a note, my dev branch is based of a july version of asahi branch(based on 5.19.0-rc5), not tested on a more recent version yet
<jeffmiw> will get some sleep now, interested to see the result on your side
<povik> jeffmiw: list of Ts on j314: https://tpaste.us/yv7n
<jeffmiw> thanks. full output for all keys (~1400ish) will be useful too for the other sensors(current/voltage/...)
<povik> and here's what sensors give me: https://tpaste.us/Yrj4
jeffmiw has quit [Quit: Konversation terminated!]
<povik> (in addition to the dmesg flood ;) )