linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dmitry Osipenko <digetx@gmail.com>
To: Jon Hunter <jonathanh@nvidia.com>,
	Thierry Reding <thierry.reding@gmail.com>,
	Peter De Schrijver <pdeschrijver@nvidia.com>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Viresh Kumar <viresh.kumar@linaro.org>,
	Rob Herring <robh+dt@kernel.org>
Cc: linux-pm@vger.kernel.org, devicetree@vger.kernel.org,
	linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1 1/5] dt-bindings: cpufreq: Add binding for NVIDIA Tegra20/30
Date: Wed, 17 Oct 2018 17:43:38 +0300	[thread overview]
Message-ID: <e4f63df9-d92a-4e57-05ba-c999bdda9cc0@gmail.com> (raw)
In-Reply-To: <4db9c51c-0c1d-c9a2-b781-250c053e6e24@nvidia.com>

On 10/17/18 5:14 PM, Jon Hunter wrote:
> 
> On 17/10/2018 14:46, Dmitry Osipenko wrote:
>> On 10/17/18 4:34 PM, Jon Hunter wrote:
>>>
>>> On 17/10/2018 14:07, Dmitry Osipenko wrote:
>>>> On 10/17/18 3:59 PM, Jon Hunter wrote:
>>>>>
>>>>> On 17/10/2018 13:37, Dmitry Osipenko wrote:
>>>>>> On 10/17/18 11:40 AM, Jon Hunter wrote:
>>>>>>>
>>>>>>> On 30/08/2018 20:43, Dmitry Osipenko wrote:
>>>>>>>> Add device-tree binding that describes CPU frequency-scaling hardware
>>>>>>>> found on NVIDIA Tegra20/30 SoC's.
>>>>>>>>
>>>>>>>> Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
>>>>>>>> ---
>>>>>>>>  .../cpufreq/nvidia,tegra20-cpufreq.txt        | 38 +++++++++++++++++++
>>>>>>>>  1 file changed, 38 insertions(+)
>>>>>>>>  create mode 100644 Documentation/devicetree/bindings/cpufreq/nvidia,tegra20-cpufreq.txt
>>>>>>>>
>>>>>>>> diff --git a/Documentation/devicetree/bindings/cpufreq/nvidia,tegra20-cpufreq.txt b/Documentation/devicetree/bindings/cpufreq/nvidia,tegra20-cpufreq.txt
>>>>>>>> new file mode 100644
>>>>>>>> index 000000000000..2c51f676e958
>>>>>>>> --- /dev/null
>>>>>>>> +++ b/Documentation/devicetree/bindings/cpufreq/nvidia,tegra20-cpufreq.txt
>>>>>>>> @@ -0,0 +1,38 @@
>>>>>>>> +Binding for NVIDIA Tegra20 CPUFreq
>>>>>>>> +==================================
>>>>>>>> +
>>>>>>>> +Required properties:
>>>>>>>> +- clocks: Must contain an entry for each entry in clock-names.
>>>>>>>> +  See ../clocks/clock-bindings.txt for details.
>>>>>>>> +- clock-names: Must include the following entries:
>>>>>>>> +  - pll_x: main-parent for CPU clock, must be the first entry
>>>>>>>> +  - backup: intermediate-parent for CPU clock
>>>>>>>> +  - cpu: the CPU clock
>>>>>>>
>>>>>>> Is it likely that 'backup' will be anything other that pll_p? If not why
>>>>>>> not just call it pll_p? Personally, I don't 'backup' to descriptive even
>>>>>>> though I can see what you mean.
>>>>>>>
>>>>>>> I can see that you want to make this flexible, but if the likelihood is
>>>>>>> that we will just use pll_p then I am not sure it is warranted at this
>>>>>>> point.
>>>>>>
>>>>>> That won't describe HW, but software. And device tree should describe HW.
>>>>>
>>>>> Hmm ... well that's my point exactly. So why call it 'backup'? Sounds
>>>>> like a software description to me.
>>>>
>>>> Because HW is designed the way that CPU parent need to be switched to the backup clock source while main clock changes its rate. HW also allow to select among different parents, pll_p is one of those parents.
>>>
>>> Yes that part is understood. I am just splitting hairs over the actual
>>> name. We do the same for tegra124 but we just call it 'pll_p'. See ...
>>>
>>> Documentation/devicetree/bindings/cpufreq/nvidia,tegra124-cpufreq.txt
>>
>> tegra124-cpufreq choose to hardwire to the pll_p, but it could be other clocks. Technically abstracting backup clock should be more correct, but result is the same in the end.
> 
> Yes and that is probably intentional as that is the configuration that
> has been validated. So unless we are planning to test and verify every
> possibility, my preference is to keep it simple. But yes the result is
> the same.
> 
> I was simply curious of your intention here because of the other series
> you posted with regard to the cpu clocks.

