Hi Dave,
Just random misc stuff that Sean/Sumit&Archit picked up while I relaxed.
Well except for one commit:
commit a988588b1806b40ae115fe1c9ab38706fd1a7c2b
Author: Kristian H. Kristensen
Date: Tue Sep 13 14:20:45 2016 -0700
drm: Only use compat ioctl for addfb2 on X86/IA64
Pls also che
On Fri, 2016-09-16 at 16:59 +0300, Jani Nikula wrote:
> Pre-production hardware is not supported.
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_dp.c | 4
> drivers/gpu/drm/i915/intel_dp_link_training.c | 3 ---
> drivers/gpu/drm/i915/intel_guc_loader.c
On Mon, 19 Sep 2016, Mika Kahola wrote:
> On Fri, 2016-09-16 at 16:59 +0300, Jani Nikula wrote:
>> Pre-production hardware is not supported.
>>
>> Signed-off-by: Jani Nikula
>> ---
>> drivers/gpu/drm/i915/intel_dp.c | 4
>> drivers/gpu/drm/i915/intel_dp_link_training.c | 3
From: Shawn Lee
Backlight enable is supposed to do a full setup of the backlight. We
were missing the PWM alternate increment bit in the south chicken
registers on lpt+ pch. This potentially caused a PWM frequency change
when the chicken register value was lost e.g. on suspend.
v2 by Jani, rebas
This will also be needed later on when setting up the alternate
increment in backlight enable.
Cc: Shawn Lee
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_panel.c | 14 +++---
2 files changed, 12 insertions(+), 3 deletions(-)
diff
From: Shawn Lee
Backlight enable is supposed to do a full setup of the backlight. We
were missing the PWM alternate increment bit in the south chicken
registers on lpt+ pch. This potentially caused a PWM frequency change
when the chicken register value was lost e.g. on suspend.
v2 by Jani, rebas
On Mon, 19 Sep 2016, Jani Nikula wrote:
> From: Shawn Lee
>
> Backlight enable is supposed to do a full setup of the backlight. We
> were missing the PWM alternate increment bit in the south chicken
> registers on lpt+ pch. This potentially caused a PWM frequency change
> when the chicken registe
On pe, 2016-09-16 at 20:23 +0100, Chris Wilson wrote:
> void intel_lr_context_resume(struct drm_i915_private *dev_priv)
> {
> > - struct i915_gem_context *ctx = dev_priv->kernel_context;
> > struct intel_engine_cs *engine;
> > + struct i915_gem_context *ctx;
> +
> > + /* Because we emit
Hey,
Op 14-09-16 om 14:36 schreef Mahesh Kumar:
> Hi,
> There was an issue with transition WM, it was getting enabled & causing fifo
> underrun.
> I fixed the condition, After that tested kms_plane & not getting any underrun.
> Please let me know if you see any other issue.
kms_cursor_legacy.cu
On pe, 2016-09-16 at 20:23 +0100, Chris Wilson wrote:
> int i915_gem_freeze_late(struct drm_i915_private *dev_priv)
> {
> > struct drm_i915_gem_object *obj;
> @@ -4692,7 +4705,8 @@ int i915_gem_freeze_late(struct drm_i915_private
> *dev_priv)
> > * the objects as well.
> > */
>
>
From: "Lee, Shawn C"
SPT_PWM_GRANULARITY (SOUTH_CHICKEN1, bit 0) controls the granularity
(minimum increment) of the PWM backlight control counter. PWM frequency
adjustment on 128 clock increments when this bit was 1. And 16 clock
increments when it was 0.
PWM frequency multiple octuple (from 20
On Mon, 19 Sep 2016, Jani Nikula wrote:
> From: Shawn Lee
>
> Backlight enable is supposed to do a full setup of the backlight. We
> were missing the PWM alternate increment bit in the south chicken
> registers on lpt+ pch. This potentially caused a PWM frequency change
> when the chicken registe
On Mon, 19 Sep 2016, "Lee, Shawn C" wrote:
> From: "Lee, Shawn C"
>
> SPT_PWM_GRANULARITY (SOUTH_CHICKEN1, bit 0) controls the granularity
> (minimum increment) of the PWM backlight control counter. PWM frequency
> adjustment on 128 clock increments when this bit was 1. And 16 clock
> increments
On Mon, Sep 19, 2016 at 11:31:37AM +0300, Joonas Lahtinen wrote:
> On pe, 2016-09-16 at 20:23 +0100, Chris Wilson wrote:
> > int i915_gem_freeze_late(struct drm_i915_private *dev_priv)
> > {
> > > struct drm_i915_gem_object *obj;
> > @@ -4692,7 +4705,8 @@ int i915_gem_freeze_late(struct drm_i91
On Mon, 19 Sep 2016, "Lee, Shawn C" wrote:
> + if (HAS_PCH_LPT(dev_priv)) {
> + mul = I915_READ(SOUTH_CHICKEN2);
> + mul &= ~LPT_PWM_GRANULARITY;
> + I915_WRITE(SOUTH_CHICKEN2, mul |
> (panel->backlight.pwm_alternate_increment << LPT_PWM_GRANULARITY));
> +
On ke, 2016-09-14 at 07:52 +0100, Chris Wilson wrote:
> +static long
> +__i915_request_wait_for_submit(struct drm_i915_gem_request *request,
> + unsigned int flags,
> + long timeout)
> +{
> + const int state = flags & I915_WAIT_INTERRUPTIBLE
Hi all,
New -testing cycle with cool stuff:
- refactor the sseu code (Imre)
- refine guc dmesg output (Dave Gordon)
- more vgpu work
- more skl wm fixes (Lyude)
- refactor dpll code in prep for upfront link training (Jim Bride et al)
- consolidate all platform feature checks into intel_device_info
he git repository at:
git://anongit.freedesktop.org/drm-intel tags/drm-intel-next-2016-09-19
for you to fetch changes up to 6e05f3d3b9298a56d6f1acb474a75cf14a17c31e:
drm/i915: Update DRIVER_DATE to 20160919 (2016-09-19 09:26:08 +0200)
---
PWM was enabled in bios. i915 driver will save max duty to panel->backlight.max.
So *_hz_to_pwm will not be called if backlight.max not zero.
pch_ctl2 = I915_READ(BLC_PWM_PCH_CTL2);
panel->backlight.max = pch_ctl2 >> 16;
if (!panel->backlight.max)
panel->b
On Mon, 19 Sep 2016, "Lee, Shawn C" wrote:
> PWM was enabled in bios. i915 driver will save max duty to
> panel->backlight.max.
> So *_hz_to_pwm will not be called if backlight.max not zero.
And what difference does it make?
BR,
Jani.
>
> pch_ctl2 = I915_READ(BLC_PWM_PCH_CTL2);
>
From: "Lee, Shawn C"
SPT_PWM_GRANULARITY (SOUTH_CHICKEN1, bit 0) controls the granularity
(minimum increment) of the PWM backlight control counter. PWM frequency
adjustment on 128 clock increments when this bit was 1. And 16 clock
increments when it was 0.
PWM frequency multiple octuple (from 20
On Mon, 19 Sep 2016, "Lee, Shawn C" wrote:
> From: "Lee, Shawn C"
>
> SPT_PWM_GRANULARITY (SOUTH_CHICKEN1, bit 0) controls the granularity
> (minimum increment) of the PWM backlight control counter. PWM frequency
> adjustment on 128 clock increments when this bit was 1. And 16 clock
> increments
Op 14-09-16 om 14:36 schreef Mahesh Kumar:
> Hi,
> There was an issue with transition WM, it was getting enabled & causing fifo
> underrun.
> I fixed the condition, After that tested kms_plane & not getting any underrun.
> Please let me know if you see any other issue.
>
> Regards,
> -Mahesh
>
> O
Understood. Thanks!
-Original Message-
From: Nikula, Jani
Sent: Monday, September 19, 2016 5:43 PM
To: Lee, Shawn C ; intel-gfx@lists.freedesktop.org
Cc: Lee, Shawn C
Subject: Re: [PATCH] drm/i915 : Restore PWM_GRANULARITY after resume
On Mon, 19 Sep 2016, "Lee, Shawn C" wrote:
> From
== Series Details ==
Series: drm/i915 : Restore PWM_GRANULARITY after resume (rev3)
URL : https://patchwork.freedesktop.org/series/12165/
State : success
== Summary ==
Series 12165v3 drm/i915 : Restore PWM_GRANULARITY after resume
https://patchwork.freedesktop.org/api/1.0/series/12165/revision
for
convenience) to record what (public, well-known) commit your patch series was
built on]
[Check https://git-scm.com/docs/git-format-patch for more information]
url:
https://github.com/0day-ci/linux/commits/Lee-Shawn-C/drm-i915-Restore-PWM_GRANULARITY-after-resume/20160919-180644
base:
CI got confused by all the patches flowing in the earlier thread, so
resend. No changes.
BR,
Jani.
Jani Nikula (1):
drm/i915/backlight: setup and cache pwm alternate increment value
Shawn Lee (1):
drm/i915/backlight: setup backlight pwm alternate increment on
backlight enable
drivers/g
From: Shawn Lee
Backlight enable is supposed to do a full setup of the backlight. We
were missing the PWM alternate increment bit in the south chicken
registers on lpt+ pch. This potentially caused a PWM frequency change
when the chicken register value was lost e.g. on suspend.
v2 by Jani, rebas
This will also be needed later on when setting up the alternate
increment in backlight enable.
Cc: Shawn Lee
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_panel.c | 14 +++---
2 files changed, 12 insertions(+), 3 deletions(-)
diff
On ke, 2016-09-14 at 07:52 +0100, Chris Wilson wrote:
> @@ -465,8 +466,15 @@ i915_gem_request_await_request(struct
> drm_i915_gem_request *to,
> return ret < 0 ? ret : 0;
> }
>
> + if (from->global_seqno == 0) {
Just use (!from->global_seqno) here too, for consistency.
M
On ke, 2016-09-14 at 07:52 +0100, Chris Wilson wrote:
> @@ -1572,6 +1572,8 @@ static int gen8_emit_request(struct
> drm_i915_gem_request *request)
> return intel_logical_ring_advance(request);
> }
>
> +static const int gen8_emit_request_sz = 6 + WA_TAIL_DWORDS;
Could argue these to be #d
nce) to record what (public, well-known) commit your patch series was
built on]
[Check https://git-scm.com/docs/git-format-patch for more information]
url:
https://github.com/0day-ci/linux/commits/Jani-Nikula/drm-i915-backlight-setup-backlight-pwm-alternate-increment-on-backlight-enable/20160
nce) to record what (public, well-known) commit your patch series was
built on]
[Check https://git-scm.com/docs/git-format-patch for more information]
url:
https://github.com/0day-ci/linux/commits/Lee-Shawn-C/drm-i915-Restore-PWM_GRANULARITY-after-resume/20160919-180644
base:
== Series Details ==
Series: drm/i915: fix pwm increment setup
URL : https://patchwork.freedesktop.org/series/12636/
State : warning
== Summary ==
Series 12636v1 drm/i915: fix pwm increment setup
https://patchwork.freedesktop.org/api/1.0/series/12636/revisions/1/mbox/
Test kms_pipe_crc_basic:
On Wed, Sep 14, 2016 at 10:37:18AM +0300, Joonas Lahtinen wrote:
> On ke, 2016-09-14 at 07:52 +0100, Chris Wilson wrote:
> > + array = to_fence_array(fence);
> > + for (i = 0; i < array->num_fences; i++) {
> > + struct fence *child = array->fences[i];
> > +
> > + if (fence_i
On Mon, Sep 19, 2016 at 01:47:30PM +0300, Joonas Lahtinen wrote:
> On ke, 2016-09-14 at 07:52 +0100, Chris Wilson wrote:
> > @@ -2677,8 +2681,21 @@ static void intel_ring_default_vfuncs(struct
> > drm_i915_private *dev_priv,
> > engine->reset_hw = reset_ring_common;
> >
> > engine->emit_
v2 of an old series, addressing issues pointed out by Ville.
BR,
Jani.
Jani Nikula (7):
drm/i915/dsi: don't debug log "missing" sequences
drm/i915/dsi: add debug logging to element execution
drm/i915/dsi: add skip functions for spi and pmic elements
drm/i915/dsi: update reset and power se
This is not interesting. They are not "missing", they are just not part
of the VBT sequences for the panel.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
Just simple breadcrumbs for now. While at it, rename the i2c skip
function.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
b/drivers/gpu/drm/i9
In sequence block v3 these are gracefully skipped anyway, but add the
functions so we can have some debug breadcrumbs.
v2: the pmic block is 15 bytes (Ville)
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 16
1 file changed, 16 insertions(+)
diff -
Based on the documentation alone, it's anyone's guess when exactly we
should be running these sequences. Add power on/off sequences where they
feel logical and update assert/deassert reset. The drm panel hooks don't
currently offer us more granularity anyway.
v2: update assert/deassert reset as we
Be a little paranoid in case the specs change or something.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
index 24953f9
Based on the documentation alone, it's anyone's guess when exactly we
should be running these sequences. Add them where it feels logical. The
drm panel hooks don't currently offer us more granularity anyway.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 2 ++
1 file
Leave behind some debugging clues in case some panels don't work
properly.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_bios.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index c6e69e4cfa83..83667e8cd
On ke, 2016-09-14 at 07:52 +0100, Chris Wilson wrote:
> +static void gen8_emit_wa_tail(struct drm_i915_gem_request *request, u32 *out)
> {
> - struct intel_ring *ring = request->ring;
> - int ret;
> -
> - ret = intel_ring_begin(request, 6 + WA_TAIL_DWORDS);
> - if (ret)
> -
On ma, 2016-09-19 at 09:38 +0100, Chris Wilson wrote:
> On Mon, Sep 19, 2016 at 11:31:37AM +0300, Joonas Lahtinen wrote:
> >
> > On pe, 2016-09-16 at 20:23 +0100, Chris Wilson wrote:
> > >
> > > int i915_gem_freeze_late(struct drm_i915_private *dev_priv)
> > > {
> > > >
> > > > > > > >
== Series Details ==
Series: drm/i915: clean up dsi sequences
URL : https://patchwork.freedesktop.org/series/12640/
State : warning
== Summary ==
Series 12640v1 drm/i915: clean up dsi sequences
https://patchwork.freedesktop.org/api/1.0/series/12640/revisions/1/mbox/
Test kms_pipe_crc_basic:
On Tue, Sep 06, 2016 at 12:59:31PM -0400, Sean Paul wrote:
> On Wed, Aug 31, 2016 at 12:09 PM, Daniel Vetter
> wrote:
> > Just pure code movement, cleanup and polish will happen in later
> > patches.
> >
> > v2: Don't forget all the ioctl! To extract those cleanly I decided to
> > put check_src_c
On Fri, Sep 02, 2016 at 03:00:38PM +0530, Archit Taneja wrote:
>
>
> On 8/31/2016 9:39 PM, Daniel Vetter wrote:
> > Big thing is untangling and carefully documenting the different uapi
> > types of planes. I also sprinkled a few more cross references around
> > to make this easier to discover.
>
On ke, 2016-09-14 at 07:52 +0100, Chris Wilson wrote:
> @@ -262,6 +263,12 @@ static int i915_gem_init_global_seqno(struct
> drm_i915_private *dev_priv,
> for_each_engine(engine, dev_priv)
> intel_engine_init_global_seqno(engine, seqno);
>
> + list_for_each_entry(tl, &dev_
On ke, 2016-09-14 at 07:52 +0100, Chris Wilson wrote:
> @@ -310,12 +311,21 @@ __create_hw_context(struct drm_device *dev,
> goto err_out;
> } else
> ret = DEFAULT_CONTEXT_HANDLE;
Confusing indent, so add braces to above else and a newline here.
Reviewed-b
On ke, 2016-09-14 at 07:52 +0100, Chris Wilson wrote:
> +static int reserve_global_seqno(struct drm_i915_private *i915)
> {
> - struct i915_gem_timeline *tl = &dev_priv->gt.global_timeline;
> + struct i915_gem_timeline *tl = &i915->gt.global_timeline;
> + u32 next_seqno = atomic_read(&
On Mon, Sep 19, 2016 at 03:02:23PM +0300, Jani Nikula wrote:
> v2 of an old series, addressing issues pointed out by Ville.
Entire series looks reasonable. Spec is vague, so hard to be 100% sure.
Reviewed-by: Ville Syrjälä
>
> BR,
> Jani.
>
> Jani Nikula (7):
> drm/i915/dsi: don't debug log
On Tue, Sep 06, 2016 at 12:59:39PM -0400, Sean Paul wrote:
> On Wed, Aug 31, 2016 at 12:09 PM, Daniel Vetter
> wrote:
> > Some were still left in drm_crtc.h. Also include drm_edid.h in the
> > rst files.
> >
> > Signed-off-by: Daniel Vetter
>
> Reviewed-by: Sean Paul
Merged up to this patch,
On Fri, Sep 16, 2016 at 01:06:36PM +0300, Jani Nikula wrote:
>drivers/gpu/drm/drm_dp_helper.c: In function 'drm_dp_downstream_debug':
> >> drivers/gpu/drm/drm_dp_helper.c:551:2: error: implicit declaration of
> >> function 'seq_printf' [-Werror=implicit-function-declaration]
> seq_printf(m
On Sun, 2016-09-18 at 13:35 +0200, Thorsten Leemhuis wrote:
> Hi! James & Paulo: What's the current status of this?
No, the only interaction has been the suggestion below for a revert,
which didn't fix the problem.
> Was this issue discussed elsewhere or even fixed in between? Just
> asking, be
From: "arun.siluv...@linux.intel.com"
In preparation for engine reset work update this parameter to handle more
than one type of reset. Default at the moment is still full gpu reset.
v2
- rebase
Cc: Chris Wilson
Cc: Mika Kuoppala
Signed-off-by: Arun Siluvery
Signed-off-by: Matthew Auld
--
From: Mika Kuoppala
To perform engine reset we first disable engine to capture its state. This
is done by issuing a reset request. Because we are reusing existing
infrastructure, again when we actually reset an engine, reset function
checks engine mask and issues reset request again which is unne
From: "arun.siluv...@linux.intel.com"
This feature is made available only from Gen8, for previous gen devices
driver uses legacy full gpu reset.
v2
- rebase
Cc: Chris Wilson
Cc: Mika Kuoppala
Signed-off-by: Tomas Elf
Signed-off-by: Arun Siluvery
Signed-off-by: Matthew Auld
---
drivers/g
From: "arun.siluv...@linux.intel.com"
This is a preparatory patch which modifies error handler to do per engine
hang recovery. The actual patch which implements this sequence follows
later in the series. The aim is to prepare existing recovery function to
adapt to this new function where applicab
From: "arun.siluv...@linux.intel.com"
This change implements support for per-engine reset as an initial, less
intrusive hang recovery option to be attempted before falling back to the
legacy full GPU reset recovery mode if necessary. This is only supported
from Gen8 onwards.
Hangchecker determin
From: "arun.siluv...@linux.intel.com"
A new variable is added to export the reset counts to debugfs, this
includes full gpu reset and engine reset count. This is useful for tests
where they areexpected to trigger reset; these counts are checked before
and after the test to ensure the same.
v2
From: "arun.siluv...@linux.intel.com"
Driver maintains count of how many times a given engine is reset, useful to
capture this in error state also. It gives an idea of how engine is coping
up with the workloads it is executing before this error state.
v2
- rebase
Cc: Chris Wilson
Cc: Mika Ku
On Mon, 19 Sep 2016, Joonas Lahtinen wrote:
> On ke, 2016-09-14 at 07:52 +0100, Chris Wilson wrote:
>> +static int reserve_global_seqno(struct drm_i915_private *i915)
>> {
>> -struct i915_gem_timeline *tl = &dev_priv->gt.global_timeline;
>> +struct i915_gem_timeline *tl = &i915->gt.global
On Mon, 19 Sep 2016, Ville Syrjälä wrote:
> On Mon, Sep 19, 2016 at 03:02:23PM +0300, Jani Nikula wrote:
>> v2 of an old series, addressing issues pointed out by Ville.
>
> Entire series looks reasonable. Spec is vague, so hard to be 100% sure.
We're about to find out, I pushed the lot. Thanks fo
On ke, 2016-09-14 at 07:52 +0100, Chris Wilson wrote:
> @@ -315,17 +304,42 @@ submit_notify(struct i915_sw_fence *fence, enum
> i915_sw_fence_notify state)
> {
> struct drm_i915_gem_request *request =
> container_of(fence, typeof(*request), submit);
> + struct intel_timeli
On ma, 2016-09-19 at 16:30 +0100, Matthew Auld wrote:
> From: "arun.siluv...@linux.intel.com"
>
I assume "From:" needs to be properly formatted just like
"Signed-off-by:". So in all patches;
From: Arun Siluvery
Cover letters are also gaining popularity, and remember to use
--reroll-count=N wh
Maarten, could you give this a look?
On ke, 2016-09-14 at 07:52 +0100, Chris Wilson wrote:
> After combining the dma-buf reservation object and the GEM reservation
> object, we lost the ability to do a nonblocking wait on the i915 request
> (as we blocked upon the reservation object during prepare
On ma, 2016-09-19 at 18:35 +0300, Jani Nikula wrote:
> > On Mon, 19 Sep 2016, Joonas Lahtinen
> > wrote:
> >
> > On ke, 2016-09-14 at 07:52 +0100, Chris Wilson wrote:
> > >
> > > +static int reserve_global_seqno(struct drm_i915_private *i915)
> > > {
> > > - struct i915_gem_timeline *tl = &dev
On ma, 2016-09-19 at 12:32 +0100, Chris Wilson wrote:
> On Mon, Sep 19, 2016 at 01:47:30PM +0300, Joonas Lahtinen wrote:
> > On ke, 2016-09-14 at 07:52 +0100, Chris Wilson wrote:
> > > @@ -2677,8 +2681,21 @@ static void intel_ring_default_vfuncs(struct
> > > drm_i915_private *dev_priv,
> > > e
On to, 2016-09-15 at 16:28 +0300, Jani Nikula wrote:
> Fix sparse warnings:
>
> drivers/gpu/drm/i915/i915_drv.c:1179:5: warning: symbol
> 'i915_driver_load' was not declared. Should it be static?
>
> drivers/gpu/drm/i915/i915_drv.c:1267:6: warning: symbol
> 'i915_driver_unload' was not declared.
Some of the Intel platforms have odd numbers of LUT entries and we
need to tests a couple of values around the expected result. Bring
back the CRC equal function we need that doesn't trigger an assert
right away, while we still assert if we can't find a correct result in
the outter loop.
bugzilla:
On Mon, 19 Sep 2016, Lionel Landwerlin wrote:
> Some of the Intel platforms have odd numbers of LUT entries and we
> need to tests a couple of values around the expected result. Bring
> back the CRC equal function we need that doesn't trigger an assert
> right away, while we still assert if we can
== Series Details ==
Series: series starting with [1/7] drm/i915: Update i915.reset to handle engine
resets
URL : https://patchwork.freedesktop.org/series/12651/
State : failure
== Summary ==
Series 12651v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/12651/rev
On Tuesday 06 September 2016 12:06 PM, Chris Wilson wrote:
On Tue, Sep 06, 2016 at 10:54:14AM +0530, Praveen Paneri wrote:
Decoupled MMIO is an alternative way to access forcewake domain
registers, which requires less cycles and avoids frequent software
forcewake.
How about when forcewake is
On Thu, Sep 15, 2016 at 12:25:51PM -0700, Manasi Navare wrote:
> On Thu, Sep 15, 2016 at 10:48:17AM -0700, Pandiyan, Dhinakaran wrote:
> > On Tue, 2016-09-13 at 18:08 -0700, Manasi Navare wrote:
> > > From: Jim Bride
> > >
> > > Add upfront link training to intel_dp_mst_mode_valid() so that we kn
Decoupled MMIO is an alternative way to access forcewake domain
registers, which requires less cycles and avoids frequent software
forcewake.
v2:
- Moved platform check out of the function and got rid of duplicate
functions to find out decoupled power domain.
- Added a check for forcewake already
On Mon, Sep 19, 2016 at 10:03:29AM -0700, Jim Bride wrote:
> On Thu, Sep 15, 2016 at 12:25:51PM -0700, Manasi Navare wrote:
> > On Thu, Sep 15, 2016 at 10:48:17AM -0700, Pandiyan, Dhinakaran wrote:
> > > On Tue, 2016-09-13 at 18:08 -0700, Manasi Navare wrote:
> > > > From: Jim Bride
> > > >
> > >
== Series Details ==
Series: drm/i915/bxt: Broxton decoupled MMIO (rev2)
URL : https://patchwork.freedesktop.org/series/12028/
State : warning
== Summary ==
Series 12028v2 drm/i915/bxt: Broxton decoupled MMIO
https://patchwork.freedesktop.org/api/1.0/series/12028/revisions/2/mbox/
Test kms_cu
Em Sex, 2016-09-09 às 13:30 +0530, Kumar, Mahesh escreveu:
> From: Mahesh Kumar
>
> This patch make changes to use linetime latency instead of allocated
> DDB size during plane watermark calculation in switch case, This is
> required to implement new DDB allocation algorithm.
>
> In New Algorith
Em Seg, 2016-09-19 às 15:19 -0300, Paulo Zanoni escreveu:
> Em Sex, 2016-09-09 às 13:30 +0530, Kumar, Mahesh escreveu:
> >
> > From: Mahesh Kumar
> >
> > This patch make changes to use linetime latency instead of
> > allocated
> > DDB size during plane watermark calculation in switch case, This
Hi,
I have a monitor, that when connected a skylake system, doesn't ever come
up when hotplugging or after resume. The "bios" seems to not have problems
bringing it up, even at the native 3840x2160 resolution, and when it works,
all modes are correctly read (checked via xrandr).
I tried both the
And the normal output at bootup:
[2.826131] [drm:drm_helper_probe_single_connector_modes]
[CONNECTOR:48:DP-2]
[2.826135] [drm:intel_dp_detect] [CONNECTOR:48:DP-2]
[2.826645] [drm:intel_dp_get_dpcd] DPCD: 12 14 c4 01 01 15 00 01 00 00
04 00 0f 00 00
[2.827032] [drm:intel_dp_get_dpcd
Hi Maarten,
Is this the Debug message when you are connected to the external DP Port or the
HDMI port? I want to know if the problem is with the native DP connector or
LSPCON?
Also could you send the log that has the Video Bios Table information (VBT)
information?
Manasi
From: Intel-gfx [mail
On Mon, 2016-09-19 at 08:09 -0700, James Bottomley wrote:
> On Sun, 2016-09-18 at 13:35 +0200, Thorsten Leemhuis wrote:
> > Hi! James & Paulo: What's the current status of this?
>
> No, the only interaction has been the suggestion below for a revert,
> which didn't fix the problem.
>
> > Was thi
The previous messages are about using the HDMI connection of my monitor on
the HDMI 2.0->DP bridge (whatever the formal name may be) of my motherboard,
Using the HDMI 1.4 connection of my motherboard:
[ 55.744581] [drm:intel_get_hpd_pins] hotplug event received, stat
0x0040, dig 0x10101210,
On Mon, Sep 19, 2016 at 04:30:14PM +0100, Matthew Auld wrote:
> From: "arun.siluv...@linux.intel.com"
>
> This is a preparatory patch which modifies error handler to do per engine
> hang recovery. The actual patch which implements this sequence follows
> later in the series. The aim is to prepare
On Mon, Sep 19, 2016 at 04:30:15PM +0100, Matthew Auld wrote:
> From: "arun.siluv...@linux.intel.com"
>
> This change implements support for per-engine reset as an initial, less
> intrusive hang recovery option to be attempted before falling back to the
> legacy full GPU reset recovery mode if ne
On Mon, Sep 19, 2016 at 04:30:13PM +0100, Matthew Auld wrote:
> From: "arun.siluv...@linux.intel.com"
>
> In preparation for engine reset work update this parameter to handle more
> than one type of reset. Default at the moment is still full gpu reset.
This is not ready yet. Please try integrati
I checked both monitors, on displayport they work, on HDMI they share the
same trouble.
An interesting observation is that when plug the monitor into another
system which has an older nvidia card using nouveau (only HDMI is
available, card is too old for displayport).
It seems that the i2c connect
Hi
Em Sex, 2016-09-09 às 13:31 +0530, Kumar, Mahesh escreveu:
> From: Mahesh Kumar
>
> This patch adds support to decode system memory bandwidth
> which will be used for arbitrated display memory percentage
> calculation in GEN9 based system.
This is not a complete review of this patch since I
Corrected typo in bridge and encoder comparison. Also, added a one-line
encoder description from the previous documentation.
Cc: Daniel Vetter
Cc: Archit Taneja
Signed-off-by: Dhinakaran Pandiyan
---
drivers/gpu/drm/drm_encoder.c | 17 +
1 file changed, 9 insertions(+), 8 dele
== Series Details ==
Series: drm: Fix typo in encoder docs
URL : https://patchwork.freedesktop.org/series/12666/
State : warning
== Summary ==
Series 12666v1 drm: Fix typo in encoder docs
https://patchwork.freedesktop.org/api/1.0/series/12666/revisions/1/mbox/
Test kms_pipe_crc_basic:
From: Mika Kuoppala
Commit to a mode before querying it.
Tested-by: Rodrigo Vivi
References: https://bugs.freedesktop.org/show_bug.cgi?id=97172
Cc: Maarten Lankhorst
Signed-off-by: Mika Kuoppala
Signed-off-by: Rodrigo Vivi
---
tests/kms_psr_sink_crc.c | 8
1 file changed, 8 inserti
This series lays the groundwork for more DP MST audio work that will
follow.
v7:
Added R-B tags and rebased.
v6:
Modified the return type for a helper that returns port in intel_dvo.c
v5:
Really renamed the port enum member from 'attached_port' to 'port'
Rebased on atomic changes.
v4:
Fixed mis
From: "Pandiyan, Dhinakaran"
Storing the port enum in intel_encoder makes it convenient to know the
port attached to an encoder. Moving the port information up from
intel_digital_port to intel_encoder avoids unecessary intel_digital_port
access and handles MST encoders cleanly without requiring c
From: "Pandiyan, Dhinakaran"
Now that we have the port enum stored in intel_encoder, use that instead of
dereferencing intel_dig_port. Saves us a few locals.
struct intel_encoder variables have been renamed to be consistent and
convey type information.
v2:
Fix incorrect 'enum port' member names
From: "Pandiyan, Dhinakaran"
With DP MST, a digital_port can carry more than one audio stream. Hence,
more than one audio_connector needs to be attached to intel_digital_port in
such cases. However, each stream is associated with an unique encoder. So,
instead of creating an array of audio_connec
From: "Pandiyan, Dhinakaran"
Changing the return type from 'char' to 'enum port' in
intel_dvo_port_name() makes it easier to later move the port information to
intel_encoder. In addition, the port type conforms to what we have
elsewhere.
Removing the last conditional that handles invalid port be
From: Libin Yang
(This patch is developed by Dave Airlie originally)
This patch adds support for DP MST audio in i915.
Enable audio codec when DP MST is enabled if has_audio flag is set.
Disable audio codec when DP MST is disabled if has_audio flag is set.
Another separated patches to support
1 - 100 of 101 matches
Mail list logo
