Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

2 participants
3108 discussions

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

1 year, 4 months

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

1 year, 4 months

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 >

1 year, 4 months

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>

1 year, 4 months

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

1 year, 5 months

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

1 year, 5 months

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 10:21 AM Hailong Liu <hailong.liu(a)oppo.com> wrote: > On Mon, 03. Jun 09:01, John Stultz wrote: > > On Mon, Jun 3, 2024 at 4:40 AM <hailong.liu(a)oppo.com> wrote: > > > > > > From: "Hailong.Liu" <hailong.liu(a)oppo.com> > > > > > > This help module use heap_flags to determine the type of dma-buf, > > > so that some mechanisms can be used to speed up allocation, such as > > > memory_pool, to optimize the allocation time of dma-buf. > > > > This feels like it's trying to introduce heap specific flags, but > > doesn't introduce any details about what those flags might be? > > > > This seems like it would re-allow the old opaque vendor specific heap > > flags that we saw in the ION days, which was problematic as different > > userspaces would use the same interface with potentially colliding > > heap flags with different meanings. Resulting in no way to properly > > move to an upstream solution. > > > > With the dma-heaps interface, we're trying to make sure it is well > > defined. One can register a number of heaps with different behaviors, > > and the heap name is used to differentiate the behavior. Any flags > > introduced will need to be well defined and behaviorally consistent > > between heaps. That way when an upstream solution lands, if necessary > > we can provide backwards compatibility via symlinks. > > > > So I don't think this is a good direction to go for dma-heaps. > > > > It would be better if you were able to clarify what flag requirements > > you need, so we can better understand how they might apply to other > > heaps, and see if it was something we would want to define as a flag > > (see the discussion here for similar thoughts: > > https://lore.kernel.org/lkml/CANDhNCoOKwtpstFE2VDcUvzdXUWkZ-Zx+fz6xrdPWTyci… > > ) > > > > But if your vendor heap really needs some sort of flags argument that > > you can't generalize, you can always implement your own dmabuf > > exporter driver with whatever ioctl interface you'd prefer. > > Thanks for your reply. Let’s continue our discussion here instead > of on android-review. We aim to enhance memory allocation on each > all heaps. Your pointer towards heap_flags used in /dev/ion for heap > identification was helpful. > > 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. thanks -john

1 year, 5 months

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 4:40 AM <hailong.liu(a)oppo.com> wrote: > > From: "Hailong.Liu" <hailong.liu(a)oppo.com> > > This help module use heap_flags to determine the type of dma-buf, > so that some mechanisms can be used to speed up allocation, such as > memory_pool, to optimize the allocation time of dma-buf. This feels like it's trying to introduce heap specific flags, but doesn't introduce any details about what those flags might be? This seems like it would re-allow the old opaque vendor specific heap flags that we saw in the ION days, which was problematic as different userspaces would use the same interface with potentially colliding heap flags with different meanings. Resulting in no way to properly move to an upstream solution. With the dma-heaps interface, we're trying to make sure it is well defined. One can register a number of heaps with different behaviors, and the heap name is used to differentiate the behavior. Any flags introduced will need to be well defined and behaviorally consistent between heaps. That way when an upstream solution lands, if necessary we can provide backwards compatibility via symlinks. So I don't think this is a good direction to go for dma-heaps. It would be better if you were able to clarify what flag requirements you need, so we can better understand how they might apply to other heaps, and see if it was something we would want to define as a flag (see the discussion here for similar thoughts: https://lore.kernel.org/lkml/CANDhNCoOKwtpstFE2VDcUvzdXUWkZ-Zx+fz6xrdPWTyci… ) But if your vendor heap really needs some sort of flags argument that you can't generalize, you can always implement your own dmabuf exporter driver with whatever ioctl interface you'd prefer. thanks -john

1 year, 5 months

Re: [PATCH v6 0/7] Add mediate-drm secure flow for SVP

by mripard＠kernel.org

On Tue, May 28, 2024 at 07:15:34AM GMT, Jason-JH Lin (林睿祥) wrote: > Hi Maxime, > > On Mon, 2024-05-27 at 16:06 +0200, Maxime Ripard wrote: > > Hi, > > > > On Sun, May 26, 2024 at 07:29:21AM GMT, Jason-JH.Lin wrote: > > > From: Jason-jh Lin <jason-jh.lin(a)mediatek.corp-partner.google.com> > > > > > > Memory Definitions: > > > secure memory - Memory allocated in the TEE (Trusted Execution > > > Environment) which is inaccessible in the REE (Rich Execution > > > Environment, i.e. linux kernel/userspace). > > > secure handle - Integer value which acts as reference to 'secure > > > memory'. Used in communication between TEE and REE to reference > > > 'secure memory'. > > > secure buffer - 'secure memory' that is used to store decrypted, > > > compressed video or for other general purposes in the TEE. > > > secure surface - 'secure memory' that is used to store graphic > > > buffers. > > > > > > Memory Usage in SVP: > > > The overall flow of SVP starts with encrypted video coming in from > > > an > > > outside source into the REE. The REE will then allocate a 'secure > > > buffer' and send the corresponding 'secure handle' along with the > > > encrypted, compressed video data to the TEE. The TEE will then > > > decrypt > > > the video and store the result in the 'secure buffer'. The REE will > > > then allocate a 'secure surface'. The REE will pass the 'secure > > > handles' for both the 'secure buffer' and 'secure surface' into the > > > TEE for video decoding. The video decoder HW will then decode the > > > contents of the 'secure buffer' and place the result in the 'secure > > > surface'. The REE will then attach the 'secure surface' to the > > > overlay > > > plane for rendering of the video. > > > > > > Everything relating to ensuring security of the actual contents of > > > the > > > 'secure buffer' and 'secure surface' is out of scope for the REE > > > and > > > is the responsibility of the TEE. > > > > > > DRM driver handles allocation of gem objects that are backed by a > > > 'secure > > > surface' and for displaying a 'secure surface' on the overlay > > > plane. > > > This introduces a new flag for object creation called > > > DRM_MTK_GEM_CREATE_RESTRICTED which indicates it should be a > > > 'secure > > > surface'. All changes here are in MediaTek specific code. > > > --- > > > TODO: > > > 1) Drop MTK_DRM_IOCTL_GEM_CREATE and use DMA_HEAP_IOCTL_ALLOC in > > > userspace > > > 2) DRM driver use secure mailbox channel to handle normal and > > > secure flow > > > 3) Implement setting mmsys routing table in the secure world series > > > > I'm not sure what you mean here. Why are you trying to upstream > > something that still needs to be removed from your patch series? > > > Because their is too much patches need to be fixed in this series, so I > list down the remaining TODO items and send to review for the other > patches. > > Sorry for the bothering, I'll drop this at the next version. If you don't intend to use it, we just shouldn't add it. Removing the TODO item doesn't make sense, even more so if heaps should be the way you handle this. > > Also, I made some comments on the previous version that have been > > entirely ignored and still apply on this version: > > > https://lore.kernel.org/dri-devel/20240415-guppy-of-perpetual-current-3a797… > > > > I lost that mail in my mailbox, so I didn't reply at that time. > I have imported that mail and replied to you. Hope you don't mind :) I haven't received that answer Maxime

1 year, 5 months

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

by John Stultz

On Wed, May 22, 2024 at 2:02 AM 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 them into unsigned int. It's unclear > whether this is intentional or what the purpose is, but it can be quite > confusing for users. > > Adding to the confusion, dma_heap_ops.allocate defines both of these as > unsigned long. Fortunately, since dma_heap_ops is not part of the UAPI, > it is less of a concern. > > struct dma_heap_ops { > struct dma_buf *(*allocate)(struct dma_heap *heap, > unsigned long len, > unsigned long fd_flags, > unsigned long heap_flags); > }; > > I am sending this RFC in hopes of clarifying these confusions. > > If the goal is to constrain both flags to 32 bits while ensuring the struct > is aligned to 64 bits, it would have been more suitable to define > dma_heap_allocation_data accordingly from the beginning, like so: > > struct dma_heap_allocation_data { > __u64 len; > __u32 fd; > __u32 fd_flags; > __u32 heap_flags; > __u32 padding; > }; So here, if I recall, the intent was to keep 64bits for potential future heap_flags. But your point above that we're inconsistent with types in the non UAPI arguments is valid. So I think your patch makes sense. Thanks for raising this issue! Acked-by: John Stultz <jstultz(a)google.com>

1 year, 5 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig