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 {
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
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
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
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
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
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
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
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
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 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 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 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
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
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ä
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ä
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ä
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
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.
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
"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
"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
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
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 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 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
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
--
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
---
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
---
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
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_
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
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
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 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: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: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 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 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
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
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
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ä
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ä
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ä
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ä
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ä
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ä
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ä
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
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
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 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
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
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 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.
On Mon, Dec 14, 2015 at 05:35:02PM +0200, ville.syrj...@linux.intel.com wrote:
> 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 whe
On Mon, Dec 14, 2015 at 11:32:23AM +, Chris Wilson wrote:
> On Mon, Dec 14, 2015 at 01:16:47PM +0200, ville.syrj...@linux.intel.com wrote:
> > 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
On Mon, Dec 14, 2015 at 02:59:30PM +, Tvrtko Ursulin wrote:
>
> Hi,
>
> On 11/12/15 11:33, Chris Wilson wrote:
> >Now that we have split out the seqno-barrier from the
> >engine->get_seqno() callback itself, we can move the users of the
> >seqno-barrier to the required callsites simplifying t
On Mon, Dec 14, 2015 at 03:31:09PM +0200, Meelis Roos wrote:
> Between 4.4-rc3 and 4.4-rc4, i915 modesetting broke on my i5-2400 PC.
That would seem to be SNB.
> Instead of seeing the new dense graphics mode, I see the last VGA text
> lines and no X appears either.
That's a bit weird. SNB has
Hi,
On 11/12/15 11:33, Chris Wilson wrote:
Now that we have split out the seqno-barrier from the
engine->get_seqno() callback itself, we can move the users of the
seqno-barrier to the required callsites simplifying the common code and
making the required workaround handling much more explicit.
On Sun, Dec 13, 2015 at 12:49:45PM +, Chris Wilson wrote:
> On Wed, Nov 25, 2015 at 04:47:22PM +0200, Jani Nikula wrote:
> > We had the "The master control interrupt lied (SDE)!" check and error
> > message in place for a long time without any problems, until
> >
> > commit aaf5ec2e51ab1d9c5e9
On Mon, Dec 14, 2015 at 04:38:58PM +0200, Jani Nikula wrote:
> On Mon, 14 Dec 2015, Ville Syrjälä wrote:
> > On Mon, Dec 14, 2015 at 12:50:53PM +0200, Jani Nikula wrote:
> >> Hasn't been necessary since
> >>
> >> commit 115719fceaa733d646e39cdce83cc32ddb891a49
> >> Author: Williams, Dan J
> >> D
On Mon, Dec 14, 2015 at 04:34:50PM +0200, Jani Nikula wrote:
> On Mon, 14 Dec 2015, Ville Syrjälä wrote:
> > On Mon, Dec 14, 2015 at 12:50:50PM +0200, Jani Nikula wrote:
> >> Make the validation function a boolean operating on a buffer of given
> >> size, removing the extra pointer dances.
> >>
>
On Mon, 14 Dec 2015, Ville Syrjälä wrote:
> On Mon, Dec 14, 2015 at 12:50:55PM +0200, Jani Nikula wrote:
>> The RVDA and RVDS (raw VBT data address and size) fields of the ASLE
>> mailbox may specify an alternate location for VBT instead of mailbox #4.
>> Use the alternate location if available an
On Mon, 14 Dec 2015, Ville Syrjälä wrote:
> On Mon, Dec 14, 2015 at 12:50:53PM +0200, Jani Nikula wrote:
>> Hasn't been necessary since
>>
>> commit 115719fceaa733d646e39cdce83cc32ddb891a49
>> Author: Williams, Dan J
>> Date: Mon Oct 12 21:12:57 2015 +
>>
>> i915: switch from acpi_os_
On Mon, Dec 14, 2015 at 04:19:50PM +0200, Ville Syrjälä wrote:
> On Mon, Dec 14, 2015 at 12:50:55PM +0200, Jani Nikula wrote:
> > The RVDA and RVDS (raw VBT data address and size) fields of the ASLE
> > mailbox may specify an alternate location for VBT instead of mailbox #4.
> > Use the alternate l
On Mon, 14 Dec 2015, Ville Syrjälä wrote:
> On Mon, Dec 14, 2015 at 12:50:50PM +0200, Jani Nikula wrote:
>> Make the validation function a boolean operating on a buffer of given
>> size, removing the extra pointer dances.
>>
>> Move the OpRegion based VBT validation to intel_opregion_setup(), onl
On Mon, Dec 14, 2015 at 12:50:55PM +0200, Jani Nikula wrote:
> The RVDA and RVDS (raw VBT data address and size) fields of the ASLE
> mailbox may specify an alternate location for VBT instead of mailbox #4.
> Use the alternate location if available and valid, falling back to
> mailbox #4 otherwise.
On Mon, Dec 14, 2015 at 01:54:38PM +, Chris Wilson wrote:
> This reverts commit e9f24d5fb7cf3628b195b18ff3ac4e37937ceeae.
>
> The patch was incomplete, introduced more problems of greater severity
> than it solved and worse the solution was known and available at the
> time of the patch.
Bad
Our driver compiles clean (nowadays thanks to 0day) but for me, at least,
it would be beneficial if the compiler threw an error rather than a
warning when it found a piece of suspect code. (I use this to
compile-check patch series and want to break on the first compiler error
in order to fix the pa
Between 4.4-rc3 and 4.4-rc4, i915 modesetting broke on my i5-2400 PC.
Instead of seeing the new dense graphics mode, I see the last VGA text
lines and no X appears either.
I saw something similar on I865G but have not had time to check if it is
the same issue.
ac9b8236551d1177fd07b56aef9b565d1
This reverts commit e9f24d5fb7cf3628b195b18ff3ac4e37937ceeae.
The patch was incomplete, introduced more problems of greater severity
than it solved and worse the solution was known and available at the
time of the patch.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h |
On Mon, Dec 14, 2015 at 12:50:53PM +0200, Jani Nikula wrote:
> Hasn't been necessary since
>
> commit 115719fceaa733d646e39cdce83cc32ddb891a49
> Author: Williams, Dan J
> Date: Mon Oct 12 21:12:57 2015 +
>
> i915: switch from acpi_os_ioremap to memremap
>
> Signed-off-by: Jani Nikula
On Mon, Dec 14, 2015 at 11:39:47AM +, Chris Wilson wrote:
> On Mon, Dec 14, 2015 at 11:28:39AM +, Dave Gordon wrote:
> > If this is a test that has disabled error state
> > capture (because it's *trying* to hang one or more rings) can we
> > still know how many rings have been diagnosed as
On Mon, Dec 14, 2015 at 12:50:50PM +0200, Jani Nikula wrote:
> Make the validation function a boolean operating on a buffer of given
> size, removing the extra pointer dances.
>
> Move the OpRegion based VBT validation to intel_opregion_setup(), only
> initializing opregion->vbt if it's valid.
>
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, screen is all white with black squiggles after running updates on
> Ubuntu 14.04
In the future the VBT might not be in mailbox #4 of the ACPI OpRegion,
thus unavailable in i915_opregion, so add a separate file for the VBT.
v2: Drop the locking as unneeded (Chris)
Cc: Chris Wilson
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_debugfs.c | 14 ++
driv
On Mon, Dec 14, 2015 at 12:21:32PM +, Tvrtko Ursulin wrote:
> >@@ -1229,18 +1219,13 @@ int __i915_wait_request(struct drm_i915_gem_request
> >*req,
> > s64 *timeout,
> > struct intel_rps_client *rps)
> > {
> >-struct intel_engine_cs *ring = i915_gem
On 14/12/15 11:58, John Harrison wrote:
On 11/12/2015 14:28, Tvrtko Ursulin wrote:
On 11/12/15 13:12, john.c.harri...@intel.com wrote:
From: John Harrison
The notify function can be called many times without the seqno
changing. A large number of duplicates are to prevent races due to the
req
On 14/12/15 11:22, John Harrison wrote:
On 11/12/2015 15:57, Tvrtko Ursulin wrote:
On 11/12/15 13:11, john.c.harri...@intel.com wrote:
From: Peter Lawthers
In the 3.14 kernel, a signaled fence was indicated by the status field
== 1. In 4.x, a status == 0 indicates signaled, status < 0 indic
On Mon, Dec 14, 2015 at 11:46:22AM +, John Harrison wrote:
> >>@@ -1341,6 +1375,17 @@ i915_gem_do_execbuffer(struct drm_device
> >>*dev, void *data,
> >> u32 dispatch_flags;
> >> int ret;
> >> bool need_relocs;
> >>+int fd_fence_complete = -1;
> >>+int fd_fence_wait = low
Hi,
On 11/12/15 11:33, Chris Wilson wrote:
One particularly stressful scenario consists of many independent tasks
all competing for GPU time and waiting upon the results (e.g. realtime
transcoding of many, many streams). One bottleneck in particular is that
each client waits on its own results,
On Tue, 2015-11-24 at 11:29 +0100, Maarten Lankhorst wrote:
> This fixes a warning when the crtc is turned off. In that case fb
> will be NULL, and crtc_clock will be 0. Because the crtc is no longer
> active this is not a bug, and shouldn't trigger the WARN_ON.
>
> Also remove handling a null crt
Op 04-12-15 om 09:12 schreef Daniel Vetter:
> On Thu, Dec 03, 2015 at 12:01:02PM +0100, Maarten Lankhorst wrote:
>> Op 03-12-15 om 10:53 schreef Daniel Vetter:
>>> On Tue, Nov 24, 2015 at 10:34:36AM +0100, Maarten Lankhorst wrote:
This allows iteration over encoders without requiring connectio
On 11/12/2015 14:28, Tvrtko Ursulin wrote:
On 11/12/15 13:12, john.c.harri...@intel.com wrote:
From: John Harrison
The notify function can be called many times without the seqno
changing. A large number of duplicates are to prevent races due to the
requirement of not enabling interrupts until
On 11/12/2015 15:29, Tvrtko Ursulin wrote:
On 11/12/15 13:12, john.c.harri...@intel.com wrote:
From: John Harrison
Various projects desire a mechanism for managing dependencies between
work items asynchronously. This can also include work items across
complete different and independent syste
On 14 December 2015 at 09:04, Daniel Vetter wrote:
> On Mon, Dec 14, 2015 at 08:41:05AM +, Song, Ruiling wrote:
>>
>>
>> > -Original Message-
>> > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
>> > Vetter
>> > Sent: Monday, December 14, 2015 4:28 PM
>> > To: S
Hook the vma itself into the i915_gem_request_retire() so that we can
accurately track when a solitary vma is inactive (as opposed to having
to wait for the entire object to be idle). This improves the interaction
when using multiple contexts (with full-ppgtt) and eliminates some
frequent list walk
On Mon, Dec 14, 2015 at 11:28:39AM +, Dave Gordon wrote:
> On 11/12/15 22:59, Chris Wilson wrote:
> >Remove some redundant kernel messages as we deduce a hung GPU and
> >capture the error state.
> >
> >Signed-off-by: Chris Wilson
> >---
> > drivers/gpu/drm/i915/i915_irq.c | 16 ++-
When the user closes the context mark it and the dependent address space
as closed. As we use an asynchronous destruct method, this has two purposes.
First it allows us to flag the closed context and detect internal errors if
we to create any new objects for it (as it is removed from the user's
nam
The multiple levels of indirect do nothing but hinder the compiler and
the pointer chasing turns to be quite painful but painless to fix.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c| 13 ++---
drivers/gpu/drm/i915/i915_drv.h| 7 ---
driver
In order to prevent a leak of the vma on shared objects, we need to
hook into the object_close callback to destroy the vma on the object for
this file. However, if we destroyed that vma immediately we may cause
unexpected application stalls as we try to unbind a busy vma - hence we
defer the unbind
This patch is broken out of the next just to remove the code motion from
that patch and make it more readable. What we do here is move the
i915_vma_move_to_active() to i915_gem_execbuffer.c and put the three
stages (read, write, fenced) together so that future modifications to
active handling are a
This reverts commit e9f24d5fb7cf3628b195b18ff3ac4e37937ceeae.
The patch was incomplete, introduced more problems of greater severity
than it solved and worse the solution was known and available at the
time of the patch.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h |
As we can now have multiple VMA inside the global GTT (with partial
mappings, rotations, etc), it is no longer true that there may just be a
single GGTT entry and so we should walk the full vma_list to count up
the actual usage. In addition to unifying the two walkers, switch from
multiplying the o
For the global GTT (and aliasing GTT), the address space is owned by the
device (it is a global resource) and so the per-file owner field is
NULL. For per-process GTT (where we create an address space per
context), each is owned by the opening file. We can use this ownership
information to both dis
1 - 100 of 159 matches
Mail list logo
