[PATCH 6/7] of/platform: Skip coresight etm4x devices from AMBA bus

[Rob Herring]

On Fri, Mar 17, 2023 at 11:03 AM Suzuki K Poulose
<suzuki.poulose at arm.com> 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 at arm.com> 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