On Sat, 2014-03-08 at 11:25 -0800, Sean V Kelley wrote: > On Saturday 08 Mar 2014 at 09:25:54 (+0000), Chris Wilson writes : > > 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? > > It should affect all baytrail systems. To my knowledge there are no subsets that have it fused off. This is in the gross hacks department but what happens if you set the VXD to DMA to GTT translated addresses, does it see the memory directly or via the GTT translations ? Alan _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
