Em Ter, 2016-07-05 às 10:28 +0100, Matthew Auld escreveu:
> The fbc enabled/active sanity checks are already done in
> __intel_fbc_disable so no need to do them again.
>
> Signed-off-by: Matthew Auld
Reviewed-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/intel_fbc.c | 5 +
> 1 file change
On Sat, 2022-06-25 at 18:49 -0700, Niranjana Vishwanathapura wrote:
> VM_BIND and related uapi definitions
>
> v2: Reduce the scope to simple Mesa use case.
> v3: Expand VM_UNBIND documentation and add
> I915_GEM_VM_BIND/UNBIND_FENCE_VALID
> and I915_GEM_VM_BIND_TLB_FLUSH flags.
> v4: Remo
On Sat, 2022-06-25 at 18:49 -0700, Niranjana Vishwanathapura wrote:
> VM_BIND design document with description of intended use cases.
>
> v2: Reduce the scope to simple Mesa use case.
> v3: Expand documentation on dma-resv usage, TLB flushing and
> execbuf3.
> v4: Remove vm_bind tlb flush requ
On Wed, 2022-06-29 at 23:08 -0700, Niranjana Vishwanathapura wrote:
> On Wed, Jun 29, 2022 at 05:33:49PM -0700, Zanoni, Paulo R wrote:
> > On Sat, 2022-06-25 at 18:49 -0700, Niranjana Vishwanathapura wrote:
> > > VM_BIND and related uapi definitions
> > >
> > >
On Thu, 2022-06-30 at 09:18 -0700, Niranjana Vishwanathapura wrote:
> On Wed, Jun 29, 2022 at 11:39:52PM -0700, Zanoni, Paulo R wrote:
> > On Wed, 2022-06-29 at 23:08 -0700, Niranjana Vishwanathapura wrote:
> > > On Wed, Jun 29, 2022 at 05:33:49PM -0700, Zanoni, Paulo R wrote:
&g
On Tue, 2022-05-17 at 11:32 -0700, Niranjana Vishwanathapura wrote:
> VM_BIND design document with description of intended use cases.
>
> v2: Add more documentation and format as per review comments
> from Daniel.
>
> Signed-off-by: Niranjana Vishwanathapura
> ---
>
> diff --git a/Documenta
On Tue, 2022-05-17 at 11:32 -0700, Niranjana Vishwanathapura wrote:
> VM_BIND and related uapi definitions
>
> v2: Ensure proper kernel-doc formatting with cross references.
> Also add new uapi and documentation as per review comments
> from Daniel.
>
> Signed-off-by: Niranjana Vishwanath
Em Qui, 2016-08-04 às 16:51 -0700, Matt Roper escreveu:
> On Thu, Aug 04, 2016 at 07:36:15PM -0400, Lyude wrote:
> >
> > Reviewed-by: Lyude
>
> Merged to dinq. Thanks for the quick review.
Regression? This patch makes my SKL machine fail any modesets. I now
boot to a blinking screen where X ke
Em Seg, 2016-08-08 às 18:25 +, Zanoni, Paulo R escreveu:
> Em Qui, 2016-08-04 às 16:51 -0700, Matt Roper escreveu:
> >
> > On Thu, Aug 04, 2016 at 07:36:15PM -0400, Lyude wrote:
> > >
> > >
> > > Reviewed-by: Lyude
> >
> > Merged
Em Seg, 2016-08-08 às 19:35 +0100, Chris Wilson escreveu:
> On Mon, Aug 08, 2016 at 06:25:49PM +0000, Zanoni, Paulo R wrote:
> >
> > Em Qui, 2016-08-04 às 16:51 -0700, Matt Roper escreveu:
> > >
> > > On Thu, Aug 04, 2016 at 07:36:15PM -0400, Lyude wrote:
>
Em Ter, 2016-08-09 às 14:44 +0200, Maarten Lankhorst escreveu:
> Hey,
>
> Op 08-08-16 om 23:03 schreef Lyude:
> >
> > Since the watermark calculations for Skylake are still broken,
> > we're apt
> > to hitting underruns very easily under multi-monitor
> > configurations.
> > While it would be lov
Em Sáb, 2016-08-13 às 10:05 +0100, Chris Wilson escreveu:
> On Fri, Aug 12, 2016 at 11:24:59PM +, Pandiyan, Dhinakaran wrote:
> Do we know why we get black screens in this scenario?
I don't know exactly, but I can speculate that it's probably because
the display engine fails to decompress the
Em Seg, 2016-08-15 às 21:55 +0100, Chris Wilson escreveu:
> On Tue, Jan 19, 2016 at 11:35:44AM -0200, Paulo Zanoni wrote:
> >
> > We'll now call intel_fbc_pre_update instead of intel_fbc_deactivate
> > during atomic commits. This will continue to guarantee that we
> > deactivate FBC and it will al
nd
> nonblocking...")
I think it actually fixes e8216e502acaad129210c3c8b30cb4ab41e70239
("drm/i915/fbc: call intel_fbc_pre_update earlier during page flips").
> Signed-off-by: Chris Wilson
> Cc: Daniel Vetter
> Cc: "Zanoni, Paulo R"
>
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 already
> > pinned
> > in place in the Global GTT (primarily for both fencing which
Em Qua, 2016-08-17 às 19:20 +0100, Chris Wilson escreveu:
> Similarly to invalidating beforehand, if the object is mmapped via
> I915_MMAP_WC we cannot track writes through the I915_GEM_DOMAIN_GTT.
> At
> the conclusion of the write, i915_gem_object_flush_gtt_writes() we
> also
> need to treat the
eed to implement some workarounds we skipped.
>
> Signed-off-by: Chris Wilson
> Cc: Daniel Vetter
> Cc: "Zanoni, Paulo R"
> ---
> drivers/gpu/drm/i915/intel_fbc.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu
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.
>
> Signed-off-by: Chris Wilson
> Cc: Daniel Vetter
> Cc: "Zanoni, Paulo R"
more
> > > flexible and allow operation on unfenced frontbuffers.
> > >
> > > Signed-off-by: Chris Wilson
> > > Cc: Daniel Vetter
> > > Cc: "Zanoni, Paulo R"
> >
> > Hi
> >
> > I see this patch was applied. Now,
Em Qua, 2016-08-17 às 12:02 -0700, Dhinakaran Pandiyan escreveu:
> Since a DRM function that reads link DP link status is available,
> let's
> use that instead of the i915 clone.
One could describe the i915 function as a convenient wrapper instead of
a clone, since it allows passing just intel_dp
Em Qua, 2016-08-24 às 19:00 +0100, Chris Wilson escreveu:
> This reverts commit 8678fdaf396c ("drm/i915/fbc: Allow on unfenced
> surfaces,
> for recent gen") as Skylake has issues with unfenced FBC tracking
> (and
> yes Skylake doesn't even enable FBC yet)
But it used to work if you had i915.enabl
Em Seg, 2016-08-29 às 18:05 +0530, Kumar, Mahesh escreveu:
> Set the intel_crtc->active flag after pipe/crtc is actually active in
> haswell_crtc_enable function.
Why?
Can you please elaborate more on why this change is needed, what are
the benefits it brings, what are the problems it solves and
Hi
Em Seg, 2016-08-29 às 18:05 +0530, Kumar, Mahesh escreveu:
> This patch enables Transition WM for SKL+ platforms.
>
> Transition WM are used if IPC is enabled, to decide, number of blocks
> to be fetched before reducing the priority of display to fetch from
> memory.
>
> Signed-off-by: Kumar,
Em Ter, 2016-08-30 às 19:32 +, Zanoni, Paulo R escreveu:
> Hi
>
> Em Seg, 2016-08-29 às 18:05 +0530, Kumar, Mahesh escreveu:
> >
> > This patch enables Transition WM for SKL+ platforms.
> >
> > Transition WM are used if IPC is enabled, to decide, numbe
Hi
Em Qua, 2016-08-31 às 14:43 -0700, James Bottomley escreveu:
> On Wed, 2016-08-31 at 11:23 -0700, James Bottomley wrote:
> >
> > On Fri, 2016-08-26 at 09:10 -0400, James Bottomley wrote:
> > >
> > > We seem to have an xrandr regression with skylake now. What's
> > > happening is that I can g
Em Sex, 2016-09-02 às 17:16 +0530, Mahesh Kumar escreveu:
> Hi,
>
> On Wednesday 31 August 2016 07:17 PM, Zanoni, Paulo R wrote:
> >
> > Em Ter, 2016-08-30 às 19:32 +, Zanoni, Paulo R escreveu:
> > >
> > > Hi
> > >
> > >
Em Sex, 2016-09-02 às 05:58 +, Pandiyan, Dhinakaran escreveu:
> On Mon, 2016-08-15 at 19:36 -0300, Paulo Zanoni wrote:
> >
> > Ever since I started working on FBC I was already aware that FBC
> > can
> > really amplify the FIFO underrun symptoms. On systems where FIFO
> > underruns were harmle
Em Qua, 2017-04-26 às 15:40 -0300, Gabriel Krisman Bertazi escreveu:
> Paulo Zanoni writes:
>
> >
> > Em Qui, 2017-04-20 às 11:11 -0300, Gabriel Krisman Bertazi
> > escreveu:
> > >
> > > After Linux commit f7e9b004b8a3 ("drm/i915/fbc: inline
> > > intel_fbc_can_choose()"), no_fbc_reason will be
Em Qua, 2016-06-08 às 22:35 +0100, Steven Honeyman escreveu:
> Hi,
Hi
CC'ing the mailing list.
>
> With commit a98ee79317b4091cafb502b4ffdbbbe1335e298c to enable FBC by
> default, I get a strange issue with screen update/refresh (sorry if
> my
> terminology is off - I'm not a graphics dev!).
>
Em Qui, 2016-06-09 às 11:58 -0400, Lyude escreveu:
> From https://bugs.freedesktop.org/show_bug.cgi?id=96461 :
>
> This was kind of a difficult bug to track down. If you're using a
> Haswell system running GNOME and you have fbc completely enabled and
> working, playing videos can result in video
Em Seg, 2016-06-13 às 13:47 +0200, Stefan Richter escreveu:
> On Jun 10 Paulo Zanoni wrote:
> >
> > Since my test machines don't produce FIFO underrun errors, I tested
> > this by
> > creating a debugfs file that just calls
> > intel_fbc_handle_fifo_underrun(). I'd
> > appreciate some Tested-by ta
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)
> and VT - d (Intel® Virtualization Technology for Directed I/O) are
> enabled
> a
Em Sex, 2016-06-10 às 08:44 +0200, Stefan Richter escreveu:
> On Jun 09 Zanoni, Paulo R wrote:
> >
> > Em Qui, 2016-06-09 às 11:58 -0400, Lyude escreveu:
> > >
> > > From https://bugs.freedesktop.org/show_bug.cgi?id=96461 :
> > >
> > > This w
Em Ter, 2016-06-21 às 08:25 +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)
> and VT - d (Intel® Virtualization Technology for Directed I/O) are
> enabled
> a
Em Qua, 2016-06-22 às 21:34 +0100, Chris Wilson escreveu:
> On Tue, Jun 21, 2016 at 03:31:25PM +0200, Daniel Vetter wrote:
> >
> > On Tue, Jun 21, 2016 at 08:25:27AM +0100, Chris Wilson wrote:
> > >
> > > Erratum SKL075: Display Flicker May Occur When Both VT-d And FBC
> > > Are Enabled
> > >
>
Em Qui, 2015-11-19 às 13:07 +0200, Ander Conselvan De Oliveira
escreveu:
> (Cc'ing Paulo for the audio power domain question)
>
> On Wed, 2015-11-11 at 13:33 +0800, libin.y...@linux.intel.com wrote:
> > From: Libin Yang
> >
> > This patch adds support for DP MST audio in i915.
> >
> > Enable au
Em Qua, 2015-12-02 às 12:37 +, Chris Wilson escreveu:
> On Wed, Dec 02, 2015 at 10:15:16AM -0200, Paulo Zanoni wrote:
> > Hi
> >
> > This series includes the implementation for the review feedback
> > given by Chris.
> > I also removed the patch that transformed our 50ms timeout into a
> > vbl
Em Sex, 2015-12-04 às 10:40 +0200, Jani Nikula escreveu:
> On Thu, 03 Dec 2015, Paulo Zanoni wrote:
> > Because just running dim help doesn't give you the greater picture
> > of
> > the workflow. All the text here is based on an email written by
> > Daniel
> > Vetter, so the credits go to him. Any
Em Sex, 2015-12-04 às 16:28 +0100, Daniel Vetter escreveu:
> On Wed, Dec 02, 2015 at 10:47:01AM -0200, Paulo Zanoni wrote:
> > We want to make sure that both tiled and untiled buffers have the
> > same
> > size for the same width/height/format. This will allow better
> > control
> > over the failur
Em Ter, 2015-12-08 às 10:50 +0200, David Weinehall escreveu:
> Since the defaults for some external power management related
> settings
> prevents us from testing our power management functionality properly,
> we have to work around it. Currently this is done from the individual
> test cases, but t
Em Qua, 2016-01-20 às 18:26 -0800, tom.orou...@intel.com escreveu:
> From: Tom O'Rourke
>
> SLPC (Single Loop Power Controller) is a replacement for
> some host-based power management features. The SLPC
> implemenation runs in firmware on GuC.
>
> This series is a first request for comments. T
up
> later. Will keep it vrefresh for now.
I was under the impression that the VSyncFTUsec field wanted the more
precise solution. Maybe Tom or someone else could clarify this to us.
>
> Thanks
> Sagar
>
>
> On 2/4/2016 1:55 AM, Zanoni, Paulo R wrote:
> > Em Qua, 2016
Em Qua, 2016-02-10 às 13:49 +0100, Maarten Lankhorst escreveu:
> intel_post_plane_update did an extra vblank wait that's no longer
> needed when enabling ips.
>
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/i915/intel_display.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --g
Em Qua, 2016-02-10 às 13:49 +0100, Maarten Lankhorst escreveu:
> Factor out intel_fbc_supports_rotation
^ not anymore
> and use it in
> pre_plane_update as well. This leaves intel_crtc->atomic
> empty, so remove it too.
>
> Changes since v1:
> - Add a intel_fbc_supports_rotation helper.
Chang
Em Ter, 2016-02-16 às 12:27 +0200, Jani Nikula escreveu:
> On Fri, 12 Feb 2016, Rodrigo Vivi wrote:
> > This will give us flexibility to enable PSR by default
> > independently so
> > issues and corner cases in one platform won't affect others were we
> > have
> > it working properly.
> >
> > Cc:
Em Qua, 2016-02-10 às 13:49 +0100, Maarten Lankhorst escreveu:
> Use our newly created encoder_mask to iterate over the encoders.
As someone who was not paying attention to the discussion of the
previous patches related to this, I think it would be really good if
your commit message could tell me
Em Qua, 2016-02-10 às 13:49 +0100, Maarten Lankhorst escreveu:
> Right now there's separate power domain handling for update_pipe and
> modesets. Unify this and only grab POWER_DOMAIN_MODESET once.
I would have split this in two separate commits: one for
POWER_DOMAIN_MODESET, and the other for kil
Em Qua, 2016-02-10 às 13:49 +0100, Maarten Lankhorst escreveu:
> Currently we perform our own wait in post_plane_update,
> but the atomic core performs another one in wait_for_vblanks.
> This means that 2 vblanks are done when a fb is changed,
> which is a bit overkill.
>
> Merge them by creating
Em Qui, 2016-02-18 às 10:51 +0100, Maarten Lankhorst escreveu:
> Op 17-02-16 om 18:54 schreef Zanoni, Paulo R:
> > Em Qua, 2016-02-10 às 13:49 +0100, Maarten Lankhorst escreveu:
> > > Use our newly created encoder_mask to iterate over the encoders.
> > As someone who was
Em Qui, 2016-02-18 às 14:22 +0100, Maarten Lankhorst escreveu:
> Op 17-02-16 om 22:20 schreef Zanoni, Paulo R:
> > Em Qua, 2016-02-10 às 13:49 +0100, Maarten Lankhorst escreveu:
> > > Currently we perform our own wait in post_plane_update,
> > > but the atomic c
Em Qui, 2016-02-18 às 15:46 +0100, Maarten Lankhorst escreveu:
> Op 18-02-16 om 15:14 schreef Zanoni, Paulo R:
> > Em Qui, 2016-02-18 às 14:22 +0100, Maarten Lankhorst escreveu:
> > > Op 17-02-16 om 22:20 schreef Zanoni, Paulo R:
> > > > Em Qua, 2016-02-10 às
Em Seg, 2016-02-15 às 15:31 +0100, Maarten Lankhorst escreveu:
> Op 12-02-16 om 14:56 schreef Zanoni, Paulo R:
> > Em Qua, 2016-02-10 às 13:49 +0100, Maarten Lankhorst escreveu:
> > > Factor out intel_fbc_supports_rotation
> > ^ not anymore
> >
> >
> >
Em Qua, 2016-02-10 às 13:49 +0100, Maarten Lankhorst escreveu:
> No atomic state should be included after all validation when nothing
> has
> changed. During modeset all active planes will be added to the state,
> while disabled planes won't change their state.
As someone who is also not super fam
Em Qua, 2016-02-17 às 21:41 +0200, ville.syrj...@linux.intel.com
escreveu:
> From: Ville Syrjälä
>
> The reason for spcial casing 20MHz in the iclkip calculations is that
> it would overflow the 7 bit divisor value. Let's rewrite the special
> case to check for just that, and bump up auxdiv when
Em Qua, 2016-02-17 às 08:40 +, Patchwork escreveu:
> == Summary ==
>
> Series 3500v1 drm/i915/fbc: enable FBC by default on HSW and BDW
> http://patchwork.freedesktop.org/api/1.0/series/3500/revisions/1/mbox
> /
>
> Test pm_rpm:
> Subgroup basic-pci-d3-state:
> pass
Em Qua, 2016-02-24 às 11:24 +0100, Maarten Lankhorst escreveu:
> Currently we perform our own wait in post_plane_update,
> but the atomic core performs another one in wait_for_vblanks.
> This means that 2 vblanks are done when a fb is changed,
> which is a bit overkill.
>
> Merge them by creating
Em Seg, 2016-02-29 às 10:58 +0100, Maarten Lankhorst escreveu:
> Whenever there's an update to the primary plane,
> fbc_pre_update and fbc_post_update are called. Kill off
> intel_crtc->atomic.update_fbc and now that intel_crtc->atomic
> is empty, kill it off too.
>
> Changes since v1:
> - Add a i
Em Qua, 2016-03-02 às 12:38 +0100, Maarten Lankhorst escreveu:
> As Paulo has noted we can help bisectability by separating computing
> watermarks on a noop in 2 separate commits.
>
> This patch no longer clears the crtc watermark state, but
> recalculates
> it completely. Regardless whether a lev
Em Ter, 2016-03-01 às 14:28 -0800, Matt Roper escreveu:
> On Tue, Mar 01, 2016 at 11:07:22AM +0100, Maarten Lankhorst wrote:
> > Only planes that are part of the state should be used for
> > recalculating
> > watermarks. For planes not part of the state the previous patch
> > allows
> > us to re-us
Em Sex, 2016-03-04 às 12:02 +0200, Gabriel Feceoru escreveu:
> Use the pipe which is given from the possible_crcs for that connected
> port
> instead.
>
> On BSW there are constrains for the crtc<-->connector, this fix make
> this test
> passing on BSW.
>
> Signed-off-by: Gabriel Feceoru
Patch
Em Qua, 2016-03-09 às 10:35 +0100, Maarten Lankhorst escreveu:
> Whenever there's an update to the primary plane,
> fbc_pre_update and fbc_post_update are called. Kill off
> intel_crtc->atomic.update_fbc and now that intel_crtc->atomic
> is empty, kill it off too.
>
> Changes since v1:
> - Add a i
Em Qui, 2016-12-08 às 17:00 +0100, Daniel Vetter escreveu:
> On Wed, Dec 07, 2016 at 05:35:09PM -0200, Paulo Zanoni wrote:
> >
> > Em Qui, 2016-12-01 às 21:19 +0530, Mahesh Kumar escreveu:
> > >
> > > This series implements following set of functionality
> > > Implement IPC WA's for Broxton/KBL
Em Seg, 2016-04-25 às 10:45 +0100, Tvrtko Ursulin escreveu:
> On 25/04/16 09:51, Daniel Vetter wrote:
> >
> > On Fri, Apr 22, 2016 at 04:11:11PM +0100, Chris Wilson wrote:
> > >
> > > On Fri, Apr 22, 2016 at 03:41:55PM +0100, Tvrtko Ursulin wrote:
> > > >
> > > > From: Tvrtko Ursulin
> > > >
>
Em Seg, 2016-04-04 às 17:31 +0530, Shashank Sharma escreveu:
> lspcon is a device which acts as DP in some cases
> and as HDMI in some. Here is how:
> - lspcon needs DP(aux) for all the i2c_ove_aux read/write
> transitions so it needs to have some DP level initializations
> - lspcon is detected b
Em Ter, 2016-05-03 às 21:44 +0530, Sharma, Shashank escreveu:
>
> On 5/3/2016 9:39 PM, Ville Syrjälä wrote:
> >
> > On Tue, May 03, 2016 at 09:18:49PM +0530, Sharma, Shashank wrote:
> > >
> > > Regards
> > > Shashank
> > >
> > > On 5/2/2016 7:21 PM, Ville Syrjälä wrote:
> > > >
> > > > On Mon,
Em Qui, 2016-05-05 às 19:45 +0200, Stefan Richter escreveu:
> On Apr 30 Stefan Richter wrote:
> >
> > On Apr 29 Stefan Richter wrote:
> > >
> > > On Apr 26 Stefan Richter wrote:
> > > >
> > > > v4.6-rc solidly hangs after a short while after boot, login to
> > > > X11, and
> > > > doing nothin
Em Sex, 2016-05-06 às 00:54 +0200, Stefan Richter escreveu:
> On May 05 Zanoni, Paulo R wrote:
> >
> > Em Qui, 2016-05-05 às 19:45 +0200, Stefan Richter escreveu:
> > >
> > > Oh, and in case you - the person reading this commit message
> > > - foun
Em Ter, 2016-05-03 às 20:56 +0300, ville.syrj...@linux.intel.com
escreveu:
> From: Ville Syrjälä
>
> Add a helper which aids in the identification of DP dual mode
> (aka. DP++) adaptors. There are several types of adaptors
> specified: type 1 DVI, type 1 HDMI, type 2 DVI, type 2 HDMI
>
> Type 1
Em Sex, 2016-09-09 às 11:06 +0300, Jani Nikula escreveu:
> On Thu, 08 Sep 2016, Lyude Paul wrote:
> >
> > On Thu, 2016-09-08 at 11:59 +0300, Jani Nikula wrote:
> > >
> > > On Wed, 07 Sep 2016, Lyude wrote:
> > > >
> > > >
> > > > On Tue, 2016-09-06 at 21:52 -0300, Paulo Zanoni wrote:
> > > >
Em Qua, 2016-09-07 às 12:05 -0400, Lyude escreveu:
> My only thought is that it seems like we prefix functions skl_, kbl_,
> etc. just to indicate which generation introduced the feature. Skl
> uses
> quite a few sandybridge and haswell functions. If this is a little
> closer to what most intel dev
Hi
Em Sex, 2016-09-09 às 14:11 +0100, Chris Wilson escreveu:
> In the next patch we want to handle reset directly by a locked waiter
> in
> order to avoid issues with returning before the reset is handled. To
> handle the reset, we must first know whether we hold the
> struct_mutex.
> If we do not
Em Seg, 2016-09-12 às 21:25 +0100, Chris Wilson escreveu:
> On Mon, Sep 12, 2016 at 05:02:56PM -0300, Paulo Zanoni wrote:
> >
> > Ever since I started working on FBC I was already aware that FBC
> > can
> > really amplify the FIFO underrun symptoms. On systems where FIFO
> > underruns were harmles
Em Qua, 2016-09-07 às 12:17 -0400, Lyude escreveu:
> I'm not sure that kbl has this either. The kbl machine I've been
> working with thus-far has passed a few modesetting stress tests with
> the chameleon, and I don't have anything trying to control sagv stuff
> on it.
>
> This being said though t
Em Qua, 2016-09-07 às 19:03 -0400, Lyude escreveu:
> On Tue, 2016-09-06 at 21:52 -0300, Paulo Zanoni wrote:
> >
> > During watermarks calculations, this value is used in 3 different
> > places. Only one of them was not using a hardcoded 4. Move the code
> > up
> > so everybody can benefit from the
Em Ter, 2016-09-13 às 20:40 +0100, Chris Wilson escreveu:
> I was looking at some wait_for() timeouts on a slow system, with lots
> of
> debug enabled (KASAN, lockdep, mmio_debug). Thinking that we were
> mishandling the timeout, I tried to ensure that we loop at least once
> after first testing CO
Em Qua, 2016-09-14 às 12:34 +0300, Jani Nikula escreveu:
> On Wed, 14 Sep 2016, Paulo Zanoni wrote:
> >
> > Hi
> >
> > Here's the series with the reviews implemented. There's a new
> > patch,
> > based on the additional issue spotted by Lyude.
>
> There's a bunch of cc: stable patches mixed wit
Em Qua, 2016-09-14 às 12:59 +0300, Jani Nikula escreveu:
> On Tue, 13 Sep 2016, "Zanoni, Paulo R"
> wrote:
> >
> > I got confirmation from the Hardware guys that KBL does need to run
> > the
> > SAGV code, and it has the same latency as SKL. Also, all SKL
Em Qua, 2016-09-14 às 10:22 +0100, Chris Wilson escreveu:
> On Tue, Sep 13, 2016 at 08:40:19PM +0100, Chris Wilson wrote:
> >
> > I was looking at some wait_for() timeouts on a slow system, with
> > lots of
> > debug enabled (KASAN, lockdep, mmio_debug). Thinking that we were
> > mishandling the t
Em Seg, 2016-09-19 às 15:19 -0300, Paulo Zanoni escreveu:
> Em Sex, 2016-09-09 às 13:30 +0530, Kumar, Mahesh escreveu:
> >
> > From: Mahesh Kumar
> >
> > This patch make changes to use linetime latency instead of
> > allocated
> > DDB size during plane watermark calculation in switch case, This
Em Sex, 2016-10-07 às 17:13 -0300, Paulo Zanoni escreveu:
> Luckily, the necessary adjustments for when we're using the scaler
> are
> exactly the same as the ones needed on ILK+, so just reuse the
> function we already have.
Now that I sent it, I realized that I should just have inverted the
patc
Em Seg, 2016-10-10 às 16:34 -0400, Lyude Paul escreveu:
> Was there a new workaround added recently? Or was this something I
> just
> missed when writing the original code for this
It's listed on the public spec:
https://01.org/sites/default/files/docum
entation/intel-gfx-prm-osrc-skl-vol12-displa
Em Ter, 2016-03-22 às 12:13 +0100, Daniel Vetter escreveu:
> On Mon, Mar 21, 2016 at 04:26:54PM -0300, Paulo Zanoni wrote:
> >
> > We ignore ORIGIN_GTT because the hardware tracking can recognize
> > GTT
> > writes and take care of them. We also ignore ORIGIN_FLIP because we
> > deal with flips wi
Em Ter, 2016-03-22 às 12:31 +0100, Daniel Vetter escreveu:
> On Mon, Mar 21, 2016 at 04:26:55PM -0300, Paulo Zanoni wrote:
> >
> > The sna_mode_wants_tear_free() function tries to detect FBC and PSR
> > based on Kernel module parameters. Currently it fails to detect FBC
> > due to the default enab
Em Ter, 2016-03-22 às 12:29 +0100, Daniel Vetter escreveu:
> On Mon, Mar 21, 2016 at 04:26:57PM -0300, Paulo Zanoni wrote:
> >
> > FBC and the frontbuffer tracking infrastructure were designed
> > assuming
> > that user space applications would follow a specific set of rules
> > regarding frontbuf
Em Ter, 2016-03-22 às 12:16 +0100, Daniel Vetter escreveu:
> On Mon, Mar 21, 2016 at 04:26:58PM -0300, Paulo Zanoni wrote:
> >
> > Now that we're more protected against user space doing frontbuffer
> > mmap rendering, the last - how many times did I say this before? -
> > SKL problem seems to be s
Em Qua, 2016-03-23 às 09:50 +0100, Daniel Vetter escreveu:
> On Tue, Mar 22, 2016 at 09:35:36PM +0000, Zanoni, Paulo R wrote:
> >
> > Em Ter, 2016-03-22 às 12:31 +0100, Daniel Vetter escreveu:
> > >
> > > On Mon, Mar 21, 2016 at 04:26:55PM -0300, Paulo Zanoni wro
Em Qua, 2016-03-23 às 14:33 +0100, Maarten Lankhorst escreveu:
> intel_post_plane_update did an extra vblank wait that's no longer
> needed when enabling ips.
>
> Changes since v1:
> - Add comment explaining why vblank wait is performed. (Paulo)
>
> Signed-off-by: Maarten Lankhorst
> ---
> Notic
Em Ter, 2016-03-01 às 16:16 +0200, ville.syrj...@linux.intel.com
escreveu:
> From: Ville Syrjälä
>
> Bspec is confused w.r.t. the HSW/BDW FDI disable sequence. It lists
> FDI RX disable both as step 13 and step 18 in the sequence. But I dug
> up an old BUN mail from Art that moved the FDI RX disa
Em Qua, 2016-03-23 às 23:57 +0200, Ville Syrjälä escreveu:
> On Wed, Mar 23, 2016 at 09:14:34PM +0000, Zanoni, Paulo R wrote:
> >
> > Em Ter, 2016-03-01 às 16:16 +0200, ville.syrj...@linux.intel.com
> > escreveu:
> > >
> > > From: Ville Syrjälä
> >
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 space applications would follow a specific set of rules
> > regarding frontbuff
Em Qui, 2016-03-24 às 21:03 +, ch...@chris-wilson.co.uk escreveu:
> On Thu, Mar 24, 2016 at 08:53:21PM +0000, Zanoni, Paulo R wrote:
> >
> > Em Qui, 2016-03-24 às 19:31 +, Chris Wilson escreveu:
> > >
> > > On Thu, Mar 24, 2016 at 04:
Em Qui, 2016-03-24 às 21:20 +, ch...@chris-wilson.co.uk escreveu:
> On Thu, Mar 24, 2016 at 09:03:59PM +, ch...@chris-wilson.co.uk
> wrote:
> >
> > On Thu, Mar 24, 2016 at 08:53:21PM +0000, Zanoni, Paulo R wrote:
> > >
> > > Em Qui, 2016-03-24 à
Em Ter, 2016-02-23 às 18:46 +0200, ville.syrj...@linux.intel.com
escreveu:
> From: Ville Syrjälä
>
> Add a helper which aids in he identification of DP dual mode (aka.
> DP++)
> adaptors. There are several types of adaptors specified:
> type 1 DVI, type 1 HDMI, type 2 DVI, type 2 HDMI
>
> Type 1
Em Qui, 2016-02-25 às 14:51 +0200, ville.syrj...@linux.intel.com
escreveu:
> From: Ville Syrjälä
>
> To save a bit of power, let's try to turn off the TMDS output buffers
> in DP++ adaptors when we're not driving the port.
>
> v2: Let's not forget DDI, toss in a debug message while at it
>
> Si
Em Ter, 2016-02-23 às 18:46 +0200, ville.syrj...@linux.intel.com
escreveu:
> From: Ville Syrjälä
>
> DP dual mode type 1 DVI adaptors aren't required to implement any
> registers, so it's a bit hard to detect them. The best way would
> be to check the state of the CONFIG1 pin, but we have no way
Em Sex, 2016-04-01 às 17:45 +0300, Ville Syrjälä escreveu:
> On Thu, Mar 31, 2016 at 10:06:37PM +0000, Zanoni, Paulo R wrote:
> >
> > Em Ter, 2016-02-23 às 18:46 +0200, ville.syrj...@linux.intel.com
> > escreveu:
> > >
> > > From: Ville Syrjälä
> &
Em Qua, 2016-04-06 às 10:36 +0530, Thulasimani, Sivakumar escreveu:
> dont want to hijack thread but wanted to point out a possible
> regression
> in the
> previous patches of this series.
>
> intel_fbc_can_choose: returns true for gen 4/5/6/7. (possible bug)
How? It will check for i915.enable_f
Em Ter, 2016-04-12 às 12:18 -0700, Alexandra Yates escreveu:
> This interface allows an immediate enabling of FBC feature. What
> allow us
> to see immediately the FBC
There's no way to guarantee the user will immediately see any FBC
savings. FBC depends on a lot of conditions (e.g., X tiling, cor
Em Ter, 2016-04-12 às 12:18 -0700, Alexandra Yates escreveu:
> This project is explained in detail on the HAS
> https://docs.google.com/a/intel.com/document/d/1E-en_xqfHgCnhD1Tes3f0
> 8UYrOc-etv2W-pU0ZErKdE/edit?usp=sharing
>
> Summary:
> Permits the user to identify and toggle values for PSR,
Em Ter, 2016-04-12 às 12:18 -0700, Alexandra Yates escreveu:
> This interface allows an immediate enabling of PSR feature. What
> allow us
> to see immediately the PSR savings and will allow us to expose this
> through sysfs interface for powertop to leverage its functionality.
>
> Signed-off-by:
1 - 100 of 190 matches
Mail list logo
