Don't let a failure of ccu_wait_bit() go unnoticed.

Signed-off-by: Alex Elder <[email protected]>

Use the init_data.name field to hold the name of a Kona clock rather
than duplicating it.

Signed-off-by: Alex Elder <[email protected]>

As I developed the bcm281xx clock code I understood there were
restrictions on device tree "compatible" strings names, and as a
result "bcm11351" was used in places despite the part family being
more properly called "bcm281xx".  This can be a little confusing.

In some cases I went to far and needlessly named things using
"bcm11351" when that was not necessary.

This patch remedies this.  It renames the symbol used to define the
"compatible" string (but not its value) so it uses "BCM281XX".
Similarly, the name names provided to the CLK_OF_DECLARE() macro
are changed, hoping to minimize the number of places that the
confusing "11351" string is used.

Signed-off-by: Alex Elder <[email protected]>

We know up front how many CCU's we'll support, so there's no need to
allocate their data structures dynamically.  Define a macro
KONA_CCU_COMMON() to simplify the initialization of many of the
fields in a ccu_data structure.  Pass the address of a statically
defined CCU structure to kona_dt_ccu_setup() rather than having that
function allocate one.

We also know at build time how many clocks a given CCU will provide,
though the number of of them for each CCU is different.  Record the
number of clocks we need in the CCU's clk_onecell_data struct
(which is used when we register the CCU with the common clock code
as a clock provider).  Rename that struct field "clk_data" (because
"data" alone gets a little confusing).

Use the known clock count to move the allocation of each CCU's
clocks array into ccu_clks_setup() rather than having each CCU's
setup callback function do it.

(The real motivation behind all of this is that we'll be doing some
static initialization of some additional CCU-specific data soon.)

Signed-off-by: Alex Elder <[email protected]>

Rather than "manually" setting up each CCU's clock entries at run
time, define a flexible array of generic Kona clock structures
within the CCU structure itself.  Each of these entries contains
generic kona clock information (like its CCU pointer and clock
framework initialization data).  Each also has a pointer to a
structure contianing clock type-dependent initialization data
(like register definitions).

Since we'll iterate over these arrays we need to be sure they have
slots for all potential clock index values.  (E.g. for the root CCU
we must have at least BCM281XX_ROOT_CCU_CLOCK_COUNT slots.)  To
ensure this we always define an extra entry and fill it using the
special initializer LAST_KONA_CLK.

Just about everything we need to know about a clock can be defined
statically.  As a result, kona_clk_setup() can be changed to take
just a kona_clk structure as its argument, and peri_clk_setup() can
be simplified.  With the information pre-defined we are also able
to handle most clock setup genericially.  We can do away with the
CCU-specific callback functions that previously were needed to set
up the entries in CCU's clock array.

Move the definition of the ccu_data structure down in "clk-kona.h"
to avoid a forward dependency.

Signed-off-by: Alex Elder <[email protected]>

Add support for CCU policy engine control, and also for setting the
mask bits for bus clocks that require a policy change to get
activated.  This includes adding validity checking framework for
CCUs, to validate the policy fields if defined.

Signed-off-by: Alex Elder <[email protected]>

Add support for clock gate hysteresis control.  For now, if it's
defined for a clock, it's enabled.

Signed-off-by: Alex Elder <[email protected]>

Add a flag that tracks whether a clock has already been initialized.
This will be used by the next patch to avoid initializing a clock
more than once when it's listed as a prerequisite.

Signed-off-by: Alex Elder <[email protected]>

Allow a clock to specify a "prerequisite" clock.  The prerequisite
clock must be initialized before the clock that depends on it.  A
prerequisite clock is defined initially by its name; as that clock
gets initialized the name gets replaced with a pointer to its clock
structure pointer.  In order to allow getting a reference to a clock
by its name we call clkdev_add() for each clock as it gets set up.
A new clk_lookup structure is added to the kona_clk type for this
purpose.

Rework the KONA_CLK() macro, and define a new KONA_CLK_PREREQ()
variant that allows a prerequisite clock to be specified.

There exist clocks that could specify more than one prequisite, but
almost all clocks only ever use one.  We can add support for more
than one if we find we need it at some point.

Signed-off-by: Alex Elder <[email protected]>

Add bus clock support.  A bus clock has a subset of the components
present in a peripheral clock (again, all optional): a gate; CCU
policy management bits; and if needed, bits to control hysteresis.

Signed-off-by: Alex Elder <[email protected]>

Define the bus clock "bsc3_apb".  This bus clock has to be managed
using the CCU policy mechanism, so add the definitions required for
that to the clock and its CCU.

This one bus clock in particular is defined because it is needed
by peripheral clock "bsc3".  Our boot loader does not properly
activate "bsc3_apb", and as a result, "bsc3" isn't able to function
properly.  With "bsc3_apb" specified as a prerequisite clock for
"bsc3", the latter works correctly.

For now only this one bus clock is defined, because it allows
correct operation of "bsc3".  Others can be added later as needed
(and this patch serves to show how that's done).

Signed-off-by: Alex Elder <[email protected]>

The Broadcom 281xx clock code uses a #define for the compatible
string for it's clock control units (CCUs).  Rather than defining
those in the C source file, define them in the header file that's
shared by both the code and the device tree source file (along with
all the clock ids).

Signed-off-by: Alex Elder <[email protected]>

The next patch defines a binding for a new Broadcom SoC that uses
Kona style CCUs for its clocks.  Update the generic Kona clock
binding document so it's more natural to accomodate the definitions
of additional SoC families.

Specifically:
    - Define the compatible string values generically, referring
      to specific per-model values later in the document.
    - Put the device tree example immediately after the required
      properties listing, before the tables of SoC-specific values.
    - Clearly identify the start of the section defining specific
      values related to the BCM281XX family
    - Add a list of the specific BCM281XX family compatible strings.
    - Reword the description of the table slightly.

Signed-off-by: Alex Elder <[email protected]>

Document the device tree binding for Broadcom BCM28164 clock control
units and clocks.  This SoC uses Kona CCUs, similar to the BCM281XX
SoC family.

Signed-off-by: Alex Elder <[email protected]>

Define the set of CCUs and provided clocks sufficient to satisfy the
needs of all the existing clock references for BCM21664.  Replace
the "fake" fixed-rate clocks used previously with "real" ones.

Note that only the minimal set of these clocks and CCUs is defined
here.  More clock definitions will need to be added as required by
the addition of additional drivers.

Signed-off-by: Alex Elder <[email protected]>

Replace the "fake" fixed-rate clocks used previously for the
bcm21664 family with "real" ones.

Signed-off-by: Alex Elder <[email protected]>

Generic version of get_cpu_idle_time() is present in cpufreq.c file. We must not
replicate that for Interactive governor, rather use the same one. Lets do it.

Signed-off-by: Viresh Kumar <[email protected]>
Signed-off-by: Jon Medhurst <[email protected]>
Signed-off-by: John Stultz <[email protected]>

Since the line below was changed to access the sk_v6_rcv_saddr
directly, we don't need to check the pinet6 value for null.

Signed-off-by: John Stultz <[email protected]>

…cking

…ore-tracking

…inaro-core-tracking

Conflicting files:

…racking

…linaro-core-tracking

…acking

…o-core-tracking

…tracking