Linux Media Controller development
 help / color / mirror / Atom feed
From: "Christian König" <christian.koenig@amd.com>
To: Jason Gunthorpe <jgg@nvidia.com>,
	Diederik de Haas <diederik@cknow-tech.com>
Cc: Karl Mehltretter <kmehltretter@gmail.com>,
	Sumit Semwal <sumit.semwal@linaro.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Rob Clark <rob.clark@oss.qualcomm.com>,
	Jianfeng Liu <liujianfeng1994@gmail.com>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Vinod Koul <vkoul@kernel.org>,
	Bjorn Andersson <andersson@kernel.org>,
	linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org,
	linaro-mm-sig@lists.linaro.org, linux-kernel@vger.kernel.org,
	Alistair Popple <apopple@nvidia.com>,
	Leon Romanovsky <leonro@nvidia.com>
Subject: Re: [RFC PATCH 2/3] dma-buf: add a warn-only mode to DMABUF_DEBUG
Date: Fri, 9 Oct 2026 15:21:47 +0200	[thread overview]
Message-ID: <50f74418-a1b9-4d93-a9a9-02bb7cbf4544@amd.com> (raw)
In-Reply-To: <20261009125338.GB13920@nvidia.com>

On 10/9/26 14:53, Jason Gunthorpe wrote:
> On Wed, Oct 07, 2026 at 02:02:31PM +0200, Diederik de Haas wrote:
>> [ 1091.981354] rc rc3: two consecutive events of type space
>> [ 1104.670513] input: EDIFIER e235 (AVRCP) as /devices/virtual/input/input12
>> [ 1172.090231] devfreq fb000000.gpu: Couldn't update frequency transition information.
>> [ 1189.403278] devfreq fb000000.gpu: Couldn't update frequency transition information.
>> [ 1206.309295] input: EDIFIER e235 (AVRCP) as /devices/virtual/input/input13
>> [ 1268.968696] DMA-BUF: importer used the CPU side of an exporter's sg_table
> 
> This is a nice stack trace, is that the point of this series?
> 
>> [ 1268.968710] CPU: 6 UID: 1000 PID: 29025 Comm: sway Not tainted 7.3-rc6+unreleased-arm64-cknow #1 PREEMPTLAZY  Debian 7.3~rc6-3
>> [ 1268.968715] Hardware name: FriendlyElec NanoPC-T6 Plus (DT)
>> [ 1268.968717] Call trace:
>> [ 1268.968719]  show_stack+0x20/0x38 (C)
>> [ 1268.968726]  dump_stack_lvl+0x60/0x80
>> [ 1268.968730]  sg_dmabuf_cpu_access_warn.part.0+0x24/0x30
>> [ 1268.968734]  sg_dmabuf_cpu_access_warn+0x34/0x38
>> [ 1268.968739]  iommu_map_sg+0xc8/0x1e0
>> [ 1268.968745]  rockchip_gem_iommu_map+0x8c/0x128 [rockchipdrm]
>> [ 1268.968757]  rockchip_gem_prime_import_sg_table+0x58/0x160 [rockchipdrm]
>> [ 1268.968761]  drm_gem_prime_import_dev+0xa8/0x1d0 [drm]
>> [ 1268.968776]  drm_gem_prime_fd_to_handle+0x1a4/0x280 [drm]
> 
> So.. This is the exact same thing I need for iommufd.
> 
> rockchip is managing its own iommu domain and you cannot map to an
> iommu domain without using a physical address.
> 
> Of course it is *completely* illegal to call iommu_map_sgtable() in the
> importer side of a dmabuf.

Yeah we are deprecating this for the last ~5 years now. This bubbled up because I change to DMA-buf debug code to be enabled by default on DEBUG_KERNEL.

Rob is now working on a solution right now for MSM which should be used for rockchip as well.

Regards,
Christian.

> 
> static int rockchip_gem_iommu_map(struct rockchip_gem_object *rk_obj)
> {
> [..]
> 	ret = iommu_map_sgtable(private->domain, rk_obj->dma_addr, rk_obj->sgt,
> 				prot);
> 
> Jason


  reply	other threads:[~2026-10-09 13:21 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-05  6:41 [RFC PATCH 0/3] dma-buf: warn-only mode for DMABUF_DEBUG Karl Mehltretter
2026-10-05  6:41 ` [RFC PATCH 1/3] dma-buf: keep the DMA flags in the DMABUF_DEBUG copy Karl Mehltretter
2026-10-09 13:29   ` Christian König
2026-10-05  6:41 ` [RFC PATCH 2/3] dma-buf: add a warn-only mode to DMABUF_DEBUG Karl Mehltretter
2026-10-07 12:02   ` Diederik de Haas
2026-10-09 12:53     ` Jason Gunthorpe
2026-10-09 13:21       ` Christian König [this message]
2026-10-09 14:24         ` Jason Gunthorpe
2026-10-09 13:29       ` Diederik de Haas
2026-10-09 12:42   ` Jason Gunthorpe
2026-10-09 13:18     ` Christian König
2026-10-05  6:41 ` [RFC PATCH 3/3] dma-buf: test the debug scatterlist wrapper Karl Mehltretter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50f74418-a1b9-4d93-a9a9-02bb7cbf4544@amd.com \
    --to=christian.koenig@amd.com \
    --cc=akpm@linux-foundation.org \
    --cc=andersson@kernel.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=apopple@nvidia.com \
    --cc=diederik@cknow-tech.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jgg@nvidia.com \
    --cc=kmehltretter@gmail.com \
    --cc=leonro@nvidia.com \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=liujianfeng1994@gmail.com \
    --cc=rob.clark@oss.qualcomm.com \
    --cc=sumit.semwal@linaro.org \
    --cc=vkoul@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox