arch/arm64/include/asm/acpi.h | 3 + drivers/hwtracing/coresight/coresight-trbe.c | 26 +++- drivers/hwtracing/coresight/coresight-trbe.h | 2 + drivers/perf/arm_pmu_acpi.c | 142 ++++++++++++++----- include/linux/perf/arm_pmu.h | 1 + 5 files changed, 132 insertions(+), 42 deletions(-)
This series enables detection of ACPI based TRBE devices via a stand alone purpose built representative platform device. But as a pre-requisite this changes coresight_platform_data structure assignment for the TRBE device. This series is based on v6.5-rc5 kernel, is also dependent on the following EDK2 changes posted earlier by Sami. https://edk2.groups.io/g/devel/message/107239 https://edk2.groups.io/g/devel/message/107241 Changes in V5: - Detected zeroed parsed GSI as a mismatch but handled all zero scenario - Changed condition check from 'if (ret < 0)' into a 'if (ret)' - Dropped pr_warn() message after platform_device_register() Changes in V4: https://lore.kernel.org/all/20230808082247.383405-1-anshuman.khandual@arm.com/ - Added in-code comment for arm_trbe_device_probe() - Reverted back using IS_ENABLED() for SPE PMU platform device - Replaced #ifdef with IS_ENABLED() for TRBE platform device - Protected arm_trbe_acpi_match with ACPI_PTR() - preventing a build failure when CONFIG_ACPI is not enabled - Added __maybe_unused for arm_acpi_register_pmu_device() and dropped config checks with IS_ENABLED() Changes in V3: https://lore.kernel.org/all/20230803055652.1322801-1-anshuman.khandual@arm.com/ - Changed ARMV8_TRBE_PDEV_NAME from "arm-trbe-acpi" into "arm,trbe" - Dropped local variable 'matched' - Replaced 'matched' with 'valid gsi' as being already matched once - Moved find_acpi_cpu_topology_hetero_id() outside conditional check Changes in V2: https://lore.kernel.org/all/20230801094052.750416-1-anshuman.khandual@arm.com/ - Refactored arm_spe_acpi_register_device() in a separate patch - Renamed trbe_acpi_resources as trbe_resources - Renamed trbe_acpi_dev as trbe_dev Changes in V1: https://lore.kernel.org/all/20230728112733.359620-1-anshuman.khandual@arm.com/ Cc: Sami Mujawar <sami.mujawar@arm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Suzuki K Poulose <suzuki.poulose@arm.com> Cc: Mike Leach <mike.leach@linaro.org> Cc: Leo Yan <leo.yan@linaro.org> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: James Clark <james.clark@arm.com> Cc: coresight@lists.linaro.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-kernel@vger.kernel.org Anshuman Khandual (4): arm_pmu: acpi: Refactor arm_spe_acpi_register_device() arm_pmu: acpi: Add a representative platform device for TRBE coresight: trbe: Add a representative coresight_platform_data for TRBE coresight: trbe: Enable ACPI based TRBE devices arch/arm64/include/asm/acpi.h | 3 + drivers/hwtracing/coresight/coresight-trbe.c | 26 +++- drivers/hwtracing/coresight/coresight-trbe.h | 2 + drivers/perf/arm_pmu_acpi.c | 142 ++++++++++++++----- include/linux/perf/arm_pmu.h | 1 + 5 files changed, 132 insertions(+), 42 deletions(-) -- 2.25.1
On Thu, 17 Aug 2023 11:24:01 +0530, Anshuman Khandual wrote:
> This series enables detection of ACPI based TRBE devices via a stand alone
> purpose built representative platform device. But as a pre-requisite this
> changes coresight_platform_data structure assignment for the TRBE device.
>
> This series is based on v6.5-rc5 kernel, is also dependent on the following
> EDK2 changes posted earlier by Sami.
>
> [...]
Applied to will (for-next/perf), thanks!
[1/4] arm_pmu: acpi: Refactor arm_spe_acpi_register_device()
https://git.kernel.org/will/c/81e5ee471609
[2/4] arm_pmu: acpi: Add a representative platform device for TRBE
https://git.kernel.org/will/c/1aa3d0274a4a
[3/4] coresight: trbe: Add a representative coresight_platform_data for TRBE
https://git.kernel.org/will/c/e926b8e9eb40
[4/4] coresight: trbe: Enable ACPI based TRBE devices
https://git.kernel.org/will/c/0fb93c5ede13
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
On 8/18/23 23:34, Will Deacon wrote: > On Thu, 17 Aug 2023 11:24:01 +0530, Anshuman Khandual wrote: >> This series enables detection of ACPI based TRBE devices via a stand alone >> purpose built representative platform device. But as a pre-requisite this >> changes coresight_platform_data structure assignment for the TRBE device. >> >> This series is based on v6.5-rc5 kernel, is also dependent on the following >> EDK2 changes posted earlier by Sami. >> >> [...] > > Applied to will (for-next/perf), thanks! > > [1/4] arm_pmu: acpi: Refactor arm_spe_acpi_register_device() > https://git.kernel.org/will/c/81e5ee471609 > [2/4] arm_pmu: acpi: Add a representative platform device for TRBE > https://git.kernel.org/will/c/1aa3d0274a4a It seems like the above two changes are still going in for 6.6-rc1 ? I could see these in arm64/for-next/core and latest linux-next next-20230825. > [3/4] coresight: trbe: Add a representative coresight_platform_data for TRBE > https://git.kernel.org/will/c/e926b8e9eb40 > [4/4] coresight: trbe: Enable ACPI based TRBE devices > https://git.kernel.org/will/c/0fb93c5ede13 > > Cheers,
On Mon, Aug 28, 2023 at 08:11:41AM +0530, Anshuman Khandual wrote: > > > On 8/18/23 23:34, Will Deacon wrote: > > On Thu, 17 Aug 2023 11:24:01 +0530, Anshuman Khandual wrote: > >> This series enables detection of ACPI based TRBE devices via a stand alone > >> purpose built representative platform device. But as a pre-requisite this > >> changes coresight_platform_data structure assignment for the TRBE device. > >> > >> This series is based on v6.5-rc5 kernel, is also dependent on the following > >> EDK2 changes posted earlier by Sami. > >> > >> [...] > > > > Applied to will (for-next/perf), thanks! > > > > [1/4] arm_pmu: acpi: Refactor arm_spe_acpi_register_device() > > https://git.kernel.org/will/c/81e5ee471609 > > [2/4] arm_pmu: acpi: Add a representative platform device for TRBE > > https://git.kernel.org/will/c/1aa3d0274a4a > > It seems like the above two changes are still going in for 6.6-rc1 ? I could > see these in arm64/for-next/core and latest linux-next next-20230825. Yes, as I said, I only dropped the coresight bits. Will
On 28/08/2023 17:30, Will Deacon wrote: > On Mon, Aug 28, 2023 at 08:11:41AM +0530, Anshuman Khandual wrote: >> >> >> On 8/18/23 23:34, Will Deacon wrote: >>> On Thu, 17 Aug 2023 11:24:01 +0530, Anshuman Khandual wrote: >>>> This series enables detection of ACPI based TRBE devices via a stand alone >>>> purpose built representative platform device. But as a pre-requisite this >>>> changes coresight_platform_data structure assignment for the TRBE device. >>>> >>>> This series is based on v6.5-rc5 kernel, is also dependent on the following >>>> EDK2 changes posted earlier by Sami. >>>> >>>> [...] >>> >>> Applied to will (for-next/perf), thanks! >>> >>> [1/4] arm_pmu: acpi: Refactor arm_spe_acpi_register_device() >>> https://git.kernel.org/will/c/81e5ee471609 >>> [2/4] arm_pmu: acpi: Add a representative platform device for TRBE >>> https://git.kernel.org/will/c/1aa3d0274a4a >> >> It seems like the above two changes are still going in for 6.6-rc1 ? I could >> see these in arm64/for-next/core and latest linux-next next-20230825. > > Yes, as I said, I only dropped the coresight bits. Ok, then I can pick up coresight changes via my tree and push it to Greg. Suzuki > > Will
Hi Will On 18/08/2023 19:04, Will Deacon wrote: > On Thu, 17 Aug 2023 11:24:01 +0530, Anshuman Khandual wrote: >> This series enables detection of ACPI based TRBE devices via a stand alone >> purpose built representative platform device. But as a pre-requisite this >> changes coresight_platform_data structure assignment for the TRBE device. >> >> This series is based on v6.5-rc5 kernel, is also dependent on the following >> EDK2 changes posted earlier by Sami. >> >> [...] > > Applied to will (for-next/perf), thanks! > > [1/4] arm_pmu: acpi: Refactor arm_spe_acpi_register_device() > https://git.kernel.org/will/c/81e5ee471609 > [2/4] arm_pmu: acpi: Add a representative platform device for TRBE > https://git.kernel.org/will/c/1aa3d0274a4a > [3/4] coresight: trbe: Add a representative coresight_platform_data for TRBE > https://git.kernel.org/will/c/e926b8e9eb40 This will conflict with what I have (already) sent to Greg for coresight/next. Please let me know how you would like handle it Suzuki > [4/4] coresight: trbe: Enable ACPI based TRBE devices > https://git.kernel.org/will/c/0fb93c5ede13 > > Cheers,
On Sat, Aug 19, 2023 at 08:36:28AM +0100, Suzuki K Poulose wrote:
> On 18/08/2023 19:04, Will Deacon wrote:
> > On Thu, 17 Aug 2023 11:24:01 +0530, Anshuman Khandual wrote:
> > > This series enables detection of ACPI based TRBE devices via a stand alone
> > > purpose built representative platform device. But as a pre-requisite this
> > > changes coresight_platform_data structure assignment for the TRBE device.
> > >
> > > This series is based on v6.5-rc5 kernel, is also dependent on the following
> > > EDK2 changes posted earlier by Sami.
> > >
> > > [...]
> >
> > Applied to will (for-next/perf), thanks!
> >
> > [1/4] arm_pmu: acpi: Refactor arm_spe_acpi_register_device()
> > https://git.kernel.org/will/c/81e5ee471609
> > [2/4] arm_pmu: acpi: Add a representative platform device for TRBE
> > https://git.kernel.org/will/c/1aa3d0274a4a
> > [3/4] coresight: trbe: Add a representative coresight_platform_data for TRBE
> > https://git.kernel.org/will/c/e926b8e9eb40
>
> This will conflict with what I have (already) sent to Greg for
> coresight/next. Please let me know how you would like handle it
Hmm, the rationale behind your change to make the pdata allocation
per-device in ("coresight: trbe: Allocate platform data per device")
confuses me: with Anshuman's change to allocate the pdata using
devm_kzalloc(), there shouldn't be any connections for the coresight
core to trip over, should there?
It would've been nice to know about the conflict earlier, but since I
think you're away this week and we're likely to hit the merge window
next week, I'm going to drop the coresight patches for now.
Will
On 21/08/2023 12:28, Will Deacon wrote:
> On Sat, Aug 19, 2023 at 08:36:28AM +0100, Suzuki K Poulose wrote:
>> On 18/08/2023 19:04, Will Deacon wrote:
>>> On Thu, 17 Aug 2023 11:24:01 +0530, Anshuman Khandual wrote:
>>>> This series enables detection of ACPI based TRBE devices via a stand alone
>>>> purpose built representative platform device. But as a pre-requisite this
>>>> changes coresight_platform_data structure assignment for the TRBE device.
>>>>
>>>> This series is based on v6.5-rc5 kernel, is also dependent on the following
>>>> EDK2 changes posted earlier by Sami.
>>>>
>>>> [...]
>>>
>>> Applied to will (for-next/perf), thanks!
>>>
>>> [1/4] arm_pmu: acpi: Refactor arm_spe_acpi_register_device()
>>> https://git.kernel.org/will/c/81e5ee471609
>>> [2/4] arm_pmu: acpi: Add a representative platform device for TRBE
>>> https://git.kernel.org/will/c/1aa3d0274a4a
>>> [3/4] coresight: trbe: Add a representative coresight_platform_data for TRBE
>>> https://git.kernel.org/will/c/e926b8e9eb40
>>
>> This will conflict with what I have (already) sent to Greg for
>> coresight/next. Please let me know how you would like handle it
>
> Hmm, the rationale behind your change to make the pdata allocation
> per-device in ("coresight: trbe: Allocate platform data per device")
> confuses me: with Anshuman's change to allocate the pdata using
> devm_kzalloc(), there shouldn't be any connections for the coresight
> core to trip over, should there?
Anshuman's patch is working around the problem of "TRBE platform
device with ACPI doesn't have a valid companion device" - this is a
problem for the acpi_get_coresight_platform_data(). The work
around is to move the "allocation" from coresight_get_platform_data()
to the driver (given we don't need anything else from the ACPI except
the IRQ). That doesn't change *how* it is allocated.
Also please note that, the TRBE driver creates a TRBE coresight_device
per-CPU and the platform data is shared by all of these devices, which
the coresight core driver doesn't cope with. The other option is to
move the releasing of these platform-data to the individual drivers,
which is quite an invasive change. Or, make the core driver tolerate
a NULL platform data, which is also again invasive. So the merged fix
is correct and is still valid after this patch.
>
> It would've been nice to know about the conflict earlier, but since I
> think you're away this week and we're likely to hit the merge window
> next week, I'm going to drop the coresight patches for now.
Apologies, I was expecting to queue the changes via coresight tree,
given how it was affecting the tree and was awaiting your Ack. However
I didn't confirm it on the list, which is my mistake.
The other problem was reported and the fix eventually had to
conflict with Anshuman's series, which he was made aware of.
Given, your Ack was missing I hoping that Anshuman could respin
the series with your Ack on top of the fix and eventually queue
that via my tree.
Suzuki
>
> Will
On Sun, Aug 27, 2023 at 11:11:16PM +0100, Suzuki K Poulose wrote:
> On 21/08/2023 12:28, Will Deacon wrote:
> > Hmm, the rationale behind your change to make the pdata allocation
> > per-device in ("coresight: trbe: Allocate platform data per device")
> > confuses me: with Anshuman's change to allocate the pdata using
> > devm_kzalloc(), there shouldn't be any connections for the coresight
> > core to trip over, should there?
>
> Anshuman's patch is working around the problem of "TRBE platform
> device with ACPI doesn't have a valid companion device" - this is a problem
> for the acpi_get_coresight_platform_data(). The work
> around is to move the "allocation" from coresight_get_platform_data()
> to the driver (given we don't need anything else from the ACPI except
> the IRQ). That doesn't change *how* it is allocated.
> Also please note that, the TRBE driver creates a TRBE coresight_device
> per-CPU and the platform data is shared by all of these devices, which
> the coresight core driver doesn't cope with. The other option is to
> move the releasing of these platform-data to the individual drivers,
> which is quite an invasive change. Or, make the core driver tolerate
> a NULL platform data, which is also again invasive. So the merged fix
> is correct and is still valid after this patch.
Ah, ok, so the problem with TRBE isn't anything to do with its connections,
but simply because the pdata is shared?
Will
On 28/08/2023 22:35, Will Deacon wrote:
> On Sun, Aug 27, 2023 at 11:11:16PM +0100, Suzuki K Poulose wrote:
>> On 21/08/2023 12:28, Will Deacon wrote:
>>> Hmm, the rationale behind your change to make the pdata allocation
>>> per-device in ("coresight: trbe: Allocate platform data per device")
>>> confuses me: with Anshuman's change to allocate the pdata using
>>> devm_kzalloc(), there shouldn't be any connections for the coresight
>>> core to trip over, should there?
>>
>> Anshuman's patch is working around the problem of "TRBE platform
>> device with ACPI doesn't have a valid companion device" - this is a problem
>> for the acpi_get_coresight_platform_data(). The work
>> around is to move the "allocation" from coresight_get_platform_data()
>> to the driver (given we don't need anything else from the ACPI except
>> the IRQ). That doesn't change *how* it is allocated.
>> Also please note that, the TRBE driver creates a TRBE coresight_device
>> per-CPU and the platform data is shared by all of these devices, which
>> the coresight core driver doesn't cope with. The other option is to
>> move the releasing of these platform-data to the individual drivers,
>> which is quite an invasive change. Or, make the core driver tolerate
>> a NULL platform data, which is also again invasive. So the merged fix
>> is correct and is still valid after this patch.
>
> Ah, ok, so the problem with TRBE isn't anything to do with its connections,
> but simply because the pdata is shared?
Correct, thats an issue outside of the ACPI support. With ACPI, the
coresight_get_platform_data() can't cope with the TRBE with missing
companion device, that is fixed by Anshuman's patch in this series.
Also, please could you confirm the plan forward for merging this
(next version of course) ?
Cheers
Suzuki
>
> Will
On 8/28/23 03:41, Suzuki K Poulose wrote:
> On 21/08/2023 12:28, Will Deacon wrote:
>> On Sat, Aug 19, 2023 at 08:36:28AM +0100, Suzuki K Poulose wrote:
>>> On 18/08/2023 19:04, Will Deacon wrote:
>>>> On Thu, 17 Aug 2023 11:24:01 +0530, Anshuman Khandual wrote:
>>>>> This series enables detection of ACPI based TRBE devices via a stand alone
>>>>> purpose built representative platform device. But as a pre-requisite this
>>>>> changes coresight_platform_data structure assignment for the TRBE device.
>>>>>
>>>>> This series is based on v6.5-rc5 kernel, is also dependent on the following
>>>>> EDK2 changes posted earlier by Sami.
>>>>>
>>>>> [...]
>>>>
>>>> Applied to will (for-next/perf), thanks!
>>>>
>>>> [1/4] arm_pmu: acpi: Refactor arm_spe_acpi_register_device()
>>>> https://git.kernel.org/will/c/81e5ee471609
>>>> [2/4] arm_pmu: acpi: Add a representative platform device for TRBE
>>>> https://git.kernel.org/will/c/1aa3d0274a4a
>>>> [3/4] coresight: trbe: Add a representative coresight_platform_data for TRBE
>>>> https://git.kernel.org/will/c/e926b8e9eb40
>>>
>>> This will conflict with what I have (already) sent to Greg for
>>> coresight/next. Please let me know how you would like handle it
>>
>> Hmm, the rationale behind your change to make the pdata allocation
>> per-device in ("coresight: trbe: Allocate platform data per device")
>> confuses me: with Anshuman's change to allocate the pdata using
>> devm_kzalloc(), there shouldn't be any connections for the coresight
>> core to trip over, should there?
>
> Anshuman's patch is working around the problem of "TRBE platform
> device with ACPI doesn't have a valid companion device" - this is a problem for the acpi_get_coresight_platform_data(). The work
> around is to move the "allocation" from coresight_get_platform_data()
> to the driver (given we don't need anything else from the ACPI except
> the IRQ). That doesn't change *how* it is allocated.
> Also please note that, the TRBE driver creates a TRBE coresight_device per-CPU and the platform data is shared by all of these devices, which
> the coresight core driver doesn't cope with. The other option is to
> move the releasing of these platform-data to the individual drivers,
> which is quite an invasive change. Or, make the core driver tolerate
> a NULL platform data, which is also again invasive. So the merged fix
> is correct and is still valid after this patch.
>
>>
>> It would've been nice to know about the conflict earlier, but since I
>> think you're away this week and we're likely to hit the merge window
>> next week, I'm going to drop the coresight patches for now.
>
> Apologies, I was expecting to queue the changes via coresight tree,
> given how it was affecting the tree and was awaiting your Ack. However
> I didn't confirm it on the list, which is my mistake.
>
> The other problem was reported and the fix eventually had to
> conflict with Anshuman's series, which he was made aware of.
> Given, your Ack was missing I hoping that Anshuman could respin
> the series with your Ack on top of the fix and eventually queue
> that via my tree.
As Will had picked up the series for arm64 tree, I had assumed that the
conflict fix will be taken care of in the process. Hence did not resend
the series, but it got suddenly dropped.
I am wondering - would it be worth re-spinning the series now fixing the
conflict, does it even have a chance for 6.6-rc1 ? Otherwise, will respin
the series after the merge window is over.
© 2016 - 2025 Red Hat, Inc.