On 05/27/2015 11:54 AM, Guenter Roeck wrote: > 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. Yes I saw them. I have no experience with CCF. It will take some learning time. I am trying to find an SI5xx EVB board so I can try it out. > >>> >>>> 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. Yes, please send them to me. > >>> >>>> 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. > Sounds promising. Thanks for the guidance. York -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
