2015-01-15 14:03:41 +08:00
|
|
|
* Clock Block on Freescale QorIQ Platforms
|
2014-01-13 16:16:35 +08: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 12:29:54 +08:00
|
|
|
Freescale QorIQ chips take primary clocking input from the external
|
2014-01-13 16:16:35 +08:00
|
|
|
SYSCLK signal. The SYSCLK input (frequency) is multiplied using
|
|
|
|
|
multiple phase locked loops (PLL) to create a variety of frequencies
|
|
|
|
|
which can then be passed to a variety of internal logic, including
|
|
|
|
|
cores and peripheral IP blocks.
|
|
|
|
|
Please refer to the Reference Manual for details.
|
|
|
|
|
|
2014-05-08 11:12:10 +08:00
|
|
|
All references to "1.0" and "2.0" refer to the QorIQ chassis version to
|
|
|
|
|
which the chip complies.
|
|
|
|
|
|
|
|
|
|
Chassis Version Example Chips
|
|
|
|
|
--------------- -------------
|
|
|
|
|
1.0 p4080, p5020, p5040
|
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 12:29:54 +08:00
|
|
|
2.0 t4240, b4860
|
2014-05-08 11:12:10 +08:00
|
|
|
|
2014-01-13 16:16:35 +08:00
|
|
|
1. Clock Block Binding
|
|
|
|
|
|
|
|
|
|
Required properties:
|
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 12:29:54 +08:00
|
|
|
- compatible: Should contain a chip-specific clock block compatible
|
|
|
|
|
string and (if applicable) may contain a chassis-version clock
|
|
|
|
|
compatible string.
|
|
|
|
|
|
|
|
|
|
Chip-specific strings are of the form "fsl,<chip>-clockgen", such as:
|
2014-01-13 16:16:35 +08:00
|
|
|
* "fsl,p2041-clockgen"
|
|
|
|
|
* "fsl,p3041-clockgen"
|
|
|
|
|
* "fsl,p4080-clockgen"
|
|
|
|
|
* "fsl,p5020-clockgen"
|
|
|
|
|
* "fsl,p5040-clockgen"
|
|
|
|
|
* "fsl,t4240-clockgen"
|
|
|
|
|
* "fsl,b4420-clockgen"
|
|
|
|
|
* "fsl,b4860-clockgen"
|
2016-11-10 02:10:53 +08:00
|
|
|
* "fsl,ls1012a-clockgen"
|
2015-01-15 14:03:41 +08:00
|
|
|
* "fsl,ls1021a-clockgen"
|
2016-09-13 16:09:57 +08:00
|
|
|
* "fsl,ls1043a-clockgen"
|
|
|
|
|
* "fsl,ls1046a-clockgen"
|
2017-02-09 19:03:49 +08:00
|
|
|
* "fsl,ls1088a-clockgen"
|
2016-09-13 16:09:57 +08:00
|
|
|
* "fsl,ls2080a-clockgen"
|
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 12:29:54 +08:00
|
|
|
Chassis-version clock strings include:
|
2014-01-13 16:16:35 +08:00
|
|
|
* "fsl,qoriq-clockgen-1.0": for chassis 1.0 clocks
|
|
|
|
|
* "fsl,qoriq-clockgen-2.0": for chassis 2.0 clocks
|
|
|
|
|
- reg: Describes the address of the device's resources within the
|
|
|
|
|
address space defined by its parent bus, and resource zero
|
|
|
|
|
represents the clock register set
|
|
|
|
|
|
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 12:29:54 +08:00
|
|
|
Optional properties:
|
2014-01-13 16:16:35 +08:00
|
|
|
- ranges: Allows valid translation between child's address space and
|
|
|
|
|
parent's. Must be present if the device has sub-nodes.
|
|
|
|
|
- #address-cells: Specifies the number of cells used to represent
|
|
|
|
|
physical base addresses. Must be present if the device has
|
|
|
|
|
sub-nodes and set to 1 if present
|
|
|
|
|
- #size-cells: Specifies the number of cells used to represent
|
|
|
|
|
the size of an address. Must be present if the device has
|
|
|
|
|
sub-nodes and set to 1 if present
|
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 12:29:54 +08:00
|
|
|
- clock-frequency: Input system clock frequency (SYSCLK)
|
|
|
|
|
- clocks: If clock-frequency is not specified, sysclk may be provided
|
|
|
|
|
as an input clock. Either clock-frequency or clocks must be
|
|
|
|
|
provided.
|
2017-03-20 10:37:22 +08:00
|
|
|
A second input clock, called "coreclk", may be provided if
|
|
|
|
|
core PLLs are based on a different input clock from the
|
|
|
|
|
platform PLL.
|
|
|
|
|
- clock-names: Required if a coreclk is present. Valid names are
|
|
|
|
|
"sysclk" and "coreclk".
|
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 12:29:54 +08:00
|
|
|
|
|
|
|
|
2. Clock Provider
|
|
|
|
|
|
|
|
|
|
The clockgen node should act as a clock provider, though in older device
|
|
|
|
|
trees the children of the clockgen node are the clock providers.
|
|
|
|
|
|
|
|
|
|
When the clockgen node is a clock provider, #clock-cells = <2>.
|
|
|
|
|
The first cell of the clock specifier is the clock type, and the
|
|
|
|
|
second cell is the clock index for the specified type.
|
|
|
|
|
|
|
|
|
|
Type# Name Index Cell
|
|
|
|
|
0 sysclk must be 0
|
|
|
|
|
1 cmux index (n in CLKCnCSR)
|
|
|
|
|
2 hwaccel index (n in CLKCGnHWACSR)
|
|
|
|
|
3 fman 0 for fm1, 1 for fm2
|
|
|
|
|
4 platform pll 0=pll, 1=pll/2, 2=pll/3, 3=pll/4
|
2017-11-22 09:40:53 +08:00
|
|
|
4=pll/5, 5=pll/6, 6=pll/7, 7=pll/8
|
2017-03-20 10:37:22 +08:00
|
|
|
5 coreclk must be 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 12:29:54 +08:00
|
|
|
|
|
|
|
|
3. Example
|
|
|
|
|
|
|
|
|
|
clockgen: global-utilities@e1000 {
|
|
|
|
|
compatible = "fsl,p5020-clockgen", "fsl,qoriq-clockgen-1.0";
|
|
|
|
|
clock-frequency = <133333333>;
|
|
|
|
|
reg = <0xe1000 0x1000>;
|
|
|
|
|
#clock-cells = <2>;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
fman@400000 {
|
|
|
|
|
...
|
|
|
|
|
clocks = <&clockgen 3 0>;
|
|
|
|
|
...
|
|
|
|
|
};
|
|
|
|
|
}
|
|
|
|
|
4. Legacy Child Nodes
|
2014-01-13 16:16:35 +08: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 12:29:54 +08:00
|
|
|
NOTE: These nodes are deprecated. Kernels should continue to support
|
|
|
|
|
device trees with these nodes, but new device trees should not use them.
|
2014-01-13 16:16:35 +08:00
|
|
|
|
|
|
|
|
Most of the bindings are from the common clock binding[1].
|
|
|
|
|
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
|
|
|
|
|
|
|
|
|
|
Required properties:
|
|
|
|
|
- compatible : Should include one of the following:
|
|
|
|
|
* "fsl,qoriq-core-pll-1.0" for core PLL clocks (v1.0)
|
|
|
|
|
* "fsl,qoriq-core-pll-2.0" for core PLL clocks (v2.0)
|
|
|
|
|
* "fsl,qoriq-core-mux-1.0" for core mux clocks (v1.0)
|
|
|
|
|
* "fsl,qoriq-core-mux-2.0" for core mux clocks (v2.0)
|
|
|
|
|
* "fsl,qoriq-sysclk-1.0": for input system clock (v1.0).
|
|
|
|
|
It takes parent's clock-frequency as its clock.
|
|
|
|
|
* "fsl,qoriq-sysclk-2.0": for input system clock (v2.0).
|
|
|
|
|
It takes parent's clock-frequency as its clock.
|
2014-11-06 23:48:12 +08:00
|
|
|
* "fsl,qoriq-platform-pll-1.0" for the platform PLL clock (v1.0)
|
|
|
|
|
* "fsl,qoriq-platform-pll-2.0" for the platform PLL clock (v2.0)
|
2014-01-13 16:16:35 +08:00
|
|
|
- #clock-cells: From common clock binding. The number of cells in a
|
|
|
|
|
clock-specifier. Should be <0> for "fsl,qoriq-sysclk-[1,2].0"
|
|
|
|
|
clocks, or <1> for "fsl,qoriq-core-pll-[1,2].0" clocks.
|
|
|
|
|
For "fsl,qoriq-core-pll-[1,2].0" clocks, the single
|
|
|
|
|
clock-specifier cell may take the following values:
|
|
|
|
|
* 0 - equal to the PLL frequency
|
|
|
|
|
* 1 - equal to the PLL frequency divided by 2
|
|
|
|
|
* 2 - equal to the PLL frequency divided by 4
|
|
|
|
|
|
|
|
|
|
Recommended properties:
|
|
|
|
|
- clocks: Should be the phandle of input parent clock
|
|
|
|
|
- clock-names: From common clock binding, indicates the clock name
|
|
|
|
|
- clock-output-names: From common clock binding, indicates the names of
|
|
|
|
|
output clocks
|
|
|
|
|
- reg: Should be the offset and length of clock block base address.
|
|
|
|
|
The length should be 4.
|
|
|
|
|
|
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 12:29:54 +08:00
|
|
|
Legacy Example:
|
2014-01-13 16:16:35 +08:00
|
|
|
/ {
|
|
|
|
|
clockgen: global-utilities@e1000 {
|
|
|
|
|
compatible = "fsl,p5020-clockgen", "fsl,qoriq-clockgen-1.0";
|
|
|
|
|
ranges = <0x0 0xe1000 0x1000>;
|
|
|
|
|
clock-frequency = <133333333>;
|
|
|
|
|
reg = <0xe1000 0x1000>;
|
|
|
|
|
#address-cells = <1>;
|
|
|
|
|
#size-cells = <1>;
|
|
|
|
|
|
|
|
|
|
sysclk: sysclk {
|
|
|
|
|
#clock-cells = <0>;
|
|
|
|
|
compatible = "fsl,qoriq-sysclk-1.0";
|
|
|
|
|
clock-output-names = "sysclk";
|
2014-05-08 11:12:10 +08:00
|
|
|
};
|
2014-01-13 16:16:35 +08:00
|
|
|
|
|
|
|
|
pll0: pll0@800 {
|
|
|
|
|
#clock-cells = <1>;
|
|
|
|
|
reg = <0x800 0x4>;
|
|
|
|
|
compatible = "fsl,qoriq-core-pll-1.0";
|
|
|
|
|
clocks = <&sysclk>;
|
|
|
|
|
clock-output-names = "pll0", "pll0-div2";
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
pll1: pll1@820 {
|
|
|
|
|
#clock-cells = <1>;
|
|
|
|
|
reg = <0x820 0x4>;
|
|
|
|
|
compatible = "fsl,qoriq-core-pll-1.0";
|
|
|
|
|
clocks = <&sysclk>;
|
|
|
|
|
clock-output-names = "pll1", "pll1-div2";
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
mux0: mux0@0 {
|
|
|
|
|
#clock-cells = <0>;
|
|
|
|
|
reg = <0x0 0x4>;
|
|
|
|
|
compatible = "fsl,qoriq-core-mux-1.0";
|
|
|
|
|
clocks = <&pll0 0>, <&pll0 1>, <&pll1 0>, <&pll1 1>;
|
|
|
|
|
clock-names = "pll0", "pll0-div2", "pll1", "pll1-div2";
|
|
|
|
|
clock-output-names = "cmux0";
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
mux1: mux1@20 {
|
|
|
|
|
#clock-cells = <0>;
|
|
|
|
|
reg = <0x20 0x4>;
|
|
|
|
|
compatible = "fsl,qoriq-core-mux-1.0";
|
|
|
|
|
clocks = <&pll0 0>, <&pll0 1>, <&pll1 0>, <&pll1 1>;
|
|
|
|
|
clock-names = "pll0", "pll0-div2", "pll1", "pll1-div2";
|
|
|
|
|
clock-output-names = "cmux1";
|
|
|
|
|
};
|
2014-11-06 23:48:12 +08:00
|
|
|
|
|
|
|
|
platform-pll: platform-pll@c00 {
|
|
|
|
|
#clock-cells = <1>;
|
|
|
|
|
reg = <0xc00 0x4>;
|
|
|
|
|
compatible = "fsl,qoriq-platform-pll-1.0";
|
|
|
|
|
clocks = <&sysclk>;
|
|
|
|
|
clock-output-names = "platform-pll", "platform-pll-div2";
|
|
|
|
|
};
|
2014-01-13 16:16:35 +08:00
|
|
|
};
|
2014-11-06 23:48:12 +08:00
|
|
|
};
|
2014-01-13 16:16:35 +08: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 12:29:54 +08:00
|
|
|
Example for legacy clock consumer:
|
2014-01-13 16:16:35 +08:00
|
|
|
|
|
|
|
|
/ {
|
|
|
|
|
cpu0: PowerPC,e5500@0 {
|
|
|
|
|
...
|
|
|
|
|
clocks = <&mux0>;
|
|
|
|
|
...
|
|
|
|
|
};
|
2014-11-06 23:48:12 +08:00
|
|
|
};
|