* Re: [RFC PATCH 1/2] dt-bindings: pcie: Document QCOM PCIE ECAM compatible root complex
From: Krzysztof Kozlowski @ 2024-04-04 19:30 UTC (permalink / raw)
To: Mayank Rana, linux-pci, lpieralisi, kw, robh, bhelgaas, andersson,
manivannan.sadhasivam, krzysztof.kozlowski+dt, conor+dt,
devicetree
Cc: linux-arm-msm, quic_ramkri, quic_nkela, quic_shazhuss,
quic_msarkar, quic_nitegupt
In-Reply-To: <1712257884-23841-2-git-send-email-quic_mrana@quicinc.com>
On 04/04/2024 21:11, Mayank Rana wrote:
> On some of Qualcomm platform, firmware configures PCIe controller in RC
On which?
Your commit or binding must answer to all such questions.
> mode with static iATU window mappings of configuration space for entire
> supported bus range in ECAM compatible mode. Firmware also manages PCIe
> PHY as well required system resources. Here document properties and
> required configuration to power up QCOM PCIe ECAM compatible root complex
> and PHY for PCIe functionality.
>
> Signed-off-by: Mayank Rana <quic_mrana@quicinc.com>
> ---
> .../devicetree/bindings/pci/qcom,pcie-ecam.yaml | 94 ++++++++++++++++++++++
> 1 file changed, 94 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/pci/qcom,pcie-ecam.yaml
>
> diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie-ecam.yaml b/Documentation/devicetree/bindings/pci/qcom,pcie-ecam.yaml
> new file mode 100644
> index 00000000..c209f12
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pci/qcom,pcie-ecam.yaml
> @@ -0,0 +1,94 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/pci/qcom,pcie-ecam.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Qualcomm ECAM compliant PCI express root complex
> +
> +description: |
Do not need '|' unless you need to preserve formatting.
> + Qualcomm SOC based ECAM compatible PCIe root complex supporting MSI controller.
Which SoC?
> + Firmware configures PCIe controller in RC mode with static iATU window mappings
> + of configuration space for entire supported bus range in ECAM compatible mode.
> +
> +maintainers:
> + - Mayank Rana <quic_mrana@quicinc.com>
> +
> +allOf:
> + - $ref: /schemas/pci/pci-bus.yaml#
> + - $ref: /schemas/power-domain/power-domain-consumer.yaml
> +
> +properties:
> + compatible:
> + const: qcom,pcie-ecam-rc
No, this must have SoC specific compatibles.
> +
> + reg:
> + minItems: 1
maxItems instead
> + description: ECAM address space starting from root port till supported bus range
> +
> + interrupts:
> + minItems: 1
> + maxItems: 8
This is way too unspecific.
> +
> + ranges:
> + minItems: 2
> + maxItems: 3
Why variable?
> +
> + iommu-map:
> + minItems: 1
> + maxItems: 16
Why variable?
Open existing bindings and look how it is done.
> +
> + power-domains:
> + maxItems: 1
> + description: A phandle to node which is able support way to communicate with firmware
> + for enabling PCIe controller and PHY as well managing all system resources needed to
> + make both controller and PHY operational for PCIe functionality.
This description does not tell me much. Say something specific. And drop
redundant parts like phandle.
> +
> + dma-coherent: true
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - ranges
> + - power-domains
> + - device_type
> + - linux,pci-domain
> + - bus-range
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> + soc {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + pcie0: pci@1c00000 {
> + compatible = "qcom,pcie-ecam-rc";
> + reg = <0x4 0x00000000 0 0x10000000>;
> + device_type = "pci";
> + #address-cells = <3>;
> + #size-cells = <2>;
> + ranges = <0x01000000 0x0 0x40000000 0x0 0x40000000 0x0 0x100000>,
> + <0x02000000 0x0 0x40100000 0x0 0x40100000 0x0 0x1ff00000>,
> + <0x43000000 0x4 0x10100000 0x4 0x10100000 0x0 0x100000>;
Follow DTS coding style about placement and alignment.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v1 2/3] dt-bindings: arm: mediatek: mmsys: Add OF graph support for board path
From: kernel test robot @ 2024-04-04 19:21 UTC (permalink / raw)
To: AngeloGioacchino Del Regno, chunkuang.hu
Cc: oe-kbuild-all, robh, krzysztof.kozlowski+dt, conor+dt, p.zabel,
airlied, daniel, maarten.lankhorst, mripard, tzimmermann,
matthias.bgg, angelogioacchino.delregno, shawn.sung, yu-chang.lee,
ck.hu, jitao.shi, devicetree, linux-kernel, dri-devel,
linux-mediatek, linux-arm-kernel, wenst, kernel
In-Reply-To: <20240404081635.91412-3-angelogioacchino.delregno@collabora.com>
Hi AngeloGioacchino,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on robh/for-next pza/reset/next linus/master v6.9-rc2 next-20240404]
[cannot apply to pza/imx-drm/next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/AngeloGioacchino-Del-Regno/dt-bindings-display-mediatek-Add-OF-graph-support-for-board-path/20240404-161930
base: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
patch link: https://lore.kernel.org/r/20240404081635.91412-3-angelogioacchino.delregno%40collabora.com
patch subject: [PATCH v1 2/3] dt-bindings: arm: mediatek: mmsys: Add OF graph support for board path
compiler: loongarch64-linux-gcc (GCC) 13.2.0
reproduce: (https://download.01.org/0day-ci/archive/20240405/202404050315.7WBDW2E8-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202404050315.7WBDW2E8-lkp@intel.com/
dtcheck warnings: (new ones prefixed by >>)
>> Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml: properties:port:properties:required: ['endpoint@0'] is not of type 'object', 'boolean'
from schema $id: http://json-schema.org/draft-07/schema#
>> Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml: properties:port:properties: 'required' should not be valid under {'$ref': '#/definitions/json-schema-prop-names'}
hint: A json-schema keyword was found instead of a DT property name.
from schema $id: http://devicetree.org/meta-schemas/keywords.yaml#
>> Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml: properties:port:properties:required: ['endpoint@0'] is not of type 'object', 'boolean'
from schema $id: http://devicetree.org/meta-schemas/keywords.yaml#
--
>> Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml: ignoring, error in schema: properties: port: properties: required
Documentation/devicetree/bindings/net/snps,dwmac.yaml: mac-mode: missing type definition
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v3 08/29] mm: Define VM_SHADOW_STACK for RISC-V
From: Deepak Gupta @ 2024-04-04 19:21 UTC (permalink / raw)
To: David Hildenbrand
Cc: Mark Brown, paul.walmsley, rick.p.edgecombe, Szabolcs.Nagy,
kito.cheng, keescook, ajones, conor.dooley, cleger, atishp, alex,
bjorn, alexghiti, samuel.holland, conor, linux-doc, linux-riscv,
linux-kernel, devicetree, linux-mm, linux-arch, linux-kselftest,
corbet, palmer, aou, robh+dt, krzysztof.kozlowski+dt, oleg, akpm,
arnd, ebiederm, Liam.Howlett, vbabka, lstoakes, shuah, brauner,
andy.chiu, jerry.shih, hankuan.chen, greentime.hu, evan,
xiao.w.wang, charlie, apatel, mchitale, dbarboza, sameo,
shikemeng, willy, vincent.chen, guoren, samitolvanen,
songshuaishuai, gerg, heiko, bhe, jeeheng.sia, cyy, maskray,
ancientmodern4, mathis.salmen, cuiyunhui, bgray, mpe, baruch, alx,
catalin.marinas, revest, josh, shr, deller, omosnace, ojeda,
jhubbard
In-Reply-To: <604863a6-0387-4f29-9c4e-5ef86a8ca904@redhat.com>
On Thu, Apr 4, 2024 at 12:15 PM David Hildenbrand <david@redhat.com> wrote:
>
> On 04.04.24 21:04, Mark Brown wrote:
> > On Thu, Apr 04, 2024 at 08:58:06PM +0200, David Hildenbrand wrote:
> >
> >> or even introduce some ARCH_HAS_SHADOW_STACK so we can remove these
> >> arch-specific thingies here.
> >
> > It would be convenient if you could pull the ARCH_HAS_USER_SHADOW_STACK
> > patch out of my clone3 series to do that:
> >
> > https://lore.kernel.org/all/20240203-clone3-shadow-stack-v5-3-322c69598e4b@kernel.org/
>
> Crazy, I completely forgot about that one. Yes!
I missed that. Roger.
Will do that in the next series.
Thanks.
^ permalink raw reply
* Re: [PATCH v3 08/29] mm: Define VM_SHADOW_STACK for RISC-V
From: David Hildenbrand @ 2024-04-04 19:15 UTC (permalink / raw)
To: Mark Brown
Cc: Deepak Gupta, paul.walmsley, rick.p.edgecombe, Szabolcs.Nagy,
kito.cheng, keescook, ajones, conor.dooley, cleger, atishp, alex,
bjorn, alexghiti, samuel.holland, conor, linux-doc, linux-riscv,
linux-kernel, devicetree, linux-mm, linux-arch, linux-kselftest,
corbet, palmer, aou, robh+dt, krzysztof.kozlowski+dt, oleg, akpm,
arnd, ebiederm, Liam.Howlett, vbabka, lstoakes, shuah, brauner,
andy.chiu, jerry.shih, hankuan.chen, greentime.hu, evan,
xiao.w.wang, charlie, apatel, mchitale, dbarboza, sameo,
shikemeng, willy, vincent.chen, guoren, samitolvanen,
songshuaishuai, gerg, heiko, bhe, jeeheng.sia, cyy, maskray,
ancientmodern4, mathis.salmen, cuiyunhui, bgray, mpe, baruch, alx,
catalin.marinas, revest, josh, shr, deller, omosnace, ojeda,
jhubbard
In-Reply-To: <d3689521-58a7-47df-bd6a-0e2e60464491@sirena.org.uk>
On 04.04.24 21:04, Mark Brown wrote:
> On Thu, Apr 04, 2024 at 08:58:06PM +0200, David Hildenbrand wrote:
>
>> or even introduce some ARCH_HAS_SHADOW_STACK so we can remove these
>> arch-specific thingies here.
>
> It would be convenient if you could pull the ARCH_HAS_USER_SHADOW_STACK
> patch out of my clone3 series to do that:
>
> https://lore.kernel.org/all/20240203-clone3-shadow-stack-v5-3-322c69598e4b@kernel.org/
Crazy, I completely forgot about that one. Yes!
--
Cheers,
David / dhildenb
^ permalink raw reply
* [RFC PATCH 2/2] PCI: Add Qualcomm PCIe ECAM root complex driver
From: Mayank Rana @ 2024-04-04 19:11 UTC (permalink / raw)
To: linux-pci, lpieralisi, kw, robh, bhelgaas, andersson,
manivannan.sadhasivam, krzysztof.kozlowski+dt, conor+dt,
devicetree
Cc: linux-arm-msm, quic_ramkri, quic_nkela, quic_shazhuss,
quic_msarkar, quic_nitegupt, Mayank Rana
In-Reply-To: <1712257884-23841-1-git-send-email-quic_mrana@quicinc.com>
On some of Qualcomm platform, firmware configures PCIe controller into
ECAM mode allowing static memory allocation for configuration space of
supported bus range. Firmware also takes care of bringing up PCIe PHY
and performing required operation to bring PCIe link into D0. Firmware
also manages system resources (e.g. clocks/regulators/resets/ bus voting).
Hence add Qualcomm PCIe ECAM root complex driver which enumerates PCIe
root complex and connected PCIe devices. Firmware won't be enumerating
or powering up PCIe root complex until this driver invokes power domain
based notification to bring PCIe link into D0/D3cold mode.
This driver also support MSI functionality using PCIe controller based
MSI controller as GIC ITS based MSI functionality is not available on
some of platform.
Signed-off-by: Mayank Rana <quic_mrana@quicinc.com>
---
drivers/pci/controller/Kconfig | 12 +
drivers/pci/controller/Makefile | 1 +
drivers/pci/controller/pcie-qcom-ecam.c | 575 ++++++++++++++++++++++++++++++++
3 files changed, 588 insertions(+)
create mode 100644 drivers/pci/controller/pcie-qcom-ecam.c
diff --git a/drivers/pci/controller/Kconfig b/drivers/pci/controller/Kconfig
index e534c02..abbd9f2 100644
--- a/drivers/pci/controller/Kconfig
+++ b/drivers/pci/controller/Kconfig
@@ -353,6 +353,18 @@ config PCIE_XILINX_CPM
Say 'Y' here if you want kernel support for the
Xilinx Versal CPM host bridge.
+config PCIE_QCOM_ECAM
+ tristate "QCOM PCIe ECAM host controller"
+ depends on ARCH_QCOM && PCI
+ depends on OF
+ select PCI_MSI
+ select PCI_HOST_COMMON
+ select IRQ_DOMAIN
+ help
+ Say 'Y' here if you want to use ECAM shift mode compatible Qualcomm
+ PCIe root host controller. The controller is programmed using firmware
+ to support ECAM compatible memory address space.
+
source "drivers/pci/controller/cadence/Kconfig"
source "drivers/pci/controller/dwc/Kconfig"
source "drivers/pci/controller/mobiveil/Kconfig"
diff --git a/drivers/pci/controller/Makefile b/drivers/pci/controller/Makefile
index f2b19e6..2f1ee1e 100644
--- a/drivers/pci/controller/Makefile
+++ b/drivers/pci/controller/Makefile
@@ -40,6 +40,7 @@ obj-$(CONFIG_PCI_LOONGSON) += pci-loongson.o
obj-$(CONFIG_PCIE_HISI_ERR) += pcie-hisi-error.o
obj-$(CONFIG_PCIE_APPLE) += pcie-apple.o
obj-$(CONFIG_PCIE_MT7621) += pcie-mt7621.o
+obj-$(CONFIG_PCIE_QCOM_ECAM) += pcie-qcom-ecam.o
# pcie-hisi.o quirks are needed even without CONFIG_PCIE_DW
obj-y += dwc/
diff --git a/drivers/pci/controller/pcie-qcom-ecam.c b/drivers/pci/controller/pcie-qcom-ecam.c
new file mode 100644
index 00000000..5b4c68b
--- /dev/null
+++ b/drivers/pci/controller/pcie-qcom-ecam.c
@@ -0,0 +1,575 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Qualcomm PCIe ECAM root host controller driver
+ * Copyright (c) 2024 Qualcomm Innovation Center, Inc. All rights reserved.
+ */
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include <linux/irq.h>
+#include <linux/irqchip/chained_irq.h>
+#include <linux/irqdomain.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/msi.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+#include <linux/of_pci.h>
+#include <linux/pci.h>
+#include <linux/pci-ecam.h>
+#include <linux/platform_device.h>
+#include <linux/pm_domain.h>
+#include <linux/pm_runtime.h>
+#include <linux/slab.h>
+#include <linux/types.h>
+
+#define PCIE_MSI_CTRL_BASE (0x820)
+#define PCIE_MSI_CTRL_SIZE (0x68)
+#define PCIE_MSI_CTRL_ADDR_OFFS (0x0)
+#define PCIE_MSI_CTRL_UPPER_ADDR_OFFS (0x4)
+#define PCIE_MSI_CTRL_INT_N_EN_OFFS(n) (0x8 + 0xc * (n))
+#define PCIE_MSI_CTRL_INT_N_MASK_OFFS(n) (0xc + 0xc * (n))
+#define PCIE_MSI_CTRL_INT_N_STATUS_OFFS(n) (0x10 + 0xc * (n))
+
+#define MSI_DB_ADDR 0xa0000000
+#define MSI_IRQ_PER_GRP (32)
+
+/**
+ * struct qcom_msi_irq - MSI IRQ information
+ * @client: pointer to MSI client struct
+ * @grp: group the irq belongs to
+ * @grp_index: index in group
+ * @hwirq: hwirq number
+ * @virq: virq number
+ * @pos: position in MSI bitmap
+ */
+struct qcom_msi_irq {
+ struct qcom_msi_client *client;
+ struct qcom_msi_grp *grp;
+ unsigned int grp_index;
+ unsigned int hwirq;
+ unsigned int virq;
+ u32 pos;
+};
+
+/**
+ * struct qcom_msi_grp - MSI group information
+ * @int_en_reg: memory-mapped interrupt enable register address
+ * @int_mask_reg: memory-mapped interrupt mask register address
+ * @int_status_reg: memory-mapped interrupt status register address
+ * @mask: tracks masked/unmasked MSI
+ * @irqs: structure to MSI IRQ information
+ */
+struct qcom_msi_grp {
+ void __iomem *int_en_reg;
+ void __iomem *int_mask_reg;
+ void __iomem *int_status_reg;
+ u32 mask;
+ struct qcom_msi_irq irqs[MSI_IRQ_PER_GRP];
+};
+
+/**
+ * struct qcom_msi - PCIe controller based MSI controller information
+ * @clients: list for tracking clients
+ * @dev: platform device node
+ * @nr_hwirqs: total number of hardware IRQs
+ * @nr_virqs: total number of virqs
+ * @nr_grps: total number of groups
+ * @grps: pointer to all groups information
+ * @bitmap: tracks used/unused MSI
+ * @mutex: for modifying MSI client list and bitmap
+ * @inner_domain: parent domain; gen irq related
+ * @msi_domain: child domain; pcie related
+ * @msi_db_addr: MSI doorbell address
+ * @cfg_lock: lock for configuring MSI controller registers
+ * @pcie_msi_cfg: memory-mapped MSI controller register space
+ */
+struct qcom_msi {
+ struct list_head clients;
+ struct device *dev;
+ int nr_hwirqs;
+ int nr_virqs;
+ int nr_grps;
+ struct qcom_msi_grp *grps;
+ unsigned long *bitmap;
+ struct mutex mutex;
+ struct irq_domain *inner_domain;
+ struct irq_domain *msi_domain;
+ phys_addr_t msi_db_addr;
+ spinlock_t cfg_lock;
+ void __iomem *pcie_msi_cfg;
+};
+
+/**
+ * struct qcom_msi_client - structure for each client of MSI controller
+ * @node: list to track number of MSI clients
+ * @msi: client specific MSI controller based resource pointer
+ * @dev: client's dev of pci_dev
+ * @nr_irqs: number of irqs allocated for client
+ * @msi_addr: MSI doorbell address
+ */
+struct qcom_msi_client {
+ struct list_head node;
+ struct qcom_msi *msi;
+ struct device *dev;
+ unsigned int nr_irqs;
+ phys_addr_t msi_addr;
+};
+
+static void qcom_msi_handler(struct irq_desc *desc)
+{
+ struct irq_chip *chip = irq_desc_get_chip(desc);
+ struct qcom_msi_grp *msi_grp;
+ u32 status;
+ int i;
+
+ chained_irq_enter(chip, desc);
+
+ msi_grp = irq_desc_get_handler_data(desc);
+ status = readl_relaxed(msi_grp->int_status_reg);
+ status ^= (msi_grp->mask & status);
+ writel(status, msi_grp->int_status_reg);
+
+ for (i = 0; status; i++, status >>= 1)
+ if (status & 0x1)
+ generic_handle_irq(msi_grp->irqs[i].virq);
+
+ chained_irq_exit(chip, desc);
+}
+
+static void qcom_msi_mask_irq(struct irq_data *data)
+{
+ struct irq_data *parent_data;
+ struct qcom_msi_irq *msi_irq;
+ struct qcom_msi_grp *msi_grp;
+ struct qcom_msi *msi;
+ unsigned long flags;
+
+ parent_data = data->parent_data;
+ if (!parent_data)
+ return;
+
+ msi_irq = irq_data_get_irq_chip_data(parent_data);
+ msi = msi_irq->client->msi;
+ msi_grp = msi_irq->grp;
+
+ spin_lock_irqsave(&msi->cfg_lock, flags);
+ pci_msi_mask_irq(data);
+ msi_grp->mask |= BIT(msi_irq->grp_index);
+ writel(msi_grp->mask, msi_grp->int_mask_reg);
+ spin_unlock_irqrestore(&msi->cfg_lock, flags);
+}
+
+static void qcom_msi_unmask_irq(struct irq_data *data)
+{
+ struct irq_data *parent_data;
+ struct qcom_msi_irq *msi_irq;
+ struct qcom_msi_grp *msi_grp;
+ struct qcom_msi *msi;
+ unsigned long flags;
+
+ parent_data = data->parent_data;
+ if (!parent_data)
+ return;
+
+ msi_irq = irq_data_get_irq_chip_data(parent_data);
+ msi = msi_irq->client->msi;
+ msi_grp = msi_irq->grp;
+
+ spin_lock_irqsave(&msi->cfg_lock, flags);
+ msi_grp->mask &= ~BIT(msi_irq->grp_index);
+ writel(msi_grp->mask, msi_grp->int_mask_reg);
+ pci_msi_unmask_irq(data);
+ spin_unlock_irqrestore(&msi->cfg_lock, flags);
+}
+
+static struct irq_chip qcom_msi_irq_chip = {
+ .name = "qcom_pci_msi",
+ .irq_enable = qcom_msi_unmask_irq,
+ .irq_disable = qcom_msi_mask_irq,
+ .irq_mask = qcom_msi_mask_irq,
+ .irq_unmask = qcom_msi_unmask_irq,
+};
+
+static int qcom_msi_domain_prepare(struct irq_domain *domain, struct device *dev,
+ int nvec, msi_alloc_info_t *arg)
+{
+ struct qcom_msi *msi = domain->parent->host_data;
+ struct qcom_msi_client *client;
+
+ client = kzalloc(sizeof(*client), GFP_KERNEL);
+ if (!client)
+ return -ENOMEM;
+
+ client->msi = msi;
+ client->dev = dev;
+ client->msi_addr = msi->msi_db_addr;
+ mutex_lock(&msi->mutex);
+ list_add_tail(&client->node, &msi->clients);
+ mutex_unlock(&msi->mutex);
+
+ /* zero out struct for pcie msi framework */
+ memset(arg, 0, sizeof(*arg));
+ return 0;
+}
+
+static struct msi_domain_ops qcom_msi_domain_ops = {
+ .msi_prepare = qcom_msi_domain_prepare,
+};
+
+static struct msi_domain_info qcom_msi_domain_info = {
+ .flags = (MSI_FLAG_USE_DEF_DOM_OPS | MSI_FLAG_USE_DEF_CHIP_OPS |
+ MSI_FLAG_MULTI_PCI_MSI | MSI_FLAG_PCI_MSIX),
+ .ops = &qcom_msi_domain_ops,
+ .chip = &qcom_msi_irq_chip,
+};
+
+static int qcom_msi_irq_set_affinity(struct irq_data *data,
+ const struct cpumask *mask, bool force)
+{
+ struct irq_data *parent_data = irq_get_irq_data(irqd_to_hwirq(data));
+ int ret = 0;
+
+ if (!parent_data)
+ return -ENODEV;
+
+ /* set affinity for MSI HW IRQ */
+ if (parent_data->chip->irq_set_affinity)
+ ret = parent_data->chip->irq_set_affinity(parent_data, mask, force);
+
+ return ret;
+}
+
+static void qcom_msi_irq_compose_msi_msg(struct irq_data *data, struct msi_msg *msg)
+{
+ struct irq_data *parent_data = irq_get_irq_data(irqd_to_hwirq(data));
+ struct qcom_msi_irq *msi_irq = irq_data_get_irq_chip_data(data);
+ struct qcom_msi_client *client = msi_irq->client;
+
+ if (!parent_data)
+ return;
+
+ msg->address_lo = lower_32_bits(client->msi_addr);
+ msg->address_hi = upper_32_bits(client->msi_addr);
+ msg->data = msi_irq->pos;
+}
+
+static struct irq_chip qcom_msi_bottom_irq_chip = {
+ .name = "qcom_msi",
+ .irq_set_affinity = qcom_msi_irq_set_affinity,
+ .irq_compose_msi_msg = qcom_msi_irq_compose_msi_msg,
+};
+
+static int qcom_msi_irq_domain_alloc(struct irq_domain *domain, unsigned int virq,
+ unsigned int nr_irqs, void *args)
+{
+ struct device *dev = ((msi_alloc_info_t *)args)->desc->dev;
+ struct qcom_msi_client *tmp, *client = NULL;
+ struct qcom_msi *msi = domain->host_data;
+ int i, ret = 0;
+ int pos;
+
+ mutex_lock(&msi->mutex);
+ list_for_each_entry(tmp, &msi->clients, node) {
+ if (tmp->dev == dev) {
+ client = tmp;
+ break;
+ }
+ }
+
+ if (!client) {
+ dev_err(msi->dev, "failed to find MSI client dev\n");
+ ret = -ENODEV;
+ goto out;
+ }
+
+ pos = bitmap_find_next_zero_area(msi->bitmap, msi->nr_virqs, 0,
+ nr_irqs, nr_irqs - 1);
+ if (pos > msi->nr_virqs) {
+ ret = -ENOSPC;
+ goto out;
+ }
+
+ bitmap_set(msi->bitmap, pos, nr_irqs);
+ for (i = 0; i < nr_irqs; i++) {
+ u32 grp = pos / MSI_IRQ_PER_GRP;
+ u32 index = pos % MSI_IRQ_PER_GRP;
+ struct qcom_msi_irq *msi_irq = &msi->grps[grp].irqs[index];
+
+ msi_irq->virq = virq + i;
+ msi_irq->client = client;
+ irq_domain_set_info(domain, msi_irq->virq,
+ msi_irq->hwirq,
+ &qcom_msi_bottom_irq_chip, msi_irq,
+ handle_simple_irq, NULL, NULL);
+ client->nr_irqs++;
+ pos++;
+ }
+out:
+ mutex_unlock(&msi->mutex);
+ return ret;
+}
+
+static void qcom_msi_irq_domain_free(struct irq_domain *domain, unsigned int virq,
+ unsigned int nr_irqs)
+{
+ struct irq_data *data = irq_domain_get_irq_data(domain, virq);
+ struct qcom_msi_client *client;
+ struct qcom_msi_irq *msi_irq;
+ struct qcom_msi *msi;
+
+ if (!data)
+ return;
+
+ msi_irq = irq_data_get_irq_chip_data(data);
+ client = msi_irq->client;
+ msi = client->msi;
+
+ mutex_lock(&msi->mutex);
+ bitmap_clear(msi->bitmap, msi_irq->pos, nr_irqs);
+
+ client->nr_irqs -= nr_irqs;
+ if (!client->nr_irqs) {
+ list_del(&client->node);
+ kfree(client);
+ }
+ mutex_unlock(&msi->mutex);
+
+ irq_domain_free_irqs_parent(domain, virq, nr_irqs);
+}
+
+static const struct irq_domain_ops msi_domain_ops = {
+ .alloc = qcom_msi_irq_domain_alloc,
+ .free = qcom_msi_irq_domain_free,
+};
+
+static int qcom_msi_alloc_domains(struct qcom_msi *msi)
+{
+ msi->inner_domain = irq_domain_add_linear(NULL, msi->nr_virqs,
+ &msi_domain_ops, msi);
+ if (!msi->inner_domain) {
+ dev_err(msi->dev, "failed to create IRQ inner domain\n");
+ return -ENOMEM;
+ }
+
+ msi->msi_domain = pci_msi_create_irq_domain(of_node_to_fwnode(msi->dev->of_node),
+ &qcom_msi_domain_info, msi->inner_domain);
+ if (!msi->msi_domain) {
+ dev_err(msi->dev, "failed to create MSI domain\n");
+ irq_domain_remove(msi->inner_domain);
+ return -ENOMEM;
+ }
+
+ return 0;
+}
+
+static int qcom_msi_irq_setup(struct qcom_msi *msi)
+{
+ struct qcom_msi_grp *msi_grp;
+ struct qcom_msi_irq *msi_irq;
+ int i, index, ret;
+ unsigned int irq;
+
+ /* setup each MSI group. nr_hwirqs == nr_grps */
+ for (i = 0; i < msi->nr_hwirqs; i++) {
+ irq = irq_of_parse_and_map(msi->dev->of_node, i);
+ if (!irq) {
+ dev_err(msi->dev,
+ "MSI: failed to parse/map interrupt\n");
+ ret = -ENODEV;
+ goto free_irqs;
+ }
+
+ msi_grp = &msi->grps[i];
+ msi_grp->int_en_reg = msi->pcie_msi_cfg +
+ PCIE_MSI_CTRL_INT_N_EN_OFFS(i);
+ msi_grp->int_mask_reg = msi->pcie_msi_cfg +
+ PCIE_MSI_CTRL_INT_N_MASK_OFFS(i);
+ msi_grp->int_status_reg = msi->pcie_msi_cfg +
+ PCIE_MSI_CTRL_INT_N_STATUS_OFFS(i);
+
+ for (index = 0; index < MSI_IRQ_PER_GRP; index++) {
+ msi_irq = &msi_grp->irqs[index];
+
+ msi_irq->grp = msi_grp;
+ msi_irq->grp_index = index;
+ msi_irq->pos = (i * MSI_IRQ_PER_GRP) + index;
+ msi_irq->hwirq = irq;
+ }
+
+ irq_set_chained_handler_and_data(irq, qcom_msi_handler, msi_grp);
+ }
+
+ return 0;
+
+free_irqs:
+ for (--i; i >= 0; i--) {
+ irq = msi->grps[i].irqs[0].hwirq;
+
+ irq_set_chained_handler_and_data(irq, NULL, NULL);
+ irq_dispose_mapping(irq);
+ }
+
+ return ret;
+}
+
+static void qcom_msi_config(struct irq_domain *domain)
+{
+ struct qcom_msi *msi;
+ int i;
+
+ msi = domain->parent->host_data;
+
+ /* program termination address */
+ writel(msi->msi_db_addr, msi->pcie_msi_cfg + PCIE_MSI_CTRL_ADDR_OFFS);
+ writel(0, msi->pcie_msi_cfg + PCIE_MSI_CTRL_UPPER_ADDR_OFFS);
+
+ /* restore mask and enable all interrupts for each group */
+ for (i = 0; i < msi->nr_grps; i++) {
+ struct qcom_msi_grp *msi_grp = &msi->grps[i];
+
+ writel(msi_grp->mask, msi_grp->int_mask_reg);
+ writel(~0, msi_grp->int_en_reg);
+ }
+}
+
+static void qcom_msi_deinit(struct qcom_msi *msi)
+{
+ irq_domain_remove(msi->msi_domain);
+ irq_domain_remove(msi->inner_domain);
+}
+
+static struct qcom_msi *qcom_msi_init(struct device *dev)
+{
+ struct qcom_msi *msi;
+ u64 addr;
+ int ret;
+
+ msi = devm_kzalloc(dev, sizeof(*msi), GFP_KERNEL);
+ if (!msi)
+ return ERR_PTR(-ENOMEM);
+
+ msi->dev = dev;
+ mutex_init(&msi->mutex);
+ spin_lock_init(&msi->cfg_lock);
+ INIT_LIST_HEAD(&msi->clients);
+
+ msi->msi_db_addr = MSI_DB_ADDR;
+ msi->nr_hwirqs = of_irq_count(dev->of_node);
+ if (!msi->nr_hwirqs) {
+ dev_err(msi->dev, "no hwirqs found\n");
+ return ERR_PTR(-ENODEV);
+ }
+
+ if (of_property_read_reg(dev->of_node, 0, &addr, NULL) < 0) {
+ dev_err(msi->dev, "failed to get reg address\n");
+ return ERR_PTR(-ENODEV);
+ }
+
+ dev_dbg(msi->dev, "hwirq:%d pcie_msi_cfg:%llx\n", msi->nr_hwirqs, addr);
+ msi->pcie_msi_cfg = devm_ioremap(dev, addr + PCIE_MSI_CTRL_BASE, PCIE_MSI_CTRL_SIZE);
+ if (!msi->pcie_msi_cfg)
+ return ERR_PTR(-ENOMEM);
+
+ msi->nr_virqs = msi->nr_hwirqs * MSI_IRQ_PER_GRP;
+ msi->nr_grps = msi->nr_hwirqs;
+ msi->grps = devm_kcalloc(dev, msi->nr_grps, sizeof(*msi->grps), GFP_KERNEL);
+ if (!msi->grps)
+ return ERR_PTR(-ENOMEM);
+
+ msi->bitmap = devm_kcalloc(dev, BITS_TO_LONGS(msi->nr_virqs),
+ sizeof(*msi->bitmap), GFP_KERNEL);
+ if (!msi->bitmap)
+ return ERR_PTR(-ENOMEM);
+
+ ret = qcom_msi_alloc_domains(msi);
+ if (ret)
+ return ERR_PTR(ret);
+
+ ret = qcom_msi_irq_setup(msi);
+ if (ret) {
+ qcom_msi_deinit(msi);
+ return ERR_PTR(ret);
+ }
+
+ qcom_msi_config(msi->msi_domain);
+ return msi;
+}
+
+static int qcom_pcie_ecam_suspend_noirq(struct device *dev)
+{
+ return pm_runtime_put_sync(dev);
+}
+
+static int qcom_pcie_ecam_resume_noirq(struct device *dev)
+{
+ return pm_runtime_get_sync(dev);
+}
+
+static int qcom_pcie_ecam_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct qcom_msi *msi;
+ int ret;
+
+ ret = devm_pm_runtime_enable(dev);
+ if (ret)
+ return ret;
+
+ ret = pm_runtime_resume_and_get(dev);
+ if (ret < 0) {
+ dev_err(dev, "fail to enable pcie controller: %d\n", ret);
+ return ret;
+ }
+
+ msi = qcom_msi_init(dev);
+ if (IS_ERR(msi)) {
+ pm_runtime_put_sync(dev);
+ return PTR_ERR(msi);
+ }
+
+ ret = pci_host_common_probe(pdev);
+ if (ret) {
+ dev_err(dev, "pci_host_common_probe() failed:%d\n", ret);
+ qcom_msi_deinit(msi);
+ pm_runtime_put_sync(dev);
+ }
+
+ return ret;
+}
+
+static const struct dev_pm_ops qcom_pcie_ecam_pm_ops = {
+ NOIRQ_SYSTEM_SLEEP_PM_OPS(qcom_pcie_ecam_suspend_noirq,
+ qcom_pcie_ecam_resume_noirq)
+};
+
+static const struct pci_ecam_ops qcom_pcie_ecam_ops = {
+ .pci_ops = {
+ .map_bus = pci_ecam_map_bus,
+ .read = pci_generic_config_read,
+ .write = pci_generic_config_write,
+ }
+};
+
+static const struct of_device_id qcom_pcie_ecam_of_match[] = {
+ {
+ .compatible = "qcom,pcie-ecam-rc",
+ .data = &qcom_pcie_ecam_ops,
+ },
+ { },
+};
+MODULE_DEVICE_TABLE(of, qcom_pcie_ecam_of_match);
+
+static struct platform_driver qcom_pcie_ecam_driver = {
+ .probe = qcom_pcie_ecam_probe,
+ .driver = {
+ .name = "qcom-pcie-ecam-rc",
+ .suppress_bind_attrs = true,
+ .of_match_table = qcom_pcie_ecam_of_match,
+ .probe_type = PROBE_PREFER_ASYNCHRONOUS,
+ .pm = &qcom_pcie_ecam_pm_ops,
+ },
+};
+module_platform_driver(qcom_pcie_ecam_driver);
+
+MODULE_DESCRIPTION("Qualcomm PCIe ECAM root complex driver");
+MODULE_LICENSE("GPL");
--
2.7.4
^ permalink raw reply related
* [RFC PATCH 0/2] Add Qualcomm PCIe ECAM root complex driver
From: Mayank Rana @ 2024-04-04 19:11 UTC (permalink / raw)
To: linux-pci, lpieralisi, kw, robh, bhelgaas, andersson,
manivannan.sadhasivam, krzysztof.kozlowski+dt, conor+dt,
devicetree
Cc: linux-arm-msm, quic_ramkri, quic_nkela, quic_shazhuss,
quic_msarkar, quic_nitegupt, Mayank Rana
On some of Qualcomm platform, firmware takes care of system resources
related to PCIe PHY and controller as well bringing up PCIe link and
having static iATU configuration for PCIe controller to work into
ECAM compliant mode. Hence add Qualcomm PCIe ECAM root complex driver.
Tested:
- Validated NVME functionality with PCIe0 and PCIe1 on SA877p-ride platform
Mayank Rana (2):
dt-bindings: pcie: Document QCOM PCIE ECAM compatible root complex
PCI: Add Qualcomm PCIe ECAM root complex driver
.../devicetree/bindings/pci/qcom,pcie-ecam.yaml | 94 ++++
drivers/pci/controller/Kconfig | 12 +
drivers/pci/controller/Makefile | 1 +
drivers/pci/controller/pcie-qcom-ecam.c | 575 +++++++++++++++++++++
4 files changed, 682 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pci/qcom,pcie-ecam.yaml
create mode 100644 drivers/pci/controller/pcie-qcom-ecam.c
--
2.7.4
^ permalink raw reply
* [RFC PATCH 1/2] dt-bindings: pcie: Document QCOM PCIE ECAM compatible root complex
From: Mayank Rana @ 2024-04-04 19:11 UTC (permalink / raw)
To: linux-pci, lpieralisi, kw, robh, bhelgaas, andersson,
manivannan.sadhasivam, krzysztof.kozlowski+dt, conor+dt,
devicetree
Cc: linux-arm-msm, quic_ramkri, quic_nkela, quic_shazhuss,
quic_msarkar, quic_nitegupt, Mayank Rana
In-Reply-To: <1712257884-23841-1-git-send-email-quic_mrana@quicinc.com>
On some of Qualcomm platform, firmware configures PCIe controller in RC
mode with static iATU window mappings of configuration space for entire
supported bus range in ECAM compatible mode. Firmware also manages PCIe
PHY as well required system resources. Here document properties and
required configuration to power up QCOM PCIe ECAM compatible root complex
and PHY for PCIe functionality.
Signed-off-by: Mayank Rana <quic_mrana@quicinc.com>
---
.../devicetree/bindings/pci/qcom,pcie-ecam.yaml | 94 ++++++++++++++++++++++
1 file changed, 94 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pci/qcom,pcie-ecam.yaml
diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie-ecam.yaml b/Documentation/devicetree/bindings/pci/qcom,pcie-ecam.yaml
new file mode 100644
index 00000000..c209f12
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/qcom,pcie-ecam.yaml
@@ -0,0 +1,94 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/qcom,pcie-ecam.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm ECAM compliant PCI express root complex
+
+description: |
+ Qualcomm SOC based ECAM compatible PCIe root complex supporting MSI controller.
+ Firmware configures PCIe controller in RC mode with static iATU window mappings
+ of configuration space for entire supported bus range in ECAM compatible mode.
+
+maintainers:
+ - Mayank Rana <quic_mrana@quicinc.com>
+
+allOf:
+ - $ref: /schemas/pci/pci-bus.yaml#
+ - $ref: /schemas/power-domain/power-domain-consumer.yaml
+
+properties:
+ compatible:
+ const: qcom,pcie-ecam-rc
+
+ reg:
+ minItems: 1
+ description: ECAM address space starting from root port till supported bus range
+
+ interrupts:
+ minItems: 1
+ maxItems: 8
+
+ ranges:
+ minItems: 2
+ maxItems: 3
+
+ iommu-map:
+ minItems: 1
+ maxItems: 16
+
+ power-domains:
+ maxItems: 1
+ description: A phandle to node which is able support way to communicate with firmware
+ for enabling PCIe controller and PHY as well managing all system resources needed to
+ make both controller and PHY operational for PCIe functionality.
+
+ dma-coherent: true
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - ranges
+ - power-domains
+ - device_type
+ - linux,pci-domain
+ - bus-range
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ pcie0: pci@1c00000 {
+ compatible = "qcom,pcie-ecam-rc";
+ reg = <0x4 0x00000000 0 0x10000000>;
+ device_type = "pci";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges = <0x01000000 0x0 0x40000000 0x0 0x40000000 0x0 0x100000>,
+ <0x02000000 0x0 0x40100000 0x0 0x40100000 0x0 0x1ff00000>,
+ <0x43000000 0x4 0x10100000 0x4 0x10100000 0x0 0x100000>;
+ bus-range = <0x00 0xff>;
+ dma-coherent;
+ linux,pci-domain = <0>;
+ power-domains = <&scmi5_pd 0>;
+ power-domain-names = "power";
+ iommu-map = <0x0 &pcie_smmu 0x0000 0x1>,
+ <0x100 &pcie_smmu 0x0001 0x1>;
+ interrupt-parent = <&intc>;
+ interrupts = <GIC_SPI 307 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 308 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 309 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 312 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 313 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 314 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 374 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 375 IRQ_TYPE_LEVEL_HIGH>;
+ };
+ };
+...
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v3 08/29] mm: Define VM_SHADOW_STACK for RISC-V
From: Mark Brown @ 2024-04-04 19:04 UTC (permalink / raw)
To: David Hildenbrand
Cc: Deepak Gupta, paul.walmsley, rick.p.edgecombe, Szabolcs.Nagy,
kito.cheng, keescook, ajones, conor.dooley, cleger, atishp, alex,
bjorn, alexghiti, samuel.holland, conor, linux-doc, linux-riscv,
linux-kernel, devicetree, linux-mm, linux-arch, linux-kselftest,
corbet, palmer, aou, robh+dt, krzysztof.kozlowski+dt, oleg, akpm,
arnd, ebiederm, Liam.Howlett, vbabka, lstoakes, shuah, brauner,
andy.chiu, jerry.shih, hankuan.chen, greentime.hu, evan,
xiao.w.wang, charlie, apatel, mchitale, dbarboza, sameo,
shikemeng, willy, vincent.chen, guoren, samitolvanen,
songshuaishuai, gerg, heiko, bhe, jeeheng.sia, cyy, maskray,
ancientmodern4, mathis.salmen, cuiyunhui, bgray, mpe, baruch, alx,
catalin.marinas, revest, josh, shr, deller, omosnace, ojeda,
jhubbard
In-Reply-To: <8fb37319-288c-4f77-9cd7-92f17bb567ee@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 375 bytes --]
On Thu, Apr 04, 2024 at 08:58:06PM +0200, David Hildenbrand wrote:
> or even introduce some ARCH_HAS_SHADOW_STACK so we can remove these
> arch-specific thingies here.
It would be convenient if you could pull the ARCH_HAS_USER_SHADOW_STACK
patch out of my clone3 series to do that:
https://lore.kernel.org/all/20240203-clone3-shadow-stack-v5-3-322c69598e4b@kernel.org/
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v3 09/29] mm: abstract shadow stack vma behind `vma_is_shadow_stack`
From: David Hildenbrand @ 2024-04-04 19:02 UTC (permalink / raw)
To: Deepak Gupta, paul.walmsley, rick.p.edgecombe, broonie,
Szabolcs.Nagy, kito.cheng, keescook, ajones, conor.dooley, cleger,
atishp, alex, bjorn, alexghiti, samuel.holland, conor
Cc: linux-doc, linux-riscv, linux-kernel, devicetree, linux-mm,
linux-arch, linux-kselftest, corbet, palmer, aou, robh+dt,
krzysztof.kozlowski+dt, oleg, akpm, arnd, ebiederm, Liam.Howlett,
vbabka, lstoakes, shuah, brauner, andy.chiu, jerry.shih,
hankuan.chen, greentime.hu, evan, xiao.w.wang, charlie, apatel,
mchitale, dbarboza, sameo, shikemeng, willy, vincent.chen, guoren,
samitolvanen, songshuaishuai, gerg, heiko, bhe, jeeheng.sia, cyy,
maskray, ancientmodern4, mathis.salmen, cuiyunhui, bgray, mpe,
baruch, alx, catalin.marinas, revest, josh, shr, deller, omosnace,
ojeda, jhubbard, Mike Rapoport
In-Reply-To: <20240403234054.2020347-10-debug@rivosinc.com>
On 04.04.24 01:34, Deepak Gupta wrote:
> VM_SHADOW_STACK (alias to VM_HIGH_ARCH_5) to encode shadow stack VMA.
>
> This patch changes checks of VM_SHADOW_STACK flag in generic code to call
> to a function `vma_is_shadow_stack` which will return true if its a
> shadow stack vma and default stub (when support doesnt exist) returns false.
>
> Signed-off-by: Deepak Gupta <debug@rivosinc.com>
> Suggested-by: Mike Rapoport <rppt@kernel.org>
> ---
> include/linux/mm.h | 13 ++++++++++++-
> mm/gup.c | 5 +++--
> mm/internal.h | 2 +-
> 3 files changed, 16 insertions(+), 4 deletions(-)
>
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 64109f6c70f5..9952937be659 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -363,8 +363,19 @@ extern unsigned int kobjsize(const void *objp);
>
> #ifndef VM_SHADOW_STACK
> # define VM_SHADOW_STACK VM_NONE
> +
> +static inline bool vma_is_shadow_stack(vm_flags_t vm_flags)
> +{
> + return false;
> +}
> +#else
> +static inline bool vma_is_shadow_stack(vm_flags_t vm_flags)
> +{
> + return (vm_flags & VM_SHADOW_STACK);
> +}
> #endif
You can simply do outside the ifdef
static inline bool vma_is_shadow_stack(vm_flags_t vm_flags)
{
return !!(vm_flags & VM_SHADOW_STACK);
}
This will work even when VM_SHADOW_STACK is defined to be VM_NONE.
>
> +
unrelated code change
> #if defined(CONFIG_X86)
> # define VM_PAT VM_ARCH_1 /* PAT reserves whole VMA at once (x86) */
> #elif defined(CONFIG_PPC)
> @@ -3473,7 +3484,7 @@ static inline unsigned long stack_guard_start_gap(struct vm_area_struct *vma)
> return stack_guard_gap;
>
> /* See reasoning around the VM_SHADOW_STACK definition */
> - if (vma->vm_flags & VM_SHADOW_STACK)
> + if (vma->vm_flags && vma_is_shadow_stack(vma->vm_flags))
Pretty sure:
if (vma_is_shadow_stack(vma->vm_flags))
> return PAGE_SIZE;
>
> return 0;
> diff --git a/mm/gup.c b/mm/gup.c
> index df83182ec72d..a7a02eb0a6b3 100644
> --- a/mm/gup.c
> +++ b/mm/gup.c
> @@ -1053,7 +1053,7 @@ static int check_vma_flags(struct vm_area_struct *vma, unsigned long gup_flags)
> !writable_file_mapping_allowed(vma, gup_flags))
> return -EFAULT;
>
> - if (!(vm_flags & VM_WRITE) || (vm_flags & VM_SHADOW_STACK)) {
> + if (!(vm_flags & VM_WRITE) || vma_is_shadow_stack(vm_flags)) {
> if (!(gup_flags & FOLL_FORCE))
> return -EFAULT;
> /* hugetlb does not support FOLL_FORCE|FOLL_WRITE. */
> @@ -1071,7 +1071,8 @@ static int check_vma_flags(struct vm_area_struct *vma, unsigned long gup_flags)
> if (!is_cow_mapping(vm_flags))
> return -EFAULT;
> }
> - } else if (!(vm_flags & VM_READ)) {
> + } else if (!(vm_flags & VM_READ) && !vma_is_shadow_stack(vm_flags)) {
> + /* reads allowed if its shadow stack vma */
> if (!(gup_flags & FOLL_FORCE))
> return -EFAULT;
> /*
Unless I am missing something, this is not a simple cleanup. It should
go into a separate patch with a clearly documented reason for that change.
--
Cheers,
David / dhildenb
^ permalink raw reply
* Re: [PATCH v3 08/29] mm: Define VM_SHADOW_STACK for RISC-V
From: David Hildenbrand @ 2024-04-04 18:58 UTC (permalink / raw)
To: Deepak Gupta, paul.walmsley, rick.p.edgecombe, broonie,
Szabolcs.Nagy, kito.cheng, keescook, ajones, conor.dooley, cleger,
atishp, alex, bjorn, alexghiti, samuel.holland, conor
Cc: linux-doc, linux-riscv, linux-kernel, devicetree, linux-mm,
linux-arch, linux-kselftest, corbet, palmer, aou, robh+dt,
krzysztof.kozlowski+dt, oleg, akpm, arnd, ebiederm, Liam.Howlett,
vbabka, lstoakes, shuah, brauner, andy.chiu, jerry.shih,
hankuan.chen, greentime.hu, evan, xiao.w.wang, charlie, apatel,
mchitale, dbarboza, sameo, shikemeng, willy, vincent.chen, guoren,
samitolvanen, songshuaishuai, gerg, heiko, bhe, jeeheng.sia, cyy,
maskray, ancientmodern4, mathis.salmen, cuiyunhui, bgray, mpe,
baruch, alx, catalin.marinas, revest, josh, shr, deller, omosnace,
ojeda, jhubbard
In-Reply-To: <20240403234054.2020347-9-debug@rivosinc.com>
On 04.04.24 01:34, Deepak Gupta wrote:
> VM_SHADOW_STACK is defined by x86 as vm flag to mark a shadow stack vma.
>
> x86 uses VM_HIGH_ARCH_5 bit but that limits shadow stack vma to 64bit only.
> arm64 follows same path (see links)
>
> To keep things simple, RISC-V follows the same.
> This patch adds `ss` for shadow stack in process maps.
>
> Links:
> https://lore.kernel.org/lkml/20231009-arm64-gcs-v6-12-78e55deaa4dd@kernel.org/#r
>
> Signed-off-by: Deepak Gupta <debug@rivosinc.com>
> ---
> fs/proc/task_mmu.c | 3 +++
> include/linux/mm.h | 11 ++++++++++-
> 2 files changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
> index 3f78ebbb795f..d9d63eb74f0d 100644
> --- a/fs/proc/task_mmu.c
> +++ b/fs/proc/task_mmu.c
> @@ -702,6 +702,9 @@ static void show_smap_vma_flags(struct seq_file *m, struct vm_area_struct *vma)
> #endif /* CONFIG_HAVE_ARCH_USERFAULTFD_MINOR */
> #ifdef CONFIG_X86_USER_SHADOW_STACK
> [ilog2(VM_SHADOW_STACK)] = "ss",
> +#endif
> +#ifdef CONFIG_RISCV_USER_CFI
> + [ilog2(VM_SHADOW_STACK)] = "ss",
> #endif
> };
> size_t i;
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index f5a97dec5169..64109f6c70f5 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -352,7 +352,16 @@ extern unsigned int kobjsize(const void *objp);
> * for more details on the guard size.
> */
> # define VM_SHADOW_STACK VM_HIGH_ARCH_5
> -#else
> +#endif
> +
> +#ifdef CONFIG_RISCV_USER_CFI
> +/*
> + * RISC-V is going along with using VM_HIGH_ARCH_5 bit position for shadow stack
> + */
Wow, really?! I could never have guesses that from the code :P
Just drop that comment. Are them semantics the same as for the x86 variant documented?
("VM_SHADOW_STACK should not be set with VM_SHARED because of lack of")
I assume so. So it might now make sense to merge both paths
#if defined(CONFIG_X86_USER_SHADOW_STACK) || defined(CONFIG_RISCV_USER_CFI)
or even introduce some ARCH_HAS_SHADOW_STACK so we can remove these
arch-specific thingies here.
--
Cheers,
David / dhildenb
^ permalink raw reply
* Re: [PATCH v2] arm64: dts: qcom: qcs6490-rb3gen2: Enable UFS
From: Konrad Dybcio @ 2024-04-04 18:50 UTC (permalink / raw)
To: Bjorn Andersson, Bjorn Andersson, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20240327-rb3gen2-ufs-v2-1-3de6b5dd78dd@quicinc.com>
On 3/28/24 03:01, Bjorn Andersson wrote:
> The rb3gen2 has UFS memory, adjust the necessary supply voltage and add
> the controller and phy nodes to enable this.
>
> Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Konrad
^ permalink raw reply
* [PATCH] arm64: dts: ti: k3-am625-phyboard-lyra-rdk: Add Audio Codec
From: Garrett Giordano @ 2024-04-04 18:42 UTC (permalink / raw)
To: nm, vigneshr, kristo, robh, krzysztof.kozlowski+dt, conor+dt,
w.egorov
Cc: linux-arm-kernel, devicetree, linux-kernel, upstream
The Audio Codec runs over the MCASP (Multichannel Audio Serial Port).
Add pinmux for the Audio Reference Clock and MCASP2.
Add DT nodes for Audio Codec, MCASP2, VCC 1v8 and VCC 3v3 regulators.
Additionally, create a sound node that connects our sound card and the
MCASP2.
Signed-off-by: Garrett Giordano <ggiordano@phytec.com>
---
.../dts/ti/k3-am625-phyboard-lyra-rdk.dts | 99 +++++++++++++++++++
1 file changed, 99 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am625-phyboard-lyra-rdk.dts b/arch/arm64/boot/dts/ti/k3-am625-phyboard-lyra-rdk.dts
index a83a90497857..dfc78995d30a 100644
--- a/arch/arm64/boot/dts/ti/k3-am625-phyboard-lyra-rdk.dts
+++ b/arch/arm64/boot/dts/ti/k3-am625-phyboard-lyra-rdk.dts
@@ -66,6 +66,35 @@ key-menu {
};
};
+ sound {
+ compatible = "simple-audio-card";
+ simple-audio-card,name = "phyBOARD-Lyra";
+ simple-audio-card,widgets =
+ "Microphone", "Mic Jack",
+ "Headphone", "Headphone Jack",
+ "Speaker", "External Speaker";
+ simple-audio-card,routing =
+ "MIC3R", "Mic Jack",
+ "Mic Jack", "Mic Bias",
+ "Headphone Jack", "HPLOUT",
+ "Headphone Jack", "HPROUT",
+ "External Speaker", "SPOP",
+ "External Speaker", "SPOM";
+ simple-audio-card,format = "dsp_b";
+ simple-audio-card,bitclock-master = <&sound_master>;
+ simple-audio-card,frame-master = <&sound_master>;
+ simple-audio-card,bitclock-inversion;
+
+ simple-audio-card,cpu {
+ sound-dai = <&mcasp2>;
+ };
+
+ sound_master: simple-audio-card,codec {
+ sound-dai = <&audio_codec>;
+ clocks = <&audio_refclk1>;
+ };
+ };
+
leds {
compatible = "gpio-leds";
pinctrl-names = "default";
@@ -82,6 +111,15 @@ led-2 {
};
};
+ vcc_1v8: regulator-vcc-1v8 {
+ compatible = "regulator-fixed";
+ regulator-name = "VCC_1V8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
vcc_3v3_mmc: regulator-vcc-3v3-mmc {
compatible = "regulator-fixed";
regulator-name = "VCC_3V3_MMC";
@@ -90,9 +128,24 @@ vcc_3v3_mmc: regulator-vcc-3v3-mmc {
regulator-always-on;
regulator-boot-on;
};
+
+ vcc_3v3_sw: regulator-vcc-3v3-sw {
+ compatible = "regulator-fixed";
+ regulator-name = "VCC_3V3_SW";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
};
&main_pmx0 {
+ audio_ext_refclk1_pins_default: audio-ext-refclk1-default-pins {
+ pinctrl-single,pins = <
+ AM62X_IOPAD(0x0a0, PIN_OUTPUT, 1) /* (K25) GPMC0_WPn.AUDIO_EXT_REFCLK1 */
+ >;
+ };
+
gpio_keys_pins_default: gpio-keys-default-pins {
pinctrl-single,pins = <
AM62X_IOPAD(0x1d4, PIN_INPUT, 7) /* (B15) UART0_RTSn.GPIO1_23 */
@@ -150,6 +203,15 @@ AM62X_IOPAD(0x1d8, PIN_OUTPUT, 0) /* (C15) MCAN0_TX */
>;
};
+ main_mcasp2_pins_default: main-mcasp2-default-pins {
+ pinctrl-single,pins = <
+ AM62X_IOPAD(0x070, PIN_INPUT, 3) /* (T24) GPMC0_AD13.MCASP2_ACLKX */
+ AM62X_IOPAD(0x06c, PIN_INPUT, 3) /* (T22) GPMC0_AD12.MCASP2_AFSX */
+ AM62X_IOPAD(0x064, PIN_OUTPUT, 3) /* (T25) GPMC0_AD10.MCASP2_AXR2 */
+ AM62X_IOPAD(0x068, PIN_INPUT, 3) /* (R21) GPMC0_AD11.MCASP2_AXR3 */
+ >;
+ };
+
main_mmc1_pins_default: main-mmc1-default-pins {
pinctrl-single,pins = <
AM62X_IOPAD(0x23c, PIN_INPUT_PULLUP, 0) /* (A21) MMC1_CMD */
@@ -254,6 +316,21 @@ &main_i2c1 {
clock-frequency = <100000>;
status = "okay";
+ audio_codec: audio-codec@18 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&audio_ext_refclk1_pins_default>;
+
+ #sound-dai-cells = <0>;
+ compatible = "ti,tlv320aic3007";
+ reg = <0x18>;
+ ai3x-micbias-vg = <2>;
+
+ AVDD-supply = <&vcc_3v3_sw>;
+ IOVDD-supply = <&vcc_3v3_sw>;
+ DRVDD-supply = <&vcc_3v3_sw>;
+ DVDD-supply = <&vcc_1v8>;
+ };
+
gpio_exp: gpio-expander@21 {
pinctrl-names = "default";
pinctrl-0 = <&gpio_exp_int_pins_default>;
@@ -329,6 +406,28 @@ &main_uart1 {
status = "okay";
};
+&mcasp2 {
+ status = "okay";
+ #sound-dai-cells = <0>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&main_mcasp2_pins_default>;
+
+ /* MCASP_IIS_MODE */
+ op-mode = <0>;
+ tdm-slots = <2>;
+
+ /* 0: INACTIVE, 1: TX, 2: RX */
+ serial-dir = <
+ 0 0 1 2
+ 0 0 0 0
+ 0 0 0 0
+ 0 0 0 0
+ >;
+ tx-num-evt = <32>;
+ rx-num-evt = <32>;
+};
+
&sdhci1 {
vmmc-supply = <&vcc_3v3_mmc>;
vqmmc-supply = <&vddshv5_sdio>;
--
2.25.1
^ permalink raw reply related
* Re: [PATCH] media: mediatek: vcodec: fix the error sizeimage for 10bit bitstream
From: Nicolas Dufresne @ 2024-04-04 18:28 UTC (permalink / raw)
To: Yunfei Dong, Nícolas F . R . A . Prado, Sebastian Fricke,
Hans Verkuil, AngeloGioacchino Del Regno, Benjamin Gaignard,
Nathan Hebert
Cc: Hsin-Yi Wang, Fritz Koenig, Daniel Vetter, Steve Cho, linux-media,
devicetree, linux-kernel, linux-arm-kernel, linux-mediatek,
Project_Global_Chrome_Upstream_Group
In-Reply-To: <20240403093018.13168-1-yunfei.dong@mediatek.com>
Hi,
Le mercredi 03 avril 2024 à 17:30 +0800, Yunfei Dong a écrit :
> The sizeimage of each plane are calculated the same way for 8bit and
> 10bit bitstream. Need to enlarge the sizeimage with simeimage*5/4 for
> 10bit bitstream when try and set fmt.
Can we stop adding more layers of custom code and port to v4l2-common helpers
please.
regards,
Nicolas
>
> Fixes: 9d86be9bda6c ("media: mediatek: vcodec: Add driver to support 10bit")
> Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
> ---
> .../mediatek/vcodec/decoder/mtk_vcodec_dec.c | 47 ++++++++++++++-----
> 1 file changed, 34 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec.c b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec.c
> index 9107707de6c4..45209894f1fe 100644
> --- a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec.c
> +++ b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec.c
> @@ -259,6 +259,7 @@ static int vidioc_try_fmt(struct mtk_vcodec_dec_ctx *ctx, struct v4l2_format *f,
> pix_fmt_mp->num_planes = 1;
> pix_fmt_mp->plane_fmt[0].bytesperline = 0;
> } else if (f->type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE) {
> + unsigned int dram_y, dram_c, dram_y_10bit, dram_c_10bit;
> int tmp_w, tmp_h;
>
> /*
> @@ -280,22 +281,42 @@ static int vidioc_try_fmt(struct mtk_vcodec_dec_ctx *ctx, struct v4l2_format *f,
> (pix_fmt_mp->height + 64) <= frmsize->max_height)
> pix_fmt_mp->height += 64;
>
> - mtk_v4l2_vdec_dbg(0, ctx,
> - "before resize wxh=%dx%d, after resize wxh=%dx%d, sizeimage=%d",
> - tmp_w, tmp_h, pix_fmt_mp->width, pix_fmt_mp->height,
> - pix_fmt_mp->width * pix_fmt_mp->height);
> + dram_y = pix_fmt_mp->width * pix_fmt_mp->height;
> + dram_c = dram_y / 2;
> +
> + dram_y_10bit = dram_y * 5 / 4;
> + dram_c_10bit = dram_y_10bit / 2;
>
> pix_fmt_mp->num_planes = fmt->num_planes;
> - pix_fmt_mp->plane_fmt[0].sizeimage =
> - pix_fmt_mp->width * pix_fmt_mp->height;
> - pix_fmt_mp->plane_fmt[0].bytesperline = pix_fmt_mp->width;
> -
> - if (pix_fmt_mp->num_planes == 2) {
> - pix_fmt_mp->plane_fmt[1].sizeimage =
> - (pix_fmt_mp->width * pix_fmt_mp->height) / 2;
> - pix_fmt_mp->plane_fmt[1].bytesperline =
> - pix_fmt_mp->width;
> + if (pix_fmt_mp->num_planes == 1) {
> + if (ctx->is_10bit_bitstream) {
> + pix_fmt_mp->plane_fmt[0].bytesperline = pix_fmt_mp->width * 5 / 4;
> + pix_fmt_mp->plane_fmt[0].sizeimage = dram_y_10bit + dram_c_10bit;
> + } else {
> + pix_fmt_mp->plane_fmt[0].bytesperline = pix_fmt_mp->width;
> + pix_fmt_mp->plane_fmt[0].sizeimage = dram_y + dram_c;
> + }
> + } else {
> + if (ctx->is_10bit_bitstream) {
> + pix_fmt_mp->plane_fmt[0].bytesperline = pix_fmt_mp->width * 5 / 4;
> + pix_fmt_mp->plane_fmt[1].bytesperline = pix_fmt_mp->width * 5 / 4;
> +
> + pix_fmt_mp->plane_fmt[0].sizeimage = dram_y_10bit;
> + pix_fmt_mp->plane_fmt[1].sizeimage = dram_c_10bit;
> + } else {
> + pix_fmt_mp->plane_fmt[0].bytesperline = pix_fmt_mp->width;
> + pix_fmt_mp->plane_fmt[1].bytesperline = pix_fmt_mp->width;
> +
> + pix_fmt_mp->plane_fmt[0].sizeimage = dram_y;
> + pix_fmt_mp->plane_fmt[1].sizeimage = dram_c;
> + }
> }
> +
> + mtk_v4l2_vdec_dbg(0, ctx,
> + "before resize:%dx%d, after resize:%dx%d, sizeimage=0x%x_0x%x",
> + tmp_w, tmp_h, pix_fmt_mp->width, pix_fmt_mp->height,
> + pix_fmt_mp->plane_fmt[0].sizeimage,
> + pix_fmt_mp->plane_fmt[1].sizeimage);
> }
>
> pix_fmt_mp->flags = 0;
^ permalink raw reply
* Re: [PATCH v2 1/2] media: dt-binding: media: Document rk3588’s VEPU121
From: Nicolas Dufresne @ 2024-04-04 17:47 UTC (permalink / raw)
To: Conor Dooley, Emmanuel Gil Peyrot
Cc: linux-kernel, Ezequiel Garcia, Philipp Zabel,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Heiko Stuebner, Joerg Roedel, Will Deacon,
Robin Murphy, Sebastian Reichel, Cristian Ciocaltea, Dragan Simic,
Shreeya Patel, Chris Morgan, Andy Yan, Nicolas Frattaroli,
linux-media, linux-rockchip, devicetree, linux-arm-kernel, iommu
In-Reply-To: <20240327-doze-uncheck-475f3feaee57@spud>
Le mercredi 27 mars 2024 à 17:23 +0000, Conor Dooley a écrit :
> On Wed, Mar 27, 2024 at 02:41:11PM +0100, Emmanuel Gil Peyrot wrote:
> > This encoder-only device is present four times on this SoC, and should
> > support everything the rk3568 vepu supports (so JPEG, H.264 and VP8
> > encoding).
> >
> > According to the TRM[1], there is also the VEPU580 encoder which
> > supports H.264 and H.265, and various VDPU* decoders, of which only the
> > VDPU981 is currently supported. This patch describes only the VEPU121.
> >
> > [1] https://github.com/FanX-Tek/rk3588-TRM-and-Datasheet
> >
> > Signed-off-by: Emmanuel Gil Peyrot <linkmauve@linkmauve.fr>
>
> Acked-by: Conor Dooley <conor.dooley@microchip.com>
I'd like to prevent this change until we fix the driver. It should not expose 1
video device per core, it should instead do schedule around these cores.
Nicolas
>
> Thanks,
> Conor.
>
> > ---
> > .../devicetree/bindings/media/rockchip,rk3568-vepu.yaml | 8 ++++++--
> > 1 file changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/media/rockchip,rk3568-vepu.yaml b/Documentation/devicetree/bindings/media/rockchip,rk3568-vepu.yaml
> > index 9d90d8d0565a..4c6cb21da041 100644
> > --- a/Documentation/devicetree/bindings/media/rockchip,rk3568-vepu.yaml
> > +++ b/Documentation/devicetree/bindings/media/rockchip,rk3568-vepu.yaml
> > @@ -15,8 +15,12 @@ description:
> >
> > properties:
> > compatible:
> > - enum:
> > - - rockchip,rk3568-vepu
> > + oneOf:
> > + - const: rockchip,rk3568-vepu
> > + - items:
> > + - enum:
> > + - rockchip,rk3588-vepu121
> > + - const: rockchip,rk3568-vepu
> >
> > reg:
> > maxItems: 1
> > --
> > 2.44.0
> >
^ permalink raw reply
* Re: [PATCH v2 0/2] Enable JPEG encoding on rk3588
From: Nicolas Dufresne @ 2024-04-04 17:41 UTC (permalink / raw)
To: Emmanuel Gil Peyrot, linux-kernel
Cc: Ezequiel Garcia, Philipp Zabel, Mauro Carvalho Chehab,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Joerg Roedel, Will Deacon, Robin Murphy, Sebastian Reichel,
Cristian Ciocaltea, Dragan Simic, Shreeya Patel, Chris Morgan,
Andy Yan, Nicolas Frattaroli, linux-media, linux-rockchip,
devicetree, linux-arm-kernel, iommu
In-Reply-To: <20240327134115.424846-1-linkmauve@linkmauve.fr>
Hi,
Le mercredi 27 mars 2024 à 14:41 +0100, Emmanuel Gil Peyrot a écrit :
> Only the JPEG encoder is available for now, although there are patches
> for the undocumented VP8 encoder floating around[0].
[0] seems like a broken link. The VP8 encoder RFC is for RK3399 (and Hantro H1
posted by ST more recently). The TRM says "VEPU121(JPEG encoder only)", which
suggest that the H.264 and VP8 encoders usually found on the VEPU121 are
removed. As Rockchip have remove the synthesize register while modifying the H1
IP, it is difficult to verify. Confusingly the H.264 specific registers are
documented in the TRM around VEPU121.
>
> This has been tested on a rock-5b, resulting in four /dev/video*
> encoders. The userspace program I’ve been using to test them is
> Onix[1], using the jpeg-encoder example, it will pick one of these four
> at random (but displays the one it picked):
> % ffmpeg -i <input image> -pix_fmt yuvj420p temp.yuv
> % jpeg-encoder temp.yuv <width> <height> NV12 <quality> output.jpeg
I don't like that we exposing each identical cores a separate video nodes. I
think we should aim for 1 device, and then multi-plex and schedule de cores from
inside the Linux kernel.
Not doing this now means we'll never have an optimal hardware usage
distribution. Just consider two userspace software wanting to do jpeg encoding.
If they both take a guess, they may endup using a single core. Where with proper
scheduling in V4L2, the kernel will be able to properly distribute the load. I
insist on this, since if we merge you changes it becomes an ABI and we can't
change it anymore.
I understand that this impose a rework of the mem2mem framework so that we can
run multiple jobs, but this will be needed anyway on RK3588, since the rkvdec2,
which we don't have a driver yet is also multi-core, but you need to use 2 cores
when the resolution is close to 8K.
Nicolas
>
> [0] https://patchwork.kernel.org/project/linux-rockchip/list/?series=789885
> [1] https://crates.io/crates/onix
>
> Changes since v1:
> - Dropped patches 1 and 4.
> - Use the proper compatible form, since this device should be fully
> compatible with the VEPU of rk356x.
> - Describe where the VEPU121 name comes from, and list other encoders
> and decoders present in this SoC.
> - Properly test the device tree changes, I previously couldn’t since I
> was using a too recent version of python-jsonschema…
>
> Emmanuel Gil Peyrot (2):
> media: dt-binding: media: Document rk3588’s VEPU121
> arm64: dts: rockchip: Add VEPU121 to rk3588
>
> .../bindings/media/rockchip,rk3568-vepu.yaml | 8 +-
> arch/arm64/boot/dts/rockchip/rk3588s.dtsi | 80 +++++++++++++++++++
> 2 files changed, 86 insertions(+), 2 deletions(-)
>
^ permalink raw reply
* Re: [PATCH v12 2/7] clk: meson: add vclk driver
From: Neil Armstrong @ 2024-04-04 16:59 UTC (permalink / raw)
To: Jerome Brunet
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Martin Blumenstingl, Kevin Hilman, Michael Turquette,
Stephen Boyd, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Daniel Vetter, Jagan Teki, Nicolas Belin,
devicetree, linux-kernel, linux-amlogic, linux-clk,
linux-arm-kernel, dri-devel
In-Reply-To: <1jmsq9pmgd.fsf@starbuckisacylon.baylibre.com>
On 04/04/2024 10:13, Jerome Brunet wrote:
>
> On Wed 03 Apr 2024 at 09:46, Neil Armstrong <neil.armstrong@linaro.org> wrote:
>
>> The VCLK and VCLK_DIV clocks have supplementary bits.
>>
>> The VCLK gate has a "SOFT RESET" bit to toggle after the whole
>> VCLK sub-tree rate has been set, this is implemented in
>> the gate enable callback.
>>
>> The VCLK_DIV clocks as enable and reset bits used to disable
>> and reset the divider, associated with CLK_SET_RATE_GATE it ensures
>> the rate is set while the divider is disabled and in reset mode.
>>
>> The VCLK_DIV enable bit isn't implemented as a gate since it's part
>> of the divider logic and vendor does this exact sequence to ensure
>> the divider is correctly set.
>
> The checkpatch warning is still there. Is it a choice or a mistake ?
>
> Documentation says "GPL v2" exists for historic reason which seems to
> hint "GPL" is preferred, and I suppose this is why checkpatch warns for
> it.
Well I didn't see this warning, this is what I fixed:
$ scripts/checkpatch.pl --strict drivers/clk/meson/vclk.c
CHECK: Alignment should match open parenthesis
#63: FILE: drivers/clk/meson/vclk.c:63:
+static unsigned long meson_vclk_div_recalc_rate(struct clk_hw *hw,
+ unsigned long prate)
CHECK: Alignment should match open parenthesis
#73: FILE: drivers/clk/meson/vclk.c:73:
+static int meson_vclk_div_determine_rate(struct clk_hw *hw,
+ struct clk_rate_request *req)
CHECK: Alignment should match open parenthesis
#83: FILE: drivers/clk/meson/vclk.c:83:
+static int meson_vclk_div_set_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long parent_rate)
<snip>
It seems that checking a commit triggers an extra check....
$ scripts/checkpatch.pl --strict -G 1bac9f6aa3c3
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#58:
new file mode 100644
<snip>
WARNING: Prefer "GPL" over "GPL v2" - see commit bf7fbeeae6db ("module: Cure the MODULE_LICENSE "GPL" vs. "GPL v2" bogosity")
#203: FILE: drivers/clk/meson/vclk.c:141:
+MODULE_LICENSE("GPL v2");
<snip>
Neil
>
>>
>> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
>> ---
>> drivers/clk/meson/Kconfig | 4 ++
>> drivers/clk/meson/Makefile | 1 +
>> drivers/clk/meson/vclk.c | 141 +++++++++++++++++++++++++++++++++++++++++++++
>> drivers/clk/meson/vclk.h | 51 ++++++++++++++++
>> 4 files changed, 197 insertions(+)
>>
>> diff --git a/drivers/clk/meson/Kconfig b/drivers/clk/meson/Kconfig
>> index 29ffd14d267b..8a9823789fa3 100644
>> --- a/drivers/clk/meson/Kconfig
>> +++ b/drivers/clk/meson/Kconfig
>> @@ -30,6 +30,10 @@ config COMMON_CLK_MESON_VID_PLL_DIV
>> tristate
>> select COMMON_CLK_MESON_REGMAP
>>
>> +config COMMON_CLK_MESON_VCLK
>> + tristate
>> + select COMMON_CLK_MESON_REGMAP
>> +
>> config COMMON_CLK_MESON_CLKC_UTILS
>> tristate
>>
>> diff --git a/drivers/clk/meson/Makefile b/drivers/clk/meson/Makefile
>> index 9ee4b954c896..9ba43fe7a07a 100644
>> --- a/drivers/clk/meson/Makefile
>> +++ b/drivers/clk/meson/Makefile
>> @@ -12,6 +12,7 @@ obj-$(CONFIG_COMMON_CLK_MESON_PLL) += clk-pll.o
>> obj-$(CONFIG_COMMON_CLK_MESON_REGMAP) += clk-regmap.o
>> obj-$(CONFIG_COMMON_CLK_MESON_SCLK_DIV) += sclk-div.o
>> obj-$(CONFIG_COMMON_CLK_MESON_VID_PLL_DIV) += vid-pll-div.o
>> +obj-$(CONFIG_COMMON_CLK_MESON_VCLK) += vclk.o
>>
>> # Amlogic Clock controllers
>>
>> diff --git a/drivers/clk/meson/vclk.c b/drivers/clk/meson/vclk.c
>> new file mode 100644
>> index 000000000000..45dc216941ea
>> --- /dev/null
>> +++ b/drivers/clk/meson/vclk.c
>> @@ -0,0 +1,141 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Copyright (c) 2024 Neil Armstrong <neil.armstrong@linaro.org>
>> + */
>> +
>> +#include <linux/module.h>
>> +#include "vclk.h"
>> +
>> +/* The VCLK gate has a supplementary reset bit to pulse after ungating */
>> +
>> +static inline struct meson_vclk_gate_data *
>> +clk_get_meson_vclk_gate_data(struct clk_regmap *clk)
>> +{
>> + return (struct meson_vclk_gate_data *)clk->data;
>> +}
>> +
>> +static int meson_vclk_gate_enable(struct clk_hw *hw)
>> +{
>> + struct clk_regmap *clk = to_clk_regmap(hw);
>> + struct meson_vclk_gate_data *vclk = clk_get_meson_vclk_gate_data(clk);
>> +
>> + meson_parm_write(clk->map, &vclk->enable, 1);
>> +
>> + /* Do a reset pulse */
>> + meson_parm_write(clk->map, &vclk->reset, 1);
>> + meson_parm_write(clk->map, &vclk->reset, 0);
>> +
>> + return 0;
>> +}
>> +
>> +static void meson_vclk_gate_disable(struct clk_hw *hw)
>> +{
>> + struct clk_regmap *clk = to_clk_regmap(hw);
>> + struct meson_vclk_gate_data *vclk = clk_get_meson_vclk_gate_data(clk);
>> +
>> + meson_parm_write(clk->map, &vclk->enable, 0);
>> +}
>> +
>> +static int meson_vclk_gate_is_enabled(struct clk_hw *hw)
>> +{
>> + struct clk_regmap *clk = to_clk_regmap(hw);
>> + struct meson_vclk_gate_data *vclk = clk_get_meson_vclk_gate_data(clk);
>> +
>> + return meson_parm_read(clk->map, &vclk->enable);
>> +}
>> +
>> +const struct clk_ops meson_vclk_gate_ops = {
>> + .enable = meson_vclk_gate_enable,
>> + .disable = meson_vclk_gate_disable,
>> + .is_enabled = meson_vclk_gate_is_enabled,
>> +};
>> +EXPORT_SYMBOL_GPL(meson_vclk_gate_ops);
>> +
>> +/* The VCLK Divider has supplementary reset & enable bits */
>> +
>> +static inline struct meson_vclk_div_data *
>> +clk_get_meson_vclk_div_data(struct clk_regmap *clk)
>> +{
>> + return (struct meson_vclk_div_data *)clk->data;
>> +}
>> +
>> +static unsigned long meson_vclk_div_recalc_rate(struct clk_hw *hw,
>> + unsigned long prate)
>> +{
>> + struct clk_regmap *clk = to_clk_regmap(hw);
>> + struct meson_vclk_div_data *vclk = clk_get_meson_vclk_div_data(clk);
>> +
>> + return divider_recalc_rate(hw, prate, meson_parm_read(clk->map, &vclk->div),
>> + vclk->table, vclk->flags, vclk->div.width);
>> +}
>> +
>> +static int meson_vclk_div_determine_rate(struct clk_hw *hw,
>> + struct clk_rate_request *req)
>> +{
>> + struct clk_regmap *clk = to_clk_regmap(hw);
>> + struct meson_vclk_div_data *vclk = clk_get_meson_vclk_div_data(clk);
>> +
>> + return divider_determine_rate(hw, req, vclk->table, vclk->div.width,
>> + vclk->flags);
>> +}
>> +
>> +static int meson_vclk_div_set_rate(struct clk_hw *hw, unsigned long rate,
>> + unsigned long parent_rate)
>> +{
>> + struct clk_regmap *clk = to_clk_regmap(hw);
>> + struct meson_vclk_div_data *vclk = clk_get_meson_vclk_div_data(clk);
>> + int ret;
>> +
>> + ret = divider_get_val(rate, parent_rate, vclk->table, vclk->div.width,
>> + vclk->flags);
>> + if (ret < 0)
>> + return ret;
>> +
>> + meson_parm_write(clk->map, &vclk->div, ret);
>> +
>> + return 0;
>> +};
>> +
>> +static int meson_vclk_div_enable(struct clk_hw *hw)
>> +{
>> + struct clk_regmap *clk = to_clk_regmap(hw);
>> + struct meson_vclk_div_data *vclk = clk_get_meson_vclk_div_data(clk);
>> +
>> + /* Unreset the divider when ungating */
>> + meson_parm_write(clk->map, &vclk->reset, 0);
>> + meson_parm_write(clk->map, &vclk->enable, 1);
>> +
>> + return 0;
>> +}
>> +
>> +static void meson_vclk_div_disable(struct clk_hw *hw)
>> +{
>> + struct clk_regmap *clk = to_clk_regmap(hw);
>> + struct meson_vclk_div_data *vclk = clk_get_meson_vclk_div_data(clk);
>> +
>> + /* Reset the divider when gating */
>> + meson_parm_write(clk->map, &vclk->enable, 0);
>> + meson_parm_write(clk->map, &vclk->reset, 1);
>> +}
>> +
>> +static int meson_vclk_div_is_enabled(struct clk_hw *hw)
>> +{
>> + struct clk_regmap *clk = to_clk_regmap(hw);
>> + struct meson_vclk_div_data *vclk = clk_get_meson_vclk_div_data(clk);
>> +
>> + return meson_parm_read(clk->map, &vclk->enable);
>> +}
>> +
>> +const struct clk_ops meson_vclk_div_ops = {
>> + .recalc_rate = meson_vclk_div_recalc_rate,
>> + .determine_rate = meson_vclk_div_determine_rate,
>> + .set_rate = meson_vclk_div_set_rate,
>> + .enable = meson_vclk_div_enable,
>> + .disable = meson_vclk_div_disable,
>> + .is_enabled = meson_vclk_div_is_enabled,
>> +};
>> +EXPORT_SYMBOL_GPL(meson_vclk_div_ops);
>> +
>> +MODULE_DESCRIPTION("Amlogic vclk clock driver");
>> +MODULE_AUTHOR("Neil Armstrong <neil.armstrong@linaro.org>");
>> +MODULE_LICENSE("GPL v2");
>> diff --git a/drivers/clk/meson/vclk.h b/drivers/clk/meson/vclk.h
>> new file mode 100644
>> index 000000000000..20b0b181db09
>> --- /dev/null
>> +++ b/drivers/clk/meson/vclk.h
>> @@ -0,0 +1,51 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>> +/*
>> + * Copyright (c) 2024 Neil Armstrong <neil.armstrong@linaro.org>
>> + */
>> +
>> +#ifndef __VCLK_H
>> +#define __VCLK_H
>> +
>> +#include "clk-regmap.h"
>> +#include "parm.h"
>> +
>> +/**
>> + * struct meson_vclk_gate_data - vclk_gate regmap backed specific data
>> + *
>> + * @enable: vclk enable field
>> + * @reset: vclk reset field
>> + * @flags: hardware-specific flags
>> + *
>> + * Flags:
>> + * Same as clk_gate except CLK_GATE_HIWORD_MASK which is ignored
>> + */
>> +struct meson_vclk_gate_data {
>> + struct parm enable;
>> + struct parm reset;
>> + u8 flags;
>> +};
>> +
>> +extern const struct clk_ops meson_vclk_gate_ops;
>> +
>> +/**
>> + * struct meson_vclk_div_data - vclk_div regmap back specific data
>> + *
>> + * @div: divider field
>> + * @enable: vclk divider enable field
>> + * @reset: vclk divider reset field
>> + * @table: array of value/divider pairs, last entry should have div = 0
>> + *
>> + * Flags:
>> + * Same as clk_divider except CLK_DIVIDER_HIWORD_MASK which is ignored
>> + */
>> +struct meson_vclk_div_data {
>> + struct parm div;
>> + struct parm enable;
>> + struct parm reset;
>> + const struct clk_div_table *table;
>> + u8 flags;
>> +};
>> +
>> +extern const struct clk_ops meson_vclk_div_ops;
>> +
>> +#endif /* __VCLK_H */
>
>
^ permalink raw reply
* Re: [RESEND v7 06/37] sh: kernel/setup Update DT support.
From: Rob Herring @ 2024-04-04 16:48 UTC (permalink / raw)
To: Yoshinori Sato
Cc: linux-sh, Damien Le Moal, Niklas Cassel, Krzysztof Kozlowski,
Conor Dooley, Geert Uytterhoeven, Michael Turquette, Stephen Boyd,
David Airlie, Daniel Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Thomas Gleixner, Bjorn Helgaas,
Lorenzo Pieralisi, Krzysztof Wilczyński, Greg Kroah-Hartman,
Jiri Slaby, Magnus Damm, Daniel Lezcano, Rich Felker,
John Paul Adrian Glaubitz, Lee Jones, Helge Deller,
Heiko Stuebner, Shawn Guo, Sebastian Reichel, Chris Morgan,
Linus Walleij, Arnd Bergmann, David Rientjes, Hyeonggon Yoo,
Vlastimil Babka, Baoquan He, Andrew Morton, Guenter Roeck,
Kefeng Wang, Stephen Rothwell, Javier Martinez Canillas, Guo Ren,
Azeem Shaikh, Max Filippov, Jonathan Corbet, Jacky Huang,
Herve Codina, Manikanta Guntupalli, Anup Patel, Biju Das,
Uwe Kleine-König, Sam Ravnborg, Sergey Shtylyov,
Laurent Pinchart, linux-ide, devicetree, linux-kernel,
linux-renesas-soc, linux-clk, dri-devel, linux-pci, linux-serial,
linux-fbdev
In-Reply-To: <a4ce7771faec761b9bbb91ff6694a99e5bc293b6.1712207606.git.ysato@users.sourceforge.jp>
On Thu, Apr 4, 2024 at 12:15 AM Yoshinori Sato
<ysato@users.sourceforge.jp> wrote:
>
> Fix extrnal fdt initialize and bootargs.
What is the problem you are trying to solve?
And a typo.
>
> Signed-off-by: Yoshinori Sato <ysato@users.sourceforge.jp>
> ---
> arch/sh/Kconfig | 23 +++++++++++------------
> arch/sh/include/asm/setup.h | 1 +
> arch/sh/kernel/setup.c | 36 +++++++++++++++++++++++-------------
> 3 files changed, 35 insertions(+), 25 deletions(-)
>
> diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig
> index 6711cde0d973..242cf30e704d 100644
> --- a/arch/sh/Kconfig
> +++ b/arch/sh/Kconfig
> @@ -708,17 +708,22 @@ config ROMIMAGE_MMCIF
> first part of the romImage which in turn loads the rest the kernel
> image to RAM using the MMCIF hardware block.
>
> +config CMDLINE
> + string "Kernel command line arguments string"
> + default "console=ttySC1,115200"
> +
> choice
> prompt "Kernel command line"
> - optional
> - default CMDLINE_OVERWRITE
> - depends on !OF || USE_BUILTIN_DTB
> + default CMDLINE_BOOTLOADER
> +
> +config CMDLINE_BOOTLOADER
> + bool "Use bootloader kernel arguments"
This should be the preferred, normal, default way. So why is it a user
visible option?
> help
> - Setting this option allows the kernel command line arguments
> - to be set.
> + Uses the command-line options passed by the boot loader.
> + If boot loader dosen't provide kernel argments, Use built-in argments.
typos
bootloader in some spots, "boot loader" in others. Go with the former.
>
> config CMDLINE_OVERWRITE
> - bool "Overwrite bootloader kernel arguments"
> + bool "Overwrite built-in kernel arguments"
The original made more sense to me. The default should be to use
bootloader args. Any built-in kernel command line should be prepend,
append (extend), or overwrite/replace.
Rob
^ permalink raw reply
* Re: [PATCH v2 3/3] ARM: dts: bcm283x: Drop unneeded properties in the bcm2835-firmware node
From: Florian Fainelli @ 2024-04-04 16:47 UTC (permalink / raw)
To: bcm-kernel-feedback-list, Laurent Pinchart, devicetree,
linux-rpi-kernel, linux-arm-kernel
Cc: Florian Fainelli, Dave Stevenson, Naushir Patuck, Conor Dooley,
Krzysztof Kozlowski, Nicolas Saenz Julienne, Ray Jui, Rob Herring,
Scott Branden, Stefan Wahren
In-Reply-To: <20240326195807.15163-4-laurent.pinchart@ideasonboard.com>
From: Florian Fainelli <f.fainelli@gmail.com>
On Tue, 26 Mar 2024 21:58:07 +0200, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote:
> The firmware node contains a "dma-ranges" property to enable usage of
> the DMA mapping API with its child devices, along with "#address-cells"
> and "#size-cells" properties to support the dma-ranges. This was needed
> due to usage of the incorrect device to perform the DMA mapping in
> drivers. Now that this has been fixed, drop the properties.
>
> This effectively reverts commits be08d278eb09 ("ARM: dts: bcm283x: Add
> cells encoding format to firmware bus") and 55c7c0621078 ("ARM: dts:
> bcm283x: Fix vc4's firmware bus DMA limitations").
>
> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
Applied to https://github.com/Broadcom/stblinux/commits/devicetree/next, thanks!
--
Florian
^ permalink raw reply
* Re: [PATCH v2 2/3] firmware: raspberrypi: Use correct device for DMA mappings
From: Florian Fainelli @ 2024-04-04 16:46 UTC (permalink / raw)
To: bcm-kernel-feedback-list, Laurent Pinchart, devicetree,
linux-rpi-kernel, linux-arm-kernel
Cc: Florian Fainelli, Dave Stevenson, Naushir Patuck, Conor Dooley,
Krzysztof Kozlowski, Nicolas Saenz Julienne, Ray Jui, Rob Herring,
Scott Branden, Stefan Wahren
In-Reply-To: <20240326195807.15163-3-laurent.pinchart@ideasonboard.com>
From: Florian Fainelli <f.fainelli@gmail.com>
On Tue, 26 Mar 2024 21:58:06 +0200, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote:
> The buffer used to transfer data over the mailbox interface is mapped
> using the client's device. This is incorrect, as the device performing
> the DMA transfer is the mailbox itself. Fix it by using the mailbox
> controller device instead.
>
> This requires including the mailbox_controller.h header to dereference
> the mbox_chan and mbox_controller structures. The header is not meant to
> be included by clients. This could be fixed by extending the client API
> with a function to access the controller's device.
>
> Fixes: 4e3d60656a72 ("ARM: bcm2835: Add the Raspberry Pi firmware driver")
> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
Applied to https://github.com/Broadcom/stblinux/commits/devicetree/next, thanks!
--
Florian
^ permalink raw reply
* Re: [PATCH v2 1/3] dt-bindings: arm: bcm: raspberrypi,bcm2835-firmware: Add gpio child node
From: Florian Fainelli @ 2024-04-04 16:46 UTC (permalink / raw)
To: bcm-kernel-feedback-list, Laurent Pinchart, devicetree,
linux-rpi-kernel, linux-arm-kernel
Cc: Florian Fainelli, Dave Stevenson, Naushir Patuck,
Bartosz Golaszewski, Conor Dooley, Krzysztof Kozlowski,
Linus Walleij, Ray Jui, Rob Herring, Scott Branden, Stefan Wahren
In-Reply-To: <20240326195807.15163-2-laurent.pinchart@ideasonboard.com>
From: Florian Fainelli <f.fainelli@gmail.com>
On Tue, 26 Mar 2024 21:58:05 +0200, Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote:
> Unlike the other child nodes of the raspberrypi,bcm2835-firmware device,
> the gpio child is documented in a legacy text-based binding in
> gpio/raspberrypi,firmware-gpio.txt. This causes DT validation failures:
>
> arch/arm64/boot/dts/broadcom/bcm2711-rpi-4-b.dtb: 'gpio' does not match any of the regexes: 'pinctrl-[0-9]+'
> from schema $id: http://devicetree.org/schemas/arm/bcm/raspberrypi,bcm2835-firmware.yaml#
>
> Convert the binding to YAML and move it to
> raspberrypi,bcm2835-firmware.yaml.
>
> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> ---
Applied to https://github.com/Broadcom/stblinux/commits/devicetree/next, thanks!
--
Florian
^ permalink raw reply
* [PATCH] dt-bindings: usb: Document the Microchip USB2514 hub
From: Fabio Estevam @ 2024-04-04 16:41 UTC (permalink / raw)
To: gregkh; +Cc: robh, krzk+dt, conor+dt, linux-usb, devicetree, Fabio Estevam
From: Fabio Estevam <festevam@denx.de>
Document the Microchip USB2514, USB2412, and USB2417 USB hubs.
Signed-off-by: Fabio Estevam <festevam@denx.de>
---
.../bindings/usb/microchip,usb2514.yaml | 53 +++++++++++++++++++
1 file changed, 53 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/microchip,usb2514.yaml
diff --git a/Documentation/devicetree/bindings/usb/microchip,usb2514.yaml b/Documentation/devicetree/bindings/usb/microchip,usb2514.yaml
new file mode 100644
index 000000000000..8df7a5adfbe8
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/microchip,usb2514.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/microchip,usb2514.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip USB2514 Hub Controller
+
+maintainers:
+ - Fabio Estevam <festevam@gmail.com>
+
+properties:
+ compatible:
+ enum:
+ - usb424,2412
+ - usb424,2514
+ - usb424,2417
+
+ reg: true
+
+ reset-gpios:
+ description: GPIO connected to the RESET_N pin.
+
+ vdd-supply:
+ description: 3.3V power supply.
+
+ clocks:
+ description: External 24MHz clock connected to the CLKIN pin.
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: true
+
+examples:
+ - |
+ #include <dt-bindings/clock/imx6qdl-clock.h>
+ #include <dt-bindings/gpio/gpio.h>
+
+ usb {
+ dr_mode = "host";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ hub@1 {
+ compatible = "usb424,2514";
+ reg = <1>;
+ clocks = <&clks IMX6QDL_CLK_CKO>;
+ reset-gpios = <&gpio7 12 GPIO_ACTIVE_LOW>;
+ vdd-supply = <®_3v3_hub>;
+ };
+ };
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v2] arm64: dts: ti: k3-am62p: use eFuse MAC Address for CPSW3G Port 1
From: Andrew Davis @ 2024-04-04 16:28 UTC (permalink / raw)
To: Krzysztof Kozlowski, Siddharth Vadapalli
Cc: nm, vigneshr, kristo, robh, krzk+dt, conor+dt, devicetree,
linux-kernel, linux-arm-kernel, srk
In-Reply-To: <903ad855-ab26-4ef3-80bd-249917056188@linaro.org>
On 4/4/24 5:00 AM, Krzysztof Kozlowski wrote:
> On 04/04/2024 11:12, Siddharth Vadapalli wrote:
>> On Thu, Apr 04, 2024 at 10:43:04AM +0200, Krzysztof Kozlowski wrote:
>>> On 04/04/2024 10:18, Siddharth Vadapalli wrote:
>>>> Add the "cpsw-mac-efuse" node within "wkup_conf" node corresponding to the
>>>> CTRLMMR_MAC_IDx registers within the CTRL_MMR space. Assign the compatible
>>>> "ti,am62p-cpsw-mac-efuse" to enable "syscon_regmap" operations on these
>>>> registers. The MAC Address programmed in the eFuse is accessible through
>>>> the CTRLMMR_MAC_IDx registers. The "ti,syscon-efuse" device-tree property
>>>> points to the CTRLMMR_MAC_IDx registers, allowing the CPSW driver to fetch
>>>> the MAC Address and assign it to the network interface associated with
>>>> CPSW3G MAC Port 1.
>>>>
>>>> Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
>>>> ---
>>>>
>>>> This patch is based on linux-next tagged next-20240404.
>>>> Patch depends on:
>>>> https://patchwork.kernel.org/project/linux-arm-kernel/patch/20240402105708.4114146-1-s-vadapalli@ti.com/
>>>> for the newly added "ti,am62p-cpsw-mac-efuse" compatible.
>>>>
>>>> v1:
>>>> https://patchwork.kernel.org/project/linux-arm-kernel/patch/20240402094200.4036076-1-s-vadapalli@ti.com/
>>>> Changes since v1:
>>>> - Since "wkup_conf" is modelled as a "simple-bus" rather than being
>>>
>>> And maybe the hardware representation is not correct? What bus is it?
>>
>> I will let Andrew comment on it. Andrew had posted a patch at:
>> https://lore.kernel.org/r/20240124184722.150615-10-afd@ti.com/
>> to convert an equivalent "main_conf" node for AM62 SoC to "simple-bus"
>> from the existing "syscon".
>>
>>>
>>>> modelled as a System Controller node with the "syscon" compatible,
>>>> directly passing the reference to the "wkup_conf" node using the
>>>> "ti,syscon-efuse" device-tree property will not work.
>>>> Therefore, I posted the patch at:
>>>> https://patchwork.kernel.org/project/linux-arm-kernel/patch/20240402105708.4114146-1-s-vadapalli@ti.com/
>>>> in order to add a new compatible to be used for modelling the
>>>> CTRLMMR_MAC_IDx registers as System Controller nodes, thereby
>>>> allowing the existing "ti,syscon-efuse" property to be used.
>>>> Now, "ti,syscon-efuse" points to the "cpsw_mac_efuse" node within
>>>> "wkup_conf" node, with "cpsw_mac_efuse" being a "syscon" node.
>>>>
>>>> Logs verifying that the CPSW driver assigns the MAC Address from the
>>>> eFuse based on the CTRLMMR_MAC_IDx registers at 0x43000200 and 0x43000204
>>>> to the interface eth0 corresponding to CPSW3G MAC Port 1:
>>>> https://gist.github.com/Siddharth-Vadapalli-at-TI/9982c6f13bf9b8cfaf97e8517e7dea13
>>>>
>>>> Regards,
>>>> Siddharth.
>>>>
>>>> arch/arm64/boot/dts/ti/k3-am62p-main.dtsi | 1 +
>>>> arch/arm64/boot/dts/ti/k3-am62p-wakeup.dtsi | 5 +++++
>>>> 2 files changed, 6 insertions(+)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/ti/k3-am62p-main.dtsi b/arch/arm64/boot/dts/ti/k3-am62p-main.dtsi
>>>> index 7337a9e13535..848ca454a411 100644
>>>> --- a/arch/arm64/boot/dts/ti/k3-am62p-main.dtsi
>>>> +++ b/arch/arm64/boot/dts/ti/k3-am62p-main.dtsi
>>>> @@ -696,6 +696,7 @@ cpsw_port1: port@1 {
>>>> label = "port1";
>>>> phys = <&phy_gmii_sel 1>;
>>>> mac-address = [00 00 00 00 00 00];
>>>> + ti,syscon-efuse = <&cpsw_mac_efuse 0x0>;
>>>
>>> Why this is not nvmem cell, like or efuses?
>>
>> Since it belongs to the MMIO register set. You had recommended *not*
>> using nvmem for such MMIO registers at:
>> https://lore.kernel.org/r/48902771-5d3b-448a-8a74-ac18fb4f1a86@linaro.org/
>> "nvmem is for non-volatile memory, like OCOTP and eFUSE. This is not for
>> accessing regular MMIO registers of system-controller..."
>>
>> Despite the "ti,syscon-efuse" property containing the term "efuse" in its
>> name, it is reading the CTRLMMR_MAC_IDx MMIO registers. So I assumed that
>> the existing approach which has been used on all K3 SoCs apart from this
>> one, will be suitable for this SoC as well.
>
> OK, I totally forgot we discussed this.
>
Discussed but never finalized, here is the last message[0] but with
no response.
You even asked above, "Why this is not nvmem cell", you should trust
your instincts, this *should* be a NVMEM cell. That is how everyone else
handles eFused MACs, no clue why you want us to use syscon?? We would
have no way forward in removing all our DT check warnings with syscon.
Syscon is a hacky dead-end filled with custom compatible strings like
"ti,am62p-cpsw-mac-efuse" and custom properties like "ti,syscon-efuse".
NVMEM is a standard, forcing us to use TI custom syscon properties will
prevent our DT from working on anything other than Linux (unless we go
manually add support for every TI custom property to every DT using SW,
defeats the whole purpose DT).
Andrew
[0] https://lore.kernel.org/all/e7114cb4-e24f-4e78-a89f-4e2e2e704b8a@ti.com/
>>
>>>
>>>> };
>>>>
>>>> cpsw_port2: port@2 {
>>>> diff --git a/arch/arm64/boot/dts/ti/k3-am62p-wakeup.dtsi b/arch/arm64/boot/dts/ti/k3-am62p-wakeup.dtsi
>>>> index a84756c336d0..df9d40f64e3b 100644
>>>> --- a/arch/arm64/boot/dts/ti/k3-am62p-wakeup.dtsi
>>>> +++ b/arch/arm64/boot/dts/ti/k3-am62p-wakeup.dtsi
>>>> @@ -18,6 +18,11 @@ chipid: chipid@14 {
>>>> reg = <0x14 0x4>;
>>>> bootph-all;
>>>> };
>>>> +
>>>> + cpsw_mac_efuse: cpsw-mac-efuse@200 {
>>>
>>> Node names should be generic. See also an explanation and list of
>>> examples (not exhaustive) in DT specification:
>>> https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#generic-names-recommendation
>>
>> I was following the convention that other mfd-syscon compatible nodes
>> seemed to be using:
>> https://github.com/torvalds/linux/blob/41bccc98fb7931d63d03f326a746ac4d429c1dd3/arch/arm64/boot/dts/ti/k3-am65-main.dtsi#L502
>> The node is:
>> dss_oldi_io_ctrl: dss-oldi-io-ctrl@41e0
>> corresponding to the compatible:
>> "ti,am654-dss-oldi-io-ctrl"
>> which was added by commit:
>> https://github.com/torvalds/linux/commit/cb523495ee2a5938fbdd30b8a35094d386c55c12
>
> So if that one was wrong, then what? I don't know really what type of
> device is it, but just because one contributor called it that way, does
> not mean you should keep going. Maybe investigate why that contributor
> did not decide to follow Devicetree spec recommendation?
>
> Best regards,
> Krzysztof
>
^ permalink raw reply
* [PATCH 1/1] arm64: dts: imx8qxp-mek: add cm40_i2c, wm8960/wm8962 and sai[0,1,4,5]
From: Frank Li @ 2024-04-04 16:19 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
open list
imx8qxp-mek use two kind audio codec, wm8960 and wm8962. Using dummy gpio
i2c bus mux to connect both i2c devices. One will probe failure and other
will probe success when devices driver check whoami. So one dtb can cover
both board configuration.
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
arch/arm64/boot/dts/freescale/imx8qxp-mek.dts | 210 ++++++++++++++++++
1 file changed, 210 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts b/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts
index 8360bb851ac03..adff87c7cf305 100644
--- a/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts
+++ b/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts
@@ -30,6 +30,13 @@ reg_usdhc2_vmmc: usdhc2-vmmc {
enable-active-high;
};
+ reg_audio: regulator-wm8962 {
+ compatible = "regulator-fixed";
+ regulator-name = "3v3_aud";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
gpio-sbu-mux {
compatible = "nxp,cbdtu02043", "gpio-sbu-mux";
pinctrl-names = "default";
@@ -44,6 +51,105 @@ usb3_data_ss: endpoint {
};
};
};
+
+ sound-wm8960 {
+ compatible = "fsl,imx-audio-wm8960";
+ model = "wm8960-audio";
+ audio-cpu = <&sai1>;
+ audio-codec = <&wm8960>;
+ hp-det-gpio = <&lsio_gpio1 0 GPIO_ACTIVE_HIGH>;
+ audio-routing =
+ "Headphone Jack", "HP_L",
+ "Headphone Jack", "HP_R",
+ "Ext Spk", "SPK_LP",
+ "Ext Spk", "SPK_LN",
+ "Ext Spk", "SPK_RP",
+ "Ext Spk", "SPK_RN",
+ "LINPUT1", "Mic Jack",
+ "Mic Jack", "MICB";
+ };
+
+ sound-wm8962 {
+ compatible = "fsl,imx-audio-wm8962";
+ model = "wm8962-audio";
+ audio-cpu = <&sai1>;
+ audio-codec = <&wm8962>;
+ hp-det-gpio = <&lsio_gpio1 0 GPIO_ACTIVE_HIGH>;
+ audio-routing =
+ "Headphone Jack", "HPOUTL",
+ "Headphone Jack", "HPOUTR",
+ "Ext Spk", "SPKOUTL",
+ "Ext Spk", "SPKOUTR",
+ "AMIC", "MICBIAS",
+ "IN3R", "AMIC",
+ "IN1R", "AMIC";
+ };
+
+ /*
+ * This dummy i2c mux. GPIO actually will not impact selection. At actual boards, only 1
+ * device connectted. I2C client driver will check ID when probe. Only matched ID's driver
+ * probe successfully.
+ */
+ i2cvmux: i2cmux {
+ compatible = "i2c-mux-gpio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ mux-gpios = <&lsio_gpio5 0 GPIO_ACTIVE_HIGH>; /* use an unused gpio */
+ i2c-parent = <&cm40_i2c>;
+
+ i2c@0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* WCPU boards SCH-54536 */
+ wm8962: wm8962@1a {
+ compatible = "wlf,wm8962";
+ reg = <0x1a>;
+ clocks = <&mclkout0_lpcg IMX_LPCG_CLK_0>;
+ assigned-clocks = <&clk IMX_SC_R_AUDIO_PLL_0 IMX_SC_PM_CLK_PLL>,
+ <&clk IMX_SC_R_AUDIO_PLL_0 IMX_SC_PM_CLK_SLV_BUS>,
+ <&clk IMX_SC_R_AUDIO_PLL_0 IMX_SC_PM_CLK_MST_BUS>,
+ <&mclkout0_lpcg IMX_LPCG_CLK_0>;
+ assigned-clock-rates = <786432000>,
+ <49152000>,
+ <12288000>,
+ <12288000>;
+ DCVDD-supply = <®_audio>;
+ DBVDD-supply = <®_audio>;
+ AVDD-supply = <®_audio>;
+ CPVDD-supply = <®_audio>;
+ MICVDD-supply = <®_audio>;
+ PLLVDD-supply = <®_audio>;
+ SPKVDD1-supply = <®_audio>;
+ SPKVDD2-supply = <®_audio>;
+ };
+ };
+
+ i2c@1 {
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ wm8960: wm8960@1a {
+ compatible = "wlf,wm8960";
+ reg = <0x1a>;
+ clocks = <&mclkout0_lpcg IMX_LPCG_CLK_0>;
+ clock-names = "mclk";
+ wlf,shared-lrclk;
+ wlf,hp-cfg = <2 2 3>;
+ wlf,gpio-cfg = <1 3>;
+ assigned-clocks = <&clk IMX_SC_R_AUDIO_PLL_0 IMX_SC_PM_CLK_PLL>,
+ <&clk IMX_SC_R_AUDIO_PLL_0 IMX_SC_PM_CLK_SLV_BUS>,
+ <&clk IMX_SC_R_AUDIO_PLL_0 IMX_SC_PM_CLK_MST_BUS>,
+ <&mclkout0_lpcg IMX_LPCG_CLK_0>;
+ assigned-clock-rates = <786432000>,
+ <49152000>,
+ <12288000>,
+ <12288000>;
+ };
+ };
+ };
};
&dsp {
@@ -188,6 +294,29 @@ typec_con_ss: endpoint {
};
+&cm40_i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clock-frequency = <100000>;
+ pinctrl-names = "default", "gpio";
+ pinctrl-0 = <&pinctrl_cm40_i2c>;
+ pinctrl-1 = <&pinctrl_cm40_i2c_gpio>;
+ scl-gpios = <&lsio_gpio1 10 GPIO_ACTIVE_HIGH>;
+ sda-gpios = <&lsio_gpio1 9 GPIO_ACTIVE_HIGH>;
+ status = "okay";
+
+ pca6416: gpio@20 {
+ compatible = "ti,tca6416";
+ reg = <0x20>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+};
+
+&cm40_intmux {
+ status = "okay";
+};
+
&lpuart0 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_lpuart0>;
@@ -218,6 +347,53 @@ &scu_key {
status = "okay";
};
+&sai0 {
+ #sound-dai-cells = <0>;
+ assigned-clocks = <&clk IMX_SC_R_AUDIO_PLL_0 IMX_SC_PM_CLK_PLL>,
+ <&clk IMX_SC_R_AUDIO_PLL_0 IMX_SC_PM_CLK_SLV_BUS>,
+ <&clk IMX_SC_R_AUDIO_PLL_0 IMX_SC_PM_CLK_MST_BUS>,
+ <&sai0_lpcg IMX_LPCG_CLK_0>;
+ assigned-clock-rates = <786432000>, <49152000>, <12288000>, <49152000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_sai0>;
+ status = "okay";
+};
+
+&sai1 {
+ assigned-clocks = <&clk IMX_SC_R_AUDIO_PLL_0 IMX_SC_PM_CLK_PLL>,
+ <&clk IMX_SC_R_AUDIO_PLL_0 IMX_SC_PM_CLK_SLV_BUS>,
+ <&clk IMX_SC_R_AUDIO_PLL_0 IMX_SC_PM_CLK_MST_BUS>,
+ <&sai1_lpcg IMX_LPCG_CLK_0>;
+ assigned-clock-rates = <786432000>, <49152000>, <12288000>, <49152000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_sai1>;
+ status = "okay";
+};
+
+&sai4 {
+ assigned-clocks = <&acm IMX_ADMA_ACM_SAI4_MCLK_SEL>,
+ <&clk IMX_SC_R_AUDIO_PLL_1 IMX_SC_PM_CLK_PLL>,
+ <&clk IMX_SC_R_AUDIO_PLL_1 IMX_SC_PM_CLK_SLV_BUS>,
+ <&clk IMX_SC_R_AUDIO_PLL_1 IMX_SC_PM_CLK_MST_BUS>,
+ <&sai4_lpcg IMX_LPCG_CLK_0>;
+ assigned-clock-parents = <&aud_pll_div1_lpcg IMX_LPCG_CLK_0>;
+ assigned-clock-rates = <0>, <786432000>, <98304000>, <12288000>, <98304000>;
+ fsl,sai-asynchronous;
+ status = "okay";
+};
+
+&sai5 {
+ assigned-clocks = <&acm IMX_ADMA_ACM_SAI5_MCLK_SEL>,
+ <&clk IMX_SC_R_AUDIO_PLL_1 IMX_SC_PM_CLK_PLL>,
+ <&clk IMX_SC_R_AUDIO_PLL_1 IMX_SC_PM_CLK_SLV_BUS>,
+ <&clk IMX_SC_R_AUDIO_PLL_1 IMX_SC_PM_CLK_MST_BUS>,
+ <&sai5_lpcg IMX_LPCG_CLK_0>;
+ assigned-clock-parents = <&aud_pll_div1_lpcg IMX_LPCG_CLK_0>;
+ assigned-clock-rates = <0>, <786432000>, <98304000>, <12288000>, <98304000>;
+ fsl,sai-asynchronous;
+ status = "okay";
+};
+
&thermal_zones {
pmic-thermal {
polling-delay-passive = <250>;
@@ -314,6 +490,21 @@ &vpu_core1 {
};
&iomuxc {
+
+ pinctrl_cm40_i2c: cm40i2cgrp {
+ fsl,pins = <
+ IMX8QXP_ADC_IN1_M40_I2C0_SDA 0x0600004c
+ IMX8QXP_ADC_IN0_M40_I2C0_SCL 0x0600004c
+ >;
+ };
+
+ pinctrl_cm40_i2c_gpio: cm40i2cgpio-grp {
+ fsl,pins = <
+ IMX8QXP_ADC_IN1_LSIO_GPIO1_IO09 0xc600004c
+ IMX8QXP_ADC_IN0_LSIO_GPIO1_IO10 0xc600004c
+ >;
+ };
+
pinctrl_fec1: fec1grp {
fsl,pins = <
IMX8QXP_ENET0_MDC_CONN_ENET0_MDC 0x06000020
@@ -385,6 +576,25 @@ IMX8QXP_ENET0_REFCLK_125M_25M_LSIO_GPIO5_IO09 0x60
>;
};
+ pinctrl_sai0: sai0grp {
+ fsl,pins = <
+ IMX8QXP_SAI0_TXD_ADMA_SAI0_TXD 0x06000060
+ IMX8QXP_SAI0_RXD_ADMA_SAI0_RXD 0x06000040
+ IMX8QXP_SAI0_TXC_ADMA_SAI0_TXC 0x06000040
+ IMX8QXP_SAI0_TXFS_ADMA_SAI0_TXFS 0x06000040
+ >;
+ };
+
+ pinctrl_sai1: sai1grp {
+ fsl,pins = <
+ IMX8QXP_SAI1_RXD_ADMA_SAI1_RXD 0x06000040
+ IMX8QXP_SAI1_RXC_ADMA_SAI1_TXC 0x06000040
+ IMX8QXP_SAI1_RXFS_ADMA_SAI1_TXFS 0x06000040
+ IMX8QXP_SPI0_CS1_ADMA_SAI1_TXD 0x06000060
+ IMX8QXP_SPI2_CS0_LSIO_GPIO1_IO00 0x06000040
+ >;
+ };
+
pinctrl_usdhc1: usdhc1grp {
fsl,pins = <
IMX8QXP_EMMC0_CLK_CONN_EMMC0_CLK 0x06000041
--
2.34.1
^ permalink raw reply related
* [PATCH v2] dt-bindings: omap-mcpdm: Convert to DT schema
From: Mighty @ 2024-04-04 16:06 UTC (permalink / raw)
Cc: Mithil Bavishi, Liam Girdwood, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, alsa-devel, devicetree,
linux-kernel
From: Mithil Bavishi <bavishimithil@gmail.com>
Convert the OMAP4+ McPDM bindings to DT schema.
Signed-off-by: Mighty <bavishimithil@gmail.com>
---
.../devicetree/bindings/sound/omap-mcpdm.txt | 30 ----------
.../bindings/sound/ti,omap-mcpdm.yaml | 59 +++++++++++++++++++
2 files changed, 59 insertions(+), 30 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/sound/omap-mcpdm.txt
create mode 100644 Documentation/devicetree/bindings/sound/ti,omap-mcpdm.yaml
diff --git a/Documentation/devicetree/bindings/sound/omap-mcpdm.txt b/Documentation/devicetree/bindings/sound/omap-mcpdm.txt
deleted file mode 100644
index ff98a0cb5..000000000
--- a/Documentation/devicetree/bindings/sound/omap-mcpdm.txt
+++ /dev/null
@@ -1,30 +0,0 @@
-* Texas Instruments OMAP4+ McPDM
-
-Required properties:
-- compatible: "ti,omap4-mcpdm"
-- reg: Register location and size as an array:
- <MPU access base address, size>,
- <L3 interconnect address, size>;
-- interrupts: Interrupt number for McPDM
-- ti,hwmods: Name of the hwmod associated to the McPDM
-- clocks: phandle for the pdmclk provider, likely <&twl6040>
-- clock-names: Must be "pdmclk"
-
-Example:
-
-mcpdm: mcpdm@40132000 {
- compatible = "ti,omap4-mcpdm";
- reg = <0x40132000 0x7f>, /* MPU private access */
- <0x49032000 0x7f>; /* L3 Interconnect */
- interrupts = <0 112 0x4>;
- interrupt-parent = <&gic>;
- ti,hwmods = "mcpdm";
-};
-
-In board DTS file the pdmclk needs to be added:
-
-&mcpdm {
- clocks = <&twl6040>;
- clock-names = "pdmclk";
- status = "okay";
-};
diff --git a/Documentation/devicetree/bindings/sound/ti,omap-mcpdm.yaml b/Documentation/devicetree/bindings/sound/ti,omap-mcpdm.yaml
new file mode 100644
index 000000000..4d5d37e98
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/ti,omap-mcpdm.yaml
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/ti,omap-mcpdm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: OMAP McPDM
+
+maintainers:
+ - Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+
+description:
+ OMAP ALSA SoC DAI driver using McPDM port used by TWL6040
+
+properties:
+ compatible:
+ const: ti,omap4-mcpdm
+
+ reg:
+ description:
+ Register location and size as an array
+ <MPU access base address, size>,
+ <L3 interconnect address, size>;
+
+ interrupts:
+ maxItems: 1
+
+ ti,hwmods:
+ maxItems: 1
+
+ clocks:
+ description: phandle for the pdmclk provider, likely <&twl6040>
+
+ clock-names:
+ description: Must be "pdmclk"
+
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - ti,hwmods
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+ mcpdm@0 {
+ compatible = "ti,omap4-mcpdm";
+ reg = <0x40132000 0x7f>, /* MPU private access */
+ <0x49032000 0x7f>; /* L3 Interconnect */
+ interrupts = <0 112 0x4>;
+ interrupt-parent = <&gic>;
+ ti,hwmods = "mcpdm";
+ clocks = <&twl6040>;
+ clock-names = "pdmclk";
+ };
--
2.34.1
^ permalink raw reply related
* Re: [PATCH V2 RESEND 6/6] arm64: dts: qcom: sm8650: Add video and camera clock controllers
From: Dmitry Baryshkov @ 2024-04-04 16:05 UTC (permalink / raw)
To: Jagadeesh Kona
Cc: Bjorn Andersson, Konrad Dybcio, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Vladimir Zapolskiy, linux-arm-msm, linux-clk, devicetree,
linux-kernel, Taniya Das, Satya Priya Kakitapalli, Ajit Pandey,
Imran Shaik
In-Reply-To: <8a5a3cf8-5b4f-487f-ad91-00499509f8ec@quicinc.com>
On Thu, 4 Apr 2024 at 13:06, Jagadeesh Kona <quic_jkona@quicinc.com> wrote:
>
>
>
> On 4/4/2024 11:00 AM, Dmitry Baryshkov wrote:
> > On Thu, 4 Apr 2024 at 08:13, Jagadeesh Kona <quic_jkona@quicinc.com> wrote:
> >>
> >>
> >>
> >> On 4/3/2024 9:24 PM, Dmitry Baryshkov wrote:
> >>> On Wed, 3 Apr 2024 at 10:16, Jagadeesh Kona <quic_jkona@quicinc.com> wrote:
> >>>>
> >>>>
> >>>>
> >>>> On 3/25/2024 11:38 AM, Jagadeesh Kona wrote:
> >>>>>
> >>>>>
> >>>>> On 3/21/2024 6:43 PM, Dmitry Baryshkov wrote:
> >>>>>> On Thu, 21 Mar 2024 at 11:27, Jagadeesh Kona <quic_jkona@quicinc.com>
> >>>>>> wrote:
> >>>>>>>
> >>>>>>> Add device nodes for video and camera clock controllers on Qualcomm
> >>>>>>> SM8650 platform.
> >>>>>>>
> >>>>>>> Signed-off-by: Jagadeesh Kona <quic_jkona@quicinc.com>
> >>>>>>> ---
> >>>>>>> arch/arm64/boot/dts/qcom/sm8650.dtsi | 28 ++++++++++++++++++++++++++++
> >>>>>>> 1 file changed, 28 insertions(+)
> >>>>>>>
> >>>>>>> diff --git a/arch/arm64/boot/dts/qcom/sm8650.dtsi
> >>>>>>> b/arch/arm64/boot/dts/qcom/sm8650.dtsi
> >>>>>>> index 32c0a7b9aded..d862aa6be824 100644
> >>>>>>> --- a/arch/arm64/boot/dts/qcom/sm8650.dtsi
> >>>>>>> +++ b/arch/arm64/boot/dts/qcom/sm8650.dtsi
> >>>>>>> @@ -4,6 +4,8 @@
> >>>>>>> */
> >>>>>>>
> >>>>>>> #include <dt-bindings/clock/qcom,rpmh.h>
> >>>>>>> +#include <dt-bindings/clock/qcom,sm8450-videocc.h>
> >>>>>>> +#include <dt-bindings/clock/qcom,sm8650-camcc.h>
> >>>>>>> #include <dt-bindings/clock/qcom,sm8650-dispcc.h>
> >>>>>>> #include <dt-bindings/clock/qcom,sm8650-gcc.h>
> >>>>>>> #include <dt-bindings/clock/qcom,sm8650-gpucc.h>
> >>>>>>> @@ -3110,6 +3112,32 @@ opp-202000000 {
> >>>>>>> };
> >>>>>>> };
> >>>>>>>
> >>>>>>> + videocc: clock-controller@aaf0000 {
> >>>>>>> + compatible = "qcom,sm8650-videocc";
> >>>>>>> + reg = <0 0x0aaf0000 0 0x10000>;
> >>>>>>> + clocks = <&bi_tcxo_div2>,
> >>>>>>> + <&gcc GCC_VIDEO_AHB_CLK>;
> >>>>>>> + power-domains = <&rpmhpd RPMHPD_MMCX>;
> >>>>>>> + required-opps = <&rpmhpd_opp_low_svs>;
> >>>>>>
> >>>>>> The required-opps should no longer be necessary.
> >>>>>>
> >>>>>
> >>>>> Sure, will check and remove this if not required.
> >>>>
> >>>>
> >>>> I checked further on this and without required-opps, if there is no vote
> >>>> on the power-domain & its peer from any other consumers, when runtime
> >>>> get is called on device, it enables the power domain just at the minimum
> >>>> non-zero level. But in some cases, the minimum non-zero level of
> >>>> power-domain could be just retention and is not sufficient for clock
> >>>> controller to operate, hence required-opps property is needed to specify
> >>>> the minimum level required on power-domain for this clock controller.
> >>>
> >>> In which cases? If it ends up with the retention vote, it is a bug
> >>> which must be fixed.
> >>>
> >>
> >> The minimum non-zero level(configured from bootloaders) of MMCX is
> >> retention on few chipsets but it can vary across the chipsets. Hence to
> >> be on safer side from our end, it is good to have required-opps in DT to
> >> specify the minimum level required for this clock controller.
> >
> > We are discussing sm8650, not some abstract chipset. Does it list
> > retention or low_svs as a minimal level for MMCX?
> >
>
> Actually, the minimum level for MMCX is external to the clock
> controllers.
Yes, it comes from cmd-db
> But the clock controller requires MMCX to be atleast at
> lowsvs for it to be functional.
Correct
> Hence we need to keep required-opps to
> ensure the same without relying on the actual minimum level for MMCX.
And this is not correct. There is no need for the DT to be redundant.
I plan to send patches removing the existing required-opps when they
are not required.
--
With best wishes
Dmitry
^ 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