On 19/12/16 01:51, Chris Wilson wrote:
On Sun, Dec 18, 2016 at 09:02:33PM -0800, Michel Thierry wrote:
On 12/16/2016 12:45 PM, Chris Wilson wrote:
On Fri, Dec 16, 2016 at 12:20:05PM -0800, Michel Thierry wrote:
From: Arun Siluvery
This change implements support for per-engine reset as an
On Wed, 2017-01-04 at 11:42 +0100, Peter Frühberger wrote:
> Forgot to CC the list, sorry.
>
> On Wed, Jan 4, 2017 at 11:42 AM, Peter Frühberger
> wrote:
> Hi Jani,
> thanks for your reply
>
> On Wed, Jan 4, 2017 at 10:34 AM, Jani Nikula
> wrote:
>
== Series Details ==
Series: drm/i915: Extending DC9 support for GEN9_LP.
URL : https://patchwork.freedesktop.org/series/17568/
State : warning
== Summary ==
Series 17568v1 drm/i915: Extending DC9 support for GEN9_LP.
https://patchwork.freedesktop.org/api/1.0/series/17568/revisions/1/mbox/
Te
On Tue, Jan 03, 2017 at 10:27:51PM +0530, vathsala nagaraju wrote:
> Program EDP_PSR_DEBUG_CTL (PSR_MASK) to enable system
> to go to deep sleep while in psr2.PSR2_STATUS bit 31:28
> should report value 8 , if system enters deep sleep state.
>
> Also, EDP_FRAMES_BEFORE_SU_ENTRY is set 1 , if not s
On Fri, 2017-01-06 at 00:55 +0530, vathsala nagaraju wrote:
> 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_ID
All gen9-lp platform has support for DC9 (lowest power state of display
engine). Modified the condition check for enabling/disabling DC9.
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/i915_drv.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i
On Mon, Jan 02, 2017 at 05:00:58PM +0530, vathsala nagaraju wrote:
> As per edp1.4 spec , alpm is required for psr2 operation as it's
> used for all psr2 main link power down management and alpm enable
> bit must be set for psr2 operation.
>
> Cc: Rodrigo Vivi
> Cc: Jim Bride
> Signed-off-by: v
On Fri, Jan 06, 2017 at 12:55:59AM +0530, vathsala nagaraju wrote:
> 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 ,
== Series Details ==
Series: 4.10-rc2 oops in DRM connector code
URL : https://patchwork.freedesktop.org/series/17563/
State : success
== Summary ==
Series 17563v1 4.10-rc2 oops in DRM connector code
https://patchwork.freedesktop.org/api/1.0/series/17563/revisions/1/mbox/
fi-bdw-5557u to
On 6 January 2017 at 04:29, Linus Torvalds
wrote:
> On Thu, Jan 5, 2017 at 3:19 AM, Jani Nikula wrote:
>>
>> Hi Dave, or Linus if Dave's on vacation, I'm a bit unsure,
>
> I'm going to ignore this on the assumption that Dave is around. But if
> nothing happens for a few days, ping me again and I'
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
My Thinkpad x260 doesn't like to be unplugged from its dock. I don't
think this is a new bug. It's happening on my distro's 4.4 kernel
as well.
The actual oops is in device_del(). It appears to have been passed a
null 'struct device *'.
There appears to have been a race _around_ here fixed in
== Series Details ==
Series: drm/i915: Only skip requests once a context is banned (rev2)
URL : https://patchwork.freedesktop.org/series/17404/
State : success
== Summary ==
Series 17404v2 drm/i915: Only skip requests once a context is banned
https://patchwork.freedesktop.org/api/1.0/series/17
On Thu, Jan 5, 2017 at 3:19 AM, Jani Nikula wrote:
>
> Hi Dave, or Linus if Dave's on vacation, I'm a bit unsure,
I'm going to ignore this on the assumption that Dave is around. But if
nothing happens for a few days, ping me again and I'll pull it
directly. Ok?
Linus
__
== Series Details ==
Series: drm/i915: Move a few more utility macros to i915_utils.h
URL : https://patchwork.freedesktop.org/series/17557/
State : success
== Summary ==
Series 17557v1 drm/i915: Move a few more utility macros to i915_utils.h
https://patchwork.freedesktop.org/api/1.0/series/175
On Mon, Jan 02, 2017 at 05:00:56PM +0530, vathsala nagaraju wrote:
> 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 ,
makes sense
Reviewed-by: Rodrigo Vivi
On Mon, Jan 02, 2017 at 05:00:57PM +0530, vathsala nagaraju wrote:
> 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.
>
> Cc: Rodrigo
Please don't forget about the bit 11 for KBL. In a separated patch.
This patch is correct and count with my rv-b, but I believe the best place for
this is
on intel_psr_enable, right after setup_vsc.
On Mon, Jan 02, 2017 at 05:00:59PM +0530, vathsala nagaraju wrote:
> As per bpsec, CHICKEN_TRAN
On Mon, Jan 02, 2017 at 05:01:01PM +0530, vathsala nagaraju wrote:
> Psr2 is enabled only for y cordinate panels.Once GTC (global time code)
> is implemented,this restriction is removed so that psr2
> can work on panels without y cordinate support.
>
> Cc: Rodrigo Vivi
> Cc: Jim Bride
> Signed-o
I like this live status!
On Mon, Jan 02, 2017 at 05:01:02PM +0530, vathsala nagaraju wrote:
> Reports live state of PSR2 form PSR2_STATUS register.
> bit field 31:28 gives the live state of PSR2.
> It can be used to check if system is in deep sleep,
> selective update or selective update standby
On 17-01-05 16:24:56, Tvrtko Ursulin wrote:
On 04/01/2017 18:42, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä
SKL+ display engine can scan out certain kinds of compressed surfaces
produced by the render engine. This involved telling the display engine
the location of the color con
On Mon, Jan 02, 2017 at 05:01:03PM +0530, vathsala nagaraju wrote:
> PSR1 and PSR2 enable sequence are mutually exclusive.
> Register SRD_PERF_COUNT increments while system is in psr1.
> This register is not valid for psr2.while in psr2,SRD_PERF_COUNT
> is always 0.
> Reporting psr perfcount from S
On 05/01/2017 16:41, Chris Wilson wrote:
Now that we have split out a header file for simple macros (that maybe
we can promote into a core header), move a few macros across from
i915_drv.h
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h | 20
drivers/gpu
If we skip before banning, we have an inconsistent interface between
execbuf still queueing valid request but those requests already queued
being cancelled. If we only cancel the pending requests once we stop
accepting new requests, the user interface is more consistent.
Reported-by: Tvrtko Ursuli
== Series Details ==
Series: drm/i915: initialize ret in i915_gem_evict_something (rev2)
URL : https://patchwork.freedesktop.org/series/17552/
State : warning
== Summary ==
Series 17552v2 drm/i915: initialize ret in i915_gem_evict_something
https://patchwork.freedesktop.org/api/1.0/series/1755
On Thu, Jan 05, 2017 at 04:36:06PM +, Matthew Auld wrote:
> On 5 January 2017 at 16:33, Chris Wilson wrote:
> > On Thu, Jan 05, 2017 at 03:59:40PM +, Chris Wilson wrote:
> >> Missed when rebasing patches, I failed to set ret to zero before
> >> starting the unbind loop (which depends upon
On 5 January 2017 at 16:41, Chris Wilson wrote:
> Now that we have split out a header file for simple macros (that maybe
> we can promote into a core header), move a few macros across from
> i915_drv.h
>
> Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
Now that we have split out a header file for simple macros (that maybe
we can promote into a core header), move a few macros across from
i915_drv.h
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h | 20
drivers/gpu/drm/i915/i915_utils.h | 20
On 5 January 2017 at 16:33, Chris Wilson wrote:
> On Thu, Jan 05, 2017 at 03:59:40PM +, Chris Wilson wrote:
>> Missed when rebasing patches, I failed to set ret to zero before
>> starting the unbind loop (which depends upon ret being zero).
>>
>> Reported-by: Matthew Auld
>> Fixes: 9332f3b1b9
On Thu, Jan 05, 2017 at 03:59:40PM +, Chris Wilson wrote:
> Missed when rebasing patches, I failed to set ret to zero before
> starting the unbind loop (which depends upon ret being zero).
>
> Reported-by: Matthew Auld
> Fixes: 9332f3b1b99a ("drm/i915: Combine loops within
> i915_gem_evict_s
On 04/01/2017 18:42, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä
SKL+ display engine can scan out certain kinds of compressed surfaces
produced by the render engine. This involved telling the display engine
the location of the color control surfae (CCS) which describes which
parts
== Series Details ==
Series: series starting with [CI,1/5] drm/i915: Assert all timeline requests
are gone before fini
URL : https://patchwork.freedesktop.org/series/17556/
State : success
== Summary ==
Series 17556v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/serie
Missed when rebasing patches, I failed to set ret to zero before
starting the unbind loop (which depends upon ret being zero).
Reported-by: Matthew Auld
Fixes: 9332f3b1b99a ("drm/i915: Combine loops within i915_gem_evict_something")
Signed-off-by: Chris Wilson
Cc: Matthew Auld
---
drivers/gpu/
== Series Details ==
Series: drm/i915: SKL+ render decompression support (rev2)
URL : https://patchwork.freedesktop.org/series/17507/
State : failure
== Summary ==
Series 17507v2 drm/i915: SKL+ render decompression support
https://patchwork.freedesktop.org/api/1.0/series/17507/revisions/2/mbox
== Series Details ==
Series: drm/i915: initialize ret in i915_gem_evict_something
URL : https://patchwork.freedesktop.org/series/17552/
State : success
== Summary ==
Series 17552v1 drm/i915: initialize ret in i915_gem_evict_something
https://patchwork.freedesktop.org/api/1.0/series/17552/revis
Empirically we restart following a GPU reset more successfully if we call
lrc_init_hws() (which contains a posting read) last. (The failure mode
that was observed was that breadcrumb writes into the HWS from the
recovered requests went astray leading to the context-switch maintaining
forward progre
The GuC uses a special mapping for the upper end of the Global GTT,
similar to the way it uses a special mapping for the lower end, so
exclude it from our drm_mm to prevent us using it.
v2: Rename to reflect that it is unmappable similar to the region at the
bottom of the GGTT, and couple it into
In order to defeat some circular dependencies between headers to allow use
of e.g. range_overflows() in a header, move the simple independent macros
into their own header.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drv.h | 13 +---
drivers/gp
During i915_gem_timeline_fini(), assert that all the timeline's request
are completed and removed from the timeline.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem_timeline.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff
In order to convince static analyzers that the allocation function
returns an error or sets ce->state, assert that it is set afterwards.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_lrc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/d
On 5 January 2017 at 15:13, Chris Wilson wrote:
> On Thu, Jan 05, 2017 at 02:41:31PM +, Matthew Auld wrote:
>> If we find a suitable victim node on our first pass, then ret
>> will be uninitialized which could lead to some funny business later.
>>
>> Fixes: 9332f3b1b99a ("drm/i915: Combine loo
From: Ville Syrjälä
SKL+ display engine can scan out certain kinds of compressed surfaces
produced by the render engine. This involved telling the display engine
the location of the color control surfae (CCS) which describes
which parts of the main surface are compressed and which are not. The
lo
On Thu, Jan 05, 2017 at 02:41:31PM +, Matthew Auld wrote:
> If we find a suitable victim node on our first pass, then ret
> will be uninitialized which could lead to some funny business later.
>
> Fixes: 9332f3b1b99a ("drm/i915: Combine loops within
> i915_gem_evict_something")
> Cc: Chris Wi
On Wed, Jan 04, 2017 at 05:14:04PM -0200, Paulo Zanoni wrote:
> Em Qua, 2017-01-04 às 20:42 +0200, ville.syrj...@linux.intel.com
> escreveu:
> > From: Ville Syrjälä
> >
> > SKL+ display engine can scan out certain kinds of compressed surfaces
> > produced by the render engine. This involved telli
On Wed, Jan 04, 2017 at 08:25:23PM -0800, Ben Widawsky wrote:
> On 17-01-04 20:42:32, Ville Syrjälä wrote:
> >From: Ville Syrjälä
> >
> >SKL+ display engine can scan out certain kinds of compressed surfaces
> >produced by the render engine. This involved telling the display engine
> >the location
On Thu, 2017-01-05 at 09:52 +0100, Daniel Vetter wrote:
> On Thu, Jan 05, 2017 at 10:41:07AM +0200, Jani Nikula wrote:
> > No matter what we do here, the question remains what to do with
> > Chamelium. Changing the color range is really a workaround for
> > Chamelium, not a fix. Using CEA range is
If we find a suitable victim node on our first pass, then ret
will be uninitialized which could lead to some funny business later.
Fixes: 9332f3b1b99a ("drm/i915: Combine loops within i915_gem_evict_something")
Cc: Chris Wilson
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_gem_evict
On Wed, Jan 04, 2017 at 06:55:54AM -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
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 to mesa.
Signed-off-by: Rainer Hochecker
Reviewed-by: Ville Syrjälä
Good to see so
On Wed, Jan 04, 2017 at 06:55:48AM -0800, Anusha Srivatsa wrote:
> From: Peter Antoine
>
> Rename some of the GuC fw loading code to make them more general. We
> will utilise them for HuC loading as well.
> s/intel_guc_fw/intel_uc_fw/g
> s/GUC_FIRMWARE/UC_FIRMWARE/g
>
> Struct intel_gu
On Wed, Jan 04, 2017 at 06:55:54AM -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 04, 2017 at 06:55:54AM -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 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 to mesa.
>
> Signed-off-by: Rainer Hochecker
Reviewed-by: Ville Syrjälä
> ---
> include/uapi/drm/drm_fourcc.h | 7 +++
>
Hi Dave, or Linus if Dave's on vacation, I'm a bit unsure,
Here's a bunch of drm/i915 fixes for v4.10-rc3. It includes GVT-g fixes,
which apparently have a conflict with Alex's (Cc'd) upcoming vfio
changes [1]. So heads up.
My new year's resolution is to start using signed tags for pulls. If
tha
Hi Jani,
On Thu, 05 Jan 2017 12:24:13 +0200 Jani Nikula
wrote:
>
> Daniel reverted it in drm-misc.
OK, thanks.
--
Cheers,
Stephen Rothwell
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/inte
On Thu, 05 Jan 2017, Stephen Rothwell wrote:
> Hi all,
>
> After merging the drm-misc tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> drivers/usb/Kconfig:39:error: recursive dependency detected!
> drivers/usb/Kconfig:39: symbol USB is selected by MOUSE_APPLETOUCH
>
Hi,
On 5 January 2017 at 08:52, Daniel Vetter wrote:
> On Thu, Jan 05, 2017 at 10:41:07AM +0200, Jani Nikula wrote:
>> No matter what we do here, the question remains what to do with
>> Chamelium. Changing the color range is really a workaround for
>> Chamelium, not a fix. Using CEA range is perf
On Thu, Jan 05, 2017 at 09:12:17AM +0200, Mika Kahola wrote:
> Remove reference to drm/drm_edid.h and drm/drmP.h as these are no longer
> required.
>
> Signed-off-by: Mika Kahola
> ---
> drivers/gpu/drm/i915/intel_display.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/d
After this patch we got some failures in CI for anything not connected
to eDP. sink_crc.supported now defaults to true, so perhaps...
diff --git a/tests/kms_frontbuffer_tracking.c b/tests/kms_frontbuffer_tracking.c
index b91f08b..b84721f 100644
--- a/tests/kms_frontbuffer_tracking.c
+++ b/tests/
Hi,
On Thu, Jan 5, 2017 at 9:52 AM, Daniel Vetter wrote:
> On Thu, Jan 05, 2017 at 10:41:07AM +0200, Jani Nikula wrote:
> > No matter what we do here, the question remains what to do with
> > Chamelium. Changing the color range is really a workaround for
> > Chamelium, not a fix. Using CEA range
On Wed, Jan 04, 2017 at 11:44:29AM +, Chris Wilson wrote:
> The fbcon imposes unpredictable latencies on tests - each drmIoctl has
> been observed to trigger two 650us calls to console_unlock() as it
> flushes printk buffer for the DRM_DEBUG around the ioctl. This makes
> tests such as gem_wait
On Thu, Jan 05, 2017 at 10:41:07AM +0200, Jani Nikula wrote:
> No matter what we do here, the question remains what to do with
> Chamelium. Changing the color range is really a workaround for
> Chamelium, not a fix. Using CEA range is perfectly fine per DP spec.
Can we just set a non-CEA mode/edid
On Wed, Jan 04, 2017 at 07:15:34PM -0800, Ben Widawsky wrote:
> On 17-01-04 20:42:24, Ville Syrjälä wrote:
> > From: Ville Syrjälä
> >
> > Allow drivers to return a custom drm_format_info structure for special
> > fb layouts. We'll use this for the compression control surface in i915.
> >
> > v2
On Thu, 05 Jan 2017, Lyude wrote:
> Until now, it seems we've been erroneously enabling limited color ranges
> for the vast majority of DisplayPort monitors. I noticed this after
> writing a frame dump comparison test for the Chamelium and noticing that
> every i915 device I had was failing, while
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 at 10:33 +0100, Daniel Vetter wrote:
> > > On Tue, Jan 03, 2017 at 01:01:49PM -0800, Dhinakaran Pandiyan wrote:
> > > > Link bandwidth is sha
65 matches
Mail list logo
