On Thu, 05 Mar 2015, Joe Perches wrote:
> Only commit log and patch additions are checked for
> typos and spelling errors currently. Add a check
> of the email subject line too.
>
> Suggested-by: Jani Nikula
> Signed-off-by: Joe Perches
Thanks Joe.
FWIW,
Tested-by: Jani Nikula
> ---
> scr
drmSLLookupNeighbors function is using update without
initializing it. Fixed it by calling SLLocate().
Signed-off-by: Praveen Paneri
---
xf86drmSL.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/xf86drmSL.c b/xf86drmSL.c
index 00ae9f9..ca54148 100644
--- a/xf86drmSL.c
+++ b/xf86drmSL.c
@@
This patch adds check for various malloc/calloc function if they
were able to allocate memory as requested or not. Return
appropriate error if the allocation fails.
Signed-off-by: Praveen Paneri
---
intel/intel_bufmgr_fake.c | 4
intel/intel_bufmgr_gem.c | 3 +++
intel/intel_decode.c
Return value of drmHashCreate() and drmGetEntry() functions
can be NULL. It should be validated before being used.
Signed-off-by: Praveen Paneri
---
xf86drm.c | 24 ++--
1 file changed, 18 insertions(+), 6 deletions(-)
diff --git a/xf86drm.c b/xf86drm.c
index 73e0665..60663d
Move the dereferencing below the check for valid ctx pointer.
Signed-off-by: Praveen Paneri
---
intel/intel_decode.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/intel/intel_decode.c b/intel/intel_decode.c
index 2667a7c..5a4fc4a 100644
--- a/intel/intel_decode.c
+++ b/i
We must have upper bound on what we are going to write into a fixed
size buffer.
Signed-off-by: Praveen Paneri
---
intel/intel_decode.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/intel/intel_decode.c b/intel/intel_decode.c
index 61239dd..2667a7c 100644
--- a/inte
Validate the return value of SLCreateEntry() before using it.
Signed-off-by: Praveen Paneri
---
xf86drmSL.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/xf86drmSL.c b/xf86drmSL.c
index acddb54..45f3906 100644
--- a/xf86drmSL.c
+++ b/xf86drmSL.c
@@ -139,6 +139,7 @@ void *drmSLCreate(void
Check on bo_fake before dereferencing the object in functions
evict_lru and evict_mru.
Signed-off-by: Praveen Paneri
---
intel/intel_bufmgr_fake.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/intel/intel_bufmgr_fake.c b/intel/intel_bufmgr_fake.c
index d63fc81.
recode can be negative or zero as well. Put the correct condition
on it before using it as array index.
Signed-off-by: Praveen Paneri
---
xf86drm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xf86drm.c b/xf86drm.c
index 60663d4..df56f9e 100644
--- a/xf86drm.c
+++ b/xf86dr
realloc will return NULL if failed to allocate the extra memory
requested. Return from function if it fails.
Signed-off-by: Praveen Paneri
---
intel/intel_bufmgr_gem.c | 37 -
1 file changed, 28 insertions(+), 9 deletions(-)
diff --git a/intel/intel_bufmgr_ge
This patch set fixes various issues reported by a static
analysis tool.
Praveen Paneri (9):
external/drm: Validate bo_fake before using.
external/drm: Validate output of realloc()
external/drm: Use snprintf instead of sprintf
external/drm: Validate pointer before using
external/drm: Vali
From: Akash Goel
On SKL the frequency is specified in units of 16.66 MHZ, barring the
RP_STATE_CAP(0x5998) register, which still reports frequency in units
of 50 MHZ. So an extra conversion is required in gen6_init_rps_frequencies
function for SKL, to store the frequency values as per the actual
From: Akash Goel
This patch series add the missing changes, required for proper
functioning of the Turbo feature on SKL. Most of the changes are
mainly due to the fact that on SKL, the frequency has to be programmed
in units of 16.66 MHZ and the time period value programmed in Up/Down
EI & thresh
From: Akash Goel
Prior to SKL, the time period programmed in Up/Down EI & Up/Down
threshold registers was in units of 1.28 micro seconds. But for
SKL, the units have changed (1.333 micro seconds).
Have generalized the implementation of gen6_set_rps_thresholds function,
by removing the hard coding
From: Akash Goel
Enable the RPS interrupts programming(enable/disable/reset) for GEN9,
as missing changes to enable the RPS support on GEN9 have been added.
Signed-off-by: Akash Goel
---
drivers/gpu/drm/i915/intel_pm.c | 17 +++--
1 file changed, 3 insertions(+), 14 deletions(-)
d
From: Akash Goel
Earlier Turbo interrupts were not being processed for SKL,
as something was amiss in turbo programming for SKL.
Now missing changes have been added, so enabling the Turbo
interrupt processing for SKL.
Signed-off-by: Akash Goel
---
drivers/gpu/drm/i915/i915_irq.c | 5 -
1 f
From: Akash Goel
On SKL, the frequency is programmed differently in RPNSWREQ (A008)
register (from bits 23 to 31, compared to bits 24 to 31). So updated
the gen6_set_rps function, as per this change.
Signed-off-by: Akash Goel
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 5
From: Akash Goel
For SKL, register definition for RPNSWREQ (A008), RPSTAT1(A01C)
have changed slightly. Also on SKL, frequency is specified in
units of 16.66 MHZ, compared to 50 MHZ for most of the earlier
platforms and the time values are expressed in units of 1.33 us,
compared to 1.28 us for ea
From: Akash Goel
Added support for SKL in the i915_frequency_info debugfs function
v2:
- corrected the handling of reqf (Damien)
- Reorderd the platform check for cagf (Ville)
Signed-off-by: Akash Goel
---
drivers/gpu/drm/i915/i915_debugfs.c | 25 +
1 file changed, 17
From: Akash Goel
On SKL, frequency is specified in units of 16.66 MHZ.
Updated the intel_gpu_freq() and intel_freq_opecode() functions
to do the conversion appropriately.
Signed-off-by: Akash Goel
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 8 ++--
1 file changed, 6 i
From: Akash Goel
Added support for SKL in the act_freq_mhz_show sysfs function
Signed-off-by: Akash Goel
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_sysfs.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_sysfs.c
b/drivers/gpu/drm
From: Akash Goel
RP Interrupt Up/Down Frequency Limits register (A014) definition
has changed for SKL. Updated the gen6_rps_limits function as per that
v2: Renamed the function to intel_rps_limits (Chris)
Signed-off-by: Akash Goel
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.
From: Akash Goel
On SKL, GT frequency is programmed in units of 16.66 MHZ units compared
to 50 MHZ for older platforms. Also the time value specified for Up/Down EI &
Up/Down thresholds are expressed in units of 1.33 us, compared to 1.28
us for older platforms. So updated the gen9_enable_rps func
I don't understand why we need a complex solution when there is already a
simple solution with patch.
What is the drawback of reserving page 0?
Before we going to that complex solution, could we just reserve page zero?
It is simple and straight forward.
Thanks
Zou Nanhai
> -Original Message-
Current ILK-style watermark code assumes the primary plane and cursor
plane are always enabled. This assumption, along with the combination
of two independent commits that got merged at the same time, results in
a NULL dereference. The offending commits are:
commit fd2d61341bf39d1054256c
The integer comparison macros give us better error output by including
the actual values that failed the comparison.
Signed-off-by: Matt Roper
---
lib/igt.cocci | 32
tests/drv_hangman.c | 26 +-
tests/drv_suspend.c | 2 +-
On Thu, Mar 05, 2015 at 04:27:59PM +0100, Daniel Vetter wrote:
> I recommended exposing the PIN_BIAS since that will work without full
> ppgtt too. And yeah for full ppgtt we could just use svm where userspace
> controls the address, but since that's still a bit out we might need a
> quick interim
On 05/03/2015 15:46, John Harrison wrote:
On 05/03/2015 15:27, Tomas Elf wrote:
On 19/02/2015 17:17, john.c.harri...@intel.com wrote:
From: John Harrison
The alloc_request() function does not actually return the newly
allocated
request. Instead, it must be pulled from
ring->outstanding_lazy_r
On 19/02/2015 17:17, john.c.harri...@intel.com wrote:
From: John Harrison
Updated *_ring_invalidate_all_caches(), i915_reset_gen7_sol_offsets() and
i915_emit_box() to take request structures instead of ring or ringbuf/context
pairs.
For: VIZ-5115
Signed-off-by: John Harrison
---
drivers/gpu
On 19/02/2015 17:17, john.c.harri...@intel.com wrote:
From: John Harrison
Updated mi_set_context() to take a request structure instead of a ring and
context pair.
For: VIZ-5115
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/i915_gem_context.c |9 -
1 file changed, 4 inse
On 19/02/2015 17:17, john.c.harri...@intel.com wrote:
From: John Harrison
Converted i915_gem_l3_remap() to take a request structure instead of a ring.
For: VIZ-5115
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/i915_drv.h |2 +-
drivers/gpu/drm/i915/i915_gem.c |
On 19/02/2015 17:17, john.c.harri...@intel.com wrote:
From: John Harrison
Now that everything above has been converted to use request structures, it is
possible to update the lower level move_to_active() functions to be request
based as well.
For: VIZ-5115
Signed-off-by: John Harrison
---
d
On 19/02/2015 17:17, john.c.harri...@intel.com wrote:
From: John Harrison
Now that all callers of i915_add_request() have a request pointer to hand, it is
possible to update the add request function to take a request pointer rather
than pulling it out of the OLR.
For: VIZ-5115
Signed-off-by: J
On 19/02/2015 17:17, john.c.harri...@intel.com wrote:
From: John Harrison
Updated the display page flip code to do explicit request creation and
submission rather than relying on the OLR and just hoping that the request
actually gets submitted at some random point.
The sequence is now to creat
From: Ville Syrjälä
Poke at the CBR1_VLV register during init_clock_gating to make sure the
PND deadline scheme is used.
The hardware has two modes of operation wrt. watermarks:
1) PND deadline mode:
- memory request deadline is calculated from actual FIFO level * DDL
- WM1 watermark values a
From: Ville Syrjälä
Here's an updated version of the series to redo the VLV/CHV watermark
code. The most important thing is that this makes the display stable
on BSW with the fancy new memory PM features enabled by the firmware.
Changes since v1:
* Drop the two plane maxfifo mode patch (Vijay)
*
From: Ville Syrjälä
Apparently we must yet halve the DDL drain latency from what we're
using currently. This little nugget is not in any spec, but came
down through the grapevine.
This makes the displays a bit more stable. Not quite fully stable but at
least they don't fall over immediately on d
From: Ville Syrjälä
Now that we have drm_planes for the cursor and primary we can move the
pixel_size handling into vlv_compute_drain_latency() and just pass the
appropriate plane to it.
v2: Check plane->state->fb instead of plane->fb
Reviewed-by: Jesse Barnes (v1)
Signed-off-by: Ville Syrjälä
From: Ville Syrjälä
CHV has a new knob in Punit to select between some memory power savings
modes PM2 and PM5. We can allow the deeper PM5 when maxfifo mode is
enabled, so let's do so in the hopes for moar power savings.
v2: Put the thing into a separate function to avoid churn later
v3: Don't b
From: Ville Syrjälä
Assuming the PND deadline mechanism works reasonably we should do
memory requests as early as possible so that PND has schedule the
requests more intelligently. Currently we're still calculating
the watermarks as if VLV/CHV are identical to g4x, which isn't
the case.
The curr
From: Ville Syrjälä
VLV/CHV have similar DSPARB registers as older platforms, just more of
them due to more planes. Add a bit of code to read out the current FIFO
split from the registers. Will be useful later when we improve the WM
calculations.
v2: Add display_mmio_offset to DSPARB
Reviewed-b
From: Ville Syrjälä
Move the DDL precision handling into vlv_compute_drain_latency() so the
callers don't have to duplicate the same code to deal with it.
Reviewed-by: Jesse Barnes
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 8 ++---
drivers/gpu/drm/i915/intel_pm.c | 7
From: Ville Syrjälä
The current drain lantency computation relies on hardcoded limits to
determine when the to use the low vs. high precision multiplier.
Rewrite the code to use a more straightforward approach.
Reviewed-by: Jesse Barnes
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/in
From: Ville Syrjälä
DDR DVFS introduces massive memory latencies which can't be handled by
the PND deadline stuff. Instead the watermarks will need to be
programmed to compensate for the latency and the deadlines will need to
be programmed to tight fixed values. That means DDR DVFS can only be
en
From: Vidya Srinivas
PFI credit programming is required when CD clock (related to data flow from
display pipeline to end display) is greater than CZ clock (related to data
flow from memory to display plane). This programming should be done when all
planes are OFF to avoid intermittent hangs while
From: Ville Syrjälä
Kill the silly DRAIN_LATENCY_PRECISION_* defines and just use the raw
number instead.
v2: Move the sprite 32/16 -> 16/8 preision multiplier
change to another patch (Jesse)
Reviewed-by: Jesse Barnes
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 4
From: Ville Syrjälä
Introduce struct vlv_wm_values to house VLV watermark/drain latency
values. We start by using it when computing the drain latency values.
Reviewed-by: Jesse Barnes
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.h | 9
drivers/gpu/drm/i915/intel_pm
On 19/02/2015 17:17, john.c.harri...@intel.com wrote:
From: John Harrison
The overlay update code path to do explicit request creation and submission
rather than relying on the OLR to do the right thing.
For: VIZ-5115
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/intel_overlay.c |
Based on light reading, patches 1, 5, 6, 7, 8, 10, and 11 are
Reviewed-by: Ian Romanick
I sent a comment on patch 9. I'll try to look at the others in the next
few days... assuming nobody beats me to it.
I'm also going to send some similar Mesa patches that I'll CC you on.
On 03/05/2015 08:20
On 19/02/2015 17:17, john.c.harri...@intel.com wrote:
From: John Harrison
Updated the two render_state_init() functions to take a request pointer instead
of a ring. This removes their reliance on the OLR.
v2: Rebased to newer tree.
For: VIZ-5115
Signed-off-by: John Harrison
---
drivers/gpu
On Thu, Mar 05, 2015 at 10:41:19AM -0800, Ian Romanick wrote:
> On 03/05/2015 08:20 AM, Damien Lespiau wrote:
> > Time to switch over all the IS_GENX() macros to the new device object.
> > Nothing more than a mechanical search & replace here.
>
> Hmm... why not just do the comparisons directly? T
On 03/05/2015 08:20 AM, Damien Lespiau wrote:
> Time to switch over all the IS_GENX() macros to the new device object.
> Nothing more than a mechanical search & replace here.
Hmm... why not just do the comparisons directly? The macros seem
superfluous.
> Signed-off-by: Damien Lespiau
> ---
> i
On 19/02/2015 17:17, john.c.harri...@intel.com wrote:
From: John Harrison
Now that everything above has been converted to use requests, it is possible to
update init_context() to take a request pointer instead of a ring/context pair.
For: VIZ-5115
Signed-off-by: John Harrison
---
drivers/gp
Update the hot plug function to handle the SST case. Instead of placing
the SST case within the long/short pulse block, it is now handled after
determining that MST mode is not in use. This way, the topology management
layer can handle any MST-related operations while SST operations are still
corre
On 19/02/2015 17:17, john.c.harri...@intel.com wrote:
From: John Harrison
In execlist mode, context initialisation is deferred until first use of the
given context. This is because execlist mode has many more contexts than legacy
mode and many are never actually used. Previously, the initialisa
On 19/02/2015 17:17, john.c.harri...@intel.com wrote:
From: John Harrison
Updated do_switch() to take a request pointer instead of a ring/context pair.
For: VIZ-5115
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/i915_gem_context.c | 17 +
1 file changed, 9 inserti
On 19/02/2015 17:17, john.c.harri...@intel.com wrote:
From: John Harrison
Now that the request is guaranteed to specify the context, it is possible to
update the context switch code to use requests rather than ring and context
pairs. This patch updates i915_switch_context() accordingly.
Also r
On 19/02/2015 17:17, john.c.harri...@intel.com wrote:
From: John Harrison
In execlist mode, the context object pointer is written in to the request
structure (and reference counted) at the point of request creation. In legacy
mode, this only happens inside i915_add_request().
This patch update
On 19/02/2015 17:17, john.c.harri...@intel.com wrote:
From: John Harrison
The final step in removing the OLR from i915_gem_init_hw() is to pass the newly
allocated request structure in to each step rather than passing a ring
structure. This patch updates both i915_ppgtt_init_ring() and
i915_gem
On Tue, Mar 03, 2015 at 01:27:17PM +0530, Arun R Murthy wrote:
>
> > From: Ville Syrjälä
> >
> > DDR DVFS introduces massive memory latencies which can't be handled by the
> > PND deadline stuff. Instead the watermarks will need to be programmed to
> > compensate for the latency and the deadlin
On Tue, Feb 10, 2015 at 03:28:26PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Assuming the PND deadline mechanism works reasonably we should do
> memory requests as early as possible so that PND has schedule the
> requests more intelligently. Currently we're still calcu
On 19/02/2015 17:17, john.c.harri...@intel.com wrote:
From: John Harrison
Now that a single per ring loop is being done for all the different
intialisation steps in i915_gem_init_hw(), it is possible to add proper request
management as well. The last remaining issue is that the context enable c
On Thu, 2015-03-05 at 14:06 +, Chris Wilson wrote:
>
> Probably unrelated. Look in dmesg
dmesg is pretty muddy right now as I still have drm.debug=6 set.
> and /sys/class/drm/card0/error
http://brian.interlinx.bc.ca/intel.debug.gz
as it is currently. Or is it more useful if it's collected
On 19/02/2015 17:17, john.c.harri...@intel.com wrote:
From: John Harrison
The start of day context initialisation code in i915_gem_context_enable() loops
over each ring and calls the legacy switch context or the execlist init context
code as appropriate.
This patch moves the ring looping out o
Only commit log and patch additions are checked for
typos and spelling errors currently. Add a check
of the email subject line too.
Suggested-by: Jani Nikula
Signed-off-by: Joe Perches
---
scripts/checkpatch.pl | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/scripts/check
On 19/02/2015 17:17, john.c.harri...@intel.com wrote:
From: John Harrison
The i915_gem_init_hw() function calls a bunch of smaller initialisation
functions. Multiple of which have generic sections and per ring sections. This
means multiple passes are done over the rings. Each pass writes data t
On 19/02/2015 17:17, john.c.harri...@intel.com wrote:
From: John Harrison
Added explicit request creation and submission to the GPU idle code path.
For: VIZ-5115
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/i915_gem.c | 18 +-
1 file changed, 17 insertions(+), 1
On 19/02/2015 17:17, john.c.harri...@intel.com wrote:
From: John Harrison
The plan is to pass requests around as the basic submission tracking structure
rather than rings and contexts. This patch updates the i915_gem_object_sync()
code path.
For: VIZ-5115
Signed-off-by: John Harrison
---
dr
On 19/02/2015 17:17, john.c.harri...@intel.com wrote:
From: John Harrison
Added explicit creation creation and submission of the request structure to the
Nitpick: "creation creation"
display object pinning code. This removes any reliance on the OLR keeping track
of the request and the unkno
On Thu, Mar 05, 2015 at 03:01:21PM +, Tomas Elf wrote:
> On 19/02/2015 17:17, john.c.harri...@intel.com wrote:
> >From: John Harrison
> >
> >In order to explicitly manage requests from creation to submission, it is
> >necessary to be able to explicitly create them in the first place. This patc
If, for some reason, we couldn't create the decode context, exit,
instead of segfaulting.
Signed-off-by: Damien Lespiau
---
intel/test_decode.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/intel/test_decode.c b/intel/test_decode.c
index 93f47ef..1ffd829 100644
--- a/intel/test_decode
On 19/02/2015 17:17, john.c.harri...@intel.com wrote:
From: John Harrison
Added explicit creation creation and submission of the request structure to the
display object pinning code. This removes any reliance on the OLR keeping track
of the request and the unknown randomness that can ensue with
Signed-off-by: Damien Lespiau
---
intel/intel_decode.c | 31 ---
1 file changed, 12 insertions(+), 19 deletions(-)
diff --git a/intel/intel_decode.c b/intel/intel_decode.c
index 7d5cbe5..9ada2fa 100644
--- a/intel/intel_decode.c
+++ b/intel/intel_decode.c
@@ -35,6 +35
Finally, we can remove this file now that everything is using
drm_intel_device.
Signed-off-by: Damien Lespiau
---
intel/Makefile.sources | 1 -
intel/intel_bufmgr_gem.c | 1 -
intel/intel_chipset.h| 184 ---
intel/intel_decode.c | 1 -
One more step towards getting rid of intel_chipset.h. The slightly
tricky bit here is that I don't want to leave defines like IS_CHIP() or
IS_GEN4() is a file that can potentially become a public header.
intel_device_priv.h was introduced then.
Signed-off-by: Damien Lespiau
---
intel/Makefile.so
The intention here is to:
- have a single object that represents a device
- reuse the kernel i915_pciids.h file so we only one place to update
and copy the file over.
- hide the various information about an intel device in that object
instead of having endless #define in intel_chip
A couple of things I wanted to do for the longest time:
- Have (intel's) libdrm use the kernel i915_pciids.h so we can just copy the
file when updating
- Start a new object, struct drm_intel_device where we could put common code
across several userspace projects. For instance it coul
IS_9XX() has grown to mean gen >= 3. It was only used in a single test:
(IS_9XX && !IS_GEN3)
Which has then be replaced with gen >= 4.
The code in that area was idented a bit weirdly, so do a pass on that as
well.
Signed-off-by: Damien Lespiau
---
intel/intel_chipset.h | 9 -
intel
Signed-off-by: Damien Lespiau
---
intel/intel_bufmgr_gem.c | 58 +++-
1 file changed, 8 insertions(+), 50 deletions(-)
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index 33d8fbc..72a6ab1 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/i
While the bitwise operator should do the right thing here, it's probably
better to use the logical or here, at least to not cause a 'wtf' when
reading the code.
At the same time, get rid of unnecessary '()'.
Signed-off-by: Damien Lespiau
---
intel/intel_bufmgr_gem.c | 4 ++--
1 file changed, 2
We were pulling a few PCI ids, we can just hardcode them, it doesn't
change much.
Signed-off-by: Damien Lespiau
---
intel/test_decode.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/intel/test_decode.c b/intel/test_decode.c
index 1ffd829..b9897b3 100644
--- a/intel/t
Turns out nobody was using it, nor the underlying defines.
Signed-off-by: Damien Lespiau
---
intel/intel_chipset.h | 15 ---
1 file changed, 15 deletions(-)
diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h
index a8a2b0e..241d700 100644
--- a/intel/intel_chipset.h
+++ b/int
Signed-off-by: Damien Lespiau
---
intel/intel_chipset.h | 10 --
1 file changed, 10 deletions(-)
diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h
index e22a867..9a8df6a 100644
--- a/intel/intel_chipset.h
+++ b/intel/intel_chipset.h
@@ -181,16 +181,6 @@
#define PCI_CHIP_SKYLAKE
Time to switch over all the IS_GENX() macros to the new device object.
Nothing more than a mechanical search & replace here.
Signed-off-by: Damien Lespiau
---
intel/intel_bufmgr_gem.c | 7 +-
intel/intel_chipset.h | 158 --
intel/intel_decode.c
On Thu, Mar 05, 2015 at 03:06:42PM +, John Harrison wrote:
> On 05/03/2015 14:44, Daniel Vetter wrote:
> >Imo reserving a bit of ring space for each add_request should be solid.
> >Userspace uses the exact same reservation logic for adding end-of-batch
> >workarounds. The only thing needed to m
On 19/02/2015 17:17, john.c.harri...@intel.com wrote:
From: John Harrison
The plan is to pass requests around as the basic submission tracking structure
rather than rings and contexts. This patch updates the
execbuffer_move_to_active() code path.
For: VIZ-5115
Signed-off-by: John Harrison
---
From: Deepak S
In normal cases, RC6 promotion timer is 1700us/500us. This will
result in more time spent in C1 state. For more residency in
C6 in case of media workloads, this is changed to 250us.
Not doing this for 3D workloads as too many C6-C0
transition delays can result in performance impact
On Thu, Mar 05, 2015 at 04:52:56PM +0100, Daniel Vetter wrote:
> On Mon, Feb 16, 2015 at 01:21:34PM +0200, Ville Syrjälä wrote:
> > On Mon, Feb 16, 2015 at 03:07:59PM +0530, Vijay Purushothaman wrote:
> > > As per the recommendation from PHY team, limit the max vco supported in
> > > CHV to 6.48 G
On Thu, Mar 05, 2015 at 04:29:30PM +0100, Daniel Vetter wrote:
> On Thu, Mar 05, 2015 at 03:08:17PM +0200, Ville Syrjälä wrote:
> > On Thu, Mar 05, 2015 at 01:56:53PM +0100, Daniel Vetter wrote:
> > > On Thu, Mar 05, 2015 at 02:51:28PM +0530, Sonika Jindal wrote:
> > > > @@ -1519,16 +1550,7 @@ inte
On 19/02/2015 17:17, john.c.harri...@intel.com wrote:
From: John Harrison
The plan is to pass requests around as the basic submission tracking structure
rather than rings and contexts. This patch updates the move_to_gpu() code paths.
For: VIZ-5115
Signed-off-by: John Harrison
---
drivers/gp
On Mon, Feb 16, 2015 at 01:21:34PM +0200, Ville Syrjälä wrote:
> On Mon, Feb 16, 2015 at 03:07:59PM +0530, Vijay Purushothaman wrote:
> > As per the recommendation from PHY team, limit the max vco supported in CHV
> > to 6.48 GHz
> >
> > Signed-off-by: Vijay Purushothaman
> > ---
> > drivers/gp
On 05/03/2015 15:27, Tomas Elf wrote:
On 19/02/2015 17:17, john.c.harri...@intel.com wrote:
From: John Harrison
The alloc_request() function does not actually return the newly
allocated
request. Instead, it must be pulled from
ring->outstanding_lazy_request. This
patch fixes this so that cod
On 19/02/2015 17:17, john.c.harri...@intel.com wrote:
From: John Harrison
Updated a couple of trace points to use the now cached request pointer rather
than extracting it from the ring.
For: VIZ-5115
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c |2 +-
dri
On 19/02/2015 17:17, john.c.harri...@intel.com wrote:
From: John Harrison
Rather than just having a local request variable in the execbuff code, the
request pointer is now stored in the execbuff params structure. Also added
explicit cleanup of the request (plus wiping the OLR to match) in the e
On 05/03/2015 15:22, Daniel Vetter wrote:
On Thu, Mar 05, 2015 at 02:03:03PM +, john.c.harri...@intel.com wrote:
From: John Harrison
Apparently, this has never worked reliably and is currently disabled. Also, the
gains are not particularly impressive. Thus rather than try to keep unused co
On Thu, Mar 05, 2015 at 10:03:08PM +0800, kbuild test robot wrote:
> drivers/gpu/drm/i915/intel_ringbuffer.c:435:1-4: WARNING: end returns can be
> simpified
>
> Simplify a trivial if-return sequence. Possibly combine with a
> preceding function call.
> Generated by: scripts/coccinelle/misc/si
On Thu, Mar 05, 2015 at 03:08:17PM +0200, Ville Syrjälä wrote:
> On Thu, Mar 05, 2015 at 01:56:53PM +0100, Daniel Vetter wrote:
> > On Thu, Mar 05, 2015 at 02:51:28PM +0530, Sonika Jindal wrote:
> > > @@ -1519,16 +1550,7 @@ intel_plane_init(struct drm_device *dev, enum pipe
> > > pipe, int plane)
On 19/02/2015 17:17, john.c.harri...@intel.com wrote:
From: John Harrison
The alloc_request() function does not actually return the newly allocated
request. Instead, it must be pulled from ring->outstanding_lazy_request. This
patch fixes this so that code can create a request and start using it
On Thu, Mar 05, 2015 at 01:01:21PM +, Chris Wilson wrote:
> On Thu, Mar 05, 2015 at 01:52:51PM +0100, Daniel Vetter wrote:
> > On Thu, Mar 05, 2015 at 02:56:52AM +, Song, Ruiling wrote:
> > > Hi Daniel,
> > >
> > > OpenCL language support NULL pointer, using zero as the NULL pointer is
> >
On Thu, Mar 05, 2015 at 02:03:03PM +, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> Apparently, this has never worked reliably and is currently disabled. Also,
> the
> gains are not particularly impressive. Thus rather than try to keep unused
> code
> from decaying and having t
1 - 100 of 173 matches
Mail list logo
