Linaro-mm-sig June 2024

linaro-mm-sig@lists.linaro.org

26 participants
62 discussions

Re: [PATCH 3/9] dt-bindings: mailbox: rockchip,rknn: Add bindings

by Rob Herring

On Wed, Jun 12, 2024 at 03:52:56PM +0200, Tomeu Vizoso wrote: > Add the bindings for the Neural Processing Unit IP from Rockchip. Subject is wrong. Not a mailbox... > Signed-off-by: Tomeu Vizoso <tomeu(a)tomeuvizoso.net> > --- > .../devicetree/bindings/npu/rockchip,rknn.yaml | 123 +++++++++++++++++++++ > 1 file changed, 123 insertions(+) > > diff --git a/Documentation/devicetree/bindings/npu/rockchip,rknn.yaml b/Documentation/devicetree/bindings/npu/rockchip,rknn.yaml > new file mode 100644 > index 000000000000..570a4889c11c > --- /dev/null > +++ b/Documentation/devicetree/bindings/npu/rockchip,rknn.yaml > @@ -0,0 +1,123 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/npu/rockchip,rknn.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Neural Processing Unit IP from Rockchip, based on NVIDIA's NVDLA > + > +maintainers: > + - Tomeu Vizoso <tomeu(a)tomeuvizoso.net> > + > +description: |+ > + Rockchip IP for accelerating inference of neural networks, based on NVIDIA's open source NVDLA IP. Wrap at 80. > + > +properties: > + compatible: > + items: > + - enum: > + - rockchip,rk3588-rknn > + - const: rockchip,rknn Is there any evidence this block is 'the same' on multiple chips? > + > + reg: > + description: Base registers for NPU cores > + minItems: 1 > + maxItems: 20 > + > + interrupts: > + minItems: 1 > + maxItems: 20 > + > + interrupt-names: > + minItems: 1 > + maxItems: 20 > + > + clocks: > + minItems: 1 > + maxItems: 20 > + > + clock-names: > + minItems: 1 > + maxItems: 20 > + > + assigned-clocks: > + maxItems: 1 > + > + assigned-clock-rates: > + maxItems: 1 You don't need assigned-clocks in schemas. > + > + resets: > + minItems: 1 > + maxItems: 20 > + > + reset-names: > + minItems: 1 > + maxItems: 20 > + > + power-domains: > + minItems: 1 > + maxItems: 20 > + > + power-domain-names: > + minItems: 1 > + maxItems: 20 > + > + iommus: > + items: > + - description: IOMMU for all cores > + > +required: > + - compatible > + - reg > + - interrupts > + - interrupt-names > + - clocks > + - clock-names > + - assigned-clocks > + - assigned-clock-rates And never should be required. > + - resets > + - reset-names > + - power-domains > + - power-domain-names > + - iommus > + > +additionalProperties: false > + > +examples: > + - | > + #include <dt-bindings/interrupt-controller/arm-gic.h> > + > + bus { > + #address-cells = <2>; > + #size-cells = <2>; > + > + rknn: npu@fdab0000 { > + compatible = "rockchip,rk3588-rknn", "rockchip,rknn"; > + reg = <0x0 0xfdab0000 0x0 0x9000>, > + <0x0 0xfdac0000 0x0 0x9000>, > + <0x0 0xfdad0000 0x0 0x9000>; > + interrupts = <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH 0>, > + <GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH 0>, > + <GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH 0>; > + interrupt-names = "npu0_irq", "npu1_irq", "npu2_irq"; 'irq' is redundant. Names with the index are also kind of pointless unless they can be not contiguous. > + clocks = <&scmi_clk 0>, <&cru 1>, > + <&cru 2>, <&cru 3>, > + <&cru 4>, <&cru 5>, > + <&cru 6>, <&cru 7>; > + clock-names = "clk_npu", 'clk_' is redundant. > + "aclk0", "aclk1", "aclk2", > + "hclk0", "hclk1", "hclk2", > + "pclk"; Assuming 0, 1, 2 are cores and may vary, put all the fixed clocks first and then better to do "aclk0", "hclk0", "aclk1", "hclk1",... > + assigned-clocks = <&scmi_clk 0>; > + assigned-clock-rates = <200000000>; > + resets = <&cru 0>, <&cru 1>, <&cru 2>, > + <&cru 3>, <&cru 4>, <&cru 5>; > + reset-names = "srst_a0", "srst_a1", "srst_a2", > + "srst_h0", "srst_h1", "srst_h2"; And similar order here. > + power-domains = <&power 0>, <&power 1>, <&power 2>; > + power-domain-names = "npu0", "npu1", "npu2"; > + iommus = <&rknpu_mmu>; > + status = "disabled"; > + }; > + }; > +... > > -- > 2.45.2 >

