Hi Edgar,
On Mon, Nov 23, 2020 at 06:41:18AM +, Merger, Edgar [AUTOSOL/MAS/AUGS]
wrote:
> Just wanted to follow-up on that topic.
> Is that quirk already put into upstream kernel?
Sorry for the late reply, I had to take an extended sick leave. I will
take care of sending this fix upstream ne
On Fri, Nov 06, 2020 at 02:28:27PM +, Merger, Edgar [AUTOSOL/MAS/AUGS]
wrote:
> Alright, so is this going to make it into an upstream-Kernel?
Yes, but please test it first. It should apply on-top of a 5.9.3 kernel.
If it works I can send a patch and will Cc you as well as a few other
folks.
On Fri, Nov 06, 2020 at 01:03:22PM +, Merger, Edgar [AUTOSOL/MAS/AUGS]
wrote:
> Thank you. I do think that this is the GPU. Would you please elaborate
> on what that quirk would be?
The GPU seems to have broken ATS, or require driver setup to make ATS
work. Anyhow, ATS is unstable for Linux t
On Fri, Nov 06, 2020 at 05:51:18AM +, Merger, Edgar [AUTOSOL/MAS/AUGS]
wrote:
> With Kernel 5.9.3 kernel-parameter pci=noats the system is running for
> 19hours now in reboot-test without the error to occur.
Thanks. So I guess the GPU needs a quirk to disable ATS on it. Can you
please send me
On Thu, Nov 05, 2020 at 11:58:30AM +, Merger, Edgar [AUTOSOL/MAS/AUGS]
wrote:
> One remark:
> With kernel-parameter pci=noats in dmesg there is
>
> [ 10.128463] kfd kfd: Error initializing iommuv2
That is expected. IOMMUv2 depends on ATS support.
Regards,
Joerg
__
; to "General Electric" or "Emerson".
>
> Best regards,
> Edgar
>
> -Original Message-
> From: jroe...@suse.de
> Sent: Mittwoch, 4. November 2020 09:53
> To: Merger, Edgar [AUTOSOL/MAS/AUGS]
> Cc: iommu@lists.linux-foundation.org
> Subject: [EXTERNA
Hi Edgar,
On Fri, Oct 30, 2020 at 02:26:23PM +, Merger, Edgar [AUTOSOL/MAS/AUGS]
wrote:
> With one board we have a boot-problem that is reproducible at every ~50 boot.
> The system is accessible via ssh and works fine except for the Graphics. The
> graphics is off. We don´t see a screen. Plea
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
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 Tue, Jun 11, 2019 at 05:27:15PM +, Prakhya, Sai Praneeth wrote:
> 1. Since we already have "type" file, which is "read-only", we could make it
> R/W.
>
> The present value shows the existing type of default domain.
> If user wants to change it (Eg: from DMA to IDENTITY or vice versa), he
On Tue, May 14, 2019 at 10:55:46AM -0400, Qian Cai wrote:
> Jroedel, I am wondering what the plan for 41e59a41fc5d1 (iommu tree) or this
> patch to be pushed to the linux-next or mainline...
Looks like I applied that patch directly to the master branch, which is
not what goes upstream. I cherry-pi
On Tue, Nov 24, 2015 at 02:05:12PM -0800, Shaohua Li wrote:
> The lib/iommu-common.c uses a bitmap and a lock. This implementation
> actually uses a percpu_ida which completely avoids locking. It would be
> possible to make lib/iommu-common.c use percpu_ida too if somebody wants
> to do it, but I t
Hi Will,
Thanks for having a look!
On Fri, Jun 05, 2015 at 03:22:06PM +0100, Will Deacon wrote:
>
> Most of this looks fine to me, modulo by comments about the dm regions
> (which I'm not sure how to implement for ARM).
When there are no direct mapping requirements from the firmware on ARM,
you
Hi Will,
On Fri, Jun 05, 2015 at 03:17:50PM +0100, Will Deacon wrote:
> On Thu, May 28, 2015 at 05:41:33PM +0100, Joerg Roedel wrote:
> > +/**
> > + * struct iommu_dm_region - descriptor for a direct mapped memory region
> > + * @list: Linked list pointers
> > + * @start: System physical start add
On Tue, May 05, 2015 at 01:22:24PM +, Varun Sethi wrote:
> > Which means the driver was only buildable on e500mc and now you are
> > telling me that this is broken. What am I missing?
> >
> PPC_E500MC dependency is fine, but with the COMPIL_TEST flag ("or"
> condition) the PAMU driver code w
Hi Varun,
On Wed, Apr 08, 2015 at 01:24:16PM +, Varun Sethi wrote:
> Following issue was observed while building (compile test) for a
> non-powerpc (e500mc) based platform. The pamu driver includes a file
> which is available in the architecture include directory. Should we
> move the header f
On Wed, Nov 26, 2014 at 05:47:07PM +, Will Deacon wrote:
> Joerg, would you expect this to go via your tree or via something broader
> like arm-soc, with your Ack on the IOMMU bits (patches 1, 3 and 4) instead?
Hmm, I don't like the idea of storing private data in iommu_ops. But
given that thi
On Mon, Oct 27, 2014 at 04:02:16PM +, Will Deacon wrote:
> On Mon, Oct 27, 2014 at 11:30:33AM +, Laurent Pinchart wrote:
> > I'm not sure to follow you here. Aren't we already exposing masters that
> > master through multiple IOMMUs as single instances of struct device ?
>
> Hmm, yes, now
On Mon, Oct 20, 2014 at 07:42:01PM +0100, Will Deacon wrote:
> On Mon, Oct 20, 2014 at 04:39:15PM +0100, Will Deacon wrote:
> > On Mon, Oct 13, 2014 at 02:06:15PM +0100, Antonios Motakis wrote:
> > > This patch series applies to Joerg Roedel's iommu/next branch, commit
> > > 09b5269a.
> > > It rep
On Tue, Sep 02, 2014 at 04:01:32PM +0200, Arnd Bergmann wrote:
> This is an artifact of the API being single-instance at the moment.
> We might not in fact need it, I was just trying to think of things
> that naturally fit in there and that are probably already linked
> together in the individual i
21 matches
Mail list logo
