summaryrefslogtreecommitdiffstats
path: root/drivers/pwm
diff options
context:
space:
mode:
authorEric Anholt <eric@anholt.net>2015-10-08 18:37:24 -0700
committerStephen Boyd <sboyd@codeaurora.org>2015-10-12 11:32:02 -0700
commit41691b8862e2a32080306f17a723efc4b6ca86ab (patch)
tree56082eb8f81ec0b5d28dc2314a996e0b5820ac12 /drivers/pwm
parent2c74b5399de730e3155dc3d5a8ad041fba5e93f4 (diff)
downloadlinux-stable-41691b8862e2a32080306f17a723efc4b6ca86ab.tar.gz
linux-stable-41691b8862e2a32080306f17a723efc4b6ca86ab.tar.bz2
linux-stable-41691b8862e2a32080306f17a723efc4b6ca86ab.zip
clk: bcm2835: Add support for programming the audio domain clocks
This adds support for enabling, disabling, and setting the rate of the audio domain clocks. It will be necessary for setting the pixel clock for HDMI in the VC4 driver and let us write a cpufreq driver. It will also improve compatibility with user changes to the firmware's config.txt, since our previous fixed clocks are unaware of it. The firmware also has support for configuring the clocks through the mailbox channel, but the pixel clock setup by the firmware doesn't work, and it's Raspberry Pi specific anyway. The only conflicts we should have with the firmware would be if we made firmware calls that result in clock management (like opening firmware V3D or ISP access, which we don't support in upstream), or on hardware over-thermal or under-voltage (when the firmware would rewrite PLLB to take the ARM out of overclock). If that happens, our cached .recalc_rate() results would be incorrect, but that's no worse than our current state where we used fixed clocks. The existing fixed clocks in the code are left in place to provide backwards compatibility with old device tree files. Signed-off-by: Eric Anholt <eric@anholt.net> Tested-by: Martin Sperl <kernel@martin.sperl.org> Acked-by: Stephen Warren <swarren@wwwdotorg.org> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Diffstat (limited to 'drivers/pwm')
0 files changed, 0 insertions, 0 deletions