Signed-off-by: Dave Gordon
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h | 23 +--
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 01cde0f..53ff499 100644
--- a/drivers/gpu/drm/i915/
We're using this function for ringbuffers and other "small" objects, so
it's worth avoiding an extra malloc()/free() cycle if the page array is
small enough to put on the stack. Here we've chosen an arbitrary cutoff
of 32 (4k) pages, which is big enough for a ringbuffer (4 pages) or a
context image
The recently-added i915_gem_object_pin_map() can be further optimised
for "small" objects. To facilitate this, and simplify the error paths
before adding the new code, this patch pulls out the "mapping" part of
the operation (involving local allocations which must be undone before
return) into its
The existing for_each_sg_page() iterator is somewhat heavyweight, and is
limiting i915 driver performance in a few benchmarks. So here we
introduce somewhat lighter weight iterators, primarily for use with GEM
objects or other case where we need only deal with whole aligned pages.
Unlike the old i
Hi Lukas,
On 19 May 2016 at 15:39, Lukas Wunner wrote:
> +bool vga_switcheroo_client_probe_defer(struct pci_dev *pdev)
> +{
> + if ((pdev->class >> 8) == PCI_CLASS_DISPLAY_VGA) {
Not sure if we want/need this, yet at least. This changes behaviour
which is not what refactoring patches shoul
I'm still seeing this periodically, previous to today it happened on
April 24th. Doesn't matter what I'm doing the video will freeze however
the cursor will still move. Only option is to SSH in to the system from
my tablet and do a reboot.
Note: This has been going on since Sept 13, 2014. There co
From: "Kumar, Mahesh"
if downscaling is enabled plane data rate increases according to scaling
amount. take scaling amount under consideration while calculating plane
data rate
v2: Address Matt's comments, where data rate was overridden because of
missing else.
v3 (by Matt):
- Add braces to 'e
Hi Daniel,
Thank you for the patch.
On Wednesday 18 May 2016 22:29:57 Daniel Vetter wrote:
> This was added in
>
> commit 0a3e67a4caac273a3bfc4ced3da364830b1ab241
> Author: Jesse Barnes
> Date: Tue Sep 30 12:14:26 2008 -0700
>
> drm: Rework vblank-wait handling to allow interrupt reducti
Thanks for reviewing, I have a few comments/queries as below:
Manasi
On Thu, May 19, 2016 at 06:40:45PM +0300, Marius Vlad wrote:
> On Mon, May 16, 2016 at 05:50:40PM -0700, Manasi Navare wrote:
> > This is the userspace component of the Displayport Compliance
> > testing software required for co
Hi Chris,
On Thu, May 19, 2016 at 09:28:10AM +0100, Chris Wilson wrote:
> During cleanup we have to synchronise with the async task we are using
> to initialise and register our fbdev. Currently, we are using a full
> synchronisation on the global domain, but we can restrict this to just
> synchro
On Mon, 2016-05-16 at 16:59 +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Like with cdclk, the DMC is supposed to manage dbuf enabling/disabling.
> Let's make sure it has correctly restored the dbuf state to enabled
> when we disable the DC states.
>
> Cc: Imre Deak
> Su
On Fri, 2016-05-13 at 23:41 +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> In case the driver is initialized without active displays, we should
> just drop the cdclk to the minimum frequency right off the bat. There
> might not be a modeset to drop it to the minimum late ra
On Fri, 2016-05-13 at 23:41 +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Rather than having a BXT specific function to make sure the DE PLL is
> enabled after disabling DC6, let's just make sure the current cdclk
> is the same as what we last programmed.
>
> Having anoth
On Fri, 2016-05-13 at 23:41 +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Make bxt_set_cdclk() more readable by looking at current vs. target
> DE PLL vco to determine if the DE PLL needs disabling and/or enabling.
> We can also calculate the CD2X divider simply as (vco/cd
On Fri, 2016-05-13 at 23:41 +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Now that we've read out the DE PLL vco and refclk, we can just use them
> in the cdclk calculation. While at it switch over to
> DIV_ROUND_CLOSEST().
>
> Signed-off-by: Ville Syrjälä
Reviewed-by:
On Fri, 2016-05-13 at 23:41 +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Let's make sure our cached cdclk state is accurate right after
> broxton_init_cdclk() whether or not we end up changing the cdclk
> frequency.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Imre De
On Fri, 2016-05-13 at 23:41 +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> We have need to know the DE PLL refclk and output frequency in various
> cdclk calculations, so let's store those in dev_priv.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Imre Deak
> ---
> dr
On pe, 2016-05-13 at 23:41 +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Enabling and disalbing the DE PLL are two nice self contained
> operations, so let's move them into a few small helper functions.
> Makes it easier to see the forest from the trees in broxton_set_cdcl
On pe, 2016-05-13 at 23:41 +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Future platforms will have multiple options for the cdclk PLL reference
> clock, so let's start tracking that under dev_priv alreday on SKL,
> although on SKL it's always 24 MHz.
>
> Signed-off-by: V
On Thu, May 19, 2016 at 07:17:17PM +0300, Imre Deak wrote:
> On pe, 2016-05-13 at 23:41 +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > We'll want to store the cdclk PLL (whatever PLL that is in reality) vco
> > frequency somewhere on other platforms too, so let's rena
On pe, 2016-05-13 at 23:41 +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> We'll want to store the cdclk PLL (whatever PLL that is in reality) vco
> frequency somewhere on other platforms too, so let's rename the
> skl_vco_freq to cdclk_pll.vco, and let's store it in kHz ins
== Series Details ==
Series: vga_switcheroo: Add helper for deferred probing
URL : https://patchwork.freedesktop.org/series/7409/
State : failure
== Summary ==
Series 7409v1 vga_switcheroo: Add helper for deferred probing
http://patchwork.freedesktop.org/api/1.0/series/7409/revisions/1/mbox
T
On pe, 2016-05-13 at 23:41 +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> The SKL 308.57 MHz cdclk is probably 8640/28 = ~308.571 Mhz.
> Similartly the 617.14 MHz cdclk is probably 8640/14 = ~617.143 MHz.
> Let's use the slightly more accurate numbers. Potentially we might
On pe, 2016-05-13 at 23:41 +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> SKL and BXT have the same snippets of code for enabling disabling the
> DBUF. Extract those into helpers and move the calls from
> init/unit_cdclk() to the display core init/init since this stuff isn'
== Series Details ==
Series: drm/i915/userptr: Convert to drm_i915_private
URL : https://patchwork.freedesktop.org/series/7413/
State : failure
== Summary ==
Series 7413v1 drm/i915/userptr: Convert to drm_i915_private
http://patchwork.freedesktop.org/api/1.0/series/7413/revisions/1/mbox
Test
On pe, 2016-05-13 at 23:41 +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Currently we initialize cdclk on SKL from two different places,
> depending on whether it's during driver init or resume. Let's
> unify it to happen from the same place always, and that place will be
On 19/05/16 12:32, Chris Wilson wrote:
Avoid the two calls to ktime_get_raw_ns() (at best it reads the TSC) as
we only need to compute the elapsed time for a timed wait.
v2: Eliminate the unused local variable reducing the function size by 64
bytes (using the storage space on the callers stack
On Mon, May 16, 2016 at 05:50:40PM -0700, Manasi Navare wrote:
> This is the userspace component of the Displayport Compliance
> testing software required for compliance testing of the I915
> Display Port driver. This must be running in order to successfully
> complete Display Port compliance testi
On Thu, May 19, 2016 at 2:10 PM, Patrik Jakobsson
wrote:
> On Tue, May 17, 2016 at 03:08:04PM +0200, Maarten Lankhorst wrote:
>> Signed-off-by: Maarten Lankhorst
>
> We could have had a short note on what the patch does, though reading it is
> quite straight forward. Either way is fine by me.
0-
On 19/05/16 16:17, Chris Wilson wrote:
userptr directly only uses drm_device in a single interface where it
meant to use drm_i915_private (everywhere else we have to derive it from
the drm_i915_gem_object and so require going from drm_device).
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc
userptr directly only uses drm_device in a single interface where it
meant to use drm_i915_private (everywhere else we have to derive it from
the drm_i915_gem_object and so require going from drm_device).
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i9
On Thu, May 19, 2016 at 01:23:53PM -, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: only disable memory self-refresh on GMCH
> URL : https://patchwork.freedesktop.org/series/7406/
> State : failure
>
> == Summary ==
>
> Series 7406v1 drm/i915: only disable memory self-refre
On pe, 2016-05-13 at 23:41 +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Also verify the DPLL_CTRL1 register value in skl_sanitize_cdclk(), throw
> out a few unneeded variables, and write the CDCLK_CTL check a bit more
> legible way.
>
> Signed-off-by: Ville Syrjälä
Rev
On pe, 2016-05-13 at 23:41 +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Now that skl_vco_freq tracks the actual DPLL0 vco frequency, we'll need
> something that keeps track of which vco frequency we want to use in case
> the current vco is 0. This would be important acros
A follow-up to the previous commit, we skip checking the status of the
MST device and completely reprobe it if drm_dp_mst_topology_mgr_resume()
returns -EINVAL.
Cc: sta...@vger.kernel.org
Signed-off-by: Lyude
---
drivers/gpu/drm/i915/intel_dp.c | 11 +--
1 file changed, 9 insertions(+),
As observed with the latest ThinkPad docks, we unfortunately can't rely
on docks keeping us updated with hotplug events that happened while we
were suspended. On top of that, even if the number of connectors remains
the same between suspend and resume it's still not safe to assume that
there were n
On Thu, May 19, 2016 at 07:02:40AM -0700, Ben Widawsky wrote:
> On Thu, May 19, 2016 at 12:28:10PM +0100, Damien Lespiau wrote:
> > On Mon, May 16, 2016 at 01:39:10PM +0300, Marius Vlad wrote:
> > > Signed-off-by: Marius Vlad
> > > ---
> > > assembler/gram.y | 74
> > > ++
On Thu, May 19, 2016 at 12:28:10PM +0100, Damien Lespiau wrote:
> On Mon, May 16, 2016 at 01:39:10PM +0300, Marius Vlad wrote:
> > Signed-off-by: Marius Vlad
> > ---
> > assembler/gram.y | 74
> >
> > 1 file changed, 37 insertions(+), 37 d
So far we've got one condition when DRM drivers need to defer probing
on a dual GPU system and it's coded separately into each of the relevant
drivers. As suggested by Daniel Vetter, deduplicate that code in the
drivers and move it to a new vga_switcheroo helper. This yields better
encapsulation of
On to, 2016-05-19 at 16:18 +0300, Ville Syrjälä wrote:
> On Thu, May 19, 2016 at 04:04:40PM +0300, Imre Deak wrote:
> > On pe, 2016-05-13 at 23:41 +0300, ville.syrj...@linux.intel.com wrote:
> > > From: Ville Syrjälä
> > >
> > > In case we originally guessed wrong which lcpll vco frequency to use
== Series Details ==
Series: drm/i915: only disable memory self-refresh on GMCH
URL : https://patchwork.freedesktop.org/series/7406/
State : failure
== Summary ==
Series 7406v1 drm/i915: only disable memory self-refresh on GMCH
http://patchwork.freedesktop.org/api/1.0/series/7406/revisions/1/m
On Thu, May 19, 2016 at 04:04:40PM +0300, Imre Deak wrote:
> On pe, 2016-05-13 at 23:41 +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > In case we originally guessed wrong which lcpll vco frequency to use,
> > we will need to shut down the pll and restart it when repro
On Thu, May 19, 2016 at 01:53:51PM +0100, Tvrtko Ursulin wrote:
>
>
> On 19/05/16 12:32, Chris Wilson wrote:
> >Since the function is a small wrapper around schedule_delayed_work(),
> >move it inline to remove the function call overhead for the principle
> >caller.
>
> Alternatively move it to i
On Thu, May 19, 2016 at 01:50:51PM +0100, Tvrtko Ursulin wrote:
>
> On 19/05/16 12:32, Chris Wilson wrote:
> >The queue only ever contains at most one item and has no special flags.
> >It is just a very simple wrapper around the system-wq - a complication
> >with no benefits.
>
> How much time do
On pe, 2016-05-13 at 23:41 +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> In case we originally guessed wrong which lcpll vco frequency to use,
> we will need to shut down the pll and restart it when reprogamming the
> cdclk.
>
> This also allows us to track the actual vco
On 19/05/16 12:32, Chris Wilson wrote:
Since the function is a small wrapper around schedule_delayed_work(),
move it inline to remove the function call overhead for the principle
caller.
Alternatively move it to i915_gem.c and let the compiler decide?
But it is small enough, so anyway:
Revie
On Thu, May 19, 2016 at 01:34:55PM +0100, Tvrtko Ursulin wrote:
>
> On 19/05/16 12:32, Chris Wilson wrote:
> >We can forgo queuing the hangcheck from the start of every request to
> >until we wait upon a request. This reduces the overhead of every
> >request, but may increase the latency of detect
On 19/05/16 12:32, Chris Wilson wrote:
The queue only ever contains at most one item and has no special flags.
It is just a very simple wrapper around the system-wq - a complication
with no benefits.
How much time do we take in the reset case - is it acceptable to do that
work from the system
The atomic version of intel_pre_plane_update did not check
for HAS_GMCH_DISPLAY before calling intel_set_memory_cxsr().
While this doesn't cause any issues on its own (it will
return without doing anything if the hardware doesn't
have the required feature), the drm_wait_one_vblank() that
is needed
Allow users of autogen.sh to skip the call to configure, which is needed
when building out of tree.
Signed-off-by: Tomeu Vizoso
---
autogen.sh | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/autogen.sh b/autogen.sh
index 629a2575532d..ec633f3efefd 100755
--- a/autogen.sh
+
On pe, 2016-05-13 at 23:41 +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Imre Deak
> ---
> drivers/gpu/drm/i915/intel_display.c | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm
On pe, 2016-05-13 at 23:41 +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Currently we're trying to guess which lcpll vco frequency is used
> use based on the cdclk. That doesn't work for cdclk==540 since
> both vco frequencies can generate a 540 Mhz output. Let's stop
> gu
On 19/05/16 12:32, Chris Wilson wrote:
We can forgo queuing the hangcheck from the start of every request to
until we wait upon a request. This reduces the overhead of every
request, but may increase the latency of detecting a hang. Howeever, if
nothing every waits upon a hang, did it ever hang?
On Tue, May 17, 2016 at 03:07:43PM +0200, Maarten Lankhorst wrote:
> Connector lifetime patches forced a rethinking for handling connectors.
> Instead of flushing modesets from the connector destroy function this
> meant destroying the connector state inside the unpin_work function,
> similar to th
On 19/05/16 12:32, Chris Wilson wrote:
As we inspect obj->active to decide how many objects we can shrink (we
only shrink idle objects), it helps to flush the active lists first
in order to have a more accurate count of available objects.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/
On Tue, May 17, 2016 at 03:08:04PM +0200, Maarten Lankhorst wrote:
> Signed-off-by: Maarten Lankhorst
We could have had a short note on what the patch does, though reading it is
quite straight forward. Either way is fine by me.
Reviewed-by: Patrik Jakobsson
> ---
> drivers/gpu/drm/i915/intel_
== Series Details ==
Series: series starting with [CI,01/20] drm: Restore double clflush on the last
partial cacheline
URL : https://patchwork.freedesktop.org/series/7403/
State : warning
== Summary ==
Series 7403v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/7
On pe, 2016-05-13 at 23:41 +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> We have many places where we want to pick a suitable cdclk frequency for
> skl based on the dotclock and lcpll vco. Split that code into a small
> helper and call it from all over.
>
> Signed-off-by:
On pe, 2016-05-13 at 23:41 +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Shared plls won't get assigned until the .compute_clocks() hook gets
> called, which happens from the crtc .atomic_check hook. That's too late
> as the cdclk computation has already happened. So let's
On Tue, May 17, 2016 at 03:08:01PM +0200, Maarten Lankhorst wrote:
> All of intel_post_plane_update is handled there now, so move it over.
> This is run after the hw state checker because it can't handle checking
> crtc's separately yet.
>
> Signed-off-by: Maarten Lankhorst
Reviewed-by: Patrik J
On Thu, May 19, 2016 at 10:02:40AM -, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Enable GSE interrupt on BDW+ (rev2)
> URL : https://patchwork.freedesktop.org/series/1366/
> State : failure
>
> == Summary ==
>
> Series 1366v2 drm/i915: Enable GSE interrupt on BDW+
> http
One particularly stressful scenario consists of many independent tasks
all competing for GPU time and waiting upon the results (e.g. realtime
transcoding of many, many streams). One bottleneck in particular is that
each client waits on its own results, but every client is woken up after
every batch
If we convert the tracing over from direct use of ring->irq_get() and
over to the breadcrumb infrastructure, we only have a single user of the
ring->irq_get and so we will be able to simplify the driver routines
(eliminating the redundant validation and irq refcounting).
v2: Move to a signaling fr
Borrow the idea from intel_lrc.c to precompute the mask of interrupts we
wish to always enable to avoid having lots of conditionals inside the
interrupt enabling.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 35 +++--
drivers/gpu/drm/i915/
The queue only ever contains at most one item and has no special flags.
It is just a very simple wrapper around the system-wq - a complication
with no benefits.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_dma.c | 8
drivers/gpu/drm/i915/i915_drv.h | 1 -
drivers/gpu/drm/i9
We have testcases to ensure that seqno wraparound works fine, so we can
forgo forcing everyone to encounter seqno wraparound during early
uptime. seqno wraparound incurs a full GPU stall so not forcing it
will eliminate one jitter from the early system. Using the testcases, we
have very determinist
With the last direct CPU access to the scratch page removed, we can now
allocate it from our small amount of reserved system pages (stolen
memory).
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drive
With only a single callsite for intel_engine_cs->irq_get and ->irq_put,
we can reduce the code size by moving the common preamble into the
caller, and we can also eliminate the reference counting.
For completeness, as we are no longer doing reference counting on irq,
rename the get/put vfunctions
On Ironlake, there is no command nor register to ensure that the write
from a MI_STORE command is completed (and coherent on the CPU) before the
command parser continues. This means that the ordering between the seqno
write and the subsequent user interrupt is undefined (like gen6+). So to
ensure t
Since the tests can and do explicitly check debugfs/i915_ring_missed_irqs
for the handling of a "missed interrupt", adding it to the dmesg at INFO
is just noise. When it happens for real, we still class it as an ERROR.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_irq.c | 3 ---
1 fi
After the elimination of using the scratch page for Ironlake's
breadcrumb, we no longer need to kmap the object. We therefore can move
it into the high unmappable space and do not need to force the object to
be coherent (i.e. snooped on !llc platforms).
Signed-off-by: Chris Wilson
---
drivers/gp
Now that we have split out the seqno-barrier from the
engine->get_seqno() callback itself, we can move the users of the
seqno-barrier to the required callsites simplifying the common code and
making the required workaround handling much more explicit.
Signed-off-by: Chris Wilson
---
drivers/gpu/
The gen2 w/a buffer is stuffed into the same slot as the gen5+ scratch
buffer. If we pass in the size we want to allocate for the scratch
buffer, both callers can use the same routine.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_lrc.c| 2 +-
drivers/gpu/drm/i915/intel_rin
By using the same address for storing the HWS on every platform, we can
remove the platform specific vfuncs and reduce the get-seqno routine to
a single read of a cached memory location.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c | 6 +--
drivers/gpu/drm/i915/i915_
Avoid the two calls to ktime_get_raw_ns() (at best it reads the TSC) as
we only need to compute the elapsed time for a timed wait.
v2: Eliminate the unused local variable reducing the function size by 64
bytes (using the storage space on the callers stack rather than adding
to our stack frame)
Si
If we have multiple waiters, we may find that many complete on the same
wake up. If we first inspect the seqno from the CPU cache, we may reduce
the number of heavyweight coherent seqno reads we require.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h | 14 ++
1 file
We can forgo queuing the hangcheck from the start of every request to
until we wait upon a request. This reduces the overhead of every
request, but may increase the latency of detecting a hang. Howeever, if
nothing every waits upon a hang, did it ever hang? It also improves the
robustness of the wa
This effectively reverts
commit afcd950cafea6e27b739fe7772cbbeed37d05b8b
Author: Chris Wilson
Date: Wed Jun 10 15:58:01 2015 +0100
drm: Avoid the double clflush on the last cache line in
drm_clflush_virt_range()
as we have observed issues with serialisation of the clflush operations
on B
Since the function is a small wrapper around schedule_delayed_work(),
move it inline to remove the function call overhead for the principle
caller.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h | 17 -
drivers/gpu/drm/i915/i915_irq.c | 16
2 fil
If we flag the seqno as potentially stale upon receiving an interrupt,
we can use that information to reduce the frequency that we apply the
heavyweight coherent seqno read (i.e. if we wake up a chain of waiters).
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h | 15
As we inspect obj->active to decide how many objects we can shrink (we
only shrink idle objects), it helps to flush the active lists first
in order to have a more accurate count of available objects.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_shrinker.c | 2 ++
1 file changed,
On Mon, May 16, 2016 at 01:39:10PM +0300, Marius Vlad wrote:
> Signed-off-by: Marius Vlad
> ---
> assembler/gram.y | 74
>
> 1 file changed, 37 insertions(+), 37 deletions(-)
The only way to test the change is to regenerate the vaapi shad
On Tue, May 17, 2016 at 03:08:00PM +0200, Maarten Lankhorst wrote:
> intel_unpin_work may not take the list lock because it requires the
> connector_mutex.
> To prevent taking locks we add an array of old and new state. The old state
> to free,
> the new state to commit and verify.
>
> Signed-of
On Tue, May 17, 2016 at 03:07:54PM +0200, Maarten Lankhorst wrote:
> Create a work structure that will be used for all changes. This will
> be used later on in the atomic commit function.
>
> Changes since v1:
> - Free old_crtc_state from unpin_work_fn properly.
> Changes since v2:
> - Add hunk fo
On 5/18/2016 10:17 PM, Daniel Vetter wrote:
Oops. Hw default for programming these fields to 0 is "skip link
training". Display won't take that too well usually.
But we were defaulting it to value 0, which means 500us for both TP1 and
TP2 or TP3 time.
I dont think it means skip link training.
== Series Details ==
Series: drm/i915/fbdev: Limit the global async-domain synchronization (rev2)
URL : https://patchwork.freedesktop.org/series/7332/
State : success
== Summary ==
Series 7332v2 drm/i915/fbdev: Limit the global async-domain synchronization
http://patchwork.freedesktop.org/api/
== Series Details ==
Series: drm/i915: Enable GSE interrupt on BDW+ (rev2)
URL : https://patchwork.freedesktop.org/series/1366/
State : failure
== Summary ==
Series 1366v2 drm/i915: Enable GSE interrupt on BDW+
http://patchwork.freedesktop.org/api/1.0/series/1366/revisions/2/mbox
Test drv_han
On Fri, May 13, 2016 at 10:19:11AM +0100, John Harrison wrote:
> On 13/05/2016 08:27, Chris Wilson wrote:
> >On Thu, May 12, 2016 at 10:06:34PM +0100, john.c.harri...@intel.com wrote:
> >>+void i915_gem_request_notify(struct intel_engine_cs *engine, bool
> >>fence_locked)
> >>+{
> >>+ struct drm
On 5/18/2016 11:56 PM, Ville Syrjälä wrote:
On Wed, May 18, 2016 at 06:47:10PM +0200, Daniel Vetter wrote:
The definitions for the error register should be valid on bdw/skl too,
but there we haven't even enabled DE_MISC handling yet.
Somewhat confusing the the moved register offset on bdw is
Op 12-05-16 om 23:06 schreef john.c.harri...@intel.com:
> From: John Harrison
>
> The intended usage model for struct fence is that the signalled status
> should be set on demand rather than polled. That is, there should not
> be a need for a 'signaled' function to be called everytime the status
>
On Thu, May 19, 2016 at 12:08:42PM +0300, Imre Deak wrote:
> On pe, 2016-05-13 at 23:41 +0300, ville.syrj...@linux.intel.com wrote:
> > From: Clint Taylor
> >
> > WARNING: Using ChromeOS with an eDP panel and a 4K@60 DP monitor connected
> > to DDI1 the system will hard hang during a cold boot. O
From: Ville Syrjälä
We've never actually enabled or unmasked the GSE interrupt on BDW+,
even though the interrupt handler was always prepared for it.
Let's enable it and see what happens.
Credit to Mark Kettenis who fixed this in the OpenBSD fork of the
driver. He reports that it fixed the "ACPI
On pe, 2016-05-13 at 23:41 +0300, ville.syrj...@linux.intel.com wrote:
> From: Clint Taylor
>
> WARNING: Using ChromeOS with an eDP panel and a 4K@60 DP monitor connected
> to DDI1 the system will hard hang during a cold boot. Occurs when DDI1
> is enabled when the cdclk is less then required. DP
Looks good to me.
Reviewed-by: Sonika Jindal
On 5/19/2016 12:44 PM, Daniel Vetter wrote:
Found this while browsing Bspec. Looks like it applies to both skl and
kbl.
v2: Also for bxt (Art).
Cc: Rodrigo Vivi
Cc: Sonika Jindal
Cc: Durgadoss R
Cc: "Pandiyan, Dhinakaran"
Cc: "Runyan, Arthur
From: Ville Syrjälä
Add a small helper to parse the PSR setup time from the DPCD PSR
capabilities and return the value in microseconds.
v2: Don't waste so many bytes on the psr_setup_time_us[] table
Cc: Daniel Vetter
Reviewed-by: Daniel Vetter
Signed-off-by: Ville Syrjälä
---
drivers/gpu/dr
== Series Details ==
Series: series starting with [1/5] drm/i915: Convert RPS irq worker into a
tasklet
URL : https://patchwork.freedesktop.org/series/7386/
State : failure
== Summary ==
Series 7386v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/7386/revisions/1
During cleanup we have to synchronise with the async task we are using
to initialise and register our fbdev. Currently, we are using a full
synchronisation on the global domain, but we can restrict this to just
synchronising up to our task if we remember our cookie.
v2: async_synchronize_cookie()
On Tue, May 17, 2016 at 03:08:03PM +0200, Maarten Lankhorst wrote:
> If planes are added to the state after the call to
> drm_atomic_helper_check_planes planes_changed may not be set
> and we will not unpin the old framebuffer. This results in a
> pin leak long after the framebuffer is destroyed, s
On Thu, May 19, 2016 at 08:48:29AM +0100, Chris Wilson wrote:
> Just a small set to convert our irq bottom-halves to use a tasklet
> instead of a work_struct. In theory, the tasklet has lower latency
> from the interrupt (or lower upper bound at least), but in practice I
> think it is clearer to be
On Wed, May 18, 2016 at 10:29:57PM +0200, Daniel Vetter wrote:
> This was added in
>
> commit 0a3e67a4caac273a3bfc4ced3da364830b1ab241
> Author: Jesse Barnes
> Date: Tue Sep 30 12:14:26 2008 -0700
>
> drm: Rework vblank-wait handling to allow interrupt reduction.
>
> to stay backwards-com
1 - 100 of 108 matches
Mail list logo
