ChanServ changed the topic of #linux-msm to:
djakov has joined #linux-msm
marvin24 has joined #linux-msm
marvin24_ has quit [Ping timeout: 480 seconds]
pespin has joined #linux-msm
pespin has quit []
pespin has joined #linux-msm
Danct12 has quit []
Danct12 has joined #linux-msm
<aka_[m]> lumag: regarding your comment on xo for 8976 this is way we do lately and I would love to not pollute board dts but sadly that's way someone made us do it
<aka_[m]> You can find it same way on sm6115/sm6375/sm8550
<aka_[m]> I remember it was said xo fixed crystal should not be in soc dts as it's board specific component and not soc part
<lumag> ah, that part
<lumag> ack.
* lumag hates this kind of duplication of standard items
<lumag> Then the whole xo_board and sleep_clk should go to the board dtsi. Because other boards might have it implemented in a different way, like using an external clock source, etc.
<bamse> lumag: except that it won't be implemented in different way between different boards...
<bamse> lumag: the xo_board i mean...
<bamse> lumag: someone might pick another vendor/part, but there's no much flexibility in the rate (which is the only aspect the dts covers)
<lumag> bamse, yep. It's that either the whole XO is fixed (including the rate), or the whole xo_board should go to soc-board.dtsi.
<lumag> Because one can imagine a board, using external source for the XO (especially if it's a networked SoC)
<bamse> lumag: to my knowledge it's fixed per soc
<lumag> bamse, to my knowledge too
<minecrell> lumag: related: I think the end result was that qru1000 has the xo-board & sleep-clk fully in the board DTS now, some SoCs have the clock-frequency in board DTS mess, and the older SoCs have the nodes fully in the SoC dtsi
<minecrell> so the usual inconsistent mess when conventions are not properly documented and people don't quite agree :S
<lumag> minecrell, as you probably see, I'd prefer to have xo-board & sleep in SoC.dtsi
<minecrell> lumag: I'm fine with that as well, but it seems like Krzysztof doesn't/didn't want that
<lumag> Yep
<lumag> minecrell, my second preference would be to have both clocks in board.dtsi
<lumag> but that's my 2c., so it is up to krzk and bamse
<krzk> yeah, I was pushing the frequency out of SoC DTSI (but not only me commented about this in the past:
<krzk> The clock is not part of SoC, it is external component, so it should be in the board. To avoid duplication - as it is common input to the SoC - my recommendation was to store almost everything in the SoC and only the frequency outside to indicate, that it has to be intentionally filled in (just like it has to be populated on the board).
<lumag> krzk, ack, it just seems strange to me to have the xo_board in the dtsi then. But I would not argue here, you definitely know more (and can estimate if it's good or not).
<lumag> Excuse me for grumbling :D
pespin has quit [Remote host closed the connection]
pespin has joined #linux-msm
pespin has quit [Remote host closed the connection]
pespin has joined #linux-msm
<bamse> lumag: to make it more fun... sleep_clk is just a clock coming out of one of the pmics...
<lumag> bamse, I think it's typical
<lumag> I saw that on other boards too.
<lumag> do you propose to move sleep_clk to be a child of the rpmcc/rpmhcc?
<bamse> lumag: i think it's apq8060 or something where it's an actual clock, everything newer derrives it from xo_board
<lumag> It don't think it derives from xo. It would quite defeat a purpose
<lumag> At 32 kHz it well might be an RC thing
<bamse> hmm, you might be right
<bamse> but i don't think xo is turned off ever
<bamse> it's been so long since i looked at that though...i don't remember the exact details
<lumag> I don't think I have 8060 schematics. At apq8964 sleep_clk comes from pmm8920
<lumag> apq8064 ofc
<konradybcio> if you plug in an lte modem it's effectively apq8964 ;)