From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752195AbbE0SZL (ORCPT ); Wed, 27 May 2015 14:25:11 -0400 Received: from mail-bn1bn0102.outbound.protection.outlook.com ([157.56.110.102]:13173 "EHLO na01-bn1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752084AbbE0SZA (ORCPT ); Wed, 27 May 2015 14:25:00 -0400 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=yorksun@freescale.com; Message-ID: <55660BF2.6000002@freescale.com> Date: Wed, 27 May 2015 11:24:50 -0700 From: York Sun User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Guenter Roeck CC: Michael Turquette , , , , , , Subject: Re: clock driver References: <5564C58B.9050400@freescale.com> <20150526223829.GA26454@roeck-us.net> <55650DBA.5000304@freescale.com> <5565108D.2020502@freescale.com> <20150527173055.22384.74368@quantum> <556602BC.6040203@freescale.com> <20150527181521.GA19448@roeck-us.net> In-Reply-To: <20150527181521.GA19448@roeck-us.net> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Originating-IP: [192.88.168.49] X-ClientProxiedBy: SN1PR15CA0005.namprd15.prod.outlook.com (25.163.200.15) To BY2PR03MB157.namprd03.prod.outlook.com (10.242.36.12) X-Microsoft-Exchange-Diagnostics: 1;BY2PR03MB157;2:RSDzsKYApHozlZ44TQz5wvaDgQI/K23F5ICDJDzK3uATC6T9NgsmWHw4J6b9hgJl;2:bxwWvCIFQ+dhnmvr8JVijiLMDJcT2HfZx4U8RlDpLDUXwr8eaSi70Vh41Awms1XkM0A/oT3YCqpidgpv3fb/4umhNvLKqjxPc0LGwL/S8dHb8Wzlr6Eo1RhT4C+24FVJPfcR8+K9kManb7H165Wzww==;6:hkgxpbCcnrQH4oUxyJrBDjA2kwpPwZqJZznEYJoh/FcEy0pM7sxahwB1hgUPGN5nXBwUmfgr1i2iWBhwlBm/EMAeZ1DK+0un3ldSPX8swHVYnYo9WRWbeRsSgXQcfWJuoWJIIFsFBT0eYrVUmTjU41Q7UGZqFNljxBb8nd0GfB/t3kbXczJH7BNZsoVeC5xyNPBtVHwztoanKtgoihvVXXePLCVKprMGQ0fQ6wxVx7GCIz8e/gt7pGASyXEFI2Ic01aPHwU+hwckfB4qv1rP4yB67vJxF2xRx8VHXt5AX03fnaJGq7hlQhpakDBUEiqsRmY+BtaPo21BLeFFmbWfpCCgajzGEuV9oRMzyKvyzUddrDf95V+DN7dE9GjaQoOuMg5oy9oaxzXw6W4k316LQ+Ys0AC7mpto7JCUcTvrEV8ZKtXcQ720JAl+uYkfJmORmQqsm+acx1hKAwnWxT+6oi1f3GPEWmYmnl5G87gL84u3Ev20bOA1VDTasPHZ3w4TrKkukEuVZnmE+K4zaaY1FyLFPkLRvKU2bb6fbilNCvZrKM+cl610ePNxDsDDPLI4Sqrv7vTBoNh+i5KOtaJ+AyzePysiT3GTRkG9W6k1lNk= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB157; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(520003)(5005006)(3002001);SRVR:BY2PR03MB157;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB157; X-Microsoft-Exchange-Diagnostics: 1;BY2PR03MB157;3:paLgLyUXRBGwsJyRwN5Tu+Di8eP272eYNgA2t5fHXPry3L32OJHCZ0HNMkQVeOQ81z8Fp0lu0zodfiE29KnZBPEdKTpiOdcS6MiI19X2uy7ralj9NQl2hlCv4ENZnto5nmWFijm4lfhDKtjIUy4X5rGqtqrQgkFOHABG4Qt37CgI9Zw9QA97MTORaxmo2e0Ls8Ir6n62uwhNjyVOSNNGJW4SW/84B6uOS1yWGYD9u+bZA+6Ciwsdx5xHz838EzS/r67Nzjn3HbN2gMgcc1hHK/yhG1p+Ml302xFybrWPXf1oNNZROj6PVcPEcg5d9T8N X-Forefront-PRVS: 05891FB07F X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10019020)(6049001)(6009001)(377424004)(377454003)(199003)(51704005)(501624003)(479174004)(54094003)(189002)(24454002)(33656002)(23746002)(105586002)(64126003)(65816999)(76176999)(86362001)(99136001)(80316001)(87266999)(54356999)(106356001)(50986999)(83506001)(50466002)(87976001)(19580395003)(42186005)(59896002)(101416001)(65956001)(5001830100001)(66066001)(97736004)(65806001)(77156002)(62966003)(36756003)(64706001)(15975445007)(221733001)(5001920100001)(2950100001)(4001350100001)(4001540100001)(77096005)(5001860100001)(81156007)(122386002)(46102003)(110136002)(68736005)(92566002)(47776003)(189998001)(93886004)(5001960100002)(40100003)(111123002);DIR:OUT;SFP:1102;SCL:1;SRVR:BY2PR03MB157;H:[10.214.80.244];FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1;BY2PR03MB157;9:toLTJdVtLKvzHi7QNqttQ8/h4wqBF6+X0BPjSzd?= =?Windows-1252?Q?Jk6Jcj2UQ55hNGI2MYeD5tRqIF+/UzAHauzqj3mSJEkACUkC9pkHH4EF?= =?Windows-1252?Q?G7mKZULbN3Lsm+b/aFF3xNfzQmePFj0591EemWOKWEnVnZ7FF/ibQYIC?= =?Windows-1252?Q?AV4EIBuLA5PJy1zqzwMLRL+0khduT9gL7iILibrrYqvaww+527XAnRqf?= =?Windows-1252?Q?NyNLPKSXcRucLn+ftWuMHIn31jUwFjDQTNwkLOBmNGlagjO8h88Q8o06?= =?Windows-1252?Q?RwPChY+dEpaie9YyxfX17q+jsiS+vFV5eDYjHuLCOOJN1gX2UCO0UJ0X?= =?Windows-1252?Q?O4zzIN6+7r5nj344yMchS5eWbg+X4RlWRSOlYBtjFR1XQNV5bAImF7KC?= =?Windows-1252?Q?Ub9wxwtFj73oiNtWhP/XfQEseonq+G7MSi0yFT9LJ3X4fq1JHM+FfLsK?= =?Windows-1252?Q?pfCwAxpgLIHNpT+NooJDEttONt2MgaCc4iOYl14+XpezoK7EHDk7F9jy?= =?Windows-1252?Q?CYiINP4TG5TPr3Rl4nLrJpcEQ59+tNUtdixQrbernJXvel2tNDKek6PZ?= =?Windows-1252?Q?ZiAigbNBtwRqSK9er4wX8B03upvUoWqju8pR3XQwnYQcSbmG2+rz/201?= =?Windows-1252?Q?j9RzduTXud+FOP/fPKSx8v59ui/jbHXGQ72Xxzzl0MljmLzFQwX7woGS?= =?Windows-1252?Q?JEIPhsETYBU+uYyW4nf8LJyDxsYqqgJEOx7ybelwqa6KPcgqKU5k/d2e?= =?Windows-1252?Q?iKSryZdBYt5Q2xcF5rZho4EfnjV0FTgWQntPrK38jlkpnX2APopc2dZA?= =?Windows-1252?Q?aTtfx8r/QXsriYcYay0mwHh6yxL2BqBjy9hvO/bAiIblmou3s3q2j6Pt?= =?Windows-1252?Q?9KQK4DumZNGrKD7qDpYUKAau8YYOxPypm/qHNnXxWIs2OetkpUBNxbK8?= =?Windows-1252?Q?0Tcz59SwWTStWw3eVtTbTA1AUKin09R+Vpi4TP+IhoxSArMBS1rp678Y?= =?Windows-1252?Q?viTqKHnocngr0twcMpo2J3eATPJtpp/6bRlxukEB4gbgiJlc+um5mJXL?= =?Windows-1252?Q?Hxsvr8eIgt3bKxGXcDyY29mWEVR5csGjv3kg/rvjBpcnY7WWDfWb0V9M?= =?Windows-1252?Q?jsHaPQmBmI29RneMaKXekSrBdkfRD60u6jymzFIjHiOe+4eDbii30Q58?= =?Windows-1252?Q?4bOw0sRB5YPC7hd0a4YHbma15Za3Bh3fI1kObu9D3NY1wVPAQmY0h8FY?= =?Windows-1252?Q?wEIApkULI2UKSyruNIEpZRBXcr9Grtw8sKP+SGHzDr8AcjHno3r1z6wM?= =?Windows-1252?Q?Vex+5ro+vYgO6TL3GIja1egPvbbMGJEibm6YLBKAkUXlgvV7cnuNmqaW?= =?Windows-1252?Q?TXm2YEjydJ/IdFKdMAIQ6MgFdYkqXXQVjIuCoXANirMxWO1R0DbvZEET?= =?Windows-1252?Q?nj0Y3mknASqcUXL+QdEq3rc2D+IjE/n3y2BCX77hVbrAGi/XEy1luZ2M?= =?Windows-1252?Q?jgMh7iGvpg7UGz/VrFVMbKxTRMwXzKF+q/wwV3JShj6l95GlN7Lfk4bV?= =?Windows-1252?Q?wlzGTYvXvLLxpqbvPV9vZajNT2UeTKtthDxSOboECDGtL2eH9kIGzVbp?= =?Windows-1252?Q?V58HebuvRRxCJynXMDcoAvPh7Us/1HUnleOrcWI61?= X-Microsoft-Exchange-Diagnostics: 1;BY2PR03MB157;3:YE6c95VO3UOCTryadTINEW6cWzvP0a73jK3R6VBRWPZi6jtjgbv0NGDzsKmsMslv19nWoyL3akgKhDUqECgG1yRJSyVHy553mDROkbd/XDKtGRBUFbevjOKmuaiFNxE2DrYJ0aDP3jkVA4ID+pmKnA==;10:H13Muxqc4cRSPcQh+yAWyC/2no/hOZRETdqrhDDeSeRUrwozARCIVkEqkavRImq+oZEu4nkqb8pJDlAqcUsZgjttcu/fNu6NGJDjQPNraeU=;6:9sg/TH0qe8rrhSxeCrMvZO+0Cd9lNsP9J3Wuhz/BG8GfkwUtmciR94SDJDhJsG0+ X-OriginatorOrg: freescale.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 May 2015 18:24:55.7982 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB157 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/27/2015 11:15 AM, Guenter Roeck wrote: > 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 am interested in this path. Can you explain a little bit more about setting the clock rates? I have no experience on CCF. > >> 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. > >> 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. York