4 months, 1 week

Re: [PATCH 0/9] New DRM accel driver for Rockchip's RKNN NPU

by Rob Herring (Arm)

On Wed, 12 Jun 2024 15:52:53 +0200, Tomeu Vizoso wrote: > This series adds a new driver for the NPU that Rockchip includes in its > newer SoCs, developed by them on the NVDLA base. > > In its current form, it supports the specific NPU in the RK3588 SoC. > > The userspace driver is part of Mesa and an initial draft can be found at: > > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29698 > > Signed-off-by: Tomeu Vizoso <tomeu(a)tomeuvizoso.net> > --- > Tomeu Vizoso (9): > iommu/rockchip: Add compatible for rockchip,rk3588-iommu > iommu/rockchip: Attach multiple power domains > dt-bindings: mailbox: rockchip,rknn: Add bindings > arm64: dts: rockchip: Add nodes for NPU and its MMU to rk3588s > arm64: dts: rockchip: Enable the NPU on quartzpro64 > accel/rocket: Add a new driver for Rockchip's NPU > accel/rocket: Add IOCTL for BO creation > accel/rocket: Add job submission IOCTL > accel/rocket: Add IOCTLs for synchronizing memory accesses > > .../devicetree/bindings/npu/rockchip,rknn.yaml | 123 + > MAINTAINERS | 8 + > .../arm64/boot/dts/rockchip/rk3588-quartzpro64.dts | 8 + > arch/arm64/boot/dts/rockchip/rk3588s.dtsi | 53 + > drivers/accel/Kconfig | 1 + > drivers/accel/Makefile | 1 + > drivers/accel/rocket/Kconfig | 13 + > drivers/accel/rocket/Makefile | 10 + > drivers/accel/rocket/rocket_core.c | 155 + > drivers/accel/rocket/rocket_core.h | 48 + > drivers/accel/rocket/rocket_device.c | 39 + > drivers/accel/rocket/rocket_device.h | 40 + > drivers/accel/rocket/rocket_drv.c | 243 ++ > drivers/accel/rocket/rocket_drv.h | 16 + > drivers/accel/rocket/rocket_gem.c | 136 + > drivers/accel/rocket/rocket_gem.h | 33 + > drivers/accel/rocket/rocket_job.c | 708 ++++ > drivers/accel/rocket/rocket_job.h | 49 + > drivers/accel/rocket/rocket_registers.h | 4449 ++++++++++++++++++++ > drivers/iommu/rockchip-iommu.c | 39 + > include/uapi/drm/rocket_accel.h | 116 + > 21 files changed, 6288 insertions(+) > --- > base-commit: 83a7eefedc9b56fe7bfeff13b6c7356688ffa670 > change-id: 20240612-6-10-rocket-9316defc14c7 > > Best regards, > -- > Tomeu Vizoso <tomeu(a)tomeuvizoso.net> > > > My bot found new DTB warnings on the .dts files added or changed in this series. Some warnings may be from an existing SoC .dtsi. Or perhaps the warnings are fixed by another series. Ultimately, it is up to the platform maintainer whether these warnings are acceptable or not. No need to reply unless the platform maintainer has comments. If you already ran DT checks and didn't see these error(s), then make sure dt-schema is up to date: pip3 install dtschema --upgrade New warnings running 'make CHECK_DTBS=y rockchip/rk3588-quartzpro64.dtb' for 20240612-6-10-rocket-v1-0-060e48eea250(a)tomeuvizoso.net: arch/arm64/boot/dts/rockchip/rk3588-quartzpro64.dtb: iommu@fdab9000: compatible: 'oneOf' conditional failed, one must be fixed: ['rockchip,rk3588-iommu'] is too short 'rockchip,rk3588-iommu' is not one of ['rockchip,iommu', 'rockchip,rk3568-iommu'] from schema $id: http://devicetree.org/schemas/iommu/rockchip,iommu.yaml# arch/arm64/boot/dts/rockchip/rk3588-quartzpro64.dtb: iommu@fdab9000: reg: [[0, 4255879168, 0, 256], [0, 4255883264, 0, 256], [0, 4255948800, 0, 256], [0, 4256014336, 0, 256]] is too long from schema $id: http://devicetree.org/schemas/iommu/rockchip,iommu.yaml# arch/arm64/boot/dts/rockchip/rk3588-quartzpro64.dtb: iommu@fdab9000: interrupts: [[0, 110, 4, 0], [0, 111, 4, 0], [0, 112, 4, 0]] is too long from schema $id: http://devicetree.org/schemas/iommu/rockchip,iommu.yaml# arch/arm64/boot/dts/rockchip/rk3588-quartzpro64.dtb: iommu@fdab9000: clocks: [[28, 287], [28, 276], [28, 278], [28, 288], [28, 277], [28, 279]] is too long from schema $id: http://devicetree.org/schemas/iommu/rockchip,iommu.yaml# arch/arm64/boot/dts/rockchip/rk3588-quartzpro64.dtb: iommu@fdab9000: clock-names:0: 'aclk' was expected from schema $id: http://devicetree.org/schemas/iommu/rockchip,iommu.yaml# arch/arm64/boot/dts/rockchip/rk3588-quartzpro64.dtb: iommu@fdab9000: clock-names:1: 'iface' was expected from schema $id: http://devicetree.org/schemas/iommu/rockchip,iommu.yaml# arch/arm64/boot/dts/rockchip/rk3588-quartzpro64.dtb: iommu@fdab9000: clock-names: ['aclk0', 'aclk1', 'aclk2', 'iface0', 'iface1', 'iface2'] is too long from schema $id: http://devicetree.org/schemas/iommu/rockchip,iommu.yaml# arch/arm64/boot/dts/rockchip/rk3588-quartzpro64.dtb: iommu@fdab9000: power-domains: [[30, 9], [30, 10], [30, 11]] is too long from schema $id: http://devicetree.org/schemas/iommu/rockchip,iommu.yaml# arch/arm64/boot/dts/rockchip/rk3588-quartzpro64.dtb: iommu@fdab9000: 'interrupt-names', 'power-domain-names' do not match any of the regexes: 'pinctrl-[0-9]+' from schema $id: http://devicetree.org/schemas/iommu/rockchip,iommu.yaml#

