On Tue, Feb 4, 2014 at 8:37 PM, Daniel Vetter wrote:
> On Tue, Feb 4, 2014 at 8:00 PM, Daniel Vetter wrote:
>> Moved to a common location so that Jani also can push to it, to avoid
>> moving it every time I go on vacation. Please update autobuilders and
>> everything else pointing at the drm-inte
* Daniel Vetter wrote:
> On Tue, Feb 04, 2014 at 02:47:07PM +0200, Ville Syrjälä wrote:
> > Hi x86 folks,
> >
> > Ping on getting the gen2 stolen memory early quirk patches into
> > the x86 tree.
> >
> > From our side Daniel and Chris both seemed happy with them, so I'd
> > like to get them
On Tue, Feb 04, 2014 at 11:33:31AM -0800, Daniel Vetter wrote:
> On Tue, Feb 04, 2014 at 10:45:45AM -0800, Volkin, Bradley D wrote:
> > The current table structure is that we have tables per-ring and per-gen
> > (plus the table
> > for common MI commands) and all tables are treated as blacklist/gr
On Tue, Feb 04, 2014 at 08:20:31PM +0200, Ville Syrjälä wrote:
> On Tue, Feb 04, 2014 at 02:22:24PM +0200, Antti Koskipaa wrote:
> > RFCv2: Reorganize array indexing so that full offsets can be used as
> > is. It makes grepping for registers in i915_reg.h much easier. Also
> > move offset arrays to
>
> >> And I have a question: how to assure the audio/gfx client find its
right peer?
> >> On a x86 platform, there can be an integrated GPU and an discrete GPU.
So there can be two audio controllers and two GPUs.
> >> We need to assure audio controller find the proper GPU, and vice
versa. Maybe we
Hi,
What is the current status for DP MST support on Haswell? Are there
experimental patches that can be tested? If not, what can be done to
help progress?
Supposing the kernel parts are figured, will userland need updates
accordingly, or would the existing multi-head support work as-is?
Cheers,
None of these files are actually using any __init type directives
and hence don't need to include . Most are just a
left over from __devinit and __cpuinit removal, or simply due to
code getting copied from one driver to the next.
Cc: David Airlie
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: dri-de...
On 01/21/2014 12:24 PM, Thierry Reding wrote:
> Add support for eDP functionality found on Tegra124 and later SoCs. Only
> fast link training is currently supported.
>
> Signed-off-by: Thierry Reding
> ---
> .../bindings/gpu/nvidia,tegra20-host1x.txt | 42 +
This part should go to the
On Thu, Jan 30, 2014 at 02:03:18PM -0500, Josh Boyer wrote:
> Hi All,
>
> I'm seeing the oops below on my MacBookPro 10,2 machine using i915
> graphics. It's after the DRM merge for 3.14 ( v3.13-10094-g9b0cd30) ,
> but we seem to have one report[1] of this happening well before that,
> in v3.13-3
Hi,
I am installing a DELL Inspiron 7737 with an Intel HD 4400.
PCI Device (8086:0a16). So it should be a HD 4400.
The Operating System is SLES 11 SP1.
I tried to install the sources, but the are so many dependencies.
From the one package to the next package an so on.
Do you have
On Wed, Jan 22, 2014 at 8:42 PM, Yijing Wang wrote:
> Since acpi_evaluate_object() returns acpi_status and not plain int,
> ACPI_FAILURE() should be used for checking its return value. Also
> add some detailed debug info when acpi_evaluate_object() failed.
>
> Reviewed-by: Jani Nikula
> Acked-by:
On Mon, Jan 20, 2014 at 7:46 PM, Yijing Wang wrote:
> Since acpi_evaluate_object() returns acpi_status and not plain int,
> ACPI_FAILURE() should be used for checking its return value.
>
> Reviewed-by: Jani Nikula
> Signed-off-by: Yijing Wang
> ---
> v3->v4: Fix spell error, add Jani Nikula revi
On Fri, Jan 24, 2014 at 8:36 AM, Rafael J. Wysocki wrote:
> On Friday, January 24, 2014 07:54:29 AM Bjorn Helgaas wrote:
>> On Thu, Jan 23, 2014 at 5:33 PM, Rafael J. Wysocki
>> wrote:
>> > On Thursday, January 23, 2014 11:21:01 AM Bjorn Helgaas wrote:
>> >> On Wed, Jan 22, 2014 at 8:42 PM, Yiji
On Thu, Jan 23, 2014 at 5:33 PM, Rafael J. Wysocki wrote:
> On Thursday, January 23, 2014 11:21:01 AM Bjorn Helgaas wrote:
>> On Wed, Jan 22, 2014 at 8:42 PM, Yijing Wang wrote:
>> > Since acpi_evaluate_object() returns acpi_status and not plain int,
>> > ACPI_FAILURE() should be used for checkin
On Wed, Feb 05, 2014 at 12:04:46AM +0200, Imre Deak wrote:
> On Tue, 2014-02-04 at 21:29 +, Chris Wilson wrote:
> > On Tue, Feb 04, 2014 at 09:15:14PM +0200, Imre Deak wrote:
> > > It's not signal safe and I got kms_flip in hung state with the backtrace
> > > below, while the parent process wai
Hi Daniel,
On Tue, 4 Feb 2014 20:15:03 +0100 Daniel Vetter wrote:
>
> On Tue, Feb 4, 2014 at 8:00 PM, Daniel Vetter wrote:
> > Moved to a common location so that Jani also can push to it, to avoid
> > moving it every time I go on vacation. Please update autobuilders and
> > everything else point
On Tue, 2014-02-04 at 21:29 +, Chris Wilson wrote:
> On Tue, Feb 04, 2014 at 09:15:14PM +0200, Imre Deak wrote:
> > It's not signal safe and I got kms_flip in hung state with the backtrace
> > below, while the parent process waiting for the signal helper to exit.
> > It was quite easy to reprod
On Tue, Feb 04, 2014 at 09:15:14PM +0200, Imre Deak wrote:
> It's not signal safe and I got kms_flip in hung state with the backtrace
> below, while the parent process waiting for the signal helper to exit.
> It was quite easy to reproduce the bug by running
>
> kms_flip --run-subtest=flip-vs-dpms
On Tue, Feb 04, 2014 at 09:59:15PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> On SNB we set up WaSetupGtModeTdRowDispatch:snb early in
> gen6_init_clock_gating(). That sets a bit in the GEN6_GT_MODE register.
> However later we go and disable all the bits in the same re
On Tue, Feb 04, 2014 at 08:37:02PM +0100, Thomas Meyer wrote:
>
> Hi,
>
> I see a *lot* of these warning in 3.13.1.
> 3.12.x never showed this problem.
> Any ideas?!
Can you please try latest the drm-intel-nightly git branch from
git://anongit.freedesktop.org/drm-intel ?
If that one's still aff
On Fri, Jan 31, 2014 at 01:48:39PM +, Chris Wilson wrote:
> On Fri, Jan 31, 2014 at 03:49:08PM +0200, Jani Nikula wrote:
> > The WARN_ONCE is a bit too verbose, make it a DRM_INFO_ONCE.
> >
> > While at it, add a #define for MAX_DSLP and make the message a bit more
> > informative.
> >
> > v2
Hi,
I see a *lot* of these warning in 3.13.1.
3.12.x never showed this problem.
Any ideas?!
[ 9373.175179] WARNING: CPU: 0 PID: 7715 at
drivers/gpu/drm/i915/i915_irq.c:1240 i965_irq_handler+0x4ee/0x670()
[ 9373.175181] Received HPD interrupt although disabled
[ 9373.175183] Modules linked in: t
From: Ville Syrjälä
Based on the name, the workaround we implement is
WaStripsFansDisableFastClipPerformanceFix. Unfortunately there's no
description in the w/a database, so this is just a guess.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 1 +
1 file changed, 1 insertio
From: Ville Syrjälä
According to Bspec we need to disable SF pipelined attribute fetch
whenever SF outputs exceed 16 and normal clip mode is used. A quick
glance at Mesa suggests that these conditions could happen. So let's
just always set the magic bit.
Signed-off-by: Ville Syrjälä
---
driver
From: Ville Syrjälä
The need to set all of the mask bits for 3D_CHICKEN3 was required
only for pre-production hardware.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/dr
From: Ville Syrjälä
BSpec recommends using 8x4 hashing mode when MSAA is used. But in
practice 16x4 seems to have a slight edge in performance (on IVB and
HSW at least). So just use 16x4.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 7 +++
1 file changed, 7 insertions
From: Ville Syrjälä
BSpec recommends using 8x4 hashing mode when MSAA is used. But in
practice 16x4 seems to have a slight edge in performance (on IVB and
HSW at least). So just use 16x4.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 7 +++
1 file changed, 7 insertions
From: Ville Syrjälä
On SNB we set up WaSetupGtModeTdRowDispatch:snb early in
gen6_init_clock_gating(). That sets a bit in the GEN6_GT_MODE register.
However later we go and disable all the bits in the same register. And
then we go on to set some other bit. So apparently we never actually
implemen
From: Ville Syrjälä
BSpec recommends using 8x4 hashing mode when MSAA is used. But in
practice 16x4 seems to have a slight edge in performance (on IVB and
HSW at least). So just use 16x4.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_pm.c |
From: Ville Syrjälä
So I accidentally looked at gen6_init_clock_gating() and noticed a few
weird things that should have gotten cleaned up years ago. So I did that.
While doing that I also noticed the WIZ hashing bits, and the fact that
we weren't following the BSpec recommendation. After doing
Bspec and the code suggests that the interrupt signaled by IIR[7,5]
(DISPLAY_PIPE_A/B_VBLANK) is a first level IRQ flag for the second
level PIPEA/BSTAT[2] (Start of Vertical Blank) interrupt. Measuring
the relative timings of when IIR[7] and PIPEASTAT[1,2] get set and
checking the effect of unmask
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/i915_irq.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index b5524ea..e0e5190 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i9
On Tue, Feb 04, 2014 at 10:45:45AM -0800, Volkin, Bradley D wrote:
> The current table structure is that we have tables per-ring and per-gen (plus
> the table
> for common MI commands) and all tables are treated as blacklist/greylist. The
> proposed
> flow here would indicate that we need tables
Atm we call the handlers for pending pipestat interrupt events even if
they aren't explicitly enabled by i915_enable_pipestat(). This isn't an
issue for events other than the vblank start event, since those are
always enabled anyways. Otoh, we enable the vblank start event
on-demand, so we'll end u
On Tue, Feb 4, 2014 at 8:00 PM, Daniel Vetter wrote:
> Moved to a common location so that Jani also can push to it, to avoid
> moving it every time I go on vacation. Please update autobuilders and
> everything else pointing at the drm-intel.git repo, the old one won't
> be updated any more.
>
> Cc
There isn't any PSR interrupt enable bit for pipe A, so we couldn't
enable it through the current API. Passing the corresponding status bits
solves this and also makes the mapping between enable and status bits
simpler on VLV (addressed in an upcoming patch).
Except of checking for invalid status
Atm on VLV we handle any pending pipestat interruts, whether or not
these were actually enabled explicitly with i915_enable_pipestat(). This
may or may not cause any real problem, but for consistency it's worth
fixing. See the last patch for more details.
I also need this as a dependency for the V
At least on VLV we can't get at the pipestat status bits by simply right
shifting the corresponding enable bits. The mapping between enable and
status bits for the sprite0,1 flip done and the PSR events don't follow
this rule, so we need to map them separately.
The PSR enable for pipe A is DPFLIPS
This will be used by other platforms too, so factor it out.
The only functional change is the reordeing of gmbus_irq_handler() wrt.
the hotplug handling, but since it only schedules a work, it isn't an
issue.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/i915_irq.c | 76
s/FLIPDONE/FLIP_DONE/ to make all FLIP_DONE macro names consistent.
No functional change.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/i915_irq.c | 2 +-
drivers/gpu/drm/i915/i915_reg.h | 18 +-
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/d
On Tue, Feb 4, 2014 at 8:00 PM, Daniel Vetter wrote:
> Moved to a common location so that Jani also can push to it, to avoid
> moving it every time I go on vacation. Please update autobuilders and
> everything else pointing at the drm-intel.git repo, the old one won't
> be updated any more.
>
> Cc
It's not signal safe and I got kms_flip in hung state with the backtrace
below, while the parent process waiting for the signal helper to exit.
It was quite easy to reproduce the bug by running
kms_flip --run-subtest=flip-vs-dpms-off-vs-modeset
With the change I couldn't reproduce it.
0 0x7
Moved to a common location so that Jani also can push to it, to avoid
moving it every time I go on vacation. Please update autobuilders and
everything else pointing at the drm-intel.git repo, the old one won't
be updated any more.
Cc: Dave Airlie
Cc: Jani Nikula
Signed-off-by: Daniel Vetter
---
On Tue, Feb 04, 2014 at 02:20:36AM -0800, Daniel Vetter wrote:
> On Mon, Feb 03, 2014 at 03:00:19PM -0800, Volkin, Bradley D wrote:
> > Ping. Daniel or Chris, can one of you clarify this request? Thanks.
>
> I've been enjoying fosdem ...
>
> > On Thu, Jan 30, 2014 at 10:05:27AM -0800, Volkin, Bra
On Tue, Feb 04, 2014 at 02:22:24PM +0200, Antti Koskipaa wrote:
> RFCv2: Reorganize array indexing so that full offsets can be used as
> is. It makes grepping for registers in i915_reg.h much easier. Also
> move offset arrays to intel_device_info.
>
> v1: Fixed offsets for VLV, proper eDP handling
From: Jeff McGee
sysfs changes to rps min and max delay were only triggering an update
of the rps interrupt limits if the active delay required an update.
This change ensures that interrupt limits are always updated.
v2: correct compile issue missed on rebase
v3: add igt testcases to signed-off-
From: Jeff McGee
A check of rps/rc6 state after i915_reset determined that the ring
MAX_IDLE registers were returned to their hardware defaults and that
the GEN6_PMIMR register was set to mask all interrupts. This change
restores those values to their pre-reset states by re-initializing
rps/rc6 i
On Tue, 2014-02-04 at 17:13 +0100, Daniel Vetter wrote:
> On Fri, Jan 24, 2014 at 10:15 AM, Imre Deak wrote:
> > Atm we try to remove the connector's i2c sysfs entry too late in the
> > encoder's destroy callback. By that time the kobject used as the parent
> > for all connector sysfs entries is a
On Fri, Jan 24, 2014 at 10:15 AM, Imre Deak wrote:
> Atm we try to remove the connector's i2c sysfs entry too late in the
> encoder's destroy callback. By that time the kobject used as the parent
> for all connector sysfs entries is already removed when we do an early
> removal of all connector sy
On Tue, Feb 04, 2014 at 02:14:31PM +, Chris Wilson wrote:
> Exercise that calling madvise produces expected results
>
> Signed-off-by: Chris Wilson
Thanks a lot for the testcase and patches, all pulled in.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 -
On Tue, Feb 04, 2014 at 11:40:20AM +, Chris Wilson wrote:
> On Tue, Feb 04, 2014 at 12:31:37PM +0100, Daniel Vetter wrote:
> > On Fri, Jan 31, 2014 at 03:42:48PM -0600, jeff.mc...@intel.com wrote:
> > > From: Jeff McGee
> > >
> > > RPS manual mode disables/ignores load-based inputs and allows
On Tue, Feb 04, 2014 at 02:47:07PM +0200, Ville Syrjälä wrote:
> Hi x86 folks,
>
> Ping on getting the gen2 stolen memory early quirk patches into the x86
> tree.
>
> From our side Daniel and Chris both seemed happy with them, so I'd like
> to get them in at some point.
Yup, I think this is read
Exercise that calling madvise produces expected results
Signed-off-by: Chris Wilson
---
tests/.gitignore | 1 +
tests/Makefile.sources | 1 +
tests/gem_madvise.c| 155 +
3 files changed, 157 insertions(+)
create mode 100644 tests/gem
On Mon, Feb 03, 2014 at 10:59:42AM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> A set of userptr test cases to support the new feature.
>
> For the eviction and swapping stress testing I have extracted
> some common behaviour from gem_evict_everything and made both
> test cases use it
On Tue, Feb 04, 2014 at 11:36:39AM +, Chris Wilson wrote:
> On Tue, Feb 04, 2014 at 12:05:13PM +0100, Daniel Vetter wrote:
> > On Fri, Jan 31, 2014 at 11:34:58AM +, Chris Wilson wrote:
> > > Since a purged buffer is one without any associated pages, attempting to
> > > use it should generat
On Tue, Feb 04, 2014 at 11:03:25AM -0200, Rodrigo Vivi wrote:
> >> > In the case of a moving cursor that means indefinitely.
> >> That's true... So I think we really need a work queue delaying the enable.
> >> Or do you have any better idea?
> >
> > Yeah, sounds like we need a delayed work-queue to
On Tue, Feb 04, 2014 at 03:12:49PM +0100, Daniel Vetter wrote:
> On Tue, Feb 04, 2014 at 01:30:19PM +, Chris Wilson wrote:
> > Inserting additional PTEs has no side-effect for us as the pfn are fixed
> > for the entire time the object is resident in the global GTT. The
> > downside is that we p
This test demonstrates the performance cliff clients face when they
unwittingly use too many fenced surfaces in a looped upload.
Signed-off-by: Chris Wilson
---
Note that pass/fail here is based on arbitrary value, and passing the test
is a wishlist item. Is it worthwhile pushing as is, or should
On Tue, Feb 04, 2014 at 03:40:44PM +0200, Jani Nikula wrote:
> intel_dp_aux_native_read_retry() is only needed when the sink might be
> asleep. Use the regular read without retries otherwise.
I guess I should repeat here what I mentioned to Jani:
The DP spec seems to indicate that AUX transaction
On Tue, Feb 04, 2014 at 03:15:26PM +0100, Daniel Vetter wrote:
> On Tue, Feb 04, 2014 at 03:12:49PM +0100, Daniel Vetter wrote:
> > On Tue, Feb 04, 2014 at 01:30:19PM +, Chris Wilson wrote:
> > > Inserting additional PTEs has no side-effect for us as the pfn are fixed
> > > for the entire time
On Tue, Feb 04, 2014 at 01:30:19PM +, Chris Wilson wrote:
> Inserting additional PTEs has no side-effect for us as the pfn are fixed
> for the entire time the object is resident in the global GTT. The
> downside is that we pay the entire cost of faulting the object upon the
> first hit, for whi
Inserting additional PTEs has no side-effect for us as the pfn are fixed
for the entire time the object is resident in the global GTT. The
downside is that we pay the entire cost of faulting the object upon the
first hit, for which we in return receive the benefit of removing the
per-page faulting
>> > In the case of a moving cursor that means indefinitely.
>> That's true... So I think we really need a work queue delaying the enable.
>> Or do you have any better idea?
>
> Yeah, sounds like we need a delayed work-queue to re-enable psr, also for
> gtt mmap writes. See Chris' latest crazy exam
intel_dp_aux_native_read_retry() is only needed when the sink might be
asleep. Use the regular read without retries otherwise.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dp.c | 33 +
1 file changed, 13 insertions(+), 20 deletions(-)
diff --git a/
These are based on drm-intel-nightly plus Thierry's aux channel
infrastructure patches [1], and supersede my dp aux fixes [2].
Patches 1-4 are prep work and fixes to our current code.
Patches 5 and 7 do the actual conversion for native aux and i2c over
aux, respectively. Patch 6 is minor cleanup
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dp.c | 45 ++-
1 file changed, 25 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 835f16da80af..0a8a2b189ed0 100644
--- a/drivers/gp
There's some confusion between ints and bools.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dp.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 19ff1b161ffb..ccc1228b7df7 1006
Introduce _edp_panel_vdd_on() that returns true if the call enabled vdd,
and a matching disable is needed. Keep edp_panel_vdd_on() as a helper
for when it is expected the vdd is off.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dp.c | 22 --
1 file changed, 16
The main differences are:
* Native aux has retry limit of 7 instead of infinite retry.
* Sleep in native reply defer increases from udelay(100) to
usleep_range(400, 500).
* Unknown native reply results in retry instead of -EIO.
* Lower level -EBUSY results in retry instead of fail.
* Write r
This is prep work for conversion to generic drm i2c-over-aux helpers
where we won't have the function to do this at.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dp.c |9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/dr
The main differences are:
* Many of the native aux differences mentioned in the relevant commit
apply.
* Native aux and i2c-over-aux defer timeouts are increased to be safe
for all use cases instead of depending on DP device type and
properties.
* i2c start/stop/reset are not done.
* i2c
Hi x86 folks,
Ping on getting the gen2 stolen memory early quirk patches into the x86
tree.
>From our side Daniel and Chris both seemed happy with them, so I'd like
to get them in at some point.
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
In
On Tue, Feb 4, 2014 at 1:18 PM, Ben Widawsky
wrote:
> We get a large number of bugs which have a, "hey I have that too"
> because they see a GPU hang in dmesg. While two machines of the same
> model having a GPU hang is indeed a coincidence, it is far from enough
> evidence to suggest they are the
On Mon, Feb 03, 2014 at 10:59:41AM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Make sure selection loop does not generate duplicates
> when it picks a subset of objects for a single exec buffer.
>
> Signed-off-by: Tvrtko Ursulin
I've pulled in the first two patches and also fixed u
RFCv2: Reorganize array indexing so that full offsets can be used as
is. It makes grepping for registers in i915_reg.h much easier. Also
move offset arrays to intel_device_info.
v1: Fixed offsets for VLV, proper eDP handling
v2: Fixed BCLRPAT, PIPESRC, PIPECONF and DSP* macros.
v3: Added EDP pip
We get a large number of bugs which have a, "hey I have that too"
because they see a GPU hang in dmesg. While two machines of the same
model having a GPU hang is indeed a coincidence, it is far from enough
evidence to suggest they are the same.
In order to reduce this effect, and hopefully get peo
On Tue, Feb 04, 2014 at 02:08:27PM +0200, Ville Syrjälä wrote:
> On Tue, Feb 04, 2014 at 11:46:46AM +, Damien Lespiau wrote:
> > On Tue, Feb 04, 2014 at 05:05:47PM +0530, Sagar Arun Kamble wrote:
> > > On Tue, 2014-02-04 at 11:25 +, Damien Lespiau wrote:
> > > > On Tue, Feb 04, 2014 at 12:1
Bunch of explicit include paths needed adjustments and
eviction_common.c needs to be added to the dist files.
This has been broken in the following three commits:
commit 42bcd05eb3f1545fbf9c397c3f37c3f6a27c5da4
Author: Tvrtko Ursulin
Date: Mon Feb 3 10:59:41 2014 +
tests/eviction_comm
On Tue, Feb 04, 2014 at 11:46:46AM +, Damien Lespiau wrote:
> On Tue, Feb 04, 2014 at 05:05:47PM +0530, Sagar Arun Kamble wrote:
> > On Tue, 2014-02-04 at 11:25 +, Damien Lespiau wrote:
> > > On Tue, Feb 04, 2014 at 12:18:24PM +0100, Daniel Vetter wrote:
> > > > On Sat, Feb 01, 2014 at 12:4
On Tue, Feb 04, 2014 at 05:05:47PM +0530, Sagar Arun Kamble wrote:
> On Tue, 2014-02-04 at 11:25 +, Damien Lespiau wrote:
> > On Tue, Feb 04, 2014 at 12:18:24PM +0100, Daniel Vetter wrote:
> > > On Sat, Feb 01, 2014 at 12:43:48AM +0530, sagar.a.kam...@intel.com wrote:
> > > > From: Sagar Kamble
On Tue, Feb 04, 2014 at 12:31:37PM +0100, Daniel Vetter wrote:
> On Fri, Jan 31, 2014 at 03:42:48PM -0600, jeff.mc...@intel.com wrote:
> > From: Jeff McGee
> >
> > RPS manual mode disables/ignores load-based inputs and allows render
> > performance state to be controlled externally. The enabling
On Tue, Feb 04, 2014 at 12:05:13PM +0100, Daniel Vetter wrote:
> On Fri, Jan 31, 2014 at 11:34:58AM +, Chris Wilson wrote:
> > Since a purged buffer is one without any associated pages, attempting to
> > use it should generate EFAULT rather than EINVAL, as it is not strictly
> > an invalid para
On Tue, 2014-02-04 at 11:25 +, Damien Lespiau wrote:
> On Tue, Feb 04, 2014 at 12:18:24PM +0100, Daniel Vetter wrote:
> > On Sat, Feb 01, 2014 at 12:43:48AM +0530, sagar.a.kam...@intel.com wrote:
> > > From: Sagar Kamble
> > >
> > > This test will verify the 180 degree rotation of sprite and
On Sat, Feb 01, 2014 at 05:14:22PM +, Chris Wilson wrote:
> On Fri, Jan 31, 2014 at 03:42:47PM -0600, jeff.mc...@intel.com wrote:
> > From: Jeff McGee
> >
> > This series has recently been accepted into the Haswell Android kernel and
> > helps with debugging and profiling these power features
On Fri, Jan 31, 2014 at 03:42:48PM -0600, jeff.mc...@intel.com wrote:
> From: Jeff McGee
>
> RPS manual mode disables/ignores load-based inputs and allows render
> performance state to be controlled externally. The enabling of manual
> mode and setting of desired frequency is done through debugfs
On Fri, Jan 31, 2014 at 03:42:47PM -0600, jeff.mc...@intel.com wrote:
> From: Jeff McGee
>
> This series has recently been accepted into the Haswell Android kernel and
> helps with debugging and profiling these power features. I would like it
> to be considered for upstream incorporation. The pat
On Tue, Feb 04, 2014 at 12:18:24PM +0100, Daniel Vetter wrote:
> On Sat, Feb 01, 2014 at 12:43:48AM +0530, sagar.a.kam...@intel.com wrote:
> > From: Sagar Kamble
> >
> > This test will verify the 180 degree rotation of sprite and crtc planes.
> > It will allow user to control rotation separately
On Tue, Feb 04, 2014 at 12:18:24PM +0100, Daniel Vetter wrote:
> On Sat, Feb 01, 2014 at 12:43:48AM +0530, sagar.a.kam...@intel.com wrote:
> > From: Sagar Kamble
> >
> > This test will verify the 180 degree rotation of sprite and crtc planes.
> > It will allow user to control rotation separately
On Sat, Feb 01, 2014 at 12:43:48AM +0530, sagar.a.kam...@intel.com wrote:
> From: Sagar Kamble
>
> This test will verify the 180 degree rotation of sprite and crtc planes.
> It will allow user to control rotation separately for crtc and sprite
> planes.
>
> Signed-off-by: Sagar Kamble
What I a
On Fri, Jan 31, 2014 at 05:14:02PM +0200, Mika Kuoppala wrote:
> Found with smatch.
>
> Signed-off-by: Mika Kuoppala
Both smatch patches merged to dinq, thanks.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
On Mon, Feb 03, 2014 at 11:59:05AM +0530, Sagar Arun Kamble wrote:
> On Fri, 2014-01-31 at 22:38 +0200, Ville Syrjälä wrote:
> > On Sat, Feb 01, 2014 at 12:40:36AM +0530, sagar.a.kam...@intel.com wrote:
> > > From: Sagar Kamble
> > >
> > > With these patches 180 degree rotation for crtc and sprit
On Fri, Jan 31, 2014 at 11:34:58AM +, Chris Wilson wrote:
> Since a purged buffer is one without any associated pages, attempting to
> use it should generate EFAULT rather than EINVAL, as it is not strictly
> an invalid parameter.
>
> Signed-off-by: Chris Wilson
Care to drop a quick testcase
On Wed, Jan 29, 2014 at 04:17:37PM +, Damien Lespiau wrote:
> +static void run_test(data_t *data, enum ring r1, enum ring r2, enum test
> test)
> +{
> + struct ring_ops *r1_ops = &ops[r1];
> + struct ring_ops *r2_ops = &ops[r2];
> + drm_intel_bo *a, *b, *c;
> +
> + a = bo_creat
On Fri, Jan 31, 2014 at 11:09:47PM +0530, S, Deepak wrote:
> On 1/31/2014 10:40 PM, Ville Syrjälä wrote:
> >On Thu, Jan 30, 2014 at 11:08:16PM +0530, deepa...@intel.com wrote:
> >>From: Deepak S
> >>
> >>When we enter RC6 and GFX Clocks are off, the voltage remains higher
> >>than Vmin. When we tr
On Thu, Jan 30, 2014 at 07:04:44PM +0200, Mika Kuoppala wrote:
> As we seek the guilty batch using request and hangcheck
> score, this code is not needed anymore.
>
> v2: Rebase. Passing dev_priv instead of getting it from last_ring
>
> Signed-off-by: Mika Kuoppala
> Reviewed-by: Ben Widawsky (
On Mon, Feb 03, 2014 at 03:28:37PM +, Tvrtko Ursulin wrote:
>
> On 01/29/2014 08:34 PM, Daniel Vetter wrote:
> >Actually I've found something else to complain about:
> >
> >On Tue, Jan 28, 2014 at 2:16 PM, Chris Wilson
> >wrote:
> >>+#define I915_USERPTR_READ_ONLY 0x1
> >
> >This smells like
On Fri, Jan 31, 2014 at 02:57:35PM +, rafael.barba...@intel.com wrote:
> From: Rafael Barbalho
>
> IGT in android still had some hang-ups from the initial porting, we were
> re-compiling the lib directory every time for each tool or test binary. It
> also could get its include paths confused
On Thu, Jan 30, 2014 at 03:01:08PM -0200, Rodrigo Vivi wrote:
> On Thu, Jan 30, 2014 at 11:02 AM, Chris Wilson
> wrote:
> > On Wed, Jan 29, 2014 at 01:50:06PM -0200, Rodrigo Vivi wrote:
> >> @@ -7501,6 +7501,9 @@ static void intel_crtc_update_cursor(struct drm_crtc
> >> *crtc,
> >> u32 bas
On Sat, Feb 01, 2014 at 11:34:02AM +, Chris Wilson wrote:
> On Wed, Jan 29, 2014 at 08:21:41PM +0100, Daniel Vetter wrote:
> > On Wed, Jan 29, 2014 at 12:55:35PM -0200, Rodrigo Vivi wrote:
> > > This patch adds PSR Support to Baytrail.
> > >
> > > Baytrail cannot easily detect screen updates a
On Fri, Jan 31, 2014 at 08:05:37AM -0500, Rodrigo Vivi wrote:
> Both registers must be programmed for the Mode bit to be valid. DevIVB:GT2 ...
>
> So I also agree ;)
> Maybe you should improve the commit message now that we are sure, but anyway:
I've added a little not to the commit message when
1 - 100 of 105 matches
Mail list logo
