On 9 April 2014 15:08, Jani Nikula jani.nik...@linux.intel.com wrote:
On Wed, 09 Apr 2014, Dave Airlie airl...@gmail.com wrote:
On Wed, Apr 9, 2014 at 4:07 PM, Daniel J Blueman dan...@quora.org wrote:
On 9 April 2014 11:41, Dave Airlie airl...@gmail.com wrote:
On Tue, Apr 8, 2014 at 5:32 PM,
Add drm_intel_bufmgr_gem_set_aub_state_only to disable dumping of unannotated
or untyped data. The result should still be a valid AUB dump, in that it can
be fed to the simulator. But it will not trigger execution.
This can be used to dump states in binary form.
Signed-off-by: Chia-I Wu
On Mon, Apr 14, 2014 at 07:26:08PM +0200, Egbert Eich wrote:
Depending on the SDVO output_flags SDVO may have multiple connectors
linking to the same encoder (in intel_connector-encoder-base).
Only one of those connectors should be active (ie link to the encoder
thru drm_connector-encoder.
If
On Tue, Apr 15, 2014 at 3:37 PM, Chia-I Wu olva...@gmail.com wrote:
Add drm_intel_bufmgr_gem_set_aub_state_only to disable dumping of unannotated
or untyped data. The result should still be a valid AUB dump, in that it can
be fed to the simulator. But it will not trigger execution.
This can
After thinking about this topic a bit more I've reached the conclusion
that implementing this doesn't make sense:
- The locking is all wrong: set_config(NULL) will also unlink encoders
and connectors, but those links are protected with the mode_config
mutex. In the -disable_plane callback we
This cleans up the checkpatch errors for the merged commit -
commit d3b542fcfc72d7724585e3fd2c5e75351bc3df47
Author: Shobhit Kumar shobhit.ku...@intel.com
Date: Mon Apr 14 11:00:34 2014 +0530
drm/i915: Add parsing support for new MIPI blocks in VBT
Signed-off-by: Shobhit Kumar
Chris Wilson writes:
On Mon, Apr 14, 2014 at 07:26:08PM +0200, Egbert Eich wrote:
Depending on the SDVO output_flags SDVO may have multiple connectors
linking to the same encoder (in intel_connector-encoder-base).
Only one of those connectors should be active (ie link to the encoder
On Mon, Apr 14, 2014 at 07:26:09PM +0200, Egbert Eich wrote:
Depending on the SDVO output_flags SDVO may have multiple connectors.
These are all initialized in intel_sdvo_output_setup(). The connector
that is initialized later will override the encoder_type that has been
set up by an earlier
Hi Ville,
Somehow I did not receive your review comments
(http://lists.freedesktop.org/archives/intel-gfx/2014-April/042956.html
) in my mailbox.
Here is my input w.r.t patches I have sent for review:
Currently my patches are modeling constant alpha blend factor (assuming
pre-multiplied format)
On Tue, Apr 15, 2014 at 02:27:41PM +0800, Daniel J Blueman wrote:
On 9 April 2014 15:08, Jani Nikula jani.nik...@linux.intel.com wrote:
On Wed, 09 Apr 2014, Dave Airlie airl...@gmail.com wrote:
On Wed, Apr 9, 2014 at 4:07 PM, Daniel J Blueman dan...@quora.org wrote:
On 9 April 2014 11:41,
On Tue, Apr 15, 2014 at 10:02:43AM +0200, Daniel Vetter wrote:
After thinking about this topic a bit more I've reached the conclusion
that implementing this doesn't make sense:
- The locking is all wrong: set_config(NULL) will also unlink encoders
and connectors, but those links are
On Tue, Apr 15, 2014 at 03:14:04PM +0530, Sagar Arun Kamble wrote:
Hi Ville,
Somehow I did not receive your review comments
(http://lists.freedesktop.org/archives/intel-gfx/2014-April/042956.html
) in my mailbox.
Here is my input w.r.t patches I have sent for review:
Currently my
Hi Ville,
Thanks for the reply.
I have few more queries.
On Tue, 2014-04-15 at 13:35 +0300, Ville Syrjälä wrote:
On Tue, Apr 15, 2014 at 03:14:04PM +0530, Sagar Arun Kamble wrote:
Hi Ville,
Somehow I did not receive your review comments
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
Jesse Barnes
Sent: Friday, April 11, 2014 11:46 PM
To: Ville Syrjälä
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH] drm/i915/vlv: assert and de-assert sideband
On Tue, Apr 15, 2014 at 04:53:22PM +0530, Sagar Arun Kamble wrote:
Hi Ville,
Thanks for the reply.
I have few more queries.
On Tue, 2014-04-15 at 13:35 +0300, Ville Syrjälä wrote:
On Tue, Apr 15, 2014 at 03:14:04PM +0530, Sagar Arun Kamble wrote:
Hi Ville,
Somehow I did not
On Tue, Apr 15, 2014 at 12:22 PM, Ville Syrjälä
ville.syrj...@linux.intel.com wrote:
Although I'm not sure EINVAL is the best choice here. Maybe ENOSYS?
We return -EINVAL everywhere else where we don't support a giving
config, e.g. lack of dpll, unsupported plane scaling, pixel format
mismatch
On Tue, Apr 15, 2014 at 11:39:41AM +, Purushothaman, Vijay A wrote:
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
Of
Jesse Barnes
Sent: Friday, April 11, 2014 11:46 PM
To: Ville Syrjälä
Cc:
On Tue, 2014-04-15 at 11:39 +, Purushothaman, Vijay A wrote:
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
Of
Jesse Barnes
Sent: Friday, April 11, 2014 11:46 PM
To: Ville Syrjälä
Cc: intel-gfx@lists.freedesktop.org
Atm, none of the RPM callbacks can fail, but the next patch adding
RPM support for VLV changes this, so prepare for it.
In case one of these callbacks return error RPM will get permanently
disabled until the error is explicitly cleared. In the future we could
add support for re-enabling it, for
On Tue, Apr 15, 2014 at 10:02:43AM +0200, Daniel Vetter wrote:
After thinking about this topic a bit more I've reached the conclusion
that implementing this doesn't make sense:
- The locking is all wrong: set_config(NULL) will also unlink encoders
and connectors, but those links are
Hi,
oscar.ma...@intel.com writes:
From: Oscar Mateo oscar.ma...@intel.com
Guarantees that error capture works at a very basic level.
v2: Also check that the ring object contains a reloc with MI_BB_START
for the presumed batch object's address.
Signed-off-by: Oscar Mateo
Hi all,
I have discussed with Daniel about the running time for each cases before and
we set the standard as 10M, if one can’t finish after running 10M we will see
it as Timeout and report bug on FDO(such as : Bug
77474https://bugs.freedesktop.org/show_bug.cgi?id=77474 -
On Wed, 2014-04-09 at 13:28 +0300, ville.syrj...@linux.intel.com wrote:
From: Rafael Barbalho rafael.barba...@intel.com
Add support for the third pipe in cherrview
Signed-off-by: Rafael Barbalho rafael.barba...@intel.com
[vsyrjala: slightly massaged the patch]
Signed-off-by: Ville Syrjälä
On Thu, Mar 27, 2014 at 05:59:48PM +, oscar.ma...@intel.com wrote:
From: Ben Widawsky benjamin.widaw...@intel.com
For the most part, logical rinf context objects are similar to hardware
contexts in that the backing object is meant to be opaque. There are
some exceptions where we need to
On Tue, Apr 15, 2014 at 11:00:33AM -0500, Jeff McGee wrote:
On Thu, Mar 27, 2014 at 05:59:48PM +, oscar.ma...@intel.com wrote:
From: Ben Widawsky benjamin.widaw...@intel.com
For the most part, logical rinf context objects are similar to hardware
contexts in that the backing object is
On Tue, Apr 15, 2014 at 09:19:27PM +0530, S, Deepak wrote:
On 4/10/2014 7:34 PM, Ville Syrjälä wrote:
On Thu, Apr 10, 2014 at 04:41:10PM +0300, Jani Nikula wrote:
On Thu, 10 Apr 2014, Ville Syrjälä ville.syrj...@linux.intel.com wrote:
On Thu, Apr 10, 2014 at 09:31:39AM +0530, S, Deepak
Like on hsw/bdw the pipe isn't actually running yet at this point.
This holds for both pch ports and the cpu edp port according to my
testing on ilk, snb and ivb.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77297
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
Like on hsw/bdw the pipe only starts running once the port/pch
transcoder combo is all enabled. Before that the vblank wait in the
primary plane enable function simply times out.
This is also really nice prep work for atomic modesets since now all
the plane enabling is at the very end and all
Chated with Ben last week about this
It may be feasiable to have a fast.tests for intel-gpu-tools also
Thanks
--Shuang
From: Yang, Guang A
Sent: Tuesday, April 15, 2014 11:46 PM
To: Vetter, Daniel; Barnes, Jesse; Widawsky, Benjamin; Wood, Thomas; Jin,
Gordon; OTC GFX QA Extended;
On 4/15/2014 9:46 PM, Ville Syrjälä wrote:
On Tue, Apr 15, 2014 at 09:19:27PM +0530, S, Deepak wrote:
On 4/10/2014 7:34 PM, Ville Syrjälä wrote:
On Thu, Apr 10, 2014 at 04:41:10PM +0300, Jani Nikula wrote:
On Thu, 10 Apr 2014, Ville Syrjälä ville.syrj...@linux.intel.com wrote:
On Thu,
On 15/04/2014 17:46, Yang, Guang A wrote:
Hi all,
I have discussed with Daniel about the running time for each cases
before and we set the standard as 10M, if one can’t finish after
running 10M we will see it as Timeout and report bug on FDO(such as :
Bug 77474
From: Ville Syrjälä ville.syrj...@linux.intel.com
All of the .queue_flip() callbacks duplicate the same code to pin the
buffers and calculate the gtt_offset. Move that code to
intel_crtc_page_flip(). In order to do that we must also move the ring
selection logic there.
Signed-off-by: Ville
From: Ville Syrjälä ville.syrj...@linux.intel.com
Now that we've plugged the mmio vs. ring flip race, we shouldn't need
these vblank waits in the modeset codepaths anymore. So get rid of
them.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_display.c |
From: Ville Syrjälä ville.syrj...@linux.intel.com
kms_mmio_vs_cs_flip has two subtests:
- setplane_vs_cs_flip tests the interaction between
fullscreen sprites and CS flips
- setcrtc_vs_cs_flip tests the interaction between
primary plane panning and CS flips
Signed-off-by: Ville Syrjälä
From: Ville Syrjälä ville.syrj...@linux.intel.com
Starting from ILK, mmio flips also cause a flip done interrupt to be
signalled. This means if we first do a set_base and follow it
immediately with the CS flip, we might mistake the flip done interrupt
caused by the set_base as the flip done
From: Ville Syrjälä ville.syrj...@linux.intel.com
Now that the vblank wait is gone from intel_enable_primary_plane(),
hsw_enable_ips() needs to do the vblank wait itself.
Signed-off-by: Ville Syrjälä ville.syrj...@linux.intel.com
---
drivers/gpu/drm/i915/intel_display.c | 12 ++--
From: Ville Syrjälä ville.syrj...@linux.intel.com
This is the second version of the mmio vs. CS flip race fix.
Since v1 I fixed one if Chris's complaints. I still left the
flip_count_after_eq() untouched so that it's reasonably consistent
with the vbl_count_after_eq() I have in my watermark
From: Ville Syrjälä ville.syrj...@linux.intel.com
We have to write to the primary plane base address registrer when we
enable/disable the primary plane in response to sprite coverage. Those
writes will cause the flip counter to increment which could interfere
with the detection of CS flip
On Fri, Apr 11, 2014 at 08:26:25PM +0300, Imre Deak wrote:
On Fri, 2014-04-11 at 19:07 +0200, Egbert Eich wrote:
When linking the i2c sysfs file into the connector's directory
pass directory and link target in the right order.
This code was introduced with:
commit
On Mon, Apr 14, 2014 at 07:26:08PM +0200, Egbert Eich wrote:
Depending on the SDVO output_flags SDVO may have multiple connectors
linking to the same encoder (in intel_connector-encoder-base).
Only one of those connectors should be active (ie link to the encoder
thru drm_connector-encoder.
If
On Mon, Apr 14, 2014 at 07:26:09PM +0200, Egbert Eich wrote:
Depending on the SDVO output_flags SDVO may have multiple connectors.
These are all initialized in intel_sdvo_output_setup(). The connector
that is initialized later will override the encoder_type that has been
set up by an earlier
Depending on the SDVO output_flags SDVO may have multiple connectors.
These are all initialized in intel_sdvo_output_setup(). The connector
that is initialized later will override the encoder_type that has been
set up by an earlier connector type initialization. Eventually the
one that comes last
On Tue, Apr 15, 2014 at 09:14:13PM +0200, Egbert Eich wrote:
Depending on the SDVO output_flags SDVO may have multiple connectors.
These are all initialized in intel_sdvo_output_setup(). The connector
that is initialized later will override the encoder_type that has been
set up by an earlier
On Fri, Apr 11, 2014 at 10:21:59AM +0300, Jani Nikula wrote:
On Fri, 11 Apr 2014, Ben Widawsky b...@bwidawsk.net wrote:
On Wed, Apr 09, 2014 at 06:44:29PM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
Hi
We always talk about how intel_display.c is a giant
On Mon, Apr 14, 2014 at 11:17:53AM +0300, Imre Deak wrote:
On Mon, 2014-04-14 at 09:47 +0200, Daniel Vetter wrote:
On Mon, Apr 14, 2014 at 9:43 AM, Arun Chandran achand...@mvista.com wrote:
1) Revert the commit 77961eb984c7e5394bd29cc7be2ab0bf0cc7e7b1.
With this commit DP hotplug events
On Mon, Apr 14, 2014 at 01:03:58PM +, Mateo Lozano, Oscar wrote:
I would add a little more smarts to both the kernel and error-decode.
In the kernel, we can print the guilty request, which you can then use to
confirm that it is yours. That seems to me to be a stronger validation of
On Mon, Apr 14, 2014 at 11:56:03AM -0700, Steven Noonan wrote:
On Mon, Apr 14, 2014 at 11:35:05AM -0700, Keith Packard wrote:
Steven Noonan ste...@uplinklabs.net writes:
Was using my machine normally, then my mouse cursor vanished. After
switching
to a VT and back to X11, my cursor
On Tue, Apr 15, 2014 at 01:54:07PM +0530, Shobhit Kumar wrote:
This cleans up the checkpatch errors for the merged commit -
commit d3b542fcfc72d7724585e3fd2c5e75351bc3df47
Author: Shobhit Kumar shobhit.ku...@intel.com
Date: Mon Apr 14 11:00:34 2014 +0530
drm/i915: Add parsing
On Tue, Apr 15, 2014 at 11:10:34AM -0500, Jeff McGee wrote:
Oh, nevermind. I understand now.
Quickly explaining your understanding for everyone else's benefit would be
nice ... In general be explicit and verbose on mailing lists to make sure
you don't miss some important bit of context people
On Tue, 2014-04-15 at 21:32 +0200, Daniel Vetter wrote:
On Mon, Apr 14, 2014 at 11:17:53AM +0300, Imre Deak wrote:
On Mon, 2014-04-14 at 09:47 +0200, Daniel Vetter wrote:
On Mon, Apr 14, 2014 at 9:43 AM, Arun Chandran achand...@mvista.com
wrote:
1) Revert the commit
On Tue, 2014-04-15 at 21:43 +0200, Daniel Vetter wrote:
On Mon, Apr 14, 2014 at 11:56:03AM -0700, Steven Noonan wrote:
On Mon, Apr 14, 2014 at 11:35:05AM -0700, Keith Packard wrote:
Steven Noonan ste...@uplinklabs.net writes:
Was using my machine normally, then my mouse cursor
On Tue, Apr 15, 2014 at 06:41:23PM +0200, Daniel Vetter wrote:
Like on hsw/bdw the pipe only starts running once the port/pch
transcoder combo is all enabled. Before that the vblank wait in the
primary plane enable function simply times out.
This is also really nice prep work for atomic
On Tue, Apr 15, 2014 at 11:10:34AM -0500, Jeff McGee wrote:
On Tue, Apr 15, 2014 at 11:00:33AM -0500, Jeff McGee wrote:
On Thu, Mar 27, 2014 at 05:59:48PM +, oscar.ma...@intel.com wrote:
From: Ben Widawsky benjamin.widaw...@intel.com
For the most part, logical rinf context objects
On Tue, Apr 15, 2014 at 06:41:22PM +0200, Daniel Vetter wrote:
Like on hsw/bdw the pipe isn't actually running yet at this point.
This holds for both pch ports and the cpu edp port according to my
testing on ilk, snb and ivb.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77297
On Tue, Apr 15, 2014 at 10:05 PM, Ville Syrjälä
ville.syrj...@linux.intel.com wrote:
This more or less duplicates what's in my watermark series already. Except
you have a few more bugs here. The intel_wait_for_vblank() should be after
the plane enabling since it's a hack to avoid the flip done
From: Vetter, Daniel
Sent: Wednesday, April 16, 2014 1:18 AM
To: Yang, Guang A; Barnes, Jesse; Widawsky, Benjamin; Wood, Thomas; Jin,
Gordon; OTC GFX QA Extended; intel-gfx@lists.freedesktop.org; Parenteau, Paul
A; Nikkanen, Kimmo
Subject: Re: The whole round of i-g-t testing cost too long
On Tue, Apr 15, 2014 at 03:43:23PM -0500, Jeff McGee wrote:
On Tue, Apr 15, 2014 at 11:10:34AM -0500, Jeff McGee wrote:
On Tue, Apr 15, 2014 at 11:00:33AM -0500, Jeff McGee wrote:
On Thu, Mar 27, 2014 at 05:59:48PM +, oscar.ma...@intel.com wrote:
From: Ben Widawsky
On Tue, Apr 15, 2014 at 11:01:02PM +0300, Imre Deak wrote:
On Tue, 2014-04-15 at 21:32 +0200, Daniel Vetter wrote:
On Mon, Apr 14, 2014 at 11:17:53AM +0300, Imre Deak wrote:
On Mon, 2014-04-14 at 09:47 +0200, Daniel Vetter wrote:
On Mon, Apr 14, 2014 at 9:43 AM, Arun Chandran
On Mon, Apr 07, 2014 at 04:51:21PM -0300, Paulo Zanoni wrote:
2014-03-07 13:32 GMT-03:00 ville.syrj...@linux.intel.com:
From: Ville Syrjälä ville.syrj...@linux.intel.com
We already do this for HSW, but doing it makes sense for everything else
as well. Extend it for ILK/SNB/IVB since
On Tue, Apr 15, 2014 at 11:08:02PM +0200, Daniel Vetter wrote:
On Tue, Apr 15, 2014 at 03:43:23PM -0500, Jeff McGee wrote:
On Tue, Apr 15, 2014 at 11:10:34AM -0500, Jeff McGee wrote:
On Tue, Apr 15, 2014 at 11:00:33AM -0500, Jeff McGee wrote:
On Thu, Mar 27, 2014 at 05:59:48PM +,
On Tue, Apr 15, 2014 at 12:59 PM, Imre Deak imre.d...@intel.com wrote:
On Tue, 2014-04-15 at 21:43 +0200, Daniel Vetter wrote:
On Mon, Apr 14, 2014 at 11:56:03AM -0700, Steven Noonan wrote:
On Mon, Apr 14, 2014 at 11:35:05AM -0700, Keith Packard wrote:
Steven Noonan ste...@uplinklabs.net
The BDW GT3 has two independent BSD rings, which can be used to process the
video commands. To be simpler, it is transparent to user-space driver/middle.
Instead the kernel driver will decide which ring is to dispatch the BSD video
command.
As every BSD ring is powerful, it is enough to dispatch
Based on the hardware spec, the BDW GT3 machine has two independent
BSD ring that can be used to dispatch the video commands.
So just initialize it.
Signed-off-by: Zhao Yakui yakui.z...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c |4 +--
drivers/gpu/drm/i915/i915_drv.h |
Based on the hardware spec, the BDW GT3 has the different configuration
with the BDW GT1/GT2. So split the BDW device info definition.
This is to do the preparation for adding the Dual BSD rings on BDW GT3 machine.
V1-V2: Follow Daniel's comment to pay attention to the stolen check for BDW
in
One extra ring is added in the kernel driver but it is transparent to the
user-space application/middleware. In such case the number of the rings
in kernel driver is bigger than that exported to the user-space. So
it needs to filter out the wrong Ring ID passed by user-space.
Signed-off-by: Zhao
This is the patch set that tries to add the support of dual BSD rings on BDW
GT3. Based on hardware spec, the BDW GT3 has two independent BSD rings, which
can be used to process the video commands. To be simpler, it is transparent
to user-space driver/middleware. In such case the kernel driver
The Gen7 doesn't have the second BSD ring. But it will complain the switch check
warning message during compilation. So just add it to remove the
switch check warning.
V1-V2: Follow Daniel's comment to update the comment
Signed-off-by: Zhao Yakui yakui.z...@intel.com
---
On Mon, Apr 14, 2014 at 10:55:53PM +0300, Ville Syrjälä wrote:
On Mon, Apr 14, 2014 at 10:41:14PM +0530, deepa...@intel.com wrote:
From: Ben Widawsky benjamin.widaw...@intel.com
Almost all of it is reusable from the existing code. The primary
difference is we need to do even less in the
Based on the hardware spec, the BDW GT3 has the different configuration
with the BDW GT1/GT2. So split the BDW device info definition.
This is to do the preparation for adding the Dual BSD rings on BDW GT3 machine.
V1-V2: Follow Daniel's comment to pay attention to the stolen check for BDW
in
The Gen7 doesn't have the second BSD ring. But it will complain the switch check
warning message during compilation. So just add it to remove the
switch check warning.
V1-V2: Follow Daniel's comment to update the comment
Signed-off-by: Zhao Yakui yakui.z...@intel.com
---
The BDW GT3 has two independent BSD rings, which can be used to process the
video commands. To be simpler, it is transparent to user-space driver/middle.
Instead the kernel driver will decide which ring is to dispatch the BSD video
command.
As every BSD ring is powerful, it is enough to dispatch
One extra ring is added in the kernel driver but it is transparent to the
user-space application/middleware. In such case the number of the rings
in kernel driver is bigger than that exported to the user-space. So
it needs to filter out the wrong Ring ID passed by user-space.
Signed-off-by: Zhao
This is the patch set that tries to add the support of dual BSD rings on BDW
GT3. Based on hardware spec, the BDW GT3 has two independent BSD rings, which
can be used to process the video commands. To be simpler, it is transparent
to user-space driver/middleware. In such case the kernel driver
Signed-off-by: Zhao Yakui yakui.z...@intel.com
---
drivers/gpu/drm/i915/i915_irq.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 7a4d3ae..63bd5de 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++
Based on the hardware spec, the BDW GT3 machine has two independent
BSD ring that can be used to dispatch the video commands.
So just initialize it.
Signed-off-by: Zhao Yakui yakui.z...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c |4 +--
drivers/gpu/drm/i915/i915_drv.h |
Ok there are a few cases where we can indeed make tests faster, but it will be
work for us. And that won't really speed up much since we're adding piles more
testcases at a pretty quick rate. And many of these new testcases are CRC
based, so inheritely take some time to run.
[He, Shuang] OK, so
76 matches
Mail list logo
