Message ID | 20150327172246.GN1562@arm.com |
---|---|
State | New |
Headers | show |
Hi Will, On Fri, Mar 27, 2015 at 6:22 PM, Will Deacon <will.deacon@arm.com> wrote: > Will Deacon (1): > ARM: pmu: add support for interrupt-affinity property As most DTSes lack this property, we now get scary warnings: CPU PMU: Failed to parse <no-node>/interrupt-affinity[0] BTW, shouldn't the DT update go in first, or together with the code update? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
On Tue, Apr 07, 2015 at 04:05:40PM +0100, Geert Uytterhoeven wrote: > On Fri, Mar 27, 2015 at 6:22 PM, Will Deacon <will.deacon@arm.com> wrote: > > Will Deacon (1): > > ARM: pmu: add support for interrupt-affinity property > > As most DTSes lack this property, we now get scary warnings: > > CPU PMU: Failed to parse <no-node>/interrupt-affinity[0] That's a harmless warning (i.e. perf will `work' as before), but I'd like to print something to say that we didn't find the property. > BTW, shouldn't the DT update go in first, or together with the code update? It's going via the arm64 tree (I had to choose one of the trees for the binding, since they both arm and arm64 use it). Will
Hi Will, On Mon, Apr 13, 2015 at 10:10:12AM +0100, Will Deacon wrote: > On Tue, Apr 07, 2015 at 04:05:40PM +0100, Geert Uytterhoeven wrote: > > On Fri, Mar 27, 2015 at 6:22 PM, Will Deacon <will.deacon@arm.com> wrote: > > > Will Deacon (1): > > > ARM: pmu: add support for interrupt-affinity property > > > > As most DTSes lack this property, we now get scary warnings: > > > > CPU PMU: Failed to parse <no-node>/interrupt-affinity[0] > > That's a harmless warning (i.e. perf will `work' as before), but I'd like to > print something to say that we didn't find the property. Shouldn't we have a warning only if that property makes some kind of sense? I mean, I agree on the fact that we want this property if this is an SPI, but if it is a PPI, it doesn't make any sense to have this property, and this is very well documented in the binding documentation. Maxime
Hi Will, On Mon, Apr 13, 2015 at 11:10 AM, Will Deacon <will.deacon@arm.com> wrote: > On Tue, Apr 07, 2015 at 04:05:40PM +0100, Geert Uytterhoeven wrote: >> On Fri, Mar 27, 2015 at 6:22 PM, Will Deacon <will.deacon@arm.com> wrote: >> > Will Deacon (1): >> > ARM: pmu: add support for interrupt-affinity property >> >> As most DTSes lack this property, we now get scary warnings: >> >> CPU PMU: Failed to parse <no-node>/interrupt-affinity[0] > > That's a harmless warning (i.e. perf will `work' as before), but I'd like to > print something to say that we didn't find the property. > >> BTW, shouldn't the DT update go in first, or together with the code update? > > It's going via the arm64 tree (I had to choose one of the trees for the > binding, since they both arm and arm64 use it). OK. Will start to pull arm64 too into renesas-drivers... BTW, time to start unifying arm32 and arm64? ;-) Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
On Mon, Apr 13, 2015 at 10:30:22AM +0100, Geert Uytterhoeven wrote: > On Mon, Apr 13, 2015 at 11:10 AM, Will Deacon <will.deacon@arm.com> wrote: > > On Tue, Apr 07, 2015 at 04:05:40PM +0100, Geert Uytterhoeven wrote: > >> On Fri, Mar 27, 2015 at 6:22 PM, Will Deacon <will.deacon@arm.com> wrote: > >> > Will Deacon (1): > >> > ARM: pmu: add support for interrupt-affinity property > >> > >> As most DTSes lack this property, we now get scary warnings: > >> > >> CPU PMU: Failed to parse <no-node>/interrupt-affinity[0] > > > > That's a harmless warning (i.e. perf will `work' as before), but I'd like to > > print something to say that we didn't find the property. > > > >> BTW, shouldn't the DT update go in first, or together with the code update? > > > > It's going via the arm64 tree (I had to choose one of the trees for the > > binding, since they both arm and arm64 use it). > > OK. Will start to pull arm64 too into renesas-drivers... > > BTW, time to start unifying arm32 and arm64? ;-) We're already working on unifying the perf bits (the major duplication imo) by moving the bulk of it into drivers. Stay tuned! Will
On Mon, Apr 13, 2015 at 10:28:12AM +0100, Maxime Ripard wrote: > On Mon, Apr 13, 2015 at 10:10:12AM +0100, Will Deacon wrote: > > On Tue, Apr 07, 2015 at 04:05:40PM +0100, Geert Uytterhoeven wrote: > > > On Fri, Mar 27, 2015 at 6:22 PM, Will Deacon <will.deacon@arm.com> wrote: > > > > Will Deacon (1): > > > > ARM: pmu: add support for interrupt-affinity property > > > > > > As most DTSes lack this property, we now get scary warnings: > > > > > > CPU PMU: Failed to parse <no-node>/interrupt-affinity[0] > > > > That's a harmless warning (i.e. perf will `work' as before), but I'd like to > > print something to say that we didn't find the property. > > Shouldn't we have a warning only if that property makes some kind of > sense? > > I mean, I agree on the fact that we want this property if this is an > SPI, but if it is a PPI, it doesn't make any sense to have this > property, and this is very well documented in the binding > documentation. Yes, that's a good point; for PPIs, the warning is nonsensical. I'll cook a fix. Cheers, Will