From mboxrd@z Thu Jan 1 00:00:00 1970 From: Claude Code Review Bot To: dri-devel-reviews@example.com Subject: Claude review: drm/mediatek: Set dedicated DMA device and drop custom GEM callbacks Date: Wed, 11 Mar 2026 13:48:35 +1000 Message-ID: In-Reply-To: <20260310032012.2542334-4-wenst@chromium.org> References: <20260310032012.2542334-1-wenst@chromium.org> <20260310032012.2542334-4-wenst@chromium.org> X-Mailer: Claude Code Patch Reviewer Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Patch Review This is the big payoff: replaces the loop setting `private->all_drm_private[i]->dma_dev` and drops `mtk_gem.c` / `mtk_gem.h` entirely. ```c - for (i = 0; i < private->data->mmsys_dev_num; i++) - private->all_drm_private[i]->dma_dev = dma_dev; + drm_dev_set_dma_dev(drm, dma_dev); ``` One observation: the old code set `.dma_dev` on **all** `mmsys_dev_num` drm_private instances, while the new code only calls `drm_dev_set_dma_dev()` on the single `drm` device. For multi-MMSYS configurations (e.g., MT8195 which has 2 MMSYS blocks), are there multiple `drm_device` instances that need the DMA device set? Looking at the code, all the `all_drm_private[i]` share the same `drm` device (they're all private data for sub-components bound to the same master), and `dma_dev` is stored in the private struct, not in `drm_device`. The new code sets it on `drm->dma_dev` which is the single DRM device, so this should be fine -- all paths now go through `drm_dev_dma_dev(drm)` which reads the single `drm->dma_dev` field. But it's worth confirming that none of the old `private->dma_dev` references remain elsewhere in the mediatek driver code beyond what's being removed. The replacement of custom driver ops with `DRM_GEM_DMA_DRIVER_OPS` is clean: ```c - .dumb_create = mtk_gem_dumb_create, + DRM_GEM_DMA_DRIVER_OPS, ... - .gem_prime_import = mtk_gem_prime_import, - .gem_prime_import_sg_table = mtk_gem_prime_import_sg_table, ``` The commit message correctly notes the VM_DONTDUMP and VM_IO flag difference in the mmap path. The GEM DMA helpers don't set these because `dma_mmap_wc()` handles the mapping directly and the backing pages come from DMA-coherent allocations, making VM_IO inappropriate as the author notes. **Minor**: No remaining references to `mtk_gem.h` in other mediatek files besides `mtk_crtc.c` (which is cleaned up)? The patch looks complete. **Reviewed-by worthy**: Yes, with confirmation that multi-MMSYS setups work correctly with only one `drm_dev_set_dma_dev()` call. --- Generated by Claude Code Patch Reviewer