On Thu, Dec 07, 2023 at 02:03:07PM -0400, Jason Gunthorpe wrote:
> Jason Gunthorpe (7):
> iommu: Remove struct iommu_ops *iommu from arch_setup_dma_ops()
> iommmu/of: Do not return struct iommu_ops from of_iommu_configure()
> iommu/of: Use -ENODEV consistently in of_iommu_configure()
>
On Mon, Jan 23, 2023 at 04:35:53PM -0400, Jason Gunthorpe wrote:
> Jason Gunthorpe (10):
> iommu: Add a gfp parameter to iommu_map()
> iommu: Remove iommu_map_atomic()
> iommu: Add a gfp parameter to iommu_map_sg()
> iommu/dma: Use the gfp parameter in __iommu_dma_alloc_noncontiguous()
>
On Fri, Jan 20, 2023 at 01:53:40PM -0400, Jason Gunthorpe wrote:
> > Well, having GFP parameters is not a strict kernel convention. There are
> > places doing it differently and have sleeping and atomic variants of
> > APIs. I have to say I like the latter more. But given that this leads to
> > an
On Fri, Jan 06, 2023 at 01:24:11PM -0400, Jason Gunthorpe wrote:
> I think it is just better to follow kernel convention and have
> allocation functions include the GFP because it is a clear signal to
> the user that there is an allocation hidden inside the API. The whole
> point of gfp is not to
On Sat, Nov 02, 2019 at 06:56:28PM +0100, Thierry Reding wrote:
> Thierry Reding (9):
> iommu: Document iommu_fwspec::flags field
> iommu: Add dummy dev_iommu_fwspec_get() helper
Acked-by: Joerg Roedel
___
Nouveau mailing lis
Hi Thierry,
On Mon, Sep 16, 2019 at 05:54:43PM +0200, Thierry Reding wrote:
> > Joerg, to summarize: the proposal here is to move the declaration of the
> > iommu_fwspec outside of the IOMMU_API guard and provide a dummy
> > implementation of dev_iommu_fwspec_get() to allow this code to be built
On Fri, Jul 27, 2018 at 11:13:31AM -0600, Rob Herring wrote:
> I don't follow why we need a property rather than being implied by the
> device's (the GPU) compatible string.
There might be devices where either setup works, with or without IOMMU
translation, and the firmware can set the property
On Fri, Jul 27, 2018 at 05:10:22PM +0300, Dmitry Osipenko wrote:
> I'm not sure what you guys are meaning by the "firmware", could you elaborate
> please? Do you mean the Open Firmware and hence the devicetree or what?
Yes, I think the best way to request this is using a device-tree
property.
On Fri, Jul 27, 2018 at 02:16:18AM +0300, Dmitry Osipenko wrote:
> The proposed solution adds a new option to the base device driver
> structure that allows device drivers to explicitly convey to the drivers
> core that the implicit IOMMU backing for devices must not happen.
Why is IOMMU mapping
From: Joerg Roedel <jroe...@suse.de>
The map and unmap functions of the IOMMU-API changed their
semantics: They do no longer guarantee that the hardware
TLBs are synchronized with the page-table updates they made.
To make conversion easier, new synchronized functions have
been introduced
obj = acpi_evaluate_dsm_typed(handle, dmar_hp_uuid, DMAR_DSM_REV_ID,
> + obj = acpi_evaluate_dsm_typed(handle, _hp_uuid, DMAR_DSM_REV_ID,
> func, NULL, ACPI_TYPE_BUFFER);
> if (!obj)
> return -ENODEV;
DMAR part is
Acked-
11 matches
Mail list logo
