Message-ID: <20150527185442.GA6607@roeck-us.net>
Date:	Wed, 27 May 2015 11:54:42 -0700
From:	Guenter Roeck <linux@...ck-us.net>
To:	York Sun <yorksun@...escale.com>
Cc:	Michael Turquette <mturquette@...aro.org>,
	linux-i2c@...r.kernel.org, linux-kernel@...r.kernel.org,
	lee.jones@...aro.org, andrey@...hel.com,
	sebastian.hesselbarth@...il.com, rabeeh@...id-run.com
Subject: Re: clock driver

On Wed, May 27, 2015 at 11:24:50AM -0700, York Sun wrote:
> 
> > 
> > Someone suggested earlier that the clocks should be set from the PCIe driver.
> > Question here is really if you need to control the clocks from user space.
> > Even if you do, the driver for the chip _using_ the clocks would be better
> > suited for changing the clock rates than the clock driver itself. This way it
> > can ensure that the clock rates are sane for the given use case, and the use
> > case is kept out of the clock driver.
> > 
> >> I wrote a driver for the PCIe card to load FPGA images. To setup the clocks, I
> >> rewrote the SI5338 driver and set the desired frequencies using sysfs. This
> >> driver has a feature to import/dump the raw configuration data. That's one
> >> feature I plan to use, at least for debugging.
> >>
> > With the above in mind, the idea would be for the PCIe driver to set the clock
> > rates.
> 
> I am interested in this path. Can you explain a little bit more about setting
> the clock rates? I have no experience on CCF.
> 
The API functions are documented in include/linux/clk.h. What you are looking
for here would be clk_set_rate() and related functions such as clk_round_rate(),
and of course support functions such as devm_clk_get(), clk_prepare_enable(),
and clk_disable_unprepare().

You can find lots of examples on how this works if you search for clk_set_rate()
in the kernel source.

> > 
> >> I don't think device tree is the best for my application because I will have
> >> about 30 clock chips to program in the complete system. It is easier to use user
> >> space application to do so from I2C bus.
> >>
> > Devicetree is static, so you might have to use devicetree overlays if the
> > programming changes at runtime. Not sure why the number of clock chips
> > would make that non-feasible, though.
> 
> I mean the existence is unknown for many chips. The baseline is I can't use
> static data.
> 
> > 
> > On a side note, we are using devicetree a lot for PCIe devices.
> 
> It's tempting. I want to explore this direction at a later phase of my project.
> I will appreciate if you can point me to something.
> 
I can send you some devicetree files if you think that would help. Note that we
are heavily using devicetree overlays, so this is all a bit WIP.

> > 
> >> Earlier Guenter helped me to comb through the idea and we concluded CCF may not
> >> be the best fit for this application. I wonder if CCF is the only way to get
> > 
> > Well, you did ;-). I think it would be feasible, but you would have to change
> > your viewpoint (in respect to how to control the clocks).
> 
> Right, I did. I will revisit this after bring up the platform initially, when I
> have more knowledge about those clocks. Maybe I should add an interface for my
> FPGA driver to request clock rates, instead of setting them from clock driver.
> It sounds better.
> 
Yes, that would be the idea. Essentially your FPGA driver could either determine
the clock rate(s) it needs internally, or you could set the clock rate(s)
through sysfs attributes attached to the FPGA driver. The FPGA driver would then
use clk_set_rate() to set the rate in the clock chip.

Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists