From: sudeep.holla@arm.com (Sudeep Holla)
To: linux-arm-kernel@lists.infradead.org
Subject: [QUESTION ]ARM64 external L3 cache support in topology info
Date: Fri, 5 Feb 2016 14:30:18 +0000 [thread overview]
Message-ID: <56B4B1FA.5030309@arm.com> (raw)
In-Reply-To: <5FC3163CFD30C246ABAA99954A238FA8172E13A4@lhreml504-mbs>
On 05/02/16 12:04, Shameerali Kolothum Thodi wrote:
> Hi,
>
> This is a query to get the external L3 cache included in the cache
> topology info. ARM64 kernel now has the cache topology info added
> based on the patch here [1].
>
> 1. http://permalink.gmane.org/gmane.linux.ports.arm.kernel/383628
>
[..]
>
> We have a ARM64 board(Hisilicon D02) and it has got an external L3 cache.
> As per my understanding after talking to our SoC guys, this cache is not
> integrated into the processor and is not visible in (CLIDR) register.
> But this looks to be fine as per the Programmer's Guide for ARMv8-A.
>
> "The CLIDR register is only aware of how many levels of cache are
> integrated into the processor itself. It cannot provide information
> about any caches in the external memory system. For example, if
> only L1 and L2 are integrated, CLIDR/CLIDR_EL1 identifies two levels
> of cache and the processor is unaware of any external L3 cache.
> It might be necessary to take into account non-integrated caches
> when performing cache maintenance, or code that is maintaining
> coherency with integrated caches."
>
Understood.
[..]
>
> In our case, the L3 cache seems to be intelligent enough and doesn't
> require any additional maintenance ops. So there is no cache-controller
> code for this. I am just wondering what's the best way to add this L3
> cache info to the topology. Overriding the CLIDR register, if there is
> a next-level-cache entry in the dts and then retrieve the cache geometry
> either from dts or from cache specific registers( but this will be
> implementation specific) ? Or am I missing something here?
>
Recent discussion on this [1] made it clear that we need to support
overriding cache properties using DT for some designs. I will consider
this "transparent" external/system level cache when I look into moving
PPC DT code in generic cacheinfo. I am not sure if it's OK to support
mixed information source for a platform(all internal caches via CLIDR
and external ones via DT), but we can pick up discussion once we I have
the patch.
--
Regards,
Sudeep
[1]
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-October/381758.html
next prev parent reply other threads:[~2016-02-05 14:30 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-05 12:04 [QUESTION ]ARM64 external L3 cache support in topology info Shameerali Kolothum Thodi
2016-02-05 14:30 ` Sudeep Holla [this message]
2016-02-05 15:33 ` Shameerali Kolothum Thodi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56B4B1FA.5030309@arm.com \
--to=sudeep.holla@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.