On Mon, 28 Nov 2016, "Anand, Jerome" wrote:
> Last time , it took close to 10 days when my patches were reflected on
> the gfx mailing list. Not sure what is the problem ?? Let me try
> sending it again ??
I guess the last time they only ever showed up because Ville bounced
them to the list after
On su, 2016-11-27 at 17:09 +, Chris Wilson wrote:
> smatch correctly warns:
>
> drivers/gpu/drm/drm_fb_helper.c:1960 drm_target_preferred() warn:
> should '1 << i' be a 64 bit type?
> drivers/gpu/drm/drm_fb_helper.c:2001 drm_target_preferred() warn:
> should '1 << i' be a 64 bit
On Mon, Nov 28, 2016 at 08:55:58AM +0100, Daniel Vetter wrote:
> On Wed, Nov 23, 2016 at 02:04:17PM +, Chris Wilson wrote:
> > Though we only walk the kernel_fb_helper_list inside a panic (or single
> > thread debugging), we still need to protect the list manipulation on
> > creating/removing a
On Mon, Nov 28, 2016 at 08:48:34AM +0100, Daniel Vetter wrote:
> On Fri, Nov 25, 2016 at 03:32:31PM +, Chris Wilson wrote:
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -1253,7 +1253,7 @@ drm_atomic_set_fb_for_plane(struct drm_plane_state
> > *plane_state
On su, 2016-11-27 at 19:05 +, Chris Wilson wrote:
> In places (e.g. i915.ko), the alignment is exported to userspace as u64
> and there now exists hardware for which we can indeed utilize a u64
> alignment. As such, we need to keep 64bit integers throughout when
> handling alignment.
>
> Testc
Pretend to run on a non-intel machine even when running on i915.ko,
so that we could run and gather passrate data.
Signed-off-by: Abdiel Janulgue
---
lib/drmtest.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/lib/drmtest.c b/lib/drmtest.c
index 44abc7e..a8b75e8 100644
On Mon, 28 Nov 2016, Jairo Miramontes
wrote:
> Total regressions: 47
Repeating my earlier request, please share a fdo bugzilla query link
where anyone can get the results in bugzilla.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
___
Hi,
In linux-4.8.11, I get the following in my dmesg (and a
20-second delay):
[1.932295] Linux agpgart interface v0.103
[1.932448] [drm] Initialized drm 1.1.0 20060810
[1.932799] pci :00:00.0: Intel 965GME/GLE Chipset
[1.932902] pci :00:00.0: detected gtt size: 524288K tot
Commit eaf0 has been causing multiple problems for i915 users. See for
example:
https://bugs.freedesktop.org/show_bug.cgi?id=96781
https://bugs.freedesktop.org/show_bug.cgi?id=97529
https://bugzilla.redhat.com/show_bug.cgi?id=1385228
https://forums.opensuse.org/showthread.php/520969-drm-915-Re
On Mon, 28 Nov 2016, Ali Gholami Rudi wrote:
> In linux-4.8.11, I get the following in my dmesg (and a
> 20-second delay):
Please file a bug at [1].
BR,
Jani.
[1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI&component=DRM/Intel
--
Jani Nikula, Intel Open Source Technology Center
___
On 14/11/2016 11:45, Tvrtko Ursulin wrote:
Hi Andrew,
On 11/11/2016 08:50, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Userptr backing store with SWIOTBL active is currently allocated in
the same
inefficient manner, with one sg entry per object page, as what the commit
871dfbd67d4e ("drm/i91
We grab the struct_mutex in intel_crtc_page_flip, but if we are wedged
or a reset is in progress we bail early but never seem to actually
release the lock.
Fixes: 7f1847ebf48b ("drm/i915: Simplify checking of GPU reset_counter in
display pageflips")
Cc: Chris Wilson
Signed-off-by: Matthew Auld
Am 27.11.2016 um 20:05 schrieb Chris Wilson:
In places (e.g. i915.ko), the alignment is exported to userspace as u64
and there now exists hardware for which we can indeed utilize a u64
alignment. As such, we need to keep 64bit integers throughout when
handling alignment.
Testcase: igt/drm_mm/ali
On 11/23/2016 10:02 PM, Chris Wilson wrote:
On Wed, Nov 23, 2016 at 09:48:23PM +0530, Animesh Manna wrote:
Guid is changed for bxt platform, so corrected the guid for bxt.
v1: Initial version as RFC.
v2: Based on review comment from Jani and David,
have kept guid as binary format.
Signed-of
== Series Details ==
Series: drm/i915: drop the struct_mutex when wedged or trying to reset
URL : https://patchwork.freedesktop.org/series/16024/
State : success
== Summary ==
Series 16024v1 drm/i915: drop the struct_mutex when wedged or trying to reset
https://patchwork.freedesktop.org/api/1.
On pe, 2016-11-25 at 11:44 +, Chris Wilson wrote:
> On Fri, Nov 25, 2016 at 01:30:38PM +0200, Ville Syrjälä wrote:
> > On Fri, Nov 25, 2016 at 12:57:01PM +0200, Imre Deak wrote:
> > > commit 848496e5902833600f7992f4faa82dc1546051ba
> > > Author: Ville Syrjälä
> > > Date: Wed Jul 13 16:32:03
commit 848496e5902833600f7992f4faa82dc1546051ba
Author: Ville Syrjälä
Date: Wed Jul 13 16:32:03 2016 +0300
drm/i915: Wait up to 3ms for the pcu to ack the cdclk change request on SKL
increased the timeout to match the spec, but we still see a timeout on
at least one SKL. A CDCLK change req
According to the previous patch, it's possible atm that we call
intel_do_sagv_disable() only once during the 1ms period and time out if
that call fails. As opposed to this the spec says that we need to keep
retrying this request for a 1ms duration, so let's do this similarly to
the CDCLK change not
The spec calls for the upper data byte to be cleared before most of the
PCODE write commands, for others like IPS control it doesn't say
anything about this byte. Let's clear it in case it's clobbered somehow,
especially that there are places where we only do a PCODE write without
a preceeding PCOD
On 25/11/2016 09:30, Chris Wilson wrote:
i915_guc_info() (part of debugfs output) tries to avoid holding
struct_mutex for a long period by copying onto the stack. This causes a
warning that the stack frame is massive, so stop doing that. We can even
forgo holding the struct_mutex here as that do
On ma, 2016-11-28 at 10:36 +, Matthew Auld wrote:
> We grab the struct_mutex in intel_crtc_page_flip, but if we are wedged
> or a reset is in progress we bail early but never seem to actually
> release the lock.
>
> Fixes: 7f1847ebf48b ("drm/i915: Simplify checking of GPU reset_counter in
> d
On Mon, Nov 21, 2016 at 12:30:01PM +, Chris Wilson wrote:
>
> I was looking at how we get out of the pm_runtime mess. In part, we hurt
> ourselves because we are using wakeref_count to disable asserts, but it
> also seems that pushing the optimisation to pm_runtime is the right
> thing to do.
On Mon, 28 Nov 2016, Animesh Manna wrote:
> On 11/23/2016 10:02 PM, Chris Wilson wrote:
>> On Wed, Nov 23, 2016 at 09:48:23PM +0530, Animesh Manna wrote:
>>> Guid is changed for bxt platform, so corrected the guid for bxt.
>>>
>>> v1: Initial version as RFC.
>>>
>>> v2: Based on review comment fro
Update all nightly repos that have a corresponding local remote.
Cc: Archit Taneja
Signed-off-by: Jani Nikula
---
dim | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/dim b/dim
index a709342572ab..3dd2d1dec796 100755
--- a/dim
+++ b/dim
@@ -1255,8 +1255,15 @@ function
On Mon, Nov 28, 2016 at 11:15:27AM +, Tvrtko Ursulin wrote:
>
> On 25/11/2016 09:30, Chris Wilson wrote:
> >i915_guc_info() (part of debugfs output) tries to avoid holding
> >struct_mutex for a long period by copying onto the stack. This causes a
> >warning that the stack frame is massive, so
On 25/11/2016 09:30, Chris Wilson wrote:
The client->cookie is a shadow of the doorbell->cookie value, so rename
it to indicate its association with the doorbell, like the doorbell id
and offset.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c| 2 +-
drivers/gpu/dr
On Mon, 28 Nov 2016, Joonas Lahtinen wrote:
> On ma, 2016-11-28 at 10:36 +, Matthew Auld wrote:
>> We grab the struct_mutex in intel_crtc_page_flip, but if we are wedged
>> or a reset is in progress we bail early but never seem to actually
>> release the lock.
>>
>> Fixes: 7f1847ebf48b ("drm/
From: Arkadiusz Hiler
Cc: Chris Wilson
Cc: Michal Winiarski
Signed-off-by: Arkadiusz Hiler
Reviewed-by: Chris Wilson
Link:
http://patchwork.freedesktop.org/patch/msgid/1480096777-12573-6-git-send-email-arkadiusz.hi...@intel.com
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_guc_
From: Arkadiusz Hiler
send_mutex is used to serialise communication with GuC via
intel_guc_send().
Since functions that utilize it are no longer limited to submission,
initialization should be handled as a part of general setup.
v2: move initialization to *_early()
Cc: Chris Wilson
Cc: Michal
From: Arkadiusz Hiler
GuC is not the only one micro controller we have.
There are also HuC and DMC.
Making the file more general will help with code organization.
Cc: Chris Wilson
Cc: Michal Winiarski
Signed-off-by: Arkadiusz Hiler
Reviewed-by: Chris Wilson
Signed-off-by: Chris Wilson
Lin
From: Arkadiusz Hiler
guc_send(), guc_recv() and related functions were introduced in the
i915_guc_submission.c and their scope was limited only to that file.
Those are not submission specific though.
This patch moves moves them to intel_uc.c with intel_ prefix added.
v2: rename intel_guc_log_*
From: Arkadiusz Hiler
To facilitate code reorganization we are renaming everything that
contains guc2host or host2guc.
host2guc_action() and host2guc_action_response() become guc_send()
and guc_recv() respectively.
Other host2guc_*() functions become simply guc_*().
Other entities are renamed
== Series Details ==
Series: series starting with [v3,1/3] drm/i915/gen6+: Clear upper data byte
during PCODE write
URL : https://patchwork.freedesktop.org/series/16028/
State : failure
== Summary ==
Series 16028v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/1
Op 28-11-16 om 10:37 schreef Abdiel Janulgue:
> Pretend to run on a non-intel machine even when running on i915.ko,
> so that we could run and gather passrate data.
> Signed-off-by: Abdiel Janulgue
> ---
> lib/drmtest.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a
On 25/11/2016 09:30, Chris Wilson wrote:
Set the initial value of the doorbell cookie from the client.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_guc_submission.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/d
On ma, 2016-11-28 at 13:40 +0200, Jani Nikula wrote:
> > On Mon, 28 Nov 2016, Joonas Lahtinen
> > wrote:
> >
> > Cc: stable # v4.6 ?
>
> $ dim fixes 7f1847ebf48b
> Fixes: 7f1847ebf48b ("drm/i915: Simplify checking of GPU reset_counter in
> display pageflips")
> Cc: Chris Wilson
> Cc: Daniel Ve
From: Libin Yang
Add the DP MST info dump in debugfs.
Signed-off-by: Libin Yang
Signed-off-by: Dhinakaran Pandiyan
Reviewed-by: Lyude
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_debugfs.c | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/d
From: Libin Yang
Prepare for using the same code for judging ddi being audio enabled.
No functional changes.
Signed-off-by: Libin Yang
Signed-off-by: Dhinakaran Pandiyan
Reviewed-by: Lyude
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_ddi.c | 20 +++-
drivers/gp
From: Libin Yang
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 DP MST audio will be implemented
in audio driver.
Th
== Series Details ==
Series: GuC code reorganization (rev7)
URL : https://patchwork.freedesktop.org/series/15896/
State : success
== Summary ==
Series 15896v7 GuC code reorganization
https://patchwork.freedesktop.org/api/1.0/series/15896/revisions/7/mbox/
Test kms_pipe_crc_basic:
Subg
On 28/11/2016 11:35, Chris Wilson wrote:
On Mon, Nov 28, 2016 at 11:15:27AM +, Tvrtko Ursulin wrote:
On 25/11/2016 09:30, Chris Wilson wrote:
i915_guc_info() (part of debugfs output) tries to avoid holding
struct_mutex for a long period by copying onto the stack. This causes a
warning tha
On Mon, Nov 28, 2016 at 12:09:38PM +, Tvrtko Ursulin wrote:
>
> On 25/11/2016 09:30, Chris Wilson wrote:
> >Set the initial value of the doorbell cookie from the client.
> >
> >Signed-off-by: Chris Wilson
> >---
> > drivers/gpu/drm/i915/i915_guc_submission.c | 2 +-
> > 1 file changed, 1 inser
On Mon, Nov 28, 2016 at 01:07:36PM +0100, Maarten Lankhorst wrote:
> Op 28-11-16 om 10:37 schreef Abdiel Janulgue:
> > Pretend to run on a non-intel machine even when running on i915.ko,
> > so that we could run and gather passrate data.
What exactly do you mean?
> > Signed-off-by: Abdiel Janulgu
On 11/28/2016 05:03 PM, Jani Nikula wrote:
Update all nightly repos that have a corresponding local remote.
Cc: Archit Taneja
Signed-off-by: Jani Nikula
Tested-by: Archit Taneja
---
dim | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/dim b/dim
index a7093425
== Series Details ==
Series: series starting with [CI,1/5] drm/i915: Rename intel_guc.h to intel_uc.h
URL : https://patchwork.freedesktop.org/series/16034/
State : warning
== Summary ==
Series 16034v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/16034/revisions/
Hi,
Will keep WA number in commit message/WA location.
thanks,
Regards,
-Mahesh
On Thursday 24 November 2016 06:21 PM, Lankhorst, Maarten wrote:
Mahesh Kumar schreef op do 24-11-2016 om 09:31 [+0530]:
If IPC is enabled in BXT, display underruns are observed.
WA: The Line Time programmed in t
On Mon, Nov 28, 2016 at 12:53:27PM +, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [CI,1/5] drm/i915: Rename intel_guc.h to
> intel_uc.h
> URL : https://patchwork.freedesktop.org/series/16034/
> State : warning
>
> == Summary ==
>
> Series 16034v1 Series withou
On 11/23/2016 10:31 PM, Imre Deak wrote:
On Wed, 2016-11-23 at 21:48 +0530, Animesh Manna wrote:
While suspending the device hpd related interrupts are enabled
to get the interrupt when device is in suspend state.
Though display is in DC9 but system can be in S0 or S0i3 state.
Hot plug during
On Sun, Nov 27, 2016 at 12:20:30PM -0600, Pierre-Louis Bossart wrote:
> On 11/24/16 7:31 AM, Ville Syrjälä wrote:
> >> +static void lpe_audio_irq_unmask(struct irq_data *d)
> >> +{
> >> + struct drm_device *dev = d->chip_data;
> >> + struct drm_i915_private *dev_priv = to_i915(dev);
> >> + unsig
On 25/11/2016 09:30, Chris Wilson wrote:
In order to avoid some complexity in trying to reconstruct the
workqueues across reset, remember them instead. The issue comes when we
have to handle a reset between request allocation and submission, the
request has reserved space in the wq, but is not i
On Mon, Nov 28, 2016 at 01:12:57PM +0200, Imre Deak wrote:
> commit 848496e5902833600f7992f4faa82dc1546051ba
> Author: Ville Syrjälä
> Date: Wed Jul 13 16:32:03 2016 +0300
>
> drm/i915: Wait up to 3ms for the pcu to ack the cdclk change request on
> SKL
>
> increased the timeout to match
On ma, 2016-11-28 at 15:51 +0200, Ville Syrjälä wrote:
> On Mon, Nov 28, 2016 at 01:12:57PM +0200, Imre Deak wrote:
> > commit 848496e5902833600f7992f4faa82dc1546051ba
> > Author: Ville Syrjälä
> > Date: Wed Jul 13 16:32:03 2016 +0300
> >
> > drm/i915: Wait up to 3ms for the pcu to ack the
On Fri, Nov 25, 2016 at 05:51:00AM +, Anand, Jerome wrote:
>
>
> > -Original Message-
> > From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> > Sent: Thursday, November 24, 2016 7:03 PM
> > To: Anand, Jerome
> > Cc: intel-gfx@lists.freedesktop.org; alsa-de...@alsa-project.or
On 25/11/2016 09:30, Chris Wilson wrote:
Something I missed before sending off the partial series was that the
non-scheduler guc reset path was broken (in the full series, this is
pushed to the execlists reset handler). The issue is that after a reset,
we have to refill the GuC workqueues, which
On Mon, Nov 28, 2016 at 03:54:08PM +0200, Imre Deak wrote:
> On ma, 2016-11-28 at 15:51 +0200, Ville Syrjälä wrote:
> > On Mon, Nov 28, 2016 at 01:12:57PM +0200, Imre Deak wrote:
> > > commit 848496e5902833600f7992f4faa82dc1546051ba
> > > Author: Ville Syrjälä
> > > Date: Wed Jul 13 16:32:03 201
On Mon, Nov 28, 2016 at 04:06:05PM +0200, Ville Syrjälä wrote:
> On Mon, Nov 28, 2016 at 03:54:08PM +0200, Imre Deak wrote:
> > On ma, 2016-11-28 at 15:51 +0200, Ville Syrjälä wrote:
> > > On Mon, Nov 28, 2016 at 01:12:57PM +0200, Imre Deak wrote:
> > > > commit 848496e5902833600f7992f4faa82dc15460
On Mon, Nov 28, 2016 at 01:49:03PM +, Tvrtko Ursulin wrote:
>
> On 25/11/2016 09:30, Chris Wilson wrote:
> >In order to avoid some complexity in trying to reconstruct the
> >workqueues across reset, remember them instead. The issue comes when we
> >have to handle a reset between request alloca
On Mon, Nov 28, 2016 at 08:46:11AM +, Chris Wilson wrote:
> On Mon, Nov 28, 2016 at 08:48:34AM +0100, Daniel Vetter wrote:
> > On Fri, Nov 25, 2016 at 03:32:31PM +, Chris Wilson wrote:
> > > --- a/drivers/gpu/drm/drm_atomic.c
> > > +++ b/drivers/gpu/drm/drm_atomic.c
> > > @@ -1253,7 +1253,7
On Mon, Nov 28, 2016 at 08:38:21AM +, Chris Wilson wrote:
> On Mon, Nov 28, 2016 at 08:55:58AM +0100, Daniel Vetter wrote:
> > On Wed, Nov 23, 2016 at 02:04:17PM +, Chris Wilson wrote:
> > > Though we only walk the kernel_fb_helper_list inside a panic (or single
> > > thread debugging), we
On Mon, Nov 28, 2016 at 02:02:33PM +, Tvrtko Ursulin wrote:
>
> On 25/11/2016 09:30, Chris Wilson wrote:
> >Something I missed before sending off the partial series was that the
> >non-scheduler guc reset path was broken (in the full series, this is
> >pushed to the execlists reset handler). T
On ma, 2016-11-28 at 16:11 +0200, Ville Syrjälä wrote:
> On Mon, Nov 28, 2016 at 04:06:05PM +0200, Ville Syrjälä wrote:
> > On Mon, Nov 28, 2016 at 03:54:08PM +0200, Imre Deak wrote:
> > > On ma, 2016-11-28 at 15:51 +0200, Ville Syrjälä wrote:
> > > > On Mon, Nov 28, 2016 at 01:12:57PM +0200, Imre
This reverts commit 27745e829a5c ("drm/i915/execlists: Use a local lock
for dfs_link access") as the struct_mutex was required to prevent
concurrent retiring and freeing, now restored in the previous patch.
Signed-off-by: Chris Wilson
Cc: David Weinehall
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/
On ma, 2016-11-28 at 19:09 +0530, Animesh Manna wrote:
>
> On 11/23/2016 10:31 PM, Imre Deak wrote:
> > On Wed, 2016-11-23 at 21:48 +0530, Animesh Manna wrote:
> > > While suspending the device hpd related interrupts are enabled
> > > to get the interrupt when device is in suspend state.
> > >
>
David found another issue with priority bumping from mmioflips, where we
are accessing the requests concurrently to them being retired and freed.
Whilst we are skipping the dependency if has been submitted, that is not
sufficient to stop the dependency from disappearing if another thread
retires th
On Mon, Nov 28, 2016 at 03:15:12PM +0100, Daniel Vetter wrote:
> On Mon, Nov 28, 2016 at 08:46:11AM +, Chris Wilson wrote:
> > On Mon, Nov 28, 2016 at 08:48:34AM +0100, Daniel Vetter wrote:
> > > On Fri, Nov 25, 2016 at 03:32:31PM +, Chris Wilson wrote:
> > > > --- a/drivers/gpu/drm/drm_ato
== Series Details ==
Series: series starting with [1/3] drm/i915/debugfs: add dp mst info
URL : https://patchwork.freedesktop.org/series/16036/
State : success
== Summary ==
Series 16036v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/16036/revisions/1/mbox/
fi
On Mon, Nov 28, 2016 at 08:26:07AM +0100, Daniel Vetter wrote:
> On Wed, Nov 23, 2016 at 02:04:15PM +, Chris Wilson wrote:
> > +#define drm_fb_helper_for_each_connector(fbh, i__) \
> > + for (({lockdep_assert_held(&(fbh)->dev->mode_config.mutex); 1;}), \
> > +i__ = 0; i__ < (fbh)->con
== Series Details ==
Series: series starting with [1/2] drm/i915: Move priority bumping for flips
earlier
URL : https://patchwork.freedesktop.org/series/16043/
State : success
== Summary ==
Series 16043v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/16043/revis
Chris Wilson writes:
> On Mon, Nov 28, 2016 at 02:02:33PM +, Tvrtko Ursulin wrote:
>>
>> On 25/11/2016 09:30, Chris Wilson wrote:
>> >Something I missed before sending off the partial series was that the
>> >non-scheduler guc reset path was broken (in the full series, this is
>> >pushed to t
According to the previous patch, it's possible atm that we call
intel_do_sagv_disable() only once during the 1ms period and time out if
that call fails. As opposed to this the spec says that we need to keep
retrying this request for a 1ms duration, so let's do this similarly to
the CDCLK change not
commit 848496e5902833600f7992f4faa82dc1546051ba
Author: Ville Syrjälä
Date: Wed Jul 13 16:32:03 2016 +0300
drm/i915: Wait up to 3ms for the pcu to ack the cdclk change request on SKL
increased the timeout to match the spec, but we still see a timeout on
at least one SKL. A CDCLK change req
The spec calls for the upper data byte to be cleared before most of the
PCODE write commands, for others like IPS control it doesn't say
anything about this byte. Let's clear it in case it's clobbered somehow,
especially that there are places where we only do a PCODE write without
a preceeding PCOD
On Mon, Nov 28, 2016 at 02:44:15PM +, Chris Wilson wrote:
> On Mon, Nov 28, 2016 at 03:15:12PM +0100, Daniel Vetter wrote:
> > On Mon, Nov 28, 2016 at 08:46:11AM +, Chris Wilson wrote:
> > > On Mon, Nov 28, 2016 at 08:48:34AM +0100, Daniel Vetter wrote:
> > > > On Fri, Nov 25, 2016 at 03:32
On 28/11/2016 14:11, Chris Wilson wrote:
On Mon, Nov 28, 2016 at 01:49:03PM +, Tvrtko Ursulin wrote:
On 25/11/2016 09:30, Chris Wilson wrote:
In order to avoid some complexity in trying to reconstruct the
workqueues across reset, remember them instead. The issue comes when we
have to hand
== Series Details ==
Series: series starting with [v4,1/3] drm/i915/gen6+: Clear upper data byte
during PCODE write
URL : https://patchwork.freedesktop.org/series/16046/
State : success
== Summary ==
Series 16046v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/1
On 11/23/2016 10:40 PM, Ville Syrjälä wrote:
On Wed, Nov 23, 2016 at 09:48:27PM +0530, Animesh Manna wrote:
While suspending the device hpd related interrupts are enabled
to get the interrupt when device is in suspend state.
Though display is in DC9 but system can be in S0 or S0i3 state.
Hot
On 28/11/2016 14:19, Chris Wilson wrote:
On Mon, Nov 28, 2016 at 02:02:33PM +, Tvrtko Ursulin wrote:
On 25/11/2016 09:30, Chris Wilson wrote:
Something I missed before sending off the partial series was that the
non-scheduler guc reset path was broken (in the full series, this is
pushed t
On Mon, Nov 28, 2016 at 05:29:28PM +0200, Imre Deak wrote:
> commit 848496e5902833600f7992f4faa82dc1546051ba
> Author: Ville Syrjälä
> Date: Wed Jul 13 16:32:03 2016 +0300
>
> drm/i915: Wait up to 3ms for the pcu to ack the cdclk change request on
> SKL
>
> increased the timeout to match
On Mon, Nov 28, 2016 at 03:44:41PM +, Tvrtko Ursulin wrote:
>
> On 28/11/2016 14:11, Chris Wilson wrote:
> >On Mon, Nov 28, 2016 at 01:49:03PM +, Tvrtko Ursulin wrote:
> >>
> >>On 25/11/2016 09:30, Chris Wilson wrote:
> >>>In order to avoid some complexity in trying to reconstruct the
> >>
On Mon, Nov 28, 2016 at 09:19:36PM +0530, Animesh Manna wrote:
>
>
> On 11/23/2016 10:40 PM, Ville Syrjälä wrote:
> > On Wed, Nov 23, 2016 at 09:48:27PM +0530, Animesh Manna wrote:
> >> While suspending the device hpd related interrupts are enabled
> >> to get the interrupt when device is in susp
On Mon, Nov 28, 2016 at 03:55:42PM +, Tvrtko Ursulin wrote:
>
> On 28/11/2016 14:19, Chris Wilson wrote:
> >On Mon, Nov 28, 2016 at 02:02:33PM +, Tvrtko Ursulin wrote:
> >>
> >>On 25/11/2016 09:30, Chris Wilson wrote:
> >>>Something I missed before sending off the partial series was that t
On 11/23/2016 11:47 PM, Ville Syrjälä wrote:
On Wed, Nov 23, 2016 at 09:48:25PM +0530, Animesh Manna wrote:
_DSM is added to program HPD_CTL(0x1094) register
of PMC from i915 driver which will be called
based on driver feature flag. PMC hpd control register
programming will enable PMC to get h
On ma, 2016-11-28 at 17:58 +0200, Ville Syrjälä wrote:
> On Mon, Nov 28, 2016 at 05:29:28PM +0200, Imre Deak wrote:
> > commit 848496e5902833600f7992f4faa82dc1546051ba
> > Author: Ville Syrjälä
> > Date: Wed Jul 13 16:32:03 2016 +0300
> >
> > drm/i915: Wait up to 3ms for the pcu to ack the
On 11/28/2016 4:54 PM, Jani Nikula wrote:
On Mon, 28 Nov 2016, Animesh Manna wrote:
On 11/23/2016 10:02 PM, Chris Wilson wrote:
On Wed, Nov 23, 2016 at 09:48:23PM +0530, Animesh Manna wrote:
Guid is changed for bxt platform, so corrected the guid for bxt.
v1: Initial version as RFC.
v2: B
On Mon, Nov 28, 2016 at 06:12:51PM +0200, Imre Deak wrote:
> On ma, 2016-11-28 at 17:58 +0200, Ville Syrjälä wrote:
> > On Mon, Nov 28, 2016 at 05:29:28PM +0200, Imre Deak wrote:
> > > commit 848496e5902833600f7992f4faa82dc1546051ba
> > > Author: Ville Syrjälä
> > > Date: Wed Jul 13 16:32:03 201
On Mon, Nov 28, 2016 at 09:36:51PM +0530, Animesh Manna wrote:
>
>
> On 11/23/2016 11:47 PM, Ville Syrjälä wrote:
> > On Wed, Nov 23, 2016 at 09:48:25PM +0530, Animesh Manna wrote:
> >> _DSM is added to program HPD_CTL(0x1094) register
> >> of PMC from i915 driver which will be called
> >> based
commit 848496e5902833600f7992f4faa82dc1546051ba
Author: Ville Syrjälä
Date: Wed Jul 13 16:32:03 2016 +0300
drm/i915: Wait up to 3ms for the pcu to ack the cdclk change request on SKL
increased the timeout to match the spec, but we still see a timeout on
at least one SKL. A CDCLK change req
> -Original Message-
> From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> Sent: Monday, November 28, 2016 7:30 PM
> To: Anand, Jerome
> Cc: intel-gfx@lists.freedesktop.org; alsa-de...@alsa-project.org;
> broo...@kernel.org; ti...@suse.de; pierre-louis.boss...@linux.intel.com;
>
On Mon, Nov 28, 2016 at 04:50:15PM +, Anand, Jerome wrote:
>
>
> > -Original Message-
> > From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> > Sent: Monday, November 28, 2016 7:30 PM
> > To: Anand, Jerome
> > Cc: intel-gfx@lists.freedesktop.org; alsa-de...@alsa-project.org;
On Mon, Nov 28, 2016 at 06:40:33PM +0200, Imre Deak wrote:
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 66c62f3..4e06e92 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -7864,6 +7864,59 @@ int sandybridge_pcode_
== Series Details ==
Series: series starting with [v4,1/3] drm/i915/gen6+: Clear upper data byte
during PCODE write (rev2)
URL : https://patchwork.freedesktop.org/series/16046/
State : success
== Summary ==
Series 16046v2 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/s
From: Ville Syrjälä
A decent pile of prep work split off from my VLV/CHV atomic watermark
work. Mostly VLV/CHV specific stuff, but there are a few small things
in there that touch other platforms as well.
Entire series available here:
git://github.com/vsyrjala/linux.git vlv_atomic_wm_prep
Ville
From: Ville Syrjälä
The watermark should never exceed the FIFO size, so we need to
check against the current FIFO size instead of the theoretical
maximum when we clamp the level 0 watermark.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 4 ++--
1 file changed, 2 insertions
From: Ville Syrjälä
HSW+ all use the .initial_watermarks() hook, so there's no point in
calling intel_update_watermarks() from HSW+ specific code. We'll still
hang on to the .initial_watermarks NULL check since theoretically if the
memory latencies are not populated we would not populate the func
From: Ville Syrjälä
Store the vlv/chv watermark values in straight up arrays indexed by
enum plane_id. Avoids a lot of useless checks for the plane type when
we don't have to think which structure member we need to access.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.h | 16
From: Ville Syrjälä
On VLV/CHV some of the watermark values are split across two registers:
low order bits in one, and high order bits in another. So we may not be
able to update a single watermark value atomically, and thus we must be
careful that we don't temporarily introduce out of bounds val
From: Ville Syrjälä
The code for vlv and chv wm latency/function pointer setup is
identical. Drop one of the copies.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/driver
From: Ville Syrjälä
ilk_disable_lp_wm() will tell us whether the LP1+ watermarks were
disabled or not, and hence whether we need to for the vblank wait or
not. Let's use that information to eliminate some useless vblank
waits.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display
From: Ville Syrjälä
Pasing dev_priv instead of dev is the future. Let's make the vlv/chv wm
functions respect that idea.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 24 +++-
1 file changed, 11 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/d
From: Ville Syrjälä
Each DSPARB register can house bits for two separate pipes, hence
we must protect the registers during reprogramming so that parallel
FIFO reconfigurations happening simultaneosly on multiple pipes won't
corrupt each others values.
Signed-off-by: Ville Syrjälä
---
drivers/g
1 - 100 of 126 matches
Mail list logo
