[Intel-gfx] [PATCH] drm/i915: fix vxd392 memory corruption on VLV and >4GB

[Sean V Kelley]

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 at virtuousgeek.org>
> > > Cc: Alan Cox <alan at linux.intel.com>
> > > Cc: Fei Jiang <fei.jiang at intel.com>
> > > Signed-off-by: Sean V Kelley <sean.v.kelley at intel.com>
> > > ---
> > >  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 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20140308/be3b8a4a/attachment.sig>