Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

24 participants
2728 discussions

Start a nNew thread

Re: [PATCH v1 5/5] i2c: i2c-qcom-geni: Add Block event interrupt support

by kernel test robot

6 months, 1 week

Re: [PATCH v1 5/5] i2c: i2c-qcom-geni: Add Block event interrupt support

by kernel test robot

Hi Jyothi, kernel test robot noticed the following build errors: [auto build test ERROR on 55bcd2e0d04c1171d382badef1def1fd04ef66c5] url: https://github.com/intel-lab-lkp/linux/commits/Jyothi-Kumar-Seerapu/dt-bind… base: 55bcd2e0d04c1171d382badef1def1fd04ef66c5 patch link: https://lore.kernel.org/r/20241015120750.21217-6-quic_jseerapu%40quicinc.com patch subject: [PATCH v1 5/5] i2c: i2c-qcom-geni: Add Block event interrupt support config: x86_64-allyesconfig (https://download.01.org/0day-ci/archive/20241019/202410190549.hGAfByqg-lkp@…) compiler: clang version 18.1.8 (https://github.com/llvm/llvm-project 3b5b5c1ec4a3095ab096dd780e84d7ab81f3d7ff) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20241019/202410190549.hGAfByqg-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/202410190549.hGAfByqg-lkp@intel.com/ All errors (new ones prefixed by >>): >> drivers/i2c/busses/i2c-qcom-geni.c:562:8: error: incompatible pointer to integer conversion passing 'dma_addr_t *' (aka 'unsigned long long *') to parameter of type 'dma_addr_t' (aka 'unsigned long long'); dereference with * [-Wint-conversion] 562 | tx_multi_xfer->dma_addr[wr_idx], NULL, NULL); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | * drivers/i2c/busses/i2c-qcom-geni.c:519:36: note: passing argument to parameter 'tx_addr' here 519 | void *tx_buf, dma_addr_t tx_addr, | ^ >> drivers/i2c/busses/i2c-qcom-geni.c:562:47: error: incompatible pointer to integer conversion passing 'void *' to parameter of type 'dma_addr_t' (aka 'unsigned long long') [-Wint-conversion] 562 | tx_multi_xfer->dma_addr[wr_idx], NULL, NULL); | ^~~~ include/linux/stddef.h:8:14: note: expanded from macro 'NULL' 8 | #define NULL ((void *)0) | ^~~~~~~~~~~ drivers/i2c/busses/i2c-qcom-geni.c:520:36: note: passing argument to parameter 'rx_addr' here 520 | void *rx_buf, dma_addr_t rx_addr) | ^ >> drivers/i2c/busses/i2c-qcom-geni.c:586:7: error: incompatible pointer to integer conversion assigning to 'dma_addr_t' (aka 'unsigned long long') from 'dma_addr_t *' (aka 'unsigned long long *'); dereference with * [-Wint-conversion] 586 | addr = gi2c_gpi_xfer->dma_addr[gi2c_gpi_xfer->buf_idx]; | ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | * 3 errors generated. Kconfig warnings: (for reference only) WARNING: unmet direct dependencies detected for OMAP2PLUS_MBOX Depends on [n]: MAILBOX [=y] && (ARCH_OMAP2PLUS || ARCH_K3) Selected by [y]: - TI_K3_M4_REMOTEPROC [=y] && REMOTEPROC [=y] && (ARCH_K3 || COMPILE_TEST [=y]) vim +562 drivers/i2c/busses/i2c-qcom-geni.c 532 533 /** 534 * gpi_i2c_multi_desc_unmap() - unmaps the buffers post multi message TX transfers 535 * @dev: pointer to the corresponding dev node 536 * @gi2c: i2c dev handle 537 * @msgs: i2c messages array 538 * @peripheral: pointer to the gpi_i2c_config 539 */ 540 static void gpi_i2c_multi_desc_unmap(struct geni_i2c_dev *gi2c, struct i2c_msg msgs[], 541 struct gpi_i2c_config *peripheral) 542 { 543 u32 msg_xfer_cnt, wr_idx = 0; 544 struct gpi_multi_xfer *tx_multi_xfer = &peripheral->multi_xfer; 545 546 /* 547 * In error case, need to unmap all messages based on the msg_idx_cnt. 548 * Non-error case unmap all the processed messages. 549 */ 550 if (gi2c->err) 551 msg_xfer_cnt = tx_multi_xfer->msg_idx_cnt; 552 else 553 msg_xfer_cnt = tx_multi_xfer->irq_cnt * NUM_MSGS_PER_IRQ; 554 555 /* Unmap the processed DMA buffers based on the received interrupt count */ 556 for (; tx_multi_xfer->unmap_msg_cnt < msg_xfer_cnt; tx_multi_xfer->unmap_msg_cnt++) { 557 if (tx_multi_xfer->unmap_msg_cnt == gi2c->num_msgs) 558 break; 559 wr_idx = tx_multi_xfer->unmap_msg_cnt % QCOM_GPI_MAX_NUM_MSGS; 560 geni_i2c_gpi_unmap(gi2c, &msgs[tx_multi_xfer->unmap_msg_cnt], 561 tx_multi_xfer->dma_buf[wr_idx], > 562 tx_multi_xfer->dma_addr[wr_idx], NULL, NULL); 563 tx_multi_xfer->freed_msg_cnt++; 564 } 565 } 566 567 static int geni_i2c_gpi(struct geni_i2c_dev *gi2c, struct i2c_msg msgs[], int cur_msg_idx, 568 struct dma_slave_config *config, dma_addr_t *dma_addr_p, 569 void **buf, unsigned int op, struct dma_chan *dma_chan) 570 { 571 struct gpi_i2c_config *peripheral; 572 unsigned int flags; 573 void *dma_buf; 574 dma_addr_t addr; 575 enum dma_data_direction map_dirn; 576 enum dma_transfer_direction dma_dirn; 577 struct dma_async_tx_descriptor *desc; 578 int ret; 579 struct gpi_multi_xfer *gi2c_gpi_xfer; 580 dma_cookie_t cookie; 581 582 peripheral = config->peripheral_config; 583 gi2c_gpi_xfer = &peripheral->multi_xfer; 584 gi2c_gpi_xfer->msg_idx_cnt = cur_msg_idx; 585 dma_buf = gi2c_gpi_xfer->dma_buf[gi2c_gpi_xfer->buf_idx]; > 586 addr = gi2c_gpi_xfer->dma_addr[gi2c_gpi_xfer->buf_idx]; 587 588 dma_buf = i2c_get_dma_safe_msg_buf(&msgs[gi2c_gpi_xfer->msg_idx_cnt], 1); 589 if (!dma_buf) { 590 gi2c->err = -ENOMEM; 591 return -ENOMEM; 592 } 593 594 if (op == I2C_WRITE) 595 map_dirn = DMA_TO_DEVICE; 596 else 597 map_dirn = DMA_FROM_DEVICE; 598 599 addr = dma_map_single(gi2c->se.dev->parent, 600 dma_buf, msgs[gi2c_gpi_xfer->msg_idx_cnt].len, 601 map_dirn); 602 if (dma_mapping_error(gi2c->se.dev->parent, addr)) { 603 i2c_put_dma_safe_msg_buf(dma_buf, &msgs[gi2c_gpi_xfer->msg_idx_cnt], 604 false); 605 gi2c->err = -ENOMEM; 606 return -ENOMEM; 607 } 608 609 if (gi2c->is_tx_multi_xfer) { 610 if (((gi2c_gpi_xfer->msg_idx_cnt + 1) % NUM_MSGS_PER_IRQ)) 611 peripheral->flags |= QCOM_GPI_BLOCK_EVENT_IRQ; 612 else 613 peripheral->flags &= ~QCOM_GPI_BLOCK_EVENT_IRQ; 614 615 /* BEI bit to be cleared for last TRE */ 616 if (gi2c_gpi_xfer->msg_idx_cnt == gi2c->num_msgs - 1) 617 peripheral->flags &= ~QCOM_GPI_BLOCK_EVENT_IRQ; 618 } 619 620 /* set the length as message for rx txn */ 621 peripheral->rx_len = msgs[gi2c_gpi_xfer->msg_idx_cnt].len; 622 peripheral->op = op; 623 624 ret = dmaengine_slave_config(dma_chan, config); 625 if (ret) { 626 dev_err(gi2c->se.dev, "dma config error: %d for op:%d\n", ret, op); 627 goto err_config; 628 } 629 630 peripheral->set_config = 0; 631 peripheral->multi_msg = true; 632 flags = DMA_PREP_INTERRUPT | DMA_CTRL_ACK; 633 634 if (op == I2C_WRITE) 635 dma_dirn = DMA_MEM_TO_DEV; 636 else 637 dma_dirn = DMA_DEV_TO_MEM; 638 639 desc = dmaengine_prep_slave_single(dma_chan, addr, 640 msgs[gi2c_gpi_xfer->msg_idx_cnt].len, 641 dma_dirn, flags); 642 if (!desc) { 643 dev_err(gi2c->se.dev, "prep_slave_sg failed\n"); 644 gi2c->err = -EIO; 645 goto err_config; 646 } 647 648 desc->callback_result = i2c_gpi_cb_result; 649 desc->callback_param = gi2c; 650 651 if (!((msgs[cur_msg_idx].flags & I2C_M_RD) && op == I2C_WRITE)) { 652 gi2c_gpi_xfer->msg_idx_cnt++; 653 gi2c_gpi_xfer->buf_idx = (cur_msg_idx + 1) % QCOM_GPI_MAX_NUM_MSGS; 654 } 655 cookie = dmaengine_submit(desc); 656 if (dma_submit_error(cookie)) { 657 dev_err(gi2c->se.dev, 658 "%s: dmaengine_submit failed (%d)\n", __func__, cookie); 659 return -EINVAL; 660 } 661 662 if (gi2c->is_tx_multi_xfer) { 663 dma_async_issue_pending(gi2c->tx_c); 664 if ((cur_msg_idx == (gi2c->num_msgs - 1)) || 665 (gi2c_gpi_xfer->msg_idx_cnt >= 666 QCOM_GPI_MAX_NUM_MSGS + gi2c_gpi_xfer->freed_msg_cnt)) { 667 ret = gpi_multi_desc_process(gi2c->se.dev, gi2c_gpi_xfer, 668 gi2c->num_msgs, XFER_TIMEOUT, 669 &gi2c->done); 670 if (ret) { 671 dev_dbg(gi2c->se.dev, 672 "I2C multi write msg transfer timeout: %d\n", 673 ret); 674 gi2c->err = -ETIMEDOUT; 675 goto err_config; 676 } 677 } 678 } else { 679 /* Non multi descriptor message transfer */ 680 *buf = dma_buf; 681 *dma_addr_p = addr; 682 } 683 return 0; 684 685 err_config: 686 dma_unmap_single(gi2c->se.dev->parent, addr, 687 msgs[cur_msg_idx].len, map_dirn); 688 i2c_put_dma_safe_msg_buf(dma_buf, &msgs[cur_msg_idx], false); 689 return ret; 690 } 691 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

6 months, 1 week

[RFC PATCH v2 0/2] TEE subsystem for restricted dma-buf allocations

by Jens Wiklander

Hi, This patch set allocates the restricted DMA-bufs via the TEE subsystem. This a complete rewrite compared to the previous patch set [1], and other earlier proposals [2] and [3] with a separate restricted heap. The TEE subsystem handles the DMA-buf allocations since it is the TEE (OP-TEE, AMD-TEE, TS-TEE, or a future QTEE) which sets up the restrictions for the memory used for the DMA-bufs. I've added a new IOCTL, TEE_IOC_RSTMEM_ALLOC, to allocate the restricted DMA-bufs. This new IOCTL reaches the backend TEE driver, allowing it to choose how to allocate the restricted physical memory. TEE_IOC_RSTMEM_ALLOC is quite similar to TEE_IOC_SHM_ALLOC so it's tempting to extend TEE_IOC_SHM_ALLOC with two new flags TEE_IOC_SHM_FLAG_SECURE_VIDEO and TEE_IOC_SHM_FLAG_SECURE_TRUSTED_UI for the same feature. However, it might be a bit confusing since TEE_IOC_SHM_ALLOC only returns an anonymous file descriptor, but TEE_IOC_SHM_FLAG_SECURE_VIDEO and TEE_IOC_SHM_FLAG_SECURE_TRUSTED_UI would return a DMA-buf file descriptor instead. What do others think? This can be tested on QEMU with the following steps: repo init -u https://github.com/jenswi-linaro/manifest.git -m qemu_v8.xml \ -b prototype/sdp-v2 repo sync -j8 cd build make toolchains -j4 make all -j$(nproc) make run-only # login and at the prompt: xtest --sdp-basic https://optee.readthedocs.io/en/latest/building/prerequisites.html list dependencies needed to build the above. The tests are pretty basic, mostly checking that a Trusted Application in the secure world can access and manipulate the memory. There are also some negative tests for out of bounds buffers etc. Thanks, Jens [1] https://lore.kernel.org/lkml/20240830070351.2855919-1-jens.wiklander@linaro… [2] https://lore.kernel.org/dri-devel/20240515112308.10171-1-yong.wu@mediatek.c… [3] https://lore.kernel.org/lkml/20220805135330.970-1-olivier.masse@nxp.com/ Changes since the V1 RFC: * Based on v6.11 * Complete rewrite, replacing the restricted heap with TEE_IOC_RSTMEM_ALLOC Changes since Olivier's post [2]: * Based on Yong Wu's post [1] where much of dma-buf handling is done in the generic restricted heap * Simplifications and cleanup * New commit message for "dma-buf: heaps: add Linaro restricted dmabuf heap support" * Replaced the word "secure" with "restricted" where applicable Jens Wiklander (2): tee: add restricted memory allocation optee: support restricted memory allocation drivers/tee/Makefile | 1 + drivers/tee/optee/core.c | 21 ++++ drivers/tee/optee/optee_private.h | 6 + drivers/tee/optee/optee_smc.h | 35 ++++++ drivers/tee/optee/smc_abi.c | 45 ++++++- drivers/tee/tee_core.c | 33 ++++- drivers/tee/tee_private.h | 2 + drivers/tee/tee_rstmem.c | 200 ++++++++++++++++++++++++++++++ drivers/tee/tee_shm.c | 2 + drivers/tee/tee_shm_pool.c | 69 ++++++++++- include/linux/tee_core.h | 6 + include/linux/tee_drv.h | 9 ++ include/uapi/linux/tee.h | 33 ++++- 13 files changed, 455 insertions(+), 7 deletions(-) create mode 100644 drivers/tee/tee_rstmem.c -- 2.43.0

6 months, 1 week

[PATCH] dma-buf/dma-fence_array: use kvzalloc

by Christian König

Reports indicates that some userspace applications try to merge more than 80k of fences into a single dma_fence_array leading to a warning from kzalloc() that the requested size becomes to big. While that is clearly an userspace bug we should probably handle that case gracefully in the kernel. So we can either reject requests to merge more than a reasonable amount of fences (64k maybe?) or we can start to use kvzalloc() instead of kzalloc(). This patch here does the later. Signed-off-by: Christian König <christian.koenig(a)amd.com> CC: stable(a)vger.kernel.org --- drivers/dma-buf/dma-fence-array.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/dma-buf/dma-fence-array.c b/drivers/dma-buf/dma-fence-array.c index 8a08ffde31e7..46ac42bcfac0 100644 --- a/drivers/dma-buf/dma-fence-array.c +++ b/drivers/dma-buf/dma-fence-array.c @@ -119,8 +119,8 @@ static void dma_fence_array_release(struct dma_fence *fence) for (i = 0; i < array->num_fences; ++i) dma_fence_put(array->fences[i]); - kfree(array->fences); - dma_fence_free(fence); + kvfree(array->fences); + kvfree_rcu(fence, rcu); } static void dma_fence_array_set_deadline(struct dma_fence *fence, @@ -153,7 +153,7 @@ struct dma_fence_array *dma_fence_array_alloc(int num_fences) { struct dma_fence_array *array; - return kzalloc(struct_size(array, callbacks, num_fences), GFP_KERNEL); + return kvzalloc(struct_size(array, callbacks, num_fences), GFP_KERNEL); } EXPORT_SYMBOL(dma_fence_array_alloc); -- 2.34.1

6 months, 1 week

Re: [PATCH 9/9] drm/panfrost: Explicitly clean up panfrost fence

by Christian König

Am 16.10.24 um 18:43 schrieb Adrián Larumbe: > On 16.10.2024 15:12, Christian König wrote: >> Am 15.10.24 um 01:31 schrieb Adrián Larumbe: >>> Doesn't make any functional difference because generic dma_fence is the >>> first panfrost_fence structure member, but I guess it doesn't hurt either. >> As discussed with Sima we want to push into the exactly opposite direction >> because that requires that the panfrost module stays loaded as long as fences >> are around. > Does that mean in future commits the struct dma_fence_ops' .release pointer will be > done with altogether? Yes, exactly that's the idea. As a first step I'm preparing patches right now to enforce using kmalloc instead of driver brewed approaches for dma_fence handling. Regards, Christian. > >> So clearly a NAK to this one here. Rather document on the structure that the >> dma_fence structure must be the first member. >> >> Regards, >> Christian. >> >>> Signed-off-by: Adrián Larumbe <adrian.larumbe(a)collabora.com> >>> --- >>> drivers/gpu/drm/panfrost/panfrost_job.c | 6 ++++++ >>> 1 file changed, 6 insertions(+) >>> >>> diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c b/drivers/gpu/drm/panfrost/panfrost_job.c >>> index 5d83c6a148ec..fa219f719bdc 100644 >>> --- a/drivers/gpu/drm/panfrost/panfrost_job.c >>> +++ b/drivers/gpu/drm/panfrost/panfrost_job.c >>> @@ -85,9 +85,15 @@ static const char *panfrost_fence_get_timeline_name(struct dma_fence *fence) >>> } >>> } >>> +static void panfrost_fence_release(struct dma_fence *fence) >>> +{ >>> + kfree(to_panfrost_fence(fence)); >>> +} >>> + >>> static const struct dma_fence_ops panfrost_fence_ops = { >>> .get_driver_name = panfrost_fence_get_driver_name, >>> .get_timeline_name = panfrost_fence_get_timeline_name, >>> + .release = panfrost_fence_release, >>> }; >>> static struct dma_fence *panfrost_fence_create(struct panfrost_device *pfdev, int js_num)

6 months, 1 week

Re: [PATCH v1 2/5] arm64: dts: qcom: Add support for configuring channel TRE size

by Krzysztof Kozlowski

On 15/10/2024 14:07, Jyothi Kumar Seerapu wrote: > When high performance with multiple i2c messages in a single transfer > is required, employ Block Event Interrupt (BEI) to trigger interrupts > after specific messages transfer and the last message transfer, > thereby reducing interrupts. > For each i2c message transfer, a series of Transfer Request Elements(TREs) > must be programmed, including config tre for frequency configuration, > go tre for holding i2c address and dma tre for holding dma buffer address, > length as per the hardware programming guide. For transfer using BEI, > multiple I2C messages may necessitate the preparation of config, go, > and tx DMA TREs. However, a channel TRE size of 64 is often insufficient, > potentially leading to failures due to inadequate memory space. > > Adjust the channel TRE size through the device tree. > The default size is 64, but clients can modify this value based on > their heigher channel TRE size requirements. > > Signed-off-by: Jyothi Kumar Seerapu <quic_jseerapu(a)quicinc.com> > --- > arch/arm64/boot/dts/qcom/sc7280.dtsi | 132 +++++++++++++-------------- > 1 file changed, 66 insertions(+), 66 deletions(-) > > diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi b/arch/arm64/boot/dts/qcom/sc7280.dtsi > index 3d8410683402..c7c0e15ff9d3 100644 > --- a/arch/arm64/boot/dts/qcom/sc7280.dtsi > +++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi > @@ -1064,7 +1064,7 @@ > }; > > gpi_dma0: dma-controller@900000 { > - #dma-cells = <3>; > + #dma-cells = <4>; > compatible = "qcom,sc7280-gpi-dma", "qcom,sm6350-gpi-dma"; > reg = <0 0x00900000 0 0x60000>; > interrupts = <GIC_SPI 244 IRQ_TYPE_LEVEL_HIGH>, > @@ -1114,8 +1114,8 @@ > "qup-memory"; > power-domains = <&rpmhpd SC7280_CX>; > required-opps = <&rpmhpd_opp_low_svs>; > - dmas = <&gpi_dma0 0 0 QCOM_GPI_I2C>, > - <&gpi_dma0 1 0 QCOM_GPI_I2C>; > + dmas = <&gpi_dma0 0 0 QCOM_GPI_I2C 64>, > + <&gpi_dma0 1 0 QCOM_GPI_I2C 64>; So everywhere is 64, thus this is fixed. Deduce it from the compatible Best regards, Krzysztof

6 months, 1 week

Re: [PATCH 9/9] drm/panfrost: Explicitly clean up panfrost fence

by Christian König

Am 15.10.24 um 01:31 schrieb Adrián Larumbe: > Doesn't make any functional difference because generic dma_fence is the > first panfrost_fence structure member, but I guess it doesn't hurt either. As discussed with Sima we want to push into the exactly opposite direction because that requires that the panfrost module stays loaded as long as fences are around. So clearly a NAK to this one here. Rather document on the structure that the dma_fence structure must be the first member. Regards, Christian. > Signed-off-by: Adrián Larumbe <adrian.larumbe(a)collabora.com> > --- > drivers/gpu/drm/panfrost/panfrost_job.c | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c b/drivers/gpu/drm/panfrost/panfrost_job.c > index 5d83c6a148ec..fa219f719bdc 100644 > --- a/drivers/gpu/drm/panfrost/panfrost_job.c > +++ b/drivers/gpu/drm/panfrost/panfrost_job.c > @@ -85,9 +85,15 @@ static const char *panfrost_fence_get_timeline_name(struct dma_fence *fence) > } > } > > +static void panfrost_fence_release(struct dma_fence *fence) > +{ > + kfree(to_panfrost_fence(fence)); > +} > + > static const struct dma_fence_ops panfrost_fence_ops = { > .get_driver_name = panfrost_fence_get_driver_name, > .get_timeline_name = panfrost_fence_get_timeline_name, > + .release = panfrost_fence_release, > }; > > static struct dma_fence *panfrost_fence_create(struct panfrost_device *pfdev, int js_num)

6 months, 1 week

Re: [PATCH v1 1/5] dt-bindings: dmaengine: qcom: gpi: Add additional arg to dma-cell property

by Vinod Koul

On 15-10-24, 17:37, Jyothi Kumar Seerapu wrote: > When high performance with multiple i2c messages in a single transfer > is required, employ Block Event Interrupt (BEI) to trigger interrupts > after specific messages transfer and the last message transfer, > thereby reducing interrupts. > > For each i2c message transfer, a series of Transfer Request Elements(TREs) > must be programmed, including config tre for frequency configuration, > go tre for holding i2c address and dma tre for holding dma buffer address, > length as per the hardware programming guide. For transfer using BEI, > multiple I2C messages may necessitate the preparation of config, go, > and tx DMA TREs. However, a channel TRE size of 64 is often insufficient, > potentially leading to failures due to inadequate memory space. > > Add additional argument to dma-cell property for channel TRE size. > With this, adjust the channel TRE size via the device tree. > The default size is 64, but clients can modify this value based on > their specific requirements. > > Signed-off-by: Jyothi Kumar Seerapu <quic_jseerapu(a)quicinc.com> > --- > Documentation/devicetree/bindings/dma/qcom,gpi.yaml | 6 ++++-- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/Documentation/devicetree/bindings/dma/qcom,gpi.yaml b/Documentation/devicetree/bindings/dma/qcom,gpi.yaml > index 4df4e61895d2..002495921643 100644 > --- a/Documentation/devicetree/bindings/dma/qcom,gpi.yaml > +++ b/Documentation/devicetree/bindings/dma/qcom,gpi.yaml > @@ -54,14 +54,16 @@ properties: > maxItems: 13 > > "#dma-cells": > - const: 3 > + minItems: 3 > + maxItems: 4 > description: > > DMA clients must use the format described in dma.txt, giving a phandle > - to the DMA controller plus the following 3 integer cells: > + to the DMA controller plus the following 4 integer cells: > - channel: if set to 0xffffffff, any available channel will be allocated > for the client. Otherwise, the exact channel specified will be used. > - seid: serial id of the client as defined in the SoC documentation. > - client: type of the client as defined in dt-bindings/dma/qcom-gpi.h > + - channel-tre-size: size of the channel TRE (transfer ring element) This is a firmware /software property, why should this be in hardware description? -- ~Vinod

