All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
To: Dmitry Osipenko <digetx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Peter De Schrijver
	<pdeschrijver-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>,
	Prashant Gaikwad
	<pgaikwad-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>,
	Michael Turquette
	<mturquette-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>,
	Stephen Boyd <sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>,
	Thierry Reding
	<thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: linux-clk-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH] clk: tegra: Mark APB clock as critical
Date: Wed, 29 Nov 2017 22:55:36 +0000	[thread overview]
Message-ID: <9d479a38-f40b-0e58-09c3-d06e9ee32a25@nvidia.com> (raw)
In-Reply-To: <95c14859-a2c7-1c61-adba-bd6c16155c01-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>


On 29/11/17 15:08, Dmitry Osipenko wrote:
> On 29.11.2017 13:12, Jon Hunter wrote:
>>
>> On 29/11/17 00:09, Dmitry Osipenko wrote:
>>> On 29.11.2017 02:30, Dmitry Osipenko wrote:
>>>> On 23.10.2017 14:12, Jon Hunter wrote:
>>>>> Commit a140614373ae ("clk: tegra: Correct parent of the APBDMA clock")
>>>>> fixed the parent clock for APBDMA, but the consequence of this that
>>>>> after probing the APBDMA device, the APB Clock (or PCLK) is now
>>>>> disabled. Disabling the APB clock causes accesses to any other device
>>>>> on the APB to hang and prevent Tegra from booting.
>>>>>
>>>>> Currently, the APB clock is registered with the flag "CLK_IGNORE_UNUSED"
>>>>> to prevent the clock being disabled if unused on boot. However, even
>>>>> if it is used, it still needs to be always kept enabled and so update
>>>>> the flag for the APB clock to be "CLK_IS_CRITICAL".
>>>>>
>>>>> Fixes: a140614373ae ("clk: tegra: Correct parent of the APBDMA clock")
>>>>>
>>>>> Suggested-by: Peter De Schrijver <pdeschrijver-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>>>>> Signed-off-by: Jon Hunter <jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>>>>> ---
>>>>>  drivers/clk/tegra/clk-tegra-super-gen4.c | 2 +-
>>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/drivers/clk/tegra/clk-tegra-super-gen4.c b/drivers/clk/tegra/clk-tegra-super-gen4.c
>>>>> index 4f6fd307cb70..10047107c1dc 100644
>>>>> --- a/drivers/clk/tegra/clk-tegra-super-gen4.c
>>>>> +++ b/drivers/clk/tegra/clk-tegra-super-gen4.c
>>>>> @@ -166,7 +166,7 @@ static void __init tegra_sclk_init(void __iomem *clk_base,
>>>>>  				   clk_base + SYSTEM_CLK_RATE, 0, 2, 0,
>>>>>  				   &sysrate_lock);
>>>>>  	clk = clk_register_gate(NULL, "pclk", "pclk_div", CLK_SET_RATE_PARENT |
>>>>> -				CLK_IGNORE_UNUSED, clk_base + SYSTEM_CLK_RATE,
>>>>> +				CLK_IS_CRITICAL, clk_base + SYSTEM_CLK_RATE,
>>>>>  				3, CLK_GATE_SET_TO_DISABLE, &sysrate_lock);
>>>>>  	*dt_clk = clk;
>>>>>  }
>>>>>
>>>>
>>>> Unfortunately this patch somehow breaks Tegra20, getting a hang during boot. For
>>>> now I don't know what's the cause of the issue, may take a more detailed look
>>>> soon. If you have any suggestions, please tell.
>>>>
>>>
>>> It looks like that with CLK_IS_CRITICAL flag, pclk is getting enabled before
>>> clock rate is setup and in result it is enabled with some invalid rate config.
>>
>> What Tegra20 platform? I have not seen any issues with booting Tegra20
>> trimslice with v4.15-rc1 or next-20171129. I am surprised this clock
>> would not have been enabled by the bootloader and hence rate set correctly.
>>
> 
> It is not an upstream'ed device and it uses proprietary bootloader. But turned
> out it is unrelated.. the actual problem is that with the offending patch
> applied, for some reason PLL_M is now getting disabled on SCLK reparent, PLL_M
> is a critical clock that feeds EMC and marking it as CLK_IS_CRITICAL fixes issue
> for me.
> 
> Jon, could you please try to revert "Mark APB clock as critical" patch, mark the
> PLL_M as critical and re-test?

Sorry but you have lost me here. I am not sure I understand the relation
between the problem you are describing and this change.

