srinik has quit [Killed (NickServ (Too many failed password attempts.))]
srinik has joined #linux-msm
<z3ntu>
I'm trying to get bluetooth working on sm7225-fairphone-fp4 that's using wcn3988. With the pwrseq patches I can get bluetooth somewhat up and e.g. make it discoverable (which does work!). But trying "scan on" in bluetoothctl results in "[ 92.737688] Bluetooth: hci0: Opcode 0x200b failed: -16"
<z3ntu>
Does anybody have any insight in what this might be caused by and how to fix it? The opcode 0x200b is HCI_OP_LE_SET_SCAN_PARAM
<lumag>
z3ntu, are you using the firmware from linux-firmware or from your phone? There were reports (e.g. for axolotl) that firmware from l-f doesn't work
<z3ntu>
I'm using apbtfw11.tlv + apnv11.bin from stock image
<lumag>
z3ntu, in this case, can you try using the l-f version?
<z3ntu>
firmware with that filename isn't part of linux-firmware it seems
<z3ntu>
lumag: downstream calls this chip APACHE_VER_1_2_1 , and it has the build number (or whatever it's called) BTFM.CHE.2.1.5-00291-QCACHROMZ-1
<lumag>
z3ntu, just to doublecheck. Are we talking about 3998 or 3988 ?
<z3ntu>
lumag: pretty sure it's WCN3988 (although downstream kernel calls it WCN3990 but that doesn't really do much, and probably just compatible on downstream-kernel-level)
<mal>
z3ntu: although it seems you have different error code
<z3ntu>
mal: I think it's a completely different problem, for me stuff does work except for "scan on" in bluetoothctl (and possibly other stuff I couldn't/didn't test yet)
<mal>
yeah
<abhinav__>
Marijn[m] what is INTF-PP support? PP split?
<Marijn[m]>
abhinav__: `DPU_INTF_TE`
<Marijn[m]>
Someone talked INTF-PP into me, but it's the move of the TE registers/"subblock" from the PP to the INTF block
<Marijn[m]>
On at least sm6350 the proof-of-concept I have at least makes the `sync_cfg_height` go again, but we're still figuring out why the TE channel from our panel isn't reaching into MDP.
<Marijn[m]>
* The proof-of-concept I have makes `sync_cfg_height` go again on sm6350, but we're still figuring out why the TE channel from our panel isn't reaching into MDP.
<abhinav__>
Marijn[m] you mean you want to make it wrap around right?
<Marijn[m]>
abhinav__: What do you mean with "wrap around"?
<Marijn[m]>
I want to implement support for it because our command mode panels don't work on these SoCs
<abhinav__>
typically, when the tear check block received the TE from the panel, the pointer resets to init_val. i am guessing that you are not receiving TE from the panel, so you want the pointer to wrap around by changing the sync_cfg_height
<abhinav__>
so when you say "go again" i thought you meant wraps around to go again
<Marijn[m]>
abhinav__: I don't have a hardware manual so it's only guessing what it does for me. With "go again" I meant that panel display "starts working" again, prior to that vsync would only time out. Indeed, it seems the TE from the panel is not received by the hardware and in turn not triggering the RDPTR in the DPU driver (and not wrapping around), so we use `sync_cfg_height = vtotal * 2` to run at half the framerate.
<Marijn[m]>
abhinav__: I did however register an interrupt handler for our TE pin, and it's firing a lot. Perhaps I'm missing some configuration on the PP or INTF TE registers, but all I can do is compare to downstream.
<Marijn[m]>
abhinav__: If you have documentation available on how the pointer, init_val, and wraparound reset works, I'd love to read it!
<Marijn[m]>
abhinav__: in fact any documentation (or best-practices) on DPU hardware would be appreciated...
<abhinav__>
Marijn[m] i need to check if there is something available which is also shareable .... if i find something i will share it.
<abhinav__>
from your comments, it does seem to me that the TE block seems misconfigured
<Marijn[m]>
abhinav__: thanks! All the registers are identical to what I dumped on downstream though; maybe there are registers elsewhere that I haven't compared yet that could be different. I haven't dumped and diffed the entire mmio range yet; given that it's in debugfs it might've been useful to someone but I'm afraid it has a terrible signal to noise ratio