On Mon, Jul 07, 2014 at 06:21:48PM -0700, Matt Roper wrote:
> This should hopefully simplify the display code slightly and also
> solves at least one mistake in intel_pipe_set_base() where
> to_intel_framebuffer(fb)->obj is referenced during local variable
> initialization, before 'if (!fb)' gets c
On Wed, Jul 09, 2014 at 10:09:00AM +0530, Deepak S wrote:
>
> On Monday 07 July 2014 02:35 PM, Daniel Vetter wrote:
> >On Tue, Jun 24, 2014 at 05:22:17PM +0530, Deepak S wrote:
> >>Hi Chris/Daniel,
> >>
> >>The patch is helping in some of the side-effects due to gpu boost. I
> >>still need to get
From: Ville Syrjälä
drm_rotation_simplify() can be used to eliminate unsupported rotation
flags. It will check if any unsupported flags are present, and if so
it will modify the rotation to an alternate form by adding 180 degrees
to rotation angle, and flipping the reflect x and y bits. The hope
From: Sagar Kamble
These property descriptions were kept as placeholder. Removing them for
simplicity.
Cc: damien.lesp...@intel.com
Cc: daniel.vet...@ffwll.ch
Cc: ville.syrj...@linux.intel.com
Signed-off-by: Sagar Kamble
Reviewed-by: Damien Lespiau
---
Documentation/DocBook/drm.tmpl | 64 +
From: Sagar Kamble
Cc: damien.lesp...@intel.com
Cc: daniel.vet...@ffwll.ch
Cc: ville.syrj...@linux.intel.com
Signed-off-by: Sagar Kamble
Reviewed-by: Damien Lespiau
---
Documentation/DocBook/drm.tmpl | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/Documentation/
From: Ville Syrjälä
The sprite planes (in fact all display planes starting from gen4)
support 180 degree rotation. Add the relevant low level bits to the
sprite code to make use of that feature.
The upper layers are not yet plugged in.
v2: HSW handles the rotated buffer offset automagically
v3
From: Ville Syrjälä
Sprite planes support 180 degree rotation. The lower layers are now in
place, so hook in the standard rotation property to expose the feature
to the users.
v2: Moving rotation_property to drm_plane
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Ville Syrjälä
Signed-off-
From: Sonika Jindal
Reset rotation property to 0 wherever applicable
v2: Also calling set_property of the plane to set the rotation in the plane
structure.
Cc: damien.lesp...@intel.com
Signed-off-by: Sonika Jindal
Reviewed-by: Damien Lespiau
---
drivers/gpu/drm/drm_fb_helper.c | 16 +++
From: Sonika Jindal
Primary planes support 180 degree rotation. Expose the feature
through rotation drm property.
v2: Calculating linear/tiled offsets based on pipe source width and
height. Added 180 degree rotation support in ironlake_update_plane.
v3: Checking if CRTC is active before issuein
From: Ville Syrjälä
Propagate the error from intel_update_plane() up through
intel_plane_restore() to the caller. This will be used for
rollback purposes when setting properties fails.
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Ville Syrjälä
Reviewed-by: Imre Deak
---
drivers/gpu/drm/
From: Ville Syrjälä
Add some helper functions to move drm_rects between different rotated
coordinate spaces. One function does the forward transform and
another does the inverse.
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Ville Syrjälä
Reviewed-by: Imre Deak
---
drivers/gpu/drm/drm_re
From: Ville Syrjälä
Use the new drm_mode_create_rotation_property() in omapdrm.
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Ville Syrjälä
Reviewed-by: Rob Clark
Reviewed-by: Imre Deak
Reviewed-by: Sagar Kamble
---
drivers/gpu/drm/omapdrm/omap_plane.c | 20 +++-
1 fi
From: Ville Syrjälä
Make drm_property_create_bitmask() a bit more generic by allowing the
caller to specify which bits are in fact supported. This allows multiple
callers to use the same enum list, but still create different versions
of the same property with different list of supported bits.
v2
From: Sonika Jindal
Enables 180 degree rotation for sprite and primary planes.
Updated the primary plane rotation support as per the new universal plane
design.
Most of these patches were already reviewed in intel-gfx in February 2014 thats
why there is version history in few of them.
v2: Moved
From: Ville Syrjälä
The rotation property stuff should be standardized among all drivers.
Move the bits to drm_crtc.h from omap_drv.h.
Signed-off-by: Ville Syrjälä
Reviewed-by: Imre Deak
---
drivers/gpu/drm/omapdrm/omap_drv.h |7 ---
include/drm/drm_crtc.h |8
From: Ville Syrjälä
Add a function to create a standards compliant rotation property.
Signed-off-by: Ville Syrjälä
Reviewed-by: Imre Deak
---
drivers/gpu/drm/drm_crtc.c | 18 ++
include/drm/drm_crtc.h |2 ++
2 files changed, 20 insertions(+)
diff --git a/drivers/gpu
On Monday 07 July 2014 02:35 PM, Daniel Vetter wrote:
On Tue, Jun 24, 2014 at 05:22:17PM +0530, Deepak S wrote:
Hi Chris/Daniel,
The patch is helping in some of the side-effects due to gpu boost. I
still need to get more data. I will keep the thread updated.
Ping. Might as well review it, to
Hi Daniel,
The patch below also works. You can use my Tested By for it.
Thanks
Ed Tomlinson
PS. I _really_ need to get a serial console working on my i7 box.
On Monday 07 July 2014 14:26:54 Daniel Vetter wrote:
> On Mon, Jul 07, 2014 at 06:45:49AM -0400, Ed Tomlinson wrote:
> > Daniel,
> >
>
With this bit enabled, HW changes the color when compressing frames for
debug purposes.
ALthough the simple way to enable a single bit is over intel_reg_write,
this value is overwriten on next update_fbc so depending on the workload
it is not possible to set this bit with intel-gpu-tools. So this
On 07/07/2014 08:51 PM, Rafael J. Wysocki wrote:
> On Monday, July 07, 2014 03:43:51 PM Aaron Lu wrote:
>> Some Thinkpad laptops' firmware will initiate a backlight level change
>> request through operation region on the events of AC plug/unplug, but
>> since we are not using firmware's interface t
On 07/07/2014 09:01 PM, Rafael J. Wysocki wrote:
> On Monday, July 07, 2014 03:43:51 PM Aaron Lu wrote:
>> Some Thinkpad laptops' firmware will initiate a backlight level change
>> request through operation region on the events of AC plug/unplug, but
>> since we are not using firmware's interface t
This should hopefully simplify the display code slightly and also
solves at least one mistake in intel_pipe_set_base() where
to_intel_framebuffer(fb)->obj is referenced during local variable
initialization, before 'if (!fb)' gets checked.
Potential uses of this macro were identified via the follow
Add an intel_fb_obj() macro that returns the GEM object associated with
a DRM framebuffer. This macro is safe to call on NULL framebuffers (a
NULL object pointer will be returned in this case).
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/intel_drv.h | 1 +
1 file changed, 1 insertion(+)
On Mon, Jul 7, 2014 at 9:43 PM, Daniel Vetter wrote:
> On Tue, Jul 01, 2014 at 08:54:27PM +0100, Chris Wilson wrote:
> > On Tue, Jul 01, 2014 at 05:16:30PM +, Mateo Lozano, Oscar wrote:
> > > > The issue is they need:
> > > >
> > > > A) A buffer object.
> > > > B) Bound to GGTT.
> > > > C) Th
On Monday, July 07, 2014 11:49:22 PM Rafael J. Wysocki wrote:
> On Monday, July 07, 2014 10:06:59 PM Daniel Vetter wrote:
> > On Mon, Jul 07, 2014 at 10:01:27PM +0200, Rafael J. Wysocki wrote:
> > > On Monday, July 07, 2014 04:54:23 PM Daniel Vetter wrote:
> > > > On Wed, Jun 25, 2014 at 01:01:36AM
On 7/8/2014 1:13 AM, Rafael J. Wysocki wrote:
On 6/24/2014 5:12 PM, Imre Deak wrote:
On Tue, 2014-06-24 at 17:53 +0300, Jani Nikula wrote:
On Tue, 24 Jun 2014, Imre Deak wrote:
On Tue, 2014-06-24 at 16:54 +0300, Jani Nikula wrote:
On Mon, 23 Jun 2014, Imre Deak wrote:
To achieve further po
On 6/24/2014 5:12 PM, Imre Deak wrote:
On Tue, 2014-06-24 at 17:53 +0300, Jani Nikula wrote:
On Tue, 24 Jun 2014, Imre Deak wrote:
On Tue, 2014-06-24 at 16:54 +0300, Jani Nikula wrote:
On Mon, 23 Jun 2014, Imre Deak wrote:
To achieve further power savings during system freeze (aka connected
On Mon, Jul 07, 2014 at 11:18:49PM +0200, Daniel Vetter wrote:
> On Fri, Jul 04, 2014 at 12:01:24PM +0100, Damien Lespiau wrote:
> > Doing otherwise breaks listing the subtests. The test was throwing an
> > error out when universal planes were disabled as well because of that.
> >
> > Cc: Matt Rop
On Mon, 7 Jul 2014, Chris Wilson wrote:
> > > this patch on top of v3.16-rc3-62-gd92a333 makes the resume from ram
> > > regression go away on my machine:
> >
> > Hm, we could conditionalize this hack on IS_G4X ... Chris, thoughts?
>
> As different machines favour different w/a, I think the issu
On Mon, 7 Jul 2014 18:48:47 -0300
Paulo Zanoni wrote:
> (documenting what we discussed on IRC)
>
> 2014-06-20 13:29 GMT-03:00 Jesse Barnes :
> > This was always the case on our suspend path, but it was recently
> > exposed by the change to use our runtime IRQ disable routine rather than
> > the
(documenting what we discussed on IRC)
2014-06-20 13:29 GMT-03:00 Jesse Barnes :
> This was always the case on our suspend path, but it was recently
> exposed by the change to use our runtime IRQ disable routine rather than
> the full DRM IRQ disable. Keep the warning on the enable side, as that
On Thu, Jun 19, 2014 at 11:00:20AM -0700, Jesse Barnes wrote:
> Jani, can you review this one? It's still needed for us to conform to
> the eDP timing spec.
Jani's already goofing off on vacation and I couldn't spot his r-b. Merged
anyway, I guess people will scream fast enough if this breaks stu
On Fri, Jul 04, 2014 at 11:50:32AM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> The current code only runs when we do an I915_WRITE operation. It
> checks if the unclaimed register flag is set before we do the
> operation, and then it checks it again after we do the operation. This
> doubl
On Monday, July 07, 2014 10:06:59 PM Daniel Vetter wrote:
> On Mon, Jul 07, 2014 at 10:01:27PM +0200, Rafael J. Wysocki wrote:
> > On Monday, July 07, 2014 04:54:23 PM Daniel Vetter wrote:
> > > On Wed, Jun 25, 2014 at 01:01:36AM +0200, Rafael J. Wysocki wrote:
> > > > On Tuesday, June 24, 2014 02:
Ipehr just carries Dword 0 and on Gen 8, offsets are located
on Dword 2 and 3 of MI_SEMAPHORE_WAIT.
This implementation was based on Ben's work and on Ville's suggestion for Ben
v2: fix typo. Removing spurious 0% from debug msg "0x%0%0". (Daniel)
Cc: Daniel Vetter
Cc: Ville Syrjälä
Cc: Ben Wid
On Mon, Jul 7, 2014 at 11:16 PM, Jesse Barnes wrote:
> I don't think it's unreasonable to use a macro that checks a global
> list for whether to apply a given WA. They'll be scattered all over,
> but at least it'll be easy to see:
> 1) whether we implement a given workaround
> and
> 2) which
I will try to disable the cairo tests on esx.
Thanks
Ying
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
Sent: Monday, July 07, 2014 1:53 PM
To: Liu, Ying2
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] how to build intel-
On Fri, Jul 04, 2014 at 11:50:29AM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> If we enable unclaimed register reporting on Gen 8, we will discover
> that the IRQ registers for pipes B and C are also on the power well,
> so writes to them when the power well is disabled result in unclaime
On Fri, Jul 04, 2014 at 12:01:24PM +0100, Damien Lespiau wrote:
> Doing otherwise breaks listing the subtests. The test was throwing an
> error out when universal planes were disabled as well because of that.
>
> Cc: Matt Roper
> Signed-off-by: Damien Lespiau
> ---
> tests/kms_universal_plane.c
On Mon, Jun 30, 2014 at 09:53:39AM -0700, Rodrigo Vivi wrote:
> Ipehr just carries Dword 0 and on Gen 8, offsets are located
> on Dword 2 and 3 of MI_SEMAPHORE_WAIT.
>
> This implementation was based on Ben's work and on Ville's suggestion for Ben
>
> Cc: Ville Syrjälä
> Cc: Ben Widawsky
> Sign
On Mon, 7 Jul 2014 23:04:55 +0200
Daniel Vetter wrote:
> On Thu, Jul 03, 2014 at 08:12:35AM +0100, Damien Lespiau wrote:
> > This reverts commit 02f6bcccf7c324115747aae2f0addd6af5d321cd.
> >
> > The OA buffer can contain global data (in particular, not linked to a
> > context or a single batch e
On Mon, 7 Jul 2014 22:50:08 +0200
Daniel Vetter wrote:
> On Tue, Jul 01, 2014 at 04:51:07PM +, Mateo Lozano, Oscar wrote:
> > Is there any reason why the WAs are applied in *_init_clock_gating? We
> > are finding that some of them are lost during reset, and also the
> > default context ends u
On Mon, Jul 07, 2014 at 06:04:45PM +0100, Damien Lespiau wrote:
> From: Yi Sun
>
> Get CRCs of a full red and a full blue surface as reference.
>
> Create a big framebuffer that is twice width and twice height as the
> current display mode.
The interesting stuff happens for framebuffers with of
On Mon, Jul 07, 2014 at 06:03:29PM +0100, Damien Lespiau wrote:
> This is what we read when the CRC logic in in a powered down well. We
> really don't want that to happen.
>
> In theory, it's possible 0x to be a valid CRC value, so I don't
> assert here.
I think we also should go through
On Thu, Jul 03, 2014 at 08:12:35AM +0100, Damien Lespiau wrote:
> This reverts commit 02f6bcccf7c324115747aae2f0addd6af5d321cd.
>
> The OA buffer can contain global data (in particular, not linked to a
> context or a single batch execution) about GPU events (eg. hw context
> switches, rc6 transiti
On Thu, Jul 03, 2014 at 09:47:13PM +, Liu, Ying2 wrote:
> Damien,
>
> We run intel-gpu-tool in VMware esx console. We didn't port display part of
> intel gpu driver to esx, so we don't need any display tests at all.
> If you could provide us a solution to run intel gpu tools without cairo, th
On Tue, Jul 01, 2014 at 04:51:07PM +, Mateo Lozano, Oscar wrote:
> Is there any reason why the WAs are applied in *_init_clock_gating? We
> are finding that some of them are lost during reset, and also the
> default context ends up with wrong values because the render context is
> restored & sa
On Tue, Jul 01, 2014 at 08:54:27PM +0100, Chris Wilson wrote:
> On Tue, Jul 01, 2014 at 05:16:30PM +, Mateo Lozano, Oscar wrote:
> > > The issue is they need:
> > >
> > > A) A buffer object.
> > > B) Bound to GGTT.
> > > C) That userspace knows the GGTT offset of, so that they can program
> >
On Tue, Jul 01, 2014 at 05:24:23PM +0100, daniele.ceraolospu...@intel.com wrote:
> From: Daniele Ceraolo Spurio
>
> These callbacks can be assigned to specific functions inside an external
> validation kernel module. This module can then extract run-time
> information to make sure everything is w
On Mon, Jun 30, 2014 at 05:14:50PM -0700, Ben Widawsky wrote:
> On Mon, Jun 30, 2014 at 09:53:44AM -0700, Rodrigo Vivi wrote:
> > Signed-off-by: Rodrigo Vivi
>
> Reviewed-by: Ben Widawsky
Pulled in entire series. Yay!
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365
On Mon, Jul 07, 2014 at 10:01:27PM +0200, Rafael J. Wysocki wrote:
> On Monday, July 07, 2014 04:54:23 PM Daniel Vetter wrote:
> > On Wed, Jun 25, 2014 at 01:01:36AM +0200, Rafael J. Wysocki wrote:
> > > On Tuesday, June 24, 2014 02:43:02 PM Jani Nikula wrote:
> > > > On Thu, 19 Jun 2014, Randy Dun
On Mon, Jun 30, 2014 at 06:16:50PM -0700, Ben Widawsky wrote:
> On Mon, Jun 30, 2014 at 09:51:11AM -0700, Rodrigo Vivi wrote:
> > ring index calculation table was out of date after other rings were added,
> > although the formula is flexible and scale when adding new rings.
> >
> > So this patch j
From: Clint Taylor
The panel power sequencer on vlv doesn't appear to accept changes to its
T12 power down duration during warm reboots. This change forces a delay
for warm reboots to the T12 panel timing as defined in the VBT table for
the connected panel.
Ver2: removed redundant pr_crit(), com
On Tue, Jul 01, 2014 at 02:41:36AM -0700, Rodrigo Vivi wrote:
> It just fix a typo.
>
> v2: removing underscore to let this like all other ring names (Oscar)
>
> Cc: Oscar Mateo
> Reviewed-by (v1): Ben Widawsky
> Signed-off-by: Rodrigo Vivi
Queued for -next, thanks for the patch.
-Daniel
> -
On Sun, Jun 29, 2014 at 06:27:03AM +0200, Andi Kleen wrote:
>
> Hi,
>
> The current version of chrome reproducibly hangs the GPU on my
> sandy bridge system when using google maps. The GUI freezes
> and I have to kill chrome from a console to recover.
>
> Known problem? Crash dump is attached.
Hi,
Since the 3.16.0-rc my laptop displays a lower color depth. Gradient
surfaces show a staircase effect where before the gradient was smooth.
--
Hans
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/li
On Monday, July 07, 2014 04:54:23 PM Daniel Vetter wrote:
> On Wed, Jun 25, 2014 at 01:01:36AM +0200, Rafael J. Wysocki wrote:
> > On Tuesday, June 24, 2014 02:43:02 PM Jani Nikula wrote:
> > > On Thu, 19 Jun 2014, Randy Dunlap wrote:
> > > > On 06/18/14 23:16, Stephen Rothwell wrote:
> > > >> Hi
On Mon, Jun 30, 2014 at 11:27:25AM +, Mateo Lozano, Oscar wrote:
>
>
> -
> Intel Corporation (UK) Limited
> Registered No. 1134945 (England)
> Registered Office: Pipers Way, Swindon SN3 1RJ
> VAT No: 860 2173 47
>
> > -O
On Thu, Jun 26, 2014 at 06:24:35PM +0100, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> Any commands written to the ring without the scheduler's knowledge can get
> lost
> during a pre-emption event. This checkin updates the page flip code to send
> the
> ring commands via the sche
On Wed, Jul 02, 2014 at 11:37:29AM -0700, Jesse Barnes wrote:
> On Thu, 26 Jun 2014 18:24:09 +0100
> john.c.harri...@intel.com wrote:
>
> > From: John Harrison
> >
> > Added a DRM debug facility for use by the scheduler.
> > ---
> > include/drm/drmP.h |7 +++
> > 1 file changed, 7 inser
On Wed, Jul 02, 2014 at 11:34:23AM -0700, Jesse Barnes wrote:
> On Thu, 26 Jun 2014 18:24:08 +0100
> john.c.harri...@intel.com wrote:
>
> > From: John Harrison
> >
> > The scheduler decouples the submission of batch buffers to the driver with
> > their
> > submission to the hardware. This basic
On Thu, Jun 26, 2014 at 06:24:06PM +0100, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> The scheduler needs to do interrupt triggered work that is too complex to do
> in
> the interrupt handler. Thus it requires a deferred work handler to process
> this
> work asynchronously.
> ---
On Wed, Jul 02, 2014 at 11:21:42AM -0700, Jesse Barnes wrote:
> On Thu, 26 Jun 2014 18:24:05 +0100
> john.c.harri...@intel.com wrote:
>
> > From: John Harrison
> >
> > This is required by user land validation programs that need to know whether
> > the
> > scheduler is available for testing or n
On Thu, Jun 26, 2014 at 06:24:01PM +0100, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> A major point of the GPU scheduler is that it re-orders batch buffers after
> they
> have been submitted to the driver. Rather than attempting to re-assign seqno
> values, it is much simpler to h
On Thu, Jun 26, 2014 at 06:24:00PM +0100, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> Created GPU scheduler source files with only a basic init function.
Same critique as for Oscar's execlist: Please don't order patches by
adding unused leave code and structures first, but start b
On Thu, Jun 26, 2014 at 06:23:59PM +0100, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> Added a Kconfig option for enabling/disabling the GPU scheduler.
> ---
> drivers/gpu/drm/i915/Kconfig |8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/Kco
On Wed, Jul 02, 2014 at 10:51:23AM -0700, Jesse Barnes wrote:
> On Thu, 26 Jun 2014 18:23:58 +0100
> john.c.harri...@intel.com wrote:
>
> > From: John Harrison
> >
> > There is a workaround for a hardware bug when reading the seqno from the
> > status
> > page. The bug does not exist on VLV how
On Thu, Jun 26, 2014 at 06:23:53PM +0100, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> Validation tests need a run time mechanism for querying whether or not the
> driver supports the Android native sync facility.
> ---
> drivers/gpu/drm/i915/i915_dma.c |7 +++
> include/ua
On Tue, Jul 01, 2014 at 08:12:11AM +0100, Chris Wilson wrote:
> On Mon, Jun 30, 2014 at 02:40:05PM -0700, Jesse Barnes wrote:
> > On Thu, 26 Jun 2014 18:23:55 +0100
> > john.c.harri...@intel.com wrote:
> >
> > > From: John Harrison
> > >
> > > The i915_gem_record_rings() code was unconditionally
On Mon, Jun 30, 2014 at 02:10:16PM -0700, Jesse Barnes wrote:
> On Thu, 26 Jun 2014 18:23:54 +0100
> john.c.harri...@intel.com wrote:
> I think "no_flush" would be more in line with some of the other
> functions in the kernel. "wo" makes me think of "write only". But
> it's not a big deal.
>
> I
On Mon, Jul 07, 2014 at 07:58:30PM +0200, Paolo Bonzini wrote:
> Il 07/07/2014 19:54, Daniel Vetter ha scritto:
> >On Mon, Jul 07, 2014 at 04:57:45PM +0200, Paolo Bonzini wrote:
> >>Il 07/07/2014 16:49, Daniel Vetter ha scritto:
> >>>So the correct fix to forward intel gpus to guests is indeed to s
Il 07/07/2014 19:54, Daniel Vetter ha scritto:
On Mon, Jul 07, 2014 at 04:57:45PM +0200, Paolo Bonzini wrote:
Il 07/07/2014 16:49, Daniel Vetter ha scritto:
So the correct fix to forward intel gpus to guests is indeed to somehow
fake the pch pci ids since the driver really needs them. Gross des
On Mon, Jun 30, 2014 at 02:03:18PM -0700, Jesse Barnes wrote:
> On Thu, 26 Jun 2014 18:23:52 +0100
> john.c.harri...@intel.com wrote:
>
> > From: John Harrison
> >
> > The 'i915_driver_preclose()' function has a parameter called 'file_priv'.
> > However, this is misleading as the structure it po
On Mon, Jul 07, 2014 at 04:57:45PM +0200, Paolo Bonzini wrote:
> Il 07/07/2014 16:49, Daniel Vetter ha scritto:
> >So the correct fix to forward intel gpus to guests is indeed to somehow
> >fake the pch pci ids since the driver really needs them. Gross design, but
> >that's how the hardware works.
On Mon, Jul 07, 2014 at 06:40:20PM +0200, Thomas Richter wrote:
> On 07.07.2014 17:04, Daniel Vetter wrote:
> >On Sat, Jun 21, 2014 at 01:57:32PM +0200, Thomas Richter wrote:
> >>Hi Daniel, dear intel experts,
> >>
> >>this a bug report for the intel i945GM integrated graphics chipset (*NOT*
> >>th
On Mon, Jul 07, 2014 at 05:22:44PM +0100, Damien Lespiau wrote:
> On Thu, May 29, 2014 at 02:10:22PM +0200, Daniel Vetter wrote:
> > The always-on power well pixel path on haswell is routed such that it
> > bypasses the panel fitter when we use is. Which means the pfit CRC
> > source won't work in
On 07/04/2014 05:26 AM, Paulo Zanoni wrote:
2014-07-03 19:07 GMT-03:00 Clint Taylor :
On 07/02/2014 07:40 AM, Paulo Zanoni wrote:
2014-07-02 5:35 GMT-03:00 Jani Nikula :
From: Clint Taylor
The panel power sequencer on vlv doesn't appear to accept changes to its
T12 power down duration duri
Signed-off-by: Damien Lespiau
---
tests/kms_plane.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/tests/kms_plane.c b/tests/kms_plane.c
index 7437641..5f7bfc0 100644
--- a/tests/kms_plane.c
+++ b/tests/kms_plane.c
@@ -69,6 +69,7 @@ test_grab_crc(data_t *data, igt_output_t *output, col
From: Yi Sun
Get CRCs of a full red and a full blue surface as reference.
Create a big framebuffer that is twice width and twice height as the
current display mode.
Fill the top left quarter with red, bottom right quarter with blue
Check the scanned out image with the CRTC at position (0, 0) of
On Fri, May 23, 2014 at 08:28:47AM +0800, Yi Sun wrote:
> Get CRCs of a full red and a full blue surface as reference.
>
> Create a big framebuffer that is twice width and twice height as the
> current display mode.
>
> Fill the top left quarter with red, bottom right quarter with blue
> Check th
This is what we read when the CRC logic in in a powered down well. We
really don't want that to happen.
In theory, it's possible 0x to be a valid CRC value, so I don't
assert here.
Signed-off-by: Damien Lespiau
---
lib/igt_debugfs.c | 7 ++-
1 file changed, 6 insertions(+), 1 deleti
Signed-off-by: Damien Lespiau
---
lib/igt_debugfs.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/lib/igt_debugfs.c b/lib/igt_debugfs.c
index 5c4bbc5..d4a6cf6 100644
--- a/lib/igt_debugfs.c
+++ b/lib/igt_debugfs.c
@@ -527,6 +527,8 @@ void igt_pipe_crc_collect_crc(igt_pipe_crc_t *pipe_crc,
So the next commit won't trigger a drmModeSetCrtc() if the primary plane
doesn't have any update needing it.
This shouldn't be a problem at the moment as we don't allow the primary
plane to be of a different size than the CRTC viewport, but it will most
likely change in the future and we don't wan
On Wed, May 28, 2014 at 07:23:58PM +0100, Damien Lespiau wrote:
> We currenly have a bug on HSW where asking for the panel fitter CRC when the
> power well is down returns 0x, but kms_pipe_crc_basic passes as it
> only
> tests that the CRCs obtained for a FB are consistent over time. We
>
On 07.07.2014 17:04, Daniel Vetter wrote:
On Sat, Jun 21, 2014 at 01:57:32PM +0200, Thomas Richter wrote:
Hi Daniel, dear intel experts,
this a bug report for the intel i945GM integrated graphics chipset (*NOT*
the 830GM this time). Since at least 3.12.0, but also with the latest
intel-drm-nigh
I recently built a new desktop machine using a Shuttle SZ87R6, an I7-4770S and
a Dell U2713HM monitor. Did my initial HW burn-in and testing using a Fedora
20 KDE Spin Live CD (Kernel 3.11.10-301.fc20.x86_64 & KDE Systems settings
v4.11.3) using the DVI port on the computer and display and a du
On Mon, Jul 07, 2014 at 04:06:02PM +0300, Mika Kuoppala wrote:
> michel.thie...@intel.com writes:
>
> > From: Michel Thierry
> >
> > The workaround to limit SDE poly depth FIFO to 2 is not applied because
> > 3D Chicken-3 mask bit is not set.
> >
> > WaLimitSizeOfSDEPolyFifo is only for BDW-A and
On Mon, Jul 07, 2014 at 06:20:34PM +0200, Egbert Eich wrote:
> Since the root cause is understood now and with the fix
>
>commit 564ed191f5d816d24501664296991ec70327e2bc
>Author: Imre Deak
>Date: Fri Jun 13 14:54:21 2014 +0300
>
>drm/i915: gmch: fix stuck primary plane due
On Thu, May 29, 2014 at 02:10:22PM +0200, Daniel Vetter wrote:
> The always-on power well pixel path on haswell is routed such that it
> bypasses the panel fitter when we use is. Which means the pfit CRC
> source won't work in that configuration.
>
> Add a new disallow-bypass flags to the pfit pip
Hi,
We're working on Video Wall project on Linux, I need to know if it's
possible to grab Intel gpu output frames or not ? I also need to know if
It's possible to create virtual outputs for an Intel gpu to use gpu
acceleration and then grab the output frames ?
Regards
___
Since the root cause is understood now and with the fix
commit 564ed191f5d816d24501664296991ec70327e2bc
Author: Imre Deak
Date: Fri Jun 13 14:54:21 2014 +0300
drm/i915: gmch: fix stuck primary plane due to memory self-refresh mode
in place the magic for G4x chipsets introduced
On Mon, Jun 30, 2014 at 04:17:00PM -0300, Paulo Zanoni wrote:
> 2014-06-30 8:45 GMT-03:00 Rodrigo Vivi :
> > As pointed out before we don't have a reliable way to read back ips
> > status on BDW without the risk to disable it when reading.
> > However now we are pretending that IPS on BDW is always
On Fri, Jun 27, 2014 at 03:15:36PM +0100, tim.g...@intel.com wrote:
> From: Tim Gore
>
> Quite a few single tests do not use the igt_simple_main
> macro because they want access to argc/argv. So change the
> igt_simple_main macro to pass these arguments through to the
> "__real_mainxxx" function,
On Fri, Jun 27, 2014 at 03:15:37PM +0100, tim.g...@intel.com wrote:
> From: Tim Gore
>
> igt_subtest_init mainly does stuff that we also want for
> simple/single tests, such as looking for --list-subtests
> and --help options and calling common_init. So just call
> this from igt_simple_init and t
There hasn't been a libdrm release containing the universal plane
definitions yet, so add them to igt_kms to allow compilation to succeed
in the meantime.
Signed-off-by: Matt Roper
---
lib/igt_kms.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/lib/igt_kms.c b/lib/igt_kms.c
On Mon, Jul 07, 2014 at 05:16:13PM +0200, Daniel Vetter wrote:
> On Wed, Jul 02, 2014 at 06:18:41PM +0200, Thomas Meyer wrote:
> > Hi,
> >
> > this patch on top of v3.16-rc3-62-gd92a333 makes the resume from ram
> > regression go away on my machine:
>
> Hm, we could conditionalize this hack on IS
On Fri, Jun 27, 2014 at 06:44:04AM +1000, Dave Airlie wrote:
> >
> > Implemented a batch buffer submission scheduler for the i915 DRM driver.
> >
>
> While this seems very interesting, you might want to address in the commit msg
> or the cover email
>
> a) why this is needed,
> b) any improvement
Suggested by Brad Volking.
Signed-off-by: Daniel Vetter
---
tests/gem_exec_parse.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/tests/gem_exec_parse.c b/tests/gem_exec_parse.c
index f7376e391ee9..5bab4db777b3 100644
--- a/tests/gem_exec_parse.c
+++ b/tests/gem_exec_
On Thu, Jul 03, 2014 at 12:01:35PM +, Mateo Lozano, Oscar wrote:
> > -Original Message-
> > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> > Sent: Thursday, July 03, 2014 10:53 AM
> > To: Mateo Lozano, Oscar; intel-gfx@lists.freedesktop.org
> > Subject: Re: [Intel-gfx] [PATCH 4/
On Tue, Jun 24, 2014 at 03:12:51PM -0700, Todd Previte wrote:
> Implements some of the basic EDID tests for Displayport compliance. These
> tests
> include reading the EDID, verifying the checksum and writing the test
> responses
> back to the sink device.
>
> Signed-off-by: Todd Previte
> ---
1 - 100 of 150 matches
Mail list logo
