Hi all,
Today's linux-next merge of the risc-v tree got a conflict in:
drivers/perf/Kconfig
between commits:
c2b24812f7bc ("perf: starfive: Add StarLink PMU support")
f0dbc6d0de38 ("perf: starfive: Only allow COMPILE_TEST for 64-bit architectures")
from the arm64 tree and commit:
bc969d6cc96a ("perf: RISC-V: Introduce Andes PMU to support perf event sampling")
from the risc-v tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/perf/Kconfig
index 004d86230aa6,564e813d8c69..000000000000
--- a/drivers/perf/Kconfig
+++ b/drivers/perf/Kconfig
@@@ -86,15 -86,20 +86,29 @@@ config RISCV_PMU_SB
full perf feature support i.e. counter overflow, privilege mode
filtering, counter configuration.
+config STARFIVE_STARLINK_PMU
+ depends on ARCH_STARFIVE || (COMPILE_TEST && 64BIT)
+ bool "StarFive StarLink PMU"
+ help
+ Provide support for StarLink Performance Monitor Unit.
+ StarLink Performance Monitor Unit integrates one or more cores with
+ an L3 memory system. The L3 cache events are added into perf event
+ subsystem, allowing monitoring of various L3 cache perf events.
+
+ config ANDES_CUSTOM_PMU
+ bool "Andes custom PMU support"
+ depends on ARCH_RENESAS && RISCV_ALTERNATIVE && RISCV_PMU_SBI
+ default y
+ help
+ The Andes cores implement the PMU overflow extension very
+ similar to the standard Sscofpmf and Smcntrpmf extension.
+
+ This will patch the overflow and pending CSRs and handle the
+ non-standard behaviour via the regular SBI PMU driver and
+ interface.
+
+ If you don't know what to do here, say "Y".
+
config ARM_PMU_ACPI
depends on ARM_PMU && ACPI
def_bool y
On Thu, 14 Mar 2024 16:31:46 PDT (-0700), Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the risc-v tree got a conflict in:
>
> drivers/perf/Kconfig
>
> between commits:
>
> c2b24812f7bc ("perf: starfive: Add StarLink PMU support")
> f0dbc6d0de38 ("perf: starfive: Only allow COMPILE_TEST for 64-bit architectures")
>
> from the arm64 tree and commit:
>
> bc969d6cc96a ("perf: RISC-V: Introduce Andes PMU to support perf event sampling")
>
> from the risc-v tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
Sorry, I guess maybe I should have looked at my queue before agreeing to
send the starfive PMU patches via the arm64 tree. The Andes stuff
touches a bunch of other RISC-V bits, but I'm happy to do a shared tag
or something if folks want.
Otherwise I'll just point this out to Linus when I send my PR -- I'm
going to hold off on that this morning, as I just realized I should have
taken this GUP fix and thus want to let things bake a little longer.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc drivers/perf/Kconfig
> index 004d86230aa6,564e813d8c69..000000000000
> --- a/drivers/perf/Kconfig
> +++ b/drivers/perf/Kconfig
> @@@ -86,15 -86,20 +86,29 @@@ config RISCV_PMU_SB
> full perf feature support i.e. counter overflow, privilege mode
> filtering, counter configuration.
>
> +config STARFIVE_STARLINK_PMU
> + depends on ARCH_STARFIVE || (COMPILE_TEST && 64BIT)
> + bool "StarFive StarLink PMU"
> + help
> + Provide support for StarLink Performance Monitor Unit.
> + StarLink Performance Monitor Unit integrates one or more cores with
> + an L3 memory system. The L3 cache events are added into perf event
> + subsystem, allowing monitoring of various L3 cache perf events.
> +
> + config ANDES_CUSTOM_PMU
> + bool "Andes custom PMU support"
> + depends on ARCH_RENESAS && RISCV_ALTERNATIVE && RISCV_PMU_SBI
> + default y
> + help
> + The Andes cores implement the PMU overflow extension very
> + similar to the standard Sscofpmf and Smcntrpmf extension.
> +
> + This will patch the overflow and pending CSRs and handle the
> + non-standard behaviour via the regular SBI PMU driver and
> + interface.
> +
> + If you don't know what to do here, say "Y".
> +
> config ARM_PMU_ACPI
> depends on ARM_PMU && ACPI
> def_bool y
On Fri, Mar 15, 2024 at 10:21:13AM -0700, Palmer Dabbelt wrote:
> On Thu, 14 Mar 2024 16:31:46 PDT (-0700), Stephen Rothwell wrote:
> > Hi all,
> >
> > Today's linux-next merge of the risc-v tree got a conflict in:
> >
> > drivers/perf/Kconfig
> >
> > between commits:
> >
> > c2b24812f7bc ("perf: starfive: Add StarLink PMU support")
> > f0dbc6d0de38 ("perf: starfive: Only allow COMPILE_TEST for 64-bit architectures")
> >
> > from the arm64 tree and commit:
> >
> > bc969d6cc96a ("perf: RISC-V: Introduce Andes PMU to support perf event sampling")
> >
> > from the risc-v tree.
> >
> > I fixed it up (see below) and can carry the fix as necessary. This
> > is now fixed as far as linux-next is concerned, but any non trivial
> > conflicts should be mentioned to your upstream maintainer when your tree
> > is submitted for merging. You may also want to consider cooperating
> > with the maintainer of the conflicting tree to minimise any particularly
> > complex conflicts.
>
> Sorry, I guess maybe I should have looked at my queue before agreeing to
> send the starfive PMU patches via the arm64 tree. The Andes stuff touches a
> bunch of other RISC-V bits, but I'm happy to do a shared tag or something if
> folks want.
>
> Otherwise I'll just point this out to Linus when I send my PR -- I'm going
> to hold off on that this morning, as I just realized I should have taken
> this GUP fix and thus want to let things bake a little longer.
The arm64 tree went in yesterday already. If you want, you can merge
the arm64 for-next/perf tree into yours before sending the PR to Linus.
Otherwise, the conflict is trivial, just give Linus a heads-up.
--
Catalin