Re: [PATCH v4 0/6] Add MSM8939 SoC support with two devices

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 26/01/2023 15:34, Konrad Dybcio wrote:
To me this looks like a confirmation of what downstream does, that both
DSI byte clocks are actually sourced from the dsi0_phy and the PLL of
A better name would have been dsiX_phy_pll_out_byteclk.
I believe Stephan is just confused what the clock source of both
pairs of GCC DSI clocks are, as you're suggesting that:

phy_clock0
   |_gcc_clock0

and

phy_clock0 (yes, zero)
   |_gcc_clock1

whereas on most other SoCs the following is true:

phy_clock0
   |_gcc_clock0

phy_clock1
   |_gcc_clock_1

Konrad

The only input clock to GCC is XO or buffered CXO if routed through the PMIC.

You can select via GCC::RCGR where dsiX_phy_pll_out_byteclk is *sourced* from XO, GPLL0_AUX or P_DSI0_PHYPLL_BYTE.

So, obvs the byte clock can be any one of those input sources.

But the question is, if you select dsi0_phy_pll_out_byteclk - what provides it ?

Reviewing the LK bootloader for 3.18, it *looks* to me like the dsi0 pll is always switched on. The downstream kernel tree doesn't represent that.

0x01A9811C MDSS_DSI_0_CLK_CTRL
Type: RW
Reset State: 0x00000000 -> BIT(4) -> Turns on/off BYTECLK for the DSI. If set to 1, clock is ON.

Hmm. I think actually it must be the case that DSI1 is a slave of DSI0.

You can have both interfaces running or just DSI0 on its own.

Hmm, I'll change it.

---
bod



[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux