Hi Mark,
On Tue, Apr 18, 2017 at 8:33 PM, Mark Rutland <mark.rutland@xxxxxxx> wrote:
>> On Tue, Apr 11, 2017 at 10:39 AM, Mark Rutland <mark.rutland@xxxxxxx> wrote:
>> > Currently we have functions to request/free all IRQs for a given PMU.
>> > While this works today, this won't work for ACPI, where we don't know
>> > the full set of IRQs up front, and need to request them separately.
>> >
>> > To enable supporting ACPI, this patch splits out the cpu-local
>> > request/free into new functions, allowing us to request/free individual
>> > IRQs.
>> >
>> > As this makes it possible/necessary to request a PPI once per cpu, an
>> > additional check is added to detect mismatched PPIs. This shouldn't
>> > matter for the DT / platform case, as we check this when parsing.
>> >
>> > Signed-off-by: Mark Rutland <mark.rutland@xxxxxxx>
>> > Tested-by: Jeremy Linton <jeremy.linton@xxxxxxx>
>> > Cc: Will Deacon <will.deacon@xxxxxxx>
>>
>> This patch causes warnings during PSCI system suspend on R-Car Gen3.
>>
>> On R-Car M3-W (Dual CA57):
>>
>> Disabling non-boot CPUs ...
>> +IRQ15 no longer affine to CPU1
>> CPU1: shutdown
>> psci: CPU1 killed.
>>
>> On R-Car H3 (Quad CA57):
>>
>> Disabling non-boot CPUs ...
>> +IRQ15 no longer affine to CPU1
>> CPU1: shutdown
>> psci: CPU1 killed.
>> +IRQ16 no longer affine to CPU2
>> CPU2: shutdown
>> psci: CPU2 killed.
>> +IRQ17 no longer affine to CPU3
>> CPU3: shutdown
>> psci: CPU3 killed.
>>
>> Unfortunately it can't be reverted easily.
>>
>> Do you have any clue?
>
> Not presently. I'm somewhat surprised that this patch would have that
> effect -- I would imagine that the rework this is based on is more
> likely to. e.g. commit:
>
> c09adab01e4aeecf ("drivers/perf: arm_pmu: split irq request from enable")
Bummer. You're right. It's actually due to that commit.
I searched in my gmail for a patch with the specific title, and blindly
replied to the first match, not noticing that was not the right patch.
Sorry for that.
> Just to check, you definitely don't see these warnings immediately prior
> to applying this patch?
>
> My best guess otherwise is that prior to this patch, the PMU IRQ
> request was failing earlier, and we bailed out.
>
> Can you dump a dmesg before and after this patch, and see if the arm_pmu
> driver dumps anything?
On R-Car Gen3, there's no change in PMU related messages.
Actual PMU messages are:
hw perfevents: enabled with armv8_cortex_a57 PMU driver, 7
counters available
hw perfevents: /soc/pmu_a53: failed to probe PMU!
hw perfevents: /soc/pmu_a53: failed to register PMU devices!
The last two are due to the CA53 cores being described in DT, but not
enabled in the firmware.
On SH-Mobile AG5 (sh73a0/kzm9g), it recently (not due to the bad commit)
started printing:
+hw perfevents: no interrupt-affinity property for /pmu, guessing.
hw perfevents: enabled with armv7_cortex_a9 PMU driver, 7 counters available
which looks related.
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
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
