[alsa-devel] [PATCH 10/10] ASoC: SAMSUNG: Add Machine driver for S/PDIF PCM audio

[jassisinghbrar@gmail.com (Jassi Brar)]

On Tue, Oct 5, 2010 at 2:59 PM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> On Tue, Oct 05, 2010 at 02:39:00PM +0900, Jassi Brar wrote:
>
>> Yes we can have a kconfig entry for 'Controllable EPLL' but that seems
>> orthogonal to ASoC because, for SMDKs, we choose to produce
>> accurate signals hence need to manipulate EPLL. The only point is
>> where to do it.
>
> Well, there's two approaches the driver can take: one is to change the
> EPLL to deliver the clock rates which allow maximum flexibility, the
> other is to constrain the clock rates offered to applications based on
> the frequencies that can be generated from the current EPLL setup.
For SMDKs(our reference platform) I would like to change EPLL in order
to be able to verify accuracy and provide all capabilities of the controllers.
For a final product, it would make sense to fix the EPLL to one optimal value
according to the type of h/w and s/w components(ex PA can be configured
to 48KHz after making sure EPLL can also be used to generate suitable
clocks for the SPI devices on board)

>> (our priority is accuracy of each IP's functioning rather than having
>> all parts of
>> SMDK playing nice with each other on such h/w design issues)
>
> That'd be the problem, kind of - it does mean people can get burned when
> they pick up the BSP code and use it as a reference for their systems.
I expect people to replace/modify/inspect board specific code before they
run the BSP on their systems. IMO reference platforms are not good for
integrated-testing.
Meanwhile, we should make sure the SoC specific stuff supports and is
tested with
as many configurations as are possible on SMDKs.

>> I hope you noticed that this clock hierarchy is a _very_ board specific thing.
>> We can easily place SoCs' shared stuff in arch/arm/plat-samsung (or similar)
>> Any suggestions, where do we place code shared by SMDK-boards ?
>
> plat-samsung would probably be fine for that also - create a file called
> common-smdk or something. ?Some other things have gone for a plat-smdk
> style approach too, though I'm not sure how tasteful I find that
> personally.
Even though I would personally like to have EPLL control for a device
in machine specific manner as part of its driver, I accept your opinion.

Claude, let us create one arch/arm/plat-samsung/smdk.c to do common
stuff for SMKDs like EPLL control. What do you think ?


Thanks.