OMAP1: mcbsp clocks

[Russell King - ARM Linux <linux@arm.linux.org.uk>]

A question about OMAP1 mcbsp clocks.  From what I understand from the
OMAP5912 clock architecture documentation, mcbsp1 and mcbsp3 have two
clocks:

1. interface clock switchable between DSPPER_CK and DSPXOR_CK.
2. a function clock which could be DSPXOR_CK (mcbsp3), and
   CK_DPLL1OUT or MCBS1_CLKS (mcbsp1).

However, the code in mach-omap1/mcbsp.c associates both mcbsp1 and 3
unconditionally with all of: DSP_CK, API_CK and DSPXOR_CK.  As far as
I can see, DSP_CK (for the DSP processor) and API_CK (for system dma)
have nothing to do with mcbsp1,3.

So, the question is why is it this way, and what would be the effect
of correcting this so that both of these mcbsp units are associated
with their proper interface and function clocks?

On a related note, mcbsp2 has its own interface and function clocks,
both tied to ARMPER_CK, which it doesn't even claim.  Again - why
not?

And on that note, can someone explain to me the weird way idle stuff
is handled?  It seems that idle modes are only controlled in one
situation:

1. a clock has CLOCK_NO_IDLE_PARENT set
2. the parent has CLOCK_IDLE_CONTROL set

In other words, to invoke the idle state of a clock, it's _child_ needs
to be manipulated - manipulating the clock itself, even if it has
CLOCK_IDLE_CONTROL, has no effect on the idle states.  Why is this?

(There's also a bunch of clocks which have CLOCK_IDLE_CONTROL set
but which don't have any children, making the idle state for those
clocks effectively unreachable - bug?)