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 occu
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 a
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 inclusions
into "#ifdef CONFIG_ACPI", build breakge can help to detect wrong ACPICA
dependent modules
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
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 a
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
> pipes&planes 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 t
From: Paulo Zanoni
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
---
tests/.gitignore | 1 +
tests/Makefile.sources | 1 +
tests/pm_lpsp.c| 275
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 a
On Thu, Nov 21, 2013 at 09:29:51PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> 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ä
Yeah, makes tons of sense and has definitely st
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ä
> >
> > Only plane A is FBC capable on gen2 (like gen3), but the panel fitter
> > is hooked up to pipe B, so we want to prefer pip
On Tue, Dec 03, 2013 at 03:36:20PM -0200, Paulo Zanoni wrote:
> From: Damien Lespiau
>
> 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 co
From: Paulo Zanoni
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
---
tests/kms_setmode.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/te
From: Damien Lespiau
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 use a connector that is
2013/11/29 Damien Lespiau :
> 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 use a con
2013/11/29 Damien Lespiau :
> That we can use for debugging purposes.
>
> Signed-off-by: Damien Lespiau
> ---
> drivers/gpu/drm/i915/intel_display.c | 13 +
> drivers/gpu/drm/i915/intel_drv.h | 1 +
> 2 files changed, 14 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_d
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ä
> >
> > We don't have clock state readout support for DDI, so skip the pipe
> > config clock checks on all DDI platforms.
> >
>
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(
On Sun, 2013-12-01 at 10:58 +0100, Daniel Vetter wrote:
> Should be fixed with
>
> commit 7c063c725987406d743cc7de7625ff224fab75de
> Author: Jesse Barnes
> Date: Tue Nov 26 09:13:41 2013 -0800
>
> drm/i915: take mode config lock around crtc disable at suspend
>
> which is currently in drm
On Mon, 2013-12-02 at 15:23 +0100, Daniel Vetter wrote:
> On Mon, Dec 2, 2013 at 10:53 AM, Paul Bolle 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 that's insuf
On Mon, 2013-12-02 at 11:08 +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> 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 locks, but the init codepath
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 current
On Mon, 2013-12-02 at 08:33 +0100, Daniel Vetter wrote:
> On Sun, Dec 1, 2013 at 5:57 PM, Paul Bolle 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 during boot?
>
Hi all,
Paulo poked me to make the testcase tag in the sob-section of commit
messages official:
Please mention testcases which exercise the new feature your patch adds or
the bug it fixes with a tag in the sob-section of your commit message like
this:
Testcase: igt/kms_setmode/clone-exclusive-cr
On Mon, Dec 02, 2013 at 05:31:53PM +0200, Mika Kuoppala wrote:
> We used to lean on active_list to handle the references
> to batch objects. But there are useful cases when same,
> albeit simple, batch can be executing on multiple rings
> concurrently. For this case the active_list reference count
On Tue, Dec 03, 2013 at 01:47:00PM +, Damien Lespiau wrote:
> Sweeping some dead code away.
>
> Signed-off-by: Damien Lespiau
This one and patch 1 merged to dinq, thanks.
-Daniel
> ---
> drivers/gpu/drm/i915/intel_dp.c | 12
> 1 file changed, 12 deletions(-)
>
> diff --git a/
On Mon, Dec 02, 2013 at 06:32:51PM +0200, Mika Kuoppala wrote:
> Chris Wilson 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 the
> >> reque
On Tue, Dec 03, 2013 at 04:44:53PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> 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 implement
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
> > >
> > > We do not have GLib there so it does not build.
> >
> > What depende
From: Tvrtko Ursulin
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 correct PID/TGID and TID val
From: Tvrtko Ursulin
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 values.
Solution is to
On Tue, Dec 03, 2013 at 01:07:46PM -0200, Paulo Zanoni wrote:
> 2013/12/3 Damien Lespiau :
> > 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 in the last month
From: Tvrtko Ursulin
This reverts commit a031a1bf93b828585e7147f06145fc5030814547.
Signed-off-by: Tvrtko Ursulin
Conflicts:
lib/drmtest.c
---
lib/drmtest.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/lib/drmtest.c b/lib/drmtest.c
index 94fa686..dcacd3b 100644
--- a/
On Mon, Dec 02, 2013 at 11:27:50PM +0100, Jiri Kosina wrote:
> I am getting this during suspend with latest Linus' git (HEAD == af91706).
>
> [ cut here ]
> WARNING: CPU: 0 PID: 5397 at drivers/gpu/drm/i915/intel_display.c:9948
> intel_get_pipe_from_connector+0x4a/0x50
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 initi
On Tue, Dec 03, 2013 at 03:09:57PM +, tvrtko.ursu...@linux.intel.com wrote:
> From: Tvrtko Ursulin
>
> 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 Ursu
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
> >
> > We do not have GLib there so it does not build.
>
> What dependence on GLib would that be?
Haven't looked further than the header it includes
From: Ville Syrjälä
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] BIOS-e820: [mem 0x000
From: Ville Syrjälä
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ä
---
drivers/gpu/drm/i915/i915_gem_s
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 TOU
From: Ville Syrjälä
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] BIOS-e820: [mem 0x000
From: Ville Syrjälä
Print an informative message when reserving the graphics stolen
memory region in the early quirk.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Ville Syrjälä
---
arch/x86/kernel/early-quirks.c
From: Ville Syrjälä
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 were to stumble on one of these
From: Ville Syrjälä
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
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Cc: linux
On Tue, Dec 03, 2013 at 03:35:41PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> 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
___
Intel-gf
From: Tvrtko Ursulin
We do not have GLib there so it does not build.
Signed-off-by: Tvrtko Ursulin
---
tests/Android.mk | 1 +
1 file changed, 1 insertion(+)
diff --git a/tests/Android.mk b/tests/Android.mk
index ec64acd..c96f30a 100644
--- a/tests/Android.mk
+++ b/tests/Android.mk
@@ -65,6 +
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 wrote:
> > > This generated quite a bit of debug messages so I only copied the
> > > WARNING and the drm (related) messages immediat
From: Tvrtko Ursulin
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
---
lib/check-ndebug.h | 3 +++
tests/Android.mk | 2 +-
tests/Makefile.am | 1 +
3 f
2013/12/3 Damien Lespiau :
> 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 in the last months to
debug things, like the PC8 interrupts. I'm not sure how much we gai
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
---
drivers/gpu/drm/i915/intel_dp.c | 17 ++---
1 file changed, 6 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu
It's all about tiny details.
Signed-off-by: Damien Lespiau
---
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
--- a/drivers/gpu/drm/i915/intel_d
Sweeping some dead code away.
Signed-off-by: Damien Lespiau
---
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
--- a/drivers/gpu/drm/i915/intel_dp.c
+
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
---
drivers/gpu/drm/i915/i915_reg.h | 8
drivers/gpu/drm/i915/intel_dp.c | 18 +-
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
On Mon, Dec 02, 2013 at 11:26:09AM -0200, Rodrigo Vivi wrote:
> From: Jani Nikula
>
> 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 Nikula
> Signe
On Tue, Dec 03, 2013 at 11:30:09AM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> 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 mi
From: Ville Syrjälä
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ä
---
drivers/gpu/drm/i915/int
56 matches
Mail list logo
