On Fri, Feb 01, 2019 at 11:46:00AM +, Jean-Philippe Brucker wrote:
> On 01/02/2019 03:51, Peter Xu wrote:
> > On Thu, Jan 31, 2019 at 12:25:40PM +, Jean-Philippe Brucker wrote:
> >> On 31/01/2019 07:59, Peter Xu wrote:
> >>> On Wed, Jan 30, 2019 at 12:27:40PM +, Jean-Philippe Brucker wr
Hi Robin:
Thanks for your review.
On Sat, Feb 2, 2019 at 1:00 AM Robin Murphy wrote:
>
> On 31/01/2019 10:17, lantianyu1...@gmail.com wrote:
> > From: Lan Tianyu
> >
> > On the bare metal, enabling X2APIC mode requires interrupt remapping
> > function which helps to deliver irq to cpu
Hi Sasha:
Thanks for your review.
On Fri, Feb 1, 2019 at 10:51 PM Sasha Levin wrote:
>
> Hi Tianyu,
>
> Few comments below.
>
> On Thu, Jan 31, 2019 at 06:17:32PM +0800, lantianyu1...@gmail.com wrote:
> >From: Lan Tianyu
> >
> >On the bare metal, enabling X2APIC mode requires interr
Hi Joerg:
Thanks for your review.
On Sat, Feb 2, 2019 at 12:34 AM Joerg Roedel wrote:
>
> Hi,
>
> On Thu, Jan 31, 2019 at 06:17:32PM +0800, lantianyu1...@gmail.com wrote:
> > +config HYPERV_IOMMU
> > + bool "Hyper-V stub IOMMU support"
>
> This is not a real IOMMU driver, it only
On Thu, Jan 31, 2019 at 03:52:09PM -0700, Logan Gunthorpe wrote:
> On 2019-01-31 3:39 p.m., Bjorn Helgaas wrote:
> >> diff --git a/include/linux/msi.h b/include/linux/msi.h
> >> index 784fb52b9900..6458ab049852 100644
> >> --- a/include/linux/msi.h
> >> +++ b/include/linux/msi.h
> >> @@ -88,6 +88,7
On 2019-02-01 9:44 a.m., Joerg Roedel wrote:
> On Thu, Jan 31, 2019 at 11:56:48AM -0700, Logan Gunthorpe wrote:
>> @@ -394,6 +402,10 @@ static int set_msi_sid(struct irte *irte, struct
>> pci_dev *dev)
>> set_irte_sid(irte, SVT_VERIFY_BUS, SQ_ALL_16,
>> PC
On 31/01/2019 10:17, lantianyu1...@gmail.com wrote:
From: Lan Tianyu
On the bare metal, enabling X2APIC mode requires interrupt remapping
function which helps to deliver irq to cpu with 32-bit APIC ID.
Hyper-V doesn't provide interrupt remapping function so far and Hyper-V
MSI protocol already
On Fri, Feb 01, 2019 at 05:56:10PM +0100, Christoph Hellwig wrote:
> On Fri, Feb 01, 2019 at 05:50:29PM +0100, Joerg Roedel wrote:
> > > Mike just killed the _nopanic versions and made the normal ones not
> > > panic.
> >
> > This sounds like a change to break quite a couple of places in the
> > k
On Fri, Feb 01, 2019 at 05:50:29PM +0100, Joerg Roedel wrote:
> > Mike just killed the _nopanic versions and made the normal ones not
> > panic.
>
> This sounds like a change to break quite a couple of places in the
> kernel. But okay, it just makes this hunk obsolete.
He also added either explic
Hi Christoph,
I will try it at the weekend.
Thanks,
Christian
Sent from my iPhone
> On 1. Feb 2019, at 09:04, Christoph Hellwig wrote:
>
>> On Thu, Jan 31, 2019 at 01:48:26PM +0100, Christian Zigotzky wrote:
>> Hi Christoph,
>>
>> I compiled kernels for the X5000 and X1000 from your branch '
On Fri, Feb 01, 2019 at 09:12:08AM +0100, Christoph Hellwig wrote:
> On Thu, Jan 31, 2019 at 05:24:24PM +0100, Joerg Roedel wrote:
> > - io_tlb_list = memblock_alloc(
> > + io_tlb_list = memblock_alloc_nopanic(
> > PAGE_ALIGN(io_tlb_nslabs * sizeof(int)),
> >
On Thu, Jan 31, 2019 at 11:56:48AM -0700, Logan Gunthorpe wrote:
> @@ -394,6 +402,10 @@ static int set_msi_sid(struct irte *irte, struct pci_dev
> *dev)
> set_irte_sid(irte, SVT_VERIFY_BUS, SQ_ALL_16,
>PCI_DEVID(PCI_BUS_NUM(data.alias),
>
Hi,
On Thu, Jan 31, 2019 at 06:17:32PM +0800, lantianyu1...@gmail.com wrote:
> +config HYPERV_IOMMU
> + bool "Hyper-V stub IOMMU support"
This is not a real IOMMU driver, it only implements IRQ remapping
capabilities. Please change the name to reflect that, e.g. to
"Hyper-V IRQ Remapping Supp
On Fri, Feb 01, 2019 at 03:24:45PM +, Robin Murphy wrote:
> On 14/01/2019 09:41, Christoph Hellwig wrote:
>> Directly iterating over the pages makes the code a bit simpler and
>> prepares for the following changes.
>
> It also defeats the whole purpose of __iommu_dma_alloc_pages(), so I'm not
On Fri, 01 Feb 2019 17:09:57 +0100,
Christoph Hellwig wrote:
>
> On Fri, Feb 01, 2019 at 02:16:08PM +0100, Takashi Iwai wrote:
> > Actually there are a bunch of ISA sound drivers that still call
> > allocators with NULL device.
> >
> > The patch below should address it, although it's only compile
On Fri, 01 Feb 2019 17:09:06 +0100,
Christoph Hellwig wrote:
>
> On Fri, Feb 01, 2019 at 02:12:45PM +0100, Takashi Iwai wrote:
> > Shall I take this one through sound git tree or all through yours?
>
> Feel free to merge the sound bits through your tree!
Alright, merged both patches 17 and 18 no
On Fri, Feb 01, 2019 at 02:47:17PM +, Robin Murphy wrote:
> On 14/01/2019 09:41, Christoph Hellwig wrote:
>> No need for a __KERNEL__ guard outside uapi, make sure we pull in the
>> includes unconditionally so users can rely on it, and add a missing
>> comment describing the #else cpp statement
On Fri, Feb 01, 2019 at 02:14:34PM +, Robin Murphy wrote:
> And equivalently for rxdma here. However, given that this all seems only
> relevant to antique ARCH_PXA platforms which are presumably managing to
> work as-is, it's probably not worth tinkering too much. I'd just stick a
> note in
On Fri, Feb 01, 2019 at 03:19:41PM +0200, Felipe Balbi wrote:
> Christoph Hellwig writes:
>
> > dma_map_single already transfers ownership to the device.
> >
> > Signed-off-by: Christoph Hellwig
>
> Do you want me to take the USB bits or will you take the entire series?
> In case you're taking
On Fri, Feb 01, 2019 at 02:22:46PM +, Robin Murphy wrote:
> On 14/01/2019 09:41, Christoph Hellwig wrote:
>> Add a Kconfig symbol that indicates an architecture provides a
>> arch_dma_prep_coherent implementation, and provide a stub otherwise.
>>
>> This will allow the generic dma-iommu code to
On Fri, Feb 01, 2019 at 01:53:09PM +, Robin Murphy wrote:
>> #define LOW_WATER_MARK 100
>> #define HIGH_WATER_MARK (LOW_WATER_MARK*5)
>> -#ifdef CONFIG_UML
>> +#ifdef CONFIG_HAS_DMA
>
> #ifndef, surely?
Indeed.
___
iommu mailing list
iommu@l
On Fri, Feb 01, 2019 at 02:16:08PM +0100, Takashi Iwai wrote:
> Actually there are a bunch of ISA sound drivers that still call
> allocators with NULL device.
>
> The patch below should address it, although it's only compile-tested.
Oh, I missed these "indirect" calls. This looks good to me:
Re
On Fri, Feb 01, 2019 at 02:12:45PM +0100, Takashi Iwai wrote:
> Shall I take this one through sound git tree or all through yours?
Feel free to merge the sound bits through your tree!
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.
On 14/01/2019 09:41, Christoph Hellwig wrote:
We now have a arch_dma_prep_coherent architecture hook that is used
for the generic DMA remap allocator, and we should use the same
interface for the dma-iommu code.
Agreed - I'd definitely ack a version of this change which didn't depend
on patch
On 14/01/2019 09:41, Christoph Hellwig wrote:
Directly iterating over the pages makes the code a bit simpler and
prepares for the following changes.
It also defeats the whole purpose of __iommu_dma_alloc_pages(), so I'm
not really buying the simplification angle - you've *seen* that code,
rig
On 01/02/2019 at 09:47, Christoph Hellwig wrote:
> The DMA API generally relies on a struct device to work properly, and
> only barely works without one for legacy reasons. Pass the easily
> available struct device from the platform_device to remedy this.
>
> Signed-off-by: Christoph Hellwig
Ac
On 14/01/2019 09:41, Christoph Hellwig wrote:
No need for a __KERNEL__ guard outside uapi, make sure we pull in the
includes unconditionally so users can rely on it, and add a missing
comment describing the #else cpp statement. Last but not least include
instead of the asm version, which is fro
Hi Tianyu,
Few comments below.
On Thu, Jan 31, 2019 at 06:17:32PM +0800, lantianyu1...@gmail.com wrote:
From: Lan Tianyu
On the bare metal, enabling X2APIC mode requires interrupt remapping
function which helps to deliver irq to cpu with 32-bit APIC ID.
Hyper-V doesn't provide interrupt remap
On 14/01/2019 09:41, Christoph Hellwig wrote:
Add a Kconfig symbol that indicates an architecture provides a
arch_dma_prep_coherent implementation, and provide a stub otherwise.
This will allow the generic dma-iommu code to it while still allowing
to be built for cache coherent architectures.
On 01/02/2019 08:47, Christoph Hellwig wrote:
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Hmm, as far as I'm aware these are PIO chips wi
On 01/02/2019 08:47, Christoph Hellwig wrote:
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Also use the proper Kconfig symbol to check for
Christoph Hellwig writes:
> The DMA API generally relies on a struct device to work properly, and
> only barely works without one for legacy reasons. Pass the easily
> available struct device from the platform_device to remedy this.
>
> Signed-off-by: Christoph Hellwig
In case you're taking th
Christoph Hellwig writes:
> dma_map_single already transfers ownership to the device.
>
> Signed-off-by: Christoph Hellwig
Do you want me to take the USB bits or will you take the entire series?
In case you're taking the entire series:
Acked-by: Felipe Balbi
> ---
> drivers/usb/gadget/udc/f
On Fri, 01 Feb 2019 09:48:01 +0100,
Christoph Hellwig wrote:
>
> The DMA API generally relies on a struct device to work properly, and
> only barely works without one for legacy reasons. Pass the easily
> available struct device from the platform_device to remedy this.
>
> Also use GFP_KERNEL in
On Fri, 01 Feb 2019 09:48:00 +0100,
Christoph Hellwig wrote:
>
> The DMA API generally relies on a struct device to work properly, and
> only barely works without one for legacy reasons. Pass the easily
> available struct device from the platform_device to remedy this.
>
> Signed-off-by: Christo
On Fri, 01 Feb 2019 09:47:43 +0100,
Christoph Hellwig wrote:
>
> We still have a few drivers which pass a NULL struct device pointer
> to DMA API functions, which generally is a bad idea as the API
> implementations rely on the device not only for ops selection, but
> also the dma mask and various
On Thu, Jan 31, 2019 at 6:04 PM Heiko Stuebner wrote:
>
> Am Donnerstag, 31. Januar 2019, 13:31:52 CET schrieb Souptick Joarder:
> > On Thu, Jan 31, 2019 at 5:37 PM Heiko Stuebner wrote:
> > >
> > > Am Donnerstag, 31. Januar 2019, 04:08:12 CET schrieb Souptick Joarder:
> > > > Previouly drivers h
On 01/02/2019 03:51, Peter Xu wrote:
> On Thu, Jan 31, 2019 at 12:25:40PM +, Jean-Philippe Brucker wrote:
>> On 31/01/2019 07:59, Peter Xu wrote:
>>> On Wed, Jan 30, 2019 at 12:27:40PM +, Jean-Philippe Brucker wrote:
Hi Peter,
>>>
>>> Hi, Jean,
>>>
On 30/01/2019 05:57, Peter
On Thu, 2019-01-31 at 11:23 -0800, Evan Green wrote:
> On Wed, Jan 30, 2019 at 10:59 PM Yong Wu wrote:
> >
> > On Wed, 2019-01-30 at 10:28 -0800, Evan Green wrote:
> > > On Mon, Dec 31, 2018 at 7:57 PM Yong Wu wrote:
> > > >
> > > > MediaTek extend the arm v7s descriptor to support the dram over
On Thu, 2019-01-31 at 09:45 -0800, Evan Green wrote:
> On Wed, Jan 30, 2019 at 7:22 PM Yong Wu wrote:
> >
> > On Wed, 2019-01-30 at 11:11 -0800, Evan Green wrote:
> > > On Mon, Dec 31, 2018 at 7:59 PM Yong Wu wrote:
> > > >
> > > > The "mediatek,larb-id" has already been parsed in MTK IOMMU drive
On Fri, Feb 01, 2019 at 10:04:02AM +0100, Christoph Hellwig wrote:
> On Tue, Jan 22, 2019 at 07:48:47PM +0100, Greg Kroah-Hartman wrote:
> > > Does this actually need to be at file scope, or could it be punted to a
> > > local in dma_debug_fs_init() while we're here?
> >
> > It can be moved to the
Thanks!
I had to adjust the patch a bit for the debugfs cleanups form Greg
that I applied before, can you check the result here:
http://git.infradead.org/users/hch/dma-mapping.git/commitdiff/0a3b192c26da198fce38e1ee242a34f558670246
___
iommu mailin
On Fri, Feb 01, 2019 at 08:05:21AM +0100, Marek Szyprowski wrote:
> Works fine on older Exynos based boards with IOMMU and CMA disabled.
>
> Tested-by: Marek Szyprowski
Thanks. I've merged the Ń•eries into the dma-mapping tree, and I've
also made a stable branch available at:
git://git.infr
On Tue, Jan 22, 2019 at 07:48:47PM +0100, Greg Kroah-Hartman wrote:
> > Does this actually need to be at file scope, or could it be punted to a
> > local in dma_debug_fs_init() while we're here?
>
> It can be moved to the function scope if you want me to, I was trying to
> do the least needed here
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Signed-off-by: Christoph Hellwig
---
drivers/usb/gadget/udc/fotg210-udc.c | 7 ---
1 file
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Also use GFP_KERNEL instead of GFP_USER as the gfp_t for the memory
allocation, as we should tre
Just like we do for all other DMA operations.
Signed-off-by: Christoph Hellwig
---
drivers/video/fbdev/pxa3xx-gcu.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/pxa3xx-gcu.c b/drivers/video/fbdev/pxa3xx-gcu.c
index 69cfb337c857..047a2fa4b87e 100644
-
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Signed-off-by: Christoph Hellwig
---
sound/mips/hal2.c | 31 +--
1
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Signed-off-by: Christoph Hellwig
---
drivers/net/ethernet/cadence/macb_main.c | 8
1
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Signed-off-by: Christoph Hellwig
---
drivers/net/ethernet/smsc/smc911x.c | 4 ++--
1 file chan
gbefb uses managed resources, so it should do the same for DMA
allocations.
Signed-off-by: Christoph Hellwig
---
drivers/video/fbdev/gbefb.c | 24
1 file changed, 8 insertions(+), 16 deletions(-)
diff --git a/drivers/video/fbdev/gbefb.c b/drivers/video/fbdev/gbefb.c
ind
dma_map_single already transfers ownership to the device.
Signed-off-by: Christoph Hellwig
---
drivers/usb/gadget/udc/fotg210-udc.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/usb/gadget/udc/fotg210-udc.c
b/drivers/usb/gadget/udc/fotg210-udc.c
index bc6abaea907d..fe9cf415f2f1
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Signed-off-by: Christoph Hellwig
---
drivers/video/fbdev/da8xx-fb.c | 13 +++--
1 file
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Note this driver seems to lack dma_unmap_* calls entirely, but fixing
that is left for another t
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Signed-off-by: Christoph Hellwig
---
drivers/net/ethernet/moxa/moxart_ether.c | 11 +++
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Also use GFP_KERNEL instead of GFP_ATOMIC as the gfp_t for the memory
allocation, as we aren't i
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Note that this driver seems to entirely lack dma_map_single error
handling, but that is left for
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Signed-off-by: Christoph Hellwig
---
drivers/parport/parport_ip32.c | 18 ++
1
We still have a few drivers which pass a NULL struct device pointer
to DMA API functions, which generally is a bad idea as the API
implementations rely on the device not only for ops selection, but
also the dma mask and various other attributes.
This series contains all easy conversions to pass a
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Signed-off-by: Christoph Hellwig
---
drivers/net/ethernet/amd/au1000_eth.c | 6 +++---
1 file
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Also use GFP_KERNEL instead of GFP_ATOMIC as the gfp_t for the memory
allocation, as we aren't i
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Signed-off-by: Christoph Hellwig
---
drivers/dma/imx-sdma.c | 10 +-
1 file changed, 5
The DMA API generally relies on a struct device to work properly, and
only barely works without one for legacy reasons. Pass the easily
available struct device from the platform_device to remedy this.
Also use the proper Kconfig symbol to check for DMA API availability.
Signed-off-by: Christoph
On Thu, Jan 31, 2019 at 05:24:24PM +0100, Joerg Roedel wrote:
> From: Joerg Roedel
>
> The only reason why swiotlb_init_with_tbl() can fail is an
> allocation failure in the memblock_alloc() function. But
> this function just calls panic() in case it can't fulfill
> the request and never returns
For some reason patch 5 didn't make it to my inbox, but assuming
nothing has changed this whole series looks good to me now.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On Thu, Jan 31, 2019 at 01:48:26PM +0100, Christian Zigotzky wrote:
> Hi Christoph,
>
> I compiled kernels for the X5000 and X1000 from your branch 'powerpc-dma.6'
> today.
>
> Gitweb:
> http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/powerpc-dma.6
>
> git clone git://git.infradea
66 matches
Mail list logo
