Re: [PATCH v2 3/3] arm64: dts: meson: add GPIO line names to ODROID N2/N2+
On Wed, Apr 7, 2021 at 6:27 AM Christian Hewitt wrote: > > From: Hyeonki Hong > > Add GPIO line-name identifiers to the ODROID N2/N2+ common dtsi. > > Signed-off-by: Hyeonki Hong > Signed-off-by: Christian Hewitt > Reviewed-by: Neil Armstrong Acked-by: Martin Blumenstingl
Re: [PATCH v2 2/3] arm64: dts: meson: add saradc node to ODROID N2/N2+
On Wed, Apr 7, 2021 at 6:27 AM Christian Hewitt wrote: > > From: Hyeonki Hong > > Add the meson saradc node to the ODROID N2/N2+ common dtsi. > > Signed-off-by: Hyeonki Hong > Signed-off-by: Christian Hewitt Reviewed-by: Martin Blumenstingl
Re: [PATCH net-next] net: dsa: lantiq_gswip: Add support for dumping the registers
On Tue, Apr 13, 2021 at 1:45 AM Andrew Lunn wrote: [...] > > > and a few people have forked it and modified it for other DSA > > > switches. At some point we might want to try to merge the forks back > > > together so we have one tool to dump any switch. > > actually I was wondering if there is some way to make the registers > > "easier to read" in userspace. > > You can add decoding to ethtool. The marvell chips have this, to some > extent. But the ethtool API is limited to just port registers, and > there can be a lot more registers which are not associated to a > port. devlink gives you access to these additional registers. oh, then that's actually also a problem with my patch: the .get_regs implementation currently also uses five registers which are not related to the specific port. noted in case I re-send this as .get_regs patch instead of moving over to devlink. Thanks for the hints as always! Martin
Re: [PATCH net-next] net: dsa: lantiq_gswip: Add support for dumping the registers
Hi Andrew, On Mon, Apr 12, 2021 at 1:16 AM Andrew Lunn wrote: > > On Sun, Apr 11, 2021 at 10:55:11PM +0200, Martin Blumenstingl wrote: > > Add support for .get_regs_len and .get_regs so it is easier to find out > > about the state of the ports on the GSWIP hardware. For this we > > specifically add the GSWIP_MAC_PSTATp(port) and GSWIP_MDIO_STATp(port) > > register #defines as these contain the current port status (as well as > > the result of the auto polling mechanism). Other global and per-port > > registers which are also considered useful are included as well. > > Although this is O.K, there has been a trend towards using devlink > regions for this, and other register sets in the switch. Take a look > at drivers/net/dsa/mv88e6xxx/devlink.c. > > There is a userspace tool for the mv88e6xxx devlink regions here: > > https://github.com/lunn/mv88e6xxx_dump > > and a few people have forked it and modified it for other DSA > switches. At some point we might want to try to merge the forks back > together so we have one tool to dump any switch. actually I was wondering if there is some way to make the registers "easier to read" in userspace. It turns out there is :-) Hauke, which approach do you recommend?: - update this patch with your suggestion and ask Andrew to still merge it soon-ish - put this topic somewhere on my or your TODO-list and come up with a devlink solution at some point in the future Best regards, Martin
[PATCH net-next] net: dsa: lantiq_gswip: Add support for dumping the registers
Add support for .get_regs_len and .get_regs so it is easier to find out
about the state of the ports on the GSWIP hardware. For this we
specifically add the GSWIP_MAC_PSTATp(port) and GSWIP_MDIO_STATp(port)
register #defines as these contain the current port status (as well as
the result of the auto polling mechanism). Other global and per-port
registers which are also considered useful are included as well.
Acked-by: Hauke Mehrtens
Signed-off-by: Martin Blumenstingl
---
drivers/net/dsa/lantiq_gswip.c | 83 ++
1 file changed, 83 insertions(+)
diff --git a/drivers/net/dsa/lantiq_gswip.c b/drivers/net/dsa/lantiq_gswip.c
index 314ae78bbdd6..d3cfc72644ff 100644
--- a/drivers/net/dsa/lantiq_gswip.c
+++ b/drivers/net/dsa/lantiq_gswip.c
@@ -90,6 +90,21 @@
GSWIP_MDIO_PHY_LINK_MASK | \
GSWIP_MDIO_PHY_SPEED_MASK | \
GSWIP_MDIO_PHY_FDUP_MASK)
+#define GSWIP_MDIO_STATp(p)(0x16 + (p))
+#define GSWIP_MDIO_STAT_RXACT BIT(10)
+#define GSWIP_MDIO_STAT_TXACT BIT(9)
+#define GSWIP_MDIO_STAT_CLK_STOP_CAPABBIT(8)
+#define GSWIP_MDIO_STAT_EEE_CAPABLE BIT(7)
+#define GSWIP_MDIO_STAT_PACT BIT(6)
+#define GSWIP_MDIO_STAT_LSTAT BIT(5)
+#define GSWIP_MDIO_STAT_SPEED_M10 0x00
+#define GSWIP_MDIO_STAT_SPEED_M1000x08
+#define GSWIP_MDIO_STAT_SPEED_1G 0x10
+#define GSWIP_MDIO_STAT_SPEED_RESERVED0x18
+#define GSWIP_MDIO_STAT_SPEED_MASK0x18
+#define GSWIP_MDIO_STAT_FDUP BIT(2)
+#define GSWIP_MDIO_STAT_RXPAUEN BIT(1)
+#define GSWIP_MDIO_STAT_TXPAUEN BIT(0)
/* GSWIP MII Registers */
#define GSWIP_MII_CFGp(p) (0x2 * (p))
@@ -195,6 +210,19 @@
#define GSWIP_PCE_DEFPVID(p) (0x486 + ((p) * 0xA))
#define GSWIP_MAC_FLEN 0x8C5
+#define GSWIP_MAC_PSTATp(p)(0x900 + ((p) * 0xC))
+#define GSWIP_MAC_PSTAT_PACT BIT(11)
+#define GSWIP_MAC_PSTAT_GBIT BIT(10)
+#define GSWIP_MAC_PSTAT_MBIT BIT(9)
+#define GSWIP_MAC_PSTAT_FDUP BIT(8)
+#define GSWIP_MAC_PSTAT_RXPAU BIT(7)
+#define GSWIP_MAC_PSTAT_TXPAU BIT(6)
+#define GSWIP_MAC_PSTAT_RXPAUEN BIT(5)
+#define GSWIP_MAC_PSTAT_TXPAUEN BIT(4)
+#define GSWIP_MAC_PSTAT_LSTAT BIT(3)
+#define GSWIP_MAC_PSTAT_CRS BIT(2)
+#define GSWIP_MAC_PSTAT_TXLPI BIT(1)
+#define GSWIP_MAC_PSTAT_RXLPI BIT(0)
#define GSWIP_MAC_CTRL_0p(p) (0x903 + ((p) * 0xC))
#define GSWIP_MAC_CTRL_0_PADENBIT(8)
#define GSWIP_MAC_CTRL_0_FCS_EN BIT(7)
@@ -701,6 +729,57 @@ static void gswip_port_disable(struct dsa_switch *ds, int
port)
GSWIP_SDMA_PCTRLp(port));
}
+static int gswip_get_regs_len(struct dsa_switch *ds, int port)
+{
+ return 17 * sizeof(u32);
+}
+
+static void gswip_get_regs(struct dsa_switch *ds, int port,
+ struct ethtool_regs *regs, void *_p)
+{
+ struct gswip_priv *priv = ds->priv;
+ u32 *p = _p;
+
+ regs->version = gswip_switch_r(priv, GSWIP_VERSION);
+
+ memset(p, 0xff, 17 * sizeof(u32));
+
+ p[0] = gswip_mdio_r(priv, GSWIP_MDIO_GLOB);
+ p[1] = gswip_mdio_r(priv, GSWIP_MDIO_CTRL);
+ p[2] = gswip_mdio_r(priv, GSWIP_MDIO_MDC_CFG0);
+ p[3] = gswip_mdio_r(priv, GSWIP_MDIO_MDC_CFG1);
+
+ if (!dsa_is_cpu_port(priv->ds, port)) {
+ p[4] = gswip_mdio_r(priv, GSWIP_MDIO_PHYp(port));
+ p[5] = gswip_mdio_r(priv, GSWIP_MDIO_STATp(port));
+ p[6] = gswip_mii_r(priv, GSWIP_MII_CFGp(port));
+ }
+
+ switch (port) {
+ case 0:
+ p[7] = gswip_mii_r(priv, GSWIP_MII_PCDU0);
+ break;
+ case 1:
+ p[7] = gswip_mii_r(priv, GSWIP_MII_PCDU1);
+ break;
+ case 5:
+ p[7] = gswip_mii_r(priv, GSWIP_MII_PCDU5);
+ break;
+ default:
+ break;
+ }
+
+ p[8] = gswip_switch_r(priv, GSWIP_PCE_PCTRL_0p(port));
+ p[9] = gswip_switch_r(priv, GSWIP_PCE_VCTRL(port));
+ p[10] = gswip_switch_r(priv, GSWIP_PCE_DEFPVID(port));
+ p[11] = gswip_switch_r(priv, GSWIP_MAC_FLEN);
+ p[12] = gswip_switch_r(priv, GSWIP_MAC_PSTATp(port));
+ p[13] = gswip_switch_r(priv, GSWIP_MAC_CTRL_0p(port));
+ p[14] = gswip_switch_r(priv, GSWIP_MAC_CTRL_2p(port));
+ p[15] = gswip_switch_r(priv, GSWIP_FDMA_PCTRLp(port));
+ p[16] = gswip_switch_r(priv, GSWIP_SDMA_PCTRLp(port));
+}
+
static int gswip_pce_load_microcode(struct gswip_priv *priv)
{
int i;
@@ -1795,6 +1874,8 @@ static const struct dsa_switch_ops
gswip_xrx200_switch_ops = {
.setup = gswip_setup,
.port_enable= gswip_port_enable,
.por
Re: [PATCH stable-5.4 0/2] net: dsa: lantiq_gswip: backports for Linux 5.4
Hi Sasha,
On Sun, Apr 11, 2021 at 6:48 PM Sasha Levin wrote:
>
> On Sun, Apr 11, 2021 at 12:23:42PM +0200, Martin Blumenstingl wrote:
> >Hello,
> >
> >This backports two patches (which could not be backported automatically
> >because the gswip_phylink_mac_link_up function is different in Linux 5.4
> >compared to 5.7 and newer) for the lantiq_gswip driver:
> >- commit 3e9005be8afc902b9f5497495898202d335d upstream.
> >- commit 4b5923249b8fa427943b50b8f35265176472be38 upstream.
> >
> >This is the first time that I am doing such a backport so I am not
> >sure how to mention the required modifications. I added them at the
> >bottom of each patch with another Signed-off-by. If this is not correct
> >then please suggest how I can do it rights.
>
> Hey Martin,
>
> Your backport works, but I'd rather take 5b502a7b2992 ("net: dsa:
> propagate resolved link config via mac_link_up()") along with the
> backport instead. This means that we don't diverge from upstream too
> much and will make future backports easier.
>
> I've queued up these 3 commits to 5.4, thanks!
in general I am fine with your suggested approach. however, I think at
least one more backport is required then:
91a208f2185ad4855ff03c342d0b7e4f5fc6f5df ("net: phylink: propagate
resolved link config via mac_link_up()")
Patches should be backported in a specific order also so we don't
break git bisect:
- phylink patch
- dsa patch
- the two lantiq GSWIP patches
Best regards,
Martin
[PATCH stable-5.4 2/2] net: dsa: lantiq_gswip: Configure all remaining GSWIP_MII_CFG bits
commit 4b5923249b8fa427943b50b8f35265176472be38 upstream.
There are a few more bits in the GSWIP_MII_CFG register for which we
did rely on the boot-loader (or the hardware defaults) to set them up
properly.
For some external RMII PHYs we need to select the GSWIP_MII_CFG_RMII_CLK
bit and also we should un-set it for non-RMII PHYs. The
GSWIP_MII_CFG_RMII_CLK bit is ignored for other PHY connection modes.
The GSWIP IP also supports in-band auto-negotiation for RGMII PHYs when
the GSWIP_MII_CFG_RGMII_IBS bit is set. Clear this bit always as there's
no known hardware which uses this (so it is not tested yet).
Clear the xMII isolation bit when set at initialization time if it was
previously set by the bootloader. Not doing so could lead to no traffic
(neither RX nor TX) on a port with this bit set.
While here, also add the GSWIP_MII_CFG_RESET bit. We don't need to
manage it because this bit is self-clearning when set. We still add it
here to get a better overview of the GSWIP_MII_CFG register.
Fixes: 14fceff4771e51 ("net: dsa: Add Lantiq / Intel DSA driver for vrx200")
Cc: sta...@vger.kernel.org
Suggested-by: Hauke Mehrtens
Acked-by: Hauke Mehrtens
Signed-off-by: Martin Blumenstingl
Reviewed-by: Florian Fainelli
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
[ Updated after the upstream commit 3e9005be8 required some changes
for Linux 5.4 ]
Signed-off-by: Martin Blumenstingl
---
drivers/net/dsa/lantiq_gswip.c | 19 ---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/drivers/net/dsa/lantiq_gswip.c b/drivers/net/dsa/lantiq_gswip.c
index e0f5d406e6c0..dc75e798dbff 100644
--- a/drivers/net/dsa/lantiq_gswip.c
+++ b/drivers/net/dsa/lantiq_gswip.c
@@ -93,8 +93,12 @@
/* GSWIP MII Registers */
#define GSWIP_MII_CFGp(p) (0x2 * (p))
+#define GSWIP_MII_CFG_RESET BIT(15)
#define GSWIP_MII_CFG_EN BIT(14)
+#define GSWIP_MII_CFG_ISOLATE BIT(13)
#define GSWIP_MII_CFG_LDCLKDISBIT(12)
+#define GSWIP_MII_CFG_RGMII_IBS BIT(8)
+#define GSWIP_MII_CFG_RMII_CLKBIT(7)
#define GSWIP_MII_CFG_MODE_MIIP 0x0
#define GSWIP_MII_CFG_MODE_MIIM 0x1
#define GSWIP_MII_CFG_MODE_RMIIP 0x2
@@ -817,9 +821,11 @@ static int gswip_setup(struct dsa_switch *ds)
/* Configure the MDIO Clock 2.5 MHz */
gswip_mdio_mask(priv, 0xff, 0x09, GSWIP_MDIO_MDC_CFG1);
- /* Disable the xMII link */
+ /* Disable the xMII interface and clear it's isolation bit */
for (i = 0; i < priv->hw_info->max_ports; i++)
- gswip_mii_mask_cfg(priv, GSWIP_MII_CFG_EN, 0, i);
+ gswip_mii_mask_cfg(priv,
+ GSWIP_MII_CFG_EN | GSWIP_MII_CFG_ISOLATE,
+ 0, i);
/* enable special tag insertion on cpu port */
gswip_switch_mask(priv, 0, GSWIP_FDMA_PCTRL_STEN,
@@ -1594,6 +1600,9 @@ static void gswip_phylink_mac_config(struct dsa_switch
*ds, int port,
break;
case PHY_INTERFACE_MODE_RMII:
miicfg |= GSWIP_MII_CFG_MODE_RMIIM;
+
+ /* Configure the RMII clock as output: */
+ miicfg |= GSWIP_MII_CFG_RMII_CLK;
break;
case PHY_INTERFACE_MODE_RGMII:
case PHY_INTERFACE_MODE_RGMII_ID:
@@ -1606,7 +1615,11 @@ static void gswip_phylink_mac_config(struct dsa_switch
*ds, int port,
"Unsupported interface: %d\n", state->interface);
return;
}
- gswip_mii_mask_cfg(priv, GSWIP_MII_CFG_MODE_MASK, miicfg, port);
+
+ gswip_mii_mask_cfg(priv,
+ GSWIP_MII_CFG_MODE_MASK | GSWIP_MII_CFG_RMII_CLK |
+ GSWIP_MII_CFG_RGMII_IBS | GSWIP_MII_CFG_LDCLKDIS,
+ miicfg, port);
gswip_port_set_speed(priv, port, state->speed, state->interface);
gswip_port_set_duplex(priv, port, state->duplex);
--
2.31.1
[PATCH stable-5.4 1/2] net: dsa: lantiq_gswip: Don't use PHY auto polling
commit 3e9005be8afc902b9f5497495898202d335d upstream.
PHY auto polling on the GSWIP hardware can be used so link changes
(speed, link up/down, etc.) can be detected automatically. Internally
GSWIP reads the PHY's registers for this functionality. Based on this
automatic detection GSWIP can also automatically re-configure it's port
settings. Unfortunately this auto polling (and configuration) mechanism
seems to cause various issues observed by different people on different
devices:
- FritzBox 7360v2: the two Gbit/s ports (connected to the two internal
PHY11G instances) are working fine but the two Fast Ethernet ports
(using an AR8030 RMII PHY) are completely dead (neither RX nor TX are
received). It turns out that the AR8030 PHY sets the BMSR_ESTATEN bit
as well as the ESTATUS_1000_TFULL and ESTATUS_1000_XFULL bits. This
makes the PHY auto polling state machine (rightfully?) think that the
established link speed (when the other side is Gbit/s capable) is
1Gbit/s.
- None of the Ethernet ports on the Zyxel P-2812HNU-F1 (two are
connected to the internal PHY11G GPHYs while the other three are
external RGMII PHYs) are working. Neither RX nor TX traffic was
observed. It is not clear which part of the PHY auto polling state-
machine caused this.
- FritzBox 7412 (only one LAN port which is connected to one of the
internal GPHYs running in PHY22F / Fast Ethernet mode) was seeing
random disconnects (link down events could be seen). Sometimes all
traffic would stop after such disconnect. It is not clear which part
of the PHY auto polling state-machine cauased this.
- TP-Link TD-W9980 (two ports are connected to the internal GPHYs
running in PHY11G / Gbit/s mode, the other two are external RGMII
PHYs) was affected by similar issues as the FritzBox 7412 just without
the "link down" events
Switch to software based configuration instead of PHY auto polling (and
letting the GSWIP hardware configure the ports automatically) for the
following link parameters:
- link up/down
- link speed
- full/half duplex
- flow control (RX / TX pause)
After a big round of manual testing by various people (who helped test
this on OpenWrt) it turns out that this fixes all reported issues.
Additionally it can be considered more future proof because any
"quirk" which is implemented for a PHY on the driver side can now be
used with the GSWIP hardware as well because Linux is in control of the
link parameters.
As a nice side-effect this also solves a problem where fixed-links were
not supported previously because we were relying on the PHY auto polling
mechanism, which cannot work for fixed-links as there's no PHY from
where it can read the registers. Configuring the link settings on the
GSWIP ports means that we now use the settings from device-tree also for
ports with fixed-links.
Fixes: 14fceff4771e51 ("net: dsa: Add Lantiq / Intel DSA driver for vrx200")
Fixes: 3e6fdeb28f4c33 ("net: dsa: lantiq_gswip: Let GSWIP automatically set the
xMII clock")
Cc: sta...@vger.kernel.org
Acked-by: Hauke Mehrtens
Reviewed-by: Andrew Lunn
Signed-off-by: Martin Blumenstingl
Reviewed-by: Florian Fainelli
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
[ Move gswip_port_set_{speed, duplex, pause} calls from
gswip_phylink_mac_link_up to gswip_phylink_mac_config because the
data required for these functions is not available inside
gswip_phylink_mac_link_up yet in Linux 5.4 (it was only added with
Linux 5.7). ]
Signed-off-by: Martin Blumenstingl
---
drivers/net/dsa/lantiq_gswip.c | 186 -
1 file changed, 160 insertions(+), 26 deletions(-)
diff --git a/drivers/net/dsa/lantiq_gswip.c b/drivers/net/dsa/lantiq_gswip.c
index 14019b3197f6..e0f5d406e6c0 100644
--- a/drivers/net/dsa/lantiq_gswip.c
+++ b/drivers/net/dsa/lantiq_gswip.c
@@ -190,6 +190,23 @@
#define GSWIP_PCE_DEFPVID(p) (0x486 + ((p) * 0xA))
#define GSWIP_MAC_FLEN 0x8C5
+#define GSWIP_MAC_CTRL_0p(p) (0x903 + ((p) * 0xC))
+#define GSWIP_MAC_CTRL_0_PADENBIT(8)
+#define GSWIP_MAC_CTRL_0_FCS_EN BIT(7)
+#define GSWIP_MAC_CTRL_0_FCON_MASK0x0070
+#define GSWIP_MAC_CTRL_0_FCON_AUTO0x
+#define GSWIP_MAC_CTRL_0_FCON_RX 0x0010
+#define GSWIP_MAC_CTRL_0_FCON_TX 0x0020
+#define GSWIP_MAC_CTRL_0_FCON_RXTX0x0030
+#define GSWIP_MAC_CTRL_0_FCON_NONE0x0040
+#define GSWIP_MAC_CTRL_0_FDUP_MASK0x000C
+#define GSWIP_MAC_CTRL_0_FDUP_AUTO0x
+#define GSWIP_MAC_CTRL_0_FDUP_EN 0x0004
+#define GSWIP_MAC_CTRL_0_FDUP_DIS 0x000C
+#define GSWIP_MAC_CTRL_0_GMII_MASK0x0003
+#define GSWIP_MAC_CTRL_0_GMII_AUTO0x
+#define GSWIP_MAC_CTRL_0_GMII_MII 0x0001
+#define GSWIP_MAC_CTRL_0_GMII_RGMII 0x0002
#define GSWIP_MAC_CTRL_2p(p) (0x905 + ((p) * 0xC))
#define GSWIP_MAC_CTRL_2_MLEN BIT(3) /* Maximum Untagged Frame Lnegt
[PATCH stable-5.4 0/2] net: dsa: lantiq_gswip: backports for Linux 5.4
Hello, This backports two patches (which could not be backported automatically because the gswip_phylink_mac_link_up function is different in Linux 5.4 compared to 5.7 and newer) for the lantiq_gswip driver: - commit 3e9005be8afc902b9f5497495898202d335d upstream. - commit 4b5923249b8fa427943b50b8f35265176472be38 upstream. This is the first time that I am doing such a backport so I am not sure how to mention the required modifications. I added them at the bottom of each patch with another Signed-off-by. If this is not correct then please suggest how I can do it rights. Thank you! Martin Martin Blumenstingl (2): net: dsa: lantiq_gswip: Don't use PHY auto polling net: dsa: lantiq_gswip: Configure all remaining GSWIP_MII_CFG bits drivers/net/dsa/lantiq_gswip.c | 203 - 1 file changed, 175 insertions(+), 28 deletions(-) -- 2.31.1
Re: [PATCH] staging: media: meson: vdec: matched alignment with parenthesis
On Fri, Apr 9, 2021 at 7:00 PM Mitali Borkar wrote: > > Looks good, will try this. if you re-send this patch then please include our mailing list: linux-amlo...@lists.infradead.org Thank you! Martin
Re: [PATCH net v2 1/2] net: dsa: lantiq_gswip: Don't use PHY auto polling
Hello Vladimir, On Fri, Apr 9, 2021 at 12:46 AM Vladimir Oltean wrote: > > On Thu, Apr 08, 2021 at 08:38:27PM +0200, Martin Blumenstingl wrote: > > PHY auto polling on the GSWIP hardware can be used so link changes > > (speed, link up/down, etc.) can be detected automatically. Internally > > GSWIP reads the PHY's registers for this functionality. Based on this > > automatic detection GSWIP can also automatically re-configure it's port > > settings. Unfortunately this auto polling (and configuration) mechanism > > seems to cause various issues observed by different people on different > > devices: > > - FritzBox 7360v2: the two Gbit/s ports (connected to the two internal > > PHY11G instances) are working fine but the two Fast Ethernet ports > > (using an AR8030 RMII PHY) are completely dead (neither RX nor TX are > > received). It turns out that the AR8030 PHY sets the BMSR_ESTATEN bit > > as well as the ESTATUS_1000_TFULL and ESTATUS_1000_XFULL bits. This > > makes the PHY auto polling state machine (rightfully?) think that the > > established link speed (when the other side is Gbit/s capable) is > > 1Gbit/s. > > Why do you say "rightfully"? The PHY is gigabit capable, and it reports > that via the Extended Status register. This is one of the reasons why > the "advertising" and "supported" link modes are separate concepts, > because even though you support gigabit, you don't advertise it because > you are in RMII mode. according to the marketing materials of the AR8030 it is a "Ultra low-power single RMII Fast Ethernet PHY" based on that I am referring to this PHY as "not Gbit/s capable" (other PHYs from the AR803x series are Gbit/s capable though) > How does turning off the auto polling feature help circumvent the > Atheros PHY reporting "issue"? Do we even know that is the problem, or > is it simply a guess on your part based on something that looked strange? I have a patch in my queue (which I'll send for the next -net-next cycle) which adds "ethtool -d" (.get_regs) support to the GSWIP driver. There are multiple status registers, one of them indicates that the link speed (as result of the auto polling mechanism) is 1Gbit/s [...] > > Switch to software based configuration instead of PHY auto polling (and > > letting the GSWIP hardware configure the ports automatically) for the > > following link parameters: > > - link up/down > > - link speed > > - full/half duplex > > - flow control (RX / TX pause) > > What does the auto polling feature consist of, exactly? Is there some > sort of microcontroller accessing the MDIO bus simultaneously with > Linux? I believe the answer is yes, but there's no clear description in the datasheet for a newer GSWIP revision [0] "Figure 8" on page 41 (or page 39 if you go by the numbers at the bottom of each page) has a description of the state machine logic. If I understood Hauke correct the "not fiber" part is only checked for newer GSWIP revisions Please note that the datasheet from [0] refers to part number GSW140 which is a stand-alone IC. The GSWIP driver (currently) supports an older revision (at least two generations older) of GSWIP which is built into Lantiq xRX200 and xRX300 SoCs. Best regards, Martin [0] https://www.maxlinear.com/document/index?id=23266=1033=Datasheet=GSW140=617930_GSW140_DS_Rev1.7.pdf=GSW140
Re: [PATCH] PCI: dwc/intel-gw: Fix enabling the legacy PCI interrupt lines
Hi Lorenzo,
On Tue, Mar 23, 2021 at 12:36 PM Lorenzo Pieralisi
wrote:
>
> On Wed, Jan 06, 2021 at 02:55:40PM +0100, Martin Blumenstingl wrote:
> > The legacy PCI interrupt lines need to be enabled using PCIE_APP_IRNEN
> > bits 13 (INTA), 14 (INTB), 15 (INTC) and 16 (INTD). The old code however
> > was taking (for example) "13" as raw value instead of taking BIT(13).
> > Define the legacy PCI interrupt bits using the BIT() macro and then use
> > these in PCIE_APP_IRN_INT.
> >
> > Fixes: ed22aaaede44 ("PCI: dwc: intel: PCIe RC controller driver")
> > Signed-off-by: Martin Blumenstingl
> > ---
> > drivers/pci/controller/dwc/pcie-intel-gw.c | 10 ++
> > 1 file changed, 6 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/pci/controller/dwc/pcie-intel-gw.c
> > b/drivers/pci/controller/dwc/pcie-intel-gw.c
> > index 0cedd1f95f37..ae96bfbb6c83 100644
> > --- a/drivers/pci/controller/dwc/pcie-intel-gw.c
> > +++ b/drivers/pci/controller/dwc/pcie-intel-gw.c
> > @@ -39,6 +39,10 @@
> > #define PCIE_APP_IRN_PM_TO_ACK BIT(9)
> > #define PCIE_APP_IRN_LINK_AUTO_BW_STAT BIT(11)
> > #define PCIE_APP_IRN_BW_MGT BIT(12)
> > +#define PCIE_APP_IRN_INTABIT(13)
> > +#define PCIE_APP_IRN_INTBBIT(14)
> > +#define PCIE_APP_IRN_INTCBIT(15)
> > +#define PCIE_APP_IRN_INTDBIT(16)
> > #define PCIE_APP_IRN_MSG_LTR BIT(18)
> > #define PCIE_APP_IRN_SYS_ERR_RC BIT(29)
> > #define PCIE_APP_INTX_OFST 12
> > @@ -48,10 +52,8 @@
> > PCIE_APP_IRN_RX_VDM_MSG | PCIE_APP_IRN_SYS_ERR_RC | \
> > PCIE_APP_IRN_PM_TO_ACK | PCIE_APP_IRN_MSG_LTR | \
> > PCIE_APP_IRN_BW_MGT | PCIE_APP_IRN_LINK_AUTO_BW_STAT | \
> > - (PCIE_APP_INTX_OFST + PCI_INTERRUPT_INTA) | \
> > - (PCIE_APP_INTX_OFST + PCI_INTERRUPT_INTB) | \
> > - (PCIE_APP_INTX_OFST + PCI_INTERRUPT_INTC) | \
> > - (PCIE_APP_INTX_OFST + PCI_INTERRUPT_INTD))
> > + PCIE_APP_IRN_INTA | PCIE_APP_IRN_INTB | \
> > + PCIE_APP_IRN_INTC | PCIE_APP_IRN_INTD)
> >
> > #define BUS_IATU_OFFSET SZ_256M
> > #define RESET_INTERVAL_MS100
>
> This looks like a significant bug - which in turn raises the question
> on how well this driver has been tested.
to give them the benefit of doubt: maybe only MSIs were tested
> Dilip, can you review and ACK asap please ?
>From "Re: MaxLinear, please maintain your drivers was Re: [PATCH]
leds: lgm: fix gpiolib dependency" [0]:
> Please send any Lightning Mountain SoC related issues email to Rahul
> Tanwar (rtan...@maxlinear.com) and I will ensure that I address the
> issues in a timely manner.
so I added rtan...@maxlinear.com to this email
Best regards,
Martin
[0] https://lkml.org/lkml/2021/3/16/282
[PATCH net v2 2/2] net: dsa: lantiq_gswip: Configure all remaining GSWIP_MII_CFG bits
There are a few more bits in the GSWIP_MII_CFG register for which we
did rely on the boot-loader (or the hardware defaults) to set them up
properly.
For some external RMII PHYs we need to select the GSWIP_MII_CFG_RMII_CLK
bit and also we should un-set it for non-RMII PHYs. The
GSWIP_MII_CFG_RMII_CLK bit is ignored for other PHY connection modes.
The GSWIP IP also supports in-band auto-negotiation for RGMII PHYs when
the GSWIP_MII_CFG_RGMII_IBS bit is set. Clear this bit always as there's
no known hardware which uses this (so it is not tested yet).
Clear the xMII isolation bit when set at initialization time if it was
previously set by the bootloader. Not doing so could lead to no traffic
(neither RX nor TX) on a port with this bit set.
While here, also add the GSWIP_MII_CFG_RESET bit. We don't need to
manage it because this bit is self-clearning when set. We still add it
here to get a better overview of the GSWIP_MII_CFG register.
Fixes: 14fceff4771e51 ("net: dsa: Add Lantiq / Intel DSA driver for vrx200")
Cc: sta...@vger.kernel.org
Suggested-by: Hauke Mehrtens
Acked-by: Hauke Mehrtens
Signed-off-by: Martin Blumenstingl
---
drivers/net/dsa/lantiq_gswip.c | 19 ---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/drivers/net/dsa/lantiq_gswip.c b/drivers/net/dsa/lantiq_gswip.c
index 126d4ea868ba..bf5c62e5c0b0 100644
--- a/drivers/net/dsa/lantiq_gswip.c
+++ b/drivers/net/dsa/lantiq_gswip.c
@@ -93,8 +93,12 @@
/* GSWIP MII Registers */
#define GSWIP_MII_CFGp(p) (0x2 * (p))
+#define GSWIP_MII_CFG_RESET BIT(15)
#define GSWIP_MII_CFG_EN BIT(14)
+#define GSWIP_MII_CFG_ISOLATE BIT(13)
#define GSWIP_MII_CFG_LDCLKDISBIT(12)
+#define GSWIP_MII_CFG_RGMII_IBS BIT(8)
+#define GSWIP_MII_CFG_RMII_CLKBIT(7)
#define GSWIP_MII_CFG_MODE_MIIP 0x0
#define GSWIP_MII_CFG_MODE_MIIM 0x1
#define GSWIP_MII_CFG_MODE_RMIIP 0x2
@@ -821,9 +825,11 @@ static int gswip_setup(struct dsa_switch *ds)
/* Configure the MDIO Clock 2.5 MHz */
gswip_mdio_mask(priv, 0xff, 0x09, GSWIP_MDIO_MDC_CFG1);
- /* Disable the xMII link */
+ /* Disable the xMII interface and clear it's isolation bit */
for (i = 0; i < priv->hw_info->max_ports; i++)
- gswip_mii_mask_cfg(priv, GSWIP_MII_CFG_EN, 0, i);
+ gswip_mii_mask_cfg(priv,
+ GSWIP_MII_CFG_EN | GSWIP_MII_CFG_ISOLATE,
+ 0, i);
/* enable special tag insertion on cpu port */
gswip_switch_mask(priv, 0, GSWIP_FDMA_PCTRL_STEN,
@@ -1597,6 +1603,9 @@ static void gswip_phylink_mac_config(struct dsa_switch
*ds, int port,
break;
case PHY_INTERFACE_MODE_RMII:
miicfg |= GSWIP_MII_CFG_MODE_RMIIM;
+
+ /* Configure the RMII clock as output: */
+ miicfg |= GSWIP_MII_CFG_RMII_CLK;
break;
case PHY_INTERFACE_MODE_RGMII:
case PHY_INTERFACE_MODE_RGMII_ID:
@@ -1609,7 +1618,11 @@ static void gswip_phylink_mac_config(struct dsa_switch
*ds, int port,
"Unsupported interface: %d\n", state->interface);
return;
}
- gswip_mii_mask_cfg(priv, GSWIP_MII_CFG_MODE_MASK, miicfg, port);
+
+ gswip_mii_mask_cfg(priv,
+ GSWIP_MII_CFG_MODE_MASK | GSWIP_MII_CFG_RMII_CLK |
+ GSWIP_MII_CFG_RGMII_IBS | GSWIP_MII_CFG_LDCLKDIS,
+ miicfg, port);
switch (state->interface) {
case PHY_INTERFACE_MODE_RGMII_ID:
--
2.31.1
[PATCH net v2 1/2] net: dsa: lantiq_gswip: Don't use PHY auto polling
PHY auto polling on the GSWIP hardware can be used so link changes
(speed, link up/down, etc.) can be detected automatically. Internally
GSWIP reads the PHY's registers for this functionality. Based on this
automatic detection GSWIP can also automatically re-configure it's port
settings. Unfortunately this auto polling (and configuration) mechanism
seems to cause various issues observed by different people on different
devices:
- FritzBox 7360v2: the two Gbit/s ports (connected to the two internal
PHY11G instances) are working fine but the two Fast Ethernet ports
(using an AR8030 RMII PHY) are completely dead (neither RX nor TX are
received). It turns out that the AR8030 PHY sets the BMSR_ESTATEN bit
as well as the ESTATUS_1000_TFULL and ESTATUS_1000_XFULL bits. This
makes the PHY auto polling state machine (rightfully?) think that the
established link speed (when the other side is Gbit/s capable) is
1Gbit/s.
- None of the Ethernet ports on the Zyxel P-2812HNU-F1 (two are
connected to the internal PHY11G GPHYs while the other three are
external RGMII PHYs) are working. Neither RX nor TX traffic was
observed. It is not clear which part of the PHY auto polling state-
machine caused this.
- FritzBox 7412 (only one LAN port which is connected to one of the
internal GPHYs running in PHY22F / Fast Ethernet mode) was seeing
random disconnects (link down events could be seen). Sometimes all
traffic would stop after such disconnect. It is not clear which part
of the PHY auto polling state-machine cauased this.
- TP-Link TD-W9980 (two ports are connected to the internal GPHYs
running in PHY11G / Gbit/s mode, the other two are external RGMII
PHYs) was affected by similar issues as the FritzBox 7412 just without
the "link down" events
Switch to software based configuration instead of PHY auto polling (and
letting the GSWIP hardware configure the ports automatically) for the
following link parameters:
- link up/down
- link speed
- full/half duplex
- flow control (RX / TX pause)
After a big round of manual testing by various people (who helped test
this on OpenWrt) it turns out that this fixes all reported issues.
Additionally it can be considered more future proof because any
"quirk" which is implemented for a PHY on the driver side can now be
used with the GSWIP hardware as well because Linux is in control of the
link parameters.
As a nice side-effect this also solves a problem where fixed-links were
not supported previously because we were relying on the PHY auto polling
mechanism, which cannot work for fixed-links as there's no PHY from
where it can read the registers. Configuring the link settings on the
GSWIP ports means that we now use the settings from device-tree also for
ports with fixed-links.
Fixes: 14fceff4771e51 ("net: dsa: Add Lantiq / Intel DSA driver for vrx200")
Fixes: 3e6fdeb28f4c33 ("net: dsa: lantiq_gswip: Let GSWIP automatically set the
xMII clock")
Cc: sta...@vger.kernel.org
Acked-by: Hauke Mehrtens
Reviewed-by: Andrew Lunn
Signed-off-by: Martin Blumenstingl
---
drivers/net/dsa/lantiq_gswip.c | 185 -
1 file changed, 159 insertions(+), 26 deletions(-)
diff --git a/drivers/net/dsa/lantiq_gswip.c b/drivers/net/dsa/lantiq_gswip.c
index 809dfa3be6bb..126d4ea868ba 100644
--- a/drivers/net/dsa/lantiq_gswip.c
+++ b/drivers/net/dsa/lantiq_gswip.c
@@ -190,6 +190,23 @@
#define GSWIP_PCE_DEFPVID(p) (0x486 + ((p) * 0xA))
#define GSWIP_MAC_FLEN 0x8C5
+#define GSWIP_MAC_CTRL_0p(p) (0x903 + ((p) * 0xC))
+#define GSWIP_MAC_CTRL_0_PADENBIT(8)
+#define GSWIP_MAC_CTRL_0_FCS_EN BIT(7)
+#define GSWIP_MAC_CTRL_0_FCON_MASK0x0070
+#define GSWIP_MAC_CTRL_0_FCON_AUTO0x
+#define GSWIP_MAC_CTRL_0_FCON_RX 0x0010
+#define GSWIP_MAC_CTRL_0_FCON_TX 0x0020
+#define GSWIP_MAC_CTRL_0_FCON_RXTX0x0030
+#define GSWIP_MAC_CTRL_0_FCON_NONE0x0040
+#define GSWIP_MAC_CTRL_0_FDUP_MASK0x000C
+#define GSWIP_MAC_CTRL_0_FDUP_AUTO0x
+#define GSWIP_MAC_CTRL_0_FDUP_EN 0x0004
+#define GSWIP_MAC_CTRL_0_FDUP_DIS 0x000C
+#define GSWIP_MAC_CTRL_0_GMII_MASK0x0003
+#define GSWIP_MAC_CTRL_0_GMII_AUTO0x
+#define GSWIP_MAC_CTRL_0_GMII_MII 0x0001
+#define GSWIP_MAC_CTRL_0_GMII_RGMII 0x0002
#define GSWIP_MAC_CTRL_2p(p) (0x905 + ((p) * 0xC))
#define GSWIP_MAC_CTRL_2_MLEN BIT(3) /* Maximum Untagged Frame Lnegth
*/
@@ -653,16 +670,13 @@ static int gswip_port_enable(struct dsa_switch *ds, int
port,
GSWIP_SDMA_PCTRLp(port));
if (!dsa_is_cpu_port(ds, port)) {
- u32 macconf = GSWIP_MDIO_PHY_LINK_AUTO |
- GSWIP_MDIO_PHY_SPEED_AUTO |
- GSWIP_MDIO_PHY_FDUP_AUTO |
- GSWIP_MDIO_PHY_FCONTX_AUTO |
- GSWIP_MDIO_PHY_FCONRX_AUTO
[PATCH net v2 0/2] lantiq: GSWIP: two more fixes
Hello,
after my last patch got accepted and is now in net as commit
3e6fdeb28f4c33 ("net: dsa: lantiq_gswip: Let GSWIP automatically set
the xMII clock") [0] some more people from the OpenWrt community
(many thanks to everyone involved) helped test the GSWIP driver: [1]
It turns out that the previous fix does not work for all boards.
There's no regression, but it doesn't fix as many problems as I
thought. This is why two more fixes are needed:
- the first one solves many (four known but probably there are
a few extra hidden ones) reported bugs with the GSWIP where no
traffic would flow. Not all circumstances are fully understood
but testing shows that switching away from PHY auto polling
solves all of them
- while investigating the different problems which are addressed
by the first patch some small issues with the existing code were
found. These are addressed by the second patch
Changes since v1 at [0]:
- Don't configure the link parameters in gswip_phylink_mac_config
(as we're using the "modern" way in gswip_phylink_mac_link_up).
Thanks to Andrew for the hint with the phylink documentation.
- Clarify that GSWIP_MII_CFG_RMII_CLK is ignored by the hardware in
the description of the second patch as suggested by Hauke
- Don't set GSWIP_MII_CFG_RGMII_IBS in the second patch as we don't
have any hardware available for testing this. The patch
description now also reflects this.
- Added Andrew's Reviewed-by to the first patch (thank you!)
Best regards,
Martin
[0]
https://patchwork.kernel.org/project/netdevbpf/cover/20210406203508.476122-1-martin.blumensti...@googlemail.com/
Martin Blumenstingl (2):
net: dsa: lantiq_gswip: Don't use PHY auto polling
net: dsa: lantiq_gswip: Configure all remaining GSWIP_MII_CFG bits
drivers/net/dsa/lantiq_gswip.c | 202 -
1 file changed, 174 insertions(+), 28 deletions(-)
--
2.31.1
Re: [PATCH RFC net 1/2] net: dsa: lantiq_gswip: Don't use PHY auto polling
On Wed, Apr 7, 2021 at 9:44 PM Andrew Lunn wrote: > > > For my own curiosity: is there a "recommended" way where to configure > > link up/down, speed, duplex and flow control? currently I have the > > logic in both, .phylink_mac_config and .phylink_mac_link_up. > > You probably want to read the documentation in > > include/linux/phylink.h it turns out that I should have scrolled down in that file. there's a perfect explanation in it about the various functions, just not at the top. thanks for the hint! For my own reference: [...] @state->link [...] are never guaranteed to be correct, and so any mac_config() implementation must never reference these fields. I am referencing state->link so I will fix that in v2 [...] drivers may use @state->speed, @state->duplex and @state->pause to configure the MAC, but this is deprecated; such drivers should be converted to use mac_link_up so I will also drop these also from the gswip_phylink_mac_config implementation If dropping the modifications to gswip_phylink_mac_config is my only change: do you want me to keep or drop your Reviewed-by in v2? Best regards, Martin
Re: [PATCH RFC net 1/2] net: dsa: lantiq_gswip: Don't use PHY auto polling
Hi Andrew, On Wed, Apr 7, 2021 at 2:25 AM Andrew Lunn wrote: [...] > Having the MAC polling the PHY is pretty much always a bad idea. > > Reviewed-by: Andrew Lunn thanks for reviewing this! For my own curiosity: is there a "recommended" way where to configure link up/down, speed, duplex and flow control? currently I have the logic in both, .phylink_mac_config and .phylink_mac_link_up. Thank you! Martin
Re: [PATCH RFC net 2/2] net: dsa: lantiq_gswip: Configure all remaining GSWIP_MII_CFG bits
Hello, On Wed, Apr 7, 2021 at 6:47 PM Florian Fainelli wrote: > > > > On 4/6/2021 5:32 PM, Andrew Lunn wrote: > >> case PHY_INTERFACE_MODE_RGMII: > >> case PHY_INTERFACE_MODE_RGMII_ID: > >> case PHY_INTERFACE_MODE_RGMII_RXID: > >> case PHY_INTERFACE_MODE_RGMII_TXID: > >> miicfg |= GSWIP_MII_CFG_MODE_RGMII; > >> + > >> +if (phylink_autoneg_inband(mode)) > >> +miicfg |= GSWIP_MII_CFG_RGMII_IBS; > > > > Is there any other MAC driver doing this? Are there any boards > > actually enabling it? Since it is so odd, if there is nothing using > > it, i would be tempted to leave this out. > > Some PHYs (Broadcom namely) support suppressing the RGMII in-band > signaling towards the MAC, so if the MAC relies on that signaling to > configure itself based on what the PHY reports this may not work. point taken. in v2 we'll not set GSWIP_MII_CFG_RGMII_IBS unless there's someone who can actually test this. so far I don't know any hardware with Lantiq SoC that uses it Best regards, Martin
[PATCH RFC net 2/2] net: dsa: lantiq_gswip: Configure all remaining GSWIP_MII_CFG bits
There are a few more bits in the GSWIP_MII_CFG register for which we
did rely on the boot-loader (or the hardware defaults) to set them up
properly.
For some external RMII PHYs we need to select the GSWIP_MII_CFG_RMII_CLK
bit and also we should un-set it for non-RMII PHYs. The GSWIP IP also
supports in-band auto-negotiation for RGMII PHYs. Set or unset the
corresponding bit depending on the auto-negotiation mode.
Clear the xMII isolation bit when set at initialization time if it was
previously set by the bootloader. Not doing so could lead to no traffic
(neither RX nor TX) on a port with this bit set.
While here, also add the GSWIP_MII_CFG_RESET bit. We don't need to
manage it because this bit is self-clearning when set. We still add it
here to get a better overview of the GSWIP_MII_CFG register.
Fixes: 14fceff4771e51 ("net: dsa: Add Lantiq / Intel DSA driver for vrx200")
Cc: sta...@vger.kernel.org
Suggested-by: Hauke Mehrtens
Acked-by: Hauke Mehrtens
Signed-off-by: Martin Blumenstingl
---
drivers/net/dsa/lantiq_gswip.c | 22 +++---
1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/drivers/net/dsa/lantiq_gswip.c b/drivers/net/dsa/lantiq_gswip.c
index 47ea3a8c90a4..f330035ed85b 100644
--- a/drivers/net/dsa/lantiq_gswip.c
+++ b/drivers/net/dsa/lantiq_gswip.c
@@ -93,8 +93,12 @@
/* GSWIP MII Registers */
#define GSWIP_MII_CFGp(p) (0x2 * (p))
+#define GSWIP_MII_CFG_RESET BIT(15)
#define GSWIP_MII_CFG_EN BIT(14)
+#define GSWIP_MII_CFG_ISOLATE BIT(13)
#define GSWIP_MII_CFG_LDCLKDISBIT(12)
+#define GSWIP_MII_CFG_RGMII_IBS BIT(8)
+#define GSWIP_MII_CFG_RMII_CLKBIT(7)
#define GSWIP_MII_CFG_MODE_MIIP 0x0
#define GSWIP_MII_CFG_MODE_MIIM 0x1
#define GSWIP_MII_CFG_MODE_RMIIP 0x2
@@ -821,9 +825,11 @@ static int gswip_setup(struct dsa_switch *ds)
/* Configure the MDIO Clock 2.5 MHz */
gswip_mdio_mask(priv, 0xff, 0x09, GSWIP_MDIO_MDC_CFG1);
- /* Disable the xMII link */
+ /* Disable the xMII interface and clear it's isolation bit */
for (i = 0; i < priv->hw_info->max_ports; i++)
- gswip_mii_mask_cfg(priv, GSWIP_MII_CFG_EN, 0, i);
+ gswip_mii_mask_cfg(priv,
+ GSWIP_MII_CFG_EN | GSWIP_MII_CFG_ISOLATE,
+ 0, i);
/* enable special tag insertion on cpu port */
gswip_switch_mask(priv, 0, GSWIP_FDMA_PCTRL_STEN,
@@ -1597,19 +1603,29 @@ static void gswip_phylink_mac_config(struct dsa_switch
*ds, int port,
break;
case PHY_INTERFACE_MODE_RMII:
miicfg |= GSWIP_MII_CFG_MODE_RMIIM;
+
+ /* Configure the RMII clock as output: */
+ miicfg |= GSWIP_MII_CFG_RMII_CLK;
break;
case PHY_INTERFACE_MODE_RGMII:
case PHY_INTERFACE_MODE_RGMII_ID:
case PHY_INTERFACE_MODE_RGMII_RXID:
case PHY_INTERFACE_MODE_RGMII_TXID:
miicfg |= GSWIP_MII_CFG_MODE_RGMII;
+
+ if (phylink_autoneg_inband(mode))
+ miicfg |= GSWIP_MII_CFG_RGMII_IBS;
break;
default:
dev_err(ds->dev,
"Unsupported interface: %d\n", state->interface);
return;
}
- gswip_mii_mask_cfg(priv, GSWIP_MII_CFG_MODE_MASK, miicfg, port);
+
+ gswip_mii_mask_cfg(priv,
+ GSWIP_MII_CFG_MODE_MASK | GSWIP_MII_CFG_RMII_CLK |
+ GSWIP_MII_CFG_RGMII_IBS | GSWIP_MII_CFG_LDCLKDIS,
+ miicfg, port);
gswip_port_set_link(priv, port, state->link);
gswip_port_set_speed(priv, port, state->speed, state->interface);
--
2.31.1
[PATCH RFC net 1/2] net: dsa: lantiq_gswip: Don't use PHY auto polling
PHY auto polling on the GSWIP hardware can be used so link changes
(speed, link up/down, etc.) can be detected automatically. Internally
GSWIP reads the PHY's registers for this functionality. Based on this
automatic detection GSWIP can also automatically re-configure it's port
settings. Unfortunately this auto polling (and configuration) mechanism
seems to cause various issues observed by different people on different
devices:
- FritzBox 7360v2: the two Gbit/s ports (connected to the two internal
PHY11G instances) are working fine but the two Fast Ethernet ports
(using an AR8030 RMII PHY) are completely dead (neither RX nor TX are
received). It turns out that the AR8030 PHY sets the BMSR_ESTATEN bit
as well as the ESTATUS_1000_TFULL and ESTATUS_1000_XFULL bits. This
makes the PHY auto polling state machine (rightfully?) think that the
established link speed (when the other side is Gbit/s capable) is
1Gbit/s.
- None of the Ethernet ports on the Zyxel P-2812HNU-F1 (two are
connected to the internal PHY11G GPHYs while the other three are
external RGMII PHYs) are working. Neither RX nor TX traffic was
observed. It is not clear which part of the PHY auto polling state-
machine caused this.
- FritzBox 7412 (only one LAN port which is connected to one of the
internal GPHYs running in PHY22F / Fast Ethernet mode) was seeing
random disconnects (link down events could be seen). Sometimes all
traffic would stop after such disconnect. It is not clear which part
of the PHY auto polling state-machine cauased this.
- TP-Link TD-W9980 (two ports are connected to the internal GPHYs
running in PHY11G / Gbit/s mode, the other two are external RGMII
PHYs) was affected by similar issues as the FritzBox 7412 just without
the "link down" events
Switch to software based configuration instead of PHY auto polling (and
letting the GSWIP hardware configure the ports automatically) for the
following link parameters:
- link up/down
- link speed
- full/half duplex
- flow control (RX / TX pause)
After a big round of manual testing by various people (who helped test
this on OpenWrt) it turns out that this fixes all reported issues.
Additionally it can be considered more future proof because any
"quirk" which is implemented for a PHY on the driver side can now be
used with the GSWIP hardware as well because Linux is in control of the
link parameters.
As a nice side-effect this also solves a problem where fixed-links were
not supported previously because we were relying on the PHY auto polling
mechanism, which cannot work for fixed-links as there's no PHY from
where it can read the registers. Configuring the link settings on the
GSWIP ports means that we now use the settings from device-tree also for
ports with fixed-links.
Fixes: 14fceff4771e51 ("net: dsa: Add Lantiq / Intel DSA driver for vrx200")
Fixes: 3e6fdeb28f4c33 ("net: dsa: lantiq_gswip: Let GSWIP automatically set the
xMII clock")
Cc: sta...@vger.kernel.org
Acked-by: Hauke Mehrtens
Signed-off-by: Martin Blumenstingl
---
drivers/net/dsa/lantiq_gswip.c | 191 -
1 file changed, 165 insertions(+), 26 deletions(-)
diff --git a/drivers/net/dsa/lantiq_gswip.c b/drivers/net/dsa/lantiq_gswip.c
index 809dfa3be6bb..47ea3a8c90a4 100644
--- a/drivers/net/dsa/lantiq_gswip.c
+++ b/drivers/net/dsa/lantiq_gswip.c
@@ -190,6 +190,23 @@
#define GSWIP_PCE_DEFPVID(p) (0x486 + ((p) * 0xA))
#define GSWIP_MAC_FLEN 0x8C5
+#define GSWIP_MAC_CTRL_0p(p) (0x903 + ((p) * 0xC))
+#define GSWIP_MAC_CTRL_0_PADENBIT(8)
+#define GSWIP_MAC_CTRL_0_FCS_EN BIT(7)
+#define GSWIP_MAC_CTRL_0_FCON_MASK0x0070
+#define GSWIP_MAC_CTRL_0_FCON_AUTO0x
+#define GSWIP_MAC_CTRL_0_FCON_RX 0x0010
+#define GSWIP_MAC_CTRL_0_FCON_TX 0x0020
+#define GSWIP_MAC_CTRL_0_FCON_RXTX0x0030
+#define GSWIP_MAC_CTRL_0_FCON_NONE0x0040
+#define GSWIP_MAC_CTRL_0_FDUP_MASK0x000C
+#define GSWIP_MAC_CTRL_0_FDUP_AUTO0x
+#define GSWIP_MAC_CTRL_0_FDUP_EN 0x0004
+#define GSWIP_MAC_CTRL_0_FDUP_DIS 0x000C
+#define GSWIP_MAC_CTRL_0_GMII_MASK0x0003
+#define GSWIP_MAC_CTRL_0_GMII_AUTO0x
+#define GSWIP_MAC_CTRL_0_GMII_MII 0x0001
+#define GSWIP_MAC_CTRL_0_GMII_RGMII 0x0002
#define GSWIP_MAC_CTRL_2p(p) (0x905 + ((p) * 0xC))
#define GSWIP_MAC_CTRL_2_MLEN BIT(3) /* Maximum Untagged Frame Lnegth
*/
@@ -653,16 +670,13 @@ static int gswip_port_enable(struct dsa_switch *ds, int
port,
GSWIP_SDMA_PCTRLp(port));
if (!dsa_is_cpu_port(ds, port)) {
- u32 macconf = GSWIP_MDIO_PHY_LINK_AUTO |
- GSWIP_MDIO_PHY_SPEED_AUTO |
- GSWIP_MDIO_PHY_FDUP_AUTO |
- GSWIP_MDIO_PHY_FCONTX_AUTO |
- GSWIP_MDIO_PHY_FCONRX_AUTO |
-
[PATCH RFC net 0/2] lantiq: GSWIP: two more fixes
Hello,
after my last patch got accepted and is now in net as commit
3e6fdeb28f4c33 ("net: dsa: lantiq_gswip: Let GSWIP automatically set
the xMII clock") [0] some more people from the OpenWrt community
(many thanks to everyone involved) helped test the GSWIP driver: [1]
It turns out that the previous fix does not work for all boards.
There's no regression, but it doesn't fix as many problems as I
thought. This is why two more fixes are needed:
- the first one solves many (four known but probably there are
a few extra hidden ones) reported bugs with the GSWIP where no
traffic would flow. Not all circumstances are fully understood
but testing shows that switching away from PHY auto polling
solves all of them
- while investigating the different problems which are addressed
by the first patch some small issues with the existing code were
found. These are addressed by the second patch
Why am I sending this as RFC then?
Because I am not sure where to place the link configuration bits
in the first patch (as I don't understand why phylink_mac_config
and also phylink_mac_link_up both have the required parameters
to configure the link, just in differnet formats):
- in gswip_phylink_mac_config
- in gswip_phylink_mac_link_up
- in both
Any feedback is very welcome on this topic!
I have already gotten Hauke's Acked-by off-list. He's Cc'ed so he
can speak up if he changes his opinion or finds some issue with
the patches still.
Best regards,
Martin
[0]
https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=3e6fdeb28f4c331acbd27bdb0effc4befd4ef8e8
[1] https://github.com/openwrt/openwrt/pull/3085
Martin Blumenstingl (2):
net: dsa: lantiq_gswip: Don't use PHY auto polling
net: dsa: lantiq_gswip: Configure all remaining GSWIP_MII_CFG bits
drivers/net/dsa/lantiq_gswip.c | 211 -
1 file changed, 183 insertions(+), 28 deletions(-)
--
2.31.1
Re: [PATCH 2/3] arm64: dts: meson: add saradc node to ODROID N2/N2+
On Tue, Mar 30, 2021 at 1:18 AM Christian Hewitt
wrote:
>
> From: Hyeonki Hong
>
> Add the meson saradc node to the ODROID N2/N2+ common dtsi.
in general I am fine with this as some SAR ADC channels seem to be on
the pin headers...
[...]
> + {
> + status = "okay";
> +};
...but a vref-supply should be provided to get meaningful numbers
Re: [PATCH 1/3] arm64: dts: meson: remove extra tab from ODROID N2/N2+ ext_mdio node
On Tue, Mar 30, 2021 at 1:17 AM Christian Hewitt wrote: > > Remove an extra tab from the ext_mdio node in the ODROID N2/N2+ common > dtsi file. > > Signed-off-by: Christian Hewitt Reviewed-by: Martin Blumenstingl
Re: [PATCH v2 3/3] arm64: dts: meson: set 128bytes FIFO size on uart A
On Thu, Mar 25, 2021 at 4:25 PM Neil Armstrong wrote: > > The first UART controller in "Everything-Else" power domain, usually used > for Bluetooth HCI has 128bytes FIFO depth. > > Signed-off-by: Neil Armstrong Reviewed-by: Martin Blumenstingl
Re: [PATCH v2 2/3] tty: serial: meson: retrieve port FIFO size from DT
On Thu, Mar 25, 2021 at 4:25 PM Neil Armstrong wrote: > > Now the DT bindings has a property to get the FIFO size for a particular port, > retrieve it and use to setup the FIFO interrupts threshold. > > Signed-off-by: Neil Armstrong > Reviewed-by: Kevin Hilman Reviewed-by: Martin Blumenstingl
Re: [PATCH net] net: dsa: lantiq_gswip: Let GSWIP automatically set the xMII clock
Hi Florian, On Thu, Mar 25, 2021 at 7:09 PM Florian Fainelli wrote: [...] > > It would be great to have this fix backported to Linux 5.4 and 5.10 to > > get rid of one more blocker which prevents OpenWrt from switching to > > this new in-tree driver. > > Given there is a Fixes: tag this should land at some point in the stable > tree auto-selection. Stable fixes for networking patches follows a > slightly different path: > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/networking/netdev-FAQ.rst#n145 thank you very much for this link - I missed the news that net patches should now also be Cc'ed to linux-stable I think this simplifies the process (at least for me as contributor) Also thank you for the Reviewed-by! Best regards, Martin
[PATCH net] net: dsa: lantiq_gswip: Let GSWIP automatically set the xMII clock
The xMII interface clock depends on the PHY interface (MII, RMII, RGMII)
as well as the current link speed. Explicitly configure the GSWIP to
automatically select the appropriate xMII interface clock.
This fixes an issue seen by some users where ports using an external
RMII or RGMII PHY were deaf (no RX or TX traffic could be seen). Most
likely this is due to an "invalid" xMII clock being selected either by
the bootloader or hardware-defaults.
Fixes: 14fceff4771e51 ("net: dsa: Add Lantiq / Intel DSA driver for vrx200")
Signed-off-by: Martin Blumenstingl
---
It would be great to have this fix backported to Linux 5.4 and 5.10 to
get rid of one more blocker which prevents OpenWrt from switching to
this new in-tree driver.
drivers/net/dsa/lantiq_gswip.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/net/dsa/lantiq_gswip.c b/drivers/net/dsa/lantiq_gswip.c
index 52e865a3912c..809dfa3be6bb 100644
--- a/drivers/net/dsa/lantiq_gswip.c
+++ b/drivers/net/dsa/lantiq_gswip.c
@@ -799,10 +799,15 @@ static int gswip_setup(struct dsa_switch *ds)
/* Configure the MDIO Clock 2.5 MHz */
gswip_mdio_mask(priv, 0xff, 0x09, GSWIP_MDIO_MDC_CFG1);
- /* Disable the xMII link */
- for (i = 0; i < priv->hw_info->max_ports; i++)
+ for (i = 0; i < priv->hw_info->max_ports; i++) {
+ /* Disable the xMII link */
gswip_mii_mask_cfg(priv, GSWIP_MII_CFG_EN, 0, i);
+ /* Automatically select the xMII interface clock */
+ gswip_mii_mask_cfg(priv, GSWIP_MII_CFG_RATE_MASK,
+ GSWIP_MII_CFG_RATE_AUTO, i);
+ }
+
/* enable special tag insertion on cpu port */
gswip_switch_mask(priv, 0, GSWIP_FDMA_PCTRL_STEN,
GSWIP_FDMA_PCTRLp(cpu_port));
--
2.31.0
Re: [PATCH 3/5] dt-bindings: remoteproc: Add the documentation for Meson AO ARC rproc
Hi Bjorn,
On Thu, Mar 18, 2021 at 3:55 AM Bjorn Andersson
wrote:
[...]
> > +examples:
> > + - |
> > +remoteproc@1c {
> > + compatible= "amlogic,meson8-ao-arc", "amlogic,meson-mx-ao-arc";
> > + reg = <0x1c 0x8>, <0x38 0x8>;
>
> I'm generally not in favor of mapping "individual" registers, do you
> know what hardware block this is part of? Can you express the whole
> block as an single entity in your DT?
the answer is unfortunately not easy :-)
some background information:
Amlogic SoCs have two power domains:
- AO (Always-On)
- EE (Everything-Else)
AO includes (at least) one ARC core for which this remoteproc dt-binding is.
EE includes ARM Cortex-A7/15/... cores
The AO registers can be accessed from the EE power-domain and vice versa
Following is an extract (with comments added by me) for the AO
registers (taken from the GPL vendor kernel):
#define AO_RTI_STATUS_REG0 ((0x00 << 10) | (0x00 << 2))
#define AO_RTI_STATUS_REG1 ((0x00 << 10) | (0x01 << 2))
#define AO_RTI_STATUS_REG2 ((0x00 << 10) | (0x02 << 2))
these three are used for communication with the firmware on the AO ARC core
I am not sure into which Linux subsystem these would fit into best
#define AO_RTI_PWR_CNTL_REG1 ((0x00 << 10) | (0x03 << 2))
#define AO_RTI_PWR_CNTL_REG0 ((0x00 << 10) | (0x04 << 2))
this includes various power-domains for the following functionality
(and probably more):
- DDR PHY I/O
- AHB SRAM
- video encoder/decoders
- EE domain isolation
#define AO_RTI_PIN_MUX_REG ((0x00 << 10) | (0x05 << 2))
first part of the pin controller registers for the "AO" bank pads
this includes various GPIOs, UART, I2C for communication with a PMIC,
infrared remote decoder, two PWMs, etc.
all (known) functionality can be used by Linux as well.
especially the UART, I2C, IR decoder and GPIOs are functionality that
we use with Linux today - without involving the AO ARC
remote-processor.
#define AO_WD_GPIO_REG ((0x00 << 10) | (0x06 << 2))
(I think this is related to the watchdog being able to trigger the
SoC's reset line, but there's no documentation on this register)
#define AO_REMAP_REG0 ((0x00 << 10) | (0x07 << 2))
#define AO_REMAP_REG1 ((0x00 << 10) | (0x08 << 2))
remap registers for the AO ARC remote-processor as used in this binding
#define AO_GPIO_O_EN_N ((0x00 << 10) | (0x09 << 2))
#define AO_GPIO_I ((0x00 << 10) | (0x0A << 2))
GPIO controller registers for the "AO" bank pads
#define AO_RTI_PULL_UP_REG ((0x00 << 10) | (0x0B << 2))
second part of the pin controller registers for the "AO" bank pads
#define AO_RTI_WD_MARK ((0x00 << 10) | (0x0D << 2))
again, I think this is somehow related to the watchdog but there's no
documentation on this
#define AO_CPU_CNTL ((0x00 << 10) | (0x0E << 2))
#define AO_CPU_STAT ((0x00 << 10) | (0x0F << 2))
used for booting the AO ARC remote-processor
#define AO_RTI_GEN_CNTL_REG0 ((0x00 << 10) | (0x10 << 2))
seems to be a multi purpose register as it (seems to) contains some
reset bits (for the AO UART and RTC) - not documented
(more registers are following)
to summarize this: I think there's indeed three different sets of registers
having one big device-tree node spanning all of these registers seems
incorrect to me as the other IPs are independent of the AO ARC
remote-processor.
so the way I have done it in the original patch is the best I could
come up with.
Please let me know what you think!
Best regards,
Martin
Re: [PATCH 4/5] remoteproc: meson-mx-ao-arc: Add a driver for the AO ARC remote procesor
Hi Bjorn, On Thu, Mar 18, 2021 at 3:51 AM Bjorn Andersson wrote: > > On Tue 29 Dec 19:27 CST 2020, Martin Blumenstingl wrote: > > > Amlogic Meson6, Meson8, Meson8b and Meson8m2 embed an ARC core in the > > Always-On (AO) power-domain. This is typically used for waking up the > > ARM cores after system suspend. > > > > The configuration is spread across three different registers: > > - AO_REMAP_REG0 which must be programmed to zero, it's actual purpose > > is unknown. There is a second remap register which is not used in the > > vendor kernel (which served as reference for this driver). > > - AO_CPU_CNTL is used to start and stop the ARC core. > > - AO_SECURE_REG0 in the SECBUS2 register area with unknown purpose. > > > > To boot the ARC core we also need to enable it's gate clock and trigger > > a reset. > > > > The actual code for this ARC core can come from an ELF binary, for > > example by building the Zephyr RTOS for an ARC EM4 core and then taking > > "zephyr.elf" as firmware. This executable does not have any "rsc table" > > so we are skipping rproc_elf_load_rsc_table (rproc_ops.parse_fw) and > > rproc_elf_find_loaded_rsc_table (rproc_ops.find_loaded_rsc_table). > > > > Thanks for the patch Martin, it looks really good. Just some minor > things as I expect a respin of the DT binding as well. thank you for your comments. I will send an updated series in the next few days and include all of your suggested changes since I sent this series (it's been a few days) I also got an update from Amlogic so I know have better understanding of some (but unfortunately not all) registers so it'll be a bigger update. but don't worry: I'll include a changelog Best regards, Martin
Re: [PATCH 2/3] tty: serial: meson: retrieve port FIFO size from DT
On Mon, Mar 15, 2021 at 9:37 AM Neil Armstrong wrote: > > Now the DT bindings has a property to get the FIFO size for a particular port, > retrieve it and use to setup the FIFO interrupts threshold. > > Signed-off-by: Neil Armstrong Reviewed-by: Martin Blumenstingl
Re: [PATCH 1/3] dt-bindings: serial: amlogic, meson-uart: add amlogic, uart-fifosize property
Hi Neil, On Mon, Mar 15, 2021 at 9:37 AM Neil Armstrong wrote: > > On most of the Amlogic SoCs, the first UART controller in the > "Everything-Else" > power domain has 128bytes of RX & TX FIFO, so add an optional property to > describe do we still need wrapping of long lines in commit messages? if so I think the line above is too long > a different FIFO size from the other ports (64bytes). > > Signed-off-by: Neil Armstrong Reviewed-by: Martin Blumenstingl one additional note below > --- > .../devicetree/bindings/serial/amlogic,meson-uart.yaml | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/Documentation/devicetree/bindings/serial/amlogic,meson-uart.yaml > b/Documentation/devicetree/bindings/serial/amlogic,meson-uart.yaml > index 75ebc9952a99..e0a742112783 100644 > --- a/Documentation/devicetree/bindings/serial/amlogic,meson-uart.yaml > +++ b/Documentation/devicetree/bindings/serial/amlogic,meson-uart.yaml > @@ -55,6 +55,12 @@ properties: >- const: pclk >- const: baud > > + > + amlogic,uart-fifosize: > +description: The fifo size supported by the UART channel. > +$ref: /schemas/types.yaml#/definitions/uint32 > +enum: [64, 128] I personally think this is generic enough to be described as fifo-size (as it's done in Documentation/devicetree/bindings/serial/8250.yaml) let's wait and hear what Rob thinks Best regards, Martin
[PATCH] net: stmmac: dwmac-meson8b: fix the RX delay validation
When has_prg_eth1_rgmii_rx_delay is true then we support RX delays
between 0ps and 3000ps in 200ps steps. Swap the validation of the RX
delay based on the has_prg_eth1_rgmii_rx_delay flag so the 200ps check
is now applied correctly on G12A SoCs (instead of only allow 0ps or
2000ps on G12A, but 0..3000ps in 200ps steps on older SoCs which don't
support that).
Fixes: de94fc104d58ea ("net: stmmac: dwmac-meson8b: add support for the RGMII
RX delay on G12A")
Reported-by: Martijn van Deventer
Signed-off-by: Martin Blumenstingl
---
Many thanks to Martijn for this excellent catch and for reporting this
issue (off-list)!
drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
index 55152d7ba99a..848e5c37746b 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
@@ -443,16 +443,16 @@ static int meson8b_dwmac_probe(struct platform_device
*pdev)
}
if (dwmac->data->has_prg_eth1_rgmii_rx_delay) {
- if (dwmac->rx_delay_ps != 0 && dwmac->rx_delay_ps != 2000) {
+ if (dwmac->rx_delay_ps > 3000 || dwmac->rx_delay_ps % 200) {
dev_err(dwmac->dev,
- "The only allowed RGMII RX delays values are:
0ps, 2000ps");
+ "The RGMII RX delay range is 0..3000ps in 200ps
steps");
ret = -EINVAL;
goto err_remove_config_dt;
}
} else {
- if (dwmac->rx_delay_ps > 3000 || dwmac->rx_delay_ps % 200) {
+ if (dwmac->rx_delay_ps != 0 && dwmac->rx_delay_ps != 2000) {
dev_err(dwmac->dev,
- "The RGMII RX delay range is 0..3000ps in 200ps
steps");
+ "The only allowed RGMII RX delays values are:
0ps, 2000ps");
ret = -EINVAL;
goto err_remove_config_dt;
}
--
2.30.0
Re: [PATCH v2 4/5] remoteproc: meson-mx-ao-arc: Add a driver for the AO ARC remote procesor
Hi Mathieu,
thank you for taking the time to go through my patch!
On Wed, Jan 13, 2021 at 12:43 AM Mathieu Poirier
wrote:
[...]
> > + If unusre say N.
>
> s/unusre/unsure
godo catch, noted.
[...]
> > +#include
>
> Is it possible for this to go after platform_device.h?
I think so, not sure why this is not in alphabetical order
[...]
> > +#define AO_CPU_CNTL 0x0
> > + #define AO_CPU_CNTL_MEM_ADDR_UPPER GENMASK(28, 16)
> > + #define AO_CPU_CNTL_HALTBIT(9)
> > + #define AO_CPU_CNTL_UNKNONWNBIT(8)
> > + #define AO_CPU_CNTL_RUN BIT(0)
>
> Any reason for the extra tabulation at the beginning of the lines?
not really, I think I did the same thing as in
drivers/iio/adc/meson_saradc.c where the register itself starts at the
beginning of the line and each bit(mask) starts indented
I'll change this for the next version
[...]
> > +#define MESON_AO_RPROC_SRAM_USABLE_BITS GENMASK(31,
> > 20)
>
> As per your comments in the cover letter I assume we don't know more about
> this?
unfortunately not, but I'll still try to get some more information
from someone at Amlogic.
That said, this is "legacy" hardware for them so I can't make any promises.
> > +#define MESON_AO_RPROC_MEMORY_OFFSET 0x1000
> > +
> > +struct meson_mx_ao_arc_rproc_priv {
> > + void __iomem*remap_base;
> > + void __iomem*cpu_base;
> > + unsigned long sram_va;
> > + phys_addr_t sram_pa;
> > + size_t sram_size;
> > + struct gen_pool *sram_pool;
> > + struct reset_control*arc_reset;
> > + struct clk *arc_pclk;
> > + struct regmap *secbus2_regmap;
> > +};
> > +
> > +static int meson_mx_ao_arc_rproc_start(struct rproc *rproc)
> > +{
> > + struct meson_mx_ao_arc_rproc_priv *priv = rproc->priv;
> > + phys_addr_t phys_addr;
> > + int ret;
> > +
> > + ret = clk_prepare_enable(priv->arc_pclk);
> > + if (ret)
> > + return ret;
> > +
> > + writel(0, priv->remap_base + AO_REMAP_REG0);
> > + usleep_range(10, 100);
>
> That's wonderful - here too I assume there is no indication as to why this is
> needed?
looking at this again: the vendor driver only has a delay after
pulsing the reset line
I will double check and hopefully remove this usleep_range and only
keep the one below (after pulsing the reset line)
[...]
> > +static void *meson_mx_ao_arc_rproc_da_to_va(struct rproc *rproc, u64 da,
> > + size_t len)
> > +{
> > + struct meson_mx_ao_arc_rproc_priv *priv = rproc->priv;
> > +
> > + if ((da + len) >= priv->sram_size)
> > + return NULL;
>
> This isn't an index so it should be '>' rather than '>='. You should be able
> to
> ask for the whole range and get it, which the above prevents you from doing.
>
> Moreover are you sure 'da' always starts at 0? This seems to be at odds with
> your comment in meson_mx_ao_arc_rproc_start() about converting from 0xd900
> to 0xc900.
thanks for both of these comments, I'll address this in the next version
[...]
> > + priv->arc_reset = devm_reset_control_get_exclusive(dev, NULL);
> > + if (IS_ERR(priv->arc_reset)) {
>
> Looking at __devm_reset_control_get(), this should probably be
> IS_ERR_OR_NULL().
as far as I know only devm_reset_control_get_optional_exclusive (the
important bit is "optional" - I am using the "mandatory/not optional"
variant) can return NULL, all other variants return PTR_ERR or a valid
reset_control.
Best regards,
Martin
RE: [PATCH] dt-bindings: mips: lantiq: Document Lantiq Xway DMA bindings
(another late reply from me, sorry)
> +required:
> + - compatible
> + - reg
This is actually an older IP variant of what can be found in the Intel
LGM SoCs. The dt-bindings are currently being upstreamed for that newer
SoC in [0].
Based on "DOs and DON’Ts for designing and writing Devicetree bindings"
I think some more mandatory properties are needed, even though our
driver currently uses none of them:
- interrupts: as far as I know the IP on the Lantiq SoCs has (at least)
one interrupt for each DMA channel. That means: 28 interrupts on the
xRX200 SoCs
- I *assume* (but I have not researched if that's really the case) that
the Lantiq variant also has at least one clock input and a reset line
- since we don't have a proper DMA driver yet I can't comment what we
should use for #dma-cells
> +examples:
> + - |
> +dma@e104100 {
note to self: it seems that both dma@ and dma-controller@ are used in
existing schemas (the latter having twice as many occurrences though):
$ grep -R dma@ Documentation/devicetree/bindings/dma/* | wc -l
20
$ grep -R dma-controller@ Documentation/devicetree/bindings/dma/* | wc -l
45
Best regards,
Martin
[0]
https://patchwork.ozlabs.org/project/devicetree-bindings/patch/0864b9bfa6e2b8b5e7ad9a7a739ca3274f66493c.1610703653.git.mallikarjunax.re...@linux.intel.com/
[1]
https://www.kernel.org/doc/html/latest/devicetree/bindings/writing-bindings.html
RE: [PATCH] dt-bindings: mips: lantiq: Document Lantiq Xway EBU bindings
(again, sorry for seeing this patch late) > +properties: > + compatible: > +items: > + - enum: > + - lantiq,ebu-xway I think this compatible string is very generic and with that comes some problems. There is actually two different versions of this IP: one which has support for controlling the interrupt of the PCI controller on some SoCs (Danube, xRX100, xRX200). Other SoC variants (Falcon, Amazon-SE) don't have that interrupt-controller as they don't have PCI support. Also there is at least one clock input. I *assume* we need to describe it but I am not sure (as this platform doesn't use the common clock framework yet). My version of this can be found here [0]. It's still sitting in my tree because it has a dependency on an ICU patch in my tree which I could not make work properly yet. Best regards, Martin [0] https://github.com/xdarklight/linux/blob/8d5c632e11fe0ca14497efc2f9d99b69f75590ba/Documentation/devicetree/bindings/mips/lantiq/lantiq%2Cebu.yaml
RE: [PATCH] dt-bindings: mips: lantiq: Document Lantiq Xway CGU bindings
(sorry for only seeing this late)
[...]
> +maintainers:
> + - John Crispin
personally I think we should get at least John's Acked-by but I don't
know if there's any rule for adding a dt-binding for some other
maintainer
[...]
> +required:
> + - compatible
> + - reg
based on "DOs and DON’Ts for designing and writing Devicetree bindings"
from [0] I think this is incomplete
As far as I know CGU contains some PLLs. These PLLs need at least one
input: the main XTAL which is found on the board
Also the Lantiq code does not use the common clock framework yet. Once
that's used we also need #clock-cells = <1>. I don't know if that
should be added already (or not).
> +examples:
> + - |
> +cgu@103000 {
this should be clock-controller@...
Best regards,
Martin
[0]
https://www.kernel.org/doc/html/latest/devicetree/bindings/writing-bindings.html
[PATCH] MIPS: lantiq: irq: register the interrupt controllers with irqchip_init
Add support for more interrupt controllers by switching from
of_irq_init() to irqchip_init() in Lantiq's arch_init_irq(). This
requires switching the ICU interrupt controller to use
IRQCHIP_DECLARE(), like a real irqchip driver would do.
This is needed for future changes when new irqchip drivers are
implemented:
- a dedicated driver for the EIU interrupt controller
- a driver for the MSI PIC (Programmable Interrupt Controller) found on
VRX200 and newer SoCs
- ..or any other driver which uses IRQCHIP_DECLARE
Signed-off-by: Martin Blumenstingl
---
arch/mips/lantiq/irq.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/arch/mips/lantiq/irq.c b/arch/mips/lantiq/irq.c
index df8eed3875f6..76806d11e483 100644
--- a/arch/mips/lantiq/irq.c
+++ b/arch/mips/lantiq/irq.c
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -422,12 +423,9 @@ unsigned int get_c0_compare_int(void)
return CP0_LEGACY_COMPARE_IRQ;
}
-static const struct of_device_id of_irq_ids[] __initconst = {
- { .compatible = "lantiq,icu", .data = icu_of_init },
- {},
-};
+IRQCHIP_DECLARE(lantiq_icu, "lantiq,icu", icu_of_init);
void __init arch_init_irq(void)
{
- of_irq_init(of_irq_ids);
+ irqchip_init();
}
--
2.30.0
Re: [PATCH] phy: lantiq: rcu-usb2: wait after clock enable
On Thu, Jan 7, 2021 at 11:49 PM Mathias Kresin wrote:
>
> Commit 65dc2e725286 ("usb: dwc2: Update Core Reset programming flow.")
> revealed that the phy isn't ready immediately after enabling it's
> clocks. The dwc2_check_core_version() fails and the dwc2 usb driver
> errors out.
>
> Add a short delay to let the phy get up and running. There isn't any
> documentation how much time is required, the value was chosen based on
> tests.
>
> Cc: # v5.7+
> Signed-off-by: Mathias Kresin
Acked-by: Martin Blumenstingl
Re: [RFC PATCH 3/3] gpio: ej1x8: Add GPIO driver for Etron Tech Inc. EJ168/EJ188/EJ198
Hi Linus, On Tue, Jan 5, 2021 at 11:23 PM Linus Walleij wrote: > > On Mon, Dec 21, 2020 at 4:28 PM Martin Blumenstingl > wrote: > > On Wed, Oct 7, 2020 at 9:44 PM Martin Blumenstingl > > wrote: > > [...] > > > > As noted on the earlier patches I think this should be folded into the > > > > existing XHCI USB driver in drivers/usb/host/xhci-pci.c or, if that > > > > gets messy, as a separate bolt-on, something like > > > > xhci-pci-gpio.[c|h] in the drivers/usb/host/* directory. > > > > You can use a Kconfig symbol for the GPIO portions or not. > > > OK, I will do that if there are no objections from other developers > > > I am intending to place the relevant code in xhci-pci-etron.c, similar > > > to what we already have with xhci-pci-renesas.c > > > > I tried this and unfortunately there's a catch. > > the nice thing about having a separate GPIO driver means that the > > xhci-pci driver doesn't need to know about it. > > Since PCI devices have device-wide power management and things > like that I think that is a really dangerous idea. > > What if the GPIO driver starts poking around in this PCI device > when the main driver is also probed and has put the device > into sleep state? that is asking for trouble, indeed. [...] > > I implemented xhci-pci-etron.c and gave it a Kconfig option. > > xhci-pci is then calling into xhci-pci-etron (through some > > etron_xhci_pci_probe function). > > This sounds about right. > > > unfortunately this means that xhci-pci now depends on xhci-pci-etron. > > for xhci-pci-renesas this is fine (I think) because that part of the > > code is needed to get the xHCI controller going > > but for xhci-pci-etron this is a different story: the GPIO controller > > is entirely optional and only used on few devices > > I might be naive but should it not be the other way around? > That xhci-pci-etron is dependent on xhci-pci? I imagine > it would be an optional add-on. the only way to achieve this that I can think of is to basically have xhci-pci-etron implement it's own pci_driver and then call xhci_pci_probe, xhci_pci_remove, etc. but then it depends on the driver load order if the GPIO controller is exposed what structure did you have in mind to achieve this? > > my goal is (at some point in the future) to have the GPIO driver in OpenWrt. > > I am not sure if they would accept a patch where xhci-pci would then > > pull in the dependencies for that Etron controller, even though most > > boards don't need it. > > Make sure the etron part is an additional module that can be > loaded after xhci-pci. my approach from above unfortunately would not achieve this so if you have an idea how to achieve this (or have any other driver in mind that I can use as reference, even if not related to GPIO/USB/PCI then please let me know) > OpenWrt support optional modules to be compiled per-system. that I already found out. That's why I think that I need to get the driver part "right" and then get the OpenWrt part done in just a few lines of their build-system Best regards, Martin
[PATCH v2] mtd: rawnand: intel: check the mtd name only after setting the variable
Move the check for mtd->name after the mtd variable has actually been
initialized.
While here, also drop the NULL assignment to the mtd variable as it's
overwritten later on anyways and the NULL value is never read.
Fixes: 0b1039f016e8a3 ("mtd: rawnand: Add NAND controller support on Intel LGM
SoC")
Signed-off-by: Martin Blumenstingl
---
changes since v1:
- don't drop the check but actually move it after the mtd variable has
been initialized as suggested by Miquel Raynal
drivers/mtd/nand/raw/intel-nand-controller.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/nand/raw/intel-nand-controller.c
b/drivers/mtd/nand/raw/intel-nand-controller.c
index fdb112e8a90d..a304fda5d1fa 100644
--- a/drivers/mtd/nand/raw/intel-nand-controller.c
+++ b/drivers/mtd/nand/raw/intel-nand-controller.c
@@ -579,7 +579,7 @@ static int ebu_nand_probe(struct platform_device *pdev)
struct device *dev = >dev;
struct ebu_nand_controller *ebu_host;
struct nand_chip *nand;
- struct mtd_info *mtd = NULL;
+ struct mtd_info *mtd;
struct resource *res;
char *resname;
int ret;
@@ -647,12 +647,13 @@ static int ebu_nand_probe(struct platform_device *pdev)
ebu_host->ebu + EBU_ADDR_SEL(cs));
nand_set_flash_node(_host->chip, dev->of_node);
+
+ mtd = nand_to_mtd(_host->chip);
if (!mtd->name) {
dev_err(ebu_host->dev, "NAND label property is mandatory\n");
return -EINVAL;
}
- mtd = nand_to_mtd(_host->chip);
mtd->dev.parent = dev;
ebu_host->dev = dev;
--
2.30.0
[PATCH] PCI: dwc/intel-gw: Fix enabling the legacy PCI interrupt lines
The legacy PCI interrupt lines need to be enabled using PCIE_APP_IRNEN
bits 13 (INTA), 14 (INTB), 15 (INTC) and 16 (INTD). The old code however
was taking (for example) "13" as raw value instead of taking BIT(13).
Define the legacy PCI interrupt bits using the BIT() macro and then use
these in PCIE_APP_IRN_INT.
Fixes: ed22aaaede44 ("PCI: dwc: intel: PCIe RC controller driver")
Signed-off-by: Martin Blumenstingl
---
drivers/pci/controller/dwc/pcie-intel-gw.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/pci/controller/dwc/pcie-intel-gw.c
b/drivers/pci/controller/dwc/pcie-intel-gw.c
index 0cedd1f95f37..ae96bfbb6c83 100644
--- a/drivers/pci/controller/dwc/pcie-intel-gw.c
+++ b/drivers/pci/controller/dwc/pcie-intel-gw.c
@@ -39,6 +39,10 @@
#define PCIE_APP_IRN_PM_TO_ACK BIT(9)
#define PCIE_APP_IRN_LINK_AUTO_BW_STAT BIT(11)
#define PCIE_APP_IRN_BW_MGTBIT(12)
+#define PCIE_APP_IRN_INTA BIT(13)
+#define PCIE_APP_IRN_INTB BIT(14)
+#define PCIE_APP_IRN_INTC BIT(15)
+#define PCIE_APP_IRN_INTD BIT(16)
#define PCIE_APP_IRN_MSG_LTR BIT(18)
#define PCIE_APP_IRN_SYS_ERR_RCBIT(29)
#define PCIE_APP_INTX_OFST 12
@@ -48,10 +52,8 @@
PCIE_APP_IRN_RX_VDM_MSG | PCIE_APP_IRN_SYS_ERR_RC | \
PCIE_APP_IRN_PM_TO_ACK | PCIE_APP_IRN_MSG_LTR | \
PCIE_APP_IRN_BW_MGT | PCIE_APP_IRN_LINK_AUTO_BW_STAT | \
- (PCIE_APP_INTX_OFST + PCI_INTERRUPT_INTA) | \
- (PCIE_APP_INTX_OFST + PCI_INTERRUPT_INTB) | \
- (PCIE_APP_INTX_OFST + PCI_INTERRUPT_INTC) | \
- (PCIE_APP_INTX_OFST + PCI_INTERRUPT_INTD))
+ PCIE_APP_IRN_INTA | PCIE_APP_IRN_INTB | \
+ PCIE_APP_IRN_INTC | PCIE_APP_IRN_INTD)
#define BUS_IATU_OFFSETSZ_256M
#define RESET_INTERVAL_MS 100
--
2.30.0
[PATCH v4 2/5] net: stmmac: dwmac-meson8b: fix enabling the timing-adjustment clock
The timing-adjustment clock only has to be enabled when a) there is a
2ns RX delay configured using device-tree and b) the phy-mode indicates
that the RX delay should be enabled.
Only enable the RX delay if both are true, instead of (by accident) also
enabling it when there's the 2ns RX delay configured but the phy-mode
incicates that the RX delay is not used.
Fixes: 9308c47640d515 ("net: stmmac: dwmac-meson8b: add support for the RX
delay configuration")
Reported-by: Andrew Lunn
Reviewed-by: Andrew Lunn
Reviewed-by: Florian Fainelli
Signed-off-by: Martin Blumenstingl
---
drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
index f184b00f5116..5f500141567d 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
@@ -301,7 +301,7 @@ static int meson8b_init_prg_eth(struct meson8b_dwmac *dwmac)
return -EINVAL;
}
- if (rx_dly_config & PRG_ETH0_ADJ_ENABLE) {
+ if (delay_config & PRG_ETH0_ADJ_ENABLE) {
if (!dwmac->timing_adj_clk) {
dev_err(dwmac->dev,
"The timing-adjustment clock is mandatory for
the RX delay re-timing\n");
--
2.30.0
[PATCH v4 1/5] dt-bindings: net: dwmac-meson: use picoseconds for the RGMII RX delay
Amlogic Meson G12A, G12B and SM1 SoCs have a more advanced RGMII RX delay register which allows picoseconds precision. Deprecate the old "amlogic,rx-delay-ns" in favour of the generic "rx-internal-delay-ps" property. For older SoCs the only known supported values were 0ns and 2ns. The new SoCs have support for RGMII RX delays between 0ps and 3000ps in 200ps steps. Don't carry over the description for the "rx-internal-delay-ps" property and inherit that from ethernet-controller.yaml instead. Reviewed-by: Florian Fainelli Signed-off-by: Martin Blumenstingl --- .../bindings/net/amlogic,meson-dwmac.yaml | 55 +-- 1 file changed, 49 insertions(+), 6 deletions(-) diff --git a/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml index 1f133f4a2924..0467441d7037 100644 --- a/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml +++ b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml @@ -74,17 +74,60 @@ allOf: Any configuration is ignored when the phy-mode is set to "rmii". amlogic,rx-delay-ns: + deprecated: true enum: - 0 - 2 default: 0 description: -The internal RGMII RX clock delay (provided by this IP block) in -nanoseconds. When phy-mode is set to "rgmii" then the RX delay -should be explicitly configured. When the phy-mode is set to -either "rgmii-id" or "rgmii-rxid" the RX clock delay is already -provided by the PHY. Any configuration is ignored when the -phy-mode is set to "rmii". +The internal RGMII RX clock delay in nanoseconds. Deprecated, use +rx-internal-delay-ps instead. + +rx-internal-delay-ps: + default: 0 + + - if: + properties: +compatible: + contains: +enum: + - amlogic,meson8b-dwmac + - amlogic,meson8m2-dwmac + - amlogic,meson-gxbb-dwmac + - amlogic,meson-axg-dwmac +then: + properties: +rx-internal-delay-ps: + enum: +- 0 +- 2000 + + - if: + properties: +compatible: + contains: +enum: + - amlogic,meson-g12a-dwmac +then: + properties: +rx-internal-delay-ps: + enum: +- 0 +- 200 +- 400 +- 600 +- 800 +- 1000 +- 1200 +- 1400 +- 1600 +- 1800 +- 2000 +- 2200 +- 2400 +- 2600 +- 2800 +- 3000 properties: compatible: -- 2.30.0
[PATCH v4 4/5] net: stmmac: dwmac-meson8b: move RGMII delays into a separate function
Newer SoCs starting with the Amlogic Meson G12A have more a precise
RGMII RX delay configuration register. This means more complexity in the
code. Extract the existing RGMII delay configuration code into a
separate function to make it easier to read/understand even when adding
more logic in the future.
Reviewed-by: Andrew Lunn
Reviewed-by: Florian Fainelli
Signed-off-by: Martin Blumenstingl
---
drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
index d2be3a7bd8fd..4937432ac70d 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
@@ -268,7 +268,7 @@ static int meson8b_devm_clk_prepare_enable(struct
meson8b_dwmac *dwmac,
return 0;
}
-static int meson8b_init_prg_eth(struct meson8b_dwmac *dwmac)
+static int meson8b_init_rgmii_delays(struct meson8b_dwmac *dwmac)
{
u32 tx_dly_config, rx_dly_config, delay_config;
int ret;
@@ -323,6 +323,13 @@ static int meson8b_init_prg_eth(struct meson8b_dwmac
*dwmac)
PRG_ETH0_ADJ_DELAY | PRG_ETH0_ADJ_SKEW,
delay_config);
+ return 0;
+}
+
+static int meson8b_init_prg_eth(struct meson8b_dwmac *dwmac)
+{
+ int ret;
+
if (phy_interface_mode_is_rgmii(dwmac->phy_mode)) {
/* only relevant for RMII mode -> disable in RGMII mode */
meson8b_dwmac_mask_bits(dwmac, PRG_ETH0,
@@ -430,6 +437,10 @@ static int meson8b_dwmac_probe(struct platform_device
*pdev)
goto err_remove_config_dt;
}
+ ret = meson8b_init_rgmii_delays(dwmac);
+ if (ret)
+ goto err_remove_config_dt;
+
ret = meson8b_init_rgmii_tx_clk(dwmac);
if (ret)
goto err_remove_config_dt;
--
2.30.0
[PATCH v4 3/5] net: stmmac: dwmac-meson8b: use picoseconds for the RGMII RX delay
Amlogic Meson G12A, G12B and SM1 SoCs have a more advanced RGMII RX
delay register which allows picoseconds precision. Parse the new
"rx-internal-delay-ps" property or fall back to the value from the old
"amlogic,rx-delay-ns" property.
No upstream DTB uses the old "amlogic,rx-delay-ns" property (yet).
Only include minimalistic logic to fall back to the old property,
without any special validation (for example if the old and new
property are given at the same time).
Reviewed-by: Andrew Lunn
Reviewed-by: Florian Fainelli
Signed-off-by: Martin Blumenstingl
---
.../ethernet/stmicro/stmmac/dwmac-meson8b.c | 21 ---
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
index 5f500141567d..d2be3a7bd8fd 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
@@ -82,7 +82,7 @@ struct meson8b_dwmac {
phy_interface_t phy_mode;
struct clk *rgmii_tx_clk;
u32 tx_delay_ns;
- u32 rx_delay_ns;
+ u32 rx_delay_ps;
struct clk *timing_adj_clk;
};
@@ -276,7 +276,7 @@ static int meson8b_init_prg_eth(struct meson8b_dwmac *dwmac)
tx_dly_config = FIELD_PREP(PRG_ETH0_TXDLY_MASK,
dwmac->tx_delay_ns >> 1);
- if (dwmac->rx_delay_ns == 2)
+ if (dwmac->rx_delay_ps == 2000)
rx_dly_config = PRG_ETH0_ADJ_ENABLE | PRG_ETH0_ADJ_SETUP;
else
rx_dly_config = 0;
@@ -406,14 +406,19 @@ static int meson8b_dwmac_probe(struct platform_device
*pdev)
>tx_delay_ns))
dwmac->tx_delay_ns = 2;
- /* use 0ns as fallback since this is what most boards actually use */
- if (of_property_read_u32(pdev->dev.of_node, "amlogic,rx-delay-ns",
->rx_delay_ns))
- dwmac->rx_delay_ns = 0;
+ /* RX delay defaults to 0ps since this is what many boards use */
+ if (of_property_read_u32(pdev->dev.of_node, "rx-internal-delay-ps",
+>rx_delay_ps)) {
+ if (!of_property_read_u32(pdev->dev.of_node,
+ "amlogic,rx-delay-ns",
+ >rx_delay_ps))
+ /* convert ns to ps */
+ dwmac->rx_delay_ps *= 1000;
+ }
- if (dwmac->rx_delay_ns != 0 && dwmac->rx_delay_ns != 2) {
+ if (dwmac->rx_delay_ps != 0 && dwmac->rx_delay_ps != 2000) {
dev_err(>dev,
- "The only allowed RX delays values are: 0ns, 2ns");
+ "The only allowed RX delays values are: 0ps, 2000ps");
ret = -EINVAL;
goto err_remove_config_dt;
}
--
2.30.0
[PATCH v4 0/5] dwmac-meson8b: picosecond precision RX delay support
Hello,
with the help of Jianxin Pan (many thanks!) the meaning of the "new"
PRG_ETH1[19:16] register bits on Amlogic Meson G12A, G12B and SM1 SoCs
are finally known. These SoCs allow fine-tuning the RGMII RX delay in
200ps steps (contrary to what I have thought in the past [0] these are
not some "calibration" values).
The vendor u-boot has code to automatically detect the best RX/TX delay
settings. For now we keep it simple and add a device-tree property with
200ps precision to select the "right" RX delay for each board.
While here, deprecate the "amlogic,rx-delay-ns" property as it's not
used on any upstream .dts (yet). The driver is backwards compatible.
I have tested this on an X96 Air 4GB board (not upstream yet). Testing
with iperf3 gives 938 Mbits/sec in both directions (RX and TX). The
following network settings were used in the .dts (2ns TX delay
generated by the PHY, 800ps RX delay generated by the MAC as the PHY
only supports 0ns or 2ns RX delays):
_mdio {
external_phy: ethernet-phy@0 {
/* Realtek RTL8211F (0x001cc916) */
reg = <0>;
eee-broken-1000t;
reset-assert-us = <1>;
reset-deassert-us = <3>;
reset-gpios = < GPIOZ_15 (GPIO_ACTIVE_LOW |
GPIO_OPEN_DRAIN)>;
interrupt-parent = <_intc>;
/* MAC_INTR on GPIOZ_14 */
interrupts = <26 IRQ_TYPE_LEVEL_LOW>;
};
};
{
status = "okay";
pinctrl-0 = <_pins>, <_rgmii_pins>;
pinctrl-names = "default";
phy-mode = "rgmii-txid";
phy-handle = <_phy>;
amlogic,rgmii-rx-delay-ps = <800>;
};
To use the same settings from vendor u-boot (which in my case has broken
Ethernet) the following commands can be used:
mw.l 0xff634540 0x1621
mw.l 0xff634544 0x3
phyreg w 0x0 0x1040
phyreg w 0x1f 0xd08
phyreg w 0x11 0x9
phyreg w 0x15 0x11
phyreg w 0x1f 0x0
phyreg w 0x0 0x9200
Also I have tested this on a X96 Max board without any .dts changes
to confirm that other boards with the same IP block still work fine
with these changes.
Changes since v3 at [3].
- added Florian's Reviewed-by to patch 1 (thank you!)
- rebased on top of net-next
Changes since v2 at [2]:
- use the generic property name "rx-internal-delay-ps" as suggested by
Rob (thanks!). This affects patches #1 and #3. The biggest change is
is in patch #1 which is why I didn't add Florian's and Andrew's
Reviewed-by
- added Andrew's and Florian's Reviewed-by to patches 2, 3, 4, 5 (many
thanks to both!). I decided to do this despite renaming the property
to the generic name "rx-internal-delay-ps" as it only affects the
patch description and one line of code
- updated patch description of patch #3 to explain why there's not a
lot of validation when parsing the old device-tree property (in
nanosecond precision)
- dropped RFC status
Changes since v1 at [1]:
- updated patch 1 by making it more clear when the RX delay is applied.
Thanks to Andrew for the suggestion!
- added a fix to enabling the timing-adjustment clock only when really
needed. Found by Andrew - thanks!
- added testing not about X96 Max
- v1 did not go to the netdev mailing list, v2 fixes this
[0]
https://lore.kernel.org/netdev/CAFBinCATt4Hi9rigj52nMf3oygyFbnopZcsakGL=kywnsjy...@mail.gmail.com/
[1]
https://patchwork.kernel.org/project/linux-amlogic/list/?series=384279=%2A=both
[2]
https://patchwork.kernel.org/project/linux-amlogic/list/?series=384491=%2A=both
[3]
https://patchwork.kernel.org/project/linux-amlogic/list/?series=406005=%2A=both
Martin Blumenstingl (5):
dt-bindings: net: dwmac-meson: use picoseconds for the RGMII RX delay
net: stmmac: dwmac-meson8b: fix enabling the timing-adjustment clock
net: stmmac: dwmac-meson8b: use picoseconds for the RGMII RX delay
net: stmmac: dwmac-meson8b: move RGMII delays into a separate function
net: stmmac: dwmac-meson8b: add support for the RGMII RX delay on G12A
.../bindings/net/amlogic,meson-dwmac.yaml | 55 +--
.../ethernet/stmicro/stmmac/dwmac-meson8b.c | 91 +++
2 files changed, 120 insertions(+), 26 deletions(-)
--
2.30.0
[PATCH v4 5/5] net: stmmac: dwmac-meson8b: add support for the RGMII RX delay on G12A
Amlogic Meson G12A (and newer: G12B, SM1) SoCs have a more advanced RX
delay logic. Instead of fine-tuning the delay in the nanoseconds range
it now allows tuning in 200 picosecond steps. This support comes with
new bits in the PRG_ETH1[19:16] register.
Add support for validating the RGMII RX delay as well as configuring the
register accordingly on these platforms.
Reviewed-by: Andrew Lunn
Reviewed-by: Florian Fainelli
Signed-off-by: Martin Blumenstingl
---
.../ethernet/stmicro/stmmac/dwmac-meson8b.c | 61 +++
1 file changed, 48 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
index 4937432ac70d..55152d7ba99a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
@@ -68,10 +68,21 @@
*/
#define PRG_ETH0_ADJ_SKEW GENMASK(24, 20)
+#define PRG_ETH1 0x4
+
+/* Defined for adding a delay to the input RX_CLK for better timing.
+ * Each step is 200ps. These bits are used with external RGMII PHYs
+ * because RGMII RX only has the small window. cfg_rxclk_dly can
+ * adjust the window between RX_CLK and RX_DATA and improve the stability
+ * of "rx data valid".
+ */
+#define PRG_ETH1_CFG_RXCLK_DLY GENMASK(19, 16)
+
struct meson8b_dwmac;
struct meson8b_dwmac_data {
int (*set_phy_mode)(struct meson8b_dwmac *dwmac);
+ bool has_prg_eth1_rgmii_rx_delay;
};
struct meson8b_dwmac {
@@ -270,30 +281,35 @@ static int meson8b_devm_clk_prepare_enable(struct
meson8b_dwmac *dwmac,
static int meson8b_init_rgmii_delays(struct meson8b_dwmac *dwmac)
{
- u32 tx_dly_config, rx_dly_config, delay_config;
+ u32 tx_dly_config, rx_adj_config, cfg_rxclk_dly, delay_config;
int ret;
+ rx_adj_config = 0;
+ cfg_rxclk_dly = 0;
tx_dly_config = FIELD_PREP(PRG_ETH0_TXDLY_MASK,
dwmac->tx_delay_ns >> 1);
- if (dwmac->rx_delay_ps == 2000)
- rx_dly_config = PRG_ETH0_ADJ_ENABLE | PRG_ETH0_ADJ_SETUP;
- else
- rx_dly_config = 0;
+ if (dwmac->data->has_prg_eth1_rgmii_rx_delay)
+ cfg_rxclk_dly = FIELD_PREP(PRG_ETH1_CFG_RXCLK_DLY,
+ dwmac->rx_delay_ps / 200);
+ else if (dwmac->rx_delay_ps == 2000)
+ rx_adj_config = PRG_ETH0_ADJ_ENABLE | PRG_ETH0_ADJ_SETUP;
switch (dwmac->phy_mode) {
case PHY_INTERFACE_MODE_RGMII:
- delay_config = tx_dly_config | rx_dly_config;
+ delay_config = tx_dly_config | rx_adj_config;
break;
case PHY_INTERFACE_MODE_RGMII_RXID:
delay_config = tx_dly_config;
+ cfg_rxclk_dly = 0;
break;
case PHY_INTERFACE_MODE_RGMII_TXID:
- delay_config = rx_dly_config;
+ delay_config = rx_adj_config;
break;
case PHY_INTERFACE_MODE_RGMII_ID:
case PHY_INTERFACE_MODE_RMII:
delay_config = 0;
+ cfg_rxclk_dly = 0;
break;
default:
dev_err(dwmac->dev, "unsupported phy-mode %s\n",
@@ -323,6 +339,9 @@ static int meson8b_init_rgmii_delays(struct meson8b_dwmac
*dwmac)
PRG_ETH0_ADJ_DELAY | PRG_ETH0_ADJ_SKEW,
delay_config);
+ meson8b_dwmac_mask_bits(dwmac, PRG_ETH1, PRG_ETH1_CFG_RXCLK_DLY,
+ cfg_rxclk_dly);
+
return 0;
}
@@ -423,11 +442,20 @@ static int meson8b_dwmac_probe(struct platform_device
*pdev)
dwmac->rx_delay_ps *= 1000;
}
- if (dwmac->rx_delay_ps != 0 && dwmac->rx_delay_ps != 2000) {
- dev_err(>dev,
- "The only allowed RX delays values are: 0ps, 2000ps");
- ret = -EINVAL;
- goto err_remove_config_dt;
+ if (dwmac->data->has_prg_eth1_rgmii_rx_delay) {
+ if (dwmac->rx_delay_ps != 0 && dwmac->rx_delay_ps != 2000) {
+ dev_err(dwmac->dev,
+ "The only allowed RGMII RX delays values are:
0ps, 2000ps");
+ ret = -EINVAL;
+ goto err_remove_config_dt;
+ }
+ } else {
+ if (dwmac->rx_delay_ps > 3000 || dwmac->rx_delay_ps % 200) {
+ dev_err(dwmac->dev,
+ "The RGMII RX delay range is 0..3000ps in 200ps
steps");
+ ret = -EINVAL;
+ goto err_remove_config_dt;
+ }
}
dwmac->timing_adj_clk = devm_clk_get_optional(dwmac->dev,
@@
Re: discussion: re-structuring of the Amlogic Meson VPU DRM driver
Hi Neil, On Mon, Jan 4, 2021 at 2:29 PM Neil Armstrong wrote: > > Hi, > > Sorry for the delay... > > On 31/12/2020 00:24, Martin Blumenstingl wrote: > > Hi Neil and all interested people, > > > > in the past there were concerns about how some of the components are > > coupled in our Meson DRM driver(s). > > With this discussion I would like to achieve four things: > > 1. understand the current issues that we have> 2. come up with a TODO list > > of things that need to be tackled as well > > as recommendations how to solve it (for example: "driver ABC function > > ABC uses the recommended way - take that as reference") > > 3. one by one work on the items on the TODO list > > 4. add support for the 32-bit SoCs to the Meson VPU DRM driver > > (without adding more "not recommended" code) > > > > Disclaimer: I am not familiar with the DRM subsystem - so apologies if > > the terminology is not correct. > > > > drivers/gpu/drm/meson/meson_dw_hdmi.c currently serves four purposes: > > 1. manage the TOP (glue) registers for the dw-hdmi IP > > This is Amlogic specific and consists of things like HPD filtering, > > some internal resets, etc. > > In my opinion this part is supposed to stay in this driver > Yep, it's tightly coupled to the DW-HDMI core > > > > > 2. load the driver for the dw-hdmi IP by calling dw_hdmi_probe() > > I read somewhere that this is not recommended anymore and should be > > replaced. > > Is my understanding correct and what is the recommended replacement? > Yeah in fact the dw-hdmi glue should be a pure bridge, not a component > anymore. > > This means it should probe by itself entirely, should not use the component > stuff. OK, I see > This also means all the VPU related part (mainly encoder and clock) should be > moved > out of this file as a bridge and built with the meson_drm driver, > then find the "next bridge" like other drivers. is that linkage automatically set up with the endpoint definitions inside the .dts? > > 3. it manages the HDMI PHY registers in the HHI register area > > For the 32-bit SoCs I will not follow this pattern and will create a > > separate PHY instead. > > As a long-term goal I think we should also move this into a dedicated > > PHY driver. > > I looked at it, and ... it's complex. For the 32-bit socs it's easy because > you only have a single PHY setup, for the new gens you have to deal with the > 4k modes and co. This could be handle by adding a new parameters set to the > phy_configure union, but what should we add in it to be super generic ? you are right, on the 32-bit SoCs it's pretty easy actually. it's only "4k" and "everything else". I think using the phy_configure approach is the right way but to be honest: I have not thought about which parameters to add to that union (for the 64-bit SoCs) to make it "generic" enough also I think this is a TODO "for later", so no action needed now - but it's great to see that you had the same idea in mind :) > > > > 4. call back into VPU/VENC functions to set up these registers > > This is a blocker for 32-bit SoC support as I would have to duplicate > > this code if we don't make any changes. This includes things like > > calculating (and setting) clock frequencies, calling > > meson_venc_hdmi_mode_set for setting up the DVI pixel encoder, etc. > > My understanding is that this part should not be part of the > > meson_dw_hdmi driver, but "some other" driver. I don't understand > > which driver that's supposed to be though and how things would be > > wired up in the end. > > Yep it should be a bridge. You can chain bridges, it's designed for such use > case. > > We will have internal bridges for encoders, ENCL+ENCP grouped for HDMI and > ENCL. I see. adding to my question above: would this mean that we have then more "endpoints" defined in our .dts - one for the ENCI+ENCP (HDMI) output, another one for the ENCL (DSI), ...? > CVBS can be handled separately without bridges. indeed, let's postpone CVBS for now as it's easy to adapt the current code for the 32-bit SoCs. in a perfect world I think the CVBS encoder/bridge (whatever the correct type is) would be it's own driver as it's part of the HHI registers > I can have a try to move stuff if you can review/test on your side. > Would it be a good start ? that would be awesome if there's any way I can help (you add FIXMEs/TODOs to your code which you want me to solve, testing, etc.) then please let me know! > > > > In addition to HDMI my understanding is that for adding MIPI DSI > > support you would > > a) e
Re: [PATCH 1/2] net: dsa: lantiq_gswip: Enable GSWIP_MII_CFG_EN also for internal PHYs
Hi Jakub,
On Mon, Jan 4, 2021 at 10:52 PM Jakub Kicinski wrote:
>
> On Sun, 3 Jan 2021 03:12:21 +0100 Martin Blumenstingl wrote:
> > Hi Andrew,
> >
> > On Sun, Jan 3, 2021 at 3:09 AM Andrew Lunn wrote:
> > >
> > > On Sun, Jan 03, 2021 at 02:25:43AM +0100, Martin Blumenstingl wrote:
> > > > Enable GSWIP_MII_CFG_EN also for internal PHYs to make traffic flow.
> > > > Without this the PHY link is detected properly and ethtool statistics
> > > > for TX are increasing but there's no RX traffic coming in.
> > > >
> > > > Fixes: 14fceff4771e51 ("net: dsa: Add Lantiq / Intel DSA driver for
> > > > vrx200")
> > > > Cc: sta...@vger.kernel.org
> > >
> > > Hi Martin
> > >
> > > No need to Cc: stable. David or Jakub will handle the backport to
> > > stable. You should however set the subject to [PATCH net 1/2] and
> > > base the patches on the net tree, not net-next.
> > do you recommend re-sending these patches and changing the subject?
> > the lantiq_gswip.c driver is identical in -net and -net-next and so
> > the patch will apply fine in both cases
>
> Resend is pretty much always a safe bet. But since as you said trees
> are identical at the moment I made an exception applied as is :)
awesome, thank you! :-)
Best regards,
Martin
[PATCH 0/5] clk: meson8b: video clock tree updates
Hi Jerome, this is a small set of updates for the video clocks. I have verified these patches to be able to generate the video clocks for 1080P, 720P and a few other video modes. The main "mystery" is still how the rate doubling happens. However, that doesn't affect these patches as with this rate doubling the "hdmi_pll_lvds_out" (which is a parent of this tree) is doubled as well. That's why I am sending these patches because even with this unknown part about rate doubling they will still be valid once that unknown part has been figured out. Martin Blumenstingl (5): clk: meson: meson8b: don't use MPLL1 as parent of vclk_in_sel clk: meson: meson8b: define the rate range for the hdmi_pll_dco clock clk: meson: meson8b: add the video clock divider tables clk: meson: meson8b: add the HDMI PLL M/N parameters clk: meson: meson8b: add the vid_pll_lvds_en gate clock drivers/clk/meson/meson8b.c | 79 - drivers/clk/meson/meson8b.h | 3 +- 2 files changed, 79 insertions(+), 3 deletions(-) -- 2.30.0
[PATCH 5/5] clk: meson: meson8b: add the vid_pll_lvds_en gate clock
HHI_VID_DIVIDER_CNTL[11] must be enabled for the video clock tree to
work. This bit is described as "LVDS_CLK_EN". It is not 100% clear where
this bit has to be placed in the hierarchy. But since the "LVDS_OUT" of
the HDMI PLL uses it's own set of registers it's more likely that this
"LVDS_CLK_EN" bit actually enables the input of the "hdmi_pll_lvds_out"
clock to the "vid_pll_in_sel" tree.
Add a gate definition for this bit (which will not be exported) so that
the kernel can manage all required bits to enable and disable the video
clocks.
Signed-off-by: Martin Blumenstingl
---
drivers/clk/meson/meson8b.c | 23 ++-
drivers/clk/meson/meson8b.h | 3 ++-
2 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/meson/meson8b.c b/drivers/clk/meson/meson8b.c
index 8061c11389a9..450579779de0 100644
--- a/drivers/clk/meson/meson8b.c
+++ b/drivers/clk/meson/meson8b.c
@@ -1068,6 +1068,23 @@ static struct clk_regmap meson8b_l2_dram_clk_gate = {
},
};
+/* also called LVDS_CLK_EN */
+static struct clk_regmap meson8b_vid_pll_lvds_en = {
+ .data = &(struct clk_regmap_gate_data){
+ .offset = HHI_VID_DIVIDER_CNTL,
+ .bit_idx = 11,
+ },
+ .hw.init = &(struct clk_init_data){
+ .name = "vid_pll_lvds_en",
+ .ops = _regmap_gate_ro_ops,
+ .parent_hws = (const struct clk_hw *[]) {
+ _hdmi_pll_lvds_out.hw
+ },
+ .num_parents = 1,
+ .flags = CLK_SET_RATE_PARENT,
+ },
+};
+
static struct clk_regmap meson8b_vid_pll_in_sel = {
.data = &(struct clk_regmap_mux_data){
.offset = HHI_VID_DIVIDER_CNTL,
@@ -1084,7 +1101,7 @@ static struct clk_regmap meson8b_vid_pll_in_sel = {
* Meson8m2: vid2_pll
*/
.parent_hws = (const struct clk_hw *[]) {
- _hdmi_pll_lvds_out.hw
+ _vid_pll_lvds_en.hw
},
.num_parents = 1,
.flags = CLK_SET_RATE_PARENT,
@@ -2954,6 +2971,7 @@ static struct clk_hw_onecell_data meson8_hw_onecell_data
= {
[CLKID_CTS_MCLK_I958_DIV] = _cts_mclk_i958_div.hw,
[CLKID_CTS_MCLK_I958] = _cts_mclk_i958.hw,
[CLKID_CTS_I958]= _cts_i958.hw,
+ [CLKID_VID_PLL_LVDS_EN] = _vid_pll_lvds_en.hw,
[CLK_NR_CLKS] = NULL,
},
.num = CLK_NR_CLKS,
@@ -3171,6 +3189,7 @@ static struct clk_hw_onecell_data meson8b_hw_onecell_data
= {
[CLKID_CTS_MCLK_I958_DIV] = _cts_mclk_i958_div.hw,
[CLKID_CTS_MCLK_I958] = _cts_mclk_i958.hw,
[CLKID_CTS_I958]= _cts_i958.hw,
+ [CLKID_VID_PLL_LVDS_EN] = _vid_pll_lvds_en.hw,
[CLK_NR_CLKS] = NULL,
},
.num = CLK_NR_CLKS,
@@ -3390,6 +3409,7 @@ static struct clk_hw_onecell_data
meson8m2_hw_onecell_data = {
[CLKID_CTS_MCLK_I958_DIV] = _cts_mclk_i958_div.hw,
[CLKID_CTS_MCLK_I958] = _cts_mclk_i958.hw,
[CLKID_CTS_I958]= _cts_i958.hw,
+ [CLKID_VID_PLL_LVDS_EN] = _vid_pll_lvds_en.hw,
[CLK_NR_CLKS] = NULL,
},
.num = CLK_NR_CLKS,
@@ -3588,6 +3608,7 @@ static struct clk_regmap *const meson8b_clk_regmaps[] = {
_cts_mclk_i958_div,
_cts_mclk_i958,
_cts_i958,
+ _vid_pll_lvds_en,
};
static const struct meson8b_clk_reset_line {
diff --git a/drivers/clk/meson/meson8b.h b/drivers/clk/meson/meson8b.h
index b1a5074cf148..954d97cf6c5a 100644
--- a/drivers/clk/meson/meson8b.h
+++ b/drivers/clk/meson/meson8b.h
@@ -182,8 +182,9 @@
#define CLKID_CTS_MCLK_I958_DIV211
#define CLKID_VCLK_EN 214
#define CLKID_VCLK2_EN 215
+#define CLKID_VID_PLL_LVDS_EN 216
-#define CLK_NR_CLKS216
+#define CLK_NR_CLKS217
/*
* include the CLKID and RESETID that have
--
2.30.0
[PATCH 3/5] clk: meson: meson8b: add the video clock divider tables
Add all known clock dividers from Amlogic's 3.10 vendor kernel. If not
stated otherwise the values given in the tables are the only ones used
by the 3.10 vendor kernel even if the hardware is capable of other
dividers as well:
- vid_pll_pre_div can divide by 5 or 6 and if u-boot did not initialize
this clock then it divides by 1 by default (only 5 and 6 are used at
runtime by the vendor kernel though)
- vid_pll_post_div is either 1 or 2
- vid_pll_final_div is either 1, 2 or 4
Signed-off-by: Martin Blumenstingl
---
drivers/clk/meson/meson8b.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/clk/meson/meson8b.c b/drivers/clk/meson/meson8b.c
index 16ab595ab1a4..1ae771bac4a5 100644
--- a/drivers/clk/meson/meson8b.c
+++ b/drivers/clk/meson/meson8b.c
@@ -1084,11 +1084,19 @@ static struct clk_regmap meson8b_vid_pll_in_en = {
},
};
+static const struct clk_div_table vid_pll_pre_div_table[] = {
+ { .val = 0, .div = 1 },
+ { .val = 4, .div = 5 },
+ { .val = 5, .div = 6 },
+ { /* sentinel */ }
+};
+
static struct clk_regmap meson8b_vid_pll_pre_div = {
.data = &(struct clk_regmap_div_data){
.offset = HHI_VID_DIVIDER_CNTL,
.shift = 4,
.width = 3,
+ .table = vid_pll_pre_div_table,
},
.hw.init = &(struct clk_init_data){
.name = "vid_pll_pre_div",
@@ -1101,11 +1109,18 @@ static struct clk_regmap meson8b_vid_pll_pre_div = {
},
};
+static const struct clk_div_table vid_pll_post_div_table[] = {
+ { .val = 0, .div = 1 },
+ { .val = 1, .div = 2 },
+ { /* sentinel */ }
+};
+
static struct clk_regmap meson8b_vid_pll_post_div = {
.data = &(struct clk_regmap_div_data){
.offset = HHI_VID_DIVIDER_CNTL,
.shift = 12,
.width = 3,
+ .table = vid_pll_post_div_table,
},
.hw.init = &(struct clk_init_data){
.name = "vid_pll_post_div",
@@ -1137,11 +1152,19 @@ static struct clk_regmap meson8b_vid_pll = {
},
};
+static const struct clk_div_table meson8b_vid_pll_final_div_table[] = {
+ { .val = 0, .div = 1 },
+ { .val = 1, .div = 2 },
+ { .val = 3, .div = 4 },
+ { /* sentinel */ }
+};
+
static struct clk_regmap meson8b_vid_pll_final_div = {
.data = &(struct clk_regmap_div_data){
.offset = HHI_VID_CLK_DIV,
.shift = 0,
.width = 8,
+ .table = meson8b_vid_pll_final_div_table,
},
.hw.init = &(struct clk_init_data){
.name = "vid_pll_final_div",
--
2.30.0
[PATCH 4/5] clk: meson: meson8b: add the HDMI PLL M/N parameters
The 3.10 vendor kernel uses only specific HDMI PLL M/N parameter
combinations. The PLL won't lock for values smaller than 50 if the
internal doubling (which is yet unknown how to use it) is disabled.
However, when this doubling is enabled then the values smaller than 50
will lock just fine. The only restriction for values greater than 50 is
that the resulting frequency must not exceed the 3.0GHz limit.
These values are taken from the endlessm 3.10 kernel which includes some
additional M/N combinations for some VESA and 75Hz display modes.
Signed-off-by: Martin Blumenstingl
---
drivers/clk/meson/meson8b.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/clk/meson/meson8b.c b/drivers/clk/meson/meson8b.c
index 1ae771bac4a5..8061c11389a9 100644
--- a/drivers/clk/meson/meson8b.c
+++ b/drivers/clk/meson/meson8b.c
@@ -118,6 +118,28 @@ static struct clk_regmap meson8b_fixed_pll = {
},
};
+static const struct pll_params_table hdmi_pll_params_table[] = {
+ PLL_PARAMS(34, 1),
+ PLL_PARAMS(40, 1),
+ PLL_PARAMS(42, 1),
+ PLL_PARAMS(44, 1),
+ PLL_PARAMS(45, 1),
+ PLL_PARAMS(49, 1),
+ PLL_PARAMS(52, 1),
+ PLL_PARAMS(54, 1),
+ PLL_PARAMS(56, 1),
+ PLL_PARAMS(59, 1),
+ PLL_PARAMS(60, 1),
+ PLL_PARAMS(61, 1),
+ PLL_PARAMS(62, 1),
+ PLL_PARAMS(64, 1),
+ PLL_PARAMS(66, 1),
+ PLL_PARAMS(68, 1),
+ PLL_PARAMS(71, 1),
+ PLL_PARAMS(82, 1),
+ { /* sentinel */ }
+};
+
static struct clk_regmap meson8b_hdmi_pll_dco = {
.data = &(struct meson_clk_pll_data){
.en = {
@@ -150,6 +172,7 @@ static struct clk_regmap meson8b_hdmi_pll_dco = {
.shift = 29,
.width = 1,
},
+ .table = hdmi_pll_params_table,
},
.hw.init = &(struct clk_init_data){
/* sometimes also called "HPLL" or "HPLL PLL" */
--
2.30.0
[PATCH 1/5] clk: meson: meson8b: don't use MPLL1 as parent of vclk_in_sel
MPLL1 is needed for audio output. Drop it from the vclk_in_sel parent
list so we only use the (mutable) vid_pll_final_div tree or one of the
(fixed) FCLK_DIV{3,4,5} clocks.
Signed-off-by: Martin Blumenstingl
---
drivers/clk/meson/meson8b.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/meson/meson8b.c b/drivers/clk/meson/meson8b.c
index a844d35b553a..f8bd211db720 100644
--- a/drivers/clk/meson/meson8b.c
+++ b/drivers/clk/meson/meson8b.c
@@ -1154,6 +1154,10 @@ static struct clk_regmap meson8b_vid_pll_final_div = {
},
};
+/*
+ * parent 0x6 is meson8b_mpll1 but we don't use it here because it's reserved
+ * for the audio outputs.
+ */
static const struct clk_hw *meson8b_vclk_mux_parent_hws[] = {
_vid_pll_final_div.hw,
_fclk_div4.hw,
@@ -1161,7 +1165,6 @@ static const struct clk_hw *meson8b_vclk_mux_parent_hws[]
= {
_fclk_div5.hw,
_vid_pll_final_div.hw,
_fclk_div7.hw,
- _mpll1.hw,
};
static struct clk_regmap meson8b_vclk_in_sel = {
--
2.30.0
[PATCH 2/5] clk: meson: meson8b: define the rate range for the hdmi_pll_dco clock
According to the public S805 datasheet the HDMI PLL VCO frequency has to be between 1.2GHz and 3.0GHz. Add this range in our driver so we won't get too low (which means the PLL won't lock) or too high. Signed-off-by: Martin Blumenstingl --- drivers/clk/meson/meson8b.c | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/clk/meson/meson8b.c b/drivers/clk/meson/meson8b.c index f8bd211db720..16ab595ab1a4 100644 --- a/drivers/clk/meson/meson8b.c +++ b/drivers/clk/meson/meson8b.c @@ -3781,6 +3781,11 @@ static void __init meson8b_clkc_init_common(struct device_node *np, return; } + /* The HDMI PLL VCO is limited to 1.2G~3.0GHz */ + clk_hw_set_rate_range(clk_hw_onecell_data->hws[CLKID_HDMI_PLL_DCO], + 1200 * 1000UL * 1000UL, + 3000 * 1000UL * 1000UL); + ret = of_clk_add_hw_provider(np, of_clk_hw_onecell_get, clk_hw_onecell_data); if (ret) -- 2.30.0
Re: [PATCH] mtd: rawnand: intel: remove broken code
Hi Miquel,
thank you for looking into this
On Mon, Jan 4, 2021 at 9:48 AM Miquel Raynal wrote:
[...]
> > nand_set_flash_node(_host->chip, dev->of_node);
> > - if (!mtd->name) {
> > - dev_err(ebu_host->dev, "NAND label property is mandatory\n");
> > - return -EINVAL;
> > - }
>
> This is valid code, it's best to use a label = "my-storage"; property
> in your NAND DT node. Then mtd->name will be updated by
> nand_set_flash_node().
so you suggest moving the check instead?
the original code flow was:
mtd = NULL;
if (!mtd->name)
return -EINVAL;
mtd = nand_to_mtd(_host->chip);
...
by saying that the code itself is valid you're asking me to update the
flow to the following:
mtd = nand_to_mtd(_host->chip);
if (!mtd->name)
return -EINVAL;
Best regards,
Martin
Re: [PATCH 1/2] net: dsa: lantiq_gswip: Enable GSWIP_MII_CFG_EN also for internal PHYs
Hi Andrew,
On Sun, Jan 3, 2021 at 3:09 AM Andrew Lunn wrote:
>
> On Sun, Jan 03, 2021 at 02:25:43AM +0100, Martin Blumenstingl wrote:
> > Enable GSWIP_MII_CFG_EN also for internal PHYs to make traffic flow.
> > Without this the PHY link is detected properly and ethtool statistics
> > for TX are increasing but there's no RX traffic coming in.
> >
> > Fixes: 14fceff4771e51 ("net: dsa: Add Lantiq / Intel DSA driver for vrx200")
> > Cc: sta...@vger.kernel.org
>
> Hi Martin
>
> No need to Cc: stable. David or Jakub will handle the backport to
> stable. You should however set the subject to [PATCH net 1/2] and
> base the patches on the net tree, not net-next.
do you recommend re-sending these patches and changing the subject?
the lantiq_gswip.c driver is identical in -net and -net-next and so
the patch will apply fine in both cases
Best regards,
Martin
[PATCH 1/2] net: dsa: lantiq_gswip: Enable GSWIP_MII_CFG_EN also for internal PHYs
Enable GSWIP_MII_CFG_EN also for internal PHYs to make traffic flow.
Without this the PHY link is detected properly and ethtool statistics
for TX are increasing but there's no RX traffic coming in.
Fixes: 14fceff4771e51 ("net: dsa: Add Lantiq / Intel DSA driver for vrx200")
Cc: sta...@vger.kernel.org
Suggested-by: Hauke Mehrtens
Signed-off-by: Martin Blumenstingl
---
drivers/net/dsa/lantiq_gswip.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/net/dsa/lantiq_gswip.c b/drivers/net/dsa/lantiq_gswip.c
index 09701c17f3f6..5d378c8026f0 100644
--- a/drivers/net/dsa/lantiq_gswip.c
+++ b/drivers/net/dsa/lantiq_gswip.c
@@ -1541,9 +1541,7 @@ static void gswip_phylink_mac_link_up(struct dsa_switch
*ds, int port,
{
struct gswip_priv *priv = ds->priv;
- /* Enable the xMII interface only for the external PHY */
- if (interface != PHY_INTERFACE_MODE_INTERNAL)
- gswip_mii_mask_cfg(priv, 0, GSWIP_MII_CFG_EN, port);
+ gswip_mii_mask_cfg(priv, 0, GSWIP_MII_CFG_EN, port);
}
static void gswip_get_strings(struct dsa_switch *ds, int port, u32 stringset,
--
2.30.0
[PATCH 2/2] net: dsa: lantiq_gswip: Fix GSWIP_MII_CFG(p) register access
There is one GSWIP_MII_CFG register for each switch-port except the CPU
port. The register offset for the first port is 0x0, 0x02 for the
second, 0x04 for the third and so on.
Update the driver to not only restrict the GSWIP_MII_CFG registers to
ports 0, 1 and 5. Handle ports 0..5 instead but skip the CPU port. This
means we are not overwriting the configuration for the third port (port
two since we start counting from zero) with the settings for the sixth
port (with number five) anymore.
The GSWIP_MII_PCDU(p) registers are not updated because there's really
only three (one for each of the following ports: 0, 1, 5).
Fixes: 14fceff4771e51 ("net: dsa: Add Lantiq / Intel DSA driver for vrx200")
Cc: sta...@vger.kernel.org
Signed-off-by: Martin Blumenstingl
---
drivers/net/dsa/lantiq_gswip.c | 23 ++-
1 file changed, 6 insertions(+), 17 deletions(-)
diff --git a/drivers/net/dsa/lantiq_gswip.c b/drivers/net/dsa/lantiq_gswip.c
index 5d378c8026f0..4b36d89bec06 100644
--- a/drivers/net/dsa/lantiq_gswip.c
+++ b/drivers/net/dsa/lantiq_gswip.c
@@ -92,9 +92,7 @@
GSWIP_MDIO_PHY_FDUP_MASK)
/* GSWIP MII Registers */
-#define GSWIP_MII_CFG0 0x00
-#define GSWIP_MII_CFG1 0x02
-#define GSWIP_MII_CFG5 0x04
+#define GSWIP_MII_CFGp(p) (0x2 * (p))
#define GSWIP_MII_CFG_EN BIT(14)
#define GSWIP_MII_CFG_LDCLKDISBIT(12)
#define GSWIP_MII_CFG_MODE_MIIP 0x0
@@ -392,17 +390,9 @@ static void gswip_mii_mask(struct gswip_priv *priv, u32
clear, u32 set,
static void gswip_mii_mask_cfg(struct gswip_priv *priv, u32 clear, u32 set,
int port)
{
- switch (port) {
- case 0:
- gswip_mii_mask(priv, clear, set, GSWIP_MII_CFG0);
- break;
- case 1:
- gswip_mii_mask(priv, clear, set, GSWIP_MII_CFG1);
- break;
- case 5:
- gswip_mii_mask(priv, clear, set, GSWIP_MII_CFG5);
- break;
- }
+ /* There's no MII_CFG register for the CPU port */
+ if (!dsa_is_cpu_port(priv->ds, port))
+ gswip_mii_mask(priv, clear, set, GSWIP_MII_CFGp(port));
}
static void gswip_mii_mask_pcdu(struct gswip_priv *priv, u32 clear, u32 set,
@@ -822,9 +812,8 @@ static int gswip_setup(struct dsa_switch *ds)
gswip_mdio_mask(priv, 0xff, 0x09, GSWIP_MDIO_MDC_CFG1);
/* Disable the xMII link */
- gswip_mii_mask_cfg(priv, GSWIP_MII_CFG_EN, 0, 0);
- gswip_mii_mask_cfg(priv, GSWIP_MII_CFG_EN, 0, 1);
- gswip_mii_mask_cfg(priv, GSWIP_MII_CFG_EN, 0, 5);
+ for (i = 0; i < priv->hw_info->max_ports; i++)
+ gswip_mii_mask_cfg(priv, GSWIP_MII_CFG_EN, 0, i);
/* enable special tag insertion on cpu port */
gswip_switch_mask(priv, 0, GSWIP_FDMA_PCTRL_STEN,
--
2.30.0
[PATCH 0/2] net: dsa: lantiq_gswip: two fixes for -net/-stable
While testing the lantiq_gswip driver in OpenWrt at least one board had a non-working Ethernet port connected to an internal 100Mbit/s PHY22F GPHY. The problem which could be observed: - the PHY would detect the link just fine - ethtool stats would see the TX counter rise - the RX counter in ethtool was stuck at zero It turns out that two independent patches are needed to fix this: - first we need to enable the MII data lines also for internal PHYs - second we need to program the GSWIP_MII_CFG registers for all ports except the CPU port These two patches have also been tested by back-porting them on top of Linux 5.4.86 in OpenWrt. Special thanks to Hauke for debugging and brainstorming this on IRC with me! Martin Blumenstingl (2): net: dsa: lantiq_gswip: Enable GSWIP_MII_CFG_EN also for internal PHYs net: dsa: lantiq_gswip: Fix GSWIP_MII_CFG(p) register access drivers/net/dsa/lantiq_gswip.c | 27 +++ 1 file changed, 7 insertions(+), 20 deletions(-) -- 2.30.0
[PATCH v2 0/5] Amlogic Meson Always-On ARC remote-processor support
Amlogic Meson6/8/8b/8m2 come with an ARC core in the Always-On (AO) power-domain. This is typically used for waking up the ARM CPU after powering it down for system suspend. The exact ARC core used on Meson6 and earlier is not known. I believe it is an ARC625, but I am not sure about this. Meson8/8b/8m2 uses an ARC EM4 core. They all have in common that they use a section of the SoCs SRAM for running code on the ARC core. Unfortunately there's no information about the remote-processor control registers in the public Meson8b (S805) datasheet. All information is either taken from Amlogic's 3.10 kernel and 2011-03 u-boot or found by testing (for example the clock input is not mentioned anywhere in the reference code, but disabling it stops the AO ARC core from working). This series consists of five patches: 1: dt-bindings for the SRAM section 2: dt-bindings for the SECBUS2 syscon region which contains a few bits for controlling this remote processor 3: dt-bindings for the AO ARC remote processor 4: the driver for booting code on the AO ARC remote processor 5: (only included for documentation purposes) dts changes (these will be re-sent separately) Patches #3 and #4 should go through the remoteproc tree. Patches #1 and #2 may go through Rob's (devicetree) tree, Kevin's linux-amlogic tree or through the remoteproc tree. Personally I have no preference here. To test this series I ported the Amlogic serial driver and added the board files for the Amlogic AO ARC EM4 to the Zephyr RTOS. The code can be found here: [0] (the resulting zephyr.elf can then be loaded as remote-processor firmware from Linux). Changes since v1 at [1]: - fixed yamllint warnings (after installing the package these now also show up on my build machine) in patches #2 and #3. Thanks for the hint Rob - dropped the explicit "select" statement from the dt-bindings in patch #2 as suggested by Rob (thanks) [0] https://github.com/xdarklight/zephyr-rtos/commits/amlogic_ao_em4-20201229 [1] https://patchwork.kernel.org/project/linux-amlogic/list/?series=407349 Martin Blumenstingl (5): dt-bindings: sram: Add compatible strings for the Meson AO ARC SRAM dt-bindings: Amlogic: add the documentation for the SECBUS2 registers dt-bindings: remoteproc: Add the documentation for Meson AO ARC rproc remoteproc: meson-mx-ao-arc: Add a driver for the AO ARC remote procesor ARM: dts: meson: add the AO ARC remote processor .../arm/amlogic/amlogic,meson-mx-secbus2.yaml | 42 +++ .../remoteproc/amlogic,meson-mx-ao-arc.yaml | 87 +++ .../devicetree/bindings/sram/sram.yaml| 2 + arch/arm/boot/dts/meson.dtsi | 7 + arch/arm/boot/dts/meson8.dtsi | 21 ++ arch/arm/boot/dts/meson8b.dtsi| 21 ++ drivers/remoteproc/Kconfig| 11 + drivers/remoteproc/Makefile | 1 + drivers/remoteproc/meson_mx_ao_arc.c | 240 ++ 9 files changed, 432 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-mx-secbus2.yaml create mode 100644 Documentation/devicetree/bindings/remoteproc/amlogic,meson-mx-ao-arc.yaml create mode 100644 drivers/remoteproc/meson_mx_ao_arc.c -- 2.30.0
[PATCH v2 3/5] dt-bindings: remoteproc: Add the documentation for Meson AO ARC rproc
Amlogic Meson6, Meson8, Meson8b and Meson8m2 SoCs embed an ARC EM4
controller for always-on operations, typically used for managing system
suspend.
Signed-off-by: Martin Blumenstingl
---
.../remoteproc/amlogic,meson-mx-ao-arc.yaml | 87 +++
1 file changed, 87 insertions(+)
create mode 100644
Documentation/devicetree/bindings/remoteproc/amlogic,meson-mx-ao-arc.yaml
diff --git
a/Documentation/devicetree/bindings/remoteproc/amlogic,meson-mx-ao-arc.yaml
b/Documentation/devicetree/bindings/remoteproc/amlogic,meson-mx-ao-arc.yaml
new file mode 100644
index ..d892d29a656b
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/amlogic,meson-mx-ao-arc.yaml
@@ -0,0 +1,87 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/remoteproc/amlogic,meson-mx-ao-arc.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: Amlogic Meson AO ARC Remote Processor bindings
+
+description:
+ Amlogic Meson6, Meson8, Meson8b and Meson8m2 SoCs embed an ARC core
+ controller for always-on operations, typically used for managing
+ system suspend. Meson6 and older use a ARC core based on the ARCv1
+ ISA, while Meson8, Meson8b and Meson8m2 use an ARC EM4 (ARCv2 ISA)
+ core.
+
+maintainers:
+ - Martin Blumenstingl
+
+properties:
+ compatible:
+items:
+ - enum:
+ - amlogic,meson8-ao-arc
+ - amlogic,meson8b-ao-arc
+ - const: amlogic,meson-mx-ao-arc
+
+ firmware-name:
+$ref: /schemas/types.yaml#/definitions/string
+description:
+ The name of the firmware which should be loaded for this remote
+ processor.
+
+ reg:
+description:
+ Address ranges of the remap and CPU control addresses for the
+ remote processor.
+minItems: 2
+
+ reg-names:
+items:
+ - const: remap
+ - const: cpu
+
+ resets:
+minItems: 1
+
+ clocks:
+minItems: 1
+
+ sram:
+$ref: /schemas/types.yaml#/definitions/phandle
+description:
+ phandles to a reserved SRAM region which is used as the memory of
+ the ARC core. The region should be defined as child nodes of the
+ AHB SRAM node as per the generic bindings in
+ Documentation/devicetree/bindings/sram/sram.yaml
+
+ amlogic,secbus2:
+$ref: /schemas/types.yaml#/definitions/phandle
+description:
+ A phandle to the SECBUS2 region which contains some configuration
+ bits of this remote processor
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - resets
+ - clocks
+ - sram
+ - amlogic,secbus2
+
+additionalProperties: false
+
+examples:
+ - |
+remoteproc@1c {
+ compatible= "amlogic,meson8-ao-arc", "amlogic,meson-mx-ao-arc";
+ reg = <0x1c 0x8>, <0x38 0x8>;
+ reg-names = "remap", "cpu";
+ resets = <_cpu_reset>;
+ clocks = <_cpu_clock>;
+ sram = <_sram_ao_arc>;
+ amlogic,secbus2 = <>;
+};
+
+...
--
2.30.0
[PATCH v2 5/5] ARM: dts: meson: add the AO ARC remote processor
The 32-bit Amlogic Meson SoCs embed an ARC processor in the Always-On
power domain which is typically used for managing system suspend. The
memory for this ARC core is taken from the AHB SRAM area. Depending on
the actual SoC a different ARC core is used:
- Meson6 and earlier: some ARCv1 ISA based core (probably an ARC625)
- Meson8 and later: an ARC EM4 (ARCv2 ISA) based core
Add the device-tree node for this remote-processor along with the
required SRAM sections, clocks and reset-lines. Also use the
SoC-specific compatible string to manage any differences (should
they exist).
On Meson8, Meson8b and Meson8m2 the "secbus2" IO region is needed as
some bits need to be programmed there. Add this IO region for those
SoCs as well.
Signed-off-by: Martin Blumenstingl
---
arch/arm/boot/dts/meson.dtsi | 7 +++
arch/arm/boot/dts/meson8.dtsi | 21 +
arch/arm/boot/dts/meson8b.dtsi | 21 +
3 files changed, 49 insertions(+)
diff --git a/arch/arm/boot/dts/meson.dtsi b/arch/arm/boot/dts/meson.dtsi
index e0ca5f08d07d..8bae6ed0abb2 100644
--- a/arch/arm/boot/dts/meson.dtsi
+++ b/arch/arm/boot/dts/meson.dtsi
@@ -200,6 +200,13 @@ aobus: aobus@c810 {
#size-cells = <1>;
ranges = <0x0 0xc810 0x10>;
+ ao_arc_rproc: remoteproc@1c {
+ compatible= "amlogic,meson-mx-ao-arc";
+ reg = <0x1c 0x8>, <0x38 0x8>;
+ reg-names = "remap", "cpu";
+ status = "disabled";
+ };
+
ir_receiver: ir-receiver@480 {
compatible= "amlogic,meson6-ir";
reg = <0x480 0x20>;
diff --git a/arch/arm/boot/dts/meson8.dtsi b/arch/arm/boot/dts/meson8.dtsi
index 420324ea2ad7..157a950a55d3 100644
--- a/arch/arm/boot/dts/meson8.dtsi
+++ b/arch/arm/boot/dts/meson8.dtsi
@@ -369,6 +369,14 @@ mux {
};
};
+_arc_rproc {
+ compatible= "amlogic,meson8-ao-arc", "amlogic,meson-mx-ao-arc";
+ amlogic,secbus2 = <>;
+ sram = <_arc_sram>;
+ resets = < RESET_MEDIA_CPU>;
+ clocks = < CLKID_AO_MEDIA_CPU>;
+};
+
{
reset: reset-controller@4404 {
compatible = "amlogic,meson8b-reset";
@@ -496,6 +504,12 @@ mux {
};
_sram {
+ ao_arc_sram: ao-arc-sram@0 {
+ compatible = "amlogic,meson8-ao-arc-sram";
+ reg = <0x0 0x8000>;
+ pool;
+ };
+
smp-sram@1ff80 {
compatible = "amlogic,meson8-smp-sram";
reg = <0x1ff80 0x8>;
@@ -631,6 +645,13 @@ {
clock-names = "clkin0", "clkin1", "clkin2", "clkin3", "pclk";
};
+ {
+ secbus2: system-controller@4000 {
+ compatible = "amlogic,meson8-secbus2", "syscon";
+ reg = <0x4000 0x2000>;
+ };
+};
+
{
compatible = "amlogic,meson8-sdio", "amlogic,meson-mx-sdio";
clocks = < CLKID_SDIO>, < CLKID_CLK81>;
diff --git a/arch/arm/boot/dts/meson8b.dtsi b/arch/arm/boot/dts/meson8b.dtsi
index dbf7963b6c87..c02b03cbcdf4 100644
--- a/arch/arm/boot/dts/meson8b.dtsi
+++ b/arch/arm/boot/dts/meson8b.dtsi
@@ -320,6 +320,14 @@ mux {
};
};
+_arc_rproc {
+ compatible= "amlogic,meson8b-ao-arc", "amlogic,meson-mx-ao-arc";
+ amlogic,secbus2 = <>;
+ sram = <_arc_sram>;
+ resets = < RESET_MEDIA_CPU>;
+ clocks = < CLKID_AO_MEDIA_CPU>;
+};
+
{
reset: reset-controller@4404 {
compatible = "amlogic,meson8b-reset";
@@ -464,6 +472,12 @@ mux {
};
_sram {
+ ao_arc_sram: ao-arc-sram@0 {
+ compatible = "amlogic,meson8b-ao-arc-sram";
+ reg = <0x0 0x8000>;
+ pool;
+ };
+
smp-sram@1ff80 {
compatible = "amlogic,meson8b-smp-sram";
reg = <0x1ff80 0x8>;
@@ -628,6 +642,13 @@ {
clock-names = "clkin0", "clkin1", "clkin2", "clkin3", "pclk";
};
+ {
+ secbus2: system-controller@4000 {
+ compatible = "amlogic,meson8b-secbus2", "syscon";
+ reg = <0x4000 0x2000>;
+ };
+};
+
{
compatible = "amlogic,meson8b-sdio", "amlogic,meson-mx-sdio";
clocks = < CLKID_SDIO>, < CLKID_CLK81>;
--
2.30.0
[PATCH v2 2/5] dt-bindings: Amlogic: add the documentation for the SECBUS2 registers
The Meson8/Meson8b/Meson8m2 SoCs have a register bank called SECBUS2 which
contains registers for various IP blocks such as pin-controller bits for
the BSD_EN and TEST_N GPIOs as well as some AO ARC core control bits.
The registers can be accessed directly when not running in "secure mode".
When "secure mode" is enabled then these registers have to be accessed
through secure monitor calls.
So far these SoCs are always known to boot in "non-secure mode".
Add a binding documentation using syscon (as these registers are shared
across different IPs) for the SECBUS2 registers.
Signed-off-by: Martin Blumenstingl
---
.../arm/amlogic/amlogic,meson-mx-secbus2.yaml | 42 +++
1 file changed, 42 insertions(+)
create mode 100644
Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-mx-secbus2.yaml
diff --git
a/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-mx-secbus2.yaml
b/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-mx-secbus2.yaml
new file mode 100644
index ..eee7cda9f91b
--- /dev/null
+++
b/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-mx-secbus2.yaml
@@ -0,0 +1,42 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/arm/amlogic/amlogic,meson-mx-secbus2.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: Amlogic Meson8/Meson8b/Meson8m2 SECBUS2 register interface
+
+maintainers:
+ - Martin Blumenstingl
+
+description: |
+ The Meson8/Meson8b/Meson8m2 SoCs have a register bank called SECBUS2 which
+ contains registers for various IP blocks such as pin-controller bits for
+ the BSD_EN and TEST_N GPIOs as well as some AO ARC core control bits.
+ The registers can be accessed directly when not running in "secure mode".
+ When "secure mode" is enabled then these registers have to be accessed
+ through secure monitor calls.
+
+properties:
+ compatible:
+items:
+ - enum:
+ - amlogic,meson8-secbus2
+ - amlogic,meson8b-secbus2
+ - const: syscon
+
+ reg:
+maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+secbus2: system-controller@4000 {
+ compatible = "amlogic,meson8-secbus2", "syscon";
+ reg = <0x4000 0x2000>;
+};
--
2.30.0
[PATCH v2 1/5] dt-bindings: sram: Add compatible strings for the Meson AO ARC SRAM
Amlogic Meson8, Meson8b and Meson8m2 SoCs embed an ARC EM4 core typically used for managing system suspend. A section of the SoCs SRAM is mapped as memory for this ARC core. Add new compatible strings for the SRAM section for the ARC core memory. Signed-off-by: Martin Blumenstingl --- Documentation/devicetree/bindings/sram/sram.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/sram/sram.yaml b/Documentation/devicetree/bindings/sram/sram.yaml index 19d116ff9ddc..6d65771e979c 100644 --- a/Documentation/devicetree/bindings/sram/sram.yaml +++ b/Documentation/devicetree/bindings/sram/sram.yaml @@ -72,6 +72,8 @@ patternProperties: - allwinner,sun4i-a10-sram-d - allwinner,sun9i-a80-smp-sram - allwinner,sun50i-a64-sram-c +- amlogic,meson8-ao-arc-sram +- amlogic,meson8b-ao-arc-sram - amlogic,meson8-smp-sram - amlogic,meson8b-smp-sram - amlogic,meson-gxbb-scp-shmem -- 2.30.0
[PATCH v2 4/5] remoteproc: meson-mx-ao-arc: Add a driver for the AO ARC remote procesor
Amlogic Meson6, Meson8, Meson8b and Meson8m2 embed an ARC core in the
Always-On (AO) power-domain. This is typically used for waking up the
ARM cores after system suspend.
The configuration is spread across three different registers:
- AO_REMAP_REG0 which must be programmed to zero, it's actual purpose
is unknown. There is a second remap register which is not used in the
vendor kernel (which served as reference for this driver).
- AO_CPU_CNTL is used to start and stop the ARC core.
- AO_SECURE_REG0 in the SECBUS2 register area with unknown purpose.
To boot the ARC core we also need to enable it's gate clock and trigger
a reset.
The actual code for this ARC core can come from an ELF binary, for
example by building the Zephyr RTOS for an ARC EM4 core and then taking
"zephyr.elf" as firmware. This executable does not have any "rsc table"
so we are skipping rproc_elf_load_rsc_table (rproc_ops.parse_fw) and
rproc_elf_find_loaded_rsc_table (rproc_ops.find_loaded_rsc_table).
Signed-off-by: Martin Blumenstingl
---
drivers/remoteproc/Kconfig | 11 ++
drivers/remoteproc/Makefile | 1 +
drivers/remoteproc/meson_mx_ao_arc.c | 240 +++
3 files changed, 252 insertions(+)
create mode 100644 drivers/remoteproc/meson_mx_ao_arc.c
diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 9e7efe542f69..0e7fb91635fe 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -125,6 +125,17 @@ config KEYSTONE_REMOTEPROC
It's safe to say N here if you're not interested in the Keystone
DSPs or just want to use a bare minimum kernel.
+config MESON_MX_AO_ARC_REMOTEPROC
+ tristate "Amlogic Meson6/8/8b/8m2 AO ARC remote processor support"
+ depends on HAS_IOMEM
+ depends on (ARM && ARCH_MESON) || COMPILE_TEST
+ select GENERIC_ALLOCATOR
+ help
+ Say m or y here to have support for the AO ARC remote processor
+ on Amlogic Meson6/Meson8/Meson8b/Meson8m2 SoCs. This is
+ typically used for system suspend.
+ If unusre say N.
+
config PRU_REMOTEPROC
tristate "TI PRU remoteproc support"
depends on TI_PRUSS
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index bb26c9e4ef9c..ce1abeb30907 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -18,6 +18,7 @@ obj-$(CONFIG_OMAP_REMOTEPROC) += omap_remoteproc.o
obj-$(CONFIG_WKUP_M3_RPROC)+= wkup_m3_rproc.o
obj-$(CONFIG_DA8XX_REMOTEPROC) += da8xx_remoteproc.o
obj-$(CONFIG_KEYSTONE_REMOTEPROC) += keystone_remoteproc.o
+obj-$(CONFIG_MESON_MX_AO_ARC_REMOTEPROC)+= meson_mx_ao_arc.o
obj-$(CONFIG_PRU_REMOTEPROC) += pru_rproc.o
obj-$(CONFIG_QCOM_PIL_INFO)+= qcom_pil_info.o
obj-$(CONFIG_QCOM_RPROC_COMMON)+= qcom_common.o
diff --git a/drivers/remoteproc/meson_mx_ao_arc.c
b/drivers/remoteproc/meson_mx_ao_arc.c
new file mode 100644
index ..1deb03ca30f4
--- /dev/null
+++ b/drivers/remoteproc/meson_mx_ao_arc.c
@@ -0,0 +1,240 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (C) 2020 Martin Blumenstingl
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "remoteproc_internal.h"
+
+#define AO_REMAP_REG0 0x0
+#define AO_REMAP_REG1 0x4
+
+#define AO_CPU_CNTL0x0
+ #define AO_CPU_CNTL_MEM_ADDR_UPPER GENMASK(28, 16)
+ #define AO_CPU_CNTL_HALTBIT(9)
+ #define AO_CPU_CNTL_UNKNONWNBIT(8)
+ #define AO_CPU_CNTL_RUN BIT(0)
+
+#define AO_CPU_STAT0x4
+
+#define AO_SECURE_REG0 0x0
+ #define AO_SECURE_REG0_UNKNOWN GENMASK(23, 8)
+
+#define MESON_AO_RPROC_SRAM_USABLE_BITSGENMASK(31, 20)
+#define MESON_AO_RPROC_MEMORY_OFFSET 0x1000
+
+struct meson_mx_ao_arc_rproc_priv {
+ void __iomem*remap_base;
+ void __iomem*cpu_base;
+ unsigned long sram_va;
+ phys_addr_t sram_pa;
+ size_t sram_size;
+ struct gen_pool *sram_pool;
+ struct reset_control*arc_reset;
+ struct clk *arc_pclk;
+ struct regmap *secbus2_regmap;
+};
+
+static int meson_mx_ao_arc_rproc_start(struct rproc *rproc)
+{
+ struct meson_mx_ao_arc_rproc_priv *priv = rproc->priv;
+ phys_addr_t phys_addr;
+ int ret;
+
+ ret = clk_prepare_enable(priv->arc_pclk);
+ if (ret)
+ return ret;
+
+ writel(0,
Re: [PATCH v2 2/2] arm64: dts: meson: add initial Beelink GS-King-X device-tree
On Wed, Dec 30, 2020 at 11:38 AM Christian Hewitt wrote: > > The Shenzen AZW (Beelink) GS-King-X is based on the Amlogic W400 reference > board with an S922X-H chip. > > - 4GB LPDDR4 RAM > - 64GB eMMC storage > - 10/100/1000 Base-T Ethernet > - AP6356S Wireless (802.11 a/b/g/n/ac, BT 4.1) > - HDMI 2.1 video > - S/PDIF optical output are you planning to enable this also? > - 2x ESS9018 audio DACs > - 4x Ricor RT6862 audio amps > - Analogue headphone output there's no driver for that DAC so I think that's why you are not enabling them > - 1x USB 2.0 OTG port > - 3x USB 3.0 ports > - IR receiver > - 1x micro SD card slot (internal) > - USB SATA controller with 2x 3.5" drive bays > - 1x Power on/off button > > Signed-off-by: Christian Hewitt I don't know/have this board but also I don't see anything problematic so: Acked-by: Martin Blumenstingl
Re: [PATCH v2 1/2] dt-bindings: arm: amlogic: add support for the Beelink GS-King-X
On Wed, Dec 30, 2020 at 11:38 AM Christian Hewitt wrote: > > The Shenzen AZW (Beelink) GS-King-X is based on the Amlogic W400 reference > board with an S922X-H chip. > > Signed-off-by: Christian Hewitt > Acked-by: Rob Herring Reviewed-by: Martin Blumenstingl
Re: [RFC PATCH 3/3] gpio: ej1x8: Add GPIO driver for Etron Tech Inc. EJ168/EJ188/EJ198
Hi Linus, On Mon, Dec 21, 2020 at 4:28 PM Martin Blumenstingl wrote: > > Hi Linus, > > On Wed, Oct 7, 2020 at 9:44 PM Martin Blumenstingl > wrote: > [...] > > > As noted on the earlier patches I think this should be folded into the > > > existing XHCI USB driver in drivers/usb/host/xhci-pci.c or, if that > > > gets messy, as a separate bolt-on, something like > > > xhci-pci-gpio.[c|h] in the drivers/usb/host/* directory. > > > You can use a Kconfig symbol for the GPIO portions or not. > > OK, I will do that if there are no objections from other developers > > I am intending to place the relevant code in xhci-pci-etron.c, similar > > to what we already have with xhci-pci-renesas.c > I tried this and unfortunately there's a catch. > the nice thing about having a separate GPIO driver means that the > xhci-pci driver doesn't need to know about it. > > I implemented xhci-pci-etron.c and gave it a Kconfig option. > xhci-pci is then calling into xhci-pci-etron (through some > etron_xhci_pci_probe function). > unfortunately this means that xhci-pci now depends on xhci-pci-etron. > for xhci-pci-renesas this is fine (I think) because that part of the > code is needed to get the xHCI controller going > but for xhci-pci-etron this is a different story: the GPIO controller > is entirely optional and only used on few devices > > my goal is (at some point in the future) to have the GPIO driver in OpenWrt. > I am not sure if they would accept a patch where xhci-pci would then > pull in the dependencies for that Etron controller, even though most > boards don't need it. > > Please let me know if you have any idea on how to solve this. next week I have some free time to work on this I am still interested in any ideas that you have about this Best regards, Martin
discussion: re-structuring of the Amlogic Meson VPU DRM driver
Hi Neil and all interested people, in the past there were concerns about how some of the components are coupled in our Meson DRM driver(s). With this discussion I would like to achieve four things: 1. understand the current issues that we have 2. come up with a TODO list of things that need to be tackled as well as recommendations how to solve it (for example: "driver ABC function ABC uses the recommended way - take that as reference") 3. one by one work on the items on the TODO list 4. add support for the 32-bit SoCs to the Meson VPU DRM driver (without adding more "not recommended" code) Disclaimer: I am not familiar with the DRM subsystem - so apologies if the terminology is not correct. drivers/gpu/drm/meson/meson_dw_hdmi.c currently serves four purposes: 1. manage the TOP (glue) registers for the dw-hdmi IP This is Amlogic specific and consists of things like HPD filtering, some internal resets, etc. In my opinion this part is supposed to stay in this driver 2. load the driver for the dw-hdmi IP by calling dw_hdmi_probe() I read somewhere that this is not recommended anymore and should be replaced. Is my understanding correct and what is the recommended replacement? 3. it manages the HDMI PHY registers in the HHI register area For the 32-bit SoCs I will not follow this pattern and will create a separate PHY instead. As a long-term goal I think we should also move this into a dedicated PHY driver. 4. call back into VPU/VENC functions to set up these registers This is a blocker for 32-bit SoC support as I would have to duplicate this code if we don't make any changes. This includes things like calculating (and setting) clock frequencies, calling meson_venc_hdmi_mode_set for setting up the DVI pixel encoder, etc. My understanding is that this part should not be part of the meson_dw_hdmi driver, but "some other" driver. I don't understand which driver that's supposed to be though and how things would be wired up in the end. In addition to HDMI my understanding is that for adding MIPI DSI support you would a) either have to follow the pattern from the meson_dw_hdmi driver or b) also require some better way to achieve this The biggest question marks for me are #2 and #4 from the list above. Also is there anything I have missed? Any input, feedback and questions are welcome! PS: an additional topic on the TODO list will be "use the common clock framework" for clock setup. it's currently not clear to me if that's possible on the 64-bit SoCs in all cases. I will start a separate discussion for that topic after this one. Best regards, Martin
[PATCH 5/5] ARM: dts: meson: add the AO ARC remote processor
The 32-bit Amlogic Meson SoCs embed an ARC processor in the Always-On
power domain which is typically used for managing system suspend. The
memory for this ARC core is taken from the AHB SRAM area. Depending on
the actual SoC a different ARC core is used:
- Meson6 and earlier: some ARCv1 ISA based core (probably an ARC625)
- Meson8 and later: an ARC EM4 (ARCv2 ISA) based core
Add the device-tree node for this remote-processor along with the
required SRAM sections, clocks and reset-lines. Also use the
SoC-specific compatible string to manage any differences (should
they exist).
On Meson8, Meson8b and Meson8m2 the "secbus2" IO region is needed as
some bits need to be programmed there. Add this IO region for those
SoCs as well.
Signed-off-by: Martin Blumenstingl
---
arch/arm/boot/dts/meson.dtsi | 7 +++
arch/arm/boot/dts/meson8.dtsi | 21 +
arch/arm/boot/dts/meson8b.dtsi | 21 +
3 files changed, 49 insertions(+)
diff --git a/arch/arm/boot/dts/meson.dtsi b/arch/arm/boot/dts/meson.dtsi
index e0ca5f08d07d..8bae6ed0abb2 100644
--- a/arch/arm/boot/dts/meson.dtsi
+++ b/arch/arm/boot/dts/meson.dtsi
@@ -200,6 +200,13 @@ aobus: aobus@c810 {
#size-cells = <1>;
ranges = <0x0 0xc810 0x10>;
+ ao_arc_rproc: remoteproc@1c {
+ compatible= "amlogic,meson-mx-ao-arc";
+ reg = <0x1c 0x8>, <0x38 0x8>;
+ reg-names = "remap", "cpu";
+ status = "disabled";
+ };
+
ir_receiver: ir-receiver@480 {
compatible= "amlogic,meson6-ir";
reg = <0x480 0x20>;
diff --git a/arch/arm/boot/dts/meson8.dtsi b/arch/arm/boot/dts/meson8.dtsi
index 420324ea2ad7..157a950a55d3 100644
--- a/arch/arm/boot/dts/meson8.dtsi
+++ b/arch/arm/boot/dts/meson8.dtsi
@@ -369,6 +369,14 @@ mux {
};
};
+_arc_rproc {
+ compatible= "amlogic,meson8-ao-arc", "amlogic,meson-mx-ao-arc";
+ amlogic,secbus2 = <>;
+ sram = <_arc_sram>;
+ resets = < RESET_MEDIA_CPU>;
+ clocks = < CLKID_AO_MEDIA_CPU>;
+};
+
{
reset: reset-controller@4404 {
compatible = "amlogic,meson8b-reset";
@@ -496,6 +504,12 @@ mux {
};
_sram {
+ ao_arc_sram: ao-arc-sram@0 {
+ compatible = "amlogic,meson8-ao-arc-sram";
+ reg = <0x0 0x8000>;
+ pool;
+ };
+
smp-sram@1ff80 {
compatible = "amlogic,meson8-smp-sram";
reg = <0x1ff80 0x8>;
@@ -631,6 +645,13 @@ {
clock-names = "clkin0", "clkin1", "clkin2", "clkin3", "pclk";
};
+ {
+ secbus2: system-controller@4000 {
+ compatible = "amlogic,meson8-secbus2", "syscon";
+ reg = <0x4000 0x2000>;
+ };
+};
+
{
compatible = "amlogic,meson8-sdio", "amlogic,meson-mx-sdio";
clocks = < CLKID_SDIO>, < CLKID_CLK81>;
diff --git a/arch/arm/boot/dts/meson8b.dtsi b/arch/arm/boot/dts/meson8b.dtsi
index dbf7963b6c87..c02b03cbcdf4 100644
--- a/arch/arm/boot/dts/meson8b.dtsi
+++ b/arch/arm/boot/dts/meson8b.dtsi
@@ -320,6 +320,14 @@ mux {
};
};
+_arc_rproc {
+ compatible= "amlogic,meson8b-ao-arc", "amlogic,meson-mx-ao-arc";
+ amlogic,secbus2 = <>;
+ sram = <_arc_sram>;
+ resets = < RESET_MEDIA_CPU>;
+ clocks = < CLKID_AO_MEDIA_CPU>;
+};
+
{
reset: reset-controller@4404 {
compatible = "amlogic,meson8b-reset";
@@ -464,6 +472,12 @@ mux {
};
_sram {
+ ao_arc_sram: ao-arc-sram@0 {
+ compatible = "amlogic,meson8b-ao-arc-sram";
+ reg = <0x0 0x8000>;
+ pool;
+ };
+
smp-sram@1ff80 {
compatible = "amlogic,meson8b-smp-sram";
reg = <0x1ff80 0x8>;
@@ -628,6 +642,13 @@ {
clock-names = "clkin0", "clkin1", "clkin2", "clkin3", "pclk";
};
+ {
+ secbus2: system-controller@4000 {
+ compatible = "amlogic,meson8b-secbus2", "syscon";
+ reg = <0x4000 0x2000>;
+ };
+};
+
{
compatible = "amlogic,meson8b-sdio", "amlogic,meson-mx-sdio";
clocks = < CLKID_SDIO>, < CLKID_CLK81>;
--
2.30.0
[PATCH 0/5] Amlogic Meson Always-On ARC remote-processor support
Amlogic Meson6/8/8b/8m2 come with an ARC core in the Always-On (AO) power-domain. This is typically used for waking up the ARM CPU after powering it down for system suspend. The exact ARC core used on Meson6 and earlier is not known. I believe it is an ARC625, but I am not sure about this. Meson8/8b/8m2 uses an ARC EM4 core. They all have in common that they use a section of the SoCs SRAM for running code on the ARC core. Unfortunately there's no information about the remote-processor control registers in the public Meson8b (S805) datasheet. All information is either taken from Amlogic's 3.10 kernel and 2011-03 u-boot or found by testing (for example the clock input is not mentioned anywhere in the reference code, but disabling it stops the AO ARC core from working). This series consists of five patches: 1: dt-bindings for the SRAM section 2: dt-bindings for the SECBUS2 syscon region which contains a few bits for controlling this remote processor 3: dt-bindings for the AO ARC remote processor 4: the driver for booting code on the AO ARC remote processor 5: (only included for documentation purposes) dts changes (these will be re-sent separately) Patches #3 and #4 should go through the remoteproc tree. Patches #1 and #2 may go through Rob's (devicetree) tree, Kevin's linux-amlogic tree or through the remoteproc tree. Personally I have no preference here. To test this series I ported the Amlogic serial driver and added the board files for the Amlogic AO ARC EM4 to the Zephyr RTOS. The code can be found here: [0] (the resulting zephyr.elf can then be loaded as remote-processor firmware from Linux). [0] https://github.com/xdarklight/zephyr-rtos/commits/amlogic_ao_em4-20201229 Martin Blumenstingl (5): dt-bindings: sram: Add compatible strings for the Meson AO ARC SRAM dt-bindings: Amlogic: add the documentation for the SECBUS2 registers dt-bindings: remoteproc: Add the documentation for Meson AO ARC rproc remoteproc: meson-mx-ao-arc: Add a driver for the AO ARC remote procesor ARM: dts: meson: add the AO ARC remote processor .../arm/amlogic/amlogic,meson-mx-secbus2.yaml | 53 .../remoteproc/amlogic,meson-mx-ao-arc.yaml | 87 +++ .../devicetree/bindings/sram/sram.yaml| 2 + arch/arm/boot/dts/meson.dtsi | 7 + arch/arm/boot/dts/meson8.dtsi | 21 ++ arch/arm/boot/dts/meson8b.dtsi| 21 ++ drivers/remoteproc/Kconfig| 11 + drivers/remoteproc/Makefile | 1 + drivers/remoteproc/meson_mx_ao_arc.c | 240 ++ 9 files changed, 443 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-mx-secbus2.yaml create mode 100644 Documentation/devicetree/bindings/remoteproc/amlogic,meson-mx-ao-arc.yaml create mode 100644 drivers/remoteproc/meson_mx_ao_arc.c -- 2.30.0
[PATCH 2/5] dt-bindings: Amlogic: add the documentation for the SECBUS2 registers
The Meson8/Meson8b/Meson8m2 SoCs have a register bank called SECBUS2 which
contains registers for various IP blocks such as pin-controller bits for
the BSD_EN and TEST_N GPIOs as well as some AO ARC core control bits.
The registers can be accessed directly when not running in "secure mode".
When "secure mode" is enabled then these registers have to be accessed
through secure monitor calls.
So far these SoCs are always known to boot in "non-secure mode".
Add a binding documentation using syscon (as these registers are shared
across different IPs) for the SECBUS2 registers.
Signed-off-by: Martin Blumenstingl
---
.../arm/amlogic/amlogic,meson-mx-secbus2.yaml | 53 +++
1 file changed, 53 insertions(+)
create mode 100644
Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-mx-secbus2.yaml
diff --git
a/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-mx-secbus2.yaml
b/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-mx-secbus2.yaml
new file mode 100644
index ..cfa8e9de6c28
--- /dev/null
+++
b/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-mx-secbus2.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/arm/amlogic/amlogic,meson-mx-secbus2.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: Amlogic Meson8/Meson8b/Meson8m2 SECBUS2 register interface
+
+maintainers:
+ - Martin Blumenstingl
+
+description: |
+ The Meson8/Meson8b/Meson8m2 SoCs have a register bank called SECBUS2 which
+ contains registers for various IP blocks such as pin-controller bits for
+ the BSD_EN and TEST_N GPIOs as well as some AO ARC core control bits.
+ The registers can be accessed directly when not running in "secure mode".
+ When "secure mode" is enabled then these registers have to be accessed
+ through secure monitor calls.
+
+# We need a select here so we don't match all nodes with 'syscon'
+select:
+ properties:
+compatible:
+ contains:
+enum:
+ - amlogic,meson8-secbus2
+ - amlogic,meson8b-secbus2
+ required:
+- compatible
+
+properties:
+ compatible:
+items:
+ - enum:
+- amlogic,meson8-secbus2
+- amlogic,meson8b-secbus2
+ - const: syscon
+
+ reg:
+maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+secbus2: system-controller@4000 {
+ compatible = "amlogic,meson8-secbus2", "syscon";
+ reg = <0x4000 0x2000>;
+};
--
2.30.0
[PATCH 1/5] dt-bindings: sram: Add compatible strings for the Meson AO ARC SRAM
Amlogic Meson8, Meson8b and Meson8m2 SoCs embed an ARC EM4 core typically used for managing system suspend. A section of the SoCs SRAM is mapped as memory for this ARC core. Add new compatible strings for the SRAM section for the ARC core memory. Signed-off-by: Martin Blumenstingl --- Documentation/devicetree/bindings/sram/sram.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/sram/sram.yaml b/Documentation/devicetree/bindings/sram/sram.yaml index 19d116ff9ddc..6d65771e979c 100644 --- a/Documentation/devicetree/bindings/sram/sram.yaml +++ b/Documentation/devicetree/bindings/sram/sram.yaml @@ -72,6 +72,8 @@ patternProperties: - allwinner,sun4i-a10-sram-d - allwinner,sun9i-a80-smp-sram - allwinner,sun50i-a64-sram-c +- amlogic,meson8-ao-arc-sram +- amlogic,meson8b-ao-arc-sram - amlogic,meson8-smp-sram - amlogic,meson8b-smp-sram - amlogic,meson-gxbb-scp-shmem -- 2.30.0
[PATCH 4/5] remoteproc: meson-mx-ao-arc: Add a driver for the AO ARC remote procesor
Amlogic Meson6, Meson8, Meson8b and Meson8m2 embed an ARC core in the
Always-On (AO) power-domain. This is typically used for waking up the
ARM cores after system suspend.
The configuration is spread across three different registers:
- AO_REMAP_REG0 which must be programmed to zero, it's actual purpose
is unknown. There is a second remap register which is not used in the
vendor kernel (which served as reference for this driver).
- AO_CPU_CNTL is used to start and stop the ARC core.
- AO_SECURE_REG0 in the SECBUS2 register area with unknown purpose.
To boot the ARC core we also need to enable it's gate clock and trigger
a reset.
The actual code for this ARC core can come from an ELF binary, for
example by building the Zephyr RTOS for an ARC EM4 core and then taking
"zephyr.elf" as firmware. This executable does not have any "rsc table"
so we are skipping rproc_elf_load_rsc_table (rproc_ops.parse_fw) and
rproc_elf_find_loaded_rsc_table (rproc_ops.find_loaded_rsc_table).
Signed-off-by: Martin Blumenstingl
---
drivers/remoteproc/Kconfig | 11 ++
drivers/remoteproc/Makefile | 1 +
drivers/remoteproc/meson_mx_ao_arc.c | 240 +++
3 files changed, 252 insertions(+)
create mode 100644 drivers/remoteproc/meson_mx_ao_arc.c
diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 9e7efe542f69..0e7fb91635fe 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -125,6 +125,17 @@ config KEYSTONE_REMOTEPROC
It's safe to say N here if you're not interested in the Keystone
DSPs or just want to use a bare minimum kernel.
+config MESON_MX_AO_ARC_REMOTEPROC
+ tristate "Amlogic Meson6/8/8b/8m2 AO ARC remote processor support"
+ depends on HAS_IOMEM
+ depends on (ARM && ARCH_MESON) || COMPILE_TEST
+ select GENERIC_ALLOCATOR
+ help
+ Say m or y here to have support for the AO ARC remote processor
+ on Amlogic Meson6/Meson8/Meson8b/Meson8m2 SoCs. This is
+ typically used for system suspend.
+ If unusre say N.
+
config PRU_REMOTEPROC
tristate "TI PRU remoteproc support"
depends on TI_PRUSS
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index bb26c9e4ef9c..ce1abeb30907 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -18,6 +18,7 @@ obj-$(CONFIG_OMAP_REMOTEPROC) += omap_remoteproc.o
obj-$(CONFIG_WKUP_M3_RPROC)+= wkup_m3_rproc.o
obj-$(CONFIG_DA8XX_REMOTEPROC) += da8xx_remoteproc.o
obj-$(CONFIG_KEYSTONE_REMOTEPROC) += keystone_remoteproc.o
+obj-$(CONFIG_MESON_MX_AO_ARC_REMOTEPROC)+= meson_mx_ao_arc.o
obj-$(CONFIG_PRU_REMOTEPROC) += pru_rproc.o
obj-$(CONFIG_QCOM_PIL_INFO)+= qcom_pil_info.o
obj-$(CONFIG_QCOM_RPROC_COMMON)+= qcom_common.o
diff --git a/drivers/remoteproc/meson_mx_ao_arc.c
b/drivers/remoteproc/meson_mx_ao_arc.c
new file mode 100644
index ..1deb03ca30f4
--- /dev/null
+++ b/drivers/remoteproc/meson_mx_ao_arc.c
@@ -0,0 +1,240 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (C) 2020 Martin Blumenstingl
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "remoteproc_internal.h"
+
+#define AO_REMAP_REG0 0x0
+#define AO_REMAP_REG1 0x4
+
+#define AO_CPU_CNTL0x0
+ #define AO_CPU_CNTL_MEM_ADDR_UPPER GENMASK(28, 16)
+ #define AO_CPU_CNTL_HALTBIT(9)
+ #define AO_CPU_CNTL_UNKNONWNBIT(8)
+ #define AO_CPU_CNTL_RUN BIT(0)
+
+#define AO_CPU_STAT0x4
+
+#define AO_SECURE_REG0 0x0
+ #define AO_SECURE_REG0_UNKNOWN GENMASK(23, 8)
+
+#define MESON_AO_RPROC_SRAM_USABLE_BITSGENMASK(31, 20)
+#define MESON_AO_RPROC_MEMORY_OFFSET 0x1000
+
+struct meson_mx_ao_arc_rproc_priv {
+ void __iomem*remap_base;
+ void __iomem*cpu_base;
+ unsigned long sram_va;
+ phys_addr_t sram_pa;
+ size_t sram_size;
+ struct gen_pool *sram_pool;
+ struct reset_control*arc_reset;
+ struct clk *arc_pclk;
+ struct regmap *secbus2_regmap;
+};
+
+static int meson_mx_ao_arc_rproc_start(struct rproc *rproc)
+{
+ struct meson_mx_ao_arc_rproc_priv *priv = rproc->priv;
+ phys_addr_t phys_addr;
+ int ret;
+
+ ret = clk_prepare_enable(priv->arc_pclk);
+ if (ret)
+ return ret;
+
+ writel(0,
[PATCH 3/5] dt-bindings: remoteproc: Add the documentation for Meson AO ARC rproc
Amlogic Meson6, Meson8, Meson8b and Meson8m2 SoCs embed an ARC EM4
controller for always-on operations, typically used for managing system
suspend.
Signed-off-by: Martin Blumenstingl
---
.../remoteproc/amlogic,meson-mx-ao-arc.yaml | 87 +++
1 file changed, 87 insertions(+)
create mode 100644
Documentation/devicetree/bindings/remoteproc/amlogic,meson-mx-ao-arc.yaml
diff --git
a/Documentation/devicetree/bindings/remoteproc/amlogic,meson-mx-ao-arc.yaml
b/Documentation/devicetree/bindings/remoteproc/amlogic,meson-mx-ao-arc.yaml
new file mode 100644
index ..ba5deebaf7dc
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/amlogic,meson-mx-ao-arc.yaml
@@ -0,0 +1,87 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/remoteproc/amlogic,meson-mx-ao-arc.yaml#;
+$schema: "http://devicetree.org/meta-schemas/core.yaml#;
+
+title: Amlogic Meson AO ARC Remote Processor bindings
+
+description:
+ Amlogic Meson6, Meson8, Meson8b and Meson8m2 SoCs embed an ARC core
+ controller for always-on operations, typically used for managing
+ system suspend. Meson6 and older use a ARC core based on the ARCv1
+ ISA, while Meson8, Meson8b and Meson8m2 use an ARC EM4 (ARCv2 ISA)
+ core.
+
+maintainers:
+ - Martin Blumenstingl
+
+properties:
+ compatible:
+items:
+ - enum:
+- amlogic,meson8-ao-arc
+- amlogic,meson8b-ao-arc
+ - const: amlogic,meson-mx-ao-arc
+
+ firmware-name:
+$ref: /schemas/types.yaml#/definitions/string
+description:
+ The name of the firmware which should be loaded for this remote
+ processor.
+
+ reg:
+description:
+ Address ranges of the remap and CPU control addresses for the
+ remote processor.
+minItems: 2
+
+ reg-names:
+items:
+ - const: remap
+ - const: cpu
+
+ resets:
+ minItems: 1
+
+ clocks:
+minItems: 1
+
+ sram:
+$ref: /schemas/types.yaml#/definitions/phandle
+description:
+ phandles to a reserved SRAM region which is used as the memory of
+ the ARC core. The region should be defined as child nodes of the
+ AHB SRAM node as per the generic bindings in
+ Documentation/devicetree/bindings/sram/sram.yaml
+
+ amlogic,secbus2:
+$ref: /schemas/types.yaml#/definitions/phandle
+description:
+ A phandle to the SECBUS2 region which contains some configuration
+ bits of this remote processor
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - resets
+ - clocks
+ - sram
+ - amlogic,secbus2
+
+additionalProperties: false
+
+examples:
+ - |
+remoteproc@1c {
+ compatible= "amlogic,meson8-ao-arc", "amlogic,meson-mx-ao-arc";
+ reg = <0x1c 0x8>, <0x38 0x8>;
+ reg-names = "remap", "cpu";
+ resets = <_cpu_reset>;
+ clocks = <_cpu_clock>;
+ sram = <_sram_ao_arc>;
+ amlogic,secbus2 = <>;
+};
+
+...
--
2.30.0
Re: [PATCH v3 0/5] dwmac-meson8b: picosecond precision RX delay support
Hi Jakub, On Mon, Dec 28, 2020 at 9:37 PM Jakub Kicinski wrote: > > On Thu, 24 Dec 2020 00:29:00 +0100 Martin Blumenstingl wrote: > > Hello, > > > > with the help of Jianxin Pan (many thanks!) the meaning of the "new" > > PRG_ETH1[19:16] register bits on Amlogic Meson G12A, G12B and SM1 SoCs > > are finally known. These SoCs allow fine-tuning the RGMII RX delay in > > 200ps steps (contrary to what I have thought in the past [0] these are > > not some "calibration" values). > > Could you repost in a few days? Net-next is still closed: sure I also received a Reviewed-by from Florian on patch #1 so I'll also include that Best regards, Martin
[PATCH 3/3] clk: meson: clk-pll: propagate the error from meson_clk_pll_set_rate()
Popagate the error code from meson_clk_pll_set_rate() when the PLL does
not lock with the new settings.
Fixes: 722825dcd54b2e ("clk: meson: migrate plls clocks to clk_regmap")
Signed-off-by: Martin Blumenstingl
---
drivers/clk/meson/clk-pll.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/meson/clk-pll.c b/drivers/clk/meson/clk-pll.c
index 5b932976483f..49f27fe53213 100644
--- a/drivers/clk/meson/clk-pll.c
+++ b/drivers/clk/meson/clk-pll.c
@@ -394,7 +394,8 @@ static int meson_clk_pll_set_rate(struct clk_hw *hw,
unsigned long rate,
if (!enabled)
return 0;
- if (meson_clk_pll_enable(hw)) {
+ ret = meson_clk_pll_enable(hw);
+ if (ret) {
pr_warn("%s: pll did not lock, trying to restore old rate
%lu\n",
__func__, old_rate);
/*
@@ -406,7 +407,7 @@ static int meson_clk_pll_set_rate(struct clk_hw *hw,
unsigned long rate,
meson_clk_pll_set_rate(hw, old_rate, parent_rate);
}
- return 0;
+ return ret;
}
/*
--
2.29.2
[PATCH 1/3] clk: meson: clk-pll: fix initializing the old rate (fallback) for a PLL
The "rate" parameter in meson_clk_pll_set_rate() contains the new rate.
Retrieve the old rate with clk_hw_get_rate() so we don't inifinitely try
to switch from the new rate to the same ratte again.
Fixes: 7a29a869434e8b ("clk: meson: Add support for Meson clock controller")
Signed-off-by: Martin Blumenstingl
---
drivers/clk/meson/clk-pll.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/meson/clk-pll.c b/drivers/clk/meson/clk-pll.c
index b17a13e9337c..9404609b5ebf 100644
--- a/drivers/clk/meson/clk-pll.c
+++ b/drivers/clk/meson/clk-pll.c
@@ -371,7 +371,7 @@ static int meson_clk_pll_set_rate(struct clk_hw *hw,
unsigned long rate,
if (parent_rate == 0 || rate == 0)
return -EINVAL;
- old_rate = rate;
+ old_rate = clk_hw_get_rate(hw);
ret = meson_clk_get_pll_settings(rate, parent_rate, , , pll);
if (ret)
--
2.29.2
[PATCH 2/3] clk: meson: clk-pll: make "ret" a signed integer
The error codes returned by meson_clk_get_pll_settings() are all
negative. Make "ret" a signed integer in meson_clk_pll_set_rate() to
make it match with the clk_ops.set_rate API as well as the data type
returned by meson_clk_get_pll_settings().
Fixes: 8eed1db1adec6a ("clk: meson: pll: update driver for the g12a")
Signed-off-by: Martin Blumenstingl
---
drivers/clk/meson/clk-pll.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/meson/clk-pll.c b/drivers/clk/meson/clk-pll.c
index 9404609b5ebf..5b932976483f 100644
--- a/drivers/clk/meson/clk-pll.c
+++ b/drivers/clk/meson/clk-pll.c
@@ -365,8 +365,9 @@ static int meson_clk_pll_set_rate(struct clk_hw *hw,
unsigned long rate,
{
struct clk_regmap *clk = to_clk_regmap(hw);
struct meson_clk_pll_data *pll = meson_clk_pll_data(clk);
- unsigned int enabled, m, n, frac = 0, ret;
+ unsigned int enabled, m, n, frac = 0;
unsigned long old_rate;
+ int ret;
if (parent_rate == 0 || rate == 0)
return -EINVAL;
--
2.29.2
[PATCH 0/3] clk: meson: three small clk-pll fixes
Hi Jerome, while working on some changes for the 32-bit SoCs I hit a corner-case in the HDMI PLL: there's some rate doubling going. The PLL only locks in a specific rate range but the M/N table is not aware of that. This means for now (I am planning to fix that) that we can end up in a ituation where the PLL doesn't lock and meson_clk_pll_set_rate() is supposed to still behave in this case. So here's three small patches for that. For me it's fine to queue these patches for -next. I am not aware of any breakage upstream, only some of my pending patches prefer to have these fixes. Slightly unrelated: if you know anything about that clock doubling then please let me know! Best regards, Martin Martin Blumenstingl (3): clk: meson: clk-pll: fix initializing the old rate (fallback) for a PLL clk: meson: clk-pll: make "ret" a signed integer clk: meson: clk-pll: propagate the error from meson_clk_pll_set_rate() drivers/clk/meson/clk-pll.c | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) -- 2.29.2
[PATCH v3 4/5] net: stmmac: dwmac-meson8b: move RGMII delays into a separate function
Newer SoCs starting with the Amlogic Meson G12A have more a precise
RGMII RX delay configuration register. This means more complexity in the
code. Extract the existing RGMII delay configuration code into a
separate function to make it easier to read/understand even when adding
more logic in the future.
Reviewed-by: Andrew Lunn
Reviewed-by: Florian Fainelli
Signed-off-by: Martin Blumenstingl
---
drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
index d2be3a7bd8fd..4937432ac70d 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
@@ -268,7 +268,7 @@ static int meson8b_devm_clk_prepare_enable(struct
meson8b_dwmac *dwmac,
return 0;
}
-static int meson8b_init_prg_eth(struct meson8b_dwmac *dwmac)
+static int meson8b_init_rgmii_delays(struct meson8b_dwmac *dwmac)
{
u32 tx_dly_config, rx_dly_config, delay_config;
int ret;
@@ -323,6 +323,13 @@ static int meson8b_init_prg_eth(struct meson8b_dwmac
*dwmac)
PRG_ETH0_ADJ_DELAY | PRG_ETH0_ADJ_SKEW,
delay_config);
+ return 0;
+}
+
+static int meson8b_init_prg_eth(struct meson8b_dwmac *dwmac)
+{
+ int ret;
+
if (phy_interface_mode_is_rgmii(dwmac->phy_mode)) {
/* only relevant for RMII mode -> disable in RGMII mode */
meson8b_dwmac_mask_bits(dwmac, PRG_ETH0,
@@ -430,6 +437,10 @@ static int meson8b_dwmac_probe(struct platform_device
*pdev)
goto err_remove_config_dt;
}
+ ret = meson8b_init_rgmii_delays(dwmac);
+ if (ret)
+ goto err_remove_config_dt;
+
ret = meson8b_init_rgmii_tx_clk(dwmac);
if (ret)
goto err_remove_config_dt;
--
2.29.2
[PATCH v3 0/5] dwmac-meson8b: picosecond precision RX delay support
Hello,
with the help of Jianxin Pan (many thanks!) the meaning of the "new"
PRG_ETH1[19:16] register bits on Amlogic Meson G12A, G12B and SM1 SoCs
are finally known. These SoCs allow fine-tuning the RGMII RX delay in
200ps steps (contrary to what I have thought in the past [0] these are
not some "calibration" values).
The vendor u-boot has code to automatically detect the best RX/TX delay
settings. For now we keep it simple and add a device-tree property with
200ps precision to select the "right" RX delay for each board.
While here, deprecate the "amlogic,rx-delay-ns" property as it's not
used on any upstream .dts (yet). The driver is backwards compatible.
I have tested this on an X96 Air 4GB board (not upstream yet). Testing
with iperf3 gives 938 Mbits/sec in both directions (RX and TX). The
following network settings were used in the .dts (2ns TX delay
generated by the PHY, 800ps RX delay generated by the MAC as the PHY
only supports 0ns or 2ns RX delays):
_mdio {
external_phy: ethernet-phy@0 {
/* Realtek RTL8211F (0x001cc916) */
reg = <0>;
eee-broken-1000t;
reset-assert-us = <1>;
reset-deassert-us = <3>;
reset-gpios = < GPIOZ_15 (GPIO_ACTIVE_LOW |
GPIO_OPEN_DRAIN)>;
interrupt-parent = <_intc>;
/* MAC_INTR on GPIOZ_14 */
interrupts = <26 IRQ_TYPE_LEVEL_LOW>;
};
};
{
status = "okay";
pinctrl-0 = <_pins>, <_rgmii_pins>;
pinctrl-names = "default";
phy-mode = "rgmii-txid";
phy-handle = <_phy>;
amlogic,rgmii-rx-delay-ps = <800>;
};
To use the same settings from vendor u-boot (which in my case has broken
Ethernet) the following commands can be used:
mw.l 0xff634540 0x1621
mw.l 0xff634544 0x3
phyreg w 0x0 0x1040
phyreg w 0x1f 0xd08
phyreg w 0x11 0x9
phyreg w 0x15 0x11
phyreg w 0x1f 0x0
phyreg w 0x0 0x9200
Also I have tested this on a X96 Max board without any .dts changes
to confirm that other boards with the same IP block still work fine
with these changes.
Changes since v2 at [2]:
- use the generic property name "rx-internal-delay-ps" as suggested by
Rob (thanks!). This affects patches #1 and #3. The biggest change is
is in patch #1 which is why I didn't add Florian's and Andrew's
Reviewed-by
- added Andrew's and Florian's Reviewed-by to patches 2, 3, 4, 5 (many
thanks to both!). I decided to do this despite renaming the property
to the generic name "rx-internal-delay-ps" as it only affects the
patch description and one line of code
- updated patch description of patch #3 to explain why there's not a
lot of validation when parsing the old device-tree property (in
nanosecond precision)
- dropped RFC status
Changes since v1 at [1]:
- updated patch 1 by making it more clear when the RX delay is applied.
Thanks to Andrew for the suggestion!
- added a fix to enabling the timing-adjustment clock only when really
needed. Found by Andrew - thanks!
- added testing not about X96 Max
- v1 did not go to the netdev mailing list, v2 fixes this
[0]
https://lore.kernel.org/netdev/CAFBinCATt4Hi9rigj52nMf3oygyFbnopZcsakGL=kywnsjy...@mail.gmail.com/
[1] https://patchwork.kernel.org/project/linux-amlogic/list/?series=384279
[2]
https://patchwork.kernel.org/project/linux-amlogic/list/?series=384491=%2A=both
Martin Blumenstingl (5):
dt-bindings: net: dwmac-meson: use picoseconds for the RGMII RX delay
net: stmmac: dwmac-meson8b: fix enabling the timing-adjustment clock
net: stmmac: dwmac-meson8b: use picoseconds for the RGMII RX delay
net: stmmac: dwmac-meson8b: move RGMII delays into a separate function
net: stmmac: dwmac-meson8b: add support for the RGMII RX delay on G12A
.../bindings/net/amlogic,meson-dwmac.yaml | 55 +--
.../ethernet/stmicro/stmmac/dwmac-meson8b.c | 91 +++
2 files changed, 120 insertions(+), 26 deletions(-)
--
2.29.2
[PATCH v3 1/5] dt-bindings: net: dwmac-meson: use picoseconds for the RGMII RX delay
Amlogic Meson G12A, G12B and SM1 SoCs have a more advanced RGMII RX delay register which allows picoseconds precision. Deprecate the old "amlogic,rx-delay-ns" in favour of the generic "rx-internal-delay-ps" property. For older SoCs the only known supported values were 0ns and 2ns. The new SoCs have support for RGMII RX delays between 0ps and 3000ps in 200ps steps. Don't carry over the description for the "rx-internal-delay-ps" property and inherit that from ethernet-controller.yaml instead. Signed-off-by: Martin Blumenstingl --- .../bindings/net/amlogic,meson-dwmac.yaml | 55 +-- 1 file changed, 49 insertions(+), 6 deletions(-) diff --git a/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml index 6b057b117aa0..a406e38e1848 100644 --- a/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml +++ b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml @@ -74,17 +74,60 @@ allOf: Any configuration is ignored when the phy-mode is set to "rmii". amlogic,rx-delay-ns: + deprecated: true enum: - 0 - 2 default: 0 description: -The internal RGMII RX clock delay (provided by this IP block) in -nanoseconds. When phy-mode is set to "rgmii" then the RX delay -should be explicitly configured. When the phy-mode is set to -either "rgmii-id" or "rgmii-rxid" the RX clock delay is already -provided by the PHY. Any configuration is ignored when the -phy-mode is set to "rmii". +The internal RGMII RX clock delay in nanoseconds. Deprecated, use +rx-internal-delay-ps instead. + +rx-internal-delay-ps: + default: 0 + + - if: + properties: +compatible: + contains: +enum: + - amlogic,meson8b-dwmac + - amlogic,meson8m2-dwmac + - amlogic,meson-gxbb-dwmac + - amlogic,meson-axg-dwmac +then: + properties: +rx-internal-delay-ps: + enum: +- 0 +- 2000 + + - if: + properties: +compatible: + contains: +enum: + - amlogic,meson-g12a-dwmac +then: + properties: +rx-internal-delay-ps: + enum: +- 0 +- 200 +- 400 +- 600 +- 800 +- 1000 +- 1200 +- 1400 +- 1600 +- 1800 +- 2000 +- 2200 +- 2400 +- 2600 +- 2800 +- 3000 properties: compatible: -- 2.29.2
[PATCH v3 2/5] net: stmmac: dwmac-meson8b: fix enabling the timing-adjustment clock
The timing-adjustment clock only has to be enabled when a) there is a
2ns RX delay configured using device-tree and b) the phy-mode indicates
that the RX delay should be enabled.
Only enable the RX delay if both are true, instead of (by accident) also
enabling it when there's the 2ns RX delay configured but the phy-mode
incicates that the RX delay is not used.
Fixes: 9308c47640d515 ("net: stmmac: dwmac-meson8b: add support for the RX
delay configuration")
Reported-by: Andrew Lunn
Reviewed-by: Andrew Lunn
Reviewed-by: Florian Fainelli
Signed-off-by: Martin Blumenstingl
---
drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
index f184b00f5116..5f500141567d 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
@@ -301,7 +301,7 @@ static int meson8b_init_prg_eth(struct meson8b_dwmac *dwmac)
return -EINVAL;
}
- if (rx_dly_config & PRG_ETH0_ADJ_ENABLE) {
+ if (delay_config & PRG_ETH0_ADJ_ENABLE) {
if (!dwmac->timing_adj_clk) {
dev_err(dwmac->dev,
"The timing-adjustment clock is mandatory for
the RX delay re-timing\n");
--
2.29.2
[PATCH v3 3/5] net: stmmac: dwmac-meson8b: use picoseconds for the RGMII RX delay
Amlogic Meson G12A, G12B and SM1 SoCs have a more advanced RGMII RX
delay register which allows picoseconds precision. Parse the new
"rx-internal-delay-ps" property or fall back to the value from the old
"amlogic,rx-delay-ns" property.
No upstream DTB uses the old "amlogic,rx-delay-ns" property (yet).
Only include minimalistic logic to fall back to the old property,
without any special validation (for example if the old and new
property are given at the same time).
Reviewed-by: Andrew Lunn
Reviewed-by: Florian Fainelli
Signed-off-by: Martin Blumenstingl
---
.../ethernet/stmicro/stmmac/dwmac-meson8b.c | 21 ---
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
index 5f500141567d..d2be3a7bd8fd 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
@@ -82,7 +82,7 @@ struct meson8b_dwmac {
phy_interface_t phy_mode;
struct clk *rgmii_tx_clk;
u32 tx_delay_ns;
- u32 rx_delay_ns;
+ u32 rx_delay_ps;
struct clk *timing_adj_clk;
};
@@ -276,7 +276,7 @@ static int meson8b_init_prg_eth(struct meson8b_dwmac *dwmac)
tx_dly_config = FIELD_PREP(PRG_ETH0_TXDLY_MASK,
dwmac->tx_delay_ns >> 1);
- if (dwmac->rx_delay_ns == 2)
+ if (dwmac->rx_delay_ps == 2000)
rx_dly_config = PRG_ETH0_ADJ_ENABLE | PRG_ETH0_ADJ_SETUP;
else
rx_dly_config = 0;
@@ -406,14 +406,19 @@ static int meson8b_dwmac_probe(struct platform_device
*pdev)
>tx_delay_ns))
dwmac->tx_delay_ns = 2;
- /* use 0ns as fallback since this is what most boards actually use */
- if (of_property_read_u32(pdev->dev.of_node, "amlogic,rx-delay-ns",
->rx_delay_ns))
- dwmac->rx_delay_ns = 0;
+ /* RX delay defaults to 0ps since this is what many boards use */
+ if (of_property_read_u32(pdev->dev.of_node, "rx-internal-delay-ps",
+>rx_delay_ps)) {
+ if (!of_property_read_u32(pdev->dev.of_node,
+ "amlogic,rx-delay-ns",
+ >rx_delay_ps))
+ /* convert ns to ps */
+ dwmac->rx_delay_ps *= 1000;
+ }
- if (dwmac->rx_delay_ns != 0 && dwmac->rx_delay_ns != 2) {
+ if (dwmac->rx_delay_ps != 0 && dwmac->rx_delay_ps != 2000) {
dev_err(>dev,
- "The only allowed RX delays values are: 0ns, 2ns");
+ "The only allowed RX delays values are: 0ps, 2000ps");
ret = -EINVAL;
goto err_remove_config_dt;
}
--
2.29.2
[PATCH v3 5/5] net: stmmac: dwmac-meson8b: add support for the RGMII RX delay on G12A
Amlogic Meson G12A (and newer: G12B, SM1) SoCs have a more advanced RX
delay logic. Instead of fine-tuning the delay in the nanoseconds range
it now allows tuning in 200 picosecond steps. This support comes with
new bits in the PRG_ETH1[19:16] register.
Add support for validating the RGMII RX delay as well as configuring the
register accordingly on these platforms.
Reviewed-by: Andrew Lunn
Reviewed-by: Florian Fainelli
Signed-off-by: Martin Blumenstingl
---
.../ethernet/stmicro/stmmac/dwmac-meson8b.c | 61 +++
1 file changed, 48 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
index 4937432ac70d..55152d7ba99a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
@@ -68,10 +68,21 @@
*/
#define PRG_ETH0_ADJ_SKEW GENMASK(24, 20)
+#define PRG_ETH1 0x4
+
+/* Defined for adding a delay to the input RX_CLK for better timing.
+ * Each step is 200ps. These bits are used with external RGMII PHYs
+ * because RGMII RX only has the small window. cfg_rxclk_dly can
+ * adjust the window between RX_CLK and RX_DATA and improve the stability
+ * of "rx data valid".
+ */
+#define PRG_ETH1_CFG_RXCLK_DLY GENMASK(19, 16)
+
struct meson8b_dwmac;
struct meson8b_dwmac_data {
int (*set_phy_mode)(struct meson8b_dwmac *dwmac);
+ bool has_prg_eth1_rgmii_rx_delay;
};
struct meson8b_dwmac {
@@ -270,30 +281,35 @@ static int meson8b_devm_clk_prepare_enable(struct
meson8b_dwmac *dwmac,
static int meson8b_init_rgmii_delays(struct meson8b_dwmac *dwmac)
{
- u32 tx_dly_config, rx_dly_config, delay_config;
+ u32 tx_dly_config, rx_adj_config, cfg_rxclk_dly, delay_config;
int ret;
+ rx_adj_config = 0;
+ cfg_rxclk_dly = 0;
tx_dly_config = FIELD_PREP(PRG_ETH0_TXDLY_MASK,
dwmac->tx_delay_ns >> 1);
- if (dwmac->rx_delay_ps == 2000)
- rx_dly_config = PRG_ETH0_ADJ_ENABLE | PRG_ETH0_ADJ_SETUP;
- else
- rx_dly_config = 0;
+ if (dwmac->data->has_prg_eth1_rgmii_rx_delay)
+ cfg_rxclk_dly = FIELD_PREP(PRG_ETH1_CFG_RXCLK_DLY,
+ dwmac->rx_delay_ps / 200);
+ else if (dwmac->rx_delay_ps == 2000)
+ rx_adj_config = PRG_ETH0_ADJ_ENABLE | PRG_ETH0_ADJ_SETUP;
switch (dwmac->phy_mode) {
case PHY_INTERFACE_MODE_RGMII:
- delay_config = tx_dly_config | rx_dly_config;
+ delay_config = tx_dly_config | rx_adj_config;
break;
case PHY_INTERFACE_MODE_RGMII_RXID:
delay_config = tx_dly_config;
+ cfg_rxclk_dly = 0;
break;
case PHY_INTERFACE_MODE_RGMII_TXID:
- delay_config = rx_dly_config;
+ delay_config = rx_adj_config;
break;
case PHY_INTERFACE_MODE_RGMII_ID:
case PHY_INTERFACE_MODE_RMII:
delay_config = 0;
+ cfg_rxclk_dly = 0;
break;
default:
dev_err(dwmac->dev, "unsupported phy-mode %s\n",
@@ -323,6 +339,9 @@ static int meson8b_init_rgmii_delays(struct meson8b_dwmac
*dwmac)
PRG_ETH0_ADJ_DELAY | PRG_ETH0_ADJ_SKEW,
delay_config);
+ meson8b_dwmac_mask_bits(dwmac, PRG_ETH1, PRG_ETH1_CFG_RXCLK_DLY,
+ cfg_rxclk_dly);
+
return 0;
}
@@ -423,11 +442,20 @@ static int meson8b_dwmac_probe(struct platform_device
*pdev)
dwmac->rx_delay_ps *= 1000;
}
- if (dwmac->rx_delay_ps != 0 && dwmac->rx_delay_ps != 2000) {
- dev_err(>dev,
- "The only allowed RX delays values are: 0ps, 2000ps");
- ret = -EINVAL;
- goto err_remove_config_dt;
+ if (dwmac->data->has_prg_eth1_rgmii_rx_delay) {
+ if (dwmac->rx_delay_ps != 0 && dwmac->rx_delay_ps != 2000) {
+ dev_err(dwmac->dev,
+ "The only allowed RGMII RX delays values are:
0ps, 2000ps");
+ ret = -EINVAL;
+ goto err_remove_config_dt;
+ }
+ } else {
+ if (dwmac->rx_delay_ps > 3000 || dwmac->rx_delay_ps % 200) {
+ dev_err(dwmac->dev,
+ "The RGMII RX delay range is 0..3000ps in 200ps
steps");
+ ret = -EINVAL;
+ goto err_remove_config_dt;
+ }
}
dwmac->timing_adj_clk = devm_clk_get_optional(dwmac->dev,
@@
Re: [PATCH 5.9 14/49] net: stmmac: dwmac-meson8b: fix mask definition of the m250_sel mux
Hi Pavel, On Sun, Dec 20, 2020 at 12:13 AM Pavel Machek wrote: > > On Sat 2020-12-19 23:38:25, Martin Blumenstingl wrote: > > Hi Pavel, > > > > On Sat, Dec 19, 2020 at 10:51 PM Pavel Machek wrote: > > [...] > > > I can't say I like this one: > > > > > > > > > > clk_configs->m250_mux.reg = dwmac->regs + PRG_ETH0; > > > > - clk_configs->m250_mux.shift = PRG_ETH0_CLK_M250_SEL_SHIFT; > > > > - clk_configs->m250_mux.mask = PRG_ETH0_CLK_M250_SEL_MASK; > > > > + clk_configs->m250_mux.shift = __ffs(PRG_ETH0_CLK_M250_SEL_MASK); > > > > > > It replaces constant with computation done at runtime; compiler can't > > > optimize it as __ffs is implemented with asm(). > > what do you suggest to use instead? > > personally I don't see a problem because this is only called once at > > driver probe time. > > I believe canonical solution is version before this patch, just with > fixed values OK, thanks for the hint I will keep it in my for patches in the future Best regards, Martin
[PATCH 0/2] clk: meson8b: cleanup unused code
Hi Jerome, these patches are two small cleanups for code we don't need anymore. The first patch removes support for old .dtbs. I am not sure if the "fallback" logic still works as I have not tried this in a long time. Martin Blumenstingl (2): clk: meson: meson8b: remove compatibility code for old .dtbs dt-bindings: clock: meson8b: remove non-existing clock macros drivers/clk/meson/meson8b.c | 45 +++- include/dt-bindings/clock/meson8b-clkc.h | 2 -- 2 files changed, 5 insertions(+), 42 deletions(-) -- 2.29.2
[PATCH 2/2] dt-bindings: clock: meson8b: remove non-existing clock macros
CLKID_UNUSED and CLKID_XTAL aren't valid clocks. Remove them since there are no consumers of this anymore. Signed-off-by: Martin Blumenstingl --- include/dt-bindings/clock/meson8b-clkc.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/include/dt-bindings/clock/meson8b-clkc.h b/include/dt-bindings/clock/meson8b-clkc.h index 4c5965ae1df4..f33781338eda 100644 --- a/include/dt-bindings/clock/meson8b-clkc.h +++ b/include/dt-bindings/clock/meson8b-clkc.h @@ -6,8 +6,6 @@ #ifndef __MESON8B_CLKC_H #define __MESON8B_CLKC_H -#define CLKID_UNUSED 0 -#define CLKID_XTAL 1 #define CLKID_PLL_FIXED2 #define CLKID_PLL_VID 3 #define CLKID_PLL_SYS 4 -- 2.29.2
[PATCH 1/2] clk: meson: meson8b: remove compatibility code for old .dtbs
The XTAL clock is provided via .dts since Linux 5.6. Remove
compatibility code for .dtbs which are older than that.
The switch to the HHI syscon has been done with Linux 5.1. Also remove
any code needed to support .dtbs that have not switched to the HHI
syscon yet.
Signed-off-by: Martin Blumenstingl
---
drivers/clk/meson/meson8b.c | 45 +
1 file changed, 5 insertions(+), 40 deletions(-)
diff --git a/drivers/clk/meson/meson8b.c b/drivers/clk/meson/meson8b.c
index 862f0756b50f..a844d35b553a 100644
--- a/drivers/clk/meson/meson8b.c
+++ b/drivers/clk/meson/meson8b.c
@@ -52,15 +52,6 @@ static const struct pll_params_table sys_pll_params_table[]
= {
{ /* sentinel */ },
};
-static struct clk_fixed_rate meson8b_xtal = {
- .fixed_rate = 2400,
- .hw.init = &(struct clk_init_data){
- .name = "xtal",
- .num_parents = 0,
- .ops = _fixed_rate_ops,
- },
-};
-
static struct clk_regmap meson8b_fixed_pll_dco = {
.data = &(struct meson_clk_pll_data){
.en = {
@@ -2715,7 +2706,6 @@ static MESON_GATE(meson8b_ao_iface, HHI_GCLK_AO, 3);
static struct clk_hw_onecell_data meson8_hw_onecell_data = {
.hws = {
- [CLKID_XTAL] = _xtal.hw,
[CLKID_PLL_FIXED] = _fixed_pll.hw,
[CLKID_PLL_VID] = _vid_pll.hw,
[CLKID_PLL_SYS] = _sys_pll.hw,
@@ -2922,7 +2912,6 @@ static struct clk_hw_onecell_data meson8_hw_onecell_data
= {
static struct clk_hw_onecell_data meson8b_hw_onecell_data = {
.hws = {
- [CLKID_XTAL] = _xtal.hw,
[CLKID_PLL_FIXED] = _fixed_pll.hw,
[CLKID_PLL_VID] = _vid_pll.hw,
[CLKID_PLL_SYS] = _sys_pll.hw,
@@ -3140,7 +3129,6 @@ static struct clk_hw_onecell_data meson8b_hw_onecell_data
= {
static struct clk_hw_onecell_data meson8m2_hw_onecell_data = {
.hws = {
- [CLKID_XTAL] = _xtal.hw,
[CLKID_PLL_FIXED] = _fixed_pll.hw,
[CLKID_PLL_VID] = _vid_pll.hw,
[CLKID_PLL_SYS] = _sys_pll.hw,
@@ -3725,36 +3713,19 @@ static struct meson8b_nb_data meson8b_cpu_nb_data = {
.nb.notifier_call = meson8b_cpu_clk_notifier_cb,
};
-static const struct regmap_config clkc_regmap_config = {
- .reg_bits = 32,
- .val_bits = 32,
- .reg_stride = 4,
-};
-
static void __init meson8b_clkc_init_common(struct device_node *np,
struct clk_hw_onecell_data *clk_hw_onecell_data)
{
struct meson8b_clk_reset *rstc;
const char *notifier_clk_name;
struct clk *notifier_clk;
- void __iomem *clk_base;
struct regmap *map;
int i, ret;
map = syscon_node_to_regmap(of_get_parent(np));
if (IS_ERR(map)) {
- pr_info("failed to get HHI regmap - Trying obsolete regs\n");
-
- /* Generic clocks, PLLs and some of the reset-bits */
- clk_base = of_iomap(np, 1);
- if (!clk_base) {
- pr_err("%s: Unable to map clk base\n", __func__);
- return;
- }
-
- map = regmap_init_mmio(NULL, clk_base, _regmap_config);
- if (IS_ERR(map))
- return;
+ pr_err("failed to get HHI regmap - Trying obsolete regs\n");
+ return;
}
rstc = kzalloc(sizeof(*rstc), GFP_KERNEL);
@@ -3778,16 +3749,10 @@ static void __init meson8b_clkc_init_common(struct
device_node *np,
meson8b_clk_regmaps[i]->map = map;
/*
-* always skip CLKID_UNUSED and also skip XTAL if the .dtb provides the
-* XTAL clock as input.
+* register all clks and start with the first used ID (which is
+* CLKID_PLL_FIXED)
*/
- if (!IS_ERR(of_clk_get_by_name(np, "xtal")))
- i = CLKID_PLL_FIXED;
- else
- i = CLKID_XTAL;
-
- /* register all clks */
- for (; i < CLK_NR_CLKS; i++) {
+ for (i = CLKID_PLL_FIXED; i < CLK_NR_CLKS; i++) {
/* array might be sparse */
if (!clk_hw_onecell_data->hws[i])
continue;
--
2.29.2
Re: [RFC PATCH 3/3] gpio: ej1x8: Add GPIO driver for Etron Tech Inc. EJ168/EJ188/EJ198
Hi Linus, On Wed, Oct 7, 2020 at 9:44 PM Martin Blumenstingl wrote: [...] > > As noted on the earlier patches I think this should be folded into the > > existing XHCI USB driver in drivers/usb/host/xhci-pci.c or, if that > > gets messy, as a separate bolt-on, something like > > xhci-pci-gpio.[c|h] in the drivers/usb/host/* directory. > > You can use a Kconfig symbol for the GPIO portions or not. > OK, I will do that if there are no objections from other developers > I am intending to place the relevant code in xhci-pci-etron.c, similar > to what we already have with xhci-pci-renesas.c I tried this and unfortunately there's a catch. the nice thing about having a separate GPIO driver means that the xhci-pci driver doesn't need to know about it. I implemented xhci-pci-etron.c and gave it a Kconfig option. xhci-pci is then calling into xhci-pci-etron (through some etron_xhci_pci_probe function). unfortunately this means that xhci-pci now depends on xhci-pci-etron. for xhci-pci-renesas this is fine (I think) because that part of the code is needed to get the xHCI controller going but for xhci-pci-etron this is a different story: the GPIO controller is entirely optional and only used on few devices my goal is (at some point in the future) to have the GPIO driver in OpenWrt. I am not sure if they would accept a patch where xhci-pci would then pull in the dependencies for that Etron controller, even though most boards don't need it. Please let me know if you have any idea on how to solve this. Best regards, Martin
[PATCH 3/5] ARM: dts: meson8: add the thermal-zones with cooling configuration
The vendor kernel uses the following thermal-zone settings:
<= 70°C:
- CPU frequency limited to 1.608GHz
- GPU limited to 511MHz and 5 cores (pixel processors)
<= 80°C:
- CPU frequency limited to 1.2GHz
- GPU limited to 435MHz and 4 cores (pixel processors)
<= 90°C:
- CPU frequency limited to 0.804GHz
- GPU limited to 328MHz and 3 cores (pixel processors)
Add simplified thermal configuration which is taken from the
GXBB/GXL/GXM SoC family (which uses the same manufacturing process and
has the same maximum junction temperature of 125°C). With this the
thermal framework will try to keep the SoC temperature at or below 80°C
which is identical to the vendor kernel (with the exception of one GPU
pixel processor).
The number of GPU cores are not taken into account as this is not
supported.
Signed-off-by: Martin Blumenstingl
---
arch/arm/boot/dts/meson8.dtsi | 54 +++
1 file changed, 54 insertions(+)
diff --git a/arch/arm/boot/dts/meson8.dtsi b/arch/arm/boot/dts/meson8.dtsi
index 04688e8abce2..420324ea2ad7 100644
--- a/arch/arm/boot/dts/meson8.dtsi
+++ b/arch/arm/boot/dts/meson8.dtsi
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include "meson.dtsi"
/ {
@@ -28,6 +29,7 @@ cpu0: cpu@200 {
resets = < CLKC_RESET_CPU0_SOFT_RESET>;
operating-points-v2 = <_opp_table>;
clocks = < CLKID_CPUCLK>;
+ #cooling-cells = <2>; /* min followed by max */
};
cpu1: cpu@201 {
@@ -39,6 +41,7 @@ cpu1: cpu@201 {
resets = < CLKC_RESET_CPU1_SOFT_RESET>;
operating-points-v2 = <_opp_table>;
clocks = < CLKID_CPUCLK>;
+ #cooling-cells = <2>; /* min followed by max */
};
cpu2: cpu@202 {
@@ -50,6 +53,7 @@ cpu2: cpu@202 {
resets = < CLKC_RESET_CPU2_SOFT_RESET>;
operating-points-v2 = <_opp_table>;
clocks = < CLKID_CPUCLK>;
+ #cooling-cells = <2>; /* min followed by max */
};
cpu3: cpu@203 {
@@ -61,6 +65,7 @@ cpu3: cpu@203 {
resets = < CLKC_RESET_CPU3_SOFT_RESET>;
operating-points-v2 = <_opp_table>;
clocks = < CLKID_CPUCLK>;
+ #cooling-cells = <2>; /* min followed by max */
};
};
@@ -190,6 +195,54 @@ power-firmware@4f0 {
};
};
+ thermal-zones {
+ soc {
+ polling-delay-passive = <250>; /* milliseconds */
+ polling-delay = <1000>; /* milliseconds */
+ thermal-sensors = <_sensor>;
+
+ cooling-maps {
+ map0 {
+ trip = <_passive>;
+ cooling-device = <
THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+<
THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+<
THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+<
THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+<
THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+
+ map1 {
+ trip = <_hot>;
+ cooling-device = <
THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+<
THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+<
THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+<
THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+<
THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
+
+ trips {
+ soc_passive: soc-passive {
+ temperature = <8>; /* millicelsius
*/
+ hysteresis = <2000>; /* millicelsius */
+ type = "passive";
+ };
+
+ soc_hot: soc-hot {
+ temperature = <9>; /* millicelsius
*/
+ hysteresis = <2000>; /* millicelsius */
+ type =
[PATCH 4/5] ARM: dts: meson8b: add the thermal-zones with cooling configuration
The vendor kernel uses the following thermal-zone settings:
<= 70°C:
- CPU frequency limited to 1.488GHz
- GPU limited to 511MHz and 2 cores (pixel processors)
<= 80°C:
- CPU frequency limited to 1.2GHz
- GPU limited to 435MHz and 2 cores (pixel processors)
<= 90°C:
- CPU frequency limited to 0.804GHz
- GPU limited to 328MHz and 1 core (pixel processor)
Add simplified thermal configuration which is taken from the
GXBB/GXL/GXM SoC family (which uses the same manufacturing process and
has the same maximum junction temperature of 125°C). With this the
thermal framework will try to keep the SoC temperature at or below 80°C
which is identical to the vendor kernel (with the exception of one CPU
frequency step from 1.488GHz to 1.536GHz).
The number of GPU cores are not taken into account as this is not
supported.
Signed-off-by: Martin Blumenstingl
---
arch/arm/boot/dts/meson8b.dtsi | 54 ++
1 file changed, 54 insertions(+)
diff --git a/arch/arm/boot/dts/meson8b.dtsi b/arch/arm/boot/dts/meson8b.dtsi
index 2401cdf5f751..dbf7963b6c87 100644
--- a/arch/arm/boot/dts/meson8b.dtsi
+++ b/arch/arm/boot/dts/meson8b.dtsi
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include "meson.dtsi"
/ {
@@ -26,6 +27,7 @@ cpu0: cpu@200 {
resets = < CLKC_RESET_CPU0_SOFT_RESET>;
operating-points-v2 = <_opp_table>;
clocks = < CLKID_CPUCLK>;
+ #cooling-cells = <2>; /* min followed by max */
};
cpu1: cpu@201 {
@@ -37,6 +39,7 @@ cpu1: cpu@201 {
resets = < CLKC_RESET_CPU1_SOFT_RESET>;
operating-points-v2 = <_opp_table>;
clocks = < CLKID_CPUCLK>;
+ #cooling-cells = <2>; /* min followed by max */
};
cpu2: cpu@202 {
@@ -48,6 +51,7 @@ cpu2: cpu@202 {
resets = < CLKC_RESET_CPU2_SOFT_RESET>;
operating-points-v2 = <_opp_table>;
clocks = < CLKID_CPUCLK>;
+ #cooling-cells = <2>; /* min followed by max */
};
cpu3: cpu@203 {
@@ -59,6 +63,7 @@ cpu3: cpu@203 {
resets = < CLKC_RESET_CPU3_SOFT_RESET>;
operating-points-v2 = <_opp_table>;
clocks = < CLKID_CPUCLK>;
+ #cooling-cells = <2>; /* min followed by max */
};
};
@@ -167,6 +172,54 @@ hwrom@0 {
};
};
+ thermal-zones {
+ soc {
+ polling-delay-passive = <250>; /* milliseconds */
+ polling-delay = <1000>; /* milliseconds */
+ thermal-sensors = <_sensor>;
+
+ cooling-maps {
+ map0 {
+ trip = <_passive>;
+ cooling-device = <
THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+<
THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+<
THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+<
THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+<
THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+
+ map1 {
+ trip = <_hot>;
+ cooling-device = <
THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+<
THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+<
THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+<
THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
+<
THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
+
+ trips {
+ soc_passive: soc-passive {
+ temperature = <8>; /* millicelsius
*/
+ hysteresis = <2000>; /* millicelsius */
+ type = "passive";
+ };
+
+ soc_hot: soc-hot {
+ temperature = <9>; /* millicelsius
*/
+ hysteresis = <2000>; /* millicel
[PATCH 2/5] ARM: dts: meson: add the ADC thermal sensor to meson.dtsi
The SoC temperature can be retrieved from ADC channel 8 on all 32-bit
SoCs (Meson6, Meson8, Meson8b and Meson8m2). Add a "generic-adc-thermal"
instance to meson.dtsi so the thermal sensor is available for all SoCs.
If the temperature sensor calibration data is missing for a board then
the "generic-adc-thermal" will not probe and not register a thermal
sensor.
Signed-off-by: Martin Blumenstingl
---
arch/arm/boot/dts/meson.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/meson.dtsi b/arch/arm/boot/dts/meson.dtsi
index 5f074f7aa1a2..e0ca5f08d07d 100644
--- a/arch/arm/boot/dts/meson.dtsi
+++ b/arch/arm/boot/dts/meson.dtsi
@@ -298,6 +298,13 @@ efuse: nvmem@0 {
};
};
+ thermal_sensor: thermal-sensor {
+ compatible = "generic-adc-thermal";
+ #thermal-sensor-cells = <0>;
+ io-channels = < 8>;
+ io-channel-names = "sensor-channel";
+ };
+
xtal: xtal-clk {
compatible = "fixed-clock";
clock-frequency = <2400>;
--
2.29.2
[PATCH 1/5] ARM: dts: meson: move iio-hwmon for the SoC temperature to meson.dtsi
The SoC temperature can be retrieved from ADC channel 8 on all 32-bit
SoCs (Meson6, Meson8, Meson8b and Meson8m2). Move the iio-hwmon instance
to meson.dtsi instead of duplicating it in all board.dts.
If the temperature sensor calibration data is missing for a board then
iio-hwmon will simply not probe.
Signed-off-by: Martin Blumenstingl
---
arch/arm/boot/dts/meson.dtsi | 5 +
arch/arm/boot/dts/meson8b-ec100.dts | 5 -
arch/arm/boot/dts/meson8b-mxq.dts | 5 -
arch/arm/boot/dts/meson8b-odroidc1.dts| 5 -
arch/arm/boot/dts/meson8m2-mxiii-plus.dts | 5 -
5 files changed, 5 insertions(+), 20 deletions(-)
diff --git a/arch/arm/boot/dts/meson.dtsi b/arch/arm/boot/dts/meson.dtsi
index 7649dd1e0b9e..5f074f7aa1a2 100644
--- a/arch/arm/boot/dts/meson.dtsi
+++ b/arch/arm/boot/dts/meson.dtsi
@@ -11,6 +11,11 @@ / {
#size-cells = <1>;
interrupt-parent = <>;
+ iio-hwmon {
+ compatible = "iio-hwmon";
+ io-channels = < 8>;
+ };
+
soc {
compatible = "simple-bus";
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/meson8b-ec100.dts
b/arch/arm/boot/dts/meson8b-ec100.dts
index ed06102a4014..8e48ccc6b634 100644
--- a/arch/arm/boot/dts/meson8b-ec100.dts
+++ b/arch/arm/boot/dts/meson8b-ec100.dts
@@ -70,11 +70,6 @@ gpio-poweroff {
timeout-ms = <2>;
};
- iio-hwmon {
- compatible = "iio-hwmon";
- io-channels = < 8>;
- };
-
leds {
compatible = "gpio-leds";
diff --git a/arch/arm/boot/dts/meson8b-mxq.dts
b/arch/arm/boot/dts/meson8b-mxq.dts
index 33037ef62d0a..f3937d55472d 100644
--- a/arch/arm/boot/dts/meson8b-mxq.dts
+++ b/arch/arm/boot/dts/meson8b-mxq.dts
@@ -27,11 +27,6 @@ memory {
reg = <0x4000 0x4000>;
};
- iio-hwmon {
- compatible = "iio-hwmon";
- io-channels = < 8>;
- };
-
vcck: regulator-vcck {
compatible = "pwm-regulator";
diff --git a/arch/arm/boot/dts/meson8b-odroidc1.dts
b/arch/arm/boot/dts/meson8b-odroidc1.dts
index 5963566dbcc9..c440ef94e082 100644
--- a/arch/arm/boot/dts/meson8b-odroidc1.dts
+++ b/arch/arm/boot/dts/meson8b-odroidc1.dts
@@ -85,11 +85,6 @@ tf_io: gpio-regulator-tf_io {
180 1>;
};
- iio-hwmon {
- compatible = "iio-hwmon";
- io-channels = < 8>;
- };
-
rtc32k_xtal: rtc32k-xtal-clk {
/* X3 in the schematics */
compatible = "fixed-clock";
diff --git a/arch/arm/boot/dts/meson8m2-mxiii-plus.dts
b/arch/arm/boot/dts/meson8m2-mxiii-plus.dts
index 8f4eb1ed4581..fa6d55f1cfb9 100644
--- a/arch/arm/boot/dts/meson8m2-mxiii-plus.dts
+++ b/arch/arm/boot/dts/meson8m2-mxiii-plus.dts
@@ -45,11 +45,6 @@ button-function {
};
};
- iio-hwmon {
- compatible = "iio-hwmon";
- io-channels = < 8>;
- };
-
vcc_3v3: regulator-vcc3v3 {
compatible = "regulator-fixed";
regulator-name = "VCC3V3";
--
2.29.2
[PATCH 0/5] Thermal zone configuration for Meson8/Meson8b/Meson8m2
This adds the thermal zone configuration on Meson8/Meson8b/Meson8m2 SoCs. The thermal sensor reading is taken from SAR ADC. With "generic-adc-thermal" it is then used to configure the thermal zone. CPU and GPU frequencies can both be managed. The vendor kernel also manages the number of active GPU pixel processor cores. This is not supported yet so we skip it. Martin Blumenstingl (5): ARM: dts: meson: move iio-hwmon for the SoC temperature to meson.dtsi ARM: dts: meson: add the ADC thermal sensor to meson.dtsi ARM: dts: meson8: add the thermal-zones with cooling configuration ARM: dts: meson8b: add the thermal-zones with cooling configuration ARM: multi_v7_defconfig: Enable support for the ADC thermal sensor arch/arm/boot/dts/meson.dtsi | 12 + arch/arm/boot/dts/meson8.dtsi | 54 +++ arch/arm/boot/dts/meson8b-ec100.dts | 5 --- arch/arm/boot/dts/meson8b-mxq.dts | 5 --- arch/arm/boot/dts/meson8b-odroidc1.dts| 5 --- arch/arm/boot/dts/meson8b.dtsi| 54 +++ arch/arm/boot/dts/meson8m2-mxiii-plus.dts | 5 --- arch/arm/configs/multi_v7_defconfig | 1 + 8 files changed, 121 insertions(+), 20 deletions(-) -- 2.29.2
[PATCH 5/5] ARM: multi_v7_defconfig: Enable support for the ADC thermal sensor
32-bit Amlogic Meson platforms are using a special ADC channel to read the SoC temperature. Enable the "generic ADC thermal" driver so this data can be used to cool the SoC for example by reduing the maximum CPU and GPU frequencies temporarily. Signed-off-by: Martin Blumenstingl --- arch/arm/configs/multi_v7_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig index c5f25710fedc..0a55240ce2fc 100644 --- a/arch/arm/configs/multi_v7_defconfig +++ b/arch/arm/configs/multi_v7_defconfig @@ -515,6 +515,7 @@ CONFIG_ARMADA_THERMAL=y CONFIG_BCM2711_THERMAL=m CONFIG_BCM2835_THERMAL=m CONFIG_BRCMSTB_THERMAL=m +CONFIG_GENERIC_ADC_THERMAL=m CONFIG_ST_THERMAL_MEMMAP=y CONFIG_UNIPHIER_THERMAL=y CONFIG_DA9063_WATCHDOG=m -- 2.29.2
Re: [PATCH 5.9 14/49] net: stmmac: dwmac-meson8b: fix mask definition of the m250_sel mux
Hi Pavel, On Sat, Dec 19, 2020 at 10:51 PM Pavel Machek wrote: [...] > I can't say I like this one: > > > > clk_configs->m250_mux.reg = dwmac->regs + PRG_ETH0; > > - clk_configs->m250_mux.shift = PRG_ETH0_CLK_M250_SEL_SHIFT; > > - clk_configs->m250_mux.mask = PRG_ETH0_CLK_M250_SEL_MASK; > > + clk_configs->m250_mux.shift = __ffs(PRG_ETH0_CLK_M250_SEL_MASK); > > It replaces constant with computation done at runtime; compiler can't > optimize it as __ffs is implemented with asm(). what do you suggest to use instead? personally I don't see a problem because this is only called once at driver probe time. Best regards, Martin
[PATCH] net: stmmac: dwmac-meson8b: ignore the second clock input
The dwmac glue registers on Amlogic Meson8b and newer SoCs has two clock
inputs:
- Meson8b and Meson8m2: MPLL2 and MPLL2 (the same parent is wired to
both inputs)
- GXBB, GXL, GXM, AXG, G12A, G12B, SM1: FCLK_DIV2 and MPLL2
All known vendor kernels and u-boots are using the first input only. We
let the common clock framework automatically choose the "right" parent.
For some boards this causes a problem though, specificially with G12A and
newer SoCs. The clock input is used for generating the 125MHz RGMII TX
clock. For the two input clocks this means on G12A:
- FCLK_DIV2: 99985Hz / 8 = 12498.125Hz
- MPLL2: 49993Hz / 4 = 12498.25Hz
In theory MPLL2 is the "better" clock input because it's gets us 0.125Hz
closer to the requested frequency than FCLK_DIV2. In reality however
there is a resource conflict because MPLL2 is needed to generate some of
the audio clocks. dwmac-meson8b probes first and sets up the clock tree
with MPLL2. This works fine until the audio driver comes and "steals"
the MPLL2 clocks and configures it with it's own rate (294909637Hz). The
common clock framework happily changes the MPLL2 rate but does not
reconfigure our RGMII TX clock tree, which then ends up at 73727409Hz,
which is more than 40% off the requested 125MHz.
Don't use the second clock input for now to force the common clock
framework to always select the first parent. This mimics the behavior
from the vendor driver and fixes the clock resource conflict with the
audio driver on G12A boards. Once the common clock framework can handle
this situation this change can be reverted again.
Fixes: 566e8251625304 ("net: stmmac: add a glue driver for the Amlogic Meson 8b
/ GXBB DWMAC")
Reported-by: Thomas Graichen
Signed-off-by: Martin Blumenstingl
---
drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
index 459ae715b33d..f184b00f5116 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
@@ -135,7 +135,7 @@ static int meson8b_init_rgmii_tx_clk(struct meson8b_dwmac
*dwmac)
struct device *dev = dwmac->dev;
static const struct clk_parent_data mux_parents[] = {
{ .fw_name = "clkin0", },
- { .fw_name = "clkin1", },
+ { .index = -1, },
};
static const struct clk_div_table div_table[] = {
{ .div = 2, .val = 2, },
--
2.29.2
