On Wed, Jul 11, 2018 at 10:49:51AM +0100, Chris Wilson wrote:
> 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
On Thu, Jul 12, 2018 at 12:09:01AM -0700, Dhinakaran Pandiyan wrote:
> On Wed, 2018-07-11 at 23:17 -0700, Rodrigo Vivi wrote:
> > On Wed, Jul 11, 2018 at 11:08:17PM -0700, Dhinakaran Pandiyan wrote:
> > >
> > > On Wed, 2018-07-11 at 22:27 -0700, Rodrigo Vivi wrote:
> > > >
> > > > Reduce the modu
On Wed, Jul 11, 2018 at 12:12:39PM +0100, Chris Wilson wrote:
> 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,
On Wed, Jul 11, 2018 at 10:40:56AM +0800, Zhenyu Wang wrote:
>
> Hi,
>
> Here's one gvt fix for KBL vGPU hang to update virtual register from LRI.
Pulled.
Not sure yet if I'm doing another pull this week or next week for the fixes.
Thanks,
Rodrigo.
>
> Thanks.
> --
> The following changes si
Before running a hang test, check if we can inject a hang and expect
recover to work. If we can't control a hang, skip the subtest.
Signed-off-by: Chris Wilson
---
tests/kms_vblank.c | 4
1 file changed, 4 insertions(+)
diff --git a/tests/kms_vblank.c b/tests/kms_vblank.c
index 2bee49de5..
On Wed, Jul 11, 2018 at 10:33:53AM +0800, Zhenyu Wang wrote:
>
> 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.
Pulled to dinq.
Thanks,
Rodrigo.
>
> Thanks.
> --
> The following changes s
On Thu, Jul 12, 2018 at 8:56 AM, Takashi Iwai wrote:
> On Thu, 12 Jul 2018 08:54:34 +0200,
> Daniel Vetter wrote:
>>
>> On Thu, Jul 12, 2018 at 09:29:01AM +0800, Feng Tang wrote:
>> > On Tue, Jun 26, 2018 at 10:29:16AM +0800, Feng Tang wrote:
>> > > On Mon, Jun 25, 2018 at 05:36:32PM +0200, Daniel
Quoting Dominique Martinet (2018-07-12 00:24:46)
> Change it to use strlcpy instead
>
> Signed-off-by: Dominique Martinet
Reviewed-by: Chris Wilson
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/
RPS provides a feedback loop where we use the load during the previous
evaluation interval to decide whether to up or down clock the GPU
frequency. Our responsiveness is split into 3 regimes, a high and low
plateau with the intent to keep the gpu clocked high to cover occasional
stalls under high l
RPS provides a feedback loop where we use the load during the previous
evaluation interval to decide whether to up or down clock the GPU
frequency. Our responsiveness is split into 3 regimes, a high and low
plateau with the intent to keep the gpu clocked high to cover occasional
stalls under high l
From: Dominique Martinet
Change it to use strlcpy instead
Signed-off-by: Dominique Martinet
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_tv.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
ind
Hi Daniel,
On Thu, Jul 12, 2018 at 08:54:34AM +0200, Daniel Vetter wrote:
> On Thu, Jul 12, 2018 at 09:29:01AM +0800, Feng Tang wrote:
> > On Tue, Jun 26, 2018 at 10:29:16AM +0800, Feng Tang wrote:
> > > On Mon, Jun 25, 2018 at 05:36:32PM +0200, Daniel Vetter wrote:
> >
> > > Hi Daneil/Jani/Taka
RPS provides a feedback loop where we use the load during the previous
evaluation interval to decide whether to up or down clock the GPU
frequency. Our responsiveness is split into 3 regimes, a high and low
plateau with the intent to keep the gpu clocked high to cover occasional
stalls under high l
On Thu, Jul 12, 2018 at 09:37:41AM +0200, Daniel Vetter wrote:
> On Thu, Jul 12, 2018 at 8:56 AM, Takashi Iwai wrote:
> > On Thu, 12 Jul 2018 08:54:34 +0200,
> > Daniel Vetter wrote:
> >>
> >> On Thu, Jul 12, 2018 at 09:29:01AM +0800, Feng Tang wrote:
> >> > On Tue, Jun 26, 2018 at 10:29:16AM +080
RPS provides a feedback loop where we use the load during the previous
evaluation interval to decide whether to up or down clock the GPU
frequency. Our responsiveness is split into 3 regimes, a high and low
plateau with the intent to keep the gpu clocked high to cover occasional
stalls under high l
== Series Details ==
Series: drm/i915: Interactive RPS mode (rev3)
URL : https://patchwork.freedesktop.org/series/46334/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
d9b851d1738d drm/i915: Interactive RPS mode
-:24: ERROR:GIT_COMMIT_ID: Please use git commit description style
== Series Details ==
Series: drm/i915: Interactive RPS mode (rev3)
URL : https://patchwork.freedesktop.org/series/46334/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: drm/i915: Interactive RPS mode
-drivers/gpu/drm/i915/selftests/../i915_drv.h:3652:16: warning: expression
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.c | 5 +
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_runtime_pm.c | 3 +++
3 files changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index
On Wed, Jul 11, 2018 at 07:41:26PM +0530, Ramalingam C wrote:
> 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,
On Wed, Jul 11, 2018 at 07:41:27PM +0530, Ramalingam C wrote:
> 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 mas
Quoting Chris Wilson (2018-07-12 09:20:37)
It needs to be equally on runtime_pm_get.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
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 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 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
== Series Details ==
Series: drm/i915: Interactive RPS mode (rev3)
URL : https://patchwork.freedesktop.org/series/46334/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4474 -> Patchwork_9622 =
== Summary - FAILURE ==
Serious unknown changes coming with Patchwork_9622 abso
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 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 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 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
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.c | 5 +
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_runtime_pm.c | 11 +++
3 files changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915
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/
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:
On Thu, Jul 12, 2018 at 09:33:32AM +0100, Chris Wilson wrote:
> Quoting Chris Wilson (2018-07-12 09:20:37)
>
> It needs to be equally on runtime_pm_get.
Just wanted to complain about "what if we know there's someone holding an
rpm ref already?", but then remembered that this is what we have the
_
Quoting Chris Wilson (2018-07-12 09:36:33)
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/i915_drv.c | 5 +
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> drivers/gpu/drm/i915/intel_runtime_pm.c | 11 +++
> 3 files changed, 17 insertions(+)
>
> diff --git a/
On Thursday 12 July 2018 01:51 PM, Daniel Vetter wrote:
On Wed, Jul 11, 2018 at 07:41:26PM +0530, Ramalingam C wrote:
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
co
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
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 Thursday 12 July 2018 01:56 PM, Daniel Vetter wrote:
On Wed, Jul 11, 2018 at 07:41:27PM +0530, Ramalingam C wrote:
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:
- mov
== Series Details ==
Series: i915: make the probe asynchronous (rev4)
URL : https://patchwork.freedesktop.org/series/44159/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
9a02b4dfc2e6 i915: make the probe asynchronous
-:17: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit
== Series Details ==
Series: drm/i915/tv: fix strncpy truncation warning
URL : https://patchwork.freedesktop.org/series/46360/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4474 -> Patchwork_9623 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://p
Quoting Dominique Martinet (2018-07-12 00:24:46)
> Change it to use strlcpy instead
>
> Signed-off-by: Dominique Martinet
Thanks for the spotting the issue and providing a fix, pushed.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
h
== Series Details ==
Series: i915: make the probe asynchronous (rev4)
URL : https://patchwork.freedesktop.org/series/44159/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4474 -> Patchwork_9624 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patc
== Series Details ==
Series: Improve crc-core driver interface (rev6)
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 (rev6)
URL : https://patchwork.freedesktop.org/series/45246/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4474 -> Patchwork_9625 =
== Summary - FAILURE ==
Serious unknown changes coming with Patchwork_9625 a
== Series Details ==
Series: RFC drm/i915: Mark runtime_pm as a special class of lock (rev2)
URL : https://patchwork.freedesktop.org/series/46366/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Commit: RFC drm/i915: Mark runtime_pm as a special class of lock
-drivers/gpu/drm/i915/se
== Series Details ==
Series: RFC drm/i915: Mark runtime_pm as a special class of lock (rev2)
URL : https://patchwork.freedesktop.org/series/46366/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4475 -> Patchwork_9626 =
== Summary - SUCCESS ==
No regressions found.
Exte
Quoting Patchwork (2018-07-12 11:12:25)
> == Series Details ==
>
> Series: RFC drm/i915: Mark runtime_pm as a special class of lock (rev2)
> URL : https://patchwork.freedesktop.org/series/46366/
> State : success
>
> == Summary ==
>
> = CI Bug Log - changes from CI_DRM_4475 -> Patchwork_9626 =
Along a module load error path, we may try to cleanup the powercontext
even before we have allocated it. Reorganising GT powermanagement is an
on going process, so for simplicity handle it.
[ 522.733832] WARN_ON(!dev_priv->vlv_pctx)
[ 522.733986] WARNING: CPU: 1 PID: 3856 at
drivers/gpu/drm/i
If we fail the module load, we may try and cleanup before we even
allocate the GuC clients. KISS in order to try and re-enable
drv_module_reload for BAT.
Testcase: igt/drv_module_reload/basic-reload-inject
Signed-off-by: Chris Wilson
Cc: Michał Winiarski
Cc: Michal Wajdeczko
---
drivers/gpu/dr
On 12 July 2018 at 11:54, Chris Wilson wrote:
> Along a module load error path, we may try to cleanup the powercontext
> even before we have allocated it. Reorganising GT powermanagement is an
> on going process, so for simplicity handle it.
>
> [ 522.733832] WARN_ON(!dev_priv->vlv_pctx)
> [ 5
From: Tvrtko Ursulin
Latest state of patches preceding the virtual engine support.
John Harrison (1):
trace.pl: Improved key/colours
Tvrtko Ursulin (8):
trace.pl: Improve time axis labels
trace.pl: Scale timeline for better precision
trace.pl: Improve readability of graphical timeline r
From: John Harrison
Improve the timeline legend to show actual context colours.
v2: (Tvrtko Ursulin)
* Commit msg.
* Tweak layout for more compactness and more readability.
Signed-off-by: Tvrtko Ursulin
Cc: John Harrison
Cc: Tvrtko Ursulin
---
scripts/trace.pl | 69 +++
From: Tvrtko Ursulin
We add stripes for different stages of request execution so it is easier
to follow one context in the multi-colour mode.
Vertical stripe pattern indicates pipeline "blockages" - requests waiting
for dependencies before they are runnable.
Diagonal stripes indicate runnable r
From: Tvrtko Ursulin
Just forget about earlier request_in events.
Signed-off-by: Tvrtko Ursulin
---
scripts/trace.pl | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/scripts/trace.pl b/scripts/trace.pl
index 33045f3264f2..43c68001d768 100755
--- a/scripts/trace.pl
+++ b/s
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.
v2: Rebase for time axis changes.
Signed-off-by: Tvrtko Ursulin
Suggested-by: John Harr
From: Tvrtko Ursulin
It is possible to customize the axis display so change it to display
timestamps in seconds on the major axis (with six decimal spaces) and
relative millisecond offsets on the minor axis.
Signed-off-by: Tvrtko Ursulin
Suggested-by: Chris Wilson
Cc: Chris Wilson
Cc: John Ha
From: Tvrtko Ursulin
Request split mode had several bugs, both in the original version and also
after the recent refactorings.
One big one was that it wasn't considering different submit ports as a
reason to split execution, and also that it was too time based instead of
looking at relevant time
From: Tvrtko Ursulin
Skip accounting the context save time for anything but the last request of
the coalesced bunch, and also skip drawing those boxes on the timeline.
Signed-off-by: Tvrtko Ursulin
---
scripts/trace.pl | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --gi
From: Tvrtko Ursulin
John reports that on a long runnning systems the huge disparity between
kernel context and user context id's causes all interesting colours to be
clustered too close together.
Fix this by assigning colours to seen contexts instead of basing purely
on context id's.
Signed-of
From: Tvrtko Ursulin
Incomplete requests (no notify, no context complete) have to be corrected
by looking at the engine timeline, and not the sorted-by-start-time view
as was previously used.
Per-engine timelines are generated on demand and cached for later use.
v2: Find end of current context
On 12/07/2018 11:59, Tvrtko Ursulin wrote:
From: John Harrison
Improve the timeline legend to show actual context colours.
v2: (Tvrtko Ursulin)
* Commit msg.
* Tweak layout for more compactness and more readability.
Signed-off-by: Tvrtko Ursulin
I've picked up this patch of yours and
Hi Mahesh,
Thank you for the patch.
On Thursday, 12 July 2018 11:36:26 EEST Mahesh Kumar wrote:
> 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.
>
> C
Hi Mahesh,
Thank you for the patches.
When resubmitting patch series, could you please add a version number to the
[PATCH] prefix ? Otherwise it gets difficult to figure out which version is
the latest. This can be done automatically with the -v argument to git-format-
patch.
On Thursday, 12 J
From: Michał Winiarski
Since:
0d4b78b3d2c0 ("drm/i915/guc: Assert we have the doorbell before setting it up")
We have asserts in GuC doorbell related functions, which is a good thing.
Unfortunately, we were using those to check whether GuC FW is refusing
to allocate invalid doorbell - which make
Hi Mahesh,
Thank you for the patch.
On Thursday, 12 July 2018 11:36:27 EEST Mahesh Kumar wrote:
> 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
> s
Hi Mahesh,
Thank you for the patch.
On Thursday, 12 July 2018 11:36:30 EEST Mahesh Kumar wrote:
> 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.freede
Hi Mahesh,
Thank you for the patch.
On Thursday, 12 July 2018 11:36:33 EEST Mahesh Kumar wrote:
> 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
Hi Mahesh,
Thank you for the patch.
On Thursday, 12 July 2018 11:36:35 EEST Mahesh Kumar wrote:
> 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
> ---
>
We require that we keep the list of outstanding work short so that we do
not "leak" memory while pageflipping under stress. However that system
stress may delay kernel workers virtually indefinitely, which incurs the
pageflips stall and eventually hit a timeout waiting for the cleanup.
Try to comb
== Series Details ==
Series: drm/i915: Silence warning for no vlv powercontext
URL : https://patchwork.freedesktop.org/series/46380/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4475 -> Patchwork_9627 =
== Summary - SUCCESS ==
No regressions found.
External URL:
htt
On Wed, 04 Jul 2018, Neil Armstrong wrote:
> Hi All,
>
> The new Google "Fizz" Intel-based ChromeOS device is gaining CEC support
> through it's Embedded Controller, to enable the Linux CEC Core to communicate
> with it and get the CEC Physical Address from the correct HDMI Connector, the
> follo
On Wed, 04 Jul 2018, Neil Armstrong wrote:
> Having a 16 byte mkbp event size makes it possible to send CEC
> messages from the EC to the AP directly inside the mkbp event
> instead of first doing a notification and then a read.
>
> Signed-off-by: Stefan Adolfsson
> Signed-off-by: Neil Armstrong
On 12/07/2018 11:59, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
It is possible to customize the axis display so change it to display
timestamps in seconds on the major axis (with six decimal spaces) and
relative millisecond offsets on the minor axis.
Signed-off-by: Tvrtko Ursulin
Suggested-b
Hi Lee,
On 12/07/2018 14:26, Lee Jones wrote:
> On Wed, 04 Jul 2018, Neil Armstrong wrote:
>
>> Hi All,
>>
>> The new Google "Fizz" Intel-based ChromeOS device is gaining CEC support
>> through it's Embedded Controller, to enable the Linux CEC Core to communicate
>> with it and get the CEC Physic
On Wed, Jul 11, 2018 at 09:46:15AM +0200, Dominique Martinet wrote:
> This is effectively no-op as the next line writes a nul at the final
What is "This". Please write self contained commit messages.
> byte of the buffer, so copying one letter less does not change the
> behaviour.
>
> Signed-off
There's nothing there. Last vfunc got removed along with gen8 legacy
ringbuffer submission.
Signed-off-by: Michał Winiarski
Cc: Chris Wilson
---
drivers/gpu/drm/i915/intel_lrc.c| 3 ---
drivers/gpu/drm/i915/intel_ringbuffer.c | 3 ---
drivers/gpu/drm/i915/intel_ringbuffer.h | 1 -
3 fil
== Series Details ==
Series: drm/i915/guc: Skip cleaning up the doorbells on error-before-allocate
URL : https://patchwork.freedesktop.org/series/46382/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4475 -> Patchwork_9628 =
== Summary - SUCCESS ==
No regressions found.
Let's reorder things so that we can do onion teardown rather than double
goto.
References: b96f6ebfd024 ("drm/i915: Correctly handle error path in
i915_gem_init_hw")
Signed-off-by: Michał Winiarski
Cc: Michal Wajdeczko
Cc: Sagar Arun Kamble
---
drivers/gpu/drm/i915/i915_gem.c | 10 +++---
== Series Details ==
Series: drm/i915/selftests: Fixup GuC FW negative test
URL : https://patchwork.freedesktop.org/series/46388/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
f9b5ed208b2f drm/i915/selftests: Fixup GuC FW negative test
-:10: WARNING:COMMIT_LOG_LONG_LINE: Possib
Quoting Michał Winiarski (2018-07-12 13:44:15)
> There's nothing there. Last vfunc got removed along with gen8 legacy
> ringbuffer submission.
Honestly it's gt.cleanup_engine that is the unwanted vfunc.
engine->cleanup is the right layer, esp as we do not plan to have a single
class of engine in t
On Thu, Jul 12, 2018 at 09:41:07AM +0100, Chris Wilson wrote:
> Quoting Chris Wilson (2018-07-12 09:36:33)
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/i915/i915_drv.c | 5 +
> > drivers/gpu/drm/i915/i915_drv.h | 1 +
> > drivers/gpu/drm/i915/intel_runtime_pm.
Quoting Michał Winiarski (2018-07-12 13:48:10)
> Let's reorder things so that we can do onion teardown rather than double
> goto.
>
> References: b96f6ebfd024 ("drm/i915: Correctly handle error path in
> i915_gem_init_hw")
> Signed-off-by: Michał Winiarski
> Cc: Michal Wajdeczko
> Cc: Sagar Aru
On 12/07/18 14:42, Neil Armstrong wrote:
> Hi Lee,
>
> On 12/07/2018 14:26, Lee Jones wrote:
>> On Wed, 04 Jul 2018, Neil Armstrong wrote:
>>
>>> Hi All,
>>>
>>> The new Google "Fizz" Intel-based ChromeOS device is gaining CEC support
>>> through it's Embedded Controller, to enable the Linux CEC C
== Series Details ==
Series: drm/i915/selftests: Fixup GuC FW negative test
URL : https://patchwork.freedesktop.org/series/46388/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4475 -> Patchwork_9629 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https:
On Thu, Jul 12, 2018 at 11:58:30AM +0100, Chris Wilson wrote:
> If we fail the module load, we may try and cleanup before we even
> allocate the GuC clients. KISS in order to try and re-enable
> drv_module_reload for BAT.
>
> Testcase: igt/drv_module_reload/basic-reload-inject
> Signed-off-by: Chr
== Series Details ==
Series: drm/i915: Bump priority of clean up work
URL : https://patchwork.freedesktop.org/series/46390/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4475 -> Patchwork_9630 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patc
== Series Details ==
Series: drm/i915: Remove unused engine->cleanup
URL : https://patchwork.freedesktop.org/series/46392/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4475 -> Patchwork_9631 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patch
== Series Details ==
Series: drm/i915: Tidy error handling in i915_gem_init_hw
URL : https://patchwork.freedesktop.org/series/46393/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
5a23ed1e4a1a drm/i915: Tidy error handling in i915_gem_init_hw
-:12: WARNING:COMMIT_LOG_LONG_LINE:
On 7/12/18 12:45 AM, Joe Perches wrote:
> On Wed, 2018-07-11 at 20:50 +0200, Daniel Vetter wrote:
>> On Wed, Jul 11, 2018 at 8:30 PM, Jens Axboe wrote:
>>> 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
== Series Details ==
Series: drm/i915: Tidy error handling in i915_gem_init_hw
URL : https://patchwork.freedesktop.org/series/46393/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4475 -> Patchwork_9632 =
== Summary - SUCCESS ==
No regressions found.
External URL:
htt
Some functions used within mock selftests may expect platform-dependent
automatic modparams parameters to have already been resolved, resulting
in failed assertions.
Backing up the modparams before mock selftests and manually setting
offending parameters inside the affected selftests should fix the
From: Michal Wajdeczko
Signed-off-by: Michal Wajdeczko
---
drivers/gpu/drm/i915/i915_params.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_params.h
b/drivers/gpu/drm/i915/i915_params.h
index aebe0469ddaa..3e4e128237ac 100644
--- a/drivers/gpu/dr
On Thu, Jul 12, 2018 at 03:55:26PM +0200, Dominique Martinet wrote:
> Ville Syrjälä wrote on Thu, Jul 12, 2018:
> > On Wed, Jul 11, 2018 at 09:46:15AM +0200, Dominique Martinet wrote:
> > > This is effectively no-op as the next line writes a nul at the final
> >
> > What is "This". Please write se
Quoting Chris Wilson (2018-07-12 12:20:13)
> From: Michał Winiarski
>
> Since:
> 0d4b78b3d2c0 ("drm/i915/guc: Assert we have the doorbell before setting it
> up")
>
> We have asserts in GuC doorbell related functions, which is a good thing.
> Unfortunately, we were using those to check whether
Quoting Jakub Bartmiński (2018-07-12 15:07:18)
> Some functions used within mock selftests may expect platform-dependent
> automatic modparams parameters to have already been resolved, resulting
> in failed assertions.
> Backing up the modparams before mock selftests and manually setting
> offendin
On Tuesday 10 July 2018 02:14 AM, Sean Paul wrote:
On Wed, Jun 27, 2018 at 02:10:00PM +0530, Ramalingam C wrote:
Considering that HDCP2.2 is more secure than HDCP1.4, When a setup
supports HDCP2.2 and HDCP1.4, HDCP2.2 will be enabled.
v2:
Included few optimization suggestions [Chris Wilson
On Tuesday 10 July 2018 02:14 AM, Sean Paul wrote:
On Wed, Jun 27, 2018 at 02:10:01PM +0530, Ramalingam C wrote:
When HDCP2.2 enabling fails and HDCP1.4 is supported, HDCP1.4 is
enabled.
Just squash this into patch 11, no need for a separate patch.
Doing it in the next version of the series
Quoting Michał Winiarski (2018-07-12 13:48:10)
> Let's reorder things so that we can do onion teardown rather than double
> goto.
>
> References: b96f6ebfd024 ("drm/i915: Correctly handle error path in
> i915_gem_init_hw")
> Signed-off-by: Michał Winiarski
> Cc: Michal Wajdeczko
> Cc: Sagar Aru
1 - 100 of 180 matches
Mail list logo
