* [PATCH net-next v4 2/2] net: dsa: microchip: Add property to disable reference clock
From: Robert Hancock @ 2022-01-27 16:41 UTC (permalink / raw)
To: netdev
Cc: woojung.huh, UNGLinuxDriver, andrew, vivien.didelot, f.fainelli,
olteanv, davem, kuba, robh+dt, marex, devicetree, Robert Hancock
In-Reply-To: <20220127164156.3677856-1-robert.hancock@calian.com>
Add a new microchip,synclko-disable property which can be specified
to disable the reference clock output from the device if not required
by the board design.
Signed-off-by: Robert Hancock <robert.hancock@calian.com>
---
drivers/net/dsa/microchip/ksz9477.c | 9 ++++++---
drivers/net/dsa/microchip/ksz_common.c | 6 ++++++
drivers/net/dsa/microchip/ksz_common.h | 1 +
3 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/net/dsa/microchip/ksz9477.c b/drivers/net/dsa/microchip/ksz9477.c
index 353b5f981740..a85d990896b0 100644
--- a/drivers/net/dsa/microchip/ksz9477.c
+++ b/drivers/net/dsa/microchip/ksz9477.c
@@ -222,9 +222,12 @@ static int ksz9477_reset_switch(struct ksz_device *dev)
(BROADCAST_STORM_VALUE *
BROADCAST_STORM_PROT_RATE) / 100);
- if (dev->synclko_125)
- ksz_write8(dev, REG_SW_GLOBAL_OUTPUT_CTRL__1,
- SW_ENABLE_REFCLKO | SW_REFCLKO_IS_125MHZ);
+ data8 = SW_ENABLE_REFCLKO;
+ if (dev->synclko_disable)
+ data8 = 0;
+ else if (dev->synclko_125)
+ data8 = SW_ENABLE_REFCLKO | SW_REFCLKO_IS_125MHZ;
+ ksz_write8(dev, REG_SW_GLOBAL_OUTPUT_CTRL__1, data8);
return 0;
}
diff --git a/drivers/net/dsa/microchip/ksz_common.c b/drivers/net/dsa/microchip/ksz_common.c
index 55dbda04ea62..7e33ec73f803 100644
--- a/drivers/net/dsa/microchip/ksz_common.c
+++ b/drivers/net/dsa/microchip/ksz_common.c
@@ -434,6 +434,12 @@ int ksz_switch_register(struct ksz_device *dev,
}
dev->synclko_125 = of_property_read_bool(dev->dev->of_node,
"microchip,synclko-125");
+ dev->synclko_disable = of_property_read_bool(dev->dev->of_node,
+ "microchip,synclko-disable");
+ if (dev->synclko_125 && dev->synclko_disable) {
+ dev_err(dev->dev, "inconsistent synclko settings\n");
+ return -EINVAL;
+ }
}
ret = dsa_register_switch(dev->ds);
diff --git a/drivers/net/dsa/microchip/ksz_common.h b/drivers/net/dsa/microchip/ksz_common.h
index df8ae59c8525..3db63f62f0a1 100644
--- a/drivers/net/dsa/microchip/ksz_common.h
+++ b/drivers/net/dsa/microchip/ksz_common.h
@@ -75,6 +75,7 @@ struct ksz_device {
u32 regs_size;
bool phy_errata_9477;
bool synclko_125;
+ bool synclko_disable;
struct vlan_table *vlan_cache;
--
2.31.1
^ permalink raw reply related
* [PATCH net-next v4 1/2] net: dsa: microchip: Document property to disable reference clock
From: Robert Hancock @ 2022-01-27 16:41 UTC (permalink / raw)
To: netdev
Cc: woojung.huh, UNGLinuxDriver, andrew, vivien.didelot, f.fainelli,
olteanv, davem, kuba, robh+dt, marex, devicetree, Robert Hancock,
Rob Herring
In-Reply-To: <20220127164156.3677856-1-robert.hancock@calian.com>
Document the new microchip,synclko-disable property which can be
specified to disable the reference clock output from the device if not
required by the board design.
Signed-off-by: Robert Hancock <robert.hancock@calian.com>
Acked-by: Rob Herring <robh@kernel.org>
---
.../devicetree/bindings/net/dsa/microchip,ksz.yaml | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml b/Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml
index 84985f53bffd..184152087b60 100644
--- a/Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml
+++ b/Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml
@@ -42,6 +42,12 @@ properties:
description:
Set if the output SYNCLKO frequency should be set to 125MHz instead of 25MHz.
+ microchip,synclko-disable:
+ $ref: /schemas/types.yaml#/definitions/flag
+ description:
+ Set if the output SYNCLKO clock should be disabled. Do not mix with
+ microchip,synclko-125.
+
required:
- compatible
- reg
--
2.31.1
^ permalink raw reply related
* [PATCH net-next v4 1/3] dt-bindings: net: cdns,macb: added generic PHY and reset mappings for ZynqMP
From: Robert Hancock @ 2022-01-27 16:37 UTC (permalink / raw)
To: netdev
Cc: davem, kuba, robh+dt, michal.simek, nicolas.ferre, claudiu.beznea,
devicetree, linux, laurent.pinchart, Robert Hancock
In-Reply-To: <20220127163736.3677478-1-robert.hancock@calian.com>
Updated macb DT binding documentation to reflect the phy-names, phys,
resets, reset-names properties which are now used with ZynqMP GEM
devices, and added a ZynqMP-specific DT example.
Signed-off-by: Robert Hancock <robert.hancock@calian.com>
---
.../devicetree/bindings/net/cdns,macb.yaml | 56 +++++++++++++++++++
1 file changed, 56 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/cdns,macb.yaml b/Documentation/devicetree/bindings/net/cdns,macb.yaml
index 8dd06db34169..6cd3d853dcba 100644
--- a/Documentation/devicetree/bindings/net/cdns,macb.yaml
+++ b/Documentation/devicetree/bindings/net/cdns,macb.yaml
@@ -81,6 +81,25 @@ properties:
phy-handle: true
+ phys:
+ maxItems: 1
+
+ phy-names:
+ const: sgmii-phy
+ description:
+ Required with ZynqMP SoC when in SGMII mode.
+ Should reference PS-GTR generic PHY device for this controller
+ instance. See ZynqMP example.
+
+ resets:
+ maxItems: 1
+ description:
+ Recommended with ZynqMP, specify reset control for this
+ controller instance with zynqmp-reset driver.
+
+ reset-names:
+ maxItems: 1
+
fixed-link: true
iommus:
@@ -157,3 +176,40 @@ examples:
reset-gpios = <&pioE 6 1>;
};
};
+
+ - |
+ #include <dt-bindings/clock/xlnx-zynqmp-clk.h>
+ #include <dt-bindings/power/xlnx-zynqmp-power.h>
+ #include <dt-bindings/reset/xlnx-zynqmp-resets.h>
+ #include <dt-bindings/phy/phy.h>
+
+ bus {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ gem1: ethernet@ff0c0000 {
+ compatible = "cdns,zynqmp-gem", "cdns,gem";
+ interrupt-parent = <&gic>;
+ interrupts = <0 59 4>, <0 59 4>;
+ reg = <0x0 0xff0c0000 0x0 0x1000>;
+ clocks = <&zynqmp_clk LPD_LSBUS>, <&zynqmp_clk GEM1_REF>,
+ <&zynqmp_clk GEM1_TX>, <&zynqmp_clk GEM1_RX>,
+ <&zynqmp_clk GEM_TSU>;
+ clock-names = "pclk", "hclk", "tx_clk", "rx_clk", "tsu_clk";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ #stream-id-cells = <1>;
+ iommus = <&smmu 0x875>;
+ power-domains = <&zynqmp_firmware PD_ETH_1>;
+ resets = <&zynqmp_reset ZYNQMP_RESET_GEM1>;
+ reset-names = "gem1_rst";
+ status = "okay";
+ phy-mode = "sgmii";
+ phy-names = "sgmii-phy";
+ phys = <&psgtr 1 PHY_TYPE_SGMII 1 1>;
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ pause;
+ };
+ };
+ };
--
2.31.1
^ permalink raw reply related
* [PATCH net-next v4 3/3] arm64: dts: zynqmp: Added GEM reset definitions
From: Robert Hancock @ 2022-01-27 16:37 UTC (permalink / raw)
To: netdev
Cc: davem, kuba, robh+dt, michal.simek, nicolas.ferre, claudiu.beznea,
devicetree, linux, laurent.pinchart, Robert Hancock
In-Reply-To: <20220127163736.3677478-1-robert.hancock@calian.com>
The Cadence GEM/MACB driver now utilizes the platform-level reset on the
ZynqMP platform. Add reset definitions to the ZynqMP platform device
tree to allow this to be used.
Signed-off-by: Robert Hancock <robert.hancock@calian.com>
---
arch/arm64/boot/dts/xilinx/zynqmp.dtsi | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
index 74e66443e4ce..9bec3ba20c69 100644
--- a/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
+++ b/arch/arm64/boot/dts/xilinx/zynqmp.dtsi
@@ -512,6 +512,8 @@ gem0: ethernet@ff0b0000 {
#stream-id-cells = <1>;
iommus = <&smmu 0x874>;
power-domains = <&zynqmp_firmware PD_ETH_0>;
+ resets = <&zynqmp_reset ZYNQMP_RESET_GEM0>;
+ reset-names = "gem0_rst";
};
gem1: ethernet@ff0c0000 {
@@ -526,6 +528,8 @@ gem1: ethernet@ff0c0000 {
#stream-id-cells = <1>;
iommus = <&smmu 0x875>;
power-domains = <&zynqmp_firmware PD_ETH_1>;
+ resets = <&zynqmp_reset ZYNQMP_RESET_GEM1>;
+ reset-names = "gem1_rst";
};
gem2: ethernet@ff0d0000 {
@@ -540,6 +544,8 @@ gem2: ethernet@ff0d0000 {
#stream-id-cells = <1>;
iommus = <&smmu 0x876>;
power-domains = <&zynqmp_firmware PD_ETH_2>;
+ resets = <&zynqmp_reset ZYNQMP_RESET_GEM2>;
+ reset-names = "gem2_rst";
};
gem3: ethernet@ff0e0000 {
@@ -554,6 +560,8 @@ gem3: ethernet@ff0e0000 {
#stream-id-cells = <1>;
iommus = <&smmu 0x877>;
power-domains = <&zynqmp_firmware PD_ETH_3>;
+ resets = <&zynqmp_reset ZYNQMP_RESET_GEM3>;
+ reset-names = "gem3_rst";
};
gpio: gpio@ff0a0000 {
--
2.31.1
^ permalink raw reply related
* [PATCH net-next v4 0/3] Cadence MACB/GEM support for ZynqMP SGMII
From: Robert Hancock @ 2022-01-27 16:37 UTC (permalink / raw)
To: netdev
Cc: davem, kuba, robh+dt, michal.simek, nicolas.ferre, claudiu.beznea,
devicetree, linux, laurent.pinchart, Robert Hancock
Changes to allow SGMII mode to work properly in the GEM driver on the
Xilinx ZynqMP platform.
Changes since v3:
-more code formatting and error handling fixes
Changes since v2:
-fixed missing includes in DT binding example
-fixed phy_init and phy_power_on error handling/cleanup, moved
phy_power_on to open rather than probe
Changes since v1:
-changed order of controller reset and PHY init as per suggestion
-switched device reset to be optional
-updated bindings doc patch for switch to YAML
Robert Hancock (3):
dt-bindings: net: cdns,macb: added generic PHY and reset mappings for
ZynqMP
net: macb: Added ZynqMP-specific initialization
arm64: dts: zynqmp: Added GEM reset definitions
.../devicetree/bindings/net/cdns,macb.yaml | 56 +++++++++++++++++
arch/arm64/boot/dts/xilinx/zynqmp.dtsi | 8 +++
drivers/net/ethernet/cadence/macb.h | 4 ++
drivers/net/ethernet/cadence/macb_main.c | 63 ++++++++++++++++++-
4 files changed, 128 insertions(+), 3 deletions(-)
--
2.31.1
^ permalink raw reply
* [PATCH net-next v4 2/3] net: macb: Added ZynqMP-specific initialization
From: Robert Hancock @ 2022-01-27 16:37 UTC (permalink / raw)
To: netdev
Cc: davem, kuba, robh+dt, michal.simek, nicolas.ferre, claudiu.beznea,
devicetree, linux, laurent.pinchart, Robert Hancock
In-Reply-To: <20220127163736.3677478-1-robert.hancock@calian.com>
The GEM controllers on ZynqMP were missing some initialization steps which
are required in some cases when using SGMII mode, which uses the PS-GTR
transceivers managed by the phy-zynqmp driver.
The GEM core appears to need a hardware-level reset in order to work
properly in SGMII mode in cases where the GT reference clock was not
present at initial power-on. This can be done using a reset mapped to
the zynqmp-reset driver in the device tree.
Also, when in SGMII mode, the GEM driver needs to ensure the PHY is
initialized and powered on.
Signed-off-by: Robert Hancock <robert.hancock@calian.com>
---
drivers/net/ethernet/cadence/macb.h | 4 ++
drivers/net/ethernet/cadence/macb_main.c | 63 ++++++++++++++++++++++--
2 files changed, 64 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/cadence/macb.h b/drivers/net/ethernet/cadence/macb.h
index 9ddbee7de72b..f0a7d8396a4a 100644
--- a/drivers/net/ethernet/cadence/macb.h
+++ b/drivers/net/ethernet/cadence/macb.h
@@ -12,6 +12,7 @@
#include <linux/ptp_clock_kernel.h>
#include <linux/net_tstamp.h>
#include <linux/interrupt.h>
+#include <linux/phy/phy.h>
#if defined(CONFIG_ARCH_DMA_ADDR_T_64BIT) || defined(CONFIG_MACB_USE_HWSTAMP)
#define MACB_EXT_DESC
@@ -1291,6 +1292,9 @@ struct macb {
u32 wol;
struct macb_ptp_info *ptp_info; /* macb-ptp interface */
+
+ struct phy *sgmii_phy; /* for ZynqMP SGMII mode */
+
#ifdef MACB_EXT_DESC
uint8_t hw_dma_cap;
#endif
diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
index a363da928e8b..1ce20bf52f72 100644
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -34,7 +34,9 @@
#include <linux/udp.h>
#include <linux/tcp.h>
#include <linux/iopoll.h>
+#include <linux/phy/phy.h>
#include <linux/pm_runtime.h>
+#include <linux/reset.h>
#include "macb.h"
/* This structure is only used for MACB on SiFive FU540 devices */
@@ -2739,10 +2741,14 @@ static int macb_open(struct net_device *dev)
macb_init_hw(bp);
- err = macb_phylink_connect(bp);
+ err = phy_power_on(bp->sgmii_phy);
if (err)
goto reset_hw;
+ err = macb_phylink_connect(bp);
+ if (err)
+ goto phy_off;
+
netif_tx_start_all_queues(dev);
if (bp->ptp_info)
@@ -2750,6 +2756,9 @@ static int macb_open(struct net_device *dev)
return 0;
+phy_off:
+ phy_power_off(bp->sgmii_phy);
+
reset_hw:
macb_reset_hw(bp);
for (q = 0, queue = bp->queues; q < bp->num_queues; ++q, ++queue)
@@ -2775,6 +2784,8 @@ static int macb_close(struct net_device *dev)
phylink_stop(bp->phylink);
phylink_disconnect_phy(bp->phylink);
+ phy_power_off(bp->sgmii_phy);
+
spin_lock_irqsave(&bp->lock, flags);
macb_reset_hw(bp);
netif_carrier_off(dev);
@@ -4544,13 +4555,55 @@ static const struct macb_config np4_config = {
.usrio = &macb_default_usrio,
};
+static int zynqmp_init(struct platform_device *pdev)
+{
+ struct net_device *dev = platform_get_drvdata(pdev);
+ struct macb *bp = netdev_priv(dev);
+ int ret;
+
+ if (bp->phy_interface == PHY_INTERFACE_MODE_SGMII) {
+ /* Ensure PS-GTR PHY device used in SGMII mode is ready */
+ bp->sgmii_phy = devm_phy_get(&pdev->dev, "sgmii-phy");
+
+ if (IS_ERR(bp->sgmii_phy)) {
+ ret = PTR_ERR(bp->sgmii_phy);
+ dev_err_probe(&pdev->dev, ret,
+ "failed to get PS-GTR PHY\n");
+ return ret;
+ }
+
+ ret = phy_init(bp->sgmii_phy);
+ if (ret) {
+ dev_err(&pdev->dev, "failed to init PS-GTR PHY: %d\n",
+ ret);
+ return ret;
+ }
+ }
+
+ /* Fully reset GEM controller at hardware level using zynqmp-reset driver,
+ * if mapped in device tree.
+ */
+ ret = device_reset_optional(&pdev->dev);
+ if (ret) {
+ dev_err_probe(&pdev->dev, ret, "failed to reset controller");
+ phy_exit(bp->sgmii_phy);
+ return ret;
+ }
+
+ ret = macb_init(pdev);
+ if (ret)
+ phy_exit(bp->sgmii_phy);
+
+ return ret;
+}
+
static const struct macb_config zynqmp_config = {
.caps = MACB_CAPS_GIGABIT_MODE_AVAILABLE |
MACB_CAPS_JUMBO |
MACB_CAPS_GEM_HAS_PTP | MACB_CAPS_BD_RD_PREFETCH,
.dma_burst_length = 16,
.clk_init = macb_clk_init,
- .init = macb_init,
+ .init = zynqmp_init,
.jumbo_max_len = 10240,
.usrio = &macb_default_usrio,
};
@@ -4767,7 +4820,7 @@ static int macb_probe(struct platform_device *pdev)
err = macb_mii_init(bp);
if (err)
- goto err_out_free_netdev;
+ goto err_out_phy_exit;
netif_carrier_off(dev);
@@ -4792,6 +4845,9 @@ static int macb_probe(struct platform_device *pdev)
mdiobus_unregister(bp->mii_bus);
mdiobus_free(bp->mii_bus);
+err_out_phy_exit:
+ phy_exit(bp->sgmii_phy);
+
err_out_free_netdev:
free_netdev(dev);
@@ -4813,6 +4869,7 @@ static int macb_remove(struct platform_device *pdev)
if (dev) {
bp = netdev_priv(dev);
+ phy_exit(bp->sgmii_phy);
mdiobus_unregister(bp->mii_bus);
mdiobus_free(bp->mii_bus);
--
2.31.1
^ permalink raw reply related
* [PATCH v1 2/3] nvmem: add driver for Layerscape SFP (Security Fuse Processor)
From: Michael Walle @ 2022-01-27 16:37 UTC (permalink / raw)
To: devicetree, linux-kernel, linux-arm-kernel
Cc: Srinivas Kandagatla, Rob Herring, Shawn Guo, Li Yang,
Michael Walle
In-Reply-To: <20220127163728.3650648-1-michael@walle.cc>
Add support for the Security Fuse Processor found on Layerscape SoCs.
This driver implements basic read access.
Signed-off-by: Michael Walle <michael@walle.cc>
---
drivers/nvmem/Kconfig | 12 +++++
drivers/nvmem/Makefile | 2 +
drivers/nvmem/layerscape-sfp.c | 91 ++++++++++++++++++++++++++++++++++
3 files changed, 105 insertions(+)
create mode 100644 drivers/nvmem/layerscape-sfp.c
diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
index 94dd60b2654e..63792082e476 100644
--- a/drivers/nvmem/Kconfig
+++ b/drivers/nvmem/Kconfig
@@ -307,4 +307,16 @@ config NVMEM_BRCM_NVRAM
This driver provides support for Broadcom's NVRAM that can be accessed
using I/O mapping.
+config NVMEM_LAYERSCAPE_SFP
+ tristate "Layerscape SFP (Security Fuse Processor) support"
+ depends on ARCH_LAYERSCAPE || COMPILE_TEST
+ depends on HAS_IOMEM
+ help
+ This driver provides support to read the eFuses on Freescale
+ Layerscape SoC's. For example, the vendor provides a per part
+ unique ID there.
+
+ This driver can also be built as a module. If so, the module
+ will be called layerscape-sfp.
+
endif
diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
index 4e6d877fdfaf..914358fcdb37 100644
--- a/drivers/nvmem/Makefile
+++ b/drivers/nvmem/Makefile
@@ -62,3 +62,5 @@ obj-$(CONFIG_NVMEM_RMEM) += nvmem-rmem.o
nvmem-rmem-y := rmem.o
obj-$(CONFIG_NVMEM_BRCM_NVRAM) += nvmem_brcm_nvram.o
nvmem_brcm_nvram-y := brcm_nvram.o
+obj-$(CONFIG_NVMEM_LAYERSCAPE_SFP) += nvmem-layerscape-sfp.o
+nvmem-layerscape-sfp-y := layerscape-sfp.o
diff --git a/drivers/nvmem/layerscape-sfp.c b/drivers/nvmem/layerscape-sfp.c
new file mode 100644
index 000000000000..4aa94e03d8d1
--- /dev/null
+++ b/drivers/nvmem/layerscape-sfp.c
@@ -0,0 +1,91 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Layerscape SFP driver
+ *
+ * Copyright (c) 2022 Michael Walle <michael@walle.cc>
+ *
+ */
+
+#include <linux/clk.h>
+#include <linux/device.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/nvmem-provider.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+#include <linux/delay.h>
+
+#define LAYERSCAPE_SFP_OTP_OFFSET 0x0200
+
+struct layerscape_sfp_priv {
+ void __iomem *base;
+};
+
+struct layerscape_sfp_data {
+ int size;
+};
+
+static int layerscape_sfp_read(void *context, unsigned int offset, void *val,
+ size_t bytes)
+{
+ struct layerscape_sfp_priv *priv = context;
+
+ memcpy_fromio(val, priv->base + LAYERSCAPE_SFP_OTP_OFFSET + offset, bytes);
+
+ return 0;
+}
+
+static struct nvmem_config layerscape_sfp_nvmem_config = {
+ .name = "fsl-sfp",
+ .reg_read = layerscape_sfp_read,
+};
+
+static int layerscape_sfp_probe(struct platform_device *pdev)
+{
+ const struct layerscape_sfp_data *data;
+ struct layerscape_sfp_priv *priv;
+ struct nvmem_device *nvmem;
+
+ priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ priv->base = devm_platform_ioremap_resource(pdev, 0);
+ if (IS_ERR(priv->base))
+ return PTR_ERR(priv->base);
+
+ data = device_get_match_data(&pdev->dev);
+
+ layerscape_sfp_nvmem_config.size = data->size;
+ layerscape_sfp_nvmem_config.dev = &pdev->dev;
+ layerscape_sfp_nvmem_config.priv = priv;
+
+ nvmem = devm_nvmem_register(&pdev->dev, &layerscape_sfp_nvmem_config);
+
+ return PTR_ERR_OR_ZERO(nvmem);
+}
+
+static const struct layerscape_sfp_data ls1028a_data = {
+ .size = 0x88,
+};
+
+static const struct of_device_id layerscape_sfp_dt_ids[] = {
+ { .compatible = "fsl,ls1028a-sfp", .data = &ls1028a_data },
+ {},
+};
+MODULE_DEVICE_TABLE(of, layerscape_sfp_dt_ids);
+
+static struct platform_driver layerscape_sfp_driver = {
+ .probe = layerscape_sfp_probe,
+ .driver = {
+ .name = "layerscape_sfp",
+ .of_match_table = layerscape_sfp_dt_ids,
+ },
+};
+module_platform_driver(layerscape_sfp_driver);
+
+MODULE_AUTHOR("Michael Walle <michael@walle.cc>");
+MODULE_DESCRIPTION("Layerscape Security Fuse Processor driver");
+MODULE_LICENSE("GPL v2");
--
2.30.2
^ permalink raw reply related
* [PATCH v1 1/3] dt-bindings: nvmem: add fsl,layerscape-sfp binding
From: Michael Walle @ 2022-01-27 16:37 UTC (permalink / raw)
To: devicetree, linux-kernel, linux-arm-kernel
Cc: Srinivas Kandagatla, Rob Herring, Shawn Guo, Li Yang,
Michael Walle
In-Reply-To: <20220127163728.3650648-1-michael@walle.cc>
The Security Fuse Processor provides efuses and is responsible for
reading it at SoC startup and configuring it accordingly.
Signed-off-by: Michael Walle <michael@walle.cc>
---
.../bindings/nvmem/fsl,layerscape-sfp.yaml | 38 +++++++++++++++++++
1 file changed, 38 insertions(+)
create mode 100644 Documentation/devicetree/bindings/nvmem/fsl,layerscape-sfp.yaml
diff --git a/Documentation/devicetree/bindings/nvmem/fsl,layerscape-sfp.yaml b/Documentation/devicetree/bindings/nvmem/fsl,layerscape-sfp.yaml
new file mode 100644
index 000000000000..80914b93638e
--- /dev/null
+++ b/Documentation/devicetree/bindings/nvmem/fsl,layerscape-sfp.yaml
@@ -0,0 +1,38 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/nvmem/fsl,layerscape-sfp.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Freescale Layerscape Security Fuse Processor
+
+maintainers:
+ - Michael Walle <michael@walle.cc>
+
+description: |
+ SFP is the security fuse processor which among other things provide a
+ unique identifier per part.
+
+allOf:
+ - $ref: "nvmem.yaml#"
+
+properties:
+ compatible:
+ enum:
+ - fsl,ls1028a-sfp
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ efuse@1e80000 {
+ compatible = "fsl,ls1028a-sfp";
+ reg = <0x1e80000 0x8000>;
+ };
--
2.30.2
^ permalink raw reply related
* [PATCH v1 0/3] nvmem: add Layerscape SFP support
From: Michael Walle @ 2022-01-27 16:37 UTC (permalink / raw)
To: devicetree, linux-kernel, linux-arm-kernel
Cc: Srinivas Kandagatla, Rob Herring, Shawn Guo, Li Yang,
Michael Walle
Add support for the Security Fuse Processor found on Layerscape
SoCs.
Michael Walle (3):
dt-bindings: nvmem: add fsl,layerscape-sfp binding
nvmem: add driver for Layerscape SFP (Security Fuse Processor)
arm64: dts: ls1028a: add efuse node
.../bindings/nvmem/fsl,layerscape-sfp.yaml | 38 ++++++++
.../arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 11 +++
drivers/nvmem/Kconfig | 12 +++
drivers/nvmem/Makefile | 2 +
drivers/nvmem/layerscape-sfp.c | 91 +++++++++++++++++++
5 files changed, 154 insertions(+)
create mode 100644 Documentation/devicetree/bindings/nvmem/fsl,layerscape-sfp.yaml
create mode 100644 drivers/nvmem/layerscape-sfp.c
--
2.30.2
^ permalink raw reply
* [PATCH v1 3/3] arm64: dts: ls1028a: add efuse node
From: Michael Walle @ 2022-01-27 16:37 UTC (permalink / raw)
To: devicetree, linux-kernel, linux-arm-kernel
Cc: Srinivas Kandagatla, Rob Herring, Shawn Guo, Li Yang,
Michael Walle
In-Reply-To: <20220127163728.3650648-1-michael@walle.cc>
Layerscape SoCs contain a Security Fuse Processor which is basically a
efuse controller. Add the node, so userspace can read the efuses.
Signed-off-by: Michael Walle <michael@walle.cc>
---
arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
index 7d44102d9c6c..4b248cee830a 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
@@ -224,6 +224,17 @@ rst: syscon@1e60000 {
little-endian;
};
+ efuse@1e80000 {
+ compatible = "fsl,ls1028a-sfp";
+ reg = <0x0 0x1e80000 0x0 0x10000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ ls1028a_uid: unique-id@1c {
+ reg = <0x1c 0x8>;
+ };
+ };
+
scfg: syscon@1fc0000 {
compatible = "fsl,ls1028a-scfg", "syscon";
reg = <0x0 0x1fc0000 0x0 0x10000>;
--
2.30.2
^ permalink raw reply related
* RE: [PATCH v16 2/4] dmaengine: tegra: Add tegra gpcdma driver
From: Akhil R @ 2022-01-27 16:29 UTC (permalink / raw)
To: Dmitry Osipenko, dan.j.williams@intel.com,
devicetree@vger.kernel.org, dmaengine@vger.kernel.org,
Jonathan Hunter, Krishna Yarlagadda, Laxman Dewangan,
linux-kernel@vger.kernel.org, linux-tegra@vger.kernel.org,
p.zabel@pengutronix.de, Rajesh Gumasta, robh+dt@kernel.org,
thierry.reding@gmail.com, vkoul@kernel.org
Cc: Pavan Kunapuli
In-Reply-To: <80a90a28-d9b8-1ba6-b79e-07fd49cc92b7@gmail.com>
> 23.01.2022 19:49, Akhil R пишет:
> >> 21.01.2022 19:24, Akhil R пишет:
> >>>>>>>>> +static int tegra_dma_terminate_all(struct dma_chan *dc) {
> >>>>>>>>> + struct tegra_dma_channel *tdc = to_tegra_dma_chan(dc);
> >>>>>>>>> + unsigned long flags;
> >>>>>>>>> + LIST_HEAD(head);
> >>>>>>>>> + int err;
> >>>>>>>>> +
> >>>>>>>>> + if (tdc->dma_desc) {
> >>>>>>>>
> >>>>>>>> Needs locking protection against racing with the interrupt handler.
> >>>>>>> tegra_dma_stop_client() waits for the in-flight transfer to
> >>>>>>> complete and prevents any additional transfer to start.
> >>>>>>> Wouldn't it manage the race? Do you see any potential issue there?
> >>>>>>
> >>>>>> You should consider interrupt handler like a process running in a
> >>>>>> parallel thread. The interrupt handler sets tdc->dma_desc to NULL,
> >>>>>> hence you'll get NULL dereference in tegra_dma_stop_client().
> >>>>>
> >>>>> Is it better if I remove the below part from tegra_dma_stop_client()
> >>>>> so that dma_desc is not accessed at all?
> >>>>>
> >>>>> + wcount = tdc_read(tdc, TEGRA_GPCDMA_CHAN_XFER_COUNT);
> >>>>> + tdc->dma_desc->bytes_transferred +=
> >>>>> + tdc->dma_desc->bytes_requested - (wcount * 4);
> >>>>>
> >>>>> Because I don't see a point in updating the value there. dma_desc is
> >>>>> set to NULL in the next step in terminate_all() anyway.
> >>>>
> >>>> That isn't going help you much because you also can't release DMA
> >>>> descriptor while interrupt handler still may be running and using
> >>>> that descriptor.
> >>>
> >>> Does the below functions look good to resolve the issue, provided
> >>> tegra_dma_stop_client() doesn't access dma_desc?
> >>
> >> Stop shall not race with the start.
> >>
> >>> +static int tegra_dma_terminate_all(struct dma_chan *dc) {
> >>> + struct tegra_dma_channel *tdc = to_tegra_dma_chan(dc);
> >>> + unsigned long flags;
> >>> + LIST_HEAD(head);
> >>> + int err;
> >>> +
> >>> + err = tegra_dma_stop_client(tdc);
> >>> + if (err)
> >>> + return err;
> >>> +
> >>> + tegra_dma_stop(tdc);
> >>> +
> >>> + spin_lock_irqsave(&tdc->vc.lock, flags);
> >>> + tegra_dma_sid_free(tdc);
> >>> + tdc->dma_desc = NULL;
> >>> +
> >>> + vchan_get_all_descriptors(&tdc->vc, &head);
> >>> + spin_unlock_irqrestore(&tdc->vc.lock, flags);
> >>> +
> >>> + vchan_dma_desc_free_list(&tdc->vc, &head);
> >>> +
> >>> + return 0;
> >>> +}
> >>>
> >>> +static irqreturn_t tegra_dma_isr(int irq, void *dev_id) {
> >>> + struct tegra_dma_channel *tdc = dev_id;
> >>> + struct tegra_dma_desc *dma_desc = tdc->dma_desc;
> >>> + struct tegra_dma_sg_req *sg_req;
> >>> + u32 status;
> >>> +
> >>> + /* Check channel error status register */
> >>> + status = tdc_read(tdc, TEGRA_GPCDMA_CHAN_ERR_STATUS);
> >>> + if (status) {
> >>> + tegra_dma_chan_decode_error(tdc, status);
> >>> + tegra_dma_dump_chan_regs(tdc);
> >>> + tdc_write(tdc, TEGRA_GPCDMA_CHAN_ERR_STATUS, 0xFFFFFFFF);
> >>> + }
> >>> +
> >>> + status = tdc_read(tdc, TEGRA_GPCDMA_CHAN_STATUS);
> >>> + if (!(status & TEGRA_GPCDMA_STATUS_ISE_EOC))
> >>> + return IRQ_HANDLED;
> >>> +
> >>> + tdc_write(tdc, TEGRA_GPCDMA_CHAN_STATUS,
> >>> + TEGRA_GPCDMA_STATUS_ISE_EOC);
> >>> +
> >>> + spin_lock(&tdc->vc.lock);
> >>> + if (!dma_desc)
> >> All checks and assignments must be done inside of critical section.
> >
> > Okay. So, the lock should be held throughout the function.
> > Do you think tegra_dma_pause should also hold a lock
> > and remove irq_synchronize? That function also writes
> > to CSR register.
>
> Interrupt handler shall not unpause channel in a case of race condition,
> it should handle completed transfer and check whether channel is paused
> before issuing next transfer.
> So yes, pause also needs a lock.
Thanks for the points. I collected more details on this scenario and found that
DMA can only be paused if there is an in-flight transfer (i.e no interrupt will be
pending). And there cannot be an interrupt after DMA is paused. Hence, there
is no case of ISR unpausing a paused transfer. So, I guess, the check or a lock
might not be required there.
One thing I am thinking of is to wait for DMA to be busy so that it can be paused.
I would add these changes and send out a new patch.
Thanks,
Akhil
^ permalink raw reply
* Re: [PATCH] ASoC: dt-bindings: Centralize the 'sound-dai' definition
From: Jerome Brunet @ 2022-01-27 16:20 UTC (permalink / raw)
To: Rob Herring
Cc: Liam Girdwood, Mark Brown, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, NXP Linux Team,
Andy Gross, Bjorn Andersson, Krzysztof Kozlowski,
Sylwester Nawrocki, Rohit kumar, Cheng-Yi Chiang, Shengjiu Wang,
Srinivas Kandagatla, Jonathan Bakker, Krzysztof Kozlowski,
Linux-ALSA, devicetree, linux-kernel@vger.kernel.org,
linux-arm-kernel, linux-arm-msm
In-Reply-To: <CAL_JsqL77E+5ftqgHPdWQzfp98Oh3d=QZRQ8Z6v91OfSeprxig@mail.gmail.com>
On Thu 27 Jan 2022 at 08:35, Rob Herring <robh@kernel.org> wrote:
> On Thu, Jan 27, 2022 at 3:05 AM Jerome Brunet <jbrunet@baylibre.com> wrote:
>>
>>
>> On Wed 26 Jan 2022 at 17:14, Rob Herring <robh@kernel.org> wrote:
>>
>> > 'sound-dai' is a common property, but has duplicate type definitions.
>> > Create a new common definition to define the type and then update all
>> > the other occurrences to just define how many entries there are just
>> > like other phandle+arg properties.
>> >
>> > The constraints on the number of entries is based on the examples and
>> > could be wrong.
>> >
>> > Cc: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
>> > Signed-off-by: Rob Herring <robh@kernel.org>
>> > ---
>> > Please ack, this depends on commit abf0fee97313 ("dt-bindings: Improve
>> > phandle-array schemas") in my tree.
>> > ---
>> > .../bindings/sound/amlogic,gx-sound-card.yaml | 4 ++--
>> > .../bindings/sound/google,sc7180-trogdor.yaml | 6 ++++--
>> > .../bindings/sound/imx-audio-card.yaml | 7 +++++--
>> > .../bindings/sound/qcom,sm8250.yaml | 10 +++++++---
>> > .../bindings/sound/samsung,aries-wm8994.yaml | 5 +----
>> > .../bindings/sound/samsung,midas-audio.yaml | 2 --
>> > .../bindings/sound/samsung,odroid.yaml | 9 +++------
>> > .../devicetree/bindings/sound/sound-dai.yaml | 20 +++++++++++++++++++
>> > 8 files changed, 42 insertions(+), 21 deletions(-)
>> > create mode 100644 Documentation/devicetree/bindings/sound/sound-dai.yaml
>> >
>> > diff --git a/Documentation/devicetree/bindings/sound/amlogic,gx-sound-card.yaml b/Documentation/devicetree/bindings/sound/amlogic,gx-sound-card.yaml
>> > index 2e35aeaa8781..8b5be4b92f35 100644
>> > --- a/Documentation/devicetree/bindings/sound/amlogic,gx-sound-card.yaml
>> > +++ b/Documentation/devicetree/bindings/sound/amlogic,gx-sound-card.yaml
>> > @@ -57,7 +57,7 @@ patternProperties:
>> > rate
>> >
>> > sound-dai:
>> > - $ref: /schemas/types.yaml#/definitions/phandle-array
>> > + maxItems: 1
>> > description: phandle of the CPU DAI
>> >
>> > patternProperties:
>> > @@ -71,7 +71,7 @@ patternProperties:
>> >
>> > properties:
>> > sound-dai:
>> > - $ref: /schemas/types.yaml#/definitions/phandle-array
>> > + maxItems: 1
>>
>> No min or max here. Links may have more than one codec.
>>
>> Ex:
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/amlogic/meson-gxl-s905x-libretech-cc.dts#n158
>
> What do you mean? Every 'sound-dai' there only has 1 phande+args. Each
> codec is a child node.
Yes it is a child - sorry I misunderstood.
I thought the MaxItems: 1 would limit the number of codecs
For the amlogic part:
Acked-by: Jerome Brunet <jbrunet@baylibre.com>
>
> Rob
^ permalink raw reply
* [PATCH v4 3/4] dt-bindings: hwmon: Add binding for max6639
From: Marcello Sylvester Bauer @ 2022-01-27 16:17 UTC (permalink / raw)
To: linux-hwmon
Cc: Marcello Sylvester Bauer, Patrick Rudolph, Jean Delvare,
Guenter Roeck, Rob Herring, Roland Stigge, devicetree
In-Reply-To: <cover.1643299570.git.sylv@sylv.io>
Add Devicetree binding documentation for Maxim MAX6639 temperature
monitor with PWM fan-speed controller.
The devicetree documentation for the SD3078 device tree.
Signed-off-by: Marcello Sylvester Bauer <sylv@sylv.io>
---
.../bindings/hwmon/maxim,max6639.yaml | 112 ++++++++++++++++++
1 file changed, 112 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwmon/maxim,max6639.yaml
diff --git a/Documentation/devicetree/bindings/hwmon/maxim,max6639.yaml b/Documentation/devicetree/bindings/hwmon/maxim,max6639.yaml
new file mode 100644
index 000000000000..570e9fe07503
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/maxim,max6639.yaml
@@ -0,0 +1,112 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+
+$id: http://devicetree.org/schemas/hwmon/maxim,max6639.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Maxim max6639
+
+maintainers:
+ - Roland Stigge <stigge@antcom.de>
+
+description: |
+ The MAX6639 is a 2-channel temperature monitor with dual, automatic, PWM
+ fan-speed controller. It monitors its own temperature and one external
+ diode-connected transistor or the temperatures of two external diode-connected
+ transistors, typically available in CPUs, FPGAs, or GPUs.
+
+ Datasheets:
+ https://datasheets.maximintegrated.com/en/ds/MAX6639-MAX6639F.pdf
+
+properties:
+ compatible:
+ enum:
+ - maxim,max6639
+
+ reg:
+ maxItems: 1
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+required:
+ - compatible
+ - reg
+ - "channel@0"
+ - "channel@1"
+
+additionalProperties: false
+
+patternProperties:
+ "^channel@[0-1]$":
+ type: object
+ description: |
+ Represents the two fans and their specific configuration.
+
+ properties:
+ reg:
+ description: |
+ The fan number.
+ items:
+ minimum: 0
+ maximum: 1
+
+ pwm-polarity:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [0, 1]
+ default: 1
+ description:
+ PWM output is low at 100% duty cycle when this bit is set to zero. PWM
+ output is high at 100% duty cycle when this bit is set to 1.
+
+ pulses-per-revolution:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [1, 2, 3, 4]
+ default: 2
+ description:
+ Value specifying the number of pulses per revolution of the controlled
+ FAN.
+
+ rpm-max:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ enum: [2000, 4000, 8000, 16000]
+ default: 4000
+ description:
+ Scales the tachometer counter by setting the maximum (full-scale) value
+ of the RPM range.
+
+ required:
+ - reg
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ max6639@10 {
+ compatible = "maxim,max6639";
+ reg = <0x10>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ channel@0 {
+ reg = <0x0>;
+ pwm-polarity = <1>;
+ pulses-per-revolution = <2>;
+ rpm-range = <4000>;
+ };
+
+ channel@1 {
+ reg = <0x1>;
+ pwm-polarity = <1>;
+ pulses-per-revolution = <2>;
+ rpm-range = <4000>;
+ };
+ };
+ };
+...
--
2.34.1
^ permalink raw reply related
* [RESEND PATCH v5 2/2] arm64: dts: imx8mm: Add support for emtrion emCON-MX8M Mini
From: reinhold.mueller @ 2022-01-27 15:35 UTC (permalink / raw)
To: festevam
Cc: robh+dt, s.hauer, kernel, shawnguo, linux-imx, devicetree,
linux-kernel, reinhold.mueller
In-Reply-To: <20220127153500.9236-1-reinhold.mueller@emtrion.com>
From: Reinhold Mueller <reinhold.mueller@emtrion.com>
This patch adds support for the emtrion GmbH emCON-MX8M Mini modules.
They are available with NXP i.MX 8M Mini equipped with 2 or 4 GB Memory.
The devicetree imx8mm-emcon.dtsi is the common part providing all
module components and the basic support for the SoC. The support for the
avari baseboard in the developer-kit configuration is provided by the
emcon-avari dts files.
Signed-off-by: Reinhold Mueller <reinhold.mueller@emtrion.com>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
---
arch/arm64/boot/dts/freescale/Makefile | 3 +-
.../boot/dts/freescale/imx8mm-emcon-avari.dts | 23 +
.../dts/freescale/imx8mm-emcon-avari.dtsi | 139 ++++
.../boot/dts/freescale/imx8mm-emcon.dtsi | 627 ++++++++++++++++++
4 files changed, 791 insertions(+), 1 deletion(-)
create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-emcon-avari.dts
create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-emcon-avari.dtsi
create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-emcon.dtsi
diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index a14a6173b765..a09b5e4d5a45 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -34,8 +34,9 @@ dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-lx2160a-rdb.dtb
dtb-$(CONFIG_ARCH_LAYERSCAPE) += fsl-lx2162a-qds.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mm-beacon-kit.dtb
-dtb-$(CONFIG_ARCH_MXC) += imx8mm-evk.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mm-ddr4-evk.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx8mm-emcon-avari.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx8mm-evk.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mm-icore-mx8mm-ctouch2.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mm-icore-mx8mm-edimm2.2.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mm-kontron-n801x-s.dtb
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-emcon-avari.dts b/arch/arm64/boot/dts/freescale/imx8mm-emcon-avari.dts
new file mode 100644
index 000000000000..b2e8967e9687
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mm-emcon-avari.dts
@@ -0,0 +1,23 @@
+// SPDX-License-Identifier: (GPL-2.0 or MIT)
+//
+// Copyright (c) 2021 emtrion GmbH
+// Author: Frank Erdrich <frank.erdrich@emtrion.com>
+//
+
+/dts-v1/;
+
+#include "imx8mm-emcon.dtsi"
+#include "imx8mm-emcon-avari.dtsi"
+
+/ {
+ model = "emtrion SoM emCON-MX8M mini on Avari";
+ compatible = "emtrion,emcon-mx8mm-avari", "fsl,imx8mm";
+};
+
+&lvds_backlight {
+ status = "okay";
+};
+
+&pwm1 {
+ status = "okay";
+};
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-emcon-avari.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-emcon-avari.dtsi
new file mode 100644
index 000000000000..5028f232b6bd
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mm-emcon-avari.dtsi
@@ -0,0 +1,139 @@
+// SPDX-License-Identifier: (GPL-2.0 or MIT)
+//
+// Copyright (C) 2021 emtrion GmbH
+// Author: Frank Erdrich <frank.erdrich@emtrion.com>
+//
+
+/ {
+ aliases {
+ boardid = &boardID;
+ mmc0 = &usdhc1;
+ mmc1 = &usdhc2;
+ };
+
+ chosen {
+ stdout-path = &uart1;
+ };
+
+ reg_wall_5p0: regulator-wall5p0 {
+ compatible = "regulator-fixed";
+ regulator-name = "Main-Supply";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ reg_base3p3: regulator-base3p3 {
+ compatible = "regulator-fixed";
+ vin-supply = <®_wall_5p0>;
+ regulator-name = "3V3-avari";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ reg_base1p5: regulator-base1p5 {
+ compatible = "regulator-fixed";
+ vin-supply = <®_base3p3>;
+ regulator-name = "1V5-avari";
+ regulator-min-microvolt = <1500000>;
+ regulator-max-microvolt = <1500000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ reg_usb_otg: regulator-otgvbus {
+ compatible = "regulator-fixed";
+ vin-supply = <®_wall_5p0>;
+ regulator-name = "OTG_VBUS";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ gpio = <&gpio1 8 GPIO_ACTIVE_LOW>;
+ regulator-always-on;
+ };
+
+ clk_codec: clock-codec {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <12000000>;
+ };
+
+ sound {
+ compatible = "simple-audio-card";
+ simple-audio-card,name = "SGTL5000-Card";
+ simple-audio-card,format = "i2s";
+ simple-audio-card,bitclock-master = <&codec_dai>;
+ simple-audio-card,frame-master = <&codec_dai>;
+ simple-audio-card,widgets = "Headphone", "Headphone Jack";
+ simple-audio-card,routing = "Headphone Jack", "HP_OUT";
+
+ cpu_dai: simple-audio-card,cpu {
+ sound-dai = <&sai2>;
+ };
+
+ codec_dai: simple-audio-card,codec {
+ sound-dai = <&sgtl5000>;
+ };
+ };
+};
+
+&ecspi1 {
+ status = "okay";
+};
+
+&i2c2 {
+ status = "okay";
+};
+
+&i2c1 {
+ clock-frequency = <100000>;
+ status = "okay";
+
+ sgtl5000: audio-codec@a {
+ compatible = "fsl,sgtl5000";
+ reg = <0x0a>;
+ #sound-dai-cells = <0>;
+ clocks = <&clk_codec>;
+ VDDA-supply = <®_base3p3>;
+ VDDIO-supply = <®_base3p3>;
+ };
+
+ boardID: gpio@3a {
+ compatible = "nxp,pca8574";
+ reg = <0x3a>;
+ gpio-controller;
+ #gpio-cells = <1>;
+ };
+};
+
+&sai2 {
+ status = "okay";
+};
+
+&uart2 {
+ uart-has-rtscts;
+ status = "okay";
+};
+
+&uart3 {
+ status = "okay";
+};
+
+&uart4 {
+ status = "okay";
+};
+
+&usbotg1 {
+ status = "okay";
+};
+
+&usbotg2 {
+ dr_mode = "host";
+ status = "disabled";
+};
+
+&usdhc2 {
+ status = "okay";
+};
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-emcon.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-emcon.dtsi
new file mode 100644
index 000000000000..7c4af71baab9
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mm-emcon.dtsi
@@ -0,0 +1,627 @@
+// SPDX-License-Identifier: (GPL-2.0 or MIT)
+//
+// Copyright 2018 NXP
+// Copyright (C) 2021 emtrion GmbH
+//
+
+/dts-v1/;
+
+#include "imx8mm.dtsi"
+
+/ {
+ chosen {
+ stdout-path = &uart1;
+ };
+
+ som_leds: leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio_led>;
+
+ green {
+ label = "som:green";
+ gpios = <&gpio3 4 GPIO_ACTIVE_HIGH>;
+ default-state = "on";
+ linux,default-trigger = "heartbeat";
+ };
+
+ red {
+ label = "som:red";
+ gpios = <&gpio5 10 GPIO_ACTIVE_HIGH>;
+ default-state = "off";
+ };
+ };
+
+ lvds_backlight: lvds-backlight {
+ compatible = "pwm-backlight";
+ enable-gpios = <&gpio3 23 GPIO_ACTIVE_HIGH>;
+ pwms = <&pwm1 0 50000 0>;
+ brightness-levels = <
+ 0 4 8 16 32 64 80 96 112
+ 128 144 160 176 250
+ >;
+ default-brightness-level = <9>;
+ status = "disabled";
+ };
+
+ reg_usdhc1_vmmc: regulator-emmc {
+ compatible = "regulator-fixed";
+ regulator-name = "eMMC";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ reg_usdhc2_vmmc: regulator-usdhc2 {
+ compatible = "regulator-fixed";
+ regulator-name = "sdcard_3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
+};
+
+&A53_0 {
+ cpu-supply = <&buck2_reg>;
+};
+
+&ecspi1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ecspi1 &pinctrl_ecspi1_cs>;
+ cs-gpios = <&gpio5 9 GPIO_ACTIVE_LOW>,
+ <&gpio5 13 GPIO_ACTIVE_LOW>;
+ status = "okay";
+};
+
+&fec1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_fec1>;
+ phy-mode = "rgmii-id";
+ phy-handle = <ðphy0>;
+ fsl,magic-packet;
+ status = "okay";
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethphy0: ethernet-phy@0 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <0>;
+ reset-gpios = <&gpio1 9 GPIO_ACTIVE_LOW>;
+ reset-assert-us = <10000>;
+ };
+ };
+};
+
+&flexspi {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_flexspi0>;
+ pinctrl-1 = <&pinctrl_flexspi1>;
+ status = "okay";
+
+ flash0: spi-flash@0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "jedec,spi-nor";
+ spi-max-frequency = <40000000>;
+ };
+};
+
+&iomuxc {
+ pinctrl-names = "default";
+
+ pinctrl_csi_pwn: csi-pwn-grp {
+ fsl,pins = <
+ MX8MM_IOMUXC_GPIO1_IO07_GPIO1_IO7 0x19
+ >;
+ };
+
+ pinctrl_ecspi1: ecspi1-grp {
+ fsl,pins = <
+ MX8MM_IOMUXC_ECSPI1_SCLK_ECSPI1_SCLK 0x82
+ MX8MM_IOMUXC_ECSPI1_MOSI_ECSPI1_MOSI 0x82
+ MX8MM_IOMUXC_ECSPI1_MISO_ECSPI1_MISO 0x82
+ >;
+ };
+
+ pinctrl_ecspi1_cs: ecspi1-cs {
+ fsl,pins = <
+ MX8MM_IOMUXC_ECSPI1_SS0_GPIO5_IO9 0x40000
+ MX8MM_IOMUXC_ECSPI2_SS0_GPIO5_IO13 0x40000
+ >;
+ };
+
+ pinctrl_fec1: fec1-grp {
+ fsl,pins = <
+ MX8MM_IOMUXC_ENET_MDC_ENET1_MDC 0x3
+ MX8MM_IOMUXC_ENET_MDIO_ENET1_MDIO 0x3
+ MX8MM_IOMUXC_ENET_TD3_ENET1_RGMII_TD3 0x1f
+ MX8MM_IOMUXC_ENET_TD2_ENET1_RGMII_TD2 0x1f
+ MX8MM_IOMUXC_ENET_TD1_ENET1_RGMII_TD1 0x1f
+ MX8MM_IOMUXC_ENET_TD0_ENET1_RGMII_TD0 0x1f
+ MX8MM_IOMUXC_ENET_RD3_ENET1_RGMII_RD3 0x91
+ MX8MM_IOMUXC_ENET_RD2_ENET1_RGMII_RD2 0x91
+ MX8MM_IOMUXC_ENET_RD1_ENET1_RGMII_RD1 0x91
+ MX8MM_IOMUXC_ENET_RD0_ENET1_RGMII_RD0 0x91
+ MX8MM_IOMUXC_ENET_TXC_ENET1_RGMII_TXC 0x1f
+ MX8MM_IOMUXC_ENET_RXC_ENET1_RGMII_RXC 0x91
+ MX8MM_IOMUXC_ENET_RX_CTL_ENET1_RGMII_RX_CTL 0x91
+ MX8MM_IOMUXC_ENET_TX_CTL_ENET1_RGMII_TX_CTL 0x1f
+ MX8MM_IOMUXC_GPIO1_IO09_GPIO1_IO9 0x19
+ >;
+ };
+
+ pinctrl_flexspi0: flexspi0-grp {
+ fsl,pins = <
+ MX8MM_IOMUXC_NAND_ALE_QSPI_A_SCLK 0x1c2
+ MX8MM_IOMUXC_NAND_CE0_B_QSPI_A_SS0_B 0x82
+ MX8MM_IOMUXC_NAND_DATA00_QSPI_A_DATA0 0x82
+ MX8MM_IOMUXC_NAND_DATA01_QSPI_A_DATA1 0x82
+ MX8MM_IOMUXC_NAND_DATA02_QSPI_A_DATA2 0x82
+ MX8MM_IOMUXC_NAND_DATA03_QSPI_A_DATA3 0x82
+ MX8MM_IOMUXC_NAND_DQS_QSPI_A_DQS 0x82
+ >;
+ };
+
+ pinctrl_flexspi1: flexspi1-grp {
+ fsl,pins = <
+ MX8MM_IOMUXC_NAND_CLE_QSPI_B_SCLK 0x1c2
+ MX8MM_IOMUXC_NAND_CE2_B_QSPI_B_SS0_B 0x82
+ MX8MM_IOMUXC_NAND_DATA04_QSPI_B_DATA0 0x82
+ MX8MM_IOMUXC_NAND_DATA05_QSPI_B_DATA1 0x82
+ MX8MM_IOMUXC_NAND_DATA06_QSPI_B_DATA2 0x82
+ MX8MM_IOMUXC_NAND_DATA07_QSPI_B_DATA3 0x82
+ >;
+ };
+
+ pinctrl_gpio_led: gpio-led-grp {
+ fsl,pins = <
+ MX8MM_IOMUXC_ECSPI2_SCLK_GPIO5_IO10 0x19
+ MX8MM_IOMUXC_NAND_CE3_B_GPIO3_IO4 0x19
+ >;
+ };
+
+ pinctrl_i2c1: i2c1-grp {
+ fsl,pins = <
+ MX8MM_IOMUXC_I2C1_SCL_I2C1_SCL 0x400001c3
+ MX8MM_IOMUXC_I2C1_SDA_I2C1_SDA 0x400001c3
+ >;
+ };
+
+ pinctrl_i2c2: i2c2grp {
+ fsl,pins = <
+ MX8MM_IOMUXC_I2C2_SCL_I2C2_SCL 0x400001c3
+ MX8MM_IOMUXC_I2C2_SDA_I2C2_SDA 0x400001c3
+ >;
+ };
+
+ pinctrl_i2c3: i2c3-grp {
+ fsl,pins = <
+ MX8MM_IOMUXC_I2C3_SCL_I2C3_SCL 0x400001c3
+ MX8MM_IOMUXC_I2C3_SDA_I2C3_SDA 0x400001c3
+ >;
+ };
+
+ pinctrl_lvds: lvds-grp {
+ fsl,pins = <
+ MX8MM_IOMUXC_SAI5_MCLK_GPIO3_IO25 0x06
+ >;
+ };
+
+ pinctrl_pcie0: pcie0-grp {
+ fsl,pins = <
+ MX8MM_IOMUXC_SAI5_RXC_GPIO3_IO20 0x41
+ MX8MM_IOMUXC_SAI5_RXFS_GPIO3_IO19 0x41
+ >;
+ };
+
+ pinctrl_pmic: pmic-irq {
+ fsl,pins = <
+ MX8MM_IOMUXC_NAND_CE1_B_GPIO3_IO2 0x41
+ >;
+ };
+
+ pinctrl_pwm1: pwm1-grp {
+ fsl,pins = <
+ MX8MM_IOMUXC_GPIO1_IO01_PWM1_OUT 0x06
+ >;
+ };
+
+ pinctrl_sai2: sai2-grp {
+ fsl,pins = <
+ MX8MM_IOMUXC_SAI2_MCLK_SAI2_MCLK 0xd6
+ MX8MM_IOMUXC_SAI2_RXC_SAI2_RX_BCLK 0xd6
+ MX8MM_IOMUXC_SAI2_RXD0_SAI2_RX_DATA0 0xd6
+ MX8MM_IOMUXC_SAI2_RXFS_SAI2_RX_SYNC 0xd6
+ MX8MM_IOMUXC_SAI2_TXC_SAI2_TX_BCLK 0xd6
+ MX8MM_IOMUXC_SAI2_TXD0_SAI2_TX_DATA0 0xd6
+ MX8MM_IOMUXC_SAI2_TXFS_SAI2_TX_SYNC 0xd6
+ >;
+ };
+
+ pinctrl_spdif1: spdif1-grp {
+ fsl,pins = <
+ MX8MM_IOMUXC_SPDIF_TX_SPDIF1_OUT 0xd6
+ MX8MM_IOMUXC_SPDIF_RX_SPDIF1_IN 0xd6
+ >;
+ };
+
+ pinctrl_uart1: uart1-grp {
+ fsl,pins = <
+ MX8MM_IOMUXC_UART1_RXD_UART1_DCE_RX 0x140
+ MX8MM_IOMUXC_UART1_TXD_UART1_DCE_TX 0x140
+ >;
+ };
+
+ pinctrl_uart2: uart2-grp {
+ fsl,pins = <
+ MX8MM_IOMUXC_UART2_RXD_UART2_DCE_RX 0x140
+ MX8MM_IOMUXC_UART2_TXD_UART2_DCE_TX 0x140
+
+ /* rts and cts */
+ MX8MM_IOMUXC_SAI3_RXC_UART2_DCE_CTS_B 0x140
+ MX8MM_IOMUXC_SAI3_RXD_UART2_DCE_RTS_B 0x140
+ >;
+ };
+
+ pinctrl_uart3: uart3-grp {
+ fsl,pins = <
+ MX8MM_IOMUXC_UART3_RXD_UART3_DCE_RX 0x140
+ MX8MM_IOMUXC_UART3_TXD_UART3_DCE_TX 0x140
+ >;
+ };
+
+ pinctrl_uart4: uart4-grp {
+ fsl,pins = <
+ MX8MM_IOMUXC_UART4_RXD_UART4_DCE_RX 0x140
+ MX8MM_IOMUXC_UART4_TXD_UART4_DCE_TX 0x140
+ >;
+ };
+
+ pinctrl_usdhc1: usdhc1-grp {
+ fsl,pins = <
+ MX8MM_IOMUXC_SD1_CLK_USDHC1_CLK 0x190
+ MX8MM_IOMUXC_SD1_CMD_USDHC1_CMD 0x1d0
+ MX8MM_IOMUXC_SD1_DATA0_USDHC1_DATA0 0x1d0
+ MX8MM_IOMUXC_SD1_DATA1_USDHC1_DATA1 0x1d0
+ MX8MM_IOMUXC_SD1_DATA2_USDHC1_DATA2 0x1d0
+ MX8MM_IOMUXC_SD1_DATA3_USDHC1_DATA3 0x1d0
+ MX8MM_IOMUXC_SD1_DATA4_USDHC1_DATA4 0x1d0
+ MX8MM_IOMUXC_SD1_DATA5_USDHC1_DATA5 0x1d0
+ MX8MM_IOMUXC_SD1_DATA6_USDHC1_DATA6 0x1d0
+ MX8MM_IOMUXC_SD1_DATA7_USDHC1_DATA7 0x1d0
+ >;
+ };
+
+ pinctrl_usdhc1_100mhz: usdhc1-100mhz-grp {
+ fsl,pins = <
+ MX8MM_IOMUXC_SD1_CLK_USDHC1_CLK 0x194
+ MX8MM_IOMUXC_SD1_CMD_USDHC1_CMD 0x1d4
+ MX8MM_IOMUXC_SD1_DATA0_USDHC1_DATA0 0x1d4
+ MX8MM_IOMUXC_SD1_DATA1_USDHC1_DATA1 0x1d4
+ MX8MM_IOMUXC_SD1_DATA2_USDHC1_DATA2 0x1d4
+ MX8MM_IOMUXC_SD1_DATA3_USDHC1_DATA3 0x1d4
+ MX8MM_IOMUXC_SD1_DATA4_USDHC1_DATA4 0x1d4
+ MX8MM_IOMUXC_SD1_DATA5_USDHC1_DATA5 0x1d4
+ MX8MM_IOMUXC_SD1_DATA6_USDHC1_DATA6 0x1d4
+ MX8MM_IOMUXC_SD1_DATA7_USDHC1_DATA7 0x1d4
+ >;
+ };
+
+ pinctrl_usdhc1_200mhz: usdhc1-200mhz-grp {
+ fsl,pins = <
+ MX8MM_IOMUXC_SD1_CLK_USDHC1_CLK 0x196
+ MX8MM_IOMUXC_SD1_CMD_USDHC1_CMD 0x1d6
+ MX8MM_IOMUXC_SD1_DATA0_USDHC1_DATA0 0x1d6
+ MX8MM_IOMUXC_SD1_DATA1_USDHC1_DATA1 0x1d6
+ MX8MM_IOMUXC_SD1_DATA2_USDHC1_DATA2 0x1d6
+ MX8MM_IOMUXC_SD1_DATA3_USDHC1_DATA3 0x1d6
+ MX8MM_IOMUXC_SD1_DATA4_USDHC1_DATA4 0x1d6
+ MX8MM_IOMUXC_SD1_DATA5_USDHC1_DATA5 0x1d6
+ MX8MM_IOMUXC_SD1_DATA6_USDHC1_DATA6 0x1d6
+ MX8MM_IOMUXC_SD1_DATA7_USDHC1_DATA7 0x1d6
+ >;
+ };
+
+ pinctrl_usdhc1_gpio: usdhc1-gpio-grp {
+ fsl,pins = <
+ MX8MM_IOMUXC_SD1_RESET_B_USDHC1_RESET_B 0x41
+ MX8MM_IOMUXC_GPIO1_IO03_GPIO1_IO3 0x1c4
+ >;
+ };
+
+ pinctrl_usdhc2: usdhc2-grp {
+ fsl,pins = <
+ MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK 0x190
+ MX8MM_IOMUXC_SD2_CMD_USDHC2_CMD 0x1d0
+ MX8MM_IOMUXC_SD2_DATA0_USDHC2_DATA0 0x1d0
+ MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1 0x1d0
+ MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 0x1d0
+ MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 0x1d0
+ MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x1d0
+ >;
+ };
+
+ pinctrl_usdhc2_100mhz: usdhc2-100mhz-grp {
+ fsl,pins = <
+ MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK 0x194
+ MX8MM_IOMUXC_SD2_CMD_USDHC2_CMD 0x1d4
+ MX8MM_IOMUXC_SD2_DATA0_USDHC2_DATA0 0x1d4
+ MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1 0x1d4
+ MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 0x1d4
+ MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 0x1d4
+ MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x1d0
+ >;
+ };
+
+ pinctrl_usdhc2_200mhz: usdhc2-200mhz-grp {
+ fsl,pins = <
+ MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK 0x196
+ MX8MM_IOMUXC_SD2_CMD_USDHC2_CMD 0x1d6
+ MX8MM_IOMUXC_SD2_DATA0_USDHC2_DATA0 0x1d6
+ MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1 0x1d6
+ MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 0x1d6
+ MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 0x1d6
+ MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x1d0
+ >;
+ };
+
+ /* no reset for sdhc2 interface */
+ pinctrl_usdhc2_gpio: usdhc2-gpio-grp {
+ fsl,pins = <
+ MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12 0x1c4
+ MX8MM_IOMUXC_SD2_WP_USDHC2_WP 0x1c4
+ >;
+ };
+
+ pinctrl_wdog: wdog-grp {
+ fsl,pins = <
+ MX8MM_IOMUXC_GPIO1_IO02_WDOG1_WDOG_B 0xc6
+ >;
+ };
+};
+
+&i2c1 {
+ clock-frequency = <400000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c1>;
+ status = "okay";
+};
+
+&i2c2 {
+ clock-frequency = <400000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c2>;
+ status = "okay";
+};
+
+&i2c3 {
+ clock-frequency = <400000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c3>;
+ status = "okay";
+
+ bd71847: pmic@4b {
+ compatible = "rohm,bd71847";
+ reg = <0x4b>;
+ pinctrl-0 = <&pinctrl_pmic>;
+ interrupt-parent = <&gpio3>;
+ interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
+ rohm,reset-snvs-powered;
+
+ regulators {
+ buck1_reg: BUCK1 {
+ regulator-name = "BUCK1";
+ regulator-min-microvolt = <700000>;
+ regulator-max-microvolt = <1300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-ramp-delay = <1250>;
+ };
+
+ buck2_reg: BUCK2 {
+ regulator-name = "BUCK2";
+ regulator-min-microvolt = <700000>;
+ regulator-max-microvolt = <1300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-ramp-delay = <1250>;
+ rohm,dvs-run-voltage = <1000000>;
+ rohm,dvs-idle-voltage = <900000>;
+ };
+
+ buck3_reg: BUCK3 {
+ // BUCK5 in datasheet
+ regulator-name = "BUCK3";
+ regulator-min-microvolt = <700000>;
+ regulator-max-microvolt = <1350000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ buck4_reg: BUCK4 {
+ // BUCK6 in datasheet
+ regulator-name = "BUCK4";
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ buck5_reg: BUCK5 {
+ // BUCK7 in datasheet
+ regulator-name = "BUCK5";
+ regulator-min-microvolt = <1605000>;
+ regulator-max-microvolt = <1995000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ buck6_reg: BUCK6 {
+ // BUCK8 in datasheet
+ regulator-name = "BUCK6";
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <1400000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo1_reg: LDO1 {
+ regulator-name = "LDO1";
+ regulator-min-microvolt = <1600000>;
+ regulator-max-microvolt = <1900000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo2_reg: LDO2 {
+ regulator-name = "LDO2";
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <900000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo3_reg: LDO3 {
+ regulator-name = "LDO3";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo4_reg: LDO4 {
+ regulator-name = "LDO4";
+ regulator-min-microvolt = <900000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo6_reg: LDO6 {
+ regulator-name = "LDO6";
+ regulator-min-microvolt = <900000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ };
+ };
+
+ rv1805: rtc@69 {
+ compatible = "abracon,ab1805";
+ reg = <0x69>;
+ };
+};
+
+&mu {
+ status = "okay";
+};
+
+&pwm1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pwm1>;
+};
+
+&sai2 {
+ #sound-dai-cells = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_sai2>;
+ assigned-clocks = <&clk IMX8MM_CLK_SAI2>;
+ assigned-clock-parents = <&clk IMX8MM_AUDIO_PLL1_OUT>;
+ assigned-clock-rates = <12000000>;
+ status = "disabled";
+};
+
+&spdif1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_spdif1>;
+ assigned-clocks = <&clk IMX8MM_CLK_SPDIF1>;
+ assigned-clock-parents = <&clk IMX8MM_AUDIO_PLL1_OUT>;
+ assigned-clock-rates = <24576000>;
+ clocks = <&clk IMX8MM_CLK_AUDIO_AHB>, <&clk IMX8MM_CLK_24M>,
+ <&clk IMX8MM_CLK_SPDIF1>, <&clk IMX8MM_CLK_DUMMY>,
+ <&clk IMX8MM_CLK_DUMMY>, <&clk IMX8MM_CLK_DUMMY>,
+ <&clk IMX8MM_CLK_AUDIO_AHB>, <&clk IMX8MM_CLK_DUMMY>,
+ <&clk IMX8MM_CLK_DUMMY>, <&clk IMX8MM_CLK_DUMMY>,
+ <&clk IMX8MM_AUDIO_PLL1_OUT>, <&clk IMX8MM_AUDIO_PLL2_OUT>;
+ clock-names = "core", "rxtx0", "rxtx1", "rxtx2", "rxtx3",
+ "rxtx4", "rxtx5", "rxtx6", "rxtx7", "spba", "pll8k", "pll11k";
+ status = "disabled";
+};
+
+&uart1 { /* console */
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart1>;
+ assigned-clocks = <&clk IMX8MM_CLK_UART1>;
+ assigned-clock-parents = <&clk IMX8MM_SYS_PLL1_80M>;
+ status = "okay";
+};
+
+&uart2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart2>;
+ assigned-clocks = <&clk IMX8MM_CLK_UART2>;
+ assigned-clock-parents = <&clk IMX8MM_SYS_PLL1_80M>;
+ status = "okay";
+};
+
+&uart3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart3>;
+ assigned-clocks = <&clk IMX8MM_CLK_UART3>;
+ assigned-clock-parents = <&clk IMX8MM_SYS_PLL1_80M>;
+ status = "okay";
+};
+
+&uart4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart4>;
+ assigned-clocks = <&clk IMX8MM_CLK_UART4>;
+ assigned-clock-parents = <&clk IMX8MM_SYS_PLL1_80M>;
+ status = "okay";
+};
+
+&usbotg1 {
+ dr_mode = "otg";
+ over-current-active-low;
+ status = "okay";
+};
+
+&usbotg2 {
+ dr_mode = "host";
+ disable-over-current;
+ status = "disabled";
+};
+
+&usdhc1 {
+ pinctrl-names = "default", "state_100mhz", "state_200mhz";
+ pinctrl-0 = <&pinctrl_usdhc1>, <&pinctrl_usdhc1_gpio>;
+ pinctrl-1 = <&pinctrl_usdhc1_100mhz>, <&pinctrl_usdhc1_gpio>;
+ pinctrl-2 = <&pinctrl_usdhc1_200mhz>, <&pinctrl_usdhc1_gpio>;
+ bus-width = <8>;
+ vmmc-supply = <®_usdhc1_vmmc>;
+ keep-power-in-suspend;
+ non-removable;
+ status = "okay";
+};
+
+&usdhc2 {
+ pinctrl-names = "default", "state_100mhz", "state_200mhz";
+ pinctrl-0 = <&pinctrl_usdhc2>, <&pinctrl_usdhc2_gpio>;
+ pinctrl-1 = <&pinctrl_usdhc2_100mhz>, <&pinctrl_usdhc2_gpio>;
+ pinctrl-2 = <&pinctrl_usdhc2_200mhz>, <&pinctrl_usdhc2_gpio>;
+ cd-gpios = <&gpio2 12 GPIO_ACTIVE_LOW>;
+ wp-gpios = <&gpio2 20 GPIO_ACTIVE_HIGH>;
+ bus-width = <4>;
+ vmmc-supply = <®_usdhc2_vmmc>;
+ no-1-8-v;
+ status = "okay";
+};
+
+&wdog1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_wdog>;
+ fsl,ext-reset-output;
+ status = "okay";
+};
--
2.20.1
^ permalink raw reply related
* [RESEND PATCH v5 1/2] dt-bindings: arm: Add emtrion hardware emCON-MX8M Mini
From: reinhold.mueller @ 2022-01-27 15:34 UTC (permalink / raw)
To: festevam
Cc: robh+dt, s.hauer, kernel, shawnguo, linux-imx, devicetree,
linux-kernel, reinhold.mueller
In-Reply-To: <20220127153500.9236-1-reinhold.mueller@emtrion.com>
From: Reinhold Mueller <reinhold.mueller@emtrion.com>
This patch presents the yaml patch for the emtrion GmbH
emCON-MX8M Mini.
Signed-off-by: Reinhold Mueller <reinhold.mueller@emtrion.com>
Acked-by: Rob Herring <robh+dt@kernel.org>
---
Documentation/devicetree/bindings/arm/fsl.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
index 0b595b26061f..e2c70c87baef 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -723,6 +723,7 @@ properties:
- enum:
- beacon,imx8mm-beacon-kit # i.MX8MM Beacon Development Kit
- boundary,imx8mm-nitrogen8mm # i.MX8MM Nitrogen Board
+ - emtrion,emcon-mx8mm-avari # emCON-MX8MM SoM on Avari Base
- fsl,imx8mm-ddr4-evk # i.MX8MM DDR4 EVK Board
- fsl,imx8mm-evk # i.MX8MM EVK Board
- gw,imx8mm-gw71xx-0x # i.MX8MM Gateworks Development Kit
--
2.20.1
^ permalink raw reply related
* [RESEND PATCH v5 0/2] new emtrion hardware emCON-MX8M Mini
From: reinhold.mueller @ 2022-01-27 15:34 UTC (permalink / raw)
To: festevam
Cc: robh+dt, s.hauer, kernel, shawnguo, linux-imx, devicetree,
linux-kernel, reinhold.mueller
From: Reinhold Mueller <reinhold.mueller@emtrion.com>
This patchset adds support for the emtrion emCON-MX8M Mini
Changes
v5:
[RESEND PATCH 1/2]
- no changes
- since v2 Acked-by: Rob Herring <robh@kernel.org>
[RESEND PATCH 2/2]
- ecspi1: add cs-gpios in cs-gpios property
- Reviewed-by: Fabio Estevam <festevam@gmail.com>
v4:
[PATCH 1/2]
- no changes
- since v2 Acked-by: Rob Herring <robh@kernel.org>
[PATCH 2/2]
- removed reserved memory nodes
- added a child node in fec for the phy reset gpios
v3:
[PATCH 1/2]
- no changes
- since v2 Acked-by: Rob Herring <robh@kernel.org>
[PATCH 2/2]
- inserted hyphen in some node names
- spell out regulator in some regulator nodes
- order of properties
- sort label node alphabetically
- inserting space before node name
v2:
[PATCH 1/2]
- no changes
- Acked-by: Rob Herring <robh@kernel.org>
[PATCH 2/2]
- replaced GPIO_ACTIVE_LOW by IRQ_TYPE_LEVEL_LOW
v1:
[PATCH 0/2]
- split former patch in dts -and yaml patches
[PATCH 1/2]
- removing character '\t'
[PATCH 2/2]
- correct entry compatible in spi-flash@0
Reinhold Mueller (2):
dt-bindings: arm: Add emtrion hardware emCON-MX8M Mini
arm64: dts: imx8mm: Add support for emtrion emCON-MX8M Mini
.../devicetree/bindings/arm/fsl.yaml | 1 +
arch/arm64/boot/dts/freescale/Makefile | 3 +-
.../boot/dts/freescale/imx8mm-emcon-avari.dts | 23 +
.../dts/freescale/imx8mm-emcon-avari.dtsi | 139 ++++
.../boot/dts/freescale/imx8mm-emcon.dtsi | 627 ++++++++++++++++++
5 files changed, 792 insertions(+), 1 deletion(-)
create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-emcon-avari.dts
create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-emcon-avari.dtsi
create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-emcon.dtsi
--
2.20.1
^ permalink raw reply
* RE: [PATCH v3 1/2] dt-bindings: arm: xen: document Xen iommu device
From: Sergiy Kibrik @ 2022-01-26 15:09 UTC (permalink / raw)
To: Robin Murphy
Cc: Stefano Stabellini, Julien Grall, Oleksandr Tyshchenko,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
xen-devel@lists.xenproject.org
In-Reply-To: <e88b882f-4b5d-a801-fc68-66b7f790e11c@arm.com>
Hi Robin,
>
> This could break Linux guests, since depending on the deferred probe
> timeout setting it could lead to drivers never probing because the "IOMMU"
> never becomes available.
>
I've noticed no deferred probe timeouts when booting with this patch. Could you please explain more on how this would break guests?
Thank you!
-- Sergiy
^ permalink raw reply
* Re: [PATCH stable 5.4 0/7] pinctrl-bcm2835 gpio-ranges bugfix
From: Greg KH @ 2022-01-27 15:41 UTC (permalink / raw)
To: Florian Fainelli
Cc: stable, Rob Herring, Mark Rutland, Ray Jui, Scott Branden,
maintainer:BROADCOM BCM281XX/BCM11XXX/BCM216XX ARM ARCHITE...,
Linus Walleij, Eric Anholt, Stefan Wahren, Nicolas Saenz Julienne,
Phil Elwell,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list, open list:PIN CONTROL SUBSYSTEM,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE
In-Reply-To: <20220125194222.12783-1-f.fainelli@gmail.com>
On Tue, Jan 25, 2022 at 11:42:15AM -0800, Florian Fainelli wrote:
> Hi all,
>
> This patch series is intended to backport the fix from Phil "pinctrl:
> bcm2835: Change init order for gpio hogs" into the 5.4 tree since the
> blamed commit:
>
> 73345a18d464b ("pinctrl: bcm2835: Pass irqchip when adding gpiochip")
>
> is in 5.4. To get there, I did backport a number of changes in order for
> the commit "pinctrl: bcm2835: Change init order for gpio hogs" to apply
> cleanly with no hunks.
>
> Those should have no functional impact since we do not have support for
> 7211 or 2711 in the upstream stable 5.4.
>
> Both the pinctrl *and* the DTS changes must be taken in lockstep
> otherwise the GPIO pins are simply not usable unfortunately.
>
> Thanks!
>
> Florian Fainelli (2):
> pinctrl: bcm2835: Match BCM7211 compatible string
> pinctrl: bcm2835: Add support for wake-up interrupts
>
> Phil Elwell (2):
> pinctrl: bcm2835: Change init order for gpio hogs
> ARM: dts: gpio-ranges property is now required
>
> Stefan Wahren (3):
> pinctrl: bcm2835: Drop unused define
> pinctrl: bcm2835: Refactor platform data
> pinctrl: bcm2835: Add support for all GPIOs on BCM2711
>
> arch/arm/boot/dts/bcm283x.dtsi | 1 +
> drivers/pinctrl/bcm/pinctrl-bcm2835.c | 209 +++++++++++++++++++++-----
> 2 files changed, 175 insertions(+), 35 deletions(-)
>
> --
> 2.25.1
>
All now queued up, thanks.
greg k-h
^ permalink raw reply
* Re: [PATCH net-next 3/7] net: lan966x: Add support for ptp clocks
From: Richard Cochran @ 2022-01-27 15:28 UTC (permalink / raw)
To: Horatiu Vultur
Cc: netdev, devicetree, linux-kernel, davem, kuba, robh+dt,
UNGLinuxDriver, linux, f.fainelli, vivien.didelot,
vladimir.oltean, andrew
In-Reply-To: <20220127102333.987195-4-horatiu.vultur@microchip.com>
On Thu, Jan 27, 2022 at 11:23:29AM +0100, Horatiu Vultur wrote:
> +static int lan966x_ptp_phc_init(struct lan966x *lan966x,
> + int index,
> + struct ptp_clock_info *clock_info)
> +{
> + struct lan966x_phc *phc = &lan966x->phc[index];
> +
> + phc->info = *clock_info;
> + phc->clock = ptp_clock_register(&phc->info, lan966x->dev);
> + if (IS_ERR(phc->clock))
> + return PTR_ERR(phc->clock);
> +
> + phc->index = index;
> + phc->lan966x = lan966x;
> +
> + /* PTP Rx stamping is always enabled. */
> + phc->hwtstamp_config.rx_filter = HWTSTAMP_FILTER_PTP_V2_EVENT;
Not true -- you allow it to be disabled in the next patch!
Thanks,
Richard
> +
> + return 0;
> +}
^ permalink raw reply
* Re: [PATCH net-next 3/7] net: lan966x: Add support for ptp clocks
From: Richard Cochran @ 2022-01-27 15:25 UTC (permalink / raw)
To: Horatiu Vultur
Cc: netdev, devicetree, linux-kernel, davem, kuba, robh+dt,
UNGLinuxDriver, linux, f.fainelli, vivien.didelot,
vladimir.oltean, andrew
In-Reply-To: <20220127102333.987195-4-horatiu.vultur@microchip.com>
On Thu, Jan 27, 2022 at 11:23:29AM +0100, Horatiu Vultur wrote:
> The lan966x has 3 PHC. Enable each of them, for now all the
> timestamping is happening on the first PHC.
>
> Signed-off-by: Horatiu Vultur <horatiu.vultur@microchip.com>
Acked-by: Richard Cochran <richardcochran@gmail.com>
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: PCI: ti,j721e: Add device id for J721S2
From: Bjorn Helgaas @ 2022-01-27 15:23 UTC (permalink / raw)
To: Aswath Govindraju
Cc: Bjorn Helgaas, Vignesh Raghavendra, Nishanth Menon,
Kishon Vijay Abraham I, Rob Herring, linux-pci, devicetree,
linux-kernel, Lorenzo Pieralisi
In-Reply-To: <ab490690-eac2-c714-1359-b4058e2f98ff@ti.com>
[+cc Lorenzo, initial post
https://lore.kernel.org/r/20211130035608.13492-1-a-govindraju@ti.com]
On Tue, Jan 25, 2022 at 12:06:16PM +0530, Aswath Govindraju wrote:
> On 30/11/21 9:26 am, Aswath Govindraju wrote:
> > Document the device id of J721S2 SoC.
> >
> > Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
> > ---
> >
>
> May I know if this patch can be picked up?
"git log Documentation/devicetree/bindings/pci/ti,j721e-pci-host.yaml"
says most changes to this file have been applied by Lorenzo, so I cc'd
him.
> > changes since v1:
> > - changed (oneOf, items) into enum
> >
> > .../devicetree/bindings/pci/ti,j721e-pci-host.yaml | 12 +++++-------
> > 1 file changed, 5 insertions(+), 7 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/pci/ti,j721e-pci-host.yaml b/Documentation/devicetree/bindings/pci/ti,j721e-pci-host.yaml
> > index cc900202df29..41df8f1c2d4c 100644
> > --- a/Documentation/devicetree/bindings/pci/ti,j721e-pci-host.yaml
> > +++ b/Documentation/devicetree/bindings/pci/ti,j721e-pci-host.yaml
> > @@ -64,13 +64,11 @@ properties:
> > const: 0x104c
> >
> > device-id:
> > - oneOf:
> > - - items:
> > - - const: 0xb00d
> > - - items:
> > - - const: 0xb00f
> > - - items:
> > - - const: 0xb010
> > + enum:
> > + - 0xb00d
> > + - 0xb00f
> > + - 0xb010
> > + - 0xb013
> > msi-map: true
> >
> >
>
^ permalink raw reply
* Re: [PATCH v20 2/3] Input: mt6779-keypad - Add MediaTek keypad driver
From: Andy Shevchenko @ 2022-01-27 15:20 UTC (permalink / raw)
To: Mattijs Korpershoek
Cc: Dmitry Torokhov, Marco Felsch, Rob Herring, Matthias Brugger,
Fengping Yu, Yingjoe Chen, Fabien Parent, Kevin Hilman,
linux-input, devicetree, linux-arm-kernel, linux-mediatek,
linux-kernel
In-Reply-To: <20220127111526.3716689-3-mkorpershoek@baylibre.com>
On Thu, Jan 27, 2022 at 12:15:25PM +0100, Mattijs Korpershoek wrote:
> From: "fengping.yu" <fengping.yu@mediatek.com>
>
> This patch adds matrix keypad support for Mediatek SoCs.
Some comments which may be addressed now or in the follow-up patch(es).
Up to you.
...
> +static const struct regmap_config mt6779_keypad_regmap_cfg = {
> + .reg_bits = 32,
> + .val_bits = 32,
> + .reg_stride = sizeof(u32),
I'm wondering if we need this when we have reg_bits = 32 already.
> + .max_register = 36,
> +};
...
> + regmap_write(keypad->regmap, MTK_KPD_DEBOUNCE,
> + (debounce * 32) & MTK_KPD_DEBOUNCE_MASK);
I'm wondering if << 5 is more specific to show that the value
is based on 2^5 units.
...
> + error = devm_add_action_or_reset(&pdev->dev, mt6779_keypad_clk_disable, keypad->clk);
You have this long line...
> + error = devm_request_threaded_irq(&pdev->dev, irq,
> + NULL, mt6779_keypad_irq_handler,
> + IRQF_ONESHOT,
> + MTK_KPD_NAME, keypad);
...at the same time you may reduce LOCs here...
> + if (error) {
> + dev_err(&pdev->dev, "Failed to request IRQ#%d:%d\n",
> + irq, error);
...and here.
> + return error;
> + }
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH net-next 2/7] net: lan966x: Add registers that are use for ptp functionality
From: Richard Cochran @ 2022-01-27 15:18 UTC (permalink / raw)
To: Horatiu Vultur
Cc: netdev, devicetree, linux-kernel, davem, kuba, robh+dt,
UNGLinuxDriver, linux, f.fainelli, vivien.didelot,
vladimir.oltean, andrew
In-Reply-To: <20220127102333.987195-3-horatiu.vultur@microchip.com>
On Thu, Jan 27, 2022 at 11:23:28AM +0100, Horatiu Vultur wrote:
> This patch adds the registers that will be used to configure the PHC in
> the HW.
See "This patch" in Documentation/process/submitting-patches.rst
Thanks,
Richard
^ permalink raw reply
* Re: [PATCH] arm64: dts: meson-sm1-bananapi-m5: fix wrong GPIO domain for GPIOE_2
From: Neil Armstrong @ 2022-01-27 15:17 UTC (permalink / raw)
To: Dongjin Kim, Rob Herring, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, devicetree, linux-arm-kernel, linux-amlogic,
linux-kernel
In-Reply-To: <20220127151656.GA2419733@paju>
On 27/01/2022 16:16, Dongjin Kim wrote:
> GPIOE_2 is in AO domain and "<&gpio GPIOE_2 ...>" changes the state of
> TF_PWR_EN of 'FC8731' on BPI-M5
>
> Fixes: 976e920183e4 ("arm64: dts: meson-sm1: add Banana PI BPI-M5 board dts")
>
> Signed-off-by: Dongjin Kim <tobetter@gmail.com>
> ---
> arch/arm64/boot/dts/amlogic/meson-sm1-bananapi-m5.dts | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-sm1-bananapi-m5.dts b/arch/arm64/boot/dts/amlogic/meson-sm1-bananapi-m5.dts
> index 212c6aa5a3b8..5751c48620ed 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-sm1-bananapi-m5.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-sm1-bananapi-m5.dts
> @@ -123,7 +123,7 @@ vddio_c: regulator-vddio_c {
> regulator-min-microvolt = <1800000>;
> regulator-max-microvolt = <3300000>;
>
> - enable-gpio = <&gpio GPIOE_2 GPIO_ACTIVE_HIGH>;
> + enable-gpio = <&gpio_ao GPIOE_2 GPIO_ACTIVE_HIGH>;
> enable-active-high;
> regulator-always-on;
>
>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Thanks !
Neil
^ permalink raw reply
* [PATCH 11/12] MAINTAINERS: add myself as Nuclei SoCs/CPUs supporter
From: Icenowy Zheng @ 2022-01-27 15:16 UTC (permalink / raw)
To: Rob Herring, Palmer Dabbelt, Paul Walmsley, Albert Ou
Cc: linux-kernel, devicetree, linux-riscv, linux-serial, linux-spi,
Icenowy Zheng
In-Reply-To: <20220127151647.2375449-1-icenowy@nucleisys.com>
Currently I am working on mainlining Nuclei SoCs/CPUs Linux support.
Add myself as a supporter of this.
Signed-off-by: Icenowy Zheng <icenowy@nucleisys.com>
---
MAINTAINERS | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index ea3e6c914384..499450d14625 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -13733,6 +13733,13 @@ F: drivers/nubus/
F: include/linux/nubus.h
F: include/uapi/linux/nubus.h
+NUCLEI RISCV CORES AND SOCS
+M: Icenowy Zheng <icenowy@nucleisys.com>
+L: linux-riscv@lists.infradead.org
+S: Supported
+N: nuclei
+K: [^@]nuclei
+
NVIDIA (rivafb and nvidiafb) FRAMEBUFFER DRIVER
M: Antonino Daplas <adaplas@gmail.com>
L: linux-fbdev@vger.kernel.org
--
2.30.2
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox