12:35 <dv_> hi, sorry, missed the compress-offload discussion due to an emergency. thx for the insight. minecrell : any link to those patches and the old firmware?

12:37 <dv_> hm. would it work to use the patches together with the firmware that's on the Android image?

15:24 <calebccff> krzk: I'm trying to test your SDM845 audio DTS series, it doesn't want to apply very cleanly on -rc4, are there other patches I should have as well?

15:25 <calebccff> it fails on patch 4 because the capitalisation of the hex values of the bits in the swm node don't match

15:32 <krzk> calebccff: try on qcom for-next (RC4 is not for testing - many patches won't apply)

15:32 <krzk> or on linux-next of course

15:33 <krzk> the patches do not have dependencies, so they were based on next from 13th

16:03 <calebccff> krzk: ah right, thanks! I'll rebase on next and give it a whirl

16:09 <calebccff> krzk: Would you be against adding mm4/5/6 dai links to the sound node, and same for the slim dai's?

16:10 <steev> linux-next applied cleanly here (i haven't had a chance to test on the c630 yet though)

16:11 <calebccff> DylanVanAssche & JoelSelvaraj[m] found that for everything to work reliably we have to give each individual input/output device it's own alsa "device" and slim channel for routing

16:11 <krzk> calebccff: the mm4/5/6 are not present for other boards

16:12 <calebccff> krzk: right, I don't *think* adding more FE's would break anything in userspace though

16:12 <calebccff> it's just more routing options

16:14 <krzk> calebccff: but isn't the sound machine driver parsing all children?

16:19 <calebccff> krzk: yes, I'm not sure I follow. The q6 ASM service supports 6 front-ends, the 6 mmX-dai-link children, we set alsa UCM configs to route specific frontends (usually) to the wcd934x codec via SLIMBUS, or to some i2s codec

16:20 <calebccff> what FE goes where is totally customisable afaik?

16:21 <calebccff> so exposing all 6 to userspace just gives us more options, for phones with 2 mics, speaker, earpiece and headphones where we might want to support odd configurations like doing stereo with earpiece+speaker, that configuration could be done statically by assigning a particular FE to it

16:22 <calebccff> i hope im making some sense, i might be totally misunderstanding how this works

16:25 <krzk> it could work but then the move of my audio stuff is not equivalent - few boards will get new properties - and actually I am not sure how user-space will behave...

16:27 <krzk> calebccff: another point (I don't remember) maybe these reference some nodes which aren't there for every board?

16:30 <calebccff> krzk: right, it would need to be a separate patch at least. The q6asm interface is just a software one though afaik? I don't see why a board would have a different number of FE's on the ADSP, and if it did I'd argue that's a quirk of the board

16:33 <calebccff> only the db845c and c630 are currently supported in upstream alsa ucm, they share a configuration and reference the output device by index (like "PlaybackPCM "hw:${CardId},2""), the indexes can be preserved because it's based on how the nodes are ordered in DT

16:34 <calebccff> at least, I'm fairly certain it is... citation needed

16:37 <calebccff> the only other upstream device with working audio is the PocoPhone F1 (beryllium) where we have a to-be-upstreamed patch adding MM4: https://gitlab.com/sdm845-mainline/linux/-/commit/cb29a5d86537b38228382e5f330915e04fc9cf4c

16:58 <steev> calebccff: you could ask srinik :) he wrote them

17:03 <calebccff> I'll refactor op6 support on top of krzk's series and maybe see about enabling all MM FE's by default later on if makes sense

17:08 <krzk> calebccff: that sounds ok

17:16 <calebccff> krzk: so i was right about the reordering, except it's not just the order for the FEs... The device number _is_ the index of the node

17:19 <calebccff> I refactored my patch on top of yours and now my mm4/5/6 FEs have different device numbers, mm5 was device 4 before but now it's device 5: https://p.calebs.dev/eddc96@raw

19:24 <minecrell> dv_: not too familiar with the DB410c Android build but yeah, using its modem firmware seems promising

19:26 <minecrell> dv_: you can find the remaining QDSP6 patches buried somewhere in https://github.com/msm8916-mainline/linux, probably just grep for QDSP6 commits there. They are ready now so will probably also send them upstream when I get to it

23:33 <calebccff> bamse: regarding glink/qrtr wakeups: I wasn't aware of EPOLLWAKEUP, it seems like a nice option. The "userspace" in question is ModemManager, I've opened an issue there to discuss the two solutions: https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/694

23:35 <bamse> calebccff: cool, i don't know if it makes much difference on the mpss ipcrtr channel; perhaps we just want to wake up on all traffic on that channel? but it feels nicer to start small/specific

23:36 <calebccff> bamse: right, I was wondering actually. with EPOLLWAKEUP, would wakeups be limited to only messages for that specific client? Or does QRTR always "broadcast" to every client?

23:37 <calebccff> I guess the main thing I'm considering is if some userspcae program sets EPOLLWAKEUP and it causes a bunch of erroneous wakeups it could wind up being really hard to track down, I'm not sure how the wakeup_source is named though

23:38 <calebccff> whereas with the glink channel being the wakeup_source it would be a lot easier to figure out what's up, as well as the on/off switch being global. I'm not sure that's a very strong argument though aha

23:38 <bamse> calebccff: qrtr routes messages to specific socket queues...and you polling with EPOLLWAKEUP will hold a wakeup source until you get back into the next poll with EPOLLWAKEUP

23:38 <bamse> calebccff: based on reading the source...i haven't tried it myself...

23:39 <calebccff> neato, ok that's pretty awesome. And yeah as specific as it could be

23:39 <bamse> calebccff: so it would be per client...but you're right, it circumvent the convenient sysfs wakeup toggle

23:39 <calebccff> Do you know if any changes would be needed in the qrtr net driver to support this?

23:40 <bamse> as far as i understand epoll has all this stuff already in place for us

23:41 <calebccff> I'll give it a whirl, hopefully I don't hit any frozen workqueues :D