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.