Add data for omap4 clkctrl clocks, and register it within the clkctrl
driver.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Previously, hwmod core has been used for controlling the hwmod level
clocks directly. This has certain drawbacks, like being unable to share
the clocks for multiple users, missing usecounting and generally being
totally incompatible with the common clock framework.
This patch adds support for clkctrl clocks for addressing the above
issues. These support the modulemode handling, which will replace the
direct hwmod clkctrl linkage. Any optional clocks are also supported,
gate, mux and divider.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Currently, TI clock driver uses an encapsulated struct that is cast into
a void pointer to store all register addresses. This can be considered
as rather nasty hackery, and prevents from expanding the register
address field also. Instead, replace all the code to use proper struct
in place for this, which contains all the previously used data.
This patch is rather large as it is touching multiple files, but this
can't be split up as we need to avoid any boot breakage.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
These are going to be used by the clkctrl support that will be introduced
later.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
This can be used from the divider itself, and also from the clkctrl
clocks once this is introduced.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Instead of using the generic clock driver data struct, use one internal
for the TI clock driver itself. This allows modifying the register access
parts in subsequent patch.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Instead of using the generic clock driver data struct, use one internal
for the TI clock driver itself. This allows modifying the register access
parts in subsequent patch.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Constant string arrays should use const char * const instead of just
const char *. Change the implementations using these to proper type.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
This is not needed outside the driver, so move it inside it and remove
the prototype from the public header also.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
This API generates clock aliases automatically for simple clock types
(fixed-clock, fixed-factor-clock), so that we don't need to add the data
for these statically into tables. Shall be called from the SoC specific
clock init.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Large portions of the OMAP framework still depend on the support of
having clock aliases in place, so add support functions for generating
these automatically.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
The OMAP36xx DPLL5, driving EHCI USB, can be subject to a long-term
frequency drift. The frequency drift magnitude depends on the VCO update
rate, which is inversely proportional to the PLL divider. The kernel
DPLL configuration code results in a high value for the divider, leading
to a long term drift high enough to cause USB transmission errors. In
the worst case the USB PHY's ULPI interface can stop responding,
breaking USB operation completely. This manifests itself on the
Beagleboard xM by the LAN9514 reporting 'Cannot enable port 2. Maybe the
cable is bad?' in the kernel log.
Errata sprz319 advisory 2.1 documents PLL values that minimize the
drift. Use them automatically when DPLL5 is used for USB operation,
which we detect based on the requested clock rate. The clock framework
will still compute the PLL parameters and resulting rate as usual, but
the PLL M and N values will then be overridden. This can result in the
effective clock rate being slightly different than the rate cached by
the clock framework, but won't cause any adverse effect to USB
operation.
Signed-off-by: Richard Watts <rrw@kynesim.co.uk>
[Upported from v3.2 to v4.9]
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Tested-by: Ladislav Michl <ladis@linux-mips.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
We're removing struct clk from the clk provider API, so switch
this code to using the clk_hw based provider APIs.
Acked-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
From Tero Kristo:
"This pull request contains the TI clock driver set to move the
clock implementations under clock driver. Some small portions of
the clock driver code still remain under mach-omap2 after this,
it should be decided whether this code is now obsolete and should
be deleted or should someone try to fix it."
Slight merge conflicts with determine_rate prototype changes.
We should avoid exporting data from drivers, instead use an API for
registering the clock low level operations.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Several exported TI clock driver features are no longer needed outside
the clock driver itself, thus move all of these to the driver private
header file. Also, update some of the driver files to actually include
this header.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
With legacy clock support gone, this is no longer needed under platform,
so move it under the clock driver itself. Make some exports be driver
internal definitions at the same time.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
With the legacy clock data gone, this is no longer needed under platform,
so move it under the clock driver itself. Remove unnecessary declarations
from the TI clock header also.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
With the legacy clock data gone, this is no longer needed under platform,
so move it under the clock driver itself. Remove the exported clock driver
APIs as well, as these are not needed outside clock driver anymore.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
With the legacy clock support gone, this is no longer needed under
platform code-base. Thus, move this under the TI clock driver, and
remove the exported API from the public header.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
With the legacy support gone, OMAP2+ default gate clock can be moved
under clock driver. Create a new file for the purpose, and clean-up
the header exports a bit as some clock APIs are no longer needed
outside clock driver itself.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
With the legacy clock support gone, OMAP3 generic DPLL code can now be
moved over to the clock driver also. A few un-unused clkoutx2 functions
are also removed at the same time.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
This is no longer used outside clock driver, so move it under the driver
and remove the export for it from the global header file.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
This is no longer needed in platform directory, as the legacy clock data
is gone, so move it under TI clock driver. Some static functions are
renamed also.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
With the legacy clock support gone, the OMAP interface clock implementation
can be moved under the clock driver. Some temporary header file tweaks are
also needed to make this change work properly.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
With the legacy clock support gone, the OMAP4 specific DPLL implementations
can be moved under the clock driver. Change some of the function prototypes
to be static at the same time, and remove some exports from the global TI
clock driver header.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
With the legacy clock data now gone, we can start moving OMAP clock
type implementations under clock driver. Start this with moving the
generic OMAP DPLL clock type under TI clock driver.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Legacy clock data is initialized slightly differently compared to
DT clocks, thus add support for this.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Michael Turquette <mturquette@linaro.org>
Legacy clock data is initialized slightly differently compared to
DT clocks, thus add support for this.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Michael Turquette <mturquette@linaro.org>
Legacy clock data is initialized slightly differently compared to
DT clocks, thus add support for this.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Michael Turquette <mturquette@linaro.org>
Legacy clock data is initialized slightly differently compared to
DT clocks, thus add support for this. The interface clock descriptor
itself is overloading the gate clock descriptor, thus it needs to
be called from the gate setup.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Michael Turquette <mturquette@linaro.org>
Legacy clock data is initialialized slightly differently compared to
DT clocks, thus add support for this.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Michael Turquette <mturquette@linaro.org>
Legacy clock data is initialized slightly differently compared to
DT clocks, thus add support for this.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Michael Turquette <mturquette@linaro.org>
Legacy clock data for OMAP3 is being moved under clock driver, thus
base support for this is needed. This patch adds basic definitions for
clock init descriptors and core infrastructure for initialization,
which will be called from the OMAP3 clock init.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Michael Turquette <mturquette@linaro.org>
Tero Kristo