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

From: Rob Herring <robh+dt@kernel.org>
To: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Anshuman Khandual <anshuman.khandual@arm.com>,
	linux-arm-kernel@lists.infradead.org,
	 coresight@lists.linaro.org, scclevenger@os.amperecomputing.com,
	 Frank Rowand <frowand.list@gmail.com>,
	Russell King <linux@armlinux.org.uk>,
	 Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	 Len Brown <lenb@kernel.org>, Sudeep Holla <sudeep.holla@arm.com>,
	 Lorenzo Pieralisi <lpieralisi@kernel.org>,
	Mathieu Poirier <mathieu.poirier@linaro.org>,
	 Mike Leach <mike.leach@linaro.org>, Leo Yan <leo.yan@linaro.org>,
	devicetree@vger.kernel.org,  linux-acpi@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 6/7] of/platform: Skip coresight etm4x devices from AMBA bus
Date: Fri, 17 Mar 2023 15:06:45 -0500	[thread overview]
Message-ID: <CAL_JsqKQWL4Y9zZj5x11QUB=8N9GLKo26EX=fVxXes_gShYf7Q@mail.gmail.com> (raw)
In-Reply-To: <b1518e16-d74b-719c-a0fc-bc172a6011c4@arm.com>

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel