From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1765789AbYDYVgW (ORCPT ); Fri, 25 Apr 2008 17:36:22 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1762529AbYDYVgO (ORCPT ); Fri, 25 Apr 2008 17:36:14 -0400 Received: from rv-out-0708.google.com ([209.85.198.250]:33733 "EHLO rv-out-0506.google.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1762685AbYDYVgN (ORCPT ); Fri, 25 Apr 2008 17:36:13 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=rFG9hyv7x4rSwBYylTFHLt+zQcyqKlzwJjENO7TS9bPaEFPl7cvNiO4LXAeH0nfVYXFfv+/ubSpjJgdKcnvZAns3neUGoXlgZdByfxzq3jzHKURmjw1LvMt0nl2932LMOUtwbOzoLZVrUh3cH54too4RqidD7IxyHF2lDT2O6/c= Message-ID: Date: Sat, 26 Apr 2008 01:36:10 +0400 From: Dmitry To: "Russell King" Subject: Re: [PATCH 0/5] Clocklib: generic clocks framework Cc: "Pavel Machek" , "Paul Walmsley" , linux-kernel@vger.kernel.org, akpm@linux-foundation.org, "Haavard Skinnemoen" , "Paul Mundt" , "pHilipp Zabel" , tony@atomide.com, "David Brownell" , hiroshi.DOYU@nokia.com In-Reply-To: <20080425211343.GD28893@flint.arm.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080420082925.GA32739@doriath.ww600.siemens.net> <20080425103942.GC14903@elf.ucw.cz> <20080425202010.GA28893@flint.arm.linux.org.uk> <20080425205151.GA6251@elf.ucw.cz> <20080425211343.GD28893@flint.arm.linux.org.uk> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, 2008/4/26 Russell King : > On Fri, Apr 25, 2008 at 10:51:51PM +0200, Pavel Machek wrote: > > Hi! > > > > > > WTF? There are currently around 10 copies of clock code in the tree, > > > > every one slightly different. If this can help us get rid of all that > > > > crap, that's a GOOD THING, normative or not. > > > > > > At the expense of people going off and inventing their own APIs because > > > they find that the "normatived" clock API doesn't do what they need to? > > > > Just now, everyone just cuts&copies clock.c. I do not think "new" > > situation can worse than that. > > That's certainly not what I've seen going on. Each implementation is > customised to the needs of the SoC it's running on - OMAP has a complex > implementation, whereas simpler SoCs have a more simple implementation. > > That's an entirely reasonable state of affairs - those who need complexity > are able to have it, whereas those who don't need complexity don't have > to be lumbered with it. > > It's a long way from a "cut and copy" situation you're trying to suggest > it is. Certainly on ARM, your viewpoint does not hold. Actually it is "cut and copy". I once have examined all arm clock subsystems and converted most of them (excluding OMAP, at91, maybe some others) to the clocklib. There is more code duplication that one would think. E.g. DaVinci clock.h contains a few flags definitions, that are totally unused by the code (most probably direct c&p from omap code). I don't understand why do you give such strong oppression to these patches. Simple systems (like sa1100) will be reduced just to few lines of code. Mediocre (like pxa) will be again highly reduced in terms of size, maintainability, etc. And highly comliex (like omap) do already provide some type of framework like clocklib. -- With best wishes Dmitry