Cc: Sudeep
Hi Suzuki,
Hi Tanmay
Hi Anshuman,
On 2024-03-14 at 11:28:32, Anshuman Khandual (anshuman.khandual(a)arm.com) wrote:
This moves remaining AMBA ACPI devices into respective platform drivers for enabling ACPI based power management support. This series applies on latest coresight next. This series has been built, and boot tested on a DT based (RB5) and ACPI supported coresight platform (N1SDP).
I have tested this patch series on Marvell platform with ACPI and DT support.
On platforms that have a dedicated sink (ETF/ETR) for every source, when we boot with fewer cores, the per-core sinks (ETF/ETR) are still probed successfully.
Thank you for testing, could we add your Tested-by: tag to the series ?
Yes sure.
Tested-by: Tanmay Jagdale <tanmay(a)marvell.com>
Ansuhman, Suzuki, James,
Would be helpful if we add a notion of associated CPU to the TMC core driver? So that, if the associated CPU is powered off, the TMC ETF/ETR device would not be probed.
Doing this in a generic way (i.e., "not probing" devices with missing devices is complicated). What exactly is the concern here ? "power consumption" or "devices that cannot be used without the source devices" ?
Yeah the concern is regarding devices that cannot be used without the source devices. They would be visible in sysfs and unusable. Our platform has a fixed-clock common clock for Coresight but on other platforms that support clock gating, power consumption could be a concern.
Prior to this patch series, the acpi/arm64/amba.c created a dummy apb_pclk and then hooked into the AMBA subsystem. Now, we have to provide the clock information via ACPI tables. Or, we have an option to not provide any clock information and continue as is.
Is this understanding correct ?
You don't need to add the Clock in the ACPI tables, if that is taken care of by the firmware (e.g., Turned on always or dynamically by the ACPI PM)
Sudeep, please correct me if I am wrong above ^.
The driver now ignores the absence of an explicit apb_clk, please let us know if that isn't the case. If a clock is present, the driver would try to enable it.
Okay. Thanks for the clarification. We have a fixed clock on our platform and we haven't mentioned any clock explicity in ACPI table. Able to collect Coresight traces with this patch series.
We already have a concept of "orphan" devices (i.e., with missing connection links). But we need the devices probed to have this information!
How are these CPUs connected to the TMC ? are there any funnels/links in between them ? If we have to walk the connection link up the trace path, that could be complicated.
On our platform, the ETF devices are directly connected to the cores, and then there is a funnel which collects inputs and routes them to a common ETR.
That makes it complicated, as we have to walk up the path from "a device" we are trying to probe and keep track of the dependencies and then re-trigger the probe when dependent devices turn up. Like I said, it is not worth the efforts.
Yes agree, it would become complicated.
Thanks, Tanmay
Suzuki
The best we could do is expose if a device is still orphan or not via sysfs. I guess that doesn't take us anywhere much.
Yeah agree.
Thanks and regards, Tanmay
Suzuki