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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <b7343ea6-7194-e709-8fed-4a1a17f7beb5@linaro.org>
Date:   Thu, 26 Jan 2023 16:32:17 +0000
From:   Bryan O'Donoghue <bryan.odonoghue@...aro.org>
To:     Konrad Dybcio <konrad.dybcio@...aro.org>,
        Stephan Gerhold <stephan@...hold.net>
Cc:     agross@...nel.org, andersson@...nel.org, djakov@...nel.org,
        robh+dt@...nel.org, krzysztof.kozlowski+dt@...aro.org,
        linux-arm-msm@...r.kernel.org, linux-pm@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        benl@...areup.com, shawn.guo@...aro.org, fabien.parent@...aro.org,
        leo.yan@...aro.org, dmitry.baryshkov@...aro.org
Subject: Re: [PATCH v4 0/6] Add MSM8939 SoC support with two devices

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