On Tue, May 23, 2023 at 10:15:47AM +0530, 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.4-rc3. > Tested on Juno with some hacked up UEFI f/w. Tested-by: Sudeep Holla <sudeep.holla@xxxxxxx> -- Regards, Sudeep
