tree 1313057e514a83f76cb86fc687e4fca6b1488fee
parent ff87d619ac180444db297f043962a5c325ded47b
parent 28086d05ada6d03daa886aad0e469854b811311c
author Mark Brown <broonie@kernel.org> 1654770360 +0100
committer Mark Brown <broonie@kernel.org> 1654772192 +0100
gpgsig -----BEGIN PGP SIGNATURE-----
 
 iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmKh0eYACgkQJNaLcl1U
 h9BcIgf/ZR3953tsPFHx8VO0MszCtg4NCXEqD4YhBZTONcj1WyPdVrpObaYUC21J
 W8/K9N0z0CEh89Nn+TNAP+wlmfXjt00edQgMZaeDEipmOLxPTuYRtiWIN/R6XwnI
 rODZlIV4gOscbWUGtlvUz8IMK+l+OkipjXGdgV7Q/002lfvuy0c9F1q0uY594t8H
 nAISwfLatXqbATBfDNuMOglG434NCjEvWAnsqeWixg9fQ07e0aEdKPkbNm7lDGtL
 JmiOn5nd5x4YCX4JceNpZB+EzIR07nhUMf7ESSOa2nAcbmkVOw3nsT4eHfqKmIQC
 ClOV8+QjaR3xuHwBBhRjO89JFzWluA==
 =QCRp
 -----END PGP SIGNATURE-----

Specify clock provider directly to CPU DAIs

Merge series from Charles Keepax <ckeepax@opensource.cirrus.com>:

Currently the set_fmt callback always passes clock provider/consumer
with respect to the CODEC. This made sense when the framework was
directly broken down into platforms and CODECs. However, as things
are now broken down into components which can be connected as either
the CPU or CODEC side of a DAI link it simplifies things if each
side of the link is just told if it is provider or consumer of the
clocks. Making this change allows us to remove one of the last parts
of the ASoC core that needs to know if a driver is a CODEC driver,
where it flips the clock format specifier if a CODEC driver is used on
the CPU side of a DAI link, as well as just being conceptually more
consistent with componentisation.

The basic idea of this patch chain is to change the set_fmt callback
from specifying if the CODEC is provider/consumer into directly
specifying if the component is provider/consumer. To do this we add
some new defines, and then to preserve bisectability, the migration is
done by adding a new callback, converting over all existing CPU side
drivers, converting the core, and then finally reverting back to the
old callback.

Converting the platform drivers makes sense as the existing defines
are from the perspective of the CODEC and there are more CODEC drivers
than platform drivers.

Obviously a fair amount of this patch chain I was only able to build
test, so any testing that can be done would be greatly appreciated.