On Thu, 20 Jul 2017, "Pandiyan, Dhinakaran"
wrote:
> On Thu, 2017-07-20 at 12:25 +0300, Jani Nikula wrote:
>> This reverts commit 560a758d39c616f83ac25ff6e0816a49ebe6401c.
>>
>> The DPCD backlight commits regress a Thinkpad X1 Carbon 4th Gen and a
>> BXT-P (in CI). Enabling dynamic backlight boo
Hi Greg&Hans,
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 probably lead to more conflicts because git will get confused.
Or you could just delete the set_busid hook in -staging, which renders
On Wed, 2017-07-19 at 16:50 +0300, Paul Kocialkowski wrote:
> Nowadays, many VGA connectors are not actually native VGA but use a
> discrete bridge to a digital connector. These bridges usually enforce
> their own EDID instead of the one supplied by the chamelium.
>
> Thus, the EDID read test for
On 20.07.2017 17:27, Maarten Lankhorst wrote:
> emon_crash should skip if the debugfs file could not be opened the first
> time, and debugfs_test.read_all_entries should skip files that could not
> be opened, instead of returning an error.
>
> This is because in a typical IGT run there may be mo
On to, 2017-07-20 at 14:48 +0100, Chris Wilson wrote:
> 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.7
On Thu, Jul 20, 2017 at 6:23 PM, 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 everything started
> clicking together.
>
> The CI team is no longer overwhelmed with fires and
On Fri, Jul 21, 2017 at 11:39 AM, Daniel Vetter wrote:
> On Thu, Jul 20, 2017 at 6:23 PM, 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 everything started
>> clicking
From: Tvrtko Ursulin
Proposal to add test tags as a replacement for separate test
list which can be difficult to maintain and get out of date.
Putting this maintanenace inline with tests makes it easier
to remember to update the (now implicit) lists, and also enables
richer test selection possib
Quoting Tvrtko Ursulin (2017-07-21 11:20:05)
> From: Tvrtko Ursulin
>
> Proposal to add test tags as a replacement for separate test
> list which can be difficult to maintain and get out of date.
>
> Putting this maintanenace inline with tests makes it easier
> to remember to update the (now imp
Just a small nit down there.
On 19/07/17 06:39, Zhenyu Wang wrote:
In order to support profiling for special context e.g vGPU context,
we can expose vGPU context hw id and enable i915 perf property to
get target context for profiling. This adds new perf property to
assign target context with hw
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 everything
started clicking together.
The CI team is no longer overwhelmed with fires and bug reports, so we
On Thu, Jul 06, 2017 at 05:40:30PM +0300, Imre Deak wrote:
> We check already for power wells that are unexpectedly on (or forced on)
> during power well disabling. Those checks also account for other
> power well requesters like KVMR or DEBUG. As such this check is
> redundant, let's remove it to
Quoting Zhenyu Wang (2017-07-19 06:39:48)
> +static struct i915_gem_context *
> +lookup_context_hw_id(struct drm_i915_private *dev_priv, unsigned int hw_id)
> +{
> + struct i915_gem_context *ctx;
> + int ret;
> +
> + ret = i915_mutex_lock_interruptible(&dev_priv->drm);
> + i
On 21/07/2017 11:36, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2017-07-21 11:20:05)
From: Tvrtko Ursulin
[snip]
--- a/tests/gem_concurrent_all.c
+++ b/tests/gem_concurrent_all.c
@@ -1492,47 +1492,47 @@ run_mode(const char *prefix,
igt_subtest_group {
On Thu, Jul 06, 2017 at 05:40:31PM +0300, Imre Deak wrote:
> Atm we enable/disable a power well only if it wasn't already
> enabled/disabled respectively. The only reason for this I can think of
> is to save the extra MMIO writes. Since the HW state matches the power
> well's usage counter most of
On Fri, Jul 21, 2017 at 02:14:33PM +0300, Arkadiusz Hiler wrote:
> On Thu, Jul 06, 2017 at 05:40:31PM +0300, Imre Deak wrote:
> > Atm we enable/disable a power well only if it wasn't already
> > enabled/disabled respectively. The only reason for this I can think of
> > is to save the extra MMIO wri
Quoting Tvrtko Ursulin (2017-07-21 12:08:00)
>
> On 21/07/2017 11:36, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2017-07-21 11:20:05)
> >> From: Tvrtko Ursulin
>
> [snip]
>
> >> --- a/tests/gem_concurrent_all.c
> >> +++ b/tests/gem_concurrent_all.c
> >> @@ -1492,47 +1492,47 @@ run_mode(con
On Thu, Jul 06, 2017 at 05:40:32PM +0300, Imre Deak wrote:
> Similarly to the GEN9 power well toggling, saving an occasional extra
> MMIO write is not worth the code complexity, let's simplify things.
>
> Signed-off-by: Imre Deak
Reviewed-by: Arkadiusz Hiler
_
On Fri, Jul 21, 2017 at 02:25:18PM +0300, Imre Deak wrote:
> On Fri, Jul 21, 2017 at 02:14:33PM +0300, Arkadiusz Hiler wrote:
> > On Thu, Jul 06, 2017 at 05:40:31PM +0300, Imre Deak wrote:
> > > Atm we enable/disable a power well only if it wasn't already
> > > enabled/disabled respectively. The on
On Thu, Jul 06, 2017 at 05:40:33PM +0300, Imre Deak wrote:
> We can reduce the code indentation by splitting the set helper to
> separate enable/disable helpers. This also allows us to unify the
> HSW/BDW and GEN9+ power well ops in follow-up patches, which introduces
> some differences between the
On 21/07/2017 12:27, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2017-07-21 12:08:00)
On 21/07/2017 11:36, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2017-07-21 11:20:05)
From: Tvrtko Ursulin
[snip]
--- a/tests/gem_concurrent_all.c
+++ b/tests/gem_concurrent_all.c
@@ -1492,47 +1492,47
On 21/07/17 14:27, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2017-07-21 12:08:00)
On 21/07/2017 11:36, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2017-07-21 11:20:05)
From: Tvrtko Ursulin
[snip]
--- a/tests/gem_concurrent_all.c
+++ b/tests/gem_concurrent_all.c
@@ -1492,47 +1492,47 @@
Hi,
On Thursday 20 July 2017 08:19 PM, Sharma, Shashank wrote:
Acked-by: Shashank Sharma
Regards
Shashank
On 7/20/2017 4:20 AM, Imre Deak wrote:
The scaler allocation code depends on a non-zero default value for the
crtc scaler_id, so make sure we initialize the scaler state accordingly
even
On 21/07/2017 13:02, Martin Peres wrote:
On 21/07/17 14:27, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2017-07-21 12:08:00)
On 21/07/2017 11:36, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2017-07-21 11:20:05)
From: Tvrtko Ursulin
[snip]
--- a/tests/gem_concurrent_all.c
+++ b/tests/ge
On 21/07/17 15:17, Tvrtko Ursulin wrote:
On 21/07/2017 13:02, Martin Peres wrote:
On 21/07/17 14:27, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2017-07-21 12:08:00)
On 21/07/2017 11:36, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2017-07-21 11:20:05)
From: Tvrtko Ursulin
[snip]
--- a
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
intel_engine_init_globa_seqno() may be called from an uncontrolled
set-wedged path where we have given up waiting for broken hw and declare
it defunct. Along that path, any sanity checks that the hw is idle
before we adjust its state will expectedly fail, so we simply cannot.
Instead of asserting i
We should only ever do nop_submit_request when the machine is wedged, so
assert it is so.
Signed-off-by: Chris Wilson
Reviewed-by: Michel Thierry
---
drivers/gpu/drm/i915/i915_gem.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_g
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:
Including a check against the execlist queue before calling the engine
idle and passing hangcheck.
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
---
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/
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-
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
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
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
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gem.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
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
We need to be able to reclaim from any process context, including the
shrinker. We can simulate being inside the shrinker using lockdep and
adjusting the task's reclaim state.
References: https://bugs.freedesktop.org/show_bug.cgi?id=101857
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/sel
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] kernel BUG at ./include/linux/dma-fence.h:434!
[ 231.74315
The purpose of the test was to check per-engine resets would fallback to
the global reset when required, but first we actually need a test for a
basic i915_handle_error()!
Cc: Mika Kuoppala
Cc: Michel Thierry
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/selftests/intel_hangcheck.c | 74
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
---
drivers/gpu/drm/i915/selftests/intel_hangcheck.c
If all goes well, resetting one engine should not affect the operation of
any others. So to test this, we setup a continuous stream of requests
onto to each of the "innocent" engines whilst constantly resetting our
target engine.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Michel Thierry
Although a banned context will be told to -EIO off if they try to submit
more requests, we have a discrepancy between whole device resets and
per-engine resets where we report the GPU reset but not the engine
resets. This leaves a bit of mystery as to why the context was banned,
and also reduces aw
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-by: Chris Wilson
---
drivers/gpu/drm/i915/i
Triggering a GPU reset for one engine affects another, notably
corrupting the context status buffer (CSB) effectively losing track of
inflight requests.
Adding a few printks:
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index ad41836fa5e5..a969456bc0fa 100644
---
Since we make call i915_gem_context_mark_guilty() concurrently when
resetting different engines in parallel, we need to make sure that our
updates are safe for the unlocked access.
Signed-off-by: Chris Wilson
Cc: Michel Thierry
Cc: Mika Kuoppala
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/
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
On Thu, Jul 06, 2017 at 05:40:34PM +0300, Imre Deak wrote:
> Although on HSW/BDW there is only a single display global power well,
> it's programmed the same way as other GEN9+ power wells. This also
> means we can get at the HSW/BDW request and status flags the same way
> it's done on GEN9+ by ass
On Fri, Jul 21, 2017 at 05:41:13PM +0530, Mahesh Kumar wrote:
> Hi,
>
>
> On Thursday 20 July 2017 08:19 PM, Sharma, Shashank wrote:
> > Acked-by: Shashank Sharma
> >
> > Regards
> > Shashank
> > On 7/20/2017 4:20 AM, Imre Deak wrote:
> > > The scaler allocation code depends on a non-zero defau
Quoting Martin Peres (2017-07-21 13:02:47)
> On 21/07/17 14:27, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2017-07-21 12:08:00)
> >>
> >> On 21/07/2017 11:36, Chris Wilson wrote:
> >>> Quoting Tvrtko Ursulin (2017-07-21 11:20:05)
> From: Tvrtko Ursulin
> >>
> >> [snip]
> >>
> --- a/
From: Tvrtko Ursulin
No need to sync filesystems when only listing subtest.
Extremely marginal benefit of avoid a short stall after make
followed by listing subtests.
Signed-off-by: Tvrtko Ursulin
---
lib/igt_core.h | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/lib
I think Chris' comments show this isn't actually tested.
Can you please write at least one test case for igt ?
We have a pretty long list of patches that need to land (still need
review on some patches).
I would recommend you base you patches on this :
https://github.com/djdeath/intel-gpu-tool
Hi
On Friday 21 July 2017 06:20 PM, Imre Deak wrote:
On Fri, Jul 21, 2017 at 05:41:13PM +0530, Mahesh Kumar wrote:
Hi,
On Thursday 20 July 2017 08:19 PM, Sharma, Shashank wrote:
Acked-by: Shashank Sharma
Regards
Shashank
On 7/20/2017 4:20 AM, Imre Deak wrote:
The scaler allocation code d
== Series Details ==
Series: series starting with [01/20] drm/i915: Report execlists irq bit in
debugfs
URL : https://patchwork.freedesktop.org/series/27700/
State : failure
== Summary ==
Series 27700v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/27700/revisio
On Wed, Jul 12, 2017 at 06:54:13PM +0300, Imre Deak wrote:
> The pattern of a power well backing a set of pipe IRQ or VGA
> functionality applies to all HSW+ platforms. Using power well attributes
> instead of platform checks to decide whether to init/reset pipe IRQs and
> VGA correspondingly is cl
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 connector and to configure the same.
CP States defined:
DRM_CP_UN
== Series Details ==
Series: series starting with [01/20] drm/i915: Report execlists irq bit in
debugfs
URL : https://patchwork.freedesktop.org/series/27700/
State : failure
== Summary ==
Series 27700v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/27700/revisio
On Thu, Jul 06, 2017 at 05:40:36PM +0300, Imre Deak wrote:
> Similarly to GEN9+ waiting for the power well disabled state is a safer
> option and also provides diagnostic info if the disabling didn't succeed
> or the power well was forced on by an external requester. While at it
> also use the exis
Hi,
On Thursday 20 July 2017 04:20 AM, Imre Deak wrote:
The crtc state starts out being bzero'd, so no need to clear
scaler_users. Also intel_crtc_init_scalers() knows already which
platforms have scalers, so no need for the platform check here.
Similarly intel_crtc_init_scalers() will init sca
On Tue, Jul 11, 2017 at 11:42:35PM +0300, Imre Deak wrote:
> The pattern of a power well backing a set of fuses whose initialization
> we need to wait for during power well enabling is common to all GEN9+
> platforms. Adding support for this to the HSW power well enable helper
> allows us to use th
Quoting Tvrtko Ursulin (2017-07-21 14:00:27)
> From: Tvrtko Ursulin
>
> No need to sync filesystems when only listing subtest.
>
> Extremely marginal benefit of avoid a short stall after make
> followed by listing subtests.
Ah, I was looking for the sync recently, to move it to common_init()
al
On Fri, Jul 21, 2017 at 06:44:24PM +0530, Mahesh Kumar wrote:
> Hi,
>
>
> On Thursday 20 July 2017 04:20 AM, Imre Deak wrote:
> > The crtc state starts out being bzero'd, so no need to clear
> > scaler_users. Also intel_crtc_init_scalers() knows already which
> > platforms have scalers, so no nee
On Fri, Jul 21, 2017 at 02:32:55PM +0300, Arkadiusz Hiler wrote:
> On Fri, Jul 21, 2017 at 02:25:18PM +0300, Imre Deak wrote:
> > On Fri, Jul 21, 2017 at 02:14:33PM +0300, Arkadiusz Hiler wrote:
> > > On Thu, Jul 06, 2017 at 05:40:31PM +0300, Imre Deak wrote:
> > > > Atm we enable/disable a power w
On Tue, Jul 11, 2017 at 11:42:36PM +0300, Imre Deak wrote:
> After the previous refactorings the HSW/BDW and GEN9+ power well helpers
> are practically identical, so use the HSW power well helpers for GEN9+
> too. This means using the HSW power well ops instead of the SKL one and
> setting the irq_
On Thu, Jul 06, 2017 at 05:40:39PM +0300, Imre Deak wrote:
> Move the helper next to the rest of HSW specific code.
>
> Signed-off-by: Imre Deak
Reviewed-by: Arkadiusz Hiler
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freed
On Thu, Jul 06, 2017 at 05:40:40PM +0300, Imre Deak wrote:
> Shuffle the power well->domain mapping macros around so they are at one
> place in old->new GEN order.
>
> Signed-off-by: Imre Deak
Reviewed-by: Arkadiusz Hiler
___
Intel-gfx mailing list
Int
Hi,
On Friday 21 July 2017 06:56 PM, Imre Deak wrote:
On Fri, Jul 21, 2017 at 06:44:24PM +0530, Mahesh Kumar wrote:
Hi,
On Thursday 20 July 2017 04:20 AM, Imre Deak wrote:
The crtc state starts out being bzero'd, so no need to clear
scaler_users. Also intel_crtc_init_scalers() knows already
On 21/07/2017 14:17, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2017-07-21 14:00:27)
From: Tvrtko Ursulin
No need to sync filesystems when only listing subtest.
Extremely marginal benefit of avoid a short stall after make
followed by listing subtests.
Ah, I was looking for the sync recent
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:
[snip]
I've applied al
On Fri, Jul 21, 2017 at 07:36:22PM +0530, Mahesh Kumar wrote:
> Hi,
>
>
> On Friday 21 July 2017 06:56 PM, Imre Deak wrote:
> > On Fri, Jul 21, 2017 at 06:44:24PM +0530, Mahesh Kumar wrote:
> > > Hi,
> > >
> > >
> > > On Thursday 20 July 2017 04:20 AM, Imre Deak wrote:
> > > > The crtc state st
A couple of regression fixes that have been outstanding for a few weeks,
plus a pair of recent findings
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
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 to the user (as historically the culprit has
be a leak in the
I was being overly paranoid in not updating the execobject.offset after
performing the fallback copy where we set reloc.presumed_offset to -1.
The thinking was to ensure that a subsequent NORELOC execbuf would be
forced to process the invalid relocations. However this is overkill so
long as we *onl
The goal here was to minimise doing any thing or any check inside the
kernel that was not strictly required. For a userspace that assumes
complete control over the cache domains, the kernel is usually using
outdated information and may trigger clflushes where none were
required.
However, swapping
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.991802] kernel BUG at drivers/gpu/drm/i915/i915_vma.h:287!
[ 3193.9
On Thu, Jul 20, 2017 at 12:35:27PM +, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [v2,1/2] drm/i915: Fix scaler init during CRTC
> HW state readout (rev2)
> URL : https://patchwork.freedesktop.org/series/27607/
> State : success
>
> == Summary ==
>
> Series 27
On Fri, 21 Jul 2017, Daniel Vetter wrote:
> On Thu, Jul 20, 2017 at 6:23 PM, 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 everything started
>> clicking together.
>>
To get a YCBCR420 output from intel platforms, we need one
scaler to scale down YCBCR444 samples to YCBCR420 samples.
This patch:
- Does scaler allocation for HDMI ycbcr420 outputs.
- Programs PIPE_MISC register for ycbcr420 output.
V2: rebase
V3: rebase
V4: rebase
V5: addressed review comments f
To support ycbcr output, we need a pipe CSC block to do
RGB->YCBCR conversion.
Current Intel platforms have only one pipe CSC unit, so
we can either do color correction using it, or we can perform
RGB->YCBCR conversion.
This function adds a csc handler, which uses recommended bspec
values to perf
This patch series is a subset of series "YCBCR 4:2:0 handling in DRM layer"
Published and reviewed here: https://patchwork.freedesktop.org/series/26973/
The original series had 14 patches, out of which first 8 (which were in DRM
layer) are reviewed merged. These 6 patches are the I915 layer handli
When output colorspace is YCBCR420, we have to load the
corresponding colorspace in AVI infoframe. This patch fills
the colorspace of AVI infoframe as per the output mode.
V2: Rebase
V3: Rebase
V4: Rebase
V5: Added r-b from Ander
V6: Checking RGB/YCBCR420 output only (Ville)
V7: Add colorspace inf
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
This patch checks encoder level support for YCBCR420 outputs.
The logic goes as simple as this:
If the input mode is YCBCR420-only mode: prepare HDMI for
YCBCR420 output, else continue with RGB output mode.
It checks if the mode is YCBCR420 and source can support this
output then it marks the ycbc
This patch sets the is_hdmi2_src identifier in drm connector
for GLK platform. GLK contains a native HDMI 2.0 controller.
This identifier will help the EDID handling functions to save
lot of work which is specific to HDMI 2.0 sources.
V3: Added this patch
V4: Rebase
V4: Rebase
V5: Added r-b from A
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 everything started
>> clicking together.
On Fri, Jul 21, 2017 at 5:13 PM, Jani Nikula
wrote:
> On Fri, 21 Jul 2017, Daniel Vetter wrote:
>> On Thu, Jul 20, 2017 at 6:23 PM, 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 la
On Fri, Jul 21, 2017 at 2:02 PM, Martin Peres
wrote:
> This is why I would rather use the execution time of tests as a way to tag
> the tests. What I want is to have a couple of options that brings me the
> best coverage in a certain amount of time:
> - BAT: 70% coverage in 10 minutes
> - FULL:
On Fri, Jul 21, 2017 at 2:59 PM, Chris Wilson wrote:
> My dream would be for the system to recognise which tests provide
> coverage for a patch and rank them by relevance and then run until death
> or timeout. Without such introspection, the best we can do is to have
> the developer supply the sel
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/i915/intel_ringbuffer.c | 3 +++
1 file changed,
Quoting Chris Wilson (2017-07-21 17:11:01)
> 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
> ---
> dri
== Series Details ==
Series: series starting with [1/4] drm/i915: Remove assertion from raw
__i915_vma_unpin()
URL : https://patchwork.freedesktop.org/series/27714/
State : warning
== Summary ==
Series 27714v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/27714/
== Series Details ==
Series: YCBCR 4:2:0 handling in i915 layer (rev2)
URL : https://patchwork.freedesktop.org/series/27412/
State : success
== Summary ==
Series 27412v2 YCBCR 4:2:0 handling in i915 layer
https://patchwork.freedesktop.org/api/1.0/series/27412/revisions/2/mbox/
Test gem_exec_f
== Series Details ==
Series: drm/i915: Enforce that CS packets are qword aligned
URL : https://patchwork.freedesktop.org/series/27723/
State : success
== Summary ==
Series 27723v1 drm/i915: Enforce that CS packets are qword aligned
https://patchwork.freedesktop.org/api/1.0/series/27723/revisio
On 18/07/17 19:34, Chris Wilson wrote:
Quoting Lionel Landwerlin (2017-07-18 17:50:42)
static struct drm_driver driver = {
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 2b824f8875c4..607484737f3d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/
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
Here is another iteration which tries to address Chris' comments.
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/i915_drv.c |2 +
drive
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
On 18/07/17 19:14, Chris Wilson wrote:
Quoting Lionel Landwerlin (2017-07-18 18:18:52)
v2: Add tests regarding removing configs (Matthew)
Add tests regarding adding/removing configs without permissions
(Matthew)
v3: Add some flex registers (Matthew)
v4: memset oa_config to 0 (Lionel)
v2: Add tests regarding removing configs (Matthew)
Add tests regarding adding/removing configs without permissions
(Matthew)
v3: Add some flex registers (Matthew)
v4: memset oa_config to 0 (Lionel)
Change error code for removing unexisting config EINVAL->ENOENT (Lionel)
v5: Update i9
== Series Details ==
Series: Add support for loadable OA configs
URL : https://patchwork.freedesktop.org/series/27727/
State : success
== Summary ==
Series 27727v1 Add support for loadable OA configs
https://patchwork.freedesktop.org/api/1.0/series/27727/revisions/1/mbox/
Test gem_exec_flush:
On Fri, 2017-07-21 at 11:19 +0300, Paul Kocialkowski wrote:
> On Wed, 2017-07-19 at 16:50 +0300, Paul Kocialkowski wrote:
> > Nowadays, many VGA connectors are not actually native VGA but use a
> > discrete bridge to a digital connector. These bridges usually
> > enforce
> > their own EDID instead
Hi,
On 21-07-17 09:24, Daniel Vetter wrote:
Hi Greg&Hans,
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 probably lead to more conflicts because git will get confused.
Or you could just delet
1 - 100 of 105 matches
Mail list logo
