From: Niklas Cassel <Niklas.Cassel@wdc.com>
To: Conor Dooley <conor@kernel.org>
Cc: "Niklas Cassel" <nks@flawful.org>,
"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
"Krzysztof Wilczyński" <kw@linux.com>,
"Rob Herring" <robh@kernel.org>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>,
"Conor Dooley" <conor+dt@kernel.org>,
"Heiko Stuebner" <heiko@sntech.de>,
"Shawn Lin" <shawn.lin@rock-chips.com>,
"Simon Xue" <xxm@rock-chips.com>,
"Damien Le Moal" <dlemoal@kernel.org>,
"Sebastian Reichel" <sebastian.reichel@collabora.com>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-rockchip@lists.infradead.org"
<linux-rockchip@lists.infradead.org>
Subject: Re: [PATCH v2 3/4] dt-bindings: PCI: dwc: rockchip: Add dma properties
Date: Wed, 25 Oct 2023 20:55:33 +0000 [thread overview]
Message-ID: <ZTmAxH0AXpCN1+G+@x1-carbon> (raw)
In-Reply-To: <ZTl1ZsHvk3DDHWsm@x1-carbon>
On Wed, Oct 25, 2023 at 10:07:02PM +0200, Niklas Cassel wrote:
> Hello Conor,
>
> On Tue, Oct 24, 2023 at 05:30:22PM +0100, Conor Dooley wrote:
> > On Tue, Oct 24, 2023 at 05:10:10PM +0200, Niklas Cassel wrote:
> > > From: Niklas Cassel <niklas.cassel@wdc.com>
> > >
> > > Even though rockchip-dw-pcie.yaml inherits snps,dw-pcie.yaml
> > > using:
> > >
> > > allOf:
> > > - $ref: /schemas/pci/snps,dw-pcie.yaml#
> > >
> > > and snps,dw-pcie.yaml does have the dma properties defined, in order to be
> > > able to use these properties, while still making sure 'make CHECK_DTBS=y'
> > > pass, we need to add these properties to rockchip-dw-pcie.yaml.
> > >
> > > Signed-off-by: Niklas Cassel <niklas.cassel@wdc.com>
> > > ---
> > > .../bindings/pci/rockchip-dw-pcie.yaml | 20 +++++++++++++++++++
> > > 1 file changed, 20 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/pci/rockchip-dw-pcie.yaml b/Documentation/devicetree/bindings/pci/rockchip-dw-pcie.yaml
> > > index 229f8608c535..633f8e0e884f 100644
> > > --- a/Documentation/devicetree/bindings/pci/rockchip-dw-pcie.yaml
> > > +++ b/Documentation/devicetree/bindings/pci/rockchip-dw-pcie.yaml
> > > @@ -35,6 +35,7 @@ properties:
> > > - description: Rockchip designed configuration registers
> > > - description: Config registers
> > > - description: iATU registers
> > > + - description: eDMA registers
> >
> > Same here, is this just for one of the two supported models, or for
> > both?
>
> For the 3 controllers found in rk3568, this range exists for all
> (all of the controllers were synthesized with the eDMA controller).
>
> For the 5 controllers found in rk3588, this range exists for only one of them
> (only one of the controllers was synthesized with the eDMA controller).
>
>
> > > interrupt-names:
> > > + minItems: 5
> > > items:
> > > - const: sys
> > > - const: pmc
> > > - const: msg
> > > - const: legacy
> > > - const: err
> > > + - const: dma0
> > > + - const: dma1
> > > + - const: dma2
> > > + - const: dma3
>
> While all the PCIe controllers on the rk3568 have the embedded DMA controller
> as part of the PCIe controller, they don't have separate IRQs for the eDMA.
> (They will need to use the combined "sys" irq, so the driver will need to read
> an additional register to see that it was an eDMA irq.)
>
> For the rk3588, only one of the 5 PCIe controllers have the eDMA, and that
> controller also has dedicated IRQs for the eDMA.
> (It should also be able to use the combined "sys" irq, but that would be less
> efficient, and AFAICT, the driver currently only works with dedicated IRQs.)
We could go with Sebastian's suggestion to define a 1MB range for "atu", see:
https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/pci/snps%2Cdw-pcie.yaml#L76-L85
Which would allow the driver to probe if the eDMA is there or not
(even if this is strictly bigger than the real ATU_CAP size, the size is still
within the PCIe core's register map).
That would solve the problem that some pcie controllers, with the exact same
compatible, has a "dma" range while others do not.
(All controllers would have a 1MB atu range, and none of them would have the
dma range specified.)
However, we would still have the problem that for the exact same compatible,
some controllers have eDMA irqs specified in interrupts, and some do not...
But perhaps having mandatory atu range (and no dma range) + optional dma irqs
is better than mandatory atu range + optional dma range + optional dma irqs?
(At least from a DT schema maintainability PoV.)
Kind regards,
Niklas
next prev parent reply other threads:[~2023-10-25 20:55 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-24 15:10 [PATCH v2 0/4] rk3588 PCIe improvements Niklas Cassel
2023-10-24 15:10 ` [PATCH v2 1/4] dt-bindings: PCI: dwc: rockchip: Add atu property Niklas Cassel
2023-10-24 16:29 ` Conor Dooley
2023-10-25 20:02 ` Niklas Cassel
2023-10-26 18:35 ` Rob Herring
2023-10-27 14:34 ` Niklas Cassel
2023-10-27 15:56 ` Rob Herring
2023-10-27 16:37 ` Niklas Cassel
2023-10-26 18:20 ` Rob Herring
2023-10-24 15:10 ` [PATCH v2 2/4] arm64: dts: rockchip: add missing mandatory rk3588 PCIe " Niklas Cassel
2023-10-24 15:10 ` [PATCH v2 3/4] dt-bindings: PCI: dwc: rockchip: Add dma properties Niklas Cassel
2023-10-24 16:30 ` Conor Dooley
2023-10-25 20:07 ` Niklas Cassel
2023-10-25 20:55 ` Niklas Cassel [this message]
2023-10-26 14:29 ` Serge Semin
2023-10-26 14:32 ` Serge Semin
2023-10-27 14:51 ` Niklas Cassel
2023-10-24 15:10 ` [PATCH v2 4/4] arm64: dts: rockchip: add missing rk3588 PCIe " Niklas Cassel
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=ZTmAxH0AXpCN1+G+@x1-carbon \
--to=niklas.cassel@wdc.com \
--cc=bhelgaas@google.com \
--cc=conor+dt@kernel.org \
--cc=conor@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dlemoal@kernel.org \
--cc=heiko@sntech.de \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=kw@linux.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=lpieralisi@kernel.org \
--cc=nks@flawful.org \
--cc=robh@kernel.org \
--cc=sebastian.reichel@collabora.com \
--cc=shawn.lin@rock-chips.com \
--cc=xxm@rock-chips.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).