4 months, 1 week

Re: [PATCH 6/9] accel/rocket: Add a new driver for Rockchip's NPU

by kernel test robot

4 months, 1 week

Re: [PATCH 8/9] accel/rocket: Add job submission IOCTL

by kernel test robot

Hi Tomeu, kernel test robot noticed the following build warnings: [auto build test WARNING on 83a7eefedc9b56fe7bfeff13b6c7356688ffa670] url: https://github.com/intel-lab-lkp/linux/commits/Tomeu-Vizoso/iommu-rockchip-… base: 83a7eefedc9b56fe7bfeff13b6c7356688ffa670 patch link: https://lore.kernel.org/r/20240612-6-10-rocket-v1-8-060e48eea250%40tomeuviz… patch subject: [PATCH 8/9] accel/rocket: Add job submission IOCTL config: hexagon-allmodconfig (https://download.01.org/0day-ci/archive/20240613/202406131640.WbBaRMbr-lkp@…) compiler: clang version 19.0.0git (https://github.com/llvm/llvm-project 4403cdbaf01379de96f8d0d6ea4f51a085e37766) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240613/202406131640.WbBaRMbr-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202406131640.WbBaRMbr-lkp@intel.com/ All warnings (new ones prefixed by >>): In file included from drivers/accel/rocket/rocket_job.c:6: In file included from include/drm/drm_file.h:39: In file included from include/drm/drm_prime.h:37: In file included from include/linux/scatterlist.h:8: In file included from include/linux/mm.h:2253: include/linux/vmstat.h:514:36: warning: arithmetic between different enumeration types ('enum node_stat_item' and 'enum lru_list') [-Wenum-enum-conversion] 514 | return node_stat_name(NR_LRU_BASE + lru) + 3; // skip "nr_" | ~~~~~~~~~~~ ^ ~~~ In file included from drivers/accel/rocket/rocket_job.c:6: In file included from include/drm/drm_file.h:39: In file included from include/drm/drm_prime.h:37: In file included from include/linux/scatterlist.h:9: In file included from arch/hexagon/include/asm/io.h:328: include/asm-generic/io.h:548:31: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] 548 | val = __raw_readb(PCI_IOBASE + addr); | ~~~~~~~~~~ ^ include/asm-generic/io.h:561:61: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] 561 | val = __le16_to_cpu((__le16 __force)__raw_readw(PCI_IOBASE + addr)); | ~~~~~~~~~~ ^ include/uapi/linux/byteorder/little_endian.h:37:51: note: expanded from macro '__le16_to_cpu' 37 | #define __le16_to_cpu(x) ((__force __u16)(__le16)(x)) | ^ In file included from drivers/accel/rocket/rocket_job.c:6: In file included from include/drm/drm_file.h:39: In file included from include/drm/drm_prime.h:37: In file included from include/linux/scatterlist.h:9: In file included from arch/hexagon/include/asm/io.h:328: include/asm-generic/io.h:574:61: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] 574 | val = __le32_to_cpu((__le32 __force)__raw_readl(PCI_IOBASE + addr)); | ~~~~~~~~~~ ^ include/uapi/linux/byteorder/little_endian.h:35:51: note: expanded from macro '__le32_to_cpu' 35 | #define __le32_to_cpu(x) ((__force __u32)(__le32)(x)) | ^ In file included from drivers/accel/rocket/rocket_job.c:6: In file included from include/drm/drm_file.h:39: In file included from include/drm/drm_prime.h:37: In file included from include/linux/scatterlist.h:9: In file included from arch/hexagon/include/asm/io.h:328: include/asm-generic/io.h:585:33: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] 585 | __raw_writeb(value, PCI_IOBASE + addr); | ~~~~~~~~~~ ^ include/asm-generic/io.h:595:59: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] 595 | __raw_writew((u16 __force)cpu_to_le16(value), PCI_IOBASE + addr); | ~~~~~~~~~~ ^ include/asm-generic/io.h:605:59: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] 605 | __raw_writel((u32 __force)cpu_to_le32(value), PCI_IOBASE + addr); | ~~~~~~~~~~ ^ >> drivers/accel/rocket/rocket_job.c:353:11: warning: variable 'status' set but not used [-Wunused-but-set-variable] 353 | uint32_t status, raw_status; | ^ >> drivers/accel/rocket/rocket_job.c:353:19: warning: variable 'raw_status' set but not used [-Wunused-but-set-variable] 353 | uint32_t status, raw_status; | ^ drivers/accel/rocket/rocket_job.c:40:1: warning: unused function 'to_rocket_fence' [-Wunused-function] 40 | to_rocket_fence(struct dma_fence *fence) | ^~~~~~~~~~~~~~~ 10 warnings generated. Kconfig warnings: (for reference only) WARNING: unmet direct dependencies detected for IOMMU_IO_PGTABLE_LPAE Depends on [n]: IOMMU_SUPPORT [=y] && (ARM || ARM64 || COMPILE_TEST [=y]) && !GENERIC_ATOMIC64 [=y] Selected by [m]: - DRM_ACCEL_ROCKET [=m] && DRM [=m] && (ARM64 || COMPILE_TEST [=y]) && MMU [=y] vim +/status +353 drivers/accel/rocket/rocket_job.c 350 351 static void rocket_job_handle_irq(struct rocket_core *core) 352 { > 353 uint32_t status, raw_status; 354 355 pm_runtime_mark_last_busy(core->dev->dev); 356 357 status = rocket_read(core, REG_PC_INTERRUPT_STATUS); 358 raw_status = rocket_read(core, REG_PC_INTERRUPT_RAW_STATUS); 359 360 rocket_write(core, REG_PC_OPERATION_ENABLE, 0x0); 361 rocket_write(core, REG_PC_INTERRUPT_CLEAR, 0x1ffff); 362 363 spin_lock(&core->job_lock); 364 365 if (core->in_flight_job) 366 rocket_job_handle_done(core, core->in_flight_job); 367 368 spin_unlock(&core->job_lock); 369 } 370 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

