ssume that a NULL domain means no
DMA IOMMU").
Fixes: c8cc2655cc6c ("iommu/tegra-smmu: Implement an IDENTITY domain")
Reported-by: Diogo Ivo
Closes:
https://lore.kernel.org/all/c6a6f114-3acd-4d56-a13b-b88978e92...@tecnico.ulisboa.pt/
Tested-by: Diogo Ivo
Signed-off-by: Jason Gu
On Tue, Feb 04, 2025 at 03:29:48PM +0100, Thomas Hellström wrote:
> On Tue, 2025-02-04 at 09:26 -0400, Jason Gunthorpe wrote:
> > On Tue, Feb 04, 2025 at 10:32:32AM +0100, Thomas Hellström wrote:
> > >
> >
> > > 1) Existing users would never use the callb
pcie_p2p is already planning a dev_pagemap callback?
Yes, but it is not a racy validation callback, and it already is
creating a complicated lifecycle problem inside the exporting the
driver.
Jason
er or so as Thomas suggested).
Neither really match the expected design here. The owner should be
entirely based on reachability. Devices that cannot reach each other
directly should have different owners.
> But upfront speccing all this out doesn't seem like a good idea to,
> because I honestly don't know what we all need.
This is why it is currently just void *owner :)
Jason
ase for hardware access. So some access will go to nowhere
> when that happens, until we've torn down all the mappings and migrated
> memory out.
I think a literal (safe!) hot unplug must always use the page map
revoke, and that should be safely locked between hmm_range_fault and
the notifier.
If the underlying fabric is loosing operations during an unplanned hot
unplug I expect things will need resets to recover..
Jason
sn't treated very special.
I'm not sure it is meaningful, but in principle a driver could keep
track of the poisoned private memory using that struct page
bit. Perhaps in that sense it is more of a driver private flag than
something the core MM would touch.
If you have a coherent interconnect then you should not be using
device private.
Jason
On Thu, Jan 30, 2025 at 11:50:27AM +0100, Simona Vetter wrote:
> On Wed, Jan 29, 2025 at 09:47:57AM -0400, Jason Gunthorpe wrote:
> > On Wed, Jan 29, 2025 at 02:38:58PM +0100, Simona Vetter wrote:
> >
> > > > The pgmap->owner doesn't *have* to fixed, certainl
itable pages, toss it back to
> hmm_range_fault asking for an unconditional migration to system memory for
> those. But that's kinda not great and I think goes at least against the
> spirit of how you want to handle pci p2p in step 2 below?
Right, hmm_range_fault should return pages that can be used and you
should not call it twice.
Jason
try to use an interconnect-common owner
> for now and revisit the problem if that's not sufficient so we can come
> up with an acceptable solution.
That is the intention for sure. The idea was that the drivers under
the private pages would somehow generate unique owners for shared
private interconnect segments.
I wouldn't say this is the end all of the idea, if there are better
ways to handle accepting private pages they can certainly be
explored..
Jason
On Tue, Jan 28, 2025 at 03:48:54PM +0100, Thomas Hellström wrote:
> On Tue, 2025-01-28 at 09:20 -0400, Jason Gunthorpe wrote:
> > On Tue, Jan 28, 2025 at 09:51:52AM +0100, Thomas Hellström wrote:
> >
> > > How would the pgmap device know whether P2P is actually possible
&
mity I'd rather do it
directly in the core code than using a per-driver callback. Every
driver needs exactly the same logic for such a case.
Jason
reliably
is a reasonable goal.
Jason
>per-mapping properties?
Not fully yet (though some multipath is supported), but I want to
slowly move in this direction to solve all of these problems we
have :(
Jason
On Thu, Jan 23, 2025 at 03:35:21PM +0100, Christian König wrote:
> Sending it as text mail once more.
>
> Am 23.01.25 um 15:32 schrieb Christian König:
> > Am 23.01.25 um 14:59 schrieb Jason Gunthorpe:
> > > On Wed, Jan 22, 2025 at 03:59:11PM +0100, Christian König wrote:
the RDMA HW side. I can't do
those optimizations if I'm not in control of the mapping.
The same is probably true on the GPU side too, you want IOVAs that
have tidy alignment with your PTE structure, but only the importer
understands its own HW to make the correct hints to the DMA API.
Jason
7;s security architecture.
The entire flow needs to have options for drivers to be involved in
the flow, somehow.
Jason
ossible.
I remain skeptical of this.. Aside from all the technical reasons I
already outlined..
I think it is too much work to have the exporters conditionally build
all sorts of different representations of the same thing depending on
the importer. Like having alot of DRM drivers generate both a PFN and
DMA mapped list in their export code doesn't sound very appealing to
me at all.
It makes sense that a driver would be able to conditionally generate
private and generic based on negotiation, but IMHO, not more than one
flavour of generic..
Jason
u drivers, vmwgfx is
> fiddling around with these bits (at least last I tried to understand this
> all) and I think a few others do too.
IMHO, most places I've seen touching this out side arch code feel very
hacky. :\
Jason
On Wed, Jan 22, 2025 at 12:32:56PM +0800, Xu Yilun wrote:
> On Tue, Jan 21, 2025 at 01:43:03PM -0400, Jason Gunthorpe wrote:
> > On Tue, Jun 25, 2024 at 05:12:10AM +0800, Xu Yilun wrote:
> >
> > > When VFIO works as a TEE user in VM, it means an attester (e.g. PCI
>
erstood is the target. :\
Jason
On Tue, Jan 21, 2025 at 05:11:32PM +0100, Simona Vetter wrote:
> On Mon, Jan 20, 2025 at 03:48:04PM -0400, Jason Gunthorpe wrote:
> > On Mon, Jan 20, 2025 at 07:50:23PM +0100, Simona Vetter wrote:
> > > On Mon, Jan 20, 2025 at 01:59:01PM -0400, Jason Gunthorpe wrote:
> >
On Mon, Jan 20, 2025 at 07:50:23PM +0100, Simona Vetter wrote:
> On Mon, Jan 20, 2025 at 01:59:01PM -0400, Jason Gunthorpe wrote:
> > On Mon, Jan 20, 2025 at 01:14:12PM +0100, Christian König wrote:
> > What is going wrong with your email? You replied to Simona, but
> > Simo
f using CPU pfns
through the non-scatterlist op.
8) Relevant GPU drivers implement the non-scatterlist op and RDMA
removes support for the deprecated scatterlist hacks.
Xu's series has jumped ahead a bit and is missing infrastructure to
build it properly.
Jason
is KVM business beyond
> IOMMUFD.
As in my other email, VFIO is not restricted to running VMs, useful
things should be available to apps like DPDK.
There is a use case for using TDISP and getting devices up into an
ecrypted/attested state on pure bare metal without any KVM, VFIO
should work in that use case too.
Jason
aged by TDX firmware.
> Now a SW Mirror Secure EPT is introduced in KVM and managed by KVM
> directly, and KVM will finally use firmware calls to propagate Mirror
> Secure EPT changes to secure EPT.
If the secure world managed it then the secure world can have rules
that work with the IOMMU as well..
Jason
On Fri, Jan 17, 2025 at 09:57:40AM +0800, Baolu Lu wrote:
> On 1/15/25 21:01, Jason Gunthorpe wrote:
> > On Wed, Jan 15, 2025 at 11:57:05PM +1100, Alexey Kardashevskiy wrote:
> > > On 15/1/25 00:35, Jason Gunthorpe wrote:
> > > > On Tue, Jun 18, 2024 at 07
the secure worlds are full VMs with all
the device emulation and more.
It CC is much more like xen with it's hypervisor and DOM0 concepts.
>From this perspective, the only thing that matters is that CC secure
memory is different and special - it is very much like your private
memory concept. Only special places that understand it and have the
right HW capability can use it. All the consumers need a CPU address
to program their HW because of how the secure world security works.
Jason
On Thu, Jan 16, 2025 at 06:33:48AM +0100, Christoph Hellwig wrote:
> On Wed, Jan 15, 2025 at 09:34:19AM -0400, Jason Gunthorpe wrote:
> > > Or do you mean some that don't have pages associated with them, and
> > > thus have pfn_valid fail on them? They still have a PFN,
s of doing digital rights management
>and content protection.
Well, that is TEE stuff, TEE and CC are not the same thing, though
they have some high level conceptual overlap.
In a certain sense CC is a TEE that is built using KVM instead of the
TEE subsystem. Using KVM and integrating with the MM brings a whole
set of unique challenges that TEE got to avoid..
Jason
etup what the mutual capability is. :\ swiotlb hides
> > some of this some times, but confidential P2P is currently unsolved.
>
> Yes and it is documented by now how that is supposed to happen with
> DMA-buf.
I doubt that. It is complex and not fully solved in the core code
today. Many scenarios do not work correctly, devices don't even exist
yet that can exercise the hard paths. This is a future problem :(
Jason
for holding it's private CPU memory.
This is about confidential MMIO memory.
This is also not just about the KVM side, the VM side also has issues
with DMABUF and CC - only co-operating devices can interact with the
VM side "encrypted" memory and there needs to be a negotiation as part
of all buffer setup what the mutual capability is. :\ swiotlb hides
some of this some times, but confidential P2P is currently unsolved.
Jason
On Wed, Jan 15, 2025 at 10:38:00AM +0100, Christian König wrote:
> Am 10.01.25 um 21:54 schrieb Jason Gunthorpe:
> > [SNIP]
> > > > I don't fully understand your use case, but I think it's quite likely
> > > > that we already have that working.
> >
ddress on the hidden interconnect. Somehow the
importer knows this has happened and programs its HW to use the
private path.
Jason
On Wed, Jan 15, 2025 at 11:57:05PM +1100, Alexey Kardashevskiy wrote:
> On 15/1/25 00:35, Jason Gunthorpe wrote:
> > On Tue, Jun 18, 2024 at 07:28:43AM +0800, Xu Yilun wrote:
> >
> > > > is needed so the secure world can prepare anything it needs prior to
> > >
lf defined within dmabuf and
kvm should adopt to it, move semantics and all.
My general desire is to move all of RDMA's MR process away from
scatterlist and work using only the new DMA API. This will save *huge*
amounts of memory in common workloads and be the basis for non-struct
page DMA support, including P2P.
Jason
entation is not to prepare as much as possible,
> but only necessary, so most of the secure work for vPCI function is done
> at late bind time.
That's fine too, but both options need to be valid.
Jason
need this, I'd be surprised if AMD actually doesn't in
the full scenario with secure viommu.
It should not be a surprise to the secure world after the VM has
started that suddenly it learns about a vPCI function that wants to be
secure. This should all be pre-arranged as possible before starting
the VM, even if alot of steps happen after the VM starts running (or
maybe don't happen at all).
Jason
re memory inside a FD entirely within the
kernel so that only an importer that understands how to handle secure
memory (such as KVM) is using it to avoid machine checking.
The patch series here should be thought of as the first part of this,
allowing PFNs to flow without VMAs. IMHO the second part of preventing
machine checks is not complete.
In the approach I have been talking about the secure memory would be
represented by a p2p_provider structure that is incompatible with
everything else. For instance importers that can only do DMA would
simply cleanly fail when presented with this memory.
Jason
CPU, etc and
would be efficient with the new DMA API.
This is similar to the structure BIO has, and it composes nicely with
a future pin_user_pages() and memfd_pin_folios().
Jason
t, &sg_iter, 0) {
dma_addr_t addr = sg_page_iter_dma_address(&sg_iter);
unsigned long pfn = bfn_to_pfn(XEN_PFN_DOWN(dma_to_phys(dev,
addr)));
*barf*
Can we please all agree that is a horrible abuse of the DMA API and
lets not point it as some acceptable "solution"? KVM and iommufd do
not have fake struct devices with fake iommus.
Jason
ryone.
> Yes. It carries out the idea of "KVM maps MMIO resources without firstly
> mapping into the host" even for normal VM. That's why I think it could
> be an independent patchset.
Yes, just remove this patch and other TDI focused stuff. Just
infrastructure to move to FD based mapping instead of VMA.
Jason
On Thu, Jan 09, 2025 at 12:57:58AM +0800, Xu Yilun wrote:
> On Wed, Jan 08, 2025 at 09:30:26AM -0400, Jason Gunthorpe wrote:
> > On Tue, Jan 07, 2025 at 10:27:15PM +0800, Xu Yilun wrote:
> > > Add a flag for ioctl(VFIO_DEVICE_BIND_IOMMUFD) to mark a device as
> > >
On Wed, Jan 08, 2025 at 04:25:54PM +0100, Christian König wrote:
> Am 08.01.25 um 15:58 schrieb Jason Gunthorpe:
> > On Wed, Jan 08, 2025 at 02:44:26PM +0100, Christian König wrote:
> >
> > > > Having the importer do the mapping is the correct way to operate the
>
e the exporter mapping
destroyed that information.
5) iommufd and kvm are both using CPU addresses without DMA. No
exporter mapping is possible
Jason
? Why does the kernel have
to enforce this?
Jason
pport
in dmabuf is like that principally because of this.
That said, I don't think get_pfn() is an especially good interface,
but we will need to come with something that passes the physical pfn
out.
Jason
On Mon, Jan 06, 2025 at 01:05:08PM +0100, Simona Vetter wrote:
> On Thu, Jan 02, 2025 at 09:39:51AM -0400, Jason Gunthorpe wrote:
> > On Thu, Dec 19, 2024 at 11:04:54AM +0100, Christian König wrote:
> >
> > > > Based on all the above, I think we can conclude that since
asn't aware that the task_work functionality exists
> for that use case.
IIRC it was changed a while back because call chains were getting kind of
crazy long with the file release functions and stack overflow was a
problem in some cases.
Jason
Signed-off-by: Jason-JH.Lin
---
.../bindings/display/mediatek/mediatek,ovl.yaml | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git
a/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml
b/Documentation/devicetree/bindings/display/mediatek
Sung (1):
dt-bindings: display: mediatek: ovl: Modify rules for MT8195/MT8188
Jason-JH.Lin (3):
dt-bindings: display: mediatek: ovl: Add compatible strings for MT8188
MDP3
dts: arm64: mediatek: mt8188: Update OVL compatible from MT8183 to
MT8195
dts: arm64: mediatek: mt8195: Remove
The OVL hardware capabilities have changed starting from MT8195,
making the MT8183 compatible no longer applicable.
Therefore, it is necessary to remove the MT8183 compatible for OVL.
Reviewed-by: AngeloGioacchino Del Regno
Signed-off-by: Jason-JH.Lin
---
arch/arm64/boot/dts/mediatek/mt8195
Add compatible strings for the MDP3 OVL hardware components in
MediaTek's MT8188 SoC and it is compatible with the existing
MT8195 MDP OVL components.
Signed-off-by: Jason-JH.Lin
Suggested-by: AngeloGioacchino Del Regno
---
.../devicetree/bindings/display/mediatek/mediatek,ovl.yaml
The OVL hardware capabilities have changed starting from MT8195,
making the MT8183 compatible no longer applicable.
Therefore, it is necessary to update the OVL compatible from MT8183 to
MT8195.
Reviewed-by: AngeloGioacchino Del Regno
Signed-off-by: Jason-JH.Lin
---
arch/arm64/boot/dts
From: Jason-jh Lin
This patch series adds support for the MediaTek MT8196 SoC in the CMDQ
driver and related subsystems. The changes include adding compatible
names and properties, updating driver data to accommodate hardware
changes, and modifying the usage of CMDQ APIs to support non-subsys ID
accessing DRAM,
GCE needs to configure the DMA address to be less than 35 bits.
Signed-off-by: Jason-JH.Lin
---
drivers/mailbox/mtk-cmdq-mailbox.c | 90 +---
include/linux/mailbox/mtk-cmdq-mailbox.h | 2 +
2 files changed, 84 insertions(+), 8 deletions(-)
diff --git a
To support hardware without subsys IDs on new SoCs, add a programming
flow that checks whether the subsys ID is valid. If the subsys ID is
invalid, the flow will call 2 alternative CMDQ APIs:
cmdq_pkt_assign() and cmdq_pkt_write_s_value() to achieve the same
functionality.
Signed-off-by: Jason
STREAM_DONE event sent from DISP_MUTEX hardware
cmdq_pkt_clear_event(cmdq_handle, mtk_crtc->cmdq_event);
```
Signed-off-by: Jason-JH.Lin
---
.../mailbox/mediatek,gce-mailbox.yaml |4 +
.../dt-bindings/mailbox/mediatek,mt8196-gce.h | 1415 +
2 files changed, 1419
parsing flow to the cmdq_client_reg structure
for these unsupported subsys ID hardware.
Signed-off-by: Jason-JH.Lin
---
drivers/soc/mediatek/mtk-cmdq-helper.c | 18 --
include/linux/soc/mediatek/mtk-cmdq.h | 3 +++
2 files changed, 19 insertions(+), 2 deletions(-)
diff --git a
: Jason-JH.Lin
---
.../platform/mediatek/mdp3/mtk-mdp3-cmdq.c| 18 -
.../platform/mediatek/mdp3/mtk-mdp3-comp.h| 79 ++-
2 files changed, 77 insertions(+), 20 deletions(-)
diff --git a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-cmdq.c
b/drivers/media/platform/mediatek
the mbox API to get the
mminfra_offset value of the SoC, and then add it to the DRAM address
when generating instructions to ensure GCE accesses the correct DRAM
address.
Signed-off-by: Jason-JH.Lin
---
drivers/soc/mediatek/mtk-cmdq-helper.c | 35 --
1 file changed, 33
To support hardware without subsys IDs on new SoCs, add a programming
flow that checks whether the subsys ID is valid. If the subsys ID is
invalid, the flow will call 2 alternative CMDQ APIs:
cmdq_pkt_assign() and cmdq_pkt_write_s_value() to achieve the same
functionality.
Signed-off-by: Jason
Signed-off-by: Jason-JH.Lin
---
.../bindings/display/mediatek/mediatek,ovl.yaml | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git
a/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml
b/Documentation/devicetree/bindings/display/mediatek
The OVL hardware capabilities have changed starting from MT8195,
making the MT8183 compatible no longer applicable.
Therefore, it is necessary to remove the MT8183 compatible for OVL.
Signed-off-by: Jason-JH.Lin
---
arch/arm64/boot/dts/mediatek/mt8195.dtsi | 2 +-
1 file changed, 1 insertion
of compatible property.
2. Add fix patch to mt8195.
---
Hsiao Chien Sung (1):
dt-bindings: display: mediatek: ovl: Modify rules for MT8195/MT8188
Jason-JH.Lin (2):
dts: arm64: mediatek: mt8188: Update OVL compatible from MT8183 to
MT8195
dts: arm64: mediatek: mt8195: Remove MT8183
The OVL hardware capabilities have changed starting from MT8195,
making the MT8183 compatible no longer applicable.
Therefore, it is necessary to update the OVL compatible from MT8183 to
MT8195.
Signed-off-by: Jason-JH.Lin
---
arch/arm64/boot/dts/mediatek/mt8188.dtsi | 2 +-
1 file changed, 1
: Jason-JH.Lin
---
.../bindings/display/mediatek/mediatek,ovl.yaml | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git
a/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml
b/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml
index
Jason-JH.Lin (1):
dts: arm64: mediatek: mt8188: Update OVL compatible from MT8183 to
MT8195
.../bindings/display/mediatek/mediatek,ovl.yaml | 8 +++-
arch/arm64/boot/dts/mediatek/mt8188.dtsi | 2 +-
2 files changed, 4 insertions(+), 6 deletions(-)
--
2.43.0
The OVL hardware capabilities have changed starting from MT8195,
making the MT8183 compatible no longer applicable.
Therefore, it is necessary to update the OVL compatible from MT8183 to
MT8195.
Signed-off-by: Jason-JH.Lin
---
arch/arm64/boot/dts/mediatek/mt8188.dtsi | 2 +-
1 file changed, 1
To support hardware without subsys IDs on new SoCs, add a programming
flow that checks whether the subsys ID is valid. If the subsys ID is
invalid, the flow will call 2 alternative CMDQ APIs:
cmdq_pkt_assign() and cmdq_pkt_write_s_value() to achieve the same
functionality.
Signed-off-by: Jason
g for notifying
`DRM_EVENT_FLIP_COMPLETE` to userspace, mtk_crtc_finish_page_flip()
should be moved to ddp_cmdq_cb().
Fixes: 7f82d9c43879 ("drm/mediatek: Clear pending flag when cmdq packet is
done")
Signed-off-by: Jason-JH.Lin
---
drivers/gpu/drm/mediatek/mtk_crtc.c | 25 +
these unsupported subsys ID hardware.
Signed-off-by: Jason-JH.Lin
---
drivers/soc/mediatek/mtk-cmdq-helper.c | 18 --
include/linux/soc/mediatek/mtk-cmdq.h | 1 +
2 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c
b/drivers/soc
: Jason-JH.Lin
---
.../platform/mediatek/mdp3/mtk-mdp3-cmdq.c| 26 ++--
.../platform/mediatek/mdp3/mtk-mdp3-comp.h| 41 +++
2 files changed, 55 insertions(+), 12 deletions(-)
diff --git a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-cmdq.c
b/drivers/media/platform
To support hardware without subsys IDs on new SoCs, add a programming
flow that checks whether the subsys ID is valid. If the subsys ID is
invalid, the flow will call 2 alternative CMDQ APIs:
cmdq_pkt_assign() and cmdq_pkt_write_s_value() to achieve the same
functionality.
Signed-off-by: Jason
know how to program the command.
Signed-off-by: Jason-JH.Lin
---
drivers/mailbox/mtk-cmdq-mailbox.c | 107 +--
include/linux/mailbox/mtk-cmdq-mailbox.h | 3 +
2 files changed, 102 insertions(+), 8 deletions(-)
diff --git a/drivers/mailbox/mtk-cmdq-mailbox.c
b/drivers
the mbox API to get the
mminfra_offset value of the SoC, and then add it to the DRAM address
when generating instructions to ensure GCE accesses the correct DRAM
address.
Signed-off-by: Jason-JH.Lin
---
drivers/soc/mediatek/mtk-cmdq-helper.c | 35 --
1 file changed, 33
Add the Global Command Engine (GCE) header file to define the GCE
thread priority, GCE subsys ID and GCE events for MT8196.
Signed-off-by: Jason-JH.Lin
---
.../dt-bindings/mailbox/mediatek,mt8196-gce.h | 1439 +
1 file changed, 1439 insertions(+)
create mode 100644 include/dt
From: Jason-jh Lin
This patch series adds support for the MediaTek MT8196 SoC in the CMDQ
driver and related subsystems. The changes include adding compatible
names and properties, updating driver data to accommodate hardware
changes, and modifying the usage of CMDQ API to support non-subsys ID
Add compatible name and iommus property for MT8196.
Signed-off-by: Jason-JH.Lin
---
.../devicetree/bindings/mailbox/mediatek,gce-mailbox.yaml | 4
1 file changed, 4 insertions(+)
diff --git
a/Documentation/devicetree/bindings/mailbox/mediatek,gce-mailbox.yaml
b/Documentation
g for notifying
`DRM_EVENT_FLIP_COMPLETE` to userspace, mtk_crtc_finish_page_flip()
should be moved to ddp_cmdq_cb().
Fixes: 7f82d9c43879 ("drm/mediatek: Clear pending flag when cmdq packet is
done")
Signed-off-by: Jason-JH.Lin
---
drivers/gpu/drm/mediatek/
know how to program the command.
Signed-off-by: Jason-JH.Lin
---
drivers/mailbox/mtk-cmdq-mailbox.c | 107 +--
include/linux/mailbox/mtk-cmdq-mailbox.h | 3 +
2 files changed, 102 insertions(+), 8 deletions(-)
diff --git a/drivers/mailbox/mtk-cmdq-mailbox.c
b/drivers
Add the Global Command Engine (GCE) header file to define the GCE
thread priority, GCE subsys ID, GCE events, and various constants
for MT8196.
Signed-off-by: Jason-JH.Lin
---
.../dt-bindings/mailbox/mediatek,mt8196-gce.h | 1449 +
1 file changed, 1449 insertions(+)
create mode
To support non-subsys ID hardware on new SoCs, the CMDQ API has been
changed to include the pa_base parameter. This change accommodates
the new interface requirements.
Signed-off-by: Jason-JH.Lin
---
drivers/soc/mediatek/mtk-mmsys.c | 1 +
drivers/soc/mediatek/mtk-mutex.c | 2 +-
2 files
Add compatible name and iommus property for MT8196.
Signed-off-by: Jason-JH.Lin
---
.../devicetree/bindings/mailbox/mediatek,gce-mailbox.yaml | 4
1 file changed, 4 insertions(+)
diff --git
a/Documentation/devicetree/bindings/mailbox/mediatek,gce-mailbox.yaml
b/Documentation
the mbox API to get the
mminfra_offset value of the SoC, and then add it to the DRAM address
when generating instructions to ensure GCE accesses the correct DRAM
address.
Signed-off-by: Jason-JH.Lin
---
drivers/soc/mediatek/mtk-cmdq-helper.c | 43 +-
1 file changed, 42
ID hardware.
Signed-off-by: Jason-JH.Lin
---
drivers/soc/mediatek/mtk-cmdq-helper.c | 90 ++
include/linux/soc/mediatek/mtk-cmdq.h | 22 ---
2 files changed, 92 insertions(+), 20 deletions(-)
diff --git a/drivers/soc/mediatek/mtk-cmdq-helper.c
b/drivers/soc
This patch series adds support for the MediaTek MT8196 SoC in the CMDQ
driver and related subsystems. The changes include adding compatible
names and properties, updating driver data to accommodate hardware
changes, and modifying the CMDQ API to support non-subsys ID hardware.
Jason-JH.Lin (8
To support non-subsys ID hardware on new SoCs, the CMDQ API has been
changed to include the pa_base parameter. This change accommodates
the new interface requirements.
Signed-off-by: Jason-JH.Lin
---
drivers/gpu/drm/mediatek/mtk_ddp_comp.c | 6 +++---
1 file changed, 3 insertions(+), 3
To support non-subsys ID hardware on new SoCs, the CMDQ API has been
changed to include the pa_base parameter. This change accommodates
the new interface requirements.
Signed-off-by: Jason-JH.Lin
---
drivers/media/platform/mediatek/mdp3/mtk-mdp3-cmdq.c | 4 ++--
drivers/media/platform/mediatek
g for notifying
`DRM_EVENT_FLIP_COMPLETE` to userspace, mtk_crtc_finish_page_flip()
should be moved to ddp_cmdq_cb().
Fixes: 7f82d9c43879 ("drm/mediatek: Clear pending flag when cmdq packet is
done")
Signed-off-by: Jason-JH.Lin
---
drivers/gpu/drm/mediatek/mtk_crtc.c | 27 +++
flag when cmdq packet is
done")
Signed-off-by: Jason-JH.Lin
---
drivers/gpu/drm/mediatek/mtk_crtc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_crtc.c
b/drivers/gpu/drm/mediatek/mtk_crtc.c
index eb0e1233ad04..b03b9102ff90 100644
---
("drm/mediatek: Add DRM_MODE_ROTATE_0 to rotation property")
Signed-off-by: Jason-JH.Lin
---
drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
b/drivers/gpu/drm/mediatek/mtk_
On Tue, Nov 12, 2024 at 10:10:06AM +0100, David Hildenbrand wrote:
> On 12.11.24 06:26, Matthew Wilcox wrote:
> > On Mon, Nov 11, 2024 at 08:26:54AM +, Fuad Tabba wrote:
> > > Thanks for your comments Jason, and for clarifying my cover letter
> > > David. I think D
?
But this is also why I suggested to shift them to ZONE_DEVICE for
guestmemfd, because then you get these things for free from the pgmap.
(this is not a disagreement this is a valid solution, but a request
you explain much more about what it is you actually need and compare
it with the other existing options)
Jason
On Wed, Nov 06, 2024 at 03:53:23PM +, Will Deacon wrote:
> On Tue, 05 Nov 2024 14:14:23 -0400, Jason Gunthorpe wrote:
> > This is the result of the discussion on removing split. We agreed that
> > split is not required, and no application should ask for anything that
> > w
ality.
Outside the iommu users, this will potentially effect io_pgtable users of
ARM_32_LPAE_S1, ARM_32_LPAE_S2, ARM_64_LPAE_S1, ARM_64_LPAE_S2, and
ARM_MALI_LPAE formats.
Cc: Boris Brezillon
Cc: Steven Price
Cc: Liviu Dudau
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Liviu Dudau
Signe
- Add arm-v7s patch
- Write a kdoc for iommu_unmap()
v1: https://patch.msgid.link/r/0-v1-8c5f369ec2e5+75-arm_no_split_...@nvidia.com
Jason Gunthorpe (3):
iommu/io-pgtable-arm: Remove split on unmap behavior
iommu/io-pgtable-arm-v7s: Remove split on unmap behavior
iommu: Add a kdoc to iommu_unmap
1.ga6...@nvidia.com/
Bring consistency to the implementations and remove this unused
functionality.
There are no uses outside iommu, this effects the ARM_V7S drivers
msm_iommu, mtk_iommu, and arm-smmmu.
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/io-pgtable-arm-v7s.c
iewed-by: Liviu Dudau
Signed-off-by: Jason Gunthorpe
---
drivers/iommu/iommu.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 83c8e617a2c588..19b177720d3aca 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -2
On Tue, Nov 05, 2024 at 04:59:43PM +, Will Deacon wrote:
> > /* Full unmap */
> > iova = 0;
> > for_each_set_bit(i, &cfg.pgsize_bitmap, BITS_PER_LONG) {
>
> Yup, and you can do the same for the other selftest in io-pgtable-arm.c
Ugh, yes, I ran it and thought the log it printed wa
On Mon, Nov 04, 2024 at 07:53:46PM +, Robin Murphy wrote:
> On 2024-11-04 5:41 pm, Jason Gunthorpe wrote:
> > A minority of page table implementations (arm_lpae, armv7) are unique in
> > how they handle partial unmap of large IOPTEs.
> >
> > Other implementations
1 - 100 of 2182 matches
Mail list logo
