All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Zimmermann <tzimmermann@suse.de>
To: 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>
Subject: Re: [PATCH] drm/fbdev-dma: fix getting smem_start
Date: Wed, 12 Jun 2024 15:03:41 +0200	[thread overview]
Message-ID: <605bf442-41f9-49d9-a4b7-e889ff800734@suse.de> (raw)
In-Reply-To: <ZmlgQV4Eov0xv5bc@phenom.ffwll.local>

Hi

Am 12.06.24 um 10:45 schrieb Daniel Vetter:
> 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.

Thanks, that makes sense. As I mentioned in another reply, it might make 
sense to protect smem_start with an opt-in flag for only that single 
driver that needs it.

Best regards
Thomas

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

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


  reply	other threads:[~2024-06-12 13:03 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-04  8:03 [PATCH] drm/fbdev-dma: fix getting smem_start Peng Fan (OSS)
2024-06-10  8:47 ` Thomas Zimmermann
2024-06-11  1:00   ` Peng Fan
2024-06-11  7:50     ` Thomas Zimmermann
2024-06-11  8:23       ` Peng Fan
2024-06-11  9:29         ` Thomas Zimmermann
2024-06-12  8:45           ` Daniel Vetter
2024-06-12 13:03             ` Thomas Zimmermann [this message]
2024-06-12  6:48   ` Thomas Zimmermann
2024-06-12  7:49     ` Javier Martinez Canillas
2024-06-12  8:37       ` Thomas Zimmermann
2024-06-12 15:00         ` Daniel Vetter
2024-06-13 10:14           ` Thomas Zimmermann
2024-06-13 10:18             ` Thomas Zimmermann
2024-06-17 14:04               ` Daniel Vetter
2024-06-17 14:26                 ` Thomas Zimmermann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=605bf442-41f9-49d9-a4b7-e889ff800734@suse.de \
    --to=tzimmermann@suse.de \
    --cc=airlied@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=javierm@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mripard@kernel.org \
    --cc=peng.fan@nxp.com \
    --cc=peng.fan@oss.nxp.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.