4 months, 1 week

Re: [PATCH 6/9] accel/rocket: Add a new driver for Rockchip's NPU

by kernel test robot

Hi Tomeu, kernel test robot noticed the following build errors: [auto build test ERROR on 83a7eefedc9b56fe7bfeff13b6c7356688ffa670] url: https://github.com/intel-lab-lkp/linux/commits/Tomeu-Vizoso/iommu-rockchip-… base: 83a7eefedc9b56fe7bfeff13b6c7356688ffa670 patch link: https://lore.kernel.org/r/20240612-6-10-rocket-v1-6-060e48eea250%40tomeuviz… patch subject: [PATCH 6/9] accel/rocket: Add a new driver for Rockchip's NPU config: s390-allyesconfig (https://download.01.org/0day-ci/archive/20240613/202406131022.1JKNS7me-lkp@…) compiler: s390-linux-gcc (GCC) 13.2.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240613/202406131022.1JKNS7me-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202406131022.1JKNS7me-lkp@intel.com/ All errors (new ones prefixed by >>): In file included from include/linux/clk.h:13, from drivers/accel/rocket/rocket_drv.c:4: >> drivers/accel/rocket/rocket_drv.c:213:31: error: 'rocket_pm_ops' undeclared here (not in a function); did you mean 'rocket_probe'? 213 | .pm = pm_ptr(&rocket_pm_ops), | ^~~~~~~~~~~~~ include/linux/kernel.h:48:44: note: in definition of macro 'PTR_IF' 48 | #define PTR_IF(cond, ptr) ((cond) ? (ptr) : NULL) | ^~~ drivers/accel/rocket/rocket_drv.c:213:23: note: in expansion of macro 'pm_ptr' 213 | .pm = pm_ptr(&rocket_pm_ops), | ^~~~~~ vim +213 drivers/accel/rocket/rocket_drv.c 207 208 static struct platform_driver rocket_driver = { 209 .probe = rocket_probe, 210 .remove_new = rocket_remove, 211 .driver = { 212 .name = "rocket", > 213 .pm = pm_ptr(&rocket_pm_ops), 214 .of_match_table = dt_match, 215 }, 216 }; 217 module_platform_driver(rocket_driver); 218 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

