On 05/27/2015 11:15 AM, Guenter Roeck wrote: > On Wed, May 27, 2015 at 10:45:32AM -0700, York Sun wrote: >> >> >> On 05/27/2015 10:30 AM, Michael Turquette wrote: >>> Quoting York Sun (2015-05-26 17:32:13) >>>> Michael, >>>> >>>> Can you give me some guidance here? >>>> >>>> >>>> On 05/26/2015 05:20 PM, York Sun wrote: >>>>> >>>>> >>>>> On 05/26/2015 03:38 PM, Guenter Roeck wrote: >>>>>> On Tue, May 26, 2015 at 12:12:11PM -0700, York Sun wrote: >>>>>>> Linux experts, >>>>>>> >>>>>>> I have rewritten a driver for Silicon Labs SI5338 programmable clock chip. The >>>>>>> original driver was written by Andrey (CC'ed), but was floatingn outside of the >>>>>>> kernel. The driver was written to use sysfs as the interface, not the common >>>>>>> clock framework. I wonder if I have to rewrite the driver following common clock >>>>>>> framework. One concern is to support a feature to accept ClockBuilder (TM) >>>>>>> output on sysfs. I don't see sysfs support on common clock framework. Please >>>>>>> correct me if I am wrong. >>> >>> Can you give me a link to some info about ClockBuilder? >> >> It is a software provided by Silicon Labs to create configuration. See >> http://www.silabs.com/products/clocksoscillators/Pages/Timing-Software-Development-Tools.aspx >> >>> >>>>>>> >>>>>>> If not using common clock framework is acceptable, I would like to send a RFC >>>>>>> patch for review. >>>>>>> >>>>>> My original driver for si570 was rejected because it didn't support the clock >>>>>> framework, so you might face an uphill battle. >>>>>> >>>>>> SI provides a document for SI5338 describing how to configure it without >>>>>> using clockbuilder [1]. Can that be used to implement generic code which >>>>>> doesn't need clockbuilder ? >>>>>> >>>>> >>>>> The driver is capable to handle the user's input and enable the clocks. Removing >>>>> the support of importing is a step back. At least it is a feature I am using. I >>>>> believe Andrey also used this feature when the driver was first drafted. >>>>> >>>>> That being said, my application relies on setting multiple clock chips on a PCIe >>>>> device. That means I cannot put the configuration into device tree. There may be >>>>> a way to fill device tree, but I am not ready to explore yet. Without a sysfs >>>>> interface, can I change the configuration for each clock? >>> >>> CCF does not have any dependency on DeviceTree. Zero. If you don't want >>> to use DT, then that is great! The ARM community has chosen DT, and the >>> ARM community by and large uses CCF in Linux. But there is no >>> requirement to use DT if you want to use CCF. >> >> That's good to know. >> >>> >>> Regarding sysfs, I really need to understand what interfaces you want >>> from sysfs. Can you provide a link to the ClockBuilder(TM) stuff? >>> >>> It is certainly possible for you to create sysfs entries in your clock >>> driver. Depending on what you want to do, there may be no need to >>> involve the framework in this stuff. Do you think you can keep your >>> sysfs stuff localized in your driver? >> >> I understand that I can create sysfs entries in my driver. I brought it up >> because I remember seeing your plan to add sysfs interface. >> >> If I add sysfs for this driver, it will not be a generic driver. >> >>> >>>>> >>>>> I also found COMMON_CLK is a bool, not tristate. It is only selected by others. >>>>> Is there a reason for doing so? My current platform (P1022DS) doesn't have >>>>> CONFIG_COMMON_CLK enabled. >>>>> >>>> >>>> If converting my driver to common clock framework, I need to find a way to >>>> configure the clocks without recompiling the kernel. I will have about 30 clock >>>> chips (with different frequency) on multiple PCIe cards. >>> >>> Sure. Let's figure out your requirements and decide if we can make CCF >>> work for you. I think we can. >>> >>> I know that the Beagle Bone folks have been looking at modifying DT >>> blobs and changing them/loading them at run-time. That might be >>> interesting for your on-the-fly clock configuration. >>> >>> If you don't like DT then perhaps you can export your sysfs clock stuff >>> via your clock driver, instead of the framework? >>> >> >> Like I explained in the other email of this thread, I plan to use the clock >> driver to initialize clocks on PCIe (FPGA) cards which four chips on each card. >> The clocks will be set by the host SoC for FPGA to use. Messing with the clocks >> will not crash host OS. It is required to set the clocks with different >> frequencies without recompiling/rebooting the host OS. >> > > 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. > >> 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. > >> 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. 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
