mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Robin Murphy <robin.murphy@arm.com>
To: Andy Yan <andyshrk@163.com>, heiko@sntech.de
Cc: hjc@rock-chips.com, krzk+dt@kernel.org, robh@kernel.org,
	conor+dt@kernel.org, s.hauer@pengutronix.de,
	devicetree@vger.kernel.org, dri-devel@lists.freedesktop.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-rockchip@lists.infradead.org,
	derek.foreman@collabora.com, minhuadotchen@gmail.com,
	detlev.casanova@collabora.com, Andy Yan <andy.yan@rock-chips.com>
Subject: Re: [PATCH v3 02/15] drm/rockchip: Set dma mask to 64 bit
Date: Wed, 16 Oct 2024 18:38:23 +0100	[thread overview]
Message-ID: <b5e89288-d1c9-4c10-91b3-b1351b623ce6@arm.com> (raw)
In-Reply-To: <20240920082036.6623-1-andyshrk@163.com>

On 2024-09-20 9:20 am, Andy Yan wrote:
> From: Andy Yan <andy.yan@rock-chips.com>
> 
> The vop mmu support translate physical address upper 4 GB to iova
> below 4 GB. So set dma mask to 64 bit to indicate we support address
>> 4GB.
> 
> This can avoid warnging message like this on some boards with DDR
>> 4 GB:
> 
> rockchip-drm display-subsystem: swiotlb buffer is full (sz: 266240 bytes), total 32768 (slots), used 130 (slots)
> rockchip-drm display-subsystem: swiotlb buffer is full (sz: 266240 bytes), total 32768 (slots), used 0 (slots)
> rockchip-drm display-subsystem: swiotlb buffer is full (sz: 266240 bytes), total 32768 (slots), used 130 (slots)
> rockchip-drm display-subsystem: swiotlb buffer is full (sz: 266240 bytes), total 32768 (slots), used 130 (slots)
> rockchip-drm display-subsystem: swiotlb buffer is full (sz: 266240 bytes), total 32768 (slots), used 0 (slots)

There are several things wrong with this...

AFAICS the VOP itself still only supports 32-bit addresses, so the VOP 
driver should only be setting a 32-bit DMA mask. The IOMMUs support 
either 32-bit or 40-bit addresses, and the IOMMU driver does set its DMA 
mask appropriately. None of those numbers is 64, so that's clearly 
suspicious already. Plus it would seem the claim of the IOMMU being able 
to address >4GB isn't strictly true for RK3288 (which does supposedly 
support 8GB of RAM).

Furthermore, the "display-subsystem" doesn't even exist - it does not 
represent any actual DMA-capable hardware, so it should not have a DMA 
mask, and it should not be used for DMA API operations. Buffers for the 
VOP should be DMA-mapped for the VOP device itself. At the very least, 
the rockchip_gem_alloc_dma() path is clearly broken otherwise (I guess 
this patch possibly *would* make that brokenness apparent).

> Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
> Tested-by: Derek Foreman <derek.foreman@collabora.com>
> ---
> 
> (no changes since v1)
> 
>   drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 4 +++-
>   1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> index 04ef7a2c3833..8bc2ff3b04bb 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> @@ -445,7 +445,9 @@ static int rockchip_drm_platform_probe(struct platform_device *pdev)
>   		return ret;
>   	}
>   
> -	return 0;
> +	ret = dma_coerce_mask_and_coherent(dev, DMA_BIT_MASK(64));

Finally as a general thing, please don't misuse 
dma_coerce_mask_and_coherent() in platform drivers, just use normal 
dma_set_mask_and_coherent(). The platform bus code has been initialising 
the dev->dma_mask pointer for years now, drivers should not be messing 
with it any more.

Thanks,
Robin.

> +
> +	return ret;
>   }
>   
>   static void rockchip_drm_platform_remove(struct platform_device *pdev)


  reply	other threads:[~2024-10-16 17:38 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-20  8:16 [PATCH v3 00/15] VOP Support for rk3576 Andy Yan
2024-09-20  8:20 ` [PATCH v3 01/15] drm/rockchip: vop2: Add debugfs support Andy Yan
2024-09-20  8:20 ` [PATCH v3 02/15] drm/rockchip: Set dma mask to 64 bit Andy Yan
2024-10-16 17:38   ` Robin Murphy [this message]
2024-10-17  7:06     ` Andy Yan
2024-10-17  8:58       ` Jonas Karlman
2024-09-20  8:20 ` [PATCH v3 03/15] drm/rockchip: vop2: Fix cluster windows alpha ctrl regsiters offset Andy Yan
2024-09-20  8:20 ` [PATCH v3 04/15] drm/rockchip: vop2: Fix the mixer alpha setup for layer 0 Andy Yan
2024-09-20  8:21 ` [PATCH v3 05/15] drm/rockchip: vop2: Fix the windows switch between different layers Andy Yan
2024-09-20  8:21 ` [PATCH v3 06/15] drm/rockchip: vop2: include rockchip_drm_drv.h Andy Yan
2024-09-22 10:20   ` Min-Hua Chen
2024-09-22 10:33   ` Diederik de Haas
2024-09-22 10:50     ` Min-Hua Chen
2024-09-20  8:21 ` [PATCH v3 07/15] drm/rockchip: vop2: Support 32x8 superblock afbc Andy Yan
2024-09-20  8:21 ` [PATCH v3 08/15] drm/rockchip: vop2: Add platform specific callback Andy Yan
2024-09-20  8:21 ` [PATCH v3 09/15] drm/rockchip: vop2: Support for different layer selet configuration between VPs Andy Yan
2024-09-20  8:22 ` [PATCH v3 10/15] drm/rockchip: vop2: Introduce vop hardware version Andy Yan
2024-09-20  8:22 ` [PATCH v3 11/15] drm/rockchip: vop2: Register the primary plane and overlay plane separately Andy Yan
2024-09-20  8:22 ` [PATCH v3 12/15] drm/rockchip: vop2: Set plane possible crtcs by possible vp mask Andy Yan
2024-09-20  8:22 ` [PATCH v3 13/15] drm/rockchip: vop2: Add uv swap for cluster window Andy Yan
2024-09-20  8:23 ` [PATCH v3 14/15] dt-bindings: display: vop2: Add rk3576 support Andy Yan
2024-09-22 21:05   ` Krzysztof Kozlowski
2024-09-20  8:23 ` [PATCH v3 15/15] drm/rockchip: vop2: Add support for rk3576 Andy Yan
2024-09-24  9:34 ` [PATCH v3 00/15] VOP Support " Michael Riesch
2024-09-25  9:54   ` Andy Yan
2024-09-30 19:32 ` Detlev Casanova

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=b5e89288-d1c9-4c10-91b3-b1351b623ce6@arm.com \
    --to=robin.murphy@arm.com \
    --cc=andy.yan@rock-chips.com \
    --cc=andyshrk@163.com \
    --cc=conor+dt@kernel.org \
    --cc=derek.foreman@collabora.com \
    --cc=detlev.casanova@collabora.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=heiko@sntech.de \
    --cc=hjc@rock-chips.com \
    --cc=krzk+dt@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=minhuadotchen@gmail.com \
    --cc=robh@kernel.org \
    --cc=s.hauer@pengutronix.de \
    /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

all inboxes | Powered by JetHome®