Acked-by: Alyssa Rosenzweig
On Tue, Apr 12, 2022 at 06:12:11PM +0200, Sven Peter wrote:
> It's the same people anyway.
>
> Signed-off-by: Sven Peter
> ---
> MAINTAINERS | 10 ++
> 1 file changed, 2 insertions(+), 8 deletions(-)
>
> diff --git a/MAINTAINE
Reviewed-by: Alyssa Rosenzweig
On Wed, Oct 13, 2021 at 02:34:41AM -0400, Wan Jiabing wrote:
> Fix following coccicheck warning:
> drivers/iommu/apple-dart.c:704:20-27: WARNING opportunity for kmemdup
>
> Signed-off-by: Wan Jiabing
> ---
> drivers/iommu/apple-dart.c | 3 +--
> The IOMMU_DEVONLY flag allows the caller to flag a mappings backed by
> device-private buffers. That means other devices or CPUs are not
> expected to access the physical memory region pointed by the mapping,
> and the MMU driver can safely restrict the shareability domain to the
> device
> > This seems reasonable to me - it matches the kbase
> > BASE_MEM_COHERENT_SYSTEM (only backwards obviously) and it worked
> > reasonably well for the blob.
Oh, is that what that was for? I remember seeing it set on Midgard for
varyings. Good to go full circle now.
> > But I'm wondering if we
> > On the IOMMU API level you have much more information available about the
> > actual
> > hardware and can prepare the buffers in a way that makes both devices happy.
> > That's why iommu_map_sgtable combined with iovad->granule aligned sgt
> > entries
> > can actually guarantee to map the
> My biggest issue is that I do not understand how this function is supposed
> to be used correctly. It would work fine as-is if it only ever gets passed
> buffers
> allocated by the coherent API but there's not way to check or guarantee that.
> There may also be callers making assumptions that
> Some background: On the Apple M1 the IOMMUs are hardwired to only support 16
> KB pages.
> We'd still like to boot Linux with 4KB pages though because that's what most
> distros
> ship these days. This patch series adds support for that setup to the IOMMU
> DMA API.
This isn't just a distro
> + if ((1 << __ffs(domain->pgsize_bitmap)) > PAGE_SIZE) {
Not a fan of this construction. Could you assign `(1 <<
__ffs(domain->pgsize_bitmap))` to an appropriately named temporary (e.g
min_io_pgsize) so it's clearer what's going on?
> + pr_warn("IOMMU page size cannot represent
off-by: Sven Peter
> ---
> drivers/iommu/apple-dart.c | 14 ++
> 1 file changed, 2 insertions(+), 12 deletions(-)
This was such an ugly hack, glad to see it go. This patch is
Reviewed-by: Alyssa Rosenzweig
___
iommu mailing list
iommu
I use this function for cross-device sharing on the M1 display driver.
Arguably this is unsafe but it works on 16k kernels and if you want to
test the function on 4k, you know where my code is.
On Sat, Aug 28, 2021 at 05:36:37PM +0200, Sven Peter wrote:
> Pretend that iommu_dma_get_sgtable is not
> I'll let my current version simmer for a bit and wait until it's been
> tested by a few people and will send it in a week or so then!
New version has my T-b :)
___
iommu mailing list
iommu@lists.linux-foundation.org
> > Should we be checking alignment here? Something like
> >
> > BUG_ON(paddr & ((1 << DART_TTBR_SHIFT) - 1));
> >
>
> Sure, right now paddr will always be aligned but adding that
> BUG_ON doesn't hurt :)
Probably should have suggested WARN_ON instead of BUG_ON but yes.
Looks really good! Just a few minor comments. With them addressed,
Reviewed-by: Alyssa Rosenzweig
> + Say Y here if you are using an Apple SoC with a DART IOMMU.
Nit: Do we need to spell out "with a DART IOMMU"? Don't all the apple
socs need DART?
> +/*
>
Reviewed-by: Alyssa Rosenzweig
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Reviewed-by: Alyssa Rosenzweig
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Series is:
Acked-by: Alyssa Rosenzweig
On Tue, Sep 22, 2020 at 03:16:47PM +0100, Robin Murphy wrote:
> Hi all,
>
> Here's a quick v2 with the tags so far picked up and some inline
> commentary about the shareability domains for the pagetable code.
>
> Robin.
>
> The DDK blob has the ability to mark only certain areas of memory as
> coherent for performance reasons. For simple things like kmscube I would
> expect that it's basically write-only from the CPU and almost all memory the
> GPU touches isn't touched by the CPU. I.e. coherency isn't helping and
> So I get a performance regression with the dma-coherent approach, even if it's
> clearly the cleaner.
That's bizarre -- this should really be the faster of the two.
signature.asc
Description: PGP signature
___
iommu mailing list
> Sorry - "Thread Local Storage" - e.g. registers spilled to memory from a
> shader program.
Gotcha, thank you. Register spilling isn't implemented yet, so I haven't
run into this. (Partially because the blob's RA is very good so it's
somewhat nontrivial to get it to spill... not that I've tried,
> I'm also somewhat surprised that you don't need loads of other
> properties from the GPU - in particular knowing the number of shader
> cores is useful for allocating the right amount of memory for TLS (and
> can't be obtained purely from the GPU_ID).
Since I have no idea what TLS is (and in my
> the userspace definitely doesn't support T624
This is true, yes. Shouldn't be too hard to backport; if there's still
interest in Midgard 1st/2nd gen, I suppose I can grab hardware and sort
it out...
> You probably want a dma_set_mask_and_coherent() call for your 'real' output
> address size
Nice job!
Patches 1-2 are Acked-by: Alyssa Rosenzweig
Patch 3 is Reviewed-by: Alyssa Rosenzweig
Excited to see this mainlined!
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
22 matches
Mail list logo
