ChanServ changed the topic of #linux-msm to:
djakov has quit [Remote host closed the connection]
djakov has joined #linux-msm
Daanct12 has joined #linux-msm
marvin24 has joined #linux-msm
marvin24_ has quit [Ping timeout: 480 seconds]
jhovold has joined #linux-msm
srinik has joined #linux-msm
ungeskriptet has quit [Quit: Contact links: https://david-w.eu]
srinik has quit [Remote host closed the connection]
srinik has joined #linux-msm
srinik has quit [Ping timeout: 480 seconds]
pg12_ has joined #linux-msm
pg12 has quit [Ping timeout: 480 seconds]
ungeskriptet has joined #linux-msm
pg12_ is now known as pg12
<lumag> djakov, is there any difference between sdm845-tbu and sc7280-tbu?
pespin has joined #linux-msm
pespin has quit []
pespin has joined #linux-msm
srinik has joined #linux-msm
marc|gonzalez has joined #linux-msm
<marc|gonzalez> lumag: it appears that a drm_connector is mandatory if I want to use the enable/disable functions?
Daanct12 has quit [Quit: WeeChat 4.3.2]
<DylanVanAssche> bamseYou did some work on the WCN3990 in the past right? I'm trying to bring up the SLIMBus controller linked to in downstream but the phone gets stuck in EDL mode. Watchdog timer seems to be triggered. Do you know if there are some clocks or stuff is not upstreamed in mainline yet?
<z3ntu> Dylan Van Assche: So right now you're just trying to get the slimbus controller on SoC side, nothing with wcn chip yet?
<DylanVanAssche> Luca WeissYes, there's a second SLIMBus controller downstream with a `btfm_slim` driver but that's not in mainline. I'm trying to bring up that SLIMBus controller. I don't have the `btfm_slim` driver yet.
<z3ntu> I'd imagine just the slimbus controller should be fine to enable without the otherside configured - sure you won't get audio data in and out but it shouldn't crash the device
<z3ntu> maybe some wrong registers are touched by the driver you try to use, while the register layout has changed for your SoC?
<DylanVanAssche> Same... I would expect that as well. This is what I have:
<DylanVanAssche> (need to rebase as I'm on a very old branch currently it seems, but the SLIMBus part is still the same in mainline)
<z3ntu> basically any crashing-to-EDL problem is wrong registers are being touched, clock or interconnect is not on, and maybe power domain not being on
<z3ntu> and of course iommu
<DylanVanAssche> Yeah I think it is some clock or interconnect because it is a timeout according to logs I pulled in EDL mode by dumping memory. If it was registers, it would be immediately after probing the driver. I fail to find out what I'm missing
<z3ntu> huh ok
<DylanVanAssche> I don't see anything in downstream DTS regarding clocks or interconnect with the SLIMBus controller which makes it hard to figure out.
<z3ntu> Dylan Van Assche: idk if it helps, the btfm slimbus is already upstream for sc7280.dtsi, maybe it can be a small reference?
<z3ntu> I can check at some point for sm6350 or msm8953, that's closer to sdm845 at least
<lumag> marc|gonzalez, please expand your question. I might be missing the context
<lumag> marc|gonzalez, it's totally fine to have a chain of bridges and then the drm_bridge_connector at its end
<marc|gonzalez> lumag: OK expanding question to provide more context
<marc|gonzalez> So I've been told that the GPIO powering the TDP158 must be toggled in the .enable & .disable callbacks of drm_bridge_funcs (actually, the atomic versions someone said)
<marc|gonzalez> In order for that to be called, I think it is mandatory to have an .attach callback
<marc|gonzalez> And that attach callback must call drm_bridge_attach and also init a connector & attach it to the encoder
<marc|gonzalez> at least this is my current understanding, as nothing works if I don't have all these steps
<marc|gonzalez> I just want to call gpiod_set_value_cansleep() but it looks like the framework expects several other things to be set up
<marc|gonzalez> Is my understanding correct?
<lumag> marc|gonzalez, please look at the aux-bridge or aux-hpd-bridge, those are two minimal examples.
<marc|gonzalez> thanks for the pointer
<lumag> marc|gonzalez, you'd need to use the same pattern and also add the .atomic_enable / .atomic_disable
<lumag> the connector and all the stuff is created by the host driver.
<marc|gonzalez> I think I did it like that and it doesn't work... I'll clean up my example, and post it to ask for comments :(
<lumag> marc|gonzalez, sounds good
<lumag> you can check how your bridges are stacked by consulting /sys/kernel/debug/dri/0/encoder-0/bridges (replace -0 with -1, -2, etc for each encoder)
<marc|gonzalez> Thanks. I had a printk in drm_bridge_attach that probably gave me similar info
<DylanVanAssche> Luca WeissWhere do you see it in sc7280.dtsi? I only see 1 SLIMBus controller and nothing that matches 'btfm'
norris has quit [Ping timeout: 480 seconds]
SanchayanMaity__ has quit [Ping timeout: 480 seconds]
mka has quit [Ping timeout: 480 seconds]
sskras has quit [Ping timeout: 480 seconds]
linusw_ has quit [Ping timeout: 480 seconds]
elder has quit [Ping timeout: 480 seconds]
steev has quit [Ping timeout: 480 seconds]
pundir has quit [Ping timeout: 480 seconds]
ldts has quit [Ping timeout: 480 seconds]
agross has quit [Ping timeout: 480 seconds]
CosmicPenguin has quit [Ping timeout: 480 seconds]
arnd has quit [Ping timeout: 480 seconds]
ytrio has quit [Ping timeout: 480 seconds]
roxell has quit [Ping timeout: 480 seconds]
dianders has quit [Ping timeout: 480 seconds]
jstultz has quit [Ping timeout: 480 seconds]
robher has quit [Ping timeout: 480 seconds]
qyousef has quit [Ping timeout: 480 seconds]
narmstrong has quit [Ping timeout: 480 seconds]
cwabbott has quit [Ping timeout: 480 seconds]
sboyd has quit [Ping timeout: 480 seconds]
kido has quit [Ping timeout: 480 seconds]
ndec has quit [Ping timeout: 480 seconds]
jbg has quit [Ping timeout: 480 seconds]
robclark has quit [Ping timeout: 480 seconds]
pac85 has quit [Ping timeout: 480 seconds]
jhugo has quit [Ping timeout: 480 seconds]
hfink has quit [Ping timeout: 480 seconds]
<z3ntu> Dylan Van Assche: it's that one, slimbus is only used for bt/fm on that SoC afaik
narmstrong has joined #linux-msm
pac85 has joined #linux-msm
CosmicPenguin has joined #linux-msm
kido has joined #linux-msm
linusw_ has joined #linux-msm
robclark has joined #linux-msm
jhugo has joined #linux-msm
cwabbott has joined #linux-msm
<DylanVanAssche> Luca Weiss: But there is no specific bluetooth slimbus driver?
arnd has joined #linux-msm
steev has joined #linux-msm
jstultz has joined #linux-msm
<z3ntu> no just the slimbus part was added so far it seems, not that "Slimbus Slave DT for QCA6490"
ldts has joined #linux-msm
ytrio has joined #linux-msm
qyousef has joined #linux-msm
ndec has joined #linux-msm
<DylanVanAssche> Ah okay... I will have a look after dayjob
mka has joined #linux-msm
dianders has joined #linux-msm
agross has joined #linux-msm
sboyd has joined #linux-msm
elder has joined #linux-msm
hfink has joined #linux-msm
pundir has joined #linux-msm
jbg has joined #linux-msm
sskras has joined #linux-msm
norris has joined #linux-msm
SanchayanMaity__ has joined #linux-msm
roxell has joined #linux-msm
robher has joined #linux-msm
<DylanVanAssche> Ah seems that somebody already asked for Bluetooth FM enablement but no response: https://lkml.org/lkml/2024/2/26/1425
<marc|gonzalez> lumag: does devm_regulator_get() never fail...? I just get "tdp158-bridge 2-005e: supply vcc not found, using dummy regulator"
<lumag> marc|gonzalez, yep, that's expected
<marc|gonzalez> So no point in testing for failure then!
<lumag> It fails if there is a real mistake, like pointing to a non-regulator device
<lumag> But if it's missing, a dummy will be substituted
<lumag> so testing for failure is still mandatory
<marc|gonzalez> understood
<marc|gonzalez> lumag: .enable works, but .atomic_enable doesn't : it fails in WARNING: CPU: 0 PID: 45 at drivers/gpu/drm/drm_bridge.c:864 drm_atomic_bridge_chain_enable+0xac/0xc8
<marc|gonzalez> WARN_ON(!old_bridge_state)
<lumag> marc|gonzalez, did you enable state-related hooks?
<marc|gonzalez> Is the driver supposed to do something about bridge states
<marc|gonzalez> I only s/enable/atomic_enable :)
<lumag> .atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
<lumag> .atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
<lumag> .atomic_reset = drm_atomic_helper_bridge_reset,
<marc|gonzalez> Wow, thanks
<djakov> lumag: from a hardware POV they should be the same, register layouts are compatible etc.
<lumag> djakov, ack, thanks!
<djakov> some of the newer SoCs have another version of TBUs, called QTB, that are different..
<djakov> i have some patches to support QTBs as well, but need to catch up with other things first
<lumag> djakov, I think it would be nice to limit the compatibles in the driver. If a chip is compatible with sdm845, we can have compatible = "qcom,sc7180-tbu", "qcom,sdm845-tbu";
minecrell75 has joined #linux-msm
minecrell7 has quit []
minecrell754 has joined #linux-msm
<djakov> lumag, Yes, right. This can save a line in the of_device_id struct... It can be added later only if needed i guess. But if we list both compatibles in DT, then we should document them both anyway.
<lumag> djakov, document in bindings, yes
<djakov> ack, thanks!
minecrell75 has quit [Ping timeout: 480 seconds]
srinik has quit [Ping timeout: 480 seconds]
pespin has quit [Remote host closed the connection]
dliviu has quit [Quit: Going away]
dliviu has joined #linux-msm