From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753730AbbE1PYl (ORCPT ); Thu, 28 May 2015 11:24:41 -0400 Received: from mail-bl2on0142.outbound.protection.outlook.com ([65.55.169.142]:23491 "EHLO na01-bl2-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753357AbbE1PYe (ORCPT ); Thu, 28 May 2015 11:24:34 -0400 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=yorksun@freescale.com; Message-ID: <55673328.5050206@freescale.com> Date: Thu, 28 May 2015 08:24:24 -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: Michael Turquette , andrey , Guenter Roeck CC: , , , , Subject: Re: clock driver References: <5564C58B.9050400@freescale.com> <20150527181521.GA19448@roeck-us.net> <55660BF2.6000002@freescale.com> <20150527185442.GA6607@roeck-us.net> <556613CE.8020906@freescale.com> <14d96cd6d64.f62a1a09739217.9114963256886461171@elphel.com> <55664E5C.3000903@roeck-us.net> <14d97d05f05.c0c23a8c778110.9087956443203424916@elphel.com> <55665CDE.7060601@roeck-us.net> <14d97ec12ae.121e65c4b780118.1307005790953163680@elphel.com> <20150528061121.22384.20782@quantum> In-Reply-To: <20150528061121.22384.20782@quantum> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [192.88.168.49] X-ClientProxiedBy: SN1PR12CA0004.namprd12.prod.outlook.com (25.162.96.142) To BN1PR03MB155.namprd03.prod.outlook.com (10.255.201.24) X-Microsoft-Exchange-Diagnostics: 1;BN1PR03MB155;2:1sT63NYmW6U3epzegQCMq4P8lZukRQ/Var2QX/vpaDVFKEKIAfyJvKI/mkO/KDJG;2:K5s8onGGzGdaJTaA1aKNIaGMIzrc2zIyjwxXeeG5+BqWFyk6k17ISww18D+nVArEI7YGzNegngjcIzq+wg0N4e7rkAzp4r67kGgD/JqZYj2WLOKumTU2ojKZkz8FOBmR+YO1a2L+Bq3NUUNT7IIZDw==;6:Lv7pSwzlxzw7PQewPngc9VFggkfXvdSLavDg8R7MedixjBzKs+gWBM7/z0VH4vni6VgIeMzQDoZmxvmczKoeFVdKwnW4iXP06oC+oIx8zcMdj8efZRbCtLmHEAo6849k5iIDX1a3fflmdZq7eUKemQ4iMoEBBN71JYTsOfJC6Ib+puL24vLGX4Z1NEbaG3gd3Cp2dXdCnaI13wjyzUZU4oQm7lLu7JbVhf36Ov3dOXNT+aa5uJjWoMLbPmWZpGacVNKCeVam9OJFIW7agAwCgLzaVJge+0TVSxCMqiXfi+0VgFAXV036cEEOtXkVMpE888o+9NA2CvZzw7Z9f/sez6rsRMv+sX02UpiFckDCn+2PfbbKfgw4MqRqTSOYvdUH5Plqva4Mjkj3UWMIiffutPtQcb2K9UK4kVMFGa4bLGrb+iUDTg/rw65DxqMElwtLqWeDkhN9HYsRP2Fzy6Xt6fEYV5zYuH5j3Rydyn2N+dfW4YynYu2uvptAFyjJuAp31eTW+xDuEc+HUi0GCVDf1XG9nvHd0GBuUwj/0d/mtBWJKSOrg1vGH2ESB+dWLqyuVQ1o0FWVc+al6jBr93ZzEeeCfI/bnTQPnLHnpGXByrU= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR03MB155; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(5005006)(520003)(3002001);SRVR:BN1PR03MB155;BCL:0;PCL:0;RULEID:;SRVR:BN1PR03MB155; X-Microsoft-Exchange-Diagnostics: 1;BN1PR03MB155;3:axbpBadz1o4pQ4XdD1nnH8z6yZLpX33h9BoidVuZjiPYvuOYg3hmfVkOgBw9kRqV5iBPTM/wI3PRZ6/S2cZQ4E9dB6JQphhI4618jrnMD/SjNSw1Da3KEsZSy6/TkgCJ3S8da3Q9Y81f9XhxwPa/ATUH5kA7XOfDmdFjKnuDXNsO5BSOPoFL1qFi7fO1xXvVusc5392roI8f0ZhOjPuI4yORNZ4DlSEae/xgK3hSVb31eDUkOiZs/qNPcMp9bQGdTnakh5LIJtd+s4zkq6NhxYkNUFCqhqofr9NUCKu9mPjihyMJXP3I5x7Umefhs95l X-Forefront-PRVS: 0590BBCCBC X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10019020)(6049001)(6009001)(51704005)(189002)(24454002)(51914003)(199003)(377454003)(479174004)(19580405001)(83506001)(66066001)(65956001)(221733001)(50986999)(64706001)(47776003)(19580395003)(99136001)(76176999)(65816999)(54356999)(87266999)(23676002)(46102003)(93886004)(5001830100001)(5001860100001)(68736005)(5001960100002)(15975445007)(62966003)(77096005)(77156002)(122386002)(2950100001)(40100003)(4001540100001)(4001350100001)(81156007)(189998001)(5001770100001)(97736004)(59896002)(117636001)(575784001)(86362001)(105586002)(87976001)(101416001)(64126003)(42186005)(65806001)(106356001)(50466002)(92566002)(36756003)(111123002)(62816006);DIR:OUT;SFP:1102;SCL:1;SRVR:BN1PR03MB155;H:[10.214.80.244];FPR:;SPF:None;PTR:InfoNoRecords;MX:1;A:1;LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTjFQUjAzTUIxNTU7OTptenVwRnNtOGp1OHNPZ0ErZUhQWXVGL1RJVHcv?= =?utf-8?B?NzdnTjRNQVdTSllRZlVNU2J1R2dHdU1QWnlianhKSnZzWmc3ZDRQNnVzOHVw?= =?utf-8?B?djdIdHdQWFNkQzdjUy9MWVBWcTY2T2dvejR1aC9BdERkR2NBSWRLb283NW12?= =?utf-8?B?N1hCcVc1akJBQVRnMm42REJ3SGpOdG95UnRUemRFZGl3VWFSM24wajNGNGdH?= =?utf-8?B?RWVSQ2o2RkFMNTBvbjNZSXJ2QS9PVFZlSm4zYStSbDA5Q2w0VzA4ZERSeHRr?= =?utf-8?B?cnNyVTFzTE12QUUreXl4WXM0NU0vYXFPRnlrTkFCa3dmMVRzTHg5RlpPUXB4?= =?utf-8?B?QU9nSWV3cUpISEtac0ZVb1drbWJyRHhMblVwQnUxT0xkZ3BTL2xLWGRBRk9K?= =?utf-8?B?UVdQOGhkY1ZPM25tbi81SGV3cUtsS3pCejRHVFQvU0Y5RUpBUFpGYS94NDFw?= =?utf-8?B?QXphSHF2aWF0SGk1Q1pRSzdaQng3bjAreFBjcE1lSGIra2VaZjdNem9UVk1a?= =?utf-8?B?VlBaMW1zeEM0R3A0MXl0bVQ1MFVWUFhsbHFRbDU2OGp3bWwvQ2l6eGJaUnlv?= =?utf-8?B?UkRielFIdm9yWkN6Ri9SL25VRVhyc3Y5VzhEcHpzamIvMC9SUkVqUm0vV3B4?= =?utf-8?B?UTBmdTdjc0FlSzViWEQ3ekEzWVhjYWlXNXNPdVk5VlZWNnF2eW9iUjRuckhD?= =?utf-8?B?T3ZTV0h0c0ZKZm0rSG5kVnlJWmRyV2NYSVJYUzJDR3NLajBQaHM1L3BxK0Fj?= =?utf-8?B?Ly8wRFBSejBEOWhtb3NwSTVOa3QvZXdxY1hTdVo1US9QU3d2dWFZbkhiLzdh?= =?utf-8?B?LzVyWGlremErV0RMcU5SZ1VQaDd3L1VHTGNyNUVsTnlyMVZoTHhERzVqRnYr?= =?utf-8?B?YTU2czlRWk9RVmdEcmRicmV0a21SRDgvd045NTF3NndSWXh1NGtqK2dPMENi?= =?utf-8?B?VzhJQVU3SkNmeTBVZzBSdDRkb1FVUURacm9KbkhzQS96SGVzU2dZRWRzZDh5?= =?utf-8?B?bFRob3ZqeFkxWEpsNU9pUmluR0FEQXNTdFdBa2dnWFhaUkowZkp1SXdSQ1pE?= =?utf-8?B?RW9FOHk0MjAwV1RRWE00UHVaYXphYlhXdUgySktiVjRiUnFPeHZBMk45ZURq?= =?utf-8?B?eXdOZ3dWNGt0cjBqOUxqalpTL0VWQUphalRKelRFUVF6UCs0L3VJdUM2Nmto?= =?utf-8?B?cEx0ZVZzUGVKTzZXMWx2Y2tpMHpCWlJKazhIWDJtd0dsaFpoc3FCZTZLZkRm?= =?utf-8?B?SXUyeVcrelRGNlVudjVlSituTkpXUFBjQUx3TlNZbnRnVWU5VU9BUHJSRHg3?= =?utf-8?B?UHM2TGxLUDg5d256aUp5OS9IdUZSTUl1ZlE5V3g2cEhvenFGMCt1bTJnWWZX?= =?utf-8?B?cjFEcmVmZFlWdjBROE84MVlDcU1lb0xqZGt2Mk1OaklKU3dVZmx3cmJIQUFX?= =?utf-8?B?andRQUdxdXAwWlExTFJFNXVnd2ZnMU9hd25GdTk5MHRSbUl6OXJnR1kvOWVL?= =?utf-8?B?eGNiNVpHRUtGeXlxOWQ5dmxnR3ZRTlRnSlBkWmpYUFRBK3FyTTlkOE9ZT0lK?= =?utf-8?B?ZVNYS0lMQXZEUk1DT0dUb3lKQzZtUWYyYnRHRG1NUEhyYnkreVhTS3p4MURz?= =?utf-8?B?TWd5TityV21OTnJvSGc4RDRyNSs5aG92ODR3WHpRaGRjOFZGZTVRUFIrays1?= =?utf-8?B?VzRsaHZtZkJObWovQ2ozNGRPRnZNWUFXeUZ5WVQ1VzR4OXZSeTFRYjNqNjh1?= =?utf-8?B?d1E1VzFBampUcnpDbWFNZnV0M3hpSHkzWllVNFh0NE15Qk9uM2pySzd6V0wv?= =?utf-8?B?MDVJTDVHeGkvUzVWUlEyM25lQ1BneHpRNVZDcnNpK3dnTC9aSkJreHdVWUM2?= =?utf-8?B?Vnk3aVlLZDFNelFmMGtPSUZmY1hGL0g5aTBYVjd2KzdZcEpsTFNxR1dOWVNH?= =?utf-8?B?dlFFN256Y0pJSDZZd1dqeFZlSlc4bGRYSjBmbE5mSHpBY2J4MkZWeVE4WDND?= =?utf-8?B?NkhTOUdOZ0ZGK3VmQ0wyT0pqd0VJTE1yYTAyeklxdk1mb2hJRFpNbDdJbDI2?= =?utf-8?Q?3k=3D?= X-Microsoft-Exchange-Diagnostics: 1;BN1PR03MB155;3:ftYyQUhcdHOKdj3bj+xuc8PgS6Jgpq8WRHmz/xWno1x98MifVlJZhjoH90mAqywAsz6nD7YBmS/UCma17oBMXbxdnpaOboe2hhdveq/QZGcigxADVCavpGFMKSf1qDVKLdGAGsq3Uc7c5A04cB2smA==;10:rzRMZl7UlRqEvSCG+M4rCRW9w3PyI+mo12bR7AGMfE5eayGTJggzBduaORMwSUY4XrTcK/15GCDlk+jxKSEEENt//QU8zhNxkZ7bM5Oe8/A=;6:EK3rDRESYBptllviZt5WhiNwti43oVLBKB0GSkbI08hLgdlgSRuyFedOioXsHUVX X-OriginatorOrg: freescale.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 May 2015 15:24:29.9600 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR03MB155 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/27/2015 11:11 PM, Michael Turquette wrote: > > Hi Andrey, > > I think this is a cool problem to solve. As far as frontier devices go I > really can't say. Other companies create similar clock generators that > are programmed at run-time over i2c. And we already have support merged > for Silicon Labs 5351 and 570 devices: > > drivers/clk/clk-si5351.c > drivers/clk/clk-si5351.h > drivers/clk/clk-si570.c > > I'm not sure that we need to group such devices into a new "class". The > Linux common clock framework (ccf) has two classes: clock providers and > clock consumers. We haven't needed any more classification than that > thus far. > > I took a look at your github code and it looks like you expose registers > individually as sysfs files. That is a start, but a better abstraction > 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 configure > them for consumption by the downstream fpga. > > According to the data sheet[0] it looks like there are not many clock > outputs (CLK0{A,B}, CLK1{A,B}, CLK2{A,B}, and CLK3{A,B}). > > At what point do you know how the clocks should be configured? I am > guessing that your fpga driver (e.g. the clock consumer) figures that > out as bytestream blobs are loaded? So that seems like the right call > site to start enabling clocks and configuring rates, instead of stuffing > that into the silabs driver (e.g. the clock provider). I think it works for my case. I will explore this direction. > > York, > > There is already a way to clock drivers to extend the debugfs interfaces > for per-driver stuff. The Nvidia Tegra guys do this already in their > out-of-tree test modules. Do you think such an interface might be > helpful to you? See: > > clk_debugfs_add_file in drivers/clk/clk.c > and, > http://lkml.kernel.org/r/<1403794853-16928-1-git-send-email-pdeschrijver@nvidia.com> > > So your silabs clock generator driver could export some custom knobs > which help out in the early phases of development. > > Ideally this interface would not be a register-level interface, but an > output signal type interface. Here is an example of the files you will > have by default: > > $ ls /sys/kernel/debug/clk/clk0a/ > clk_accuracy clk_flags clk_phase clk_rate > clk_enable_count clk_notifier_count clk_prepare_count > > With the custom debugfs interface you might add a "clk_set_rate" file > where user space can write to it and change the frequency of that clock > signal. You can do the same to change mux settings and clock gates as > well. > > A userspace tool might even be able to take the clockbuilder data to do > this, if someone is willing to write it. > > [0] https://www.silabs.com/Support%20Documents/TechnicalDocs/Si5338.pdf Thanks for the suggestion. I think I can limit the features of this clock chip and fit it into CCF. Earlier I thought too much about exposing all features for general use, which shouldn't be the case for the clocks. I will see if I can remove those features or reserve them for debug use. York