On Tue, Oct 5, 2010 at 1:43 PM, Mark Brown <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote: > 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@xxxxxxxxx> wrote: >> > On Tue, Oct 5, 2010 at 7:42 AM, Mark Brown > 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. Yes, past mistakes haunt us still. > 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. 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. (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) >> 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. 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 ? Thanks -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |