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 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. On a side note, we are using devicetree a lot for PCIe devices. > 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). Thanks, Guenter -- 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
