* [PATCH 1/1] arm64: dts: imx8mp: Enable HDMI on TQMa8MPxL/MBa8MPxL
From: Alexander Stein @ 2024-04-10 6:37 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: Alexander Stein, linux, devicetree, imx, linux-arm-kernel,
linux-kernel
Enable HDMI nodes and add the output connector.
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
---
.../freescale/imx8mp-tqma8mpql-mba8mpxl.dts | 38 +++++++++++++++++++
1 file changed, 38 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpql-mba8mpxl.dts b/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpql-mba8mpxl.dts
index 86d3da36e4f3e..c51ed7d991d18 100644
--- a/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpql-mba8mpxl.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpql-mba8mpxl.dts
@@ -135,6 +135,18 @@ led-2 {
};
};
+ hdmi-connector {
+ compatible = "hdmi-connector";
+ label = "X44";
+ type = "a";
+
+ port {
+ hdmi_connector_in: endpoint {
+ remote-endpoint = <&hdmi_tx_out>;
+ };
+ };
+ };
+
display: display {
/*
* Display is not fixed, so compatible has to be added from
@@ -470,6 +482,28 @@ &gpio5 {
"", "", "", "";
};
+&hdmi_pvi {
+ status = "okay";
+};
+
+&hdmi_tx {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hdmi>;
+ status = "okay";
+
+ ports {
+ port@1 {
+ hdmi_tx_out: endpoint {
+ remote-endpoint = <&hdmi_connector_in>;
+ };
+ };
+ };
+};
+
+&hdmi_tx_phy {
+ status = "okay";
+};
+
&i2c2 {
clock-frequency = <384000>;
pinctrl-names = "default", "gpio";
@@ -531,6 +565,10 @@ &i2c6 {
status = "okay";
};
+&lcdif3 {
+ status = "okay";
+};
+
&pcf85063 {
/* RTC_EVENT# is connected on MBa8MPxL */
pinctrl-names = "default";
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v2 1/1] arm64: dts: imx93-11x11-evk: add rtc PCF2131 support
From: Krzysztof Kozlowski @ 2024-04-10 6:34 UTC (permalink / raw)
To: Joy Zou, ping.bai, robh+dt, krzysztof.kozlowski+dt, conor+dt,
shawnguo, s.hauer
Cc: kernel, festevam, linux-imx, devicetree, imx, linux-arm-kernel,
linux-kernel
In-Reply-To: <20240410033256.1341662-2-joy.zou@nxp.com>
On 10/04/2024 05:32, Joy Zou wrote:
> Support rtc PCF2131 on imx93-11x11-evk.
>
> Signed-off-by: Joy Zou <joy.zou@nxp.com>
> ---
> Changes in v2:
> 1. remove unnecessary status property.
> ---
> .../boot/dts/freescale/imx93-11x11-evk.dts | 24 +++++++++++++++++++
> 1 file changed, 24 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/freescale/imx93-11x11-evk.dts b/arch/arm64/boot/dts/freescale/imx93-11x11-evk.dts
> index 07e85a30a25f..e66723ed25c2 100644
> --- a/arch/arm64/boot/dts/freescale/imx93-11x11-evk.dts
> +++ b/arch/arm64/boot/dts/freescale/imx93-11x11-evk.dts
> @@ -281,6 +281,23 @@ ldo5: LDO5 {
> };
> };
>
> +&lpi2c3 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + clock-frequency = <400000>;
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <&pinctrl_lpi2c3>;
> + pinctrl-1 = <&pinctrl_lpi2c3>;
> + status = "okay";
> +
> + pcf2131: rtc@53 {
> + compatible = "nxp,pcf2131";
> + reg = <0x53>;
> + interrupt-parent = <&pcal6524>;
> + interrupts = <1 IRQ_TYPE_EDGE_FALLING>;
Fix indentation.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: dma: fsl-edma: remove 'clocks' from required
From: Krzysztof Kozlowski @ 2024-04-10 6:32 UTC (permalink / raw)
To: Frank Li
Cc: conor+dt, devicetree, dmaengine, imx, krzysztof.kozlowski+dt,
linux-kernel, peng.fan, robh, vkoul
In-Reply-To: <680f8830-6cd8-433b-85b7-439070bc528f@linaro.org>
On 10/04/2024 08:30, Krzysztof Kozlowski wrote:
> On 09/04/2024 23:09, Frank Li wrote:
>> On Tue, Apr 09, 2024 at 10:02:32PM +0200, Krzysztof Kozlowski wrote:
>>> On 09/04/2024 20:54, Frank Li wrote:
>>>> fsl,imx8qm-adma and fsl,imx8qm-edma don't require 'clocks'. Remove it from
>>>> required and add 'if' block for other compatible string to keep the same
>>>> restrictions.
>>>>
>>>> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
>>>> Signed-off-by: Frank Li <Frank.Li@nxp.com>
>>>> ---
>>>>
>>>> Notes:
>>>> Change from v2 to v3
>>>> - rebase to dmaengine/next
>>>
>>> This fails...
>>
>> What's wrong?
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/vkoul/dmaengine.git/log/?h=next
>>
>>>
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/dma/fsl,edma.yaml b/Documentation/devicetree/bindings/dma/fsl,edma.yaml
>>>> index 825f4715499e5..657a7d3ebf857 100644
>>>> --- a/Documentation/devicetree/bindings/dma/fsl,edma.yaml
>>>> +++ b/Documentation/devicetree/bindings/dma/fsl,edma.yaml
>>>> @@ -82,7 +82,6 @@ required:
>>>> - compatible
>>>> - reg
>>>> - interrupts
>>>> - - clocks
>>>> - dma-channels
>>>>
>>>> allOf:
>>>> @@ -187,6 +186,22 @@ allOf:
>>>> "#dma-cells":
>>>> const: 3
>>>>
>>>> + - if:
>>>> + properties:
>>>> + compatible:
>>>> + contains:
>>>
>>> It does not look like you tested the bindings, at least after quick
>>> look. Please run `make dt_binding_check` (see
>>> Documentation/devicetree/bindings/writing-schema.rst for instructions).
>>> Maybe you need to update your dtschema and yamllint.
>>
>> Strange, Test passed
>>
>> make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j8 dt_binding_check DT_SCHEMA_FILES=fsl,edma.yaml
>> LINT Documentation/devicetree/bindings
>> DTEX Documentation/devicetree/bindings/dma/fsl,edma.example.dts
>> CHKDT Documentation/devicetree/bindings/processed-schema.json
>> SCHEMA Documentation/devicetree/bindings/processed-schema.json
>> DTC_CHK Documentation/devicetree/bindings/dma/fsl,edma.example.dtb
>
> Nope, you tested other patch. Just look at your second patch for this.
> When reviewer points to errors to your code, please investigate?
>
> NAK, fix your patches.
And to prove it, so you will stop wasting my time:
../Documentation/devicetree/bindings/dma/fsl,edma.yaml:192:1: found
character that cannot start any token
../Documentation/devicetree/bindings/dma/fsl,edma.yaml:192:1: [error]
syntax error: found character '\t' that cannot start any token (syntax)
../Documentation/devicetree/bindings/dma/fsl,edma.yaml:192:1: found
character that cannot start any token
Documentation/devicetree/bindings/dma/fsl,edma.yaml: ignoring, error
parsing file
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: dma: fsl-edma: remove 'clocks' from required
From: Krzysztof Kozlowski @ 2024-04-10 6:30 UTC (permalink / raw)
To: Frank Li
Cc: conor+dt, devicetree, dmaengine, imx, krzysztof.kozlowski+dt,
linux-kernel, peng.fan, robh, vkoul
In-Reply-To: <ZhWuetC8bRvDyxgX@lizhi-Precision-Tower-5810>
On 09/04/2024 23:09, Frank Li wrote:
> On Tue, Apr 09, 2024 at 10:02:32PM +0200, Krzysztof Kozlowski wrote:
>> On 09/04/2024 20:54, Frank Li wrote:
>>> fsl,imx8qm-adma and fsl,imx8qm-edma don't require 'clocks'. Remove it from
>>> required and add 'if' block for other compatible string to keep the same
>>> restrictions.
>>>
>>> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
>>> Signed-off-by: Frank Li <Frank.Li@nxp.com>
>>> ---
>>>
>>> Notes:
>>> Change from v2 to v3
>>> - rebase to dmaengine/next
>>
>> This fails...
>
> What's wrong?
>
> https://git.kernel.org/pub/scm/linux/kernel/git/vkoul/dmaengine.git/log/?h=next
>
>>
>>>
>>> diff --git a/Documentation/devicetree/bindings/dma/fsl,edma.yaml b/Documentation/devicetree/bindings/dma/fsl,edma.yaml
>>> index 825f4715499e5..657a7d3ebf857 100644
>>> --- a/Documentation/devicetree/bindings/dma/fsl,edma.yaml
>>> +++ b/Documentation/devicetree/bindings/dma/fsl,edma.yaml
>>> @@ -82,7 +82,6 @@ required:
>>> - compatible
>>> - reg
>>> - interrupts
>>> - - clocks
>>> - dma-channels
>>>
>>> allOf:
>>> @@ -187,6 +186,22 @@ allOf:
>>> "#dma-cells":
>>> const: 3
>>>
>>> + - if:
>>> + properties:
>>> + compatible:
>>> + contains:
>>
>> It does not look like you tested the bindings, at least after quick
>> look. Please run `make dt_binding_check` (see
>> Documentation/devicetree/bindings/writing-schema.rst for instructions).
>> Maybe you need to update your dtschema and yamllint.
>
> Strange, Test passed
>
> make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j8 dt_binding_check DT_SCHEMA_FILES=fsl,edma.yaml
> LINT Documentation/devicetree/bindings
> DTEX Documentation/devicetree/bindings/dma/fsl,edma.example.dts
> CHKDT Documentation/devicetree/bindings/processed-schema.json
> SCHEMA Documentation/devicetree/bindings/processed-schema.json
> DTC_CHK Documentation/devicetree/bindings/dma/fsl,edma.example.dtb
Nope, you tested other patch. Just look at your second patch for this.
When reviewer points to errors to your code, please investigate?
NAK, fix your patches.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [RFC PATCH 2/2] PCI: Add Qualcomm PCIe ECAM root complex driver
From: Manivannan Sadhasivam @ 2024-04-10 6:26 UTC (permalink / raw)
To: Mayank Rana
Cc: linux-pci, lpieralisi, kw, robh, bhelgaas, andersson,
krzysztof.kozlowski+dt, conor+dt, devicetree, linux-arm-msm,
quic_ramkri, quic_nkela, quic_shazhuss, quic_msarkar,
quic_nitegupt
In-Reply-To: <0b738556-0042-43ab-80f2-d78ed3b432f7@quicinc.com>
On Mon, Apr 08, 2024 at 11:57:58AM -0700, Mayank Rana wrote:
> Hi Mani
>
> On 4/5/2024 9:17 PM, Manivannan Sadhasivam wrote:
> > On Fri, Apr 05, 2024 at 10:41:15AM -0700, Mayank Rana wrote:
> > > Hi Mani
> > >
> > > On 4/4/2024 10:30 PM, Manivannan Sadhasivam wrote:
> > > > On Thu, Apr 04, 2024 at 12:11:24PM -0700, Mayank Rana wrote:
> > > > > 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.
> > > > >
> > > >
> > > > Is this an in-house PCIe IP of Qualcomm or the same DWC IP that is used in other
> > > > SoCs?
> > > >
> > > > - Mani
> > > Driver is validated on SA8775p-ride platform using PCIe DWC IP for
> > > now.Although this driver doesn't need to know used PCIe controller and PHY
> > > IP as well programming sequence as that would be taken care by firmware.
> > >
> >
> > Ok, so it is the same IP but firmware is controlling the resources now. This
> > information should be present in the commit message.
> >
> > Btw, there is an existing generic ECAM host controller driver:
> > drivers/pci/controller/pci-host-generic.c
> >
> > This driver is already being used by several vendors as well. So we should try
> > to extend it for Qcom usecase also.
> I did review pci-host-generic.c driver for usage. although there are more
> functionalityneeded for use case purpose as below:
> 1. MSI functionality
> 2. Suspend/Resume
> 3. Wakeup Functionality (not part of current change, but would be added
> later)
> 4. Here this driver provides way to virtualized PCIe controller. So VMs only
> talk to a generic ECAM whereas HW is only directed accessed by service VM.
> 5. Adding more Auto based safety use cases related implementation
>
> Hence keeping pci-host-generic.c as generic driver where above functionality
> may not be needed. Also here we may add more functionality using PM runtime
> based GenPD/Power Domain with SCMI communication with firmware.
>
Ok. I think it is fine for now. But why should this driver be called
'pcie-qcom-ecam'? For sure the driver is ECAM compatible, but that's not the
only factor, right? I think it is better to call it as 'pcie-qcom-generic'. Even
though 'generic' may bring some ambiguity, I think still it is a better naming.
> > > > > 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.
> > > > >
> >
> > So is this the same internal MSI controller in the DWC IP? If so, then we
> > already have the MSI implementation in
> > drivers/pci/controller/dwc/pcie-designware-host.c and that should be reused here
> > instead of duplicating the code.
> If you are referring just MSI implementation as duplication code than I
> agree with you.
> Although proposed new driver is agnostic to specific PCIe controller related
> IP. Currently we are using PCIe DWC controller based MSI controller for MSI
> functionality using controller specific SPIs. Although I am looking into
> implementation where we can use free SPIs (there is no free SPIs available
> on SA877p-ride platform) or extended
> SPIs to use for MSI functionality so we don't need to use PCIe controller
> based MSI controller. extended SPI based MSI functionality related work is
> under progress and eventually will replace current proposed solution based
> MSI implementation. With that we would have generic enough implementation
> for MSI functionality using free SPIs/extended SPIs with this new driver.\
Ok for keeping it in the driver.
But this driver depends on the SCMI firmware design, that is still being
discussed. There should be a note in the cover letter about it.
Also, the discussion on whether to use a new compatible or a property is not yet
concluded afair. So that should also be mentioned (More importantly, this driver
should not get merged till that discussion is concluded).
I'm planning to do the code review later this week.
- Mani
> > - Mani
> >
> Regards,
> Mayank
> > > > > 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
* Re: [PATCH v5 0/3] arm64: dts: qcom: apq8016: Add Schneider HMIBSC board DTS
From: Sumit Garg @ 2024-04-10 6:24 UTC (permalink / raw)
To: andersson, konrad.dybcio
Cc: linux-arm-msm, devicetree, robh+dt, krzysztof.kozlowski+dt,
conor+dt, stephan, caleb.connolly, neil.armstrong,
dmitry.baryshkov, laetitia.mariottini, pascal.eberhard,
abdou.saker, jimmy.lalande, benjamin.missey, daniel.thompson,
linux-kernel
In-Reply-To: <20240403043416.3800259-1-sumit.garg@linaro.org>
Hi Bjorn, Konrad,
On Wed, 3 Apr 2024 at 10:04, Sumit Garg <sumit.garg@linaro.org> wrote:
>
> Add Schneider Electric HMIBSC board DTS. The HMIBSC board is an IIoT Edge
> Box Core board based on the Qualcomm APQ8016E SoC. For more information
> refer to the product page [1].
>
> One of the major difference from db410c is serial port where HMIBSC board
> uses UART1 as the debug console with a default RS232 mode (UART1 mode mux
> configured via gpio99 and gpio100).
>
> Support for Schneider Electric HMIBSC. Features:
> - Qualcomm Snapdragon 410C SoC - APQ8016 (4xCortex A53, Adreno 306)
> - 1GiB RAM
> - 8GiB eMMC, SD slot
> - WiFi and Bluetooth
> - 2x Host, 1x Device USB port
> - HDMI
> - Discrete TPM2 chip over SPI
> - USB ethernet adaptors (soldered)
>
> This series is a v2 since v1 of this DTS file has been reviewed on the
> U-Boot mailing list [2].
>
> Changes in v5:
> - Addressed another nitpick from Stephen.
> - Collected Stephen's review tag.
> - Warnings reported by Rob's DT check bot aren't related to HMIBSC
> board DTS but rather they are due to msm8916.dtsi or extcon-usb-gpio.txt
> still not converted to YAML format.
>
I haven't seen any further comments on this series, can you help to pick it up?
-Sumit
> Changes in v4:
> - Dropped IRQ_TYPE_EDGE_FALLING for pm8916_resin given the expectations
> of Linux kernel driver. Instead depend on systemd workaround suggested
> by Caleb to get expected HMIBSC reset behaviour.
> - Incorporated further DT coding style comments from Stephen.
> - Warnings reported by Rob's DT check bot aren't related to HMIBSC
> board DTS but rather they are due to msm8916.dtsi or extcon-usb-gpio.txt
> still not converted to YAML format.
>
> Changes in v3:
> - Picked up tags.
> - Fixed further DT schema warnings.
> - Configure resin/power button interrupt as falling edge.
> - Incorporate DTS coding style comments from Krzysztof and Konrad.
>
> Changes in v2:
> - Fix DT schema warnings.
> - Incorporate suggestions from Stephan.
> - Document UART1 mode GPIOs based mux.
>
> [1] https://www.se.com/us/en/product/HMIBSCEA53D1L0T/iiot-edge-box-core-harmony-ipc-emmc-dc-linux-tpm/
> [2] https://patchwork.ozlabs.org/project/uboot/patch/20240311111027.44577-6-sumit.garg@linaro.org/
>
> Sumit Garg (3):
> dt-bindings: vendor-prefixes: Add Schneider Electric
> dt-bindings: arm: qcom: Add Schneider Electric HMIBSC board
> arm64: dts: qcom: apq8016: Add Schneider HMIBSC board DTS
>
> .../devicetree/bindings/arm/qcom.yaml | 1 +
> .../devicetree/bindings/vendor-prefixes.yaml | 2 +
> arch/arm64/boot/dts/qcom/Makefile | 1 +
> .../dts/qcom/apq8016-schneider-hmibsc.dts | 491 ++++++++++++++++++
> 4 files changed, 495 insertions(+)
> create mode 100644 arch/arm64/boot/dts/qcom/apq8016-schneider-hmibsc.dts
>
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH 2/3] riscv: dts: thead: Add XuanTie TH1520 ADC device node
From: kernel test robot @ 2024-04-10 6:23 UTC (permalink / raw)
To: wefu, jszhang, guoren, conor, robh, krzysztof.kozlowski+dt,
paul.walmsley, palmer, aou, jic23, lars, andriy.shevchenko,
nuno.sa, marcelo.schmitt, bigunclemax, marius.cristea, fr0st61te,
okan.sahin, marcus.folkesson, schnelle, lee, mike.looijmans
Cc: llvm, oe-kbuild-all, linux-riscv, devicetree, linux-kernel,
linux-iio, Wei Fu
In-Reply-To: <20240329200241.4122000-3-wefu@redhat.com>
Hi,
kernel test robot noticed the following build errors:
[auto build test ERROR on jic23-iio/togreg]
[also build test ERROR on robh/for-next linus/master v6.9-rc3 next-20240409]
[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/wefu-redhat-com/drivers-iio-adc-Add-XuanTie-TH1520-ADC-driver/20240330-041029
base: https://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git togreg
patch link: https://lore.kernel.org/r/20240329200241.4122000-3-wefu%40redhat.com
patch subject: [PATCH 2/3] riscv: dts: thead: Add XuanTie TH1520 ADC device node
config: riscv-allyesconfig (https://download.01.org/0day-ci/archive/20240410/202404101407.KnrqaGoC-lkp@intel.com/config)
compiler: clang version 19.0.0git (https://github.com/llvm/llvm-project 546dc2245ffc4cccd0b05b58b7a5955e355a3b27)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240410/202404101407.KnrqaGoC-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/202404101407.KnrqaGoC-lkp@intel.com/
All errors (new ones prefixed by >>):
>> ERROR: Input tree has errors, aborting (use -f to force output)
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH v3 2/2] riscv: dts: sophgo: add initial Milk-V Duo S board support
From: michael.opdenacker @ 2024-04-10 6:22 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Chen Wang, Inochi Amaoto
Cc: Michael Opdenacker, devicetree, linux-riscv, linux-kernel
In-Reply-To: <20240410062254.2955647-1-michael.opdenacker@bootlin.com>
From: Michael Opdenacker <michael.opdenacker@bootlin.com>
This adds initial support for the Milk-V Duo S board
(https://milkv.io/duo-s), enabling the serial port and
SD card support, allowing to boot Linux to the command line.
Link: https://lore.kernel.org/linux-riscv/171266958507.1032617.9460749136730849811.robh@kernel.org/T/#t
Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
---
arch/riscv/boot/dts/sophgo/Makefile | 1 +
.../boot/dts/sophgo/sg2000-milkv-duos.dts | 39 +++++++++++++++++++
2 files changed, 40 insertions(+)
create mode 100644 arch/riscv/boot/dts/sophgo/sg2000-milkv-duos.dts
diff --git a/arch/riscv/boot/dts/sophgo/Makefile b/arch/riscv/boot/dts/sophgo/Makefile
index 57ad82a61ea6..e008acb5240f 100644
--- a/arch/riscv/boot/dts/sophgo/Makefile
+++ b/arch/riscv/boot/dts/sophgo/Makefile
@@ -1,4 +1,5 @@
# SPDX-License-Identifier: GPL-2.0
dtb-$(CONFIG_ARCH_SOPHGO) += cv1800b-milkv-duo.dtb
dtb-$(CONFIG_ARCH_SOPHGO) += cv1812h-huashan-pi.dtb
+dtb-$(CONFIG_ARCH_SOPHGO) += sg2000-milkv-duos.dtb
dtb-$(CONFIG_ARCH_SOPHGO) += sg2042-milkv-pioneer.dtb
diff --git a/arch/riscv/boot/dts/sophgo/sg2000-milkv-duos.dts b/arch/riscv/boot/dts/sophgo/sg2000-milkv-duos.dts
new file mode 100644
index 000000000000..679d2854938a
--- /dev/null
+++ b/arch/riscv/boot/dts/sophgo/sg2000-milkv-duos.dts
@@ -0,0 +1,39 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright (C) 2024 Michael Opdenacker <michael.opdenacker@bootlin.com>
+ */
+
+/dts-v1/;
+
+#include "cv1800b.dtsi"
+
+/ {
+ model = "Milk-V Duo S";
+ compatible = "milkv,duos", "sophgo,cv1800b";
+
+ aliases {
+ serial0 = &uart0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory@80000000 {
+ device_type = "memory";
+ reg = <0x80000000 0x20000000>;
+ };
+};
+
+&osc {
+ clock-frequency = <25000000>;
+};
+
+&sdhci0 {
+ status = "okay";
+ disable-wp;
+};
+
+&uart0 {
+ status = "okay";
+};
--
2.34.1
^ permalink raw reply related
* [PATCH v3 1/2] dt-bindings: riscv: add Milk-V Duo S board compatibles
From: michael.opdenacker @ 2024-04-10 6:22 UTC (permalink / raw)
To: Conor Dooley, Rob Herring, Krzysztof Kozlowski, Chen Wang,
Inochi Amaoto, Paul Walmsley, Palmer Dabbelt, Albert Ou, Chao Wei
Cc: Michael Opdenacker, linux-riscv, devicetree, linux-kernel
In-Reply-To: <20240410062254.2955647-1-michael.opdenacker@bootlin.com>
From: Michael Opdenacker <michael.opdenacker@bootlin.com>
Document the compatible strings for the Milk-V Duo S board[1] which uses
the SOPHGO SG2000 SoC, compatible with the SOPHGO CV1800B SoC[2].
Link: https://milkv.io/duo-s [1]
Link: https://en.sophgo.com/product/introduce/cv180xB.html [2]
Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
---
Documentation/devicetree/bindings/riscv/sophgo.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/riscv/sophgo.yaml b/Documentation/devicetree/bindings/riscv/sophgo.yaml
index 9bc813dad098..1837bc550056 100644
--- a/Documentation/devicetree/bindings/riscv/sophgo.yaml
+++ b/Documentation/devicetree/bindings/riscv/sophgo.yaml
@@ -21,6 +21,7 @@ properties:
- items:
- enum:
- milkv,duo
+ - milkv,duos
- const: sophgo,cv1800b
- items:
- enum:
--
2.34.1
^ permalink raw reply related
* Re: (subset) [PATCH 2/2] ARM: dts: ti: omap: minor whitespace cleanup
From: Krzysztof Kozlowski @ 2024-04-10 6:21 UTC (permalink / raw)
To: Benoît Cousson, Tony Lindgren, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Nishanth Menon,
Vignesh Raghavendra, Tero Kristo, linux-omap, devicetree,
linux-kernel, linux-arm-kernel, Krzysztof Kozlowski
In-Reply-To: <20240208105146.128645-2-krzysztof.kozlowski@linaro.org>
On Thu, 08 Feb 2024 11:51:46 +0100, Krzysztof Kozlowski wrote:
> The DTS code coding style expects exactly one space before '{'
> character.
>
>
Applied, thanks!
[2/2] ARM: dts: ti: omap: minor whitespace cleanup
https://git.kernel.org/krzk/linux-dt/c/71413bcb66e018e54afec47a9ce1199130d6fa38
Best regards,
--
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
^ permalink raw reply
* [PATCH] arm64: dts: mediatek: mt8192: Add missing trip point in thermal zone
From: Hsin-Te Yuan @ 2024-04-10 6:20 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Nícolas F. R. A. Prado,
Bernhard Rosenkränzer, Balsam CHIHI, Alexandre Mergnat
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-mediatek,
Hsin-Te Yuan
Add the missing passive trip point which is expected by kernel.
Fixes: c7a728051f4e ("arm64: dts: mediatek: mt8192: Add thermal nodes and thermal zones")
Signed-off-by: Hsin-Te Yuan <yuanhsinte@chromium.org>
---
arch/arm64/boot/dts/mediatek/mt8192.dtsi | 40 ++++++++++++++++++++++++++++++++
1 file changed, 40 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8192.dtsi b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
index 05e401670bced..08d8bccc84669 100644
--- a/arch/arm64/boot/dts/mediatek/mt8192.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8192.dtsi
@@ -1959,6 +1959,11 @@ cpu0-thermal {
thermal-sensors = <&lvts_mcu MT8192_MCU_LITTLE_CPU0>;
trips {
+ cpu0_thres: trip-point {
+ temperature = <68000>;
+ hysteresis = <2000>;
+ type = "passive";
+ };
cpu0_alert: trip-alert {
temperature = <85000>;
hysteresis = <2000>;
@@ -1989,6 +1994,11 @@ cpu1-thermal {
thermal-sensors = <&lvts_mcu MT8192_MCU_LITTLE_CPU1>;
trips {
+ cpu1_thres: trip-point {
+ temperature = <68000>;
+ hysteresis = <2000>;
+ type = "passive";
+ };
cpu1_alert: trip-alert {
temperature = <85000>;
hysteresis = <2000>;
@@ -2019,6 +2029,11 @@ cpu2-thermal {
thermal-sensors = <&lvts_mcu MT8192_MCU_LITTLE_CPU2>;
trips {
+ cpu2_thres: trip-point {
+ temperature = <68000>;
+ hysteresis = <2000>;
+ type = "passive";
+ };
cpu2_alert: trip-alert {
temperature = <85000>;
hysteresis = <2000>;
@@ -2049,6 +2064,11 @@ cpu3-thermal {
thermal-sensors = <&lvts_mcu MT8192_MCU_LITTLE_CPU3>;
trips {
+ cpu3_thres: trip-point {
+ temperature = <68000>;
+ hysteresis = <2000>;
+ type = "passive";
+ };
cpu3_alert: trip-alert {
temperature = <85000>;
hysteresis = <2000>;
@@ -2079,6 +2099,11 @@ cpu4-thermal {
thermal-sensors = <&lvts_mcu MT8192_MCU_BIG_CPU0>;
trips {
+ cpu4_thres: trip-point {
+ temperature = <68000>;
+ hysteresis = <2000>;
+ type = "passive";
+ };
cpu4_alert: trip-alert {
temperature = <85000>;
hysteresis = <2000>;
@@ -2109,6 +2134,11 @@ cpu5-thermal {
thermal-sensors = <&lvts_mcu MT8192_MCU_BIG_CPU1>;
trips {
+ cpu5_thres: trip-point {
+ temperature = <68000>;
+ hysteresis = <2000>;
+ type = "passive";
+ };
cpu5_alert: trip-alert {
temperature = <85000>;
hysteresis = <2000>;
@@ -2139,6 +2169,11 @@ cpu6-thermal {
thermal-sensors = <&lvts_mcu MT8192_MCU_BIG_CPU2>;
trips {
+ cpu6_thres: trip-point {
+ temperature = <68000>;
+ hysteresis = <2000>;
+ type = "passive";
+ };
cpu6_alert: trip-alert {
temperature = <85000>;
hysteresis = <2000>;
@@ -2169,6 +2204,11 @@ cpu7-thermal {
thermal-sensors = <&lvts_mcu MT8192_MCU_BIG_CPU3>;
trips {
+ cpu7_thres: trip-point {
+ temperature = <68000>;
+ hysteresis = <2000>;
+ type = "passive";
+ };
cpu7_alert: trip-alert {
temperature = <85000>;
hysteresis = <2000>;
---
base-commit: 20cb38a7af88dc40095da7c2c9094da3873fea23
change-id: 20240410-upstream-torvalds-master-40aeff5416c7
Best regards,
--
Hsin-Te Yuan <yuanhsinte@chromium.org>
^ permalink raw reply related
* Re: [PATCH] dt-bindings: host1x: Add missing 'dma-coherent'
From: Krzysztof Kozlowski @ 2024-04-10 6:18 UTC (permalink / raw)
To: Jon Hunter, Thierry Reding, Mikko Perttunen, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-tegra, devicetree
In-Reply-To: <20240409082324.9928-1-jonathanh@nvidia.com>
On 09/04/2024 10:23, Jon Hunter wrote:
> The dtbs_check reports that the 'dma-coherent' property is "unevaluated
> and invalid" for the host1x@13e00000 device on Tegra194 and Tegra234
> platforms. Fix this by updating the dt-binding document for host1x to
> add the 'dma-coherent' property for these devices.
That's not really proper reason. What if DTS is wrong? The reason could
be if device is actually DMA coherent...
>
> Fixes: 361238cdc525 ("arm64: tegra: Mark host1x as dma-coherent on Tegra194/234")
> Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
> ---
> .../bindings/display/tegra/nvidia,tegra20-host1x.yaml | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml
> index 94c5242c03b2..3563378a01af 100644
> --- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml
> +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml
> @@ -177,6 +177,15 @@ allOf:
>
> required:
> - reg-names
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - nvidia,tegra194-host1x
> + then:
> + properties:
> + dma-coherent: true
Do not define properties in allOf. Put it in top-level. If not all
devices are DMA coherent, you can disallow it for certain variants (:false).
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 1/5] dt-bindings: soc: qcom: pmic-glink: allow orientation-gpios
From: Krzysztof Kozlowski @ 2024-04-10 6:16 UTC (permalink / raw)
To: Dmitry Baryshkov, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20240409-hdk-orientation-gpios-v2-1-658efd993987@linaro.org>
On 09/04/2024 16:28, Dmitry Baryshkov wrote:
> The orientation GPIOs are not limited to sm8450/sm8550/x1e8000
> platforms. Allow corresponding property to be used on all Qualcom
> platforms.
>
> Fixes: 65682407f8f4 ("dt-bindings: soc: qcom: qcom,pmic-glink: add a gpio used to determine the Type-C port plug orientation")
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
> ---
> .../devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml | 14 --------------
> 1 file changed, 14 deletions(-)
>
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 2/2] ARM: dts: qcom: msm8974-hammerhead: Update gpio hog node name
From: Krzysztof Kozlowski @ 2024-04-10 6:15 UTC (permalink / raw)
To: Luca Weiss, ~postmarketos/upstreaming, phone-devel,
Bjorn Andersson, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Konrad Dybcio
Cc: linux-arm-msm, linux-gpio, devicetree, linux-kernel
In-Reply-To: <20240409-qcom-pmic-gpio-hog-v2-2-5ff812d2baed@z3ntu.xyz>
On 09/04/2024 20:36, Luca Weiss wrote:
> Follow the gpio-hog bindings and use otg-hog as node name.
>
> Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
> ---
> arch/arm/boot/dts/qcom/qcom-msm8974-lge-nexus5-hammerhead.dts | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: pinctrl: qcom,pmic-gpio: Allow gpio-hog nodes
From: Krzysztof Kozlowski @ 2024-04-10 6:14 UTC (permalink / raw)
To: Luca Weiss, ~postmarketos/upstreaming, phone-devel,
Bjorn Andersson, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Konrad Dybcio
Cc: linux-arm-msm, linux-gpio, devicetree, linux-kernel
In-Reply-To: <20240409-qcom-pmic-gpio-hog-v2-1-5ff812d2baed@z3ntu.xyz>
On 09/04/2024 20:36, Luca Weiss wrote:
> Allow specifying a GPIO hog, as already used on
> qcom-msm8974-lge-nexus5-hammerhead.dts.
>
> Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
> ---
> .../devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Best regards,
Krzysztof
^ permalink raw reply
* Re: (subset) [PATCH 1/2] arm64: dts: ti: k3-am62p5-sk: minor whitespace cleanup
From: Tony Lindgren @ 2024-04-10 6:13 UTC (permalink / raw)
To: Nishanth Menon
Cc: Krzysztof Kozlowski, Benoît Cousson, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Vignesh Raghavendra,
Tero Kristo, linux-omap, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <20240410003952.wnxayyiyqxkgj7we@supplier>
* Nishanth Menon <nm@ti.com> [240410 00:39]:
> On 22:04-20240409, Krzysztof Kozlowski wrote:
> > On 09/04/2024 21:36, Nishanth Menon wrote:
> > > Hi Krzysztof Kozlowski,
> > >
> > > On Thu, 08 Feb 2024 11:51:45 +0100, Krzysztof Kozlowski wrote:
> > >> The DTS code coding style expects exactly one space before '{'
> > >> character.
> > >>
> > >>
> > > As discussed offline, I am picking this patch up.
> > >
> > > I have applied the following to branch ti-k3-dts-next on [1].
> > > Thank you!
> > >
> > > [1/2] arm64: dts: ti: k3-am62p5-sk: minor whitespace cleanup
> > > commit: 45ab8daed512258c07fd14536a3633440dabfe84
> >
> > What about the omap one (second in the series)? Shall I take it?
>
> I had poked Tony about it (he is the maintainer for OMAP). Tony: could
> you comment?
Krzysztof, please go ahead apply it, it's not confilicting with anything
I have. I just acked the patch.
Regards,
Tony
^ permalink raw reply
* Re: [PATCH 2/2] ARM: dts: ti: omap: minor whitespace cleanup
From: Tony Lindgren @ 2024-04-10 6:12 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Benoît Cousson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Nishanth Menon, Vignesh Raghavendra, Tero Kristo,
linux-omap, devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <20240208105146.128645-2-krzysztof.kozlowski@linaro.org>
* Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> [240208 10:51]:
> The DTS code coding style expects exactly one space before '{'
> character.
Krzysztof, sorry for the confusion on getting this merged, please go ahead
and take it:
Acked-by: Tony Lindgren <tony@atomide.com>
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: riscv: add Milk-V Duo S board compatibles
From: Krzysztof Kozlowski @ 2024-04-10 6:12 UTC (permalink / raw)
To: michael.opdenacker, Conor Dooley, Rob Herring,
Krzysztof Kozlowski, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Chen Wang, Inochi Amaoto, Chao Wei
Cc: linux-riscv, devicetree, linux-kernel
In-Reply-To: <20240410052518.2945789-2-michael.opdenacker@bootlin.com>
On 10/04/2024 07:25, michael.opdenacker@bootlin.com wrote:
> From: Michael Opdenacker <michael.opdenacker@bootlin.com>
>
> Document the compatible strings for the Milk-V Duo S board[1] which uses
> the SOPHGO SG2000 SoC, compatible with the SOPHGO CV1800B SoC[2].
>
> Link: https://milkv.io/duo-s [1]
> Link: https://en.sophgo.com/product/introduce/cv180xB.html [2]
>
> Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
> ---
> Documentation/devicetree/bindings/riscv/sophgo.yaml | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/riscv/sophgo.yaml b/Documentation/devicetree/bindings/riscv/sophgo.yaml
> index 9bc813dad098..2bf58bd6f3a0 100644
> --- a/Documentation/devicetree/bindings/riscv/sophgo.yaml
> +++ b/Documentation/devicetree/bindings/riscv/sophgo.yaml
> @@ -22,6 +22,10 @@ properties:
> - enum:
> - milkv,duo
> - const: sophgo,cv1800b
> + - items:
> + - enum:
> + - milkv,duos
This should be just part of previous enum.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 4/4] arm64: dts: ti: k3-j7200-main: Add the MAIN domain watchdog instances
From: Neha Malcom Francis @ 2024-04-10 6:09 UTC (permalink / raw)
To: Kumar, Udit, robh, conor+dt, krzysztof.kozlowski+dt, vigneshr, nm
Cc: linux-arm-kernel, devicetree, linux-kernel, kristo
In-Reply-To: <f999020f-0f07-4eb3-bc59-f1a0f7237af7@ti.com>
Hi Udit
On 10/04/24 11:35, Kumar, Udit wrote:
> Hi Neha
>
> On 3/26/2024 5:57 PM, Neha Malcom Francis wrote:
>> There are 4 watchdog instances in the MAIN domain:
>> * one each for the 2 A72 cores
>> * one each for the 2 R5F cores
>>
>> Currently, the devicetree only describes watchdog instances for the A72
>> cores and enables them. Describe the remaining but reserve them as they
>> will be used by their respective firmware.
>>
>> Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
>> ---
>> arch/arm64/boot/dts/ti/k3-j7200-main.dtsi | 27 +++++++++++++++++++++++
>> 1 file changed, 27 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi
>> b/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi
>> index 657f9cc9f4ea..c448c2218e23 100644
>> --- a/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi
>> +++ b/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi
>> @@ -1254,6 +1254,33 @@ watchdog1: watchdog@2210000 {
>> assigned-clock-parents = <&k3_clks 253 5>;
>> };
>> + /*
>> + * The following RTI instances are coupled with MCU R5Fs so
>> + * keeping them reserved as these will be used by their respective
>> + * firmware
>> + */
>> + watchdog2: watchdog@23c0000 {
>> + compatible = "ti,j7-rti-wdt";
>> + reg = <0x00 0x23c0000 0x00 0x100>;
>> + clocks = <&k3_clks 258 1>;
>> + power-domains = <&k3_pds 258 TI_SCI_PD_EXCLUSIVE>;
>> + assigned-clocks = <&k3_clks 258 1>;
>> + assigned-clock-parents = <&k3_clks 258 5>;
>> + /* reserved for MAIN_R5F0_0 */
>> + status = "reserved";
>> + };
>> +
>> + watchdog3: watchdog@23d0000 {
>> + compatible = "ti,j7-rti-wdt";
>> + reg = <0x00 0x23d0000 0x00 0x100>;
>> + clocks = <&k3_clks 259 1>;
>> + power-domains = <&k3_pds 259 TI_SCI_PD_EXCLUSIVE>;
>> + assigned-clocks = <&k3_clks 259 1>;
>> + assigned-clock-parents = <&k3_clks 259 5>;
>> + /* reserved for MAIN_R5F0_1 */
>> + status = "reserved";
>> + };
>> +
>
> Please see, if this make more sense to have label as watchdog28 and watchdog29,
> to align with TRM.
Yes I will change all the patches in the series to align with TRM numbering.
>
> Also request to add mcu domain 2 watchdog as well.
Oh I had missed that out, will add it in v2.
>
>
>> main_timer0: timer@2400000 {
>> compatible = "ti,am654-timer";
>> reg = <0x00 0x2400000 0x00 0x400>;
--
Thanking You
Neha Malcom Francis
^ permalink raw reply
* Re: [PATCH 4/4] arm64: dts: ti: k3-j7200-main: Add the MAIN domain watchdog instances
From: Kumar, Udit @ 2024-04-10 6:05 UTC (permalink / raw)
To: Neha Malcom Francis, robh, conor+dt, krzysztof.kozlowski+dt,
vigneshr, nm
Cc: linux-arm-kernel, devicetree, linux-kernel, kristo, u-kumar1
In-Reply-To: <20240326122723.2329402-5-n-francis@ti.com>
Hi Neha
On 3/26/2024 5:57 PM, Neha Malcom Francis wrote:
> There are 4 watchdog instances in the MAIN domain:
> * one each for the 2 A72 cores
> * one each for the 2 R5F cores
>
> Currently, the devicetree only describes watchdog instances for the A72
> cores and enables them. Describe the remaining but reserve them as they
> will be used by their respective firmware.
>
> Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
> ---
> arch/arm64/boot/dts/ti/k3-j7200-main.dtsi | 27 +++++++++++++++++++++++
> 1 file changed, 27 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi b/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi
> index 657f9cc9f4ea..c448c2218e23 100644
> --- a/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-j7200-main.dtsi
> @@ -1254,6 +1254,33 @@ watchdog1: watchdog@2210000 {
> assigned-clock-parents = <&k3_clks 253 5>;
> };
>
> + /*
> + * The following RTI instances are coupled with MCU R5Fs so
> + * keeping them reserved as these will be used by their respective
> + * firmware
> + */
> + watchdog2: watchdog@23c0000 {
> + compatible = "ti,j7-rti-wdt";
> + reg = <0x00 0x23c0000 0x00 0x100>;
> + clocks = <&k3_clks 258 1>;
> + power-domains = <&k3_pds 258 TI_SCI_PD_EXCLUSIVE>;
> + assigned-clocks = <&k3_clks 258 1>;
> + assigned-clock-parents = <&k3_clks 258 5>;
> + /* reserved for MAIN_R5F0_0 */
> + status = "reserved";
> + };
> +
> + watchdog3: watchdog@23d0000 {
> + compatible = "ti,j7-rti-wdt";
> + reg = <0x00 0x23d0000 0x00 0x100>;
> + clocks = <&k3_clks 259 1>;
> + power-domains = <&k3_pds 259 TI_SCI_PD_EXCLUSIVE>;
> + assigned-clocks = <&k3_clks 259 1>;
> + assigned-clock-parents = <&k3_clks 259 5>;
> + /* reserved for MAIN_R5F0_1 */
> + status = "reserved";
> + };
> +
Please see, if this make more sense to have label as watchdog28 and
watchdog29, to align with TRM.
Also request to add mcu domain 2 watchdog as well.
> main_timer0: timer@2400000 {
> compatible = "ti,am654-timer";
> reg = <0x00 0x2400000 0x00 0x400>;
^ permalink raw reply
* [PATCH v4 2/2] riscv: dts: starfive: visionfive-2: Fix lower rate of CPUfreq by setting PLL0 rate to 1.5GHz
From: Xingyu Wu @ 2024-04-10 3:31 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Conor Dooley,
Emil Renner Berthing, Rob Herring, Krzysztof Kozlowski
Cc: Emil Renner Berthing, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Hal Feng, Xingyu Wu, linux-kernel, linux-clk, linux-riscv,
devicetree
In-Reply-To: <20240410033148.213991-1-xingyu.wu@starfivetech.com>
CPUfreq supports 4 cpu frequency loads on 375/500/750/1500MHz.
But now PLL0 rate is 1GHz and the cpu frequency loads become
333/500/500/1000MHz in fact.
So PLL0 rate should be default set to 1.5GHz and set the
cpu_core rate to 500MHz in safe.
Fixes: e2c510d6d630 ("riscv: dts: starfive: Add cpu scaling for JH7110 SoC")
Signed-off-by: Xingyu Wu <xingyu.wu@starfivetech.com>
---
.../boot/dts/starfive/jh7110-starfive-visionfive-2.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2.dtsi b/arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2.dtsi
index 45b58b6f3df8..28981b267de4 100644
--- a/arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2.dtsi
+++ b/arch/riscv/boot/dts/starfive/jh7110-starfive-visionfive-2.dtsi
@@ -390,6 +390,12 @@ spi_dev0: spi@0 {
};
};
+&syscrg {
+ assigned-clocks = <&syscrg JH7110_SYSCLK_CPU_CORE>,
+ <&pllclk JH7110_PLLCLK_PLL0_OUT>;
+ assigned-clock-rates = <500000000>, <1500000000>;
+};
+
&sysgpio {
i2c0_pins: i2c0-0 {
i2c-pins {
--
2.25.1
^ permalink raw reply related
* Re: [PATCH 3/4] arm64: dts: ti: k3-j721e-main: Add the MAIN domain watchdog instances
From: Neha Malcom Francis @ 2024-04-10 5:50 UTC (permalink / raw)
To: Kumar, Udit, robh, conor+dt, krzysztof.kozlowski+dt, vigneshr, nm
Cc: linux-arm-kernel, devicetree, linux-kernel, kristo
In-Reply-To: <a329fc6b-561c-4300-8778-c90ca97b70f3@ti.com>
Hi Udit,
On 10/04/24 11:06, Kumar, Udit wrote:
> Hi Neha
>
> On 3/26/2024 5:57 PM, Neha Malcom Francis wrote:
>> There are 10 watchdog instances in the MAIN domain:
>> * one each for the 2 A72 cores
>> * one for the GPU core
>> * one for the C7x core
>> * one each for the 2 C66x cores
>> * one each for the 4 R5F cores
>>
>> Currently, the devicetree only describes watchdog instances for the A72
>> cores and enables them. Describe the remaining but reserve them as they
>> will be used by their respective firmware.
>>
>> Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
>> ---
>> arch/arm64/boot/dts/ti/k3-j721e-main.dtsi | 93 +++++++++++++++++++++++
>> 1 file changed, 93 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi
>> b/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi
>> index c7eafbc862f9..d8930b8ea8ec 100644
>> --- a/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi
>> +++ b/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi
>> @@ -2157,6 +2157,99 @@ watchdog1: watchdog@2210000 {
>> assigned-clock-parents = <&k3_clks 253 5>;
>> };
>
> Looking at TRM, SPRUIJ7*3–December 2018–Revised March 2019,
>
> Table 12-22646. RTI Instances, says There is gap in numbering
>
> RTI0, RTI1, RTI15 and so on
>
> IMO, labels for watchdog should be as per TRM.
>
> eg watchdog2 to watchdog15, But I don't have strong opinion on either .
>
> Let maintainer suggest on this
>
Yes, perhaps sticking to the TRM numbering with gaps will improve readability. I
can change that in next version if no objections.
>
>
>> + /*
>> + * The following RTI instances are coupled with MCU R5Fs, c7x and
>> + * GPU so keeping them reserved as these will be used by their
>> + * respective firmware
>> + */
>> + watchdog2: watchdog@22f0000 {
>> + compatible = "ti,j7-rti-wdt";
>> + reg = <0x00 0x22f0000 0x00 0x100>;
>> + clocks = <&k3_clks 257 1>;
>> + power-domains = <&k3_pds 257 TI_SCI_PD_EXCLUSIVE>;
>> + assigned-clocks = <&k3_clks 257 1>;
>> + assigned-clock-parents = <&k3_clks 257 5>;
>> + /* reserved for GPU */
>> + status = "reserved";
>> + };
>
> Please help me to understand, where from you got it for GPU,
>
> May be I am looking at wrong data, Again above TRM
>
> Table 12-22645. RTI Hardware Requests. RTI-15 says esm0
>
The table you are looking at mentions where the interrupt from the watchdog is
routed to.
In the TRM, in sub-section 12.10.2 Windowed Watchdog Timer (WWDT) > 12.19.2.1
RTI Overview; it is mentioned that RTI15 is dedicated to the GPU.
>> +
>> + watchdog3: watchdog@2300000 {
>> + compatible = "ti,j7-rti-wdt";
>> + reg = <0x00 0x2300000 0x00 0x100>;
>> + clocks = <&k3_clks 256 1>;
>> + power-domains = <&k3_pds 256 TI_SCI_PD_EXCLUSIVE>;
>> + assigned-clocks = <&k3_clks 256 1>;
>> + assigned-clock-parents = <&k3_clks 256 5>;
>> + /* reserved for C7X */
>> + status = "reserved";
>
> This I see in above table for Compute Cluster
>
>
>> + };
>> +
>> + watchdog4: watchdog@2380000 {
>> + compatible = "ti,j7-rti-wdt";
>> + reg = <0x00 0x2380000 0x00 0x100>;
>> + clocks = <&k3_clks 254 1>;
>> + power-domains = <&k3_pds 254 TI_SCI_PD_EXCLUSIVE>;
>> + assigned-clocks = <&k3_clks 254 1>;
>> + assigned-clock-parents = <&k3_clks 254 5>;
>> + /* reserved for C66X_0 */
>> + status = "reserved";
>> + };
>> +
>> + watchdog5: watchdog@2390000 {
>> + compatible = "ti,j7-rti-wdt";
>> + reg = <0x00 0x2390000 0x00 0x100>;
>> + clocks = <&k3_clks 255 1>;
>> + power-domains = <&k3_pds 255 TI_SCI_PD_EXCLUSIVE>;
>> + assigned-clocks = <&k3_clks 255 1>;
>> + assigned-clock-parents = <&k3_clks 255 5>;
>> + /* reserved for C66X_1 */
>> + status = "reserved";
>> + };
>> +
>> + watchdog6: watchdog@23c0000 {
>> + compatible = "ti,j7-rti-wdt";
>> + reg = <0x00 0x23c0000 0x00 0x100>;
>> + clocks = <&k3_clks 258 1>;
>> + power-domains = <&k3_pds 258 TI_SCI_PD_EXCLUSIVE>;
>> + assigned-clocks = <&k3_clks 258 1>;
>> + assigned-clock-parents = <&k3_clks 258 5>;
>> + /* reserved for MAIN_R5F0_0 */
>
> TRM says, this covers both MAIN_R5F0_0 and MAIN_R5F0_1.
>
> Suggest , if split is done at fw level
>
>> + status = "reserved";
>> + };
>> +
>> + watchdog7: watchdog@23d0000 {
>> + compatible = "ti,j7-rti-wdt";
>> + reg = <0x00 0x23d0000 0x00 0x100>;
>> + clocks = <&k3_clks 259 1>;
>> + power-domains = <&k3_pds 259 TI_SCI_PD_EXCLUSIVE>;
>> + assigned-clocks = <&k3_clks 259 1>;
>> + assigned-clock-parents = <&k3_clks 259 5>;
>> + /* reserved for MAIN_R5F0_1 */
>> + status = "reserved";
>
> TRM says, this covers both MAIN_R5F0_0 and MAIN_R5F0_1.
>
> Suggest , if split is done at fw level
I didn't quite understand, these watchdogs are mentioned only for DTS
completeness sake.
>
>> + };
>> +
>> + watchdog8: watchdog@23e0000 {
>> + compatible = "ti,j7-rti-wdt";
>> + reg = <0x00 0x23e0000 0x00 0x100>;
>> + clocks = <&k3_clks 260 1>;
>> + power-domains = <&k3_pds 260 TI_SCI_PD_EXCLUSIVE>;
>> + assigned-clocks = <&k3_clks 260 1>;
>> + assigned-clock-parents = <&k3_clks 260 5>;
>> + /* reserved for MAIN_R5F1_0 */
>> + status = "reserved";
>> + };
>
>
> TRM says, this covers both MAIN_R5F1_0 and MAIN_R5F1_1.
>
> Suggest , if split is done at fw level
>
>> +
>> + watchdog9: watchdog@23f0000 {
>> + compatible = "ti,j7-rti-wdt";
>> + reg = <0x00 0x23f0000 0x00 0x100>;
>> + clocks = <&k3_clks 261 1>;
>> + power-domains = <&k3_pds 261 TI_SCI_PD_EXCLUSIVE>;
>> + assigned-clocks = <&k3_clks 261 1>;
>> + assigned-clock-parents = <&k3_clks 261 5>;
>> + /* reserved for MAIN_R5F1_1 */
>
> TRM says, this covers both MAIN_R5F1_0 and MAIN_R5F1_1.
>
> Suggest , if split is done at fw level
>
>> + status = "reserved";
>> + };
>> +
>> main_r5fss0: r5fss@5c00000 {
>> compatible = "ti,j721e-r5fss";
>> ti,cluster-mode = <1>;
--
Thanking You
Neha Malcom Francis
^ permalink raw reply
* Re: [PATCH 2/4] arm64: dts: ti: k3-j721e-mcu: Add the MCU domain watchdog instances
From: Kumar, Udit @ 2024-04-10 5:45 UTC (permalink / raw)
To: Neha Malcom Francis, robh, conor+dt, krzysztof.kozlowski+dt,
vigneshr, nm
Cc: linux-arm-kernel, devicetree, linux-kernel, kristo, u-kumar1
In-Reply-To: <20240326122723.2329402-3-n-francis@ti.com>
Hi Neha
On 3/26/2024 5:57 PM, Neha Malcom Francis wrote:
> There are 2 watchdog instances in the MCU domain. These instances are
> coupled with the MCU domain R55 instances. Reserve them as they are not
> used by A72.
>
> Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
> ---
> .../boot/dts/ti/k3-j721e-mcu-wakeup.dtsi | 26 +++++++++++++++++++
> 1 file changed, 26 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi b/arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi
> index b0f41e9829cc..867f307909be 100644
> --- a/arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi
> @@ -694,4 +694,30 @@ wkup_esm: esm@42080000 {
> compatible = "ti,j721e-esm";
> reg = <0x00 0x42080000 0x00 0x1000>;
> };
> +
> + /*
> + * The 2 RTI instances are couple with MCU R5Fs so keeping them
> + * reserved as these will be used by their respective firmware
> + */
> + mcu_watchdog0: watchdog@40600000 {
> + compatible = "ti,j7-rti-wdt";
> + reg = <0x00 0x40600000 0x00 0x100>;
> + clocks = <&k3_clks 262 1>;
> + power-domains = <&k3_pds 262 TI_SCI_PD_EXCLUSIVE>;
> + assigned-clocks = <&k3_clks 262 1>;
> + assigned-clock-parents = <&k3_clks 262 5>;
> + /* reserved for MCU_R5F0_0 */
> + status = "reserved";
> + };
> +
> + mcu_watchdog1: watchdog@40610000 {
> + compatible = "ti,j7-rti-wdt";
> + reg = <0x00 0x40610000 0x00 0x100>;
> + clocks = <&k3_clks 263 1>;
> + power-domains = <&k3_pds 263 TI_SCI_PD_EXCLUSIVE>;
> + assigned-clocks = <&k3_clks 263 1>;
> + assigned-clock-parents = <&k3_clks 263 5>;
> + /* reserved for MCU_R5F0_1 */
Table 12-22642. MCU_RTI Hardware Requests (In same TRM referred in 3/4
patch review ),
says each WDT has destination of MCU0_R5_CORE0 and MCU0_R5_CORE1
Please suggest, if fw level this is decided to reserved like above ?
With that clarification, Please use
Reviewed-by: Udit Kumar <u-kumar1@ti.com>
> + status = "reserved";
> + };
> };
^ permalink raw reply
* Re: [PATCH 1/4] arm64: dts: ti: k3-j721e-mcu: Add the WKUP ESM instance
From: Neha Malcom Francis @ 2024-04-10 5:39 UTC (permalink / raw)
To: Kumar, Udit, robh, conor+dt, krzysztof.kozlowski+dt, vigneshr, nm
Cc: linux-arm-kernel, devicetree, linux-kernel, kristo
In-Reply-To: <b76578ca-9e94-43a6-93cf-690e23545529@ti.com>
Hi Udit,
On 10/04/24 10:42, Kumar, Udit wrote:
> Hi Neha
>
> On 3/26/2024 5:57 PM, Neha Malcom Francis wrote:
>> Add the WKUP ESM instance for J721E. It has three instances in total,
>> one in the MAIN domain (main_esm) and two in the MCU-WKUP domain
>> (mcu_esm and wkup_esm).
>>
>> Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
>> ---
>> arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi | 5 +++++
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi
>> b/arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi
>> index 4618b697fbc4..b0f41e9829cc 100644
>> --- a/arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi
>> +++ b/arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi
>> @@ -689,4 +689,9 @@ mcu_esm: esm@40800000 {
>> ti,esm-pins = <95>;
>> bootph-pre-ram;
>> };
>> +
>> + wkup_esm: esm@42080000 {
>> + compatible = "ti,j721e-esm";
>> + reg = <0x00 0x42080000 0x00 0x1000>;
>
> I think , only esm@40800000 should be good for this SOC.
>
> I am not sure, why you want to add this. If you still want to add this for
> completeness ,
Yes, I wanted to make sure all ESM modules are present for DTS completeness.
>
> then two options, I suggest
>
> 1) If you plan to use this mention bootph-pre-ram and ti,esm-pins
>
No plans for using it as of now.
J721E ESM interrupt routing is such that the MAIN_ESM interrupt triggers an
error event in the MCU_ESM (which is correctly set via their node ti,j721e-esm
glue logic pins). The MCU_ESM and WKUP_ESM both generate the same interrupt
after. So there is no ti,j721e-esm pin applicable for WKUP_ESM.
> 2) In case , no plan to use this then please mark node as disabled
>
Yes I will mark this as disabled, I overlooked the fact that leaving this
enabled would throw "ESM init failed" when DT syncs with U-Boot. Thanks for
catching!
>
>> + };
>> };
--
Thanking You
Neha Malcom Francis
^ permalink raw reply
* Re: [PATCH 3/4] arm64: dts: ti: k3-j721e-main: Add the MAIN domain watchdog instances
From: Kumar, Udit @ 2024-04-10 5:36 UTC (permalink / raw)
To: Neha Malcom Francis, robh, conor+dt, krzysztof.kozlowski+dt,
vigneshr, nm
Cc: linux-arm-kernel, devicetree, linux-kernel, kristo
In-Reply-To: <20240326122723.2329402-4-n-francis@ti.com>
Hi Neha
On 3/26/2024 5:57 PM, Neha Malcom Francis wrote:
> There are 10 watchdog instances in the MAIN domain:
> * one each for the 2 A72 cores
> * one for the GPU core
> * one for the C7x core
> * one each for the 2 C66x cores
> * one each for the 4 R5F cores
>
> Currently, the devicetree only describes watchdog instances for the A72
> cores and enables them. Describe the remaining but reserve them as they
> will be used by their respective firmware.
>
> Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
> ---
> arch/arm64/boot/dts/ti/k3-j721e-main.dtsi | 93 +++++++++++++++++++++++
> 1 file changed, 93 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi b/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi
> index c7eafbc862f9..d8930b8ea8ec 100644
> --- a/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi
> @@ -2157,6 +2157,99 @@ watchdog1: watchdog@2210000 {
> assigned-clock-parents = <&k3_clks 253 5>;
> };
>
Looking at TRM, SPRUIJ7*3–December 2018–Revised March 2019,
Table 12-22646. RTI Instances, says There is gap in numbering
RTI0, RTI1, RTI15 and so on
IMO, labels for watchdog should be as per TRM.
eg watchdog2 to watchdog15, But I don't have strong opinion on either .
Let maintainer suggest on this
> + /*
> + * The following RTI instances are coupled with MCU R5Fs, c7x and
> + * GPU so keeping them reserved as these will be used by their
> + * respective firmware
> + */
> + watchdog2: watchdog@22f0000 {
> + compatible = "ti,j7-rti-wdt";
> + reg = <0x00 0x22f0000 0x00 0x100>;
> + clocks = <&k3_clks 257 1>;
> + power-domains = <&k3_pds 257 TI_SCI_PD_EXCLUSIVE>;
> + assigned-clocks = <&k3_clks 257 1>;
> + assigned-clock-parents = <&k3_clks 257 5>;
> + /* reserved for GPU */
> + status = "reserved";
> + };
Please help me to understand, where from you got it for GPU,
May be I am looking at wrong data, Again above TRM
Table 12-22645. RTI Hardware Requests. RTI-15 says esm0
> +
> + watchdog3: watchdog@2300000 {
> + compatible = "ti,j7-rti-wdt";
> + reg = <0x00 0x2300000 0x00 0x100>;
> + clocks = <&k3_clks 256 1>;
> + power-domains = <&k3_pds 256 TI_SCI_PD_EXCLUSIVE>;
> + assigned-clocks = <&k3_clks 256 1>;
> + assigned-clock-parents = <&k3_clks 256 5>;
> + /* reserved for C7X */
> + status = "reserved";
This I see in above table for Compute Cluster
> + };
> +
> + watchdog4: watchdog@2380000 {
> + compatible = "ti,j7-rti-wdt";
> + reg = <0x00 0x2380000 0x00 0x100>;
> + clocks = <&k3_clks 254 1>;
> + power-domains = <&k3_pds 254 TI_SCI_PD_EXCLUSIVE>;
> + assigned-clocks = <&k3_clks 254 1>;
> + assigned-clock-parents = <&k3_clks 254 5>;
> + /* reserved for C66X_0 */
> + status = "reserved";
> + };
> +
> + watchdog5: watchdog@2390000 {
> + compatible = "ti,j7-rti-wdt";
> + reg = <0x00 0x2390000 0x00 0x100>;
> + clocks = <&k3_clks 255 1>;
> + power-domains = <&k3_pds 255 TI_SCI_PD_EXCLUSIVE>;
> + assigned-clocks = <&k3_clks 255 1>;
> + assigned-clock-parents = <&k3_clks 255 5>;
> + /* reserved for C66X_1 */
> + status = "reserved";
> + };
> +
> + watchdog6: watchdog@23c0000 {
> + compatible = "ti,j7-rti-wdt";
> + reg = <0x00 0x23c0000 0x00 0x100>;
> + clocks = <&k3_clks 258 1>;
> + power-domains = <&k3_pds 258 TI_SCI_PD_EXCLUSIVE>;
> + assigned-clocks = <&k3_clks 258 1>;
> + assigned-clock-parents = <&k3_clks 258 5>;
> + /* reserved for MAIN_R5F0_0 */
TRM says, this covers both MAIN_R5F0_0 and MAIN_R5F0_1.
Suggest , if split is done at fw level
> + status = "reserved";
> + };
> +
> + watchdog7: watchdog@23d0000 {
> + compatible = "ti,j7-rti-wdt";
> + reg = <0x00 0x23d0000 0x00 0x100>;
> + clocks = <&k3_clks 259 1>;
> + power-domains = <&k3_pds 259 TI_SCI_PD_EXCLUSIVE>;
> + assigned-clocks = <&k3_clks 259 1>;
> + assigned-clock-parents = <&k3_clks 259 5>;
> + /* reserved for MAIN_R5F0_1 */
> + status = "reserved";
TRM says, this covers both MAIN_R5F0_0 and MAIN_R5F0_1.
Suggest , if split is done at fw level
> + };
> +
> + watchdog8: watchdog@23e0000 {
> + compatible = "ti,j7-rti-wdt";
> + reg = <0x00 0x23e0000 0x00 0x100>;
> + clocks = <&k3_clks 260 1>;
> + power-domains = <&k3_pds 260 TI_SCI_PD_EXCLUSIVE>;
> + assigned-clocks = <&k3_clks 260 1>;
> + assigned-clock-parents = <&k3_clks 260 5>;
> + /* reserved for MAIN_R5F1_0 */
> + status = "reserved";
> + };
TRM says, this covers both MAIN_R5F1_0 and MAIN_R5F1_1.
Suggest , if split is done at fw level
> +
> + watchdog9: watchdog@23f0000 {
> + compatible = "ti,j7-rti-wdt";
> + reg = <0x00 0x23f0000 0x00 0x100>;
> + clocks = <&k3_clks 261 1>;
> + power-domains = <&k3_pds 261 TI_SCI_PD_EXCLUSIVE>;
> + assigned-clocks = <&k3_clks 261 1>;
> + assigned-clock-parents = <&k3_clks 261 5>;
> + /* reserved for MAIN_R5F1_1 */
TRM says, this covers both MAIN_R5F1_0 and MAIN_R5F1_1.
Suggest , if split is done at fw level
> + status = "reserved";
> + };
> +
> main_r5fss0: r5fss@5c00000 {
> compatible = "ti,j721e-r5fss";
> ti,cluster-mode = <1>;
^ 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