ChanServ changed the topic of #aarch64-laptops to: Linux support for AArch64 Laptops (Asus NovaGo TP370QL - HP Envy x2 - Lenovo Mixx 630 - Lenovo Yoga C630)
lun[m] has joined #aarch64-laptops
agl7 has quit [Quit: bis denne]
Guest2915 is now known as go4godvin
agl7-Galaxy has quit [Quit: Leaving]
Leandro[m] has joined #aarch64-laptops
mahmoudajawad[m] has joined #aarch64-laptops
juergh has joined #aarch64-laptops
juergh is now known as Guest2937
Prawn[m] has joined #aarch64-laptops
hexdump01 has joined #aarch64-laptops
hexdump0815 has quit [Ping timeout: 480 seconds]
Nao[m] has joined #aarch64-laptops
<cenunix[m]>
I have the same issue with sound not working on NixOS, I have the firmware and alsa-ucm, not really sure where to go from here
<cenunix[m]>
sound card doesn't show up in alsamixer or anything
iivanov has joined #aarch64-laptops
harvestz[m] has joined #aarch64-laptops
owc[m] has joined #aarch64-laptops
<steev>
clover[m]: that *should* work
<steev>
assuming alsa-ucm is 1.2.8.2 (i think it was or higher) - 1.2.9 for sure
<steev>
correct, the tplg is the topology firmware (and is not packaged anywhere upstream yet)
saekau[m] has joined #aarch64-laptops
stirl_ has joined #aarch64-laptops
stirl has quit [Read error: Connection reset by peer]
Programming__ has joined #aarch64-laptops
stirl_ has quit [Ping timeout: 480 seconds]
<steev>
clover[m]: also, fwiw, i *think* fedora uses dracut for their initramfs generations
<clover[m]>
Yeah. I tried to do that and it did generate one. But when I went to use it in my bootloader it didn't work.
<clover[m]>
Using the one arch makes does "work." Since I am using the same kernel and modules as arch. Only thing is that sound doesn't work and it might be because of sharing kernel / initrd between two distros idk.
<steev>
sound things shouldn't come into play until post initramfs
<steev>
unless you're actually loading the modules in the initramfs
<bamse>
no, the ucm applies to thing in /proc/asound/cards...
<clover[m]>
i see
<bamse>
so sounds like a kernel or firmware issue
<clover[m]>
anything i should look for in dmesg?
<bamse>
steev is your guy...
<bamse>
but to answer the specific question...the sound node in devicetree has compatible "qcom,sc8280xp-sndcard"...when the kernel tries to find a driver for that, it will match the modinfo of the snd_soc_sc8280xp.ko and that will be loaded
<krzk>
clover[m]: are you sure you have the topology files in the /lib/firmware directory?
<steev>
it should be in /lib/firmware/qcom/sc8280xp
<ajhalaney[m]>
nice! didn't even think of that but makes sense given that's for all the DSP stuff essentially
<ajhalaney[m]>
I too associate it with battery and external display lol
<steev>
i just assume people have it :(
<ajhalaney[m]>
I don't understand the song and dance of discovery with pd-mapper. It feels like it should live in kernel and dynamically start things up... but good chance I'm not following what that actually does for us.
<ajhalaney[m]>
I have adding a README to the project as a todo list item for like 4 months now but I haven't gotten around to it.. surprise surprise..
<bamse>
ajhalaney[m]: it provides system configuration information to the dsp, and then it's the basis for the kernel knowing when the audio firmware is booted/stopped
<bamse>
ajhalaney[m]: and it would indeed be nice to bundle that information with the dtb instead
<ajhalaney[m]>
bamse: I'm dumb, you'd have to walk me thru step by step with a hair more detail for me to fully understand the flow on the system right now tbh
<bamse>
ajhalaney[m]: we boot the remoteproc, the firmware finds the pd-mapper and ask for the data from the .jsn files...and based on that it makes decisions to start or not some parts of the firmware
<bamse>
ajhalaney[m]: the first encounter we had with this was sdm845, where the modem may or may not run the wifi firmware
<bamse>
ajhalaney[m]: pd-mapper allow you to just change the .jsn files if your product has a pcie wifi chip instead of that solution
<bamse>
you don't have to recompile the firmware
<ajhalaney[m]>
oooohhh it lets APPS start services remotely... I thought it was discovering the services and somehow that helped kernel discover "devices" provided by the DSPs.
<ajhalaney[m]>
that explanation helps, thanks!
<bamse>
the same identifiers are then used in signalling when such services are up/down/restarting
<bamse>
so the reason why clover[m]'s audio didn't work is that the linux driver was sitting there waiting for the audio service to be reported to be up and running
<bamse>
it made total sense to had pd-mapper in userspace when we had 5-6 other such services, but on x13s this isn't true anymore...
<ajhalaney[m]>
:D
<cenunix[m]>
Okay trying to follow this because my audio doesn’t work due to my extremely hacky workarounds on nixos. Is there more firmware pd-mapper needs to find ? I know about battmgr, but is there anything else?
<bamse>
cenunix[m]: yeah, for audio to work you need some other .jsn (perhaps 2?)
hexdump0815 has joined #aarch64-laptops
hexdump01 has quit [Read error: Connection reset by peer]