On Saturday 08 Mar 2014 at 11:07:50 (+0100), Daniel Vetter writes : > 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 Sure, I just wanted to get some feedback. Yeah, in it's current state my driver port will not be acceptable upstream until I cleanup the deprecated API from the driver, remove my wrappers/hooks from the i915, and make similar API changes to the user mode driver. That is a work-in-progress for me now. > - 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). Will keep that in mind. I have been getting some feedback from Alan too. Thanks, Sean > > 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
Attachment:
pgpSzNgrtDe9j.pgp
Description: PGP signature
_______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
