- 28 Jun, 2022 35 commits
-
-
Kajol Jain authored
Thresh select bits in the event code is used to program thresh_sel field in Monitor Mode Control Register A (MMCRA: 45-47). When scheduling events as a group, all events in that group should match value in these bits. Otherwise event open for the sibling events will fail. Testcase uses event code PM_MRK_INST_CMPL (0x401e0) as leader and another event PM_THRESH_MET (0x101ec) as sibling event, and checks if group constraint checks for thresh_sel field added correctly via perf interface. Signed-off-by:
Kajol Jain <kjain@linux.ibm.com> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20220610134113.62991-35-atrajeev@linux.vnet.ibm.com
-
Kajol Jain authored
Thresh control bits in the event code is used to program thresh_ctl field in Monitor Mode Control Register A (MMCRA: 48-55). When scheduling events as a group, all events in that group should match value in these bits. Otherwise event open for the sibling events will fail. Testcase uses event code PM_MRK_INST_CMPL (0x401e0) as leader and another event PM_THRESH_MET (101ec) as sibling event, and checks if group constraint checks for thresh_ctl field added correctly via perf interface. Signed-off-by:
-
Kajol Jain authored
Unit and pmu bits in the event code is used to program unit and pmc fields in Monitor Mode Control Register 1 (MMCR1). For power9 platform, incase unit field value is within 6 to 9, one of the event in the group should use PMC4. Otherwise event_open should fail for that group. Signed-off-by:
-
Kajol Jain authored
Thresh compare bits for a event is used to program thresh compare field in Monitor Mode Control Register A (MMCRA: 9-18 bits for power9 and MMCRA: 8-18 bits for power10). When scheduling events as a group, all events in that group should match value in thresh compare bits. Otherwise event open for the sibling events will fail. Testcase uses event code "0x401e0" as leader and another event "0x101ec" as sibling event, and checks for thresh compare constraint via perf interface. Signed-off-by:
-
Kajol Jain authored
Data and instruction cache qualifier bits in the event code is used to program cache select field in Monitor Mode Control Register 1 (MMCR1: 16-17). When scheduling events as a group, all events in that group should match value in these bits. Otherwise event open for the sibling events will fail. Testcase uses event code "0x1100fc" as leader and other events like "0x23e054" and "0x13e054" as sibling events to checks for l1 cache select field constraints via perf interface. Signed-off-by:
-
Kajol Jain authored
In power10, L2L3 select bits in the event code is used to program l2l3_sel field in Monitor Mode Control Register 0 (MMCR0: 56-60). When scheduling events as a group, all events in that group should match value in these bits. Otherwise event open for the sibling events will fail. Testcase uses event code "0x010000046080" as leader and another events "0x26880" and "0x010000026880" as sibling events, and checks for l2l3_sel constraints via perf interface for ISA v3.1 platform. Signed-off-by:
-
Athira Rajeev authored
Testcase to ensure that using invalid event in generic event for PERF_TYPE_HARDWARE will fail. Invalid generic events in power10 are: - PERF_COUNT_HW_BUS_CYCLES - PERF_COUNT_HW_STALLED_CYCLES_FRONTEND - PERF_COUNT_HW_STALLED_CYCLES_BACKEND - PERF_COUNT_HW_REF_CPU_CYCLES Invalid generic events in power9 are: - PERF_COUNT_HW_BUS_CYCLES - PERF_COUNT_HW_REF_CPU_CYCLES Testcase does event open for valid and invalid generic events to ensure event open works for all valid events and fails for invalid events. Signed-off-by:
Athira Rajeev <atrajeev@linux.vnet.ibm.com> Signed-off-by:
-
Athira Rajeev authored
Platform specific PMU supports alternative event for some of the event codes. During perf_event_open, it any event group doesn't match constraint check criteria, further lookup is done to find alternative event. Code checks to see if it is possible to schedule event as group using alternative events. Testcase exercises the alternative event find code for power10. Example, Using PMC1 to PMC4 in a group and again trying to schedule PM_CYC_ALT (0x0001e) will fail since this exceeds number of programmable events in group. But since 0x600f4 is an alternative event for 0x0001e, it is possible to use 0x0001e in the group. Testcase uses such combination all events in power10 which has alternative event. Signed-off-by:
-
Athira Rajeev authored
Platform specific PMU supports alternative event for some of the event codes. During perf_event_open, it any event group doesn't match constraint check criteria, further lookup is done to find alternative event. Code checks to see if it is possible to schedule event as group using alternative events. Testcase exercises the alternative event find code for power9. Example, since events in same PMC can't go in as a group, ideally using PM_RUN_CYC_ALT (0x200f4) and PM_BR_TAKEN_CMPL (0x200fa) will fail. But since RUN_CYC (0x600f4) is alternative event for 0x200f4, it is possible to use 0x600f4 and 0x200fa as group. Testcase uses such combination for all events in power9 which has an alternative event. Signed-off-by:
-
Athira Rajeev authored
Some of the events are blacklisted in power9. The list of blacklisted events are noted in power9-events-list.h When trying to do event open for any of these blacklisted event will cause a failure. Testcase ensures that using blacklisted events will cause event_open to fail in power9. This test is only applicable on power9 DD2.1 and DD2.2 and hence test adds checks to skip on other platforms. Signed-off-by:
-
Athira Rajeev authored
Testcase for reserved bits in Monitor Mode Control Register A (MMCRA) thresh_ctl bits. For MMCRA[48:51]/[52:55]) Threshold Start/Stop, 0b11110000/0b00001111 is reserved. Signed-off-by:
-
Athira Rajeev authored
Some of the bits in the event code is reserved for specific platforms. Event code bits 52-59 are reserved in power9, whereas in power10, these are used for programming Monitor Mode Control Register 3 (MMCR3). Bit 9 in event code is reserved in power9, whereas it is used for programming "radix_scope_qual" bit 18 in Monitor Mode Control Register 1 (MMCR1). Testcase to ensure that using reserved bits in event code should cause event_open to fail. Signed-off-by:
-
Athira Rajeev authored
Events with different "sample" field values which is used to program Monitor Mode Control Register A (MMCRA) in a group will fail to schedule. Testcase uses event with load only sampling mode as group leader and event with store only sampling as sibling event. So that it can check that using different sample bits in event code will fail in event open for group of events Signed-off-by:
-
Athira Rajeev authored
Testcase for reserved bits in Monitor Mode Control Register A (MMCRA) Random Sampling Mode (SM) value. As per Instruction Set Architecture (ISA), the values 0x5, 0x9, 0xD, 0x19, 0x1D, 0x1A, 0x1E are reserved for sampling mode field. Test that having these reserved bit values should cause event_open to fail. Input event code in testcases uses these sampling bits along with 401e0 (PM_MRK_INST_CMPL). Signed-off-by:
-
Athira Rajeev authored
Testcase for group constraint check for radix_scope_qual field which is used to program Monitor Mode Control Register (MMCR1) bit 18. All events in the group should match radix_scope_qual bit, otherwise event_open for the group should fail. Testcase uses "0x14242" (PM_DATA_RADIX_PROCESS_L2_PTE_FROM_L2) with radix_scope_qual bit set for power10. Signed-off-by:
-
Athira Rajeev authored
Testcase for group constraint check when using events with same PMC. Multiple events in a group asking for same PMC should fail. Testcase uses "0x22C040" on PMC2 as leader and also subling which is expected to fail. Using PMC1 for sibling event should pass the test. Signed-off-by:
-
Athira Rajeev authored
Testcase for group constraint check for number of counters in use. The number of programmable counters is from PMC1 to PMC4. Testcase uses four events with PMC1 to PMC4 and 5th event without any PMC which is expected to fail since it is exceeding the number of counters in use. Signed-off-by:
-
Athira Rajeev authored
Events using Performance Monitor Counter 5 (PMC5) and Performance Monitor Counter 6 (PMC6) should be excluded from constraint check when scheduled along with group of events. Example, combination of PMC5, PMC6, and an event with cache bit will succeed to schedule though first two events doesn't have cache bit set. Testcase use three events, ie, 600f4(cycles), 500fa(instructions), 22C040 with cache bit (dc_ic) set to test this constraint check. Signed-off-by:
-
Athira Rajeev authored
Events using Performance Monitor Counter 5 (PMC5) and Performance Monitor Counter 6 (PMC6) can't have other fields in event code like cache bits, thresholding or marked bit. PMC5 and PMC6 only supports base events: ie 500fa and 600f4. Other combinations should fail. Testcase tries setting other bits in event code for 500fa and 600f4 to check this scenario. Signed-off-by:
-
Athira Rajeev authored
Add new folder for enabling perf event code tests which includes checking for group constraints, valid/invalid events, also checks for event excludes, alternatives so on. A new folder "event_code_tests", is created under "selftests/powerpc/pmu". Also updates the corresponding Makefiles in "selftests/powerpc" and "event_code_tests" folder. Signed-off-by:
-
Kajol Jain authored
The testcase uses "instructions" event to generate the samples and fetch Monitor Mode Control Register A (MMCRA) when overflow. Branch History Rolling Buffer(bhrb) disable bit is part of MMCRA which need to be verified by perf interface. Incase sample is not of branch type, bhrb disable bit is explicitly set to 1. Testcase checks if the bhrb disable bit is set of MMCRA register via perf interface for ISA v3.1 platform Signed-off-by:
-
Athira Rajeev authored
The testcase uses event code "0x21c040" to verify the settings for different fields in Monitor Mode Control Register 1 (MMCR1). The fields include PMCxSEL, PMCXCOMB PMCxUNIT, cache. Checks if these fields are translated correctly via perf interface to MMCR1 Signed-off-by:
-
Athira Rajeev authored
For PERF_SAMPLE_BRANCH_STACK sample type, different branch_sample_type, ie branch filters are supported. All the branch filters are not supported in powerpc. Example, power10 platform supports any, ind_call and cond branch filters. Whereas, it is different in power9. Testcase checks event open for invalid and valid branch sample types. The branch types for testcase are picked from "perf_branch_sample_type" in perf_event.h Signed-off-by:
-
Athira Rajeev authored
selftests/powerpc/pmu: Add selftest to check PERF_SAMPLE_REGS_INTR option will not crash on any platforms With sampling, --intr-regs option is used for capturing interrupt regs. When --intr-regs option is used, PMU code uses is_sier_available() function which uses PMU flags in the code. In environment where platform specific PMU is not registered, PMU flags is not defined. A fix was added in kernel to address crash while accessing is_sier_available() function when pmu is not set. commit f75e7d73 ("powerpc/perf: Fix crash with is_sier_available when pmu is not set"). Add perf sampling test to exercise this code and make sure enabling intr_regs shouldn't crash in any platform. Testcase uses software event cycles since software event will work even in cases without PMU. Signed-off-by:
-
Athira Rajeev authored
selftests/powerpc/pmu: Add selftest to check branch stack enablement will not crash on any platforms While enabling branch stack for an event, BHRB (Branch History Rolling Buffer) filter is set using bhrb_filter_map() callback. This callback is not defined for cases like generic_compat_pmu or in case where there is no PMU registered. A fix was added in kernel to address a crash issue observed while enabling branch stack for environments which doesn't have this callback. commit b460b512 ("powerpc/perf: Fix crashes with generic_compat_pmu & BHRB"). Add perf sampling test to exercise this code path and make sure enabling branch stack shouldn't crash in any platform. Testcase uses software event cycles since software event is available and can be used even in cases without PMU. Signed-off-by:
-
Athira Rajeev authored
The platform check for selftest support "check_pvr_for_sampling_tests" is specific to sampling tests which includes PVR check, presence of PMU and extended regs support. Extended regs support is needed for sampling tests which tests whether PMU registers are programmed correctly. There could be other sampling tests which may not need extended regs, example, bhrb filter tests which only needs validity check via event open. Hence refactor the platform check to have a common function "platform_check_for_tests" that checks only for PVR check and presence of PMU. The existing function "check_pvr_for_sampling_tests" will invoke the common function and also will include checks for extended regs specific for sampling. The common function can also be used by tests other than sampling like event code tests. Add macro to find array size ("ARRAY_SIZE") to sampling tests "misc.h" file. This can be used in next tests to find event array size. Also update "include/reg.h" to add macros to find minor and major version from PVR which will be used in testcases. Signed-off-by: -
Kajol Jain authored
The testcase uses "instructions" event to generate the samples and fetch Monitor Mode Control Register A (MMCRA) when overflow. Branch History Rolling Buffer(bhrb) disable bit is part of MMCRA which need to be verified by perf interface. Testcase checks if the bhrb disable bit of MMCRA register is programmed correctly via perf interface for ISA v3.1 platform Also make get_mmcra_ifm return type as u64. Signed-off-by:
-
Kajol Jain authored
The testcase uses "instructions" event to check if the Instruction filtering mode(IFM) bits are programmed correctly for conditional branch type. Testcase checks if IFM bits is programmed correctly to Monitor Mode Control Register A (MMCRA) via perf interface for ISA v3.1 platform. Signed-off-by:
-
Kajol Jain authored
The testcase uses "instructions" event to check if the Instruction filtering mode(IFM) bits are programmed correctly for type any branch. Testcase checks if IFM bits is programmed correctly to Monitor Mode Control Register A (MMCRA) via perf interface. Signed-off-by:
-
Kajol Jain authored
The testcase uses "instructions" event to check if the Instruction filtering mode(IFM) bits are programmed correctly for indirect branch type. Testcase checks if IFM bits are programmed correctly to Monitor Mode Control Register A (MMCRA) via perf interface for ISA v3.1 platform. Signed-off-by:
-
Kajol Jain authored
Add support for sample type as PERF_SAMPLE_BRANCH_STACK in sampling tests. This change is a precursor/helper for sampling testcases, that test branck stack feature in perf interface. Signed-off-by:
-
Kajol Jain authored
The testcase uses event code 0x35340401e0 for load only sampling, to verify the settings of thresh compare field in Monitor Mode Control Register A (MMCRA: 9-18 bits for power9 and MMCRA: 8-18 bits for power10). Testcase checks if the thresh compare field is programmed correctly via perf interface to MMCRA register. Signed-off-by:
-
Athira Rajeev authored
selftests/powerpc: Add support to fetch "platform" and "base platform" from auxv to detect platform. The /proc/self/auxv contains information about "platform" on any system. Also "base platform" which is an indication about platform string corresponding to the real PVR. When systems are booted in compat mode, say, power10 booted in power9 mode, "platform" will point to power9 whereas base platform will point to power10. Incase, if the distro doesn't support platform indicated by real PVR, base platform will have a default value. The mismatch of platform/base platform is an indication of system booted in compat mode. In such cases, distro will have a Generic Compat registered which supports basic features for performance monitoring. Some of the selftest needs to be handled differently ( ex: generic events, alternative events, bhrb filter map) in Generic Compat PMU. Hence selftest framework needs utility functions to identify such cases. One way is make sure of auxv information. Below condition can be used to detect if Generic Compat PMU is registered. ie: if ((AT_PLATFORM != AT_BASE_PLATFORM) && (AT_BASE_PLATFORM != PVR)) this indicates Generic Compat PMU. Add utility function in "include/utils.h" to return: AT_PLATFORM and AT_BASE_PLATFORM from auxv. Also update misc.c in "sampling_tests" folder to add function to use above check to determine presence of generic compat pmu. In other architecture ( like x86 ), pmu_name is exposed via "/sys/bus/event_source/devices/cpu/caps". The same could be used in powerpc in future. Since currently we don't have the "caps" support in powerpc, patch uses auxv information to detect platform type and compat mode. But as placeholder utility function is added considering possiblity of getting "caps" information via sysfs. If that doesn't exist, fallback to using auxv information. Signed-off-by:
-
Kajol Jain authored
In power10, threshold compare field is not part of the raw event code and provided via event attribute config1. Hence add the mask and shift bits based on event attribute config1, to extract the threshold compare value for power10 Also add a new function called get_thresh_cmp_val to compute and return the threshold compare field for a given platform, since incase of power10, threshold compare value provided is decimal. Signed-off-by:
-
Athira Rajeev authored
powerpc/perf: Optimize clearing the pending PMI and remove WARN_ON for PMI check in power_pmu_disable commit 2c9ac51b ("powerpc/perf: Fix PMU callbacks to clear pending PMI before resetting an overflown PMC") added a new function "pmi_irq_pending" in hw_irq.h. This function is to check if there is a PMI marked as pending in Paca (PACA_IRQ_PMI).This is used in power_pmu_disable in a WARN_ON. The intention here is to provide a warning if there is PMI pending, but no counter is found overflown. During some of the perf runs, below warning is hit: WARNING: CPU: 36 PID: 0 at arch/powerpc/perf/core-book3s.c:1332 power_pmu_disable+0x25c/0x2c0 Modules linked in: ----- NIP [c000000000141c3c] power_pmu_disable+0x25c/0x2c0 LR [c000000000141c8c] power_pmu_disable+0x2ac/0x2c0 Call Trace: [c000000baffcfb90] [c000000000141c8c] power_pmu_disable+0x2ac/0x2c0 (unreliable) [c000000baffcfc10] [c0000000003e2f8c] perf_pmu_disable+0x4c/0x60 [c000000baffcfc30] [c0000000003e3344] group_sched_out.part.124+0x44/0x100 [c000000baffcfc80] [c0000000003e353c] __perf_event_disable+0x13c/0x240 [c000000baffcfcd0] [c0000000003dd334] event_function+0xc4/0x140 [c000000baffcfd20] [c0000000003d855c] remote_function+0x7c/0xa0 [c000000baffcfd50] [c00000000026c394] flush_smp_call_function_queue+0xd4/0x300 [c000000baffcfde0] [c000000000065b24] smp_ipi_demux_relaxed+0xa4/0x100 [c000000baffcfe20] [c0000000000cb2b0] xive_muxed_ipi_action+0x20/0x40 [c000000baffcfe40] [c000000000207c3c] __handle_irq_event_percpu+0x8c/0x250 [c000000baffcfee0] [c000000000207e2c] handle_irq_event_percpu+0x2c/0xa0 [c000000baffcff10] [c000000000210a04] handle_percpu_irq+0x84/0xc0 [c000000baffcff40] [c000000000205f14] generic_handle_irq+0x54/0x80 [c000000baffcff60] [c000000000015740] __do_irq+0x90/0x1d0 [c000000baffcff90] [c000000000016990] __do_IRQ+0xc0/0x140 [c0000009732f3940] [c000000bafceaca8] 0xc000000bafceaca8 [c0000009732f39d0] [c000000000016b78] do_IRQ+0x168/0x1c0 [c0000009732f3a00] [c0000000000090c8] hardware_interrupt_common_virt+0x218/0x220 This means that there is no PMC overflown among the active events in the PMU, but there is a PMU pending in Paca. The function "any_pmc_overflown" checks the PMCs on active events in cpuhw->n_events. Code snippet: <<>> if (any_pmc_overflown(cpuhw)) clear_pmi_irq_pending(); else WARN_ON(pmi_irq_pending()); <<>> Here the PMC overflown is not from active event. Example: When we do perf record, default cycles and instructions will be running on PMC6 and PMC5 respectively. It could happen that overflowed event is currently not active and pending PMI is for the inactive event. Debug logs from trace_printk: <<>> any_pmc_overflown: idx is 5: pmc value is 0xd9a power_pmu_disable: PMC1: 0x0, PMC2: 0x0, PMC3: 0x0, PMC4: 0x0, PMC5: 0xd9a, PMC6: 0x80002011 <<>> Here active PMC (from idx) is PMC5 , but overflown PMC is PMC6(0x80002011). When we handle PMI interrupt for such cases, if the PMC overflown is from inactive event, it will be ignored. Reference commit: commit bc09c219 ("powerpc/perf: Fix finding overflowed PMC in interrupt") Patch addresses two changes: 1) Fix 1 : Removal of warning ( WARN_ON(pmi_irq_pending()); ) We were printing warning if no PMC is found overflown among active PMU events, but PMI pending in PACA. But this could happen in cases where PMC overflown is not in active PMC. An inactive event could have caused the overflow. Hence the warning is not needed. To know pending PMI is from an inactive event, we need to loop through all PMC's which will cause more SPR reads via mfspr and increase in context switch. Also in existing function: perf_event_interrupt, already we ignore PMI's overflown when it is from an inactive PMC. 2) Fix 2: optimization in clearing pending PMI. Currently we check for any active PMC overflown before clearing PMI pending in Paca. This is causing additional SPR read also. From point 1, we know that if PMI pending in Paca from inactive cases, that is going to be ignored during replay. Hence if there is pending PMI in Paca, just clear it irrespective of PMC overflown or not. In summary, remove the any_pmc_overflown check entirely in power_pmu_disable. ie If there is a pending PMI in Paca, clear it, since we are in pmu_disable. There could be cases where PMI is pending because of inactive PMC ( which later when replayed also will get ignored ), so WARN_ON could give false warning. Hence removing it. Fixes: 2c9ac51b ("powerpc/perf: Fix PMU callbacks to clear pending PMI before resetting an overflown PMC") Signed-off-by:
-
- 26 Jun, 2022 3 commits
-
-
Christophe Leroy authored
note_scsi_host() has been an empty function since commit 6ee0d9f7 ("[POWERPC] Remove unused old code from powermac setup code"). Remove it. Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by:
-
Michael Ellerman authored
This header was recently cleaned up in commit 76222808 ("powerpc: Move C prototypes out of asm-prototypes.h"), update the comment to reflect it's proper purpose. Signed-off-by:
-
Michael Ellerman authored
Older machines don't have the firmware feature that enables the code this test is testing. Skip the test if the sysfs directory doesn't exist. Also use the FAIL_IF() macro to provide more verbose error reporting if an error is encountered. Fixes: 57201d65 ("selftest/powerpc: Add PAPR sysfs attributes sniff test") Signed-off-by:
-
- 22 Jun, 2022 2 commits
-
-
Andy Shevchenko authored
Let GPIO library assign of_node from the parent device. This allows to move GPIO library and drivers to use fwnode APIs instead of being stuck with OF-only interfaces. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
Andy Shevchenko authored
Switch mpc5xxx_get_bus_frequency() to use fwnode in order to help cleaning up other parts of the kernel from OF specific code. No functional change intended. Signed-off-by:
Mark Brown <broonie@kernel.org> Acked-by: Marc Kleine-Budde <mkl@pengutronix.de> # for mscan/mpc5xxx_can Acked-by:
Damien Le Moal <damien.lemoal@opensource.wdc.com> Signed-off-by:
-
