Quoting Ankit Navik (2019-11-25 06:39:02)
> This patch sets improves GPU power consumption on Linux kernel based OS such
> as
> Chromium OS, Ubuntu, etc. Following are the power savings.
The code is still as broken as it was when it was last posted.
-Chris
On Fri, Nov 22, 2019 at 08:35:13PM +0200, Ville Syrjälä wrote:
> On Tue, Nov 19, 2019 at 11:14:43AM +0100, Daniel Vetter wrote:
> > On Fri, Nov 15, 2019 at 09:42:00PM +0200, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > Yank out the code for the plane->fb/old_fb/crtc handling from
>
On converting from kunmap_atomic() to kunamp() one must remember the
latter takes the struct page, the former the vaddr.
Fixes: 48715f700174 ("drm/i915: Avoid atomic context for error capture")
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gpu_error.c | 2 +-
1 file changed, 1 insert
Chris Wilson writes:
> Since we want to do a lockless read of the current active request, and
> that request is written to by process_csb also without serialisation, we
> need to instruct gcc to take care in reading the pointer itself.
>
> Otherwise, we have observed execlists_active() to report
Chris Wilson writes:
> On converting from kunmap_atomic() to kunamp() one must remember the
> latter takes the struct page, the former the vaddr.
>
> Fixes: 48715f700174 ("drm/i915: Avoid atomic context for error capture")
> Signed-off-by: Chris Wilson
Would it have been otherway around, we wou
Quoting Mika Kuoppala (2019-11-25 09:16:30)
> Chris Wilson writes:
>
> > Since we want to do a lockless read of the current active request, and
> > that request is written to by process_csb also without serialisation, we
> > need to instruct gcc to take care in reading the pointer itself.
> >
> >
Chris Wilson writes:
> Quoting Mika Kuoppala (2019-11-25 09:16:30)
>> Chris Wilson writes:
>>
>> > Since we want to do a lockless read of the current active request, and
>> > that request is written to by process_csb also without serialisation, we
>> > need to instruct gcc to take care in readi
Since we want to do a lockless read of the current active request, and
that request is written to by process_csb also without serialisation, we
need to instruct gcc to take care in reading the pointer itself.
Otherwise, we have observed execlists_active() to report 0x40.
[ 2400.760381] igt/para-4
I'll add more fancy logic to them soon, so everyone really has to use
them. Plus they already provide some nice additional debug
infrastructure on top of direct ww_mutex usage for the fences tracked
by dma_resv.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/vc4/vc4_gem.c | 11 +--
1 f
I'll add more fancy logic to them soon, so everyone really has to use
them. Plus they already provide some nice additional debug
infrastructure on top of direct ww_mutex usage for the fences tracked
by dma_resv.
Signed-off-by: Daniel Vetter
Cc: Rob Clark
Cc: Sean Paul
Cc: linux-arm-...@vger.ker
Hi all,
This is prep work for some dma_resv series I'm tinkering with, but I
figured good to split this out since good idea to land this no matter what
exactly I'll end up creating in dma_resv. With these everything in
drivers/gpu nicely goes through either the dma_resv or drm_modeset_lock
wrapper
I'll add more fancy logic to them soon, so everyone really has to use
them. Plus they already provide some nice additional debug
infrastructure on top of direct ww_mutex usage for the fences tracked
by dma_resv.
Signed-off-by: Daniel Vetter
Cc: Lucas Stach
Cc: Russell King
Cc: Christian Gmeiner
I'll add more fancy logic to them soon, so everyone really has to use
them. Plus they already provide some nice additional debug
infrastructure on top of direct ww_mutex usage for the fences tracked
by dma_resv.
Aside: We might want to create wrappers for i915_vma locking of the
->resv like we hav
On Mon, Nov 18, 2019 at 11:35:22AM +0100, Daniel Vetter wrote:
> A few reasons to drop kmap:
>
> - For native objects all we do is look at obj->vaddr anyway, so might
> as well not call functions for every page.
>
> - Reloc-processing on dma-buf is ... questionable.
>
> - Plus most dma-buf tha
Quoting Niranjana Vishwanathapura (2019-11-22 20:57:24)
> Shared Virtual Memory (SVM) runtime allocator support allows
> binding a shared virtual address to a buffer object (BO) in the
> device page table through an ioctl call.
The ioctl though is not svm specific, it is to do with "bulk residency
Quoting Chris Wilson (2019-11-15 16:05:45)
> No good reason why we must always use a static ringsize, so let
> userspace select one during construction.
Do we have any news on whether userspace has materialised for this yet?
It's literally just
--- a/runtime/os_interface/linux/drm_neo.cpp
+++ b/
> -Original Message-
> From: Chris Wilson
> Sent: Monday, November 25, 2019 1:46 PM
> To: Navik, Ankit P ; intel-
> g...@lists.freedesktop.org
> Cc: Navik, Ankit P ; Anand, Vipin
>
> Subject: Re: [Intel-gfx] [PATCH v5 0/3] drm/i915: Context aware user agnostic
> EU/Slice/Sub-slice contr
We are moving our issue tracking over from bugs.fd.o to gitlab.fd.o, so
update the user instructions accordingly.
Signed-off-by: Chris Wilson
Cc: Martin Peres
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: Jani Nikula
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/i915/i915_gpu_error.c | 2 +-
dri
On 24/11/2019 17:05, Chris Wilson wrote:
As the engine->kernel_context is used within the engine-pm barrier, we
have to be careful when emitting requests outside of the barrier, as the
strict timeline locking rules do not apply. Instead, we must ensure the
engine_park() cannot be entered as we b
On Mon, Nov 25, 2019 at 10:58:56AM +0100, Daniel Vetter wrote:
> On Mon, Nov 18, 2019 at 11:35:22AM +0100, Daniel Vetter wrote:
> > A few reasons to drop kmap:
> >
> > - For native objects all we do is look at obj->vaddr anyway, so might
> > as well not call functions for every page.
> >
> > -
Hi Chris,
On Sat, Nov 23, 2019 at 05:49:46PM +, Chris Wilson wrote:
> Since we want to do a lockless read of the current active request, and
> that request is written to by process_csb also without serialisation, we
> need to instruct gcc to take care in reading the pointer itself.
>
> Otherw
On Thu, 21 Nov 2019, Michal Wajdeczko wrote:
> Today VGT implements GGTT ballooning on its own, using some private
> static structure to hold info about reserved GGTT nodes and then
> manually update vm.reserved size owned by i915_ggtt.
>
> As i915_ggtt already manages some custom reserved nodes (
Quoting Tvrtko Ursulin (2019-11-25 10:44:15)
>
> On 24/11/2019 17:05, Chris Wilson wrote:
> > +static inline struct i915_request *
> > +intel_engine_create_kernel_request(struct intel_engine_cs *engine)
> > +{
> > + struct i915_request *rq;
> > +
> > + /*
> > + * The engine->kernel_co
As the engine->kernel_context is used within the engine-pm barrier, we
have to be careful when emitting requests outside of the barrier, as the
strict timeline locking rules do not apply. Instead, we must ensure the
engine_park() cannot be entered as we build the request, which is
simplest by takin
In the next patch, we will introduce a new asynchronous retirement
worker, fed by execlists CS events. Here we may queue a retirement as
soon as a request is submitted to HW (and completes instantly), and we
also want to process that retirement as early as possible and cannot
afford to postpone (as
The major drawback of commit 7e34f4e4aad3 ("drm/i915/gen8+: Add RC6 CTX
corruption WA") is that it disables RC6 while Skylake (and friends) is
active, and we do not consider the GPU idle until all outstanding
requests have been retired and the engine switched over to the kernel
context. If userspac
On Mon, Nov 18, 2019 at 11:35:22AM +0100, Daniel Vetter wrote:
> A few reasons to drop kmap:
>
> - For native objects all we do is look at obj->vaddr anyway, so might
> as well not call functions for every page.
>
> - Reloc-processing on dma-buf is ... questionable.
>
> - Plus most dma-buf tha
On Mon, Nov 18, 2019 at 11:35:23AM +0100, Daniel Vetter wrote:
> It doesn't have any callers anymore.
>
> Aside: The ->mmap/munmap hooks have a bit a confusing name, they don't
> do userspace mmaps, but a kernel vmap. I think most places use vmap
> for this, except ttm, which uses kmap for vmap fo
On Mon, Nov 18, 2019 at 11:35:29AM +0100, Daniel Vetter wrote:
> No in-tree users left.
>
> Signed-off-by: Daniel Vetter
> Cc: Thierry Reding
> Cc: Jonathan Hunter
> Cc: linux-te...@vger.kernel.org
> ---
> drivers/gpu/drm/tegra/gem.c | 12
> 1 file changed, 12 deletions(-)
Same a
I rushed a last minute correction to cancel_port_requests() to prevent
the snooping of *execlists->active as the inflight array was being
updated, without noticing we iterated the inflight array starting from
active! Oops.
Fixes: 331bf9059157 ("drm/i915/gt: Mark the execlists->active as the primar
Quoting Jani Nikula (2019-11-25 10:51:53)
> On Thu, 21 Nov 2019, Michal Wajdeczko wrote:
> > Today VGT implements GGTT ballooning on its own, using some private
> > static structure to hold info about reserved GGTT nodes and then
> > manually update vm.reserved size owned by i915_ggtt.
> >
> > As
Quoting Navik, Ankit P (2019-11-25 10:32:23)
>
>
> > -Original Message-
> > From: Chris Wilson
> > Sent: Monday, November 25, 2019 1:46 PM
> > To: Navik, Ankit P ; intel-
> > g...@lists.freedesktop.org
> > Cc: Navik, Ankit P ; Anand, Vipin
> >
> > Subject: Re: [Intel-gfx] [PATCH v5 0/3]
On 25/11/2019 10:58, Chris Wilson wrote:
As the engine->kernel_context is used within the engine-pm barrier, we
have to be careful when emitting requests outside of the barrier, as the
strict timeline locking rules do not apply. Instead, we must ensure the
engine_park() cannot be entered as we b
Quoting Tvrtko Ursulin (2019-11-25 11:39:17)
>
> On 25/11/2019 10:58, Chris Wilson wrote:
> > As the engine->kernel_context is used within the engine-pm barrier, we
> > have to be careful when emitting requests outside of the barrier, as the
> > strict timeline locking rules do not apply. Instead,
== Series Details ==
Series: drm/i915: Switch kunmap() to take the page not vaddr
URL : https://patchwork.freedesktop.org/series/69967/
State : failure
== Summary ==
Applying: drm/i915: Switch kunmap() to take the page not vaddr
Using index info to reconstruct a base tree...
M drivers/gp
== Series Details ==
Series: drm/i915/gt: Mark the execlists->active as the primary volatile access
(rev5)
URL : https://patchwork.freedesktop.org/series/69928/
State : failure
== Summary ==
Applying: drm/i915/gt: Mark the execlists->active as the primary volatile access
Using index info to r
== Series Details ==
Series: consistently use dma_resv locking wrappers
URL : https://patchwork.freedesktop.org/series/69970/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
7776c394b6e2 drm/etnaviv: Use dma_resv locking wrappers
-:49: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-o
High resolution timer is used for predictive governor to control
eu/slice/subslice based on workloads.
param is provided to enable/disable/update timer configuration
V2:
* Fix code style.
* Move predictive_load_timer into a drm_i915_private
structure.
* Make generic function to set optimum
drm/i915: Context aware user agnostic EU/Slice/Sub-slice control within kernel
This patch sets improves GPU power consumption on Linux kernel based OS such as
Chromium OS, Ubuntu, etc. Following are the power savings.
Power savings on GLK-GT1 Bobba platform running on Chrome OS.
-
This patch gives us the active pending request count which is yet
to be submitted to the GPU.
V2:
* Change 64-bit to atomic for request count. (Tvrtko Ursulin)
V3:
* Remove mutex for request count.
* Rebase.
* Fixes hitting underflow for predictive request. (Tvrtko Ursulin)
V4:
* Rebase.
V
This patch will select optimum eu/slice/sub-slice configuration based on
type of load (low, medium, high) as input.
Based on our readings and experiments we have predefined set of optimum
configuration for each platform(CHT, KBL).
i915_gem_context_set_load_type will select optimum configuration fro
== Series Details ==
Series: series starting with [1/3] drm/i915: Flush idle barriers when waiting
(rev2)
URL : https://patchwork.freedesktop.org/series/69546/
State : failure
== Summary ==
Applying: drm/i915: Flush idle barriers when waiting
Applying: drm/i915: Allow userspace to specify rin
== Series Details ==
Series: consistently use dma_resv locking wrappers
URL : https://patchwork.freedesktop.org/series/69970/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7416 -> Patchwork_15417
Summary
---
**WARNIN
An i915_vma struct on the stack may push the frame over the limit, if
set conservatively, so move it to the heap.
Signed-off-by: Chris Wilson
Cc: Matthew Auld
---
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 19 ---
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git
== Series Details ==
Series: drm/i915: Update bug URL to point at gitlab issues
URL : https://patchwork.freedesktop.org/series/69974/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7416 -> Patchwork_15419
Summary
---
Starting with gen12, PORT_A can be also connected to DP
transcoder. Update code in intel_dp_init() to take this
into account.
Signed-off-by: Kai Vehmanen
---
drivers/gpu/drm/i915/display/intel_dp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/i
Starting with gen12, PORT_A can be connected to a transcoder
with audio support. Modify the existing logic that disabled
audio on PORT_A unconditionally.
Signed-off-by: Kai Vehmanen
---
drivers/gpu/drm/i915/display/intel_dp.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
d
Hi,
On Fri, 22 Nov 2019, Ville Syrjälä wrote:
> > - if (IS_G4X(dev_priv) || port == PORT_A)
> > + if (IS_G4X(dev_priv) || (INTEL_GEN(dev_priv) < 12 && port == PORT_A))
>
> Getting a bit messy.
>
> Hoovering that into something like
> static bool intel_dp_port_has_audio(struct intel_encoder
== Series Details ==
Series: series starting with [CI,1/3] drm/i915: Serialise with engine-pm around
requests on the kernel_context
URL : https://patchwork.freedesktop.org/series/69975/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
a349dbb29dc7 drm/i915: Serialise with engine-
On 25/11/2019 11:25, Chris Wilson wrote:
I rushed a last minute correction to cancel_port_requests() to prevent
the snooping of *execlists->active as the inflight array was being
updated, without noticing we iterated the inflight array starting from
active! Oops.
Fixes: 331bf9059157 ("drm/i915/
Hi Chris,
> /* Mark the end of active before we overwrite *active */
> - WRITE_ONCE(execlists->active, execlists->pending);
> -
> - for (port = execlists->active; (rq = *port); port++)
> - execlists_schedule_out(rq);
> - execlists->active =
> - memset(exec
On Fri, 22 Nov 2019 01:13:25 +0100, Matthew Brost
wrote:
On Thu, Nov 21, 2019 at 12:43:26PM +0100, Michal Wajdeczko wrote:
On Thu, 21 Nov 2019 00:56:02 +0100, wrote:
From: Matthew Brost
Add non blocking CTB send fuction, intel_guc_send_nb. In order to
support a non blocking CTB send fuc
On Sun, Nov 24, 2019 at 01:12:47PM -0800, Niranjan Vishwanathapura wrote:
> > > > Using a temporary range is the pattern from nouveau, is it really
> > > > necessary in this driver?
> > >
> > > Yah, not required. In my local build I tried with proper default_flags
> > > and set pfn_flags_mask to
== Series Details ==
Series: series starting with [CI,1/3] drm/i915: Serialise with engine-pm around
requests on the kernel_context
URL : https://patchwork.freedesktop.org/series/69975/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7416 -> Patchwork_15420
On Fri, 22 Nov 2019 02:34:22 +0100, Matthew Brost
wrote:
On Thu, Nov 21, 2019 at 04:13:25PM -0800, Matthew Brost wrote:
On Thu, Nov 21, 2019 at 12:43:26PM +0100, Michal Wajdeczko wrote:
On Thu, 21 Nov 2019 00:56:02 +0100, wrote:
From: Matthew Brost
Add non blocking CTB send fuction, in
On Fri, 22 Nov 2019 02:29:59 +0100, Matthew Brost
wrote:
On Thu, Nov 21, 2019 at 07:56:07AM -0800, Matthew Brost wrote:
On Thu, Nov 21, 2019 at 12:58:50PM +0100, Michal Wajdeczko wrote:
On Thu, 21 Nov 2019 00:56:03 +0100, wrote:
From: Matthew Brost
CTB writes are now in the path of com
== Series Details ==
Series: drm/i915/execlists: Fixup cancel_port_requests()
URL : https://patchwork.freedesktop.org/series/69978/
State : failure
== Summary ==
Applying: drm/i915/execlists: Fixup cancel_port_requests()
Using index info to reconstruct a base tree...
M drivers/gpu/drm/i9
== Series Details ==
Series: drm/i915/selftests: Move mock_vma to the heap to reduce stack_frame
URL : https://patchwork.freedesktop.org/series/69981/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7417 -> Patchwork_15422
Su
On 25/11/2019 12:48, Chris Wilson wrote:
An i915_vma struct on the stack may push the frame over the limit, if
set conservatively, so move it to the heap.
Signed-off-by: Chris Wilson
Cc: Matthew Auld
Reviewed-by: Matthew Auld
___
Intel-gfx mailing
On Mon, Nov 25, 2019 at 10:02:38AM +0100, Daniel Vetter wrote:
> On Fri, Nov 22, 2019 at 08:35:13PM +0200, Ville Syrjälä wrote:
> > On Tue, Nov 19, 2019 at 11:14:43AM +0100, Daniel Vetter wrote:
> > > On Fri, Nov 15, 2019 at 09:42:00PM +0200, Ville Syrjala wrote:
> > > > From: Ville Syrjälä
> > >
On Sat, 23 Nov 2019, Uma Shankar wrote:
> This reverts commit f25c7a006cd1c07254780e3406e45cee4842b933.
>
> 2p2c display configuration blows up dmesg when one connector is
> disconnected, causing issues in CI.
>
> Below are the sample errors thrown in logs:
>
> [IGT] core_getversion: executing
> [
Since commit c45e788d95b4 ("drm/i915/tgl: Suspend pre-parser across GTT
invalidations"), we now disable the advanced preparser on Tigerlake for the
invalidation phase at the start of the batch, we no longer need to emit
the GPU relocations from a second context as they are now flushed inlined.
Ref
One does not lightly add a new hidden struct_mutex dependency deep within
the execbuf bowels! The immediate suspicion in seeing the whitelist
cached on the context, is that it is intended to be preserved between
batches, as the kernel is quite adept at caching small allocations
itself. But no, it's
On Fri, Nov 22, 2019 at 04:10:49PM +0200, Stanislav Lisovskiy wrote:
> According to BSpec 53998, there is a mask of
> max 8 SAGV/QGV points we need to support.
>
> Bumping this up to keep the CI happy(currently
> preventing tests to run), until all SAGV
> changes land.
>
> Fixes: https://bugs.fre
On Mon, 2019-11-25 at 17:31 +0200, Ville Syrjälä wrote:
> On Fri, Nov 22, 2019 at 04:10:49PM +0200, Stanislav Lisovskiy wrote:
> > According to BSpec 53998, there is a mask of
> > max 8 SAGV/QGV points we need to support.
> >
> > Bumping this up to keep the CI happy(currently
> > preventing tests
Hi,
> -Original Message-
> From: Lisovskiy, Stanislav
> Sent: maanantai 25. marraskuuta 2019 17.55
> To: ville.syrj...@linux.intel.com
> Cc: Saarinen, Jani ; intel-gfx@lists.freedesktop.org;
> Roper, Matthew D ; jani.nik...@linux.intel.com;
> Sarvela, Tomi P
> Subject: Re: [PATCH v2] drm
On Mon, 2019-11-25 at 16:03 +, Saarinen, Jani wrote:
> Hi,
>
> > -Original Message-
> > From: Lisovskiy, Stanislav
> > Sent: maanantai 25. marraskuuta 2019 17.55
> > To: ville.syrj...@linux.intel.com
> > Cc: Saarinen, Jani ;
> > intel-gfx@lists.freedesktop.org;
> > Roper, Matthew D ;
According to BSpec 53998, there is a mask of
max 8 SAGV/QGV points we need to support.
Bumping this up to keep the CI happy(currently
preventing tests to run), until all SAGV
changes land.
v2: Fix second plane where QGV points were
hardcoded as well.
v3: Change the naming of I915_NUM_SAGV_PO
== Series Details ==
Series: series starting with [v2,1/2] drm/i915/dp: fix DP audio for PORT_A on
gen12+
URL : https://patchwork.freedesktop.org/series/69982/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7418 -> Patchwork_15423
==
== Series Details ==
Series: Dynamic EU configuration of Slice/Sub-slice/EU (rev2)
URL : https://patchwork.freedesktop.org/series/69980/
State : failure
== Summary ==
CALLscripts/checksyscalls.sh
CALLscripts/atomic/check-atomics.sh
DESCEND objtool
CHK include/generated/compi
Based on a sampling of a number of benchmarks across platforms, by
default opt for a more much lenient timeout so that we should not
adversely affect existing clients.
640ms ought to be enough for anyone.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112169
Fixes: 3a7a92aba8fb ("drm/i915
On Fri, Nov 22, 2019 at 11:33:12PM +, Jason Gunthorpe wrote:
> On Fri, Nov 22, 2019 at 12:57:27PM -0800, Niranjana Vishwanathapura wrote:
[...]
> > +static int
> > +i915_range_fault(struct i915_svm *svm, struct hmm_range *range)
> > +{
> > + long ret;
> > +
> > + range->default_flags = 0;
On Mon, Nov 25, 2019 at 01:24:18PM +, Jason Gunthorpe wrote:
> On Sun, Nov 24, 2019 at 01:12:47PM -0800, Niranjan Vishwanathapura wrote:
>
> > > > > Using a temporary range is the pattern from nouveau, is it really
> > > > > necessary in this driver?
> > > >
> > > > Yah, not required. In my l
== Series Details ==
Series: series starting with [1/2] drm/i915/gem: Excise the per-batch whitelist
from the context
URL : https://patchwork.freedesktop.org/series/69988/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
b54dfcdb21c6 drm/i915/gem: Excise the per-batch whitelist f
On Mon, Nov 25, 2019 at 01:24:18PM +, Jason Gunthorpe wrote:
On Sun, Nov 24, 2019 at 01:12:47PM -0800, Niranjan Vishwanathapura wrote:
> > > Using a temporary range is the pattern from nouveau, is it really
> > > necessary in this driver?
> >
> > Yah, not required. In my local build I tried
On Mon, Nov 25, 2019 at 09:59:37AM +, Chris Wilson wrote:
Quoting Niranjana Vishwanathapura (2019-11-22 20:57:24)
Shared Virtual Memory (SVM) runtime allocator support allows
binding a shared virtual address to a buffer object (BO) in the
device page table through an ioctl call.
The ioctl
== Series Details ==
Series: series starting with [1/2] drm/i915/gem: Excise the per-batch whitelist
from the context
URL : https://patchwork.freedesktop.org/series/69988/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7418 -> Patchwork_15425
==
== Series Details ==
Series: drm/i915: Support more QGV points (rev4)
URL : https://patchwork.freedesktop.org/series/69886/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
d993a329d475 drm/i915: Support more QGV points
-:45: CHECK:BRACES: braces {} should be used on all arms of t
[Why]
HDMI 2.0 adds aspect ratio attribute to distinguish different
4k modes. According to Appendix E of HDMI 2.0 spec, source should
use VSIF to indicate video mode only when the mode is one defined
in HDMI 1.4b 4K modes. Otherwise, use AVI infoframes to convey VIC.
Current code doesn't take aspe
Hi Dave, Daniel,
Here are a few lates fixes for drm-misc-fixes. Obviously, it's not
going to make it into 5.4, but it'd be great if they were in the
upcoming PR.
Thanks!
Maxime
drm-misc-fixes-2019-11-25:
- A fix for a memory leak in the dma-buf support
- One in mcde DSI support that leads to a
[Why]
In hdmi_mode_alternate_clock(), it adds an exception for VIC 4
mode (4096x2160@24) due to there is no alternate clock defined for
that mode in HDMI1.4b. But HDMI2.0 adds 23.98Hz for that mode.
[How]
Remove the exception
v2: Adjust the comment description of hdmi_mode_alternate_clock()
due t
On Mon, Nov 25, 2019 at 4:05 PM Ville Syrjälä
wrote:
>
> On Mon, Nov 25, 2019 at 10:02:38AM +0100, Daniel Vetter wrote:
> > On Fri, Nov 22, 2019 at 08:35:13PM +0200, Ville Syrjälä wrote:
> > > On Tue, Nov 19, 2019 at 11:14:43AM +0100, Daniel Vetter wrote:
> > > > On Fri, Nov 15, 2019 at 09:42:00PM
== Series Details ==
Series: drm/i915: Support more QGV points (rev4)
URL : https://patchwork.freedesktop.org/series/69886/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7418 -> Patchwork_15426
Summary
---
**SUCCESS*
On Fri, Nov 22, 2019 at 03:55:32PM +0200, Ville Syrjälä wrote:
On Thu, Nov 21, 2019 at 10:54:29AM -0800, Lucas De Marchi wrote:
On Thu, Nov 21, 2019 at 03:09:03PM +0200, Jani Nikula wrote:
>On Wed, 20 Nov 2019, Lucas De Marchi wrote:
>> The unaligned ioread32() will make us read byte by byte lo
== Series Details ==
Series: drm/i915: Default to more lenient force preempt timeout
URL : https://patchwork.freedesktop.org/series/69992/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7418 -> Patchwork_15427
Summary
--
== Series Details ==
Series: series starting with [V2,1/2] drm/edid: Add aspect ratios to HDMI 4K
modes
URL : https://patchwork.freedesktop.org/series/69993/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7418 -> Patchwork_15428
On Sun, 2019-11-24 at 11:27 +, Chris Wilson wrote:
> The implicit soft-pinning we use to probe the vm layout using
> execbuf,
> depends on the batch remaining active (not retired) between execbufs.
> Naturally, if the background retire worker runs the batch is retired
> and
> the implicit soft-
Hi all,
On 22-11-2019 21:45, Patchwork wrote:
== Series Details ==
Series: drm/i915: opregion: set opregion chpd value to indicate the driver
handles hotplug
URL : https://patchwork.freedesktop.org/series/69902/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7409 -> Patchwo
Chris,
I applied your patches and tested on DG1 hardware. This new code works
well, except there are still two issues to this test (gem_ctx_isloation.c)
1. the test loops over all possible engines (..ccs0, ccs1, ccs2,). the
legacy interface is used to check if an engine is supporte
On Mon, Nov 25, 2019 at 05:07:26PM +0200, Jani Nikula wrote:
> On Sat, 23 Nov 2019, Uma Shankar wrote:
> > This reverts commit f25c7a006cd1c07254780e3406e45cee4842b933.
> >
> > 2p2c display configuration blows up dmesg when one connector is
> > disconnected, causing issues in CI.
> >
> > Below are
On Mon, Nov 25, 2019 at 11:33:27AM -0500, Jerome Glisse wrote:
On Fri, Nov 22, 2019 at 11:33:12PM +, Jason Gunthorpe wrote:
On Fri, Nov 22, 2019 at 12:57:27PM -0800, Niranjana Vishwanathapura wrote:
[...]
> +static int
> +i915_range_fault(struct i915_svm *svm, struct hmm_range *range)
>
On Mon, Nov 18, 2019 at 11:35:26AM +0100, Daniel Vetter wrote:
> It's a dummy anyway.
>
> Signed-off-by: Daniel Vetter
> Cc: Russell King
I merged the entire series except this one and the final patch, sill
waiting a bit more for an ack on this perhaps.
-Daniel
> ---
> drivers/gpu/drm/armada/
Hi Gaurav
As we already talked, on upstream for now we do not want to recovery of
PSR runtime errors, so not merging this patch.
But if you want comments in this patch to merge in your kernel tree...I
would change the commit title to: "Do not mark as sink as not reliable
to PSR runtime errors" or
== Series Details ==
Series: drm/i915/selftests: Move mock_vma to the heap to reduce stack_frame
URL : https://patchwork.freedesktop.org/series/69981/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7417_full -> Patchwork_15422_full
==
Recent improvements in the state tracking in i915 caused PSR to not be
enabled when reusing firmware/BIOS modeset, this is due to all initial
commits returning ealier in intel_atomic_check() as needs_modeset()
is always false.
To fix that here forcing the state compute phase in CRTC that is
drivin
== Series Details ==
Series: drm/i915/display: Force the state compute phase once to enable PSR
URL : https://patchwork.freedesktop.org/series/7/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7420 -> Patchwork_15429
Sum
Support for Clear Color is contained in the last two patches
submitted by Radhakrishna Sripada. The first 5 patches are
currently undergoing review/revision changes. The first 5 patches
are cherry-picked from the series
https://patchwork.freedesktop.org/series/67078/
Expecting feedback for the las
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 modifier to identify
and parse n
From: Dhinakaran Pandiyan
Easier to read if all the alignment changes are in one place and contained
within a function.
Cc: Ville Syrjälä
Cc: Matt Roper
Signed-off-by: Dhinakaran Pandiyan
---
drivers/gpu/drm/i915/display/intel_display.c | 31 ++--
1 file changed, 16 insertion
From: Dhinakaran Pandiyan
intel_fill_fb_info() has grown quite large and wrapping the offset checks
into a separate function makes the loop a bit easier to follow.
Cc: Ville Syrjälä
Cc: Matt Roper
Signed-off-by: Dhinakaran Pandiyan
---
drivers/gpu/drm/i915/display/intel_display.c | 69 ++
1 - 100 of 134 matches
Mail list logo
