<Daanct12>
perhaps mtk just doesnt get much love as qcom
<aka_[m]>
I have alldocube g99 tablet on the side and vendor appears to not really give a flying duck about firnware
<aka_[m]>
Would be cool to run gnome on it
jhovold has quit [Quit: WeeChat 4.2.1]
jhovold has joined #linux-msm
pespin has joined #linux-msm
<calebccff>
lumag: regarding pixel3 display, would be interesting to know what happens if you send a get_compression_mode message, not sure if reading is supported
Daanct12 has quit [Quit: WeeChat 4.2.1]
Daanct12 has joined #linux-msm
mgonzalez has joined #linux-msm
<mgonzalez>
bamse: jhugo: did you guys see my DT msm8998 proposed work around for ath10k?
Daanct12 has quit [Quit: WeeChat 4.2.1]
Daanct12 has joined #linux-msm
<mgonzalez>
lumag: my apologies: I forgot to CC you on v2 on the ath10k work-around for msm8998
<lumag>
mgonzalez, wlanmdsp is loaded via tqftp, so you can check for it in syslog / journalctl
<lumag>
Well, krzk raised a valid question.
<lumag>
But I also can't find a corresponding piece in msm-4.4 kernel
<mgonzalez>
not easy to correlate kernel timestamps with syslog dates :(
<mgonzalez>
I had a patch somewhere to change syslog timestamps
<lumag>
I see that the driver seems to always send the MSA_READY and then wait for the result
<lumag>
dmesg -T ?
<mgonzalez>
oh boy, never knew about that (embarrassed look)
<mgonzalez>
I have no logs from tqftp, only qrtr-ns & rmtfs
<lumag>
jhugo, do you remember any details by chance? I don't see any kind of special MSA READY handling in msm-4.4
<mgonzalez>
lumag: jeff said that the vendor ath10k driver did not wait for MSA_READY
<lumag>
As I wrote, I don't see it.
<lumag>
See wlfw_msa_ready_send_sync_msg() in msm-4.4 and the calling code
<lumag>
calebccff, i didn't try sending that command. I'm not even sure that read commands are supported by the panel.
<mgonzalez>
lumag: maybe jeff meant the Android driver.
<lumag>
msm-4.4 is the Android kernel
<mgonzalez>
I thought there was a "naked linux" version and an "android linux" version.
<lumag>
That's LE.soemthing vs LA.something
<mgonzalez>
yeah that!
<mgonzalez>
lumag: I didn't catch the valid question from kk though...??
<Marijn[m]>
mgonzalez aka_ the SoMainline repository is still actively being used. All display stuff that I work on is pushed to that repo, _not_ outside of it?
<Marijn[m]>
But thanks for calling me/us dead, effectively
<mgonzalez>
Marijn[m]: thanks for clarifying the situation.
<mgonzalez>
Marijn[m]: somainline is an embedded linux-focused consultancy org, like baylibre?
<Marijn[m]>
mgonzalez: no, we're a bunch of hobbyists/enthusiasts who all happened to work on Qcom-based Sony devices
<mgonzalez>
Oh so you were not paid by sony or qcom for all the mainlining effort?
<lumag>
mgonzalez, I'd note that 4.4 has been sending host_cap after the MSA
<mgonzalez>
what does "MSA" stand for?
<lumag>
No idea (yet?)
<mgonzalez>
my patch only deals with "MSA_READY indicator"
<Marijn[m]>
mgonzalez: I don't know if receiving a device every once in a while counts as payment¸ if it only amounts to yet another thing to "work" on :)
<Marijn[m]>
mgonzalez: why all these questions by the way?
<lumag>
?
aklimov has joined #linux-msm
<mgonzalez>
Marijn[m]: I'm trying to mainline support for another msm8998 device, and I guess I'll be sending a few somainline patches
<mgonzalez>
Marijn[m]: at the moment, I was working on WiFi support, specifically a work-around for the missing MSA_READY indicator.
<Marijn[m]>
Anything important that we haven't sent yet? I'm about to grab the 8998 device for a specific panel request
<mgonzalez>
Sending is one thing, but some patches are not mainline, right?
<mgonzalez>
(I'm on 6.9-rc1)
<lumag>
mgonzalez, if you have downstream running, there should be a debugfs for the wlan. Then it has nice 'stats' file which has msa_read_foo counters
<Marijn[m]>
mgonzalez: well, if they were on the list at some point (but never) merged you have to be careful to have the right vX tag and address previous review
<Marijn[m]>
* mgonzalez: well, if they were on the list at some point (but never merged) you have to be careful to have the right vX tag and address previous review
<mgonzalez>
(My TODO list includes venus decoder, HDMI, cpufreq -- off the top of my head)
<mgonzalez>
Marijn[m]: if you run the msm8998 device, can you give WiFi a try? :)
<Daanct12>
i recently got back to msm stuff and ready to send some patches
<Daanct12>
but i decided to hold it because it's a weird platform
<Daanct12>
are device bring up without wcnss and stuffs are accepted in lkml?
<mgonzalez>
Daanct12: I agree, getting WiFi working is pretty hairy with lots of FW blobs to send to a remoteproc
<mgonzalez>
I'll try to test venus today & tomorrow
aklimov has quit [Quit: Leaving]
<mgonzalez>
I think phh got it working, but he had to disable low-power mode, and when I submitted a patch to do that in mainline, a qcom maintainer said "that's too intrusive, let's find a better way" then forgot about me :(
aklimov has joined #linux-msm
<Daanct12>
mgonzalez: which platform are you working on?
<phh>
mgonzalez: correct
<mgonzalez>
Daanct12: msm8998 (actually apq8098)
<Daanct12>
ah
<Daanct12>
how's the gpu situation?
<mgonzalez>
I defer to phh :p
<phh>
freedreno worked without any issue ootb, though we didn't test much, not even performance
<Daanct12>
nice
<Daanct12>
as long it runs mainline that's already very good :D
<Marijn[m]>
Danct12: wifi is definitely not a requirement to upstream a device!
<Marijn[m]>
The requirements are and should be really lenient (not counting strictness in quality of course) so that you have something to iterate on
<Marijn[m]>
In fact it's always nicer if things land in small isolated chunks/commits
<Daanct12>
ah! so even if initial bring up is just i2c and uart.. that's all?
<krzk>
Daanct12: the rule is release early, release often
<krzk>
or rather concept, not rule
<aklimov>
krzk: even if it's not ready?
Daanct12 has quit [Quit: WeeChat 4.2.1]
<krzk>
aklimov: what does it mean "not ready"?
<krzk>
Then submitting patches explains how to divide your work and send it...
<mgonzalez>
lumag: I don't run the downstream kernel.
<mgonzalez>
krzk: hello, I hope the changelog I provided for the msm8998 ath10k work-around clarified the situation?
Caterpillar has joined #linux-msm
<jhugo>
lumag: I don't remember any MSA ready issue
<lumag>
jhugo, :-D
<jhugo>
lumag: I vaguely remember a QMI issue which I thought I upstreamed
<jhugo>
I haven't actually used Wifi on the 8998 laptop in a long while. Its possible something broke
<mgonzalez>
jhugo: it's the same thing. You even documented it on a web page.
<mgonzalez>
I'm not sure I can intelligently compare mainline & vendor : the user-space tools are not the same
<mgonzalez>
From my perspective, the issue seems to be stuck
<mgonzalez>
It was noted that the driver waits for an indicator that does not come
<mgonzalez>
Not waiting for the indicator works around the issue
<mgonzalez>
The same issue affects at least 3 different msm8998 boards. I don't know if they ran exactly the same FW blobs.
<mgonzalez>
Downstream DT has 2 nodes using the same reg addresses, I thought that's not even valid...
<lumag>
mgonzalez, the first node is disabled by default
<lumag>
And it gets enabled only on one device.
<lumag>
mgonzalez, I won't insist on jumping into downstream. It's just it well might be that the msm8998 expects slightly different sequence somewhere.