[alsa-devel] [PATCH 10/10] ASoC: SAMSUNG: Add Machine driver for S/PDIF PCM audio
jassisinghbrar at gmail.com
Tue Oct 5 09:09:47 CEST 2010
On Tue, Oct 5, 2010 at 2:59 PM, Mark Brown
<broonie at 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
Meanwhile, we should make sure the SoC specific stuff supports and is
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
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 ?
More information about the Alsa-devel