cpufreq: brcmstb-cpufreq: CPUfreq driver for older Broadcom STB SoCs
Subsystems (5)
v5 cover cpufreq: brcmstb-cpufreq: CPUfreq driver for older Broadcom STB SoCs
From: Markus Mayer <[email protected]>
This CPUfreq driver provides basic frequency scaling for older Broadcom STB SoCs that do not use AVS firmware with DVFS support. There is no support for voltage scaling.
v4 of this patch can be found at: https://patchwork.kernel.org/patch/9482357/
Changes since v4:
- Simplified (and hopefully clarified) binding document
- No code changes
v3 of this patch can be found at: https://lkml.org/lkml/2016/11/22/747
Changes since v3:
- added binding document
- got rid of calls to __clk_lookup(), using devm_clk_get() instead
- re-worked clock lookup code a bit, along with switching to devm_clk_get()
- get_frequencies() became a void function, removing the need for some error checking
- fixed CONFIG_ARM_BRCM_AVS_CPUFREQ typo
- fixed MODULE_DEVICE_TABLE declaration
Markus Mayer (2):
dt-bindings: brcm: clocks: add binding for brcmstb-cpu-clk-div
cpufreq: brcmstb-cpufreq: CPUfreq driver for older Broadcom STB SoCs
.../bindings/clock/brcm,brcmstb-cpu-clk-div.txt | 27 ++ MAINTAINERS | 1 + drivers/cpufreq/Kconfig.arm | 12 + drivers/cpufreq/Makefile | 1 + drivers/cpufreq/brcmstb-cpufreq.c | 377 +++++++++++++++++++++ 5 files changed, 418 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/brcm,brcmstb-cpu-clk-div.txt create mode 100644 drivers/cpufreq/brcmstb-cpufreq.c
Signature · 1 line
2.7.4
PATCH v5 1/2 dt-bindings: brcm: clocks: add binding for brcmstb-cpu-clk-div
From: Markus Mayer <[email protected]>
Add binding document for brcm,brcmstb-cpu-clk-div.
--- .../bindings/clock/brcm,brcmstb-cpu-clk-div.txt | 27 ++++++++++++++++++++++ MAINTAINERS | 1 + 2 files changed, 28 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/brcm,brcmstb-cpu-clk-div.txt
Documentation/devicetree/bindings/clock/brcm,brcmstb-cpu-clk-div.txt new file +27 -0
@@ -0,0 +1,27 @@ +The CPU divider node serves as the sole clock for the CPU complex. It supports +power-of-2 clock division, with a divider of "1" as the default highest-speed +setting. + +Required properties: +- compatible: shall be "brcm,brcmstb-cpu-clk-div" +- reg: address and width of the divider configuration register +- #clock-cells: shall be set to 0 +- clocks: phandle of clock provider which provides the source clock + (this would typically be a "fixed-clock" type PLL) +- div-table: list of (raw_value,divider) ordered pairs that correspond to the + allowed clock divider settings +- div-shift-width: least-significant bit position and width of divider value + +Optional properties: +- clock-names: the clock may be named + +Example: + cpuclkdiv: cpu-clk-div at f03e257c { + compatible = "brcm,brcmstb-cpu-clk-div"; + reg = <0xf03e257c 0x4>; + div-table = <0x00 1>; + div-shift-width = <0 5>; + #clock-cells = <0>; + clocks = <&cpupll>; + clock-names = "cpupll"; + };
MAINTAINERS +1 -0
@@ -2786,6 +2786,7 @@ M: bcm-kernel-feedback-list at broadcom.com L: linux-pm at vger.kernel.org S: Maintained F: Documentation/devicetree/bindings/cpufreq/brcm,stb-avs-cpu-freq.txt +F: Documentation/devicetree/bindings/clock/brcm,brcmstb-cpu-clk-div.txt F: drivers/cpufreq/brcmstb* BROADCOM SPECIFIC AMBA DRIVER (BCMA)
Signature · 1 line
2.7.4
Re: [PATCH v5 1/2] dt-bindings: brcm: clocks: add binding for brcmstb-cpu-clk-div
Quoted 9 lines · Markus Mayer
Documentation/devicetree/bindings/clock/brcm,brcmstb-cpu-clk-div.txt new file +3
-0@@ -0,0 +1,27 @@ +The CPU divider node serves as the sole clock for the CPU complex. It supports +power-of-2 clock division, with a divider of "1" as the default highest-speed +setting.
Documentation/devicetree/bindings/clock/brcm,brcmstb-cpu-clk-div.txt line 13
Quoted 10 lines
Documentation/devicetree/bindings/clock/brcm,brcmstb-cpu-clk-div.txt new file +10
-0+ +Required properties: +- compatible: shall be "brcm,brcmstb-cpu-clk-div" +- reg: address and width of the divider configuration register +- #clock-cells: shall be set to 0 +- clocks: phandle of clock provider which provides the source clock + (this would typically be a "fixed-clock" type PLL) +- div-table: list of (raw_value,divider) ordered pairs that correspond to the + allowed clock divider settings +- div-shift-width: least-significant bit position and width of divider value
Are these properties used? Please don't put these types of details in DT.
Documentation/devicetree/bindings/clock/brcm,brcmstb-cpu-clk-div.txt line 21
Quoted 8 lines
Documentation/devicetree/bindings/clock/brcm,brcmstb-cpu-clk-div.txt new file +8
-0+ +Optional properties: +- clock-names: the clock may be named + +Example: + cpuclkdiv: cpu-clk-div at f03e257c { + compatible = "brcm,brcmstb-cpu-clk-div"; + reg = <0xf03e257c 0x4>;
This register really looks like some offset in something larger. Is there some clock controller? What's the hw block at 0xf03e2000? Maybe I already asked this.
Quoted 7 lines
Documentation/devicetree/bindings/clock/brcm,brcmstb-cpu-clk-div.txt new file +6
-0+ div-table = <0x00 1>; + div-shift-width = <0 5>; + #clock-cells = <0>; + clocks = <&cpupll>; + clock-names = "cpupll"; + };
Signature · 2 lines
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH v5 1/2] dt-bindings: brcm: clocks: add binding for brcmstb-cpu-clk-div
Quoted 15 lines · Stephen Boyd
Quoted 14 lines · Markus Mayer
Documentation/devicetree/bindings/clock/brcm,brcmstb-cpu-clk-div.txt new file +8
-0@@ -0,0 +1,27 @@ +The CPU divider node serves as the sole clock for the CPU complex. It supports +power-of-2 clock division, with a divider of "1" as the default highest-speed +setting. + +Required properties: +- compatible: shall be "brcm,brcmstb-cpu-clk-div" +- reg: address and width of the divider configuration register +- #clock-cells: shall be set to 0
Quoted 8 lines
Documentation/devicetree/bindings/clock/brcm,brcmstb-cpu-clk-div.txt line 13
Quoted 5 lines
Documentation/devicetree/bindings/clock/brcm,brcmstb-cpu-clk-div.txt new file +5
-0+- clocks: phandle of clock provider which provides the source clock + (this would typically be a "fixed-clock" type PLL) +- div-table: list of (raw_value,divider) ordered pairs that correspond to the + allowed clock divider settings +- div-shift-width: least-significant bit position and width of divider valueAre these properties used? Please don't put these types of details in DT.
Yeah, unfortunately they are. Luckily, I think the issue can be resolved quite easily, because the user of those properties isn't involved in this series.
They are currently being used by a clock driver ("drivers/clk/clk-brcmstb.c") that hasn't been upstreamed yet. I performed some code archeology. While I wasn't 100% successful in tracking down the origins of this interface, it looks like it was designed this way a while back (4+ years or so), probably before device tree best practices were developed or, at least, before they were widely known.
So, what I can do is to remove the properties from the official binding. (I'll send an update to that effect shortly.) Once the binding is accepted upstream, we can work on fixing up the design of clk-brcmstb.c, so it doesn't rely on these properties anymore (and derives them from the compatible string instead), and then proceed to upstream that, as well.
I don't think this approach would cause any conflicts or problems.
Quoted 4 lines
Quoted 4 lines
Documentation/devicetree/bindings/clock/brcm,brcmstb-cpu-clk-div.txt new file +4
-0+ +Optional properties: +- clock-names: the clock may be named +
Quoted 8 lines
Documentation/devicetree/bindings/clock/brcm,brcmstb-cpu-clk-div.txt line 21
Quoted 4 lines
Documentation/devicetree/bindings/clock/brcm,brcmstb-cpu-clk-div.txt new file +4
-0+Example: + cpuclkdiv: cpu-clk-div at f03e257c { + compatible = "brcm,brcmstb-cpu-clk-div"; + reg = <0xf03e257c 0x4>;This register really looks like some offset in something larger. Is there some clock controller? What's the hw block at
0xf03e2000? Maybe I already asked this.
It looks this way, but in this case, looks are deceiving. The address and the length are really correct the way they are.
This memory area holds a range of only loosely related configuration registers. It's called the Bus Interface Unit Register Set and deals with configuring the CPU in general. At address 0xf03e257c, there happens to be the clock divider register we need, and it's really just one register, i.e. 4 bytes.
Quoted 11 lines
Documentation/devicetree/bindings/clock/brcm,brcmstb-cpu-clk-div.txt line 27
Quoted 7 lines
Documentation/devicetree/bindings/clock/brcm,brcmstb-cpu-clk-div.txt new file +6
-0+ div-table = <0x00 1>; + div-shift-width = <0 5>; + #clock-cells = <0>; + clocks = <&cpupll>; + clock-names = "cpupll"; + };--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH v5 1/2] dt-bindings: brcm: clocks: add binding for brcmstb-cpu-clk-div
Quoted 17 lines · Markus Mayer
Quoted 3 lines · Stephen Boyd
Are these properties used? Please don't put these types of details in DT.
Yeah, unfortunately they are. Luckily, I think the issue can be resolved quite easily, because the user of those properties isn't involved in this series.
They are currently being used by a clock driver ("
drivers/clk/clk-brcmstb.c") that hasn't been upstreamed yet. I performed some code archeology. While I wasn't 100% successful in tracking down the origins of this interface, it looks like it was designed this way a while back (4+ years or so), probably before device tree best practices were developed or, at least, before they were widely known.
Quoted 6 lines
So, what I can do is to remove the properties from the official binding. (I'll send an update to that effect shortly.) Once the binding is accepted upstream, we can work on fixing up the design of
clk-brcmstb.c, so it doesn't rely on these properties anymore (and derives them from the compatible string instead), and then proceed to upstream that, as well.
Ok. Sounds like some cleanup needs to be done on the way upstream.
Quoted 4 lines
Quoted 3 lines
This register really looks like some offset in something larger. Is there some clock controller? What's the hw block at
0xf03e2000? Maybe I already asked this.
Quoted 8 lines
It looks this way, but in this case, looks are deceiving. The address and the length are really correct the way they are.
This memory area holds a range of only loosely related configuration registers. It's called the Bus Interface Unit Register Set and deals with configuring the CPU in general. At address
0xf03e257c, there happens to be the clock divider register we need, and it's really just one register, i.e. 4 bytes.
We've seen this style of hardware design before. I'd prefer we make the "Bus Interface Unit Register Set" into one device node and have a driver probe for it that registers this clock. If other things need to be controlled in there then the driver will do more than just register one clock, possibly hooking into multiple frameworks. The compatible string can indicate which SoC it is if the divider register offset changes or if the register layout is a total free for all.
Either way, having reg properties end in non-zero values is suspect on ARM systems because a device is usually aligned to at least a 1k boundary for proper CPU addressing and mapping of the device. We can't possibly make a smaller mapping than a page anyway, so the registers around this one register will need to be mapped with the same attributes, hence the desire to make one device for the hardware block.
Signature · 2 lines
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH v5 1/2] dt-bindings: brcm: clocks: add binding for brcmstb-cpu-clk-div
Quoted 41 lines · Stephen Boyd
Quoted 17 lines · Markus Mayer
Quoted 3 lines · Stephen Boyd
Are these properties used? Please don't put these types of details in DT.
Yeah, unfortunately they are. Luckily, I think the issue can be resolved quite easily, because the user of those properties isn't involved in this series.
They are currently being used by a clock driver ("
drivers/clk/clk-brcmstb.c") that hasn't been upstreamed yet. I performed some code archeology. While I wasn't 100% successful in tracking down the origins of this interface, it looks like it was designed this way a while back (4+ years or so), probably before device tree best practices were developed or, at least, before they were widely known.Quoted 6 lines
So, what I can do is to remove the properties from the official binding. (I'll send an update to that effect shortly.) Once the binding is accepted upstream, we can work on fixing up the design of
clk-brcmstb.c, so it doesn't rely on these properties anymore (and derives them from the compatible string instead), and then proceed to upstream that, as well.Ok. Sounds like some cleanup needs to be done on the way upstream.
Quoted 4 lines
Quoted 3 lines
This register really looks like some offset in something larger. Is there some clock controller? What's the hw block at
0xf03e2000? Maybe I already asked this.Quoted 8 lines
It looks this way, but in this case, looks are deceiving. The address and the length are really correct the way they are.
This memory area holds a range of only loosely related configuration registers. It's called the Bus Interface Unit Register Set and deals with configuring the CPU in general. At address
0xf03e257c, there happens to be the clock divider register we need, and it's really just one register, i.e. 4 bytes.
Quoted 8 lines
We've seen this style of hardware design before. I'd prefer we make the "Bus Interface Unit Register Set" into one device node and have a driver probe for it that registers this clock. If other things need to be controlled in there then the driver will do more than just register one clock, possibly hooking into multiple frameworks. The compatible string can indicate which SoC it is if the divider register offset changes or if the register layout is a total free for all.
We already have another piece of drive code that manipulates registers in the Bus Interface Unit located in drivers/soc/bcm/brcmstb/biuctrl.c and which has little to nothing to do with the CPU's clock ratio. And actually another one being submitted that deals with the CPU's read-ahead cache. I would very much prefer we keep all of them separate and dealing with just the register offset they need to do, but that does not mean the Device Tree binding has to look that way though.
The binding for the BIUCTRL register made it here:
Documentation/devicetree/bindings/arm/bcm/brcm,brcmstb.txt
so we should re-use that, and have a small piece of clock provided that just uses the relevant register range within that larger register space and provide the CLOCK_RATIO. Does that work?
Quoted 8 lines
Either way, having reg properties end in non-zero values is suspect on ARM systems because a device is usually aligned to at least a 1k boundary for proper CPU addressing and mapping of the device. We can't possibly make a smaller mapping than a page anyway, so the registers around this one register will need to be mapped with the same attributes, hence the desire to make one device for the hardware block.
Yes that's absolutely valid, but this is not really a problem, since ioremap() is smart enough to re-use existing mappings (or AFAIR).
Signature · 1 line
Florian
Re: [PATCH v5 1/2] dt-bindings: brcm: clocks: add binding for brcmstb-cpu-clk-div
Quoted 59 lines · Florian Fainelli
Quoted 41 lines · Stephen Boyd
Quoted 17 lines · Markus Mayer
Quoted 3 lines · Stephen Boyd
Are these properties used? Please don't put these types of details in DT.
Yeah, unfortunately they are. Luckily, I think the issue can be resolved quite easily, because the user of those properties isn't involved in this series.
They are currently being used by a clock driver ("
drivers/clk/clk-brcmstb.c") that hasn't been upstreamed yet. I performed some code archeology. While I wasn't 100% successful in tracking down the origins of this interface, it looks like it was designed this way a while back (4+ years or so), probably before device tree best practices were developed or, at least, before they were widely known.Quoted 6 lines
So, what I can do is to remove the properties from the official binding. (I'll send an update to that effect shortly.) Once the binding is accepted upstream, we can work on fixing up the design of
clk-brcmstb.c, so it doesn't rely on these properties anymore (and derives them from the compatible string instead), and then proceed to upstream that, as well.Ok. Sounds like some cleanup needs to be done on the way upstream.
Quoted 4 lines
Quoted 3 lines
This register really looks like some offset in something larger. Is there some clock controller? What's the hw block at
0xf03e2000? Maybe I already asked this.Quoted 8 lines
It looks this way, but in this case, looks are deceiving. The address and the length are really correct the way they are.
This memory area holds a range of only loosely related configuration registers. It's called the Bus Interface Unit Register Set and deals with configuring the CPU in general. At address
0xf03e257c, there happens to be the clock divider register we need, and it's really just one register, i.e. 4 bytes.Quoted 8 lines
We've seen this style of hardware design before. I'd prefer we make the "Bus Interface Unit Register Set" into one device node and have a driver probe for it that registers this clock. If other things need to be controlled in there then the driver will do more than just register one clock, possibly hooking into multiple frameworks. The compatible string can indicate which SoC it is if the divider register offset changes or if the register layout is a total free for all.
We already have another piece of drive code that manipulates registers in the Bus Interface Unit located in
drivers/soc/bcm/brcmstb/biuctrl.cand which has little to nothing to do with the CPU's clock ratio. And actually another one being submitted that deals with the CPU's read-ahead cache. I would very much prefer we keep all of them separate and dealing with just the register offset they need to do, but that does not mean the Device Tree binding has to look that way though.
Quoted 8 lines
The binding for the BIUCTRL register made it here:
Documentation/devicetree/bindings/arm/bcm/brcm,brcmstb.txtso we should re-use that, and have a small piece of clock provided that just uses the relevant register range within that larger register space and provide the
CLOCK_RATIO. Does that work?
Ok. That's fine. The existing binding will be updated to include this new subnode then for the clock component?
Signature · 2 lines
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Florian Fainelli
maintainerRe: [PATCH v5 1/2] dt-bindings: brcm: clocks: add binding for brcmstb-cpu-clk-div
Quoted 64 lines · Stephen Boyd
Quoted 63 lines · Florian Fainelli
Quoted 41 lines · Stephen Boyd
Quoted 17 lines · Markus Mayer
Quoted 3 lines · Stephen Boyd
Are these properties used? Please don't put these types of details in DT.
Yeah, unfortunately they are. Luckily, I think the issue can be resolved quite easily, because the user of those properties isn't involved in this series.
They are currently being used by a clock driver ("
drivers/clk/clk-brcmstb.c") that hasn't been upstreamed yet. I performed some code archeology. While I wasn't 100% successful in tracking down the origins of this interface, it looks like it was designed this way a while back (4+ years or so), probably before device tree best practices were developed or, at least, before they were widely known.Quoted 6 lines
So, what I can do is to remove the properties from the official binding. (I'll send an update to that effect shortly.) Once the binding is accepted upstream, we can work on fixing up the design of
clk-brcmstb.c, so it doesn't rely on these properties anymore (and derives them from the compatible string instead), and then proceed to upstream that, as well.Ok. Sounds like some cleanup needs to be done on the way upstream.
Quoted 4 lines
Quoted 3 lines
This register really looks like some offset in something larger. Is there some clock controller? What's the hw block at
0xf03e2000? Maybe I already asked this.Quoted 8 lines
It looks this way, but in this case, looks are deceiving. The address and the length are really correct the way they are.
This memory area holds a range of only loosely related configuration registers. It's called the Bus Interface Unit Register Set and deals with configuring the CPU in general. At address
0xf03e257c, there happens to be the clock divider register we need, and it's really just one register, i.e. 4 bytes.Quoted 8 lines
We've seen this style of hardware design before. I'd prefer we make the "Bus Interface Unit Register Set" into one device node and have a driver probe for it that registers this clock. If other things need to be controlled in there then the driver will do more than just register one clock, possibly hooking into multiple frameworks. The compatible string can indicate which SoC it is if the divider register offset changes or if the register layout is a total free for all.
We already have another piece of drive code that manipulates registers in the Bus Interface Unit located in
drivers/soc/bcm/brcmstb/biuctrl.cand which has little to nothing to do with the CPU's clock ratio. And actually another one being submitted that deals with the CPU's read-ahead cache. I would very much prefer we keep all of them separate and dealing with just the register offset they need to do, but that does not mean the Device Tree binding has to look that way though.The binding for the BIUCTRL register made it here:
Documentation/devicetree/bindings/arm/bcm/brcm,brcmstb.txt
Quoted 7 lines
Quoted 4 lines
so we should re-use that, and have a small piece of clock provided that just uses the relevant register range within that larger register space and provide the
CLOCK_RATIO. Does that work?Ok. That's fine. The existing binding will be updated to include this new subnode then for the clock component?
Humm, I suppose we could do that yes, my original thought was to just have this CPU clock provider remap the entire BIUCTRL register range (of_iomap() etc.) and manipulate just the relevant register range of interest (CPU_CLOCK_CONFIG_REG), but if you want a sub-node to appear, we could probably do that as well.
Signature · 1 line
Florian
Re: [PATCH v5 1/2] dt-bindings: brcm: clocks: add binding for brcmstb-cpu-clk-div
Quoted 20 lines · Florian Fainelli
Quoted 19 lines · Stephen Boyd
Quoted 17 lines · Florian Fainelli
We already have another piece of drive code that manipulates registers in the Bus Interface Unit located in
drivers/soc/bcm/brcmstb/biuctrl.cand which has little to nothing to do with the CPU's clock ratio. And actually another one being submitted that deals with the CPU's read-ahead cache. I would very much prefer we keep all of them separate and dealing with just the register offset they need to do, but that does not mean the Device Tree binding has to look that way though.The binding for the BIUCTRL register made it here:
Documentation/devicetree/bindings/arm/bcm/brcm,brcmstb.txtso we should re-use that, and have a small piece of clock provided that just uses the relevant register range within that larger register space and provide the
CLOCK_RATIO. Does that work?
Quoted 8 lines
Quoted 2 lines
Ok. That's fine. The existing binding will be updated to include this new subnode then for the clock component?
Humm, I suppose we could do that yes, my original thought was to just have this CPU clock provider remap the entire BIUCTRL register range (
of_iomap()etc.) and manipulate just the relevant register range of interest (CPU_CLOCK_CONFIG_REG), but if you want a sub-node to appear, we could probably do that as well.
One node is fine as well. I thought the plan was many subnodes based on the binding document you mentioned earlier.
Signature · 2 lines
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Rob Herring
maintainerRe: [PATCH v5 1/2] dt-bindings: brcm: clocks: add binding for brcmstb-cpu-clk-div
In reply to Markus MayerQuoted 19 lines · Markus Mayer
From: Markus Mayer <[email protected]>
Add binding document for brcm,brcmstb-cpu-clk-div.
Signed-off-by Markus Mayer <[email protected]>--- .../bindings/clock/brcm,brcmstb-cpu-clk-div.txt | 27 ++++++++++++++++++++++ MAINTAINERS | 1 + 2 files changed, 28 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/brcm,brcmstb-cpu-clk-div.txtDocumentation/devicetree/bindings/clock/brcm,brcmstb-cpu-clk-div.txt new file +2
-0@@ -0,0 +1,27 @@ +The CPU divider node serves as the sole clock for the CPU complex. It supports +power-of-2 clock division, with a divider of "1" as the default highest-speed
Documentation/devicetree/bindings/clock/brcm,brcmstb-cpu-clk-div.txt line 12
Quoted 10 lines
Documentation/devicetree/bindings/clock/brcm,brcmstb-cpu-clk-div.txt new file +10
-0+setting. + +Required properties: +- compatible: shall be "brcm,brcmstb-cpu-clk-div" +- reg: address and width of the divider configuration register +- #clock-cells: shall be set to 0 +- clocks: phandle of clock provider which provides the source clock + (this would typically be a "fixed-clock" type PLL) +- div-table: list of (raw_value,divider) ordered pairs that correspond to the + allowed clock divider settings
Why do you need 2 values? Can't you use the index or calculate the register value from the divider value?
Documentation/devicetree/bindings/clock/brcm,brcmstb-cpu-clk-div.txt line 19
Quoted 7 lines
Documentation/devicetree/bindings/clock/brcm,brcmstb-cpu-clk-div.txt new file +7
-0+- div-shift-width: least-significant bit position and width of divider value + +Optional properties: +- clock-names: the clock may be named + +Example: + cpuclkdiv: cpu-clk-div at f03e257c {
clock-controller at ...
Quoted 23 lines
Documentation/devicetree/bindings/clock/brcm,brcmstb-cpu-clk-div.txt new file +8
-0+ compatible = "brcm,brcmstb-cpu-clk-div"; + reg = <0xf03e257c 0x4>; + div-table = <0x00 1>; + div-shift-width = <0 5>; + #clock-cells = <0>; + clocks = <&cpupll>; + clock-names = "cpupll"; + };MAINTAINERS +1
-0@@ -2786,6 +2786,7 @@ M: bcm-kernel-feedback-list at broadcom.com L: linux-pm at vger.kernel.org S: Maintained F: Documentation/devicetree/bindings/cpufreq/brcm,stb-avs-cpu-freq.txt +F: Documentation/devicetree/bindings/clock/brcm,brcmstb-cpu-clk-div.txt F: drivers/cpufreq/brcmstb* BROADCOM SPECIFIC AMBA DRIVER (BCMA)Signature · 1 line
2.7.4
PATCH v5 2/2 cpufreq: brcmstb-cpufreq: CPUfreq driver for older Broadcom STB SoCs
In reply to Markus MayerFrom: Markus Mayer <[email protected]>
This CPUfreq driver provides basic frequency scaling for older Broadcom STB SoCs that do not use AVS firmware with DVFS support. There is no support for voltage scaling.
--- drivers/cpufreq/Kconfig.arm | 12 ++ drivers/cpufreq/Makefile | 1 + drivers/cpufreq/brcmstb-cpufreq.c | 377 ++++++++++++++++++++++++++++++++++++++ 3 files changed, 390 insertions(+) create mode 100644 drivers/cpufreq/brcmstb-cpufreq.c
drivers/cpufreq/Kconfig.arm +12 -0
@@ -33,6 +33,18 @@ config ARM_BRCMSTB_AVS_CPUFREQ_DEBUG If in doubt, say N. +config ARM_BRCMSTB_CPUFREQ + tristate "Broadcom STB CPUfreq driver" + depends on ARCH_BRCMSTB || COMPILE_TEST + default y + help + Some Broadcom SoCs offer multiple operating frequencies that CPUfreq + can take advantage of to improve energy efficiency. + + Say Y, if you have a supported Broadcom SoC. If your Broadcom SoC + has AVS firmware with support for frequency and voltage scaling, + say N here and enable ARM_BRCMSTB_AVS_CPUFREQ instead. + config ARM_DT_BL_CPUFREQ tristate "Generic probing via DT for ARM big LITTLE CPUfreq driver" depends on ARM_BIG_LITTLE_CPUFREQ && OF
drivers/cpufreq/Makefile +1 -0
@@ -52,6 +52,7 @@ obj-$(CONFIG_ARM_BIG_LITTLE_CPUFREQ) += arm_big_little.o obj-$(CONFIG_ARM_DT_BL_CPUFREQ) += arm_big_little_dt.o obj-$(CONFIG_ARM_BRCMSTB_AVS_CPUFREQ) += brcmstb-avs-cpufreq.o +obj-$(CONFIG_ARM_BRCMSTB_CPUFREQ) += brcmstb-cpufreq.o obj-$(CONFIG_ARCH_DAVINCI) += davinci-cpufreq.o obj-$(CONFIG_UX500_SOC_DB8500) += dbx500-cpufreq.o obj-$(CONFIG_ARM_EXYNOS5440_CPUFREQ) += exynos5440-cpufreq.o
drivers/cpufreq/brcmstb-cpufreq.c new file +377 -0
377 lines not on this page · raw message
Signature · 1 line
2.7.4