On 26/07/2023 18:03, Steve Clevenger OS wrote:
Hi Suzuki,
On 7/26/2023 9:59 AM, Suzuki K Poulose wrote:
On 10/07/2023 07:24, Anshuman Khandual wrote:
CoreSight ETM4x devices could be accessed either via MMIO (handled via amba_driver) or CPU system instructions (handled via platform driver). But this has the following issues :
- Each new CPU comes up with its own PID and thus we need to keep on adding the "known" PIDs to get it working with AMBA driver. While the ETM4 architecture (and CoreSight architecture) defines way to identify a device as ETM4. Thus older kernels won't be able to "discover" a newer CPU, unless we add the PIDs.
- With ACPI, the ETM4x devices have the same HID to identify the device irrespective of the mode of access. This creates a problem where two different drivers (both AMBA based driver and platform driver) would hook into the "HID" and could conflict. e.g., if AMBA driver gets hold of a non-MMIO device, the probe fails. If we have single driver hooked into the given "HID", we could handle them seamlessly, irrespective of the mode of access.
- CoreSight is heavily dependent on the runtime power management. With ACPI, amba_driver doesn't get us anywhere with handling the power and thus one need to always turn the power ON to use them. Moving to platform driver gives us the power management for free.
Due to all of the above, we are moving ACPI MMIO based etm4x devices to be supported via tha platform driver. The series makes the existing platform driver generic to handle both type of the access modes. Although existing AMBA driver would still continue to support DT based etm4x MMIO devices. Although some problems still remain, such as manually adding PIDs for all new AMBA DT based devices.
The series applies on 6.5-rc1.
Changes in V6:
- Rebased on 6.5-rc1
I have queued this version for v6.6, should appear on coresight/next soon.
Suzuki
Is there anyway to queue this for 6.5? Or has that ship sailed?
Only fixes are allowed for v6.5 at this time.
Suzuki
Thanks,
Steve C.