On Mon, 23 Apr 2012 16:51:06 +0200, Daniel Vetter
wrote:
> We kzalloc dev_priv, and we never use hws_map in intel_ringbuffer.c.
>
> Signed-Off-by: Daniel Vetter
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_
On Mon, 23 Apr 2012 16:51:02 +0200, Daniel Vetter
wrote:
> Wohoo!
>
> Now we only need to move all the gem/kms stuff that accidentally
> landed in i915_dma.c out of it, and this will be our legacy dri1
> grave-yard.
>
> Signed-off-by: Daniel Vetter
Reviewed-by: Chris Wilson
-Chris
--
Chris
On Mon, 23 Apr 2012 16:51:01 +0200, Daniel Vetter
wrote:
> ... and hide it in i915_dma.c.
>
> This way all the legacy stuff dealing with READ_BREADCRUMB and
> LP_RING and friends is in i915_dma.c.
>
> Signed-off-by: Daniel Vetter
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open
On Mon, 23 Apr 2012 16:51:00 +0200, Daniel Vetter
wrote:
> Let's just get this out of the way.
>
> Signed-off-by: Daniel Vetter
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-g
On Mon, 23 Apr 2012 16:50:59 +0200, Daniel Vetter
wrote:
> We never supported dri1 on gen5+.
>
> VLV never had that code, so no need to remove it.
>
> Signed-off-by: Daniel Vetter
Reviewed-by: Chris Wilson
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_
On Mon, 23 Apr 2012 16:50:58 +0200, Daniel Vetter
wrote:
> This is a pretty racy way to close these races, and we have
> much better means to cope with these races meanwhile: For
> non-broken userspace we correctly wait for any outstanding
> rendering, for broken userspace the hangcheck will save
On Mon, 23 Apr 2012 16:50:57 +0200, Daniel Vetter
wrote:
> The LP refers to 'low priority' as opposed to the high priority
> ring on gen2/3. So lets constrain its use to the code of that era.
>
> Unfortunately we can't yet completely remove the associated
> macros from common headers and shove t
On Mon, 23 Apr 2012 16:50:52 +0200, Daniel Vetter
wrote:
> Calling these when gem assumes full control of the hw won't end
> in anything else than tears. So be a bit more paranoid here.
>
> Just serves as documentation.
>
> Signed-off-by: Daniel Vetter
Having already killed do_init, I can't a
On Mon, 23 Apr 2012 16:50:51 +0200, Daniel Vetter
wrote:
> Always true these days. It has been added originally to work
> around some issues with the agp layer in 2.6.29:
>
> commit ac5c4e76180a74c7f922f6fa71ace0cef45fa433
> Author: Dave Airlie
> Date: Fri Dec 19 15:38:34 2008 +1000
>
>
On Mon, 23 Apr 2012 16:50:50 +0200, Daniel Vetter
wrote:
> We always set it so there's no point in checking. We could
> instead add a bit that tells us whether gem is actually
> initialized (i.e. either kms or gem_init_ioctl called), but
> that's imho not worth it.
>
> So just rip it out.
>
> T
On Mon, 23 Apr 2012 16:50:49 +0200, Daniel Vetter
wrote:
> This ioctl used in a kms driver is only useful to create massive
> havoc.
If used this would have rewritten existing and active PTEs. I would
probably go with ENODEV rather than EINVAL though.
Reviewed-by: Chris Wilson
-Chris
--
Chris
On Mon, 23 Apr 2012 16:50:48 +0200, Daniel Vetter
wrote:
> Also ditch the cargo-culted dev_priv checks - either we have a
> giant hole in our setup code or this is useless. Plainly bogus
> to check for it in either case.
>
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/intel_displ
On Fri, Apr 20, 2012 at 05:11:53PM +0100, Chris Wilson wrote:
> From: Jesse Barnes
>
> PCH PLLs aren't required for outputs on the CPU, so we shouldn't just
> treat them as part of the pipe.
>
> So split the code out and manage PCH PLLs separately, allocating them
> when needed or trying to re-u
On Mon, Apr 23, 2012 at 10:59, Eugeni Dodonov wrote:
> On Fri, Apr 20, 2012 at 13:11, Chris Wilson wrote:
>
>> From: Jesse Barnes
>>
>> PCH PLLs aren't required for outputs on the CPU, so we shouldn't just
>> treat them as part of the pipe.
>>
>> So split the code out and manage PCH PLLs separat
On Fri, 20 Apr 2012 17:11:53 +0100
Chris Wilson wrote:
> From: Jesse Barnes
>
> PCH PLLs aren't required for outputs on the CPU, so we shouldn't just
> treat them as part of the pipe.
>
> So split the code out and manage PCH PLLs separately, allocating them
> when needed or trying to re-use ex
On Sun, Apr 22, 2012 at 09:13:57PM +0100, Chris Wilson wrote:
> gen2 hardware has some significant differences from the other interrupt
> routines that were glossed over and then forgotten about in the
> transition to KMS. Such as
>
> - 16bit IIR
> - PendingFlip status bit
>
> This patch reintrod
On Mon, Apr 23, 2012 at 09:18:25AM +0100, Chris Wilson wrote:
> On Mon, 23 Apr 2012 04:06:41 -0400, Xi Wang wrote:
> > On 32-bit systems, a large args->buffer_count from userspace via ioctl
> > may overflow the allocation size, leading to out-of-bounds access.
> >
> > This vulnerability was intro
On 04/23/2012 05:56 PM, Daniel Vetter wrote:
On Mon, Apr 23, 2012 at 05:38:27PM +0200, Carsten Emde wrote:
On 04/23/2012 05:22 PM, Daniel Vetter wrote:
On Mon, Apr 23, 2012 at 05:06:53PM +0200, Carsten Emde wrote:
On 04/23/2012 04:22 PM, Daniel Vetter wrote:
On Mon, Apr 23, 2012 at 04:00:23PM
Because this is the place where we actually use the results of
them.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_dma.c | 112 --
drivers/gpu/drm/i915/intel_pm.c | 113 +++
2 files changed, 113 insertions(+),
Two things:
- ring->virtual start is an __iomem pointer, treat it accordingly.
- dev_priv->status_page.page_addr is now always a cpu addr, no pointer
casting needed for that.
Take the opportunity to remove the unnecessary drm indirection when
setting up the ringbuffer iomapping.
Signed-off-by:
To get the fun stuff out of the way, the legacy hws is allocated by
userspace when the gpu needs a gfx hws. And there's no reference-counting
going on, so userspace can simply screw everyone over.
At least it's not as horrible as i810, where the ringbuffer is allocated
by userspace ...
We can't f
We kzalloc dev_priv, and we never use hws_map in intel_ringbuffer.c.
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_ringbuffer.c |5 -
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuf
They're now in intel_pm.c, so group them a bit better.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_drv.h |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index b5f5181..09541a6 100
Unfortunately there has been dri1 userspace that used gem to manage
the gtt and hence also needed cliprects in the execbuf ioctl. So
we can't ever remove that code without breaking the ioctl abi.
But at least we can disable it on gen5+, because these horrible
versions of mesa have not supported th
We now have a nice home for power management code, so let's use it!
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_dma.c | 472 +-
drivers/gpu/drm/i915/intel_drv.h |3 +
drivers/gpu/drm/i915/intel_pm.c | 478
Wohoo!
Now we only need to move all the gem/kms stuff that accidentally
landed in i915_dma.c out of it, and this will be our legacy dri1
grave-yard.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_dma.c | 26 ++
drivers/gpu/drm/i915/i915_drv.h
... and hide it in i915_dma.c.
This way all the legacy stuff dealing with READ_BREADCRUMB and
LP_RING and friends is in i915_dma.c.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_dma.c | 13 +
drivers/gpu/drm/i915/i915_drv.h |1 +
drivers/gpu/drm/i915/i915_irq.c |
Let's just get this out of the way.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_dma.c | 110 +++
drivers/gpu/drm/i915/i915_drv.h |4 --
drivers/gpu/drm/i915/i915_irq.c | 110 ---
3 files changed, 110 ins
We never supported dri1 on gen5+.
VLV never had that code, so no need to remove it.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_irq.c | 16
1 files changed, 0 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i9
This is a pretty racy way to close these races, and we have
much better means to cope with these races meanwhile: For
non-broken userspace we correctly wait for any outstanding
rendering, for broken userspace the hangcheck will save the
day.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/
The LP refers to 'low priority' as opposed to the high priority
ring on gen2/3. So lets constrain its use to the code of that era.
Unfortunately we can't yet completely remove the associated
macros from common headers and shove them into i915_dma.c to
the other dri1 legacy support code, a few clea
Assigned in setparam, used never.
I didn't bother to dig through the archives to figure out what
this was supposed to do.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_dma.c |1 -
drivers/gpu/drm/i915/i915_drv.h |1 -
2 files changed, 0 insertions(+), 2 deletions(-)
diff -
Even the horrible gen3 XvMC code has learned to do this
right by the time xf86-video-intel releases learned to do
kernel modesetting. So we can just disallow this.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_dma.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
di
... and shove allow_batchbuffer in there. More dragons will
follow suit.
There's the curious case that we allow this for KMS ...
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_dma.c | 10 +-
drivers/gpu/drm/i915/i915_drv.h | 11 ++-
2 files changed, 15 insertions
i915_dma.c contains most of the old dri1 horror-show, so move
the remaining bits there, too. The code has been removed and
the only thing left are some stubs to ensure that userspace
doesn't try to use this stuff. vblank_pipe_set only returns 0
without any side-effects, so we can even stub it out w
Calling these when gem assumes full control of the hw won't end
in anything else than tears. So be a bit more paranoid here.
Just serves as documentation.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_dma.c | 18 ++
drivers/gpu/drm/i915/i915_irq.c | 12 +
Always true these days. It has been added originally to work
around some issues with the agp layer in 2.6.29:
commit ac5c4e76180a74c7f922f6fa71ace0cef45fa433
Author: Dave Airlie
Date: Fri Dec 19 15:38:34 2008 +1000
drm/i915: GEM on PAE has problems - disable it for now.
Signed-Off-by: Dan
We always set it so there's no point in checking. We could
instead add a bit that tells us whether gem is actually
initialized (i.e. either kms or gem_init_ioctl called), but
that's imho not worth it.
So just rip it out.
There's a little change in the wait_ring timeout, but we've never
run with a
This ioctl used in a kms driver is only useful to create massive
havoc.
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_gem.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 38490cd..787
Also ditch the cargo-culted dev_priv checks - either we have a
giant hole in our setup code or this is useless. Plainly bogus
to check for it in either case.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c |3 +++
drivers/gpu/drm/i915/intel_overlay.c | 12
Hi all,
So I got a bit bored over the w/e and decided to take my broadsword and dwell a
bit in the dri1 dragon dungeon. The big battle I've lost is against the
cliprects stuff, we can't rip that out because dri1 userspace using gem depends
upon that. DRI1 userspace using gem ...
Otherwise my jour
On Mon, Apr 23, 2012 at 05:38:27PM +0200, Carsten Emde wrote:
> On 04/23/2012 05:22 PM, Daniel Vetter wrote:
> >On Mon, Apr 23, 2012 at 05:06:53PM +0200, Carsten Emde wrote:
> >>On 04/23/2012 04:22 PM, Daniel Vetter wrote:
> >>>On Mon, Apr 23, 2012 at 04:00:23PM +0200, Carsten Emde wrote:
> >>> [..
On 04/23/2012 05:22 PM, Daniel Vetter wrote:
On Mon, Apr 23, 2012 at 05:06:53PM +0200, Carsten Emde wrote:
On 04/23/2012 04:22 PM, Daniel Vetter wrote:
On Mon, Apr 23, 2012 at 04:00:23PM +0200, Carsten Emde wrote:
[..]
The idea was to boot with kms and see whether any of these values would
res
On Sun, 22 Apr 2012 14:45:13 +0200
Daniel Vetter wrote:
> On Fri, Apr 20, 2012 at 06:23:31PM -0700, Ben Widawsky wrote:
> > Finally we can use the new timed seqno waiting function to allow
> > userspace to wait on a request with a timeout. This implements that
> > interface.
> >
> > The new ioct
On Mon, Apr 23, 2012 at 05:06:53PM +0200, Carsten Emde wrote:
> On 04/23/2012 04:22 PM, Daniel Vetter wrote:
> >On Mon, Apr 23, 2012 at 04:00:23PM +0200, Carsten Emde wrote:
> >># intel_reg_write 0x61250 0x8000
> >>Value before: 0xE000
> >>Value after: 0x8000
> >># intel_reg_read 0x6125
On 04/23/2012 04:22 PM, Daniel Vetter wrote:
On Mon, Apr 23, 2012 at 04:00:23PM +0200, Carsten Emde wrote:
# intel_reg_write 0x61250 0x8000
Value before: 0xE000
Value after: 0x8000
# intel_reg_read 0x61254
0x61254 : 0xB4A0B4A
# intel_reg_write 0x61250 0xa000
Value before: 0x8000
On Mon, Apr 23, 2012 at 04:00:23PM +0200, Carsten Emde wrote:
> # intel_reg_write 0x61250 0x8000
> Value before: 0xE000
> Value after: 0x8000
> # intel_reg_read 0x61254
> 0x61254 : 0xB4A0B4A
>
> # intel_reg_write 0x61250 0xa000
> Value before: 0x8000
> Value after: 0xA000
>
On 04/23/2012 03:39 PM, Daniel Vetter wrote:
On Mon, Apr 23, 2012 at 03:15:02PM +0200, Carsten Emde wrote:
On 04/23/2012 02:36 PM, Daniel Vetter wrote:
On Mon, Apr 23, 2012 at 02:32:57PM +0200, Daniel Vetter wrote:
On Mon, Apr 23, 2012 at 01:54:23PM +0200, Carsten Emde wrote:
On 04/23/2012 11
On Fri, Apr 20, 2012 at 13:11, Chris Wilson wrote:
> From: Jesse Barnes
>
> PCH PLLs aren't required for outputs on the CPU, so we shouldn't just
> treat them as part of the pipe.
>
> So split the code out and manage PCH PLLs separately, allocating them
> when needed or trying to re-use existing
On Mon, Apr 23, 2012 at 01:32:31PM +0100, Chris Wilson wrote:
> On Mon, 23 Apr 2012 14:21:20 +0200, Daniel Vetter wrote:
> > On my specs bit29 is pipe assignement, we should set it if the panel is on
> > pipe B (well, it just takes the pll to do the modulation from that pipe
> > then).
>
> On CTL
On Mon, Apr 23, 2012 at 03:15:02PM +0200, Carsten Emde wrote:
> On 04/23/2012 02:36 PM, Daniel Vetter wrote:
> >On Mon, Apr 23, 2012 at 02:32:57PM +0200, Daniel Vetter wrote:
> >>On Mon, Apr 23, 2012 at 01:54:23PM +0200, Carsten Emde wrote:
> >>>On 04/23/2012 11:32 AM, Daniel Vetter wrote:
> Th
On 04/23/2012 02:36 PM, Daniel Vetter wrote:
On Mon, Apr 23, 2012 at 02:32:57PM +0200, Daniel Vetter wrote:
On Mon, Apr 23, 2012 at 01:54:23PM +0200, Carsten Emde wrote:
On 04/23/2012 11:32 AM, Daniel Vetter wrote:
There's a bit in the docs for gen4 only that says whether the
backlight control
On Mon, Apr 23, 2012 at 02:32:57PM +0200, Daniel Vetter wrote:
> On Mon, Apr 23, 2012 at 01:54:23PM +0200, Carsten Emde wrote:
> > On 04/23/2012 11:32 AM, Daniel Vetter wrote:
> > >There's a bit in the docs for gen4 only that says whether the
> > >backlight control is inverted. And both the quirk w
On Mon, 23 Apr 2012 14:21:20 +0200, Daniel Vetter wrote:
> On my specs bit29 is pipe assignement, we should set it if the panel is on
> pipe B (well, it just takes the pll to do the modulation from that pipe
> then).
On CTL1 rather than CTL2, if that makes a difference. Listed in both the
IBX and
On Mon, Apr 23, 2012 at 01:54:23PM +0200, Carsten Emde wrote:
> On 04/23/2012 11:32 AM, Daniel Vetter wrote:
> >There's a bit in the docs for gen4 only that says whether the
> >backlight control is inverted. And both the quirk we have and
> >all bugs only concern i965gm and gm45 (and mostly Acer) a
On Mon, Apr 23, 2012 at 10:53:31AM +0100, Chris Wilson wrote:
> On Mon, 23 Apr 2012 11:32:14 +0200, Daniel Vetter
> wrote:
> > There's a bit in the docs for gen4 only that says whether the
> > backlight control is inverted. And both the quirk we have and
> > all bugs only concern i965gm and gm45
On Mon, 23 Apr 2012 11:32:15 +0200, Daniel Vetter
wrote:
> So let's use it.
>
> We already correctly ignore bit0 on gen < 4, now we also now why ;-)
> I've decided that losing that single bit of precision isn't worth the
> trouble to sprinkle IS_PINEVIEW checks all over the backlight control
> c
On Mon, 23 Apr 2012 11:32:14 +0200, Daniel Vetter
wrote:
> There's a bit in the docs for gen4 only that says whether the
> backlight control is inverted. And both the quirk we have and
> all bugs only concern i965gm and gm45 (and mostly Acer) afaics.
>
> So lets drop the quirk and use the bit in
So let's use it.
We already correctly ignore bit0 on gen < 4, now we also now why ;-)
I've decided that losing that single bit of precision isn't worth the
trouble to sprinkle IS_PINEVIEW checks all over the backlight control
code - that code is way too fragile imo.
Cc: Chris Wilson
Signed-Off-b
There's a bit in the docs for gen4 only that says whether the
backlight control is inverted. And both the quirk we have and
all bugs only concern i965gm and gm45 (and mostly Acer) afaics.
So lets drop the quirk and use the bit instead.
Also clean up the BLC register definitions a bit by correctly
On Mon, 23 Apr 2012 04:06:42 -0400, Xi Wang wrote:
> On 32-bit systems, a large args->num_cliprects from userspace via ioctl
> may overflow the allocation size, leading to out-of-bounds access.
>
> This vulnerability was introduced in commit 432e58ed ("drm/i915: Avoid
> allocation for execbuffer
On Mon, 23 Apr 2012 04:06:41 -0400, Xi Wang wrote:
> On 32-bit systems, a large args->buffer_count from userspace via ioctl
> may overflow the allocation size, leading to out-of-bounds access.
>
> This vulnerability was introduced in commit 8408c282 ("drm/i915:
> First try a normal large kmalloc
Okay, I'm just going to write mail to you for that issue.
Thanks
--Yi Sun
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
> Sent: Monday, April 23, 2012 3:39 PM
> To: Intel Graphics Development; Sun, Yi
> Subject: Re: Updated -nex
On Sat, Apr 21, 2012 at 06:40:32PM +0200, Daniel Vetter wrote:
> Hi all,
>
> Highlights:
> - More gmbus patches from Daniel Kurtz, I think gmbus is now ready, all
> known issues fixed.
> - Fencing cleanup and pipelined fencing removal from Chris.
> - rc6 residency interface from Ben, useful for
On Sun, Apr 22, 2012 at 07:57:33PM -0700, Ben Widawsky wrote:
> On Sun, 22 Apr 2012 18:39:23 +0100
> Chris Wilson wrote:
>
> > On Sun, 22 Apr 2012 10:35:29 -0700, Ben Widawsky
> > wrote:
> > > On Sun, 22 Apr 2012 16:49:53 +0100
> > > Chris Wilson wrote:
> > >
> > > > On Fri, 20 Apr 2012 11:50:
The libva driver for Intel doesn't support GM35.
Thanks
Haihao
> Howdy,
>
> Xorg says:
> [ 36196.880] (II) Loading /usr/lib/xorg/modules/drivers/intel_drv.so
> [ 36196.880] drmOpenDevice: node name is /dev/dri/card0
> [ 36196.880] drmOpenDevice: open result is 9, (OK)
> [ 36196.880] drmOpenByBu
66 matches
Mail list logo
