From: York Sun <yorksun-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
To: Guenter Roeck <linux-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>,
mturquette-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org
Cc: linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
andrey-MoRZu3FOBbXQT0dZR+AlfA@public.gmane.org,
sebastian.hesselbarth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
rabeeh-UBr1pzP51AyaMJb+Lgu22Q@public.gmane.org
Subject: Re: clock driver
Date: Tue, 26 May 2015 17:32:13 -0700 [thread overview]
Message-ID: <5565108D.2020502@freescale.com> (raw)
In-Reply-To: <55650DBA.5000304-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
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.
>>>
>>> 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?
>
> 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.
York
WARNING: multiple messages have this Message-ID (diff)
From: York Sun <yorksun@freescale.com>
To: Guenter Roeck <linux@roeck-us.net>, <mturquette@linaro.org>
Cc: <linux-i2c@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<lee.jones@linaro.org>, <andrey@elphel.com>,
<sebastian.hesselbarth@gmail.com>, <rabeeh@solid-run.com>
Subject: Re: clock driver
Date: Tue, 26 May 2015 17:32:13 -0700 [thread overview]
Message-ID: <5565108D.2020502@freescale.com> (raw)
In-Reply-To: <55650DBA.5000304@freescale.com>
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.
>>>
>>> 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?
>
> 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.
York
next prev parent reply other threads:[~2015-05-27 0:32 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-26 19:12 clock driver York Sun
2015-05-26 19:12 ` York Sun
[not found] ` <5564C58B.9050400-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
2015-05-26 22:38 ` Guenter Roeck
2015-05-26 22:38 ` Guenter Roeck
[not found] ` <20150526223829.GA26454-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>
2015-05-27 0:20 ` York Sun
2015-05-27 0:20 ` York Sun
[not found] ` <55650DBA.5000304-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
2015-05-27 0:32 ` York Sun [this message]
2015-05-27 0:32 ` York Sun
[not found] ` <5565108D.2020502-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
2015-05-27 7:09 ` Sebastian Hesselbarth
2015-05-27 7:09 ` Sebastian Hesselbarth
2015-05-27 15:07 ` York Sun
2015-05-27 15:07 ` York Sun
2015-05-27 16:42 ` Sebastian Hesselbarth
[not found] ` <5565F40E.70805-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2015-05-27 16:46 ` York Sun
2015-05-27 16:46 ` York Sun
[not found] ` <5565F4CA.4080105-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
2015-05-27 17:09 ` Guenter Roeck
2015-05-27 17:09 ` Guenter Roeck
2015-05-27 17:10 ` York Sun
2015-05-27 17:10 ` York Sun
2015-05-27 17:30 ` Michael Turquette
2015-05-27 17:30 ` Michael Turquette
2015-05-27 17:45 ` York Sun
2015-05-27 17:45 ` York Sun
[not found] ` <556602BC.6040203-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
2015-05-27 18:15 ` Guenter Roeck
2015-05-27 18:15 ` Guenter Roeck
[not found] ` <20150527181521.GA19448-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>
2015-05-27 18:24 ` York Sun
2015-05-27 18:24 ` York Sun
2015-05-27 18:54 ` Guenter Roeck
2015-05-27 18:58 ` York Sun
2015-05-27 18:58 ` York Sun
[not found] ` <14d96cd6d64.f62a1a09739217.9114963256886461171@elphel.com>
[not found] ` <14d96cd6d64.f62a1a09739217.9114963256886461171-MoRZu3FOBbXQT0dZR+AlfA@public.gmane.org>
2015-05-27 23:08 ` Guenter Roeck
2015-05-27 23:08 ` Guenter Roeck
2015-05-27 23:58 ` andrey
2015-05-27 23:58 ` andrey
[not found] ` <14d97d05f05.c0c23a8c778110.9087956443203424916-MoRZu3FOBbXQT0dZR+AlfA@public.gmane.org>
2015-05-28 0:10 ` Guenter Roeck
2015-05-28 0:10 ` Guenter Roeck
2015-05-28 0:29 ` andrey
2015-05-28 0:29 ` andrey
[not found] ` <14d97ec12ae.121e65c4b780118.1307005790953163680-MoRZu3FOBbXQT0dZR+AlfA@public.gmane.org>
2015-05-28 6:11 ` Michael Turquette
2015-05-28 6:11 ` Michael Turquette
2015-05-28 15:24 ` York Sun
2015-05-28 15:24 ` York Sun
2015-06-10 0:40 ` York Sun
2015-06-10 0:40 ` York Sun
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5565108D.2020502@freescale.com \
--to=yorksun-kzfg59tc24xl57midrcfdg@public.gmane.org \
--cc=andrey-MoRZu3FOBbXQT0dZR+AlfA@public.gmane.org \
--cc=lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=linux-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org \
--cc=linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=mturquette-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=rabeeh-UBr1pzP51AyaMJb+Lgu22Q@public.gmane.org \
--cc=sebastian.hesselbarth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.