On Tue, Mar 28, 2017 at 12:10:37PM -0400, Alex Deucher wrote:
> On Tue, Mar 28, 2017 at 11:53 AM, Daniel Vetter
> wrote:
> > Mostly because I want the links from the newly-added @state functions
> > to work. But I think explaining when they're useful and that the
> > implicit one is deprecated is
== Series Details ==
Series: drm/i915/gvt: fix error return check for copy_gma_to_hva()
URL : https://patchwork.freedesktop.org/series/22049/
State : success
== Summary ==
Series 22049v1 drm/i915/gvt: fix error return check for copy_gma_to_hva()
https://patchwork.freedesktop.org/api/1.0/series
From commit 73dec95e6ba3 ("drm/i915: Emit to ringbuffer directly"),
copy_gma_to_hva() now returns copied data length instead of 0, so
need to change error return check for that.
Note: Looks this is caused by backmerge conflict resolving, so
4.11-rc4 is not impacted as commit 73dec95e6ba3 ("drm/i91
On Tue, 2017-03-28 at 17:01 -0700, Vivi, Rodrigo wrote:
> On Tue, 2017-03-28 at 22:11 +, Srivatsa, Anusha wrote:
> >
> >
> > >
> > > -Original Message-
> > > From: Spotswood, John A
> > > Sent: Tuesday, March 28, 2017 2:35 PM
> > > To: Srivatsa, Anusha ; intel-
> > > g...@lists.freed
Pushed.
On 2017-03-28 07:39 PM, Jordan Justen wrote:
Reviewed-by: Jordan Justen
On 2017-03-28 16:22:22, Robert Foss wrote:
The binary tools/intel_bios_reader was accidentally included
in 3e04c5197ff965a8cd050f9c3b5213abcf437a31.
This commit removes it again.
Signed-off-by: Robert Foss
___
== Series Details ==
Series: drm/i915/guc: Take enable_guc_loading check out of GEM core code
URL : https://patchwork.freedesktop.org/series/22041/
State : success
== Summary ==
Series 22041v1 drm/i915/guc: Take enable_guc_loading check out of GEM core code
https://patchwork.freedesktop.org/ap
On Tue, 2017-03-28 at 22:11 +, Srivatsa, Anusha wrote:
>
> >-Original Message-
> >From: Spotswood, John A
> >Sent: Tuesday, March 28, 2017 2:35 PM
> >To: Srivatsa, Anusha ; intel-
> >g...@lists.freedesktop.org
> >Cc: Mcgee, Jeff ; Vivi, Rodrigo
> >
> >Subject: Re: [PATCH 1/2] drm/i915
I wanted to get this out of the way as soon as possible, but I'll follow
shortly with a proposal to remove enable_guc_loading as a module parameter.
Thanks,
Oscar
On 03/28/2017 09:53 AM, Oscar Mateo wrote:
The should happen as soon as possible, but always within the logic that
depends on it
The should happen as soon as possible, but always within the logic that
depends on it (and not interrupting the top-level driver control flow).
Cc: Chris Wilson
Cc: Joonas Lahtinen
Signed-off-by: Oscar Mateo
---
drivers/gpu/drm/i915/i915_drv.c | 3 +--
drivers/gpu/drm/i915/i915_gem.c | 10 +++
On 2017-03-28 15:19:51, Robert Foss wrote:
> Hi,
>
> On 2017-03-28 06:06 PM, Jordan Justen wrote:
> > Robert,
> >
> > I think this patch got committed (with a slight change) in
> > 3e04c5197ff965a8cd050f9c3b5213abcf437a31.
> >
> > Unfortunately, I think that commit inadvertently included a binary
Hi,
On 2017-03-28 06:06 PM, Jordan Justen wrote:
Robert,
I think this patch got committed (with a slight change) in
3e04c5197ff965a8cd050f9c3b5213abcf437a31.
Unfortunately, I think that commit inadvertently included a binary
file 'tools/intel_bios_reader' as well. Can you remove this file?
T
>-Original Message-
>From: Spotswood, John A
>Sent: Tuesday, March 28, 2017 2:35 PM
>To: Srivatsa, Anusha ; intel-
>g...@lists.freedesktop.org
>Cc: Mcgee, Jeff ; Vivi, Rodrigo
>Subject: Re: [PATCH 1/2] drm/i915/GuC/GLK: Load GuC on GLK
>
>On Tue, 2017-03-21 at 14:09 -0700, Anusha Srivats
Robert,
I think this patch got committed (with a slight change) in
3e04c5197ff965a8cd050f9c3b5213abcf437a31.
Unfortunately, I think that commit inadvertently included a binary
file 'tools/intel_bios_reader' as well. Can you remove this file?
Thanks,
-Jordan
On 2017-01-30 06:12:17, Robert Foss
Why not squash this with patch 08/14? and call it cleanup for obtaining the
rate index using intel_dp_rate_index()
Just a thought..
Regards
Manasi
On Tue, Mar 28, 2017 at 05:59:12PM +0300, Jani Nikula wrote:
> Localize link_rate_index to the if block, and rename to just index to
> reduce indent.
On Tue, Mar 28, 2017 at 05:59:11PM +0300, Jani Nikula wrote:
> The source might not support as many lanes as the sink, or the link
> training might have failed at higher lane counts. Take these into
> account.
>
Yes that is true for link fallback to work correctly for MST.
So Reviewed-by: Manasi N
On Tue, Mar 28, 2017 at 08:00:27PM +0200, Michał Winiarski wrote:
> Normally when we're inserting requests with equal priority, we're using
> FIFO ordering. However, when we're resubmitting requests it's helpful
> to be able to ensure that they're executed before their dependencies,
> meaning that
On Tue, Mar 28, 2017 at 05:59:10PM +0300, Jani Nikula wrote:
> These are the theoretical maximums common for source and sink. These are
> the maximums we should start with. They may be degraded in case of link
> training failures, and the dynamic link values are stored separately.
>
> Cc: Manasi N
On Tue, 2017-03-21 at 14:09 -0700, Anusha Srivatsa wrote:
> Load GuC 10.56 on GLK. Work on firmware is still
> in progress. Testing has not been done yet.
> This patch addresses the initial need to load the GuC
> firmware for HuC authentication
>
> Cc: Jeff mcgee
> Cc: Rodrigo Vivi
> Cc: John Sp
On Tue, 2017-03-21 at 17:29 -0700, Anusha Srivatsa wrote:
> Load HuC version 1.07.1748 on GLK.
>
> v2: rebased.
> v3: Use name of the right platform(John Spotswood)
>
> Cc: Jeff Mcgee
> Cc: John Spotswood
> Cc: Rodrigo Vivi
> Signed-off-by: Anusha Srivatsa
> ---
> drivers/gpu/drm/i915/intel_
I agree this definitely minimizes the confusion! Thanks for this patch.
Regards
Manasi
On Tue, Mar 28, 2017 at 05:59:09PM +0300, Jani Nikula wrote:
> If we modify these on the fly depending on the link conditions, don't
> pretend they are sink properties.
>
> Some link vs. sink confusion still r
On Tue, Mar 28, 2017 at 05:59:08PM +0300, Jani Nikula wrote:
> In link training fallback, we're trying to find a rate that we know is
> in a sorted array of common link rates. We don't need to limit the array
> using the max rate. For test request, the DP CTS doesn't say we should
> limit the rate
== Series Details ==
Series: drm/i915: Make legacy cursor updates more unsynced
URL : https://patchwork.freedesktop.org/series/22031/
State : warning
== Summary ==
Series 22031v1 drm/i915: Make legacy cursor updates more unsynced
https://patchwork.freedesktop.org/api/1.0/series/22031/revisions
On Tue, Mar 28, 2017 at 08:00:29PM +0200, Michał Winiarski wrote:
> Now that we're only driving GuC submissions from the tasklet, we can
> simply skip the submission if GuC wq is full. This allows us to
> completely remove reservation from the request_alloc path, and only
> use it to manage wq betw
On Tue, Mar 28, 2017 at 08:00:28PM +0200, Michał Winiarski wrote:
> Now that we're able to unsubmit requests, we can take advantage of it
> during reset. Rather than resubmitting the previous workload directly to
> GuC/ELSP, we can simply move the requests back to priority queue,
> submitting from
On Tue, Mar 28, 2017 at 08:00:27PM +0200, Michał Winiarski wrote:
> Normally when we're inserting requests with equal priority, we're using
> FIFO ordering. However, when we're resubmitting requests it's helpful
> to be able to ensure that they're executed before their dependencies,
> meaning that
On Tue, Mar 28, 2017 at 08:00:26PM +0200, Michał Winiarski wrote:
> Since request can be unsubmitted, we need to avoid overriding its priority
> during submission. Otherwise we won't be able to resubmit it with
> correct priority.
>
> Cc: Chris Wilson
> Cc: Joonas Lahtinen
> Cc: Tvrtko Ursulin
From: Ville Syrjälä
We're clearing the legacy_cursor_update flag before calling
drm_atomic_helper_setup_commit() which means the helper will
wait for the flip to complete before cleaning up the framebuffers.
That's not what we want for the legacy cursor, so let's clear
the flag after setting up t
Won't it make more sense to squash this patch with Patch 01 in this series?
When i was reading Patch 1, I almost was going to comment about
handling the case where we dont find the index..
Regards
Manasi
On Tue, Mar 28, 2017 at 05:59:02PM +0300, Jani Nikula wrote:
> We shouldn't silently use the
== Series Details ==
Series: series starting with [RFC,1/4] drm/i915/scheduler: Remember request
priority throughout its lifetime
URL : https://patchwork.freedesktop.org/series/22030/
State : failure
== Summary ==
Series 22030v1 Series without cover letter
https://patchwork.freedesktop.org/ap
Now that we're only driving GuC submissions from the tasklet, we can
simply skip the submission if GuC wq is full. This allows us to
completely remove reservation from the request_alloc path, and only
use it to manage wq between tasklets belonging to different engines.
Cc: Arkadiusz Hiler
Cc: Chr
Now that we're able to unsubmit requests, we can take advantage of it
during reset. Rather than resubmitting the previous workload directly to
GuC/ELSP, we can simply move the requests back to priority queue,
submitting from the tasklet instead.
Cc: Chris Wilson
Cc: Michel Thierry
Cc: Mika Kuopp
Since request can be unsubmitted, we need to avoid overriding its priority
during submission. Otherwise we won't be able to resubmit it with
correct priority.
Cc: Chris Wilson
Cc: Joonas Lahtinen
Cc: Tvrtko Ursulin
Signed-off-by: Michał Winiarski
---
drivers/gpu/drm/i915/i915_guc_submission.c
Normally when we're inserting requests with equal priority, we're using
FIFO ordering. However, when we're resubmitting requests it's helpful
to be able to ensure that they're executed before their dependencies,
meaning that we need to use LIFO ordering instead.
Cc: Chris Wilson
Cc: Joonas Lahtin
== Series Details ==
Series: series starting with [1/3] drm/doc: remove standard connector props
from the csv file
URL : https://patchwork.freedesktop.org/series/22023/
State : failure
== Summary ==
Series 22023v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/22
== Series Details ==
Series: drm/i915: Prefer to reschedule the free_object worker rather than block
URL : https://patchwork.freedesktop.org/series/22020/
State : failure
== Summary ==
Series 22020v1 drm/i915: Prefer to reschedule the free_object worker rather
than block
https://patchwork.fre
== Series Details ==
Series: drm/i915/dp: link rate and lane count refactoring (rev3)
URL : https://patchwork.freedesktop.org/series/18359/
State : success
== Summary ==
Series 18359v3 drm/i915/dp: link rate and lane count refactoring
https://patchwork.freedesktop.org/api/1.0/series/18359/revi
Patches 1-3 are Reviewed-by: Harry Wentland
Harry
On 2017-03-28 11:53 AM, Daniel Vetter wrote:
Mostly because I want the links from the newly-added @state functions
to work. But I think explaining when they're useful and that the
implicit one is deprecated is good either way. Slightly repetiti
>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Michal Wajdeczko
>Sent: Tuesday, March 28, 2017 5:51 AM
>To: Joonas Lahtinen
>Cc: intel-gfx@lists.freedesktop.org
>Subject: Re: [Intel-gfx] [PATCH 1/5] drm/i915/uc: Move
>intel_uc_fw_stat
On Tue, Mar 28, 2017 at 11:53 AM, Daniel Vetter wrote:
> Mostly because I want the links from the newly-added @state functions
> to work. But I think explaining when they're useful and that the
> implicit one is deprecated is good either way. Slightly repetitive
> unfortunately.
>
> Cc: Harry Went
Mostly because I want the links from the newly-added @state functions
to work. But I think explaining when they're useful and that the
implicit one is deprecated is good either way. Slightly repetitive
unfortunately.
Cc: Harry Wentland
Cc: Maarten Lankhorst
Signed-off-by: Daniel Vetter
---
inc
The rules are getting real hard, better to dump my brain into text a
bit. This is by far not complete, but I think I reasonable start at
least.
Some of the older kms structures would need a full doc review anyway
...
Cc: Harry Wentland
Reviewed-by: Harry Wentland
Cc: Maarten Lankhorst
Signed-o
They're properly documented in drm_connector.c now, and this
csv file is a horrible mess. Better to remove it.
Signed-off-by: Daniel Vetter
---
Documentation/gpu/kms-properties.csv | 5 -
1 file changed, 5 deletions(-)
diff --git a/Documentation/gpu/kms-properties.csv
b/Documentation/gpu/k
Jani,
Should I just hold on to this until your patch series
gets merged so I can rebase this on top of it?
Regards
Manasi
On Mon, Mar 27, 2017 at 02:44:50PM -0700, Manasi Navare wrote:
> Currently intel_dp_check_link_status() tries to retrain the link if
> Clock recovery or Channel EQ for any o
On Tue, Mar 28, 2017 at 10:34:42AM +0300, Jani Nikula wrote:
> On Mon, 27 Mar 2017, Manasi Navare wrote:
> > Hmm, yes but if you want I can work on rebasing it after these two patches
> > land. That series is really required.
>
> I can do the rebasing, I'll just need the review from you. ;)
>
Ye
On Mon, 27 Mar 2017, Clint Taylor wrote:
> On 03/27/2017 08:22 AM, Jani Nikula wrote:
>> On Mon, 27 Mar 2017, Daniel Vetter wrote:
>>> On Mon, Mar 27, 2017 at 02:33:25PM +0300, Jani Nikula wrote:
Several major vendor USB-C->HDMI converters, in particular the DA200,
fail to recover a 5.4
Avoid blocking the kworker by putting back the freed object list if we
cannot immediately take the mutex. We will try again shortly, and flush
the work when desperate.
References: https://bugs.freedesktop.org/show_bug.cgi?id=100434
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c
On 2017-03-28 03:02 AM, Daniel Vetter wrote:
On Tue, Mar 28, 2017 at 08:23:53AM +0200, Daniel Vetter wrote:
On Mon, Mar 27, 2017 at 04:12:05PM -0400, Harry Wentland wrote:
On Wednesday, March 22, 2017 10:50:40 PM EDT Daniel Vetter wrote:
This is just prep work to get an acquire ctx into ever
On Tue, Mar 28, 2017 at 04:22:40PM +0300, Mika Kuoppala wrote:
> Chris Wilson writes:
>
> > Capturing GPU state requires the device to be awake in order to read
> > registers. Normally, this is taken along the error handler, but for the
> > direct debugfs access, we cannot make assumptions about
Localize link_rate_index to the if block, and rename to just index to
reduce indent.
Cc: Manasi Navare
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dp.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_d
Don't clobber intel_dp->sink_count with the raw value.
Suggested-by: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dp.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 81
This is what we have the readb and writeb variants for. Do some minor
return value and variable cleanup while at it.
Cc: Manasi Navare
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dp.c | 37 +
1 file changed, 17 insertions(+),
The source might not support as many lanes as the sink, or the link
training might have failed at higher lane counts. Take these into
account.
Cc: Dhinakaran Pandiyan
Cc: Manasi Navare
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dp.c | 2 +-
drivers/gpu/drm
Now that source rates are static and sink rates are updated whenever
DPCD is updated, we can do and cache the intersection of them whenever
sink rates are updated. This reduces code complexity, as we don't have
to keep calling the functions to intersect. We also get rid of several
common rates arra
In link training fallback, we're trying to find a rate that we know is
in a sorted array of common link rates. We don't need to limit the array
using the max rate. For test request, the DP CTS doesn't say we should
limit the rate based on earlier fallback.
Cc: Manasi Navare
Cc: Ville Syrjälä
Sig
There is some conflation related to sink rates, making this change more
complicated than it would otherwise have to be. There are three changes
here that are rather difficult to split up:
1) Use the intel_dp->sink_rates array for all DP, not just eDP 1.4. We
initialize it from DPCD on eDP 1.4 l
These are the theoretical maximums common for source and sink. These are
the maximums we should start with. They may be degraded in case of link
training failures, and the dynamic link values are stored separately.
Cc: Manasi Navare
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/
If we modify these on the fly depending on the link conditions, don't
pretend they are sink properties.
Some link vs. sink confusion still remains, but we'll take care of them
in follow-up patches.
Cc: Manasi Navare
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_d
v3 of [1], rebased and review addressed.
This might still conflict with some of Manasi's pending work, but I
think for the most parts we could start pushing these. The scales are
tipping, it'll be easier to rebase Manasi's stuff than this. Indeed some
of it may be easier to understand after the ch
Looking at DPCD DP_MAX_LINK_RATE may be completely bogus for eDP 1.4
which is allowed to use link rate select method and have 0 in max link
rate. With this change, it makes sense to store the max rate as the
actual rate rather than as a bw code.
Cc: Manasi Navare
Cc: Ville Syrjälä
Signed-off-by:
We need the source rates array so often that it makes sense to set it
once at init. This reduces function calls when we need the rates, making
the code easier to follow.
Cc: Manasi Navare
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dp.c | 35 +++
I can't think of a real world bug this could cause now, but this will be
required in follow-up work. While at it, change the parameter order to
be slightly more sensible.
Cc: Manasi Navare
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dp.c | 11 ++-
1 file
Rename the function, move it at the top, and reuse in
intel_dp_link_rate_index(). If there was a reason in the past to use
reverse search order here, there isn't now.
The names may be slightly confusing now, but intel_dp_link_rate_index()
will go away in follow-up patches.
v2: Use name intel_dp_r
We shouldn't silently use the first element if we can't find the rate
we're looking for. Make rate_to_index() more generally useful, and
fallback to the first element in the caller, with a big warning.
Cc: Manasi Navare
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/inte
Reviewed-by: Harry Wentland
Harry
On 2017-03-28 03:01 AM, Daniel Vetter wrote:
No need to grab both plane and crtc locks at the same time, we can do
them one after the other. If userspace races it'll get what it
deserves either way.
This removes another user of drm_modeset_lock_crtc. There's
This repo stopped being my own personal turf a long time ago ...
Very-much-acked-by: Jani Nikula
Signed-off-by: Daniel Vetter
---
dim | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/dim b/dim
index 99120b82513e..8f8104ce0b16 100755
--- a/dim
+++ b/dim
@@ -49,7 +49,7 @@ DIM_P
On Tue, Mar 28, 2017 at 12:51:26PM +0300, Jani Nikula wrote:
> This will print a generic usage error message and bail out on required
> arguments missing. This is in preparation for enabling 'set -u'.
>
> This is not an exhaustive conversion, but a good start.
>
> Signed-off-by: Jani Nikula
I t
On Tue, Mar 28, 2017 at 03:18:36PM +0300, Tomi Valkeinen wrote:
> On 27/03/17 10:43, Daniel Vetter wrote:
>
> > With atomic we've stopped killing the entire CRTC when you the last
> > userspace reference for the framebuffer on the primary plane disappears,
> > but just shut down the primary plane.
== Series Details ==
Series: drm/i915: Take rpm wakelock around debugfs/i915_gpu_info
URL : https://patchwork.freedesktop.org/series/22012/
State : success
== Summary ==
Series 22012v1 drm/i915: Take rpm wakelock around debugfs/i915_gpu_info
https://patchwork.freedesktop.org/api/1.0/series/220
On Tue, Mar 28, 2017 at 09:58:51AM +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: WARN if the core runtime PM get helpers fail
> URL : https://patchwork.freedesktop.org/series/21997/
> State : success
>
> == Summary ==
>
> Series 21997v1 drm/i915: WARN if the core runtime
Chris Wilson writes:
> Capturing GPU state requires the device to be awake in order to read
> registers. Normally, this is taken along the error handler, but for the
> direct debugfs access, we cannot make assumptions about the current
> device state and so either need to wake it up, or abort.
>
Capturing GPU state requires the device to be awake in order to read
registers. Normally, this is taken along the error handler, but for the
direct debugfs access, we cannot make assumptions about the current
device state and so either need to wake it up, or abort.
Fixes: 5a4c6f1b1b2d ("drm/i915:
On Tue, Mar 28, 2017 at 10:27:28AM +0200, Michal Wajdeczko wrote:
> On Tue, Mar 28, 2017 at 10:05:31AM +0300, Joonas Lahtinen wrote:
> > On ma, 2017-03-27 at 17:19 +, Michal Wajdeczko wrote:
> > > The file fits better. Also use "" for invalid case.
> > >
> > > Signed-off-by: Michal Wajdeczko
On Tue, Mar 28, 2017 at 11:11:55AM +0100, Chris Wilson wrote:
> On Tue, Mar 28, 2017 at 12:38:55PM +0300, Imre Deak wrote:
> > We don't expect the core runtime PM get helpers to return any error, so
> > add a WARN for this. Also print the return value for all the callsites
> > to help debugging.
>
On 27/03/17 10:43, Daniel Vetter wrote:
> With atomic we've stopped killing the entire CRTC when you the last
> userspace reference for the framebuffer on the primary plane disappears,
> but just shut down the primary plane. Assuming the driver can do that, we
> fall back to full CRTC shutdown if
Robert Bragg writes:
> On Mon, Mar 27, 2017 at 9:32 PM, Matthew Auld
> wrote:
>
>> Don't throw a warning if we are given an invalid property id. While
>> here let's also bring back Robert' original idea of catching unhandled
>> enumeration values at compile time.
>>
>> Fixes: eec688e1420d ("drm/
On Mon, Mar 27, 2017 at 9:32 PM, Matthew Auld
wrote:
> Don't throw a warning if we are given an invalid property id. While
> here let's also bring back Robert' original idea of catching unhandled
> enumeration values at compile time.
>
> Fixes: eec688e1420d ("drm/i915: Add i915 perf infrastructur
== Series Details ==
Series: series starting with [v2,1/2] drm/i915/scheduler: add gvt
force-single-submission for guc
URL : https://patchwork.freedesktop.org/series/21998/
State : success
== Summary ==
Series 21998v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/serie
On Tue, Mar 28, 2017 at 12:38:55PM +0300, Imre Deak wrote:
> We don't expect the core runtime PM get helpers to return any error, so
> add a WARN for this. Also print the return value for all the callsites
> to help debugging.
>
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/intel_runti
== Series Details ==
Series: drm/i915: WARN if the core runtime PM get helpers fail
URL : https://patchwork.freedesktop.org/series/21997/
State : success
== Summary ==
Series 21997v1 drm/i915: WARN if the core runtime PM get helpers fail
https://patchwork.freedesktop.org/api/1.0/series/21997/r
On Tue, Mar 28, 2017 at 09:33:20AM +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Move WARN_ON/MISSING_CASE macros to i915_utils.h
> URL : https://patchwork.freedesktop.org/series/21993/
> State : failure
>
> == Summary ==
>
> Series 21993v1 drm/i915: Move WARN_ON/MISSING
This will print a generic usage error message and bail out on required
arguments missing. This is in preparation for enabling 'set -u'.
This is not an exhaustive conversion, but a good start.
Signed-off-by: Jani Nikula
---
dim | 95 +++
Use -s for "strict" to 'set -u'. Fix the variable references to not fail
before subcommand call. The goal is to unconditionally 'set -u' at the
top, but it can't be done in one go, so add a way to test drive first.
Signed-off-by: Jani Nikula
---
dim | 11 ---
1 file changed, 8 insertions
GVT request needs a manual mmio load/restore. Before GuC submit
a request, send notification to gvt for mmio loading. And after
the GuC finished this GVT request, notify gvt again for mmio
restore. This follows the usage when using execlists submission.
Cc: xiao.zh...@intel.com
Cc: kevin.t...@inte
GVT needs single submission and cannot allow merge. So when GuC submitting
a GVT request, the next one should be submitted to guc later until the
previous one is completed. This is following the usage when using execlist
mode submission.
v2: make force-single-submission specific to gvt (Chris)
Cc
GVT requires force-single-submission and notification when i915
using execlist submit, and these should be extended to GuC when
i915 using GuC submit. Below two patches are used to implement this
Chuanxiao Dong (2):
drm/i915/scheduler: add gvt force-single-submission for guc
drm/i915/scheduler
We don't expect the core runtime PM get helpers to return any error, so
add a WARN for this. Also print the return value for all the callsites
to help debugging.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_runtime_pm.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
== Series Details ==
Series: drm/i915: Move WARN_ON/MISSING_CASE macros to i915_utils.h
URL : https://patchwork.freedesktop.org/series/21993/
State : failure
== Summary ==
Series 21993v1 drm/i915: Move WARN_ON/MISSING_CASE macros to i915_utils.h
https://patchwork.freedesktop.org/api/1.0/series
On Mon, 27 Mar 2017, Daniel Vetter wrote:
> It's kinda beyond just drm-intel nowadays ...
>
> Idea from Jani on irc.
Hah, it was a bit tongue-in-cheek, but works for me!
Ack also on patch 1.
BR,
Jani.
>
> Signed-off-by: Daniel Vetter
> ---
> dim.rst | 6 +++---
> 1 file changed, 3 insertions
On Mon, 27 Mar 2017, Daniel Vetter wrote:
> Inspired by Jani's efforts to clean this up and structure it better.
>
> Signed-off-by: Daniel Vetter
> ---
> dim.rst | 20 ++--
> 1 file changed, 14 insertions(+), 6 deletions(-)
>
> diff --git a/dim.rst b/dim.rst
> index 2f8fda8c42a7.
On ma, 2017-03-27 at 17:20 +, Michal Wajdeczko wrote:
> Cleanups of uc firmware structs from GuC and Huc are the same for both.
> Move common code to the helper function to avoid duplication.
>
> Signed-off-by: Michal Wajdeczko
> Cc: Arkadiusz Hiler
> Cc: Joonas Lahtinen
fetch_and_zero see
On ti, 2017-03-28 at 08:45 +, Michal Wajdeczko wrote:
> We can't sometimes use these macros in other headers due to
> include and definition order. As i915_utils.h already contains
> other helper macros move these macros there.
>
> Signed-off-by: Michal Wajdeczko
> Cc: Joonas Lahtinen
> Cc:
On Mon, Mar 27, 2017 at 05:21:24PM +, Michal Wajdeczko wrote:
> There is no reason to separately check for valid fw path before
> we try to fetch it. Let the fetch function take care of this.
>
> Signed-off-by: Michal Wajdeczko
> Cc: Arkadiusz Hiler
> Cc: Joonas Lahtinen
Reviewed-by: Arkadi
On Tue, 28 Mar 2017, Michal Wajdeczko wrote:
> On Wed, Mar 15, 2017 at 12:49:26PM +0200, Jani Nikula wrote:
>> The old URL works but gives 301 Moved Permanently. Update.
>>
>> Signed-off-by: Jani Nikula
>> ---
>> drivers/gpu/drm/i915/intel_csr.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 dele
On Mon, Mar 27, 2017 at 05:21:02PM +, Michal Wajdeczko wrote:
> This function is no longer used. Its functionality is covered
> by intel_uc_fini_fw().
>
> Signed-off-by: Michal Wajdeczko
> Cc: Arkadiusz Hiler
> Cc: Joonas Lahtinen
Reviewed-by: Arkadiusz Hiler
--
Cheers,
Arek
On Mon, Mar 27, 2017 at 05:20:40PM +, Michal Wajdeczko wrote:
> Cleanups of uc firmware structs from GuC and Huc are the same for both.
> Move common code to the helper function to avoid duplication.
>
> Signed-off-by: Michal Wajdeczko
> Cc: Arkadiusz Hiler
> Cc: Joonas Lahtinen
Reviewed-by
We can't sometimes use these macros in other headers due to
include and definition order. As i915_utils.h already contains
other helper macros move these macros there.
Signed-off-by: Michal Wajdeczko
Cc: Joonas Lahtinen
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h | 18 --
> -Original Message-
> From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> Sent: Tuesday, March 28, 2017 4:22 PM
> To: Dong, Chuanxiao
> Cc: intel-gfx@lists.freedesktop.org; intel-gvt-...@lists.freedesktop.org
> Subject: Re: [PATCH 1/2] drm/i915/scheduler: add gvt force-single-
> subm
On Tue, Mar 28, 2017 at 09:31:16AM +0100, Chris Wilson wrote:
> On Mon, Mar 27, 2017 at 06:03:37PM -0700, Michel Thierry wrote:
> > What if it fails/overflows after some engines' thresholds have been
> > set, should it set them back to 0's or leave them enable?
>
> Yes. Validate userspace first, t
On Mon, Mar 27, 2017 at 02:48:42PM -0700, Michel Thierry wrote:
>
>
> On 25/03/17 02:26, Chris Wilson wrote:
> >On Fri, Mar 24, 2017 at 06:30:07PM -0700, Michel Thierry wrote:
> >>diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
> >>b/drivers/gpu/drm/i915/intel_ringbuffer.h
> >>index e8faf2c
On Mon, Mar 27, 2017 at 06:03:37PM -0700, Michel Thierry wrote:
> On 25/03/17 02:38, Chris Wilson wrote:
> >On Fri, Mar 24, 2017 at 06:30:09PM -0700, Michel Thierry wrote:
> >>diff --git a/drivers/gpu/drm/i915/i915_drv.h
> >>b/drivers/gpu/drm/i915/i915_drv.h
> >>index b43c37a911bb..1741584d858f 10
1 - 100 of 111 matches
Mail list logo
