On 2020.11.23 11:32:38 +0200, Joonas Lahtinen wrote:
> Quoting Zhenyu Wang (2020-11-23 11:05:17)
> >
> > Hi,
> >
> > Here's gvt next pull for v5.11. Mostly it's for host suspend/resume
> > fix with vGPU active and with some other enhancement as details below.
> > Note that this includes some
On 11/17/20 11:17 AM, Jani Nikula wrote:
> On Tue, 17 Nov 2020, Aditya Swarup wrote:
>> From: Caz Yokoyama
>>
>> - Add the initial platform information for Alderlake-S.
>> - Specify ppgtt_size value
>> - Add dma_mask_size
>> - Add ADLS REVIDs
>> - HW tracking(Selective Update Tracking Enable)
On 11/18/20 1:18 AM, Jani Nikula wrote:
> On Tue, 17 Nov 2020, Lucas De Marchi wrote:
>> On Tue, Nov 17, 2020 at 10:50:10AM -0800, Aditya Swarup wrote:
>>> @@ -1579,9 +1579,9 @@ static inline const struct i915_rev_steppings *
>>> tgl_revids_get(struct drm_i915_private *dev_priv)
>>> {
>>> if
On Tue, 2020-11-24 at 11:58 +1100, Finn Thain wrote:
> it's not for me to prove that such patches don't affect code
> generation. That's for the patch author and (unfortunately) for reviewers.
Ideally, that proof would be provided by the compilation system itself
and not patch authors nor
== Series Details ==
Series: series starting with [1/2] drm/framebuffer: Format modifier for Intel
Gen 12 render compression with Clear Color
URL : https://patchwork.freedesktop.org/series/84183/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9378 -> Patchwork_18961
== Series Details ==
Series: series starting with [1/2] drm/framebuffer: Format modifier for Intel
Gen 12 render compression with Clear Color
URL : https://patchwork.freedesktop.org/series/84183/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast
== Series Details ==
Series: series starting with [1/2] drm/framebuffer: Format modifier for Intel
Gen 12 render compression with Clear Color
URL : https://patchwork.freedesktop.org/series/84183/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
a3b4d1336125 drm/framebuffer:
On Fri, 20 Nov 2020 12:21:39 -0600, Gustavo A. R. Silva wrote:
> This series aims to fix almost all remaining fall-through warnings in
> order to enable -Wimplicit-fallthrough for Clang.
>
> In preparation to enable -Wimplicit-fallthrough for Clang, explicitly
> add multiple
On Mon, 2020-11-23 at 19:56 +0100, Miguel Ojeda wrote:
> On Mon, Nov 23, 2020 at 4:58 PM James Bottomley
> wrote:
> > Well, I used git. It says that as of today in Linus' tree we have
> > 889 patches related to fall throughs and the first series went in
> > in october 2017 ... ignoring a couple
== Series Details ==
Series: relay: cleanup and const callbacks, take 2
URL : https://patchwork.freedesktop.org/series/84182/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9378 -> Patchwork_18960
Summary
---
== Series Details ==
Series: drm/i915/display: Record the plane update times for debugging (rev2)
URL : https://patchwork.freedesktop.org/series/84174/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9376_full -> Patchwork_18959_full
Use the spinners to provide exactly the right amount of background
busyness.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
lib/igt_dummyload.c | 13 +--
lib/igt_dummyload.h | 1 +
tests/i915/gem_request_retire.c | 169
3 files
== Series Details ==
Series: relay: cleanup and const callbacks, take 2
URL : https://patchwork.freedesktop.org/series/84182/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
Jani Nikula writes:
> This is v2 of [1], with a number of cleanups added first based on
> Christoph's feedback, making the actual constness patch much smaller and
> cleaner.
>
> I don't know who actually maintains relay, it's not in MAINTAINERS -
> Cc'd Andrew just in case.
>
> I'd think it
On Mon, Nov 23, 2020 at 4:58 PM James Bottomley
wrote:
>
> Well, I used git. It says that as of today in Linus' tree we have 889
> patches related to fall throughs and the first series went in in
> october 2017 ... ignoring a couple of outliers back to February.
I can see ~10k insertions over
From: Radhakrishna Sripada
Render Decompression is supported with Y-Tiled main surface. The CCS is
linear and has 4 bits of data for each main surface cache line pair, a
ratio of 1:256. Additional Clear Color information is passed from the
user-space through an offset in the GEM BO. Add a new
From: Radhakrishna Sripada
Gen12 display can decompress surfaces compressed by render engine with
Clear Color, add a new modifier as the driver needs to know the surface
was compressed by render engine.
V2: Description changes as suggested by Rafael.
V3: Mention the Clear Color size of 64 bits
On Thu, 19 Nov 2020, Christoph Hellwig wrote:
> But taking one step back: All instances implement create_buf_file
> and remove_buf_file, which makes sense as that is the prime aim
> of these methods. So there is no point in making those optional.
> subbuf_start_callback is overriden by two
Now that relay_open() accepts const callbacks, make relay callbacks
const.
Cc: Kalle Valo
Cc: ath...@lists.infradead.org
Acked-by: Kalle Valo
Signed-off-by: Jani Nikula
---
drivers/net/wireless/ath/ath10k/spectral.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Now that relay_open() accepts const callbacks, make relay callbacks
const.
Cc: Jens Axboe
Cc: linux-bl...@vger.kernel.org
Signed-off-by: Jani Nikula
---
kernel/trace/blktrace.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/trace/blktrace.c b/kernel/trace/blktrace.c
Now that relay_open() accepts const callbacks, make relay callbacks
const.
Cc: Kalle Valo
Cc: QCA ath9k Development
Cc: linux-wirel...@vger.kernel.org
Acked-by: Kalle Valo
Signed-off-by: Jani Nikula
---
drivers/net/wireless/ath/ath9k/common-spectral.c | 2 +-
1 file changed, 1 insertion(+),
Now that relay_open() accepts const callbacks, make relay callbacks
const.
Cc: Kalle Valo
Cc: ath...@lists.infradead.org
Signed-off-by: Jani Nikula
---
drivers/net/wireless/ath/ath11k/spectral.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Now that relay_open() accepts const callbacks, make relay callbacks
const.
Cc: intel-gfx@lists.freedesktop.org
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/gt/uc/intel_guc_log.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_log.c
None of the relay users require the use of mutable structs for
callbacks, however the relay code does. Instead of assigning the default
callback for subbuf_start, add a wrapper to conditionally call the
client callback if available, and fall back to default behaviour
otherwise.
This lets all
All clients provide create_buf_file and remove_buf_file callbacks, and
they're required for relay to make sense. There is no point in them
being optional.
Also document whether each callback is mandatory/optional.
Suggested-by: Christoph Hellwig
Cc: Christoph Hellwig
Signed-off-by: Jani Nikula
There are no clients passing NULL callbacks, which makes sense as it
wouldn't even create a file. Require non-NULL callbacks, and throw away
the handling for NULL callbacks.
Suggested-by: Christoph Hellwig
Cc: Christoph Hellwig
Signed-off-by: Jani Nikula
---
kernel/relay.c | 14 ++
No relay client uses the buf_mapped or buf_unmapped callbacks. Remove
them. This makes relay's vm_operations_struct close callback a dummy,
remove it as well.
Suggested-by: Christoph Hellwig
Cc: Christoph Hellwig
Signed-off-by: Jani Nikula
---
include/linux/relay.h | 19 ---
This is v2 of [1], with a number of cleanups added first based on
Christoph's feedback, making the actual constness patch much smaller and
cleaner.
I don't know who actually maintains relay, it's not in MAINTAINERS -
Cc'd Andrew just in case.
I'd think it would be simplest to queue patches 5-9
== Series Details ==
Series: drm/i915/display: Record the plane update times for debugging (rev2)
URL : https://patchwork.freedesktop.org/series/84174/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9376 -> Patchwork_18959
On 11/22/20 10:22 AM, Joe Perches wrote:
> On Sun, 2020-11-22 at 08:33 -0800, Tom Rix wrote:
>> On 11/21/20 9:10 AM, Joe Perches wrote:
>>> On Sat, 2020-11-21 at 08:50 -0800, t...@redhat.com wrote:
A difficult part of automating commits is composing the subsystem
preamble in the commit
== Series Details ==
Series: drm/i915/display: Record the plane update times for debugging (rev2)
URL : https://patchwork.freedesktop.org/series/84174/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
38fb4e810247 drm/i915/display: Record the plane update times for debugging
On Mon, 2020-11-23 at 07:58 -0800, James Bottomley wrote:
> We're also complaining about the inability to recruit maintainers:
>
> https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
>
> And burn out:
>
> http://antirez.com/news/129
On Mon, 2020-11-23 at 07:03 -0600, Gustavo A. R. Silva wrote:
> On Sun, Nov 22, 2020 at 11:53:55AM -0800, James Bottomley wrote:
> > On Sun, 2020-11-22 at 11:22 -0800, Joe Perches wrote:
> > > On Sun, 2020-11-22 at 11:12 -0800, James Bottomley wrote:
> > > > On Sun, 2020-11-22 at 10:25 -0800, Joe
Since we try and estimate how long we require to update the registers to
perform a plane update, it is of vital importance that we measure the
distribution of plane updates to better guide our estimate. If we
underestimate how long it takes to perform the plane update, we may
slip into the next
== Series Details ==
Series: drm/i915/display: Record the plane update times for debugging
URL : https://patchwork.freedesktop.org/series/84174/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9376 -> Patchwork_18958
Summary
On Mon, Nov 23, 2020 at 4:58 PM James Bottomley
wrote:
>
> On Mon, 2020-11-23 at 15:19 +0100, Miguel Ojeda wrote:
> > On Sun, Nov 22, 2020 at 11:36 PM James Bottomley
> > wrote:
[cut]
> >
> > Maintainers routinely review 1-line trivial patches, not to mention
> > internal API changes, etc.
>
>
On Fri, 20 Nov 2020, "Huang, Sean Z" wrote:
> PXP is an i915 componment, that helps user space to establish the
> hardware protected session and manage the status of each alive
> software session, as well as the life cycle of each session.
I seem to have replied to an old version of the series;
On Sat, 21 Nov 2020, Paul Gardiner wrote:
> On 17/11/2020 14:52, Jani Nikula wrote:
>> On Thu, 29 Oct 2020, Paul Gardiner wrote:
>>> I use an open source DVR called MythTV. I've just swapped from using
>>> nvidia graphics to intel graphics. Generally it's working great, but
>>> I've run into one
On Mon, Nov 23, 2020 at 4:52 PM Jani Nikula wrote:
>
> On Sat, 21 Nov 2020, James Bottomley
> wrote:
> > On Sat, 2020-11-21 at 08:50 -0800, t...@redhat.com wrote:
> >> A difficult part of automating commits is composing the subsystem
> >> preamble in the commit log. For the ongoing effort of a
On Mon, 2020-11-23 at 15:19 +0100, Miguel Ojeda wrote:
> On Sun, Nov 22, 2020 at 11:36 PM James Bottomley
> wrote:
> > Well, it seems to be three years of someone's time plus the
> > maintainer review time and series disruption of nearly a thousand
> > patches. Let's be conservative and assume
== Series Details ==
Series: drm/i915/display: Record the plane update times for debugging
URL : https://patchwork.freedesktop.org/series/84174/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
b17790555707 drm/i915/display: Record the plane update times for debugging
-:65:
On Sat, 21 Nov 2020, James Bottomley
wrote:
> On Sat, 2020-11-21 at 08:50 -0800, t...@redhat.com wrote:
>> A difficult part of automating commits is composing the subsystem
>> preamble in the commit log. For the ongoing effort of a fixer
>> producing
>> one or two fixes a release the use of
== Series Details ==
Series: series starting with [CI,1/4] drm/i915/gt: Defer enabling the
breadcrumb interrupt to after submission
URL : https://patchwork.freedesktop.org/series/84165/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9376_full -> Patchwork_18957_full
On Sat, 14 Nov 2020, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [PXP,CLEAN,v06,01/27] drm/i915/pxp: Introduce
> Intel PXP component
> URL : https://patchwork.freedesktop.org/series/83843/
> State : failure
>
> == Summary ==
>
> CALLscripts/checksyscalls.sh
>
On Fri, 13 Nov 2020, Sean Z Huang wrote:
> From: "Huang, Sean Z"
>
> During the power event S3+ sleep/resume, hardware will lose all the
> encryption keys for every hardware session, even though the
> software session state was marked as alive after resume. So to
> handle such case, ring0 PXP
On Fri, 13 Nov 2020, Sean Z Huang wrote:
> From: "Huang, Sean Z"
>
> Add several PXP-related reg into allowlist to allow
> ring3 driver to read the those register values.
>
> Signed-off-by: Huang, Sean Z
> ---
> drivers/gpu/drm/i915/i915_reg.h | 8
>
On Fri, 13 Nov 2020, Sean Z Huang wrote:
> From: "Huang, Sean Z"
>
> Rename the whitelist to allowlist as suggested
Please post this separately and we can merge this while the rest of the
series is still being reviewed.
BR,
Jani.
>
> Signed-off-by: Huang, Sean Z
> ---
>
On Mon, 16 Nov 2020, "Souza, Jose" wrote:
> On Fri, 2020-11-13 at 16:36 -0800, Sean Z Huang wrote:
>> From: "Huang, Sean Z"
>>
>> Create the irq worker that serves as callback handler, those
>> callback stubs should be called while the hardware key teardown
>> occurs.
>>
>> Signed-off-by:
Since we try and estimate how long we require to update the registers to
perform a plane update, it is of vital importance that we measure the
distribution of plane updates to better guide our estimate. If we
underestimate how long it takes to perform the plane update, we may
slip into the next
On Sun, Nov 22, 2020 at 11:54 PM Finn Thain wrote:
>
> We should also take into account optimisim about future improvements in
> tooling.
Not sure what you mean here. There is no reliable way to guess what
the intention was with a missing fallthrough, even if you parsed
whitespace and
On Sun, Nov 22, 2020 at 11:36 PM James Bottomley
wrote:
>
> Well, it seems to be three years of someone's time plus the maintainer
> review time and series disruption of nearly a thousand patches. Let's
> be conservative and assume the producer worked about 30% on the series
> and it takes about
On Sun, Nov 22, 2020 at 11:53:55AM -0800, James Bottomley wrote:
> On Sun, 2020-11-22 at 11:22 -0800, Joe Perches wrote:
> > On Sun, 2020-11-22 at 11:12 -0800, James Bottomley wrote:
> > > On Sun, 2020-11-22 at 10:25 -0800, Joe Perches wrote:
> > > > On Sun, 2020-11-22 at 10:21 -0800, James
== Series Details ==
Series: series starting with [CI,1/4] drm/i915/gt: Defer enabling the
breadcrumb interrupt to after submission
URL : https://patchwork.freedesktop.org/series/84165/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9376 -> Patchwork_18957
== Series Details ==
Series: series starting with [CI,1/4] drm/i915/gt: Defer enabling the
breadcrumb interrupt to after submission
URL : https://patchwork.freedesktop.org/series/84165/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used,
We currently want to keep the interrupt enabled until the interrupt after
which we have no more work to do. This heuristic was broken by us
kicking the irq-work on adding a completed request without attaching a
signaler -- hence it appearing to the irq-worker that an interrupt had
fired when we
Make b->signaled_requests a lockless-list so that we can manipulate it
outside of the b->irq_lock.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 34 ---
.../gpu/drm/i915/gt/intel_breadcrumbs_types.h | 2 +-
Move the register slow register write and readback from out of the
critical path for execlists submission and delay it until the following
worker, shaving off around 200us. Note that the same signal_irq_work() is
allowed to run concurrently on each CPU (but it will only be queued once,
once
Since preempt-to-busy, we may unsubmit a request while it is still on
the HW and completes asynchronously. That means it may be retired and in
the process destroy the virtual engine (as the user has closed their
context), but that engine may still be holding onto the unsubmitted
compelted request.
Quoting Zhenyu Wang (2020-11-23 11:05:17)
>
> Hi,
>
> Here's gvt next pull for v5.11. Mostly it's for host suspend/resume
> fix with vGPU active and with some other enhancement as details below.
> Note that this includes some minor i915 driver change to add gvt hook
> in suspend/resume function
Hi,
Here's gvt next pull for v5.11. Mostly it's for host suspend/resume
fix with vGPU active and with some other enhancement as details below.
Note that this includes some minor i915 driver change to add gvt hook
in suspend/resume function which has been sent and reviewed on
intel-gfx list.
I
60 matches
Mail list logo