4 months, 1 week

Re: [PATCH 6/9] accel/rocket: Add a new driver for Rockchip's NPU

by kernel test robot

Hi Tomeu, kernel test robot noticed the following build errors: [auto build test ERROR on 83a7eefedc9b56fe7bfeff13b6c7356688ffa670] url: https://github.com/intel-lab-lkp/linux/commits/Tomeu-Vizoso/iommu-rockchip-… base: 83a7eefedc9b56fe7bfeff13b6c7356688ffa670 patch link: https://lore.kernel.org/r/20240612-6-10-rocket-v1-6-060e48eea250%40tomeuviz… patch subject: [PATCH 6/9] accel/rocket: Add a new driver for Rockchip's NPU config: loongarch-allmodconfig (https://download.01.org/0day-ci/archive/20240613/202406130901.oiofrkFe-lkp@…) compiler: loongarch64-linux-gcc (GCC) 13.2.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240613/202406130901.oiofrkFe-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202406130901.oiofrkFe-lkp@intel.com/ All errors (new ones prefixed by >>): In file included from arch/loongarch/include/asm/processor.h:17, from arch/loongarch/include/asm/thread_info.h:15, from include/linux/thread_info.h:60, from include/asm-generic/current.h:6, from ./arch/loongarch/include/generated/asm/current.h:1, from include/linux/mutex.h:14, from include/linux/notifier.h:14, from include/linux/clk.h:14, from drivers/accel/rocket/rocket_core.c:6: >> arch/loongarch/include/uapi/asm/ptrace.h:25:25: error: expected identifier before '(' token 25 | #define PC (GPR_END + 2) | ^ drivers/accel/rocket/rocket_registers.h:53:9: note: in expansion of macro 'PC' 53 | PC = 0x00000100, | ^~ vim +25 arch/loongarch/include/uapi/asm/ptrace.h 803b0fc5c3f2ba Huacai Chen 2022-05-31 16 803b0fc5c3f2ba Huacai Chen 2022-05-31 17 /* 803b0fc5c3f2ba Huacai Chen 2022-05-31 18 * For PTRACE_{POKE,PEEK}USR. 0 - 31 are GPRs, 803b0fc5c3f2ba Huacai Chen 2022-05-31 19 * 32 is syscall's original ARG0, 33 is PC, 34 is BADVADDR. 803b0fc5c3f2ba Huacai Chen 2022-05-31 20 */ 803b0fc5c3f2ba Huacai Chen 2022-05-31 21 #define GPR_BASE 0 803b0fc5c3f2ba Huacai Chen 2022-05-31 22 #define GPR_NUM 32 803b0fc5c3f2ba Huacai Chen 2022-05-31 23 #define GPR_END (GPR_BASE + GPR_NUM - 1) 803b0fc5c3f2ba Huacai Chen 2022-05-31 24 #define ARG0 (GPR_END + 1) 803b0fc5c3f2ba Huacai Chen 2022-05-31 @25 #define PC (GPR_END + 2) 803b0fc5c3f2ba Huacai Chen 2022-05-31 26 #define BADVADDR (GPR_END + 3) 803b0fc5c3f2ba Huacai Chen 2022-05-31 27 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

4 months, 1 week

Re: [PATCH 3/9] dt-bindings: mailbox: rockchip,rknn: Add bindings

by Conor Dooley

On Wed, Jun 12, 2024 at 03:52:56PM +0200, Tomeu Vizoso wrote: > Add the bindings for the Neural Processing Unit IP from Rockchip. > > Signed-off-by: Tomeu Vizoso <tomeu(a)tomeuvizoso.net> > --- > .../devicetree/bindings/npu/rockchip,rknn.yaml | 123 +++++++++++++++++++++ > 1 file changed, 123 insertions(+) > > diff --git a/Documentation/devicetree/bindings/npu/rockchip,rknn.yaml b/Documentation/devicetree/bindings/npu/rockchip,rknn.yaml > new file mode 100644 > index 000000000000..570a4889c11c > --- /dev/null > +++ b/Documentation/devicetree/bindings/npu/rockchip,rknn.yaml > @@ -0,0 +1,123 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/npu/rockchip,rknn.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Neural Processing Unit IP from Rockchip, based on NVIDIA's NVDLA > + > +maintainers: > + - Tomeu Vizoso <tomeu(a)tomeuvizoso.net> > + > +description: |+ The |+ chomping operator is not needed here. > + Rockchip IP for accelerating inference of neural networks, based on NVIDIA's open source NVDLA IP. > + > +properties: > + compatible: > + items: > + - enum: > + - rockchip,rk3588-rknn > + - const: rockchip,rknn > + > + reg: > + description: Base registers for NPU cores > + minItems: 1 > + maxItems: 20 For all of these properties, you need to describe the individual items. > + > + interrupts: > + minItems: 1 > + maxItems: 20 > + > + interrupt-names: > + minItems: 1 > + maxItems: 20 > + > + clocks: > + minItems: 1 > + maxItems: 20 > + > + clock-names: > + minItems: 1 > + maxItems: 20 > + > + assigned-clocks: > + maxItems: 1 > + > + assigned-clock-rates: > + maxItems: 1 > + > + resets: > + minItems: 1 > + maxItems: 20 > + > + reset-names: > + minItems: 1 > + maxItems: 20 > + > + power-domains: > + minItems: 1 > + maxItems: 20 > + > + power-domain-names: > + minItems: 1 > + maxItems: 20 > + > + iommus: > + items: > + - description: IOMMU for all cores > + > +required: > + - compatible > + - reg > + - interrupts > + - interrupt-names > + - clocks > + - clock-names > + - assigned-clocks > + - assigned-clock-rates > + - resets > + - reset-names > + - power-domains > + - power-domain-names > + - iommus > + > +additionalProperties: false > + > +examples: > + - | > + #include <dt-bindings/interrupt-controller/arm-gic.h> > + > + bus { > + #address-cells = <2>; > + #size-cells = <2>; > + > + rknn: npu@fdab0000 { Drop the label here, it's not used. > + compatible = "rockchip,rk3588-rknn", "rockchip,rknn"; > + reg = <0x0 0xfdab0000 0x0 0x9000>, > + <0x0 0xfdac0000 0x0 0x9000>, > + <0x0 0xfdad0000 0x0 0x9000>; > + interrupts = <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH 0>, > + <GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH 0>, > + <GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH 0>; > + interrupt-names = "npu0_irq", "npu1_irq", "npu2_irq"; > + clocks = <&scmi_clk 0>, <&cru 1>, > + <&cru 2>, <&cru 3>, > + <&cru 4>, <&cru 5>, > + <&cru 6>, <&cru 7>; > + clock-names = "clk_npu", > + "aclk0", "aclk1", "aclk2", > + "hclk0", "hclk1", "hclk2", > + "pclk"; > + assigned-clocks = <&scmi_clk 0>; > + assigned-clock-rates = <200000000>; > + resets = <&cru 0>, <&cru 1>, <&cru 2>, > + <&cru 3>, <&cru 4>, <&cru 5>; > + reset-names = "srst_a0", "srst_a1", "srst_a2", > + "srst_h0", "srst_h1", "srst_h2"; > + power-domains = <&power 0>, <&power 1>, <&power 2>; > + power-domain-names = "npu0", "npu1", "npu2"; > + iommus = <&rknpu_mmu>; > + status = "disabled"; A disabled example is useless. > + }; > + }; > +... > > -- > 2.45.2 >

