ChanServ changed the topic of #asahi-dev to: Asahi Linux: porting Linux to Apple Silicon macs | General development | GitHub: | Wiki: | Logs:
surge9n has joined #asahi-dev
MajorBiscuit has quit [Quit: WeeChat 3.5]
surge9n has quit [Ping timeout: 480 seconds]
<amarioguy> it works!!!!!!!!!!
<amarioguy> YES
<amarioguy> povik: turns out that was the change we needed all along lol, we boot to userspace and the irq path seems to work without a hitch
<amarioguy> only thing i'm not sure on at this point is where we want the init_completion call, right now i put it in the pasemi_platform_i2c_probe func after common probe is called, but otherwise assuming we don't see further issues seems like the bulk of the patch is done
<amarioguy> still need to run all the other things though like getmaintainers and all (btw for anyone who needs to review it's on the same page as before)
benpoulson has joined #asahi-dev
surge9n has joined #asahi-dev
<chadmed> DmitrySharshakov[m]: i think you misunderstood. i meant that i wont be able to test your changes until some time after next week as i am busy with real life stuff. i cant even pretend to be doing work when doing asahi stuff because my real life duties arent even tangentially related :P
surge9n has quit [Ping timeout: 480 seconds]
jluthra has quit [Remote host closed the connection]
jluthra has joined #asahi-dev
DarkShadow44 has quit [Quit: ZNC -]
DarkShadow44 has joined #asahi-dev
<povik> amarioguy: congratulations!
<povik> well you needed the other changes still
surge9n has joined #asahi-dev
Emantor has quit [Quit: ZNC -]
Emantor has joined #asahi-dev
ethantwardy[m] has joined #asahi-dev
benpouls_ has joined #asahi-dev
surge9n has quit [Ping timeout: 480 seconds]
benpoulson has quit [Ping timeout: 480 seconds]
<amarioguy> yea ofc definitely needed the other changes too
benpouls_ has quit [Remote host closed the connection]
surge9n has joined #asahi-dev
surge9n has quit [Ping timeout: 480 seconds]
benpoulson has joined #asahi-dev
derzahl has joined #asahi-dev
benpoulson has quit [Ping timeout: 480 seconds]
dmmcf has joined #asahi-dev
surge9n has joined #asahi-dev
dmmcf has quit [Quit: dmmcf]
amarioguy has quit [Remote host closed the connection]
amarioguy has joined #asahi-dev
surge9n has quit [Ping timeout: 480 seconds]
surge9n has joined #asahi-dev
pyropeter3 has joined #asahi-dev
surge9n has quit [Ping timeout: 480 seconds]
pyropeter2 has quit [Ping timeout: 480 seconds]
surge9n has joined #asahi-dev
surge9n has quit [Ping timeout: 480 seconds]
dmmcf has joined #asahi-dev
surge9n has joined #asahi-dev
surge9n has quit [Ping timeout: 480 seconds]
<DmitrySharshakov[m]> <chadmed> "Dmitry Sharshakov: i think you..." <- Alright, I understood you. Maybe povik has an opportunity to see that
surge9n has joined #asahi-dev
<chadmed> fwiw that policy looks like itll work fine but in the filter chain json i probably wouldnt specify manually if you can avoid it, let pw sort that out itself
<chadmed> just specify a node.nick for the virtual sink instead
<chadmed> also you need to hide the hardware sink, not the dsp output
<chadmed> applications need to be able to see the DSP sink and not the HW
<DmitrySharshakov[m]> <chadmed> "fwiw that policy looks like itll..." <- On PW chat room I got answer that it'd be better to use autoconnect rather than wiring up from my script. I would also prefer manual immutable routing, let's sort this out later in the MR life cycle
<DmitrySharshakov[m]> chadmed: I hide both
<chadmed> yeah autoconnect is fine, i just mean in the filter chain you have given the virtual sink a of audio_output.platform-audio.analog-stereo which i think may be confusing to some
<DmitrySharshakov[m]> I can hide sink, device (to avoid people messing with profiles in pavucontrol) and stream (like output of the chain in case of speakers)
<chadmed> we dont want to hide the virtual sink since this is the one we _want_ applications to be able to connect to and configure
surge9n has quit [Ping timeout: 480 seconds]
<chadmed> i.e. DEs and their pipewire/pulseaudio integrations need to be able to see it so that users can set the volume etc
<DmitrySharshakov[m]> chadmed: Hmm, alright
<DmitrySharshakov[m]> That's more up to the config file, and one I sent to you is experimental yet, just to test things in a real case
<DmitrySharshakov[m]> chadmed: We don't hide it. Virtual = false means it appears as a hw sink
<chadmed> ohhhh yeah ok i see what youve done there
<DmitrySharshakov[m]> Api = dsp is for the same thing, since else Plasma PA settings applet doesn't see the device
<chadmed> yeah yeah i get it now, all good
<chadmed> then yeah id just give the final sink a nice node.nick, everything else is fine
<chadmed> then the only question in flight is what upstream would be okay with WP actually doing
<DmitrySharshakov[m]> chadmed: So if I have say builtin audio, wp will add a virtual sink. There're extra parts we don't want user or stuff like EasyEffects to interact with: real sink, real device and a stream from virtual sink to real sink. Hide those from everybody except WP (and while testing also allow helvum)
<chadmed> "ucm but not utterly useless garbage" is my preferred way
<DmitrySharshakov[m]> chadmed: Like the mechanism of discovery
<chadmed> yeah yeah its all clicked to me now, i didnt notice the beauty in that last line of the filter chain
<DmitrySharshakov[m]> chadmed: Yes I proposed we should have an API to read files from WirePlumber scripts
<chadmed> its all good now im totaally happy with that
<DmitrySharshakov[m]> While George, one of the maintainers, is on his vacation, we'll have to stick with my current approach. Then, if he's fine with the fact WP scripts will be able to read FS under WP config dirs, then I'll implement it the way you proposed as I now agree it should be almost 100% descriptive
surge9n has joined #asahi-dev
<DmitrySharshakov[m]> I opened a proposal for nobody to forget about this: localhost:7474
<DmitrySharshakov[m]> lol
<DmitrySharshakov[m]> s/localhost:7474/
dmmcf has quit [Quit: dmmcf]
<DmitrySharshakov[m]> I'd wait for comments and concept approval from maintainers and then probably implement some functions for filesystem access
dmmcf has joined #asahi-dev
dmmcf has quit []
surge9n has quit [Ping timeout: 480 seconds]
dmmcf has joined #asahi-dev
dmmcf has quit []
dmmcf has joined #asahi-dev
systwi_ has joined #asahi-dev
systwi has quit [Ping timeout: 480 seconds]
surge9n has joined #asahi-dev
surge9n has quit [Ping timeout: 480 seconds]
surge9n has joined #asahi-dev
surge9n has quit [Ping timeout: 480 seconds]
surge9n has joined #asahi-dev
benpoulson has joined #asahi-dev
surge9n has quit [Ping timeout: 480 seconds]
benpoulson has quit [Ping timeout: 480 seconds]
<DmitrySharshakov[m]> povik: based on it appears to be decent to apply 50 or 100 Hz filter (DC_BLK0 -> HPF_FREQ_PB) in hardware for (sub)woofers, so that vibration is filtered out + DC protection active. as well as 800 Hz for tweeters as it's planned. This could 1. make us able to drop the lower part of woofer FIR filter. 2. People who want raw ALSA can just play sound
<DmitrySharshakov[m]> on woofers via some sort of custom channelmap.
dmmcf has quit [Quit: dmmcf]
the_lanetly_052 has joined #asahi-dev
surge9n has joined #asahi-dev
dmmcf has joined #asahi-dev
<chadmed> please note lines 5 and 6 of that document.
<chadmed> i dont tune the "
<chadmed> "subwoofers" differently to the woofers anymore, they have the exact same IR
<chadmed> sounds better at low to moderate volumes and doesnt compromise clarity at all. theres still a teeny bit of boxiness around 400-600hz but ill play around with that when i have the time
<DmitrySharshakov[m]> Yes, but hardware filter removing DC and vibration frequencies can still improve things. Is 100 or 50 Hz appropriate?
surge9n has quit [Ping timeout: 480 seconds]
<chadmed> 50Hz would make more sense to me, the drivers are still pretty good down to about 70Hz so i dont really want to cut off that real nice low end that gives them their fullness
<chadmed> but i would just not cut anything out and let the DSP take care of it because that gives us finer grained control over their profile
<DmitrySharshakov[m]> Yes, so it'd be great to test 800 Hz cutoff for tweeters and 50 Hz for other 4 speakers.
<chadmed> imo the hardware/kernel should only be concerned with stopping people from melting their laptops and nothing else
<DmitrySharshakov[m]> chadmed: Maybe 2 Hz then&
<DmitrySharshakov[m]> > <> but i would just not cut anything out and let the DSP take care of it because that gives us finer grained control over their profile
<DmitrySharshakov[m]> * Maybe 2 Hz then?
<chadmed> is the HPF configurable?
<chadmed> anything below 20hz is noise and id expect the codec to high pass on that regardless of what we tell it to do
<chadmed> but it shouldnt do anything to input above that
<DmitrySharshakov[m]> See 8.9.8 in . There're options: no, 2 hz, 50, 100, 200, 400, 800
<DmitrySharshakov[m]> It's a coarse-grained mechanism which evolved from DC protection. Not really an equalizer or something like that. marcan first found it as a measure to protect tweeters from low frequencies at kernel level
surge9n has joined #asahi-dev
surge9n has quit [Ping timeout: 480 seconds]
surge9n has joined #asahi-dev
dmmcf has quit [Quit: dmmcf]
isoriano has quit [Remote host closed the connection]
MajorBiscuit has joined #asahi-dev
<chadmed> yeah right, so id set it to 2hz on the woofers and let the DSP handle everything else then
<DmitrySharshakov[m]> Alright
<DmitrySharshakov[m]> I have also read some materials on IV sense. That's mostly for cases of overdriving mobile microspeakers. So a speaker like a phone one can be operated on power higher than the rated one while being monitored and corrected with IV sense enabled amp. I guess that's not necessary nor suitable for MacBook pro level audio, since such an overdrive will reduce the quality and tone reproduction, plus I guess builtin speakers are not of
<DmitrySharshakov[m]> "microspeaker" class so they should not need such a drive mode
<DmitrySharshakov[m]> How is volume with caps in place? How does it compare to macOS defaults?
<povik> don't forget that the codec doesn't filter all below the frequency we set
<povik> it's a frequency at which it has -3 dB attenuation
<DmitrySharshakov[m]> Yes but should keep things safe I guess. Low volume does no harm typically
<DmitrySharshakov[m]> Is the volume loud enough with caps?
<DmitrySharshakov[m]> Is there any progress from yesterday (like testing WP changes and kernel driver)? Is there a decent way of marking the device as either J314 or J316 (probably DT prop on audio node could help)
<povik> so far i have written in -3 dB cap below macOS values, still very loud, but that was mostly arbitrary while i am focusing on other issues
<povik> what do you mean DT prop on audio node?
<povik> if you mean the j314/316 distinction, which is currently lost, that is just matter of modifying the model= property
<DmitrySharshakov[m]> Like if it should be named `MacBook Pro J314 Internal Speakers` or J316
<DmitrySharshakov[m]> Alright
<DmitrySharshakov[m]> `-3 dB cap below macOS values` is that about HFP or common volume cap?
<povik> ^ here, we just change that
<povik> or rather set it from the j314/j316 specific files
<DmitrySharshakov[m]> Alright
<povik> common volume cap
<povik> the HFP i will lock on the highest setting for the tweeters, on the woofers i will let them be set from userspace
<povik> at least initially
<DmitrySharshakov[m]> Is HPF 'sharp' enough to cut low frequencies off btw?
<DmitrySharshakov[m]> What about 2 Hz 'DC protection' mode?
<povik> i don't know yet, got stopped by some other work on the drivers
<povik> you mean that it would be good to assure the filter's not disabled on the woofers?
<povik> i agree, but i want to give chadmed a chance to play with the filter :p
<DmitrySharshakov[m]> Well, 50 Hz might be too high, but since we can why not enable 2 Hz cutoff? It will protect from DC bias
<DmitrySharshakov[m]> 2-50 Hz should do no damage to woofers I guess, so it should be safe to keep those 'convenience' things to userspace
<povik> of course we don't want to disable it (2 hz appears default and was set already)
<povik> chadmed: scratching my head at the prealloc thing now
<DmitrySharshakov[m]> Ah, alright, wasn't sure if it was enabled by default
<chadmed> DmitrySharshakov[m]: yeah the idea is the kernel driver passes off a device with a "here is 6 codecs, nothing you do could ever blow them up" and the rest should be entirely up to us
<chadmed> sound quality, "niceties" like filtering out subsonic frequencies etc is not the job of the kernel
<chadmed> i already have an aggressive rolloff under 20hz in the DSP and it works absolutely fine, the codec should only do DC protection and the 800hz HPF on the tweeters because those are safety guarantees
<DmitrySharshakov[m]> chadmed: Exactly. So 2Hz for woofers, 800 to tweeters and we're safe. Then WirePlumber should do the "niceties" and automatic stuff
<chadmed> yep exactly
<DmitrySharshakov[m]> So then I'm awaiting for initial testing/review for my WirePlumber MR and maintainers' response on the file access thing to improve further
benpoulson has joined #asahi-dev
benpoulson has quit [Ping timeout: 480 seconds]
<chadmed> povik: it's admac
<povik> i would reckon
<povik> this boils down to allocating admac-usable buffer
<povik> chadmed: you know more why it fails?
<chadmed> i assume its trying to allocate that buffer before admac is fully alive
<chadmed> but im not so sure, it can repro it continuously by unloading and loading snd-soc-apple-silicon
<chadmed> but if i unload then load apple-admac and then do the same, it allocates successfully
<chadmed> so maybe admac is being put in a bad state on init?
<povik> ah
<povik> 12:38 < chadmed> i assume its trying to allocate that buffer before admac is fully alive
<povik> not sure that can happen. by that point we have requested admac channels so i would assume it's been fully probed
<marcan> does anyone have the pkg file for grub-2.06.r261.g2f4430cc0-1 lying around? I'm pretty sure yesterday's update broke stuff... (still boots, but the unicode menu is very borked)
<marcan> I *think* it's throwing up an out of memory followed by "no suitable video mode found", so I'm going to guess something about the hidpi screen breaks it...
<marcan> (and then it falls back to the uboot text console, which isn't... great)
<marcan> thanks!
<marcan> jannau: yup, that one works. sigh.
<marcan> ALARM keeps breaking things and then doesn't take our fixes :(
<jannau> they have merged the rust fix last week. finally
<marcan> still no jemalloc...
<jannau> oh, I forgot to update the wiki
<chadmed> jannau: i did it
<jannau> or libunwind
<chadmed> apple-admac causes a segfault when reloading snd-soc-apple-silicon now -.-
<povik> userspace segfault?
<chadmed> nah kernel
<povik> that the modules do not fully clean after themselves wouldn't surprise me
chadmed_ has joined #asahi-dev
<povik> haven't tested that extensively
<povik> (but accepting bug reports)
<chadmed> LMAO
<povik> chadmed: don't spend time on unloading the old code
chadmed_ has quit []
gabuscus has quit [Ping timeout: 480 seconds]
<chadmed> hmm
bisko has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<marcan> fixed it by increasing the GRUB heap from... 1MB... to 16MB...
<marcan> let me try 2MB and send a PR if that works...
<marcan> yup, works
chadmed_ has joined #asahi-dev
chadmed_ has quit []
<chadmed> apple-admac 39b400000.dma-controller: deferred probe timeout, ignoring dependency
<chadmed> coincides with failed allocs
<povik> what does /sys/kernel/debug/deferred_devices say
<povik> before the timeout
chadmed_ has joined #asahi-dev
<povik> (you need to mount -t debugfs debug /sys/kernel/debug first, maybe there's typo)
chadmed_ has quit []
<chadmed> povik: its empty
<povik> hm, is it stuck in probe? is that what the message means?
chadmed_ has joined #asahi-dev
<chadmed_> [ 101.348516] Failed to set up IOMMU for device 39b400000.dma-controller; retaining platform DMA ops
<chadmed_> this is all i get when trying to reload when its in this state
<povik> well
chadmed_ has quit []
<povik> ah i am an idiot
<povik> of course it won't work for me since the t6000 darts weren't upstreamed
<povik> and i am running 6.0-rc1 + audio
<povik> and it fails by not allocating
<povik> also the 10s delay before it probes was that deferred timeout
<povik> but i didn't notice the messages
<povik> let's run it once more to confirm
<povik> i guess they removed the timeout print in 6.0-rc1?
<povik> but the symptoms match
<povik> $ git merge asahi/bits/020-t6000-dart
<povik> you always have a commit at hand, dont you :-p
<j`ey> git log ftw
<chadmed> odds throwing some sleeps around apple-admac fixes it
<povik> so that fixed it on my end
<povik> chadmed: sorry to say we are back to me not reproducing it
<chadmed> link to branch?
<povik> let me push those
<povik> pushed
<povik> but maybe it's best you try after it makes it's way into asahi
<povik> i have few loose ends to tie, then it should be ok to merge
<chadmed> yeah at this point i just want to confirm if its something on my end and im just going insane or something
<povik> my guess is it's indeed a timing issue manifest when loading modules
<povik> which i don't do
<chadmed> ah do you have everything built in
<povik> yup
chadmed_ has joined #asahi-dev
<kazukih[m]> Everything? Including the firmware?
isoriano has joined #asahi-dev
* j`ey builds the firmware in
* povik did build in the firmware at some point
chadmed_ has quit [Remote host closed the connection]
<kazukih[m]> Hm, doesn't firmware loading break if you inline modules unless the firmware is also inlined as well?
<povik> don't think so, i don't need firmware for audio testing though
<kazukih[m]> Huh weird, last time I inlined everything graphics/wifi/bt broke
<kazukih[m]> Which was fixed by inlining the firmware
chadmed_ has joined #asahi-dev
<marcan> graphics does not depend on any firmware
<marcan> wifi/bt does
<povik> okay, hpf works. it's audible on the woofers under pink noise
<marcan> HID on M2 does but does deferred loading, so it will still work
<marcan> so really just wifi/bt
<marcan> you don't need to embed it, putting it in the initramfs is enough
<marcan> I have an initramfs with just firmware lying around for this purpose
<kazukih[m]> I see, thanks
<kazukih[m]> marcan: I meant on my Intel machine
gabuscus has joined #asahi-dev
gabuscus has quit []
gabuscus has joined #asahi-dev
gabuscus has quit []
chadmed_ has quit [Quit: Konversation terminated!]
gabuscus has joined #asahi-dev
gabuscus has quit []
chengsun has quit [Quit: Quit]
chengsun has joined #asahi-dev
gabuscus has joined #asahi-dev
gabuscus has quit []
benpoulson has joined #asahi-dev
gabuscus has joined #asahi-dev
benpoulson has quit [Ping timeout: 480 seconds]
gladiac has joined #asahi-dev
gladiac has quit [Quit: k thx bye]
* amarioguy amarioguy attempts to figure out if i2c should be a patch series or one giant patch
<povik> one 'giant' patch
<povik> it's small, really
bisko has joined #asahi-dev
qcyrdqcpzg[m] has joined #asahi-dev
<amarioguy> sven - figured i'd give a status update, we boot to userspace successfully now without issue after fixing the enable/disable bits, some minor pointer issues and not being an idiot and forgetting to init the completion for the first time (that last one hung me up for some time lol)
<amarioguy> i put init_completion in the platform probe for now is that fine
<amarioguy> since i'm not sure if the old pasemi systems will use this path
<amarioguy> don't mean to ping you too much btw, just making sure things are good before i start preparing things for upstreaming
<sven> sounds like it’s time to submit it to the mailing lists
bisko has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<amarioguy> alright perfect, lemme get a clean tree, get the patches ready, i'll cc you on the emails once they're done
<sven> getmaintainers should automatically add my mail address anyway
<amarioguy> ah true
<povik> just add
<povik> btw does everyone contributing to kernel eventually write their own little helper scripts for series prep?
<povik> mine is
<j`ey> i stole a coworkers
<sven> I’m too paranoid to do that automatically
<povik> i'm too paranoid to do it manually each time
<sven> iirc b4 is getting sone feature like that as well
<j`ey> :)
<povik> mine prepares a like
<povik> so you can further modify it
<povik> in the folder with the outgoing patches
<jannau> I started using patman from u-boot (tools/patman/patman) which is nice since it uses annotations in the commits itself
<j`ey> jannau: yeah the one I use picks up Cc: from the commit messages too
<povik> does it too afaik
<povik> or is it git-send-email that does it?
<jannau> i.e. you can add patch/series changed entries when you amend the actual commits
<sven> send-email picks up Cc: from commit messages
<amarioguy> to be safe i should probably apply my patches to a clean copy of the tree i suppose
<amarioguy> since i'm submitting it as one patch and not a series
<sven> yes, and run checkpatch on it as well
<sven> (that might generate some spurious warnings but also prevent common mistakes)
leitao has joined #asahi-dev
leitao has quit []
leitao has joined #asahi-dev
Race has quit [Ping timeout: 480 seconds]
leitao has quit [Ping timeout: 480 seconds]
benpoulson has joined #asahi-dev
benpoulson has quit [Ping timeout: 480 seconds]
MajorBiscuit has quit [Ping timeout: 480 seconds]
leitao has joined #asahi-dev
<marcan> just pushed updates to -dev to get rid of kernel image compression and make update-m1n1 work with different ESP mount styles
<marcan> with that, you can try systemd-boot (doesn't look great on the uboot console right now)
<marcan> you're on your own if you do that/etc
<j`ey> WhyNotHugo: ^
<marcan> I guess "vmlinuz" is a lie at this point, not sure if that should be something else, but shrug
<marcan> I should look at how Arch does it
<whynothugo> Oh, nice. I've been using systemd-boot, but have been manually decompressing during installation till now.
leitao has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<marcan> need to see if kettenis would take patches to improve the u-boot console, because that is *very* broken right now
<marcan> (and systemd-boot inherits it)
<j`ey> marcan: how so?
<jannau> does anyone uses uncompressed images on x86? handling is easier there due to self decompression code
<marcan> graphic drawing characters confuse it, it has terminal size confusion / scrolling issues (grub without gfx mode ran into this too), and also the keyboard is flaky at least on my m1pro
<marcan> to the point I need to type character by character and make sure it worked
<jannau> related systemd issues/feature request
<whynothugo> I was going to point out that `bootctl status` is a reliable way to find the ESP mountpoint, but `--json` doesn't work.
<whynothugo> Any thoughts on tow-boot marcan? It usually targets phones a bit more, but might not be terrible here.
<marcan> doesn't sound like it fits our model
gabuscus has quit [Ping timeout: 480 seconds]
<whynothugo> It does work somewhat as a staging for upstreaming to u-boot in some aspects.
<whynothugo> But I guess it's a stretch for this case.
<jannau> we do not really have problems getting things into u-boot upstream and we have our own fork anyway
gabuscus has joined #asahi-dev
<jannau> I still need a see if there's a nicer way to handle the blessed ESP than the way we do it currently
<tpw_rules> systemd-boot has always worked okay for me on nixos fwiw, but yeah the graphic characters do show up funny
<tpw_rules> except for the blessed ESP, doesn't tow-boot fit the "just install UEFI" model pretty well?
<marcan> what does it offer over regular u-boot? the website makes it sound like it's intended to be "board firmware".
<tpw_rules> yes, that's the point. it's intended to be a standard firmware experience like UEFI firmware is on x86 systems. the big things it offers are a consistent UX and graphical device selection
<tpw_rules> i don't know if it's ultimately feasible for reasons like the ESP being married to the macos stub, but it seems like an ideal thing for the "just give me UEFI pls" option in the asahi installer
<tpw_rules> and the eventual "asahi isn't a distro" target. though maybe you always intended to offer a unified installer
the_lanetly_052 has quit [Ping timeout: 480 seconds]
<povik> ugh
<povik> marcan: so, this ^ would be revamped bits/070-audio on top 6.0-rc1
<povik> you can check out the safety stuff while i sort out the DTs
<DmitrySharshakov[m]> Looks great! Why 400 Hz as corner frequency? Tweeters are intended for 2 kHz+ playback, so setting corner to 800 Hz effectively cuts off more. Or is 400 fine as well and you gave more freedom to userspace without introducing safety risks?
<povik> nah, that's just me misremembering the maximum when i wrote it
<povik> let me fix it to 800 hz right away
<povik> pushed
<DmitrySharshakov[m]> Cool. I hope the WP config snippet I sent does work properly.
<povik> didn't get the chance to try it yet
<povik> still some work on preparing the kernel side for new merge
<DmitrySharshakov[m]> Getting everything rebased on top of 6.0 etc?
<povik> yeah, but mostly getting my wip stuff in shape
<povik> there's been architectural changes and new features
<povik> and the old code merged in asahi started conflicting with pieces upstream
<amarioguy> alright sven just sent the patch email, hopefully i didn't screw up too awfully
* povik refreshes mailbox
<amarioguy> first time i used git send-email lol
<amarioguy> well it's on lore, with the right names and all (though the lack of email addrs may be because i use outlook)
<povik> ah you didn't CC asahi, so i won't get a copy :(
<amarioguy> my bad, if i get a response i'll cc it (i just used the output of get_maintainers to stay safe, i'll remember to cc that moving forward)
<povik> no, that's okay, i can reply by downloading it from lore and importing it
<sven> did you base it on linux 6.0-rc1? That should already have the list in MAINTAINERS
<sven> I’ll take a look tomorrow
<povik> ha, sound drivers probe with the patch applied
<povik> amarioguy: seems ok
<amarioguy> sven: i based off the asahi branch
<amarioguy> (before today's update to clarify)
<sven> that’s usually a bad idea, you want to base on torvald’s tree (or possibly Linux-next)
<sven> doesn’t matter for this patch though since nothing changed
<amarioguy> right, i'll note that moving forward, i did test in torvalds's tree and it worked just to be sure
<amarioguy> i was just unsure where i wanted to base it since again first time sending to lists
<amarioguy> will note that
isoriano has quit [Quit: Leaving]
gabuscus has quit [Ping timeout: 480 seconds]
gabuscus has joined #asahi-dev
benpoulson has joined #asahi-dev
benpoulson has quit [Ping timeout: 480 seconds]
benpoulson has joined #asahi-dev
<povik> amarioguy: seems ok
<povik> uh ignore that
povik has quit [Ping timeout: 480 seconds]
c10l has quit [Quit: Ping timeout (120 seconds)]
c10l has joined #asahi-dev
* amarioguy acknowledges request
povik has joined #asahi-dev
digidev[m] has joined #asahi-dev
Race has joined #asahi-dev