(Remove CLK people, which, I believe, don't have anything with this matter, add Pierre who did CLK support for pmc_atom) On Tue, Mar 13, 2018 at 7:13 PM, tedheadster <tedheadster@xxxxxxxxx> wrote: >> Long story, but main concern here, that if you do s/ATOM/X86/ it will >> be more clear since we provide as less kernels as possible to cover >> all x86 architectures. >> >> Currently we have one kernel per: >> - any x86_64 case >> - any i686 case >> - uniprocessor i586 TSC case (Intel Quark) >> - (the rest exotic cases which is probably no-one using anymore) >> >> Your change disrupts this quite badly. > > This simplifies your situation, but it forces everybody else to > include extra code they will never use. x86 historically was and is almost one kernel for all CPUs/SoCs (32/64 is obvious split, Quark is rather rare exception). >> So, I think your point that you don't need it by default, and here is >> another story related to the design of Intel BayTrail / CherryTrail >> platforms where we have a nasty bug and we can't use the driver as a >> module. > Please explain the history so we can understand. > In more detail, here are the Kconfig dependencies: > > - Symbol: PMC_ATOM [=y] > - Depends on: X86 [=y] && PCI [=y] > - Selects: COMMON_CLK [=y] > > Symbol: COMMON_CLK [=y] > - Selected by: PMC_ATOM [=y] && X86 [=y] && PCI [=y] > - Selects: HAVE_CLK_PREPARE [=y] && CLKDEV_LOOKUP [=y] && SRCU [=y] && > RATIONAL [=y] > > So having _any_ X86 and PCI pulls in these four files: > > drivers/clk/x86/clk-pmc-atom.c > drivers/platform/x86/pmc_atom.c (you are right, I cut-and-pasted the > wrong file earlier) > drivers/clk/clkdev.c > lib/rational.c (^^^ this one is needed for UART anyway, so, you may exclude it if you are going to use serial console on modern x86 chips) Yes, and even more (unfortunately). If you look to the case with Cherrytrail we need to built-in I2C, PMIC stuff, otherwise it ends up badly for user experience... >>> Would this change (or something similar) make sense? >> >> No. > Okay, my novice solution isn't the right way. There must be an elegant > way to leave this configured in by default (what you want), and still > be able to turn it off if you desire (what I want). Only way I can see is to introduce a special option ATOM / non-ATOM and switch it by user desire, though it's really hard to use a binary logic to do this split. Some of the IPs are re-used in big cores as well as in Atoms. So, there is no elegant solution comes to my mind. And for sure, no upstreamable one as I can see right now. The best people to ask are x86 maintainers in this matter (Tomas, HPA, Ingo, and possible other experts in an area). So, I mark this patch in our patchwork as Rejected. But if you have a solution that will carry credits from above guys I mentioned, please, repeat your attempt. -- With Best Regards, Andy Shevchenko
