Re: [Linaro-mm-sig] [RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism

[Anca Emanuel]

On Tue, Dec 20, 2011 at 4:05 AM, Robert Morell  wrote:
>
> One of the goals of this project is to unify the fragmented space of the
> ARM SoC memory managers so that each vendor doesn't implement their own,
> and they can all be closer to mainline.

That is a very good objective.

> I fear that restricting the use of this buffer sharing mechanism to GPL
> drivers only will prevent that goal from being achieved, if an SoC
> driver has to interact with modules that use a non-GPL license.

If nobody from nvidia have any experience with this kind of work...
Look at Intel. Why are you afraid of ?

> As a hypothetical example, consider laptops that have multiple GPUs.
> Today, these ship with onboard graphics (integrated to the CPU or
> chipset) along with a discrete GPU, where in many cases only the onboard
> graphics can actually display to the screen.  In order for anything
> rendered by the discrete GPU to be displayed, it has to be copied to
> memory available for the smaller onboard graphics to texture from or
> display directly.  Obviously, that's best done by sharing dma buffers
> rather than bouncing them through the GPU.  It's not much of a stretch
> to imagine that we'll see such systems with a Tegra CPU/GPU plus a
> discrete GPU in the future; in that case, we'd want to be able to share
> memory between the discrete GPU and the Tegra system.  In that scenario,
> if this interface is GPL-only, we'd be unable to adopt the dma_buffer
> sharing mechanism for Tegra.
>
> (This isn't too pie-in-the-sky, either; people are already combining
> Tegra with discrete GPUs:
> http://blogs.nvidia.com/2011/11/world%e2%80%99s-first-arm-based-supercomputer-to-launch-in-barcelona/
> )
>
> Thanks,
> Robert

There are other problems ? Some secret agreements with Microsoft ?

I hope to see something open sourced. You can do it nVidia.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Linux 3.4-rc1

[Anca Emanuel]

@Subash Patel, prime is already included.

Why the CMA is at 24 version and still not included ?
Linus, please include
CMA,git://git.linaro.org/people/mszyprowski/linux-dma-mapping.git
3.4-rc1-cma-v24
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm for rc1

[Anca Emanuel]

On Tue, Jan 11, 2011 at 6:01 PM, Linus Torvalds
 wrote:
> On Mon, Jan 10, 2011 at 10:06 PM, Jesse Barnes  
> wrote:
>>
>> Arg.  It's been ok on my ILK systems, but Chris has found some issues with 
>> out watermarking code iirc; apparently we're underflowing the display FIFO, 
>> causing all sorts of trouble.  If it works before the pull of Dave's tree, 
>> can you bisect?
>
> There's no way to bisect this thing - it started happening after 2
> hours (first message at 8287.139375 seconds from boot, to be exact).
> So far only once, but that's possibly because I've been asleep for the
> last eight hours ;)
>
> But yes, it worked before pulling Dave's tree, IOW, I haven't seen
> this message on this machine before.
>
> And as mentioned, this is a regular machine, not one of my
> preproduction things that tend to have odd silicon or BIOSes.
> Bog-standard Core i5 on an Asus P7H57D-V EVO motherboard. The fanciest
> part of that machine is the silent case ;)
>
> Chris wrote:
>> Linus, is anything else kicked off upon powersaving? A screen saver or is
>> it just the blanking that triggers the mess?
>
> So I don't _know_ that it was the screen saver that triggered, but I
> do know that it started happening while I was out to pick up a kid
> from gymnastics. So the screen saver was pretty much the only thing
> going on apart from an idle desktop with a few terminals and chrome.
>
> And it's not even a 3D screen saver or anything graphically fancy,
> it's just the "show random photos" one (it eventually does blank too,
> but I think I've set the blanking interval to an hour or something).
> But compiz was on.
>
>                         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/
>

Linus, 2.6.37-git4 works for me, can you unpull the DRM, and wait
until is more stable ?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm for rc1

[Anca Emanuel]

On Tue, Jan 11, 2011 at 6:11 PM, Anca Emanuel  wrote:
> Linus, 2.6.37-git4 works for me, can you unpull the DRM, and wait
> until is more stable ?

What I have done:
git bisect log
git bisect start
# bad: [5b2eef966cb2ae307aa4ef1767f7307774bc96ca] Merge branch
'drm-core-next' of
git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6
git bisect bad 5b2eef966cb2ae307aa4ef1767f7307774bc96ca
# good: [3c0eee3fe6a3a1c745379547c7e7c904aa64f6d5] Linux 2.6.37
git bisect good 3c0eee3fe6a3a1c745379547c7e7c904aa64f6d5
# good: [c413521eb4e2d7ffd5ce432a144708d479054bd3] ARM: mach-shmobile:
update for SMP changes.
git bisect good c413521eb4e2d7ffd5ce432a144708d479054bd3
# bad: [78c92a9fd4b6abbbc1fe1ec335c697cb4e63f252] Merge branch
'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6
git bisect bad 78c92a9fd4b6abbbc1fe1ec335c697cb4e63f252
# bad: [da40d036fd716f0efb2917076220814b1e927ae1] Merge
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6
git bisect bad da40d036fd716f0efb2917076220814b1e927ae1
# bad: [dc69d1af9e8d9cbbabff88bb35a6782187a9] omap2: Make
OMAP2PLUS select OMAP_DM_TIMER
git bisect bad dc69d1af9e8d9cbbabff88bb35a6782187a9

Second bisect bad: nouveau not loaded, but I have an usable system.
I don't feel I'm doing it right.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm for rc1

[Anca Emanuel]

Dave, in the future, can you make pull requests like Ingo ?
What I mean:
non-drm
generic
power
nouveau
radeon
intel
others
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm for rc1

[Anca Emanuel]

On Wed, Jan 12, 2011 at 1:21 PM, Christian Borntraeger
 wrote:
> Am 12.01.2011 00:28, schrieb Linus Torvalds:
>> On Tue, Jan 11, 2011 at 3:20 PM, Christian Borntraeger
>>  wrote:
>>>
>>> Now nouveau framebuffer is completely broken on my T61p (01:00.0 VGA 
>>> compatible controller: nVidia Corporation G84M [Quadro FX 570M] (rev a1))
>>> During startup the framebuffer shows only stripes and a blank
>>> screen after suspend/resume.
>>> I also see lots of TRAP messages. (see below).
>>> X11 seems to work fine though...
>>
>> Can you try to bisect?
>
> dfe63bb0ad9810db13aab0058caba97866e0a681 is the first bad commit
> commit dfe63bb0ad9810db13aab0058caba97866e0a681
> Author: James Simmons 
> Date:   Thu Dec 23 16:40:37 2010 +
>
>    drm: Update fbdev fb_fix_screeninfo
>
>
> Reverting this on top of todays git also fixes my problem.
>
> Christian
> --
> 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/
>

