[PATCH 0/3] Ampere Computing ETMv4.x Support

[Steve Clevenger]

Hi Suzuki,

Comments inline.

Steve

On 3/7/2023 2:21 AM, Suzuki K Poulose wrote:
> Hi Steve
> 
> On 07/03/2023 01:23, Steve Clevenger wrote:
>>
>> Hi Suzuki,
>>
>> To answer your question, Ampere plans to use the existing MMIO
>> implementation to introduce CoreSight HW Assisted Trace since we're
>> preparing for release. As a minimum, we know this would require a respin
> 
> Please note that MMIO interface is for "external debug" not for
> self-hosted usecase, with system instruction support. This is why you need
> to work around the driver "as an errata".
> 

Sorry, my earlier response was poorly worded.

> 
>> of our CoreSight DSDT. Also, if I didn't misunderstand, it sounded like
>> you planned supporting work (e.g. ETMv4 not handled as an AMBA
>> device). Since our ETMv4 sink components (ETF, ETR, +CATU) remain memory
>> mapped, do these remain AMBA?
> 
> Just to be clear, all of these components will be MMIO. We are simply
> moving the "Linux" driver framework from AMBA driver to platform device.
> This will be done in stages. ETMv4x would be moved in the first pass to
> allow us to support system instruction based devices seemlessly with
> ACPI.
> 
>>
>> We understand ETMv4/ETE MMIO is going away. As a sysreg quick test, I
> 
> As mentioned above it is not going away. MMIO is the way to access if
> that is *the only* access mode. For ETMv4.4+ and ETE MMIO system
> instructions is *the mode* of access for self-hosted. Please be aware
> that, going down this route may prevent them being virtualised (when
> we add the support in the near future).

Ampere intends to support sysreg access going forward. What we're
lacking in this moment is time to work out the kinks.

> 
>> bypassed the code which checks for an ETMv4 base address in order to
>> default to sysreg access. Trace collection failed with an error. I don't
>> have the time to chase after this right now, but I intend to budget the
>> time in the near future.
> 
> If we can get to the bottom of this, we should be able to support
> the platform in a future proof way than adding this ugly work around
> of accessing via the *external MMIO* interface.

As I mention above, my assessment is it's too far along in our product
cycle to work through unforeseen sysreg issues which might surface. I
plan to devote time to this shortly. At present, a subset of our cores
have working self-hosted trace using MMIO. Our priority right now is to
scale the solution for our SoC. There are challenges here which span
OpenCSD, perf, and possibly the CoreSight driver.

In this patch submission, I've addressed the maintainer comments brought
to my attention. Nothing else has surfaced. The Ampere Linux team meets
every week or biweekly with ARM. I'll ask they add this topic to the
agenda if you believe it's warranted. Otherwise, can I ask your support
to move these upstream?

Thank you

> 
> Suzuki
> 
>>
>> Thanks and regards,
>> Steve
>>
>> On 3/6/2023 2:29 AM, Suzuki K Poulose wrote:
>>> Hi Steve,
>>>
>>> On 06/03/2023 05:54, Steve Clevenger wrote:
>>>> Ampere ETMv4.x support. Added Ampere ETM ID, and changes required by
>>>> the Ampere ETMv4.x hardware implementation.
>>>>
>>>
>>> I don't see any mention of the access via system instructions. Where did
>>> that end up ? What is the conclusion on that front ?
>>>
>>> Kind regards
>>> Suzuki
>>>
>>>
>>>> Steve Clevenger (3):
>>>>     Add known list of Ampere ETMv4 errata
>>>>     coresight etm4x: Early clear TRCOSLAR.OSLK prior to TRCIDR1 read
>>>>     coresight etm4x: Add 32-bit read/write option to split 64-bit words
>>>>
>>>>    Documentation/arm64/silicon-errata.rst        |  6 +-
>>>>    .../coresight/coresight-etm4x-core.c          | 50 +++++++++++-----
>>>>    drivers/hwtracing/coresight/coresight-etm4x.h | 58
>>>> ++++++++++++++-----
>>>>    include/linux/coresight.h                     |  3 +
>>>>    4 files changed, 89 insertions(+), 28 deletions(-)
>>>>
>>>
>