Should it fix this[1] bug?
[1]https://bugs.freedesktop.org/show_bug.cgi?id=26664
Thank you,
Darkbasic
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Fri, 24 Sep 2010 22:48:36 +0300
Vasily Khoruzhick wrote:
> On 24 of September 2010 22:39:01 Jesse Barnes wrote:
> > On Thu, 16 Sep 2010 23:06:46 +0300
> >
> > Vasily Khoruzhick wrote:
> > > В сообщении от 16 of September 2010 21:50:50 автор Thomas Gleixner
> написал:
> > > > Ok. The problem
On 24 of September 2010 22:39:01 Jesse Barnes wrote:
> On Thu, 16 Sep 2010 23:06:46 +0300
>
> Vasily Khoruzhick wrote:
> > В сообщении от 16 of September 2010 21:50:50 автор Thomas Gleixner
написал:
> > > Ok. The problematic part of HPET was not the clocksource, it was the
> > > clock event devi
This patch enables the sending of AVI infoframes in
drivers/gpu/drm/i915/intel_hdmi.c.
My receiver currently loses sync when the HDMI output on my computer
(DG45FC motherboard) is switched from 800x600 (the BIOS resolution) to
1920x1080 as part of the boot. Fixable by switching inputs on the recei
On Thu, 16 Sep 2010 23:06:46 +0300
Vasily Khoruzhick wrote:
> В сообщении от 16 of September 2010 21:50:50 автор Thomas Gleixner написал:
> > Ok. The problematic part of HPET was not the clocksource, it was the
> > clock event device which failed to deliver interrupts occasionally. It
> > was wor
On Mon, 2010-09-13 at 18:48 +0100, Matthew Garrett wrote:
> I've looked into this issue more closely and think I've worked out the
> underlying problem. The system in question appears to have two GPUs and
> exposes two ACPI backlight devices. Both of these are associated with
> existing PCI devi
On Thu, 16 Sep 2010 18:03:04 +0300
Vasily Khoruzhick wrote:
> В сообщении от 15 of September 2010 01:41:11 автор Sitsofe Wheeler написал:
> > > > processor.max_cstate=2
> > >
> > > Nope, it doesn't work with max_cstate=2
> >
> > Perhaps intel_idle is being used? Any mention of it in dmesg?
On Fri, 24 Sep 2010 19:32:05 +0200, Daniel Vetter
wrote:
> It seems to work rather well and decently improves performance for
> workloads that now fit into the gtt and previously didn't.
That's the understatement of the year. Nice work. :)
-Chris
--
Chris Wilson, Intel Open Source Technology C
On VT-d supporting platforms the GGTT is allocated in a stolen mem
section separate from graphcis stolen mem. The GMCH register contains
a bitfield specifying the size of that region. Docs suggest that this
region can only be used for GGTT and PPGTT. Hence ensure that the
PPGTT is disabled and use
... and switch to a more classical store-reg-on-suspend, restore-on-resume
way of doing things. Obviously this is just preparation for the future,
the code is not there at all, yet.
This is needed because the next patch adjusts this register and everything
in it (not just the pagetable address) ne
At least the part that's currently enabled by the BIOS.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_dma.c | 14 +-
drivers/gpu/drm/i915/i915_drv.h |2 +-
drivers/gpu/drm/i915/i915_gem.c |6 +++---
3 files changed, 13 insertions(+), 9 deletions(-)
diff --git
In i915_gem_object_pin obviously unbind only if mappable is true.
This is the last part to enable gtt_mappable_end != gtt_size, which
the next patch will do.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_gem.c | 24 ++--
1 files changed, 22 insertions(+), 2 de
Like before add a parameter mappable (also to gem_object_pin) and
set it depending upon the context. Only bos that are brought into
the gtt due to an execbuffer call can be put into the unmappable
part of the gtt, everything else (especially pinned objects) need
to be put into the mappable part of
Add a mappable parameter to i915_gem_evict_something to distinguish
the two cases (non-restricted vs. mappable gtt allocations). No
functional changes because the mappable limit is set to the end of
the gtt currently.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.h |5
Hi all,
This patch series enables the unmappable part of the gtt where available
(g33/pineview and gen4 and later). I've already sent out the required drm
core changes to dri-devel. Current wip branch for this is available at
git://anongit.freedesktop.org/~danvet/drm full-gtt
It seems to work ra
2010/9/23 Chris Wilson :
> On Thu, 23 Sep 2010 20:36:47 +0200, Hette Visser
> wrote:
>> This patch fixes the black screen bug on Dell e6510:
>> https://bugs.freedesktop.org/show_bug.cgi?id=29278
>>
>> It adds two delays to give the eDP panel time to turn on before we
>> continue with the next wri
16 matches
Mail list logo
