On Tue, Oct 18, 2016 at 01:48:52PM +0100, Chris Wilson wrote:
> On Tue, Oct 18, 2016 at 03:41:54PM +0300, Petri Latvala wrote:
> > How should vgem work be flushed properly? With this i915 flushing is
> > guaranteed even if vgem is opened first, then i915, but such
> > flushing won't be done if only
On Thu, Oct 20, 2016 at 08:22:00AM +0800, Zhenyu Wang wrote:
> On 2016.10.19 11:11:42 +0100, Chris Wilson wrote:
> > The workload took a pointer to the request, and even waited upon,
> > without holding a reference on the request. Take that reference
> > explicitly and fix up the error path followi
On Wed, Oct 19, 2016 at 06:29:13PM +0300, Jani Nikula wrote:
> On Wed, 19 Oct 2016, Ander Conselvan De Oliveira wrote:
> > On Thu, 2016-10-13 at 15:46 +0200, Daniel Vetter wrote:
> >> > +/**
> >> > + * @hw_state: hardware configuration for the DPLL.
> >> "... stored in struct &inte
Hey,
Op 20-10-16 om 01:15 schreef Matt Roper:
> On Wed, Oct 12, 2016 at 03:28:18PM +0200, Maarten Lankhorst wrote:
>> Allow the driver to write watermarks during atomic evasion.
>> This will make it possible to write the watermarks in a cleaner
>> way on gen9+.
>>
>> Signed-off-by: Maarten Lankhor
> -Original Message-
> From: Nikula, Jani
> Sent: Wednesday, October 19, 2016 11:09 PM
> To: Yang, Libin ; Lin, Mengdong
> ; intel-gfx@lists.freedesktop.org
> Cc: libin.y...@linux.intel.com; Pandiyan, Dhinakaran
> ; Zhang, Keqiao
> ; Zhao, Juan J
> Subject: RE: [Intel-gfx] [PATCH RESEND 9
On 2016.10.19 12:02:58 +0100, Chris Wilson wrote:
> On Wed, Oct 19, 2016 at 06:45:51PM +0800, Zhenyu Wang wrote:
> > On 2016.10.19 11:11:35 +0100, Chris Wilson wrote:
> > > I think this is the set required to bring gvt into line, at least to
> > > unblock myself.
> >
> > Thanks a lot, Chris. I'd l
On Wed, 2016-10-19 at 08:47 +0100, Chris Wilson wrote:
> On Tue, Oct 18, 2016 at 05:18:48PM -0700, Dhinakaran Pandiyan wrote:
> > From: "Pandiyan, Dhinakaran"
> >
> > No functional change. Just printing the number of active links without
> > stating what the number means is not very useful. So, a
On 2016.10.19 11:11:42 +0100, Chris Wilson wrote:
> The workload took a pointer to the request, and even waited upon,
> without holding a reference on the request. Take that reference
> explicitly and fix up the error path following request allocation that
> missed flushing the request.
>
> Signed
On 2016.10.19 16:18:03 +, Wei Yongjun wrote:
> From: Wei Yongjun
>
> In case of error, the function i915_gem_object_create() returns
> ERR_PTR() not NULL. The NULL test in the return value check should
> be replaced with IS_ERR().
>
> Signed-off-by: Wei Yongjun
Hi, Yongjun, we've already h
On Wed, 2016-10-19 at 14:46 -0700, Manasi Navare wrote:
> This work struct will be used to schedule a uevent on a separate
> thread. This will be scheduled after a link train failure during modeset
> to indicate a modeset retry request. It will get executed after the
> current modeset is complete a
On Wed, Oct 19, 2016 at 04:15:02PM -0700, Matt Roper wrote:
> On Wed, Oct 12, 2016 at 03:28:18PM +0200, Maarten Lankhorst wrote:
> > Allow the driver to write watermarks during atomic evasion.
> > This will make it possible to write the watermarks in a cleaner
> > way on gen9+.
> >
> > Signed-off-
On Wed, Oct 12, 2016 at 03:28:18PM +0200, Maarten Lankhorst wrote:
> Allow the driver to write watermarks during atomic evasion.
> This will make it possible to write the watermarks in a cleaner
> way on gen9+.
>
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/i915/i915_drv.h |
On Wed, Oct 12, 2016 at 03:28:17PM +0200, Maarten Lankhorst wrote:
> Move calculating minimum allocations to a helper, which cleans up the
> code some more. The cursor is still allocated in advance because it
> doesn't count towards data rate and should always be reserved.
>
> Signed-off-by: Maart
== Series Details ==
Series: Hotplug Uevent on Link training failure on DP
URL : https://patchwork.freedesktop.org/series/14057/
State : failure
== Summary ==
Series 14057v1 Hotplug Uevent on Link training failure on DP
https://patchwork.freedesktop.org/api/1.0/series/14057/revisions/1/mbox/
On Wed, Oct 12, 2016 at 03:28:16PM +0200, Maarten Lankhorst wrote:
> This is not required any more now that we get fresh state from
> drm_atomic_crtc_state_for_each_plane_state. Zero all state
> in advance.
>
> Signed-off-by: Maarten Lankhorst
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i
On Wed, Oct 12, 2016 at 03:28:14PM +0200, Maarten Lankhorst wrote:
> Caching is not required, drm_atomic_crtc_state_for_each_plane_state
> can be used to inspect all plane_states that are assigned to the
> current crtc_state, so we can just recalculate every time.
>
> Signed-off-by: Maarten Lankho
On Wed, Oct 12, 2016 at 03:28:15PM +0200, Maarten Lankhorst wrote:
> It's only used in one function, and can be calculated without caching it
> in the global struct by using drm_atomic_crtc_state_for_each_plane_state.
>
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/i915/intel_drv.h
== Series Details ==
Series: drm/i915/dp: add lane_count check in intel_dp_check_link_status (rev2)
URL : https://patchwork.freedesktop.org/series/11667/
State : warning
== Summary ==
Series 11667v2 drm/i915/dp: add lane_count check in intel_dp_check_link_status
https://patchwork.freedesktop.o
From: "Navare, Manasi D"
These static helper functions are required to be used during
fallback link rate implemnetation so they need to be placed at the top
of the file.
v3:
* Add cleanup to other patch (Mika Kahola)
v2:
* Dont move around functions declared in intel_drv.h (Rodrigo Vivi)
Cc: Ja
This is required to return the index of link rate into
common_rates array. This gets used to retry the link
training at lower link rate.
Cc: Jani Nikula
Cc: Daniel Vetter
Cc: Ville Syrjala
Signed-off-by: Manasi Navare
---
drivers/gpu/drm/i915/intel_dp.c | 15 +++
1 file changed, 1
These patches handle the DP link training failure during atomic modeset.
A new connector property is defined to indicate if link training retry
is requested on failure. If link training fails, we set this connector
property and send a hotplug uevent that gets exceuted after the current modeset
is c
The link_train_retry property of the connector needs to be checked
to see if a full modeset is required. If this is set, then link train
retry is requested possibly due to linktrain failure in the previous
modeset. Hence we need to indicate connector status changed in order to
trigger a full modese
If link training at a link rate optimal for a particular
mode fails during modeset's atomic commit phase, then we
let the modeset complete and then retry. We save the link rate
value at which link training failed and use a lower link rate
to prune the modes during the next modeset, configure the pi
This work function gets scheduled on link training failure
during the atomic commit of modeset. It should get executed
after the current modeset is completed and send a hotplug uevent
to notify the usersapce about change in the connector link property
requesting link_train_retry
Cc: Jani Nikula
C
This work struct will be used to schedule a uevent on a separate
thread. This will be scheduled after a link train failure during modeset
to indicate a modeset retry request. It will get executed after the
current modeset is complete and all locks are released. This was
required to avoid deadlock.
This patch adds support to handle automated DP compliance
link training test requests. This patch has been tested with
Unigraf DPR-120 DP Compliance device for testing Link
Training Compliance.
After we get a short pulse Compliance test request, test
request values are read and hotplug uevent is se
This is a boolean that is set to true if link training fails
during modeset in the atomic commit.
This will be used to detect a change in the connector properties
and to retrigger a full modeset so that the link can be retrained
at lower link rate value.
Cc: dri-de...@lists.freedesktop.org
Cc: Jan
Currently it's entirely possible to go through the link training step
without first determining the lane_count, which is silly since we end up
doing a bunch of aux transfers of size = 0, as highlighted by
WARN_ON(!msg->buffer != !msg->size), and can only ever result in a
'failed to update link trai
The inter-engine synchronisation (with and without semaphores) is
equally exercised by gem_sync, so leave gem_storedw_loop out of the
"quick" set.
Signed-off-by: Chris Wilson
---
tests/gem_storedw_loop.c | 6 +++---
tests/intel-ci/fast-feedback.testlist | 7 ---
2 files changed,
On Wed, Oct 19, 2016 at 09:48:02PM +0300, Ville Syrjälä wrote:
> On Wed, Oct 19, 2016 at 07:06:35PM +0100, Chris Wilson wrote:
> > With the merge of 4.9-rc1, we can say goodbye to having to forcibly
> > select STOP_MACHINE in order to have a working stop_machine(). The code
> > just works now and t
On Wed, Oct 19, 2016 at 07:06:35PM +0100, Chris Wilson wrote:
> With the merge of 4.9-rc1, we can say goodbye to having to forcibly
> select STOP_MACHINE in order to have a working stop_machine(). The code
> just works now and the CONFIG_STOP_MACHINE symbol removed.
Note the relevant commit too?
8
On Wed, Oct 19, 2016 at 07:16:39PM +0100, Chris Wilson wrote:
> On Wed, Oct 19, 2016 at 09:02:04PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Using spin_lock_irq()/spin_unlock_irq() from within the interrupt
> > handler is a no-no. Let's save/restore the flags to
== Series Details ==
Series: drm/i915/gvt: fix return value check
URL : https://patchwork.freedesktop.org/series/14033/
State : warning
== Summary ==
Series 14033v1 drm/i915/gvt: fix return value check
https://patchwork.freedesktop.org/api/1.0/series/14033/revisions/1/mbox/
Test kms_cursor_le
On Wed, Oct 19, 2016 at 09:02:04PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Using spin_lock_irq()/spin_unlock_irq() from within the interrupt
> handler is a no-no. Let's save/restore the flags to avoid turning on
> interrupts prematurely.
>
> We hit this in a bunch o
With the merge of 4.9-rc1, we can say goodbye to having to forcibly
select STOP_MACHINE in order to have a working stop_machine(). The code
just works now and the CONFIG_STOP_MACHINE symbol removed.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/Kconfig | 1 -
1 file changed, 1 deletion(-)
From: Ville Syrjälä
Using spin_lock_irq()/spin_unlock_irq() from within the interrupt
handler is a no-no. Let's save/restore the flags to avoid turning on
interrupts prematurely.
We hit this in a bunch of our CI systems, but for whatever reason I
wasn't able to reproduce on my own machine, so th
On Wed, Oct 19, 2016 at 05:47:39PM -, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Handle early failure during intel_get_load_detect_pipe
> URL : https://patchwork.freedesktop.org/series/14016/
> State : warning
>
> == Summary ==
>
> Series 14016v1 drm/i915: Handle early f
== Series Details ==
Series: drm/i915: Handle early failure during intel_get_load_detect_pipe
URL : https://patchwork.freedesktop.org/series/14016/
State : warning
== Summary ==
Series 14016v1 drm/i915: Handle early failure during intel_get_load_detect_pipe
https://patchwork.freedesktop.org/ap
== Series Details ==
Series: drm/i915: Enable support for nonblocking modeset.
URL : https://patchwork.freedesktop.org/series/14026/
State : failure
== Summary ==
Series 14026v1 drm/i915: Enable support for nonblocking modeset.
https://patchwork.freedesktop.org/api/1.0/series/14026/revisions/1
On 10/19/2016 10:01 AM, Michal Hocko wrote:
> The question I had earlier was whether this has to be an explicit FOLL
> flag used by g-u-p users or we can just use it internally when mm !=
> current->mm
The reason I chose not to do that was that deferred work gets run under
a basically random 'curr
On Tue, Sep 06, 2016 at 05:43:44PM +0300, Ville Syrjälä wrote:
> On Sat, Aug 27, 2016 at 02:33:25PM +0100, Matthew Auld wrote:
> > Currently it's entirely possible to go through the link training step
> > without first determining the lane_count, which is silly since we end up
> > doing a bunch of
On Wed 19-10-16 09:49:43, Dave Hansen wrote:
> On 10/19/2016 02:07 AM, Michal Hocko wrote:
> > On Wed 19-10-16 09:58:15, Lorenzo Stoakes wrote:
> >> On Tue, Oct 18, 2016 at 05:30:50PM +0200, Michal Hocko wrote:
> >>> I am wondering whether we can go further. E.g. it is not really clear to
> >>> me
== Series Details ==
Series: Broxton ddi phy refactoring (rev5)
URL : https://patchwork.freedesktop.org/series/13320/
State : failure
== Summary ==
Series 13320v5 Broxton ddi phy refactoring
https://patchwork.freedesktop.org/api/1.0/series/13320/revisions/5/mbox/
Test drv_module_reload_basic:
On 10/19/2016 02:07 AM, Michal Hocko wrote:
> On Wed 19-10-16 09:58:15, Lorenzo Stoakes wrote:
>> On Tue, Oct 18, 2016 at 05:30:50PM +0200, Michal Hocko wrote:
>>> I am wondering whether we can go further. E.g. it is not really clear to
>>> me whether we need an explicit FOLL_REMOTE when we can in
On Wed, Oct 12, 2016 at 12:41 PM, Joonas Lahtinen <
joonas.lahti...@linux.intel.com> wrote:
> On ti, 2016-10-11 at 12:03 -0700, Robert Bragg wrote:
> > > > + case DRM_I915_PERF_PROP_MAX:
> > > > + BUG();
> > >
> > > We already handle this case above, but I guess
From: Wei Yongjun
In case of error, the function i915_gem_object_create() returns
ERR_PTR() not NULL. The NULL test in the return value check should
be replaced with IS_ERR().
Signed-off-by: Wei Yongjun
---
drivers/gpu/drm/i915/gvt/cmd_parser.c | 8
1 file changed, 4 insertions(+), 4
== Series Details ==
Series: drm/i915: Stop reporting error details in dmesg as well as the
error-state
URL : https://patchwork.freedesktop.org/series/14021/
State : failure
== Summary ==
Series 14021v1 drm/i915: Stop reporting error details in dmesg as well as the
error-state
https://patchw
On Wed, 19 Oct 2016, Ander Conselvan De Oliveira wrote:
> On Thu, 2016-10-13 at 15:46 +0200, Daniel Vetter wrote:
>> > + /**
>> > + * @hw_state: hardware configuration for the DPLL.
>> "... stored in struct &intel_dpll_hw_state." - I love my hyperlinks ;-)
>
> I'll add that, but I think it's si
On Wed, 19 Oct 2016, Ville Syrjälä wrote:
> On Wed, Oct 19, 2016 at 03:08:04PM +0300, Jani Nikula wrote:
>> Fix warnings on building htmldocs.
>>
>> v2: whitespace around '/' (Ville)
>>
>> Fixes: 056996b95686 ("drm: Helper for lspcon in drm_dp_dual_mode")
>> Cc: Rodrigo Vivi
>> Cc: Shashank Sha
On Wed, 19 Oct 2016, Patchwork wrote:
> == Series Details ==
>
> Series: drm: Fix LSPCON kernel-doc (rev2)
> URL : https://patchwork.freedesktop.org/series/14017/
> State : failure
>
> == Summary ==
>
> Series 14017v2 drm: Fix LSPCON kernel-doc
> https://patchwork.freedesktop.org/api/1.0/series/
On Thu, Mar 24, 2016 at 5:41 PM, Joonas Lahtinen
wrote:
> On ke, 2016-03-23 at 11:39 +0530, akash.g...@intel.com wrote:
>> From: Chris Wilson
>>
>> This provides support for the Drivers or shmem file owners to register
>> a set of callbacks, which can be invoked from the address space operations
Sorry it's taken me forever to get back to this. Some comments inline.
BR,
Jani.
On Wed, 12 Oct 2016, "Yang, Libin" wrote:
>> -Original Message-
>> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>> Lin, Mengdong
>> Sent: Wednesday, October 12, 2016 10:46 A
On Wed, Oct 19, 2016 at 03:08:04PM +0300, Jani Nikula wrote:
> Fix warnings on building htmldocs.
>
> v2: whitespace around '/' (Ville)
>
> Fixes: 056996b95686 ("drm: Helper for lspcon in drm_dp_dual_mode")
> Cc: Rodrigo Vivi
> Cc: Shashank Sharma
> Cc:
> Signed-off-by: Jani Nikula
lgtm
Revi
== Series Details ==
Series: drm: Fix LSPCON kernel-doc (rev2)
URL : https://patchwork.freedesktop.org/series/14017/
State : failure
== Summary ==
Series 14017v2 drm: Fix LSPCON kernel-doc
https://patchwork.freedesktop.org/api/1.0/series/14017/revisions/2/mbox/
Test gem_exec_suspend:
Emitting a debug message for every pixel tested takes us from 0.4s to 20s
on an old Core2.
Signed-off-by: Chris Wilson
---
tests/gem_tiled_pread_basic.c | 32
1 file changed, 20 insertions(+), 12 deletions(-)
diff --git a/tests/gem_tiled_pread_basic.c b/tests/ge
== Series Details ==
Series: drm/i915: Handle early failure during intel_get_load_detect_pipe
URL : https://patchwork.freedesktop.org/series/14016/
State : failure
== Summary ==
Series 14016v1 drm/i915: Handle early failure during intel_get_load_detect_pipe
https://patchwork.freedesktop.org/ap
This is the last connector still looking at crtc->config. Fix this.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_hdmi.c | 48 +--
1 file changed, 21 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gp
== Series Details ==
Series: series starting with [01/12] drm/i915/gvt:
s/drm_gem_object_unreference/i915_gem_object_put/
URL : https://patchwork.freedesktop.org/series/14013/
State : warning
== Summary ==
Series 14013v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/se
The only user was i915, which is now gone.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_edid.c | 26 --
include/drm/drm_edid.h | 1 -
2 files changed, 27 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 95de47ba1e77
This gets rid of a warning that the connectors are used without locking
when doing a nonblocking modeset.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 24 +++-
1 file changed, 15 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i
All of this state should be updated as soon as possible. It shouldn't be
done later because then future updates may not depend on it.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/driv
drm_select_eld requires mode_config.mutex and connection_mutex
because it looks at the connector list and at the legacy encoders.
This is not required, because when we call audio_codec_enable we know
which connector it was called for, so pass the state.
This also removes having to look at crtc->c
This is a rebased version of the series. Patch 4 fails to apply because
of drm_atomic_state refcounting, but otherwise unchanged.
This series is tested on my BDW and SKL. Skylake requires
Lyude's fixes + "[PATCH 0/8] drm/i915/gen9+: Atomic wm fixes."
Maarten Lankhorst (6):
drm/i915: Convert int
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 54a4b2704179..523bb97c3bca 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++
== Series Details ==
Series: drm/i915/gvt: Add runtime pm around fences
URL : https://patchwork.freedesktop.org/series/14011/
State : warning
== Summary ==
Series 14011v1 drm/i915/gvt: Add runtime pm around fences
https://patchwork.freedesktop.org/api/1.0/series/14011/revisions/1/mbox/
Test d
On Wed, Oct 19, 2016 at 1:26 PM, Jani Nikula
wrote:
> On Wed, 19 Oct 2016, Daniel Vetter wrote:
>> On Tue, Oct 18, 2016 at 07:33:10PM +0300, Jani Nikula wrote:
>>> On Tue, 18 Oct 2016, Petri Latvala wrote:
>>> > The current contributing docs for IGT state:
>>> >
>>> > <<
>>> > There is no form
On Wed, 19 Oct 2016, Paulo Zanoni wrote:
> Why is Daniel asking me to submit patches to the mailing list if that
> guy doesn't seem to need to follow the same rule? Is this some sort of
> double- standard?".
Not to take anything away from a perfectly good rant, but from now on
it's really s/Danie
On Wed, Oct 19, 2016 at 3:06 PM, Paulo Zanoni wrote:
>> > > At the very least I would like to see all commits have a visit to
>> > > the
>> > > mailing list before pushing, as the current docs already ask for.
>> > > The
>> > > "right after" part would be changed to a $period of quarantine,
>> > >
The kernel tries to hide L-shaped memory with asymmetric swizzling from
userspace by reporting lies through the get-tiling interface. Check for
these lies by comparing the reported swizzle with the actual swizzle,
and only run swizzling tests where we know the underlying physical
swizzling.
Signed
Em Qua, 2016-10-19 às 09:50 +0200, Daniel Vetter escreveu:
> On Tue, Oct 18, 2016 at 07:33:10PM +0300, Jani Nikula wrote:
> >
> > On Tue, 18 Oct 2016, Petri Latvala wrote:
> > >
> > > The current contributing docs for IGT state:
> > >
> > > <<
> > > There is no formal review requirement and r
== Series Details ==
Series: drm/i915/gvt: Hold a reference on the request
URL : https://patchwork.freedesktop.org/series/14009/
State : failure
== Summary ==
Series 14009v1 drm/i915/gvt: Hold a reference on the request
https://patchwork.freedesktop.org/api/1.0/series/14009/revisions/1/mbox/
As we already capture all the information from the registers into the
error-state, also dumping that to dmesg just generates noise that upsets
CI and users alike (and doesn't provide us with any more information).
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_irq.c | 86 ++---
Fix warnings on building htmldocs.
v2: whitespace around '/' (Ville)
Fixes: 056996b95686 ("drm: Helper for lspcon in drm_dp_dual_mode")
Cc: Rodrigo Vivi
Cc: Shashank Sharma
Cc:
Signed-off-by: Jani Nikula
---
n.b. 056996b95686 ("drm: Helper for lspcon in drm_dp_dual_mode") has
been merged vi
On Thu, 2016-10-13 at 15:46 +0200, Daniel Vetter wrote:
> On Tue, Oct 04, 2016 at 03:32:15PM +0300, Ander Conselvan de Oliveira wrote:
> >
> > The documentation for most of the non-static members and structs were
> > missing. Fix that.
> >
> > v2: Fix typos (Durga)
> >
> > v3: Rebase.
> > Fi
On Wed, Oct 19, 2016 at 02:43:24PM +0300, Jani Nikula wrote:
> Fix warnings on building htmldocs.
>
> Fixes: 056996b95686 ("drm: Helper for lspcon in drm_dp_dual_mode")
> Cc: Rodrigo Vivi
> Cc: Shashank Sharma
> Cc:
> Signed-off-by: Jani Nikula
>
> ---
>
> n.b. 056996b95686 ("drm: Helper for
Fix warnings on building htmldocs.
Fixes: 056996b95686 ("drm: Helper for lspcon in drm_dp_dual_mode")
Cc: Rodrigo Vivi
Cc: Shashank Sharma
Cc:
Signed-off-by: Jani Nikula
---
n.b. 056996b95686 ("drm: Helper for lspcon in drm_dp_dual_mode") has
been merged via drm-intel tree
---
drivers/gpu/d
In the error path, we have to be ready to handle an error before either
the state or restore_state have been allocated.
[ 397.001342] BUG: unable to handle kernel NULL pointer dereference at
(null)
[ 397.001419] IP: [] intel_get_load_detect_pipe+0xe4/0x610
[i915]
[ 397.001502] PGD 1
On Wed, 19 Oct 2016, Daniel Vetter wrote:
> On Tue, Oct 18, 2016 at 07:33:10PM +0300, Jani Nikula wrote:
>> On Tue, 18 Oct 2016, Petri Latvala wrote:
>> > The current contributing docs for IGT state:
>> >
>> > <<
>> > There is no formal review requirement and regular contributors with
>> > co
On Tue, 18 Oct 2016, "Sharma, Shashank" wrote:
> Reviewed-by: Shashank Sharma
Both pushed to drm-intel-next-queued, thanks for the review.
RB,
Jani.
>
> Regards
> Shashank
> -Original Message-
> From: Nikula, Jani
> Sent: Tuesday, October 18, 2016 4:52 PM
> To: intel-gfx@lists.freedesk
On Tue, 18 Oct 2016, Chris Wilson wrote:
> On Tue, Oct 18, 2016 at 02:28:35PM +0300, Jani Nikula wrote:
>> Fixes sparse warnings:
>>
>> drivers/gpu/drm/drm_debugfs_crc.c:118:30: warning: symbol
>> 'drm_crtc_crc_control_fops' was not declared. Should it be static?
>>
>> drivers/gpu/drm/drm_debugf
On Wed, Oct 19, 2016 at 06:45:51PM +0800, Zhenyu Wang wrote:
> On 2016.10.19 11:11:35 +0100, Chris Wilson wrote:
> > I think this is the set required to bring gvt into line, at least to
> > unblock myself.
>
> Thanks a lot, Chris. I'd like to merge this in next pull request,
> or let me know you w
== Series Details ==
Series: series starting with [1/2] drm/i915/gvt: Stop checking for impossible
interrupts from a kthread (rev2)
URL : https://patchwork.freedesktop.org/series/14004/
State : failure
== Summary ==
Series 14004v2 Series without cover letter
https://patchwork.freedesktop.org/
On Wed, Oct 19, 2016 at 06:32:54PM +0800, Zhenyu Wang wrote:
> On 2016.10.19 11:11:42 +0100, Chris Wilson wrote:
> > The workload took a pointer to the request, and even waited upon,
> > without holding a reference on the request. Take that reference
> > explicitly and fix up the error path followi
On 2016.10.19 11:11:35 +0100, Chris Wilson wrote:
> I think this is the set required to bring gvt into line, at least to
> unblock myself.
Thanks a lot, Chris. I'd like to merge this in next pull request,
or let me know you want to be picked up by drm-intel directly.
If 4/12 would be picked up alo
On ti, 2016-10-18 at 14:39 +0100, Chris Wilson wrote:
> It's in my tree (on top of nightly) already with Joonas' r-b.
Patch 1/2 seems to have my comments already, could be addressed and
respined too.
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
_
On ti, 2016-10-18 at 19:51 +0100, Matthew Auld wrote:
> >
> > * Returns 0 if the request was found within the alloted time.
> > Else returns the
> > * errno with remaining time filled in timeout argument.
> > */
> > -int i915_wait_request(struct drm_i915_gem_request *req,
> > -
On Tue, Oct 18, 2016 at 05:46:48PM +, Saarinen, Jani wrote:
> > On Tue, Oct 18, 2016 at 01:05:24PM -, Patchwork wrote:
> > > == Series Details ==
> > >
> > > Series: series starting with [CI,1/4] drm/i915: Bump object bookkeeping to
> > u64 from size_t
> > > URL : https://patchwork.freede
On 2016.10.19 11:11:42 +0100, Chris Wilson wrote:
> The workload took a pointer to the request, and even waited upon,
> without holding a reference on the request. Take that reference
> explicitly and fix up the error path following request allocation that
> missed flushing the request.
>
> Signed
On 2016.10.19 11:11:45 +0100, Chris Wilson wrote:
> We have the ability to map an object, so use it rather than opencode it
> badly.
>
> Signed-off-by: Chris Wilson
Planned to fix these mapping too, obviously not fast than you..
Reviewed-by: Zhenyu Wang
> ---
> drivers/gpu/drm/i915/gvt/cmd_p
On ke, 2016-10-19 at 11:11 +0100, Chris Wilson wrote:
> Try to catch the violation of unpinning the backing storage whilst still
> bound to the GPU.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Joonas Lahtinen
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
This code was removed from i915_cmd_parser.c but still an obsolete
version wound up being duplicated into gvt/cmd_parser.c. Good riddance.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gvt/cmd_parser.c | 38 ---
1 file changed, 38 deletions(-)
diff --git a
We have the ability to map an object, so use it rather than opencode it
badly.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gvt/cmd_parser.c | 28 +---
drivers/gpu/drm/i915/gvt/execlist.c | 2 +-
2 files changed, 10 insertions(+), 20 deletions(-)
diff --git a/
The workload took a pointer to the request, and even waited upon,
without holding a reference on the request. Take that reference
explicitly and fix up the error path following request allocation that
missed flushing the request.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gvt/scheduler
Unpinning the pages prior to the object being release from the GPU may
allow the GPU to read and write into system pages (i.e. use after free
by the hw).
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gvt/execlist.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff
Deprecated functions; it is also not clear whether these are called from
the right context.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gvt/execlist.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/execlist.c
b/drivers/gpu/drm/i915/gvt/
The purpose of returning the just-pinned VMA is so that we can use the
information within, like its address. Also it should be tracked and used
as the cookie to unpin...
Signed-off-by: Chris Wilson
Reviewed-by: Zhenyu Wang
---
drivers/gpu/drm/i915/gvt/execlist.c | 20 +---
1 fil
The kthread will not be interrupted, don't even bother checking.
Signed-off-by: Chris Wilson
Reviewed-by: Zhenyu Wang
---
drivers/gpu/drm/i915/gvt/scheduler.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c
b/drivers/gpu/drm/i91
For whatever reason, the gvt scheduler runs synchronously. At the very
least, lets run synchronously without holding the struct_mutex.
v2: cut'n'paste mutex_lock instead of unlock.
Replace long hold of struct_mutex with a mutex to serialise the worker
threads.
Signed-off-by: Chris Wilson
---
dr
Manipulating the fence_list requires the runtime wakelock, as does
writing to the fence registers. Acquire a wakelock for the former, and
assert that the device is awake for the latter.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gvt/aperture_gm.c | 10 ++
1 file changed, 10 ins
We have the ability to map an object, so use it rather than opencode it
badly. Note that the object remains permanently pinned, this is poor
practise.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gvt/cmd_parser.c | 21 ++---
drivers/gpu/drm/i915/gvt/execlist.c | 2 +-
1 - 100 of 156 matches
Mail list logo
