[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJ9a7Vh44rYWN3mjHPBq8pkBcPuhS2pTBZNaMpWgJECmPZtupg@mail.gmail.com>
Date: Thu, 14 Aug 2025 13:37:23 +0100
From: Mike Leach <mike.leach@...aro.org>
To: James Clark <james.clark@...aro.org>
Cc: Suzuki K Poulose <suzuki.poulose@....com>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>, Jonathan Corbet <corbet@....net>,
Leo Yan <leo.yan@....com>, coresight@...ts.linaro.org,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
linux-doc@...r.kernel.org
Subject: Re: [PATCH 2/6] coresight: Fix holes in struct etmv4_config
Hi James
On Mon, 11 Aug 2025 at 10:32, James Clark <james.clark@...aro.org> wrote:
>
> Lots of u8s are mixed with u64s and u32s so repack it to save a bit
> of space because there's one of these for each ETM.
>
> Signed-off-by: James Clark <james.clark@...aro.org>
> ---
> drivers/hwtracing/coresight/coresight-etm4x.h | 19 ++++++++++++-------
> 1 file changed, 12 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/hwtracing/coresight/coresight-etm4x.h b/drivers/hwtracing/coresight/coresight-etm4x.h
> index 746627476bd3..a355a1e9606d 100644
> --- a/drivers/hwtracing/coresight/coresight-etm4x.h
> +++ b/drivers/hwtracing/coresight/coresight-etm4x.h
> @@ -832,28 +832,33 @@ struct etmv4_config {
> u32 vipcssctlr;
> u8 seq_idx;
> u8 syncfreq;
> + u8 cntr_idx;
> + u8 res_idx;
> + u8 ss_idx;
> + u8 addr_idx;
> + u8 addr_type[ETM_MAX_SINGLE_ADDR_CMP];
> + u8 ctxid_idx;
> + u8 vmid_idx;
> u32 seq_ctrl[ETM_MAX_SEQ_STATES];
> u32 seq_rst;
> u32 seq_state;
> - u8 cntr_idx;
> +
> u32 cntrldvr[ETMv4_MAX_CNTR];
> u32 cntr_ctrl[ETMv4_MAX_CNTR];
> u32 cntr_val[ETMv4_MAX_CNTR];
> - u8 res_idx;
> +
> u32 res_ctrl[ETM_MAX_RES_SEL];
> - u8 ss_idx;
> +
> u32 ss_ctrl[ETM_MAX_SS_CMP];
> u32 ss_status[ETM_MAX_SS_CMP];
> u32 ss_pe_cmp[ETM_MAX_SS_CMP];
> - u8 addr_idx;
> +
> u64 addr_val[ETM_MAX_SINGLE_ADDR_CMP];
> u64 addr_acc[ETM_MAX_SINGLE_ADDR_CMP];
> - u8 addr_type[ETM_MAX_SINGLE_ADDR_CMP];
this is 16 x u8 - could this not just stay here?
> - u8 ctxid_idx;
> +
> u64 ctxid_pid[ETMv4_MAX_CTXID_CMP];
> u32 ctxid_mask0;
> u32 ctxid_mask1;
> - u8 vmid_idx;
> u64 vmid_val[ETM_MAX_VMID_CMP];
> u32 vmid_mask0;
> u32 vmid_mask1;
>
> --
> 2.34.1
>
These attributes have been functionally grouped for ease of
understanding. If we move the _idx values away from what they are
indexing, we probably need comments cross referencing from where they
where and where they have gone to.
Mike
--
Mike Leach
Principal Engineer, ARM Ltd.
Manchester Design Centre. UK
Powered by blists - more mailing lists