On Tue, Oct 5, 2010 at 10:10 AM, Jassi Brar <jassisinghbrar@xxxxxxxxx> wrote:
> On Tue, Oct 5, 2010 at 7:42 AM, Mark Brown
> <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
>> On Mon, Oct 04, 2010 at 09:16:23PM +0900, Seungwhan Youn wrote:
>>
>>> +/* Audio clock settings are belonged to board specific part. Every
>>> + * board can set audio source clock setting which is matched with H/W
>>> + * like this function-'set_audio_clock_heirachy'.
>>> + */
>>> +static int set_audio_clock_heirachy(struct platform_device *pdev)
>>> +{
>>
>> 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.
>
> Please let me explain on Claude's behalf.
> That is the first option that crossed my mind as well.
> 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.
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.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
