On Thu, Dec 20, 2018 at 02:32:52PM +, Eugeniy Paltsev wrote:
> Hi Christoph,
>
> I test kernel from your 'dma-alloc-always-zero' branch, and as
> I can see we have DMA peripherals (like USB) broken.
I would be really surprised if that is caused by the patch to add
the zeroing. Can you check
On Thu, Dec 20, 2018 at 05:59:46PM +, Jean-Philippe Brucker wrote:
> On 19/12/2018 23:09, Michael S. Tsirkin wrote:
> > On Thu, Dec 13, 2018 at 12:50:29PM +, Jean-Philippe Brucker wrote:
> [3] git://linux-arm.org/linux-jpb.git virtio-iommu/v0.9.1
>
Btw, can you try wit the very latests dma-mapping-for-next tree
which has a new fix from Thierry Reding that might be related.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On 19/12/2018 23:09, Michael S. Tsirkin wrote:
> On Thu, Dec 13, 2018 at 12:50:29PM +, Jean-Philippe Brucker wrote:
[3] git://linux-arm.org/linux-jpb.git virtio-iommu/v0.9.1
git://linux-arm.org/kvmtool-jpb.git virtio-iommu/v0.9
>>>
>>> Unfortunatly gitweb seems to be broken on
Hi Christoph,
I test kernel from your 'dma-alloc-always-zero' branch, and as
I can see we have DMA peripherals (like USB) broken.
There are the errors example I got during USB initializing:
-->8
usb 1-1: device descriptor read/64, error
On Thu, 2018-12-20 at 15:34 +0100, h...@lst.de wrote:
> On Thu, Dec 20, 2018 at 02:32:52PM +, Eugeniy Paltsev wrote:
> > Hi Christoph,
> >
> > I test kernel from your 'dma-alloc-always-zero' branch, and as
> > I can see we have DMA peripherals (like USB) broken.
>
> I would be really
On Thu, Dec 20, 2018 at 02:39:20PM +, Eugeniy Paltsev wrote:
> > I would be really surprised if that is caused by the patch to add
> > the zeroing.
> Me too :)
>
> > Can you check which commit caused the issue by bisecting
> > from a known good baseline?
>
> Yep. At least kernel build from
of the problem may be somewhere else. *
* Hope this helps! *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
next/master boot bisection: next-20181220 on tegra124-nyan-big
Summary:
Start: 1efde6eb1819 Add linux-next specific files
Ah shoot, it looks like I forgot to change flush_tlb_all -> flush_iotlb_all
Should I submit another patch?
On Wed, 5 Dec 2018 at 16:04, Joerg Roedel wrote:
>
> On Tue, Dec 04, 2018 at 06:27:34PM +, Tom Murphy wrote:
> > From: tom
> >
> > Someone forgot to update this comment.
> >
> >
Hi Jörg,
On Wed, Dec 19, 2018 at 5:51 PM Joerg Roedel wrote:
> On Wed, Dec 19, 2018 at 10:54:18AM +0100, Marek Szyprowski wrote:
> > On 2018-12-11 16:05, Joerg Roedel wrote:
> > > From: Joerg Roedel
> > >
> > > Make sure to invoke this call-back through the proper
> > > function of the
On Fri, Dec 07, 2018 at 04:31:35PM +, Robin Murphy wrote:
> Rather than checking the DMA attribute at each callsite, just pass it
> through for acpi_dma_configure() to handle directly. That can then deal
> with the relatively exceptional DEV_DMA_NOT_SUPPORTED case by explicitly
> installing
On Thu, Dec 20, 2018 at 05:44:18PM +0100, Thierry Reding wrote:
> On Fri, Dec 07, 2018 at 11:07:20AM -0800, Christoph Hellwig wrote:
> [...]
> > diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c
> > index 0b18cfbdde95..fc84c81029d9 100644
> > --- a/kernel/dma/mapping.c
> > +++
On Fri, Dec 07, 2018 at 11:07:20AM -0800, Christoph Hellwig wrote:
[...]
> diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c
> index 0b18cfbdde95..fc84c81029d9 100644
> --- a/kernel/dma/mapping.c
> +++ b/kernel/dma/mapping.c
[...]
> @@ -397,9 +404,9 @@ int dma_supported(struct device *dev,
On Sat, Dec 8, 2018 at 4:42 PM Yong Wu wrote:
>
> The M4U IP blocks in mt8183 is MediaTek's generation2 M4U which use
> the ARM Short-descriptor like mt8173, and most of the HW registers
> are the same.
>
> Here list main differences between mt8183 and mt8173/mt2712:
> 1) mt8183 has only one M4U
On Sat, Dec 8, 2018 at 4:43 PM Yong Wu wrote:
>
> There are 2 mmu cells in a M4U HW. we could adjust some larbs entering
> mmu0 or mmu1 to balance the bandwidth via the smi-common register
> SMI_BUS_SEL(0x220)(Each larb occupy 2 bits).
>
> In mt8183, For better performance, we switch larb1/2/5/7
On Sat, Dec 8, 2018 at 4:42 PM Yong Wu wrote:
>
> The larb-id may be remapped in the smi-common, this means the
> larb-id reported in the mtk_iommu_isr isn't the real larb-id,
>
> Take mt8183 as a example:
>M4U
> |
>
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* This automated bisection report was sent to you on the basis *
* that you may be involved with the breaking commit it has *
* found. No manual investigation has been done to verify it, *
* and the root cause of the
From: Joerg Roedel
This check needs to be there and got lost at some point
during development. Add it again.
Fixes: 641fb0efbff0 ('iommu/of: Don't call iommu_ops->add_device directly')
Reported-by: Marek Szyprowski
Reported-by: kernelci.org bot
Signed-off-by: Joerg Roedel
---
Hi Marek,
On Wed, Dec 19, 2018 at 03:53:51PM +0100, Marek Szyprowski wrote:
> Yes, it fixes this issue.
Thanks a lot, patch is sent out and in iommu tree.
Regards,
Joerg
___
iommu mailing list
iommu@lists.linux-foundation.org
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* This automated bisection report was sent to you on the basis *
* that you may be involved with the breaking commit it has *
* found. No manual investigation has been done to verify it, *
* and the root cause of the
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* This automated bisection report was sent to you on the basis *
* that you may be involved with the breaking commit it has *
* found. No manual investigation has been done to verify it, *
* and the root cause of the
21 matches
Mail list logo