4 months, 1 week

Re: [PATCH] dma-buf/heaps: Correct the types of fd_flags and heap_flags

by John Stultz

On Wed, Jun 5, 2024 at 7:02 PM Barry Song <21cnbao(a)gmail.com> wrote: > > From: Barry Song <v-songbaohua(a)oppo.com> > > dma_heap_allocation_data defines the UAPI as follows: > > struct dma_heap_allocation_data { > __u64 len; > __u32 fd; > __u32 fd_flags; > __u64 heap_flags; > }; > > But dma heaps are casting both fd_flags and heap_flags into > unsigned long. This patch makes dma heaps - cma heap and > system heap have consistent types with UAPI. > > Signed-off-by: Barry Song <v-songbaohua(a)oppo.com> Thanks for submitting this additional cleanup! Acked-by: John Stultz <jstultz(a)google.com>

4 months, 2 weeks

Re: [PATCH v2] dma-buf: align fd_flags and heap_flags with dma_heap_allocation_data

by Sumit Semwal

Hello Barry, On Wed, 5 Jun 2024 at 06:56, Barry Song <21cnbao(a)gmail.com> wrote: > > From: Barry Song <v-songbaohua(a)oppo.com> > > dma_heap_allocation_data defines the UAPI as follows: > > struct dma_heap_allocation_data { > __u64 len; > __u32 fd; > __u32 fd_flags; > __u64 heap_flags; > }; > > However, dma_heap_buffer_alloc() casts both fd_flags and heap_flags > into unsigned int. We're inconsistent with types in the non UAPI > arguments. This patch fixes it. Thank you for your patch; I've pushed it to drm-misc-next. Best, Sumit. > > Signed-off-by: Barry Song <v-songbaohua(a)oppo.com> > Acked-by: John Stultz <jstultz(a)google.com> > --- > -v2: > collect ack of John, thanks! > refine commit message; > > drivers/dma-buf/dma-heap.c | 4 ++-- > include/uapi/linux/dma-heap.h | 2 +- > 2 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c > index 84ae708fafe7..2298ca5e112e 100644 > --- a/drivers/dma-buf/dma-heap.c > +++ b/drivers/dma-buf/dma-heap.c > @@ -50,8 +50,8 @@ static struct class *dma_heap_class; > static DEFINE_XARRAY_ALLOC(dma_heap_minors); > > static int dma_heap_buffer_alloc(struct dma_heap *heap, size_t len, > - unsigned int fd_flags, > - unsigned int heap_flags) > + u32 fd_flags, > + u64 heap_flags) > { > struct dma_buf *dmabuf; > int fd; > diff --git a/include/uapi/linux/dma-heap.h b/include/uapi/linux/dma-heap.h > index 6f84fa08e074..a4cf716a49fa 100644 > --- a/include/uapi/linux/dma-heap.h > +++ b/include/uapi/linux/dma-heap.h > @@ -19,7 +19,7 @@ > #define DMA_HEAP_VALID_FD_FLAGS (O_CLOEXEC | O_ACCMODE) > > /* Currently no heap flags */ > -#define DMA_HEAP_VALID_HEAP_FLAGS (0) > +#define DMA_HEAP_VALID_HEAP_FLAGS (0ULL) > > /** > * struct dma_heap_allocation_data - metadata passed from userspace for > -- > 2.34.1 > -- Thanks and regards, Sumit Semwal (he / him) Tech Lead - LCG, Vertical Technologies Linaro.org │ Open source software for ARM SoCs

4 months, 2 weeks

Re: [RFC PATCH v1] dma-buf: heaps: move the verification of heap_flags to the corresponding heap

by John Stultz

On Mon, Jun 3, 2024 at 11:30 PM Hailong Liu <hailong.liu(a)oppo.com> wrote: > On 6/4/2024 2:06 AM, John Stultz wrote: > > On Mon, Jun 3, 2024 at 10:21 AM Hailong Liu <hailong.liu(a)oppo.com> wrote: > >> We now aim to improve priority dma-buf allocation. Consider android > >> animations scene: > >> > >> when device is in low memory, Allocating dma-buf as animation > >> buffers enter direct_reclaimation, longer allocation time result in a > >> laggy UI. But if we know the usage of the dma-buf, we can use some > >> mechanisms to boost, e.g. animation-memory-pool. > > > > Can you generalize this a bit further? When would userland know to use > > this new flag? > > If it is aware, would it make sense to just use a separate heap name instead? > > > > (Also: These other mechanisms you mention should probably also be > > submitted upstream, however for upstream there's also the requirement > > that we have open users and are not just enabling proprietary blob > > userspace, which makes any changes to dma-buf heaps for out of tree > > code quite difficult) > > > >> However, dma-buf usage identification becomes a challenge. A potential > >> solution could be heap_flags. the use of heap_flags seems ugly and > >> contrary to the intended design as you said, How aboult extending > >> dma_heap_allocation_data as follows? > >> > >> struct dma_heap_allocation_data { > >> __u64 len; > >> __u32 fd; > >> __u32 fd_flags; > >> __u64 heap_flags; > >> __u64 buf_flags: // buf usage > >> }; > > > > This would affect the ABI (forcing a new ioctl number). And it's > > unclear what flags you envision as buffer specific (rather than heap > > specific as this patch suggested). > > > > I think we need more details about the specific problem you're seeing > > and trying to resolve. > This patch mainly focuses on optimization for Android scenarios. Let’s > discuss it on the issue website. > Bug: 344501512 Ok, we can do that if you need. But if this is ever going to go upstream (and it's more and more important that we minimize out of tree technical debt), conversations about how to generalize this will need to happen on the list. thanks -john

4 months, 2 weeks

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig June 2024