SUPERH platform development
 help / color / mirror / Atom feed
From: Paul Mundt <lethal@linux-sh.org>
To: linux-sh@vger.kernel.org
Subject: Re: [PATCH 2.1/5 v2] ARM: mach-shmobile: R-Mobile A1 support.
Date: Mon, 07 Nov 2011 04:38:45 +0000	[thread overview]
Message-ID: <20111107043844.GA3927@linux-sh.org> (raw)
In-Reply-To: <8739e0srjd.wl%kuninori.morimoto.gx@renesas.com>

On Sun, Nov 06, 2011 at 04:30:17PM -0800, Kuninori Morimoto wrote:
> +enum {	DIV4_I, DIV4_ZG, DIV4_B, DIV4_M1, DIV4_HP,
> +	DIV4_HPP, DIV4_S, DIV4_ZB, DIV4_M3, DIV4_CP,
> +	DIV4_NR
> +};
> +
For enum definitions I generally prefer:

enum {
	...
};

rather than bringing the definitions up to the enum line. This keeps more
in line with structure definitions and so on as well.

> +#define DIV4(_reg, _bit, _mask, _flags) \
> +	SH_CLK_DIV4(&pllc1_clk, _reg, _bit, _mask, _flags)
> +
> +struct clk div4_clks[DIV4_NR] = {
> +	[DIV4_I]	= DIV4(FRQCRA, 20, 0x6fff, CLK_ENABLE_ON_INIT),
> +	[DIV4_ZG]	= DIV4(FRQCRA, 16, 0x6fff, CLK_ENABLE_ON_INIT),
> +	[DIV4_B]	= DIV4(FRQCRA,  8, 0x6fff, CLK_ENABLE_ON_INIT),
> +	[DIV4_M1]	= DIV4(FRQCRA,  4, 0x6fff, CLK_ENABLE_ON_INIT),
> +	[DIV4_HP]	= DIV4(FRQCRB,  4, 0x6fff, 0),
> +	[DIV4_HPP]	= DIV4(FRQCRC, 20, 0x6fff, 0),
> +	[DIV4_S]	= DIV4(FRQCRC, 12, 0x6fff, 0),
> +	[DIV4_ZB]	= DIV4(FRQCRC,  8, 0x6fff, 0),
> +	[DIV4_M3]	= DIV4(FRQCRC,  4, 0x6fff, 0),
> +	[DIV4_CP]	= DIV4(FRQCRC,  0, 0x6fff, 0),
> +};
> +
I'd prefer that we simply stick with SH_CLK_DIV4. All of these wrappers
to wrappers are just irritating, regardless of whether it helps cut down
on a bit of screen real estate or not.

The whole reason we have SH_CLK_DIV4 is to already make things less
verbose, I don't see any valid reason for wrapping it a second time.

> +#define MSTP(_parent, _reg, _bit, _flags) \
> +	SH_CLK_MSTP32(_parent, _reg, _bit, _flags)
> +
Likewise for these.

> +	/* detect RCLK parent */
> +	switch (md_ck & (MD_CK2 | MD_CK1)) {
> +	case 0 | 0:
> +	case 0 | MD_CK1:
> +		r_clk.parent = &extalr_clk;
> +		break;
> +	case MD_CK2 | 0:
> +		r_clk.parent = &extal1_div1024_clk;
> +		break;
> +	case MD_CK2 | MD_CK1:
> +		r_clk.parent = &extal1_div2048_clk;
> +	}
> +
I'm a bit confused as to what the point of the | 0 stuff is. Why not
just:

	switch (md_ck & (MD_CK2 | MD_CK1)) {
	case MD_CK2 | MD_CK1:
		...
	case MD_CK2:
		...
	case MD_CK1:
	default:
		...
	}

> +/* SCIFA0 */
> +static struct plat_sci_port scif0_platform_data = {
> +	.mapbase	= 0xe6c40000,
> +	.flags		= UPF_BOOT_AUTOCONF,
> +	.scscr		= SCSCR_RE | SCSCR_TE,
> +	.scbrr_algo_id	= SCBRR_ALGO_4,
> +	.type		= PORT_SCIFA,
> +	.irqs		= { gic_spi(100), gic_spi(100),
> +			    gic_spi(100), gic_spi(100) },
> +};
> +
Please use SCIx_IRQ_MUXED() for all of the muxed IRQs.

      reply	other threads:[~2011-11-07  4:38 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-07  0:30 [PATCH 2.1/5 v2] ARM: mach-shmobile: R-Mobile A1 support Kuninori Morimoto
2011-11-07  4:38 ` Paul Mundt [this message]

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=20111107043844.GA3927@linux-sh.org \
    --to=lethal@linux-sh.org \
    --cc=linux-sh@vger.kernel.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