Received-SPF: pass (google.com: domain of linux-kernel+bounces-211201-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Date: Wed, 12 Jun 2024 10:45:53 +0200
From: Daniel Vetter <daniel@ffwll.ch>
To: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Peng Fan <peng.fan@nxp.com>, "Peng Fan (OSS)" <peng.fan@oss.nxp.com>,
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Maxime Ripard <mripard@kernel.org>,
	David Airlie <airlied@gmail.com>, Daniel Vetter <daniel@ffwll.ch>,
	Javier Martinez Canillas <javierm@redhat.com>,
	"dri-devel@lists.freedesktop.org" <dri-devel@lists.freedesktop.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] drm/fbdev-dma: fix getting smem_start
Message-ID: <ZmlgQV4Eov0xv5bc@phenom.ffwll.local>
Mail-Followup-To: Thomas Zimmermann <tzimmermann@suse.de>,
	Peng Fan <peng.fan@nxp.com>,
	"Peng Fan (OSS)" <peng.fan@oss.nxp.com>,
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Maxime Ripard <mripard@kernel.org>,
	David Airlie <airlied@gmail.com>,
	Javier Martinez Canillas <javierm@redhat.com>,
	"dri-devel@lists.freedesktop.org" <dri-devel@lists.freedesktop.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
References: <20240604080328.4024838-1-peng.fan@oss.nxp.com>
 <8f4a6d80-dd3e-422f-88af-d26f50c973ff@suse.de>
 <AM6PR04MB59415B3F01D02024A255BFB988C72@AM6PR04MB5941.eurprd04.prod.outlook.com>
 <766908de-922c-4d71-bb04-29dbe4d1d64d@suse.de>
 <AM6PR04MB5941216A69AE325A79689C5888C72@AM6PR04MB5941.eurprd04.prod.outlook.com>
 <6c01bee4-c3f5-496e-8b4f-a29c97954808@suse.de>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <6c01bee4-c3f5-496e-8b4f-a29c97954808@suse.de>

On Tue, Jun 11, 2024 at 11:29:58AM +0200, Thomas Zimmermann wrote:
> Hi
> 
> Am 11.06.24 um 10:23 schrieb Peng Fan:
> > > Subject: Re: [PATCH] drm/fbdev-dma: fix getting smem_start
> > > 
> > > Hi
> > > 
> > > Am 11.06.24 um 03:00 schrieb Peng Fan:
> > > > > Subject: Re: [PATCH] drm/fbdev-dma: fix getting smem_start
> > > > > 
> > > > > Hi
> > > > > 
> > > > > Am 04.06.24 um 10:03 schrieb Peng Fan (OSS):
> > > > > > From: Peng Fan <peng.fan@nxp.com>
> > > > > > 
> > > > > > If 'info->screen_buffer' locates in vmalloc address space,
> > > > > > virt_to_page will not be able to get correct results. With
> > > > > > CONFIG_DEBUG_VM and CONFIG_DEBUG_VIRTUAL enabled on ARM64,
> > > > > there is dump below:
> > > > > 
> > > > > Which graphics driver triggers this bug?
> > > > It is NXP i.MX95 DPU driver which is still in NXP downstream repo.
> > > Which DRM memory manager does that driver use?
> > DRM_GEM_DMA_DRIVER_OPS
> 
> So fbdev-dma would be correct. But with the gem-dma allocator, wouldn't you
> allocate from one of these dma_alloc_() calls at [1] ? How does the drivers
> end up with vmalloc'd fbdev memory? Specifically in the light of the docs at
> [2].

I think when you have an iommu dma_alloc just allocates pages, and uses
the iommu to make it all contiguous for the device, and vmalloc for the
kernel. So it's not allocated with vmalloc(), just ends up getting mapped
into the vmalloc range.
-Sima


> 
> [1] https://elixir.bootlin.com/linux/v6.9/source/drivers/gpu/drm/drm_gem_dma_helper.c#L146
> [2] https://elixir.bootlin.com/linux/v6.9/source/Documentation/core-api/dma-api-howto.rst#L124
> 
> Best regards
> Thomas
> 
> > 
> > > I'm asking because if the driver allocates BOs via vmalloc(), should it really
> > > use fbdev-dma?
> > We use it for fbdev emulation. If drm_kms_helper.fbdev_emulation is 0,
> > fbdev emulation could be disabled.
> > 
> > Thanks
> > Peng
> > > Best regards
> > > Thomas
> > > 
> > > > Thanks,
> > > > Peng.
> > > --
> > > --
> > > Thomas Zimmermann
> > > Graphics Driver Developer
> > > SUSE Software Solutions Germany GmbH
> > > Frankenstrasse 146, 90461 Nuernberg, Germany
> > > GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman HRB
> > > 36809 (AG Nuernberg)
> 
> -- 
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Frankenstrasse 146, 90461 Nuernberg, Germany
> GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
> HRB 36809 (AG Nuernberg)
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch