LKML Archive on
help / color / mirror / Atom feed
From: Haavard Skinnemoen <>
To: David Brownell <>
Subject: Re: [patch 2.6.25-rc2-git 1/2] atmel_tc library
Date: Mon, 25 Feb 2008 12:43:19 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Sun, 24 Feb 2008 17:03:10 -0800
David Brownell <> wrote:

> > Which reminds were talking about a patch that adds oneshot
> > support for the count/compare clocksource and more cleanups, but I
> > don't think I've seen it...?
> I avoid sending non-working patches, and hadn't made time to
> work on that issue recently.

I was thinking that I could perhaps help you get it working...

> > But I was thinking about Linus' suggestions that we exploit the
> > distributed nature of git and do cross-tree merges to synchronize
> > changes to common code.
> >
> > Setting up a separate git tree would allow the changes to go into the
> > arm tree without littering it with possibly unstable avr32 changes as
> > well, and it would allow me to merge them and put more stuff on top.
> Doing that with ARM patches is Russell's call; he hasn't been too
> keen on merging from non-Linus GIT trees when that came up before.

Fine with me either way.

> > I've never really seen the point of indenting those defines at all.
> Without them, it's harder to discern the logical structure of
> all the various bitfields and their contents.

I prefer to separate the registers from the bitfields and the other
stuff. That way, no indentation is necessary.

> > I thought about that, but while the driver can safely call clk_enable()
> > on the same clock several times, I'm not sure if it's such a great idea
> > to call request_irq() on the same interrupt several times. So the
> > driver probably needs to know how many irqs there really are and might
> > as well use platform_get_irq() to find out.
> I thought the whole point of passing the clocks was to avoid needing
> to ask for them!!  If trying one or three platform_get_irq() calls is
> OK, then surely trying one or three clk_get() calls is also OK...

If you want to go down that path, surely reserving the iomem resource
is fine too? Why don't we just kill the whole tclib layer, the driver
can certainly do everything itself?

Of course the driver should be responsible for calling clk_enable() and
clk_disable(). Otherwise, power management will be tricky. And since
the driver may need to make a decision about which interrupts to
request, it might as well call platform_get_irq() directly.

On the other hand, the driver will _always_ need a reference to each
clock, and it will always need a pointer through which to access the
registers, so the mid-layer might as well do those things.


  reply	other threads:[~2008-02-25 11:43 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-23  1:23 David Brownell
2008-02-24 17:45 ` Haavard Skinnemoen
2008-02-24 22:55   ` David Brownell
2008-02-25  0:26     ` Haavard Skinnemoen
2008-02-25  1:03       ` David Brownell
2008-02-25 11:43         ` Haavard Skinnemoen [this message]
2008-02-25 18:06           ` David Brownell
2008-02-26  9:08             ` Haavard Skinnemoen
2008-02-26  9:17               ` David Brownell

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \
    --subject='Re: [patch 2.6.25-rc2-git 1/2] atmel_tc library' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).