mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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

  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®