On Sat, Mar 08, 2014 at 08:58:24PM +0100, Daniel Vetter wrote:
> On Sat, Mar 8, 2014 at 7:50 PM, Ben Widawsky wrote:
> > I've seen this too. Though I think the WARN does coincide with what the
> > docs state - it doesn't seem to match reality. So I totally agree this
> > is the right course.
> >
>
On Sat, Mar 08, 2014 at 11:58:16AM -0800, Ben Widawsky wrote:
> I'm not clear if the hardware is still subject to the same prefetching
> issues that made us use a scratch page in the first place. In either
> case, we're using garbage with the current code (we will end up using
> offset 0).
>
> Thi
I'm not clear if the hardware is still subject to the same prefetching
issues that made us use a scratch page in the first place. In either
case, we're using garbage with the current code (we will end up using
offset 0).
This may be the cause of our current gem_cpu_reloc regression with
PPGTT. I c
Our code allows have a PPGTT that is smaller than the maximum size for
GEN6-GEN7. Though I don't think this actually ever occurs, the code may
as well work properly and more importantly look correct by using the
variable size instead of the HW max.
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm
On Sat, Mar 8, 2014 at 7:50 PM, Ben Widawsky wrote:
> I've seen this too. Though I think the WARN does coincide with what the
> docs state - it doesn't seem to match reality. So I totally agree this
> is the right course.
>
> However, for my curiosity, Chris, can you elaborate on why you think it
On Saturday 08 Mar 2014 at 11:07:50 (+0100), Daniel Vetter writes :
> On Sat, Mar 08, 2014 at 09:25:54AM +, 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
> > > wh
On Saturday 08 Mar 2014 at 09:25:54 (+), 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
>
On Sun, 2014-03-09 at 00:34 +0530, Sagar Arun Kamble wrote:
> On Sat, 2014-03-08 at 13:51 -0500, Alex Deucher wrote:
> > On Sat, Mar 8, 2014 at 1:49 PM, wrote:
> > > From: Sagar Kamble
> > >
> > > With this patch we allow larger cursor planes of sizes 128x128
> > > and 256x256.
> > >
> > > v2: A
On Sat, 2014-03-08 at 13:51 -0500, Alex Deucher wrote:
> On Sat, Mar 8, 2014 at 1:49 PM, wrote:
> > From: Sagar Kamble
> >
> > With this patch we allow larger cursor planes of sizes 128x128
> > and 256x256.
> >
> > v2: Added more precise check on size while setting cursor plane.
> >
> > v3: Chan
On Sat, Mar 8, 2014 at 1:49 PM, wrote:
> From: Sagar Kamble
>
> With this patch we allow larger cursor planes of sizes 128x128
> and 256x256.
>
> v2: Added more precise check on size while setting cursor plane.
>
> v3: Changes related to restructuring cursor size restrictions
> and DRM_DEBUG usa
On Fri, Mar 07, 2014 at 10:35:56PM +0100, Daniel Vetter wrote:
> On Fri, Mar 07, 2014 at 09:09:03PM +0100, Daniel Vetter wrote:
> > Since the gpu reset + full ppgtt merge we have a hard hang on snb when
> > running the gem_reset_stat tests. Recently Mika also some more strict
> > forcewake fifo war
From: Sagar Kamble
v1: Added 128x128 and 256x256 cursor size support.
v2: Refined the test to use igt_subtest_f and automate enumeration.
Signed-off-by: Sagar Kamble
---
lib/igt_kms.c | 13 ++-
tests/kms_cursor_crc.c | 219 +++--
2 files c
From: Sagar Kamble
With this patch we allow larger cursor planes of sizes 128x128
and 256x256.
v2: Added more precise check on size while setting cursor plane.
v3: Changes related to restructuring cursor size restrictions
and DRM_DEBUG usage.
Testcase: igt/kms_cursor_crc
Cc: Daniel Vetter
Cc:
Bjorn Helgaas schreef op za 08-03-2014 om 07:12 [-0700]:
> I assume you have CONFIG_PHYS_ADDR_T_64BIT=n (which is perfectly
> legal); let me know if otherwise.
$ grep CONFIG_PHYS_ADDR_T_64BIT /boot/config-3.14.0-0.rc5.1.local2.fc20.i686
# CONFIG_PHYS_ADDR_T_64BIT is not set
So, yes, CONFIG_PHYS_
On Fri, Mar 7, 2014 at 1:40 PM, Bjorn Helgaas wrote:
> It seems quite possible that I broke pci_bus_alloc_resource(), which could
> cause an allocation failure like this.
>
> If you have a chance to try it, here's a debug patch against v3.14-rc5. It
> should apply cleanly to 96702be56037. If you
On Fri, Mar 07, 2014 at 08:57:53AM -0800, Jesse Barnes wrote:
> As of IVB, the memory controller does internal swizzling already, so we
> shouldn't need to enable these. Based on an earlier fix from Kristian.
>
> Reported-by: Kristian Høgsberg
> Signed-off-by: Jesse Barnes
Imo the right approa
On Fri, Mar 07, 2014 at 08:57:52AM -0800, Jesse Barnes wrote:
> Some machines may have a broken VBT or no VBT at all, but we still want
> to use SSC there. So check for it and keep it enabled if we see it
> already on. Based on an earlier fix from Kristian.
>
> Reported-by: Kristian Høgsberg
>
On Fri, Mar 07, 2014 at 08:57:55AM -0800, Jesse Barnes wrote:
> By stuffing the fb allocation into the crtc, we get mode set lifetime
> refcounting for free, but have to handle the initial pin & fence
> slightly differently. It also means we can move the shared fb handling
> into the core rather t
On Sat, Mar 08, 2014 at 09:36:01AM +, Chris Wilson wrote:
> On Fri, Mar 07, 2014 at 08:05:19PM -0300, Paulo Zanoni wrote:
> > From: Paulo Zanoni
> >
> > So far force_wake_timer was only used by gen6_gt_force_wake_put. Since
> > we always had balanced gen6_gt_force_wake_get/put calls, we could
On Sat, Mar 08, 2014 at 09:25:54AM +, 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
> > usi
On Fri, Mar 07, 2014 at 08:05:24PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Otherwise, when we run intel_modeset_check_state we may already be
> runtime suspended, and our state checking code will read registers
> while the device is suspended. This can only happen if your
> autosuspen
On Fri, Mar 07, 2014 at 08:05:19PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> So far force_wake_timer was only used by gen6_gt_force_wake_put. Since
> we always had balanced gen6_gt_force_wake_get/put calls, we could
> guarantee balanced calls to intel_runtime_pm_get/put.
I'm sure you c
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 o
From: Sagar Kamble
This patch enables property for changin the pixel format
of plane to enable/disable pre-multiplied alpha format.
Client has to set BIT(DRM_BLEND_PREMULTIPLIED_ALPHA) | 0x0/0x1
to disable/enable pre-multiplied alpha format.
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: David Airlie
From: Sagar Kamble
Cc: Rob Landley
Cc: Dave Airlie
Cc: Daniel Vetter
Cc: Laurent Pinchart
Cc: David Herrmann
Cc: Alex Deucher
Cc: "Ville Syrjälä"
Cc: Sagar Kamble
Cc: "Purushothaman, Vijay A"
Cc: linux-...@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Sagar Kamble
-
From: Sagar Kamble
This patch creates a generic blending enum property.
Drivers may support subset of these values.
Cc: airl...@linux.ie
Cc: dri-de...@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Sagar Kamble
---
drivers/gpu/drm/drm_crtc.c | 33
From: Sagar Kamble
This patch enables constant alpha property for Sprite planes.
Client has to set BIT(DRM_BLEND_CONSTANT_ALPHA) | (8 bit alpha value)
for applying constant alpha on a plane. To disable constant alpha,
client has to set BIT(DRM_BLEND_NONE)
Cc: Daniel Vetter
Cc: Jani Nikula
Cc:
From: Sagar Kamble
This patch series introduces drm property modelled after glBlendFuc function.
For i915
constant alpha is exposed through this property to start with. Additional new
property
value for controlling pre-multiplied alpha is added.
i-g-t test case is to be added.
These patches ar
28 matches
Mail list logo
