From: Andrew Lunn <andrew@lunn.ch>
To: Chris Packham <Chris.Packham@alliedtelesis.co.nz>
Cc: "linus.walleij@linaro.org" <linus.walleij@linaro.org>,
"robh+dt@kernel.org" <robh+dt@kernel.org>,
"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
"will@kernel.org" <will@kernel.org>,
"gregory.clement@bootlin.com" <gregory.clement@bootlin.com>,
"sebastian.hesselbarth@gmail.com"
<sebastian.hesselbarth@gmail.com>,
"kostap@marvell.com" <kostap@marvell.com>,
"robert.marko@sartura.hr" <robert.marko@sartura.hr>,
"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v1 3/4] arm64: dts: marvell: Add Armada 98DX2530 SoC and RD-AC5X board
Date: Fri, 11 Mar 2022 00:25:43 +0100 [thread overview]
Message-ID: <YiqI9/Or4SL6NthP@lunn.ch> (raw)
In-Reply-To: <b6128e83-3f97-e728-66f2-25507d0f7abe@alliedtelesis.co.nz>
> >> + mvDma {
> >> + compatible = "marvell,mv_dma";
> >> + memory-region = <&prestera_rsvd>;
> >> + status = "okay";
> >> + };
> > Is this different to the existing Marvell XOR engine?
>
> Yes it has something to do with the DMA memory for the integrated L3
> switch. Because that driver doesn't exist I'll probably remove this node
> (and the other prestera node below) in v2.
The compatible itself is not so great, since it made me think of the
DMA engine in the SoC. So maybe when the driver is added, it could be
something like prestera_dma?
> >> + sdhci0: sdhci@805c0000 {
> >> + compatible = "marvell,ac5-sdhci", "marvell,armada-ap806-sdhci";
> > This additional compatible should be added to the existing binding
> > document.
> I'll see what differences there are with the ap806-sdhci. I might be
> able to remove it.
It is actually good to have the additional compatible. You might not
spot a difference now, but sometime in the future you do find a
difference which you need to work around in the driver. Having the
compatible in place means you can just change the driver and existing
DT blobs, burnt into flash etc, don't need to change.
> >
> >> + eth0: ethernet@20000 {
> >> + compatible = "marvell,armada-ac5-neta";
> > So it is not compatible with plain nata?
>
> There is some odd muxing setup where the serdes are either SGMII or PCIe
> or can even be connected to the internal switch. Whether the Ethernet
> driver needs to care about it I'm not sure.
Russell King probably knows more about this, but it sounds more like a
comphy issues, not neta. The comphy connects the MAC to a SERDES, and
that SERDES can be SGMII, PCIe or USB.
> >> + nand: nand@805b0000 {
> >> + compatible = "marvell,ac5-nand-controller";
> > The current NAND driver does not work?
>
> This is one of the things I can't test on the board I have (uses eMMC
> instead of NAND). Should I put "marvell,armada-8k-nand-controller" in as
> a placeholder or leave the node out entirely?
I would leave it out if you cannot test it.
Andrew
next prev parent reply other threads:[~2022-03-10 23:26 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-10 3:00 [PATCH v1 0/4] arm64: mvebu: Support for Marvell 98DX2530 (and variants) Chris Packham
2022-03-10 3:00 ` [PATCH v1 1/4] dt-bindings: pinctrl: mvebu: Document bindings for AC5 Chris Packham
2022-03-10 23:25 ` Rob Herring
2022-03-10 23:53 ` Chris Packham
2022-03-11 3:25 ` Chris Packham
2022-03-11 3:59 ` Chris Packham
2022-03-10 3:00 ` [PATCH v1 2/4] pinctrl: mvebu: pinctrl driver for 98DX2530 SoC Chris Packham
2022-03-10 13:59 ` Andrew Lunn
2022-03-10 21:51 ` Chris Packham
2022-03-10 3:00 ` [PATCH v1 3/4] arm64: dts: marvell: Add Armada 98DX2530 SoC and RD-AC5X board Chris Packham
2022-03-10 14:26 ` Andrew Lunn
2022-03-10 22:32 ` Chris Packham
2022-03-10 23:25 ` Andrew Lunn [this message]
2022-03-10 3:00 ` [PATCH v1 4/4] arm64: marvell: enable the 98DX2530 pinctrl driver Chris Packham
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=YiqI9/Or4SL6NthP@lunn.ch \
--to=andrew@lunn.ch \
--cc=Chris.Packham@alliedtelesis.co.nz \
--cc=catalin.marinas@arm.com \
--cc=devicetree@vger.kernel.org \
--cc=gregory.clement@bootlin.com \
--cc=kostap@marvell.com \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=robert.marko@sartura.hr \
--cc=robh+dt@kernel.org \
--cc=sebastian.hesselbarth@gmail.com \
--cc=will@kernel.org \
/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