All of lore.kernel.org
 help / color / mirror / Atom feed
* Programming a clock in the device tree
@ 2016-04-13 23:15 Peter Rosin
  2016-04-14 11:32 ` Sylwester Nawrocki
  0 siblings, 1 reply; 3+ messages in thread
From: Peter Rosin @ 2016-04-13 23:15 UTC (permalink / raw)
  To: linux-clk

Hi!

I'm trying to connect (in a device tree) a programmable clock
to a device that does not expect the clock to need any
programming.

I can hack this and add a clk_set_rate at the appropriate point
in the driver for the clk consumer, but I was expecting to see
some way of just adding a device tree node to get this done for
me.

It just feels wrong to add this hack to the driver as the
programmable clock might be needed for more than one device and
the decisions by one driver might conflict with other needs (the
driver in question can use a variety of clock rates, so the rate
it should request is policy not belonging in a driver).

Adding a device tree frequency property to the driver in question
is also a possibility, but that would need code duplication for
other clock consumers as well, when someone wants to use those
drivers in the way I'm now trying to use this driver.

I.e. I expected to see a driver, just like the fixed clock
driver, but that programs a parent clock instead of just
representing a fixed oscillator. Is there such a thing? If not,
what is it that I'm not seeing? Because I just can't believe that
I'm the first person to need this...

Cheers,
Peter

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Programming a clock in the device tree
  2016-04-13 23:15 Programming a clock in the device tree Peter Rosin
@ 2016-04-14 11:32 ` Sylwester Nawrocki
  2016-04-14 20:44   ` Peter Rosin
  0 siblings, 1 reply; 3+ messages in thread
From: Sylwester Nawrocki @ 2016-04-14 11:32 UTC (permalink / raw)
  To: Peter Rosin; +Cc: linux-clk

On 04/14/2016 01:15 AM, Peter Rosin wrote:
> Hi!
> 
> I'm trying to connect (in a device tree) a programmable clock
> to a device that does not expect the clock to need any
> programming.
> 
> I can hack this and add a clk_set_rate at the appropriate point
> in the driver for the clk consumer, but I was expecting to see
> some way of just adding a device tree node to get this done for
> me.
> 
> It just feels wrong to add this hack to the driver as the
> programmable clock might be needed for more than one device and
> the decisions by one driver might conflict with other needs (the
> driver in question can use a variety of clock rates, so the rate
> it should request is policy not belonging in a driver).
> 
> Adding a device tree frequency property to the driver in question
> is also a possibility, but that would need code duplication for
> other clock consumers as well, when someone wants to use those
> drivers in the way I'm now trying to use this driver.
> 
> I.e. I expected to see a driver, just like the fixed clock
> driver, but that programs a parent clock instead of just
> representing a fixed oscillator. Is there such a thing? If not,
> what is it that I'm not seeing? Because I just can't believe that
> I'm the first person to need this...

How about using assigned-{clocks, clock-parents, clock-rates}
properties in the clock provider node? Wouldn't it help in your
case? Documentation can be found in Documentation/devicetree/
bindings/clock/clock-bindings.txt


-- 
Regards,
Sylwester

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Programming a clock in the device tree
  2016-04-14 11:32 ` Sylwester Nawrocki
@ 2016-04-14 20:44   ` Peter Rosin
  0 siblings, 0 replies; 3+ messages in thread
From: Peter Rosin @ 2016-04-14 20:44 UTC (permalink / raw)
  To: Sylwester Nawrocki; +Cc: linux-clk

Hi!

On 2016-04-14 13:32, Sylwester Nawrocki wrote:
> On 04/14/2016 01:15 AM, Peter Rosin wrote:
>> Hi!
>>
>> I'm trying to connect (in a device tree) a programmable clock
>> to a device that does not expect the clock to need any
>> programming.
>>
>> I can hack this and add a clk_set_rate at the appropriate point
>> in the driver for the clk consumer, but I was expecting to see
>> some way of just adding a device tree node to get this done for
>> me.
>>
>> It just feels wrong to add this hack to the driver as the
>> programmable clock might be needed for more than one device and
>> the decisions by one driver might conflict with other needs (the
>> driver in question can use a variety of clock rates, so the rate
>> it should request is policy not belonging in a driver).
>>
>> Adding a device tree frequency property to the driver in question
>> is also a possibility, but that would need code duplication for
>> other clock consumers as well, when someone wants to use those
>> drivers in the way I'm now trying to use this driver.
>>
>> I.e. I expected to see a driver, just like the fixed clock
>> driver, but that programs a parent clock instead of just
>> representing a fixed oscillator. Is there such a thing? If not,
>> what is it that I'm not seeing? Because I just can't believe that
>> I'm the first person to need this...
> 
> How about using assigned-{clocks, clock-parents, clock-rates}
> properties in the clock provider node? Wouldn't it help in your
> case? Documentation can be found in Documentation/devicetree/
> bindings/clock/clock-bindings.txt

I added
	assigned-clocks = <&pck2>;
	assigned-clock-rates = <16000000>;
to the consumer node and that worked like a charm. That was exactly
what I was looking for, thanks!

Cheers,
Peter

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2016-04-14 20:44 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-04-13 23:15 Programming a clock in the device tree Peter Rosin
2016-04-14 11:32 ` Sylwester Nawrocki
2016-04-14 20:44   ` Peter Rosin

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.