Steve Langasek came over today and we hacked on the i915 driver
initialization code to try and avoid the initial mode set. I thought I'd
summarize what we found out.
* Ubuntu has hacked up grub2 so that it gets the boot monitor running
in a reasonable configuration using VBE calls if possib
On Fri, 28 Oct 2011 22:55:26 -0700, Ben Widawsky wrote:
> These patches are pretty raw as I'm hoping to get some comments before
> working to hard too clean them up. The goal is GPU fairness for clients
> running on i915.
The biggest danger I see is that num_outstanding is only decremented
in ret
On Sat, 29 Oct 2011 00:05:22 -0700, "Keith Packard" wrote:
> * Constructing a fake drm_framebuffer is a pain; there are a million
> places that assume all kinds of things about the frame buffer on
> a crtc.
This is vital as we need to capture the current GATT and stolen allocations
and
On Fri, Oct 28, 2011 at 10:55:27PM -0700, Ben Widawsky wrote:
> There is already a list of requests outstanding for a given client.
> Keeping a count is easy, and will give some information necessary to
> enable a more fair throttling scheme.
>
> For now a client is uniquely identified by its file
Hi all!
I'm trying to setup some strange LCD display which supports only one
mode 1920x480@61Hz. It works with old IEGD drivers, but not with
xf86-video-intel 2.15.0. After some changes to source code I'm able to
force the proper resolution, but there is still nothing on the screen.
Is th
On Sat, 29 Oct 2011 09:07:35 +0100, Chris Wilson
wrote:
> On Fri, 28 Oct 2011 22:55:26 -0700, Ben Widawsky wrote:
> > These patches are pretty raw as I'm hoping to get some comments before
> > working to hard too clean them up. The goal is GPU fairness for clients
> > running on i915.
>
> The b
On Sat, 29 Oct 2011 11:45:34 -0700
Eric Anholt wrote:
> On Sat, 29 Oct 2011 09:07:35 +0100, Chris Wilson
> wrote:
> > On Fri, 28 Oct 2011 22:55:26 -0700, Ben Widawsky wrote:
> > > These patches are pretty raw as I'm hoping to get some comments before
> > > working to hard too clean them up. Th
On Sat, 29 Oct 2011 09:07:35 +0100
Chris Wilson wrote:
> On Fri, 28 Oct 2011 22:55:26 -0700, Ben Widawsky wrote:
> > These patches are pretty raw as I'm hoping to get some comments before
> > working to hard too clean them up. The goal is GPU fairness for clients
> > running on i915.
>
> The bi
On Sat, 29 Oct 2011 11:35:13 +0200
Daniel Vetter wrote:
> On Fri, Oct 28, 2011 at 10:55:27PM -0700, Ben Widawsky wrote:
> > There is already a list of requests outstanding for a given client.
> > Keeping a count is easy, and will give some information necessary to
> > enable a more fair throttlin
On Sat, Oct 29, 2011 at 12:22:25PM -0700, Ben Widawsky wrote:
> On Sat, 29 Oct 2011 11:45:34 -0700
> Eric Anholt wrote:
>
> > On Sat, 29 Oct 2011 09:07:35 +0100, Chris Wilson
> > wrote:
> > > On Fri, 28 Oct 2011 22:55:26 -0700, Ben Widawsky
> > > wrote:
> > > > These patches are pretty raw as
On Sat, Oct 29, 2011 at 09:40:57PM +0200, Daniel Vetter wrote:
> On Sat, Oct 29, 2011 at 12:22:25PM -0700, Ben Widawsky wrote:
> > On Sat, 29 Oct 2011 11:45:34 -0700
> > Eric Anholt wrote:
> >
> > > On Sat, 29 Oct 2011 09:07:35 +0100, Chris Wilson
> > > wrote:
> > > > On Fri, 28 Oct 2011 22:55:
On Sat, 29 Oct 2011 21:47:04 +0200
Daniel Vetter wrote:
> On Sat, Oct 29, 2011 at 09:40:57PM +0200, Daniel Vetter wrote:
> > On Sat, Oct 29, 2011 at 12:22:25PM -0700, Ben Widawsky wrote:
> > > On Sat, 29 Oct 2011 11:45:34 -0700
> > > Eric Anholt wrote:
> > >
> > > > On Sat, 29 Oct 2011 09:07:35
On Fri, Oct 28, 2011 at 15:56, Keith Packard wrote:
> Kernels with no iommu support cannot ever need the Ironlake
> work-around, so never enable it in that case.
>
> Might be better to completely remove the work-around from the kernel
> in this case?
>
> Signed-off-by: Keith Packard
> Cc: Ben Wi
On Sat, 29 Oct 2011 09:12:13 +0100, Chris Wilson
wrote:
> On Sat, 29 Oct 2011 00:05:22 -0700, "Keith Packard" wrote:
> > * Constructing a fake drm_framebuffer is a pain; there are a million
> > places that assume all kinds of things about the frame buffer on
> > a crtc.
>
> This is vi
After the ILK vt-d workaround patches it became clear that we had
introduced a bug. Chris tracked down the issue to recursive calls to
unmap. This happens because we try to optimize waiting on requests by
calling retire requests after the wait, which may drop the last
reference on an object and en
On Sat, 29 Oct 2011 19:07:23 -0700, Ben Widawsky wrote:
> + /**
> + * Flag if GTT ptes shouldn't be modified.
> + *
> + * This is set when graphics virtual address space
> + * should not be changed. It's currently only useful for
> +
On Sat, 29 Oct 2011 19:51:26 -0700
Keith Packard wrote:
> On Sat, 29 Oct 2011 19:07:23 -0700, Ben Widawsky wrote:
>
> > + /**
> > +* Flag if GTT ptes shouldn't be modified.
> > +*
> > +* This is set when graphics virtual address space
> > +
On Sat, 29 Oct 2011 19:56:43 -0700, Ben Widawsky wrote:
> Sigh. I started down that path, but it was becoming tedious with only
> one case where we actually want to not retire (I think), so I thought
> I'd see how this went down on the mailing list.
I don't even want to think about locking for t
On Sat, 29 Oct 2011 00:05:22 -0700, "Keith Packard" wrote:
> * I've got LVDS pulling the current mode out of the hardware
With a machine that has a native VBE mode for the panel, the problem is
that clock computed from the hardware settings is not quite the same as
the clock requested in the m
19 matches
Mail list logo
