This patch touches few drivers subsystems, they are added to the CC list.
Thanks,
Rakib
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110524/188e6fed/attachment.htm>
On Tuesday 2011-05-24 20:48, eschvoca wrote:
>On Tue, May 24, 2011 at 1:41 PM, Linus Torvalds wrote:
>>
>> It's not about features. It hasn't been about features for forever.
>
>Using the date also clearly communicates it is not about features.
On the contrary: Whenever a 2.6.x release was set ou
Hi,
2011/5/24 Lisa Milne :
>> So I'm toying with 3.0 (and in that case, it really would be "3.0",
>> not "3.0.0" - the stable team would get the third digit rather than
>> the fourth one.
>
> How about stardates?
This is a wonderful idea! :)
> That'd make a release made now 64860.8
>
> I really
On Tue, 24 May 2011 14:30:59 +0200, Jacek Luczak said:
> 2011/5/24 Jan Engelhardt :
> > On Tuesday 2011-05-24 01:33, Linus Torvalds wrote:
> >
> >>Another advantage of switching numbering models (ie 3.0 instead of
> >>2.8.x) would be that it would also make the "odd numbers are also
> >>numbers" tr
Allows us to use the 3D engine for memory management
and allows us to use vram beyond the BAR aperture.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/cayman_blit_shaders.c | 326 -
drivers/gpu/drm/radeon/cayman_blit_shaders.h |3 +
drivers/gpu/drm/radeon/evergreen_b
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/evergreen_blit_kms.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen_blit_kms.c
b/drivers/gpu/drm/radeon/evergreen_blit_kms.c
index ba06a69..4086729 100644
--- a/drivers/gpu
how about 3.0 be the
release where we re-sync the syscall numbers on all the archs? ;)
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110524/975148ab/attachment-0001.pgp>
Linus Torvalds wrote:
> PS. The voices in my head also tell me that the numbers are getting
> too big. I may just call the thing 2.8.0. And I almost guarantee that
> this PS is going to result in more discussion than the rest, but when
> the voices tell me to do things, I listen.
Correct :)
I wou
From: Dave Airlie
I forgot about the special uv handling code for this, so this
patch fixes it up.
Signed-off-by: Dave Airlie
---
arch/x86/kernel/apic/x2apic_uv_x.c |8
drivers/pci/pci.c |4 ++--
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/a
On 23.05.2011 13:33, Linus Torvalds wrote:
> On Mon, May 23, 2011 at 12:20 PM, Ingo Molnar wrote:
> >
> > I really hope there's also a voice that tells you to wait until .42 before
> > cutting 3.0.0! :-)
>
> So I'm toying with 3.0 (and in that case, it really would be "3.0",
> not "3.0.0" - the s
On Tuesday 2011-05-24 17:46, Ralf Baechle wrote:
>On Tue, May 24, 2011 at 03:43:48PM +0100, Alan Cox wrote:
>
>> Can we drop most of MCA, EISA and ISA bus if we are going to have a big
>> version change ? A driver spring clean is much overdue and it's all in
>> git in case someone wishes to sneak
On Sun, May 22, 2011 at 6:15 PM, Dee Sharpe
wrote:
> Hello all,
>
> I'm not sure that this is really the appropriate place to pose this
> question; but, I was wondering how GLX Visuals are created internally. What
> info does a video driver give that allows the XServer & also GLX to
> configure a
On 05/23/2011 04:33 PM, Linus Torvalds wrote:
> On Mon, May 23, 2011 at 12:20 PM, Ingo Molnar wrote:
>>
>> I really hope there's also a voice that tells you to wait until .42 before
>> cutting 3.0.0! :-)
>
> So I'm toying with 3.0 (and in that case, it really would be "3.0",
> not "3.0.0" - the st
On Tue, May 24, 2011 at 03:43:48PM +0100, Alan Cox wrote:
> Can we drop most of MCA, EISA and ISA bus if we are going to have a big
> version change ? A driver spring clean is much overdue and it's all in
> git in case someone wishes to sneak out at midnight and bring some crawly
> horror back fro
On Mon, May 23, 2011 at 07:17:21PM -0400, Ted Ts'o wrote:
> > So I'm toying with 3.0 (and in that case, it really would be "3.0",
> > not "3.0.0" - the stable team would get the third digit rather than
> > the fourth one.
>
> If we change from 2.6.X to 3.X, then if we don't change anything else,
Can we drop most of MCA, EISA and ISA bus if we are going to have a big
version change ? A driver spring clean is much overdue and it's all in
git in case someone wishes to sneak out at midnight and bring some crawly
horror back from the dead.
Alan
> If we change from 2.6.X to 3.X, then if we don't change anything else,
> then successive stable release will cause the LINUX_VERSION_CODE to be
> incremented. This isn't necessary bad, but it would be a different
> from what we have now.
I think I prefer 3 digits. Otherwise we will have to pass
2011/5/24 Jan Engelhardt :
> On Tuesday 2011-05-24 14:30, Jacek Luczak wrote:
>
>>2011/5/24 Jan Engelhardt :
>>> On Tuesday 2011-05-24 01:33, Linus Torvalds wrote:
>>>
Another advantage of switching numbering models (ie 3.0 instead of
2.8.x) would be that it would also make the "odd numbers
https://bugs.freedesktop.org/show_bug.cgi?id=28125
--- Comment #4 from ajax at nwnk dot net 2011-05-24 15:02:46
PDT ---
Patch posted:
http://lists.freedesktop.org/archives/mesa-dev/2011-May/007789.html
A less robust version was tested by the reporter on IRC.
--
Configure bugmail: https://bug
https://bugs.freedesktop.org/show_bug.cgi?id=28125
--- Comment #4 from ajax at nwnk dot net 2011-05-24 15:02:46
PDT ---
Patch posted:
http://lists.freedesktop.org/archives/mesa-dev/2011-May/007789.html
A less robust version was tested by the reporter on IRC.
--
Configure bugmail: https://bug
On Tuesday 2011-05-24 14:30, Jacek Luczak wrote:
>2011/5/24 Jan Engelhardt :
>> On Tuesday 2011-05-24 01:33, Linus Torvalds wrote:
>>
>>>Another advantage of switching numbering models (ie 3.0 instead of
>>>2.8.x) would be that it would also make the "odd numbers are also
>>>numbers" transition mu
On Tue, May 24, 2011 at 1:41 PM, Linus Torvalds
wrote:
> On Tue, May 24, 2011 at 10:36 AM, H. Peter Anvin wrote:
>>
>> I think this whole discussion misses the essence of the new development
>> model, which is that we no longer do these kinds of feature-based major
>> milestones.
>
> Indeed.
>
>
https://bugs.freedesktop.org/show_bug.cgi?id=37490
--- Comment #15 from William Pitcock 2011-05-24
14:32:50 PDT ---
(In reply to comment #14)
> (In reply to comment #13)
> > i don't know, and my concern is mostly with the non-gallium driver right
> > now.
> >
> > i can test the gallium driver,
https://bugs.freedesktop.org/show_bug.cgi?id=37490
--- Comment #15 from William Pitcock 2011-05-24
14:32:50 PDT ---
(In reply to comment #14)
> (In reply to comment #13)
> > i don't know, and my concern is mostly with the non-gallium driver right
> > now.
> >
> > i can test the gallium driver,
2011/5/24 Jan Engelhardt :
> On Tuesday 2011-05-24 01:33, Linus Torvalds wrote:
>
>>Another advantage of switching numbering models (ie 3.0 instead of
>>2.8.x) would be that it would also make the "odd numbers are also
>>numbers" transition much more natural.
>>
>>Because of our historical even/odd
On 05/23/2011 04:33 PM, Linus Torvalds wrote:
On Mon, May 23, 2011 at 12:20 PM, Ingo Molnar wrote:
I really hope there's also a voice that tells you to wait until .42 before
cutting 3.0.0! :-)
So I'm toying with 3.0 (and in that case, it really would be "3.0",
not "3.0.0" - the stable team w
https://bugs.freedesktop.org/show_bug.cgi?id=37490
--- Comment #14 from Alex Deucher 2011-05-24 14:19:34 PDT ---
(In reply to comment #13)
> i don't know, and my concern is mostly with the non-gallium driver right now.
>
> i can test the gallium driver, but i need the normal driver to work as i
https://bugs.freedesktop.org/show_bug.cgi?id=37490
--- Comment #14 from Alex Deucher 2011-05-24 14:19:34 PDT
---
(In reply to comment #13)
> i don't know, and my concern is mostly with the non-gallium driver right now.
>
> i can test the gallium driver, but i need the normal driver to work as i
On Tuesday 2011-05-24 01:33, Linus Torvalds wrote:
>Another advantage of switching numbering models (ie 3.0 instead of
>2.8.x) would be that it would also make the "odd numbers are also
>numbers" transition much more natural.
>
>Because of our historical even/odd model, I wouldn't do a 2.7.x -
>th
https://bugs.freedesktop.org/show_bug.cgi?id=37490
--- Comment #13 from William Pitcock 2011-05-24
13:34:59 PDT ---
i don't know, and my concern is mostly with the non-gallium driver right now.
i can test the gallium driver, but i need the normal driver to work as i have
32-bit applications i a
https://bugs.freedesktop.org/show_bug.cgi?id=37490
--- Comment #13 from William Pitcock 2011-05-24
13:34:59 PDT ---
i don't know, and my concern is mostly with the non-gallium driver right now.
i can test the gallium driver, but i need the normal driver to work as i have
32-bit applications i a
https://bugs.freedesktop.org/show_bug.cgi?id=35434
--- Comment #13 from Sven Arvidsson 2011-05-24 13:12:43 PDT ---
(In reply to comment #12)
>
> You are right, ETQW is too slow to move the mouse.
Yeah, that sounds about right for software rendering :)
--
Configure bugmail: https://bugs.freede
https://bugs.freedesktop.org/show_bug.cgi?id=35434
--- Comment #13 from Sven Arvidsson 2011-05-24 13:12:43 PDT ---
(In reply to comment #12)
>
> You are right, ETQW is too slow to move the mouse.
Yeah, that sounds about right for software rendering :)
--
Configure bugmail: https://bugs.freede
https://bugs.freedesktop.org/show_bug.cgi?id=35434
--- Comment #12 from Benjamin Bellec 2011-05-24 13:10:52
PDT ---
(In reply to comment #11)
> (In reply to comment #10)
> > In fact, I have these 2 issues also with gallium-swrast.
>
> I just tried ETQW with llvmpipe and it's rendering correctly
https://bugs.freedesktop.org/show_bug.cgi?id=35434
--- Comment #12 from Benjamin Bellec 2011-05-24
13:10:52 PDT ---
(In reply to comment #11)
> (In reply to comment #10)
> > In fact, I have these 2 issues also with gallium-swrast.
>
> I just tried ETQW with llvmpipe and it's rendering correctly
https://bugs.freedesktop.org/show_bug.cgi?id=35434
--- Comment #11 from Sven Arvidsson 2011-05-24 12:30:03 PDT ---
(In reply to comment #10)
> In fact, I have these 2 issues also with gallium-swrast.
I just tried ETQW with llvmpipe and it's rendering correctly.
Can you confirm that you're getti
https://bugs.freedesktop.org/show_bug.cgi?id=35434
--- Comment #11 from Sven Arvidsson 2011-05-24 12:30:03 PDT ---
(In reply to comment #10)
> In fact, I have these 2 issues also with gallium-swrast.
I just tried ETQW with llvmpipe and it's rendering correctly.
Can you confirm that you're getti
On 24 May 2011 12:02, Andy Lutomirski wrote:
> On 05/17/2011 07:27 AM, Daniel J Blueman wrote:
>> With 2.6.39-rc7 on my Sandy Bridge laptop GPU (8086:0126 rev 9),
>> sometimes I find one of the kworker threads busily running with 15-20%
>> system time for some minutes, causing terrible interactivi
On Tue, 24 May 2011, Matthias Schniedermeyer wrote:
> On 23.05.2011 13:33, Linus Torvalds wrote:
>> On Mon, May 23, 2011 at 12:20 PM, Ingo Molnar wrote:
>>>
>>> I really hope there's also a voice that tells you to wait until .42 before
>>> cutting 3.0.0! :-)
>>
>> So I'm toying with 3.0 (and in t
On 17 May 2011 12:27, Daniel J Blueman wrote:
> With 2.6.39-rc7 on my Sandy Bridge laptop GPU (8086:0126 rev 9),
> sometimes I find one of the kworker threads busily running with 15-20%
> system time for some minutes, causing terrible interactivity latency.
> I've seen it occur when plugging eg a
On Tue, May 24, 2011 at 10:43 AM, Alan Cox wrote:
> Can we drop most of MCA, EISA and ISA bus if we are going to have a big
> version change ? A driver spring clean is much overdue and it's all in
> git in case someone wishes to sneak out at midnight and bring some crawly
> horror back from the de
https://bugs.freedesktop.org/show_bug.cgi?id=37253
Benoit Jacob changed:
What|Removed |Added
Component|Drivers/Gallium/r600|Mesa core
AssignedTo|dri-devel@li
https://bugs.freedesktop.org/show_bug.cgi?id=37253
Benoit Jacob changed:
What|Removed |Added
CC||pavel.ondra...@email.cz
--- Comment #4 fr
Hi Linus,
core: updates for 30-bit color
intel: Ivybridge support + hopeful rc6 support
nouveau: rewritten engine support for adding PCOPY engine
radeon: Displayport overhaul for pending Llano APU along with more cayman
and fusion fixes.
There is also a platform/x86 driver for the MXM GPU stand
https://bugs.freedesktop.org/show_bug.cgi?id=37253
Benoit Jacob changed:
What|Removed |Added
Component|Drivers/Gallium/r600|Mesa core
AssignedTo|dri-devel at
https://bugs.freedesktop.org/show_bug.cgi?id=37253
Benoit Jacob changed:
What|Removed |Added
CC||pavel.ondracka at email.cz
--- Comment #4
https://bugs.freedesktop.org/show_bug.cgi?id=37253
--- Comment #3 from Sven Arvidsson 2011-05-24 10:48:14 PDT ---
(In reply to comment #2)
> Close the other one as duplicate of this one (despite anachronism) ?
That's probably a good idea. You could also reassign this bug to component
"Mesa core"
https://bugs.freedesktop.org/show_bug.cgi?id=37253
--- Comment #3 from Sven Arvidsson 2011-05-24 10:48:14 PDT ---
(In reply to comment #2)
> Close the other one as duplicate of this one (despite anachronism) ?
That's probably a good idea. You could also reassign this bug to component
"Mesa core"
On Tue, May 24, 2011 at 10:36 AM, H. Peter Anvin wrote:
>
> I think this whole discussion misses the essence of the new development
> model, which is that we no longer do these kinds of feature-based major
> milestones.
Indeed.
It's not about features. It hasn't been about features for forever.
On Tue, May 24, 2011 at 10:36 AM, H. Peter Anvin wrote:
>
> I think this whole discussion misses the essence of the new development
> model, which is that we no longer do these kinds of feature-based major
> milestones.
Indeed.
It's not about features. It hasn't been about features for forever.
On 05/24/2011 08:07 AM, jonsm...@gmail.com wrote:
> On Tue, May 24, 2011 at 10:43 AM, Alan Cox wrote:
>> Can we drop most of MCA, EISA and ISA bus if we are going to have a big
>> version change ? A driver spring clean is much overdue and it's all in
>> git in case someone wishes to sneak out at m
On 05/24/2011 08:07 AM, jonsmirl at gmail.com wrote:
> On Tue, May 24, 2011 at 10:43 AM, Alan Cox
> wrote:
>> Can we drop most of MCA, EISA and ISA bus if we are going to have a big
>> version change ? A driver spring clean is much overdue and it's all in
>> git in case someone wishes to sneak ou
https://bugs.freedesktop.org/show_bug.cgi?id=28125
Marc Gariépy changed:
What|Removed |Added
CC||mgari...@ubuntu.com
See Also|
On Tuesday 24 May 2011, Linus Torvalds wrote:
> Another advantage of switching numbering models (ie 3.0 instead of
> 2.8.x) would be that it would also make the "odd numbers are also
> numbers" transition much more natural.
>
> Because of our historical even/odd model, I wouldn't do a 2.7.x -
> th
https://bugs.freedesktop.org/show_bug.cgi?id=28125
Marc Gari?py changed:
What|Removed |Added
CC||mgariepy at ubuntu.com
See Also
Hi Yermandu,
Please pay attention when writing and proofread yourself before
sending. You certainly meant i915, not i195, in the subject line. I've
fixed it. This is important if you want to get the attention of the
relevant maintainers and developers.
On Mon, 23 May 2011 19:33:15 -0300, Yermandu
On Sun, May 22, 2011 at 6:15 PM, Dee Sharpe
wrote:
> Hello all,
>
> I'm not sure that this is really the appropriate place to pose this
> question; but, I was wondering how GLX Visuals are created internally. What
> info does a video driver give that allows the XServer & also GLX to
> configure a
https://bugs.freedesktop.org/show_bug.cgi?id=37490
--- Comment #12 from Michel Dänzer 2011-05-24 08:43:15 PDT
---
Could be a mipmap generation issue then. Is it still broken with r600g from
upstream Git master?
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
---
https://bugs.freedesktop.org/show_bug.cgi?id=37490
--- Comment #12 from Michel D?nzer 2011-05-24 08:43:15
PDT ---
Could be a mipmap generation issue then. Is it still broken with r600g from
upstream Git master?
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
---
https://bugs.freedesktop.org/show_bug.cgi?id=37490
Michel Dänzer changed:
What|Removed |Added
Attachment #47089|text/x-log |text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=37490
Michel D?nzer changed:
What|Removed |Added
Attachment #47089|text/x-log |text/plain
mime type|
On Tue, May 24, 2011 at 10:43 AM, Alan Cox wrote:
> Can we drop most of MCA, EISA and ISA bus if we are going to have a big
> version change ? A driver spring clean is much overdue and it's all in
> git in case someone wishes to sneak out at midnight and bring some crawly
> horror back from the de
Can we drop most of MCA, EISA and ISA bus if we are going to have a big
version change ? A driver spring clean is much overdue and it's all in
git in case someone wishes to sneak out at midnight and bring some crawly
horror back from the dead.
Alan
___
d
> If we change from 2.6.X to 3.X, then if we don't change anything else,
> then successive stable release will cause the LINUX_VERSION_CODE to be
> incremented. This isn't necessary bad, but it would be a different
> from what we have now.
I think I prefer 3 digits. Otherwise we will have to pass
2011/5/24 Jan Engelhardt :
> On Tuesday 2011-05-24 14:30, Jacek Luczak wrote:
>
>>2011/5/24 Jan Engelhardt :
>>> On Tuesday 2011-05-24 01:33, Linus Torvalds wrote:
>>>
Another advantage of switching numbering models (ie 3.0 instead of
2.8.x) would be that it would also make the "odd numbers
On Tuesday 2011-05-24 14:30, Jacek Luczak wrote:
>2011/5/24 Jan Engelhardt :
>> On Tuesday 2011-05-24 01:33, Linus Torvalds wrote:
>>
>>>Another advantage of switching numbering models (ie 3.0 instead of
>>>2.8.x) would be that it would also make the "odd numbers are also
>>>numbers" transition mu
2011/5/24 Jan Engelhardt :
> On Tuesday 2011-05-24 01:33, Linus Torvalds wrote:
>
>>Another advantage of switching numbering models (ie 3.0 instead of
>>2.8.x) would be that it would also make the "odd numbers are also
>>numbers" transition much more natural.
>>
>>Because of our historical even/odd
On Tuesday 2011-05-24 01:33, Linus Torvalds wrote:
>Another advantage of switching numbering models (ie 3.0 instead of
>2.8.x) would be that it would also make the "odd numbers are also
>numbers" transition much more natural.
>
>Because of our historical even/odd model, I wouldn't do a 2.7.x -
>th
On Mon, May 23, 2011 at 03:21:21PM -0700, Greg KH wrote:
> On Mon, May 23, 2011 at 01:33:48PM -0700, Linus Torvalds wrote:
> > On Mon, May 23, 2011 at 12:20 PM, Ingo Molnar wrote:
> > > I really hope there's also a voice that tells you to wait until .42 before
> > > cutting 3.0.0! :-)
> >
> > So
On Mon, May 23, 2011 at 01:33:48PM -0700, Linus Torvalds wrote:
> On Mon, May 23, 2011 at 12:20 PM, Ingo Molnar wrote:
> >
> > I really hope there's also a voice that tells you to wait until .42 before
> > cutting 3.0.0! :-)
>
> So I'm toying with 3.0 (and in that case, it really would be "3.0",
On 5/23/11, Linus Torvalds wrote:
> On Mon, May 23, 2011 at 12:20 PM, Ingo Molnar wrote:
>>
>> I really hope there's also a voice that tells you to wait until .42 before
>> cutting 3.0.0! :-)
I think, the best time for this, after reorganize the ARM arch folder / tree.
>
> So I'm toying with 3.
On Mon, May 23, 2011 at 01:21:26PM -0700, Randy Dunlap wrote:
>
> They tell him to avoid the question to which 42 is the answer.
What 2.6 Linux kernel version was the last before 3.0?
-- Steve
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
On Tue, May 24, 2011 at 00:33, Linus Torvalds
wrote:
> On Mon, May 23, 2011 at 12:20 PM, Ingo Molnar wrote:
>>
>> I really hope there's also a voice that tells you to wait until .42 before
>> cutting 3.0.0! :-)
>
> So I'm toying with 3.0 (and in that case, it really would be "3.0",
> not "3.0.0"
On Mon, 2011-05-23 at 12:22 -0700, Greg KH wrote:
> On Mon, May 23, 2011 at 12:13:29PM -0700, Linus Torvalds wrote:
> > PS. The voices in my head also tell me that the numbers are getting
> > too big. I may just call the thing 2.8.0. And I almost guarantee that
> > this PS is going to result in mor
On Mon, 23 May 2011, Linus Torvalds wrote:
> PS. The voices in my head also tell me that the numbers are getting
> too big. I may just call the thing 2.8.0. And I almost guarantee that
> this PS is going to result in more discussion than the rest, but when
> the voices tell me to do things, I liste
On 05/17/2011 07:27 AM, Daniel J Blueman wrote:
> With 2.6.39-rc7 on my Sandy Bridge laptop GPU (8086:0126 rev 9),
> sometimes I find one of the kworker threads busily running with 15-20%
> system time for some minutes, causing terrible interactivity latency.
> I've seen it occur when plugging eg a
On 24 May 2011 12:02, Andy Lutomirski wrote:
> On 05/17/2011 07:27 AM, Daniel J Blueman wrote:
>> With 2.6.39-rc7 on my Sandy Bridge laptop GPU (8086:0126 rev 9),
>> sometimes I find one of the kworker threads busily running with 15-20%
>> system time for some minutes, causing terrible interactivi
* Linus Torvalds wrote:
> On Mon, May 23, 2011 at 12:20 PM, Ingo Molnar wrote:
> >
> > I really hope there's also a voice that tells you to wait until .42 before
> > cutting 3.0.0! :-)
>
> So I'm toying with 3.0 (and in that case, it really would be "3.0",
> not "3.0.0" - the stable team would
On 05/17/2011 07:27 AM, Daniel J Blueman wrote:
> With 2.6.39-rc7 on my Sandy Bridge laptop GPU (8086:0126 rev 9),
> sometimes I find one of the kworker threads busily running with 15-20%
> system time for some minutes, causing terrible interactivity latency.
> I've seen it occur when plugging eg a
* Linus Torvalds wrote:
> Another advantage of switching numbering models (ie 3.0 instead of
> 2.8.x) would be that it would also make the "odd numbers are also
> numbers" transition much more natural.
Yeah, it sounds really good to get rid of the (meanwhile) meaningless
"2.6." prefix from our
On 17 May 2011 12:27, Daniel J Blueman wrote:
> With 2.6.39-rc7 on my Sandy Bridge laptop GPU (8086:0126 rev 9),
> sometimes I find one of the kworker threads busily running with 15-20%
> system time for some minutes, causing terrible interactivity latency.
> I've seen it occur when plugging eg a
Hi Linus,
core: updates for 30-bit color
intel: Ivybridge support + hopeful rc6 support
nouveau: rewritten engine support for adding PCOPY engine
radeon: Displayport overhaul for pending Llano APU along with more cayman
and fusion fixes.
There is also a platform/x86 driver for the MXM GPU stand
On Tuesday 24 May 2011, Linus Torvalds wrote:
> Another advantage of switching numbering models (ie 3.0 instead of
> 2.8.x) would be that it would also make the "odd numbers are also
> numbers" transition much more natural.
>
> Because of our historical even/odd model, I wouldn't do a 2.7.x -
> th
On Tue, May 24, 2011 at 00:33, Linus Torvalds
wrote:
> On Mon, May 23, 2011 at 12:20 PM, Ingo Molnar wrote:
>>
>> I really hope there's also a voice that tells you to wait until .42 before
>> cutting 3.0.0! :-)
>
> So I'm toying with 3.0 (and in that case, it really would be "3.0",
> not "3.0.0"
Hi Yermandu,
Please pay attention when writing and proofread yourself before
sending. You certainly meant i915, not i195, in the subject line. I've
fixed it. This is important if you want to get the attention of the
relevant maintainers and developers.
On Mon, 23 May 2011 19:33:15 -0300, Yermandu
On Mon, 2011-05-23 at 12:22 -0700, Greg KH wrote:
> On Mon, May 23, 2011 at 12:13:29PM -0700, Linus Torvalds wrote:
> > PS. The voices in my head also tell me that the numbers are getting
> > too big. I may just call the thing 2.8.0. And I almost guarantee that
> > this PS is going to result in mor
86 matches
Mail list logo
