On Tue, Oct 05, 2010 at 11:19:35AM +0900, Jassi Brar wrote:
On Tue, Oct 5, 2010 at 10:10 AM, Jassi Brar jassisinghbrar@gmail.com wrote:
On Tue, Oct 5, 2010 at 7:42 AM, Mark Brown
I'd expect this to be with the other clock configuration code under arch/arm, especially as it's involving the EPLL which can have fairly wide usage - it seems better to make sure people working with other, non-audio, bits of the system are aware of the EPLL usage.
But that would have made us have EPLL manipulation in two places - one in arch/arm/mach/board-init and other in ASoC Machine driver because we would need to change the source clock's rate in runtime(using callback pointers for the purpose seemed too over the top). If ASoC doesn't change EPLL, it doesn't matter to other devices, if it does there is currently no means for other drivers to know about it. So, we might just as well move the EPLL related code to ASoC machine driver.
The reason I'm concerned about this is that I've had actual problems with users of your out of tree BSPs getting confused by similar code there. Thinking about it some more it's not so much the fact that the code is spread out as the fact that the the EPLL is so widely used within the system that having one driver change it can easily disrupt another subsystem in surprising ways.
Since the clock API currently doesn't have a good way of resolving this perhaps a config option or something which masks the EPLL behaviour controllable and leaves it alone by default? That would show people how to use this chip feature without affecting the other subsystems so non-obviously.
Btw, another important reason is that having EPLL manipulation in board-int would result in code-duplication on other SMDK platforms as most have the same clock routing options available in h/w and we want to use the same ASoC machine driver for SoCs whenever possible.
This doesn't seem such a big deal - you could create a shared file for the code under arch/arm.