* Re: [PATCH v3] Add remoteproc PAS loader for SoCCP on Glymur DT
From: Ananthu C V @ 2026-04-10 7:28 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel,
Sibi Sankar
In-Reply-To: <238b23bf-a180-4dfc-a896-955b1559bee7@oss.qualcomm.com>
On Tue, Apr 07, 2026 at 01:41:33PM +0200, Konrad Dybcio wrote:
> On 4/3/26 1:39 PM, Ananthu C V wrote:
> > From: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
> >
> > Signed-off-by: Sibi Sankar <sibi.sankar@oss.qualcomm.com>
> > Co-developed-by: Ananthu C V <ananthu.cv@oss.qualcomm.com>
> > Signed-off-by: Ananthu C V <ananthu.cv@oss.qualcomm.com>
> > ---
>
> [...]
>
> > + remoteproc_soccp: remoteproc-soccp@d00000 {
>
> remoteproc-soccp@ ->remoteproc@
ack
> > + compatible = "qcom,glymur-soccp-pas", "qcom,kaanapali-soccp-pas";
> > + reg = <0x0 0x00d00000 0x0 0x200000>;
> > +
> > + interrupts-extended = <&intc GIC_SPI 167 IRQ_TYPE_EDGE_RISING>,
> > + <&soccp_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
> > + <&soccp_smp2p_in 1 IRQ_TYPE_EDGE_RISING>,
> > + <&soccp_smp2p_in 2 IRQ_TYPE_EDGE_RISING>,
> > + <&soccp_smp2p_in 3 IRQ_TYPE_EDGE_RISING>,
> > + <&soccp_smp2p_in 9 IRQ_TYPE_EDGE_RISING>;
> > + interrupt-names = "wdog",
> > + "fatal",
> > + "ready",
> > + "handover",
> > + "stop-ack",
> > + "pong";
> > +
> > + clocks = <&rpmhcc RPMH_CXO_CLK>;
> > + clock-names = "xo";
> > +
> > + power-domains = <&rpmhpd RPMHPD_CX>,
> > + <&rpmhpd RPMHPD_MX>;
> > + power-domain-names = "cx",
> > + "mx";
> > +
> > + memory-region = <&soccp_mem>,
> > + <&soccpdtb_mem>;
> > +
> > + qcom,smem-states = <&soccp_smp2p_out 0>,
> > + <&soccp_smp2p_out 8>;
> > + qcom,smem-state-names = "stop",
> > + "ping";
> > +
> > + status = "disabled";
>
> Let's drop this line, no one should desire to run a system without SoCCP
ack, that makes sense.
> > +
> > + glink-edge {
> > + interrupts-extended = <&ipcc IPCC_MPROC_SOCCP
> > + IPCC_MPROC_SIGNAL_GLINK_QMP
> > + IRQ_TYPE_EDGE_RISING>;
> > + mboxes = <&ipcc IPCC_MPROC_SOCCP
> > + IPCC_MPROC_SIGNAL_GLINK_QMP>;
> > + qcom,remote-pid = <19>;
> > + label = "soccp";
> > +
> > + };
>
> Stray \n above
noted, will fix.
> Konrad
Thanks for the review Konrad, will reflect the changes in the next revision.
Best,
Ananthu
^ permalink raw reply
* [PATCH v3 0/2] Describe IMEM on Milos
From: Luca Weiss @ 2026-04-10 7:31 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio
Cc: ~postmarketos/upstreaming, phone-devel, linux-arm-msm, devicetree,
linux-kernel, Luca Weiss, Krzysztof Kozlowski
Add a compatible and describe the IMEM for the Milos SoC.
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
---
Changes in v3:
- Adjust node names to include hyphens (Konrad)
- Use hex for ranges (Krzysztof)
- Pick up tags
- Link to v2: https://patch.msgid.link/20260407-milos-imem-v2-0-5084a490340c@fairphone.com
Changes in v2:
- Use mmio-sram for describing IMEM
- Link to v1: https://patch.msgid.link/20260403-milos-imem-v1-0-4244ebb47017@fairphone.com
---
Luca Weiss (2):
dt-bindings: sram: Document qcom,milos-imem
arm64: dts: qcom: milos: Add IMEM node
Documentation/devicetree/bindings/sram/sram.yaml | 1 +
arch/arm64/boot/dts/qcom/milos.dtsi | 20 ++++++++++++++++++++
2 files changed, 21 insertions(+)
---
base-commit: 0190c2c6dae368aeb9bf59a449ebe23f24bfa059
change-id: 20260403-milos-imem-3a034224946a
prerequisite-change-id: 20260408-topic-sram_dtbindings_misc-5e8834f63d51:v2
prerequisite-patch-id: 1052a7a8c6ef7e9ffccd547c934b318f27ce4c26
Best regards,
--
Luca Weiss <luca.weiss@fairphone.com>
^ permalink raw reply
* [PATCH v3 1/2] dt-bindings: sram: Document qcom,milos-imem
From: Luca Weiss @ 2026-04-10 7:31 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio
Cc: ~postmarketos/upstreaming, phone-devel, linux-arm-msm, devicetree,
linux-kernel, Luca Weiss, Krzysztof Kozlowski
In-Reply-To: <20260410-milos-imem-v3-0-d215385fa5ab@fairphone.com>
Add compatible for Milos SoC IMEM.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
---
Documentation/devicetree/bindings/sram/sram.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/sram/sram.yaml b/Documentation/devicetree/bindings/sram/sram.yaml
index d9a1da12dc66..d5955fef53a4 100644
--- a/Documentation/devicetree/bindings/sram/sram.yaml
+++ b/Documentation/devicetree/bindings/sram/sram.yaml
@@ -35,6 +35,7 @@ properties:
- nvidia,tegra194-sysram
- nvidia,tegra234-sysram
- qcom,kaanapali-imem
+ - qcom,milos-imem
- qcom,rpm-msg-ram
- rockchip,rk3288-pmu-sram
--
2.53.0
^ permalink raw reply related
* [PATCH v3 2/2] arm64: dts: qcom: milos: Add IMEM node
From: Luca Weiss @ 2026-04-10 7:31 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio
Cc: ~postmarketos/upstreaming, phone-devel, linux-arm-msm, devicetree,
linux-kernel, Luca Weiss
In-Reply-To: <20260410-milos-imem-v3-0-d215385fa5ab@fairphone.com>
Add a node for the IMEM found on Milos, which contains pil-reloc-info
and the modem tables for IPA, among others.
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
---
arch/arm64/boot/dts/qcom/milos.dtsi | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/milos.dtsi b/arch/arm64/boot/dts/qcom/milos.dtsi
index 4a64a98a434b..a8536a873c69 100644
--- a/arch/arm64/boot/dts/qcom/milos.dtsi
+++ b/arch/arm64/boot/dts/qcom/milos.dtsi
@@ -2289,6 +2289,26 @@ scl-pins {
};
};
+ sram@14680000 {
+ compatible = "qcom,milos-imem", "mmio-sram";
+ reg = <0x0 0x14680000 0x0 0x2c000>;
+ ranges = <0x0 0x0 0x14680000 0x2c000>;
+
+ no-memory-wc;
+
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ pil-reloc-sram@94c {
+ compatible = "qcom,pil-reloc-info";
+ reg = <0x94c 0xc8>;
+ };
+
+ ipa_modem_tables: modem-tables-sram@3000 {
+ reg = <0x3000 0x2000>;
+ };
+ };
+
apps_smmu: iommu@15000000 {
compatible = "qcom,milos-smmu-500", "qcom,smmu-500", "arm,mmu-500";
reg = <0x0 0x15000000 0x0 0x100000>;
--
2.53.0
^ permalink raw reply related
* Re: [PATCH net-next v3 00/12] net: airoha: Support multiple net_devices connected to the same GDM port
From: Lorenzo Bianconi @ 2026-04-10 7:37 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Christian Marangi,
Benjamin Larsson, linux-arm-kernel, linux-mediatek, netdev,
devicetree, Xuegang Lu
In-Reply-To: <20260409195950.74e4bc97@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 672 bytes --]
> On Mon, 06 Apr 2026 12:34:05 +0200 Lorenzo Bianconi wrote:
> > 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.
>
> Looks like this driver uses page pool.
> If you're sharing the same page pool across multiple netdevs
> it must not be linked to a netdev.
are you referring to slow.netdev pointer? If so, this is not set in airoha_eth
driver.
Regards,
Lorenzo
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH net-next v2 0/2] IPA v5.2 support
From: Luca Weiss @ 2026-04-10 7:40 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Alex Elder
Cc: ~postmarketos/upstreaming, phone-devel, linux-arm-msm, netdev,
devicetree, linux-kernel, Krzysztof Kozlowski, Luca Weiss,
Simon Horman
Add support for IPA v5.2 which can be found in the Milos SoC.
Note: This series has been split up into two, one for net(-next), one
for the qcom dts bits.
Changes in v2:
- Split the series, drop applied IPA fixes, mark as net-next
- Pick up tags
- Link to v1: https://patch.msgid.link/20260403-milos-ipa-v1-0-01e9e4e03d3e@fairphone.com
---
Luca Weiss (2):
dt-bindings: net: qcom,ipa: add Milos compatible
net: ipa: add IPA v5.2 configuration data
.../devicetree/bindings/net/qcom,ipa.yaml | 1 +
drivers/net/ipa/Makefile | 2 +-
drivers/net/ipa/data/ipa_data-v5.2.c | 452 +++++++++++++++++++++
drivers/net/ipa/gsi_reg.c | 1 +
drivers/net/ipa/ipa_data.h | 1 +
drivers/net/ipa/ipa_main.c | 4 +
drivers/net/ipa/ipa_reg.c | 1 +
drivers/net/ipa/ipa_sysfs.c | 2 +
drivers/net/ipa/ipa_version.h | 2 +
9 files changed, 465 insertions(+), 1 deletion(-)
---
base-commit: 42f9b4c6ef19e71d2c7d9bfd3c5037d4fe434ad7
change-id: 20260410-ipa-v5-2-df8702bb8a3b
Best regards,
--
Luca Weiss <luca.weiss@fairphone.com>
^ permalink raw reply
* [PATCH net-next v2 1/2] dt-bindings: net: qcom,ipa: add Milos compatible
From: Luca Weiss @ 2026-04-10 7:40 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Alex Elder
Cc: ~postmarketos/upstreaming, phone-devel, linux-arm-msm, netdev,
devicetree, linux-kernel, Krzysztof Kozlowski, Luca Weiss
In-Reply-To: <20260410-ipa-v5-2-v2-0-778422a05060@fairphone.com>
Add support for the Milos SoC, which uses IPA v5.2.
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
---
Documentation/devicetree/bindings/net/qcom,ipa.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/net/qcom,ipa.yaml b/Documentation/devicetree/bindings/net/qcom,ipa.yaml
index e4bb627e1757..fdeaa81b9645 100644
--- a/Documentation/devicetree/bindings/net/qcom,ipa.yaml
+++ b/Documentation/devicetree/bindings/net/qcom,ipa.yaml
@@ -44,6 +44,7 @@ properties:
compatible:
oneOf:
- enum:
+ - qcom,milos-ipa
- qcom,msm8998-ipa
- qcom,sc7180-ipa
- qcom,sc7280-ipa
--
2.53.0
^ permalink raw reply related
* [PATCH net-next v2 2/2] net: ipa: add IPA v5.2 configuration data
From: Luca Weiss @ 2026-04-10 7:40 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Alex Elder
Cc: ~postmarketos/upstreaming, phone-devel, linux-arm-msm, netdev,
devicetree, linux-kernel, Simon Horman, Luca Weiss
In-Reply-To: <20260410-ipa-v5-2-v2-0-778422a05060@fairphone.com>
Add the configuration data required for IPA v5.2, which is used in
the Qualcomm Milos SoC.
Reviewed-by: Simon Horman <horms@kernel.org>
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
---
drivers/net/ipa/Makefile | 2 +-
drivers/net/ipa/data/ipa_data-v5.2.c | 452 +++++++++++++++++++++++++++++++++++
drivers/net/ipa/gsi_reg.c | 1 +
drivers/net/ipa/ipa_data.h | 1 +
drivers/net/ipa/ipa_main.c | 4 +
drivers/net/ipa/ipa_reg.c | 1 +
drivers/net/ipa/ipa_sysfs.c | 2 +
drivers/net/ipa/ipa_version.h | 2 +
8 files changed, 464 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ipa/Makefile b/drivers/net/ipa/Makefile
index d3abb38633e0..e148ec3c1a10 100644
--- a/drivers/net/ipa/Makefile
+++ b/drivers/net/ipa/Makefile
@@ -7,7 +7,7 @@ IPA_REG_VERSIONS := 3.1 3.5.1 4.2 4.5 4.7 4.9 4.11 5.0 5.5
# Some IPA versions can reuse another set of GSI register definitions.
GSI_REG_VERSIONS := 3.1 3.5.1 4.0 4.5 4.9 4.11 5.0
-IPA_DATA_VERSIONS := 3.1 3.5.1 4.2 4.5 4.7 4.9 4.11 5.0 5.5
+IPA_DATA_VERSIONS := 3.1 3.5.1 4.2 4.5 4.7 4.9 4.11 5.0 5.2 5.5
obj-$(CONFIG_QCOM_IPA) += ipa.o
diff --git a/drivers/net/ipa/data/ipa_data-v5.2.c b/drivers/net/ipa/data/ipa_data-v5.2.c
new file mode 100644
index 000000000000..c56c4f1836ae
--- /dev/null
+++ b/drivers/net/ipa/data/ipa_data-v5.2.c
@@ -0,0 +1,452 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2023-2024 Linaro Ltd.
+ * Copyright (c) 2026, Luca Weiss <luca.weiss@fairphone.com>
+ */
+
+#include <linux/array_size.h>
+#include <linux/log2.h>
+
+#include "../ipa_data.h"
+#include "../ipa_endpoint.h"
+#include "../ipa_mem.h"
+#include "../ipa_version.h"
+
+/** enum ipa_resource_type - IPA resource types for an SoC having IPA v5.2 */
+enum ipa_resource_type {
+ /* Source resource types; first must have value 0 */
+ IPA_RESOURCE_TYPE_SRC_PKT_CONTEXTS = 0,
+ IPA_RESOURCE_TYPE_SRC_DESCRIPTOR_LISTS,
+ IPA_RESOURCE_TYPE_SRC_DESCRIPTOR_BUFF,
+ IPA_RESOURCE_TYPE_SRC_HPS_DMARS,
+ IPA_RESOURCE_TYPE_SRC_ACK_ENTRIES,
+
+ /* Destination resource types; first must have value 0 */
+ IPA_RESOURCE_TYPE_DST_DATA_SECTORS = 0,
+ IPA_RESOURCE_TYPE_DST_DPS_DMARS,
+ IPA_RESOURCE_TYPE_DST_ULSO_SEGMENTS,
+};
+
+/* Resource groups used for an SoC having IPA v5.2 */
+enum ipa_rsrc_group_id {
+ /* Source resource group identifiers */
+ IPA_RSRC_GROUP_SRC_UL = 0,
+ IPA_RSRC_GROUP_SRC_DL,
+ IPA_RSRC_GROUP_SRC_URLLC,
+ IPA_RSRC_GROUP_SRC_COUNT, /* Last in set; not a source group */
+
+ /* Destination resource group identifiers */
+ IPA_RSRC_GROUP_DST_UL = 0,
+ IPA_RSRC_GROUP_DST_DL,
+ IPA_RSRC_GROUP_DST_UNUSED_1,
+ IPA_RSRC_GROUP_DST_DRB_IP,
+ IPA_RSRC_GROUP_DST_COUNT, /* Last; not a destination group */
+};
+
+/* QSB configuration data for an SoC having IPA v5.2 */
+static const struct ipa_qsb_data ipa_qsb_data[] = {
+ [IPA_QSB_MASTER_DDR] = {
+ .max_writes = 13,
+ .max_reads = 13,
+ .max_reads_beats = 0,
+ },
+};
+
+/* Endpoint configuration data for an SoC having IPA v5.2 */
+static const struct ipa_gsi_endpoint_data ipa_gsi_endpoint_data[] = {
+ [IPA_ENDPOINT_AP_COMMAND_TX] = {
+ .ee_id = GSI_EE_AP,
+ .channel_id = 6,
+ .endpoint_id = 9,
+ .toward_ipa = true,
+ .channel = {
+ .tre_count = 256,
+ .event_count = 256,
+ .tlv_count = 20,
+ },
+ .endpoint = {
+ .config = {
+ .resource_group = IPA_RSRC_GROUP_SRC_UL,
+ .dma_mode = true,
+ .dma_endpoint = IPA_ENDPOINT_AP_LAN_RX,
+ .tx = {
+ .seq_type = IPA_SEQ_DMA,
+ },
+ },
+ },
+ },
+ [IPA_ENDPOINT_AP_LAN_RX] = {
+ .ee_id = GSI_EE_AP,
+ .channel_id = 7,
+ .endpoint_id = 11,
+ .toward_ipa = false,
+ .channel = {
+ .tre_count = 256,
+ .event_count = 256,
+ .tlv_count = 9,
+ },
+ .endpoint = {
+ .config = {
+ .resource_group = IPA_RSRC_GROUP_DST_UL,
+ .aggregation = true,
+ .status_enable = true,
+ .rx = {
+ .buffer_size = 8192,
+ .pad_align = ilog2(sizeof(u32)),
+ .aggr_time_limit = 500,
+ },
+ },
+ },
+ },
+ [IPA_ENDPOINT_AP_MODEM_TX] = {
+ .ee_id = GSI_EE_AP,
+ .channel_id = 5,
+ .endpoint_id = 2,
+ .toward_ipa = true,
+ .channel = {
+ .tre_count = 512,
+ .event_count = 512,
+ .tlv_count = 25,
+ },
+ .endpoint = {
+ .filter_support = true,
+ .config = {
+ .resource_group = IPA_RSRC_GROUP_SRC_UL,
+ .checksum = true,
+ .qmap = true,
+ .status_enable = true,
+ .tx = {
+ .seq_type = IPA_SEQ_2_PASS_SKIP_LAST_UC,
+ .status_endpoint =
+ IPA_ENDPOINT_MODEM_AP_RX,
+ },
+ },
+ },
+ },
+ [IPA_ENDPOINT_AP_MODEM_RX] = {
+ .ee_id = GSI_EE_AP,
+ .channel_id = 9,
+ .endpoint_id = 18,
+ .toward_ipa = false,
+ .channel = {
+ .tre_count = 256,
+ .event_count = 256,
+ .tlv_count = 9,
+ },
+ .endpoint = {
+ .config = {
+ .resource_group = IPA_RSRC_GROUP_DST_DL,
+ .checksum = true,
+ .qmap = true,
+ .aggregation = true,
+ .rx = {
+ .buffer_size = 8192,
+ .aggr_time_limit = 500,
+ .aggr_close_eof = true,
+ },
+ },
+ },
+ },
+ [IPA_ENDPOINT_MODEM_AP_TX] = {
+ .ee_id = GSI_EE_MODEM,
+ .channel_id = 0,
+ .endpoint_id = 7,
+ .toward_ipa = true,
+ .endpoint = {
+ .filter_support = true,
+ },
+ },
+ [IPA_ENDPOINT_MODEM_AP_RX] = {
+ .ee_id = GSI_EE_MODEM,
+ .channel_id = 7,
+ .endpoint_id = 16,
+ .toward_ipa = false,
+ },
+ [IPA_ENDPOINT_MODEM_DL_NLO_TX] = {
+ .ee_id = GSI_EE_MODEM,
+ .channel_id = 2,
+ .endpoint_id = 10,
+ .toward_ipa = true,
+ .endpoint = {
+ .filter_support = true,
+ },
+ },
+};
+
+/* Source resource configuration data for an SoC having IPA v5.2 */
+static const struct ipa_resource ipa_resource_src[] = {
+ [IPA_RESOURCE_TYPE_SRC_PKT_CONTEXTS] = {
+ .limits[IPA_RSRC_GROUP_SRC_UL] = {
+ .min = 1, .max = 7,
+ },
+ .limits[IPA_RSRC_GROUP_SRC_DL] = {
+ .min = 1, .max = 7,
+ },
+ .limits[IPA_RSRC_GROUP_SRC_URLLC] = {
+ .min = 0, .max = 5,
+ },
+ },
+ [IPA_RESOURCE_TYPE_SRC_DESCRIPTOR_LISTS] = {
+ .limits[IPA_RSRC_GROUP_SRC_UL] = {
+ .min = 8, .max = 8,
+ },
+ .limits[IPA_RSRC_GROUP_SRC_DL] = {
+ .min = 8, .max = 8,
+ },
+ .limits[IPA_RSRC_GROUP_SRC_URLLC] = {
+ .min = 8, .max = 8,
+ },
+ },
+ [IPA_RESOURCE_TYPE_SRC_DESCRIPTOR_BUFF] = {
+ .limits[IPA_RSRC_GROUP_SRC_UL] = {
+ .min = 10, .max = 10,
+ },
+ .limits[IPA_RSRC_GROUP_SRC_DL] = {
+ .min = 12, .max = 12,
+ },
+ .limits[IPA_RSRC_GROUP_SRC_URLLC] = {
+ .min = 12, .max = 12,
+ },
+ },
+ [IPA_RESOURCE_TYPE_SRC_HPS_DMARS] = {
+ .limits[IPA_RSRC_GROUP_SRC_UL] = {
+ .min = 0, .max = 63,
+ },
+ .limits[IPA_RSRC_GROUP_SRC_DL] = {
+ .min = 0, .max = 63,
+ },
+ .limits[IPA_RSRC_GROUP_SRC_URLLC] = {
+ .min = 0, .max = 63,
+ },
+ },
+ [IPA_RESOURCE_TYPE_SRC_ACK_ENTRIES] = {
+ .limits[IPA_RSRC_GROUP_SRC_UL] = {
+ .min = 15, .max = 15,
+ },
+ .limits[IPA_RSRC_GROUP_SRC_DL] = {
+ .min = 15, .max = 15,
+ },
+ .limits[IPA_RSRC_GROUP_SRC_URLLC] = {
+ .min = 12, .max = 12,
+ },
+ },
+};
+
+/* Destination resource configuration data for an SoC having IPA v5.2 */
+static const struct ipa_resource ipa_resource_dst[] = {
+ [IPA_RESOURCE_TYPE_DST_DATA_SECTORS] = {
+ .limits[IPA_RSRC_GROUP_DST_UL] = {
+ .min = 3, .max = 3,
+ },
+ .limits[IPA_RSRC_GROUP_DST_DL] = {
+ .min = 3, .max = 3,
+ },
+ .limits[IPA_RSRC_GROUP_DST_DRB_IP] = {
+ .min = 23, .max = 23,
+ },
+ },
+ [IPA_RESOURCE_TYPE_DST_DPS_DMARS] = {
+ .limits[IPA_RSRC_GROUP_DST_UL] = {
+ .min = 1, .max = 2,
+ },
+ .limits[IPA_RSRC_GROUP_DST_DL] = {
+ .min = 1, .max = 2,
+ },
+ },
+ [IPA_RESOURCE_TYPE_DST_ULSO_SEGMENTS] = {
+ .limits[IPA_RSRC_GROUP_DST_UL] = {
+ .min = 1, .max = 63,
+ },
+ .limits[IPA_RSRC_GROUP_DST_DL] = {
+ .min = 1, .max = 63,
+ },
+ },
+};
+
+/* Resource configuration data for an SoC having IPA v5.2 */
+static const struct ipa_resource_data ipa_resource_data = {
+ .rsrc_group_dst_count = IPA_RSRC_GROUP_DST_COUNT,
+ .rsrc_group_src_count = IPA_RSRC_GROUP_SRC_COUNT,
+ .resource_src_count = ARRAY_SIZE(ipa_resource_src),
+ .resource_src = ipa_resource_src,
+ .resource_dst_count = ARRAY_SIZE(ipa_resource_dst),
+ .resource_dst = ipa_resource_dst,
+};
+
+/* IPA-resident memory region data for an SoC having IPA v5.2 */
+static const struct ipa_mem ipa_mem_local_data[] = {
+ {
+ .id = IPA_MEM_UC_SHARED,
+ .offset = 0x0000,
+ .size = 0x0080,
+ .canary_count = 0,
+ },
+ {
+ .id = IPA_MEM_UC_INFO,
+ .offset = 0x0080,
+ .size = 0x0200,
+ .canary_count = 0,
+ },
+ {
+ .id = IPA_MEM_V4_FILTER_HASHED,
+ .offset = 0x0288,
+ .size = 0x0078,
+ .canary_count = 2,
+ },
+ {
+ .id = IPA_MEM_V4_FILTER,
+ .offset = 0x0308,
+ .size = 0x0078,
+ .canary_count = 2,
+ },
+ {
+ .id = IPA_MEM_V6_FILTER_HASHED,
+ .offset = 0x0388,
+ .size = 0x0078,
+ .canary_count = 2,
+ },
+ {
+ .id = IPA_MEM_V6_FILTER,
+ .offset = 0x0408,
+ .size = 0x0078,
+ .canary_count = 2,
+ },
+ {
+ .id = IPA_MEM_V4_ROUTE_HASHED,
+ .offset = 0x0488,
+ .size = 0x0098,
+ .canary_count = 2,
+ },
+ {
+ .id = IPA_MEM_V4_ROUTE,
+ .offset = 0x0528,
+ .size = 0x0098,
+ .canary_count = 2,
+ },
+ {
+ .id = IPA_MEM_V6_ROUTE_HASHED,
+ .offset = 0x05c8,
+ .size = 0x0098,
+ .canary_count = 2,
+ },
+ {
+ .id = IPA_MEM_V6_ROUTE,
+ .offset = 0x0668,
+ .size = 0x0098,
+ .canary_count = 2,
+ },
+ {
+ .id = IPA_MEM_MODEM_HEADER,
+ .offset = 0x0708,
+ .size = 0x0240,
+ .canary_count = 2,
+ },
+ {
+ .id = IPA_MEM_AP_HEADER,
+ .offset = 0x0948,
+ .size = 0x01e0,
+ .canary_count = 0,
+ },
+ {
+ .id = IPA_MEM_MODEM_PROC_CTX,
+ .offset = 0x0b40,
+ .size = 0x0b20,
+ .canary_count = 2,
+ },
+ {
+ .id = IPA_MEM_AP_PROC_CTX,
+ .offset = 0x1660,
+ .size = 0x0200,
+ .canary_count = 0,
+ },
+ {
+ .id = IPA_MEM_STATS_QUOTA_MODEM,
+ .offset = 0x1868,
+ .size = 0x0060,
+ .canary_count = 2,
+ },
+ {
+ .id = IPA_MEM_STATS_QUOTA_AP,
+ .offset = 0x18c8,
+ .size = 0x0048,
+ .canary_count = 0,
+ },
+ {
+ .id = IPA_MEM_STATS_TETHERING,
+ .offset = 0x1910,
+ .size = 0x03c0,
+ .canary_count = 0,
+ },
+ {
+ .id = IPA_MEM_STATS_FILTER_ROUTE,
+ .offset = 0x1cd0,
+ .size = 0x0ba0,
+ .canary_count = 0,
+ },
+ {
+ .id = IPA_MEM_STATS_DROP,
+ .offset = 0x2870,
+ .size = 0x0020,
+ .canary_count = 0,
+ },
+ {
+ .id = IPA_MEM_MODEM,
+ .offset = 0x2898,
+ .size = 0x0d48,
+ .canary_count = 2,
+ },
+ {
+ .id = IPA_MEM_NAT_TABLE,
+ .offset = 0x35e0,
+ .size = 0x0900,
+ .canary_count = 0,
+ },
+ {
+ .id = IPA_MEM_PDN_CONFIG,
+ .offset = 0x3ee8,
+ .size = 0x0100,
+ .canary_count = 2,
+ },
+};
+
+/* Memory configuration data for an SoC having IPA v5.2 */
+static const struct ipa_mem_data ipa_mem_data = {
+ .local_count = ARRAY_SIZE(ipa_mem_local_data),
+ .local = ipa_mem_local_data,
+ .smem_size = 0x0000b000,
+};
+
+/* Interconnect rates are in 1000 byte/second units */
+static const struct ipa_interconnect_data ipa_interconnect_data[] = {
+ {
+ .name = "memory",
+ .peak_bandwidth = 1300000, /* 1.3 GBps */
+ .average_bandwidth = 600000, /* 600 MBps */
+ },
+ /* Average rate is unused for the next interconnect */
+ {
+ .name = "config",
+ .peak_bandwidth = 76800, /* 76.8 MBps */
+ .average_bandwidth = 0, /* unused */
+ },
+};
+
+/* Clock and interconnect configuration data for an SoC having IPA v5.2 */
+static const struct ipa_power_data ipa_power_data = {
+ .core_clock_rate = 120 * 1000 * 1000, /* Hz */
+ .interconnect_count = ARRAY_SIZE(ipa_interconnect_data),
+ .interconnect_data = ipa_interconnect_data,
+};
+
+/* Configuration data for an SoC having IPA v5.2. */
+const struct ipa_data ipa_data_v5_2 = {
+ .version = IPA_VERSION_5_2,
+ .qsb_count = ARRAY_SIZE(ipa_qsb_data),
+ .qsb_data = ipa_qsb_data,
+ .modem_route_count = 11,
+ .endpoint_count = ARRAY_SIZE(ipa_gsi_endpoint_data),
+ .endpoint_data = ipa_gsi_endpoint_data,
+ .resource_data = &ipa_resource_data,
+ .mem_data = &ipa_mem_data,
+ .power_data = &ipa_power_data,
+};
diff --git a/drivers/net/ipa/gsi_reg.c b/drivers/net/ipa/gsi_reg.c
index 825598661188..e13cf835a013 100644
--- a/drivers/net/ipa/gsi_reg.c
+++ b/drivers/net/ipa/gsi_reg.c
@@ -110,6 +110,7 @@ static const struct regs *gsi_regs(struct gsi *gsi)
return &gsi_regs_v4_11;
case IPA_VERSION_5_0:
+ case IPA_VERSION_5_2:
case IPA_VERSION_5_5:
return &gsi_regs_v5_0;
diff --git a/drivers/net/ipa/ipa_data.h b/drivers/net/ipa/ipa_data.h
index f3bdc64cef05..3eb9dc2ce339 100644
--- a/drivers/net/ipa/ipa_data.h
+++ b/drivers/net/ipa/ipa_data.h
@@ -253,6 +253,7 @@ extern const struct ipa_data ipa_data_v4_7;
extern const struct ipa_data ipa_data_v4_9;
extern const struct ipa_data ipa_data_v4_11;
extern const struct ipa_data ipa_data_v5_0;
+extern const struct ipa_data ipa_data_v5_2;
extern const struct ipa_data ipa_data_v5_5;
#endif /* _IPA_DATA_H_ */
diff --git a/drivers/net/ipa/ipa_main.c b/drivers/net/ipa/ipa_main.c
index edead9c48d1f..8e2b4bf7b14e 100644
--- a/drivers/net/ipa/ipa_main.c
+++ b/drivers/net/ipa/ipa_main.c
@@ -669,6 +669,10 @@ static const struct of_device_id ipa_match[] = {
.compatible = "qcom,sdx65-ipa",
.data = &ipa_data_v5_0,
},
+ {
+ .compatible = "qcom,milos-ipa",
+ .data = &ipa_data_v5_2,
+ },
{
.compatible = "qcom,sm8550-ipa",
.data = &ipa_data_v5_5,
diff --git a/drivers/net/ipa/ipa_reg.c b/drivers/net/ipa/ipa_reg.c
index c574f798fdc9..30bd69f4c147 100644
--- a/drivers/net/ipa/ipa_reg.c
+++ b/drivers/net/ipa/ipa_reg.c
@@ -125,6 +125,7 @@ static const struct regs *ipa_regs(enum ipa_version version)
case IPA_VERSION_4_11:
return &ipa_regs_v4_11;
case IPA_VERSION_5_0:
+ case IPA_VERSION_5_2:
return &ipa_regs_v5_0;
case IPA_VERSION_5_5:
return &ipa_regs_v5_5;
diff --git a/drivers/net/ipa/ipa_sysfs.c b/drivers/net/ipa/ipa_sysfs.c
index a53e9e6f6cdf..8b805a9d49e6 100644
--- a/drivers/net/ipa/ipa_sysfs.c
+++ b/drivers/net/ipa/ipa_sysfs.c
@@ -39,6 +39,8 @@ static const char *ipa_version_string(struct ipa *ipa)
return "5.0";
case IPA_VERSION_5_1:
return "5.1";
+ case IPA_VERSION_5_2:
+ return "5.2";
case IPA_VERSION_5_5:
return "5.5";
default:
diff --git a/drivers/net/ipa/ipa_version.h b/drivers/net/ipa/ipa_version.h
index 38c47f51a50c..c157c72a5bad 100644
--- a/drivers/net/ipa/ipa_version.h
+++ b/drivers/net/ipa/ipa_version.h
@@ -23,6 +23,7 @@
* @IPA_VERSION_4_11: IPA version 4.11/GSI version 2.11 (2.1.1)
* @IPA_VERSION_5_0: IPA version 5.0/GSI version 3.0
* @IPA_VERSION_5_1: IPA version 5.1/GSI version 3.0
+ * @IPA_VERSION_5_2: IPA version 5.2/GSI version 5.2
* @IPA_VERSION_5_5: IPA version 5.5/GSI version 5.5
* @IPA_VERSION_COUNT: Number of defined IPA versions
*
@@ -43,6 +44,7 @@ enum ipa_version {
IPA_VERSION_4_11,
IPA_VERSION_5_0,
IPA_VERSION_5_1,
+ IPA_VERSION_5_2,
IPA_VERSION_5_5,
IPA_VERSION_COUNT, /* Last; not a version */
};
--
2.53.0
^ permalink raw reply related
* RE: [PATCH v6 04/10] clk: realtek: Add support for phase locked loops (PLLs)
From: Yu-Chun Lin [林祐君] @ 2026-04-10 7:43 UTC (permalink / raw)
To: Brian Masney
Cc: mturquette@baylibre.com, sboyd@kernel.org, robh@kernel.org,
krzk+dt@kernel.org, conor+dt@kernel.org, p.zabel@pengutronix.de,
Edgar Lee [李承諭], afaerber@suse.com,
Jyan Chou [周芷安], devicetree@vger.kernel.org,
linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-realtek-soc@lists.infradead.org,
James Tai [戴志峰],
CY_Huang[黃鉦晏],
Stanley Chang[昌育德]
In-Reply-To: <ac_QBGY8VxcvuVlY@redhat.com>
Hi Brian,
> Hi Cheng-Yu,
>
> On Thu, Apr 02, 2026 at 03:39:51PM +0800, Yu-Chun Lin wrote:
> > From: Cheng-Yu Lee <cylee12@realtek.com>
> >
> > Provide a full set of PLL operations for programmable PLLs and a
> > read-only variant for fixed or hardware-managed PLLs.
> >
> > Signed-off-by: Cheng-Yu Lee <cylee12@realtek.com>
> > Co-developed-by: Yu-Chun Lin <eleanor.lin@realtek.com>
> > Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
> > ---
> > Changes in v6:
> > - Add the headers used in c file to follow the "Include What You Use"
> principle.
> > - Move to_clk_pll() from clk-pll.h to clk-pll.c to limit its scope.
> > ---
> > drivers/clk/realtek/Makefile | 2 +
> > drivers/clk/realtek/clk-pll.c | 164
> +++++++++++++++++++++++++++++++
> > drivers/clk/realtek/clk-pll.h | 42 ++++++++
> > drivers/clk/realtek/freq_table.c | 36 +++++++
> > drivers/clk/realtek/freq_table.h | 21 ++++
> > 5 files changed, 265 insertions(+)
> > create mode 100644 drivers/clk/realtek/clk-pll.c create mode 100644
> > drivers/clk/realtek/clk-pll.h create mode 100644
> > drivers/clk/realtek/freq_table.c create mode 100644
> > drivers/clk/realtek/freq_table.h
> >
> > diff --git a/drivers/clk/realtek/Makefile
> > b/drivers/clk/realtek/Makefile index 377ec776ee47..a89ad77993e9 100644
> > --- a/drivers/clk/realtek/Makefile
> > +++ b/drivers/clk/realtek/Makefile
> > @@ -2,3 +2,5 @@
> > obj-$(CONFIG_RTK_CLK_COMMON) += clk-rtk.o
> >
> > clk-rtk-y += common.o
> > +clk-rtk-y += clk-pll.o
> > +clk-rtk-y += freq_table.o
> > diff --git a/drivers/clk/realtek/clk-pll.c
> > b/drivers/clk/realtek/clk-pll.c new file mode 100644 index
> > 000000000000..44730b22a94c
> > --- /dev/null
> > +++ b/drivers/clk/realtek/clk-pll.c
> > @@ -0,0 +1,164 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * Copyright (C) 2024 Realtek Semiconductor Corporation
> > + * Author: Cheng-Yu Lee <cylee12@realtek.com> */
> > +
> > +#include <linux/regmap.h>
> > +#include "clk-pll.h"
> > +
> > +#define TIMEOUT 2000
> > +
> > +static inline struct clk_pll *to_clk_pll(struct clk_hw *hw) {
> > + struct clk_regmap *clkr = to_clk_regmap(hw);
> > +
> > + return container_of(clkr, struct clk_pll, clkr); }
> > +
> > +static int wait_freq_ready(struct clk_pll *clkp) {
> > + u32 pollval;
> > +
> > + if (!clkp->freq_ready_valid)
> > + return 0;
> > +
> > + return regmap_read_poll_timeout_atomic(clkp->clkr.regmap,
> clkp->freq_ready_reg, pollval,
> > + (pollval &
> clkp->freq_ready_mask)
> > + ==
> clkp->freq_ready_val,
> > + 0, TIMEOUT);
>
> I would put the "(pollval & clkp->freq_ready_mask) == clkp->freq_ready_val"
> on the same line to improve readability. You can go out to 100 characters.
>
> Also should the delay be greater than 0 to avoid tons of constant retries?
>
Since aligning with the open parenthesis would exceed the 100-character limit,
I will use an extra tab for the continuation line.
Also, I have increased the delay_us parameter to 1 to avoid constant retries.
The code will look like this:
return regmap_read_poll_timeout_atomic(clkp->clkr.regmap, clkp->freq_ready_reg, pollval,
(pollval & clkp->freq_ready_mask) == clkp->freq_ready_val, 1, TIMEOUT);
> > +}
> > +
> > +static bool is_power_on(struct clk_pll *clkp) {
> > + u32 val;
> > +
> > + if (!clkp->power_reg)
> > + return true;
> > +
> > + if (regmap_read(clkp->clkr.regmap, clkp->power_reg, &val))
> > + return true;
>
> Is the intention if there is an error, then it marks it as success?
>
Returning true here is a conservative design choice. When reading the power
status fails, returning true prevents unconditionally turning off the clock.
> > +
> > + return (val & clkp->power_mask) == clkp->power_val_on; }
> > +
> > +static void clk_pll_disable(struct clk_hw *hw) {
> > + struct clk_pll *clkp = to_clk_pll(hw);
> > +
> > + if (!clkp->seq_power_off)
> > + return;
> > +
> > + regmap_multi_reg_write(clkp->clkr.regmap, clkp->seq_power_off,
> > + clkp->num_seq_power_off); }
> > +
> > +static int clk_pll_is_enabled(struct clk_hw *hw) {
> > + struct clk_pll *clkp = to_clk_pll(hw);
> > +
> > + return is_power_on(clkp);
> > +}
> > +
> > +static int clk_pll_determine_rate(struct clk_hw *hw,
> > + struct clk_rate_request *req) {
> > + struct clk_pll *clkp = to_clk_pll(hw);
> > + const struct freq_table *ftblv = NULL;
> > +
> > + ftblv = ftbl_find_by_rate(clkp->freq_tbl, req->rate);
> > + if (!ftblv)
> > + return -EINVAL;
> > +
> > + req->rate = ftblv->rate;
> > + return 0;
>
> Add newline before return.
>
Ack.
> > +}
> > +
> > +static unsigned long clk_pll_recalc_rate(struct clk_hw *hw,
> > + unsigned long parent_rate) {
> > + struct clk_pll *clkp = to_clk_pll(hw);
> > + const struct freq_table *fv;
> > + u32 freq_val;
> > +
> > + if (regmap_read(clkp->clkr.regmap, clkp->freq_reg, &freq_val))
> > + return 0;
> > +
> > + freq_val &= clkp->freq_mask;
> > +
> > + fv = ftbl_find_by_val_with_mask(clkp->freq_tbl, clkp->freq_mask,
> > + freq_val);
> > + return fv ? fv->rate : 0;
>
> Add newline before return.
>
Ack.
> > +}
> > +
(snip)
> > index 000000000000..272a10e75a54
> > --- /dev/null
> > +++ b/drivers/clk/realtek/freq_table.c
> > @@ -0,0 +1,36 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +
> > +#include <linux/bitops.h>
> > +#include "freq_table.h"
> > +
> > +const struct freq_table *ftbl_find_by_rate(const struct freq_table *ftbl,
> > + unsigned long rate) {
> > + unsigned long best_rate = 0;
> > + const struct freq_table *best = NULL;
>
> Put variables in reverse Christmas tree order.
Ack
>
> > +
> > + for (; !IS_FREQ_TABLE_END(ftbl); ftbl++) {
> > + if (ftbl->rate == rate)
> > + return ftbl;
> > +
> > + if (ftbl->rate > rate)
> > + continue;
> > +
> > + if (ftbl->rate > best_rate) {
> > + best_rate = ftbl->rate;
> > + best = ftbl;
> > + }
> > + }
> > +
> > + return best;
> > +}
> > +
> > +const struct freq_table *
> > +ftbl_find_by_val_with_mask(const struct freq_table *ftbl, u32 mask,
> > +u32 value) {
> > + for (; !IS_FREQ_TABLE_END(ftbl); ftbl++) {
> > + if ((ftbl->val & mask) == (value & mask))
> > + return ftbl;
> > + }
> > + return NULL;
> > +};
> > diff --git a/drivers/clk/realtek/freq_table.h
> > b/drivers/clk/realtek/freq_table.h
> > new file mode 100644
> > index 000000000000..6d9116651105
> > --- /dev/null
> > +++ b/drivers/clk/realtek/freq_table.h
> > @@ -0,0 +1,21 @@
> > +/* SPDX-License-Identifier: GPL-2.0-only */
> > +
> > +struct freq_table {
> > + u32 val;
> > + unsigned long rate;
> > +};
> > +
> > +/* ofs check */
> > +#define CLK_OFS_INVALID -1
> > +#define CLK_OFS_IS_VALID(_ofs) ((_ofs) != CLK_OFS_INVALID)
>
> Is this used anywhere?
I will drop them.
Best Regards,
Yu-Chun
>
> Brian
^ permalink raw reply
* Re: [PATCH v2 8/8] arm64: dts: qcom: eliza: Add support for MM clock controllers
From: Krzysztof Kozlowski @ 2026-04-10 7:44 UTC (permalink / raw)
To: Taniya Das
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio, Maxime Coquelin,
Alexandre Torgue, Ajit Pandey, Imran Shaik, Jagadeesh Kona,
linux-arm-msm, linux-clk, devicetree, linux-kernel, linux-stm32,
linux-arm-kernel
In-Reply-To: <20260409-eliza_mm_cc_v2-v2-8-bc0c6dd77bc5@oss.qualcomm.com>
On Thu, Apr 09, 2026 at 11:40:49PM +0530, Taniya Das wrote:
> Add the device nodes for the multimedia clock controllers (cambistmclkcc,
> camcc, videocc, gpucc) for Qualcomm Eliza SoC.
>
> Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/eliza.dtsi | 54 +++++++++++++++++++++++++++++++++++++
> 1 file changed, 54 insertions(+)
Note that this patch and drivers parches were likely not tested.
Please mark patches you wish others to test as RFT.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 3/8] dt-bindings: clock: qcom: Add support for CAMCC for Eliza
From: Krzysztof Kozlowski @ 2026-04-10 7:47 UTC (permalink / raw)
To: Taniya Das
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio, Maxime Coquelin,
Alexandre Torgue, Ajit Pandey, Imran Shaik, Jagadeesh Kona,
linux-arm-msm, linux-clk, devicetree, linux-kernel, linux-stm32,
linux-arm-kernel
In-Reply-To: <20260409-eliza_mm_cc_v2-v2-3-bc0c6dd77bc5@oss.qualcomm.com>
On Thu, Apr 09, 2026 at 11:40:44PM +0530, Taniya Das wrote:
> Update the compatible and the bindings for CAMCC support on Eliza SoC.
I do not see any update here. Also, no improvements after v1 comments.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 1/4] dt-bindings: vendor-prefixes: Add QST Corporation
From: Krzysztof Kozlowski @ 2026-04-10 7:52 UTC (permalink / raw)
To: Hardik Phalet
Cc: Greg Kroah-Hartman, Jonathan Cameron, David Lechner, Nuno Sá,
Andy Shevchenko, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Brigham Campbell, Shuah Khan, linux-iio, devicetree, linux-kernel,
linux-staging
In-Reply-To: <20260409210639.3197576-2-hardik.phalet@pm.me>
On Thu, Apr 09, 2026 at 09:07:20PM +0000, Hardik Phalet wrote:
> Add the vendor prefix 'qst' for QST Corporation, a manufacturer of
> MEMS sensors.
>
> Signed-off-by: Hardik Phalet <hardik.phalet@pm.me>
> ---
> Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> index 5d2a7a8d3ac6..71a1b9087c5e 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
> @@ -1244,6 +1244,8 @@ patternProperties:
> description: Shenzhen QiShenglong Industrialist Co., Ltd.
> "^qnap,.*":
> description: QNAP Systems, Inc.
> + "^qst,.*":
Website tells me qstcorp.com, so prefix is qstcorp. Unless it is
different company, but then just explain that in commit msg (e.g.
provide link to website).
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 2/4] ASoC: dt-bindings: Add support for the GPIOs driven amplifier
From: Herve Codina @ 2026-04-10 7:52 UTC (permalink / raw)
To: Rob Herring
Cc: Liam Girdwood, Mark Brown, Krzysztof Kozlowski, Conor Dooley,
Saravana Kannan, Jaroslav Kysela, Takashi Iwai, linux-sound,
devicetree, linux-kernel, Christophe Leroy, Thomas Petazzoni
In-Reply-To: <CAL_JsqK4SHQS6MciQpLSrGWo2knqs7-eB3yoAv2J54bSfW-Lxg@mail.gmail.com>
Hi Rob, Mark,
On Thu, 9 Apr 2026 10:00:55 -0500
Rob Herring <robh@kernel.org> wrote:
...
>
> > > If not, then gain-range could be expressed using gain-points instead.
> >
> > Do you have in mind something like the following?
> > gain-range = <0 (-300)>, <3 600>;
> >
> > defining the range from -3dB to +6dB with GPIOs value 0 for -3dB and 3 for +6dB.
>
> Yes, but since you can have reserved values, that won't work.
In that case gpio-points can be used.
The other solution will be to allow multiple ranges:
gpios Gain
0b000 -> -6dB
0b001 -> -3dB
0b010 -> 0dB
0b011 -> Reserved
0b100 -> +3dB
0b101 -> +6dB
other -> Reserved
This could be described as
gain-ranges = <0 (-600)>, <2 0>,
<4 300>, <5 600>;
As a side note, this will probably add quite a lot of complexity to handle
multiple ranges in the driver. If too complex, the driver will handle only
one range and returns -ENOTSUPP if multiple ranges (more than one) are used.
Is that something acceptable?
...
> > > > + description: |
> > > > + List of the gain labels attached to the combination of GPIOs controlling
> > > > + the gain. The first label is related to the gain value 0, the second label
> > > > + is related to the gain value 1 and so on.
> > > > +
> > > > + With 2 GPIOs controlling the gain, GPIOs value can be 0, 1, 2 and 3.
> > > > + Assuming that gain value set the hardware according to the following
> > > > + table:
> > > > +
> > > > + GPIOs | Hardware
> > > > + value | amplification
> > > > + ------+--------------
> > > > + 0 | Low
> > > > + 1 | Middle
> > > > + 2 | High
> > > > + 3 | Max
> > > > + ------+--------------
> > > > +
> > > > + The description using gain labels can be:
> > > > + gain-labels = "Low", "Middle", "High", "Max";
> > >
> > > Do we need to allow these to be anything? It's going to get hard to come
> > > up with 2^32 names.
> >
> > Well, "Normal" / "Boost" can make sense on some hardware.
> >
> > I don't think we need to restrict labels to a list of known label here.
>
> As long as the names are meaningless to software.
>
> >
> > Of course 2^32 names is obviously a lot. What could be the limit?
>
> I would guess at 8 or more, it's just going to be gain1, gain2, etc.
> or something similar constructed from the gain values.
I suppose that gpio-points or gpio-ranges are going to be used instead
of labels at 8 or more.
With a lot number of GPIOs involved, I am not sure that using labels makes
sense even from the hardware point of view.
The 3 possible descriptions (gpio-points, gpio-range(s), gpio-labels) are
mutually exclusive. Depending on the hardware designed, one of them has to
be chosen.
Of course, you can describe 256 labels but does it make sense in that case
with alternative available ?
>
> > ...
> >
> > > > +
> > > > + /* A mutable amplifier without any gain control */
> > > > + amplifier4 {
> > > > + compatible = "audio-gpio-amp";
> > > > + vdd-supply = <®ulator>;
> > > > + mute-gpios = <&gpio 0 GPIO_ACTIVE_HIGH>;
> > >
> > > This case is just simple-amplifier...
> >
> > No, simple-amplifier uses 'enable' and not 'mute'.
>
> Yes, I know...
>
> > We can have the amplifier enabled ('enable' GPIO active) as it is
> > used and a switch driven by an other GPIO to mute / un-mute the
> > amplifier output.
>
> But you have no 'enable' GPIO here. To me, enable just looks like
> inverted mute. If there's some electrical difference, I can't tell
> what that is from either binding.
A known physical component handle by simple-amplifier is the dio2125.
According to its datasheet:
Pop-free power up is ensured by keeping the EN (shutdown pin) low during
power down. The EN pin should be kept low EN pin high to achieve pop-less
power up
The 'enable' gpio should be used when power is established or remove.
The mute gpio handle an output switch:
+---------+ op-amp output
| dio2125 +-------------------o
| | o---- Amplifier feature output
enable ---+ | ,--o ^
| | | |
+---------+ v |
GND |
|
mute --------------------------------------'
The mute signal switches on/off the dio2125 output while the dio2125 is
active (powered uup) and so its enable pin is driven high.
I can add an 'enable' GPIO here to handle it in the same way as it is handled in the
simple-amplifier (dio2125 use case).
>
> I guess my point was that really we could deprecate simple-amplifier
> binding because this one can handle it and more. But I'm not
> suggesting we do that yet.
>
Best regards,
Hervé
^ permalink raw reply
* Re: [PATCH v2 2/4] dt-bindings: iio: magnetometer: Add binding for QST QMC5883P
From: Krzysztof Kozlowski @ 2026-04-10 7:55 UTC (permalink / raw)
To: Hardik Phalet
Cc: Greg Kroah-Hartman, Jonathan Cameron, David Lechner, Nuno Sá,
Andy Shevchenko, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Brigham Campbell, Shuah Khan, linux-iio, devicetree, linux-kernel,
linux-staging
In-Reply-To: <20260409210639.3197576-3-hardik.phalet@pm.me>
On Thu, Apr 09, 2026 at 09:07:29PM +0000, Hardik Phalet wrote:
> Add the device tree binding document for the QST QMC5883P, a 3-axis
> anisotropic magneto-resistive (AMR) sensor with a 16-bit ADC that
> communicates over I2C. The binding exposes the required 'compatible'
> and 'reg' properties along with an optional 'vdd-supply' for the
> 2.5 V–3.6 V VDD rail.
Drop last sentence. We can read the diff.
...
> +properties:
> + compatible:
> + const: qst,qmc5883p
> +
> + reg:
> + maxItems: 1
> + description: I2C address of the device; the default address is 0x2c.
> +
> + vdd-supply:
> + description:
> + VDD power supply (2.5 V to 3.6 V). Powers all internal analog and
> + digital functional blocks.
Supply should be required. Devices need them to operate.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v6 04/10] clk: realtek: Add support for phase locked loops (PLLs)
From: Yu-Chun Lin @ 2026-04-10 7:53 UTC (permalink / raw)
To: bmasney
Cc: afaerber, conor+dt, cy.huang, cylee12, devicetree, eleanor.lin,
james.tai, jyanchou, krzk+dt, linux-arm-kernel, linux-clk,
linux-kernel, linux-realtek-soc, mturquette, p.zabel, robh, sboyd,
stanley_chang
In-Reply-To: <ac_SX1UJRqiBH2iM@redhat.com>
Hi Brian,
> Hi Cheng-Yu and Yu-Chun,
>
> On Thu, Apr 02, 2026 at 03:39:51PM +0800, Yu-Chun Lin wrote:
> > From: Cheng-Yu Lee <cylee12@realtek.com>
> >
> > Provide a full set of PLL operations for programmable PLLs and a read-only
> > variant for fixed or hardware-managed PLLs.
> >
> > Signed-off-by: Cheng-Yu Lee <cylee12@realtek.com>
> > Co-developed-by: Yu-Chun Lin <eleanor.lin@realtek.com>
> > Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
> > ---
> > +static int clk_pll_set_rate(struct clk_hw *hw, unsigned long rate,
> > + unsigned long parent_rate)
> > +{
> > + struct clk_pll *clkp = to_clk_pll(hw);
> > + const struct freq_table *fv;
> > + int ret;
> > +
> > + fv = ftbl_find_by_rate(clkp->freq_tbl, rate);
> > + if (!fv || fv->rate != rate)
> > + return -EINVAL;
> > +
> > + if (clkp->seq_pre_set_freq) {
> > + ret = regmap_multi_reg_write(clkp->clkr.regmap, clkp->seq_pre_set_freq,
> > + clkp->num_seq_pre_set_freq);
> > + if (ret)
> > + return ret;
> > + }
> > +
> > + ret = regmap_update_bits(clkp->clkr.regmap, clkp->freq_reg,
> > + clkp->freq_mask, fv->val);
> > + if (ret)
> > + return ret;
> > +
> > + if (clkp->seq_post_set_freq) {
> > + ret = regmap_multi_reg_write(clkp->clkr.regmap, clkp->seq_post_set_freq,
> > + clkp->num_seq_post_set_freq);
> > + if (ret)
> > + return ret;
> > + }
> > +
> > + if (is_power_on(clkp)) {
> > + ret = wait_freq_ready(clkp);
>
> I should have checked Sashiko before I hit send on my last review.
> https://sashiko.dev/#/patchset/20260402073957.2742459-1-eleanor.lin%40realtek.com
>
> It suggested the following:
>
> In the Common Clock Framework, .set_rate executes under the prepare_lock
> mutex, while .enable and .disable execute under the enable_lock spinlock.
>
> Could an interleaved clk_pll_enable() corrupt the hardware state by running
> its seq_power_on sequence concurrently with these multi-step register
> updates?
>
> There also appears to be a potential race condition later in this function:
>
> if (is_power_on(clkp)) {
> ret = wait_freq_ready(clkp);
> ...
> }
>
> If .disable() powers off the PLL right before wait_freq_ready() is called,
> will wait_freq_ready() poll a disabled PLL and erroneously return
> -ETIMEDOUT? Is a private spinlock needed to serialize these operations?
>
> Brian
>
Agreed, I will add a private spinlock here.
Best Regards,
Yu-Chun
^ permalink raw reply
* [PATCH v2 0/2] cpufreq: spacemit: Add cpufreq support for K1 SoC
From: Shuwei Wu @ 2026-04-10 7:58 UTC (permalink / raw)
To: Rafael J. Wysocki, Viresh Kumar, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, Yixun Lan, Yixun Lan
Cc: linux-pm, linux-kernel, linux-riscv, spacemit, devicetree,
Shuwei Wu
This series enables dynamic voltage and frequency scaling (DVFS) for
the SpacemiT K1 SoC using the generic cpufreq-dt driver.
Tested on Banana Pi BPI-F3, the execution time scales as expected
across different CPU frequencies:
~ # echo userspace > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
~ # echo 1600000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
~ # time awk 'BEGIN{for(i=0;i<1000000;i++){}}'
real 0m 1.07s
user 0m 1.07s
sys 0m 0.00s
~ # echo 1228800 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
~ # time awk 'BEGIN{for(i=0;i<1000000;i++){}}'
real 0m 1.40s
user 0m 1.40s
sys 0m 0.00s
~ # echo 1000000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
~ # time awk 'BEGIN{for(i=0;i<1000000;i++){}}'
real 0m 1.72s
user 0m 1.72s
sys 0m 0.00s
~ # echo 819000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
~ # time awk 'BEGIN{for(i=0;i<1000000;i++){}}'
real 0m 2.10s
user 0m 2.10s
sys 0m 0.00s
~ # echo 614400 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
~ # time awk 'BEGIN{for(i=0;i<1000000;i++){}}'
real 0m 2.80s
user 0m 2.80s
sys 0m 0.00s
Signed-off-by: Shuwei Wu <shuwei.wu@mailbox.org>
---
Changes in v2:
- Move OPP tables to dedicated k1-opp.dtsi
- Enable OPP only on BPI-F3 with cpu-supply present
- Link to v1: https://lore.kernel.org/r/20260308-shadow-deps-v1-0-0ceb5c7c07eb@mailbox.org
---
Shuwei Wu (2):
cpufreq: dt-platdev: Add SpacemiT K1 SoC to the allowlist
riscv: dts: spacemit: Add cpu scaling for K1 SoC
arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts | 35 +++++++-
arch/riscv/boot/dts/spacemit/k1-opp.dtsi | 105 ++++++++++++++++++++++++
arch/riscv/boot/dts/spacemit/k1.dtsi | 8 ++
drivers/cpufreq/cpufreq-dt-platdev.c | 1 +
4 files changed, 148 insertions(+), 1 deletion(-)
---
base-commit: 5164e95565d3fd508ca8a95351323f5716dfb695
change-id: 20260307-shadow-deps-3582a78aa756
prerequisite-patch-id: 154bd4f720ce5065d58b988de8f273207b44572e
prerequisite-message-id: <20260206-spacemit-p1-v4-0-8f695d93811e@riscstar.com>
prerequisite-patch-id: 5da3e75b18291a5540d4f66d7a0600fb8975ef62
prerequisite-patch-id: bcf41917414ecef8cf743095d130f6004c32f6a5
prerequisite-patch-id: cfe3800f8c791ec4c63e070af9628e88e0fc31b9
prerequisite-message-id: <20260305-k1-clk-fix-v1-1-abca85d6e266@mailbox.org>
prerequisite-patch-id: 7c7fb9f87dba019ece4c97c45750349a7cd28f3a
Best regards,
--
Shuwei Wu <shuwei.wu@mailbox.org>
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: media: Add bindings for qcom,x1p42100-camss
From: Bryan O'Donoghue @ 2026-04-10 7:59 UTC (permalink / raw)
To: Wenmeng Liu, Robert Foss, Todor Tomov, Vladimir Zapolskiy,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio
Cc: linux-media, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260410-purwa_camss-v1-1-eedcf6d9d8ee@oss.qualcomm.com>
On 10/04/2026 05:25, Wenmeng Liu wrote:
> Add bindings for the Camera Subsystem for X1P42100.
>
> The X1P42100 platform provides:
> - 2 x CSIPHY
> - 3 x TPG
> - 3 x CSID
> - 2 x CSID Lite
> - 1 x IFE
> - 2 x IFE Lite
>
> Signed-off-by: Wenmeng Liu <wenmeng.liu@oss.qualcomm.com>
> ---
> .../bindings/media/qcom,x1p42100-camss.yaml | 424 +++++++++++++++++++++
> 1 file changed, 424 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/media/qcom,x1p42100-camss.yaml b/Documentation/devicetree/bindings/media/qcom,x1p42100-camss.yaml
> new file mode 100644
> index 0000000000000000000000000000000000000000..8bfa7e616c3b6b91adc8e21ebfbbe6fb579484f6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/qcom,x1p42100-camss.yaml
> @@ -0,0 +1,424 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/media/qcom,x1p42100-camss.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Qualcomm X1P42100 Camera Subsystem (CAMSS)
> +
> +maintainers:
> + - Wenmeng Liu <wenmeng.liu@oss.qualcomm.com>
> +
> +description:
> + The CAMSS IP is a CSI decoder and ISP present on Qualcomm platforms.
> +
> +properties:
> + compatible:
> + const: qcom,x1p42100-camss
> +
> + reg:
> + maxItems: 14
> +
> + reg-names:
> + items:
> + - const: csid0
> + - const: csid1
> + - const: csid2
> + - const: csid_lite0
> + - const: csid_lite1
> + - const: csid_wrapper
> + - const: csiphy0
> + - const: csiphy4
> + - const: csitpg0
> + - const: csitpg1
> + - const: csitpg2
> + - const: vfe0
> + - const: vfe_lite0
> + - const: vfe_lite1
> +
> + '#address-cells':
> + const: 2
> +
> + '#size-cells':
> + const: 2
> +
> + ranges: true
> +
> + clocks:
> + maxItems: 22
> +
> + clock-names:
> + items:
> + - const: camnoc_nrt_axi
> + - const: camnoc_rt_axi
> + - const: core_ahb
> + - const: cpas_ahb
> + - const: cpas_fast_ahb
> + - const: cpas_vfe0
> + - const: cpas_vfe_lite
> + - const: cphy_rx_clk_src
> + - const: csid
> + - const: csid_csiphy_rx
> + - const: csiphy0
> + - const: csiphy0_timer
> + - const: csiphy4
> + - const: csiphy4_timer
> + - const: gcc_axi_hf
> + - const: gcc_axi_sf
> + - const: vfe0
> + - const: vfe0_fast_ahb
> + - const: vfe_lite
> + - const: vfe_lite_ahb
> + - const: vfe_lite_cphy_rx
> + - const: vfe_lite_csid
> +
> + interrupts:
> + maxItems: 10
> +
> + interrupt-names:
> + items:
> + - const: csid0
> + - const: csid1
> + - const: csid2
> + - const: csid_lite0
> + - const: csid_lite1
> + - const: csiphy0
> + - const: csiphy4
> + - const: vfe0
> + - const: vfe_lite0
> + - const: vfe_lite1
> +
> + interconnects:
> + maxItems: 4
> +
> + interconnect-names:
> + items:
> + - const: ahb
> + - const: hf_mnoc
> + - const: sf_mnoc
> + - const: sf_icp_mnoc
> +
> + iommus:
> + oneOf:
> + - items:
> + - description: S1 HLOS IFE and IFE_LITE non-protected read
> + - description: S1 HLOS IFE and IFE_LITE non-protected write
> + - description: S1 HLOS SFE non-protected read
> + - description: S1 HLOS SFE non-protected write
> + - description: S1 HLOS CDM IFE non-protected
> + - description: Legacy slot 0 - do not use
> + - description: Legacy slot 1 - do not use
> + - description: Legacy slot 2 - do not use
> + - items:
> + - description: S1 HLOS IFE and IFE_LITE non-protected read
> + - description: S1 HLOS IFE and IFE_LITE non-protected write
> + - description: S1 HLOS SFE non-protected read
> + - description: S1 HLOS SFE non-protected write
> + - description: S1 HLOS CDM IFE non-protected
> +
> + power-domains:
> + items:
> + - description: IFE0 GDSC - Image Front End, Global Distributed Switch Controller.
> + - description: Titan Top GDSC - Titan ISP Block, Global Distributed Switch Controller.
> +
> + power-domain-names:
> + items:
> + - const: ife0
> + - const: top
> +
> + vdd-csiphy-0p8-supply:
> + description:
> + 0.8V supply to a PHY.
> +
> + vdd-csiphy-1p2-supply:
> + description:
> + 1.2V supply to a PHY.
> +
> + phys:
> + maxItems: 2
> +
> + phy-names:
> + items:
> + - const: csiphy0
> + - const: csiphy4
> +
> + ports:
> + $ref: /schemas/graph.yaml#/properties/ports
> +
> + description:
> + CSI input ports. Supports either standard single sensor mode or
> + Qualcomm's combo mode with one sensor in 2x1 + 1x1 data-lane, clock-lane mode.
> +
> + patternProperties:
> + "^port@[0-3]$":
> + $ref: /schemas/graph.yaml#/$defs/port-base
> + unevaluatedProperties: false
> +
> + description:
> + Input port for receiving CSI data.
> +
> + properties:
> + endpoint@0:
> + $ref: video-interfaces.yaml#
> + unevaluatedProperties: false
> +
> + description:
> + Endpoint for receiving a single sensor input (or first leg of combo).
> +
> + properties:
> + data-lanes:
> + minItems: 1
> + maxItems: 4 # Base max allows 4 (for D-PHY)
> +
> + clock-lanes:
> + maxItems: 1
> +
> + bus-type:
> + enum:
> + - 1 # MEDIA_BUS_TYPE_CSI2_CPHY
> + - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
> +
> + endpoint@1:
> + $ref: video-interfaces.yaml#
> + unevaluatedProperties: false
> +
> + description:
> + Endpoint for receiving the second leg of a combo sensor input.
> +
> + properties:
> + data-lanes:
> + maxItems: 1
> +
> + clock-lanes:
> + maxItems: 1
> +
> + bus-type:
> + const: 4 # Combo is D-PHY specific
> +
> + required:
> + - data-lanes
> +
> + allOf:
> + # Case 1: Combo Mode (endpoint@1 is present)
> + # If endpoint@1 exists, we restrict endpoint@0 to 2 lanes (D-PHY split)
> + - if:
> + required:
> + - endpoint@1
> + then:
> + properties:
> + endpoint@0:
> + properties:
> + data-lanes:
> + minItems: 2
> + maxItems: 2
> + bus-type:
> + const: 4
> + endpoint@1:
> + properties:
> + data-lanes:
> + minItems: 1
> + maxItems: 1
> + bus-type:
> + const: 4
> +
> + # Case 2: Single Mode (endpoint@1 is missing)
> + # We explicitly allow up to 4 lanes here to cover the D-PHY use case.
> + - if:
> + not:
> + required:
> + - endpoint@1
> + then:
> + properties:
> + endpoint@0:
> + properties:
> + data-lanes:
> + minItems: 1
> + maxItems: 4
> +
> +patternProperties:
> + "^phy@[0-9a-f]+$":
> + $ref: /schemas/phy/qcom,x1e80100-csi2-phy.yaml
> + unevaluatedProperties: false
> +
> + "^opp-table(-.*)?$":
> + type: object
> +
> +required:
> + - compatible
> + - reg
> + - reg-names
> + - clocks
> + - clock-names
> + - interrupts
> + - interrupt-names
> + - interconnects
> + - interconnect-names
> + - iommus
> + - power-domains
> + - power-domain-names
> + - ports
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> + #include <dt-bindings/clock/qcom,x1e80100-gcc.h>
> + #include <dt-bindings/clock/qcom,x1e80100-camcc.h>
> + #include <dt-bindings/interconnect/qcom,icc.h>
> + #include <dt-bindings/interconnect/qcom,x1e80100-rpmh.h>
> + #include <dt-bindings/phy/phy.h>
> + #include <dt-bindings/power/qcom-rpmpd.h>
> +
> + soc {
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + camss: isp@acb7000 {
> + compatible = "qcom,x1p42100-camss";
> +
> + reg = <0 0x0acb7000 0 0x2000>,
> + <0 0x0acb9000 0 0x2000>,
> + <0 0x0acbb000 0 0x2000>,
> + <0 0x0acc6000 0 0x1000>,
> + <0 0x0acca000 0 0x1000>,
> + <0 0x0acb6000 0 0x1000>,
> + <0 0x0ace4000 0 0x1000>,
> + <0 0x0acec000 0 0x4000>,
> + <0 0x0acf6000 0 0x1000>,
> + <0 0x0acf7000 0 0x1000>,
> + <0 0x0acf8000 0 0x1000>,
> + <0 0x0ac62000 0 0x4000>,
Is this the full extent of the VFE ? It looks like not to me.
For each register block please make sure you cover the _entire_ range of
the block not just the RDI part of it.
> + <0 0x0acc7000 0 0x2000>,
> + <0 0x0accb000 0 0x2000>;
> +
> + reg-names = "csid0",
> + "csid1",
> + "csid2",
> + "csid_lite0",
> + "csid_lite1",
> + "csid_wrapper",
> + "csiphy0",
> + "csiphy4",
> + "csitpg0",
> + "csitpg1",
> + "csitpg2",
> + "vfe0",
> + "vfe_lite0",
> + "vfe_lite1";
> +
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + clocks = <&camcc CAM_CC_CAMNOC_AXI_NRT_CLK>,
> + <&camcc CAM_CC_CAMNOC_AXI_RT_CLK>,
> + <&camcc CAM_CC_CORE_AHB_CLK>,
> + <&camcc CAM_CC_CPAS_AHB_CLK>,
> + <&camcc CAM_CC_CPAS_FAST_AHB_CLK>,
> + <&camcc CAM_CC_CPAS_IFE_0_CLK>,
> + <&camcc CAM_CC_CPAS_IFE_LITE_CLK>,
> + <&camcc CAM_CC_CPHY_RX_CLK_SRC>,
_SRC clocks are generally not necessary, is this one ?
> + <&camcc CAM_CC_CSID_CLK>,
> + <&camcc CAM_CC_CSID_CSIPHY_RX_CLK>,
> + <&camcc CAM_CC_CSIPHY0_CLK>,
> + <&camcc CAM_CC_CSI0PHYTIMER_CLK>,
> + <&camcc CAM_CC_CSIPHY4_CLK>,
> + <&camcc CAM_CC_CSI4PHYTIMER_CLK>,
> + <&gcc GCC_CAMERA_HF_AXI_CLK>,
> + <&gcc GCC_CAMERA_SF_AXI_CLK>,
> + <&camcc CAM_CC_IFE_0_CLK>,
> + <&camcc CAM_CC_IFE_0_FAST_AHB_CLK>,
> + <&camcc CAM_CC_IFE_LITE_CLK>,
> + <&camcc CAM_CC_IFE_LITE_AHB_CLK>,
> + <&camcc CAM_CC_IFE_LITE_CPHY_RX_CLK>,
> + <&camcc CAM_CC_IFE_LITE_CSID_CLK>;
> +
> + clock-names = "camnoc_nrt_axi",
> + "camnoc_rt_axi",
> + "core_ahb",
> + "cpas_ahb",
> + "cpas_fast_ahb",
> + "cpas_vfe0",
> + "cpas_vfe_lite",
> + "cphy_rx_clk_src",
> + "csid",
> + "csid_csiphy_rx",
> + "csiphy0",
> + "csiphy0_timer",
> + "csiphy4",
> + "csiphy4_timer",
> + "gcc_axi_hf",
> + "gcc_axi_sf",
> + "vfe0",
> + "vfe0_fast_ahb",
> + "vfe_lite",
> + "vfe_lite_ahb",
> + "vfe_lite_cphy_rx",
> + "vfe_lite_csid";
> +
> + interrupts = <GIC_SPI 464 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 466 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 431 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 468 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 359 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 477 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 122 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 465 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 469 IRQ_TYPE_EDGE_RISING>,
> + <GIC_SPI 360 IRQ_TYPE_EDGE_RISING>;
> +
> + interrupt-names = "csid0",
> + "csid1",
> + "csid2",
> + "csid_lite0",
> + "csid_lite1",
> + "csiphy0",
> + "csiphy4",
> + "vfe0",
> + "vfe_lite0",
> + "vfe_lite1";
> +
> + interconnects = <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
> + &config_noc SLAVE_CAMERA_CFG QCOM_ICC_TAG_ACTIVE_ONLY>,
> + <&mmss_noc MASTER_CAMNOC_HF QCOM_ICC_TAG_ALWAYS
> + &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
> + <&mmss_noc MASTER_CAMNOC_SF QCOM_ICC_TAG_ALWAYS
> + &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
> + <&mmss_noc MASTER_CAMNOC_ICP QCOM_ICC_TAG_ALWAYS
> + &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>;
> +
> + interconnect-names = "ahb",
> + "hf_mnoc",
> + "sf_mnoc",
> + "sf_icp_mnoc";
> +
> + iommus = <&apps_smmu 0x800 0x60>,
> + <&apps_smmu 0x820 0x60>,
> + <&apps_smmu 0x840 0x60>,
> + <&apps_smmu 0x860 0x60>,
> + <&apps_smmu 0x18a0 0x0>;
Please define which IOMMUs these are - I'd like to make sure the top
level node maps the IFE IOMMUs and not the ICP IOMMUs - as ICP should be
its own sub/separate node.
> +
> + power-domains = <&camcc CAM_CC_IFE_0_GDSC>,
> + <&camcc CAM_CC_TITAN_TOP_GDSC>;
> +
> + power-domain-names = "ife0",
> + "top";
> +
> + vdd-csiphy-0p8-supply = <&csiphy_0p8_supply>;
> + vdd-csiphy-1p2-supply = <&csiphy_1p2_supply>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + csiphy_ep0: endpoint {
> + data-lanes = <0 1>;
> + remote-endpoint = <&sensor_ep>;
> + };
> + };
> + };
> + };
> + };
>
^ permalink raw reply
* [PATCH v2 1/2] cpufreq: dt-platdev: Add SpacemiT K1 SoC to the allowlist
From: Shuwei Wu @ 2026-04-10 7:58 UTC (permalink / raw)
To: Rafael J. Wysocki, Viresh Kumar, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, Yixun Lan, Yixun Lan
Cc: linux-pm, linux-kernel, linux-riscv, spacemit, devicetree,
Shuwei Wu
In-Reply-To: <20260410-shadow-deps-v2-0-4e16b8c0f60e@mailbox.org>
The SpacemiT K1 SoC uses standard device tree based CPU frequency
scaling. Add it to the allowlist to instantiate the cpufreq-dt driver.
Signed-off-by: Shuwei Wu <shuwei.wu@mailbox.org>
---
drivers/cpufreq/cpufreq-dt-platdev.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq-dt-platdev.c
index 25fd3b191b7e..31a64739df25 100644
--- a/drivers/cpufreq/cpufreq-dt-platdev.c
+++ b/drivers/cpufreq/cpufreq-dt-platdev.c
@@ -81,6 +81,7 @@ static const struct of_device_id allowlist[] __initconst = {
{ .have_governor_per_policy = true, },
},
+ { .compatible = "spacemit,k1", },
{ .compatible = "st-ericsson,u8500", },
{ .compatible = "st-ericsson,u8540", },
{ .compatible = "st-ericsson,u9500", },
--
2.53.0
^ permalink raw reply related
* [PATCH v2 2/2] riscv: dts: spacemit: Add cpu scaling for K1 SoC
From: Shuwei Wu @ 2026-04-10 7:58 UTC (permalink / raw)
To: Rafael J. Wysocki, Viresh Kumar, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, Yixun Lan, Yixun Lan
Cc: linux-pm, linux-kernel, linux-riscv, spacemit, devicetree,
Shuwei Wu
In-Reply-To: <20260410-shadow-deps-v2-0-4e16b8c0f60e@mailbox.org>
Add Operating Performance Points (OPP) tables and CPU clock properties
for the two clusters in the SpacemiT K1 SoC.
Also assign the CPU power supply (cpu-supply) for the Banana Pi BPI-F3
board to fully enable CPU DVFS.
Signed-off-by: Shuwei Wu <shuwei.wu@mailbox.org>
---
Changes in v2:
- Add k1-opp.dtsi with OPP tables for both CPU clusters
- Assign CPU supplies and include OPP table for Banana Pi BPI-F3
---
arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts | 35 +++++++-
arch/riscv/boot/dts/spacemit/k1-opp.dtsi | 105 ++++++++++++++++++++++++
arch/riscv/boot/dts/spacemit/k1.dtsi | 8 ++
3 files changed, 147 insertions(+), 1 deletion(-)
diff --git a/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts b/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts
index 444c3b1e6f44..3780593f610d 100644
--- a/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts
+++ b/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts
@@ -5,6 +5,7 @@
#include "k1.dtsi"
#include "k1-pinctrl.dtsi"
+#include "k1-opp.dtsi"
/ {
model = "Banana Pi BPI-F3";
@@ -86,6 +87,38 @@ &combo_phy {
status = "okay";
};
+&cpu_0 {
+ cpu-supply = <&buck1_3v45>;
+};
+
+&cpu_1 {
+ cpu-supply = <&buck1_3v45>;
+};
+
+&cpu_2 {
+ cpu-supply = <&buck1_3v45>;
+};
+
+&cpu_3 {
+ cpu-supply = <&buck1_3v45>;
+};
+
+&cpu_4 {
+ cpu-supply = <&buck1_3v45>;
+};
+
+&cpu_5 {
+ cpu-supply = <&buck1_3v45>;
+};
+
+&cpu_6 {
+ cpu-supply = <&buck1_3v45>;
+};
+
+&cpu_7 {
+ cpu-supply = <&buck1_3v45>;
+};
+
&emmc {
bus-width = <8>;
mmc-hs400-1_8v;
@@ -201,7 +234,7 @@ pmic@41 {
dldoin2-supply = <&buck5>;
regulators {
- buck1 {
+ buck1_3v45: buck1 {
regulator-min-microvolt = <500000>;
regulator-max-microvolt = <3450000>;
regulator-ramp-delay = <5000>;
diff --git a/arch/riscv/boot/dts/spacemit/k1-opp.dtsi b/arch/riscv/boot/dts/spacemit/k1-opp.dtsi
new file mode 100644
index 000000000000..768ae390686d
--- /dev/null
+++ b/arch/riscv/boot/dts/spacemit/k1-opp.dtsi
@@ -0,0 +1,105 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+/ {
+ cluster0_opp_table: opp-table-cluster0 {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp-614400000 {
+ opp-hz = /bits/ 64 <614400000>;
+ opp-microvolt = <950000>;
+ clock-latency-ns = <200000>;
+ };
+
+ opp-819000000 {
+ opp-hz = /bits/ 64 <819000000>;
+ opp-microvolt = <950000>;
+ clock-latency-ns = <200000>;
+ };
+
+ opp-1000000000 {
+ opp-hz = /bits/ 64 <1000000000>;
+ opp-microvolt = <950000>;
+ clock-latency-ns = <200000>;
+ };
+
+ opp-1228800000 {
+ opp-hz = /bits/ 64 <1228800000>;
+ opp-microvolt = <950000>;
+ clock-latency-ns = <200000>;
+ };
+
+ opp-1600000000 {
+ opp-hz = /bits/ 64 <1600000000>;
+ opp-microvolt = <1050000>;
+ clock-latency-ns = <200000>;
+ };
+ };
+
+ cluster1_opp_table: opp-table-cluster1 {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp-614400000 {
+ opp-hz = /bits/ 64 <614400000>;
+ opp-microvolt = <950000>;
+ clock-latency-ns = <200000>;
+ };
+
+ opp-819000000 {
+ opp-hz = /bits/ 64 <819000000>;
+ opp-microvolt = <950000>;
+ clock-latency-ns = <200000>;
+ };
+
+ opp-1000000000 {
+ opp-hz = /bits/ 64 <1000000000>;
+ opp-microvolt = <950000>;
+ clock-latency-ns = <200000>;
+ };
+
+ opp-1228800000 {
+ opp-hz = /bits/ 64 <1228800000>;
+ opp-microvolt = <950000>;
+ clock-latency-ns = <200000>;
+ };
+
+ opp-1600000000 {
+ opp-hz = /bits/ 64 <1600000000>;
+ opp-microvolt = <1050000>;
+ clock-latency-ns = <200000>;
+ };
+ };
+};
+
+&cpu_0 {
+ operating-points-v2 = <&cluster0_opp_table>;
+};
+
+&cpu_1 {
+ operating-points-v2 = <&cluster0_opp_table>;
+};
+
+&cpu_2 {
+ operating-points-v2 = <&cluster0_opp_table>;
+};
+
+&cpu_3 {
+ operating-points-v2 = <&cluster0_opp_table>;
+};
+
+&cpu_4 {
+ operating-points-v2 = <&cluster1_opp_table>;
+};
+
+&cpu_5 {
+ operating-points-v2 = <&cluster1_opp_table>;
+};
+
+&cpu_6 {
+ operating-points-v2 = <&cluster1_opp_table>;
+};
+
+&cpu_7 {
+ operating-points-v2 = <&cluster1_opp_table>;
+};
diff --git a/arch/riscv/boot/dts/spacemit/k1.dtsi b/arch/riscv/boot/dts/spacemit/k1.dtsi
index 529ec68e9c23..bdd109b81730 100644
--- a/arch/riscv/boot/dts/spacemit/k1.dtsi
+++ b/arch/riscv/boot/dts/spacemit/k1.dtsi
@@ -54,6 +54,7 @@ cpu_0: cpu@0 {
compatible = "spacemit,x60", "riscv";
device_type = "cpu";
reg = <0>;
+ clocks = <&syscon_apmu CLK_CPU_C0_CORE>;
riscv,isa = "rv64imafdcbv_zicbom_zicbop_zicboz_zicntr_zicond_zicsr_zifencei_zihintpause_zihpm_zfh_zba_zbb_zbc_zbs_zkt_zvfh_zvkt_sscofpmf_sstc_svinval_svnapot_svpbmt";
riscv,isa-base = "rv64i";
riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "zicbom",
@@ -84,6 +85,7 @@ cpu_1: cpu@1 {
compatible = "spacemit,x60", "riscv";
device_type = "cpu";
reg = <1>;
+ clocks = <&syscon_apmu CLK_CPU_C0_CORE>;
riscv,isa = "rv64imafdcbv_zicbom_zicbop_zicboz_zicntr_zicond_zicsr_zifencei_zihintpause_zihpm_zfh_zba_zbb_zbc_zbs_zkt_zvfh_zvkt_sscofpmf_sstc_svinval_svnapot_svpbmt";
riscv,isa-base = "rv64i";
riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "zicbom",
@@ -114,6 +116,7 @@ cpu_2: cpu@2 {
compatible = "spacemit,x60", "riscv";
device_type = "cpu";
reg = <2>;
+ clocks = <&syscon_apmu CLK_CPU_C0_CORE>;
riscv,isa = "rv64imafdcbv_zicbom_zicbop_zicboz_zicntr_zicond_zicsr_zifencei_zihintpause_zihpm_zfh_zba_zbb_zbc_zbs_zkt_zvfh_zvkt_sscofpmf_sstc_svinval_svnapot_svpbmt";
riscv,isa-base = "rv64i";
riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "zicbom",
@@ -144,6 +147,7 @@ cpu_3: cpu@3 {
compatible = "spacemit,x60", "riscv";
device_type = "cpu";
reg = <3>;
+ clocks = <&syscon_apmu CLK_CPU_C0_CORE>;
riscv,isa = "rv64imafdcbv_zicbom_zicbop_zicboz_zicntr_zicond_zicsr_zifencei_zihintpause_zihpm_zfh_zba_zbb_zbc_zbs_zkt_zvfh_zvkt_sscofpmf_sstc_svinval_svnapot_svpbmt";
riscv,isa-base = "rv64i";
riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "zicbom",
@@ -174,6 +178,7 @@ cpu_4: cpu@4 {
compatible = "spacemit,x60", "riscv";
device_type = "cpu";
reg = <4>;
+ clocks = <&syscon_apmu CLK_CPU_C1_CORE>;
riscv,isa = "rv64imafdcbv_zicbom_zicbop_zicboz_zicntr_zicond_zicsr_zifencei_zihintpause_zihpm_zfh_zba_zbb_zbc_zbs_zkt_zvfh_zvkt_sscofpmf_sstc_svinval_svnapot_svpbmt";
riscv,isa-base = "rv64i";
riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "zicbom",
@@ -204,6 +209,7 @@ cpu_5: cpu@5 {
compatible = "spacemit,x60", "riscv";
device_type = "cpu";
reg = <5>;
+ clocks = <&syscon_apmu CLK_CPU_C1_CORE>;
riscv,isa = "rv64imafdcbv_zicbom_zicbop_zicboz_zicntr_zicond_zicsr_zifencei_zihintpause_zihpm_zfh_zba_zbb_zbc_zbs_zkt_zvfh_zvkt_sscofpmf_sstc_svinval_svnapot_svpbmt";
riscv,isa-base = "rv64i";
riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "zicbom",
@@ -234,6 +240,7 @@ cpu_6: cpu@6 {
compatible = "spacemit,x60", "riscv";
device_type = "cpu";
reg = <6>;
+ clocks = <&syscon_apmu CLK_CPU_C1_CORE>;
riscv,isa = "rv64imafdcbv_zicbom_zicbop_zicboz_zicntr_zicond_zicsr_zifencei_zihintpause_zihpm_zfh_zba_zbb_zbc_zbs_zkt_zvfh_zvkt_sscofpmf_sstc_svinval_svnapot_svpbmt";
riscv,isa-base = "rv64i";
riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "zicbom",
@@ -264,6 +271,7 @@ cpu_7: cpu@7 {
compatible = "spacemit,x60", "riscv";
device_type = "cpu";
reg = <7>;
+ clocks = <&syscon_apmu CLK_CPU_C1_CORE>;
riscv,isa = "rv64imafdcbv_zicbom_zicbop_zicboz_zicntr_zicond_zicsr_zifencei_zihintpause_zihpm_zfh_zba_zbb_zbc_zbs_zkt_zvfh_zvkt_sscofpmf_sstc_svinval_svnapot_svpbmt";
riscv,isa-base = "rv64i";
riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "zicbom",
--
2.53.0
^ permalink raw reply related
* Re: [PATCH 2/4] ASoC: dt-bindings: Add support for the GPIOs driven amplifier
From: Herve Codina @ 2026-04-10 8:03 UTC (permalink / raw)
To: Mark Brown
Cc: Rob Herring, Liam Girdwood, Krzysztof Kozlowski, Conor Dooley,
Saravana Kannan, Jaroslav Kysela, Takashi Iwai, linux-sound,
devicetree, linux-kernel, Christophe Leroy, Thomas Petazzoni
In-Reply-To: <383635c6-0417-4333-aa9c-9056437d4a5f@sirena.org.uk>
Hi Mark, Rob,
On Thu, 9 Apr 2026 16:26:25 +0100
Mark Brown <broonie@kernel.org> wrote:
> > > I didn't want to set a particular limit related to the number of GPIOs
> > > used for thje gain value. Of course 2^32 is obviously a lot.
>
> > > What do you think about 16 for maxItems?
>
> > What is the most you are aware of? Take that and double it.
>
> > Seems to me 256 levels would be way more than a human ear could distinguish.
>
> There's plenty of gain controls with way more than 256 bits of
> resolution, though I'm not aware of any that are configured via GPIO.
> The step size and absolute values you want can vary dramatically
> depending on application, possibly in the same system (eg, a DAC that
> can be connected to both headphones or speakers) so you often end up
> making practical adjustments in a small subset of the available range
> but that subset can vary a lot for the same part.
Mark, do you think that max 16 GPIOs could be an acceptable limit?
IMHO, this value is large enough to be used as the limit.
>
> > I guess my point was that really we could deprecate simple-amplifier
> > binding because this one can handle it and more. But I'm not
> > suggesting we do that yet.
>
> That's my thinking.
Fine for me to, at the end, deprecate the simple-amplifier.
^ permalink raw reply
* Re: [PATCH v2 2/4] dt-bindings: iio: magnetometer: Add binding for QST QMC5883P
From: Krzysztof Kozlowski @ 2026-04-10 8:06 UTC (permalink / raw)
To: Hardik Phalet
Cc: Greg Kroah-Hartman, Jonathan Cameron, David Lechner, Nuno Sá,
Andy Shevchenko, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Brigham Campbell, Shuah Khan, linux-iio, devicetree, linux-kernel,
linux-staging
In-Reply-To: <20260410-stimulating-happy-terrier-e82dcc@quoll>
On Fri, Apr 10, 2026 at 09:55:24AM +0200, Krzysztof Kozlowski wrote:
> On Thu, Apr 09, 2026 at 09:07:29PM +0000, Hardik Phalet wrote:
> > Add the device tree binding document for the QST QMC5883P, a 3-axis
> > anisotropic magneto-resistive (AMR) sensor with a 16-bit ADC that
> > communicates over I2C. The binding exposes the required 'compatible'
> > and 'reg' properties along with an optional 'vdd-supply' for the
> > 2.5 V–3.6 V VDD rail.
>
> Drop last sentence. We can read the diff.
>
> ...
>
> > +properties:
> > + compatible:
> > + const: qst,qmc5883p
> > +
> > + reg:
> > + maxItems: 1
> > + description: I2C address of the device; the default address is 0x2c.
> > +
> > + vdd-supply:
> > + description:
> > + VDD power supply (2.5 V to 3.6 V). Powers all internal analog and
> > + digital functional blocks.
>
> Supply should be required. Devices need them to operate.
Ah, and since I expect new version, also:
A nit, subject: drop second/last, redundant "binding for". The
"dt-bindings" prefix is already stating that these are bindings.
See also:
https://elixir.bootlin.com/linux/v6.17-rc3/source/Documentation/devicetree/bindings/submitting-patches.rst#L18
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: media: Add bindings for qcom,x1p42100-camss
From: Bryan O'Donoghue @ 2026-04-10 8:06 UTC (permalink / raw)
To: Wenmeng Liu, Robert Foss, Todor Tomov, Vladimir Zapolskiy,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio
Cc: linux-media, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260410-purwa_camss-v1-1-eedcf6d9d8ee@oss.qualcomm.com>
On 10/04/2026 05:25, Wenmeng Liu wrote:
> + vdd-csiphy-0p8-supply:
> + description:
> + 0.8V supply to a PHY.
> +
> + vdd-csiphy-1p2-supply:
> + description:
> + 1.2V supply to a PHY.
> +
> + phys:
> + maxItems: 2
> +
> + phy-names:
> + items:
> + - const: csiphy0
> + - const: csiphy4
> +
So if we still can't agree to get phys = in in the next kernel cycle,
then this scheme is acceptable but with the huge caveat that one
power-rail for each PHY is known to be wrong.
And I absolutely hate to continue to knowingly do the wrong thing...
---
bod
^ permalink raw reply
* Re: [PATCH v6 00/10] Add GPCDMA support in Tegra264
From: Jon Hunter @ 2026-04-10 8:09 UTC (permalink / raw)
To: Vinod Koul, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Thierry Reding, Laxman Dewangan, Philipp Zabel, dmaengine,
devicetree, linux-tegra, linux-kernel, Akhil R, Frank Li
In-Reply-To: <586052f6-d415-4603-accb-be15bad80db8@nvidia.com>
Hi Vinod,
On 31/03/2026 19:06, Jon Hunter wrote:
>
> On 31/03/2026 11:22, Akhil R wrote:
>> This series adds support for GPCDMA in Tegra264 with additional
>> support for separate stream ID for each channel. Tegra264 GPCDMA
>> controller has changes in the register offsets and uses 41-bit
>> addressing for memory. Add changes in the tegra186-gpc-dma driver
>> to support these.
>>
>> v5->v6:
>> - Replace dev_err() with dev_err_probe() in the probe function for fixed
>> return values also.
>> v4->v5:
>> - Use dev_err_probe() when returning error from the probe function.
>> - Remove tegra194 and tegra234 compatible from the reset 'if' condition
>> in the bindings as suggested in v2 (which I missed).
>> v3->v4:
>> - Split device tree changes to two patches.
>> - Reordered patches to have fixes first.
>> - Added fixes tag to dt-bindings and device tree changes.
>> v2->v3:
>> - Add description for iommu-map property and update commit descriptions.
>> - Use enum for compatible string instead of const.
>> - Remove unused registers from struct tegra_dma_channel_regs.
>> - Use devm_of_dma_controller_register() to register the DMA controller.
>> - Remove return value check for mask setting in the driver as the bitmask
>> value is always greater than 32.
>> v1->v2:
>> - Fix dt_bindings_check warnings
>> - Drop fallback compatible "nvidia,tegra186-gpcdma" from Tegra264 DT
>> - Use dma_addr_t for sg_req src/dst fields and drop separate high_add
>> variable and check for the addr_bits only when programming the
>> registers.
>> - Update address width to 39 bits for Tegra234 and before since the SMMU
>> supports only up to 39 bits till Tegra234.
>> - Add a patch to do managed DMA controller registration.
>> - Describe the second iteration in the probe.
>> - Update commit descriptions.
>>
>> Akhil R (10):
>> dt-bindings: dma: nvidia,tegra186-gpc-dma: Make reset optional
>> arm64: tegra: Remove fallback compatible for GPCDMA
>> dt-bindings: dma: nvidia,tegra186-gpc-dma: Add iommu-map property
>> dmaengine: tegra: Make reset control optional
>> dmaengine: tegra: Use struct for register offsets
>> dmaengine: tegra: Support address width > 39 bits
>> dmaengine: tegra: Use managed DMA controller registration
>> dmaengine: tegra: Use iommu-map for stream ID
>> dmaengine: tegra: Add Tegra264 support
>> arm64: tegra: Enable GPCDMA in Tegra264 and add iommu-map
>>
>> .../bindings/dma/nvidia,tegra186-gpc-dma.yaml | 32 +-
>> .../arm64/boot/dts/nvidia/tegra264-p3834.dtsi | 4 +
>> arch/arm64/boot/dts/nvidia/tegra264.dtsi | 3 +-
>> drivers/dma/tegra186-gpc-dma.c | 429 +++++++++++-------
>> 4 files changed, 284 insertions(+), 184 deletions(-)
>>
>
> For the series ...
>
> Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
I am not sure if it is too late to pick this up for v7.1, but we would
like to get this into -next if you are happy with it.
Thanks
Jon
--
nvpublic
^ permalink raw reply
* Re: [PATCH 4/4] arm64: dts: qcom: purwa-iot-evk: Add camss node
From: Bryan O'Donoghue @ 2026-04-10 8:16 UTC (permalink / raw)
To: Wenmeng Liu, Robert Foss, Todor Tomov, Vladimir Zapolskiy,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio
Cc: linux-media, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260410-purwa_camss-v1-4-eedcf6d9d8ee@oss.qualcomm.com>
On 10/04/2026 05:25, Wenmeng Liu wrote:
> nable camss node for purwa iot evk board camss tpg support.
>
> Signed-off-by: Wenmeng Liu<wenmeng.liu@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/purwa-iot-evk.dts | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/purwa-iot-evk.dts b/arch/arm64/boot/dts/qcom/purwa-iot-evk.dts
> index ad503beec1d3d8c671d3564942a74c484de762d0..eef03f1eb2a950c06294159be3f97169fb487265 100644
> --- a/arch/arm64/boot/dts/qcom/purwa-iot-evk.dts
> +++ b/arch/arm64/boot/dts/qcom/purwa-iot-evk.dts
> @@ -734,6 +734,10 @@ retimer_ss2_con_sbu_out: endpoint {
> };
> };
>
> +&camss {
> + status = "okay";
> +};
Hmm.
I don't agree with this. Enabling the CAMSS node with just the TPG is of
very low value to an end-user and doesn't "prove out" the CSIPHY, TPG
and RDI path - which is the minimum entry point in upstream right now.
I don't support less than a sensor at minimum.
You guys must have a sensor you've used with this board ?
---
bod
^ permalink raw reply
* [PATCH v2 0/2] IPA v5.2 support for Milos and Fairphone (Gen. 6)
From: Luca Weiss @ 2026-04-10 8:17 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: ~postmarketos/upstreaming, phone-devel, linux-arm-msm, devicetree,
linux-kernel, Luca Weiss, Konrad Dybcio, Dmitry Baryshkov
Add support for IPA v5.2 which can be found in the Milos SoC. And
finally enable it on Fairphone (Gen. 6) so that mobile data (4G/5G/..)
starts working.
Depends on:
* IPA v5.2 support
https://lore.kernel.org/linux-arm-msm/20260410-ipa-v5-2-v2-0-778422a05060@fairphone.com/T/
* Describe IMEM on Milos
https://lore.kernel.org/linux-arm-msm/20260410-milos-imem-v3-0-d215385fa5ab@fairphone.com/T/
I'd like to have specified these as b4 deps but somehow b4's behaving
quite weird with this series, adding many thousands of
prerequisite-patch-id, so I guess manually will need to be enough.
Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
---
Changes in v2:
- Split net patches into a separate series
- Pick up tags
- Link to v1: https://patch.msgid.link/20260403-milos-ipa-v1-0-01e9e4e03d3e@fairphone.com
---
Luca Weiss (2):
arm64: dts: qcom: milos: Add IPA node
arm64: dts: qcom: milos-fairphone-fp6: Enable IPA
arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts | 9 +++++
arch/arm64/boot/dts/qcom/milos.dtsi | 44 ++++++++++++++++++++++++
2 files changed, 53 insertions(+)
---
base-commit: 0190c2c6dae368aeb9bf59a449ebe23f24bfa059
change-id: 20260403-milos-ipa-e5705aa87245
Best regards,
--
Luca Weiss <luca.weiss@fairphone.com>
^ 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