The following changes since commit cd97824994042b809493807ea644ba26c0c23290:
Linus Torvalds (1):
Merge git://git.kernel.org/.../davem/net-2.6
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel drm-intel-next
A few miscellaneous fixes. The 965 tiling one fixes breakage exposed by
the current 2D driver when we fixed performance for 2D rendering on KMS
(factor of 3 win).
Eric Anholt (1):
drm/i915: Don't let an oops get triggered from irq_emit without dma init.
Jesse Barnes (1):
drm/i915: allow tiled front buffers on 965+
Keith Packard (1):
drm/i915: fix transition to I915_TILING_NONE
Matthew Garrett (3):
drm/i915: Register ACPI video even when not modesetting
drm/i915: Unregister ACPI video driver when exiting
drm/i915: Enable ASLE if present
drivers/acpi/video.c | 3 ++-
drivers/gpu/drm/i915/i915_dma.c | 2 +-
drivers/gpu/drm/i915/i915_drv.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h | 4 ++--
drivers/gpu/drm/i915/i915_gem_tiling.c | 1 -
drivers/gpu/drm/i915/i915_irq.c | 2 +-
drivers/gpu/drm/i915/i915_opregion.c | 15 ++++++++++-----
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_display.c | 9 +++++++++
include/acpi/video.h | 2 ++
10 files changed, 29 insertions(+), 12 deletions(-)
--
Eric Anholt
[email protected] [email protected]
From: Eric Anholt <[email protected]>
Date: Fri, 17 Apr 2009 13:49:59 -0700
> git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel drm-intel-next
Eric, any plans to ever push your work through David Airlie's DRM
tree? I've been watching this for a few weeks and I'm mystified why
the Intel DRM drier stuff is so special that is always goes seperate.
It's seems foolish for David to manage the infrastructure and core DRM
changes, as well as those for radeon and the other drivers other than
Intel, which could potentially cause merge issues and conflicts with
your driver changes.
Why not do Intel DRM driver development via his tree? I just don't
get it. :-/
On Sat, 2009-04-18 at 01:59 -0700, David Miller wrote:
> From: Eric Anholt <[email protected]>
> Date: Fri, 17 Apr 2009 13:49:59 -0700
>
> > git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel drm-intel-next
>
> Eric, any plans to ever push your work through David Airlie's DRM
> tree? I've been watching this for a few weeks and I'm mystified why
> the Intel DRM drier stuff is so special that is always goes seperate.
>
> It's seems foolish for David to manage the infrastructure and core DRM
> changes, as well as those for radeon and the other drivers other than
> Intel, which could potentially cause merge issues and conflicts with
> your driver changes.
>
> Why not do Intel DRM driver development via his tree? I just don't
> get it. :-/
Inside of the merge window, I am going through Dave again because he
requested it (though delays meant that I didn't get a major cleanup in
this merge window). However, Dave is also quite busy, and not stealing
his time every few days to pull my tree for just forwarding bugfixes on
seems to be a win.
--
Eric Anholt
[email protected] [email protected]
From: Eric Anholt <[email protected]>
Date: Sat, 18 Apr 2009 13:23:36 -0700
> On Sat, 2009-04-18 at 01:59 -0700, David Miller wrote:
>> Eric, any plans to ever push your work through David Airlie's DRM
>> tree? I've been watching this for a few weeks and I'm mystified why
>> the Intel DRM drier stuff is so special that is always goes seperate.
>>
>> It's seems foolish for David to manage the infrastructure and core DRM
>> changes, as well as those for radeon and the other drivers other than
>> Intel, which could potentially cause merge issues and conflicts with
>> your driver changes.
>>
>> Why not do Intel DRM driver development via his tree? I just don't
>> get it. :-/
>
> Inside of the merge window, I am going through Dave again because he
> requested it (though delays meant that I didn't get a major cleanup in
> this merge window). However, Dave is also quite busy, and not stealing
> his time every few days to pull my tree for just forwarding bugfixes on
> seems to be a win.
So you're essentially claiming that Dave isn't being a responsive
enough maintainer of the DRM subsystem?
> > On Sat, 2009-04-18 at 01:59 -0700, David Miller wrote:
> >> Eric, any plans to ever push your work through David Airlie's DRM
> >> tree? I've been watching this for a few weeks and I'm mystified why
> >> the Intel DRM drier stuff is so special that is always goes seperate.
> >>
> >> It's seems foolish for David to manage the infrastructure and core DRM
> >> changes, as well as those for radeon and the other drivers other than
> >> Intel, which could potentially cause merge issues and conflicts with
> >> your driver changes.
> >>
> >> Why not do Intel DRM driver development via his tree? I just don't
> >> get it. :-/
> >
> > Inside of the merge window, I am going through Dave again because he
> > requested it (though delays meant that I didn't get a major cleanup in
> > this merge window). However, Dave is also quite busy, and not stealing
> > his time every few days to pull my tree for just forwarding bugfixes on
> > seems to be a win.
>
> So you're essentially claiming that Dave isn't being a responsive
> enough maintainer of the DRM subsystem?
I'd believe that, its never been the primary focus of my job, the thing is
the kernel portion of the stuff we work is still quite miniscule compare
to the time it takes to maintain all the userspace bits we also take care
off, so I still end up with 3-4 hrs a week max to do DRM maintainer jobs,
this works out okay when we have merge windows and I can plan for it, but
when Eric has a lot of fixes outside of merge windows I do get in the way.
The thing is the situation really hasn't changed in the 3-4 years I've
done this, nobody want this job, Eric could probably do it, but when the
work balance moves over to merging AMD or nvidia code and fixes, which
will be happening at some point soon, I'd suspect he'd have an equally bad time
justifying the time to the managers in Intel.
So yes at the moment outside of merge windows having Eric request pulls
direct is fine as a) he generally only has non-conflicting Intel code, b)
we don't normally have much other driver changes outside the merge window,
For the merge window I really have to make him go via me as generally we
end up with a lot more conflicts.
Maybe I can talk Eric into co-maintainers job :)
Dave.
On Sun, Apr 19, 2009 at 6:23 AM, Eric Anholt <[email protected]> wrote:
> On Sat, 2009-04-18 at 01:59 -0700, David Miller wrote:
>> From: Eric Anholt <[email protected]>
>> Date: Fri, 17 Apr 2009 13:49:59 -0700
>>
>> > ? git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel drm-intel-next
>>
>> Eric, any plans to ever push your work through David Airlie's DRM
>> tree? ?I've been watching this for a few weeks and I'm mystified why
>> the Intel DRM drier stuff is so special that is always goes seperate.
>>
>> It's seems foolish for David to manage the infrastructure and core DRM
>> changes, as well as those for radeon and the other drivers other than
>> Intel, which could potentially cause merge issues and conflicts with
>> your driver changes.
>>
>> Why not do Intel DRM driver development via his tree? ?I just don't
>> get it. :-/
>
> Inside of the merge window, I am going through Dave again because he
> requested it (though delays meant that I didn't get a major cleanup in
> this merge window). ?However, Dave is also quite busy, and not stealing
> his time every few days to pull my tree for just forwarding bugfixes on
> seems to be a win.
btw which cleanup, I seem to remember it arriving after the merge
window had opened.
The theory is the code was in my tree before Linus opened the window
or it doesn't
get merged.
Dave.
>
> --
> Eric Anholt
> [email protected] ? ? ? ? ? ? ? ? ? ? ? ? [email protected]
>
>
>
On Sun, 2009-04-19 at 16:47 +1000, Dave Airlie wrote:
> On Sun, Apr 19, 2009 at 6:23 AM, Eric Anholt <[email protected]> wrote:
> > On Sat, 2009-04-18 at 01:59 -0700, David Miller wrote:
> >> From: Eric Anholt <[email protected]>
> >> Date: Fri, 17 Apr 2009 13:49:59 -0700
> >>
> >> > git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel drm-intel-next
> >>
> >> Eric, any plans to ever push your work through David Airlie's DRM
> >> tree? I've been watching this for a few weeks and I'm mystified why
> >> the Intel DRM drier stuff is so special that is always goes seperate.
> >>
> >> It's seems foolish for David to manage the infrastructure and core DRM
> >> changes, as well as those for radeon and the other drivers other than
> >> Intel, which could potentially cause merge issues and conflicts with
> >> your driver changes.
> >>
> >> Why not do Intel DRM driver development via his tree? I just don't
> >> get it. :-/
> >
> > Inside of the merge window, I am going through Dave again because he
> > requested it (though delays meant that I didn't get a major cleanup in
> > this merge window). However, Dave is also quite busy, and not stealing
> > his time every few days to pull my tree for just forwarding bugfixes on
> > seems to be a win.
>
> btw which cleanup, I seem to remember it arriving after the merge
> window had opened.
>
> The theory is the code was in my tree before Linus opened the window
> or it doesn't
> get
Yeah, it was early merge window iirc, the mechanical
drm_malloc/drm_calloc/drm_free nuke. It really needs to die. In a
fire.
--
Eric Anholt
[email protected] [email protected]