[PATCH 00/24] MacBook Air patch sequence (v2)

2011-10-11 Thread Chris Wilson 
On Thu, 29 Sep 2011 18:09:32 -0700, Keith Packard  wrote:
> Ok, so I've split all of the changes into bite-sized pieces so that
> they should make sense individually now. I've also added the same
> asynchronous power control to the panel power, this reduces the
> module load time down to about 700ms on my MacBook Air, which is
> pretty nice.
> 
> Given the length of the series, I don't think this should all land in
> 3.1, however I'd like opinions on whether I should push this subset,
> which makes the MacBook Air work, into drm-intel-fixes and send that
> along.

I can confirm that these indeed make the MBA (this one at least!) work,
but I don't have any other eDP device with which to cross-check.

Tested-by: Chris Wilson 
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

Re: [PATCH 00/24] MacBook Air patch sequence (v2)

2011-10-11 Thread Chris Wilson 
On Thu, 29 Sep 2011 18:09:32 -0700, Keith Packard kei...@keithp.com wrote:
 Ok, so I've split all of the changes into bite-sized pieces so that
 they should make sense individually now. I've also added the same
 asynchronous power control to the panel power, this reduces the
 module load time down to about 700ms on my MacBook Air, which is
 pretty nice.
 
 Given the length of the series, I don't think this should all land in
 3.1, however I'd like opinions on whether I should push this subset,
 which makes the MacBook Air work, into drm-intel-fixes and send that
 along.

I can confirm that these indeed make the MBA (this one at least!) work,
but I don't have any other eDP device with which to cross-check.

Tested-by: Chris Wilson ch...@chris-wilson.co.uk
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Intel-gfx] [PATCH 00/24] MacBook Air patch sequence (v2)

2011-10-03 Thread Jesse Barnes 
On Fri, 30 Sep 2011 11:17:38 -0700
Keith Packard  wrote:

> On Fri, 30 Sep 2011 09:20:55 -0400, Ted Ts'o  wrote:
> 
> > What kind of battery life do you get with these patches applied, out
> > of curiosity?
> 
> 4-5 hours when doing the usual web-surfing, etc. Seems pretty much the
> same as people are getting under Mac OS.

As long as you enable RC6. :)

-- 
Jesse Barnes, Intel Open Source Technology Center

Re: [PATCH 00/24] MacBook Air patch sequence (v2)

2011-10-01 Thread Ted Ts'o 
On Thu, Sep 29, 2011 at 08:33:56PM -0700, Greg KH wrote:
 I'm all for enabling new hardware like this, and overall, the patches
 aren't that bad, just want to verify this.
 
 And, I do have to tell you, curses, now I have no excuse to not buy
 that laptop!

What kind of battery life do you get with these patches applied, out
of curiosity?

Darn it, I have a Macbook Air, but I use it for media consumption
purposes.  This would be a great temption to get a second one as a
Linux box...

- Ted
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 00/24] MacBook Air patch sequence (v2)

2011-09-30 Thread Keith Packard 
On Fri, 30 Sep 2011 09:20:55 -0400, Ted Ts'o  wrote:

> What kind of battery life do you get with these patches applied, out
> of curiosity?

4-5 hours when doing the usual web-surfing, etc. Seems pretty much the
same as people are getting under Mac OS.

-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:

[PATCH 00/24] MacBook Air patch sequence (v2)

2011-09-30 Thread Keith Packard 
On Fri, 30 Sep 2011 06:57:05 -0700, Greg KH  wrote:

> No, actually this makes it easier for -stable as each individual patch
> fixes a problem, so in re-reading them, I have no objection for them to
> go into -stable.

Ok, cool. Splitting these up was a pain.

> Would these also work on 3.0?

They won't apply cleanly, but yes, they should be useful there.

> > I'd rather have a 'regular' PC; getting Debian installed on this machine
> > was no picnic.
> 
> Due to UEFI stuff?  Or something else?

UEFI, the lack of CD booting, and the general 'Steve knows best'
attitude of the hardware.

> I agree, it is a very nice hardware form factor that no other
> manufacturer can seem to duplicate for the same (well, any) price these
> days.

Yeah, PC vendors clearly aren't making hardware for us anymore.

-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:

[PATCH 00/24] MacBook Air patch sequence (v2)

2011-09-30 Thread Ted Ts'o 
On Thu, Sep 29, 2011 at 08:33:56PM -0700, Greg KH wrote:
> I'm all for enabling new hardware like this, and overall, the patches
> aren't that bad, just want to verify this.
> 
> And, I do have to tell you, "curses, now I have no excuse to not buy
> that laptop!"

What kind of battery life do you get with these patches applied, out
of curiosity?

Darn it, I have a Macbook Air, but I use it for media consumption
purposes.  This would be a great temption to get a second one as a
Linux box...

- Ted

[PATCH 00/24] MacBook Air patch sequence (v2)

2011-09-30 Thread Greg KH 
On Fri, Sep 30, 2011 at 01:58:29AM -0700, Keith Packard wrote:
> On Thu, 29 Sep 2011 20:33:56 -0700, Greg KH  wrote:
> 
> > Are these really all -stable material?
> 
> I think just the sequence that actually makes the machine work; the
> scarier patches are those which reduce the mode setting time from 5-10s
> down to .7s.
> 
> Is this stretching the bounds of what is acceptable for -stable? Would
> it look better as a single patch, instead of 14 separate ones?

No, actually this makes it easier for -stable as each individual patch
fixes a problem, so in re-reading them, I have no objection for them to
go into -stable.

Would these also work on 3.0?

> > I'm all for enabling new hardware like this, and overall, the patches
> > aren't that bad, just want to verify this.
> 
> Let me know what you think; they'll be queued for 3.2 once they've
> gotten review and (I hope) more testing. It's Jesse's fault there are
> so many little patches; he asked me to split things up into separate
> functional changes. It's either that, or I'm just looking to increase
> the number of patches I have in the kernel.
> 
> > And, I do have to tell you, "curses, now I have no excuse to not buy
> > that laptop!"
> 
> I'd rather have a 'regular' PC; getting Debian installed on this machine
> was no picnic.

Due to UEFI stuff?  Or something else?

> But, I haven't seen anything else in this form factor that includes a
> display port connector.

I agree, it is a very nice hardware form factor that no other
manufacturer can seem to duplicate for the same (well, any) price these
days.

greg k-h

[PATCH 00/24] MacBook Air patch sequence (v2)

2011-09-30 Thread Keith Packard 
On Thu, 29 Sep 2011 20:33:56 -0700, Greg KH  wrote:

> Are these really all -stable material?

I think just the sequence that actually makes the machine work; the
scarier patches are those which reduce the mode setting time from 5-10s
down to .7s.

Is this stretching the bounds of what is acceptable for -stable? Would
it look better as a single patch, instead of 14 separate ones?

> I'm all for enabling new hardware like this, and overall, the patches
> aren't that bad, just want to verify this.

Let me know what you think; they'll be queued for 3.2 once they've
gotten review and (I hope) more testing. It's Jesse's fault there are
so many little patches; he asked me to split things up into separate
functional changes. It's either that, or I'm just looking to increase
the number of patches I have in the kernel.

> And, I do have to tell you, "curses, now I have no excuse to not buy
> that laptop!"

I'd rather have a 'regular' PC; getting Debian installed on this machine
was no picnic. But, I haven't seen anything else in this form factor
that includes a display port connector.

-- 
keith.packard at intel.com
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:

Re: [PATCH 00/24] MacBook Air patch sequence (v2)

2011-09-30 Thread Keith Packard 
On Thu, 29 Sep 2011 20:33:56 -0700, Greg KH g...@kroah.com wrote:

 Are these really all -stable material?

I think just the sequence that actually makes the machine work; the
scarier patches are those which reduce the mode setting time from 5-10s
down to .7s.

Is this stretching the bounds of what is acceptable for -stable? Would
it look better as a single patch, instead of 14 separate ones?

 I'm all for enabling new hardware like this, and overall, the patches
 aren't that bad, just want to verify this.

Let me know what you think; they'll be queued for 3.2 once they've
gotten review and (I hope) more testing. It's Jesse's fault there are
so many little patches; he asked me to split things up into separate
functional changes. It's either that, or I'm just looking to increase
the number of patches I have in the kernel.

 And, I do have to tell you, curses, now I have no excuse to not buy
 that laptop!

I'd rather have a 'regular' PC; getting Debian installed on this machine
was no picnic. But, I haven't seen anything else in this form factor
that includes a display port connector.

-- 
keith.pack...@intel.com


pgpYUA3UG6bJZ.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 00/24] MacBook Air patch sequence (v2)

2011-09-30 Thread Greg KH 
On Fri, Sep 30, 2011 at 01:58:29AM -0700, Keith Packard wrote:
 On Thu, 29 Sep 2011 20:33:56 -0700, Greg KH g...@kroah.com wrote:
 
  Are these really all -stable material?
 
 I think just the sequence that actually makes the machine work; the
 scarier patches are those which reduce the mode setting time from 5-10s
 down to .7s.
 
 Is this stretching the bounds of what is acceptable for -stable? Would
 it look better as a single patch, instead of 14 separate ones?

No, actually this makes it easier for -stable as each individual patch
fixes a problem, so in re-reading them, I have no objection for them to
go into -stable.

Would these also work on 3.0?

  I'm all for enabling new hardware like this, and overall, the patches
  aren't that bad, just want to verify this.
 
 Let me know what you think; they'll be queued for 3.2 once they've
 gotten review and (I hope) more testing. It's Jesse's fault there are
 so many little patches; he asked me to split things up into separate
 functional changes. It's either that, or I'm just looking to increase
 the number of patches I have in the kernel.
 
  And, I do have to tell you, curses, now I have no excuse to not buy
  that laptop!
 
 I'd rather have a 'regular' PC; getting Debian installed on this machine
 was no picnic.

Due to UEFI stuff?  Or something else?

 But, I haven't seen anything else in this form factor that includes a
 display port connector.

I agree, it is a very nice hardware form factor that no other
manufacturer can seem to duplicate for the same (well, any) price these
days.

greg k-h
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 00/24] MacBook Air patch sequence (v2)

2011-09-30 Thread Keith Packard 
On Fri, 30 Sep 2011 06:57:05 -0700, Greg KH g...@kroah.com wrote:

 No, actually this makes it easier for -stable as each individual patch
 fixes a problem, so in re-reading them, I have no objection for them to
 go into -stable.

Ok, cool. Splitting these up was a pain.

 Would these also work on 3.0?

They won't apply cleanly, but yes, they should be useful there.

  I'd rather have a 'regular' PC; getting Debian installed on this machine
  was no picnic.
 
 Due to UEFI stuff?  Or something else?

UEFI, the lack of CD booting, and the general 'Steve knows best'
attitude of the hardware.

 I agree, it is a very nice hardware form factor that no other
 manufacturer can seem to duplicate for the same (well, any) price these
 days.

Yeah, PC vendors clearly aren't making hardware for us anymore.

-- 
keith.pack...@intel.com


pgpbKpg5ckr3R.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 00/24] MacBook Air patch sequence (v2)

2011-09-30 Thread Keith Packard 
On Fri, 30 Sep 2011 09:20:55 -0400, Ted Ts'o ty...@mit.edu wrote:

 What kind of battery life do you get with these patches applied, out
 of curiosity?

4-5 hours when doing the usual web-surfing, etc. Seems pretty much the
same as people are getting under Mac OS.

-- 
keith.pack...@intel.com


pgpczbMwrKpO6.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 00/24] MacBook Air patch sequence (v2)

2011-09-29 Thread Greg KH 
On Thu, Sep 29, 2011 at 06:09:32PM -0700, Keith Packard wrote:
> Ok, so I've split all of the changes into bite-sized pieces so that
> they should make sense individually now. I've also added the same
> asynchronous power control to the panel power, this reduces the
> module load time down to about 700ms on my MacBook Air, which is
> pretty nice.
> 
> Given the length of the series, I don't think this should all land in
> 3.1, however I'd like opinions on whether I should push this subset,
> which makes the MacBook Air work, into drm-intel-fixes and send that
> along.
> 
>  [PATCH 01/21] drm/i915: Enable digital port hotplug on PCH systems
>  [PATCH 02/21] drm/i915: Shut down PCH interrupts during
>  [PATCH 03/21] drm/i915: Remove extra 300ms delay during eDP mode
>  [PATCH 04/21] drm/i915: Only use VBT panel mode on eDP if no EDID is
>  [PATCH 05/21] drm/i915: Check eDP power when doing aux channel
>  [PATCH 06/21] drm/i915: Unlock PCH_PP_CONTROL always
>  [PATCH 07/21] drm/i915: Check for eDP inside
>  [PATCH 08/21] drm/i915: Turn force VDD back off when panel running
>  [PATCH 09/21] drm/i915: Delay DP i2c initialization until panel
>  [PATCH 10/21] drm/i915: Wrap DP EDID fetch functions to enable eDP
>  [PATCH 11/21] drm/i915: Enable eDP panel power during I2C
>  [PATCH 12/21] drm/i915: Ensure eDP powered up during DP_SET_POWER
>  [PATCH 13/21] drm/i915: Place long delays after each eDP VDD
>  [PATCH 14/21] drm/i915: Correct eDP panel power sequencing delay
> 
> The diffstat for that sequence is:
> 
>  i915_drv.h |1 
>  i915_irq.c |   28 
>  i915_reg.h |6 +
>  intel_dp.c |  194 
> ++---
>  4 files changed, 180 insertions(+), 49 deletions(-)
> 
> This might be too big at this point in the 3.1 release, so perhaps
> just marking these with a Cc: to stable would be more appropriate.

Are these really all -stable material?

I'm all for enabling new hardware like this, and overall, the patches
aren't that bad, just want to verify this.

And, I do have to tell you, "curses, now I have no excuse to not buy
that laptop!"

greg k-h

[PATCH 00/24] MacBook Air patch sequence (v2)

2011-09-29 Thread Keith Packard 
Ok, so I've split all of the changes into bite-sized pieces so that
they should make sense individually now. I've also added the same
asynchronous power control to the panel power, this reduces the
module load time down to about 700ms on my MacBook Air, which is
pretty nice.

Given the length of the series, I don't think this should all land in
3.1, however I'd like opinions on whether I should push this subset,
which makes the MacBook Air work, into drm-intel-fixes and send that
along.

 [PATCH 01/21] drm/i915: Enable digital port hotplug on PCH systems
 [PATCH 02/21] drm/i915: Shut down PCH interrupts during
 [PATCH 03/21] drm/i915: Remove extra 300ms delay during eDP mode
 [PATCH 04/21] drm/i915: Only use VBT panel mode on eDP if no EDID is
 [PATCH 05/21] drm/i915: Check eDP power when doing aux channel
 [PATCH 06/21] drm/i915: Unlock PCH_PP_CONTROL always
 [PATCH 07/21] drm/i915: Check for eDP inside
 [PATCH 08/21] drm/i915: Turn force VDD back off when panel running
 [PATCH 09/21] drm/i915: Delay DP i2c initialization until panel
 [PATCH 10/21] drm/i915: Wrap DP EDID fetch functions to enable eDP
 [PATCH 11/21] drm/i915: Enable eDP panel power during I2C
 [PATCH 12/21] drm/i915: Ensure eDP powered up during DP_SET_POWER
 [PATCH 13/21] drm/i915: Place long delays after each eDP VDD
 [PATCH 14/21] drm/i915: Correct eDP panel power sequencing delay

The diffstat for that sequence is:

 i915_drv.h |1 
 i915_irq.c |   28 
 i915_reg.h |6 +
 intel_dp.c |  194 ++---
 4 files changed, 180 insertions(+), 49 deletions(-)

This might be too big at this point in the 3.1 release, so perhaps
just marking these with a Cc: to stable would be more appropriate.

-keith

[PATCH 00/24] MacBook Air patch sequence (v2)

2011-09-29 Thread Keith Packard 
Ok, so I've split all of the changes into bite-sized pieces so that
they should make sense individually now. I've also added the same
asynchronous power control to the panel power, this reduces the
module load time down to about 700ms on my MacBook Air, which is
pretty nice.

Given the length of the series, I don't think this should all land in
3.1, however I'd like opinions on whether I should push this subset,
which makes the MacBook Air work, into drm-intel-fixes and send that
along.

 [PATCH 01/21] drm/i915: Enable digital port hotplug on PCH systems
 [PATCH 02/21] drm/i915: Shut down PCH interrupts during
 [PATCH 03/21] drm/i915: Remove extra 300ms delay during eDP mode
 [PATCH 04/21] drm/i915: Only use VBT panel mode on eDP if no EDID is
 [PATCH 05/21] drm/i915: Check eDP power when doing aux channel
 [PATCH 06/21] drm/i915: Unlock PCH_PP_CONTROL always
 [PATCH 07/21] drm/i915: Check for eDP inside
 [PATCH 08/21] drm/i915: Turn force VDD back off when panel running
 [PATCH 09/21] drm/i915: Delay DP i2c initialization until panel
 [PATCH 10/21] drm/i915: Wrap DP EDID fetch functions to enable eDP
 [PATCH 11/21] drm/i915: Enable eDP panel power during I2C
 [PATCH 12/21] drm/i915: Ensure eDP powered up during DP_SET_POWER
 [PATCH 13/21] drm/i915: Place long delays after each eDP VDD
 [PATCH 14/21] drm/i915: Correct eDP panel power sequencing delay

The diffstat for that sequence is:

 i915_drv.h |1 
 i915_irq.c |   28 
 i915_reg.h |6 +
 intel_dp.c |  194 ++---
 4 files changed, 180 insertions(+), 49 deletions(-)

This might be too big at this point in the 3.1 release, so perhaps
just marking these with a Cc: to stable would be more appropriate.

-keith
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 00/24] MacBook Air patch sequence (v2)

2011-09-29 Thread Greg KH 
On Thu, Sep 29, 2011 at 06:09:32PM -0700, Keith Packard wrote:
 Ok, so I've split all of the changes into bite-sized pieces so that
 they should make sense individually now. I've also added the same
 asynchronous power control to the panel power, this reduces the
 module load time down to about 700ms on my MacBook Air, which is
 pretty nice.
 
 Given the length of the series, I don't think this should all land in
 3.1, however I'd like opinions on whether I should push this subset,
 which makes the MacBook Air work, into drm-intel-fixes and send that
 along.
 
  [PATCH 01/21] drm/i915: Enable digital port hotplug on PCH systems
  [PATCH 02/21] drm/i915: Shut down PCH interrupts during
  [PATCH 03/21] drm/i915: Remove extra 300ms delay during eDP mode
  [PATCH 04/21] drm/i915: Only use VBT panel mode on eDP if no EDID is
  [PATCH 05/21] drm/i915: Check eDP power when doing aux channel
  [PATCH 06/21] drm/i915: Unlock PCH_PP_CONTROL always
  [PATCH 07/21] drm/i915: Check for eDP inside
  [PATCH 08/21] drm/i915: Turn force VDD back off when panel running
  [PATCH 09/21] drm/i915: Delay DP i2c initialization until panel
  [PATCH 10/21] drm/i915: Wrap DP EDID fetch functions to enable eDP
  [PATCH 11/21] drm/i915: Enable eDP panel power during I2C
  [PATCH 12/21] drm/i915: Ensure eDP powered up during DP_SET_POWER
  [PATCH 13/21] drm/i915: Place long delays after each eDP VDD
  [PATCH 14/21] drm/i915: Correct eDP panel power sequencing delay
 
 The diffstat for that sequence is:
 
  i915_drv.h |1 
  i915_irq.c |   28 
  i915_reg.h |6 +
  intel_dp.c |  194 
 ++---
  4 files changed, 180 insertions(+), 49 deletions(-)
 
 This might be too big at this point in the 3.1 release, so perhaps
 just marking these with a Cc: to stable would be more appropriate.

Are these really all -stable material?

I'm all for enabling new hardware like this, and overall, the patches
aren't that bad, just want to verify this.

And, I do have to tell you, curses, now I have no excuse to not buy
that laptop!

greg k-h
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel