(Short?) merge window reminder
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 should sleep more... > > -- > Lisa Milne > -- > 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/ > -- Slawa! Zimny Lech z Wawelu
(Short?) merge window reminder
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" transition much more natural.
> >>
> >>Because of our historical even/odd model, I wouldn't do a 2.7.x -
> >>there's just too much history of 2.1, 2.3, 2.5 being development
> >>trees.
> >
> > .oO(Though once 2.{7 or more, odd} trickle into the distros, it would
> > become pretty much apparent that they are not devel.)
> >
> >>And then in another few years (probably before getting close to 3.40,
> >>so I'm not going to make a big deal of 3 = "third decade"), I'd just
> >>do 4.0 etc.
> >
> > While 2.6 has certainly worn out, already thinking of a 4.0 is highly
> > reminiscient of the version number arms race Firefox and ChromeBrowser
> > are doing currently.
> >
> >>Because all our releases are supposed to be stable releases these
> >>days, and if we get rid of one level of numbering, I feel perfectly
> >>fine with getting rid of the even/odd history too.
> >
> > If I remember past-time discussions right, ELF was the contributing
> > factor to bump the major number to 2.0 back then; ever since 2.0, no
> > similarly breakthrough-ing event has occurred.
>
> What then about BKL removal? Nice place to celebrate with version jump
> and heaving some beers.
Well, if we're looking at ELF-sized ABI changes, 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>
(Short?) merge window reminder
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 would still prefer the version number change to something like 2011.0 - already proposed at http://kerneltrap.org/Linux/Kernel_Release_Numbering_Redux I don't think that it is reasonable to say that it is bad because third party scripts would break - they would break anyway (I would bet that many of them don't expect to see 3.x anyway). And changing now to 3.0 and then incrementing the second one everytime for 10 years will also lead to something like 3.56.7. I would also say that defining the release number using the time of the merge window start/end is easy understandable. "2.6.40" would be the third development cycle this year aka v2011.2 or v2011.2.0 when the patchlevel should always be included. -- Emil Langrock
(Short?) merge window reminder
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 stable team would get the third digit rather than > the fourth one. What about strictly 3 part versions? Just add a .0. 3.0.0 - Release Kernel 3.0 3.0.1 - Stable 1 3.0.2 - Stable 2 3.1.0 - Release Kernel 3.1 3.1.1 - Stable 1 ... Biggest problem is likely version phobics that get pimples when they see trailing zeros. ;-) Bis denn -- Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous.
(Short?) merge window reminder
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 out at midnight and bring some crawly >> horror back from the dead. > >Dunno about MCA but I doubt we can kill all of (E)ISA. i8253, i8259 and a >few others still refuse hard to die. > >Is it worth to setup a system to track success / failure reports for >drivers and ditch drivers once there are no success reports for a driver >for too long? It may not be a good idea - people tend not report success >much more rarely than failure. > >(On that matter, I wonder if there are 5.25" USB floppy drives ...) If there were, they would appear as Mass Storage devices (at least the 3.5" USB floppy gadgets do), and as such, don't depend on ISA or the classic floppy driver at all.
How are GLX Visuals Created???
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 list of Visuals? How is this info combined & shaped into > Visuals? I'm looking specifically for functions & variables. If someone > could point me to a few files, I'd be immensely grateful! > http://cgit.freedesktop.org/xorg/xserver/tree/glx/glxscreens.c#n322 Is that what you are looking for? > -- > > Dee Sharpe > > The difference between what IS done > & ?what COULD be done is relational to > what you ARE doing& ?what you COULD be doing! > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel >
(Short?) merge window reminder
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 would get the third digit rather than > the fourth one. > > But no, it wouldn't be for 42. Despite THHGTTG, I think "40" is a > fairly nice round number. > > There's also the timing issue - since we no longer do version numbers > based on features, but based on time, just saying "we're about to > start the third decade" works as well as any other excuse. > I don't think year-based versions (like 2011.0 for the first 2011 release, or maybe 2011.5 for May 2011) are pretty, but I'll make an argument for them anyway: it makes it easier to figure out when hardware ought to be supported. So if I buy a 2014-model laptop and the coffee-making button doesn't work, and my favorite distro is running the 2013 kernel, then I know I shouldn't expect to it to work. (Graphics drivers are probably a more realistic example.) Also, when someone in my lab installs on a box that's running software I wrote that needs to support modern high-speed peripherals, then I can say "What? You seriously expect this stuff to work on Linux 2007? Let's install a slightly less stable distro from at least 2010." This sounds a lot less nerdy than "What? You seriously expect this stuff to work on Linux 2.6.27? Let's install a slightly less stable distro that uses at least 2.6.36." --Andy
(Short?) merge window reminder
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 from the dead. Dunno about MCA but I doubt we can kill all of (E)ISA. i8253, i8259 and a few others still refuse hard to die. Is it worth to setup a system to track success / failure reports for drivers and ditch drivers once there are no success reports for a driver for too long? It may not be a good idea - people tend not report success much more rarely than failure. (On that matter, I wonder if there are 5.25" USB floppy drives ...) Ralf
(Short?) merge window reminder
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, > 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. It will require another bunch of changes to scripts that try to make sense out of kernel Linux version numbers. It's a minor issue and we might be better off doing something else than version number magic. Not last a new major version number raises expectations - whatever those might be. Ralf
(Short?) merge window reminder
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
(Short?) merge window reminder
> 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 3.0, 3.1 and 3.11 all of which numbers still give older sysadmins flashbacks and will have them waking screaming in the middle of the night. Also saves breaking all the tools and assumptions people have been used to for some many years Alan
(Short?) merge window reminder
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 are also
numbers" transition much more natural.
Because of our historical even/odd model, I wouldn't do a 2.7.x -
there's just too much history of 2.1, 2.3, 2.5 being development
trees.
>>>
>>> .oO(Though once 2.{7 or more, odd} trickle into the distros, it would
>>> become pretty much apparent that they are not devel.)
>>>
And then in another few years (probably before getting close to 3.40,
so I'm not going to make a big deal of 3 = "third decade"), I'd just
do 4.0 etc.
>>>
>>> While 2.6 has certainly worn out, already thinking of a 4.0 is highly
>>> reminiscient of the version number arms race Firefox and ChromeBrowser
>>> are doing currently.
>>>
Because all our releases are supposed to be stable releases these
days, and if we get rid of one level of numbering, I feel perfectly
fine with getting rid of the even/odd history too.
>>>
>>> If I remember past-time discussions right, ELF was the contributing
>>> factor to bump the major number to 2.0 back then; ever since 2.0, no
>>> similarly breakthrough-ing event has occurred.
>>
>>What then about BKL removal? Nice place to celebrate with version jump
>>and heaving some beers.
>
> The BKL going away was not a change that would require new
> userspace programs.
True but as you I guess - kind off - notice there's no such event that
would launch fireworks and we get features smoothly. By that then we
should celebrate killing old nightmares aka BKL. It's more like - lets
not find the reason but include one just to feel better. At the end
the simplified version convention is the best reason to do this cut
off. I even plan to send a truck full of chickens to Linus if this
will convince him :) Then, while describing new kernel deployment, I
won't need to pronounce the cool sounding - ,,Mika so I've now
installed two(dot)six(dot)thirty-five(dot)forty-one(dash)one
version.''
Cheers,
-Jacek
[Bug 28125] DRI2 prevents indirect glx
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://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
(Short?) merge window reminder
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 much more natural.
>>>
>>>Because of our historical even/odd model, I wouldn't do a 2.7.x -
>>>there's just too much history of 2.1, 2.3, 2.5 being development
>>>trees.
>>
>> .oO(Though once 2.{7 or more, odd} trickle into the distros, it would
>> become pretty much apparent that they are not devel.)
>>
>>>And then in another few years (probably before getting close to 3.40,
>>>so I'm not going to make a big deal of 3 = "third decade"), I'd just
>>>do 4.0 etc.
>>
>> While 2.6 has certainly worn out, already thinking of a 4.0 is highly
>> reminiscient of the version number arms race Firefox and ChromeBrowser
>> are doing currently.
>>
>>>Because all our releases are supposed to be stable releases these
>>>days, and if we get rid of one level of numbering, I feel perfectly
>>>fine with getting rid of the even/odd history too.
>>
>> If I remember past-time discussions right, ELF was the contributing
>> factor to bump the major number to 2.0 back then; ever since 2.0, no
>> similarly breakthrough-ing event has occurred.
>
>What then about BKL removal? Nice place to celebrate with version jump
>and heaving some beers.
The BKL going away was not a change that would require new
userspace programs.
(Short?) merge window reminder
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. > > It's not about features. It hasn't been about features for forever. > > So a renumbering would be purely about dropping the numbers to > something smaller and more easily recognized. The ABI wouldn't change. > The API wouldn't change. There wouldn't be any big "because we finally > did xyz". > Me, a nobody end user, would prefer a version number that corresponded to the date. Something like: %y.%m. %Y.%m. Then users would know the significance of the number and when a vendor says they support Linux 11.09 the user will immediately know if they are up to date. Using the date also clearly communicates it is not about features. When there is a 3.0 (4.0) release people expect big new features and API/ABI breakage. My 2 cents.
[Bug 37490] texture corruption in r600/r600g when using DRI2, no texture corruption in r600 with dri1
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, but i need the normal driver to work as i > > have > > 32-bit applications i am running in a debian chroot. thusly, i do not > > really > > use the gallium driver yet... i only tested it to see if it did the same > > thing, > > which it does. > > > > the result is not the same everytime you trigger that kwin effect though; > > sometimes i get part of a console framebuffer (e.g. radeondrmfb). > > > > so would it make more sense for me to test non-gallium driver first? > > No one is really working on the non gallium driver any more, so it's not > likely > to get much more attention. well, i will try and see if r600g git master solves the problem. unfortunately, i think this means i'm screwed when it comes to running proprietary apps in chroots. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
(Short?) merge window reminder
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 model, I wouldn't do a 2.7.x -
>>there's just too much history of 2.1, 2.3, 2.5 being development
>>trees.
>
> .oO(Though once 2.{7 or more, odd} trickle into the distros, it would
> become pretty much apparent that they are not devel.)
>
>>And then in another few years (probably before getting close to 3.40,
>>so I'm not going to make a big deal of 3 = "third decade"), I'd just
>>do 4.0 etc.
>
> While 2.6 has certainly worn out, already thinking of a 4.0 is highly
> reminiscient of the version number arms race Firefox and ChromeBrowser
> are doing currently.
>
>>Because all our releases are supposed to be stable releases these
>>days, and if we get rid of one level of numbering, I feel perfectly
>>fine with getting rid of the even/odd history too.
>
> If I remember past-time discussions right, ELF was the contributing
> factor to bump the major number to 2.0 back then; ever since 2.0, no
> similarly breakthrough-ing event has occurred.
What then about BKL removal? Nice place to celebrate with version jump
and heaving some beers.
-Jacek
[Bug 37490] texture corruption in r600/r600g when using DRI2, no texture corruption in r600 with dri1
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 have > 32-bit applications i am running in a debian chroot. thusly, i do not really > use the gallium driver yet... i only tested it to see if it did the same > thing, > which it does. > > the result is not the same everytime you trigger that kwin effect though; > sometimes i get part of a console framebuffer (e.g. radeondrmfb). > > so would it make more sense for me to test non-gallium driver first? No one is really working on the non gallium driver any more, so it's not likely to get much more attention. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
(Short?) merge window reminder
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 -
>there's just too much history of 2.1, 2.3, 2.5 being development
>trees.
.oO(Though once 2.{7 or more, odd} trickle into the distros, it would
become pretty much apparent that they are not devel.)
>And then in another few years (probably before getting close to 3.40,
>so I'm not going to make a big deal of 3 = "third decade"), I'd just
>do 4.0 etc.
While 2.6 has certainly worn out, already thinking of a 4.0 is highly
reminiscient of the version number arms race Firefox and ChromeBrowser
are doing currently.
>Because all our releases are supposed to be stable releases these
>days, and if we get rid of one level of numbering, I feel perfectly
>fine with getting rid of the even/odd history too.
If I remember past-time discussions right, ELF was the contributing
factor to bump the major number to 2.0 back then; ever since 2.0, no
similarly breakthrough-ing event has occurred.
[Bug 37490] texture corruption in r600/r600g when using DRI2, no texture corruption in r600 with dri1
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 am running in a debian chroot. thusly, i do not really use the gallium driver yet... i only tested it to see if it did the same thing, which it does. the result is not the same everytime you trigger that kwin effect though; sometimes i get part of a console framebuffer (e.g. radeondrmfb). so would it make more sense for me to test non-gallium driver first? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 35434] [RADEON:KMS:R600G] etqw: broken ground textures
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.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 35434] [RADEON:KMS:R600G] etqw: broken ground textures
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. > > Can you confirm that you're getting software rendering? Check the renderer > string in glxinfo, and double check by setting LIBGL_DEBUG=verbose and check > which driver is loaded. > > If nothing else, the game should be very slow, even with a fast CPU, 4-5 fps > and a loading time of several minutes... Shame on me! ETQW has loaded r600_dri.so from /usr/local/dri (my former dri install) when I deleted it from /usr/dri ! So I believed I was on llvmpipe (Gnome 3 was in fallback-mode, and glxinfo said that too). You are right, ETQW is too slow to move the mouse. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 35434] [RADEON:KMS:R600G] etqw: broken ground textures
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 getting software rendering? Check the renderer string in glxinfo, and double check by setting LIBGL_DEBUG=verbose and check which driver is loaded. If nothing else, the game should be very slow, even with a fast CPU, 4-5 fps and a loading time of several minutes... -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[2.6.39-rc7] i915: kworker busily spinning...
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 interactivity latency. >> I've seen it occur when plugging eg a HDMI display, and also when no >> display has been plugged (ie only the internal LVDS connection is >> active). >> >> Across multiple kernel task captures, I see the kernel thread >> consistently reading one of the connector's EDID data [1]; I guess >> either it's having a hard time reading from a disconnected connector >> and retrying, or is incorrectly detecting a change when there is none. >> >> I'll enable DRM debugging to see what connectors it believes it needs >> to read from. Anything else that would be handy to capture, or any >> thoughts? >> >> Also, the 100ms connector change polling seems overkill, particularly >> when power consumption is important; 1000-2000ms would be sufficient, >> do you think? > > I think it's meant to be every 10 seconds. > > In any case, the output_poll_execute code does more work than necessary, > which might exacerbate the problem. ?Here's an old patch I wrote that > probably doesn't apply any more but might help. Thanks for the patch Andy; I'll test it after we've found a fix for the underlying issue. Daniel -- Daniel J Blueman
(Short?) merge window reminder
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 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. > > What about strictly 3 part versions? Just add a .0. > > 3.0.0 - Release Kernel 3.0 > 3.0.1 - Stable 1 > 3.0.2 - Stable 2 > 3.1.0 - Release Kernel 3.1 > 3.1.1 - Stable 1 > ... > > Biggest problem is likely version phobics that get pimples when they see > trailing zeros. ;-) since there are always issues discovered with a new kernel is released (which is why the -stable kernels exist), being wary of .0 kernels is not neccessarily a bad thing. I still think a date based approach would be the best. since people are worried about not knowing when a final release will happen, base the date on when the merge window opened or closed (always known at the time of the first -rc kernel) in the thread on lwn, people pointed out that the latest 2.6.32 kernel would still be a 2009.12.X which doesn't reflect the fact that it was released this month. My suggestion for that is to make the X be the number of months (or years.months if you don't like large month values) between the merge window and the release of the -stable release. This would lead to a small problem when there are multiple -stable releases in a month, but since that doesn't last very long I don't see a real problem with just incramenting the month into the future in those cases. David Lang
[2.6.39-rc7] i915: kworker busily spinning...
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 HDMI display, and also when no > display has been plugged (ie only the internal LVDS connection is > active). > > Across multiple kernel task captures, I see the kernel thread > consistently reading one of the connector's EDID data [1]; I guess > either it's having a hard time reading from a disconnected connector > and retrying, or is incorrectly detecting a change when there is none. > > I'll enable DRM debugging to see what connectors it believes it needs > to read from. Anything else that would be handy to capture, or any > thoughts? > > Also, the 100ms connector change polling seems overkill, particularly > when power consumption is important; 1000-2000ms would be sufficient, > do you think? > > Thanks, > ?Daniel > > --- [1] > > kworker/2:2 ? ? R ?running task ? ? 5048 ? ?86 ? ? ?2 0x > ?0002 88021e804040 88021e85f9b0 88021e804040 > ?88021e85e000 4000 8802210a4040 88021e804040 > ?0046 81c18b20 88022106c000 8270b740 > Call Trace: > ?[] ? mark_held_locks+0x70/0xa0 > ?[] ? get_parent_ip+0x11/0x50 > ?[] ? sub_preempt_count+0x9d/0xd0 > ?[] schedule_timeout+0x175/0x250 > ?[] ? run_timer_softirq+0x2a0/0x2a0 > ?[] schedule_timeout_uninterruptible+0x19/0x20 > ?[] msleep+0x18/0x20 > ?[] gmbus_xfer+0x400/0x620 [i915] > ?[] i2c_transfer+0xa2/0xf0 > ?[] drm_do_probe_ddc_edid+0x66/0xa0 [drm] > ?[] drm_get_edid+0x29/0x60 [drm] > ?[] intel_hdmi_detect+0x56/0xe0 [i915] > ?[] output_poll_execute+0xd7/0x1a0 [drm_kms_helper] > ?[] process_one_work+0x1a4/0x450 > ?[] ? process_one_work+0x146/0x450 > ?[] ? > drm_helper_disable_unused_functions+0x150/0x150 [drm_kms_helper] > ?[] process_scheduled_works+0x2c/0x40 > ?[] worker_thread+0x284/0x350 > ?[] ? manage_workers.clone.23+0x120/0x120 > ?[] kthread+0xb6/0xc0 > ?[] ? trace_hardirqs_on_caller+0x13d/0x180 > ?[] kernel_thread_helper+0x4/0x10 > ?[] ? finish_task_switch+0x6f/0x100 > ?[] ? retint_restore_args+0xe/0xe > ?[] ? __init_kthread_worker+0x70/0x70 > ?[] ? gs_change+0xb/0xb Interestingly, I appear to observe this behaviour when the laptop battery is charging. Anyway, we see continual connector update events [1], booted drm.debug=0x4. This reproduces with 2.6.39. Any thoughts? Daniel --- [1] [ 67.035097] [drm:output_poll_execute], [CONNECTOR:22:HDMI-A-2] status updated from 2 to 2 [ 67.046549] [drm:output_poll_execute], [CONNECTOR:25:HDMI-A-3] status updated from 2 to 2 [ 67.047063] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x5143003e [ 67.047065] [drm:ironlake_dp_detect], DPCD: [ 67.047066] [drm:output_poll_execute], [CONNECTOR:27:DP-2] status updated from 2 to 2 [ 67.047578] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x5143003e [ 67.047579] [drm:ironlake_dp_detect], DPCD: [ 67.047581] [drm:output_poll_execute], [CONNECTOR:30:DP-3] status updated from 2 to 2 [ 67.047588] [drm:intel_ironlake_crt_detect_hotplug], ironlake hotplug adpa=0xf4, result 0 [ 67.047591] [drm:intel_crt_detect], CRT not detected via hotplug [ 67.047593] [drm:output_poll_execute], [CONNECTOR:12:VGA-1] status updated from 2 to 2 [ 67.059062] [drm:output_poll_execute], [CONNECTOR:15:HDMI-A-1] status updated from 2 to 2 [ 67.059573] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x5143003e [ 67.059575] [drm:ironlake_dp_detect], DPCD: [ 67.059576] [drm:output_poll_execute], [CONNECTOR:18:DP-1] status updated from 2 to 2 [ 67.059886] [drm:i915_hotplug_work_func], running encoder hotplug functions <85 lines the same> [ 67.153172] [drm:i915_hotplug_work_func], running encoder hotplug functions [ 67.155109] [drm:output_poll_execute], [CONNECTOR:22:HDMI-A-2] status updated from 2 to 2 [ 67.166569] [drm:output_poll_execute], [CONNECTOR:25:HDMI-A-3] status updated from 2 to 2 [ 67.167082] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x5143003e [ 67.167084] [drm:ironlake_dp_detect], DPCD: [ 67.167086] [drm:output_poll_execute], [CONNECTOR:27:DP-2] status updated from 2 to 2 [ 67.167598] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x5143003e [ 67.167600] [drm:ironlake_dp_detect], DPCD: [ 67.167601] [drm:output_poll_execute], [CONNECTOR:30:DP-3] status updated from 2 to 2 [ 67.167608] [drm:intel_ironlake_crt_detect_hotplug], ironlake hotplug adpa=0xf4, result 0 [ 67.167610] [drm:intel_crt_detect], CRT not detected via hotplug [ 67.167612] [drm:output_poll_execute], [CONNECTOR:12:VGA-1] status updated from 2 to 2 [ 67.179051] [drm:output_poll_execute], [CONNECTOR:15:HDMI-A-1] status updated from 2 to 2 [ 67.179563] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x5143003e [ 67.179564] [drm:ironlake_dp_detect], DPCD:
(Short?) merge window reminder
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 dead. 2.8 could mark the beginning of the great cleanup --- work out the details of what needs to be cleaned and set a goal --- remove old buses/driver, switch to device tree, graphics, 32/64 merges, etc 3.0 would mark its completion -- Jon Smirl jonsmirl at gmail.com
[git pull] drm pull for gardenshed-rc1
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 standard for allowing switchable graphics support on nvidia hw, Matthew has acked it coming via my tree. Also the VGA ARB is now smarter about devices hiding behind bridges. Dave. The following changes since commit 0ee5623f9a6e52df90a78bd21179f8ab370e102e: Linux 2.6.39-rc6 (2011-05-03 19:59:13 -0700) are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-core-next Alex Deucher (31): drm/radeon/kms: remove some underscan leftovers drm/radeon/kms: add support for thermal chips on combios asics drm/radeon/kms: set i2c adapter class to I2C_CLASS_DDC drm/radeon/kms: fix up r1xx-rs4xx i2c buses drm/radeon/kms: fix some logic errors in combios i2c mapping drm/radeon/kms: DCE4.1 DIG encoders are fully routeable just like DCE3.2 drm/radeon/kms: properly handle bpc >8 in atom command tables drm/radeon/kms: spread spectrum fixes drm/radeon/kms: fix up DP clock programming on DCE4/5 drm/radeon/kms: adjust eDP handling (v2) drm/radeon/kms: fix eDP panel power function drm/radeon/kms: make sure eDP panel is on for modesetting drm/radeon/kms: add some dp encoder/connector helper funcs drm/radeon/kms: improve DP detect logic drm/radeon/kms: improve aux error handling drm/radeon/kms: handle DP bridges drm/dp: add some new DP regs for DP 1.2 drm/radeon/kms: atombios.h updates for DP panel mode drm/radeon/kms/atom: add support for setting DP panel mode drm/radeon/kms: rewrite DP handling drm/radeon/kms: simplify hotplug handler logic drm/radeon/kms: bail early for eDP in hotplug callback drm/radeon/kms: fixup eDP connector handling drm/radeon/kms: properly set the CLK_REF bit for DCE3 devices drm/radeon/kms: the SS_Id field in the LCD table if for LVDS only drm/radeon/evergreen/btc/fusion: setup hdp to invalidate and flush when asked drm/radeon/kms: fix typo in spread spectrum code drm/radeon/kms/cayman: fix typo in register mask drm/radeon/kms/atom: move dig phy init out of modesetting drm/radeon/kms: properly set num banks for fusion asics drm/radeon/kms: bump kms version number Alex Williamson (2): vga_switcheroo: Remove unbalanced pci_enable_device drm/i915/lvds: Only act on lid notify when the device is on Andrew Morton (1): drivers/gpu/drm/radeon/atom.c: fix warning Ben Skeggs (43): drm/nvc0: more vm fault engines drm/nvc0: more vm fault reasons drm/nvc0: decode gpc/hubclient on vm fault drm/nouveau: use static vidshift of 2 on volt 0x30 tables drm/nouveau: move engine object creation into per-engine hooks drm/nouveau: remove some unused members from dev_priv drm/nouveau: working towards a common way to represent engines drm/nv50/gr: move to exec engine interfaces drm/nvc0/gr: move to exec engine interfaces drm/nv40/gr: move to exec engine interfaces drm/nv20-nv30/gr: move to exec engine interface drm/nv10/gr: move to exec engine interfaces drm/nv04/gr: move to exec engine interfaces drm/nouveau: move set_tile_region to nouveau_exec_engine drm/nouveau: remove remnants of nouveau_pgraph_engine from nouveau_channel drm/nouveau: fix suspend failure path to reinitialise all engines drm/nouveau: remove remnants of nouveau_pgraph_engine drm/nva3: implement support for copy engine drm/nvc0: implement support for copy engines drm/nv40/vpe: add support for PMPEG drm/nv84: add support for PMPEG drm/nv50: rename nv84_mpeg to nv50_mpeg drm/nv50: support PMPEG on original nv50 drm/nvc0/gr: better handling of fuc firmware drm/nvc0/fifo: kick channels off during suspend drm/nvc0/fifo: restore context table on resume drm/nvc0/gr: no need to store context in graph_fini() drm/nvc0/fifo: stick user area into a gpuobj rather than a bo drm/nv40/gr: oops, fix random bits getting set in engine obj drm/nouveau: pull refclk from vbios on limits 0x40 boards drm/nva3: somewhat improve clock reporting drm/nouveau: fix uninitialised variable warning drm/nouveau: recognise DCB connector type 0x41 as LVDS drm/nv50: respect LVDS link count from EDID on SPWG panels drm/nvc0/gr: calculate some more of our magic numbers drm/nva3/pm: initial pass at set_clock() hook drm/nva3: support for memory timing map table drm/nouveau/pm: remove memtiming support check when assigning to perflvl drm/nvc0/pm: correct core/mem/shader perflvl parsing drm/nvc0/pm: parse
[Bug 37253] SIGSEGV in dri2FlushFrontBuffer/MakeContextCurrent
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 lists.freedesktop |mesa-dev at lists.freedesktop. |.org|org -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 37253] SIGSEGV in dri2FlushFrontBuffer/MakeContextCurrent
https://bugs.freedesktop.org/show_bug.cgi?id=37253 Benoit Jacob changed: What|Removed |Added CC||pavel.ondracka at email.cz --- Comment #4 from Benoit Jacob 2011-05-24 10:53:14 PDT --- *** Bug 33188 has been marked as a duplicate of this bug. *** -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 37253] SIGSEGV in dri2FlushFrontBuffer/MakeContextCurrent
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" as it isn't a problem specific to r600g. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
(Short?) merge window reminder
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. So a renumbering would be purely about dropping the numbers to something smaller and more easily recognized. The ABI wouldn't change. The API wouldn't change. There wouldn't be any big "because we finally did xyz". Linus
(Short?) merge window reminder
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 out at midnight and bring some crawly >> horror back from the dead. > > 2.8 could mark the beginning of the great cleanup > --- work out the details of what needs to be cleaned and set a goal > --- remove old buses/driver, switch to device tree, graphics, 32/64 > merges, etc > 3.0 would mark its completion > 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. If we want to to deprecate lots of drivers (which I personally would advocate against -- I have built systems specifically to run a real floppy drive since the Linux floppy driver is amazingly flexible and can read/write a lot of formats that nothing else can, including USB floppies) then we should do that in the normal course of action, incrementally, and listed in feature-removal-schedule.txt, not all at once due to some arbitrary milestone. We have found it works better this way. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf.
(Short?) merge window reminder
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 - > there's just too much history of 2.1, 2.3, 2.5 being development > trees. But if I do 3.0, then I'd be chucking that whole thing out the > window, and the next release would be 3.1, 3.2, etc.. I like that. While I don't really care if you call it 2.7, 2.8 or 3.0 (or 4.0 even, if you want to keep continuity following .38 and .39), the current 2.5/2.6 numbering cycle is almost 10 years old and has obviously lost all significance. The only reason I can see that would make it worthwhile waiting for is if the enterprise and embedded people were to decide on a common longterm kernel and call that e.g. 2.7.x or 2.8.x while you continue with 2.9.x or 3.0.x or 3.x. My impression is however that the next longterm release is still one or two years away, so probably not worth waiting for and hard to estimate in advance. > Because all our releases are supposed to be stable releases these > days, and if we get rid of one level of numbering, I feel perfectly > fine with getting rid of the even/odd history too. We still have stable and unstable releases, except that you call the unstable ones -rcX and they are all nice and short, unlike the infamous 2.1.xxx series ;-) IMHO simply changing the names from 2.6.40-rcX to 2.7.X and from 2.6.40.X to 2.6.8.X etc would be the most straightforward change if you want to save the 3.0 release for a special moment. Enough bike shedding from my side, please just make a decision. Arnd
[Bug 28125] DRI2 prevents indirect glx
https://bugs.freedesktop.org/show_bug.cgi?id=28125 Marc Gari?py changed: What|Removed |Added CC||mgariepy at ubuntu.com See Also||https://launchpad.net/bugs/ ||785368 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
i915 and boot freeze
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 Patapitafious wrote: > since kernel .39 i can not boot, when kernel go to gmbus start the issue. > I try capture a dump with kexec, but no success, so i have the idea to > make video booting, > kernel version 2.6.39-02745-g0b26d47 and 2.6.39 vanilla same problem. What is the last kernel that works for you? Are you running self-built or distribution kernels? Can we please see the kernel configuration file? You seem to have verbose debugging options enabled (CONFIG_DEBUG_KOBJECT at least.) it makes the logs harder to read. > http://www.vimeo.com/24138372 Unfortunately the beginning is pretty hard to read. It would be great if you were able to get us the kernel logs in a text form, using some form of serial console. I see references to i2c_for_each_dev, a new function which only i2c-dev and i2c-core are using at the moment. So if you have CONFIG_I2C_CHARDEV set, and this is a self-built kernel, try again without it just to get it out of the picture. Note that logs from a pure 2.6.39 kernel would probably be more useful than from a later git snapshot. The 2.6.40 development branch is very young and could have other problems. Alternatively, if you are familiar with git, a git bisection would help too. -- Jean Delvare
[Bug 37490] texture corruption in r600/r600g when using DRI2, no texture corruption in r600 with dri1
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 --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 37490] texture corruption in r600/r600g when using DRI2, no texture corruption in r600 with dri1
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|| -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[2.6.39-rc7] i915: kworker busily spinning...
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 HDMI display, and also when no
> display has been plugged (ie only the internal LVDS connection is
> active).
>
> Across multiple kernel task captures, I see the kernel thread
> consistently reading one of the connector's EDID data [1]; I guess
> either it's having a hard time reading from a disconnected connector
> and retrying, or is incorrectly detecting a change when there is none.
>
> I'll enable DRM debugging to see what connectors it believes it needs
> to read from. Anything else that would be handy to capture, or any
> thoughts?
>
> Also, the 100ms connector change polling seems overkill, particularly
> when power consumption is important; 1000-2000ms would be sufficient,
> do you think?
I think it's meant to be every 10 seconds.
In any case, the output_poll_execute code does more work than necessary,
which might exacerbate the problem. Here's an old patch I wrote that
probably doesn't apply any more but might help.
commit 82c9114cdc60aba7d9bec1396d818362a208cfdc
Author: Andy Lutomirski
Date: Tue Aug 17 09:38:59 2010 -0400
drm: Try to poll fewer unnecessary outputs
We used to poll all outputs that had any kind of polling enabled every time
that the output polling work ran (i.e. every ten seconds). Now only poll
hotplug-interrupt capable outputs when hotplug is detected and we only
poll POLL_CONNECT and POLL_DISCONNECT when in the appropriate state.
Signed-off-by: Andy Lutomirski
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index 9b2a541..5a39e3c 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -817,31 +817,38 @@ static void output_poll_execute(struct slow_work *work)
struct drm_device *dev = container_of(delayed_work, struct drm_device,
mode_config.output_poll_slow_work);
struct drm_connector *connector;
enum drm_connector_status old_status, status;
- bool repoll = false, changed = false;
+ bool repoll = false, changed = false, need_poll, hpd_detected;
int ret;
+ hpd_detected = ACCESS_ONCE(dev->mode_config.hpd_detected);
+ ACCESS_ONCE(dev->mode_config.hpd_detected) = 0;
+
mutex_lock(>mode_config.mutex);
list_for_each_entry(connector, >mode_config.connector_list, head) {
- /* if this is HPD or polled don't check it -
- TV out for instance */
+ /* don't poll unless the drivers asked us to. */
if (!connector->polled)
continue;
- else if (connector->polled & (DRM_CONNECTOR_POLL_CONNECT |
DRM_CONNECTOR_POLL_DISCONNECT))
- repoll = true;
+ /* poll if we got an HPD request... */
+ need_poll = hpd_detected;
+ /* ...or if we're supposed to poll all the time */
old_status = connector->status;
- /* if we are connected and don't want to poll for disconnect
- skip it */
- if (old_status == connector_status_connected &&
- !(connector->polled & DRM_CONNECTOR_POLL_DISCONNECT) &&
- !(connector->polled & DRM_CONNECTOR_POLL_HPD))
- continue;
+ if (old_status == connector_status_connected ?
+ (connector->polled & DRM_CONNECTOR_POLL_CONNECT) :
+ (connector->polled & DRM_CONNECTOR_POLL_DISCONNECT))
+ need_poll = true;
- status = connector->funcs->detect(connector);
- if (old_status != status)
- changed = true;
+ /* Do we re-queue? */
+ if (connector->polled & (DRM_CONNECTOR_POLL_CONNECT |
DRM_CONNECTOR_POLL_DISCONNECT))
+ repoll = true;
+
+ if (need_poll) {
+ status = connector->funcs->detect(connector);
+ if (old_status != status)
+ changed = true;
+ }
}
mutex_unlock(>mode_config.mutex);
@@ -911,6 +918,7 @@ void drm_helper_hpd_irq_event(struct drm_device *dev)
return;
delayed_slow_work_cancel(>mode_config.output_poll_slow_work);
/* schedule a slow work asap */
+ ACCESS_ONCE(dev->mode_config.hpd_detected) = true;
delayed_slow_work_enqueue(>mode_config.output_poll_slow_work, 0);
}
EXPORT_SYMBOL(drm_helper_hpd_irq_event);
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 93a1a31..586f41f 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -596,6 +596,7 @@ struct drm_mode_config {
(Short?) merge window reminder
* 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 get the third digit rather than > the fourth one. > > But no, it wouldn't be for 42. Despite THHGTTG, I think "40" is a > fairly nice round number. Also, in all fairness, we should probably display a certain amount of humility: while Linux has certainly reached milestones such as world domination (as far as large and small computers are concerned), so calling it 3.0 is a fair deal, we probably have to wait for version 42.0 before we can consider the Linux kernel to be the ultimate answer to life, universe and everything. Thanks, Ingo
(Short?) merge window reminder
* 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 version code and iterate it in a more meaningful way. I suspect the stable team and distros will enjoy the more meaningful third digit as well: it will raise the perceived importance of stabilization and packaging work. Btw., we should probably remove the fourth (patch) level, otherwise distros might feel tempted to fill it in with their own patch-stack version number, which would result in confusing "3.3.1.5" meaning different things on different distros - while 3.3.1-5.rpm style of distro kernel package naming denotes the distro patch level more clearly. I don't think the odd/even history will linger too long: in practice we'll iterate through 3.1, 3.2, 3.3 and 3.4 rather quickly, in the first year, so any residual notion of stable/unstable will be gone within a few iterations. > Because of our historical even/odd model, I wouldn't do a 2.7.x - > there's just too much history of 2.1, 2.3, 2.5 being development > trees. But if I do 3.0, then I'd be chucking that whole thing out the > window, and the next release would be 3.1, 3.2, etc.. > > And then in another few years (probably before getting close to 3.40, > so I'm not going to make a big deal of 3 = "third decade"), I'd just > do 4.0 etc. Perhaps we could do 4.0 once the last bit of -rt hits upstream? /me ducks > Because all our releases are supposed to be stable releases these > days, and if we get rid of one level of numbering, I feel perfectly > fine with getting rid of the even/odd history too. They are very stable releases as far as i'm concerned - i can pretty confidently run and use -rc2 and better kernels on my boxes these days and could do so for the past few years. Thanks, Ingo
(Short?) merge window reminder
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" - the stable team would get the third digit rather than > the fourth one. > > But no, it wouldn't be for 42. Despite THHGTTG, I think "40" is a > fairly nice round number. > > There's also the timing issue - since we no longer do version numbers > based on features, but based on time, just saying "we're about to > start the third decade" works as well as any other excuse. > > But we'll see. Maybe, 2011.x, or 11.x, x increasing for every merge window started this year? This would better reflect the steady nature of the releases, but would certainly break a lot of scripts. ;)
(Short?) merge window reminder
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 more discussion than the rest, but when > > the voices tell me to do things, I listen. > > If you do this, I will buy you a bottle of whatever whiskey you want > that I can get my hands on in Tokyo next week. I can recommend Hanyu Ace of Spades ... I can even arrange to be on hand just to make sure it's as good as it should be ... James
(Short?) merge window reminder
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.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. > > But no, it wouldn't be for 42. Despite THHGTTG, I think "40" is a > fairly nice round number. > > There's also the timing issue - since we no longer do version numbers > based on features, but based on time, just saying "we're about to > start the third decade" works as well as any other excuse. > > But we'll see. > >Linus > -- > 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/ >
[RFC] Standardize YUV support in the fbdev API
Hi Florian,
On Saturday 21 May 2011 00:33:02 Florian Tobias Schandinat wrote:
> On 05/17/2011 10:07 PM, Laurent Pinchart wrote:
> > Hi everybody,
> >
> > I need to implement support for a YUV frame buffer in an fbdev driver. As
> > the fbdev API doesn't support this out of the box, I've spent a couple
> > of days reading fbdev (and KMS) code and thinking about how we could
> > cleanly add YUV support to the API. I'd like to share my findings and
> > thoughts, and hopefully receive some comments back.
>
> Thanks. I think you did already a good job, hope we can get it done this
> time.
Thanks. I'll keep pushing then :-)
> > Given the overlap between the KMS, V4L2 and fbdev APIs, the need to share
> > data and buffers between those subsystems, and the planned use of V4L2
> > FCCs in the KMS overlay API, I believe using V4L2 FCCs to identify fbdev
> > formats would be a wise decision.
>
> I agree.
There seems to be a general agreement on this, so I'll consider this settled.
> > To select a frame buffer YUV format, the fb_var_screeninfo structure will
> > need to be extended with a format field. The fbdev API and ABI must not
> > be broken, which prevents us from changing the current structure layout
> > and replacing the existing format selection mechanism (through the red,
> > green, blue and alpha bitfields) completely.
>
> I agree.
>
> > - Other solutions are possible, such as adding new ioctls. Those
> > solutions are more intrusive, and require larger changes to both
> > userspace and kernelspace code.
>
> I'm against (ab)using the nonstd field (probably the only sane thing we can
> do with it is declare it non-standard which interpretation is completely
> dependent on the specific driver) or requiring previously unused fields to
> have a special value so I'd like to suggest a different method:
>
> I remembered an earlier discussion:
> [ http://marc.info/?l=linux-fbdev=129896686208130=2 ]
>
> On 03/01/2011 08:07 AM, Geert Uytterhoeven wrote:
> > On Tue, Mar 1, 2011 at 04:13, Damian wrote:
> >> On 2011/02/24 15:05, Geert Uytterhoeven wrote:
> >>> For YUV (do you mean YCbCr?), I'm inclined to suggest adding a new
> >>> FB_VISUAL_*
> >>> type instead, which indicates the fb_var_screeninfo.{red,green,blue}
> >>> fields are
> >>> YCbCr instead of RGB.
> >>> Depending on the frame buffer organization, you also need new
> >>> FB_TYPE_*/FB_AUX_*
> >>> types.
> >>
> >> I just wanted to clarify here. Is your comment about these new flags
> >> in specific reference to this patch or to Magnus' "going forward"
> >> comment? It
> >
> > About new flags.
> >
> >> seems like the beginnings of a method to standardize YCbCr support in
> >> fbdev across all platforms.
> >> Also, do I understand correctly that FB_VISUAL_ would specify the
> >> colorspace
> >
> > FB_VISUAL_* specifies how pixel values (which may be tuples) are mapped
> > to colors on the screen, so to me it looks like the sensible way to set
> > up YCbCr.
> >
> >> (RGB, YCbCr), FB_TYPE_* would be a format specifier (i.e. planar,
> >> semiplanar, interleaved, etc)? I'm not really sure what you are
> >> referring to with the FB_AUX_* however.
> >
> > Yep, FB_TYPE_* specifies how pixel values/tuples are laid out in frame
> > buffer memory.
> >
> > FB_AUX_* is only used if a specific value of FB_TYPE_* needs an
> > additional parameter (e.g. the interleave value for interleaved
> > bitplanes).
>
> Adding new standard values for these fb_fix_screeninfo fields would solve
> the issue for framebuffers which only support a single format.
I've never liked changing fixed screen information :-) It would be consistent
with the API though.
> If you have the need to switch
Yes I need that. This requires an API to set the mode through
fb_var_screeninfo, which is why I skipped modifying fb_fix_screeinfo.
A new FB_TYPE_* could be used to report that we use a 4CC-based mode, with the
exact mode reported in one of the fb_fix_screeninfo reserved fields (or the
type_aux field). This would duplicate the information passed through
fb_var_screeninfo though. Do you think it's worth it ?
> I guess it would be a good idea to add a new flag to the vmode bitfield in
> fb_var_screeninfo which looks like a general purpose modifier for the
> videomode. You could than reuse any RGB-specific field you like to pass more
> information.
That looks good to me. The grayscale field could be reused to pass the 4CC.
> Maybe we should also use this chance to declare one of the fix_screeninfo
> reserved fields to be used for capability flags or an API version as we can
> assume that those are 0 (at least in sane drivers).
That's always good, although it's not a hard requirement for the purpose of
YUV support.
--
Regards,
Laurent Pinchart
Re: i915 and boot freeze
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 Patapitafious wrote: since kernel .39 i can not boot, when kernel go to gmbus start the issue. I try capture a dump with kexec, but no success, so i have the idea to make video booting, kernel version 2.6.39-02745-g0b26d47 and 2.6.39 vanilla same problem. What is the last kernel that works for you? Are you running self-built or distribution kernels? Can we please see the kernel configuration file? You seem to have verbose debugging options enabled (CONFIG_DEBUG_KOBJECT at least.) it makes the logs harder to read. http://www.vimeo.com/24138372 Unfortunately the beginning is pretty hard to read. It would be great if you were able to get us the kernel logs in a text form, using some form of serial console. I see references to i2c_for_each_dev, a new function which only i2c-dev and i2c-core are using at the moment. So if you have CONFIG_I2C_CHARDEV set, and this is a self-built kernel, try again without it just to get it out of the picture. Note that logs from a pure 2.6.39 kernel would probably be more useful than from a later git snapshot. The 2.6.40 development branch is very young and could have other problems. Alternatively, if you are familiar with git, a git bisection would help too. -- Jean Delvare ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
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 - there's just too much history of 2.1, 2.3, 2.5 being development trees. But if I do 3.0, then I'd be chucking that whole thing out the window, and the next release would be 3.1, 3.2, etc.. I like that. While I don't really care if you call it 2.7, 2.8 or 3.0 (or 4.0 even, if you want to keep continuity following .38 and .39), the current 2.5/2.6 numbering cycle is almost 10 years old and has obviously lost all significance. The only reason I can see that would make it worthwhile waiting for is if the enterprise and embedded people were to decide on a common longterm kernel and call that e.g. 2.7.x or 2.8.x while you continue with 2.9.x or 3.0.x or 3.x. My impression is however that the next longterm release is still one or two years away, so probably not worth waiting for and hard to estimate in advance. Because all our releases are supposed to be stable releases these days, and if we get rid of one level of numbering, I feel perfectly fine with getting rid of the even/odd history too. We still have stable and unstable releases, except that you call the unstable ones -rcX and they are all nice and short, unlike the infamous 2.1.xxx series ;-) IMHO simply changing the names from 2.6.40-rcX to 2.7.X and from 2.6.40.X to 2.6.8.X etc would be the most straightforward change if you want to save the 3.0 release for a special moment. Enough bike shedding from my side, please just make a decision. Arnd ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[git pull] drm pull for gardenshed-rc1
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 standard for allowing switchable graphics support on nvidia hw, Matthew has acked it coming via my tree. Also the VGA ARB is now smarter about devices hiding behind bridges. Dave. The following changes since commit 0ee5623f9a6e52df90a78bd21179f8ab370e102e: Linux 2.6.39-rc6 (2011-05-03 19:59:13 -0700) are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-core-next Alex Deucher (31): drm/radeon/kms: remove some underscan leftovers drm/radeon/kms: add support for thermal chips on combios asics drm/radeon/kms: set i2c adapter class to I2C_CLASS_DDC drm/radeon/kms: fix up r1xx-rs4xx i2c buses drm/radeon/kms: fix some logic errors in combios i2c mapping drm/radeon/kms: DCE4.1 DIG encoders are fully routeable just like DCE3.2 drm/radeon/kms: properly handle bpc 8 in atom command tables drm/radeon/kms: spread spectrum fixes drm/radeon/kms: fix up DP clock programming on DCE4/5 drm/radeon/kms: adjust eDP handling (v2) drm/radeon/kms: fix eDP panel power function drm/radeon/kms: make sure eDP panel is on for modesetting drm/radeon/kms: add some dp encoder/connector helper funcs drm/radeon/kms: improve DP detect logic drm/radeon/kms: improve aux error handling drm/radeon/kms: handle DP bridges drm/dp: add some new DP regs for DP 1.2 drm/radeon/kms: atombios.h updates for DP panel mode drm/radeon/kms/atom: add support for setting DP panel mode drm/radeon/kms: rewrite DP handling drm/radeon/kms: simplify hotplug handler logic drm/radeon/kms: bail early for eDP in hotplug callback drm/radeon/kms: fixup eDP connector handling drm/radeon/kms: properly set the CLK_REF bit for DCE3 devices drm/radeon/kms: the SS_Id field in the LCD table if for LVDS only drm/radeon/evergreen/btc/fusion: setup hdp to invalidate and flush when asked drm/radeon/kms: fix typo in spread spectrum code drm/radeon/kms/cayman: fix typo in register mask drm/radeon/kms/atom: move dig phy init out of modesetting drm/radeon/kms: properly set num banks for fusion asics drm/radeon/kms: bump kms version number Alex Williamson (2): vga_switcheroo: Remove unbalanced pci_enable_device drm/i915/lvds: Only act on lid notify when the device is on Andrew Morton (1): drivers/gpu/drm/radeon/atom.c: fix warning Ben Skeggs (43): drm/nvc0: more vm fault engines drm/nvc0: more vm fault reasons drm/nvc0: decode gpc/hubclient on vm fault drm/nouveau: use static vidshift of 2 on volt 0x30 tables drm/nouveau: move engine object creation into per-engine hooks drm/nouveau: remove some unused members from dev_priv drm/nouveau: working towards a common way to represent engines drm/nv50/gr: move to exec engine interfaces drm/nvc0/gr: move to exec engine interfaces drm/nv40/gr: move to exec engine interfaces drm/nv20-nv30/gr: move to exec engine interface drm/nv10/gr: move to exec engine interfaces drm/nv04/gr: move to exec engine interfaces drm/nouveau: move set_tile_region to nouveau_exec_engine drm/nouveau: remove remnants of nouveau_pgraph_engine from nouveau_channel drm/nouveau: fix suspend failure path to reinitialise all engines drm/nouveau: remove remnants of nouveau_pgraph_engine drm/nva3: implement support for copy engine drm/nvc0: implement support for copy engines drm/nv40/vpe: add support for PMPEG drm/nv84: add support for PMPEG drm/nv50: rename nv84_mpeg to nv50_mpeg drm/nv50: support PMPEG on original nv50 drm/nvc0/gr: better handling of fuc firmware drm/nvc0/fifo: kick channels off during suspend drm/nvc0/fifo: restore context table on resume drm/nvc0/gr: no need to store context in graph_fini() drm/nvc0/fifo: stick user area into a gpuobj rather than a bo drm/nv40/gr: oops, fix random bits getting set in engine obj drm/nouveau: pull refclk from vbios on limits 0x40 boards drm/nva3: somewhat improve clock reporting drm/nouveau: fix uninitialised variable warning drm/nouveau: recognise DCB connector type 0x41 as LVDS drm/nv50: respect LVDS link count from EDID on SPWG panels drm/nvc0/gr: calculate some more of our magic numbers drm/nva3/pm: initial pass at set_clock() hook drm/nva3: support for memory timing map table drm/nouveau/pm: remove memtiming support check when assigning to perflvl drm/nvc0/pm: correct core/mem/shader perflvl parsing drm/nvc0/pm: parse
Re: [2.6.39-rc7] i915: kworker busily spinning...
On 17 May 2011 12:27, Daniel J Blueman daniel.blue...@gmail.com 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 HDMI display, and also when no display has been plugged (ie only the internal LVDS connection is active). Across multiple kernel task captures, I see the kernel thread consistently reading one of the connector's EDID data [1]; I guess either it's having a hard time reading from a disconnected connector and retrying, or is incorrectly detecting a change when there is none. I'll enable DRM debugging to see what connectors it believes it needs to read from. Anything else that would be handy to capture, or any thoughts? Also, the 100ms connector change polling seems overkill, particularly when power consumption is important; 1000-2000ms would be sufficient, do you think? Thanks, Daniel --- [1] kworker/2:2 R running task 5048 86 2 0x 0002 88021e804040 88021e85f9b0 88021e804040 88021e85e000 4000 8802210a4040 88021e804040 0046 81c18b20 88022106c000 8270b740 Call Trace: [8109a460] ? mark_held_locks+0x70/0xa0 [81059261] ? get_parent_ip+0x11/0x50 [8105933d] ? sub_preempt_count+0x9d/0xd0 [81705a35] schedule_timeout+0x175/0x250 [8106ec10] ? run_timer_softirq+0x2a0/0x2a0 [81705b29] schedule_timeout_uninterruptible+0x19/0x20 [8106f878] msleep+0x18/0x20 [a017c620] gmbus_xfer+0x400/0x620 [i915] [8150c892] i2c_transfer+0xa2/0xf0 [a002bc96] drm_do_probe_ddc_edid+0x66/0xa0 [drm] [a002c0f9] drm_get_edid+0x29/0x60 [drm] [a0176f86] intel_hdmi_detect+0x56/0xe0 [i915] [a00d1177] output_poll_execute+0xd7/0x1a0 [drm_kms_helper] [81078e14] process_one_work+0x1a4/0x450 [81078db6] ? process_one_work+0x146/0x450 [a00d10a0] ? drm_helper_disable_unused_functions+0x150/0x150 [drm_kms_helper] [810790ec] process_scheduled_works+0x2c/0x40 [8107c384] worker_thread+0x284/0x350 [8107c100] ? manage_workers.clone.23+0x120/0x120 [81080ea6] kthread+0xb6/0xc0 [8109a5cd] ? trace_hardirqs_on_caller+0x13d/0x180 [8170a494] kernel_thread_helper+0x4/0x10 [8104c64f] ? finish_task_switch+0x6f/0x100 [81708bc4] ? retint_restore_args+0xe/0xe [81080df0] ? __init_kthread_worker+0x70/0x70 [8170a490] ? gs_change+0xb/0xb Interestingly, I appear to observe this behaviour when the laptop battery is charging. Anyway, we see continual connector update events [1], booted drm.debug=0x4. This reproduces with 2.6.39. Any thoughts? Daniel --- [1] [ 67.035097] [drm:output_poll_execute], [CONNECTOR:22:HDMI-A-2] status updated from 2 to 2 [ 67.046549] [drm:output_poll_execute], [CONNECTOR:25:HDMI-A-3] status updated from 2 to 2 [ 67.047063] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x5143003e [ 67.047065] [drm:ironlake_dp_detect], DPCD: [ 67.047066] [drm:output_poll_execute], [CONNECTOR:27:DP-2] status updated from 2 to 2 [ 67.047578] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x5143003e [ 67.047579] [drm:ironlake_dp_detect], DPCD: [ 67.047581] [drm:output_poll_execute], [CONNECTOR:30:DP-3] status updated from 2 to 2 [ 67.047588] [drm:intel_ironlake_crt_detect_hotplug], ironlake hotplug adpa=0xf4, result 0 [ 67.047591] [drm:intel_crt_detect], CRT not detected via hotplug [ 67.047593] [drm:output_poll_execute], [CONNECTOR:12:VGA-1] status updated from 2 to 2 [ 67.059062] [drm:output_poll_execute], [CONNECTOR:15:HDMI-A-1] status updated from 2 to 2 [ 67.059573] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x5143003e [ 67.059575] [drm:ironlake_dp_detect], DPCD: [ 67.059576] [drm:output_poll_execute], [CONNECTOR:18:DP-1] status updated from 2 to 2 [ 67.059886] [drm:i915_hotplug_work_func], running encoder hotplug functions 85 lines the same [ 67.153172] [drm:i915_hotplug_work_func], running encoder hotplug functions [ 67.155109] [drm:output_poll_execute], [CONNECTOR:22:HDMI-A-2] status updated from 2 to 2 [ 67.166569] [drm:output_poll_execute], [CONNECTOR:25:HDMI-A-3] status updated from 2 to 2 [ 67.167082] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x5143003e [ 67.167084] [drm:ironlake_dp_detect], DPCD: [ 67.167086] [drm:output_poll_execute], [CONNECTOR:27:DP-2] status updated from 2 to 2 [ 67.167598] [drm:intel_dp_aux_ch], dp_aux_ch timeout status 0x5143003e [ 67.167600] [drm:ironlake_dp_detect], DPCD: [ 67.167601] [drm:output_poll_execute], [CONNECTOR:30:DP-3] status updated from 2 to 2 [ 67.167608] [drm:intel_ironlake_crt_detect_hotplug], ironlake hotplug adpa=0xf4,
Re: [2.6.39-rc7] i915: kworker busily spinning...
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 HDMI display, and also when no
display has been plugged (ie only the internal LVDS connection is
active).
Across multiple kernel task captures, I see the kernel thread
consistently reading one of the connector's EDID data [1]; I guess
either it's having a hard time reading from a disconnected connector
and retrying, or is incorrectly detecting a change when there is none.
I'll enable DRM debugging to see what connectors it believes it needs
to read from. Anything else that would be handy to capture, or any
thoughts?
Also, the 100ms connector change polling seems overkill, particularly
when power consumption is important; 1000-2000ms would be sufficient,
do you think?
I think it's meant to be every 10 seconds.
In any case, the output_poll_execute code does more work than necessary,
which might exacerbate the problem. Here's an old patch I wrote that
probably doesn't apply any more but might help.
commit 82c9114cdc60aba7d9bec1396d818362a208cfdc
Author: Andy Lutomirski l...@mit.edu
Date: Tue Aug 17 09:38:59 2010 -0400
drm: Try to poll fewer unnecessary outputs
We used to poll all outputs that had any kind of polling enabled every time
that the output polling work ran (i.e. every ten seconds). Now only poll
hotplug-interrupt capable outputs when hotplug is detected and we only
poll POLL_CONNECT and POLL_DISCONNECT when in the appropriate state.
Signed-off-by: Andy Lutomirski l...@mit.edu
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index 9b2a541..5a39e3c 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -817,31 +817,38 @@ static void output_poll_execute(struct slow_work *work)
struct drm_device *dev = container_of(delayed_work, struct drm_device,
mode_config.output_poll_slow_work);
struct drm_connector *connector;
enum drm_connector_status old_status, status;
- bool repoll = false, changed = false;
+ bool repoll = false, changed = false, need_poll, hpd_detected;
int ret;
+ hpd_detected = ACCESS_ONCE(dev-mode_config.hpd_detected);
+ ACCESS_ONCE(dev-mode_config.hpd_detected) = 0;
+
mutex_lock(dev-mode_config.mutex);
list_for_each_entry(connector, dev-mode_config.connector_list, head) {
- /* if this is HPD or polled don't check it -
- TV out for instance */
+ /* don't poll unless the drivers asked us to. */
if (!connector-polled)
continue;
- else if (connector-polled (DRM_CONNECTOR_POLL_CONNECT |
DRM_CONNECTOR_POLL_DISCONNECT))
- repoll = true;
+ /* poll if we got an HPD request... */
+ need_poll = hpd_detected;
+ /* ...or if we're supposed to poll all the time */
old_status = connector-status;
- /* if we are connected and don't want to poll for disconnect
- skip it */
- if (old_status == connector_status_connected
- !(connector-polled DRM_CONNECTOR_POLL_DISCONNECT)
- !(connector-polled DRM_CONNECTOR_POLL_HPD))
- continue;
+ if (old_status == connector_status_connected ?
+ (connector-polled DRM_CONNECTOR_POLL_CONNECT) :
+ (connector-polled DRM_CONNECTOR_POLL_DISCONNECT))
+ need_poll = true;
- status = connector-funcs-detect(connector);
- if (old_status != status)
- changed = true;
+ /* Do we re-queue? */
+ if (connector-polled (DRM_CONNECTOR_POLL_CONNECT |
DRM_CONNECTOR_POLL_DISCONNECT))
+ repoll = true;
+
+ if (need_poll) {
+ status = connector-funcs-detect(connector);
+ if (old_status != status)
+ changed = true;
+ }
}
mutex_unlock(dev-mode_config.mutex);
@@ -911,6 +918,7 @@ void drm_helper_hpd_irq_event(struct drm_device *dev)
return;
delayed_slow_work_cancel(dev-mode_config.output_poll_slow_work);
/* schedule a slow work asap */
+ ACCESS_ONCE(dev-mode_config.hpd_detected) = true;
delayed_slow_work_enqueue(dev-mode_config.output_poll_slow_work, 0);
}
EXPORT_SYMBOL(drm_helper_hpd_irq_event);
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 93a1a31..586f41f 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -596,6 +596,7 @@ struct drm_mode_config {
Re: [2.6.39-rc7] i915: kworker busily spinning...
On 24 May 2011 12:02, Andy Lutomirski l...@mit.edu 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 interactivity latency. I've seen it occur when plugging eg a HDMI display, and also when no display has been plugged (ie only the internal LVDS connection is active). Across multiple kernel task captures, I see the kernel thread consistently reading one of the connector's EDID data [1]; I guess either it's having a hard time reading from a disconnected connector and retrying, or is incorrectly detecting a change when there is none. I'll enable DRM debugging to see what connectors it believes it needs to read from. Anything else that would be handy to capture, or any thoughts? Also, the 100ms connector change polling seems overkill, particularly when power consumption is important; 1000-2000ms would be sufficient, do you think? I think it's meant to be every 10 seconds. In any case, the output_poll_execute code does more work than necessary, which might exacerbate the problem. Here's an old patch I wrote that probably doesn't apply any more but might help. Thanks for the patch Andy; I'll test it after we've found a fix for the underlying issue. Daniel -- Daniel J Blueman ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
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 listen. So the voices tell you to avoid .42 ? Thanks, tglx ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
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 more discussion than the rest, but when the voices tell me to do things, I listen. If you do this, I will buy you a bottle of whatever whiskey you want that I can get my hands on in Tokyo next week. I can recommend Hanyu Ace of Spades ... I can even arrange to be on hand just to make sure it's as good as it should be ... James ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
On Tue, May 24, 2011 at 00:33, Linus Torvalds torva...@linux-foundation.org wrote: On Mon, May 23, 2011 at 12:20 PM, Ingo Molnar mi...@elte.hu 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 get the third digit rather than the fourth one. But no, it wouldn't be for 42. Despite THHGTTG, I think 40 is a fairly nice round number. There's also the timing issue - since we no longer do version numbers based on features, but based on time, just saying we're about to start the third decade works as well as any other excuse. But we'll see. Maybe, 2011.x, or 11.x, x increasing for every merge window started this year? This would better reflect the steady nature of the releases, but would certainly break a lot of scripts. ;) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
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 http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
On 5/23/11, Linus Torvalds torva...@linux-foundation.org wrote: On Mon, May 23, 2011 at 12:20 PM, Ingo Molnar mi...@elte.hu 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.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. But no, it wouldn't be for 42. Despite THHGTTG, I think 40 is a fairly nice round number. There's also the timing issue - since we no longer do version numbers based on features, but based on time, just saying we're about to start the third decade works as well as any other excuse. But we'll see. Linus -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
On Mon, May 23, 2011 at 01:33:48PM -0700, Linus Torvalds wrote: On Mon, May 23, 2011 at 12:20 PM, Ingo Molnar mi...@elte.hu 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 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, 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. - Ted ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
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 mi...@elte.hu 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 get the third digit rather than the fourth one. I like that, it would make things much easier for me to keep track of stuff. As long as 3.14 turns into a long-term support kernel and gets up to 159 ... In all serious, I'm very supportive of this move. I'm heartily sick of people claiming we have version 2.6 support when they really mean they haven't updated since version 2.6.9. Yeah, congratulations, you're seven years out of date. -- Matthew Wilcox Intel Open Source Technology Centre Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
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 -
there's just too much history of 2.1, 2.3, 2.5 being development
trees.
.oO(Though once 2.{7 or more, odd} trickle into the distros, it would
become pretty much apparent that they are not devel.)
And then in another few years (probably before getting close to 3.40,
so I'm not going to make a big deal of 3 = third decade), I'd just
do 4.0 etc.
While 2.6 has certainly worn out, already thinking of a 4.0 is highly
reminiscient of the version number arms race Firefox and ChromeBrowser
are doing currently.
Because all our releases are supposed to be stable releases these
days, and if we get rid of one level of numbering, I feel perfectly
fine with getting rid of the even/odd history too.
If I remember past-time discussions right, ELF was the contributing
factor to bump the major number to 2.0 back then; ever since 2.0, no
similarly breakthrough-ing event has occurred.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
2011/5/24 Jan Engelhardt jeng...@medozas.de:
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 -
there's just too much history of 2.1, 2.3, 2.5 being development
trees.
.oO(Though once 2.{7 or more, odd} trickle into the distros, it would
become pretty much apparent that they are not devel.)
And then in another few years (probably before getting close to 3.40,
so I'm not going to make a big deal of 3 = third decade), I'd just
do 4.0 etc.
While 2.6 has certainly worn out, already thinking of a 4.0 is highly
reminiscient of the version number arms race Firefox and ChromeBrowser
are doing currently.
Because all our releases are supposed to be stable releases these
days, and if we get rid of one level of numbering, I feel perfectly
fine with getting rid of the even/odd history too.
If I remember past-time discussions right, ELF was the contributing
factor to bump the major number to 2.0 back then; ever since 2.0, no
similarly breakthrough-ing event has occurred.
What then about BKL removal? Nice place to celebrate with version jump
and heaving some beers.
-Jacek
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
On Tuesday 2011-05-24 14:30, Jacek Luczak wrote:
2011/5/24 Jan Engelhardt jeng...@medozas.de:
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 -
there's just too much history of 2.1, 2.3, 2.5 being development
trees.
.oO(Though once 2.{7 or more, odd} trickle into the distros, it would
become pretty much apparent that they are not devel.)
And then in another few years (probably before getting close to 3.40,
so I'm not going to make a big deal of 3 = third decade), I'd just
do 4.0 etc.
While 2.6 has certainly worn out, already thinking of a 4.0 is highly
reminiscient of the version number arms race Firefox and ChromeBrowser
are doing currently.
Because all our releases are supposed to be stable releases these
days, and if we get rid of one level of numbering, I feel perfectly
fine with getting rid of the even/odd history too.
If I remember past-time discussions right, ELF was the contributing
factor to bump the major number to 2.0 back then; ever since 2.0, no
similarly breakthrough-ing event has occurred.
What then about BKL removal? Nice place to celebrate with version jump
and heaving some beers.
The BKL going away was not a change that would require new
userspace programs.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
2011/5/24 Jan Engelhardt jeng...@medozas.de:
On Tuesday 2011-05-24 14:30, Jacek Luczak wrote:
2011/5/24 Jan Engelhardt jeng...@medozas.de:
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 -
there's just too much history of 2.1, 2.3, 2.5 being development
trees.
.oO(Though once 2.{7 or more, odd} trickle into the distros, it would
become pretty much apparent that they are not devel.)
And then in another few years (probably before getting close to 3.40,
so I'm not going to make a big deal of 3 = third decade), I'd just
do 4.0 etc.
While 2.6 has certainly worn out, already thinking of a 4.0 is highly
reminiscient of the version number arms race Firefox and ChromeBrowser
are doing currently.
Because all our releases are supposed to be stable releases these
days, and if we get rid of one level of numbering, I feel perfectly
fine with getting rid of the even/odd history too.
If I remember past-time discussions right, ELF was the contributing
factor to bump the major number to 2.0 back then; ever since 2.0, no
similarly breakthrough-ing event has occurred.
What then about BKL removal? Nice place to celebrate with version jump
and heaving some beers.
The BKL going away was not a change that would require new
userspace programs.
True but as you I guess - kind off - notice there's no such event that
would launch fireworks and we get features smoothly. By that then we
should celebrate killing old nightmares aka BKL. It's more like - lets
not find the reason but include one just to feel better. At the end
the simplified version convention is the best reason to do this cut
off. I even plan to send a truck full of chickens to Linus if this
will convince him :) Then, while describing new kernel deployment, I
won't need to pronounce the cool sounding - ,,Mika so I've now
installed two(dot)six(dot)thirty-five(dot)forty-one(dash)one
version.''
Cheers,
-Jacek
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
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 3.0, 3.1 and 3.11 all of which numbers still give older sysadmins flashbacks and will have them waking screaming in the middle of the night. Also saves breaking all the tools and assumptions people have been used to for some many years Alan ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
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 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
On Tue, May 24, 2011 at 10:43 AM, Alan Cox a...@lxorguk.ukuu.org.uk 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 dead. 2.8 could mark the beginning of the great cleanup --- work out the details of what needs to be cleaned and set a goal --- remove old buses/driver, switch to device tree, graphics, 32/64 merges, etc 3.0 would mark its completion -- Jon Smirl jonsm...@gmail.com ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 37490] texture corruption in r600/r600g when using DRI2, no texture corruption in r600 with dri1
https://bugs.freedesktop.org/show_bug.cgi?id=37490 Michel Dänzer mic...@daenzer.net changed: What|Removed |Added Attachment #47089|text/x-log |text/plain mime type|| -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 37490] texture corruption in r600/r600g when using DRI2, no texture corruption in r600 with dri1
https://bugs.freedesktop.org/show_bug.cgi?id=37490 --- Comment #12 from Michel Dänzer mic...@daenzer.net 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 --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: How are GLX Visuals Created???
On Sun, May 22, 2011 at 6:15 PM, Dee Sharpe demetrioussha...@netscape.net 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 list of Visuals? How is this info combined shaped into Visuals? I'm looking specifically for functions variables. If someone could point me to a few files, I'd be immensely grateful! http://cgit.freedesktop.org/xorg/xserver/tree/glx/glxscreens.c#n322 Is that what you are looking for? -- Dee Sharpe The difference between what IS done what COULD be done is relational to what you ARE doing what you COULD be doing! ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 28125] DRI2 prevents indirect glx
https://bugs.freedesktop.org/show_bug.cgi?id=28125 Marc Gariépy mgari...@ubuntu.com changed: What|Removed |Added CC||mgari...@ubuntu.com See Also||https://launchpad.net/bugs/ ||785368 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
On 05/24/2011 08:07 AM, jonsm...@gmail.com wrote: On Tue, May 24, 2011 at 10:43 AM, Alan Cox a...@lxorguk.ukuu.org.uk 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 dead. 2.8 could mark the beginning of the great cleanup --- work out the details of what needs to be cleaned and set a goal --- remove old buses/driver, switch to device tree, graphics, 32/64 merges, etc 3.0 would mark its completion 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. If we want to to deprecate lots of drivers (which I personally would advocate against -- I have built systems specifically to run a real floppy drive since the Linux floppy driver is amazingly flexible and can read/write a lot of formats that nothing else can, including USB floppies) then we should do that in the normal course of action, incrementally, and listed in feature-removal-schedule.txt, not all at once due to some arbitrary milestone. We have found it works better this way. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
On Tue, May 24, 2011 at 10:36 AM, H. Peter Anvin h...@zytor.com 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. So a renumbering would be purely about dropping the numbers to something smaller and more easily recognized. The ABI wouldn't change. The API wouldn't change. There wouldn't be any big because we finally did xyz. Linus ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 37253] SIGSEGV in dri2FlushFrontBuffer/MakeContextCurrent
https://bugs.freedesktop.org/show_bug.cgi?id=37253 --- Comment #3 from Sven Arvidsson s...@whiz.se 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 as it isn't a problem specific to r600g. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 37253] SIGSEGV in dri2FlushFrontBuffer/MakeContextCurrent
https://bugs.freedesktop.org/show_bug.cgi?id=37253 Benoit Jacob bja...@mozilla.com changed: What|Removed |Added Component|Drivers/Gallium/r600|Mesa core AssignedTo|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 35434] [RADEON:KMS:R600G] etqw: broken ground textures
https://bugs.freedesktop.org/show_bug.cgi?id=35434 --- Comment #11 from Sven Arvidsson s...@whiz.se 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 getting software rendering? Check the renderer string in glxinfo, and double check by setting LIBGL_DEBUG=verbose and check which driver is loaded. If nothing else, the game should be very slow, even with a fast CPU, 4-5 fps and a loading time of several minutes... -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 35434] [RADEON:KMS:R600G] etqw: broken ground textures
https://bugs.freedesktop.org/show_bug.cgi?id=35434 --- Comment #12 from Benjamin Bellec b.bel...@gmail.com 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. Can you confirm that you're getting software rendering? Check the renderer string in glxinfo, and double check by setting LIBGL_DEBUG=verbose and check which driver is loaded. If nothing else, the game should be very slow, even with a fast CPU, 4-5 fps and a loading time of several minutes... Shame on me! ETQW has loaded r600_dri.so from /usr/local/dri (my former dri install) when I deleted it from /usr/dri ! So I believed I was on llvmpipe (Gnome 3 was in fallback-mode, and glxinfo said that too). You are right, ETQW is too slow to move the mouse. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 35434] [RADEON:KMS:R600G] etqw: broken ground textures
https://bugs.freedesktop.org/show_bug.cgi?id=35434 --- Comment #13 from Sven Arvidsson s...@whiz.se 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.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 37490] texture corruption in r600/r600g when using DRI2, no texture corruption in r600 with dri1
https://bugs.freedesktop.org/show_bug.cgi?id=37490 --- Comment #13 from William Pitcock neno...@systeminplace.net 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 am running in a debian chroot. thusly, i do not really use the gallium driver yet... i only tested it to see if it did the same thing, which it does. the result is not the same everytime you trigger that kwin effect though; sometimes i get part of a console framebuffer (e.g. radeondrmfb). so would it make more sense for me to test non-gallium driver first? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 37490] texture corruption in r600/r600g when using DRI2, no texture corruption in r600 with dri1
https://bugs.freedesktop.org/show_bug.cgi?id=37490 --- Comment #14 from Alex Deucher ag...@yahoo.com 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 have 32-bit applications i am running in a debian chroot. thusly, i do not really use the gallium driver yet... i only tested it to see if it did the same thing, which it does. the result is not the same everytime you trigger that kwin effect though; sometimes i get part of a console framebuffer (e.g. radeondrmfb). so would it make more sense for me to test non-gallium driver first? No one is really working on the non gallium driver any more, so it's not likely to get much more attention. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (Short?) merge window reminder
On 05/23/2011 04:33 PM, Linus Torvalds wrote: On Mon, May 23, 2011 at 12:20 PM, Ingo Molnarmi...@elte.hu 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 get the third digit rather than the fourth one. But no, it wouldn't be for 42. Despite THHGTTG, I think 40 is a fairly nice round number. There's also the timing issue - since we no longer do version numbers based on features, but based on time, just saying we're about to start the third decade works as well as any other excuse. I don't think year-based versions (like 2011.0 for the first 2011 release, or maybe 2011.5 for May 2011) are pretty, but I'll make an argument for them anyway: it makes it easier to figure out when hardware ought to be supported. So if I buy a 2014-model laptop and the coffee-making button doesn't work, and my favorite distro is running the 2013 kernel, then I know I shouldn't expect to it to work. (Graphics drivers are probably a more realistic example.) Also, when someone in my lab installs insert ancient enterprise distro here on a box that's running software I wrote that needs to support modern high-speed peripherals, then I can say What? You seriously expect this stuff to work on Linux 2007? Let's install a slightly less stable distro from at least 2010. This sounds a lot less nerdy than What? You seriously expect this stuff to work on Linux 2.6.27? Let's install a slightly less stable distro that uses at least 2.6.36. --Andy ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 37490] texture corruption in r600/r600g when using DRI2, no texture corruption in r600 with dri1
https://bugs.freedesktop.org/show_bug.cgi?id=37490 --- Comment #15 from William Pitcock neno...@systeminplace.net 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, but i need the normal driver to work as i have 32-bit applications i am running in a debian chroot. thusly, i do not really use the gallium driver yet... i only tested it to see if it did the same thing, which it does. the result is not the same everytime you trigger that kwin effect though; sometimes i get part of a console framebuffer (e.g. radeondrmfb). so would it make more sense for me to test non-gallium driver first? No one is really working on the non gallium driver any more, so it's not likely to get much more attention. well, i will try and see if r600g git master solves the problem. unfortunately, i think this means i'm screwed when it comes to running proprietary apps in chroots. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 28125] DRI2 prevents indirect glx
https://bugs.freedesktop.org/show_bug.cgi?id=28125 --- Comment #4 from ajax at nwnk dot net a...@nwnk.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://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] uv/x2apic: update for change in pci bridge handling.
From: Dave Airlie airl...@redhat.com
I forgot about the special uv handling code for this, so this
patch fixes it up.
Signed-off-by: Dave Airlie airl...@redhat.com
---
arch/x86/kernel/apic/x2apic_uv_x.c |8
drivers/pci/pci.c |4 ++--
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/x86/kernel/apic/x2apic_uv_x.c
b/arch/x86/kernel/apic/x2apic_uv_x.c
index 33b10a0..185cd1e 100644
--- a/arch/x86/kernel/apic/x2apic_uv_x.c
+++ b/arch/x86/kernel/apic/x2apic_uv_x.c
@@ -599,14 +599,14 @@ late_initcall(uv_init_heartbeat);
/* Direct Legacy VGA I/O traffic to designated IOH */
int uv_set_vga_state(struct pci_dev *pdev, bool decode,
- unsigned int command_bits, bool change_bridge)
+ unsigned int command_bits, u32 flags)
{
int domain, bus, rc;
- PR_DEVEL(devfn %x decode %d cmd %x chg_brdg %d\n,
- pdev-devfn, decode, command_bits, change_bridge);
+ PR_DEVEL(devfn %x decode %d cmd %x flags %d\n,
+ pdev-devfn, decode, command_bits, flags);
- if (!change_bridge)
+ if (!(flags PCI_VGA_STATE_CHANGE_BRIDGE))
return 0;
if ((command_bits PCI_COMMAND_IO) == 0)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index a339237..4528ee7 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -2862,11 +2862,11 @@ void __init
pci_register_set_vga_state(arch_set_vga_state_t func)
}
static int pci_set_vga_state_arch(struct pci_dev *dev, bool decode,
- unsigned int command_bits, bool change_bridge)
+ unsigned int command_bits, u32 flags)
{
if (arch_set_vga_state)
return arch_set_vga_state(dev, decode, command_bits,
- change_bridge);
+ flags);
return 0;
}
--
1.7.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/radeon/kms/blit: workaround some hw issues on evergreen+
Signed-off-by: Alex Deucher alexdeuc...@gmail.com
---
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/drm/radeon/evergreen_blit_kms.c
+++ b/drivers/gpu/drm/radeon/evergreen_blit_kms.c
@@ -199,6 +199,16 @@ static void
set_scissors(struct radeon_device *rdev, int x1, int y1,
int x2, int y2)
{
+ /* workaround some hw bugs */
+ if (x2 == 0)
+ x1 = 1;
+ if (y2 == 0)
+ y1 = 1;
+ if (rdev-family == CHIP_CAYMAN) {
+ if ((x2 == 1) (y2 == 1))
+ x2 = 2;
+ }
+
radeon_ring_write(rdev, PACKET3(PACKET3_SET_CONTEXT_REG, 2));
radeon_ring_write(rdev, (PA_SC_SCREEN_SCISSOR_TL -
PACKET3_SET_CONTEXT_REG_START) 2);
radeon_ring_write(rdev, (x1 0) | (y1 16));
--
1.7.1.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/radeon/kms: add blit support for cayman
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 alexdeuc...@gmail.com
---
drivers/gpu/drm/radeon/cayman_blit_shaders.c | 326 -
drivers/gpu/drm/radeon/cayman_blit_shaders.h |3 +
drivers/gpu/drm/radeon/evergreen_blit_kms.c | 505 ++
drivers/gpu/drm/radeon/ni.c | 13 +-
drivers/gpu/drm/radeon/radeon_asic.c |6 +-
5 files changed, 598 insertions(+), 255 deletions(-)
diff --git a/drivers/gpu/drm/radeon/cayman_blit_shaders.c
b/drivers/gpu/drm/radeon/cayman_blit_shaders.c
index e148ab0..7b4eeb7 100644
--- a/drivers/gpu/drm/radeon/cayman_blit_shaders.c
+++ b/drivers/gpu/drm/radeon/cayman_blit_shaders.c
@@ -39,17 +39,335 @@
const u32 cayman_default_state[] =
{
- /* XXX fill in additional blit state */
+ 0xc0066900,
+ 0x,
+ 0x0060, /* DB_RENDER_CONTROL */
+ 0x, /* DB_COUNT_CONTROL */
+ 0x, /* DB_DEPTH_VIEW */
+ 0x002a, /* DB_RENDER_OVERRIDE */
+ 0x, /* DB_RENDER_OVERRIDE2 */
+ 0x, /* DB_HTILE_DATA_BASE */
0xc0026900,
- 0x0316,
- 0x000e, /* VGT_VERTEX_REUSE_BLOCK_CNTL */
- 0x0010, /* */
+ 0x000a,
+ 0x, /* DB_STENCIL_CLEAR */
+ 0x, /* DB_DEPTH_CLEAR */
+
+ 0xc0036900,
+ 0x000f,
+ 0x, /* DB_DEPTH_INFO */
+ 0x, /* DB_Z_INFO */
+ 0x, /* DB_STENCIL_INFO */
+
+ 0xc0016900,
+ 0x0080,
+ 0x, /* PA_SC_WINDOW_OFFSET */
+
+ 0xc00d6900,
+ 0x0083,
+ 0x, /* PA_SC_CLIPRECT_RULE */
+ 0x, /* PA_SC_CLIPRECT_0_TL */
+ 0x20002000, /* PA_SC_CLIPRECT_0_BR */
+ 0x,
+ 0x20002000,
+ 0x,
+ 0x20002000,
+ 0x,
+ 0x20002000,
+ 0x, /* PA_SC_EDGERULE */
+ 0x, /* PA_SU_HARDWARE_SCREEN_OFFSET */
+ 0x000f, /* CB_TARGET_MASK */
+ 0x000f, /* CB_SHADER_MASK */
+
+ 0xc0226900,
+ 0x0094,
+ 0x8000, /* PA_SC_VPORT_SCISSOR_0_TL */
+ 0x20002000, /* PA_SC_VPORT_SCISSOR_0_BR */
+ 0x8000,
+ 0x20002000,
+ 0x8000,
+ 0x20002000,
+ 0x8000,
+ 0x20002000,
+ 0x8000,
+ 0x20002000,
+ 0x8000,
+ 0x20002000,
+ 0x8000,
+ 0x20002000,
+ 0x8000,
+ 0x20002000,
+ 0x8000,
+ 0x20002000,
+ 0x8000,
+ 0x20002000,
+ 0x8000,
+ 0x20002000,
+ 0x8000,
+ 0x20002000,
+ 0x8000,
+ 0x20002000,
+ 0x8000,
+ 0x20002000,
+ 0x8000,
+ 0x20002000,
+ 0x8000,
+ 0x20002000,
+ 0x, /* PA_SC_VPORT_ZMIN_0 */
+ 0x3f80, /* PA_SC_VPORT_ZMAX_0 */
+
+ 0xc0016900,
+ 0x00d4,
+ 0x, /* SX_MISC */
0xc0026900,
0x00d9,
0x, /* CP_RINGID */
0x, /* CP_VMID */
+
+ 0xc0096900,
+ 0x0100,
+ 0x00ff, /* VGT_MAX_VTX_INDX */
+ 0x, /* VGT_MIN_VTX_INDX */
+ 0x, /* VGT_INDX_OFFSET */
+ 0x, /* VGT_MULTI_PRIM_IB_RESET_INDX */
+ 0x, /* SX_ALPHA_TEST_CONTROL */
+ 0x, /* CB_BLEND_RED */
+ 0x, /* CB_BLEND_GREEN */
+ 0x, /* CB_BLEND_BLUE */
+ 0x, /* CB_BLEND_ALPHA */
+
+ 0xc0016900,
+ 0x0187,
+ 0x0100, /* SPI_VS_OUT_ID_0 */
+
+ 0xc0026900,
+ 0x0191,
+ 0x0100, /* SPI_PS_INPUT_CNTL_0 */
+ 0x0101, /* SPI_PS_INPUT_CNTL_1 */
+
+ 0xc0016900,
+ 0x01b1,
+ 0x, /* SPI_VS_OUT_CONFIG */
+
+ 0xc0106900,
+ 0x01b3,
+ 0x2001, /* SPI_PS_IN_CONTROL_0 */
+ 0x, /* SPI_PS_IN_CONTROL_1 */
+ 0x, /* SPI_INTERP_CONTROL_0 */
+ 0x, /* SPI_INPUT_Z */
+ 0x, /* SPI_FOG_CNTL */
+ 0x0010, /* SPI_BARYC_CNTL */
+ 0x, /* SPI_PS_IN_CONTROL_2 */
+ 0x, /* SPI_COMPUTE_INPUT_CNTL */
+ 0x, /* SPI_COMPUTE_NUM_THREAD_X */
+ 0x, /* SPI_COMPUTE_NUM_THREAD_Y */
+ 0x, /* SPI_COMPUTE_NUM_THREAD_Z */
+ 0x, /* SPI_GPR_MGMT */
+ 0x, /* SPI_LDS_MGMT */
+ 0x, /* SPI_STACK_MGMT */
+ 0x, /* SPI_WAVE_MGMT_1 */
+ 0x, /* SPI_WAVE_MGMT_2 */
+
+ 0xc0016900,
+ 0x01e0,
+ 0x, /* CB_BLEND0_CONTROL */
+
+ 0xc00e6900,
+ 0x0200,
+ 0x, /* DB_DEPTH_CONTROL */
+ 0x, /* DB_EQAA */
+ 0x00cc0010, /* CB_COLOR_CONTROL */
+ 0x0210, /* DB_SHADER_CONTROL */
+ 0x0001, /* PA_CL_CLIP_CNTL */
+
Re: (Short?) merge window reminder
On Tue, 24 May 2011 14:30:59 +0200, Jacek Luczak said:
2011/5/24 Jan Engelhardt jeng...@medozas.de:
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 -
there's just too much history of 2.1, 2.3, 2.5 being development
trees.
.oO(Though once 2.{7 or more, odd} trickle into the distros, it would
become pretty much apparent that they are not devel.)
And then in another few years (probably before getting close to 3.40,
so I'm not going to make a big deal of 3 = third decade), I'd just
do 4.0 etc.
While 2.6 has certainly worn out, already thinking of a 4.0 is highly
reminiscient of the version number arms race Firefox and ChromeBrowser
are doing currently.
Because all our releases are supposed to be stable releases these
days, and if we get rid of one level of numbering, I feel perfectly
fine with getting rid of the even/odd history too.
If I remember past-time discussions right, ELF was the contributing
factor to bump the major number to 2.0 back then; ever since 2.0, no
similarly breakthrough-ing event has occurred.
What then about BKL removal? Nice place to celebrate with version jump
and heaving some beers.
Well, if we're looking at ELF-sized ABI changes, how about 3.0 be the
release where we re-sync the syscall numbers on all the archs? ;)
pgp21lBpIoZeR.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
