Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1622948 > unrolled thread
| Started by | Michael Ellerman <mpe@ellerman.id.au> |
|---|---|
| First post | 2017-04-13 13:50 +0200 |
| Last post | 2017-04-17 10:10 +0200 |
| Articles | 2 — 2 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: [PATCH v6 03/11] powerpc/powernv: Detect supported IMC units and its events Michael Ellerman <mpe@ellerman.id.au> - 2017-04-13 13:50 +0200
Re: [PATCH v6 03/11] powerpc/powernv: Detect supported IMC units and its events Anju T Sudhakar <anju@linux.vnet.ibm.com> - 2017-04-17 10:10 +0200
| From | Michael Ellerman <mpe@ellerman.id.au> |
|---|---|
| Date | 2017-04-13 13:50 +0200 |
| Subject | Re: [PATCH v6 03/11] powerpc/powernv: Detect supported IMC units and its events |
| Message-ID | <tvLqa-2qX-5@gated-at.bofh.it> |
Anju T Sudhakar <anju@linux.vnet.ibm.com> writes:
> On Thursday 06 April 2017 02:07 PM, Stewart Smith wrote:
>> Madhavan Srinivasan <maddy@linux.vnet.ibm.com> writes:
>>> --- a/arch/powerpc/platforms/powernv/opal-imc.c
>>> +++ b/arch/powerpc/platforms/powernv/opal-imc.c
>>> @@ -33,6 +33,388 @@
>> <snip>
>>> +static void imc_pmu_setup(struct device_node *parent)
>>> +{
>>> + struct device_node *child;
>>> + int pmu_count = 0, rc = 0;
>>> + const struct property *pp;
>>> +
>>> + if (!parent)
>>> + return;
>>> +
>>> + /* Setup all the IMC pmus */
>>> + for_each_child_of_node(parent, child) {
>>> + pp = of_get_property(child, "compatible", NULL);
>>> + if (pp) {
>>> + /*
>>> + * If there is a node with a "compatible" field,
>>> + * that's a PMU node
>>> + */
>>> + rc = imc_pmu_create(child, pmu_count);
>>> + if (rc)
>>> + return;
>>> + pmu_count++;
>>> + }
>>> + }
>>> +}
>> This doesn't strike me as the right kind of structure, the presence of a
>> compatible property really just says "hey, there's this device and it's
>> compatible with these ways of accessing it".
>>
>> I'm guessing the idea behind having imc-nest-offset/size in a top level
>> node is because it's common to everything under it and the aim is to not
>> blow up the device tree to be enormous.
>>
>> So why not go after each ibm,imc-counters-nest compatible node under the
>> top level ibm,opal-in-memory-counters node? (i'm not convinced that
>> having ibm,ibmc-counters-nest versus ibm,imc-counters-core and
>> ibm,imc-counters-thread as I see in the dts is correct though, as
>> they're all accessed exactly the same way?)
>
> The idea here is, we have one directory which contains common events
> information for nest(same incase of core and thread), and one directory
> for each nest(/core/thread) pmu.
> So while parsing we need to make sure that the node which we are parsing
> is the pmu node, not the node which contains the common event
> information. We use the "compatible" property here for that purpose.
> Because we don't have a compatible property for the node which contains
> events info.
That's a really bad hack.
You can use the compatible property to detect the node you're looking
for, but you need to look at the *value* of the property and check it's
what you expect. Just checking that it's there is fragile.
cheers
[toc] | [next] | [standalone]
| From | Anju T Sudhakar <anju@linux.vnet.ibm.com> |
|---|---|
| Date | 2017-04-17 10:10 +0200 |
| Subject | Re: [PATCH v6 03/11] powerpc/powernv: Detect supported IMC units and its events |
| Message-ID | <tx9Tr-6KB-3@gated-at.bofh.it> |
| In reply to | #1622948 |
Hi Michael,
On Thursday 13 April 2017 05:13 PM, Michael Ellerman wrote:
> Anju T Sudhakar <anju@linux.vnet.ibm.com> writes:
>> On Thursday 06 April 2017 02:07 PM, Stewart Smith wrote:
>>> Madhavan Srinivasan <maddy@linux.vnet.ibm.com> writes:
>>>> --- a/arch/powerpc/platforms/powernv/opal-imc.c
>>>> +++ b/arch/powerpc/platforms/powernv/opal-imc.c
>>>> @@ -33,6 +33,388 @@
>>> <snip>
>>>> +static void imc_pmu_setup(struct device_node *parent)
>>>> +{
>>>> + struct device_node *child;
>>>> + int pmu_count = 0, rc = 0;
>>>> + const struct property *pp;
>>>> +
>>>> + if (!parent)
>>>> + return;
>>>> +
>>>> + /* Setup all the IMC pmus */
>>>> + for_each_child_of_node(parent, child) {
>>>> + pp = of_get_property(child, "compatible", NULL);
>>>> + if (pp) {
>>>> + /*
>>>> + * If there is a node with a "compatible" field,
>>>> + * that's a PMU node
>>>> + */
>>>> + rc = imc_pmu_create(child, pmu_count);
>>>> + if (rc)
>>>> + return;
>>>> + pmu_count++;
>>>> + }
>>>> + }
>>>> +}
>>> This doesn't strike me as the right kind of structure, the presence of a
>>> compatible property really just says "hey, there's this device and it's
>>> compatible with these ways of accessing it".
>>>
>>> I'm guessing the idea behind having imc-nest-offset/size in a top level
>>> node is because it's common to everything under it and the aim is to not
>>> blow up the device tree to be enormous.
>>>
>>> So why not go after each ibm,imc-counters-nest compatible node under the
>>> top level ibm,opal-in-memory-counters node? (i'm not convinced that
>>> having ibm,ibmc-counters-nest versus ibm,imc-counters-core and
>>> ibm,imc-counters-thread as I see in the dts is correct though, as
>>> they're all accessed exactly the same way?)
>> The idea here is, we have one directory which contains common events
>> information for nest(same incase of core and thread), and one directory
>> for each nest(/core/thread) pmu.
>> So while parsing we need to make sure that the node which we are parsing
>> is the pmu node, not the node which contains the common event
>> information. We use the "compatible" property here for that purpose.
>> Because we don't have a compatible property for the node which contains
>> events info.
> That's a really bad hack.
>
> You can use the compatible property to detect the node you're looking
> for, but you need to look at the *value* of the property and check it's
> what you expect. Just checking that it's there is fragile.
>
> cheers
>
ok. I will rework this code.
Thanks,
Anju
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web