<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