Message-ID: <ff3aebd7-2932-fd9f-3e82-fe123b770a87@linaro.org>
Date:   Thu, 26 Jan 2023 16:45:41 +0000
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.5.0
Subject: Re: [PATCH v4 0/6] Add MSM8939 SoC support with two devices
Content-Language: en-US
From:   Bryan O'Donoghue <bryan.odonoghue@linaro.org>
To:     Konrad Dybcio <konrad.dybcio@linaro.org>,
        Stephan Gerhold <stephan@gerhold.net>
Cc:     agross@kernel.org, andersson@kernel.org, djakov@kernel.org,
        robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org,
        linux-arm-msm@vger.kernel.org, linux-pm@vger.kernel.org,
        devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
        benl@squareup.com, shawn.guo@linaro.org, fabien.parent@linaro.org,
        leo.yan@linaro.org, dmitry.baryshkov@linaro.org
References: <20230123023127.1186619-1-bryan.odonoghue@linaro.org>
 <42baa874-c926-9111-b0b3-2df2562d8de6@linaro.org>
 <Y86CPmgvAi+kChQI@gerhold.net>
 <87192098-b7f4-060f-9274-933d974c0a7d@linaro.org>
 <df4c76eb-aec7-823e-28f9-5ba96cc200c6@linaro.org>
 <b7343ea6-7194-e709-8fed-4a1a17f7beb5@linaro.org>
In-Reply-To: <b7343ea6-7194-e709-8fed-4a1a17f7beb5@linaro.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 26/01/2023 16:32, Bryan O'Donoghue wrote:
> 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.

* If and only if you set P_DSI0_PHYPLL_BYTE::SRC_SEL = 0x01, using 
SRC_SEL = 0 (XO) or SRC_SEL = 0x02 (GPLL0_AUX) should negate the dependency.

I'll review downstream further - perhaps DSI1 in practice doesn't set 
P_DSI0_PHYPLL_BYTE as the source clock..

---
bod