git clean updates the .gitignore file? Not having to run git clean is the
whole point of this patch...
On 08/14/2015 01:09 AM, Daniel Vetter wrote:
> On Thu, Aug 13, 2015 at 01:31:41PM -0700, Jesse Barnes wrote:
>
> git clean fixes this all, at least over here git status is clean.
> -Daniel
>
---
tests/core_getversion.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/core_getversion.c b/tests/core_getversion.c
index f994315..2f481c9 100644
--- a/tests/core_getversion.c
+++ b/tests/core_getversion.c
@@ -37,7 +37,7 @@ igt_simple_main
int fd;
drmV
---
tests/core_get_client_auth.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tests/core_get_client_auth.c b/tests/core_get_client_auth.c
index 92313f9..3518bb7 100644
--- a/tests/core_get_client_auth.c
+++ b/tests/core_get_client_auth.c
@@ -84,7 +84,7 @@ igt_main
{
On 08/14/2015 05:19 AM, Daniel Vetter wrote:
> On Thu, Aug 13, 2015 at 01:31:24PM -0700, Jesse Barnes wrote:
>> There was a lot of duplication going on... Mark as basic while we're at
>> it as these should never fail.
>>
>> Signed-off-by: Jesse Barnes
>> ---
>> tests/Makefile.sources | 1 +
>
On 08/14/2015 05:27 AM, Daniel Vetter wrote:
> On Thu, Aug 13, 2015 at 01:31:28PM -0700, Jesse Barnes wrote:
>> Fundamental and simple functionality.
>>
>> Signed-off-by: Jesse Barnes
>
> Mark entire testcase as basic instead to catch future extensions?
> getparams should always complete super-fa
The drm_open_driver*() functions replace the drm_open_any*() functions and
provide the same utility, but in a way that is platform agnostic, not
intel-specific. This opens the path for adopting intel-gpu-tools to non-intel
platforms.
This commit renames the calls and adds the chipset parameter wh
Changes since last version of patch:
Now using the core_* tests as demonstrations rather than drm_read.
Micah Fedke (7):
lib: adding drm_open_driver() interface
convert drm_open_any*() calls to drm_open_driver*(DRIVER_INTEL) calls
with cocci
lib: remove support for deprecated drm_open_a
---
tests/core_getstats.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/core_getstats.c b/tests/core_getstats.c
index cdab0e5..6f6a4ee 100644
--- a/tests/core_getstats.c
+++ b/tests/core_getstats.c
@@ -48,7 +48,7 @@ igt_simple_main
int fd, ret;
drm_stats
On 08/14/2015 05:22 AM, Daniel Vetter wrote:
> On Thu, Aug 13, 2015 at 01:31:26PM -0700, Jesse Barnes wrote:
>> Reduces runtime a lot...
>>
>> Signed-off-by: Jesse Barnes
>> ---
>> tests/drv_module_reload_basic | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/tests/drv_
Apply the new API to all call sites within the test suite using the following
semantic patch:
// Semantic patch for replacing drm_open_any* with arch-specific
drm_open_driver* calls
@@
identifier i =~ "\bdrm_open_any\b";
@@
- i()
+ drm_open_driver(DRIVER_INTEL)
@@
identifier i =~ "\bdrm_open_any
---
tests/core_getclient.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/core_getclient.c b/tests/core_getclient.c
index d82e349..5293741 100644
--- a/tests/core_getclient.c
+++ b/tests/core_getclient.c
@@ -39,7 +39,7 @@ igt_simple_main
int fd, ret;
drm_
Signed-off-by: Micah Fedke
---
lib/drmtest.h | 6 --
1 file changed, 6 deletions(-)
diff --git a/lib/drmtest.h b/lib/drmtest.h
index dcb0c34..41ddbe7 100644
--- a/lib/drmtest.h
+++ b/lib/drmtest.h
@@ -41,12 +41,6 @@
#define OPEN_ANY_GPU 0x1
#define DRIVER_INTEL (0x1 << 1)
-/* provide the
On 08/14/2015 05:26 AM, Daniel Vetter wrote:
> On Thu, Aug 13, 2015 at 01:31:27PM -0700, Jesse Barnes wrote:
>> They're testing basic functionality and don't involve stress or race
>> induction.
>>
>> Signed-off-by: Jesse Barnes
>
> These are more stress-tests in nature I think. For basic testsca
On 08/14/2015 05:32 AM, Daniel Vetter wrote:
> On Thu, Aug 13, 2015 at 01:31:30PM -0700, Jesse Barnes wrote:
>> Need some LRC tests in the 'basic' subset, and this is a good simple
>> one.
>>
>> Signed-off-by: Jesse Barnes
>
> This is just a testcase for a very specific lrc corner case. We do alr
On 08/14/2015 05:33 AM, Daniel Vetter wrote:
> On Thu, Aug 13, 2015 at 01:31:31PM -0700, Jesse Barnes wrote:
>> We should be able to create small and moderate sized objects quickly and
>> without errors.
>>
>> Signed-off-by: Jesse Barnes
>
> They're all super-fast basic testcases for api cornerca
By running igt/store_dword_loop_render on BXT we can hit a coherency
problem where the seqno written at GPU command completion time is not
seen by the CPU. This results in __i915_wait_request seeing the stale
seqno and not completing the request (not considering the lost
interrupt/GPU reset mechani
On 08/14/2015 05:29 AM, Daniel Vetter wrote:
> On Thu, Aug 13, 2015 at 01:31:29PM -0700, Jesse Barnes wrote:
>> debugfs may not be mounted, but sysfs should always be restored after
>> suspend or hibernate.
>>
>> Signed-off-by: Jesse Barnes
>
> We already have a suspend/resume testcase in kms_pip
On 08/14/2015 05:41 AM, Daniel Vetter wrote:
> On Thu, Aug 13, 2015 at 01:31:34PM -0700, Jesse Barnes wrote:
>> These simple tests should always pass.
>>
>> Signed-off-by: Jesse Barnes
>
> Imo shouldn't be part of the basic set, they thrash the machine quite
> badly. Especially gem_tiled_pread_pw
Due to a coherency issue on BXT A steppings we can't guarantee a
coherent view of cached (CPU snooped) GPU mappings, so fail such
requests. User space is supposed to fall back to uncached mappings in
this case.
v2:
- limit the WA to A steppings, on later stepping this HW issue is fixed
v3:
- retur
The ENODEV return value was introduced to the GEM_SET_CACHING ioctl to
mean that the given platform doesn't support the requested caching level
(currently only due to a HW issues on BXT A steppings). Handle this as
the other cases where we want to skip the related subtests.
Signed-off-by: Imre Dea
On 08/14/2015 05:44 AM, Daniel Vetter wrote:
> On Thu, Aug 13, 2015 at 01:31:36PM -0700, Jesse Barnes wrote:
>> Need some simple vblank coverage in the BAT list.
>>
>> Signed-off-by: Jesse Barnes
>
> This testcase relies upon fbcon to have enabled pipe 0, which means it
> spuriously skips (when f
On 08/14/2015 05:50 AM, Daniel Vetter wrote:
> On Thu, Aug 13, 2015 at 01:31:38PM -0700, Jesse Barnes wrote:
>> These always need to pass for basic PM functionality.
>>
>> Signed-off-by: Jesse Barnes
>> ---
>> tests/pm_rpm.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff
On Fri, Aug 14, 2015 at 08:29:40AM -0700, Jesse Barnes wrote:
> On 08/14/2015 05:29 AM, Daniel Vetter wrote:
> > On Thu, Aug 13, 2015 at 01:31:29PM -0700, Jesse Barnes wrote:
> >> debugfs may not be mounted, but sysfs should always be restored after
> >> suspend or hibernate.
> >>
> >> Signed-off-b
On Fri, Aug 14, 2015 at 08:31:01AM -0700, Jesse Barnes wrote:
> On 08/14/2015 05:32 AM, Daniel Vetter wrote:
> > On Thu, Aug 13, 2015 at 01:31:30PM -0700, Jesse Barnes wrote:
> >> Need some LRC tests in the 'basic' subset, and this is a good simple
> >> one.
> >>
> >> Signed-off-by: Jesse Barnes
>
On Fri, Aug 14, 2015 at 08:31:53AM -0700, Jesse Barnes wrote:
> On 08/14/2015 05:33 AM, Daniel Vetter wrote:
> > On Thu, Aug 13, 2015 at 01:31:31PM -0700, Jesse Barnes wrote:
> >> We should be able to create small and moderate sized objects quickly and
> >> without errors.
> >>
> >> Signed-off-by:
On Fri, Aug 14, 2015 at 08:48:42AM -0700, Jesse Barnes wrote:
> On 08/14/2015 05:50 AM, Daniel Vetter wrote:
> > On Thu, Aug 13, 2015 at 01:31:38PM -0700, Jesse Barnes wrote:
> >> These always need to pass for basic PM functionality.
> >>
> >> Signed-off-by: Jesse Barnes
> >> ---
> >> tests/pm_rp
On Fri, Aug 14, 2015 at 08:20:22AM -0700, Jesse Barnes wrote:
> git clean updates the .gitignore file? Not having to run git clean is the
> whole point of this patch...
I looked at this patch first, but later noticed that you have a few
renames where you don't update the .gitignore.
>
> On 08/1
On Fri, Aug 14, 2015 at 08:21:12AM -0700, Jesse Barnes wrote:
> On 08/14/2015 05:19 AM, Daniel Vetter wrote:
> > On Thu, Aug 13, 2015 at 01:31:24PM -0700, Jesse Barnes wrote:
> >> There was a lot of duplication going on... Mark as basic while we're at
> >> it as these should never fail.
> >>
> >>
On Fri, Aug 14, 2015 at 06:43:30PM +0300, Imre Deak wrote:
> Due to a coherency issue on BXT A steppings we can't guarantee a
> coherent view of cached (CPU snooped) GPU mappings, so fail such
> requests. User space is supposed to fall back to uncached mappings in
> this case.
>
> v2:
> - limit th
Hi Dave,
drm-intel-next-2015-07-31:
- kerneldoc for tiling/swizzling/fencing code
- bxt hpd port A w/a
- various other fixes all over
... not much, everyone's on vacation.
Cheers, Daniel
The following changes since commit e0548f1979bfee900fb0671a5dd3a2f217dce5df:
drm/i915: Update DRIVER_DAT
On Fri, Aug 14, 2015 at 06:35:27PM +0300, Imre Deak wrote:
> By running igt/store_dword_loop_render on BXT we can hit a coherency
> problem where the seqno written at GPU command completion time is not
> seen by the CPU. This results in __i915_wait_request seeing the stale
> seqno and not completin
On Fri, Aug 14, 2015 at 05:12:57AM +, Zhang, Xiong Y wrote:
> > On Mon, Aug 10, 2015 at 03:26:09PM +0800, Xiong Zhang wrote:
> > > Only internal eDP, LVDS, DVI screen could set scalling mode, some
> > > customers need to set scalling mode for external DP, HDMI, VGA screen.
> > > Let's fulfill t
On Mon, Jun 16, 2014 at 04:11:00PM +0100, oscar.ma...@intel.com wrote:
> From: Oscar Mateo
>
> Otherwise, we might receive a new interrupt before we have time to
> ack the first one, eventually missing it.
>
> Without an atomic XCHG operation with mmio space, this patch merely
> reduces the wind
The PIPE.STAT register contains some interrupt status bits per pipe, and
if assert cause the corresponding bit in the IIR to be asserted (thus
raising an interrupt). When handling an interrupt, we should clear the
PIPE.STAT generator first before clearing the IIR so that we do not miss
events or ca
On 08/13/2015 08:20 PM, Jonathan Corbet wrote:
> On Thu, 13 Aug 2015 20:09:35 -0300
> Danilo Cesar Lemes de Paula wrote:
>
>> Did you find time to take a look on this?
>
> No. Just when I thought things couldn't get crazier, my laptop died.
>
> https://plus.google.com/+JonathanCorbet/p
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 7142
-Summary-
Platform Delta drm-intel-nightly Series Applied
ILK -2
On 08/14/2015 09:01 AM, Daniel Vetter wrote:
> On Fri, Aug 14, 2015 at 08:29:40AM -0700, Jesse Barnes wrote:
>> On 08/14/2015 05:29 AM, Daniel Vetter wrote:
>>> On Thu, Aug 13, 2015 at 01:31:29PM -0700, Jesse Barnes wrote:
debugfs may not be mounted, but sysfs should always be restored after
>
On 08/14/2015 09:07 AM, Daniel Vetter wrote:
> On Fri, Aug 14, 2015 at 08:20:22AM -0700, Jesse Barnes wrote:
>> git clean updates the .gitignore file? Not having to run git clean is the
>> whole point of this patch...
>
> I looked at this patch first, but later noticed that you have a few
> rena
On 08/14/2015 05:56 AM, Daniel Vetter wrote:
> On Thu, Aug 13, 2015 at 01:31:39PM -0700, Jesse Barnes wrote:
>> Simple variants that don't do multiple output or interruptible testing.
>>
>> Signed-off-by: Jesse Barnes
>> ---
>> tests/kms_flip.c | 11 ++-
>> 1 file changed, 10 insertions(+
Hi Mika,
On Fri, Aug 14, 2015 at 01:03:24PM +0300, Mika Kahola wrote:
> It is possible the we request to have a mode that has
> higher pixel clock than our HW can support. This patch
> checks if requested pixel clock is lower than the one
> supported by the HW. The requested mode is discarded
> if
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 7150
-Summary-
Platform Delta drm-intel-nightly Series Applied
ILK
Always update the currrent crtc, fb and vertical offset after calling
enable_fbc. We were forgetting to do so along the failure paths when
enabling fbc synchronously. Fix this with a new helper to enable_fbc()
and update the state simultaneously.
v2: Improve commit message (Chris).
Signed-off-by:
Hello
This series contains tons of bug fixes for FBC. Some of the patches on this
series have seen the mailing list a few times already. With this series applied,
my BDW machine passes all the FBC tests that are on IGT.
This means we could even try to enable FBC on BDW by default, but I won't put
This commit is essentially a rewrite of "drm/i915: Check pixel format
for fbc" from Ville Syrjälä. The idea is the same, but the code is
different due to all the changes that happened since his original
patch. So any bugs are due to my bad rewrite.
Testcases: igt/kms_frontbuffer_tracking/*fbc*-${f
I only tested this on BDW, but since the register description is the
same ever since gen4, let's assume that all gens take the same
register format. If that's not true, then hopefully someone will
bisect a bug to this patch and we'll fix it.
Notice that the wrong fence offset register just means t
The doc is pretty clear that this register should be set to 0 on SNB.
We already write y_offset to DPFC_CPU_FENCE_OFFSET a few lines below.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_fbc.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i
The spec says the register should have that value for the entire time
that FBC is enabled, so apply the WA before we enable FBC.
Notice that we also have this WA for ILK/SNB, but it is implemented at
init_clock_gating(). I could move the IVB/HSW/BDW WA code to
init_clock_gating() too, but since we
BSpec says we shouldn't enable FBC on BDW when the pipe pixel rate
exceeds 95% of the core display clock.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_fbc.c | 8
2 files changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/i915/i91
And also print the threshold. I was surprised to see a log message
claiming the CFB size was 32mb when there was less than 24mb available
for it.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_fbc.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/
The FBC hardware for these platforms doesn't have access to the
bios_reserved range, so it always assumes the maximum (8mb) is used.
So avoid this range while allocating.
This solves a bunch of FIFO underruns that happen if you end up
putting the CFB in that memory range. On my machine, with 32mb
We used to have this bug in the past, but now that we properly track
the size of the CFB, we don't have it anymore. Still, add the WARN
just to make sure we don't go back to the bad state.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_fbc.c | 2 ++
1 file changed, 2 insertions(+)
d
I could only find the restrictions for HSW+, but I think it's safe to
assume that the older platforms also can't support the configurations
HSW can't support. The older platforms probably have additional
restrictions, so we need to figure out those and implement them later.
Let's not block HSW+ FBC
Keep searching in case the candidate has a NULL primary fb. This is
only relevant for the platforms that don't have the pipe_a_only
restriction.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_fbc.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/
We were considering the whole framebuffer height, but the spec clearly
says that we should only consider the active display height size.
On my current testing machine, this moves us from 124 successes and
502 skips to 209 successes and 417 skips on "kms_frontbuffer_tracking
--fbc-only". The high a
This reverts commit 0ffb0ff283cca16f72caf29c44496d83b0c291fb.
Technology has evolved and now we have eDP panels with 3200x1800
resolution. In the meantime, the BIOS guys didn't change the default
32mb for stolen memory. And we can't assume our users will be able to
increase the default stolen memo
The spec says we just can't use it.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_gem_stolen.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c
b/drivers/gpu/drm/i915/i915_gem_stolen.c
index 824334d..a292ea1 100644
--- a/drivers/gpu/drm/i
If we want to try to enable FBC by default on any platform we need to
be on the safe side and disable it in case we get an underrun while
FBC is enabled on the corresponding pipe. We currently already have
other reasons for FIFO underruns on our driver, but the ones I saw
with FBC lead to black scr
This WA is only for HSW/BDW.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_fbc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index b76c19f..5dfe460 100644
--- a/drivers/gpu/drm/i915/intel_fbc
Hi Daniel,
On 08/13/2015 04:04 AM, Daniel Vetter wrote:
On Wed, Aug 12, 2015 at 08:29:14PM -0300, Tiago Vignatti wrote:
+ /* Map too big */
+ handle = gem_create(fd, BO_SIZE);
+ fill_bo(handle, BO_SIZE);
+ dma_buf_fd = prime_handle_to_fd(fd, handle);
+ igt_assert(e
Sorry, but I don't get how this enables power_well_2 as well. I just see it
enabling ddi A/E as the other.
Maybe Paulo or Imre are the best one to review this.
On Thu, Aug 13, 2015 at 2:54 AM Xiong Zhang wrote:
> From B spec, DDI_E port belong to PowerWell 2, but
> DDI_E share the powerwell_req
On Wed, Aug 5, 2015 at 12:34 PM, Benjamin Tissoires
wrote:
> On Jul 30 2015 or thereabouts, Sivakumar Thulasimani wrote:
>>
>>
>> On 7/29/2015 8:52 PM, Benjamin Tissoires wrote:
>> >On Jul 29 2015 or thereabouts, Sivakumar Thulasimani wrote:
>> >>why not detect reverse in intel_dp_detect/intel_hpd
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 7152
-Summary-
Platform Delta drm-intel-nightly Series Applied
ILK
On 11 August 2015 at 17:54, Maarten Lankhorst
wrote:
> The port is removed synchronously, but the connector delayed.
> This causes a use after free which can cause a kernel BUG with
> slug_debug=FPZU. This is fixed by freeing the port after the
> connector.
Where is the use after free btw? I'm no
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 7155
-Summary-
Platform Delta drm-intel-nightly Series Applied
ILK -1
101 - 164 of 164 matches
Mail list logo
