From: Sui Jingfeng <sui.jingfeng@linux.dev>
To: "Wang, Xiaolei" <Xiaolei.Wang@windriver.com>,
"l.stach@pengutronix.de" <l.stach@pengutronix.de>,
"linux+etnaviv@armlinux.org.uk" <linux+etnaviv@armlinux.org.uk>,
"christian.gmeiner@gmail.com" <christian.gmeiner@gmail.com>,
"airlied@gmail.com" <airlied@gmail.com>,
"daniel@ffwll.ch" <daniel@ffwll.ch>
Cc: "etnaviv@lists.freedesktop.org" <etnaviv@lists.freedesktop.org>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [v2] drm/etnaviv: Clear the __GFP_HIGHMEM bit in GFP_HIGHUSER with 32 address
Date: Sat, 31 Aug 2024 05:03:01 +0800 [thread overview]
Message-ID: <e0d206be-7ad1-4b80-9f58-88eb0cf1ce74@linux.dev> (raw)
In-Reply-To: <MW5PR11MB57648F441CEDD36E614E31EA95812@MW5PR11MB5764.namprd11.prod.outlook.com>
Hi, Xiaolei
Thanks for your nice catch! I have more to say.
On 2024/8/16 09:55, Wang, Xiaolei wrote:
> Ping ...
32 address -> 32-bit address,
Perhaps, we could improve the commit title a little bit
by writing a more accurate sentence if possible, say:
drm/etnaviv: Properly request pages from DMA32 zone when needed
or
drm/etnaviv: Request pages from DMA32 zone on addressing_limited
> thanks
> xiaolei
Vivante GPU is a 32-bit GPU, it do can access 40-bit physical address via its MMU(IOMMU).
But this is only possible *after* the MMU has been setup(initialized). Before GPU page
table is setup(and flush-ed into the GPU's TLB), the device can only access 32-bit
physical addresses and the addresses has to be physical continues in ranges.
The GPU page tables (GART) and command buffer has to reside in low 4GB address.
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> index 7c7f97793ddd..0e6bdf2d028b 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> @@ -844,8 +844,10 @@ int etnaviv_gpu_init(struct etnaviv_gpu *gpu)
> * request pages for our SHM backend buffers from the DMA32 zone to
> * hopefully avoid performance killing SWIOTLB bounce buffering.
> */
> - if (dma_addressing_limited(gpu->dev))
> + if (dma_addressing_limited(gpu->dev)) {
> priv->shm_gfp_mask |= GFP_DMA32;
> + priv->shm_gfp_mask &= ~__GFP_HIGHMEM;
> + }
The code here still looks itchy and risky,
because for a i.MX8 SoC with multiple vivante GPU core.
We will modify priv->shm_gfp_mask *multiple* time.
For the 2D core and the 3D core have different DMA addressing constraint.
Then, only the last(latest) modify will be effective. This lead to the
probe order dependent.
However this may not be a problem in practice, as usually, all vivante
GPUs in the system will share the same DMA constraints. And the driver
assume that.
But then, we probably still should not modify the global shared GFP
mask multiple time.
Now that we do assume that all vivante GPUs in the system share the
same DMA constraints. And the DMA constraints information has been
assigned to the virtual master. The right time to modify the
`priv->shm_gfp_mask` should be in the etnaviv_bind() function. as
this can eliminate overlap(repeat) stores.
Please consider move the entire if() {} to etnaviv_bind(), just below
where the 'priv->shm_gfp_mask' was initially initialized.
or alternatively we can just hard-code to use low 4GM memmory only:
priv->shm_gfp_mask = GFP_USER | GFP_DMA32 | __GFP_RETRY_MAYFAIL | __GFP_NOWARN;
Best regards,
Sui
> /* Create buffer: */
> ret = etnaviv_cmdbuf_init(priv->cmdbuf_suballoc, &gpu->buffer,
next prev parent reply other threads:[~2024-08-30 21:03 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <MW5PR11MB57648F441CEDD36E614E31EA95812@MW5PR11MB5764.namprd11.prod.outlook.com>
2024-08-30 19:40 ` [v2] drm/etnaviv: Clear the __GFP_HIGHMEM bit in GFP_HIGHUSER with 32 address Sui Jingfeng
2024-08-30 19:48 ` Sui Jingfeng
2024-08-30 21:03 ` Sui Jingfeng [this message]
2024-09-03 1:00 ` wang xiaolei
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=e0d206be-7ad1-4b80-9f58-88eb0cf1ce74@linux.dev \
--to=sui.jingfeng@linux.dev \
--cc=Xiaolei.Wang@windriver.com \
--cc=airlied@gmail.com \
--cc=christian.gmeiner@gmail.com \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=etnaviv@lists.freedesktop.org \
--cc=l.stach@pengutronix.de \
--cc=linux+etnaviv@armlinux.org.uk \
--cc=linux-kernel@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox