[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <209a99c3-6d44-4abc-a486-8e6d0a0c7370@suse.de>
Date: Thu, 13 Jun 2024 12:18:55 +0200
From: Thomas Zimmermann <tzimmermann@...e.de>
To: Javier Martinez Canillas <javierm@...hat.com>,
"Peng Fan (OSS)" <peng.fan@....nxp.com>,
Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
Maxime Ripard <mripard@...nel.org>, David Airlie <airlied@...il.com>,
Peng Fan <peng.fan@....com>, dri-devel@...ts.freedesktop.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] drm/fbdev-dma: fix getting smem_start
Hi
Am 13.06.24 um 12:14 schrieb Thomas Zimmermann:
> Hi
>
> Am 12.06.24 um 17:00 schrieb Daniel Vetter:
>> On Wed, Jun 12, 2024 at 10:37:14AM +0200, Thomas Zimmermann wrote:
>>> Hi Javier
>>>
>>> Am 12.06.24 um 09:49 schrieb Javier Martinez Canillas:
>>>> Thomas Zimmermann <tzimmermann@...e.de> writes:
>>>>
>>>> Hello Thomas,
>>>>
>>>>> Hi
>>>>>
>>>>> Am 10.06.24 um 10:47 schrieb Thomas Zimmermann:
>>>>>> Hi
>>>>>>
>>>>>> Am 04.06.24 um 10:03 schrieb Peng Fan (OSS):
>>>>>>> From: Peng Fan <peng.fan@....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?
>>>>>>
>>>>>>> [ 3.536043] ------------[ cut here ]------------
>>>>>>> [ 3.540716] virt_to_phys used for non-linear address:
>>>>>>> 000000007fc4f540 (0xffff800086001000)
>>>>>>> [ 3.552628] WARNING: CPU: 4 PID: 61 at
>>>>>>> arch/arm64/mm/physaddr.c:12
>>>>>>> __virt_to_phys+0x68/0x98
>>>>>>> [ 3.565455] Modules linked in:
>>>>>>> [ 3.568525] CPU: 4 PID: 61 Comm: kworker/u12:5 Not tainted
>>>>>>> 6.6.23-06226-g4986cc3e1b75-dirty #250
>>>>>>> [ 3.577310] Hardware name: NXP i.MX95 19X19 board (DT)
>>>>>>> [ 3.582452] Workqueue: events_unbound deferred_probe_work_func
>>>>>>> [ 3.588291] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT
>>>>>>> -SSBS
>>>>>>> BTYPE=--)
>>>>>>> [ 3.595233] pc : __virt_to_phys+0x68/0x98
>>>>>>> [ 3.599246] lr : __virt_to_phys+0x68/0x98
>>>>>>> [ 3.603276] sp : ffff800083603990
>>>>>>> [ 3.677939] Call trace:
>>>>>>> [ 3.680393] __virt_to_phys+0x68/0x98
>>>>>>> [ 3.684067] drm_fbdev_dma_helper_fb_probe+0x138/0x238
>>>>>>> [ 3.689214]
>>>>>>> __drm_fb_helper_initial_config_and_unlock+0x2b0/0x4c0
>>>>>>> [ 3.695385] drm_fb_helper_initial_config+0x4c/0x68
>>>>>>> [ 3.700264] drm_fbdev_dma_client_hotplug+0x8c/0xe0
>>>>>>> [ 3.705161] drm_client_register+0x60/0xb0
>>>>>>> [ 3.709269] drm_fbdev_dma_setup+0x94/0x148
>>>>>>>
>>>>>>> So add a check 'is_vmalloc_addr'.
>>>>>>>
>>>>>>> Fixes: b79fe9abd58b ("drm/fbdev-dma: Implement fbdev emulation for
>>>>>>> GEM DMA helpers")
>>>>>>> Signed-off-by: Peng Fan <peng.fan@....com>
>>>>>> Reviewed-by: Thomas Zimmermann <tzimmermann@...e.de>
>>>>> I'm taking back my r-b. The memory is expected to by be physically
>>>>> contiguous and vmalloc() won't guarantee that.
>>>>>
>>>> Agreed.
>>> These smem_ fields are clearly designed for PCI BARs of traditional
>>> graphics
>>> cards. So can we even assume contiguous memory for DMA? That was my
>>> assumption, but with IOMMUs it might not be the case. Fbdev-dma only
>>> sets
>>> smem_start to support a single old userspace driver. Maybe we should
>>> further
>>> restrict usage of this field by making it opt-in for each driver. Best
>>> regards Thomas
>> We could make it all conditional on CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM, and
>> remove the FBINFO_HIDE_SMEM_START flag. The reason I've done the flag is
>> that with the old fb_mmap code we had to always fill out smem_start to
>> make mmap work. But now that the various drm fbdev helpers have all
>> their
>> own mmap implementation, we could make this a lot cleaner.
>
> Enabling CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM would still crash the NXP
> driver. I think I'll add a flag to drm_fbdev_dma_setup() to set
> smem_start from within lima, which is the only driver that requires
> it.I'd like to remove CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM and all that,
> but I fear that it would break someone's setup. Best regards Thomas
I've been looking at
https://lore.kernel.org/dri-devel/20240318-dark-mongoose-of-camouflage-7ac6ed@houat/
and I'm now confused to find that lima doesn't even set up fbdev support.
Best regards
Thomas
>>
>> If I haven't missed anything, that is.
>> -Sima
>
--
--
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)
Powered by blists - more mailing lists