linux-kernel - Re: [PATCH v4 3/8] mailbox: mtk-cmdq: Add driver data to support for MT8196

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] [day] [month] [year] [list]

Message-ID: <219a0c8d675cf52298a8d3e542764206480598ca.camel@mediatek.com>
Date: Sat, 22 Feb 2025 10:44:42 +0000
From: Jason-JH Lin (林睿祥) <Jason-JH.Lin@...iatek.com>
To: "chunkuang.hu@...nel.org" <chunkuang.hu@...nel.org>, "AngeloGioacchino Del
 Regno" <angelogioacchino.delregno@...labora.com>, "robh@...nel.org"
	<robh@...nel.org>, "krzk+dt@...nel.org" <krzk+dt@...nel.org>,
	"jassisinghbrar@...il.com" <jassisinghbrar@...il.com>, "mchehab@...nel.org"
	<mchehab@...nel.org>, "conor+dt@...nel.org" <conor+dt@...nel.org>,
	CK Hu (胡俊光) <ck.hu@...iatek.com>
CC: "linux-media@...r.kernel.org" <linux-media@...r.kernel.org>,
	Sirius Wang (王皓昱) <Sirius.Wang@...iatek.com>,
	Nancy Lin (林欣螢) <Nancy.Lin@...iatek.com>,
	Xiandong Wang (王先冬)
	<Xiandong.Wang@...iatek.com>, "linux-mediatek@...ts.infradead.org"
	<linux-mediatek@...ts.infradead.org>, Project_Global_Chrome_Upstream_Group
	<Project_Global_Chrome_Upstream_Group@...iatek.com>,
	"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
	Moudy Ho (何宗原) <Moudy.Ho@...iatek.com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"fshao@...omium.org" <fshao@...omium.org>,
	Singo Chang (張興國) <Singo.Chang@...iatek.com>,
	"linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>,
	Xavier Chang (張獻文) <Xavier.Chang@...iatek.com>,
	"matthias.bgg@...il.com" <matthias.bgg@...il.com>, "treapking@...omium.org"
	<treapking@...omium.org>
Subject: Re: [PATCH v4 3/8] mailbox: mtk-cmdq: Add driver data to support for
 MT8196

Hi CK,

Thanks for the reviews.

On Tue, 2025-02-18 at 09:25 +0000, CK Hu (胡俊光) wrote:
> On Tue, 2025-02-18 at 13:41 +0800, Jason-JH Lin wrote:
> > MT8196 has 3 new hardware configuration compared with the previous
> > SoC,
> > which correspond to the 3 new driver data:
> > 
> > 1. mminfra_offset: For GCE data plane control
> >    Since GCE has been moved into mminfra, GCE needs to append the
> >    mminfra offset to the DRAM address when accessing the DRAM.
> 
> It seems that GCE has iova and mminfra would mapping the iova to
> physical address.
> Maybe let GCE be a iommu device or add iommus property in device
> node, and use dma_map_xxx() to get iova of GCE.
> iommus property point to mminfra device (maybe another name) and
> mminfra device would process the mapping of iova and physical
> address.

The GCE in the 8196 is using IOVA already.

The main reason of adding the mminfra_offset 0x8000_0000(2G) is to
solve the address conflicting problem:
Due to MMIO, if the GCE needs to access a hardware register at
0x1000_0000, but the SMMU is also mapping a DRAM block at 0x1000_0000,
the GCE will not know whether it should write to the hardware register
or the DRAM.
Therefore, a rule was set in the MMINFRA circuit during the HW design:
transactions with addresses greater than 2G are considered data paths,
while those with addresses less than 2G are considered config paths.
Additionally, on the data path, addresses are remapped by subtracting
2G, allowing the SMMU to still map DRAM addresses less than 2G.
However, the software needs to add 2G to the DRAM address that
the GCE needs to access to ensure that MMINFRA will follow the data
path.

Since the MMINFRA remap subtracting 2G is done in the hardware circuit
and cannot be configured by software, the address +2G adjustment is
implemented in the CMDQ driver.

> 
> > 
> > 2. gce_vm: For GCE hardware virtualization
> >    Currently, the first version of the mt8196 mailbox controller
> > only
> >    requires setting the VM-related registers to enable the
> > permissions
> >    of a host VM.
> 
> What's this? I know this patch would not implement the full VM
> function,
> but describe more about what this is. Why need to enable permission?
> 

OK I'll add the commit message below in the next version:

For the 8196, it is necessary to configure access permissions for
specific GCE threads for different VMs in order to properly access the
GCE thread registers.
Currently, since only the host VM is being used, it is required to
enable access permissions for all GCE threads for the host VM.

VM_MAP0 is for threads 0-9, VM_MAP1 is for threads 10-19, VM_MAP2 is
for threads 20-29, and VM_MAP3 is for threads 30-31. Each thread has a
3-bit configuration, and setting all bits to 1 means the thread is
configured for the host VM.

Regards,
Jason-JH Lin

> Regards,
> CK
>