From: Dmitry Osipenko <dmitry.osipenko@collabora.com>
To: Marc Zyngier <maz@kernel.org>
Cc: Heiko Stuebner <heiko@sntech.de>, Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
devicetree@vger.kernel.org, linux-rockchip@lists.infradead.org,
linux-kernel@vger.kernel.org,
Kever Yang <kever.yang@rock-chips.com>,
XiaoDong Huang <derrick.huang@rock-chips.com>,
Peter Geis <pgwipeout@gmail.com>,
Robin Murphy <robin.murphy@arm.com>,
kernel@collabora.com
Subject: Re: [PATCH v1 1/4] irqchip/gic-v3: Add Rockchip 3568002 erratum workaround
Date: Sun, 16 Feb 2025 18:25:53 +0300 [thread overview]
Message-ID: <ac4afb67-9ec7-405a-acf9-6287b30320d4@collabora.com> (raw)
In-Reply-To: <87seoe1aeu.wl-maz@kernel.org>
On 2/16/25 12:55, Marc Zyngier wrote:
> On Sat, 15 Feb 2025 23:54:28 +0000,
> Dmitry Osipenko <dmitry.osipenko@collabora.com> wrote:
>>
>> Rockchip RK3566/RK3568 GIC600 integration has DDR addressing
>> limited to first 4GB of DRAM. Rockchip assigned Erratum ID #3568002
>> for this issue. Add driver quirk for this Rockchip GIC Erratum.
>
> Thanks for taking the time to submit this. It only took 5 years for
> this erratum to be published...
The erratum document itself actually is dated by 5 years ago. Only wish
the doc was made publicly available, which would've accelerated the
upstreaming process.
> However, my understanding of this issue is that the integration is
> limited to the first 32bit of physical address space, not the first
> 32bit of RAM. If the memory is placed as physical address 0, then they
> represent the same space. But this is still an important distinction.
Indeed, will correct the description in v2.
>> Note, that the 0x0201743b ID is not Rockchip 356x specific and thus
>> there is an extra of_machine_is_compatible() check. Rockchip 3588 uses
>> same ID and it is not affected by this errata.
>
> This ID is that of ARM's GIC600, which is a very common GICv3
> implementation, and is not Rockchip-specific. Please capture this in
> the commit message.
Ack
...
>> +config ROCKCHIP_ERRATUM_3568002
>> + bool "Rockchip 3568002: can not support DDR addresses higher than 4G"
>> + default y
>> + help
>> + The Rockchip RK3566 and RK3568 GIC600 SoC integrations have DDR
>> + addressing limited to first 4GB.
>> +
>> + If unsure, say Y.
>> +
>
> s/DDR addresses/physical addresses/
Ack
...
> Another thing is that this patch conflates ITS and redistributors. As
> it turns out, we use the same allocator for both, but they are
> distinct architectural concepts, even if GIC600 is a monolithic
> implementation. It is OK for now, but it will have to be revisited if
> we ever move the redistributor management outside of the ITS driver.
>
> With the other comments addressed:
>
> Acked-by: Marc Zyngier <maz@kernel.org>
Thanks for the review!
--
Best regards,
Dmitry
next prev parent reply other threads:[~2025-02-16 15:26 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-15 23:54 [PATCH v1 0/4] Add Rockchip 3568001/2 errata workarounds and enable ITS on RK356x Dmitry Osipenko
2025-02-15 23:54 ` [PATCH v1 1/4] irqchip/gic-v3: Add Rockchip 3568002 erratum workaround Dmitry Osipenko
2025-02-16 9:55 ` Marc Zyngier
2025-02-16 15:25 ` Dmitry Osipenko [this message]
2025-02-16 18:21 ` Marc Zyngier
2025-02-15 23:54 ` [PATCH v1 2/4] arm64: dts: rockchip: rk356x: Add dma-noncoherent property to GIC node Dmitry Osipenko
2025-02-15 23:54 ` [PATCH v1 3/4] arm64: dts: rockchip: rk356x: Add MSI controller node Dmitry Osipenko
2025-02-16 9:59 ` Marc Zyngier
2025-02-16 15:26 ` Dmitry Osipenko
2025-02-15 23:54 ` [PATCH v1 4/4] arm64: dts: rockchip: rk356x: Move PCIe MSI to use GIC ITS instead of MBI Dmitry Osipenko
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=ac4afb67-9ec7-405a-acf9-6287b30320d4@collabora.com \
--to=dmitry.osipenko@collabora.com \
--cc=derrick.huang@rock-chips.com \
--cc=devicetree@vger.kernel.org \
--cc=heiko@sntech.de \
--cc=kernel@collabora.com \
--cc=kever.yang@rock-chips.com \
--cc=krzk+dt@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=maz@kernel.org \
--cc=pgwipeout@gmail.com \
--cc=robh@kernel.org \
--cc=robin.murphy@arm.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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®