Date: Thu, 30 Oct 2008 20:08:54 +0000
From: Mark Brown <broonie@sirena.org.uk>
To: Jonas Bonn <jonas.bonn@gmail.com>
Cc: linux-kernel@vger.kernel.org
Message-ID: <20081030200851.GC13678@sirena.org.uk>
References: <7a6abd110810300741wf73f838laa3754e23c22baf3@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <7a6abd110810300741wf73f838laa3754e23c22baf3@mail.gmail.com>
User-Agent: Mutt/1.5.17+20080114 (2008-01-14)
Subject: Re: [RFC] API for system clocks (oscillators)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1101
Lines: 22

On Thu, Oct 30, 2008 at 03:41:17PM +0100, Jonas Bonn wrote:

> I'd be happy to get some feedback on this, whether or not it is a good
> idea or even the right way to approach this problem.  This is part of

Something like this would certainly be very useful for audio clocking if
it could be made to fit - that can get complex, is partly off-SoC and
frequently has multiple interrelated clock sources available, often with
various hard to describe interdependencies with constraints coming from
multiple sources and changing dynamically at run time.

In general your problem statement looks fairly sane.  I've not reviewed
this in detail but do think you should have a look at the OMAP stuff.

One thing to watch out for is that you'll find clocks doing things like
originating in one chip, going through another and being fed back into
the original chip.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/