From: Ville Syrjälä ville.syrj...@linux.intel.com
The BIOS or someone else might have done something bad and there
might be old GT FIFO erros reported in GTFIFODBG. Clear those out
in intel_uncore_early_sanitize() to make sure we don't mistake them
for our problems.
Signed-off-by: Ville Syrjälä
On Tue, Dec 03, 2013 at 11:30:09AM +0200, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
The BIOS or someone else might have done something bad and there
might be old GT FIFO erros reported in GTFIFODBG. Clear those out
in intel_uncore_early_sanitize()
On Mon, Dec 02, 2013 at 11:26:09AM -0200, Rodrigo Vivi wrote:
From: Jani Nikula jani.nik...@intel.com
Checkpatch tells me
WARNING: __packed is preferred over __attribute__((packed))
so switch over to __packed across the driver before adding new packed
structs.
Signed-off-by: Jani
While cruising in intel_dp.c, a few things caught my eye.
--
Damien
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
It's all about tiny details.
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/i915/intel_ddi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index c8382f5..c8a5fb7 100644
---
Sweeping some dead code away.
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/i915/intel_dp.c | 12
1 file changed, 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 7a825db..07fcc9e 100644
---
Let's use a less verbose version to fill the DP_AUX_CTL register.
Improves the readability a little bit. Also sort the fields by their
place in the register.
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 8
drivers/gpu/drm/i915/intel_dp.c
has_aux_irq is initialized to true and never touched again these days.
Just remove it along with the has_aux_irq = false code path.
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/i915/intel_dp.c | 17 ++---
1 file changed, 6 insertions(+), 11 deletions(-)
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
Tests depend on assertions being enabled since they can, and do,
contain actual test steps. They are also mandatory for ensuring
sane test case behaviour.
Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
---
lib/check-ndebug.h | 3 +++
On Mon, Dec 02, 2013 at 07:05:25PM +0100, Paul Bolle wrote:
On Mon, 2013-12-02 at 15:23 +0100, Daniel Vetter wrote:
On Mon, Dec 2, 2013 at 10:53 AM, Paul Bolle pebo...@tiscali.nl wrote:
This generated quite a bit of debug messages so I only copied the
WARNING and the drm (related)
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
We do not have GLib there so it does not build.
Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
---
tests/Android.mk | 1 +
1 file changed, 1 insertion(+)
diff --git a/tests/Android.mk b/tests/Android.mk
index ec64acd..c96f30a 100644
---
On Tue, Dec 03, 2013 at 03:35:41PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
We do not have GLib there so it does not build.
What dependence on GLib would that be?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
From: Ville Syrjälä ville.syrj...@linux.intel.com
For gen2 devices we're going to need another way to determine the
stolen memory base address. Make that into a vfunc as well.
Also drop the bogus inline keyword from gen8_stolen_size().
Cc: Thomas Gleixner t...@linutronix.de
Cc: Ingo Molnar
From: Ville Syrjälä ville.syrj...@linux.intel.com
Print an informative message when reserving the graphics stolen
memory region in the early quirk.
Cc: Thomas Gleixner t...@linutronix.de
Cc: Ingo Molnar mi...@redhat.com
Cc: H. Peter Anvin h...@zytor.com
Cc: x...@kernel.org
Cc:
From: Ville Syrjälä ville.syrj...@linux.intel.com
We don't have proper support for local memory elsewhere in the code,
and seeing as no-one seems to have ever seen a system which has local
memory, just report stolen_size as 0 when local memory is detected.
Add a big WARN to alert us if someone
From: Ville Syrjälä ville.syrj...@linux.intel.com
There isn't an explicit stolen memory base register on gen2.
Some old comment in the i915 code suggests we should get it via
max_low_pfn_mapped, but that's clearly a bad idea on my MGM.
The e820 map in said machine looks like this:
[0.00]
Another attempt at figuring out stolen memory for gen2. This time instead
of trusting the GTT base address, I used the same method the BIOS uses.
(TOM-TSEG_SIZE-stolen_size). Except on 865G where things are more complicated.
Fortunately it seems to have a simlple answer for us in the for om the
From: Ville Syrjälä ville.syrj...@linux.intel.com
On most gen2-4 platforms the GTT can be (or maybe always is?)
inside the stolen memory region. If that's the case, reduce the
size of the stolen memory appropriately to make make sure we
don't clobber the GTT.
Signed-off-by: Ville Syrjälä
On Tue, 2013-12-03 at 15:40 +, Chris Wilson wrote:
On Tue, Dec 03, 2013 at 03:35:41PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
We do not have GLib there so it does not build.
What dependence on GLib would that be?
Haven't looked further than the
On Mon, Dec 02, 2013 at 05:39:09PM +, Chris Wilson wrote:
We call intel_modeset_setup_hw_state() along two paths, driver
load/resume and after a lid event notification. During initialisation of
the driver, it is imperative that we reset the config state. This
correctly sets up the initial
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
This reverts commit a031a1bf93b828585e7147f06145fc5030814547.
Signed-off-by: Tvrtko Ursulin tvrtko.ursu...@intel.com
Conflicts:
lib/drmtest.c
---
lib/drmtest.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/lib/drmtest.c
On Tue, Dec 03, 2013 at 01:07:46PM -0200, Paulo Zanoni wrote:
2013/12/3 Damien Lespiau damien.lesp...@intel.com:
has_aux_irq is initialized to true and never touched again these days.
Just remove it along with the has_aux_irq = false code path.
I have set has_aux_irq to false a few times
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
It was observed both on Linux and Android that tests which
fork can sometimes hang failing to terminate child
processes.
This was eventually tracked down to race conditions in C
library implementations, all with regards to caching of
PID/TGID and TID
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
Various C library implementations have various races with regards
to caching getpid() or TID inside pthread_kill() implementations.
For example see clone(2) glibc man page and pthread_kill
Bionic C library source.
Work around that by making sure
On Tue, Dec 03, 2013 at 04:06:51PM +, Tvrtko Ursulin wrote:
On Tue, 2013-12-03 at 15:40 +, Chris Wilson wrote:
On Tue, Dec 03, 2013 at 03:35:41PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
We do not have GLib there so it does not build.
On Tue, Dec 03, 2013 at 04:44:53PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin tvrtko.ursu...@intel.com
It was observed both on Linux and Android that tests which
fork can sometimes hang failing to terminate child
processes.
This was eventually tracked down to race conditions in C
On Mon, Dec 02, 2013 at 06:32:51PM +0200, Mika Kuoppala wrote:
Chris Wilson ch...@chris-wilson.co.uk writes:
On Mon, Dec 02, 2013 at 04:47:46PM +0200, Mika Kuoppala wrote:
Fork and create another filedesc to wait access to already
hung GPU and then kill it. This triggers use after free of
On Tue, Dec 03, 2013 at 01:47:00PM +, Damien Lespiau wrote:
Sweeping some dead code away.
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
This one and patch 1 merged to dinq, thanks.
-Daniel
---
drivers/gpu/drm/i915/intel_dp.c | 12
1 file changed, 12 deletions(-)
On Mon, 2013-12-02 at 08:33 +0100, Daniel Vetter wrote:
On Sun, Dec 1, 2013 at 5:57 PM, Paul Bolle pebo...@tiscali.nl wrote:
The WARNING is now gone during suspend and resume (having tested that
thoroughly - ie, twice). But I still see it at boot. Is there a related
fix for that WARNING
On Mon, 2013-12-02 at 11:08 +0200, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Some lower level things get angry if we don't have modeset locks
during intel_modeset_setup_hw_state(). Actually the resume and
lid_notify codepaths alreday hold the
On Mon, 2013-12-02 at 14:12 +0200, Ville Syrjälä wrote:
On Mon, Dec 02, 2013 at 11:00:29AM +0100, Paul Bolle wrote:
I assume I need to test this, on top of 7c063c725987 (drm/i915: take
mode config lock around crtc disable at suspend), to see if this makes
the WARNING that I currently see
On Mon, 2013-12-02 at 15:23 +0100, Daniel Vetter wrote:
On Mon, Dec 2, 2013 at 10:53 AM, Paul Bolle pebo...@tiscali.nl wrote:
This generated quite a bit of debug messages so I only copied the
WARNING and the drm (related) messages immediately preceding it. Please
feel free to prod again if
On Sun, 2013-12-01 at 10:58 +0100, Daniel Vetter wrote:
Should be fixed with
commit 7c063c725987406d743cc7de7625ff224fab75de
Author: Jesse Barnes jbar...@virtuousgeek.org
Date: Tue Nov 26 09:13:41 2013 -0800
drm/i915: take mode config lock around crtc disable at suspend
which is
On both v3.13-rc1 and v3.13-rc2 is see this at every boot and during
every suspend and resume cycle:
4[2.682468] WARNING: CPU: 0 PID: 173 at
drivers/gpu/drm/i915/intel_display.c:9948
intel_get_pipe_from_connector+0x42/0x50 [i915]()
5[2.682470] Modules linked in: i915(F+) ata_generic(F)
On Mon, Dec 02, 2013 at 02:01:45PM +, Damien Lespiau wrote:
On Mon, Dec 02, 2013 at 11:23:39AM +0200, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
We don't have clock state readout support for DDI, so skip the pipe
config clock checks on all
2013/11/29 Damien Lespiau damien.lesp...@intel.com:
That we can use for debugging purposes.
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 13 +
drivers/gpu/drm/i915/intel_drv.h | 1 +
2 files changed, 14 insertions(+)
From: Damien Lespiau damien.lesp...@intel.com
The -detect() vfunc of connectors is usually responsible for setting the
encoder type on intel_digital_ports when a hotplug event happens.
However we sometimes want to force a modeset on a specific connector:
- the user can ask the SETCRTC ioctl to
From: Paulo Zanoni paulo.r.zan...@intel.com
Don't try to set modes on two connectors that share the same encoder.
That will just fail.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68463
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
tests/kms_setmode.c | 15 +++
On Tue, Dec 03, 2013 at 03:36:20PM -0200, Paulo Zanoni wrote:
From: Damien Lespiau damien.lesp...@intel.com
The -detect() vfunc of connectors is usually responsible for setting the
encoder type on intel_digital_ports when a hotplug event happens.
However we sometimes want to force a
On Fri, Nov 29, 2013 at 01:55:04PM +, Chris Wilson wrote:
On Thu, Nov 28, 2013 at 05:30:01PM +0200, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Only plane A is FBC capable on gen2 (like gen3), but the panel fitter
is hooked up to pipe B, so
On Thu, Nov 21, 2013 at 09:29:51PM +0200, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä ville.syrj...@linux.intel.com
Not all drivers will need take all the modeset locks for dirtyfb, so
push the locking down to the drivers.
Signed-off-by: Ville Syrjälä
On Thu, Nov 21, 2013 at 09:29:44PM +0200, ville.syrj...@linux.intel.com wrote:
Another set of FBC patches, which should fit on top of the previous set:
[PATCH 00/10] drm/i915: FBC fixes v2
The persistent mode and HT tracking bit stuff is a bit unclear in the docs,
but I can remove it all,
From: Paulo Zanoni paulo.r.zan...@intel.com
QA has asked me How can we make sure LPSP is working?. Now, instead
of writing big paragraphs, I can just answer make sure pm_lpsp
works.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
---
tests/.gitignore | 1 +
tests/Makefile.sources |
On Tue, 2013-12-03 at 16:19 +0100, Daniel Vetter wrote:
I'd like to confirm the actual cause (I suspect that we switch
pipesplanes around) for why you see this but other machines don't show
this to augment the commit message. But I've merged the fix already.
The dmesg, up to and including the
Clean up the return values/error handling so it's obvious what is going
on. This was tripped over in the PPGTT branch where code was added to do
a ret = foo() near the top, and this ended up bypassing some error cases
later.
These errors shouldn't exist with today's code, but a future patch
will
On Mon, Dec 02, 2013 at 10:08:02AM +, Chris Wilson wrote:
It is useful to assert that if the object is bound, then it must have
its pages pinned to prevent the shrinker from reaping its backing store.
This is even more useful with the introduction of real-ppgtt whereupon
we may have the
In Linux kernel, ACPICA is wrapped and safely exported by CONFIG_ACPI. So
all external modules should depend on CONFIG_ACPI rather than using ACPICA
header directly for stubbing. But if we moves acpi/acpi.h inclusions
into #ifdef CONFIG_ACPI, build breakge can help to detect wrong ACPICA
eb_destroy currently cleans up the refcounts for all the VMAs done at
lookup. Currently eb_lookup_vmas cleans up all the *objects* we've
looked up. There exists a period of time when we under severe memory
pressure, the VMA creation will fail, and fall into our exit path.
When the above event
48 matches
Mail list logo
