From: Kever Yang <kever.yang@rock-chips.com> To: Marc Zyngier <maz@kernel.org> Cc: "Peter Geis" <pgwipeout@gmail.com>, "Thomas Gleixner" <tglx@linutronix.de>, "open list:ARM/Rockchip SoC..." <linux-rockchip@lists.infradead.org>, "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>, "Heiko Stübner" <heiko@sntech.de> Subject: Re: [RFC] ITS fails to allocate on rk3568/rk3566 Date: Fri, 16 Apr 2021 09:13:38 +0800 [thread overview] Message-ID: <8d2e22f5-1c1b-e795-8757-ae078446d961@rock-chips.com> (raw) In-Reply-To: <87k0p4m0gm.wl-maz@kernel.org> Hi Marc, On 2021/4/15 下午4:11, Marc Zyngier wrote: > Hi Kever, > > On Thu, 15 Apr 2021 08:24:33 +0100, > Kever Yang <kever.yang@rock-chips.com> wrote: >> Hi Marc, Peter, >> >> RK356x GIC has two issues: >> >> 1. GIC only support 32bit address while rk356x supports 8GB DDR SDRAM, >> so we use ZONE_DMA32 to fix this issue; > What transactions does this affect exactly? The GIC on rk356x is a 32bit master, which means all the space its logic need to access should be in the 4GB range. > Only some ITS tables? Or > all of them, including the command queue? What about the configuration > and pending tables associated with the redistributors? > >> 2. GIC version is r1p6-00rel0, RK356x interconnect does not support >> GIC and CPU snoop to each other, hence the GIC does not support the >> shareability feature. The read of register value for shareability >> feature does not return as expect in GICR and GITS, so we have to >> workaround for it. > How about the cacheability attribute? Can you please provide the exact > set of attributes that this system actually supports for each of the > ITS and redistributor base registers? The shareability attributes in GICR_PENDBASEER, GICR_PROPBASER, GITS_BASERn, GITS_CBASER default value is 0b00, when we set 0b01 then read returns 0b01. Since there is no ACE coherency interface for this GIC controller, all the cacheability in the GIC is not support in hardware. > > Also, please provide errata numbers for these two issues so that we > can properly document them and track the workarounds. What kind of errata do you need, could you please share any kind of example close to this case? We consider this as a SoC implement design instead of a bug, so we will add document in RK356X TRM to describe the GIC design, but no idea how to provide the errata. Here is the shareabily attribute from ARM GIC architecture specification: Shareability, bits [11:10] (from GITS_CBASER) Indicates the Shareability attributes of accesses to the command queue. The possible values of this field are: 0b00 Non-shareable. 0b01 Inner Shareable. 0b10 Outer Shareable. 0b11 Reserved. Treated as 0b00. It is IMPLEMENTATION DEFINED whether this field has a fixed value or can be programmed by software. Implementing this field with a fixed value is deprecated. On a Warm reset, this field resets to an architecturally UNKNOWN value As you can see, "Implementing this field with a fixed value is deprecated", so software should program this field to '0b00 Non-shareable' if the SoC design does not support the cache shareability. Thanks, - Kever > > Thanks, > > M. >
WARNING: multiple messages have this Message-ID (diff)
From: Kever Yang <kever.yang@rock-chips.com> To: Marc Zyngier <maz@kernel.org> Cc: "Peter Geis" <pgwipeout@gmail.com>, "Thomas Gleixner" <tglx@linutronix.de>, "open list:ARM/Rockchip SoC..." <linux-rockchip@lists.infradead.org>, "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>, "Heiko Stübner" <heiko@sntech.de> Subject: Re: [RFC] ITS fails to allocate on rk3568/rk3566 Date: Fri, 16 Apr 2021 09:13:38 +0800 [thread overview] Message-ID: <8d2e22f5-1c1b-e795-8757-ae078446d961@rock-chips.com> (raw) In-Reply-To: <87k0p4m0gm.wl-maz@kernel.org> Hi Marc, On 2021/4/15 下午4:11, Marc Zyngier wrote: > Hi Kever, > > On Thu, 15 Apr 2021 08:24:33 +0100, > Kever Yang <kever.yang@rock-chips.com> wrote: >> Hi Marc, Peter, >> >> RK356x GIC has two issues: >> >> 1. GIC only support 32bit address while rk356x supports 8GB DDR SDRAM, >> so we use ZONE_DMA32 to fix this issue; > What transactions does this affect exactly? The GIC on rk356x is a 32bit master, which means all the space its logic need to access should be in the 4GB range. > Only some ITS tables? Or > all of them, including the command queue? What about the configuration > and pending tables associated with the redistributors? > >> 2. GIC version is r1p6-00rel0, RK356x interconnect does not support >> GIC and CPU snoop to each other, hence the GIC does not support the >> shareability feature. The read of register value for shareability >> feature does not return as expect in GICR and GITS, so we have to >> workaround for it. > How about the cacheability attribute? Can you please provide the exact > set of attributes that this system actually supports for each of the > ITS and redistributor base registers? The shareability attributes in GICR_PENDBASEER, GICR_PROPBASER, GITS_BASERn, GITS_CBASER default value is 0b00, when we set 0b01 then read returns 0b01. Since there is no ACE coherency interface for this GIC controller, all the cacheability in the GIC is not support in hardware. > > Also, please provide errata numbers for these two issues so that we > can properly document them and track the workarounds. What kind of errata do you need, could you please share any kind of example close to this case? We consider this as a SoC implement design instead of a bug, so we will add document in RK356X TRM to describe the GIC design, but no idea how to provide the errata. Here is the shareabily attribute from ARM GIC architecture specification: Shareability, bits [11:10] (from GITS_CBASER) Indicates the Shareability attributes of accesses to the command queue. The possible values of this field are: 0b00 Non-shareable. 0b01 Inner Shareable. 0b10 Outer Shareable. 0b11 Reserved. Treated as 0b00. It is IMPLEMENTATION DEFINED whether this field has a fixed value or can be programmed by software. Implementing this field with a fixed value is deprecated. On a Warm reset, this field resets to an architecturally UNKNOWN value As you can see, "Implementing this field with a fixed value is deprecated", so software should program this field to '0b00 Non-shareable' if the SoC design does not support the cache shareability. Thanks, - Kever > > Thanks, > > M. > _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip
next prev parent reply other threads:[~2021-04-16 1:14 UTC|newest] Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-04-12 20:49 [RFC] ITS fails to allocate on rk3568/rk3566 Peter Geis 2021-04-12 20:49 ` Peter Geis 2021-04-13 9:23 ` Marc Zyngier 2021-04-13 9:23 ` Marc Zyngier [not found] ` <CAMdYzYruPyiT89FrbJhuV=c36PyRwZ7sT45abnv8rTv85AKRow@mail.gmail.com> [not found] ` <87y2dmmggt.wl-maz@kernel.org> 2021-04-13 15:03 ` Peter Geis 2021-04-13 15:03 ` Peter Geis 2021-04-13 15:51 ` Marc Zyngier 2021-04-13 15:51 ` Marc Zyngier 2021-04-14 11:41 ` Peter Geis 2021-04-14 11:41 ` Peter Geis 2021-04-14 12:42 ` Marc Zyngier 2021-04-14 12:42 ` Marc Zyngier 2021-04-15 7:24 ` Kever Yang 2021-04-15 7:24 ` Kever Yang 2021-04-15 8:11 ` Marc Zyngier 2021-04-15 8:11 ` Marc Zyngier 2021-04-16 1:13 ` Kever Yang [this message] 2021-04-16 1:13 ` Kever Yang 2021-04-16 15:23 ` Marc Zyngier 2021-04-16 15:23 ` Marc Zyngier 2021-04-21 1:40 ` Kever Yang 2021-04-21 1:40 ` Kever Yang 2021-04-21 10:23 ` Marc Zyngier 2021-04-21 10:23 ` Marc Zyngier
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=8d2e22f5-1c1b-e795-8757-ae078446d961@rock-chips.com \ --to=kever.yang@rock-chips.com \ --cc=heiko@sntech.de \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-rockchip@lists.infradead.org \ --cc=maz@kernel.org \ --cc=pgwipeout@gmail.com \ --cc=tglx@linutronix.de \ /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: linkBe 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.