Hi all,
More in i915 for 4.12:
- designware i2c fixes from Hans de Goede, in a topic branch shared
with other subsystems (maybe, they didn't confirm, but requested the
pull)
- drop drm_panel usage from the intel dsi vbt panel (Jani)
- vblank evasion improvements and tracing (Maarten and Ville
On Mon, Mar 20, 2017 at 11:32:15AM +0530, Sagar Arun Kamble wrote:
> Due to garbage data seen by i915, gem_create_ioctl failed for gem obj
> created with drmIoctl(GEM_CREATE) without properly initialized
> parameters. Can be fixed by calling gem_create helper too.
Whose bug are you working around?
Cc: Ville Syrjälä
Signed-off-by: Daniel Vetter
---
dim.rst | 30 ++
1 file changed, 30 insertions(+)
diff --git a/dim.rst b/dim.rst
index a778701c7335..1bec3838bace 100644
--- a/dim.rst
+++ b/dim.rst
@@ -182,6 +182,22 @@ apply-queued|aq [*git am arguments*]
Applies
The integration branch moved!
Signed-off-by: Daniel Vetter
---
dim | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/dim b/dim
index 64edcda83084..d8b190efe2de 100755
--- a/dim
+++ b/dim
@@ -1291,13 +1291,14 @@ function dim_update_next
remote=`url_to_remote $drm_ti
When opening a DRM debugfs file, locate the right path based on the
given DRM device FD.
This is needed so, in setups with more than one DRM device, any
operations on debugfs files affect the expected DRM device.
v2: rebased and fixed new API additions
Signed-off-by: Tomeu Vizoso
Reviewed-by: R
Some frame sources such as sinks aren't able to provide meaningful frame
numbers, so in those cases just skip the TEST_SEQUENCE tests.
v2: Rebased
Signed-off-by: Tomeu Vizoso
---
tests/kms_pipe_crc_basic.c | 28 ++--
1 file changed, 22 insertions(+), 6 deletions(-)
diff
On Mon, Mar 20, 2017 at 1:51 AM, Stephen Rothwell wrote:
> This cherry picking of fixes from new development back to Linus' tree
> can be a real pain when so many other changes happen in the same files.
One possible fix for this would be if you reuse our rerere cache. The
only reason we don't go
On Mon, Mar 20, 2017 at 9:03 AM, Daniel Vetter wrote:
> On Mon, Mar 20, 2017 at 1:51 AM, Stephen Rothwell
> wrote:
>> This cherry picking of fixes from new development back to Linus' tree
>> can be a real pain when so many other changes happen in the same files.
>
> One possible fix for this wou
> -Original Message-
> From: Chauhan, Madhav
> Sent: Friday, March 17, 2017 7:11 PM
> To: Nikula, Jani ; Ander Conselvan De Oliveira
> ; intel-gfx@lists.freedesktop.org
> Subject: RE: [Intel-gfx] [PATCH] drm/i915/glk: CDCLK calculation changes for
> glk
>
> > -Original Message-
> >
On Fri, Mar 17, 2017 at 05:52:32PM +0100, Maarten Lankhorst wrote:
> Op 16-03-17 om 21:15 schreef Daniel Vetter:
> > On Thu, Mar 16, 2017 at 5:09 PM, Maarten Lankhorst
> > wrote:
> >> Op 16-03-17 om 16:52 schreef Daniel Vetter:
> >>> The vblank code really wants to look at crtc->state without havi
Op 20-03-17 om 09:18 schreef Daniel Vetter:
> On Fri, Mar 17, 2017 at 05:52:32PM +0100, Maarten Lankhorst wrote:
>> Op 16-03-17 om 21:15 schreef Daniel Vetter:
>>> On Thu, Mar 16, 2017 at 5:09 PM, Maarten Lankhorst
>>> wrote:
Op 16-03-17 om 16:52 schreef Daniel Vetter:
> The vblank code r
On 3/20/2017 1:11 PM, Chris Wilson wrote:
On Mon, Mar 20, 2017 at 11:32:15AM +0530, Sagar Arun Kamble wrote:
Due to garbage data seen by i915, gem_create_ioctl failed for gem obj
created with drmIoctl(GEM_CREATE) without properly initialized
parameters. Can be fixed by calling gem_create helpe
Op 09-03-17 om 10:19 schreef Mika Kahola:
> We need to make sure that TEST_ONLY really only touches the free-standing
> state objects and nothing else. Test approach here is the following:
>
> - Create a config and submit it with TEST_ONLY.
> - do dpms off/on cycle with the current config to reconf
On Mon, Mar 20, 2017 at 02:16:54PM +0530, Kamble, Sagar A wrote:
>
>
> On 3/20/2017 1:11 PM, Chris Wilson wrote:
> >On Mon, Mar 20, 2017 at 11:32:15AM +0530, Sagar Arun Kamble wrote:
> >>Due to garbage data seen by i915, gem_create_ioctl failed for gem obj
> >>created with drmIoctl(GEM_CREATE) wi
On Mon, Mar 20, 2017 at 09:38:52AM +0100, Maarten Lankhorst wrote:
> Op 20-03-17 om 09:18 schreef Daniel Vetter:
> > On Fri, Mar 17, 2017 at 05:52:32PM +0100, Maarten Lankhorst wrote:
> >> Op 16-03-17 om 21:15 schreef Daniel Vetter:
> >>> On Thu, Mar 16, 2017 at 5:09 PM, Maarten Lankhorst
> >>> wr
On 3/20/2017 2:25 PM, Chris Wilson wrote:
On Mon, Mar 20, 2017 at 02:16:54PM +0530, Kamble, Sagar A wrote:
On 3/20/2017 1:11 PM, Chris Wilson wrote:
On Mon, Mar 20, 2017 at 11:32:15AM +0530, Sagar Arun Kamble wrote:
Due to garbage data seen by i915, gem_create_ioctl failed for gem obj
creat
On Fri, 17 Mar 2017, Paulo Zanoni wrote:
> Em Ter, 2017-03-14 às 11:09 +0200, Jani Nikula escreveu:
>> On Mon, 13 Mar 2017, Manasi Navare wrote:
>> >
>> > On Mon, Mar 13, 2017 at 11:55:31AM +0200, Jani Nikula wrote:
>> > >
>> > > On Sat, 11 Mar 2017, Manasi Navare
>> > > wrote:
>> > > >
>> >
Hi,
After a kernel update from v4.9.10 to v4.10.3, any time I bring out the gimp,
the i915 driver NULL-pointer dereferences something in list_move_tail(),
somewhere in i915_gem_evict_for_vma().
I'm providing the kernel log, if more is needed (say you aren't
aware of this regression) I'm availabl
A struct file is a bit too large to put on the kernel stack in general
and triggers a warning for low settings of CONFIG_FRAME_WARN:
drivers/gpu/drm/i915/selftests/mock_drm.c: In function 'mock_file':
drivers/gpu/drm/i915/selftests/mock_drm.c:46:1: error: the frame size of 1328
bytes is larger th
We get a warning with gcc-7 about a pointless comparison when
using a linear memmap:
drivers/gpu/drm/i915/selftests/scatterlist.c: In function 'alloc_table':
drivers/gpu/drm/i915/selftests/scatterlist.c:219:66: error: self-comparison
always evaluates to false [-Werror=tautological-compare]
Split
The varargs macro trick in _PIPE3/_PHY3/_PORT3 was meant as an optimization
to shrink the i915 kernel module by around 1000 bytes. However, the
downside is a size regression with CONFIG_KASAN, as I found from stack size
warnings with gcc-7.0.1:
before:
drivers/gpu/drm/i915/intel_dpll_mgr.c: In fun
On Sat, Mar 18, 2017 at 12:45:20AM +0530, Praveen Paneri wrote:
> This function can be used by igt_draw to get accurate
> tile dimensions for all tile formats.
>
> Signed-off-by: Praveen Paneri
> ---
> lib/igt_fb.c | 2 +-
> lib/igt_fb.h | 3 ++-
> 2 files changed, 3 insertions(+), 2 deletions(-
On Mon, Mar 20, 2017 at 10:40:27AM +0100, Arnd Bergmann wrote:
> A struct file is a bit too large to put on the kernel stack in general
> and triggers a warning for low settings of CONFIG_FRAME_WARN:
>
> drivers/gpu/drm/i915/selftests/mock_drm.c: In function 'mock_file':
> drivers/gpu/drm/i915/sel
On ke, 2017-03-15 at 19:38 +, Michal Wajdeczko wrote:
> There is no need to expose this function as it is called from
> one function only. Also move it up to avoid forward declaration.
>
> Signed-off-by: Michal Wajdeczko
> Cc: Arkadiusz Hiler
> Cc: Joonas Lahtinen
+ Adding CCs
Looks good
Chris Wilson writes:
> The trick of using an uncached mmio read to ensure that the GGTT writes
> are flushed does not require us to do the forcewake dance, so avoid it
> in the hope of reducing the frequency that we do keep the device forced
> awake.
>
> Signed-off-by: Chris Wilson
> ---
> driv
== Series Details ==
Series: series starting with [1/3] drm/i915: allocate mock file pointer
dynamically
URL : https://patchwork.freedesktop.org/series/21533/
State : success
== Summary ==
Series 21533v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/21533/revisi
Op 20-03-17 om 09:59 schreef Daniel Vetter:
> On Mon, Mar 20, 2017 at 09:38:52AM +0100, Maarten Lankhorst wrote:
>> Op 20-03-17 om 09:18 schreef Daniel Vetter:
>>> On Fri, Mar 17, 2017 at 05:52:32PM +0100, Maarten Lankhorst wrote:
Op 16-03-17 om 21:15 schreef Daniel Vetter:
> On Thu, Mar 1
On Mon, Mar 20, 2017 at 12:02:02PM +0200, Mika Kuoppala wrote:
> Chris Wilson writes:
>
> > The trick of using an uncached mmio read to ensure that the GGTT writes
> > are flushed does not require us to do the forcewake dance, so avoid it
> > in the hope of reducing the frequency that we do keep
On Mon, 20 Mar 2017, Arnd Bergmann wrote:
> The varargs macro trick in _PIPE3/_PHY3/_PORT3 was meant as an optimization
> to shrink the i915 kernel module by around 1000 bytes.
To be clear, it was not at all intended to be an optimization, nothing
of the sort. The intention was to make it easier
On Mon, Mar 20, 2017 at 11:01:59AM +0100, Maarten Lankhorst wrote:
> Op 20-03-17 om 09:59 schreef Daniel Vetter:
> > But my idea was kinda that we'd do the same for probe -> modeset data
> > flows like here for the other way round: Just a bunch of READ_ONCE and
> > maybe lookup the edid with rcu to
On Mon, Mar 20, 2017 at 11:08 AM, Jani Nikula
wrote:
> On Mon, 20 Mar 2017, Arnd Bergmann wrote:
>> The varargs macro trick in _PIPE3/_PHY3/_PORT3 was meant as an optimization
>> to shrink the i915 kernel module by around 1000 bytes.
>
> To be clear, it was not at all intended to be an optimizati
Chris Wilson writes:
> The trick of using an uncached mmio read to ensure that the GGTT writes
> are flushed does not require us to do the forcewake dance, so avoid it
> in the hope of reducing the frequency that we do keep the device forced
> awake.
>
> Signed-off-by: Chris Wilson
Reviewed-by:
On Mon, 20 Mar 2017, Arnd Bergmann wrote:
> I don't know how to generate a URL for it, but after adding this to the
> command line for gcc-7,
>
> -fsanitize=kernel-address -fasan-shadow-offset=0xdfff9000
> --param asan-stack=1 --param asan-globals=1 --param
> asan-instrumentation-with-call
On ma, 2017-03-20 at 10:40 +0100, Arnd Bergmann wrote:
> A struct file is a bit too large to put on the kernel stack in general
> and triggers a warning for low settings of CONFIG_FRAME_WARN:
>
> drivers/gpu/drm/i915/selftests/mock_drm.c: In function 'mock_file':
> drivers/gpu/drm/i915/selftests/m
On Mon, Mar 20, 2017 at 1:00 PM, Joonas Lahtinen
wrote:
> On ma, 2017-03-20 at 10:40 +0100, Arnd Bergmann wrote:
>> diff --git a/drivers/gpu/drm/i915/selftests/mock_drm.c
>> b/drivers/gpu/drm/i915/selftests/mock_drm.c
>> index 113dec05c7dc..18514065c93d 100644
>> --- a/drivers/gpu/drm/i915/selft
On Mon, Mar 20, 2017 at 1:02 PM, Arnd Bergmann wrote:
> On Mon, Mar 20, 2017 at 1:00 PM, Joonas Lahtinen
> wrote:
>> On ma, 2017-03-20 at 10:40 +0100, Arnd Bergmann wrote:
>
>>> diff --git a/drivers/gpu/drm/i915/selftests/mock_drm.c
>>> b/drivers/gpu/drm/i915/selftests/mock_drm.c
>>> index 113de
Op 20-03-17 om 11:22 schreef Chris Wilson:
> On Mon, Mar 20, 2017 at 11:01:59AM +0100, Maarten Lankhorst wrote:
>> Op 20-03-17 om 09:59 schreef Daniel Vetter:
>>> But my idea was kinda that we'd do the same for probe -> modeset data
>>> flows like here for the other way round: Just a bunch of READ_
On pe, 2017-03-10 at 08:28 -0800, Oscar Mateo wrote:
> Some recent refactoring patches have left the doorbell creation outside
> the GuC client allocation, which does not make a lot of sense (a client
> without a doorbell is something useless). Move it back there, and
> refactor the init_doorbell_h
On Fri, 17 Mar 2017, Daniel Vetter wrote:
> On Fri, Mar 17, 2017 at 12:42:51PM +0200, Jani Nikula wrote:
>> Noticing that 64a54c5e1a5d ("dim: Add add-link command") added a
>> condition that is always true (if [ -n $foo ]), despite my review of the
>> patch, I refreshed some of my old patches to f
From: Tvrtko Ursulin
It has to be called after the global seqno has been assigned.
Signed-off-by: Tvrtko Ursulin
Fixes: 31de73501ac9 ("drm/i915/scheduler: emulate a scheduler for guc")
Cc: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
Cc: Michał Winiarski
Cc: Daniel Vetter
Cc: Jani N
We do not use the struct file backpointer so struct drm_file, so mark it
as invalid when creating a mock file for i915 selftests.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/selftests/mock_drm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/selftests/mock_drm.
On Mon, Mar 20, 2017 at 01:25:56PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> It has to be called after the global seqno has been assigned.
>
> Signed-off-by: Tvrtko Ursulin
> Fixes: 31de73501ac9 ("drm/i915/scheduler: emulate a scheduler for guc")
> Cc: Chris Wilson
So be it. You
On Mon, Mar 20, 2017 at 01:30:21PM +, Chris Wilson wrote:
> We do not use the struct file backpointer so struct drm_file, so mark it
s/so/from/
> as invalid when creating a mock file for i915 selftests.
It is only used by legacy vm mmapping, not by i915.ko
-Chris
--
Chris Wilson, Intel Open
On 20/03/2017 13:37, Chris Wilson wrote:
On Mon, Mar 20, 2017 at 01:25:56PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
It has to be called after the global seqno has been assigned.
Signed-off-by: Tvrtko Ursulin
Fixes: 31de73501ac9 ("drm/i915/scheduler: emulate a scheduler for guc")
C
== Series Details ==
Series: drm/i915/guc: Correct the request_in tracepoint position
URL : https://patchwork.freedesktop.org/series/21538/
State : success
== Summary ==
Series 21538v1 drm/i915/guc: Correct the request_in tracepoint position
https://patchwork.freedesktop.org/api/1.0/series/215
On Mon, Mar 20, 2017 at 01:41:28PM +, Tvrtko Ursulin wrote:
>
> On 20/03/2017 13:37, Chris Wilson wrote:
> >On Mon, Mar 20, 2017 at 01:25:56PM +, Tvrtko Ursulin wrote:
> >>From: Tvrtko Ursulin
> >>
> >>It has to be called after the global seqno has been assigned.
> >>
> >>Signed-off-by: T
On Mon, Mar 20, 2017 at 12:38:31PM +0200, Mika Kuoppala wrote:
> Chris Wilson writes:
>
> > The trick of using an uncached mmio read to ensure that the GGTT writes
> > are flushed does not require us to do the forcewake dance, so avoid it
> > in the hope of reducing the frequency that we do keep
On Sun, Mar 19, 2017 at 10:58:12PM +0100, Michał Winiarski wrote:
> On Sat, Mar 18, 2017 at 10:28:59AM +, Chris Wilson wrote:
> > When switching back to execlists, we also now need to restore the
> > tasklet handler.
> >
> > Reported-by: Oscar Mateo
> > Fixes: 31de73501ac9 ("drm/i915/schedule
intel_engine_wakeup() is called by nop_request_submit() which is
installed to handle third party fences completed from within irq
context. As such, it needs the full irqsave/irqrestore and not the
partial spin_irq_lock handling.
[18942.714467] =
[18942.719076] [ INF
On 20/03/2017 14:31, Chris Wilson wrote:
intel_engine_wakeup() is called by nop_request_submit() which is
installed to handle third party fences completed from within irq
context. As such, it needs the full irqsave/irqrestore and not the
partial spin_irq_lock handling.
[18942.714467] ==
On Mon, Mar 20, 2017 at 02:39:39PM +, Tvrtko Ursulin wrote:
>
> On 20/03/2017 14:31, Chris Wilson wrote:
> >intel_engine_wakeup() is called by nop_request_submit() which is
> >installed to handle third party fences completed from within irq
> >context. As such, it needs the full irqsave/irqres
Hi! We are conducting an international project with the Stockholm School
of Economics and the Politecnico of Milan to assess some relevant issues
about software development.
We’d like you to answer the following survey, which is completely
anonymous. It’ll take you only 10 minutes!
Link: https:
== Series Details ==
Series: drm/i915/selftest: Mark the mock struct file backpointer as invalid
URL : https://patchwork.freedesktop.org/series/21539/
State : success
== Summary ==
Series 21539v1 drm/i915/selftest: Mark the mock struct file backpointer as
invalid
https://patchwork.freedesktop
On Tue, 14 Mar 2017, Eric Blau wrote:
> That's funny. I have a MacBook Pro 12,1 from late 2015. Hibernate
> failed for me in 4.9.6 through 4.9.8 (possibly earlier as well, I do
> no recall) without the patch. The patch you reference fixed my problem
> and apparently many others based on the bug re
As intel_engine_init_global_seqno() may be called by
nop_submit_request() from inside irq context, we have to use atomic
versions of kmap/kunmap. This is rare as this requires using gen8 legacy
ringbuffer submission.
Reported-by: Tvrtko Ursulin
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc:
On Mon, Mar 20, 2017 at 05:01:34PM +0200, Jani Nikula wrote:
> On Tue, 14 Mar 2017, Eric Blau wrote:
> > That's funny. I have a MacBook Pro 12,1 from late 2015. Hibernate
> > failed for me in 4.9.6 through 4.9.8 (possibly earlier as well, I do
> > no recall) without the patch. The patch you refere
On Mon, Mar 20, 2017 at 11:01:59AM +0100, Maarten Lankhorst wrote:
> Op 20-03-17 om 09:59 schreef Daniel Vetter:
> > On Mon, Mar 20, 2017 at 09:38:52AM +0100, Maarten Lankhorst wrote:
> >> Op 20-03-17 om 09:18 schreef Daniel Vetter:
> >>> On Fri, Mar 17, 2017 at 05:52:32PM +0100, Maarten Lankhorst
On Mon, Mar 20, 2017 at 11:13 AM, Greg Kroah-Hartman
wrote:
> On Mon, Mar 20, 2017 at 05:01:34PM +0200, Jani Nikula wrote:
>> On Tue, 14 Mar 2017, Eric Blau wrote:
>> > That's funny. I have a MacBook Pro 12,1 from late 2015. Hibernate
>> > failed for me in 4.9.6 through 4.9.8 (possibly earlier as
== Series Details ==
Series: drm/i915: Protect intel_engine_wakeup() for call from irq context
URL : https://patchwork.freedesktop.org/series/21540/
State : failure
== Summary ==
Series 21540v1 drm/i915: Protect intel_engine_wakeup() for call from irq context
https://patchwork.freedesktop.org/
/anongit.freedesktop.org/git/drm-intel tags/drm-intel-next-2017-03-20
for you to fetch changes up to c5bd2e14e85d180bc7fb3b8b62ac9348bddaf898:
drm/i915: Update DRIVER_DATE to 20170320 (2017-03-20 08:21:05 +0100)
More in i915 for
On Mon, 20 Mar 2017, Greg Kroah-Hartman wrote:
> On Mon, Mar 20, 2017 at 05:01:34PM +0200, Jani Nikula wrote:
>> On Tue, 14 Mar 2017, Eric Blau wrote:
>> > That's funny. I have a MacBook Pro 12,1 from late 2015. Hibernate
>> > failed for me in 4.9.6 through 4.9.8 (possibly earlier as well, I do
>
== Series Details ==
Series: drm/i915: intel_engine_init_global_seqno() requires atomic kmap
URL : https://patchwork.freedesktop.org/series/21541/
State : failure
== Summary ==
Series 21541v1 drm/i915: intel_engine_init_global_seqno() requires atomic kmap
https://patchwork.freedesktop.org/api/
On Fri, Mar 17, 2017 at 09:48:26PM +, Chris Wilson wrote:
> On Fri, Mar 17, 2017 at 11:17:56PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > On SKL the planes are uniform so the "sprites" can use the
> > primary plane code perfectly fine. The only difference we
>
On Mon, Mar 20, 2017 at 06:09:44PM +0200, Ville Syrjälä wrote:
> On Fri, Mar 17, 2017 at 09:48:26PM +, Chris Wilson wrote:
> > On Fri, Mar 17, 2017 at 11:17:56PM +0200, ville.syrj...@linux.intel.com
> > wrote:
> > > From: Ville Syrjälä
> > >
> > > On SKL the planes are uniform so the "sprite
On Tue, Feb 28, 2017 at 1:33 PM, Chris Wilson wrote:
> On Tue, Feb 28, 2017 at 01:28:13PM +, Matthew Auld wrote:
>> On 22 February 2017 at 15:25, Robert Bragg wrote:
>> > This change is pre-emptively aiming to avoid a potential cause of kernel
>> > logging noise in case some condition were to
Hi! We are conducting an international project with the Stockholm School
of Economics and the Politecnico of Milan to assess some relevant issues
about software development.
We’d like you to answer the following survey, which is completely
anonymous. It’ll take you only 10 minutes!
Link: https:
On Wed, Mar 1, 2017 at 1:00 PM, Matthew Auld
wrote:
> On 02/22, Robert Bragg wrote:
>> These are auto generated from an XML description of metric sets,
>> currently maintained in gputop, ref:
>>
>> https://github.com/rib/gputop
>> > gputop-data/oa-*.xml
>> > scripts/i915-perf-kernelgen.py
>>
>>
From: Ville Syrjälä
Share the code to compute the primary plane control register value
between the i9xx and ilk codepaths as the differences are minimal.
Actually there are no differences between g4x and ilk, so the
current split doesn't really make any sense.
Cc: Chris Wilson
Signed-off-by: Vi
From: Ville Syrjälä
Pull the code to calculate the pre-SKL primary plane control register
value into separate functions. Allows us to pre-compute it in the
future.
v2: Split the pre-ilk vs. ilk+ unification to a separate patch (Chris)
Cc: Chris Wilson
Signed-off-by: Ville Syrjälä
---
drivers
== Series Details ==
Series: drm/i915: Moar plane update optimizations (rev3)
URL : https://patchwork.freedesktop.org/series/21475/
State : failure
== Summary ==
LD [M] drivers/net/ethernet/broadcom/genet/genet.o
LD drivers/gpu/drm/drm.o
LD drivers/thermal/thermal_sys.o
LD
Em Seg, 2017-03-20 às 11:38 +0200, Jani Nikula escreveu:
> On Fri, 17 Mar 2017, Paulo Zanoni wrote:
> >
> > Em Ter, 2017-03-14 às 11:09 +0200, Jani Nikula escreveu:
> > >
> > > On Mon, 13 Mar 2017, Manasi Navare
> > > wrote:
> > > >
> > > >
> > > > On Mon, Mar 13, 2017 at 11:55:31AM +0200, Ja
On Fri, Mar 17, 2017 at 10:04:32PM +, Chris Wilson wrote:
> On Fri, Mar 17, 2017 at 11:18:03PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Extract the primary plane surfae offset/x/y calculations for
> > pre-SKL platforms into a common function, and call it dur
On Mon, Mar 20, 2017 at 07:07:55PM +0200, Ville Syrjälä wrote:
> On Fri, Mar 17, 2017 at 10:04:32PM +, Chris Wilson wrote:
> > On Fri, Mar 17, 2017 at 11:18:03PM +0200, ville.syrj...@linux.intel.com
> > wrote:
> > > From: Ville Syrjälä
> > >
> > > Extract the primary plane surfae offset/x/y
On Fri, Mar 17, 2017 at 2:52 AM, Chris Wilson wrote:
> In order to prevent a cyclic recursion between psi->read_mutex and the
> inode_lock, we need to move the pse->erase to a worker.
>
> [ 605.374955] ==
> [ 605.381281] [ INFO: possible circul
As per BSPEC, valid cdclk values for glk are 79.2, 158.4, 316.8 Mhz.
Practically we can achive only 99% of these cdclk values(HW team
checking on this). So cdclk should be calculated for the given pixclk as
per that otherwise it may lead to screen corruption for some scenarios.
v2: Rebased to new
== Series Details ==
Series: drm/i915/glk: CDCLK calculation changes for glk (rev3)
URL : https://patchwork.freedesktop.org/series/19226/
State : failure
== Summary ==
Series 19226v3 drm/i915/glk: CDCLK calculation changes for glk
https://patchwork.freedesktop.org/api/1.0/series/19226/revision
== Series Details ==
Series: drm/i915: Enable atomic for VLV/CHV
URL : https://patchwork.freedesktop.org/series/20634/
State : failure
== Summary ==
Series 20634v1 drm/i915: Enable atomic for VLV/CHV
https://patchwork.freedesktop.org/api/1.0/series/20634/revisions/1/mbox/
Test gem_exec_flush:
On Mon, Mar 20, 2017 at 01:57:51PM -0300, Paulo Zanoni wrote:
> Em Seg, 2017-03-20 às 11:38 +0200, Jani Nikula escreveu:
> > On Fri, 17 Mar 2017, Paulo Zanoni wrote:
> > >
> > > Em Ter, 2017-03-14 às 11:09 +0200, Jani Nikula escreveu:
> > > >
> > > > On Mon, 13 Mar 2017, Manasi Navare
> > > > w
Storing the position of the breadcrumb of the last retired request as
a separate last_retired_head is superfluous as we always copy that into
head prior to recalculation of the intel_ring.space.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c | 5 ++---
drivers/gpu/
== Series Details ==
Series: drm/i915: Remove intel_ring.last_retired_head
URL : https://patchwork.freedesktop.org/series/21559/
State : failure
== Summary ==
Series 21559v1 drm/i915: Remove intel_ring.last_retired_head
https://patchwork.freedesktop.org/api/1.0/series/21559/revisions/1/mbox/
The varargs macro trick in _PIPE3/_PHY3/_PORT3 was meant as an optimization
to shrink the i915 kernel module by around 1000 bytes. However, the
downside is a size regression with CONFIG_KASAN, as I found from stack size
warnings with gcc-7.0.1:
before:
drivers/gpu/drm/i915/intel_dpll_mgr.c: In fun
== Series Details ==
Series: drm/i915: use static const array for PICK macro
URL : https://patchwork.freedesktop.org/series/21561/
State : warning
== Summary ==
Series 21561v1 drm/i915: use static const array for PICK macro
https://patchwork.freedesktop.org/api/1.0/series/21561/revisions/1/mbo
On 03/15/2017 12:38 PM, Michal Wajdeczko wrote:
There is no need to expose this function as it is called from
one function only. Also move it up to avoid forward declaration.
Signed-off-by: Michal Wajdeczko
Cc: Arkadiusz Hiler
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/intel_uc.c | 269
Hi Dave,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/i915/gvt/cmd_parser.c
between commit:
695fbc08d80f ("drm/i915/gvt: replace the gvt_err with gvt_vgpu_err")
from the drm-intel-fixes tree and commit:
73dec95e6ba3 ("drm/i915: Emit to ringbuffer directly"
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in:
drivers/gpu/drm/i915/gvt/scheduler.c
between commit:
3cd23b828b37 ("drm/i915/gvt: GVT pin/unpin shadow context")
from the drm-intel-fixes tree and commit:
e642c85b03de ("drm/i915: Remove superfluous i915_add_reque
The new guc submission scheduler is not to emulation Execlist mode in driver.
You can keep existing execlist_xx function name if insisted it is better.
> -Original Message-
> From: Dong, Chuanxiao
> Sent: Monday, March 20, 2017 11:20 AM
> To: Zheng, Xiao ; intel-gfx@lists.freedesktop.org
> -Original Message-
> From: Zheng, Xiao
> Sent: Tuesday, March 21, 2017 9:39 AM
> To: Dong, Chuanxiao ; intel-
> g...@lists.freedesktop.org
> Cc: intel-gvt-...@lists.freedesktop.org
> Subject: RE: [Intel-gfx] [PATCH] drm/i915/scheduler: add gvt notification for
> guc submission
>
> The n
GVT request needs a manual mmio load/restore. Before GuC submit
a request, send notification to gvt for mmio loading. And after
the GuC finished this GVT request, notify gvt again for mmio
restore. This follows the usage when using execlists submission.
v2: use context_status_change instead of exe
== Series Details ==
Series: drm/i915/scheduler: add gvt notification for guc submission
URL : https://patchwork.freedesktop.org/series/21514/
State : success
== Summary ==
Series 21514v1 drm/i915/scheduler: add gvt notification for guc submission
https://patchwork.freedesktop.org/api/1.0/seri
89 matches
Mail list logo
