* Re: [PATCH 2/4] arm64: dts: rockchip: drop redundant bus-scan-delay-ms in Pinebook
From: Dragan Simic @ 2024-04-07 10:34 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
devicetree, linux-arm-kernel, linux-rockchip, linux-kernel
In-Reply-To: <20240407102854.38672-2-krzysztof.kozlowski@linaro.org>
Hello Krzysztof,
On 2024-04-07 12:28, Krzysztof Kozlowski wrote:
> There is no "bus-scan-delay-ms" property in the PCI bindings or Linux
> driver, so assume this was copied from downstream. This fixes
> dtbs_check warning:
>
> rk3399-pinebook-pro.dtb: pcie@f8000000: Unevaluated properties are
> not allowed ('bus-scan-delay-ms' was unexpected)
Please note that it's been already deleted. [1]
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=43853e843aa6c3d47ff2b0cce898318839483d05
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> ---
> arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts
> b/arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts
> index 054c6a4d1a45..294eb2de263d 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts
> @@ -779,7 +779,6 @@ &pcie_phy {
> };
>
> &pcie0 {
> - bus-scan-delay-ms = <1000>;
> ep-gpios = <&gpio2 RK_PD4 GPIO_ACTIVE_HIGH>;
> num-lanes = <4>;
> pinctrl-names = "default";
^ permalink raw reply
* Re: [PATCH v2 3/3] dt-bindings: kbuild: Add separate target/dependency for processed-schema.json
From: Conor Dooley @ 2024-04-07 10:59 UTC (permalink / raw)
To: Rob Herring
Cc: Krzysztof Kozlowski, Conor Dooley, Masahiro Yamada,
Nathan Chancellor, Nicolas Schier, Dmitry Baryshkov,
Marijn Suijten, devicetree, linux-kernel, linux-kbuild
In-Reply-To: <20240405-dt-kbuild-rework-v2-3-3a035caee357@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 1162 bytes --]
On Fri, Apr 05, 2024 at 05:56:03PM -0500, Rob Herring wrote:
> Running dtbs_check and dt_compatible_check targets really only depend
> on processed-schema.json, but the dependency is 'dt_binding_check'. That
> was sort worked around with the CHECK_DT_BINDING variable in order to
> skip some of the work that 'dt_binding_check' does. It still runs the
> full checks of the schemas which is not necessary and adds 10s of
> seconds to the build time. That's significant when checking only a few
> DTBs and with recent changes that have improved the validation time by
> 6-7x.
>
> Add a new target, dt_binding_schema, which just builds
> processed-schema.json and can be used as the dependency for other
> targets. The scripts_dtc dependency isn't needed either as the examples
> aren't built for it.
>
> Signed-off-by: Rob Herring <robh@kernel.org>
Yoo, that's pretty nice. 20 seconds cut off my dtbs_check build time on
riscv with this change :) As you point out, when you're not checking all
that many it is pretty significant - 48 seconds before and 28 seconds now
Tested-by: Conor Dooley <conor.dooley@microchip.com>
Thanks,
Conor.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v4 1/2] dt-bindings: arm: qcom: Document the Samsung Galaxy Z Fold5
From: Krzysztof Kozlowski @ 2024-04-07 11:08 UTC (permalink / raw)
To: Alexandru Serdeliuc, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <46ca8527-8b3e-4894-a1ee-8f2663e457fb@yahoo.com>
On 07/04/2024 11:21, Alexandru Serdeliuc wrote:
> I am terribly sorry, this is my first patch sent here, I am still
> trying to understand what and how to do it.
>
> How to proceed with those missing tags? i should create a v5 and add them?
>
You need to add them. Please read the document I linked.
Best regards,
Krzysztof
^ permalink raw reply
* RE: [PATCH v2 4/6] firmware: arm_scmi: add initial support for i.MX MISC protocol
From: Peng Fan @ 2024-04-07 11:16 UTC (permalink / raw)
To: Marco Felsch
Cc: Peng Fan (OSS), Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Sudeep Holla, Cristian Marussi, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, imx@lists.linux.dev
In-Reply-To: <20240407110208.4huirwif7as3dsps@pengutronix.de>
> Subject: Re: [PATCH v2 4/6] firmware: arm_scmi: add initial support for i.MX
> MISC protocol
>
> Hi Peng,
>
> On 24-04-07, Peng Fan wrote:
> > > Subject: Re: [PATCH v2 4/6] firmware: arm_scmi: add initial support
> > > for i.MX MISC protocol
> > >
> > > Hi Peng,
> > >
> > > On 24-04-05, Peng Fan (OSS) wrote:
> > > > From: Peng Fan <peng.fan@nxp.com>
> > > >
> > > > The i.MX MISC protocol is for misc settings, such as gpio expander
> > > > wakeup.
> > >
> > > Can you elaborate a bit more please?
> >
> > The gpio expander is under M33(SCMI firmware used core) I2C control,
>
> Due to missing technical references I guess that your specific EVK has an i2c-
> expander connected to the system-critical-i2c bus? The system-critical-i2c
> should be only used for system critical topics like PMIC control.
Right.
>
> > But the gpio expander supports board function such as PCIE_WAKEUP,
> > BTN_WAKEUP. So these are managed by MISC protocol.
>
> This seems more like an specific i.MX95-EVK problem too me since you have
> conneccted the i2c-gpio-expander to the system-critical-i2c bus instead of
> using an bus available within Linux. Also can you please provide me a link
> with the propsoal for the MISC protocol? I can't find any references within the
> SCMI v3.2
It is i.MX VENDOR Extension, not a standard one in Spec.
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdevelo
> per.arm.com%2Fdocumentation%2Fden0056%2Fe%2F&data=05%7C02%7Cp
> eng.fan%40nxp.com%7C6120357a772045a0618808dc56f22c95%7C686ea1d
> 3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C638480845336536607%7CUnk
> nown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik
> 1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=NI%2F8WMPuGzJwD74
> 1jcuknHZUR5uI2me9iEeWbeDKshE%3D&reserved=0 nor within the SCP
> firmware git:
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub
> .com%2FARM-software%2FSCP-
> firmware&data=05%7C02%7Cpeng.fan%40nxp.com%7C6120357a772045a06
> 18808dc56f22c95%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C
> 638480845336550459%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw
> MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C
> &sdata=N3bT9ItgvL4Z9xP1oxlmDTG%2FFjsXkuhJIA9wooJWfcM%3D&reserve
> d=0.
>
> > SAI_CLK_MSEL in WAKEUP BLK CTRL is also managed by MISC Protocol.
>
> You recently said that we need blk-ctrl drivers for managing/controlling the
> GPR stuff within Linux since the SCMI firmware does not support this. Now
> blk-ctrl GPR control is supported by the firmware?
AONMIX/WAKEUPMIX BLK CTRL is managed by SCMI firmware, for other
non system critical BLK CTRLs, they are managed by Linux directly, such as
GPU/VPU BLK CTRL and etc.
Regards,
Peng.
>
> Regards,
> Marco
>
> >
> > And etc...
> >
> > I will add more info in commit log in next version later, after I get
> > more reviews on the patchset.
> >
> > Thanks,
> > Peng.
> >
> > >
> > > Regards,
> > > Marco
> > >
> > >
> > > >
> > > > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> > > > ---
> > > > drivers/firmware/arm_scmi/Kconfig | 10 ++
> > > > drivers/firmware/arm_scmi/Makefile | 1 +
> > > > drivers/firmware/arm_scmi/imx-sm-misc.c | 305
> > > ++++++++++++++++++++++++++++++++
> > > > include/linux/scmi_imx_protocol.h | 17 ++
> > > > 4 files changed, 333 insertions(+)
> > > >
> > > > diff --git a/drivers/firmware/arm_scmi/Kconfig
> > > > b/drivers/firmware/arm_scmi/Kconfig
> > > > index 56d11c9d9f47..bfeae92f6420 100644
> > > > --- a/drivers/firmware/arm_scmi/Kconfig
> > > > +++ b/drivers/firmware/arm_scmi/Kconfig
> > > > @@ -191,3 +191,13 @@ config IMX_SCMI_BBM_EXT
> > > > and BUTTON.
> > > >
> > > > This driver can also be built as a module.
> > > > +
> > > > +config IMX_SCMI_MISC_EXT
> > > > + tristate "i.MX SCMI MISC EXTENSION"
> > > > + depends on ARM_SCMI_PROTOCOL || (COMPILE_TEST && OF)
> > > > + default y if ARCH_MXC
> > > > + help
> > > > + This enables i.MX System MISC control logic such as gpio expander
> > > > + wakeup
> > > > +
> > > > + This driver can also be built as a module.
> > > > diff --git a/drivers/firmware/arm_scmi/Makefile
> > > > b/drivers/firmware/arm_scmi/Makefile
> > > > index 327687acf857..a23fde721222 100644
> > > > --- a/drivers/firmware/arm_scmi/Makefile
> > > > +++ b/drivers/firmware/arm_scmi/Makefile
> > > > @@ -12,6 +12,7 @@ scmi-transport-
> > > $(CONFIG_ARM_SCMI_TRANSPORT_VIRTIO)
> > > > += virtio.o
> > > > scmi-transport-$(CONFIG_ARM_SCMI_TRANSPORT_OPTEE) += optee.o
> > > > scmi-protocols-y = base.o clock.o perf.o power.o reset.o sensors.o
> > > > system.o voltage.o powercap.o
> > > > scmi-protocols-$(CONFIG_IMX_SCMI_BBM_EXT) += imx-sm-bbm.o
> > > > +scmi-protocols-$(CONFIG_IMX_SCMI_MISC_EXT) += imx-sm-misc.o
> > > > scmi-module-objs := $(scmi-driver-y) $(scmi-protocols-y)
> > > > $(scmi-transport-y)
> > > >
> > > > obj-$(CONFIG_ARM_SCMI_PROTOCOL) += scmi-core.o diff --git
> > > > a/drivers/firmware/arm_scmi/imx-sm-misc.c
> > > > b/drivers/firmware/arm_scmi/imx-sm-misc.c
> > > > new file mode 100644
> > > > index 000000000000..1b0ec2281518
> > > > --- /dev/null
> > > > +++ b/drivers/firmware/arm_scmi/imx-sm-misc.c
> > > > @@ -0,0 +1,305 @@
> > > > +// SPDX-License-Identifier: GPL-2.0
> > > > +/*
> > > > + * System control and Management Interface (SCMI) NXP MISC
> > > > +Protocol
> > > > + *
> > > > + * Copyright 2024 NXP
> > > > + */
> > > > +
> > > > +#define pr_fmt(fmt) "SCMI Notifications MISC - " fmt
> > > > +
> > > > +#include <linux/bits.h>
> > > > +#include <linux/io.h>
> > > > +#include <linux/module.h>
> > > > +#include <linux/of.h>
> > > > +#include <linux/platform_device.h> #include
> > > > +<linux/scmi_protocol.h> #include <linux/scmi_imx_protocol.h>
> > > > +
> > > > +#include "protocols.h"
> > > > +#include "notify.h"
> > > > +
> > > > +#define SCMI_PROTOCOL_SUPPORTED_VERSION 0x10000
> > > > +
> > > > +enum scmi_imx_misc_protocol_cmd {
> > > > + SCMI_IMX_MISC_CTRL_SET = 0x3,
> > > > + SCMI_IMX_MISC_CTRL_GET = 0x4,
> > > > + SCMI_IMX_MISC_CTRL_NOTIFY = 0x8, };
> > > > +
> > > > +struct scmi_imx_misc_info {
> > > > + u32 version;
> > > > + u32 nr_dev_ctrl;
> > > > + u32 nr_brd_ctrl;
> > > > + u32 nr_reason;
> > > > +};
> > > > +
> > > > +struct scmi_msg_imx_misc_protocol_attributes {
> > > > + __le32 attributes;
> > > > +};
> > > > +
> > > > +#define GET_BRD_CTRLS_NR(x) le32_get_bits((x), GENMASK(31,
> > > 24))
> > > > +#define GET_REASONS_NR(x) le32_get_bits((x), GENMASK(23,
> 16))
> > > > +#define GET_DEV_CTRLS_NR(x) le32_get_bits((x), GENMASK(15, 0))
> > > > +#define BRD_CTRL_START_ID BIT(15)
> > > > +
> > > > +struct scmi_imx_misc_ctrl_set_in {
> > > > + __le32 id;
> > > > + __le32 num;
> > > > + __le32 value[MISC_MAX_VAL];
> > > > +};
> > > > +
> > > > +struct scmi_imx_misc_ctrl_notify_in {
> > > > + __le32 ctrl_id;
> > > > + __le32 flags;
> > > > +};
> > > > +
> > > > +struct scmi_imx_misc_ctrl_notify_payld {
> > > > + __le32 ctrl_id;
> > > > + __le32 flags;
> > > > +};
> > > > +
> > > > +struct scmi_imx_misc_ctrl_get_out {
> > > > + __le32 num;
> > > > + __le32 *val;
> > > > +};
> > > > +
> > > > +static int scmi_imx_misc_attributes_get(const struct
> > > > +scmi_protocol_handle
> > > *ph,
> > > > + struct scmi_imx_misc_info *mi) {
> > > > + int ret;
> > > > + struct scmi_xfer *t;
> > > > + struct scmi_msg_imx_misc_protocol_attributes *attr;
> > > > +
> > > > + ret = ph->xops->xfer_get_init(ph, PROTOCOL_ATTRIBUTES, 0,
> > > > + sizeof(*attr), &t);
> > > > + if (ret)
> > > > + return ret;
> > > > +
> > > > + attr = t->rx.buf;
> > > > +
> > > > + ret = ph->xops->do_xfer(ph, t);
> > > > + if (!ret) {
> > > > + mi->nr_dev_ctrl = GET_DEV_CTRLS_NR(attr->attributes);
> > > > + mi->nr_brd_ctrl = GET_BRD_CTRLS_NR(attr->attributes);
> > > > + mi->nr_reason = GET_REASONS_NR(attr->attributes);
> > > > + dev_info(ph->dev, "i.MX MISC NUM DEV CTRL: %d, NUM
> > > BRD CTRL: %d,NUM Reason: %d\n",
> > > > + mi->nr_dev_ctrl, mi->nr_brd_ctrl, mi->nr_reason);
> > > > + }
> > > > +
> > > > + ph->xops->xfer_put(ph, t);
> > > > +
> > > > + return ret;
> > > > +}
> > > > +
> > > > +static int scmi_imx_misc_ctrl_validate_id(const struct
> > > scmi_protocol_handle *ph,
> > > > + u32 ctrl_id)
> > > > +{
> > > > + struct scmi_imx_misc_info *mi = ph->get_priv(ph);
> > > > +
> > > > + if ((ctrl_id < BRD_CTRL_START_ID) && (ctrl_id > mi->nr_dev_ctrl))
> > > > + return -EINVAL;
> > > > + if (ctrl_id >= BRD_CTRL_START_ID + mi->nr_brd_ctrl)
> > > > + return -EINVAL;
> > > > +
> > > > + return 0;
> > > > +}
> > > > +
> > > > +static int scmi_imx_misc_ctrl_notify(const struct
> > > > +scmi_protocol_handle
> > > *ph,
> > > > + u32 ctrl_id, u32 flags)
> > > > +{
> > > > + struct scmi_imx_misc_ctrl_notify_in *in;
> > > > + struct scmi_xfer *t;
> > > > + int ret;
> > > > +
> > > > + ret = scmi_imx_misc_ctrl_validate_id(ph, ctrl_id);
> > > > + if (ret)
> > > > + return ret;
> > > > +
> > > > + ret = ph->xops->xfer_get_init(ph, SCMI_IMX_MISC_CTRL_NOTIFY,
> > > > + sizeof(*in), 0, &t);
> > > > + if (ret)
> > > > + return ret;
> > > > +
> > > > + in = t->tx.buf;
> > > > + in->ctrl_id = cpu_to_le32(ctrl_id);
> > > > + in->flags = cpu_to_le32(flags);
> > > > +
> > > > + ret = ph->xops->do_xfer(ph, t);
> > > > +
> > > > + ph->xops->xfer_put(ph, t);
> > > > +
> > > > + return ret;
> > > > +}
> > > > +
> > > > +static int
> > > > +scmi_imx_misc_ctrl_set_notify_enabled(const struct
> > > scmi_protocol_handle *ph,
> > > > + u8 evt_id, u32 src_id, bool enable) {
> > > > + int ret;
> > > > +
> > > > + ret = scmi_imx_misc_ctrl_notify(ph, src_id, enable ? evt_id : 0);
> > > > + if (ret)
> > > > + dev_err(ph->dev, "FAIL_ENABLED - evt[%X] src[%d] -
> > > ret:%d\n",
> > > > + evt_id, src_id, ret);
> > > > +
> > > > + return ret;
> > > > +}
> > > > +
> > > > +static int scmi_imx_misc_ctrl_get_num_sources(const struct
> > > > +scmi_protocol_handle *ph) {
> > > > + return GENMASK(15, 0);
> > > > +}
> > > > +
> > > > +static void *
> > > > +scmi_imx_misc_ctrl_fill_custom_report(const struct
> > > > +scmi_protocol_handle
> > > *ph,
> > > > + u8 evt_id, ktime_t timestamp,
> > > > + const void *payld, size_t payld_sz,
> > > > + void *report, u32 *src_id) {
> > > > + const struct scmi_imx_misc_ctrl_notify_payld *p = payld;
> > > > + struct scmi_imx_misc_ctrl_notify_report *r = report;
> > > > +
> > > > + if (sizeof(*p) != payld_sz)
> > > > + return NULL;
> > > > +
> > > > + r->timestamp = timestamp;
> > > > + r->ctrl_id = p->ctrl_id;
> > > > + r->flags = p->flags;
> > > > + *src_id = r->ctrl_id;
> > > > + dev_dbg(ph->dev, "%s: ctrl_id: %d flags: %d\n", __func__,
> > > > + r->ctrl_id, r->flags);
> > > > +
> > > > + return r;
> > > > +}
> > > > +
> > > > +static const struct scmi_event_ops scmi_imx_misc_event_ops = {
> > > > + .get_num_sources = scmi_imx_misc_ctrl_get_num_sources,
> > > > + .set_notify_enabled = scmi_imx_misc_ctrl_set_notify_enabled,
> > > > + .fill_custom_report = scmi_imx_misc_ctrl_fill_custom_report,
> > > > +};
> > > > +
> > > > +static const struct scmi_event scmi_imx_misc_events[] = {
> > > > + {
> > > > + .id = SCMI_EVENT_IMX_MISC_CONTROL_DISABLED,
> > > > + .max_payld_sz = sizeof(struct
> > > scmi_imx_misc_ctrl_notify_payld),
> > > > + .max_report_sz = sizeof(struct
> > > scmi_imx_misc_ctrl_notify_report),
> > > > + },
> > > > + {
> > > > + .id = SCMI_EVENT_IMX_MISC_CONTROL_FALLING_EDGE,
> > > > + .max_payld_sz = sizeof(struct
> > > scmi_imx_misc_ctrl_notify_payld),
> > > > + .max_report_sz = sizeof(struct
> > > scmi_imx_misc_ctrl_notify_report),
> > > > + },
> > > > + {
> > > > + .id = SCMI_EVENT_IMX_MISC_CONTROL_RISING_EDGE,
> > > > + .max_payld_sz = sizeof(struct
> > > scmi_imx_misc_ctrl_notify_payld),
> > > > + .max_report_sz = sizeof(struct
> > > scmi_imx_misc_ctrl_notify_report),
> > > > + }
> > > > +};
> > > > +
> > > > +static struct scmi_protocol_events scmi_imx_misc_protocol_events = {
> > > > + .queue_sz = SCMI_PROTO_QUEUE_SZ,
> > > > + .ops = &scmi_imx_misc_event_ops,
> > > > + .evts = scmi_imx_misc_events,
> > > > + .num_events = ARRAY_SIZE(scmi_imx_misc_events), };
> > > > +
> > > > +static int scmi_imx_misc_protocol_init(const struct
> > > > +scmi_protocol_handle *ph) {
> > > > + struct scmi_imx_misc_info *minfo;
> > > > + u32 version;
> > > > + int ret;
> > > > +
> > > > + ret = ph->xops->version_get(ph, &version);
> > > > + if (ret)
> > > > + return ret;
> > > > +
> > > > + dev_info(ph->dev, "NXP SM MISC Version %d.%d\n",
> > > > + PROTOCOL_REV_MAJOR(version),
> > > PROTOCOL_REV_MINOR(version));
> > > > +
> > > > + minfo = devm_kzalloc(ph->dev, sizeof(*minfo), GFP_KERNEL);
> > > > + if (!minfo)
> > > > + return -ENOMEM;
> > > > +
> > > > + ret = scmi_imx_misc_attributes_get(ph, minfo);
> > > > + if (ret)
> > > > + return ret;
> > > > +
> > > > + return ph->set_priv(ph, minfo, version); }
> > > > +
> > > > +static int scmi_imx_misc_ctrl_get(const struct scmi_protocol_handle
> *ph,
> > > > + u32 ctrl_id, u32 *num, u32 *val) {
> > > > + struct scmi_imx_misc_ctrl_get_out *out;
> > > > + struct scmi_xfer *t;
> > > > + int ret, i;
> > > > +
> > > > + ret = scmi_imx_misc_ctrl_validate_id(ph, ctrl_id);
> > > > + if (ret)
> > > > + return ret;
> > > > +
> > > > + ret = ph->xops->xfer_get_init(ph, SCMI_IMX_MISC_CTRL_GET,
> > > sizeof(u32),
> > > > + 0, &t);
> > > > + if (ret)
> > > > + return ret;
> > > > +
> > > > + put_unaligned_le32(ctrl_id, t->tx.buf);
> > > > + ret = ph->xops->do_xfer(ph, t);
> > > > + if (!ret) {
> > > > + out = t->rx.buf;
> > > > + *num = le32_to_cpu(out->num);
> > > > + for (i = 0; i < *num && i < MISC_MAX_VAL; i++)
> > > > + val[i] = le32_to_cpu(out->val[i]);
> > > > + }
> > > > +
> > > > + ph->xops->xfer_put(ph, t);
> > > > +
> > > > + return ret;
> > > > +}
> > > > +
> > > > +static int scmi_imx_misc_ctrl_set(const struct scmi_protocol_handle
> *ph,
> > > > + u32 ctrl_id, u32 num, u32 *val) {
> > > > + struct scmi_imx_misc_ctrl_set_in *in;
> > > > + struct scmi_xfer *t;
> > > > + int ret, i;
> > > > +
> > > > + ret = scmi_imx_misc_ctrl_validate_id(ph, ctrl_id);
> > > > + if (ret)
> > > > + return ret;
> > > > +
> > > > + if (num > MISC_MAX_VAL)
> > > > + return -EINVAL;
> > > > +
> > > > + ret = ph->xops->xfer_get_init(ph, SCMI_IMX_MISC_CTRL_SET,
> > > sizeof(*in),
> > > > + 0, &t);
> > > > + if (ret)
> > > > + return ret;
> > > > +
> > > > + in = t->tx.buf;
> > > > + in->id = cpu_to_le32(ctrl_id);
> > > > + in->num = cpu_to_le32(num);
> > > > + for (i = 0; i < num; i++)
> > > > + in->value[i] = cpu_to_le32(val[i]);
> > > > +
> > > > + ret = ph->xops->do_xfer(ph, t);
> > > > +
> > > > + ph->xops->xfer_put(ph, t);
> > > > +
> > > > + return ret;
> > > > +}
> > > > +
> > > > +static const struct scmi_imx_misc_proto_ops
> > > > +scmi_imx_misc_proto_ops =
> > > {
> > > > + .misc_ctrl_set = scmi_imx_misc_ctrl_set,
> > > > + .misc_ctrl_get = scmi_imx_misc_ctrl_get, };
> > > > +
> > > > +static const struct scmi_protocol scmi_imx_misc = {
> > > > + .id = SCMI_PROTOCOL_IMX_MISC,
> > > > + .owner = THIS_MODULE,
> > > > + .instance_init = &scmi_imx_misc_protocol_init,
> > > > + .ops = &scmi_imx_misc_proto_ops,
> > > > + .events = &scmi_imx_misc_protocol_events,
> > > > + .supported_version = SCMI_PROTOCOL_SUPPORTED_VERSION, };
> > > > +module_scmi_protocol(scmi_imx_misc);
> > > > diff --git a/include/linux/scmi_imx_protocol.h
> > > > b/include/linux/scmi_imx_protocol.h
> > > > index 90ce011a4429..a69bd4a20f0f 100644
> > > > --- a/include/linux/scmi_imx_protocol.h
> > > > +++ b/include/linux/scmi_imx_protocol.h
> > > > @@ -13,8 +13,14 @@
> > > > #include <linux/notifier.h>
> > > > #include <linux/types.h>
> > > >
> > > > +#define SCMI_PAYLOAD_LEN 100
> > > > +
> > > > +#define SCMI_ARRAY(X, Y) ((SCMI_PAYLOAD_LEN - (X)) / sizeof(Y))
> > > > +#define MISC_MAX_VAL SCMI_ARRAY(8, uint32_t)
> > > > +
> > > > enum scmi_nxp_protocol {
> > > > SCMI_PROTOCOL_IMX_BBM = 0x81,
> > > > + SCMI_PROTOCOL_IMX_MISC = 0x84,
> > > > };
> > > >
> > > > struct scmi_imx_bbm_proto_ops {
> > > > @@ -42,4 +48,15 @@ struct scmi_imx_bbm_notif_report {
> > > > unsigned int rtc_id;
> > > > unsigned int rtc_evt;
> > > > };
> > > > +
> > > > +struct scmi_imx_misc_ctrl_notify_report {
> > > > + ktime_t timestamp;
> > > > + unsigned int ctrl_id;
> > > > + unsigned int flags;
> > > > +};
> > > > +
> > > > +struct scmi_imx_misc_proto_ops {
> > > > + int (*misc_ctrl_set)(const struct scmi_protocol_handle *ph, u32
> > > > +id,
> > > u32 num, u32 *val);
> > > > + int (*misc_ctrl_get)(const struct scmi_protocol_handle *ph, u32
> > > > +id,
> > > > +u32 *num, u32 *val); };
> > > > #endif
> > > >
> > > > --
> > > > 2.37.1
> > > >
> > > >
> > > >
> >
^ permalink raw reply
* Re: [PATCH v4 5/5] dmaengine: imx-sdma: Add i2c dma support
From: Vinod Koul @ 2024-04-07 11:20 UTC (permalink / raw)
To: Frank Li
Cc: Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
NXP Linux Team, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Joy Zou, dmaengine, linux-arm-kernel, linux-kernel, devicetree,
imx, Robin Gong, Clark Wang, Daniel Baluta
In-Reply-To: <20240329-sdma_upstream-v4-5-daeb3067dea7@nxp.com>
On 29-03-24, 10:34, Frank Li wrote:
> From: Robin Gong <yibin.gong@nxp.com>
>
> New sdma script (sdma-6q: v3.6, sdma-7d: v4.6) support i2c at imx8mp and
> imx6ull. So add I2C dma support.
>
> Signed-off-by: Robin Gong <yibin.gong@nxp.com>
> Acked-by: Clark Wang <xiaoning.wang@nxp.com>
> Reviewed-by: Joy Zou <joy.zou@nxp.com>
> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>
> Signed-off-by: Frank Li <Frank.Li@nxp.com>
> ---
> drivers/dma/imx-sdma.c | 7 +++++++
> include/linux/dma/imx-dma.h | 1 +
> 2 files changed, 8 insertions(+)
>
> diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
> index f68ab34a3c880..1ab8a7d3a50dc 100644
> --- a/drivers/dma/imx-sdma.c
> +++ b/drivers/dma/imx-sdma.c
> @@ -251,6 +251,8 @@ struct sdma_script_start_addrs {
> s32 sai_2_mcu_addr;
> s32 uart_2_mcu_rom_addr;
> s32 uartsh_2_mcu_rom_addr;
> + s32 i2c_2_mcu_addr;
> + s32 mcu_2_i2c_addr;
> /* End of v3 array */
> s32 mcu_2_zqspi_addr;
> /* End of v4 array */
> @@ -1081,6 +1083,11 @@ static int sdma_get_pc(struct sdma_channel *sdmac,
> per_2_emi = sdma->script_addrs->sai_2_mcu_addr;
> emi_2_per = sdma->script_addrs->mcu_2_sai_addr;
> break;
> + case IMX_DMATYPE_I2C:
> + per_2_emi = sdma->script_addrs->i2c_2_mcu_addr;
> + emi_2_per = sdma->script_addrs->mcu_2_i2c_addr;
> + sdmac->is_ram_script = true;
> + break;
> case IMX_DMATYPE_HDMI:
> emi_2_per = sdma->script_addrs->hdmi_dma_addr;
> sdmac->is_ram_script = true;
> diff --git a/include/linux/dma/imx-dma.h b/include/linux/dma/imx-dma.h
> index cfec5f946e237..76a8de9ae1517 100644
> --- a/include/linux/dma/imx-dma.h
> +++ b/include/linux/dma/imx-dma.h
> @@ -41,6 +41,7 @@ enum sdma_peripheral_type {
> IMX_DMATYPE_SAI, /* SAI */
> IMX_DMATYPE_MULTI_SAI, /* MULTI FIFOs For Audio */
> IMX_DMATYPE_HDMI, /* HDMI Audio */
> + IMX_DMATYPE_I2C, /* I2C */
I have HDMI Audio: 26 already?
--
~Vinod
^ permalink raw reply
* Re: [PATCH v4 4/5] dt-bindings: fsl-imx-sdma: Add I2C peripheral types ID
From: Vinod Koul @ 2024-04-07 11:21 UTC (permalink / raw)
To: Frank Li
Cc: Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
NXP Linux Team, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Joy Zou, dmaengine, linux-arm-kernel, linux-kernel, devicetree,
imx
In-Reply-To: <20240329-sdma_upstream-v4-4-daeb3067dea7@nxp.com>
On 29-03-24, 10:34, Frank Li wrote:
> Add peripheral types ID 26 for I2C because sdma firmware (sdma-6q: v3.6,
> sdma-7d: v4.6) support I2C DMA transfer.
>
> Signed-off-by: Frank Li <Frank.Li@nxp.com>
> ---
> Documentation/devicetree/bindings/dma/fsl,imx-sdma.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/dma/fsl,imx-sdma.yaml b/Documentation/devicetree/bindings/dma/fsl,imx-sdma.yaml
> index b95dd8db5a30a..80bcd3a6ecaf3 100644
> --- a/Documentation/devicetree/bindings/dma/fsl,imx-sdma.yaml
> +++ b/Documentation/devicetree/bindings/dma/fsl,imx-sdma.yaml
> @@ -93,6 +93,7 @@ properties:
> - Shared ASRC: 23
> - SAI: 24
> - HDMI Audio: 25
> + - I2C: 26
Sorry comment was for this patch, I have skipped these two now
>
> The third cell: transfer priority ID
> enum:
>
> --
> 2.34.1
--
~Vinod
^ permalink raw reply
* Re: [PATCH v2 4/6] firmware: arm_scmi: add initial support for i.MX MISC protocol
From: Marco Felsch @ 2024-04-07 11:02 UTC (permalink / raw)
To: Peng Fan
Cc: Peng Fan (OSS), Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Sudeep Holla, Cristian Marussi, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, imx@lists.linux.dev
In-Reply-To: <DU0PR04MB9417A07F56B7E14DAB3DCE2188012@DU0PR04MB9417.eurprd04.prod.outlook.com>
Hi Peng,
On 24-04-07, Peng Fan wrote:
> > Subject: Re: [PATCH v2 4/6] firmware: arm_scmi: add initial support for i.MX
> > MISC protocol
> >
> > Hi Peng,
> >
> > On 24-04-05, Peng Fan (OSS) wrote:
> > > From: Peng Fan <peng.fan@nxp.com>
> > >
> > > The i.MX MISC protocol is for misc settings, such as gpio expander
> > > wakeup.
> >
> > Can you elaborate a bit more please?
>
> The gpio expander is under M33(SCMI firmware used core) I2C control,
Due to missing technical references I guess that your specific EVK has
an i2c-expander connected to the system-critical-i2c bus? The
system-critical-i2c should be only used for system critical topics like
PMIC control.
> But the gpio expander supports board function such as PCIE_WAKEUP,
> BTN_WAKEUP. So these are managed by MISC protocol.
This seems more like an specific i.MX95-EVK problem too me since you
have conneccted the i2c-gpio-expander to the system-critical-i2c bus
instead of using an bus available within Linux. Also can you please
provide me a link with the propsoal for the MISC protocol? I can't find
any references within the SCMI v3.2
https://developer.arm.com/documentation/den0056/e/ nor within the SCP
firmware git: https://github.com/ARM-software/SCP-firmware.
> SAI_CLK_MSEL in WAKEUP BLK CTRL is also managed by MISC Protocol.
You recently said that we need blk-ctrl drivers for managing/controlling
the GPR stuff within Linux since the SCMI firmware does not support
this. Now blk-ctrl GPR control is supported by the firmware?
Regards,
Marco
>
> And etc...
>
> I will add more info in commit log in next version later, after I get more
> reviews on the patchset.
>
> Thanks,
> Peng.
>
> >
> > Regards,
> > Marco
> >
> >
> > >
> > > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> > > ---
> > > drivers/firmware/arm_scmi/Kconfig | 10 ++
> > > drivers/firmware/arm_scmi/Makefile | 1 +
> > > drivers/firmware/arm_scmi/imx-sm-misc.c | 305
> > ++++++++++++++++++++++++++++++++
> > > include/linux/scmi_imx_protocol.h | 17 ++
> > > 4 files changed, 333 insertions(+)
> > >
> > > diff --git a/drivers/firmware/arm_scmi/Kconfig
> > > b/drivers/firmware/arm_scmi/Kconfig
> > > index 56d11c9d9f47..bfeae92f6420 100644
> > > --- a/drivers/firmware/arm_scmi/Kconfig
> > > +++ b/drivers/firmware/arm_scmi/Kconfig
> > > @@ -191,3 +191,13 @@ config IMX_SCMI_BBM_EXT
> > > and BUTTON.
> > >
> > > This driver can also be built as a module.
> > > +
> > > +config IMX_SCMI_MISC_EXT
> > > + tristate "i.MX SCMI MISC EXTENSION"
> > > + depends on ARM_SCMI_PROTOCOL || (COMPILE_TEST && OF)
> > > + default y if ARCH_MXC
> > > + help
> > > + This enables i.MX System MISC control logic such as gpio expander
> > > + wakeup
> > > +
> > > + This driver can also be built as a module.
> > > diff --git a/drivers/firmware/arm_scmi/Makefile
> > > b/drivers/firmware/arm_scmi/Makefile
> > > index 327687acf857..a23fde721222 100644
> > > --- a/drivers/firmware/arm_scmi/Makefile
> > > +++ b/drivers/firmware/arm_scmi/Makefile
> > > @@ -12,6 +12,7 @@ scmi-transport-
> > $(CONFIG_ARM_SCMI_TRANSPORT_VIRTIO)
> > > += virtio.o
> > > scmi-transport-$(CONFIG_ARM_SCMI_TRANSPORT_OPTEE) += optee.o
> > > scmi-protocols-y = base.o clock.o perf.o power.o reset.o sensors.o
> > > system.o voltage.o powercap.o
> > > scmi-protocols-$(CONFIG_IMX_SCMI_BBM_EXT) += imx-sm-bbm.o
> > > +scmi-protocols-$(CONFIG_IMX_SCMI_MISC_EXT) += imx-sm-misc.o
> > > scmi-module-objs := $(scmi-driver-y) $(scmi-protocols-y)
> > > $(scmi-transport-y)
> > >
> > > obj-$(CONFIG_ARM_SCMI_PROTOCOL) += scmi-core.o diff --git
> > > a/drivers/firmware/arm_scmi/imx-sm-misc.c
> > > b/drivers/firmware/arm_scmi/imx-sm-misc.c
> > > new file mode 100644
> > > index 000000000000..1b0ec2281518
> > > --- /dev/null
> > > +++ b/drivers/firmware/arm_scmi/imx-sm-misc.c
> > > @@ -0,0 +1,305 @@
> > > +// SPDX-License-Identifier: GPL-2.0
> > > +/*
> > > + * System control and Management Interface (SCMI) NXP MISC Protocol
> > > + *
> > > + * Copyright 2024 NXP
> > > + */
> > > +
> > > +#define pr_fmt(fmt) "SCMI Notifications MISC - " fmt
> > > +
> > > +#include <linux/bits.h>
> > > +#include <linux/io.h>
> > > +#include <linux/module.h>
> > > +#include <linux/of.h>
> > > +#include <linux/platform_device.h>
> > > +#include <linux/scmi_protocol.h>
> > > +#include <linux/scmi_imx_protocol.h>
> > > +
> > > +#include "protocols.h"
> > > +#include "notify.h"
> > > +
> > > +#define SCMI_PROTOCOL_SUPPORTED_VERSION 0x10000
> > > +
> > > +enum scmi_imx_misc_protocol_cmd {
> > > + SCMI_IMX_MISC_CTRL_SET = 0x3,
> > > + SCMI_IMX_MISC_CTRL_GET = 0x4,
> > > + SCMI_IMX_MISC_CTRL_NOTIFY = 0x8,
> > > +};
> > > +
> > > +struct scmi_imx_misc_info {
> > > + u32 version;
> > > + u32 nr_dev_ctrl;
> > > + u32 nr_brd_ctrl;
> > > + u32 nr_reason;
> > > +};
> > > +
> > > +struct scmi_msg_imx_misc_protocol_attributes {
> > > + __le32 attributes;
> > > +};
> > > +
> > > +#define GET_BRD_CTRLS_NR(x) le32_get_bits((x), GENMASK(31,
> > 24))
> > > +#define GET_REASONS_NR(x) le32_get_bits((x), GENMASK(23, 16))
> > > +#define GET_DEV_CTRLS_NR(x) le32_get_bits((x), GENMASK(15, 0))
> > > +#define BRD_CTRL_START_ID BIT(15)
> > > +
> > > +struct scmi_imx_misc_ctrl_set_in {
> > > + __le32 id;
> > > + __le32 num;
> > > + __le32 value[MISC_MAX_VAL];
> > > +};
> > > +
> > > +struct scmi_imx_misc_ctrl_notify_in {
> > > + __le32 ctrl_id;
> > > + __le32 flags;
> > > +};
> > > +
> > > +struct scmi_imx_misc_ctrl_notify_payld {
> > > + __le32 ctrl_id;
> > > + __le32 flags;
> > > +};
> > > +
> > > +struct scmi_imx_misc_ctrl_get_out {
> > > + __le32 num;
> > > + __le32 *val;
> > > +};
> > > +
> > > +static int scmi_imx_misc_attributes_get(const struct scmi_protocol_handle
> > *ph,
> > > + struct scmi_imx_misc_info *mi)
> > > +{
> > > + int ret;
> > > + struct scmi_xfer *t;
> > > + struct scmi_msg_imx_misc_protocol_attributes *attr;
> > > +
> > > + ret = ph->xops->xfer_get_init(ph, PROTOCOL_ATTRIBUTES, 0,
> > > + sizeof(*attr), &t);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + attr = t->rx.buf;
> > > +
> > > + ret = ph->xops->do_xfer(ph, t);
> > > + if (!ret) {
> > > + mi->nr_dev_ctrl = GET_DEV_CTRLS_NR(attr->attributes);
> > > + mi->nr_brd_ctrl = GET_BRD_CTRLS_NR(attr->attributes);
> > > + mi->nr_reason = GET_REASONS_NR(attr->attributes);
> > > + dev_info(ph->dev, "i.MX MISC NUM DEV CTRL: %d, NUM
> > BRD CTRL: %d,NUM Reason: %d\n",
> > > + mi->nr_dev_ctrl, mi->nr_brd_ctrl, mi->nr_reason);
> > > + }
> > > +
> > > + ph->xops->xfer_put(ph, t);
> > > +
> > > + return ret;
> > > +}
> > > +
> > > +static int scmi_imx_misc_ctrl_validate_id(const struct
> > scmi_protocol_handle *ph,
> > > + u32 ctrl_id)
> > > +{
> > > + struct scmi_imx_misc_info *mi = ph->get_priv(ph);
> > > +
> > > + if ((ctrl_id < BRD_CTRL_START_ID) && (ctrl_id > mi->nr_dev_ctrl))
> > > + return -EINVAL;
> > > + if (ctrl_id >= BRD_CTRL_START_ID + mi->nr_brd_ctrl)
> > > + return -EINVAL;
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +static int scmi_imx_misc_ctrl_notify(const struct scmi_protocol_handle
> > *ph,
> > > + u32 ctrl_id, u32 flags)
> > > +{
> > > + struct scmi_imx_misc_ctrl_notify_in *in;
> > > + struct scmi_xfer *t;
> > > + int ret;
> > > +
> > > + ret = scmi_imx_misc_ctrl_validate_id(ph, ctrl_id);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + ret = ph->xops->xfer_get_init(ph, SCMI_IMX_MISC_CTRL_NOTIFY,
> > > + sizeof(*in), 0, &t);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + in = t->tx.buf;
> > > + in->ctrl_id = cpu_to_le32(ctrl_id);
> > > + in->flags = cpu_to_le32(flags);
> > > +
> > > + ret = ph->xops->do_xfer(ph, t);
> > > +
> > > + ph->xops->xfer_put(ph, t);
> > > +
> > > + return ret;
> > > +}
> > > +
> > > +static int
> > > +scmi_imx_misc_ctrl_set_notify_enabled(const struct
> > scmi_protocol_handle *ph,
> > > + u8 evt_id, u32 src_id, bool enable) {
> > > + int ret;
> > > +
> > > + ret = scmi_imx_misc_ctrl_notify(ph, src_id, enable ? evt_id : 0);
> > > + if (ret)
> > > + dev_err(ph->dev, "FAIL_ENABLED - evt[%X] src[%d] -
> > ret:%d\n",
> > > + evt_id, src_id, ret);
> > > +
> > > + return ret;
> > > +}
> > > +
> > > +static int scmi_imx_misc_ctrl_get_num_sources(const struct
> > > +scmi_protocol_handle *ph) {
> > > + return GENMASK(15, 0);
> > > +}
> > > +
> > > +static void *
> > > +scmi_imx_misc_ctrl_fill_custom_report(const struct scmi_protocol_handle
> > *ph,
> > > + u8 evt_id, ktime_t timestamp,
> > > + const void *payld, size_t payld_sz,
> > > + void *report, u32 *src_id)
> > > +{
> > > + const struct scmi_imx_misc_ctrl_notify_payld *p = payld;
> > > + struct scmi_imx_misc_ctrl_notify_report *r = report;
> > > +
> > > + if (sizeof(*p) != payld_sz)
> > > + return NULL;
> > > +
> > > + r->timestamp = timestamp;
> > > + r->ctrl_id = p->ctrl_id;
> > > + r->flags = p->flags;
> > > + *src_id = r->ctrl_id;
> > > + dev_dbg(ph->dev, "%s: ctrl_id: %d flags: %d\n", __func__,
> > > + r->ctrl_id, r->flags);
> > > +
> > > + return r;
> > > +}
> > > +
> > > +static const struct scmi_event_ops scmi_imx_misc_event_ops = {
> > > + .get_num_sources = scmi_imx_misc_ctrl_get_num_sources,
> > > + .set_notify_enabled = scmi_imx_misc_ctrl_set_notify_enabled,
> > > + .fill_custom_report = scmi_imx_misc_ctrl_fill_custom_report,
> > > +};
> > > +
> > > +static const struct scmi_event scmi_imx_misc_events[] = {
> > > + {
> > > + .id = SCMI_EVENT_IMX_MISC_CONTROL_DISABLED,
> > > + .max_payld_sz = sizeof(struct
> > scmi_imx_misc_ctrl_notify_payld),
> > > + .max_report_sz = sizeof(struct
> > scmi_imx_misc_ctrl_notify_report),
> > > + },
> > > + {
> > > + .id = SCMI_EVENT_IMX_MISC_CONTROL_FALLING_EDGE,
> > > + .max_payld_sz = sizeof(struct
> > scmi_imx_misc_ctrl_notify_payld),
> > > + .max_report_sz = sizeof(struct
> > scmi_imx_misc_ctrl_notify_report),
> > > + },
> > > + {
> > > + .id = SCMI_EVENT_IMX_MISC_CONTROL_RISING_EDGE,
> > > + .max_payld_sz = sizeof(struct
> > scmi_imx_misc_ctrl_notify_payld),
> > > + .max_report_sz = sizeof(struct
> > scmi_imx_misc_ctrl_notify_report),
> > > + }
> > > +};
> > > +
> > > +static struct scmi_protocol_events scmi_imx_misc_protocol_events = {
> > > + .queue_sz = SCMI_PROTO_QUEUE_SZ,
> > > + .ops = &scmi_imx_misc_event_ops,
> > > + .evts = scmi_imx_misc_events,
> > > + .num_events = ARRAY_SIZE(scmi_imx_misc_events), };
> > > +
> > > +static int scmi_imx_misc_protocol_init(const struct
> > > +scmi_protocol_handle *ph) {
> > > + struct scmi_imx_misc_info *minfo;
> > > + u32 version;
> > > + int ret;
> > > +
> > > + ret = ph->xops->version_get(ph, &version);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + dev_info(ph->dev, "NXP SM MISC Version %d.%d\n",
> > > + PROTOCOL_REV_MAJOR(version),
> > PROTOCOL_REV_MINOR(version));
> > > +
> > > + minfo = devm_kzalloc(ph->dev, sizeof(*minfo), GFP_KERNEL);
> > > + if (!minfo)
> > > + return -ENOMEM;
> > > +
> > > + ret = scmi_imx_misc_attributes_get(ph, minfo);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + return ph->set_priv(ph, minfo, version); }
> > > +
> > > +static int scmi_imx_misc_ctrl_get(const struct scmi_protocol_handle *ph,
> > > + u32 ctrl_id, u32 *num, u32 *val) {
> > > + struct scmi_imx_misc_ctrl_get_out *out;
> > > + struct scmi_xfer *t;
> > > + int ret, i;
> > > +
> > > + ret = scmi_imx_misc_ctrl_validate_id(ph, ctrl_id);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + ret = ph->xops->xfer_get_init(ph, SCMI_IMX_MISC_CTRL_GET,
> > sizeof(u32),
> > > + 0, &t);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + put_unaligned_le32(ctrl_id, t->tx.buf);
> > > + ret = ph->xops->do_xfer(ph, t);
> > > + if (!ret) {
> > > + out = t->rx.buf;
> > > + *num = le32_to_cpu(out->num);
> > > + for (i = 0; i < *num && i < MISC_MAX_VAL; i++)
> > > + val[i] = le32_to_cpu(out->val[i]);
> > > + }
> > > +
> > > + ph->xops->xfer_put(ph, t);
> > > +
> > > + return ret;
> > > +}
> > > +
> > > +static int scmi_imx_misc_ctrl_set(const struct scmi_protocol_handle *ph,
> > > + u32 ctrl_id, u32 num, u32 *val) {
> > > + struct scmi_imx_misc_ctrl_set_in *in;
> > > + struct scmi_xfer *t;
> > > + int ret, i;
> > > +
> > > + ret = scmi_imx_misc_ctrl_validate_id(ph, ctrl_id);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + if (num > MISC_MAX_VAL)
> > > + return -EINVAL;
> > > +
> > > + ret = ph->xops->xfer_get_init(ph, SCMI_IMX_MISC_CTRL_SET,
> > sizeof(*in),
> > > + 0, &t);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + in = t->tx.buf;
> > > + in->id = cpu_to_le32(ctrl_id);
> > > + in->num = cpu_to_le32(num);
> > > + for (i = 0; i < num; i++)
> > > + in->value[i] = cpu_to_le32(val[i]);
> > > +
> > > + ret = ph->xops->do_xfer(ph, t);
> > > +
> > > + ph->xops->xfer_put(ph, t);
> > > +
> > > + return ret;
> > > +}
> > > +
> > > +static const struct scmi_imx_misc_proto_ops scmi_imx_misc_proto_ops =
> > {
> > > + .misc_ctrl_set = scmi_imx_misc_ctrl_set,
> > > + .misc_ctrl_get = scmi_imx_misc_ctrl_get, };
> > > +
> > > +static const struct scmi_protocol scmi_imx_misc = {
> > > + .id = SCMI_PROTOCOL_IMX_MISC,
> > > + .owner = THIS_MODULE,
> > > + .instance_init = &scmi_imx_misc_protocol_init,
> > > + .ops = &scmi_imx_misc_proto_ops,
> > > + .events = &scmi_imx_misc_protocol_events,
> > > + .supported_version = SCMI_PROTOCOL_SUPPORTED_VERSION, };
> > > +module_scmi_protocol(scmi_imx_misc);
> > > diff --git a/include/linux/scmi_imx_protocol.h
> > > b/include/linux/scmi_imx_protocol.h
> > > index 90ce011a4429..a69bd4a20f0f 100644
> > > --- a/include/linux/scmi_imx_protocol.h
> > > +++ b/include/linux/scmi_imx_protocol.h
> > > @@ -13,8 +13,14 @@
> > > #include <linux/notifier.h>
> > > #include <linux/types.h>
> > >
> > > +#define SCMI_PAYLOAD_LEN 100
> > > +
> > > +#define SCMI_ARRAY(X, Y) ((SCMI_PAYLOAD_LEN - (X)) / sizeof(Y))
> > > +#define MISC_MAX_VAL SCMI_ARRAY(8, uint32_t)
> > > +
> > > enum scmi_nxp_protocol {
> > > SCMI_PROTOCOL_IMX_BBM = 0x81,
> > > + SCMI_PROTOCOL_IMX_MISC = 0x84,
> > > };
> > >
> > > struct scmi_imx_bbm_proto_ops {
> > > @@ -42,4 +48,15 @@ struct scmi_imx_bbm_notif_report {
> > > unsigned int rtc_id;
> > > unsigned int rtc_evt;
> > > };
> > > +
> > > +struct scmi_imx_misc_ctrl_notify_report {
> > > + ktime_t timestamp;
> > > + unsigned int ctrl_id;
> > > + unsigned int flags;
> > > +};
> > > +
> > > +struct scmi_imx_misc_proto_ops {
> > > + int (*misc_ctrl_set)(const struct scmi_protocol_handle *ph, u32 id,
> > u32 num, u32 *val);
> > > + int (*misc_ctrl_get)(const struct scmi_protocol_handle *ph, u32 id,
> > > +u32 *num, u32 *val); };
> > > #endif
> > >
> > > --
> > > 2.37.1
> > >
> > >
> > >
>
^ permalink raw reply
* Re: [PATCH v6 2/3] soc/sophgo: add top sysctrl layout file for CV18XX/SG200X
From: Vinod Koul @ 2024-04-07 11:23 UTC (permalink / raw)
To: Inochi Amaoto
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen Wang,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Jisheng Zhang, Liu Gui,
Jingbao Qiu, dlan, dmaengine, devicetree, linux-kernel,
linux-riscv
In-Reply-To: <IA1PR20MB49532FB358A842A2ACC5E878BB3A2@IA1PR20MB4953.namprd20.prod.outlook.com>
On 29-03-24, 10:04, Inochi Amaoto wrote:
> The "top" system controller of CV18XX/SG200X exposes control
> register access for various devices. Add soc header file to
> describe it.
>
> Signed-off-by: Inochi Amaoto <inochiama@outlook.com>
> ---
> include/soc/sophgo/cv1800-sysctl.h | 30 ++++++++++++++++++++++++++++++
> 1 file changed, 30 insertions(+)
> create mode 100644 include/soc/sophgo/cv1800-sysctl.h
>
> diff --git a/include/soc/sophgo/cv1800-sysctl.h b/include/soc/sophgo/cv1800-sysctl.h
> new file mode 100644
> index 000000000000..b9396d33e240
> --- /dev/null
> +++ b/include/soc/sophgo/cv1800-sysctl.h
> @@ -0,0 +1,30 @@
> +/* SPDX-License-Identifier: GPL-2.0-or-later */
> +/*
> + * Copyright (C) 2023 Inochi Amaoto <inochiama@outlook.com>
> + */
> +
> +#ifndef CV1800_SYSCTL_H
> +#define CV1800_SYSCTL_H
> +
> +/*
> + * SOPHGO CV1800/SG2000 SoC top system controller registers offsets.
> + */
> +
> +#define CV1800_CONF_INFO 0x004
> +#define CV1800_SYS_CTRL_REG 0x008
> +#define CV1800_USB_PHY_CTRL_REG 0x048
> +#define CV1800_SDMA_DMA_CHANNEL_REMAP0 0x154
> +#define CV1800_SDMA_DMA_CHANNEL_REMAP1 0x158
> +#define CV1800_TOP_TIMER_CLK_SEL 0x1a0
> +#define CV1800_TOP_WDT_CTRL 0x1a8
> +#define CV1800_DDR_AXI_URGENT_OW 0x1b8
> +#define CV1800_DDR_AXI_URGENT 0x1bc
> +#define CV1800_DDR_AXI_QOS_0 0x1d8
> +#define CV1800_DDR_AXI_QOS_1 0x1dc
> +#define CV1800_SD_PWRSW_CTRL 0x1f4
> +#define CV1800_SD_PWRSW_TIME 0x1f8
> +#define CV1800_DDR_AXI_QOS_OW 0x23c
> +#define CV1800_SD_CTRL_OPT 0x294
> +#define CV1800_SDMA_DMA_INT_MUX 0x298
Why are these register defines in soc, all the dma registers should
belong to dma driver and other IPs, why do you need a common header??
--
~Vinod
^ permalink raw reply
* Re: [PATCH v6 3/3] dmaengine: add driver for Sophgo CV18XX/SG200X dmamux
From: Vinod Koul @ 2024-04-07 11:29 UTC (permalink / raw)
To: Inochi Amaoto
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen Wang,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Jisheng Zhang, Liu Gui,
Jingbao Qiu, dlan, dmaengine, devicetree, linux-kernel,
linux-riscv
In-Reply-To: <IA1PR20MB4953AE1184DD09F9203C665CBB3A2@IA1PR20MB4953.namprd20.prod.outlook.com>
On 29-03-24, 10:04, Inochi Amaoto wrote:
> Sophgo CV18XX/SG200X use DW AXI CORE with a multiplexer for remapping
> its request lines. The multiplexer supports at most 8 request lines.
>
> Add driver for Sophgo CV18XX/SG200X DMA multiplexer.
>
> Signed-off-by: Inochi Amaoto <inochiama@outlook.com>
> ---
> drivers/dma/Kconfig | 9 ++
> drivers/dma/Makefile | 1 +
> drivers/dma/cv1800-dmamux.c | 267 ++++++++++++++++++++++++++++++++++++
> 3 files changed, 277 insertions(+)
> create mode 100644 drivers/dma/cv1800-dmamux.c
>
> diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
> index 002a5ec80620..cb31520b9f86 100644
> --- a/drivers/dma/Kconfig
> +++ b/drivers/dma/Kconfig
> @@ -546,6 +546,15 @@ config PLX_DMA
> These are exposed via extra functions on the switch's
> upstream port. Each function exposes one DMA channel.
>
> +config SOPHGO_CV1800_DMAMUX
> + tristate "Sophgo CV1800/SG2000 series SoC DMA multiplexer support"
> + depends on MFD_SYSCON
> + depends on ARCH_SOPHGO
> + help
> + Support for the DMA multiplexer on Sophgo CV1800/SG2000
> + series SoCs.
> + Say Y here if your board have this soc.
> +
> config STE_DMA40
> bool "ST-Ericsson DMA40 support"
> depends on ARCH_U8500
> diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
> index dfd40d14e408..7465f249ee47 100644
> --- a/drivers/dma/Makefile
> +++ b/drivers/dma/Makefile
> @@ -67,6 +67,7 @@ obj-$(CONFIG_PPC_BESTCOMM) += bestcomm/
> obj-$(CONFIG_PXA_DMA) += pxa_dma.o
> obj-$(CONFIG_RENESAS_DMA) += sh/
> obj-$(CONFIG_SF_PDMA) += sf-pdma/
> +obj-$(CONFIG_SOPHGO_CV1800_DMAMUX) += cv1800-dmamux.o
> obj-$(CONFIG_STE_DMA40) += ste_dma40.o ste_dma40_ll.o
> obj-$(CONFIG_STM32_DMA) += stm32-dma.o
> obj-$(CONFIG_STM32_DMAMUX) += stm32-dmamux.o
> diff --git a/drivers/dma/cv1800-dmamux.c b/drivers/dma/cv1800-dmamux.c
> new file mode 100644
> index 000000000000..709414898b67
> --- /dev/null
> +++ b/drivers/dma/cv1800-dmamux.c
> @@ -0,0 +1,267 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2023 Inochi Amaoto <inochiama@outlook.com>
2024
> + */
> +
> +#include <linux/bitops.h>
> +#include <linux/module.h>
> +#include <linux/of_dma.h>
> +#include <linux/of_address.h>
> +#include <linux/of_platform.h>
> +#include <linux/platform_device.h>
> +#include <linux/llist.h>
> +#include <linux/regmap.h>
> +#include <linux/spinlock.h>
> +#include <linux/mfd/syscon.h>
> +
> +#include <soc/sophgo/cv1800-sysctl.h>
> +
> +#define DMAMUX_NCELLS 2
> +#define MAX_DMA_MAPPING_ID 42
> +#define MAX_DMA_CPU_ID 2
> +#define MAX_DMA_CH_ID 7
> +
> +#define DMAMUX_INTMUX_REGISTER_LEN 4
> +#define DMAMUX_NR_CH_PER_REGISTER 4
> +#define DMAMUX_BIT_PER_CH 8
> +#define DMAMUX_CH_MASk GENMASK(5, 0)
> +#define DMAMUX_INT_BIT_PER_CPU 10
> +#define DMAMUX_CH_UPDATE_BIT BIT(31)
> +
> +#define DMAMUX_CH_REGPOS(chid) \
> + ((chid) / DMAMUX_NR_CH_PER_REGISTER)
> +#define DMAMUX_CH_REGOFF(chid) \
> + ((chid) % DMAMUX_NR_CH_PER_REGISTER)
> +#define DMAMUX_CH_REG(chid) \
> + ((DMAMUX_CH_REGPOS(chid) * sizeof(u32)) + \
> + CV1800_SDMA_DMA_CHANNEL_REMAP0)
> +#define DMAMUX_CH_SET(chid, val) \
> + (((val) << (DMAMUX_CH_REGOFF(chid) * DMAMUX_BIT_PER_CH)) | \
> + DMAMUX_CH_UPDATE_BIT)
> +#define DMAMUX_CH_MASK(chid) \
> + DMAMUX_CH_SET(chid, DMAMUX_CH_MASk)
> +
> +#define DMAMUX_INT_BIT(chid, cpuid) \
> + BIT((cpuid) * DMAMUX_INT_BIT_PER_CPU + (chid))
> +#define DMAMUX_INTEN_BIT(cpuid) \
> + DMAMUX_INT_BIT(8, cpuid)
> +#define DMAMUX_INT_CH_BIT(chid, cpuid) \
> + (DMAMUX_INT_BIT(chid, cpuid) | DMAMUX_INTEN_BIT(cpuid))
> +#define DMAMUX_INT_MASK(chid) \
> + (DMAMUX_INT_BIT(chid, 0) | \
> + DMAMUX_INT_BIT(chid, 1) | \
> + DMAMUX_INT_BIT(chid, 2))
> +#define DMAMUX_INT_CH_MASK(chid, cpuid) \
> + (DMAMUX_INT_MASK(chid) | DMAMUX_INTEN_BIT(cpuid))
> +
> +struct cv1800_dmamux_data {
> + struct dma_router dmarouter;
> + struct regmap *regmap;
> + spinlock_t lock;
> + struct llist_head free_maps;
> + struct llist_head reserve_maps;
> + DECLARE_BITMAP(mapped_peripherals, MAX_DMA_MAPPING_ID);
> +};
> +
> +struct cv1800_dmamux_map {
> + struct llist_node node;
> + unsigned int channel;
> + unsigned int peripheral;
> + unsigned int cpu;
> +};
> +
> +static void cv1800_dmamux_free(struct device *dev, void *route_data)
> +{
> + struct cv1800_dmamux_data *dmamux = dev_get_drvdata(dev);
> + struct cv1800_dmamux_map *map = route_data;
> + unsigned long flags;
> +
> + spin_lock_irqsave(&dmamux->lock, flags);
> +
> + regmap_update_bits(dmamux->regmap,
> + DMAMUX_CH_REG(map->channel),
> + DMAMUX_CH_MASK(map->channel),
> + DMAMUX_CH_UPDATE_BIT);
> +
> + regmap_update_bits(dmamux->regmap, CV1800_SDMA_DMA_INT_MUX,
> + DMAMUX_INT_CH_MASK(map->channel, map->cpu),
> + DMAMUX_INTEN_BIT(map->cpu));
> +
> + spin_unlock_irqrestore(&dmamux->lock, flags);
> +
> + dev_info(dev, "free channel %u for req %u (cpu %u)\n",
> + map->channel, map->peripheral, map->cpu);
debug at most please
> +}
> +
> +static void *cv1800_dmamux_route_allocate(struct of_phandle_args *dma_spec,
> + struct of_dma *ofdma)
> +{
> + struct platform_device *pdev = of_find_device_by_node(ofdma->of_node);
> + struct cv1800_dmamux_data *dmamux = platform_get_drvdata(pdev);
> + struct cv1800_dmamux_map *map;
> + struct llist_node *node;
> + unsigned long flags;
> + unsigned int chid, devid, cpuid;
> + int ret;
> +
> + if (dma_spec->args_count != DMAMUX_NCELLS) {
> + dev_err(&pdev->dev, "invalid number of dma mux args\n");
> + return ERR_PTR(-EINVAL);
> + }
> +
> + devid = dma_spec->args[0];
> + cpuid = dma_spec->args[1];
> + dma_spec->args_count = 1;
> +
> + if (devid > MAX_DMA_MAPPING_ID) {
> + dev_err(&pdev->dev, "invalid device id: %u\n", devid);
> + return ERR_PTR(-EINVAL);
> + }
> +
> + if (cpuid > MAX_DMA_CPU_ID) {
> + dev_err(&pdev->dev, "invalid cpu id: %u\n", cpuid);
> + return ERR_PTR(-EINVAL);
> + }
> +
> + dma_spec->np = of_parse_phandle(ofdma->of_node, "dma-masters", 0);
> + if (!dma_spec->np) {
> + dev_err(&pdev->dev, "can't get dma master\n");
> + return ERR_PTR(-EINVAL);
> + }
> +
> + spin_lock_irqsave(&dmamux->lock, flags);
> +
> + if (test_bit(devid, dmamux->mapped_peripherals)) {
> + llist_for_each_entry(map, dmamux->reserve_maps.first, node) {
> + if (map->peripheral == devid && map->cpu == cpuid)
> + goto found;
> + }
> +
> + ret = -EINVAL;
> + goto failed;
> + } else {
> + node = llist_del_first(&dmamux->free_maps);
> + if (!node) {
> + ret = -ENODEV;
> + goto failed;
> + }
> +
> + map = llist_entry(node, struct cv1800_dmamux_map, node);
> + llist_add(&map->node, &dmamux->reserve_maps);
> + set_bit(devid, dmamux->mapped_peripherals);
> + }
> +
> +found:
> + chid = map->channel;
> + map->peripheral = devid;
> + map->cpu = cpuid;
> +
> + regmap_set_bits(dmamux->regmap,
> + DMAMUX_CH_REG(chid),
> + DMAMUX_CH_SET(chid, devid));
> +
> + regmap_update_bits(dmamux->regmap, CV1800_SDMA_DMA_INT_MUX,
> + DMAMUX_INT_CH_MASK(chid, cpuid),
> + DMAMUX_INT_CH_BIT(chid, cpuid));
> +
> + spin_unlock_irqrestore(&dmamux->lock, flags);
> +
> + dma_spec->args[0] = chid;
> +
> + dev_info(&pdev->dev, "register channel %u for req %u (cpu %u)\n",
> + chid, devid, cpuid);
Here as well
> +
> + return map;
> +
> +failed:
> + spin_unlock_irqrestore(&dmamux->lock, flags);
> + of_node_put(dma_spec->np);
> + dev_err(&pdev->dev, "errno %d\n", ret);
> + return ERR_PTR(ret);
> +
> +}
> +
> +static int cv1800_dmamux_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct device_node *mux_node = dev->of_node;
> + struct cv1800_dmamux_data *data;
> + struct cv1800_dmamux_map *tmp;
> + struct device *parent = dev->parent;
> + struct device_node *dma_master;
> + struct regmap *regmap = NULL;
> + unsigned int i;
> +
> + if (!parent)
> + return -ENODEV;
> +
> + regmap = device_node_to_regmap(parent->of_node);
> + if (IS_ERR(regmap))
> + return PTR_ERR(regmap);
> +
> + dma_master = of_parse_phandle(mux_node, "dma-masters", 0);
> + if (!dma_master) {
> + dev_err(dev, "invalid dma-requests property\n");
> + return -ENODEV;
> + }
> + of_node_put(dma_master);
why do this if you dont need it??
> +
> + data = devm_kmalloc(dev, sizeof(*data), GFP_KERNEL);
> + if (!data)
> + return -ENOMEM;
> +
> + spin_lock_init(&data->lock);
> + init_llist_head(&data->free_maps);
> +
> + for (i = 0; i <= MAX_DMA_CH_ID; i++) {
> + tmp = devm_kmalloc(dev, sizeof(*tmp), GFP_KERNEL);
> + if (!tmp) {
> + /* It is OK for not allocating all channel */
> + dev_warn(dev, "can not allocate channel %u\n", i);
> + continue;
> + }
> +
> + init_llist_node(&tmp->node);
> + tmp->channel = i;
> + llist_add(&tmp->node, &data->free_maps);
> + }
> +
> + /* if no channel is allocated, the probe must fail */
> + if (llist_empty(&data->free_maps))
> + return -ENOMEM;
> +
> + data->regmap = regmap;
> + data->dmarouter.dev = dev;
> + data->dmarouter.route_free = cv1800_dmamux_free;
> +
> + platform_set_drvdata(pdev, data);
> +
> + return of_dma_router_register(mux_node,
> + cv1800_dmamux_route_allocate,
> + &data->dmarouter);
> +}
> +
> +static void cv1800_dmamux_remove(struct platform_device *pdev)
> +{
> + of_dma_controller_free(pdev->dev.of_node);
> +}
> +
> +static const struct of_device_id cv1800_dmamux_ids[] = {
> + { .compatible = "sophgo,cv1800-dmamux", },
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, cv1800_dmamux_ids);
> +
> +static struct platform_driver cv1800_dmamux_driver = {
> + .driver = {
> + .name = "cv1800-dmamux",
> + .of_match_table = cv1800_dmamux_ids,
> + },
> + .probe = cv1800_dmamux_probe,
> + .remove_new = cv1800_dmamux_remove,
> +};
> +module_platform_driver(cv1800_dmamux_driver);
> +
> +MODULE_AUTHOR("Inochi Amaoto <inochiama@outlook.com>");
> +MODULE_DESCRIPTION("Sophgo CV1800/SG2000 Series Soc DMAMUX driver");
> +MODULE_LICENSE("GPL");
> --
> 2.44.0
--
~Vinod
^ permalink raw reply
* Re: [PATCH v6 2/3] soc/sophgo: add top sysctrl layout file for CV18XX/SG200X
From: Inochi Amaoto @ 2024-04-07 11:36 UTC (permalink / raw)
To: Vinod Koul, Inochi Amaoto
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen Wang,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Jisheng Zhang, Liu Gui,
Jingbao Qiu, dlan, dmaengine, devicetree, linux-kernel,
linux-riscv
In-Reply-To: <ZhKCHlAYxnhhcKnt@matsya>
On Sun, Apr 07, 2024 at 04:53:10PM +0530, Vinod Koul wrote:
> On 29-03-24, 10:04, Inochi Amaoto wrote:
> > The "top" system controller of CV18XX/SG200X exposes control
> > register access for various devices. Add soc header file to
> > describe it.
> >
> > Signed-off-by: Inochi Amaoto <inochiama@outlook.com>
> > ---
> > include/soc/sophgo/cv1800-sysctl.h | 30 ++++++++++++++++++++++++++++++
> > 1 file changed, 30 insertions(+)
> > create mode 100644 include/soc/sophgo/cv1800-sysctl.h
> >
> > diff --git a/include/soc/sophgo/cv1800-sysctl.h b/include/soc/sophgo/cv1800-sysctl.h
> > new file mode 100644
> > index 000000000000..b9396d33e240
> > --- /dev/null
> > +++ b/include/soc/sophgo/cv1800-sysctl.h
> > @@ -0,0 +1,30 @@
> > +/* SPDX-License-Identifier: GPL-2.0-or-later */
> > +/*
> > + * Copyright (C) 2023 Inochi Amaoto <inochiama@outlook.com>
> > + */
> > +
> > +#ifndef CV1800_SYSCTL_H
> > +#define CV1800_SYSCTL_H
> > +
> > +/*
> > + * SOPHGO CV1800/SG2000 SoC top system controller registers offsets.
> > + */
> > +
> > +#define CV1800_CONF_INFO 0x004
> > +#define CV1800_SYS_CTRL_REG 0x008
> > +#define CV1800_USB_PHY_CTRL_REG 0x048
> > +#define CV1800_SDMA_DMA_CHANNEL_REMAP0 0x154
> > +#define CV1800_SDMA_DMA_CHANNEL_REMAP1 0x158
> > +#define CV1800_TOP_TIMER_CLK_SEL 0x1a0
> > +#define CV1800_TOP_WDT_CTRL 0x1a8
> > +#define CV1800_DDR_AXI_URGENT_OW 0x1b8
> > +#define CV1800_DDR_AXI_URGENT 0x1bc
> > +#define CV1800_DDR_AXI_QOS_0 0x1d8
> > +#define CV1800_DDR_AXI_QOS_1 0x1dc
> > +#define CV1800_SD_PWRSW_CTRL 0x1f4
> > +#define CV1800_SD_PWRSW_TIME 0x1f8
> > +#define CV1800_DDR_AXI_QOS_OW 0x23c
> > +#define CV1800_SD_CTRL_OPT 0x294
> > +#define CV1800_SDMA_DMA_INT_MUX 0x298
>
> Why are these register defines in soc, all the dma registers should
> belong to dma driver and other IPs, why do you need a common header??
>
> --
> ~Vinod
This multiplexer is not a standalone device, instead, it is a
subdevice of the syscon. Although it is better to add this
header to the syscon series, the dma multiplexer driver itself
depends this header. So I add the header to this series.
Regards,
Inochi
^ permalink raw reply
* Re: [PATCH v6 3/3] dmaengine: add driver for Sophgo CV18XX/SG200X dmamux
From: Inochi Amaoto @ 2024-04-07 11:57 UTC (permalink / raw)
To: Vinod Koul, Inochi Amaoto
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen Wang,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Jisheng Zhang, Liu Gui,
Jingbao Qiu, dlan, dmaengine, devicetree, linux-kernel,
linux-riscv
In-Reply-To: <ZhKDo0GCpvffUcd8@matsya>
On Sun, Apr 07, 2024 at 04:59:39PM +0530, Vinod Koul wrote:
> On 29-03-24, 10:04, Inochi Amaoto wrote:
> > Sophgo CV18XX/SG200X use DW AXI CORE with a multiplexer for remapping
> > its request lines. The multiplexer supports at most 8 request lines.
> >
> > Add driver for Sophgo CV18XX/SG200X DMA multiplexer.
> >
> > Signed-off-by: Inochi Amaoto <inochiama@outlook.com>
> > ---
> > drivers/dma/Kconfig | 9 ++
> > drivers/dma/Makefile | 1 +
> > drivers/dma/cv1800-dmamux.c | 267 ++++++++++++++++++++++++++++++++++++
> > 3 files changed, 277 insertions(+)
> > create mode 100644 drivers/dma/cv1800-dmamux.c
> >
> > diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
> > index 002a5ec80620..cb31520b9f86 100644
> > --- a/drivers/dma/Kconfig
> > +++ b/drivers/dma/Kconfig
> > @@ -546,6 +546,15 @@ config PLX_DMA
> > These are exposed via extra functions on the switch's
> > upstream port. Each function exposes one DMA channel.
> >
> > +config SOPHGO_CV1800_DMAMUX
> > + tristate "Sophgo CV1800/SG2000 series SoC DMA multiplexer support"
> > + depends on MFD_SYSCON
> > + depends on ARCH_SOPHGO
> > + help
> > + Support for the DMA multiplexer on Sophgo CV1800/SG2000
> > + series SoCs.
> > + Say Y here if your board have this soc.
> > +
> > config STE_DMA40
> > bool "ST-Ericsson DMA40 support"
> > depends on ARCH_U8500
> > diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
> > index dfd40d14e408..7465f249ee47 100644
> > --- a/drivers/dma/Makefile
> > +++ b/drivers/dma/Makefile
> > @@ -67,6 +67,7 @@ obj-$(CONFIG_PPC_BESTCOMM) += bestcomm/
> > obj-$(CONFIG_PXA_DMA) += pxa_dma.o
> > obj-$(CONFIG_RENESAS_DMA) += sh/
> > obj-$(CONFIG_SF_PDMA) += sf-pdma/
> > +obj-$(CONFIG_SOPHGO_CV1800_DMAMUX) += cv1800-dmamux.o
> > obj-$(CONFIG_STE_DMA40) += ste_dma40.o ste_dma40_ll.o
> > obj-$(CONFIG_STM32_DMA) += stm32-dma.o
> > obj-$(CONFIG_STM32_DMAMUX) += stm32-dmamux.o
> > diff --git a/drivers/dma/cv1800-dmamux.c b/drivers/dma/cv1800-dmamux.c
> > new file mode 100644
> > index 000000000000..709414898b67
> > --- /dev/null
> > +++ b/drivers/dma/cv1800-dmamux.c
> > @@ -0,0 +1,267 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (C) 2023 Inochi Amaoto <inochiama@outlook.com>
>
> 2024
>
> > + */
> > +
> > +#include <linux/bitops.h>
> > +#include <linux/module.h>
> > +#include <linux/of_dma.h>
> > +#include <linux/of_address.h>
> > +#include <linux/of_platform.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/llist.h>
> > +#include <linux/regmap.h>
> > +#include <linux/spinlock.h>
> > +#include <linux/mfd/syscon.h>
> > +
> > +#include <soc/sophgo/cv1800-sysctl.h>
> > +
> > +#define DMAMUX_NCELLS 2
> > +#define MAX_DMA_MAPPING_ID 42
> > +#define MAX_DMA_CPU_ID 2
> > +#define MAX_DMA_CH_ID 7
> > +
> > +#define DMAMUX_INTMUX_REGISTER_LEN 4
> > +#define DMAMUX_NR_CH_PER_REGISTER 4
> > +#define DMAMUX_BIT_PER_CH 8
> > +#define DMAMUX_CH_MASk GENMASK(5, 0)
> > +#define DMAMUX_INT_BIT_PER_CPU 10
> > +#define DMAMUX_CH_UPDATE_BIT BIT(31)
> > +
> > +#define DMAMUX_CH_REGPOS(chid) \
> > + ((chid) / DMAMUX_NR_CH_PER_REGISTER)
> > +#define DMAMUX_CH_REGOFF(chid) \
> > + ((chid) % DMAMUX_NR_CH_PER_REGISTER)
> > +#define DMAMUX_CH_REG(chid) \
> > + ((DMAMUX_CH_REGPOS(chid) * sizeof(u32)) + \
> > + CV1800_SDMA_DMA_CHANNEL_REMAP0)
> > +#define DMAMUX_CH_SET(chid, val) \
> > + (((val) << (DMAMUX_CH_REGOFF(chid) * DMAMUX_BIT_PER_CH)) | \
> > + DMAMUX_CH_UPDATE_BIT)
> > +#define DMAMUX_CH_MASK(chid) \
> > + DMAMUX_CH_SET(chid, DMAMUX_CH_MASk)
> > +
> > +#define DMAMUX_INT_BIT(chid, cpuid) \
> > + BIT((cpuid) * DMAMUX_INT_BIT_PER_CPU + (chid))
> > +#define DMAMUX_INTEN_BIT(cpuid) \
> > + DMAMUX_INT_BIT(8, cpuid)
> > +#define DMAMUX_INT_CH_BIT(chid, cpuid) \
> > + (DMAMUX_INT_BIT(chid, cpuid) | DMAMUX_INTEN_BIT(cpuid))
> > +#define DMAMUX_INT_MASK(chid) \
> > + (DMAMUX_INT_BIT(chid, 0) | \
> > + DMAMUX_INT_BIT(chid, 1) | \
> > + DMAMUX_INT_BIT(chid, 2))
> > +#define DMAMUX_INT_CH_MASK(chid, cpuid) \
> > + (DMAMUX_INT_MASK(chid) | DMAMUX_INTEN_BIT(cpuid))
> > +
> > +struct cv1800_dmamux_data {
> > + struct dma_router dmarouter;
> > + struct regmap *regmap;
> > + spinlock_t lock;
> > + struct llist_head free_maps;
> > + struct llist_head reserve_maps;
> > + DECLARE_BITMAP(mapped_peripherals, MAX_DMA_MAPPING_ID);
> > +};
> > +
> > +struct cv1800_dmamux_map {
> > + struct llist_node node;
> > + unsigned int channel;
> > + unsigned int peripheral;
> > + unsigned int cpu;
> > +};
> > +
> > +static void cv1800_dmamux_free(struct device *dev, void *route_data)
> > +{
> > + struct cv1800_dmamux_data *dmamux = dev_get_drvdata(dev);
> > + struct cv1800_dmamux_map *map = route_data;
> > + unsigned long flags;
> > +
> > + spin_lock_irqsave(&dmamux->lock, flags);
> > +
> > + regmap_update_bits(dmamux->regmap,
> > + DMAMUX_CH_REG(map->channel),
> > + DMAMUX_CH_MASK(map->channel),
> > + DMAMUX_CH_UPDATE_BIT);
> > +
> > + regmap_update_bits(dmamux->regmap, CV1800_SDMA_DMA_INT_MUX,
> > + DMAMUX_INT_CH_MASK(map->channel, map->cpu),
> > + DMAMUX_INTEN_BIT(map->cpu));
> > +
> > + spin_unlock_irqrestore(&dmamux->lock, flags);
> > +
> > + dev_info(dev, "free channel %u for req %u (cpu %u)\n",
> > + map->channel, map->peripheral, map->cpu);
>
> debug at most please
>
> > +}
> > +
> > +static void *cv1800_dmamux_route_allocate(struct of_phandle_args *dma_spec,
> > + struct of_dma *ofdma)
> > +{
> > + struct platform_device *pdev = of_find_device_by_node(ofdma->of_node);
> > + struct cv1800_dmamux_data *dmamux = platform_get_drvdata(pdev);
> > + struct cv1800_dmamux_map *map;
> > + struct llist_node *node;
> > + unsigned long flags;
> > + unsigned int chid, devid, cpuid;
> > + int ret;
> > +
> > + if (dma_spec->args_count != DMAMUX_NCELLS) {
> > + dev_err(&pdev->dev, "invalid number of dma mux args\n");
> > + return ERR_PTR(-EINVAL);
> > + }
> > +
> > + devid = dma_spec->args[0];
> > + cpuid = dma_spec->args[1];
> > + dma_spec->args_count = 1;
> > +
> > + if (devid > MAX_DMA_MAPPING_ID) {
> > + dev_err(&pdev->dev, "invalid device id: %u\n", devid);
> > + return ERR_PTR(-EINVAL);
> > + }
> > +
> > + if (cpuid > MAX_DMA_CPU_ID) {
> > + dev_err(&pdev->dev, "invalid cpu id: %u\n", cpuid);
> > + return ERR_PTR(-EINVAL);
> > + }
> > +
> > + dma_spec->np = of_parse_phandle(ofdma->of_node, "dma-masters", 0);
> > + if (!dma_spec->np) {
> > + dev_err(&pdev->dev, "can't get dma master\n");
> > + return ERR_PTR(-EINVAL);
> > + }
> > +
> > + spin_lock_irqsave(&dmamux->lock, flags);
> > +
> > + if (test_bit(devid, dmamux->mapped_peripherals)) {
> > + llist_for_each_entry(map, dmamux->reserve_maps.first, node) {
> > + if (map->peripheral == devid && map->cpu == cpuid)
> > + goto found;
> > + }
> > +
> > + ret = -EINVAL;
> > + goto failed;
> > + } else {
> > + node = llist_del_first(&dmamux->free_maps);
> > + if (!node) {
> > + ret = -ENODEV;
> > + goto failed;
> > + }
> > +
> > + map = llist_entry(node, struct cv1800_dmamux_map, node);
> > + llist_add(&map->node, &dmamux->reserve_maps);
> > + set_bit(devid, dmamux->mapped_peripherals);
> > + }
> > +
> > +found:
> > + chid = map->channel;
> > + map->peripheral = devid;
> > + map->cpu = cpuid;
> > +
> > + regmap_set_bits(dmamux->regmap,
> > + DMAMUX_CH_REG(chid),
> > + DMAMUX_CH_SET(chid, devid));
> > +
> > + regmap_update_bits(dmamux->regmap, CV1800_SDMA_DMA_INT_MUX,
> > + DMAMUX_INT_CH_MASK(chid, cpuid),
> > + DMAMUX_INT_CH_BIT(chid, cpuid));
> > +
> > + spin_unlock_irqrestore(&dmamux->lock, flags);
> > +
> > + dma_spec->args[0] = chid;
> > +
> > + dev_info(&pdev->dev, "register channel %u for req %u (cpu %u)\n",
> > + chid, devid, cpuid);
>
> Here as well
>
> > +
> > + return map;
> > +
> > +failed:
> > + spin_unlock_irqrestore(&dmamux->lock, flags);
> > + of_node_put(dma_spec->np);
> > + dev_err(&pdev->dev, "errno %d\n", ret);
> > + return ERR_PTR(ret);
> > +
> > +}
> > +
> > +static int cv1800_dmamux_probe(struct platform_device *pdev)
> > +{
> > + struct device *dev = &pdev->dev;
> > + struct device_node *mux_node = dev->of_node;
> > + struct cv1800_dmamux_data *data;
> > + struct cv1800_dmamux_map *tmp;
> > + struct device *parent = dev->parent;
> > + struct device_node *dma_master;
> > + struct regmap *regmap = NULL;
> > + unsigned int i;
> > +
> > + if (!parent)
> > + return -ENODEV;
> > +
> > + regmap = device_node_to_regmap(parent->of_node);
> > + if (IS_ERR(regmap))
> > + return PTR_ERR(regmap);
> > +
> > + dma_master = of_parse_phandle(mux_node, "dma-masters", 0);
> > + if (!dma_master) {
> > + dev_err(dev, "invalid dma-requests property\n");
> > + return -ENODEV;
> > + }
> > + of_node_put(dma_master);
>
> why do this if you dont need it??
>
This is a pre check. It will issue an error if no valid dma-master.
The dma-master is used in the route callback. Is it better to just
leave this check in the callback?
> > +
> > + data = devm_kmalloc(dev, sizeof(*data), GFP_KERNEL);
> > + if (!data)
> > + return -ENOMEM;
> > +
> > + spin_lock_init(&data->lock);
> > + init_llist_head(&data->free_maps);
> > +
> > + for (i = 0; i <= MAX_DMA_CH_ID; i++) {
> > + tmp = devm_kmalloc(dev, sizeof(*tmp), GFP_KERNEL);
> > + if (!tmp) {
> > + /* It is OK for not allocating all channel */
> > + dev_warn(dev, "can not allocate channel %u\n", i);
> > + continue;
> > + }
> > +
> > + init_llist_node(&tmp->node);
> > + tmp->channel = i;
> > + llist_add(&tmp->node, &data->free_maps);
> > + }
> > +
> > + /* if no channel is allocated, the probe must fail */
> > + if (llist_empty(&data->free_maps))
> > + return -ENOMEM;
> > +
> > + data->regmap = regmap;
> > + data->dmarouter.dev = dev;
> > + data->dmarouter.route_free = cv1800_dmamux_free;
> > +
> > + platform_set_drvdata(pdev, data);
> > +
> > + return of_dma_router_register(mux_node,
> > + cv1800_dmamux_route_allocate,
> > + &data->dmarouter);
> > +}
> > +
> > +static void cv1800_dmamux_remove(struct platform_device *pdev)
> > +{
> > + of_dma_controller_free(pdev->dev.of_node);
> > +}
> > +
> > +static const struct of_device_id cv1800_dmamux_ids[] = {
> > + { .compatible = "sophgo,cv1800-dmamux", },
> > + { }
> > +};
> > +MODULE_DEVICE_TABLE(of, cv1800_dmamux_ids);
> > +
> > +static struct platform_driver cv1800_dmamux_driver = {
> > + .driver = {
> > + .name = "cv1800-dmamux",
> > + .of_match_table = cv1800_dmamux_ids,
> > + },
> > + .probe = cv1800_dmamux_probe,
> > + .remove_new = cv1800_dmamux_remove,
> > +};
> > +module_platform_driver(cv1800_dmamux_driver);
> > +
> > +MODULE_AUTHOR("Inochi Amaoto <inochiama@outlook.com>");
> > +MODULE_DESCRIPTION("Sophgo CV1800/SG2000 Series Soc DMAMUX driver");
> > +MODULE_LICENSE("GPL");
> > --
> > 2.44.0
>
> --
> ~Vinod
^ permalink raw reply
* RE: [PATCH 1/5] dt-bindings: firmware: add i.MX SCMI Extension protocol
From: Peng Fan @ 2024-04-07 12:35 UTC (permalink / raw)
To: Rob Herring, Peng Fan (OSS)
Cc: Krzysztof Kozlowski, Conor Dooley, Sudeep Holla, Cristian Marussi,
Shawn Guo, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
dl-linux-imx, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20240212150919.GA322668-robh@kernel.org>
Hi Rob,
Sorry for late reply.
> Subject: Re: [PATCH 1/5] dt-bindings: firmware: add i.MX SCMI Extension
> protocol
>
> On Fri, Feb 02, 2024 at 02:34:39PM +0800, Peng Fan (OSS) wrote:
> > From: Peng Fan <peng.fan@nxp.com>
> >
> > Add i.MX SCMI Extension protocol BBM and MISC binding.
>
> No idea what BBM and MISC are.
The Battery Backup (BB) Domain contains the Battery Backed
Security Module (BBSM) and the Battery Backed Non-Secure Module
(BBNSM).
BBNSM:
The BBNSM is the interface to a non-interruptable power supply
(backup battery) and serves as the non-volatile logic and storage
for the chip. When the chip is powered off, the BBNSM will maintain
PMIC logic while connected to a backup supply.
Main features: RTC, PMIC Control, ONOFF Control BBSM serves as
nonvolatile security logic and storage for ELE Main features:
Monotonic counter, Secure RTC, Zeroizable Master Key, Security
Violation and Tamper Detection
MISC: it is i.MX SCMI extension protocol, including BLK CTRL
settings, board level GPIO expander settings.
>
> >
> > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> > ---
> > .../devicetree/bindings/firmware/nxp,scmi.yaml | 64
> ++++++++++++++++++++++
> > 1 file changed, 64 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/firmware/nxp,scmi.yaml
> > b/Documentation/devicetree/bindings/firmware/nxp,scmi.yaml
> > new file mode 100644
> > index 000000000000..00d6361bbbea
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/firmware/nxp,scmi.yaml
> > @@ -0,0 +1,64 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) # Copyright 2024
> > +NXP %YAML 1.2
> > +---
> > +$id:
> > +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevi
> >
> +cetree.org%2Fschemas%2Ffirmware%2Fnxp%2Cscmi.yaml%23&data=05%7
> C02%7Cp
> >
> +eng.fan%40nxp.com%7C625d14c7c4f14d16289908dc2bdc9967%7C686ea1
> d3bc2b4c
> >
> +6fa92cd99c5c301635%7C0%7C0%7C638433473675932860%7CUnknown%
> 7CTWFpbGZsb
> >
> +3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn
> 0%3D
> >
> +%7C0%7C%7C%7C&sdata=dP0%2FgyCwmWtSW9BNYWZQtunpgayjCl2AkSkj
> ZIZjn9o%3D&
> > +reserved=0
> > +$schema:
> > +https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdevi
> > +cetree.org%2Fmeta-
> schemas%2Fcore.yaml%23&data=05%7C02%7Cpeng.fan%40nx
> >
> +p.com%7C625d14c7c4f14d16289908dc2bdc9967%7C686ea1d3bc2b4c6fa9
> 2cd99c5c
> >
> +301635%7C0%7C0%7C638433473675946764%7CUnknown%7CTWFpbGZs
> b3d8eyJWIjoiM
> >
> +C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7
> C%7C%7
> >
> +C&sdata=efmqKP8%2FyS4YoDLCb%2Fmxx72D7ZW2KxiEDhgnWdEUT1s%3D
> &reserved=0
> > +
> > +title: i.MX System Control and Management Interface (SCMI) Protocol
> > +Extension
> > +
> > +maintainers:
> > + - Peng Fan <peng.fan@nxp.com>
> > +
> > +allOf:
> > + - $ref: arm,scmi.yaml#
> > +
> > +properties:
> > + protocol@11:
>
> Wrong unit-address?
Yeah. Fixed.
>
> > + $ref: 'arm,scmi.yaml#/$defs/protocol-node'
> > + unevaluatedProperties: false
>
> Description of what this protocol is needed.
Added.
>
> > +
> > + properties:
> > + reg:
> > + const: 0x81
> > +
> > + protocol@13:
> > + $ref: 'arm,scmi.yaml#/$defs/protocol-node'
> > + unevaluatedProperties: false
> > +
> > + properties:
> > + reg:
> > + const: 0x84
> > +
> > + wakeup-sources:
>
> Is this somehow generic?
I think it yes, but if you disagree, please suggest.
>
> > + description: each entry consists of 2 integers and represents
> > + the source and edge
>
> What does 'edge' mean in this context?
Electric signal edge.
>
> > + items:
> > + items:
> > + - description: the wakeup source
> > + - description: the wakeup edge
>
> Constraints?
Will add in V3.
minItems: 1
maxItems: 32
>
> > + $ref: /schemas/types.yaml#/definitions/uint32-matrix
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > + firmware {
> > + scmi {
>
>
> Need a compatible here so this actually gets tested.
Fixed.
>
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + protocol@81 {
> > + reg = <0x81>;
> > + };
> > +
> > + protocol@84 {
> > + reg = <0x84>;
> > + wakeup-sources = <6 1
> > + 7 1
> > + 8 1
> > + 9 1
> > + 10 1>;
>
> <> around each entry. e.g. "<6 1>"
Fix in V3.
Thanks,
Peng.
>
> > + };
> > + };
> > + };
> > +...
> >
> > --
> > 2.37.1
> >
^ permalink raw reply
* Re: [PATCH 2/3] dt-bindings: PCI: mediatek,mt7621: add missing child node reg
From: Sergio Paracuellos @ 2024-04-07 12:36 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Bjorn Helgaas, Lorenzo Pieralisi, Krzysztof Wilczyński,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Hector Martin,
Sven Peter, Alyssa Rosenzweig, Ray Jui, Scott Branden,
Broadcom internal kernel review list, Jim Quinlan,
Nicolas Saenz Julienne, Florian Fainelli, Will Deacon,
Linus Walleij, Srikanth Thokala, Ryder Lee, Jianjun Wang,
Matthias Brugger, AngeloGioacchino Del Regno, Daire McNamara,
Bjorn Andersson, Konrad Dybcio, Marek Vasut, Yoshihiro Shimoda,
Shawn Lin, Heiko Stuebner, Jingoo Han, Gustavo Pimentel,
Manivannan Sadhasivam, Bharat Kumar Gogada, Michal Simek,
Geert Uytterhoeven, Magnus Damm, Neil Armstrong, Mark Kettenis,
Tom Joseph, Ahmad Zainie, Jiaxun Yang, Kishon Vijay Abraham I,
Thippeswamy Havalige, linux-pci, devicetree, linux-kernel, asahi,
linux-arm-kernel, linux-rpi-kernel, linux-mediatek, linux-arm-msm,
linux-renesas-soc, linux-rockchip
In-Reply-To: <20240407102000.37213-2-krzysztof.kozlowski@linaro.org>
On Sun, Apr 7, 2024 at 12:20 PM Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:
>
> MT7621 PCI host bridge has children which apparently are also PCI host
> bridges, at least that's what the binding suggest. The children have
> "reg" property, but do not explicitly define it. Instead they rely on
> pci-bus.yaml schema, but that one has "reg" without any constraints.
>
> Define the "reg" for the children, so the binding will be more specific
> and later will allow dropping reference to deprecated pci-bus.yaml
> schema.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> ---
> .../devicetree/bindings/pci/mediatek,mt7621-pcie.yaml | 3 +++
> 1 file changed, 3 insertions(+)
Acked-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Thanks,
Sergio Paracuellos
^ permalink raw reply
* Re: [PATCH 3/3] dt-bindings: PCI: host-bridges: switch from deprecated pci-bus.yaml
From: Sergio Paracuellos @ 2024-04-07 12:38 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Bjorn Helgaas, Lorenzo Pieralisi, Krzysztof Wilczyński,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Hector Martin,
Sven Peter, Alyssa Rosenzweig, Ray Jui, Scott Branden,
Broadcom internal kernel review list, Jim Quinlan,
Nicolas Saenz Julienne, Florian Fainelli, Will Deacon,
Linus Walleij, Srikanth Thokala, Ryder Lee, Jianjun Wang,
Matthias Brugger, AngeloGioacchino Del Regno, Daire McNamara,
Bjorn Andersson, Konrad Dybcio, Marek Vasut, Yoshihiro Shimoda,
Shawn Lin, Heiko Stuebner, Jingoo Han, Gustavo Pimentel,
Manivannan Sadhasivam, Bharat Kumar Gogada, Michal Simek,
Geert Uytterhoeven, Magnus Damm, Neil Armstrong, Mark Kettenis,
Tom Joseph, Ahmad Zainie, Jiaxun Yang, Kishon Vijay Abraham I,
Thippeswamy Havalige, linux-pci, devicetree, linux-kernel, asahi,
linux-arm-kernel, linux-rpi-kernel, linux-mediatek, linux-arm-msm,
linux-renesas-soc, linux-rockchip
In-Reply-To: <20240407102000.37213-3-krzysztof.kozlowski@linaro.org>
On Sun, Apr 7, 2024 at 12:20 PM Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:
>
> dtschema package with core schemas deprecated pci-bus.yaml schema in
> favor of pci-host-bridge.yaml. Update all bindings to use the latter
> one.
>
> The difference between pci-bus.yaml and pci-host-bridge.yaml is only in
> lack of "reg" property defined by the latter, which should not have any
> effect here, because all these bindings define the "reg".
>
> The change is therefore quite trivial, except mediatek,mt7621-pcie.yaml
> binding which have children nodes being also host bridges, apparently.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> ---
> .../devicetree/bindings/pci/mediatek,mt7621-pcie.yaml | 4 ++--
Acked-by: Sergio Paracuellos <sergio.paracuellos@gmail.com>
Thanks,
Sergio Paracuellos
^ permalink raw reply
* Re: [PATCH] dt-bindings: dma: snps,dma-spear1340: Fix data{-,_}width schema
From: Vinod Koul @ 2024-04-07 13:04 UTC (permalink / raw)
To: Rob Herring
Cc: Viresh Kumar, Andy Shevchenko, Krzysztof Kozlowski, Conor Dooley,
dmaengine, devicetree, linux-kernel
In-Reply-To: <20240311222522.1939951-1-robh@kernel.org>
On 11-03-24, 16:25, Rob Herring wrote:
> 'data-width' and 'data_width' properties are defined as arrays, but the
> schema is defined as a matrix. That works currently since everything gets
> decoded in to matrices, but that is internal to dtschema and could change.
This fails to apply on dmaengine/next.
Can you please rebase?
>
> Signed-off-by: Rob Herring <robh@kernel.org>
> ---
> .../bindings/dma/snps,dma-spear1340.yaml | 38 +++++++++----------
> 1 file changed, 17 insertions(+), 21 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/dma/snps,dma-spear1340.yaml b/Documentation/devicetree/bindings/dma/snps,dma-spear1340.yaml
> index 5da8291a7de0..7b0ff4afcaa1 100644
> --- a/Documentation/devicetree/bindings/dma/snps,dma-spear1340.yaml
> +++ b/Documentation/devicetree/bindings/dma/snps,dma-spear1340.yaml
> @@ -93,10 +93,9 @@ properties:
> data-width:
> $ref: /schemas/types.yaml#/definitions/uint32-array
> description: Data bus width per each DMA master in bytes.
> + maxItems: 4
> items:
> - maxItems: 4
> - items:
> - enum: [4, 8, 16, 32]
> + enum: [4, 8, 16, 32]
>
> data_width:
> $ref: /schemas/types.yaml#/definitions/uint32-array
> @@ -106,28 +105,26 @@ properties:
> deprecated. It' usage is discouraged in favor of data-width one. Moreover
> the property incorrectly permits to define data-bus width of 8 and 16
> bits, which is impossible in accordance with DW DMAC IP-core data book.
> + maxItems: 4
> items:
> - maxItems: 4
> - items:
> - enum:
> - - 0 # 8 bits
> - - 1 # 16 bits
> - - 2 # 32 bits
> - - 3 # 64 bits
> - - 4 # 128 bits
> - - 5 # 256 bits
> - default: 0
> + enum:
> + - 0 # 8 bits
> + - 1 # 16 bits
> + - 2 # 32 bits
> + - 3 # 64 bits
> + - 4 # 128 bits
> + - 5 # 256 bits
> + default: 0
>
> multi-block:
> $ref: /schemas/types.yaml#/definitions/uint32-array
> description: |
> LLP-based multi-block transfer supported by hardware per
> each DMA channel.
> + maxItems: 8
> items:
> - maxItems: 8
> - items:
> - enum: [0, 1]
> - default: 1
> + enum: [0, 1]
> + default: 1
>
> snps,max-burst-len:
> $ref: /schemas/types.yaml#/definitions/uint32-array
> @@ -138,11 +135,10 @@ properties:
> will be from 1 to max-burst-len words. It's an array property with one
> cell per channel in the units determined by the value set in the
> CTLx.SRC_TR_WIDTH/CTLx.DST_TR_WIDTH fields (data width).
> + maxItems: 8
> items:
> - maxItems: 8
> - items:
> - enum: [4, 8, 16, 32, 64, 128, 256]
> - default: 256
> + enum: [4, 8, 16, 32, 64, 128, 256]
> + default: 256
>
> snps,dma-protection-control:
> $ref: /schemas/types.yaml#/definitions/uint32
> --
> 2.43.0
--
~Vinod
^ permalink raw reply
* Re: [PATCH] dt-bindings: dma: snps,dma-spear1340: Fix data{-,_}width schema
From: Vinod Koul @ 2024-04-07 13:05 UTC (permalink / raw)
To: Rob Herring
Cc: Viresh Kumar, Andy Shevchenko, Krzysztof Kozlowski, Conor Dooley,
dmaengine, devicetree, linux-kernel
In-Reply-To: <ZhKZwp4n7RYlprP-@matsya>
On 07-04-24, 18:34, Vinod Koul wrote:
> On 11-03-24, 16:25, Rob Herring wrote:
> > 'data-width' and 'data_width' properties are defined as arrays, but the
> > schema is defined as a matrix. That works currently since everything gets
> > decoded in to matrices, but that is internal to dtschema and could change.
>
> This fails to apply on dmaengine/next.
>
> Can you please rebase?
Never mind, the v2 worked just fine
--
~Vinod
^ permalink raw reply
* RE: [PATCH v3] clk: starfive: pll: Fix lower rate of CPUfreq by setting PLL0 rate to 1.5GHz
From: Xingyu Wu @ 2024-04-07 13:14 UTC (permalink / raw)
To: Samuel Holland
Cc: Paul Walmsley, Palmer Dabbelt, Albert Ou, Hal Feng,
linux-kernel@vger.kernel.org, linux-clk@vger.kernel.org,
linux-riscv@lists.infradead.org, devicetree@vger.kernel.org,
Krzysztof Kozlowski, Michael Turquette, Stephen Boyd,
Conor Dooley, Emil Renner Berthing, Rob Herring,
Krzysztof Kozlowski
In-Reply-To: <74d6213f-51de-4d48-a7fb-844d6bb57fa7@sifive.com>
On 2024-04-05 5:28 AM, Samuel Holland wrote:
>
> Hi Xingyu,
>
> On 2024-04-03 2:44 AM, Xingyu Wu wrote:
> > On 03/04/2024 15:24, Krzysztof Kozlowski wrote:
> >>
> >> On 03/04/2024 09:19, Xingyu Wu wrote:
> >>> On 03/04/2024 0:18, Krzysztof Kozlowski wrote:
> >>>>
> >>>> On 02/04/2024 11:09, Xingyu Wu wrote:
> >>>>> 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. But setting the
> >>>>> PLL0 rate need certain steps:
> >>>>>
> >>>>> 1. Change the parent of cpu_root clock to OSC clock.
> >>>>> 2. Change the divider of cpu_core if PLL0 rate is higher than
> >>>>> 1.25GHz before CPUfreq boot.
> >>>>> 3. Change the parent of cpu_root clock back to PLL0 clock.
> >>>>>
> >>>>> Reviewed-by: Hal Feng <hal.feng@starfivetech.com>
> >>>>> Fixes: e2c510d6d630 ("riscv: dts: starfive: Add cpu scaling for
> >>>>> JH7110
> >>>>> SoC")
> >>>>> Signed-off-by: Xingyu Wu <xingyu.wu@starfivetech.com>
> >>>>> ---
> >>>>>
> >>>>> Hi Stephen and Emil,
> >>>>>
> >>>>> This patch fixes the issue about lower rate of CPUfreq[1] by
> >>>>> setting
> >>>>> PLL0 rate to 1.5GHz.
> >>>>>
> >>>>> In order not to affect the cpu operation, setting the PLL0 rate
> >>>>> need certain steps. The cpu_root's parent clock should be changed first.
> >>>>> And the divider of the cpu_core clock should be set to 2 so they
> >>>>> won't crash when setting 1.5GHz without voltage regulation. Due to
> >>>>> PLL driver boot earlier than SYSCRG driver, cpu_core and cpu_root
> >>>>> clocks are using by ioremap().
> >>>>>
> >>>>> [1]: https://github.com/starfive-tech/VisionFive2/issues/55
> >>>>>
> >>>>> Previous patch link:
> >>>>> v2:
> >>>>> https://lore.kernel.org/all/20230821152915.208366-1-xingyu.wu@star
> >>>>> fi
> >>>>> ve
> >>>>> tech.com/
> >>>>> v1:
> >>>>> https://lore.kernel.org/all/20230811033631.160912-1-xingyu.wu@star
> >>>>> fi
> >>>>> ve
> >>>>> tech.com/
> >>>>>
> >>>>> Thanks,
> >>>>> Xingyu Wu
> >>>>> ---
> >>>>> .../jh7110-starfive-visionfive-2.dtsi | 5 +
> >>>>> .../clk/starfive/clk-starfive-jh7110-pll.c | 102 ++++++++++++++++++
> >>>>
> >>>> Please do not mix DTS and driver code. That's not really portable.
> >>>> DTS is being exported and used in other projects.
> >>>
> >>> OK, I will submit that in two patches.
> >>>
> >>>>
> >>>> ...
> >>>>
> >>>>>
> >>>>> @@ -458,6 +535,8 @@ static int jh7110_pll_probe(struct
> >>>>> platform_device
> >>>> *pdev)
> >>>>> struct jh7110_pll_priv *priv;
> >>>>> unsigned int idx;
> >>>>> int ret;
> >>>>> + struct device_node *np;
> >>>>> + struct resource res;
> >>>>>
> >>>>> priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
> >>>>> if (!priv)
> >>>>> @@ -489,6 +568,29 @@ static int jh7110_pll_probe(struct
> >>>>> platform_device
> >>>> *pdev)
> >>>>> return ret;
> >>>>> }
> >>>>>
> >>>>> + priv->is_first_set = true;
> >>>>> + np = of_find_compatible_node(NULL, NULL,
> >>>>> +"starfive,jh7110-syscrg");
> >>>>
> >>>> Your drivers should not do it. It's fragile, hides true link/dependency.
> >>>> Please use phandles.
> >>>>
> >>>>
> >>>>> + if (!np) {
> >>>>> + ret = PTR_ERR(np);
> >>>>> + dev_err(priv->dev, "failed to get syscrg node\n");
> >>>>> + goto np_put;
> >>>>> + }
> >>>>> +
> >>>>> + ret = of_address_to_resource(np, 0, &res);
> >>>>> + if (ret) {
> >>>>> + dev_err(priv->dev, "failed to get syscrg resource\n");
> >>>>> + goto np_put;
> >>>>> + }
> >>>>> +
> >>>>> + priv->syscrg_base = ioremap(res.start, resource_size(&res));
> >>>>> + if (!priv->syscrg_base)
> >>>>> + ret = -ENOMEM;
> >>>>
> >>>> Why are you mapping other device's IO? How are you going to ensure
> >>>> synced access to registers?
> >>>
> >>> Because setting PLL0 rate need specific steps and use the clocks of SYSCRG.
> >>
> >> That's not a reason to map other device's IO. That could be a reason
> >> for having syscon or some other sort of relationship, like clock or reset.
> >>
> >>> But SYSCRG driver also need PLL clock to be clock source when adding
> >>> clock providers. I tried to add SYSCRG clocks in 'clocks' property
> >>> in DT and use
> >>> clk_get() to get the clocks. But it could not run and crash. So I
> >>> use
> >>> ioremap() instead.
> >>
> >> So instead of properly model the relationship, you entangle the
> >> drivers even more.
> >>
> >> Please come with a proper design for this. I have no clue about your
> >> hardware, but that looks like you are asynchronously configuring the
> >> same hardware in two different places.
> >>
> >> Sorry, that's poor code.
> >>
> >> Best regards,
> >> Krzysztof
> >
> > Hi Krzysztof,
> >
> > If I use the old patch[1] like v2 and set the PLL0 default rate in the
> > SYSCRG driver, will it be better?
> >
> > [1]:
> > https://lore.kernel.org/all/20230821152915.208366-1-xingyu.wu@starfive
> > tech.com/
>
> Both reparenting cpu_root and enforcing the maximum cpu_core frequency can
> be accomplished with clk notifiers. See for example ccu_mux_notifier_register()
> in drivers/clk/sunxi-ng/ccu_mux.c.
>
This seems like a good idea. I'll try it.
Thanks,
Xingyu Wu
^ permalink raw reply
* Re: [PATCH v9 2/6] PCI: qcom: Add ICC bandwidth vote for CPU to PCIe path
From: Manivannan Sadhasivam @ 2024-04-07 14:39 UTC (permalink / raw)
To: Krishna chaitanya chundru
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Lorenzo Pieralisi, Krzysztof Wilczyński,
Bjorn Helgaas, johan+linaro, bmasney, djakov, linux-arm-msm,
devicetree, linux-kernel, linux-pci, vireshk, quic_vbadigan,
quic_skananth, quic_nitegupt, quic_parass, krzysztof.kozlowski,
Bryan O'Donoghue
In-Reply-To: <20240407-opp_support-v9-2-496184dc45d7@quicinc.com>
On Sun, Apr 07, 2024 at 10:07:35AM +0530, Krishna chaitanya chundru wrote:
> To access PCIe registers, PCIe BAR space, config space the CPU-PCIe
Please specify whether you are referencing PCIe host controller or endpoint
device or both.
> ICC (interconnect consumers) path should be voted otherwise it may
ICC is just 'Interconnect' unless I misunderstood.
> lead to NoC (Network on chip) timeout. We are surviving because of
> other driver vote for this path.
>
s/vote/voting
> As there is less access on this path compared to PCIe to mem path
> add minimum vote i.e 1KBps bandwidth always which is recommended
> by HW team.
>
'which is sufficient enough to keep the path active.'
> When suspending, disable this path after register space access
> is done.
>
> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
> Signed-off-by: Krishna chaitanya chundru <quic_krichai@quicinc.com>
> ---
> drivers/pci/controller/dwc/pcie-qcom.c | 38 ++++++++++++++++++++++++++++++----
> 1 file changed, 34 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controller/dwc/pcie-qcom.c
> index 14772edcf0d3..b4893214b2d3 100644
> --- a/drivers/pci/controller/dwc/pcie-qcom.c
> +++ b/drivers/pci/controller/dwc/pcie-qcom.c
> @@ -245,6 +245,7 @@ struct qcom_pcie {
> struct phy *phy;
> struct gpio_desc *reset;
> struct icc_path *icc_mem;
> + struct icc_path *icc_cpu;
> const struct qcom_pcie_cfg *cfg;
> struct dentry *debugfs;
> bool suspended;
> @@ -1409,6 +1410,9 @@ static int qcom_pcie_icc_init(struct qcom_pcie *pcie)
> if (IS_ERR(pcie->icc_mem))
> return PTR_ERR(pcie->icc_mem);
>
> + pcie->icc_cpu = devm_of_icc_get(pci->dev, "cpu-pcie");
> + if (IS_ERR(pcie->icc_cpu))
> + return PTR_ERR(pcie->icc_cpu);
> /*
> * Some Qualcomm platforms require interconnect bandwidth constraints
> * to be set before enabling interconnect clocks.
> @@ -1418,7 +1422,19 @@ static int qcom_pcie_icc_init(struct qcom_pcie *pcie)
> */
> ret = icc_set_bw(pcie->icc_mem, 0, QCOM_PCIE_LINK_SPEED_TO_BW(1));
> if (ret) {
> - dev_err(pci->dev, "failed to set interconnect bandwidth: %d\n",
> + dev_err(pci->dev, "failed to set interconnect bandwidth for PCIe-MEM: %d\n",
> + ret);
> + return ret;
> + }
> +
> + /*
> + * Since the CPU-PCIe path is only used for activities like register
Again, differentiate PCIe controller and endpoint device access.
> + * access, Config/BAR space access, HW team has recommended to use a
> + * minimal bandwidth of 1KBps just to keep the link active.
> + */
> + ret = icc_set_bw(pcie->icc_cpu, 0, kBps_to_icc(1));
> + if (ret) {
> + dev_err(pci->dev, "failed to set interconnect bandwidth for CPU-PCIe: %d\n",
> ret);
> return ret;
> }
> @@ -1448,7 +1464,7 @@ static void qcom_pcie_icc_update(struct qcom_pcie *pcie)
>
> ret = icc_set_bw(pcie->icc_mem, 0, width * QCOM_PCIE_LINK_SPEED_TO_BW(speed));
> if (ret) {
> - dev_err(pci->dev, "failed to set interconnect bandwidth: %d\n",
> + dev_err(pci->dev, "failed to set interconnect bandwidth for PCIe-MEM: %d\n",
> ret);
> }
> }
> @@ -1610,7 +1626,7 @@ static int qcom_pcie_suspend_noirq(struct device *dev)
> */
> ret = icc_set_bw(pcie->icc_mem, 0, kBps_to_icc(1));
> if (ret) {
> - dev_err(dev, "Failed to set interconnect bandwidth: %d\n", ret);
> + dev_err(dev, "Failed to set interconnect bandwidth for PCIe-MEM: %d\n", ret);
> return ret;
> }
>
> @@ -1634,7 +1650,15 @@ static int qcom_pcie_suspend_noirq(struct device *dev)
> pcie->suspended = true;
> }
>
> - return 0;
> + /*
> + * Remove the vote for CPU-PCIe path now, since at this point onwards,
> + * no register access will be done.
> + */
Are you sure? Didn't we see late access to DBI registers on sc7280?
> + ret = icc_disable(pcie->icc_cpu);
> + if (ret)
> + dev_err(dev, "failed to disable icc path of CPU-PCIe: %d\n", ret);
s/failed to disable icc path/Failed to disable Interconnect path between CPU-PCIe
> +
> + return ret;
> }
>
> static int qcom_pcie_resume_noirq(struct device *dev)
> @@ -1642,6 +1666,12 @@ static int qcom_pcie_resume_noirq(struct device *dev)
> struct qcom_pcie *pcie = dev_get_drvdata(dev);
> int ret;
>
> + ret = icc_enable(pcie->icc_cpu);
> + if (ret) {
> + dev_err(dev, "failed to enable icc path of CPU-PCIe: %d\n", ret);
Same as above.
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH v9 3/6] dt-bindings: pci: qcom: Add opp table
From: Manivannan Sadhasivam @ 2024-04-07 14:42 UTC (permalink / raw)
To: Krishna chaitanya chundru
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Lorenzo Pieralisi, Krzysztof Wilczyński,
Bjorn Helgaas, johan+linaro, bmasney, djakov, linux-arm-msm,
devicetree, linux-kernel, linux-pci, vireshk, quic_vbadigan,
quic_skananth, quic_nitegupt, quic_parass, krzysztof.kozlowski
In-Reply-To: <20240407-opp_support-v9-3-496184dc45d7@quicinc.com>
On Sun, Apr 07, 2024 at 10:07:36AM +0530, Krishna chaitanya chundru wrote:
s/opp/OPP
> PCIe needs to choose the appropriate performance state of RPMH power
s/RPMH/RPMh
> domain based upon the PCIe gen speed.
>
s/upon/on
> Adding the Operating Performance Points table allows to adjust power
> domain performance state and icc peak bw, depending on the PCIe gen
s/icc/ICC
s/PCIe gen speed/PCIe data rate
> speed and width.
>
s/width/link width
> Signed-off-by: Krishna chaitanya chundru <quic_krichai@quicinc.com>
With above changes,
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
- Mani
> ---
> Documentation/devicetree/bindings/pci/qcom,pcie-sm8450.yaml | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie-sm8450.yaml b/Documentation/devicetree/bindings/pci/qcom,pcie-sm8450.yaml
> index 1496d6993ab4..d8c0afaa4b19 100644
> --- a/Documentation/devicetree/bindings/pci/qcom,pcie-sm8450.yaml
> +++ b/Documentation/devicetree/bindings/pci/qcom,pcie-sm8450.yaml
> @@ -69,6 +69,10 @@ properties:
> - const: msi6
> - const: msi7
>
> + operating-points-v2: true
> + opp-table:
> + type: object
> +
> resets:
> maxItems: 1
>
>
> --
> 2.42.0
>
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH v9 4/6] arm64: dts: qcom: sm8450: Add opp table support to PCIe
From: Manivannan Sadhasivam @ 2024-04-07 14:45 UTC (permalink / raw)
To: Krishna chaitanya chundru
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Lorenzo Pieralisi, Krzysztof Wilczyński,
Bjorn Helgaas, johan+linaro, bmasney, djakov, linux-arm-msm,
devicetree, linux-kernel, linux-pci, vireshk, quic_vbadigan,
quic_skananth, quic_nitegupt, quic_parass, krzysztof.kozlowski
In-Reply-To: <20240407-opp_support-v9-4-496184dc45d7@quicinc.com>
On Sun, Apr 07, 2024 at 10:07:37AM +0530, Krishna chaitanya chundru wrote:
> PCIe needs to choose the appropriate performance state of RPMH power
> domain and interconnect bandwidth based up on the PCIe gen speed.
>
> Add the OPP table support to specify RPMH performance states and
> interconnect peak bandwidth.
>
Same comment as the bindings patch.
> Signed-off-by: Krishna chaitanya chundru <quic_krichai@quicinc.com>
> ---
> arch/arm64/boot/dts/qcom/sm8450.dtsi | 77 ++++++++++++++++++++++++++++++++++++
> 1 file changed, 77 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sm8450.dtsi b/arch/arm64/boot/dts/qcom/sm8450.dtsi
> index 615296e13c43..881e5339cfff 100644
> --- a/arch/arm64/boot/dts/qcom/sm8450.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sm8450.dtsi
> @@ -1855,7 +1855,35 @@ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
> pinctrl-names = "default";
> pinctrl-0 = <&pcie0_default_state>;
>
> + operating-points-v2 = <&pcie0_opp_table>;
> +
> status = "disabled";
> +
> + pcie0_opp_table: opp-table {
> + compatible = "operating-points-v2";
> +
> + /* GEN 1x1 */
s/GEN 1x1/Gen 1 x1
Same for all comments
- Mani
> + opp-2500000 {
> + opp-hz = /bits/ 64 <2500000>;
> + required-opps = <&rpmhpd_opp_low_svs>;
> + opp-peak-kBps = <250000 1>;
> + };
> +
> + /* GEN 2x1 */
> + opp-5000000 {
> + opp-hz = /bits/ 64 <5000000>;
> + required-opps = <&rpmhpd_opp_low_svs>;
> + opp-peak-kBps = <500000 1>;
> + };
> +
> + /* GEN 3x1 */
> + opp-8000000 {
> + opp-hz = /bits/ 64 <8000000>;
> + required-opps = <&rpmhpd_opp_nom>;
> + opp-peak-kBps = <984500 1>;
> + };
> + };
> +
> };
>
> pcie0_phy: phy@1c06000 {
> @@ -1982,7 +2010,56 @@ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
> pinctrl-names = "default";
> pinctrl-0 = <&pcie1_default_state>;
>
> + operating-points-v2 = <&pcie1_opp_table>;
> +
> status = "disabled";
> +
> + pcie1_opp_table: opp-table {
> + compatible = "operating-points-v2";
> +
> + /* GEN 1x1 */
> + opp-2500000 {
> + opp-hz = /bits/ 64 <2500000>;
> + required-opps = <&rpmhpd_opp_low_svs>;
> + opp-peak-kBps = <250000 1>;
> + };
> +
> + /* GEN 1x2 GEN 2x1 */
> + opp-5000000 {
> + opp-hz = /bits/ 64 <5000000>;
> + required-opps = <&rpmhpd_opp_low_svs>;
> + opp-peak-kBps = <500000 1>;
> + };
> +
> + /* GEN 2x2 */
> + opp-10000000 {
> + opp-hz = /bits/ 64 <10000000>;
> + required-opps = <&rpmhpd_opp_low_svs>;
> + opp-peak-kBps = <1000000 1>;
> + };
> +
> + /* GEN 3x1 */
> + opp-8000000 {
> + opp-hz = /bits/ 64 <8000000>;
> + required-opps = <&rpmhpd_opp_nom>;
> + opp-peak-kBps = <984500 1>;
> + };
> +
> + /* GEN 3x2 GEN 4x1 */
> + opp-16000000 {
> + opp-hz = /bits/ 64 <16000000>;
> + required-opps = <&rpmhpd_opp_nom>;
> + opp-peak-kBps = <1969000 1>;
> + };
> +
> + /* GEN 4x2 */
> + opp-32000000 {
> + opp-hz = /bits/ 64 <32000000>;
> + required-opps = <&rpmhpd_opp_nom>;
> + opp-peak-kBps = <3938000 1>;
> + };
> + };
> +
> };
>
> pcie1_phy: phy@1c0e000 {
>
> --
> 2.42.0
>
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH v9 6/6] PCI: qcom: Add OPP support to scale performance state of power domain
From: Manivannan Sadhasivam @ 2024-04-07 15:00 UTC (permalink / raw)
To: Krishna chaitanya chundru
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Lorenzo Pieralisi, Krzysztof Wilczyński,
Bjorn Helgaas, johan+linaro, bmasney, djakov, linux-arm-msm,
devicetree, linux-kernel, linux-pci, vireshk, quic_vbadigan,
quic_skananth, quic_nitegupt, quic_parass, krzysztof.kozlowski
In-Reply-To: <20240407-opp_support-v9-6-496184dc45d7@quicinc.com>
On Sun, Apr 07, 2024 at 10:07:39AM +0530, Krishna chaitanya chundru wrote:
> QCOM Resource Power Manager-hardened (RPMh) is a hardware block which
> maintains hardware state of a regulator by performing max aggregation of
> the requests made by all of the clients.
>
> PCIe controller can operate on different RPMh performance state of power
> domain based on the speed of the link. And this performance state varies
> from target to target, like some controllers support GEN3 in NOM (Nominal)
> voltage corner, while some other supports GEN3 in low SVS (static voltage
> scaling).
>
> The SoC can be more power efficient if we scale the performance state
> based on the aggregate PCIe link bandwidth.
>
> Add Operating Performance Points (OPP) support to vote for RPMh state based
> on the aggregate link bandwidth.
>
> OPP can handle ICC bw voting also, so move ICC bw voting through OPP
> framework if OPP entries are present.
>
> Different link configurations may share the same aggregate bandwidth,
> e.g., a 2.5 GT/s x2 link and a 5.0 GT/s x1 link have the same bandwidth
> and share the same OPP entry.
>
This info should be part of the dts change.
> As we are moving ICC voting as part of OPP, don't initialize ICC if OPP
> is supported.
>
> Before PCIe link is initialized vote for highest OPP in the OPP table,
> so that we are voting for maximum voltage corner for the link to come up
> in maximum supported speed.
>
> Signed-off-by: Krishna chaitanya chundru <quic_krichai@quicinc.com>
> ---
> drivers/pci/controller/dwc/pcie-qcom.c | 72 +++++++++++++++++++++++++++-------
> 1 file changed, 58 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controller/dwc/pcie-qcom.c
> index b4893214b2d3..4ad5ef3bf8fc 100644
> --- a/drivers/pci/controller/dwc/pcie-qcom.c
> +++ b/drivers/pci/controller/dwc/pcie-qcom.c
> @@ -22,6 +22,7 @@
> #include <linux/of.h>
> #include <linux/of_gpio.h>
> #include <linux/pci.h>
> +#include <linux/pm_opp.h>
> #include <linux/pm_runtime.h>
> #include <linux/platform_device.h>
> #include <linux/phy/pcie.h>
> @@ -1442,15 +1443,13 @@ static int qcom_pcie_icc_init(struct qcom_pcie *pcie)
> return 0;
> }
>
> -static void qcom_pcie_icc_update(struct qcom_pcie *pcie)
> +static void qcom_pcie_icc_opp_update(struct qcom_pcie *pcie)
> {
> struct dw_pcie *pci = pcie->pci;
> - u32 offset, status;
> + u32 offset, status, freq;
> + struct dev_pm_opp *opp;
> int speed, width;
> - int ret;
> -
> - if (!pcie->icc_mem)
> - return;
> + int ret, mbps;
>
> offset = dw_pcie_find_capability(pci, PCI_CAP_ID_EXP);
> status = readw(pci->dbi_base + offset + PCI_EXP_LNKSTA);
> @@ -1462,10 +1461,26 @@ static void qcom_pcie_icc_update(struct qcom_pcie *pcie)
> speed = FIELD_GET(PCI_EXP_LNKSTA_CLS, status);
> width = FIELD_GET(PCI_EXP_LNKSTA_NLW, status);
>
> - ret = icc_set_bw(pcie->icc_mem, 0, width * QCOM_PCIE_LINK_SPEED_TO_BW(speed));
> - if (ret) {
> - dev_err(pci->dev, "failed to set interconnect bandwidth for PCIe-MEM: %d\n",
> - ret);
> + if (pcie->icc_mem) {
> + ret = icc_set_bw(pcie->icc_mem, 0, width * QCOM_PCIE_LINK_SPEED_TO_BW(speed));
> + if (ret) {
> + dev_err(pci->dev, "failed to set interconnect bandwidth for PCIe-MEM: %d\n",
s/failed/Failed
> + ret);
> + }
> + } else {
> + mbps = pcie_link_speed_to_mbps(pcie_link_speed[speed]);
> + if (mbps < 0)
> + return;
> +
> + freq = mbps * 1000;
> + opp = dev_pm_opp_find_freq_exact(pci->dev, freq * width, true);
As per the API documentation, dev_pm_opp_put() should be called for both success
and failure case.
> + if (!IS_ERR(opp)) {
So what is the action if OPP is not found for the freq?
> + ret = dev_pm_opp_set_opp(pci->dev, opp);
> + if (ret)
> + dev_err(pci->dev, "Failed to set opp: freq %ld ret %d\n",
'Failed to set OPP for freq (%ld): %d'
> + dev_pm_opp_get_freq(opp), ret);
> + dev_pm_opp_put(opp);
> + }
> }
> }
>
> @@ -1509,8 +1524,10 @@ static void qcom_pcie_init_debugfs(struct qcom_pcie *pcie)
> static int qcom_pcie_probe(struct platform_device *pdev)
> {
> const struct qcom_pcie_cfg *pcie_cfg;
> + unsigned long max_freq = INT_MAX;
> struct device *dev = &pdev->dev;
> struct qcom_pcie *pcie;
> + struct dev_pm_opp *opp;
> struct dw_pcie_rp *pp;
> struct resource *res;
> struct dw_pcie *pci;
> @@ -1577,9 +1594,33 @@ static int qcom_pcie_probe(struct platform_device *pdev)
> goto err_pm_runtime_put;
> }
>
> - ret = qcom_pcie_icc_init(pcie);
> - if (ret)
> + /* OPP table is optional */
> + ret = devm_pm_opp_of_add_table(dev);
> + if (ret && ret != -ENODEV) {
> + dev_err_probe(dev, ret, "Failed to add OPP table\n");
> goto err_pm_runtime_put;
> + }
> +
> + /*
> + * Use highest OPP here if the OPP table is present. At the end of
I believe I asked you to add the information justifying why the highest OPP
should be used.
> + * the probe(), OPP will be updated using qcom_pcie_icc_opp_update().
> + */
> + if (!ret) {
> + opp = dev_pm_opp_find_freq_floor(dev, &max_freq);
Same comment as dev_pm_opp_find_freq_exact().
> + if (!IS_ERR(opp)) {
> + ret = dev_pm_opp_set_opp(dev, opp);
> + if (ret)
> + dev_err_probe(pci->dev, ret,
> + "Failed to set OPP: freq %ld\n",
Same comment as above.
> + dev_pm_opp_get_freq(opp));
> + dev_pm_opp_put(opp);
So you want to continue even in the case of failure?
- Mani
> + }
> + } else {
> + /* Skip ICC init if OPP is supported as it is handled by OPP */
> + ret = qcom_pcie_icc_init(pcie);
> + if (ret)
> + goto err_pm_runtime_put;
> + }
>
> ret = pcie->cfg->ops->get_resources(pcie);
> if (ret)
> @@ -1599,7 +1640,7 @@ static int qcom_pcie_probe(struct platform_device *pdev)
> goto err_phy_exit;
> }
>
> - qcom_pcie_icc_update(pcie);
> + qcom_pcie_icc_opp_update(pcie);
>
> if (pcie->mhi)
> qcom_pcie_init_debugfs(pcie);
> @@ -1658,6 +1699,9 @@ static int qcom_pcie_suspend_noirq(struct device *dev)
> if (ret)
> dev_err(dev, "failed to disable icc path of CPU-PCIe: %d\n", ret);
>
> + if (!pcie->icc_mem)
> + dev_pm_opp_set_opp(pcie->pci->dev, NULL);
> +
> return ret;
> }
>
> @@ -1680,7 +1724,7 @@ static int qcom_pcie_resume_noirq(struct device *dev)
> pcie->suspended = false;
> }
>
> - qcom_pcie_icc_update(pcie);
> + qcom_pcie_icc_opp_update(pcie);
>
> return 0;
> }
>
> --
> 2.42.0
>
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set additionalProperties to true
From: Krzysztof Kozlowski @ 2024-04-07 16:15 UTC (permalink / raw)
To: Peng Fan, Peng Fan (OSS), Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Sudeep Holla, Cristian Marussi
Cc: devicetree@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <DU0PR04MB9417C5B9BDD9E0B47E7494C088012@DU0PR04MB9417.eurprd04.prod.outlook.com>
On 07/04/2024 12:04, Peng Fan wrote:
>> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
>> additionalProperties to true
>>
>> On 07/04/2024 02:37, Peng Fan wrote:
>>>> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
>>>> additionalProperties to true
>>>>
>>>> On 05/04/2024 14:39, Peng Fan (OSS) wrote:
>>>>> From: Peng Fan <peng.fan@nxp.com>
>>>>>
>>>>> When adding vendor extension protocols, there is dt-schema warning:
>>>>> "
>>>>> imx,scmi.example.dtb: scmi: 'protocol@81', 'protocol@84' do not
>>>>> match any of the regexes: 'pinctrl-[0-9]+'
>>>>> "
>>>>>
>>>>> Set additionalProperties to true to address the issue.
>>>>
>>>> I do not see anything addressed here, except making the binding
>>>> accepting anything anywhere...
>>>
>>> I not wanna add vendor protocols in arm,scmi.yaml, so will introduce a
>>> new yaml imx.scmi.yaml which add i.MX SCMI protocol extension.
>>>
>>> With additionalProperties set to false, I not know how, please suggest.
>>
>> First of all, you cannot affect negatively existing devices (their
>> bindings) and your patch does exactly that. This should make you thing what
>> is the correct approach...
>>
>> Rob gave you the comment about missing compatible - you still did not
>> address that.
>
> I added the compatible in patch 2/6 in the examples "compatible = "arm,scmi";"
So you claim that your vendor extensions are the same or fully
compatible with arm,scmi and you add nothing... Are your
extensions/protocol valid for arm,scmi? If yes, why is this in separate
binding. If no, why you use someone else's compatible?
Maybe your binding is correct, feel free to convince me (and read first
writing bindings).
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v9 0/7] spmi: pmic-arb: Add support for multiple buses
From: Abel Vesa @ 2024-04-07 16:23 UTC (permalink / raw)
To: Stephen Boyd, Matthias Brugger, Bjorn Andersson, Konrad Dybcio,
Dmitry Baryshkov, Neil Armstrong, AngeloGioacchino Del Regno,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Srini Kandagatla, Johan Hovold, David Collins, linux-kernel,
linux-arm-kernel, linux-arm-msm, linux-mediatek, devicetree,
Abel Vesa, Krzysztof Kozlowski
This patchset prepares for and adds support for 2 buses, which is supported
in HW starting with version 7. Until now, none of the currently
supported platforms in upstream have used the second bus. The X1E80100
platform, on the other hand, needs the second bus for the USB2.0 to work
as there are 3 SMB2360 PMICs which provide eUSB2 repeaters and they are
all found on the second bus.
Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
---
Changes in v9:
- Use the proper number of buses on deregister, like David suggested
- Moved the lock from the arbiter to the bus, like David suggested
- Fixed type in schema file, pointed out by David
- Added Neil's R-b tag to patches #3, #6 and #7
- Link to v8: https://lore.kernel.org/r/20240402-spmi-multi-master-support-v8-0-ce6f2d14a058@linaro.org
Changes in v8:
- Added Neil's R-b tag to the 3rd patch
- Fixed compile warnings already existent by adding another patch
- Fixed compile warning about get_core_resources, reported by Neil
- Dropped and moved the spurious core removal changes, as suggested by Neil
- Link to v7: https://lore.kernel.org/r/20240329-spmi-multi-master-support-v7-0-7b902824246c@linaro.org
Changes in v7:
- This time really collected Krzysztof's R-b tags
- Added Neil's R-b tag to the 4th patch
- Split the multi bus patch into two separate patches, one for adding
the bus object and one for the secondary bus, as per Neil's suggestion
- Fixed regression for single bus platforms triggered by casting to
pmic_arb instead of bus in pmic_arb_non_data_cmd_v1
- Fixed bus object allocation by using ctrl drvdata instead
- Prefixed the spmi node property in x1e80100 schema with '^'
- Fixed struct and function documentation warnings reported by Neil
Changes in v6 (resend):
- Collected Krzysztof's R-b tags
- Link to v6: https://lore.kernel.org/r/20240222-spmi-multi-master-support-v6-0-bc34ea9561da@linaro.org
Changes in v6:
- Changed the compatible to platform specific (X1E80100) along with the
schema. Fixed the spmi buses unit addresses and added the empty ranges
property. Added missing properties to the spmi buses and the
"unevaluatedProperties: false".
- Deprecated the "qcom,bus-id" in the legacy schema.
- Changed the driver to check for legacy compatible first
- Link to v5: https://lore.kernel.org/r/20240221-spmi-multi-master-support-v5-0-3255ca413a0b@linaro.org
Changes in v5:
- Dropped the RFC as there aren't any concerns about the approach anymore
- Dropped the unused dev and res variables from pmic_arb_get_obsrvr_chnls_v2
- Link to v4: https://lore.kernel.org/r/20240220-spmi-multi-master-support-v4-0-dc813c878ba8@linaro.org
Changes in v4:
- Fixed comment above pmic_arb_init_apid_v7 by dropping the extra "bus" word
- Swicthed to devm_platform_ioremap_resource_byname for obsrvr and chnls.
The core remains with platform_get_resource_byname as we need the core size.
- Dropped comment from probe related to the need of platform_get_resource_byname
as it not true anymore.
- Dropped the qcom,bus-id optional property.
- Link to v3: https://lore.kernel.org/r/20240214-spmi-multi-master-support-v3-0-0bae0ef04faf@linaro.org
Changes in v3:
- Split the change into 3 separate patches. First 2 patches are moving
apid init and core resources into version specific ops. Third one is
adding the support for 2 buses and dedicated compatible.
- Added separate bindings patch
- Link to v2: https://lore.kernel.org/r/20240213-spmi-multi-master-support-v2-1-b3b102326906@linaro.org
Changes in v2:
- Reworked it so that it registers a spmi controller for each bus
rather than relying on the generic framework to pass on the bus
(master) id.
- Link to v1: https://lore.kernel.org/r/20240207-spmi-multi-master-support-v1-0-ce57f301c7fd@linaro.org
---
Abel Vesa (7):
dt-bindings: spmi: Add X1E80100 SPMI PMIC ARB schema
dt-bindings: spmi: Deprecate qcom,bus-id
spmi: pmic-arb: Fix some compile warnings about members not being described
spmi: pmic-arb: Make the APID init a version operation
spmi: pmic-arb: Make core resources acquiring a version operation
spmi: pmic-arb: Register controller for bus instead of arbiter
spmi: pmic-arb: Add multi bus support
.../bindings/spmi/qcom,spmi-pmic-arb.yaml | 1 +
.../bindings/spmi/qcom,x1e80100-spmi-pmic-arb.yaml | 136 +++
drivers/spmi/spmi-pmic-arb.c | 964 +++++++++++++--------
3 files changed, 728 insertions(+), 373 deletions(-)
---
base-commit: 8568bb2ccc278f344e6ac44af6ed010a90aa88dc
change-id: 20240207-spmi-multi-master-support-832a704b779b
Best regards,
--
Abel Vesa <abel.vesa@linaro.org>
^ permalink raw reply
* [PATCH v9 1/7] dt-bindings: spmi: Add X1E80100 SPMI PMIC ARB schema
From: Abel Vesa @ 2024-04-07 16:23 UTC (permalink / raw)
To: Stephen Boyd, Matthias Brugger, Bjorn Andersson, Konrad Dybcio,
Dmitry Baryshkov, Neil Armstrong, AngeloGioacchino Del Regno,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Srini Kandagatla, Johan Hovold, David Collins, linux-kernel,
linux-arm-kernel, linux-arm-msm, linux-mediatek, devicetree,
Abel Vesa, Krzysztof Kozlowski
In-Reply-To: <20240407-spmi-multi-master-support-v9-0-fa151c1391f3@linaro.org>
Add dedicated schema for X1E80100 PMIC ARB (v7) as it allows multiple
buses by declaring them as child nodes.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
---
.../bindings/spmi/qcom,x1e80100-spmi-pmic-arb.yaml | 136 +++++++++++++++++++++
1 file changed, 136 insertions(+)
diff --git a/Documentation/devicetree/bindings/spmi/qcom,x1e80100-spmi-pmic-arb.yaml b/Documentation/devicetree/bindings/spmi/qcom,x1e80100-spmi-pmic-arb.yaml
new file mode 100644
index 000000000000..a28b70fb330a
--- /dev/null
+++ b/Documentation/devicetree/bindings/spmi/qcom,x1e80100-spmi-pmic-arb.yaml
@@ -0,0 +1,136 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spmi/qcom,x1e80100-spmi-pmic-arb.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm X1E80100 SPMI Controller (PMIC Arbiter v7)
+
+maintainers:
+ - Stephen Boyd <sboyd@kernel.org>
+
+description: |
+ The X1E80100 SPMI PMIC Arbiter implements HW version 7 and it's an SPMI
+ controller with wrapping arbitration logic to allow for multiple on-chip
+ devices to control up to 2 SPMI separate buses.
+
+ The PMIC Arbiter can also act as an interrupt controller, providing interrupts
+ to slave devices.
+
+properties:
+ compatible:
+ const: qcom,x1e80100-spmi-pmic-arb
+
+ reg:
+ items:
+ - description: core registers
+ - description: tx-channel per virtual slave registers
+ - description: rx-channel (called observer) per virtual slave registers
+
+ reg-names:
+ items:
+ - const: core
+ - const: chnls
+ - const: obsrvr
+
+ ranges: true
+
+ '#address-cells':
+ const: 2
+
+ '#size-cells':
+ const: 2
+
+ qcom,ee:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 5
+ description: >
+ indicates the active Execution Environment identifier
+
+ qcom,channel:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 5
+ description: >
+ which of the PMIC Arb provided channels to use for accesses
+
+patternProperties:
+ "^spmi@[a-f0-9]+$":
+ type: object
+ $ref: /schemas/spmi/spmi.yaml
+ unevaluatedProperties: false
+
+ properties:
+ reg:
+ items:
+ - description: configuration registers
+ - description: interrupt controller registers
+
+ reg-names:
+ items:
+ - const: cnfg
+ - const: intr
+
+ interrupts:
+ maxItems: 1
+
+ interrupt-names:
+ const: periph_irq
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 4
+ description: |
+ cell 1: slave ID for the requested interrupt (0-15)
+ cell 2: peripheral ID for requested interrupt (0-255)
+ cell 3: the requested peripheral interrupt (0-7)
+ cell 4: interrupt flags indicating level-sense information,
+ as defined in dt-bindings/interrupt-controller/irq.h
+
+required:
+ - compatible
+ - reg-names
+ - qcom,ee
+ - qcom,channel
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ spmi: arbiter@c400000 {
+ compatible = "qcom,x1e80100-spmi-pmic-arb";
+ reg = <0 0x0c400000 0 0x3000>,
+ <0 0x0c500000 0 0x4000000>,
+ <0 0x0c440000 0 0x80000>;
+ reg-names = "core", "chnls", "obsrvr";
+
+ qcom,ee = <0>;
+ qcom,channel = <0>;
+
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ spmi_bus0: spmi@c42d000 {
+ reg = <0 0x0c42d000 0 0x4000>,
+ <0 0x0c4c0000 0 0x10000>;
+ reg-names = "cnfg", "intr";
+
+ interrupt-names = "periph_irq";
+ interrupts-extended = <&pdc 1 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-controller;
+ #interrupt-cells = <4>;
+
+ #address-cells = <2>;
+ #size-cells = <0>;
+ };
+ };
+ };
--
2.34.1
^ permalink raw reply related
* [PATCH v9 2/7] dt-bindings: spmi: Deprecate qcom,bus-id
From: Abel Vesa @ 2024-04-07 16:23 UTC (permalink / raw)
To: Stephen Boyd, Matthias Brugger, Bjorn Andersson, Konrad Dybcio,
Dmitry Baryshkov, Neil Armstrong, AngeloGioacchino Del Regno,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Srini Kandagatla, Johan Hovold, David Collins, linux-kernel,
linux-arm-kernel, linux-arm-msm, linux-mediatek, devicetree,
Abel Vesa, Krzysztof Kozlowski
In-Reply-To: <20240407-spmi-multi-master-support-v9-0-fa151c1391f3@linaro.org>
As it is optional and no platform is actually using the secondary bus,
deprecate the qcom,bus-id property. For newer platforms that implement
SPMI PMIC ARB v7 in HW, the X1E80100 approach should be used.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
---
Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.yaml b/Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.yaml
index f983b4af6db9..51daf1b847a9 100644
--- a/Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.yaml
+++ b/Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.yaml
@@ -92,6 +92,7 @@ properties:
description: >
SPMI bus instance. only applicable to PMIC arbiter version 7 and beyond.
Supported values, 0 = primary bus, 1 = secondary bus
+ deprecated: true
required:
- compatible
--
2.34.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox