Linaro-mm-sig

linaro-mm-sig@lists.linaro.org

27 participants
3105 discussions

Re: build failure of next-20220920 due to c2b08e7a6d27 ("drm/amdgpu: move entity selection and job init earlier during CS")

by Christian König

Thanks for pointing this out! It's indeed quite a bug. Going to send a patch ASAP. Regards, Christian. Am 20.09.22 um 13:47 schrieb Sudip Mukherjee: > Hi All, > > The builds of arm64 allmodconfig with clang failed to build next-20220920 > with the error: > > drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c:1190:3: error: variable 'r' is uninitialized when used here [-Werror,-Wuninitialized] > r |= !amdgpu_ttm_tt_get_user_pages_done(bo->tbo.ttm); > ^ > drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c:1171:7: note: initialize the variable 'r' to silence this warning > int r; > ^ > = 0 > 1 error generated. > > > git bisect pointed to c2b08e7a6d27 ("drm/amdgpu: move entity selection and job init earlier during CS") > > I will be happy to test any patch or provide any extra log if needed. > >

3 years, 1 month

[BUG] ls1046a: eDMA does not transfer data from I2C

by Sean Anderson

Hi all, I discovered a bug in either imx_i2c or fsl-edma on the LS1046A where no data is read in i2c_imx_dma_read except for the last two bytes (which are not read using DMA). This is perhaps best illustrated with the following example: # hexdump -C /sys/bus/nvmem/devices/0-00540/nvmem [ 308.914884] i2c i2c-0: ffff000809380000 0x0000000889380000 0x00000000f5401000 ffff000075401000 [ 308.923529] src= 2180004 dst=f5401000 attr= 0 soff= 0 nbytes=1 slast= 0 [ 308.923529] citer= 7e biter= 7e doff= 1 dlast_sga= 0 [ 308.923529] major_int=1 disable_req=1 enable_sg=0 [ 308.942113] fsl-edma 2c00000.edma: vchan 000000001b4371fc: txd 00000000d9dd26c5[4]: submitted [ 308.974049] fsl-edma 2c00000.edma: txd 00000000d9dd26c5[4]: marked complete [ 308.981339] i2c i2c-0: ffff000809380000 = [2e 2e 2f 2e 2e 2f 2e 2e 2f 64 65 76 69 63 65 73 2f 70 6c 61 74 66 6f 72 6d 2f 73 6f 63 2f 32 31 38 30 30 30 30 2e 69 32 63 2f 69 32 63 2d 30 2f 30 2d 30 30 35 34 2f 30 2d 30 30 35 34 30 00 00] [ 309.002226] i2c i2c-0: ffff000075401000 = [2e 2e 2f 2e 2e 2f 2e 2e 2f 64 65 76 69 63 65 73 2f 70 6c 61 74 66 6f 72 6d 2f 73 6f 63 2f 32 31 38 30 30 30 30 2e 69 32 63 2f 69 32 63 2d 30 2f 30 2d 30 30 35 34 2f 30 2d 30 30 35 34 30 00 00] [ 309.024649] i2c i2c-0: ffff000809380080 0x0000000889380080 0x00000000f5401800 ffff000075401800 [ 309.033270] src= 2180004 dst=f5401800 attr= 0 soff= 0 nbytes=1 slast= 0 [ 309.033270] citer= 7e biter= 7e doff= 1 dlast_sga= 0 [ 309.033270] major_int=1 disable_req=1 enable_sg=0 [ 309.051633] fsl-edma 2c00000.edma: vchan 000000001b4371fc: txd 00000000d9dd26c5[5]: submitted [ 309.083526] fsl-edma 2c00000.edma: txd 00000000d9dd26c5[5]: marked complete [ 309.090807] i2c i2c-0: ffff000809380080 = [00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00] [ 309.111694] i2c i2c-0: ffff000075401800 = [00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00] 00000000 2e 2e 2f 2e 2e 2f 2e 2e 2f 64 65 76 69 63 65 73 |../../../devices| 00000010 2f 70 6c 61 74 66 6f 72 6d 2f 73 6f 63 2f 32 31 |/platform/soc/21| 00000020 38 30 30 30 30 2e 69 32 63 2f 69 32 63 2d 30 2f |80000.i2c/i2c-0/| 00000030 30 2d 30 30 35 34 2f 30 2d 30 30 35 34 30 00 00 |0-0054/0-00540..| 00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff ff |................| 00000080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 000000f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff 5b |...............[| 00000100 (patch with my debug prints appended below) Despite the DMA completing successfully, no data was copied into the buffer, leaving the original (now junk) contents. I probed the I2C bus with an oscilloscope, and I verified that the transfer did indeed occur. The timing between submission and completion seems reasonable for the bus speed (50 kHz for whatever reason). I had a look over the I2C driver, and nothing looked obviously incorrect. If anyone has ideas on what to try, I'm more than willing. --Sean diff --git a/drivers/dma/fsl-edma-common.c b/drivers/dma/fsl-edma-common.c index 15896e2413c4..1d9d4a55d2af 100644 --- a/drivers/dma/fsl-edma-common.c +++ b/drivers/dma/fsl-edma-common.c @@ -391,6 +391,12 @@ void fsl_edma_fill_tcd(struct fsl_edma_hw_tcd *tcd, u32 src, u32 dst, { u16 csr = 0; + pr_info("src=%8x dst=%8x attr=%4x soff=%4x nbytes=%u slast=%8x\n" + "citer=%4x biter=%4x doff=%4x dlast_sga=%8x\n" + "major_int=%d disable_req=%d enable_sg=%d\n", + src, dst, attr, soff, nbytes, slast, citer, biter, doff, + dlast_sga, major_int, disable_req, enable_sg); + /* * eDMA hardware SGs require the TCDs to be stored in little * endian format irrespective of the register endian model. diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c index 3576b63a6c03..0217f0cb1331 100644 --- a/drivers/i2c/busses/i2c-imx.c +++ b/drivers/i2c/busses/i2c-imx.c @@ -402,6 +402,9 @@ static int i2c_imx_dma_xfer(struct imx_i2c_struct *i2c_imx, dev_err(dev, "DMA mapping failed\n"); goto err_map; } + phys_addr_t bufp = virt_to_phys(msgs->buf); + dev_info(dev, "%px %pap %pad %px\n", msgs->buf, &bufp, + &dma->dma_buf, phys_to_virt(dma->dma_buf)); txdesc = dmaengine_prep_slave_single(dma->chan_using, dma->dma_buf, dma->dma_len, dma->dma_transfer_dir, @@ -965,6 +968,9 @@ static int i2c_imx_dma_read(struct imx_i2c_struct *i2c_imx, } schedule(); } + dev_info(dev, "%px = [%*ph]\n", msgs->buf, msgs->len, msgs->buf); + dev_info(dev, "%px = [%*ph]\n", phys_to_virt(dma->dma_buf), msgs->len, + phys_to_virt(dma->dma_buf)); temp = imx_i2c_read_reg(i2c_imx, IMX_I2C_I2CR); temp &= ~I2CR_DMAEN;

3 years, 1 month

[PATCH v4 0/6] dma-buf: Check status of enable-signaling bit on debug

by Arvind Yadav

Fence signaling must be enabled to make sure that the dma_fence_is_signaled() function ever returns true. Since drivers and implementations sometimes mess this up, this ensures correct behaviour when DEBUG_WW_MUTEX_SLOWPATH is used during debugging. This should make any implementation bugs resulting in not signaled fences much more obvious. Arvind Yadav (6): [PATCH v4 1/6] dma-buf: Remove the signaled bit status check [PATCH v4 2/6] dma-buf: set signaling bit for the stub fence [PATCH v4 3/6] dma-buf: Enable signaling on fence for selftests [PATCH v4 4/6] dma-buf: dma_fence_wait must enable signaling [PATCH v4 5/6] drm/sched: Use parent fence instead of finished [PATCH v4 6/6] dma-buf: Check status of enable-signaling bit on debug drivers/dma-buf/Kconfig | 7 +++++++ drivers/dma-buf/dma-fence.c | 16 ++++++++++------ drivers/dma-buf/st-dma-fence-chain.c | 4 ++++ drivers/dma-buf/st-dma-fence-unwrap.c | 22 ++++++++++++++++++++++ drivers/dma-buf/st-dma-fence.c | 16 ++++++++++++++++ drivers/dma-buf/st-dma-resv.c | 10 ++++++++++ drivers/gpu/drm/scheduler/sched_main.c | 4 ++-- include/linux/dma-fence.h | 5 +++++ 8 files changed, 76 insertions(+), 8 deletions(-) -- 2.25.1

