[PATCH] drm/fbdev-dma: fix getting smem_start

[Thomas Zimmermann]

Hi

Am 17.06.24 um 16:04 schrieb Daniel Vetter:
> On Thu, Jun 13, 2024 at 12:18:55PM +0200, Thomas Zimmermann wrote:
>> 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 at suse.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 at 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?
>>>>>>>>
>>>>>>>>> [    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 at nxp.com>
>>>>>>>> Reviewed-by: Thomas Zimmermann <tzimmermann at suse.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
> Yeah we'd always need to make this conditional on the memory not being in
> the vmalloc range, or things will blow up.
>
>> 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.
> The mali driver here was the out-of-tree proprietary mali driver as the
> consumer of such buffers.
>
> The "exporters" was just any random fbdev driver, and with the DRM option
> to set the smem, also drm drivers could play in this role. It at least
> seems to have helped a few people to move away from out-of-tree fbdev
> drivers to upstream drm drivers (but still with the out-of-tree mali gpu
> driver). Which means we've needed this for any display driver that
> happens to have shipped together with one of these older mali gpus.
>
> It's a bit a mess, and it might indeed have outlived it's usefulness.

Thanks a lot for explaining. Sounds like the kind of workaround that is 
almost impossible to remove.

Let me send out a patch that connects the setting in fbdev-dma to the 
drm_leak_fbdev_smem parameter. At least fbdev-dma won't try to set 
smem_start unnecessarily.


Best regards
Thomas

>
> Cheers, 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)