All of lore.kernel.org
 help / color / mirror / Atom feed
From: Miquel Raynal <miquel.raynal-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org>
To: Peter Geis <pgwipeout-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Heiko Stuebner <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>,
	Maxime Chevallier
	<maxime.chevallier-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org>,
	Paul Kocialkowski
	<paul.kocialkowski-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org>,
	"open list:ARM/Rockchip SoC..."
	<linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
	Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	Thomas Petazzoni
	<thomas.petazzoni-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org>
Subject: Re: [PATCH] arm64: dts: rockchip: Describe PX30 caches
Date: Wed, 4 Dec 2019 18:17:06 +0100	[thread overview]
Message-ID: <20191204181706.0421c4f7@xps13> (raw)
In-Reply-To: <CAMdYzYoUo_M+qEp3HRsEGrGJDa73JACfH38HG7aY6C8NrQi=5A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

Hi Peter,

Peter Geis <pgwipeout@gmail.com> wrote on Wed, 4 Dec 2019 12:14:40
-0500:

> On Wed, Dec 4, 2019 at 10:44 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> >
> > Hi Peter,
> >
> > Peter Geis <pgwipeout@gmail.com> wrote on Wed, 4 Dec 2019 10:36:19
> > -0500:
> >  
> > > On Wed, Dec 4, 2019 at 5:40 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:  
> > > >
> > > > PX30 SoCs feature 4 Cortex-A35 CPUs with each of them a L1 data and
> > > > instruction cache. Both are 32kiB wide (PX30 TRM) and made of 64-bit
> > > > lines (ARM Cortex-A35 manual). I-cache is 2-way set associative (ARM
> > > > Cortex-A35 manual), D-cache is 4-way set associative (ARM
> > > > Cortex-A35manual).
> > > >
> > > > An L2 cache is placed after these 4 L1 caches (PX30 TRM), is 256kiB
> > > > wide (PX30 TRM) and made of 64-bit lines (ARM Cortex-A35 manual) and
> > > > is 8-way set associative (ARM Cortex-A35 manual).
> > > >
> > > > Describe all of them in the PX30 DTSI.
> > > >
> > > > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> > > > ---
> > > >  arch/arm64/boot/dts/rockchip/px30.dtsi | 35 ++++++++++++++++++++++++++
> > > >  1 file changed, 35 insertions(+)
> > > >
> > > > diff --git a/arch/arm64/boot/dts/rockchip/px30.dtsi b/arch/arm64/boot/dts/rockchip/px30.dtsi
> > > > index 1fd12bd09e83..0e10a224a84b 100644
> > > > --- a/arch/arm64/boot/dts/rockchip/px30.dtsi
> > > > +++ b/arch/arm64/boot/dts/rockchip/px30.dtsi
> > > > @@ -48,6 +48,13 @@
> > > >                         cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP>;
> > > >                         dynamic-power-coefficient = <90>;
> > > >                         operating-points-v2 = <&cpu0_opp_table>;
> > > > +                       i-cache-size = <0x8000>;
> > > > +                       i-cache-line-size = <64>;
> > > > +                       i-cache-sets = <256>;
> > > > +                       d-cache-size = <0x8000>;
> > > > +                       d-cache-line-size = <64>;
> > > > +                       d-cache-sets = <128>;
> > > > +                       next-level-cache = <&l2>;  
> > >
> > > If the i-cache is 2-way associative and the d-cache is 4-way, wouldn't
> > > that mean these two values are backwards?  
> >
> > Which value are you referring to? Do you mean cache-sets? The following
> > calculation is my understanding of the situation but it is the first
> > time I am doing it so I might be totally wrong.
> >
> > My understanding is that if there are 32768 cache bytes made of 64-byte
> > lines, so there are 512 lines in both cases.
> >
> > Then, if the instruction cache is 2-way associative, it means there are
> > 512 / 2 = 256 sets. For the data cache (4-way), it would be 512 / 4 =
> > 128. Am I wrong?  
> 
> Apologies, you are correct, it was I who was mistaken.

No problem, I was not 100% sure either. Thanks for the review anyway!

Cheers,
Miquèl

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

WARNING: multiple messages have this Message-ID (diff)
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Peter Geis <pgwipeout@gmail.com>
Cc: Heiko Stuebner <heiko@sntech.de>,
	"open list:ARM/Rockchip SoC..."
	<linux-rockchip@lists.infradead.org>,
	Rob Herring <robh+dt@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	devicetree@vger.kernel.org,
	Paul Kocialkowski <paul.kocialkowski@bootlin.com>,
	Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
	Maxime Chevallier <maxime.chevallier@bootlin.com>
Subject: Re: [PATCH] arm64: dts: rockchip: Describe PX30 caches
Date: Wed, 4 Dec 2019 18:17:06 +0100	[thread overview]
Message-ID: <20191204181706.0421c4f7@xps13> (raw)
In-Reply-To: <CAMdYzYoUo_M+qEp3HRsEGrGJDa73JACfH38HG7aY6C8NrQi=5A@mail.gmail.com>

