On 14/08/13 22:16, Kumar Gala wrote:
On Aug 14, 2013, at 4:13 PM, Stephen Warren wrote:
On 08/14/2013 03:09 PM, Kumar Gala wrote:
On Aug 14, 2013, at 4:06 PM, Stephen Warren wrote:
On 07/23/2013 03:19 AM, Punit Agrawal wrote:
The CCI PMU can profile bus transactions at the master and slave
interfaces of the CCI. The PMU can be used to observe an aggregated view
of the bus traffic between the various components connected to the CCI.
Extend the existing CCI driver to support the PMU by registering a perf
backend for it.
Document the device tree binding to describe the CCI PMU.
diff --git a/Documentation/devicetree/bindings/arm/cci.txt b/Documentation/devicetree/bindings/arm/cci.txt
+ - CCI PMU node
+
+ Node name must be "pmu".
I don't think the binding should require the node to have a particular
name; node names shouldn't be interpret/used/relied-upon by drivers.
While I agree with that, we should be aiming for some convention and consistency with node names.
Sure. Should there be a Documentation/devictree/bindings/node-names that
lists common node names for people to use? Either way though, I still
think this is an aspect of authoring the *.dts file, not an aspect of
the DT binding? After all, what if there were more than one CCI so they
needed to be named pmu@0, pmu@1, etc.?
Agreed, I was thinking a bindings/node-names would be a good idea.
I'm guessing 99% of people copy either from the example in the binding of an existing .dts file. So while I agree the binding shouldn't require a node name be a specific thing as part of the spec, we as reviewers should try to ensure consistency in examples or .dts files.
Based on the comments so far, I will change the bindings documentation
submitted with this patch to remove the requirement for a particular
node name for CCI PMU.
As it is, this is not required by the driver but was only done for
consistency.
Cheers,
Punit
- k
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
