[PATCH 05/10] clk: Add support for simple dividers

Saravana Kannan
2011-05-03T03:37:06Z

On 04/28/2011 08:14 AM, Russell King - ARM Linux wrote:
> On Mon, Apr 18, 2011 at 07:45:53PM -0700, Saravana Kannan wrote:
>> On 04/18/2011 03:07 AM, Sascha Hauer wrote:
>>> AFAIK there are two different implementation types in the tree. Some
>>> implementations only allow to set to the exact rate round_rate returns
>>> while others round down in set_rate.
>>>
>>> Has this been specified what behaviour is expected?
>>>
>>
>> This is something I have nagged Russell once or twice about and then
>> sent out an email to the list for which there was very limited response.
>> I think clk_round_rate() is too generic and not very useful.
>
> As I've always said, clk_round_rate() returns the rate which you will
> get if you ask clk_set_rate() to set the same rate. It's not ment to
> be "tell me the clock rate which I'd like to then pass to clk_set_rate(),
> oh that's not good enough, so lets tweak it a bit and try again".

Yes, I understood the purpose of clk_round_rate() from the previous
discussion we had.

> For example, take a video driver. The user passes in the pixel clock as
> a picosecond argument. This gets converted to Hz. We can then use
> clk_round_rate() to find out what clock rate we _actually_ end up with
> when we set that rate using clk_set_rate(), and return that rate (again
> as ps) back to the user before we alter anything. The user can then
> make a decision whether they want to actually set it.

Sure clk_round_rate() might be sufficient for this case.

> Having some sort of range stuff doesn't help you there because you're
> not supplied a range from userspace. You're just asked to set a 39752ps
> clock rate.

But this not the problem I'm trying to solve though. There are several
devices that have a freq operating range in their spec sheet and they
can't operate outside of that range. As of today, when the
device/drivers are used in multiple soc/arch, they are solving that
issue either by using clk_round_rate() in a way that you didn't intend
(to search for a freq that will work for them) or by passing in the
clock freq through platform data.

I think a better way to solve this problem is to have a
clk_set_rate_range() and hence suggesting it. This would also help
reduce the no. of lines/data passed in board files which I think helps
clean up ARM code.

Btw, one of the use cases this would help is actually related to display
too. It's some clock that's fed to the display panel (I don't think it's
the pixel clock) which has a 96 MHz - 103 MHz operating range.

-Saravana
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.