<nta>
on my x13s (running jhovold's sc8280xp linux tree- still on the 6.9.0-rc2 bits, haven't checked with the rc4 branch yet), bluetooth seems to be broken (since commit 5fbfdc8 on their v6.8 branch which i suppose fixed accidentally allowing use of unconfigured device addresses) - the device address looks somewhat incorrect (00:00:00:00:5A:AD), any operations on the device lead to EOPNOTSUPP, which makes me wonder... what is supposed to set the
<nta>
device address (the dt in firmware/a dt overlay I have to add myself? some user-space daemon?) and.. what would the ideal steps here even be? i feel like i missed something during device setup almost
pespin has quit [Remote host closed the connection]
pespin has joined #linux-msm
abelvesa has quit [Quit: Lost terminal]
<jhovold>
nta: we currently don't know how to access the x13 bluetooth device address so the controller starts up as unconfigured
<nta>
ah, there's a GitHub wiki page on the repo, didn't realize that- d'oh
<nta>
discoverability for that is a bit wacky
<nta>
so I am supposed to use public-addr, I see.. I did try a few commands but I hadn't tried that yet, will do shortly
<nta>
yea, that worked- my apologies for not finding that this was documented (and not managing to find that command somehow.. either- a lot of web search results were for usb adapters and other stuff)
<jhovold>
nta: no worries, you can always ask on #aarch64-laptops where a lot of x13s users hang out too
anholt has joined #linux-msm
f_ has joined #linux-msm
anholt has quit [Quit: Leaving]
<calebccff>
lumag: so the thing I mentioned earlier about the op6, turns out there's two additional GPIO controlled power rails, downstream just used pinctrl to drive them...
<calebccff>
lumag: I modelled them correctly in DT as regulator-boot-on regulators, and by correctly enabling/disabling/enabling them it makes the panels work on devices with crappy replacement ones
<calebccff>
lumag: it doesn't fix the weird race condition with printk though, things are still broken when booting without "console=ttyMSM0,115200"
<calebccff>
oh yeah the other part is calling devm_gpiod_get() with the right flag so we don't keep the panel in reset during probe
<calebccff>
because the bootloader enables everything, it makes sense to skip the first prepare() call (or adjust it to first power OFF the panel)
f_ has quit [Ping timeout: 480 seconds]
<lumag>
calebccff, Well, you can't reliably power it off. The regulators might be shared, etc.
<lumag>
But you surely should be able to reset it
pespin has quit [Remote host closed the connection]
<calebccff>
lumag: we can reliably power it of, the regulators are l14a (which according to the schematics are used ONLY for the panel, there's even a comment denoting it as such) and then the other two are GPIO controlled, and are also only for the panel
<konradybcio>
aka_: my tab has 4 awinic amps
<konradybcio>
but rb2 will benefit from it, for sure
<aka_[m]>
my lemon probably have two
<aka_[m]>
<konradybcio> "aka_: my tab has 4 awinic amps..." <- well, have you had some time to check that icc logs from pastebin i posted?
<aka_[m]>
not sure if its supposed to be this way
<konradybcio>
the all zeroes log?
<konradybcio>
does the device suddenly feel super slow?
<aka_[m]>
not much change
<aka_[m]>
almost none
<aka_[m]>
sync state ain't commented
<aka_[m]>
tho not sure if i haven't booted with clk_ignore_unused
<aka_[m]>
konradybcio: so its not supposed to be like that/
<aka_[m]>
haven't you had some flag for dts when icc was "wired" so rpmcc would not keep those clocks hostage?
<konradybcio>
nope
<konradybcio>
do you have a debugcc port by chance?
<aka_[m]>
no
<aka_[m]>
konradybcio: i look at debugcc and it shows mostly gcc clocks
<aka_[m]>
not rpmcc
<konradybcio>
rpm clocks are really just gcc clocks abstracted through the rpm core
<aka_[m]>
so you say device should become lagfest?
<aka_[m]>
back in time when i wired only single mdp endpoint i had part of screen going blue
<konradybcio>
well yeah, you're going to set all buses to "as slow as posibble, or even off if possible"
<konradybcio>
and iirc gcc was the only CC on 8976?
<aka_[m]>
yea
<konradybcio>
then yeah that's all
<aka_[m]>
i think before only 8974 ones had separate cc blocks
<aka_[m]>
konradybcio: out of wonder how do we even use this debugcc?
<aka_[m]>
it looks like binary to me
<konradybcio>
enable devmem, disable devmem strict, compile, run on device
<konradybcio>
it's a fancy mmio r/w wrapper
<aka_[m]>
ah so its binary
<aka_[m]>
i put on device and do make
<konradybcio>
yes
<aka_[m]>
konradybcio: I bet I seen kernel mode debugcc too
<konradybcio>
again, this is just register r/w, so it could be moved to kernel too
<konradybcio>
just that nobody has time to do it
<konradybcio>
and this works as is
<z3ntu>
Anyone got a clue why qcom_scm_pas_init_image might fail for wcnss on an old msm8226 htc-memul (when booting wcnss)? The scm call looks super standard, downstream also looks pretty similar
<z3ntu>
scm call args seem to be always: args[0]=0x6 args[1]=0x3e042000
<konradybcio>
memory region?
<konradybcio>
wcnss is very very picky iirc
<z3ntu>
this seems to be even before wcnss_region reserved-memory is used, the memory here is from dma_alloc_coherent
<z3ntu>
But in any case, downstream says "pil_pronto fb21b000.qcom,pronto: wcnss: loading from 0x0d200000 to 0x0d850000" and I have the same stuff reserved in mainline "OF: reserved mem: 0x0d200000..0x0d84ffff (6464 KiB) nomap non-reusable wcnss@d200000"
<z3ntu>
I don't really have an easy way to dump the scm args on downstream right now, so I can't say what exact args downstream uses - which would probably be useful
<konradybcio>
i hope htc hasn't pulled a sony
<konradybcio>
who requires some more magic to boot rprocs
<z3ntu>
ADSP and modem (pretty sure modem actually booted), so it's just wcnss making troubles right now
<konradybcio>
i suppose all of them would be beneficial
<aka_[m]>
konradybcio: arent we just interested in main pcnoc/snoc/bimc/snoc_mm clock?
<aka_[m]>
the "rpmcc clocks"
<aka_[m]>
or rpmcc just abstract it as single and it could be more
<konradybcio>
i mean, data doesn't hurt
<z3ntu>
konradybcio One weird thing I've also noticed about the wcnss firmware is that when you squash it with pil-squasher then "strings" doesn't seem to find the secure boot metadata anymore, so "HTC" and OEM_ID etc all disappear https://github.com/fairblobs/memul-firmware
<z3ntu>
this doesn't happen with the adsp firmware
<konradybcio>
maybe htc poked at the mbn format while at it.
<konradybcio>
would be helpful to know which set (active/sleep) fails
<aka_[m]>
konradybcio: it exist but different resource type
<aka_[m]>
you will see in patch
<konradybcio>
oh i see
<konradybcio>
i wonder if that's why sodp-4.4 had issues
<aka_[m]>
shouldn't
<z3ntu>
konradybcio At least running it back through pil-splitter again has some differences for some of the split files... namely wcnss.mdt missing the secure boot header, and also a bunch of bytes went missing from wcnss.b01
<aka_[m]>
noone changed pm file i think
<aka_[m]>
i booted 4.9 on leeco just to twrp
<aka_[m]>
getting 4.19 on 8976 sounds kinda trivial with 8937 being supported
<z3ntu>
So something a bit funky seems to be going in with the elf.. But downstream kernel driver seems super simple, read wcnss.mdt, copy it into the allocated memory region and call scm on it, so I can't imagine what's special there. Maybe mainline messes up somehow with some bytes...
<aka_[m]>
can add shit into clk-msm.c and even reuse boilerplate of apsscc driver
<aka_[m]>
konradybcio: so was that commit looking legit/should i rebase it
<konradybcio>
looks like
<aka_[m]>
on v2 Angelo was complaining
<aka_[m]>
konradybcio: well regarding this icc once i get display off it cannot really turn on
<aka_[m]>
right of the bat i don't see much issue in perf