Thread (7 messages) flat view 7 messages, 3 authors, 2011-11-09

Re: [PATCH 5/7] fsl_pmc: update device bindings

From: Scott Wood <hidden>
Date: 2011-11-09 17:15:55

On Wed, Nov 09, 2011 at 04:59:16AM -0600, Li Yang-R58472 wrote:
quoted
quoted
quoted
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.
Have you tried waking from sleep with it on those other SoCs?
We have tried and it's not working.
OK.
AFAIKT, the purpose of defining the clock binding is used to describe
the topology of clocks in a system.  And then used for runtime control
of enabling/disabling clocks or getting/changing clock frequencies.

But in this PM case, we just set the wakeup capability 
Where "wakeup capability" means deciding whether to turn off the clock
during a low-power state.  The basic information you need from the device
tree is the same -- a connection from here to there.
and provide little runtime control of the clocks for on-chip devices.
My original intent for the binding you replaced was that it could be used
for other clock management as well -- you could use it to describe
DEVDISR or 83xx SCCR mappings as well.  It was when I sent that binding
out that I recall being asked to use the clock binding.

That said, Grant has recently said he's unhappy with the current state of
the clock binding, so I'm not sure what the right thing to do here is.
 And it doesn't get any benefit of using this binding.  If your concern
is the confusion with the already existing clock binding, we can remove
the clk in the name of the PM binding.
My concern, besides unnecessary duplication of ways to express something,
is a loss of generality.
If we are to use the clock binding, I think adding the CSB clock, DDR
clock, core clock, and etc with this binding is more appropriate.
That would be another use of it, but one doesn't need to imply the other.

-Scott
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help