1 insertion(+), 1 deletion(-)
Acked-by: Joerg Roedel
mu/io-pgtable-arm.c | 51 --
> include/linux/io-pgtable.h | 4 +++
> 2 files changed, 46 insertions(+), 9 deletions(-)
Acked-by: Joerg Roedel
On Tue, Jan 30, 2024 at 12:14:54PM -0400, Jason Gunthorpe wrote:
> Previously with tegra-smmu, even with CONFIG_IOMMU_DMA, the default domain
> could have been left as NULL. The NULL domain is specially recognized by
> host1x_client_iommu_attach() as meaning it is not the DMA domain and
> should be
On Thu, Dec 07, 2023 at 02:03:07PM -0400, Jason Gunthorpe wrote:
> Jason Gunthorpe (7):
> iommu: Remove struct iommu_ops *iommu from arch_setup_dma_ops()
> iommmu/of: Do not return struct iommu_ops from of_iommu_configure()
> iommu/of: Use -ENODEV consistently in of_iommu_configure()
> iomm
On Mon, Aug 21, 2023 at 09:51:13AM -0300, Jason Gunthorpe wrote:
> So now that Joerg has dropped it - what is your big idea to make the
> locking actually work right?
I am not opposed to the general idea. When putting it into the tree I
wasn't aware how many users still need to be adapted to prope
On Mon, Aug 21, 2023 at 12:06:40PM +0100, Robin Murphy wrote:
> The solution is to drop those locking patches entirely and rethink the whole
> thing.
Agreed, that was exactly what I thought when looking at this patch.
I dropped the original 10 patches and the 4 fixes on-top from the IOMMU
tree. T
On Mon, Jan 23, 2023 at 04:35:53PM -0400, Jason Gunthorpe wrote:
> Jason Gunthorpe (10):
> iommu: Add a gfp parameter to iommu_map()
> iommu: Remove iommu_map_atomic()
> iommu: Add a gfp parameter to iommu_map_sg()
> iommu/dma: Use the gfp parameter in __iommu_dma_alloc_noncontiguous()
>
On Fri, Jan 20, 2023 at 01:53:40PM -0400, Jason Gunthorpe wrote:
> > Well, having GFP parameters is not a strict kernel convention. There are
> > places doing it differently and have sleeping and atomic variants of
> > APIs. I have to say I like the latter more. But given that this leads to
> > an
On Fri, Jan 06, 2023 at 01:24:11PM -0400, Jason Gunthorpe wrote:
> I think it is just better to follow kernel convention and have
> allocation functions include the GFP because it is a clear signal to
> the user that there is an allocation hidden inside the API. The whole
> point of gfp is not to h
On Tue, Aug 16, 2022 at 06:28:02PM +0100, Robin Murphy wrote:
> Robin Murphy (3):
> iommu/dma: Clean up Kconfig
> iommu/dma: Move public interfaces to linux/iommu.h
> iommu/dma: Make header private
Applied, thanks.
> include/linux/dma-iommu.h | 93 -
S
l
> conversion series first, though. This time with the linux-media mailinglist
> included :-)
>
> I would need your Ack for the iommu patches as well, of course.
Okay, makes sense. IOMMU parts are
Acked-by: Joerg Roedel
Hi Robin,
On Wed, Nov 24, 2021 at 02:05:15PM +, Robin Murphy wrote:
> Bah, seems like tegra-vic needs the same treatment too, but wasn't in my
> local config. Should I squash that into a respin of this patch on the
> grounds of being vaguely related, or would you prefer it separate?
In case t
On Fri, Nov 12, 2021 at 06:54:54PM +0800, Yong Wu wrote:
> Yong Wu (14):
> dt-binding: mediatek: Get rid of mediatek, larb for multimedia HW
> iommu/mediatek-v1: Free the existed fwspec if the master dev already
> has
> iommu/mediatek: Return ENODEV if the device is NULL
> iommu/mediate
On Fri, Oct 01, 2021 at 04:34:23PM +0200, Boris Brezillon wrote:
> +/*
> + * Mapping is only accessed by the device behind the iommu. That means other
> + * devices or CPUs are not expected to access this physical memory region,
> + * and the MMU driver can safely restrict the shareability domain t
size nor member offset changes to struct ivhd_entry.
> "objdump -d" shows no object code changes.
>
> Cc: Joerg Roedel
> Cc: Will Deacon
> Cc: io...@lists.linux-foundation.org
> Signed-off-by: Kees Cook
Acked-by: Joerg Roedel
On Tue, Jul 27, 2021 at 05:26:11PM -0500, Tom Lendacky wrote:
> The mem_encrypt_active() function has been replaced by prot_guest_has(),
> so remove the implementation.
>
> Signed-off-by: Tom Lendacky
Reviewed-by: Joerg Roedel
On Tue, Jul 27, 2021 at 05:26:12PM -0500, Tom Lendacky wrote:
> The mem_encrypt_active() function has been replaced by prot_guest_has(),
> so remove the implementation.
>
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: Borislav Petkov
> Signed-off-by: Tom Lendacky
Reviewed-by: Joerg Roedel
On Tue, Jul 27, 2021 at 05:26:09PM -0500, Tom Lendacky wrote:
> @@ -48,7 +47,7 @@ static void sme_sev_setup_real_mode(struct
> trampoline_header *th)
> if (prot_guest_has(PATTR_HOST_MEM_ENCRYPT))
> th->flags |= TH_FLAGS_SME_ACTIVE;
>
> - if (sev_es_active()) {
> + if
Signed-off-by: Tom Lendacky
Reviewed-by: Joerg Roedel
er memory
> encryption technologies, the use of PATTR_HOST_MEM_ENCRYPT can be
> updated, as required, to use PATTR_SME.
>
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: Borislav Petkov
> Cc: Dave Hansen
> Cc: Andy Lutomirski
> Cc: Peter Zijlstra
> Cc: Joerg Roedel
> Cc:
nsen
> Cc: Andy Lutomirski
> Cc: Peter Zijlstra
> Co-developed-by: Andi Kleen
> Signed-off-by: Andi Kleen
> Co-developed-by: Kuppuswamy Sathyanarayanan
>
> Signed-off-by: Kuppuswamy Sathyanarayanan
>
> Signed-off-by: Tom Lendacky
Reviewed-by: Joerg Roedel
>
> Signed-off-by: Tom Lendacky
Reviewed-by: Joerg Roedel
include/soc/mediatek/smi.h| 20
> 28 files changed, 92 insertions(+), 321 deletions(-)
So this is likely not going through the IOMMU tree, given Matthias has
reviewed the IOMMU changes you can add my Acked-by: Joerg Roedel
On Fri, Apr 30, 2021 at 08:20:10PM +0800, Kevin Tang wrote:
> Cc Robin & Joerg
This is just some GPU internal MMU being used here, it seems. It doesn't
use the IOMMU core code, so no Ack needed from the IOMMU side.
Regards,
Joerg
On Thu, Apr 01, 2021 at 05:52:36PM +0200, Christoph Hellwig wrote:
> Diffstat:
> arch/powerpc/include/asm/fsl_pamu_stash.h | 12
> drivers/gpu/drm/msm/adreno/adreno_gpu.c |5
> drivers/iommu/amd/iommu.c | 23
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 75 -
On Mon, Mar 01, 2021 at 09:42:40AM +0100, Christoph Hellwig wrote:
> Diffstat:
> arch/powerpc/include/asm/fsl_pamu_stash.h | 12
> drivers/gpu/drm/msm/adreno/adreno_gpu.c |2
> drivers/iommu/amd/iommu.c | 23
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 85 -
On Tue, Oct 06, 2020 at 08:23:06AM +0100, Christoph Hellwig wrote:
> If people want to use the "raw" IOMMU API with not cache coherent
> devices we'll need a cache maintainance API that goes along with it.
> It could either be formally part of the IOMMU API or be separate.
The IOMMU-API does not c
On Fri, Aug 28, 2020 at 07:12:11PM +0300, Andy Shevchenko wrote:
> 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
On Mon, Aug 17, 2020 at 03:01:25PM -0700, Rob Clark wrote:
> Jordan Crouse (12):
> iommu/arm-smmu: Pass io-pgtable config to implementation specific
> function
> iommu/arm-smmu: Add support for split pagetables
> iommu/arm-smmu: Prepare for the adreno-smmu implementation
> iommu/arm-smm
Hi Marek,
On Tue, May 12, 2020 at 11:00:23AM +0200, Marek Szyprowski wrote:
> ---
> include/linux/iommu.h | 16
> 1 file changed, 16 insertions(+)
Some nits below, with those fixed:
Acked-by: Joerg Roedel
> diff --git a/include/linux/iommu.h b/include/l
On Sat, Nov 02, 2019 at 06:56:28PM +0100, Thierry Reding wrote:
> Thierry Reding (9):
> iommu: Document iommu_fwspec::flags field
> iommu: Add dummy dev_iommu_fwspec_get() helper
Acked-by: Joerg Roedel
___
dri-devel mailing list
Hi Thierry,
On Mon, Sep 16, 2019 at 05:54:43PM +0200, Thierry Reding wrote:
> > Joerg, to summarize: the proposal here is to move the declaration of the
> > iommu_fwspec outside of the IOMMU_API guard and provide a dummy
> > implementation of dev_iommu_fwspec_get() to allow this code to be built
>
On Fri, Sep 06, 2019 at 02:44:01PM -0700, Rob Clark wrote:
> @@ -674,7 +674,7 @@ int iommu_group_add_device(struct iommu_group *group,
> struct device *dev)
>
> mutex_lock(&group->mutex);
> list_add_tail(&device->list, &group->devices);
> - if (group->domain)
> + if (group->d
On Fri, Aug 16, 2019 at 02:47:53PM +0200, Vlastimil Babka wrote:
> On 8/15/19 9:13 PM, Petr Vandrovec wrote:
> > [ 18.110985] DMAR: [DMA Write] Request device [07:00.1] fault addr
> > fffe [fault reason 02] Present bit in context entry is clear
>
> Worth reporting as well, not nice regressi
Hi Rob,
On Tue, Jul 02, 2019 at 01:26:18PM -0700, Rob Clark wrote:
> 1) In some cases the bootloader takes the iommu out of bypass and
>enables the display. This is in particular a problem on the aarch64
>laptops that exist these days, and modern snapdragon android devices.
>(Older de
On Wed, Apr 24, 2019 at 09:15:25PM +0200, Heiner Kallweit wrote:
> Use new helper pci_dev_id() to simplify the code.
>
> Signed-off-by: Heiner Kallweit
Reviewed-by: Joerg Roedel
> ---
> drivers/iommu/amd_iommu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
On Wed, Apr 24, 2019 at 09:16:10PM +0200, Heiner Kallweit wrote:
> Use new helper pci_dev_id() to simplify the code.
>
> Signed-off-by: Heiner Kallweit
Reviewed-by: Joerg Roedel
> ---
> drivers/iommu/intel-iommu.c | 2 +-
> drivers/iommu/intel_irq_remapping.c
e final say up to Joerg.
No objection from my side with merging this via DRM. With Robin's
concerns addressed:
Acked-by: Joerg Roedel
>
> Thanks,
> Robin.
>
> ->8-
> diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
> inde
On Wed, Jan 23, 2019 at 05:02:38PM +0200, Joonas Lahtinen wrote:
> We have many reports where just having intel_iommu=on (and using the
> system normally, without any virtualization stuff going on) will cause
> unexplained GPU hangs. For those users, simply switching to
> intel_iommu=igfx_off solve
On Tue, Jan 22, 2019 at 04:48:26PM +0200, Joonas Lahtinen wrote:
> According to our IOMMU folks there exists some desire to be able to assign
> the iGFX device aka have intel_iommu=on instead of intel_iommu=igfx_off
> due to how the devices might be grouped in IOMMU groups. Even when you
> would no
Hi Daniel,
On Tue, Jan 22, 2019 at 11:46:39AM +0100, Daniel Vetter wrote:
> Note that the string of platforms which have various issues with iommu
> and igfx is very long, thus far we only disabled it where there's no
> workaround to stop it from hanging the box, but otherwise left it
> enabled. S
On Fri, Jan 18, 2019 at 12:17:05PM +, Eric Wong wrote:
> @@ -5411,6 +5411,7 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e20,
> quirk_iommu_g4x_gfx);
> DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e30, quirk_iommu_g4x_gfx);
> DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x2e40, q
From: Joerg Roedel
Running kfdtest on Kaveri triggers a kernel NULL-ptr dereference:
BUG: unable to handle kernel NULL pointer dereference at
PGD 42c017067 P4D 42c017067 PUD 40f071067 PMD 0
Oops: 0010 [#1] SMP NOPTI
CPU: 0 PID: 13107 Comm
From: Joerg Roedel
Running kfdtest on an AMD Carizzo flooded the kernel log
with thousands of these "was not implemented" messages,
making it impossible to see other messages there.
Ratelimit the messages to prevent user-space from flooding
the kernel log.
Signed-off-by: Jo
On Fri, Jul 27, 2018 at 11:13:31AM -0600, Rob Herring wrote:
> I don't follow why we need a property rather than being implied by the
> device's (the GPU) compatible string.
There might be devices where either setup works, with or without IOMMU
translation, and the firmware can set the property de
On Fri, Jul 27, 2018 at 05:10:22PM +0300, Dmitry Osipenko wrote:
> I'm not sure what you guys are meaning by the "firmware", could you elaborate
> please? Do you mean the Open Firmware and hence the devicetree or what?
Yes, I think the best way to request this is using a device-tree
property. Let
On Fri, Jul 27, 2018 at 02:16:18AM +0300, Dmitry Osipenko wrote:
> The proposed solution adds a new option to the base device driver
> structure that allows device drivers to explicitly convey to the drivers
> core that the implicit IOMMU backing for devices must not happen.
Why is IOMMU mapping a
On Mon, Jul 09, 2018 at 10:36:43AM +0200, Daniel Vetter wrote:
> #define for_each_active_drhd_unit(drhd)
> \
> list_for_each_entry_rcu(drhd, &dmar_drhd_units, list) \
> - if (drhd->ignored) {} else
> + for_each_if (!drhd
Hi Lucas,
On Thu, Aug 17, 2017 at 03:32:38PM +0200, Lucas Stach wrote:
> I don't think this is necessary. Etnaviv has managed and batched up TLB
> flushes from day 1, as they don't happen through the MMU MMIO interface,
> but through the GPU command stream.
>
> So if my understanding of this seri
On Thu, Aug 17, 2017 at 04:30:48PM +0200, Lucas Stach wrote:
> Yeah, the IOMMU API being used internally is a historical accident, that
> we didn't get around to rectify yet. It's on my things-we-need-to-do
> list to prune the usage of the IOMMU API in etnaviv.
Okay, so for the time being, I drop
On Thu, Aug 17, 2017 at 04:03:54PM +0200, Lucas Stach wrote:
> There is no IOMMU driver in use. Etnaviv just uses part of the IOMMU API
> to manage the GPU internal MMU, see
> drivers/gpu/drm/etnaviv/etnaviv_iommu.c
That looks like a very fragile construct, because it relies on internal
behavior o
From: Joerg Roedel
The map and unmap functions of the IOMMU-API changed their
semantics: They do no longer guarantee that the hardware
TLBs are synchronized with the page-table updates they made.
To make conversion easier, new synchronized functions have
been introduced which give these
From: Joerg Roedel
The map and unmap functions of the IOMMU-API changed their
semantics: They do no longer guarantee that the hardware
TLBs are synchronized with the page-table updates they made.
To make conversion easier, new synchronized functions have
been introduced which give these
From: Joerg Roedel
The map and unmap functions of the IOMMU-API changed their
semantics: They do no longer guarantee that the hardware
TLBs are synchronized with the page-table updates they made.
To make conversion easier, new synchronized functions have
been introduced which give these
From: Joerg Roedel
The map and unmap functions of the IOMMU-API changed their
semantics: They do no longer guarantee that the hardware
TLBs are synchronized with the page-table updates they made.
To make conversion easier, new synchronized functions have
been introduced which give these
From: Joerg Roedel
The map and unmap functions of the IOMMU-API changed their
semantics: They do no longer guarantee that the hardware
TLBs are synchronized with the page-table updates they made.
To make conversion easier, new synchronized functions have
been introduced which give these
From: Joerg Roedel
The map and unmap functions of the IOMMU-API changed their
semantics: They do no longer guarantee that the hardware
TLBs are synchronized with the page-table updates they made.
To make conversion easier, new synchronized functions have
been introduced which give these
> 2 files changed, 8 insertions(+), 2 deletions(-)
Not sure what the context here is or if the patches need to merged with
the rest of the patch-set, so:
Acked-by: Joerg Roedel
___
dri-devel mailing list
dri-devel@lis
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/iommu/tegra-gart.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Acked-by: Joerg Roedel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Fri, Jul 15, 2016 at 05:32:02PM +0200, Matthias Brugger wrote:
> >The drm rockchip patches are dependent on iommu/rockchip patches, can
> >you also apply these patches together? So that can avoid compile problem.
> >
>
> While at it. I don't see patch 8 (iommu/Kconfig) in linux-next.
> I suppos
On Thu, Jul 07, 2016 at 10:18:02PM +0900, Tomasz Figa wrote:
> This is probably because we missed this hidden dependency and decided
> to push the IOMMU part separately through the IOMMU tree. I guess we
> can remove the offending patch from the IOMMU tree and let the DRM
> tree include it based on
On Fri, Jun 24, 2016 at 10:13:25AM +0800, Shunqian Zheng wrote:
> drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 100 +++--
> drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 3 +
> drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 221
> ++--
> drivers/gpu/drm/rockchip/
On Tue, Jun 21, 2016 at 03:18:49PM +0200, Heiko Stübner wrote:
> Am Dienstag, 21. Juni 2016, 14:54:35 schrieb Joerg Roedel:
> > Hi Tomasz,
> >
> > On Tue, Jun 21, 2016 at 09:42:16PM +0900, Tomasz Figa wrote:
> > > In simple words, DRM patches depend on IOMMU patche
Hi Tomasz,
On Tue, Jun 21, 2016 at 09:42:16PM +0900, Tomasz Figa wrote:
> In simple words, DRM patches depend on IOMMU patches.
>
> More precisely: The IOMMU patches alone are supposed to not break
> anything. Same goes for the first DRM patch (7/8). Only second DRM
> patch (8/8) depends on chang
On Tue, Jun 21, 2016 at 01:34:33PM +0900, Tomasz Figa wrote:
> This series intends mostly to enable support for ARM64 architecture
> in the rockchip-iommu driver. On the way to do so, some bugs are also
> fixed.
>
> The most important changes here are:
> - making the Rockchip IOMMU driver use DMA
On Fri, Jun 03, 2016 at 03:21:30PM +0100, Russell King wrote:
> Convert DT component matching to use component_match_add_release().
>
> Signed-off-by: Russell King
> ---
> drivers/iommu/mtk_iommu.c | 14 ++
> 1 file changed, 6 insertions(+), 8 deletions(-)
Applied, thanks.
On Sat, Dec 26, 2015 at 09:26:32PM +0800, chengang at emindsoft.com.cn wrote:
> From: Chen Gang
>
> It is architecture specific mechanism header, not generic header, so
> move it to arch/x86/include/asm.
There might be future non-x86 hardware which also has an amd iommu, so
the header file shoul
Hi Alex, Christian,
I recently tested v4.3-rc4 on one of my AMD IOMMU boxes with a radeon
GPU in it:
mars:~ # lspci -k -s 08:00.0
08:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI]
Juniper XT [Radeon HD 5770]
Subsystem: PC Partner Limited / Sapphire Technology Devi
On Tue, Oct 06, 2015 at 09:13:11PM +0800, Jiang Liu wrote:
> We are on leave for Chinese National Holiday and has limited
> access to my working environment. It would be appreciated if you could
> help to send out a patch for it. Otherwise I will send out a patch
> within 2-3 days.
Okay, I j
Hi Jiang,
On Sat, Oct 03, 2015 at 03:36:35PM +0800, Jiang Liu wrote:
> So to summary, I think we only need following change to fix the
> regression:
> int pcibios_alloc_irq(struct pci_dev *dev)
> {
> + if (pci_dev_msi_enabled(dev))
> + return -EBUSY;
>
> What do you think?
Yes,
On Wed, Sep 30, 2015 at 07:36:19PM +0200, Borislav Petkov wrote:
> Right, so this fixes the issue on my box, courtesy of Joerg. WE
> basically don't disable the IRQ on MSI-enabled devices. The AMD IOMMU
> uses a barebones PCI device but not a PCI driver, which would be an
> overkill.
Well, not onl
On Thu, Oct 01, 2015 at 01:00:44AM +0800, Jiang Liu wrote:
> Thanks Joerg, that makes sense. If some driver tries to binding to the
> IOMMU device, it will trigger the scenario as you described. For
> example, Xen backend driver will try to probe all PCI devices
> if enabled. I will do more invest
On Wed, Sep 30, 2015 at 03:45:39PM +0800, Jiang Liu wrote:
> So we need to figure out why we got irq number 0 after enabling
> MSI for AMD IOMMU device. The only hint I got is that iommu driver just
> grabbing the PCI device without providing a PCI device driver for IOMMU
> PCI device, we have solv
On Wed, Nov 26, 2014 at 01:37:51AM +0100, Heiko Stübner wrote:
>
> Joerg, is your arm/rockchip branch [0] considered stable?
>
> [0]
> https://git.kernel.org/cgit/linux/kernel/git/joro/iommu.git/log/?h=arm/rockchip
>
Yes, this branch will not be rebased. It can be pulled into another
tree.
On Fri, Jul 11, 2014 at 12:53:54AM +0300, Oded Gabbay wrote:
> This patch creates a workaround for a bug in amd_iommu driver, where
> the driver doesn't save all necessary information when going to
> suspend. The workaround removes a device from the IOMMU device list
> on suspend and register a re
On Fri, Jul 11, 2014 at 12:53:26AM +0300, Oded Gabbay wrote:
> mm/rmap.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/mm/rmap.c b/mm/rmap.c
> index 196cd0c..73d4c3d 100644
> --- a/mm/rmap.c
> +++ b/mm/rmap.c
> @@ -1231,13 +1231,17 @@ static int try_to_unmap_one
Hi Rob,
On Fri, Sep 27, 2013 at 11:28:36AM -0400, Rob Clark wrote:
> But I am not the right one to merge this one. And, well, if there is
> a way to make this work without msm_iommu_get_ctx(), I am interested
> in some hints ;-)
>
> Of the other two, 1/3 looks fine and I'll pull that in. And I'
The function msm_iommu_get_ctx() is needed buy the MSM-GPU
driver with and wiithout IOMMU compiled in. Make the
function available when no IOMMU driver is there.
Signed-off-by: Joerg Roedel
---
drivers/iommu/msm_iommu.h |7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/iommu
The include file has been moved but this file was not
updated, so compile breaks.
Signed-off-by: Joerg Roedel
---
drivers/gpu/drm/msm/Makefile |3 ---
drivers/gpu/drm/msm/msm_drv.c |5 -
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/Makefile b
The include file has been removed and the file does not
need it anyway, so remove it. Fixes a compile error.
Signed-off-by: Joerg Roedel
---
drivers/gpu/drm/msm/mdp4/mdp4_kms.c |2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/mdp4/mdp4_kms.c
b/drivers/gpu/drm/msm
On Sat, Apr 16, 2011 at 02:54:04PM -0400, Jerome Glisse wrote:
> If you want to go the printk way you can add printk before each test
> ring_test, ib_test in r600.c this 2 functions are the own that might
> trigger the first GPU gart activities.
Okay, I found the place in source that triggers thi
On Sat, Apr 16, 2011 at 02:54:04PM -0400, Jerome Glisse wrote:
> If you want to go the printk way you can add printk before each test
> ring_test, ib_test in r600.c this 2 functions are the own that might
> trigger the first GPU gart activities.
Okay, I found the place in source that triggers thi
On Fri, Apr 15, 2011 at 12:11:28PM -0400, Jerome Glisse wrote:
> Do you also got the write if you load radeon with radeon.no_wb=1 ?
> I think at this address it's the wb page, or maybe the cp as wb likely
> take only one page
radeon.no_wb=1 makes no difference. The box still reboots.
Joer
On Fri, Apr 15, 2011 at 12:18:02PM -0700, Yinghai Lu wrote:
> On 04/15/2011 12:06 PM, Ingo Molnar wrote:
>
> >
> > Joerg, mind submitting it with a changelog that includes everything we
> > learned
> > about this bug and all the Tested-by's in place?
> >
> > Is anyone of the opinion that we sh
On Fri, Apr 15, 2011 at 09:06:41PM +0200, Ingo Molnar wrote:
>
> * Alexandre Demers wrote:
>
> > On 11-04-15 10:27 AM, Joerg Roedel wrote:
> > > On Fri, Apr 15, 2011 at 10:16:59AM -0400, Alexandre Demers wrote:
> > >> Ok, I'll test it today. Should
On Fri, Apr 15, 2011 at 12:11:28PM -0400, Jerome Glisse wrote:
> Do you also got the write if you load radeon with radeon.no_wb=1 ?
> I think at this address it's the wb page, or maybe the cp as wb likely
> take only one page
radeon.no_wb=1 makes no difference. The box still reboots.
Joer
On Fri, Apr 15, 2011 at 12:18:02PM -0700, Yinghai Lu wrote:
> On 04/15/2011 12:06 PM, Ingo Molnar wrote:
>
> >
> > Joerg, mind submitting it with a changelog that includes everything we
> > learned
> > about this bug and all the Tested-by's in place?
> >
> > Is anyone of the opinion that we sh
On Fri, Apr 15, 2011 at 09:06:41PM +0200, Ingo Molnar wrote:
>
> * Alexandre Demers wrote:
>
> > On 11-04-15 10:27 AM, Joerg Roedel wrote:
> > > On Fri, Apr 15, 2011 at 10:16:59AM -0400, Alexandre Demers wrote:
> > >> Ok, I'll test it today. Should
On Fri, Apr 15, 2011 at 03:16:50PM +0200, Ingo Molnar wrote:
> Ok, but how did the allocation changes start triggering this error in
> v2.6.39-rc1? There must still be some layout specific thing here, right?
> Do we understand the details of that as well?
Well, thinking again about this, the GPU
On Fri, Apr 15, 2011 at 03:16:50PM +0200, Ingo Molnar wrote:
> Ok, but how did the allocation changes start triggering this error in
> v2.6.39-rc1? There must still be some layout specific thing here, right?
> Do we understand the details of that as well?
No, I must admit that I lack enough knowl
On Fri, Apr 15, 2011 at 04:04:45PM +0200, Andreas Herrmann wrote:
> What about tagging this patch for stable/longterm releases?
>
> Potentially there are other cases where certain combinations of
> hardware(GPUs)/drivers/whatsoever might trigger a GartTlbWlkErr. If
> the BIOS doesn't follow the BK
On Fri, Apr 15, 2011 at 10:16:59AM -0400, Alexandre Demers wrote:
> Ok, I'll test it today. Should I apply it on a clean rc3 without any of
> the other patches?
Yes, apply it just on -rc3 without any other patch.
>
> BTW, may I suggest adding the info under bug 33012 in kernel bugzilla?
> This c
On Wed, Apr 13, 2011 at 07:33:40PM -0700, Linus Torvalds wrote:
> we definitely want to also understand the reason for things not
> working, even if we do revert..
Okay, here it is.
After experimenting with different configurations for the north-bridge
it turned out that a GART related MCE fires
-off-by: Joerg Roedel
---
arch/x86/include/asm/msr-index.h |4
arch/x86/kernel/cpu/amd.c| 19 +++
2 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
index fd5a1f3..3cce714 100644
On Fri, Apr 15, 2011 at 10:26:34AM +0200, Michel D?nzer wrote:
> On Don, 2011-04-14 at 23:09 +0200, Joerg Roedel wrote:
> > On Thu, Apr 14, 2011 at 10:28:43AM -0400, Alex Deucher wrote:
> > > On Thu, Apr 14, 2011 at 4:56 AM, Joerg Roedel wrote:
> > > > And this
On Thu, Apr 14, 2011 at 05:34:46PM -0400, Alex Deucher wrote:
> On Thu, Apr 14, 2011 at 5:09 PM, Joerg Roedel wrote:
> > Actually, the nb gart is part of the cpu. It is part of the cpu north
> > bridge and can translate io and cpu accesses. In fact, it is a remapper
> &g
On Fri, Apr 15, 2011 at 03:16:50PM +0200, Ingo Molnar wrote:
> Ok, but how did the allocation changes start triggering this error in
> v2.6.39-rc1? There must still be some layout specific thing here, right?
> Do we understand the details of that as well?
Well, thinking again about this, the GPU
On Fri, Apr 15, 2011 at 03:16:50PM +0200, Ingo Molnar wrote:
> Ok, but how did the allocation changes start triggering this error in
> v2.6.39-rc1? There must still be some layout specific thing here, right?
> Do we understand the details of that as well?
No, I must admit that I lack enough knowl
On Fri, Apr 15, 2011 at 04:04:45PM +0200, Andreas Herrmann wrote:
> What about tagging this patch for stable/longterm releases?
>
> Potentially there are other cases where certain combinations of
> hardware(GPUs)/drivers/whatsoever might trigger a GartTlbWlkErr. If
> the BIOS doesn't follow the BK
On Fri, Apr 15, 2011 at 10:16:59AM -0400, Alexandre Demers wrote:
> Ok, I'll test it today. Should I apply it on a clean rc3 without any of
> the other patches?
Yes, apply it just on -rc3 without any other patch.
>
> BTW, may I suggest adding the info under bug 33012 in kernel bugzilla?
> This c
1 - 100 of 127 matches
Mail list logo
