From: Marc Zyngier <maz@kernel.org>
To: Lucas Tanure <lucas.tanure@collabora.com>
Cc: Robin Murphy <robin.murphy@arm.com>,
Peter Geis <pgwipeout@gmail.com>, Vinod Koul <vkoul@kernel.org>,
Kishon Vijay Abraham I <kishon@kernel.org>,
Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Heiko Stuebner <heiko@sntech.de>,
Thomas Gleixner <tglx@linutronix.de>,
Lorenzo Pieralisi <lpieralisi@kernel.org>,
Krzysztof Wilczynski <kw@linux.com>,
Bjorn Helgaas <bhelgaas@google.com>, Qu Wenruo <wqu@suse.com>,
Piotr Oniszczuk <piotr.oniszczuk@gmail.com>,
Kever Yang <kever.yang@rock-chips.com>,
linux-phy@lists.infradead.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org,
linux-pci@vger.kernel.org, kernel@collabora.com
Subject: Re: [PATCH 1/7] irqchip/gic-v3: Add a DMA Non-Coherent flag
Date: Tue, 14 Mar 2023 14:14:27 +0000 [thread overview]
Message-ID: <86h6unxvwc.wl-maz@kernel.org> (raw)
In-Reply-To: <93e4d83d-9559-c987-d93b-c49572413275@collabora.com>
On Tue, 14 Mar 2023 13:25:28 +0000,
Lucas Tanure <lucas.tanure@collabora.com> wrote:
>
> On 10-03-2023 12:04, Robin Murphy wrote:
> > On 2023-03-10 11:41, Peter Geis wrote:
> >> On Fri, Mar 10, 2023 at 3:05 AM Lucas Tanure
> >> <lucas.tanure@collabora.com> wrote:
> >>>
> >>> The GIC600 integration in RK356x, used in rk3588, doesn't support
> >>> any of the shareability or cacheability attributes, and requires
> >>> both values to be set to 0b00 for all the ITS and Redistributor
> >>> tables.
> >>>
> >>> This is loosely based on prior work from XiaoDong Huang and
> >>> Peter Geis fixing this issue specifically for Rockchip 356x.
> >>
> >> Good Morning,
> >>
> >> Since the gic is using dma, would it be reasonable to have all memory
> >> allocations be requested with the GFP_DMA flag? Otherwise this doesn't
> >> fully solve the problem for rk356x, where only the lower 4GB range is
> >> DMA capable, but this tends to get allocated in the upper 4GB on 8GB
> >> boards.
> >
> > Not really, because there's no fixed definition of what GFP_DMA
> > actually means, and it may mean nothing (same for GFP_DMA32, which
> > may or may not be meaningful depending on kernel config and platform
> > topology). Drivers should really use the DMA API allocation
> > functions if they care about what they get, which comes back round
> > to the notion from years ago of converting the ITS driver to a
> > regular platform driver, so it can benefit from regular DT concepts
> > like "dma-ranges" automatically.
> >
> > Thanks,
> > Robin.
> >
> I am looking how to do that conversion to platform driver.
> But about the communication between irq-gic-v3-its and irq-gic-v3.
> Should irq-gic-v3-its be a MFD child of irq-gic-v3?
MFD? I'd rather suggest an VME bus driver. ;-)
Seriously, this is an interrupt controller. Nothing else. It should
probe the parent irqdomain, and stack onto that. No parent? Probe
deferral.
> Or use the component bind/unbind framework?
I don't understand what you mean here.
M.
--
Without deviation from the norm, progress is not possible.
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Lucas Tanure <lucas.tanure@collabora.com>
Cc: Robin Murphy <robin.murphy@arm.com>,
Peter Geis <pgwipeout@gmail.com>, Vinod Koul <vkoul@kernel.org>,
Kishon Vijay Abraham I <kishon@kernel.org>,
Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Heiko Stuebner <heiko@sntech.de>,
Thomas Gleixner <tglx@linutronix.de>,
Lorenzo Pieralisi <lpieralisi@kernel.org>,
Krzysztof Wilczynski <kw@linux.com>,
Bjorn Helgaas <bhelgaas@google.com>, Qu Wenruo <wqu@suse.com>,
Piotr Oniszczuk <piotr.oniszczuk@gmail.com>,
Kever Yang <kever.yang@rock-chips.com>,
linux-phy@lists.infradead.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org,
linux-pci@vger.kernel.org, kernel@collabora.com
Subject: Re: [PATCH 1/7] irqchip/gic-v3: Add a DMA Non-Coherent flag
Date: Tue, 14 Mar 2023 14:14:27 +0000 [thread overview]
Message-ID: <86h6unxvwc.wl-maz@kernel.org> (raw)
In-Reply-To: <93e4d83d-9559-c987-d93b-c49572413275@collabora.com>
On Tue, 14 Mar 2023 13:25:28 +0000,
Lucas Tanure <lucas.tanure@collabora.com> wrote:
>
> On 10-03-2023 12:04, Robin Murphy wrote:
> > On 2023-03-10 11:41, Peter Geis wrote:
> >> On Fri, Mar 10, 2023 at 3:05 AM Lucas Tanure
> >> <lucas.tanure@collabora.com> wrote:
> >>>
> >>> The GIC600 integration in RK356x, used in rk3588, doesn't support
> >>> any of the shareability or cacheability attributes, and requires
> >>> both values to be set to 0b00 for all the ITS and Redistributor
> >>> tables.
> >>>
> >>> This is loosely based on prior work from XiaoDong Huang and
> >>> Peter Geis fixing this issue specifically for Rockchip 356x.
> >>
> >> Good Morning,
> >>
> >> Since the gic is using dma, would it be reasonable to have all memory
> >> allocations be requested with the GFP_DMA flag? Otherwise this doesn't
> >> fully solve the problem for rk356x, where only the lower 4GB range is
> >> DMA capable, but this tends to get allocated in the upper 4GB on 8GB
> >> boards.
> >
> > Not really, because there's no fixed definition of what GFP_DMA
> > actually means, and it may mean nothing (same for GFP_DMA32, which
> > may or may not be meaningful depending on kernel config and platform
> > topology). Drivers should really use the DMA API allocation
> > functions if they care about what they get, which comes back round
> > to the notion from years ago of converting the ITS driver to a
> > regular platform driver, so it can benefit from regular DT concepts
> > like "dma-ranges" automatically.
> >
> > Thanks,
> > Robin.
> >
> I am looking how to do that conversion to platform driver.
> But about the communication between irq-gic-v3-its and irq-gic-v3.
> Should irq-gic-v3-its be a MFD child of irq-gic-v3?
MFD? I'd rather suggest an VME bus driver. ;-)
Seriously, this is an interrupt controller. Nothing else. It should
probe the parent irqdomain, and stack onto that. No parent? Probe
deferral.
> Or use the component bind/unbind framework?
I don't understand what you mean here.
M.
--
Without deviation from the norm, progress is not possible.
WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Lucas Tanure <lucas.tanure@collabora.com>
Cc: Robin Murphy <robin.murphy@arm.com>,
Peter Geis <pgwipeout@gmail.com>, Vinod Koul <vkoul@kernel.org>,
Kishon Vijay Abraham I <kishon@kernel.org>,
Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Heiko Stuebner <heiko@sntech.de>,
Thomas Gleixner <tglx@linutronix.de>,
Lorenzo Pieralisi <lpieralisi@kernel.org>,
Krzysztof Wilczynski <kw@linux.com>,
Bjorn Helgaas <bhelgaas@google.com>, Qu Wenruo <wqu@suse.com>,
Piotr Oniszczuk <piotr.oniszczuk@gmail.com>,
Kever Yang <kever.yang@rock-chips.com>,
linux-phy@lists.infradead.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org,
linux-pci@vger.kernel.org, kernel@collabora.com
Subject: Re: [PATCH 1/7] irqchip/gic-v3: Add a DMA Non-Coherent flag
Date: Tue, 14 Mar 2023 14:14:27 +0000 [thread overview]
Message-ID: <86h6unxvwc.wl-maz@kernel.org> (raw)
In-Reply-To: <93e4d83d-9559-c987-d93b-c49572413275@collabora.com>
On Tue, 14 Mar 2023 13:25:28 +0000,
Lucas Tanure <lucas.tanure@collabora.com> wrote:
>
> On 10-03-2023 12:04, Robin Murphy wrote:
> > On 2023-03-10 11:41, Peter Geis wrote:
> >> On Fri, Mar 10, 2023 at 3:05 AM Lucas Tanure
> >> <lucas.tanure@collabora.com> wrote:
> >>>
> >>> The GIC600 integration in RK356x, used in rk3588, doesn't support
> >>> any of the shareability or cacheability attributes, and requires
> >>> both values to be set to 0b00 for all the ITS and Redistributor
> >>> tables.
> >>>
> >>> This is loosely based on prior work from XiaoDong Huang and
> >>> Peter Geis fixing this issue specifically for Rockchip 356x.
> >>
> >> Good Morning,
> >>
> >> Since the gic is using dma, would it be reasonable to have all memory
> >> allocations be requested with the GFP_DMA flag? Otherwise this doesn't
> >> fully solve the problem for rk356x, where only the lower 4GB range is
> >> DMA capable, but this tends to get allocated in the upper 4GB on 8GB
> >> boards.
> >
> > Not really, because there's no fixed definition of what GFP_DMA
> > actually means, and it may mean nothing (same for GFP_DMA32, which
> > may or may not be meaningful depending on kernel config and platform
> > topology). Drivers should really use the DMA API allocation
> > functions if they care about what they get, which comes back round
> > to the notion from years ago of converting the ITS driver to a
> > regular platform driver, so it can benefit from regular DT concepts
> > like "dma-ranges" automatically.
> >
> > Thanks,
> > Robin.
> >
> I am looking how to do that conversion to platform driver.
> But about the communication between irq-gic-v3-its and irq-gic-v3.
> Should irq-gic-v3-its be a MFD child of irq-gic-v3?
MFD? I'd rather suggest an VME bus driver. ;-)
Seriously, this is an interrupt controller. Nothing else. It should
probe the parent irqdomain, and stack onto that. No parent? Probe
deferral.
> Or use the component bind/unbind framework?
I don't understand what you mean here.
M.
--
Without deviation from the norm, progress is not possible.
_______________________________________________
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: Marc Zyngier <maz@kernel.org>
To: Lucas Tanure <lucas.tanure@collabora.com>
Cc: Robin Murphy <robin.murphy@arm.com>,
Peter Geis <pgwipeout@gmail.com>, Vinod Koul <vkoul@kernel.org>,
Kishon Vijay Abraham I <kishon@kernel.org>,
Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Heiko Stuebner <heiko@sntech.de>,
Thomas Gleixner <tglx@linutronix.de>,
Lorenzo Pieralisi <lpieralisi@kernel.org>,
Krzysztof Wilczynski <kw@linux.com>,
Bjorn Helgaas <bhelgaas@google.com>, Qu Wenruo <wqu@suse.com>,
Piotr Oniszczuk <piotr.oniszczuk@gmail.com>,
Kever Yang <kever.yang@rock-chips.com>,
linux-phy@lists.infradead.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org,
linux-pci@vger.kernel.org, kernel@collabora.com
Subject: Re: [PATCH 1/7] irqchip/gic-v3: Add a DMA Non-Coherent flag
Date: Tue, 14 Mar 2023 14:14:27 +0000 [thread overview]
Message-ID: <86h6unxvwc.wl-maz@kernel.org> (raw)
In-Reply-To: <93e4d83d-9559-c987-d93b-c49572413275@collabora.com>
On Tue, 14 Mar 2023 13:25:28 +0000,
Lucas Tanure <lucas.tanure@collabora.com> wrote:
>
> On 10-03-2023 12:04, Robin Murphy wrote:
> > On 2023-03-10 11:41, Peter Geis wrote:
> >> On Fri, Mar 10, 2023 at 3:05 AM Lucas Tanure
> >> <lucas.tanure@collabora.com> wrote:
> >>>
> >>> The GIC600 integration in RK356x, used in rk3588, doesn't support
> >>> any of the shareability or cacheability attributes, and requires
> >>> both values to be set to 0b00 for all the ITS and Redistributor
> >>> tables.
> >>>
> >>> This is loosely based on prior work from XiaoDong Huang and
> >>> Peter Geis fixing this issue specifically for Rockchip 356x.
> >>
> >> Good Morning,
> >>
> >> Since the gic is using dma, would it be reasonable to have all memory
> >> allocations be requested with the GFP_DMA flag? Otherwise this doesn't
> >> fully solve the problem for rk356x, where only the lower 4GB range is
> >> DMA capable, but this tends to get allocated in the upper 4GB on 8GB
> >> boards.
> >
> > Not really, because there's no fixed definition of what GFP_DMA
> > actually means, and it may mean nothing (same for GFP_DMA32, which
> > may or may not be meaningful depending on kernel config and platform
> > topology). Drivers should really use the DMA API allocation
> > functions if they care about what they get, which comes back round
> > to the notion from years ago of converting the ITS driver to a
> > regular platform driver, so it can benefit from regular DT concepts
> > like "dma-ranges" automatically.
> >
> > Thanks,
> > Robin.
> >
> I am looking how to do that conversion to platform driver.
> But about the communication between irq-gic-v3-its and irq-gic-v3.
> Should irq-gic-v3-its be a MFD child of irq-gic-v3?
MFD? I'd rather suggest an VME bus driver. ;-)
Seriously, this is an interrupt controller. Nothing else. It should
probe the parent irqdomain, and stack onto that. No parent? Probe
deferral.
> Or use the component bind/unbind framework?
I don't understand what you mean here.
M.
--
Without deviation from the norm, progress is not possible.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-03-14 14:14 UTC|newest]
Thread overview: 80+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-10 8:05 [PATCH 0/7] Add PCIe2 support for Rockchip Boards Lucas Tanure
2023-03-10 8:05 ` Lucas Tanure
2023-03-10 8:05 ` Lucas Tanure
2023-03-10 8:05 ` Lucas Tanure
2023-03-10 8:05 ` [PATCH 1/7] irqchip/gic-v3: Add a DMA Non-Coherent flag Lucas Tanure
2023-03-10 8:05 ` Lucas Tanure
2023-03-10 8:05 ` Lucas Tanure
2023-03-10 8:05 ` Lucas Tanure
2023-03-10 8:56 ` Marc Zyngier
2023-03-10 8:56 ` Marc Zyngier
2023-03-10 8:56 ` Marc Zyngier
2023-03-10 8:56 ` Marc Zyngier
2023-03-10 9:53 ` Lucas Tanure
2023-03-10 9:53 ` Lucas Tanure
2023-03-10 9:53 ` Lucas Tanure
2023-03-10 9:53 ` Lucas Tanure
2023-03-10 10:44 ` Marc Zyngier
2023-03-10 10:44 ` Marc Zyngier
2023-03-10 10:44 ` Marc Zyngier
2023-03-10 10:44 ` Marc Zyngier
2023-03-10 11:41 ` Peter Geis
2023-03-10 11:41 ` Peter Geis
2023-03-10 11:41 ` Peter Geis
2023-03-10 11:41 ` Peter Geis
2023-03-10 11:56 ` Marc Zyngier
2023-03-10 11:56 ` Marc Zyngier
2023-03-10 11:56 ` Marc Zyngier
2023-03-10 11:56 ` Marc Zyngier
2023-03-10 12:04 ` Peter Geis
2023-03-10 12:04 ` Peter Geis
2023-03-10 12:04 ` Peter Geis
2023-03-10 12:04 ` Peter Geis
2023-03-10 12:12 ` Marc Zyngier
2023-03-10 12:12 ` Marc Zyngier
2023-03-10 12:12 ` Marc Zyngier
2023-03-10 12:12 ` Marc Zyngier
2023-03-10 12:04 ` Robin Murphy
2023-03-10 12:04 ` Robin Murphy
2023-03-10 12:04 ` Robin Murphy
2023-03-10 12:04 ` Robin Murphy
2023-03-14 13:25 ` Lucas Tanure
2023-03-14 13:25 ` Lucas Tanure
2023-03-14 13:25 ` Lucas Tanure
2023-03-14 13:25 ` Lucas Tanure
2023-03-14 14:14 ` Marc Zyngier [this message]
2023-03-14 14:14 ` Marc Zyngier
2023-03-14 14:14 ` Marc Zyngier
2023-03-14 14:14 ` Marc Zyngier
2023-03-10 8:05 ` [PATCH 2/7] PCI: rockchip-dwc: Add rk3588 compatible line Lucas Tanure
2023-03-10 8:05 ` Lucas Tanure
2023-03-10 8:05 ` Lucas Tanure
2023-03-10 8:05 ` Lucas Tanure
2023-03-10 8:05 ` [PATCH 3/7] dt-bindings: phy: rockchip: " Lucas Tanure
2023-03-10 8:05 ` Lucas Tanure
2023-03-10 8:05 ` Lucas Tanure
2023-03-10 8:05 ` Lucas Tanure
2023-03-12 11:31 ` Krzysztof Kozlowski
2023-03-12 11:31 ` Krzysztof Kozlowski
2023-03-12 11:31 ` Krzysztof Kozlowski
2023-03-12 11:31 ` Krzysztof Kozlowski
2023-03-10 8:05 ` [PATCH 4/7] phy: rockchip: Add naneng combo phy support for RK3588 Lucas Tanure
2023-03-10 8:05 ` Lucas Tanure
2023-03-10 8:05 ` Lucas Tanure
2023-03-10 8:05 ` Lucas Tanure
2023-03-10 12:31 ` Peter Geis
2023-03-10 12:31 ` Peter Geis
2023-03-10 12:31 ` Peter Geis
2023-03-10 12:31 ` Peter Geis
2023-03-10 8:05 ` [PATCH 5/7] arm64: dts: rockchip: Add ITS GIC600 configuration for rk3588s Lucas Tanure
2023-03-10 8:05 ` Lucas Tanure
2023-03-10 8:05 ` Lucas Tanure
2023-03-10 8:05 ` Lucas Tanure
2023-03-10 8:05 ` [PATCH 6/7] arm64: dts: rockchip: Add PCIE2.0x1 lane @fe190000 for RK3588s Lucas Tanure
2023-03-10 8:05 ` Lucas Tanure
2023-03-10 8:05 ` Lucas Tanure
2023-03-10 8:05 ` Lucas Tanure
2023-03-10 8:05 ` [PATCH 7/7] arm64: dts: rockchip: RK3588s: Enable PCIE2.0x1 @fe190000 Lucas Tanure
2023-03-10 8:05 ` Lucas Tanure
2023-03-10 8:05 ` Lucas Tanure
2023-03-10 8:05 ` Lucas Tanure
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=86h6unxvwc.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=bhelgaas@google.com \
--cc=devicetree@vger.kernel.org \
--cc=heiko@sntech.de \
--cc=kernel@collabora.com \
--cc=kever.yang@rock-chips.com \
--cc=kishon@kernel.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=kw@linux.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-phy@lists.infradead.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=lpieralisi@kernel.org \
--cc=lucas.tanure@collabora.com \
--cc=pgwipeout@gmail.com \
--cc=piotr.oniszczuk@gmail.com \
--cc=robh+dt@kernel.org \
--cc=robin.murphy@arm.com \
--cc=tglx@linutronix.de \
--cc=vkoul@kernel.org \
--cc=wqu@suse.com \
/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.