lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3fe0e553-ac73-0d97-4404-c597fd4993a0@arm.com>
Date:   Thu, 1 Jul 2021 11:15:14 +0100
From:   Steven Price <steven.price@....com>
To:     Chunyou Tang <tangchunyou@....com>
Cc:     tomeu.vizoso@...labora.com, airlied@...ux.ie,
        linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
        alyssa.rosenzweig@...labora.com,
        ChunyouTang <tangchunyou@...becorp.cn>
Subject: Re: [PATCH v2] drm/panfrost:report the full raw fault information
 instead

On 29/06/2021 04:04, Chunyou Tang wrote:
> Hi Steve,
> 	thinks for your reply.
> 	I set the pte in arm_lpae_prot_to_pte(),
> ***********************************************************************
> 	/*
> 	 * Also Mali has its own notions of shareability wherein its
> Inner
> 	 * domain covers the cores within the GPU, and its Outer domain
> is
> 	 * "outside the GPU" (i.e. either the Inner or System domain in
> CPU
> 	 * terms, depending on coherency).
> 	 */
> 	if (prot & IOMMU_CACHE && data->iop.fmt != ARM_MALI_LPAE)
> 		pte |= ARM_LPAE_PTE_SH_IS;
> 	else
> 		pte |= ARM_LPAE_PTE_SH_OS;
> ***********************************************************************
> I set pte |= ARM_LPAE_PTE_SH_NS.
> 
> 	If I set pte to ARM_LPAE_PTE_SH_OS or
> 	ARM_LPAE_PTE_SH_IS,whether I use singel core GPU or multi core
> 	GPU,it will occur GPU Fault.
> 	if I set pte to ARM_LPAE_PTE_SH_NS,whether I use singel core
> 	GPU or multi core GPU,it will not occur GPU Fault.

Hi,

So this is a difference between Panfrost and kbase. Panfrost (well
technically the IOMMU framework) enables the inner-shareable bit for all
memory, whereas kbase only enables it for some memory types (the
BASE_MEM_COHERENT_LOCAL flag in the UABI controls it). However this
should only be a performance/power difference (and AFAIK probably an
irrelevant one) and it's definitely required that "inner shareable"
(i.e. within the GPU) works for communication between the different
units of the GPU.

You didn't answer my previous question:

> Is this device working with the kbase/DDK proprietary driver?

What you are describing sounds like a hardware integration issue, so it
would be good to check that the hardware is working with the proprietary
driver to rule that out. And perhaps there is something in the kbase for
this device that is setting a chicken bit to 'fix' the coherency?

Steve

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