Hi Daniel
Am 28.02.20 um 18:43 schrieb Daniel Vetter:
> On Fri, Feb 28, 2020 at 12:46 PM Thomas Zimmermann
> wrote:
>>
>> Hi
>>
>> Am 28.02.20 um 09:40 schrieb Daniel Vetter:
>>> On Fri, Feb 28, 2020 at 8:44 AM Thomas Zimmermann
>>> wrote:
Hi Daniel
Am 27.02.20 um 19:15 sch
commit 83a0a2ea0b991927e42984be220329e776ce7137
Author: Ard Biesheuvel
Date: Fri Jul 20 10:47:18 2018 +0900
efi/x86: Prevent reentrant firmware calls in mixed mode
Signed-off-by: Chris Wilson
---
arch/x86/platform/efi/efi_64.c | 32
1 file changed, 16 ins
Whenever we walk along the dma-fence-chain, we prune signaled links to
keep the chain nice and tidy. This leads to situations where we can
prune a link and report the earlier fence as the target seqno --
violating our own consistency checks that the seqno is not more advanced
than the last element
Fixes: a88b6e4cbafd ("drm/i915: Allow specification of parallel execbuf")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Lionel Landwerlin
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 10 +++---
include/uapi/drm/i915_drm.h| 7 ---
2 files changed, 11 ins
We only use sentinel requests for "preempt-to-idle" passes, so assert
that they are the only request in a new submission.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_l
Extend i915_request_await_active() to be able to asynchronously wait on
all the tracked timelines simultaneously.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_active.c | 51 +++---
drivers/gpu/drm/i915/i915_active.h | 5 ++-
drivers/gpu/drm/i915/i915_vma.c
To prevent the context from proceeding past the end of the request as we
unwind, we embed a semaphore into the footer of each request. (If the
context were to skip past the end of the request as we perform the
preemption, next time we reload the context it's RING_HEAD would be past
the RING_TAIL an
As we no longer stash anything inside i915_vma under the exclusive
protection of struct_mutex, we do not need to revoke the i915_vma
stashes before dropping struct_mutex to handle pagefaults. Knowing that
we must drop the struct_mutex while keeping the eb->vma around, means
that we are required to
We wish that the scheduler emit the context modification commands prior
to enabling the oa_config, for which we must explicitly inform it of the
ordering constraints. This is especially important as we now wait for
the final oa_config setup to be completed and as this wait may be on a
distinct cont
For conveniences of callers that just want to use an i915_active to
track a wide array of concurrent timelines, wrap the base i915_active
struct inside a kref. This i915_active will self-destruct after use.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_active.c | 53 +
Inside dma-fence-chain, we use a cmpxchg on an RCU-protected pointer. To
avoid the sparse warning for using the RCU pointer directly, we have to
cast away the __rcu annotation. However, we don't need to use void*
everywhere and can stick to the dma_fence*.
Signed-off-by: Chris Wilson
---
drivers
Use the same engine_idle_release() routine for cleaning all old
ctx->engine[] state, closing any potential races with concurrent execbuf
submission.
v2ish: Use the ce->pin_count to close the execbuf gap.
Closes: https://gitlab.freedesktop.org/drm/intel/issues/1241
Signed-off-by: Chris Wilson
Cc:
A few very simple testcases to exercise the dma-fence-chain API.
Signed-off-by: Chris Wilson
---
drivers/dma-buf/Makefile | 3 +-
drivers/dma-buf/selftests.h | 1 +
drivers/dma-buf/st-dma-fence-chain.c | 713 +++
3 files changed, 716 insertions(+)
Allow the callers to supply a dma-fence-proxy for asynchronous waiting on
future fences.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_syncobj.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 4
If a syncobj has not yet been assigned, treat it as a future fence and
install and wait upon a dma-fence-proxy. The proxy will be replace by
the real fence later, and that fence will be responsible for signaling
our waiter.
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/gem/i915_gem_execbuffer
We still need to wait for the initial OA configuration to happen
before we enable OA report writes to the OA buffer.
Reported-by: Lionel Landwerlin
Fixes: 15d0ace1f876 ("drm/i915/perf: execute OA configuration from command
stream")
Testcase: igt/perf/stream-open-close
Signed-off-by: Chris Wilson
Often we need to create a fence for a future event that has not yet been
associated with a fence. We can store a proxy fence, a placeholder, in
the timeline and replace it later when the real fence is known. Any
listeners that attach to the proxy fence will automatically be signaled
when the real f
As setup takes a long time, the user may close the context during the
construction of the execbuf. In order to make sure we correctly track
all outstanding work with non-persistent contexts, we need to serialise
the submission with the context closure and mop up any leaks.
Signed-off-by: Chris Wil
Let userspace know if they can trust timeslicing by including it as part
of the I915_PARAM_HAS_SCHEDULER::I915_SCHEDULER_CAP_TIMESLICING
v2: Only declare timeslicing if we can safely preempt userspace.
Fixes: 8ee36e048c98 ("drm/i915/execlists: Minimalistic timeslicing")
Signed-off-by: Chris Wilso
If we find ourselves waiting on a MI_SEMAPHORE_WAIT, either within the
user batch or in our own preamble, the engine raises a
GT_WAIT_ON_SEMAPHORE interrupt. We can unmask that interrupt and so
respond to a semaphore wait by yielding the timeslice, if we have
another context to yield to!
The only
With the goal of removing the serialisation from around execbuf, we will
no longer have the privilege of there being a single execbuf in flight
at any time and so will only be able to inspect the user's flags within
the carefully controlled execbuf context. i915_gem_evict_for_node() is
the only use
If a context is banned even before we submit our first request to it,
report the failure before we attempt to allocate any resources for the
context.
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gt/intel_context.c | 5 +
1 file changed, 5 insertions(+)
dif
For our convenience, and to avoid frequent allocations, we placed some
lists we use for execbuf inside the common i915_vma struct. As we look
to parallelise execbuf, such fields guarded by the struct_mutex BKL must
be pulled under local control. Instead of using the i915_vma as our
primary means of
Under ideal circumstances, the driver should be able to keep the GPU
fully saturated with work. Measure how close to ideal we get under the
harshest of conditions with no user payload.
Signed-off-by: Chris Wilson
---
.../drm/i915/selftests/i915_perf_selftests.h | 1 +
drivers/gpu/drm/i915/sel
On Mon, Mar 2, 2020 at 9:14 AM Thomas Zimmermann wrote:
>
> Hi Daniel
>
> Am 28.02.20 um 18:43 schrieb Daniel Vetter:
> > On Fri, Feb 28, 2020 at 12:46 PM Thomas Zimmermann
> > wrote:
> >>
> >> Hi
> >>
> >> Am 28.02.20 um 09:40 schrieb Daniel Vetter:
> >>> On Fri, Feb 28, 2020 at 8:44 AM Thomas
Hi!
I get a conflict when merging drm-next into drm-tip as part of 'dim
push-branch'.
The conflicting patches appear to be
commit 1c4d821db919366034dc9ff4c01b4b0da0b8e30f
Author: Anshuman Gupta
Date: Thu Oct 3 13:47:37 2019 +0530
drm/i915/tgl: Switch between dc3co and dc5 based on
On Sat, 29 Feb 2020, Daniel Vetter wrote:
> On Sat, Feb 29, 2020 at 12:17 PM Sam Ravnborg wrote:
>> The header-check infrastructure was dropped again - see:
>> fcbb8461fd2376ba3782b5b8bd440c929b8e4980
>
> Uh I'm disappoint :-/
To say the least. I thought it was a good *opt-in* feature for whoeve
On Mon, 02 Mar 2020, Thomas Zimmermann wrote:
> I get a conflict when merging drm-next into drm-tip as part of 'dim
> push-branch'.
It's mine, doing drm-intel-fixes, I'll take care of it.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
_
On Thu, 27 Feb 2020, Jani Nikula wrote:
> Hi all -
>
> The following commits have been marked as Cc: stable or fixing something
> in v5.6-rc3 or earlier, but failed to cherry-pick to
> drm-intel-fixes. Please see if they are worth backporting, and please do
> so if they are.
>
> Failed to cherry-p
On Mon, Mar 02, 2020 at 11:22:34AM +0200, Jani Nikula wrote:
> On Sat, 29 Feb 2020, Daniel Vetter wrote:
> > On Sat, Feb 29, 2020 at 12:17 PM Sam Ravnborg wrote:
> >> > > > + /**
> >> > > > + * @managed:
> >> > > > + *
> >> > > > + * Managed resources linked to the lifetime of
Op 02-03-2020 om 09:57 schreef Chris Wilson:
> As we no longer stash anything inside i915_vma under the exclusive
> protection of struct_mutex, we do not need to revoke the i915_vma
> stashes before dropping struct_mutex to handle pagefaults. Knowing that
> we must drop the struct_mutex while keepi
On Mon, Mar 02, 2020 at 11:22:34AM +0200, Jani Nikula wrote:
> On Sat, 29 Feb 2020, Daniel Vetter wrote:
> > On Sat, Feb 29, 2020 at 12:17 PM Sam Ravnborg wrote:
> >> The header-check infrastructure was dropped again - see:
> >> fcbb8461fd2376ba3782b5b8bd440c929b8e4980
> >
> > Uh I'm disappoint :
On 2/28/20 8:52 PM, Souza, Jose wrote:
On Fri, 2020-02-28 at 12:21 +0200, Petri Latvala wrote:
On Thu, Feb 27, 2020 at 11:42:03PM +, Souza, Jose wrote:
The following changes since commit
efcfa03ae6100dfe523ebf612e03c3a90fc4c794:
linux-firmware: Update firmware file for Intel Bluetooth
On Fri, Feb 28, 2020 at 06:52:01PM +, Souza, Jose wrote:
> On Fri, 2020-02-28 at 12:21 +0200, Petri Latvala wrote:
> > On Thu, Feb 27, 2020 at 11:42:03PM +, Souza, Jose wrote:
> > > The following changes since commit
> > > efcfa03ae6100dfe523ebf612e03c3a90fc4c794:
> > >
> > > linux-firmw
On 02/03/2020 10:57, Chris Wilson wrote:
We still need to wait for the initial OA configuration to happen
before we enable OA report writes to the OA buffer.
Reported-by: Lionel Landwerlin
Fixes: 15d0ace1f876 ("drm/i915/perf: execute OA configuration from command
stream")
Testcase: igt/perf/st
On Gen11 powergating half the execution units is a functional
requirement when using the VME samplers. Not fullfilling this
requirement can lead to hangs.
This unfortunately plays fairly poorly with the NOA requirements. NOA
requires a stable power configuration to maintain its configuration.
As
A little bit of history :
Back when i915-perf was introduced (4.13), there was no way to
dynamically add new OA configurations to i915. Only the generated
configs baked in at build time were allowed.
It quickly became obvious that we would need to allow applications
to upload their
== Series Details ==
Series: series starting with [1/2] trace: Export anonymous tracing
URL : https://patchwork.freedesktop.org/series/74117/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8037_full -> Patchwork_16775_full
S
On Thu, 27 Feb 2020, Ville Syrjälä wrote:
> On Thu, Feb 27, 2020 at 06:12:53PM +0200, Jani Nikula wrote:
>> Having an array pipe_crc[I915_MAX_PIPES] in struct drm_i915_private
>> should be an obvious clue this should be located in struct intel_crtc
>> instead. Make it so.
>>
>> As a side-effect,
On Thu, 27 Feb 2020, Ville Syrjälä wrote:
> On Thu, Feb 27, 2020 at 04:53:59PM +0200, Jani Nikula wrote:
>> Finish the job started in d28ae3b28187 ("drm/i915: split out
>> intel_dram.[ch] from i915_drv.c") by moving struct dram_dimm_info and
>> dram_channel_info inside intel_dram.c, the only user
On Sun, Mar 01, 2020 at 03:52:48PM +, Chris Wilson wrote:
> Rather than put sensitive, and often voluminous, user details into a
> global dmesg, report the error and debug messages directly back to the
> user via the kernel tracing mechanism.
>
> Signed-off-by: Chris Wilson
> Cc: Steven Roste
On Fri, 28 Feb 2020, Chris Wilson wrote:
> Quoting Jani Nikula (2020-02-27 17:00:47)
>> Shrink i915_drv.h a bit by moving watermark structs where they are
>> needed.
>>
>> Signed-off-by: Jani Nikula
>
> Series is
> Reviewed-by: Chris Wilson
Thanks, pushed 1-2 to dinq, will need to rebase 3.
B
This series addresses below drm_fb_helper tasks from
Documentation/gpu/todo.rst.
- The max connector argument for drm_fb_helper_init() isn't used
anymore and can be removed.
- The helper doesn't keep an array of connectors anymore so these can
be removed: drm_fb_helper_single_add_all_connecto
The max connector argument for drm_fb_helper_init() isn't used anymore
hence remove it.
All the drm_fb_helper_init() calls are modified with below sementic
patch.
@@
expression E1, E2, E3;
@@
- drm_fb_helper_init(E1,E2, E3)
+ drm_fb_helper_init(E1,E2)
Signed-off-by: Pankaj Bharadiya
---
driv
drm_fb_helper_{add,remove}_one_connector() are dummy functions now
and serve no purpose. Hence remove their calls.
This is the preparatory step for removing the
drm_fb_helper_{add,remove}_one_connector() functions from
drm_fb_helper.h
Signed-off-by: Pankaj Bharadiya
---
drivers/gpu/drm/i915/dis
drm_fb_helper_{add,remove}_one_connector() are dummy functions now
and serve no purpose. Hence remove their calls.
This is the preparatory step for removing the
drm_fb_helper_{add,remove}_one_connector() functions from
drm_fb_helper.h
Signed-off-by: Pankaj Bharadiya
---
drivers/gpu/drm/radeon/r
drm_fb_helper_{add,remove}_one_connector() are dummy functions now
and serve no purpose. Hence remove their calls.
This is the preparatory step for removing the
drm_fb_helper_{add,remove}_one_connector() functions from
drm_fb_helper.h
Signed-off-by: Pankaj Bharadiya
---
.../drm/amd/display/amdg
drm_fb_helper_single_add_all_connectors(), drm_fb_helper_add_one_connector()
and drm_fb_helper_remove_one_connector() doesn't keep an array of
connectors anymore and are just dummy. Now we have no callers to these
functions hence remove them.
Signed-off-by: Pankaj Bharadiya
---
include/drm/drm_f
drm_fb_helper_{add,remove}_one_connector() and
drm_fb_helper_single_add_all_connectors() are dummy functions now
and serve no purpose. Hence remove their calls.
This is the preparatory step for removing the
drm_fb_helper_{add,remove}_one_connector() functions from
drm_fb_helper.h
This removal is
drm_device pointer is not getting used in tc358764_detach() anymore,
hence remove it.
This fixes below warning.
drivers/gpu/drm/bridge/tc358764.c: In function ‘tc358764_detach’:
drivers/gpu/drm/bridge/tc358764.c:386:21: warning: unused variable ‘drm’
[-Wunused-variable]
struct drm_device *drm
nouveau_drm pointer is not getting used anymore in
nv50_mstm_{register,destroy}_connector functions, hence remove it.
This fixes below warning.
drivers/gpu/drm/nouveau/dispnv50/disp.c: In function
‘nv50_mstm_destroy_connector’:
drivers/gpu/drm/nouveau/dispnv50/disp.c:1263:22: warning: unused var
Remove completed drm_fb_helper tasks from todo list.
Signed-off-by: Pankaj Bharadiya
---
Documentation/gpu/todo.rst | 15 ---
1 file changed, 4 insertions(+), 11 deletions(-)
diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index ccf5e8e34222..98d8782e1440 100644
On Thu, 2020-02-27 at 18:20 +0200, Ville Syrjälä wrote:
> On Tue, Feb 25, 2020 at 05:00:43PM +0200, Stanislav Lisovskiy wrote:
> > According to BSpec 53998, we should try to
> > restrict qgv points, which can't provide
> > enough bandwidth for desired display configuration.
> >
> > Currently we ar
Hi Pankaj,
Thank you for the patch.
You can squash this with the patch that introduced the issue in the same
series. Otherwise we will be left with a compilation breakage in the
history, which could be annoying when bisecting issues.
On Mon, Mar 02, 2020 at 06:26:47PM +0530, Pankaj Bharadiya wro
Hi Pankaj,
Thank you for the patch.
On Mon, Mar 02, 2020 at 06:26:48PM +0530, Pankaj Bharadiya wrote:
> drm_fb_helper_single_add_all_connectors(), drm_fb_helper_add_one_connector()
> and drm_fb_helper_remove_one_connector() doesn't keep an array of
s/doesn't/don't/
> connectors anymore and are
Hi Pankaj,
Thank you for the patch.
On Mon, Mar 02, 2020 at 06:26:49PM +0530, Pankaj Bharadiya wrote:
> Remove completed drm_fb_helper tasks from todo list.
>
> Signed-off-by: Pankaj Bharadiya
> ---
> Documentation/gpu/todo.rst | 15 ---
> 1 file changed, 4 insertions(+), 11 deleti
Hi Pankaj,
Thank you for the patch.
On Mon, Mar 02, 2020 at 06:26:46PM +0530, Pankaj Bharadiya wrote:
> nouveau_drm pointer is not getting used anymore in
> nv50_mstm_{register,destroy}_connector functions, hence remove it.
>
> This fixes below warning.
>
> drivers/gpu/drm/nouveau/dispnv50/disp
On Sun, Mar 01, 2020 at 02:06:00PM +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Clean up DPLL output/refclock tracking (rev2)
> URL : https://patchwork.freedesktop.org/series/73977/
> State : failure
>
> [...]
> Possible regressions
>
> * igt@kms_cursor_lega
Hi
Am 02.03.20 um 13:56 schrieb Pankaj Bharadiya:
> The max connector argument for drm_fb_helper_init() isn't used anymore
> hence remove it.
>
> All the drm_fb_helper_init() calls are modified with below sementic
> patch.
>
> @@
> expression E1, E2, E3;
> @@
> - drm_fb_helper_init(E1,E2, E3)
>
On Fri, Feb 28, 2020 at 04:48:06PM -0800, Vivek Kasireddy wrote:
> On some platforms such as Elkhart Lake, although we may use DDI D
> to drive a connector, we have to use PHY A (Combo Phy PORT A) to
> detect the hotplug interrupts as per the spec because there is no
> one-to-one mapping between DD
== Series Details ==
Series: efi/x86: Protect rtc_lock from interrupts
URL : https://patchwork.freedesktop.org/series/74127/
State : failure
== Summary ==
Applying: efi/x86: Protect rtc_lock from interrupts
Using index info to reconstruct a base tree...
M arch/x86/platform/efi/efi_64.c
F
== Series Details ==
Series: drm/i915: Clean up DPLL output/refclock tracking (rev2)
URL : https://patchwork.freedesktop.org/series/73977/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8032_full -> Patchwork_16764_full
Summ
== Series Details ==
Series: series starting with [01/22] drm/i915/gem: Consolidate ctx->engines[]
release
URL : https://patchwork.freedesktop.org/series/74131/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
15d2ef066485 drm/i915/gem: Consolidate ctx->engines[] release
efe30d6b
On 02/03/2020 12:31, Lionel Landwerlin wrote:
On Gen11 powergating half the execution units is a functional
requirement when using the VME samplers. Not fullfilling this
requirement can lead to hangs.
This unfortunately plays fairly poorly with the NOA requirements. NOA
requires a stable power c
Chris Wilson writes:
> We only use sentinel requests for "preempt-to-idle" passes, so assert
> that they are the only request in a new submission.
>
> Signed-off-by: Chris Wilson
>From other thread,
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gt/intel_lrc.c | 21
On 2020-02-20 at 18:02:17 +0530, Anshuman Gupta wrote:
> As DP shim's config_stream_type returns size of message
> to be written in case of success therefore on
> config_stream_type success return a zero success
> value in order to succeed the HDCP auth.
>
> CC: Ramalingam C
> Signed-off-by: Ansh
On Sat, Feb 29, 2020 at 12:11:28AM +0100, Daniel Vetter wrote:
> On Fri, Feb 28, 2020 at 9:26 PM Sam Ravnborg wrote:
> > > @@ -312,7 +305,9 @@ void drm_minor_release(struct drm_minor *minor)
> > > * }
> > > * drmm_add_final_kfree(drm, priv);
> > > *
> > > - * dr
== Series Details ==
Series: series starting with [01/22] drm/i915/gem: Consolidate ctx->engines[]
release
URL : https://patchwork.freedesktop.org/series/74131/
State : warning
== Summary ==
$ make htmldocs 2>&1 > /dev/null | grep i915
Error: Cannot open file ./drivers/gpu/drm/i915/intel_csr.
On 28/02/2020 12:19, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-02-28 12:08:18)
On 27/02/2020 11:01, Chris Wilson wrote:
+static void engines_idle_release(struct i915_gem_context *ctx,
+ struct i915_gem_engines *engines)
+{
+ struct i915_gem_engines_ite
== Series Details ==
Series: series starting with [v2,1/2] drm/i915/perf: remove generated code
URL : https://patchwork.freedesktop.org/series/74136/
State : failure
== Summary ==
Applying: drm/i915/perf: remove generated code
Applying: drm/i915/perf: introduce global sseu pinning
error: sha1
== Series Details ==
Series: series starting with [01/22] drm/i915/gem: Consolidate ctx->engines[]
release
URL : https://patchwork.freedesktop.org/series/74131/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8043 -> Patchwork_16777
=
== Series Details ==
Series: drm: drm_fb_helper cleanup.
URL : https://patchwork.freedesktop.org/series/74140/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
b1b805dc68b7 drm: Remove unused arg from drm_fb_helper_init
175d46a47660 drm/radeon: remove radeon_fb_{add, remove}_conne
@Deak, Imre Re-reported the results. All good now.
Lakshmi.
-Original Message-
From: Imre Deak
Sent: Monday, March 2, 2020 3:31 PM
To: intel-gfx@lists.freedesktop.org
Cc: Vudum, Lakshminarayana
Subject: Re: ✗ Fi.CI.IGT: failure for drm/i915: Clean up DPLL output/refclock
tracking (rev
From: Ville Syrjälä
Despite what the spec says the TIMESTAMP register seems to tick
once every hrawclk (confirmed on i965gm and g35).
Cc: Lionel Landwerlin
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_device_info.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff
From: Ville Syrjälä
On ilk the UDW of TIMESTAMP increments every 1000 ns,
LDW is mbz. In order to represent cs_timestamp_frequency_hz
for that we'd need 52 bits, but we only have 32 bits.
Even worse most things want to only deak with the low
32 bits of timestamp. So let's just set up cs_timestamp
From: Ville Syrjälä
kHz isn't accurate enough for storing the CS timestamp
frequency on some of the platforms. Store the value
in Hz instead.
Cc: Lionel Landwerlin
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_debugfs.c| 6 ++--
drivers/gpu/drm/i915/i915_getparam.c
From: Ville Syrjälä
Bunch of places use a 64bit divisor needlessly. Switch
to 32bit divisor.
Cc: Lionel Landwerlin
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_perf.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c
From: Ville Syrjälä
Pull the code to do the CS timestamp ns<->ticks conversion into
helpers and use them all over.
The check in i915_perf_noa_delay_set() seems a bit dubious,
so we switch it to do what I assume it wanted to do all along
(ie. make sure the resulting delay in CS timestamp ticks
do
From: Ville Syrjälä
On pre-ivb the CS timestamp register is only present on RCS (despite
what snb bspec claims). Let's test it.
Also on ctg/elk/ilk the usable part of the timestamp is the UDW so
let's read that instead of the LDW. On ctg/elk the 10 msbs of the LDW
do actually work, but we config
== Series Details ==
Series: drm: drm_fb_helper cleanup.
URL : https://patchwork.freedesktop.org/series/74140/
State : warning
== Summary ==
$ make htmldocs 2>&1 > /dev/null | grep i915
Error: Cannot open file ./drivers/gpu/drm/i915/intel_csr.c
Error: Cannot open file ./drivers/gpu/drm/i915/in
On Tue, Feb 25, 2020 at 05:30:57PM +, Lisovskiy, Stanislav wrote:
> On Tue, 2020-02-25 at 19:11 +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Currently skl_compute_dbuf_slices() returns 0 for any inactive pipe
> > on
> > icl+, but returns BIT(S1) on pre-icl for any pipe (whether
Update locations for
./drivers/gpu/drm/i915/i915_vma.h:1: warning: 'Virtual Memory Address' not found
./drivers/gpu/drm/i915/i915_gem_gtt.c:1: warning: 'Global GTT views' not found
Signed-off-by: Chris Wilson
---
Documentation/gpu/i915.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(
== Series Details ==
Series: series starting with [1/6] drm/i915: Nuke pointless div by 64bit
URL : https://patchwork.freedesktop.org/series/74145/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
6cf1345486f2 drm/i915: Nuke pointless div by 64bit
03152bdf42be drm/i915: Store CS t
== Series Details ==
Series: drm: drm_fb_helper cleanup.
URL : https://patchwork.freedesktop.org/series/74140/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8043 -> Patchwork_16779
Summary
---
**SUCCESS**
No regre
== Series Details ==
Series: series starting with [1/6] drm/i915: Nuke pointless div by 64bit
URL : https://patchwork.freedesktop.org/series/74145/
State : warning
== Summary ==
$ make htmldocs 2>&1 > /dev/null | grep i915
Error: Cannot open file ./drivers/gpu/drm/i915/intel_csr.c
Error: Canno
== Series Details ==
Series: series starting with [1/6] drm/i915: Nuke pointless div by 64bit
URL : https://patchwork.freedesktop.org/series/74145/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8043 -> Patchwork_16780
Summa
== Series Details ==
Series: drm/i915: Fix doclinks
URL : https://patchwork.freedesktop.org/series/74146/
State : warning
== Summary ==
$ make htmldocs 2>&1 > /dev/null | grep i915
Error: Cannot open file ./drivers/gpu/drm/i915/intel_csr.c
Error: Cannot open file ./drivers/gpu/drm/i915/intel_c
On Mon, 2020-03-02 at 16:50 +0200, Ville Syrjälä wrote:
> On Tue, Feb 25, 2020 at 05:30:57PM +, Lisovskiy, Stanislav wrote:
> > On Tue, 2020-02-25 at 19:11 +0200, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > Currently skl_compute_dbuf_slices() returns 0 for any inactive
> > > pi
On Tue, Feb 11, 2020 at 06:14:50PM +0200, Jani Nikula wrote:
> The DMC firmware is about display. Move the handling under display. No
> functional changes.
>
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/Makefile | 2 +-
> drivers/gpu/drm/i915/{
On Mon, 2 Mar 2020 at 13:08, Pankaj Bharadiya
wrote:
>
> This series addresses below drm_fb_helper tasks from
> Documentation/gpu/todo.rst.
>
> - The max connector argument for drm_fb_helper_init() isn't used
> anymore and can be removed.
>
> - The helper doesn't keep an array of connectors anym
== Series Details ==
Series: drm/i915: Fix doclinks
URL : https://patchwork.freedesktop.org/series/74146/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8043 -> Patchwork_16781
Summary
---
**SUCCESS**
No regression
Chris Wilson writes:
> Inside dma-fence-chain, we use a cmpxchg on an RCU-protected pointer. To
> avoid the sparse warning for using the RCU pointer directly, we have to
> cast away the __rcu annotation. However, we don't need to use void*
> everywhere and can stick to the dma_fence*.
Prolly jus
On Mon, 2 Mar 2020 at 15:58, Emil Velikov wrote:
>
> On Mon, 2 Mar 2020 at 13:08, Pankaj Bharadiya
> wrote:
> >
> > This series addresses below drm_fb_helper tasks from
> > Documentation/gpu/todo.rst.
> >
> > - The max connector argument for drm_fb_helper_init() isn't used
> > anymore and can b
Chris Wilson writes:
> For conveniences of callers that just want to use an i915_active to
> track a wide array of concurrent timelines, wrap the base i915_active
> struct inside a kref. This i915_active will self-destruct after use.
>
I looks ok and I would buy this. However I didn't manage to
Quoting Mika Kuoppala (2020-03-02 16:18:48)
> Chris Wilson writes:
>
> > For conveniences of callers that just want to use an i915_active to
> > track a wide array of concurrent timelines, wrap the base i915_active
> > struct inside a kref. This i915_active will self-destruct after use.
> >
>
>
This series addresses below drm_fb_helper tasks from
Documentation/gpu/todo.rst.
- The max connector argument for drm_fb_helper_init() isn't used
anymore and can be removed.
- The helper doesn't keep an array of connectors anymore so these can
be removed: drm_fb_helper_single_add_all_connecto
drm_fb_helper_{add,remove}_one_connector() are dummy functions now
and serve no purpose. Hence remove their calls.
This is the preparatory step for removing the
drm_fb_helper_{add,remove}_one_connector() functions from
drm_fb_helper.h
Signed-off-by: Pankaj Bharadiya
---
drivers/gpu/drm/radeon/r
drm_fb_helper_{add,remove}_one_connector() are dummy functions now
and serve no purpose. Hence remove their calls.
This is the preparatory step for removing the
drm_fb_helper_{add,remove}_one_connector() functions from
drm_fb_helper.h
Signed-off-by: Pankaj Bharadiya
---
drivers/gpu/drm/i915/dis
The max connector argument for drm_fb_helper_init() isn't used anymore
hence remove it.
All the drm_fb_helper_init() calls are modified with below sementic
patch.
@@
expression E1, E2, E3;
@@
- drm_fb_helper_init(E1,E2, E3)
+ drm_fb_helper_init(E1,E2)
Signed-off-by: Pankaj Bharadiya
---
driv
drm_fb_helper_{add,remove}_one_connector() are dummy functions now
and serve no purpose. Hence remove their calls.
This is the preparatory step for removing the
drm_fb_helper_{add,remove}_one_connector() functions from
drm_fb_helper.h
Signed-off-by: Pankaj Bharadiya
---
.../drm/amd/display/amdg
1 - 100 of 243 matches
Mail list logo
