On Thu, Apr 27, 2017 at 09:22:11AM +, Olinski, Krzysztof E wrote:
> On Thu, 2017-04-27 at 10:05 +0100, Chris Wilson wrote:
> > On Thu, Apr 27, 2017 at 10:59:18AM +0200, Krzysztof E. Olinski wrote:
> > > GuC logger implementation simplified and moved to a library
> > > (GuCLAW).
> > > Adds simpl
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 Thu, Feb 23, 2017 at 05:39:24PM +, Vivi, Rodrigo wrote:
> Reviewed-by: Rodrigo Vivi
Thanks, applied. Just noticed the odd message when browsing the gvt logs.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
On Mon, Feb 20, 2017 at 11:15:23AM +, Szwichtenberg, Radoslaw wrote:
> On Mon, 2017-02-20 at 09:47 +, Chris Wilson wrote:
> > The uncached mmio is sufficient to queue the mmio writes without raising
> > forcewake. The forced flush along with acquiring forcewake from the
> > posting read is
On Mon, Feb 20, 2017 at 11:02:10AM +, Szwichtenberg, Radoslaw wrote:
> On Sat, 2017-02-18 at 11:27 +, Chris Wilson wrote:
> > Either by chance, or by misread, the current evaluation interval may be
> > zero. If that is the case, don't divide by it!
> >
> > Signed-off-by: Chris Wilson
> Re
On Mon, Feb 20, 2017 at 08:36:31AM +, Szwichtenberg, Radoslaw wrote:
> On Sat, 2017-02-18 at 15:00 +, Chris Wilson wrote:
> > We don't need struct_mutex for acquiring an rpm wakeref, and do not need
> > to serialise those register read (it's the wrong mutex for those
> > registers in any ca
On Tue, Jan 17, 2017 at 07:05:04PM +, Vivi, Rodrigo wrote:
> same for the other...
> dm old gcc...
>
> Also my bad here since I asked Vathsala to organize like this...
>
> Anyways, for this patch
> Reviewed-by: Rodrigo Vivi
Ta, another couple of warnings squashed. We are not that far from
On Mon, Dec 05, 2016 at 09:39:49PM +, Pandiyan, Dhinakaran wrote:
> On Mon, 2016-12-05 at 08:02 +, Chris Wilson wrote:
> > On Sun, Dec 04, 2016 at 07:31:18PM -0600, Pierre-Louis Bossart wrote:
> > > 100% reproducible issue found on SKL SkullCanyon NUC with two external
> > > DP daisy-chaine
On Thu, Nov 17, 2016 at 09:03:42PM +, Vivi, Rodrigo wrote:
> On Thu, 2016-11-17 at 19:35 +, Chris Wilson wrote:
> > On Thu, Nov 17, 2016 at 11:06:54AM -0800, Rodrigo Vivi wrote:
> > > On Thu, Nov 17, 2016 at 10:53:04AM +0200, David Weinehall wrote:
> > > > On Tue, Nov 15, 2016 at 02:21:01PM
On Thu, Sep 22, 2016 at 04:05:51PM -0300, Paulo Zanoni wrote:
> Em Qua, 2016-09-14 às 09:40 +0100, ch...@chris-wilson.co.uk escreveu:
> > On Tue, Sep 13, 2016 at 03:21:48PM +0300, Mika Kuoppala wrote:
> > >
> > > Mika Kuoppala writes:
> > >
On Tue, Sep 13, 2016 at 03:21:48PM +0300, Mika Kuoppala wrote:
> Mika Kuoppala writes:
> > "Zanoni, Paulo R" writes:
> >>> +#if IS_ENABLED(CONFIG_LOCKDEP)
> >>> + GEM_BUG_ON(!!lockdep_is_held(&req->i915->drm.struct_mutex)
> >>> !=
> >>> + !!(flags & I915_WAIT_LOCKED));
> >>> +#endif
>
On Wed, Aug 24, 2016 at 09:14:59PM +, Zanoni, Paulo R wrote:
> Em Qua, 2016-08-24 às 19:00 +0100, Chris Wilson escreveu:
> > . In the meantime lets hope that all
> > framebuffers are idle and naturally fit within the mappable aperture.
>
> What exactly do you mean with the sentence above? Is t
On Wed, Aug 17, 2016 at 08:00:09PM +, Zanoni, Paulo R wrote:
> Em Qua, 2016-08-17 às 20:49 +0100, Chris Wilson escreveu:
> > On Wed, Aug 17, 2016 at 04:41:44PM -0300, Paulo Zanoni wrote:
> > >
> > > From: Chris Wilson
> > >
> > > intel_fbc_pre_update() depends upon the new state being alread
On Thu, Aug 18, 2016 at 01:56:56PM +, Zanoni, Paulo R wrote:
> Em Qui, 2016-08-18 às 09:21 +0100, Chris Wilson escreveu:
> > Only fbc1 is tied to using a fence. Later iterations of fbc are more
> > flexible and allow operation on unfenced frontbuffers.
>
> But then we'll lose GTT tracking - wh
On Tue, Aug 16, 2016 at 04:49:26PM +, Zanoni, Paulo R wrote:
> Em Ter, 2016-08-16 às 08:43 +0100, Chris Wilson escreveu:
> > intel_fbc_pre_update() depends upon the new state being already
> > pinned
> > in place in the Global GTT (primarily for both fencing which wants
> > both
> > an offset a
On Mon, Aug 15, 2016 at 10:47:18PM +, Zanoni, Paulo R wrote:
> Em Seg, 2016-08-15 às 21:55 +0100, Chris Wilson escreveu:
> > So this change is broken as intel_fbc_pre_update() depends upon state
> > derived from the pinned framebuffer object but is being called by
> > intel_crtc_page_flip() bef
On Thu, Aug 04, 2016 at 04:50:35PM +, Pandiyan, Dhinakaran wrote:
> On Thu, 2016-08-04 at 04:12 +0100, Chris Wilson wrote:
> > On Wed, Aug 03, 2016 at 08:07:40PM -0700, Dhinakaran Pandiyan wrote:
> > > The causes of clock recovery and channel equalization failures are not
> > > explicitly print
On Mon, Jul 11, 2016 at 04:24:50PM +0300, Imre Deak wrote:
> On ma, 2016-07-11 at 13:55 +0100, ch...@chris-wilson.co.uk wrote:
> > And then you get random changes in the firmare whilst bisecting the
> > kernel.
>
> What do you mean random? During bisecting we want to load t
On Mon, Jul 11, 2016 at 03:45:21PM +0300, Imre Deak wrote:
> On ma, 2016-07-11 at 13:39 +0100, ch...@chris-wilson.co.uk wrote:
> > On Mon, Jul 11, 2016 at 02:23:48PM +0300, Imre Deak wrote:
> > > On to, 2016-07-07 at 17:57 +0300, Mika Kuoppala wrote:
> > >
On Mon, Jul 11, 2016 at 02:23:48PM +0300, Imre Deak wrote:
> On to, 2016-07-07 at 17:57 +0300, Mika Kuoppala wrote:
> > "Vivi, Rodrigo" writes:
> >
> > > Nak.
> > >
> > > I don't intend to update the symbolic links on linux-firmware.git
> > > repository anymore so if we receive a new minor versi
On Fri, Jun 17, 2016 at 07:02:57PM +, Zanoni, Paulo R wrote:
> Em Sex, 2016-06-17 às 17:39 +0100, Chris Wilson escreveu:
> > Erratum SKL075: Display Flicker May Occur When Both VT-d And FBC Are
> > Enabled
> >
> > "Display flickering may occur when both FBC (Frame Buffer
> > Compression)
> > a
On Tue, Mar 29, 2016 at 01:55:02PM +0200, Daniel Vetter wrote:
> *Blonk* or whatever the sound for suddenly realization is. Totally forgot
> that we're reuseding set_domain(GTT) for wc mmaps because this it's a nice
> trick.
>
> Otoh, is that trick the reason why wc mmaps aren't coherent enough? O
On Fri, Mar 25, 2016 at 02:05:42PM +, Zanoni, Paulo R wrote:
> What if I have both a WC mmap and a GTT mmap, and I'm actually using
> the GTT mmap now? My set_domain call will be treated as WC mmap usage,
> while in fact it should be treated as GTT usage. Is there a way to
> differentiate betwe
On Thu, Mar 24, 2016 at 09:21:49PM +, Zanoni, Paulo R wrote:
> Em Qui, 2016-03-24 às 21:03 +0000, ch...@chris-wilson.co.uk escreveu:
> > On Thu, Mar 24, 2016 at 08:53:21PM +, Zanoni, Paulo R wrote:
> > >
> > > Em Qui, 2016-03-24 às 19:31 +, Chris Wilson es
On Thu, Mar 24, 2016 at 09:03:59PM +, ch...@chris-wilson.co.uk wrote:
> On Thu, Mar 24, 2016 at 08:53:21PM +, Zanoni, Paulo R wrote:
> > Em Qui, 2016-03-24 às 19:31 +, Chris Wilson escreveu:
> > > On Thu, Mar 24, 2016 at 04:16:11PM -0300, Paulo Zanoni wrote:
> &
On Thu, Mar 24, 2016 at 08:53:21PM +, Zanoni, Paulo R wrote:
> Em Qui, 2016-03-24 às 19:31 +, Chris Wilson escreveu:
> > On Thu, Mar 24, 2016 at 04:16:11PM -0300, Paulo Zanoni wrote:
> > >
> > > FBC and the frontbuffer tracking infrastructure were designed
> > > assuming
> > > that user sp
On Wed, Dec 02, 2015 at 05:19:33PM +, Zanoni, Paulo R wrote:
> Em Qua, 2015-12-02 às 12:37 +, Chris Wilson escreveu:
> > My r-b still stand.
>
> What about patch 6? Any concerns or additional requests?
> drm/i915: alloc/free the FBC CFB during enable/disable
I thought I had spotted one
On Fri, Nov 13, 2015 at 09:17:04PM +, Zanoni, Paulo R wrote:
> Em Sex, 2015-11-13 às 21:03 +, Chris Wilson escreveu:
> > On Fri, Nov 13, 2015 at 05:53:41PM -0200, Paulo Zanoni wrote:
> > > Instead of waiting for 50ms, just wait until the next vblank, since
> > > it's the minimum requirement
On Wed, Oct 28, 2015 at 05:24:18PM +, Zanoni, Paulo R wrote:
> Em Ter, 2015-10-27 às 20:29 +, Chris Wilson escreveu:
> > On Tue, Oct 27, 2015 at 02:50:25PM -0200, Paulo Zanoni wrote:
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > b/drivers/gpu/drm/i915/i915_drv.h
> > > index a9434
On Wed, Oct 21, 2015 at 06:19:23PM +, Zanoni, Paulo R wrote:
> Em Qua, 2015-10-21 às 14:01 +0100, Chris Wilson escreveu:
> > On Tue, Oct 20, 2015 at 11:49:59AM -0200, Paulo Zanoni wrote:
> > > If we run igt/kms_frontbuffer_tracking, this message will appear
> > > thousands of times, eating a si
On Wed, Oct 21, 2015 at 05:27:32PM +, Zanoni, Paulo R wrote:
> Em Ter, 2015-10-20 às 17:03 +0100, Chris Wilson escreveu:
> > On Tue, Oct 20, 2015 at 11:49:51AM -0200, Paulo Zanoni wrote:
> > > This thing where we need to get the crtc either from the work
> > > structure or the fbc structure its
On Wed, Oct 21, 2015 at 05:45:33PM +, Zanoni, Paulo R wrote:
> Em Qua, 2015-10-21 às 13:34 +0100, Chris Wilson escreveu:
> > On Tue, Oct 20, 2015 at 11:49:56AM -0200, Paulo Zanoni wrote:
> > > The long term goal is to have enable/disable as the higher level
> > > functions and activate/deactiva
On Wed, Oct 21, 2015 at 05:32:16PM +, Zanoni, Paulo R wrote:
> Em Qua, 2015-10-21 às 13:37 +0100, Chris Wilson escreveu:
> > On Tue, Oct 20, 2015 at 11:49:53AM -0200, Paulo Zanoni wrote:
> > > Don't try to list in comments the cases where we should enable or
> > > disable FBC: it varies a lot w
On Wed, Oct 21, 2015 at 05:08:42PM +, Zanoni, Paulo R wrote:
> Em Ter, 2015-10-20 às 16:59 +0100, Chris Wilson escreveu:
> > On Tue, Oct 20, 2015 at 11:49:49AM -0200, Paulo Zanoni wrote:
> > > There's no need to stop and restart FBC: a nuke should be fine.
> > >
> > > Signed-off-by: Paulo Zano
On Wed, Oct 21, 2015 at 05:16:04PM +, Zanoni, Paulo R wrote:
> Em Ter, 2015-10-20 às 16:52 +0100, Chris Wilson escreveu:
> > On Tue, Oct 20, 2015 at 11:49:50AM -0200, Paulo Zanoni wrote:
> > > We're going to kill intel_fbc_find_crtc(), that's why a big part of
> > > the logic moved from intel_f
On Thu, Sep 03, 2015 at 02:01:51PM +, Zanoni, Paulo R wrote:
> Em Qui, 2015-09-03 às 13:01 +0100, Chris Wilson escreveu:
> > A small, very small, step to sharing the duplicate code between
> > execlists and legacy submission engines, starting with the ringbuffer
> > allocation code.
> >
> > Si
On Wed, Sep 02, 2015 at 08:20:52PM +, Zanoni, Paulo R wrote:
> Em Qua, 2015-08-26 às 08:44 +0100, Chris Wilson escreveu:
> > On Tue, Aug 25, 2015 at 07:03:42PM -0300, Paulo Zanoni wrote:
> > > The unclaimed register bit is only triggered when someone touches
> > > the
> > > specified register
On Tue, Aug 18, 2015 at 09:49:34PM +, Zanoni, Paulo R wrote:
> Em Sáb, 2015-08-15 às 09:29 +0100, Chris Wilson escreveu:
> > On Fri, Aug 14, 2015 at 06:34:13PM -0300, Paulo Zanoni wrote:
> > > The FBC hardware for these platforms doesn't have access to the
> > > bios_reserved range, so it alway
On Tue, Aug 18, 2015 at 09:54:57PM +, Zanoni, Paulo R wrote:
> Em Sáb, 2015-08-15 às 09:24 +0100, Chris Wilson escreveu:
> > On Fri, Aug 14, 2015 at 06:34:20PM -0300, Paulo Zanoni wrote:
> > > This reverts commit 0ffb0ff283cca16f72caf29c44496d83b0c291fb.
> > >
> > > Technology has evolved and
On Thu, Jun 18, 2015 at 04:25:47PM +0100, Damien Lespiau wrote:
> >>On Thu, Jun 18, 2015 at 03:45:44PM +0100, Antoine, Peter wrote:
> >> So, intializing the other (non-render) MOCS in gen8_init_rcs_context()
> >> isn't the most logical thing to do I'm afraid. What happens if we
> >> suddenly decide
On Thu, Jun 18, 2015 at 08:45:10AM +, Antoine, Peter wrote:
> On Thu, 2015-06-18 at 08:49 +0100, ch...@chris-wilson.co.uk wrote:
> > On Thu, Jun 18, 2015 at 07:36:41AM +, Antoine, Peter wrote:
> > >
> > > On Wed, 2015-06-17 at 17:33 +0100, Chris Wilson wrote:
&
On Thu, Jun 18, 2015 at 07:36:41AM +, Antoine, Peter wrote:
>
> On Wed, 2015-06-17 at 17:33 +0100, Chris Wilson wrote:
> > On Wed, Jun 17, 2015 at 04:19:22PM +0100, Peter Antoine wrote:
> > > This change adds the programming of the MOCS registers to the gen 9+
> > > platforms. This change set
On Wed, Jun 17, 2015 at 03:02:31PM +, Antoine, Peter wrote:
> On Wed, 2015-06-10 at 11:37 +0100, Chris Wilson wrote:
> > > +/* Defines for the tables (XXX_MOCS_0 - XXX_MOCS_63) */
> > > +#define MOCS_CACHEABILITY(value)((value & 0x03) << 0)
> >
> > value & mask? These macros should on
On Tue, Apr 28, 2015 at 10:21:49AM +0100, Dave Gordon wrote:
> On 24/04/15 06:52, Antoine, Peter wrote:
> > I picked up this work due to the following Jira ticket created by the
> > security team (on Android) and was asked to give it a second look and
> > found a few more issues with the hw lock co
On Tue, Apr 28, 2015 at 09:28:51AM +, Antoine, Peter wrote:
> Also, the PARAM should give legitimate code the opportunity to avoid the
> problems but avoiding these features completely.
There are no legitimate users.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
On Wed, Mar 25, 2015 at 08:37:29PM +, Vivi, Rodrigo wrote:
> Also talking about visible names I'm not sure about "Idle" as well...
> Every time I read it get confused... I believe it is because PSR active
> needs Idle usage...
>
> What do you think about changing to Idle to Enable-Exit and Act
On Wed, Mar 25, 2015 at 07:27:35PM +, Vivi, Rodrigo wrote:
> On Tue, 2015-03-24 at 22:05 +0000, ch...@chris-wilson.co.uk wrote:
> > On Tue, Mar 24, 2015 at 08:55:04PM +, Vivi, Rodrigo wrote:
> > > On Tue, 2015-03-24 at 10:08 +, Chris Wilson wrote:
> > > >
On Tue, Mar 24, 2015 at 08:55:04PM +, Vivi, Rodrigo wrote:
> On Tue, 2015-03-24 at 10:08 +, Chris Wilson wrote:
> > On Tue, Mar 24, 2015 at 11:03:30AM +0100, Daniel Vetter wrote:
> > > On Mon, Mar 23, 2015 at 01:20:07PM -0700, Rodrigo Vivi wrote:
> > > > Hi Daniel,
> > > >
> > > > Is somet
On Wed, Feb 06, 2013 at 11:43:51PM +, Kamble, Nitin A wrote:
> Chris,
>
> X is failing even with this reduced 1 screen config.
>
> Section "Device"
> Identifier "Intel0"
> Driver "intel"
> BusID "PCI:00:02:0"
> Option "ZaphodHeads" "HDMI-A-1"
The ZaphodHead c
On Wed, Feb 06, 2013 at 11:00:49PM +, Kamble, Nitin A wrote:
> Thanks Chris for the reply. Attached are all the relevant log files.
Both screen stanzas are pointing to the same device.
It should be:
Screen0 -> Device0,
Screen1 -> Device1
-Chris
--
Chris Wilson, Intel Open Source Technolo
On Wed, Feb 06, 2013 at 06:43:53PM +, Kamble, Nitin A wrote:
>
> On a Intel core i3 (ivybridge) system (NUC) with 2 HDMI ports, I am trying to
> get two independent screens by following this method.
> http://en.gentoo-wiki.com/wiki/X.Org/
> Dual_Monitors#Single_graphics_card.2C_Multiple_X_scre
51 matches
Mail list logo
