Re: [PATCH 2/2] clk: uniphier: add clock data for cpufreq

From: Masahiro Yamada <yamada.masahiro@socionext.com>
To: Stephen Boyd <sboyd@codeaurora.org>
Cc: linux-clk <linux-clk@vger.kernel.org>,
	Michael Turquette <mturquette@baylibre.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 2/2] clk: uniphier: add clock data for cpufreq
Date: Thu, 24 Nov 2016 09:57:32 +0900	[thread overview]
Message-ID: <CAK7LNAQ6XeSHd7DbvD1jWeMfOqk8+R27Q-fNDWtXxpRd=OFgjA@mail.gmail.com> (raw)
In-Reply-To: <20161124000503.GE6095@codeaurora.org>

Hi Stephen,

2016-11-24 9:05 GMT+09:00 Stephen Boyd <sboyd@codeaurora.org>:

>> +#if 1
>> +     /*
>> +      * TODO:
>> +      * The return type of .round_rate() is "long", which is 32 bit wide on
>> +      * 32 bit systems.  Clock rate greater than LONG_MAX (~ 2.15 GHz) is
>> +      * treated as an error.  Needs a workaround until the problem is fixed.
>> +      */
>
> Just curious is the problem internal to the clk framework because
> of the clk_ops::round_rate design? Or does the consumer, cpufreq
> in this case, have to deal with rates that are larger than
> unsigned long on a 32 bit system? If it's just a clk_ops problem
> and we need to support rates up to 32 bits wide (~ 4.3 GHz) on
> the system then the driver could be changed to use
> .determine_rate() ops and that would allow us to use all the bits
> of unsigned long to figure out rates.
>
> If the problem is rates even larger than unsigned long on 32 bit
> systems, then at the least I'd like to see some sort of plan to
> fix that in the framework before merging code. Hopefully it can
> be done gradually, but as I start looking at it it seems more and
> more complicated to support this so this will be a long term
> project.
>
> We can discuss the clk API changes needed as well if those are
> required, but that is another issue that requires changes in
> other places outside of clk drivers.
>

I understand your point, but core frame-work changes
need more careful review than clk data changes in low-level drivers.
It is too late to be included in v4.10.

If I drop 32bit SoC things, and send v2 only for 64bit SoCs,
is that acceptable for 4.10-rc1?

Our ARMv8 SoCs are more actively developed, so
getting 64bit clk data in first will be helpful.

I postpone the 32bit SoC data until
I figure out the root cause of the problem
(and possible change for the API if necessary).

-- 
Best Regards
Masahiro Yamada