From: Stanislav Lisovskiy
Added encoding of drm content_type property from drm_connector_state
within AVI infoframe in order to properly handle external HDMI TV
content-type setting.
This requires also manipulationg ITC bit, as stated in
HDMI spec.
v2:
* Moved helper function which attaches co
From: Stanislav Lisovskiy
Added content_type property to drm_connector_state
in order to properly handle external HDMI TV content-type setting.
v2:
* Moved helper function which attaches content type property
to the drm core, as was suggested.
Removed redundant connector state initializat
From: Stanislav Lisovskiy
Added content type setting property to drm_connector(part 1)
and enabled transmitting it with HDMI AVI infoframes
for i915(part 2).
Stanislav Lisovskiy (2):
drm: content-type property for HDMI connector
i915: content-type property for HDMI connector
Documentation/
== Series Details ==
Series: Enabling content-type setting for HDMI displays. (rev6)
URL : https://patchwork.freedesktop.org/series/41876/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
f891f01659af drm: content-type property for HDMI connector
-:127: CHECK:LINE_SPACING: Please
On Saturday 21 April 2018 09:30 AM, Nagaraju, Vathsala wrote:
-Original Message-
From: Vivi, Rodrigo
Sent: Friday, April 20, 2018 11:06 PM
To: Nagaraju, Vathsala
Cc: intel-gfx@lists.freedesktop.org; Pandiyan, Dhinakaran
Subject: Re: [PATCH] drm/i915/psr : Add psr1 live status
On Fri,
== Series Details ==
Series: Enabling content-type setting for HDMI displays. (rev6)
URL : https://patchwork.freedesktop.org/series/41876/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4075 -> Patchwork_8770 =
== Summary - SUCCESS ==
No regressions found.
External URL
The following changes since commit fadec6eefe232696c5c471b40df33e6db616e854:
drm/i915: Update DRIVER_DATE to 20180413 (2018-04-13 12:20:58 +0300)
are available in the git repository at:
https://github.com/intel/gvt-linux.git tags/gvt-next-2018-04-23
for you to fetch changes up to 3eda0d22e
Hi Jani:
I picked out the patch which causes conflicts and may put it back in the
next back merge from drm-intel-next to gvt-next. So there shouldn't be
any conflict in this pull. Thanks for your efforts.
Thanks,
Zhi.
On 04/23/18 16:11, Zhi Wang wrote:
The following changes since commit
fad
Quoting Daniel Vetter (2018-04-20 09:51:57)
> Control nodes are no more!
>
> Signed-off-by: Daniel Vetter
> Cc: Jani Nikula
> Cc: Joonas Lahtinen
> Cc: Rodrigo Vivi
> Cc: intel-gfx@lists.freedesktop.org
Reviewed-by: Joonas Lahtinen
Regards, Joonas
___
Hi Adam,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on v4.17-rc2 next-20180423]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day
On 20/04/2018 14:20, Chris Wilson wrote:
In the next patch, rings are the central timeline as requests may jump
between engines. Therefore in the future as we retire in order along the
engine timeline, we may retire out-of-order within a ring (as the ring now
occurs along multiple engines), lead
Quoting Tvrtko Ursulin (2018-04-23 09:47:57)
>
> On 20/04/2018 14:20, Chris Wilson wrote:
> > void i915_retire_requests(struct drm_i915_private *i915)
> > {
> > - struct intel_engine_cs *engine;
> > - enum intel_engine_id id;
> > + struct intel_ring *ring, *next;
> >
> > l
On 2018/4/21 17:51, YueHaibing wrote:
Remove boilerplate code by using macro module_pci_driver.
Signed-off-by: YueHaibing
Thanks Haibing,
Reviewed-by: Xinliang Liu
Xinliang
---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 13 +
1 file changed, 1 insertion(+), 12 dele
Remove boilerplate code by using macro module_pci_driver.
Signed-off-by: YueHaibing
---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 13 +
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
b/drivers/gpu/drm/hisilicon/h
== Series Details ==
Series: Enabling content-type setting for HDMI displays. (rev6)
URL : https://patchwork.freedesktop.org/series/41876/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4075_full -> Patchwork_8770_full =
== Summary - WARNING ==
Minor unknown changes comin
From: Tvrtko Ursulin
Remaining unreviewed (and one almost reviewed) patches to fix known outstanding
issues in trace.pl and improve its request split mode.
This will be useful for Virtual Engine development which is currently ongoing.
Tvrtko Ursulin (4):
trace.pl: Add support for colouring co
From: Tvrtko Ursulin
Add the command line switch which uses different colours for different
context execution boxes.
v2:
* Use HSL to simplify color generation. (Lionel)
* Colour other boxes in the same colour but different shade so it is
easier to follow the timeline.
Signed-off-by: Tvrtk
From: Tvrtko Ursulin
In split mode all requests have to be added up since they were previously
re-arranged so there is no overlap.
Signed-off-by: Tvrtko Ursulin
Cc: John Harrison
---
scripts/trace.pl | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/scripts/trace.pl b/scri
From: Tvrtko Ursulin
Incomplete requests (no notify, no context complete) have to be corrected
by looking at the engine timeline, and not the sorted-by-start-time view
as was previously used.
Per-engine timelines are generated on demand and cached for later use.
v2: Find end of current context
From: Tvrtko Ursulin
Request split mode had several bugs, both in the original version and also
after the recent refactorings.
One big one was that it wasn't considering different submit ports as a
reason to split execution, and also that it was too time based instead of
looking at relevant time
On Mon, Apr 23, 2018 at 10:43:47AM +0530, Nautiyal, Ankit K wrote:
>
>
> On 4/20/2018 7:37 PM, Ville Syrjälä wrote:
> > On Fri, Apr 20, 2018 at 07:01:46PM +0530, Nautiyal, Ankit K wrote:
> >> From: Ankit Nautiyal
> >>
> >> To enable aspect-ratio support in DRM, blindly exposing the aspect
> >> r
On Mon, Apr 23, 2018 at 10:55:54AM +0530, Nautiyal, Ankit K wrote:
>
>
> On 4/20/2018 7:42 PM, Ville Syrjälä wrote:
> > On Fri, Apr 20, 2018 at 07:01:47PM +0530, Nautiyal, Ankit K wrote:
> >> From: Ankit Nautiyal
> >>
> >> This patch adds helper functions for determining if aspect-ratio is
> >>
In commit 9b6586ae9f6b ("drm/i915: Keep a global seqno per-engine"), we
moved from a global inflight counter to per-engine counters in the
hope that will be easy to run concurrently in future. However, with the
advent of the desire to move requests between engines, we do need a
global counter to pr
In the next patch, rings are the central timeline as requests may jump
between engines. Therefore in the future as we retire in order along the
engine timeline, we may retire out-of-order within a ring (as the ring now
occurs along multiple engines), leading to much hilarity in miscomputing
the pos
When userspace is passing around swapbuffers using DRI, we frequently
have to open and close the same object in the foreign address space.
This shows itself as the same object being rebound at roughly 30fps
(with a second object also being rebound at 30fps), which involves us
having to rewrite the
We need to move to a more flexible timeline that doesn't assume one
fence context per engine, and so allow for a single timeline to be used
across a combination of engines. This means that preallocating a fence
context per engine is now a hindrance, and so we want to introduce the
singular timeline
We don't need to track every ring for its lifetime as they are managed
by the contexts/engines. What we do want to track are the live rings so
that we can sporadically clean up requests if userspace falls behind. We
can simply restrict the gt->rings list to being only gt->live_rings.
Suggested-by:
In the future, we want to move a request between engines. To achieve
this, we first realise that we have two timelines in effect here. The
first runs through the GTT is required for ordering vma access, which is
tracked currently by engine. The second is implied by sequential
execution of commands
On 23/04/2018 10:06, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-04-23 09:47:57)
On 20/04/2018 14:20, Chris Wilson wrote:
void i915_retire_requests(struct drm_i915_private *i915)
{
- struct intel_engine_cs *engine;
- enum intel_engine_id id;
+ struct intel_ring *ring,
On Mon, Apr 23, 2018 at 11:19:08AM +0530, Nautiyal, Ankit K wrote:
>
>
> On 4/20/2018 7:52 PM, Ville Syrjälä wrote:
> > On Fri, Apr 20, 2018 at 07:01:49PM +0530, Nautiyal, Ankit K wrote:
> >> From: Ankit Nautiyal
> >>
> >> We parse the EDID and add all the modes in the connector's modelist.
> >>
On Mon, 23 Apr 2018, "Nautiyal, Ankit K" wrote:
> On 4/20/2018 7:42 PM, Ville Syrjälä wrote:
>> On Fri, Apr 20, 2018 at 07:01:47PM +0530, Nautiyal, Ankit K wrote:
>>> From: Ankit Nautiyal
>>> +bool
>>> +drm_mode_aspect_ratio_allowed(const struct drm_file *file_priv,
>>> +
On 23/04/2018 11:13, Chris Wilson wrote:
In the next patch, rings are the central timeline as requests may jump
between engines. Therefore in the future as we retire in order along the
engine timeline, we may retire out-of-order within a ring (as the ring now
occurs along multiple engines), lead
On Mon, 23 Apr 2018, Zhi Wang wrote:
> Hi Jani:
>
> I picked out the patch which causes conflicts and may put it back in the
> next back merge from drm-intel-next to gvt-next. So there shouldn't be
> any conflict in this pull. Thanks for your efforts.
Thanks, pulled to drm-intel-next-queued.
J
On 23/04/2018 11:13, Chris Wilson wrote:
We don't need to track every ring for its lifetime as they are managed
by the contexts/engines. What we do want to track are the live rings so
that we can sporadically clean up requests if userspace falls behind. We
can simply restrict the gt->rings list
Quoting Tvrtko Ursulin (2018-04-23 11:25:54)
>
> On 23/04/2018 11:13, Chris Wilson wrote:
> > We don't need to track every ring for its lifetime as they are managed
> > by the contexts/engines. What we do want to track are the live rings so
> > that we can sporadically clean up requests if userspa
On 23/04/2018 11:13, Chris Wilson wrote:
In the future, we want to move a request between engines. To achieve
this, we first realise that we have two timelines in effect here. The
first runs through the GTT is required for ordering vma access, which is
tracked currently by engine. The second is
The rounding can cause a perfectly normal 16x16 src to full-screen
dst to be rounded down, even without clipping involved. Because of
this we should just remove the adjustment, as no other driver or plane
does it.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_sprite.c | 5 -
On 23/04/2018 11:36, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-04-23 11:25:54)
On 23/04/2018 11:13, Chris Wilson wrote:
We don't need to track every ring for its lifetime as they are managed
by the contexts/engines. What we do want to track are the live rings so
that we can sporadicall
We use jiffies to determine when wait expires. However
Imre did find out that jiffies can and will do a >1
increments on certain situations [1]. When this happens
in a wait_for loop, we return timeout errorneously
much earlier than what the real wallclock would say.
We can't afford our waits to ti
We need to be careful to not let compiler evaluate
the expiration and the operation on it's terms.
Document and enforce that COND will be evaluated
before checking timeout expiration.
Suggested-by: Chris Wilson
Cc: Chris Wilson
Signed-off-by: Mika Kuoppala
Reviewed-by: Chris Wilson
---
drive
Ping?
>Понедельник, 9 апреля 2018, 15:26 +03:00 от Tvrtko Ursulin
>:
>
>
>[Adding some people to Cc for more ack/nack type feedback.]
>
>Executive question is ack or nack on replacing intel_gpu_top with a new
>implementation which uses only perf PMU for counter gathering.
>
>A short history on
On 23/04/2018 11:13, Chris Wilson wrote:
We need to move to a more flexible timeline that doesn't assume one
fence context per engine, and so allow for a single timeline to be used
across a combination of engines. This means that preallocating a fence
context per engine is now a hindrance, and s
Quoting Tvrtko Ursulin (2018-04-23 11:44:19)
>
> On 23/04/2018 11:13, Chris Wilson wrote:
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c
> > b/drivers/gpu/drm/i915/i915_gem.c
> > index 0097a77fae8d..1635975dbc16 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i91
Quoting Tvrtko Ursulin (2018-04-23 13:33:04)
>
> On 23/04/2018 11:13, Chris Wilson wrote:
> > We need to move to a more flexible timeline that doesn't assume one
> > fence context per engine, and so allow for a single timeline to be used
> > across a combination of engines. This means that preallo
Chris Wilson writes:
> Instead of synchronously cancelling the timer and re-enabling it inside
> the reset callbacks, keep the timer enabled and let it die on its next
> wakeup if no longer required. This allows
> intel_engine_reset_breadcrumbs() to be used from an atomic
> (timer/softirq) contex
On 23/04/2018 11:14, Chris Wilson wrote:
When userspace is passing around swapbuffers using DRI, we frequently
have to open and close the same object in the foreign address space.
This shows itself as the same object being rebound at roughly 30fps
(with a second object also being rebound at 30fp
== Series Details ==
Series: drm/hisilicon/hibmc: Using module_pci_driver.
URL : https://patchwork.freedesktop.org/series/42103/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4078 -> Patchwork_8771 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https:/
== Series Details ==
Series: series starting with [1/6] drm/i915: Stop tracking
timeline->inflight_seqnos
URL : https://patchwork.freedesktop.org/series/42111/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
cdd8eb08a9de drm/i915: Stop tracking timeline->inflight_seqnos
-:14: ER
== Series Details ==
Series: series starting with [1/6] drm/i915: Stop tracking
timeline->inflight_seqnos
URL : https://patchwork.freedesktop.org/series/42111/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm/i915: Stop tracking timeline->inflight_seqnos
-O:drivers/gpu/dr
== Series Details ==
Series: series starting with [1/6] drm/i915: Stop tracking
timeline->inflight_seqnos
URL : https://patchwork.freedesktop.org/series/42111/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4078 -> Patchwork_8772 =
== Summary - FAILURE ==
Serious unknown
In the existing ABI, each engine operates its own timeline
(fence.context) and so should execute independently of any other. If we
install a blocker on all other engines, that should not affect execution
on the local engine.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
tests/gem_exec_sche
Ping
From: Intel-gfx [intel-gfx-boun...@lists.freedesktop.org] on behalf of StanLis
[stanislav.lisovs...@intel.com]
Sent: Monday, April 23, 2018 10:34 AM
To: dri-de...@lists.freedesktop.org
Cc: intel-gfx@lists.freedesktop.org
Subject: [Intel-gfx] [PATCH v7
Quoting Patchwork (2018-04-23 14:40:51)
> igt@core_auth@basic-auth:
> fi-glk-j4005: PASS -> INCOMPLETE (k.org#198133, fdo#103359)
> fi-bdw-gvtdvm: PASS -> INCOMPLETE (fdo#105600)
> fi-bxt-dsi: PASS -> INCOMPLETE (fdo#103927)
> fi-cnl-psr: PASS
Acked-by: Stanislav Lisovskiy
Best Regards,
Lisovskiy Stanislav
Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo>
From: Ville Syrjala [ville.syrj...@linux.intel.com]
Sent: Friday, March 16, 2018 9:04 PM
To: dri-de...@lists.f
On Fri, 20 Apr 2018, Paul Menzel wrote:
> Dear Jose,
>
>
> On 04/19/18 01:41, Souza, Jose wrote:
>> If the initial fbdev configuration(intel_fbdev_initial_config()) runs and
>
> Nit: Space before (.
>
>> there still no sink connected it will cause
>> drm_fb_helper_initial_config() to return 0 as n
== Series Details ==
Series: drm/i915: Remove src adjustment in intel_check_sprite_plane.
URL : https://patchwork.freedesktop.org/series/42113/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4078 -> Patchwork_8773 =
== Summary - SUCCESS ==
No regressions found.
Externa
== Series Details ==
Series: series starting with [CI,1/2] drm/i915: Use ktime on wait_for
URL : https://patchwork.freedesktop.org/series/42115/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4078 -> Patchwork_8774 =
== Summary - SUCCESS ==
No regressions found.
Extern
== Series Details ==
Series: drm: Don't pass the index to drm_property_add_enum() (rev2)
URL : https://patchwork.freedesktop.org/series/40122/
State : failure
== Summary ==
Applying: drm: Don't pass the index to drm_property_add_enum()
error: patch failed: drivers/gpu/drm/drm_connector.c:1069
On Mon, Apr 23, 2018 at 12:49:22PM +0200, Maarten Lankhorst wrote:
> The rounding can cause a perfectly normal 16x16 src to full-screen
> dst to be rounded down, even without clipping involved. Because of
> this we should just remove the adjustment, as no other driver or plane
> does it.
>
> Signe
Op 23-04-18 om 16:30 schreef Ville Syrjälä:
> On Mon, Apr 23, 2018 at 12:49:22PM +0200, Maarten Lankhorst wrote:
>> The rounding can cause a perfectly normal 16x16 src to full-screen
>> dst to be rounded down, even without clipping involved. Because of
>> this we should just remove the adjustment,
Quoting Mika Kuoppala (2018-04-23 14:03:02)
> Chris Wilson writes:
> > @@ -148,6 +149,12 @@ static void intel_breadcrumbs_fake_irq(struct
> > timer_list *t)
> > if (!b->irq_armed)
> > return;
> >
> > + /* If the user has disabled the fake-irq, restore the hangchecking */
On Mon, Apr 23, 2018 at 04:39:54PM +0200, Maarten Lankhorst wrote:
> Op 23-04-18 om 16:30 schreef Ville Syrjälä:
> > On Mon, Apr 23, 2018 at 12:49:22PM +0200, Maarten Lankhorst wrote:
> >> The rounding can cause a perfectly normal 16x16 src to full-screen
> >> dst to be rounded down, even without c
On Mon, Apr 23, 2018 at 4:37 AM, Mika Kuoppala
wrote:
> We use jiffies to determine when wait expires. However
> Imre did find out that jiffies can and will do a >1
> increments on certain situations [1]. When this happens
> in a wait_for loop, we return timeout errorneously
> much earlier than wh
On 23/04/18 06:43, Chris Wilson wrote:
In the existing ABI, each engine operates its own timeline
(fence.context) and so should execute independently of any other. If we
install a blocker on all other engines, that should not affect execution
on the local engine.
Signed-off-by: Chris Wilson
C
Quoting Antonio Argenziano (2018-04-23 16:37:17)
>
>
> On 23/04/18 06:43, Chris Wilson wrote:
> > In the existing ABI, each engine operates its own timeline
> > (fence.context) and so should execute independently of any other. If we
> > install a blocker on all other engines, that should not affe
On 23/04/18 08:51, Chris Wilson wrote:
Quoting Antonio Argenziano (2018-04-23 16:37:17)
On 23/04/18 06:43, Chris Wilson wrote:
In the existing ABI, each engine operates its own timeline
(fence.context) and so should execute independently of any other. If we
install a blocker on all other en
Thanks! :)
On 04/23/18 18:25, Jani Nikula wrote:
On Mon, 23 Apr 2018, Zhi Wang wrote:
Hi Jani:
I picked out the patch which causes conflicts and may put it back in the
next back merge from drm-intel-next to gvt-next. So there shouldn't be
any conflict in this pull. Thanks for your efforts.
This warning just started appearing during boot on a machine I upgraded
to 4.17-rc2. The warning seems to have been there since 2015, but it
has never triggered before today.
Dave
[1.158500] fb: switching to inteldrmfb from EFI VGA
[1.159073] Console: switching to colour dummy de
L3Bank could be fused off in hardware for debug purpose, and it
is possible that subslice is enabled while its corresponding L3Bank pairs
are disabled. In such case, if MCR packet control register(0xFDC) is
programed to point to a disabled bank pair, a MMIO read into L3Bank range
will return 0 inst
On 23/04/2018 14:43, Chris Wilson wrote:
In the existing ABI, each engine operates its own timeline
(fence.context) and so should execute independently of any other. If we
install a blocker on all other engines, that should not affect execution
on the local engine.
Signed-off-by: Chris Wilson
Quoting Tvrtko Ursulin (2018-04-23 17:52:54)
>
> On 23/04/2018 14:43, Chris Wilson wrote:
> > In the existing ABI, each engine operates its own timeline
> > (fence.context) and so should execute independently of any other. If we
> > install a blocker on all other engines, that should not affect ex
When userspace is passing around swapbuffers using DRI, we frequently
have to open and close the same object in the foreign address space.
This shows itself as the same object being rebound at roughly 30fps
(with a second object also being rebound at 30fps), which involves us
having to rewrite the
We don't need to track every ring for its lifetime as they are managed
by the contexts/engines. What we do want to track are the live rings so
that we can sporadically clean up requests if userspace falls behind. We
can simply restrict the gt->rings list to being only gt->live_rings.
v2: s/live/ac
We need to move to a more flexible timeline that doesn't assume one
fence context per engine, and so allow for a single timeline to be used
across a combination of engines. This means that preallocating a fence
context per engine is now a hindrance, and so we want to introduce the
singular timeline
In the next patch, rings are the central timeline as requests may jump
between engines. Therefore in the future as we retire in order along the
engine timeline, we may retire out-of-order within a ring (as the ring now
occurs along multiple engines), leading to much hilarity in miscomputing
the pos
In commit 9b6586ae9f6b ("drm/i915: Keep a global seqno per-engine"), we
moved from a global inflight counter to per-engine counters in the
hope that will be easy to run concurrently in future. However, with the
advent of the desire to move requests between engines, we do need a
global counter to pr
In the future, we want to move a request between engines. To achieve
this, we first realise that we have two timelines in effect here. The
first runs through the GTT is required for ordering vma access, which is
tracked currently by engine. The second is implied by sequential
execution of commands
== Series Details ==
Series: drm/hisilicon/hibmc: Using module_pci_driver.
URL : https://patchwork.freedesktop.org/series/42103/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4078_full -> Patchwork_8771_full =
== Summary - WARNING ==
Minor unknown changes coming with Pat
== Series Details ==
Series: drm/i915: Remove src adjustment in intel_check_sprite_plane.
URL : https://patchwork.freedesktop.org/series/42113/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4078_full -> Patchwork_8773_full =
== Summary - WARNING ==
Minor unknown changes
== Series Details ==
Series: series starting with [v2,1/6] drm/i915: Stop tracking
timeline->inflight_seqnos
URL : https://patchwork.freedesktop.org/series/42139/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
b1a184759165 drm/i915: Stop tracking timeline->inflight_seqnos
-:17:
== Series Details ==
Series: series starting with [CI,1/2] drm/i915: Use ktime on wait_for
URL : https://patchwork.freedesktop.org/series/42115/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4078_full -> Patchwork_8774_full =
== Summary - WARNING ==
Minor unknown changes
== Series Details ==
Series: series starting with [v2,1/6] drm/i915: Stop tracking
timeline->inflight_seqnos
URL : https://patchwork.freedesktop.org/series/42139/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm/i915: Stop tracking timeline->inflight_seqnos
-O:drivers/gpu
== Series Details ==
Series: series starting with [v2,1/6] drm/i915: Stop tracking
timeline->inflight_seqnos
URL : https://patchwork.freedesktop.org/series/42139/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4079 -> Patchwork_8776 =
== Summary - FAILURE ==
Serious unkn
On Fri, 2018-04-20 at 14:15 +0300, Mika Kahola wrote:
> On Fri, 2018-04-20 at 11:22 +0300, Jani Nikula wrote:
> > On Fri, 20 Apr 2018, Mika Kahola wrote:
> > >
> > > On Thu, 2018-04-19 at 17:09 +0300, Jani Nikula wrote:
> > > >
> > > > On Wed, 18 Apr 2018, Mika Kahola wrote:
> > > > >
> > >
On Mon, Apr 23, 2018 at 12:21:39PM -0700, Dhinakaran Pandiyan wrote:
>
>
>
> On Fri, 2018-04-20 at 14:15 +0300, Mika Kahola wrote:
> > On Fri, 2018-04-20 at 11:22 +0300, Jani Nikula wrote:
> > > On Fri, 20 Apr 2018, Mika Kahola wrote:
> > > >
> > > > On Thu, 2018-04-19 at 17:09 +0300, Jani Nik
On Mon, Apr 23, 2018 at 09:12:46AM -0700, Yunwei Zhang wrote:
> L3Bank could be fused off in hardware for debug purpose, and it
> is possible that subslice is enabled while its corresponding L3Bank pairs
> are disabled. In such case, if MCR packet control register(0xFDC) is
> programed to point to
On Mon, 2018-04-23 at 12:34 -0700, Rodrigo Vivi wrote:
> On Mon, Apr 23, 2018 at 12:21:39PM -0700, Dhinakaran Pandiyan wrote:
> >
> >
> >
> > On Fri, 2018-04-20 at 14:15 +0300, Mika Kahola wrote:
> > > On Fri, 2018-04-20 at 11:22 +0300, Jani Nikula wrote:
> > > > On Fri, 20 Apr 2018, Mika Kah
On Mon, Apr 23, 2018 at 01:24:39PM -0700, Dhinakaran Pandiyan wrote:
>
>
>
> On Mon, 2018-04-23 at 12:34 -0700, Rodrigo Vivi wrote:
> > On Mon, Apr 23, 2018 at 12:21:39PM -0700, Dhinakaran Pandiyan wrote:
> > >
> > >
> > >
> > > On Fri, 2018-04-20 at 14:15 +0300, Mika Kahola wrote:
> > > > On
== Series Details ==
Series: series starting with [v2,1/6] drm/i915: Stop tracking
timeline->inflight_seqnos
URL : https://patchwork.freedesktop.org/series/42139/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
397f93096828 drm/i915: Stop tracking timeline->inflight_seqnos
-:17:
== Series Details ==
Series: series starting with [v2,1/6] drm/i915: Stop tracking
timeline->inflight_seqnos
URL : https://patchwork.freedesktop.org/series/42139/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm/i915: Stop tracking timeline->inflight_seqnos
-O:drivers/gpu
In the existing ABI, each engine operates its own timeline
(fence.context) and so should execute independently of any other. If we
install a blocker on all other engines, that should not affect execution
on the local engine.
v2: Move the requirements checks from the fixture to subtest so that
the
== Series Details ==
Series: series starting with [v2,1/6] drm/i915: Stop tracking
timeline->inflight_seqnos
URL : https://patchwork.freedesktop.org/series/42139/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4081 -> Patchwork_8777 =
== Summary - FAILURE ==
Serious unkn
Sorry, I added a debug patch when submitting to trybot and forgot to
remove that from my local branch. I will resubmit to a new series.
Yunwei
On 4/23/2018 12:55 PM, Rodrigo Vivi wrote:
On Mon, Apr 23, 2018 at 09:12:46AM -0700, Yunwei Zhang wrote:
L3Bank could be fused off in hardware for de
Hi
I have a secondary monitor connected via USB-C adapter to HDMI. It
can manage resolutions up to 2560x1440.
Most of the time, when the system is booted the resolution is detected
ok, but If I suspend the machine, or replug the screen, or alternate
to the text console, the resolution is "downgr
From: Matt Atwood
Adding a missing GT2 sku discovered off hardware.
Signed-off-by: Matt Atwood
---
include/drm/i915_pciids.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h
index 70f0c25..a58a548 100644
--- a/include/drm/i915_pciids.h
+
On 04/23/2018 03:01 PM, matthew.s.atw...@intel.com wrote:
From: Matt Atwood
Adding a missing GT2 sku discovered off hardware.
Signed-off-by: Matt Atwood
---
include/drm/i915_pciids.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h
From: Matt Atwood
Adding a missing GT2 sku discovered off hardware.
Signed-off-by: Matt Atwood
Reviewed-by: Clint Taylor
---
include/drm/i915_pciids.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h
index 70f0c25..bab70ff 100644
--- a/
== Series Details ==
Series: drm/i915/kbl: Add KBL GT2 sku
URL : https://patchwork.freedesktop.org/series/42144/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4081 -> Patchwork_8778 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patchwork.freed
== Series Details ==
Series: drm/i915/kbl: Add KBL GT2 sku (rev2)
URL : https://patchwork.freedesktop.org/series/42144/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4081 -> Patchwork_8779 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patchwor
On Mon, Apr 23, 2018 at 03:28:03PM -0700, matthew.s.atw...@intel.com wrote:
> From: Matt Atwood
>
> Adding a missing GT2 sku discovered off hardware.
>
> Signed-off-by: Matt Atwood
> Reviewed-by: Clint Taylor
pushed to dinq, thanks for patch and review.
> ---
> include/drm/i915_pciids.h | 1
1 - 100 of 120 matches
Mail list logo
