Commit Graph

14 Commits

Author SHA1 Message Date
Stephen Boyd c430daf951 Revert "clk: qcom: Specify LE device endianness"
This reverts commit 329cabcecf.

The commit that caused us to specify LE device endianness here,
29bb45f25f (regmap-mmio: Use native endianness for read/write,
2015-10-29), has been reverted in mainline so now when we specify
LE it actively breaks big endian kernels because the byte
swapping in regmap-mmio is incorrect. Let's revert this change
because it will 1) fix the big endian kernels and 2) be redundant
to specify LE because that will become the default soon.

Cc: Kevin Hilman <khilman@linaro.org>
Tested-by: Kevin Hilman <khilman@baylibre.com>
Cc: Mark Brown <broonie@kernel.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
2016-02-12 14:24:24 -08:00
Stephen Boyd 329cabcecf clk: qcom: Specify LE device endianness
All these clock controllers are little endian devices, but so far
we've been relying on the regmap mmio bus handling this for us
without explicitly stating that fact. After commit 4a98da2164cf
(regmap-mmio: Use native endianness for read/write, 2015-10-29),
the regmap mmio bus will read/write with the __raw_*() IO
accessors, instead of using the readl/writel() APIs that do
proper byte swapping for little endian devices.

So if we're running on a big endian processor and haven't
specified the endianness explicitly in the regmap config or in
DT, we're going to switch from doing little endian byte swapping
to big endian accesses without byte swapping, leading to some
confusing results. On my apq8074 dragonboard, this causes the
device to fail to boot as we access the clock controller with
big endian IO accesses even though the device is little endian.

Specify the endianness explicitly so that the regmap core
properly byte swaps the accesses for us.

Reported-by: Kevin Hilman <khilman@linaro.org>
Tested-by: Tyler Baker <tyler.baker@linaro.org>
Tested-by: Kevin Hilman <khilman@linaro.org>
Cc: Simon Arlott <simon@fire.lp0.eu>
Cc: Mark Brown <broonie@kernel.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
2015-11-20 13:14:43 -08:00
Stephen Boyd 9bc432cb24 clk: qcom: Drop calls to qcom_cc_remove()
Now that qcom_cc_remove() is a nop, drop calls to
qcom_cc_remove() and any empty driver remove functions.

Cc: Rajendra Nayak <rnayak@codeaurora.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
2015-10-08 23:53:01 -07:00
Stephen Boyd b68f2c3b88 clk: qcom: Make oxili GDSC parent of oxili_cx GDSC
The oxili_cx GDSC is inside the power domain of the oxili GDSC.
Add the dependency so that the CX domain can properly power up.

Reported-by: Rob Clark <robdclark@gmail.com>
Cc: Rajendra Nayak <rnayak@codeaurora.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
2015-10-08 23:52:56 -07:00
Stephen Boyd 8108b23ca7 clk: qcom: gdsc: Add GDSCs in msm8974 MMCC
Add the GDSC instances that exist as part of msm8974 MMCC block

Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Rajendra Nayak <rnayak@codeaurora.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-16 15:22:44 -07:00
Stephen Boyd 8ee9c7de01 clk: qcom: Allow clk_set_parent() to work on display clocks
Sometimes the display driver may want to change the parent PLL of
the display clocks (byte and pixel clocks) depending on the
use-case. Currently the parent is fixed by means of having a
frequency table with one entry that chooses a particular parent.
Remove this restriction and use the parent the clock is
configured for in the hardware during clk_set_rate(). This
requires consumers to rely on the default parent or to configure
the parent with clk_set_parent()/assigned-clock-parents on the
clocks before calling clk_set_rate().

Tested-by: Archit Taneja <architt@codeaurora.org>
Cc: Hai Li <hali@codeaurora.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-16 15:22:18 -07:00
Georgi Djakov adb11a40a3 clk: qcom: Constify the parent names arrays
Make const both the array and the strings, so they can be
moved to .rodata section.

Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
2015-07-06 17:20:59 -07:00
Georgi Djakov 293d2e97b3 clk: qcom: Introduce parent_map tables
In the current parent mapping code, we can get duplicate or inconsistent
indexes, which leads to discrepancy between the number of elements in the
array and the number of parents. Until now, this was solved with some
reordering but this is not always possible.

This patch introduces index tables that are used to define the relations
between the PLL source and the hardware mux configuration value.
To accomplish this, here we do the following:
 - Define a parent_map struct to map the relations between PLL source index
 and register configuration value.
 - Add a qcom_find_src_index() function for finding the index of a clock
 matching the specific PLL configuration.
 - Update the {set,get}_parent RCG functions use the newly introduced
 parent_map struct.
 - Convert all existing drivers to the new parent_map tables.

Signed-off-by: Georgi Djakov <georgi.djakov@linaro.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
2015-03-23 16:09:19 -07:00
Kiran Padwal 59c0621d4d clk: Remove .owner field for driver
There is no need to init .owner field.

Based on the patch from Peter Griffin <peter.griffin@linaro.org>
"mmc: remove .owner field for drivers using module_platform_driver"

This patch removes the superflous .owner field for drivers which
use the module_platform_driver API, as this is overriden in
platform_driver_register anyway."

Signed-off-by: Kiran Padwal <kiran.padwal@smartplayin.com>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
2014-09-25 17:43:31 -07:00
Stephen Boyd 5b6b7490af clk: qcom: Fix PLL rate configurations
Sometimes we need to program PLLs with a fixed rate
configuration during driver probe. Doing this after we register
the PLLs with the clock framework causes the common clock
framework to assume the rate of the PLLs are 0. This causes all
sorts of problems for rate recalculations because the common
clock framework caches the rate once at registration time unless
a flag is set to always recalculate the rates.

Split the qcom_cc_probe() function into two pieces, map and
everything else, so that drivers which need to configure some
PLL rates or otherwise twiddle bits in the clock controller can
do so before registering clocks. This allows us to properly
detect the rates of PLLs that are programmed at boot.

Fixes: 49fc825f0c "clk: qcom: Consolidate common probe code"
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
2014-07-15 16:39:00 -07:00
Stephen Boyd b7b7cc7034 clk: qcom: Properly support display clocks on msm8974
The display clocks all source from dedicated phy PLLs within their
respective multimedia hardware block. Hook up these PLLs to the
display clocks with the appropriate parent mappings, clock flags,
and the appropriate clock ops. This should allow the display
clocks to work once the appropriate phy PLL driver registers their
PLL clocks.

Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
2014-05-29 09:30:24 -07:00
Stephen Boyd 437ae6a1b8 clk: qcom: Fix mmcc-8974's PLL configurations
We forgot to add the status bit for the PLLs and we were using
the wrong register and masks for configuration, leading to
unexpected PLL configurations. Fix this.

Fixes: d8b212014e (clk: qcom: Add support for MSM8974's multimedia clock controller (MMCC))
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
2014-05-29 09:30:21 -07:00
Stephen Boyd 49fc825f0c clk: qcom: Consolidate common probe code
Most of the probe code is the same between all the different
clock controllers. Consolidate the code into a common.c file.
This makes changes to the common probe parts easier and reduces
chances for bugs.

Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
2014-04-30 11:51:51 -07:00
Stephen Boyd d8b212014e clk: qcom: Add support for MSM8974's multimedia clock controller (MMCC)
Add a driver for the global clock controller found on MSM 8974
based platforms. This should allow most multimedia device drivers
to probe and control their clocks.

Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
2014-01-16 12:01:05 -08:00