On Thu, 15 Sep 2016, bobcao3 wrote:
> DRM: i915: Fix gen8 graphics on Broadwell-U. These patches stop the
> random gpu hang on my XPS-13-9343, kernel version 4.8-rc5.
Please do everyone a favor and file a bug on the hangs over at [1],
describing the issue and attaching the error state etc. After
On Wed, Sep 14, 2016 at 11:04:30AM -0400, robert.f...@collabora.com wrote:
> +void sw_sync_timeline_inc(int fd, uint32_t count)
> +{
> + uint32_t arg = count;
> +
> + if (fd == 0)
> + return;
But fd = 0 is a valid fd, and might be a timeline somewhere.
Did you mean count == 0
On Thu, Sep 15, 2016 at 11:12:08AM +0800, bobcao3 wrote:
> Signed-off-by: bobcao3
> ---
> drivers/gpu/drm/i915/i915_gem_gtt.c | 6
> drivers/gpu/drm/i915/i915_gem_stolen.c | 61
> -
> drivers/gpu/drm/i915/i915_reg.h | 6
> drivers/gpu/drm/
I guess it's too late for review now. But, I want to send this anyway.
On Mon, 2016-08-29 at 10:27 +0200, Daniel Vetter wrote:
> - Move missing bits into struct drm_encoder docs.
> - Explain that encoders are 95% internal and only 5% uapi, and that in
> general the uapi part is broken.
> - Remov
== Series Details ==
Series: Prep. for DP audio MST support (rev10)
URL : https://patchwork.freedesktop.org/series/11129/
State : failure
== Summary ==
Series 11129v10 Prep. for DP audio MST support
https://patchwork.freedesktop.org/api/1.0/series/11129/revisions/10/mbox/
Test drv_module_relo
This version of the patch has been included in the series "Prep. for DP
audio MST support" since the helper is used by the patch that stores
port in struct intel_encoder.
On Wed, 2016-09-14 at 14:03 -0700, Dhinakaran Pandiyan wrote:
> Changing the return type from 'char' to 'enum port' in
> intel_
With DP MST, a digital_port can carry more than one audio stream. Hence,
more than one audio_connector needs to be attached to intel_digital_port in
such cases. However, each stream is associated with an unique encoder. So,
instead of creating an array of audio_connectors per port, move
audio_conne
From: Libin Yang
(This patch is developed by Dave Airlie originally)
This patch adds support for DP MST audio in i915.
Enable audio codec when DP MST is enabled if has_audio flag is set.
Disable audio codec when DP MST is disabled if has_audio flag is set.
Another separated patches to support
Changing the return type from 'char' to 'enum port' in
intel_dvo_port_name() makes it easier to later move the port information to
intel_encoder. In addition, the port type conforms to what we have
elsewhere.
Removing the last conditional that handles invalid port because dvo_reg is
intialized to
Now that we have the port enum stored in intel_encoder, use that instead of
dereferencing intel_dig_port. Saves us a few locals.
struct intel_encoder variables have been renamed to be consistent and
convey type information.
v2:
Fix incorrect 'enum port' member names - s/attached_port/port
Signed
Storing the port enum in intel_encoder makes it convenient to know the
port attached to an encoder. Moving the port information up from
intel_digital_port to intel_encoder avoids unecessary intel_digital_port
access and handles MST encoders cleanly without requiring conditional
checks for them (tha
This series lays the groundwork for more DP MST audio work that will
follow.
v2:
Different solution replacing the enc_to_dig_port() fix (Ville, Lyude).
No changes to MST audio enabling and move audio_connector patches.
Reordered the patches (Lyude)
v3:
Different solution to get port from encoder
== Series Details ==
Series: drm/i915: Standardize port type for DVO encoders (rev2)
URL : https://patchwork.freedesktop.org/series/12418/
State : failure
== Summary ==
Series 12418v2 drm/i915: Standardize port type for DVO encoders
https://patchwork.freedesktop.org/api/1.0/series/12418/revisi
Changing the return type from 'char' to 'enum port' in
intel_dvo_port_name() makes it easier to later move the port information to
intel_encoder. In addition, the port type conforms to what we have
elsewhere.
Removing the last conditional that handles invalid port because dvo_reg is
intialized to
Em Qua, 2016-09-14 às 13:10 +0100, Dave Gordon escreveu:
> Commentary from Chris Wilson's original version:
>
> >
> > I was looking at some wait_for() timeouts on a slow system, with
> > lots of
> > debug enabled (KASAN, lockdep, mmio_debug). Thinking that we were
> > mishandling the timeout, I t
== Series Details ==
Series: drm/i915: Queue page flip work with high priority (rev2)
URL : https://patchwork.freedesktop.org/series/12336/
State : failure
== Summary ==
Series 12336v2 drm/i915: Queue page flip work with high priority
https://patchwork.freedesktop.org/api/1.0/series/12336/revi
On Wed, Sep 14, 2016 at 12:44:04PM +0300, Joonas Lahtinen wrote:
> On ke, 2016-09-14 at 07:52 +0100, Chris Wilson wrote:
> > -static inline bool
> > -i915_gem_object_has_active_engine(const struct drm_i915_gem_object *obj,
> > - int engine)
> > -{
> > - return obj->fla
On Wed, Sep 14, 2016 at 02:30:20PM +0100, Tvrtko Ursulin wrote:
>
> On 14/09/2016 07:52, Chris Wilson wrote:
> >In the next patch, we will use deferred request emission. That requires
> >reserving sufficient space in the ringbuffer to emit the request, which
> >first requires us to know how large
While user space has control over the scheduling priority of its page
flipping thread, the corresponding work the driver schedules for MMIO
flips always runs from the generic system workqueue which has some
scheduling overhead due it being CPU bound. This would hinder an
application that wants more
On 14/09/16 16:22, Tvrtko Ursulin wrote:
On 12/09/2016 21:19, Dave Gordon wrote:
Renaming to more consistent scheme, and updating comments, mostly
about i915_guc_wq_reserve(), aka i915_guc_wq_check_space().
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_guc_submission.c | 63
+
== Series Details ==
Series: Enable i915 perf stream for Haswell OA unit (rev4)
URL : https://patchwork.freedesktop.org/series/11295/
State : failure
== Summary ==
Series 11295v4 Enable i915 perf stream for Haswell OA unit
https://patchwork.freedesktop.org/api/1.0/series/11295/revisions/4/mbox
On ke, 2016-09-14 at 07:52 +0100, Chris Wilson wrote:
> i915_next_seqno_get(void *data, u64 *val)
> {
> struct drm_i915_private *dev_priv = data;
> - int ret;
> -
> - ret = mutex_lock_interruptible(&dev_priv->drm.struct_mutex);
> - if (ret)
> - return ret;
> -
> -
Adds base i915 perf infrastructure for Gen performance metrics.
This adds a DRM_IOCTL_I915_PERF_OPEN ioctl that takes an array of uint64
properties to configure a stream of metrics and returns a new fd usable
with standard VFS system calls including read() to read typed and sized
records; ioctl()
On 12/09/2016 21:19, Dave Gordon wrote:
Renaming to more consistent scheme, and updating comments, mostly
about i915_guc_wq_reserve(), aka i915_guc_wq_check_space().
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_guc_submission.c | 63 +++---
drivers/gpu/dr
== Series Details ==
Series: drm/i915: introduce & use i915_gem_object_{set, clear, is}_dirty()
(rev2)
URL : https://patchwork.freedesktop.org/series/12262/
State : failure
== Summary ==
Series 12262v2 drm/i915: introduce & use i915_gem_object_{set, clear,
is}_dirty()
https://patchwork.freed
On 12/09/2016 21:19, Dave Gordon wrote:
Renaming to more consistent scheme, delete unused definitions
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_guc_reg.h | 3 ---
drivers/gpu/drm/i915/intel_guc_loader.c | 27 ---
2 files changed, 16 insertions(+)
On 12/09/2016 21:19, Dave Gordon wrote:
No functional changes; just renaming a bit, tweaking a datatype,
prettifying layout, and adding comments, in particular in the
GuC setup code that touches this data.
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
driver
From: Robert Foss
This subtest runs a single consumer thread and multiple producer thread that
are synchronized using multiple timelines.
Signed-off-by: Robert Foss
Reviewed-by: Eric Engestrom
---
tests/sw_sync.c | 139
1 file changed,
From: Robert Foss
This subtests tests that creating fences on negative timelines fail.
Signed-off-by: Robert Foss
Reviewed-by: Eric Engestrom
---
tests/sw_sync.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index 8f6208b..75bd471 100644
--- a/te
From: Robert Foss
This subtest verifies that waiting, timing out on a wait and that counting
fences in various states works.
Signed-off-by: Robert Foss
Reviewed-by: Eric Engestrom
---
tests/sw_sync.c | 66 +
1 file changed, 66 insertions
From: Robert Foss
This subtest verifies merging a fence with itself does not fail.
Signed-off-by: Robert Foss
Reviewed-by: Eric Engestrom
---
tests/sw_sync.c | 37 -
1 file changed, 32 insertions(+), 5 deletions(-)
diff --git a/tests/sw_sync.c b/tests/sw_s
From: Robert Foss
This subtest verifies the access ordering of multiple consumer threads.
Signed-off-by: Robert Foss
Reviewed-by: Eric Engestrom
---
tests/sw_sync.c | 103
1 file changed, 103 insertions(+)
diff --git a/tests/sw_sync.c
From: Robert Foss
This subtest verifies that creating many timelines and merging random fences
from each timeline with eachother results in merged fences that are fully
functional.
Signed-off-by: Robert Foss
Reviewed-by: Eric Engestrom
---
tests/sw_sync.c | 73
From: Robert Foss
Add subtest test_sync_merge that tests merging fences and the validity of the
resulting merged fence.
Signed-off-by: Robert Foss
Reviewed-by: Eric Engestrom
---
tests/sw_sync.c | 67 +
1 file changed, 67 insertions(+)
From: Robert Foss
Add subtest alloc_fence that verifies that it's possible to allocate a fence
on a timeline.
Signed-off-by: Robert Foss
Reviewed-by: Eric Engestrom
---
tests/sw_sync.c | 16
1 file changed, 16 insertions(+)
diff --git a/tests/sw_sync.c b/tests/sw_sync.c
inde
From: Robert Foss
Base functions to help testing the Sync File Framework (explicit fencing
mechanism ported from Android).
These functions allow you to create, use and destroy timelines and fences.
Signed-off-by: Robert Foss
Signed-off-by: Gustavo Padovan
Reviewed-by: Eric Engestrom
---
lib/
From: Robert Foss
Add initial tests for sw_sync.
Signed-off-by: Robert Foss
Signed-off-by: Gustavo Padovan
Reviewed-by: Eric Engestrom
---
tests/Makefile.sources | 1 +
tests/sw_sync.c| 52 ++
2 files changed, 53 insertions(+)
create
From: Robert Foss
This test verifies that stressing the kernel by creating multiple
consumer/producer threads that wait on a single timeline to be incremented
by another conumer/producer thread does not fail.
And that the order amongst the threads is maintained.
Signed-off-by: Robert Foss
Revie
From: Robert Foss
This subtest verifies that merging two fences works in the simples possible
case.
Signed-off-by: Robert Foss
Reviewed-by: Eric Engestrom
---
tests/sw_sync.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index 7
From: Robert Foss
This subtest verifies that waiting on fences works properly.
Signed-off-by: Robert Foss
Reviewed-by: Eric Engestrom
---
tests/sw_sync.c | 38 ++
1 file changed, 38 insertions(+)
diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index fcb2f57
From: Robert Foss
s series implements the sw_sync test and the lib/sw_sync helper functions for
said test.
Gustavo Padovans sw_sync series was just de-staged in
gregkh-staging/staging-next [1], and this test is targeted at verifying the
functionality implemented in that series.
The sw_sync subt
On Wed, Sep 14, 2016 at 3:42 PM, Emil Velikov
wrote:
> Hi Robert,
>
> I think I've spotted one interesting, yet trivial bit.
>
> On 14 September 2016 at 15:19, Robert Bragg wrote:
> > Adds base i915 perf infrastructure for Gen performance metrics.
> >
> > This adds a DRM_IOCTL_I915_PERF_OPEN ioc
On 2016-09-14 08:18 AM, Chris Wilson wrote:
On Tue, Sep 13, 2016 at 11:40:18AM -0400, Robert Foss wrote:
On 2016-09-13 07:03 AM, Chris Wilson wrote:
Try:
int __sw_sync_fence_create(int fd, int32_t seqno) /* int32_t not unsigned ? */
{
struct sw_sync_create_fence_data data;
== Series Details ==
Series: Enable i915 perf stream for Haswell OA unit (rev3)
URL : https://patchwork.freedesktop.org/series/11295/
State : failure
== Summary ==
Series 11295v3 Enable i915 perf stream for Haswell OA unit
https://patchwork.freedesktop.org/api/1.0/series/11295/revisions/3/mbox
This just hides the existing obj->dirty flag inside a trivial inline
setter, to discourage non-GEM code from looking too closely. The
flag is renamed to emphasise that it is private to the GEM memory-
management code and ensure that no legacy code continues to use it
directly.
v2:
Use Chris Wilson
Hi Robert,
I think I've spotted one interesting, yet trivial bit.
On 14 September 2016 at 15:19, Robert Bragg wrote:
> Adds base i915 perf infrastructure for Gen performance metrics.
>
> This adds a DRM_IOCTL_I915_PERF_OPEN ioctl that takes an array of uint64
> properties to configure a stream o
On 12/09/16 16:48, Tvrtko Ursulin wrote:
Hi,
On 09/09/16 20:48, Dave Gordon wrote:
This just hides the existing obj->dirty flag inside a trivial inline
setter, to discourage non-GEM code from looking too closely. The
flag is renamed to emphasise that it is private to the GEM memory-
management
Changes in v2:
- Split per-driver
- Remove i915_driver_open()
- Fix dce_virtual_hw_init() as well
Masahiro Yamada (5):
drm/amdgpu: squash lines for simple wrapper functions
drm/radeon: squash lines for simple wrapper functions
drm/bridge: squash lines for simple wrapper functions
drm
i915_driver_open() is equivalent to i915_gem_open(). Replace the
i915_driver_open with the direct use of i915_gem_open().
Signed-off-by: Masahiro Yamada
---
drivers/gpu/drm/i915/i915_drv.c | 13 +
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/i9
check_cmd() is checking whether a command adheres to certain
restrictions that ensure it's safe to execute within a privileged batch
buffer. Returning false implies a privilege problem, not that the
command is invalid.
The distinction makes the difference between allowing the buffer to be
executed
Gen graphics hardware can be set up to periodically write snapshots of
performance counters into a circular buffer via its Observation
Architecture and this patch exposes that capability to userspace via the
i915 perf interface.
Cc: Chris Wilson
Signed-off-by: Robert Bragg
Signed-off-by: Zhenyu
This adds 'compute', 'compute extended', 'memory reads', 'memory writes'
and 'sampler balance' metric sets for Haswell.
The code is auto generated from an XML description of metric sets,
currently maintained in gputop, ref:
https://github.com/rib/gputop
> gputop-data/oa-*.xml
> scripts/i915-pe
Each metric set is given a sysfs entry like:
/sys/class/drm/card0/metrics//id
This allows userspace to enumerate the specific sets that are available
for the current system. The 'id' file contains an unsigned integer that
can be used to open the associated metric set via
DRM_IOCTL_I915_PERF_OPEN.
Consistent with the kernel.perf_event_paranoid sysctl option that can
allow non-root users to access system wide cpu metrics, this can
optionally allow non-root users to access system wide OA counter metrics
from Gen graphics hardware.
Signed-off-by: Robert Bragg
---
drivers/gpu/drm/i915/i915_dr
The minimal sampling period is now configurable via a
dev.i915.oa_min_timer_exponent sysctl parameter.
Following the precedent set by perf, the default is the minimum that
won't (on its own) exceed the default kernel.perf_event_max_sample_rate
default of 10 samples/s.
Signed-off-by: Robert Br
Adds a static OA unit, MUX + B Counter configuration for basic render
metrics on Haswell. This is auto generated from an XML
description of metric sets, currently maintained in gputop, ref:
https://github.com/rib/gputop
> gputop-data/oa-*.xml
> scripts/i915-perf-kernelgen.py
$ make -C gpu
In particular this tries to capture for posterity some of the early
challenges we had with using the core perf infrastructure in case we
ever want to revisit adapting perf for device metrics.
Cc: Chris Wilson
Signed-off-by: Robert Bragg
---
drivers/gpu/drm/i915/i915_perf.c | 163 +++
Being able to program OACONTROL from a non-privileged batch buffer is
not sufficient to be able to configure the OA unit. This was originally
allowed to help enable Mesa to expose OA counters via the
INTEL_performance_query extension, but the current implementation based
on programming OACONTROL vi
OACONTROL changes quite a bit for gen8, with some bits split out into a
per-context OACTXCONTROL register. Rename now before adding more gen7 OA
registers
Signed-off-by: Robert Bragg
---
drivers/gpu/drm/i915/i915_cmd_parser.c | 4 ++--
drivers/gpu/drm/i915/i915_reg.h| 2 +-
2 files chang
This just rebases my i915 perf series on a recent drm-intel-nightly.
Considering now that this series has been reviewed a number of times by Chris,
and I think I've responded to his feedback: I wonder if this series is ready
to be added to drm-intel-nightly soon?
I think most of the effort for th
Adds base i915 perf infrastructure for Gen performance metrics.
This adds a DRM_IOCTL_I915_PERF_OPEN ioctl that takes an array of uint64
properties to configure a stream of metrics and returns a new fd usable
with standard VFS system calls including read() to read typed and sized
records; ioctl()
Em Qua, 2016-09-14 às 10:22 +0100, Chris Wilson escreveu:
> On Tue, Sep 13, 2016 at 08:40:19PM +0100, Chris Wilson wrote:
> >
> > I was looking at some wait_for() timeouts on a slow system, with
> > lots of
> > debug enabled (KASAN, lockdep, mmio_debug). Thinking that we were
> > mishandling the t
Em Qua, 2016-09-14 às 12:59 +0300, Jani Nikula escreveu:
> On Tue, 13 Sep 2016, "Zanoni, Paulo R"
> wrote:
> >
> > I got confirmation from the Hardware guys that KBL does need to run
> > the
> > SAGV code, and it has the same latency as SKL. Also, all SKL
> > production
> > steppings need to run
On 14/09/2016 07:52, Chris Wilson wrote:
In the next patch, we will use deferred request emission. That requires
reserving sufficient space in the ringbuffer to emit the request, which
first requires us to know how large the request is.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i9
Em Qua, 2016-09-14 às 12:34 +0300, Jani Nikula escreveu:
> On Wed, 14 Sep 2016, Paulo Zanoni wrote:
> >
> > Hi
> >
> > Here's the series with the reviews implemented. There's a new
> > patch,
> > based on the additional issue spotted by Lyude.
>
> There's a bunch of cc: stable patches mixed wit
== Series Details ==
Series: drm/i915: Only expand COND once in wait_for() (rev2)
URL : https://patchwork.freedesktop.org/series/12403/
State : failure
== Summary ==
Series 12403v2 drm/i915: Only expand COND once in wait_for()
https://patchwork.freedesktop.org/api/1.0/series/12403/revisions/2/
On 14/09/16 13:32, Dave Gordon wrote:
On 13/09/16 10:10, Jani Nikula wrote:
On Sat, 10 Sep 2016, Dave Gordon wrote:
Thanks, the other things I was thinking of fixing in the remaining files
were generally things like
if (INTEL_INFO(dev)->gen < 5 || IS_G33(dev))
Is that a real or a made up
Hi,
There was an issue with transition WM, it was getting enabled & causing
fifo underrun.
I fixed the condition, After that tested kms_plane & not getting any
underrun.
Please let me know if you see any other issue.
Regards,
-Mahesh
On Tuesday 13 September 2016 06:10 PM, Maarten Lankhorst wr
On 13/09/16 10:10, Jani Nikula wrote:
On Sat, 10 Sep 2016, Dave Gordon wrote:
Thanks, the other things I was thinking of fixing in the remaining files
were generally things like
if (INTEL_INFO(dev)->gen < 5 || IS_G33(dev))
Is that a real or a made up example? IS_G33() would be redundant.
On Tue, Sep 13, 2016 at 11:40:18AM -0400, Robert Foss wrote:
>
>
> On 2016-09-13 07:03 AM, Chris Wilson wrote:
> >Try:
> >
> >int __sw_sync_fence_create(int fd, int32_t seqno) /* int32_t not unsigned ?
> >*/
> >{
> >
> > struct sw_sync_create_fence_data data;
> >
> > memset(&data, 0, siz
Commentary from Chris Wilson's original version:
> I was looking at some wait_for() timeouts on a slow system, with lots of
> debug enabled (KASAN, lockdep, mmio_debug). Thinking that we were
> mishandling the timeout, I tried to ensure that we loop at least once
> after first testing COND. Howeve
From: Mahesh Kumar
This patch enables Transition WM for SKL+ platforms.
Transition WM are used if IPC is enabled, to decide, number of blocks
to be fetched before reducing the priority of display to fetch from
memory.
Changes since v1:
- Don't enable transition WM for GEN9 (Art/Paulo)
- Rebas
Am Mittwoch, 14. September 2016, 12:17:53 CEST schrieb Jani Nikula:
> On Wed, 14 Sep 2016, Pavel Machek wrote:
> > For the "sometimes need xrandr after resume": I don't think I can
> > bisect that. It only happens sometimes :-(. But there's something
> > helpful in the logs:
> >
> > [ 1856.218863
On Wed, 14 Sep 2016, Jani Nikula wrote:
> On Wed, 14 Sep 2016, Pavel Machek wrote:
>> For the "sometimes need xrandr after resume": I don't think I can
>> bisect that. It only happens sometimes :-(. But there's something
>> helpful in the logs:
>
>> [ 1856.218863] [drm:drm_edid_block_valid] *ERRO
On ti, 2016-09-13 at 12:12 +0100, Tvrtko Ursulin wrote:
> On 13/09/16 11:31, Imre Deak wrote:
> > On ti, 2016-09-13 at 11:24 +0100, Tvrtko Ursulin wrote:
> > > On 12/09/16 15:09, Imre Deak wrote:
> > > > While user space has control over the scheduling priority of
> > > > its
> > > > page
> > > > f
== Series Details ==
Series: drm/i915: Unlock PPS registers after GPU reset
URL : https://patchwork.freedesktop.org/series/12446/
State : success
== Summary ==
Series 12446v1 drm/i915: Unlock PPS registers after GPU reset
https://patchwork.freedesktop.org/api/1.0/series/12446/revisions/1/mbox/
On Tue, Sep 13, 2016 at 11:04:37PM +0200, Pavel Machek wrote:
> Hi!
>
> > I have
> >
> > 00:02.0 VGA compatible controller: Intel Corporation 4 Series Chipset
> > Integrated Graphics Controller (rev 03)
> >
> > In previous kernels, resume worked ok. With 4.8-rc1, I quite often (1
> > in 10 resum
Reapply the PPS register unlock workaround after GPU reset on platforms
where the reset clobbers the display HW state. This at least gets rid of
the related WARN during LVDS encoder enabling on PNV.
Fixes: ed6143b8f75 ("drm/i915/lvds: Restore initial HW state during encoder
enabling")
Reported-by
On Wed, 14 Sep 2016, Pavel Machek wrote:
> Intel folks, any ideas? Can you reproduce it?
It's possible (but not confirmed yet) we've seen this in our CI, but has
slipped through because it's sporadic.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
__
On Tue, 13 Sep 2016, "Zanoni, Paulo R" wrote:
> I got confirmation from the Hardware guys that KBL does need to run the
> SAGV code, and it has the same latency as SKL. Also, all SKL production
> steppings need to run the SAGV code.
Can you get confirmation what's the first shipped production ste
On ke, 2016-09-14 at 07:52 +0100, Chris Wilson wrote:
> In preparation to support many distinct timelines, we need to expand the
> activity tracking on the GEM object to handle more than just a request
> per engine. We already use the struct reservation_object on the dma-buf
> to handle many fence
On Mon, 20 Jun 2016, James Bottomley
wrote:
> On Fri, 2016-06-17 at 16:06 -0700, James Bottomley wrote:
>> On Fri, 2016-06-17 at 16:34 +0300, Jani Nikula wrote:
>> > On Fri, 17 Jun 2016, Daniel Vetter wrote:
>> > > On Thu, Jun 16, 2016 at 03:42:12PM -0700, James Bottomley wrote:
>> > > > On Thu,
On Mon, 29 Aug 2016, Sean Greenslade wrote:
> In investigating the issue myself, I discovered that the root of the
> problem seemed to be that the new code for getting the panel type from
> the opregion seems to believe it is getting good data, but it is not.
> The function intel_opregion_get_pane
On Wed, 14 Sep 2016, Paulo Zanoni wrote:
> Hi
>
> Here's the series with the reviews implemented. There's a new patch,
> based on the additional issue spotted by Lyude.
There's a bunch of cc: stable patches mixed with non cc: stable patches
in the series. Do the cc: stable fixes work and backport
On Wed, 14 Sep 2016, Dhinakaran Pandiyan wrote:
> Changing the return type from 'char' to 'enum port' in
> intel_dvo_port_name() makes it easier to later move the port information to
> intel_encoder. In addition, the port type conforms to what we have
> elsewhere.
>
> Removing the last conditional
On Tue, Sep 13, 2016 at 08:40:19PM +0100, Chris Wilson wrote:
> I was looking at some wait_for() timeouts on a slow system, with lots of
> debug enabled (KASAN, lockdep, mmio_debug). Thinking that we were
> mishandling the timeout, I tried to ensure that we loop at least once
> after first testing
On Wed, 14 Sep 2016, Pavel Machek wrote:
> For the "sometimes need xrandr after resume": I don't think I can
> bisect that. It only happens sometimes :-(. But there's something
> helpful in the logs:
> [ 1856.218863] [drm:drm_edid_block_valid] *ERROR* EDID checksum is
> invalid, remainder is 130
== Series Details ==
Series: series starting with [01/18] drm/i915: Support asynchronous waits on
struct fence from i915_gem_request
URL : https://patchwork.freedesktop.org/series/12433/
State : failure
== Summary ==
Series 12433v1 Series without cover letter
https://patchwork.freedesktop.org
== Series Details ==
Series: drm/i915: Add ddb size field to device info structure (rev2)
URL : https://patchwork.freedesktop.org/series/12427/
State : success
== Summary ==
Series 12427v2 drm/i915: Add ddb size field to device info structure
https://patchwork.freedesktop.org/api/1.0/series/12
On ke, 2016-09-14 at 07:52 +0100, Chris Wilson wrote:
> Since we only use the more generic unlocked variant, just rename it as
> the normal i915_gem_active_wait(). The temporary cost is that we need to
> always acquire the reference in a RCU safe manner, but the benefit is
> that we will combine th
On ke, 2016-09-14 at 07:52 +0100, Chris Wilson wrote:
> +int
> +i915_gem_object_wait(struct drm_i915_gem_object *obj,
> + unsigned int flags,
> + long timeout,
> + struct intel_rps_client *rps)
> {
>
[...]
> - return 0;
> + resv = i915
On Wed, Sep 14, 2016 at 10:51:12AM +0300, Joonas Lahtinen wrote:
> On ke, 2016-09-14 at 07:52 +0100, Chris Wilson wrote:
> > @@ -678,7 +678,7 @@ void __i915_add_request(struct drm_i915_gem_request
> > *request, bool flush_caches)
> > &request->i915->drm.struct_mutex)
On Tue, Sep 13, 2016 at 03:21:48PM +0300, Mika Kuoppala wrote:
> Mika Kuoppala writes:
> > "Zanoni, Paulo R" writes:
> >>> +#if IS_ENABLED(CONFIG_LOCKDEP)
> >>> + GEM_BUG_ON(!!lockdep_is_held(&req->i915->drm.struct_mutex)
> >>> !=
> >>> + !!(flags & I915_WAIT_LOCKED));
> >>> +#endif
>
On 13 September 2016 at 10:22, wrote:
> From: Ville Syrjälä
>
> Turns out
> commit a05628195a0d ("drm/i915: Get panel_type from OpRegion panel
> details") has regressed quite a few machines. So it looks like we
> can't use the panel type from OpRegion on all systems, and yet we
> absolutely must
Adding the ddb size into the devide info will avoid
platform checks while computing wm.
v2: Added comment and WARN_ON if ddb size is zero.(Jani)
Suggested-by: Ander Conselvan de Oliveira
Signed-off-by: Deepak M
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_pci.c | 5 +
On Tue, 2016-09-13 at 18:08 -0700, Manasi Navare wrote:
> According to the DisplayPort Spec, in case of Clock Recovery failure
> the link training sequence should fall back to the lower link rate
> followed by lower lane count until CR succeeds.
> On CR success, the sequence proceeds with Channel E
On Wed, 14 Sep 2016, Deepak M wrote:
> Adding the ddb size into the devide info will avoid
> platform checks while computing wm.
>
> Suggested-by: Ander Conselvan de Oliveira
>
> Signed-off-by: Deepak M
> ---
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> drivers/gpu/drm/i915/i915_pci.c | 5
On Wed 2016-09-14 10:38:18, Jani Nikula wrote:
> On Wed, 14 Sep 2016, Pavel Machek wrote:
> > Hi!
> >
> >> I have
> >>
> >> 00:02.0 VGA compatible controller: Intel Corporation 4 Series Chipset
> >> Integrated Graphics Controller (rev 03)
> >>
> >> In previous kernels, resume worked ok. With 4.8
On ke, 2016-09-14 at 07:52 +0100, Chris Wilson wrote:
> @@ -678,7 +678,7 @@ void __i915_add_request(struct drm_i915_gem_request
> *request, bool flush_caches)
> &request->i915->drm.struct_mutex);
> if (prev)
> i915_sw_fence_await_sw_fence(&reque
On Wed, 14 Sep 2016, Jani Nikula wrote:
> On Wed, 14 Sep 2016, Pavel Machek wrote:
>> Hi!
>>
>>> I have
>>>
>>> 00:02.0 VGA compatible controller: Intel Corporation 4 Series Chipset
>>> Integrated Graphics Controller (rev 03)
>>>
>>> In previous kernels, resume worked ok. With 4.8-rc1, I quite
1 - 100 of 104 matches
Mail list logo