3 years, 1 month

[PATCH v1] drivers/gpu/drm/i915/gt: Check the return value of i915_active_acquire()

by Li Zhong

i915_active_acquire() could return error when the acquire fails. Check and return the error code. Signed-off-by: Li Zhong <floridsleeves(a)gmail.com> --- drivers/gpu/drm/i915/gt/intel_timeline.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gt/intel_timeline.c b/drivers/gpu/drm/i915/gt/intel_timeline.c index b9640212d659..d8333ab64574 100644 --- a/drivers/gpu/drm/i915/gt/intel_timeline.c +++ b/drivers/gpu/drm/i915/gt/intel_timeline.c @@ -211,7 +211,10 @@ int intel_timeline_pin(struct intel_timeline *tl, struct i915_gem_ww_ctx *ww) GT_TRACE(tl->gt, "timeline:%llx using HWSP offset:%x\n", tl->fence_context, tl->hwsp_offset); - i915_active_acquire(&tl->active); + err = i915_active_acquire(&tl->active); + if (err) + return err; + if (atomic_fetch_inc(&tl->pin_count)) { i915_active_release(&tl->active); __i915_vma_unpin(tl->hwsp_ggtt); -- 2.25.1

3 years, 1 month

[PATCH] dma-buf: use strscpy() is more robust and safer

by cgel.zte＠gmail.com

From: Minghao Chi <chi.minghao(a)zte.com.cn> The implementation of strscpy() is more robust and safer. That's now the recommended way to copy NUL terminated strings. Signed-off-by: Minghao Chi <chi.minghao(a)zte.com.cn> --- drivers/dma-buf/dma-buf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index dd0f83ee505b..51cdd4060539 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -50,7 +50,7 @@ static char *dmabuffs_dname(struct dentry *dentry, char *buffer, int buflen) dmabuf = dentry->d_fsdata; spin_lock(&dmabuf->name_lock); if (dmabuf->name) - ret = strlcpy(name, dmabuf->name, DMA_BUF_NAME_LEN); + ret = strscpy(name, dmabuf->name, DMA_BUF_NAME_LEN); spin_unlock(&dmabuf->name_lock); return dynamic_dname(buffer, buflen, "/%s:%s", -- 2.25.1

3 years, 1 month

[PATCH linux-next] drm/ttm: remove duplicate included header files

by cgel.zte＠gmail.com

From: Xu Panda <xu.panda(a)zte.com.cn> drm/drm_drv.h is included more than once. Reported-by: Zeal Robot <zealci(a)zte.com.cn> Signed-off-by: Xu Panda <xu.panda(a)zte.com.cn> --- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c index b1c455329023..c659d4535ee0 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c @@ -43,7 +43,6 @@ #include <linux/sizes.h> #include <linux/module.h> -#include <drm/drm_drv.h> #include <drm/ttm/ttm_bo_api.h> #include <drm/ttm/ttm_bo_driver.h> #include <drm/ttm/ttm_placement.h> -- 2.15.2

3 years, 1 month

[PATCH v3 0/6] dma-buf: Check status of enable-signaling bit on debug

by Arvind Yadav

Fence signaling must be enabled to make sure that the dma_fence_is_signaled() function ever returns true. Since drivers and implementations sometimes mess this up, this ensures correct behaviour when DEBUG_WW_MUTEX_SLOWPATH is used during debugging. This should make any implementation bugs resulting in not signaled fences much more obvious. Arvind Yadav (6): [PATCH v3 1/6] dma-buf: Remove the signaled bit status check [PATCH v3 2/6] dma-buf: set signaling bit for the stub fence [PATCH v3 3/6] dma-buf: Enable signaling on fence for selftests [PATCH v3 4/6] drm/amdgpu: Enable signaling on fence. [PATCH v3 5/6] drm/sched: Use parent fence instead of finished [PATCH v3 6/6] dma-buf: Check status of enable-signaling bit on debug drivers/dma-buf/dma-fence.c | 7 ++++--- drivers/dma-buf/st-dma-fence-chain.c | 4 ++++ drivers/dma-buf/st-dma-fence-unwrap.c | 22 ++++++++++++++++++++++ drivers/dma-buf/st-dma-fence.c | 16 ++++++++++++++++ drivers/dma-buf/st-dma-resv.c | 10 ++++++++++ drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 2 ++ drivers/gpu/drm/scheduler/sched_main.c | 4 ++-- include/linux/dma-fence.h | 5 +++++ 8 files changed, 65 insertions(+), 5 deletions(-) -- 2.25.1

3 years, 1 month

[PATCH v2 0/4] dma-buf: To check enable signaling before signaled

by Arvind Yadav

TTM, GEM, DRM or the core DMA-buf framework are needs to enable software signaling before the fence is signaled. The core DMA-buf framework software can forget to call enable_signaling before the fence is signaled. It means framework code can forget to call dma_fence_enable_sw_signaling() before calling dma_fence_is_signaled(). To avoid this scenario on debug kernel, check the DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT bit status before checking the MA_FENCE_FLAG_SIGNALED_BIT bit status to confirm that software signaling is enabled. Arvind Yadav (4): [PATCH v2 1/4] drm/sched: Enable signaling for finished fence [PATCH v2 2/4] dma-buf: enable signaling for the stub fence on debug [PATCH v2 3/4] dma-buf: enable signaling for selftest fence on debug [PATCH v2 4/4] dma-buf: Check status of enable-signaling bit on debug drivers/dma-buf/dma-fence.c | 7 ++++ drivers/dma-buf/st-dma-fence-chain.c | 8 +++++ drivers/dma-buf/st-dma-fence-unwrap.c | 44 ++++++++++++++++++++++++++ drivers/dma-buf/st-dma-fence.c | 25 ++++++++++++++- drivers/dma-buf/st-dma-resv.c | 20 ++++++++++++ drivers/gpu/drm/scheduler/sched_main.c | 2 ++ include/linux/dma-fence.h | 5 +++ 7 files changed, 110 insertions(+), 1 deletion(-) -- 2.25.1

3 years, 1 month

Re: [PATCH v2 4/4] vfio/pci: Allow MMIO regions to be exported through dma-buf

by jgg＠nvidia.com

The content of this message was lost. It was probably cross-posted to multiple lists and previously handled on another list.

3 years, 1 month

[PATCH v2 0/3] dma-buf: map-info support

by Rob Clark

From: Rob Clark <robdclark(a)chromium.org> See 1/3 for motivation. Rob Clark (3): dma-buf: Add ioctl to query mmap coherency/cache info drm/prime: Wire up mmap_info support drm/msm/prime: Add mmap_info support drivers/dma-buf/dma-buf.c | 63 ++++++++++++++++++++++++++------ drivers/gpu/drm/drm_prime.c | 3 ++ drivers/gpu/drm/msm/msm_gem.c | 12 +++++++ include/drm/drm_gem.h | 11 ++++++ include/linux/dma-buf.h | 11 ++++++ include/uapi/linux/dma-buf.h | 68 +++++++++++++++++++++++++++++++++++ 6 files changed, 158 insertions(+), 10 deletions(-) -- 2.36.1

3 years, 1 month

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Linaro-mm-sig