<aka_[m]>
konradybcio: Can you comment on 8917 gcc that while he added oxili GX he forgot about oxili CX?
<aka_[m]>
its part of msm-gdsc-8916.dtsi and obv GX should select parent of CX even on 8917(which is a3xx)
<aka_[m]>
Affe Null: oh hi is that you?
<mort_>
my hardware is more affected by electromagnetic noise on a new kernel than on an old kernel and I can not for the life of me figure out how
<mort_>
it's an apq8016-style SoM, using CSI/CCI for a camera that's connected via a fairly long wire, it should probably have had more shielding but something about the old kernel + devicetree made it robust in conditions where the new kernel + devicetree goes down to 0.5-1 FPS
<konradybcio>
mort_: bisect time?
<mort_>
hmm that works if it's a kernel thing and not a devicetree thing
<konradybcio>
if you have your device tree stored separately and have a change history, that should work too
<mort_>
I have two (very) different devicetrees, one which works for a vendor 4.9 kernel, and one which works with an upstream 5.10 kernel, there's no history apart from that
<konradybcio>
so you made no changes to your own device tree?
<konradybcio>
bisecting the upstream one works just like bisecting any other part of linux
<konradybcio>
you may have to adjust your OOT as you go though, as things change
<konradybcio>
which is expected, considering you're... OOT..
<mort_>
I built the 5.10 devicetree, based on a mix of what's for the upstream apq8016 stuff and what was in our custom devicetree for 4.9
Daanct12 has quit [Remote host closed the connection]
<mort_>
though that looks like it would only affect stuff after the streamon call...
pevik__ has joined #linux-msm
<AffeNull[m]>
<aka_[m]> "Affe Null: oh hi is that you?" <- Yes, I'm the one who sent the 8917 patches
pevik__ has quit [Remote host closed the connection]
<AffeNull[m]>
The reason why I only added oxili_gx_gdsc is that oxili_cx_gdsc is status="disabled" on downstream afaict
<aka_[m]>
AffeNull[m]: Sounds weird
danylo has joined #linux-msm
<aka_[m]>
If you add it anyway nothing bad going to happen I think
<aka_[m]>
If you don't define it in dts as power domain
<aka_[m]>
Also someone will add it at the end when adding msm8937/sdm429
<aka_[m]>
I have 8917 device, might test it one day
<aka_[m]>
Oh, Gpu guy is there
<aka_[m]>
Nice
<danylo>
Hi, I'm working on Turnip driver and looking into a7xx support. I'll have sm8550 board soon and I'd like to know what is the most complete kernel at the moment for it (from GPU support perspective), and tips/workarounds if any would be required. I was told I could ping narmstrong for this. Thanks!
<konradybcio>
from the kernel-GPU standpoint, flto got something working without GMU and I've been poking at the with-GMU side of things for 8450
<konradybcio>
I'd imagine 8550 isn't much different, I can start looking into it soon
<danylo>
Ah, so I should ask flto after all.
<narmstrong>
danylo: hi! V6.3-rc1 will be the most complete
<danylo>
There are no important unlanded patches?
<danylo>
(I need a kernel purely for dev purposes)
arnd has quit []
arnd has joined #linux-msm
<flto>
narmstrong: btw how do you make the boot_a/dtbo_a for the stock fastboot on 8550? (I can work around it in an ugly way, but wondering how to do it correctly.. for 8450 and earlier I could erase dtbo_a and use the debian packaged mkimage to make an older version boot.img with kernel+dtb, but 8550 broke this)
<konradybcio>
did you also erase recovery_a and vendor_boot_a flto
pevik has quit [Remote host closed the connection]