Re: [PATCH v2 2/2] powerpc/mpic: add global timer support

On 08/13/2012 09:32 PM, Wang Dongsheng-B40534 wrote:

quoted

-----Original Message-----
From: Wood Scott-B07421
Sent: Tuesday, August 14, 2012 10:19 AM
To: Wang Dongsheng-B40534
Cc: Wood Scott-B07421; benh@kernel.crashing.org; paulus@samba.org;
linuxppc-dev@lists.ozlabs.org; Gala Kumar-B11780; Li Yang-R58472
Subject: Re: [PATCH v2 2/2] powerpc/mpic: add global timer support

On 08/13/2012 09:15 PM, Wang Dongsheng-B40534 wrote:

quoted

quoted

-----Original Message-----
From: Wood Scott-B07421
Sent: Tuesday, August 14, 2012 10:05 AM
To: Wang Dongsheng-B40534
Cc: Wood Scott-B07421; benh@kernel.crashing.org; paulus@samba.org;
linuxppc-dev@lists.ozlabs.org; Gala Kumar-B11780; Li Yang-R58472
Subject: Re: [PATCH v2 2/2] powerpc/mpic: add global timer support

On 08/13/2012 09:00 PM, Wang Dongsheng-B40534 wrote:

quoted

quoted

-----Original Message-----
From: Wood Scott-B07421
Sent: Tuesday, August 14, 2012 1:37 AM
To: Wang Dongsheng-B40534
Cc: Wood Scott-B07421; benh@kernel.crashing.org; paulus@samba.org;
linuxppc-dev@lists.ozlabs.org; Gala Kumar-B11780; Li Yang-R58472
Subject: Re: [PATCH v2 2/2] powerpc/mpic: add global timer support

On 08/13/2012 01:18 AM, Wang Dongsheng-B40534 wrote:

quoted

quoted

quoted

+	p = of_get_property(np, "available-ranges", &len);
+	if (p && len % (2 * sizeof(u32)) != 0) {
+		pr_err("%s: malformed fsl,available-ranges property.\n",
+				np->full_name);
+		return -EINVAL;
+	}

You need to support fsl,available-ranges since that's in an
accepted binding and people could have partitioned setups already

using it.

quoted

quoted

quoted

quoted

[Wang Dongsheng] FSL chip or OPEN-PIC specification(Only a group)
in each group only four timer. This is unified. So i use a generic

name.

quoted

quoted

quoted

quoted

quoted

I think there is not compatible with existing mpic timer nodes.

We need to be compatible with existing trees, so you'd need to
check for both -- but I think any further discussion of the details
is premature until we decide whether this is worthwhile to begin
with (both the support of non-FSL timers, and the creation of a new
device tree binding which will not be implemented by many of the
machines that have non-FSL openpic because they run real Open

Firmware).

quoted

quoted

quoted

quoted

[Wang Dongsheng]
	p = of_get_property(np, "available-ranges", &len);
	if (!p)
		p = of_get_property(np, "fsl,available-ranges", &len);

	this code be compatible with existing trees.

Yes, that's what I meant by checking both.

I still think we need to discuss why we're doing this first.  What
specific machines are going to have these new openpic timer nodes?

[Wang Dongsheng] It's support to power management awakening. At
present, the power management more and more important. This way is
important to wake up machine. At least need support power management
of machine still needs such a driver.

I mean specifically for the non-Freescale openpic nodes.

[Wang Dongsheng] I think non-Freescale chips can also use this function
to wake up the machine. 

Maybe (it's very machine-specific what can be used as a wake source),
but what I asked was what specific machines could make use of this.
Name *one* machine for which these new openpic timer nodes will actually
be created.

And There is also an important feature, It can
periodically generate an interrupt.

That's not important at all.  We already have a way to do that using the
decrementer.

For example, the network periodically check the hardware device(link status).

And it uses standard Linux software timers to do it.

-Scott