diff options
author | Eric Anholt <eric@anholt.net> | 2015-10-08 18:37:24 -0700 |
---|---|---|
committer | Stephen Boyd <sboyd@codeaurora.org> | 2015-10-12 11:32:02 -0700 |
commit | 41691b8862e2a32080306f17a723efc4b6ca86ab (patch) | |
tree | 56082eb8f81ec0b5d28dc2314a996e0b5820ac12 /crypto | |
parent | 2c74b5399de730e3155dc3d5a8ad041fba5e93f4 (diff) | |
download | linux-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 'crypto')
0 files changed, 0 insertions, 0 deletions