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>
