On Fri, Jun 30, 2017 at 09:46:36PM +0300, Ville Syrjälä wrote:
> On Fri, Jun 30, 2017 at 08:23:58PM +0200, Daniel Vetter wrote:
> > On Fri, Jun 30, 2017 at 5:44 PM, Ville Syrjälä
> > wrote:
> > >> And if the GEM folks insist the old behavior can't be restored, then we
> > >> just need a tailor-mad
On Fri, Jun 30, 2017 at 5:39 PM, Chris Wilson wrote:
>> Yeah, but my point is that this here is an extremely fancy and fragile
>> (and afaics in this form, incomplete) fix for something that in the past
>> was fixed much, much simpler. Why do we need this massive amount of
>> complexity now? Who's
On Fri, Jun 30, 2017 at 03:03:17PM -0300, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> In some cases, like cursor updates, it is interesting to update the
> plane in an asynchronous fashion to avoid big delays. The current queued
> update could be still waiting for a fence to signal and thu
Quoting Daniel Vetter (2017-07-03 09:03:36)
> On Fri, Jun 30, 2017 at 5:39 PM, Chris Wilson
> wrote:
> >> Yeah, but my point is that this here is an extremely fancy and fragile
> >> (and afaics in this form, incomplete) fix for something that in the past
> >> was fixed much, much simpler. Why do
We try to fixup the context image after the reset to ensure that there
are no more pending writes from the hw that may conflict and to fixup
any that were in flight.
Fixes: a1ef70e14453 ("drm/i915: Add support for per engine reset recovery")
Signed-off-by: Chris Wilson
Cc: Michel Thierry
Cc: Tvr
As part of the knowing whether there is outstanding data in the CSB,
also check whether there is an outstanding IRQ notification.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_debugfs.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
Op 30-06-17 om 14:46 schreef Daniel Vetter:
> On Thu, Jun 29, 2017 at 01:59:54PM +0200, Maarten Lankhorst wrote:
>> Signed-off-by: Maarten Lankhorst
> With a real commit message (just explain why it's needed):
>
> Reviewed-by: Daniel Vetter
>
> Also needs
>
> Fixes: db8f6403e88a ("drm: Convert dr
On Fri, Jun 30, 2017 at 08:13:58PM +0200, Daniel Vetter wrote:
> On Fri, Jun 30, 2017 at 6:51 PM, Liviu Dudau wrote:
> > Prior to commit b0aa06e9a7fd ("drm/fb-helper: Support deferred setup"),
> > if no output is connected at framebuffer setup time, we get a default
> > 1024x768 mode that is going
== Series Details ==
Series: series starting with [1/2] drm/i915: Report execlists irq bit in debugfs
URL : https://patchwork.freedesktop.org/series/26714/
State : success
== Summary ==
Series 26714v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/26714/revisions/
When doing a GPU reset, the CSB register will be trashed and we will
lose any context-switch notifications that happened since the tasklet
was disabled. If we find that all requests on this engine were
completed, we want to make sure that the ELSP tracker is similarly empty
so that we do not feed b
Regards
Shashank
On 6/30/2017 5:24 PM, Ville Syrjälä wrote:
On Wed, Jun 21, 2017 at 04:03:59PM +0530, Shashank Sharma wrote:
HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
For any other mode, the VIC filed in AVI infoframes should be 0.
HDMI 2.0 sinks, support vid
== Series Details ==
Series: drm/i915: Flush the execlist ports if idle
URL : https://patchwork.freedesktop.org/series/26731/
State : success
== Summary ==
Series 26731v1 drm/i915: Flush the execlist ports if idle
https://patchwork.freedesktop.org/api/1.0/series/26731/revisions/1/mbox/
Test g
Quoting Chris Wilson (2017-07-03 09:58:51)
> When doing a GPU reset, the CSB register will be trashed and we will
> lose any context-switch notifications that happened since the tasklet
> was disabled. If we find that all requests on this engine were
> completed, we want to make sure that the ELSP
On Mon, Jul 03, 2017 at 09:55:48AM +0200, Daniel Vetter wrote:
> On Fri, Jun 30, 2017 at 09:46:36PM +0300, Ville Syrjälä wrote:
> > On Fri, Jun 30, 2017 at 08:23:58PM +0200, Daniel Vetter wrote:
> > > On Fri, Jun 30, 2017 at 5:44 PM, Ville Syrjälä
> > > wrote:
> > > >> And if the GEM folks insist
Quoting Chris Wilson (2017-06-29 13:09:31)
> Quoting Chris Wilson (2017-06-28 12:18:44)
> > Quoting Chris Wilson (2017-06-22 17:02:11)
> > > Commit fabef825626d ("drm/i915: Drop struct_mutex around frontbuffer
> > > flushes") adds a dependency to ifbdev->vma when flushing the framebufer,
> > > but
On Mon, Jul 03, 2017 at 02:36:58PM +0530, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 6/30/2017 5:24 PM, Ville Syrjälä wrote:
> > On Wed, Jun 21, 2017 at 04:03:59PM +0530, Shashank Sharma wrote:
> >> HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
> >> For
Op 30-06-17 om 15:48 schreef Lionel Landwerlin:
> Hi Daniel,
>
> Any chance on getting this patch upstream?
Applied, thanks.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
When we unpin a fence, we do no other operation than mark it available.
This we can do outside of any locking by making the operation atomic.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gvt/aperture_gm.c| 2 +-
drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
drivers/gpu/drm/i915
Following the pattern now used for obj->mm.pages, use just pin_fence and
unpin_fence to control access to the fence registers. I.e. instead of
calling get_fence(); pin_fence(), we now just need to call pin_fence().
This will make it easier to reduce the locking requirements around
fence registers.
We probably want for the caller to specify whether the fence should be
pinned for their usage, but at the moment all callers do want the
associated fence, or none, so take it on their behalf.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_vma.c | 19 ++
Many years ago, long before requests, we tried doing this. We never
quite got it right, but now with requests we have the tracking to do the
job properly!
One of the stall points for gen2/gen3 is the use of fence registers for
GPU operations. There are only a few available, and currently if we
exh
When descending thru debugfs directory. Doing this tends to
takes forever. CRC pipe read tests for this are already
covered under kms_pipe_crc_basic.
v2: Be more verbose that the check is meant for the crtc control data
Signed-off-by: Abdiel Janulgue
Cc: arkadiusz.hi...@intel.com
---
tests/debu
Since we occasionally stuff an error pointer into obj->mm.pages for a
semi-permanent or even permanent failure, we have to be more careful and
not just test against NULL when deciding if the object has a complete
set of its concurrent pages.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i
We free objects in bulk after they wait for their RCU grace period.
Currently, we take struct_mutex and unbind all the objects. This can lead
to a long lock duration during which time those objects have their pages
unfreeable (i.e. the shrinker is prevented from reaping those pages). If
we only pro
Remove the struct_mutex requirement around dev_priv->mm.bound_list and
dev_priv->mm.unbound_list by giving it its own spinlock. This reduces
one more requirement for struct_mutex and in the process gives us
slightly more accurate unbound_list tracking, which should improve the
shrinker.
Signed-off
Op 30-06-17 om 15:56 schreef Daniel Vetter:
> On Wed, Jun 28, 2017 at 03:28:11PM +0200, Maarten Lankhorst wrote:
>> We want to change swap_state to wait indefinitely, but to do this
>> swap_state should wait interruptibly. This requires propagating
>> the error to each driver. All drivers have chan
== Series Details ==
Series: series starting with [1/4] drm/i915: Pin fence for iomap
URL : https://patchwork.freedesktop.org/series/26734/
State : success
== Summary ==
Series 26734v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/26734/revisions/1/mbox/
Test km
Thanks!
Minor typo "dsiplay", otherwise: Reviewed-by: Sinclair Yeh
On Mon, Jun 26, 2017 at 06:19:48PM +0200, Daniel Vetter wrote:
> Again stopping the vblank before uninstalling the irq handler is kinda
> the wrong way round, but the fb_off stuff should take care of
> disabling the dsiplay at l
Regards
Shashank
On 7/3/2017 3:27 PM, Ville Syrjälä wrote:
On Mon, Jul 03, 2017 at 02:36:58PM +0530, Sharma, Shashank wrote:
Regards
Shashank
On 6/30/2017 5:24 PM, Ville Syrjälä wrote:
On Wed, Jun 21, 2017 at 04:03:59PM +0530, Shashank Sharma wrote:
HDMI 1.4b support the CEA video modes
== Series Details ==
Series: series starting with [1/3] drm/i915: Refactor testing obj->mm.pages
URL : https://patchwork.freedesktop.org/series/26737/
State : success
== Summary ==
Series 26737v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/26737/revisions/1/mbo
Chris Wilson writes:
> As part of the knowing whether there is outstanding data in the CSB,
> also check whether there is an outstanding IRQ notification.
>
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> Cc: Tvrtko Ursulin
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_d
Remove drm_mode_config_fb, I don't see the point of it.
To make it clear that it's ok to use plane->fb directly,
move up drm_drv_uses_atomic_modeset so the code is skipped for atomic
drivers that require plane_state->fb.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_fb_helper.c | 22 +
Since most tests are already doing a reset, there is no need to
duplicate it at init time. This removes that duplicate reset and adds
a call to reset_state where in-test resets where not done previously.
Signed-off-by: Paul Kocialkowski
---
lib/igt_chamelium.c | 2 --
tests/chamelium.c | 6 +++
This adds support for configurable suspend/resume delay and takes the
occasion to move igtrc configuation from igt_chamelium to igt_core.
This way, suspend/resume delay configuration can be used for all tests.
Signed-off-by: Paul Kocialkowski
---
lib/Makefile.am | 2 ++
lib/igt_aux.c
This renames the reprobe_connector function to update_connector and
ensures that full reprobe of the connector is only done when really
necessary (e.g. when changing the EDID).
A full reprobe takes time and is not required for updating the connector
state. Thus, this allows executing tests faster.
When a CRC comparison error occurs, it is quite useful to get a dump
of both the frame obtained from the chamelium and the reference in order
to compare them.
This implements the frame dump, with a configurable path that enables
the use of this feature.
Signed-off-by: Paul Kocialkowski
---
lib/
The frame dump tests provide no additional functionality over CRC tests
and are considerably slower. Thus, these tests should be considered as
poorer duplicates and removed.
Signed-off-by: Paul Kocialkowski
---
tests/chamelium.c | 53 -
1 file
This introduces CRC calculation for reference frames, instead of using
hardcoded values for them. The rendering of reference frames may differ
from machine to machine, especially due to font rendering, and the
frame itself may change with subsequent IGT changes.
These differences would cause the C
This introduces a chamelium_write_frame_to_png function that saves a
Chamelium frame dump to a png file. This should be useful when a frame
comparison with a reference fails.
---
lib/igt_chamelium.c | 32
lib/igt_chamelium.h | 3 +++
2 files changed, 35 insertions
Op 30-06-17 om 15:56 schreef Daniel Vetter:
> On Wed, Jun 28, 2017 at 03:28:11PM +0200, Maarten Lankhorst wrote:
>> We want to change swap_state to wait indefinitely, but to do this
>> swap_state should wait interruptibly. This requires propagating
>> the error to each driver. All drivers have chan
== Series Details ==
Series: drm/fb-helper: Remove drm_mode_config_fb.
URL : https://patchwork.freedesktop.org/series/26740/
State : warning
== Summary ==
Series 26740v1 drm/fb-helper: Remove drm_mode_config_fb.
https://patchwork.freedesktop.org/api/1.0/series/26740/revisions/1/mbox/
Test gem
CEA-861-F introduces extended tag codes for EDID extension blocks,
which indicates the actual type of the data block. The code for
using exteded tag is 0x7, whereas in the existing code, the
corresponding macro is named as "VIDEO_CAPABILITY_BLOCK"
This patch renames the macro and usages from "VIDE
On Mon, Jun 26, 2017 at 04:40:08PM -0400, Lyude wrote:
> There's quite a number of machines on the market, mainly Lenovo
> ThinkPads, that make the horrible mistake in their firmware of reusing
> the PCIBAR space reserved for the SMBus for things that are completely
> unrelated to the SMBus control
On Mon, Jul 03, 2017 at 05:55:43PM +0530, Shashank Sharma wrote:
> CEA-861-F introduces extended tag codes for EDID extension blocks,
> which indicates the actual type of the data block. The code for
> using exteded tag is 0x7, whereas in the existing code, the
> corresponding macro is named as "VI
== Series Details ==
Series: drm/edid: rename macro for CEA extended-tag
URL : https://patchwork.freedesktop.org/series/26744/
State : failure
== Summary ==
Series 26744v1 drm/edid: rename macro for CEA extended-tag
https://patchwork.freedesktop.org/api/1.0/series/26744/revisions/1/mbox/
Test
Before we declare an engine as idle, check if there are any pending
execlist context-switches and if the ring itself reports as idle.
Otherwise, we may be left in a situation where we miss a crucial
execlist event (or something more sinister) yet the requests complete.
Since the seqno write happens
Including a check against the execlist queue before calling the engine
idle and passing hangcheck.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_engine_cs.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_e
After setting the WEDGED bit, make sure that we do wake up waiters as
they may not be waiting for a request completion yet, just for its
execution.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/d
== Series Details ==
Series: series starting with [1/3] drm/i915: Check execlist/ring status during
hangcheck
URL : https://patchwork.freedesktop.org/series/26747/
State : success
== Summary ==
Series 26747v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/26747/r
When the GPU is reset, we want to discard all pending notifications as
either we have manually completed them, or they are no longer
applicable. Make sure we do reset the engine->irq_posted prior to
re-enabling the engine (e.g. the interrupt tasklets) in
i915_gem_reset_finish_engine().
Signed-off-
On Sat, Jul 01, 2017 at 09:35:12AM +0530, Mahesh Kumar wrote:
> Hi,
>
>
> On Friday 30 June 2017 05:56 PM, Ville Syrjälä wrote:
> > On Fri, Jun 30, 2017 at 05:40:59PM +0530, Mahesh Kumar wrote:
> >> In Gen9 platform Interlaced fetch mode doesn't support following plane
> >> configuration:
> >>
When we wedge the device, we clear out the in-flight requests and
advance the breadcrumb to indicate they are complete. However, the
breadcrumb advance includes an assert that the engine is idle, so that
advancement needs to be the last step to ensure we pass our own sanity
checks.
Signed-off-by:
We are planning to use our own tmpfs mnt in i915 in place of the
shm_mnt, such that we can control the mount options, in particular
huge=, which we require to support huge-gtt-pages. So rather than roll
our own version of __shmem_file_setup, it would be preferred if we could
just give shmem our mnt
Not a fully blown gemfs, just our very own tmpfs kernel mount. Doing so
moves us away from the shmemfs shm_mnt, and gives us the much needed
flexibility to do things like set our own mount options, namely huge=
which should allow us to enable the use of transparent-huge-pages for
our shmem backed o
Enable transparent-huge-pages through gemfs by mounting with
huge=within_size.
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_gemfs.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gemfs.c
b/driver
We now try running all mockable selftests through the mock_device, and disable
vGPU huge gtt pages for now.
Matthew Auld (21):
mm/shmem: introduce shmem_file_setup_with_mnt
drm/i915: introduce simple gemfs
drm/i915/gemfs: enable THP
drm/i915: introduce page_size_mask to dev_info
drm/i915
Before we can enable 64K pages through the IPS bit, we must first enable
it through MMIO, otherwise the page-walker will simply ignore it.
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 11 +++
drivers/gpu/drm/i915/i915_reg.h | 3
Move the setting/clearing of the vma->pages to a vm operation. Doing so
neatens things up a little, but more importantly gives us a sane place
to also set/clear the vma->pages_sizes, which we introduce later in
preparation for supporting huge-pages.
Suggested-by: Chris Wilson
Signed-off-by: Matth
We can't mix 64K and 4K pte's in the same page-table, so for now we
align 64K objects to 2M to avoid any potential mixing. This is
potentially wasteful but in reality shouldn't be too bad since this only
applies to the virtual address space of a 48b PPGTT.
v2: don't separate logically connected op
When SW enables the use of 2M/1G pages, it must disable the GTT cache.
v2: don't disable for Cherryview which doesn't even support 48b PPGTT!
v3: explicitly check that the system does support 2M/1G pages
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
Cc: Chris Wilson
---
drivers/gpu/drm/i91
For the 48b PPGTT try to align the vma start address to the required
page size boundary to guarantee we use said page size in the gtt. If we
are dealing with multiple page sizes, we can't guarantee anything and
just align to the largest. For soft pinning and objects which need to be
tightly packed
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 8
drivers/gpu/drm/i915/i915_gem_gtt.h | 2 ++
2 files changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 861
In preparation for huge gtt pages expose a page_size_mask as part of the
device info, to indicate the page sizes supported by the HW. Currently
only 4K is supported.
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
Cc: Mika Kuoppala
Cc: Chris Wilson
Reviewed-by: Joonas Lahtinen
---
drivers/g
In preparation for supporting huge gtt pages for the ppgtt, we introduce
page size members for gem objects. We fill in the page sizes by
scanning the sg table.
v2: pass the sg_mask to set_pages
v3: calculate the sg_mask inline with populating the sg_table where
possible, and pass to set_pages al
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 26 ++
drivers/gpu/drm/i915/i915_gem_gtt.h | 1 +
2 files changed, 27 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_
Support inserting 1G gtt pages into the 48b PPGTT.
v2: sanity check sg->length against page_size
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 73 +++--
drivers/gpu/drm/i915/i915_gem_gtt.h | 2 +
2 f
Now that we support multiple page sizes for the ppgtt, it would be
useful to track the real usage for debugging purposes.
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_gtt.c| 10 ++
drivers/gpu/drm/i915/i915_gem_object.h | 10 +++
v2: mock test page support configurations and add MI_STORE_DWORD test
v3: run all mockable huge page tests on all platforms via the mock_device
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c| 1 +
drivers/gpu/drm/i915
Try to mix sg page sizes for 4K, 64K and 2M pages.
v2: s/BIT(x) >> 12/BIT(x) >> PAGE_SHIFT/
Suggested-by: Chris Wilson
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
Cc: Chris Wilson
---
drivers/gpu/drm/i915/selftests/scatterlist.c | 15 +++
1 file changed, 15 insertions(+)
dif
For gen9+ enable platform level support for 64K pages. Also enable for
mock testing.
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_pci.c | 3 ++-
drivers/gpu/drm/i915/selftests/mock_gem_device.c | 3 ++-
2 files changed, 4 inser
For gen8+ platforms which support the 48b PPGTT, enable platform level
support for 2M pages. Also enable for mock testing.
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_pci.c | 6 --
drivers/gpu/drm/i915/selftests/mock_gem_d
For gen8+ enable platforms which support the 48b PPGTT, enable support
for 1G pages. Also enable for mock testing.
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_pci.c | 6 --
drivers/gpu/drm/i915/selftests/mock_gem_device.c
Currently gvt gtt handling doesn't support huge page entries, so disable
for now.
Suggested-by: Zhenyu Wang
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
Cc: Chris Wilson
Cc: Zhenyu Wang
---
drivers/gpu/drm/i915/i915_gem.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/driver
Good to know, mostly for debugging purposes.
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c | 42 +
1 file changed, 38 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
CEA-861-F introduces extended tag codes for EDID extension blocks,
which indicates the actual type of the data block. The code for
using exteded tag is 0x7, whereas in the existing code, the
corresponding macro is named as "VIDEO_CAPABILITY_BLOCK"
This patch renames the macro and usages from "VIDE
== Series Details ==
Series: drm/i915: Clear engine irq posted following a reset
URL : https://patchwork.freedesktop.org/series/26752/
State : success
== Summary ==
Series 26752v1 drm/i915: Clear engine irq posted following a reset
https://patchwork.freedesktop.org/api/1.0/series/26752/revisio
On Fri, Jun 30, 2017 at 08:18:19PM +0200, Daniel Vetter wrote:
> On Fri, Jun 30, 2017 at 5:26 PM, Daniel Vetter wrote:
> > On Fri, Jun 30, 2017 at 05:18:41PM +0300, ville.syrj...@linux.intel.com
> > wrote:
> >> From: Ville Syrjälä
> >>
> >> Add drm_crtc_vblank_get_accurate() which is the same as
On Mon, Jul 03, 2017 at 07:53:44PM +0530, Shashank Sharma wrote:
> CEA-861-F introduces extended tag codes for EDID extension blocks,
> which indicates the actual type of the data block. The code for
> using exteded tag is 0x7, whereas in the existing code, the
> corresponding macro is named as "VI
== Series Details ==
Series: drm/i915: Clear execlist port[] before updating seqno on wedging
URL : https://patchwork.freedesktop.org/series/26753/
State : success
== Summary ==
Series 26753v1 drm/i915: Clear execlist port[] before updating seqno on wedging
https://patchwork.freedesktop.org/ap
Quoting Matthew Auld (2017-07-03 15:14:58)
> +static struct i915_vma *
> +gpu_write_dw(struct i915_vma *vma, u64 offset, u32 value)
> +{
> + struct drm_i915_private *i915 = to_i915(vma->obj->base.dev);
> + struct drm_i915_gem_object *obj;
> + struct i915_vma *batch;
> + unsi
== Series Details ==
Series: huge gtt pages (rev4)
URL : https://patchwork.freedesktop.org/series/25118/
State : success
== Summary ==
Series 25118v4 huge gtt pages
https://patchwork.freedesktop.org/api/1.0/series/25118/revisions/4/mbox/
Test gem_exec_suspend:
Subgroup basic-s4-device
On Mon, 2017-07-03 at 15:01 +0300, Paul Kocialkowski wrote:
> This adds support for configurable suspend/resume delay and takes the
> occasion to move igtrc configuation from igt_chamelium to igt_core.
> This way, suspend/resume delay configuration can be used for all tests.
>
> Signed-off-by: Pau
CEA-861-F introduces extended tag codes for EDID extension blocks,
which indicates the actual type of the data block. The code for
using exteded tag is 0x7, whereas in the existing code, the
corresponding macro is named as "VIDEO_CAPABILITY_BLOCK"
This patch renames the macro and usages from "VIDE
Please ignore this version, sent premature. Actual one on the way.
-Original Message-
From: Sharma, Shashank
Sent: Monday, July 3, 2017 8:39 PM
To: dri-de...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org
Cc: Sharma, Shashank ; Ville Syrjala
Subject: [PATCH v3] drm/edid: rename
CEA-861-F introduces extended tag codes for EDID extension blocks,
which indicates the actual type of the data block. The code for
using exteded tag is 0x7, whereas in the existing code, the
corresponding macro is named as "VIDEO_CAPABILITY_BLOCK"
This patch renames the macro and usages from "VIDE
== Series Details ==
Series: drm/edid: rename macro for CEA extended-tag (rev2)
URL : https://patchwork.freedesktop.org/series/26744/
State : success
== Summary ==
Series 26744v2 drm/edid: rename macro for CEA extended-tag
https://patchwork.freedesktop.org/api/1.0/series/26744/revisions/2/mbox
== Series Details ==
Series: drm/edid: rename macro for CEA extended-tag (rev5)
URL : https://patchwork.freedesktop.org/series/26744/
State : warning
== Summary ==
Series 26744v5 drm/edid: rename macro for CEA extended-tag
https://patchwork.freedesktop.org/api/1.0/series/26744/revisions/5/mbox
On Mon, Jul 03, 2017 at 08:41:53PM +0530, Shashank Sharma wrote:
> CEA-861-F introduces extended tag codes for EDID extension blocks,
> which indicates the actual type of the data block. The code for
> using exteded tag is 0x7, whereas in the existing code, the
> corresponding macro is named as "VI
Hi,
On Monday 03 July 2017 07:32 PM, Ville Syrjälä wrote:
On Sat, Jul 01, 2017 at 09:35:12AM +0530, Mahesh Kumar wrote:
Hi,
On Friday 30 June 2017 05:56 PM, Ville Syrjälä wrote:
On Fri, Jun 30, 2017 at 05:40:59PM +0530, Mahesh Kumar wrote:
In Gen9 platform Interlaced fetch mode doesn't sup
We try to fixup the context image after the reset to ensure that there
are no more pending writes from the hw that may conflict and to fixup
any that were in flight.
Fixes: a1ef70e14453 ("drm/i915: Add support for per engine reset recovery")
Signed-off-by: Chris Wilson
Cc: Michel Thierry
Cc: Tvr
We rely on disabling the execlists (by stopping the tasklet) to prevent
new requests from submitting to the engine ELSP before we are ready.
However, we re-enable the engine before we call init_hw which gives
userspace the opportunity to subit a new request which is then
overwritten by init_hw -- b
As part of the knowing whether there is outstanding data in the CSB,
also check whether there is an outstanding IRQ notification.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Tvrtko Ursulin
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_debugfs.c | 6 --
1 file changed, 4 i
Regards
Shashank
On 7/3/2017 9:14 PM, David Weinehall wrote:
On Mon, Jul 03, 2017 at 08:41:53PM +0530, Shashank Sharma wrote:
CEA-861-F introduces extended tag codes for EDID extension blocks,
which indicates the actual type of the data block. The code for
using exteded tag is 0x7, whereas in
== Series Details ==
Series: series starting with [1/3] drm/i915: Report execlists irq bit in debugfs
URL : https://patchwork.freedesktop.org/series/26763/
State : success
== Summary ==
Series 26763v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/26763/revisions/
On Mon, Jul 03, 2017 at 09:44:50AM +0100, Liviu Dudau wrote:
> On Fri, Jun 30, 2017 at 08:13:58PM +0200, Daniel Vetter wrote:
> > On Fri, Jun 30, 2017 at 6:51 PM, Liviu Dudau wrote:
> > > Prior to commit b0aa06e9a7fd ("drm/fb-helper: Support deferred setup"),
> > > if no output is connected at fra
On Mon, Jul 03, 2017 at 01:01:55PM +0200, Maarten Lankhorst wrote:
> Op 30-06-17 om 15:56 schreef Daniel Vetter:
> > On Wed, Jun 28, 2017 at 03:28:11PM +0200, Maarten Lankhorst wrote:
> >> We want to change swap_state to wait indefinitely, but to do this
> >> swap_state should wait interruptibly. T
== Series Details ==
Series: Handle unsupported configuration with IF-ID (rev3)
URL : https://patchwork.freedesktop.org/series/26546/
State : success
== Summary ==
Series 26546v3 Handle unsupported configuration with IF-ID
https://patchwork.freedesktop.org/api/1.0/series/26546/revisions/3/mbox
On Mon, Jul 03, 2017 at 09:16:54AM +0100, Chris Wilson wrote:
> Quoting Daniel Vetter (2017-07-03 09:03:36)
> > On Fri, Jun 30, 2017 at 5:39 PM, Chris Wilson
> > wrote:
> > >> Yeah, but my point is that this here is an extremely fancy and fragile
> > >> (and afaics in this form, incomplete) fix f
On Mon, Jul 03, 2017 at 05:26:24PM +0300, Ville Syrjälä wrote:
> On Fri, Jun 30, 2017 at 08:18:19PM +0200, Daniel Vetter wrote:
> > On Fri, Jun 30, 2017 at 5:26 PM, Daniel Vetter wrote:
> > > On Fri, Jun 30, 2017 at 05:18:41PM +0300, ville.syrj...@linux.intel.com
> > > wrote:
> > >> From: Ville S
On Mon, Jul 03, 2017 at 12:30:48PM +0300, Ville Syrjälä wrote:
> I've pretty much decided that I'll be happy if I can solve this for
> future kernels. If someone else wants to try and cook up some kind
> of simple regression fix I don't have any real objections.
Imo fixing the regression isn't the
1 - 100 of 111 matches
Mail list logo
