On Thu, Oct 31, 2019 at 12:38 PM Jean-Philippe Brucker
wrote:
>
> Hi Saravana, Will,
>
> On Wed, Oct 30, 2019 at 05:57:44PM -0700, Saravana Kannan via iommu wrote:
> > > > > Obviously you need to be careful about using IOMMU drivers as modules,
> > > > > since late loading of the driver for an
From: Rob Clark
When games, browser, or anything using a lot of GPU buffers exits, there
can be many hundreds or thousands of buffers to unmap and free. If the
GPU is otherwise suspended, this can cause arm-smmu to resume/suspend
for each buffer, resulting 5-10 seconds worth of reprogramming
Hi Saravana, Will,
On Wed, Oct 30, 2019 at 05:57:44PM -0700, Saravana Kannan via iommu wrote:
> > > > Obviously you need to be careful about using IOMMU drivers as modules,
> > > > since late loading of the driver for an IOMMU serving active DMA masters
> > > > is going to end badly in many
On Thu, Oct 31, 2019 at 06:06:19PM +, Catalin Marinas wrote:
> On Thu, Oct 31, 2019 at 05:58:53PM +0100, Christoph Hellwig wrote:
> > On Thu, Oct 31, 2019 at 05:22:59PM +0100, Nicolas Saenz Julienne wrote:
> > > OK, I see what you mean now. It's wrong indeed.
> > >
> > > The trouble is the
On Thu, Oct 31, 2019 at 05:58:53PM +0100, Christoph Hellwig wrote:
> On Thu, Oct 31, 2019 at 05:22:59PM +0100, Nicolas Saenz Julienne wrote:
> > OK, I see what you mean now. It's wrong indeed.
> >
> > The trouble is the ZONE_DMA series[1] in arm64, also due for v5.5, will be
> > affected by this
On Tue, 29 Oct 2019 14:40:14 +0800
Zhangfei Gao wrote:
> From: Kenneth Lee
>
> Uacce (Unified/User-space-access-intended Accelerator Framework) is
> a kernel module targets to provide Shared Virtual Addressing (SVA)
> between the accelerator and process.
>
> This patch add document to explain
On Tue, 29 Oct 2019 14:40:15 +0800
Zhangfei Gao wrote:
> From: Kenneth Lee
>
> Uacce (Unified/User-space-access-intended Accelerator Framework) targets to
> provide Shared Virtual Addressing (SVA) between accelerators and processes.
> So accelerator can access any data structure of the main
On Tue, 29 Oct 2019 14:40:16 +0800
Zhangfei Gao wrote:
> Register qm to uacce framework for user crypto driver
>
> Signed-off-by: Zhangfei Gao
> Signed-off-by: Zhou Wang
Hi.
This shows there is probably a race during setup that you should close.
Userspace interface is exposed before the
On Thu, 2019-10-31 at 06:38 -0700, Christoph Hellwig wrote:
> On Thu, Oct 31, 2019 at 11:30:36AM +0100, Nicolas Saenz Julienne wrote:
> > On Wed, 2019-10-30 at 14:49 -0700, Christoph Hellwig wrote:
> > > On Mon, Oct 14, 2019 at 08:31:03PM +0200, Nicolas Saenz Julienne wrote:
> > > > Some
Thanks,
applied to the dma-mapping for-next tree.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On Thu, Oct 31, 2019 at 05:22:59PM +0100, Nicolas Saenz Julienne wrote:
> OK, I see what you mean now. It's wrong indeed.
>
> The trouble is the ZONE_DMA series[1] in arm64, also due for v5.5, will be
> affected by this patch. I don't know the right way to approach this problem
> since depending
On Thu, 2019-10-31 at 16:57 +0100, Christoph Hellwig wrote:
> On Thu, Oct 31, 2019 at 04:53:13PM +0100, Nicolas Saenz Julienne wrote:
> > > > +#define ARM64_ZONE_DMA_BITS30
> > > > +
> > > > /*
> > > > * We need to be able to catch inadvertent references to memstart_addr
> > > > * that
On Thu, Oct 31, 2019 at 04:53:13PM +0100, Nicolas Saenz Julienne wrote:
> > > +#define ARM64_ZONE_DMA_BITS 30
> > > +
> > > /*
> > > * We need to be able to catch inadvertent references to memstart_addr
> > > * that occur (potentially in generic code) before arm64_memblock_init()
> > >
On Thu, 2019-10-31 at 16:47 +0100, Christoph Hellwig wrote:
> On Thu, Oct 31, 2019 at 04:28:37PM +0100, Nicolas Saenz Julienne wrote:
> > Some architectures, notably ARM, are interested in tweaking this
> > depending on their runtime DMA addressing limitations.
> >
> > Signed-off-by: Nicolas
On Thu, Oct 31, 2019 at 04:28:37PM +0100, Nicolas Saenz Julienne wrote:
> Some architectures, notably ARM, are interested in tweaking this
> depending on their runtime DMA addressing limitations.
>
> Signed-off-by: Nicolas Saenz Julienne
> ---
>
> Changes since RFC:
> - Rebased to v5.4-rc6,
Hi Joerg,
On Wed, Oct 30, 2019 at 08:31:48PM +0100, Joerg Roedel wrote:
> On Wed, Oct 30, 2019 at 02:51:10PM +, Will Deacon wrote:
> > By removing the redundant call to 'pci_request_acs()' we can allow the
> > ARM SMMUv3 driver to be built as a module.
> >
> > Signed-off-by: Will Deacon
> >
Some architectures, notably ARM, are interested in tweaking this
depending on their runtime DMA addressing limitations.
Signed-off-by: Nicolas Saenz Julienne
---
Changes since RFC:
- Rebased to v5.4-rc6, fixed arm64 code.
NOTE: This will only apply to linux-next, where
arch/arm64/mm/init.c
On Thu, Oct 31, 2019 at 12:03:28PM +, Will Deacon wrote:
> On Wed, Oct 30, 2019 at 05:09:41PM -0600, Jordan Crouse wrote:
> > On Wed, Oct 30, 2019 at 02:51:11PM +, Will Deacon wrote:
> > > @@ -2235,12 +2237,16 @@ static const struct dev_pm_ops arm_smmu_pm_ops = {
> > >
> > > static
15.10.2019 19:29, Thierry Reding пишет:
> From: Thierry Reding
>
> This new framework is currently nothing more than a registry of memory
> controllers, with the goal being to order device probing. One use-case
> where this is useful, for example, is a memory controller device which
> needs to
On Thu, Oct 31, 2019 at 11:30:36AM +0100, Nicolas Saenz Julienne wrote:
> On Wed, 2019-10-30 at 14:49 -0700, Christoph Hellwig wrote:
> > On Mon, Oct 14, 2019 at 08:31:03PM +0200, Nicolas Saenz Julienne wrote:
> > > Some architectures, notably ARM, are interested in tweaking this
> > > depending
On Wed, Oct 30, 2019 at 05:09:41PM -0600, Jordan Crouse wrote:
> On Wed, Oct 30, 2019 at 02:51:11PM +, Will Deacon wrote:
> > @@ -2235,12 +2237,16 @@ static const struct dev_pm_ops arm_smmu_pm_ops = {
> >
> > static struct platform_driver arm_smmu_driver = {
> > .driver = {
> > -
On Wed, 2019-10-30 at 14:41 -0700, Christoph Hellwig wrote:
> On Fri, Oct 18, 2019 at 01:00:43PM +0200, Nicolas Saenz Julienne wrote:
> > +#ifndef CONFIG_ARCH_DMA_ADDR_T_64BIT
> > + /* Check if DMA address overflowed */
> > + if (min(addr, addr + size - 1) <
> > + __phys_to_dma(dev,
On Wed, 2019-10-30 at 14:49 -0700, Christoph Hellwig wrote:
> On Mon, Oct 14, 2019 at 08:31:03PM +0200, Nicolas Saenz Julienne wrote:
> > Some architectures, notably ARM, are interested in tweaking this
> > depending on their runtime DMA addressing limitations.
> >
> > Signed-off-by: Nicolas
On Wed, Oct 30, 2019 at 8:54 AM Will Deacon wrote:
>
> Hi Robin,
>
> On Wed, Oct 30, 2019 at 03:35:55PM +, Robin Murphy wrote:
> > On 30/10/2019 14:51, Will Deacon wrote:
> > > As part of the work to enable a "Generic Kernel Image" across multiple
> > > Android devices, there is a need to
On Wed, Oct 30, 2019 at 08:45:32PM +0100, Christoph Hellwig wrote:
> On Wed, Oct 30, 2019 at 08:26:40PM +0100, Greg Kroah-Hartman wrote:
> > Looks good! You can apply patch 2/2 as well if you want to take that
> > through your tree too.
>
> I can do that, I'll just need a formal ACK from you.
On Tue, Oct 29, 2019 at 02:34:23PM -0700, Kees Cook wrote:
> Now that the vmap area checks are being performed in the DMA
> infrastructure directly, there is no need to repeat them in USB.
>
> Signed-off-by: Kees Cook
> ---
> drivers/usb/core/hcd.c | 8 +---
> 1 file changed, 1
26 matches
Mail list logo
