ChanServ changed the topic of #linux-msm to:
<bryanodonoghue> aka_[m] i wonder if the TPG has received that kind of extensive testing on vfe 480
<bryanodonoghue> this might not be a problem specific to you at all
<bryanodonoghue> I'll test it on sm8250 tomorrow and see if I get the same result
marvin24_ has joined #linux-msm
marvin24 has quit [Ping timeout: 480 seconds]
DavidHeidelberg has quit [Remote host closed the connection]
DavidHeidelberg has joined #linux-msm
jhovold has joined #linux-msm
flto has quit [Ping timeout: 480 seconds]
mripard has joined #linux-msm
flto has joined #linux-msm
ungeskriptet has quit [Quit: The Lounge - https://thelounge.chat]
ungeskriptet has joined #linux-msm
ungeskriptet has quit [Quit: The Lounge - https://thelounge.chat]
ungeskriptet has joined #linux-msm
wfranken[m] has quit [reticulum.oftc.net helix.oftc.net]
mal has quit [reticulum.oftc.net helix.oftc.net]
danylo1 has quit [reticulum.oftc.net helix.oftc.net]
valentine has quit [reticulum.oftc.net helix.oftc.net]
JIaxyga[m] has quit [reticulum.oftc.net helix.oftc.net]
Adrian[m] has quit [reticulum.oftc.net helix.oftc.net]
FieryFlames[m] has quit [reticulum.oftc.net helix.oftc.net]
Newbyte has quit [reticulum.oftc.net helix.oftc.net]
mal has joined #linux-msm
danylo1 has joined #linux-msm
wfranken[m] has joined #linux-msm
valentine has joined #linux-msm
Newbyte has joined #linux-msm
Adrian[m] has joined #linux-msm
JIaxyga[m] has joined #linux-msm
FieryFlames[m] has joined #linux-msm
anuw[m] has quit [Ping timeout: 481 seconds]
Tooniis[m] has quit [Ping timeout: 480 seconds]
DylanVanAssche has quit [Ping timeout: 480 seconds]
nta has quit [Ping timeout: 480 seconds]
z3ntu has quit [Ping timeout: 480 seconds]
Marijn[m] has quit [Ping timeout: 485 seconds]
strongtz[m] has quit [Ping timeout: 480 seconds]
aka_[m] has quit [Ping timeout: 480 seconds]
travmurav[m] has quit [Ping timeout: 480 seconds]
konradybcio has quit [Ping timeout: 480 seconds]
flamingradian[m] has quit [Ping timeout: 480 seconds]
danylo1 has quit [Ping timeout: 607 seconds]
FieryFlames[m] has quit [Ping timeout: 607 seconds]
<marc|gonzalez> bryanodonoghue: did you see anything useful in the venus debug output dump?
wfranken[m] has quit [Read error: Connection reset by peer]
JIaxyga[m] has quit [Write error: connection closed]
Adrian[m] has quit [Remote host closed the connection]
valentine has quit [Remote host closed the connection]
Newbyte has quit [Remote host closed the connection]
AntoniAloyTorrens[m]1 has joined #linux-msm
dliviu has quit [Quit: Going away]
dliviu has joined #linux-msm
<marc|gonzalez> bryanodonoghue: I didn't understand your latest email.
<bryanodonoghue> the video ahb clock should probably be always-on
<bryanodonoghue> venus ahb clock
<marc|gonzalez> That means setting a specific flag somewhere?
<bryanodonoghue> .flags = CLK_SET_RATE_PARENT | CLK_IS_CRITICAL,
<bryanodonoghue> but for preference we'd remove the AHB clock description
<bryanodonoghue> and write the always-on bit per the email
<marc|gonzalez> Are you going to send a patch for the sm8250?
<bryanodonoghue> no that's already upstream
<marc|gonzalez> oooh, you meant "you can look at sm8250 to do the same for 8998" now I get it.
<marc|gonzalez> I will be brutally honest: my experience sending short patches has been awful, and I hesitate even to send one-liners.
<bryanodonoghue> meh fuck the begrudgers marc|gonzalez
f_ has joined #linux-msm
<arnd> bamse: you sent multiple patches that mark DT nodes as dma-coherent for 6.10. Are you sure those shouldn't be in v6.9 as well? I would expect that a missing dma-coherent annotation causes data corruption when data gets put into the cache but gets flushed by the CPU
<arnd> mani_s: I'm confused by all your "arm64: dts: qcom: xxx: Add PCIe bridge node" patches. What issue does this address?
<arnd> I would expect that any PCIe controller has a bridge behind it and that we probe that automatically
<mani_s> arnd, We need to model PCI bridges for multiple reasons:
<mani_s> arnd, 1. Bridge specific properties are going to be added in the future. Like PERST#, WAKE# etc.. currently these are added in controller node, but that's not correct
<mani_s> arnd, 2. We need bridge to add child nodes. Like when we use the ongoing 'power sequencing' series
<arnd> right, that makes more sense then. I was mainly confused because you don't add any properties or children that make any difference at the moment
<arnd> thanks
<mani_s> arnd, np. I mentioned it in the cover letter, but that got missed
<marc|gonzalez> bryanodonoghue: did you have a chance to look at the venus debug output? Did you see anything useful?
f_ has quit [Ping timeout: 480 seconds]
jhovold has quit [Ping timeout: 480 seconds]
<bryanodonoghue> marcgonzalez honestly you should ask dikshita - maybe ping her direclty
<bryanodonoghue> she can probably tell you straight out or even read the fw sources if not