>>> Any reason that this code is in the header? Why not in cpuidle.c? >>> >> >> Not a strong reason. I thought making it an inline would introduce >> slightly less new execution when adding this code (realizing that >> there are function calls immediately after, so the only benefit is the >> reduce popping and pushing). But it does require an extra copy of >> this code for any platform driver that does not enable >> en_core_tk_irqen and instead makes calls to it directly (like omap3). >> For this case, I don't think the inline implementation should add >> extra code from what exists today as it should simply replace the >> existing platform time keeping calls to a standard one defined by the >> core cpuidle. >> > But you will have multiple copies of the inlined code if platforms do > use it. Or is it used only by the core cpuidle code? In that case, gcc > can automatically inline static functions.
Used by some platforms as well. > > It seems a bit long to inline and this isn't performance critical (at > least for the enter side). Ok. Unless there are further comments supporting the inline method, I'll switch to non-inline for next version. Thanks Mike and Rob for the feedback. > > Rob > >> I don't have a strong preference with using the inline so if you or >> others can give your opinion on which method to use and why, I'd be >> glad to read it. >> >>> Regards, >>> Mike >> >> _______________________________________________ >> linux-arm-kernel mailing list >> linux-arm-ker...@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