Hi Peter,

Peter Geis <pgwipeout@gmail.com> wrote on Wed, 4 Dec 2019 12:14:40
-0500:

> On Wed, Dec 4, 2019 at 10:44 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:
> >
> > Hi Peter,
> >
> > Peter Geis <pgwipeout@gmail.com> wrote on Wed, 4 Dec 2019 10:36:19
> > -0500:
> >  
> > > On Wed, Dec 4, 2019 at 5:40 AM Miquel Raynal <miquel.raynal@bootlin.com> wrote:  
> > > >
> > > > PX30 SoCs feature 4 Cortex-A35 CPUs with each of them a L1 data and
> > > > instruction cache. Both are 32kiB wide (PX30 TRM) and made of 64-bit
> > > > lines (ARM Cortex-A35 manual). I-cache is 2-way set associative (ARM
> > > > Cortex-A35 manual), D-cache is 4-way set associative (ARM
> > > > Cortex-A35manual).
> > > >
> > > > An L2 cache is placed after these 4 L1 caches (PX30 TRM), is 256kiB
> > > > wide (PX30 TRM) and made of 64-bit lines (ARM Cortex-A35 manual) and
> > > > is 8-way set associative (ARM Cortex-A35 manual).
> > > >
> > > > Describe all of them in the PX30 DTSI.
> > > >
> > > > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
> > > > ---
> > > >  arch/arm64/boot/dts/rockchip/px30.dtsi | 35 ++++++++++++++++++++++++++
> > > >  1 file changed, 35 insertions(+)
> > > >
> > > > diff --git a/arch/arm64/boot/dts/rockchip/px30.dtsi b/arch/arm64/boot/dts/rockchip/px30.dtsi
> > > > index 1fd12bd09e83..0e10a224a84b 100644
> > > > --- a/arch/arm64/boot/dts/rockchip/px30.dtsi
> > > > +++ b/arch/arm64/boot/dts/rockchip/px30.dtsi
> > > > @@ -48,6 +48,13 @@
> > > >                         cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP>;
> > > >                         dynamic-power-coefficient = <90>;
> > > >                         operating-points-v2 = <&cpu0_opp_table>;
> > > > +                       i-cache-size = <0x8000>;
> > > > +                       i-cache-line-size = <64>;
> > > > +                       i-cache-sets = <256>;
> > > > +                       d-cache-size = <0x8000>;
> > > > +                       d-cache-line-size = <64>;
> > > > +                       d-cache-sets = <128>;
> > > > +                       next-level-cache = <&l2>;  
> > >
> > > If the i-cache is 2-way associative and the d-cache is 4-way, wouldn't
> > > that mean these two values are backwards?  
> >
> > Which value are you referring to? Do you mean cache-sets? The following
> > calculation is my understanding of the situation but it is the first
> > time I am doing it so I might be totally wrong.
> >
> > My understanding is that if there are 32768 cache bytes made of 64-byte
> > lines, so there are 512 lines in both cases.
> >
> > Then, if the instruction cache is 2-way associative, it means there are
> > 512 / 2 = 256 sets. For the data cache (4-way), it would be 512 / 4 =
> > 128. Am I wrong?  
> 
> Apologies, you are correct, it was I who was mistaken.

No problem, I was not 100% sure either. Thanks for the review anyway!

Cheers,
Miquèl

  parent reply	other threads:[~2019-12-04 17:17 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-04 10:39 [PATCH] arm64: dts: rockchip: Describe PX30 caches Miquel Raynal
2019-12-04 10:39 ` Miquel Raynal
     [not found] ` <20191204103940.22050-1-miquel.raynal-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org>
2019-12-04 15:36   ` Peter Geis
2019-12-04 15:36     ` Peter Geis
     [not found]     ` <CAMdYzYrEmTqvJ6m54EADxLDf70duCtdz3pesV3EZmt67=cbs5g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-12-04 15:44       ` Miquel Raynal
2019-12-04 15:44         ` Miquel Raynal
2019-12-04 17:14         ` Peter Geis
2019-12-04 17:14           ` Peter Geis
     [not found]           ` <CAMdYzYoUo_M+qEp3HRsEGrGJDa73JACfH38HG7aY6C8NrQi=5A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2019-12-04 17:17             ` Miquel Raynal [this message]
2019-12-04 17:17               ` Miquel Raynal
2019-12-20  0:55   ` Heiko Stübner
2019-12-20  0:55     ` Heiko Stübner
2019-12-23  9:03     ` Miquel Raynal
2019-12-23  9:03       ` Miquel Raynal

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=20191204181706.0421c4f7@xps13 \
    --to=miquel.raynal-ldxbnhwyfcjbdgjk7y7tuq@public.gmane.org \
    --cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org \
    --cc=linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=mark.rutland-5wv7dgnIgG8@public.gmane.org \
    --cc=maxime.chevallier-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org \
    --cc=paul.kocialkowski-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org \
    --cc=pgwipeout-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
    --cc=thomas.petazzoni-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.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.