Hi Guillaume,
On Sat, Feb 06, 2021 at 01:40:13PM +, Guillaume Tucker wrote:
> > It'd be nicer if I can get both logs of the vanilla kernel (failing)
> > and the commit-reverted version (passing), each applying this patch.
>
> Sure, I've run 3 jobs:
>
> * v5.11-rc6 as a reference, to see the
Hi Saravana,
CC iommu
On Tue, Feb 9, 2021 at 10:55 PM Saravana Kannan wrote:
> On Tue, Feb 9, 2021 at 1:33 PM Rob Herring wrote:
> > On Fri, Feb 05, 2021 at 02:26:40PM -0800, Saravana Kannan wrote:
> > > Not all DT bindings are mandatory bindings. Add support for optional DT
> > > bindings and
On Tue, Feb 09, 2021 at 02:12:37PM +0100, Thomas Bogendoerfer wrote:
> > +#ifdef CONFIG_DMA_MAYBE_COHERENT
> > +extern bool dma_default_coherent;
> > static inline bool dev_is_dma_coherent(struct device *dev)
> > {
> > - return coherentio == IO_COHERENCE_ENABLED ||
> > - (coherentio =
Hi Thomas,
this series cleans up some of the mips (maybe) noncoherent support.
It also remove the need for the special header only
provided by mips.
Changes since v1:
- fix a bisection issue due to a missing brace
- simplify the parameter parsing given that it happens after
plat_mem_init
__
Given that plat_mem_setup runs before earlyparams are handled and malta
selects CONFIG_DMA_MAYBE_COHERENT, coherentio can only be set to
IO_COHERENCE_DEFAULT at this point. So remove the checking for other
options and merge plat_enable_iocoherency into plat_setup_iocoherency
to simplify the code a
Factor out a alchemy_dma_coherent helper that determines if the platform
is DMA coherent. Also stop initializing the hw_coherentio variable, given
that is only ever set to a non-zero value by the malta setup code.
Signed-off-by: Christoph Hellwig
---
arch/mips/alchemy/common/setup.c | 33 ++
Replace the global coherentio enum, and the hw_coherentio (fake) boolean
variables with a single boolean dma_default_coherent flag.
Signed-off-by: Christoph Hellwig
---
arch/mips/alchemy/common/setup.c | 3 +--
arch/mips/include/asm/dma-coherence.h | 24
arch/mips/
CONFIG_DMA_MAYBE_COHERENT just guards two early init options now. Just
enable them unconditionally for CONFIG_DMA_NONCOHERENT.
Signed-off-by: Christoph Hellwig
---
arch/mips/Kconfig| 8 ++--
arch/mips/kernel/setup.c | 2 +-
2 files changed, 3 insertions(+), 7 deletions(-)
diff --gi
Just select DMA_NONCOHERENT and ARCH_HAS_SETUP_DMA_OPS from the
MIPS_GENERIC platform instead.
Signed-off-by: Christoph Hellwig
Reviewed-by: Huacai Chen
---
arch/mips/Kconfig | 3 ++-
arch/mips/mm/dma-noncoherent.c | 2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --gi
Lift the dma_default_coherent variable from the mips architecture code
to the driver core. This allows an architecture to sdefault all device
to be DMA coherent at run time, even if the kernel is build with support
for DMA noncoherent device. By allowing device_initialize to set the
->dma_coheren
On Wed, Feb 10, 2021 at 10:56:35AM +0100, Christoph Hellwig wrote:
> Hi Thomas,
>
> this series cleans up some of the mips (maybe) noncoherent support.
> It also remove the need for the special header only
> provided by mips.
>
> Changes since v1:
> - fix a bisection issue due to a missing brac
VMD retransmits child device MSI-X with the VMD endpoint's requester-id.
In order to support direct interrupt remapping of VMD child devices,
ensure that the IRTE is programmed with the VMD endpoint's requester-id
using pci_real_dma_dev().
Acked-by: Lu Baolu
Acked-by: Joerg Roedel
Signed-off-by:
VMD will retransmit child device MSI-X using its own MSI-X table and
requester-id. This limits the number of MSI-X available to the whole
child device domain to the number of VMD MSI-X interrupts.
Some VMD devices have a mode where this remapping can be disabled,
allowing child device interrupts t
The Intel Volume Management Device acts similar to a PCI-to-PCI bridge in that
it changes downstream devices' requester-ids to its own. As VMD supports PCIe
devices, it has its own MSI-X table and transmits child device MSI-X by
remapping child device MSI-X and handling like a demultiplexer.
Some
On Tue, Feb 09, 2021 at 10:22:47PM +, Song Bao Hua (Barry Song) wrote:
> The problem is that SVA declares we can use any memory of a process
> to do I/O. And in real scenarios, we are unable to customize most
> applications to make them use the pool. So we are looking for some
> extension gene
On Tue, Feb 09, 2021 at 08:20:18PM +0800, Zhou Wang wrote:
> Agree, will add it in next version.
No, don't do another version. Jason is right, this approach is wrong.
The point of SVA is that it doesn't require the application to do
anything special. If jitter from too-frequent page migration is
tree: https://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git x86/vt-d
head: 31a75cbbb9274cf8185f402904bf11386917870b
commit: 933fcd01e97e2ba29880dd5f1239365e40094950 [10/12] iommu/vt-d: Add
iotlb_sync_map callback
config: x86_64-rhel-8.3 (attached as .config)
compiler: gcc-9 (Debian 9.
On Fri, Feb 5, 2021 at 1:21 AM Chunyan Zhang wrote:
>
> Hi Rob,
>
> On Fri, 5 Feb 2021 at 07:25, Rob Herring wrote:
> >
> > On Wed, Feb 03, 2021 at 05:07:26PM +0800, Chunyan Zhang wrote:
> > > From: Chunyan Zhang
> > >
> > > This iommu module can be used by Unisoc's multimedia devices, such as
>
> -Original Message-
> From: Jason Gunthorpe [mailto:j...@ziepe.ca]
> Sent: Thursday, February 11, 2021 7:04 AM
> To: Song Bao Hua (Barry Song)
> Cc: David Hildenbrand ; Wangzhou (B)
> ; linux-ker...@vger.kernel.org;
> iommu@lists.linux-foundation.org; linux...@kvack.org;
> linux-arm-ke
The following warning gets triggered while trying to boot a 64K page size
without THP config kernel on arm64 platform.
WARNING: CPU: 5 PID: 124 at mm/vmstat.c:1080 __fragmentation_index+0xa4/0xc0
Modules linked in:
CPU: 5 PID: 124 Comm: kswapd0 Not tainted 5.11.0-rc6-4-ga0ea7d62002 #159
Hardwa
With HUGETLB_PAGE_SIZE_VARIABLE enabled, pageblock_order cannot be assigned
as HUGETLB_PAGE_ORDER when it is greater than or equal to MAX_ORDER during
set_pageblock_order(). Otherwise the following warning is triggered during
boot as detected on an arm64 platform.
WARNING: CPU: 5 PID: 124 at mm/v
MAX_ORDER which invariably depends on FORCE_MAX_ZONEORDER can be a variable
for a given page size, depending on whether TRANSPARENT_HUGEPAGE is enabled
or not. In certain page size and THP combinations HUGETLB_PAGE_ORDER can be
greater than MAX_ORDER, making it unusable as pageblock_order.
This en
Type cast MAX_ORDER as unsigned int to fix the following build warning.
In file included from ./include/linux/kernel.h:14,
from ./include/asm-generic/bug.h:20,
from ./arch/arm64/include/asm/bug.h:26,
from ./include/linux/bug.h:5,
23 matches
Mail list logo
