linux-kernel - Re: clock driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <556613CE.8020906@freescale.com>
Date:	Wed, 27 May 2015 11:58:22 -0700
From:	York Sun <yorksun@...escale.com>
To:	Guenter Roeck <linux@...ck-us.net>
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 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-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/