== Series Details ==
Series: drm/i915/perf: Do not clear pollin for small user read buffers (rev2)
URL : https://patchwork.freedesktop.org/series/75085/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8190 -> Patchwork_17092
== Series Details ==
Series: drm/i915: Drop final few uses of drm_i915_private.engine
URL : https://patchwork.freedesktop.org/series/75095/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8190_full -> Patchwork_17091_full
It is wrong to block the user thread in the next poll when OA data is
already available which could not fit in the user buffer provided in
the previous read. In several cases the exact user buffer size is not
known. Blocking user space in poll can lead to data loss when the
buffer size used is
== Series Details ==
Series: drivers/gpu/drm/i915/selftests/i915_buddy.c: Fix bug
URL : https://patchwork.freedesktop.org/series/75090/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8190_full -> Patchwork_17090_full
On Wed, 25 Mar 2020 17:32:35 -0700, Umesh Nerlige Ramappa wrote:
>
> On Wed, Mar 25, 2020 at 11:20:19AM -0700, Ashutosh Dixit wrote:
> > It is wrong to block the user thread in the next poll when OA data is
> > already available which could not fit in the user buffer provided in
> > the previous
On Wed, Mar 25, 2020 at 11:20:19AM -0700, Ashutosh Dixit wrote:
It is wrong to block the user thread in the next poll when OA data is
already available which could not fit in the user buffer provided in
the previous read. In several cases the exact user buffer size is not
known. Blocking user
== Series Details ==
Series: drm/i915/perf: Do not clear pollin for small user read buffers
URL : https://patchwork.freedesktop.org/series/75085/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8189_full -> Patchwork_17089_full
== Series Details ==
Series: drm/i915: Drop final few uses of drm_i915_private.engine
URL : https://patchwork.freedesktop.org/series/75095/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8190 -> Patchwork_17091
Summary
We've migrated all the heavy users over to the intel_gt, and can finally
drop the last few users and with that the mirror in dev_priv->engine[].
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Andi Shyti
---
drivers/gpu/drm/i915/display/intel_overlay.c | 2 +-
== Series Details ==
Series: drivers/gpu/drm/i915/selftests/i915_buddy.c: Fix bug
URL : https://patchwork.freedesktop.org/series/75090/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8190 -> Patchwork_17090
Summary
---
Convert over to the new dynamic subtests for the per-engine tests, and
in the process switch over to for-each-physical engine iterators.
Signed-off-by: Chris Wilson
---
tests/i915/gem_ctx_shared.c | 140 +++-
1 file changed, 75 insertions(+), 65 deletions(-)
Convert over to the new dynamic subtests for the per-engine tests, and
in the process switch over to for-each-physical engine iterators.
Signed-off-by: Chris Wilson
---
tests/i915/gem_ctx_isolation.c | 109 -
1 file changed, 66 insertions(+), 43 deletions(-)
== Series Details ==
Series: drivers/gpu/drm/i915/selftests/i915_buddy.c: Fix bug
URL : https://patchwork.freedesktop.org/series/75090/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
11370081d24e drivers/gpu/drm/i915/selftests/i915_buddy.c: Fix bug
-:53: CHECK:SPACING: spaces
== Series Details ==
Series: drm/i915: Differentiate between aliasing-ppgtt and ggtt pinning
URL : https://patchwork.freedesktop.org/series/75078/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8188_full -> Patchwork_17088_full
igt_mm_config() calls ilog2() on the (pseudo)random 21-bit number
s>>12. Once in 2 million seeds, this is zero and ilog2 summons
the nasal demons.
There was an attempt to handle this case with a max(), but that's
too late; ms could already be something bizarre.
Given that the low 12 bits of s
== Series Details ==
Series: drm/i915/gem: Drop cached obj->bind_count (rev2)
URL : https://patchwork.freedesktop.org/series/74593/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8188_full -> Patchwork_17087_full
Summary
On 3/11/20 6:16 PM, Daniele Ceraolo Spurio wrote:
uC is a component of the GT, so it makes sense for the uC debugfs files
to be in the GT folder. A subfolder has been used to keep the same
structure we have for the code.
v2: use intel_* prefix (Jani), rebase on new gt_debugfs_register_files,
On Wed, 25 Mar 2020 12:25:59 -0700, Lionel Landwerlin wrote:
>
> On 25/03/2020 20:20, Ashutosh Dixit wrote:
> > It is wrong to block the user thread in the next poll when OA data is
> > already available which could not fit in the user buffer provided in
> > the previous read. In several cases the
== Series Details ==
Series: series starting with [1/2] drm/i915: Allow for different modes of
interruptible i915_active_wait
URL : https://patchwork.freedesktop.org/series/75076/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8188_full -> Patchwork_17086_full
== Series Details ==
Series: drm/i915/perf: Do not clear pollin for small user read buffers
URL : https://patchwork.freedesktop.org/series/75085/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8189 -> Patchwork_17089
On 25/03/2020 20:20, Ashutosh Dixit wrote:
It is wrong to block the user thread in the next poll when OA data is
already available which could not fit in the user buffer provided in
the previous read. In several cases the exact user buffer size is not
known. Blocking user space in poll can lead
== Series Details ==
Series: drm/i915/display: Return early after MISSING_CSAE for write_dp_sdp
URL : https://patchwork.freedesktop.org/series/75075/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8187_full -> Patchwork_17085_full
On 1/31/20 10:55 AM, Daniele Ceraolo Spurio wrote:
On 1/31/20 2:45 AM, Chris Wilson wrote:
We want to separate the utility functions for controlling the logical
ring context from the execlists submission mechanism (which is an
overgrown scheduler).
This is similar to Daniele's work to
On Mon, 23 Mar 2020, Daniel Vetter wrote:
> For two reasons:
>
> - The driver core clears this already for us after we're unloaded in
> __device_release_driver().
>
> - It's way too late, the drm_device ->release callback might massively
> outlive the underlying physical device, since a
It is wrong to block the user thread in the next poll when OA data is
already available which could not fit in the user buffer provided in
the previous read. In several cases the exact user buffer size is not
known. Blocking user space in poll can lead to data loss when the
buffer size used is
On 3/25/2020 11:03, Daniele Ceraolo Spurio wrote:
On 3/25/20 10:58 AM, John Harrison wrote:
On 3/11/2020 18:16, Daniele Ceraolo Spurio wrote:
we do call uc_fini if there is an issue while loading the GuC, so we
can't delete in there the logs we need to debug the load failure.
Moving the log
== Series Details ==
Series: drm/i915/gt: Stage the transfer of the virtual breadcrumb
URL : https://patchwork.freedesktop.org/series/75073/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8187_full -> Patchwork_17084_full
On 3/25/20 10:58 AM, John Harrison wrote:
On 3/11/2020 18:16, Daniele Ceraolo Spurio wrote:
we do call uc_fini if there is an issue while loading the GuC, so we
can't delete in there the logs we need to debug the load failure.
Moving the log free to driver remove ensures the logs stick around
On 3/11/2020 18:16, Daniele Ceraolo Spurio wrote:
we do call uc_fini if there is an issue while loading the GuC, so we
can't delete in there the logs we need to debug the load failure.
Moving the log free to driver remove ensures the logs stick around ong
enough for us to dump them.
I think
On Wed, 25 Mar 2020, Daniel Vetter wrote:
> On Fri, Mar 20, 2020 at 04:36:35PM +0200, Jani Nikula wrote:
>> Drop useless macro hiding the return. Fix superfluous whitespace. Rename
>> function to all lowercase.
>>
>> Signed-off-by: Jani Nikula
>
> We do lose the debug output, but then I don't
On Wed, 25 Mar 2020, Daniel Vetter wrote:
> Hm I guess the foo_to_i915 idea doesn't scale, we'd need C++ and add
> ->to_i915 to all of them somehow (but not even sure C++ is that powerful
> with it's abstraction, definitely last time around I looked at it and that
> was 20 years ago :-)
This was
On Wed, 25 Mar 2020, Daniel Vetter wrote:
> On Fri, Mar 20, 2020 at 04:36:32PM +0200, Jani Nikula wrote:
>> Convert all the DRM_* logging macros to the struct drm_device based
>> macros to provide device specific logging.
>>
>> No functional changes.
>
> Not done with the cocci from Wambui?
On 3/25/2020 10:14, Daniele Ceraolo Spurio wrote:
On 3/25/20 10:05 AM, John Harrison wrote:
On 3/11/2020 18:16, Daniele Ceraolo Spurio wrote:
Move the printers to the respective files for clarity. The
guc_load_status debugfs has been squashed in the guc_info one, has
having separate ones
On 3/25/20 10:05 AM, John Harrison wrote:
On 3/11/2020 18:16, Daniele Ceraolo Spurio wrote:
Move the printers to the respective files for clarity. The
guc_load_status debugfs has been squashed in the guc_info one, has
having separate ones wasn't very useful. The HuC debugfs has been
renamed
== Series Details ==
Series: drm/i915: Differentiate between aliasing-ppgtt and ggtt pinning
URL : https://patchwork.freedesktop.org/series/75078/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8188 -> Patchwork_17088
On 3/11/2020 18:16, Daniele Ceraolo Spurio wrote:
Move the printers to the respective files for clarity. The
guc_load_status debugfs has been squashed in the guc_info one, has
having separate ones wasn't very useful. The HuC debugfs has been
renamed huc_info to match.
v2: keep printing
== Series Details ==
Series: drm/i915: Differentiate between aliasing-ppgtt and ggtt pinning
URL : https://patchwork.freedesktop.org/series/75078/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
9a411725f19d drm/i915: Differentiate between aliasing-ppgtt and ggtt pinning
-:30:
== Series Details ==
Series: drm/i915/gem: Drop cached obj->bind_count (rev2)
URL : https://patchwork.freedesktop.org/series/74593/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8188 -> Patchwork_17087
Summary
---
On 3/11/2020 18:16, Daniele Ceraolo Spurio wrote:
We currently initialize HuC support based on GuC being enabled in
modparam; this means that huc_is_supported() can return false on HW that
does have a HuC when enable_guc=0. The rationale for this behavior is
that HuC requires GuC for
On 3/24/20 6:47 PM, Andi Shyti wrote:
Hi Daniele,
On Wed, Mar 11, 2020 at 06:16:25PM -0700, Daniele Ceraolo Spurio wrote:
Rebased on top of Andi's patch. Note that some discussion is still
ongoing on that patch.
Also dropped the patch that caused a const->non-const conversion and
fixed a
== Series Details ==
Series: drm/i915/gem: Drop cached obj->bind_count (rev2)
URL : https://patchwork.freedesktop.org/series/74593/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
52775c70f21b drm/i915/gem: Drop cached obj->bind_count
-:159: WARNING:LONG_LINE: line over 100
== Series Details ==
Series: series starting with [1/2] drm/i915: Allow for different modes of
interruptible i915_active_wait
URL : https://patchwork.freedesktop.org/series/75076/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8188 -> Patchwork_17086
== Series Details ==
Series: drm/i915/display: Return early after MISSING_CSAE for write_dp_sdp
URL : https://patchwork.freedesktop.org/series/75075/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8187 -> Patchwork_17085
== Series Details ==
Series: drm/i915/gt: Stage the transfer of the virtual breadcrumb
URL : https://patchwork.freedesktop.org/series/75073/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8187 -> Patchwork_17084
Summary
Userptr causes lockdep to complain when we are using the aliasing-ppgtt
(and ggtt, but for that it is rightfully so to complain about) in that
when we revoke the userptr we take a mutex which we also use to revoke
the mmaps. However, we only revoke mmaps for GGTT bindings and we never
allow
A nasty issue was found with the way we serialise the update of the GTT
(GPU virtual address space) on the GEM context and with execution via
execbuf. On update we serialise with ctx->mutex and attempt to rewrite
the GTT addresses stored within the context from inside a request (along
that
Allow some users the discretion to not immediately return on a normal
signal. Hopefully, they will opt to use TASK_KILLABLE instead.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_active.c | 6 --
drivers/gpu/drm/i915/i915_active.h | 6 +-
2 files changed, 9 insertions(+), 3
Avoid using the uninitialised len along the impossible error path to
shut the compiler up:
drivers/gpu/drm/i915/display/intel_dp.c:4928 intel_write_dp_sdp() error:
uninitialized symbol 'len'.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/display/intel_dp.c | 2 +-
1 file changed, 1
On 25/03/2020 13:00, Chris Wilson wrote:
We move the virtual breadcrumb from one physical engine to the next, if
the next virtual request is scheduled on a new physical engine. Since
the virtual context can only be in one signal queue, we need it to track
the current physical engine for the
We move the virtual breadcrumb from one physical engine to the next, if
the next virtual request is scheduled on a new physical engine. Since
the virtual context can only be in one signal queue, we need it to track
the current physical engine for the new breadcrumbs. However, to move
the list we
On 25/03/2020 12:02, Chris Wilson wrote:
If the caller allows and we do not have to wait for any signals,
immediately execute the work within the caller's process. By doing so we
avoid the overhead of scheduling a new task, and the latency in
executing it, at the cost of pulling that work back
On 25/03/2020 12:02, Chris Wilson wrote:
We dropped calling process_csb prior to handling direct submission in
order to avoid the nesting of spinlocks and lift process_csb() and the
majority of the tasklet out of irq-off. However, we do want to avoid
ksoftirqd latency in the fast path, so try
== Series Details ==
Series: series starting with [1/2] drm/i915/execlists: Pull tasklet
interrupt-bh local to direct submission
URL : https://patchwork.freedesktop.org/series/75068/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8186 -> Patchwork_17083
Hi Ingo,
On Wed, Mar 25, 2020 at 1:59 PM Ingo Molnar wrote:
>
>
> * Masahiro Yamada wrote:
>
> > This series of cleanups was prompted by Linus:
> > https://lkml.org/lkml/2020/3/12/726
> >
> > First, this series drop always-on CONFIG_AS_* options.
> > Some of those options were introduced in old
CONFIG_AS_MOVNTDQA was introduced by commit 0b1de5d58e19 ("drm/i915:
Use SSE4.1 movntdqa to accelerate reads from WC memory").
We raise the minimal supported binutils version from time to time.
The last bump was commit 1fb12b35e5ff ("kbuild: Raise the minimum
required binutils version to 2.21").
Tested-by: You-Sheng Yang
signature.asc
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Hi i915 maintainers,
On Mon, Mar 23, 2020 at 11:12 AM Masahiro Yamada wrote:
>
> CONFIG_AS_MOVNTDQA was introduced by commit 0b1de5d58e19 ("drm/i915:
> Use SSE4.1 movntdqa to accelerate reads from WC memory").
>
> We raise the minimal supported binutils version from time to time.
> The last
This series of cleanups was prompted by Linus:
https://lkml.org/lkml/2020/3/12/726
First, this series drop always-on CONFIG_AS_* options.
Some of those options were introduced in old days.
For example, the check for CONFIG_AS_CFI dates back to 2006.
We raise the minimal tool versions from time
If the caller allows and we do not have to wait for any signals,
immediately execute the work within the caller's process. By doing so we
avoid the overhead of scheduling a new task, and the latency in
executing it, at the cost of pulling that work back into the immediate
context. (Sometimes we
We dropped calling process_csb prior to handling direct submission in
order to avoid the nesting of spinlocks and lift process_csb() and the
majority of the tasklet out of irq-off. However, we do want to avoid
ksoftirqd latency in the fast path, so try and pull the interrupt-bh
local to direct
== Series Details ==
Series: drm/i915/execlists: Drop setting sibling priority hint on virtual
engines
URL : https://patchwork.freedesktop.org/series/75063/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8185_full -> Patchwork_17081_full
== Series Details ==
Series: drm/i915/selftests: Measure the energy consumed while in RC6 (rev7)
URL : https://patchwork.freedesktop.org/series/75035/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8185 -> Patchwork_17082
Quoting Tvrtko Ursulin (2020-03-25 10:43:55)
>
> On 25/03/2020 10:13, Chris Wilson wrote:
> > We set the priority hint on execlists to avoid executing the tasklet for
> > when we know that there will be no change in execution order. However,
> > as we set it from the virtual engine for all
== Series Details ==
Series: drm/i915/execlists: Drop setting sibling priority hint on virtual
engines
URL : https://patchwork.freedesktop.org/series/75063/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8185 -> Patchwork_17081
On 25/03/2020 10:13, Chris Wilson wrote:
We set the priority hint on execlists to avoid executing the tasklet for
when we know that there will be no change in execution order. However,
as we set it from the virtual engine for all siblings, but only one
physical engine may respond, we leave the
We set the priority hint on execlists to avoid executing the tasklet for
when we know that there will be no change in execution order. However,
as we set it from the virtual engine for all siblings, but only one
physical engine may respond, we leave the hint set on the others
stopping direct
Measure and compare the energy consumed, as reported by the rapl MSR,
by the GPU while in RC0 and RC6 states. Throw an error if RC6 does not
at least halve the energy consumption of RC0, as this more than likely
means we failed to enter RC0 correctly.
If we can't measure the energy draw with the
== Series Details ==
Series: drm/i915/selftests: Measure the energy consumed while in RC6 (rev6)
URL : https://patchwork.freedesktop.org/series/75035/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8185 -> Patchwork_17080
== Series Details ==
Series: drm_device managed resources (rev8)
URL : https://patchwork.freedesktop.org/series/73633/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8185_full -> Patchwork_17078_full
Summary
---
Measure and compare the energy consumed, as reported by the rapl MSR,
by the GPU while in RC0 and RC6 states. Throw an error if RC6 does not
at least halve the energy consumption of RC0, as this more than likely
means we failed to enter RC0 correctly.
If we can't measure the energy draw with the
Hi Chris,
On Wed, Mar 25, 2020 at 08:10:56AM +, Chris Wilson wrote:
> Measure and compare the energy consumed, as reported by the rapl MSR,
> by the GPU while in RC0 and RC6 states. Throw an error if RC6 does not
> at least halve the energy consumption of RC0, as this more than likely
> means
Quoting Andi Shyti (2020-03-25 08:58:54)
> Hi Chris,
>
> On Wed, Mar 25, 2020 at 08:10:56AM +, Chris Wilson wrote:
> > Measure and compare the energy consumed, as reported by the rapl MSR,
> > by the GPU while in RC0 and RC6 states. Throw an error if RC6 does not
> > at least halve the energy
On Fri, Mar 20, 2020 at 04:36:38PM +0200, Jani Nikula wrote:
> Prefer drm_dbg() over DRM_DEV_DEBUG_DRIVER() and drm_err() over
> dev_err().
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_wopcm.c | 22 ++
> 1 file changed, 10 insertions(+), 12 deletions(-)
On Tue, Mar 24, 2020 at 10:42 PM Sam Ravnborg wrote:
>
> On Tue, Mar 24, 2020 at 09:39:36PM +0100, Daniel Vetter wrote:
> > The cleanup here is somewhat tricky, since we can't tell apart the
> > allocated minor index from 0. So register a cleanup action first, and
> > if the index allocation
== Series Details ==
Series: series starting with [01/21] Revert "drm/i915/gem: Drop relocation
slowpath"
URL : https://patchwork.freedesktop.org/series/75026/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8183_full -> Patchwork_17071_full
== Series Details ==
Series: drm/i915/selftests: Measure the energy consumed while in RC6 (rev5)
URL : https://patchwork.freedesktop.org/series/75035/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8185 -> Patchwork_17079
On Tue, Mar 24, 2020 at 10:36 PM Sam Ravnborg wrote:
>
> On Mon, Mar 23, 2020 at 03:49:21PM +0100, Daniel Vetter wrote:
> > The cleanup here is somewhat tricky, since we can't tell apart the
> > allocated minor index from 0. So register a cleanup action first, and
> > if the index allocation
On Fri, Mar 20, 2020 at 04:36:37PM +0200, Jani Nikula wrote:
> Convert all the DRM_* logging macros to the struct drm_device based
> macros to provide device specific logging.
>
> No functional changes.
>
> Generated using the following semantic patch, originally written by
> Wambui Karuga ,
On Fri, Mar 20, 2020 at 04:36:36PM +0200, Jani Nikula wrote:
> Convert all the DRM_* logging macros to the struct drm_device based
> macros to provide device specific logging.
>
> No functional changes.
>
> Generated using the following semantic patch, originally written by
> Wambui Karuga ,
On Fri, Mar 20, 2020 at 04:36:35PM +0200, Jani Nikula wrote:
> Drop useless macro hiding the return. Fix superfluous whitespace. Rename
> function to all lowercase.
>
> Signed-off-by: Jani Nikula
We do lose the debug output, but then I don't think we'll do much bug
hunting in here anytime soon,
On Fri, Mar 20, 2020 at 04:36:33PM +0200, Jani Nikula wrote:
> Signed-off-by: Jani Nikula
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/display/intel_connector.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_connector.c
On Fri, Mar 20, 2020 at 04:36:34PM +0200, Jani Nikula wrote:
> Convert all the DRM_* logging macros to the struct drm_device based
> macros to provide device specific logging.
>
> No functional changes.
>
> Generated using the following semantic patch, originally written by
> Wambui Karuga ,
On Fri, Mar 20, 2020 at 04:36:32PM +0200, Jani Nikula wrote:
> Convert all the DRM_* logging macros to the struct drm_device based
> macros to provide device specific logging.
>
> No functional changes.
Not done with the cocci from Wambui? Please add usual blurb if done with
cocci's help.
>
>
On Fri, Mar 20, 2020 at 04:36:30PM +0200, Jani Nikula wrote:
> Convert all the DRM_* logging macros to the struct drm_device based
> macros to provide device specific logging.
>
> No functional changes.
>
> Generated using the following semantic patch, originally written by
> Wambui Karuga ,
On Fri, Mar 20, 2020 at 04:36:31PM +0200, Jani Nikula wrote:
> Convert all the DRM_* logging macros to the struct drm_device based
> macros to provide device specific logging.
>
> No functional changes.
>
> Generated using the following semantic patch, originally written by
> Wambui Karuga ,
On Fri, Mar 20, 2020 at 04:36:29PM +0200, Jani Nikula wrote:
> Convert all the DRM_* logging macros to the struct drm_device based
> macros to provide device specific logging.
>
> No functional changes.
>
> Generated using the following semantic patch, originally written by
> Wambui Karuga ,
On Fri, Mar 20, 2020 at 04:36:28PM +0200, Jani Nikula wrote:
> Convert all the DRM_* logging macros to the struct drm_device based
> macros to provide device specific logging.
>
> No functional changes.
>
> Generated using the following semantic patch, originally written by
> Wambui Karuga ,
On Fri, Mar 20, 2020 at 04:36:27PM +0200, Jani Nikula wrote:
> Convert all the DRM_* logging macros to the struct drm_device based
> macros to provide device specific logging.
>
> No functional changes.
>
> Generated using the following semantic patch, originally written by
> Wambui Karuga ,
== Series Details ==
Series: drm_device managed resources (rev8)
URL : https://patchwork.freedesktop.org/series/73633/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8185 -> Patchwork_17078
Summary
---
**SUCCESS**
On Fri, Mar 20, 2020 at 04:36:26PM +0200, Jani Nikula wrote:
> Convert all the DRM_* logging macros to the struct drm_device based
> macros to provide device specific logging.
>
> No functional changes.
>
> Generated using the following semantic patch, originally written by
> Wambui Karuga ,
== Series Details ==
Series: drm_device managed resources (rev8)
URL : https://patchwork.freedesktop.org/series/73633/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.6.0
Commit: mm/sl[uo]b: export __kmalloc_track(_node)_caller
Okay!
== Series Details ==
Series: drm_device managed resources (rev8)
URL : https://patchwork.freedesktop.org/series/73633/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
5c1fd37276a0 mm/sl[uo]b: export __kmalloc_track(_node)_caller
-:58: WARNING:NO_AUTHOR_SIGN_OFF: Missing
Measure and compare the energy consumed, as reported by the rapl MSR,
by the GPU while in RC0 and RC6 states. Throw an error if RC6 does not
at least halve the energy consumption of RC0, as this more than likely
means we failed to enter RC0 correctly.
If we can't measure the energy draw with the
On 2020-03-24 at 17:53:08 +0200, Jani Nikula wrote:
> On Tue, 24 Mar 2020, Anshuman Gupta wrote:
> > New i915_pm_lpsp igt solution approach relies on connector specific
> > debugfs attribute i915_lpsp_info, it exposes whether an output is
> > capable of driving lpsp and exposes lpsp enablement
94 matches
Mail list logo
