kernel test robot writes:
>
> on test machine: qemu-system-x86_64 -enable-kvm -m 320M
>
> caused below changes:
>
> [1.608985] mwave: mwavedd::mwave_init: Error: Failed to initialize
> [1.609295] Hangcheck: starting hangcheck timer 0.9.1 (tick is 180
> seconds, margin is 60 seconds).
>
FYI, we noticed the following commit:
commit: 75f6dfe3e652e1adef8cc1b073c89f3e22103a8f ("drm: Deduplicate driver
initialization message")
git://anongit.freedesktop.org/drm-intel drm-intel-nightly
in testcase: trinity
with following parameters:
runtime: 300s
test-description: Trinity i
== Series Details ==
Series: Introduce DP MST Topology state (rev2)
URL : https://patchwork.freedesktop.org/series/17303/
State : success
== Summary ==
Series 17303v2 Introduce DP MST Topology state
https://patchwork.freedesktop.org/api/1.0/series/17303/revisions/2/mbox/
fi-bdw-5557u tot
Make use of the added MST helpers to find, allocate and release link bw
for atomic modesets.
Signed-off-by: Dhinakaran Pandiyan
---
drivers/gpu/drm/i915/intel_display.c | 39 +++-
drivers/gpu/drm/i915/intel_dp_mst.c | 36 -
drivers
Link bandwidth is shared between multiple display streams in DP MST
configurations. The DP MST topology manager structure maintains the shared
link bandwidth for a primary link directly connected to the GPU. For atomic
modesetting drivers, checking if there is sufficient link bandwidth for a
mode n
drm_dp_mst_allocate_vcpi() apart from setting up the vcpi structure,
also finds if there are enough slots available. This check is a duplicate
of that implemented in drm_dp_mst_find_vcpi_slots(). Let's move this check
out and reuse the existing drm_dp_mst_find_vcpi_slots() function to check
if ther
drm_dp_atomic_find_vcpi_slots() should be called from ->atomic_check() to
check there are sufficient vcpi slots for a mode and to add that to the
state. This should be followed by a call to drm_dp_mst_allocate_vcpi()
in ->atomic_commit() to initialize a struct vcpi for the port.
drm_dp_atomic_rele
struct drm_dp_mst_topology_mgr currently stores a pointer to struct dev.
Changing this to instead hold a pointer to drm_device is more useful as it
can give us access to DRM structures from the topology manager. This
also makes it consistent with other DRM structures like drm_crtc,
drm_connector et
Link bandwidth is shared between multiple display streams in DP MST
configurations. The DP MST topology manager structure maintains the shared
link bandwidth for a primary link directly connected to the GPU. For atomic
modesetting drivers, checking if there is sufficient link bandwidth for a
mode n
The avail_slots member in the MST topology manager is never updated to
reflect the available vcpi slots. The check is effectively against
total_slots. So, let's make that check obvious. Secondly, since the total
vcpi time slots is always 63 and does not depend on the link BW, remove
total_slots fro
No functional changes. Apparently spec has been changed
the valid table showing 0x192A as Server GT4
while 0x193A is Server GT4e.
Libdrm and Mesa already have this right. So let's fix the ref here.
Kernel is also fixed with commit 5390974f981907.
"drm/i915: Update SKL SRV GT4 pci ids reference."
== Series Details ==
Series: series starting with [1/3] drm/i915: fix INTEL_BDW_IDS definition
URL : https://patchwork.freedesktop.org/series/17445/
State : success
== Summary ==
Series 17445v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/17445/revisions/1/mbox/
On 03/01/17 22:47, Jani Nikula wrote:
On Fri, 23 Dec 2016, norbert wrote:
Hello,
about a year ago there was a discussion about Implementing Miracast on
this list:
https://lists.freedesktop.org/archives/dri-devel/2015-December/096035.html
Since then I could not find further information about t
On Fri, 23 Dec 2016, norbert wrote:
> Hello,
> about a year ago there was a discussion about Implementing Miracast on
> this list:
>
> https://lists.freedesktop.org/archives/dri-devel/2015-December/096035.html
>
> Since then I could not find further information about that topic there.
> So maybe
On Tue, 03 Jan 2017 15:25:24 +0200
Jani Nikula wrote:
> On Tue, 03 Jan 2017, Zhenyu Wang wrote:
> > On 2017.01.02 21:48:57 -0700, Alex Williamson wrote:
> >> > Alex, I liked to have kvmgt related mdev interface change be merged
> >> > through
> >> > vfio tree, but wasn't awared one of Jike's
Reviewed-by: Rodrigo Vivi
On Tue, 2017-01-03 at 18:04 -0200, Paulo Zanoni wrote:
> Commit 8d9c20e1d1e3 ("drm/i915: Remove .is_mobile field from platform
> struct") removed mobile vs desktop differences for HSW+, but forgot
> the Broadwell reserved IDs, so do it now.
>
> It's interesting to noti
Reviewed-by: Rodrigo Vivi
On Tue, 2017-01-03 at 18:04 -0200, Paulo Zanoni wrote:
> Remove duplicated IDs from the list. Currently, this definition is
> only used by early-quirks.c. From my understanding of the code, having
> duplicated IDs shouldn't be causing any bugs.
>
> Fixes: 8d9c20e1d1e3 (
On Tue, 2017-01-03 at 18:04 -0200, Paulo Zanoni wrote:
> Back in 2014, commit fb7023e0e248 ("drm/i915: BDW: Adding Reserved PCI
> IDs.") added the reserved PCI IDs in order to try to make sure we had
> working drivers in case we ever released products using these IDs
> (since we had instances of th
Back in 2014, commit fb7023e0e248 ("drm/i915: BDW: Adding Reserved PCI
IDs.") added the reserved PCI IDs in order to try to make sure we had
working drivers in case we ever released products using these IDs
(since we had instances of this type of problem in the past). The
problem is that the patch
Remove duplicated IDs from the list. Currently, this definition is
only used by early-quirks.c. From my understanding of the code, having
duplicated IDs shouldn't be causing any bugs.
Fixes: 8d9c20e1d1e3 ("drm/i915: Remove .is_mobile field from platform struct")
Cc: Carlos Santa
Cc: Rodrigo Vivi
Commit 8d9c20e1d1e3 ("drm/i915: Remove .is_mobile field from platform
struct") removed mobile vs desktop differences for HSW+, but forgot
the Broadwell reserved IDs, so do it now.
It's interesting to notice that these IDs are used by early-quirks.c
but are *not* used by i915_pci.c.
Cc: Carlos San
== Series Details ==
Series: drm/i915: Update SKL SRV GT4 pci ids reference.
URL : https://patchwork.freedesktop.org/series/17443/
State : success
== Summary ==
Series 17443v1 drm/i915: Update SKL SRV GT4 pci ids reference.
https://patchwork.freedesktop.org/api/1.0/series/17443/revisions/1/mbo
>-Original Message-
>From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
>Sent: Thursday, December 22, 2016 3:30 PM
>To: Srivatsa, Anusha
>Cc: intel-gfx@lists.freedesktop.org; Alex Dai ; Peter Antoine
>
>Subject: Re: [Intel-gfx] [PATCH 7/8] drm/i915/huc: Support HuC authentication
>
>On
On 17-01-03 11:27:52, Rodrigo Vivi wrote:
No functional changes. Apparently spec has been changed
the valid table showing 0x192A as Server GT4
while 0x193A is Server GT4e.
Libdrm and Mesa already have this right. So let's fix the ref here.
Cc: Ben Widawsky
Signed-off-by: Rodrigo Vivi
Reviewe
No functional changes. Apparently spec has been changed
the valid table showing 0x192A as Server GT4
while 0x193A is Server GT4e.
Libdrm and Mesa already have this right. So let's fix the ref here.
Cc: Ben Widawsky
Signed-off-by: Rodrigo Vivi
---
include/drm/i915_pciids.h | 6 +++---
1 file ch
>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Srivatsa, Anusha
>Sent: Monday, January 2, 2017 4:09 PM
>To: Wajdeczko, Michal
>Cc: intel-gfx@lists.freedesktop.org; Alex Dai ; Peter Antoine
>
>Subject: Re: [Intel-gfx] [PATCH 3/8] drm/i9
On Tuesday, 2017-01-03 17:56:10 +0100, Rainer Hochecker wrote:
> On Mon, Jan 2, 2017 at 3:31 PM, Rainer Hochecker wrote:
> >
> > I chose GR16 because that matches with Mesa texture formats. Unfortunately
> > RG16 is already taken by DRM_FORMAT_RGB565
> > So GR32 / RG32 might be better. All other c
>-Original Message-
>From: Wajdeczko, Michal
>Sent: Tuesday, January 3, 2017 6:15 AM
>To: Srivatsa, Anusha
>Cc: intel-gfx@lists.freedesktop.org
>Subject: Re: [Intel-gfx] [PATCH 1/8] drm/i915/guc: Make the GuC fw loading
>helper functions general
>
>On Tue, Jan 03, 2017 at 01:07:14AM +010
Program EDP_PSR_DEBUG_CTL (PSR_MASK) to enable system
to go to deep sleep while in psr2.PSR2_STATUS bit 31:28
should report value 8 , if system enters deep sleep state.
Also, EDP_FRAMES_BEFORE_SU_ENTRY is set 1 , if not set,
flickering is observed on psr2 panel.
v2: (Ilia Mirkin)
- Remove duplica
On Mon, Jan 2, 2017 at 6:31 AM, vathsala nagaraju
wrote:
> Program EDP_PSR_DEBUG_CTL (PSR_MASK) to enable system
> to go to deep sleep while in psr2.PSR2_STATUS bit 31:28
> should report value 8 , if system enters deep sleep state.
>
> Also, EDP_FRAMES_BEFORE_SU_ENTRY is set 1 , if not set,
> flic
On Wed, Dec 21, 2016 at 3:12 PM, Dhinakaran Pandiyan
wrote:
> i915 does not set DRIVER_ATOMIC by default yet but uses atomic_check and
> atomic_commit. drm_object_property_get_value() does not read the correct
> value of atomic properties if DRIVER_ATOMIC is not set. Checking whether
> the driver
After the fence is signaled, the status feed reports whether or not the
request completed successfully. We set this to -EIO if a hang was
detected.
Signed-off-by: Chris Wilson
---
tests/gem_exec_fence.c | 41 +
1 file changed, 41 insertions(+)
diff --git
On Tue, Jan 03, 2017 at 01:07:14AM +0100, Srivatsa, Anusha wrote:
>
>
> >-Original Message-
> >From: Wajdeczko, Michal
> >Sent: Tuesday, December 27, 2016 9:28 AM
> >To: Srivatsa, Anusha
> >Cc: intel-gfx@lists.freedesktop.org; Alex Dai ; Peter
> >Antoine
> >
> >Subject: Re: [Intel-gfx]
HI,
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
> Ander Conselvan De Oliveira
> Sent: Tuesday, January 3, 2017 3:49 PM
> To: Chris Wilson ; Sarvela, Tomi P
> ; Latvala, Petri
> Cc: Vetter, Daniel ; intel-gfx@lists.freedesktop.org
>
On 03/01/2017 11:05, Chris Wilson wrote:
As the fence->status is an optional field that may be set before
dma_fence_signal() is called to convey that the fence completed with an
error, we have to ensure that it is always set to zero on initialisation
so that the typical use (i.e. unset) always f
Empirically we restart more successfully if we call lrc_init_hws()
(which contains a posting read) last. (The failure mode that was
observed was that breadcrumb writes into the HWS from the recovered
request went astray leading to the context-switch maintaining forward
progress, but the requests no
On Tue, Jan 03, 2017 at 03:49:15PM +0200, Ander Conselvan De Oliveira wrote:
> On Tue, 2017-01-03 at 12:26 +0200, Ander Conselvan De Oliveira wrote:
> > On Mon, 2017-01-02 at 14:57 +, Chris Wilson wrote:
> > >
> > > On Mon, Jan 02, 2017 at 03:54:41PM +0200, Ander Conselvan de Oliveira
> > > w
On Tue, 2017-01-03 at 12:26 +0200, Ander Conselvan De Oliveira wrote:
> On Mon, 2017-01-02 at 14:57 +, Chris Wilson wrote:
> >
> > On Mon, Jan 02, 2017 at 03:54:41PM +0200, Ander Conselvan de Oliveira wrote:
> > >
> > >
> > > After commit 1c74eeaf16b8 ("drm/i915: Move number of scalers
> > >
On 03/01/2017 11:59, Chris Wilson wrote:
If we skip before banning, we have an inconsistent interface between
execbuf still queueing valid request but those requests already queued
being cancelled. If we only cancel the pending requests once we stop
accepting new requests, the interface is more
On Tue, 2017-01-03 at 15:35 +0200, Ville Syrjälä wrote:
> On Mon, Jan 02, 2017 at 03:54:41PM +0200, Ander Conselvan de Oliveira wrote:
> >
> > After commit 1c74eeaf16b8 ("drm/i915: Move number of scalers initialization
> > to
> > runtime init"), scalers are not initialized properly for skl and glk
On Mon, Jan 02, 2017 at 03:54:41PM +0200, Ander Conselvan de Oliveira wrote:
> After commit 1c74eeaf16b8 ("drm/i915: Move number of scalers initialization to
> runtime init"), scalers are not initialized properly for skl and glk
> since num_scalers is left as 0 for those platforms.
>
> Fixes: 1c74
On Tue, 03 Jan 2017, Zhenyu Wang wrote:
> On 2017.01.02 21:48:57 -0700, Alex Williamson wrote:
>> > Alex, I liked to have kvmgt related mdev interface change be merged through
>> > vfio tree, but wasn't awared one of Jike's fix had conflict. Could you
>> > apply
>> > below fix in your tree? I thi
On Tue, Jan 03, 2017 at 01:17:19PM +, Tvrtko Ursulin wrote:
>
> On 03/01/2017 12:38, Chris Wilson wrote:
> >On Tue, Jan 03, 2017 at 12:34:16PM +, Tvrtko Ursulin wrote:
> >>
> >>On 03/01/2017 12:13, Chris Wilson wrote:
> >>>On Tue, Jan 03, 2017 at 11:57:44AM +, Tvrtko Ursulin wrote:
> >
On 03/01/2017 12:38, Chris Wilson wrote:
On Tue, Jan 03, 2017 at 12:34:16PM +, Tvrtko Ursulin wrote:
On 03/01/2017 12:13, Chris Wilson wrote:
On Tue, Jan 03, 2017 at 11:57:44AM +, Tvrtko Ursulin wrote:
On 03/01/2017 11:46, Chris Wilson wrote:
On Tue, Jan 03, 2017 at 11:34:45AM +000
On Tue, Jan 03, 2017 at 12:34:16PM +, Tvrtko Ursulin wrote:
>
> On 03/01/2017 12:13, Chris Wilson wrote:
> >On Tue, Jan 03, 2017 at 11:57:44AM +, Tvrtko Ursulin wrote:
> >>
> >>On 03/01/2017 11:46, Chris Wilson wrote:
> >>>On Tue, Jan 03, 2017 at 11:34:45AM +, Tvrtko Ursulin wrote:
> >
On 03/01/2017 12:13, Chris Wilson wrote:
On Tue, Jan 03, 2017 at 11:57:44AM +, Tvrtko Ursulin wrote:
On 03/01/2017 11:46, Chris Wilson wrote:
On Tue, Jan 03, 2017 at 11:34:45AM +, Tvrtko Ursulin wrote:
On 03/01/2017 11:05, Chris Wilson wrote:
The struct dma_fence carries a status f
On Tue, Jan 03, 2017 at 11:57:44AM +, Tvrtko Ursulin wrote:
>
> On 03/01/2017 11:46, Chris Wilson wrote:
> >On Tue, Jan 03, 2017 at 11:34:45AM +, Tvrtko Ursulin wrote:
> >>
> >>On 03/01/2017 11:05, Chris Wilson wrote:
> >>>The struct dma_fence carries a status field exposed to userspace by
On Mon, Jan 02, 2017 at 05:56:51PM +0200, Ville Syrjälä wrote:
> On Mon, Jan 02, 2017 at 03:28:45PM +, Chris Wilson wrote:
> > Ville explained that the wakelock was being acquired during set-idle in
> > order to flush the voltage change from the punit.
> >
> > Signed-off-by: Chris Wilson
> >
If we skip before banning, we have an inconsistent interface between
execbuf still queueing valid request but those requests already queued
being cancelled. If we only cancel the pending requests once we stop
accepting new requests, the interface is more consistent.
Reported-by: Tvrtko Ursulin
Fi
On 03/01/2017 11:46, Chris Wilson wrote:
On Tue, Jan 03, 2017 at 11:34:45AM +, Tvrtko Ursulin wrote:
On 03/01/2017 11:05, Chris Wilson wrote:
The struct dma_fence carries a status field exposed to userspace by
sync_file. This is inspected after the fence is signaled and can convey
whether
== Series Details ==
Series: series starting with [1/2] dma-fence: Clear fence->status during
dma_fence_init()
URL : https://patchwork.freedesktop.org/series/17403/
State : failure
== Summary ==
Series 17403v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/17403/
On Tue, Jan 03, 2017 at 11:34:45AM +, Tvrtko Ursulin wrote:
>
> On 03/01/2017 11:05, Chris Wilson wrote:
> >The struct dma_fence carries a status field exposed to userspace by
> >sync_file. This is inspected after the fence is signaled and can convey
> >whether or not the request completed suc
On 03/01/2017 11:05, Chris Wilson wrote:
The struct dma_fence carries a status field exposed to userspace by
sync_file. This is inspected after the fence is signaled and can convey
whether or not the request completed successfully, or in our case if we
detected a hang during the request (signale
As the fence->status is an optional field that may be set before
dma_fence_signal() is called to convey that the fence completed with an
error, we have to ensure that it is always set to zero on initialisation
so that the typical use (i.e. unset) always flags a successful completion.
Signed-off-by
The struct dma_fence carries a status field exposed to userspace by
sync_file. This is inspected after the fence is signaled and can convey
whether or not the request completed successfully, or in our case if we
detected a hang during the request (signaled via -EIO in
SYNC_IOC_FILE_INFO).
Signed-o
On Mon, 2017-01-02 at 21:19 +0530, Maiti, Nabendu Bikash wrote:
> I am wondering why the number of sprite initialization is not done in
> runtime init for skylake/glk similarly.
It is done in the "else if (INTEL_GEN(dev_priv) >= 5)" branch. The comment
explains why the topmost plane is not enable
On Mon, 2017-01-02 at 14:57 +, Chris Wilson wrote:
> On Mon, Jan 02, 2017 at 03:54:41PM +0200, Ander Conselvan de Oliveira wrote:
> >
> > After commit 1c74eeaf16b8 ("drm/i915: Move number of scalers initialization
> > to
> > runtime init"), scalers are not initialized properly for skl and glk
On 20/12/2016 13:45, Patchwork wrote:
== Series Details ==
Series: drm/i915/guc: Make intel_guc_recv static.
URL : https://patchwork.freedesktop.org/series/17052/
State : success
== Summary ==
Series 17052v1 drm/i915/guc: Make intel_guc_recv static.
https://patchwork.freedesktop.org/api/1.0
On 2017.01.02 21:48:57 -0700, Alex Williamson wrote:
> > Alex, I liked to have kvmgt related mdev interface change be merged through
> > vfio tree, but wasn't awared one of Jike's fix had conflict. Could you apply
> > below fix in your tree? I think in general for possible interface change in
> > f
On Tue, 03 Jan 2017, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the drm-intel-fixes tree got a conflict in:
>
> drivers/gpu/drm/i915/gvt/kvmgt.c
>
> between commit:
>
> 99e3123e3d72 ("vfio-mdev: Make mdev_device private and abstract interfaces")
>
> from the vfio-fixes t
On Mon, Jan 02, 2017 at 04:33:03PM +0200, Ander Conselvan De Oliveira wrote:
> Hi Petri,
>
> I'm not sure what are the i-g-t rules regarding R-b tags nowadays. Does this
> require one or can I push it?
The series is
Reviewed-by: Petri Latvala
Some of the comments got misaligned but that's also
61 matches
Mail list logo