6 months, 2 weeks

Re: [PATCH v1 00/10] Add MediaTek ISP7 camera system driver

by Nicolas Dufresne

Hi, Le mercredi 09 octobre 2024 à 19:15 +0800, Shu-hsiang Yang a écrit : > Based on linux-next/master, tag: next-20241008 > > The patch set adds the MediaTek ISP7.x camera system hardware driver. > > This driver sets up ISP hardware, handles interrupts, and initializes > V4L2 device nodes and functions. Moreover, implement V4L2 standard > video driver that utilizes media framework APIs. It also connects > the sensors and ISP, bridging with the seninf interface. Communicate > with SCP co-processor to compose ISP registers in the firmware. Thanks for this work. If I read you correctly, this will depends on an scp firmware update. Its probably early at rev1, but we appreciate if you can cross- reference your associated linux-firmware submission (or document which MT flavour of SCP firmware) contains this support already. For ISP drivers reviewers, we have the experience with SCP that the IPC is not versioned, making it difficult to maintain backward compatibility. Won't matter until this is merged, but be aware that unless this SCP IPC design issue has been fixed, any change to the -if headers means a modification to the SCP has been made, and often we have had to ask MTK to revisit the firmware code to unbreak backward compatibility. If this specific part of the SCP IPC is versioned, please let us know. I don't want this to be alarming message, just something we need to collectively be aware of not to break userspace, which may not update their firmwares in lock step with the kernel. regards, Nicolas p.s. for those new to MTK architecture, the SCP firmware provides services to everything multimedia in the platform, including CODECs, color converter and scalers, etc. > > These patches include CSI received data from sensors, sensor interface > bridge, raw/YUV image pre-processing, ISP utility and ISP control parts. > > Thank you for reviewing these patches. > > Shu-hsiang Yang (10): > dt-bindings: media: mediatek: add camsys device > media: platform: mediatek: add seninf controller > media: platform: mediatek: add isp_7x seninf unit > media: platform: mediatek: add isp_7x cam-raw unit > media: platform: mediatek: add isp_7x camsys unit > media: platform: mediatek: add isp_7x utility > media: platform: mediatek: add isp_7x video ops > media: platform: mediatek: add isp_7x state ctrl > media: platform: mediatek: add isp_7x build config > uapi: linux: add mediatek isp_7x camsys user api > > .../media/mediatek/mediatek,cam-raw.yaml | 169 + > .../media/mediatek/mediatek,cam-yuv.yaml | 148 + > .../media/mediatek/mediatek,camisp.yaml | 71 + > .../media/mediatek/mediatek,seninf-core.yaml | 106 + > .../media/mediatek/mediatek,seninf.yaml | 88 + > drivers/media/platform/mediatek/Kconfig | 1 + > drivers/media/platform/mediatek/Makefile | 2 + > drivers/media/platform/mediatek/isp/Kconfig | 21 + > .../platform/mediatek/isp/isp_7x/Makefile | 7 + > .../mediatek/isp/isp_7x/camsys/Makefile | 16 + > .../isp_7x/camsys/kd_imgsensor_define_v4l2.h | 87 + > .../mediatek/isp/isp_7x/camsys/mtk_cam-ctrl.c | 1797 ++++++ > .../mediatek/isp/isp_7x/camsys/mtk_cam-ctrl.h | 140 + > .../isp/isp_7x/camsys/mtk_cam-debug.c | 1271 ++++ > .../isp/isp_7x/camsys/mtk_cam-debug.h | 273 + > .../mediatek/isp/isp_7x/camsys/mtk_cam-defs.h | 168 + > .../isp/isp_7x/camsys/mtk_cam-dmadbg.h | 721 +++ > .../isp/isp_7x/camsys/mtk_cam-feature.c | 40 + > .../isp/isp_7x/camsys/mtk_cam-feature.h | 26 + > .../mediatek/isp/isp_7x/camsys/mtk_cam-fmt.h | 87 + > .../mediatek/isp/isp_7x/camsys/mtk_cam-ipi.h | 233 + > .../isp/isp_7x/camsys/mtk_cam-meta-mt8188.h | 2436 ++++++++ > .../isp/isp_7x/camsys/mtk_cam-plat-util.c | 207 + > .../isp/isp_7x/camsys/mtk_cam-plat-util.h | 16 + > .../mediatek/isp/isp_7x/camsys/mtk_cam-pool.c | 393 ++ > .../mediatek/isp/isp_7x/camsys/mtk_cam-pool.h | 28 + > .../mediatek/isp/isp_7x/camsys/mtk_cam-raw.c | 5359 +++++++++++++++++ > .../mediatek/isp/isp_7x/camsys/mtk_cam-raw.h | 325 + > .../isp/isp_7x/camsys/mtk_cam-raw_debug.c | 403 ++ > .../isp/isp_7x/camsys/mtk_cam-raw_debug.h | 39 + > .../isp/isp_7x/camsys/mtk_cam-regs-mt8188.h | 382 ++ > .../isp/isp_7x/camsys/mtk_cam-seninf-def.h | 193 + > .../isp/isp_7x/camsys/mtk_cam-seninf-drv.c | 1741 ++++++ > .../isp/isp_7x/camsys/mtk_cam-seninf-drv.h | 16 + > .../isp/isp_7x/camsys/mtk_cam-seninf-hw.h | 120 + > .../isp/isp_7x/camsys/mtk_cam-seninf-if.h | 28 + > .../isp/isp_7x/camsys/mtk_cam-seninf-regs.h | 40 + > .../isp/isp_7x/camsys/mtk_cam-seninf-route.c | 356 ++ > .../isp/isp_7x/camsys/mtk_cam-seninf-route.h | 23 + > .../isp/isp_7x/camsys/mtk_cam-seninf.h | 170 + > .../isp/isp_7x/camsys/mtk_cam-timesync.c | 125 + > .../isp/isp_7x/camsys/mtk_cam-timesync.h | 12 + > .../isp/isp_7x/camsys/mtk_cam-ufbc-def.h | 59 + > .../isp/isp_7x/camsys/mtk_cam-video.c | 1817 ++++++ > .../isp/isp_7x/camsys/mtk_cam-video.h | 224 + > .../mediatek/isp/isp_7x/camsys/mtk_cam.c | 4168 +++++++++++++ > .../mediatek/isp/isp_7x/camsys/mtk_cam.h | 733 +++ > .../isp_7x/camsys/mtk_camera-v4l2-controls.h | 65 + > .../isp_7x/camsys/mtk_csi_phy_2_0/Makefile | 5 + > .../mtk_csi_phy_2_0/mtk_cam-seninf-cammux.h | 911 +++ > .../mtk_cam-seninf-csi0-cphy.h | 69 + > .../mtk_cam-seninf-csi0-dphy.h | 139 + > .../mtk_cam-seninf-hw_phy_2_0.c | 2879 +++++++++ > .../mtk_cam-seninf-mipi-rx-ana-cdphy-csi0a.h | 257 + > .../mtk_cam-seninf-seninf1-csi2.h | 415 ++ > .../mtk_cam-seninf-seninf1-mux.h | 147 + > .../mtk_csi_phy_2_0/mtk_cam-seninf-seninf1.h | 47 + > .../mtk_csi_phy_2_0/mtk_cam-seninf-tg1.h | 49 + > .../mtk_csi_phy_2_0/mtk_cam-seninf-top-ctrl.h | 99 + > include/uapi/linux/mtkisp_camsys.h | 227 + > 60 files changed, 30194 insertions(+) > create mode 100644 Documentation/devicetree/bindings/media/mediatek/mediatek,cam-raw.yaml > create mode 100644 Documentation/devicetree/bindings/media/mediatek/mediatek,cam-yuv.yaml > create mode 100644 Documentation/devicetree/bindings/media/mediatek/mediatek,camisp.yaml > create mode 100644 Documentation/devicetree/bindings/media/mediatek/mediatek,seninf-core.yaml > create mode 100644 Documentation/devicetree/bindings/media/mediatek/mediatek,seninf.yaml > create mode 100644 drivers/media/platform/mediatek/isp/Kconfig > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/Makefile > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/Makefile > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/kd_imgsensor_define_v4l2.h > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_cam-ctrl.c > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_cam-ctrl.h > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_cam-debug.c > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_cam-debug.h > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_cam-defs.h > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_cam-dmadbg.h > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_cam-feature.c > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_cam-feature.h > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_cam-fmt.h > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_cam-ipi.h > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_cam-meta-mt8188.h > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_cam-plat-util.c > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_cam-plat-util.h > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_cam-pool.c > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_cam-pool.h > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_cam-raw.c > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_cam-raw.h > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_cam-raw_debug.c > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_cam-raw_debug.h > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_cam-regs-mt8188.h > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_cam-seninf-def.h > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_cam-seninf-drv.c > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_cam-seninf-drv.h > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_cam-seninf-hw.h > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_cam-seninf-if.h > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_cam-seninf-regs.h > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_cam-seninf-route.c > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_cam-seninf-route.h > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_cam-seninf.h > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_cam-timesync.c > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_cam-timesync.h > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_cam-ufbc-def.h > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_cam-video.c > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_cam-video.h > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_cam.c > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_cam.h > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_camera-v4l2-controls.h > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_csi_phy_2_0/Makefile > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_csi_phy_2_0/mtk_cam-seninf-cammux.h > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_csi_phy_2_0/mtk_cam-seninf-csi0-cphy.h > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_csi_phy_2_0/mtk_cam-seninf-csi0-dphy.h > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_csi_phy_2_0/mtk_cam-seninf-hw_phy_2_0.c > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_csi_phy_2_0/mtk_cam-seninf-mipi-rx-ana-cdphy-csi0a.h > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_csi_phy_2_0/mtk_cam-seninf-seninf1-csi2.h > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_csi_phy_2_0/mtk_cam-seninf-seninf1-mux.h > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_csi_phy_2_0/mtk_cam-seninf-seninf1.h > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_csi_phy_2_0/mtk_cam-seninf-tg1.h > create mode 100644 drivers/media/platform/mediatek/isp/isp_7x/camsys/mtk_csi_phy_2_0/mtk_cam-seninf-top-ctrl.h > create mode 100644 include/uapi/linux/mtkisp_camsys.h >

