Arnd, On Fri, May 2, 2014 at 11:52 AM, Arnd Bergmann <arnd@xxxxxxxx> wrote: > On Friday 02 May 2014 18:33:39 Arun Kumar K wrote: >> From: Alim Akhtar <alim.akhtar@xxxxxxxxxxx> >> >> Exynos5800 clock structure is mostly similar to 5420 with only >> a small delta changes. So the 5420 clock file is re-used for >> 5800 also. The common clocks for both are seggreagated and few >> clocks which are different for both are separately initialized. >> >> Signed-off-by: Alim Akhtar <alim.akhtar@xxxxxxxxxxx> >> Signed-off-by: Arun Kumar K <arun.kk@xxxxxxxxxxx> > > This isn't about your specific patch, but every time I see a new > exynos variant get supported, it comes with a clock driver patch > that is at least as big as all the other patches combined. > > New variants come out all the time now, and we are starting to > accumulate huge amounts of clock definitions both in the source > and the binary. I think we should try to come up with a better > way to represent the clocks. I don't think any other SoC > family is nearly as bad as Exynos, either because they have > much fewer models, or because they abstract their clocks more > and put all the tables into DT. > > I'm definitely not saying no to the exynos5800 addition for this, > but I'm starting to get a little annoyed, and I think it would be > good to come up with a new clock binding before we see 64-bit > Exynos variants. One thing to note: your suggestion will almost certainly not be conducive to get stable device trees. IMHO there's pretty much a zero chance that you could properly describe all of the exynos clocks in the first, second, third, or twentieth attempt. That means that if anyone ever took it in their head to actually ship a device tree that wasn't bundled with the kernel that it would probably be wrong. Declaring just "I have exynos5800 clocks" means that you're not relying on the device tree. The clocks are pretty table-based as-is, and I think that's about the best you're going to get. NOTE: one could argue that possibly the 5420 and 5800 are different enough that they ought to have separate tables. I don't feel like I'm in enough of an ownership position to make that tradeoff either way, though. -Doug -- 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
 |