[v1,1/4] clk: qcom: smd: Add XO clock for MSM8998
diff mbox series

Message ID 1548866144-30265-1-git-send-email-jhugo@codeaurora.org
State Superseded
Headers show
Series
  • MSM8998 Multimedia Clock Controller
Related show

Commit Message

Jeffrey Hugo Jan. 30, 2019, 4:35 p.m. UTC
The XO clock generally feeds into other clock controllers as the parent
for a lot of clock generators.

Fixes: 6131dc81211c (clk: qcom: smd: Add support for MSM8998 rpm clocks)
Signed-off-by: Jeffrey Hugo <jhugo@codeaurora.org>
---
 drivers/clk/qcom/clk-smd-rpm.c | 4 ++++
 1 file changed, 4 insertions(+)

Comments

Stephen Boyd Feb. 5, 2019, 10:01 p.m. UTC | #1
Quoting Jeffrey Hugo (2019-01-30 08:35:44)
> The XO clock generally feeds into other clock controllers as the parent
> for a lot of clock generators.
> 
> Fixes: 6131dc81211c (clk: qcom: smd: Add support for MSM8998 rpm clocks)
> Signed-off-by: Jeffrey Hugo <jhugo@codeaurora.org>

We've historically left out the XO clk because it causes problems where
the XO vote goes away during late init because nobody references it from
the rest of the clk tree and also because RPM defers probe of the system
and then the console blows up when it gets a clk that can't change rate.
See commit 54823af9cd52 ("clk: qcom: Always add factor clock for xo
clocks") for some more info on why we removed all the workarounds and
stuff around here too.

So are you sure this is OK to do?
Jeffrey Hugo Feb. 5, 2019, 10:15 p.m. UTC | #2
On 2/5/2019 3:01 PM, Stephen Boyd wrote:
> Quoting Jeffrey Hugo (2019-01-30 08:35:44)
>> The XO clock generally feeds into other clock controllers as the parent
>> for a lot of clock generators.
>>
>> Fixes: 6131dc81211c (clk: qcom: smd: Add support for MSM8998 rpm clocks)
>> Signed-off-by: Jeffrey Hugo <jhugo@codeaurora.org>
> 
> We've historically left out the XO clk because it causes problems where
> the XO vote goes away during late init because nobody references it from
> the rest of the clk tree and also because RPM defers probe of the system
> and then the console blows up when it gets a clk that can't change rate.
> See commit 54823af9cd52 ("clk: qcom: Always add factor clock for xo
> clocks") for some more info on why we removed all the workarounds and
> stuff around here too.
> 
> So are you sure this is OK to do?
>   
> 

So, I've got pretty much everything as modules, and I haven't seen any 
issues.  However let me take a look at the commit you point out and see.
Stephen Boyd Feb. 5, 2019, 10:32 p.m. UTC | #3
Quoting Jeffrey Hugo (2019-02-05 14:15:16)
> On 2/5/2019 3:01 PM, Stephen Boyd wrote:
> > Quoting Jeffrey Hugo (2019-01-30 08:35:44)
> >> The XO clock generally feeds into other clock controllers as the parent
> >> for a lot of clock generators.
> >>
> >> Fixes: 6131dc81211c (clk: qcom: smd: Add support for MSM8998 rpm clocks)
> >> Signed-off-by: Jeffrey Hugo <jhugo@codeaurora.org>
> > 
> > We've historically left out the XO clk because it causes problems where
> > the XO vote goes away during late init because nobody references it from
> > the rest of the clk tree and also because RPM defers probe of the system
> > and then the console blows up when it gets a clk that can't change rate.
> > See commit 54823af9cd52 ("clk: qcom: Always add factor clock for xo
> > clocks") for some more info on why we removed all the workarounds and
> > stuff around here too.
> > 
> > So are you sure this is OK to do?
> >   
> > 
> 
> So, I've got pretty much everything as modules, and I haven't seen any 
> issues.  However let me take a look at the commit you point out and see.
> 

Is the name of the clk "xo_clk_src"? That isn't the name that we were
expecting the XO clk from RPM to be called. You might have to look back
at the history of the rpm clk driver on the list and see when Georgi
dropped the XO clk from it and if there was anything wrong with that. I
can't recall if this was discussed on the list or if he just told me in
some hallway conversation at Connect.
Jeffrey Hugo Feb. 5, 2019, 10:37 p.m. UTC | #4
On 2/5/2019 3:32 PM, Stephen Boyd wrote:
> Quoting Jeffrey Hugo (2019-02-05 14:15:16)
>> On 2/5/2019 3:01 PM, Stephen Boyd wrote:
>>> Quoting Jeffrey Hugo (2019-01-30 08:35:44)
>>>> The XO clock generally feeds into other clock controllers as the parent
>>>> for a lot of clock generators.
>>>>
>>>> Fixes: 6131dc81211c (clk: qcom: smd: Add support for MSM8998 rpm clocks)
>>>> Signed-off-by: Jeffrey Hugo <jhugo@codeaurora.org>
>>>
>>> We've historically left out the XO clk because it causes problems where
>>> the XO vote goes away during late init because nobody references it from
>>> the rest of the clk tree and also because RPM defers probe of the system
>>> and then the console blows up when it gets a clk that can't change rate.
>>> See commit 54823af9cd52 ("clk: qcom: Always add factor clock for xo
>>> clocks") for some more info on why we removed all the workarounds and
>>> stuff around here too.
>>>
>>> So are you sure this is OK to do?
>>>    
>>>
>>
>> So, I've got pretty much everything as modules, and I haven't seen any
>> issues.  However let me take a look at the commit you point out and see.
>>
> 
> Is the name of the clk "xo_clk_src"? That isn't the name that we were
> expecting the XO clk from RPM to be called. You might have to look back
> at the history of the rpm clk driver on the list and see when Georgi
> dropped the XO clk from it and if there was anything wrong with that. I
> can't recall if this was discussed on the list or if he just told me in
> some hallway conversation at Connect.
> 

Will do.  Thanks for pointing out the history.
Georgi Djakov Feb. 6, 2019, 1:55 p.m. UTC | #5
Hi Jeffrey,

On 2/6/19 00:32, Stephen Boyd wrote:
> Quoting Jeffrey Hugo (2019-02-05 14:15:16)
>> On 2/5/2019 3:01 PM, Stephen Boyd wrote:
>>> Quoting Jeffrey Hugo (2019-01-30 08:35:44)
>>>> The XO clock generally feeds into other clock controllers as the parent
>>>> for a lot of clock generators.
>>>>
>>>> Fixes: 6131dc81211c (clk: qcom: smd: Add support for MSM8998 rpm clocks)
>>>> Signed-off-by: Jeffrey Hugo <jhugo@codeaurora.org>
>>>
>>> We've historically left out the XO clk because it causes problems where
>>> the XO vote goes away during late init because nobody references it from
>>> the rest of the clk tree and also because RPM defers probe of the system
>>> and then the console blows up when it gets a clk that can't change rate.
>>> See commit 54823af9cd52 ("clk: qcom: Always add factor clock for xo
>>> clocks") for some more info on why we removed all the workarounds and
>>> stuff around here too.
>>>
>>> So are you sure this is OK to do?
>>>   
>>>
>>
>> So, I've got pretty much everything as modules, and I haven't seen any 
>> issues.  However let me take a look at the commit you point out and see.
>>
> 
> Is the name of the clk "xo_clk_src"? That isn't the name that we were
> expecting the XO clk from RPM to be called. You might have to look back
> at the history of the rpm clk driver on the list and see when Georgi
> dropped the XO clk from it and if there was anything wrong with that. I
> can't recall if this was discussed on the list or if he just told me in
> some hallway conversation at Connect.

The problem back then was the following: The RPM clock driver has
various dependencies on other drivers (hwspinlock, smem, smd, rpmsg etc)
and may probe defer multiple times during boot. Meanwhile the GCC clocks
are registered as orphans, as their parent clock (RPM XO) is not there
yet. And when some driver calls clk_get_rate() on an orphan clock, a
bogus rate is returned. The consequence of this was that the serial
console was broken, because of the baud rate being calculated based on
this bogus clock rate.

Thanks,
Georgi
Jeffrey Hugo Feb. 6, 2019, 5:04 p.m. UTC | #6
On 2/6/2019 6:55 AM, Georgi Djakov wrote:
> Hi Jeffrey,
> 
> On 2/6/19 00:32, Stephen Boyd wrote:
>> Quoting Jeffrey Hugo (2019-02-05 14:15:16)
>>> On 2/5/2019 3:01 PM, Stephen Boyd wrote:
>>>> Quoting Jeffrey Hugo (2019-01-30 08:35:44)
>>>>> The XO clock generally feeds into other clock controllers as the parent
>>>>> for a lot of clock generators.
>>>>>
>>>>> Fixes: 6131dc81211c (clk: qcom: smd: Add support for MSM8998 rpm clocks)
>>>>> Signed-off-by: Jeffrey Hugo <jhugo@codeaurora.org>
>>>>
>>>> We've historically left out the XO clk because it causes problems where
>>>> the XO vote goes away during late init because nobody references it from
>>>> the rest of the clk tree and also because RPM defers probe of the system
>>>> and then the console blows up when it gets a clk that can't change rate.
>>>> See commit 54823af9cd52 ("clk: qcom: Always add factor clock for xo
>>>> clocks") for some more info on why we removed all the workarounds and
>>>> stuff around here too.
>>>>
>>>> So are you sure this is OK to do?
>>>>    
>>>>
>>>
>>> So, I've got pretty much everything as modules, and I haven't seen any
>>> issues.  However let me take a look at the commit you point out and see.
>>>
>>
>> Is the name of the clk "xo_clk_src"? That isn't the name that we were
>> expecting the XO clk from RPM to be called. You might have to look back
>> at the history of the rpm clk driver on the list and see when Georgi
>> dropped the XO clk from it and if there was anything wrong with that. I
>> can't recall if this was discussed on the list or if he just told me in
>> some hallway conversation at Connect.
> 
> The problem back then was the following: The RPM clock driver has
> various dependencies on other drivers (hwspinlock, smem, smd, rpmsg etc)
> and may probe defer multiple times during boot. Meanwhile the GCC clocks
> are registered as orphans, as their parent clock (RPM XO) is not there
> yet. And when some driver calls clk_get_rate() on an orphan clock, a
> bogus rate is returned. The consequence of this was that the serial
> console was broken, because of the baud rate being calculated based on
> this bogus clock rate.

Ok.  As far as I am aware, that issue still basically exists but I don't 
seem to be hitting it.  I suspect timing.  However, it seems like the 
key point is that GCC is initing, doesn't have its dependencies in 
place, but is allowing client activity anyways.  It seems like either 1) 
GCC should detect XO isn't present (yet), and probe defer or 2) clocks 
are somehow not usable if the parent hasn't appeared yet (maybe such 
parents are marked as critical somehow?)

Stephen, what are your thoughts?

Patch
diff mbox series

diff --git a/drivers/clk/qcom/clk-smd-rpm.c b/drivers/clk/qcom/clk-smd-rpm.c
index 22dd42a..5b1d718 100644
--- a/drivers/clk/qcom/clk-smd-rpm.c
+++ b/drivers/clk/qcom/clk-smd-rpm.c
@@ -656,6 +656,8 @@  static int clk_smd_rpm_enable_scaling(struct qcom_smd_rpm *rpm)
 };
 
 /* msm8998 */
+DEFINE_CLK_SMD_RPM_BRANCH(msm8998, xo_clk_src, xo_a_clk_src,
+			  QCOM_SMD_RPM_MISC_CLK, 0, 19200000);
 DEFINE_CLK_SMD_RPM(msm8998, snoc_clk, snoc_a_clk, QCOM_SMD_RPM_BUS_CLK, 1);
 DEFINE_CLK_SMD_RPM(msm8998, cnoc_clk, cnoc_a_clk, QCOM_SMD_RPM_BUS_CLK, 2);
 DEFINE_CLK_SMD_RPM(msm8998, ce1_clk, ce1_a_clk, QCOM_SMD_RPM_CE_CLK, 0);
@@ -678,6 +680,8 @@  static int clk_smd_rpm_enable_scaling(struct qcom_smd_rpm *rpm)
 DEFINE_CLK_SMD_RPM_XO_BUFFER(msm8998, rf_clk3, rf_clk3_a, 6);
 DEFINE_CLK_SMD_RPM_XO_BUFFER_PINCTRL(msm8998, rf_clk3_pin, rf_clk3_a_pin, 6);
 static struct clk_smd_rpm *msm8998_clks[] = {
+	[RPM_SMD_XO_CLK_SRC] = &msm8998_xo_clk_src,
+	[RPM_SMD_XO_A_CLK_SRC] = &msm8998_xo_a_clk_src,
 	[RPM_SMD_SNOC_CLK] = &msm8998_snoc_clk,
 	[RPM_SMD_SNOC_A_CLK] = &msm8998_snoc_a_clk,
 	[RPM_SMD_CNOC_CLK] = &msm8998_cnoc_clk,