linux-kernel - Re: [PATCH v3 5/5] drm/etnaviv: add HWDB entry for VIPNano-QI.7120.0055

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: <ce69ab2c95e500ab94ab9ebc186c351a605ada89.camel@pengutronix.de>
Date:   Tue, 29 Nov 2022 10:21:33 +0100
From:   Lucas Stach <l.stach@...gutronix.de>
To:     Tomeu Vizoso <tomeu.vizoso@...labora.com>
Cc:     italonicola@...labora.com,
        "moderated list:DRM DRIVERS FOR VIVANTE GPU IP" 
        <etnaviv@...ts.freedesktop.org>,
        "open list:DRM DRIVERS FOR VIVANTE GPU IP" 
        <dri-devel@...ts.freedesktop.org>,
        open list <linux-kernel@...r.kernel.org>,
        Christian Gmeiner <christian.gmeiner@...il.com>,
        Daniel Vetter <daniel@...ll.ch>,
        Russell King <linux+etnaviv@...linux.org.uk>,
        David Airlie <airlied@...il.com>
Subject: Re: [PATCH v3 5/5] drm/etnaviv: add HWDB entry for
 VIPNano-QI.7120.0055

Hi Tomeu,

Am Dienstag, dem 29.11.2022 um 09:50 +0100 schrieb Tomeu Vizoso:
> This is a compute-only module marketed towards AI and vision
> acceleration. This particular version can be found on the Amlogic A311D
> SoC.
> 
> The feature bits are taken from the Khadas downstream kernel driver
> 6.4.4.3.310723AAA.
> 
Since the downstream driver uses NNCoreCount or the TP_Engine feature
bit to tell if a core is a NPU, I think we should add the NNCoreCount
field to the HWDB to be able to do the same.

Also I would like to see a notice printed into the kernel log that we
instantiated the driver on a NPU core and show it as experimental, as
I'm not sure if our UAPI covers all things that are needed for NPU
operation. I wouldn't want to break our basic assumption that the
kernel driver is in charge of cleaning write caches when switching
contexts and event management, which might require some UAPI additions
to work with the NPU accelerator programming model.

Regards,
Lucas

> Signed-off-by: Tomeu Vizoso <tomeu.vizoso@...labora.com>
> ---
>  drivers/gpu/drm/etnaviv/etnaviv_hwdb.c | 31 ++++++++++++++++++++++++++
>  1 file changed, 31 insertions(+)
> 
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_hwdb.c b/drivers/gpu/drm/etnaviv/etnaviv_hwdb.c
> index f2fc645c7956..3f6fd9a3c088 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_hwdb.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_hwdb.c
> @@ -130,6 +130,37 @@ static const struct etnaviv_chip_identity etnaviv_chip_identities[] = {
>  		.minor_features10 = 0x90044250,
>  		.minor_features11 = 0x00000024,
>  	},
> +	{
> +		.model = 0x8000,
> +		.revision = 0x7120,
> +		.product_id = 0x45080009,
> +		.customer_id = 0x88,
> +		.eco_id = 0,
> +		.stream_count = 8,
> +		.register_max = 64,
> +		.thread_count = 256,
> +		.shader_core_count = 1,
> +		.vertex_cache_size = 16,
> +		.vertex_output_buffer_size = 1024,
> +		.pixel_pipes = 1,
> +		.instruction_count = 512,
> +		.num_constants = 320,
> +		.buffer_size = 0,
> +		.varyings_count = 16,
> +		.features = 0xe0287cac,
> +		.minor_features0 = 0xc1799eff,
> +		.minor_features1 = 0xfefbfadb,
> +		.minor_features2 = 0xeb9d6fbf,
> +		.minor_features3 = 0xedfffced,
> +		.minor_features4 = 0xd30dafc7,
> +		.minor_features5 = 0x7b5ac333,
> +		.minor_features6 = 0xfc8ee200,
> +		.minor_features7 = 0x03fffa6f,
> +		.minor_features8 = 0x00fe0ef0,
> +		.minor_features9 = 0x0088003c,
> +		.minor_features10 = 0x108048c0,
> +		.minor_features11 = 0x00000010,
> +	},
>  };
>  
>  bool etnaviv_fill_identity_from_hwdb(struct etnaviv_gpu *gpu)