== Series Details ==
Series: Enable Multi-segmented-gamma for ICL (rev4)
URL : https://patchwork.freedesktop.org/series/60126/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6242_full -> Patchwork_13248_full
Summary
---
== Series Details ==
Series: series starting with [1/4] drm/i915: Refine placement of
gt.reset_lockmap
URL : https://patchwork.freedesktop.org/series/61991/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6253 -> Patchwork_13265
=
Quoting Patchwork (2019-06-13 08:10:55)
> == Series Details ==
>
> Series: series starting with [1/4] drm/i915: Refine placement of
> gt.reset_lockmap
> URL : https://patchwork.freedesktop.org/series/61991/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_6253 -> Patch
Quoting Chris Wilson (2019-06-13 08:15:47)
> Quoting Patchwork (2019-06-13 08:10:55)
> > == Series Details ==
> >
> > Series: series starting with [1/4] drm/i915: Refine placement of
> > gt.reset_lockmap
> > URL : https://patchwork.freedesktop.org/series/61991/
> > State : failure
> >
> > == S
As the fence registers only apply to regions inside the GGTT is makes
more sense that we track these as part of the i915_ggtt and not the
general mm. In the next patch, we will then pull the register locking
underneath the i915_ggtt.mutex.
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
-
>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Patchwork
>Sent: Thursday, June 13, 2019 12:36 PM
>To: Sharma, Shashank
>Cc: intel-gfx@lists.freedesktop.org
>Subject: [Intel-gfx] ✗ Fi.CI.IGT: failure for Enable Multi-segmented-gamma for
== Series Details ==
Series: drm/i915: Move fence register tracking from i915->mm to ggtt
URL : https://patchwork.freedesktop.org/series/62000/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
b3b76fb5623d drm/i915: Move fence register tracking from i915->mm to ggtt
-:182: WARNING
On Wed, Jun 12, 2019 at 11:10:54PM -0300, Rodrigo Siqueira wrote:
> For historical reason, the function drm_wait_vblank_ioctl always return
> -EINVAL if something gets wrong. This scenario limits the flexibility
> for the userspace make detailed verification of the problem and take
> some action. I
== Series Details ==
Series: drm/i915: Move fence register tracking from i915->mm to ggtt
URL : https://patchwork.freedesktop.org/series/62000/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6254 -> Patchwork_13266
Summary
-
Ensure intel_sdvo_regs.h is self-contained and remains that way.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/Makefile.header-test | 1 +
drivers/gpu/drm/i915/intel_sdvo_regs.h| 7 +++
2 files changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/Makefile.header-test
b/driv
Now that we have a new subdirectory for display code, continue by moving
modesetting core code.
display/intel_frontbuffer.h sticks out like a sore thumb, otherwise this
is, again, a surprisingly clean operation.
v2:
- don't move intel_sideband.[ch] (Ville)
- use tabs for Makefile file lists and s
Add a new subdirectory for display code, and start off by moving
modesetting output/encoder code. Judging by the include changes, this is
a surprisingly clean operation.
v2:
- move intel_sdvo_regs.h too
- use tabs for Makefile file lists and sort them
Cc: Chris Wilson
Cc: Joonas Lahtinen
Cc: Ro
On Wed, Jun 12, 2019 at 01:59:52PM -0700, Manasi Navare wrote:
> On Wed, Jun 12, 2019 at 10:30:55PM +0300, Ville Syrjälä wrote:
> > On Wed, Jun 12, 2019 at 12:11:02PM -0700, Manasi Navare wrote:
> > > On Wed, Jun 12, 2019 at 10:04:26PM +0300, Ville Syrjälä wrote:
> > > > On Wed, Jun 12, 2019 at 11:
Quoting Jani Nikula (2019-06-13 09:44:14)
> Ensure intel_sdvo_regs.h is self-contained and remains that way.
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/Makefile.header-test | 1 +
> drivers/gpu/drm/i915/intel_sdvo_regs.h| 7 +++
> 2 files changed, 8 insertions(+)
>
> di
On Wed, Jun 12, 2019 at 10:47:22PM -0700, Lee, Shawn C wrote:
> Modify aux backlight enable sequence just like what we
> did for genernal eDP panel.
> 1. Setup PWM freq and brightness level before enable display backlight.
> 2. Add T8 (valid data to backlight enable) delay.
If we respect the on_de
On Wed, Jun 12, 2019 at 08:24:23PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We're now calling intel_pipe_config_compare(..., true) uncoditionally
> which means we're always going clobber the calculated M/N values with
> the old values if the fuzzy M/N check passes. That causes proble
Hi Dave, Daniel, on behalf of Joonas,
drm-intel-fixes-2019-06-13:
drm/i915 fixes for v5.2-rc5:
- Fix DMC firmware input validation to avoid buffer overflow
- Fix perf register access whitelist for userspace
- Fix DSI panel on GPD MicroPC
- Fix per-pixel alpha with CCS
- Fix HDMI audio for SDVO
B
On Thu, 13 Jun 2019, Chris Wilson wrote:
> Quoting Jani Nikula (2019-06-13 09:44:14)
>> Ensure intel_sdvo_regs.h is self-contained and remains that way.
>>
>> Signed-off-by: Jani Nikula
>> ---
>> drivers/gpu/drm/i915/Makefile.header-test | 1 +
>> drivers/gpu/drm/i915/intel_sdvo_regs.h| 7 +
Quoting Jani Nikula (2019-06-13 10:36:20)
> On Thu, 13 Jun 2019, Chris Wilson wrote:
> > Quoting Jani Nikula (2019-06-13 09:44:14)
> >> Ensure intel_sdvo_regs.h is self-contained and remains that way.
> >>
> >> Signed-off-by: Jani Nikula
> >> ---
> >> drivers/gpu/drm/i915/Makefile.header-test |
== Series Details ==
Series: series starting with [v2,1/3] drm/i915: make intel_sdvo_regs.h
self-contained
URL : https://patchwork.freedesktop.org/series/62002/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
4c21ec3a2fa6 drm/i915: make intel_sdvo_regs.h self-contained
f2f555746
== Series Details ==
Series: series starting with [v2,1/3] drm/i915: make intel_sdvo_regs.h
self-contained
URL : https://patchwork.freedesktop.org/series/62002/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: make intel_sdvo_regs.h self-conta
Ensure intel_sdvo_regs.h is self-contained and remains that way.
v2:
- include for __packed (Chris)
Cc: Chris Wilson
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/Makefile.header-test | 1 +
drivers/gpu/drm/i915/intel_sdvo_regs.h| 8
2 files changed, 9 insertions(+)
diff -
Quoting Jani Nikula (2019-06-13 11:08:18)
> Ensure intel_sdvo_regs.h is self-contained and remains that way.
>
> v2:
> - include for __packed (Chris)
>
> Cc: Chris Wilson
> Signed-off-by: Jani Nikula
Reviewed-by: Chris Wilson
-Chris
___
Intel-gfx ma
== Series Details ==
Series: series starting with [v2,1/3] drm/i915: make intel_sdvo_regs.h
self-contained
URL : https://patchwork.freedesktop.org/series/62002/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6256 -> Patchwork_13267
=
== Series Details ==
Series: series starting with [v2] drm/i915: make intel_sdvo_regs.h
self-contained (rev2)
URL : https://patchwork.freedesktop.org/series/62002/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
d6787a862416 drm/i915: make intel_sdvo_regs.h self-contained
4162eb
== Series Details ==
Series: series starting with [v2] drm/i915: make intel_sdvo_regs.h
self-contained (rev2)
URL : https://patchwork.freedesktop.org/series/62002/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915: make intel_sdvo_regs.h self-co
On 6/12/19 10:52 AM, Mauro Carvalho Chehab wrote:
> Convert the PM documents to ReST, in order to allow them to
> build with Sphinx.
>
> The conversion is actually:
> - add blank lines and identation in order to identify paragraphs;
> - fix tables markups;
> - add some lists markups;
> - m
Em Wed, 12 Jun 2019 17:25:39 -0700
"Srivatsa S. Bhat" escreveu:
> On 6/12/19 10:52 AM, Mauro Carvalho Chehab wrote:
> > Convert the PM documents to ReST, in order to allow them to
> > build with Sphinx.
> >
> > The conversion is actually:
> > - add blank lines and identation in order to identi
We already use a mutex to serialise i915_reset() and wedging, so all we
need it to link that into i915_request_wait() and we have our lock cycle
detection.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/intel_reset.c| 6 ++
drivers/gpu/drm/i915/i915_d
== Series Details ==
Series: series starting with [v2] drm/i915: make intel_sdvo_regs.h
self-contained (rev2)
URL : https://patchwork.freedesktop.org/series/62002/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6257 -> Patchwork_13268
==
refcount_t is our first line of defence against use-after-free, so let's
enable it for debugging.
Signed-off-by: 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
On Thu, Jun 13, 2019 at 01:28:42PM +0100, Chris Wilson wrote:
> refcount_t is our first line of defence against use-after-free, so let's
> enable it for debugging.
It seems a nice thing to have on debug by default and they promise no
performance impact.
Acked-by: Rodrigo Vivi
Well, I hope our C
On Thu, 2019-06-13 at 13:55 +0100, Guillaume Tucker wrote:
> On 06/06/2019 08:18, Ser, Simon wrote:
> > On Mon, 2019-06-03 at 12:54 +0100, Guillaume Tucker wrote:
> > > Add dependency to libatomic in order to be able to use the __atomic_*
> > > functions instead of the older __sync_* ones. This is
On 6/13/19 3:46 PM, Rodrigo Vivi wrote:
On Thu, Jun 13, 2019 at 01:28:42PM +0100, Chris Wilson wrote:
refcount_t is our first line of defence against use-after-free, so let's
enable it for debugging.
It seems a nice thing to have on debug by default and they promise no
performance impact.
Ack
On Thu, Jun 13, 2019 at 12:32:39PM +0300, Jani Nikula wrote:
>
> Hi Dave, Daniel, on behalf of Joonas,
>
> drm-intel-fixes-2019-06-13:
> drm/i915 fixes for v5.2-rc5:
> - Fix DMC firmware input validation to avoid buffer overflow
> - Fix perf register access whitelist for userspace
> - Fix DSI pan
On 06/06/2019 08:20, Ser, Simon wrote:
> On Mon, 2019-06-03 at 12:54 +0100, Guillaume Tucker wrote:
>> Replace calls to the older __sync_* functions with the new __atomic_*
>> standard ones. This fixes builds on some architectures, in particular
>> MIPS which doesn't have __sync_add_and_fetch_8 an
On 06/06/2019 08:26, Ser, Simon wrote:
> On Thu, 2019-06-06 at 10:21 +0300, Arkadiusz Hiler wrote:
>> On Mon, Jun 03, 2019 at 12:54:48PM +0100, Guillaume Tucker wrote:
>>> Add libatomic to the Fedora docker image so it can link binaries that
>>> use __atomic_* functions.
>>>
>>> Signed-off-by: Guil
On 06/06/2019 08:18, Ser, Simon wrote:
> On Mon, 2019-06-03 at 12:54 +0100, Guillaume Tucker wrote:
>> Add dependency to libatomic in order to be able to use the __atomic_*
>> functions instead of the older __sync_* ones. This is to enable
>> atomic operations on a wider number of architectures in
== Series Details ==
Series: drm/i915: Combine unbound/bound list tracking for objects
URL : https://patchwork.freedesktop.org/series/61952/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6248_full -> Patchwork_13251_full
Su
On Wed, 12 Jun 2019, Lucas De Marchi wrote:
> We are slowly converting dev_priv to i915 everywhere, spread into
> smaller series. While this is good to avoid unrelated breakages to other
> inflight patches, it's bad because inflight patches on nearby paths keep
> breaking. Paired with other code m
On 06/06/2019 14:16, Arkadiusz Hiler wrote:
> On Wed, Jun 05, 2019 at 09:18:09PM +0100, Guillaume Tucker wrote:
>> Add Docker image and Gitlab CI steps to run builds for the MIPS
>> architecture using Debian Buster.
>>
>> Signed-off-by: Guillaume Tucker
>> ---
>> .gitlab-ci.yml | 28 +
On Thu, 13 Jun 2019, Ville Syrjälä wrote:
> On Wed, Jun 12, 2019 at 10:47:22PM -0700, Lee, Shawn C wrote:
>> Modify aux backlight enable sequence just like what we
>> did for genernal eDP panel.
>> 1. Setup PWM freq and brightness level before enable display backlight.
>> 2. Add T8 (valid data to
== Series Details ==
Series: drm/i915: Refine i915_reset.lock_map
URL : https://patchwork.freedesktop.org/series/62017/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6258 -> Patchwork_13269
Summary
---
**FAILURE**
We already use a mutex to serialise i915_reset() and wedging, so all we
need it to link that into i915_request_wait() and we have our lock cycle
detection.
v2: Take error mutex for selftests
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/intel_reset.c| 6
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: David Airlie
Cc: Daniel Vetter
Cc: intel-gfx@lists.fre
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Because there is no need to check these functions, a number of local
functions can be made to return void to simplif
From: Tvrtko Ursulin
This time round series still starts with some implicit dev_priv removal, but
after in the following round the feedback was to not go with intel_uncore but
introduce intel_gt, most patches have been reworked to reflect this.
Also, while nosing around in the code I have spotte
From: Tvrtko Ursulin
More removal of implicit dev_priv from using old mmio accessors.
Furthermore these calls really operate on ggtt so it logically makes sense
if they take it as parameter.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 4 ++--
drivers/gpu/drm/i915/
We already use a mutex to serialise i915_reset() and wedging, so all we
need it to link that into i915_request_wait() and we have our lock cycle
detection.
v2.5: Take error mutex for selftests
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/intel_reset.c|
From: Tvrtko Ursulin
We have long been slighlty annoyed by the anonymous i915->gt.
Promote it to a separate structure and give it its own header.
This is a first step towards cleaning up the separation between i915 and gt.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_gt_ty
From: Tvrtko Ursulin
We need an easy way to get back to i915 and uncore.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_gt.c | 7 ++-
drivers/gpu/drm/i915/gt/intel_gt.h | 4 +++-
drivers/gpu/drm/i915/gt/intel_gt_types.h | 6 ++
drivers/gpu/drm/i915/i915_gem
From: Tvrtko Ursulin
More removal of implicit dev_priv from using old mmio accessors.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem.c | 42 ++---
1 file changed, 23 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/driv
From: Tvrtko Ursulin
Continuing the conversion and elimination of implicit dev_priv.
Signed-off-by: Tvrtko Ursulin
Suggested-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 4 +-
drivers/gpu/drm/i915/gt/intel_gt.c| 129 ++
drivers/gpu/drm/i915/gt
From: Tvrtko Ursulin
As it will grow in a following patch make a new home for it.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/gt/intel_gt.c | 19 +++
drivers/gpu/drm/i915/gt/intel_gt.h | 14 ++
drivers/gpu/drm/i9
From: Tvrtko Ursulin
Start using the newly introduced struct intel_gt to fuse together correct
logical init flow with uncore for more removal of implicit dev_priv in
mmio access.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_gt.c | 37 ++
drivers/g
From: Tvrtko Ursulin
More conversion of i915_gem_init_hw to uncore.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 10 +-
drivers/gpu/drm/i915/gt/intel_workarounds.h | 6 +++---
drivers/gpu/drm/i915/i915_gem.c | 4 ++--
3 files changed, 10
From: Tvrtko Ursulin
It will come useful in the next patch.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c| 1 +
drivers/gpu/drm/i915/gt/intel_engine_types.h | 2 ++
2 files changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/dri
From: Tvrtko Ursulin
More removal of implicit dev_priv from using old mmio accessors.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_mocs.c | 52 +---
drivers/gpu/drm/i915/gt/intel_mocs.h | 3 +-
drivers/gpu/drm/i915/i915_gem.c | 2 +-
3 files ch
From: Tvrtko Ursulin
More removal of implicit dev_priv from using old mmio accessors.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem.c | 2 +-
drivers/gpu/drm/i915/i915_gem_gtt.c | 102 ++--
drivers/gpu/drm/i915/i915_gem_gtt.h | 3 +-
3 files ch
From: Tvrtko Ursulin
Replace some gen6/7 open coded rmw with intel_uncore_rmw.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 41 +
1 file changed, 18 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i9
From: Tvrtko Ursulin
More removal of implicit dev_priv from using old mmio accessors.
Actually the top level function remains but is split into a part which
writes to i915 and part which operates on intel_gt in order to initialize
the hardware.
GuC and engines are the only odd ones out remainin
From: Tvrtko Ursulin
Since this part still operates on i915 and not intel_gt, move it to the
common (top-level) function.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem.c | 29 ++---
1 file changed, 22 insertions(+), 7 deletions(-)
diff --git a/drivers
From: Tvrtko Ursulin
More legacy mmio accessor removal. We pass in intel_gt explicitly allowing
code to use new intel_uncore_read/write helpers.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem.c| 2 +-
drivers/gpu/drm/i915/intel_wopcm.c | 31 --
From: Tvrtko Ursulin
Having made start to better code compartmentalization by introducing
struct intel_gt, continue the theme elsewhere in code by making functions
take parameters take what logically makes most sense for them instead of
the global struct drm_i915_private.
Signed-off-by: Tvrtko U
From: Tvrtko Ursulin
Having made start to better code compartmentalization by introducing
struct intel_gt, continue the theme elsewhere in code by making functions
take parameters take what logically makes most sense for them instead of
the global struct drm_i915_private.
Signed-off-by: Tvrtko U
From: Tvrtko Ursulin
It is more logical for ggtt invalidation to take ggtt as input parameter.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 51 ++---
drivers/gpu/drm/i915/i915_gem_gtt.h | 2 +-
2 files changed, 26 insertions(+), 27 deletions(
From: Tvrtko Ursulin
Having made start to better code compartmentalization by introducing
struct intel_gt, continue the theme elsewhere in code by making functions
take parameters take what logically makes most sense for them instead of
the global struct drm_i915_private.
Signed-off-by: Tvrtko U
From: Tvrtko Ursulin
This will come useful in the following patch.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 16 ++--
drivers/gpu/drm/i915/i915_gem_gtt.h | 1 +
2 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_
Quoting Tvrtko Ursulin (2019-06-13 14:35:12)
> From: Tvrtko Ursulin
>
> More removal of implicit dev_priv from using old mmio accessors.
>
> Furthermore these calls really operate on ggtt so it logically makes sense
> if they take it as parameter.
Yeah, I had expected them to take a vgpu, but t
Quoting Tvrtko Ursulin (2019-06-13 14:35:13)
> From: Tvrtko Ursulin
>
> We have long been slighlty annoyed by the anonymous i915->gt.
>
> Promote it to a separate structure and give it its own header.
>
> This is a first step towards cleaning up the separation between i915 and gt.
>
> Signed-o
Quoting Tvrtko Ursulin (2019-06-13 14:35:14)
> From: Tvrtko Ursulin
>
> As it will grow in a following patch make a new home for it.
>
> Signed-off-by: Tvrtko Ursulin
> ---
> drivers/gpu/drm/i915/Makefile | 1 +
> drivers/gpu/drm/i915/gt/intel_gt.c | 19 +++
> drivers/gpu
From: Tvrtko Ursulin
There is a lot of code in i915_gem_gtt.c which repeatadly dereferences
either ggtt or ppgtt in order to get to the vm. Cache those accesses in
local variables for better readability.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 254 ++
Quoting Tvrtko Ursulin (2019-06-13 14:35:15)
> From: Tvrtko Ursulin
>
> We need an easy way to get back to i915 and uncore.
>
> Signed-off-by: Tvrtko Ursulin
> ---
> drivers/gpu/drm/i915/gt/intel_gt.c | 7 ++-
> drivers/gpu/drm/i915/gt/intel_gt.h | 4 +++-
> drivers/gpu/drm/i91
Quoting Tvrtko Ursulin (2019-06-13 14:35:16)
> From: Tvrtko Ursulin
>
> Continuing the conversion and elimination of implicit dev_priv.
>
> Signed-off-by: Tvrtko Ursulin
> Suggested-by: Rodrigo Vivi
Reviewed-by: Chris Wilson
-Chris
___
Intel-gfx mai
Quoting Tvrtko Ursulin (2019-06-13 14:35:17)
> From: Tvrtko Ursulin
>
> Start using the newly introduced struct intel_gt to fuse together correct
> logical init flow with uncore for more removal of implicit dev_priv in
> mmio access.
>
> Signed-off-by: Tvrtko Ursulin
Looks fine, I might move i
Quoting Tvrtko Ursulin (2019-06-13 14:35:18)
> From: Tvrtko Ursulin
>
> More removal of implicit dev_priv from using old mmio accessors.
>
> Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.fre
Quoting Tvrtko Ursulin (2019-06-13 14:35:19)
> From: Tvrtko Ursulin
>
> More conversion of i915_gem_init_hw to uncore.
>
> Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https
Quoting Tvrtko Ursulin (2019-06-13 14:35:20)
> From: Tvrtko Ursulin
>
> It will come useful in the next patch.
>
> Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists
Quoting Tvrtko Ursulin (2019-06-13 14:35:20)
> From: Tvrtko Ursulin
>
> It will come useful in the next patch.
(Does this even constitute a functional change? ;)
> Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson
-Chris
___
Intel-gfx mailing
This series replaces calls to the __sync_* functions with the more
recent atomic_* ones defined in stdatomic.h in gem_create and
sw_sync. It also adds dependency on libatomic when required, that is
to say when the CPU architecture doesn't provide native support for
some atomic operations. This ma
Add conditional dependency on libatomic in order to be able to use the
__atomic_* functions instead of the older __sync_* ones. The
libatomic library is only needed when there aren't any native support
on the current architecture, so a linker test is used for this
purpose. This enables atomic ope
This fixes builds on some architectures, in particular MIPS which
doesn't have __sync_add_and_fetch_8 and __sync_val_compare_and_swap_8
for 64-bit variable handling.
* replace calls to the older __sync_* functions with the new atomic_*
standard ones
* use the _Atomic type modifier as required wi
Add libatomic to the Fedora docker image so it can link binaries that
use __atomic_* functions. Also explicitly add libatomic1 to Debian
docker images even though it's already installed as a dependency.
Signed-off-by: Guillaume Tucker
---
Dockerfile.debian | 1 +
Dockerfile.debian-arm64 |
Replace calls to the older __sync_* functions with the new atomic_*
standard ones to be consistent with other tests and improve
portability across CPU architectures. Add dependency of sw_sync on
libatomic.
Signed-off-by: Guillaume Tucker
---
tests/Makefile.am | 1 +
tests/meson.build | 8
Quoting Tvrtko Ursulin (2019-06-13 14:35:21)
> From: Tvrtko Ursulin
>
> More removal of implicit dev_priv from using old mmio accessors.
>
> Signed-off-by: Tvrtko Ursulin
Reviewed-by: Chris Wilson
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.fre
Quoting Tvrtko Ursulin (2019-06-13 14:35:22)
> From: Tvrtko Ursulin
>
> More removal of implicit dev_priv from using old mmio accessors.
>
> Signed-off-by: Tvrtko Ursulin
i915_gem_gtt.[ch] is an outlier at the moment, they need to migrate to
gt/ but are a clumsy mix of high and low level objec
Quoting Tvrtko Ursulin (2019-06-13 14:35:24)
> From: Tvrtko Ursulin
>
> More removal of implicit dev_priv from using old mmio accessors.
>
> Actually the top level function remains but is split into a part which
> writes to i915 and part which operates on intel_gt in order to initialize
> the ha
Quoting Tvrtko Ursulin (2019-06-13 14:35:25)
> From: Tvrtko Ursulin
>
> Since this part still operates on i915 and not intel_gt, move it to the
> common (top-level) function.
Whilst I do agree with the splitting, I will note that
intel_engines_resume() operates within gt :) You just haven't move
Add Docker image and Gitlab CI steps to run builds for the MIPS
architecture using Debian Stretch with backports.
Signed-off-by: Guillaume Tucker
---
.gitlab-ci.yml | 28
Dockerfile.debian-mips | 39 +++
meson-cross-mips.tx
This is to add MIPS builds to Gitlab CI.
v2:
- use stretch-backports rather than Buster
- explicitly require libatomic
Guillaume Tucker (1):
gitlab-ci: add build for MIPS
.gitlab-ci.yml | 28
Dockerfile.debian-mips | 39 ++
Quoting Tvrtko Ursulin (2019-06-13 14:35:27)
> From: Tvrtko Ursulin
>
> Having made start to better code compartmentalization by introducing
> struct intel_gt, continue the theme elsewhere in code by making functions
> take parameters take what logically makes most sense for them instead of
> the
Quoting Tvrtko Ursulin (2019-06-13 14:35:28)
> From: Tvrtko Ursulin
>
> Having made start to better code compartmentalization by introducing
> struct intel_gt, continue the theme elsewhere in code by making functions
> take parameters take what logically makes most sense for them instead of
> the
Quoting Tvrtko Ursulin (2019-06-13 14:35:29)
> From: Tvrtko Ursulin
>
> It is more logical for ggtt invalidation to take ggtt as input parameter.
>
> Signed-off-by: Tvrtko Ursulin
There's a great saying about not bringing logic into driver development.
Reviewed-by: Chris Wilson
-Chris
___
Quoting Tvrtko Ursulin (2019-06-13 14:35:31)
> From: Tvrtko Ursulin
>
> Having made start to better code compartmentalization by introducing
> struct intel_gt, continue the theme elsewhere in code by making functions
> take parameters take what logically makes most sense for them instead of
> the
Quoting Tvrtko Ursulin (2019-06-13 14:35:32)
> From: Tvrtko Ursulin
>
> There is a lot of code in i915_gem_gtt.c which repeatadly dereferences
> either ggtt or ppgtt in order to get to the vm. Cache those accesses in
> local variables for better readability.
There isn't a dereference though, it'
Op 13-06-2019 om 10:44 schreef Jani Nikula:
> Now that we have a new subdirectory for display code, continue by moving
> modesetting core code.
>
> display/intel_frontbuffer.h sticks out like a sore thumb, otherwise this
> is, again, a surprisingly clean operation.
>
> v2:
> - don't move intel_side
Hi Da.*,
A bit more meat on this PR, which should probably be expected given how light we
have been on the last 4.
drm-misc-fixes-2019-06-13:
meson: A few G12A fixes across the driver (Neil)
quirks: A couple quirks for GPD devices (Hans)
gem_shmem: Use writecombine when vmapping non-dmabuf BOs (
From: Greg Kroah-Hartman
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: David Airlie
Cc: Daniel Vett
On Thu, 13 Jun 2019, Greg Kroah-Hartman wrote:
> When calling debugfs functions, there is no need to ever check the
> return value. The function can work or not, but the code logic should
> never do something different based on this.
>
> Cc: Jani Nikula
> Cc: Joonas Lahtinen
> Cc: Rodrigo Vivi
On Wed, Jun 12, 2019 at 11:16:02PM -0300, Brian Starkey wrote:
> Add support in igt_kms for writeback connectors, with the ability
> to attach framebuffers.
>
> v5: Rebase and add DRM_CLIENT_CAP_WRITEBACK_CONNECTORS before
> drmModeGetResources()
Reviewed-by: Liviu Dudau
Thanks for updating thi
1 - 100 of 179 matches
Mail list logo
