Dynamic Refresh Rate Switching (DRRS) is a power conservation feature which
enables swtiching between low and high refresh rates based on the usage
scenario. This feature is applciable for internal eDP panel. Indication that
the panel supports DRRS is given by the panel EDID, whic
From: Pradeep Bhat
This patch reads the DRRS support and Mode type from VBT fields.
The read information will be stored in VBT struct during BIOS
parsing. The above functionality is needed for decision making
whether DRRS feature is supported in i915 driver for eDP panels.
This information helps
For Broadwell, there is one instance of Transcoder MN values per transcoder.
For dynamic switching between multiple refreshr rates, M/N values may be
reprogrammed on the fly. Link N programming triggers update of all data and
link M & N registers and the new M/N values will be used in the next fram
From: Pradeep Bhat
This patch and finds out the lowest refresh rate supported for the resolution
same as the fixed_mode.
It also checks the VBT fields to see if panel supports seamless DRRS or not.
Based on above data it marks whether eDP panel supports seamless DRRS or not.
This information is n
Adding support to detect display idleness by tracking page flip from
user space. Switch to low refresh rate is triggered after 2 seconds of
idleness. The delay is configurable. If there is a page flip or call to
update the plane, then high refresh rate is applied.
The feature is not used in dual-di
From: Pradeep Bhat
This patch computes and stored 2nd M/N/TU for switching to different
refresh rate dynamically. PIPECONF_EDP_RR_MODE_SWITCH bit helps toggle
between alternate refresh rates programmed in 2nd M/N/TU registers.
v2: Daniel's review comments
Computing M2/N2 in compute_config and st
Definition of VLV RR switch bit and corresponding toggling in
set_drrs function.
Signed-off-by: Vandana Kannan
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/i915_reg.h |1 +
drivers/gpu/drm/i915/intel_dp.c | 10 --
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git
On Fri, Feb 28, 2014 at 09:42:02AM +, Chris Wilson wrote:
> On Thu, Feb 27, 2014 at 07:26:36PM -0300, Paulo Zanoni wrote:
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index ce582eb..788b165 100644
> > --- a/drivers/gpu/drm/i915/intel_disp
On Thu, Mar 6, 2014 at 11:23 PM, Paulo Zanoni wrote:
> 2014-03-05 14:09 GMT-03:00 Daniel Vetter :
>> On Thu, Feb 27, 2014 at 07:26:27PM -0300, Paulo Zanoni wrote:
>>> From: Paulo Zanoni
>>>
>>> Hi
>>>
>>> This is the second time I send this series to the mailing list. Please read
>>> the
>>> fir
2014-03-05 14:09 GMT-03:00 Daniel Vetter :
> On Thu, Feb 27, 2014 at 07:26:27PM -0300, Paulo Zanoni wrote:
>> From: Paulo Zanoni
>>
>> Hi
>>
>> This is the second time I send this series to the mailing list. Please read
>> the
>> first cover letter:
>>http://lists.freedesktop.org/archives/int
On Thu, Mar 06, 2014 at 01:58:09PM -0800, Daniel Vetter wrote:
> On Thu, Mar 06, 2014 at 01:32:48PM -0800, Volkin, Bradley D wrote:
> > On Thu, Mar 06, 2014 at 05:17:59AM -0800, Jani Nikula wrote:
> > > On Tue, 18 Feb 2014, bradley.d.vol...@intel.com wrote:
> > > > From: Brad Volkin
> > > >
> > >
Originally posted this to the Linux on Thinkpad list. A friend
recommended I try here instead.
I have an X220, I am running Debian Sid, 3.12.9. I've used this machine
to drive 27" and larger Dell displays at full resolution via displayport
to displayport and displayport to dual link DVI without is
On Thu, Mar 06, 2014 at 01:32:48PM -0800, Volkin, Bradley D wrote:
> On Thu, Mar 06, 2014 at 05:17:59AM -0800, Jani Nikula wrote:
> > On Tue, 18 Feb 2014, bradley.d.vol...@intel.com wrote:
> > > From: Brad Volkin
> > >
> > > Various commands that access memory have a bit to determine whether
> > >
On Thu, Mar 06, 2014 at 09:30:01PM +0100, Daniel Vetter wrote:
> On Thu, Mar 06, 2014 at 10:17:12AM -0800, Ben Widawsky wrote:
> > On Thu, Mar 06, 2014 at 12:14:21PM +0100, Daniel Vetter wrote:
> > > There are too many oustanding issues:
> > >
> > > - Fence handling in the current code is broken.
On Thu, Mar 6, 2014 at 9:30 PM, Daniel Vetter wrote:
>> * Aliasing PPGTT real address treatment: What do you want?
>
> i915_gem_context_free in i195_gem_context.c has a comment:
>
> /* We refcount even the aliasing PPGTT to keep the code symmetric */
>
> That comment is a lie and _not_ ref
On Thu, Mar 6, 2014 at 1:25 PM, Paul Bolle wrote:
> Bjorn Helgaas schreef op ma 10-02-2014 om 14:33 [-0700]:
>> Can you open a kernel.org bugzilla report and attach complete dmesg
>> logs of the working and broken kernels to it? There might be more
>> useful resource-related messages from the PCI
On Thu, Mar 06, 2014 at 05:17:59AM -0800, Jani Nikula wrote:
> On Tue, 18 Feb 2014, bradley.d.vol...@intel.com wrote:
> > From: Brad Volkin
> >
> > Various commands that access memory have a bit to determine whether
> > the graphics address specified in the command should use the GGTT or
> > PPGTT
On Thu, Mar 06, 2014 at 01:12:30PM -0800, Kenneth Graunke wrote:
> The first call to BEGIN_BATCH or BEGIN_BATCH_BLT will set current_batch
> to RENDER_BATCH or BLT_BATCH. If it's zero, that means the batch is
> empty, so there's no point in flushing.
>
> Previously, we would just go ahead and do
This supports solid, copy, put_image, and get_image acceleration via the
BLT engine. RENDER acceleration (composite) would be piles of work,
which is not worth doing since SNA exists, and Glamor is coming.
Signed-off-by: Kenneth Graunke
---
src/uxa/intel_batchbuffer.h | 8 +++-
src/uxa/int
These command packets grew on Gen8.
Signed-off-by: Kenneth Graunke
---
src/uxa/i830_reg.h | 12 ++--
src/uxa/intel_uxa.c | 4 ++--
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/src/uxa/i830_reg.h b/src/uxa/i830_reg.h
index 93d03cf..d8306bc 100644
--- a/src/uxa/i830_reg
The first call to BEGIN_BATCH or BEGIN_BATCH_BLT will set current_batch
to RENDER_BATCH or BLT_BATCH. If it's zero, that means the batch is
empty, so there's no point in flushing.
Previously, we would just go ahead and do a RENDER_RING flush, though
more by accident than intentional design.
Sign
On Thu, Mar 06, 2014 at 03:10:50PM +0200, Jani Nikula wrote:
> On Tue, 18 Feb 2014, bradley.d.vol...@intel.com wrote:
> > From: Brad Volkin
> >
> > The command parser scans batch buffers submitted via execbuffer ioctls
> > before
> > the driver submits them to hardware. At a high level, it looks
On Thu, 2014-03-06 at 21:52 +0100, Daniel Vetter wrote:
> On Thu, Mar 06, 2014 at 12:29:24PM -0800, Jesse Barnes wrote:
> > On Tue, 4 Mar 2014 19:23:10 +0200
> > Imre Deak wrote:
> >
> > > Based on an early draft from Jesse.
> > >
> > > Add support for powering on/off the dynamic power wells on
On Wed, Mar 5, 2014 at 4:04 PM, Daniel Vetter wrote:
> On Sat, Mar 01, 2014 at 07:34:12AM +, Chris Wilson wrote:
>> On Fri, Feb 28, 2014 at 07:28:41PM -0300, Paulo Zanoni wrote:
>> > 2014-02-27 9:23 GMT-03:00 :
>> > > From: Ville Syrjälä
>> > >
>> > > We normally use 10Khz units when describ
On Fri, Feb 14, 2014 at 02:40:39PM +0200, Ville Syrjälä wrote:
> On Fri, Feb 14, 2014 at 12:28:29PM +, Chris Wilson wrote:
> > On Fri, Feb 14, 2014 at 02:18:57PM +0200, ville.syrj...@linux.intel.com
> > wrote:
> > > From: Ville Syrjälä
> > >
> > > Make sure the line_time_us isn't zero in the
On Thu, Mar 06, 2014 at 12:29:24PM -0800, Jesse Barnes wrote:
> On Tue, 4 Mar 2014 19:23:10 +0200
> Imre Deak wrote:
>
> > Based on an early draft from Jesse.
> >
> > Add support for powering on/off the dynamic power wells on VLV by
> > registering its display and dpio dynamic power wells with
On Thu, Mar 06, 2014 at 11:18:38AM -0800, Jesse Barnes wrote:
> On Tue, 4 Mar 2014 19:23:09 +0200
> Imre Deak wrote:
>
> > Needed by the next patch, wanting to set the underrun reporting as part
> > of a bigger dev_priv->irq_lock'ed sequence.
> >
> > Signed-off-by: Imre Deak
> > ---
> > drive
On Tue, 4 Mar 2014 19:23:10 +0200
Imre Deak wrote:
> Based on an early draft from Jesse.
>
> Add support for powering on/off the dynamic power wells on VLV by
> registering its display and dpio dynamic power wells with the power
> domain framework.
>
> For now power on all PHY TX lanes regardl
On Thu, Mar 06, 2014 at 10:17:12AM -0800, Ben Widawsky wrote:
> On Thu, Mar 06, 2014 at 12:14:21PM +0100, Daniel Vetter wrote:
> > There are too many oustanding issues:
> >
> > - Fence handling in the current code is broken. There's a patch series
> > from me, but it's blocked on and extended re
If we run out of stolen memory when trying to allocate an object, see if
we can reap enough purgeable objects to free up enough contiguous free
space for the allocation. This is in principle very much like evicting
objects to free up enough contiguous space in the vma when binding
a new object - an
Bjorn Helgaas schreef op ma 10-02-2014 om 14:33 [-0700]:
> Can you open a kernel.org bugzilla report and attach complete dmesg
> logs of the working and broken kernels to it? There might be more
> useful resource-related messages from the PCI core.
That took me quite a bit longer than I hoped, bu
On Thu, Mar 06, 2014 at 08:17:51AM -0800, Jesse Barnes wrote:
> On Thu, 6 Mar 2014 09:12:40 +
> Chris Wilson wrote:
>
> > On Wed, Mar 05, 2014 at 02:48:27PM -0800, Jesse Barnes wrote:
> > > This gets us out of our init code and out to userspace quite a bit
> > > faster, but does open us up to
On Tue, Mar 04, 2014 at 07:22:55PM +0200, Imre Deak wrote:
> Split the 'set' power well handler into an 'enable', 'disable' and
> 'sync_hw' handler. This maps more conveniently to higher level
> operations, for example it allows us to push the hsw package c8 handling
> into the corresponding hsw/bd
From: Ville Syrjälä
On HSW the scanline counter seems to behave differently depending on
the output type. eDP on port A does what you would expect an the normal
+1 fixup is sufficient to cover it. But on HDMI outputs we seem to need
a +2 fixup. Just assume we always need the +2 fixup and accept t
On Tue, 4 Mar 2014 19:23:09 +0200
Imre Deak wrote:
> Needed by the next patch, wanting to set the underrun reporting as part
> of a bigger dev_priv->irq_lock'ed sequence.
>
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/i915_irq.c | 20 +++-
> 1 file changed, 15 inser
On Tue, 4 Mar 2014 19:23:08 +0200
Imre Deak wrote:
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/intel_pm.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index c034842..39acff
On Tue, 4 Mar 2014 19:23:07 +0200
Imre Deak wrote:
> +void valleyview_enable_display_irqs(struct drm_i915_private *dev_priv)
> +{
> + assert_spin_locked(&dev_priv->irq_lock);
> +
> + if (dev_priv->display_irqs_enabled)
> + return;
> +
> + dev_priv->display_irqs_enabled =
On Wed, 5 Mar 2014 16:20:54 +0200
Imre Deak wrote:
> Since the encoder is tied to its port, we need to make sure the power
> domain for that port is on before reading out the encoder HW state.
>
> Note that this also covers also all connector get_hw_state handlers,
> since all those just call t
On Wed, 5 Mar 2014 16:20:53 +0200
Imre Deak wrote:
> The connector detect and get_mode handlers need to access the port
> specific HW blocks to read the EDID etc. Get/put the port power domains
> around these handlers.
>
> v2:
> - get port power domain for HDMI too (Ville)
> - get port power do
On Tue, 4 Mar 2014 19:23:06 +0200
Imre Deak wrote:
> Suggested by Daniel.
>
> v2:
> - sanitize the state checking condition, the original was rather
> confusing (partly due to the unfortunate naming of
> i915.disable_power_well) (Ville)
> - simpler message+backtrace generation by using WARN
On Tue, 4 Mar 2014 19:23:03 +0200
Imre Deak wrote:
> We need to do the same for other platforms in upcoming patches.
>
> v2:
> - s/p/pipe (Ville)
> - Call the new helper with the vbl_lock already held. The part it
> protects is short, so releasing it between pipes only makes proving
> corre
On Tue, 4 Mar 2014 19:23:01 +0200
Imre Deak wrote:
> This is a left-over from
>
> commit b7e634cc8dcd320123199a18bae0937b40dc28b8
> Author: Imre Deak
> Date: Tue Feb 4 21:35:45 2014 +0200
>
> drm/i915: vlv: don't unmask IIR[DISPLAY_PIPE_A/B_VBLANK] interrupt
>
> where we stopped unmasking
On Wed, 5 Mar 2014 16:20:55 +0200
Imre Deak wrote:
> We can read out the pipe HW state only if the required power domain is
> on. If not we consider the pipe to be off.
>
> v2:
> - no change
> v3:
> - push down the power domain checks into the specific crtc
> get_pipe_config handlers (Daniel)
On Tue, 4 Mar 2014 19:22:56 +0200
Imre Deak wrote:
> Reading code free of special cases wins over the small overhead of
> calling a noop handler. Suggested by Jesse.
>
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/intel_pm.c | 29 +
> 1 file changed, 21 i
On Tue, 4 Mar 2014 19:22:54 +0200
Imre Deak wrote:
> Whenever we request a power domain it has to guarantee that all HW
> resources are enabled that are needed to access a HW register associated
> with that power domain. In case a register is on an always-on power well
> this won't result in tur
On Tue, 4 Mar 2014 19:22:53 +0200
Imre Deak wrote:
> These macros are used only locally, so move them to the .c file.
>
> No functional change.
>
> v2:
> - add init power domain to always-on power wells in the following
> - separate - patch (Paulo)
>
> Signed-off-by: Imre Deak
> ---
> dri
On Tue, 4 Mar 2014 19:22:50 +0200
Imre Deak wrote:
> The power domains framework is internal to the i915 driver, so pass
> drm_i915_private instead of drm_device to its functions.
>
> Also remove a dangling intel_set_power_well() declaration.
>
> No functional change.
>
> Signed-off-by: Imre
On Thu, Mar 06, 2014 at 12:14:21PM +0100, Daniel Vetter wrote:
> There are too many oustanding issues:
>
> - Fence handling in the current code is broken. There's a patch series
> from me, but it's blocked on and extended review (which includes
> writing the testcases).
>
> - IOMMU mapping ha
On Thu, 6 Mar 2014 12:14:21 +0100
Daniel Vetter wrote:
> There are too many oustanding issues:
>
> - Fence handling in the current code is broken. There's a patch series
> from me, but it's blocked on and extended review (which includes
> writing the testcases).
>
> - IOMMU mapping handlin
2014-03-05 10:25 GMT-03:00 Daniel Vetter :
> On Fri, Feb 21, 2014 at 01:52:21PM -0300, Paulo Zanoni wrote:
>> From: Paulo Zanoni
>>
>> Otherwise, when we run intel_modeset_check_state we may already be
>> runtime suspended, and our state checking code will read registers
>> while the device is sus
No special reason. It shouldn't matter on BYT either, really, since
pipe A doesn't have special characteristics like it does on HSW.
Jesse
On Thu, 6 Mar 2014 17:19:22 +0800
"Lin, Mengdong" wrote:
> Hi Jesse,
>
>
>
> Could you tell us why Baytrail Gfx driver does not always use pipe A when
On Thu, 6 Mar 2014 11:28:13 +0200
Ville Syrjälä wrote:
> On Wed, Mar 05, 2014 at 02:48:30PM -0800, Jesse Barnes wrote:
> > It takes awhile to fetch the DPCD and EDID for caching, so take it out
> > of the critical path to improve init time.
> >
> > Signed-off-by: Jesse Barnes
> > ---
> > drive
On Thu, 6 Mar 2014 09:12:40 +
Chris Wilson wrote:
> On Wed, Mar 05, 2014 at 02:48:27PM -0800, Jesse Barnes wrote:
> > This gets us out of our init code and out to userspace quite a bit
> > faster, but does open us up to some bugs given the state of our init
> > time locking.
>
> Why are we h
From: Ville Syrjälä
Sprinkle drm_vblank_on() calls to the .crtc_enable() callbacks.
Also drop the drm_vblank_{pre,post}_modeset() calls since those
are now useless.
Testcase: igt/kms_flip/{dpms,modeset}-vs-vblank-race
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 13 +
On Thu, 6 Mar 2014 09:35:23 +
Chris Wilson wrote:
> On Wed, Mar 05, 2014 at 02:48:26PM -0800, Jesse Barnes wrote:
> > @@ -7554,6 +7610,8 @@ static int intel_crtc_cursor_set(struct drm_crtc
> > *crtc,
> > goto fail;
> > }
> >
> > + intel_sync_crtc(crtc);
> > +
> > /* w
From: Ville Syrjälä
This series is a continuation of the earlier attempt [1]. The first two
patches from that series are still needed, but since they were unchanged
I didn't include them here. The rest of the original series should be
scrapped.
This time I dropped the 'reject' and 'vblank_always
From: Ville Syrjälä
If there's a blocking vblank wait in progress while the vblank interrupt
gets disabled, the current code will just let the vblank wait time out.
Instead make it return immediately when vblank interrupts get disabled.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_irq.
From: Ville Syrjälä
drm_vblank_off() will turn off vblank interrupts, but as long as the
refcount is elevated drm_vblank_get() will not re-enable them. This
is a problem is someone is holding a vblank reference while a modeset is
happening, and the driver requires vblank interrupt to work during
From: Sagar Kamble
Started documenting drm properties for drm drivers. This patch provides
information about properties in drm, i915, psb and cdv/gma-500. Information
about other properties can be added on top of these.
v2: Added description of drm properties in armada, exynos, i2c/ch7006, novea
From: Sagar Kamble
Started documenting drm properties for drm drivers. This patch provides
information about properties in drm, i915, psb and cdv/gma-500. Information
about other properties can be added on top of these.
v2: Added description of drm properties in armada, exynos, i2c/ch7006, novea
On Thu, 2014-03-06 at 14:09 +0200, Ville Syrjälä wrote:
> On Thu, Mar 06, 2014 at 12:45:25PM +0530, sagar.a.kam...@intel.com wrote:
> > From: Sagar Kamble
> >
> > Started documenting drm properties for drm drivers. This patch provides
> > information about properties in drm, i915, psb and cdv/gma
On Thu, Mar 6, 2014 at 2:35 PM, Daniel Martin wrote:
>
> Is it worth opening bugs for drm-intel-nightly?
It's an old one actually: https://bugs.freedesktop.org/show_bug.cgi?id=54687
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
On Tue, 18 Feb 2014, bradley.d.vol...@intel.com wrote:
> From: Brad Volkin
>
> Various commands that access memory have a bit to determine whether
> the graphics address specified in the command should use the GGTT or
> PPGTT for translation. These checks ensure that the bit indicates
> PPGTT tran
On Tue, 18 Feb 2014, bradley.d.vol...@intel.com wrote:
> From: Brad Volkin
>
> Add command tables defining irregular length commands for each ring.
> This requires a few new command opcode definitions.
>
> v2: Whitespace adjustment in command definitions, sparse fix for !F
Apart from the table co
On Tue, 18 Feb 2014, bradley.d.vol...@intel.com wrote:
> From: Brad Volkin
>
> The command parser scans batch buffers submitted via execbuffer ioctls before
> the driver submits them to hardware. At a high level, it looks for several
> things:
>
> 1) Commands which are explicitly defined as privil
On Tue, 18 Feb 2014, bradley.d.vol...@intel.com wrote:
> From: Brad Volkin
>
> The command parser is going to need the same synchronization and
> setup logic, so factor it out for reuse.
>
> v2: Add a check that the object is backed by shmem
>
Reviewed-by: Jani Nikula
> Signed-off-by: Brad Vol
On Thu, Mar 06, 2014 at 12:45:25PM +0530, sagar.a.kam...@intel.com wrote:
> From: Sagar Kamble
>
> Started documenting drm properties for drm drivers. This patch provides
> information about properties in drm, i915, psb and cdv/gma-500. Information
> about other properties can be added on top of
On Thu, Mar 06, 2014 at 12:03:07PM +, Damien Lespiau wrote:
> On Mon, Feb 24, 2014 at 09:14:41PM +0530, Sagar Arun Kamble wrote:
> > Gentle Reminder !!!
> > Kindly review and provide feedback
>
> This main issue here is that we don't have yet the split between the
> CRTC and the primary plane
On Wed, 05 Mar 2014, Jani Nikula wrote:
> On Wed, 05 Mar 2014, Ben Widawsky wrote:
>> | has a higher precedence than ?. Therefore, the calculation doesn't do
>> at all what you would expect. Thanks to Ken for convincing me that this
>> was indeed the issue. Send me back to C programmer school, pl
On Mon, Feb 24, 2014 at 09:14:41PM +0530, Sagar Arun Kamble wrote:
> Gentle Reminder !!!
> Kindly review and provide feedback
This main issue here is that we don't have yet the split between the
CRTC and the primary plane in the DRM API.
Why is this a problem? because you need to define a 'plane-
On Thu, Mar 6, 2014 at 11:28 AM, Sagar Arun Kamble
wrote:
> We can only model GL_CONSTANT_ALPHA given we have sprite control
> registers for that. How do we model other pixel arithmetic related to
> color blending?
> How do we model source and destination pixel arithmetic? We can only set
> alpha/
On Thu, Mar 6, 2014 at 11:48 AM, Gupta, Sourab wrote:
> Also, do we need to enable cacheing for stolen objects at libdrm ( therefore
> deferring the stolen object truncation to later) ?
That was kinda the entire point of making stolen objects purgeable ...
-Daniel
--
Daniel Vetter
Software Engi
There are too many oustanding issues:
- Fence handling in the current code is broken. There's a patch series
from me, but it's blocked on and extended review (which includes
writing the testcases).
- IOMMU mapping handling is broken, we need to properly refcount it -
currently it gets destr
Hi Daniel,
For stolen objects, we have not enabled the libdrm cacheing, so that when the
user creates bo with this flag, the objects created are not cached.
Then the scenario of breaking the libdrm cacheing will not arise in this case.
This is ensured in the libdrm patches uploaded together with
On Tue, 2014-03-04 at 14:06 +0200, Ville Syrjälä wrote:
> On Tue, Mar 04, 2014 at 10:42:38AM +0100, Daniel Vetter wrote:
> > On Tue, Feb 25, 2014 at 08:18:30PM +0200, Ville Syrjälä wrote:
> > > On Wed, Feb 19, 2014 at 03:38:08PM +0530, sagar.a.kam...@intel.com wrote:
> > > > From: Sagar Kamble
> >
On 06/03/2014 10:39, Gupta, Sourab wrote:
Hi Daniel,
We had also considered the two points where the stolen mem objs can be
truncated -
a) at the point of a new bo allocation, if stolen mem space is
exhausted.
b) at the point when the bo is marked as purgeable (madvise ioctl)
Hi Daniel,
We had also considered the two points where the stolen mem objs can be
truncated -
a) at the point of a new bo allocation, if stolen mem space is
exhausted.
b) at the point when the bo is marked as purgeable (madvise ioctl)
We decided upon the second case because:
1
On Wed, Mar 05, 2014 at 02:48:26PM -0800, Jesse Barnes wrote:
> @@ -7554,6 +7610,8 @@ static int intel_crtc_cursor_set(struct drm_crtc *crtc,
> goto fail;
> }
>
> + intel_sync_crtc(crtc);
> +
> /* we only need to pin inside GTT if cursor is non-phy */
> mutex_l
On Wed, Mar 05, 2014 at 02:48:30PM -0800, Jesse Barnes wrote:
> It takes awhile to fetch the DPCD and EDID for caching, so take it out
> of the critical path to improve init time.
>
> Signed-off-by: Jesse Barnes
> ---
> drivers/gpu/drm/i915/intel_dp.c | 113
> +--
Hi Jesse,
Could you tell us why Baytrail Gfx driver does not always use pipe A when it's
free?
We have a Baytrail-M which only have HDMI (port B) and DisplayPort (port C)
output.
When I connect HDMI or DP only, the Gfx driver always uses pipe B for port B/C,
although pipe A is free. This behav
On Wed, Mar 05, 2014 at 02:48:29PM -0800, Jesse Barnes wrote:
> Drivers ought to complain otherwise.
>
> Signed-off-by: Jesse Barnes
> ---
> drivers/gpu/drm/drm_fb_helper.c | 2 ++
> drivers/gpu/drm/i915/intel_dp.c | 4
> drivers/gpu/drm/i915/intel_drv.h | 3 +++
> 3 files changed, 9 inse
On Wed, Mar 05, 2014 at 02:48:27PM -0800, Jesse Barnes wrote:
> This gets us out of our init code and out to userspace quite a bit
> faster, but does open us up to some bugs given the state of our init
> time locking.
Why are we hand rolling an async task for this? See
http://lists.freedesktop.org
On Wed, Mar 05, 2014 at 07:14:49PM -0800, Hugh Dickins wrote:
> On Wed, 5 Mar 2014, Chris Wilson wrote:
>
> > The intention of returning ENOSPC for a page allocation failure due to
> > memory exhausstion in shmem_getpage_gfp() is purely "so that a failure
> > on a sparse tmpfs mapping will give SI
On Wed, Mar 05, 2014 at 08:06:23PM -0800, Hugh Dickins wrote:
> On Wed, 5 Mar 2014, Chris Wilson wrote:
>
> > "When we cannot write a page we should use redirty_page_for_writepage()
> > instead of plain set_page_dirty(). That tells writeback code we have
> > problems, redirties only the page (redi
From: "Ds, Sreedhara"
new file: scripts/build_igt_cairo_tests.py
---
scripts/build_igt_cairo_tests.py | 362 ++
1 file changed, 362 insertions(+)
create mode 100755 scripts/build_igt_cairo_tests.py
diff --git a/scripts/build_igt_cairo_tests.py b/s
85 matches
Mail list logo
