?
Q2: What do you suggest to name multiple clocks on PCIe (FPGA) cards?
I will have multiple cards with multiple clock chips on each. The clock driver
can handle clocks on each chip. Is it recommended to create unique names by the
driver? Is there any example to follow?
Q3: Is there a guideline or
straction
> is to consider the clock input signals that your pcie/fpga device will
> take as input. With a proper clock driver for the silabs part your
> pcie/fpga driver could hopefully just call clk_prepare_enable and
> clk_set_rate and clk_set_parent as needed on those clocks to configu
gt; common
> functionality to a more abstract interface. But we just need this device
> support now,
> and when this one will become a member of some generic class - "frontier"
> will again
> move a step farther, new devices will emerge that stick out of the nice
> f
On Wed, 27 May 2015 17:10:06 -0700 Guenter Roeck wrote
> On 05/27/2015 04:58 PM, andrey wrote:
> >
> >
> > On Wed, 27 May 2015 16:08:12 -0700 Guenter Roeck
> > wrote
> >
> > > On 05/27/2015 12:44 PM, andrey wrote:
> > > > Hello all,
> > > > Let me add
On 05/27/2015 04:58 PM, andrey wrote:
On Wed, 27 May 2015 16:08:12 -0700 Guenter Roeck wrote
> On 05/27/2015 12:44 PM, andrey wrote:
> > Hello all,
> > Let me add a comment on using sysfs to simplify user space access to the
clock
> > features as opposed to controlling them
On Wed, 27 May 2015 16:08:12 -0700 Guenter Roeck wrote
> On 05/27/2015 12:44 PM, andrey wrote:
> > Hello all,
> > Let me add a comment on using sysfs to simplify user space access to the
> > clock
> > features as opposed to controlling them from a driver that uses the clock
On 05/27/2015 12:44 PM, andrey wrote:
Hello all,
Let me add a comment on using sysfs to simplify user space access to the clock
features as opposed to controlling them from a driver that uses the clock chip
driver.
It is common to use such advanced clock chips with the FPGA devices (as me and
he 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, an
r 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.
> >
> &
le 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.
>
gt;> 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.
ot 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
>
ange 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.
Re
On 05/27/2015 10:09 AM, Guenter Roeck wrote:
> On Wed, May 27, 2015 at 09:46:02AM -0700, York Sun wrote:
>>
> [ ... ]
>>
>> Sebastian,
>>
>> Thanks for the insight. Looks like I should give up upstreaming this driver.
>> I
>> will find other ways to make this driver available if anyone wants to
On Wed, May 27, 2015 at 09:46:02AM -0700, York Sun wrote:
>
[ ... ]
>
> Sebastian,
>
> Thanks for the insight. Looks like I should give up upstreaming this driver. I
> will find other ways to make this driver available if anyone wants to use it.
>
You might consider putting it on github. That
et initialized with their clocks. The clocks are not used by host
>> SoC, so
>> setting the wrong clocks doesn't crash the system. Each PCIe card has up to
>> four
>> clock chips (with four clocks on each chip). It is required for users to be
>> able
>> to chang
ks doesn't crash the system. Each PCIe card has up to four
clock chips (with four clocks on each chip). It is required for users to be able
to change the clocks after system boots up.
Consider a userspace configurable clock driver, load the FPGA design
which depends on a specific frequency gene
that will be requested. Expose
> each clock with CCF and find some good code to derive si5338 register
> values from the requested rate. si5351 driver is an example but I know
> silabs documentation isn't that good when it comes to dynamically
> changing the clocks. With CCF you&#
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.
This is your specific use case of the clock driver, something that
clearly doesn't match a generi
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 c
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
>> th
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 in
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
23 matches
Mail list logo