6 months, 2 weeks

Re: [PATCH v1 1/5] dt-bindings: dmaengine: qcom: gpi: Add additional arg to dma-cell property

by Rob Herring

On Tue, Oct 15, 2024 at 05:37:46PM +0530, Jyothi Kumar Seerapu wrote: > When high performance with multiple i2c messages in a single transfer > is required, employ Block Event Interrupt (BEI) to trigger interrupts > after specific messages transfer and the last message transfer, > thereby reducing interrupts. > > For each i2c message transfer, a series of Transfer Request Elements(TREs) > must be programmed, including config tre for frequency configuration, > go tre for holding i2c address and dma tre for holding dma buffer address, > length as per the hardware programming guide. For transfer using BEI, > multiple I2C messages may necessitate the preparation of config, go, > and tx DMA TREs. However, a channel TRE size of 64 is often insufficient, > potentially leading to failures due to inadequate memory space. > > Add additional argument to dma-cell property for channel TRE size. No such property 'dma-cell' > With this, adjust the channel TRE size via the device tree. > The default size is 64, but clients can modify this value based on > their specific requirements. > > Signed-off-by: Jyothi Kumar Seerapu <quic_jseerapu(a)quicinc.com> > --- > Documentation/devicetree/bindings/dma/qcom,gpi.yaml | 6 ++++-- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/Documentation/devicetree/bindings/dma/qcom,gpi.yaml b/Documentation/devicetree/bindings/dma/qcom,gpi.yaml > index 4df4e61895d2..002495921643 100644 > --- a/Documentation/devicetree/bindings/dma/qcom,gpi.yaml > +++ b/Documentation/devicetree/bindings/dma/qcom,gpi.yaml > @@ -54,14 +54,16 @@ properties: > maxItems: 13 > > "#dma-cells": > - const: 3 > + minItems: 3 > + maxItems: 4 > description: > > DMA clients must use the format described in dma.txt, giving a phandle > - to the DMA controller plus the following 3 integer cells: > + to the DMA controller plus the following 4 integer cells: > - channel: if set to 0xffffffff, any available channel will be allocated > for the client. Otherwise, the exact channel specified will be used. > - seid: serial id of the client as defined in the SoC documentation. > - client: type of the client as defined in dt-bindings/dma/qcom-gpi.h > + - channel-tre-size: size of the channel TRE (transfer ring element) > > iommus: > maxItems: 1 > -- > 2.17.1 >

6 months, 2 weeks

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig