On Wed, Dec 09, 2015 at 05:08:02PM +0100, Daniel Vetter wrote:
> Every time I type or review docs this seems a bit different. Try to
> document the common style so we can try to unify at least new docs.
>
> v2: Spelling fixes from Pierre, Laurent and Jani.
>
> v3: More spelling fixes from Lukas.
From: Ville Syrjälä
The vma may have been rebound between the last time the cursor was
enabled and now, so skipping the cursor gtt offset deduction is not
safe unless we would also reset cursor_bo to NULL when disabling the
cursor. Just thow cursor_bo to the bin instead since it's lost all
other
On Tue, Dec 08, 2015 at 09:49:19AM +0100, Daniel Vetter wrote:
[...]
> @@ -187,6 +189,9 @@ struct drm_framebuffer_funcs {
>* copying the current screen contents to a private buffer and blending
>* between that and the new contents.
>*
> + * GEM based drivers should call
On Tue, Dec 08, 2015 at 09:49:18AM +0100, Daniel Vetter wrote:
> Just a remnant from an old iteration of this patch that I've forgotten
> to remove: We only need the encoder to figure out whether it has been
> reassigned in this update already or not to figure out whether there's
> a conflict or no
Hi,
On 14/12/15 11:36, Chris Wilson wrote:
In the next patch, request tracking is made more generic and for that we
need a new expanded struct and to separate out the logic changes from
the mechanical churn, we split out the structure renaming into this
patch. For extra fun, create a new i915_
On Mon, Dec 14, 2015 at 03:58:42PM +, Tvrtko Ursulin wrote:
>
> Hi,
>
>
> On 14/12/15 11:36, Chris Wilson wrote:
> >In the next patch, request tracking is made more generic and for that we
> >need a new expanded struct and to separate out the logic changes from
> >the mechanical churn, we sp
From: Ville Syrjälä
It's been a while since I last ran igt on gen2, so I figured I'd
give it a shot. 855 had some failures, 830 no longer worked at
all. So I went ahead and fixed them, and here's the result.
The first three patches are not even gen2 specific bugs I caught
with this effort. The r
From: Ville Syrjälä
When a partial ggtt vma gets evicted, we need to zap any CPU
mapping to said vma as well. Currently we zap the mappings
only when the normal gtt vma gets evicted, but for partial
vmas we leave behind stale CPU mappins. And so, if something
else gets bound into the same gtt add
From: Ville Syrjälä
Since
commit 4dfd648 ("drm: Use vblank timestamps to guesstimate how many vblanks
were missed")
the vblank code can cook up a frame counter value based on
the vblank timestamps (as long as they're accurate), so there's
no longer any need to keep vblank interrupts enabled on g
From: Ville Syrjälä
Gen2 doesn't have a hardware frame counter, so let's use the sw
counter value instead.
Testcase: igt/kms_pipe_crc_basic/read-crc-pipe-?-frame-sequence
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_debugfs.c | 11 +++
drivers/gpu/drm/i915/i915_irq.c
From: Ville Syrjälä
Restore the lost phys status page cleanup.
Fixes the following splat with DMA_API_DEBUG=y:
WARNING: CPU: 0 PID: 21615 at ../lib/dma-debug.c:974
dma_debug_device_change+0x190/0x1f0()
pci :00:02.0: DMA-API: device driver has pending DMA allocations while
released from de
From: Ville Syrjälä
The crc code assumes that the printed frame counter value takes
exactly 8 characters. The counter is a 32bit value, so to fit
it into 8 characters we need to print it in hex, in decimal it
would take 10 characters.
This obviously needs a corresponding change in intel-gpu-tool
From: Ville Syrjälä
We use the vblank timestamps to generate the vblank frame counter value
on gen2. That means we need the pipe scanout position to be accurate
when we call drm_crtc_vblank_on(), otherwise the frame counter
guesstimate may jump when the pipe actually start.
What I observed on my
From: Ville Syrjälä
My 85x has VBT version 108 which has a child dev size of 27 bytes.
Let's allow that without printing an error.
We still want to reject the actual parsin since for that we need
the child device size to be at least 33 bytes. So we should still
check for that, but let's make it
From: Ville Syrjälä
My 830 has VBT version 105 with child device size of 22 bytes.
Let's assume that's correct and adjust our expectations.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_bios.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/
From: Ville Syrjälä
MI_BATCH_BUFFER is nasty since it requires that userspace pass in the
correct batch length.
Let's switch to using MI_BATCH_BUFFER_START instead (like we do on
other platforms). Then we don't have to specify the batch length
at all, and the CS will instead execute until it see
From: Ville Syrjälä
We use MI_BATCH_BUFFER on 830/845, which means we need to know
the batch length. If the user passes a bad batch length (< 8)
the results is most likely a GPU hang. Rejct such batches.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 3 +++
1 file c
Swap the order of context & engine cleanup, so that it is now
contexts, then engines.
This allows the context clean up code to do things like confirm
that ring->dev->struct_mutex is locked without a NULL pointer
dereference.
This came about as a result of the 'intel_ring_initialized() must
be simpl
On Mon, Dec 14, 2015 at 01:23:34PM +, Ian Bruntlett wrote:
> Hi All,
>
> On 12 December 2015 at 12:54, Ian Bruntlett wrote:
>
> > I've got a couple of third hand computers using Intel graphics (Dell
> > Optiplex GX50, HP Compaq dc 7600) with graphics problems - Dell becomes
> > unusable, scr
On pe, 2015-12-11 at 14:14 +0530, Sagar Arun Kamble wrote:
> RC6 setup is shared between BIOS and Driver. BIOS sets up subset of RC6
> setup registers. If those are not setup Driver should not enable RC6.
> For implementing this, driver can check RC_CTRL0 and RC_CTRL1 values
> to know if BIOS has e
On Mon, Dec 14, 2015 at 06:23:49PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> MI_BATCH_BUFFER is nasty since it requires that userspace pass in the
> correct batch length.
>
> Let's switch to using MI_BATCH_BUFFER_START instead (like we do on
> other platforms). Then w
On Mon, Dec 14, 2015 at 06:23:40PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> When a partial ggtt vma gets evicted, we need to zap any CPU
> mapping to said vma as well. Currently we zap the mappings
> only when the normal gtt vma gets evicted, but for partial
> vmas we
On Mon, Dec 14, 2015 at 06:23:41PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Restore the lost phys status page cleanup.
>
> Fixes the following splat with DMA_API_DEBUG=y:
>
> WARNING: CPU: 0 PID: 21615 at ../lib/dma-debug.c:974
> dma_debug_device_change+0x190/0x1f0
On Mon, Dec 14, 2015 at 06:23:48PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> We use MI_BATCH_BUFFER on 830/845, which means we need to know
> the batch length. If the user passes a bad batch length (< 8)
> the results is most likely a GPU hang. Rejct such batches.
>
>
On Mon, Dec 14, 2015 at 04:30:04PM +, Nick Hoath wrote:
> diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
> b/drivers/gpu/drm/i915/i915_gem_context.c
> index 900ffd0..7df3c7a 100644
> --- a/drivers/gpu/drm/i915/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/i915_gem_context.c
> @@ -431,1
Getting guc load status does hardware access so it needs
to have pm ref.
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_debugfs.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 3e0e30d..5770307
When we drop caches, this debugfs entry does hardware access later in
the chain, when fences are updated, so it needs a runtime pm ref.
Dropping caches is used by some igt/bat tests, so this fixes
some unclaimed register access traces.
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_
intel_set_rps() does hardware access later in the
chain, so it needs a runtime pm ref.
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_debugfs.c | 4
drivers/gpu/drm/i915/i915_sysfs.c | 4
2 files changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
Getting subslice status does access hw so it needs a pm ref.
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_debugfs.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 5770307..c9d11ba 100644
---
Getting emon status does access hw so it needs to have pm ref.
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_debugfs.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 0e568de..3e0e30d 100644
---
Setting the fbc does hardware access so it needs to have
pm ref.
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_debugfs.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index d0e9f2d..0e568de 100644
--
On Mon, Dec 14, 2015 at 04:58:54PM +, Chris Wilson wrote:
> On Mon, Dec 14, 2015 at 06:23:49PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > MI_BATCH_BUFFER is nasty since it requires that userspace pass in the
> > correct batch length.
> >
> > Let's switch to u
On Mon, Dec 14, 2015 at 04:58:13PM +0100, Thierry Reding wrote:
> On Tue, Dec 08, 2015 at 09:49:19AM +0100, Daniel Vetter wrote:
> [...]
> > @@ -187,6 +189,9 @@ struct drm_framebuffer_funcs {
> > * copying the current screen contents to a private buffer and blending
> > * between that and
On Mon, Dec 14, 2015 at 05:01:45PM +, Chris Wilson wrote:
> On Mon, Dec 14, 2015 at 06:23:40PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > When a partial ggtt vma gets evicted, we need to zap any CPU
> > mapping to said vma as well. Currently we zap the mapping
On Mon, Dec 14, 2015 at 05:07:50PM +, Chris Wilson wrote:
> On Mon, Dec 14, 2015 at 06:23:48PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > We use MI_BATCH_BUFFER on 830/845, which means we need to know
> > the batch length. If the user passes a bad batch length
"Song, Ruiling" writes:
>> -Original Message-
>> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
>> Vetter
>> Sent: Monday, December 14, 2015 4:28 PM
>> To: Song, Ruiling
>> Cc: k...@bitplanet.net; Winiarski, Michal ;
>> mesa-...@lists.freedesktop.org; intel-gfx@l
"Song, Ruiling" writes:
>> -Original Message-
>> From: hoegsb...@gmail.com [mailto:hoegsb...@gmail.com] On Behalf Of
>> Kristian H?gsberg
>> Sent: Monday, December 14, 2015 1:34 PM
>> To: Song, Ruiling
>> Cc: Winiarski, Michal ; intel-
>> g...@lists.freedesktop.org; mesa-...@lists.freede
Ian Bruntlett composed on 2015-12-14 13:23 (UTC):
> Ian Bruntlett wrote:
>> I've got a couple of third hand computers using Intel graphics (Dell
>> Optiplex GX50, HP Compaq dc 7600) with graphics problems - Dell becomes
>> unusable, screen is all white with black squiggles after running updates o
Kristian Høgsberg writes:
> "Song, Ruiling" writes:
>
>>> -Original Message-
>>> From: hoegsb...@gmail.com [mailto:hoegsb...@gmail.com] On Behalf Of
>>> Kristian H?gsberg
>>> Sent: Monday, December 14, 2015 1:34 PM
>>> To: Song, Ruiling
>>> Cc: Winiarski, Michal ; intel-
>>> g...@lists.
From: Ville Syrjälä
Use igt_assert_eq() to compare the frame numbers during the frame
sequence tests so that we'll see exactly what the bad frame counts
are when the test fails.
Signed-off-by: Ville Syrjälä
---
tests/kms_pipe_crc_basic.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
d
From: Ville Syrjälä
Gen2/3 platforms have some unusual tile dimensions. Account
for them to make the test work correctly.
Signed-off-by: Ville Syrjälä
---
tests/gem_mmap_gtt.c | 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/tests/gem_mmap_gtt.c b/tests
From: Ville Syrjälä
During suspend tests we can exceed the current 100 frame difference
in sequence numbers. Bump the limit to 150 frames.
Signed-off-by: Ville Syrjälä
---
tests/kms_flip.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tests/kms_flip.c b/tests/kms_flip
From: Ville Syrjälä
igt_kms.c: In function ‘igt_crtc_set_background’:
igt_kms.c:1940:2: warning: format ‘%lu’ expects argument of type ‘long unsigned
int’, but argument 5 has type ‘uint64_t’ [-Wformat=]
LOG(display, "%s.%d: crtc_set_background(%lu)\n",
^
intel_firmware_decode.c: In function
From: Ville Syrjälä
With the kernel fixed to dump out the crc frame counts in hex,
we must follow suit.
Signed-off-by: Ville Syrjälä
---
lib/igt_debugfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/igt_debugfs.c b/lib/igt_debugfs.c
index 2c3b1cfe2370..5e71f50d7326
From: Ville Syrjälä
Some of the copy tests take a while, so let the user know how
far along we are via a progress indicator.
Signed-off-by: Ville Syrjälä
---
tests/gem_mmap_gtt.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/tests/gem_mmap_gtt.c b/tests/gem_mm
From: Ville Syrjälä
Several factors conspire against us when trying to execute
the tiled small-bo tests:
- pre-gen4 require power of two fences, with natural alignment
- the entire gtt may be mappable
- we put a guard page at the end of gtt
What all that means is that when we try to use a tiled
On Mon, Dec 14, 2015 at 01:16:46PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> These two should provide the minimal fix for the invisible cursor
> problem that's been plaguing me and some other people. It's caused
> by the cursor bo getting bound at ggtt offset 0, which
On Mon, Dec 14, 2015 at 10:15:53PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Several factors conspire against us when trying to execute
> the tiled small-bo tests:
> - pre-gen4 require power of two fences, with natural alignment
> - the entire gtt may be mappable
> - w
On Mon, Dec 14, 2015 at 08:49:38PM +, Chris Wilson wrote:
> On Mon, Dec 14, 2015 at 10:15:53PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Several factors conspire against us when trying to execute
> > the tiled small-bo tests:
> > - pre-gen4 require power of t
On Mon, Dec 14, 2015 at 07:14:23PM +0200, Mika Kuoppala wrote:
> When we drop caches, this debugfs entry does hardware access later in
> the chain, when fences are updated, so it needs a runtime pm ref.
>
> Dropping caches is used by some igt/bat tests, so this fixes
> some unclaimed register acce
On Mon, Dec 14, 2015 at 10:15:51PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Gen2/3 platforms have some unusual tile dimensions. Account
> for them to make the test work correctly.
iirc, for the purposes of the test, we could just set the stride to 512
and be done wit
From: Rafael J. Wysocki
Introduce a new runtime PM function, pm_runtime_get_if_in_use(),
that will increment the device's runtime PM usage counter and
return 'true' if its status is RPM_ACTIVE and its usage counter
is greater than 0 at the same time ('false' will be returned
otherwise).
This is
Hi Felix,
Like I've emailed Daniel Vetter and Jani Nikula, as well as getting help, I
hope to one day be able to provide help. I used to be a C programmer and
I've discovered https://01.org/linuxgraphics/documentation
On 14 December 2015 at 18:17, Felix Miata wrote:
> I've run across many Optip
On Tue, Dec 01, 2015 at 08:27:32AM -0800, Marc MERLIN wrote:
> On Sat, Nov 28, 2015 at 09:54:50AM -0800, Marc MERLIN wrote:
> > On Tue, Nov 17, 2015 at 05:11:05PM +0200, Jani Nikula wrote:
> > > On Tue, 17 Nov 2015, Marc MERLIN wrote:
> > > > So, this is probably the 3rd time I send such a report
On Mon, Dec 14, 2015 at 05:13:43PM +, Chris Wilson wrote:
> On Mon, Dec 14, 2015 at 04:30:04PM +, Nick Hoath wrote:
> > diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
> > b/drivers/gpu/drm/i915/i915_gem_context.c
> > index 900ffd0..7df3c7a 100644
> > --- a/drivers/gpu/drm/i915/i915_g
In addition to calculating final watermarks, let's also pre-calculate a
set of intermediate watermark values at atomic check time. These
intermediate watermarks are a combination of the watermarks for the old
state and the new state; they should satisfy the requirements of both
states which means
Yes, your code is clear. It tried to check hot-plug with 4 times based on delay
setup (30ms) in following patch,
commit 237ed86c693d8a8e4db476976aeb30df4deac74b
Author: Sonika Jindal
Date: Tue Sep 15 09:44:20 2015 +0530
drm/i915: Check live status before reading edid
I will refine patch
The total delay of HDMI hotplug detecting with 30ms have already
been split into a resolution of 3 retries of 10ms each, for the worst
cases. But it still suffered from only waiting 10ms at most in
intel_hdmi_detect(). This patch corrects it by reading hotplug status
with 4 times at most for 30ms d
On Mon, 2015-12-14 at 10:05 +, Chris Wilson wrote:
> > diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> > index d727b49..ebce8c9 100644
> > --- a/include/uapi/drm/i915_drm.h
> > +++ b/include/uapi/drm/i915_drm.h
> > @@ -357,6 +357,7 @@ typedef struct drm_i915_irq_wait {
101 - 159 of 159 matches
Mail list logo
