On Wed, 11 Jan 2017 08:39:13 +0100,
Daniel Vetter wrote:
>
> On Tue, Jan 10, 2017 at 9:49 AM, Takashi Iwai wrote:
> > On Tue, 10 Jan 2017 09:45:31 +0100,
> >> >-Original Message-
> >> >From: Takashi Iwai [mailto:ti...@suse.de]
> >> >Sent: Tuesday, January 10, 2017 4:19 PM
> >> >To: Yang,
On Sat, Jan 07, 2017 at 12:35:36AM +, Pandiyan, Dhinakaran wrote:
> On Thu, 2017-01-05 at 09:24 +0100, Daniel Vetter wrote:
> > On Thu, Jan 05, 2017 at 03:54:54AM +, Pandiyan, Dhinakaran wrote:
> > > On Wed, 2017-01-04 at 19:20 +, Pandiyan, Dhinakaran wrote:
> > > > On Wed, 2017-01-04 a
On Mon, Jan 09, 2017 at 11:00:02AM +0200, Jani Nikula wrote:
> On Sat, 07 Jan 2017, Yadav Jyoti wrote:
> > From: Jenkins Val
> >
>
> This place here is for the commit message, where you should explain
> *why* we need this change.
>
> Where do you get the XML file? Do you write it manually? How
On Mon, Jan 09, 2017 at 01:07:56PM -0800, Francisco Jerez wrote:
> The WaDisableLSQCROPERFforOCL workaround has the side effect of
> disabling an L3SQ optimization that has huge performance implications
> and is unlikely to be necessary for the correct functioning of usual
> graphic workloads. Use
On Wed, Jan 11, 2017 at 09:00:27AM +0100, Takashi Iwai wrote:
> On Wed, 11 Jan 2017 08:39:13 +0100,
> Daniel Vetter wrote:
> >
> > On Tue, Jan 10, 2017 at 9:49 AM, Takashi Iwai wrote:
> > > On Tue, 10 Jan 2017 09:45:31 +0100,
> > >> >-Original Message-
> > >> >From: Takashi Iwai [mailto:t
Hi Daniel,
OK, I will resend the patches tomorrow. Thanks.
Hi Takashi,
In case you still need the patches for i915, it is on
git://anongit.freedesktop.org/drm-tip:drm-tip
My patches are:
commit 9a148a96fc3a654ddcf142a7ab7db37b972ba5d8
drm/i915/debugfs: add dp mst info
commit 9935f7fa285435520
From: "Lee, Shawn C"
Kernel oops was trigger by DP MST monitor/hub connected.
DP MST series patch already upstream and MST should
be support also. MST monitor will display normally with this
change on bxt platform.
Cc: Jani Nikula
Reviewed-by: Cooper Chiou
Reviewed-by: Gary C Wang
Reviewed-by
From: Tvrtko Ursulin
Since the scatterlist length field is an unsigned int, make
sure that sg_alloc_table_from_pages does not overflow it while
coallescing pages to a single entry.
v2: Drop reference to future use. Use UINT_MAX.
v3: max_segment must be page aligned.
Signed-off-by: Tvrtko Ursuli
From: Tvrtko Ursulin
Scatterlist entries have an unsigned int for the offset so
correct the sg_alloc_table_from_pages function accordingly.
Since these are offsets withing a page, unsigned int is
wide enough.
Also converts callers which were using unsigned long locally
with the lower_32_bits an
From: Tvrtko Ursulin
Drivers like i915 benefit from being able to control the maxium
size of the sg coallesced segment while building the scatter-
gather list.
Introduce and export the __sg_alloc_table_from_pages function
which will allow it that control.
v2: Reorder parameters. (Chris Wilson)
From: Tvrtko Ursulin
With the addition of __sg_alloc_table_from_pages we can control
the maximum coallescing size and eliminate a separate path for
allocating backing store here.
Similar to 871dfbd67d4e ("drm/i915: Allow compaction upto
SWIOTLB max segment size") this enables more compact sg lis
It was only needed to protect the connector_list walking, see
commit 8c4ccc4ab6f64e859d4ff8d7c02c2ed2e956e07f
Author: Daniel Vetter
Date: Thu Jul 9 23:44:26 2015 +0200
drm/probe-helper: Grab mode_config.mutex in poll_init/enable
Unfortunately the commit message of that patch fails to ment
On Wed, 11 Jan 2017, "Lee, Shawn C" wrote:
> From: "Lee, Shawn C"
>
> Kernel oops was trigger by DP MST monitor/hub connected.
Copy paste the oops to the commit message please. It's *much* easier to
match bug reports and fixes this way.
There's likely a bug report, or several bug reports about
== Series Details ==
Series: drm/i915/bxt: Add MST support when do DPLL calculation
URL : https://patchwork.freedesktop.org/series/17815/
State : warning
== Summary ==
Series 17815v1 drm/i915/bxt: Add MST support when do DPLL calculation
https://patchwork.freedesktop.org/api/1.0/series/17815/r
On Wed, Jan 11, 2017 at 09:47:41AM +0200, Joonas Lahtinen wrote:
> On ti, 2017-01-10 at 21:55 +, Chris Wilson wrote:
> > Performing an eviction search can be very, very slow especially for a
> > range restricted replacement. For example, a workload like
> > gem_concurrent_blit will populate the
== Series Details ==
Series: series starting with [1/4] lib/scatterlist: Fix offset type in
sg_alloc_table_from_pages
URL : https://patchwork.freedesktop.org/series/17816/
State : success
== Summary ==
Series 17816v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series
Performing an eviction search can be very, very slow especially for a
range restricted replacement. For example, a workload like
gem_concurrent_blit will populate the entire GTT and then cause aperture
thrashing. Since the GTT is a mix of active and inactive tiny objects,
we have to search through
Performing an eviction search can be very, very slow especially for a
range restricted replacement. For example, a workload like
gem_concurrent_blit will populate the entire GTT and then cause aperture
thrashing. Since the GTT is a mix of active and inactive tiny objects,
we have to search through
== Series Details ==
Series: series starting with [1/3] drm/i915: Use the MRU stack search after
evicting (rev3)
URL : https://patchwork.freedesktop.org/series/17784/
State : warning
== Summary ==
Series 17784v3 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/1778
Performing an eviction search can be very, very slow especially for a
range restricted replacement. For example, a workload like
gem_concurrent_blit will populate the entire GTT and then cause aperture
thrashing. Since the GTT is a mix of active and inactive tiny objects,
we have to search through
Extract drm_mm_reserve_node + calling i915_gem_evict_for_node into its
own routine so that it can be shared rather than duplicated.
v2: Kerneldoc
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Cc: igvt-g-...@lists.01.org
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_drv.h
When we evict from the GTT to make room for an object, the hole we
create is put onto the MRU stack inside the drm_mm range manager. On the
next search pass, we can speed up a PIN_HIGH allocation by referencing
that stack for the new hole.
v2: Pull together the 3 identical implements (ahem, a coup
== Series Details ==
Series: series starting with [v2,1/3] drm/i915: Use the MRU stack search after
evicting
URL : https://patchwork.freedesktop.org/series/17822/
State : success
== Summary ==
Series 17822v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/17822/re
From: Tvrtko Ursulin
Since the scatterlist length field is an unsigned int, make
sure that sg_alloc_table_from_pages does not overflow it while
coallescing pages to a single entry.
v2: Drop reference to future use. Use UINT_MAX.
v3: max_segment must be page aligned.
v4: Do not rely on compiler t
From: Tvrtko Ursulin
Drivers like i915 benefit from being able to control the maxium
size of the sg coallesced segment while building the scatter-
gather list.
Introduce and export the __sg_alloc_table_from_pages function
which will allow it that control.
v2: Reorder parameters. (Chris Wilson)
From: Tvrtko Ursulin
With the addition of __sg_alloc_table_from_pages we can control
the maximum coallescing size and eliminate a separate path for
allocating backing store here.
Similar to 871dfbd67d4e ("drm/i915: Allow compaction upto
SWIOTLB max segment size") this enables more compact sg lis
On ke, 2017-01-11 at 11:23 +, Chris Wilson wrote:
> When we evict from the GTT to make room for an object, the hole we
> create is put onto the MRU stack inside the drm_mm range manager. On the
> next search pass, we can speed up a PIN_HIGH allocation by referencing
> that stack for the new hol
Daniel Vetter writes:
> On Mon, Jan 09, 2017 at 01:07:56PM -0800, Francisco Jerez wrote:
>> The WaDisableLSQCROPERFforOCL workaround has the side effect of
>> disabling an L3SQ optimization that has huge performance implications
>> and is unlikely to be necessary for the correct functioning of us
When switching between contexts using the aliasing_ppgtt, the VM is
shared. We don't need to reload the PD registers unless they are dirty.
Martin Peres reported an issue that looks like corruption between
Haswell context switches, bisecting to commit f9326be5f1d3 ("drm/i915:
Rearrange switch_cont
On Wed, Jan 11, 2017 at 02:07:37PM +0200, Mika Kuoppala wrote:
> Daniel Vetter writes:
>
> > On Mon, Jan 09, 2017 at 01:07:56PM -0800, Francisco Jerez wrote:
> >> The WaDisableLSQCROPERFforOCL workaround has the side effect of
> >> disabling an L3SQ optimization that has huge performance implicat
On Wed, Jan 11, 2017 at 02:04:53PM +0200, Joonas Lahtinen wrote:
> On ke, 2017-01-11 at 11:23 +, Chris Wilson wrote:
> > When we evict from the GTT to make room for an object, the hole we
> > create is put onto the MRU stack inside the drm_mm range manager. On the
> > next search pass, we can s
Chris Wilson writes:
> On Wed, Jan 11, 2017 at 02:07:37PM +0200, Mika Kuoppala wrote:
>> Daniel Vetter writes:
>>
>> > On Mon, Jan 09, 2017 at 01:07:56PM -0800, Francisco Jerez wrote:
>> >> The WaDisableLSQCROPERFforOCL workaround has the side effect of
>> >> disabling an L3SQ optimization that
== Series Details ==
Series: drm/i915: Suppress switch_mm emission between the same aliasing_ppgtt
URL : https://patchwork.freedesktop.org/series/17823/
State : failure
== Summary ==
Series 17823v1 drm/i915: Suppress switch_mm emission between the same
aliasing_ppgtt
https://patchwork.freedes
From: Ville Syrjälä
While reading the HDMI 2.0 spec I noticed some new things related to
the RGB quantization range stuff, and after cross checking with
CEA-861-F I spotted a some other things as well. So I figured I should
pimp up the code a bit.
And since we now have two drivers that deal with
From: Ville Syrjälä
drm_edid.h depends on hdmi.h on account of enum hdmi_picture_aspect,
so let's just include hdmi.h and drop some useless struct declarations.
Signed-off-by: Ville Syrjälä
---
include/drm/drm_edid.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/include
From: Ville Syrjälä
HDMI 2.0 recommends that we set the Q bits in the AVI infoframe
even when the sink does not support quantization range selection (QS=0).
According to CEA-861 we can do that as long as the Q we send matches
the default quantization range for the mode.
Previosuly I think I had
From: Ville Syrjälä
Make the code selecting the RGB quantization range a little less magicy
by wrapping it up in a small helper.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c| 18 ++
drivers/gpu/drm/i915/intel_dp.c | 4 +++-
drivers/gpu/drm/i915/intel_h
From: Ville Syrjälä
CEA-861-F tells us:
"When transmitting any RGB colorimetry, the Source should set the
YQ-field to match the RGB Quantization Range being transmitted
(e.g., when Limited Range RGB, set YQ=0 or when Full Range RGB,
set YQ=1) and the Sink shall ignore the YQ-field."
So let's
From: Ville Syrjälä
Pull the logic to populate the quantization range information
in the AVI infoframe into a small helper. We'll be adding a bit
more logic to it, and having it in a central place seems like a
good idea since it's based on the CEA-861 spec.
Signed-off-by: Ville Syrjälä
---
dri
On ke, 2017-01-11 at 12:14 +, Chris Wilson wrote:
> When switching between contexts using the aliasing_ppgtt, the VM is
> shared. We don't need to reload the PD registers unless they are dirty.
>
> Martin Peres reported an issue that looks like corruption between
> Haswell context switches, bi
On Wed, Jan 11, 2017 at 12:56:03PM -, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Suppress switch_mm emission between the same aliasing_ppgtt
> URL : https://patchwork.freedesktop.org/series/17823/
> State : failure
>
> == Summary ==
>
> Series 17823v1 drm/i915: Suppress
---
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 0e280fbd52f1..1d3766cfc837 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_p
Move the GuC invalidation of its ggtt TLB to where we perform the ggtt
modification rather than proliferate it into all the callers of the
insert (which may or may not in fact have to do the insertion).
v2: Just do the guc invalidate unconditionally, (afaict) it has no impact
without the guc loade
This emulates execlists on top of the GuC in order to defer submission of
requests to the hardware. This deferral allows time for high priority
requests to gazump their way to the head of the queue, however it nerfs
the GuC by converting it back into a simple execlist (where the CPU has
to wake up
The HuC loading process is similar to GuC. The intel_uc_fw_fetch()
is used for both cases.
HuC loading needs to be before GuC loading. The WOPCM setting must
be done early before loading any of them.
v2: rebased on-top of drm-intel-nightly.
removed if(HAS_GUC()) before the guc call. (D.Gordon
On Wed, Jan 11, 2017 at 12:24:59PM +, Chris Wilson wrote:
> On Wed, Jan 11, 2017 at 02:07:37PM +0200, Mika Kuoppala wrote:
> > Daniel Vetter writes:
> >
> > > On Mon, Jan 09, 2017 at 01:07:56PM -0800, Francisco Jerez wrote:
> > >> The WaDisableLSQCROPERFforOCL workaround has the side effect o
On Wed, Jan 11, 2017 at 01:01:18PM +, Chris Wilson wrote:
> On Wed, Jan 11, 2017 at 12:56:03PM -, Patchwork wrote:
> > == Series Details ==
> >
> > Series: drm/i915: Suppress switch_mm emission between the same
> > aliasing_ppgtt
> > URL : https://patchwork.freedesktop.org/series/17823/
From: Peter Antoine
The HuC authentication is done by host2guc call. The HuC RSA keys
are sent to GuC for authentication.
v2: rebased on top of drm-intel-nightly.
changed name format and upped version 1.7.
v3: rebased on top of drm-intel-nightly.
v4: changed wait_for_automic to wait_for
v5:
Hi
The copyright statements still need the year
corrected. intel_dp_compliance needs to be added to tools/.gitignore
Some new comments also:
- Why do some of the prints have \r\n?
- Building intel_dp_compliance should actually be made conditional upon
HAVE_UDEV
--
Petri Latvala
On Fri, D
== Series Details ==
Series: drm/edid: Improve RGB limited range handling a bit
URL : https://patchwork.freedesktop.org/series/17825/
State : success
== Summary ==
Series 17825v1 drm/edid: Improve RGB limited range handling a bit
https://patchwork.freedesktop.org/api/1.0/series/17825/revisions
It is an error to start a new request on the same timeline (ringbuffer)
as the current one before the current is submitted. If there are two
requests emitting to the ringbuffer at the same time, the operation is
undefined. We can catch this by checking for the timeline having a later
seqno than our
On Wed, Jan 11, 2017 at 05:36:49AM -0800, Anusha Srivatsa wrote:
> From: Peter Antoine
>
> The HuC authentication is done by host2guc call. The HuC RSA keys
> are sent to GuC for authentication.
>
> v2: rebased on top of drm-intel-nightly.
> changed name format and upped version 1.7.
> v3: r
On Wed, Jan 11, 2017 at 05:15:14AM -0800, Anusha Srivatsa wrote:
> The HuC loading process is similar to GuC. The intel_uc_fw_fetch()
> is used for both cases.
>
> HuC loading needs to be before GuC loading. The WOPCM setting must
> be done early before loading any of them.
>
> v2: rebased on-top
Chris Wilson writes:
> It is an error to start a new request on the same timeline (ringbuffer)
> as the current one before the current is submitted. If there are two
> requests emitting to the ringbuffer at the same time, the operation is
> undefined. We can catch this by checking for the timelin
From: Ville Syrjälä
Make the code selecting the RGB quantization range a little less magicy
by wrapping it up in a small helper.
v2: s/adjusted_mode/mode in vc4 to make it actually compile
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c| 18 ++
drivers/gpu/
On ke, 2017-01-11 at 14:08 +, Chris Wilson wrote:
> It is an error to start a new request on the same timeline (ringbuffer)
> as the current one before the current is submitted. If there are two
> requests emitting to the ringbuffer at the same time, the operation is
> undefined. We can catch t
On Wed, Jan 11, 2017 at 03:13:29PM +0100, Michal Wajdeczko wrote:
> > + vma = i915_gem_object_ggtt_pin(huc_fw->obj, NULL, 0, 0, 0);
> > + if (IS_ERR(vma)) {
> > + DRM_DEBUG_DRIVER("pin failed %d\n", (int)PTR_ERR(vma));
> > + return PTR_ERR(vma);
> > + }
Just asking a stup
== Series Details ==
Series: series starting with [1/3] drm/i915: Invalidate the guc ggtt TLB upon
insertion
URL : https://patchwork.freedesktop.org/series/17829/
State : failure
== Summary ==
Series 17829v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/17829/re
On Wed, Jan 11, 2017 at 04:19:19PM +0200, Joonas Lahtinen wrote:
> On ke, 2017-01-11 at 14:08 +, Chris Wilson wrote:
> > It is an error to start a new request on the same timeline (ringbuffer)
> > as the current one before the current is submitted. If there are two
> > requests emitting to the
Psr1 and psr2 are mutually exclusive,ie when psr2 is enabled,
psr1 should be disabled.When psr2 is exited , bit 31 of reg
PSR2_CTL must be set to 0 but currently bit 31 of SRD_CTL
(psr1 control register)is set to 0.
Also ,PSR2_IDLE state is looked up from SRD_STATUS(psr1 register)
instead of PSR2_S
On Thu, Jan 05, 2017 at 02:45:37PM +0100, Christian König wrote:
> Am 05.01.2017 um 12:37 schrieb Ville Syrjälä:
> > On Wed, Jan 04, 2017 at 07:38:55PM +0100, Rainer Hochecker wrote:
> >> From: Rainer Hochecker
> >>
> >> This adds fourcc codes for 16bit planes required for DRM buffer
> >> export t
On Tue, 10 Jan 2017, Manasi Navare wrote:
> Hi All,
>
> We are seeing CRC check failures in some of the 18bpp video pattern
> DP Compliance tests causing the tests to fail. On further investigation, it is
> rootcaused to dithering that the i915 driver enables in case of 18bpp pipe
> configuration
The HuC loading process is similar to GuC. The intel_uc_fw_fetch()
is used for both cases.
HuC loading needs to be before GuC loading. The WOPCM setting must
be done early before loading any of them.
v2: rebased on-top of drm-intel-nightly.
removed if(HAS_GUC()) before the guc call. (D.Gordon
Since commit 4741da925fa3 ("drm/i915/guc: Assert that all GGTT offsets used
by the GuC are mappable"), we're asserting that GuC firmware is in the
GuC mappable range.
Except we're not pinning the object with bias, which means it's possible
to trigger this assert. Let's add a proper bias.
Cc: Chris
Screen freeze observed if AUX_FRAME_SYNC is not disabled
on psr2 exit.AUX_FRAME_SYNC needed for psr2 is enabled during
psr2 entry. It must be disabled on psr2 exit.
v2: rebase
Cc: Rodrigo Vivi
Cc: Jim Bride
Signed-off-by: Vathsala Nagaraju
Signed-off-by: Patil Deepti
Reviewed-by: Rodrigo Vivi
As per bpsec, CHICKEN_TRANS_EDP bit 12 ,15 must be programmed in
psr2 enable sequence.
bit 12 : Program Transcoder EDP VSC DIP header with a valid setting for
PSR2 and Set CHICKEN_TRANS_EDP(0x420cc) bit 12 for programmable
header packet.
bit 15 : Set CHICKEN_TRANS_EDP(0x420cc) bit 1
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 01/10/2017 11:43 PM, Daniel Vetter wrote:
> On Tue, Jan 10, 2017 at 08:52:47AM -0800, Dave Hansen wrote:
>> On 01/10/2017 02:31 AM, Daniel Vetter wrote:
>>> commit e73ab00e9a0f1731f34d0620a9c55f5c30c4ad4e
>>> Author: Daniel Vetter
>>> Date: Sun Dec 18 14:35:45 2016 +0100
>>>
>>> drm: prev
On Wed, Jan 11, 2017 at 04:17:39PM +0100, Michał Winiarski wrote:
> Since commit 4741da925fa3 ("drm/i915/guc: Assert that all GGTT offsets used
> by the GuC are mappable"), we're asserting that GuC firmware is in the
> GuC mappable range.
> Except we're not pinning the object with bias, which means
On 11/01/17 14:58, Joonas Lahtinen wrote:
On ke, 2017-01-11 at 12:14 +, Chris Wilson wrote:
When switching between contexts using the aliasing_ppgtt, the VM is
shared. We don't need to reload the PD registers unless they are dirty.
Martin Peres reported an issue that looks like corruption b
On Wed, Jan 11, 2017 at 05:09:16PM +0200, Jani Nikula wrote:
> On Tue, 10 Jan 2017, Manasi Navare wrote:
> > Hi All,
> >
> > We are seeing CRC check failures in some of the 18bpp video pattern
> > DP Compliance tests causing the tests to fail. On further investigation, it
> > is
> > rootcaused to
On Wed, Jan 11, 2017 at 4:24 PM, Dave Hansen wrote:
> On 01/10/2017 11:43 PM, Daniel Vetter wrote:
>> On Tue, Jan 10, 2017 at 08:52:47AM -0800, Dave Hansen wrote:
>>> On 01/10/2017 02:31 AM, Daniel Vetter wrote:
commit e73ab00e9a0f1731f34d0620a9c55f5c30c4ad4e
Author: Daniel Vetter
On Wed, Jan 11, 2017 at 07:24:45AM -0800, Dave Hansen wrote:
> On 01/10/2017 11:43 PM, Daniel Vetter wrote:
> > On Tue, Jan 10, 2017 at 08:52:47AM -0800, Dave Hansen wrote:
> >> On 01/10/2017 02:31 AM, Daniel Vetter wrote:
> >>> commit e73ab00e9a0f1731f34d0620a9c55f5c30c4ad4e
> >>> Author: Daniel V
On Wed, Jan 11, 2017 at 05:35:08PM +0200, Martin Peres wrote:
> On 11/01/17 14:58, Joonas Lahtinen wrote:
> >On ke, 2017-01-11 at 12:14 +, Chris Wilson wrote:
> >>When switching between contexts using the aliasing_ppgtt, the VM is
> >>shared. We don't need to reload the PD registers unless they
On 17-01-11 17:05:04, Ville Syrjälä wrote:
On Thu, Jan 05, 2017 at 02:45:37PM +0100, Christian König wrote:
Am 05.01.2017 um 12:37 schrieb Ville Syrjälä:
> On Wed, Jan 04, 2017 at 07:38:55PM +0100, Rainer Hochecker wrote:
>> From: Rainer Hochecker
>>
>> This adds fourcc codes for 16bit planes r
On 11/01/2017 13:13, Chris Wilson wrote:
Move the GuC invalidation of its ggtt TLB to where we perform the ggtt
modification rather than proliferate it into all the callers of the
insert (which may or may not in fact have to do the insertion).
v2: Just do the guc invalidate unconditionally, (af
tree: git://anongit.freedesktop.org/drm-intel for-linux-next
head: c781c978e784c50dcd7cb312fe17f5281923f55b
commit: e007b19d7ba7424735fd4f17a355b145ae153e4c [1/4] drm/i915: Use the MRU
stack search after evicting
reproduce: make htmldocs
All warnings (new ones prefixed by >>):
make[3]: wa
== Series Details ==
Series: HuC Loading Patches (rev2)
URL : https://patchwork.freedesktop.org/series/17499/
State : success
== Summary ==
Series 17499v2 HuC Loading Patches
https://patchwork.freedesktop.org/api/1.0/series/17499/revisions/2/mbox/
fi-bdw-5557u total:246 pass:232 dwarn:
This emulates execlists on top of the GuC in order to defer submission of
requests to the hardware. This deferral allows time for high priority
requests to gazump their way to the head of the queue, however it nerfs
the GuC by converting it back into a simple execlist (where the CPU has
to wake up
On Thu, Dec 15, 2016 at 03:29:43PM +0100, Maarten Lankhorst wrote:
> If the crtc was brought up with audio before the driver loads,
> then crtc_disable will remove a refcount to audio that doesn't exist
> before.
>
> Fortunately we already set power domains on readout, so we can just add
> the pow
On Thu, Dec 15, 2016 at 03:29:44PM +0100, Maarten Lankhorst wrote:
> We may keep the crtc's enabled when userspace unsets all framebuffers but
> keeps the crtc active. This exposes a WARN in fbc_global disable, and
> a lot of bugs in our hardware readout code. Solve this by disabling
> all crtc's f
On Thu, Dec 15, 2016 at 03:29:45PM +0100, Maarten Lankhorst wrote:
> From: Daniel Vetter
>
> This was somehow lost between v3 and the merged version in Maarten's
> patch merged as:
>
> commit f2d580b9a8149735cbc4b59c4a8df60173658140
> Author: Maarten Lankhorst
> Date: Wed May 4 14:38:26 2016
On 01/11/2017 07:39 AM, Daniel Vetter wrote:
> Hm, just cherry-picked it on top of Linus' latest 4.10 git, applies
> cleanly there. The substituation was for 4.9. I can send you the patch
> here, but seems all fine from what I can tell ...
All of the printk's that I added were making it fail to ap
On Wed, Jan 11, 2017 at 02:57:22PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Make the code selecting the RGB quantization range a little less magicy
> by wrapping it up in a small helper.
>
> Signed-off-by: Ville Syrjälä
Needs cc: for driver maintainers, Eric for vc
On Wed, Jan 11, 2017 at 05:16:54PM +0100, Daniel Vetter wrote:
> On Wed, Jan 11, 2017 at 02:57:22PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Make the code selecting the RGB quantization range a little less magicy
> > by wrapping it up in a small helper.
> >
> >
With kernel 4.10rc3 running as Xen dm0 I get at each boot:
[ 49.213697] [drm] GPU HANG: ecode 7:0:0x3d1d3d3d, in gnome-shell
[1431], reason: Hang on render ring, action: reset
[ 49.213699] [drm] GPU hangs can indicate a bug anywhere in the entire
gfx stack, including userspace.
[ 49.213700]
On Wed, Jan 11, 2017 at 07:44:05AM -0800, Ben Widawsky wrote:
> On 17-01-11 17:05:04, Ville Syrjälä wrote:
> >On Thu, Jan 05, 2017 at 02:45:37PM +0100, Christian König wrote:
> >> Am 05.01.2017 um 12:37 schrieb Ville Syrjälä:
> >> > On Wed, Jan 04, 2017 at 07:38:55PM +0100, Rainer Hochecker wrote:
On 11/01/2017 13:13, Chris Wilson wrote:
This emulates execlists on top of the GuC in order to defer submission of
> requests to the hardware. This deferral allows time for high priority
requests to gazump their way to the head of the queue, however it nerfs
the GuC by converting it back into
On 11/01/2017 16:11, Chris Wilson wrote:
This emulates execlists on top of the GuC in order to defer submission of
requests to the hardware. This deferral allows time for high priority
requests to gazump their way to the head of the queue, however it nerfs
the GuC by converting it back into a si
On Wed, Jan 11, 2017 at 05:33:34PM +0100, Juergen Gross wrote:
> With kernel 4.10rc3 running as Xen dm0 I get at each boot:
>
> [ 49.213697] [drm] GPU HANG: ecode 7:0:0x3d1d3d3d, in gnome-shell
> [1431], reason: Hang on render ring, action: reset
> [ 49.213699] [drm] GPU hangs can indicate a b
On Wed, Jan 11, 2017 at 04:55:46PM +, Tvrtko Ursulin wrote:
>
> On 11/01/2017 13:13, Chris Wilson wrote:
> >This emulates execlists on top of the GuC in order to defer submission of
> > requests to the hardware. This deferral allows time for high priority
> >requests to gazump their way to th
tree: git://anongit.freedesktop.org/drm-intel for-linux-next
head: c781c978e784c50dcd7cb312fe17f5281923f55b
commit: 625d988acc28f3fe1d44f3798426561c17387a59 [2/4] drm/i915: Extract
reserving space in the GTT to a helper
reproduce: make htmldocs
All warnings (new ones prefixed by >>):
make
On 20/12/2016 13:07, Chris Wilson wrote:
Some pieces of code are independent of hardware but are very tricky to
exercise through the normal userspace ABI or via debugfs hooks. Being
able to create mock unit tests and execute them through CI is vital.
Start by adding a central point where we can
The vma->exec_list is still the only means we have for both reserving an
object in execbuf, and for constructing the eviction list. So during the
construction of the eviction list, we must treat anything already on the
exec_list as being pinned.
Yes, this sharing of two semantically different list
On 20 December 2016 at 13:08, Chris Wilson wrote:
> Now that the kselftest infrastructure exists, put it to use and add to
> it the existing consistency checks on the fw register lookup tables.
>
> v2: s/tabke/table/
>
> Signed-off-by: Chris Wilson
> Cc: Tvrtko Ursulin
Reviewed-by: Matthew Auld
On 20 December 2016 at 13:08, Chris Wilson wrote:
> In addition to just testing the fw table we load, during the initial
> mock testing we can test that all tables are valid (so the testing is
> not limited to just the platforms that load that particular table).
>
> Signed-off-by: Chris Wilson
>
On 20 December 2016 at 13:08, Chris Wilson wrote:
> Add a late selftest that walks over all forcewake registers (those below
> 0x4) and checks intel_uncore_forcewake_for_reg() that the look
> exists and we having the matching powerwells.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/dr
On Wed, Jan 11, 2017 at 06:17:48PM +, Tvrtko Ursulin wrote:
> On 20/12/2016 13:07, Chris Wilson wrote:
> >@@ -522,6 +534,11 @@ static struct pci_driver i915_pci_driver = {
> > static int __init i915_init(void)
> > {
> > bool use_kms = true;
> >+int err;
> >+
> >+err = i915_mock_self
On Wed, Jan 11, 2017 at 06:25:59PM +, Matthew Auld wrote:
> On 20 December 2016 at 13:08, Chris Wilson wrote:
> > + for_each_set_bit(offset, valid, FW_RANGE) {
> > + i915_reg_t reg = { offset };
> > +
> > + intel_uncore_forcewake_reset(dev_priv, false);
> > +
== Series Details ==
Series: drm/edid: Improve RGB limited range handling a bit (rev2)
URL : https://patchwork.freedesktop.org/series/17825/
State : success
== Summary ==
Series 17825v2 drm/edid: Improve RGB limited range handling a bit
https://patchwork.freedesktop.org/api/1.0/series/17825/re
1 - 100 of 228 matches
Mail list logo
