[PATCH 5/7] fsl_pmc: update device bindings

[Scott Wood]

On Wed, Nov 09, 2011 at 04:59:16AM -0600, Li Yang-R58472 wrote:
> >>> 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