This is unusual. Usually IDs listed on early stages of platform
definition are kept there as reserved for later use.
However these IDs here are not listed anymore in any of steppings
and devices IDs tables for Kabylake on configurations overview
section of BSpec.
So it is better removing them bef
The spec has been updated adding new PCI IDs.
In parity with kernel:
commit 33d9391d3020e069dca98fa87a604c037beb2b9e
Author: Rodrigo Vivi
Date: Thu Jun 23 14:50:35 2016 -0700
drm/i915: Add more Kabylake PCI IDs.
Cc: Chris Wilson
Reviewed-by: Dhinakaran Pandiyan
Signed-off-by: Rodrigo Vi
I don't believe we need to be that extreme here.
Daniel asked a cleaner version, but we don't need to block the huc on
a full rework of an unified fw loader.
On Tue, Jun 28, 2016 at 8:45 AM, Dave Gordon wrote:
> On 28/06/16 15:54, Dave Gordon wrote:
>>
>> On 21/06/16 19:11, Peter Antoine wrote:
On Thu, 2016-06-23 at 14:50 -0700, Rodrigo Vivi wrote:
> This is unusual. Usually IDs listed on early stages of platform
> definition are kept there as reserved for later use.
>
> However these IDs here are not listed anymore in any of steppings
> and devices IDs tables for Kabylake on configurati
Does anyone have any sample code or demo applications for VDBOX/VEBOX?
Are these the only documents on how to use the Media VDBOX and VEBOX?
https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc-skl-vol08-media_vdbox.pdf
https://01.org/sites/default/files/documentation/intel-gfx-prm
On Thu, 2016-06-23 at 14:50 -0700, Rodrigo Vivi wrote:
> This is unusual. Usually IDs listed on early stages of platform
> definition are kept there as reserved for later use.
>
> However these IDs here are not listed anymore in any of steppings
> and devices IDs tables for Kabylake on configurati
On Thu, 2016-06-23 at 14:50 -0700, Rodrigo Vivi wrote:
> The spec has been updated adding new PCI IDs.
>
> Signed-off-by: Rodrigo Vivi
> ---
> include/pci_ids/i965_pci_ids.h | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/include/pci_ids/i965_pci_ids.h b/include/pci_ids/i965_pci_ids
On Thu, 2016-06-23 at 14:50 -0700, Rodrigo Vivi wrote:
> This is unusual. Usually IDs listed on early stages of platform
> definition are kept there as reserved for later use.
>
> However these IDs here are not listed anymore in any of steppings
> and devices IDs tables for Kabylake on configurati
On Thu, 2016-06-23 at 14:50 -0700, Rodrigo Vivi wrote:
> - INTEL_VGA_DEVICE(0x5932, info), /* DT GT4 */ \
> - INTEL_VGA_DEVICE(0x593B, info), /* Halo GT4 */ \
> - INTEL_VGA_DEVICE(0x593A, info), /* SRV GT4 */ \
> - INTEL_VGA_DEVICE(0x593D, info) /* WKS GT4
Reviewed-by: D
On Tue, Jun 28, 2016 at 09:51:34AM -0700, Bob Paauwe wrote:
> On Tue, 28 Jun 2016 16:47:28 +0100
> Chris Wilson wrote:
>
> > On Tue, Jun 28, 2016 at 08:42:01AM -0700, Bob Paauwe wrote:
> > > When fbdev emulation is disabled it is not a good idea to call into
> > > the core fb_set_suspend() functi
On Tue, Jun 28, 2016 at 05:20:43PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> usleep_range is not recommended for waits shorten than 10us.
>
> Make the wait_for_us use the atomic variant for such waits.
>
> To do so we need to reimplement the _wait_for_atomic macro to
> be safe wit
On Tue, Jun 28, 2016 at 05:03:20PM -, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [1/2] drm/i915/debug: Select PREEMPT_COUNT when
> enabling debugging (rev3)
> URL : https://patchwork.freedesktop.org/series/9226/
> State : success
>
> == Summary ==
>
> Series
On Mon, 2016-06-27 at 17:10 -0700, Rodrigo Vivi wrote:
> The spec has been updated adding new PCI IDs.
>
> v2: Avoid using "H" instead of HALO to keep names uniform - DK.
>
> Cc: Dhinakaran Pandiyan
> Signed-off-by: Rodrigo Vivi
> ---
> intel/intel_chipset.h | 14 ++
> 1 file chang
On Mon, 2016-06-27 at 17:10 -0700, Rodrigo Vivi wrote:
> This is unusual. Usually IDs listed on early stages of platform
> definition are kept there as reserved for later use.
>
> However these IDs here are not listed anymore in any of steppings
> and devices IDs tables for Kabylake on configurati
On Tue, 2016-06-28 at 11:00 +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Avoid early timeout due to wait_for_atomic
> URL : https://patchwork.freedesktop.org/series/9224/
> State : success
Thanks for the reviews, I pushed the patchset to -dinq. I also added
CC: drm-intel
On Mon, 2016-06-27 at 17:11 -0700, Rodrigo Vivi wrote:
> The spec has been updated adding new PCI IDs.
>
> v2: Avoid using "H" instead of HALO to keep names uniform - DK.
>
> Cc: Dhinakaran Pandiyan
> Signed-off-by: Rodrigo Vivi
> ---
> lib/intel_chipset.h | 14 ++
> 1 file changed
On Mon, 2016-06-27 at 17:11 -0700, Rodrigo Vivi wrote:
> This is unusual. Usually IDs listed on early stages of platform
> definition are kept there as reserved for later use.
>
> However these IDs here are not listed anymore in any of steppings
> and devices IDs tables for Kabylake on configurati
On Tue, Jun 28, 2016 at 10:50:20AM +0200, Maarten Lankhorst wrote:
> Op 28-06-16 om 01:42 schreef Matt Roper:
> > When a display update triggers a DDB re-allocation, we should start by
> > assuming that only the updated pipes need to be re-allocated (we have
> > logic later that may add additional
On Tue, 2016-06-28 at 15:38 +0100, Tvrtko Ursulin wrote:
> On 28/06/16 14:53, Imre Deak wrote:
> > On ti, 2016-06-28 at 14:29 +0100, Tvrtko Ursulin wrote:
> > > On 28/06/16 13:19, Imre Deak wrote:
> > > > On ti, 2016-06-28 at 12:51 +0100, Tvrtko Ursulin wrote:
> > > > > From: Tvrtko Ursulin
> > >
== Series Details ==
Series: drm/i915: hybrid wait-for macro
URL : https://patchwork.freedesktop.org/series/9237/
State : failure
== Summary ==
Series 9237v1 drm/i915: hybrid wait-for macro
http://patchwork.freedesktop.org/api/1.0/series/9237/revisions/1/mbox
Test gem_exec_flush:
Subg
On 27/06/2016 21:18, Chad Versace wrote:
On Mon 27 Jun 2016, Chad Versace wrote:
Let the hight 32 bits of drm_i915_gem_execbuffer2::rsvd1 contain an
input and/or output fence fd, whose presence is controlled by flags.
Also add I915_PARAM_HAS_FENCE_FD.
Signed-off-by: Chad Versace
---
include/
== Series Details ==
Series: series starting with [1/2] drm/i915/debug: Select PREEMPT_COUNT when
enabling debugging (rev3)
URL : https://patchwork.freedesktop.org/series/9226/
State : success
== Summary ==
Series 9226v3 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/ser
Part spin-wait, part sleep-wait.
Plus one example of where it might be used.
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_guc_submission.c | 2 +-
drivers/gpu/drm/i915/intel_drv.h | 10 ++
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/d
On Tue, 28 Jun 2016 16:47:28 +0100
Chris Wilson wrote:
> On Tue, Jun 28, 2016 at 08:42:01AM -0700, Bob Paauwe wrote:
> > When fbdev emulation is disabled it is not a good idea to call into
> > the core fb_set_suspend() function as this will cause suspend and
> > resume to fail. Also ifbdev->fb is
== Series Details ==
Series: series starting with [1/2] drm/i915/debug: Select PREEMPT_COUNT when
enabling debugging (rev2)
URL : https://patchwork.freedesktop.org/series/9226/
State : warning
== Summary ==
Series 9226v2 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/ser
From: Tvrtko Ursulin
usleep_range is not recommended for waits shorten than 10us.
Make the wait_for_us use the atomic variant for such waits.
To do so we need to reimplement the _wait_for_atomic macro to
be safe with regards to preemption and interrupts.
v2: Reimplement _wait_for_atomic to be
== Series Details ==
Series: drm/i915: Skip fbdev core suspend/resume when fbdev emulation is
disabled.
URL : https://patchwork.freedesktop.org/series/9235/
State : failure
== Summary ==
Series 9235v1 drm/i915: Skip fbdev core suspend/resume when fbdev emulation is
disabled.
http://patchwork
From: Tvrtko Ursulin
usleep_range is not recommended for waits shorten than 10us.
Make the wait_for_us use the atomic variant for such waits.
To do so we need to reimplement the _wait_for_atomic macro to
be safe with regards to preemption and interrupts.
v2: Reimplement _wait_for_atomic to be
On 28/06/16 16:50, Dave Gordon wrote:
On 28/06/16 15:30, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
host2guc_action does not appear to be called from atomic context
so a more polite wait_for macro should be used. Especially since
the timeout is 10ms.
Maybe. However we don't really want to s
On 28/06/16 15:30, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
host2guc_action does not appear to be called from atomic context
so a more polite wait_for macro should be used. Especially since
the timeout is 10ms.
Maybe. However we don't really want to sleep if the action takes only a
few mic
On Tue, Jun 28, 2016 at 08:42:01AM -0700, Bob Paauwe wrote:
> When fbdev emulation is disabled it is not a good idea to call into
> the core fb_set_suspend() function as this will cause suspend and
> resume to fail. Also ifbdev->fb is null so the defeference farther
> down will oops. Nothing in tha
On 28/06/16 15:54, Dave Gordon wrote:
On 21/06/16 19:11, Peter Antoine wrote:
From: Alex Dai
The HuC loading process is similar to GuC. The intel_uc_fw_fetch()
is used for both cases.
HuC loading needs to be before GuC loading. The WOPCM setting must
be done early before loading any of them.
When fbdev emulation is disabled it is not a good idea to call into
the core fb_set_suspend() function as this will cause suspend and
resume to fail. Also ifbdev->fb is null so the defeference farther
down will oops. Nothing in that path is needed in this case so bail
early when ifbdev->fb is null.
On Tue, Jun 28, 2016 at 03:40:24PM +0100, Tvrtko Ursulin wrote:
>
> On 28/06/16 15:14, Chris Wilson wrote:
> >On Tue, Jun 28, 2016 at 02:55:28PM +0100, Chris Wilson wrote:
> >>On Tue, Jun 28, 2016 at 02:29:33PM +0100, Tvrtko Ursulin wrote:
> >>>How would you implement it with cpu_clock? What would
Hi,
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on v4.7-rc5 next-20160628]
[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/Tvrtko-Ursulin/drm-i915-debug-Select
On 21/06/16 19:11, Peter Antoine wrote:
This patch adds the HuC Loading for the BXT.
Version 1.x of the HuC firmware.
Signed-off-by: Peter Antoine
---
drivers/gpu/drm/i915/i915_gem.c | 13 +++--
drivers/gpu/drm/i915/intel_guc_loader.c | 29 +
driv
On 21/06/16 19:11, Peter Antoine wrote:
The HuC authentication is done by host2guc call. The HuC RSA keys
are sent to GuC for authentication.
Signed-off-by: Alex Dai
Signed-off-by: Peter Antoine
---
drivers/gpu/drm/i915/i915_guc_submission.c | 65 ++
drivers/gpu/
== Series Details ==
Series: drm/i915/guc: Do not use wait_for_atomic in host2guc_action
URL : https://patchwork.freedesktop.org/series/9233/
State : failure
== Summary ==
Series 9233v1 drm/i915/guc: Do not use wait_for_atomic in host2guc_action
http://patchwork.freedesktop.org/api/1.0/series/
On 21/06/16 19:11, Peter Antoine wrote:
From: Alex Dai
Add debugfs entry for HuC loading status check.
Signed-off-by: Alex Dai
Signed-off-by: Peter Antoine
---
drivers/gpu/drm/i915/i915_debugfs.c | 32
1 file changed, 32 insertions(+)
diff --git a/drivers
On 21/06/16 19:11, Peter Antoine wrote:
From: Alex Dai
The HuC loading process is similar to GuC. The intel_uc_fw_fetch()
is used for both cases.
HuC loading needs to be before GuC loading. The WOPCM setting must
be done early before loading any of them.
Signed-off-by: Alex Dai
Signed-off-by
Op 28-06-16 om 10:35 schreef Chris Wilson:
> On Tue, Jun 28, 2016 at 09:56:47AM +0200, Maarten Lankhorst wrote:
>> Op 24-06-16 om 14:44 schreef Chris Wilson:
>>> This reverts commit ee042aa40b66d18d465206845b0752c6a617ba3f.
>>>
>>> Something appears to be off in the timing, but as far as I can tell
On 28/06/16 14:53, Imre Deak wrote:
On ti, 2016-06-28 at 14:29 +0100, Tvrtko Ursulin wrote:
On 28/06/16 13:19, Imre Deak wrote:
On ti, 2016-06-28 at 12:51 +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
usleep_range is not recommended for waits shorten than 10us.
Make the wait_for_us use
From: Tvrtko Ursulin
host2guc_action does not appear to be called from atomic context
so a more polite wait_for macro should be used. Especially since
the timeout is 10ms.
Signed-off-by: Tvrtko Ursulin
Reported-by: Imre Deak
Cc: Dave Gordon
Cc: Imre Deak
---
drivers/gpu/drm/i915/i915_guc_su
On 28/06/16 15:14, Chris Wilson wrote:
On Tue, Jun 28, 2016 at 02:55:28PM +0100, Chris Wilson wrote:
On Tue, Jun 28, 2016 at 02:29:33PM +0100, Tvrtko Ursulin wrote:
How would you implement it with cpu_clock? What would you do when
re-scheduled?
unsigned long base;
int cpu;
int ret;
preempt_
On 21/06/16 19:11, Peter Antoine wrote:
From: Alex Dai
HuC firmware css header has almost exactly same definition as GuC
firmware except for the sw_version. Also, add a new member fw_type
into intel_uc_fw to indicate what kind of fw it is. So, the loader
will pull right sw_version from header.
On 21/06/16 19:11, Peter Antoine wrote:
Rename some of the GuC fw loading code to make them more general. We
will utilize them for HuC loading as well.
s/intel_guc_fw/intel_uc_fw/g
s/GUC_FIRMWARE/UC_FIRMWARE/g
Struct intel_guc_fw is renamed to intel_uc_fw. Prefix of tts members,
such a
== Series Details ==
Series: Introdcue client-managed fence register
URL : https://patchwork.freedesktop.org/series/9229/
State : warning
== Summary ==
Series 9229v1 Introdcue client-managed fence register
http://patchwork.freedesktop.org/api/1.0/series/9229/revisions/1/mbox
Test kms_pipe_crc
On Tue, Jun 28, 2016 at 02:55:28PM +0100, Chris Wilson wrote:
> On Tue, Jun 28, 2016 at 02:29:33PM +0100, Tvrtko Ursulin wrote:
> > How would you implement it with cpu_clock? What would you do when
> > re-scheduled?
>
> unsigned long base;
> int cpu;
> int ret;
>
> preempt_disable();
> cpu = smp_
On Tue, Jun 28, 2016 at 09:51:41AM -0400, Zhi Wang wrote:
> The client-managed fence register will be supported in Chris' i915 mark II
> revamp patch series. This patchset is based on previous ideas from Joonas
> and Chris. Better we can start to discuss them and have a fallback solution
> in case
Ha, Sure, glad to do that. Have you sent them out? :P
I'm worrying about the schedule and I sent these patches for discussion as plan
B
> -Original Message-
> From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> Sent: Tuesday, June 28, 2016 4:58 PM
> To: Wang, Zhi A
> Cc: intel-gfx@lis
On Tue, Jun 28, 2016 at 02:29:33PM +0100, Tvrtko Ursulin wrote:
> How would you implement it with cpu_clock? What would you do when
> re-scheduled?
unsigned long base;
int cpu;
int ret;
preempt_disable();
cpu = smp_processor_id();
base = local_clock() >> 10;
for (;;) {
u64 now = local_clo
Hi Chris,
On 24 June 2016 at 22:44, Chris Wilson wrote:
> This reverts commit ee042aa40b66d18d465206845b0752c6a617ba3f.
>
> Something appears to be off in the timing, but as far as I can tell it
> is not along the event delivery path. The net effect appears to be
> rendering flicker (the current
On ti, 2016-06-28 at 14:29 +0100, Tvrtko Ursulin wrote:
> On 28/06/16 13:19, Imre Deak wrote:
> > On ti, 2016-06-28 at 12:51 +0100, Tvrtko Ursulin wrote:
> > > From: Tvrtko Ursulin
> > >
> > > usleep_range is not recommended for waits shorten than 10us.
> > >
> > > Make the wait_for_us use the a
A client like GVT-g will request fence register from host when creating
vGPUs. According to Chris's comments, we'd better not expose the fence
stealing function as a dedicated API as the caller may not know if the
fence register could be stealed without touching the inner pin_count.
This patch mer
This patch renames the i915_find_fence_reg() to i915_request_fence_reg(),
and expose it in kernel.
Cc: Joonas Lahtinen
Cc: Tvrtko Ursulin
Cc: Chris Wilson
Signed-off-by: Zhi Wang
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_gem_fence.c | 14 +++---
2 fi
Introduce a macro for iterating all fence registers.
Cc: Joonas Lahtinen
Cc: Tvrtko Ursulin
Cc: Chris Wilson
Signed-off-by: Zhi Wang
---
drivers/gpu/drm/i915/i915_drv.h | 4
drivers/gpu/drm/i915/i915_gem_fence.c | 8 +++-
2 files changed, 7 insertions(+), 5 deletions(-)
diff -
This patche enables a client to request fence register from i915 and
manage it by itself.
A client should:
- Set the client_managed flag and clear the HW fence register after
acquiring a fence reg from i915
- Clear the HW fence register and return it to i915 by clearing
client_managed flag
- Sa
The client-managed fence register will be supported in Chris' i915 mark II
revamp patch series. This patchset is based on previous ideas from Joonas
and Chris. Better we can start to discuss them and have a fallback solution
in case the schedule bites us before Chris' work.
Zhi Wang (4):
drm/i91
On 28/06/16 12:12, Goel, Akash wrote:
On 6/28/2016 3:33 PM, Tvrtko Ursulin wrote:
On 27/06/16 13:16, akash.g...@intel.com wrote:
From: Sagar Arun Kamble
There are certain types of interrupts which Host can recieve from GuC.
GuC ukernel sends an interrupt to Host for certain events, like f
On Tue, Jun 28, 2016 at 12:51:49PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Required to enable correct wait_for_atomic checks.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Chris Wilson
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
__
On 28/06/16 13:19, Imre Deak wrote:
On ti, 2016-06-28 at 12:51 +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
usleep_range is not recommended for waits shorten than 10us.
Make the wait_for_us use the atomic variant for such waits.
To do so we need to disable the !in_atomic warning for su
== Series Details ==
Series: series starting with [1/2] Revert "drm/i915: Workaround CHV pipe C
cursor fail" (rev2)
URL : https://patchwork.freedesktop.org/series/8431/
State : failure
== Summary ==
Series 8431v2 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/8431
== Series Details ==
Series: series starting with [1/2] drm/i915/debug: Select PREEMPT_COUNT when
enabling debugging
URL : https://patchwork.freedesktop.org/series/9226/
State : success
== Summary ==
Series 9226v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/922
Daniel,
On 06/28/2016 05:57 PM, Shobhit Kumar wrote:
From: Shobhit Kumar
CHV pipe C hits underrun when we get negative crtc_x values of cursor.
To avoid this we clip and shift the cursor image by negative crtc_x
value.
v2: Make a copy of cursor plane state and allocate new gem object and fb
From: Shobhit Kumar
CHV pipe C hits underrun when we get negative crtc_x values of cursor.
To avoid this we clip and shift the cursor image by negative crtc_x
value.
v2: Make a copy of cursor plane state and allocate new gem object and fb
for clipped cursor and use that in case of negative c
On Tue, Jun 28, 2016 at 12:51:50PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> usleep_range is not recommended for waits shorten than 10us.
>
> Make the wait_for_us use the atomic variant for such waits.
>
> To do so we need to disable the !in_atomic warning for such uses
> and also
On ti, 2016-06-28 at 12:51 +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> usleep_range is not recommended for waits shorten than 10us.
>
> Make the wait_for_us use the atomic variant for such waits.
>
> To do so we need to disable the !in_atomic warning for such uses
> and also disable
On Mon, Jun 27, 2016 at 03:04:07PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Preparation step towards unifying what can be unified between
> legacy and execlist.
>
> This series tries to simplify the engine initializers by moving some
> of the commonatility replicated between all o
On Mon, Jun 27, 2016 at 03:04:16PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Replace the macro initializer with a programatic loop which
> results in smaller code and hopefully just as clear.
>
> Signed-off-by: Tvrtko Ursulin
> ---
> drivers/gpu/drm/i915/intel_ringbuffer.c | 16 +
On Mon, Jun 27, 2016 at 03:04:14PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Signed-off-by: Tvrtko Ursulin
> ---
> drivers/gpu/drm/i915/intel_ringbuffer.c | 25 ++---
> 1 file changed, 6 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/inte
On Mon, Jun 27, 2016 at 03:04:11PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Signed-off-by: Tvrtko Ursulin
> ---
> drivers/gpu/drm/i915/intel_ringbuffer.c | 46
> -
> 1 file changed, 17 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/gpu/d
From: Tvrtko Ursulin
usleep_range is not recommended for waits shorten than 10us.
Make the wait_for_us use the atomic variant for such waits.
To do so we need to disable the !in_atomic warning for such uses
and also disable preemption since the macro is written in a way
to only be safe to be us
From: Tvrtko Ursulin
Required to enable correct wait_for_atomic checks.
Signed-off-by: Tvrtko Ursulin
Cc: Chris Wilson
---
drivers/gpu/drm/i915/Kconfig.debug | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/Kconfig.debug
b/drivers/gpu/drm/i915/Kconfig.debug
index 8f40
On 28/06/16 11:37, Imre Deak wrote:
Since wait_for_atomic doesn't re-check the wait-for condition after
expiry of the timeout it can fail when called from non-atomic context
even if the condition is set correctly before the expiry. Fix this by
using the non-atomic wait_for instead.
I noticed th
On 28/06/16 12:16, Imre Deak wrote:
On ti, 2016-06-28 at 12:05 +0100, Tvrtko Ursulin wrote:
On 28/06/16 11:48, Chris Wilson wrote:
On Tue, Jun 28, 2016 at 01:37:30PM +0300, Imre Deak wrote:
Since wait_for_atomic doesn't re-check the wait-for condition after
expiry of the timeout it can fail w
On 28/06/16 11:37, Imre Deak wrote:
Since wait_for_atomic doesn't re-check the wait-for condition after
expiry of the timeout it can fail when called from non-atomic context
even if the condition is set correctly before the expiry. Fix this by
using the non-atomic wait_for instead.
Due to the r
On 28/06/16 11:37, Imre Deak wrote:
Since wait_for_atomic doesn't re-check the wait-for condition after
expiry of the timeout it can fail when called from non-atomic context
even if the condition is set correctly before the expiry. Fix this by
using the non-atomic wait_for instead.
Fixes: 0351b
On ti, 2016-06-28 at 12:05 +0100, Tvrtko Ursulin wrote:
> On 28/06/16 11:48, Chris Wilson wrote:
> > On Tue, Jun 28, 2016 at 01:37:30PM +0300, Imre Deak wrote:
> > > Since wait_for_atomic doesn't re-check the wait-for condition after
> > > expiry of the timeout it can fail when called from non-atom
On 6/28/2016 3:33 PM, Tvrtko Ursulin wrote:
On 27/06/16 13:16, akash.g...@intel.com wrote:
From: Sagar Arun Kamble
There are certain types of interrupts which Host can recieve from GuC.
GuC ukernel sends an interrupt to Host for certain events, like for
example retrieve/consume the logs gen
On 28/06/16 11:37, Imre Deak wrote:
Since wait_for_atomic doesn't re-check the wait-for condition after
expiry of the timeout it can fail when called from non-atomic context
even if the condition is set correctly before the expiry. Fix this by
using the non-atomic wait_for instead.
Fixes: 0351b
On Tue, Jun 28, 2016 at 12:05:42PM +0100, Tvrtko Ursulin wrote:
>
> On 28/06/16 11:48, Chris Wilson wrote:
> >On Tue, Jun 28, 2016 at 01:37:30PM +0300, Imre Deak wrote:
> >>Since wait_for_atomic doesn't re-check the wait-for condition after
> >>expiry of the timeout it can fail when called from no
On Tue, 28 Jun 2016, Chris Wilson wrote:
> On Mon, Jun 27, 2016 at 02:53:19PM +0300, Jani Nikula wrote:
>> From: Randy Dunlap
>>
>> Fix build errors when ACPI is not enabled by adding function stubs:
>>
>> ../drivers/gpu/drm/i915/i915_drv.c: In function 'i915_drm_suspend':
>> ../drivers/gpu/drm
On 28/06/16 11:48, Chris Wilson wrote:
On Tue, Jun 28, 2016 at 01:37:30PM +0300, Imre Deak wrote:
Since wait_for_atomic doesn't re-check the wait-for condition after
expiry of the timeout it can fail when called from non-atomic context
even if the condition is set correctly before the expiry. F
On ti, 2016-06-28 at 11:50 +0100, Chris Wilson wrote:
> On Tue, Jun 28, 2016 at 01:37:31PM +0300, Imre Deak wrote:
> > Since wait_for_atomic doesn't re-check the wait-for condition after
> > expiry of the timeout it can fail when called from non-atomic
> > context
> > even if the condition is set c
== Series Details ==
Series: drm/i915: Avoid early timeout due to wait_for_atomic
URL : https://patchwork.freedesktop.org/series/9224/
State : success
== Summary ==
Series 9224v1 drm/i915: Avoid early timeout due to wait_for_atomic
http://patchwork.freedesktop.org/api/1.0/series/9224/revisions
On ti, 2016-06-28 at 11:48 +0100, Chris Wilson wrote:
> On Tue, Jun 28, 2016 at 01:37:30PM +0300, Imre Deak wrote:
> > Since wait_for_atomic doesn't re-check the wait-for condition after
> > expiry of the timeout it can fail when called from non-atomic
> > context
> > even if the condition is set c
On Tue, Jun 28, 2016 at 01:37:31PM +0300, Imre Deak wrote:
> Since wait_for_atomic doesn't re-check the wait-for condition after
> expiry of the timeout it can fail when called from non-atomic context
> even if the condition is set correctly before the expiry. Fix this by
> using the non-atomic wai
On Tue, Jun 28, 2016 at 01:37:30PM +0300, Imre Deak wrote:
> Since wait_for_atomic doesn't re-check the wait-for condition after
> expiry of the timeout it can fail when called from non-atomic context
> even if the condition is set correctly before the expiry. Fix this by
> using the non-atomic wai
Op 23-06-16 om 14:36 schreef Chi Ding:
> From: Maarten Lankhorst
>
> Rename vlv_compute_wm to vlv_compute_pipe_wm to compute optimal watermark
> Add vlv_compute_intermediate_wm to computer intermediate watermark
> Add vlv_initial_watermarks to write intermediate watermark into hardware
> Add vlv_o
On Tue, Jun 28, 2016 at 03:55:15PM +0530, Goel, Akash wrote:
> >>+ pinned = (obj->pages_pin_count > 1);
> >
> >Too many ()
>
> Sorry is the above condition not correct ?
> If pin count is more than 1 then it implies that pages have been
> pinned elsewhere also, so pages were already pinned befor
Since wait_for_atomic doesn't re-check the wait-for condition after
expiry of the timeout it can fail when called from non-atomic context
even if the condition is set correctly before the expiry. Fix this by
using the non-atomic wait_for instead.
Fixes: 0351b93992aa ("drm/i915: Do not lie about at
Since wait_for_atomic doesn't re-check the wait-for condition after
expiry of the timeout it can fail when called from non-atomic context
even if the condition is set correctly before the expiry. Fix this by
using the non-atomic wait_for instead.
Fixes: 0351b93992aa ("drm/i915: Do not lie about at
Since wait_for_atomic doesn't re-check the wait-for condition after
expiry of the timeout it can fail when called from non-atomic context
even if the condition is set correctly before the expiry. Fix this by
using the non-atomic wait_for instead.
Due to the relatively long 10ms timeout, probably t
Since wait_for_atomic doesn't re-check the wait-for condition after
expiry of the timeout it can fail when called from non-atomic context
even if the condition is set correctly before the expiry. Fix this by
using the non-atomic wait_for instead.
I noticed this via the PLL locking timing out incor
If called from non-atomic context wait_for_atomic{,_us} can fail even
though the given condition becomes true before the timeout passes. I
noticed this via sporadic timeouts during PLL locking on BXT (fixed by
patch 1). The WARN in wait_for_atomic would be also triggered, alas I
didn't have extra d
On 6/28/2016 3:22 PM, Chris Wilson wrote:
On Mon, Jun 27, 2016 at 05:46:57PM +0530, akash.g...@intel.com wrote:
From: Chris Wilson
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 20c701c..3ef1ee5 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/g
On 27/06/16 13:16, akash.g...@intel.com wrote:
From: Sagar Arun Kamble
There are certain types of interrupts which Host can recieve from GuC.
GuC ukernel sends an interrupt to Host for certain events, like for
example retrieve/consume the logs generated by ukernel.
This patch adds support to r
Reviewed-by: Matthew Auld
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
On 6/28/2016 3:17 PM, Chris Wilson wrote:
On Mon, Jun 27, 2016 at 05:46:53PM +0530, akash.g...@intel.com wrote:
+static void guc_remove_log_relay_file(struct intel_guc *guc)
+{
+ relay_close(guc->log_relay_chan);
+}
+
+static void guc_create_log_relay_file(struct intel_guc *guc)
+{
+
On Mon, Jun 27, 2016 at 05:46:57PM +0530, akash.g...@intel.com wrote:
> From: Chris Wilson
>
> vmaps has a provision for controlling the page protection bits, with which
> we can use to control the mapping type, e.g. WB, WC, UC or even WT.
> To allow the caller to choose their mapping type, we ad
1 - 100 of 114 matches
Mail list logo
