Re: [GIT PULL] exynos-drm-next

[Simona Vetter <simona.vetter@ffwll.ch>]

On Tue, May 26, 2026 at 11:01:07AM +1000, Dave Airlie wrote:
> On Fri, 22 May 2026 at 00:36, Inki Dae <inki.dae@samsung.com> wrote:
> >
> > Hi Dave and Daniel,
> >
> >     This PR brings a cleanup and modernization series for Exynos DRM,
> >     focused on fbdev emulation and DMA/GEM internals.
> >
> > Major changes are:
> >     - migrate fbdev allocation to DRM client buffers,
> >     - switch fbdev geometry calculations to DRM format helpers with tighter checks,
> >     - fix screen_buffer handling to match fb_info semantics,
> >     - adopt DRM core DMA tracking and remove redundant Exynos-side code.
> >
> > Please kindly let me know if there is any problem.
> 
> Hi Inki,
> 
> In file included from
> /home/airlied/devel/kernel/dim/src/drivers/gpu/drm/exynos/exynos_drm_gem.c:16:
> /home/airlied/devel/kernel/dim/src/drivers/gpu/drm/exynos/exynos_drm_gem.c:
> In function ‘exynos_drm_alloc_buf’:
> /home/airlied/devel/kernel/dim/src/drivers/gpu/drm/exynos/exynos_drm_gem.c:69:49:
> warning: format ‘%lx’ expects argument of type ‘long unsigned int’,
> but argument 6 has type ‘size_t’ {aka ‘unsigned int’} [-Wformat=]
>    69 |         DRM_DEV_DEBUG_KMS(drm_dev_dma_dev(dev),
> "dma_addr(0x%lx), size(0x%lx)\n",
>       |
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>    70 |                         (unsigned long)exynos_gem->dma_addr,
> exynos_gem->base.size);
>       |
> ~~~~~~~~~~~~~~~~~~~~~
>       |
>               |
>       |
>               size_t {aka unsigned int}
> /home/airlied/devel/kernel/dim/src/include/drm/drm_print.h:563:39:
> note: in definition of macro ‘drm_dev_dbg’
>   563 |         __drm_dev_dbg(NULL, dev, cat, fmt, ##__VA_ARGS__)
>       |                                       ^~~
> /home/airlied/devel/kernel/dim/src/drivers/gpu/drm/exynos/exynos_drm_gem.c:69:9:
> note: in expansion of macro ‘DRM_DEV_DEBUG_KMS’
>    69 |         DRM_DEV_DEBUG_KMS(drm_dev_dma_dev(dev),
> "dma_addr(0x%lx), size(0x%lx)\n",
>       |         ^~~~~~~~~~~~~~~~~
> /home/airlied/devel/kernel/dim/src/drivers/gpu/drm/exynos/exynos_drm_gem.c:69:76:
> note: format string is defined here
>    69 |         DRM_DEV_DEBUG_KMS(drm_dev_dma_dev(dev),
> "dma_addr(0x%lx), size(0x%lx)\n",
>       |
>           ~~^
>       |
>             |
>       |
>             long unsigned int
>       |
>           %x
> /home/airlied/devel/kernel/dim/src/drivers/gpu/drm/exynos/exynos_drm_gem.c:
> In function ‘exynos_drm_free_buf’:
> /home/airlied/devel/kernel/dim/src/drivers/gpu/drm/exynos/exynos_drm_gem.c:83:37:
> warning: format ‘%lx’ expects argument of type ‘long unsigned int’,
> but argument 6 has type ‘size_t’ {aka ‘unsigned int’} [-Wformat=]
>    83 |         DRM_DEV_DEBUG_KMS(dev->dev, "dma_addr(0x%lx), size(0x%lx)\n",
>       |                                     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>    84 |                         (unsigned long)exynos_gem->dma_addr,
> exynos_gem->base.size);
>       |
> ~~~~~~~~~~~~~~~~~~~~~
>       |
>               |
>       |
>               size_t {aka unsigned int}
> /home/airlied/devel/kernel/dim/src/include/drm/drm_print.h:563:39:
> note: in definition of macro ‘drm_dev_dbg’
>   563 |         __drm_dev_dbg(NULL, dev, cat, fmt, ##__VA_ARGS__)
>       |                                       ^~~
> /home/airlied/devel/kernel/dim/src/drivers/gpu/drm/exynos/exynos_drm_gem.c:83:9:
> note: in expansion of macro ‘DRM_DEV_DEBUG_KMS’
>    83 |         DRM_DEV_DEBUG_KMS(dev->dev, "dma_addr(0x%lx), size(0x%lx)\n",
>       |         ^~~~~~~~~~~~~~~~~
> /home/airlied/devel/kernel/dim/src/drivers/gpu/drm/exynos/exynos_drm_gem.c:83:64:
> note: format string is defined here
>    83 |         DRM_DEV_DEBUG_KMS(dev->dev, "dma_addr(0x%lx), size(0x%lx)\n",
>       |                                                              ~~^
>       |                                                                |
>       |
> long unsigned int
>       |                                                              %x
> 
> 
> Can you fix this up in a follow on PR?

Uh, you've pushed this already and it kinda broke my workflow. I've
applied the fixup from Arnd to sort this out. Apparently there was also a
fixup by the original author, but that never landed in the right trees.

Cheers, Sima
-- 
Simona Vetter
Software Engineer
http://blog.ffwll.ch