From: "Lee, Shawn C"
Display driver read DPCD register 0x202, 0x203 and 0x204 to identify
eDP sink status.If PSR exit is ongoing at eDP sink, and eDP source
read these registers at the same time. Panel will report EQ & symbol
lock not done. It will cause panel display flicking.
Try to read link
On Sun, Mar 12, 2017 at 09:53:40PM +0100, Daniel Vetter wrote:
> Peter/Ingo,
>
> We want this to validate the i915 shrinker locking in our fast tests
> without thrashing badly (that takes too long, we can only thrash in
> the extended runs). Can you pls take a look and if it's ok ack for
> mergin
On Mon, Mar 13, 2017 at 09:01:57AM +0100, Peter Zijlstra wrote:
> On Sun, Mar 12, 2017 at 09:53:40PM +0100, Daniel Vetter wrote:
>
> > Peter/Ingo,
> >
> > We want this to validate the i915 shrinker locking in our fast tests
> > without thrashing badly (that takes too long, we can only thrash in
>
== Series Details ==
Series: drm/i915/dp: Read link status more times when EQ not done (rev4)
URL : https://patchwork.freedesktop.org/series/18982/
State : success
== Summary ==
Series 18982v4 drm/i915/dp: Read link status more times when EQ not done
https://patchwork.freedesktop.org/api/1.0/s
On Sun, Mar 12, 2017 at 03:07:14PM -0700, Kenneth Graunke wrote:
> On Sunday, March 12, 2017 6:21:12 AM PDT Chris Wilson wrote:
> > On Fri, Mar 10, 2017 at 05:14:32PM -0800, Kenneth Graunke wrote:
> > > On systems without LLC, drm_intel_gem_bo_map_unsynchronized() has
> > > had the surprising behav
On Thu, Mar 02, 2017 at 04:56:49PM +0100, Daniel Vetter wrote:
> Hi Dave,
>
> topic/designware-baytrail-2017-03-02:
> Baytrail PMIC vs. PMU race fixes from Hans de Goede
>
> This time the right version (v4), with the compile fix.
>
> Updated pull request with new tag, same story as before
>
> C
On Mon, Mar 13, 2017 at 09:15:17AM +0100, Daniel Vetter wrote:
> On Mon, Mar 13, 2017 at 09:01:57AM +0100, Peter Zijlstra wrote:
> > On Sun, Mar 12, 2017 at 09:53:40PM +0100, Daniel Vetter wrote:
> >
> > > Peter/Ingo,
> > >
> > > We want this to validate the i915 shrinker locking in our fast test
HI,
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Patchwork
> Sent: Saturday, March 11, 2017 1:23 AM
> To: Puthikorn Voravootivat
> Cc: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] ✗ Fi.CI.BAT: failure for Enhancement to
>
On Tue, Jan 31, 2017 at 10:36:42PM +0100, Takashi Iwai wrote:
> Hi,
>
> the following patches enable DisplayPort Audio on Cherrytrail machines
> when applied on top of my topic/intel-lpe-audio branch. Tests of DP
> audio were run on Dell Wyse 3040. The regression test were performed
> on Baytrai
Hi
we have "HP ProOne 600 G2 21.5-in Touch AiO" PC, equipped with "Intel
HD Graphics 530" graphics card
We are using debian stretch (testing) based linux distro named pardus.
But we have observed the same condition under ubuntu 16.04 LTS.
our problem is: screen divided half horizontally.
On Thu, Mar 09, 2017 at 12:48:56PM +0200, Jani Nikula wrote:
> On Thu, 09 Mar 2017, Daniel Vetter wrote:
> > On Wed, Mar 01, 2017 at 10:52:35AM -, Patchwork wrote:
> >> == Series Details ==
> >>
> >> Series: series starting with [1/6] drm/i915: Use drm_connector_list_iter
> >> in debugfs
> >
On Thu, Mar 09, 2017 at 03:52:01PM +0100, Maarten Lankhorst wrote:
> Use for_each_new_connector_in_state instead of for_each_connector_in_state.
> Also make the function static, it's only used inside intel_ddi.c
>
> Signed-off-by: Maarten Lankhorst
On the topic of static, intel_ddi.h exports _wa
On Mon, 13 Mar 2017, Daniel Vetter wrote:
> On Thu, Mar 09, 2017 at 12:48:56PM +0200, Jani Nikula wrote:
>> On Thu, 09 Mar 2017, Daniel Vetter wrote:
>> > On Wed, Mar 01, 2017 at 10:52:35AM -, Patchwork wrote:
>> >> == Series Details ==
>> >>
>> >> Series: series starting with [1/6] drm/i915
On pe, 2017-03-10 at 00:09 +, Chris Wilson wrote:
> If the object is coherent, we can simply update the cache domain on the
> whole object rather than calculate the before/after clflushes. The
> advantage is that we then get correct tracking of ellided flushes when
> changing coherency later.
>
== Series Details ==
Series: drm/i915/vbt: defaults handling for no VBT case
URL : https://patchwork.freedesktop.org/series/21061/
State : success
== Summary ==
Series 21061v1 drm/i915/vbt: defaults handling for no VBT case
https://patchwork.freedesktop.org/api/1.0/series/21061/revisions/1/mbo
> -Original Message-
> From: intel-gvt-dev [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On
> Behalf Of Dong, Chuanxiao
> Sent: Thursday, March 9, 2017 9:28 AM
> To: Chris Wilson ; intel-gfx@lists.freedesktop.org
> Cc: intel-gvt-...@lists.freedesktop.org; Wang, Zhi A
> ; Zhenyu Wan
Op 09-03-17 om 18:36 schreef Ville Syrjälä:
> On Thu, Mar 09, 2017 at 02:06:15PM +0100, Maarten Lankhorst wrote:
>> As a proof of concept, first try to convert intel_tv, which is a rarely
>> used connector. It has 5 properties, tv format and 4 margins.
> Since it's so rare, if you want someone to a
On 10/03/2017 10:09, Chris Wilson wrote:
On Fri, Mar 10, 2017 at 09:57:47AM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
If we avoid initializing forcewake domains when running as
a guest, and also use gen2 mmio accessors in that case, we
can avoid the timer traffic and any looping throu
On Mon, Mar 13, 2017 at 09:21:58AM +, Dong, Chuanxiao wrote:
>
>
> > -Original Message-
> > From: intel-gvt-dev [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On
> > Behalf Of Dong, Chuanxiao
> > Sent: Thursday, March 9, 2017 9:28 AM
> > To: Chris Wilson ; intel-gfx@lists.freede
Hello Chris Wilson,
The patch 6e32ab3d4777: "drm/i915: Fill different pages of the GTT"
from Feb 13, 2017, leads to the following static checker warning:
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:583 walk_hole()
error: 'vma' dereferencing possible ERR_PTR()
drivers/gpu/drm/i9
On Mon, Mar 13, 2017 at 10:22:51AM +0100, Maarten Lankhorst wrote:
> Op 09-03-17 om 18:36 schreef Ville Syrjälä:
> > On Thu, Mar 09, 2017 at 02:06:15PM +0100, Maarten Lankhorst wrote:
> >> As a proof of concept, first try to convert intel_tv, which is a rarely
> >> used connector. It has 5 properti
On Thu, 2017-03-09 at 17:44 +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Replace __raw_i915_read32() with I915_READ_FW() in the workaround for
> the SKL+ scanline counter hardware fail. The two are the same thing
> but everyone else uses I915_READ_FW() so let's follow sui
> -Original Message-
> From: intel-gvt-dev [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On
> Behalf Of Chris Wilson
> Sent: Monday, March 13, 2017 5:28 PM
> To: Dong, Chuanxiao
> Cc: intel-gfx@lists.freedesktop.org; intel-gvt-...@lists.freedesktop.org;
> Zhenyu Wang ; Wang, Zhi A
On Mon, Mar 13, 2017 at 08:31:28AM +, Saarinen, Jani wrote:
> HI,
> > -Original Message-
> > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> > Of Patchwork
> > Sent: Saturday, March 11, 2017 1:23 AM
> > To: Puthikorn Voravootivat
> > Cc: intel-gfx@lists.fre
On 2017.03.13 09:26:26 +, Tvrtko Ursulin wrote:
>
> On 10/03/2017 10:09, Chris Wilson wrote:
> > On Fri, Mar 10, 2017 at 09:57:47AM +, Tvrtko Ursulin wrote:
> > > From: Tvrtko Ursulin
> > >
> > > If we avoid initializing forcewake domains when running as
> > > a guest, and also use gen2
On pe, 2017-03-10 at 12:46 +0100, Arkadiusz Hiler wrote:
> Current version of intel_guc_init_hw() does a lot:
> - cares about submission
> - loads huc
> - implement WA
>
> This change offloads some of the logic to intel_uc_init_hw(), which now
> cares about the above.
>
> v2: rename guc_hw_res
On Mon, Mar 13, 2017 at 10:17:25AM +0530, Kamble, Sagar A wrote:
> LGTM.
> Reviewed-by: Sagar Arun Kamble [1]
>
> PS: Might need updating comments in the guc_interrupts_capture to align with
> new name and semantics of this bit
> w.r.t pm_intrmsk_mbz.
I felt the comment was still correct. It
On 2017.03.08 22:08:08 +, Chris Wilson wrote:
> commit 8f1117abb408 ("drm/i915/gvt: handle workload lifecycle properly")
> includes some nonsense to retry a indefinite wait - i915_wait_request()
> does not return until the request is completed when used from an
> uninterruptible context.
>
> F
On 13/03/2017 09:37, Zhenyu Wang wrote:
On 2017.03.13 09:26:26 +, Tvrtko Ursulin wrote:
On 10/03/2017 10:09, Chris Wilson wrote:
On Fri, Mar 10, 2017 at 09:57:47AM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
If we avoid initializing forcewake domains when running as
a guest, and
On Mon, Mar 13, 2017 at 10:28:34AM +0530, Kamble, Sagar A wrote:
>
>
> On 3/12/2017 6:29 PM, Chris Wilson wrote:
> >On Sat, Mar 11, 2017 at 04:17:34AM -, Patchwork wrote:
> >>== Series Details ==
> >>
> >>Series: series starting with [1/3] drm/i915/guc: Release GuC interrupts in
> >>i915_guc
On 2017.03.09 23:07:12 +0800, Chuanxiao Dong wrote:
> The GVT-g needs execlists to be enabled otherwise gvt should be
> disabled. Add a check for enable_execlists before enabling gvt.
>
> v2: use DRM_INFO in response to the user action
>
> Signed-off-by: Chuanxiao Dong
> ---
> drivers/gpu/drm/i
On ke, 2017-03-08 at 11:02 +0100, Arkadiusz Hiler wrote:
>
> Having a mean to easily point to any binary you want to try out helps
> with testing and verification, without the need to do in-kernel changes.
>
> This param was suggested by Chris, and I've seen couple of similar
> patches by differen
On Sat, 11 Mar 2017, Manasi Navare wrote:
> On Fri, Mar 10, 2017 at 03:27:58PM +0200, Jani Nikula wrote:
>> The main thing are the DDI ports. If there's a VBT that says there are
>> no outputs, we should trust that, and not have semi-random
>> defaults. Unfortunately, the defaults have resulted in
i915_drpc_info missed covering a few register read with the runtime pm
wakelock. Be simple and cover the entire function with a single wakelock
so that new additions are not similarly missed in future.
WARNING: CPU: 2 PID: 1334 at drivers/gpu/drm/i915/intel_drv.h:1743
gen6_read32+0x192/0x1e0 [i
On Mon, Mar 13, 2017 at 09:47:15AM +, Tvrtko Ursulin wrote:
>
> On 13/03/2017 09:37, Zhenyu Wang wrote:
> >On 2017.03.13 09:26:26 +, Tvrtko Ursulin wrote:
> >>
> >>On 10/03/2017 10:09, Chris Wilson wrote:
> >>>On Fri, Mar 10, 2017 at 09:57:47AM +, Tvrtko Ursulin wrote:
> From: Tvrt
On Fri, 10 Mar 2017, Chris Wilson wrote:
> On Fri, Mar 10, 2017 at 03:27:57PM +0200, Jani Nikula wrote:
>> We don't use the error return for anything other than reporting and
>> logging that there is no VBT. We can pull the logging in the function,
>> and remove the error status return. Moreover,
On Thu, Mar 09, 2017 at 03:52:02PM +0100, Maarten Lankhorst wrote:
> Use for_each_new_plane_in_state, only the new state is needed.
>
> Signed-off-by: Maarten Lankhorst
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/intel_fbc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
The patch 6e32ab3d4777: "drm/i915: Fill different pages of the GTT"
from Feb 13, 2017, leads to the following static checker warning:
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:583 walk_hole()
error: 'vma' dereferencing possible ERR_PTR()
Reported-by: Dan Carpenter
Fixes: 6e32
On Thu, Mar 09, 2017 at 03:52:03PM +0100, Maarten Lankhorst wrote:
> The watermark code needs to look at the new allocations, so use
> for_each_new_crtc_in_state everywhere.
>
> Signed-off-by: Maarten Lankhorst
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/intel_pm.c | 8
>
On Mon, Mar 13, 2017 at 12:28:01PM +0300, Dan Carpenter wrote:
> Hello Chris Wilson,
>
> The patch 6e32ab3d4777: "drm/i915: Fill different pages of the GTT"
> from Feb 13, 2017, leads to the following static checker warning:
>
> drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:583 walk_hole()
On Thu, Mar 09, 2017 at 03:52:04PM +0100, Maarten Lankhorst wrote:
> Add a big fat warning in __intel_display_resume that the old state is
> invalid, and use the correct state everywhere.
>
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/i915/intel_display.c | 161
> +
On Thu, Mar 09, 2017 at 03:52:05PM +0100, Maarten Lankhorst wrote:
> Calculating the max pixel rate requires the new state, so use it there.
>
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/i915/intel_cdclk.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/d
== Series Details ==
Series: drm/i915: Extend rpm wakelock for debugfs/i915_drpc_info
URL : https://patchwork.freedesktop.org/series/21139/
State : success
== Summary ==
Series 21139v1 drm/i915: Extend rpm wakelock for debugfs/i915_drpc_info
https://patchwork.freedesktop.org/api/1.0/series/211
Regards
Shashank
From: Ville Syrjälä
Check that the sink really declared 12bpc support before we enable it.
This should not actually never happen since it's mandatory for HDMI sinks to
support 12bpc if they support any deep color modes. But reality disagrees with
the theory and there are ac
On Sat, 11 Mar 2017, Lukas Erlacher wrote:
> I don't know if this is a known bug, but it affects all kernels from 4.9
> upwards (tested also with 4.11-rc1) and probably also 4.8 (there was one
> report of someone using a 4.8 kernel).
Please file a bug at [1].
Thanks,
Jani.
[1] https://bugs.free
On Mon, Mar 13, 2017 at 12:23:49PM +0200, Jani Nikula wrote:
> On Sat, 11 Mar 2017, Lukas Erlacher wrote:
> > I don't know if this is a known bug, but it affects all kernels from 4.9
> > upwards (tested also with 4.11-rc1) and probably also 4.8 (there was one
> > report of someone using a 4.8 kern
On 13 March 2017 at 10:07, Chris Wilson wrote:
> The patch 6e32ab3d4777: "drm/i915: Fill different pages of the GTT"
> from Feb 13, 2017, leads to the following static checker warning:
>
> drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:583 walk_hole()
> error: 'vma' dereferencing po
Op 13-03-17 om 10:29 schreef Ville Syrjälä:
> On Mon, Mar 13, 2017 at 10:22:51AM +0100, Maarten Lankhorst wrote:
>> Op 09-03-17 om 18:36 schreef Ville Syrjälä:
>>> On Thu, Mar 09, 2017 at 02:06:15PM +0100, Maarten Lankhorst wrote:
As a proof of concept, first try to convert intel_tv, which is
On Mon, 13 Mar 2017, Daniel Vetter wrote:
> Our cherry-pick sha1 work exactly like yours: They don't make sense
> when you only look at the tree a patch has been cherry-picked _to_,
> since they're the sha1 from the tree they've been cherry-picked
> _from_. When you clone a fresh copy of your stab
v2 of the series with miscellaneous fixes.
IGT subtest enumeration must work regardless of what the running
environment is. Kernel selftest launchers want to expose everything
the running kernel can execute.
These two things are mutually exclusive. This series is an attempt for
a best-of-both-wor
Copied as of commit
commit 496b575e3ccbf6fbe57a674c721af43dc8826361
Author: Chris Wilson
Date: Mon Feb 13 17:15:58 2017 +
drm/i915: Add initial selftests for hang detection and resets
The headers are used to enumerate available tests when the running
kernel does not support selftes
Even when the running kernel does not support selftests, make subtest
enumeration list known kselftests. The list is generated using
selftest listing headers copied from the kernel.
If the running kernel gains new selftest subtests, they are listed
even without copying the headers over and rebuild
On Mon, 13 Mar 2017, "M. selcuk karaca" wrote:
> we have "HP ProOne 600 G2 21.5-in Touch AiO" PC, equipped with "Intel
> HD Graphics 530" graphics card
>
> We are using debian stretch (testing) based linux distro named pardus.
> But we have observed the same condition under ubuntu 16.04 LTS.
>
On Mon, Mar 13, 2017 at 12:43:56PM +0200, Petri Latvala wrote:
> v2 of the series with miscellaneous fixes.
>
> IGT subtest enumeration must work regardless of what the running
> environment is. Kernel selftest launchers want to expose everything
> the running kernel can execute.
>
> These two th
On Mon, Mar 13, 2017 at 12:22:53PM +0200, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
> > From: Ville Syrjälä
> >
> > Check that the sink really declared 12bpc support before we enable it.
> > This should not actually never happen since it's mandatory for HDMI sinks
> > to support 12bpc if
On Mon, Mar 13, 2017 at 11:38:33AM +0100, Maarten Lankhorst wrote:
> Op 13-03-17 om 10:29 schreef Ville Syrjälä:
> > On Mon, Mar 13, 2017 at 10:22:51AM +0100, Maarten Lankhorst wrote:
> >> Op 09-03-17 om 18:36 schreef Ville Syrjälä:
> >>> On Thu, Mar 09, 2017 at 02:06:15PM +0100, Maarten Lankhorst
On Mon, Mar 13, 2017 at 10:50:04AM +, Chris Wilson wrote:
> Still completely lacking justification. The above is a non sequitur;
> static testlist generation can be done just from the source.
Static testlist generation can be done and it breaks when run on a
kernel without selftests enabled.
Op 13-03-17 om 11:15 schreef Daniel Vetter:
> On Thu, Mar 09, 2017 at 03:52:04PM +0100, Maarten Lankhorst wrote:
>> Add a big fat warning in __intel_display_resume that the old state is
>> invalid, and use the correct state everywhere.
>>
>> Signed-off-by: Maarten Lankhorst
>> ---
>> drivers/gpu/
Op 09-03-17 om 19:35 schreef Ville Syrjälä:
> On Thu, Mar 09, 2017 at 03:52:00PM +0100, Maarten Lankhorst wrote:
>> Some small patchset to deal with the atomic iterator changes.
>>
>> Maarten Lankhorst (5):
>> drm/i915: Use new atomic iterator macros in ddi
>> drm/i915: Use new atomic iterator
Regards
Shashank
On 3/13/2017 12:53 PM, Ville Syrjälä wrote:
On Mon, Mar 13, 2017 at 12:22:53PM +0200, Sharma, Shashank wrote:
Regards
Shashank
From: Ville Syrjälä
Check that the sink really declared 12bpc support before we enable it.
This should not actually never happen since it's mand
From: Thierry Reding
This patch implements a small function that finds if a
given CEA db is hdmi-forum vendor specific data block
or not.
V2: Rebase.
V3: Added R-B from Jose.
V4: Rebase
V5: Rebase
V6: Rebase
V7: Rebase
V8: Rebase
V9: Rebase
V10: Rebase
Signed-off-by: Thierry Reding
Signed-off-
HDMI 2.0 spec defines a method to reduce the RF footprint while
operating at higher pixel clocks, which is called Scrambling.
Scrambling can be controlled over a new set of I2C registers
which are accessible over existing DDC I2C lines, called SCDC
register set.
This patch series contains 6 patche
This patch does following:
- Adds a new structure (drm_hdmi_info) in drm_display_info.
This structure will be used to save and indicate if sink
supports advanced HDMI 2.0 features
- Adds another structure drm_scdc within drm_hdmi_info, to
reflect scdc support and capabilities in connected HDM
From: Thierry Reding
SCDC is a mechanism defined in the HDMI 2.0 specification that allows
the source and sink devices to communicate.
This commit introduces helpers to access the SCDC and provides the
symbolic names for the various registers defined in the specification.
V2: Rebase.
V3: Added
This patch does following:
- Adds a new structure (drm_hdmi_info) in drm_display_info.
This structure will be used to save and indicate if sink
supports advanced HDMI 2.0 features
- Adds another structure drm_scdc within drm_hdmi_info, to
reflect scdc support and capabilities in connected HDM
Geminilake platform sports a native HDMI 2.0 controller, and is
capable of driving pixel-clocks upto 594Mhz. HDMI 2.0 spec
mendates scrambling for these higher clocks, for reduced RF footprint.
This patch checks if the monitor supports scrambling, and if required,
enables it during the modeset.
V
Geminilake has a native HDMI 2.0 controller, which is capable of
driving clocks upto 594Mhz. This patch updates the max tmds clock
limit for the same.
V2: rebase
V3: rebase
V4: added r-b from Ander
V5: rebase
V6: rebase
V7: rebase
V8: rebase
V9: rebase
V10: rebase
Cc: Ander Conselvan De Oliveira
== Series Details ==
Series: drm/i915/selftests: Fix error path for ggtt walk_hole()
URL : https://patchwork.freedesktop.org/series/21140/
State : success
== Summary ==
Series 21140v1 drm/i915/selftests: Fix error path for ggtt walk_hole()
https://patchwork.freedesktop.org/api/1.0/series/21140
Signed-off-by: Petri Latvala
---
Marius has stepped down from being a maintainer a while ago, it's time
to make the file match reality.
I'd like to take this opportunity to thank Marius for his work and
wish him the best in his new endeavours.
MAINTAINERS | 1 -
1 file changed, 1 deletion(-)
To improve our historical record and to simplify userspace that wants to
include i915_pciids.h as its canonical breakdown of PCI IDs and their
respective generations, include the gen1 ids for i810 and i815.
Signed-off-by: Chris Wilson
---
include/drm/i915_pciids.h | 8
1 file changed, 8
On Fri, Mar 10, 2017 at 08:28:55AM -0800, Oscar Mateo wrote:
> Doorbell release flow requires that we wait for GEN8_DRB_VALID bit to go
> to zero after updating db_status before we call the GuC to release the
> doorbell.
Does this fix some of the '110' errors?
-Chris
--
Chris Wilson, Intel Open
On Fri, Mar 10, 2017 at 08:28:57AM -0800, Oscar Mateo wrote:
> A GuC context and a HW context are in no way related, so the name "GuC
> context descriptor"
> is very unfortunate, because a new reader of the code gets overwhelmed very
> quickly with
> a lot of things called "context" that refer to
== Series Details ==
Series: HDMI 2.0: Scrambling in DRM layer (rev10)
URL : https://patchwork.freedesktop.org/series/19161/
State : success
== Summary ==
Series 19161v10 HDMI 2.0: Scrambling in DRM layer
https://patchwork.freedesktop.org/api/1.0/series/19161/revisions/10/mbox/
Test gvt_basic
Op 13-03-17 om 11:55 schreef Ville Syrjälä:
> On Mon, Mar 13, 2017 at 11:38:33AM +0100, Maarten Lankhorst wrote:
>> Op 13-03-17 om 10:29 schreef Ville Syrjälä:
>>> On Mon, Mar 13, 2017 at 10:22:51AM +0100, Maarten Lankhorst wrote:
Op 09-03-17 om 18:36 schreef Ville Syrjälä:
> On Thu, Mar 0
Hello Chris Wilson,
The patch 791ff39ae32a: "drm/i915: Live testing for context
execution" from Feb 13, 2017, leads to the following static checker
warning:
drivers/gpu/drm/i915/selftests/i915_gem_context.c:347 igt_ctx_exec()
error: 'file' dereferencing possible ERR_PTR()
drivers
On Fri, Mar 10, 2017 at 01:11:06PM +0100, Michal Wajdeczko wrote:
> On Fri, Mar 10, 2017 at 12:46:06PM +0100, Arkadiusz Hiler wrote:
> > Current version of intel_guc_init_hw() does a lot:
> > - cares about submission
> > - loads huc
> > - implement WA
> >
> > This change offloads some of the lo
On Mon, Mar 13, 2017 at 03:34:29PM +0300, Dan Carpenter wrote:
> Hello Chris Wilson,
>
> The patch 791ff39ae32a: "drm/i915: Live testing for context
> execution" from Feb 13, 2017, leads to the following static checker
> warning:
>
> drivers/gpu/drm/i915/selftests/i915_gem_context.c:347 igt
The patch 791ff39ae32a: "drm/i915: Live testing for context
execution" from Feb 13, 2017, leads to the following static checker
warning:
drivers/gpu/drm/i915/selftests/i915_gem_context.c:347 igt_ctx_exec()
error: 'file' dereferencing possible ERR_PTR()
Reported-by: Dan Carpenter
== Series Details ==
Series: drm/i915: Add i810/i815 pci-ids for completeness
URL : https://patchwork.freedesktop.org/series/21149/
State : failure
== Summary ==
Series 21149v1 drm/i915: Add i810/i815 pci-ids for completeness
https://patchwork.freedesktop.org/api/1.0/series/21149/revisions/1/m
On 13/03/2017 12:47, Chris Wilson wrote:
The patch 791ff39ae32a: "drm/i915: Live testing for context
execution" from Feb 13, 2017, leads to the following static checker
warning:
drivers/gpu/drm/i915/selftests/i915_gem_context.c:347 igt_ctx_exec()
error: 'file' dereferencing poss
On Mon, 13 Mar 2017, Chris Wilson wrote:
> To improve our historical record and to simplify userspace that wants to
> include i915_pciids.h as its canonical breakdown of PCI IDs and their
> respective generations, include the gen1 ids for i810 and i815.
Is this how you start sneaking in support f
On Mon, Mar 13, 2017 at 03:04:21PM +0200, Jani Nikula wrote:
> On Mon, 13 Mar 2017, Chris Wilson wrote:
> > To improve our historical record and to simplify userspace that wants to
> > include i915_pciids.h as its canonical breakdown of PCI IDs and their
> > respective generations, include the gen
Reasoning
=
General GuC/HuC cleanup simplifying logic and moving chunks around as the area
got pretty rusty.
This is the first part of effort to clean it up.
A lot of logic were extracted from intel_guc_load() to other functions - it did
not only handle the actual loading but had WA impl
Externs are implicit and we generally try to avoid them.
Cc: Michal Wajdeczko
Signed-off-by: Arkadiusz Hiler
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/intel_uc.h | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_uc.h b/drive
Instead of calling intel_guc_init() and intel_huc_init() one by one this
patch introduces intel_uc_init_fw() function that calls them both.
Called functions are renamed accordingly.
Trying to have subject_verb_object ordering and more descriptive names,
the intel_huc_init() and intel_guc_init() f
GuC historically has two "startup" functions called _init() and _setup()
Then HuC came with it's _init() and _load().
This commit renames intel_guc_setup() and intel_huc_load() to
*uc_init_hw() as they called from the i915_gem_init_hw().
The aim is to be consistent in that entry points called du
Used to obtain "dev_priv" from huc struct pointer.
We already have similar thing for guc.
Cc: Michal Wajdeczko
Signed-off-by: Arkadiusz Hiler
Reviewed-by: Michal Wajdeczko
---
drivers/gpu/drm/i915/i915_drv.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv
Current version of intel_guc_init_hw() does a lot:
- cares about submission
- loads huc
- implement WA
This change offloads some of the logic to intel_uc_init_hw(), which now
cares about the above.
v2: rename guc_hw_reset and fix typo in define name (M. Wajdeczko)
v3: rename once again
v4: rem
The file fits better.
Additionally rename it to intel_uc_prepare_fw(), as the function does
more than simple fetch.
`obj` cleanup in the function is also fixed (i.e. removed). In the fail
scenario it was always 'put' but there's no possible flow that
initializes the obj properly and then goes to
`guc_firmware_path` and `huc_firmware_path` module parameters are added.
Using the parameter disables version checks and loads desired firmware
instead of the default one.
v2: make params unsafe && notice about disabled fw check (J. Lahtinen)
Cc: Chris Wilson
Cc: Joonas Lahtinen
Cc: Michal Win
intel_{h,g}uc_init_fw selects correct firmware and then triggers it's
preparation (fetch + initial parsing).
This change separates out select steps, so those can be called by
the sanitize_options().
Then, during the init_fw(), we prepare the firmware if the firmware was
selected.
Cc: Michal Wini
Let intel_guc_init_fw() focus on determining and fetching the correct
firmware.
This patch introduces intel_uc_sanitize_options() that is called from
intel_sanitize_options().
Then, if we have GuC, we can call intel_guc_init_fw() conditionally
and we do not have to do the internal checks.
v2: fi
Currently fw->path values can represent one of three possible states:
1) NULL - device without the uC
2) '\0' - device with the uC but have no firmware
3) else - device with the uC and we have firmware
Second case is used only to WARN at a later stage.
We can WARN right away and merge cases 1
---
drivers/gpu/drm/i915/i915_params.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index b6a7e36..9dcc8a0 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@
Chris Wilson writes:
> gen6_sanitize_rps_pm_mask() is small enough that inlining it shrinks the
> object code.
>
> Signed-off-by: Chris Wilson
> Cc: Tvrtko Ursulin
> ---
> drivers/gpu/drm/i915/i915_irq.c | 5 -
> drivers/gpu/drm/i915/intel_drv.h | 8 +++-
> 2 files changed, 7 insertio
== Series Details ==
Series: drm/i915/selftests: Catch error from mock_file()
URL : https://patchwork.freedesktop.org/series/21156/
State : success
== Summary ==
Series 21156v1 drm/i915/selftests: Catch error from mock_file()
https://patchwork.freedesktop.org/api/1.0/series/21156/revisions/1/m
On Mon, Mar 13, 2017 at 03:15:32PM +0200, Mika Kuoppala wrote:
> Chris Wilson writes:
>
> > gen6_sanitize_rps_pm_mask() is small enough that inlining it shrinks the
> > object code.
> >
> > Signed-off-by: Chris Wilson
> > Cc: Tvrtko Ursulin
> > ---
> > drivers/gpu/drm/i915/i915_irq.c | 5
On Fri, Mar 10, 2017 at 08:28:50AM -0800, Oscar Mateo wrote:
> Starting with intel_guc_loader, down to intel_guc_submission
> and finally to intel_guc_log.
>
> v2:
> - Null execbuf client outside guc_client_free (Daniele)
> - Assert if things try to get allocated twice (Daniele/Joonas)
> - N
On Fri, Mar 10, 2017 at 10:22:38AM +0800, Zhenyu Wang wrote:
> From commit a6508ded2a66 ("drm/i915: Use page coloring to provide the guard
> page at the end of the GTT"), we no longer explicitly subtract guard page
> at end for GGTT address space init, so shouldn't subtract that for vGPU
> balloon
On 13/03/2017 13:15, Arkadiusz Hiler wrote:
Currently fw->path values can represent one of three possible states:
1) NULL - device without the uC
2) '\0' - device with the uC but have no firmware
3) else - device with the uC and we have firmware
Second case is used only to WARN at a later s
1 - 100 of 164 matches
Mail list logo
