On Fri, Mar 17, 2023 at 11:03 AM Suzuki K Poulose <suzuki.poulose@xxxxxxx> wrote: > > Hi Rob > > Thanks for your response. > > On 17/03/2023 14:52, Rob Herring wrote: > > On Thu, Mar 16, 2023 at 10:06 PM Anshuman Khandual > > <anshuman.khandual@xxxxxxx> wrote: > >> > >> Allow other drivers to claim a device, disregarding the "priority" of > >> "arm,primecell". e.g., CoreSight ETM4x devices could be accessed via MMIO > >> (AMBA Bus) or via CPU system instructions. > > > > The OS can pick which one, use both, or this is a system integration > > time decision? > > Not an OS choice. Historically, this has always been MMIO accessed but > with v8.4 TraceFiltering support, CPUs are encouraged to use system > instructions and obsolete MMIO. So, yes, MMIO is still possible but > something that is discouraged and have to be decided at system > integration time. > > > > >> The CoreSight ETM4x platform > >> driver can now handle both types of devices. In order to make sure the > >> driver gets to handle the "MMIO based" devices, which always had the > >> "arm,primecell" compatible, we have two options : > >> > >> 1) Remove the "arm,primecell" from the DTS. But this may be problematic > >> for an older kernel without the support. > >> > >> 2) The other option is to allow OF code to "ignore" the arm,primecell > >> priority for a selected list of compatibles. This would make sure that > >> both older kernels and the new kernels work fine without breaking > >> the functionality. The new DTS could always have the "arm,primecell" > >> removed. > > > > 3) Drop patches 6 and 7 and just register as both AMBA and platform > > drivers. It's just some extra boilerplate. I would also do different > > compatible strings for CPU system instruction version (assuming this > > is an integration time decision). > > The system instruction (and the reigster layouts) are all part of the > ETMv4/ETE architecture and specific capabilities/features are > discoverable, just like the Arm CPUs. Thus we don't need special > versions within the ETMv4x or ETE minor versions. As of now, we have > one for etm4x and another for ete. I just meant 2 new compatible strings. One each for ETMv4x and ETE, but different from the 2 existing ones. It is different h/w presented to the OS, so different compatible. > One problem with the AMBA driver in place is having to keep on adding > new PIDs for the CPUs. The other option is to have a blanket mask > for matching the PIDs with AMBA_UCI_ID checks. But if MMIO access is discouraged, then new h/w would use the platform driver(s), not the amba driver, and you won't have to add PIDs. Rob
