From: Oleg Vasilev
Since DP-specific information is stored in driver's structures, every
driver needs to implement subconnector property by itself. Display
Core already has the subconnector information, we only need to
expose it through DRM property.
v2:rebase
Cc: Alex Deucher
Cc: Christian Kö
From: Oleg Vasilev
Since DP-specific information is stored in driver's structures, every
driver needs to implement subconnector property by itself.
v2: rebase
Cc: Ben Skeggs
Cc: nouv...@lists.freedesktop.org
Signed-off-by: Jeevan B
Signed-off-by: Oleg Vasilev
Reviewed-by: Emil Velikov
Link:
From: Oleg Vasilev
Since DP-specific information is stored in driver's structures, every
driver needs to implement subconnector property by itself.
v2: updates to match previous commit changes
v3: rebase
Cc: Ville Syrjälä
Cc: intel-gfx@lists.freedesktop.org
Signed-off-by: Jeevan B
Signed-off
From: Oleg Vasilev
Since DP-specific information is stored in driver's structures, every
driver needs to implement subconnector property by itself.
v2: rebase
Cc: Alex Deucher
Cc: Christian König
Cc: David (ChunMing) Zhou
Cc: amd-...@lists.freedesktop.org
Signed-off-by: Jeevan B
Signed-off-
From: Oleg Vasilev
Currently, downstream port type is only reported in debugfs. This
information should be considered important since it reflects the actual
physical connector type. Some userspace (e.g. window compositors)
may want to show this info to a user.
The 'subconnector' property is alre
On Mon, Apr 06, 2020 at 11:26:21PM -0700, Sultan Alsawaf wrote:
> From: Sultan Alsawaf
>
> Hi,
>
> There's a mutex lock deadlock in i915 that only affects 5.4, but was fixed in
> 5.5. Normally, I would send a backport of the fix from 5.5, but the patch set
> that fixes the deadlock involves mass
Enable Display Audio WA #1406928334 for 4k+VDSC usecase
on DP encoders.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_audio.c | 110 +
drivers/gpu/drm/i915/i915_reg.h| 16 +++
2 files changed, 126 insertions(+)
diff --git a/drivers/gpu/drm/i9
On Mon, 06 Apr 2020, Lyude Paul wrote:
> The only reason for having this cast as void * before was because we
> originally needed to use drm_dp_mst_get_port_validated() and friends in
> order to (attempt to) safely access MST ports. However, we've since
> improved how reference counting works with
== Series Details ==
Series: drm/i915/gem: Apply more mb() around clflush relocation paths
URL : https://patchwork.freedesktop.org/series/75558/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8264_full -> Patchwork_17223_full
== Series Details ==
Series: series starting with [CI,1/3] drm/i915: Make exclusive awaits on
i915_active optional
URL : https://patchwork.freedesktop.org/series/75556/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8261_full -> Patchwork_17222_full
===
On Sat, Apr 04, 2020 at 11:40:57AM +0200, Christoph Hellwig wrote:
> Use the proper API instead.
>
> Fixes: f440c8a572d7 ("drm/i915/gvt/kvmgt: read/write GPA via KVM API")
> Signed-off-by: Christoph Hellwig
> ---
> drivers/gpu/drm/i915/gvt/kvmgt.c | 2 +-
> 1 file changed, 1 insertion(+), 1 dele
== Series Details ==
Series: series starting with [v2,1/8] drm/i915/display: Move out code to return
the digital_port of the aux ch
URL : https://patchwork.freedesktop.org/series/75576/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8264 -> Patchwork_17226
Hi Jani
On 2020-04-06 02:11, Jani Nikula wrote:
On Fri, 03 Apr 2020, abhin...@codeaurora.org wrote:
Hi Ville
Thanks for the patch.
Our understanding of private_flags was that we can use it within our
drivers to handle vendor specific features.
Hence we do have several features in our downstre
== Series Details ==
Series: series starting with [v2,1/8] drm/i915/display: Move out code to return
the digital_port of the aux ch
URL : https://patchwork.freedesktop.org/series/75576/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
14654d404b1a drm/i915/display: Move out code
Hi Jani
On 2020-04-06 01:32, Jani Nikula wrote:
On Fri, 03 Apr 2020, abhin...@codeaurora.org wrote:
On 2020-04-03 13:39, Ville Syrjala wrote:
diff --git a/drivers/gpu/drm/drm_modes.c
b/drivers/gpu/drm/drm_modes.c
index fec1c33b3045..e3d5f011f7bd 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/
This is required for legacy/static TC ports as IOM is not aware of
the connection and will not trigger the TC cold exit.
Just request PCODE to exit TCCOLD is not enough as it could enter
again before driver makes use of the port, to prevent it BSpec states
that aux powerwell should be held.
So he
This is a expected timeout of static TC ports not conneceted, so
not throwing warnings that would taint CI.
Signed-off-by: José Roberto de Souza
---
.../drm/i915/display/intel_display_power.c| 37 +++
1 file changed, 21 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu
Moving the code to return the digital port of the aux channel also
removing the intel_phy_is_tc() to make it generic.
digital_port will be needed in icl_tc_phy_aux_power_well_enable()
so adding it as a parameter to icl_tc_port_assert_ref_held().
While at at removing the duplicated call to icl_tc_p
As described in "drm/i915/tc/icl: Implement TC cold sequences" users
of TC functions should held aux power well during access to avoid
read garbage due HW in TC cold state.
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_tc.c | 22 --
1 file change
This is a preparation for ICL TC cold exit sequences.
v2:
- renamed new functions to hsw_power_well_enable_prepare()/complete()
Signed-off-by: José Roberto de Souza
---
.../drm/i915/display/intel_display_power.c| 39 +++
1 file changed, 32 insertions(+), 7 deletions(-)
diff
TC ports can enter in TCCOLD to save power and is required to request
to PCODE to exit this state before use or read to TC registers.
For TGL there is a new MBOX command to do that with a parameter to ask
PCODE to exit and block TCCOLD entry or unblock TCCOLD entry.
So adding a new power domain t
As part of ICL TC cold exit sequences we need to request aux power
well before lock the access to TC ports, so skiping the
intel_tc_port_ref_held() check for TC legacy ports.
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_display_power.c | 3 +++
1 file changed, 3 in
This is a similar function to intel_aux_power_domain() but it do not
care about TBT ports, this will be needed by ICL TC sequences.
v2:
- renamed to intel_legacy_aux_to_power_domain()
Cc: Imre Deak
Cc: Cooper Chiou
Cc: Kai-Heng Feng
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i9
== Series Details ==
Series: series starting with [1/3] drm/i915: introduce a mechanism to extend
execbuf2
URL : https://patchwork.freedesktop.org/series/75570/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8264 -> Patchwork_17225
=
== Series Details ==
Series: series starting with [1/3] drm/i915: introduce a mechanism to extend
execbuf2
URL : https://patchwork.freedesktop.org/series/75570/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
296bd5133612 drm/i915: introduce a mechanism to extend execbuf2
-:141:
== Series Details ==
Series: series starting with [v2,1/2] drm/i915/dp_mst: Cast
intel_connector->port as drm_dp_mst_port
URL : https://patchwork.freedesktop.org/series/75569/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8264 -> Patchwork_17224
==
On Sat, Apr 04, 2020 at 11:41:01AM +0200, Christoph Hellwig wrote:
> Some architectures like arm64 and s390 require USER_DS to be set for
> kernel threads to access user address space, which is the whole purpose
> of kthread_use_mm, but other like x86 don't. That has lead to a huge
> mess where so
== Series Details ==
Series: drm/i915/gem: Apply more mb() around clflush relocation paths
URL : https://patchwork.freedesktop.org/series/75558/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8264 -> Patchwork_17223
Summary
== Series Details ==
Series: drm/i915/gem: Apply more mb() around clflush relocation paths
URL : https://patchwork.freedesktop.org/series/75558/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
0e6160631516 drm/i915/gem: Apply more mb() around clflush relocation paths
-:24: WARNIN
Hi Pankaj,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on next-20200406]
[cannot apply to v5.6]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also
Introduces a new parameters to execbuf so that we can specify syncobj
handles as well as timeline points.
v2: Reuse i915_user_extension_fn
v3: Check that the chained extension is only present once (Chris)
v4: Check that dma_fence_chain_find_seqno returns a non NULL fence
(Lionel)
v5: Use BIT_UL
From: Lionel Landwerlin
We're planning to use this for a couple of new feature where we need
to provide additional parameters to execbuf.
v2: Check for invalid flags in execbuffer2 (Lionel)
v3: Rename I915_EXEC_EXT -> I915_EXEC_USE_EXTENSIONS (Chris)
Signed-off-by: Lionel Landwerlin
Reviewed-
The only reason for having this cast as void * before was because we
originally needed to use drm_dp_mst_get_port_validated() and friends in
order to (attempt to) safely access MST ports. However, we've since
improved how reference counting works with ports and mstbs such that we
can now rely on dr
Drive-by fix I noticed the other day - drm_dp_mst_has_audio() only ever
made sense back when we still had to validate ports before accessing
them in order to (attempt to) avoid NULL dereferences. Since we have
proper reference counting that guarantees we always can safely access
the MST port, there
From: Lionel Landwerlin
To allow faster engine to engine synchronization, peel the layer of
dma-fence-chain to expose potential i915 fences so that the
i915-request code can emit HW semaphore wait/signal operations in the
ring which is faster than waking up the host to submit unblocked
workloads
== Series Details ==
Series: Prefer drm_WARN* over WARN* (rev2)
URL : https://patchwork.freedesktop.org/series/75543/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8260_full -> Patchwork_17221_full
Summary
---
**SUCC
On Fri, Apr 3, 2020 at 6:23 PM Lyude Paul wrote:
>
> Drive-by fix I noticed the other day - drm_dp_mst_has_audio() only ever
> made sense back when we still had to validate ports before accessing
> them in order to (attempt to) avoid NULL dereferences. Since we have
> proper reference counting tha
== Series Details ==
Series: series starting with [CI,1/3] drm/i915: Make exclusive awaits on
i915_active optional
URL : https://patchwork.freedesktop.org/series/75556/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8261 -> Patchwork_17222
=
== Series Details ==
Series: series starting with [1/3] drm/i915/perf: break OA config buffer object
in 2
URL : https://patchwork.freedesktop.org/series/75550/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8260_full -> Patchwork_17220_full
On Sun, Apr 5, 2020 at 3:16 PM kbuild test robot wrote:
>
> Hi Chris,
>
> Thank you for the patch! Perhaps something to improve:
>
> [auto build test WARNING on drm-tip/drm-tip]
> [cannot apply to drm-intel/for-linux-next linus/master v5.6 next-20200405]
> [if your patch is applied to the wrong gi
== Series Details ==
Series: series starting with [1/5] drm/i915: Make exclusive awaits on
i915_active optional (rev2)
URL : https://patchwork.freedesktop.org/series/75535/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8260_full -> Patchwork_17219_full
===
Am 03.04.20 um 15:58 schrieb Daniel Vetter:
> Upcasting using a container_of macro is more typesafe, faster and
> easier for the compiler to optimize.
>
> Signed-off-by: Daniel Vetter
> Cc: Dave Airlie
> Cc: Gerd Hoffmann
> Cc: Daniel Vetter
> Cc: "Noralf Trønnes"
> Cc: Sam Ravnborg
> Cc:
Hi Pankaj,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on next-20200406]
[cannot apply to v5.6]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also
On Mon, Apr 6, 2020 at 10:04 AM Michel Dänzer wrote:
>
> On 2020-04-06 6:34 p.m., Rob Clark wrote:
> >
> > The ideal thing would be to be able to click any jobs that we want to
> > run, say "arm64_a630_gles31", and for gitlab to realize that it needs
> > to automatically trigger dependencies of th
Am 03.04.20 um 15:58 schrieb Daniel Vetter:
> Also need to remove the drm_dev_put from the remove hook.
>
> Signed-off-by: Daniel Vetter
> Cc: Dave Airlie
> Cc: Gerd Hoffmann
> Cc: virtualizat...@lists.linux-foundation.org
> Cc: spice-de...@lists.freedesktop.org
> ---
> drivers/gpu/drm/qxl/q
Am 05.04.20 um 12:18 schrieb Noralf Trønnes:
>
>
> Den 03.04.2020 15.57, skrev Daniel Vetter:
>> Also init the fbdev emulation before we register the device, that way
>> we can rely on the auto-cleanup and simplify the probe error code even
>> more.
>>
>> Signed-off-by: Daniel Vetter
>> Cc: Da
Hi
Am 03.04.20 um 15:57 schrieb Daniel Vetter:
> We use the baseclass pattern here, so lets to the proper (and more
> typesafe) upcasting.
>
> Signed-off-by: Daniel Vetter
> Cc: Hans de Goede
> ---
> drivers/gpu/drm/vboxvideo/vbox_drv.c | 1 -
> drivers/gpu/drm/vboxvideo/vbox_drv.h | 1 +
>
On 2020-04-06 6:34 p.m., Rob Clark wrote:
>
> The ideal thing would be to be able to click any jobs that we want to
> run, say "arm64_a630_gles31", and for gitlab to realize that it needs
> to automatically trigger dependencies of that job (meson-arm64, and
> arm_build+arm_test). But not sure if t
== Series Details ==
Series: drm/i915/gem: Take DBG_FORCE_RELOC into account prior to using reloc_gpu
URL : https://patchwork.freedesktop.org/series/75546/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8259_full -> Patchwork_17218_full
=
Having spent some time with DBG_FORCE_RELOC == FORCE_CPU_RELOC, it
appears that our memory barriers around the clflush are lackluster for
our more seldom used paths. Seldom used does not mean never, so apply
the memory barriers or else we may randomly see incorrect relocation
addresses inside batch
On Mon, Apr 6, 2020 at 8:43 AM Adam Jackson wrote:
>
> On Sat, 2020-04-04 at 08:11 -0700, Rob Clark wrote:
> > On Fri, Apr 3, 2020 at 7:12 AM Michel Dänzer wrote:
> > > On 2020-03-01 6:46 a.m., Marek Olšák wrote:
> > > > For Mesa, we could run CI only when Marge pushes, so that it's a
> > > > st
Refresh subtests which are still using pre-v4 MMAP_GTT API.
v2: Patch 2/2: clear 'map' before reuse (Zbigniew).
Janusz Krzysztofik (2):
tests/gem_userptr_blits: Refresh readonly-mmap-unsync exercise
tests/gem_userptr_blits: Refresh other still MMAP_GTT dependent
subtests
tests/i915/gem_
Upgrade the subtest to use MMAP_GTT API v4 (aka MMAP_OFFSET),
dynamically examine each mapping type supported by i915 driver.
Signed-off-by: Janusz Krzysztofik
Reviewed-by: Zbigniew Kempczyński
---
tests/i915/gem_userptr_blits.c | 21 -
1 file changed, 16 insertions(+), 5 de
Extend initial check for support of MMAP_GTT mapping to userptr with
equivalent checks for each MMAP_OFFSET mapping type supported by i915
driver. Based on that, extend coverage of process-exit-gtt* subtests
over non-GTT mapping types. In case of dmabuf-* subtests, use first
supported mapping typ
Hi Chris,
On Mon, Apr 06, 2020 at 04:35:18PM +0100, Chris Wilson wrote:
> The test is looking at sysfs/error so dumping the old
> debugfs/i915_error_state looks quite silly. The only dilemma is whether
> it is worth replacing with a line-by-line dump. I propose we make that a
> future problem -- a
Am 2020-04-04 um 5:41 a.m. schrieb Christoph Hellwig:
> Switch the function documentation to kerneldoc comments, and add
> WARN_ON_ONCE asserts that the calling thread is a kernel thread and
> does not have ->mm set (or has ->mm set in the case of unuse_mm).
>
> Also give the functions a kthread_ p
Am 2020-04-04 um 5:40 a.m. schrieb Christoph Hellwig:
> These helpers are only for use with kernel threads, and I will tie them
> more into the kthread infrastructure going forward. Also move the
> prototypes to kthread.h - mmu_context.h was a little weird to start with
> as it otherwise contains
Am 2020-04-04 um 5:40 a.m. schrieb Christoph Hellwig:
> Use the proper API instead.
>
> Fixes: 70539bd795002 ("drm/amd: Update MEC HQD loading code for KFD")
> Signed-off-by: Christoph Hellwig
Reviewed-by: Felix Kuehling
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h | 2 +-
> 1 file chan
Allow the caller to also wait upon the barriers stored in i915_active.
v2: Hook up i915_request_await_active(I915_ACTIVE_AWAIT_BARRIER) as well
for completeness, and avoid the lazy GEM_BUG_ON()!
v3: Pull flush_lazy_signals() under the active-ref protection as it too
walks the rbtree and so we mus
If we want to percolate information back from the HW, up through the GEM
context, we need to wait until the intel_context is scheduled out for
the last time. This is handled by the retirement of the intel_context's
barrier, i.e. by listening to the pulse after the notional unpin. So
wait until the
Later use will require asynchronous waits on the active timelines, but
will not utilize an async wait on the exclusive channel. Make the await
on the exclusive fence explicit in the selection flags.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_active.c |
On 06/04/2020 14:21, Chris Wilson wrote:
Allow the caller to also wait upon the barriers stored in i915_active.
v2: Hook up i915_request_await_active(I915_ACTIVE_AWAIT_BARRIER) as well
for completeness, and avoid the lazy GEM_BUG_ON()!
v3: Pull flush_lazy_signals() under the active-ref protec
On Sat, 2020-04-04 at 08:11 -0700, Rob Clark wrote:
> On Fri, Apr 3, 2020 at 7:12 AM Michel Dänzer wrote:
> > On 2020-03-01 6:46 a.m., Marek Olšák wrote:
> > > For Mesa, we could run CI only when Marge pushes, so that it's a strictly
> > > pre-merge CI.
> >
> > Thanks for the suggestion! I implem
The test is looking at sysfs/error so dumping the old
debugfs/i915_error_state looks quite silly. The only dilemma is whether
it is worth replacing with a line-by-line dump. I propose we make that a
future problem -- and leave it to whoever has to debug it next time.
Signed-off-by: Chris Wilson
-
Le samedi 04 avril 2020 à 15:55 +0200, Andreas Bergmeier a écrit :
> The problem of data transfer costs is not new in Cloud environments. At work
> we usually just opt for paying for it since dev time is scarser. For private
> projects though, I opt for aggressive (remote) caching.
> So you can s
Hello!
On 04.04.2020 12:40, Christoph Hellwig wrote:
Use the proper API instead.
Fixes: f440c8a572d7 ("drm/i915/gvt/kvmgt: read/write GPA via KVM API")
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/i915/gvt/kvmgt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/
Hi Daniel, Dave,
Here's this week round of drm-misc-next fixes.
Thanks!
Maxime
drm-misc-next-fixes-2020-04-04:
A bunch of fixes to avoid null pointer dereference in fbcon, fix a return
in xen, some DT bindings fixes, a vc4 issue with 1920x1200 mode validation,
and a conflicting framebuffer in vb
Le 03/04/2020 à 20:01, Linus Torvalds a écrit :
On Fri, Apr 3, 2020 at 12:21 AM Christophe Leroy
wrote:
Now we have user_read_access_begin() and user_write_access_begin()
in addition to user_access_begin().
I realize Al asked for this, but I don't think it really adds anything
to the serie
On Sat, Apr 04, 2020 at 11:16:08AM -0700, Rob Clark wrote:
> On Sat, Apr 4, 2020 at 10:47 AM Nicolas Dufresne wrote:
> >
> > Le samedi 04 avril 2020 à 08:11 -0700, Rob Clark a écrit :
> > > On Fri, Apr 3, 2020 at 7:12 AM Michel Dänzer wrote:
> > > > On 2020-03-01 6:46 a.m., Marek Olšák wrote:
> >
Em Sun, Apr 05, 2020 at 05:54:37PM +0300, Alexey Budankov escreveu:
>
> On 05.04.2020 17:41, Alexey Budankov wrote:
> >
> > On 05.04.2020 17:10, Arnaldo Carvalho de Melo wrote:
> >> Em Thu, Apr 02, 2020 at 11:54:39AM +0300, Alexey Budankov escreveu:
> >>>
> >>> Update kernel.rst documentation fil
On Sat, Apr 04, 2020 at 08:11:23AM -0700, Rob Clark wrote:
> On Fri, Apr 3, 2020 at 7:12 AM Michel Dänzer wrote:
> >
> > On 2020-03-01 6:46 a.m., Marek Olšák wrote:
> > > For Mesa, we could run CI only when Marge pushes, so that it's a strictly
> > > pre-merge CI.
> >
> > Thanks for the suggestion
Em Thu, Apr 02, 2020 at 11:54:39AM +0300, Alexey Budankov escreveu:
>
> Update kernel.rst documentation file with the information
> related to usage of CAP_PERFMON capability to secure performance
> monitoring and observability operations in system.
This one is failing in my perf/core branch, ple
On Fri, Apr 03, 2020 at 03:35:15PM -0700, Sultan Alsawaf wrote:
> + ref->retire(ref);
> + mutex_unlock(&ref->callback_lock);
Ugh, this patch is still wrong because the mutex unlock after ref->retire() is a
use-after-free. Fun times...
Sultan
___
The problem of data transfer costs is not new in Cloud environments. At
work we usually just opt for paying for it since dev time is scarser. For
private projects though, I opt for aggressive (remote) caching.
So you can setup a global cache in Google Cloud Storage and more local
caches wherever yo
Le samedi 04 avril 2020 à 08:11 -0700, Rob Clark a écrit :
> On Fri, Apr 3, 2020 at 7:12 AM Michel Dänzer wrote:
> > On 2020-03-01 6:46 a.m., Marek Olšák wrote:
> > > For Mesa, we could run CI only when Marge pushes, so that it's a strictly
> > > pre-merge CI.
> >
> > Thanks for the suggestion! I
== Series Details ==
Series: Prefer drm_WARN* over WARN* (rev2)
URL : https://patchwork.freedesktop.org/series/75543/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8260 -> Patchwork_17221
Summary
---
**SUCCESS**
N
On Mon, Mar 16, 2020 at 04:07:59PM +0530, Animesh Manna wrote:
> This patch process phy compliance request by programming requested
> vswing, pre-emphasis and test pattern.
>
> v1: Initial patch.
> v2: Fixes added during testing with test-scope. (Khaled/Clint/Manasi)
> - pipe used as argument duri
On Mon, Mar 30, 2020 at 10:13:02PM +0300, Souza, Jose wrote:
> On Mon, 2020-03-30 at 12:54 +0300, Imre Deak wrote:
> > On TypeC ports if a sink deasserts/reasserts its HPD signal,
> > generating
> > a hotplug interrupt without the sink getting unplugged/replugged from
> > the connector, there can b
== Series Details ==
Series: Prefer drm_WARN* over WARN* (rev2)
URL : https://patchwork.freedesktop.org/series/75543/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
fd886b340869 drm/i915/display/icl_dsi: Prefer drm_WARN_ON over WARN_ON
5a021e68d20b drm/i915/display/atomic_plane:
On Mon, 6 Apr 2020 at 13:36, Chris Wilson wrote:
>
> If we set the debug flag to force ourselves not to relocate via the gpu,
> do not relocate via the gpu.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
___
Intel-gfx mailing list
Intel-gfx@
== Series Details ==
Series: series starting with [1/3] drm/i915/perf: break OA config buffer object
in 2
URL : https://patchwork.freedesktop.org/series/75550/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8260 -> Patchwork_17220
==
Quoting Lionel Landwerlin (2020-04-06 15:30:38)
> On 06/04/2020 17:27, Chris Wilson wrote:
> > Quoting Lionel Landwerlin (2020-04-06 15:07:30)
> >> On 06/04/2020 16:59, Chris Wilson wrote:
> >>> Quoting Lionel Landwerlin (2020-04-06 14:54:38)
> On 31/03/2020 21:08, Chris Wilson wrote:
> >
On Mon, 6 Apr 2020 at 12:48, Chris Wilson wrote:
>
> __i915_gem_object_flush_map() takes a byte range, so feed it the written
> bytes and do not mistake the u32 index as bytes!
>
> Fixes: a679f58d0510 ("drm/i915: Flush pages on acquisition")
> Signed-off-by: Chris Wilson
> Cc: Matthew Auld
> Cc:
== Series Details ==
Series: series starting with [1/3] drm/i915/perf: break OA config buffer object
in 2
URL : https://patchwork.freedesktop.org/series/75550/
State : warning
== Summary ==
$ make htmldocs 2>&1 > /dev/null | grep i915
./drivers/gpu/drm/i915/i915_perf_types.h:319: warning: Fun
On 06/04/2020 17:27, Chris Wilson wrote:
Quoting Lionel Landwerlin (2020-04-06 15:07:30)
On 06/04/2020 16:59, Chris Wilson wrote:
Quoting Lionel Landwerlin (2020-04-06 14:54:38)
On 31/03/2020 21:08, Chris Wilson wrote:
Quoting Lionel Landwerlin (2020-03-31 12:48:21)
Add 2 new properties to t
Quoting Lionel Landwerlin (2020-04-06 15:07:30)
> On 06/04/2020 16:59, Chris Wilson wrote:
> > Quoting Lionel Landwerlin (2020-04-06 14:54:38)
> >> On 31/03/2020 21:08, Chris Wilson wrote:
> >>> Quoting Lionel Landwerlin (2020-03-31 12:48:21)
> Add 2 new properties to the i915-perf open ioctl
== Series Details ==
Series: series starting with [1/3] drm/i915/perf: break OA config buffer object
in 2
URL : https://patchwork.freedesktop.org/series/75550/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
d78a933fe510 drm/i915/perf: break OA config buffer object in 2
-:27: CH
== Series Details ==
Series: series starting with [1/5] drm/i915: Make exclusive awaits on
i915_active optional (rev2)
URL : https://patchwork.freedesktop.org/series/75535/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8260 -> Patchwork_17219
=
On 06/04/2020 16:59, Chris Wilson wrote:
Quoting Lionel Landwerlin (2020-04-06 14:54:38)
On 31/03/2020 21:08, Chris Wilson wrote:
Quoting Lionel Landwerlin (2020-03-31 12:48:21)
Add 2 new properties to the i915-perf open ioctl to specify an array
of GEM context handles as well as the length of
Quoting Lionel Landwerlin (2020-04-06 14:54:38)
> On 31/03/2020 21:08, Chris Wilson wrote:
> > Quoting Lionel Landwerlin (2020-03-31 12:48:21)
> >> Add 2 new properties to the i915-perf open ioctl to specify an array
> >> of GEM context handles as well as the length of the array.
> > Hmm. The other
On Mon, Apr 6, 2020 at 3:38 PM Greg Kroah-Hartman
wrote:
>
> On Mon, Apr 06, 2020 at 02:32:51PM +0200, Daniel Vetter wrote:
> > On Fri, Apr 3, 2020 at 3:58 PM Daniel Vetter wrote:
> > >
> > > In drm we've added nice drm_device (the main gpu driver thing, which
> > > also represents the userspace
Add 2 new properties to the i915-perf open ioctl to specify an array
of GEM context handles as well as the length of the array.
This can be used by drivers using multiple GEM contexts to implement a
single GL context.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_perf.c | 58 ++
Make all the internal necessary changes before we flip the switch.
v2: Use an unlimited number of intel contexts (Chris)
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_perf.c | 587 +++--
drivers/gpu/drm/i915/i915_perf_types.h | 23 +-
2 files changed,
We want to enable performance monitoring on multiple contexts to cover
the Iris use case of using 2 GEM contexts (3D & compute).
So start by breaking the OA configuration BO which contains global &
per context register writes.
NOA muxes & OA configurations are global, while FLEXEU register
config
On 31/03/2020 21:08, Chris Wilson wrote:
Quoting Lionel Landwerlin (2020-03-31 12:48:21)
Add 2 new properties to the i915-perf open ioctl to specify an array
of GEM context handles as well as the length of the array.
Hmm. The other thought is ctx->engine[] where one context may have more
than o
On Mon, Apr 06, 2020 at 02:32:51PM +0200, Daniel Vetter wrote:
> On Fri, Apr 3, 2020 at 3:58 PM Daniel Vetter wrote:
> >
> > In drm we've added nice drm_device (the main gpu driver thing, which
> > also represents the userspace interfaces and has everything else
> > dangling off it) init functions
== Series Details ==
Series: series starting with [1/5] drm/i915: Make exclusive awaits on
i915_active optional
URL : https://patchwork.freedesktop.org/series/75535/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8259_full -> Patchwork_17215_full
==
Allow the caller to also wait upon the barriers stored in i915_active.
v2: Hook up i915_request_await_active(I915_ACTIVE_AWAIT_BARRIER) as well
for completeness, and avoid the lazy GEM_BUG_ON()!
v3: Pull flush_lazy_signals() under the active-ref protection as it too
walks the rbtree and so we mus
== Series Details ==
Series: drm/i915/gem: Take DBG_FORCE_RELOC into account prior to using reloc_gpu
URL : https://patchwork.freedesktop.org/series/75546/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8259 -> Patchwork_17218
===
Quoting Chris Wilson (2020-04-06 14:09:44)
> Quoting Tvrtko Ursulin (2020-04-06 13:06:03)
> >
> > On 06/04/2020 10:12, Chris Wilson wrote:
> > > Allow the caller to also wait upon the barriers stored in i915_active.
> > >
> > > Signed-off-by: Chris Wilson
> > > ---
> > > drivers/gpu/drm/i915/i
1 - 100 of 153 matches
Mail list logo
