leandrof/linux
1
0
Fork 0
forked from Minki/linux
Code Issues Pull Requests Packages Projects Releases Wiki Activity
9e19ca2f62
linux/drivers/clk/clk-qoriq.c

1241 lines
28 KiB
C
Raw Normal View History

clk: add PowerPC corenet clock driver support This adds the clock driver for Freescale PowerPC corenet series SoCs using common clock infrastructure. Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com> Signed-off-by: Li Yang <leoli@freescale.com> Signed-off-by: Mike Turquette <mturquette@linaro.org>
2013-04-09 08:46:26 +00:00
/*
* Copyright 2013 Freescale Semiconductor, Inc.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*
clk: ppc-corenet: rename driver to clk-qoriq Freescale introduced new ARM-based socs which using the compatible clock IP block with PowerPC-based socs'. So this driver can be used on both platforms. Updated relevant descriptions and renamed this driver to better represent its meaning and keep the function of driver untouched. Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com> Signed-off-by: Michael Turquette <mturquette@linaro.org>
2015-01-15 06:03:41 +00:00
* clock driver for Freescale QorIQ SoCs.
clk: add PowerPC corenet clock driver support This adds the clock driver for Freescale PowerPC corenet series SoCs using common clock infrastructure. Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com> Signed-off-by: Li Yang <leoli@freescale.com> Signed-off-by: Mike Turquette <mturquette@linaro.org>
2013-04-09 08:46:26 +00:00
*/
clk: qoriq: Use pr_fmt() Currently a mix of clk-qoriq/qoriq-clk and no prefix is used Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com> Signed-off-by: Michael Turquette <mturquette@linaro.org>
2015-01-21 10:03:29 +00:00
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
clk: qoriq: Move chip-specific knowledge into driver The device tree should describe the chips (or chip-like subblocks) in the system, but it generally does not describe individual registers -- it should identify, rather than describe, a programming interface. This has not been the case with the QorIQ clockgen nodes. The knowledge of what each bit setting of CLKCnCSR means is encoded in three places (binding, pll node, and mux node), and the last also needs to know which options are valid on a particular chip. All three of these locations are considered stable ABI, making it difficult to fix mistakes (of which I have found several), much less refactor the abstraction to be able to address problems, limitations, or new chips. Under the current binding, a pll clock specifier of 2 means that the PLL is divided by 4 -- and the driver implements this, unless there happen to be four clock-output-names rather than 3, in which case it interprets it as PLL divided by 3. This does not appear in the binding documentation at all. That hack is now considered stable ABI. The current device tree nodes contain errors, such as saying that T1040 can set a core clock to PLL/4 when only PLL and PLL/2 are options. The current binding also ignores some restrictions on clock selection, such as p5020's requirement that if a core uses the "wrong" PLL, that PLL must be clocked lower than the "correct" PLL and be at most 80% of the rated CPU frequency. Possibly because of the lack of the ability to express such nuance in the binding, some valid options are omitted from the device trees, such as the ability on p4080 to run cores 0-3 from PLL3 and cores 4-7 from PLL1 (again, only if they are at most 80% of rated CPU frequency). This omission, combined with excessive caution in the cpufreq driver (addressed in a subsequent patch), means that currently on a 1500 MHz p4080 with typical PLL configuration, cpufreq can lower the frequency to 1200 MHz on half the CPUs and do nothing on the others. With this patchset, all CPUs can be lowered to 1200 MHz on a rev2 p4080, and on a rev3 p4080 half can be lowered to 750 MHz and the other half to 600 MHz. The current binding only deals with CPU clocks. To describe FMan in the device tree, we need to describe its clock. Some chips have additional muxes that work like the CPU muxes, but are not described in the device tree. Others require inspecting the Reset Control Word to determine which PLL is used. Rather than continue to extend this mess, replace it. Have the driver bind to the chip-specific clockgen compatible, and keep the detailed description of quirky chip variations in the driver, where it can be easily fixed, refactored, and extended. Older device trees will continue to work (including a workaround for old ls1021a device trees that are missing compatible and reg in the clockgen node, which even the old binding required). The pll/mux details in old device trees will be ignored, but "clocks" properties pointing at the old nodes will still work, and be directed at the corresponding new clock. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-20 04:29:54 +00:00
#include <linux/clk.h>
clk: add PowerPC corenet clock driver support This adds the clock driver for Freescale PowerPC corenet series SoCs using common clock infrastructure. Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com> Signed-off-by: Li Yang <leoli@freescale.com> Signed-off-by: Mike Turquette <mturquette@linaro.org>
2013-04-09 08:46:26 +00:00
#include <linux/clk-provider.h>
clk: qoriq: Move chip-specific knowledge into driver The device tree should describe the chips (or chip-like subblocks) in the system, but it generally does not describe individual registers -- it should identify, rather than describe, a programming interface. This has not been the case with the QorIQ clockgen nodes. The knowledge of what each bit setting of CLKCnCSR means is encoded in three places (binding, pll node, and mux node), and the last also needs to know which options are valid on a particular chip. All three of these locations are considered stable ABI, making it difficult to fix mistakes (of which I have found several), much less refactor the abstraction to be able to address problems, limitations, or new chips. Under the current binding, a pll clock specifier of 2 means that the PLL is divided by 4 -- and the driver implements this, unless there happen to be four clock-output-names rather than 3, in which case it interprets it as PLL divided by 3. This does not appear in the binding documentation at all. That hack is now considered stable ABI. The current device tree nodes contain errors, such as saying that T1040 can set a core clock to PLL/4 when only PLL and PLL/2 are options. The current binding also ignores some restrictions on clock selection, such as p5020's requirement that if a core uses the "wrong" PLL, that PLL must be clocked lower than the "correct" PLL and be at most 80% of the rated CPU frequency. Possibly because of the lack of the ability to express such nuance in the binding, some valid options are omitted from the device trees, such as the ability on p4080 to run cores 0-3 from PLL3 and cores 4-7 from PLL1 (again, only if they are at most 80% of rated CPU frequency). This omission, combined with excessive caution in the cpufreq driver (addressed in a subsequent patch), means that currently on a 1500 MHz p4080 with typical PLL configuration, cpufreq can lower the frequency to 1200 MHz on half the CPUs and do nothing on the others. With this patchset, all CPUs can be lowered to 1200 MHz on a rev2 p4080, and on a rev3 p4080 half can be lowered to 750 MHz and the other half to 600 MHz. The current binding only deals with CPU clocks. To describe FMan in the device tree, we need to describe its clock. Some chips have additional muxes that work like the CPU muxes, but are not described in the device tree. Others require inspecting the Reset Control Word to determine which PLL is used. Rather than continue to extend this mess, replace it. Have the driver bind to the chip-specific clockgen compatible, and keep the detailed description of quirky chip variations in the driver, where it can be easily fixed, refactored, and extended. Older device trees will continue to work (including a workaround for old ls1021a device trees that are missing compatible and reg in the clockgen node, which even the old binding required). The pll/mux details in old device trees will be ignored, but "clocks" properties pointing at the old nodes will still work, and be directed at the corresponding new clock. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-20 04:29:54 +00:00
#include <linux/fsl/guts.h>
clk: add PowerPC corenet clock driver support This adds the clock driver for Freescale PowerPC corenet series SoCs using common clock infrastructure. Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com> Signed-off-by: Li Yang <leoli@freescale.com> Signed-off-by: Mike Turquette <mturquette@linaro.org>
2013-04-09 08:46:26 +00:00
#include <linux/io.h>
#include <linux/kernel.h>
#include <linux/module.h>
powerpc: add missing explicit OF includes for ppc Commit b5b4bb3f6a11f9 (of: only include prom.h on sparc) removed implicit includes of of_*.h headers by powerpc's prom.h. Some components were missed in initial clean-up patch, so add the necessary includes to fix powerpc builds. Signed-off-by: Rob Herring <rob.herring@calxeda.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Tejun Heo <tj@kernel.org> Cc: Matt Mackall <mpm@selenic.com> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: "David S. Miller" <davem@davemloft.net> Cc: Vinod Koul <vinod.koul@intel.com> Cc: Dan Williams <dan.j.williams@intel.com> Cc: linuxppc-dev@lists.ozlabs.org Cc: linux-ide@vger.kernel.org Cc: linux-crypto@vger.kernel.org
2013-11-11 05:19:08 +00:00
#include <linux/of_address.h>
clk: add PowerPC corenet clock driver support This adds the clock driver for Freescale PowerPC corenet series SoCs using common clock infrastructure. Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com> Signed-off-by: Li Yang <leoli@freescale.com> Signed-off-by: Mike Turquette <mturquette@linaro.org>
2013-04-09 08:46:26 +00:00
#include <linux/of_platform.h>
#include <linux/of.h>
#include <linux/slab.h>
clk: qoriq: Move chip-specific knowledge into driver The device tree should describe the chips (or chip-like subblocks) in the system, but it generally does not describe individual registers -- it should identify, rather than describe, a programming interface. This has not been the case with the QorIQ clockgen nodes. The knowledge of what each bit setting of CLKCnCSR means is encoded in three places (binding, pll node, and mux node), and the last also needs to know which options are valid on a particular chip. All three of these locations are considered stable ABI, making it difficult to fix mistakes (of which I have found several), much less refactor the abstraction to be able to address problems, limitations, or new chips. Under the current binding, a pll clock specifier of 2 means that the PLL is divided by 4 -- and the driver implements this, unless there happen to be four clock-output-names rather than 3, in which case it interprets it as PLL divided by 3. This does not appear in the binding documentation at all. That hack is now considered stable ABI. The current device tree nodes contain errors, such as saying that T1040 can set a core clock to PLL/4 when only PLL and PLL/2 are options. The current binding also ignores some restrictions on clock selection, such as p5020's requirement that if a core uses the "wrong" PLL, that PLL must be clocked lower than the "correct" PLL and be at most 80% of the rated CPU frequency. Possibly because of the lack of the ability to express such nuance in the binding, some valid options are omitted from the device trees, such as the ability on p4080 to run cores 0-3 from PLL3 and cores 4-7 from PLL1 (again, only if they are at most 80% of rated CPU frequency). This omission, combined with excessive caution in the cpufreq driver (addressed in a subsequent patch), means that currently on a 1500 MHz p4080 with typical PLL configuration, cpufreq can lower the frequency to 1200 MHz on half the CPUs and do nothing on the others. With this patchset, all CPUs can be lowered to 1200 MHz on a rev2 p4080, and on a rev3 p4080 half can be lowered to 750 MHz and the other half to 600 MHz. The current binding only deals with CPU clocks. To describe FMan in the device tree, we need to describe its clock. Some chips have additional muxes that work like the CPU muxes, but are not described in the device tree. Others require inspecting the Reset Control Word to determine which PLL is used. Rather than continue to extend this mess, replace it. Have the driver bind to the chip-specific clockgen compatible, and keep the detailed description of quirky chip variations in the driver, where it can be easily fixed, refactored, and extended. Older device trees will continue to work (including a workaround for old ls1021a device trees that are missing compatible and reg in the clockgen node, which even the old binding required). The pll/mux details in old device trees will be ignored, but "clocks" properties pointing at the old nodes will still work, and be directed at the corresponding new clock. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-20 04:29:54 +00:00
#define PLL_DIV1 0
#define PLL_DIV2 1
#define PLL_DIV3 2
#define PLL_DIV4 3
#define PLATFORM_PLL 0
#define CGA_PLL1 1
#define CGA_PLL2 2
#define CGA_PLL3 3
#define CGA_PLL4 4 /* only on clockgen-1.0, which lacks CGB */
#define CGB_PLL1 4
#define CGB_PLL2 5
struct clockgen_pll_div {
struct clk *clk;
char name[32];
};
struct clockgen_pll {
struct clockgen_pll_div div[4];
};
#define CLKSEL_VALID 1
#define CLKSEL_80PCT 2 /* Only allowed if PLL <= 80% of max cpu freq */
struct clockgen_sourceinfo {
u32 flags; /* CLKSEL_xxx */
int pll; /* CGx_PLLn */
int div; /* PLL_DIVn */
};
#define NUM_MUX_PARENTS 16
struct clockgen_muxinfo {
struct clockgen_sourceinfo clksel[NUM_MUX_PARENTS];
};
#define NUM_HWACCEL 5
#define NUM_CMUX 8
struct clockgen;
/*
* cmux freq must be >= platform pll.
* If not set, cmux freq must be >= platform pll/2
*/
#define CG_CMUX_GE_PLAT 1
clk: qoriq: Add ls2080a support. LS2080A is the first implementation of the chassis 3 clockgen, which has a different register layout than previous chips. It is also little endian, unlike previous chips. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-20 04:29:55 +00:00
clk: qoriq: Move chip-specific knowledge into driver The device tree should describe the chips (or chip-like subblocks) in the system, but it generally does not describe individual registers -- it should identify, rather than describe, a programming interface. This has not been the case with the QorIQ clockgen nodes. The knowledge of what each bit setting of CLKCnCSR means is encoded in three places (binding, pll node, and mux node), and the last also needs to know which options are valid on a particular chip. All three of these locations are considered stable ABI, making it difficult to fix mistakes (of which I have found several), much less refactor the abstraction to be able to address problems, limitations, or new chips. Under the current binding, a pll clock specifier of 2 means that the PLL is divided by 4 -- and the driver implements this, unless there happen to be four clock-output-names rather than 3, in which case it interprets it as PLL divided by 3. This does not appear in the binding documentation at all. That hack is now considered stable ABI. The current device tree nodes contain errors, such as saying that T1040 can set a core clock to PLL/4 when only PLL and PLL/2 are options. The current binding also ignores some restrictions on clock selection, such as p5020's requirement that if a core uses the "wrong" PLL, that PLL must be clocked lower than the "correct" PLL and be at most 80% of the rated CPU frequency. Possibly because of the lack of the ability to express such nuance in the binding, some valid options are omitted from the device trees, such as the ability on p4080 to run cores 0-3 from PLL3 and cores 4-7 from PLL1 (again, only if they are at most 80% of rated CPU frequency). This omission, combined with excessive caution in the cpufreq driver (addressed in a subsequent patch), means that currently on a 1500 MHz p4080 with typical PLL configuration, cpufreq can lower the frequency to 1200 MHz on half the CPUs and do nothing on the others. With this patchset, all CPUs can be lowered to 1200 MHz on a rev2 p4080, and on a rev3 p4080 half can be lowered to 750 MHz and the other half to 600 MHz. The current binding only deals with CPU clocks. To describe FMan in the device tree, we need to describe its clock. Some chips have additional muxes that work like the CPU muxes, but are not described in the device tree. Others require inspecting the Reset Control Word to determine which PLL is used. Rather than continue to extend this mess, replace it. Have the driver bind to the chip-specific clockgen compatible, and keep the detailed description of quirky chip variations in the driver, where it can be easily fixed, refactored, and extended. Older device trees will continue to work (including a workaround for old ls1021a device trees that are missing compatible and reg in the clockgen node, which even the old binding required). The pll/mux details in old device trees will be ignored, but "clocks" properties pointing at the old nodes will still work, and be directed at the corresponding new clock. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-20 04:29:54 +00:00
#define CG_PLL_8BIT 2 /* PLLCnGSR[CFG] is 8 bits, not 6 */
clk: qoriq: Add ls2080a support. LS2080A is the first implementation of the chassis 3 clockgen, which has a different register layout than previous chips. It is also little endian, unlike previous chips. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-20 04:29:55 +00:00
#define CG_VER3 4 /* version 3 cg: reg layout different */
#define CG_LITTLE_ENDIAN 8
clk: qoriq: Move chip-specific knowledge into driver The device tree should describe the chips (or chip-like subblocks) in the system, but it generally does not describe individual registers -- it should identify, rather than describe, a programming interface. This has not been the case with the QorIQ clockgen nodes. The knowledge of what each bit setting of CLKCnCSR means is encoded in three places (binding, pll node, and mux node), and the last also needs to know which options are valid on a particular chip. All three of these locations are considered stable ABI, making it difficult to fix mistakes (of which I have found several), much less refactor the abstraction to be able to address problems, limitations, or new chips. Under the current binding, a pll clock specifier of 2 means that the PLL is divided by 4 -- and the driver implements this, unless there happen to be four clock-output-names rather than 3, in which case it interprets it as PLL divided by 3. This does not appear in the binding documentation at all. That hack is now considered stable ABI. The current device tree nodes contain errors, such as saying that T1040 can set a core clock to PLL/4 when only PLL and PLL/2 are options. The current binding also ignores some restrictions on clock selection, such as p5020's requirement that if a core uses the "wrong" PLL, that PLL must be clocked lower than the "correct" PLL and be at most 80% of the rated CPU frequency. Possibly because of the lack of the ability to express such nuance in the binding, some valid options are omitted from the device trees, such as the ability on p4080 to run cores 0-3 from PLL3 and cores 4-7 from PLL1 (again, only if they are at most 80% of rated CPU frequency). This omission, combined with excessive caution in the cpufreq driver (addressed in a subsequent patch), means that currently on a 1500 MHz p4080 with typical PLL configuration, cpufreq can lower the frequency to 1200 MHz on half the CPUs and do nothing on the others. With this patchset, all CPUs can be lowered to 1200 MHz on a rev2 p4080, and on a rev3 p4080 half can be lowered to 750 MHz and the other half to 600 MHz. The current binding only deals with CPU clocks. To describe FMan in the device tree, we need to describe its clock. Some chips have additional muxes that work like the CPU muxes, but are not described in the device tree. Others require inspecting the Reset Control Word to determine which PLL is used. Rather than continue to extend this mess, replace it. Have the driver bind to the chip-specific clockgen compatible, and keep the detailed description of quirky chip variations in the driver, where it can be easily fixed, refactored, and extended. Older device trees will continue to work (including a workaround for old ls1021a device trees that are missing compatible and reg in the clockgen node, which even the old binding required). The pll/mux details in old device trees will be ignored, but "clocks" properties pointing at the old nodes will still work, and be directed at the corresponding new clock. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-20 04:29:54 +00:00
struct clockgen_chipinfo {
const char *compat, *guts_compat;
const struct clockgen_muxinfo *cmux_groups[2];
const struct clockgen_muxinfo *hwaccel[NUM_HWACCEL];
void (*init_periph)(struct clockgen *cg);
int cmux_to_group[NUM_CMUX]; /* -1 terminates if fewer than NUM_CMUX */
u32 pll_mask; /* 1 << n bit set if PLL n is valid */
u32 flags; /* CG_xxx */
};
struct clockgen {
struct device_node *node;
void __iomem *regs;
struct clockgen_chipinfo info; /* mutable copy */
struct clk *sysclk;
struct clockgen_pll pll[6];
struct clk *cmux[NUM_CMUX];
struct clk *hwaccel[NUM_HWACCEL];
struct clk *fman[2];
struct ccsr_guts __iomem *guts;
};
static struct clockgen clockgen;
clk: qoriq: Add ls2080a support. LS2080A is the first implementation of the chassis 3 clockgen, which has a different register layout than previous chips. It is also little endian, unlike previous chips. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-20 04:29:55 +00:00
static void cg_out(struct clockgen *cg, u32 val, u32 __iomem *reg)
{
if (cg->info.flags & CG_LITTLE_ENDIAN)
iowrite32(val, reg);
else
iowrite32be(val, reg);
}
static u32 cg_in(struct clockgen *cg, u32 __iomem *reg)
{
u32 val;
if (cg->info.flags & CG_LITTLE_ENDIAN)
val = ioread32(reg);
else
val = ioread32be(reg);
return val;
}
clk: qoriq: Move chip-specific knowledge into driver The device tree should describe the chips (or chip-like subblocks) in the system, but it generally does not describe individual registers -- it should identify, rather than describe, a programming interface. This has not been the case with the QorIQ clockgen nodes. The knowledge of what each bit setting of CLKCnCSR means is encoded in three places (binding, pll node, and mux node), and the last also needs to know which options are valid on a particular chip. All three of these locations are considered stable ABI, making it difficult to fix mistakes (of which I have found several), much less refactor the abstraction to be able to address problems, limitations, or new chips. Under the current binding, a pll clock specifier of 2 means that the PLL is divided by 4 -- and the driver implements this, unless there happen to be four clock-output-names rather than 3, in which case it interprets it as PLL divided by 3. This does not appear in the binding documentation at all. That hack is now considered stable ABI. The current device tree nodes contain errors, such as saying that T1040 can set a core clock to PLL/4 when only PLL and PLL/2 are options. The current binding also ignores some restrictions on clock selection, such as p5020's requirement that if a core uses the "wrong" PLL, that PLL must be clocked lower than the "correct" PLL and be at most 80% of the rated CPU frequency. Possibly because of the lack of the ability to express such nuance in the binding, some valid options are omitted from the device trees, such as the ability on p4080 to run cores 0-3 from PLL3 and cores 4-7 from PLL1 (again, only if they are at most 80% of rated CPU frequency). This omission, combined with excessive caution in the cpufreq driver (addressed in a subsequent patch), means that currently on a 1500 MHz p4080 with typical PLL configuration, cpufreq can lower the frequency to 1200 MHz on half the CPUs and do nothing on the others. With this patchset, all CPUs can be lowered to 1200 MHz on a rev2 p4080, and on a rev3 p4080 half can be lowered to 750 MHz and the other half to 600 MHz. The current binding only deals with CPU clocks. To describe FMan in the device tree, we need to describe its clock. Some chips have additional muxes that work like the CPU muxes, but are not described in the device tree. Others require inspecting the Reset Control Word to determine which PLL is used. Rather than continue to extend this mess, replace it. Have the driver bind to the chip-specific clockgen compatible, and keep the detailed description of quirky chip variations in the driver, where it can be easily fixed, refactored, and extended. Older device trees will continue to work (including a workaround for old ls1021a device trees that are missing compatible and reg in the clockgen node, which even the old binding required). The pll/mux details in old device trees will be ignored, but "clocks" properties pointing at the old nodes will still work, and be directed at the corresponding new clock. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-20 04:29:54 +00:00
static const struct clockgen_muxinfo p2041_cmux_grp1 = {
{
[0] = { CLKSEL_VALID, CGA_PLL1, PLL_DIV1 },
[1] = { CLKSEL_VALID, CGA_PLL1, PLL_DIV2 },
[4] = { CLKSEL_VALID, CGA_PLL2, PLL_DIV1 },
}
};
static const struct clockgen_muxinfo p2041_cmux_grp2 = {
{
[0] = { CLKSEL_VALID, CGA_PLL1, PLL_DIV1 },
[4] = { CLKSEL_VALID, CGA_PLL1, PLL_DIV2 },
[5] = { CLKSEL_VALID, CGA_PLL2, PLL_DIV1 },
}
};
static const struct clockgen_muxinfo p5020_cmux_grp1 = {
{
[0] = { CLKSEL_VALID, CGA_PLL1, PLL_DIV1 },
[1] = { CLKSEL_VALID, CGA_PLL1, PLL_DIV2 },
[4] = { CLKSEL_VALID | CLKSEL_80PCT, CGA_PLL2, PLL_DIV1 },
}
};
static const struct clockgen_muxinfo p5020_cmux_grp2 = {
{
[0] = { CLKSEL_VALID | CLKSEL_80PCT, CGA_PLL1, PLL_DIV1 },
[4] = { CLKSEL_VALID, CGA_PLL2, PLL_DIV1 },
[5] = { CLKSEL_VALID, CGA_PLL2, PLL_DIV2 },
}
};
static const struct clockgen_muxinfo p5040_cmux_grp1 = {
{
[0] = { CLKSEL_VALID, CGA_PLL1, PLL_DIV1 },
[1] = { CLKSEL_VALID, CGA_PLL1, PLL_DIV2 },
[4] = { CLKSEL_VALID | CLKSEL_80PCT, CGA_PLL2, PLL_DIV1 },
[5] = { CLKSEL_VALID | CLKSEL_80PCT, CGA_PLL2, PLL_DIV2 },
}
};
static const struct clockgen_muxinfo p5040_cmux_grp2 = {
{
[0] = { CLKSEL_VALID | CLKSEL_80PCT, CGA_PLL1, PLL_DIV1 },
[1] = { CLKSEL_VALID | CLKSEL_80PCT, CGA_PLL1, PLL_DIV2 },
[4] = { CLKSEL_VALID, CGA_PLL2, PLL_DIV1 },
[5] = { CLKSEL_VALID, CGA_PLL2, PLL_DIV2 },
}
};
static const struct clockgen_muxinfo p4080_cmux_grp1 = {
{
[0] = { CLKSEL_VALID, CGA_PLL1, PLL_DIV1 },
[1] = { CLKSEL_VALID, CGA_PLL1, PLL_DIV2 },
[4] = { CLKSEL_VALID, CGA_PLL2, PLL_DIV1 },
[5] = { CLKSEL_VALID, CGA_PLL2, PLL_DIV2 },
[8] = { CLKSEL_VALID | CLKSEL_80PCT, CGA_PLL3, PLL_DIV1 },
}
};
static const struct clockgen_muxinfo p4080_cmux_grp2 = {
{
[0] = { CLKSEL_VALID | CLKSEL_80PCT, CGA_PLL1, PLL_DIV1 },
[8] = { CLKSEL_VALID, CGA_PLL3, PLL_DIV1 },
[9] = { CLKSEL_VALID, CGA_PLL3, PLL_DIV2 },
[12] = { CLKSEL_VALID, CGA_PLL4, PLL_DIV1 },
[13] = { CLKSEL_VALID, CGA_PLL4, PLL_DIV2 },
}
};
static const struct clockgen_muxinfo t1023_cmux = {
{
[0] = { CLKSEL_VALID, CGA_PLL1, PLL_DIV1 },
[1] = { CLKSEL_VALID, CGA_PLL1, PLL_DIV2 },
}
};
static const struct clockgen_muxinfo t1040_cmux = {
{
[0] = { CLKSEL_VALID, CGA_PLL1, PLL_DIV1 },
[1] = { CLKSEL_VALID, CGA_PLL1, PLL_DIV2 },
[4] = { CLKSEL_VALID, CGA_PLL2, PLL_DIV1 },
[5] = { CLKSEL_VALID, CGA_PLL2, PLL_DIV2 },
}
};
static const struct clockgen_muxinfo clockgen2_cmux_cga = {
{
{ CLKSEL_VALID, CGA_PLL1, PLL_DIV1 },
{ CLKSEL_VALID, CGA_PLL1, PLL_DIV2 },
{ CLKSEL_VALID, CGA_PLL1, PLL_DIV4 },
{},
{ CLKSEL_VALID, CGA_PLL2, PLL_DIV1 },
{ CLKSEL_VALID, CGA_PLL2, PLL_DIV2 },
{ CLKSEL_VALID, CGA_PLL2, PLL_DIV4 },
{},
{ CLKSEL_VALID, CGA_PLL3, PLL_DIV1 },
{ CLKSEL_VALID, CGA_PLL3, PLL_DIV2 },
{ CLKSEL_VALID, CGA_PLL3, PLL_DIV4 },
},
};
static const struct clockgen_muxinfo clockgen2_cmux_cga12 = {
{
{ CLKSEL_VALID, CGA_PLL1, PLL_DIV1 },
{ CLKSEL_VALID, CGA_PLL1, PLL_DIV2 },
{ CLKSEL_VALID, CGA_PLL1, PLL_DIV4 },
{},
{ CLKSEL_VALID, CGA_PLL2, PLL_DIV1 },
{ CLKSEL_VALID, CGA_PLL2, PLL_DIV2 },
{ CLKSEL_VALID, CGA_PLL2, PLL_DIV4 },
},
};
static const struct clockgen_muxinfo clockgen2_cmux_cgb = {
{
{ CLKSEL_VALID, CGB_PLL1, PLL_DIV1 },
{ CLKSEL_VALID, CGB_PLL1, PLL_DIV2 },
{ CLKSEL_VALID, CGB_PLL1, PLL_DIV4 },
{},
{ CLKSEL_VALID, CGB_PLL2, PLL_DIV1 },
{ CLKSEL_VALID, CGB_PLL2, PLL_DIV2 },
{ CLKSEL_VALID, CGB_PLL2, PLL_DIV4 },
},
};
static const struct clockgen_muxinfo t1023_hwa1 = {
{
{},
{ CLKSEL_VALID, CGA_PLL1, PLL_DIV1 },
{ CLKSEL_VALID, CGA_PLL1, PLL_DIV2 },
{ CLKSEL_VALID, CGA_PLL1, PLL_DIV3 },
},
};
static const struct clockgen_muxinfo t1023_hwa2 = {
{
[6] = { CLKSEL_VALID, CGA_PLL1, PLL_DIV2 },
},
};
static const struct clockgen_muxinfo t2080_hwa1 = {
{
{},
{ CLKSEL_VALID, CGA_PLL1, PLL_DIV1 },
{ CLKSEL_VALID, CGA_PLL1, PLL_DIV2 },
{ CLKSEL_VALID, CGA_PLL1, PLL_DIV3 },
{ CLKSEL_VALID, CGA_PLL1, PLL_DIV4 },
{ CLKSEL_VALID, PLATFORM_PLL, PLL_DIV1 },
{ CLKSEL_VALID, CGA_PLL2, PLL_DIV2 },
{ CLKSEL_VALID, CGA_PLL2, PLL_DIV3 },
},
};
static const struct clockgen_muxinfo t2080_hwa2 = {
{
{},
{ CLKSEL_VALID, CGA_PLL2, PLL_DIV1 },
{ CLKSEL_VALID, CGA_PLL2, PLL_DIV2 },
{ CLKSEL_VALID, CGA_PLL2, PLL_DIV3 },
{ CLKSEL_VALID, CGA_PLL2, PLL_DIV4 },
{ CLKSEL_VALID, PLATFORM_PLL, PLL_DIV1 },
{ CLKSEL_VALID, CGA_PLL1, PLL_DIV2 },
{ CLKSEL_VALID, CGA_PLL1, PLL_DIV3 },
},
};
static const struct clockgen_muxinfo t4240_hwa1 = {
{
{ CLKSEL_VALID, PLATFORM_PLL, PLL_DIV2 },
{ CLKSEL_VALID, CGA_PLL1, PLL_DIV1 },
{ CLKSEL_VALID, CGA_PLL1, PLL_DIV2 },
{ CLKSEL_VALID, CGA_PLL1, PLL_DIV3 },
{ CLKSEL_VALID, CGA_PLL1, PLL_DIV4 },
{},
{ CLKSEL_VALID, CGA_PLL2, PLL_DIV2 },
{ CLKSEL_VALID, CGA_PLL2, PLL_DIV3 },
},
};
static const struct clockgen_muxinfo t4240_hwa4 = {
{
[2] = { CLKSEL_VALID, CGB_PLL1, PLL_DIV2 },
[3] = { CLKSEL_VALID, CGB_PLL1, PLL_DIV3 },
[4] = { CLKSEL_VALID, CGB_PLL1, PLL_DIV4 },
[5] = { CLKSEL_VALID, PLATFORM_PLL, PLL_DIV1 },
[6] = { CLKSEL_VALID, CGB_PLL2, PLL_DIV2 },
},
};
static const struct clockgen_muxinfo t4240_hwa5 = {
{
[2] = { CLKSEL_VALID, CGB_PLL2, PLL_DIV2 },
[3] = { CLKSEL_VALID, CGB_PLL2, PLL_DIV3 },
[4] = { CLKSEL_VALID, CGB_PLL2, PLL_DIV4 },
[5] = { CLKSEL_VALID, PLATFORM_PLL, PLL_DIV1 },
[6] = { CLKSEL_VALID, CGB_PLL1, PLL_DIV2 },
[7] = { CLKSEL_VALID, CGB_PLL1, PLL_DIV3 },
},
};
#define RCWSR7_FM1_CLK_SEL 0x40000000
#define RCWSR7_FM2_CLK_SEL 0x20000000
#define RCWSR7_HWA_ASYNC_DIV 0x04000000
static void __init p2041_init_periph(struct clockgen *cg)
{
u32 reg;
reg = ioread32be(&cg->guts->rcwsr[7]);
if (reg & RCWSR7_FM1_CLK_SEL)
cg->fman[0] = cg->pll[CGA_PLL2].div[PLL_DIV2].clk;
else
cg->fman[0] = cg->pll[PLATFORM_PLL].div[PLL_DIV2].clk;
}
static void __init p4080_init_periph(struct clockgen *cg)
{
u32 reg;
reg = ioread32be(&cg->guts->rcwsr[7]);
if (reg & RCWSR7_FM1_CLK_SEL)
cg->fman[0] = cg->pll[CGA_PLL3].div[PLL_DIV2].clk;
else
cg->fman[0] = cg->pll[PLATFORM_PLL].div[PLL_DIV2].clk;
if (reg & RCWSR7_FM2_CLK_SEL)
cg->fman[1] = cg->pll[CGA_PLL3].div[PLL_DIV2].clk;
else
cg->fman[1] = cg->pll[PLATFORM_PLL].div[PLL_DIV2].clk;
}
static void __init p5020_init_periph(struct clockgen *cg)
{
u32 reg;
int div = PLL_DIV2;
reg = ioread32be(&cg->guts->rcwsr[7]);
if (reg & RCWSR7_HWA_ASYNC_DIV)
div = PLL_DIV4;
if (reg & RCWSR7_FM1_CLK_SEL)
cg->fman[0] = cg->pll[CGA_PLL2].div[div].clk;
else
cg->fman[0] = cg->pll[PLATFORM_PLL].div[PLL_DIV2].clk;
}
static void __init p5040_init_periph(struct clockgen *cg)
{
u32 reg;
int div = PLL_DIV2;
reg = ioread32be(&cg->guts->rcwsr[7]);
if (reg & RCWSR7_HWA_ASYNC_DIV)
div = PLL_DIV4;
if (reg & RCWSR7_FM1_CLK_SEL)
cg->fman[0] = cg->pll[CGA_PLL3].div[div].clk;
else
cg->fman[0] = cg->pll[PLATFORM_PLL].div[PLL_DIV2].clk;
if (reg & RCWSR7_FM2_CLK_SEL)
cg->fman[1] = cg->pll[CGA_PLL3].div[div].clk;
else
cg->fman[1] = cg->pll[PLATFORM_PLL].div[PLL_DIV2].clk;
}
static void __init t1023_init_periph(struct clockgen *cg)
{
cg->fman[0] = cg->hwaccel[1];
}
static void __init t1040_init_periph(struct clockgen *cg)
{
cg->fman[0] = cg->pll[PLATFORM_PLL].div[PLL_DIV1].clk;
}
static void __init t2080_init_periph(struct clockgen *cg)
{
cg->fman[0] = cg->hwaccel[0];
}
static void __init t4240_init_periph(struct clockgen *cg)
{
cg->fman[0] = cg->hwaccel[3];
cg->fman[1] = cg->hwaccel[4];
}
static const struct clockgen_chipinfo chipinfo[] = {
{
.compat = "fsl,b4420-clockgen",
.guts_compat = "fsl,b4860-device-config",
.init_periph = t2080_init_periph,
.cmux_groups = {
&clockgen2_cmux_cga12, &clockgen2_cmux_cgb
},
.hwaccel = {
&t2080_hwa1
},
.cmux_to_group = {
0, 1, 1, 1, -1
},
.pll_mask = 0x3f,
.flags = CG_PLL_8BIT,
},
{
.compat = "fsl,b4860-clockgen",
.guts_compat = "fsl,b4860-device-config",
.init_periph = t2080_init_periph,
.cmux_groups = {
&clockgen2_cmux_cga12, &clockgen2_cmux_cgb
},
.hwaccel = {
&t2080_hwa1
},
.cmux_to_group = {
0, 1, 1, 1, -1
},
.pll_mask = 0x3f,
.flags = CG_PLL_8BIT,
},
{
.compat = "fsl,ls1021a-clockgen",
.cmux_groups = {
&t1023_cmux
},
.cmux_to_group = {
0, -1
},
.pll_mask = 0x03,
},
clk: qoriq: Add ls2080a support. LS2080A is the first implementation of the chassis 3 clockgen, which has a different register layout than previous chips. It is also little endian, unlike previous chips. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-20 04:29:55 +00:00
{
.compat = "fsl,ls2080a-clockgen",
.cmux_groups = {
&clockgen2_cmux_cga12, &clockgen2_cmux_cgb
},
.cmux_to_group = {
0, 0, 1, 1, -1
},
.pll_mask = 0x37,
.flags = CG_VER3 | CG_LITTLE_ENDIAN,
},
clk: qoriq: Move chip-specific knowledge into driver The device tree should describe the chips (or chip-like subblocks) in the system, but it generally does not describe individual registers -- it should identify, rather than describe, a programming interface. This has not been the case with the QorIQ clockgen nodes. The knowledge of what each bit setting of CLKCnCSR means is encoded in three places (binding, pll node, and mux node), and the last also needs to know which options are valid on a particular chip. All three of these locations are considered stable ABI, making it difficult to fix mistakes (of which I have found several), much less refactor the abstraction to be able to address problems, limitations, or new chips. Under the current binding, a pll clock specifier of 2 means that the PLL is divided by 4 -- and the driver implements this, unless there happen to be four clock-output-names rather than 3, in which case it interprets it as PLL divided by 3. This does not appear in the binding documentation at all. That hack is now considered stable ABI. The current device tree nodes contain errors, such as saying that T1040 can set a core clock to PLL/4 when only PLL and PLL/2 are options. The current binding also ignores some restrictions on clock selection, such as p5020's requirement that if a core uses the "wrong" PLL, that PLL must be clocked lower than the "correct" PLL and be at most 80% of the rated CPU frequency. Possibly because of the lack of the ability to express such nuance in the binding, some valid options are omitted from the device trees, such as the ability on p4080 to run cores 0-3 from PLL3 and cores 4-7 from PLL1 (again, only if they are at most 80% of rated CPU frequency). This omission, combined with excessive caution in the cpufreq driver (addressed in a subsequent patch), means that currently on a 1500 MHz p4080 with typical PLL configuration, cpufreq can lower the frequency to 1200 MHz on half the CPUs and do nothing on the others. With this patchset, all CPUs can be lowered to 1200 MHz on a rev2 p4080, and on a rev3 p4080 half can be lowered to 750 MHz and the other half to 600 MHz. The current binding only deals with CPU clocks. To describe FMan in the device tree, we need to describe its clock. Some chips have additional muxes that work like the CPU muxes, but are not described in the device tree. Others require inspecting the Reset Control Word to determine which PLL is used. Rather than continue to extend this mess, replace it. Have the driver bind to the chip-specific clockgen compatible, and keep the detailed description of quirky chip variations in the driver, where it can be easily fixed, refactored, and extended. Older device trees will continue to work (including a workaround for old ls1021a device trees that are missing compatible and reg in the clockgen node, which even the old binding required). The pll/mux details in old device trees will be ignored, but "clocks" properties pointing at the old nodes will still work, and be directed at the corresponding new clock. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-20 04:29:54 +00:00
{
.compat = "fsl,p2041-clockgen",
.guts_compat = "fsl,qoriq-device-config-1.0",
.init_periph = p2041_init_periph,
.cmux_groups = {
&p2041_cmux_grp1, &p2041_cmux_grp2
},
.cmux_to_group = {
0, 0, 1, 1, -1
},
.pll_mask = 0x07,
},
{
.compat = "fsl,p3041-clockgen",
.guts_compat = "fsl,qoriq-device-config-1.0",
.init_periph = p2041_init_periph,
.cmux_groups = {
&p2041_cmux_grp1, &p2041_cmux_grp2
},
.cmux_to_group = {
0, 0, 1, 1, -1
},
.pll_mask = 0x07,
},
{
.compat = "fsl,p4080-clockgen",
.guts_compat = "fsl,qoriq-device-config-1.0",
.init_periph = p4080_init_periph,
.cmux_groups = {
&p4080_cmux_grp1, &p4080_cmux_grp2
},
.cmux_to_group = {
0, 0, 0, 0, 1, 1, 1, 1
},
.pll_mask = 0x1f,
},
{
.compat = "fsl,p5020-clockgen",
.guts_compat = "fsl,qoriq-device-config-1.0",
.init_periph = p5020_init_periph,
.cmux_groups = {
&p2041_cmux_grp1, &p2041_cmux_grp2
},
.cmux_to_group = {
0, 1, -1
},
.pll_mask = 0x07,
},
{
.compat = "fsl,p5040-clockgen",
.guts_compat = "fsl,p5040-device-config",
.init_periph = p5040_init_periph,
.cmux_groups = {
&p5040_cmux_grp1, &p5040_cmux_grp2
},
.cmux_to_group = {
0, 0, 1, 1, -1
},
.pll_mask = 0x0f,
},
{
.compat = "fsl,t1023-clockgen",
.guts_compat = "fsl,t1023-device-config",
.init_periph = t1023_init_periph,
.cmux_groups = {
&t1023_cmux
},
.hwaccel = {
&t1023_hwa1, &t1023_hwa2
},
.cmux_to_group = {
0, 0, -1
},
.pll_mask = 0x03,
.flags = CG_PLL_8BIT,
},
{
.compat = "fsl,t1040-clockgen",
.guts_compat = "fsl,t1040-device-config",
.init_periph = t1040_init_periph,
.cmux_groups = {
&t1040_cmux
},
.cmux_to_group = {
0, 0, 0, 0, -1
},
.pll_mask = 0x07,
.flags = CG_PLL_8BIT,
},
{
.compat = "fsl,t2080-clockgen",
.guts_compat = "fsl,t2080-device-config",
.init_periph = t2080_init_periph,
.cmux_groups = {
&clockgen2_cmux_cga12
},
.hwaccel = {
&t2080_hwa1, &t2080_hwa2
},
.cmux_to_group = {
0, -1
},
.pll_mask = 0x07,
.flags = CG_PLL_8BIT,
},
{
.compat = "fsl,t4240-clockgen",
.guts_compat = "fsl,t4240-device-config",
.init_periph = t4240_init_periph,
.cmux_groups = {
&clockgen2_cmux_cga, &clockgen2_cmux_cgb
},
.hwaccel = {
&t4240_hwa1, NULL, NULL, &t4240_hwa4, &t4240_hwa5
},
.cmux_to_group = {
0, 0, 1, -1
},
.pll_mask = 0x3f,
.flags = CG_PLL_8BIT,
},
{},
};
struct mux_hwclock {
clk: add PowerPC corenet clock driver support This adds the clock driver for Freescale PowerPC corenet series SoCs using common clock infrastructure. Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com> Signed-off-by: Li Yang <leoli@freescale.com> Signed-off-by: Mike Turquette <mturquette@linaro.org>
2013-04-09 08:46:26 +00:00
struct clk_hw hw;
clk: qoriq: Move chip-specific knowledge into driver The device tree should describe the chips (or chip-like subblocks) in the system, but it generally does not describe individual registers -- it should identify, rather than describe, a programming interface. This has not been the case with the QorIQ clockgen nodes. The knowledge of what each bit setting of CLKCnCSR means is encoded in three places (binding, pll node, and mux node), and the last also needs to know which options are valid on a particular chip. All three of these locations are considered stable ABI, making it difficult to fix mistakes (of which I have found several), much less refactor the abstraction to be able to address problems, limitations, or new chips. Under the current binding, a pll clock specifier of 2 means that the PLL is divided by 4 -- and the driver implements this, unless there happen to be four clock-output-names rather than 3, in which case it interprets it as PLL divided by 3. This does not appear in the binding documentation at all. That hack is now considered stable ABI. The current device tree nodes contain errors, such as saying that T1040 can set a core clock to PLL/4 when only PLL and PLL/2 are options. The current binding also ignores some restrictions on clock selection, such as p5020's requirement that if a core uses the "wrong" PLL, that PLL must be clocked lower than the "correct" PLL and be at most 80% of the rated CPU frequency. Possibly because of the lack of the ability to express such nuance in the binding, some valid options are omitted from the device trees, such as the ability on p4080 to run cores 0-3 from PLL3 and cores 4-7 from PLL1 (again, only if they are at most 80% of rated CPU frequency). This omission, combined with excessive caution in the cpufreq driver (addressed in a subsequent patch), means that currently on a 1500 MHz p4080 with typical PLL configuration, cpufreq can lower the frequency to 1200 MHz on half the CPUs and do nothing on the others. With this patchset, all CPUs can be lowered to 1200 MHz on a rev2 p4080, and on a rev3 p4080 half can be lowered to 750 MHz and the other half to 600 MHz. The current binding only deals with CPU clocks. To describe FMan in the device tree, we need to describe its clock. Some chips have additional muxes that work like the CPU muxes, but are not described in the device tree. Others require inspecting the Reset Control Word to determine which PLL is used. Rather than continue to extend this mess, replace it. Have the driver bind to the chip-specific clockgen compatible, and keep the detailed description of quirky chip variations in the driver, where it can be easily fixed, refactored, and extended. Older device trees will continue to work (including a workaround for old ls1021a device trees that are missing compatible and reg in the clockgen node, which even the old binding required). The pll/mux details in old device trees will be ignored, but "clocks" properties pointing at the old nodes will still work, and be directed at the corresponding new clock. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-20 04:29:54 +00:00
struct clockgen *cg;
const struct clockgen_muxinfo *info;
u32 __iomem *reg;
u8 parent_to_clksel[NUM_MUX_PARENTS];
s8 clksel_to_parent[NUM_MUX_PARENTS];
int num_parents;
clk: add PowerPC corenet clock driver support This adds the clock driver for Freescale PowerPC corenet series SoCs using common clock infrastructure. Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com> Signed-off-by: Li Yang <leoli@freescale.com> Signed-off-by: Mike Turquette <mturquette@linaro.org>
2013-04-09 08:46:26 +00:00
};
clk: qoriq: Move chip-specific knowledge into driver The device tree should describe the chips (or chip-like subblocks) in the system, but it generally does not describe individual registers -- it should identify, rather than describe, a programming interface. This has not been the case with the QorIQ clockgen nodes. The knowledge of what each bit setting of CLKCnCSR means is encoded in three places (binding, pll node, and mux node), and the last also needs to know which options are valid on a particular chip. All three of these locations are considered stable ABI, making it difficult to fix mistakes (of which I have found several), much less refactor the abstraction to be able to address problems, limitations, or new chips. Under the current binding, a pll clock specifier of 2 means that the PLL is divided by 4 -- and the driver implements this, unless there happen to be four clock-output-names rather than 3, in which case it interprets it as PLL divided by 3. This does not appear in the binding documentation at all. That hack is now considered stable ABI. The current device tree nodes contain errors, such as saying that T1040 can set a core clock to PLL/4 when only PLL and PLL/2 are options. The current binding also ignores some restrictions on clock selection, such as p5020's requirement that if a core uses the "wrong" PLL, that PLL must be clocked lower than the "correct" PLL and be at most 80% of the rated CPU frequency. Possibly because of the lack of the ability to express such nuance in the binding, some valid options are omitted from the device trees, such as the ability on p4080 to run cores 0-3 from PLL3 and cores 4-7 from PLL1 (again, only if they are at most 80% of rated CPU frequency). This omission, combined with excessive caution in the cpufreq driver (addressed in a subsequent patch), means that currently on a 1500 MHz p4080 with typical PLL configuration, cpufreq can lower the frequency to 1200 MHz on half the CPUs and do nothing on the others. With this patchset, all CPUs can be lowered to 1200 MHz on a rev2 p4080, and on a rev3 p4080 half can be lowered to 750 MHz and the other half to 600 MHz. The current binding only deals with CPU clocks. To describe FMan in the device tree, we need to describe its clock. Some chips have additional muxes that work like the CPU muxes, but are not described in the device tree. Others require inspecting the Reset Control Word to determine which PLL is used. Rather than continue to extend this mess, replace it. Have the driver bind to the chip-specific clockgen compatible, and keep the detailed description of quirky chip variations in the driver, where it can be easily fixed, refactored, and extended. Older device trees will continue to work (including a workaround for old ls1021a device trees that are missing compatible and reg in the clockgen node, which even the old binding required). The pll/mux details in old device trees will be ignored, but "clocks" properties pointing at the old nodes will still work, and be directed at the corresponding new clock. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-20 04:29:54 +00:00
#define to_mux_hwclock(p) container_of(p, struct mux_hwclock, hw)
#define CLKSEL_MASK 0x78000000
clk: add PowerPC corenet clock driver support This adds the clock driver for Freescale PowerPC corenet series SoCs using common clock infrastructure. Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com> Signed-off-by: Li Yang <leoli@freescale.com> Signed-off-by: Mike Turquette <mturquette@linaro.org>
2013-04-09 08:46:26 +00:00
#define CLKSEL_SHIFT 27
clk: qoriq: Move chip-specific knowledge into driver The device tree should describe the chips (or chip-like subblocks) in the system, but it generally does not describe individual registers -- it should identify, rather than describe, a programming interface. This has not been the case with the QorIQ clockgen nodes. The knowledge of what each bit setting of CLKCnCSR means is encoded in three places (binding, pll node, and mux node), and the last also needs to know which options are valid on a particular chip. All three of these locations are considered stable ABI, making it difficult to fix mistakes (of which I have found several), much less refactor the abstraction to be able to address problems, limitations, or new chips. Under the current binding, a pll clock specifier of 2 means that the PLL is divided by 4 -- and the driver implements this, unless there happen to be four clock-output-names rather than 3, in which case it interprets it as PLL divided by 3. This does not appear in the binding documentation at all. That hack is now considered stable ABI. The current device tree nodes contain errors, such as saying that T1040 can set a core clock to PLL/4 when only PLL and PLL/2 are options. The current binding also ignores some restrictions on clock selection, such as p5020's requirement that if a core uses the "wrong" PLL, that PLL must be clocked lower than the "correct" PLL and be at most 80% of the rated CPU frequency. Possibly because of the lack of the ability to express such nuance in the binding, some valid options are omitted from the device trees, such as the ability on p4080 to run cores 0-3 from PLL3 and cores 4-7 from PLL1 (again, only if they are at most 80% of rated CPU frequency). This omission, combined with excessive caution in the cpufreq driver (addressed in a subsequent patch), means that currently on a 1500 MHz p4080 with typical PLL configuration, cpufreq can lower the frequency to 1200 MHz on half the CPUs and do nothing on the others. With this patchset, all CPUs can be lowered to 1200 MHz on a rev2 p4080, and on a rev3 p4080 half can be lowered to 750 MHz and the other half to 600 MHz. The current binding only deals with CPU clocks. To describe FMan in the device tree, we need to describe its clock. Some chips have additional muxes that work like the CPU muxes, but are not described in the device tree. Others require inspecting the Reset Control Word to determine which PLL is used. Rather than continue to extend this mess, replace it. Have the driver bind to the chip-specific clockgen compatible, and keep the detailed description of quirky chip variations in the driver, where it can be easily fixed, refactored, and extended. Older device trees will continue to work (including a workaround for old ls1021a device trees that are missing compatible and reg in the clockgen node, which even the old binding required). The pll/mux details in old device trees will be ignored, but "clocks" properties pointing at the old nodes will still work, and be directed at the corresponding new clock. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-20 04:29:54 +00:00
static int mux_set_parent(struct clk_hw *hw, u8 idx)
clk: add PowerPC corenet clock driver support This adds the clock driver for Freescale PowerPC corenet series SoCs using common clock infrastructure. Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com> Signed-off-by: Li Yang <leoli@freescale.com> Signed-off-by: Mike Turquette <mturquette@linaro.org>
2013-04-09 08:46:26 +00:00
{
clk: qoriq: Move chip-specific knowledge into driver The device tree should describe the chips (or chip-like subblocks) in the system, but it generally does not describe individual registers -- it should identify, rather than describe, a programming interface. This has not been the case with the QorIQ clockgen nodes. The knowledge of what each bit setting of CLKCnCSR means is encoded in three places (binding, pll node, and mux node), and the last also needs to know which options are valid on a particular chip. All three of these locations are considered stable ABI, making it difficult to fix mistakes (of which I have found several), much less refactor the abstraction to be able to address problems, limitations, or new chips. Under the current binding, a pll clock specifier of 2 means that the PLL is divided by 4 -- and the driver implements this, unless there happen to be four clock-output-names rather than 3, in which case it interprets it as PLL divided by 3. This does not appear in the binding documentation at all. That hack is now considered stable ABI. The current device tree nodes contain errors, such as saying that T1040 can set a core clock to PLL/4 when only PLL and PLL/2 are options. The current binding also ignores some restrictions on clock selection, such as p5020's requirement that if a core uses the "wrong" PLL, that PLL must be clocked lower than the "correct" PLL and be at most 80% of the rated CPU frequency. Possibly because of the lack of the ability to express such nuance in the binding, some valid options are omitted from the device trees, such as the ability on p4080 to run cores 0-3 from PLL3 and cores 4-7 from PLL1 (again, only if they are at most 80% of rated CPU frequency). This omission, combined with excessive caution in the cpufreq driver (addressed in a subsequent patch), means that currently on a 1500 MHz p4080 with typical PLL configuration, cpufreq can lower the frequency to 1200 MHz on half the CPUs and do nothing on the others. With this patchset, all CPUs can be lowered to 1200 MHz on a rev2 p4080, and on a rev3 p4080 half can be lowered to 750 MHz and the other half to 600 MHz. The current binding only deals with CPU clocks. To describe FMan in the device tree, we need to describe its clock. Some chips have additional muxes that work like the CPU muxes, but are not described in the device tree. Others require inspecting the Reset Control Word to determine which PLL is used. Rather than continue to extend this mess, replace it. Have the driver bind to the chip-specific clockgen compatible, and keep the detailed description of quirky chip variations in the driver, where it can be easily fixed, refactored, and extended. Older device trees will continue to work (including a workaround for old ls1021a device trees that are missing compatible and reg in the clockgen node, which even the old binding required). The pll/mux details in old device trees will be ignored, but "clocks" properties pointing at the old nodes will still work, and be directed at the corresponding new clock. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-20 04:29:54 +00:00
struct mux_hwclock *hwc = to_mux_hwclock(hw);
clk: add PowerPC corenet clock driver support This adds the clock driver for Freescale PowerPC corenet series SoCs using common clock infrastructure. Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com> Signed-off-by: Li Yang <leoli@freescale.com> Signed-off-by: Mike Turquette <mturquette@linaro.org>
2013-04-09 08:46:26 +00:00
u32 clksel;
clk: qoriq: Move chip-specific knowledge into driver The device tree should describe the chips (or chip-like subblocks) in the system, but it generally does not describe individual registers -- it should identify, rather than describe, a programming interface. This has not been the case with the QorIQ clockgen nodes. The knowledge of what each bit setting of CLKCnCSR means is encoded in three places (binding, pll node, and mux node), and the last also needs to know which options are valid on a particular chip. All three of these locations are considered stable ABI, making it difficult to fix mistakes (of which I have found several), much less refactor the abstraction to be able to address problems, limitations, or new chips. Under the current binding, a pll clock specifier of 2 means that the PLL is divided by 4 -- and the driver implements this, unless there happen to be four clock-output-names rather than 3, in which case it interprets it as PLL divided by 3. This does not appear in the binding documentation at all. That hack is now considered stable ABI. The current device tree nodes contain errors, such as saying that T1040 can set a core clock to PLL/4 when only PLL and PLL/2 are options. The current binding also ignores some restrictions on clock selection, such as p5020's requirement that if a core uses the "wrong" PLL, that PLL must be clocked lower than the "correct" PLL and be at most 80% of the rated CPU frequency. Possibly because of the lack of the ability to express such nuance in the binding, some valid options are omitted from the device trees, such as the ability on p4080 to run cores 0-3 from PLL3 and cores 4-7 from PLL1 (again, only if they are at most 80% of rated CPU frequency). This omission, combined with excessive caution in the cpufreq driver (addressed in a subsequent patch), means that currently on a 1500 MHz p4080 with typical PLL configuration, cpufreq can lower the frequency to 1200 MHz on half the CPUs and do nothing on the others. With this patchset, all CPUs can be lowered to 1200 MHz on a rev2 p4080, and on a rev3 p4080 half can be lowered to 750 MHz and the other half to 600 MHz. The current binding only deals with CPU clocks. To describe FMan in the device tree, we need to describe its clock. Some chips have additional muxes that work like the CPU muxes, but are not described in the device tree. Others require inspecting the Reset Control Word to determine which PLL is used. Rather than continue to extend this mess, replace it. Have the driver bind to the chip-specific clockgen compatible, and keep the detailed description of quirky chip variations in the driver, where it can be easily fixed, refactored, and extended. Older device trees will continue to work (including a workaround for old ls1021a device trees that are missing compatible and reg in the clockgen node, which even the old binding required). The pll/mux details in old device trees will be ignored, but "clocks" properties pointing at the old nodes will still work, and be directed at the corresponding new clock. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-20 04:29:54 +00:00
if (idx >= hwc->num_parents)
return -EINVAL;
clksel = hwc->parent_to_clksel[idx];
clk: qoriq: Add ls2080a support. LS2080A is the first implementation of the chassis 3 clockgen, which has a different register layout than previous chips. It is also little endian, unlike previous chips. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-20 04:29:55 +00:00
cg_out(hwc->cg, (clksel << CLKSEL_SHIFT) & CLKSEL_MASK, hwc->reg);
clk: add PowerPC corenet clock driver support This adds the clock driver for Freescale PowerPC corenet series SoCs using common clock infrastructure. Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com> Signed-off-by: Li Yang <leoli@freescale.com> Signed-off-by: Mike Turquette <mturquette@linaro.org>
2013-04-09 08:46:26 +00:00
return 0;
}
clk: qoriq: Move chip-specific knowledge into driver The device tree should describe the chips (or chip-like subblocks) in the system, but it generally does not describe individual registers -- it should identify, rather than describe, a programming interface. This has not been the case with the QorIQ clockgen nodes. The knowledge of what each bit setting of CLKCnCSR means is encoded in three places (binding, pll node, and mux node), and the last also needs to know which options are valid on a particular chip. All three of these locations are considered stable ABI, making it difficult to fix mistakes (of which I have found several), much less refactor the abstraction to be able to address problems, limitations, or new chips. Under the current binding, a pll clock specifier of 2 means that the PLL is divided by 4 -- and the driver implements this, unless there happen to be four clock-output-names rather than 3, in which case it interprets it as PLL divided by 3. This does not appear in the binding documentation at all. That hack is now considered stable ABI. The current device tree nodes contain errors, such as saying that T1040 can set a core clock to PLL/4 when only PLL and PLL/2 are options. The current binding also ignores some restrictions on clock selection, such as p5020's requirement that if a core uses the "wrong" PLL, that PLL must be clocked lower than the "correct" PLL and be at most 80% of the rated CPU frequency. Possibly because of the lack of the ability to express such nuance in the binding, some valid options are omitted from the device trees, such as the ability on p4080 to run cores 0-3 from PLL3 and cores 4-7 from PLL1 (again, only if they are at most 80% of rated CPU frequency). This omission, combined with excessive caution in the cpufreq driver (addressed in a subsequent patch), means that currently on a 1500 MHz p4080 with typical PLL configuration, cpufreq can lower the frequency to 1200 MHz on half the CPUs and do nothing on the others. With this patchset, all CPUs can be lowered to 1200 MHz on a rev2 p4080, and on a rev3 p4080 half can be lowered to 750 MHz and the other half to 600 MHz. The current binding only deals with CPU clocks. To describe FMan in the device tree, we need to describe its clock. Some chips have additional muxes that work like the CPU muxes, but are not described in the device tree. Others require inspecting the Reset Control Word to determine which PLL is used. Rather than continue to extend this mess, replace it. Have the driver bind to the chip-specific clockgen compatible, and keep the detailed description of quirky chip variations in the driver, where it can be easily fixed, refactored, and extended. Older device trees will continue to work (including a workaround for old ls1021a device trees that are missing compatible and reg in the clockgen node, which even the old binding required). The pll/mux details in old device trees will be ignored, but "clocks" properties pointing at the old nodes will still work, and be directed at the corresponding new clock. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-20 04:29:54 +00:00
static u8 mux_get_parent(struct clk_hw *hw)
clk: add PowerPC corenet clock driver support This adds the clock driver for Freescale PowerPC corenet series SoCs using common clock infrastructure. Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com> Signed-off-by: Li Yang <leoli@freescale.com> Signed-off-by: Mike Turquette <mturquette@linaro.org>
2013-04-09 08:46:26 +00:00
{
clk: qoriq: Move chip-specific knowledge into driver The device tree should describe the chips (or chip-like subblocks) in the system, but it generally does not describe individual registers -- it should identify, rather than describe, a programming interface. This has not been the case with the QorIQ clockgen nodes. The knowledge of what each bit setting of CLKCnCSR means is encoded in three places (binding, pll node, and mux node), and the last also needs to know which options are valid on a particular chip. All three of these locations are considered stable ABI, making it difficult to fix mistakes (of which I have found several), much less refactor the abstraction to be able to address problems, limitations, or new chips. Under the current binding, a pll clock specifier of 2 means that the PLL is divided by 4 -- and the driver implements this, unless there happen to be four clock-output-names rather than 3, in which case it interprets it as PLL divided by 3. This does not appear in the binding documentation at all. That hack is now considered stable ABI. The current device tree nodes contain errors, such as saying that T1040 can set a core clock to PLL/4 when only PLL and PLL/2 are options. The current binding also ignores some restrictions on clock selection, such as p5020's requirement that if a core uses the "wrong" PLL, that PLL must be clocked lower than the "correct" PLL and be at most 80% of the rated CPU frequency. Possibly because of the lack of the ability to express such nuance in the binding, some valid options are omitted from the device trees, such as the ability on p4080 to run cores 0-3 from PLL3 and cores 4-7 from PLL1 (again, only if they are at most 80% of rated CPU frequency). This omission, combined with excessive caution in the cpufreq driver (addressed in a subsequent patch), means that currently on a 1500 MHz p4080 with typical PLL configuration, cpufreq can lower the frequency to 1200 MHz on half the CPUs and do nothing on the others. With this patchset, all CPUs can be lowered to 1200 MHz on a rev2 p4080, and on a rev3 p4080 half can be lowered to 750 MHz and the other half to 600 MHz. The current binding only deals with CPU clocks. To describe FMan in the device tree, we need to describe its clock. Some chips have additional muxes that work like the CPU muxes, but are not described in the device tree. Others require inspecting the Reset Control Word to determine which PLL is used. Rather than continue to extend this mess, replace it. Have the driver bind to the chip-specific clockgen compatible, and keep the detailed description of quirky chip variations in the driver, where it can be easily fixed, refactored, and extended. Older device trees will continue to work (including a workaround for old ls1021a device trees that are missing compatible and reg in the clockgen node, which even the old binding required). The pll/mux details in old device trees will be ignored, but "clocks" properties pointing at the old nodes will still work, and be directed at the corresponding new clock. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-20 04:29:54 +00:00
struct mux_hwclock *hwc = to_mux_hwclock(hw);
clk: add PowerPC corenet clock driver support This adds the clock driver for Freescale PowerPC corenet series SoCs using common clock infrastructure. Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com> Signed-off-by: Li Yang <leoli@freescale.com> Signed-off-by: Mike Turquette <mturquette@linaro.org>
2013-04-09 08:46:26 +00:00
u32 clksel;
clk: qoriq: Move chip-specific knowledge into driver The device tree should describe the chips (or chip-like subblocks) in the system, but it generally does not describe individual registers -- it should identify, rather than describe, a programming interface. This has not been the case with the QorIQ clockgen nodes. The knowledge of what each bit setting of CLKCnCSR means is encoded in three places (binding, pll node, and mux node), and the last also needs to know which options are valid on a particular chip. All three of these locations are considered stable ABI, making it difficult to fix mistakes (of which I have found several), much less refactor the abstraction to be able to address problems, limitations, or new chips. Under the current binding, a pll clock specifier of 2 means that the PLL is divided by 4 -- and the driver implements this, unless there happen to be four clock-output-names rather than 3, in which case it interprets it as PLL divided by 3. This does not appear in the binding documentation at all. That hack is now considered stable ABI. The current device tree nodes contain errors, such as saying that T1040 can set a core clock to PLL/4 when only PLL and PLL/2 are options. The current binding also ignores some restrictions on clock selection, such as p5020's requirement that if a core uses the "wrong" PLL, that PLL must be clocked lower than the "correct" PLL and be at most 80% of the rated CPU frequency. Possibly because of the lack of the ability to express such nuance in the binding, some valid options are omitted from the device trees, such as the ability on p4080 to run cores 0-3 from PLL3 and cores 4-7 from PLL1 (again, only if they are at most 80% of rated CPU frequency). This omission, combined with excessive caution in the cpufreq driver (addressed in a subsequent patch), means that currently on a 1500 MHz p4080 with typical PLL configuration, cpufreq can lower the frequency to 1200 MHz on half the CPUs and do nothing on the others. With this patchset, all CPUs can be lowered to 1200 MHz on a rev2 p4080, and on a rev3 p4080 half can be lowered to 750 MHz and the other half to 600 MHz. The current binding only deals with CPU clocks. To describe FMan in the device tree, we need to describe its clock. Some chips have additional muxes that work like the CPU muxes, but are not described in the device tree. Others require inspecting the Reset Control Word to determine which PLL is used. Rather than continue to extend this mess, replace it. Have the driver bind to the chip-specific clockgen compatible, and keep the detailed description of quirky chip variations in the driver, where it can be easily fixed, refactored, and extended. Older device trees will continue to work (including a workaround for old ls1021a device trees that are missing compatible and reg in the clockgen node, which even the old binding required). The pll/mux details in old device trees will be ignored, but "clocks" properties pointing at the old nodes will still work, and be directed at the corresponding new clock. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-20 04:29:54 +00:00
s8 ret;
clk: add PowerPC corenet clock driver support This adds the clock driver for Freescale PowerPC corenet series SoCs using common clock infrastructure. Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com> Signed-off-by: Li Yang <leoli@freescale.com> Signed-off-by: Mike Turquette <mturquette@linaro.org>
2013-04-09 08:46:26 +00:00
clk: qoriq: Add ls2080a support. LS2080A is the first implementation of the chassis 3 clockgen, which has a different register layout than previous chips. It is also little endian, unlike previous chips. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-20 04:29:55 +00:00
clksel = (cg_in(hwc->cg, hwc->reg) & CLKSEL_MASK) >> CLKSEL_SHIFT;
clk: add PowerPC corenet clock driver support This adds the clock driver for Freescale PowerPC corenet series SoCs using common clock infrastructure. Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com> Signed-off-by: Li Yang <leoli@freescale.com> Signed-off-by: Mike Turquette <mturquette@linaro.org>
2013-04-09 08:46:26 +00:00
clk: qoriq: Move chip-specific knowledge into driver The device tree should describe the chips (or chip-like subblocks) in the system, but it generally does not describe individual registers -- it should identify, rather than describe, a programming interface. This has not been the case with the QorIQ clockgen nodes. The knowledge of what each bit setting of CLKCnCSR means is encoded in three places (binding, pll node, and mux node), and the last also needs to know which options are valid on a particular chip. All three of these locations are considered stable ABI, making it difficult to fix mistakes (of which I have found several), much less refactor the abstraction to be able to address problems, limitations, or new chips. Under the current binding, a pll clock specifier of 2 means that the PLL is divided by 4 -- and the driver implements this, unless there happen to be four clock-output-names rather than 3, in which case it interprets it as PLL divided by 3. This does not appear in the binding documentation at all. That hack is now considered stable ABI. The current device tree nodes contain errors, such as saying that T1040 can set a core clock to PLL/4 when only PLL and PLL/2 are options. The current binding also ignores some restrictions on clock selection, such as p5020's requirement that if a core uses the "wrong" PLL, that PLL must be clocked lower than the "correct" PLL and be at most 80% of the rated CPU frequency. Possibly because of the lack of the ability to express such nuance in the binding, some valid options are omitted from the device trees, such as the ability on p4080 to run cores 0-3 from PLL3 and cores 4-7 from PLL1 (again, only if they are at most 80% of rated CPU frequency). This omission, combined with excessive caution in the cpufreq driver (addressed in a subsequent patch), means that currently on a 1500 MHz p4080 with typical PLL configuration, cpufreq can lower the frequency to 1200 MHz on half the CPUs and do nothing on the others. With this patchset, all CPUs can be lowered to 1200 MHz on a rev2 p4080, and on a rev3 p4080 half can be lowered to 750 MHz and the other half to 600 MHz. The current binding only deals with CPU clocks. To describe FMan in the device tree, we need to describe its clock. Some chips have additional muxes that work like the CPU muxes, but are not described in the device tree. Others require inspecting the Reset Control Word to determine which PLL is used. Rather than continue to extend this mess, replace it. Have the driver bind to the chip-specific clockgen compatible, and keep the detailed description of quirky chip variations in the driver, where it can be easily fixed, refactored, and extended. Older device trees will continue to work (including a workaround for old ls1021a device trees that are missing compatible and reg in the clockgen node, which even the old binding required). The pll/mux details in old device trees will be ignored, but "clocks" properties pointing at the old nodes will still work, and be directed at the corresponding new clock. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-20 04:29:54 +00:00
ret = hwc->clksel_to_parent[clksel];
if (ret < 0) {
pr_err("%s: mux at %p has bad clksel\n", __func__, hwc->reg);
return 0;
}
return ret;
clk: add PowerPC corenet clock driver support This adds the clock driver for Freescale PowerPC corenet series SoCs using common clock infrastructure. Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com> Signed-off-by: Li Yang <leoli@freescale.com> Signed-off-by: Mike Turquette <mturquette@linaro.org>
2013-04-09 08:46:26 +00:00
}
clk: qoriq: Make local symbol 'static' drivers/clk/clk-qoriq.c:59:22: warning: symbol 'cmux_ops' was not declared. Should it be static? Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com> Signed-off-by: Michael Turquette <mturquette@linaro.org>
2015-01-21 10:03:27 +00:00
static const struct clk_ops cmux_ops = {
clk: qoriq: Move chip-specific knowledge into driver The device tree should describe the chips (or chip-like subblocks) in the system, but it generally does not describe individual registers -- it should identify, rather than describe, a programming interface. This has not been the case with the QorIQ clockgen nodes. The knowledge of what each bit setting of CLKCnCSR means is encoded in three places (binding, pll node, and mux node), and the last also needs to know which options are valid on a particular chip. All three of these locations are considered stable ABI, making it difficult to fix mistakes (of which I have found several), much less refactor the abstraction to be able to address problems, limitations, or new chips. Under the current binding, a pll clock specifier of 2 means that the PLL is divided by 4 -- and the driver implements this, unless there happen to be four clock-output-names rather than 3, in which case it interprets it as PLL divided by 3. This does not appear in the binding documentation at all. That hack is now considered stable ABI. The current device tree nodes contain errors, such as saying that T1040 can set a core clock to PLL/4 when only PLL and PLL/2 are options. The current binding also ignores some restrictions on clock selection, such as p5020's requirement that if a core uses the "wrong" PLL, that PLL must be clocked lower than the "correct" PLL and be at most 80% of the rated CPU frequency. Possibly because of the lack of the ability to express such nuance in the binding, some valid options are omitted from the device trees, such as the ability on p4080 to run cores 0-3 from PLL3 and cores 4-7 from PLL1 (again, only if they are at most 80% of rated CPU frequency). This omission, combined with excessive caution in the cpufreq driver (addressed in a subsequent patch), means that currently on a 1500 MHz p4080 with typical PLL configuration, cpufreq can lower the frequency to 1200 MHz on half the CPUs and do nothing on the others. With this patchset, all CPUs can be lowered to 1200 MHz on a rev2 p4080, and on a rev3 p4080 half can be lowered to 750 MHz and the other half to 600 MHz. The current binding only deals with CPU clocks. To describe FMan in the device tree, we need to describe its clock. Some chips have additional muxes that work like the CPU muxes, but are not described in the device tree. Others require inspecting the Reset Control Word to determine which PLL is used. Rather than continue to extend this mess, replace it. Have the driver bind to the chip-specific clockgen compatible, and keep the detailed description of quirky chip variations in the driver, where it can be easily fixed, refactored, and extended. Older device trees will continue to work (including a workaround for old ls1021a device trees that are missing compatible and reg in the clockgen node, which even the old binding required). The pll/mux details in old device trees will be ignored, but "clocks" properties pointing at the old nodes will still work, and be directed at the corresponding new clock. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-20 04:29:54 +00:00
.get_parent = mux_get_parent,
.set_parent = mux_set_parent,
clk: add PowerPC corenet clock driver support This adds the clock driver for Freescale PowerPC corenet series SoCs using common clock infrastructure. Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com> Signed-off-by: Li Yang <leoli@freescale.com> Signed-off-by: Mike Turquette <mturquette@linaro.org>
2013-04-09 08:46:26 +00:00
};
clk: qoriq: Move chip-specific knowledge into driver The device tree should describe the chips (or chip-like subblocks) in the system, but it generally does not describe individual registers -- it should identify, rather than describe, a programming interface. This has not been the case with the QorIQ clockgen nodes. The knowledge of what each bit setting of CLKCnCSR means is encoded in three places (binding, pll node, and mux node), and the last also needs to know which options are valid on a particular chip. All three of these locations are considered stable ABI, making it difficult to fix mistakes (of which I have found several), much less refactor the abstraction to be able to address problems, limitations, or new chips. Under the current binding, a pll clock specifier of 2 means that the PLL is divided by 4 -- and the driver implements this, unless there happen to be four clock-output-names rather than 3, in which case it interprets it as PLL divided by 3. This does not appear in the binding documentation at all. That hack is now considered stable ABI. The current device tree nodes contain errors, such as saying that T1040 can set a core clock to PLL/4 when only PLL and PLL/2 are options. The current binding also ignores some restrictions on clock selection, such as p5020's requirement that if a core uses the "wrong" PLL, that PLL must be clocked lower than the "correct" PLL and be at most 80% of the rated CPU frequency. Possibly because of the lack of the ability to express such nuance in the binding, some valid options are omitted from the device trees, such as the ability on p4080 to run cores 0-3 from PLL3 and cores 4-7 from PLL1 (again, only if they are at most 80% of rated CPU frequency). This omission, combined with excessive caution in the cpufreq driver (addressed in a subsequent patch), means that currently on a 1500 MHz p4080 with typical PLL configuration, cpufreq can lower the frequency to 1200 MHz on half the CPUs and do nothing on the others. With this patchset, all CPUs can be lowered to 1200 MHz on a rev2 p4080, and on a rev3 p4080 half can be lowered to 750 MHz and the other half to 600 MHz. The current binding only deals with CPU clocks. To describe FMan in the device tree, we need to describe its clock. Some chips have additional muxes that work like the CPU muxes, but are not described in the device tree. Others require inspecting the Reset Control Word to determine which PLL is used. Rather than continue to extend this mess, replace it. Have the driver bind to the chip-specific clockgen compatible, and keep the detailed description of quirky chip variations in the driver, where it can be easily fixed, refactored, and extended. Older device trees will continue to work (including a workaround for old ls1021a device trees that are missing compatible and reg in the clockgen node, which even the old binding required). The pll/mux details in old device trees will be ignored, but "clocks" properties pointing at the old nodes will still work, and be directed at the corresponding new clock. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-20 04:29:54 +00:00
/*
* Don't allow setting for now, as the clock options haven't been
* sanitized for additional restrictions.
*/
static const struct clk_ops hwaccel_ops = {
.get_parent = mux_get_parent,
};
static const struct clockgen_pll_div *get_pll_div(struct clockgen *cg,
struct mux_hwclock *hwc,
int idx)
clk: add PowerPC corenet clock driver support This adds the clock driver for Freescale PowerPC corenet series SoCs using common clock infrastructure. Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com> Signed-off-by: Li Yang <leoli@freescale.com> Signed-off-by: Mike Turquette <mturquette@linaro.org>
2013-04-09 08:46:26 +00:00
{
clk: qoriq: Move chip-specific knowledge into driver The device tree should describe the chips (or chip-like subblocks) in the system, but it generally does not describe individual registers -- it should identify, rather than describe, a programming interface. This has not been the case with the QorIQ clockgen nodes. The knowledge of what each bit setting of CLKCnCSR means is encoded in three places (binding, pll node, and mux node), and the last also needs to know which options are valid on a particular chip. All three of these locations are considered stable ABI, making it difficult to fix mistakes (of which I have found several), much less refactor the abstraction to be able to address problems, limitations, or new chips. Under the current binding, a pll clock specifier of 2 means that the PLL is divided by 4 -- and the driver implements this, unless there happen to be four clock-output-names rather than 3, in which case it interprets it as PLL divided by 3. This does not appear in the binding documentation at all. That hack is now considered stable ABI. The current device tree nodes contain errors, such as saying that T1040 can set a core clock to PLL/4 when only PLL and PLL/2 are options. The current binding also ignores some restrictions on clock selection, such as p5020's requirement that if a core uses the "wrong" PLL, that PLL must be clocked lower than the "correct" PLL and be at most 80% of the rated CPU frequency. Possibly because of the lack of the ability to express such nuance in the binding, some valid options are omitted from the device trees, such as the ability on p4080 to run cores 0-3 from PLL3 and cores 4-7 from PLL1 (again, only if they are at most 80% of rated CPU frequency). This omission, combined with excessive caution in the cpufreq driver (addressed in a subsequent patch), means that currently on a 1500 MHz p4080 with typical PLL configuration, cpufreq can lower the frequency to 1200 MHz on half the CPUs and do nothing on the others. With this patchset, all CPUs can be lowered to 1200 MHz on a rev2 p4080, and on a rev3 p4080 half can be lowered to 750 MHz and the other half to 600 MHz. The current binding only deals with CPU clocks. To describe FMan in the device tree, we need to describe its clock. Some chips have additional muxes that work like the CPU muxes, but are not described in the device tree. Others require inspecting the Reset Control Word to determine which PLL is used. Rather than continue to extend this mess, replace it. Have the driver bind to the chip-specific clockgen compatible, and keep the detailed description of quirky chip variations in the driver, where it can be easily fixed, refactored, and extended. Older device trees will continue to work (including a workaround for old ls1021a device trees that are missing compatible and reg in the clockgen node, which even the old binding required). The pll/mux details in old device trees will be ignored, but "clocks" properties pointing at the old nodes will still work, and be directed at the corresponding new clock. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-20 04:29:54 +00:00
int pll, div;
clk: add PowerPC corenet clock driver support This adds the clock driver for Freescale PowerPC corenet series SoCs using common clock infrastructure. Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com> Signed-off-by: Li Yang <leoli@freescale.com> Signed-off-by: Mike Turquette <mturquette@linaro.org>
2013-04-09 08:46:26 +00:00
clk: qoriq: Move chip-specific knowledge into driver The device tree should describe the chips (or chip-like subblocks) in the system, but it generally does not describe individual registers -- it should identify, rather than describe, a programming interface. This has not been the case with the QorIQ clockgen nodes. The knowledge of what each bit setting of CLKCnCSR means is encoded in three places (binding, pll node, and mux node), and the last also needs to know which options are valid on a particular chip. All three of these locations are considered stable ABI, making it difficult to fix mistakes (of which I have found several), much less refactor the abstraction to be able to address problems, limitations, or new chips. Under the current binding, a pll clock specifier of 2 means that the PLL is divided by 4 -- and the driver implements this, unless there happen to be four clock-output-names rather than 3, in which case it interprets it as PLL divided by 3. This does not appear in the binding documentation at all. That hack is now considered stable ABI. The current device tree nodes contain errors, such as saying that T1040 can set a core clock to PLL/4 when only PLL and PLL/2 are options. The current binding also ignores some restrictions on clock selection, such as p5020's requirement that if a core uses the "wrong" PLL, that PLL must be clocked lower than the "correct" PLL and be at most 80% of the rated CPU frequency. Possibly because of the lack of the ability to express such nuance in the binding, some valid options are omitted from the device trees, such as the ability on p4080 to run cores 0-3 from PLL3 and cores 4-7 from PLL1 (again, only if they are at most 80% of rated CPU frequency). This omission, combined with excessive caution in the cpufreq driver (addressed in a subsequent patch), means that currently on a 1500 MHz p4080 with typical PLL configuration, cpufreq can lower the frequency to 1200 MHz on half the CPUs and do nothing on the others. With this patchset, all CPUs can be lowered to 1200 MHz on a rev2 p4080, and on a rev3 p4080 half can be lowered to 750 MHz and the other half to 600 MHz. The current binding only deals with CPU clocks. To describe FMan in the device tree, we need to describe its clock. Some chips have additional muxes that work like the CPU muxes, but are not described in the device tree. Others require inspecting the Reset Control Word to determine which PLL is used. Rather than continue to extend this mess, replace it. Have the driver bind to the chip-specific clockgen compatible, and keep the detailed description of quirky chip variations in the driver, where it can be easily fixed, refactored, and extended. Older device trees will continue to work (including a workaround for old ls1021a device trees that are missing compatible and reg in the clockgen node, which even the old binding required). The pll/mux details in old device trees will be ignored, but "clocks" properties pointing at the old nodes will still work, and be directed at the corresponding new clock. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-20 04:29:54 +00:00
if (!(hwc->info->clksel[idx].flags & CLKSEL_VALID))
return NULL;
clk: add PowerPC corenet clock driver support This adds the clock driver for Freescale PowerPC corenet series SoCs using common clock infrastructure. Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com> Signed-off-by: Li Yang <leoli@freescale.com> Signed-off-by: Mike Turquette <mturquette@linaro.org>
2013-04-09 08:46:26 +00:00
clk: qoriq: Move chip-specific knowledge into driver The device tree should describe the chips (or chip-like subblocks) in the system, but it generally does not describe individual registers -- it should identify, rather than describe, a programming interface. This has not been the case with the QorIQ clockgen nodes. The knowledge of what each bit setting of CLKCnCSR means is encoded in three places (binding, pll node, and mux node), and the last also needs to know which options are valid on a particular chip. All three of these locations are considered stable ABI, making it difficult to fix mistakes (of which I have found several), much less refactor the abstraction to be able to address problems, limitations, or new chips. Under the current binding, a pll clock specifier of 2 means that the PLL is divided by 4 -- and the driver implements this, unless there happen to be four clock-output-names rather than 3, in which case it interprets it as PLL divided by 3. This does not appear in the binding documentation at all. That hack is now considered stable ABI. The current device tree nodes contain errors, such as saying that T1040 can set a core clock to PLL/4 when only PLL and PLL/2 are options. The current binding also ignores some restrictions on clock selection, such as p5020's requirement that if a core uses the "wrong" PLL, that PLL must be clocked lower than the "correct" PLL and be at most 80% of the rated CPU frequency. Possibly because of the lack of the ability to express such nuance in the binding, some valid options are omitted from the device trees, such as the ability on p4080 to run cores 0-3 from PLL3 and cores 4-7 from PLL1 (again, only if they are at most 80% of rated CPU frequency). This omission, combined with excessive caution in the cpufreq driver (addressed in a subsequent patch), means that currently on a 1500 MHz p4080 with typical PLL configuration, cpufreq can lower the frequency to 1200 MHz on half the CPUs and do nothing on the others. With this patchset, all CPUs can be lowered to 1200 MHz on a rev2 p4080, and on a rev3 p4080 half can be lowered to 750 MHz and the other half to 600 MHz. The current binding only deals with CPU clocks. To describe FMan in the device tree, we need to describe its clock. Some chips have additional muxes that work like the CPU muxes, but are not described in the device tree. Others require inspecting the Reset Control Word to determine which PLL is used. Rather than continue to extend this mess, replace it. Have the driver bind to the chip-specific clockgen compatible, and keep the detailed description of quirky chip variations in the driver, where it can be easily fixed, refactored, and extended. Older device trees will continue to work (including a workaround for old ls1021a device trees that are missing compatible and reg in the clockgen node, which even the old binding required). The pll/mux details in old device trees will be ignored, but "clocks" properties pointing at the old nodes will still work, and be directed at the corresponding new clock. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-20 04:29:54 +00:00
pll = hwc->info->clksel[idx].pll;
div = hwc->info->clksel[idx].div;
clk: add PowerPC corenet clock driver support This adds the clock driver for Freescale PowerPC corenet series SoCs using common clock infrastructure. Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com> Signed-off-by: Li Yang <leoli@freescale.com> Signed-off-by: Mike Turquette <mturquette@linaro.org>
2013-04-09 08:46:26 +00:00
clk: qoriq: Move chip-specific knowledge into driver The device tree should describe the chips (or chip-like subblocks) in the system, but it generally does not describe individual registers -- it should identify, rather than describe, a programming interface. This has not been the case with the QorIQ clockgen nodes. The knowledge of what each bit setting of CLKCnCSR means is encoded in three places (binding, pll node, and mux node), and the last also needs to know which options are valid on a particular chip. All three of these locations are considered stable ABI, making it difficult to fix mistakes (of which I have found several), much less refactor the abstraction to be able to address problems, limitations, or new chips. Under the current binding, a pll clock specifier of 2 means that the PLL is divided by 4 -- and the driver implements this, unless there happen to be four clock-output-names rather than 3, in which case it interprets it as PLL divided by 3. This does not appear in the binding documentation at all. That hack is now considered stable ABI. The current device tree nodes contain errors, such as saying that T1040 can set a core clock to PLL/4 when only PLL and PLL/2 are options. The current binding also ignores some restrictions on clock selection, such as p5020's requirement that if a core uses the "wrong" PLL, that PLL must be clocked lower than the "correct" PLL and be at most 80% of the rated CPU frequency. Possibly because of the lack of the ability to express such nuance in the binding, some valid options are omitted from the device trees, such as the ability on p4080 to run cores 0-3 from PLL3 and cores 4-7 from PLL1 (again, only if they are at most 80% of rated CPU frequency). This omission, combined with excessive caution in the cpufreq driver (addressed in a subsequent patch), means that currently on a 1500 MHz p4080 with typical PLL configuration, cpufreq can lower the frequency to 1200 MHz on half the CPUs and do nothing on the others. With this patchset, all CPUs can be lowered to 1200 MHz on a rev2 p4080, and on a rev3 p4080 half can be lowered to 750 MHz and the other half to 600 MHz. The current binding only deals with CPU clocks. To describe FMan in the device tree, we need to describe its clock. Some chips have additional muxes that work like the CPU muxes, but are not described in the device tree. Others require inspecting the Reset Control Word to determine which PLL is used. Rather than continue to extend this mess, replace it. Have the driver bind to the chip-specific clockgen compatible, and keep the detailed description of quirky chip variations in the driver, where it can be easily fixed, refactored, and extended. Older device trees will continue to work (including a workaround for old ls1021a device trees that are missing compatible and reg in the clockgen node, which even the old binding required). The pll/mux details in old device trees will be ignored, but "clocks" properties pointing at the old nodes will still work, and be directed at the corresponding new clock. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-20 04:29:54 +00:00
return &cg->pll[pll].div[div];
}
clk: add PowerPC corenet clock driver support This adds the clock driver for Freescale PowerPC corenet series SoCs using common clock infrastructure. Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com> Signed-off-by: Li Yang <leoli@freescale.com> Signed-off-by: Mike Turquette <mturquette@linaro.org>
2013-04-09 08:46:26 +00:00
clk: qoriq: Move chip-specific knowledge into driver The device tree should describe the chips (or chip-like subblocks) in the system, but it generally does not describe individual registers -- it should identify, rather than describe, a programming interface. This has not been the case with the QorIQ clockgen nodes. The knowledge of what each bit setting of CLKCnCSR means is encoded in three places (binding, pll node, and mux node), and the last also needs to know which options are valid on a particular chip. All three of these locations are considered stable ABI, making it difficult to fix mistakes (of which I have found several), much less refactor the abstraction to be able to address problems, limitations, or new chips. Under the current binding, a pll clock specifier of 2 means that the PLL is divided by 4 -- and the driver implements this, unless there happen to be four clock-output-names rather than 3, in which case it interprets it as PLL divided by 3. This does not appear in the binding documentation at all. That hack is now considered stable ABI. The current device tree nodes contain errors, such as saying that T1040 can set a core clock to PLL/4 when only PLL and PLL/2 are options. The current binding also ignores some restrictions on clock selection, such as p5020's requirement that if a core uses the "wrong" PLL, that PLL must be clocked lower than the "correct" PLL and be at most 80% of the rated CPU frequency. Possibly because of the lack of the ability to express such nuance in the binding, some valid options are omitted from the device trees, such as the ability on p4080 to run cores 0-3 from PLL3 and cores 4-7 from PLL1 (again, only if they are at most 80% of rated CPU frequency). This omission, combined with excessive caution in the cpufreq driver (addressed in a subsequent patch), means that currently on a 1500 MHz p4080 with typical PLL configuration, cpufreq can lower the frequency to 1200 MHz on half the CPUs and do nothing on the others. With this patchset, all CPUs can be lowered to 1200 MHz on a rev2 p4080, and on a rev3 p4080 half can be lowered to 750 MHz and the other half to 600 MHz. The current binding only deals with CPU clocks. To describe FMan in the device tree, we need to describe its clock. Some chips have additional muxes that work like the CPU muxes, but are not described in the device tree. Others require inspecting the Reset Control Word to determine which PLL is used. Rather than continue to extend this mess, replace it. Have the driver bind to the chip-specific clockgen compatible, and keep the detailed description of quirky chip variations in the driver, where it can be easily fixed, refactored, and extended. Older device trees will continue to work (including a workaround for old ls1021a device trees that are missing compatible and reg in the clockgen node, which even the old binding required). The pll/mux details in old device trees will be ignored, but "clocks" properties pointing at the old nodes will still work, and be directed at the corresponding new clock. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-20 04:29:54 +00:00
static struct clk * __init create_mux_common(struct clockgen *cg,
struct mux_hwclock *hwc,
const struct clk_ops *ops,
unsigned long min_rate,
unsigned long pct80_rate,
const char *fmt, int idx)
{
struct clk_init_data init = {};
struct clk *clk;
const struct clockgen_pll_div *div;
const char *parent_names[NUM_MUX_PARENTS];
char name[32];
int i, j;
clk: qoriq: Fix checkpatch type OOM_MESSAGE WARNING:OOM_MESSAGE: Possible unnecessary 'out of memory' message + if (!parent_names) { + pr_err("%s: could not allocate parent_names\n", __func__); WARNING:OOM_MESSAGE: Possible unnecessary 'out of memory' message + if (!cmux_clk) { + pr_err("%s: could not allocate cmux_clk\n", __func__); WARNING:OOM_MESSAGE: Possible unnecessary 'out of memory' message + if (!subclks) { + pr_err("%s: could not allocate subclks\n", __func__); WARNING:OOM_MESSAGE: Possible unnecessary 'out of memory' message + if (!onecell_data) { + pr_err("%s: could not allocate onecell_data\n", __func__); Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com> Signed-off-by: Michael Turquette <mturquette@linaro.org>
2015-01-21 10:03:26 +00:00
clk: qoriq: Move chip-specific knowledge into driver The device tree should describe the chips (or chip-like subblocks) in the system, but it generally does not describe individual registers -- it should identify, rather than describe, a programming interface. This has not been the case with the QorIQ clockgen nodes. The knowledge of what each bit setting of CLKCnCSR means is encoded in three places (binding, pll node, and mux node), and the last also needs to know which options are valid on a particular chip. All three of these locations are considered stable ABI, making it difficult to fix mistakes (of which I have found several), much less refactor the abstraction to be able to address problems, limitations, or new chips. Under the current binding, a pll clock specifier of 2 means that the PLL is divided by 4 -- and the driver implements this, unless there happen to be four clock-output-names rather than 3, in which case it interprets it as PLL divided by 3. This does not appear in the binding documentation at all. That hack is now considered stable ABI. The current device tree nodes contain errors, such as saying that T1040 can set a core clock to PLL/4 when only PLL and PLL/2 are options. The current binding also ignores some restrictions on clock selection, such as p5020's requirement that if a core uses the "wrong" PLL, that PLL must be clocked lower than the "correct" PLL and be at most 80% of the rated CPU frequency. Possibly because of the lack of the ability to express such nuance in the binding, some valid options are omitted from the device trees, such as the ability on p4080 to run cores 0-3 from PLL3 and cores 4-7 from PLL1 (again, only if they are at most 80% of rated CPU frequency). This omission, combined with excessive caution in the cpufreq driver (addressed in a subsequent patch), means that currently on a 1500 MHz p4080 with typical PLL configuration, cpufreq can lower the frequency to 1200 MHz on half the CPUs and do nothing on the others. With this patchset, all CPUs can be lowered to 1200 MHz on a rev2 p4080, and on a rev3 p4080 half can be lowered to 750 MHz and the other half to 600 MHz. The current binding only deals with CPU clocks. To describe FMan in the device tree, we need to describe its clock. Some chips have additional muxes that work like the CPU muxes, but are not described in the device tree. Others require inspecting the Reset Control Word to determine which PLL is used. Rather than continue to extend this mess, replace it. Have the driver bind to the chip-specific clockgen compatible, and keep the detailed description of quirky chip variations in the driver, where it can be easily fixed, refactored, and extended. Older device trees will continue to work (including a workaround for old ls1021a device trees that are missing compatible and reg in the clockgen node, which even the old binding required). The pll/mux details in old device trees will be ignored, but "clocks" properties pointing at the old nodes will still work, and be directed at the corresponding new clock. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-20 04:29:54 +00:00
snprintf(name, sizeof(name), fmt, idx);
clk: add PowerPC corenet clock driver support This adds the clock driver for Freescale PowerPC corenet series SoCs using common clock infrastructure. Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com> Signed-off-by: Li Yang <leoli@freescale.com> Signed-off-by: Mike Turquette <mturquette@linaro.org>
2013-04-09 08:46:26 +00:00
clk: qoriq: Move chip-specific knowledge into driver The device tree should describe the chips (or chip-like subblocks) in the system, but it generally does not describe individual registers -- it should identify, rather than describe, a programming interface. This has not been the case with the QorIQ clockgen nodes. The knowledge of what each bit setting of CLKCnCSR means is encoded in three places (binding, pll node, and mux node), and the last also needs to know which options are valid on a particular chip. All three of these locations are considered stable ABI, making it difficult to fix mistakes (of which I have found several), much less refactor the abstraction to be able to address problems, limitations, or new chips. Under the current binding, a pll clock specifier of 2 means that the PLL is divided by 4 -- and the driver implements this, unless there happen to be four clock-output-names rather than 3, in which case it interprets it as PLL divided by 3. This does not appear in the binding documentation at all. That hack is now considered stable ABI. The current device tree nodes contain errors, such as saying that T1040 can set a core clock to PLL/4 when only PLL and PLL/2 are options. The current binding also ignores some restrictions on clock selection, such as p5020's requirement that if a core uses the "wrong" PLL, that PLL must be clocked lower than the "correct" PLL and be at most 80% of the rated CPU frequency. Possibly because of the lack of the ability to express such nuance in the binding, some valid options are omitted from the device trees, such as the ability on p4080 to run cores 0-3 from PLL3 and cores 4-7 from PLL1 (again, only if they are at most 80% of rated CPU frequency). This omission, combined with excessive caution in the cpufreq driver (addressed in a subsequent patch), means that currently on a 1500 MHz p4080 with typical PLL configuration, cpufreq can lower the frequency to 1200 MHz on half the CPUs and do nothing on the others. With this patchset, all CPUs can be lowered to 1200 MHz on a rev2 p4080, and on a rev3 p4080 half can be lowered to 750 MHz and the other half to 600 MHz. The current binding only deals with CPU clocks. To describe FMan in the device tree, we need to describe its clock. Some chips have additional muxes that work like the CPU muxes, but are not described in the device tree. Others require inspecting the Reset Control Word to determine which PLL is used. Rather than continue to extend this mess, replace it. Have the driver bind to the chip-specific clockgen compatible, and keep the detailed description of quirky chip variations in the driver, where it can be easily fixed, refactored, and extended. Older device trees will continue to work (including a workaround for old ls1021a device trees that are missing compatible and reg in the clockgen node, which even the old binding required). The pll/mux details in old device trees will be ignored, but "clocks" properties pointing at the old nodes will still work, and be directed at the corresponding new clock. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-20 04:29:54 +00:00
for (i = 0, j = 0; i < NUM_MUX_PARENTS; i++) {
unsigned long rate;
clock: redefine variable clocks_per_pll as a struct member redefine variable clocks_per_pll as a struct member If there are multiple PLL clock nodes, this variable will get overwritten. Redefining it as a struct member can avoid that. Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com> Signed-off-by: Michael Turquette <mturquette@linaro.org>
2015-01-15 06:03:40 +00:00
clk: qoriq: Move chip-specific knowledge into driver The device tree should describe the chips (or chip-like subblocks) in the system, but it generally does not describe individual registers -- it should identify, rather than describe, a programming interface. This has not been the case with the QorIQ clockgen nodes. The knowledge of what each bit setting of CLKCnCSR means is encoded in three places (binding, pll node, and mux node), and the last also needs to know which options are valid on a particular chip. All three of these locations are considered stable ABI, making it difficult to fix mistakes (of which I have found several), much less refactor the abstraction to be able to address problems, limitations, or new chips. Under the current binding, a pll clock specifier of 2 means that the PLL is divided by 4 -- and the driver implements this, unless there happen to be four clock-output-names rather than 3, in which case it interprets it as PLL divided by 3. This does not appear in the binding documentation at all. That hack is now considered stable ABI. The current device tree nodes contain errors, such as saying that T1040 can set a core clock to PLL/4 when only PLL and PLL/2 are options. The current binding also ignores some restrictions on clock selection, such as p5020's requirement that if a core uses the "wrong" PLL, that PLL must be clocked lower than the "correct" PLL and be at most 80% of the rated CPU frequency. Possibly because of the lack of the ability to express such nuance in the binding, some valid options are omitted from the device trees, such as the ability on p4080 to run cores 0-3 from PLL3 and cores 4-7 from PLL1 (again, only if they are at most 80% of rated CPU frequency). This omission, combined with excessive caution in the cpufreq driver (addressed in a subsequent patch), means that currently on a 1500 MHz p4080 with typical PLL configuration, cpufreq can lower the frequency to 1200 MHz on half the CPUs and do nothing on the others. With this patchset, all CPUs can be lowered to 1200 MHz on a rev2 p4080, and on a rev3 p4080 half can be lowered to 750 MHz and the other half to 600 MHz. The current binding only deals with CPU clocks. To describe FMan in the device tree, we need to describe its clock. Some chips have additional muxes that work like the CPU muxes, but are not described in the device tree. Others require inspecting the Reset Control Word to determine which PLL is used. Rather than continue to extend this mess, replace it. Have the driver bind to the chip-specific clockgen compatible, and keep the detailed description of quirky chip variations in the driver, where it can be easily fixed, refactored, and extended. Older device trees will continue to work (including a workaround for old ls1021a device trees that are missing compatible and reg in the clockgen node, which even the old binding required). The pll/mux details in old device trees will be ignored, but "clocks" properties pointing at the old nodes will still work, and be directed at the corresponding new clock. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-20 04:29:54 +00:00
hwc->clksel_to_parent[i] = -1;
clock: redefine variable clocks_per_pll as a struct member redefine variable clocks_per_pll as a struct member If there are multiple PLL clock nodes, this variable will get overwritten. Redefining it as a struct member can avoid that. Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com> Signed-off-by: Michael Turquette <mturquette@linaro.org>
2015-01-15 06:03:40 +00:00
clk: qoriq: Move chip-specific knowledge into driver The device tree should describe the chips (or chip-like subblocks) in the system, but it generally does not describe individual registers -- it should identify, rather than describe, a programming interface. This has not been the case with the QorIQ clockgen nodes. The knowledge of what each bit setting of CLKCnCSR means is encoded in three places (binding, pll node, and mux node), and the last also needs to know which options are valid on a particular chip. All three of these locations are considered stable ABI, making it difficult to fix mistakes (of which I have found several), much less refactor the abstraction to be able to address problems, limitations, or new chips. Under the current binding, a pll clock specifier of 2 means that the PLL is divided by 4 -- and the driver implements this, unless there happen to be four clock-output-names rather than 3, in which case it interprets it as PLL divided by 3. This does not appear in the binding documentation at all. That hack is now considered stable ABI. The current device tree nodes contain errors, such as saying that T1040 can set a core clock to PLL/4 when only PLL and PLL/2 are options. The current binding also ignores some restrictions on clock selection, such as p5020's requirement that if a core uses the "wrong" PLL, that PLL must be clocked lower than the "correct" PLL and be at most 80% of the rated CPU frequency. Possibly because of the lack of the ability to express such nuance in the binding, some valid options are omitted from the device trees, such as the ability on p4080 to run cores 0-3 from PLL3 and cores 4-7 from PLL1 (again, only if they are at most 80% of rated CPU frequency). This omission, combined with excessive caution in the cpufreq driver (addressed in a subsequent patch), means that currently on a 1500 MHz p4080 with typical PLL configuration, cpufreq can lower the frequency to 1200 MHz on half the CPUs and do nothing on the others. With this patchset, all CPUs can be lowered to 1200 MHz on a rev2 p4080, and on a rev3 p4080 half can be lowered to 750 MHz and the other half to 600 MHz. The current binding only deals with CPU clocks. To describe FMan in the device tree, we need to describe its clock. Some chips have additional muxes that work like the CPU muxes, but are not described in the device tree. Others require inspecting the Reset Control Word to determine which PLL is used. Rather than continue to extend this mess, replace it. Have the driver bind to the chip-specific clockgen compatible, and keep the detailed description of quirky chip variations in the driver, where it can be easily fixed, refactored, and extended. Older device trees will continue to work (including a workaround for old ls1021a device trees that are missing compatible and reg in the clockgen node, which even the old binding required). The pll/mux details in old device trees will be ignored, but "clocks" properties pointing at the old nodes will still work, and be directed at the corresponding new clock. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-20 04:29:54 +00:00
div = get_pll_div(cg, hwc, i);
if (!div)
continue;
clk: add PowerPC corenet clock driver support This adds the clock driver for Freescale PowerPC corenet series SoCs using common clock infrastructure. Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com> Signed-off-by: Li Yang <leoli@freescale.com> Signed-off-by: Mike Turquette <mturquette@linaro.org>
2013-04-09 08:46:26 +00:00
clk: qoriq: Move chip-specific knowledge into driver The device tree should describe the chips (or chip-like subblocks) in the system, but it generally does not describe individual registers -- it should identify, rather than describe, a programming interface. This has not been the case with the QorIQ clockgen nodes. The knowledge of what each bit setting of CLKCnCSR means is encoded in three places (binding, pll node, and mux node), and the last also needs to know which options are valid on a particular chip. All three of these locations are considered stable ABI, making it difficult to fix mistakes (of which I have found several), much less refactor the abstraction to be able to address problems, limitations, or new chips. Under the current binding, a pll clock specifier of 2 means that the PLL is divided by 4 -- and the driver implements this, unless there happen to be four clock-output-names rather than 3, in which case it interprets it as PLL divided by 3. This does not appear in the binding documentation at all. That hack is now considered stable ABI. The current device tree nodes contain errors, such as saying that T1040 can set a core clock to PLL/4 when only PLL and PLL/2 are options. The current binding also ignores some restrictions on clock selection, such as p5020's requirement that if a core uses the "wrong" PLL, that PLL must be clocked lower than the "correct" PLL and be at most 80% of the rated CPU frequency. Possibly because of the lack of the ability to express such nuance in the binding, some valid options are omitted from the device trees, such as the ability on p4080 to run cores 0-3 from PLL3 and cores 4-7 from PLL1 (again, only if they are at most 80% of rated CPU frequency). This omission, combined with excessive caution in the cpufreq driver (addressed in a subsequent patch), means that currently on a 1500 MHz p4080 with typical PLL configuration, cpufreq can lower the frequency to 1200 MHz on half the CPUs and do nothing on the others. With this patchset, all CPUs can be lowered to 1200 MHz on a rev2 p4080, and on a rev3 p4080 half can be lowered to 750 MHz and the other half to 600 MHz. The current binding only deals with CPU clocks. To describe FMan in the device tree, we need to describe its clock. Some chips have additional muxes that work like the CPU muxes, but are not described in the device tree. Others require inspecting the Reset Control Word to determine which PLL is used. Rather than continue to extend this mess, replace it. Have the driver bind to the chip-specific clockgen compatible, and keep the detailed description of quirky chip variations in the driver, where it can be easily fixed, refactored, and extended. Older device trees will continue to work (including a workaround for old ls1021a device trees that are missing compatible and reg in the clockgen node, which even the old binding required). The pll/mux details in old device trees will be ignored, but "clocks" properties pointing at the old nodes will still work, and be directed at the corresponding new clock. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-20 04:29:54 +00:00
rate = clk_get_rate(div->clk);
if (hwc->info->clksel[i].flags & CLKSEL_80PCT &&
rate > pct80_rate)
continue;
if (rate < min_rate)
continue;
parent_names[j] = div->name;
hwc->parent_to_clksel[j] = i;
hwc->clksel_to_parent[i] = j;
j++;
clk: add PowerPC corenet clock driver support This adds the clock driver for Freescale PowerPC corenet series SoCs using common clock infrastructure. Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com> Signed-off-by: Li Yang <leoli@freescale.com> Signed-off-by: Mike Turquette <mturquette@linaro.org>
2013-04-09 08:46:26 +00:00
}
clk: qoriq: Move chip-specific knowledge into driver The device tree should describe the chips (or chip-like subblocks) in the system, but it generally does not describe individual registers -- it should identify, rather than describe, a programming interface. This has not been the case with the QorIQ clockgen nodes. The knowledge of what each bit setting of CLKCnCSR means is encoded in three places (binding, pll node, and mux node), and the last also needs to know which options are valid on a particular chip. All three of these locations are considered stable ABI, making it difficult to fix mistakes (of which I have found several), much less refactor the abstraction to be able to address problems, limitations, or new chips. Under the current binding, a pll clock specifier of 2 means that the PLL is divided by 4 -- and the driver implements this, unless there happen to be four clock-output-names rather than 3, in which case it interprets it as PLL divided by 3. This does not appear in the binding documentation at all. That hack is now considered stable ABI. The current device tree nodes contain errors, such as saying that T1040 can set a core clock to PLL/4 when only PLL and PLL/2 are options. The current binding also ignores some restrictions on clock selection, such as p5020's requirement that if a core uses the "wrong" PLL, that PLL must be clocked lower than the "correct" PLL and be at most 80% of the rated CPU frequency. Possibly because of the lack of the ability to express such nuance in the binding, some valid options are omitted from the device trees, such as the ability on p4080 to run cores 0-3 from PLL3 and cores 4-7 from PLL1 (again, only if they are at most 80% of rated CPU frequency). This omission, combined with excessive caution in the cpufreq driver (addressed in a subsequent patch), means that currently on a 1500 MHz p4080 with typical PLL configuration, cpufreq can lower the frequency to 1200 MHz on half the CPUs and do nothing on the others. With this patchset, all CPUs can be lowered to 1200 MHz on a rev2 p4080, and on a rev3 p4080 half can be lowered to 750 MHz and the other half to 600 MHz. The current binding only deals with CPU clocks. To describe FMan in the device tree, we need to describe its clock. Some chips have additional muxes that work like the CPU muxes, but are not described in the device tree. Others require inspecting the Reset Control Word to determine which PLL is used. Rather than continue to extend this mess, replace it. Have the driver bind to the chip-specific clockgen compatible, and keep the detailed description of quirky chip variations in the driver, where it can be easily fixed, refactored, and extended. Older device trees will continue to work (including a workaround for old ls1021a device trees that are missing compatible and reg in the clockgen node, which even the old binding required). The pll/mux details in old device trees will be ignored, but "clocks" properties pointing at the old nodes will still work, and be directed at the corresponding new clock. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-20 04:29:54 +00:00
init.name = name;
init.ops = ops;
clk: add PowerPC corenet clock driver support This adds the clock driver for Freescale PowerPC corenet series SoCs using common clock infrastructure. Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com> Signed-off-by: Li Yang <leoli@freescale.com> Signed-off-by: Mike Turquette <mturquette@linaro.org>
2013-04-09 08:46:26 +00:00
init.parent_names = parent_names;
clk: qoriq: Move chip-specific knowledge into driver The device tree should describe the chips (or chip-like subblocks) in the system, but it generally does not describe individual registers -- it should identify, rather than describe, a programming interface. This has not been the case with the QorIQ clockgen nodes. The knowledge of what each bit setting of CLKCnCSR means is encoded in three places (binding, pll node, and mux node), and the last also needs to know which options are valid on a particular chip. All three of these locations are considered stable ABI, making it difficult to fix mistakes (of which I have found several), much less refactor the abstraction to be able to address problems, limitations, or new chips. Under the current binding, a pll clock specifier of 2 means that the PLL is divided by 4 -- and the driver implements this, unless there happen to be four clock-output-names rather than 3, in which case it interprets it as PLL divided by 3. This does not appear in the binding documentation at all. That hack is now considered stable ABI. The current device tree nodes contain errors, such as saying that T1040 can set a core clock to PLL/4 when only PLL and PLL/2 are options. The current binding also ignores some restrictions on clock selection, such as p5020's requirement that if a core uses the "wrong" PLL, that PLL must be clocked lower than the "correct" PLL and be at most 80% of the rated CPU frequency. Possibly because of the lack of the ability to express such nuance in the binding, some valid options are omitted from the device trees, such as the ability on p4080 to run cores 0-3 from PLL3 and cores 4-7 from PLL1 (again, only if they are at most 80% of rated CPU frequency). This omission, combined with excessive caution in the cpufreq driver (addressed in a subsequent patch), means that currently on a 1500 MHz p4080 with typical PLL configuration, cpufreq can lower the frequency to 1200 MHz on half the CPUs and do nothing on the others. With this patchset, all CPUs can be lowered to 1200 MHz on a rev2 p4080, and on a rev3 p4080 half can be lowered to 750 MHz and the other half to 600 MHz. The current binding only deals with CPU clocks. To describe FMan in the device tree, we need to describe its clock. Some chips have additional muxes that work like the CPU muxes, but are not described in the device tree. Others require inspecting the Reset Control Word to determine which PLL is used. Rather than continue to extend this mess, replace it. Have the driver bind to the chip-specific clockgen compatible, and keep the detailed description of quirky chip variations in the driver, where it can be easily fixed, refactored, and extended. Older device trees will continue to work (including a workaround for old ls1021a device trees that are missing compatible and reg in the clockgen node, which even the old binding required). The pll/mux details in old device trees will be ignored, but "clocks" properties pointing at the old nodes will still work, and be directed at the corresponding new clock. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-20 04:29:54 +00:00
init.num_parents = hwc->num_parents = j;
clk: add PowerPC corenet clock driver support This adds the clock driver for Freescale PowerPC corenet series SoCs using common clock infrastructure. Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com> Signed-off-by: Li Yang <leoli@freescale.com> Signed-off-by: Mike Turquette <mturquette@linaro.org>
2013-04-09 08:46:26 +00:00
init.flags = 0;
clk: qoriq: Move chip-specific knowledge into driver The device tree should describe the chips (or chip-like subblocks) in the system, but it generally does not describe individual registers -- it should identify, rather than describe, a programming interface. This has not been the case with the QorIQ clockgen nodes. The knowledge of what each bit setting of CLKCnCSR means is encoded in three places (binding, pll node, and mux node), and the last also needs to know which options are valid on a particular chip. All three of these locations are considered stable ABI, making it difficult to fix mistakes (of which I have found several), much less refactor the abstraction to be able to address problems, limitations, or new chips. Under the current binding, a pll clock specifier of 2 means that the PLL is divided by 4 -- and the driver implements this, unless there happen to be four clock-output-names rather than 3, in which case it interprets it as PLL divided by 3. This does not appear in the binding documentation at all. That hack is now considered stable ABI. The current device tree nodes contain errors, such as saying that T1040 can set a core clock to PLL/4 when only PLL and PLL/2 are options. The current binding also ignores some restrictions on clock selection, such as p5020's requirement that if a core uses the "wrong" PLL, that PLL must be clocked lower than the "correct" PLL and be at most 80% of the rated CPU frequency. Possibly because of the lack of the ability to express such nuance in the binding, some valid options are omitted from the device trees, such as the ability on p4080 to run cores 0-3 from PLL3 and cores 4-7 from PLL1 (again, only if they are at most 80% of rated CPU frequency). This omission, combined with excessive caution in the cpufreq driver (addressed in a subsequent patch), means that currently on a 1500 MHz p4080 with typical PLL configuration, cpufreq can lower the frequency to 1200 MHz on half the CPUs and do nothing on the others. With this patchset, all CPUs can be lowered to 1200 MHz on a rev2 p4080, and on a rev3 p4080 half can be lowered to 750 MHz and the other half to 600 MHz. The current binding only deals with CPU clocks. To describe FMan in the device tree, we need to describe its clock. Some chips have additional muxes that work like the CPU muxes, but are not described in the device tree. Others require inspecting the Reset Control Word to determine which PLL is used. Rather than continue to extend this mess, replace it. Have the driver bind to the chip-specific clockgen compatible, and keep the detailed description of quirky chip variations in the driver, where it can be easily fixed, refactored, and extended. Older device trees will continue to work (including a workaround for old ls1021a device trees that are missing compatible and reg in the clockgen node, which even the old binding required). The pll/mux details in old device trees will be ignored, but "clocks" properties pointing at the old nodes will still work, and be directed at the corresponding new clock. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-20 04:29:54 +00:00
hwc->hw.init = &init;
hwc->cg = cg;
clk: add PowerPC corenet clock driver support This adds the clock driver for Freescale PowerPC corenet series SoCs using common clock infrastructure. Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com> Signed-off-by: Li Yang <leoli@freescale.com> Signed-off-by: Mike Turquette <mturquette@linaro.org>
2013-04-09 08:46:26 +00:00
clk: qoriq: Move chip-specific knowledge into driver The device tree should describe the chips (or chip-like subblocks) in the system, but it generally does not describe individual registers -- it should identify, rather than describe, a programming interface. This has not been the case with the QorIQ clockgen nodes. The knowledge of what each bit setting of CLKCnCSR means is encoded in three places (binding, pll node, and mux node), and the last also needs to know which options are valid on a particular chip. All three of these locations are considered stable ABI, making it difficult to fix mistakes (of which I have found several), much less refactor the abstraction to be able to address problems, limitations, or new chips. Under the current binding, a pll clock specifier of 2 means that the PLL is divided by 4 -- and the driver implements this, unless there happen to be four clock-output-names rather than 3, in which case it interprets it as PLL divided by 3. This does not appear in the binding documentation at all. That hack is now considered stable ABI. The current device tree nodes contain errors, such as saying that T1040 can set a core clock to PLL/4 when only PLL and PLL/2 are options. The current binding also ignores some restrictions on clock selection, such as p5020's requirement that if a core uses the "wrong" PLL, that PLL must be clocked lower than the "correct" PLL and be at most 80% of the rated CPU frequency. Possibly because of the lack of the ability to express such nuance in the binding, some valid options are omitted from the device trees, such as the ability on p4080 to run cores 0-3 from PLL3 and cores 4-7 from PLL1 (again, only if they are at most 80% of rated CPU frequency). This omission, combined with excessive caution in the cpufreq driver (addressed in a subsequent patch), means that currently on a 1500 MHz p4080 with typical PLL configuration, cpufreq can lower the frequency to 1200 MHz on half the CPUs and do nothing on the others. With this patchset, all CPUs can be lowered to 1200 MHz on a rev2 p4080, and on a rev3 p4080 half can be lowered to 750 MHz and the other half to 600 MHz. The current binding only deals with CPU clocks. To describe FMan in the device tree, we need to describe its clock. Some chips have additional muxes that work like the CPU muxes, but are not described in the device tree. Others require inspecting the Reset Control Word to determine which PLL is used. Rather than continue to extend this mess, replace it. Have the driver bind to the chip-specific clockgen compatible, and keep the detailed description of quirky chip variations in the driver, where it can be easily fixed, refactored, and extended. Older device trees will continue to work (including a workaround for old ls1021a device trees that are missing compatible and reg in the clockgen node, which even the old binding required). The pll/mux details in old device trees will be ignored, but "clocks" properties pointing at the old nodes will still work, and be directed at the corresponding new clock. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-20 04:29:54 +00:00
clk = clk_register(NULL, &hwc->hw);
clk: add PowerPC corenet clock driver support This adds the clock driver for Freescale PowerPC corenet series SoCs using common clock infrastructure. Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com> Signed-off-by: Li Yang <leoli@freescale.com> Signed-off-by: Mike Turquette <mturquette@linaro.org>
2013-04-09 08:46:26 +00:00
if (IS_ERR(clk)) {
clk: qoriq: Move chip-specific knowledge into driver The device tree should describe the chips (or chip-like subblocks) in the system, but it generally does not describe individual registers -- it should identify, rather than describe, a programming interface. This has not been the case with the QorIQ clockgen nodes. The knowledge of what each bit setting of CLKCnCSR means is encoded in three places (binding, pll node, and mux node), and the last also needs to know which options are valid on a particular chip. All three of these locations are considered stable ABI, making it difficult to fix mistakes (of which I have found several), much less refactor the abstraction to be able to address problems, limitations, or new chips. Under the current binding, a pll clock specifier of 2 means that the PLL is divided by 4 -- and the driver implements this, unless there happen to be four clock-output-names rather than 3, in which case it interprets it as PLL divided by 3. This does not appear in the binding documentation at all. That hack is now considered stable ABI. The current device tree nodes contain errors, such as saying that T1040 can set a core clock to PLL/4 when only PLL and PLL/2 are options. The current binding also ignores some restrictions on clock selection, such as p5020's requirement that if a core uses the "wrong" PLL, that PLL must be clocked lower than the "correct" PLL and be at most 80% of the rated CPU frequency. Possibly because of the lack of the ability to express such nuance in the binding, some valid options are omitted from the device trees, such as the ability on p4080 to run cores 0-3 from PLL3 and cores 4-7 from PLL1 (again, only if they are at most 80% of rated CPU frequency). This omission, combined with excessive caution in the cpufreq driver (addressed in a subsequent patch), means that currently on a 1500 MHz p4080 with typical PLL configuration, cpufreq can lower the frequency to 1200 MHz on half the CPUs and do nothing on the others. With this patchset, all CPUs can be lowered to 1200 MHz on a rev2 p4080, and on a rev3 p4080 half can be lowered to 750 MHz and the other half to 600 MHz. The current binding only deals with CPU clocks. To describe FMan in the device tree, we need to describe its clock. Some chips have additional muxes that work like the CPU muxes, but are not described in the device tree. Others require inspecting the Reset Control Word to determine which PLL is used. Rather than continue to extend this mess, replace it. Have the driver bind to the chip-specific clockgen compatible, and keep the detailed description of quirky chip variations in the driver, where it can be easily fixed, refactored, and extended. Older device trees will continue to work (including a workaround for old ls1021a device trees that are missing compatible and reg in the clockgen node, which even the old binding required). The pll/mux details in old device trees will be ignored, but "clocks" properties pointing at the old nodes will still work, and be directed at the corresponding new clock. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-20 04:29:54 +00:00
pr_err("%s: Couldn't register %s: %ld\n", __func__, name,
PTR_ERR(clk));
kfree(hwc);
return NULL;
}
return clk;
}
static struct clk * __init create_one_cmux(struct clockgen *cg, int idx)
{
struct mux_hwclock *hwc;
const struct clockgen_pll_div *div;
unsigned long plat_rate, min_rate;
u64 pct80_rate;
u32 clksel;
hwc = kzalloc(sizeof(*hwc), GFP_KERNEL);
if (!hwc)
return NULL;
hwc->reg = cg->regs + 0x20 * idx;
hwc->info = cg->info.cmux_groups[cg->info.cmux_to_group[idx]];
/*
* Find the rate for the default clksel, and treat it as the
* maximum rated core frequency. If this is an incorrect
* assumption, certain clock options (possibly including the
* default clksel) may be inappropriately excluded on certain
* chips.
*/
clk: qoriq: Add ls2080a support. LS2080A is the first implementation of the chassis 3 clockgen, which has a different register layout than previous chips. It is also little endian, unlike previous chips. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-20 04:29:55 +00:00
clksel = (cg_in(cg, hwc->reg) & CLKSEL_MASK) >> CLKSEL_SHIFT;
clk: qoriq: Move chip-specific knowledge into driver The device tree should describe the chips (or chip-like subblocks) in the system, but it generally does not describe individual registers -- it should identify, rather than describe, a programming interface. This has not been the case with the QorIQ clockgen nodes. The knowledge of what each bit setting of CLKCnCSR means is encoded in three places (binding, pll node, and mux node), and the last also needs to know which options are valid on a particular chip. All three of these locations are considered stable ABI, making it difficult to fix mistakes (of which I have found several), much less refactor the abstraction to be able to address problems, limitations, or new chips. Under the current binding, a pll clock specifier of 2 means that the PLL is divided by 4 -- and the driver implements this, unless there happen to be four clock-output-names rather than 3, in which case it interprets it as PLL divided by 3. This does not appear in the binding documentation at all. That hack is now considered stable ABI. The current device tree nodes contain errors, such as saying that T1040 can set a core clock to PLL/4 when only PLL and PLL/2 are options. The current binding also ignores some restrictions on clock selection, such as p5020's requirement that if a core uses the "wrong" PLL, that PLL must be clocked lower than the "correct" PLL and be at most 80% of the rated CPU frequency. Possibly because of the lack of the ability to express such nuance in the binding, some valid options are omitted from the device trees, such as the ability on p4080 to run cores 0-3 from PLL3 and cores 4-7 from PLL1 (again, only if they are at most 80% of rated CPU frequency). This omission, combined with excessive caution in the cpufreq driver (addressed in a subsequent patch), means that currently on a 1500 MHz p4080 with typical PLL configuration, cpufreq can lower the frequency to 1200 MHz on half the CPUs and do nothing on the others. With this patchset, all CPUs can be lowered to 1200 MHz on a rev2 p4080, and on a rev3 p4080 half can be lowered to 750 MHz and the other half to 600 MHz. The current binding only deals with CPU clocks. To describe FMan in the device tree, we need to describe its clock. Some chips have additional muxes that work like the CPU muxes, but are not described in the device tree. Others require inspecting the Reset Control Word to determine which PLL is used. Rather than continue to extend this mess, replace it. Have the driver bind to the chip-specific clockgen compatible, and keep the detailed description of quirky chip variations in the driver, where it can be easily fixed, refactored, and extended. Older device trees will continue to work (including a workaround for old ls1021a device trees that are missing compatible and reg in the clockgen node, which even the old binding required). The pll/mux details in old device trees will be ignored, but "clocks" properties pointing at the old nodes will still work, and be directed at the corresponding new clock. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-20 04:29:54 +00:00
div = get_pll_div(cg, hwc, clksel);
if (!div)
return NULL;
pct80_rate = clk_get_rate(div->clk);
pct80_rate *= 8;
do_div(pct80_rate, 10);
plat_rate = clk_get_rate(cg->pll[PLATFORM_PLL].div[PLL_DIV1].clk);
if (cg->info.flags & CG_CMUX_GE_PLAT)
min_rate = plat_rate;
else
min_rate = plat_rate / 2;
return create_mux_common(cg, hwc, &cmux_ops, min_rate,
pct80_rate, "cg-cmux%d", idx);
}
static struct clk * __init create_one_hwaccel(struct clockgen *cg, int idx)
{
struct mux_hwclock *hwc;
hwc = kzalloc(sizeof(*hwc), GFP_KERNEL);
if (!hwc)
return NULL;
hwc->reg = cg->regs + 0x20 * idx + 0x10;
hwc->info = cg->info.hwaccel[idx];
return create_mux_common(cg, hwc, &hwaccel_ops, 0, 0,
"cg-hwaccel%d", idx);
}
static void __init create_muxes(struct clockgen *cg)
{
int i;
for (i = 0; i < ARRAY_SIZE(cg->cmux); i++) {
if (cg->info.cmux_to_group[i] < 0)
break;
if (cg->info.cmux_to_group[i] >=
ARRAY_SIZE(cg->info.cmux_groups)) {
WARN_ON_ONCE(1);
continue;
}
cg->cmux[i] = create_one_cmux(cg, i);
clk: add PowerPC corenet clock driver support This adds the clock driver for Freescale PowerPC corenet series SoCs using common clock infrastructure. Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com> Signed-off-by: Li Yang <leoli@freescale.com> Signed-off-by: Mike Turquette <mturquette@linaro.org>
2013-04-09 08:46:26 +00:00
}
clk: qoriq: Move chip-specific knowledge into driver The device tree should describe the chips (or chip-like subblocks) in the system, but it generally does not describe individual registers -- it should identify, rather than describe, a programming interface. This has not been the case with the QorIQ clockgen nodes. The knowledge of what each bit setting of CLKCnCSR means is encoded in three places (binding, pll node, and mux node), and the last also needs to know which options are valid on a particular chip. All three of these locations are considered stable ABI, making it difficult to fix mistakes (of which I have found several), much less refactor the abstraction to be able to address problems, limitations, or new chips. Under the current binding, a pll clock specifier of 2 means that the PLL is divided by 4 -- and the driver implements this, unless there happen to be four clock-output-names rather than 3, in which case it interprets it as PLL divided by 3. This does not appear in the binding documentation at all. That hack is now considered stable ABI. The current device tree nodes contain errors, such as saying that T1040 can set a core clock to PLL/4 when only PLL and PLL/2 are options. The current binding also ignores some restrictions on clock selection, such as p5020's requirement that if a core uses the "wrong" PLL, that PLL must be clocked lower than the "correct" PLL and be at most 80% of the rated CPU frequency. Possibly because of the lack of the ability to express such nuance in the binding, some valid options are omitted from the device trees, such as the ability on p4080 to run cores 0-3 from PLL3 and cores 4-7 from PLL1 (again, only if they are at most 80% of rated CPU frequency). This omission, combined with excessive caution in the cpufreq driver (addressed in a subsequent patch), means that currently on a 1500 MHz p4080 with typical PLL configuration, cpufreq can lower the frequency to 1200 MHz on half the CPUs and do nothing on the others. With this patchset, all CPUs can be lowered to 1200 MHz on a rev2 p4080, and on a rev3 p4080 half can be lowered to 750 MHz and the other half to 600 MHz. The current binding only deals with CPU clocks. To describe FMan in the device tree, we need to describe its clock. Some chips have additional muxes that work like the CPU muxes, but are not described in the device tree. Others require inspecting the Reset Control Word to determine which PLL is used. Rather than continue to extend this mess, replace it. Have the driver bind to the chip-specific clockgen compatible, and keep the detailed description of quirky chip variations in the driver, where it can be easily fixed, refactored, and extended. Older device trees will continue to work (including a workaround for old ls1021a device trees that are missing compatible and reg in the clockgen node, which even the old binding required). The pll/mux details in old device trees will be ignored, but "clocks" properties pointing at the old nodes will still work, and be directed at the corresponding new clock. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-20 04:29:54 +00:00
for (i = 0; i < ARRAY_SIZE(cg->hwaccel); i++) {
if (!cg->info.hwaccel[i])
continue;
cg->hwaccel[i] = create_one_hwaccel(cg, i);
}
}
static void __init clockgen_init(struct device_node *np);
/* Legacy nodes may get probed before the parent clockgen node */
static void __init legacy_init_clockgen(struct device_node *np)
{
if (!clockgen.node)
clockgen_init(of_get_parent(np));
}
/* Legacy node */
static void __init core_mux_init(struct device_node *np)
{
struct clk *clk;
struct resource res;
int idx, rc;
legacy_init_clockgen(np);
if (of_address_to_resource(np, 0, &res))
return;
idx = (res.start & 0xf0) >> 5;
clk = clockgen.cmux[idx];
clk: add PowerPC corenet clock driver support This adds the clock driver for Freescale PowerPC corenet series SoCs using common clock infrastructure. Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com> Signed-off-by: Li Yang <leoli@freescale.com> Signed-off-by: Mike Turquette <mturquette@linaro.org>
2013-04-09 08:46:26 +00:00
rc = of_clk_add_provider(np, of_clk_src_simple_get, clk);
if (rc) {
clk: qoriq: Move chip-specific knowledge into driver The device tree should describe the chips (or chip-like subblocks) in the system, but it generally does not describe individual registers -- it should identify, rather than describe, a programming interface. This has not been the case with the QorIQ clockgen nodes. The knowledge of what each bit setting of CLKCnCSR means is encoded in three places (binding, pll node, and mux node), and the last also needs to know which options are valid on a particular chip. All three of these locations are considered stable ABI, making it difficult to fix mistakes (of which I have found several), much less refactor the abstraction to be able to address problems, limitations, or new chips. Under the current binding, a pll clock specifier of 2 means that the PLL is divided by 4 -- and the driver implements this, unless there happen to be four clock-output-names rather than 3, in which case it interprets it as PLL divided by 3. This does not appear in the binding documentation at all. That hack is now considered stable ABI. The current device tree nodes contain errors, such as saying that T1040 can set a core clock to PLL/4 when only PLL and PLL/2 are options. The current binding also ignores some restrictions on clock selection, such as p5020's requirement that if a core uses the "wrong" PLL, that PLL must be clocked lower than the "correct" PLL and be at most 80% of the rated CPU frequency. Possibly because of the lack of the ability to express such nuance in the binding, some valid options are omitted from the device trees, such as the ability on p4080 to run cores 0-3 from PLL3 and cores 4-7 from PLL1 (again, only if they are at most 80% of rated CPU frequency). This omission, combined with excessive caution in the cpufreq driver (addressed in a subsequent patch), means that currently on a 1500 MHz p4080 with typical PLL configuration, cpufreq can lower the frequency to 1200 MHz on half the CPUs and do nothing on the others. With this patchset, all CPUs can be lowered to 1200 MHz on a rev2 p4080, and on a rev3 p4080 half can be lowered to 750 MHz and the other half to 600 MHz. The current binding only deals with CPU clocks. To describe FMan in the device tree, we need to describe its clock. Some chips have additional muxes that work like the CPU muxes, but are not described in the device tree. Others require inspecting the Reset Control Word to determine which PLL is used. Rather than continue to extend this mess, replace it. Have the driver bind to the chip-specific clockgen compatible, and keep the detailed description of quirky chip variations in the driver, where it can be easily fixed, refactored, and extended. Older device trees will continue to work (including a workaround for old ls1021a device trees that are missing compatible and reg in the clockgen node, which even the old binding required). The pll/mux details in old device trees will be ignored, but "clocks" properties pointing at the old nodes will still work, and be directed at the corresponding new clock. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-20 04:29:54 +00:00
pr_err("%s: Couldn't register clk provider for node %s: %d\n",
__func__, np->name, rc);
return;
clk: add PowerPC corenet clock driver support This adds the clock driver for Freescale PowerPC corenet series SoCs using common clock infrastructure. Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com> Signed-off-by: Li Yang <leoli@freescale.com> Signed-off-by: Mike Turquette <mturquette@linaro.org>
2013-04-09 08:46:26 +00:00
}
clk: qoriq: Move chip-specific knowledge into driver The device tree should describe the chips (or chip-like subblocks) in the system, but it generally does not describe individual registers -- it should identify, rather than describe, a programming interface. This has not been the case with the QorIQ clockgen nodes. The knowledge of what each bit setting of CLKCnCSR means is encoded in three places (binding, pll node, and mux node), and the last also needs to know which options are valid on a particular chip. All three of these locations are considered stable ABI, making it difficult to fix mistakes (of which I have found several), much less refactor the abstraction to be able to address problems, limitations, or new chips. Under the current binding, a pll clock specifier of 2 means that the PLL is divided by 4 -- and the driver implements this, unless there happen to be four clock-output-names rather than 3, in which case it interprets it as PLL divided by 3. This does not appear in the binding documentation at all. That hack is now considered stable ABI. The current device tree nodes contain errors, such as saying that T1040 can set a core clock to PLL/4 when only PLL and PLL/2 are options. The current binding also ignores some restrictions on clock selection, such as p5020's requirement that if a core uses the "wrong" PLL, that PLL must be clocked lower than the "correct" PLL and be at most 80% of the rated CPU frequency. Possibly because of the lack of the ability to express such nuance in the binding, some valid options are omitted from the device trees, such as the ability on p4080 to run cores 0-3 from PLL3 and cores 4-7 from PLL1 (again, only if they are at most 80% of rated CPU frequency). This omission, combined with excessive caution in the cpufreq driver (addressed in a subsequent patch), means that currently on a 1500 MHz p4080 with typical PLL configuration, cpufreq can lower the frequency to 1200 MHz on half the CPUs and do nothing on the others. With this patchset, all CPUs can be lowered to 1200 MHz on a rev2 p4080, and on a rev3 p4080 half can be lowered to 750 MHz and the other half to 600 MHz. The current binding only deals with CPU clocks. To describe FMan in the device tree, we need to describe its clock. Some chips have additional muxes that work like the CPU muxes, but are not described in the device tree. Others require inspecting the Reset Control Word to determine which PLL is used. Rather than continue to extend this mess, replace it. Have the driver bind to the chip-specific clockgen compatible, and keep the detailed description of quirky chip variations in the driver, where it can be easily fixed, refactored, and extended. Older device trees will continue to work (including a workaround for old ls1021a device trees that are missing compatible and reg in the clockgen node, which even the old binding required). The pll/mux details in old device trees will be ignored, but "clocks" properties pointing at the old nodes will still work, and be directed at the corresponding new clock. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-20 04:29:54 +00:00
}
clk: add PowerPC corenet clock driver support This adds the clock driver for Freescale PowerPC corenet series SoCs using common clock infrastructure. Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com> Signed-off-by: Li Yang <leoli@freescale.com> Signed-off-by: Mike Turquette <mturquette@linaro.org>
2013-04-09 08:46:26 +00:00
clk: qoriq: Move chip-specific knowledge into driver The device tree should describe the chips (or chip-like subblocks) in the system, but it generally does not describe individual registers -- it should identify, rather than describe, a programming interface. This has not been the case with the QorIQ clockgen nodes. The knowledge of what each bit setting of CLKCnCSR means is encoded in three places (binding, pll node, and mux node), and the last also needs to know which options are valid on a particular chip. All three of these locations are considered stable ABI, making it difficult to fix mistakes (of which I have found several), much less refactor the abstraction to be able to address problems, limitations, or new chips. Under the current binding, a pll clock specifier of 2 means that the PLL is divided by 4 -- and the driver implements this, unless there happen to be four clock-output-names rather than 3, in which case it interprets it as PLL divided by 3. This does not appear in the binding documentation at all. That hack is now considered stable ABI. The current device tree nodes contain errors, such as saying that T1040 can set a core clock to PLL/4 when only PLL and PLL/2 are options. The current binding also ignores some restrictions on clock selection, such as p5020's requirement that if a core uses the "wrong" PLL, that PLL must be clocked lower than the "correct" PLL and be at most 80% of the rated CPU frequency. Possibly because of the lack of the ability to express such nuance in the binding, some valid options are omitted from the device trees, such as the ability on p4080 to run cores 0-3 from PLL3 and cores 4-7 from PLL1 (again, only if they are at most 80% of rated CPU frequency). This omission, combined with excessive caution in the cpufreq driver (addressed in a subsequent patch), means that currently on a 1500 MHz p4080 with typical PLL configuration, cpufreq can lower the frequency to 1200 MHz on half the CPUs and do nothing on the others. With this patchset, all CPUs can be lowered to 1200 MHz on a rev2 p4080, and on a rev3 p4080 half can be lowered to 750 MHz and the other half to 600 MHz. The current binding only deals with CPU clocks. To describe FMan in the device tree, we need to describe its clock. Some chips have additional muxes that work like the CPU muxes, but are not described in the device tree. Others require inspecting the Reset Control Word to determine which PLL is used. Rather than continue to extend this mess, replace it. Have the driver bind to the chip-specific clockgen compatible, and keep the detailed description of quirky chip variations in the driver, where it can be easily fixed, refactored, and extended. Older device trees will continue to work (including a workaround for old ls1021a device trees that are missing compatible and reg in the clockgen node, which even the old binding required). The pll/mux details in old device trees will be ignored, but "clocks" properties pointing at the old nodes will still work, and be directed at the corresponding new clock. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-20 04:29:54 +00:00
static struct clk *sysclk_from_fixed(struct device_node *node, const char *name)
{
u32 rate;
if (of_property_read_u32(node, "clock-frequency", &rate))
return ERR_PTR(-ENODEV);
return clk_register_fixed_rate(NULL, name, NULL, CLK_IS_ROOT, rate);
clk: add PowerPC corenet clock driver support This adds the clock driver for Freescale PowerPC corenet series SoCs using common clock infrastructure. Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com> Signed-off-by: Li Yang <leoli@freescale.com> Signed-off-by: Mike Turquette <mturquette@linaro.org>
2013-04-09 08:46:26 +00:00
}
clk: qoriq: Move chip-specific knowledge into driver The device tree should describe the chips (or chip-like subblocks) in the system, but it generally does not describe individual registers -- it should identify, rather than describe, a programming interface. This has not been the case with the QorIQ clockgen nodes. The knowledge of what each bit setting of CLKCnCSR means is encoded in three places (binding, pll node, and mux node), and the last also needs to know which options are valid on a particular chip. All three of these locations are considered stable ABI, making it difficult to fix mistakes (of which I have found several), much less refactor the abstraction to be able to address problems, limitations, or new chips. Under the current binding, a pll clock specifier of 2 means that the PLL is divided by 4 -- and the driver implements this, unless there happen to be four clock-output-names rather than 3, in which case it interprets it as PLL divided by 3. This does not appear in the binding documentation at all. That hack is now considered stable ABI. The current device tree nodes contain errors, such as saying that T1040 can set a core clock to PLL/4 when only PLL and PLL/2 are options. The current binding also ignores some restrictions on clock selection, such as p5020's requirement that if a core uses the "wrong" PLL, that PLL must be clocked lower than the "correct" PLL and be at most 80% of the rated CPU frequency. Possibly because of the lack of the ability to express such nuance in the binding, some valid options are omitted from the device trees, such as the ability on p4080 to run cores 0-3 from PLL3 and cores 4-7 from PLL1 (again, only if they are at most 80% of rated CPU frequency). This omission, combined with excessive caution in the cpufreq driver (addressed in a subsequent patch), means that currently on a 1500 MHz p4080 with typical PLL configuration, cpufreq can lower the frequency to 1200 MHz on half the CPUs and do nothing on the others. With this patchset, all CPUs can be lowered to 1200 MHz on a rev2 p4080, and on a rev3 p4080 half can be lowered to 750 MHz and the other half to 600 MHz. The current binding only deals with CPU clocks. To describe FMan in the device tree, we need to describe its clock. Some chips have additional muxes that work like the CPU muxes, but are not described in the device tree. Others require inspecting the Reset Control Word to determine which PLL is used. Rather than continue to extend this mess, replace it. Have the driver bind to the chip-specific clockgen compatible, and keep the detailed description of quirky chip variations in the driver, where it can be easily fixed, refactored, and extended. Older device trees will continue to work (including a workaround for old ls1021a device trees that are missing compatible and reg in the clockgen node, which even the old binding required). The pll/mux details in old device trees will be ignored, but "clocks" properties pointing at the old nodes will still work, and be directed at the corresponding new clock. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-20 04:29:54 +00:00
static struct clk *sysclk_from_parent(const char *name)
{
struct clk *clk;
const char *parent_name;
clk = of_clk_get(clockgen.node, 0);
if (IS_ERR(clk))
return clk;
/* Register the input clock under the desired name. */
parent_name = __clk_get_name(clk);
clk = clk_register_fixed_factor(NULL, name, parent_name,
0, 1, 1);
if (IS_ERR(clk))
pr_err("%s: Couldn't register %s: %ld\n", __func__, name,
PTR_ERR(clk));
return clk;
}
static struct clk * __init create_sysclk(const char *name)
{
struct device_node *sysclk;
struct clk *clk;
clk = sysclk_from_fixed(clockgen.node, name);
if (!IS_ERR(clk))
return clk;
clk = sysclk_from_parent(name);
if (!IS_ERR(clk))
return clk;
sysclk = of_get_child_by_name(clockgen.node, "sysclk");
if (sysclk) {
clk = sysclk_from_fixed(sysclk, name);
if (!IS_ERR(clk))
return clk;
}
pr_err("%s: No input clock\n", __func__);
return NULL;
}
/* Legacy node */
static void __init sysclk_init(struct device_node *node)
{
struct clk *clk;
legacy_init_clockgen(node);
clk = clockgen.sysclk;
if (clk)
of_clk_add_provider(node, of_clk_src_simple_get, clk);
}
#define PLL_KILL BIT(31)
static void __init create_one_pll(struct clockgen *cg, int idx)
clk: add PowerPC corenet clock driver support This adds the clock driver for Freescale PowerPC corenet series SoCs using common clock infrastructure. Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com> Signed-off-by: Li Yang <leoli@freescale.com> Signed-off-by: Mike Turquette <mturquette@linaro.org>
2013-04-09 08:46:26 +00:00
{
clk: qoriq: Move chip-specific knowledge into driver The device tree should describe the chips (or chip-like subblocks) in the system, but it generally does not describe individual registers -- it should identify, rather than describe, a programming interface. This has not been the case with the QorIQ clockgen nodes. The knowledge of what each bit setting of CLKCnCSR means is encoded in three places (binding, pll node, and mux node), and the last also needs to know which options are valid on a particular chip. All three of these locations are considered stable ABI, making it difficult to fix mistakes (of which I have found several), much less refactor the abstraction to be able to address problems, limitations, or new chips. Under the current binding, a pll clock specifier of 2 means that the PLL is divided by 4 -- and the driver implements this, unless there happen to be four clock-output-names rather than 3, in which case it interprets it as PLL divided by 3. This does not appear in the binding documentation at all. That hack is now considered stable ABI. The current device tree nodes contain errors, such as saying that T1040 can set a core clock to PLL/4 when only PLL and PLL/2 are options. The current binding also ignores some restrictions on clock selection, such as p5020's requirement that if a core uses the "wrong" PLL, that PLL must be clocked lower than the "correct" PLL and be at most 80% of the rated CPU frequency. Possibly because of the lack of the ability to express such nuance in the binding, some valid options are omitted from the device trees, such as the ability on p4080 to run cores 0-3 from PLL3 and cores 4-7 from PLL1 (again, only if they are at most 80% of rated CPU frequency). This omission, combined with excessive caution in the cpufreq driver (addressed in a subsequent patch), means that currently on a 1500 MHz p4080 with typical PLL configuration, cpufreq can lower the frequency to 1200 MHz on half the CPUs and do nothing on the others. With this patchset, all CPUs can be lowered to 1200 MHz on a rev2 p4080, and on a rev3 p4080 half can be lowered to 750 MHz and the other half to 600 MHz. The current binding only deals with CPU clocks. To describe FMan in the device tree, we need to describe its clock. Some chips have additional muxes that work like the CPU muxes, but are not described in the device tree. Others require inspecting the Reset Control Word to determine which PLL is used. Rather than continue to extend this mess, replace it. Have the driver bind to the chip-specific clockgen compatible, and keep the detailed description of quirky chip variations in the driver, where it can be easily fixed, refactored, and extended. Older device trees will continue to work (including a workaround for old ls1021a device trees that are missing compatible and reg in the clockgen node, which even the old binding required). The pll/mux details in old device trees will be ignored, but "clocks" properties pointing at the old nodes will still work, and be directed at the corresponding new clock. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-20 04:29:54 +00:00
u32 __iomem *reg;
clk: mpc85xx: Update the driver to align to new clock bindings The clock bindings for Freescale CoreNet platform are updated. So, the driver needs to be updated accordingly. The main changes include: - Added a new node to present the input system clock - Changed PLL and MUX's compatible string Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com> Acked-by: Scott Wood <scottwood@freescale.com> Signed-off-by: Mike Turquette <mturquette@linaro.org>
2014-01-21 01:32:45 +00:00
u32 mult;
clk: qoriq: Move chip-specific knowledge into driver The device tree should describe the chips (or chip-like subblocks) in the system, but it generally does not describe individual registers -- it should identify, rather than describe, a programming interface. This has not been the case with the QorIQ clockgen nodes. The knowledge of what each bit setting of CLKCnCSR means is encoded in three places (binding, pll node, and mux node), and the last also needs to know which options are valid on a particular chip. All three of these locations are considered stable ABI, making it difficult to fix mistakes (of which I have found several), much less refactor the abstraction to be able to address problems, limitations, or new chips. Under the current binding, a pll clock specifier of 2 means that the PLL is divided by 4 -- and the driver implements this, unless there happen to be four clock-output-names rather than 3, in which case it interprets it as PLL divided by 3. This does not appear in the binding documentation at all. That hack is now considered stable ABI. The current device tree nodes contain errors, such as saying that T1040 can set a core clock to PLL/4 when only PLL and PLL/2 are options. The current binding also ignores some restrictions on clock selection, such as p5020's requirement that if a core uses the "wrong" PLL, that PLL must be clocked lower than the "correct" PLL and be at most 80% of the rated CPU frequency. Possibly because of the lack of the ability to express such nuance in the binding, some valid options are omitted from the device trees, such as the ability on p4080 to run cores 0-3 from PLL3 and cores 4-7 from PLL1 (again, only if they are at most 80% of rated CPU frequency). This omission, combined with excessive caution in the cpufreq driver (addressed in a subsequent patch), means that currently on a 1500 MHz p4080 with typical PLL configuration, cpufreq can lower the frequency to 1200 MHz on half the CPUs and do nothing on the others. With this patchset, all CPUs can be lowered to 1200 MHz on a rev2 p4080, and on a rev3 p4080 half can be lowered to 750 MHz and the other half to 600 MHz. The current binding only deals with CPU clocks. To describe FMan in the device tree, we need to describe its clock. Some chips have additional muxes that work like the CPU muxes, but are not described in the device tree. Others require inspecting the Reset Control Word to determine which PLL is used. Rather than continue to extend this mess, replace it. Have the driver bind to the chip-specific clockgen compatible, and keep the detailed description of quirky chip variations in the driver, where it can be easily fixed, refactored, and extended. Older device trees will continue to work (including a workaround for old ls1021a device trees that are missing compatible and reg in the clockgen node, which even the old binding required). The pll/mux details in old device trees will be ignored, but "clocks" properties pointing at the old nodes will still work, and be directed at the corresponding new clock. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-20 04:29:54 +00:00
struct clockgen_pll *pll = &cg->pll[idx];
int i;
clk: add PowerPC corenet clock driver support This adds the clock driver for Freescale PowerPC corenet series SoCs using common clock infrastructure. Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com> Signed-off-by: Li Yang <leoli@freescale.com> Signed-off-by: Mike Turquette <mturquette@linaro.org>
2013-04-09 08:46:26 +00:00
clk: qoriq: Move chip-specific knowledge into driver The device tree should describe the chips (or chip-like subblocks) in the system, but it generally does not describe individual registers -- it should identify, rather than describe, a programming interface. This has not been the case with the QorIQ clockgen nodes. The knowledge of what each bit setting of CLKCnCSR means is encoded in three places (binding, pll node, and mux node), and the last also needs to know which options are valid on a particular chip. All three of these locations are considered stable ABI, making it difficult to fix mistakes (of which I have found several), much less refactor the abstraction to be able to address problems, limitations, or new chips. Under the current binding, a pll clock specifier of 2 means that the PLL is divided by 4 -- and the driver implements this, unless there happen to be four clock-output-names rather than 3, in which case it interprets it as PLL divided by 3. This does not appear in the binding documentation at all. That hack is now considered stable ABI. The current device tree nodes contain errors, such as saying that T1040 can set a core clock to PLL/4 when only PLL and PLL/2 are options. The current binding also ignores some restrictions on clock selection, such as p5020's requirement that if a core uses the "wrong" PLL, that PLL must be clocked lower than the "correct" PLL and be at most 80% of the rated CPU frequency. Possibly because of the lack of the ability to express such nuance in the binding, some valid options are omitted from the device trees, such as the ability on p4080 to run cores 0-3 from PLL3 and cores 4-7 from PLL1 (again, only if they are at most 80% of rated CPU frequency). This omission, combined with excessive caution in the cpufreq driver (addressed in a subsequent patch), means that currently on a 1500 MHz p4080 with typical PLL configuration, cpufreq can lower the frequency to 1200 MHz on half the CPUs and do nothing on the others. With this patchset, all CPUs can be lowered to 1200 MHz on a rev2 p4080, and on a rev3 p4080 half can be lowered to 750 MHz and the other half to 600 MHz. The current binding only deals with CPU clocks. To describe FMan in the device tree, we need to describe its clock. Some chips have additional muxes that work like the CPU muxes, but are not described in the device tree. Others require inspecting the Reset Control Word to determine which PLL is used. Rather than continue to extend this mess, replace it. Have the driver bind to the chip-specific clockgen compatible, and keep the detailed description of quirky chip variations in the driver, where it can be easily fixed, refactored, and extended. Older device trees will continue to work (including a workaround for old ls1021a device trees that are missing compatible and reg in the clockgen node, which even the old binding required). The pll/mux details in old device trees will be ignored, but "clocks" properties pointing at the old nodes will still work, and be directed at the corresponding new clock. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-20 04:29:54 +00:00
if (!(cg->info.pll_mask & (1 << idx)))
clk: add PowerPC corenet clock driver support This adds the clock driver for Freescale PowerPC corenet series SoCs using common clock infrastructure. Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com> Signed-off-by: Li Yang <leoli@freescale.com> Signed-off-by: Mike Turquette <mturquette@linaro.org>
2013-04-09 08:46:26 +00:00
return;
clk: qoriq: Add ls2080a support. LS2080A is the first implementation of the chassis 3 clockgen, which has a different register layout than previous chips. It is also little endian, unlike previous chips. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-20 04:29:55 +00:00
if (cg->info.flags & CG_VER3) {
switch (idx) {
case PLATFORM_PLL:
reg = cg->regs + 0x60080;
break;
case CGA_PLL1:
reg = cg->regs + 0x80;
break;
case CGA_PLL2:
reg = cg->regs + 0xa0;
break;
case CGB_PLL1:
reg = cg->regs + 0x10080;
break;
case CGB_PLL2:
reg = cg->regs + 0x100a0;
break;
default:
WARN_ONCE(1, "index %d\n", idx);
return;
}
} else {
if (idx == PLATFORM_PLL)
reg = cg->regs + 0xc00;
else
reg = cg->regs + 0x800 + 0x20 * (idx - 1);
}
clk: add PowerPC corenet clock driver support This adds the clock driver for Freescale PowerPC corenet series SoCs using common clock infrastructure. Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com> Signed-off-by: Li Yang <leoli@freescale.com> Signed-off-by: Mike Turquette <mturquette@linaro.org>
2013-04-09 08:46:26 +00:00
clk: qoriq: Move chip-specific knowledge into driver The device tree should describe the chips (or chip-like subblocks) in the system, but it generally does not describe individual registers -- it should identify, rather than describe, a programming interface. This has not been the case with the QorIQ clockgen nodes. The knowledge of what each bit setting of CLKCnCSR means is encoded in three places (binding, pll node, and mux node), and the last also needs to know which options are valid on a particular chip. All three of these locations are considered stable ABI, making it difficult to fix mistakes (of which I have found several), much less refactor the abstraction to be able to address problems, limitations, or new chips. Under the current binding, a pll clock specifier of 2 means that the PLL is divided by 4 -- and the driver implements this, unless there happen to be four clock-output-names rather than 3, in which case it interprets it as PLL divided by 3. This does not appear in the binding documentation at all. That hack is now considered stable ABI. The current device tree nodes contain errors, such as saying that T1040 can set a core clock to PLL/4 when only PLL and PLL/2 are options. The current binding also ignores some restrictions on clock selection, such as p5020's requirement that if a core uses the "wrong" PLL, that PLL must be clocked lower than the "correct" PLL and be at most 80% of the rated CPU frequency. Possibly because of the lack of the ability to express such nuance in the binding, some valid options are omitted from the device trees, such as the ability on p4080 to run cores 0-3 from PLL3 and cores 4-7 from PLL1 (again, only if they are at most 80% of rated CPU frequency). This omission, combined with excessive caution in the cpufreq driver (addressed in a subsequent patch), means that currently on a 1500 MHz p4080 with typical PLL configuration, cpufreq can lower the frequency to 1200 MHz on half the CPUs and do nothing on the others. With this patchset, all CPUs can be lowered to 1200 MHz on a rev2 p4080, and on a rev3 p4080 half can be lowered to 750 MHz and the other half to 600 MHz. The current binding only deals with CPU clocks. To describe FMan in the device tree, we need to describe its clock. Some chips have additional muxes that work like the CPU muxes, but are not described in the device tree. Others require inspecting the Reset Control Word to determine which PLL is used. Rather than continue to extend this mess, replace it. Have the driver bind to the chip-specific clockgen compatible, and keep the detailed description of quirky chip variations in the driver, where it can be easily fixed, refactored, and extended. Older device trees will continue to work (including a workaround for old ls1021a device trees that are missing compatible and reg in the clockgen node, which even the old binding required). The pll/mux details in old device trees will be ignored, but "clocks" properties pointing at the old nodes will still work, and be directed at the corresponding new clock. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-20 04:29:54 +00:00
/* Get the multiple of PLL */
clk: qoriq: Add ls2080a support. LS2080A is the first implementation of the chassis 3 clockgen, which has a different register layout than previous chips. It is also little endian, unlike previous chips. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-20 04:29:55 +00:00
mult = cg_in(cg, reg);
clk: qoriq: Move chip-specific knowledge into driver The device tree should describe the chips (or chip-like subblocks) in the system, but it generally does not describe individual registers -- it should identify, rather than describe, a programming interface. This has not been the case with the QorIQ clockgen nodes. The knowledge of what each bit setting of CLKCnCSR means is encoded in three places (binding, pll node, and mux node), and the last also needs to know which options are valid on a particular chip. All three of these locations are considered stable ABI, making it difficult to fix mistakes (of which I have found several), much less refactor the abstraction to be able to address problems, limitations, or new chips. Under the current binding, a pll clock specifier of 2 means that the PLL is divided by 4 -- and the driver implements this, unless there happen to be four clock-output-names rather than 3, in which case it interprets it as PLL divided by 3. This does not appear in the binding documentation at all. That hack is now considered stable ABI. The current device tree nodes contain errors, such as saying that T1040 can set a core clock to PLL/4 when only PLL and PLL/2 are options. The current binding also ignores some restrictions on clock selection, such as p5020's requirement that if a core uses the "wrong" PLL, that PLL must be clocked lower than the "correct" PLL and be at most 80% of the rated CPU frequency. Possibly because of the lack of the ability to express such nuance in the binding, some valid options are omitted from the device trees, such as the ability on p4080 to run cores 0-3 from PLL3 and cores 4-7 from PLL1 (again, only if they are at most 80% of rated CPU frequency). This omission, combined with excessive caution in the cpufreq driver (addressed in a subsequent patch), means that currently on a 1500 MHz p4080 with typical PLL configuration, cpufreq can lower the frequency to 1200 MHz on half the CPUs and do nothing on the others. With this patchset, all CPUs can be lowered to 1200 MHz on a rev2 p4080, and on a rev3 p4080 half can be lowered to 750 MHz and the other half to 600 MHz. The current binding only deals with CPU clocks. To describe FMan in the device tree, we need to describe its clock. Some chips have additional muxes that work like the CPU muxes, but are not described in the device tree. Others require inspecting the Reset Control Word to determine which PLL is used. Rather than continue to extend this mess, replace it. Have the driver bind to the chip-specific clockgen compatible, and keep the detailed description of quirky chip variations in the driver, where it can be easily fixed, refactored, and extended. Older device trees will continue to work (including a workaround for old ls1021a device trees that are missing compatible and reg in the clockgen node, which even the old binding required). The pll/mux details in old device trees will be ignored, but "clocks" properties pointing at the old nodes will still work, and be directed at the corresponding new clock. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-20 04:29:54 +00:00
/* Check if this PLL is disabled */
clk: add PowerPC corenet clock driver support This adds the clock driver for Freescale PowerPC corenet series SoCs using common clock infrastructure. Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com> Signed-off-by: Li Yang <leoli@freescale.com> Signed-off-by: Mike Turquette <mturquette@linaro.org>
2013-04-09 08:46:26 +00:00
if (mult & PLL_KILL) {
clk: qoriq: Move chip-specific knowledge into driver The device tree should describe the chips (or chip-like subblocks) in the system, but it generally does not describe individual registers -- it should identify, rather than describe, a programming interface. This has not been the case with the QorIQ clockgen nodes. The knowledge of what each bit setting of CLKCnCSR means is encoded in three places (binding, pll node, and mux node), and the last also needs to know which options are valid on a particular chip. All three of these locations are considered stable ABI, making it difficult to fix mistakes (of which I have found several), much less refactor the abstraction to be able to address problems, limitations, or new chips. Under the current binding, a pll clock specifier of 2 means that the PLL is divided by 4 -- and the driver implements this, unless there happen to be four clock-output-names rather than 3, in which case it interprets it as PLL divided by 3. This does not appear in the binding documentation at all. That hack is now considered stable ABI. The current device tree nodes contain errors, such as saying that T1040 can set a core clock to PLL/4 when only PLL and PLL/2 are options. The current binding also ignores some restrictions on clock selection, such as p5020's requirement that if a core uses the "wrong" PLL, that PLL must be clocked lower than the "correct" PLL and be at most 80% of the rated CPU frequency. Possibly because of the lack of the ability to express such nuance in the binding, some valid options are omitted from the device trees, such as the ability on p4080 to run cores 0-3 from PLL3 and cores 4-7 from PLL1 (again, only if they are at most 80% of rated CPU frequency). This omission, combined with excessive caution in the cpufreq driver (addressed in a subsequent patch), means that currently on a 1500 MHz p4080 with typical PLL configuration, cpufreq can lower the frequency to 1200 MHz on half the CPUs and do nothing on the others. With this patchset, all CPUs can be lowered to 1200 MHz on a rev2 p4080, and on a rev3 p4080 half can be lowered to 750 MHz and the other half to 600 MHz. The current binding only deals with CPU clocks. To describe FMan in the device tree, we need to describe its clock. Some chips have additional muxes that work like the CPU muxes, but are not described in the device tree. Others require inspecting the Reset Control Word to determine which PLL is used. Rather than continue to extend this mess, replace it. Have the driver bind to the chip-specific clockgen compatible, and keep the detailed description of quirky chip variations in the driver, where it can be easily fixed, refactored, and extended. Older device trees will continue to work (including a workaround for old ls1021a device trees that are missing compatible and reg in the clockgen node, which even the old binding required). The pll/mux details in old device trees will be ignored, but "clocks" properties pointing at the old nodes will still work, and be directed at the corresponding new clock. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-20 04:29:54 +00:00
pr_debug("%s(): pll %p disabled\n", __func__, reg);
return;
clk: add PowerPC corenet clock driver support This adds the clock driver for Freescale PowerPC corenet series SoCs using common clock infrastructure. Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com> Signed-off-by: Li Yang <leoli@freescale.com> Signed-off-by: Mike Turquette <mturquette@linaro.org>
2013-04-09 08:46:26 +00:00
}
clk: qoriq: Add ls2080a support. LS2080A is the first implementation of the chassis 3 clockgen, which has a different register layout than previous chips. It is also little endian, unlike previous chips. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-20 04:29:55 +00:00
if ((cg->info.flags & CG_VER3) ||
((cg->info.flags & CG_PLL_8BIT) && idx != PLATFORM_PLL))
clk: qoriq: Move chip-specific knowledge into driver The device tree should describe the chips (or chip-like subblocks) in the system, but it generally does not describe individual registers -- it should identify, rather than describe, a programming interface. This has not been the case with the QorIQ clockgen nodes. The knowledge of what each bit setting of CLKCnCSR means is encoded in three places (binding, pll node, and mux node), and the last also needs to know which options are valid on a particular chip. All three of these locations are considered stable ABI, making it difficult to fix mistakes (of which I have found several), much less refactor the abstraction to be able to address problems, limitations, or new chips. Under the current binding, a pll clock specifier of 2 means that the PLL is divided by 4 -- and the driver implements this, unless there happen to be four clock-output-names rather than 3, in which case it interprets it as PLL divided by 3. This does not appear in the binding documentation at all. That hack is now considered stable ABI. The current device tree nodes contain errors, such as saying that T1040 can set a core clock to PLL/4 when only PLL and PLL/2 are options. The current binding also ignores some restrictions on clock selection, such as p5020's requirement that if a core uses the "wrong" PLL, that PLL must be clocked lower than the "correct" PLL and be at most 80% of the rated CPU frequency. Possibly because of the lack of the ability to express such nuance in the binding, some valid options are omitted from the device trees, such as the ability on p4080 to run cores 0-3 from PLL3 and cores 4-7 from PLL1 (again, only if they are at most 80% of rated CPU frequency). This omission, combined with excessive caution in the cpufreq driver (addressed in a subsequent patch), means that currently on a 1500 MHz p4080 with typical PLL configuration, cpufreq can lower the frequency to 1200 MHz on half the CPUs and do nothing on the others. With this patchset, all CPUs can be lowered to 1200 MHz on a rev2 p4080, and on a rev3 p4080 half can be lowered to 750 MHz and the other half to 600 MHz. The current binding only deals with CPU clocks. To describe FMan in the device tree, we need to describe its clock. Some chips have additional muxes that work like the CPU muxes, but are not described in the device tree. Others require inspecting the Reset Control Word to determine which PLL is used. Rather than continue to extend this mess, replace it. Have the driver bind to the chip-specific clockgen compatible, and keep the detailed description of quirky chip variations in the driver, where it can be easily fixed, refactored, and extended. Older device trees will continue to work (including a workaround for old ls1021a device trees that are missing compatible and reg in the clockgen node, which even the old binding required). The pll/mux details in old device trees will be ignored, but "clocks" properties pointing at the old nodes will still work, and be directed at the corresponding new clock. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-20 04:29:54 +00:00
mult = (mult & GENMASK(8, 1)) >> 1;
else
mult = (mult & GENMASK(6, 1)) >> 1;
for (i = 0; i < ARRAY_SIZE(pll->div); i++) {
struct clk *clk;
snprintf(pll->div[i].name, sizeof(pll->div[i].name),
"cg-pll%d-div%d", idx, i + 1);
clk = clk_register_fixed_factor(NULL,
pll->div[i].name, "cg-sysclk", 0, mult, i + 1);
if (IS_ERR(clk)) {
pr_err("%s: %s: register failed %ld\n",
__func__, pll->div[i].name, PTR_ERR(clk));
continue;
}
pll->div[i].clk = clk;
clk: add PowerPC corenet clock driver support This adds the clock driver for Freescale PowerPC corenet series SoCs using common clock infrastructure. Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com> Signed-off-by: Li Yang <leoli@freescale.com> Signed-off-by: Mike Turquette <mturquette@linaro.org>
2013-04-09 08:46:26 +00:00
}
clk: qoriq: Move chip-specific knowledge into driver The device tree should describe the chips (or chip-like subblocks) in the system, but it generally does not describe individual registers -- it should identify, rather than describe, a programming interface. This has not been the case with the QorIQ clockgen nodes. The knowledge of what each bit setting of CLKCnCSR means is encoded in three places (binding, pll node, and mux node), and the last also needs to know which options are valid on a particular chip. All three of these locations are considered stable ABI, making it difficult to fix mistakes (of which I have found several), much less refactor the abstraction to be able to address problems, limitations, or new chips. Under the current binding, a pll clock specifier of 2 means that the PLL is divided by 4 -- and the driver implements this, unless there happen to be four clock-output-names rather than 3, in which case it interprets it as PLL divided by 3. This does not appear in the binding documentation at all. That hack is now considered stable ABI. The current device tree nodes contain errors, such as saying that T1040 can set a core clock to PLL/4 when only PLL and PLL/2 are options. The current binding also ignores some restrictions on clock selection, such as p5020's requirement that if a core uses the "wrong" PLL, that PLL must be clocked lower than the "correct" PLL and be at most 80% of the rated CPU frequency. Possibly because of the lack of the ability to express such nuance in the binding, some valid options are omitted from the device trees, such as the ability on p4080 to run cores 0-3 from PLL3 and cores 4-7 from PLL1 (again, only if they are at most 80% of rated CPU frequency). This omission, combined with excessive caution in the cpufreq driver (addressed in a subsequent patch), means that currently on a 1500 MHz p4080 with typical PLL configuration, cpufreq can lower the frequency to 1200 MHz on half the CPUs and do nothing on the others. With this patchset, all CPUs can be lowered to 1200 MHz on a rev2 p4080, and on a rev3 p4080 half can be lowered to 750 MHz and the other half to 600 MHz. The current binding only deals with CPU clocks. To describe FMan in the device tree, we need to describe its clock. Some chips have additional muxes that work like the CPU muxes, but are not described in the device tree. Others require inspecting the Reset Control Word to determine which PLL is used. Rather than continue to extend this mess, replace it. Have the driver bind to the chip-specific clockgen compatible, and keep the detailed description of quirky chip variations in the driver, where it can be easily fixed, refactored, and extended. Older device trees will continue to work (including a workaround for old ls1021a device trees that are missing compatible and reg in the clockgen node, which even the old binding required). The pll/mux details in old device trees will be ignored, but "clocks" properties pointing at the old nodes will still work, and be directed at the corresponding new clock. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-20 04:29:54 +00:00
}
static void __init create_plls(struct clockgen *cg)
{
int i;
for (i = 0; i < ARRAY_SIZE(cg->pll); i++)
create_one_pll(cg, i);
}
clk: add PowerPC corenet clock driver support This adds the clock driver for Freescale PowerPC corenet series SoCs using common clock infrastructure. Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com> Signed-off-by: Li Yang <leoli@freescale.com> Signed-off-by: Mike Turquette <mturquette@linaro.org>
2013-04-09 08:46:26 +00:00
clk: qoriq: Move chip-specific knowledge into driver The device tree should describe the chips (or chip-like subblocks) in the system, but it generally does not describe individual registers -- it should identify, rather than describe, a programming interface. This has not been the case with the QorIQ clockgen nodes. The knowledge of what each bit setting of CLKCnCSR means is encoded in three places (binding, pll node, and mux node), and the last also needs to know which options are valid on a particular chip. All three of these locations are considered stable ABI, making it difficult to fix mistakes (of which I have found several), much less refactor the abstraction to be able to address problems, limitations, or new chips. Under the current binding, a pll clock specifier of 2 means that the PLL is divided by 4 -- and the driver implements this, unless there happen to be four clock-output-names rather than 3, in which case it interprets it as PLL divided by 3. This does not appear in the binding documentation at all. That hack is now considered stable ABI. The current device tree nodes contain errors, such as saying that T1040 can set a core clock to PLL/4 when only PLL and PLL/2 are options. The current binding also ignores some restrictions on clock selection, such as p5020's requirement that if a core uses the "wrong" PLL, that PLL must be clocked lower than the "correct" PLL and be at most 80% of the rated CPU frequency. Possibly because of the lack of the ability to express such nuance in the binding, some valid options are omitted from the device trees, such as the ability on p4080 to run cores 0-3 from PLL3 and cores 4-7 from PLL1 (again, only if they are at most 80% of rated CPU frequency). This omission, combined with excessive caution in the cpufreq driver (addressed in a subsequent patch), means that currently on a 1500 MHz p4080 with typical PLL configuration, cpufreq can lower the frequency to 1200 MHz on half the CPUs and do nothing on the others. With this patchset, all CPUs can be lowered to 1200 MHz on a rev2 p4080, and on a rev3 p4080 half can be lowered to 750 MHz and the other half to 600 MHz. The current binding only deals with CPU clocks. To describe FMan in the device tree, we need to describe its clock. Some chips have additional muxes that work like the CPU muxes, but are not described in the device tree. Others require inspecting the Reset Control Word to determine which PLL is used. Rather than continue to extend this mess, replace it. Have the driver bind to the chip-specific clockgen compatible, and keep the detailed description of quirky chip variations in the driver, where it can be easily fixed, refactored, and extended. Older device trees will continue to work (including a workaround for old ls1021a device trees that are missing compatible and reg in the clockgen node, which even the old binding required). The pll/mux details in old device trees will be ignored, but "clocks" properties pointing at the old nodes will still work, and be directed at the corresponding new clock. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-20 04:29:54 +00:00
static void __init legacy_pll_init(struct device_node *np, int idx)
{
struct clockgen_pll *pll;
struct clk_onecell_data *onecell_data;
struct clk **subclks;
int count, rc;
legacy_init_clockgen(np);
pll = &clockgen.pll[idx];
clk: add PowerPC corenet clock driver support This adds the clock driver for Freescale PowerPC corenet series SoCs using common clock infrastructure. Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com> Signed-off-by: Li Yang <leoli@freescale.com> Signed-off-by: Mike Turquette <mturquette@linaro.org>
2013-04-09 08:46:26 +00:00
count = of_property_count_strings(np, "clock-output-names");
clk: qoriq: Move chip-specific knowledge into driver The device tree should describe the chips (or chip-like subblocks) in the system, but it generally does not describe individual registers -- it should identify, rather than describe, a programming interface. This has not been the case with the QorIQ clockgen nodes. The knowledge of what each bit setting of CLKCnCSR means is encoded in three places (binding, pll node, and mux node), and the last also needs to know which options are valid on a particular chip. All three of these locations are considered stable ABI, making it difficult to fix mistakes (of which I have found several), much less refactor the abstraction to be able to address problems, limitations, or new chips. Under the current binding, a pll clock specifier of 2 means that the PLL is divided by 4 -- and the driver implements this, unless there happen to be four clock-output-names rather than 3, in which case it interprets it as PLL divided by 3. This does not appear in the binding documentation at all. That hack is now considered stable ABI. The current device tree nodes contain errors, such as saying that T1040 can set a core clock to PLL/4 when only PLL and PLL/2 are options. The current binding also ignores some restrictions on clock selection, such as p5020's requirement that if a core uses the "wrong" PLL, that PLL must be clocked lower than the "correct" PLL and be at most 80% of the rated CPU frequency. Possibly because of the lack of the ability to express such nuance in the binding, some valid options are omitted from the device trees, such as the ability on p4080 to run cores 0-3 from PLL3 and cores 4-7 from PLL1 (again, only if they are at most 80% of rated CPU frequency). This omission, combined with excessive caution in the cpufreq driver (addressed in a subsequent patch), means that currently on a 1500 MHz p4080 with typical PLL configuration, cpufreq can lower the frequency to 1200 MHz on half the CPUs and do nothing on the others. With this patchset, all CPUs can be lowered to 1200 MHz on a rev2 p4080, and on a rev3 p4080 half can be lowered to 750 MHz and the other half to 600 MHz. The current binding only deals with CPU clocks. To describe FMan in the device tree, we need to describe its clock. Some chips have additional muxes that work like the CPU muxes, but are not described in the device tree. Others require inspecting the Reset Control Word to determine which PLL is used. Rather than continue to extend this mess, replace it. Have the driver bind to the chip-specific clockgen compatible, and keep the detailed description of quirky chip variations in the driver, where it can be easily fixed, refactored, and extended. Older device trees will continue to work (including a workaround for old ls1021a device trees that are missing compatible and reg in the clockgen node, which even the old binding required). The pll/mux details in old device trees will be ignored, but "clocks" properties pointing at the old nodes will still work, and be directed at the corresponding new clock. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-20 04:29:54 +00:00
BUILD_BUG_ON(ARRAY_SIZE(pll->div) < 4);
subclks = kcalloc(4, sizeof(struct clk *), GFP_KERNEL);
clk: qoriq: Fix checkpatch type OOM_MESSAGE WARNING:OOM_MESSAGE: Possible unnecessary 'out of memory' message + if (!parent_names) { + pr_err("%s: could not allocate parent_names\n", __func__); WARNING:OOM_MESSAGE: Possible unnecessary 'out of memory' message + if (!cmux_clk) { + pr_err("%s: could not allocate cmux_clk\n", __func__); WARNING:OOM_MESSAGE: Possible unnecessary 'out of memory' message + if (!subclks) { + pr_err("%s: could not allocate subclks\n", __func__); WARNING:OOM_MESSAGE: Possible unnecessary 'out of memory' message + if (!onecell_data) { + pr_err("%s: could not allocate onecell_data\n", __func__); Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com> Signed-off-by: Michael Turquette <mturquette@linaro.org>
2015-01-21 10:03:26 +00:00
if (!subclks)
clk: qoriq: Move chip-specific knowledge into driver The device tree should describe the chips (or chip-like subblocks) in the system, but it generally does not describe individual registers -- it should identify, rather than describe, a programming interface. This has not been the case with the QorIQ clockgen nodes. The knowledge of what each bit setting of CLKCnCSR means is encoded in three places (binding, pll node, and mux node), and the last also needs to know which options are valid on a particular chip. All three of these locations are considered stable ABI, making it difficult to fix mistakes (of which I have found several), much less refactor the abstraction to be able to address problems, limitations, or new chips. Under the current binding, a pll clock specifier of 2 means that the PLL is divided by 4 -- and the driver implements this, unless there happen to be four clock-output-names rather than 3, in which case it interprets it as PLL divided by 3. This does not appear in the binding documentation at all. That hack is now considered stable ABI. The current device tree nodes contain errors, such as saying that T1040 can set a core clock to PLL/4 when only PLL and PLL/2 are options. The current binding also ignores some restrictions on clock selection, such as p5020's requirement that if a core uses the "wrong" PLL, that PLL must be clocked lower than the "correct" PLL and be at most 80% of the rated CPU frequency. Possibly because of the lack of the ability to express such nuance in the binding, some valid options are omitted from the device trees, such as the ability on p4080 to run cores 0-3 from PLL3 and cores 4-7 from PLL1 (again, only if they are at most 80% of rated CPU frequency). This omission, combined with excessive caution in the cpufreq driver (addressed in a subsequent patch), means that currently on a 1500 MHz p4080 with typical PLL configuration, cpufreq can lower the frequency to 1200 MHz on half the CPUs and do nothing on the others. With this patchset, all CPUs can be lowered to 1200 MHz on a rev2 p4080, and on a rev3 p4080 half can be lowered to 750 MHz and the other half to 600 MHz. The current binding only deals with CPU clocks. To describe FMan in the device tree, we need to describe its clock. Some chips have additional muxes that work like the CPU muxes, but are not described in the device tree. Others require inspecting the Reset Control Word to determine which PLL is used. Rather than continue to extend this mess, replace it. Have the driver bind to the chip-specific clockgen compatible, and keep the detailed description of quirky chip variations in the driver, where it can be easily fixed, refactored, and extended. Older device trees will continue to work (including a workaround for old ls1021a device trees that are missing compatible and reg in the clockgen node, which even the old binding required). The pll/mux details in old device trees will be ignored, but "clocks" properties pointing at the old nodes will still work, and be directed at the corresponding new clock. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-20 04:29:54 +00:00
return;
clk: add PowerPC corenet clock driver support This adds the clock driver for Freescale PowerPC corenet series SoCs using common clock infrastructure. Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com> Signed-off-by: Li Yang <leoli@freescale.com> Signed-off-by: Mike Turquette <mturquette@linaro.org>
2013-04-09 08:46:26 +00:00
clk: qoriq: Replace kzalloc() with kmalloc() Where the memset() is not necessary Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com> Signed-off-by: Michael Turquette <mturquette@linaro.org>
2015-01-21 10:03:28 +00:00
onecell_data = kmalloc(sizeof(*onecell_data), GFP_KERNEL);
clk: qoriq: Fix checkpatch type OOM_MESSAGE WARNING:OOM_MESSAGE: Possible unnecessary 'out of memory' message + if (!parent_names) { + pr_err("%s: could not allocate parent_names\n", __func__); WARNING:OOM_MESSAGE: Possible unnecessary 'out of memory' message + if (!cmux_clk) { + pr_err("%s: could not allocate cmux_clk\n", __func__); WARNING:OOM_MESSAGE: Possible unnecessary 'out of memory' message + if (!subclks) { + pr_err("%s: could not allocate subclks\n", __func__); WARNING:OOM_MESSAGE: Possible unnecessary 'out of memory' message + if (!onecell_data) { + pr_err("%s: could not allocate onecell_data\n", __func__); Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com> Signed-off-by: Michael Turquette <mturquette@linaro.org>
2015-01-21 10:03:26 +00:00
if (!onecell_data)
clk: add PowerPC corenet clock driver support This adds the clock driver for Freescale PowerPC corenet series SoCs using common clock infrastructure. Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com> Signed-off-by: Li Yang <leoli@freescale.com> Signed-off-by: Mike Turquette <mturquette@linaro.org>
2013-04-09 08:46:26 +00:00
goto err_clks;
clk: qoriq: Move chip-specific knowledge into driver The device tree should describe the chips (or chip-like subblocks) in the system, but it generally does not describe individual registers -- it should identify, rather than describe, a programming interface. This has not been the case with the QorIQ clockgen nodes. The knowledge of what each bit setting of CLKCnCSR means is encoded in three places (binding, pll node, and mux node), and the last also needs to know which options are valid on a particular chip. All three of these locations are considered stable ABI, making it difficult to fix mistakes (of which I have found several), much less refactor the abstraction to be able to address problems, limitations, or new chips. Under the current binding, a pll clock specifier of 2 means that the PLL is divided by 4 -- and the driver implements this, unless there happen to be four clock-output-names rather than 3, in which case it interprets it as PLL divided by 3. This does not appear in the binding documentation at all. That hack is now considered stable ABI. The current device tree nodes contain errors, such as saying that T1040 can set a core clock to PLL/4 when only PLL and PLL/2 are options. The current binding also ignores some restrictions on clock selection, such as p5020's requirement that if a core uses the "wrong" PLL, that PLL must be clocked lower than the "correct" PLL and be at most 80% of the rated CPU frequency. Possibly because of the lack of the ability to express such nuance in the binding, some valid options are omitted from the device trees, such as the ability on p4080 to run cores 0-3 from PLL3 and cores 4-7 from PLL1 (again, only if they are at most 80% of rated CPU frequency). This omission, combined with excessive caution in the cpufreq driver (addressed in a subsequent patch), means that currently on a 1500 MHz p4080 with typical PLL configuration, cpufreq can lower the frequency to 1200 MHz on half the CPUs and do nothing on the others. With this patchset, all CPUs can be lowered to 1200 MHz on a rev2 p4080, and on a rev3 p4080 half can be lowered to 750 MHz and the other half to 600 MHz. The current binding only deals with CPU clocks. To describe FMan in the device tree, we need to describe its clock. Some chips have additional muxes that work like the CPU muxes, but are not described in the device tree. Others require inspecting the Reset Control Word to determine which PLL is used. Rather than continue to extend this mess, replace it. Have the driver bind to the chip-specific clockgen compatible, and keep the detailed description of quirky chip variations in the driver, where it can be easily fixed, refactored, and extended. Older device trees will continue to work (including a workaround for old ls1021a device trees that are missing compatible and reg in the clockgen node, which even the old binding required). The pll/mux details in old device trees will be ignored, but "clocks" properties pointing at the old nodes will still work, and be directed at the corresponding new clock. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-20 04:29:54 +00:00
if (count <= 3) {
subclks[0] = pll->div[0].clk;
subclks[1] = pll->div[1].clk;
subclks[2] = pll->div[3].clk;
} else {
subclks[0] = pll->div[0].clk;
subclks[1] = pll->div[1].clk;
subclks[2] = pll->div[2].clk;
subclks[3] = pll->div[3].clk;
clk: add PowerPC corenet clock driver support This adds the clock driver for Freescale PowerPC corenet series SoCs using common clock infrastructure. Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com> Signed-off-by: Li Yang <leoli@freescale.com> Signed-off-by: Mike Turquette <mturquette@linaro.org>
2013-04-09 08:46:26 +00:00
}
onecell_data->clks = subclks;
onecell_data->clk_num = count;
rc = of_clk_add_provider(np, of_clk_src_onecell_get, onecell_data);
if (rc) {
clk: qoriq: Move chip-specific knowledge into driver The device tree should describe the chips (or chip-like subblocks) in the system, but it generally does not describe individual registers -- it should identify, rather than describe, a programming interface. This has not been the case with the QorIQ clockgen nodes. The knowledge of what each bit setting of CLKCnCSR means is encoded in three places (binding, pll node, and mux node), and the last also needs to know which options are valid on a particular chip. All three of these locations are considered stable ABI, making it difficult to fix mistakes (of which I have found several), much less refactor the abstraction to be able to address problems, limitations, or new chips. Under the current binding, a pll clock specifier of 2 means that the PLL is divided by 4 -- and the driver implements this, unless there happen to be four clock-output-names rather than 3, in which case it interprets it as PLL divided by 3. This does not appear in the binding documentation at all. That hack is now considered stable ABI. The current device tree nodes contain errors, such as saying that T1040 can set a core clock to PLL/4 when only PLL and PLL/2 are options. The current binding also ignores some restrictions on clock selection, such as p5020's requirement that if a core uses the "wrong" PLL, that PLL must be clocked lower than the "correct" PLL and be at most 80% of the rated CPU frequency. Possibly because of the lack of the ability to express such nuance in the binding, some valid options are omitted from the device trees, such as the ability on p4080 to run cores 0-3 from PLL3 and cores 4-7 from PLL1 (again, only if they are at most 80% of rated CPU frequency). This omission, combined with excessive caution in the cpufreq driver (addressed in a subsequent patch), means that currently on a 1500 MHz p4080 with typical PLL configuration, cpufreq can lower the frequency to 1200 MHz on half the CPUs and do nothing on the others. With this patchset, all CPUs can be lowered to 1200 MHz on a rev2 p4080, and on a rev3 p4080 half can be lowered to 750 MHz and the other half to 600 MHz. The current binding only deals with CPU clocks. To describe FMan in the device tree, we need to describe its clock. Some chips have additional muxes that work like the CPU muxes, but are not described in the device tree. Others require inspecting the Reset Control Word to determine which PLL is used. Rather than continue to extend this mess, replace it. Have the driver bind to the chip-specific clockgen compatible, and keep the detailed description of quirky chip variations in the driver, where it can be easily fixed, refactored, and extended. Older device trees will continue to work (including a workaround for old ls1021a device trees that are missing compatible and reg in the clockgen node, which even the old binding required). The pll/mux details in old device trees will be ignored, but "clocks" properties pointing at the old nodes will still work, and be directed at the corresponding new clock. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-20 04:29:54 +00:00
pr_err("%s: Couldn't register clk provider for node %s: %d\n",
__func__, np->name, rc);
clk: add PowerPC corenet clock driver support This adds the clock driver for Freescale PowerPC corenet series SoCs using common clock infrastructure. Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com> Signed-off-by: Li Yang <leoli@freescale.com> Signed-off-by: Mike Turquette <mturquette@linaro.org>
2013-04-09 08:46:26 +00:00
goto err_cell;
}
return;
err_cell:
kfree(onecell_data);
err_clks:
kfree(subclks);
clk: mpc85xx: Update the driver to align to new clock bindings The clock bindings for Freescale CoreNet platform are updated. So, the driver needs to be updated accordingly. The main changes include: - Added a new node to present the input system clock - Changed PLL and MUX's compatible string Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com> Acked-by: Scott Wood <scottwood@freescale.com> Signed-off-by: Mike Turquette <mturquette@linaro.org>
2014-01-21 01:32:45 +00:00
}
clk: qoriq: Move chip-specific knowledge into driver The device tree should describe the chips (or chip-like subblocks) in the system, but it generally does not describe individual registers -- it should identify, rather than describe, a programming interface. This has not been the case with the QorIQ clockgen nodes. The knowledge of what each bit setting of CLKCnCSR means is encoded in three places (binding, pll node, and mux node), and the last also needs to know which options are valid on a particular chip. All three of these locations are considered stable ABI, making it difficult to fix mistakes (of which I have found several), much less refactor the abstraction to be able to address problems, limitations, or new chips. Under the current binding, a pll clock specifier of 2 means that the PLL is divided by 4 -- and the driver implements this, unless there happen to be four clock-output-names rather than 3, in which case it interprets it as PLL divided by 3. This does not appear in the binding documentation at all. That hack is now considered stable ABI. The current device tree nodes contain errors, such as saying that T1040 can set a core clock to PLL/4 when only PLL and PLL/2 are options. The current binding also ignores some restrictions on clock selection, such as p5020's requirement that if a core uses the "wrong" PLL, that PLL must be clocked lower than the "correct" PLL and be at most 80% of the rated CPU frequency. Possibly because of the lack of the ability to express such nuance in the binding, some valid options are omitted from the device trees, such as the ability on p4080 to run cores 0-3 from PLL3 and cores 4-7 from PLL1 (again, only if they are at most 80% of rated CPU frequency). This omission, combined with excessive caution in the cpufreq driver (addressed in a subsequent patch), means that currently on a 1500 MHz p4080 with typical PLL configuration, cpufreq can lower the frequency to 1200 MHz on half the CPUs and do nothing on the others. With this patchset, all CPUs can be lowered to 1200 MHz on a rev2 p4080, and on a rev3 p4080 half can be lowered to 750 MHz and the other half to 600 MHz. The current binding only deals with CPU clocks. To describe FMan in the device tree, we need to describe its clock. Some chips have additional muxes that work like the CPU muxes, but are not described in the device tree. Others require inspecting the Reset Control Word to determine which PLL is used. Rather than continue to extend this mess, replace it. Have the driver bind to the chip-specific clockgen compatible, and keep the detailed description of quirky chip variations in the driver, where it can be easily fixed, refactored, and extended. Older device trees will continue to work (including a workaround for old ls1021a device trees that are missing compatible and reg in the clockgen node, which even the old binding required). The pll/mux details in old device trees will be ignored, but "clocks" properties pointing at the old nodes will still work, and be directed at the corresponding new clock. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-20 04:29:54 +00:00
/* Legacy node */
static void __init pltfrm_pll_init(struct device_node *np)
clk: mpc85xx: Update the driver to align to new clock bindings The clock bindings for Freescale CoreNet platform are updated. So, the driver needs to be updated accordingly. The main changes include: - Added a new node to present the input system clock - Changed PLL and MUX's compatible string Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com> Acked-by: Scott Wood <scottwood@freescale.com> Signed-off-by: Mike Turquette <mturquette@linaro.org>
2014-01-21 01:32:45 +00:00
{
clk: qoriq: Move chip-specific knowledge into driver The device tree should describe the chips (or chip-like subblocks) in the system, but it generally does not describe individual registers -- it should identify, rather than describe, a programming interface. This has not been the case with the QorIQ clockgen nodes. The knowledge of what each bit setting of CLKCnCSR means is encoded in three places (binding, pll node, and mux node), and the last also needs to know which options are valid on a particular chip. All three of these locations are considered stable ABI, making it difficult to fix mistakes (of which I have found several), much less refactor the abstraction to be able to address problems, limitations, or new chips. Under the current binding, a pll clock specifier of 2 means that the PLL is divided by 4 -- and the driver implements this, unless there happen to be four clock-output-names rather than 3, in which case it interprets it as PLL divided by 3. This does not appear in the binding documentation at all. That hack is now considered stable ABI. The current device tree nodes contain errors, such as saying that T1040 can set a core clock to PLL/4 when only PLL and PLL/2 are options. The current binding also ignores some restrictions on clock selection, such as p5020's requirement that if a core uses the "wrong" PLL, that PLL must be clocked lower than the "correct" PLL and be at most 80% of the rated CPU frequency. Possibly because of the lack of the ability to express such nuance in the binding, some valid options are omitted from the device trees, such as the ability on p4080 to run cores 0-3 from PLL3 and cores 4-7 from PLL1 (again, only if they are at most 80% of rated CPU frequency). This omission, combined with excessive caution in the cpufreq driver (addressed in a subsequent patch), means that currently on a 1500 MHz p4080 with typical PLL configuration, cpufreq can lower the frequency to 1200 MHz on half the CPUs and do nothing on the others. With this patchset, all CPUs can be lowered to 1200 MHz on a rev2 p4080, and on a rev3 p4080 half can be lowered to 750 MHz and the other half to 600 MHz. The current binding only deals with CPU clocks. To describe FMan in the device tree, we need to describe its clock. Some chips have additional muxes that work like the CPU muxes, but are not described in the device tree. Others require inspecting the Reset Control Word to determine which PLL is used. Rather than continue to extend this mess, replace it. Have the driver bind to the chip-specific clockgen compatible, and keep the detailed description of quirky chip variations in the driver, where it can be easily fixed, refactored, and extended. Older device trees will continue to work (including a workaround for old ls1021a device trees that are missing compatible and reg in the clockgen node, which even the old binding required). The pll/mux details in old device trees will be ignored, but "clocks" properties pointing at the old nodes will still work, and be directed at the corresponding new clock. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-20 04:29:54 +00:00
legacy_pll_init(np, PLATFORM_PLL);
}
clk: mpc85xx: Update the driver to align to new clock bindings The clock bindings for Freescale CoreNet platform are updated. So, the driver needs to be updated accordingly. The main changes include: - Added a new node to present the input system clock - Changed PLL and MUX's compatible string Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com> Acked-by: Scott Wood <scottwood@freescale.com> Signed-off-by: Mike Turquette <mturquette@linaro.org>
2014-01-21 01:32:45 +00:00
clk: qoriq: Move chip-specific knowledge into driver The device tree should describe the chips (or chip-like subblocks) in the system, but it generally does not describe individual registers -- it should identify, rather than describe, a programming interface. This has not been the case with the QorIQ clockgen nodes. The knowledge of what each bit setting of CLKCnCSR means is encoded in three places (binding, pll node, and mux node), and the last also needs to know which options are valid on a particular chip. All three of these locations are considered stable ABI, making it difficult to fix mistakes (of which I have found several), much less refactor the abstraction to be able to address problems, limitations, or new chips. Under the current binding, a pll clock specifier of 2 means that the PLL is divided by 4 -- and the driver implements this, unless there happen to be four clock-output-names rather than 3, in which case it interprets it as PLL divided by 3. This does not appear in the binding documentation at all. That hack is now considered stable ABI. The current device tree nodes contain errors, such as saying that T1040 can set a core clock to PLL/4 when only PLL and PLL/2 are options. The current binding also ignores some restrictions on clock selection, such as p5020's requirement that if a core uses the "wrong" PLL, that PLL must be clocked lower than the "correct" PLL and be at most 80% of the rated CPU frequency. Possibly because of the lack of the ability to express such nuance in the binding, some valid options are omitted from the device trees, such as the ability on p4080 to run cores 0-3 from PLL3 and cores 4-7 from PLL1 (again, only if they are at most 80% of rated CPU frequency). This omission, combined with excessive caution in the cpufreq driver (addressed in a subsequent patch), means that currently on a 1500 MHz p4080 with typical PLL configuration, cpufreq can lower the frequency to 1200 MHz on half the CPUs and do nothing on the others. With this patchset, all CPUs can be lowered to 1200 MHz on a rev2 p4080, and on a rev3 p4080 half can be lowered to 750 MHz and the other half to 600 MHz. The current binding only deals with CPU clocks. To describe FMan in the device tree, we need to describe its clock. Some chips have additional muxes that work like the CPU muxes, but are not described in the device tree. Others require inspecting the Reset Control Word to determine which PLL is used. Rather than continue to extend this mess, replace it. Have the driver bind to the chip-specific clockgen compatible, and keep the detailed description of quirky chip variations in the driver, where it can be easily fixed, refactored, and extended. Older device trees will continue to work (including a workaround for old ls1021a device trees that are missing compatible and reg in the clockgen node, which even the old binding required). The pll/mux details in old device trees will be ignored, but "clocks" properties pointing at the old nodes will still work, and be directed at the corresponding new clock. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-20 04:29:54 +00:00
/* Legacy node */
static void __init core_pll_init(struct device_node *np)
{
struct resource res;
int idx;
if (of_address_to_resource(np, 0, &res))
clk: mpc85xx: Update the driver to align to new clock bindings The clock bindings for Freescale CoreNet platform are updated. So, the driver needs to be updated accordingly. The main changes include: - Added a new node to present the input system clock - Changed PLL and MUX's compatible string Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com> Acked-by: Scott Wood <scottwood@freescale.com> Signed-off-by: Mike Turquette <mturquette@linaro.org>
2014-01-21 01:32:45 +00:00
return;
clk: qoriq: Move chip-specific knowledge into driver The device tree should describe the chips (or chip-like subblocks) in the system, but it generally does not describe individual registers -- it should identify, rather than describe, a programming interface. This has not been the case with the QorIQ clockgen nodes. The knowledge of what each bit setting of CLKCnCSR means is encoded in three places (binding, pll node, and mux node), and the last also needs to know which options are valid on a particular chip. All three of these locations are considered stable ABI, making it difficult to fix mistakes (of which I have found several), much less refactor the abstraction to be able to address problems, limitations, or new chips. Under the current binding, a pll clock specifier of 2 means that the PLL is divided by 4 -- and the driver implements this, unless there happen to be four clock-output-names rather than 3, in which case it interprets it as PLL divided by 3. This does not appear in the binding documentation at all. That hack is now considered stable ABI. The current device tree nodes contain errors, such as saying that T1040 can set a core clock to PLL/4 when only PLL and PLL/2 are options. The current binding also ignores some restrictions on clock selection, such as p5020's requirement that if a core uses the "wrong" PLL, that PLL must be clocked lower than the "correct" PLL and be at most 80% of the rated CPU frequency. Possibly because of the lack of the ability to express such nuance in the binding, some valid options are omitted from the device trees, such as the ability on p4080 to run cores 0-3 from PLL3 and cores 4-7 from PLL1 (again, only if they are at most 80% of rated CPU frequency). This omission, combined with excessive caution in the cpufreq driver (addressed in a subsequent patch), means that currently on a 1500 MHz p4080 with typical PLL configuration, cpufreq can lower the frequency to 1200 MHz on half the CPUs and do nothing on the others. With this patchset, all CPUs can be lowered to 1200 MHz on a rev2 p4080, and on a rev3 p4080 half can be lowered to 750 MHz and the other half to 600 MHz. The current binding only deals with CPU clocks. To describe FMan in the device tree, we need to describe its clock. Some chips have additional muxes that work like the CPU muxes, but are not described in the device tree. Others require inspecting the Reset Control Word to determine which PLL is used. Rather than continue to extend this mess, replace it. Have the driver bind to the chip-specific clockgen compatible, and keep the detailed description of quirky chip variations in the driver, where it can be easily fixed, refactored, and extended. Older device trees will continue to work (including a workaround for old ls1021a device trees that are missing compatible and reg in the clockgen node, which even the old binding required). The pll/mux details in old device trees will be ignored, but "clocks" properties pointing at the old nodes will still work, and be directed at the corresponding new clock. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-20 04:29:54 +00:00
if ((res.start & 0xfff) == 0xc00) {
/*
* ls1021a devtree labels the platform PLL
* with the core PLL compatible
*/
pltfrm_pll_init(np);
} else {
idx = (res.start & 0xf0) >> 5;
legacy_pll_init(np, CGA_PLL1 + idx);
clk: mpc85xx: Update the driver to align to new clock bindings The clock bindings for Freescale CoreNet platform are updated. So, the driver needs to be updated accordingly. The main changes include: - Added a new node to present the input system clock - Changed PLL and MUX's compatible string Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com> Acked-by: Scott Wood <scottwood@freescale.com> Signed-off-by: Mike Turquette <mturquette@linaro.org>
2014-01-21 01:32:45 +00:00
}
clk: qoriq: Move chip-specific knowledge into driver The device tree should describe the chips (or chip-like subblocks) in the system, but it generally does not describe individual registers -- it should identify, rather than describe, a programming interface. This has not been the case with the QorIQ clockgen nodes. The knowledge of what each bit setting of CLKCnCSR means is encoded in three places (binding, pll node, and mux node), and the last also needs to know which options are valid on a particular chip. All three of these locations are considered stable ABI, making it difficult to fix mistakes (of which I have found several), much less refactor the abstraction to be able to address problems, limitations, or new chips. Under the current binding, a pll clock specifier of 2 means that the PLL is divided by 4 -- and the driver implements this, unless there happen to be four clock-output-names rather than 3, in which case it interprets it as PLL divided by 3. This does not appear in the binding documentation at all. That hack is now considered stable ABI. The current device tree nodes contain errors, such as saying that T1040 can set a core clock to PLL/4 when only PLL and PLL/2 are options. The current binding also ignores some restrictions on clock selection, such as p5020's requirement that if a core uses the "wrong" PLL, that PLL must be clocked lower than the "correct" PLL and be at most 80% of the rated CPU frequency. Possibly because of the lack of the ability to express such nuance in the binding, some valid options are omitted from the device trees, such as the ability on p4080 to run cores 0-3 from PLL3 and cores 4-7 from PLL1 (again, only if they are at most 80% of rated CPU frequency). This omission, combined with excessive caution in the cpufreq driver (addressed in a subsequent patch), means that currently on a 1500 MHz p4080 with typical PLL configuration, cpufreq can lower the frequency to 1200 MHz on half the CPUs and do nothing on the others. With this patchset, all CPUs can be lowered to 1200 MHz on a rev2 p4080, and on a rev3 p4080 half can be lowered to 750 MHz and the other half to 600 MHz. The current binding only deals with CPU clocks. To describe FMan in the device tree, we need to describe its clock. Some chips have additional muxes that work like the CPU muxes, but are not described in the device tree. Others require inspecting the Reset Control Word to determine which PLL is used. Rather than continue to extend this mess, replace it. Have the driver bind to the chip-specific clockgen compatible, and keep the detailed description of quirky chip variations in the driver, where it can be easily fixed, refactored, and extended. Older device trees will continue to work (including a workaround for old ls1021a device trees that are missing compatible and reg in the clockgen node, which even the old binding required). The pll/mux details in old device trees will be ignored, but "clocks" properties pointing at the old nodes will still work, and be directed at the corresponding new clock. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-20 04:29:54 +00:00
}
clk: mpc85xx: Update the driver to align to new clock bindings The clock bindings for Freescale CoreNet platform are updated. So, the driver needs to be updated accordingly. The main changes include: - Added a new node to present the input system clock - Changed PLL and MUX's compatible string Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com> Acked-by: Scott Wood <scottwood@freescale.com> Signed-off-by: Mike Turquette <mturquette@linaro.org>
2014-01-21 01:32:45 +00:00
clk: qoriq: Move chip-specific knowledge into driver The device tree should describe the chips (or chip-like subblocks) in the system, but it generally does not describe individual registers -- it should identify, rather than describe, a programming interface. This has not been the case with the QorIQ clockgen nodes. The knowledge of what each bit setting of CLKCnCSR means is encoded in three places (binding, pll node, and mux node), and the last also needs to know which options are valid on a particular chip. All three of these locations are considered stable ABI, making it difficult to fix mistakes (of which I have found several), much less refactor the abstraction to be able to address problems, limitations, or new chips. Under the current binding, a pll clock specifier of 2 means that the PLL is divided by 4 -- and the driver implements this, unless there happen to be four clock-output-names rather than 3, in which case it interprets it as PLL divided by 3. This does not appear in the binding documentation at all. That hack is now considered stable ABI. The current device tree nodes contain errors, such as saying that T1040 can set a core clock to PLL/4 when only PLL and PLL/2 are options. The current binding also ignores some restrictions on clock selection, such as p5020's requirement that if a core uses the "wrong" PLL, that PLL must be clocked lower than the "correct" PLL and be at most 80% of the rated CPU frequency. Possibly because of the lack of the ability to express such nuance in the binding, some valid options are omitted from the device trees, such as the ability on p4080 to run cores 0-3 from PLL3 and cores 4-7 from PLL1 (again, only if they are at most 80% of rated CPU frequency). This omission, combined with excessive caution in the cpufreq driver (addressed in a subsequent patch), means that currently on a 1500 MHz p4080 with typical PLL configuration, cpufreq can lower the frequency to 1200 MHz on half the CPUs and do nothing on the others. With this patchset, all CPUs can be lowered to 1200 MHz on a rev2 p4080, and on a rev3 p4080 half can be lowered to 750 MHz and the other half to 600 MHz. The current binding only deals with CPU clocks. To describe FMan in the device tree, we need to describe its clock. Some chips have additional muxes that work like the CPU muxes, but are not described in the device tree. Others require inspecting the Reset Control Word to determine which PLL is used. Rather than continue to extend this mess, replace it. Have the driver bind to the chip-specific clockgen compatible, and keep the detailed description of quirky chip variations in the driver, where it can be easily fixed, refactored, and extended. Older device trees will continue to work (including a workaround for old ls1021a device trees that are missing compatible and reg in the clockgen node, which even the old binding required). The pll/mux details in old device trees will be ignored, but "clocks" properties pointing at the old nodes will still work, and be directed at the corresponding new clock. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-20 04:29:54 +00:00
static struct clk *clockgen_clk_get(struct of_phandle_args *clkspec, void *data)
{
struct clockgen *cg = data;
struct clk *clk;
struct clockgen_pll *pll;
u32 type, idx;
if (clkspec->args_count < 2) {
pr_err("%s: insufficient phandle args\n", __func__);
return ERR_PTR(-EINVAL);
clk: mpc85xx: Update the driver to align to new clock bindings The clock bindings for Freescale CoreNet platform are updated. So, the driver needs to be updated accordingly. The main changes include: - Added a new node to present the input system clock - Changed PLL and MUX's compatible string Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com> Acked-by: Scott Wood <scottwood@freescale.com> Signed-off-by: Mike Turquette <mturquette@linaro.org>
2014-01-21 01:32:45 +00:00
}
clk: qoriq: Move chip-specific knowledge into driver The device tree should describe the chips (or chip-like subblocks) in the system, but it generally does not describe individual registers -- it should identify, rather than describe, a programming interface. This has not been the case with the QorIQ clockgen nodes. The knowledge of what each bit setting of CLKCnCSR means is encoded in three places (binding, pll node, and mux node), and the last also needs to know which options are valid on a particular chip. All three of these locations are considered stable ABI, making it difficult to fix mistakes (of which I have found several), much less refactor the abstraction to be able to address problems, limitations, or new chips. Under the current binding, a pll clock specifier of 2 means that the PLL is divided by 4 -- and the driver implements this, unless there happen to be four clock-output-names rather than 3, in which case it interprets it as PLL divided by 3. This does not appear in the binding documentation at all. That hack is now considered stable ABI. The current device tree nodes contain errors, such as saying that T1040 can set a core clock to PLL/4 when only PLL and PLL/2 are options. The current binding also ignores some restrictions on clock selection, such as p5020's requirement that if a core uses the "wrong" PLL, that PLL must be clocked lower than the "correct" PLL and be at most 80% of the rated CPU frequency. Possibly because of the lack of the ability to express such nuance in the binding, some valid options are omitted from the device trees, such as the ability on p4080 to run cores 0-3 from PLL3 and cores 4-7 from PLL1 (again, only if they are at most 80% of rated CPU frequency). This omission, combined with excessive caution in the cpufreq driver (addressed in a subsequent patch), means that currently on a 1500 MHz p4080 with typical PLL configuration, cpufreq can lower the frequency to 1200 MHz on half the CPUs and do nothing on the others. With this patchset, all CPUs can be lowered to 1200 MHz on a rev2 p4080, and on a rev3 p4080 half can be lowered to 750 MHz and the other half to 600 MHz. The current binding only deals with CPU clocks. To describe FMan in the device tree, we need to describe its clock. Some chips have additional muxes that work like the CPU muxes, but are not described in the device tree. Others require inspecting the Reset Control Word to determine which PLL is used. Rather than continue to extend this mess, replace it. Have the driver bind to the chip-specific clockgen compatible, and keep the detailed description of quirky chip variations in the driver, where it can be easily fixed, refactored, and extended. Older device trees will continue to work (including a workaround for old ls1021a device trees that are missing compatible and reg in the clockgen node, which even the old binding required). The pll/mux details in old device trees will be ignored, but "clocks" properties pointing at the old nodes will still work, and be directed at the corresponding new clock. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-20 04:29:54 +00:00
type = clkspec->args[0];
idx = clkspec->args[1];
clk: mpc85xx: Update the driver to align to new clock bindings The clock bindings for Freescale CoreNet platform are updated. So, the driver needs to be updated accordingly. The main changes include: - Added a new node to present the input system clock - Changed PLL and MUX's compatible string Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com> Acked-by: Scott Wood <scottwood@freescale.com> Signed-off-by: Mike Turquette <mturquette@linaro.org>
2014-01-21 01:32:45 +00:00
clk: qoriq: Move chip-specific knowledge into driver The device tree should describe the chips (or chip-like subblocks) in the system, but it generally does not describe individual registers -- it should identify, rather than describe, a programming interface. This has not been the case with the QorIQ clockgen nodes. The knowledge of what each bit setting of CLKCnCSR means is encoded in three places (binding, pll node, and mux node), and the last also needs to know which options are valid on a particular chip. All three of these locations are considered stable ABI, making it difficult to fix mistakes (of which I have found several), much less refactor the abstraction to be able to address problems, limitations, or new chips. Under the current binding, a pll clock specifier of 2 means that the PLL is divided by 4 -- and the driver implements this, unless there happen to be four clock-output-names rather than 3, in which case it interprets it as PLL divided by 3. This does not appear in the binding documentation at all. That hack is now considered stable ABI. The current device tree nodes contain errors, such as saying that T1040 can set a core clock to PLL/4 when only PLL and PLL/2 are options. The current binding also ignores some restrictions on clock selection, such as p5020's requirement that if a core uses the "wrong" PLL, that PLL must be clocked lower than the "correct" PLL and be at most 80% of the rated CPU frequency. Possibly because of the lack of the ability to express such nuance in the binding, some valid options are omitted from the device trees, such as the ability on p4080 to run cores 0-3 from PLL3 and cores 4-7 from PLL1 (again, only if they are at most 80% of rated CPU frequency). This omission, combined with excessive caution in the cpufreq driver (addressed in a subsequent patch), means that currently on a 1500 MHz p4080 with typical PLL configuration, cpufreq can lower the frequency to 1200 MHz on half the CPUs and do nothing on the others. With this patchset, all CPUs can be lowered to 1200 MHz on a rev2 p4080, and on a rev3 p4080 half can be lowered to 750 MHz and the other half to 600 MHz. The current binding only deals with CPU clocks. To describe FMan in the device tree, we need to describe its clock. Some chips have additional muxes that work like the CPU muxes, but are not described in the device tree. Others require inspecting the Reset Control Word to determine which PLL is used. Rather than continue to extend this mess, replace it. Have the driver bind to the chip-specific clockgen compatible, and keep the detailed description of quirky chip variations in the driver, where it can be easily fixed, refactored, and extended. Older device trees will continue to work (including a workaround for old ls1021a device trees that are missing compatible and reg in the clockgen node, which even the old binding required). The pll/mux details in old device trees will be ignored, but "clocks" properties pointing at the old nodes will still work, and be directed at the corresponding new clock. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-20 04:29:54 +00:00
switch (type) {
case 0:
if (idx != 0)
goto bad_args;
clk = cg->sysclk;
break;
case 1:
if (idx >= ARRAY_SIZE(cg->cmux))
goto bad_args;
clk = cg->cmux[idx];
break;
case 2:
if (idx >= ARRAY_SIZE(cg->hwaccel))
goto bad_args;
clk = cg->hwaccel[idx];
break;
case 3:
if (idx >= ARRAY_SIZE(cg->fman))
goto bad_args;
clk = cg->fman[idx];
break;
case 4:
pll = &cg->pll[PLATFORM_PLL];
if (idx >= ARRAY_SIZE(pll->div))
goto bad_args;
clk = pll->div[idx].clk;
break;
default:
goto bad_args;
}
if (!clk)
return ERR_PTR(-ENOENT);
return clk;
bad_args:
pr_err("%s: Bad phandle args %u %u\n", __func__, type, idx);
return ERR_PTR(-EINVAL);
clk: add PowerPC corenet clock driver support This adds the clock driver for Freescale PowerPC corenet series SoCs using common clock infrastructure. Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com> Signed-off-by: Li Yang <leoli@freescale.com> Signed-off-by: Mike Turquette <mturquette@linaro.org>
2013-04-09 08:46:26 +00:00
}
clk: qoriq: Add support for the platform PLL Change-Id: Iac11ed95f274485a86d2c11f32a3dc502bcd020f Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com> Acked-by: Tang Yuantian <Yuantian.Tang@freescale.com> Signed-off-by: Michael Turquette <mturquette@linaro.org>
2015-01-21 10:03:31 +00:00
clk: qoriq: Move chip-specific knowledge into driver The device tree should describe the chips (or chip-like subblocks) in the system, but it generally does not describe individual registers -- it should identify, rather than describe, a programming interface. This has not been the case with the QorIQ clockgen nodes. The knowledge of what each bit setting of CLKCnCSR means is encoded in three places (binding, pll node, and mux node), and the last also needs to know which options are valid on a particular chip. All three of these locations are considered stable ABI, making it difficult to fix mistakes (of which I have found several), much less refactor the abstraction to be able to address problems, limitations, or new chips. Under the current binding, a pll clock specifier of 2 means that the PLL is divided by 4 -- and the driver implements this, unless there happen to be four clock-output-names rather than 3, in which case it interprets it as PLL divided by 3. This does not appear in the binding documentation at all. That hack is now considered stable ABI. The current device tree nodes contain errors, such as saying that T1040 can set a core clock to PLL/4 when only PLL and PLL/2 are options. The current binding also ignores some restrictions on clock selection, such as p5020's requirement that if a core uses the "wrong" PLL, that PLL must be clocked lower than the "correct" PLL and be at most 80% of the rated CPU frequency. Possibly because of the lack of the ability to express such nuance in the binding, some valid options are omitted from the device trees, such as the ability on p4080 to run cores 0-3 from PLL3 and cores 4-7 from PLL1 (again, only if they are at most 80% of rated CPU frequency). This omission, combined with excessive caution in the cpufreq driver (addressed in a subsequent patch), means that currently on a 1500 MHz p4080 with typical PLL configuration, cpufreq can lower the frequency to 1200 MHz on half the CPUs and do nothing on the others. With this patchset, all CPUs can be lowered to 1200 MHz on a rev2 p4080, and on a rev3 p4080 half can be lowered to 750 MHz and the other half to 600 MHz. The current binding only deals with CPU clocks. To describe FMan in the device tree, we need to describe its clock. Some chips have additional muxes that work like the CPU muxes, but are not described in the device tree. Others require inspecting the Reset Control Word to determine which PLL is used. Rather than continue to extend this mess, replace it. Have the driver bind to the chip-specific clockgen compatible, and keep the detailed description of quirky chip variations in the driver, where it can be easily fixed, refactored, and extended. Older device trees will continue to work (including a workaround for old ls1021a device trees that are missing compatible and reg in the clockgen node, which even the old binding required). The pll/mux details in old device trees will be ignored, but "clocks" properties pointing at the old nodes will still work, and be directed at the corresponding new clock. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-20 04:29:54 +00:00
#ifdef CONFIG_PPC
#include <asm/mpc85xx.h>
static const u32 a4510_svrs[] __initconst = {
(SVR_P2040 << 8) | 0x10, /* P2040 1.0 */
(SVR_P2040 << 8) | 0x11, /* P2040 1.1 */
(SVR_P2041 << 8) | 0x10, /* P2041 1.0 */
(SVR_P2041 << 8) | 0x11, /* P2041 1.1 */
(SVR_P3041 << 8) | 0x10, /* P3041 1.0 */
(SVR_P3041 << 8) | 0x11, /* P3041 1.1 */
(SVR_P4040 << 8) | 0x20, /* P4040 2.0 */
(SVR_P4080 << 8) | 0x20, /* P4080 2.0 */
(SVR_P5010 << 8) | 0x10, /* P5010 1.0 */
(SVR_P5010 << 8) | 0x20, /* P5010 2.0 */
(SVR_P5020 << 8) | 0x10, /* P5020 1.0 */
(SVR_P5021 << 8) | 0x10, /* P5021 1.0 */
(SVR_P5040 << 8) | 0x10, /* P5040 1.0 */
};
#define SVR_SECURITY 0x80000 /* The Security (E) bit */
static bool __init has_erratum_a4510(void)
clk: qoriq: Add support for the platform PLL Change-Id: Iac11ed95f274485a86d2c11f32a3dc502bcd020f Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com> Acked-by: Tang Yuantian <Yuantian.Tang@freescale.com> Signed-off-by: Michael Turquette <mturquette@linaro.org>
2015-01-21 10:03:31 +00:00
{
clk: qoriq: Move chip-specific knowledge into driver The device tree should describe the chips (or chip-like subblocks) in the system, but it generally does not describe individual registers -- it should identify, rather than describe, a programming interface. This has not been the case with the QorIQ clockgen nodes. The knowledge of what each bit setting of CLKCnCSR means is encoded in three places (binding, pll node, and mux node), and the last also needs to know which options are valid on a particular chip. All three of these locations are considered stable ABI, making it difficult to fix mistakes (of which I have found several), much less refactor the abstraction to be able to address problems, limitations, or new chips. Under the current binding, a pll clock specifier of 2 means that the PLL is divided by 4 -- and the driver implements this, unless there happen to be four clock-output-names rather than 3, in which case it interprets it as PLL divided by 3. This does not appear in the binding documentation at all. That hack is now considered stable ABI. The current device tree nodes contain errors, such as saying that T1040 can set a core clock to PLL/4 when only PLL and PLL/2 are options. The current binding also ignores some restrictions on clock selection, such as p5020's requirement that if a core uses the "wrong" PLL, that PLL must be clocked lower than the "correct" PLL and be at most 80% of the rated CPU frequency. Possibly because of the lack of the ability to express such nuance in the binding, some valid options are omitted from the device trees, such as the ability on p4080 to run cores 0-3 from PLL3 and cores 4-7 from PLL1 (again, only if they are at most 80% of rated CPU frequency). This omission, combined with excessive caution in the cpufreq driver (addressed in a subsequent patch), means that currently on a 1500 MHz p4080 with typical PLL configuration, cpufreq can lower the frequency to 1200 MHz on half the CPUs and do nothing on the others. With this patchset, all CPUs can be lowered to 1200 MHz on a rev2 p4080, and on a rev3 p4080 half can be lowered to 750 MHz and the other half to 600 MHz. The current binding only deals with CPU clocks. To describe FMan in the device tree, we need to describe its clock. Some chips have additional muxes that work like the CPU muxes, but are not described in the device tree. Others require inspecting the Reset Control Word to determine which PLL is used. Rather than continue to extend this mess, replace it. Have the driver bind to the chip-specific clockgen compatible, and keep the detailed description of quirky chip variations in the driver, where it can be easily fixed, refactored, and extended. Older device trees will continue to work (including a workaround for old ls1021a device trees that are missing compatible and reg in the clockgen node, which even the old binding required). The pll/mux details in old device trees will be ignored, but "clocks" properties pointing at the old nodes will still work, and be directed at the corresponding new clock. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-20 04:29:54 +00:00
u32 svr = mfspr(SPRN_SVR);
int i;
svr &= ~SVR_SECURITY;
for (i = 0; i < ARRAY_SIZE(a4510_svrs); i++) {
if (svr == a4510_svrs[i])
return true;
clk: qoriq: Add support for the platform PLL Change-Id: Iac11ed95f274485a86d2c11f32a3dc502bcd020f Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com> Acked-by: Tang Yuantian <Yuantian.Tang@freescale.com> Signed-off-by: Michael Turquette <mturquette@linaro.org>
2015-01-21 10:03:31 +00:00
}
clk: qoriq: Move chip-specific knowledge into driver The device tree should describe the chips (or chip-like subblocks) in the system, but it generally does not describe individual registers -- it should identify, rather than describe, a programming interface. This has not been the case with the QorIQ clockgen nodes. The knowledge of what each bit setting of CLKCnCSR means is encoded in three places (binding, pll node, and mux node), and the last also needs to know which options are valid on a particular chip. All three of these locations are considered stable ABI, making it difficult to fix mistakes (of which I have found several), much less refactor the abstraction to be able to address problems, limitations, or new chips. Under the current binding, a pll clock specifier of 2 means that the PLL is divided by 4 -- and the driver implements this, unless there happen to be four clock-output-names rather than 3, in which case it interprets it as PLL divided by 3. This does not appear in the binding documentation at all. That hack is now considered stable ABI. The current device tree nodes contain errors, such as saying that T1040 can set a core clock to PLL/4 when only PLL and PLL/2 are options. The current binding also ignores some restrictions on clock selection, such as p5020's requirement that if a core uses the "wrong" PLL, that PLL must be clocked lower than the "correct" PLL and be at most 80% of the rated CPU frequency. Possibly because of the lack of the ability to express such nuance in the binding, some valid options are omitted from the device trees, such as the ability on p4080 to run cores 0-3 from PLL3 and cores 4-7 from PLL1 (again, only if they are at most 80% of rated CPU frequency). This omission, combined with excessive caution in the cpufreq driver (addressed in a subsequent patch), means that currently on a 1500 MHz p4080 with typical PLL configuration, cpufreq can lower the frequency to 1200 MHz on half the CPUs and do nothing on the others. With this patchset, all CPUs can be lowered to 1200 MHz on a rev2 p4080, and on a rev3 p4080 half can be lowered to 750 MHz and the other half to 600 MHz. The current binding only deals with CPU clocks. To describe FMan in the device tree, we need to describe its clock. Some chips have additional muxes that work like the CPU muxes, but are not described in the device tree. Others require inspecting the Reset Control Word to determine which PLL is used. Rather than continue to extend this mess, replace it. Have the driver bind to the chip-specific clockgen compatible, and keep the detailed description of quirky chip variations in the driver, where it can be easily fixed, refactored, and extended. Older device trees will continue to work (including a workaround for old ls1021a device trees that are missing compatible and reg in the clockgen node, which even the old binding required). The pll/mux details in old device trees will be ignored, but "clocks" properties pointing at the old nodes will still work, and be directed at the corresponding new clock. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-20 04:29:54 +00:00
return false;
}
#else
static bool __init has_erratum_a4510(void)
{
return false;
}
#endif
clk: qoriq: Add support for the platform PLL Change-Id: Iac11ed95f274485a86d2c11f32a3dc502bcd020f Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com> Acked-by: Tang Yuantian <Yuantian.Tang@freescale.com> Signed-off-by: Michael Turquette <mturquette@linaro.org>
2015-01-21 10:03:31 +00:00
clk: qoriq: Move chip-specific knowledge into driver The device tree should describe the chips (or chip-like subblocks) in the system, but it generally does not describe individual registers -- it should identify, rather than describe, a programming interface. This has not been the case with the QorIQ clockgen nodes. The knowledge of what each bit setting of CLKCnCSR means is encoded in three places (binding, pll node, and mux node), and the last also needs to know which options are valid on a particular chip. All three of these locations are considered stable ABI, making it difficult to fix mistakes (of which I have found several), much less refactor the abstraction to be able to address problems, limitations, or new chips. Under the current binding, a pll clock specifier of 2 means that the PLL is divided by 4 -- and the driver implements this, unless there happen to be four clock-output-names rather than 3, in which case it interprets it as PLL divided by 3. This does not appear in the binding documentation at all. That hack is now considered stable ABI. The current device tree nodes contain errors, such as saying that T1040 can set a core clock to PLL/4 when only PLL and PLL/2 are options. The current binding also ignores some restrictions on clock selection, such as p5020's requirement that if a core uses the "wrong" PLL, that PLL must be clocked lower than the "correct" PLL and be at most 80% of the rated CPU frequency. Possibly because of the lack of the ability to express such nuance in the binding, some valid options are omitted from the device trees, such as the ability on p4080 to run cores 0-3 from PLL3 and cores 4-7 from PLL1 (again, only if they are at most 80% of rated CPU frequency). This omission, combined with excessive caution in the cpufreq driver (addressed in a subsequent patch), means that currently on a 1500 MHz p4080 with typical PLL configuration, cpufreq can lower the frequency to 1200 MHz on half the CPUs and do nothing on the others. With this patchset, all CPUs can be lowered to 1200 MHz on a rev2 p4080, and on a rev3 p4080 half can be lowered to 750 MHz and the other half to 600 MHz. The current binding only deals with CPU clocks. To describe FMan in the device tree, we need to describe its clock. Some chips have additional muxes that work like the CPU muxes, but are not described in the device tree. Others require inspecting the Reset Control Word to determine which PLL is used. Rather than continue to extend this mess, replace it. Have the driver bind to the chip-specific clockgen compatible, and keep the detailed description of quirky chip variations in the driver, where it can be easily fixed, refactored, and extended. Older device trees will continue to work (including a workaround for old ls1021a device trees that are missing compatible and reg in the clockgen node, which even the old binding required). The pll/mux details in old device trees will be ignored, but "clocks" properties pointing at the old nodes will still work, and be directed at the corresponding new clock. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-20 04:29:54 +00:00
static void __init clockgen_init(struct device_node *np)
{
int i, ret;
bool is_old_ls1021a = false;
clk: qoriq: Add support for the platform PLL Change-Id: Iac11ed95f274485a86d2c11f32a3dc502bcd020f Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com> Acked-by: Tang Yuantian <Yuantian.Tang@freescale.com> Signed-off-by: Michael Turquette <mturquette@linaro.org>
2015-01-21 10:03:31 +00:00
clk: qoriq: Move chip-specific knowledge into driver The device tree should describe the chips (or chip-like subblocks) in the system, but it generally does not describe individual registers -- it should identify, rather than describe, a programming interface. This has not been the case with the QorIQ clockgen nodes. The knowledge of what each bit setting of CLKCnCSR means is encoded in three places (binding, pll node, and mux node), and the last also needs to know which options are valid on a particular chip. All three of these locations are considered stable ABI, making it difficult to fix mistakes (of which I have found several), much less refactor the abstraction to be able to address problems, limitations, or new chips. Under the current binding, a pll clock specifier of 2 means that the PLL is divided by 4 -- and the driver implements this, unless there happen to be four clock-output-names rather than 3, in which case it interprets it as PLL divided by 3. This does not appear in the binding documentation at all. That hack is now considered stable ABI. The current device tree nodes contain errors, such as saying that T1040 can set a core clock to PLL/4 when only PLL and PLL/2 are options. The current binding also ignores some restrictions on clock selection, such as p5020's requirement that if a core uses the "wrong" PLL, that PLL must be clocked lower than the "correct" PLL and be at most 80% of the rated CPU frequency. Possibly because of the lack of the ability to express such nuance in the binding, some valid options are omitted from the device trees, such as the ability on p4080 to run cores 0-3 from PLL3 and cores 4-7 from PLL1 (again, only if they are at most 80% of rated CPU frequency). This omission, combined with excessive caution in the cpufreq driver (addressed in a subsequent patch), means that currently on a 1500 MHz p4080 with typical PLL configuration, cpufreq can lower the frequency to 1200 MHz on half the CPUs and do nothing on the others. With this patchset, all CPUs can be lowered to 1200 MHz on a rev2 p4080, and on a rev3 p4080 half can be lowered to 750 MHz and the other half to 600 MHz. The current binding only deals with CPU clocks. To describe FMan in the device tree, we need to describe its clock. Some chips have additional muxes that work like the CPU muxes, but are not described in the device tree. Others require inspecting the Reset Control Word to determine which PLL is used. Rather than continue to extend this mess, replace it. Have the driver bind to the chip-specific clockgen compatible, and keep the detailed description of quirky chip variations in the driver, where it can be easily fixed, refactored, and extended. Older device trees will continue to work (including a workaround for old ls1021a device trees that are missing compatible and reg in the clockgen node, which even the old binding required). The pll/mux details in old device trees will be ignored, but "clocks" properties pointing at the old nodes will still work, and be directed at the corresponding new clock. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-20 04:29:54 +00:00
/* May have already been called by a legacy probe */
if (clockgen.node)
clk: qoriq: Add support for the platform PLL Change-Id: Iac11ed95f274485a86d2c11f32a3dc502bcd020f Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com> Acked-by: Tang Yuantian <Yuantian.Tang@freescale.com> Signed-off-by: Michael Turquette <mturquette@linaro.org>
2015-01-21 10:03:31 +00:00
return;
clk: qoriq: Move chip-specific knowledge into driver The device tree should describe the chips (or chip-like subblocks) in the system, but it generally does not describe individual registers -- it should identify, rather than describe, a programming interface. This has not been the case with the QorIQ clockgen nodes. The knowledge of what each bit setting of CLKCnCSR means is encoded in three places (binding, pll node, and mux node), and the last also needs to know which options are valid on a particular chip. All three of these locations are considered stable ABI, making it difficult to fix mistakes (of which I have found several), much less refactor the abstraction to be able to address problems, limitations, or new chips. Under the current binding, a pll clock specifier of 2 means that the PLL is divided by 4 -- and the driver implements this, unless there happen to be four clock-output-names rather than 3, in which case it interprets it as PLL divided by 3. This does not appear in the binding documentation at all. That hack is now considered stable ABI. The current device tree nodes contain errors, such as saying that T1040 can set a core clock to PLL/4 when only PLL and PLL/2 are options. The current binding also ignores some restrictions on clock selection, such as p5020's requirement that if a core uses the "wrong" PLL, that PLL must be clocked lower than the "correct" PLL and be at most 80% of the rated CPU frequency. Possibly because of the lack of the ability to express such nuance in the binding, some valid options are omitted from the device trees, such as the ability on p4080 to run cores 0-3 from PLL3 and cores 4-7 from PLL1 (again, only if they are at most 80% of rated CPU frequency). This omission, combined with excessive caution in the cpufreq driver (addressed in a subsequent patch), means that currently on a 1500 MHz p4080 with typical PLL configuration, cpufreq can lower the frequency to 1200 MHz on half the CPUs and do nothing on the others. With this patchset, all CPUs can be lowered to 1200 MHz on a rev2 p4080, and on a rev3 p4080 half can be lowered to 750 MHz and the other half to 600 MHz. The current binding only deals with CPU clocks. To describe FMan in the device tree, we need to describe its clock. Some chips have additional muxes that work like the CPU muxes, but are not described in the device tree. Others require inspecting the Reset Control Word to determine which PLL is used. Rather than continue to extend this mess, replace it. Have the driver bind to the chip-specific clockgen compatible, and keep the detailed description of quirky chip variations in the driver, where it can be easily fixed, refactored, and extended. Older device trees will continue to work (including a workaround for old ls1021a device trees that are missing compatible and reg in the clockgen node, which even the old binding required). The pll/mux details in old device trees will be ignored, but "clocks" properties pointing at the old nodes will still work, and be directed at the corresponding new clock. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-20 04:29:54 +00:00
clockgen.node = np;
clockgen.regs = of_iomap(np, 0);
if (!clockgen.regs &&
of_device_is_compatible(of_root, "fsl,ls1021a")) {
/* Compatibility hack for old, broken device trees */
clockgen.regs = ioremap(0x1ee1000, 0x1000);
is_old_ls1021a = true;
}
if (!clockgen.regs) {
pr_err("%s(): %s: of_iomap() failed\n", __func__, np->name);
clk: qoriq: Add support for the platform PLL Change-Id: Iac11ed95f274485a86d2c11f32a3dc502bcd020f Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com> Acked-by: Tang Yuantian <Yuantian.Tang@freescale.com> Signed-off-by: Michael Turquette <mturquette@linaro.org>
2015-01-21 10:03:31 +00:00
return;
}
clk: qoriq: Move chip-specific knowledge into driver The device tree should describe the chips (or chip-like subblocks) in the system, but it generally does not describe individual registers -- it should identify, rather than describe, a programming interface. This has not been the case with the QorIQ clockgen nodes. The knowledge of what each bit setting of CLKCnCSR means is encoded in three places (binding, pll node, and mux node), and the last also needs to know which options are valid on a particular chip. All three of these locations are considered stable ABI, making it difficult to fix mistakes (of which I have found several), much less refactor the abstraction to be able to address problems, limitations, or new chips. Under the current binding, a pll clock specifier of 2 means that the PLL is divided by 4 -- and the driver implements this, unless there happen to be four clock-output-names rather than 3, in which case it interprets it as PLL divided by 3. This does not appear in the binding documentation at all. That hack is now considered stable ABI. The current device tree nodes contain errors, such as saying that T1040 can set a core clock to PLL/4 when only PLL and PLL/2 are options. The current binding also ignores some restrictions on clock selection, such as p5020's requirement that if a core uses the "wrong" PLL, that PLL must be clocked lower than the "correct" PLL and be at most 80% of the rated CPU frequency. Possibly because of the lack of the ability to express such nuance in the binding, some valid options are omitted from the device trees, such as the ability on p4080 to run cores 0-3 from PLL3 and cores 4-7 from PLL1 (again, only if they are at most 80% of rated CPU frequency). This omission, combined with excessive caution in the cpufreq driver (addressed in a subsequent patch), means that currently on a 1500 MHz p4080 with typical PLL configuration, cpufreq can lower the frequency to 1200 MHz on half the CPUs and do nothing on the others. With this patchset, all CPUs can be lowered to 1200 MHz on a rev2 p4080, and on a rev3 p4080 half can be lowered to 750 MHz and the other half to 600 MHz. The current binding only deals with CPU clocks. To describe FMan in the device tree, we need to describe its clock. Some chips have additional muxes that work like the CPU muxes, but are not described in the device tree. Others require inspecting the Reset Control Word to determine which PLL is used. Rather than continue to extend this mess, replace it. Have the driver bind to the chip-specific clockgen compatible, and keep the detailed description of quirky chip variations in the driver, where it can be easily fixed, refactored, and extended. Older device trees will continue to work (including a workaround for old ls1021a device trees that are missing compatible and reg in the clockgen node, which even the old binding required). The pll/mux details in old device trees will be ignored, but "clocks" properties pointing at the old nodes will still work, and be directed at the corresponding new clock. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-20 04:29:54 +00:00
for (i = 0; i < ARRAY_SIZE(chipinfo); i++) {
if (of_device_is_compatible(np, chipinfo[i].compat))
break;
if (is_old_ls1021a &&
!strcmp(chipinfo[i].compat, "fsl,ls1021a-clockgen"))
break;
clk: qoriq: Add support for the platform PLL Change-Id: Iac11ed95f274485a86d2c11f32a3dc502bcd020f Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com> Acked-by: Tang Yuantian <Yuantian.Tang@freescale.com> Signed-off-by: Michael Turquette <mturquette@linaro.org>
2015-01-21 10:03:31 +00:00
}
clk: qoriq: Move chip-specific knowledge into driver The device tree should describe the chips (or chip-like subblocks) in the system, but it generally does not describe individual registers -- it should identify, rather than describe, a programming interface. This has not been the case with the QorIQ clockgen nodes. The knowledge of what each bit setting of CLKCnCSR means is encoded in three places (binding, pll node, and mux node), and the last also needs to know which options are valid on a particular chip. All three of these locations are considered stable ABI, making it difficult to fix mistakes (of which I have found several), much less refactor the abstraction to be able to address problems, limitations, or new chips. Under the current binding, a pll clock specifier of 2 means that the PLL is divided by 4 -- and the driver implements this, unless there happen to be four clock-output-names rather than 3, in which case it interprets it as PLL divided by 3. This does not appear in the binding documentation at all. That hack is now considered stable ABI. The current device tree nodes contain errors, such as saying that T1040 can set a core clock to PLL/4 when only PLL and PLL/2 are options. The current binding also ignores some restrictions on clock selection, such as p5020's requirement that if a core uses the "wrong" PLL, that PLL must be clocked lower than the "correct" PLL and be at most 80% of the rated CPU frequency. Possibly because of the lack of the ability to express such nuance in the binding, some valid options are omitted from the device trees, such as the ability on p4080 to run cores 0-3 from PLL3 and cores 4-7 from PLL1 (again, only if they are at most 80% of rated CPU frequency). This omission, combined with excessive caution in the cpufreq driver (addressed in a subsequent patch), means that currently on a 1500 MHz p4080 with typical PLL configuration, cpufreq can lower the frequency to 1200 MHz on half the CPUs and do nothing on the others. With this patchset, all CPUs can be lowered to 1200 MHz on a rev2 p4080, and on a rev3 p4080 half can be lowered to 750 MHz and the other half to 600 MHz. The current binding only deals with CPU clocks. To describe FMan in the device tree, we need to describe its clock. Some chips have additional muxes that work like the CPU muxes, but are not described in the device tree. Others require inspecting the Reset Control Word to determine which PLL is used. Rather than continue to extend this mess, replace it. Have the driver bind to the chip-specific clockgen compatible, and keep the detailed description of quirky chip variations in the driver, where it can be easily fixed, refactored, and extended. Older device trees will continue to work (including a workaround for old ls1021a device trees that are missing compatible and reg in the clockgen node, which even the old binding required). The pll/mux details in old device trees will be ignored, but "clocks" properties pointing at the old nodes will still work, and be directed at the corresponding new clock. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-20 04:29:54 +00:00
if (i == ARRAY_SIZE(chipinfo)) {
pr_err("%s: unknown clockgen node %s\n", __func__,
np->full_name);
goto err;
}
clockgen.info = chipinfo[i];
if (clockgen.info.guts_compat) {
struct device_node *guts;
clk: qoriq: Add support for the platform PLL Change-Id: Iac11ed95f274485a86d2c11f32a3dc502bcd020f Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com> Acked-by: Tang Yuantian <Yuantian.Tang@freescale.com> Signed-off-by: Michael Turquette <mturquette@linaro.org>
2015-01-21 10:03:31 +00:00
clk: qoriq: Move chip-specific knowledge into driver The device tree should describe the chips (or chip-like subblocks) in the system, but it generally does not describe individual registers -- it should identify, rather than describe, a programming interface. This has not been the case with the QorIQ clockgen nodes. The knowledge of what each bit setting of CLKCnCSR means is encoded in three places (binding, pll node, and mux node), and the last also needs to know which options are valid on a particular chip. All three of these locations are considered stable ABI, making it difficult to fix mistakes (of which I have found several), much less refactor the abstraction to be able to address problems, limitations, or new chips. Under the current binding, a pll clock specifier of 2 means that the PLL is divided by 4 -- and the driver implements this, unless there happen to be four clock-output-names rather than 3, in which case it interprets it as PLL divided by 3. This does not appear in the binding documentation at all. That hack is now considered stable ABI. The current device tree nodes contain errors, such as saying that T1040 can set a core clock to PLL/4 when only PLL and PLL/2 are options. The current binding also ignores some restrictions on clock selection, such as p5020's requirement that if a core uses the "wrong" PLL, that PLL must be clocked lower than the "correct" PLL and be at most 80% of the rated CPU frequency. Possibly because of the lack of the ability to express such nuance in the binding, some valid options are omitted from the device trees, such as the ability on p4080 to run cores 0-3 from PLL3 and cores 4-7 from PLL1 (again, only if they are at most 80% of rated CPU frequency). This omission, combined with excessive caution in the cpufreq driver (addressed in a subsequent patch), means that currently on a 1500 MHz p4080 with typical PLL configuration, cpufreq can lower the frequency to 1200 MHz on half the CPUs and do nothing on the others. With this patchset, all CPUs can be lowered to 1200 MHz on a rev2 p4080, and on a rev3 p4080 half can be lowered to 750 MHz and the other half to 600 MHz. The current binding only deals with CPU clocks. To describe FMan in the device tree, we need to describe its clock. Some chips have additional muxes that work like the CPU muxes, but are not described in the device tree. Others require inspecting the Reset Control Word to determine which PLL is used. Rather than continue to extend this mess, replace it. Have the driver bind to the chip-specific clockgen compatible, and keep the detailed description of quirky chip variations in the driver, where it can be easily fixed, refactored, and extended. Older device trees will continue to work (including a workaround for old ls1021a device trees that are missing compatible and reg in the clockgen node, which even the old binding required). The pll/mux details in old device trees will be ignored, but "clocks" properties pointing at the old nodes will still work, and be directed at the corresponding new clock. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-20 04:29:54 +00:00
guts = of_find_compatible_node(NULL, NULL,
clockgen.info.guts_compat);
if (guts) {
clockgen.guts = of_iomap(guts, 0);
if (!clockgen.guts) {
pr_err("%s: Couldn't map %s regs\n", __func__,
guts->full_name);
}
clk: qoriq: Add support for the platform PLL Change-Id: Iac11ed95f274485a86d2c11f32a3dc502bcd020f Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com> Acked-by: Tang Yuantian <Yuantian.Tang@freescale.com> Signed-off-by: Michael Turquette <mturquette@linaro.org>
2015-01-21 10:03:31 +00:00
}
clk: qoriq: Move chip-specific knowledge into driver The device tree should describe the chips (or chip-like subblocks) in the system, but it generally does not describe individual registers -- it should identify, rather than describe, a programming interface. This has not been the case with the QorIQ clockgen nodes. The knowledge of what each bit setting of CLKCnCSR means is encoded in three places (binding, pll node, and mux node), and the last also needs to know which options are valid on a particular chip. All three of these locations are considered stable ABI, making it difficult to fix mistakes (of which I have found several), much less refactor the abstraction to be able to address problems, limitations, or new chips. Under the current binding, a pll clock specifier of 2 means that the PLL is divided by 4 -- and the driver implements this, unless there happen to be four clock-output-names rather than 3, in which case it interprets it as PLL divided by 3. This does not appear in the binding documentation at all. That hack is now considered stable ABI. The current device tree nodes contain errors, such as saying that T1040 can set a core clock to PLL/4 when only PLL and PLL/2 are options. The current binding also ignores some restrictions on clock selection, such as p5020's requirement that if a core uses the "wrong" PLL, that PLL must be clocked lower than the "correct" PLL and be at most 80% of the rated CPU frequency. Possibly because of the lack of the ability to express such nuance in the binding, some valid options are omitted from the device trees, such as the ability on p4080 to run cores 0-3 from PLL3 and cores 4-7 from PLL1 (again, only if they are at most 80% of rated CPU frequency). This omission, combined with excessive caution in the cpufreq driver (addressed in a subsequent patch), means that currently on a 1500 MHz p4080 with typical PLL configuration, cpufreq can lower the frequency to 1200 MHz on half the CPUs and do nothing on the others. With this patchset, all CPUs can be lowered to 1200 MHz on a rev2 p4080, and on a rev3 p4080 half can be lowered to 750 MHz and the other half to 600 MHz. The current binding only deals with CPU clocks. To describe FMan in the device tree, we need to describe its clock. Some chips have additional muxes that work like the CPU muxes, but are not described in the device tree. Others require inspecting the Reset Control Word to determine which PLL is used. Rather than continue to extend this mess, replace it. Have the driver bind to the chip-specific clockgen compatible, and keep the detailed description of quirky chip variations in the driver, where it can be easily fixed, refactored, and extended. Older device trees will continue to work (including a workaround for old ls1021a device trees that are missing compatible and reg in the clockgen node, which even the old binding required). The pll/mux details in old device trees will be ignored, but "clocks" properties pointing at the old nodes will still work, and be directed at the corresponding new clock. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-20 04:29:54 +00:00
clk: qoriq: Add support for the platform PLL Change-Id: Iac11ed95f274485a86d2c11f32a3dc502bcd020f Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com> Acked-by: Tang Yuantian <Yuantian.Tang@freescale.com> Signed-off-by: Michael Turquette <mturquette@linaro.org>
2015-01-21 10:03:31 +00:00
}
clk: qoriq: Move chip-specific knowledge into driver The device tree should describe the chips (or chip-like subblocks) in the system, but it generally does not describe individual registers -- it should identify, rather than describe, a programming interface. This has not been the case with the QorIQ clockgen nodes. The knowledge of what each bit setting of CLKCnCSR means is encoded in three places (binding, pll node, and mux node), and the last also needs to know which options are valid on a particular chip. All three of these locations are considered stable ABI, making it difficult to fix mistakes (of which I have found several), much less refactor the abstraction to be able to address problems, limitations, or new chips. Under the current binding, a pll clock specifier of 2 means that the PLL is divided by 4 -- and the driver implements this, unless there happen to be four clock-output-names rather than 3, in which case it interprets it as PLL divided by 3. This does not appear in the binding documentation at all. That hack is now considered stable ABI. The current device tree nodes contain errors, such as saying that T1040 can set a core clock to PLL/4 when only PLL and PLL/2 are options. The current binding also ignores some restrictions on clock selection, such as p5020's requirement that if a core uses the "wrong" PLL, that PLL must be clocked lower than the "correct" PLL and be at most 80% of the rated CPU frequency. Possibly because of the lack of the ability to express such nuance in the binding, some valid options are omitted from the device trees, such as the ability on p4080 to run cores 0-3 from PLL3 and cores 4-7 from PLL1 (again, only if they are at most 80% of rated CPU frequency). This omission, combined with excessive caution in the cpufreq driver (addressed in a subsequent patch), means that currently on a 1500 MHz p4080 with typical PLL configuration, cpufreq can lower the frequency to 1200 MHz on half the CPUs and do nothing on the others. With this patchset, all CPUs can be lowered to 1200 MHz on a rev2 p4080, and on a rev3 p4080 half can be lowered to 750 MHz and the other half to 600 MHz. The current binding only deals with CPU clocks. To describe FMan in the device tree, we need to describe its clock. Some chips have additional muxes that work like the CPU muxes, but are not described in the device tree. Others require inspecting the Reset Control Word to determine which PLL is used. Rather than continue to extend this mess, replace it. Have the driver bind to the chip-specific clockgen compatible, and keep the detailed description of quirky chip variations in the driver, where it can be easily fixed, refactored, and extended. Older device trees will continue to work (including a workaround for old ls1021a device trees that are missing compatible and reg in the clockgen node, which even the old binding required). The pll/mux details in old device trees will be ignored, but "clocks" properties pointing at the old nodes will still work, and be directed at the corresponding new clock. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-20 04:29:54 +00:00
if (has_erratum_a4510())
clockgen.info.flags |= CG_CMUX_GE_PLAT;
clockgen.sysclk = create_sysclk("cg-sysclk");
create_plls(&clockgen);
create_muxes(&clockgen);
if (clockgen.info.init_periph)
clockgen.info.init_periph(&clockgen);
ret = of_clk_add_provider(np, clockgen_clk_get, &clockgen);
if (ret) {
pr_err("%s: Couldn't register clk provider for node %s: %d\n",
__func__, np->name, ret);
clk: qoriq: Add support for the platform PLL Change-Id: Iac11ed95f274485a86d2c11f32a3dc502bcd020f Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com> Acked-by: Tang Yuantian <Yuantian.Tang@freescale.com> Signed-off-by: Michael Turquette <mturquette@linaro.org>
2015-01-21 10:03:31 +00:00
}
return;
clk: qoriq: Move chip-specific knowledge into driver The device tree should describe the chips (or chip-like subblocks) in the system, but it generally does not describe individual registers -- it should identify, rather than describe, a programming interface. This has not been the case with the QorIQ clockgen nodes. The knowledge of what each bit setting of CLKCnCSR means is encoded in three places (binding, pll node, and mux node), and the last also needs to know which options are valid on a particular chip. All three of these locations are considered stable ABI, making it difficult to fix mistakes (of which I have found several), much less refactor the abstraction to be able to address problems, limitations, or new chips. Under the current binding, a pll clock specifier of 2 means that the PLL is divided by 4 -- and the driver implements this, unless there happen to be four clock-output-names rather than 3, in which case it interprets it as PLL divided by 3. This does not appear in the binding documentation at all. That hack is now considered stable ABI. The current device tree nodes contain errors, such as saying that T1040 can set a core clock to PLL/4 when only PLL and PLL/2 are options. The current binding also ignores some restrictions on clock selection, such as p5020's requirement that if a core uses the "wrong" PLL, that PLL must be clocked lower than the "correct" PLL and be at most 80% of the rated CPU frequency. Possibly because of the lack of the ability to express such nuance in the binding, some valid options are omitted from the device trees, such as the ability on p4080 to run cores 0-3 from PLL3 and cores 4-7 from PLL1 (again, only if they are at most 80% of rated CPU frequency). This omission, combined with excessive caution in the cpufreq driver (addressed in a subsequent patch), means that currently on a 1500 MHz p4080 with typical PLL configuration, cpufreq can lower the frequency to 1200 MHz on half the CPUs and do nothing on the others. With this patchset, all CPUs can be lowered to 1200 MHz on a rev2 p4080, and on a rev3 p4080 half can be lowered to 750 MHz and the other half to 600 MHz. The current binding only deals with CPU clocks. To describe FMan in the device tree, we need to describe its clock. Some chips have additional muxes that work like the CPU muxes, but are not described in the device tree. Others require inspecting the Reset Control Word to determine which PLL is used. Rather than continue to extend this mess, replace it. Have the driver bind to the chip-specific clockgen compatible, and keep the detailed description of quirky chip variations in the driver, where it can be easily fixed, refactored, and extended. Older device trees will continue to work (including a workaround for old ls1021a device trees that are missing compatible and reg in the clockgen node, which even the old binding required). The pll/mux details in old device trees will be ignored, but "clocks" properties pointing at the old nodes will still work, and be directed at the corresponding new clock. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-20 04:29:54 +00:00
err:
iounmap(clockgen.regs);
clockgen.regs = NULL;
clk: qoriq: Add support for the platform PLL Change-Id: Iac11ed95f274485a86d2c11f32a3dc502bcd020f Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com> Acked-by: Tang Yuantian <Yuantian.Tang@freescale.com> Signed-off-by: Michael Turquette <mturquette@linaro.org>
2015-01-21 10:03:31 +00:00
}
clk: qoriq: Move chip-specific knowledge into driver The device tree should describe the chips (or chip-like subblocks) in the system, but it generally does not describe individual registers -- it should identify, rather than describe, a programming interface. This has not been the case with the QorIQ clockgen nodes. The knowledge of what each bit setting of CLKCnCSR means is encoded in three places (binding, pll node, and mux node), and the last also needs to know which options are valid on a particular chip. All three of these locations are considered stable ABI, making it difficult to fix mistakes (of which I have found several), much less refactor the abstraction to be able to address problems, limitations, or new chips. Under the current binding, a pll clock specifier of 2 means that the PLL is divided by 4 -- and the driver implements this, unless there happen to be four clock-output-names rather than 3, in which case it interprets it as PLL divided by 3. This does not appear in the binding documentation at all. That hack is now considered stable ABI. The current device tree nodes contain errors, such as saying that T1040 can set a core clock to PLL/4 when only PLL and PLL/2 are options. The current binding also ignores some restrictions on clock selection, such as p5020's requirement that if a core uses the "wrong" PLL, that PLL must be clocked lower than the "correct" PLL and be at most 80% of the rated CPU frequency. Possibly because of the lack of the ability to express such nuance in the binding, some valid options are omitted from the device trees, such as the ability on p4080 to run cores 0-3 from PLL3 and cores 4-7 from PLL1 (again, only if they are at most 80% of rated CPU frequency). This omission, combined with excessive caution in the cpufreq driver (addressed in a subsequent patch), means that currently on a 1500 MHz p4080 with typical PLL configuration, cpufreq can lower the frequency to 1200 MHz on half the CPUs and do nothing on the others. With this patchset, all CPUs can be lowered to 1200 MHz on a rev2 p4080, and on a rev3 p4080 half can be lowered to 750 MHz and the other half to 600 MHz. The current binding only deals with CPU clocks. To describe FMan in the device tree, we need to describe its clock. Some chips have additional muxes that work like the CPU muxes, but are not described in the device tree. Others require inspecting the Reset Control Word to determine which PLL is used. Rather than continue to extend this mess, replace it. Have the driver bind to the chip-specific clockgen compatible, and keep the detailed description of quirky chip variations in the driver, where it can be easily fixed, refactored, and extended. Older device trees will continue to work (including a workaround for old ls1021a device trees that are missing compatible and reg in the clockgen node, which even the old binding required). The pll/mux details in old device trees will be ignored, but "clocks" properties pointing at the old nodes will still work, and be directed at the corresponding new clock. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-20 04:29:54 +00:00
CLK_OF_DECLARE(qoriq_clockgen_1, "fsl,qoriq-clockgen-1.0", clockgen_init);
CLK_OF_DECLARE(qoriq_clockgen_2, "fsl,qoriq-clockgen-2.0", clockgen_init);
CLK_OF_DECLARE(qoriq_clockgen_ls1021a, "fsl,ls1021a-clockgen", clockgen_init);
clk: qoriq: Add ls2080a support. LS2080A is the first implementation of the chassis 3 clockgen, which has a different register layout than previous chips. It is also little endian, unlike previous chips. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-20 04:29:55 +00:00
CLK_OF_DECLARE(qoriq_clockgen_ls2080a, "fsl,ls2080a-clockgen", clockgen_init);
clk: qoriq: Move chip-specific knowledge into driver The device tree should describe the chips (or chip-like subblocks) in the system, but it generally does not describe individual registers -- it should identify, rather than describe, a programming interface. This has not been the case with the QorIQ clockgen nodes. The knowledge of what each bit setting of CLKCnCSR means is encoded in three places (binding, pll node, and mux node), and the last also needs to know which options are valid on a particular chip. All three of these locations are considered stable ABI, making it difficult to fix mistakes (of which I have found several), much less refactor the abstraction to be able to address problems, limitations, or new chips. Under the current binding, a pll clock specifier of 2 means that the PLL is divided by 4 -- and the driver implements this, unless there happen to be four clock-output-names rather than 3, in which case it interprets it as PLL divided by 3. This does not appear in the binding documentation at all. That hack is now considered stable ABI. The current device tree nodes contain errors, such as saying that T1040 can set a core clock to PLL/4 when only PLL and PLL/2 are options. The current binding also ignores some restrictions on clock selection, such as p5020's requirement that if a core uses the "wrong" PLL, that PLL must be clocked lower than the "correct" PLL and be at most 80% of the rated CPU frequency. Possibly because of the lack of the ability to express such nuance in the binding, some valid options are omitted from the device trees, such as the ability on p4080 to run cores 0-3 from PLL3 and cores 4-7 from PLL1 (again, only if they are at most 80% of rated CPU frequency). This omission, combined with excessive caution in the cpufreq driver (addressed in a subsequent patch), means that currently on a 1500 MHz p4080 with typical PLL configuration, cpufreq can lower the frequency to 1200 MHz on half the CPUs and do nothing on the others. With this patchset, all CPUs can be lowered to 1200 MHz on a rev2 p4080, and on a rev3 p4080 half can be lowered to 750 MHz and the other half to 600 MHz. The current binding only deals with CPU clocks. To describe FMan in the device tree, we need to describe its clock. Some chips have additional muxes that work like the CPU muxes, but are not described in the device tree. Others require inspecting the Reset Control Word to determine which PLL is used. Rather than continue to extend this mess, replace it. Have the driver bind to the chip-specific clockgen compatible, and keep the detailed description of quirky chip variations in the driver, where it can be easily fixed, refactored, and extended. Older device trees will continue to work (including a workaround for old ls1021a device trees that are missing compatible and reg in the clockgen node, which even the old binding required). The pll/mux details in old device trees will be ignored, but "clocks" properties pointing at the old nodes will still work, and be directed at the corresponding new clock. Signed-off-by: Scott Wood <scottwood@freescale.com> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
2015-09-20 04:29:54 +00:00
/* Legacy nodes */
clk: ppc-corenet: fix section mismatch warning In order to fix the following section mismatch warning: WARNING: drivers/clk/built-in.o(.data+0xe4): Section mismatch in reference from the variable ppc_corenet_clk_driver to the function .init.text:ppc_corenet_clk_probe() The variable ppc_corenet_clk_driver references the function __init ppc_corenet_clk_probe() If the reference is valid then annotate the variable with __init* or __refdata (see linux/init.h) or name the variable: *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console WARNING: drivers/clk/built-in.o(.data+0x10c): Section mismatch in reference from the variable ppc_corenet_clk_driver to the variable .init.rodata:ppc_clk_ids The variable ppc_corenet_clk_driver references the variable __initconst ppc_clk_ids If the reference is valid then annotate the variable with __init* or __refdata (see linux/init.h) or name the variable: *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console We can't just add the __init annotation to ppc_corenet_clk_driver or remove the __init from ppc_corenet_clk_probe() and ppc_clk_ids. So choose to use CLK_OF_DECLARE to scan and init the clock devices. Signed-off-by: Kevin Hao <haokexin@gmail.com> Acked-by: Scott Wood <scottwood@freescale.com> Acked-by: Michael Turquette <mturquette@linaro.org> Signed-off-by: Michael Turquette <mturquette@linaro.org>
2014-12-03 08:53:53 +00:00
CLK_OF_DECLARE(qoriq_sysclk_1, "fsl,qoriq-sysclk-1.0", sysclk_init);
CLK_OF_DECLARE(qoriq_sysclk_2, "fsl,qoriq-sysclk-2.0", sysclk_init);
CLK_OF_DECLARE(qoriq_core_pll_1, "fsl,qoriq-core-pll-1.0", core_pll_init);
CLK_OF_DECLARE(qoriq_core_pll_2, "fsl,qoriq-core-pll-2.0", core_pll_init);
CLK_OF_DECLARE(qoriq_core_mux_1, "fsl,qoriq-core-mux-1.0", core_mux_init);
CLK_OF_DECLARE(qoriq_core_mux_2, "fsl,qoriq-core-mux-2.0", core_mux_init);
clk: qoriq: Add support for the platform PLL Change-Id: Iac11ed95f274485a86d2c11f32a3dc502bcd020f Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com> Acked-by: Tang Yuantian <Yuantian.Tang@freescale.com> Signed-off-by: Michael Turquette <mturquette@linaro.org>
2015-01-21 10:03:31 +00:00
CLK_OF_DECLARE(qoriq_pltfrm_pll_1, "fsl,qoriq-platform-pll-1.0", pltfrm_pll_init);
CLK_OF_DECLARE(qoriq_pltfrm_pll_2, "fsl,qoriq-platform-pll-2.0", pltfrm_pll_init);
Reference in New Issue Copy Permalink