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 <jbarnes@xxxxxxxxxxxxxxxx> > > Cc: Alan Cox <alan@xxxxxxxxxxxxxxx> > > Cc: Fei Jiang <fei.jiang@xxxxxxxxx> > > Signed-off-by: Sean V Kelley <sean.v.kelley@xxxxxxxxx> > > --- > > 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@xxxxxxxxxxxxxxxxxxxxx > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
