Re: [PATCH v2] clk: qcom: smd: Add support for MSM8998 rpm clocks

[Jeffrey Hugo <jhugo@codeaurora.org>]

On 12/7/2018 8:13 AM, Jeffrey Hugo wrote:
> On 12/7/2018 7:23 AM, Marc Gonzalez wrote:
>> On 06/12/2018 23:11, Jeffrey Hugo wrote:
>>
>>> Add rpm smd clocks, PMIC and bus clocks which are required on MSM8998
>>> for clients to vote on.
>>>
>>> Signed-off-by: Jeffrey Hugo <jhugo@codeaurora.org>
>>> ---
>>> v2
>>> -fix compatible ordering nits per Stephen
>>>
>>>   .../devicetree/bindings/clock/qcom,rpmcc.txt       |  1 +
>>>   drivers/clk/qcom/clk-smd-rpm.c                     | 62 
>>> ++++++++++++++++++++++
>>>   include/dt-bindings/clock/qcom,rpmcc.h             |  6 +++
>>>   3 files changed, 69 insertions(+)
>>
>> Hmmm, my board seems to dislike this patch... it locks up for a while,
>> then reboots.
>>
>> [    6.957289] ufshcd-qcom 1da4000.ufshc: ufshcd_query_flag: Sending 
>> flag query for idn 1 failed, err = -11
>> [    6.961233] ufshcd-qcom 1da4000.ufshc: ufshcd_query_flag_retry: 
>> failed with error -11, retries 2
>> [    6.970782] ufshcd-qcom 1da4000.ufshc: ufshcd_query_flag_retry: 
>> query attribute, opcode 6, idn 1, failed with error -11 after 3 retires
>> [    6.979576] ufshcd-qcom 1da4000.ufshc: ufshcd_complete_dev_init 
>> setting fDeviceInit flag failed with error -11
>> [   23.432798] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
>> [   23.432884] rcu:     7-...0: (1 GPs behind) 
>> idle=6a2/1/0x4000000000000000 softirq=92/93 fqs=2626
>> [   23.437927] rcu:     (detected by 0, t=5252 jiffies, g=-819, q=112)
>> [   23.446425] Task dump for CPU 7:
>> [   23.452567] swapper/0       R  running task        0     1      0 
>> 0x0000002a
>> [   23.455806] Call trace:
>> [   23.462872]  __switch_to+0x94/0xe0
>> [   23.465009]  _regmap_write+0x58/0xb0
>> [   23.468452]  _regmap_update_bits+0xf0/0x110
>> [   23.472186]  regmap_update_bits_base+0x60/0x90
>> [   23.476110]  clk_disable_regmap+0x34/0x40
>> [   23.480614]  clk_branch_toggle+0x108/0x1b0
>> [   23.484681]  clk_branch2_disable+0x18/0x20
>> [   23.488692]  clk_disable_unused_subtree+0xc4/0xe0
>> [   23.492761]  clk_disable_unused+0x3c/0x130
>> [   23.497535]  do_one_initcall+0x5c/0x180
>> [   23.501557]  kernel_init_freeable+0x198/0x244
>> [   23.505276]  kernel_init+0x10/0x110
>> [   23.509768]  ret_from_fork+0x10/0x20
>>
>> /*** REBOOT ***/
>> Format: Log Type - Time(microsec) - Message - Optional Info
>> Log Type: B - Since Boot(Power On Reset),  D - Delta,  S - Statistic
>>
>> I need to check the ufs_reset pin and phy init seq before I can 
>> investigate
>> this issue, but I wanted to send a report ASAP.
>>
> 
> Hmm.  I run with clk_ignore_unused.  I'm guessing that something was 
> defined that should be used eventually, but isn't used now, and so its 
> getting turned off when it probably shouldn't be.
> 
> I'll try to repro on my end.
> 

I think I figured this out.

The issue appears to be with the mmssnoc_axi_rpm_clk that this patch 
defines.  Removing that, and I do not observe a crash.  This clock will 
eventually be needed for the multimedia subsystem (camera and the like).

Marc, it would be good if you could comment out this clock to verify my 
observations translate to your setup.

The problem occurs when the rpm driver, during probe, sends the active 
settings to the rpm.  This causes the rpm to try to access the mmss over 
the relevant config noc, and results in an unclocked bus error, which is 
a fatal error.

clk_ignore_unused avoids this issue because it leaves on the config noc 
clock defined in gcc - gcc_mmss_noc_cfg_ahb_clk

I can see 3 workarounds to this issue -

1. comment out mmssnoc_axi_rpm_clk with an explanation to why, and leave 
this problem to whomever needs the clock in the future

2. add the CLK_IGNORE_UNUSED flag to gcc_mmss_noc_cfg_ahb_clk so prevent 
it from being disabled (aka a selective version of clk_ignore_unused)

3. add a prepare_enable call to gcc_mmss_noc_cfg_ahb_clk in the gcc 
probe, so that there is always one active consumer of the clock (this is 
what downstream does)

Stephen, do you have a preference, or an alternative suggestion?

-- 
Jeffrey Hugo
Qualcomm Datacenter Technologies as an affiliate of Qualcomm 
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.