From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [PATCH] drm/i915: fix vxd392 memory corruption on VLV and >4GB Date: Sat, 8 Mar 2014 11:07:50 +0100 Message-ID: <20140308100749.GJ25837@phenom.ffwll.local> References: <1394241231-17242-1-git-send-email-sean.v.kelley@intel.com> <20140308092554.GE20302@nuc-i3427.alporthouse.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by gabe.freedesktop.org (Postfix) with ESMTP id B3ADAFAA6D for ; Sat, 8 Mar 2014 02:07:54 -0800 (PST) Received: by mail-ea0-f172.google.com with SMTP id l9so2790240eaj.3 for ; Sat, 08 Mar 2014 02:07:53 -0800 (PST) Content-Disposition: inline In-Reply-To: <20140308092554.GE20302@nuc-i3427.alporthouse.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces@lists.freedesktop.org Errors-To: intel-gfx-bounces@lists.freedesktop.org To: Chris Wilson , Sean V Kelley , intel-gfx@lists.freedesktop.org, Fei Jiang , Alan Cox List-Id: intel-gfx@lists.freedesktop.org On Sat, Mar 08, 2014 at 09:25:54AM +0000, Chris Wilson wrote: > On Fri, Mar 07, 2014 at 05:13:51PM -0800, Sean V Kelley wrote: > > On VLV systems addressing 4GB of memory or greater, memory corruption was seen > > when initializing and attempting to render VP8 hardware decode surfaces using > > the VXD392 HW IP block. > > > > The VXD MMU has a limitation to addressing only 32bits. On 64bit kernel and > > user space builds this can cause problems for use of that IP block. > > > > When 2G memory is inserted, fw buffer pfn was at 0x5f62b, which is below 4GB. > > While for 4GB of memory the fw buffer pfn was 0x162ea9 with a physical address > > at 0x162ea9000, above 4GB. > > > > So although the memory is 4GB in the test hardware (Bayleybay CRB), a large > > physical region (for example 3G-4G) can be occupied by onboard system > > resources. > > > > Enabling ZONE_DMA32 and setting the correct mask DMA for this device > > resolves the issue kernel side. > > That's a shame. I guess this is restricted to a subset of byt? > > > Cc: Jesse Barnes > > Cc: Alan Cox > > Cc: Fei Jiang > > Signed-off-by: Sean V Kelley > > --- > > drivers/gpu/drm/i915/i915_dma.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c > > index e4d2b9f..b8c6efc 100644 > > --- a/drivers/gpu/drm/i915/i915_dma.c > > +++ b/drivers/gpu/drm/i915/i915_dma.c > > @@ -1636,7 +1636,7 @@ int i915_driver_load(struct drm_device *dev, unsigned long flags) > > * behaviour if any general state is accessed within a page above 4GB, > > * which also needs to be handled carefully. > > Also add a sentence here giving a quick explanation as to why we need to > quirk IS_VLV as well. > > > */ > > - if (IS_BROADWATER(dev) || IS_CRESTLINE(dev)) > > + if (IS_BROADWATER(dev) || IS_CRESTLINE(dev) || IS_VALLEYVIEW(dev)) > > dma_set_coherent_mask(&dev->pdev->dev, DMA_BIT_MASK(32)); Nack because: - the vxd392 isn't merged upstream - we can allocate shared buffers from vxd392 and have the restriction just there - for shared buffers allocated in i915 imo the right approach is to move offending pages around when vxd392 attaches - i.e. we need to check the attached device's dma masks and if there's something offending, migrate the buffer with a differen shmem allocation mask. Iirc Alan Cox had patches to do just that (but for swapoff, still the same idea though). Cheers, Daniel > > > > aperture_size = dev_priv->gtt.mappable_end; > > -- > Chris Wilson, Intel Open Source Technology Centre > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch