Romit Dasgupta <romit@xxxxxx> writes: > Kevin Hilman wrote: >> Kevin Hilman <khilman@xxxxxxxxxxxxxxxxxxx> writes: >> >> [...] >> >>> PMC code is ARM generic and already largely exists in other places >>> (oprofile for one.) So the use of the PMC will need to be generalized >>> as well as be shown not to interfere with other users (as raised >>> already by Jean Pihet.) >> >> Someone is already trying to generalize a PMC interface. You might want >> to follow this thread: >> >> http://lists.infradead.org/pipermail/linux-arm-kernel/2009-December/005898.html >> > > 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. 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. > 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. In summary, the PMC is a shared resource and should be treated as such using common code and common APIs. Kevin -- 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
