public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Anshuman Khandual <anshuman.khandual@arm.com>
To: linux-arm-kernel@lists.infradead.org, suzuki.poulose@arm.com
Cc: Sami Mujawar <sami.mujawar@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Mike Leach <mike.leach@linaro.org>, Leo Yan <leo.yan@linaro.org>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	James Clark <james.clark@arm.com>,
	coresight@lists.linaro.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH V3 2/4] arm_pmu: acpi: Add a representative platform device for TRBE
Date: Fri, 4 Aug 2023 15:31:24 +0530	[thread overview]
Message-ID: <0c26e6cc-d75a-e89f-4ecc-54170df2ed47@arm.com> (raw)
In-Reply-To: <20230803055652.1322801-3-anshuman.khandual@arm.com>



On 8/3/23 11:26, Anshuman Khandual wrote:
> ACPI TRBE does not have a HID for identification which could create and add
> a platform device into the platform bus. Also without a platform device, it
> cannot be probed and bound to a platform driver.
> 
> This creates a dummy platform device for TRBE after ascertaining that ACPI
> provides required interrupts uniformly across all cpus on the system. This
> device gets created inside drivers/perf/arm_pmu_acpi.c to accommodate TRBE
> being built as a module.
> 
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
> ---
>  arch/arm64/include/asm/acpi.h |  3 +++
>  drivers/perf/arm_pmu_acpi.c   | 37 ++++++++++++++++++++++++++++++++++-
>  include/linux/perf/arm_pmu.h  |  1 +
>  3 files changed, 40 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
> index bd68e1b7f29f..4d537d56eb84 100644
> --- a/arch/arm64/include/asm/acpi.h
> +++ b/arch/arm64/include/asm/acpi.h
> @@ -42,6 +42,9 @@
>  #define ACPI_MADT_GICC_SPE  (offsetof(struct acpi_madt_generic_interrupt, \
>  	spe_interrupt) + sizeof(u16))
>  
> +#define ACPI_MADT_GICC_TRBE  (offsetof(struct acpi_madt_generic_interrupt, \
> +	trbe_interrupt) + sizeof(u16))
> +
>  /* Basic configuration for ACPI */
>  #ifdef	CONFIG_ACPI
>  pgprot_t __acpi_get_mem_attribute(phys_addr_t addr);
> diff --git a/drivers/perf/arm_pmu_acpi.c b/drivers/perf/arm_pmu_acpi.c
> index 235c14766a36..79feea548e6e 100644
> --- a/drivers/perf/arm_pmu_acpi.c
> +++ b/drivers/perf/arm_pmu_acpi.c
> @@ -69,7 +69,7 @@ static void arm_pmu_acpi_unregister_irq(int cpu)
>  		acpi_unregister_gsi(gsi);
>  }
>  
> -#if IS_ENABLED(CONFIG_ARM_SPE_PMU)
> +#if IS_ENABLED(CONFIG_ARM_SPE_PMU) || IS_ENABLED(CONFIG_CORESIGHT_TRBE)

Rather than adding IS_ENABLED() checks for all applicable configs in future
which will need to call arm_acpi_register_pmu_device() for a dummy platform
device, could we instead just add __maybe_unused for the function to prevent
build warning when there are no call sites ? Seems bit better and simpler.

