Summary
We finished a new round of kernel testing. During this round 1 new bug, and
close 1 bugs. Till now, 15 related bugs are still open.
Test Environment
The Linux Kernel, the operating system core itself
Kernel: (drm-intel-testing)ef6113ad0f406db4fbe2bcf3359dd938a6046d75
Some additional comm
On Thu, 30 Aug 2012 16:31:18 +0100
Chris Wilson wrote:
> The primary purpose of this was to debug some use-after-free memory
> corruption that was causing an OOPS inside drm/i915. As it turned out
> the corruption was being caused elsewhere and i915.ko as a major user
> of many objects was being
On Thu, 30 Aug 2012 17:07:39 +0100, Damien Lespiau
wrote:
> From: Damien Lespiau
>
> From time to time, one would like to decode a register value that have
> been captured at a certain point in time (and say printed out with a
> printk). intel_reg_dumper has all the knowledge to do that and thi
You can ignore this complete set, I managed to blow away half the
changes from the last round of review.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/
From: Damien Lespiau
>From time to time, one would like to decode a register value that have
been captured at a certain point in time (and say printed out with a
printk). intel_reg_dumper has all the knowledge to do that and this
patch adds a -r option to use the tool in that mode.
Example usage
In order to specialise functions depending upon the type of object, we
can attach vfuncs to each object via a new ->ops pointer.
For instance, this will be used in future patches to only bind pages from
a dma-buf for the duration that the object is used by the GPU - and so
prevent them from pinnin
By using the recently introduced pinning of pages, we can safely drop
the mutex in the knowledge that the pages are not going to disappear
beneath us, and so we can simplify the code for iterating over the pages.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 37
We need to refcount our pages in order to prevent reaping them at
inopportune times, such as when they currently vmapped or exported to
another driver. However, we also wish to keep the lazy deallocation of
our pages so we need to take a pin/unpinned approach rather than a
simple refcount.
Signed-
By using the recently introduced pinning of pages, we can safely drop
the mutex in the knowledge that the pages are not going to disappear
beneath us, and so we can simplify the code for iterating over the pages.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 36
It was not until the G33 refresh, that a PCI config register was
introduced that explicitly said where the stolen memory was. Prior to
865G there was not even a register that said where the end of usable
low memory was and where the stolen memory began (or ended depending
upon chipset). Before then
A few of the earlier registers where enlarged and so the Base Data of
Stolem Memory Register (BDSM) was pushed to 0xb0.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_stolen.c |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_
In order to accommodate objects that are not backed by struct pages, but
instead point into a contiguous region of stolen space, we need to make
various changes to avoid dereferencing obj->pages or obj->base.filp.
First introduce a marker for the stolen object, that specifies its
offset into the s
As we may wish to wrap regions preallocated by the BIOS, we need to do
that before carving out contiguous chunks of stolen space for FBC.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h|1 +
drivers/gpu/drm/i915/i915_gem_stolen.c | 110 ---
To be used later by i915 to preallocate exact blocks of space from the
range manager.
Signed-off-by: Chris Wilson
Cc: Dave Airlie
---
drivers/gpu/drm/drm_mm.c | 49 ++
include/drm/drm_mm.h |4
2 files changed, 53 insertions(+)
diff --g
This will be used i915 in forthcoming patches in order to measure the
largest contiguous chunk of memory available for enabling chipset
features.
Signed-off-by: Chris Wilson
Cc: Dave Airlie
---
drivers/gpu/drm/drm_mm.c | 55 +++---
include/drm/drm_mm.h
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_fb.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_fb.c b/drivers/gpu/drm/i915/intel_fb.c
index 97f6735..9de9cd9 100644
--- a/drivers/gpu/drm/i915/intel_fb.c
+++ b/drivers/gpu/drm/i91
Stolen objects also share the property that they have no backing shmemfs
filp, but they can be used with pwrite/pread/gtt-mapping.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h |5 +
drivers/gpu/drm/i915/i915_gem.c |4 ++--
2 files changed, 7 insertions(+), 2 deleti
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_overlay.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_overlay.c
b/drivers/gpu/drm/i915/intel_overlay.c
index afd0f30..2fa20a4 100644
--- a/drivers/gpu/drm/i915/intel_overlay.c
+
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 159 ---
1 file changed, 100 insertions(+), 59 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index b0b81aa..bcf0708 100644
--- a/drivers/gpu/drm/i9
Allow for the creation of GEM objects backed by stolen memory. As these
are not backed by ordinary pages, we create a fake dma mapping and store
the address in the scatterlist rather than obj->pages.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h|3 +
drivers/gpu/drm
By exporting the ability to map user address and inserting PTEs
representing their backing pages into the GTT, we can exploit UMA in order
to utilize normal application data as a texture source or even as a
render target (depending upon the capabilities of the chipset). This has
a number of uses, w
The primary purpose of this was to debug some use-after-free memory
corruption that was causing an OOPS inside drm/i915. As it turned out
the corruption was being caused elsewhere and i915.ko as a major user of
many objects was being hit hardest.
Indeed as we do frequent the generic kmalloc caches
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_ringbuffer.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 984a0c5..577a96a 100644
--- a/drivers/gpu/drm/i915/intel_rin
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 175 ++-
1 file changed, 116 insertions(+), 59 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index bcf0708..d1c1b60 100644
--- a/drivers/gpu/drm/i9
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_irq.c |8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index f437398..7324850 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.
As FBC is commonly disabled due to limitations of the chipset upon
output configurations, on many systems FBC is never enabled. For those
systems, it is advantageous to make use of the stolen memory for other
objects and so we defer allocation of the FBC chunk until we actually
require it. This inc
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h |2 ++
drivers/gpu/drm/i915/i915_gem_gtt.c | 35 ---
2 files changed, 34 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index f6
By providing a callback for when we need to bind the pages, and then
release them again later, we can shorten the amount of time we hold the
foreign pages mapped and pinned, and importantly the dmabuf objects then
behave as any other normal object with respect to the shrinker and
memory management.
Rather than have multiple data structures for describing our page layout
in conjunction with the array of pages, we can migrate all users over to
a scatterlist.
One major advantage, other than unifying the page tracking structures,
this offers is that we replace the vmalloc'ed array (which can be
Just to keep the context for deciding upon the correct colour of paint,
here are the current patches to replace obj->pages with a scatterlist
and use that to map objects into the stolen memory.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedeskto
On 8/30/12 3:44 AM, Daniel Vetter wrote:
Some monitors totally don't like to receive infoframes, and naturally
don't claim to support hdmi.
But for some odd reason they've added a CEA block to their edid,
which automatically gives you basic audio. Still, we may not send
out hdmi infoframes to th
On Mon, 20 Aug 2012 21:56:08 +0200, Daniel Vetter wrote:
> On Sat, Aug 11, 2012 at 03:41:21PM +0100, Chris Wilson wrote:
> > Signed-off-by: Chris Wilson
>
> What about putting kmap/unmap abstractions into obj->ops (like the dma_buf
> interface already has)? Since the pwrite/pread code is already
Am Donnerstag, den 30.08.2012, 13:26 +0200 schrieb Daniel Vetter:
> We've had and still have too many issues where the gpu turbot doesn't
s,turbot,turbo,
> quite to what it's supposed to do (or what we want it to do).
s,to,do,
> Adding a tracepoint to track when the desired gpu frequence change
On Thu, 30 Aug 2012 13:26:48 +0200, Daniel Vetter
wrote:
> We've had and still have too many issues where the gpu turbot doesn't
> quite to what it's supposed to do (or what we want it to do).
>
> Adding a tracepoint to track when the desired gpu frequence changes
> should help a lot in characte
2012/8/30 Christian Gmeiner :
> 2012/8/30 Chris Wilson :
>> On Thu, 30 Aug 2012 10:24:17 +0200, Christian Gmeiner
>> wrote:
>>> [13.840] drmOpenDevice: node name is /dev/dri/card0
>>> [13.840] drmOpenDevice: open result is 7, (OK)
>>> [13.840] drmOpenByBusid: Searching for BusID pci:0
We've had and still have too many issues where the gpu turbot doesn't
quite to what it's supposed to do (or what we want it to do).
Adding a tracepoint to track when the desired gpu frequence changes
should help a lot in characterizing and understanding problematic
workloads.
Also, this should be
2012/8/30 Chris Wilson :
> On Thu, 30 Aug 2012 10:24:17 +0200, Christian Gmeiner
> wrote:
>> [13.840] drmOpenDevice: node name is /dev/dri/card0
>> [13.840] drmOpenDevice: open result is 7, (OK)
>> [13.840] drmOpenByBusid: Searching for BusID pci::00:02.0
>> [13.840] drmOpenDe
On Thu, 30 Aug 2012 10:24:17 +0200, Christian Gmeiner
wrote:
> [13.840] drmOpenDevice: node name is /dev/dri/card0
> [13.840] drmOpenDevice: open result is 7, (OK)
> [13.840] drmOpenByBusid: Searching for BusID pci::00:02.0
> [13.840] drmOpenDevice: node name is /dev/dri/card0
I forgot to say that I tested tv out here on 945GME Express and
82945G/GZ and it worked fine as well. No regression.
On Wed, Aug 29, 2012 at 9:26 AM, Lespiau, Damien
wrote:
> On Thu, Aug 23, 2012 at 11:39 PM, Daniel Vetter wrote:
>> On Thu, Aug 23, 2012 at 01:26:39PM +0100, Lespiau, Damien wrote
On Tue, August 28, 2012 16:55, Daniel Vetter wrote:
> On Tue, Aug 28, 2012 at 04:39:34PM +0200, Indan Zupancic wrote:
>> Some backlight problems on GEN4 can be solved by not fiddling with the
>> backlight. The current code sets the backlight to 0 to disable the panel
>> (last year anyway, maybe the
On Thu, Aug 30, 2012 at 11:06:18AM +1000, Dave Airlie wrote:
> In order to setup the i2c channel, we power up the panel
> via ironlake_edp_panel_vdd_on, however it requires
> intel_dp->panel_power_up_delay to be initialised,
> which hasn't been setup yet.
>
> So move things around so we set the pa
On Thu, Aug 30, 2012 at 10:32:48AM +0200, Indan Zupancic wrote:
> On Tue, August 28, 2012 17:15, Daniel Vetter wrote:
> > On Tue, Aug 28, 2012 at 04:49:15PM +0200, Indan Zupancic wrote:
> >> By the way, saving LBPC only makes sense if it's done before it was
> >> set to 0 to disable the panel. I do
On Tue, August 28, 2012 17:15, Daniel Vetter wrote:
> On Tue, Aug 28, 2012 at 04:49:15PM +0200, Indan Zupancic wrote:
>> By the way, saving LBPC only makes sense if it's done before it was
>> set to 0 to disable the panel. I don't know if the current code does
>> the right thing, I haven't looked a
2012/8/30 Daniel Vetter :
> On Thu, Aug 30, 2012 at 10:12 AM, Zhang, Xiong Y
> wrote:
>> I think vesafb driver should not run.
>> But in following dmesg, I see vesafb driver running before drm driver.
>
> If you are on a recent enough stable kernel that's absolutely no
> problem - the i915.ko driv
On Thu, Aug 30, 2012 at 10:12 AM, Zhang, Xiong Y
wrote:
> I think vesafb driver should not run.
> But in following dmesg, I see vesafb driver running before drm driver.
If you are on a recent enough stable kernel that's absolutely no
problem - the i915.ko driver will kick the vesafb driver before
Some monitors totally don't like to receive infoframes, and naturally
don't claim to support hdmi.
But for some odd reason they've added a CEA block to their edid,
which automatically gives you basic audio. Still, we may not send
out hdmi infoframes to them, hence check whether the sink is indeed
46 matches
Mail list logo
