* [PATCH net-next v3 09/12] net: airoha: Support multiple net_devices for a single FE GDM port
From: Lorenzo Bianconi @ 2026-04-06 10:34 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Lorenzo Bianconi
Cc: Christian Marangi, Benjamin Larsson, linux-arm-kernel,
linux-mediatek, netdev, devicetree, Xuegang Lu
In-Reply-To: <20260406-airoha-eth-multi-serdes-v3-0-ab6ea49d59ff@kernel.org>
EN7581 or AN7583 SoCs support connecting multiple external SerDes (e.g.
Ethernet or USB SerDes) to GDM3 or GDM4 ports via a hw arbiter that
manages the traffic in a TDM manner. As a result multiple net_devices can
connect to the same GDM{3,4} port and there is a theoretical "1:n"
relation between GDM ports and net_devices.
┌─────────────────────────────────┐
│ │ ┌──────┐
│ P1 GDM1 ├────►MT7530│
│ │ └──────┘
│ │ ETH0 (DSA conduit)
│ │
│ PSE/FE │
│ │
│ │
│ │ ┌─────┐
│ P0 CDM1 ├────►QDMA0│
│ P4 P9 GDM4 │ └─────┘
└──┬─────────────────────────┬────┘
│ │
┌──▼──┐ ┌────▼────┐
│ PPE │ │ ARB │
└─────┘ └─┬─────┬─┘
│ │
┌──▼──┐┌─▼───┐
│ ETH ││ USB │
└─────┘└─────┘
ETH1 ETH2
Introduce support for multiple net_devices connected to the same Frame
Engine (FE) GDM port (GDM3 or GDM4) via an external hw arbiter.
Please note GDM1 or GDM2 does not support the connection with the external
arbiter.
Add get_dev_from_sport callback since EN7581 and AN7583 have different
logics for the net_device type connected to GDM3 or GDM4.
Tested-by: Xuegang Lu <xuegang.lu@airoha.com>
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/ethernet/airoha/airoha_eth.c | 238 ++++++++++++++++++++++++-------
drivers/net/ethernet/airoha/airoha_eth.h | 9 +-
drivers/net/ethernet/airoha/airoha_ppe.c | 13 +-
3 files changed, 206 insertions(+), 54 deletions(-)
diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
index d25b0338b5ca..fd27ba13029b 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.c
+++ b/drivers/net/ethernet/airoha/airoha_eth.c
@@ -581,24 +581,26 @@ static int airoha_qdma_fill_rx_queue(struct airoha_queue *q)
return nframes;
}
-static int airoha_qdma_get_gdm_port(struct airoha_eth *eth,
- struct airoha_qdma_desc *desc)
+static struct airoha_gdm_dev *
+airoha_qdma_get_gdm_dev(struct airoha_eth *eth, struct airoha_qdma_desc *desc)
{
- u32 port, sport, msg1 = le32_to_cpu(desc->msg1);
+ struct airoha_gdm_port *port;
+ u16 p, d;
- sport = FIELD_GET(QDMA_ETH_RXMSG_SPORT_MASK, msg1);
- switch (sport) {
- case 0x10 ... 0x14:
- port = 0;
- break;
- case 0x2 ... 0x4:
- port = sport - 1;
- break;
- default:
- return -EINVAL;
- }
+ if (eth->soc->ops.get_dev_from_sport(desc, &p, &d))
+ return ERR_PTR(-ENODEV);
+
+ if (p >= ARRAY_SIZE(eth->ports))
+ return ERR_PTR(-ENODEV);
+
+ port = eth->ports[p];
+ if (!port)
+ return ERR_PTR(-ENODEV);
+
+ if (d >= ARRAY_SIZE(port->devs))
+ return ERR_PTR(-ENODEV);
- return port >= ARRAY_SIZE(eth->ports) ? -EINVAL : port;
+ return port->devs[d] ? port->devs[d] : ERR_PTR(-ENODEV);
}
static int airoha_qdma_rx_process(struct airoha_queue *q, int budget)
@@ -615,9 +617,8 @@ static int airoha_qdma_rx_process(struct airoha_queue *q, int budget)
u32 hash, reason, msg1 = le32_to_cpu(desc->msg1);
struct page *page = virt_to_head_page(e->buf);
u32 desc_ctrl = le32_to_cpu(desc->ctrl);
- struct airoha_gdm_port *port;
- struct net_device *netdev;
- int data_len, len, p;
+ struct airoha_gdm_dev *dev;
+ int data_len, len;
if (!(desc_ctrl & QDMA_DESC_DONE_MASK))
break;
@@ -634,12 +635,10 @@ static int airoha_qdma_rx_process(struct airoha_queue *q, int budget)
if (!len || data_len < len)
goto free_frag;
- p = airoha_qdma_get_gdm_port(eth, desc);
- if (p < 0 || !eth->ports[p])
+ dev = airoha_qdma_get_gdm_dev(eth, desc);
+ if (IS_ERR(dev))
goto free_frag;
- port = eth->ports[p];
- netdev = port->dev->dev;
if (!q->skb) { /* first buffer */
q->skb = napi_build_skb(e->buf, q->buf_size);
if (!q->skb)
@@ -647,8 +646,8 @@ static int airoha_qdma_rx_process(struct airoha_queue *q, int budget)
__skb_put(q->skb, len);
skb_mark_for_recycle(q->skb);
- q->skb->dev = netdev;
- q->skb->protocol = eth_type_trans(q->skb, netdev);
+ q->skb->dev = dev->dev;
+ q->skb->protocol = eth_type_trans(q->skb, dev->dev);
q->skb->ip_summed = CHECKSUM_UNNECESSARY;
skb_record_rx_queue(q->skb, qid);
} else { /* scattered frame */
@@ -666,7 +665,9 @@ static int airoha_qdma_rx_process(struct airoha_queue *q, int budget)
if (FIELD_GET(QDMA_DESC_MORE_MASK, desc_ctrl))
continue;
- if (netdev_uses_dsa(netdev)) {
+ if (netdev_uses_dsa(dev->dev)) {
+ struct airoha_gdm_port *port = dev->port;
+
/* PPE module requires untagged packets to work
* properly and it provides DSA port index via the
* DMA descriptor. Report DSA tag to the DSA stack
@@ -1734,7 +1735,7 @@ static int airoha_set_gdm2_loopback(struct airoha_gdm_dev *dev)
{
struct airoha_gdm_port *port = dev->port;
struct airoha_eth *eth = dev->eth;
- u32 val, pse_port, chan, nbq;
+ u32 val, pse_port, chan;
int i, src_port;
/* Forward the traffic to the proper GDM port */
@@ -1764,9 +1765,7 @@ static int airoha_set_gdm2_loopback(struct airoha_gdm_dev *dev)
airoha_fe_clear(eth, REG_FE_VIP_PORT_EN, BIT(AIROHA_GDM2_IDX));
airoha_fe_clear(eth, REG_FE_IFC_PORT_EN, BIT(AIROHA_GDM2_IDX));
- /* XXX: handle XSI_USB_PORT and XSI_PCE1_PORT */
- nbq = port->id == AIROHA_GDM3_IDX && airoha_is_7581(eth) ? 4 : 0;
- src_port = eth->soc->ops.get_src_port_id(port, nbq);
+ src_port = eth->soc->ops.get_src_port_id(port, dev->nbq);
if (src_port < 0)
return src_port;
@@ -1783,7 +1782,7 @@ static int airoha_set_gdm2_loopback(struct airoha_gdm_dev *dev)
airoha_ppe_set_cpu_port(dev, i, AIROHA_GDM2_IDX);
if (port->id == AIROHA_GDM4_IDX && airoha_is_7581(eth)) {
- u32 mask = FC_ID_OF_SRC_PORT_MASK(nbq);
+ u32 mask = FC_ID_OF_SRC_PORT_MASK(dev->nbq);
airoha_fe_rmw(eth, REG_SRC_PORT_FC_MAP6, mask,
__field_prep(mask, AIROHA_GDM2_IDX));
@@ -1987,7 +1986,8 @@ static netdev_tx_t airoha_dev_xmit(struct sk_buff *skb,
}
fport = airoha_get_fe_port(dev);
- msg1 = FIELD_PREP(QDMA_ETH_TXMSG_FPORT_MASK, fport) |
+ msg1 = FIELD_PREP(QDMA_ETH_TXMSG_NBOQ_MASK, dev->nbq) |
+ FIELD_PREP(QDMA_ETH_TXMSG_FPORT_MASK, fport) |
FIELD_PREP(QDMA_ETH_TXMSG_METER_MASK, 0x7f);
q = &qdma->q_tx[qid];
@@ -2901,12 +2901,15 @@ bool airoha_is_valid_gdm_dev(struct airoha_eth *eth,
for (i = 0; i < ARRAY_SIZE(eth->ports); i++) {
struct airoha_gdm_port *port = eth->ports[i];
+ int j;
if (!port)
continue;
- if (port->dev == dev)
- return true;
+ for (j = 0; j < ARRAY_SIZE(port->devs); j++) {
+ if (port->devs[j] == dev)
+ return true;
+ }
}
return false;
@@ -2914,10 +2917,11 @@ bool airoha_is_valid_gdm_dev(struct airoha_eth *eth,
static int airoha_alloc_gdm_device(struct airoha_eth *eth,
struct airoha_gdm_port *port,
- struct device_node *np)
+ int nbq, struct device_node *np)
{
- struct airoha_gdm_dev *dev;
struct net_device *netdev;
+ struct airoha_gdm_dev *dev;
+ u8 index;
int err;
netdev = devm_alloc_etherdev_mqs(eth->dev, sizeof(*dev),
@@ -2937,7 +2941,6 @@ static int airoha_alloc_gdm_device(struct airoha_eth *eth,
NETIF_F_HW_TC;
netdev->features |= netdev->hw_features;
netdev->vlan_features = netdev->hw_features;
- netdev->dev.of_node = np;
SET_NETDEV_DEV(netdev, eth->dev);
/* reserve hw queues for HTB offloading */
@@ -2955,11 +2958,25 @@ static int airoha_alloc_gdm_device(struct airoha_eth *eth,
netdev->dev_addr);
}
+ /* Allowed nbq for EN7581 on GDM3 port are 4 and 5 for PCIE0
+ * and PCIE1 respectively.
+ */
+ index = nbq;
+ if (index && airoha_is_7581(eth) && port->id == AIROHA_GDM3_IDX)
+ index -= 4;
+
+ if (index >= ARRAY_SIZE(port->devs) || port->devs[index]) {
+ dev_err(eth->dev, "invalid nbq id: %d\n", nbq);
+ return -EINVAL;
+ }
+
+ netdev->dev.of_node = of_node_get(np);
dev = netdev_priv(netdev);
dev->dev = netdev;
dev->port = port;
- port->dev = dev;
dev->eth = eth;
+ dev->nbq = nbq;
+ port->devs[index] = dev;
return 0;
}
@@ -2969,7 +2986,8 @@ static int airoha_alloc_gdm_port(struct airoha_eth *eth,
{
const __be32 *id_ptr = of_get_property(np, "reg", NULL);
struct airoha_gdm_port *port;
- int err, p;
+ struct device_node *node;
+ int err, p, d = 0;
u32 id;
if (!id_ptr) {
@@ -3003,7 +3021,43 @@ static int airoha_alloc_gdm_port(struct airoha_eth *eth,
if (err)
return err;
- return airoha_alloc_gdm_device(eth, port, np);
+ for_each_child_of_node(np, node) {
+ /* Multiple external serdes connected to the FE GDM port via an
+ * external arbiter.
+ */
+ const __be32 *nbq_ptr;
+ int nbq;
+
+ if (!of_device_is_compatible(node, "airoha,eth-port"))
+ continue;
+
+ d++;
+ if (!of_device_is_available(node))
+ continue;
+
+ nbq_ptr = of_get_property(node, "reg", NULL);
+ if (!nbq_ptr) {
+ dev_err(eth->dev, "missing nbq id\n");
+ of_node_put(node);
+ return -EINVAL;
+ }
+
+ /* Verify the provided nbq parameter is valid */
+ nbq = be32_to_cpup(nbq_ptr);
+ err = eth->soc->ops.get_src_port_id(port, nbq);
+ if (err < 0) {
+ of_node_put(node);
+ return err;
+ }
+
+ err = airoha_alloc_gdm_device(eth, port, nbq, node);
+ if (err) {
+ of_node_put(node);
+ return err;
+ }
+ }
+
+ return !d ? airoha_alloc_gdm_device(eth, port, 0, np) : 0;
}
static int airoha_register_gdm_devices(struct airoha_eth *eth)
@@ -3012,14 +3066,22 @@ static int airoha_register_gdm_devices(struct airoha_eth *eth)
for (i = 0; i < ARRAY_SIZE(eth->ports); i++) {
struct airoha_gdm_port *port = eth->ports[i];
- int err;
+ int j;
if (!port)
continue;
- err = register_netdev(port->dev->dev);
- if (err)
- return err;
+ for (j = 0; j < ARRAY_SIZE(port->devs); j++) {
+ struct airoha_gdm_dev *dev = port->devs[j];
+ int err;
+
+ if (!dev)
+ continue;
+
+ err = register_netdev(dev->dev);
+ if (err)
+ return err;
+ }
}
set_bit(DEV_STATE_REGISTERED, ð->state);
@@ -3126,14 +3188,20 @@ static int airoha_probe(struct platform_device *pdev)
for (i = 0; i < ARRAY_SIZE(eth->ports); i++) {
struct airoha_gdm_port *port = eth->ports[i];
- struct airoha_gdm_dev *dev;
+ int j;
if (!port)
continue;
- dev = port->dev;
- if (dev && dev->dev->reg_state == NETREG_REGISTERED)
- unregister_netdev(dev->dev);
+ for (j = 0; j < ARRAY_SIZE(port->devs); j++) {
+ struct airoha_gdm_dev *dev = port->devs[j];
+
+ if (!dev)
+ continue;
+
+ if (dev->dev->reg_state == NETREG_REGISTERED)
+ unregister_netdev(dev->dev);
+ }
airoha_metadata_dst_free(port);
}
airoha_hw_cleanup(eth);
@@ -3154,14 +3222,19 @@ static void airoha_remove(struct platform_device *pdev)
for (i = 0; i < ARRAY_SIZE(eth->ports); i++) {
struct airoha_gdm_port *port = eth->ports[i];
- struct airoha_gdm_dev *dev;
+ int j;
if (!port)
continue;
- dev = port->dev;
- if (dev)
+ for (j = 0; j < ARRAY_SIZE(port->devs); j++) {
+ struct airoha_gdm_dev *dev = port->devs[j];
+
+ if (!dev)
+ continue;
+
unregister_netdev(dev->dev);
+ }
airoha_metadata_dst_free(port);
}
airoha_hw_cleanup(eth);
@@ -3202,6 +3275,39 @@ static int airoha_en7581_get_src_port_id(struct airoha_gdm_port *port, int nbq)
return -EINVAL;
}
+static int airoha_en7581_get_dev_from_sport(struct airoha_qdma_desc *desc,
+ u16 *port, u16 *dev)
+{
+ u32 sport = FIELD_GET(QDMA_ETH_RXMSG_SPORT_MASK,
+ le32_to_cpu(READ_ONCE(desc->msg1)));
+
+ *dev = 0;
+ switch (sport) {
+ case 0x10 ... 0x14:
+ *port = 0; /* GDM1 */
+ break;
+ case 0x2:
+ *port = 1; /* GDM2 */
+ break;
+ case HSGMII_LAN_7581_PCIE1_SRCPORT:
+ *dev = 1;
+ fallthrough;
+ case HSGMII_LAN_7581_PCIE0_SRCPORT:
+ *port = 2; /* GDM3 */
+ break;
+ case HSGMII_LAN_7581_USB_SRCPORT:
+ *dev = 1;
+ fallthrough;
+ case HSGMII_LAN_7581_ETH_SRCPORT:
+ *port = 3; /* GDM4 */
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
static const char * const an7583_xsi_rsts_names[] = {
"xsi-mac",
"hsi0-mac",
@@ -3231,6 +3337,36 @@ static int airoha_an7583_get_src_port_id(struct airoha_gdm_port *port, int nbq)
return -EINVAL;
}
+static int airoha_an7583_get_dev_from_sport(struct airoha_qdma_desc *desc,
+ u16 *port, u16 *dev)
+{
+ u32 sport = FIELD_GET(QDMA_ETH_RXMSG_SPORT_MASK,
+ le32_to_cpu(READ_ONCE(desc->msg1)));
+
+ *dev = 0;
+ switch (sport) {
+ case 0x10 ... 0x14:
+ *port = 0; /* GDM1 */
+ break;
+ case 0x2:
+ *port = 1; /* GDM2 */
+ break;
+ case HSGMII_LAN_7583_ETH_SRCPORT:
+ *port = 2; /* GDM3 */
+ break;
+ case HSGMII_LAN_7583_USB_SRCPORT:
+ *dev = 1;
+ fallthrough;
+ case HSGMII_LAN_7583_PCIE_SRCPORT:
+ *port = 3; /* GDM4 */
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
static const struct airoha_eth_soc_data en7581_soc_data = {
.version = 0x7581,
.xsi_rsts_names = en7581_xsi_rsts_names,
@@ -3238,6 +3374,7 @@ static const struct airoha_eth_soc_data en7581_soc_data = {
.num_ppe = 2,
.ops = {
.get_src_port_id = airoha_en7581_get_src_port_id,
+ .get_dev_from_sport = airoha_en7581_get_dev_from_sport,
},
};
@@ -3248,6 +3385,7 @@ static const struct airoha_eth_soc_data an7583_soc_data = {
.num_ppe = 1,
.ops = {
.get_src_port_id = airoha_an7583_get_src_port_id,
+ .get_dev_from_sport = airoha_an7583_get_dev_from_sport,
},
};
diff --git a/drivers/net/ethernet/airoha/airoha_eth.h b/drivers/net/ethernet/airoha/airoha_eth.h
index e6c87ed20b39..5ce71aff6c39 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.h
+++ b/drivers/net/ethernet/airoha/airoha_eth.h
@@ -17,6 +17,7 @@
#include <net/dsa.h>
#define AIROHA_MAX_NUM_GDM_PORTS 4
+#define AIROHA_MAX_NUM_GDM_DEVS 2
#define AIROHA_MAX_NUM_QDMA 2
#define AIROHA_MAX_NUM_IRQ_BANKS 4
#define AIROHA_MAX_DSA_PORTS 7
@@ -535,12 +536,14 @@ struct airoha_qdma {
struct airoha_gdm_dev {
struct airoha_gdm_port *port;
struct airoha_qdma *qdma;
- struct net_device *dev;
struct airoha_eth *eth;
+ struct net_device *dev;
+
+ int nbq;
};
struct airoha_gdm_port {
- struct airoha_gdm_dev *dev;
+ struct airoha_gdm_dev *devs[AIROHA_MAX_NUM_GDM_DEVS];
int id;
struct airoha_hw_stats stats;
@@ -582,6 +585,8 @@ struct airoha_eth_soc_data {
int num_ppe;
struct {
int (*get_src_port_id)(struct airoha_gdm_port *port, int nbq);
+ int (*get_dev_from_sport)(struct airoha_qdma_desc *desc,
+ u16 *port, u16 *dev);
} ops;
};
diff --git a/drivers/net/ethernet/airoha/airoha_ppe.c b/drivers/net/ethernet/airoha/airoha_ppe.c
index 712fc336c073..a6b188fab053 100644
--- a/drivers/net/ethernet/airoha/airoha_ppe.c
+++ b/drivers/net/ethernet/airoha/airoha_ppe.c
@@ -162,6 +162,7 @@ static void airoha_ppe_hw_init(struct airoha_ppe *ppe)
for (p = 0; p < ARRAY_SIZE(eth->ports); p++) {
struct airoha_gdm_port *port = eth->ports[p];
+ int j;
airoha_fe_rmw(eth, REG_PPE_MTU(i, p),
FP0_EGRESS_MTU_MASK |
@@ -173,8 +174,16 @@ static void airoha_ppe_hw_init(struct airoha_ppe *ppe)
if (!port)
continue;
- airoha_ppe_set_cpu_port(port->dev, i,
- airoha_get_fe_port(port->dev));
+ for (j = 0; j < ARRAY_SIZE(port->devs); j++) {
+ struct airoha_gdm_dev *dev = port->devs[j];
+ u8 fport;
+
+ if (!dev)
+ continue;
+
+ fport = airoha_get_fe_port(dev);
+ airoha_ppe_set_cpu_port(dev, i, fport);
+ }
}
}
}
--
2.53.0
^ permalink raw reply related
* [PATCH net-next v3 10/12] net: airoha: Do not stop GDM port if it is shared
From: Lorenzo Bianconi @ 2026-04-06 10:34 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Lorenzo Bianconi
Cc: Christian Marangi, Benjamin Larsson, linux-arm-kernel,
linux-mediatek, netdev, devicetree, Xuegang Lu
In-Reply-To: <20260406-airoha-eth-multi-serdes-v3-0-ab6ea49d59ff@kernel.org>
Theoretically, in the current codebase, two independent net_devices can
be connected to the same GDM port so we need to check the GDM port is not
used by any other running net_device before setting the forward
configuration to FE_PSE_PORT_DROP.
Tested-by: Xuegang Lu <xuegang.lu@airoha.com>
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/ethernet/airoha/airoha_eth.c | 43 ++++++++++++++++++++++----------
drivers/net/ethernet/airoha/airoha_eth.h | 2 ++
2 files changed, 32 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
index fd27ba13029b..5b0cd37b155e 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.c
+++ b/drivers/net/ethernet/airoha/airoha_eth.c
@@ -1647,8 +1647,8 @@ static int airoha_dev_open(struct net_device *netdev)
int err, len = ETH_HLEN + netdev->mtu + ETH_FCS_LEN;
struct airoha_gdm_dev *dev = netdev_priv(netdev);
struct airoha_gdm_port *port = dev->port;
+ u32 cur_len, pse_port = FE_PSE_PORT_PPE1;
struct airoha_qdma *qdma = dev->qdma;
- u32 pse_port = FE_PSE_PORT_PPE1;
netif_tx_start_all_queues(netdev);
err = airoha_set_vip_for_gdm_port(dev, true);
@@ -1662,10 +1662,15 @@ static int airoha_dev_open(struct net_device *netdev)
airoha_fe_clear(qdma->eth, REG_GDM_INGRESS_CFG(port->id),
GDM_STAG_EN_MASK);
- airoha_fe_rmw(qdma->eth, REG_GDM_LEN_CFG(port->id),
- GDM_SHORT_LEN_MASK | GDM_LONG_LEN_MASK,
- FIELD_PREP(GDM_SHORT_LEN_MASK, 60) |
- FIELD_PREP(GDM_LONG_LEN_MASK, len));
+ cur_len = FIELD_GET(GDM_LONG_LEN_MASK,
+ airoha_fe_rr(qdma->eth,
+ REG_GDM_LEN_CFG(port->id)));
+ if (!atomic_read(&port->users) || len > cur_len)
+ airoha_fe_rmw(qdma->eth, REG_GDM_LEN_CFG(port->id),
+ GDM_SHORT_LEN_MASK | GDM_LONG_LEN_MASK,
+ FIELD_PREP(GDM_SHORT_LEN_MASK, 60) |
+ FIELD_PREP(GDM_LONG_LEN_MASK, len));
+ atomic_inc(&port->users);
airoha_qdma_set(qdma, REG_QDMA_GLOBAL_CFG,
GLOBAL_CFG_TX_DMA_EN_MASK |
@@ -1688,18 +1693,18 @@ static int airoha_dev_stop(struct net_device *netdev)
struct airoha_gdm_dev *dev = netdev_priv(netdev);
struct airoha_gdm_port *port = dev->port;
struct airoha_qdma *qdma = dev->qdma;
- int i, err;
+ int i;
netif_tx_disable(netdev);
- err = airoha_set_vip_for_gdm_port(dev, false);
- if (err)
- return err;
-
for (i = 0; i < ARRAY_SIZE(qdma->q_tx); i++)
netdev_tx_reset_subqueue(netdev, i);
- airoha_set_gdm_port_fwd_cfg(qdma->eth, REG_GDM_FWD_CFG(port->id),
- FE_PSE_PORT_DROP);
+ if (atomic_dec_and_test(&port->users)) {
+ airoha_set_vip_for_gdm_port(dev, false);
+ airoha_set_gdm_port_fwd_cfg(qdma->eth,
+ REG_GDM_FWD_CFG(port->id),
+ FE_PSE_PORT_DROP);
+ }
if (atomic_dec_and_test(&qdma->users)) {
airoha_qdma_clear(qdma, REG_QDMA_GLOBAL_CFG,
@@ -1851,10 +1856,22 @@ static void airoha_dev_get_stats64(struct net_device *netdev,
static int airoha_dev_change_mtu(struct net_device *netdev, int mtu)
{
struct airoha_gdm_dev *dev = netdev_priv(netdev);
+ u32 cur_len, len = ETH_HLEN + mtu + ETH_FCS_LEN;
struct airoha_gdm_port *port = dev->port;
- u32 len = ETH_HLEN + mtu + ETH_FCS_LEN;
struct airoha_eth *eth = dev->eth;
+ cur_len = FIELD_GET(GDM_LONG_LEN_MASK,
+ airoha_fe_rr(eth, REG_GDM_LEN_CFG(port->id)));
+ if (len < cur_len) {
+ u8 port_refcnt = atomic_read(&port->users);
+
+ /* We can decrease the device MTU just if the GDM port is
+ * not shared or if the other device is not running.
+ */
+ if (port_refcnt > 1 || (port_refcnt && !netif_running(netdev)))
+ return -EBUSY;
+ }
+
airoha_fe_rmw(eth, REG_GDM_LEN_CFG(port->id),
GDM_LONG_LEN_MASK,
FIELD_PREP(GDM_LONG_LEN_MASK, len));
diff --git a/drivers/net/ethernet/airoha/airoha_eth.h b/drivers/net/ethernet/airoha/airoha_eth.h
index 5ce71aff6c39..3e77bbae630a 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.h
+++ b/drivers/net/ethernet/airoha/airoha_eth.h
@@ -546,6 +546,8 @@ struct airoha_gdm_port {
struct airoha_gdm_dev *devs[AIROHA_MAX_NUM_GDM_DEVS];
int id;
+ atomic_t users;
+
struct airoha_hw_stats stats;
DECLARE_BITMAP(qos_sq_bmap, AIROHA_NUM_QOS_CHANNELS);
--
2.53.0
^ permalink raw reply related
* [PATCH net-next v3 11/12] net: airoha: Introduce WAN device flag
From: Lorenzo Bianconi @ 2026-04-06 10:34 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Lorenzo Bianconi
Cc: Christian Marangi, Benjamin Larsson, linux-arm-kernel,
linux-mediatek, netdev, devicetree, Xuegang Lu
In-Reply-To: <20260406-airoha-eth-multi-serdes-v3-0-ab6ea49d59ff@kernel.org>
Introduce WAN flag to specify if a given device is used to transmit/receive
WAN or LAN traffic. Current codebase supports specifying LAN/WAN device
configuration in ndo_init() callback during device bootstrap.
Please note it is possible to specify multiple LAN devices but just a
single WAN one.
Tested-by: Xuegang Lu <xuegang.lu@airoha.com>
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/ethernet/airoha/airoha_eth.c | 69 +++++++++++++++++++++++++-------
drivers/net/ethernet/airoha/airoha_eth.h | 13 +++---
drivers/net/ethernet/airoha/airoha_ppe.c | 2 +-
3 files changed, 62 insertions(+), 22 deletions(-)
diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
index 5b0cd37b155e..9988011dca53 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.c
+++ b/drivers/net/ethernet/airoha/airoha_eth.c
@@ -1796,36 +1796,77 @@ static int airoha_set_gdm2_loopback(struct airoha_gdm_dev *dev)
return 0;
}
-static int airoha_dev_init(struct net_device *netdev)
+static struct airoha_gdm_dev *
+airoha_get_wan_gdm_dev(struct airoha_eth *eth)
+{
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(eth->ports); i++) {
+ struct airoha_gdm_port *port = eth->ports[i];
+ int j;
+
+ if (!port)
+ continue;
+
+ for (j = 0; j < ARRAY_SIZE(port->devs); j++) {
+ struct airoha_gdm_dev *dev = port->devs[j];
+
+ if (dev && !airoha_is_lan_gdm_dev(dev))
+ return dev;
+ }
+ }
+
+ return NULL;
+}
+
+static void airoha_dev_set_qdma(struct airoha_gdm_dev *dev)
{
- struct airoha_gdm_dev *dev = netdev_priv(netdev);
- struct airoha_gdm_port *port = dev->port;
struct airoha_eth *eth = dev->eth;
int i;
/* QDMA0 is used for lan ports while QDMA1 is used for WAN ports */
dev->qdma = ð->qdma[!airoha_is_lan_gdm_dev(dev)];
dev->dev->irq = dev->qdma->irq_banks[0].irq;
- airoha_set_macaddr(dev, netdev->dev_addr);
+
+ for (i = 0; i < eth->soc->num_ppe; i++)
+ airoha_ppe_set_cpu_port(dev, i, airoha_get_fe_port(dev));
+}
+
+static int airoha_dev_init(struct net_device *netdev)
+{
+ struct airoha_gdm_dev *dev = netdev_priv(netdev);
+ struct airoha_gdm_port *port = dev->port;
switch (port->id) {
case AIROHA_GDM3_IDX:
- case AIROHA_GDM4_IDX:
- /* If GDM2 is active we can't enable loopback */
- if (!eth->ports[1]) {
- int err;
+ case AIROHA_GDM4_IDX: {
+ struct airoha_eth *eth = dev->eth;
- err = airoha_set_gdm2_loopback(dev);
- if (err)
- return err;
- }
+ if (eth->ports[1] || airoha_get_wan_gdm_dev(eth))
+ break;
+ fallthrough;
+ }
+ case AIROHA_GDM2_IDX:
+ /* GDM2 is always used as wan */
+ dev->flags |= PRIV_FLAG_WAN;
break;
default:
break;
}
- for (i = 0; i < eth->soc->num_ppe; i++)
- airoha_ppe_set_cpu_port(dev, i, airoha_get_fe_port(dev));
+ airoha_dev_set_qdma(dev);
+ airoha_set_macaddr(dev, netdev->dev_addr);
+
+ if (!airoha_is_lan_gdm_dev(dev) &&
+ (port->id == AIROHA_GDM3_IDX || port->id == AIROHA_GDM4_IDX)) {
+ int err;
+
+ err = airoha_set_gdm2_loopback(dev);
+ if (err) {
+ dev->flags &= ~PRIV_FLAG_WAN;
+ return err;
+ }
+ }
return 0;
}
diff --git a/drivers/net/ethernet/airoha/airoha_eth.h b/drivers/net/ethernet/airoha/airoha_eth.h
index 3e77bbae630a..8dec25fa0478 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.h
+++ b/drivers/net/ethernet/airoha/airoha_eth.h
@@ -533,12 +533,17 @@ struct airoha_qdma {
struct airoha_queue q_rx[AIROHA_NUM_RX_RING];
};
+enum airoha_priv_flags {
+ PRIV_FLAG_WAN = BIT(0),
+};
+
struct airoha_gdm_dev {
struct airoha_gdm_port *port;
struct airoha_qdma *qdma;
struct airoha_eth *eth;
struct net_device *dev;
+ u32 flags;
int nbq;
};
@@ -642,13 +647,7 @@ u32 airoha_rmw(void __iomem *base, u32 offset, u32 mask, u32 val);
static inline bool airoha_is_lan_gdm_dev(struct airoha_gdm_dev *dev)
{
- struct airoha_gdm_port *port = dev->port;
-
- /* GDM1 port on EN7581 SoC is connected to the lan dsa switch.
- * GDM{2,3,4} can be used as wan port connected to an external
- * phy module.
- */
- return port->id == 1;
+ return !(dev->flags & PRIV_FLAG_WAN);
}
static inline bool airoha_is_7581(struct airoha_eth *eth)
diff --git a/drivers/net/ethernet/airoha/airoha_ppe.c b/drivers/net/ethernet/airoha/airoha_ppe.c
index a6b188fab053..87bb20b6ee49 100644
--- a/drivers/net/ethernet/airoha/airoha_ppe.c
+++ b/drivers/net/ethernet/airoha/airoha_ppe.c
@@ -343,7 +343,7 @@ static int airoha_ppe_foe_entry_prepare(struct airoha_eth *eth,
return -EINVAL;
port = dev->port;
- if (dsa_port >= 0 || eth->ports[1])
+ if (dsa_port >= 0 || airoha_is_lan_gdm_dev(dev))
pse_port = port->id == 4 ? FE_PSE_PORT_GDM4
: port->id;
else
--
2.53.0
^ permalink raw reply related
* [PATCH net-next v3 12/12] net: airoha: Rename get_src_port_id callback in get_sport
From: Lorenzo Bianconi @ 2026-04-06 10:34 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Lorenzo Bianconi
Cc: Christian Marangi, Benjamin Larsson, linux-arm-kernel,
linux-mediatek, netdev, devicetree
In-Reply-To: <20260406-airoha-eth-multi-serdes-v3-0-ab6ea49d59ff@kernel.org>
For code consistency, rename get_src_port_id callback in get_sport.
Please note this patch does not introduce any logical change and it is
just a cosmetic patch.
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/ethernet/airoha/airoha_eth.c | 12 ++++++------
drivers/net/ethernet/airoha/airoha_eth.h | 2 +-
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
index 9988011dca53..c14dee3c9bfb 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.c
+++ b/drivers/net/ethernet/airoha/airoha_eth.c
@@ -1770,7 +1770,7 @@ static int airoha_set_gdm2_loopback(struct airoha_gdm_dev *dev)
airoha_fe_clear(eth, REG_FE_VIP_PORT_EN, BIT(AIROHA_GDM2_IDX));
airoha_fe_clear(eth, REG_FE_IFC_PORT_EN, BIT(AIROHA_GDM2_IDX));
- src_port = eth->soc->ops.get_src_port_id(port, dev->nbq);
+ src_port = eth->soc->ops.get_sport(port, dev->nbq);
if (src_port < 0)
return src_port;
@@ -3102,7 +3102,7 @@ static int airoha_alloc_gdm_port(struct airoha_eth *eth,
/* Verify the provided nbq parameter is valid */
nbq = be32_to_cpup(nbq_ptr);
- err = eth->soc->ops.get_src_port_id(port, nbq);
+ err = eth->soc->ops.get_sport(port, nbq);
if (err < 0) {
of_node_put(node);
return err;
@@ -3309,7 +3309,7 @@ static const char * const en7581_xsi_rsts_names[] = {
"xfp-mac",
};
-static int airoha_en7581_get_src_port_id(struct airoha_gdm_port *port, int nbq)
+static int airoha_en7581_get_sport(struct airoha_gdm_port *port, int nbq)
{
switch (port->id) {
case AIROHA_GDM3_IDX:
@@ -3373,7 +3373,7 @@ static const char * const an7583_xsi_rsts_names[] = {
"xfp-mac",
};
-static int airoha_an7583_get_src_port_id(struct airoha_gdm_port *port, int nbq)
+static int airoha_an7583_get_sport(struct airoha_gdm_port *port, int nbq)
{
switch (port->id) {
case AIROHA_GDM3_IDX:
@@ -3431,7 +3431,7 @@ static const struct airoha_eth_soc_data en7581_soc_data = {
.num_xsi_rsts = ARRAY_SIZE(en7581_xsi_rsts_names),
.num_ppe = 2,
.ops = {
- .get_src_port_id = airoha_en7581_get_src_port_id,
+ .get_sport = airoha_en7581_get_sport,
.get_dev_from_sport = airoha_en7581_get_dev_from_sport,
},
};
@@ -3442,7 +3442,7 @@ static const struct airoha_eth_soc_data an7583_soc_data = {
.num_xsi_rsts = ARRAY_SIZE(an7583_xsi_rsts_names),
.num_ppe = 1,
.ops = {
- .get_src_port_id = airoha_an7583_get_src_port_id,
+ .get_sport = airoha_an7583_get_sport,
.get_dev_from_sport = airoha_an7583_get_dev_from_sport,
},
};
diff --git a/drivers/net/ethernet/airoha/airoha_eth.h b/drivers/net/ethernet/airoha/airoha_eth.h
index 8dec25fa0478..ec31a3b5efc3 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.h
+++ b/drivers/net/ethernet/airoha/airoha_eth.h
@@ -591,7 +591,7 @@ struct airoha_eth_soc_data {
int num_xsi_rsts;
int num_ppe;
struct {
- int (*get_src_port_id)(struct airoha_gdm_port *port, int nbq);
+ int (*get_sport)(struct airoha_gdm_port *port, int nbq);
int (*get_dev_from_sport)(struct airoha_qdma_desc *desc,
u16 *port, u16 *dev);
} ops;
--
2.53.0
^ permalink raw reply related
* RE: [PATCH v6 4/4] iio: adc: ad4691: add SPI offload support
From: Sabau, Radu bogdan @ 2026-04-06 10:39 UTC (permalink / raw)
To: David Lechner, Lars-Peter Clausen, Hennerich, Michael,
Jonathan Cameron, Sa, Nuno, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Uwe Kleine-König,
Liam Girdwood, Mark Brown, Linus Walleij, Bartosz Golaszewski,
Philipp Zabel, Jonathan Corbet, Shuah Khan
Cc: linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-pwm@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-doc@vger.kernel.org
In-Reply-To: <22b44acb-bfb5-4b97-8fa2-aeb4aec704c2@baylibre.com>
> -----Original Message-----
> From: David Lechner <dlechner@baylibre.com>
> Sent: Saturday, April 4, 2026 6:57 PM
...
> > +
> > #define AD4691_CHANNEL(ch)
> \
> > { \
> > .type = IIO_VOLTAGE, \
> > @@ -122,11 +155,9 @@ struct ad4691_chip_info {
> > .info_mask_shared_by_all = BIT(IIO_CHAN_INFO_SCALE),
> \
> > .channel = ch, \
> > .scan_index = ch, \
> > - .scan_type = { \
> > - .sign = 'u', \
> > - .realbits = 16, \
> > - .storagebits = 16, \
> > - }, \
> > + .has_ext_scan_type = 1,
> \
> > + .ext_scan_type = ad4691_scan_types, \
> > + .num_ext_scan_type = ARRAY_SIZE(ad4691_scan_types),
> \
>
> Usually, we just make two separte ad4691_chip_info structs for offload
> vs. not offload.
>
> ext_scan_type is generally only used when the scan type can change
> dynamically after probe.
>
So, just to be clear, you are saying I should have different chip_info structs
and change the triggered-buffer for offload ones if offload is present?
I am asking since offload has different scan types as well, and this would
mean 3 different chip_info structs for each chip -> total of 12 chip_info structs,
each with a different channel array, or perhaps there is a more compact way
to have this implemented.
I could make the channel arrays use the same macro and have the scan_type
reversed to storage and shift done as parameters.
Please let me know your thoughts on this.
> > }
> >
> > static const struct iio_chan_spec ad4691_channels[] = {
> > @@ -221,6 +252,17 @@ static const struct ad4691_chip_info
> ad4694_chip_info = {
> > .max_rate = 1 * HZ_PER_MHZ,
> > };
> >
...
> > }
> >
> > @@ -883,6 +1184,20 @@ static ssize_t sampling_frequency_store(struct
> device *dev,
> > if (iio_buffer_enabled(indio_dev))
> > return -EBUSY;
> >
> > + if (st->manual_mode && st->offload) {
> > + struct spi_offload_trigger_config config = {
> > + .type = SPI_OFFLOAD_TRIGGER_PERIODIC,
> > + .periodic = { .frequency_hz = freq },
> > + };
>
> Same comment as other patches. This needs to account for oversampling
> ratio.
>
I am thinking that since we would have different chip_info structs, manual
mode channels could omit the oversampling attribute, since it is not supported
by the chip on this mode.
> > +
> > + ret = spi_offload_trigger_validate(st->offload->trigger,
> &config);
> > + if (ret)
> > + return ret;
> > +
> > + st->offload->trigger_hz = config.periodic.frequency_hz;
> > + return len;
> > + }
> > +
> > ret = ad4691_set_pwm_freq(st, freq);
> > if (ret)
> > return ret;
> > @@ -968,10 +1283,23 @@ static irqreturn_t ad4691_trigger_handler(int
> irq, void *p)
> > return IRQ_HANDLED;
> > }
> >
> > +static int ad4691_get_current_scan_type(const struct iio_dev *indio_dev,
> > + const struct iio_chan_spec *chan)
> > +{
> > + struct ad4691_state *st = iio_priv(indio_dev);
> > +
> > + if (!st->offload)
> > + return AD4691_SCAN_TYPE_NORMAL;
> > + if (st->manual_mode)
> > + return AD4691_SCAN_TYPE_OFFLOAD_MANUAL;
> > + return AD4691_SCAN_TYPE_OFFLOAD_CNV;
> > +}
> > +
> > static const struct iio_info ad4691_info = {
> > .read_raw = &ad4691_read_raw,
> > .write_raw = &ad4691_write_raw,
> > .read_avail = &ad4691_read_avail,
> > + .get_current_scan_type = &ad4691_get_current_scan_type,
> > .debugfs_reg_access = &ad4691_reg_access,
> > };
> >
> > @@ -1195,9 +1523,75 @@ static int ad4691_setup_triggered_buffer(struct
> iio_dev *indio_dev,
> >
> &ad4691_manual_buffer_setup_ops);
> > }
> >
> > +static int ad4691_setup_offload(struct iio_dev *indio_dev,
> > + struct ad4691_state *st,
> > + struct spi_offload *spi_offload)
> > +{
> > + struct device *dev = regmap_get_device(st->regmap);
> > + struct ad4691_offload_state *offload;
> > + struct dma_chan *rx_dma;
> > + int ret;
> > +
> > + offload = devm_kzalloc(dev, sizeof(*offload), GFP_KERNEL);
> > + if (!offload)
> > + return -ENOMEM;
> > +
> > + offload->spi = spi_offload;
> > + st->offload = offload;
> > +
> > + if (st->manual_mode) {
> > + offload->trigger =
> > + devm_spi_offload_trigger_get(dev, offload->spi,
> > +
> SPI_OFFLOAD_TRIGGER_PERIODIC);
> > + if (IS_ERR(offload->trigger))
> > + return dev_err_probe(dev, PTR_ERR(offload->trigger),
> > + "Failed to get periodic offload
> trigger\n");
> > +
> > + offload->trigger_hz = st->info->max_rate;
>
> I think I mentioned this elsewhere, but can we really get max_rate in manual
> mode
> due to the extra SPI overhead? Probably safer to start with a lower rate.
You are right a slower rate would be nicer, from my tests 311kHz worked perfect
with a 10MHz SPI frequency, but perhaps these numbers are a bit "odd".
How do you feel about 100kHz for a starting sample rate?
>
> > + } else {
> > + struct spi_offload_trigger_info trigger_info = {
> > + .fwnode = dev_fwnode(dev),
> > + .ops = &ad4691_offload_trigger_ops,
> > + .priv = st,
> > + };
> > +
> > + ret = devm_spi_offload_trigger_register(dev, &trigger_info);
> > + if (ret)
> > + return dev_err_probe(dev, ret,
> > + "Failed to register offload
> trigger\n");
> > +
> > + offload->trigger =
> > + devm_spi_offload_trigger_get(dev, offload->spi,
> > +
> SPI_OFFLOAD_TRIGGER_DATA_READY);
> > + if (IS_ERR(offload->trigger))
> > + return dev_err_probe(dev, PTR_ERR(offload->trigger),
> > + "Failed to get DATA_READY offload
> trigger\n");
> > + }
> > +
> > + rx_dma = devm_spi_offload_rx_stream_request_dma_chan(dev,
> offload->spi);
> > + if (IS_ERR(rx_dma))
> > + return dev_err_probe(dev, PTR_ERR(rx_dma),
> > + "Failed to get offload RX DMA channel\n");
> > +
> > + if (st->manual_mode)
> > + indio_dev->setup_ops =
> &ad4691_manual_offload_buffer_setup_ops;
> > + else
> > + indio_dev->setup_ops =
> &ad4691_cnv_burst_offload_buffer_setup_ops;
> > +
> > + ret = devm_iio_dmaengine_buffer_setup_with_handle(dev, indio_dev,
> rx_dma,
> > +
> IIO_BUFFER_DIRECTION_IN);
> > + if (ret)
> > + return ret;
> > +
> > + indio_dev->buffer->attrs = ad4691_buffer_attrs;
>
> Should including ad4691_buffer_attrs depend on st->manual_mode?
>
> I thought it was only used when PWM is connected to CNV.
>
For offload manual mode, I thought buffer sampling frequency should also be available,
since the offload trigger's frequency is accessible.
> > +
> > + return 0;
> > +}
> > +
> > static int ad4691_probe(struct spi_device *spi)
> > {
> > struct device *dev = &spi->dev;
> > + struct spi_offload *spi_offload;
> > struct iio_dev *indio_dev;
> > struct ad4691_state *st;
> > int ret;
> > @@ -1232,6 +1626,13 @@ static int ad4691_probe(struct spi_device *spi)
> > if (ret)
> > return ret;
> >
> > + spi_offload = devm_spi_offload_get(dev, spi,
> &ad4691_offload_config);
> > + ret = PTR_ERR_OR_ZERO(spi_offload);
> > + if (ret == -ENODEV)
> > + spi_offload = NULL;
> > + else if (ret)
> > + return dev_err_probe(dev, ret, "Failed to get SPI offload\n");
> > +
> > indio_dev->name = st->info->name;
> > indio_dev->info = &ad4691_info;
> > indio_dev->modes = INDIO_DIRECT_MODE;
> > @@ -1239,7 +1640,10 @@ static int ad4691_probe(struct spi_device *spi)
> > indio_dev->channels = st->info->channels;
> > indio_dev->num_channels = st->info->num_channels;
>
> As mentioned earlier, we generally want separate channel structs
> for SPI offload. These will also have different num_channels because
> there is no timestamp channel in SPI offload.
If different chip_info structs will be used, wouldn't they already have specific
channels attached to them?
^ permalink raw reply
* Re: [PATCH v5 0/7] pinctrl: Add generic pinctrl for board-level mux chips
From: Frank Li @ 2026-04-06 10:54 UTC (permalink / raw)
To: Peter Rosin, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Rafał Miłecki, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: linux-kernel, linux-gpio, devicetree, imx, linux-arm-kernel,
Haibo Chen, Conor Dooley, Ahmad Fatoum
In-Reply-To: <20260327-pinctrl-mux-v5-0-d4aec9d62c62@nxp.com>
On Fri, Mar 27, 2026 at 05:33:57PM -0400, Frank Li wrote:
Linus Walleij:
Any chance to pick this for 7.1?
Frank
>
^ permalink raw reply
* [PATCH v8 0/2] Enable secondary USB controller in host mode
From: Swati Agarwal @ 2026-04-06 11:01 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Swati Agarwal
Enable secondary USB controller in host mode.
Changes in v8:
Removed unsed nodes.
Changes in v7:
Split Driver and DT patch for USB1 controller and USB1 HUB support
Changes in v6:
- Removed vdd12-supply property status for all hubs.
- Added connections between genesys hub, HD3 port controller and type-C
connector as follows.
GL3590 USB HD3SS3220 Type‑C USB TYPE‑C
HUB Port Controller Connector
HS HUB HS con
|------------------------------------|
SS HUB HD3-out SBU con
|--------------------|
HD3-in SS con
|---------------------|
Changes in v5:
Updated comment description in DT.
Updated vdd-supply status for other hubs in bindings.
Changes in v4:
Updated power supply property for hub.
Updated details for all 4 ports of hub.
Changes in v3:
Updated binding properties for genesys hub.
Changes in v2:
Add Genesys Logic GL3590 hub support.
Rename hd3ss3220_ instance for primary port controller.
Link to v7:
https://lore.kernel.org/all/20260403100753.3477925-1-swati.agarwal@oss.qualcomm.com/
Link to v6:
https://lore.kernel.org/all/20260318040644.3591478-1-swati.agarwal@oss.qualcomm.com/
Link to v5:
https://lore.kernel.org/all/20260122092852.887624-1-swati.agarwal@oss.qualcomm.com/
Link to v4:
https://lore.kernel.org/all/20260120103312.2174727-1-swati.agarwal@oss.qualcomm.com/
Link to v3:
https://lore.kernel.org/all/20251220063537.3639535-1-swati.agarwal@oss.qualcomm.com/
Link to v2:
https://lore.kernel.org/all/20251216120749.94007-1-swati.agarwal@oss.qualcomm.com/
Link to v1:
https://lore.kernel.org/all/20251203-swati-v1-1-250efcb4e6a7@oss.qualcomm.com/
Swati Agarwal (2):
arm64: dts: qcom: lemans-evk: Rename hd3ss3220_ instance for primary
port controller
arm64: dts: qcom: lemans-evk: Enable secondary USB controller in host
mode
arch/arm64/boot/dts/qcom/lemans-evk.dts | 176 +++++++++++++++++++++++-
1 file changed, 172 insertions(+), 4 deletions(-)
--
2.34.1
^ permalink raw reply
* [PATCH v8 1/2] arm64: dts: qcom: lemans-evk: Rename hd3ss3220_ instance for primary port controller
From: Swati Agarwal @ 2026-04-06 11:01 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Swati Agarwal,
Konrad Dybcio, Dmitry Baryshkov
In-Reply-To: <20260406110113.1709886-1-swati.agarwal@oss.qualcomm.com>
Rename the hd3ss3220_ instance to improve clarity and simplify usage when
adding a secondary port controller.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Swati Agarwal <swati.agarwal@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/lemans-evk.dts | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/lemans-evk.dts b/arch/arm64/boot/dts/qcom/lemans-evk.dts
index c665db6a4595..522d407c9925 100644
--- a/arch/arm64/boot/dts/qcom/lemans-evk.dts
+++ b/arch/arm64/boot/dts/qcom/lemans-evk.dts
@@ -63,7 +63,7 @@ port@1 {
reg = <1>;
usb0_con_ss_ep: endpoint {
- remote-endpoint = <&hd3ss3220_in_ep>;
+ remote-endpoint = <&hd3ss3220_0_in_ep>;
};
};
};
@@ -551,7 +551,7 @@ ports {
port@0 {
reg = <0>;
- hd3ss3220_in_ep: endpoint {
+ hd3ss3220_0_in_ep: endpoint {
remote-endpoint = <&usb0_con_ss_ep>;
};
};
@@ -559,7 +559,7 @@ hd3ss3220_in_ep: endpoint {
port@1 {
reg = <1>;
- hd3ss3220_out_ep: endpoint {
+ hd3ss3220_0_out_ep: endpoint {
remote-endpoint = <&usb_0_dwc3_ss>;
};
};
@@ -989,7 +989,7 @@ &usb_0_dwc3_hs {
};
&usb_0_dwc3_ss {
- remote-endpoint = <&hd3ss3220_out_ep>;
+ remote-endpoint = <&hd3ss3220_0_out_ep>;
};
&usb_0_hsphy {
--
2.34.1
^ permalink raw reply related
* [PATCH v8 2/2] arm64: dts: qcom: lemans-evk: Enable secondary USB controller in host mode
From: Swati Agarwal @ 2026-04-06 11:01 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Swati Agarwal
In-Reply-To: <20260406110113.1709886-1-swati.agarwal@oss.qualcomm.com>
Enable secondary USB controller in host mode on lemans EVK Platform.
Secondary USB controller is connected to a Genesys Logic USB HUB GL3590
having 4 ports. The ports of hub that are present on lemans EVK standalone
board are used as follows:-
1) port-1 is connected to HD3SS3220 Type-C port controller.
2) port-4 is used for the M.2 E key on corekit. Standard core kit uses UART
for Bluetooth. This port is to be used only if user optionally replaces the
WiFi card with the NFA765 chip which uses USB for Bluetooth.
Remaining 2 ports will become functional when the interface plus mezzanine
board is stacked on top of corekit:
3) port-2 is connected to another hub which is present on the mezz through
which 4 type-A ports are connected.
4) port-3 is used for the M.2 B key for a 5G card when the mezz is
connected.
Secondary USB Controller
↓
GL3590 USB Hub (4 ports)
|
|-- Port 1 → HD3SS3220 Type‑C Port Controller → USB‑C Connector
|
|-- Port 2 → Mezzanine USB Hub (when mezz attached)
|
|-- Port 3 → M.2 B‑Key Slot (when mezz attached)
|
|-- Port 4 → M.2 E‑Key Slot
(Default: BT via UART;
USB only if NFA765 module is installed)
Mark the second USB controller as host only capable and add the HD3SS3220
Type-C port controller along with Type-C connector for controlling vbus
supply.
Signed-off-by: Swati Agarwal <swati.agarwal@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/lemans-evk.dts | 168 ++++++++++++++++++++++++
1 file changed, 168 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/lemans-evk.dts b/arch/arm64/boot/dts/qcom/lemans-evk.dts
index 522d407c9925..1e9a7a6ea001 100644
--- a/arch/arm64/boot/dts/qcom/lemans-evk.dts
+++ b/arch/arm64/boot/dts/qcom/lemans-evk.dts
@@ -69,6 +69,37 @@ usb0_con_ss_ep: endpoint {
};
};
+ connector-1 {
+ compatible = "usb-c-connector";
+ label = "USB1-Type-C";
+ data-role = "host";
+ power-role = "source";
+
+ vbus-supply = <&usb1_vbus>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ usb1_con_hs_ep: endpoint {
+ remote-endpoint = <&usb_hub_2_1>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ usb1_con_ss_ep: endpoint {
+ remote-endpoint = <&hd3ss3220_1_in_ep>;
+ };
+
+ };
+ };
+ };
+
connector-2 {
compatible = "gpio-usb-b-connector", "usb-b-connector";
label = "micro-USB";
@@ -161,6 +192,15 @@ usb0_vbus: regulator-usb0-vbus {
enable-active-high;
};
+ usb1_vbus: regulator-usb1-vbus {
+ compatible = "regulator-fixed";
+ regulator-name = "usb1_vbus";
+ gpio = <&expander1 3 GPIO_ACTIVE_HIGH>;
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ enable-active-high;
+ };
+
usb2_vbus: regulator-usb2-vbus {
compatible = "regulator-fixed";
regulator-name = "usb2_vbus";
@@ -565,6 +605,39 @@ hd3ss3220_0_out_ep: endpoint {
};
};
};
+
+ usb-typec@47 {
+ compatible = "ti,hd3ss3220";
+ reg = <0x47>;
+
+ interrupts-extended = <&pmm8654au_2_gpios 6 IRQ_TYPE_EDGE_FALLING>;
+
+ id-gpios = <&tlmm 51 GPIO_ACTIVE_HIGH>;
+
+ pinctrl-0 = <&usb1_id>, <&usb1_intr>;
+ pinctrl-names = "default";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ hd3ss3220_1_in_ep: endpoint {
+ remote-endpoint = <&usb1_con_ss_ep>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ hd3ss3220_1_out_ep: endpoint {
+ remote-endpoint = <&usb_hub_3_1>;
+ };
+ };
+ };
+ };
};
&i2c18 {
@@ -749,6 +822,14 @@ usb0_intr_state: usb0-intr-state {
power-source = <0>;
};
+ usb1_intr: usb1-intr-state {
+ pins = "gpio6";
+ function = "normal";
+ input-enable;
+ bias-pull-up;
+ power-source = <0>;
+ };
+
usb2_id: usb2-id-state {
pins = "gpio11";
function = "normal";
@@ -949,6 +1030,12 @@ usb_id: usb-id-state {
function = "gpio";
bias-pull-up;
};
+
+ usb1_id: usb1-id-state {
+ pins = "gpio51";
+ function = "gpio";
+ bias-pull-up;
+ };
};
&uart0 {
@@ -1007,6 +1094,87 @@ &usb_0_qmpphy {
status = "okay";
};
+&usb_1 {
+ dr_mode = "host";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ status = "okay";
+
+ usb_hub_2_x: hub@1 {
+ compatible = "usb5e3,610";
+ reg = <1>;
+
+ peer-hub = <&usb_hub_3_x>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@1 {
+ reg = <1>;
+
+ usb_hub_2_1: endpoint {
+ remote-endpoint = <&usb1_con_hs_ep>;
+ };
+ };
+
+ /*
+ * Port-4 is connected to M.2 E key connector on corekit.
+ */
+ port@4 {
+ reg = <4>;
+
+ usb_hub_2_4: endpoint {
+ };
+ };
+ };
+ };
+
+ usb_hub_3_x: hub@2 {
+ compatible = "usb5e3,625";
+ reg = <2>;
+
+ peer-hub = <&usb_hub_2_x>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@1 {
+ reg = <1>;
+
+ usb_hub_3_1: endpoint {
+ remote-endpoint = <&hd3ss3220_1_out_ep>;
+ };
+ };
+
+ port@4 {
+ reg = <4>;
+
+ usb_hub_3_4: endpoint {
+ };
+ };
+ };
+ };
+};
+
+&usb_1_hsphy {
+ vdda-pll-supply = <&vreg_l7a>;
+ vdda18-supply = <&vreg_l6c>;
+ vdda33-supply = <&vreg_l9a>;
+
+ status = "okay";
+};
+
+&usb_1_qmpphy {
+ vdda-phy-supply = <&vreg_l1c>;
+ vdda-pll-supply = <&vreg_l7a>;
+
+ status = "okay";
+};
+
&usb_2 {
status = "okay";
};
--
2.34.1
^ permalink raw reply related
* RE: [PATCH v6 4/4] iio: adc: ad4691: add SPI offload support
From: Sabau, Radu bogdan @ 2026-04-06 11:08 UTC (permalink / raw)
To: David Lechner, Lars-Peter Clausen, Hennerich, Michael,
Jonathan Cameron, Sa, Nuno, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Uwe Kleine-König,
Liam Girdwood, Mark Brown, Linus Walleij, Bartosz Golaszewski,
Philipp Zabel, Jonathan Corbet, Shuah Khan
Cc: linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-pwm@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-doc@vger.kernel.org
In-Reply-To: <LV9PR03MB8414CB6B07EA81FB5A42436AF75DA@LV9PR03MB8414.namprd03.prod.outlook.com>
> -----Original Message-----
> From: Sabau, Radu bogdan
> Sent: Monday, April 6, 2026 1:39 PM
...
> > > #define AD4691_CHANNEL(ch)
> > \
> > > { \
> > > .type = IIO_VOLTAGE, \
> > > @@ -122,11 +155,9 @@ struct ad4691_chip_info {
> > > .info_mask_shared_by_all = BIT(IIO_CHAN_INFO_SCALE),
> > \
> > > .channel = ch, \
> > > .scan_index = ch, \
> > > - .scan_type = { \
> > > - .sign = 'u', \
> > > - .realbits = 16, \
> > > - .storagebits = 16, \
> > > - }, \
> > > + .has_ext_scan_type = 1,
> > \
> > > + .ext_scan_type = ad4691_scan_types, \
> > > + .num_ext_scan_type = ARRAY_SIZE(ad4691_scan_types),
> > \
> >
> > Usually, we just make two separte ad4691_chip_info structs for offload
> > vs. not offload.
> >
> > ext_scan_type is generally only used when the scan type can change
> > dynamically after probe.
> >
>
> So, just to be clear, you are saying I should have different chip_info structs
> and change the triggered-buffer for offload ones if offload is present?
> I am asking since offload has different scan types as well, and this would
> mean 3 different chip_info structs for each chip -> total of 12 chip_info structs,
> each with a different channel array, or perhaps there is a more compact way
> to have this implemented.
> I could make the channel arrays use the same macro and have the scan_type
> reversed to storage and shift done as parameters.
>
I have given this a thought and I think this could be done in a more compact way:
1. Parametrize AD4691_CHANNEL to accept storagebits and shift, then define 4 channel
arrays:
- ad4691_channels[] - 16ch + timestamp (triggered-buffer path)
- ad4693_channels[] - 8ch + timestamp (triggered-buffer path)
- ad4691_offload_cnv_channels[] - 16 entries, storagebits=32, shift = 0
- ad4691_offload_manual_channels[] - 16 entries, storagebits=32, shift=16
The two offload arrays are shared across both chip families. Since num_channels
bound the interation in the IIO core, the 8ch chips simply use the first 8 entries of
the 16-entry offload arrays. Triggered-buffer path would need different channel
arrays since the timestamp index would be different, and offload doesn't use
timestamp.
2. chip_info could then stay at 2 structs, and have channels selected at probe for the
indio_dev, or have 4 chip info structs each having its own channels assigned, and only
num_channels could be changed at probe.
> Please let me know your thoughts on this.
^ permalink raw reply
* Re: [PATCH v3 11/15] media: qcom: Switch to generic PAS TZ APIs
From: Sumit Garg @ 2026-04-06 11:42 UTC (permalink / raw)
To: Jorge Ramirez, vikash.garodia
Cc: linux-arm-msm, devicetree, dri-devel, freedreno, linux-media,
netdev, linux-wireless, ath12k, linux-remoteproc, andersson,
konradybcio, robh, krzk+dt, conor+dt, robin.clark, sean, akhilpo,
lumag, abhinav.kumar, jesszhan0024, marijn.suijten, airlied,
simona, dikshita.agarwal, bod, mchehab, elder, andrew+netdev,
davem, edumazet, kuba, pabeni, jjohnson, mathieu.poirier,
trilokkumar.soni, mukesh.ojha, pavan.kondeti, tonyh,
vignesh.viswanathan, srinivas.kandagatla, amirreza.zarrabi,
jens.wiklander, op-tee, apurupa, skare, harshal.dev, linux-kernel,
Sumit Garg
In-Reply-To: <ac-KQ7e8-syph1Zl@trex>
Hi Jorge,
On Fri, Apr 03, 2026 at 11:37:07AM +0200, Jorge Ramirez wrote:
> On 27/03/26 18:40:39, Sumit Garg wrote:
> > From: Sumit Garg <sumit.garg@oss.qualcomm.com>
> >
> > Switch qcom media client drivers over to generic PAS TZ APIs. Generic PAS
> > TZ service allows to support multiple TZ implementation backends like QTEE
> > based SCM PAS service, OP-TEE based PAS service and any further future TZ
> > backend service.
>
> OP-TEE based PAS service relies on the linux driver to configure the
> iommu (just as it is done on the no_tz case). This generic patch does
> not cover that requirement.
That's exactly the reason why the kodiak EL2 dtso disables venus by
default in patch #1 due to missing IOMMU configuration.
>
> Because of that, it is probably better if the commit message doesnt
> mention OP-TEE and instead maybe indicate that PAS wll support TEEs that
> implement the same restrictions that QTEE (ie, iommu configuration).
The scope for this patch is to just adopt the generic PAS layer without
affecting the client functionality.
>
> I can send an RFC for OP-TEE support based on the integration work being
> carried out here [1]
@Vikash may know better details about support for IOMMU configuration
for venus since it's a generic functionality missing when Linux runs in
EL2 whether it's with QTEE or OP-TEE.
However, feel free to propose your work to initiate discussions again.
>
> [1] https://github.com/OP-TEE/optee_os/pull/7721#discussion_r3016923507
-Sumit
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: arm: qcom: Add monaco-evk-ac support
From: Umang Chheda @ 2026-04-06 11:58 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Richard Cochran, linux-arm-msm, devicetree,
linux-kernel, netdev
In-Reply-To: <7r6373fo56alzqa4e2zzdnsgwfhgdkmbhxe4cvdo4p7fg3zren@eyiml4uedfbn>
On 4/5/2026 1:09 AM, Dmitry Baryshkov wrote:
> On Sat, Apr 04, 2026 at 04:15:54PM +0530, Umang Chheda wrote:
>>
>>
>> On 4/4/2026 1:58 AM, Dmitry Baryshkov wrote:
>>> On Fri, Apr 03, 2026 at 04:14:28PM +0530, Umang Chheda wrote:
>>>> Hello Dmitry,
>>>>
>>>> On 4/1/2026 5:06 PM, Dmitry Baryshkov wrote:
>>>>> On Wed, Apr 01, 2026 at 12:14:42AM +0530, Umang Chheda wrote:
>>>>>> Introduce bindings for the monaco-evk-ac IoT board, which is
>>>>>> based on the monaco-ac (QCS8300-AC) SoC variant.
>>>>>
>>>>> If it is a different SoC SKU, should it be reflected in the SoC compat
>>>>> strings?
>>>>
>>>> Monaco‑AC does not introduce any S/W differences compared to Monaco SoC
>>>> -- All IP blocks and bindings remain identical from S/W PoV, Hence
>>>> haven't included the SoC SKU in the SoC compat strings.
>>>>
>>>> Hope this is okay ? Your view on this ?
>>>
>>> You are descibing -AC as the main difference between the kits, but then
>>> you say that -AC doesn't bring new software interfaces. What is the
>>> difference then between monako-evk and the -ac variant?
>>>
>>
>> The major difference between monaco-evk and monaco-ac-evk boards is that
>> of power grid. monaco-evk requires 4 PMICs (2x PM8650AU + Maxim MAX20018
>> + TI TPS6594) to support higher power requirements of monaco-AA variant
>> of SoC which supports upto 40 TOPS of NPU - whereas this board
>> "monaco-ac-evk" supports 20 TOPS of NPU and has lesser power
>> requirements hence 2 PMICs suffice the power requirements (2x PM8650AU).
>
> Is that the only difference? Is the PCB the same? Should we have a
> single common file for those two variants?
Yes, the major differences b/w 2 boards are:
1. Monaco-AA version of SoC in monaco-evk v/s Monaco-AC version of SoC
in monaco-ac-evk board.
2. 4 PMICs (2x PM8650AU + Maxim MAX20018 + TI TPS6594) in monaco-evk
board v/s 2 PMICs (2x PM8650AU) in monaco-ac-evk board.
PCB is different for both of the boards.
Can I restructure as below to avoid code duplication ?
"monaco-evk-common.dtsi" --> This will add/enable all the common
peripherals of monaco-evk and monaco-ac-evk.
monaco-evk.dts --> Include "monaco-evk-common.dtsi" and enable
monaco-evk specific changes.
monaco-ac-evk.dts --> Include "monaco-evk-common.dtsi" and enable
monaco-ac specific changes
Does the above file re-structuring looks good ?
>
>>
>>
>>> Also, from the naming point of view, it is monako-ac-evk, not the other
>>> way.
>>
>> Ack, will change this to "monaco-ac-evk" in the next version.
>>
>> Also, should I change DT name "monaco-ac-sku.dts" instead of current
>> "monaco-evk-ac-sku" ?
>
> monako-ac-evk.dtsi.
>
>>
>>>
>>>>
>>>>>
>>>>>>
>>>>>> Signed-off-by: Umang Chheda <umang.chheda@oss.qualcomm.com>
>>>>>> ---
>>>>>> Documentation/devicetree/bindings/arm/qcom.yaml | 1 +
>>>>>> 1 file changed, 1 insertion(+)
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
>>>>>> index ca880c105f3b..c76365a89687 100644
>>>>>> --- a/Documentation/devicetree/bindings/arm/qcom.yaml
>>>>>> +++ b/Documentation/devicetree/bindings/arm/qcom.yaml
>>>>>> @@ -918,6 +918,7 @@ properties:
>>>>>> - enum:
>>>>>> - arduino,monza
>>>>>> - qcom,monaco-evk
>>>>>> + - qcom,monaco-evk-ac
>>>>>> - qcom,qcs8300-ride
>>>>>> - const: qcom,qcs8300
>>>>>>
>>>>>>
>>>>>> --
>>>>>> 2.34.1
>>>>>>
>>>>>
>>>>
>>>> Thanks,
>>>> Umang
>>>
>>
>> Thanks,
>> Umang
>>
>>
>
Thanks,
Umang
^ permalink raw reply
* [PATCH RFC 0/3] dt-bindings: dsp: fsl,dsp: small cleanup
From: Laurentiu Mihalcea @ 2026-04-06 12:20 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Viresh Kumar,
Tushar Khandelwal, Shengjiu Wang, Daniel Baluta
Cc: devicetree, linux-kernel
From: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
Hello everyone,
So, with this patch series, we attempt to tidy up the fsl,dsp binding a
bit. Most importantly (and the reason why this was sent as an RFC), I'd
like to remove the compatibles corresponding to the SOF programming model
(i.e. the compatibles ending in "-dsp") from the binding. The reasons are
explained in the commit message, but basically the problem we're dealing
with is that we have a binding file in which two relatively different
programming models have been crammed together.
Since at the moment there's no plan to upstream the devicetrees making use
of the SOF programming model, we are stuck having to also take the SOF
programming model into consideration when making changes to the binding
(even if said changes only target the RPROC programming model).
Now, since there's no devicetree users in the upstream kernel for the SOF
programming model, I'd like to permanently remove it from the fsl,dsp
binding. If the SOF devicetrees are ever upstreamed then I think the
bindings should follow the model of fsl,imx95-cm7.yaml (i.e. one binding
per chip or group of chips, including the common fsl,sof-cpu)
As for the other projects, u-boot seems to have a devicetree node using
the "fsl,imx8mp-dsp" compatible (node has status "disabled", though)
defined at "arch/arm/dts/imx8mp.dtsi". The node configuration seems to
follow that which was used in the upstream kernel and modified via
commit f048f2126fcc ("arm64: dts: imx8mp: Configure dsp node for rproc
usage") to use the RPROC programming model.
If need be, I can send a patch to u-boot in which we configure the DT
node for RPROC like we did in Linux.
Let me know if this series would be acceptable given the current
situation.
Thanks!
Laurentiu Mihalcea (3):
dt-bindings: dsp: fsl,dsp: drop references to SOF programming model
dt-bindings: dsp: fsl,dsp: remove reserved memory definitions
dt-bindings: dsp: fsl,dsp: remove descriptions for common properties
.../devicetree/bindings/dsp/fsl,dsp.yaml | 94 +------------------
.../bindings/mailbox/arm,mhuv2.yaml | 8 +-
2 files changed, 9 insertions(+), 93 deletions(-)
--
2.43.0
^ permalink raw reply
* [PATCH RFC 1/3] dt-bindings: dsp: fsl,dsp: drop references to SOF programming model
From: Laurentiu Mihalcea @ 2026-04-06 12:20 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Viresh Kumar,
Tushar Khandelwal, Shengjiu Wang, Daniel Baluta
Cc: devicetree, linux-kernel
In-Reply-To: <20260406122025.4515-1-laurentiumihalcea111@gmail.com>
From: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
Compatible names ending in "-dsp" are associated with the SOF programming
model, which, at the moment has no devicetree users in the upstream
kernel. Furthermore, the binding either doesn't document all of the
required properties (e.g. "port" children are missing,
"memory-region-names" is undocumented) or the properties that are
documented are wrong (e.g. fsl,imx8ulp-hifi4 needs 2 reserved memory
regions, not 1).
Since the two programming models (SOF and non-SOF) have some differences,
it would make more sense for the 8 series DSP bindings to follow the same
pattern used for MX95's CM7 (i.e. one or more binding files, including the
common fsl,sof-cpu.yaml).
Given all of this, and since, at the moment, there's no plan to upstream
the devicetrees making use of this programming model anytime soon, drop all
the references to the SOF programming model from the binding docuemnt as an
attempt to clean it up.
Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
---
.../devicetree/bindings/dsp/fsl,dsp.yaml | 67 ++-----------------
.../bindings/mailbox/arm,mhuv2.yaml | 8 +--
2 files changed, 9 insertions(+), 66 deletions(-)
diff --git a/Documentation/devicetree/bindings/dsp/fsl,dsp.yaml b/Documentation/devicetree/bindings/dsp/fsl,dsp.yaml
index e610b7636a08..7970f90781c2 100644
--- a/Documentation/devicetree/bindings/dsp/fsl,dsp.yaml
+++ b/Documentation/devicetree/bindings/dsp/fsl,dsp.yaml
@@ -17,10 +17,6 @@ description: |
properties:
compatible:
enum:
- - fsl,imx8qxp-dsp
- - fsl,imx8qm-dsp
- - fsl,imx8mp-dsp
- - fsl,imx8ulp-dsp
- fsl,imx8qxp-hifi4
- fsl,imx8qm-hifi4
- fsl,imx8mp-hifi4
@@ -59,18 +55,18 @@ properties:
List of <&phandle type channel> - 2 channels for TXDB, 2 channels for RXDB
or - 1 channel for TX, 1 channel for RX, 1 channel for RXDB
(see mailbox/fsl,mu.txt)
- minItems: 3
- maxItems: 4
+ maxItems: 3
mbox-names:
- minItems: 3
- maxItems: 4
+ items:
+ - const: tx
+ - const: rx
+ - const: rxdb
memory-region:
description:
phandle to a node describing reserved memory (System RAM memory)
used by DSP (see bindings/reserved-memory/reserved-memory.txt)
- minItems: 1
maxItems: 4
firmware-name:
@@ -110,7 +106,6 @@ allOf:
compatible:
contains:
enum:
- - fsl,imx8qxp-dsp
- fsl,imx8qxp-hifi4
then:
properties:
@@ -123,7 +118,6 @@ allOf:
compatible:
contains:
enum:
- - fsl,imx8qm-dsp
- fsl,imx8qm-hifi4
then:
properties:
@@ -135,9 +129,7 @@ allOf:
compatible:
contains:
enum:
- - fsl,imx8mp-dsp
- fsl,imx8mp-hifi4
- - fsl,imx8ulp-dsp
- fsl,imx8ulp-hifi4
then:
properties:
@@ -149,39 +141,6 @@ allOf:
compatible:
contains:
enum:
- - fsl,imx8qxp-hifi4
- - fsl,imx8qm-hifi4
- - fsl,imx8mp-hifi4
- - fsl,imx8ulp-hifi4
- then:
- properties:
- memory-region:
- minItems: 4
- mboxes:
- maxItems: 3
- mbox-names:
- items:
- - const: tx
- - const: rx
- - const: rxdb
- else:
- properties:
- memory-region:
- maxItems: 1
- mboxes:
- minItems: 4
- mbox-names:
- items:
- - const: txdb0
- - const: txdb1
- - const: rxdb0
- - const: rxdb1
- - if:
- properties:
- compatible:
- contains:
- enum:
- - fsl,imx8mp-dsp
- fsl,imx8mp-hifi4
then:
required:
@@ -191,22 +150,6 @@ allOf:
additionalProperties: false
examples:
- - |
- #include <dt-bindings/firmware/imx/rsrc.h>
- #include <dt-bindings/clock/imx8-clock.h>
- dsp@596e8000 {
- compatible = "fsl,imx8qxp-dsp";
- reg = <0x596e8000 0x88000>;
- clocks = <&adma_lpcg IMX_ADMA_LPCG_DSP_IPG_CLK>,
- <&adma_lpcg IMX_ADMA_LPCG_OCRAM_IPG_CLK>,
- <&adma_lpcg IMX_ADMA_LPCG_DSP_CORE_CLK>;
- clock-names = "ipg", "ocram", "core";
- power-domains = <&pd IMX_SC_R_MU_13B>,
- <&pd IMX_SC_R_MU_2A>;
- mbox-names = "txdb0", "txdb1", "rxdb0", "rxdb1";
- mboxes = <&lsio_mu13 2 0>, <&lsio_mu13 2 1>, <&lsio_mu13 3 0>, <&lsio_mu13 3 1>;
- memory-region = <&dsp_reserved>;
- };
- |
#include <dt-bindings/clock/imx8mp-clock.h>
#include <dt-bindings/reset/imx8mp-reset-audiomix.h>
diff --git a/Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml b/Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml
index 3828d77f6316..d6ab66f6f3d5 100644
--- a/Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml
+++ b/Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml
@@ -192,16 +192,16 @@ examples:
};
mhu_client: dsp@596e8000 {
- compatible = "fsl,imx8qxp-dsp";
+ compatible = "fsl,imx8qxp-hifi4";
reg = <0 0x596e8000 0 0x88000>;
clocks = <&adma_lpcg 0>, <&adma_lpcg 1>, <&adma_lpcg 2>;
clock-names = "ipg", "ocram", "core";
power-domains = <&pd 0>, <&pd 1>;
- mbox-names = "txdb0", "txdb1", "rxdb0", "rxdb1";
+ mbox-names = "tx", "rx", "rxdb";
mboxes = <&mhu_tx 2 0>, //data-transfer protocol with 5 windows, mhu-tx
- <&mhu_tx 3 0>, //data-transfer protocol with 7 windows, mhu-tx
<&mhu_rx 2 27>, //doorbell protocol channel 2, doorbell 27, mhu-rx
<&mhu_rx 0 0>; //data-transfer protocol with 1 window, mhu-rx
- memory-region = <&dsp_reserved>;
+ memory-region = <&dsp_vdev0buffer>, <&dsp_vdev0vring0>,
+ <&dsp_vdev0vring1>, <&dsp_reserved>;
};
};
--
2.43.0
^ permalink raw reply related
* [PATCH RFC 2/3] dt-bindings: dsp: fsl,dsp: remove reserved memory definitions
From: Laurentiu Mihalcea @ 2026-04-06 12:20 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Viresh Kumar,
Tushar Khandelwal, Shengjiu Wang, Daniel Baluta
Cc: devicetree, linux-kernel
In-Reply-To: <20260406122025.4515-1-laurentiumihalcea111@gmail.com>
From: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
There's no need to define the DT nodes referenced by the node's phandle.
Remove them.
Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
---
.../devicetree/bindings/dsp/fsl,dsp.yaml | 17 -----------------
1 file changed, 17 deletions(-)
diff --git a/Documentation/devicetree/bindings/dsp/fsl,dsp.yaml b/Documentation/devicetree/bindings/dsp/fsl,dsp.yaml
index 7970f90781c2..65ed26aa3308 100644
--- a/Documentation/devicetree/bindings/dsp/fsl,dsp.yaml
+++ b/Documentation/devicetree/bindings/dsp/fsl,dsp.yaml
@@ -153,23 +153,6 @@ examples:
- |
#include <dt-bindings/clock/imx8mp-clock.h>
#include <dt-bindings/reset/imx8mp-reset-audiomix.h>
- dsp_reserved: dsp@92400000 {
- reg = <0x92400000 0x1000000>;
- no-map;
- };
- dsp_vdev0vring0: vdev0vring0@942f0000 {
- reg = <0x942f0000 0x8000>;
- no-map;
- };
- dsp_vdev0vring1: vdev0vring1@942f8000 {
- reg = <0x942f8000 0x8000>;
- no-map;
- };
- dsp_vdev0buffer: vdev0buffer@94300000 {
- compatible = "shared-dma-pool";
- reg = <0x94300000 0x100000>;
- no-map;
- };
dsp: dsp@3b6e8000 {
compatible = "fsl,imx8mp-hifi4";
--
2.43.0
^ permalink raw reply related
* [PATCH RFC 3/3] dt-bindings: dsp: fsl,dsp: remove descriptions for common properties
From: Laurentiu Mihalcea @ 2026-04-06 12:20 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Viresh Kumar,
Tushar Khandelwal, Shengjiu Wang, Daniel Baluta
Cc: devicetree, linux-kernel
In-Reply-To: <20260406122025.4515-1-laurentiumihalcea111@gmail.com>
From: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
"mboxes", "power-domains", and "memory-region" are common properties,
which should be already documented. As such, descriptions referencing
old .txt binding files provide no additional information. Thus, remove
them.
Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
---
Documentation/devicetree/bindings/dsp/fsl,dsp.yaml | 10 ----------
1 file changed, 10 deletions(-)
diff --git a/Documentation/devicetree/bindings/dsp/fsl,dsp.yaml b/Documentation/devicetree/bindings/dsp/fsl,dsp.yaml
index 65ed26aa3308..d483a229c292 100644
--- a/Documentation/devicetree/bindings/dsp/fsl,dsp.yaml
+++ b/Documentation/devicetree/bindings/dsp/fsl,dsp.yaml
@@ -44,17 +44,10 @@ properties:
minItems: 3
power-domains:
- description:
- List of phandle and PM domain specifier as documented in
- Documentation/devicetree/bindings/power/power_domain.txt
minItems: 1
maxItems: 4
mboxes:
- description:
- List of <&phandle type channel> - 2 channels for TXDB, 2 channels for RXDB
- or - 1 channel for TX, 1 channel for RX, 1 channel for RXDB
- (see mailbox/fsl,mu.txt)
maxItems: 3
mbox-names:
@@ -64,9 +57,6 @@ properties:
- const: rxdb
memory-region:
- description:
- phandle to a node describing reserved memory (System RAM memory)
- used by DSP (see bindings/reserved-memory/reserved-memory.txt)
maxItems: 4
firmware-name:
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v2 2/4] platform: arm64: dell-xps-ec: new driver
From: Bjorn Andersson @ 2026-04-06 12:32 UTC (permalink / raw)
To: Aleksandrs Vinarskis
Cc: Bryan O'Donoghue, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Hans de Goede,
Ilpo Järvinen, linux-arm-msm, devicetree, linux-kernel,
platform-driver-x86, laurentiu.tudor1, Abel Vesa, Tobias Heider,
Val Packett
In-Reply-To: <P9IQ5Penud7CH3Yfn0bw0RXJfIhFhFGksRjP-aZwLoAxmajMfeOtLEItrcWOXwVjHE_zObIA8SYjcPVR9dkAk9KgDYLun0DJJ6dBIU-IRDI=@vinarskis.com>
On Sun, Apr 05, 2026 at 08:48:25PM +0000, Aleksandrs Vinarskis wrote:
> On Sunday, April 5th, 2026 at 02:29, Bryan O'Donoghue <bryan.odonoghue@linaro.org> wrote:
>
> > On 04/04/2026 13:55, Aleksandrs Vinarskis wrote:
> > > Introduce EC driver for Dell XPS 13 9345 (codename 'tributo') which may
> > > partially of fully compatible with Snapdragon-based Dell Latitude,
> > > Inspiron ('thena'). Primary function of this driver is unblock EC's
> > > thermal management, specifically to provide it with necessary
> > > information to control device fans, peripherals power.
> > >
> > > The driver was developed primarily by analyzing ACPI DSDT's _DSM and
> > > i2c dumps of communication between SoC and EC. Changes to Windows
> > > driver's behavior include increasing temperature feed loop from ~50ms
> > > to 100ms here.
> > >
> > > While Xps's EC is rather complex and controls practically all device
> > > peripherals including touch row's brightness and special keys such as
> > > mic mute, these do not go over this particular i2c interface.
> > >
> > > Not yet implemented features:
> > > - On lid-close IRQ event is registered. Windows performs what to
> > > appears to be thermistor constants readout, though its not obvious
> > > what it used for.
> > > - According to ACPI's _DSM there is a method to readout fans' RPM.
> > > - Initial thermistor constants were sniffed from Windows, these can be
> > > likely fine tuned for better cooling performance.
> > > - There is additional temperature reading that Windows sents to EC but
> > > more rare than others, likely SoC T_j / TZ98 or TZ4. This is the only
> > > thermal zone who's reading can exceed 115C without triggering thermal
> > > shutdown.
> > > - Given similarities between 'tributo' and 'thena' platforms, including
> > > EC i2c address, driver can be potentially extended to support both.
> > >
> > > Signed-off-by: Aleksandrs Vinarskis <alex@vinarskis.com>
> > > ---
> > > MAINTAINERS | 1 +
> > > drivers/platform/arm64/Kconfig | 12 ++
> > > drivers/platform/arm64/Makefile | 1 +
> > > drivers/platform/arm64/dell-xps-ec.c | 267 +++++++++++++++++++++++++++++++++++
> > > 4 files changed, 281 insertions(+)
> > >
> > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > index a5d175559f4468dfe363b319a1b08d3425f4d712..c150f57b60706224e5b24b0dfb3d8a9b81f36398 100644
> > > --- a/MAINTAINERS
> > > +++ b/MAINTAINERS
> > > @@ -7240,6 +7240,7 @@ DELL XPS EMBEDDED CONTROLLER DRIVER
> > > M: Aleksandrs Vinarskis <alex@vinarskis.com>
> > > S: Maintained
> > > F: Documentation/devicetree/bindings/embedded-controller/dell,xps13-9345-ec.yaml
> > > +F: drivers/platform/arm64/dell-xps-ec.c
> > >
> > > DELTA AHE-50DC FAN CONTROL MODULE DRIVER
> > > M: Zev Weiss <zev@bewilderbeest.net>
> > > diff --git a/drivers/platform/arm64/Kconfig b/drivers/platform/arm64/Kconfig
> > > index 10f905d7d6bfa5fad30a0689d3a20481268c781e..0bc8f016032bb05cb3a7cc50bdf1092da04153bc 100644
> > > --- a/drivers/platform/arm64/Kconfig
> > > +++ b/drivers/platform/arm64/Kconfig
> > > @@ -33,6 +33,18 @@ config EC_ACER_ASPIRE1
> > > laptop where this information is not properly exposed via the
> > > standard ACPI devices.
> > >
> > > +config EC_DELL_XPS
> > > + tristate "Dell XPS 9345 Embedded Controller driver"
> > > + depends on ARCH_QCOM || COMPILE_TEST
> > > + depends on I2C
> > > + depends on IIO
> > > + help
> > > + Driver for the Embedded Controller in the Qualcomm Snapdragon-based
> > > + Dell XPS 13 9345, which handles thermal management and fan speed
> > > + control.
> > > +
> > > + Say M or Y here to include this support.
> > > +
> > > config EC_HUAWEI_GAOKUN
> > > tristate "Huawei Matebook E Go Embedded Controller driver"
> > > depends on ARCH_QCOM || COMPILE_TEST
> > > diff --git a/drivers/platform/arm64/Makefile b/drivers/platform/arm64/Makefile
> > > index 60c131cff6a15bb51a49c9edab95badf513ee0f6..6768dc6c2310837374e67381cfc729bed1fdaaef 100644
> > > --- a/drivers/platform/arm64/Makefile
> > > +++ b/drivers/platform/arm64/Makefile
> > > @@ -6,6 +6,7 @@
> > > #
> > >
> > > obj-$(CONFIG_EC_ACER_ASPIRE1) += acer-aspire1-ec.o
> > > +obj-$(CONFIG_EC_DELL_XPS) += dell-xps-ec.o
> > > obj-$(CONFIG_EC_HUAWEI_GAOKUN) += huawei-gaokun-ec.o
> > > obj-$(CONFIG_EC_LENOVO_YOGA_C630) += lenovo-yoga-c630.o
> > > obj-$(CONFIG_EC_LENOVO_THINKPAD_T14S) += lenovo-thinkpad-t14s.o
> > > diff --git a/drivers/platform/arm64/dell-xps-ec.c b/drivers/platform/arm64/dell-xps-ec.c
> > > new file mode 100644
> > > index 0000000000000000000000000000000000000000..bf1495fbe473ccdb82b95a66b56e8525f782cc8e
> > > --- /dev/null
> > > +++ b/drivers/platform/arm64/dell-xps-ec.c
> > > @@ -0,0 +1,267 @@
> > > +// SPDX-License-Identifier: GPL-2.0-only
> > > +/*
> > > + * Copyright (c) 2026, Aleksandrs Vinarskis <alex@vinarskis.com>
> > > + */
> > > +
> > > +#include <linux/array_size.h>
> > > +#include <linux/dev_printk.h>
> > > +#include <linux/device.h>
> > > +#include <linux/devm-helpers.h>
> > > +#include <linux/err.h>
> > > +#include <linux/i2c.h>
> > > +#include <linux/iio/consumer.h>
> > > +#include <linux/interrupt.h>
> > > +#include <linux/jiffies.h>
> > > +#include <linux/module.h>
> > > +#include <linux/pm.h>
> > > +#include <linux/unaligned.h>
> > > +#include <linux/workqueue.h>
> > > +
> > > +#define DELL_XPS_EC_SUSPEND_CMD 0xb9
> > > +#define DELL_XPS_EC_SUSPEND_MSG_LEN 64
> > > +
> > > +#define DELL_XPS_EC_TEMP_CMD0 0xfb
> > > +#define DELL_XPS_EC_TEMP_CMD1 0x20
> > > +#define DELL_XPS_EC_TEMP_CMD3 0x02
> > > +#define DELL_XPS_EC_TEMP_MSG_LEN 6
> > > +#define DELL_XPS_EC_TEMP_POLL_JIFFIES msecs_to_jiffies(100)
> > > +
> > > +/*
> > > + * Format:
> > > + * - header/unknown (2 bytes)
> > > + * - per-thermistor entries (3 bytes): thermistor_id, param1, param2
> > > + */
> > > +static const u8 dell_xps_ec_thermistor_profile[] = {
> > > + 0xff, 0x54,
> > > + 0x01, 0x00, 0x2b, /* sys_therm0 */
> > > + 0x02, 0x44, 0x2a, /* sys_therm1 */
> > > + 0x03, 0x44, 0x2b, /* sys_therm2 */
> > > + 0x04, 0x44, 0x28, /* sys_therm3 */
> > > + 0x05, 0x55, 0x2a, /* sys_therm4 */
> > > + 0x06, 0x44, 0x26, /* sys_therm5 */
> > > + 0x07, 0x44, 0x2b, /* sys_therm6 */
> > > +};
> > > +
> > > +/*
> > > + * Mapping from IIO channel name to EC command byte
> > > + */
> > > +static const struct {
> > > + const char *name;
> > > + u8 cmd;
> > > +} dell_xps_ec_therms[] = {
> > > + /* TODO: 0x01 is sent only occasionally, likely TZ98 or TZ4 */
> > > + { "sys_therm0", 0x02 },
> > > + { "sys_therm1", 0x03 },
> > > + { "sys_therm2", 0x04 },
> > > + { "sys_therm3", 0x05 },
> > > + { "sys_therm4", 0x06 },
> > > + { "sys_therm5", 0x07 },
> > > + { "sys_therm6", 0x08 },
> > > +};
> >
> > You could probably retrieve these strings from the dt if you really need
> > them.
> >
> > I don't think you need static consts in your driver though you could
> > just as easily do `sprintf("sys_therm%d\n", i) where you use
> > ec_therms[i].name - the name is only used to print errors and you have
> > the index of the channel when you do.
> >
> > It would be nicer to get the strings from DT - certainly make the string
> > names mandatory but, then let the DT specify those names.
> >
> > Either that or just do the sprintf("sys_therm%d\n", i); for the index,
> > whichever you wish yourself.
>
> Hi Bryan,
>
> Will answer here to all three comments about `sys_thermX`.
>
> The reason I have added them as static consts here, and defined them in
> the schema is because the order of the channels matters:
> 1. On my XPS (UEFI v2.11.0) changes in sys_therm2 immediately result in
> changes in fan speeds. Other channels seemingly have no affect, at
> least when spoofed one by one, implying that EC cares which value
> is which.
> 2. As I do not know internals of the EC firmware, even if today the other
> thermistor channels ordering is seemingly not relevant, we cannot be
> sure it will not change with EC firmware upgrade.
>
> I have reconstructed the order of channels by comparing i2c data dumps
> and real-time temps on Windows, eg. sys_therm0 is sent to EC under id 0x02
> and represents the TZ71 (around dram on XPS). There is no other reason to
> have the names of the channels in this driver except for enforcing the
> channel mapping, so `sprintf("sys_therm%d\n", i)` wouldn't be useful.
>
> By allowing source and sink to define the names and not enforcing it in
> schema we lose ability to force the correct order, there is no way of
> knowing whether "lpddr5-therm" or "ssd-therm" goes first. By forcing
> "sys_thermX" convention, one would need to figure which one is which,
> for example by referring to laptop schematics. I assume, "thena"'s
> schematics has thermistors labeled as "sys_thermX"?
>
> I do agree that labels of the ADC nodes could be more useful for the
> user. So far I followed the example of sc8280xp platforms that define
> ADC channels with "sys_thermX". Perhaps, we could separate the
> io-channel-names and ADC node labels then? eg:
>
The general guidance for such naming questions is to follow naming from
the schematics, whenever available.
> + io-channel-names = "sys_therm0",
> + "sys_therm1",
> ...
>
> + &pmk8550_vadc {
> + sys_therm0: channel@14c {
> + reg = <PM8350_ADC7_GPIO3_100K_PU(1)>;
> + qcom,hw-settle-time = <200>;
> + qcom,ratiometric;
> + label = "lpddr5x-therm";
>
> Though not sure if such approach is 'legal'?
I might be missing something, but that does look legal. Your node's
label follows (what I assume to be) the naming in the schematics and you
provide a human-friendly label.
PS. Once we have these adc channels in place, I presume there's also a
TM that would allow us to wire them up as cooling-maps, to throttle the
CPUs? Similar to "skin-temp-thermal" in x13s.
Regards,
Bjorn
^ permalink raw reply
* Re: [PATCH 3/3] ASoC: renesas: fsi: Fix hang by enabling SPU clock
From: Bui Duc Phuc @ 2026-04-06 12:32 UTC (permalink / raw)
To: Kuninori Morimoto
Cc: broonie, lgirdwood, robh, krzk+dt, conor+dt, geert+renesas,
magnus.damm, perex, tiwai, linux-sound, linux-renesas-soc,
devicetree, linux-kernel
In-Reply-To: <87v7e5t16l.wl-kuninori.morimoto.gx@renesas.com>
Hi Morimoto-san, Mark,
Thank you for your review.
> If it is needed for register access,
Yes, enabling this clock is essential as it functions as a bus bridge clock.
Currently, the SPU clock is still enabled by the bootloader. In legacy
kernels (v4.2 and earlier) using the Armadillo board-file/defconfig, this
clock remained active after boot, allowing the FSI to function correctly.
However, after migrating to a full Device Tree (DTS) implementation,
the kernel's unused clock cleanup mechanism disables the SPU clock
because it isn't explicitly claimed. This leads to a system hang every
time aplay is executed, as the FSI registers become inaccessible
without this clock.
> you need to call it on
> fsi_hw_startup/shutdown() which cares suspend/resume too.
I previously attempted to manage the clock within fsi_hw_startup/
shutdown, but the system would hang when stopping aplay
(e.g., via Ctrl+C). This happens because certain cleanup operations,
such as fsi_irq_disable(), are performed after fsi_hw_shutdown()
finishes. These operations require register access, which triggers a
system hang if the SPU clock has already been disabled. Therefore,
I moved the clock management to fsi_dai_startup/shutdown to ensure
the clock remains active throughout the entire lifecycle of the stream.
Furthermore, my testing shows that using dai_startup/shutdown
eliminates the need for explicit Suspend/Resume handling for this clock.
Since the ALSA framework typically invokes the hw_ callbacks during
power management transitions rather than the dai_ ones, the SPU clock
state remains stable, preventing any illegal register access during
these transitions.
> As Mark mentioned, it should be optional.
> Otherwise it breaks compatibility.
You are right. I will implement it this way in v2.
> And we already have fsi_clk_init() for clock initialize.
> spu should be handled in it.
> Now, it is called if clock master (A.
> (A) if (fsi_is_clk_master(fsi)) {
> if (fsi->clk_cpg)
> fsi_clk_init(dev, fsi, 0, 1, 1,
> fsi_clk_set_rate_cpg);
> else
> fsi_clk_init(dev, fsi, 1, 1, 0,
> fsi_clk_set_rate_external);
> }
You are right. Currently, our FSIA is configured as a slave,
so it never executes the clk_init() function.
> I think it (A) can be checked inside fsi_clk_init().
> fsi_clk_init() is now called when .set_fmt, but it can be called
> at _probe() timing ?
Yes. I can handle the implementation/coding side of this.
> Should we also be managing the clock during system suspend, or if the
> power consumption doesn't really matter should we just keep it enabled
> all the time and not worry about starting and stopping it?
Regarding the SPU clock management, I haven't measured the exact
power consumption of this block yet. However, to keep the code simple
and ensure maximum stability for register access (avoiding system
hangs during cleanup), I am open to enabling it once in fsi_probe()
if you find the dynamic management in dai_startup/shutdown
unnecessary.
> This is going to unconditionally require a clock called "spu" on all
> devices using this driver, not just the one SoC you mentioned as
> requiring it. Presumably this worked at least somewhere (possibly the
> clock is always on, or they're just lucky that something else enables
> it) and this will cause regressions for those platforms?
> This should either (ideally) be conditional, or use _optional.
Thank you for your suggestion. I will switch to using
devm_clk_get_optional() in the v2
Best regards,
Phuc
On Mon, Apr 6, 2026 at 6:52 AM Kuninori Morimoto
<kuninori.morimoto.gx@renesas.com> wrote:
>
>
> Hi
>
> Thank you for the patch
>
> > From: bui duc phuc <phucduc.bui@gmail.com>
> >
> > The FSI on r8a7740 requires the SPU clock to be enabled
> > before accessing its registers.
> > Without this clock, register access may lead to a system
> > hang.
> > Retrieve the "spu" clock in probe and enable it during
> > DAI startup. Disable the clock on shutdown to match the
> > audio stream lifecycle.
> > This ensures safe register access and prevents system
> > hangs during audio playback.
> > This is required even if the FSI functional clock is
> > enabled, as internal units depend on the SPU clock.
> >
> > Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
> > ---
> (snip)
> > @@ -1554,6 +1555,11 @@ static int fsi_dai_startup(struct snd_pcm_substream *substream,
> > struct snd_soc_dai *dai)
> > {
> > struct fsi_priv *fsi = fsi_get_priv(substream);
> > + int ret;
> > +
> > + ret = clk_prepare_enable(fsi->master->clk_spu);
> > + if (ret)
> > + return ret;
> >
> > fsi_clk_invalid(fsi);
>
> If it is needed for register access, you need to call it on
> fsi_hw_startup/shutdown() which cares suspend/resume too.
>
> And I guess it need to count user, because we have FSI-A / FSI-B ?
>
> > @@ -1963,6 +1970,13 @@ static int fsi_probe(struct platform_device *pdev)
> > master->core = core;
> > spin_lock_init(&master->lock);
> >
> > + /* SPU clock is required for FSI register access */
> > + master->clk_spu = devm_clk_get(&pdev->dev, "spu");
> > + if (IS_ERR(master->clk_spu)) {
> > + dev_err(&pdev->dev, "Failed to get spu clock\n");
> > + return PTR_ERR(master->clk_spu);
> > + }
>
> As Mark mentioned, it should be optional. Otherwise it breaks compatibility.
> And we already have fsi_clk_init() for clock initialize.
> spu should be handled in it.
>
> Now, it is called if clock master (A.
>
> (A) if (fsi_is_clk_master(fsi)) {
> if (fsi->clk_cpg)
> fsi_clk_init(dev, fsi, 0, 1, 1,
> fsi_clk_set_rate_cpg);
> else
> fsi_clk_init(dev, fsi, 1, 1, 0,
> fsi_clk_set_rate_external);
> }
>
> I think it (A) can be checked inside fsi_clk_init().
> fsi_clk_init() is now called when .set_fmt, but it can be called
> at _probe() timing ?
>
> Thank you for your help !!
>
> Best regards
> ---
> Kuninori Morimoto
^ permalink raw reply
* Re: [PATCH v7 0/3] Add MACB/GEM instances on EyeQ5, and their PHYs
From: Thomas Bogendoerfer @ 2026-04-06 12:31 UTC (permalink / raw)
To: Théo Lebrun
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-mips,
devicetree, linux-kernel, Vladimir Kondratiev, Gregory CLEMENT,
Benoît Monin, Tawfik Bayouk, Thomas Petazzoni, Luca Ceresoli,
Conor Dooley, Andrew Lunn
In-Reply-To: <20260225-macb-phy-v7-0-d3c9842ec931@bootlin.com>
On Wed, Feb 25, 2026 at 05:55:21PM +0100, Théo Lebrun wrote:
> EyeQ5 SoCs integrate two GEM instances. A system-controller register
> region named "OLB" has some control over the Ethernet PHY integration.
>
> Extend the current OLB ecosystem with a new generic PHY driver.
> - OLB is carried by one main platform driver: clk-eyeq.
> - It instantiates auxiliary devices: reset-eyeq & pinctrl-eyeq5.
> - We add a new one: phy-eyeq5-eth.
>
> Here we update dt-bindings to indicate OLB is a PHY provider. Then we
> add MACB/GEM instances in the devicetree, and the PHYs on the eval
> board.
>
> About related patches:
>
> - PHY patches are incoming to add the driver. Patches used to be [2] in
> the same series.
>
> - clk patches are incoming to make clk-eyeq instantiate this new
> auxiliary device. They also ensure we get a dev->of_node assigned.
> Patches used to be [2] in the same series.
>
> Have a nice day,
> Thanks!
> Théo
>
> [0]: https://lore.kernel.org/lkml/20250627-macb-v2-15-ff8207d0bb77@bootlin.com/
> [1]: https://lore.kernel.org/lkml/20251022-macb-eyeq5-v2-0-7c140abb0581@bootlin.com/
>
> Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
> ---
> Changes in v7:
> - Separate PHY / clk / MIPS patches into three series.
> - Rebase onto v7.0-rc1 and test on EyeQ5. Nothing to report.
> - Link to v6: https://lore.kernel.org/r/20260127-macb-phy-v6-0-cdd840588188@bootlin.com
>
> Changes in v6:
> - Rebase upon v6.19-rc7; nothing to report.
> - Add new patch "phy: sort Kconfig and Makefile".
> - phy-eyeq5-eth: drop useless explicit __iomem cast to
> dev_get_platdata() return value.
> - I did *not* drop the Kconfig `default MACH_EYEQ5` nor driver
> `dev_dbg()`. I think both are useful and should be kept. See
> last revision discussion here:
> https://lore.kernel.org/lkml/DFGSMN8268O0.33TYCQDBVHUHZ@bootlin.com/
> - Link to v5: https://lore.kernel.org/r/20251215-macb-phy-v5-0-a9dfea39da34@bootlin.com
>
> Changes in v5:
> - phy-eyeq5-eth:
> - fix #includes: add delay, gfp_types, module and drop array_size,
> bug, cleanup, container_of, lockdep, mutex.
> - eq5_phy_xlate(): avoid magic value, use EQ5_PHY_COUNT.
> - use dev_err_probe() in error cases of devm_phy_create() and
> devm_of_phy_provider_register().
> - 3x Reviewed-by: Luca Ceresoli.
> - Add Neil Armstrong to Cc as new PHY subsystem reviewer.
> - Rebase on v6.19-rc1, tested on hardware, no changes.
> - Link to v4: https://lore.kernel.org/r/20251124-macb-phy-v4-0-955c625a81a7@bootlin.com
>
> Changes in v4:
> - Append my SoB to Jerome's patch:
> [PATCH v4 3/7] clk: eyeq: use the auxiliary device creation helper
> - Rebase on net-next & linux-{clk,mips,phy}. Nothing to report.
> - Link to v3: https://lore.kernel.org/r/20251119-macb-phy-v3-0-e9a7be186a33@bootlin.com
>
> Changes in v3:
> - Take Philipp Zabel's Reviewed-by & Acked-by trailers on reset patch.
> - Take Thomas Bogendoerfer's two Acked-by trailers on DT patches.
> - Rebase on net-next & test on target. Nothing to report.
> - Link to v2: https://lore.kernel.org/r/20251101-macb-phy-v2-0-c1519eef16d3@bootlin.com
>
> Changes in v2:
> - Take Acked-by: Conor Dooley on dt-bindings-patch.
> - s/%ld/%tu/ for printing ptrdiff_t; warnings on 32-bit archs.
> Reported by NIPA's netdev/build_32bit test.
> https://patchwork.kernel.org/project/netdevbpf/patch/20251021-macb-eyeq5-v1-7-3b0b5a9d2f85@bootlin.com/
> https://netdev.bots.linux.dev/static/nipa/1014126/14277857/build_32bit/stderr
> - Link to v1: https://lore.kernel.org/r/20251022-macb-phy-v1-0-f29f28fae721@bootlin.com
>
> Changes since MACB V1:
> - Drop the old "mobileye,olb" properties from DT patches; found while
> running dtbs_check and dt_binding_check.
> - Drop all patches targeting net-next. That is MACB dt-bindings patch
> and MACB driver code. See there here [1].
> - Link to v1: https://lore.kernel.org/lkml/20251021-macb-eyeq5-v1-0-3b0b5a9d2f85@bootlin.com/
>
> Past versions of MACB patches:
> - March 2025: [PATCH net-next 00/13] Support the Cadence MACB/GEM
> instances on Mobileye EyeQ5 SoCs
> https://lore.kernel.org/lkml/20250321-macb-v1-0-537b7e37971d@bootlin.com/
> - June 2025: [PATCH net-next v2 00/18] Support the Cadence MACB/GEM
> instances on Mobileye EyeQ5 SoCs
> https://lore.kernel.org/lkml/20250627-macb-v2-0-ff8207d0bb77@bootlin.com/
> - August 2025: [PATCH net v3 00/16] net: macb: various fixes & cleanup
> https://lore.kernel.org/lkml/20250808-macb-fixes-v3-0-08f1fcb5179f@bootlin.com/
>
> ---
> Théo Lebrun (3):
> dt-bindings: soc: mobileye: OLB is an Ethernet PHY provider on EyeQ5
> MIPS: mobileye: eyeq5: add two Cadence GEM Ethernet controllers
> MIPS: mobileye: eyeq5-epm: add two Cadence GEM Ethernet PHYs
>
> .../bindings/soc/mobileye/mobileye,eyeq5-olb.yaml | 7 +++-
> arch/mips/boot/dts/mobileye/eyeq5-epm5.dts | 26 +++++++++++++
> arch/mips/boot/dts/mobileye/eyeq5.dtsi | 45 ++++++++++++++++++++++
> 3 files changed, 77 insertions(+), 1 deletion(-)
> ---
> base-commit: 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f
> change-id: 20251022-macb-phy-21bc4e1dfbb7
seried applied to mips-next
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea. [ RFC1925, 2.3 ]
^ permalink raw reply
* Re: [PATCH v2] MIPS: dts: loongson64g-package: Switch to Loongson UART driver
From: Thomas Bogendoerfer @ 2026-04-06 12:32 UTC (permalink / raw)
To: Rong Zhang
Cc: Greg Kroah-Hartman, Jiri Slaby, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Huacai Chen, Jiaxun Yang, linux-kernel,
linux-serial, linux-mips, devicetree, Yao Zi, Icenowy Zheng,
Rong Zhang
In-Reply-To: <20260315184401.413975-1-rongrong@oss.cipunited.com>
On Mon, Mar 16, 2026 at 02:44:00AM +0800, Rong Zhang wrote:
> Loongson64g is Loongson 3A4000, whose UART controller is compatible with
> Loongson 2K1500, which is NS16550A-compatible with an additional
> fractional frequency divisor register.
>
> Update the compatible strings to reflect this, so that 3A4000 can
> benefit from the fractional frequency divisor provided by loongson-uart.
> This is required on some devices, otherwise their UART can't work at
> some high baud rates, e.g., 115200.
>
> Tested on Loongson-LS3A4000-7A1000-NUC-SE with a 25MHz UART clock.
> Without fractional frequency divisor, the actual baud rate was 111607
> (25MHz / 16 / 14, measured value: 111545) and some USB-to-UART
> converters couldn't work with it at all. With fractional frequency
> divisor, the measured baud rate becomes 115207, which is quite accurate.
>
> Signed-off-by: Rong Zhang <rongrong@oss.cipunited.com>
> ---
> This patch targets the MIPS tree.
>
> The series for the serial tree to update dt-bindings and enable building
> 8250_loongson (loongson-uart) on MIPS Loongson64 is sent separately, as
> it's independant of this patch and can be applied in any order (the
> compatible strings here still contain "ns16550a", so no regression will
> be introduced).
>
> Changes in v2:
> - Separated from v1 (patch 3): https://lore.kernel.org/r/20260314234143.651298-1-rongrong@oss.cipunited.com/
> (thanks Krzysztof Kozlowski)
> ---
> arch/mips/boot/dts/loongson/loongson64g-package.dtsi | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
applied to mips-next
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea. [ RFC1925, 2.3 ]
^ permalink raw reply
* Re: [PATCH v2 8/8] mips: dts: Add PCIe to EcoNet EN751221
From: Thomas Bogendoerfer @ 2026-04-06 12:37 UTC (permalink / raw)
To: Caleb James DeLisle
Cc: linux-mips, naseefkm, mturquette, sboyd, robh, krzk+dt, conor+dt,
ryder.lee, jianjun.wang, lpieralisi, kwilczynski, mani, bhelgaas,
vkoul, neil.armstrong, p.zabel, matthias.bgg,
angelogioacchino.delregno, nbd, ansuelsmth, linux-clk, devicetree,
linux-kernel, linux-pci, linux-mediatek, linux-phy,
linux-arm-kernel
In-Reply-To: <20260309131818.74467-9-cjd@cjdns.fr>
On Mon, Mar 09, 2026 at 01:18:18PM +0000, Caleb James DeLisle wrote:
> Add PCIe based on EN7528 PCIe driver, also add two MT76 wifi devices
> to SmartFiber XP8421-B.
>
> Signed-off-by: Caleb James DeLisle <cjd@cjdns.fr>
> ---
> arch/mips/boot/dts/econet/en751221.dtsi | 114 ++++++++++++++++++
> .../econet/en751221_smartfiber_xp8421-b.dts | 21 ++++
> arch/mips/econet/Kconfig | 2 +
> 3 files changed, 137 insertions(+)
>
applied to mips-next
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea. [ RFC1925, 2.3 ]
^ permalink raw reply
* Re: Devicetree spec: Specifying /cpus/cpu@* unit address format?
From: Rob Herring @ 2026-04-06 12:48 UTC (permalink / raw)
To: David Gibson, Vivian Wang
Cc: devicetree-spec, Krzysztof Kozlowski, Conor Dooley, Paul Walmsley,
Palmer Dabbelt, Alexandre Ghiti, Chen Wang, Inochi Amaoto,
devicetree, linux-riscv, sophgo
In-Reply-To: <adHofcKAr7C5YCSA@zatzit>
On Sat, Apr 4, 2026 at 11:43 PM David Gibson
<david@gibson.dropbear.id.au> wrote:
>
> On Fri, Apr 03, 2026 at 06:06:17PM +0800, Vivian Wang wrote:
> > (Also posted at: https://github.com/devicetree-org/devicetree-specification/issues/86 )
> >
> > Hi all,
> >
> > Presently, there seems to be some confusion in the community about the
> > format of unit addresses for "/cpus/cpu@*" nodes for a CPU with ID > 9, e.g.
> >
> > cpu@??? {
> > reg = <10>;
> > /* reg = <0xa>; */ /* This should be equivalent */
> > }
> >
> >
> > Should this be a decimal "cpu@10", or hexadecimal "cpu@a"? I can't find
> > any explicit specification.
>
> It should be hex. That's a general convention for unit addresses.
> Before flattened trees, OF essentially never used decimal
> representations of things.
The only decimal usage in FDT were mistakes.
Rather than worrying about what the spec says, please worry about what
the tools check. Unfortunately, this is still only checked for
specific bus types and the default is not checked.
Rob
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: sound: renesas,fsi: Add support for multiple clocks
From: Bui Duc Phuc @ 2026-04-06 12:59 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: kuninori.morimoto.gx, broonie, lgirdwood, robh, krzk+dt, conor+dt,
geert+renesas, magnus.damm, perex, tiwai, linux-sound,
linux-renesas-soc, devicetree, linux-kernel
In-Reply-To: <20260405-ultramarine-orangutan-of-wholeness-bbcc6b@quoll>
Hi Mark, Krzysztof,
Thank you for your reviews. I will fix these in v2:
- Subject Line: Change to ASoC: dt-bindings: renesas,fsi: add support
for multiple clocks to match subsystem style.
- Commit Message: Reformat to 72-75 characters per line and remove
manual line breaks after every sentence.
- YAML Bindings: Properly constrain clocks and clock-names by
following the writing-schema and existing
Renesas sound examples.
I will submit the v2 series shortly.
Best regards,
Phuc
On Sun, Apr 5, 2026 at 2:32 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On Fri, Apr 03, 2026 at 06:26:53PM +0700, phucduc.bui@gmail.com wrote:
> > From: bui duc phuc <phucduc.bui@gmail.com>
> >
> > The FSI on r8a7740 requires the SPU clock to be enabled
> > before accessing its registers.
> > Without this clock, register access may lead to a system
> > hang.
> > Add support for the "spu" clock so it can be managed by
> > the driver.
> > The binding is also extended to allow additional clocks,
> > as FSIB may require more clock inputs, while FSIA
> > typically uses fewer.
>
> Please wrap commit message according to Linux coding style / submission
> process (neither too early nor over the limit):
> https://elixir.bootlin.com/linux/v6.4-rc1/source/Documentation/process/submitting-patches.rst#L597
>
> And not after every sentece, BTW.
>
> > Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
> > ---
> > .../devicetree/bindings/sound/renesas,fsi.yaml | 12 ++++++++++--
> > 1 file changed, 10 insertions(+), 2 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/sound/renesas,fsi.yaml b/Documentation/devicetree/bindings/sound/renesas,fsi.yaml
> > index df91991699a7..225cd8d369bb 100644
> > --- a/Documentation/devicetree/bindings/sound/renesas,fsi.yaml
> > +++ b/Documentation/devicetree/bindings/sound/renesas,fsi.yaml
> > @@ -38,7 +38,11 @@ properties:
> > maxItems: 1
> >
> > clocks:
> > - maxItems: 1
> > + minItems: 1
> > + maxItems: 8
>
> Needs valid descriptions.
>
> > +
> > + clock-names:
> > + description: List of necessary clock names.
>
> Instead constrain it. See also writing-bindings, writing-schema or
> example-schema documents.
>
> Best regards,
> Krzysztof
>
^ permalink raw reply
* Re: [RFC PATCH 0/3] media: qcom: camss: CAMSS Offline Processing Engine support
From: Loic Poulain @ 2026-04-06 13:22 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Bryan O'Donoghue, vladimir.zapolskiy, kieran.bingham, robh,
krzk+dt, andersson, konradybcio, linux-media, linux-arm-msm,
devicetree, linux-kernel, johannes.goede, mchehab
In-Reply-To: <20260405194851.GA3972481@killaraus.ideasonboard.com>
Hi Laurent,
On Sun, Apr 5, 2026 at 9:48 PM Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
>
> On Tue, Mar 24, 2026 at 05:16:21PM +0100, Loic Poulain wrote:
> > On Tue, Mar 24, 2026 at 1:54 PM Bryan O'Donoghue wrote:
> > > On 23/03/2026 12:58, Loic Poulain wrote:
> > > > This first version is intentionally minimalistic. It provides a working
> > > > configuration using a fixed set of static processing parameters, mainly
> > > > to achieve correct and good-quality debayering.
> > >
> > > You need the other 50% of the kernel side - the generation of bayer
> > > statistics in the IFE, as well as generation of parameters to feed back
> > > into the OPE - which requires a user-space implementation too, so a lot
> > > of work there too.
> > >
> > > I'd also say when we have an ICP we should be using it via the HFI
> > > protocol, thus burying all of the IPE/OPE BPS and CDM complexity in the
> > > firmware.
> > >
> > > Understood Agatti has no ICP so you're limited to direct OPE/IFE
> > > register access here. For HFI capable platforms - the majority - HFI is
> > > the way to go.
> >
> > Fully agree, this is exactly the point where we should sync and work
> > together on a proper solution.
>
> I don't necessarily agree with that. There are pros and cons for using
> HFI on platforms that have an ICP. If correctly written, a firmware can
> improve the throughput in multi-camera use cases by reprogramming the
> time-multiplexed OPE faster. On the other hand, in use cases that don't
> require pushing the platform to its limits, dealing with a closed-source
> firmware often causes lots of issues.
Yes, we need to further explore the ICP (MCU-based offload) solution
before drawing any conclusions, especially to assess how complex it is
to leverage or bypass. That said, the current platform (Agatti/OPE)
does not support it anyway.
> We should aim at supporting both direct ISP access and HFI with the same
> userspace API, even on a single platform. Which option to start with is
> an open question that we should discuss.
>
> > As a follow‑up to this RFC, I already have several ongoing pieces that
> > aim to generalize the CAMSS ISP support, and I’d very much like to
> > discuss them with you:
> >
> > - camss-isp-m2m: Generic M2M scheduling framework handling job dispatch
> > based on buffer readiness and enabled endpoints (frame input, output,
> > statistics, parameters).
>
> This should be generic, not limited to camss. v4l2-isp is a good
> candidate.
>
> > - camss-isp-pipeline: Helper layer to construct complex media/ISP graphs
> > from a structural description (endpoints, links, etc.).
>
> That also doesn't seem specific to camss.
Yes, architecturally this is not CAMSS‑specific. However, the current
implementation may rely on certain assumptions or shortcuts that do
not hold across all general offline ISP use cases. With some effort,
it should be possible to generalize them [1] [2] .
[1] https://github.com/loicpoulain/linux/blob/camss-isp-dev/drivers/media/platform/qcom/camss/camss-isp-pipeline.c
[2] https://github.com/loicpoulain/linux/blob/camss-isp-dev/drivers/media/platform/qcom/camss/camss-isp-m2m.c
>
> > - camss-isp-params: Generic helper for handling ISP parameter buffers
> > (using v4l2-isp-params).
>
> I'm curious to know what camss-specific helpers you envision there.
Nothing too complex initially, just a parser built on the v4l2‑isp
helpers, along with a few handler callbacks [3]. This is something
I’ll discuss with Bryan, as we definitely want to reuse the same
format and parser for both inline and offline ISPs (as well as for
stats).
[3] https://github.com/loicpoulain/linux/blob/camss-isp-dev/drivers/media/platform/qcom/camss/camss-isp-params.c
>
> > - camss-isp-stats: Generic helper framework for CAMSS statistics devices.
>
> Same.
>
> > - camss-(isp-)ope: OPE‑specific logic only (register configuration, IRQ
> > handling, parameter‑to‑register translation).
> >
> > This approach should significantly reduce the amount of
> > platform‑specific code required for future ISP blocks. It should also
> > allow you to integrate a camss-isp-hamoa (or similar) backend, or even
> > a camss-isp-hfi implementation for the M2M functions, without
> > duplicating the infrastructure.
> >
> > So yes, let’s sync and agree on a shared/open development model and an
> > overall direction, possibly even a common tree, to ensure we stay
> > aligned and can collaborate effectively.
>
> Let's schedule a call to kickstart those discussions. Many people are on
> Easter vacation this week, next week could be a good candidate.
>
> > > I'll publish an RFC for Hamoa for that soonish so we can make sure both
> > > coexist.
^ permalink raw reply
* RE: [PATCH v6 4/4] iio: adc: ad4691: add SPI offload support
From: Sabau, Radu bogdan @ 2026-04-06 13:30 UTC (permalink / raw)
To: David Lechner, Lars-Peter Clausen, Hennerich, Michael,
Jonathan Cameron, Sa, Nuno, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Uwe Kleine-König,
Liam Girdwood, Mark Brown, Linus Walleij, Bartosz Golaszewski,
Philipp Zabel, Jonathan Corbet, Shuah Khan
Cc: linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-pwm@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-doc@vger.kernel.org
In-Reply-To: <LV9PR03MB8414C570998C4C1EE59ABFBBF75DA@LV9PR03MB8414.namprd03.prod.outlook.com>
> -----Original Message-----
> From: Sabau, Radu bogdan
> Sent: Monday, April 6, 2026 2:08 PM
>
> ...
>
> > > > #define AD4691_CHANNEL(ch)
> > > \
> > > > { \
> > > > .type = IIO_VOLTAGE, \
> > > > @@ -122,11 +155,9 @@ struct ad4691_chip_info {
> > > > .info_mask_shared_by_all = BIT(IIO_CHAN_INFO_SCALE),
> > > \
> > > > .channel = ch, \
> > > > .scan_index = ch, \
> > > > - .scan_type = { \
> > > > - .sign = 'u', \
> > > > - .realbits = 16, \
> > > > - .storagebits = 16, \
> > > > - }, \
> > > > + .has_ext_scan_type = 1,
> > > \
> > > > + .ext_scan_type = ad4691_scan_types, \
> > > > + .num_ext_scan_type = ARRAY_SIZE(ad4691_scan_types),
> > > \
> > >
> > > Usually, we just make two separte ad4691_chip_info structs for offload
> > > vs. not offload.
> > >
> > > ext_scan_type is generally only used when the scan type can change
> > > dynamically after probe.
> > >
> >
> > So, just to be clear, you are saying I should have different chip_info structs
> > and change the triggered-buffer for offload ones if offload is present?
> > I am asking since offload has different scan types as well, and this would
> > mean 3 different chip_info structs for each chip -> total of 12 chip_info
> structs,
> > each with a different channel array, or perhaps there is a more compact way
> > to have this implemented.
> > I could make the channel arrays use the same macro and have the scan_type
> > reversed to storage and shift done as parameters.
> >
>
> I have given this a thought and I think this could be done in a more compact
> way:
>
> 1. Parametrize AD4691_CHANNEL to accept storagebits and shift, then define
> 4 channel
> arrays:
>
> - ad4691_channels[] - 16ch + timestamp (triggered-buffer path)
> - ad4693_channels[] - 8ch + timestamp (triggered-buffer path)
> - ad4691_offload_cnv_channels[] - 16 entries, storagebits=32, shift =
> 0
> - ad4691_offload_manual_channels[] - 16 entries, storagebits=32,
> shift=16
>
> The two offload arrays are shared across both chip families. Since
> num_channels
> bound the interation in the IIO core, the 8ch chips simply use the first 8
> entries of
> the 16-entry offload arrays. Triggered-buffer path would need different
> channel
> arrays since the timestamp index would be different, and offload doesn't use
> timestamp.
>
> 2. chip_info could then stay at 2 structs, and have channels selected at probe
> for the
> indio_dev, or have 4 chip info structs each having its own channels assigned,
> and only
> num_channels could be changed at probe.
>
I also have to mention that the oversampling commit would then implement
AD4691_MANUAL_CHANNEL macro which would miss the OVERSAMPLING
infomask, and offload_manual_channels will be declared using it.
More than this, that commit would also add other ad4691_manual_channels[]
and ad4693_manual_channels[] arrays that would use that MACRO as well.
Then, chip_info would have ad4691/93_channels assigned to it by default,
and indio_dev->channels will later be assigned at probe, depending on the
mode and offload.
If different chip_info structs would be wanted still, then my best guess is
to have different info structures (perhaps new types) in chip_info by default.
Something like *sw_info and *offload_info.
Each one would contain all the pre-defined channel arrays in them
(channels and manual_channels) and so have ad4691_sw_info and ad4691_offload_info.
After so, chip_info will also contain besides these 2 info structures, num_channels and max_rate.
At probe indio_dev assignments will be made from the chip_info entirely.
What's your guys take on this? I am keen to hearing your thoughts about this.
Thanks,
Radu
^ permalink raw reply
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