>  static int
>  arm_acpi_register_pmu_device(struct platform_device *pdev, u8 len,
>  			     u16 (*parse_gsi)(struct acpi_madt_generic_interrupt *))
> @@ -166,6 +166,40 @@ static inline void arm_spe_acpi_register_device(void)
>  }
>  #endif /* CONFIG_ARM_SPE_PMU */
>  
> +#ifdef CONFIG_CORESIGHT_TRBE
> +static struct resource trbe_resources[] = {
> +	{
> +		/* irq */
> +		.flags          = IORESOURCE_IRQ,
> +	}
> +};
> +
> +static struct platform_device trbe_dev = {
> +	.name = ARMV8_TRBE_PDEV_NAME,
> +	.id = -1,
> +	.resource = trbe_resources,
> +	.num_resources = ARRAY_SIZE(trbe_resources)
> +};
> +
> +static u16 arm_trbe_parse_gsi(struct acpi_madt_generic_interrupt *gicc)
> +{
> +	return gicc->trbe_interrupt;
> +}
> +
> +static void arm_trbe_acpi_register_device(void)
> +{
> +	int ret = arm_acpi_register_pmu_device(&trbe_dev, ACPI_MADT_GICC_TRBE,
> +					       arm_trbe_parse_gsi);
> +	if (ret)
> +		pr_warn("ACPI: TRBE: Unable to register device\n");
> +}
> +#else
> +static inline void arm_trbe_acpi_register_device(void)
> +{
> +
> +}
> +#endif /* CONFIG_CORESIGHT_TRBE */
> +
>  static int arm_pmu_acpi_parse_irqs(void)
>  {
>  	int irq, cpu, irq_cpu, err;
> @@ -401,6 +435,7 @@ static int arm_pmu_acpi_init(void)
>  		return 0;
>  
>  	arm_spe_acpi_register_device();
> +	arm_trbe_acpi_register_device();
>  
>  	return 0;
>  }
> diff --git a/include/linux/perf/arm_pmu.h b/include/linux/perf/arm_pmu.h
> index a0801f68762b..143fbc10ecfe 100644
> --- a/include/linux/perf/arm_pmu.h
> +++ b/include/linux/perf/arm_pmu.h
> @@ -187,5 +187,6 @@ void armpmu_free_irq(int irq, int cpu);
>  #endif /* CONFIG_ARM_PMU */
>  
>  #define ARMV8_SPE_PDEV_NAME "arm,spe-v1"
> +#define ARMV8_TRBE_PDEV_NAME "arm,trbe"
>  
>  #endif /* __ARM_PMU_H__ */

  parent reply	other threads:[~2023-08-04 10:02 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-03  5:56 [PATCH V3 0/4] coresight: trbe: Enable ACPI based devices Anshuman Khandual
2023-08-03  5:56 ` [PATCH V3 1/4] arm_pmu: acpi: Refactor arm_spe_acpi_register_device() Anshuman Khandual
2023-08-03  6:13   ` Anshuman Khandual
2023-08-04 16:39     ` Will Deacon
2023-08-07  5:33       ` Anshuman Khandual
2023-08-08 13:21         ` Will Deacon
2023-08-09  7:01           ` Anshuman Khandual
2023-08-03  5:56 ` [PATCH V3 2/4] arm_pmu: acpi: Add a representative platform device for TRBE Anshuman Khandual
2023-08-03  9:14   ` Yicong Yang
2023-08-04  9:34     ` Anshuman Khandual
2023-08-04 10:01   ` Anshuman Khandual [this message]
2023-08-03  5:56 ` [PATCH V3 3/4] coresight: trbe: Add a representative coresight_platform_data " Anshuman Khandual
2023-08-03 13:55   ` Suzuki K Poulose
2023-08-04  9:18     ` Anshuman Khandual
2023-08-04 10:04       ` Suzuki K Poulose
2023-08-03  5:56 ` [PATCH V3 4/4] coresight: trbe: Enable ACPI based TRBE devices Anshuman Khandual
2023-08-07  4:43   ` Anshuman Khandual
2023-08-07 11:37     ` Suzuki K Poulose
2023-08-07 11:58       ` Anshuman Khandual
2023-08-13 21:43   ` kernel test robot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0c26e6cc-d75a-e89f-4ecc-54170df2ed47@arm.com \
    --to=anshuman.khandual@arm.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=catalin.marinas@arm.com \
    --cc=coresight@lists.linaro.org \
    --cc=james.clark@arm.com \
    --cc=leo.yan@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mike.leach@linaro.org \
    --cc=sami.mujawar@arm.com \
    --cc=suzuki.poulose@arm.com \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox