Chris Wilson writes:
> When capturing the bo, we allocate an array for min(vma->size,
> vma->node.size) pages, plus a bit for compression overhead. Through my
> and CI testing, this was sufficient for the mostly empty NULL context as
> it compressed well (or the out-of-bounds access simply didn't
On Friday 01 December 2017 01:06 PM, Daniel Vetter wrote:
On Fri, Dec 01, 2017 at 12:53:31PM +0530, Ramalingam C wrote:
Sean,
IMHO, it will good if we can have all generic hdcp1.4 authentication flow in
drm helpers and all interested display drivers to use them.
This Design will make the ext
Patchwork writes:
> == Series Details ==
>
> Series: series starting with [CI,1/3] drm/i915: Introduce execlist_port_*
> accessors
> URL : https://patchwork.freedesktop.org/series/34685/
> State : failure
>
> == Summary ==
>
> Series 34685v1 series starting with [CI,1/3] drm/i915: Introduce
>
Quoting Mika Kuoppala (2017-12-01 08:28:45)
> Chris Wilson writes:
>
> > When capturing the bo, we allocate an array for min(vma->size,
> > vma->node.size) pages, plus a bit for compression overhead. Through my
> > and CI testing, this was sufficient for the mostly empty NULL context as
> > it co
Chris Wilson writes:
> If the HW is already wedged, attempting to submit a request will
> generate an -EIO. If we tried this during suspend, we would abort
> whereas all we want to do is to go sleep and throw away the corrupt
> state.
>
> Fixes: 5ab57c702069 ("drm/i915: Flush logical context imag
Quoting Patchwork (2017-12-01 01:39:53)
> == Series Details ==
>
> Series: drm/i915: Set fake_vma.size as well as fake_vma.node.size for capture
> URL : https://patchwork.freedesktop.org/series/34717/
> State : success
>
> == Summary ==
>
> Test kms_frontbuffer_tracking:
> Subgroup fbc
Quoting Mika Kuoppala (2017-12-01 09:16:10)
> Chris Wilson writes:
>
> > If the HW is already wedged, attempting to submit a request will
> > generate an -EIO. If we tried this during suspend, we would abort
> > whereas all we want to do is to go sleep and throw away the corrupt
> > state.
> >
>
On 01/12/2017 01:01, Rodrigo Vivi wrote:
On Tue, Nov 21, 2017 at 06:18:45PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
From: Chris Wilson
From: Tvrtko Ursulin
From: Dmitry Rogozhkin
The first goal is to be able to measure GPU (and invidual ring) busyness
without having to poll regi
Doing GuC firmware path selection from sanitize_options function
is not perfect, while there is no problem with doing so during
early init stage as we already have all needed data.
Signed-off-by: Michal Wajdeczko
Cc: Chris Wilson
Cc: Joonas Lahtinen
Cc: Sagar Arun Kamble
---
drivers/gpu/drm/i
Our new "enable_guc" modparam allows to control whenever HuC
should be loaded. However existing code will try load and
authenticate HuC always when we use the GuC. This patch is
trying to enforce modparam selection.
Signed-off-by: Michal Wajdeczko
Cc: Chris Wilson
Cc: Joonas Lahtinen
Cc: Sagar
In the upcoming patch we will change the way how to recognize
when GuC is in use. Using helper macros will minimize scope
of that changes. While here, update dev_info message.
Signed-off-by: Michal Wajdeczko
Cc: Chris Wilson
Cc: Joonas Lahtinen
Cc: Sagar Arun Kamble
---
drivers/gpu/drm/i915/i
Doing HuC firmware path selection from sanitize_options function
is not perfect, while there is no problem with doing so during
early init stage as we already have all needed data.
Signed-off-by: Michal Wajdeczko
Cc: Chris Wilson
Cc: Joonas Lahtinen
Cc: Sagar Arun Kamble
---
drivers/gpu/drm/i
-EIO has special meaning and is used when we want to allow
engine initialization to fail and mark GPU as wedged.
Missing firmware does not fit into this scenario as this is
permanent error not related to GPU condition.
Signed-off-by: Michal Wajdeczko
Cc: Chris Wilson
Cc: Joonas Lahtinen
Cc: Sag
Also revert ("drm/i915/guc: Assert that we switch between
known ggtt->invalidate functions")
v2: don't enable GuC on GLK
Signed-off-by: Michal Wajdeczko
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 8 ++--
drivers/gpu/drm/i915/i915_params.h | 2 +-
drivers/gpu/drm/i915/intel_uc.c | 2 ++
Chris Wilson writes:
> For in-flight-suspend, we need to wait for the GPU hang within
> i915_gem_suspend(). This will take 10-20s, which means that the standard
> wakeup delay of around 15s may occur before we complete the suspend.
> This causes a pm_system_wakeup(), causing dpm_suspend() to retu
We currently have two module parameters that control GuC:
"enable_guc_loading" and "enable_guc_submission". Whenever
we need submission=1, we also need loading=1. We also need
loading=1 when we want to want to load and verify the HuC.
Lets combine above module parameters into one "enable_guc"
modp
For in-flight-suspend, we need to wait for the GPU hang within
i915_gem_suspend(). This will take 10-20s, which means that the standard
wakeup delay of around 15s may occur before we complete the suspend.
This causes a pm_system_wakeup(), causing dpm_suspend() to return
-EBUSY.
Signed-off-by: Chri
Chris Wilson writes:
> To execute a requests requires us to have first woken the device, using
> the rpm wakeref (as the request needs to write to hardware to setup the
> context/ppGTT and execute on the GPU). So call intel_runtime_pm_get()
> around queuing the request; the request itself will th
Quoting Mika Kuoppala (2017-12-01 10:40:24)
> Chris Wilson writes:
>
> > To execute a requests requires us to have first woken the device, using
> > the rpm wakeref (as the request needs to write to hardware to setup the
> > context/ppGTT and execute on the GPU). So call intel_runtime_pm_get()
>
== Series Details ==
Series: series starting with [v2,1/7] drm/i915/huc: Move firmware selection to
init_early
URL : https://patchwork.freedesktop.org/series/34738/
State : warning
== Summary ==
Series 34738v1 series starting with [v2,1/7] drm/i915/huc: Move firmware
selection to init_early
A new context assumes that all of its registers are in the default state
when it is created. What may happen is that a register written by one
context may leak into the second, causing mass confusion.
v2: Extend back to Sandybridge (etc)
v3: Check context preserves registers across suspend/hiberna
It has been many years since the last confirmed sighting (and fix) of an
RC6 related bug (usually a system hang). Remove the parameter to stop
users from setting dangerous values, as they often set it during triage
and end up disabling the entire runtime pm instead (the option is not a
fine scalpel
== Series Details ==
Series: drm/i915: Remove unsafe i915.enable_rc6 (rev4)
URL : https://patchwork.freedesktop.org/series/21884/
State : success
== Summary ==
Series 21884v4 drm/i915: Remove unsafe i915.enable_rc6
https://patchwork.freedesktop.org/api/1.0/series/21884/revisions/4/mbox/
fi-bd
== Series Details ==
Series: igt/gem_eio: Increase wakeup delay for in-flight-suspend (rev2)
URL : https://patchwork.freedesktop.org/series/34691/
State : failure
== Summary ==
Series 34691 revision 2 was fully merged or fully failed: no git log
___
As we declare the GPU wedged if the reset fails, such a failure is quite
terminal. Before taking that drastic action, let's sleep first and try
active, in the hope that the hardware has quietened down and is then
able to reset. After a few such attempts, it is fair to say that the HW
is truly wedge
Quoting Chris Wilson (2017-12-01 12:12:40)
> As we declare the GPU wedged if the reset fails, such a failure is quite
> terminal. Before taking that drastic action, let's sleep first and try
> active, in the hope that the hardware has quietened down and is then
> able to reset. After a few such att
As we declare the GPU wedged if the reset fails, such a failure is quite
terminal. Before taking that drastic action, let's sleep first and try
active, in the hope that the hardware has quietened down and is then
able to reset. After a few such attempts, it is fair to say that the HW
is truly wedge
Quoting Michal Wajdeczko (2017-12-01 10:33:11)
> Doing HuC firmware path selection from sanitize_options function
> is not perfect, while there is no problem with doing so during
> early init stage as we already have all needed data.
>
> Signed-off-by: Michal Wajdeczko
> Cc: Chris Wilson
> Cc: J
== Series Details ==
Series: igt/gem_ctx_isolation: Check isolation of registers between contexts
(rev9)
URL : https://patchwork.freedesktop.org/series/32531/
State : success
== Summary ==
IGT patchset tested on top of latest successful build
476c4b462e0453c70ee81664c0227fdddc26cbd0 igt/gem_e
Quoting Michal Wajdeczko (2017-12-01 10:33:12)
> Doing GuC firmware path selection from sanitize_options function
> is not perfect, while there is no problem with doing so during
> early init stage as we already have all needed data.
>
> Signed-off-by: Michal Wajdeczko
> Cc: Chris Wilson
> Cc: J
Quoting Michal Wajdeczko (2017-12-01 10:33:13)
> In the upcoming patch we will change the way how to recognize
> when GuC is in use. Using helper macros will minimize scope
> of that changes. While here, update dev_info message.
>
> Signed-off-by: Michal Wajdeczko
> Cc: Chris Wilson
> Cc: Joonas
Quoting Michal Wajdeczko (2017-12-01 10:33:14)
> -EIO has special meaning and is used when we want to allow
> engine initialization to fail and mark GPU as wedged.
> Missing firmware does not fit into this scenario as this is
> permanent error not related to GPU condition.
>
> Signed-off-by: Micha
Quoting Michal Wajdeczko (2017-12-01 10:33:16)
> Our new "enable_guc" modparam allows to control whenever HuC
> should be loaded. However existing code will try load and
> authenticate HuC always when we use the GuC. This patch is
> trying to enforce modparam selection.
>
> Signed-off-by: Michal W
== Series Details ==
Series: drm/i915: Sleep and retry a GPU reset if at first we don't succeed
(rev2)
URL : https://patchwork.freedesktop.org/series/34747/
State : success
== Summary ==
Series 34747v2 drm/i915: Sleep and retry a GPU reset if at first we don't
succeed
https://patchwork.freed
Compiler complained on crc_lowres and crc_hires2 being uninitialized
and indeed, display_commit_mode() seems to have intention of retruning
the value through the parameter that is only a single pointer.
This couses only the local copy of the pointer, the one inside
display_commit_mode(), to be ove
Quoting Michal Wajdeczko (2017-12-01 10:33:15)
> We currently have two module parameters that control GuC:
> "enable_guc_loading" and "enable_guc_submission". Whenever
> we need submission=1, we also need loading=1. We also need
> loading=1 when we want to want to load and verify the HuC.
>
> Lets
== Series Details ==
Series: test/kms_plane_lowres: Fix display_commit_mode() so it returns the crc
URL : https://patchwork.freedesktop.org/series/34749/
State : warning
== Summary ==
IGT patchset tested on top of latest successful build
476c4b462e0453c70ee81664c0227fdddc26cbd0 igt/gem_eio: In
With Android support gone there is not much reason for keeping libunwind
dependency optional. This also deals (cheaply!) with ifdefs covering
huge portions of code, removing a placement minefield.
Cc: Tvrtko Ursulin
Cc: Chris Wilson
Signed-off-by: Arkadiusz Hiler
---
configure.ac | 12 ++
Chris Wilson writes:
> As we declare the GPU wedged if the reset fails, such a failure is quite
> terminal. Before taking that drastic action, let's sleep first and try
> active, in the hope that the hardware has quietened down and is then
> able to reset. After a few such attempts, it is fair to
== Series Details ==
Series: drm/i915: Remove unsafe i915.enable_rc6 (rev4)
URL : https://patchwork.freedesktop.org/series/21884/
State : success
== Summary ==
Test pm_rc6_residency:
Subgroup rc6p-accuracy:
skip -> PASS (shard-snb)
Test kms_flip:
Sub
On Thu, Nov 30, 2017 at 04:18:53PM +0100, Maarten Lankhorst wrote:
> Normally this is called on a modeset, but the call is missing when
> we inherit the mode from the BIOS, so make sure it's called somewhere
> in hardware readout.
>
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/i915
Quoting Mika Kuoppala (2017-12-01 13:20:29)
> Chris Wilson writes:
>
> > As we declare the GPU wedged if the reset fails, such a failure is quite
> > terminal. Before taking that drastic action, let's sleep first and try
> > active, in the hope that the hardware has quietened down and is then
> >
== Series Details ==
Series: igt/gem_ctx_isolation: Check isolation of registers between contexts
(rev9)
URL : https://patchwork.freedesktop.org/series/32531/
State : failure
== Summary ==
Test kms_frontbuffer_tracking:
Subgroup fbc-1p-primscrn-indfb-pgflip-blt:
skip
Quoting Arkadiusz Hiler (2017-12-01 13:19:54)
> With Android support gone there is not much reason for keeping libunwind
> dependency optional. This also deals (cheaply!) with ifdefs covering
> huge portions of code, removing a placement minefield.
Could also force building with frame-pointers? I'
== Series Details ==
Series: igt: Make dependency on libunwind mandatory
URL : https://patchwork.freedesktop.org/series/34752/
State : success
== Summary ==
IGT patchset tested on top of latest successful build
476c4b462e0453c70ee81664c0227fdddc26cbd0 igt/gem_eio: Increase wakeup delay for
in
== Series Details ==
Series: drm/i915: Sleep and retry a GPU reset if at first we don't succeed
(rev2)
URL : https://patchwork.freedesktop.org/series/34747/
State : success
== Summary ==
Test drv_selftest:
Subgroup mock_sanitycheck:
pass -> DMESG-WARN (shard-snb)
On Fri, 01 Dec 2017 13:36:06 +0100, Chris Wilson
wrote:
Quoting Michal Wajdeczko (2017-12-01 10:33:15)
We currently have two module parameters that control GuC:
"enable_guc_loading" and "enable_guc_submission". Whenever
we need submission=1, we also need loading=1. We also need
loading=1 whe
On Fri, Dec 1, 2017 at 2:36 AM, Daniel Vetter wrote:
> On Fri, Dec 01, 2017 at 12:53:31PM +0530, Ramalingam C wrote:
> > Sean,
> >
> > IMHO, it will good if we can have all generic hdcp1.4 authentication
> flow in
> > drm helpers and all interested display drivers to use them.
> >
> > This Design
On Fri, Dec 1, 2017 at 3:36 AM, Ramalingam C wrote:
>
>
>
> On Friday 01 December 2017 01:06 PM, Daniel Vetter wrote:
>>
>> On Fri, Dec 01, 2017 at 12:53:31PM +0530, Ramalingam C wrote:
>>>
>>> Sean,
>>>
>>> IMHO, it will good if we can have all generic hdcp1.4 authentication flow in
>>> drm helpe
On Fri, Dec 1, 2017 at 2:36 AM, Daniel Vetter wrote:
> On Fri, Dec 01, 2017 at 12:53:31PM +0530, Ramalingam C wrote:
>> Sean,
>>
>> IMHO, it will good if we can have all generic hdcp1.4 authentication flow in
>> drm helpers and all interested display drivers to use them.
>>
>> This Design will mak
Add option to specify engine for register read/write operation.
If engine is specified, use MI_LOAD_REGISTER_IMM and MI_STORE_REGISTER_IMM
to write and read register using a batch targeted at that engine.
v2: no MI_NOOP after BBE (Chris)
Cc: Jani Nikula
Cc: Chris Wilson
CC: Joonas Lahtinen
Sig
== Series Details ==
Series: tools/intel_reg: Add reading and writing registers through engine
URL : https://patchwork.freedesktop.org/series/34755/
State : failure
== Summary ==
IGT patchset build failed on latest successful build
476c4b462e0453c70ee81664c0227fdddc26cbd0 igt/gem_eio: Increase
Quoting Michal Wajdeczko (2017-12-01 14:09:31)
> On Fri, 01 Dec 2017 13:36:06 +0100, Chris Wilson
> wrote:
>
> > Quoting Michal Wajdeczko (2017-12-01 10:33:15)
> >> We currently have two module parameters that control GuC:
> >> "enable_guc_loading" and "enable_guc_submission". Whenever
> >> we
Quoting Mika Kuoppala (2017-12-01 14:16:39)
> Add option to specify engine for register read/write operation.
> If engine is specified, use MI_LOAD_REGISTER_IMM and MI_STORE_REGISTER_IMM
> to write and read register using a batch targeted at that engine.
>
> v2: no MI_NOOP after BBE (Chris)
>
> C
Quoting Arkadiusz Hiler (2017-12-01 13:19:54)
> With Android support gone there is not much reason for keeping libunwind
> dependency optional. This also deals (cheaply!) with ifdefs covering
> huge portions of code, removing a placement minefield.
>
> Cc: Tvrtko Ursulin
> Cc: Chris Wilson
> Sig
On Wed, Nov 29, 2017 at 03:45:41PM +, Chris Wilson wrote:
> Quoting Ville Syrjala (2017-11-29 15:37:32)
> > From: Ville Syrjälä
> >
> > Get rid of the crtc->config usages from within
> > intel_pipe_{enable,disable}() by passing in the appropriate
> > crtc state.
> >
> > Signed-off-by: Ville
On Wed, Nov 29, 2017 at 03:22:33PM -0800, Rodrigo Vivi wrote:
> On Wed, Nov 29, 2017 at 04:43:01PM +, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Apparently g4x doesn't support audio over DP. Bspec lists the
> > bit as "Reserved for Audio Output Enable", and empirical evidence
> > te
On Wed, Nov 29, 2017 at 02:54:11PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> i830_disable_pipe() gets called from the power well code, and thus
> we're already holding the power domain mutex. That means we can't
> call plane->get_hw_state() as it will also try to grab the
> same mutex
On Wed, Nov 29, 2017 at 03:07:03PM -0800, Rodrigo Vivi wrote:
> On Wed, Nov 29, 2017 at 06:08:47PM +, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Reject interlaced modes on VLV/CHV DP outputs. This simply does
> > not work correctly in the hardware. We do get some output, but
> > it'
== Series Details ==
Series: igt: Make dependency on libunwind mandatory
URL : https://patchwork.freedesktop.org/series/34752/
State : success
== Summary ==
Test gem_tiled_swapping:
Subgroup non-threaded:
incomplete -> PASS (shard-snb) fdo#104009 +1
Test kms_front
On 12/1/2017 4:03 PM, Michal Wajdeczko wrote:
We currently have two module parameters that control GuC:
"enable_guc_loading" and "enable_guc_submission". Whenever
we need submission=1, we also need loading=1. We also need
loading=1 when we want to want to load and verify the HuC.
Lets combine
On 12/1/2017 6:01 PM, Chris Wilson wrote:
Quoting Michal Wajdeczko (2017-12-01 10:33:14)
-EIO has special meaning and is used when we want to allow
engine initialization to fail and mark GPU as wedged.
Missing firmware does not fit into this scenario as this is
permanent error not related to G
On Fri, 01 Dec 2017 16:47:40 +0100, Sagar Arun Kamble
wrote:
On 12/1/2017 4:03 PM, Michal Wajdeczko wrote:
We currently have two module parameters that control GuC:
"enable_guc_loading" and "enable_guc_submission". Whenever
we need submission=1, we also need loading=1. We also need
loading
On Fri, 01 Dec 2017 16:55:41 +0100, Sagar Arun Kamble
wrote:
On 12/1/2017 6:01 PM, Chris Wilson wrote:
Quoting Michal Wajdeczko (2017-12-01 10:33:14)
-EIO has special meaning and is used when we want to allow
engine initialization to fail and mark GPU as wedged.
Missing firmware does not
Quoting Patchwork (2017-12-01 14:00:49)
> == Series Details ==
>
> Series: drm/i915: Sleep and retry a GPU reset if at first we don't succeed
> (rev2)
> URL : https://patchwork.freedesktop.org/series/34747/
> State : success
>
> == Summary ==
>
> Test drv_selftest:
> Subgroup mock_san
On 12/1/2017 4:03 PM, Michal Wajdeczko wrote:
Our new "enable_guc" modparam allows to control whenever HuC
should be loaded. However existing code will try load and
authenticate HuC always when we use the GuC. This patch is
trying to enforce modparam selection.
Signed-off-by: Michal Wajdeczko
On Fri, 01 Dec 2017 17:39:38 +0100, Sagar Arun Kamble
wrote:
On 12/1/2017 4:03 PM, Michal Wajdeczko wrote:
Our new "enable_guc" modparam allows to control whenever HuC
should be loaded. However existing code will try load and
authenticate HuC always when we use the GuC. This patch is
tryin
Ok, here's v2 of the HDCP patchset, no longer RFC since I've tackled the TODO
list I set out in the first version (Annotated below for convenience).
The big changes to take note of in v2 is locking. To account for atomic async +
the property's mutability, I'm using a dedicated mutex and moved prop
I'm adding some stuff below it and it's killing my editor's vibe.
Changes in v2:
- Added to the series
Cc: Manasi Navare
Acked-by: Daniel Vetter
Signed-off-by: Sean Paul
---
drivers/gpu/drm/drm_connector.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gp
This patch adds a little more control to a couple wait_for routines such
that we can avoid open-coding read/wait/timeout patterns which:
- need the value of the register after the wait_for
- run arbitrary operation for the read portion
This patch also chooses the correct sleep function (based on
This patch adds the framework required to add HDCP support to intel
connectors. It implements Aksv loading from fuse, and parts 1/2/3
of the HDCP authentication scheme.
Note that without shim implementations, this does not actually implement
HDCP. That will come in subsequent patches.
Changes in
In preparation for implementing HDCP in i915, add some HDCP related
register offsets and defines. The dpcd register offsets will go in
drm_dp_helper.h whereas the ddc offsets along with generic HDCP stuff
will get stuffed in drm_hdcp.h, which is new.
Changes in v2:
- drm_hdcp.h gets MIT license (D
This patch adds HDCP support for HDMI connectors by implementing
the intel_hdcp_shim.
Nothing too special, just a bunch of DDC reads/writes.
Changes in v2:
- Rebased on drm-intel-next
Signed-off-by: Sean Paul
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_ddi.c | 5
Once the Aksv is available in the PCH, we need to get it on the wire to
the receiver via DDC. The hardware doesn't allow us to read the value
directly, so we need to tell GMBUS to source the Aksv internally and
send it to the right offset on the receiver.
The way we do this is to initiate an index
This patch adds HDCP support for DisplayPort connectors by implementing
the intel_hdcp_shim.
Most of this is straightforward read/write from/to DPCD registers. One
thing worth pointing out is the Aksv output bit. It wasn't easily
separable like it's HDMI counterpart, so it's crammed in with the re
This patch adds a new optional connector property to allow userspace to enable
protection over the content it is displaying. This will typically be implemented
by the driver using HDCP.
The property is a tri-state with the following values:
- OFF: Self explanatory, no content protection
- DESIRED:
== Series Details ==
Series: drm/i915: Implement HDCP (rev2)
URL : https://patchwork.freedesktop.org/series/34671/
State : failure
== Summary ==
Applying: drm: Fix link-status kerneldoc line lengths
error: Failed to merge in the changes.
Using index info to reconstruct a base tree...
M d
On Fri, Dec 01, 2017 at 02:17:00AM +, James Ausmus wrote:
> Without masking out the old value, we can end up pointing the DDI to a
> disabled PLL, which makes the system fall over. Mask out the previous
> value before setting the PLL to DDI mapping.
>
> This can be observed by running igt/test
Quoting Sean Paul (2017-12-01 17:20:24)
> /**
> - * _wait_for - magic (register) wait macro
> + * __wait_for - magic wait macro
> *
> - * Does the right thing for modeset paths when run under kdgb or similar
> atomic
> - * contexts. Note that it's important that we check the condition again aft
On Fri, Dec 1, 2017 at 12:44 PM, Chris Wilson wrote:
> Quoting Sean Paul (2017-12-01 17:20:24)
>> /**
>> - * _wait_for - magic (register) wait macro
>> + * __wait_for - magic wait macro
>> *
>> - * Does the right thing for modeset paths when run under kdgb or similar
>> atomic
>> - * contexts.
Quoting Sean Paul (2017-12-01 17:48:17)
> On Fri, Dec 1, 2017 at 12:44 PM, Chris Wilson
> wrote:
> > Quoting Sean Paul (2017-12-01 17:20:24)
> >> /**
> >> - * _wait_for - magic (register) wait macro
> >> + * __wait_for - magic wait macro
> >> *
> >> - * Does the right thing for modeset paths w
Quoting Chris Wilson (2017-12-01 17:55:15)
> Quoting Sean Paul (2017-12-01 17:48:17)
> > On Fri, Dec 1, 2017 at 12:44 PM, Chris Wilson
> > wrote:
> > > The current wait_for() is a little more complicated nowadays (variable
> > > W).
> > >
> >
> > Hmm, am I based off the wrong tree? I'm using drm
On Fri, Dec 1, 2017 at 12:57 PM, Chris Wilson wrote:
> Quoting Chris Wilson (2017-12-01 17:55:15)
>> Quoting Sean Paul (2017-12-01 17:48:17)
>> > On Fri, Dec 1, 2017 at 12:44 PM, Chris Wilson
>> > wrote:
>> > > The current wait_for() is a little more complicated nowadays (variable
>> > > W).
>>
On Saturday, November 25, 2017 08:35:46 PM Hans de Goede wrote:
> Here is v7 of my series to add a "panel orientation" property to
> the drm-connector for the LCD panel to let userspace know about LCD
> panels which are not mounted upright, as well as detecting upside-down
> panels without needing
Hi Sean,
On 12/01/2017 06:20 PM, Sean Paul wrote:
> Ok, here's v2 of the HDCP patchset, no longer RFC since I've tackled the TODO
> list I set out in the first version (Annotated below for convenience).
>
> The big changes to take note of in v2 is locking. To account for atomic async
> +
> the p
On Fri, Dec 1, 2017 at 1:47 PM, Hans Verkuil wrote:
> Hi Sean,
>
> On 12/01/2017 06:20 PM, Sean Paul wrote:
>> Ok, here's v2 of the HDCP patchset, no longer RFC since I've tackled the TODO
>> list I set out in the first version (Annotated below for convenience).
>>
>> The big changes to take note
On Fri, Dec 01, 2017 at 12:20:28PM -0500, Sean Paul wrote:
> Once the Aksv is available in the PCH, we need to get it on the wire to
> the receiver via DDC. The hardware doesn't allow us to read the value
> directly, so we need to tell GMBUS to source the Aksv internally and
> send it to the right
On 17-11-15 17:37:01, Gabriel Krisman Bertazi wrote:
Two scenarios tested:
- unaligned stride
- Stride too small
Since v4:
- Fix SIGFPE if width <= 1024 (Arkadiusz Hiler/Ville Syrjälä)
- Add test for pitches[1]=0 (Ville Syrjälä)
Signed-off-by: Gabriel Krisman Bertazi
[snip]
Reviewed-by: B
On Fri, Dec 1, 2017 at 2:06 PM, Ville Syrjälä
wrote:
> On Fri, Dec 01, 2017 at 12:20:28PM -0500, Sean Paul wrote:
>> Once the Aksv is available in the PCH, we need to get it on the wire to
>> the receiver via DDC. The hardware doesn't allow us to read the value
>> directly, so we need to tell GMBU
Em Sex, 2017-11-10 às 19:08 +, Lionel Landwerlin escreveu:
> We use to have this fixed per generation, but starting with CNL
> userspace
> cannot tell just off the PCI ID. Let's make this information
> available. This
> is particularly useful for performance monitoring where much of the
> norma
On Fri, Dec 01, 2017 at 02:17:19PM -0500, Sean Paul wrote:
> On Fri, Dec 1, 2017 at 2:06 PM, Ville Syrjälä
> wrote:
> > On Fri, Dec 01, 2017 at 12:20:28PM -0500, Sean Paul wrote:
> >> Once the Aksv is available in the PCH, we need to get it on the wire to
> >> the receiver via DDC. The hardware do
On 01/12/17 20:02, Paulo Zanoni wrote:
Em Sex, 2017-11-10 às 19:08 +, Lionel Landwerlin escreveu:
We use to have this fixed per generation, but starting with CNL
userspace
cannot tell just off the PCI ID. Let's make this information
available. This
is particularly useful for performance moni
Read debugfs and sysfs entries to check for GuC
loading conditions.
The patch is still WIP. Once all check conditions are
covered, it can be extended to huc debugfs file too.
Cc: Rodrigo Vivi
Signed-off-by: Anusha Srivatsa
---
tests/Makefile.sources | 1 +
tests/test_firmware.c | 96
== Series Details ==
Series: IGT/tests/firmware: Test firmware loading by reading debugfs
URL : https://patchwork.freedesktop.org/series/34778/
State : success
== Summary ==
IGT patchset tested on top of latest successful build
476c4b462e0453c70ee81664c0227fdddc26cbd0 igt/gem_eio: Increase wak
On Fri, Dec 01, 2017 at 09:40:35PM +, Anusha Srivatsa wrote:
> Read debugfs and sysfs entries to check for GuC
> loading conditions.
>
> The patch is still WIP. Once all check conditions are
> covered, it can be extended to huc debugfs file too.
>
> Cc: Rodrigo Vivi
> Signed-off-by: Anusha S
In CI, we were observing situations where the busy blt would complete
before the very next instruction (in userspace) to assert that it was
busy. This is entirely possible if the process was scheduled away and
slept for longer than the arbitrary batch. Instead replace arbitrariness
with a precise i
== Series Details ==
Series: IGT/tests/firmware: Test firmware loading by reading debugfs
URL : https://patchwork.freedesktop.org/series/34778/
State : warning
== Summary ==
Test gem_busy:
Subgroup close-race:
fail -> PASS (shard-snb) fdo#103829
Test kms_cur
== Series Details ==
Series: igt/gem_busy: Replace arbitrary busy batch with indefinite spinbatch
URL : https://patchwork.freedesktop.org/series/34780/
State : failure
== Summary ==
IGT patchset tested on top of latest successful build
476c4b462e0453c70ee81664c0227fdddc26cbd0 igt/gem_eio: Incr
In CI, we were observing situations where the busy blt would complete
before the very next instruction (in userspace) to assert that it was
busy. This is entirely possible if the process was scheduled away and
slept for longer than the arbitrary batch. Instead replace arbitrariness
with a precise i
This workaround supposedly fixes some hangs in the VF unit.
Signed-off-by: Rafael Antognolli
---
drivers/gpu/drm/i915/i915_reg.h | 3 +++
drivers/gpu/drm/i915/intel_pm.c | 5 +
2 files changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
in
1 - 100 of 110 matches
Mail list logo
