* [PATCH v4 4/8] ARM: mstar: Link cpupll to cpu
From: Romain Perier @ 2022-01-26 17:56 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, linux-clk, Arnd Bergmann,
Daniel Palmer, Romain Perier, Rob Herring
Cc: devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20220126175604.17919-1-romain.perier@gmail.com>
From: Daniel Palmer <daniel@0x0f.com>
The CPU clock is sourced from the CPU PLL.
Link cpupll to the cpu so that frequency scaling can happen.
Signed-off-by: Daniel Palmer <daniel@0x0f.com>
Reviewed-by: Romain Perier <romain.perier@gmail.com>
---
arch/arm/boot/dts/mstar-v7.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/mstar-v7.dtsi b/arch/arm/boot/dts/mstar-v7.dtsi
index 2249faaa3aa7..c26ba9b7b6dd 100644
--- a/arch/arm/boot/dts/mstar-v7.dtsi
+++ b/arch/arm/boot/dts/mstar-v7.dtsi
@@ -21,6 +21,8 @@ cpu0: cpu@0 {
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x0>;
+ clocks = <&cpupll>;
+ clock-names = "cpuclk";
};
};
--
2.34.1
^ permalink raw reply related
* [PATCH v4 5/8] ARM: mstar: Link cpupll to second core
From: Romain Perier @ 2022-01-26 17:56 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, linux-clk, Arnd Bergmann,
Daniel Palmer, Romain Perier, Rob Herring
Cc: devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20220126175604.17919-1-romain.perier@gmail.com>
From: Daniel Palmer <daniel@0x0f.com>
The second core also sources it's clock from the CPU PLL.
Signed-off-by: Daniel Palmer <daniel@0x0f.com>
Reviewed-by: Romain Perier <romain.perier@gmail.com>
---
arch/arm/boot/dts/mstar-infinity2m.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/mstar-infinity2m.dtsi b/arch/arm/boot/dts/mstar-infinity2m.dtsi
index 6d4d1d224e96..dc339cd29778 100644
--- a/arch/arm/boot/dts/mstar-infinity2m.dtsi
+++ b/arch/arm/boot/dts/mstar-infinity2m.dtsi
@@ -11,6 +11,8 @@ cpu1: cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x1>;
+ clocks = <&cpupll>;
+ clock-names = "cpuclk";
};
};
--
2.34.1
^ permalink raw reply related
* [PATCH v4 6/8] ARM: mstar: Add OPP table for infinity
From: Romain Perier @ 2022-01-26 17:56 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, linux-clk, Arnd Bergmann,
Daniel Palmer, Romain Perier, Rob Herring
Cc: devicetree, linux-arm-kernel, linux-kernel, Willy Tarreau
In-Reply-To: <20220126175604.17919-1-romain.perier@gmail.com>
From: Daniel Palmer <daniel@0x0f.com>
Add an OPP table for the inifinity chips so
that cpu frequency scaling can happen.
Co-authored-by: Willy Tarreau <w@1wt.eu>
Signed-off-by: Daniel Palmer <daniel@0x0f.com>
Reviewed-by: Romain Perier <romain.perier@gmail.com>
---
arch/arm/boot/dts/mstar-infinity.dtsi | 34 +++++++++++++++++++++++++++
1 file changed, 34 insertions(+)
diff --git a/arch/arm/boot/dts/mstar-infinity.dtsi b/arch/arm/boot/dts/mstar-infinity.dtsi
index 0bee517797f4..441a917b88ba 100644
--- a/arch/arm/boot/dts/mstar-infinity.dtsi
+++ b/arch/arm/boot/dts/mstar-infinity.dtsi
@@ -8,6 +8,40 @@
#include <dt-bindings/gpio/msc313-gpio.h>
+/ {
+ cpu0_opp_table: opp_table0 {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp-240000000 {
+ opp-hz = /bits/ 64 <240000000>;
+ opp-microvolt = <1000000>;
+ clock-latency-ns = <300000>;
+ };
+
+ opp-400000000 {
+ opp-hz = /bits/ 64 <400000000>;
+ opp-microvolt = <1000000>;
+ clock-latency-ns = <300000>;
+ };
+ opp-600000000 {
+ opp-hz = /bits/ 64 <600000000>;
+ opp-microvolt = <1000000>;
+ clock-latency-ns = <300000>;
+ };
+
+ opp-800000000 {
+ opp-hz = /bits/ 64 <800000000>;
+ opp-microvolt = <1000000>;
+ clock-latency-ns = <300000>;
+ };
+ };
+};
+
+&cpu0 {
+ operating-points-v2 = <&cpu0_opp_table>;
+};
+
&imi {
reg = <0xa0000000 0x16000>;
};
--
2.34.1
^ permalink raw reply related
* [PATCH v4 7/8] ARM: mstar: Add OPP table for infinity3
From: Romain Perier @ 2022-01-26 17:56 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, linux-clk, Arnd Bergmann,
Daniel Palmer, Romain Perier, Rob Herring
Cc: devicetree, linux-arm-kernel, linux-kernel, Willy Tarreau
In-Reply-To: <20220126175604.17919-1-romain.perier@gmail.com>
From: Daniel Palmer <daniel@0x0f.com>
The infinity3 has a slightly higher max frequency
compared to the infinity so extend the OPP table.
Co-authored-by: Willy Tarreau <w@1wt.eu>
Signed-off-by: Daniel Palmer <daniel@0x0f.com>
Reviewed-by: Romain Perier <romain.perier@gmail.com>
---
arch/arm/boot/dts/mstar-infinity3.dtsi | 58 ++++++++++++++++++++++++++
1 file changed, 58 insertions(+)
diff --git a/arch/arm/boot/dts/mstar-infinity3.dtsi b/arch/arm/boot/dts/mstar-infinity3.dtsi
index 9857e2a9934d..a56cf29e5d82 100644
--- a/arch/arm/boot/dts/mstar-infinity3.dtsi
+++ b/arch/arm/boot/dts/mstar-infinity3.dtsi
@@ -6,6 +6,64 @@
#include "mstar-infinity.dtsi"
+&cpu0_opp_table {
+ opp-1008000000 {
+ opp-hz = /bits/ 64 <1008000000>;
+ opp-microvolt = <1000000>;
+ clock-latency-ns = <300000>;
+ };
+
+ // overclock frequencies below, shown to work fine up to 1.3 GHz
+ opp-108000000 {
+ opp-hz = /bits/ 64 <1080000000>;
+ opp-microvolt = <1000000>;
+ clock-latency-ns = <300000>;
+ turbo-mode;
+ };
+
+ opp-1188000000 {
+ opp-hz = /bits/ 64 <1188000000>;
+ opp-microvolt = <1000000>;
+ clock-latency-ns = <300000>;
+ turbo-mode;
+ };
+
+ opp-1296000000 {
+ opp-hz = /bits/ 64 <1296000000>;
+ opp-microvolt = <1000000>;
+ clock-latency-ns = <300000>;
+ turbo-mode;
+ };
+
+ opp-1350000000 {
+ opp-hz = /bits/ 64 <1350000000>;
+ opp-microvolt = <1000000>;
+ clock-latency-ns = <300000>;
+ turbo-mode;
+ };
+
+ opp-1404000000 {
+ opp-hz = /bits/ 64 <1404000000>;
+ opp-microvolt = <1000000>;
+ clock-latency-ns = <300000>;
+ turbo-mode;
+ };
+
+ opp-1458000000 {
+ opp-hz = /bits/ 64 <1458000000>;
+ opp-microvolt = <1000000>;
+ clock-latency-ns = <300000>;
+ turbo-mode;
+ };
+
+ opp-1512000000 {
+ opp-hz = /bits/ 64 <1512000000>;
+ opp-microvolt = <1000000>;
+ clock-latency-ns = <300000>;
+ turbo-mode;
+ };
+};
+
&imi {
reg = <0xa0000000 0x20000>;
};
--
2.34.1
^ permalink raw reply related
* [PATCH v4 8/8] ARM: mstar: Extend opp_table for infinity2m
From: Romain Perier @ 2022-01-26 17:56 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, linux-clk, Arnd Bergmann,
Daniel Palmer, Romain Perier, Rob Herring
Cc: devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20220126175604.17919-1-romain.perier@gmail.com>
infinity2m are running up to 1.2Ghz, this extends opp_table with the
corresponding frequencies and enable operating-points table for cpu1
Signed-off-by: Romain Perier <romain.perier@gmail.com>
---
arch/arm/boot/dts/mstar-infinity2m.dtsi | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/arch/arm/boot/dts/mstar-infinity2m.dtsi b/arch/arm/boot/dts/mstar-infinity2m.dtsi
index dc339cd29778..1b485efd7156 100644
--- a/arch/arm/boot/dts/mstar-infinity2m.dtsi
+++ b/arch/arm/boot/dts/mstar-infinity2m.dtsi
@@ -6,10 +6,25 @@
#include "mstar-infinity.dtsi"
+&cpu0_opp_table {
+ opp-1000000000 {
+ opp-hz = /bits/ 64 <1000000000>;
+ opp-microvolt = <1000000>;
+ clock-latency-ns = <300000>;
+ };
+
+ opp-1200000000 {
+ opp-hz = /bits/ 64 <1200000000>;
+ opp-microvolt = <1000000>;
+ clock-latency-ns = <300000>;
+ };
+};
+
&cpus {
cpu1: cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a7";
+ operating-points-v2 = <&cpu0_opp_table>;
reg = <0x1>;
clocks = <&cpupll>;
clock-names = "cpuclk";
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v3 02/12] misc: fastrpc: add support for FASTRPC_IOCTL_MEM_MAP/UNMAP
From: kernel test robot @ 2022-01-26 18:00 UTC (permalink / raw)
To: Srinivas Kandagatla, robh+dt, gregkh
Cc: kbuild-all, devicetree, ekangupt, bkumar, linux-kernel, srini,
bjorn.andersson, linux-arm-msm, Jeya R
In-Reply-To: <20220126135304.16340-3-srinivas.kandagatla@linaro.org>
Hi Srinivas,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on char-misc/char-misc-testing]
[also build test WARNING on robh/for-next linux/master linus/master v5.17-rc1 next-20220125]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url: https://github.com/0day-ci/linux/commits/Srinivas-Kandagatla/misc-fastrpc-Add-missing-DSP-FastRPC-features/20220126-215705
base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git 515a2f507491e7c3818e74ef4f4e088c1fecb190
config: nds32-randconfig-r014-20220126 (https://download.01.org/0day-ci/archive/20220127/202201270134.bsVprnF9-lkp@intel.com/config)
compiler: nds32le-linux-gcc (GCC) 11.2.0
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# https://github.com/0day-ci/linux/commit/b1c0b7969aa491881596e862a90a07afae4bdfd7
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review Srinivas-Kandagatla/misc-fastrpc-Add-missing-DSP-FastRPC-features/20220126-215705
git checkout b1c0b7969aa491881596e862a90a07afae4bdfd7
# save the config file to linux build tree
mkdir build_dir
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross O=build_dir ARCH=nds32 SHELL=/bin/bash
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All warnings (new ones prefixed by >>):
drivers/misc/fastrpc.c: In function 'fastrpc_req_mem_unmap_impl':
>> drivers/misc/fastrpc.c:1544:23: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
1544 | args[0].ptr = (u64) &req_msg;
| ^
drivers/misc/fastrpc.c: In function 'fastrpc_req_mem_map':
>> drivers/misc/fastrpc.c:1594:19: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
1594 | map->va = (void *) req.vaddrin;
| ^
drivers/misc/fastrpc.c:1599:23: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
1599 | args[0].ptr = (u64) &req_msg;
| ^
drivers/misc/fastrpc.c:1605:23: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
1605 | args[1].ptr = (u64) &pages;
| ^
drivers/misc/fastrpc.c:1608:23: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
1608 | args[2].ptr = (u64) &pages;
| ^
drivers/misc/fastrpc.c:1611:23: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
1611 | args[3].ptr = (u64) &rsp_msg;
| ^
vim +1544 drivers/misc/fastrpc.c
1515
1516 static int fastrpc_req_mem_unmap_impl(struct fastrpc_user *fl, struct fastrpc_mem_unmap *req)
1517 {
1518 struct fastrpc_invoke_args args[1] = { [0] = { 0 } };
1519 struct fastrpc_map *map = NULL, *m;
1520 struct fastrpc_mem_unmap_req_msg req_msg = { 0 };
1521 int err = 0;
1522 u32 sc;
1523 struct device *dev = fl->sctx->dev;
1524
1525 spin_lock(&fl->lock);
1526 list_for_each_entry_safe(map, m, &fl->maps, node) {
1527 if ((req->fd < 0 || map->fd == req->fd) && (map->raddr == req->vaddr))
1528 break;
1529 map = NULL;
1530 }
1531
1532 spin_unlock(&fl->lock);
1533
1534 if (!map) {
1535 dev_err(dev, "map not in list\n");
1536 return -EINVAL;
1537 }
1538
1539 req_msg.pgid = fl->tgid;
1540 req_msg.len = map->len;
1541 req_msg.vaddrin = map->raddr;
1542 req_msg.fd = map->fd;
1543
> 1544 args[0].ptr = (u64) &req_msg;
1545 args[0].length = sizeof(req_msg);
1546
1547 sc = FASTRPC_SCALARS(FASTRPC_RMID_INIT_MEM_UNMAP, 1, 0);
1548 err = fastrpc_internal_invoke(fl, true, FASTRPC_INIT_HANDLE, sc,
1549 &args[0]);
1550 fastrpc_map_put(map);
1551 if (err)
1552 dev_err(dev, "unmmap\tpt fd = %d, 0x%09llx error\n", map->fd, map->raddr);
1553
1554 return err;
1555 }
1556
1557 static int fastrpc_req_mem_unmap(struct fastrpc_user *fl, char __user *argp)
1558 {
1559 struct fastrpc_mem_unmap req;
1560
1561 if (copy_from_user(&req, argp, sizeof(req)))
1562 return -EFAULT;
1563
1564 return fastrpc_req_mem_unmap_impl(fl, &req);
1565 }
1566
1567 static int fastrpc_req_mem_map(struct fastrpc_user *fl, char __user *argp)
1568 {
1569 struct fastrpc_invoke_args args[4] = { [0 ... 3] = { 0 } };
1570 struct fastrpc_mem_map_req_msg req_msg = { 0 };
1571 struct fastrpc_mmap_rsp_msg rsp_msg = { 0 };
1572 struct fastrpc_mem_unmap req_unmap = { 0 };
1573 struct fastrpc_phy_page pages = { 0 };
1574 struct fastrpc_mem_map req;
1575 struct device *dev = fl->sctx->dev;
1576 struct fastrpc_map *map = NULL;
1577 int err;
1578 u32 sc;
1579
1580 if (copy_from_user(&req, argp, sizeof(req)))
1581 return -EFAULT;
1582
1583 /* create SMMU mapping */
1584 err = fastrpc_map_create(fl, req.fd, req.length, &map);
1585 if (err) {
1586 dev_err(dev, "failed to map buffer, fd = %d\n", req.fd);
1587 return err;
1588 }
1589
1590 req_msg.pgid = fl->tgid;
1591 req_msg.fd = req.fd;
1592 req_msg.offset = req.offset;
1593 req_msg.vaddrin = req.vaddrin;
> 1594 map->va = (void *) req.vaddrin;
1595 req_msg.flags = req.flags;
1596 req_msg.num = sizeof(pages);
1597 req_msg.data_len = 0;
1598
1599 args[0].ptr = (u64) &req_msg;
1600 args[0].length = sizeof(req_msg);
1601
1602 pages.addr = map->phys;
1603 pages.size = map->size;
1604
1605 args[1].ptr = (u64) &pages;
1606 args[1].length = sizeof(pages);
1607
1608 args[2].ptr = (u64) &pages;
1609 args[2].length = 0;
1610
1611 args[3].ptr = (u64) &rsp_msg;
1612 args[3].length = sizeof(rsp_msg);
1613
1614 sc = FASTRPC_SCALARS(FASTRPC_RMID_INIT_MEM_MAP, 3, 1);
1615 err = fastrpc_internal_invoke(fl, true, FASTRPC_INIT_HANDLE, sc, &args[0]);
1616 if (err) {
1617 dev_err(dev, "mem mmap error, fd %d, vaddr %llx, size %lld\n",
1618 req.fd, req.vaddrin, map->size);
1619 goto err_invoke;
1620 }
1621
1622 /* update the buffer to be able to deallocate the memory on the DSP */
1623 map->raddr = rsp_msg.vaddr;
1624
1625 /* let the client know the address to use */
1626 req.vaddrout = rsp_msg.vaddr;
1627
1628 if (copy_to_user((void __user *)argp, &req, sizeof(req))) {
1629 /* unmap the memory and release the buffer */
1630 req_unmap.vaddr = (uintptr_t) rsp_msg.vaddr;
1631 req_unmap.length = map->size;
1632 fastrpc_req_mem_unmap_impl(fl, &req_unmap);
1633 return -EFAULT;
1634 }
1635
1636 return 0;
1637
1638 err_invoke:
1639 if (map)
1640 fastrpc_map_put(map);
1641
1642 return err;
1643 }
1644
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* [PATCH v4 4/5] drivers: bus: add driver for initializing the SSC bus on (some) qcom SoCs
From: michael.srba @ 2022-01-26 18:32 UTC (permalink / raw)
To: Andy Gross, Bjorn Andersson, Rob Herring, Stephen Boyd,
Philipp Zabel
Cc: Linus Walleij, Florian Fainelli, Arnd Bergmann,
Greg Kroah-Hartman, Saravana Kannan, linux-arm-msm, linux-clk,
devicetree, Michael Srba
In-Reply-To: <20220126183250.11924-1-michael.srba@seznam.cz>
From: Michael Srba <Michael.Srba@seznam.cz>
This patch adds bindings for the AHB bus which exposes the SCC block in
the global address space. This bus (and the SSC block itself) is present
on certain qcom SoCs.
In typical configuration, this bus (as some of the clocks and registers
that we need to manipulate) is not accessible to Linux, and the resources
on this bus are indirectly accessed by communicating with a hexagon CPU
core residing in the SSC block. In this configuration, the hypervisor is
the one performing the bus initialization for the purposes of bringing
the haxagon CPU core out of reset.
However, it is possible to change the configuration, in which case this
driver will initialize the bus.
In combination with drivers for resources on the SSC bus, this driver can
aid in debugging, and for example with a TLMM driver can be used to
directly access SSC-dedicated GPIO pins, removing the need to commit
to a particular usecase during hw design.
Finally, until open firmware for the hexagon core is available, this
approach allows for using sensors hooked up to SSC-dedicated GPIO pins
on mainline Linux simply by utilizing the existing in-tree drivers for
these sensors.
Signed-off-by: Michael Srba <Michael.Srba@seznam.cz>
---
CHANGES:
- v2: none
- v3: fix clang warning
- v4: address the issues pointed out in the review
---
drivers/bus/Kconfig | 6 +
drivers/bus/Makefile | 1 +
drivers/bus/qcom-ssc-block-bus.c | 383 +++++++++++++++++++++++++++++++
3 files changed, 390 insertions(+)
create mode 100644 drivers/bus/qcom-ssc-block-bus.c
diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
index 3c68e174a113..f2b2e3098491 100644
--- a/drivers/bus/Kconfig
+++ b/drivers/bus/Kconfig
@@ -173,6 +173,12 @@ config SUNXI_RSB
with various RSB based devices, such as AXP223, AXP8XX PMICs,
and AC100/AC200 ICs.
+config QCOM_SSC_BLOCK_BUS
+ bool "Qualcomm SSC Block Bus Init Driver"
+ help
+ Say y here to enable support for initializing the bus that connects the SSC block's internal
+ bus to the cNoC on (some) qcom SoCs
+
config TEGRA_ACONNECT
tristate "Tegra ACONNECT Bus Driver"
depends on ARCH_TEGRA_210_SOC
diff --git a/drivers/bus/Makefile b/drivers/bus/Makefile
index 52c2f35a26a9..e6756e83a9c4 100644
--- a/drivers/bus/Makefile
+++ b/drivers/bus/Makefile
@@ -25,6 +25,7 @@ obj-$(CONFIG_OMAP_INTERCONNECT) += omap_l3_smx.o omap_l3_noc.o
obj-$(CONFIG_OMAP_OCP2SCP) += omap-ocp2scp.o
obj-$(CONFIG_QCOM_EBI2) += qcom-ebi2.o
+obj-$(CONFIG_QCOM_SSC_BLOCK_BUS) += qcom-ssc-block-bus.o
obj-$(CONFIG_SUN50I_DE2_BUS) += sun50i-de2.o
obj-$(CONFIG_SUNXI_RSB) += sunxi-rsb.o
obj-$(CONFIG_OF) += simple-pm-bus.o
diff --git a/drivers/bus/qcom-ssc-block-bus.c b/drivers/bus/qcom-ssc-block-bus.c
new file mode 100644
index 000000000000..e489f5614e90
--- /dev/null
+++ b/drivers/bus/qcom-ssc-block-bus.c
@@ -0,0 +1,383 @@
+// SPDX-License-Identifier: GPL-2.0-only
+// Copyright (c) 2021, Michael Srba
+
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/io.h>
+#include <linux/mfd/syscon.h>
+#include <linux/module.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <linux/pm_clock.h>
+#include <linux/pm_domain.h>
+#include <linux/pm_runtime.h>
+#include <linux/regmap.h>
+#include <linux/reset.h>
+
+/* AXI Halt Register Offsets */
+#define AXI_HALTREQ_REG 0x0
+#define AXI_HALTACK_REG 0x4
+#define AXI_IDLE_REG 0x8
+
+static const char *const qcom_ssc_block_pd_names[] = {
+ "ssc_cx",
+ "ssc_mx"
+};
+
+struct qcom_ssc_block_bus_data {
+ int num_pds;
+ const char *const *pd_names;
+ struct device *pds[ARRAY_SIZE(qcom_ssc_block_pd_names)];
+ char __iomem *reg_mpm_sscaon_config0; // MPM - msm power manager; AON - always-on
+ char __iomem *reg_mpm_sscaon_config1; // that's as much as we know about these
+ struct regmap *halt_map;
+ u32 ssc_axi_halt;
+ struct clk *xo_clk;
+ struct clk *aggre2_clk;
+ struct clk *gcc_im_sleep_clk;
+ struct clk *aggre2_north_clk;
+ struct clk *ssc_xo_clk;
+ struct clk *ssc_ahbs_clk;
+ struct reset_control *ssc_bcr;
+ struct reset_control *ssc_reset;
+};
+
+static void reg32_set_bits(char __iomem *reg, u32 value)
+{
+ u32 tmp = ioread32(reg);
+
+ iowrite32(tmp | value, reg);
+}
+
+static void reg32_clear_bits(char __iomem *reg, u32 value)
+{
+ u32 tmp = ioread32(reg);
+
+ iowrite32(tmp & (~value), reg);
+}
+
+
+static int qcom_ssc_block_bus_init(struct device *dev)
+{
+ int ret;
+
+ struct qcom_ssc_block_bus_data *data = dev_get_drvdata(dev);
+
+ ret = clk_prepare_enable(data->xo_clk);
+ if (ret) {
+ dev_err(dev, "error enabling xo_clk: %d\n", ret);
+ goto err_xo_clk;
+ }
+
+ ret = clk_prepare_enable(data->aggre2_clk);
+ if (ret) {
+ dev_err(dev, "error enabling aggre2_clk: %d\n", ret);
+ goto err_aggre2_clk;
+ }
+
+ ret = clk_prepare_enable(data->gcc_im_sleep_clk);
+ if (ret) {
+ dev_err(dev, "error enabling gcc_im_sleep_clk: %d\n", ret);
+ goto err_gcc_im_sleep_clk;
+ }
+
+ reg32_clear_bits(data->reg_mpm_sscaon_config0, BIT(4) | BIT(5));
+ reg32_clear_bits(data->reg_mpm_sscaon_config1, BIT(31));
+
+ ret = clk_prepare_enable(data->aggre2_north_clk);
+ if (ret) {
+ dev_err(dev, "error enabling aggre2_north_clk: %d\n", ret);
+ goto err_aggre2_north_clk;
+ }
+
+ ret = reset_control_deassert(data->ssc_reset);
+ if (ret) {
+ dev_err(dev, "error deasserting ssc_reset: %d\n", ret);
+ goto err_ssc_reset;
+ }
+
+ ret = reset_control_deassert(data->ssc_bcr);
+ if (ret) {
+ dev_err(dev, "error deasserting ssc_bcr: %d\n", ret);
+ goto err_ssc_bcr;
+ }
+
+ regmap_write(data->halt_map, data->ssc_axi_halt + AXI_HALTREQ_REG, 0);
+
+ ret = clk_prepare_enable(data->ssc_xo_clk);
+ if (ret) {
+ dev_err(dev, "error deasserting ssc_xo_clk: %d\n", ret);
+ goto err_ssc_xo_clk;
+ }
+
+ ret = clk_prepare_enable(data->ssc_ahbs_clk);
+ if (ret) {
+ dev_err(dev, "error deasserting ssc_ahbs_clk: %d\n", ret);
+ goto err_ssc_ahbs_clk;
+ }
+
+ return 0;
+
+err_ssc_ahbs_clk:
+ clk_disable(data->ssc_xo_clk);
+
+err_ssc_xo_clk:
+ regmap_write(data->halt_map, data->ssc_axi_halt + AXI_HALTREQ_REG, 1);
+
+ reset_control_assert(data->ssc_bcr);
+
+err_ssc_bcr:
+ reset_control_assert(data->ssc_reset);
+
+err_ssc_reset:
+ clk_disable(data->aggre2_north_clk);
+
+err_aggre2_north_clk:
+ reg32_set_bits(data->reg_mpm_sscaon_config0, BIT(4) | BIT(5));
+ reg32_set_bits(data->reg_mpm_sscaon_config1, BIT(31));
+
+ clk_disable(data->gcc_im_sleep_clk);
+
+err_gcc_im_sleep_clk:
+ clk_disable(data->aggre2_clk);
+
+err_aggre2_clk:
+ clk_disable(data->xo_clk);
+
+err_xo_clk:
+ return ret;
+}
+
+static void qcom_ssc_block_bus_deinit(struct device *dev)
+{
+ int ret;
+
+ struct qcom_ssc_block_bus_data *data = dev_get_drvdata(dev);
+
+ clk_disable(data->ssc_xo_clk);
+ clk_disable(data->ssc_ahbs_clk);
+
+ ret = reset_control_assert(data->ssc_bcr);
+ if (ret)
+ dev_err(dev, "error asserting ssc_bcr: %d\n", ret);
+
+ regmap_write(data->halt_map, data->ssc_axi_halt + AXI_HALTREQ_REG, 1);
+
+ reg32_set_bits(data->reg_mpm_sscaon_config1, BIT(31));
+ reg32_set_bits(data->reg_mpm_sscaon_config0, BIT(4) | BIT(5));
+
+ ret = reset_control_assert(data->ssc_reset);
+ if (ret)
+ dev_err(dev, "error asserting ssc_reset: %d\n", ret);
+
+ clk_disable(data->gcc_im_sleep_clk);
+
+ clk_disable(data->aggre2_north_clk);
+
+ clk_disable(data->aggre2_clk);
+ clk_disable(data->xo_clk);
+}
+
+
+static int qcom_ssc_block_bus_pds_attach(struct device *dev, struct device **pds,
+ const char *const *pd_names, size_t num_pds)
+{
+ int ret;
+ int i;
+
+ for (i = 0; i < num_pds; i++) {
+ pds[i] = dev_pm_domain_attach_by_name(dev, pd_names[i]);
+ if (IS_ERR_OR_NULL(pds[i])) {
+ ret = PTR_ERR(pds[i]) ? : -ENODATA;
+ goto unroll_attach;
+ }
+ }
+
+ return num_pds;
+
+unroll_attach:
+ for (i--; i >= 0; i--)
+ dev_pm_domain_detach(pds[i], false);
+
+ return ret;
+};
+
+static void qcom_ssc_block_bus_pds_detach(struct device *dev, struct device **pds, size_t num_pds)
+{
+ int i;
+
+ for (i = 0; i < num_pds; i++)
+ dev_pm_domain_detach(pds[i], false);
+}
+
+static int qcom_ssc_block_bus_pds_enable(struct device **pds, size_t num_pds)
+{
+ int ret;
+ int i;
+
+ for (i = 0; i < num_pds; i++) {
+ dev_pm_genpd_set_performance_state(pds[i], INT_MAX);
+ ret = pm_runtime_get_sync(pds[i]);
+ if (ret < 0)
+ goto unroll_pd_votes;
+ }
+
+ return 0;
+
+unroll_pd_votes:
+ for (i--; i >= 0; i--) {
+ dev_pm_genpd_set_performance_state(pds[i], 0);
+ pm_runtime_put(pds[i]);
+ }
+
+ return ret;
+};
+
+static void qcom_ssc_block_bus_pds_disable(struct device **pds, size_t num_pds)
+{
+ int i;
+
+ for (i = 0; i < num_pds; i++) {
+ dev_pm_genpd_set_performance_state(pds[i], 0);
+ pm_runtime_put(pds[i]);
+ }
+}
+
+static int qcom_ssc_block_bus_probe(struct platform_device *pdev)
+{
+ struct qcom_ssc_block_bus_data *data;
+ struct device_node *np = pdev->dev.of_node;
+ struct of_phandle_args halt_args;
+ struct resource *res;
+ int ret;
+
+ data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ platform_set_drvdata(pdev, data);
+
+ data->pd_names = qcom_ssc_block_pd_names;
+ data->num_pds = ARRAY_SIZE(qcom_ssc_block_pd_names);
+
+ // power domains
+ ret = qcom_ssc_block_bus_pds_attach(&pdev->dev, data->pds, data->pd_names, data->num_pds);
+ if (ret < 0)
+ return dev_err_probe(&pdev->dev, ret, "error when attaching power domains\n");
+
+ ret = qcom_ssc_block_bus_pds_enable(data->pds, data->num_pds);
+ if (ret < 0)
+ return dev_err_probe(&pdev->dev, ret, "error when enabling power domains\n");
+
+ // the meaning of the bits in these two registers is sadly not documented,
+ // the set/clear operations are just copying what qcom does
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "mpm_sscaon_config0");
+ data->reg_mpm_sscaon_config0 = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(data->reg_mpm_sscaon_config0))
+ return dev_err_probe(&pdev->dev, PTR_ERR(data->reg_mpm_sscaon_config0),
+ "Failed to ioremap mpm_sscaon_config0\n");
+
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "mpm_sscaon_config1");
+ data->reg_mpm_sscaon_config1 = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(data->reg_mpm_sscaon_config1))
+ return dev_err_probe(&pdev->dev, PTR_ERR(data->reg_mpm_sscaon_config1),
+ "Failed to ioremap mpm_sscaon_config1\n");
+
+ // resets
+ data->ssc_bcr = devm_reset_control_get_exclusive(&pdev->dev, "ssc_bcr");
+ if (IS_ERR(data->ssc_bcr))
+ return dev_err_probe(&pdev->dev, PTR_ERR(data->ssc_bcr),
+ "Failed to acquire reset: scc_bcr\n");
+
+ data->ssc_reset = devm_reset_control_get_exclusive(&pdev->dev, "ssc_reset");
+ if (IS_ERR(data->ssc_reset))
+ return dev_err_probe(&pdev->dev, PTR_ERR(data->ssc_reset),
+ "Failed to acquire reset: ssc_reset:\n");
+
+ // clocks
+ data->xo_clk = devm_clk_get(&pdev->dev, "xo");
+ if (IS_ERR(data->xo_clk))
+ return dev_err_probe(&pdev->dev, PTR_ERR(data->xo_clk),
+ "Failed to get clock: xo\n");
+
+ data->aggre2_clk = devm_clk_get(&pdev->dev, "aggre2");
+ if (IS_ERR(data->aggre2_clk))
+ return dev_err_probe(&pdev->dev, PTR_ERR(data->aggre2_clk),
+ "Failed to get clock: aggre2\n");
+
+ data->gcc_im_sleep_clk = devm_clk_get(&pdev->dev, "gcc_im_sleep");
+ if (IS_ERR(data->gcc_im_sleep_clk))
+ return dev_err_probe(&pdev->dev, PTR_ERR(data->gcc_im_sleep_clk),
+ "Failed to get clock: gcc_im_sleep\n");
+
+ data->aggre2_north_clk = devm_clk_get(&pdev->dev, "aggre2_north");
+ if (IS_ERR(data->aggre2_north_clk))
+ return dev_err_probe(&pdev->dev, PTR_ERR(data->aggre2_north_clk),
+ "Failed to get clock: aggre2_north\n");
+
+ data->ssc_xo_clk = devm_clk_get(&pdev->dev, "ssc_xo");
+ if (IS_ERR(data->ssc_xo_clk))
+ return dev_err_probe(&pdev->dev, PTR_ERR(data->ssc_xo_clk),
+ "Failed to get clock: ssc_xo\n");
+
+ data->ssc_ahbs_clk = devm_clk_get(&pdev->dev, "ssc_ahbs");
+ if (IS_ERR(data->ssc_ahbs_clk))
+ return dev_err_probe(&pdev->dev, PTR_ERR(data->ssc_ahbs_clk),
+ "Failed to get clock: ssc_ahbs\n");
+
+ ret = of_parse_phandle_with_fixed_args(pdev->dev.of_node, "qcom,halt-regs", 1, 0,
+ &halt_args);
+ if (ret < 0)
+ return dev_err_probe(&pdev->dev, ret, "Failed to parse qcom,halt-regs\n");
+
+ data->halt_map = syscon_node_to_regmap(halt_args.np);
+ of_node_put(halt_args.np);
+ if (IS_ERR(data->halt_map))
+ return PTR_ERR(data->halt_map);
+
+ data->ssc_axi_halt = halt_args.args[0];
+
+ qcom_ssc_block_bus_init(&pdev->dev);
+
+ of_platform_populate(np, NULL, NULL, &pdev->dev);
+
+ return 0;
+}
+
+static int qcom_ssc_block_bus_remove(struct platform_device *pdev)
+{
+ struct qcom_ssc_block_bus_data *data = platform_get_drvdata(pdev);
+
+ qcom_ssc_block_bus_deinit(&pdev->dev);
+
+ iounmap(data->reg_mpm_sscaon_config0);
+ iounmap(data->reg_mpm_sscaon_config1);
+
+ qcom_ssc_block_bus_pds_disable(data->pds, data->num_pds);
+ qcom_ssc_block_bus_pds_detach(&pdev->dev, data->pds, data->num_pds);
+ pm_runtime_disable(&pdev->dev);
+ pm_clk_destroy(&pdev->dev);
+
+ return 0;
+}
+
+static const struct of_device_id qcom_ssc_block_bus_of_match[] = {
+ { .compatible = "qcom,ssc-block-bus", },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, qcom_ssc_block_bus_of_match);
+
+static struct platform_driver qcom_ssc_block_bus_driver = {
+ .probe = qcom_ssc_block_bus_probe,
+ .remove = qcom_ssc_block_bus_remove,
+ .driver = {
+ .name = "qcom-ssc-block-bus",
+ .of_match_table = qcom_ssc_block_bus_of_match,
+ },
+};
+
+module_platform_driver(qcom_ssc_block_bus_driver);
+
+MODULE_DESCRIPTION("A driver for handling the init sequence needed for accessing the SSC block on (some) qcom SoCs over AHB");
+MODULE_AUTHOR("Michael Srba <Michael.Srba@seznam.cz>");
+MODULE_LICENSE("GPL v2");
--
2.34.1
^ permalink raw reply related
* [PATCH v4 1/5] dt-bindings: clock: gcc-msm8998: Add definitions of SSC-related clocks
From: michael.srba @ 2022-01-26 18:32 UTC (permalink / raw)
To: Andy Gross, Bjorn Andersson, Rob Herring, Stephen Boyd,
Philipp Zabel
Cc: Linus Walleij, Florian Fainelli, Arnd Bergmann,
Greg Kroah-Hartman, Saravana Kannan, linux-arm-msm, linux-clk,
devicetree, Michael Srba
From: Michael Srba <Michael.Srba@seznam.cz>
This patch adds definitions of four clocks which need to be manipulated
in order to initialize the AHB bus which exposes the SCC block in the
global address space.
Signed-off-by: Michael Srba <Michael.Srba@seznam.cz>
---
CHANGES:
- v2: none
- v3: none
- v4: none
---
include/dt-bindings/clock/qcom,gcc-msm8998.h | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/include/dt-bindings/clock/qcom,gcc-msm8998.h b/include/dt-bindings/clock/qcom,gcc-msm8998.h
index 72c99e486d86..1badb4f9c58f 100644
--- a/include/dt-bindings/clock/qcom,gcc-msm8998.h
+++ b/include/dt-bindings/clock/qcom,gcc-msm8998.h
@@ -186,6 +186,10 @@
#define UFS_UNIPRO_CORE_CLK_SRC 177
#define GCC_MMSS_GPLL0_CLK 178
#define HMSS_GPLL0_CLK_SRC 179
+#define GCC_IM_SLEEP 180
+#define AGGRE2_SNOC_NORTH_AXI 181
+#define SSC_XO 182
+#define SSC_CNOC_AHBS_CLK 183
#define PCIE_0_GDSC 0
#define UFS_GDSC 1
--
2.34.1
^ permalink raw reply related
* [PATCH v4 5/5] arm64: dts: qcom: msm8998: reserve potentially inaccessible clocks
From: michael.srba @ 2022-01-26 18:32 UTC (permalink / raw)
To: Andy Gross, Bjorn Andersson, Rob Herring, Stephen Boyd,
Philipp Zabel
Cc: Linus Walleij, Florian Fainelli, Arnd Bergmann,
Greg Kroah-Hartman, Saravana Kannan, linux-arm-msm, linux-clk,
devicetree, Michael Srba, Michael Srba
In-Reply-To: <20220126183250.11924-1-michael.srba@seznam.cz>
From: Michael Srba <michael.srba@seznam.cz>
With the gcc driver now being more complete and describing clocks which
might not always be write-accessible to the OS, conservatively specify
all such clocks as protected in the SoC dts.
The board dts - or even user-supplied dts - can override this property
to reflect the actual configuration.
Signed-off-by: Michael Srba <Michael.Srba@seznam.cz>
---
CHANGES:
- v2: add this patch
- v3: fix missing Signed-off-by
- v4: add a proper explanation as per review, (hopefully) fix the subject and commit message
---
arch/arm64/boot/dts/qcom/msm8998.dtsi | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/msm8998.dtsi b/arch/arm64/boot/dts/qcom/msm8998.dtsi
index f273bc1ff629..16dccf9d881e 100644
--- a/arch/arm64/boot/dts/qcom/msm8998.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8998.dtsi
@@ -863,6 +863,21 @@ gcc: clock-controller@100000 {
clock-names = "xo", "sleep_clk";
clocks = <&xo>, <&sleep_clk>;
+
+ /*
+ * The hypervisor typically configures the memory region where these clocks
+ * reside as read-only for the HLOS. If the HLOS tried to enable or disable
+ * these clocks on a device with such configuration (e.g. because they are
+ * enabled but unused during boot-up), the device will most likely decide
+ * to reboot.
+ * In light of that, we are conservative here and we list all such clocks
+ * as protected. The board dts (or a user-supplied dts) can override the
+ * list of protected clocks if it differs from the norm, and it is in fact
+ * desired for the HLOS to manage these clocks
+ */
+ protected-clocks = <AGGRE2_SNOC_NORTH_AXI>,
+ <SSC_XO>,
+ <SSC_CNOC_AHBS_CLK>;
};
rpm_msg_ram: sram@778000 {
--
2.34.1
^ permalink raw reply related
* [PATCH v4 2/5] clk: qcom: gcc-msm8998: add SSC-related clocks
From: michael.srba @ 2022-01-26 18:32 UTC (permalink / raw)
To: Andy Gross, Bjorn Andersson, Rob Herring, Stephen Boyd,
Philipp Zabel
Cc: Linus Walleij, Florian Fainelli, Arnd Bergmann,
Greg Kroah-Hartman, Saravana Kannan, linux-arm-msm, linux-clk,
devicetree, Michael Srba
In-Reply-To: <20220126183250.11924-1-michael.srba@seznam.cz>
From: Michael Srba <Michael.Srba@seznam.cz>
This patch adds four clocks which need to be manipulated in order to
initialize the AHB bus which exposes the SCC block in the global address
space.
If a device is known to be configured such that writing to these
registers from Linux is not permitted, the 'protected-clocks'
device tree property must be used to denote that fact.
Signed-off-by: Michael Srba <Michael.Srba@seznam.cz>
---
CHANGES:
- v2: none
- v3: none
- v4: reword the commit message
---
drivers/clk/qcom/gcc-msm8998.c | 56 ++++++++++++++++++++++++++++++++++
1 file changed, 56 insertions(+)
diff --git a/drivers/clk/qcom/gcc-msm8998.c b/drivers/clk/qcom/gcc-msm8998.c
index 407e2c5caea4..2d14c3d672fc 100644
--- a/drivers/clk/qcom/gcc-msm8998.c
+++ b/drivers/clk/qcom/gcc-msm8998.c
@@ -2833,6 +2833,58 @@ static struct clk_branch gcc_rx1_usb2_clkref_clk = {
},
};
+static struct clk_branch gcc_im_sleep_clk = {
+ .halt_reg = 0x4300C,
+ .halt_check = BRANCH_HALT,
+ .clkr = {
+ .enable_reg = 0x4300C,
+ .enable_mask = BIT(0),
+ .hw.init = &(struct clk_init_data){
+ .name = "gcc_im_sleep_clk",
+ .ops = &clk_branch2_ops,
+ },
+ },
+};
+
+static struct clk_branch aggre2_snoc_north_axi_clk = {
+ .halt_reg = 0x83010,
+ .halt_check = BRANCH_HALT,
+ .clkr = {
+ .enable_reg = 0x83010,
+ .enable_mask = BIT(0),
+ .hw.init = &(struct clk_init_data){
+ .name = "aggre2_snoc_north_axi_clk",
+ .ops = &clk_branch2_ops,
+ },
+ },
+};
+
+static struct clk_branch ssc_xo_clk = {
+ .halt_reg = 0x63018,
+ .halt_check = BRANCH_HALT,
+ .clkr = {
+ .enable_reg = 0x63018,
+ .enable_mask = BIT(0),
+ .hw.init = &(struct clk_init_data){
+ .name = "ssc_xo_clk",
+ .ops = &clk_branch2_ops,
+ },
+ },
+};
+
+static struct clk_branch ssc_cnoc_ahbs_clk = {
+ .halt_reg = 0x6300C,
+ .halt_check = BRANCH_HALT,
+ .clkr = {
+ .enable_reg = 0x6300C,
+ .enable_mask = BIT(0),
+ .hw.init = &(struct clk_init_data){
+ .name = "ssc_cnoc_ahbs_clk",
+ .ops = &clk_branch2_ops,
+ },
+ },
+};
+
static struct gdsc pcie_0_gdsc = {
.gdscr = 0x6b004,
.gds_hw_ctrl = 0x0,
@@ -3036,6 +3088,10 @@ static struct clk_regmap *gcc_msm8998_clocks[] = {
[GCC_MSS_MNOC_BIMC_AXI_CLK] = &gcc_mss_mnoc_bimc_axi_clk.clkr,
[GCC_MMSS_GPLL0_CLK] = &gcc_mmss_gpll0_clk.clkr,
[HMSS_GPLL0_CLK_SRC] = &hmss_gpll0_clk_src.clkr,
+ [GCC_IM_SLEEP] = &gcc_im_sleep_clk.clkr,
+ [AGGRE2_SNOC_NORTH_AXI] = &aggre2_snoc_north_axi_clk.clkr,
+ [SSC_XO] = &ssc_xo_clk.clkr,
+ [SSC_CNOC_AHBS_CLK] = &ssc_cnoc_ahbs_clk.clkr,
};
static struct gdsc *gcc_msm8998_gdscs[] = {
--
2.34.1
^ permalink raw reply related
* [PATCH v4 3/5] dt-bindings: bus: add device tree bindings for qcom,ssc-block-bus
From: michael.srba @ 2022-01-26 18:32 UTC (permalink / raw)
To: Andy Gross, Bjorn Andersson, Rob Herring, Stephen Boyd,
Philipp Zabel
Cc: Linus Walleij, Florian Fainelli, Arnd Bergmann,
Greg Kroah-Hartman, Saravana Kannan, linux-arm-msm, linux-clk,
devicetree, Michael Srba
In-Reply-To: <20220126183250.11924-1-michael.srba@seznam.cz>
From: Michael Srba <Michael.Srba@seznam.cz>
This patch adds bindings for the AHB bus which exposes the SCC block in
the global address space. This bus (and the SSC block itself) is present
on certain qcom SoCs.
In typical configuration, this bus (as some of the clocks and registers
that we need to manipulate) is not accessible to the OS, and the
resources on this bus are indirectly accessed by communicating with a
hexagon CPU core residing in the SSC block. In this configuration, the
hypervisor is the one performing the bus initialization for the purposes
of bringing the haxagon CPU core out of reset.
However, it is possible to change the configuration, in which case this
binding serves to allow the OS to initialize the bus.
Signed-off-by: Michael Srba <Michael.Srba@seznam.cz>
---
CHANGES:
- v2: fix issues caught by by dt-schema
- v3: none
- v4: address the issues pointed out in the review
---
.../bindings/bus/qcom,ssc-block-bus.yaml | 150 ++++++++++++++++++
1 file changed, 150 insertions(+)
create mode 100644 Documentation/devicetree/bindings/bus/qcom,ssc-block-bus.yaml
diff --git a/Documentation/devicetree/bindings/bus/qcom,ssc-block-bus.yaml b/Documentation/devicetree/bindings/bus/qcom,ssc-block-bus.yaml
new file mode 100644
index 000000000000..4bde169b1a19
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/qcom,ssc-block-bus.yaml
@@ -0,0 +1,150 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/bus/qcom,ssc-block-bus.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: The AHB Bus Providing a Global View of the SSC Block on (some) qcom SoCs
+
+maintainers:
+ - Michael Srba <Michael.Srba@seznam.cz>
+
+description: |
+ This binding describes the dependencies (clocks, resets, power domains) which
+ need to be turned on in a sequence before communication over the AHB bus
+ becomes possible.
+
+ Additionally, the reg property is used to pass to the driver the location of
+ two sadly undocumented registers which need to be poked as part of the sequence.
+
+properties:
+ compatible:
+ items:
+ - const: qcom,msm8998-ssc-block-bus
+ - const: qcom,ssc-block-bus
+
+ reg:
+ description: |
+ Shall contain the addresses of the SSCAON_CONFIG0 and SSCAON_CONFIG1
+ registers
+ minItems: 2
+ maxItems: 2
+
+ reg-names:
+ items:
+ - const: mpm_sscaon_config0
+ - const: mpm_sscaon_config1
+
+ '#address-cells':
+ enum: [ 1, 2 ]
+
+ '#size-cells':
+ enum: [ 1, 2 ]
+
+ ranges: true
+
+ clocks:
+ minItems: 6
+ maxItems: 6
+
+ clock-names:
+ items:
+ - const: xo
+ - const: aggre2
+ - const: gcc_im_sleep
+ - const: aggre2_north
+ - const: ssc_xo
+ - const: ssc_ahbs
+
+ power-domains:
+ description: Power domain phandles for the ssc_cx and ssc_mx power domains
+ minItems: 2
+ maxItems: 2
+
+ power-domain-names:
+ items:
+ - const: ssc_cx
+ - const: ssc_mx
+
+ resets:
+ description: |
+ Reset phandles for the ssc_reset and ssc_bcr resets (note: ssc_bcr is the
+ branch control register associated with the ssc_xo and ssc_ahbs clocks)
+ minItems: 2
+ maxItems: 2
+
+ reset-names:
+ items:
+ - const: ssc_reset
+ - const: ssc_bcr
+
+ qcom,halt-regs:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description: describes how to locate the ssc AXI halt register
+ items:
+ - items:
+ - description: Phandle reference to a syscon representing TCSR
+ - description: offset for the ssc AXI halt register
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - '#address-cells'
+ - '#size-cells'
+ - ranges
+ - clocks
+ - clock-names
+ - power-domains
+ - power-domain-names
+ - resets
+ - reset-names
+ - qcom,halt-regs
+
+additionalProperties: true
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,gcc-msm8998.h>
+ #include <dt-bindings/clock/qcom,rpmcc.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+
+ soc {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ // devices under this node are physically located in the SSC block, connected to an ssc-internal bus;
+ ssc_ahb_slave: bus@10ac008 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ compatible = "qcom,msm8998-ssc-block-bus", "qcom,ssc-block-bus";
+ reg = <0x10ac008 0x4>, <0x10ac010 0x4>;
+ reg-names = "mpm_sscaon_config0", "mpm_sscaon_config1";
+
+ clocks = <&xo>,
+ <&rpmcc RPM_SMD_AGGR2_NOC_CLK>,
+ <&gcc GCC_IM_SLEEP>,
+ <&gcc AGGRE2_SNOC_NORTH_AXI>,
+ <&gcc SSC_XO>,
+ <&gcc SSC_CNOC_AHBS_CLK>;
+ clock-names = "xo", "aggre2", "gcc_im_sleep", "aggre2_north", "ssc_xo", "ssc_ahbs";
+
+ resets = <&gcc GCC_SSC_RESET>, <&gcc GCC_SSC_BCR>;
+ reset-names = "ssc_reset", "ssc_bcr";
+
+ power-domains = <&rpmpd MSM8998_SSCCX>, <&rpmpd MSM8998_SSCMX>;
+ power-domain-names = "ssc_cx", "ssc_mx";
+
+ qcom,halt-regs = <&tcsr_mutex_regs 0x26000>;
+
+ ssc_tlmm: pinctrl@5e10000 {
+ compatible = "qcom,msm8998-ssc-tlmm-pinctrl";
+ reg = <0x5E10000 0x10000>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&ssc_tlmm 0 0 20>;
+ };
+ };
+ };
--
2.34.1
^ permalink raw reply related
* Re: [RFC PATCH v2 5/7] ARM: dts: bcm2711: Add unicam CSI nodes
From: Laurent Pinchart @ 2022-01-26 18:42 UTC (permalink / raw)
To: Dave Stevenson
Cc: Jean-Michel Hautbois, devicetree, kernel-list, linux-arm-kernel,
LKML, Linux Media Mailing List, linux-rpi-kernel, lukasz,
Mauro Carvalho Chehab, Naushir Patuck, robh, Tomi Valkeinen
In-Reply-To: <CAPY8ntDR5AsxGE5fh_KHMonoZait9evxQkpidu10F7EY9CPxZA@mail.gmail.com>
Hi Dave,
On Mon, Jan 24, 2022 at 12:31:34PM +0000, Dave Stevenson wrote:
> On Fri, 21 Jan 2022 at 22:45, Laurent Pinchart wrote:
> > On Fri, Jan 21, 2022 at 09:18:08AM +0100, Jean-Michel Hautbois wrote:
> > > Add both MIPI CSI-2 nodes in the core bcm2711 tree. Use the 3-cells
> > > interrupt declaration, corresponding clocks and default as disabled.
> > >
> > > Signed-off-by: Jean-Michel Hautbois <jeanmichel.hautbois@ideasonboard.com>
> > > ---
> > > arch/arm/boot/dts/bcm2711.dtsi | 31 +++++++++++++++++++++++++++++++
> > > 1 file changed, 31 insertions(+)
> > >
> > > diff --git a/arch/arm/boot/dts/bcm2711.dtsi b/arch/arm/boot/dts/bcm2711.dtsi
> > > index dff18fc9a906..077141df7024 100644
> > > --- a/arch/arm/boot/dts/bcm2711.dtsi
> > > +++ b/arch/arm/boot/dts/bcm2711.dtsi
> > > @@ -3,6 +3,7 @@
> > >
> > > #include <dt-bindings/interrupt-controller/arm-gic.h>
> > > #include <dt-bindings/soc/bcm2835-pm.h>
> > > +#include <dt-bindings/power/raspberrypi-power.h>
> > >
> > > / {
> > > compatible = "brcm,bcm2711";
> > > @@ -293,6 +294,36 @@ hvs: hvs@7e400000 {
> > > interrupts = <GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH>;
> > > };
> > >
> > > + csi0: csi1@7e800000 {
> >
> > The node name should be csi@7e800000, not csi1@7e800000. Now, this will
> > probably cause issues with the firmware that looks for csi1 (and csi0 ?)
> > to hand over control of the Unicam CSI-2 receiver to the kernel. I
> > wonder if this is something that could be handled by a firmware update,
> > to also recognize nodes named "csi" ?
>
> It already looks for any node starting "csi". If you check the
> downstream DT [1], then the nodes are "csi0: csi@7e800000" and "csi1:
> csi@7e801000".
Oops, indeed. I think I was misled by
https://github.com/raspberrypi/linux/blob/rpi-5.10.y/Documentation/devicetree/bindings/media/bcm2835-unicam.txt
that mentions "csi0" and "csi1".
It's all good then. Jean-Michel, can you update the DT bindings in the
next iteration of the series to correct the DT node naming ?
> There is no actual action required to hand the peripheral over to the
> kernel, it just prevents the firmware from using it and causing
> problems (it masks out the interrupt, and that's checked as part of
> the firmware initialising the peripheral).
>
> If using imx219 or one of the other sensors supported by the firmware,
> "vcgencmd get_camera" should report that the sensor isn't detected,
> and "sudo vcdbg log msg" should have a line similar to
> "020174.613: camsubs: Ignoring camera 0 as unicam device not available"
>
> Dave
>
> [1] https://github.com/raspberrypi/linux/blob/rpi-5.10.y/arch/arm/boot/dts/bcm270x.dtsi#L88
>
> > > + compatible = "brcm,bcm2835-unicam";
> > > + reg = <0x7e800000 0x800>,
> > > + <0x7e802000 0x4>;
> > > + interrupts = <GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>;
> > > + clocks = <&clocks BCM2835_CLOCK_CAM0>,
> > > + <&firmware_clocks 4>;
> > > + clock-names = "lp", "vpu";
> > > + power-domains = <&power RPI_POWER_DOMAIN_UNICAM0>;
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > + #clock-cells = <1>;
> >
> > Why do you need #address-cells, #size-cells and #clock-cells ? They're
> > not mentioned in the binding.
> >
> > > + status="disabled";
> >
> > Missing spaces around the =.
> >
> > Same comment for the next node.
> >
> > > + };
> > > +
> > > + csi1: csi1@7e801000 {
> > > + compatible = "brcm,bcm2835-unicam";
> > > + reg = <0x7e801000 0x800>,
> > > + <0x7e802004 0x4>;
> > > + interrupts = <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>;
> > > + clocks = <&clocks BCM2835_CLOCK_CAM1>,
> > > + <&firmware_clocks 4>;
> > > + clock-names = "lp", "vpu";
> > > + power-domains = <&power RPI_POWER_DOMAIN_UNICAM1>;
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > + #clock-cells = <1>;
> > > + status="disabled";
> > > + };
> > > +
> > > pixelvalve3: pixelvalve@7ec12000 {
> > > compatible = "brcm,bcm2711-pixelvalve3";
> > > reg = <0x7ec12000 0x100>;
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH 21/27] arm64: dts: rockchip: rk356x: Add HDMI nodes
From: Peter Geis @ 2022-01-26 18:44 UTC (permalink / raw)
To: Robin Murphy
Cc: Sascha Hauer, dri-devel, arm-mail-list,
open list:ARM/Rockchip SoC..., devicetree, kernel, Andy Yan,
Benjamin Gaignard, Michael Riesch, Sandy Huang,
Heiko Stübner
In-Reply-To: <a1438d39-b670-1ca5-d3f7-4e3f54702e53@arm.com>
On Wed, Jan 26, 2022 at 12:56 PM Robin Murphy <robin.murphy@arm.com> wrote:
>
> On 2022-01-26 16:04, Peter Geis wrote:
> > On Wed, Jan 26, 2022 at 9:58 AM Sascha Hauer <s.hauer@pengutronix.de> wrote:
> >>
> >> Add support for the HDMI port found on RK3568.
> >>
> >> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> >> ---
> >> arch/arm64/boot/dts/rockchip/rk356x.dtsi | 37 +++++++++++++++++++++++-
> >> 1 file changed, 36 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/arch/arm64/boot/dts/rockchip/rk356x.dtsi b/arch/arm64/boot/dts/rockchip/rk356x.dtsi
> >> index 4008bd666d01..e38fb223e9b8 100644
> >> --- a/arch/arm64/boot/dts/rockchip/rk356x.dtsi
> >> +++ b/arch/arm64/boot/dts/rockchip/rk356x.dtsi
> >> @@ -10,7 +10,6 @@
> >> #include <dt-bindings/pinctrl/rockchip.h>
> >> #include <dt-bindings/power/rk3568-power.h>
> >> #include <dt-bindings/soc/rockchip,boot-mode.h>
> >> -#include <dt-bindings/soc/rockchip,vop2.h>
> >> #include <dt-bindings/thermal/thermal.h>
> >>
> >> / {
> >> @@ -502,6 +501,42 @@ vop_mmu: iommu@fe043e00 {
> >> status = "disabled";
> >> };
> >>
> >> + hdmi: hdmi@fe0a0000 {
> >> + compatible = "rockchip,rk3568-dw-hdmi";
> >> + reg = <0x0 0xfe0a0000 0x0 0x20000>;
> >> + interrupts = <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>;
> >> + clocks = <&cru PCLK_HDMI_HOST>,
> >> + <&cru CLK_HDMI_SFR>,
> >> + <&cru CLK_HDMI_CEC>,
> >> + <&pmucru CLK_HDMI_REF>,
> >> + <&cru HCLK_VOP>;
> >> + clock-names = "iahb", "isfr", "cec", "ref", "hclk";
> >> + pinctrl-names = "default";
> >> + pinctrl-0 = <&hdmitx_scl &hdmitx_sda &hdmitxm0_cec>;
> >
> > I looked into CEC support here, and it seems that it does work with one change.
> > Please add the two following lines to your patch:
> > assigned-clocks = <&cru CLK_HDMI_CEC>;
> > assigned-clock-rates = <32768>;
> >
> > The issue is the clk_rtc32k_frac clock that feeds clk_rtc_32k which
> > feeds clk_hdmi_cec is 24mhz at boot, which is too high for CEC to
> > function.
>
> Wouldn't it make far more sense to just stick a suitable clk_set_rate()
> call in the driver? AFAICS it's already explicitly aware of the CEC clock.
This is handled purely in the
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c driver, so I'm hesitant to
touch it there as it would affect all users, not just Rockchip.
Could someone familiar with the dw-hdmi IP weigh in on the minimum and
maximum clock rate the CEC block can handle?
>
> Robin.
>
> >> + power-domains = <&power RK3568_PD_VO>;
> >> + reg-io-width = <4>;
> >> + rockchip,grf = <&grf>;
> >> + #sound-dai-cells = <0>;
> >> + status = "disabled";
> >> +
> >> + ports {
> >> + #address-cells = <1>;
> >> + #size-cells = <0>;
> >> +
> >> + hdmi_in: port@0 {
> >> + reg = <0>;
> >> + #address-cells = <1>;
> >> + #size-cells = <0>;
> >> + };
> >> +
> >> + hdmi_out: port@1 {
> >> + reg = <1>;
> >> + #address-cells = <1>;
> >> + #size-cells = <0>;
> >> + };
> >> + };
> >> + };
> >> +
> >> qos_gpu: qos@fe128000 {
> >> compatible = "rockchip,rk3568-qos", "syscon";
> >> reg = <0x0 0xfe128000 0x0 0x20>;
> >> --
> >> 2.30.2
> >>
> >
> > _______________________________________________
> > Linux-rockchip mailing list
> > Linux-rockchip@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: arm: xen: document Xen iommu device
From: Stefano Stabellini @ 2022-01-26 18:56 UTC (permalink / raw)
To: Robin Murphy
Cc: Sergiy Kibrik, Stefano Stabellini, Julien Grall,
Oleksandr Tyshchenko, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
xen-devel@lists.xenproject.org
In-Reply-To: <447f89ca-86c0-dc35-e7ac-e6639a573670@arm.com>
On Wed, 26 Jan 2022, Robin Murphy wrote:
> On 2022-01-26 15:09, Sergiy Kibrik wrote:
> > Hi Robin,
> >
> > >
> > > This could break Linux guests, since depending on the deferred probe
> > > timeout setting it could lead to drivers never probing because the "IOMMU"
> > > never becomes available.
> > >
> >
> > I've noticed no deferred probe timeouts when booting with this patch. Could
> > you please explain more on how this would break guests?
>
> Right now I think it would actually require command-line intervention, e.g.
> "fw_devlink=on" or "deferred_probe_timeout=3600" (with modules enabled for the
> latter to take full effect), but I'm wary of the potential for future config
> options to control those behaviours by default.
If deferred_probe_timeout=3600 was specified, we would just need an
IOMMU driver in Linux for the "xen,iommu-el2-v1" node to solve the
problem, right? I guess I am trying to say that it wouldn't be a device
tree interface problem but rather a Linux implementation discussion.
^ permalink raw reply
* Re: [PATCH v2 1/3] arm64: dts: renesas: Prepare AA1024XD12 panel .dtsi for overlay support
From: Laurent Pinchart @ 2022-01-26 18:58 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Linux-Renesas,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Rob Herring, Kieran Bingham, Geert Uytterhoeven, Magnus Damm,
Chris Paterson
In-Reply-To: <CAMuHMdWWRLdm+dAmso0dgf5QPqqV=txH-4Tryfm0USp7jZdbkw@mail.gmail.com>
Hi Geert,
On Wed, Jan 26, 2022 at 01:18:56PM +0100, Geert Uytterhoeven wrote:
> On Wed, Dec 29, 2021 at 8:31 PM Laurent Pinchart wrote:
> > The Mitsubishi AA1024XD12 panel can be used for R-Car Gen2 and Gen3
> > boards as an optional external panel. It is described in the
> > arm/boot/dts/r8a77xx-aa104xd12-panel.dtsi file as a direct child of the
> > DT root node. This allows including r8a77xx-aa104xd12-panel.dtsi in
> > board device trees, with other minor modifications, to enable the panel.
> >
> > This is however not how external components should be modelled. Instead
> > of modifying the board device tree to enable the panel, it should be
> > compiled as a DT overlay, to be loaded by the boot loader.
> >
> > Prepare the r8a77xx-aa104xd12-panel.dtsi file for this usage by
> > declaring a panel node only, without hardcoding its path. Overlay
> > sources can then include r8a77xx-aa104xd12-panel.dtsi where appropriate.
> >
> > This change doesn't cause any regression as r8a77xx-aa104xd12-panel.dtsi
> > is currently unused. As overlay support for this panel has only been
> > tested with Gen3 hardware, and Gen2 support will require more
> > development, move the file to arch/arm64/boot/dts/renesas/.
> >
> > Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
>
> Thanks for your patch!
>
> > --- a/arch/arm/boot/dts/r8a77xx-aa104xd12-panel.dtsi
>
> > - * Copyright (C) 2014 Renesas Electronics Corp.
>
> > +++ b/arch/arm64/boot/dts/renesas/panel-aa104xd12.dtsi
>
> > + * Copyright (C) 2021 Renesas Electronics Corp.
>
> Shouldn't you keep the year? Not much has changed.
Indeed.
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
I see you've reviewed the whole series. Can you pick it up ?
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v2 1/3] arm64: dts: renesas: Prepare AA1024XD12 panel .dtsi for overlay support
From: Geert Uytterhoeven @ 2022-01-26 19:15 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Linux-Renesas,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Rob Herring, Kieran Bingham, Geert Uytterhoeven, Magnus Damm,
Chris Paterson
In-Reply-To: <YfGZx9qHQdF8TzcT@pendragon.ideasonboard.com>
Hi Laurent,
On Wed, Jan 26, 2022 at 7:58 PM Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
> On Wed, Jan 26, 2022 at 01:18:56PM +0100, Geert Uytterhoeven wrote:
> > On Wed, Dec 29, 2021 at 8:31 PM Laurent Pinchart wrote:
> > > The Mitsubishi AA1024XD12 panel can be used for R-Car Gen2 and Gen3
> > > boards as an optional external panel. It is described in the
> > > arm/boot/dts/r8a77xx-aa104xd12-panel.dtsi file as a direct child of the
> > > DT root node. This allows including r8a77xx-aa104xd12-panel.dtsi in
> > > board device trees, with other minor modifications, to enable the panel.
> > >
> > > This is however not how external components should be modelled. Instead
> > > of modifying the board device tree to enable the panel, it should be
> > > compiled as a DT overlay, to be loaded by the boot loader.
> > >
> > > Prepare the r8a77xx-aa104xd12-panel.dtsi file for this usage by
> > > declaring a panel node only, without hardcoding its path. Overlay
> > > sources can then include r8a77xx-aa104xd12-panel.dtsi where appropriate.
> > >
> > > This change doesn't cause any regression as r8a77xx-aa104xd12-panel.dtsi
> > > is currently unused. As overlay support for this panel has only been
> > > tested with Gen3 hardware, and Gen2 support will require more
> > > development, move the file to arch/arm64/boot/dts/renesas/.
> > >
> > > Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> I see you've reviewed the whole series. Can you pick it up ?
I believe it depends on the removal of the empty endpoints, for which
we're waiting for feedback from Rob, IIRC?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 21/27] arm64: dts: rockchip: rk356x: Add HDMI nodes
From: Robin Murphy @ 2022-01-26 19:24 UTC (permalink / raw)
To: Peter Geis
Cc: Sascha Hauer, dri-devel, arm-mail-list,
open list:ARM/Rockchip SoC..., devicetree, kernel, Andy Yan,
Benjamin Gaignard, Michael Riesch, Sandy Huang,
Heiko Stübner
In-Reply-To: <CAMdYzYrcsj5Vas+ysoK6iD3uEAdmhcmLVi-5LY7hfHEtjeB6Cg@mail.gmail.com>
On 2022-01-26 18:44, Peter Geis wrote:
> On Wed, Jan 26, 2022 at 12:56 PM Robin Murphy <robin.murphy@arm.com> wrote:
>>
>> On 2022-01-26 16:04, Peter Geis wrote:
>>> On Wed, Jan 26, 2022 at 9:58 AM Sascha Hauer <s.hauer@pengutronix.de> wrote:
>>>>
>>>> Add support for the HDMI port found on RK3568.
>>>>
>>>> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
>>>> ---
>>>> arch/arm64/boot/dts/rockchip/rk356x.dtsi | 37 +++++++++++++++++++++++-
>>>> 1 file changed, 36 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/rockchip/rk356x.dtsi b/arch/arm64/boot/dts/rockchip/rk356x.dtsi
>>>> index 4008bd666d01..e38fb223e9b8 100644
>>>> --- a/arch/arm64/boot/dts/rockchip/rk356x.dtsi
>>>> +++ b/arch/arm64/boot/dts/rockchip/rk356x.dtsi
>>>> @@ -10,7 +10,6 @@
>>>> #include <dt-bindings/pinctrl/rockchip.h>
>>>> #include <dt-bindings/power/rk3568-power.h>
>>>> #include <dt-bindings/soc/rockchip,boot-mode.h>
>>>> -#include <dt-bindings/soc/rockchip,vop2.h>
>>>> #include <dt-bindings/thermal/thermal.h>
>>>>
>>>> / {
>>>> @@ -502,6 +501,42 @@ vop_mmu: iommu@fe043e00 {
>>>> status = "disabled";
>>>> };
>>>>
>>>> + hdmi: hdmi@fe0a0000 {
>>>> + compatible = "rockchip,rk3568-dw-hdmi";
>>>> + reg = <0x0 0xfe0a0000 0x0 0x20000>;
>>>> + interrupts = <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>;
>>>> + clocks = <&cru PCLK_HDMI_HOST>,
>>>> + <&cru CLK_HDMI_SFR>,
>>>> + <&cru CLK_HDMI_CEC>,
>>>> + <&pmucru CLK_HDMI_REF>,
>>>> + <&cru HCLK_VOP>;
>>>> + clock-names = "iahb", "isfr", "cec", "ref", "hclk";
>>>> + pinctrl-names = "default";
>>>> + pinctrl-0 = <&hdmitx_scl &hdmitx_sda &hdmitxm0_cec>;
>>>
>>> I looked into CEC support here, and it seems that it does work with one change.
>>> Please add the two following lines to your patch:
>>> assigned-clocks = <&cru CLK_HDMI_CEC>;
>>> assigned-clock-rates = <32768>;
>>>
>>> The issue is the clk_rtc32k_frac clock that feeds clk_rtc_32k which
>>> feeds clk_hdmi_cec is 24mhz at boot, which is too high for CEC to
>>> function.
>>
>> Wouldn't it make far more sense to just stick a suitable clk_set_rate()
>> call in the driver? AFAICS it's already explicitly aware of the CEC clock.
>
> This is handled purely in the
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c driver, so I'm hesitant to
> touch it there as it would affect all users, not just Rockchip.
I'd have a strong hunch that it's a standard thing for the DesignWare IP
and not affected by platform integration. I don't have the magical
Synopsys databook, but between the trusty old i.MX6 manual and most of
the other in-tree DTs getting their dw-hdmi "cec" clock from
suspiciously-obviously-named sources, I'd be somewhat surprised if it
was ever anything other than 32KHz.
Robin.
> Could someone familiar with the dw-hdmi IP weigh in on the minimum and
> maximum clock rate the CEC block can handle?
>
>>
>> Robin.
>>
>>>> + power-domains = <&power RK3568_PD_VO>;
>>>> + reg-io-width = <4>;
>>>> + rockchip,grf = <&grf>;
>>>> + #sound-dai-cells = <0>;
>>>> + status = "disabled";
>>>> +
>>>> + ports {
>>>> + #address-cells = <1>;
>>>> + #size-cells = <0>;
>>>> +
>>>> + hdmi_in: port@0 {
>>>> + reg = <0>;
>>>> + #address-cells = <1>;
>>>> + #size-cells = <0>;
>>>> + };
>>>> +
>>>> + hdmi_out: port@1 {
>>>> + reg = <1>;
>>>> + #address-cells = <1>;
>>>> + #size-cells = <0>;
>>>> + };
>>>> + };
>>>> + };
>>>> +
>>>> qos_gpu: qos@fe128000 {
>>>> compatible = "rockchip,rk3568-qos", "syscon";
>>>> reg = <0x0 0xfe128000 0x0 0x20>;
>>>> --
>>>> 2.30.2
>>>>
>>>
>>> _______________________________________________
>>> Linux-rockchip mailing list
>>> Linux-rockchip@lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply
* Re: [PATCH 1/1] of: unittest: rename overlay source files from .dts to .dtso
From: Rob Herring @ 2022-01-26 19:31 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Frank Rowand, David Gibson, Viresh Kumar, Masahiro Yamada,
Michal Marek, Vincent Guittot, Michal Simek, Anmar Oueja,
Bill Mills,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-kbuild, Linux Kernel Mailing List, Pantelis Antoniou
In-Reply-To: <CAMuHMdU4oUKaGxmaPiC=cX0XpHG3KXhr+4MywEfeQ8sq-EG18A@mail.gmail.com>
On Fri, Jan 14, 2022 at 3:25 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Rob,
>
> On Fri, Jan 14, 2022 at 3:10 AM Rob Herring <robh@kernel.org> wrote:
> > On Thu, Jan 6, 2022 at 11:23 AM Frank Rowand <frowand.list@gmail.com> wrote:
> > > Patient Geert has pinged again.
> >
> > If it's not a patch to be reviewed, then I'm not going to see it most
> > likely. I don't read the DT list regularly...
>
> Fair enough...
>
> > > If I remember correctly you guys were not thrilled with this idea, but
> > > also did not seem strongly against it. Are you willing to go along
> > > with .dtso for overlay source files? If so, I will revive this patch
> > > series.
> > >
> > > David, if you are against supporting .dtso in the dtc compiler then
> > > the kernel can still support it through make rules.
> >
> > I'm not really interested in diverging from dtc. I'd suggest moving
> > the discussion to dtc list and/or devicetree-spec if you want to get
> > more attention on this.
>
> What needs to be supported in the dtc compiler?
> The fallback passed to guess_input_format() is "dts".
> So this has been working out-of-the-box since forever?
Ah, okay.
> > Also, keep in mind that extensions also affect MIME types which
> > someone was also asking about recently.
>
> You mean "MIME type of Devicetree Blobs and Sources"[1]?
> According to [2](2022-01-13), none of that has happened.
This is what I was thinking of:
https://github.com/devicetree-org/devicetree-specification/issues/46
In any case, given everyone is ambivalent, send me an updated patch
and I'll apply it.
Rob
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: timer: sifive,clint: Fix number of interrupts
From: Rob Herring @ 2022-01-26 19:36 UTC (permalink / raw)
To: Anup Patel, Geert Uytterhoeven
Cc: Daniel Lezcano, Thomas Gleixner, Palmer Dabbelt, Paul Walmsley,
Anup Patel, linux-kernel@vger.kernel.org List, DTML, linux-riscv
In-Reply-To: <CAAhSdy3g9WsBmQk7KOgdVNSw9qUouxF2i==q9M3WQq3iabXv7Q@mail.gmail.com>
On Fri, Dec 17, 2021 at 6:48 AM Anup Patel <anup@brainfault.org> wrote:
>
> On Fri, Dec 17, 2021 at 6:08 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> >
> > The number of interrupts lacks an upper bound, thus assuming one,
> > causing properly grouped "interrupts-extended" properties to be flagged
> > as an error by "make dtbs_check".
> >
> > Fix this by adding the missing "maxItems". As the architectural maximum
> > is 4095 interrupts, using that as the limit would be unpractical. Hence
> > limit it to 10 interrupts (two interrupts for a system management core,
> > and two interrupts per core for other cores). This should be sufficient
> > for now, and the limit can always be increased when the need arises.
>
> Same comment as the PLIC DT binding patch.
>
> The "maxItems" should represent CLINT spec constraints so
> please don't add any synthetic value here.
I agree.
Geert, are you going to respin these?
Rob
^ permalink raw reply
* Re: [PATCH 21/27] arm64: dts: rockchip: rk356x: Add HDMI nodes
From: Peter Geis @ 2022-01-26 20:00 UTC (permalink / raw)
To: Robin Murphy
Cc: Sascha Hauer, dri-devel, arm-mail-list,
open list:ARM/Rockchip SoC..., devicetree, kernel, Andy Yan,
Benjamin Gaignard, Michael Riesch, Sandy Huang,
Heiko Stübner
In-Reply-To: <45132d1f-626d-5fe3-3118-21c0b3f4c8f1@arm.com>
On Wed, Jan 26, 2022 at 2:25 PM Robin Murphy <robin.murphy@arm.com> wrote:
>
> On 2022-01-26 18:44, Peter Geis wrote:
> > On Wed, Jan 26, 2022 at 12:56 PM Robin Murphy <robin.murphy@arm.com> wrote:
> >>
> >> On 2022-01-26 16:04, Peter Geis wrote:
> >>> On Wed, Jan 26, 2022 at 9:58 AM Sascha Hauer <s.hauer@pengutronix.de> wrote:
> >>>>
> >>>> Add support for the HDMI port found on RK3568.
> >>>>
> >>>> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> >>>> ---
> >>>> arch/arm64/boot/dts/rockchip/rk356x.dtsi | 37 +++++++++++++++++++++++-
> >>>> 1 file changed, 36 insertions(+), 1 deletion(-)
> >>>>
> >>>> diff --git a/arch/arm64/boot/dts/rockchip/rk356x.dtsi b/arch/arm64/boot/dts/rockchip/rk356x.dtsi
> >>>> index 4008bd666d01..e38fb223e9b8 100644
> >>>> --- a/arch/arm64/boot/dts/rockchip/rk356x.dtsi
> >>>> +++ b/arch/arm64/boot/dts/rockchip/rk356x.dtsi
> >>>> @@ -10,7 +10,6 @@
> >>>> #include <dt-bindings/pinctrl/rockchip.h>
> >>>> #include <dt-bindings/power/rk3568-power.h>
> >>>> #include <dt-bindings/soc/rockchip,boot-mode.h>
> >>>> -#include <dt-bindings/soc/rockchip,vop2.h>
> >>>> #include <dt-bindings/thermal/thermal.h>
> >>>>
> >>>> / {
> >>>> @@ -502,6 +501,42 @@ vop_mmu: iommu@fe043e00 {
> >>>> status = "disabled";
> >>>> };
> >>>>
> >>>> + hdmi: hdmi@fe0a0000 {
> >>>> + compatible = "rockchip,rk3568-dw-hdmi";
> >>>> + reg = <0x0 0xfe0a0000 0x0 0x20000>;
> >>>> + interrupts = <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>;
> >>>> + clocks = <&cru PCLK_HDMI_HOST>,
> >>>> + <&cru CLK_HDMI_SFR>,
> >>>> + <&cru CLK_HDMI_CEC>,
> >>>> + <&pmucru CLK_HDMI_REF>,
> >>>> + <&cru HCLK_VOP>;
> >>>> + clock-names = "iahb", "isfr", "cec", "ref", "hclk";
> >>>> + pinctrl-names = "default";
> >>>> + pinctrl-0 = <&hdmitx_scl &hdmitx_sda &hdmitxm0_cec>;
> >>>
> >>> I looked into CEC support here, and it seems that it does work with one change.
> >>> Please add the two following lines to your patch:
> >>> assigned-clocks = <&cru CLK_HDMI_CEC>;
> >>> assigned-clock-rates = <32768>;
> >>>
> >>> The issue is the clk_rtc32k_frac clock that feeds clk_rtc_32k which
> >>> feeds clk_hdmi_cec is 24mhz at boot, which is too high for CEC to
> >>> function.
> >>
> >> Wouldn't it make far more sense to just stick a suitable clk_set_rate()
> >> call in the driver? AFAICS it's already explicitly aware of the CEC clock.
> >
> > This is handled purely in the
> > drivers/gpu/drm/bridge/synopsys/dw-hdmi.c driver, so I'm hesitant to
> > touch it there as it would affect all users, not just Rockchip.
>
> I'd have a strong hunch that it's a standard thing for the DesignWare IP
> and not affected by platform integration. I don't have the magical
> Synopsys databook, but between the trusty old i.MX6 manual and most of
> the other in-tree DTs getting their dw-hdmi "cec" clock from
> suspiciously-obviously-named sources, I'd be somewhat surprised if it
> was ever anything other than 32KHz.
My main concern was similar to the other HDMI clock issues, mainly
setting the clock can propagate up and affect other users of the
upstream clock.
I'll spin up a quick patch for this method.
Thanks,
Peter
>
> Robin.
>
> > Could someone familiar with the dw-hdmi IP weigh in on the minimum and
> > maximum clock rate the CEC block can handle?
> >
> >>
> >> Robin.
> >>
> >>>> + power-domains = <&power RK3568_PD_VO>;
> >>>> + reg-io-width = <4>;
> >>>> + rockchip,grf = <&grf>;
> >>>> + #sound-dai-cells = <0>;
> >>>> + status = "disabled";
> >>>> +
> >>>> + ports {
> >>>> + #address-cells = <1>;
> >>>> + #size-cells = <0>;
> >>>> +
> >>>> + hdmi_in: port@0 {
> >>>> + reg = <0>;
> >>>> + #address-cells = <1>;
> >>>> + #size-cells = <0>;
> >>>> + };
> >>>> +
> >>>> + hdmi_out: port@1 {
> >>>> + reg = <1>;
> >>>> + #address-cells = <1>;
> >>>> + #size-cells = <0>;
> >>>> + };
> >>>> + };
> >>>> + };
> >>>> +
> >>>> qos_gpu: qos@fe128000 {
> >>>> compatible = "rockchip,rk3568-qos", "syscon";
> >>>> reg = <0x0 0xfe128000 0x0 0x20>;
> >>>> --
> >>>> 2.30.2
> >>>>
> >>>
> >>> _______________________________________________
> >>> Linux-rockchip mailing list
> >>> Linux-rockchip@lists.infradead.org
> >>> http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply
* [PATCH] dt-bindings: hwmon: gpio-fan: convert to YAML
From: Corentin Labbe @ 2022-01-26 20:03 UTC (permalink / raw)
To: jdelvare, linux, robh+dt
Cc: devicetree, linux-hwmon, linux-kernel, Corentin Labbe
Converts hwmon/gpio-fan.txt to YAML
Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
---
I didnt found any clear maintainer and since DT yaml mandates a
maintainer section, I set devicetree@vger.kernel.org.
.../devicetree/bindings/hwmon/gpio-fan.txt | 41 --------
.../devicetree/bindings/hwmon/gpio-fan.yaml | 96 +++++++++++++++++++
2 files changed, 96 insertions(+), 41 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/hwmon/gpio-fan.txt
create mode 100644 Documentation/devicetree/bindings/hwmon/gpio-fan.yaml
diff --git a/Documentation/devicetree/bindings/hwmon/gpio-fan.txt b/Documentation/devicetree/bindings/hwmon/gpio-fan.txt
deleted file mode 100644
index f4cfa350f6a1..000000000000
--- a/Documentation/devicetree/bindings/hwmon/gpio-fan.txt
+++ /dev/null
@@ -1,41 +0,0 @@
-Bindings for fan connected to GPIO lines
-
-Required properties:
-- compatible : "gpio-fan"
-
-Optional properties:
-- gpios: Specifies the pins that map to bits in the control value,
- ordered MSB-->LSB.
-- gpio-fan,speed-map: A mapping of possible fan RPM speeds and the
- control value that should be set to achieve them. This array
- must have the RPM values in ascending order.
-- alarm-gpios: This pin going active indicates something is wrong with
- the fan, and a udev event will be fired.
-- #cooling-cells: If used as a cooling device, must be <2>
- Also see:
- Documentation/devicetree/bindings/thermal/thermal-cooling-devices.yaml
- min and max states are derived from the speed-map of the fan.
-
-Note: At least one the "gpios" or "alarm-gpios" properties must be set.
-
-Examples:
-
- gpio_fan {
- compatible = "gpio-fan";
- gpios = <&gpio1 14 1
- &gpio1 13 1>;
- gpio-fan,speed-map = <0 0
- 3000 1
- 6000 2>;
- alarm-gpios = <&gpio1 15 1>;
- };
- gpio_fan_cool: gpio_fan {
- compatible = "gpio-fan";
- gpios = <&gpio2 14 1
- &gpio2 13 1>;
- gpio-fan,speed-map = <0 0>,
- <3000 1>,
- <6000 2>;
- alarm-gpios = <&gpio2 15 1>;
- #cooling-cells = <2>; /* min followed by max */
- };
diff --git a/Documentation/devicetree/bindings/hwmon/gpio-fan.yaml b/Documentation/devicetree/bindings/hwmon/gpio-fan.yaml
new file mode 100644
index 000000000000..15bb5efd3cb4
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/gpio-fan.yaml
@@ -0,0 +1,96 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/gpio-fan.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Bindings for fan connected to GPIO lines
+
+maintainers:
+ - OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS <devicetree@vger.kernel.org>
+
+properties:
+ compatible:
+ const: gpio-fan
+
+ gpios:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description: Specifies the pins that map to bits in the control value,
+ ordered MSB-->LSB.
+
+ gpio-fan,speed-map:
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ description: A mapping of possible fan RPM speeds and the
+ control value that should be set to achieve them. This array
+ must have the RPM values in ascending order.
+
+ alarm-gpios:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description: This pin going active indicates something is wrong with
+ the fan, and a udev event will be fired.
+
+ "#cooling-cells":
+ const: 2
+ description: If used as a cooling device, must be <2>
+ Also see Documentation/devicetree/bindings/thermal/thermal-cooling-devices.yaml
+ min and max states are derived from the speed-map of the fan.
+
+anyOf:
+ - required:
+ - gpios
+ - required:
+ - alarm-gpios
+
+additionalProperties: False
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/clock/cortina,gemini-clock.h>
+ #include <dt-bindings/reset/cortina,gemini-reset.h>
+ #include <dt-bindings/gpio/gpio.h>
+ gpio1: gpio@4d000000 {
+ compatible = "cortina,gemini-gpio", "faraday,ftgpio010";
+ reg = <0x4d000000 0x100>;
+ interrupts = <22 IRQ_TYPE_LEVEL_HIGH>;
+ resets = <&syscon GEMINI_RESET_GPIO0>;
+ clocks = <&syscon GEMINI_CLK_APB>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+ gpio_fan {
+ compatible = "gpio-fan";
+ gpios = <&gpio1 8 GPIO_ACTIVE_HIGH>;
+ gpio-fan,speed-map = <0 0>,
+ <3000 1>,
+ <6000 2>;
+ alarm-gpios = <&gpio1 15 GPIO_ACTIVE_HIGH>;
+ };
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/clock/cortina,gemini-clock.h>
+ #include <dt-bindings/reset/cortina,gemini-reset.h>
+ #include <dt-bindings/gpio/gpio.h>
+ gpio2: gpio@4d000000 {
+ compatible = "cortina,gemini-gpio", "faraday,ftgpio010";
+ reg = <0x4d000000 0x100>;
+ interrupts = <22 IRQ_TYPE_LEVEL_HIGH>;
+ resets = <&syscon GEMINI_RESET_GPIO0>;
+ clocks = <&syscon GEMINI_CLK_APB>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+ gpio_fan_cool: gpio_fan {
+ compatible = "gpio-fan";
+ gpios = <&gpio2 8 GPIO_ACTIVE_HIGH
+ &gpio2 1 GPIO_ACTIVE_HIGH>;
+ gpio-fan,speed-map = <0 0
+ 3000 1
+ 6000 2>;
+ alarm-gpios = <&gpio2 15 GPIO_ACTIVE_HIGH>;
+ #cooling-cells = <2>; /* min followed by max */
+ };
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v6 2/2] misc: open-dice: Add driver to expose DICE data to userspace
From: David Brazdil @ 2022-01-26 20:05 UTC (permalink / raw)
To: Wedson Almeida Filho
Cc: Greg Kroah-Hartman, Rob Herring, Arnd Bergmann, Frank Rowand,
Will Deacon, Andrew Scull, devicetree, linux-kernel, Rob Herring
In-Reply-To: <Yd4Tl2FoKnwziN8K@google.com>
Hi Wedson,
Sorry for the late reply, and thanks for the in-depth review.
On Tue, Jan 11, 2022 at 11:32:39PM +0000, Wedson Almeida Filho wrote:
> Hey David,
>
> Following up here on v6.
>
> On Tue, Jan 04, 2022 at 10:06:45AM +0000, David Brazdil wrote:
> > Open Profile for DICE is an open protocol for measured boot compatible
> > with the Trusted Computing Group's Device Identifier Composition
> > Engine (DICE) specification. The generated Compound Device Identifier
> > (CDI) certificates represent the hardware/software combination measured
> > by DICE, and can be used for remote attestation and sealing.
> >
> > Add a driver that exposes reserved memory regions populated by firmware
> > with DICE CDIs and exposes them to userspace via a character device.
> >
> > Userspace obtains the memory region's size from read() and calls mmap()
> > to create a mapping of the memory region in its address space. The
> > mapping is not allowed to be write+shared, giving userspace a guarantee
> > that the data were not overwritten by another process.
> >
> > Userspace can also call write(), which triggers a wipe of the DICE data
> > by the driver. Because both the kernel and userspace mappings use
> > write-combine semantics, all clients observe the memory as zeroed after
> > the syscall has returned.
> >
> > Acked-by: Rob Herring <robh@kernel.org>
> > Cc: Andrew Scull <ascull@google.com>
> > Cc: Will Deacon <will@kernel.org>
> > Signed-off-by: David Brazdil <dbrazdil@google.com>
> > ---
> > drivers/misc/Kconfig | 12 +++
> > drivers/misc/Makefile | 1 +
> > drivers/misc/open-dice.c | 188 +++++++++++++++++++++++++++++++++++++++
> > drivers/of/platform.c | 1 +
> > 4 files changed, 202 insertions(+)
> > create mode 100644 drivers/misc/open-dice.c
> >
> > diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> > index 0f5a49fc7c9e..a2b26426efba 100644
> > --- a/drivers/misc/Kconfig
> > +++ b/drivers/misc/Kconfig
> > @@ -470,6 +470,18 @@ config HISI_HIKEY_USB
> > switching between the dual-role USB-C port and the USB-A host ports
> > using only one USB controller.
> >
> > +config OPEN_DICE
> > + tristate "Open Profile for DICE driver"
> > + depends on OF_RESERVED_MEM
> > + help
> > + This driver exposes a DICE reserved memory region to userspace via
> > + a character device. The memory region contains Compound Device
> > + Identifiers (CDIs) generated by firmware as an output of DICE
> > + measured boot flow. Userspace can use CDIs for remote attestation
> > + and sealing.
> > +
> > + If unsure, say N.
> > +
> > source "drivers/misc/c2port/Kconfig"
> > source "drivers/misc/eeprom/Kconfig"
> > source "drivers/misc/cb710/Kconfig"
> > diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
> > index a086197af544..70e800e9127f 100644
> > --- a/drivers/misc/Makefile
> > +++ b/drivers/misc/Makefile
> > @@ -59,3 +59,4 @@ obj-$(CONFIG_UACCE) += uacce/
> > obj-$(CONFIG_XILINX_SDFEC) += xilinx_sdfec.o
> > obj-$(CONFIG_HISI_HIKEY_USB) += hisi_hikey_usb.o
> > obj-$(CONFIG_HI6421V600_IRQ) += hi6421v600-irq.o
> > +obj-$(CONFIG_OPEN_DICE) += open-dice.o
> > diff --git a/drivers/misc/open-dice.c b/drivers/misc/open-dice.c
> > new file mode 100644
> > index 000000000000..f1819f951173
> > --- /dev/null
> > +++ b/drivers/misc/open-dice.c
> > @@ -0,0 +1,188 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * Copyright (C) 2021 - Google LLC
> > + * Author: David Brazdil <dbrazdil@google.com>
> > + *
> > + * Driver for Open Profile for DICE.
> > + *
> > + * This driver takes ownership of a reserved memory region containing data
> > + * generated by the Open Profile for DICE measured boot protocol. The memory
> > + * contents are not interpreted by the kernel but can be mapped into a userspace
> > + * process via a misc device. Userspace can also request a wipe of the memory.
> > + *
> > + * Userspace can access the data with (w/o error handling):
> > + *
> > + * fd = open("/dev/open-dice0", O_RDWR);
> > + * read(fd, &size, sizeof(unsigned long));
> > + * data = mmap(NULL, size, PROT_READ, MAP_PRIVATE, fd, 0);
> > + * write(fd, NULL, 0); // wipe
> > + * close(fd);
> > + */
> > +
> > +#include <linux/io.h>
> > +#include <linux/miscdevice.h>
> > +#include <linux/mm.h>
> > +#include <linux/module.h>
> > +#include <linux/of_reserved_mem.h>
> > +#include <linux/platform_device.h>
> > +
> > +#define DRIVER_NAME "open-dice"
> > +
> > +struct open_dice_drvdata {
> > + spinlock_t lock;
> > + char name[16];
> > + struct reserved_mem *rmem;
> > + struct miscdevice misc;
> > +};
> > +
> > +static inline struct open_dice_drvdata *to_open_dice_drvdata(struct file *filp)
> > +{
> > + return container_of(filp->private_data, struct open_dice_drvdata, misc);
> > +}
> > +
> > +static int open_dice_wipe(struct open_dice_drvdata *drvdata)
> > +{
> > + void *kaddr;
> > +
> > + spin_lock(&drvdata->lock);
> > + kaddr = devm_memremap(drvdata->misc.this_device, drvdata->rmem->base,
> > + drvdata->rmem->size, MEMREMAP_WC);
>
> What's the plan here if devm_memremap sleeps while you're holding the spinlock?
Good catch. devm_memremap can indeed sleep. I'll convert the lock to a mutex.
> > + if (IS_ERR(kaddr)) {
> > + spin_unlock(&drvdata->lock);
> > + return PTR_ERR(kaddr);
> > + }
> > +
> > + memset(kaddr, 0, drvdata->rmem->size);
> > + devm_memunmap(drvdata->misc.this_device, kaddr);
> > + spin_unlock(&drvdata->lock);
> > + return 0;
> > +}
> > +
> > +/*
> > + * Copies the size of the reserved memory region to the user-provided buffer.
> > + */
> > +static ssize_t open_dice_read(struct file *filp, char __user *ptr, size_t len,
> > + loff_t *off)
> > +{
> > + unsigned long val = to_open_dice_drvdata(filp)->rmem->size;
> > +
> > + return simple_read_from_buffer(ptr, len, off, &val, sizeof(val));
> > +}
> > +
> > +/*
> > + * Triggers a wipe of the reserved memory region. The user-provided pointer
> > + * is never dereferenced.
> > + */
> > +static ssize_t open_dice_write(struct file *filp, const char __user *ptr,
> > + size_t len, loff_t *off)
> > +{
> > + if (open_dice_wipe(to_open_dice_drvdata(filp)))
> > + return -EIO;
> > +
> > + /* Consume the input buffer. */
> > + return len;
> > +}
> > +
> > +/*
> > + * Creates a mapping of the reserved memory region in user address space.
> > + */
> > +static int open_dice_mmap(struct file *filp, struct vm_area_struct *vma)
> > +{
> > + struct open_dice_drvdata *drvdata = to_open_dice_drvdata(filp);
> > +
> > + /* Do not allow userspace to modify the underlying data. */
> > + if ((vma->vm_flags & VM_WRITE) && (vma->vm_flags & VM_SHARED))
> > + return -EPERM;
> > +
> > + /* Create write-combine mapping so all clients observe a wipe. */
> > + vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);
> > + vma->vm_flags |= VM_DONTCOPY | VM_DONTDUMP;
>
> I think we need to clear VM_MAYWRITE here too, otherwise what prevents a user
> (that opened the file for write as well) from later adding VM_WRITE to the vma
> by calling mprotect?
Indeed. WRITE^SHARED is not an issue, but we need to make sure they are
never combined. And as you point out, mprotect or mremap can change the
flags later. I'll address this in v7. Thanks.
> > + return vm_iomap_memory(vma, drvdata->rmem->base, drvdata->rmem->size);
> > +}
> > +
> > +static const struct file_operations open_dice_fops = {
> > + .owner = THIS_MODULE,
> > + .read = open_dice_read,
> > + .write = open_dice_write,
> > + .mmap = open_dice_mmap,
> > +};
> > +
> > +static int __init open_dice_probe(struct platform_device *pdev)
> > +{
> > + static unsigned int dev_idx;
> > + struct device *dev = &pdev->dev;
> > + struct reserved_mem *rmem;
> > + struct open_dice_drvdata *drvdata;
> > + int ret;
> > +
> > + rmem = of_reserved_mem_lookup(dev->of_node);
> > + if (!rmem) {
> > + dev_err(dev, "failed to lookup reserved memory\n");
> > + return -EINVAL;
> > + }
> > +
> > + if (!rmem->size || (rmem->size > ULONG_MAX)) {
> > + dev_err(dev, "invalid memory region size\n");
> > + return -EINVAL;
> > + }
> > +
> > + if (!PAGE_ALIGNED(rmem->base) || !PAGE_ALIGNED(rmem->size)) {
> > + dev_err(dev, "memory region must be page-aligned\n");
> > + return -EINVAL;
> > + }
> > +
> > + drvdata = devm_kmalloc(dev, sizeof(*drvdata), GFP_KERNEL);
> > + if (!drvdata)
> > + return -ENOMEM;
> > +
> > + *drvdata = (struct open_dice_drvdata){
> > + .lock = __SPIN_LOCK_UNLOCKED(drvdata->lock),
> > + .rmem = rmem,
> > + .misc = (struct miscdevice){
> > + .parent = dev,
> > + .name = drvdata->name,
> > + .minor = MISC_DYNAMIC_MINOR,
> > + .fops = &open_dice_fops,
> > + .mode = 0600,
> > + },
> > + };
> > +
> > + /* Index overflow check not needed, misc_register() will fail. */
> > + snprintf(drvdata->name, sizeof(drvdata->name), DRIVER_NAME"%u", dev_idx++);
> > +
> > + ret = misc_register(&drvdata->misc);
> > + if (ret) {
> > + dev_err(dev, "failed to register misc device '%s': %d\n",
> > + drvdata->name, ret);
> > + return ret;
> > + }
> > +
> > + platform_set_drvdata(pdev, drvdata);
> > + return 0;
> > +}
> > +
> > +static int open_dice_remove(struct platform_device *pdev)
> > +{
>
> As we discussed before, this should never be called, right? If it does, users
> can trigger UAF. Should we call BUG or WARN here?
Not quite. This can be legitimately called when the refcount drops to
zero (ie. all FDs are closed). There is a config that allows this to be
called even with active FDs but that operation will taint the kernel.
So no BUG or WARN here.
David
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: timer: sifive,clint: Fix number of interrupts
From: Geert Uytterhoeven @ 2022-01-26 20:06 UTC (permalink / raw)
To: Rob Herring
Cc: Anup Patel, Daniel Lezcano, Thomas Gleixner, Palmer Dabbelt,
Paul Walmsley, Anup Patel, linux-kernel@vger.kernel.org List,
DTML, linux-riscv
In-Reply-To: <CAL_Jsq++-Sp45vna5-WhPsnrxp1_J1krrBUPgd2y3xkp5=sTSw@mail.gmail.com>
Hi Rob,
On Wed, Jan 26, 2022 at 8:37 PM Rob Herring <robh+dt@kernel.org> wrote:
> On Fri, Dec 17, 2021 at 6:48 AM Anup Patel <anup@brainfault.org> wrote:
> > On Fri, Dec 17, 2021 at 6:08 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > > The number of interrupts lacks an upper bound, thus assuming one,
> > > causing properly grouped "interrupts-extended" properties to be flagged
> > > as an error by "make dtbs_check".
> > >
> > > Fix this by adding the missing "maxItems". As the architectural maximum
> > > is 4095 interrupts, using that as the limit would be unpractical. Hence
> > > limit it to 10 interrupts (two interrupts for a system management core,
> > > and two interrupts per core for other cores). This should be sufficient
> > > for now, and the limit can always be increased when the need arises.
> >
> > Same comment as the PLIC DT binding patch.
> >
> > The "maxItems" should represent CLINT spec constraints so
> > please don't add any synthetic value here.
>
> I agree.
>
> Geert, are you going to respin these?
Sure, will do, now we have an agreement.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v3 11/12] misc: fastrpc: Add dma handle implementation
From: kernel test robot @ 2022-01-26 20:13 UTC (permalink / raw)
To: Srinivas Kandagatla, robh+dt, gregkh
Cc: llvm, kbuild-all, devicetree, ekangupt, bkumar, linux-kernel,
srini, bjorn.andersson, linux-arm-msm, Vamsi Krishna Gattupalli
In-Reply-To: <20220126135304.16340-12-srinivas.kandagatla@linaro.org>
Hi Srinivas,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on char-misc/char-misc-testing]
[also build test WARNING on robh/for-next linux/master linus/master v5.17-rc1 next-20220125]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url: https://github.com/0day-ci/linux/commits/Srinivas-Kandagatla/misc-fastrpc-Add-missing-DSP-FastRPC-features/20220126-215705
base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git 515a2f507491e7c3818e74ef4f4e088c1fecb190
config: hexagon-randconfig-r041-20220124 (https://download.01.org/0day-ci/archive/20220127/202201270440.GvskN5kg-lkp@intel.com/config)
compiler: clang version 14.0.0 (https://github.com/llvm/llvm-project 2a1b7aa016c0f4b5598806205bdfbab1ea2d92c4)
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# https://github.com/0day-ci/linux/commit/70d5973b9373ab26b6a1ed520ee07b71c7bdba63
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review Srinivas-Kandagatla/misc-fastrpc-Add-missing-DSP-FastRPC-features/20220126-215705
git checkout 70d5973b9373ab26b6a1ed520ee07b71c7bdba63
# save the config file to linux build tree
mkdir build_dir
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=hexagon SHELL=/bin/bash drivers/misc/
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All warnings (new ones prefixed by >>):
>> drivers/misc/fastrpc.c:1862:13: warning: stack frame size (1256) exceeds limit (1024) in 'fastrpc_device_ioctl' [-Wframe-larger-than]
static long fastrpc_device_ioctl(struct file *file, unsigned int cmd,
^
1 warning generated.
vim +/fastrpc_device_ioctl +1862 drivers/misc/fastrpc.c
b1c0b7969aa4918 Jeya R 2022-01-26 1861
c68cfb718c8f97b Srinivas Kandagatla 2019-02-08 @1862 static long fastrpc_device_ioctl(struct file *file, unsigned int cmd,
c68cfb718c8f97b Srinivas Kandagatla 2019-02-08 1863 unsigned long arg)
c68cfb718c8f97b Srinivas Kandagatla 2019-02-08 1864 {
c68cfb718c8f97b Srinivas Kandagatla 2019-02-08 1865 struct fastrpc_user *fl = (struct fastrpc_user *)file->private_data;
c68cfb718c8f97b Srinivas Kandagatla 2019-02-08 1866 char __user *argp = (char __user *)arg;
c68cfb718c8f97b Srinivas Kandagatla 2019-02-08 1867 int err;
c68cfb718c8f97b Srinivas Kandagatla 2019-02-08 1868
c68cfb718c8f97b Srinivas Kandagatla 2019-02-08 1869 switch (cmd) {
c68cfb718c8f97b Srinivas Kandagatla 2019-02-08 1870 case FASTRPC_IOCTL_INVOKE:
c68cfb718c8f97b Srinivas Kandagatla 2019-02-08 1871 err = fastrpc_invoke(fl, argp);
c68cfb718c8f97b Srinivas Kandagatla 2019-02-08 1872 break;
d73f71c7c6ee158 Srinivas Kandagatla 2019-02-08 1873 case FASTRPC_IOCTL_INIT_ATTACH:
6010d9befc8df89 Jonathan Marek 2020-09-08 1874 err = fastrpc_init_attach(fl, AUDIO_PD);
6010d9befc8df89 Jonathan Marek 2020-09-08 1875 break;
6010d9befc8df89 Jonathan Marek 2020-09-08 1876 case FASTRPC_IOCTL_INIT_ATTACH_SNS:
6010d9befc8df89 Jonathan Marek 2020-09-08 1877 err = fastrpc_init_attach(fl, SENSORS_PD);
d73f71c7c6ee158 Srinivas Kandagatla 2019-02-08 1878 break;
d73f71c7c6ee158 Srinivas Kandagatla 2019-02-08 1879 case FASTRPC_IOCTL_INIT_CREATE:
d73f71c7c6ee158 Srinivas Kandagatla 2019-02-08 1880 err = fastrpc_init_create_process(fl, argp);
d73f71c7c6ee158 Srinivas Kandagatla 2019-02-08 1881 break;
6cffd79504ce040 Srinivas Kandagatla 2019-02-08 1882 case FASTRPC_IOCTL_ALLOC_DMA_BUFF:
6cffd79504ce040 Srinivas Kandagatla 2019-02-08 1883 err = fastrpc_dmabuf_alloc(fl, argp);
6cffd79504ce040 Srinivas Kandagatla 2019-02-08 1884 break;
2419e55e532de14 Jorge Ramirez-Ortiz 2019-10-09 1885 case FASTRPC_IOCTL_MMAP:
2419e55e532de14 Jorge Ramirez-Ortiz 2019-10-09 1886 err = fastrpc_req_mmap(fl, argp);
2419e55e532de14 Jorge Ramirez-Ortiz 2019-10-09 1887 break;
2419e55e532de14 Jorge Ramirez-Ortiz 2019-10-09 1888 case FASTRPC_IOCTL_MUNMAP:
2419e55e532de14 Jorge Ramirez-Ortiz 2019-10-09 1889 err = fastrpc_req_munmap(fl, argp);
2419e55e532de14 Jorge Ramirez-Ortiz 2019-10-09 1890 break;
b1c0b7969aa4918 Jeya R 2022-01-26 1891 case FASTRPC_IOCTL_MEM_MAP:
b1c0b7969aa4918 Jeya R 2022-01-26 1892 err = fastrpc_req_mem_map(fl, argp);
b1c0b7969aa4918 Jeya R 2022-01-26 1893 break;
b1c0b7969aa4918 Jeya R 2022-01-26 1894 case FASTRPC_IOCTL_MEM_UNMAP:
b1c0b7969aa4918 Jeya R 2022-01-26 1895 err = fastrpc_req_mem_unmap(fl, argp);
b1c0b7969aa4918 Jeya R 2022-01-26 1896 break;
a22465bb4904fac Jeya R 2022-01-26 1897 case FASTRPC_IOCTL_GET_DSP_INFO:
a22465bb4904fac Jeya R 2022-01-26 1898 err = fastrpc_get_dsp_info(fl, argp);
a22465bb4904fac Jeya R 2022-01-26 1899 break;
c68cfb718c8f97b Srinivas Kandagatla 2019-02-08 1900 default:
c68cfb718c8f97b Srinivas Kandagatla 2019-02-08 1901 err = -ENOTTY;
c68cfb718c8f97b Srinivas Kandagatla 2019-02-08 1902 break;
c68cfb718c8f97b Srinivas Kandagatla 2019-02-08 1903 }
c68cfb718c8f97b Srinivas Kandagatla 2019-02-08 1904
c68cfb718c8f97b Srinivas Kandagatla 2019-02-08 1905 return err;
c68cfb718c8f97b Srinivas Kandagatla 2019-02-08 1906 }
c68cfb718c8f97b Srinivas Kandagatla 2019-02-08 1907
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* Re: [PATCH v3 11/12] misc: fastrpc: Add dma handle implementation
From: kernel test robot @ 2022-01-26 20:14 UTC (permalink / raw)
To: Srinivas Kandagatla, robh+dt, gregkh
Cc: kbuild-all, devicetree, ekangupt, bkumar, linux-kernel, srini,
bjorn.andersson, linux-arm-msm, Vamsi Krishna Gattupalli
In-Reply-To: <20220126135304.16340-12-srinivas.kandagatla@linaro.org>
Hi Srinivas,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on char-misc/char-misc-testing]
[also build test WARNING on robh/for-next linux/master linus/master v5.17-rc1 next-20220125]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url: https://github.com/0day-ci/linux/commits/Srinivas-Kandagatla/misc-fastrpc-Add-missing-DSP-FastRPC-features/20220126-215705
base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git 515a2f507491e7c3818e74ef4f4e088c1fecb190
config: arc-randconfig-r003-20220126 (https://download.01.org/0day-ci/archive/20220127/202201270412.QDMYUTEr-lkp@intel.com/config)
compiler: arc-elf-gcc (GCC) 11.2.0
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# https://github.com/0day-ci/linux/commit/70d5973b9373ab26b6a1ed520ee07b71c7bdba63
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review Srinivas-Kandagatla/misc-fastrpc-Add-missing-DSP-FastRPC-features/20220126-215705
git checkout 70d5973b9373ab26b6a1ed520ee07b71c7bdba63
# save the config file to linux build tree
mkdir build_dir
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross O=build_dir ARCH=arc SHELL=/bin/bash drivers/misc/
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All warnings (new ones prefixed by >>):
drivers/misc/fastrpc.c: In function 'fastrpc_req_mem_unmap_impl':
drivers/misc/fastrpc.c:1761:23: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
1761 | args[0].ptr = (u64) &req_msg;
| ^
drivers/misc/fastrpc.c: In function 'fastrpc_req_mem_map':
drivers/misc/fastrpc.c:1811:19: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
1811 | map->va = (void *) req.vaddrin;
| ^
drivers/misc/fastrpc.c:1816:23: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
1816 | args[0].ptr = (u64) &req_msg;
| ^
drivers/misc/fastrpc.c:1822:23: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
1822 | args[1].ptr = (u64) &pages;
| ^
drivers/misc/fastrpc.c:1825:23: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
1825 | args[2].ptr = (u64) &pages;
| ^
drivers/misc/fastrpc.c:1828:23: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
1828 | args[3].ptr = (u64) &rsp_msg;
| ^
drivers/misc/fastrpc.c: In function 'fastrpc_get_info_from_kernel.constprop':
>> drivers/misc/fastrpc.c:1552:1: warning: the frame size of 1076 bytes is larger than 1024 bytes [-Wframe-larger-than=]
1552 | }
| ^
vim +1552 drivers/misc/fastrpc.c
a22465bb4904fac Jeya R 2022-01-26 1515
a22465bb4904fac Jeya R 2022-01-26 1516 static int fastrpc_get_info_from_kernel(struct fastrpc_ioctl_capability *cap,
a22465bb4904fac Jeya R 2022-01-26 1517 struct fastrpc_user *fl)
a22465bb4904fac Jeya R 2022-01-26 1518 {
a22465bb4904fac Jeya R 2022-01-26 1519 struct fastrpc_channel_ctx *cctx = fl->cctx;
a22465bb4904fac Jeya R 2022-01-26 1520 uint32_t attribute_id = cap->attribute_id;
a22465bb4904fac Jeya R 2022-01-26 1521 uint32_t dsp_attributes[FASTRPC_MAX_DSP_ATTRIBUTES];
a22465bb4904fac Jeya R 2022-01-26 1522 unsigned long flags;
a22465bb4904fac Jeya R 2022-01-26 1523 uint32_t domain = cap->domain;
a22465bb4904fac Jeya R 2022-01-26 1524 int err;
a22465bb4904fac Jeya R 2022-01-26 1525
a22465bb4904fac Jeya R 2022-01-26 1526 spin_lock_irqsave(&cctx->lock, flags);
a22465bb4904fac Jeya R 2022-01-26 1527 /* check if we already have queried dsp for attributes */
a22465bb4904fac Jeya R 2022-01-26 1528 if (cctx->valid_attributes) {
a22465bb4904fac Jeya R 2022-01-26 1529 spin_unlock_irqrestore(&cctx->lock, flags);
a22465bb4904fac Jeya R 2022-01-26 1530 goto done;
a22465bb4904fac Jeya R 2022-01-26 1531 }
a22465bb4904fac Jeya R 2022-01-26 1532 spin_unlock_irqrestore(&cctx->lock, flags);
a22465bb4904fac Jeya R 2022-01-26 1533
a22465bb4904fac Jeya R 2022-01-26 1534 err = fastrpc_get_info_from_dsp(fl, &dsp_attributes[0], FASTRPC_MAX_DSP_ATTRIBUTES);
a22465bb4904fac Jeya R 2022-01-26 1535 if (err == DSP_UNSUPPORTED_API) {
a22465bb4904fac Jeya R 2022-01-26 1536 dev_info(&cctx->rpdev->dev,
a22465bb4904fac Jeya R 2022-01-26 1537 "Warning: DSP capabilities not supported on domain: %d\n", domain);
a22465bb4904fac Jeya R 2022-01-26 1538 return -EOPNOTSUPP;
a22465bb4904fac Jeya R 2022-01-26 1539 } else if (err) {
a22465bb4904fac Jeya R 2022-01-26 1540 dev_err(&cctx->rpdev->dev, "Error: dsp information is incorrect err: %d\n", err);
a22465bb4904fac Jeya R 2022-01-26 1541 return err;
a22465bb4904fac Jeya R 2022-01-26 1542 }
a22465bb4904fac Jeya R 2022-01-26 1543
a22465bb4904fac Jeya R 2022-01-26 1544 spin_lock_irqsave(&cctx->lock, flags);
a22465bb4904fac Jeya R 2022-01-26 1545 memcpy(cctx->dsp_attributes, dsp_attributes, sizeof(u32) * FASTRPC_MAX_DSP_ATTRIBUTES);
a22465bb4904fac Jeya R 2022-01-26 1546 cctx->valid_attributes = true;
a22465bb4904fac Jeya R 2022-01-26 1547 spin_unlock_irqrestore(&cctx->lock, flags);
a22465bb4904fac Jeya R 2022-01-26 1548 done:
a22465bb4904fac Jeya R 2022-01-26 1549 cap->capability = cctx->dsp_attributes[attribute_id];
a22465bb4904fac Jeya R 2022-01-26 1550
a22465bb4904fac Jeya R 2022-01-26 1551 return 0;
a22465bb4904fac Jeya R 2022-01-26 @1552 }
a22465bb4904fac Jeya R 2022-01-26 1553
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox