Fix pointer length compilations errors on 32-bit systems.
Signed-off-by: Robert Foss
---
tests/perf.c | 42 +-
1 file changed, 21 insertions(+), 21 deletions(-)
diff --git a/tests/perf.c b/tests/perf.c
index 87df9f00..11838299 100644
--- a/tests/perf.c
++
These 2 patches shouldn't impact the platforms that have none zero num_pipes.
BXT
has 3 pipes, so the dmesg warning in following test case isn't caused by these
2 patches.
Test kms_frontbuffer_tracking:
Subgroup basic:
pass -> DMESG-WARN (fi-bxt-j4205)
https
From: "Navare, Manasi D"
The detect_done flag was introduced in the 'commit 7d23e3c37bb3
("drm/i915: Cleaning up intel_dp_hpd_pulse")' in order to avoid multiple
detects on hotplug where intel_dp_long_pulse() was called from HPD handler
as well as intel_dp_detect(). Later, 'commit 1015811609c0
("
Hi Swati,
On Monday 19 Dec 2016 16:12:22 swati.dhin...@intel.com wrote:
> From: Swati Dhingra
>
> Currently, we don't have a stable ABI which can be used for the purpose of
> providing output debug/loggging/crc and other such data from DRM.
> The ABI in current use (filesystems, ioctls, et al.)
On Sun, 2016-12-18 at 14:43 +0100, Daniel Vetter wrote:
> On Sat, Dec 17, 2016 at 05:47:56AM +, Pandiyan, Dhinakaran wrote:
> > On Fri, 2016-12-16 at 16:47 +0200, Jani Nikula wrote:
> > > On Fri, 16 Dec 2016, Daniel Vetter wrote:
> > > > On Fri, Dec 16, 2016 at 12:29:05PM +0200, Jani Nikula wr
== Series Details ==
Series: drm/i915: Remove useless VLV_FEATURE Macro.
URL : https://patchwork.freedesktop.org/series/17018/
State : success
== Summary ==
Series 17018v1 drm/i915: Remove useless VLV_FEATURE Macro.
https://patchwork.freedesktop.org/api/1.0/series/17018/revisions/1/mbox/
fi-
This macro got useless after commit 8d9c20e1d1e38
"drm/i915: Remove .is_mobile field from platform struct"
that removed is_mobile split from VLV definition.
Also this was never reused on any following platform.
So let's clean up a bit here.
Cc: Carlos Santa
Cc: Daniel Vetter
Signed-off-by: Rod
Let's take usage of IS_LP to simplify the gem stolen
initialization as suggest by Tvrtko.
Also assume that all new LP platforms follows the chv+
and others bdw+.
v2: Remove the wrong commit message about bxt and glk. (Ander)
Cc: Ander Conselvan de Oliveira
Cc: Imre Deak
Cc: Mika Kuoppala
Cc:
On Mon, Dec 19, 2016 at 10:24:15AM -0800, Matt Roper wrote:
> On Thu, Dec 15, 2016 at 09:59:51PM +0200, Ville Syrjälä wrote:
> > On Thu, Dec 15, 2016 at 05:50:02PM -0200, Paulo Zanoni wrote:
> > > Em Qui, 2016-12-15 às 21:11 +0200, Ville Syrjälä escreveu:
> > > > On Thu, Dec 15, 2016 at 05:05:05PM
On Thu, Dec 15, 2016 at 09:59:51PM +0200, Ville Syrjälä wrote:
> On Thu, Dec 15, 2016 at 05:50:02PM -0200, Paulo Zanoni wrote:
> > Em Qui, 2016-12-15 às 21:11 +0200, Ville Syrjälä escreveu:
> > > On Thu, Dec 15, 2016 at 05:05:05PM -0200, Paulo Zanoni wrote:
> > > >
> > > > Em Ter, 2016-11-22 às 18
== Series Details ==
Series: drm/i915: Introduce intel_cdclk_state (rev2)
URL : https://patchwork.freedesktop.org/series/16994/
State : success
== Summary ==
Series 16994v2 drm/i915: Introduce intel_cdclk_state
https://patchwork.freedesktop.org/api/1.0/series/16994/revisions/2/mbox/
fi-bdw-5
On 19/12/16 00:27, Tvrtko Ursulin wrote:
On 16/12/2016 20:20, Michel Thierry wrote:
From: Arun Siluvery
@@ -937,6 +937,7 @@ struct drm_i915_error_state {
enum intel_engine_hangcheck_action hangcheck_action;
struct i915_address_space *vm;
int num_requests;
+
On Mon, 19 Dec 2016, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Let's clean up the mess we have in the if ladder that assigns the
> .get_cdclk() hooks. The grouping of the platforms by the function
> results in a thing that's not really legible, so let's do it the
> other way a
From: Ville Syrjälä
Move the vlv_program_pfi_credits() into vlv_set_cdclk() and
chv_set_cdclk() so that we can neuter vlv_modeset_commit_cdclk().
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_cdclk.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/
From: Ville Syrjälä
The hack to grab the pipe A power domain around VLV/CHV cdclk
programming has surely outlived its usefulness. We should be
hold sufficient power domains during any modeset, so let's just
nuke this hack.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_cdclk.c | 1
From: Ville Syrjälä
With the cdclk state, all the .modeset_commit_cdclk() hooks are
now pointless wrappers. Let's replace them with just a .set_cdclk()
function pointer. However let's wrap that in a small helper that
does the state comparison and prints a unified debug message across
all platform
From: Ville Syrjälä
Rather than passing all the different parameters (cdclk,vco so
far) sparately to the set_cdclk() functions, just pass the
entire cdclk state.
v2: Deal with churn
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_cdclk.c | 79 +++---
From: Ville Syrjälä
The current dev_cdclk vs. cdclk vs. atomic_cdclk_freq is quite a mess.
So here I'm introducing the "actual" and "logical" naming for our
cdclk state. "actual" is what we'll bash into the hardware and "logical"
is what everyone should use for state computaion/checking and whatn
From: Ville Syrjälä
Move ilk_pipe_pixel_rate() next to its only caller
(intel_crtc_compute_pixel_rate()).
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 35 +++
drivers/gpu/drm/i915/intel_drv.h | 1 -
drivers/gpu/drm/i915/intel_pm.c
From: Ville Syrjälä
ilk_max_pixel_rate() will now give the "correct" pixel rate for all
platforms, so let's kill rename it to intel_max_pixel_rate() and kill
off intel_mode_max_pixclk().
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 41 ++--
From: Ville Syrjälä
Introduce intel_cdclk state which for now will track the cdclk
frequency, the vco frequency and the reference frequency (not sure we
want the last one, but I put it there anyway). We'll also make the
.get_cdclk() function fill out this state structure rather than
just returnin
From: Ville Syrjälä
Clean up the dev vs. dev_priv straggles that are making things
look inconsistentt.
v2: Deal with churn
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_cdclk.c | 25 ++---
1 file changed, 10 insertions(+), 15 deletions(-)
diff --git a/driver
From: Ville Syrjälä
Rename the .get_display_clock_speed() hook to .get_cdclk().
.get_cdclk() is more specific (which clock) and it's much
shorter.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/intel_display.c| 93 +---
From: Ville Syrjälä
Rather than compute the vco inside bxt_set_cdclk() let's precompute it
outside and pass it in. A small step towards a fully precomputed cdclk
state.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_cdclk.c | 33 +++--
1 file changed, 1
From: Ville Syrjälä
Let's clean up the mess we have in the if ladder that assigns the
.get_cdclk() hooks. The grouping of the platforms by the function
results in a thing that's not really legible, so let's do it the
other way around and order the if ladder by platform and duplicate
whatever assi
From: Ville Syrjälä
Attempt number two. This time it might actually work.
The main change involved actually committing the
correct thing, and comparing against the other correct
thing to know whether we need to commit it.
Full series:
git://github.com/vsyrjala/linux.git cdclk_state_3
Ville Syr
From: Ville Syrjälä
Rather than recomptuing the pipe pixel rate on demand everwhere, let's
just stick the precomputed value into the crtc state.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 31 ++-
drivers/gpu/drm/i915/intel_drv.h | 2
== Series Details ==
Series: drm/i915: Silence allocation failure during sg_trim()
URL : https://patchwork.freedesktop.org/series/17001/
State : success
== Summary ==
Series 17001v1 drm/i915: Silence allocation failure during sg_trim()
https://patchwork.freedesktop.org/api/1.0/series/17001/rev
As trimming the sg table is merely an optimisation that gracefully fails
if we cannot allocate a new table, we do not need to report the failure
either.
Fixes: 0c40ce130e38 ("drm/i915: Trim the object sg table")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem.c
Start exercising the scattergather lists, especially looking at
iteration after coalescing.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin nents == orig_st->orig_nents)
- return;
+ return false;
if (sg_alloc_table(&new_st, orig_st->nents, GFP_KERNEL))
-
== Series Details ==
Series: drm/i915: Prevent timeline updates whilst performing reset
URL : https://patchwork.freedesktop.org/series/16998/
State : success
== Summary ==
Series 16998v1 drm/i915: Prevent timeline updates whilst performing reset
https://patchwork.freedesktop.org/api/1.0/series
As the fence may be signaled concurrently from an interrupt on another
device, it is possible for the list of requests on the timeline to be
modified as we walk it. Take both (the context's timeline and the global
timeline) locks to prevent such modifications.
Fixes: 80b204bce8f2 ("drm/i915: Enabl
== Series Details ==
Series: series starting with [1/2] drm/i915: Fallback to single PAGE_SIZE
segments for DMA remapping
URL : https://patchwork.freedesktop.org/series/16996/
State : success
== Summary ==
Series 16996v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/se
On Mon, Dec 19, 2016 at 04:24:18PM +0200, Mika Kuoppala wrote:
> Chris Wilson writes:
>
> > On Fri, Dec 16, 2016 at 12:20:05PM -0800, Michel Thierry wrote:
> >> From: Arun Siluvery
> >>
> >> This change implements support for per-engine reset as an initial, less
> >> intrusive hang recovery opt
Chris Wilson writes:
> On Fri, Dec 16, 2016 at 12:20:05PM -0800, Michel Thierry wrote:
>> From: Arun Siluvery
>>
>> This change implements support for per-engine reset as an initial, less
>> intrusive hang recovery option to be attempted before falling back to the
>> legacy full GPU reset recov
== Series Details ==
Series: drm/i915: Introduce intel_cdclk_state
URL : https://patchwork.freedesktop.org/series/16994/
State : failure
== Summary ==
Series 16994v1 drm/i915: Introduce intel_cdclk_state
https://patchwork.freedesktop.org/api/1.0/series/16994/revisions/1/mbox/
Test gem_exec_su
Thanks for the review, Thierry. My comments inline.
Regards
Shashank
On 12/5/2016 10:29 PM, Thierry Reding wrote:
On Tue, Nov 29, 2016 at 08:24:39PM +0530, Shashank Sharma wrote:
HDMI 2.0 / CEA-861-F specs define a new CEA extension data block,
called hdmi-forum vendor specific data block (H
On 19/12/16 13:29, Chris Wilson wrote:
> On Mon, Dec 19, 2016 at 12:39:16PM +0100, Juergen Gross wrote:
>> With recent 4.10 kernel the graphics isn't coming up under Xen. First
>> failure message is:
>>
>> [ 46.656649] i915 :00:02.0: swiotlb buffer is full (sz: 1630208 bytes)
>
> Do we get a
W dniu 2016-12-16 o 16:42, Ander Conselvan de Oliveira pisze:
From: Michel Thierry
Commit 89b3c3c7ee9d ("drm/i915/glk: Reuse broxton's cdclk code for GLK")
missed a few of occurences of IS_BROXTON() that should have been
coverted to IS_GEN9_LP().
Fixes: 89b3c3c7ee9d ("drm/i915/glk: Reuse bro
== Series Details ==
Series: i915 regression in kernel 4.10 (rev2)
URL : https://patchwork.freedesktop.org/series/16990/
State : success
== Summary ==
Series 16990v2 i915 regression in kernel 4.10
https://patchwork.freedesktop.org/api/1.0/series/16990/revisions/2/mbox/
Test gem_sync:
On Wed, Dec 14, 2016 at 08:00:23PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> VLV apparently gets upset if the PPS for a pipe currently driving an
> external DP port gets used for VDD stuff on another eDP port. The DP
> port falls over and fails to retrain when this hap
On Fri, Dec 16, 2016 at 07:25:13PM +, Chris Wilson wrote:
> When we evict from the GTT to make room for an object, the hole we
> create is put onto the MRU stack inside the drm_mm range manager. On the
> next search pass, we can speed up a PIN_HIGH allocation by referencing
> that stack for the
== Series Details ==
Series: Introduce drmfs pseudo filesystem for drm subsystem (rev4)
URL : https://patchwork.freedesktop.org/series/16203/
State : warning
== Summary ==
Series 16203v4 Introduce drmfs pseudo filesystem for drm subsystem
https://patchwork.freedesktop.org/api/1.0/series/16203/
In commit 0c40ce130e38 ("drm/i915: Trim the object sg table"), we expect
to copy exactly orig_st->nents across and allocate the table thusly.
The copy loop should therefore end with the new_sg being NULL.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_gem.c | 1 +
If we at first do not succeed with attempting to remap our physical
pages using a coalesced scattergather list, try again with one
scattergather entry per page. This should help with swiotlb as it uses a
limited buffer size and only searches for contiguous chunks within its
buffer aligned up to the
From: Ville Syrjälä
Introduce intel_cdclk state which for now will track the cdclk
frequency, the vco frequency and the reference frequency (not sure we
want the last one, but I put it there anyway). We'll also make the
.get_cdclk() function fill out this state structure rather than
just returnin
From: Ville Syrjälä
ilk_max_pixel_rate() will now give the "correct" pixel rate for all
platforms, so let's kill rename it to intel_max_pixel_rate() and kill
off intel_mode_max_pixclk().
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 41 ++--
From: Ville Syrjälä
Clean up the dev vs. dev_priv straggles that are making things
look inconsistentt.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_cdclk.c | 23 +--
1 file changed, 9 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_cdc
From: Ville Syrjälä
With the cdclk state, all the .modeset_commit_cdclk() hooks are
now pointless wrappers. Get rid of the extra indirection and just
use set_cdclk function directly.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.h | 3 +-
drivers/gpu/drm/i915/intel_cdclk
From: Ville Syrjälä
Rather than passing all the different parameters (cdclk,vco so
far) sparately to the set_cdclk() functions, just pass the
entire cdclk state.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_cdclk.c | 79 +++---
1 file changed, 49
From: Ville Syrjälä
Move ilk_pipe_pixel_rate() next to its only caller
(intel_crtc_compute_pixel_rate()).
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 35 +++
drivers/gpu/drm/i915/intel_drv.h | 1 -
drivers/gpu/drm/i915/intel_pm.c
From: Ville Syrjälä
Move the vlv_program_pfi_credits() into vlv_set_cdclk() and
chv_set_cdclk() so that we can neuter vlv_modeset_commit_cdclk().
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_cdclk.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/
From: Ville Syrjälä
The hack to grab the pipe A power domain around VLV/CHV cdclk
programming has surely outlived its usefulness. We should be
hold sufficient power domains during any modeset, so let's just
nuke this hack.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_cdclk.c | 1
From: Ville Syrjälä
Let's try to shrink intel_display.c a bit by moving the cdclk/rawclk
stuff to a new file. It's all reasonably self contained so we don't
even have to add that many non-static symbols.
We'll also take the opportunity to shuffle around the functions a bit
to get things in a mor
From: Ville Syrjälä
The current dev_cdclk vs. cdclk vs. atomic_cdclk_freq is quite a mess.
So here I'm introducing the "actual" and "logical" naming for our
cdclk state. "actual" is what we'll bash into the hardware and "logical"
is what everyone should use for state computaion/checking and whatn
From: Ville Syrjälä
Rename the .get_display_clock_speed() hook to .get_cdclk().
.get_cdclk() is more specific (which clock) and it's much
shorter.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/intel_display.c| 93 +---
From: Ville Syrjälä
Rather than recomptuing the pipe pixel rate on demand everwhere, let's
just stick the precomputed value into the crtc state.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 31 ++-
drivers/gpu/drm/i915/intel_drv.h | 2
From: Ville Syrjälä
Rather than compute the vco inside bxt_set_cdclk() let's precompute it
outside and pass it in. A small step towards a fully precomputed cdclk
state.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_cdclk.c | 33 +++--
1 file changed, 1
From: Ville Syrjälä
Let's clean up the mess we have in the if ladder that assigns the
.get_cdclk() hooks. The grouping of the platforms by the function
results in a thing that's not really legible, so let's do it the
other way around and order the if ladder by platform and duplicate
whatever assi
From: Ville Syrjälä
This series moves the cdclk tracking to its own state structure.
The main benefit is that we can track both the cdclk and vco in
the same place, and for future platforms we'll need to track
other things as well, so this should make that easier.
I also took the opportunity to
On Mon, Dec 19, 2016 at 12:39:16PM +0100, Juergen Gross wrote:
> With recent 4.10 kernel the graphics isn't coming up under Xen. First
> failure message is:
>
> [ 46.656649] i915 :00:02.0: swiotlb buffer is full (sz: 1630208 bytes)
Do we get a silent failure? i915_gem_gtt_prepare_pages() is
Hi Maarten,
Thank you for the patch.
On Monday 19 Dec 2016 12:08:16 Maarten Lankhorst wrote:
> Op 13-12-16 om 18:10 schreef Daniel Vetter:
> > On Tue, Dec 13, 2016 at 03:13:54PM +0100, Maarten Lankhorst wrote:
> >> Op 09-12-16 om 09:25 schreef Daniel Vetter:
> >>> On Fri, Dec 09, 2016 at 12:42:19
On Mon, Dec 19, 2016 at 01:38:13PM +0200, Joonas Lahtinen wrote:
> On ma, 2016-12-19 at 10:13 +, Chris Wilson wrote:
> > The kref_put_mutex() returns with the mutex held after freeing the
> > object - so we must remember to drop it...
> >
> > Fixes: 69df05e11ab8 ("drm/i915: Simplify releasing
== Series Details ==
Series: series starting with [v2,1/2] drm/i915: Check num_pipes before
initializing audio component
URL : https://patchwork.freedesktop.org/series/16987/
State : warning
== Summary ==
Series 16987v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/ser
With recent 4.10 kernel the graphics isn't coming up under Xen. First
failure message is:
[ 46.656649] i915 :00:02.0: swiotlb buffer is full (sz: 1630208 bytes)
Later I see splats like:
[ 49.393583] general protection fault: [#1] SMP
[ 49.403800] Modules linked in: bridge stp llc
On ma, 2016-12-19 at 10:13 +, Chris Wilson wrote:
> The kref_put_mutex() returns with the mutex held after freeing the
> object - so we must remember to drop it...
>
> Fixes: 69df05e11ab8 ("drm/i915: Simplify releasing context reference")
> Signed-off-by: Chris Wilson
> Cc: Tvrtko Ursulin
R
== Series Details ==
Series: drm/i915: Drop mutex after successful kref_put_mutex()
URL : https://patchwork.freedesktop.org/series/16985/
State : warning
== Summary ==
Series 16985v1 drm/i915: Drop mutex after successful kref_put_mutex()
https://patchwork.freedesktop.org/api/1.0/series/16985/r
Op 13-12-16 om 18:10 schreef Daniel Vetter:
> On Tue, Dec 13, 2016 at 03:13:54PM +0100, Maarten Lankhorst wrote:
>> Op 09-12-16 om 09:25 schreef Daniel Vetter:
>>> On Fri, Dec 09, 2016 at 12:42:19AM +0200, Laurent Pinchart wrote:
Hi Daniel,
On Thursday 08 Dec 2016 16:41:04 Daniel Vet
== Series Details ==
Series: series starting with [v3,01/38] drm/i915: Use the MRU stack search
after evicting (rev5)
URL : https://patchwork.freedesktop.org/series/16934/
State : failure
== Summary ==
Series 16934v5 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series
From: Sourab Gupta
The drmfs filesystem will not be registered standalone during kernel init time,
instead it is intended to be initialized/registered during drm initialization.
This again is dependent on CONFIG_DRMFS being defined.
Signed-off-by: Sourab Gupta
Signed-off-by: Swati Dhingra
---
From: Sourab Gupta
The patch introduces a new pseudo filesystem type, named 'drmfs' which is
intended to house the files for the data generated by drm subsystem that
cannot be accommodated by any of the existing filesystems.
The filesystem is modelled on the lines of existing pseudo-filesystems s
From: Sourab Gupta
A driver specific directory is created inside drmfs root, and dentry of
this directory is saved for subsequent use by the driver (e.g. i915).
The driver can then create files/directories inside this root directory
directly.
In case of i915 driver, the top directory is created
From: Sourab Gupta
In the current scenario, the relay API fit well only with debugfs, due to
availability of parent dentry. Any other existing filesystem was not feasible
for
holding guc logs, due to incompatibility with relay. But this makes the guc_log
file unavailable on the production kerne
From: Swati Dhingra
Currently, we don't have a stable ABI which can be used for the purpose of
providing output debug/loggging/crc and other such data from DRM.
The ABI in current use (filesystems, ioctls, et al.) have their own
constraints and are intended to output a particular type of data.
Fe
On Mon, 19 Dec 2016, Joonas Lahtinen wrote:
> On ma, 2016-12-19 at 09:19 +, Tvrtko Ursulin wrote:
>> +++ b/drivers/gpu/drm/i915/i915_gem_fence_reg.c
>> @@ -631,9 +631,9 @@ i915_gem_swizzle_page(struct page *page)
>> vaddr = kmap(page);
>>
>> for (i = 0; i < PAGE_SIZE; i += 128) {
>
On Mon, Dec 19, 2016 at 10:40:41AM +0900, Inki Dae wrote:
>
>
> 2016년 08월 16일 01:02에 Daniel Vetter 이(가) 쓴 글:
> > On Mon, Aug 15, 2016 at 04:42:18PM +0100, Chris Wilson wrote:
> >> Rendering operations to the dma-buf are tracked implicitly via the
> >> reservation_object (dmabuf->resv). This is us
From: Elaine Wang
when num_pipes is zero, it indicates display doesn't exist, so there
is no need to initialize display hooks. And to avoid calling these
uninitialized display hooks, respect num_pipes at the beginning of
intel_modeset_init_hw and intel_init_clock_gating.
intel_init_pm() calls FB
From: Elaine Wang
when num_pipes is zero, it indicates there is no display and HDMI
audio doesn't exist.
v2: Move the check from caller to callee for consistency.
Cc: Chris Wilson
Cc: Joonas Lahtinen
Cc: Jani Nikula
Signed-off-by: Elaine Wang
---
drivers/gpu/drm/i915/intel_audio.c | 3 +++
The kref_put_mutex() returns with the mutex held after freeing the
object - so we must remember to drop it...
Fixes: 69df05e11ab8 ("drm/i915: Simplify releasing context reference")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drv.h | 7 ---
1 file changed, 4
On Mon, Dec 19, 2016 at 05:49:46PM +0800, Zhenyu Wang wrote:
> On 2016.12.18 15:37:21 +, Chris Wilson wrote:
> > A few users only take the struct_mutex in order to release a reference
> > to a context. We can expose a kref_put_mutex() wrapper in order to
> > simplify these users, and optimise t
Prime numbers are interesting for testing components that use multiplies
and divides, such as testing DRM's struct drm_mm alignment computations.
v2: Move to lib/, add selftest
v3: Fix initial constants (exclude 0/1 from being primes)
v4: More RCU markup to keep 0day/sparse happy
v5: Fix RCU unwin
On 2016.12.18 15:37:21 +, Chris Wilson wrote:
> A few users only take the struct_mutex in order to release a reference
> to a context. We can expose a kref_put_mutex() wrapper in order to
> simplify these users, and optimise taking of the mutex to the final
> unref.
>
> Signed-off-by: Chris Wi
On Sun, Dec 18, 2016 at 09:02:33PM -0800, Michel Thierry wrote:
>
>
> On 12/16/2016 12:45 PM, Chris Wilson wrote:
> >On Fri, Dec 16, 2016 at 12:20:05PM -0800, Michel Thierry wrote:
> >>From: Arun Siluvery
> >>
> >>This change implements support for per-engine reset as an initial, less
> >>intrus
>
> On Fri, 16 Dec 2016, Wang Elaine wrote:
> > From: Elaine Wang
> >
> > when num_pipes is zero, it indicates there is no display and HDMI
> > audio doesn't exist.
> >
> > Cc: Chris Wilson
> > Cc: Joonas Lahtinen
> > Signed-off-by: Elaine Wang
> > ---
> > drivers/gpu/drm/i915/i915_drv.c | 3
On ma, 2016-12-19 at 09:19 +, Tvrtko Ursulin wrote:
> +++ b/drivers/gpu/drm/i915/i915_gem_fence_reg.c
> @@ -631,9 +631,9 @@ i915_gem_swizzle_page(struct page *page)
> vaddr = kmap(page);
>
> for (i = 0; i < PAGE_SIZE; i += 128) {
> - memcpy(temp, &vaddr[i], 64);
> +
Op 19-12-16 om 10:22 schreef Daniel Vetter:
> On Mon, Dec 19, 2016 at 09:58:28AM +0100, Daniel Vetter wrote:
>> This gets rid of the last users of for_each_intel_connector(), remove
>> that too.
>>
>> The one exception is the loop in verify_encoder_state - that needs to
>> switch over to for_each_c
== Series Details ==
Series: drm/i915: More reasonable memcpy unroll in i915_gem_swizzle_page
URL : https://patchwork.freedesktop.org/series/16981/
State : warning
== Summary ==
Series 16981v1 drm/i915: More reasonable memcpy unroll in i915_gem_swizzle_page
https://patchwork.freedesktop.org/ap
On Fri, 16 Dec 2016, Wang Elaine wrote:
> From: Elaine Wang
>
> when num_pipes is zero, it indicates there is no display and HDMI
> audio doesn't exist.
>
> Cc: Chris Wilson
> Cc: Joonas Lahtinen
> Signed-off-by: Elaine Wang
> ---
> drivers/gpu/drm/i915/i915_drv.c | 3 ++-
> 1 file changed, 2
On Mon, Dec 19, 2016 at 09:58:28AM +0100, Daniel Vetter wrote:
> This gets rid of the last users of for_each_intel_connector(), remove
> that too.
>
> The one exception is the loop in verify_encoder_state - that needs to
> switch over to for_each_connector_in_state.
>
> v2: Maarten corrected me t
From: Tvrtko Ursulin
For some reason GCC 6.2.1 here unrolls the from and to stack memcpy
here in per-byte fashion and also by repeatedly loading offset
constants. It look horrible like this for example:
...
fdc: 48 b8 41 00 00 00 00movabs rax,0x8841
fe3:
These two patches shouldn't impact the platforms that have none-zero num_pipes.
The failed case happened to fi-snb-2520m which has none-zero num_pipes("Found
CougarPoint PCH" in
dmesg log). And compared dmesg with the one caught when test pass, I didn't
see extra error messages.
One difference
On Sun, Dec 18, 2016 at 01:36:27PM -0800, Rodrigo Vivi wrote:
> gen8 is used for both Broadwell and Cherryview but this
> function here is only Cherryview and all next atom LP platforms.
> So let's rename it to avoid confusion as suggested by Ville.
>
> Cc: Ville Syrjälä
> Signed-off-by: Rodrigo
On Sun, Dec 18, 2016 at 01:36:28PM -0800, Rodrigo Vivi wrote:
> Let's take usage of IS_LP to simplify the gem stolen
> initialization as suggest by Tvrtko.
>
> Also assume that all new LP platforms follows the chv+
> and others bdw+.
>
> Broxton and Geminilake were probably using the incorrect pa
== Series Details ==
Series: series starting with [1/6] drm/i915: Use drm_connector_list_iter in
debugfs (rev2)
URL : https://patchwork.freedesktop.org/series/16979/
State : warning
== Summary ==
Series 16979v2 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/16979
On Sun, Dec 18, 2016 at 01:36:26PM -0800, Rodrigo Vivi wrote:
> Valleyview/Baytrail (gen7_lp) and Cherryview/Braswell (gen8_lp)
> are both Atom platforms like Broxton/Apollolake and Geminilake.
>
> So let's expand this is_lp back to these platforms and
> create the IS_LP(dev_priv) so we can start
This gets rid of the last users of for_each_intel_connector(), remove
that too.
The one exception is the loop in verify_encoder_state - that needs to
switch over to for_each_connector_in_state.
v2: Maarten corrected me that in the state verifier we indeed must
only walk connectors in the atomic c
== Series Details ==
Series: series starting with [1/6] drm/i915: Use drm_connector_list_iter in
debugfs
URL : https://patchwork.freedesktop.org/series/16979/
State : success
== Summary ==
Series 16979v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/16979/revisi
On 16/12/2016 20:20, Michel Thierry wrote:
From: Arun Siluvery
Driver maintains count of how many times a given engine is reset, useful to
capture this in error state also. It gives an idea of how engine is coping
up with the workloads it is executing before this error state.
Cc: Chris Wilson
This gets rid of the last users of for_each_intel_connector(), remove
that too.
At first I wasn't sure whether the 2 loops in the modeset state
checker should instead only loop over the connectors in the atomic
commit. But we never add connectors to an atomic update if they don't
(or won't have) a
Drive-by fixup while looking at all the connector_list walkers -
holding connection_mutex does actually _not_ give you locking to look
at the legacy drm_connector->encoder->crtc pointer chain. That one is
solely owned by the atomic commit workers. Instead we must inspect the
atomic state.
Signed-o
1 - 100 of 106 matches
Mail list logo
