On Mon, Jun 16, 2014 at 07:51:34PM +0200, Daniel Vetter wrote:
> +/**
> + * intel_fb_flip_prepare - flip frontbuffer
> + * @obj: GEM object to flush
> + *
> + * This function gets called after scheduling a flip on @obj. The actual
> + * frontbuffer flushing will be delayed until completion is signa
On Mon, Jun 16, 2014 at 07:51:34PM +0200, Daniel Vetter wrote:
> +/**
> + * intel_frontbuffer_flush - flush frontbuffer
> + * @dev: DRM device
> + * @frontbuffer_bits: frontbuffer plane tracking bits
> + *
> + * This function gets called every time rendering on the given planes has
> + * completed
On Mon, Jun 16, 2014 at 07:51:34PM +0200, Daniel Vetter wrote:
> +static void intel_mark_fb_busy(struct drm_device *dev,
> +unsigned frontbuffer_bits,
> +struct intel_engine_cs *ring)
> {
> - struct drm_device *dev = obj->base.dev;
>
On Mon, Jun 16, 2014 at 07:51:34PM +0200, Daniel Vetter wrote:
> @@ -2227,6 +2223,9 @@ i915_gem_object_move_to_inactive(struct
> drm_i915_gem_object *obj)
> list_move_tail(&vma->mm_list, &vm->inactive_list);
> }
>
> + if (obj->frontbuffer_bits)
> + int
On Mon, Jun 16, 2014 at 07:51:34PM +0200, Daniel Vetter wrote:
> @@ -3966,6 +3971,8 @@ i915_gem_object_set_to_cpu_domain(struct
> drm_i915_gem_object *obj, bool write)
> obj->base.write_domain = I915_GEM_DOMAIN_CPU;
> }
>
/* We do not need to explicitly invalidate the fb when
On Mon, Jun 16, 2014 at 07:51:34PM +0200, Daniel Vetter wrote:
> void i915_gem_release(struct drm_device *dev, struct drm_file *file)
> diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> index 93d7f7246588..2d06aad4a954 100644
> --- a/drivers/
On Mon, Jun 16, 2014 at 05:03:02PM -0700, Rodrigo Vivi wrote:
>On Mon, Jun 16, 2014 at 10:51 AM, Daniel Vetter
><[1]daniel.vet...@ffwll.ch> wrote:
>
> static void intel_edp_psr_enable_sink(struct intel_dp *intel_dp)
> @@ -1911,9 +1906,6 @@ void intel_edp_psr_exit(struct drm_devi
On Mon, Jun 16, 2014 at 07:51:34PM +0200, Daniel Vetter wrote:
> diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
> b/drivers/gpu/drm/i915/intel_fbdev.c
> index 27975c3e21c5..12276c39d14d 100644
> --- a/drivers/gpu/drm/i915/intel_fbdev.c
> +++ b/drivers/gpu/drm/i915/intel_fbdev.c
> @@ -43,10 +43,26
From: Akash Goel
This adds support for a write-enable bit in the entry of GTT.
This is handled via a read-only flag in the GEM buffer object which
is then used to see how to set the bit when writing the GTT entries.
Currently by default the Batch buffer & Ring buffers are marked as read only.
v2
> -Original Message-
> From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
> Sent: Monday, June 16, 2014 4:18 PM
> To: Wang, Quanxian; Daniel Vetter
> Cc: intel-gfx@lists.freedesktop.org
> Subject: RE: [Intel-gfx] [PATCH] drm/i915/vlv: DP_SINK_COUNT is not reliable
> for valleyview pla
Now I'm wondering about the psr_updated you removed and without this
disabling at this point if you alternate to fbcon you might miss most of
screen updates if not all...
On Mon, Jun 16, 2014 at 10:51 AM, Daniel Vetter
wrote:
> It's disabled already except when we've raced.
>
> Cc: Rodrigo Vivi
On Mon, Jun 16, 2014 at 10:51 AM, Daniel Vetter
wrote:
> Trying to fish that one out through looping is a bit a locking
> nightmare. So just set it and use it in the work struct.
>
> Cc: Rodrigo Vivi
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/i915_drv.h | 3 ++-
> drivers/gpu
There were more reasons for disabling it on Baytrail... but you are right..
disable sequence should be better for those cases.
Reviewed-by: Rodrigo Vivi
On Mon, Jun 16, 2014 at 10:51 AM, Daniel Vetter
wrote:
> It doesn't make sense to never again schedule the work, since by the
> time we migh
On Mon, Jun 16, 2014 at 10:51 AM, Daniel Vetter
wrote:
> Due to runtime pm and system s/r we need to restore hw state every
> time we enable a pipe again. Hence trying to avoid that is just
> pointless book-keeping which Rodrigo then tried to work around by
> manually adding psr_setup calls to ou
Reviewed-by: Rodrigo Vivi
On Mon, Jun 16, 2014 at 10:51 AM, Daniel Vetter
wrote:
> We have _enable/_disable interfaces now for the modeset sequence and
> intel_edp_psr_exit for workarounds.
>
> The callsites in intel_display.c are all redundant with the modeset
> sequence enable/disable calls
Reviewed-by: Rodrigo Vivi
On Mon, Jun 16, 2014 at 10:51 AM, Daniel Vetter
wrote:
> It's not needed and further more will get in the way of a sane
> locking scheme - psr_exit _can't_ take modeset locks due to lock
> inversion, and at least once dp mst hits the connector list
> is no longer stat
Reviewed-by: Rodrigo Vivi
On Mon, Jun 16, 2014 at 10:51 AM, Daniel Vetter
wrote:
> Cc: Rodrigo Vivi
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/intel_dp.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c
> b/drivers
The "usage" text should explain it all. I found, in my quilt series
handling endeavours, that I wanted to be able to shift the prefix
numbers of a patch series.
v2: Use heredoc for usage string, fix second example, use mv -i (Jani)
v3: Don't use a fancy read for usage() (Jani)
Collect the file
On Mon, Jun 16, 2014 at 03:48:18PM -0700, Daisy Sun wrote:
> Staring from HSW, the resolution limit of FBC has increased to
> 4096*4096
>
> Issue: VIZ-2813
> Change-Id: I842f64e3cf2c0d18d29ef1bcfef3b9bb1f1764ac
> Signed-off-by: Daisy Sun
Reviewed-by: Damien Lespiau
--
Damien
_
IC. I started working from BDW FBC, did not check all the gens
thoroughly:-)
Sent out a version 2 just now.
- Daisy
On 6/16/2014 2:49 PM, Daniel Vetter wrote:
On Mon, Jun 16, 2014 at 10:41 PM, Sun, Daisy wrote:
Yes, the change starts from HSW. I'll update the patch.
what's the "rant" I need t
Staring from HSW, the resolution limit of FBC has increased to
4096*4096
Issue: VIZ-2813
Change-Id: I842f64e3cf2c0d18d29ef1bcfef3b9bb1f1764ac
Signed-off-by: Daisy Sun
---
drivers/gpu/drm/i915/intel_pm.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/
On Mon, 16 Jun 2014 23:55:24 +0200
Daniel Vetter wrote:
> On Mon, Jun 16, 2014 at 10:38 PM, Jesse Barnes
> wrote:
> > On Mon, 16 Jun 2014 11:43:30 -0700
> > Ben Widawsky wrote:
> >
> >> Hi Wendy. Daniel has reverted your original commit here:
> >> commit 35554a1bcaaea55c1cfa88c0176c58d2fb3b801
On Mon, Jun 09, 2014 at 04:36:47PM +0800, Wendy Wang wrote:
> Why need add rc6_residency_counter subtest case:
> RC6 feature support residency counter,from power consumption aspect,
> the counter closer to 1,the better.If the counter is < 0.9, the residency
> is not good and will impact power consu
On Mon, Jun 16, 2014 at 10:38 PM, Jesse Barnes wrote:
> On Mon, 16 Jun 2014 11:43:30 -0700
> Ben Widawsky wrote:
>
>> Hi Wendy. Daniel has reverted your original commit here:
>> commit 35554a1bcaaea55c1cfa88c0176c58d2fb3b8013
>> Author: Daniel Vetter
>> Date: Tue Jun 10 11:05:16 2014 +0200
>>
On Mon, Jun 16, 2014 at 10:41 PM, Sun, Daisy wrote:
> Yes, the change starts from HSW. I'll update the patch.
> what's the "rant" I need to insert? I was not in the list a year ago:),
> having some trouble find the email as reference.
> Any archives I can look into?
No rant to insert for you ;-)
On Mon, Jun 16, 2014 at 10:08 PM, Oliver Hartkopp
wrote:
> Hey all,
>
> with my Debian unstable the upgrade from 3.15 to 3.16-rc1 failed with this
> fancy
> [drm:intel_dp_start_link_train *ERROR* too many full retries, give up]
> message loop.
This message in dmesg and
> lightdm/XFCE4 doesn't
Yes, the change starts from HSW. I'll update the patch.
what's the "rant" I need to insert? I was not in the list a year ago:),
having some trouble find the email as reference.
Any archives I can look into?
On 6/16/2014 11:15 AM, Daniel Vetter wrote:
On Mon, Jun 16, 2014 at 06:11:45PM +0100,
On Mon, Jun 16, 2014 at 9:37 PM, Chris Wilson wrote:
>> - Try to integrate hw gtt write tracking logic. Note that current psr code
>> doesn't rely on this - I've killed the X-tiled checks completely.
>
> Also probably not worth it. In the normal sporadic use, we can rely on
> the GTT being flush
On Mon, 16 Jun 2014 11:43:30 -0700
Ben Widawsky wrote:
> Hi Wendy. Daniel has reverted your original commit here:
> commit 35554a1bcaaea55c1cfa88c0176c58d2fb3b8013
> Author: Daniel Vetter
> Date: Tue Jun 10 11:05:16 2014 +0200
>
> Revert "Add rc6_residency_counter subtest"
>
> Note that
BDW supports GT C0 residency reporting in constant time unit. Driver calculates
GT utilization based on C0 residency and adjusts RP frequency up/down
accordingly.
Signed-off-by: Daisy Sun
---
drivers/gpu/drm/i915/i915_drv.h | 17
drivers/gpu/drm/i915/i915_irq.c | 10 +++
driv
Hi Akash,
On Mon, 2014-06-09 at 08:36 +0530, akash.g...@intel.com wrote:
> From: Akash Goel
>
> This adds support for a write-enable bit in the entry of GTT.
> This is handled via a read-only flag in the GEM buffer object which
> is then used to see how to set the bit when writing the GTT entrie
On Mon, Jun 16, 2014 at 07:51:20PM +0200, Daniel Vetter wrote:
> Note that currently the gtt tracking has a bit a gap: We never exit it. Bunch
> of
> fixes are possible:
>
> - Wire up the core dirty_fb ioctl to flush framebuffers. This is used by
> generic
> userspace to flush dummy buffers, wh
Am 16.06.2014 19:59, schrieb Daniel Vetter:
On Sun, Jun 15, 2014 at 09:38:49PM +0200, Thomas Richter wrote:
Thanks for keeping the repository, but that's not a solution, at least not
for most of the remaining users of old hardware.
Repositories with patches are normal procedures until those
On Mon, Jun 16, 2014 at 09:20:35PM +0300, Ville Syrjälä wrote:
> On Mon, Jun 16, 2014 at 08:01:26PM +0200, Daniel Vetter wrote:
> > On Mon, Jun 16, 2014 at 11:32:39AM +0300, Ville Syrjälä wrote:
> > > On Sun, Jun 15, 2014 at 02:55:42PM +0200, Daniel Vetter wrote:
> > > > It changes at runtime and s
Hi Wendy. Daniel has reverted your original commit here:
commit 35554a1bcaaea55c1cfa88c0176c58d2fb3b8013
Author: Daniel Vetter
Date: Tue Jun 10 11:05:16 2014 +0200
Revert "Add rc6_residency_counter subtest"
Note that I absolutely do not agree with the decision to revert your
patch as was s
On Mon, Jun 16, 2014 at 08:01:26PM +0200, Daniel Vetter wrote:
> On Mon, Jun 16, 2014 at 11:32:39AM +0300, Ville Syrjälä wrote:
> > On Sun, Jun 15, 2014 at 02:55:42PM +0200, Daniel Vetter wrote:
> > > It changes at runtime and so should be ignored for pipe state checks.
> > > Note that we don't yet
On Mon, Jun 16, 2014 at 10:12:55AM -0700, Matt Roper wrote:
> Now that the primary plane can be disabled independently of the CRTC,
> the debugfs code needs to be updated to recognize when the primary plane
> is disabled and not try to return information about the primary plane's
> framebuffer.
>
On Mon, Jun 16, 2014 at 06:11:45PM +0100, Damien Lespiau wrote:
> On Mon, Jun 16, 2014 at 05:52:12PM +0100, Damien Lespiau wrote:
> > From: Daisy Sun
> >
> > Staring from BDW, the resolution limit of FBC has increased to
> > 4096x4096>
> >
> > Issue: APDEV-2935
> > Otc-Tracker: VIZ-3826
> > Chan
On Mon, Jun 16, 2014 at 04:21:35PM +0100, Thomas Wood wrote:
> Signed-off-by: Thomas Wood
Both igt patches merged, thanks.
-Daniel
> ---
> lib/debug.h | 3 +++
> lib/gen7_render.h | 2 ++
> lib/igt_aux.h | 1 +
> lib/igt_fb.h | 2 ++
> lib/igt_kms.h | 1 +
> lib/rendercopy.h
On Mon, Jun 16, 2014 at 01:07:37PM +0100, Chris Wilson wrote:
> On Mon, Jun 16, 2014 at 12:30:26PM +0100, oscar.ma...@intel.com wrote:
> > From: Oscar Mateo
> >
> > Otherwise, we might receive a new interrupt before we have time to ack the
> > first
> > one, eventually missing it.
>
> Without a
On Mon, Jun 16, 2014 at 04:19:30PM +0300, Imre Deak wrote:
> On Mon, 2014-06-16 at 12:30 +0100, oscar.ma...@intel.com wrote:
> > From: Oscar Mateo
> >
> > Otherwise, we might receive a new interrupt before we have time to
> > ack the first one, eventually missing it.
> >
> > Notice that, before
On Mon, Jun 16, 2014 at 03:32:35PM +0300, Mika Kuoppala wrote:
> tim.g...@intel.com writes:
>
> > From: Tim Gore
> >
> > gem_seqno_wrap was not being built on Android because it uses
> > wordexp which is not in Bionic.
> > After discussion with Mika Kuoppala (the test author) it seems
> > that wo
On Mon, Jun 16, 2014 at 10:55:00AM +0300, Ville Syrjälä wrote:
> On Mon, Jun 16, 2014 at 02:08:26AM +0200, Daniel Vetter wrote:
> > Spotted while crawling around in the area.
> >
> > Signed-off-by: Daniel Vetter
>
> Reviewed-by: Ville Syrjälä
Queued for -next, thanks for the review.
-Daniel
--
On Mon, Jun 16, 2014 at 11:32:39AM +0300, Ville Syrjälä wrote:
> On Sun, Jun 15, 2014 at 02:55:42PM +0200, Daniel Vetter wrote:
> > It changes at runtime and so should be ignored for pipe state checks.
> > Note that we don't yet read out the full DRRS state, so there's some
> > gaps. Bu DRRS is als
On Sun, Jun 15, 2014 at 09:38:49PM +0200, Thomas Richter wrote:
> Am 15.06.2014 14:26, schrieb Ville Syrjälä:
>
> >We all know nightly is rather broken with 830. Nothing new here. I
> >suggest just trying my alm_fixes5 branch.
>
> Excuse my ignorance, but there is something I do not get. There ar
On Sat, Jun 14, 2014 at 10:11:51AM +0100, Damien Lespiau wrote:
> On Fri, Jun 13, 2014 at 06:45:40PM -0300, Paulo Zanoni wrote:
> > From: Paulo Zanoni
> >
> > Two BSpec updates changed the recommended values for BDW eDP and DP
> > DDI buffer translations. Now the signal levels also match the HSW
On Mon, Jun 16, 2014 at 03:24:26PM +, Mateo Lozano, Oscar wrote:
> > -Original Message-
> > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> > Sent: Friday, June 13, 2014 5:51 PM
> > To: Mateo Lozano, Oscar
> > Cc: intel-gfx@lists.freedesktop.org
> > Subject: Re: [Intel-gfx] [PATC
On Mon, Jun 16, 2014 at 02:40:45PM +0300, Mika Kuoppala wrote:
> Chris Wilson writes:
>
> > Rewrite i915_gem_render_state.c for the purposes of clarity and
> > compactness, in the process we can eliminate some dodgy math that did
> > not handle 64bit addresses correctly.
> >
> > Signed-off-by: Ch
On Mon, Jun 16, 2014 at 08:57:44AM +0100, Chris Wilson wrote:
> An object can only have an active gtt mapping if it is currently bound
> into the global gtt. Therefore we can simply walk the list of all bound
> objects and check the flag upon those for an active gtt mapping.
>
> From commit 48018a
I've tried to split this up, but all the changes are so tightly
related that I didn't find a good way to do this without breaking
bisecting. Essentially this completely changes how psr is glued into
the overall driver, and there's not much you can do to soften such a
paradigm change.
- Use frontbu
It's disabled already except when we've raced.
Cc: Rodrigo Vivi
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_dp.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 10bcc052df4b..3e0861be9
Make sure we track the sw side (psr.active) correctly and WARN
everywhere it might get out of sync with the hw.
Cc: Rodrigo Vivi
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_dp.c | 43 ++---
1 file changed, 23 insertions(+), 20 deletions(-)
di
Can't review this right now due to lack of DRRS code.
Cc: Rodrigo Vivi
Cc: Vandana Kannan
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_dp.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index c7d625040e
It's not really optional to have locking ...
The ugly part is how much locking the psr work needs since it has to
recheck everything. Which is way too much. But we need to ditch the
psr work in it's current form anyway and implement proper frontbuffer
tracking.
The other nasty bit that had to go
Cc: Rodrigo Vivi
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_dp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index b6b26407f11b..190df701edd5 100644
--- a/drivers/gpu/drm/i915/intel_dp.
The downclocking checks a few more things, so not that simple to
convert. Also, this should get unified with the drrs handling and also
use the locking of that. Otoh the drrs locking is about as hapzardous
as no locking, at least on first sight.
For easier conversion ditch the upclocking on unload
So from just a quick look we seem to have enough information to
accurately figure out whether a given gem bo is used as a frontbuffer
and where exactly: We have obj->pin_count as a first check with no
false negatives and only negligible false positives. And then we can
just walk the modeset objects
So these are the guts of the new beast. This tracks when a frontbuffer
gets invalidated (due to frontbuffer rendering) and hence should be
constantly scaned out, and when it's flushed again and can be
compressed/one-shot-upload.
Rules for flushing are simple: The frontbuffer needs one more full
up
Trying to fish that one out through looping is a bit a locking
nightmare. So just set it and use it in the work struct.
Cc: Rodrigo Vivi
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.h | 3 ++-
drivers/gpu/drm/i915/intel_dp.c | 21 +++--
2 files changed, 9 inse
It doesn't make sense to never again schedule the work, since by the
time we might want to re-enable psr the world might have changed and
we can do it again.
The only exception is when we shut down the pipe, but that's an
entirely different thing and needs to be handled in psr_disable.
Cc: Rodrig
We need to make sure that no one else is using this in the
enable function and also that the work item hasn't raced
with the disabled function.
Cc: Rodrigo Vivi
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_dp.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/g
It's not needed and further more will get in the way of a sane
locking scheme - psr_exit _can't_ take modeset locks due to lock
inversion, and at least once dp mst hits the connector list
is no longer static.
But since we track all state in dev_priv->psr there is no need
at all.
Cc: Rodrigo Vivi
We have _enable/_disable interfaces now for the modeset sequence and
intel_edp_psr_exit for workarounds.
The callsites in intel_display.c are all redundant with the modeset
sequence enable/disable calls in intel_ddi.c. The one in
intel_sprite.c is real and needs to be switched to psr_exit.
If thi
Hi all,
This patch series adds accurate frontbuffer tracking to i915 and then converts
psr over to use. Bunch of things still need to be done.
- PSR needs to be re-tested. I lack the hardware for that. The frontbuffer
tracking itself is tested.
- PSR igt testcase needs to be extended so that w
Due to runtime pm and system s/r we need to restore hw state every
time we enable a pipe again. Hence trying to avoid that is just
pointless book-keeping which Rodrigo then tried to work around by
manually adding psr_setup calls to our resume code.
Much simpler to just remove code instead.
Cc: Ro
Now that the primary plane can be disabled independently of the CRTC,
the debugfs code needs to be updated to recognize when the primary plane
is disabled and not try to return information about the primary plane's
framebuffer.
This change prevents a NULL dereference when reading i915_display_info
On Mon, Jun 16, 2014 at 05:52:12PM +0100, Damien Lespiau wrote:
> From: Daisy Sun
>
> Staring from BDW, the resolution limit of FBC has increased to
> 4096x4096>
>
> Issue: APDEV-2935
> Otc-Tracker: VIZ-3826
> Change-Id: I842f64e3cf2c0d18d29ef1bcfef3b9bb1f1764ac
> Signed-off-by: Daisy Sun
Revi
On Mon, Jun 16, 2014 at 10:01:55AM -0700, Matt Roper wrote:
> Now that the primary plane can be disabled independently of the CRTC,
> the debugfs code needs to be updated to recognize when the primary plane
> is disabled and not try to return information about the primary plane's
> framebuffer.
>
Now that the primary plane can be disabled independently of the CRTC,
the debugfs code needs to be updated to recognize when the primary plane
is disabled and not try to return information about the primary plane's
framebuffer.
This change prevents a NULL dereference when reading i915_display_info
From: Daisy Sun
Staring from BDW, the resolution limit of FBC has increased to
4096x4096>
Issue: APDEV-2935
Otc-Tracker: VIZ-3826
Change-Id: I842f64e3cf2c0d18d29ef1bcfef3b9bb1f1764ac
Signed-off-by: Daisy Sun
---
drivers/gpu/drm/i915/intel_pm.c | 5 -
1 file changed, 4 insertions(+), 1 dele
On Mon, Jun 16, 2014 at 08:59:04PM +0530, sourab.gu...@intel.com wrote:
> From: Chris Wilson
>
> This patch adds support for clearing buffer objects via blitter
> engines. This is particularly useful for clearing out the memory
> from stolen region.
>
> testcase: igt/gem_create2
>
> Signed-off-
On Mon, Jun 16, 2014 at 08:59:05PM +0530, sourab.gu...@intel.com wrote:
> From: Chris Wilson
>
> Despite being a unified memory architecture (UMA) some bits of memory
> are more equal than others. In particular we have the thorny issue of
> stolen memory, memory stolen from the system by the BIOS
From: Sourab Gupta
This patch series add the bufmgr interfaces for exposing the
create2 ioctl.
By means of this ioctl, we can specify number of parameters
during object creation time such as placement, cache domains,
caching, madvise, tiling etc.
Signed-off-by: Sourab Gupta
---
include/drm/i91
From: Sourab Gupta
This patch series add the bufmgr interfaces for exposing the
create2 ioctl.
By means of this ioctl, we can specify number of parameters
during object creation time such as placement, cache domains,
caching, madvise, tiling etc.
Sourab Gupta (2):
intel: Adding bufmgr interfa
From: Sourab Gupta
This patch add the cacheing logic for the buffer objects created
using create2 ioctl. This cacheing logic is in principle similar
the cachecing employed in the earlier clear ioctl.
The cacheing is not employed if object is created in stolen region
or if the offset is specified
From: Sourab Gupta
This patch adds the testcases for verifying the new gem_create2
ioctl. By means of this ioctl, we can specify number of parameters
during object creation time such as placement, cache domains,
caching, madvise, tiling etc.
These testcases include functional tests and interface
From: Chris Wilson
Despite being a unified memory architecture (UMA) some bits of memory
are more equal than others. In particular we have the thorny issue of
stolen memory, memory stolen from the system by the BIOS and reserved
for igfx use. Stolen memory is required for some functions of the GP
From: Chris Wilson
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 bind
From: Chris Wilson
This patch adds support for clearing buffer objects via blitter
engines. This is particularly useful for clearing out the memory
from stolen region.
testcase: igt/gem_create2
Signed-off-by: Sourab Gupta
---
drivers/gpu/drm/i915/Makefile| 1 +
drivers/gpu/drm/i915/
From: Sourab Gupta
This patch series introduces a new gem create ioctl for user specified
placement.
Despite being a unified memory architecture (UMA) some bits of memory
are more equal than others. In particular we have the thorny issue of
stolen memory, memory stolen from the system by the BIO
> -Original Message-
> From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> Sent: Friday, June 13, 2014 5:51 PM
> To: Mateo Lozano, Oscar
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 51/53] drm/i915/bdw: Document Logical
> Rings, LR contexts and Execlists
>
> O
Signed-off-by: Thomas Wood
---
lib/debug.h | 3 +++
lib/gen7_render.h | 2 ++
lib/igt_aux.h | 1 +
lib/igt_fb.h | 2 ++
lib/igt_kms.h | 1 +
lib/rendercopy.h | 3 +++
6 files changed, 12 insertions(+)
diff --git a/lib/debug.h b/lib/debug.h
index af9cf39..ca4b31e 100644
--- a/
-
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf O
> -Original Message-
> From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> Sent: Friday, June 13, 2014 6:11 PM
> To: Mateo Lozano, Oscar
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 05/53] drm/i915: Move
> i915_gem_validate_context() to i915_gem_context.c
>
>
From: Oscar Mateo
Otherwise, we might receive a new interrupt before we have time to
ack the first one, eventually missing it.
Without an atomic XCHG operation with mmio space, this patch merely
reduces the window in which we can miss an interrupt (especially when
you consider how heavyweight th
From: Oscar Mateo
Otherwise, we might receive a new interrupt before we have time to
ack the first one, eventually missing it.
The right order should be:
1 - Disable Master Interrupt Control.
2 - Find the category of interrupt that is pending.
3 - Find the source(s) of the interrupt and clear t
From: Oscar Mateo
Otherwise, we might receive a new interrupt before we have time to ack the first
one, eventually missing it.
According to BSPec, the right order should be:
1 - Disable Master Interrupt Control.
2 - Find the source(s) of the interrupt.
3 - Clear the Interrupt Identity bits (IIR
From: Oscar Mateo
Otherwise, we might receive a new interrupt before we have time to
ack the first one, eventually missing it.
Without an atomic XCHG operation with mmio space, this patch merely
reduces the window in which we can miss an interrupt (especially when
you consider how heavyweight th
Add the call to memset that was accidentally removed in:
commit 1e9e1baba389fe498be12390ceeeacb1d141a5cf
Author: Daniel Vetter
Date: Thu Mar 13 17:20:05 2014 +0100
lib/igt_kms: rip out custom verbose loggin support
Instead just piggy-pack on top of igt_log.
Signed-off-by: Daniel
On Mon, Jun 16, 2014 at 03:09:24PM +0100, oscar.ma...@intel.com wrote:
> From: Oscar Mateo
>
> Otherwise, we might receive a new interrupt before we have time to ack the
> first
> one, eventually missing it.
>
> According to BSPec, the right order should be:
>
> 1 - Disable Master Interrupt Co
On Friday 13 June 2014 07:24 PM, Daniel Vetter wrote:
On Fri, Jun 13, 2014 at 05:56:41PM +0530, Deepak S wrote:
On Friday 13 June 2014 05:27 PM, Ville Syrjälä wrote:
On Fri, Jun 13, 2014 at 02:33:44PM +0300, Ville Syrjälä wrote:
On Fri, Jun 13, 2014 at 03:46:14PM +0530, deepa...@linux.intel.c
From: Oscar Mateo
Otherwise, we might receive a new interrupt before we have time to
ack the first one, eventually missing it.
Without an atomic XCHG operation with mmio space, this patch merely
reduces the window in which we can miss an interrupt (especially when
you consider how heavyweight th
From: Oscar Mateo
Otherwise, we might receive a new interrupt before we have time to
ack the first one, eventually missing it.
The right order should be:
1 - Disable Master Interrupt Control.
2 - Find the category of interrupt that is pending.
3 - Find the source(s) of the interrupt and clear t
From: Oscar Mateo
Otherwise, we might receive a new interrupt before we have time to ack the first
one, eventually missing it.
According to BSPec, the right order should be:
1 - Disable Master Interrupt Control.
2 - Find the source(s) of the interrupt.
3 - Clear the Interrupt Identity bits (IIR
From: Oscar Mateo
Otherwise, we might receive a new interrupt before we have time to
ack the first one, eventually missing it.
Without an atomic XCHG operation with mmio space, this patch merely
reduces the window in which we can miss an interrupt (especially when
you consider how heavyweight th
Chris Wilson wrote:
> When using remap_pfn_range() from a fault handler, we are exposed to
> races between concurrent faults. Rather than hitting a BUG, report the
> error back to the caller, like vm_insert_pfn().
>
> Signed-off-by: Chris Wilson
> Cc: Andrew Morton
> Cc: "Kirill A. Shutemov"
>
On Mon, 2014-06-16 at 12:30 +0100, oscar.ma...@intel.com wrote:
> From: Oscar Mateo
>
> Otherwise, we might receive a new interrupt before we have time to
> ack the first one, eventually missing it.
>
> Notice that, before clearing a port-sourced interrupt in the IIR, the
> corresponding interru
On Mon, Jun 16, 2014 at 12:30:27PM +0100, oscar.ma...@intel.com wrote:
> From: Oscar Mateo
>
> Otherwise, we might receive a new interrupt before we have time to
> ack the first one, eventually missing it.
>
> Notice that, before clearing a port-sourced interrupt in the IIR, the
> corresponding
tim.g...@intel.com writes:
> From: Tim Gore
>
> gem_seqno_wrap was not being built on Android because it uses
> wordexp which is not in Bionic.
> After discussion with Mika Kuoppala (the test author) it seems
> that wordexp was used to implement the --cmd option that was
> really only intended fo
On Mon, Jun 16, 2014 at 12:30:26PM +0100, oscar.ma...@intel.com wrote:
> From: Oscar Mateo
>
> Otherwise, we might receive a new interrupt before we have time to ack the
> first
> one, eventually missing it.
Without a atomic xchg operation with mmio space, we merely reduce the
window. This is e
1 - 100 of 113 matches
Mail list logo
