All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wolfram Sang <w.sang@pengutronix.de>
To: Wolfgang Grandegger <wg@grandegger.com>
Cc: Socketcan-core@lists.berlios.de, Netdev@vger.kernel.org,
	Devicetree-discuss@lists.ozlabs.org,
	Linuxppc-dev@lists.ozlabs.org, Wolfgang Grandegger <wg@denx.de>
Subject: Re: [PATCH net-next 2/3] can: mscan-mpc5xxx: add support for the MPC521x processor
Date: Mon, 4 Jan 2010 17:24:41 +0100	[thread overview]
Message-ID: <20100104162441.GA4665@pengutronix.de> (raw)
In-Reply-To: <4B3F6F6B.5070004@grandegger.com>

[-- Attachment #1: Type: text/plain, Size: 4101 bytes --]

Hello Wolfgang,

first the good news: Your patches also work with our MPC5121-board.

> >> +#else /* !CONFIG_PPC_MPC5200 */
> >> +static u32 __devinit mpc52xx_can_get_clock(struct of_device *ofdev,
> >> +					   const char *clock_name,
> >> +					   int *mscan_clksrc)
> >> +{
> >> +	return 0;
> >> +}
> >> +#endif /* CONFIG_PPC_MPC5200 */
> > 
> > Hmmm, I don't really like those empty functions. I once used the data-field of
> > struct of_device_id, which carried a function pointer to a specific
> > init-function for the matched device. What do you think about such an approach?
> 
> Often the problem is that the function will not compile on the other MPC
> arch. This is not true here. So, the main reason for the #ifdefs is
> space saving. Your approach will not help in both cases.

My idea was: it might be nice to save both #else-branches and the if-clause in
probe() which calls this get_clock() or the other (and then another in case
there will be a new mpc5xyz-user in the future). And replace it with some
mpc5xxx_custom_init() which is taken from of_device_id->data. No big issue,
though; no show-stopper.

> >> +
> >> +#ifdef CONFIG_PPC_MPC512x
> >> +struct mpc512x_clockctl {
> >> +	u32 spmr;		/* System PLL Mode Reg */
> >> +	u32 sccr[2];		/* System Clk Ctrl Reg 1 & 2 */
> >> +	u32 scfr1;		/* System Clk Freq Reg 1 */
> >> +	u32 scfr2;		/* System Clk Freq Reg 2 */
> >> +	u32 reserved;
> >> +	u32 bcr;		/* Bread Crumb Reg */
> >> +	u32 pccr[12];		/* PSC Clk Ctrl Reg 0-11 */
> >> +	u32 spccr;		/* SPDIF Clk Ctrl Reg */
> >> +	u32 cccr;		/* CFM Clk Ctrl Reg */
> >> +	u32 dccr;		/* DIU Clk Cnfg Reg */
> >> +	u32 mccr[4];		/* MSCAN Clk Ctrl Reg 1-3 */
> >> +};

I wonder if this (and the occurence in clock.c) should be factored out and
moved to asm/mpc5xxx.h?

> >> +
> >> +static struct of_device_id mpc512x_clock_ids[] __devinitdata = {
> >> +	{ .compatible = "fsl,mpc5121-clock", },
> >> +	{}
> >> +};
> >> +
> >> +static u32  __devinit mpc512x_can_get_clock(struct of_device *ofdev,
> >> +					    const char *clock_name,
> >> +					    int *mscan_clksrc,
> >> +					    ssize_t mscan_addr)
> >> +{
> >> +	struct mpc512x_clockctl __iomem *clockctl;
> >> +	struct device_node *np_clock;
> >> +	struct clk *sys_clk, *ref_clk;
> >> +	int plen, clockidx, clocksrc = -1;
> >> +	u32 sys_freq, val, clockdiv = 1, freq = 0;
> >> +	const u32 *pval;
> >> +
> >> +	np_clock = of_find_matching_node(NULL, mpc512x_clock_ids);
> >> +	if (!np_clock) {
> >> +		dev_err(&ofdev->dev, "couldn't find clock node\n");
> >> +		return -ENODEV;
> >> +	}
> >> +	clockctl = of_iomap(np_clock, 0);
> >> +	if (!clockctl) {
> >> +		dev_err(&ofdev->dev, "couldn't map clock registers\n");
> >> +		return 0;
> >> +	}
> >> +
> >> +	/* Determine the MSCAN device index from the physical address */
> >> +	clockidx = (mscan_addr & 0x80) ? 1 : 0;
> >> +	if (mscan_addr & 0x2000)
> >> +		clockidx += 2;
> > 
> > The PSCs use 'cell-index', here we use mscan_addr to derive the index. This is
> > not consistent, but should be IMHO. Now, which is the preferred way? I think
> > I'd go for 'cell-index', as other processors might have mscan_addr shuffled.
> > Also, we could use 'of_iomap' again in the probe_routine.
> 
> I understood that "cell-index" is deprecated and it has been removed
> from many nodes. That's why I used the address to derive the index.

Well, the arguments in your other mail make sense to me, so keep it this way.
As not only the index-issue, but also the clock-handling is different for the
PSCs, it is at least consistently inconsistent :D

One further note: I couldn't spot any code handling Rev1 of the MPC5121? Do you
plan to add such code? If not, we should at least put a comment that it is
missing. The binding documentation should be updated as well, as you can't use
all options on such revisions.

Regards,

   Wolfram

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

  parent reply	other threads:[~2010-01-04 16:24 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-02  8:17 [PATCH net-next 0/3] can: mscan-mpc5xxx: add support for the Freescale MPC512x Wolfgang Grandegger
2010-01-02  8:17 ` Wolfgang Grandegger
2010-01-02  8:17 ` [PATCH net-next 1/3] can: mscan: fix improper return if dlc < 8 in start_xmit function Wolfgang Grandegger
2010-01-02  8:17   ` Wolfgang Grandegger
2010-01-02  8:17   ` [PATCH net-next 2/3] can: mscan-mpc5xxx: add support for the MPC521x processor Wolfgang Grandegger
2010-01-02  8:17     ` Wolfgang Grandegger
2010-01-02  8:17     ` [PATCH net-next 3/3] powerpc/mpc5xxx: add OF platform binding doc for FSL MSCAN devices Wolfgang Grandegger
2010-01-02  8:17       ` Wolfgang Grandegger
2010-01-02 14:05       ` Wolfram Sang
2010-01-02 14:05         ` Wolfram Sang
2010-01-02 13:57     ` [PATCH net-next 2/3] can: mscan-mpc5xxx: add support for the MPC521x processor Wolfram Sang
2010-01-02 13:57       ` Wolfram Sang
2010-01-02 16:08       ` Wolfgang Grandegger
2010-01-02 16:08         ` Wolfgang Grandegger
2010-01-04 12:49         ` Wolfgang Grandegger
2010-01-04 16:24         ` Wolfram Sang [this message]
2010-01-04 16:52           ` Wolfgang Grandegger
2010-01-04 16:52             ` Wolfgang Grandegger
2010-01-04 17:22             ` Wolfram Sang
2010-01-04 17:35               ` Wolfgang Grandegger
2010-01-04 17:35                 ` Wolfgang Grandegger
2010-01-04 19:40           ` Wolfgang Denk
2010-01-04 19:40             ` Wolfgang Denk
2010-01-04 20:23             ` Wolfram Sang
2010-01-04 20:23               ` Wolfram Sang
2010-01-02 13:30   ` [PATCH net-next 1/3] can: mscan: fix improper return if dlc < 8 in start_xmit function Wolfram Sang
2010-01-02 13:30     ` Wolfram Sang
2010-01-02 15:34     ` Wolfgang Grandegger
2010-01-02 15:34       ` Wolfgang Grandegger
2010-01-02 13:27 ` [PATCH net-next 0/3] can: mscan-mpc5xxx: add support for the Freescale MPC512x Wolfram Sang
2010-01-02 13:27   ` Wolfram Sang
2010-01-02 15:32   ` Wolfgang Grandegger
2010-01-02 15:32     ` Wolfgang Grandegger

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=20100104162441.GA4665@pengutronix.de \
    --to=w.sang@pengutronix.de \
    --cc=Devicetree-discuss@lists.ozlabs.org \
    --cc=Linuxppc-dev@lists.ozlabs.org \
    --cc=Netdev@vger.kernel.org \
    --cc=Socketcan-core@lists.berlios.de \
    --cc=wg@denx.de \
    --cc=wg@grandegger.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.