Re: clock driver

From: York Sun
Date: Wed May 27 2015 - 13:46:45 EST




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.

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.

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.

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
clock supported now.

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