== Series Details ==
Series: drm/i915/bxt: Fix eDP link training after suspend (rev2)
URL : https://patchwork.freedesktop.org/series/8783/
State : failure
== Summary ==
Series 8783v2 drm/i915/bxt: Fix eDP link training after suspend
http://patchwork.freedesktop.org/api/1.0/series/8783/revision
Hi Daniel,
I have tested your David's drm-next branch[1] which including this patch.
In most time it is ok. But when switching modes or disable/re-enable
mode, it will encounter bellow error msg:
--
[ 357.940728] [drm:drm_atomic_helper_commit_cleanup_done] *ERROR*
[CRTC:24:crtc-0] flip_done timed
> -Original Message-
> From: Patchwork [mailto:patchw...@emeril.freedesktop.org]
> Sent: Monday, June 13, 2016 10:54 PM
> To: Sripada, Radhakrishna
> Cc: intel-gfx@lists.freedesktop.org
> Subject: ✗ Ro.CI.BAT: failure for drm/i915/skl: Increase cursor ddb blocks in
> multi-pipe config
>
>
I believe we should use whatever BSpec recommends.
If that is not the best behavior and block things out than the spec
needs to be updated or a workaround documented there.
Art? thoughts?
On Mon, Jun 13, 2016 at 3:03 PM, Radhakrishna Sripada
wrote:
> The bspec suggests giving cursor planes a fi
On Thu, 2016-06-16 at 14:29 -0700, James Bottomley wrote:
> On Thu, 2016-06-16 at 23:24 +0200, Daniel Vetter wrote:
> > I guess we'll need the bisect on this one to make progress.
>
> Sigh, I was afraid that might be the next step.
OK, I have a curious data point. I assumed the problem would be
On Thu, Apr 21, 2016 at 11:44:48AM -0400, Lyude wrote:
> Unfortunately HPD isn't functional once we shut off all of the power
> domains. Unfortunately we can end up shutting off all of the power
> domains in any situation where we don't have any monitors connected,
> essentially breaking hpd for th
On Wed, Jun 15, 2016 at 10:58:29AM +0200, vinoth eswaran wrote:
> Hello,
>
> I working on an embedded project with Minnowboard Turbot. The goal is
> to have a camera application running as fast as possible (within 2
> sec).
>
> For this, I have replaced the UEFI bootloader with the U-boot (Latest
On Tue, Jun 14, 2016 at 09:56:01PM +0100, Chris Wilson wrote:
> obj->base.dma_buf represents a dma-buf exported from this object (for
> use by others). On the contrary, obj->base.import_attach represents the
> source dma-buf that was used to create this object (if any). When
> serialising with thir
On Thu, Jun 16, 2016 at 05:37:54PM +0300, Mika Kuoppala wrote:
> Chris Wilson writes:
> > Neither seem like a general solution for finding the testcase, for all of
> > the installed, not-installed, mixed-installed combinations.
> >
> > Even more tricky is that we want tighter control over the batc
On Thu, 2016-06-16 at 23:24 +0200, Daniel Vetter wrote:
> On Thu, Jun 16, 2016 at 11:15 PM, James Bottomley
> wrote:
> > On Mon, 2016-06-13 at 13:14 +0300, Jani Nikula wrote:
> > > On Tue, 31 May 2016, James Bottomley <
> > > james.bottom...@hansenpartnership.com> wrote:
> > > > On Tue, 2016-05-31
On Thu, Jun 16, 2016 at 11:15 PM, James Bottomley
wrote:
> On Mon, 2016-06-13 at 13:14 +0300, Jani Nikula wrote:
>> On Tue, 31 May 2016, James Bottomley <
>> james.bottom...@hansenpartnership.com> wrote:
>> > On Tue, 2016-05-31 at 10:51 +0300, Jani Nikula wrote:
>> > > On Mon, 30 May 2016, James B
On Mon, 2016-06-13 at 13:14 +0300, Jani Nikula wrote:
> On Tue, 31 May 2016, James Bottomley <
> james.bottom...@hansenpartnership.com> wrote:
> > On Tue, 2016-05-31 at 10:51 +0300, Jani Nikula wrote:
> > > On Mon, 30 May 2016, James Bottomley <
> > > james.bottom...@hansenpartnership.com> wrote:
>
On Thu, Jun 16, 2016 at 04:42:30PM +0100, Chris Wilson wrote:
> On Thu, Jun 16, 2016 at 05:19:49PM +0200, Michał Winiarski wrote:
> > void gen6_rps_busy(struct drm_i915_private *dev_priv)
> > {
> > mutex_lock(&dev_priv->rps.hw_lock);
> > if (dev_priv->rps.enabled) {
>
> /* Ensure we star
On 8 June 2016 at 20:41, wrote:
> From: Ville Syrjälä
>
> If we've determined that the encoder is eDP, we shouldn't try to use MST
> on it. Or at least the code doesn't seem to expect that since there are
> some type==DP checks in the MST code.
>
> Cc: Dave Airlie
> Signed-off-by: Ville Syrjälä
On 15 June 2016 at 16:45, Daniel Vetter wrote:
> On Wed, Jun 15, 2016 at 01:50:02PM +0100, Emil Velikov wrote:
>> On 14 June 2016 at 19:50, Daniel Vetter wrote:
>> > Master-based auth only exists for the legacy/primary drm_minor, hence
>> > there can only be one per device. The goal here is to un
On Thu, Jun 16, 2016 at 04:37:19PM +0300, Imre Deak wrote:
> This fixes eDP link training errors I noticed on BXT after suspend to
> ram and adds some HW sanity check to catch similar issues in the future.
>
> Imre Deak (4):
> drm/i915/bxt: Fix PPS lost state after suspend breaking eDP link
>
Regards
Shashank
On 6/16/2016 7:10 PM, Ville Syrjälä wrote:
On Thu, Jun 16, 2016 at 06:11:50PM +0530, Sharma, Shashank wrote:
Regards
Shashank
On 6/8/2016 4:11 PM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä
Now that eDP encoders won't have can_mst==true, we can throw out
the en
The wait for panel status helper will only function correctly if the
HW panel timings are programmed correctly. Returning prematurely from
this helper may lead to obscure bugs later, so sanity check the HW
timing registers.
v2:
- Check the T8, T9 fields too, we do program them (Ville)
CC: Ville S
Hi,
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on next-20160616]
[cannot apply to v4.7-rc3]
[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/tim-gore-intel-com/drm
== Series Details ==
Series: drm/i915:gen9: implement WaMtpRenderPowerGatingBug
URL : https://patchwork.freedesktop.org/series/8792/
State : failure
== Summary ==
CC drivers/usb/storage/usual-tables.o
CC drivers/usb/core/generic.o
CC drivers/usb/core/quirks.o
CC dri
On Thu, Jun 16, 2016 at 05:19:49PM +0200, Michał Winiarski wrote:
> If the GPU load is low enough, it's possible that we'll be stuck at idle
> frequency rather than transition into softmin frequency requested by
> userspace.
> Since we assume that idle_freq <= min_freq_softlimit and
> valleyview_se
On to, 2016-06-16 at 17:01 +0300, Ville Syrjälä wrote:
> On Thu, Jun 16, 2016 at 04:37:23PM +0300, Imre Deak wrote:
> > The wait for panel status helper will only function correctly if the
> > HW panel timings are programmed correctly. Returning prematurely from
> > this helper may lead to obscure
On Mon, Jun 13, 2016 at 01:22:15PM +0300, Jani Nikula wrote:
> 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
From: Tim Gore
This patch applies WaMtpRenderPowerGatingBug which
overcomes a hang during mid thread pre-emption when
running OCL test: test_allocations64.exe single 5 all.
Signed-off-by: Tim Gore
---
drivers/gpu/drm/i915/i915_reg.h | 5
drivers/gpu/drm/i915/intel_lrc.c | 52 +++
== Series Details ==
Series: drm/i915: Set softmin frequency on idle->busy transition
URL : https://patchwork.freedesktop.org/series/8790/
State : success
== Summary ==
Series 8790v1 drm/i915: Set softmin frequency on idle->busy transition
http://patchwork.freedesktop.org/api/1.0/series/8790/r
On Thu, Jun 16, 2016 at 05:19:49PM +0200, Michał Winiarski wrote:
> If the GPU load is low enough, it's possible that we'll be stuck at idle
> frequency rather than transition into softmin frequency requested by
> userspace.
> Since we assume that idle_freq <= min_freq_softlimit and
> valleyview_se
If the GPU load is low enough, it's possible that we'll be stuck at idle
frequency rather than transition into softmin frequency requested by
userspace.
Since we assume that idle_freq <= min_freq_softlimit and
valleyview_set_rps is already skipping write when
requested_freq == cur_freq we can also
== Series Details ==
Series: drm/i915/gen9: Add WaDisableGatherAtSetShaderCommonSlice
URL : https://patchwork.freedesktop.org/series/8788/
State : warning
== Summary ==
Series 8788v1 drm/i915/gen9: Add WaDisableGatherAtSetShaderCommonSlice
http://patchwork.freedesktop.org/api/1.0/series/8788/r
On Mon, Jun 13, 2016 at 01:22:14PM +0300, Jani Nikula wrote:
> In sequence block v3 these are gracefully skipped anyway, but add the
> functions so we can have some debug breadcrumbs.
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 16
> 1 fil
On Thu, Jun 16, 2016 at 05:39:35PM +0300, Imre Deak wrote:
> On to, 2016-06-16 at 16:58 +0300, Ville Syrjälä wrote:
> > On Thu, Jun 16, 2016 at 04:37:20PM +0300, Imre Deak wrote:
> > > The PPS registers are backed by power well #0 and as such may be reset
> > > after system or runtime suspend (both
Add WaDisableGatherAtSetShaderCommonSlice for all gen9 as stated
by bspec.
References: HSD#2135817
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_lrc.c | 7 +++
2 files changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h
Chris Wilson writes:
> On Wed, Jun 15, 2016 at 02:56:39PM +0300, Marius Vlad wrote:
>> On Mon, Jun 13, 2016 at 04:26:22PM +0300, Mika Kuoppala wrote:
>> > Don't add SOURCE_DIR to the path for gem_blt as if this
>> > script is invocated on some other directory, the path to
>> > gem_blt will be con
On to, 2016-06-16 at 16:58 +0300, Ville Syrjälä wrote:
> On Thu, Jun 16, 2016 at 04:37:20PM +0300, Imre Deak wrote:
> > The PPS registers are backed by power well #0 and as such may be reset
> > after system or runtime suspend (both implying a possible DC9
> > transition). Fix this by reusing the V
== Series Details ==
Series: drm/i915/bxt: Fix eDP link training after suspend
URL : https://patchwork.freedesktop.org/series/8783/
State : warning
== Summary ==
Series 8783v1 drm/i915/bxt: Fix eDP link training after suspend
http://patchwork.freedesktop.org/api/1.0/series/8783/revisions/1/mbo
On Thu, Jun 16, 2016 at 04:37:23PM +0300, Imre Deak wrote:
> The wait for panel status helper will only function correctly if the
> HW panel timings are programmed correctly. Returning prematurely from
> this helper may lead to obscure bugs later, so sanity check the HW
> timing registers.
>
> Sig
On Thu, Jun 16, 2016 at 04:37:20PM +0300, Imre Deak wrote:
> The PPS registers are backed by power well #0 and as such may be reset
> after system or runtime suspend (both implying a possible DC9
> transition). Fix this by reusing the VLV/CHV PPS pipe-reassignment
> logic. The difference on BXT is
On Thu, Jun 16, 2016 at 06:11:50PM +0530, Sharma, Shashank wrote:
> Regards
> Shashank
> On 6/8/2016 4:11 PM, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Now that eDP encoders won't have can_mst==true, we can throw out
> > the encoder type checks from the MST suspend/resum
No functional change.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_dp.c | 131
1 file changed, 65 insertions(+), 66 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 19a8bbe..3e875ff 100644
--- a
The wait for panel status helper will only function correctly if the
HW panel timings are programmed correctly. Returning prematurely from
this helper may lead to obscure bugs later, so sanity check the HW
timing registers.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_dp.c | 40 ++
This will be needed by the next patch too so factor it out.
No functional change.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_dp.c | 56 +++--
1 file changed, 32 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/driver
This fixes eDP link training errors I noticed on BXT after suspend to
ram and adds some HW sanity check to catch similar issues in the future.
Imre Deak (4):
drm/i915/bxt: Fix PPS lost state after suspend breaking eDP link
training
drm/i915: Deduplicate PPS register retrieval
drm/i915: F
The PPS registers are backed by power well #0 and as such may be reset
after system or runtime suspend (both implying a possible DC9
transition). Fix this by reusing the VLV/CHV PPS pipe-reassignment
logic. The difference on BXT is that the PPS instances are not pipe but
port (or more accurately pi
== Series Details ==
Series: Convert requests to use struct fence (rev7)
URL : https://patchwork.freedesktop.org/series/1068/
State : failure
== Summary ==
Series 1068v7 Convert requests to use struct fence
http://patchwork.freedesktop.org/api/1.0/series/1068/revisions/7/mbox
Test drv_module_
From: John Harrison
The change to the implementation of i915_gem_request_completed() means
that the lazy coherency flag is no longer used. This can now be
removed to simplify the interface.
v6: Updated to newer nightly and resolved conflicts.
v7: Updated to newer nightly (lots of ring -> engine
From: John Harrison
The intended usage model for struct fence is that the signalled status
should be set on demand rather than polled. That is, there should not
be a need for a 'signaled' function to be called everytime the status
is queried. Instead, 'something' should be done to enable a signal
From: John Harrison
Added the '_complete' trace event which occurs when a fence/request is
signaled as complete. Also moved the notify event from the IRQ handler
code to inside the notify function itself.
v3: Added the current ring seqno to the notify trace point.
v5: Line wrapping to keep the
From: John Harrison
There is a construct in the linux kernel called 'struct fence' that is
intended to keep track of work that is executed on hardware. I.e. it
solves the basic problem that the drivers 'struct
drm_i915_gem_request' is trying to address. The request structure does
quite a lot more
From: John Harrison
The purpose of this patch series is to convert the requst structure to
use fence objects for the underlying completion tracking. The fence
object requires a sequence number. The ultimate aim is to use the same
sequence number as for the request itself (or rather, to remove the
From: John Harrison
The notify function can be called many times without the seqno
changing. Some are to prevent races due to the requirement of not
enabling interrupts until requested. However, when interrupts are
enabled the IRQ handler can be called multiple times without the
ring's seqno valu
From: John Harrison
There is a construct in the linux kernel called 'struct fence' that is
intended to keep track of work that is executed on hardware. I.e. it
solves the basic problem that the drivers 'struct
drm_i915_gem_request' is trying to address. The request structure does
quite a lot more
Regards
Shashank
On 6/8/2016 4:11 PM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä
Now that eDP encoders won't have can_mst==true, we can throw out
the encoder type checks from the MST suspend/resume paths.
Cc: Dave Airlie
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i
The failure has been reported at:
https://bugs.freedesktop.org/show_bug.cgi?id=95236
> -Original Message-
> From: Patchwork [mailto:patchw...@emeril.freedesktop.org]
> Sent: Thursday, June 16, 2016 3:27 PM
> To: Wang, Zhi A
> Cc: intel-gfx@lists.freedesktop.org
> Subject: ✗ Ro.CI.BAT: fai
Reviewed-by: Shashank Sharma
Regards
Shashank
On 6/8/2016 4:11 PM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä
If we've determined that the encoder is eDP, we shouldn't try to use MST
on it. Or at least the code doesn't seem to expect that since there are
some type==DP checks in t
== Series Details ==
Series: Introduce the implementation of GVT context (rev10)
URL : https://patchwork.freedesktop.org/series/7208/
State : failure
== Summary ==
Series 7208v10 Introduce the implementation of GVT context
http://patchwork.freedesktop.org/api/1.0/series/7208/revisions/10/mbox
On 07/06/2016 13:47, Maarten Lankhorst wrote:
Op 01-06-16 om 19:07 schreef john.c.harri...@intel.com:
From: John Harrison
The notify function can be called many times without the seqno
changing. Some are to prevent races due to the requirement of not
enabling interrupts until requested. Howeve
Currently the addressing mode bit in context descriptor is statically
generated from the configuration of system-wide PPGTT usage model.
GVT-g will load the PPGTT shadow page table by itself and probably one
guest is using a different addressing mode with i915 host. The addressing
mode bits of a L
This patch introduces an approach to track the execlist context status
change.
GVT-g uses GVT context as the "shadow context". The content inside GVT
context will be copied back to guest after the context is idle. And GVT-g
has to know the status of the execlist context.
This function is configur
This patch introduces an option for configuring the ring buffer size
of a LRC context after the context creation.
v9:
- Fix an identation issue. (Chris)
v8:
- Rename the data member in i915_gem_context. (Chris)
Reviewed-by: Joonas Lahtinen
Cc: Joonas Lahtinen
Cc: Chris Wilson
Signed-off-by: Z
This patch introduces the very basic framework of GVT-g device model,
includes basic prototypes, definitions, initialization.
v12:
- Call intel_gvt_init() in driver early initialization stage. (Chris)
v8:
- Remove the GVT idr and mutex in intel_gvt_host. (Joonas)
v7:
- Refine the URL link in Kco
GVT workload scheduler needs special host LRC contexts, the so called
"shadow LRC context" to submit guest workload to host i915. During the
guest workload submission, workload scheduler fills the shadow LRC
context with the content of guest LRC context: engine context is copied
without changes, ri
As the PVINFO page definition is used by both GVT-g guest (vGPU) and GVT-g
host (GVT-g kernel device model), factor it out for better code structure.
v7:
- Split the "offsetof" modification into a dedicated patch. (Joonas)
v3:
- Use offsetof to calculate the member offset of PVINFO structure (Joo
v5:
- Let functions take struct drm_i915_private *. (Tvrtko)
- Fold vGPU related active check into the inner functions. (Kevin)
Reviewed-by: Tvrtko Ursulin
Reviewed-by: Joonas Lahtinen
Suggested-by: Kevin Tian
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
Cc: Kevin Tian
Signed-off-by: Zhi Wang
--
To get the offset of the members in PVINFO page, offsetof() looks much
better than the tricky approach in current code.
v7:
- Move "offsetof()" modification into a dedicated patch. (Joonas)
Suggested-by: Joonas Lahtinen
Reviewed-by: Joonas Lahtinen
Cc: Joonas Lahtinen
Signed-off-by: Zhi Wang
This patch introduces the support of LRC context single submission.
As GVT context may come from different guests, which require different
configuration of render registers. It can't be combined into a dual ELSP
submission combo.
Only GVT-g will create this kinds of GEM context currently.
v8:
-
This patchset introduces the implementation of GVT context. GVT
context is a special GEM context used by GVT-g. GVT-g uses it as the shadow
context.It doesn't have a drm client nor a PPGTT. And it requires a larger
ring buffer with several special features need by GVT-g workload scheduler
like cont
On Thu, Jun 16, 2016 at 10:49:17AM +0200, Michał Winiarski wrote:
> On Fri, Jun 03, 2016 at 05:36:31PM +0100, Chris Wilson wrote:
> > Make sure that the RPS bottom-half is flushed before we set the idle
> > frequency when we decide the GPU is idle. This should prevent any races
> > with the bottom-
The watermark means that how much is consumed from a full fifo for VLV/CHV.
From VLV spec, "Display Plane A FIFO Watermark: Number in 64Bs of space in FIFO
above which the Display A Stream
will generate requests to Memory"
It seems that smaller value should be picked to avoid FIFO underrun when
c
On Thu, Jun 16, 2016 at 11:20:31AM +0300, Mika Kuoppala wrote:
> Chris Wilson writes:
>
> > The kernel context exists simply as a placeholder and should never be
> > executed with a render context. It does not need the golden render
> > state, as that will always be applied to a user context. By
On Thu, Jun 16, 2016 at 11:51:03AM +0300, Mika Kuoppala wrote:
> > +++ b/drivers/gpu/drm/i915/i915_gem_evict.c
> > @@ -33,6 +33,37 @@
> > #include "intel_drv.h"
> > #include "i915_trace.h"
> >
> > +static int switch_to_pinned_context(struct drm_i915_private *dev_priv)
> > +{
>
> switch_to_kern
On Thu, Jun 16, 2016 at 12:15:05PM +0300, Mika Kuoppala wrote:
> Chris Wilson writes:
>
> > Select idle frequency during initialisation, then reset the last known
> > frequency when re-enabling. This allows us to preserve the user selected
> > frequency across resets.
> >
> > Signed-off-by: Chris
Chris Wilson writes:
> Select idle frequency during initialisation, then reset the last known
> frequency when re-enabling. This allows us to preserve the user selected
> frequency across resets.
>
> Signed-off-by: Chris Wilson
> Cc: ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_pm.c | 34 +
On Thu, Jun 16, 2016 at 09:34:05AM +0300, Jani Nikula wrote:
> On Wed, 15 Jun 2016, Chris Wilson wrote:
> > Allow everyone to call intel_panel_setup_backlight() (i.e. only take
> > effect if we have previously been initialised for use as a panel) and,
> > for paranoia, allow intel_panel_cleanup_ba
Chris Wilson writes:
> We only need to force a switch to the kernel context placeholder during
> eviction. All other uses of i915_gpu_idle() just want to wait until
> existing work on the GPU is idle. Rename i915_gpu_idle() to
> i915_gem_wait_for_idle() to avoid any implications about "parking" t
On Fri, Jun 03, 2016 at 05:36:31PM +0100, Chris Wilson wrote:
> Make sure that the RPS bottom-half is flushed before we set the idle
> frequency when we decide the GPU is idle. This should prevent any races
> with the bottom-half and setting the idle frequency, and ensures that
> the bottom-half is
Chris Wilson writes:
> The kernel context exists simply as a placeholder and should never be
> executed with a render context. It does not need the golden render
> state, as that will always be applied to a user context. By skipping the
> initialisation we can avoid issues in attempting to progra
On Wed, Jun 15, 2016 at 12:43:11PM +0100, Chris Wilson wrote:
> On Tue, Jun 14, 2016 at 08:51:01PM +0200, Daniel Vetter wrote:
> > Like with drm_master_open protect it with a check for primary_client
> > to make it clear that this can't happen on render/control nodes.
> >
> > Signed-off-by: Daniel
On Tue, 07 Jun 2016, Andrea Lorenzato wrote:
> we have same problem with a Intel NUC5CPYH, we have updated the
> firmware, we changed Linux distribution with the latest, also in terms
> of drivers, Ubuntu 16.04 LTS. We tried all the possible parameters on
> Linux xfreerdp client: change of bandwid
Hello,
I working on an embedded project with Minnowboard Turbot. The goal is
to have a camera application running as fast as possible (within 2
sec).
For this, I have replaced the UEFI bootloader with the U-boot (Latest
git version - uboot-x86). In u-boot I am seeing that the VGA run on
bios is t
78 matches
Mail list logo
