On Fri, Aug 28, 2020 at 07:05:02PM +0300, Andy Shevchenko wrote:
> Compiler is not happy about hidden declaration of intel_iommu_ops.
>
> .../drivers/iommu/intel/iommu.c:414:24: warning: symbol 'intel_iommu_ops' was
> not declared. Should it be static?
>
> Move declaration to header file to make
On Fri, Aug 28, 2020 at 02:13:10PM +0300, Andy Shevchenko wrote:
> Use DMA ops setter instead of direct assignment. Even we know that
> this module doesn't perform access to the dma_ops member of struct device,
> it's better to use setter to avoid potential problems in the future.
I as actually pl
Hi Jean,
Thanks for the review!
On Mon, 24 Aug 2020 12:32:39 +0200
Jean-Philippe Brucker wrote:
> On Fri, Aug 21, 2020 at 09:35:10PM -0700, Jacob Pan wrote:
> > IOASID is used to identify address spaces that can be targeted by
> > device DMA. It is a system-wide resource that is essential to it
On Thu, Aug 27 2020 at 09:17, Marc Zyngier wrote:
> On 2020-08-26 12:17, Thomas Gleixner wrote:
>> #ifdef CONFIG_GENERIC_MSI_IRQ_DOMAIN
>> +void msi_domain_set_default_info_flags(struct msi_domain_info *info)
>> +{
>> +/* Required so that a device latches a valid MSI message on startup
>> */
On Thu, Aug 27 2020 at 13:20, Bjorn Helgaas wrote:
> On Wed, Aug 26, 2020 at 01:17:02PM +0200, Thomas Gleixner wrote:
>> Make the architectures and drivers which rely on them select them in Kconfig
>> and if not selected replace them by stub functions which emit a warning and
>> fail the PCI/MSI in
Hi Baolu,
Thanks for the review!
On Sun, 23 Aug 2020 15:05:08 +0800
Lu Baolu wrote:
> Hi Jacob,
>
> On 2020/8/22 12:35, Jacob Pan wrote:
> > IOASID is used to identify address spaces that can be targeted by
> > device DMA. It is a system-wide resource that is essential to its
> > many users. T
Static analyzer is not happy about intel_iommu_gfx_mapped declaration:
.../drivers/iommu/intel/iommu.c:364:5: warning: symbol 'intel_iommu_gfx_mapped'
was not declared. Should it be static?
Move its declaration to Intel IOMMU header file.
Signed-off-by: Andy Shevchenko
---
include/drm/intel-g
Compiler is not happy about hidden declaration of intel_iommu_ops.
.../drivers/iommu/intel/iommu.c:414:24: warning: symbol 'intel_iommu_ops' was
not declared. Should it be static?
Move declaration to header file to make compiler happy.
Signed-off-by: Andy Shevchenko
---
drivers/iommu/intel/dm
[AMD Public Use]
> -Original Message-
> From: jroe...@suse.de
> Sent: Friday, August 28, 2020 11:30 AM
> To: Deucher, Alexander
> Cc: Kuehling, Felix ; Joerg Roedel
> ; iommu@lists.linux-foundation.org; Huang, Ray
> ; Koenig, Christian ;
> Lendacky, Thomas ; Suthikulpanit, Suravee
> ; li
[AMD Public Use]
> -Original Message-
> From: Kuehling, Felix
> Sent: Friday, August 28, 2020 9:55 AM
> To: jroe...@suse.de; Deucher, Alexander
> Cc: Joerg Roedel ; iommu@lists.linux-foundation.org;
> Huang, Ray ; Koenig, Christian
> ; Lendacky, Thomas
> ; Suthikulpanit, Suravee
> ; linu
On Fri, Aug 28, 2020 at 03:11:32PM +, Deucher, Alexander wrote:
> There are hw bugs on Raven and probably Carrizo/Stoney where they need
> 1:1 mapping to avoid bugs in some corner cases with the displays.
> Other GPUs should be fine. The VIDs is 0x1002 and the DIDs are 0x15dd
> and 0x15d8 for
Hi Felix,
On Fri, Aug 28, 2020 at 09:54:59AM -0400, Felix Kuehling wrote:
> Yes, we're working on this. IOMMUv2 is only needed for KFD. It's not
> needed for graphics. And we're making it optional for KFD as well.
Okay, KFD should fail gracefully because it can't initialize the
device's iommuv2 f
Am 2020-08-28 um 9:46 a.m. schrieb jroe...@suse.de:
> On Wed, Aug 26, 2020 at 03:25:58PM +, Deucher, Alexander wrote:
>>> Alex, do you know if anyone has tested amdgpu on an APU with SME
>>> enabled? Is this considered something we support?
>> It's not something we've tested. I'm not even sure
On 2020-08-28 13:54, Jason Gunthorpe wrote:
On Fri, Aug 28, 2020 at 01:47:59PM +0100, Marc Zyngier wrote:
> So the arch_setup_msi_irq/etc is not really an arch hook, but some
> infrastructure to support those 4 PCI root port drivers.
I happen to have a *really old* patch addressing Tegra [1],
On Wed, Aug 26, 2020 at 03:25:58PM +, Deucher, Alexander wrote:
> > Alex, do you know if anyone has tested amdgpu on an APU with SME
> > enabled? Is this considered something we support?
>
> It's not something we've tested. I'm not even sure the GPU portion of
> APUs will work properly withou
On Fri, Aug 28, 2020 at 01:47:59PM +0100, Marc Zyngier wrote:
> > So the arch_setup_msi_irq/etc is not really an arch hook, but some
> > infrastructure to support those 4 PCI root port drivers.
>
> I happen to have a *really old* patch addressing Tegra [1], which
> I was never able to test (no HW
Hi Jason,
On 2020-08-28 13:19, Jason Gunthorpe wrote:
On Fri, Aug 28, 2020 at 12:21:42PM +0100, Lorenzo Pieralisi wrote:
On Thu, Aug 27, 2020 at 01:20:40PM -0500, Bjorn Helgaas wrote:
[...]
> And I can't figure out what's special about tegra, rcar, and xilinx
> that makes them need it as well
On Fri, Aug 28, 2020 at 12:21:42PM +0100, Lorenzo Pieralisi wrote:
> On Thu, Aug 27, 2020 at 01:20:40PM -0500, Bjorn Helgaas wrote:
>
> [...]
>
> > And I can't figure out what's special about tegra, rcar, and xilinx
> > that makes them need it as well. Is there something I could grep for
> > to
> -Original Message-
> From: Robin Murphy [mailto:robin.mur...@arm.com]
> Sent: Friday, August 28, 2020 11:18 PM
> To: Song Bao Hua (Barry Song) ; Will Deacon
>
> Cc: iommu@lists.linux-foundation.org; linux-arm-ker...@lists.infradead.org;
> j...@8bytes.org; Linuxarm
> Subject: Re: [PAT
On Wed, Aug 26, 2020 at 01:16:28PM +0200, Thomas Gleixner wrote:
> This is the second version of providing a base to support device MSI (non
> PCI based) and on top of that support for IMS (Interrupt Message Storm)
> based devices in a halfways architecture independent way.
>
> The first version c
On Thu, Aug 27, 2020 at 01:20:40PM -0500, Bjorn Helgaas wrote:
[...]
> And I can't figure out what's special about tegra, rcar, and xilinx
> that makes them need it as well. Is there something I could grep for
> to identify them? Is there a way to convert them so they don't need
> it?
I think
On 2020-08-28 12:02, Song Bao Hua (Barry Song) wrote:
-Original Message-
From: Will Deacon [mailto:w...@kernel.org]
Sent: Friday, August 28, 2020 10:29 PM
To: Song Bao Hua (Barry Song)
Cc: iommu@lists.linux-foundation.org; linux-arm-ker...@lists.infradead.org;
robin.mur...@arm.com; j.
Use DMA ops setter instead of direct assignment. Even we know that
this module doesn't perform access to the dma_ops member of struct device,
it's better to use setter to avoid potential problems in the future.
Signed-off-by: Andy Shevchenko
---
drivers/iommu/dma-iommu.c | 2 +-
1 file changed,
> -Original Message-
> From: Will Deacon [mailto:w...@kernel.org]
> Sent: Friday, August 28, 2020 10:29 PM
> To: Song Bao Hua (Barry Song)
> Cc: iommu@lists.linux-foundation.org; linux-arm-ker...@lists.infradead.org;
> robin.mur...@arm.com; j...@8bytes.org; Linuxarm
> Subject: Re: [PAT
On Thu, Aug 27, 2020 at 09:33:51PM +1200, Barry Song wrote:
> cmdq_issue_cmdlist() is the hotspot that uses a lot of time. This patch
> adds tracepoints for it to help debug.
>
> Signed-off-by: Barry Song
> ---
> * can furthermore develop an eBPF program to benchmark using this trace
Hmm, don't
On 2020/5/20 1:54, Jean-Philippe Brucker wrote:
@@ -4454,6 +4470,12 @@ static int arm_smmu_device_hw_probe(struct
arm_smmu_device *smmu)
smmu->features |= ARM_SMMU_FEAT_E2H;
}
+ if (reg & (IDR0_HA | IDR0_HD)) {
+ smmu->features |= ARM_SMMU_FEAT_H
On Fri, Aug 28, 2020 at 07:55:18AM +, Song Bao Hua (Barry Song) wrote:
>
>
> > -Original Message-
> > From: Jean-Philippe Brucker [mailto:jean-phili...@linaro.org]
> > Sent: Friday, August 28, 2020 7:41 PM
> > To: Song Bao Hua (Barry Song)
> > Cc: iommu@lists.linux-foundation.org; li
> -Original Message-
> From: Jean-Philippe Brucker [mailto:jean-phili...@linaro.org]
> Sent: Friday, August 28, 2020 7:41 PM
> To: Song Bao Hua (Barry Song)
> Cc: iommu@lists.linux-foundation.org; linux-arm-ker...@lists.infradead.org;
> robin.mur...@arm.com; w...@kernel.org; Linuxarm
>
Hi,
On Thu, Aug 27, 2020 at 09:33:51PM +1200, Barry Song wrote:
> cmdq_issue_cmdlist() is the hotspot that uses a lot of time. This patch
> adds tracepoints for it to help debug.
>
> Signed-off-by: Barry Song
> ---
> * can furthermore develop an eBPF program to benchmark using this trace
Have
On 8/20/2020 6:19 PM, vji...@codeaurora.org wrote:
> From: Vijayanand Jitta
>
> When ever a new iova alloc request comes iova is always searched
> from the cached node and the nodes which are previous to cached
> node. So, even if there is free iova space available in the nodes
> which are nex
30 matches
Mail list logo
