On Tue, 18 Dec 2012 23:03:02 +, Chris Wilson
wrote:
> On Tue, 18 Dec 2012 23:57:05 +0100, Daniel Vetter wrote:
> > On Tue, Dec 18, 2012 at 11:51 PM, Chris Wilson
> > wrote:
> > > As we can only pass in the base address of the first plane, we can not
> > > control the offset into the subsam
On Wed, 19 Dec 2012 08:10:24 +1000, Dave Airlie wrote:
> > As the shrinker may be invoked for the allocation, and it may reap
> > neighbouring objects in the offset range mm, we need to be careful in
> > the order in which we allocate the node, search for free space and then
> > insert the node in
On Wed, Dec 19, 2012 at 2:20 AM, Jesse Barnes wrote:
>> >
>> > I'd like to see a comment about this being for Xen in here, and I
>> > wonder if there are other places where we might have to worry about the
>> > Xen implementation. In that case, setting a flag in dev_priv when we
>> > don't find t
This function can be used to set the driver's next_seqno
to arbitrary value.
i915_gem_set_seqno() will idle the gpu, retire outstanding
requests, clear the semaphore mailboxes and set the hardware
status page's seqno index.
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_drv.h |4
Hi,
I have bought a Lenovo X1 carbon which have a integrated Intel HD 4000 graphics
chip and wanted to attach 2 external monitors however there is only one
mini-DislpayPort in this machine.
I found a Sunix DPD2000 displayport splitter and it works and percents a nice
3840x1200 display to me bu
On Wed, Dec 19, 2012 at 01:45:23PM +0200, Ville Syrjälä wrote:
> On Tue, Dec 18, 2012 at 10:31:27AM -0800, Ben Widawsky wrote:
> > The iomapping of the register region has historically been a uint32_t
> > for the obvious reason that our PTE size was always 4b. In the future
> > however, we cannot m
On Wed, Dec 19, 2012 at 12:14:22PM +, Chris Wilson wrote:
> This fixes an original bug in the sprite code that miscomputed the
> source offset into a linear YUV packed framebuffer, that was magnified
> into an oops with
>
> commit 5a35e99e8162d6820013a56ad15ea8bf937af5a6
> Author: Damien Lespi
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_display.c | 56 +-
drivers/gpu/drm/i915/intel_dp.c |7 ++---
drivers/gpu/drm/i915/intel_drv.h |6 ++--
drivers/gpu/drm/i915/intel_hdmi.c|7 ++---
drivers/gpu/drm/i915/intel_lvds.c
On Wed, 19 Dec 2012 14:33:46 +0100, Daniel Vetter
wrote:
> The mmap offset structure is not part of the drm/i915 code, but
> provided by gem helpers. To avoid leaky abstractions (by either
> depending upon implementation details of said helper wrt to
> preallocations, or reimplementing it in our
The mmap offset structure is not part of the drm/i915 code, but
provided by gem helpers. To avoid leaky abstractions (by either
depending upon implementation details of said helper wrt to
preallocations, or reimplementing it in our code and so fuzzing
around in internal details of that helpr) simpl
commit 5774506f157a91400c587b85d1ce4de56f0d32f6
Author: Chris Wilson
Date: Wed Nov 21 13:04:04 2012 +
drm/i915: Borrow our struct_mutex for the direct reclaim
added a nice trick to steal the struct_mutex lock in the shrinker if
it's the current task holding it. But this also caused the
On Wed, 19 Dec 2012 13:08:35 +0100, Daniel Vetter
wrote:
> commit 5774506f157a91400c587b85d1ce4de56f0d32f6
> Author: Chris Wilson
> Date: Wed Nov 21 13:04:04 2012 +
>
> drm/i915: Borrow our struct_mutex for the direct reclaim
If you choose to take this path, do it as two patches so t
This fixes an original bug in the sprite code that miscomputed the
source offset into a linear YUV packed framebuffer, that was magnified
into an oops with
commit 5a35e99e8162d6820013a56ad15ea8bf937af5a6
Author: Damien Lespiau
Date: Fri Oct 26 18:20:12 2012 +0100
drm/i915: adjust sprite ba
On Wed, Dec 19, 2012 at 12:03:09PM +, Chris Wilson wrote:
> On Wed, 19 Dec 2012 13:56:12 +0200, Ville Syrjälä
> wrote:
> > On Tue, Dec 18, 2012 at 11:57:05PM +0100, Daniel Vetter wrote:
> > > On Tue, Dec 18, 2012 at 11:51 PM, Chris Wilson
> > > wrote:
> > > > As we can only pass in the base
On Wed, 19 Dec 2012 13:56:12 +0200, Ville Syrjälä
wrote:
> On Tue, Dec 18, 2012 at 11:57:05PM +0100, Daniel Vetter wrote:
> > On Tue, Dec 18, 2012 at 11:51 PM, Chris Wilson
> > wrote:
> > > As we can only pass in the base address of the first plane, we can not
> > > control the offset into th
On Tue, Dec 18, 2012 at 10:13:13PM +, Chris Wilson wrote:
> This fixes a regression from
>
> commit 57779d06367a915ee03e6cb918d7575f0a46e419
> Author: Ville Syrjälä
> Date: Wed Oct 31 17:50:14 2012 +0200
>
> drm/i915: Fix display pixel format handling
>
> (which even says that they ar
On Wed, Dec 19, 2012 at 11:52:11AM +, Chris Wilson wrote:
> On Wed, 19 Dec 2012 13:47:41 +0200, Ville Syrjälä
> wrote:
> > On Tue, Dec 18, 2012 at 10:13:14PM +, Chris Wilson wrote:
> > > This proves to be very useful when investigating why code suddenly
> > > started failing.
> > >
> > >
On Tue, Dec 18, 2012 at 11:57:05PM +0100, Daniel Vetter wrote:
> On Tue, Dec 18, 2012 at 11:51 PM, Chris Wilson
> wrote:
> > As we can only pass in the base address of the first plane, we can not
> > control the offset into the subsampled chroma planes. This means that we
> > cannot support a sou
On Wed, 19 Dec 2012 13:47:41 +0200, Ville Syrjälä
wrote:
> On Tue, Dec 18, 2012 at 10:13:14PM +, Chris Wilson wrote:
> > This proves to be very useful when investigating why code suddenly
> > started failing.
> >
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/i915/intel_disp
commit 5774506f157a91400c587b85d1ce4de56f0d32f6
Author: Chris Wilson
Date: Wed Nov 21 13:04:04 2012 +
drm/i915: Borrow our struct_mutex for the direct reclaim
added a nice trick to steal the struct_mutex lock in the shrinker if
it's the current task holding it. But this also caused the
On Tue, Dec 18, 2012 at 10:13:14PM +, Chris Wilson wrote:
> This proves to be very useful when investigating why code suddenly
> started failing.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/intel_display.c | 33 +
> 1 file changed, 25 insert
On Tue, Dec 18, 2012 at 10:31:27AM -0800, Ben Widawsky wrote:
> The iomapping of the register region has historically been a uint32_t
> for the obvious reason that our PTE size was always 4b. In the future
> however, we cannot make this assumption.
>
> By making the type void, it makes the upcomin
On Wed, Dec 19, 2012 at 11:03:41AM +0100, Krzysztof Mazur wrote:
> Some broken systems (like HP nc6120) in some cases, usually after LID
> close/open, enable VGA plane, making display unusable (black screen on LVDS,
> some strange mode on VGA output). We used to disable VGA plane only once at
> sta
On Wed, Dec 19, 2012 at 09:57:58AM +, Chris Wilson wrote:
> On Wed, 19 Dec 2012 11:13:09 +0200, Mika Kuoppala
> wrote:
> > This debugs entry can be used to set arbitrary value to next_seqno.
> > Use i915_gem_set_seqno instead of poking next_seqno.
> >
> > v2: nasty details of next_seqno and
On Wed, 19 Dec 2012 11:13:09 +0200, Mika Kuoppala
wrote:
> This debugs entry can be used to set arbitrary value to next_seqno.
> Use i915_gem_set_seqno instead of poking next_seqno.
>
> v2: nasty details of next_seqno and last_seqno handling
> moved inside i915_gem_set_seqno as suggested by Chri
We simply need to switch over to computing those directly, but for now
just shut this up. Totally uninteresting for anyone but developers.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=58497
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_ddi.c |4 ++--
1 file changed, 2
Chris Wilson writes:
> On Tue, 18 Dec 2012 19:26:18 +0200, Mika Kuoppala
> wrote:
>> Hardware status page needs to have proper seqno set
>> as our initial seqno can be arbitrary. If initial seqno is close
>> to wrap boundary on init and i915_seqno_passed() (31bit space)
>> refers to hw status p
In preparation for setting per ring initial seqno values
add ring::set_seqno().
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 20
drivers/gpu/drm/i915/intel_ringbuffer.h |9 +
2 files changed, 29 insertions(+)
diff --git a/drivers/
This debugs entry can be used to set arbitrary value to next_seqno.
Use i915_gem_set_seqno instead of poking next_seqno.
v2: nasty details of next_seqno and last_seqno handling
moved inside i915_gem_set_seqno as suggested by Chris Wilson.
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i9
Hardware status page needs to have proper seqno set
as our initial seqno can be arbitrary. If initial seqno is close
to wrap boundary on init and i915_seqno_passed() (31bit space)
refers to hw status page which contains zero, errorneous result
will be returned.
v2: clear mboxes and set hws page di
This function can be used to set the driver's next_seqno
to arbitrary value.
i915_gem_set_seqno() will idle the gpu, retire outstanding
requests, clear the semaphore mailboxes and set the hardware
status page's seqno index.
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_drv.h |4
In preparation for setting the seqno to arbitrary value on init or
through debugfs. We need to always clear the semaphores and set the
hws page seqno index by calling intel_ring_init_seqno().
v2: rewrote the commit message as suggested by Chris Wilson.
Signed-off-by: Mika Kuoppala
---
drivers/g
32 matches
Mail list logo
