Use clk_prepare/clk_unprepare as required by the generic clk framework.
Signed-off-by: Prashant Gaikwad <pgaikwad@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Recent list discussions concluded that drivers should not be calling
of_have_populated_dt(), and hence of_have_populated_dt() should not be
exported. Use a different mechanism to detect DT vs. non-DT boot.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Tegra30 has some additional clocks that need to be manipulated, names
some clocks differently, runs PLLs at different base rates, etc. The
utility code needs to handle this.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Initialize the audio clock tree appropriately for some reasonable rate.
This makes sure the PLLs etc. are actually programmed to something
reasonable when the audio driver is loaded.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Lots of sound drivers were getting module.h via the implicit presence
of it in <linux/device.h> but we are going to clean that up. So
fix up those users now.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Only the clock programming code needs to know whether the clocks changed,
and that is encapsulated within tegra_asoc_utils_set_rate(). The machine
driver's call to snd_soc_dai_set_sysclk(codec_dai, ...) is safe
irrespective of whether the clocks changed.
(Applying Mark's TrimSlice review comments to the existing driver)
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
The utilities will be required by every machine driver. Including the
utility object directly into every machine driver causes a build failure
if the modules are actually built into the kernel, since each will define
the symbols exported by the utility file. Solve this by moving the
utility object into a separate module.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Liam Girdwood <lrg@slimlogic.co.uk>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Instead, have the machine driver provide storage for the utility data
somehow.
For Harmony in particular, store this within struct tegra_harmony, itself
referenced by snd_soc_card's drvdata.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Liam Girdwood <lrg@slimlogic.co.uk>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
A recent discussion on linux-arm-kernel noted that the value returned by
clk_get_sys is an opaque token, and not strictly a pointer; it is
meaningful only to the clock API, clients should not dereference the value,
and the clock API must accept any non-IS_ERR value it returned.
Hence, only IS_ERR is appropriate to interpret the result, not
IS_ERR_OR_NULL.
I checked that clk_get_sys in both ASoC's for-next and Tegra's for-next
do behave as described; NULL is not returned in the case of error.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Liam Girdwood <lrg@slimlogic.co.uk>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Many portions of Tegra ASoC machine drivers will be similar or identical.
To avoid cut/paste, this file will act as a repository for all that common
code. For now, it solely includes code to reprogram the audio PLL for
44.1KHz- vs. 48KHz-based sample rates.
Signed-Off-By: Stephen Warren <swarren@nvidia.com>
Acked-by: Liam Girdwood <lrg@slimlogic.co.uk>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
