linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: jeremy.kerr@canonical.com (Jeremy Kerr)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC,PATCH 1/2] Add a common struct clk
Date: Thu, 3 Jun 2010 11:21:19 +0800	[thread overview]
Message-ID: <201006031121.21896.jeremy.kerr@canonical.com> (raw)
In-Reply-To: <20100602120356.GQ7248@trinity.fluff.org>

Hi Ben,

> > And a set of clock operations (defined per type of clock):
> > 
> > struct clk_operations {
> > 
> >        int             (*enable)(struct clk *);
> 
> I'd rather the enable/disable calls where simply a set
> and a bool on/off, very rarelyt is the enable and disable
> operartions different.

I thought about merging these, but decided against it. It does work for the 
simple case where we're setting a bit in a register:

static int clk_foo_set_state(struct clk *_clk, int enable)
{
	struct clk_foo *clk = to_clk_foo(_clk)
	u32 reg;

	reg = raw_readl(foo->some_register);
	if (enable)
		reg |= FOO_ENABLE;
	else
		reg &= ~FOO_ENABLE;
	raw_writel(foo->some_register, reg);

	return 0;
}

However, for anything more complex than this - for example, if there's a 
parent clock - then we start getting pretty messy:

static int clk_foo_set_state(struct clk *_clk, int enable)
{
	struct clk_foo *clk = to_clk_foo(_clk)
	u32 reg;

	if (enable) {
		int ret = clk_enable(clk->parent);
		if (ret)
			return ret;
	}

	reg = raw_readl(foo->some_register);
	if (enable)
		reg |= FOO_ENABLE;
	else
		reg &= ~FOO_ENABLE;

	raw_writel(foo->some_register, reg);

	if (!enable)
		clk_disable(clk->parent);

	return 0;
}

- where most of the function becomes surrounded by "if (enable)" statements. 

I'm aware that we can turn this into a conditional call of clk_foo_enable or 
clk_foo_disable, but then we're back to square 1. I also think that the simple 
case is clearer (if a little more verbose) with separate functions.

Also, enable and disable in the external clock API have different return 
types.

> an aside, you might want to just clal these clk_ops to get into the
> spirit of the original naming.

Either is fine with me - looks like 'ops' is more commonly used:

$ git grep -E '^struct \w*operations\s*\{' include/ | wc -l
30

$ git grep -E '^struct \w*ops\s*{' include/ | wc -l
138

Cheers,


Jeremy

  reply	other threads:[~2010-06-03  3:21 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-02 11:56 [RFC,PATCH 0/2] Common struct clk implementation, v3 Jeremy Kerr
2010-06-02 11:56 ` [RFC,PATCH 1/2] Add a common struct clk Jeremy Kerr
2010-06-02 12:03   ` Ben Dooks
2010-06-03  3:21     ` Jeremy Kerr [this message]
2010-06-03  8:13       ` Ben Dooks
2010-06-03 10:24         ` Jeremy Kerr
2010-06-03 11:05           ` Russell King - ARM Linux
2010-06-04  0:06             ` Ben Dooks
2010-06-04  1:43               ` Jeremy Kerr
2010-06-04  1:40             ` Jeremy Kerr
2010-06-03 21:09         ` Ryan Mallon
2010-06-03 23:45           ` Ben Dooks
2010-06-02 11:56 ` [RFC,PATCH 2/2] clk: Generic support for fixed-rate clocks Jeremy Kerr
  -- strict thread matches above, loose matches on Subject: below --
2010-06-04  7:30 [RFC,PATCH 0/2] Common struct clk implementation, v4 Jeremy Kerr
2010-06-04  7:30 ` [RFC,PATCH 1/2] Add a common struct clk Jeremy Kerr
2010-06-11  4:20   ` Ben Dooks
2010-06-11  6:50     ` Benjamin Herrenschmidt
2010-06-11  7:57     ` Jeremy Kerr
2010-06-11  8:14       ` Lothar Waßmann
2010-06-11  9:18         ` Jeremy Kerr
2010-06-11  9:23           ` Lothar Waßmann
2010-06-11  9:58             ` Uwe Kleine-König
2010-06-11 10:08               ` Lothar Waßmann
2010-06-11 10:50                 ` Jeremy Kerr
2010-06-12  5:14                 ` Benjamin Herrenschmidt
2010-06-14  6:39                   ` Lothar Waßmann
2010-06-14  6:40                     ` Uwe Kleine-König
2010-06-14  6:52                       ` Lothar Waßmann
2010-06-14  9:34                         ` Uwe Kleine-König
2010-06-16 21:14                           ` Ben Dooks
2010-06-16 21:13                         ` Ben Dooks
2010-06-14  9:22                     ` Benjamin Herrenschmidt
2010-06-14  9:30                       ` Lothar Waßmann
2010-06-14  9:43                         ` Uwe Kleine-König
2010-06-16 21:16                           ` Ben Dooks
2010-06-16 23:33                             ` Benjamin Herrenschmidt
2010-06-13 22:27                 ` Ben Dooks
2010-06-11 14:11               ` Uwe Kleine-König
2010-06-12  5:12             ` Benjamin Herrenschmidt
2010-06-12  5:10         ` Benjamin Herrenschmidt
2010-06-13 22:25         ` Ben Dooks
2010-06-13 22:23       ` Ben Dooks
2010-06-14  3:10         ` Jeremy Kerr
2010-09-10  2:10         ` Jeremy Kerr
2010-06-14 10:18     ` Jeremy Kerr

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=201006031121.21896.jeremy.kerr@canonical.com \
    --to=jeremy.kerr@canonical.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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;
as well as URLs for NNTP newsgroup(s).