Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [PATCH v6 00/26] coresight: etm4x: Support for system
 instructions
To:     Mathieu Poirier <mathieu.poirier@linaro.org>
Cc:     linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org,
        coresight@lists.linaro.org, leo.yan@linaro.org,
        mike.leach@linaro.org, anshuman.khandual@arm.com
References: <20210107123859.674252-1-suzuki.poulose@arm.com>
 <20210108010907.GJ43045@xps15>
From:   Suzuki K Poulose <suzuki.poulose@arm.com>
Message-ID: <7f3304f7-8c68-3a61-48da-553de87c027d@arm.com>
Date:   Fri, 8 Jan 2021 09:08:01 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.6.0
MIME-Version: 1.0
In-Reply-To: <20210108010907.GJ43045@xps15>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
Precedence: bulk

Hi Mathieu

On 1/8/21 1:09 AM, Mathieu Poirier wrote:
> Hi Suzuki,
> 
> On Thu, Jan 07, 2021 at 12:38:33PM +0000, Suzuki K Poulose wrote:
>> CoreSight ETMv4.4 obsoletes memory mapped access to ETM and
>> mandates the system instructions for registers.
>> This also implies that they may not be on the amba bus.
>> Right now all the CoreSight components are accessed via memory
>> map. Also, we have some common routines in coresight generic
>> code driver (e.g, CS_LOCK, claim/disclaim), which assume the
>> mmio. In order to preserve the generic algorithms at a single
>> place and to allow dynamic switch for ETMs, this series introduces
>> an abstraction layer for accessing a coresight device. It is
>> designed such that the mmio access are fast tracked (i.e, without
>> an indirect function call).
>>
>> This will also help us to get rid of the driver+attribute specific
>> sysfs show/store routines and replace them with a single routine
>> to access a given register offset (which can be embedded in the
>> dev_ext_attribute). This is not currently implemented in the series,
>> but can be achieved.
>>
>> Further we switch the generic routines to work with the abstraction.
>> With this in place, we refactor the etm4x code a bit to allow for
>> supporting the system instructions with very little new code.
>>
>> We use TRCDEVARCH for the detection of the ETM component, which
>> is a standard register as per CoreSight architecture, rather than
>> the etm specific id register TRCIDR1. This is for making sure
>> that we are able to detect the ETM via system instructions accurately,
>> when the the trace unit could be anything (etm or a custom trace unit).
>> To keep the backward compatibility for any existing broken
>> impelementation which may not implement TRCDEVARCH, we fall back to TRCIDR1.
>> Also this covers us for the changes in the future architecture [0].
>>
>> Also, v8.4 self-hosted tracing extensions (coupled with ETMv4.4) adds
>> new filtering registers for trace by exception level. So on a v8.4
>> system, with Trace Filtering support, without the appropriate
>> programming of the Trace filter registers (TRFCR_ELx), tracing
>> will not be enabled. This series also includes the TraceFiltering
>> support to cover the ETM-v4.4 support.
>>
>> The series has been mildly tested on a model for system instructions.
>> I would really appreciate any testing on real hardware.
> 
> I have queued your work in my local tree.  I will have a final pass before
> pushing to coresight-next tomorrow or on Monday.
> 

Thanks for the review and fixups. Please let me know if you need a respin.

Cheers
Suzuki