[PATCH 5/7] fsl_pmc: update device bindings

[Li Yang-R58472]

>-----Original Message-----
>From: linuxppc-dev-bounces+leoli=freescale.com at lists.ozlabs.org
>[mailto:linuxppc-dev-bounces+leoli=freescale.com at lists.ozlabs.org] On
>Behalf Of Scott Wood
>Sent: Saturday, November 05, 2011 4:05 AM
>To: Zhao Chenhui-B35336
>Cc: linuxppc-dev at lists.ozlabs.org
>Subject: Re: [PATCH 5/7] fsl_pmc: update device bindings
>
>On 11/04/2011 07:36 AM, Zhao Chenhui wrote:
>> From: Li Yang <leoli at freescale.com>
>>
>> Signed-off-by: Li Yang <leoli at freescale.com>
>> ---
>>  .../devicetree/bindings/powerpc/fsl/pmc.txt        |   63 +++++++++++--
>------
>>  1 files changed, 36 insertions(+), 27 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/powerpc/fsl/pmc.txt
>b/Documentation/devicetree/bindings/powerpc/fsl/pmc.txt
>> index 07256b7..d84b4f8 100644
>> --- a/Documentation/devicetree/bindings/powerpc/fsl/pmc.txt
>> +++ b/Documentation/devicetree/bindings/powerpc/fsl/pmc.txt
>> @@ -9,22 +9,27 @@ Properties:
>>
>>    "fsl,mpc8548-pmc" should be listed for any chip whose PMC is
>>    compatible.  "fsl,mpc8536-pmc" should also be listed for any chip
>> -  whose PMC is compatible, and implies deep-sleep capability.
>> +  whose PMC is compatible, and implies deep-sleep capability and
>> +  wake on user defined packet(wakeup on ARP).
>
>Why does the PMC care?  This is an ethernet controller feature, the PMC
>is just keeping the wakeup-relevant parts of the ethernet controller
>alive (whatever they happen to be).
>
>Do we have any chips that have ethernet controller support for wake on
>user-defined packet, but a sleep mode that doesn't let it be used?

I think it is more a PMC feature cause Ethernet controller on many SoCs have the filer feature, but only very limited SoCs can support using it as a wake-up source.  The differences should be mostly in the PM controller block.

Also the wake on user-defined packet feature was never mentioned in the Ethernet controller part of UM.

>
>BTW, please remove fsl,mpc8536-pmc from the p1023rds device tree -- it
>was wrong before (no deep sleep, though it does appear to have jog
>mode...), and is even more wrong with this provision (it has a different
>ethernet controller).
>
>> +  "fsl,p1022-pmc" should be listed for any chip whose PMC is
>> +  compatible, and implies lossless Ethernet capability during sleep.
>>
>>    "fsl,mpc8641d-pmc" should be listed for any chip whose PMC is
>>    compatible; all statements below that apply to "fsl,mpc8548-pmc" also
>>    apply to "fsl,mpc8641d-pmc".
>>
>>    Compatibility does not include bit assignments in SCCR/PMCDR/DEVDISR;
>these
>> -  bit assignments are indicated via the sleep specifier in each
>device's
>> -  sleep property.
>> +  bit assignments are indicated via the clock nodes.  Device which has
>a
>> +  controllable clock source should have a "clk-handle" property
>pointing
>> +  to the clock node.
>
>Do we have any code to use this?

Yes, in another patch in the series.

>
>Normally that shouldn't matter, but we already an unused binding for
>this. :-)
>
>Please provide rationale for doing it this way.  Ideally it should
>probably use whatever http://devicetree.org/ClockBindings ends up being.

I have looked into that binding.  The binding was primarily defined for the Linux clock API which is not same as what we are doing here(set wakeup source).  If in the future the clock API also covers wakeup related features, we can change to use it.

- Leo