Thread (1 message) 1 message, 1 author, 2011-02-09

[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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help