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

[Scott Wood]

On 08/13/2012 09:32 PM, Wang Dongsheng-B40534 wrote:
> 
> 
>> -----Original Message-----
>> From: Wood Scott-B07421
>> Sent: Tuesday, August 14, 2012 10:19 AM
>> To: Wang Dongsheng-B40534
>> Cc: Wood Scott-B07421; benh at kernel.crashing.org; paulus at samba.org;
>> linuxppc-dev at 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:
>>>
>>>
>>>> -----Original Message-----
>>>> From: Wood Scott-B07421
>>>> Sent: Tuesday, August 14, 2012 10:05 AM
>>>> To: Wang Dongsheng-B40534
>>>> Cc: Wood Scott-B07421; benh at kernel.crashing.org; paulus at samba.org;
>>>> linuxppc-dev at 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:
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Wood Scott-B07421
>>>>>> Sent: Tuesday, August 14, 2012 1:37 AM
>>>>>> To: Wang Dongsheng-B40534
>>>>>> Cc: Wood Scott-B07421; benh at kernel.crashing.org; paulus at samba.org;
>>>>>> linuxppc-dev at 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:
>>>>>>>>> +	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.
>>>>>>>>
>>>>>>> [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.
>>>>>>> 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).
>>>>>>
>>>>> [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