From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Magnus Damm <magnus.damm@gmail.com>
Cc: Ian Molton <ian@mnementh.co.uk>,
Guennadi Liakhovetski <g.liakhovetski@gmx.de>,
linux-kernel@vger.kernel.org, Pierre Ossman <drzeus@drzeus.cx>,
Magnus Damm <damm@opensource.se>
Subject: Re: MMC: Make the configuration memory resource optional
Date: Wed, 29 Jul 2009 13:42:33 +0100 [thread overview]
Message-ID: <20090729124233.GA12802@rakim.wolfsonmicro.main> (raw)
In-Reply-To: <aec7e5c30907290527w39a89895n285e932459e6c953@mail.gmail.com>
On Wed, Jul 29, 2009 at 09:27:54PM +0900, Magnus Damm wrote:
> On Wed, Jul 29, 2009 at 8:58 PM, Mark
> Brown<broonie@opensource.wolfsonmicro.com> wrote:
> > While it's true that this doesn't bother SoCs the fact that most clock
> > API implementations don't allow any off-chip drivers to register clocks
> > renders the clock API essentially unusable for fairly large parts of the
> Yeah, clocks outside the SoC are not well supported today. From what
> I've seen, most embedded boards come with external chips for cameras,
> audio codecs and/or phy devices. These devices often get their clocks
> from the main SoC. Allowing the drivers for such chips to use the
> clock framework to register clocks for internal divisors would allow
> driver writers to write better code which in turn would make life
> easier for most people hacking on embedded kernels.
That's not actually abundantly clear for the audio stuff, or rather the
audio stuff would like additional features like constraint based
configuration.
> The problem with the clock framework API is that the data structures
> varies depending on implementation. So the ops callback structure on
> SuperH is different compared to ARM. I suspect that adding generic
> clocklib support across the architectures will take quite a bit of
> time to implement propely.
Indeed. It's actually much worse than you say, each individual ARM
architecture has its own clock API implementation of varying quality and
of course there are architectures that don't do the clock API at all.
next prev parent reply other threads:[~2009-07-29 12:42 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-17 11:10 MMC: Make the configuration memory resource optional Guennadi Liakhovetski
2009-07-17 14:19 ` Magnus Damm
2009-07-17 14:34 ` [PATCH] " Guennadi Liakhovetski
2009-07-17 17:38 ` Ian Molton
2009-07-23 10:29 ` Magnus Damm
2009-07-28 13:55 ` Ian Molton
2009-07-29 2:48 ` Magnus Damm
2009-07-29 10:24 ` Ian Molton
2009-07-29 11:58 ` Mark Brown
2009-07-29 12:27 ` Magnus Damm
2009-07-29 12:35 ` Paul Mundt
2009-07-29 12:42 ` Mark Brown [this message]
2009-07-29 12:51 ` Magnus Damm
2009-07-29 12:58 ` Ian Molton
2009-07-29 13:08 ` Magnus Damm
2009-07-29 13:51 ` Ian Molton
2009-07-29 20:17 ` Paul Mundt
2009-07-29 20:55 ` pHilipp Zabel
2009-07-29 21:03 ` Paul Mundt
2009-07-30 9:59 ` Ian Molton
2009-07-30 10:56 ` Guennadi Liakhovetski
2009-07-30 19:21 ` Ian Molton
2009-07-31 6:55 ` Guennadi Liakhovetski
2009-08-03 18:51 ` Ian Molton
2009-08-05 13:33 ` Guennadi Liakhovetski
2009-08-05 14:10 ` Ian Molton
2009-08-03 2:52 ` Magnus Damm
2009-08-04 18:21 ` Ian Molton
2009-08-05 2:08 ` Magnus Damm
2009-08-05 12:07 ` Ian Molton
2009-08-05 13:34 ` Ian Molton
2009-08-05 19:44 ` Guennadi Liakhovetski
2009-08-05 22:34 ` Ian Molton
2009-08-05 22:53 ` Guennadi Liakhovetski
2009-08-05 23:06 ` Ian Molton
2009-08-18 8:40 ` Magnus Damm
2009-08-09 19:10 ` MMC / MFD / Clocks Ian Molton
2009-08-10 3:48 ` Magnus Damm
2009-08-05 14:02 ` Example idea for how to solve the clock/cnf problem Ian Molton
2009-08-05 22:43 ` Ian Molton
2009-09-02 10:44 ` Magnus Damm
2009-07-30 19:33 ` MMC: Make the configuration memory resource optional Ian Molton
2009-07-29 13:11 ` Mark Brown
2009-07-29 12:59 ` Mark Brown
2009-07-29 12:37 ` Ian Molton
2009-07-29 7:31 ` Paul Mundt
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=20090729124233.GA12802@rakim.wolfsonmicro.main \
--to=broonie@opensource.wolfsonmicro.com \
--cc=damm@opensource.se \
--cc=drzeus@drzeus.cx \
--cc=g.liakhovetski@gmx.de \
--cc=ian@mnementh.co.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=magnus.damm@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox