Introduce a new mutex to guard all of the vma operations within a vm (as
opposed to the BKL struct_mutex) and start by using it to guard the
fence operations for a GGTT VMA.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c| 9 ++-
drivers/gpu/drm/i915/i915_gem.c
Add a mutex into struct i915_address_space to be used while operating on
the vma and their lists for a particular vm. As this may be called from
the shrinker, we taint the mutex with fs_reclaim so that from the start
lockdep warns us if we are caught holding the mutex across an
allocation. (With su
If we dynamically allocate the correct sized array for the fence
registers, we can avoid the 4x overallocation on older, typically
smaller devices and avoid having to know the static layout in advance.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 33
d
Now that the submission backends are controlled via their own spinlocks,
with a wave of a magic wand we can lift the struct_mutex requirement
around GPU reset. That is we allow the submission frontend (userspace)
to keep on submitting while we process the GPU reset as we can suspend
the backend ind
Since we have a header file for i915_gem_fence_reg, let's use it for the
interface prototypes currently hidden away in the huge i915_drv.h
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_drv.h | 15 ---
drivers/gpu/drm/i915/i915_gem_fen
While killing off struct_mutex inside reset opens the door to killing
off struct_mutex *everywhere*, my ulterior goal for this series to fixup
the live_hangcheck/live_workaround BAT/IGT flip-flops.
Please review kindly,
-Chris
___
Intel-gfx mailing lis
Currently the code to reset the GPU and our state is spread widely
across a few files. Pull the logic together into a common file.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/Makefile |3 +-
drivers/gpu/drm/i915/i915_debugfs.c |2 +
drivers/gpu/drm/i915
As the fence registers define special regions of the mappable aperture
inside the Global GTT, and we track those regions using GGTT VMA, it
makes sense to pull that bookkeeping under i915_ggtt. The advantage is
that we can then start using a local GGTT lock to handle the fence
registers (in conjunc
Sometimes, we do not want to allow control to escape from the spinner,
e.g. for when we want to hang the GPU inside the batch.
(Split out from the preempt-timeout test case.)
Signed-off-by: Chris Wilson
Reviewed-by: Antonio Argenziano
---
lib/igt_dummyload.c | 5 ++---
lib/igt_dummyload.h | 7
Quoting Zhenyu Wang (2018-07-11 03:33:53)
>
> Hi,
>
> Here's last gvt-next pull for 4.19. Biggest change is to
> add vGPU huge page support for guest, with one BXT fix and
> gvt dependency handling.
Any progress to cleaning up all the compiler warnings for W=1?
-Chris
___
== Series Details ==
Series: series starting with [1/7] drm/i915: Introduce i915_address_space.mutex
URL : https://patchwork.freedesktop.org/series/46289/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
bfb49745fd80 drm/i915: Introduce i915_address_space.mutex
0fc3f4498130 drm/i9
== Series Details ==
Series: series starting with [1/7] drm/i915: Introduce i915_address_space.mutex
URL : https://patchwork.freedesktop.org/series/46289/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm/i915: Introduce i915_address_space.mutex
+drivers/gpu/drm/i915/i915_g
On 2018.07.11 08:45:08 +0100, Chris Wilson wrote:
> Quoting Zhenyu Wang (2018-07-11 03:33:53)
> >
> > Hi,
> >
> > Here's last gvt-next pull for 4.19. Biggest change is to
> > add vGPU huge page support for guest, with one BXT fix and
> > gvt dependency handling.
>
> Any progress to cleaning up a
== Series Details ==
Series: series starting with [1/7] drm/i915: Introduce i915_address_space.mutex
URL : https://patchwork.freedesktop.org/series/46289/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4469 -> Patchwork_9607 =
== Summary - SUCCESS ==
No regressions found.
On Wed, Jul 11, 2018 at 08:36:02AM +0100, Chris Wilson wrote:
> Add a mutex into struct i915_address_space to be used while operating on
> the vma and their lists for a particular vm. As this may be called from
> the shrinker, we taint the mutex with fs_reclaim so that from the start
> lockdep warn
On Wed, Jul 11, 2018 at 08:36:03AM +0100, Chris Wilson wrote:
> As the fence registers define special regions of the mappable aperture
> inside the Global GTT, and we track those regions using GGTT VMA, it
> makes sense to pull that bookkeeping under i915_ggtt. The advantage is
> that we can then s
Quoting Daniel Vetter (2018-07-11 09:19:58)
> On Wed, Jul 11, 2018 at 08:36:03AM +0100, Chris Wilson wrote:
> > @@ -5630,32 +5631,33 @@ i915_gem_cleanup_engines(struct drm_i915_private
> > *dev_priv)
> > dev_priv->gt.cleanup_engine(engine);
> > }
> >
> > -void
> > -i915_gem_load_i
If we want to set new module options, we must load the module or die
trying. We may want to always fail if the module if already loaded, but
for now, take the small incremental step and insist that the options are
set if requested.
Signed-off-by: Chris Wilson
---
lib/igt_kmod.c | 8 +++-
1 f
The current method of checking for a failed module load is flawed, as we
only report the error on probing it is not being reported back by
modprobe. So we have to dig inside the module_parameters while the
module is still loaded to discover the error.
v2: Expect i915.inject_load_failure to be zero
On Wed, Jul 11, 2018 at 09:46:18AM +0100, Chris Wilson wrote:
> If we want to set new module options, we must load the module or die
> trying. We may want to always fail if the module if already loaded, but
> for now, take the small incremental step and insist that the options are
> set if requeste
== Series Details ==
Series: series starting with [1/7] drm/i915: Introduce i915_address_space.mutex
URL : https://patchwork.freedesktop.org/series/46289/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4469_full -> Patchwork_9607_full =
== Summary - FAILURE ==
Serious unk
On Tue 10-07-18 19:20:20, Leon Romanovsky wrote:
> On Tue, Jul 10, 2018 at 04:14:10PM +0200, Michal Hocko wrote:
> > On Tue 10-07-18 16:40:40, Leon Romanovsky wrote:
> > > On Mon, Jul 09, 2018 at 02:29:08PM +0200, Michal Hocko wrote:
> > > > On Wed 27-06-18 09:44:21, Michal Hocko wrote:
> > > > > T
On Wed, Jul 11, 2018 at 08:36:04AM +0100, Chris Wilson wrote:
> Introduce a new mutex to guard all of the vma operations within a vm (as
> opposed to the BKL struct_mutex) and start by using it to guard the
> fence operations for a GGTT VMA.
Commit message is a bit confusing, since you've already
On Wed, Jul 11, 2018 at 08:36:06AM +0100, Chris Wilson wrote:
> If we dynamically allocate the correct sized array for the fence
> registers, we can avoid the 4x overallocation on older, typically
> smaller devices and avoid having to know the static layout in advance.
>
> Signed-off-by: Chris Wil
On Wed, Jul 11, 2018 at 08:36:07AM +0100, Chris Wilson wrote:
> Currently the code to reset the GPU and our state is spread widely
> across a few files. Pull the logic together into a common file.
>
> Signed-off-by: Chris Wilson
Hm when reading the fence code I'd suggested more to move the reset
Quoting Daniel Vetter (2018-07-11 10:17:09)
> On Wed, Jul 11, 2018 at 08:36:07AM +0100, Chris Wilson wrote:
> > Currently the code to reset the GPU and our state is spread widely
> > across a few files. Pull the logic together into a common file.
> >
> > Signed-off-by: Chris Wilson
>
> Hm when r
On 10/07/2018 18:32, Lis, Tomasz wrote:
On 2018-07-09 18:37, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-07-09 17:28:02)
On 09/07/2018 14:20, Tomasz Lis wrote:
+static int i915_gem_context_clear_data_port_coherent(struct i915_gem_context
*ctx)
+{
+ int ret;
+
+ ret = intel_lr_co
On Wed, Jul 11, 2018 at 08:36:02AM +0100, Chris Wilson wrote:
> Add a mutex into struct i915_address_space to be used while operating on
> the vma and their lists for a particular vm. As this may be called from
> the shrinker, we taint the mutex with fs_reclaim so that from the start
> lockdep warn
On Wed, Jul 11, 2018 at 11:33:26AM +0200, Daniel Vetter wrote:
> On Wed, Jul 11, 2018 at 08:36:02AM +0100, Chris Wilson wrote:
> > Add a mutex into struct i915_address_space to be used while operating on
> > the vma and their lists for a particular vm. As this may be called from
> > the shrinker, w
Quoting Daniel Vetter (2018-07-11 10:36:36)
> On Wed, Jul 11, 2018 at 11:33:26AM +0200, Daniel Vetter wrote:
> > On Wed, Jul 11, 2018 at 08:36:02AM +0100, Chris Wilson wrote:
> > > Add a mutex into struct i915_address_space to be used while operating on
> > > the vma and their lists for a particula
Since live_workarounds poke around the w/a registers and checks to see
if they survive across a reset, we are prone to fouling the machine and
leaving it in a non-recoverable state. Wrap the probe inside a timeout
to abort the test if the reset fails.
Bugzilla: https://bugs.freedesktop.org/show_bu
On Wed, Jul 11, 2018 at 11:03:53AM +0200, Michal Hocko wrote:
> On Tue 10-07-18 19:20:20, Leon Romanovsky wrote:
> > On Tue, Jul 10, 2018 at 04:14:10PM +0200, Michal Hocko wrote:
> > > On Tue 10-07-18 16:40:40, Leon Romanovsky wrote:
> > > > On Mon, Jul 09, 2018 at 02:29:08PM +0200, Michal Hocko wr
== Series Details ==
Series: drm/i915/selftests: Add a safety net to live_workarounds
URL : https://patchwork.freedesktop.org/series/46301/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
5f67aab2a681 drm/i915/selftests: Add a safety net to live_workarounds
-:15: WARNING:FILE_PAT
Hi Mahesh,
On Tuesday, 10 July 2018 15:59:11 EEST Kumar, Mahesh wrote:
> On 7/10/2018 5:07 PM, Laurent Pinchart wrote:
> > On Monday, 2 July 2018 14:07:24 EEST Mahesh Kumar wrote:
> >> This patch implements "verify_crc_source" callback function for
> >> rcar drm driver.
> >>
> >> Signed-off-by: M
== Series Details ==
Series: mm, oom: distinguish blockable mode for mmu notifiers (rev6)
URL : https://patchwork.freedesktop.org/series/45263/
State : failure
== Summary ==
Applying: mm, oom: distinguish blockable mode for mmu notifiers
error: patch failed: mm/oom_kill.c:1
error: mm/oom_kill.
Quoting Daniel Vetter (2018-07-11 10:08:46)
> On Wed, Jul 11, 2018 at 08:36:04AM +0100, Chris Wilson wrote:
> > Introduce a new mutex to guard all of the vma operations within a vm (as
> > opposed to the BKL struct_mutex) and start by using it to guard the
> > fence operations for a GGTT VMA.
>
>
== Series Details ==
Series: drm/i915/selftests: Add a safety net to live_workarounds
URL : https://patchwork.freedesktop.org/series/46301/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4469 -> Patchwork_9608 =
== Summary - SUCCESS ==
No regressions found.
External UR
Quoting Chris Wilson (2018-07-11 11:57:38)
> Quoting Daniel Vetter (2018-07-11 10:08:46)
> > I think the above change isn't correct, at least not yet at this stage:
> > All users of the userfault_list still use dev->struct_mutex, not vm.mutex.
> > I guess we could move that over to the ggtt.vm.mute
On Wed 11-07-18 13:14:47, Leon Romanovsky wrote:
> On Wed, Jul 11, 2018 at 11:03:53AM +0200, Michal Hocko wrote:
> > On Tue 10-07-18 19:20:20, Leon Romanovsky wrote:
> > > On Tue, Jul 10, 2018 at 04:14:10PM +0200, Michal Hocko wrote:
> > > > On Tue 10-07-18 16:40:40, Leon Romanovsky wrote:
> > > >
On 2018-07-10 20:03, Lis, Tomasz wrote:
On 2018-07-09 18:28, Tvrtko Ursulin wrote:
On 09/07/2018 14:20, Tomasz Lis wrote:
diff --git a/drivers/gpu/drm/i915/intel_lrc.h
b/drivers/gpu/drm/i915/intel_lrc.h
index 1593194..f6965ae 100644
--- a/drivers/gpu/drm/i915/intel_lrc.h
+++ b/drivers/g
Chris Wilson writes:
> Since live_workarounds poke around the w/a registers and checks to see
> if they survive across a reset, we are prone to fouling the machine and
> leaving it in a non-recoverable state. Wrap the probe inside a timeout
> to abort the test if the reset fails.
>
> Bugzilla: ht
Quoting Mika Kuoppala (2018-07-11 12:27:49)
> Chris Wilson writes:
>
> > Since live_workarounds poke around the w/a registers and checks to see
> > if they survive across a reset, we are prone to fouling the machine and
> > leaving it in a non-recoverable state. Wrap the probe inside a timeout
>
On Tue, Jul 10, 2018 at 12:32 PM, NeilBrown wrote:
> On Tue, Jul 10 2018, Daniel Vetter wrote:
>
>> On Mon, Jul 09, 2018 at 04:30:01PM -0700, Andrew Morton wrote:
>>> On Mon, 9 Jul 2018 18:25:09 +0200 Daniel Vetter
>>> wrote:
>>>
>>> > To avoid compilers complainig about ambigious else blocks w
On Wed, Jul 11, 2018 at 01:13:18PM +0200, Michal Hocko wrote:
> On Wed 11-07-18 13:14:47, Leon Romanovsky wrote:
> > On Wed, Jul 11, 2018 at 11:03:53AM +0200, Michal Hocko wrote:
> > > On Tue 10-07-18 19:20:20, Leon Romanovsky wrote:
> > > > On Tue, Jul 10, 2018 at 04:14:10PM +0200, Michal Hocko wr
On Sat, Jul 07, 2018 at 08:23:30PM -0300, Rodrigo Siqueira wrote:
> This patch fix the following GCC warning:
>
> intel_gvtg_test.c: In function ‘create_guest’:
> intel_gvtg_test.c:127:50: warning: ‘%s’ directive writing up to 4095
> bytes into a region of size 4077 [-Wformat-overflow=]
> [..]
> i
From: Hans Verkuil
Implement support for this DisplayPort feature.
Signed-off-by: Hans Verkuil
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_dp.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/dr
From: Hans Verkuil
This adds support for the DisplayPort CEC-Tunneling-over-AUX
feature that is part of the DisplayPort 1.3 standard.
Unfortunately, not all DisplayPort/USB-C to HDMI adapters with a
chip that has this capability actually hook up the CEC pin, so
even though a CEC device is create
Since live_workarounds poke around the w/a registers and checks to see
if they survive across a reset, we are prone to fouling the machine and
leaving it in a non-recoverable state. Wrap the probe inside a timeout
to abort the test if the reset fails.
v2: Include GEM_TRACE on declaring wedged.
Bu
From: Hans Verkuil
Document the Display Port CEC helper functions.
Signed-off-by: Hans Verkuil
Reviewed-by: Ville Syrjälä
---
Documentation/gpu/drm-kms-helpers.rst | 9 +
1 file changed, 9 insertions(+)
diff --git a/Documentation/gpu/drm-kms-helpers.rst
b/Documentation/gpu/drm-kms-h
From: Hans Verkuil
This patch series adds support for the DisplayPort CEC-Tunneling-over-AUX
feature. This patch series is based on the current media master branch
(https://git.linuxtv.org/media_tree.git/log/) but it applies fine on top
of the current mainline tree.
The v9 is identical to v8, th
Since live_workarounds poke around the w/a registers and checks to see
if they survive across a reset, we are prone to fouling the machine and
leaving it in a non-recoverable state. Wrap the probe inside a timeout
to abort the test if the reset fails.
v2: Include GEM_TRACE on declaring wedged.
v3:
== Series Details ==
Series: drm/i915: add DisplayPort CEC-Tunneling-over-AUX support
URL : https://patchwork.freedesktop.org/series/46306/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
a9b15a0bc541 drm: add support for DisplayPort CEC-Tunneling-over-AUX
-:53: WARNING:FILE_PATH
== Series Details ==
Series: drm/i915: add DisplayPort CEC-Tunneling-over-AUX support
URL : https://patchwork.freedesktop.org/series/46306/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm: add support for DisplayPort CEC-Tunneling-over-AUX
+
+Error in reading or end of fi
== Series Details ==
Series: drm/i915: add DisplayPort CEC-Tunneling-over-AUX support
URL : https://patchwork.freedesktop.org/series/46306/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4469 -> Patchwork_9610 =
== Summary - SUCCESS ==
No regressions found.
External UR
Chris Wilson writes:
> Since live_workarounds poke around the w/a registers and checks to see
> if they survive across a reset, we are prone to fouling the machine and
> leaving it in a non-recoverable state. Wrap the probe inside a timeout
> to abort the test if the reset fails.
>
> v2: Include
== Series Details ==
Series: drm/i915/selftests: Add a safety net to live_workarounds (rev3)
URL : https://patchwork.freedesktop.org/series/46301/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
a79baf771e2d drm/i915/selftests: Add a safety net to live_workarounds
-:20: WARNING:F
On 29/06/2018 08:53, Chris Wilson wrote:
The kernel recently gained an augmented rbtree with the purpose of
cacheing the leftmost element of the rbtree, a frequent optimisation to
avoid calls to rb_first() which is also employed by the
execlists->queue. Switch from our open-coded cache to the li
From: Hans Verkuil
Document the Display Port CEC helper functions.
Signed-off-by: Hans Verkuil
Reviewed-by: Ville Syrjälä
---
Documentation/gpu/drm-kms-helpers.rst | 9 +
1 file changed, 9 insertions(+)
diff --git a/Documentation/gpu/drm-kms-helpers.rst
b/Documentation/gpu/drm-kms-h
From: Hans Verkuil
Implement support for this DisplayPort feature.
Signed-off-by: Hans Verkuil
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_dp.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/dr
From: Hans Verkuil
This patch series adds support for the DisplayPort CEC-Tunneling-over-AUX
feature. This patch series is based on top of drm-intel-next.
The v10 is identical to v9, except it is rebased to drm-intel-next (v9
didn't apply cleanly) and two alignment warnings have been fixed.
The
From: Hans Verkuil
This adds support for the DisplayPort CEC-Tunneling-over-AUX
feature that is part of the DisplayPort 1.3 standard.
Unfortunately, not all DisplayPort/USB-C to HDMI adapters with a
chip that has this capability actually hook up the CEC pin, so
even though a CEC device is create
== Series Details ==
Series: drm/i915/selftests: Add a safety net to live_workarounds (rev3)
URL : https://patchwork.freedesktop.org/series/46301/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4469 -> Patchwork_9611 =
== Summary - SUCCESS ==
No regressions found.
Exte
== Series Details ==
Series: drm/i915: add DisplayPort CEC-Tunneling-over-AUX support (rev2)
URL : https://patchwork.freedesktop.org/series/46306/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
79b707b649f8 drm: add support for DisplayPort CEC-Tunneling-over-AUX
-:53: WARNING:FI
== Series Details ==
Series: drm/i915: add DisplayPort CEC-Tunneling-over-AUX support (rev2)
URL : https://patchwork.freedesktop.org/series/46306/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm: add support for DisplayPort CEC-Tunneling-over-AUX
+
+Error in reading or en
== Series Details ==
Series: drm/i915: add DisplayPort CEC-Tunneling-over-AUX support (rev2)
URL : https://patchwork.freedesktop.org/series/46306/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4469 -> Patchwork_9612 =
== Summary - SUCCESS ==
No regressions found.
Exte
i915_driver_load registers a component master and i915 driver
registration is moved into the bind call of that component master.
If any component of the particular features are registered with this
I915 component master's match, then I915 registration will wait
until all registered components are
If all the components associated to a component master is not added
to the component framework due to the HW capability or Kconfig
selection, component_match will be NULL at
component_master_add_with_match().
To avoid this, component_match_alloc() is added to the framework,
to allcoate the struct
A generic component master is added to hold the i915 registration
untill all required kernel modules are up and active.
This is achieved through following steps:
- moving the i915 driver registration to the component master's
bind call
- all required kernel modules
Initialize HDCP2.2 support. This includes the mei interface
initialization along with required component registration.
v2:
mei interface handle is protected with mutex. [Chris Wilson]
v3:
Notifiers are used for the mei interface state.
v4:
Poll for mei client device state
Error msg for out
== Series Details ==
Series: I915 component master
URL : https://patchwork.freedesktop.org/series/46312/
State : failure
== Summary ==
Applying: component: alloc component_match without any comp to match
Applying: drm/i915: component master at i915 driver load
Applying: drm/i915: Initialize HD
This is effectively no-op as the next line writes a nul at the final
byte of the buffer, so copying one letter less does not change the
behaviour.
Signed-off-by: Dominique Martinet
---
gcc 8 gives the following warning, which I am not sure why is treated
as error for this file, thus making me fi
Quoting Dominique Martinet (2018-07-11 08:46:15)
> This is effectively no-op as the next line writes a nul at the final
> byte of the buffer, so copying one letter less does not change the
> behaviour.
>
> Signed-off-by: Dominique Martinet
> ---
>
> gcc 8 gives the following warning, which I am
== Series Details ==
Series: i915/intel_tv_get_modes: fix strncpy truncation warning
URL : https://patchwork.freedesktop.org/series/46314/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4470 -> Patchwork_9614 =
== Summary - SUCCESS ==
No regressions found.
External URL
This series improves crc-core <-> driver interface.
This series adds following functionality in the crc-core
- Now control node will print all the available sources if
implemented by driver along with current source.
- Setting of sorce will fail if provided source is not supported
- cleanup o
This patch implements "verify_crc_source" callback function for
rockchip drm driver.
Changes since V1:
- simplify the verification (Jani N)
Signed-off-by: Mahesh Kumar
Cc: dri-de...@lists.freedesktop.org
Reviewed-by: Maarten Lankhorst
Acked-by: Heiko Stuebner
---
drivers/gpu/drm/rockchip/roc
This patch adds a new callback function "verify_crc_source" which will
be used during setting the crc source in control node. This will help
in avoiding setting of wrong string for source.
Changes since V1:
- do not yet verify_crc_source during open.
Signed-off-by: Mahesh Kumar
Cc: dri-de...@li
This patch introduce a callback function "get_crc_sources" which
will be called during read of control node. It is an optional
callback function and if driver implements this callback, driver
should return a constant pointer to an array of crc sources list
and update count according to the number o
This patch implements "verify_crc_source" callback function for
rcar drm driver.
Changes Since V1:
- avoid duplication of code
Signed-off-by: Mahesh Kumar
Cc: dri-de...@lists.freedesktop.org
Cc: Laurent Pinchart
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 66 +
This patch implements "verify_crc_source" callback function for
AMD drm driver.
Signed-off-by: Mahesh Kumar
Cc: dri-de...@lists.freedesktop.org
Reviewed-by: Maarten Lankhorst
Acked-by: Leo Li
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 1 +
drivers/gpu/drm/amd/display/amdgpu_d
This patch implements get_crc_sources callback, which returns list of
all the valid crc sources supported by driver in current platform.
Changes since V1:
- Return array of crc sources
Signed-off-by: Mahesh Kumar
Cc: dri-de...@lists.freedesktop.org
Reviewed-by: Maarten Lankhorst
---
drivers/g
This patch implements verify_crc_source callback function introduced
earlier in this series.
Signed-off-by: Mahesh Kumar
Cc: dri-de...@lists.freedesktop.org
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 1 +
drivers/gpu/drm/i915/intel_drv.h | 3 +
drivers/g
This reverts commit e8fa5671183c80342d520ad81d14fa79a9d4a680.
Don't wait for first CRC during crtc_crc_open. It avoids one frame wait
during open. If application want to wait after read call, it can use
poll/read blocking read() call.
Suggested-by: Ville Syrjälä
Signed-off-by: Mahesh Kumar
Cc:
This patch make changes to allocate crc-entries buffer before
enabling CRC generation.
It moves all the failure check early in the function before setting
the source or memory allocation.
Now set_crc_source takes only two variable inputs, values_cnt we
already gets as part of verify_crc_source.
Ch
This patch implements get_crc_sources callback, which returns list of
all the crc sources supported by driver in current platform.
Signed-off-by: Mahesh Kumar
Cc: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 11 ++
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 2 +
drivers/gpu/
On Wed, Jul 11, 2018 at 04:09:03PM +0200, Hans Verkuil wrote:
> Hi Ville,
>
> On 11/07/18 15:41, Patchwork wrote:
> > == Series Details ==
> >
> > Series: drm/i915: add DisplayPort CEC-Tunneling-over-AUX support (rev2)
> > URL : https://patchwork.freedesktop.org/series/46306/
> > State : warnin
== Series Details ==
Series: Improve crc-core driver interface (rev5)
URL : https://patchwork.freedesktop.org/series/45246/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm: crc: Introduce verify_crc_source callback
Okay!
Commit: drm: crc: Introduce get_crc_sources callba
== Series Details ==
Series: Improve crc-core driver interface (rev5)
URL : https://patchwork.freedesktop.org/series/45246/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4470 -> Patchwork_9615 =
== Summary - FAILURE ==
Serious unknown changes coming with Patchwork_9615 a
On Mon, Jul 09, 2018 at 10:36:40AM +0200, Daniel Vetter wrote:
> Makes the macros resilient against if {} else {} blocks right
> afterwards.
>
> Signed-off-by: Daniel Vetter
> Cc: Tejun Heo
> Cc: Jens Axboe
> Cc: Shaohua Li
> Cc: Kate Stewart
> Cc: Greg Kroah-Hartman
> Cc: Joseph Qi
> Cc: D
On Wed, Jul 11, 2018 at 09:40:58AM -0700, Tejun Heo wrote:
> On Mon, Jul 09, 2018 at 10:36:40AM +0200, Daniel Vetter wrote:
> > Makes the macros resilient against if {} else {} blocks right
> > afterwards.
> >
> > Signed-off-by: Daniel Vetter
> > Cc: Tejun Heo
> > Cc: Jens Axboe
> > Cc: Shaohua
On Mon, Jul 09, 2018 at 10:36:41AM +0200, Daniel Vetter wrote:
> Avoids the need to invert the condition instead of the open-coded
> version.
>
> Signed-off-by: Daniel Vetter
> Cc: Tejun Heo
> Cc: Li Zefan
> Cc: Johannes Weiner
> Cc: cgro...@vger.kernel.org
Acked-by: Tejun Heo
Please feel f
On Tue, Jul 10, 2018 at 2:51 AM Chris Wilson wrote:
>
> Quoting Lucas De Marchi (2018-07-10 01:06:58)
> > diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > index 1932bc227942..a5eec97a40fe 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_ex
On 7/9/2018 6:19 AM, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Commit 87d2affc380da96ba66c258c5337c363fe8651ef ("trace.pl: Add support
for colouring context execution"), due some dodgy attempts at patch
splitting broke the legacy colouring mode.
Fix it by passing in the request stage into the
On 7/9/2018 6:19 AM, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
vis library has a limited precision compared to our trace data which
prevents zooming into the timeline and seeing the fine detail.
Scale the HTML view by a thousand to work around it.
Signed-off-by: Tvrtko Ursulin
Suggested-by:
On 7/9/2018 6:19 AM, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Turn off timeline stacking in favour of putting all the boxes belonging to
a single context at the same vertical slot.
Also remove the custom sorting function in favour of correctly assigning
the subgroup id's and order which grea
Thanks seanpaul for the reviews.
> -Original Message-
> From: Sean Paul [mailto:seanp...@chromium.org]
> Sent: Tuesday, July 10, 2018 1:51 AM
> To: C, Ramalingam
> Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
> dan...@ffwll.ch; Winkler, Tomas ; Usyskin,
> Alexande
> -Original Message-
> From: Sean Paul [mailto:seanp...@chromium.org]
> Sent: Tuesday, July 10, 2018 1:53 AM
> To: C, Ramalingam
> Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
> dan...@ffwll.ch; Winkler, Tomas ; Usyskin,
> Alexander ; Shankar, Uma
>
> Subject: Re
On 7/9/2018 6:19 AM, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Now that we scale timestamps to get better timeline granularity, the hacky
hand rolled micro-second time to HTML date conversion does no longer cut
it.
Use perl built-in gmtime to handle things properly.
Signed-off-by: Tvrtko Urs
> -Original Message-
> From: Sean Paul [mailto:seanp...@chromium.org]
> Sent: Tuesday, July 10, 2018 2:00 AM
> To: C, Ramalingam
> Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org;
> dan...@ffwll.ch; Winkler, Tomas ; Usyskin,
> Alexander ; Shankar, Uma
>
> Subject: Re
Hi Rodrigo,
It's probably a bug fix that unveils the link errors.
tree: git://anongit.freedesktop.org/drm/drm-tip drm-tip
head: 02e578b7aace48d33fa617dddb40621bd664c92c
commit: dde6f6606700e68d82f0452d9a9a3b78dff1068f [8/9] Merge remote-tracking
branch 'drm-intel/topic/core-for-CI' into drm-
On 7/11/18 10:45 AM, Tejun Heo wrote:
> On Wed, Jul 11, 2018 at 09:40:58AM -0700, Tejun Heo wrote:
>> On Mon, Jul 09, 2018 at 10:36:40AM +0200, Daniel Vetter wrote:
>>> Makes the macros resilient against if {} else {} blocks right
>>> afterwards.
>>>
>>> Signed-off-by: Daniel Vetter
>>> Cc: Tejun
1 - 100 of 155 matches
Mail list logo