I tested the revert: the boot screen did change the resolution
(without it don't), but my PC still hangs. (using an nvidia 8800GT).
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm for rc1

[Anca Emanuel]

On Wed, Jan 12, 2011 at 3:45 PM, James Simmons  wrote:
>
>> On Wed, Jan 12, 2011 at 1:21 PM, Christian Borntraeger
>>  wrote:
>> > Am 12.01.2011 00:28, schrieb Linus Torvalds:
>> >> On Tue, Jan 11, 2011 at 3:20 PM, Christian Borntraeger
>> >>  wrote:
>> >>>
>> >>> Now nouveau framebuffer is completely broken on my T61p (01:00.0 VGA 
>> >>> compatible controller: nVidia Corporation G84M [Quadro FX 570M] (rev a1))
>> >>> During startup the framebuffer shows only stripes and a blank
>> >>> screen after suspend/resume.
>> >>> I also see lots of TRAP messages. (see below).
>> >>> X11 seems to work fine though...
>> >>
>> >> Can you try to bisect?
>> >
>> > dfe63bb0ad9810db13aab0058caba97866e0a681 is the first bad commit
>> > commit dfe63bb0ad9810db13aab0058caba97866e0a681
>> > Author: James Simmons 
>> > Date:   Thu Dec 23 16:40:37 2010 +
>> >
>> >    drm: Update fbdev fb_fix_screeninfo
>> >
>> >
>> > Reverting this on top of todays git also fixes my problem.
>> >
>> > Christian
>> > --
>> > 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/
>> >
>>
>> I tested the revert: the boot screen did change the resolution
>> (without it don't), but my PC still hangs. (using an nvidia 8800GT).
>
> Try my most recent patch. Where does it hang at? Any logs?
>

My keyboard is not working, I can not make an log.
I see 'something' on the screen, I hear the boot song sometimes.

I will test it your parch, but for me it will take over 1 hour.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm for rc1

[Anca Emanuel]

On Wed, Jan 12, 2011 at 5:13 PM, Anca Emanuel  wrote:
> On Wed, Jan 12, 2011 at 3:45 PM, James Simmons  wrote:
>>
>>> On Wed, Jan 12, 2011 at 1:21 PM, Christian Borntraeger
>>>  wrote:
>>> > Am 12.01.2011 00:28, schrieb Linus Torvalds:
>>> >> On Tue, Jan 11, 2011 at 3:20 PM, Christian Borntraeger
>>> >>  wrote:
>>> >>>
>>> >>> Now nouveau framebuffer is completely broken on my T61p (01:00.0 VGA 
>>> >>> compatible controller: nVidia Corporation G84M [Quadro FX 570M] (rev 
>>> >>> a1))
>>> >>> During startup the framebuffer shows only stripes and a blank
>>> >>> screen after suspend/resume.
>>> >>> I also see lots of TRAP messages. (see below).
>>> >>> X11 seems to work fine though...
>>> >>
>>> >> Can you try to bisect?
>>> >
>>> > dfe63bb0ad9810db13aab0058caba97866e0a681 is the first bad commit
>>> > commit dfe63bb0ad9810db13aab0058caba97866e0a681
>>> > Author: James Simmons 
>>> > Date:   Thu Dec 23 16:40:37 2010 +
>>> >
>>> >    drm: Update fbdev fb_fix_screeninfo
>>> >
>>> >
>>> > Reverting this on top of todays git also fixes my problem.
>>> >
>>> > Christian
>>> > --
>>> > 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/
>>> >
>>>
>>> I tested the revert: the boot screen did change the resolution
>>> (without it don't), but my PC still hangs. (using an nvidia 8800GT).
>>
>> Try my most recent patch. Where does it hang at? Any logs?
>>
>
> With your patch, I can boot the system. But nouveau is not loaded.
> dmesg attached.
>

Forget to mention: the revert makes first steps of boot look the same
(change the resolution of the text)
but with your patch, I see a big ugly ununtu logo, (I think that is
because nouveau is not loaded)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm for rc1

[Anca Emanuel]

On Wed, Jan 12, 2011 at 5:40 PM, James Simmons  wrote:
>
>> >>> I tested the revert: the boot screen did change the resolution
>> >>> (without it don't), but my PC still hangs. (using an nvidia 8800GT).
>> >>
>> >> Try my most recent patch. Where does it hang at? Any logs?
>> >>
>> >
>> > With your patch, I can boot the system. But nouveau is not loaded.
>> > dmesg attached.
>> >
>>
>> Forget to mention: the revert makes first steps of boot look the same
>> (change the resolution of the text)
>> but with your patch, I see a big ugly ununtu logo, (I think that is
>> because nouveau is not loaded)
>
> Is nouveau a module? Does X run? From my understanding is the xorg driver

I didn't modified any option, from the standard Ubuntu 10.10

> need KMS to run. I didn't see nouveau at all in your dmesg.

Exact. I mentioned this when I tested 'next' versions from last year.
The answer is in dfe63bb0ad9810db13aab0058caba97866e0a681.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm for rc1

[Anca Emanuel]

P.S. My laptop: radeon 3470 works perfect.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm for rc1

[Anca Emanuel]

On Fri, Jan 14, 2011 at 6:38 PM, James Simmons  wrote:
>
> On Thu, 13 Jan 2011, Anca Emanuel wrote:
>
>> On Thu, Jan 13, 2011 at 7:55 PM, James Simmons  
>> wrote:
>> >
>> >> > > With your patch, I can boot the system. But nouveau is not loaded.
>> >> > > dmesg attached.
>> >> > >
>> >> >
>> >> > Forget to mention: the revert makes first steps of boot look the same
>> >> > (change the resolution of the text)
>> >> > but with your patch, I see a big ugly ununtu logo, (I think that is
>> >> > because nouveau is not loaded)
>> >
>> > Okay, can you do one more experiment for me. Since you already reverted
>> > the patch to get it booting I like to ask you to add
>> >
>> > drm_fb_helper_fill_fix(info, fb_helper->fb);
>> >
>> > back into the drm_fb_helper_set_par function in drm_fb_helper.c. You have
>> > something like this:
>> >
>> >        mutex_lock(&dev->mode_config.mutex);
>> >        for (i = 0; i < fb_helper->crtc_count; i++) {
>> >                crtc = fb_helper->crtc_info[i].mode_set.crtc;
>> >                ret = 
>> > crtc->funcs->set_config(&fb_helper->crtc_info[i].mode_set);
>> >                if (ret) {
>> >                        mutex_unlock(&dev->mode_config.mutex);
>> >                        return ret;
>> >                }
>> >                drm_fb_helper_fill_fix(info, fb_helper->fb);
>> >        }
>> >        mutex_unlock(&dev->mode_config.mutex);
>> >
>> > Tell me if your system is still usable after that. Thanks for testing for
>> > me.
>> >
>>
>> after
>>
>> git revert dfe63bb0ad9810db13aab0058caba97866e0a681
>>
>> and
>>
>>
>> diff --git a/drivers/gpu/drm/drm_fb_helper.c 
>> b/drivers/gpu/drm/drm_fb_helper.c
>> index 5c4f9b9..2aad663 100644
>> --- a/drivers/gpu/drm/drm_fb_helper.c
>> +++ b/drivers/gpu/drm/drm_fb_helper.c
>> @@ -816,6 +816,7 @@ int drm_fb_helper_set_par(struct fb_info *info)
>>                         mutex_unlock(&dev->mode_config.mutex);
>>                         return ret;
>>                 }
>> +               drm_fb_helper_fill_fix(info, fb_helper->fb->pitch, 
>> fb_helper->fb
>>         }
>>         mutex_unlock(&dev->mode_config.mutex);
>>
>> I get an working system. ( the boot screen is not ok )
>> Tested suspend/resume. Dmesg attached.
>
> Just as I thought. Even this breaks the nouveau driver.
>
> Could you now add also in the drm_fb_helper_fill_fix function
>
> DRM_INFO("pitch %d, depth %d\n", fb_helper->fb->pitch,
>          fb_helper->fb->depth);
>
> I have a feeling the values are not right. Thanks.
>

Please make an patch to test.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm for rc1

[Anca Emanuel]

On Fri, Jan 14, 2011 at 8:26 PM, James Simmons  wrote:
>
>> > Just as I thought. Even this breaks the nouveau driver.
>> >
>> > Could you now add also in the drm_fb_helper_fill_fix function
>> >
>> > DRM_INFO("pitch %d, depth %d\n", fb_helper->fb->pitch,
>> >          fb_helper->fb->depth);
>> >
>> > I have a feeling the values are not right. Thanks.
>> >
>>
>> Please make an patch to test.
>
> Done. I had to test the patch myself. No need to do a revert. Just apply
> this patch to linus tree. Then send the dmesg to me. Thanks.
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 0307d60..beded14 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -609,6 +609,7 @@ EXPORT_SYMBOL(drm_fb_helper_fini);
>
>  void drm_fb_helper_fill_fix(struct fb_info *info, struct drm_framebuffer *fb)
>  {
> +       DRM_INFO("pitch %d, depth %d\n", fb->pitch, fb->depth);
>        info->fix.type = FB_TYPE_PACKED_PIXELS;
>        info->fix.visual = fb->depth == 8 ? FB_VISUAL_PSEUDOCOLOR :
>                FB_VISUAL_TRUECOLOR;
> @@ -973,7 +974,6 @@ int drm_fb_helper_single_fb_probe(struct drm_fb_helper 
> *fb_helper,
>
>        if (new_fb) {
>                info->var.pixclock = 0;
> -               drm_fb_helper_fill_fix(info, fb_helper->fb);
>                if (register_framebuffer(info) < 0) {
>                        return -EINVAL;
>                }
> diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c 
> b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
> index a26d047..fe87319 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
> @@ -359,6 +359,7 @@ nouveau_fbcon_create(struct nouveau_fbdev *nfbdev,
>        info->screen_base = nvbo_kmap_obj_iovirtual(nouveau_fb->nvbo);
>        info->screen_size = size;
>
> +       drm_fb_helper_fill_fix(info, fb);
>        drm_fb_helper_fill_var(info, &nfbdev->helper, sizes->fb_width, 
> sizes->fb_height);
>
>        /* Set aperture base/size for vesafb takeover */

I will test it, but first, I will need to disable the cassini driver,
because it can not compile.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm for rc1

[Anca Emanuel]

On Fri, Jan 14, 2011 at 8:40 PM, Anca Emanuel  wrote:
> On Fri, Jan 14, 2011 at 8:26 PM, James Simmons  wrote:
>>
>>> > Just as I thought. Even this breaks the nouveau driver.
>>> >
>>> > Could you now add also in the drm_fb_helper_fill_fix function
>>> >
>>> > DRM_INFO("pitch %d, depth %d\n", fb_helper->fb->pitch,
>>> >          fb_helper->fb->depth);
>>> >
>>> > I have a feeling the values are not right. Thanks.
>>> >
>>>
>>> Please make an patch to test.
>>
>> Done. I had to test the patch myself. No need to do a revert. Just apply
>> this patch to linus tree. Then send the dmesg to me. Thanks.
>>
>> diff --git a/drivers/gpu/drm/drm_fb_helper.c 
>> b/drivers/gpu/drm/drm_fb_helper.c
>> index 0307d60..beded14 100644
>> --- a/drivers/gpu/drm/drm_fb_helper.c
>> +++ b/drivers/gpu/drm/drm_fb_helper.c
>> @@ -609,6 +609,7 @@ EXPORT_SYMBOL(drm_fb_helper_fini);
>>
>>  void drm_fb_helper_fill_fix(struct fb_info *info, struct drm_framebuffer 
>> *fb)
>>  {
>> +       DRM_INFO("pitch %d, depth %d\n", fb->pitch, fb->depth);
>>        info->fix.type = FB_TYPE_PACKED_PIXELS;
>>        info->fix.visual = fb->depth == 8 ? FB_VISUAL_PSEUDOCOLOR :
>>                FB_VISUAL_TRUECOLOR;
>> @@ -973,7 +974,6 @@ int drm_fb_helper_single_fb_probe(struct drm_fb_helper 
>> *fb_helper,
>>
>>        if (new_fb) {
>>                info->var.pixclock = 0;
>> -               drm_fb_helper_fill_fix(info, fb_helper->fb);
>>                if (register_framebuffer(info) < 0) {
>>                        return -EINVAL;
>>                }
>> diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c 
>> b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
>> index a26d047..fe87319 100644
>> --- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
>> +++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
>> @@ -359,6 +359,7 @@ nouveau_fbcon_create(struct nouveau_fbdev *nfbdev,
>>        info->screen_base = nvbo_kmap_obj_iovirtual(nouveau_fb->nvbo);
>>        info->screen_size = size;
>>
>> +       drm_fb_helper_fill_fix(info, fb);
>>        drm_fb_helper_fill_var(info, &nfbdev->helper, sizes->fb_width, 
>> sizes->fb_height);
>>
>>        /* Set aperture base/size for vesafb takeover */
>
> I will test it, but first, I will need to disable the cassini driver,
> because it can not compile.
>

I will test this first:

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 0307d60..beded14 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -609,6 +609,7 @@ EXPORT_SYMBOL(drm_fb_helper_fini);

 void drm_fb_helper_fill_fix(struct fb_info *info, struct drm_framebuffer *fb)
 {
+   DRM_INFO("pitch %d, depth %d\n", fb->pitch, fb->depth);
info->fix.type = FB_TYPE_PACKED_PIXELS;
info->fix.visual = fb->depth == 8 ? FB_VISUAL_PSEUDOCOLOR :
FB_VISUAL_TRUECOLOR;
@@ -973,7 +974,6 @@ int drm_fb_helper_single_fb_probe(struct drm_fb_helper *fb_h

if (new_fb) {
info->var.pixclock = 0;
-   drm_fb_helper_fill_fix(info, fb_helper->fb);
if (register_framebuffer(info) < 0) {
return -EINVAL;
}
diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c b/drivers/gpu/drm/nouveau/n
index a26d047..3896771 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 0307d60..beded14 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -609,6 +609,7 @@ EXPORT_SYMBOL(drm_fb_helper_fini);

 void drm_fb_helper_fill_fix(struct fb_info *info, struct drm_framebuffer *fb)
 {
+   DRM_INFO("pitch %d, depth %d\n", fb->pitch, fb->depth);
info->fix.type = FB_TYPE_PACKED_PIXELS;
info->fix.visual = fb->depth == 8 ? FB_VISUAL_PSEUDOCOLOR :
FB_VISUAL_TRUECOLOR;
@@ -973,7 +974,6 @@ int drm_fb_helper_single_fb_probe(struct drm_fb_helper *fb_h

if (new_fb) {
info->var.pixclock = 0;
-   drm_fb_helper_fill_fix(info, fb_helper->fb);
if (register_framebuffer(info) < 0) {
return -EINVAL;
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 4/5] nouveau: Change the backlight parent device to the connector, not the PCI dev

[Anca Emanuel]

On Fri, Jan 14, 2011 at 9:24 PM, Matthew Garrett  wrote:
> We may eventually end up with per-connector backlights, especially with
> ddcci devices. Make sure that the parent node for the backlight device is
> the connector rather than the PCI device.
>
> Signed-off-by: Matthew Garrett 
> ---
>  drivers/gpu/drm/nouveau/nouveau_backlight.c |   24 ++--
>  drivers/gpu/drm/nouveau/nouveau_connector.c |    9 +
>  drivers/gpu/drm/nouveau/nouveau_drv.h       |    8 
>  drivers/gpu/drm/nouveau/nouveau_state.c     |    6 --
>  4 files changed, 27 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c 
> b/drivers/gpu/drm/nouveau/nouveau_backlight.c
> index 18d7bcc..00a55df 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_backlight.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c
> @@ -88,10 +88,11 @@ static const struct backlight_ops nv50_bl_ops = {
>        .update_status = nv50_set_intensity,
>  };
>
> -static int nouveau_nv40_backlight_init(struct drm_device *dev)
> +static int nouveau_nv40_backlight_init(struct drm_connector *connector)
>  {
> -       struct backlight_properties props;
> +       struct drm_device *dev = connector->dev;
>        struct drm_nouveau_private *dev_priv = dev->dev_private;
> +       struct backlight_properties props;
>        struct backlight_device *bd;
>
>        if (!(nv_rd32(dev, NV40_PMC_BACKLIGHT) & NV40_PMC_BACKLIGHT_MASK))
> @@ -100,7 +101,7 @@ static int nouveau_nv40_backlight_init(struct drm_device 
> *dev)
>        memset(&props, 0, sizeof(struct backlight_properties));
>        props.type = BACKLIGHT_RAW;
>        props.max_brightness = 31;
> -       bd = backlight_device_register("nv_backlight", &dev->pdev->dev, dev,
> +       bd = backlight_device_register("nv_backlight", &connector->kdev, dev,
>                                       &nv40_bl_ops, &props);
>        if (IS_ERR(bd))
>                return PTR_ERR(bd);
> @@ -112,10 +113,11 @@ static int nouveau_nv40_backlight_init(struct 
> drm_device *dev)
>        return 0;
>  }
>
> -static int nouveau_nv50_backlight_init(struct drm_device *dev)
> +static int nouveau_nv50_backlight_init(struct drm_connector *connector)
>  {
> -       struct backlight_properties props;
> +       struct drm_device *dev = connector->dev;
>        struct drm_nouveau_private *dev_priv = dev->dev_private;
> +       struct backlight_properties props;
>        struct backlight_device *bd;
>
>        if (!nv_rd32(dev, NV50_PDISPLAY_SOR_BACKLIGHT))
> @@ -124,7 +126,7 @@ static int nouveau_nv50_backlight_init(struct drm_device 
> *dev)
>        memset(&props, 0, sizeof(struct backlight_properties));
>        props.type = BACKLIGHT_RAW;
>        props.max_brightness = 1025;
> -       bd = backlight_device_register("nv_backlight", &dev->pdev->dev, dev,
> +       bd = backlight_device_register("nv_backlight", &connector->kdev, dev,
>                                       &nv50_bl_ops, &props);
>        if (IS_ERR(bd))
>                return PTR_ERR(bd);
> @@ -135,8 +137,9 @@ static int nouveau_nv50_backlight_init(struct drm_device 
> *dev)
>        return 0;
>  }
>
> -int nouveau_backlight_init(struct drm_device *dev)
> +int nouveau_backlight_init(struct drm_connector *connector)
>  {
> +       struct drm_device *dev = connector->dev;
>        struct drm_nouveau_private *dev_priv = dev->dev_private;
>
>  #ifdef CONFIG_ACPI
> @@ -149,9 +152,9 @@ int nouveau_backlight_init(struct drm_device *dev)
>
>        switch (dev_priv->card_type) {
>        case NV_40:
> -               return nouveau_nv40_backlight_init(dev);
> +               return nouveau_nv40_backlight_init(connector);
>        case NV_50:
> -               return nouveau_nv50_backlight_init(dev);
> +               return nouveau_nv50_backlight_init(connector);
>        default:
>                break;
>        }
> @@ -159,8 +162,9 @@ int nouveau_backlight_init(struct drm_device *dev)
>        return 0;
>  }
>
> -void nouveau_backlight_exit(struct drm_device *dev)
> +void nouveau_backlight_exit(struct drm_connector *connector)
>  {
> +       struct drm_device *dev = connector->dev;
>        struct drm_nouveau_private *dev_priv = dev->dev_private;
>
>        if (dev_priv->backlight) {
> diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c 
> b/drivers/gpu/drm/nouveau/nouveau_connector.c
> index a21e000..3a1ecc7 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_connector.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
> @@ -116,6 +116,10 @@ nouveau_connector_destroy(struct drm_connector 
> *connector)
>                                      nouveau_connector_hotplug, connector);
>        }
>
> +       if (connector->connector_type == DRM_MODE_CONNECTOR_LVDS ||
> +           connector->connector_type == DRM_MODE_CONNECTOR_eDP)
> +               nouveau_backlight_exit(connector);
> +
>        kfree(nv_connector->edid);
>        drm_sysfs_connector_remove(connector);
>        drm_connector_cleanup(connector);
> 

Re: [git pull] drm fixes

[Anca Emanuel]

Nouveau OpenGL regresion

Tools used: http://packages.ubuntu.com/maverick/misc/glmark2

With 2.6.38-rc5 latest git:
nv50_screen_get_param:162 -  Unknown PIPE_CAP 11
===
glmark2 10.07.1
===
OpenGL Information
GL_VENDOR: nouveau
GL_RENDERER:   Gallium 0.4 on NV92
GL_VERSION:2.1 Mesa 7.9-devel
===
Precompilation
Vertex array  FPS: 105
Vertex buffer object  FPS: 267
Texture filtering
Nearest   FPS: 295
LinearFPS: 299
Mipmapped FPS: 308
Shading
GLSL per vertex lighting  FPS: 227
GLSL per pixel lighting   FPS: 260
===
Your glmark2 Score is 727  ^_^
===


With Linux ubuntu 2.6.35-25-generic #44-Ubuntu SMP Fri Jan 21 17:40:44
UTC 2011 x86_64 GNU/Linux:

nv50_screen_get_param:162 -  Unknown PIPE_CAP 11
===
glmark2 10.07.1
===
OpenGL Information
GL_VENDOR: nouveau
GL_RENDERER:   Gallium 0.4 on NV92
GL_VERSION:2.1 Mesa 7.9-devel
===
Precompilation
Vertex array  FPS: 265
Vertex buffer object  FPS: 599
Texture filtering
Nearest   FPS: 687
LinearFPS: 683
Mipmapped FPS: 717
Shading
GLSL per vertex lighting  FPS: 480
GLSL per pixel lighting   FPS: 524
===
Your glmark2 Score is 1628  ^_^
===
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Linux 2.6.38-rc6

[Anca Emanuel]

On Wed, Feb 23, 2011 at 6:32 PM, Linus Torvalds
 wrote:
> On Tue, Feb 22, 2011 at 9:42 PM, Anca Emanuel  wrote:
>> General protection fault:
>> http://i.imgur.com/TBJ6y.jpg
>>
>> dmesg: http://pastebin.com/qD8pR8QH
>> config: http://pastebin.com/XEurtHWi
>
> That's drivers/video/fbmem.c: fb_release(), and the "Code:"
> disassembly shows that it is
>
>  1b:   e8 f7 c0 29 00          callq  xyz
>  20:   48 8b 93 b8 03 00 00    mov    0x3b8(%rbx),%rdx
>  27:*  48 8b 42 10             mov    0x10(%rdx),%rax     <-- trapping 
> instruction
>
> which corresponds to
>
>        mutex_lock(&info->lock);
>        if (info->fbops->fb_release)
>                info->fbops->fb_release(info,1);
>
> so it looks like 'info->fbops' is invalid. It's in %rdx, and is
> 0x00d000ae00b500c2, which is definitely not a valid pointer. Looks
> like some bad corruption (looks like a sequence of 16-bit numbers, but
> it could be anything).
>
> Looks like nouveafb took over from vesafb. Did you do anything special
> to trigger this?

No. Just boot the system.

>
> Also, you do seem to have some extra patches (yama at the least). Anything 
> else?

I used git clone, nothing else.
First time 2.6.38-rc6 was working.
After an update from ubuntu I get that error at boot.

The dmesg is from Ubuntu 11.04 with their kernel and is working fine.

>
>                            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: Linux 2.6.38-rc6

[Anca Emanuel]

On Thu, Feb 24, 2011 at 2:28 AM, Linus Torvalds
 wrote:
> On Wed, Feb 23, 2011 at 9:16 AM, Anca Emanuel  wrote:
>>>
>>> Looks like nouveafb took over from vesafb. Did you do anything special
>>> to trigger this?
>>
>> No. Just boot the system.
>
> Every boot?

Yes.

>
> And just out of interest, what happens if you don't have the vesafb
> driver at all?
>
>                          Linus
>

I used 'e' option from grub, removed the 'set gfxpayload = $linux_gfx_mode'
and it works.

dmesg: http://pastebin.com/JAZsk4vD
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Linux 2.6.38-rc6

[Anca Emanuel]

On Thu, Feb 24, 2011 at 6:37 PM, Linus Torvalds
 wrote:
> On Thu, Feb 24, 2011 at 5:20 AM, Anca Emanuel  wrote:
>>>
>>> Every boot?
>>
>> Yes.
>>
>>> And just out of interest, what happens if you don't have the vesafb
>>> driver at all?
>>
>> I used 'e' option from grub, removed the 'set gfxpayload = $linux_gfx_mode'
>> and it works.
>>
>> dmesg: http://pastebin.com/JAZsk4vD
>
> Hmm. So it definitely seems to be the hand-over.
>
> Does this patch make any difference? When we unregister the old
> framebuffer, we still leave it in the registered_fb[] array, which
> looks wrong. But it would also be interesting to hear if setting
> CONFIG_SLUB_DEBUG_ON or CONFIG_DEBUG_PAGEALLOC makes any difference
> (they'd help detect accesses to free'd data structures).
>
>                          Linus
>
 drivers/video/fbmem.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
index e2bf953..e8f8925 100644
--- a/drivers/video/fbmem.c
+++ b/drivers/video/fbmem.c
@@ -1511,6 +1511,7 @@ void remove_conflicting_framebuffers(struct
apertures_struct *a,
   "%s vs %s - removing generic driver\n",
   name, registered_fb[i]->fix.id);
unregister_framebuffer(registered_fb[i]);
+   registered_fb[i] = NULL;
}
}
 }


Tested the patch, and now I get this:
dmesg: http://pastebin.com/ieMNrA7C

[   12.252328] BUG: unable to handle kernel NULL pointer dereference
at 03b8
[   12.252342] IP: [] fb_mmap+0x58/0x1d0
[   12.252354] PGD 78e6c067 PUD 78e6d067 PMD 0
[   12.252360] Oops:  [#1] SMP
[   12.252364] last sysfs file: /sys/module/snd/initstate
[   12.252370] CPU 0
[   12.252372] Modules linked in: nouveau(+) snd ttm drm_kms_helper
psmouse serio_raw drm soundcore lp snd_page_alloc i2c_algo_bit video
parport pata_marvell ahci r8169 libahci
[   12.252393]
[   12.252397] Pid: 244, comm: plymouthd Not tainted
2.6.38-rc6-git3-patch-linus+ #2 MICRO-STAR INTERNATIONAL CO.,LTD
MS-7360/MS-7360
[   12.252407] RIP: 0010:[]  []
fb_mmap+0x58/0x1d0
[   12.252414] RSP: 0018:880078e8fd88  EFLAGS: 00010293
[   12.252418] RAX: ffea RBX: 88007047d228 RCX: 
[   12.252423] RDX: 000f RSI: 88007047d228 RDI: 880078f5d840
[   12.252428] RBP: 880078e8fdc8 R08:  R09: 88007047d228
[   12.252432] R10: 88006f9d9cf0 R11: 88006f9d9d28 R12: 880037363800
[   12.252437] R13:  R14:  R15: 88007047d228
[   12.252442] FS:  7fb5fbaa4720() GS:88007fc0()
knlGS:
[   12.252448] CS:  0010 DS:  ES:  CR0: 80050033
[   12.252453] CR2: 03b8 CR3: 78e6b000 CR4: 06f0
[   12.252458] DR0:  DR1:  DR2: 
[   12.252463] DR3:  DR6: 0ff0 DR7: 0400
[   12.252468] Process plymouthd (pid: 244, threadinfo
880078e8e000, task 88003737ad80)
[   12.252473] Stack:
[   12.252476]  880037363800 00b8 880078e8fdd8
ffea
[   12.252484]  880037363800 06bb 006bb000
88007047d228
[   12.252491]  880078e8fe98 81130543 880078f5d840

[   12.252499] Call Trace:
[   12.252507]  [] mmap_region+0x3c3/0x500
[   12.252514]  [] ?
arch_get_unmapped_area_topdown+0x1ce/0x2f0
[   12.252521]  [] do_mmap_pgoff+0x344/0x380
[   12.252528]  [] ? finish_task_switch+0x41/0xe0
[   12.252535]  [] ? schedule+0x403/0xa00
[   12.252541]  [] sys_mmap_pgoff+0x1fe/0x230
[   12.252546]  [] sys_mmap+0x29/0x30
[   12.252551]  [] system_call_fastpath+0x16/0x1b
[   12.252556] Code: ba ff ff ff ff ff ff 0f 00 48 89 f3 48 8b 40 30
8b 80 b8 00 00 00 25 ff ff 0f 00 49 39 d6 4c 8b 2c c5 c0 cf aa 81 b8
ea ff ff ff <4d> 8b bd b8 03 00 00 76 1f 48 8b 5d d8 4c 8b 65 e0 4c 8b
6d e8
[   12.252603] RIP  [] fb_mmap+0x58/0x1d0
[   12.252608]  RSP 
[   12.252611] CR2: 03b8
[   12.252616] ---[ end trace 381165bafe65d748 ]---
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Linux 2.6.38-rc6

[Anca Emanuel]

On Fri, Feb 25, 2011 at 3:14 AM, Dave Airlie  wrote:
> On Thu, 2011-02-24 at 16:54 -0800, Linus Torvalds wrote:
>> On Thu, Feb 24, 2011 at 4:48 PM, Anca Emanuel  wrote:
>> >
>> > diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
>> > index e2bf953..e8f8925 100644
>> > --- a/drivers/video/fbmem.c
>> > +++ b/drivers/video/fbmem.c
>> > @@ -1511,6 +1511,7 @@ void remove_conflicting_framebuffers(struct
>> > apertures_struct *a,
>> >                               "%s vs %s - removing generic driver\n",
>> >                               name, registered_fb[i]->fix.id);
>> >                        unregister_framebuffer(registered_fb[i]);
>> > +                       registered_fb[i] = NULL;
>> >
>> > Tested the patch, and now I get this:
>> > dmesg: http://pastebin.com/ieMNrA7C
>> >
>> > [   12.252328] BUG: unable to handle kernel NULL pointer dereference
>> > at 03b8
>> > [   12.252342] IP: [] fb_mmap+0x58/0x1d0
>>
>> Ok, goodie.
>>
>> Or not so goodie, but it does make it clear that yeah, the fb code
>> seems to be using stale pointers from that registered_fb[] array, and
>> the whole unregistration process is just racing with people using it.
>>
>> Herton had that much bigger patch, can you test it?
>
> I think Andy's patch worked, not sure why it fell between the cracks,
> either didn't appear on lkml or in my inbox at all.
>
> if we can get Herton to repost it properly + a tested by I'm happy for
> it to go in.
>
> Dave.
>
>

Tested Andy's patch and it works !
http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-natty.git;a=commit;h=c5a742b5f78e161d6a13853a7e3e6e1dfa429e69

Tested-by: Anca Emanuel 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Linux 2.6.38-rc6

[Anca Emanuel]

On Fri, Feb 25, 2011 at 3:47 AM, Anca Emanuel  wrote:
> On Fri, Feb 25, 2011 at 3:14 AM, Dave Airlie  wrote:
>> On Thu, 2011-02-24 at 16:54 -0800, Linus Torvalds wrote:
>>> On Thu, Feb 24, 2011 at 4:48 PM, Anca Emanuel  
>>> wrote:
>>> >
>>> > diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
>>> > index e2bf953..e8f8925 100644
>>> > --- a/drivers/video/fbmem.c
>>> > +++ b/drivers/video/fbmem.c
>>> > @@ -1511,6 +1511,7 @@ void remove_conflicting_framebuffers(struct
>>> > apertures_struct *a,
>>> >                               "%s vs %s - removing generic driver\n",
>>> >                               name, registered_fb[i]->fix.id);
>>> >                        unregister_framebuffer(registered_fb[i]);
>>> > +                       registered_fb[i] = NULL;
>>> >
>>> > Tested the patch, and now I get this:
>>> > dmesg: http://pastebin.com/ieMNrA7C
>>> >
>>> > [   12.252328] BUG: unable to handle kernel NULL pointer dereference
>>> > at 03b8
>>> > [   12.252342] IP: [] fb_mmap+0x58/0x1d0
>>>
>>> Ok, goodie.
>>>
>>> Or not so goodie, but it does make it clear that yeah, the fb code
>>> seems to be using stale pointers from that registered_fb[] array, and
>>> the whole unregistration process is just racing with people using it.
>>>
>>> Herton had that much bigger patch, can you test it?
>>
>> I think Andy's patch worked, not sure why it fell between the cracks,
>> either didn't appear on lkml or in my inbox at all.
>>
>> if we can get Herton to repost it properly + a tested by I'm happy for
>> it to go in.
>>
>> Dave.
>>
>>
>
> Tested Andy's patch and it works !
> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-natty.git;a=commit;h=c5a742b5f78e161d6a13853a7e3e6e1dfa429e69
>
> Tested-by: Anca Emanuel 
>

link to patch: http://is.gd/otIfGc


patch
Description: Binary data
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Linux 3.4-rc1

[Anca Emanuel]

@Subash Patel, prime is already included.

Why the CMA is at 24 version and still not included ?
Linus, please include
CMA,git://git.linaro.org/people/mszyprowski/linux-dma-mapping.git
3.4-rc1-cma-v24

[Linaro-mm-sig] [RFC v2 1/2] dma-buf: Introduce dma buffer sharing mechanism

[Anca Emanuel]

On Tue, Dec 20, 2011 at 4:05 AM, Robert Morell  wrote:
>
> One of the goals of this project is to unify the fragmented space of the
> ARM SoC memory managers so that each vendor doesn't implement their own,
> and they can all be closer to mainline.

That is a very good objective.

> I fear that restricting the use of this buffer sharing mechanism to GPL
> drivers only will prevent that goal from being achieved, if an SoC
> driver has to interact with modules that use a non-GPL license.

If nobody from nvidia have any experience with this kind of work...
Look at Intel. Why are you afraid of ?

> As a hypothetical example, consider laptops that have multiple GPUs.
> Today, these ship with onboard graphics (integrated to the CPU or
> chipset) along with a discrete GPU, where in many cases only the onboard
> graphics can actually display to the screen. ?In order for anything
> rendered by the discrete GPU to be displayed, it has to be copied to
> memory available for the smaller onboard graphics to texture from or
> display directly. ?Obviously, that's best done by sharing dma buffers
> rather than bouncing them through the GPU. ?It's not much of a stretch
> to imagine that we'll see such systems with a Tegra CPU/GPU plus a
> discrete GPU in the future; in that case, we'd want to be able to share
> memory between the discrete GPU and the Tegra system. ?In that scenario,
> if this interface is GPL-only, we'd be unable to adopt the dma_buffer
> sharing mechanism for Tegra.
>
> (This isn't too pie-in-the-sky, either; people are already combining
> Tegra with discrete GPUs:
> http://blogs.nvidia.com/2011/11/world%e2%80%99s-first-arm-based-supercomputer-to-launch-in-barcelona/
> )
>
> Thanks,
> Robert

There are other problems ? Some secret agreements with Microsoft ?

I hope to see something open sourced. You can do it nVidia.

[git pull] drm fixes

[Anca Emanuel]

Nouveau OpenGL regresion

Tools used: http://packages.ubuntu.com/maverick/misc/glmark2

With 2.6.38-rc5 latest git:
nv50_screen_get_param:162 -  Unknown PIPE_CAP 11
===
glmark2 10.07.1
===
OpenGL Information
GL_VENDOR: nouveau
GL_RENDERER:   Gallium 0.4 on NV92
GL_VERSION:2.1 Mesa 7.9-devel
===
Precompilation
Vertex array  FPS: 105
Vertex buffer object  FPS: 267
Texture filtering
Nearest   FPS: 295
LinearFPS: 299
Mipmapped FPS: 308
Shading
GLSL per vertex lighting  FPS: 227
GLSL per pixel lighting   FPS: 260
===
Your glmark2 Score is 727  ^_^
===


With Linux ubuntu 2.6.35-25-generic #44-Ubuntu SMP Fri Jan 21 17:40:44
UTC 2011 x86_64 GNU/Linux:

nv50_screen_get_param:162 -  Unknown PIPE_CAP 11
===
glmark2 10.07.1
===
OpenGL Information
GL_VENDOR: nouveau
GL_RENDERER:   Gallium 0.4 on NV92
GL_VERSION:2.1 Mesa 7.9-devel
===
Precompilation
Vertex array  FPS: 265
Vertex buffer object  FPS: 599
Texture filtering
Nearest   FPS: 687
LinearFPS: 683
Mipmapped FPS: 717
Shading
GLSL per vertex lighting  FPS: 480
GLSL per pixel lighting   FPS: 524
===
Your glmark2 Score is 1628  ^_^
===

Linux 2.6.38-rc6

[Anca Emanuel]

On Wed, Feb 23, 2011 at 6:32 PM, Linus Torvalds
 wrote:
> On Tue, Feb 22, 2011 at 9:42 PM, Anca Emanuel  
> wrote:
>> General protection fault:
>> http://i.imgur.com/TBJ6y.jpg
>>
>> dmesg: http://pastebin.com/qD8pR8QH
>> config: http://pastebin.com/XEurtHWi
>
> That's drivers/video/fbmem.c: fb_release(), and the "Code:"
> disassembly shows that it is
>
> ?1b: ? e8 f7 c0 29 00 ? ? ? ? ?callq ?xyz
> ?20: ? 48 8b 93 b8 03 00 00 ? ?mov ? ?0x3b8(%rbx),%rdx
> ?27:* ?48 8b 42 10 ? ? ? ? ? ? mov ? ?0x10(%rdx),%rax ? ? <-- trapping 
> instruction
>
> which corresponds to
>
> ? ? ? ?mutex_lock(&info->lock);
> ? ? ? ?if (info->fbops->fb_release)
> ? ? ? ? ? ? ? ?info->fbops->fb_release(info,1);
>
> so it looks like 'info->fbops' is invalid. It's in %rdx, and is
> 0x00d000ae00b500c2, which is definitely not a valid pointer. Looks
> like some bad corruption (looks like a sequence of 16-bit numbers, but
> it could be anything).
>
> Looks like nouveafb took over from vesafb. Did you do anything special
> to trigger this?

No. Just boot the system.

>
> Also, you do seem to have some extra patches (yama at the least). Anything 
> else?

I used git clone, nothing else.
First time 2.6.38-rc6 was working.
After an update from ubuntu I get that error at boot.

The dmesg is from Ubuntu 11.04 with their kernel and is working fine.

>
> ? ? ? ? ? ? ? ? ? ? ? ? ? ?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/
>

Linux 2.6.38-rc6

[Anca Emanuel]

On Thu, Feb 24, 2011 at 2:28 AM, Linus Torvalds
 wrote:
> On Wed, Feb 23, 2011 at 9:16 AM, Anca Emanuel  
> wrote:
>>>
>>> Looks like nouveafb took over from vesafb. Did you do anything special
>>> to trigger this?
>>
>> No. Just boot the system.
>
> Every boot?

Yes.

>
> And just out of interest, what happens if you don't have the vesafb
> driver at all?
>
> ? ? ? ? ? ? ? ? ? ? ? ? ?Linus
>

I used 'e' option from grub, removed the 'set gfxpayload = $linux_gfx_mode'
and it works.

dmesg: http://pastebin.com/JAZsk4vD

Linux 2.6.38-rc6

[Anca Emanuel]

On Thu, Feb 24, 2011 at 6:37 PM, Linus Torvalds
 wrote:
> On Thu, Feb 24, 2011 at 5:20 AM, Anca Emanuel  
> wrote:
>>>
>>> Every boot?
>>
>> Yes.
>>
>>> And just out of interest, what happens if you don't have the vesafb
>>> driver at all?
>>
>> I used 'e' option from grub, removed the 'set gfxpayload = $linux_gfx_mode'
>> and it works.
>>
>> dmesg: http://pastebin.com/JAZsk4vD
>
> Hmm. So it definitely seems to be the hand-over.
>
> Does this patch make any difference? When we unregister the old
> framebuffer, we still leave it in the registered_fb[] array, which
> looks wrong. But it would also be interesting to hear if setting
> CONFIG_SLUB_DEBUG_ON or CONFIG_DEBUG_PAGEALLOC makes any difference
> (they'd help detect accesses to free'd data structures).
>
> ? ? ? ? ? ? ? ? ? ? ? ? ?Linus
>
 drivers/video/fbmem.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
index e2bf953..e8f8925 100644
--- a/drivers/video/fbmem.c
+++ b/drivers/video/fbmem.c
@@ -1511,6 +1511,7 @@ void remove_conflicting_framebuffers(struct
apertures_struct *a,
   "%s vs %s - removing generic driver\n",
   name, registered_fb[i]->fix.id);
unregister_framebuffer(registered_fb[i]);
+   registered_fb[i] = NULL;
}
}
 }


Tested the patch, and now I get this:
dmesg: http://pastebin.com/ieMNrA7C

[   12.252328] BUG: unable to handle kernel NULL pointer dereference
at 03b8
[   12.252342] IP: [] fb_mmap+0x58/0x1d0
[   12.252354] PGD 78e6c067 PUD 78e6d067 PMD 0
[   12.252360] Oops:  [#1] SMP
[   12.252364] last sysfs file: /sys/module/snd/initstate
[   12.252370] CPU 0
[   12.252372] Modules linked in: nouveau(+) snd ttm drm_kms_helper
psmouse serio_raw drm soundcore lp snd_page_alloc i2c_algo_bit video
parport pata_marvell ahci r8169 libahci
[   12.252393]
[   12.252397] Pid: 244, comm: plymouthd Not tainted
2.6.38-rc6-git3-patch-linus+ #2 MICRO-STAR INTERNATIONAL CO.,LTD
MS-7360/MS-7360
[   12.252407] RIP: 0010:[]  []
fb_mmap+0x58/0x1d0
[   12.252414] RSP: 0018:880078e8fd88  EFLAGS: 00010293
[   12.252418] RAX: ffea RBX: 88007047d228 RCX: 
[   12.252423] RDX: 000f RSI: 88007047d228 RDI: 880078f5d840
[   12.252428] RBP: 880078e8fdc8 R08:  R09: 88007047d228
[   12.252432] R10: 88006f9d9cf0 R11: 88006f9d9d28 R12: 880037363800
[   12.252437] R13:  R14:  R15: 88007047d228
[   12.252442] FS:  7fb5fbaa4720() GS:88007fc0()
knlGS:
[   12.252448] CS:  0010 DS:  ES:  CR0: 80050033
[   12.252453] CR2: 03b8 CR3: 78e6b000 CR4: 06f0
[   12.252458] DR0:  DR1:  DR2: 
[   12.252463] DR3:  DR6: 0ff0 DR7: 0400
[   12.252468] Process plymouthd (pid: 244, threadinfo
880078e8e000, task 88003737ad80)
[   12.252473] Stack:
[   12.252476]  880037363800 00b8 880078e8fdd8
ffea
[   12.252484]  880037363800 06bb 006bb000
88007047d228
[   12.252491]  880078e8fe98 81130543 880078f5d840

[   12.252499] Call Trace:
[   12.252507]  [] mmap_region+0x3c3/0x500
[   12.252514]  [] ?
arch_get_unmapped_area_topdown+0x1ce/0x2f0
[   12.252521]  [] do_mmap_pgoff+0x344/0x380
[   12.252528]  [] ? finish_task_switch+0x41/0xe0
[   12.252535]  [] ? schedule+0x403/0xa00
[   12.252541]  [] sys_mmap_pgoff+0x1fe/0x230
[   12.252546]  [] sys_mmap+0x29/0x30
[   12.252551]  [] system_call_fastpath+0x16/0x1b
[   12.252556] Code: ba ff ff ff ff ff ff 0f 00 48 89 f3 48 8b 40 30
8b 80 b8 00 00 00 25 ff ff 0f 00 49 39 d6 4c 8b 2c c5 c0 cf aa 81 b8
ea ff ff ff <4d> 8b bd b8 03 00 00 76 1f 48 8b 5d d8 4c 8b 65 e0 4c 8b
6d e8
[   12.252603] RIP  [] fb_mmap+0x58/0x1d0
[   12.252608]  RSP 
[   12.252611] CR2: 03b8
[   12.252616] ---[ end trace 381165bafe65d748 ]---

Linux 2.6.38-rc6

[Anca Emanuel]

On Fri, Feb 25, 2011 at 3:14 AM, Dave Airlie  wrote:
> On Thu, 2011-02-24 at 16:54 -0800, Linus Torvalds wrote:
>> On Thu, Feb 24, 2011 at 4:48 PM, Anca Emanuel  
>> wrote:
>> >
>> > diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
>> > index e2bf953..e8f8925 100644
>> > --- a/drivers/video/fbmem.c
>> > +++ b/drivers/video/fbmem.c
>> > @@ -1511,6 +1511,7 @@ void remove_conflicting_framebuffers(struct
>> > apertures_struct *a,
>> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "%s vs %s - removing generic driver\n",
>> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? name, registered_fb[i]->fix.id);
>> > ? ? ? ? ? ? ? ? ? ? ? ?unregister_framebuffer(registered_fb[i]);
>> > + ? ? ? ? ? ? ? ? ? ? ? registered_fb[i] = NULL;
>> >
>> > Tested the patch, and now I get this:
>> > dmesg: http://pastebin.com/ieMNrA7C
>> >
>> > [ ? 12.252328] BUG: unable to handle kernel NULL pointer dereference
>> > at 03b8
>> > [ ? 12.252342] IP: [] fb_mmap+0x58/0x1d0
>>
>> Ok, goodie.
>>
>> Or not so goodie, but it does make it clear that yeah, the fb code
>> seems to be using stale pointers from that registered_fb[] array, and
>> the whole unregistration process is just racing with people using it.
>>
>> Herton had that much bigger patch, can you test it?
>
> I think Andy's patch worked, not sure why it fell between the cracks,
> either didn't appear on lkml or in my inbox at all.
>
> if we can get Herton to repost it properly + a tested by I'm happy for
> it to go in.
>
> Dave.
>
>

Tested Andy's patch and it works !
http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-natty.git;a=commit;h=c5a742b5f78e161d6a13853a7e3e6e1dfa429e69

Tested-by: Anca Emanuel 

Linux 2.6.38-rc6

[Anca Emanuel]

On Fri, Feb 25, 2011 at 3:47 AM, Anca Emanuel  wrote:
> On Fri, Feb 25, 2011 at 3:14 AM, Dave Airlie  wrote:
>> On Thu, 2011-02-24 at 16:54 -0800, Linus Torvalds wrote:
>>> On Thu, Feb 24, 2011 at 4:48 PM, Anca Emanuel  
>>> wrote:
>>> >
>>> > diff --git a/drivers/video/fbmem.c b/drivers/video/fbmem.c
>>> > index e2bf953..e8f8925 100644
>>> > --- a/drivers/video/fbmem.c
>>> > +++ b/drivers/video/fbmem.c
>>> > @@ -1511,6 +1511,7 @@ void remove_conflicting_framebuffers(struct
>>> > apertures_struct *a,
>>> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "%s vs %s - removing generic driver\n",
>>> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? name, registered_fb[i]->fix.id);
>>> > ? ? ? ? ? ? ? ? ? ? ? ?unregister_framebuffer(registered_fb[i]);
>>> > + ? ? ? ? ? ? ? ? ? ? ? registered_fb[i] = NULL;
>>> >
>>> > Tested the patch, and now I get this:
>>> > dmesg: http://pastebin.com/ieMNrA7C
>>> >
>>> > [ ? 12.252328] BUG: unable to handle kernel NULL pointer dereference
>>> > at 03b8
>>> > [ ? 12.252342] IP: [] fb_mmap+0x58/0x1d0
>>>
>>> Ok, goodie.
>>>
>>> Or not so goodie, but it does make it clear that yeah, the fb code
>>> seems to be using stale pointers from that registered_fb[] array, and
>>> the whole unregistration process is just racing with people using it.
>>>
>>> Herton had that much bigger patch, can you test it?
>>
>> I think Andy's patch worked, not sure why it fell between the cracks,
>> either didn't appear on lkml or in my inbox at all.
>>
>> if we can get Herton to repost it properly + a tested by I'm happy for
>> it to go in.
>>
>> Dave.
>>
>>
>
> Tested Andy's patch and it works !
> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-natty.git;a=commit;h=c5a742b5f78e161d6a13853a7e3e6e1dfa429e69
>
> Tested-by: Anca Emanuel 
>

link to patch: http://is.gd/otIfGc
-- next part --
A non-text attachment was scrubbed...
Name: patch
Type: application/octet-stream
Size: 9934 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20110225/3cc58448/attachment-0001.obj>

[git pull] drm for rc1

[Anca Emanuel]

With kernel 2.6.37-git5, my PC hangs.
( I have an nvidia 8800GT and nouveau )

Foto attached.
-- next part --
A non-text attachment was scrubbed...
Name: screen.JPG
Type: image/jpeg
Size: 106271 bytes
Desc: not available
URL: 

[git pull] drm for rc1

[Anca Emanuel]

On Tue, Jan 11, 2011 at 6:01 PM, Linus Torvalds
 wrote:
> On Mon, Jan 10, 2011 at 10:06 PM, Jesse Barnes  
> wrote:
>>
>> Arg. ?It's been ok on my ILK systems, but Chris has found some issues with 
>> out watermarking code iirc; apparently we're underflowing the display FIFO, 
>> causing all sorts of trouble. ?If it works before the pull of Dave's tree, 
>> can you bisect?
>
> There's no way to bisect this thing - it started happening after 2
> hours (first message at 8287.139375 seconds from boot, to be exact).
> So far only once, but that's possibly because I've been asleep for the
> last eight hours ;)
>
> But yes, it worked before pulling Dave's tree, IOW, I haven't seen
> this message on this machine before.
>
> And as mentioned, this is a regular machine, not one of my
> preproduction things that tend to have odd silicon or BIOSes.
> Bog-standard Core i5 on an Asus P7H57D-V EVO motherboard. The fanciest
> part of that machine is the silent case ;)
>
> Chris wrote:
>> Linus, is anything else kicked off upon powersaving? A screen saver or is
>> it just the blanking that triggers the mess?
>
> So I don't _know_ that it was the screen saver that triggered, but I
> do know that it started happening while I was out to pick up a kid
> from gymnastics. So the screen saver was pretty much the only thing
> going on apart from an idle desktop with a few terminals and chrome.
>
> And it's not even a 3D screen saver or anything graphically fancy,
> it's just the "show random photos" one (it eventually does blank too,
> but I think I've set the blanking interval to an hour or something).
> But compiz was on.
>
> ? ? ? ? ? ? ? ? ? ? ? ? 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/
>

Linus, 2.6.37-git4 works for me, can you unpull the DRM, and wait
until is more stable ?

[git pull] drm for rc1

[Anca Emanuel]

On Tue, Jan 11, 2011 at 6:11 PM, Anca Emanuel  wrote:
> Linus, 2.6.37-git4 works for me, can you unpull the DRM, and wait
> until is more stable ?

What I have done:
git bisect log
git bisect start
# bad: [5b2eef966cb2ae307aa4ef1767f7307774bc96ca] Merge branch
'drm-core-next' of
git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6
git bisect bad 5b2eef966cb2ae307aa4ef1767f7307774bc96ca
# good: [3c0eee3fe6a3a1c745379547c7e7c904aa64f6d5] Linux 2.6.37
git bisect good 3c0eee3fe6a3a1c745379547c7e7c904aa64f6d5
# good: [c413521eb4e2d7ffd5ce432a144708d479054bd3] ARM: mach-shmobile:
update for SMP changes.
git bisect good c413521eb4e2d7ffd5ce432a144708d479054bd3
# bad: [78c92a9fd4b6abbbc1fe1ec335c697cb4e63f252] Merge branch
'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6
git bisect bad 78c92a9fd4b6abbbc1fe1ec335c697cb4e63f252
# bad: [da40d036fd716f0efb2917076220814b1e927ae1] Merge
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6
git bisect bad da40d036fd716f0efb2917076220814b1e927ae1
# bad: [dc69d1af9e8d9cbbabff88bb35a6782187a9] omap2: Make
OMAP2PLUS select OMAP_DM_TIMER
git bisect bad dc69d1af9e8d9cbbabff88bb35a6782187a9

Second bisect bad: nouveau not loaded, but I have an usable system.
I don't feel I'm doing it right.

[git pull] drm for rc1

[Anca Emanuel]

Dave, in the future, can you make pull requests like Ingo ?
What I mean:
non-drm
generic
power
nouveau
radeon
intel
others

[git pull] drm for rc1

[Anca Emanuel]

On Wed, Jan 12, 2011 at 1:21 PM, Christian Borntraeger
 wrote:
> Am 12.01.2011 00:28, schrieb Linus Torvalds:
>> On Tue, Jan 11, 2011 at 3:20 PM, Christian Borntraeger
>>  wrote:
>>>
>>> Now nouveau framebuffer is completely broken on my T61p (01:00.0 VGA 
>>> compatible controller: nVidia Corporation G84M [Quadro FX 570M] (rev a1))
>>> During startup the framebuffer shows only stripes and a blank
>>> screen after suspend/resume.
>>> I also see lots of TRAP messages. (see below).
>>> X11 seems to work fine though...
>>
>> Can you try to bisect?
>
> dfe63bb0ad9810db13aab0058caba97866e0a681 is the first bad commit
> commit dfe63bb0ad9810db13aab0058caba97866e0a681
> Author: James Simmons 
> Date: ? Thu Dec 23 16:40:37 2010 +
>
> ? ?drm: Update fbdev fb_fix_screeninfo
>
>
> Reverting this on top of todays git also fixes my problem.
>
> Christian
> --
> 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/
>

I tested the revert: the boot screen did change the resolution
(without it don't), but my PC still hangs. (using an nvidia 8800GT).

[git pull] drm for rc1

[Anca Emanuel]

On Wed, Jan 12, 2011 at 3:45 PM, James Simmons  
wrote:
>
>> On Wed, Jan 12, 2011 at 1:21 PM, Christian Borntraeger
>>  wrote:
>> > Am 12.01.2011 00:28, schrieb Linus Torvalds:
>> >> On Tue, Jan 11, 2011 at 3:20 PM, Christian Borntraeger
>> >>  wrote:
>> >>>
>> >>> Now nouveau framebuffer is completely broken on my T61p (01:00.0 VGA 
>> >>> compatible controller: nVidia Corporation G84M [Quadro FX 570M] (rev a1))
>> >>> During startup the framebuffer shows only stripes and a blank
>> >>> screen after suspend/resume.
>> >>> I also see lots of TRAP messages. (see below).
>> >>> X11 seems to work fine though...
>> >>
>> >> Can you try to bisect?
>> >
>> > dfe63bb0ad9810db13aab0058caba97866e0a681 is the first bad commit
>> > commit dfe63bb0ad9810db13aab0058caba97866e0a681
>> > Author: James Simmons 
>> > Date: ? Thu Dec 23 16:40:37 2010 +
>> >
>> > ? ?drm: Update fbdev fb_fix_screeninfo
>> >
>> >
>> > Reverting this on top of todays git also fixes my problem.
>> >
>> > Christian
>> > --
>> > 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/
>> >
>>
>> I tested the revert: the boot screen did change the resolution
>> (without it don't), but my PC still hangs. (using an nvidia 8800GT).
>
> Try my most recent patch. Where does it hang at? Any logs?
>

My keyboard is not working, I can not make an log.
I see 'something' on the screen, I hear the boot song sometimes.

I will test it your parch, but for me it will take over 1 hour.

[git pull] drm for rc1

[Anca Emanuel]

On Wed, Jan 12, 2011 at 3:45 PM, James Simmons  
wrote:
>
>> On Wed, Jan 12, 2011 at 1:21 PM, Christian Borntraeger
>>  wrote:
>> > Am 12.01.2011 00:28, schrieb Linus Torvalds:
>> >> On Tue, Jan 11, 2011 at 3:20 PM, Christian Borntraeger
>> >>  wrote:
>> >>>
>> >>> Now nouveau framebuffer is completely broken on my T61p (01:00.0 VGA 
>> >>> compatible controller: nVidia Corporation G84M [Quadro FX 570M] (rev a1))
>> >>> During startup the framebuffer shows only stripes and a blank
>> >>> screen after suspend/resume.
>> >>> I also see lots of TRAP messages. (see below).
>> >>> X11 seems to work fine though...
>> >>
>> >> Can you try to bisect?
>> >
>> > dfe63bb0ad9810db13aab0058caba97866e0a681 is the first bad commit
>> > commit dfe63bb0ad9810db13aab0058caba97866e0a681
>> > Author: James Simmons 
>> > Date: ? Thu Dec 23 16:40:37 2010 +
>> >
>> > ? ?drm: Update fbdev fb_fix_screeninfo
>> >
>> >
>> > Reverting this on top of todays git also fixes my problem.
>> >
>> > Christian
>> > --
>> > 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/
>> >
>>
>> I tested the revert: the boot screen did change the resolution
>> (without it don't), but my PC still hangs. (using an nvidia 8800GT).
>
> Try my most recent patch. Where does it hang at? Any logs?
>

With your patch, I can boot the system. But nouveau is not loaded.
dmesg attached.
-- next part --
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Linux version 2.6.37-patch+ (root at ubuntu) (gcc version 4.4.5 
(Ubuntu/Linaro 4.4.4-14ubuntu5) ) #1 SMP Wed Jan 12 16:18:26 EET 2011
[0.00] BIOS-provided physical RAM map:
[0.00]  BIOS-e820:  - 0009f800 (usable)
[0.00]  BIOS-e820: 0009f800 - 000a (reserved)
[0.00]  BIOS-e820: 000e3000 - 0010 (reserved)
[0.00]  BIOS-e820: 0010 - 7ffb (usable)
[0.00]  BIOS-e820: 7ffb - 7ffbe000 (ACPI data)
[0.00]  BIOS-e820: 7ffbe000 - 7fff (ACPI NVS)
[0.00]  BIOS-e820: 7fff - 8000 (reserved)
[0.00]  BIOS-e820: fee0 - fee01000 (reserved)
[0.00]  BIOS-e820: ffb0 - 0001 (reserved)
[0.00] Notice: NX (Execute Disable) protection cannot be enabled: 
non-PAE kernel!
[0.00] DMI present.
[0.00] DMI: MS-7360/MS-7360, BIOS V1.10 11/11/2008
[0.00] e820 update range:  - 0001 (usable) 
==> (reserved)
[0.00] e820 remove range: 000a - 0010 (usable)
[0.00] last_pfn = 0x7ffb0 max_arch_pfn = 0x10
[0.00] MTRR default type: uncachable
[0.00] MTRR fixed ranges enabled:
[0.00]   0-9 write-back
[0.00]   A-B uncachable
[0.00]   C-C write-protect
[0.00]   D-D uncachable
[0.00]   E-E write-through
[0.00]   F-F write-protect
[0.00] MTRR variable ranges enabled:
[0.00]   0 base 0 mask F8000 write-back
[0.00]   1 disabled
[0.00]   2 disabled
[0.00]   3 disabled
[0.00]   4 disabled
[0.00]   5 disabled
[0.00]   6 disabled
[0.00]   7 disabled
[0.00] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
[0.00] found SMP MP-table at [c00ff780] ff780
[0.00] Scanning 0 areas for low memory corruption
[0.00] initial memory mapped : 0 - 00c0
[0.00] init_memory_mapping: -377fe000
[0.00]  00 - 40 page 4k
[0.00]  40 - 003740 page 2M
[0.00]  003740 - 00377fe000 page 4k
[0.00] kernel direct mapping tables up to 377fe000 @ bfb000-c0
[0.00] RAMDISK: 3758a000 - 37ff
[0.00] Allocated new RAMDISK: 36b24000 - 375899bd
[0.00] Move RAMDISK from 3758a000 - 37fef9bc to 
36b24000 - 375899bc
[0.00] ACPI: RSDP 000f9bb0 00014 (v00 ACPIAM)
[0.00] ACPI: RSDT 7ffb 00040 (v01 08 RSDT0906 2008 MSFT 
0097)
[0.00] ACPI: FACP 7ffb0200 00084 (v01 08 FACP0906 2008 MSFT 
0097)
[0.00] ACPI: DSDT 7ffb0440 05595 (v01  0 0000  INTL 
20051117)
[0.00] ACPI: FACS 7ffbe000 00040
[0.00] ACPI: APIC 7ffb0390 0006C (v01 08 APIC0906 2008 MSFT 
0097)
[0.00] ACPI: MCFG 7ffb0400 0003C (v01 08 OEMMCFG  2008 MSFT 
0097)
[0.00] ACPI: OEMB 7ffbe040 00071 (v01 08 OEMB0906 2008 MSFT 
0097)
[0.00] ACPI: HPET 7ffb59e0 00038 (v01 

[git pull] drm for rc1

[Anca Emanuel]

On Wed, Jan 12, 2011 at 5:13 PM, Anca Emanuel  wrote:
> On Wed, Jan 12, 2011 at 3:45 PM, James Simmons  
> wrote:
>>
>>> On Wed, Jan 12, 2011 at 1:21 PM, Christian Borntraeger
>>>  wrote:
>>> > Am 12.01.2011 00:28, schrieb Linus Torvalds:
>>> >> On Tue, Jan 11, 2011 at 3:20 PM, Christian Borntraeger
>>> >>  wrote:
>>> >>>
>>> >>> Now nouveau framebuffer is completely broken on my T61p (01:00.0 VGA 
>>> >>> compatible controller: nVidia Corporation G84M [Quadro FX 570M] (rev 
>>> >>> a1))
>>> >>> During startup the framebuffer shows only stripes and a blank
>>> >>> screen after suspend/resume.
>>> >>> I also see lots of TRAP messages. (see below).
>>> >>> X11 seems to work fine though...
>>> >>
>>> >> Can you try to bisect?
>>> >
>>> > dfe63bb0ad9810db13aab0058caba97866e0a681 is the first bad commit
>>> > commit dfe63bb0ad9810db13aab0058caba97866e0a681
>>> > Author: James Simmons 
>>> > Date: ? Thu Dec 23 16:40:37 2010 +
>>> >
>>> > ? ?drm: Update fbdev fb_fix_screeninfo
>>> >
>>> >
>>> > Reverting this on top of todays git also fixes my problem.
>>> >
>>> > Christian
>>> > --
>>> > 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/
>>> >
>>>
>>> I tested the revert: the boot screen did change the resolution
>>> (without it don't), but my PC still hangs. (using an nvidia 8800GT).
>>
>> Try my most recent patch. Where does it hang at? Any logs?
>>
>
> With your patch, I can boot the system. But nouveau is not loaded.
> dmesg attached.
>

Forget to mention: the revert makes first steps of boot look the same
(change the resolution of the text)
but with your patch, I see a big ugly ununtu logo, (I think that is
because nouveau is not loaded)

[git pull] drm for rc1

[Anca Emanuel]

On Wed, Jan 12, 2011 at 5:40 PM, James Simmons  
wrote:
>
>> >>> I tested the revert: the boot screen did change the resolution
>> >>> (without it don't), but my PC still hangs. (using an nvidia 8800GT).
>> >>
>> >> Try my most recent patch. Where does it hang at? Any logs?
>> >>
>> >
>> > With your patch, I can boot the system. But nouveau is not loaded.
>> > dmesg attached.
>> >
>>
>> Forget to mention: the revert makes first steps of boot look the same
>> (change the resolution of the text)
>> but with your patch, I see a big ugly ununtu logo, (I think that is
>> because nouveau is not loaded)
>
> Is nouveau a module? Does X run? From my understanding is the xorg driver

I didn't modified any option, from the standard Ubuntu 10.10

> need KMS to run. I didn't see nouveau at all in your dmesg.

Exact. I mentioned this when I tested 'next' versions from last year.
The answer is in dfe63bb0ad9810db13aab0058caba97866e0a681.

[git pull] drm for rc1

[Anca Emanuel]

On Thu, Jan 13, 2011 at 7:55 PM, James Simmons  
wrote:
>
>> > > With your patch, I can boot the system. But nouveau is not loaded.
>> > > dmesg attached.
>> > >
>> >
>> > Forget to mention: the revert makes first steps of boot look the same
>> > (change the resolution of the text)
>> > but with your patch, I see a big ugly ununtu logo, (I think that is
>> > because nouveau is not loaded)
>
> Okay, can you do one more experiment for me. Since you already reverted
> the patch to get it booting I like to ask you to add
>
> drm_fb_helper_fill_fix(info, fb_helper->fb);
>
> back into the drm_fb_helper_set_par function in drm_fb_helper.c. You have
> something like this:
>
> ? ? ? ?mutex_lock(&dev->mode_config.mutex);
> ? ? ? ?for (i = 0; i < fb_helper->crtc_count; i++) {
> ? ? ? ? ? ? ? ?crtc = fb_helper->crtc_info[i].mode_set.crtc;
> ? ? ? ? ? ? ? ?ret = 
> crtc->funcs->set_config(&fb_helper->crtc_info[i].mode_set);
> ? ? ? ? ? ? ? ?if (ret) {
> ? ? ? ? ? ? ? ? ? ? ? ?mutex_unlock(&dev->mode_config.mutex);
> ? ? ? ? ? ? ? ? ? ? ? ?return ret;
> ? ? ? ? ? ? ? ?}
> ? ? ? ? ? ? ? ?drm_fb_helper_fill_fix(info, fb_helper->fb);
> ? ? ? ?}
> ? ? ? ?mutex_unlock(&dev->mode_config.mutex);
>
> Tell me if your system is still usable after that. Thanks for testing for
> me.
>

after

git revert dfe63bb0ad9810db13aab0058caba97866e0a681

and


diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 5c4f9b9..2aad663 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -816,6 +816,7 @@ int drm_fb_helper_set_par(struct fb_info *info)
mutex_unlock(&dev->mode_config.mutex);
return ret;
}
+   drm_fb_helper_fill_fix(info, fb_helper->fb->pitch, fb_helper->fb
}
mutex_unlock(&dev->mode_config.mutex);

I get an working system. ( the boot screen is not ok )
Tested suspend/resume. Dmesg attached.
-- next part --
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Linux version 2.6.37-test+ (root at ubuntu) (gcc version 4.4.5 
(Ubuntu/Linaro 4.4.4-14ubuntu5) ) #2 SMP Thu Jan 13 20:59:09 EET 2011
[0.00] BIOS-provided physical RAM map:
[0.00]  BIOS-e820:  - 0009f800 (usable)
[0.00]  BIOS-e820: 0009f800 - 000a (reserved)
[0.00]  BIOS-e820: 000e3000 - 0010 (reserved)
[0.00]  BIOS-e820: 0010 - 7ffb (usable)
[0.00]  BIOS-e820: 7ffb - 7ffbe000 (ACPI data)
[0.00]  BIOS-e820: 7ffbe000 - 7fff (ACPI NVS)
[0.00]  BIOS-e820: 7fff - 8000 (reserved)
[0.00]  BIOS-e820: fee0 - fee01000 (reserved)
[0.00]  BIOS-e820: ffb0 - 0001 (reserved)
[0.00] Notice: NX (Execute Disable) protection cannot be enabled: 
non-PAE kernel!
[0.00] DMI present.
[0.00] DMI: MS-7360/MS-7360, BIOS V1.10 11/11/2008
[0.00] e820 update range:  - 0001 (usable) 
==> (reserved)
[0.00] e820 remove range: 000a - 0010 (usable)
[0.00] last_pfn = 0x7ffb0 max_arch_pfn = 0x10
[0.00] MTRR default type: uncachable
[0.00] MTRR fixed ranges enabled:
[0.00]   0-9 write-back
[0.00]   A-B uncachable
[0.00]   C-C write-protect
[0.00]   D-D uncachable
[0.00]   E-E write-through
[0.00]   F-F write-protect
[0.00] MTRR variable ranges enabled:
[0.00]   0 base 0 mask F8000 write-back
[0.00]   1 disabled
[0.00]   2 disabled
[0.00]   3 disabled
[0.00]   4 disabled
[0.00]   5 disabled
[0.00]   6 disabled
[0.00]   7 disabled
[0.00] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
[0.00] found SMP MP-table at [c00ff780] ff780
[0.00] Scanning 0 areas for low memory corruption
[0.00] initial memory mapped : 0 - 00c0
[0.00] init_memory_mapping: -377fe000
[0.00]  00 - 40 page 4k
[0.00]  40 - 003740 page 2M
[0.00]  003740 - 00377fe000 page 4k
[0.00] kernel direct mapping tables up to 377fe000 @ bfb000-c0
[0.00] RAMDISK: 37589000 - 37ff
[0.00] Allocated new RAMDISK: 36b22000 - 375886da
[0.00] Move RAMDISK from 37589000 - 37fef6d9 to 
36b22000 - 375886d9
[0.00] ACPI: RSDP 000f9bb0 00014 (v00 ACPIAM)
[0.00] ACPI: RSDT 7ffb 00040 (v01 08 RSDT0906 2008 MSFT 
0097)
[0.00] ACPI: FACP 7ffb0200 00084 (v01 08 FACP0906 2008 MSFT 
0097)
[0.00] ACPI: DSDT 7ffb0440 05595 (v01  0

[git pull] drm for rc1

[Anca Emanuel]

P.S. My laptop: radeon 3470 works perfect.

[git pull] drm for rc1

[Anca Emanuel]

On Fri, Jan 14, 2011 at 6:38 PM, James Simmons  
wrote:
>
> On Thu, 13 Jan 2011, Anca Emanuel wrote:
>
>> On Thu, Jan 13, 2011 at 7:55 PM, James Simmons  
>> wrote:
>> >
>> >> > > With your patch, I can boot the system. But nouveau is not loaded.
>> >> > > dmesg attached.
>> >> > >
>> >> >
>> >> > Forget to mention: the revert makes first steps of boot look the same
>> >> > (change the resolution of the text)
>> >> > but with your patch, I see a big ugly ununtu logo, (I think that is
>> >> > because nouveau is not loaded)
>> >
>> > Okay, can you do one more experiment for me. Since you already reverted
>> > the patch to get it booting I like to ask you to add
>> >
>> > drm_fb_helper_fill_fix(info, fb_helper->fb);
>> >
>> > back into the drm_fb_helper_set_par function in drm_fb_helper.c. You have
>> > something like this:
>> >
>> > ? ? ? ?mutex_lock(&dev->mode_config.mutex);
>> > ? ? ? ?for (i = 0; i < fb_helper->crtc_count; i++) {
>> > ? ? ? ? ? ? ? ?crtc = fb_helper->crtc_info[i].mode_set.crtc;
>> > ? ? ? ? ? ? ? ?ret = 
>> > crtc->funcs->set_config(&fb_helper->crtc_info[i].mode_set);
>> > ? ? ? ? ? ? ? ?if (ret) {
>> > ? ? ? ? ? ? ? ? ? ? ? ?mutex_unlock(&dev->mode_config.mutex);
>> > ? ? ? ? ? ? ? ? ? ? ? ?return ret;
>> > ? ? ? ? ? ? ? ?}
>> > ? ? ? ? ? ? ? ?drm_fb_helper_fill_fix(info, fb_helper->fb);
>> > ? ? ? ?}
>> > ? ? ? ?mutex_unlock(&dev->mode_config.mutex);
>> >
>> > Tell me if your system is still usable after that. Thanks for testing for
>> > me.
>> >
>>
>> after
>>
>> git revert dfe63bb0ad9810db13aab0058caba97866e0a681
>>
>> and
>>
>>
>> diff --git a/drivers/gpu/drm/drm_fb_helper.c 
>> b/drivers/gpu/drm/drm_fb_helper.c
>> index 5c4f9b9..2aad663 100644
>> --- a/drivers/gpu/drm/drm_fb_helper.c
>> +++ b/drivers/gpu/drm/drm_fb_helper.c
>> @@ -816,6 +816,7 @@ int drm_fb_helper_set_par(struct fb_info *info)
>> ? ? ? ? ? ? ? ? ? ? ? ? mutex_unlock(&dev->mode_config.mutex);
>> ? ? ? ? ? ? ? ? ? ? ? ? return ret;
>> ? ? ? ? ? ? ? ? }
>> + ? ? ? ? ? ? ? drm_fb_helper_fill_fix(info, fb_helper->fb->pitch, 
>> fb_helper->fb
>> ? ? ? ? }
>> ? ? ? ? mutex_unlock(&dev->mode_config.mutex);
>>
>> I get an working system. ( the boot screen is not ok )
>> Tested suspend/resume. Dmesg attached.
>
> Just as I thought. Even this breaks the nouveau driver.
>
> Could you now add also in the drm_fb_helper_fill_fix function
>
> DRM_INFO("pitch %d, depth %d\n", fb_helper->fb->pitch,
> ? ? ? ? ?fb_helper->fb->depth);
>
> I have a feeling the values are not right. Thanks.
>

Please make an patch to test.

[git pull] drm for rc1

[Anca Emanuel]

On Fri, Jan 14, 2011 at 8:26 PM, James Simmons  
wrote:
>
>> > Just as I thought. Even this breaks the nouveau driver.
>> >
>> > Could you now add also in the drm_fb_helper_fill_fix function
>> >
>> > DRM_INFO("pitch %d, depth %d\n", fb_helper->fb->pitch,
>> > ? ? ? ? ?fb_helper->fb->depth);
>> >
>> > I have a feeling the values are not right. Thanks.
>> >
>>
>> Please make an patch to test.
>
> Done. I had to test the patch myself. No need to do a revert. Just apply
> this patch to linus tree. Then send the dmesg to me. Thanks.
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 0307d60..beded14 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -609,6 +609,7 @@ EXPORT_SYMBOL(drm_fb_helper_fini);
>
> ?void drm_fb_helper_fill_fix(struct fb_info *info, struct drm_framebuffer *fb)
> ?{
> + ? ? ? DRM_INFO("pitch %d, depth %d\n", fb->pitch, fb->depth);
> ? ? ? ?info->fix.type = FB_TYPE_PACKED_PIXELS;
> ? ? ? ?info->fix.visual = fb->depth == 8 ? FB_VISUAL_PSEUDOCOLOR :
> ? ? ? ? ? ? ? ?FB_VISUAL_TRUECOLOR;
> @@ -973,7 +974,6 @@ int drm_fb_helper_single_fb_probe(struct drm_fb_helper 
> *fb_helper,
>
> ? ? ? ?if (new_fb) {
> ? ? ? ? ? ? ? ?info->var.pixclock = 0;
> - ? ? ? ? ? ? ? drm_fb_helper_fill_fix(info, fb_helper->fb);
> ? ? ? ? ? ? ? ?if (register_framebuffer(info) < 0) {
> ? ? ? ? ? ? ? ? ? ? ? ?return -EINVAL;
> ? ? ? ? ? ? ? ?}
> diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c 
> b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
> index a26d047..fe87319 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
> @@ -359,6 +359,7 @@ nouveau_fbcon_create(struct nouveau_fbdev *nfbdev,
> ? ? ? ?info->screen_base = nvbo_kmap_obj_iovirtual(nouveau_fb->nvbo);
> ? ? ? ?info->screen_size = size;
>
> + ? ? ? drm_fb_helper_fill_fix(info, fb);
> ? ? ? ?drm_fb_helper_fill_var(info, &nfbdev->helper, sizes->fb_width, 
> sizes->fb_height);
>
> ? ? ? ?/* Set aperture base/size for vesafb takeover */

I will test it, but first, I will need to disable the cassini driver,
because it can not compile.

[git pull] drm for rc1

[Anca Emanuel]

On Fri, Jan 14, 2011 at 8:40 PM, Anca Emanuel  wrote:
> On Fri, Jan 14, 2011 at 8:26 PM, James Simmons  
> wrote:
>>
>>> > Just as I thought. Even this breaks the nouveau driver.
>>> >
>>> > Could you now add also in the drm_fb_helper_fill_fix function
>>> >
>>> > DRM_INFO("pitch %d, depth %d\n", fb_helper->fb->pitch,
>>> > ? ? ? ? ?fb_helper->fb->depth);
>>> >
>>> > I have a feeling the values are not right. Thanks.
>>> >
>>>
>>> Please make an patch to test.
>>
>> Done. I had to test the patch myself. No need to do a revert. Just apply
>> this patch to linus tree. Then send the dmesg to me. Thanks.
>>
>> diff --git a/drivers/gpu/drm/drm_fb_helper.c 
>> b/drivers/gpu/drm/drm_fb_helper.c
>> index 0307d60..beded14 100644
>> --- a/drivers/gpu/drm/drm_fb_helper.c
>> +++ b/drivers/gpu/drm/drm_fb_helper.c
>> @@ -609,6 +609,7 @@ EXPORT_SYMBOL(drm_fb_helper_fini);
>>
>> ?void drm_fb_helper_fill_fix(struct fb_info *info, struct drm_framebuffer 
>> *fb)
>> ?{
>> + ? ? ? DRM_INFO("pitch %d, depth %d\n", fb->pitch, fb->depth);
>> ? ? ? ?info->fix.type = FB_TYPE_PACKED_PIXELS;
>> ? ? ? ?info->fix.visual = fb->depth == 8 ? FB_VISUAL_PSEUDOCOLOR :
>> ? ? ? ? ? ? ? ?FB_VISUAL_TRUECOLOR;
>> @@ -973,7 +974,6 @@ int drm_fb_helper_single_fb_probe(struct drm_fb_helper 
>> *fb_helper,
>>
>> ? ? ? ?if (new_fb) {
>> ? ? ? ? ? ? ? ?info->var.pixclock = 0;
>> - ? ? ? ? ? ? ? drm_fb_helper_fill_fix(info, fb_helper->fb);
>> ? ? ? ? ? ? ? ?if (register_framebuffer(info) < 0) {
>> ? ? ? ? ? ? ? ? ? ? ? ?return -EINVAL;
>> ? ? ? ? ? ? ? ?}
>> diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c 
>> b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
>> index a26d047..fe87319 100644
>> --- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
>> +++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
>> @@ -359,6 +359,7 @@ nouveau_fbcon_create(struct nouveau_fbdev *nfbdev,
>> ? ? ? ?info->screen_base = nvbo_kmap_obj_iovirtual(nouveau_fb->nvbo);
>> ? ? ? ?info->screen_size = size;
>>
>> + ? ? ? drm_fb_helper_fill_fix(info, fb);
>> ? ? ? ?drm_fb_helper_fill_var(info, &nfbdev->helper, sizes->fb_width, 
>> sizes->fb_height);
>>
>> ? ? ? ?/* Set aperture base/size for vesafb takeover */
>
> I will test it, but first, I will need to disable the cassini driver,
> because it can not compile.
>

I will test this first:

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 0307d60..beded14 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -609,6 +609,7 @@ EXPORT_SYMBOL(drm_fb_helper_fini);

 void drm_fb_helper_fill_fix(struct fb_info *info, struct drm_framebuffer *fb)
 {
+   DRM_INFO("pitch %d, depth %d\n", fb->pitch, fb->depth);
info->fix.type = FB_TYPE_PACKED_PIXELS;
info->fix.visual = fb->depth == 8 ? FB_VISUAL_PSEUDOCOLOR :
FB_VISUAL_TRUECOLOR;
@@ -973,7 +974,6 @@ int drm_fb_helper_single_fb_probe(struct drm_fb_helper *fb_h

if (new_fb) {
info->var.pixclock = 0;
-   drm_fb_helper_fill_fix(info, fb_helper->fb);
if (register_framebuffer(info) < 0) {
return -EINVAL;
}
diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c b/drivers/gpu/drm/nouveau/n
index a26d047..3896771 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 0307d60..beded14 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -609,6 +609,7 @@ EXPORT_SYMBOL(drm_fb_helper_fini);

 void drm_fb_helper_fill_fix(struct fb_info *info, struct drm_framebuffer *fb)
 {
+   DRM_INFO("pitch %d, depth %d\n", fb->pitch, fb->depth);
info->fix.type = FB_TYPE_PACKED_PIXELS;
info->fix.visual = fb->depth == 8 ? FB_VISUAL_PSEUDOCOLOR :
FB_VISUAL_TRUECOLOR;
@@ -973,7 +974,6 @@ int drm_fb_helper_single_fb_probe(struct drm_fb_helper *fb_h

if (new_fb) {
info->var.pixclock = 0;
-   drm_fb_helper_fill_fix(info, fb_helper->fb);
if (register_framebuffer(info) < 0) {
return -EINVAL;
}

[PATCH 4/5] nouveau: Change the backlight parent device to the connector, not the PCI dev

[Anca Emanuel]

On Fri, Jan 14, 2011 at 9:24 PM, Matthew Garrett  wrote:
> We may eventually end up with per-connector backlights, especially with
> ddcci devices. Make sure that the parent node for the backlight device is
> the connector rather than the PCI device.
>
> Signed-off-by: Matthew Garrett 
> ---
> ?drivers/gpu/drm/nouveau/nouveau_backlight.c | ? 24 ++--
> ?drivers/gpu/drm/nouveau/nouveau_connector.c | ? ?9 +
> ?drivers/gpu/drm/nouveau/nouveau_drv.h ? ? ? | ? ?8 
> ?drivers/gpu/drm/nouveau/nouveau_state.c ? ? | ? ?6 --
> ?4 files changed, 27 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c 
> b/drivers/gpu/drm/nouveau/nouveau_backlight.c
> index 18d7bcc..00a55df 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_backlight.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c
> @@ -88,10 +88,11 @@ static const struct backlight_ops nv50_bl_ops = {
> ? ? ? ?.update_status = nv50_set_intensity,
> ?};
>
> -static int nouveau_nv40_backlight_init(struct drm_device *dev)
> +static int nouveau_nv40_backlight_init(struct drm_connector *connector)
> ?{
> - ? ? ? struct backlight_properties props;
> + ? ? ? struct drm_device *dev = connector->dev;
> ? ? ? ?struct drm_nouveau_private *dev_priv = dev->dev_private;
> + ? ? ? struct backlight_properties props;
> ? ? ? ?struct backlight_device *bd;
>
> ? ? ? ?if (!(nv_rd32(dev, NV40_PMC_BACKLIGHT) & NV40_PMC_BACKLIGHT_MASK))
> @@ -100,7 +101,7 @@ static int nouveau_nv40_backlight_init(struct drm_device 
> *dev)
> ? ? ? ?memset(&props, 0, sizeof(struct backlight_properties));
> ? ? ? ?props.type = BACKLIGHT_RAW;
> ? ? ? ?props.max_brightness = 31;
> - ? ? ? bd = backlight_device_register("nv_backlight", &dev->pdev->dev, dev,
> + ? ? ? bd = backlight_device_register("nv_backlight", &connector->kdev, dev,
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? &nv40_bl_ops, &props);
> ? ? ? ?if (IS_ERR(bd))
> ? ? ? ? ? ? ? ?return PTR_ERR(bd);
> @@ -112,10 +113,11 @@ static int nouveau_nv40_backlight_init(struct 
> drm_device *dev)
> ? ? ? ?return 0;
> ?}
>
> -static int nouveau_nv50_backlight_init(struct drm_device *dev)
> +static int nouveau_nv50_backlight_init(struct drm_connector *connector)
> ?{
> - ? ? ? struct backlight_properties props;
> + ? ? ? struct drm_device *dev = connector->dev;
> ? ? ? ?struct drm_nouveau_private *dev_priv = dev->dev_private;
> + ? ? ? struct backlight_properties props;
> ? ? ? ?struct backlight_device *bd;
>
> ? ? ? ?if (!nv_rd32(dev, NV50_PDISPLAY_SOR_BACKLIGHT))
> @@ -124,7 +126,7 @@ static int nouveau_nv50_backlight_init(struct drm_device 
> *dev)
> ? ? ? ?memset(&props, 0, sizeof(struct backlight_properties));
> ? ? ? ?props.type = BACKLIGHT_RAW;
> ? ? ? ?props.max_brightness = 1025;
> - ? ? ? bd = backlight_device_register("nv_backlight", &dev->pdev->dev, dev,
> + ? ? ? bd = backlight_device_register("nv_backlight", &connector->kdev, dev,
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? &nv50_bl_ops, &props);
> ? ? ? ?if (IS_ERR(bd))
> ? ? ? ? ? ? ? ?return PTR_ERR(bd);
> @@ -135,8 +137,9 @@ static int nouveau_nv50_backlight_init(struct drm_device 
> *dev)
> ? ? ? ?return 0;
> ?}
>
> -int nouveau_backlight_init(struct drm_device *dev)
> +int nouveau_backlight_init(struct drm_connector *connector)
> ?{
> + ? ? ? struct drm_device *dev = connector->dev;
> ? ? ? ?struct drm_nouveau_private *dev_priv = dev->dev_private;
>
> ?#ifdef CONFIG_ACPI
> @@ -149,9 +152,9 @@ int nouveau_backlight_init(struct drm_device *dev)
>
> ? ? ? ?switch (dev_priv->card_type) {
> ? ? ? ?case NV_40:
> - ? ? ? ? ? ? ? return nouveau_nv40_backlight_init(dev);
> + ? ? ? ? ? ? ? return nouveau_nv40_backlight_init(connector);
> ? ? ? ?case NV_50:
> - ? ? ? ? ? ? ? return nouveau_nv50_backlight_init(dev);
> + ? ? ? ? ? ? ? return nouveau_nv50_backlight_init(connector);
> ? ? ? ?default:
> ? ? ? ? ? ? ? ?break;
> ? ? ? ?}
> @@ -159,8 +162,9 @@ int nouveau_backlight_init(struct drm_device *dev)
> ? ? ? ?return 0;
> ?}
>
> -void nouveau_backlight_exit(struct drm_device *dev)
> +void nouveau_backlight_exit(struct drm_connector *connector)
> ?{
> + ? ? ? struct drm_device *dev = connector->dev;
> ? ? ? ?struct drm_nouveau_private *dev_priv = dev->dev_private;
>
> ? ? ? ?if (dev_priv->backlight) {
> diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c 
> b/drivers/gpu/drm/nouveau/nouveau_connector.c
> index a21e000..3a1ecc7 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_connector.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
> @@ -116,6 +116,10 @@ nouveau_connector_destroy(struct drm_connector 
> *connector)
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?nouveau_connector_hotplug, connector);
> ? ? ? ?}
>
> + ? ? ? if (connector->connector_type == DRM_MODE_CONNECTOR_LVDS ||
> + ? ? ? ? ? connector->connector_type == DRM_MODE_CONNECTOR_eDP)
> + ? ? ? ? ? ? ? nouveau_backlight_exit(connector);
> +
> ? ? ? ?kfree(nv_connector->edid);
> ? ? ? ?drm_sysfs_connector_remove(connector);
> ? ? ? ?drm_connector_cleanup(connector);
> 

[git pull] drm fixes

[Anca Emanuel]

On Mon, Jan 17, 2011 at 6:16 AM, Dave Airlie  wrote:
>
> A bunch of radeon and nouveau fixes. Ben says this should fix any
> corruption people are seeing with plymouth splash screens, and the radeon
> fixes are scattered around, the main one being not enabling PCIE GEN2 mode
> by default, seems like AGP PCIE vendors make crappy chipsets.
>
> Dave.

Tested nouveau, 8800GT, kernel 2.6.37-git17: no problems.
Sorry for the noise.
-- next part --
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Linux version 2.6.37-git17+ (root at ubuntu) (gcc version 4.4.5 
(Ubuntu/Linaro 4.4.4-14ubuntu5) ) #1 SMP Tue Jan 18 13:06:50 EET 2011
[0.00] BIOS-provided physical RAM map:
[0.00]  BIOS-e820:  - 0009f800 (usable)
[0.00]  BIOS-e820: 0009f800 - 000a (reserved)
[0.00]  BIOS-e820: 000e3000 - 0010 (reserved)
[0.00]  BIOS-e820: 0010 - 7ffb (usable)
[0.00]  BIOS-e820: 7ffb - 7ffbe000 (ACPI data)
[0.00]  BIOS-e820: 7ffbe000 - 7fff (ACPI NVS)
[0.00]  BIOS-e820: 7fff - 8000 (reserved)
[0.00]  BIOS-e820: fee0 - fee01000 (reserved)
[0.00]  BIOS-e820: ffb0 - 0001 (reserved)
[0.00] Notice: NX (Execute Disable) protection cannot be enabled: 
non-PAE kernel!
[0.00] DMI present.
[0.00] DMI: MS-7360/MS-7360, BIOS V1.10 11/11/2008
[0.00] e820 update range:  - 0001 (usable) 
==> (reserved)
[0.00] e820 remove range: 000a - 0010 (usable)
[0.00] last_pfn = 0x7ffb0 max_arch_pfn = 0x10
[0.00] MTRR default type: uncachable
[0.00] MTRR fixed ranges enabled:
[0.00]   0-9 write-back
[0.00]   A-B uncachable
[0.00]   C-C write-protect
[0.00]   D-D uncachable
[0.00]   E-E write-through
[0.00]   F-F write-protect
[0.00] MTRR variable ranges enabled:
[0.00]   0 base 0 mask F8000 write-back
[0.00]   1 disabled
[0.00]   2 disabled
[0.00]   3 disabled
[0.00]   4 disabled
[0.00]   5 disabled
[0.00]   6 disabled
[0.00]   7 disabled
[0.00] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
[0.00] found SMP MP-table at [c00ff780] ff780
[0.00] Scanning 0 areas for low memory corruption
[0.00] initial memory mapped : 0 - 00c0
[0.00] init_memory_mapping: -377fe000
[0.00]  00 - 40 page 4k
[0.00]  40 - 003740 page 2M
[0.00]  003740 - 00377fe000 page 4k
[0.00] kernel direct mapping tables up to 377fe000 @ bfb000-c0
[0.00] RAMDISK: 37587000 - 37ff
[0.00] Allocated new RAMDISK: 36b1e000 - 375862eb
[0.00] Move RAMDISK from 37587000 - 37fef2ea to 
36b1e000 - 375862ea
[0.00] ACPI: RSDP 000f9bb0 00014 (v00 ACPIAM)
[0.00] ACPI: RSDT 7ffb 00040 (v01 08 RSDT0906 2008 MSFT 
0097)
[0.00] ACPI: FACP 7ffb0200 00084 (v01 08 FACP0906 2008 MSFT 
0097)
[0.00] ACPI: DSDT 7ffb0440 05595 (v01  0 0000  INTL 
20051117)
[0.00] ACPI: FACS 7ffbe000 00040
[0.00] ACPI: APIC 7ffb0390 0006C (v01 08 APIC0906 2008 MSFT 
0097)
[0.00] ACPI: MCFG 7ffb0400 0003C (v01 08 OEMMCFG  2008 MSFT 
0097)
[0.00] ACPI: OEMB 7ffbe040 00071 (v01 08 OEMB0906 2008 MSFT 
0097)
[0.00] ACPI: HPET 7ffb59e0 00038 (v01 08 OEMHPET  2008 MSFT 
0097)
[0.00] ACPI: GSCI 7ffbe0c0 02024 (v01 08 GMCHSCI  2008 MSFT 
0097)
[0.00] ACPI: SSDT 7ffc0570 00A7C (v01 DpgPmmCpuPm 0012 INTL 
20051117)
[0.00] ACPI: Local APIC address 0xfee0
[0.00] 1159MB HIGHMEM available.
[0.00] 887MB LOWMEM available.
[0.00]   mapped low ram: 0 - 377fe000
[0.00]   low ram: 0 - 377fe000
[0.00] Zone PFN ranges:
[0.00]   DMA  0x0010 -> 0x1000
[0.00]   Normal   0x1000 -> 0x000377fe
[0.00]   HighMem  0x000377fe -> 0x0007ffb0
[0.00] Movable zone start PFN for each node
[0.00] early_node_map[2] active PFN ranges
[0.00] 0: 0x0010 -> 0x009f
[0.00] 0: 0x0100 -> 0x0007ffb0
[0.00] On node 0 totalpages: 524095
[0.00] free_area_init_node: node 0, pgdat c0814000, node_mem_map 
f5b1e200
[0.00]   DMA zone: 32 pages used for memmap
[0.00]   DMA zone: 0 pages reserved
[0.00]   DMA zone: 3951 pages, LIFO batch:0
[0.00]   Normal zone: 1744 pages used fo