[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220630202141.37p5qhppkiz6wrcb@bogus>
Date: Thu, 30 Jun 2022 21:21:41 +0100
From: Sudeep Holla <sudeep.holla@....com>
To: Conor.Dooley@...rochip.com
Cc: linux-kernel@...r.kernel.org, gregkh@...uxfoundation.org,
atishp@...shpatra.org, atishp@...osinc.com,
vincent.guittot@...aro.org, dietmar.eggemann@....com,
wangqing@...o.com, robh+dt@...nel.org, rafael@...nel.org,
ionela.voinescu@....com, pierre.gondois@....com,
linux-arm-kernel@...ts.infradead.org,
linux-riscv@...ts.infradead.org, gshan@...hat.com,
Valentina.FernandezAlanis@...rochip.com
Subject: Re: [PATCH v5 09/19] arch_topology: Use the last level cache
information from the cacheinfo
On Thu, Jun 30, 2022 at 08:13:55PM +0000, Conor.Dooley@...rochip.com wrote:
>
> I didn't have the time to go digging into things, but the following
> macro looked odd:
> #define per_cpu_cacheinfo_idx(cpu, idx) \
> (per_cpu_cacheinfo(cpu) + (idx))
> Maybe it is just badly named, but is this getting the per_cpu_cacheinfo
> and then incrementing intentionally, or is it meant to get the
> per_cpu_cacheinfo of cpu + idx?
OK, basically per_cpu_cacheinfo(cpu) get the information for a cpu
while per_cpu_cacheinfo_idx(cpu, idx) will fetch the information for a
given cpu and given index within the cpu. So we are incrementing the
pointer by the index. These work just fine on arm64 platform.
Not sure if compiler is optimising something as I still can't understand
how we can end up with valid llc but fw_token as NULL.
--
Regards,
Sudeep
Powered by blists - more mailing lists