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@xxxxxxx> 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@xxxxxxx>
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@xxxxxxx>
Reviewed-by: Thomas Zimmermann <tzimmermann@xxxxxxx>
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)
