[git pull] Fixes to 2.6.30rc2

[git pull] Fixes to 2.6.30rc2

[Eric Anholt]

[-- Attachment #1: Type: text/plain, Size: 1557 bytes --]

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
eric@anholt.net                         eric.anholt@intel.com



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [git pull] Fixes to 2.6.30rc2

[David Miller]

From: Eric Anholt <eric@anholt.net>
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. :-/

Re: [git pull] Fixes to 2.6.30rc2

[Eric Anholt]

[-- Attachment #1: Type: text/plain, Size: 1177 bytes --]

On Sat, 2009-04-18 at 01:59 -0700, David Miller wrote:
> From: Eric Anholt <eric@anholt.net>
> 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
eric@anholt.net                         eric.anholt@intel.com



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [git pull] Fixes to 2.6.30rc2

[David Miller]

From: Eric Anholt <eric@anholt.net>
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?

Re: [git pull] Fixes to 2.6.30rc2

[Dave Airlie]

> > 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.

Re: [git pull] Fixes to 2.6.30rc2

[Dave Airlie]

On Sun, Apr 19, 2009 at 6:23 AM, Eric Anholt <eric@anholt.net> wrote:
> On Sat, 2009-04-18 at 01:59 -0700, David Miller wrote:
>> From: Eric Anholt <eric@anholt.net>
>> 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
> eric@anholt.net                         eric.anholt@intel.com
>
>
>

Re: [git pull] Fixes to 2.6.30rc2

[Eric Anholt]

[-- Attachment #1: Type: text/plain, Size: 1704 bytes --]

On Sun, 2009-04-19 at 16:47 +1000, Dave Airlie wrote:
> On Sun, Apr 19, 2009 at 6:23 AM, Eric Anholt <eric@anholt.net> wrote:
> > On Sat, 2009-04-18 at 01:59 -0700, David Miller wrote:
> >> From: Eric Anholt <eric@anholt.net>
> >> 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
eric@anholt.net                         eric.anholt@intel.com



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]