hypotarsal has quit [Remote host closed the connection]
jnn has joined #linux-msm
jn has quit [Ping timeout: 480 seconds]
marvin24_ has joined #linux-msm
marvin24 has quit [Ping timeout: 480 seconds]
svarbanov has quit [Ping timeout: 480 seconds]
jhovold has joined #linux-msm
brgl has joined #linux-msm
<aka_[m]>
Marijn: on what exactly your Suzu died?
<Marijn[m]>
It's dead, I have no way to test :(
<aka_[m]>
On one of my patches or what exactly
<Marijn[m]>
But I rebased on -next without patches on top, flashed, and that was the end o fit
<Marijn[m]>
Other phones are not affected, not sure if it's specific to mainline or age?
<aka_[m]>
Uh so kinda scary to retry
<aka_[m]>
Marijn: it's completely ded or just not booting anymore?
<aka_[m]>
Because there is patch to clk smd rpm
<aka_[m]>
Which I have to ship still
<Marijn[m]>
There's enough voltage on the battery, but it no longer responds to button presses nor USB. No output on UART anymore
<Marijn[m]>
I did get UART and USB before flashing... To make flashing possible
<Marijn[m]>
Did any regulator changes land?
mripard has joined #linux-msm
<aka_[m]>
<Marijn[m]> "Did any regulator changes land?" <- from me for sure not.
<aka_[m]>
konradybcio: ?
<aka_[m]>
i've been running next from december and it was fine for me
<aka_[m]>
if it was just linux which fail to show signs of life there could be room for testing
<aka_[m]>
if it does not even get to ABL then no idea
svarbanov has joined #linux-msm
pespin has joined #linux-msm
danylo has joined #linux-msm
<konradybcio>
Marijn: sounds weird
<konradybcio>
but then it's an 8yo phone by now
<aka_[m]>
konradybcio: unless you keept ducking it as development phone(flashing and so on) it still should be fine
<aka_[m]>
my mido is almost 7y old at this point now(bought 06/2017) and im still not that bad with emmc health
<konradybcio>
i don't think Marijn 's gonna be mad if i tell the world that he's only been using as a devboard and a tea coaster
<TJ[m]>
konradybcio: maybe you are not read my message above, how the audio is going for RB2? I see you are using gpio82 for reset pin wcd937x, while in downstream are using gpio92.
<aka_[m]>
Marijn: regarding usb, i have patch in my tree where we switch to msm8916 driver
<aka_[m]>
wouldn't it be better?
<konradybcio>
TJ: 82 is the correct one
<konradybcio>
no updates on rb2 audio
<TJ[m]>
<konradybcio> "TJ: 82 is the correct one" <- Ok
<Marijn[m]>
konradybcio: it can safely be used as a coaster now that aka_ took over to send the patches :)
<Marijn[m]>
Though aka_ you don't own Loire? Most of the patches are board/device specific still :(
<TJ[m]>
konradybcio: just check downstream from thundercomm and yes it’s gpio82, I have qcm4290 module and the manufacture are reuse thundercomm qrb4210-rb2 devicetree, so it messed up me :D
<bamse>
z3ntu1: good stuff, thanks for the ping
<bamse>
z3ntu1: btw, have you seen a problem where we run out of fds in the tqftpserv process? i had this a while back, not sure what caused it though, and i haven't tried to reproduce it...
<z3ntu1>
bamse: Thanks! Haven't seen the fd issue I think, how would that manifest itself?
<z3ntu1>
Also my other PR https://github.com/andersson/tqftpserv/pull/10 I still need to clean up a bit but that one makes modem work on my SM7225 (SM6350) and QCM6490 (SC7280) phones :)
<z3ntu1>
Also thinking about some way to add tests to tqftpserv but I'm maybe leaning towards having a separate tqftpclient implementation for testing (probably in Python because that's easier) that just tries to run some common operations and especially checks if rsize etc are handled correctly
<bamse>
z3ntu1: i had a rlimit of 128 fds (iirc) which i had hit, so i couldn't create new sockets for the downloads...
<bamse>
z3ntu1: having some tests would certainly be nice :)
<bamse>
i wouldn't mind having the whole thing rewritten in rust ;)
<z3ntu1>
ha, I'm far from a Rust wizard though
<z3ntu1>
might be interesting though
<konradybcio>
Luca Weiss: perhaps only Marijn is in this chat.. but lately there has been some oxidation within linux-msm..
<z3ntu1>
I wonder when somebody thinks about putting tqftpserv into the kernel, we already put qrtr-ns and soon pd-mapper there ;)
<Marijn[m]>
Sounds like the perfect project to convert to Rust
<bamse>
z3ntu1: it's an ugly protocol to put in the kernel, and you need fairly generic file access...
<bamse>
z3ntu1: i've started playing with rust for a few things, and it would be a much better option than python...
<bamse>
z3ntu1: had i implemented any of these tools today, i would have written them in rust
mripard has quit [Quit: mripard]
<z3ntu1>
bamse: yeah for a low level system daemon definitely Python is not a great choice, I was just thinking using that for a simple test suite or something ^^
<lumag>
z3ntu1, I doubt it makes a good fit into the kernel
<lumag>
bamse, yay for Rust!
<lumag>
The only problem up to now is the build directory size. You have to control it, otherwise it can span tens of GBs
<Marijn[m]>
On bigger projects you start talking about hundreds of gbs in a week or
<Marijn[m]>
2
<telent>
I think I triggered "run out of fds in tqftpserv" just by trying to run it without any of the files it was trying to serve, but maybe it doesn't always leak fds. Maybe try looking at /proc/$(pidof tqftpserv)/fd and hit it with requests to see if that directory fills up
<telent>
am curious what the argument is for putting it in the kernel though? i
<z3ntu1>
telent: was just a bit of a joke, since as I wrote qrtr-ns has been put into the kernel a few years ago, and now there's a patchset for pd-mapper moving into the kernel
<bamse>
telent: we moved qrtr-ns into the kernel, because it wasn't agreeable to require x86 users to install and launch qrtr to make ath11k (ath12k?) working
pespin has quit [Remote host closed the connection]
<bamse>
telent: similarly, on lenovo x13s you must install and launch pd-mapper if you want battery stats, audio and usb type-c magic...so we've been discussing (and lumag posted patches) about moving that to the kernel
<bamse>
telent: and on e.g. lenovo c630 you would then be left with tqftpserv as the one and only service that you need to install and launch to get wifi (on the wifi-only version, lte-version also needs rmtfs)
<telent>
more of a packaging reason than a technical one, then. but still a real reason
<telent>
get lennart to merge it into systemd </joke>
<bamse>
lumag, z3ntu1: i've noticed that yes, it's soo easy to just throw a dependency in cargo and suddenly you have 200 crates fetched
<bamse>
telent: the thing is that we don't control the distros...so these things won't work straight out off the box
<bamse>
which is "fine" for various iot and phone use cases, where we pretty much tailor the installation to the device...but for a laptop that shouldn't be the case
<aka_[m]>
then patch was applied in January, so in theory i should send it as fix to my own commit because at time when it got in there splitting was already done.
<aka_[m]>
so it should be fix to f47ec1bcb9d513fc0ba2eca15c56146acbc0c6dd
<aka_[m]>
for gpu i believe i have to follow konradybcio a610 example
<aka_[m]>
should i try and go for describing every a5xx supported?
<aka_[m]>
so not only if a506/a510 but also a530(8996?) and a540(8998)
<aka_[m]>
still as not developer schemas are kinda greek to me.
<aka_[m]>
Somehow i get that indents are like levels deep(scope)
<aka_[m]>
maybe i should also describe a505? we ain't supporting it yet but there are ppl doing 8937
<aka_[m]>
ok so for v2 i will get this one done, fix gpu yaml and drop sdc as its part of shipped series of Marijn
<aka_[m]>
then im left with chunky audio series which is waiting for other patches to get in
<aka_[m]>
is it my internet or git.kernel.org takes ages to load
<aka_[m]>
im trying to get some log but it goes way too slow
<lumag>
aka_[m], for GPU i think we have a mask description
<lumag>
There are some outcasts, like a305b
<lumag>
aka_[m], but I see, krzk asked to split the condition for the clocks entry
<lumag>
aka_[m], if you are afraid of indent levels, you can just c&p the existing adreno-[345] block several times and remove unnecessary parts
<Marijn[m]>
<aka_[m]> "then im left with chunky audio..." <- Theoretically the GPU and MDSS patches are still blocking on IOMMU patches (don't think that was mentioned in your series?) - that is why I refrained from sending them