>> >> I tried to find the code in LO but I think it is not yet present. >Right, it is still being discussed. >> So with that in mind may I propose that the pmc functions we >> introduce in plat-omap will be present as __init code (so that we >> ensure no one uses it after the system finishes booting up) as long >> as the pmc infrastructure is not available for non-Oprofile uses? >Personally, I don't like this idea. >IMHO, the PMC is not OMAP specific and does not belong in plat-omap >even as init code. Either generalize and use existing PMC >infrastructure, or use a different timer. Ftrace/Oprofile/Perf are all initialized later during the boot process. Actually if you see where we are using pmc it is in init_IRQ. So until the pmc libraries I think it would be fair to use it. I do not see any problem. Can you point out with any concrete code from the latest OMAP tree? >You didn't answer my other question about whether or not a GPtimer >could be used for this. You could quickly request/program/free a >GPtimer for this too using the omap_dm_timer* API. May be possibe but IMHO it is ugly to setup and more complicated to use than the pmc approach. The other indirect way is like how bogomips is calculated. But that is a different story. We need accuracy in the delay and __may be__ interrupt latency would skew the results. If someone can implement it using Interrupt we would like to see how much access delay they get using irq technique. >> As I mentioned in an earlier thread, the pmc is used and stopped >> very early during the kernel boot and AFAICT there should not be any >> problem (probably we need to check its behavior on EMU/HS devices). >This isn't very convicing. >Also, it's not just oprofile we have to be worried about. The >perf/trace infrastructure arm is also using the PMC. It will not be >uncommon to use perf on early boot/init and the use of the PMC in this >patch will clearly interfere with that. Wrong! See above. >In summary, the PMC is a shared resource and should be treated as such >using common code and common APIs. Where is it today? Thanks, -Romit-- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