Please note that the problem I was fixing with this patch was seen on
Tegra114/124 and not Tegra20. I don't recall seeing any issues with
Tegra20 and I just checked Tegra20 is still booting for me even when
reverting this. So it sounds like a different problem AFAICT.

Cheers
Jon

-- 
nvpublic

WARNING: multiple messages have this Message-ID (diff)
From: Jon Hunter <jonathanh@nvidia.com>
To: Dmitry Osipenko <digetx@gmail.com>,
	Peter De Schrijver <pdeschrijver@nvidia.com>,
	Prashant Gaikwad <pgaikwad@nvidia.com>,
	"Michael Turquette" <mturquette@baylibre.com>,
	Stephen Boyd <sboyd@codeaurora.org>,
	Thierry Reding <thierry.reding@gmail.com>
Cc: <linux-clk@vger.kernel.org>, <linux-tegra@vger.kernel.org>
Subject: Re: [PATCH] clk: tegra: Mark APB clock as critical
Date: Wed, 29 Nov 2017 22:55:36 +0000	[thread overview]
Message-ID: <9d479a38-f40b-0e58-09c3-d06e9ee32a25@nvidia.com> (raw)
In-Reply-To: <95c14859-a2c7-1c61-adba-bd6c16155c01@gmail.com>


On 29/11/17 15:08, Dmitry Osipenko wrote:
> On 29.11.2017 13:12, Jon Hunter wrote:
>>
>> On 29/11/17 00:09, Dmitry Osipenko wrote:
>>> On 29.11.2017 02:30, Dmitry Osipenko wrote:
>>>> On 23.10.2017 14:12, Jon Hunter wrote:
>>>>> Commit a140614373ae ("clk: tegra: Correct parent of the APBDMA clock")
>>>>> fixed the parent clock for APBDMA, but the consequence of this that
>>>>> after probing the APBDMA device, the APB Clock (or PCLK) is now
>>>>> disabled. Disabling the APB clock causes accesses to any other device
>>>>> on the APB to hang and prevent Tegra from booting.
>>>>>
>>>>> Currently, the APB clock is registered with the flag "CLK_IGNORE_UNUSED"
>>>>> to prevent the clock being disabled if unused on boot. However, even
>>>>> if it is used, it still needs to be always kept enabled and so update
>>>>> the flag for the APB clock to be "CLK_IS_CRITICAL".
>>>>>
>>>>> Fixes: a140614373ae ("clk: tegra: Correct parent of the APBDMA clock")
>>>>>
>>>>> Suggested-by: Peter De Schrijver <pdeschrijver@nvidia.com>
>>>>> Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
>>>>> ---
>>>>>  drivers/clk/tegra/clk-tegra-super-gen4.c | 2 +-
>>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/drivers/clk/tegra/clk-tegra-super-gen4.c b/drivers/clk/tegra/clk-tegra-super-gen4.c
>>>>> index 4f6fd307cb70..10047107c1dc 100644
>>>>> --- a/drivers/clk/tegra/clk-tegra-super-gen4.c
>>>>> +++ b/drivers/clk/tegra/clk-tegra-super-gen4.c
>>>>> @@ -166,7 +166,7 @@ static void __init tegra_sclk_init(void __iomem *clk_base,
>>>>>  				   clk_base + SYSTEM_CLK_RATE, 0, 2, 0,
>>>>>  				   &sysrate_lock);
>>>>>  	clk = clk_register_gate(NULL, "pclk", "pclk_div", CLK_SET_RATE_PARENT |
>>>>> -				CLK_IGNORE_UNUSED, clk_base + SYSTEM_CLK_RATE,
>>>>> +				CLK_IS_CRITICAL, clk_base + SYSTEM_CLK_RATE,
>>>>>  				3, CLK_GATE_SET_TO_DISABLE, &sysrate_lock);
>>>>>  	*dt_clk = clk;
>>>>>  }
>>>>>
>>>>
>>>> Unfortunately this patch somehow breaks Tegra20, getting a hang during boot. For
>>>> now I don't know what's the cause of the issue, may take a more detailed look
>>>> soon. If you have any suggestions, please tell.
>>>>
>>>
>>> It looks like that with CLK_IS_CRITICAL flag, pclk is getting enabled before
>>> clock rate is setup and in result it is enabled with some invalid rate config.
>>
>> What Tegra20 platform? I have not seen any issues with booting Tegra20
>> trimslice with v4.15-rc1 or next-20171129. I am surprised this clock
>> would not have been enabled by the bootloader and hence rate set correctly.
>>
> 
> It is not an upstream'ed device and it uses proprietary bootloader. But turned
> out it is unrelated.. the actual problem is that with the offending patch
> applied, for some reason PLL_M is now getting disabled on SCLK reparent, PLL_M
> is a critical clock that feeds EMC and marking it as CLK_IS_CRITICAL fixes issue
> for me.
> 
> Jon, could you please try to revert "Mark APB clock as critical" patch, mark the
> PLL_M as critical and re-test?

