Signed-off-by: Lyude
Cc: Maarten Lankhorst
Cc: Ville Syrjälä
Cc: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_display.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 2c682bc..6191baf 1
Finally, add some debugging output for ddb changes in the atomic debug
output. This makes it a lot easier to spot bugs from incorrect ddb
allocations.
Signed-off-by: Lyude
Reviewed-by: Maarten Lankhorst
Cc: Ville Syrjälä
Cc: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_pm.c | 57 ++
There's not much of a reason this should have the locations to read out
the hardware state hardcoded, so allow the caller to specify the
location and add this function to intel_drv.h. As well, we're going to
need this function to be reusable for the next patch.
Signed-off-by: Lyude
Cc: Maarten La
This function is a wreck, let's help it get it's life back together and
cleanup all of the copy pasta here.
(adding Maarten's reviewed-by since this is just a split-up version of one
of the previous patches)
Signed-off-by: Lyude
Reviewed-by: Maarten Lankhorst
Cc: Ville Syrjälä
Cc: Paulo Zanoni
Thanks to Paulo Zanoni for indirectly pointing this out.
Looks like we never actually added any code for checking whether or not
we actually wrote watermark levels properly. Let's fix that.
Signed-off-by: Lyude
Cc: Maarten Lankhorst
Cc: Ville Syrjälä
Cc: Paulo Zanoni
---
drivers/gpu/drm/i915
Next part of cleaning up the watermark code for skl. This is easy, since
it seems that we never actually needed to keep track of the linetime in
the skl_wm_values struct anyway.
Signed-off-by: Lyude
Reviewed-by: Paulo Zanoni
Reviewed-by: Maarten Lankhorst
Cc: Ville Syrjälä
Cc: Paulo Zanoni
--
While it (mostly) works, the code for handling watermarks on Skylake has been
kind of ugly for a while. As well a lot of it isn't that friendly to atomic
transactions, Lots of copy paste, redundant wm values, etc. While this isn't a
full cleanup, it's a good start. As well, we add a couple of featu
Now that we've make skl_wm_levels make a little more sense, we can
remove all of the redundant wm information. Up until now we'd been
storing two copies of all of the skl watermarks: one being the
skl_pipe_wm structs, the other being the global wm struct in
drm_i915_private containing the raw regis
First part of cleaning up all of the skl watermark code. This moves the
structures for storing the ddb allocations of each pipe into
intel_crtc_state, along with moving the structures for storing the
current ddb allocations active on hardware into intel_crtc.
Changes since v1:
- Don't replace allo
Having skl_wm_level contain all of the watermarks for each plane is
annoying since it prevents us from having any sort of object to
represent a single watermark level, something we take advantage of in
the next commit to cut down on all of the copy paste code in here.
Changes since v1:
- Style nit
Helper we're going to be using for implementing verification of the wm
levels in skl_verify_wm_level().
Signed-off-by: Lyude
Cc: Maarten Lankhorst
Cc: Ville Syrjälä
Cc: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_drv.h | 2 ++
drivers/gpu/drm/i915/intel_pm.c | 14 ++
2 files cha
From: "Navare, Manasi D"
These static helper functions are required to be used during
fallback link rate implemnetation so they need to be placed at the top
of the file.
v3:
* Add cleanup to other patch (Mika Kahola)
v2:
* Dont move around functions declared in intel_drv.h (Rodrigo Vivi)
Cc: Ja
This is required to return the index of link rate into
common_rates array. This gets used to retry the link
training at lower link rate.
Cc: Jani Nikula
Cc: Daniel Vetter
Cc: Ville Syrjala
Signed-off-by: Manasi Navare
---
drivers/gpu/drm/i915/intel_dp.c | 15 +++
1 file changed, 1
We create a work queue for sending a hotplug uevent. This
gets scheduled on link training failure and gets executed after
modeset is finished and all locks are released.
This was required to avoid deadlock.
Cc: Jani Nikula
Cc: Daniel Vetter
Cc: Ville Syrjala
Signed-off-by: Manasi Navare
---
d
This adds support in the kernel to handle link training compliance
requests and send a uevent to train at requested parameters.
In this patch series, if the link training fails in modeset, then a
hotplug uevent is added to a work queue and scheduled and failed link
parameters are stored in intel_dp
This patch adds support to handle automated DP compliance
link training test requests. This patch has been tested with
Unigraf DPR-120 DP Compliance device for testing Link
Training Compliance.
After we get a short pulse Compliance test request, test
request values are read and hotplug uevent is se
If link training at a link rate optimal for a particular
mode fails during modeset's atomic commit phase, then we
let the modeset complete and then retry. We save the link rate
value at which link training failed and use a lower link rate
to prune the modes during the next modeset, configure the pi
We create a work queue for sending a hotplug uevent. This
gets scheduled on link training failure and gets executed after
modeset is finished and all locks are released.
This was required to avoid deadlock.
Cc: Jani Nikula
Cc: Daniel Vetter
Cc: Ville Syrjala
Signed-off-by: Manasi Navare
---
d
This adds support in the kernel to handle link training compliance
requests and send a uevent to train at requested parameters.
In this patch series, if the link training fails in modeset, then a
hotplug uevent is added to a work queue and scheduled and failed link
parameters are stored in intel_dp
This is required to return the index of link rate into
common_rates array. This gets used to retry the link
training at lower link rate.
Cc: Jani Nikula
Cc: Daniel Vetter
Cc: Ville Syrjala
Signed-off-by: Manasi Navare
---
drivers/gpu/drm/i915/intel_dp.c | 15 +++
1 file changed, 1
If link training at a link rate optimal for a particular
mode fails during modeset's atomic commit phase, then we
let the modeset complete and then retry. We save the link rate
value at which link training failed and use a lower link rate
to prune the modes during the next modeset, configure the pi
This patch adds support to handle automated DP compliance
link training test requests. This patch has been tested with
Unigraf DPR-120 DP Compliance device for testing Link
Training Compliance.
After we get a short pulse Compliance test request, test
request values are read and hotplug uevent is se
From: "Navare, Manasi D"
These static helper functions are required to be used during
fallback link rate implemnetation so they need to be placed at the top
of the file.
v3:
* Add cleanup to other patch (Mika Kahola)
v2:
* Dont move around functions declared in intel_drv.h (Rodrigo Vivi)
Cc: Ja
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.
v2: Invert the patch order so stable backports get easier.
Cc: sta...@vger.kernel.org
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i
We used to call skl_pipe_pixel_rate(), which used to be a single
one-line return, but now we're calling ilk_pipe_pixel_rate() which is
not as simple, so it's better to just call it once and store the
computed value for reuse.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_pm.c | 8 +
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
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.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_pm.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff -
One day this function will have a complete implementation which won't
be a simple one-line return, so avoid unnecessarily calling it when we
can just store the value in a variable.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_pm.c | 8 ++--
1 file changed, 6 insertions(+), 2 de
gen4/vlv/chv all use the same bits in pipestat to enable the vblank
interrupt, so they can share the same callbacks to enable/disable.
Signed-off-by: Chris Wilson
Cc: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_irq.c | 59 +++--
1 file changed, 28 insertions(
To enable the vblank itself, we need to have an RPM wakeref for the mmio
access, and whilst generating the vblank interrupts we continue to
require the rpm wakeref. The assumption is that the RPM wakeref is held
by the display powerwell held by the active pipe. As this chain was not
obvious to me c
During rpm resume we restore the fences, but we do not have the
protection of struct_mutex. This rules out updating the activity
tracking on the fences, and requires us to rely on the rpm as the
serialisation barrier instead.
[ 350.298052] [drm:intel_runtime_resume [i915]] Resuming device
[ 350.
On Fri, Oct 07, 2016 at 08:00:35PM +0100, Chris Wilson wrote:
> On Fri, Oct 07, 2016 at 07:57:21PM +0100, Chris Wilson wrote:
> > On Fri, Oct 07, 2016 at 09:44:53PM +0300, Ville Syrjälä wrote:
> > > On Fri, Oct 07, 2016 at 07:33:00PM +0100, Chris Wilson wrote:
> > > > On Fri, Oct 07, 2016 at 09:06:
On Fri, Oct 07, 2016 at 07:57:21PM +0100, Chris Wilson wrote:
> On Fri, Oct 07, 2016 at 09:44:53PM +0300, Ville Syrjälä wrote:
> > On Fri, Oct 07, 2016 at 07:33:00PM +0100, Chris Wilson wrote:
> > > On Fri, Oct 07, 2016 at 09:06:07PM +0300, Ville Syrjälä wrote:
> > > > On Fri, Oct 07, 2016 at 02:50
On Fri, Oct 07, 2016 at 09:44:53PM +0300, Ville Syrjälä wrote:
> On Fri, Oct 07, 2016 at 07:33:00PM +0100, Chris Wilson wrote:
> > On Fri, Oct 07, 2016 at 09:06:07PM +0300, Ville Syrjälä wrote:
> > > On Fri, Oct 07, 2016 at 02:50:32PM +0100, Chris Wilson wrote:
> > > > Whilst the vblank is configur
From: Akash Goel
With the possibility of addition of many more number of rings in future,
the drm_i915_private structure could bloat as an array, of type
intel_engine_cs, is embedded inside it.
struct intel_engine_cs engine[I915_NUM_ENGINES];
Though this is still fine as generally there i
On Fri, Oct 07, 2016 at 07:33:00PM +0100, Chris Wilson wrote:
> On Fri, Oct 07, 2016 at 09:06:07PM +0300, Ville Syrjälä wrote:
> > On Fri, Oct 07, 2016 at 02:50:32PM +0100, Chris Wilson wrote:
> > > Whilst the vblank is configured to send an interrupt everytime, we need
> > > to keep the device awa
Since "Dynamic page table allocations" were introduced, our page tables
can grow (being dynamically allocated) with address space range usage.
Unfortunately, their lifetime is bound to vm. This is not a huge problem
when we're not using softpin - drm_mm is creating an upper bound on used
range by c
On Fri, Oct 07, 2016 at 09:06:07PM +0300, Ville Syrjälä wrote:
> On Fri, Oct 07, 2016 at 02:50:32PM +0100, Chris Wilson wrote:
> > Whilst the vblank is configured to send an interrupt everytime, we need
> > to keep the device awake to process those interrupts.
>
> If we can enable vblanks the pipe
On Fri, Oct 07, 2016 at 02:50:32PM +0100, Chris Wilson wrote:
> Whilst the vblank is configured to send an interrupt everytime, we need
> to keep the device awake to process those interrupts.
If we can enable vblanks the pipe will be active, and thus we can't
runtime suspend anyway. Also might_sle
On 14 September 2016 at 15:19, Robert Bragg wrote:
> In particular this tries to capture for posterity some of the early
> challenges we had with using the core perf infrastructure in case we
> ever want to revisit adapting perf for device metrics.
>
> Cc: Chris Wilson
> Signed-off-by: Robert Bra
On 14 September 2016 at 15:19, Robert Bragg wrote:
> This adds 'compute', 'compute extended', 'memory reads', 'memory writes'
> and 'sampler balance' metric sets for Haswell.
>
> The code is auto generated from an XML description of metric sets,
> currently maintained in gputop, ref:
>
> https://
On 14 September 2016 at 15:19, Robert Bragg wrote:
> Consistent with the kernel.perf_event_paranoid sysctl option that can
> allow non-root users to access system wide cpu metrics, this can
> optionally allow non-root users to access system wide OA counter metrics
> from Gen graphics hardware.
>
>
On 14 September 2016 at 15:19, Robert Bragg wrote:
> The minimal sampling period is now configurable via a
> dev.i915.oa_min_timer_exponent sysctl parameter.
>
> Following the precedent set by perf, the default is the minimum that
> won't (on its own) exceed the default kernel.perf_event_max_sampl
On 14 September 2016 at 15:19, Robert Bragg wrote:
> Each metric set is given a sysfs entry like:
>
> /sys/class/drm/card0/metrics//id
>
> This allows userspace to enumerate the specific sets that are available
> for the current system. The 'id' file contains an unsigned integer that
> can be used
On 14 September 2016 at 15:19, Robert Bragg wrote:
> Gen graphics hardware can be set up to periodically write snapshots of
> performance counters into a circular buffer via its Observation
> Architecture and this patch exposes that capability to userspace via the
> i915 perf interface.
>
> Cc: Ch
On 14 September 2016 at 15:19, Robert Bragg wrote:
> Adds a static OA unit, MUX + B Counter configuration for basic render
> metrics on Haswell. This is auto generated from an XML
> description of metric sets, currently maintained in gputop, ref:
>
> https://github.com/rib/gputop
> > gputop-da
On 14 September 2016 at 15:19, Robert Bragg wrote:
> OACONTROL changes quite a bit for gen8, with some bits split out into a
> per-context OACTXCONTROL register. Rename now before adding more gen7 OA
> registers
>
> Signed-off-by: Robert Bragg
Reviewed-by: Matthew Auld
__
On 14 September 2016 at 16:32, Robert Bragg wrote:
> Adds base i915 perf infrastructure for Gen performance metrics.
>
> This adds a DRM_IOCTL_I915_PERF_OPEN ioctl that takes an array of uint64
> properties to configure a stream of metrics and returns a new fd usable
> with standard VFS system cal
On Fri, Oct 07, 2016 at 05:52:47PM +0100, Tvrtko Ursulin wrote:
>
> On 07/10/2016 10:46, Chris Wilson wrote:
> >Quite a few of our objects used for internal hardware programming do not
> >benefit from being swappable or from being zero initialised. As such
> >they do not benefit from using a shmem
On Fri, Oct 07, 2016 at 05:35:38PM +0100, Tvrtko Ursulin wrote:
>
> On 07/10/2016 10:46, Chris Wilson wrote:
> >We only need the active reference to keep the object alive after the
> >handle has been deleted (so as to prevent a synchronous gem_close). Why
> >then pay the price of a kref on every e
On 07/10/2016 10:46, Chris Wilson wrote:
Quite a few of our objects used for internal hardware programming do not
benefit from being swappable or from being zero initialised. As such
they do not benefit from using a shmemfs backing storage and since they
are internal and never directly exposed t
>-Original Message-
>From: Vivi, Rodrigo
>Sent: Friday, October 7, 2016 7:06 AM
>To: Zanoni, Paulo R
>Cc: intel-gfx@lists.freedesktop.org; Srivatsa, Anusha
>
>Subject: Re: [Intel-gfx] [PATCH] drm/i915/guc: Sanitory checks for platform
>that
>dont have GuC
>
>On Fri, 2016-10-07 at 10:41
On Fri, Oct 07, 2016 at 05:16:17PM +0100, Tvrtko Ursulin wrote:
>
> On 07/10/2016 17:12, Chris Wilson wrote:
> >>2. Can child be another array?
> >Yes, but we don't want to recurse (or at least need to bound the
> >recursion).
>
> In that case could the array have been created in the signal_on_an
On 07/10/2016 10:46, Chris Wilson wrote:
We only need the active reference to keep the object alive after the
handle has been deleted (so as to prevent a synchronous gem_close). Why
then pay the price of a kref on every execbuf when we can insert that
final active ref just in time for the handle
On Fri, Oct 07, 2016 at 05:10:04PM +0100, Tvrtko Ursulin wrote:
>
> On 07/10/2016 10:46, Chris Wilson wrote:
> >In forthcoming patches, we want to be able to dynamically allocate the
> >wait_queue_t used whilst awaiting. This is more convenient if we extend
> >the i915_sw_fence_await_sw_fence() to
On 07/10/2016 17:12, Chris Wilson wrote:
On Fri, Oct 07, 2016 at 04:51:14PM +0100, Tvrtko Ursulin wrote:
On 07/10/2016 10:45, Chris Wilson wrote:
We will need to wait on DMA completion (as signaled via struct fence)
before executing our i915_gem_request. Therefore we want to expose a
method fo
On Fri, Oct 07, 2016 at 04:51:14PM +0100, Tvrtko Ursulin wrote:
>
> On 07/10/2016 10:45, Chris Wilson wrote:
> >We will need to wait on DMA completion (as signaled via struct fence)
> >before executing our i915_gem_request. Therefore we want to expose a
> >method for adding the await on the fence
On 07/10/2016 10:46, Chris Wilson wrote:
In forthcoming patches, we want to be able to dynamically allocate the
wait_queue_t used whilst awaiting. This is more convenient if we extend
the i915_sw_fence_await_sw_fence() to perform the allocation for us if
we pass in a gfp mask as an alternative t
On 07/10/2016 10:45, Chris Wilson wrote:
We will need to wait on DMA completion (as signaled via struct fence)
before executing our i915_gem_request. Therefore we want to expose a
method for adding the await on the fence itself to the request.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/
Sorry about how long this took! Anyway, finally got to testing it
Reviewed-by: Lyude
On Tue, 2016-10-04 at 14:37 -0300, Paulo Zanoni wrote:
> With the previous code we were only recomputing the DDB partitioning
> for the CRTCs included in the atomic commit, so any other active
> CRTCs
> would en
On Fri, Oct 07, 2016 at 03:51:50PM +0100, Tvrtko Ursulin wrote:
>
> On 07/10/2016 14:48, Ville Syrjälä wrote:
> > On Fri, Oct 07, 2016 at 02:34:12PM +0100, Tvrtko Ursulin wrote:
> >> From: Tvrtko Ursulin
> >>
> >> Convert to from signed to unsigned and from longs
> > Ddi you check that we can't g
On 07/10/2016 14:48, Ville Syrjälä wrote:
On Fri, Oct 07, 2016 at 02:34:12PM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Convert to from signed to unsigned and from longs
Ddi you check that we can't get negative values? Depending on how you do
things that can be possible on gmch platfo
intel_hpd_cancel_work() cancels a task that wants to enable output
polling. If we lose a race here, that task can run after we have already
tried to disable output polling for suspend - leaving output polling
enabled as we go to sleep, and running immediately upon resume.
Fixes: 19625e85c6ec ("drm
On Fri, 2016-10-07 at 10:41 -0300, Paulo Zanoni wrote:
> Em Qua, 2016-10-05 às 16:50 -0700, Anusha Srivatsa escreveu:
> > i915.enable_guc_loading/submission=2 forces the usage of GuC.
> > For platforms that do not have a GuC, asking the kernel to
> > use a GuC should not result in an error state. D
Whilst the vblank is configured to send an interrupt everytime, we need
to keep the device awake to process those interrupts.
Reported-by: Anssi Hannula
References: https://bugs.freedesktop.org/show_bug.cgi?id=97985
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_irq.c | 16 ++
On Fri, Oct 07, 2016 at 02:34:12PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Convert to from signed to unsigned and from longs
Ddi you check that we can't get negative values? Depending on how you do
things that can be possible on gmch platforms on account of the
watermarks being i
On 07/10/2016 10:46, Chris Wilson wrote:
We can use the radixtree index of the obj->pages to find the start
position of the desired partial range.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 38 +++--
1 file changed, 24 insertions(+),
Em Qua, 2016-10-05 às 16:50 -0700, Anusha Srivatsa escreveu:
> i915.enable_guc_loading/submission=2 forces the usage of GuC.
> For platforms that do not have a GuC, asking the kernel to
> use a GuC should not result in an error state. Do extra checks
> to see if the platform even has a GuC or not,
On Wed, Oct 05, 2016 at 07:23:23AM +0200, Greg KH wrote:
> On Tue, Oct 04, 2016 at 08:43:03PM -0300, Gaston Gonzalez wrote:
> > Hi,
> >
> > After hibernation I get the following error when I tried to connect to
> > monitor
> > through hdmi:
> >
> > $ xrandr --output LVDS1 --off --output HDMI1
On 07/10/2016 10:46, Chris Wilson wrote:
A while ago we switched from a contiguous array of pages into an sglist,
for that was both more convenient for mapping to hardware and avoided
the requirement for a vmalloc array of pages on every object. However,
certain GEM API calls (like pwrite, pread
From: Tvrtko Ursulin
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_pm.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 96d0c57c816c..68b3614c6a0b 100644
--- a/drivers/gpu
From: Tvrtko Ursulin
Either unsigned int is enough or it isn't. There is no point in
using an unsigned long here.
Also replace local long variables with integers. No need to have
a difference between 32- and 64-bit build in any case.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/inte
From: Tvrtko Ursulin
Make struct video_levels and struct tv_mode use data types
of sufficient width to save approximately one kilobyte in
the .rodata section.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_tv.c | 50 -
1 file changed, 30 in
From: Tvrtko Ursulin
Convert to from signed to unsigned and from longs
to integers where appropriate.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_pm.c | 60 +++--
1 file changed, 28 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/dr
From: Tvrtko Ursulin
Unsigned is a more appropriate data type in this case.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/intel_pm.c | 36 ++--
2 files changed, 19 insertions(+), 19 deletions(-)
diff --git a/dri
From: Tvrtko Ursulin
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_pm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 68b3614c6a0b..56726777b4d3 100644
--- a/drivers/gpu/drm/i915/intel_p
From: Tvrtko Ursulin
Pack the struct _sdvo_cmd_name to save 736 bytes of .rodata.
This is fine since the name pointers are used only for debug.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_sdvo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/d
From: Tvrtko Ursulin
unsigned long is too wide - use smaller types in
struct cxsr_latency to save 800-something bytes of .rodata.
v2: All data even fits in u16 for even more saving. (Ville Syrjala)
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_drv.h | 16
drive
From: Tvrtko Ursulin
Use types of more appropriate size in struct
intel_watermark_params to save 512 bytes of .rodata.
Signed-off-by: Tvrtko Ursulin
Acked-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_drv.h | 10 +-
drivers/gpu/drm/i915/intel_pm.c | 4 ++--
2 files changed, 7 ins
From: Tvrtko Ursulin
Drive by shrinkage of various static const tables. Also, Joonas complained about
some unsightly casts and too casual data type usage in the watermark code so
I've added a few fixes for that as well.
Series altogether saves around 3.5KiB of combined .text and .rodata.
tex
On Fri, Oct 7, 2016 at 4:19 PM, Joonas Lahtinen
wrote:
> On pe, 2016-10-07 at 15:03 +0530, akash.g...@intel.com wrote:
>> > From: Akash Goel
>>
>> With the possibility of addition of many more number of rings in future,
>> the drm_i915_private structure could bloat as an array, of type
>> intel_e
Since "Dynamic page table allocations" were introduced, our page tables
can grow (being dynamically allocated) with address space range usage.
Unfortunately, their lifetime is bound to vm. This is not a huge problem
when we're not using softpin - drm_mm is creating an upper bound on used
range by c
Let's use more top-down approach, where each gen8_ppgtt_clear_* function
is responsible for clearing the struct passed as an argument and calling
relevant clear_range functions on lower-level tables.
Doing this rather than operating on PTE ranges makes the implementation
of shrinking page tables qu
We never used any invalid ptes, those were put in place for
a possibility of doing gpu faults. However our batchbuffers are not
restricted in length, so everything needs to be pointing to something
and thus out-of-bounds is pointing to scratch.
Remove the valid flag as it is always true.
v2: Expa
On 10/7/2016 5:14 PM, Chris Wilson wrote:
On Fri, Oct 07, 2016 at 09:58:07AM -, Patchwork wrote:
== Series Details ==
Series: drm/i915: Allocate intel_engine_cs structure only for the enabled
engines
URL : https://patchwork.freedesktop.org/series/13435/
State : failure
== Summary ==
This is a testcase with multiple planes. The idea here is the following
- draw a uniform frame with blue color
- grab crc for reference
- put planes randomly on top with the same blue color
- punch holes with black color into the primary framebuffer
- ideally the planes should cover these hol
On Fri, Oct 07, 2016 at 09:58:07AM -, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Allocate intel_engine_cs structure only for the enabled
> engines
> URL : https://patchwork.freedesktop.org/series/13435/
> State : failure
>
> == Summary ==
>
> Series 13435v1 drm/i915: Al
On pe, 2016-10-07 at 12:05 +0100, Chris Wilson wrote:
> On Fri, Oct 07, 2016 at 01:12:58PM +0300, Joonas Lahtinen wrote:
> >
> > Patches 14-25 to a separate series. Will continue their review there.
>
> Nope. For reasons as I explained when I pulled them in, they are
> required to prevent a criti
On pe, 2016-10-07 at 12:03 +0100, Chris Wilson wrote:
> On Fri, Oct 07, 2016 at 01:27:12PM +0300, Joonas Lahtinen wrote:
> >
> > On pe, 2016-10-07 at 10:46 +0100, Chris Wilson wrote:
> > >
> > > @@ -324,14 +324,31 @@ submit_notify(struct i915_sw_fence *fence, enum
> > > i915_sw_fence_notify stat
On pe, 2016-10-07 at 12:00 +0100, Chris Wilson wrote:
> On Fri, Oct 07, 2016 at 01:29:09PM +0300, Joonas Lahtinen wrote:
> >
> > No changelog or comments, no re-review.
>
> Because it hasn't changed, it has been rebased, but the crux of the
> enabling is the same.
At least I have not received rep
On Fri, Oct 07, 2016 at 01:12:58PM +0300, Joonas Lahtinen wrote:
> Patches 14-25 to a separate series. Will continue their review there.
Nope. For reasons as I explained when I pulled them in, they are
required to prevent a critical use-after-free when moving the active
reference handling onto the
On Fri, Oct 07, 2016 at 01:27:12PM +0300, Joonas Lahtinen wrote:
> On pe, 2016-10-07 at 10:46 +0100, Chris Wilson wrote:
> > @@ -324,14 +324,31 @@ submit_notify(struct i915_sw_fence *fence, enum
> > i915_sw_fence_notify state)
> > struct drm_i915_gem_request *request =
> > containe
On Fri, Oct 07, 2016 at 01:29:09PM +0300, Joonas Lahtinen wrote:
> On pe, 2016-10-07 at 10:46 +0100, Chris Wilson wrote:
> > With the infrastructure converted over to tracking multiple timelines in
> > the GEM API whilst preserving the efficiency of using a single execution
> > timeline internally,
On pe, 2016-10-07 at 15:03 +0530, akash.g...@intel.com wrote:
> > From: Akash Goel
>
> With the possibility of addition of many more number of rings in future,
> the drm_i915_private structure could bloat as an array, of type
> intel_engine_cs, is embedded inside it.
> struct intel_engine_c
On pe, 2016-10-07 at 10:46 +0100, Chris Wilson wrote:
> With the infrastructure converted over to tracking multiple timelines in
> the GEM API whilst preserving the efficiency of using a single execution
> timeline internally, we can now assign a separate timeline to every
> context with full-ppgtt
On pe, 2016-10-07 at 10:46 +0100, Chris Wilson wrote:
> @@ -324,14 +324,31 @@ submit_notify(struct i915_sw_fence *fence, enum
> i915_sw_fence_notify state)
> struct drm_i915_gem_request *request =
> container_of(fence, typeof(*request), submit);
> struct intel_engine_cs *
On pe, 2016-10-07 at 10:46 +0100, Chris Wilson wrote:
> Defer the assignment of the global seqno on a request to its submission.
> In the next patch, we will only allocate the global seqno at that time,
> here we are just enabling the wait-for-submission before wait-for-seqno
> paths.
>
> Signed-o
== Series Details ==
Series: series starting with [01/42] drm/i915: Allow disabling error capture
URL : https://patchwork.freedesktop.org/series/13436/
State : warning
== Summary ==
Series 13436v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/13436/revisions/1/mb
Patches 14-25 to a separate series. Will continue their review there.
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/lis
On pe, 2016-10-07 at 10:45 +0100, Chris Wilson wrote:
> The error state is purposefully racy as we expect it to be called at any
> time and so have avoided any locking whilst capturing the crash dump.
> However, with multi-engine GPUs and multiple CPUs, those races can
> manifest into OOPSes as we
1 - 100 of 169 matches
Mail list logo