Actually I tried other parents on T30 and they worked with no problems. The intention of having 'backup' is to describe HW properly in the device tree, that's it. We'll have backup set to pll_p by default. ACK?

  reply	other threads:[~2018-10-17 14:43 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-30 19:43 [PATCH v1 0/5] CPUFREQ OPP's and Tegra30 support by tegra20-cpufreq driver Dmitry Osipenko
2018-08-30 19:43 ` [PATCH v1 1/5] dt-bindings: cpufreq: Add binding for NVIDIA Tegra20/30 Dmitry Osipenko
2018-09-25 16:58   ` Rob Herring
2018-09-25 17:29     ` Dmitry Osipenko
2018-09-25 19:36       ` Rob Herring
2018-09-25 21:57         ` Dmitry Osipenko
2018-10-17  8:40   ` Jon Hunter
2018-10-17 12:37     ` Dmitry Osipenko
2018-10-17 12:42       ` Dmitry Osipenko
2018-10-17 12:59       ` Jon Hunter
2018-10-17 13:07         ` Dmitry Osipenko
2018-10-17 13:34           ` Jon Hunter
2018-10-17 13:46             ` Dmitry Osipenko
2018-10-17 14:14               ` Jon Hunter
2018-10-17 14:43                 ` Dmitry Osipenko [this message]
2018-10-17 19:29                   ` Jon Hunter
2018-10-17 20:57                     ` Dmitry Osipenko
2018-08-30 19:43 ` [PATCH v1 2/5] cpufreq: tegra20: Support OPP, thermal cooling and Tegra30 Dmitry Osipenko
2018-10-17  8:47   ` Jon Hunter
2018-08-30 19:43 ` [PATCH v1 3/5] ARM: tegra: Create tegra20-cpufreq device on Tegra30 Dmitry Osipenko
2018-10-17  8:49   ` Jon Hunter
2018-10-17  9:54     ` Jon Hunter
2018-10-17 12:02       ` Dmitry Osipenko
2018-08-30 19:43 ` [PATCH v1 4/5] ARM: dts: tegra20: Add CPU Operating Performance Points Dmitry Osipenko
2018-08-30 19:43 ` [PATCH v1 5/5] ARM: dts: tegra30: " Dmitry Osipenko
2018-09-06 12:35 ` [PATCH v1 0/5] CPUFREQ OPP's and Tegra30 support by tegra20-cpufreq driver Marcel Ziswiler
2018-09-07 16:59   ` Dmitry Osipenko
2018-09-11  8:27     ` Marcel Ziswiler
2018-09-14 10:30       ` 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=e4f63df9-d92a-4e57-05ba-c999bdda9cc0@gmail.com \
    --to=digetx@gmail.com \
    --cc=devicetree@vger.kernel.org \
    --cc=jonathanh@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=pdeschrijver@nvidia.com \
    --cc=rjw@rjwysocki.net \
    --cc=robh+dt@kernel.org \
    --cc=thierry.reding@gmail.com \
    --cc=viresh.kumar@linaro.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).