Sorry but you have lost me here. I am not sure I understand the relation
between the problem you are describing and this change.

Please note that the problem I was fixing with this patch was seen on
Tegra114/124 and not Tegra20. I don't recall seeing any issues with
Tegra20 and I just checked Tegra20 is still booting for me even when
reverting this. So it sounds like a different problem AFAICT.

Cheers
Jon

-- 
nvpublic

  parent reply	other threads:[~2017-11-29 22:55 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-23 11:12 [PATCH] clk: tegra: Mark APB clock as critical Jon Hunter
2017-10-23 11:12 ` Jon Hunter
     [not found] ` <1508757172-13030-1-git-send-email-jonathanh-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2017-10-23 11:57   ` Peter De Schrijver
2017-10-23 11:57     ` Peter De Schrijver
2017-11-28 23:30 ` Dmitry Osipenko
     [not found]   ` <18f57c1f-add0-908a-6a26-7cc81f29d7d9-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2017-11-29  0:09     ` Dmitry Osipenko
2017-11-29  0:09       ` Dmitry Osipenko
     [not found]       ` <f940d9f1-aaec-cf25-24d2-956df63bbbd1-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2017-11-29 10:12         ` Jon Hunter
2017-11-29 10:12           ` Jon Hunter
2017-11-29 15:08           ` Dmitry Osipenko
     [not found]             ` <95c14859-a2c7-1c61-adba-bd6c16155c01-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2017-11-29 22:55               ` Jon Hunter [this message]
2017-11-29 22:55                 ` Jon Hunter
2017-11-29 23:13                 ` Dmitry Osipenko
     [not found]                   ` <a96d03da-c2a3-1e44-f227-02577f972df6-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2017-11-30 11:31                     ` Jon Hunter
2017-11-30 11:31                       ` Jon Hunter
2017-11-30 13:24                       ` Dmitry Osipenko
     [not found]                         ` <6264cf17-0850-37dd-ca92-9362521d2db6-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2017-11-30 16:39                           ` Jon Hunter
2017-11-30 16:39                             ` Jon Hunter
     [not found]                             ` <236aa250-3b9b-94de-0978-0fb8546d504d-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2017-11-30 16:45                               ` Dmitry Osipenko
2017-11-30 16:45                                 ` Dmitry Osipenko
2017-11-30 16:51                                 ` Jon Hunter
2017-11-30 16:51                                   ` Jon Hunter
     [not found]                                   ` <43e293c3-daf2-7b2e-2524-f14de3811f44-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2017-11-30 16:53                                     ` Dmitry Osipenko
2017-11-30 16:53                                       ` Dmitry Osipenko
     [not found]                                       ` <6378f92d-54a9-590a-5fdb-88a7bfa96fc1-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2017-11-30 17:22                                         ` Jon Hunter
2017-11-30 17:22                                           ` Jon Hunter
2017-11-30 17:49                                           ` Dmitry Osipenko
2017-12-01  8:48                               ` Peter De Schrijver
2017-12-01  8:48                                 ` Peter De Schrijver
2017-12-02 12:47                                 ` Dmitry Osipenko
     [not found]                                   ` <803890bc-e3fe-134a-2127-3363187d04f2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2017-12-05  9:06                                     ` Peter De Schrijver
2017-12-05  9:06                                       ` Peter De Schrijver
     [not found]                                       ` <20171205090635.GL32106-Rysk9IDjsxmJz7etNGeUX8VPkgjIgRvpAL8bYrjMMd8@public.gmane.org>
2017-12-05 18:22                                         ` Dmitry Osipenko
2017-12-05 18:22                                           ` Dmitry Osipenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9d479a38-f40b-0e58-09c3-d06e9ee32a25@nvidia.com \
    --to=jonathanh-ddmlm1+adcrqt0dzr+alfa@public.gmane.org \
    --cc=digetx-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=linux-clk-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=mturquette-rdvid1DuHRBWk0Htik3J/w@public.gmane.org \
    --cc=pdeschrijver-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
    --cc=pgaikwad-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
    --cc=sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org \
    --cc=thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.