On Mon, Jul 24, 2017 at 05:54:46PM +0300, Paul Kocialkowski wrote:
> This adds a common drm helper to detect whether the EDID changed from
> the last known cached one. This is useful help detect that a monitor was
> changed during a suspend/resume cycle.
>
> When that happens (a monitor is replace
Hi Ben,
[auto build test ERROR on drm/drm-next]
[also build test ERROR on v4.13-rc2 next-20170724]
[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-ci/linux/commits/Ben-Widawsky/drm-Plumb-modifiers-through-plane
Hi Ben,
[auto build test WARNING on drm/drm-next]
[also build test WARNING on v4.13-rc2 next-20170724]
[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-ci/linux/commits/Ben-Widawsky/drm-Plumb-modifiers-through
On 2017.07.21 14:01:01 +0100, Lionel Landwerlin wrote:
> I think Chris' comments show this isn't actually tested.
It turned out that's true...so currently Pengyuan just tried to
filter by exposed vGPU ctx_hw_id with global mode in gputop. Would
that be ok with you? If yes, then we don't need i915
Hi Ben,
[auto build test WARNING on drm/drm-next]
[also build test WARNING on v4.13-rc2 next-20170724]
[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-ci/linux/commits/Ben-Widawsky/drm-Plumb-modifiers-through
On 17-07-19 10:34:14, Tvrtko Ursulin wrote:
Hi Ben,
On 18/07/2017 15:36, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Enables other i915 components to enable and disable
the facility as needed.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_engine_cs.c | 53 ++
On 17-07-18 15:36:11, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Without this I can get a null ptr deref when trying to access
our events with perf.
Signed-off-by: Tvrtko Ursulin
This definitely seems unsafe, but should be squashed in somewhere earlier...
---
drivers/gpu/drm/i915/i915_pmu
On 17-07-18 15:36:08, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
As elsewhere in the code we have to decouple the binary
engine identifiers for easier maintenance.
Also the sampler mask was incorrect in the timer callback.
I don't quite understand the point of this patch... can you perhaps
On 17-07-18 15:36:05, Tvrtko Ursulin wrote:
From: Chris Wilson
The first goal is to be able to measure GPU (and invidual ring) busyness
without having to poll registers from userspace. (Which not only incurs
holding the forcewake lock indefinitely, perturbing the system, but also
runs the risk
Hi Ben,
[auto build test ERROR on drm/drm-next]
[also build test ERROR on v4.13-rc2 next-20170724]
[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-ci/linux/commits/Ben-Widawsky/drm-Plumb-modifiers-through-plane
I saw a DP 1.3 panel that advertise AUX backlight brightness control
but not working properly. So it should work but not in real world.
I think that is good reason enough to add this as a heuristic.
On Thu, Jul 20, 2017 at 1:27 PM, Pandiyan, Dhinakaran
wrote:
>
>
>
> On Thu, 2017-07-20 at 10:06 +
On 7/21/2017 5:32 AM, Chris Wilson wrote:
During our selftests, we try reseting the GPU tens of thousands of
times, flooding the dmesg with out reset spam drowning out any potential
warnings. Add an option to i915_reset()/i915_reset_engine() to specify a
quiet reset for selftesting.
Signed-off-b
On 7/24/2017 6:32 AM, Chris Wilson wrote:
Quoting Chris Wilson (2017-07-21 13:32:33)
If the request has been completed before the reset took effect, we don't
need to mark it up as being a victim. Touching fence->error after the
fence has been signaled is detected by dma_fence_set_error() and
tri
Quoting Michel Thierry (2017-07-24 20:25:52)
> On 7/21/2017 5:32 AM, Chris Wilson wrote:
> > Extract the common barrier against rogue hangchecks from disrupting our
> > direct testing of resets, and in the process expand the lock to include
> > the per-engine reset shortcuts.
> >
> > Signed-off-by
On 7/21/2017 5:32 AM, Chris Wilson wrote:
Extract the common barrier against rogue hangchecks from disrupting our
direct testing of resets, and in the process expand the lock to include
the per-engine reset shortcuts.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Michel Thierry
I don't
On Mon, Jul 24, 2017 at 10:24:41AM +0200, Daniel Vetter wrote:
> On Mon, Jul 24, 2017 at 2:03 AM, Stephen Rothwell
> wrote:
> > Hi Daniel,
> >
> > On Fri, 21 Jul 2017 09:24:49 +0200 Daniel Vetter
> > wrote:
> >>
> >> How are we going to handle this now? The refactor is deeply burried in
> >> dr
DRM connector property is created to represent the content protection
state of the connector and to configure the same.
Content protection states defined:
DRM_MODE_CONTENT_PROTECTION_UNSUPPORTED - Unsupported
DRM_MODE_CONTENT_PROTECTION_DISABLE - Disabled
On 2017-07-24 10:54 AM, Paul Kocialkowski wrote:
> This adds a common drm helper to detect whether the EDID changed from
> the last known cached one. This is useful help detect that a monitor was
> changed during a suspend/resume cycle.
>
> When that happens (a monitor is replaced by another one d
On Mon, Jul 24, 2017 at 06:02:46PM +0300, Imre Deak wrote:
> On Mon, Jul 24, 2017 at 02:03:31PM +, Patchwork wrote:
> > == Series Details ==
> >
> > Series: YCBCR 4:2:0 handling in i915 layer (rev4)
> > URL : https://patchwork.freedesktop.org/series/27412/
> > State : success
> >
> > == Sum
== Series Details ==
Series: series starting with [1/2] drm/edid: Add helper to detect whether EDID
changed
URL : https://patchwork.freedesktop.org/series/27807/
State : warning
== Summary ==
Series 27807v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/27807/rev
On Mon, Jul 24, 2017 at 02:03:31PM +, Patchwork wrote:
> == Series Details ==
>
> Series: YCBCR 4:2:0 handling in i915 layer (rev4)
> URL : https://patchwork.freedesktop.org/series/27412/
> State : success
>
> == Summary ==
>
> Series 27412v4 YCBCR 4:2:0 handling in i915 layer
> https://pa
This adds a common drm helper to detect whether the EDID changed from
the last known cached one. This is useful help detect that a monitor was
changed during a suspend/resume cycle.
When that happens (a monitor is replaced by another one during suspend),
no hotplug event will be triggered so the c
This introduces a dedicated work and related helpers to detect whether
a monitor was replaced by another one during suspend. This detection is
based on EDID change detection, using the associated generic drm helper.
This requires storing more information to the intel_connector structure,
such as t
Quoting Chris Wilson (2016-08-03 20:38:53)
> In the next merge, we can build support for kcov at the individual file,
> or driver level. This is useful to filter out the noise when doing
> coverage test, i.e. we do get edges through code outside of i915.ko.
>
> Signed-off-by: Chris Wilson
> ---
>
Quoting Chris Wilson (2016-08-03 20:38:53)
> In the next merge, we can build support for kcov at the individual file,
Since a4691deabf28 ("kcov: allow more fine-grained coverage instrumentation"),
> or driver level. This is useful to filter out the noise when doing
> coverage test, i.e. we do get
== Series Details ==
Series: Add support for loadable OA configs
URL : https://patchwork.freedesktop.org/series/27803/
State : success
== Summary ==
Series 27803v1 Add support for loadable OA configs
https://patchwork.freedesktop.org/api/1.0/series/27803/revisions/1/mbox/
Test kms_cursor_lega
On Wed, Jul 12, 2017 at 08:17:00PM +0300, Imre Deak wrote:
> On Wed, Jul 12, 2017 at 04:17:08PM +, Patchwork wrote:
> > == Series Details ==
> >
> > Series: drm/i915: Unify the HSW/BDW and GEN9+ power well code (rev9)
> > URL : https://patchwork.freedesktop.org/series/26922/
> > State : fail
Oops. It caused some concerns from people running dim rebuild-tip.
Signed-off-by: Daniel Vetter
---
dim | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/dim b/dim
index dca73687b69e..1849a0d0e6ba 100755
--- a/dim
+++ b/dim
@@ -516,10 +516,9 @@ function commit_rerere_cache
The motivation behind this new interface is expose at runtime the
creation of new OA configs which can be used as part of the i915 perf
open interface. This will enable the kernel to learn new configs which
may be experimental, or otherwise not part of the core set currently
available through the i
We were reserving fewer dwords in the ring than necessary. Indeed
we're always writing all registers once, so discard the actual number
of registers given by the user and just program the whitelisted ones
once.
Fixes: 19f81df2859e ("drm/i915/perf: Add OA unit support for Gen 8+")
Reported-by: Matt
Hi,
Just a quick update, I forgot Chris' comment about renaming the
pointers fields in the uapi.
Cheers,
Lionel Landwerlin (3):
drm/i915/perf: fix flex eu registers programming
drm/i915/perf: prune OA configs
drm/i915: Implement I915_PERF_ADD/REMOVE_CONFIG interface
drivers/gpu/drm/i915/
== Series Details ==
Series: YCBCR 4:2:0 handling in i915 layer (rev4)
URL : https://patchwork.freedesktop.org/series/27412/
State : success
== Summary ==
Series 27412v4 YCBCR 4:2:0 handling in i915 layer
https://patchwork.freedesktop.org/api/1.0/series/27412/revisions/4/mbox/
Test gem_exec_f
To get HDMI YCBCR420 output, the PIPEMISC register should be
programmed to:
- Generate YCBCR output (bit 11)
- In case of YCBCR420 outputs, it should be programmed in full
blend mode to use the scaler in 5x3 ratio (bits 26 and 27)
This patch:
- Adds definition of these bits.
- Programs PIPEMISC
On Monday 24 July 2017 06:53 PM, Sean Paul wrote:
On Fri, Jul 21, 2017 at 9:02 AM, Ramalingam C wrote:
Sorry for late response.
On Friday 14 July 2017 07:25 PM, Sean Paul wrote:
On Fri, Jul 14, 2017 at 04:51:43PM +0530, Ramalingam C wrote:
DRM connector property is created to represent th
Quoting Chris Wilson (2017-07-21 13:32:33)
> If the request has been completed before the reset took effect, we don't
> need to mark it up as being a victim. Touching fence->error after the
> fence has been signaled is detected by dma_fence_set_error() and
> triggers a BUG:
>
> [ 231.743133] kern
On Fri, Jul 21, 2017 at 9:02 AM, Ramalingam C wrote:
> Sorry for late response.
>
>
> On Friday 14 July 2017 07:25 PM, Sean Paul wrote:
>
> On Fri, Jul 14, 2017 at 04:51:43PM +0530, Ramalingam C wrote:
>
> DRM connector property is created to represent the content protection
> state of the connect
On Mon, Jul 24, 2017 at 03:04:54PM +0530, Shashank Sharma wrote:
> To get HDMI YCBCR420 output, the PIPEMISC register should be
> programmed to:
> - Generate YCBCR output (bit 11)
> - In case of YCBCR420 outputs, it should be programmed in full
> blend mode to use the scaler in 5x3 ratio (bits 26
On Thu, Jul 20, 2017 at 05:11:52PM +0300, Paul Kocialkowski wrote:
> This adds missing entries for documentation generation, both for tests
> and the API reference.
>
> The list of tests is made complete and ordered alphabetically, with
> modified descriptions for consistency.
>
> More files are
== Series Details ==
Series: drm/i915: Disable GPU resets for 915g (earliest gen3 desktop)
URL : https://patchwork.freedesktop.org/series/27785/
State : success
== Summary ==
Series 27785v1 drm/i915: Disable GPU resets for 915g (earliest gen3 desktop)
https://patchwork.freedesktop.org/api/1.0/
The CI farm reports that trying to write to the PCI config (GDRST: 0xc0)
results in an immediate and silent reboot on Grantsdale (i915g). Until
that is resolved, stop killing the machine!
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101852
Fixes: 59ea90543f57 ("drm/i915: Implement GPU re
Reviewed-by: Lionel Landwerlin
On 24/07/17 10:14, Maarten Lankhorst wrote:
bdw_load_gamma_lut is writing beyond the array to the maximum value.
s/writing/reading/ ?
The intend of the function is to clamp values > 1 to 1, so write
s/intend/intent/
the intended color to the max register.
== Series Details ==
Series: YCBCR 4:2:0 handling in i915 layer (rev3)
URL : https://patchwork.freedesktop.org/series/27412/
State : success
== Summary ==
Series 27412v3 YCBCR 4:2:0 handling in i915 layer
https://patchwork.freedesktop.org/api/1.0/series/27412/revisions/3/mbox/
Test gem_exec_f
To get HDMI YCBCR420 output, the PIPEMISC register should be
programmed to:
- Generate YCBCR output (bit 11)
- In case of YCBCR420 outputs, it should be programmed in full
blend mode to use the scaler in 5x3 ratio (bits 26 and 27)
This patch:
- Adds definition of these bits.
- Programs PIPEMISC
== Series Details ==
Series: drm/i915: Fix out-of-bounds array access in bdw_load_gamma_lut
URL : https://patchwork.freedesktop.org/series/27783/
State : success
== Summary ==
Series 27783v1 drm/i915: Fix out-of-bounds array access in bdw_load_gamma_lut
https://patchwork.freedesktop.org/api/1.
Hello all,
I'm not too sure where to report this but I got an unusual output in dmesg
a couple of days ago and wanted to pass it on. Please let me know if I
need to submit a bug report too.
[ 4056.074906] Unclaimed read from register 0x1f0034
[ 4056.074990] [ cut here ]
[
On Mon, Jul 24, 2017 at 09:15:28AM +0100, Tvrtko Ursulin wrote:
>
> On 21/07/2017 16:45, Daniel Vetter wrote:
> > On Fri, Jul 21, 2017 at 12:56 PM, Tvrtko Ursulin
> > wrote:
> > >
> > > On 20/07/2017 17:23, Martin Peres wrote:
> > > >
> > > > Hi everyone,
> > > >
> > > > As some of you may alr
On Mon, Jul 24, 2017 at 09:21:39AM +0100, Tvrtko Ursulin wrote:
>
> On 21/07/2017 16:52, Daniel Vetter wrote:
> > On Fri, Jul 21, 2017 at 5:13 PM, Jani Nikula
> > wrote:
>
> [snip]
>
> > > I agree the goal should be to run all tests by default. And this means
> > > we should start being more cr
bdw_load_gamma_lut is writing beyond the array to the maximum value.
The intend of the function is to clamp values > 1 to 1, so write
the intended color to the max register.
This fixes the following KASAN warning:
[ 197.020857] [IGT] kms_pipe_color: executing
[ 197.063434] [IGT] kms_pipe_color:
On pe, 2017-07-21 at 15:50 +0100, Chris Wilson wrote:
> If we fail to acquire a fence (for old school fenced GPU access) then we
> unwind the vma reservation, including its pin. However, we were making
> the execobject as holding the pin before erring out, leading to a double
> unpin:
>
> [ 3193.9
On pe, 2017-07-21 at 15:50 +0100, Chris Wilson wrote:
> After we detect a i915_vma pin overflow, we call __i915_vma_unpin to
> cleanup. However, on an overflow the pin_count bitfield will be zero,
> triggering an assertion, even though we the intention is to merely warn
> and report the error back
On Mon, Jul 24, 2017 at 2:03 AM, Stephen Rothwell wrote:
> Hi Daniel,
>
> On Fri, 21 Jul 2017 09:24:49 +0200 Daniel Vetter
> wrote:
>>
>> How are we going to handle this now? The refactor is deeply burried in
>> drm-misc, I guess you could cherry-pick the relevant patches over. But
>> that'll pr
On 21/07/2017 16:52, Daniel Vetter wrote:
On Fri, Jul 21, 2017 at 5:13 PM, Jani Nikula
wrote:
[snip]
I agree the goal should be to run all tests by default. And this means
we should start being more critical of the tests we add.
For stress tests I would like to look more into splitting up
On 21/07/2017 16:45, Daniel Vetter wrote:
On Fri, Jul 21, 2017 at 12:56 PM, Tvrtko Ursulin
wrote:
On 20/07/2017 17:23, Martin Peres wrote:
Hi everyone,
As some of you may already know, we have made great strides in making our
CI system usable, especially in the last 6 months when everythin
On 21/07/2017 17:11, Chris Wilson wrote:
We require the caller to ensure that the packets they wish to emit into
the CS ring are qword aligned (i.e. have an even number of dwords).
Double check this.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i9
54 matches
Mail list logo
