[RFC PATCH] ARM: pmu: add OF match support
From: Grant Likely <hidden>
Date: 2011-02-09 17:10:58
Also in:
linux-devicetree
On Wed, Feb 9, 2011 at 9:55 AM, Rob Herring [off-list ref] wrote:
Grant, On 02/09/2011 08:02 AM, Rob Herring wrote:quoted
Will, On 02/09/2011 03:51 AM, Will Deacon wrote:quoted
Hi Rob,quoted
Add OF match table to enable OF style driver binding. The dts entry is like this: pmu { compatible = "arm,pmu"; interrupts =<100 101>; }; The use of pdev->id as an index breaks with OF device binding. Change to use a counter instead. If more than 1 pmu device is ever really supported, a better solution to match users with particular pmu is probably needed.We will want to support multiple PMU devices in the near future but this is currently blocked on userspace issues. One such device would be the event counters on the PL310, which could be used to complement the CPU PMU on the Cortex-A9. I don't like the idea of a counter as it forces platforms to register their devices in a specific order. Is it possible to separate different types of PMU in the device tree and then have pmu.c work out what to do with them?Yes, they are easily distinguished by the compatible strings. Adding a pmu_get function which returns the device based on a string or capabilities may be a better solution. If you had 2 pmu's of the same type, the current code would break. In any case, how about this: static int __devinit pmu_device_probe(struct platform_device *pdev) { enum arm_pmu_type type = pdev->id; if (of_device_is_compatible(pdev->dev.of_node, "arm,pmu")) type = ARM_PMU_DEVICE_CPU;Actually, this needs to be: #ifdef CONFIG_OF ? ? ? ?if (of_device_is_compatible(pdev->dev.of_node, "arm,pmu")) ? ? ? ? ? ? ? ?type = ARM_PMU_DEVICE_CPU; #endif Seems fixing the struct device conditional is just the tip of the iceberg. Should we do empty functions for all driver accessed OF functions?
Usually all of the dt parsing code can be shuffled off into another function that can be #ifdef/#else/#endif away, but there is always a few functions that need to have empty implementations when CONFIG_OF is disabled. I prefer to take it on a case-by-case basis. The #ifdef around dev->of_node is going away in 2.6.39 g.