Re: 2024 X.Org Foundation Membership deadline for voting in the election

[Pekka Paalanen]

On Tue, 26 Mar 2024 11:42:48 -0400
Christopher Michael  wrote:

> The 2024 X.Org Foundation membership renewal period has been extended 
> one additional week and elections will start the following week on 01 
> April 2024.
> 
> Please note that only current members can vote in the upcoming election, 
> and that the deadline for new memberships or renewals to vote in the 
> upcoming election is 01 April 2024 at 23:59 UTC.
> 
> If you are interested in joining the X.Org Foundation or in renewing 
> your membership, please visit the membership system site at: 
> https://members.x.org/
> 
> Christopher Michael, on behalf of the X.Org elections committee

Hi everyone,

given that the year's first email reminding everyone to renew their
memberships was sent on Feb 7 when the renewal was NOT open yet, I
wonder how many people thought they had already renewed and are now
thinking they don't need to do anything?

I fell for that: On Feb 7, I went to members.x.org to check my status,
it said I was registered for "2023-2024" and there was no button to
renew, so I closed the page confident that I was a member for 2024.
After all, it said 2024. This was a mistake I realised only after being
personally poked to renew. I know for sure of one other person falling
for the same.

Now, the members page for this year says "Application for the period:
02/2024-02/2025". Thanks to the people adding the month to reduce
confusion.


Thanks,
pq


pgpDgLmUSZIec.pgp
Description: OpenPGP digital signature

Re: [Nouveau] [PATCH] x86/mm/kmmio: correctly handle kzalloc return

[Pekka Paalanen]

On Tue, 20 Oct 2020 14:13:44 +0530
Mugilraj Dhavachelvan  wrote:

> Replacing return value -1 to error code
> 
> Signed-off-by: Mugilraj Dhavachelvan 
> ---
>  arch/x86/mm/kmmio.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/x86/mm/kmmio.c b/arch/x86/mm/kmmio.c
> index be020a7bc414..15430520c232 100644
> --- a/arch/x86/mm/kmmio.c
> +++ b/arch/x86/mm/kmmio.c
> @@ -386,7 +386,7 @@ static int add_kmmio_fault_page(unsigned long addr)
>  
>   f = kzalloc(sizeof(*f), GFP_ATOMIC);
>   if (!f)
> - return -1;
> + return -ENOMEN;
>  
>   f->count = 1;
>   f->addr = addr;

Hi,

did you even build-test this?

Why did you write this patch? What does it achieve?


Thanks,
pq


pgp3RnAGg4C9Q.pgp
Description: OpenPGP digital signature
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 09/35] x86: Convert remaining uses of pr_warning to pr_warn

[Pekka Paalanen]

On Thu, 16 Feb 2017 23:11:22 -0800
Joe Perches <j...@perches.com> wrote:

> To enable eventual removal of pr_warning
> 
> This makes pr_warn use consistent for arch/x86
> 
> Prior to this patch, there were 46 uses of pr_warning and
> 122 uses of pr_warn in arch/x86
> 
> Miscellanea:
> 
> o Coalesce a few formats and realign arguments
> o Convert a couple of multiple line printks to single line
> 
> Signed-off-by: Joe Perches <j...@perches.com>
> ---
>  arch/x86/kernel/amd_gart_64.c  | 12 +++--
>  arch/x86/kernel/apic/apic.c| 46 
> --
>  arch/x86/kernel/apic/apic_noop.c   |  2 +-
>  arch/x86/kernel/setup_percpu.c |  4 +--
>  arch/x86/kernel/tboot.c| 15 ++-
>  arch/x86/kernel/tsc_sync.c |  8 +++---
>  arch/x86/mm/kmmio.c|  8 +++---
>  arch/x86/mm/mmio-mod.c |  5 ++--
>  arch/x86/mm/numa.c | 12 -
>  arch/x86/mm/numa_emulation.c   |  6 ++---
>  arch/x86/mm/testmmiotrace.c|  5 ++--
>  arch/x86/oprofile/op_x86_model.h   |  6 ++---
>  arch/x86/platform/olpc/olpc-xo15-sci.c |  2 +-
>  arch/x86/platform/sfi/sfi.c|  3 +--
>  arch/x86/xen/debugfs.c |  2 +-
>  arch/x86/xen/setup.c   |  2 +-
>  16 files changed, 63 insertions(+), 75 deletions(-)
> 

Hi,

seems fine to me, even though I haven't been involved in the kernel
side for years.

For the hunks quoted below *only*:
Reviewed-by: Pekka Paalanen <pekka.paala...@collabora.co.uk>

> diff --git a/arch/x86/mm/kmmio.c b/arch/x86/mm/kmmio.c
> index afc47f5c9531..ad70518cdcc7 100644
> --- a/arch/x86/mm/kmmio.c
> +++ b/arch/x86/mm/kmmio.c
> @@ -187,8 +187,8 @@ static int arm_kmmio_fault_page(struct kmmio_fault_page 
> *f)
>   int ret;
>   WARN_ONCE(f->armed, KERN_ERR pr_fmt("kmmio page already armed.\n"));
>   if (f->armed) {
> - pr_warning("double-arm: addr 0x%08lx, ref %d, old %d\n",
> -f->addr, f->count, !!f->old_presence);
> + pr_warn("double-arm: addr 0x%08lx, ref %d, old %d\n",
> + f->addr, f->count, !!f->old_presence);
>   }
>   ret = clear_page_presence(f, true);
>   WARN_ONCE(ret < 0, KERN_ERR pr_fmt("arming at 0x%08lx failed.\n"),
> @@ -335,8 +335,8 @@ static int post_kmmio_handler(unsigned long condition, 
> struct pt_regs *regs)
>* something external causing them (f.e. using a debugger while
>* mmio tracing enabled), or erroneous behaviour
>*/
> - pr_warning("unexpected debug trap on CPU %d.\n",
> -smp_processor_id());
> + pr_warn("unexpected debug trap on CPU %d\n",
> + smp_processor_id());
>   goto out;
>   }
>  
> diff --git a/arch/x86/mm/mmio-mod.c b/arch/x86/mm/mmio-mod.c
> index bef36622e408..706ae44d1af7 100644
> --- a/arch/x86/mm/mmio-mod.c
> +++ b/arch/x86/mm/mmio-mod.c
> @@ -407,7 +407,7 @@ static void enter_uniprocessor(void)
>   }
>  out:
>   if (num_online_cpus() > 1)
> - pr_warning("multiple CPUs still online, may miss events.\n");
> + pr_warn("multiple CPUs still online, may miss events\n");
>  }
>  
>  static void leave_uniprocessor(void)
> @@ -431,8 +431,7 @@ static void leave_uniprocessor(void)
>  static void enter_uniprocessor(void)
>  {
>   if (num_online_cpus() > 1)
> - pr_warning("multiple CPUs are online, may miss events. "
> -"Suggest booting with maxcpus=1 kernel argument.\n");
> + pr_warn("multiple CPUs are online, may miss events. Suggest 
> booting with maxcpus=1 kernel argument.\n");
>  }
>  
>  static void leave_uniprocessor(void)

> diff --git a/arch/x86/mm/testmmiotrace.c b/arch/x86/mm/testmmiotrace.c
> index 38868adf07ea..4a55e453296d 100644
> --- a/arch/x86/mm/testmmiotrace.c
> +++ b/arch/x86/mm/testmmiotrace.c
> @@ -121,9 +121,8 @@ static int __init init(void)
>   return -ENXIO;
>   }
>  
> - pr_warning("WARNING: mapping %lu kB @ 0x%08lx in PCI address space, "
> -"and writing 16 kB of rubbish in there.\n",
> -size >> 10, mmio_address);
> + pr_warn("WARNING: mapping %lu kB @ 0x%08lx in PCI address space, and 
> writing 16 kB of rubbish in there\n",
> + size >> 10, mmio_address);
>   do_test(size);
>   do_test_bulk_ioremapping();
>   pr_info("All done.\n");


Thanks,
pq


pgpnZEmabLt8e.pgp
Description: OpenPGP digital signature
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] K2200 Special Setup Question

[Pekka Paalanen]

On Tue, 22 Dec 2015 22:50:14 +0100
ternaryd  wrote:

> Hi,
> 
> I'm planning to use a K2200 board with an Eizo
> monitor at 10 bits color depth together with a
> standard monitor on a debian sid system.

Hi,

I don't know anything about K2200, but I suppose I can give what I
recall from Xorg a few years ago since no-one else replied to you
yet. I am making the assumption that you are talking about setting
up X11 with Xorg.

> Is it possible to have one monitor with 8, the
> other with 10 bit colors? Is it possible to

I think so, yes, as long as the different depths are on different
X11 SCREENs, but this has the big caveat that you cannot drag
windows from one monitor to another.

http://nouveau.freedesktop.org/wiki/MultiMonitorDesktop/

If you have a single card with multiple heads, you would be looking
for "Zaphod" options.

> configure such a setup choosing for each
> monitor a different resolution (dpi) such that
> a window would not change size when moved from
> one monitor to the other?

"Not changing physical size" is a controversial goal depending on
what exactly you want and how it is achieved. If you are working on
prints and you want to see it 1:1 in physical scale, it is probably
best to calibrate that in the editing program and with a physical
ruler than to rely on any "dpi" numbers from the system. If you are
talking about fonts, "same size" is often contradicting with "good
looking" or even "same looking". In any case on X11, it is up to the
application to resize its window and content accordingly.

I can look up a few "why dpi is not what you want" related articles
in case you are interested in that side story.

I have not heard of it being possible to have both differing color
depths and the ability to drag windows from one monitor to another
on X11.


Thanks,
pq
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH] Add Option DRI3 to allow to disable DRI3 under EXA.

[Pekka Paalanen]

On Sat, 18 Jul 2015 21:09:46 +1000
Dave Airlie airl...@gmail.com wrote:

  Hm, a total removal would at least make me and my users rather unhappy atm.,
  as without glamor no hw accel at all on = maxwell. modesetting and nouveau
  are not on par feature-wise atm. E.g., modesetting as of the next xorg 1.18
  server only provides pageflipping via dri3/present and without pageflipping
  it is game over for many of my use cases on nouveau-kms. Also modesetting
  currently completely lacks ZaphodHeads support. Without ZaphodHeads i can't
  have a page-flipped fullscreen window on one subset of outputs and a regular
  desktop on another subset, something that is needed for
  neuroscience/medical/vr applications.
 
 So what would you want in modesetting to be on par?
 
 DRI2 pageflipping?
 zaphod heads?
 
 anything else? I would like for F23 to ship a modesetting which I can
 replace intel/nouveau/ati with.

Hi,

FYI, it seems the Oculus Rift also prefers a ZaphodHeads setup.
http://blog.emarcs.org/blog/oculus-rift-direct-mode-on-linux/


Thanks,
pq
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] Logo Nouveau

[Pekka Paalanen]

On Tue, 18 Nov 2014 12:48:37 +0100
Martin Peres martin.pe...@free.fr wrote:

 With this done, I guess delivering the logo as an svg file along with 
 its licence (have you had time to look at the creative commons?) would 
 be a great step.
 It would also be nice to have one logo without nouveau written (for 
 presentations) and one logo for the wiki (to replace the freedesktop 
 logo: http://nouveau.freedesktop.org/wiki/).

I wonder if you will also need pre-made scaled versions? Simply
scaling an SVG image to something like favicon size might not
always be the best without manual tuning.

The logo is really nice apart the centering issue now that
that's been mentioned. :-)


Thanks,
pq
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] MmioTrace: Using the Instruction Decoder, etc.

[Pekka Paalanen]

On Fri, 25 Oct 2013 17:19:56 +0400
Eugene Shatokhin euspec...@gmail.com wrote:

 Hi,
 
 2013/10/25 Pekka Paalanen p...@iki.fi
 
...
  We could use some comments from the real reverse-engineers. I used
  to be mostly a tool writer.
 
 
 Yes, if some experts could share their knowledge of this matter, this would
 be most welcome!

Hi,

I got one comment in IRC, saying that a faster mmiotrace would be
nice, but probably not something he would invest time in.

Looking at it from that point of view, I guess mmiotrace works well enough,
and is only a reverse-engineering tool, not something used daily.
That, and the lack of replies here indicate that rewriting mmiotrace
with your approach might not be worth it. I don't think anyone
opposes to the idea, they just have better things to do.

It's all up to you, I believe.


Thanks,
pq
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] MmioTrace: Using the Instruction Decoder, etc.

[Pekka Paalanen]

On Sat, 19 Oct 2013 17:12:20 +0400
Eugene Shatokhin euspec...@gmail.com wrote:

 Hi,
 
   Ah, you are not using the ftrace framework nor relayfs? Mmiotrace
  used to be relayfs at one point and then converted to ftrace.
 
 Yes, I considered these when I started working on KernelStrider but finally
 borrowed ideas from Perf and implemented them. A mmapped ring buffer does
 its job well and has a higher throughput than Ftrace in my case.
 
  Are you saying that you intercept function calls, and *never* rely
  on page faulting?
 
 The system intercepts both function calls *and* memory operations made by
 the driver itself. Yes, it never relies on page faulting.
 
   Does that mean that if a driver does the ugly thing and
   dereferences an iomem pointer directly, you won't catch that?
 
 It will be caught.
 
 What my system actually does is as follows.
 
 When the target kernel module has been loaded into memory but before it has
 begun its initialization, KernelStrider processes it, function after
 function. It creates an instrumented variant of each function in the module
 mapping space and places a jump at the beginning of the original function
 to point to the instrumented one. After instrumentation is done, the target
 driver may start executing.

Oh, that works on a completely different way than I even imagined,
a whole another level of complexity.


...snip code you corrected in another email

 That is, the address which is about to be accessed is determined and stored
 in 'local_storage', a special memory structure. At the end of the block of
 instructions, the information from the local storage is sent to the output
 system. So the addresses and sizes of the accessed memory areas as well as
 the types of the accesses (read/write/update) will be available for reading
 from the user space.

Just curious, how do you detect interesting instructions to
instrument from uninteresting instructions that do not access mmio
areas?

Does it rely on post-processing, in that you instrument practically
everything, and then in post-processing you check if the accessed
memory address actually was interesting before sending the data to user
space?

 It is actually more complex than that (KernelStrider has to deal with
 register allocation, relocations and other things) but the principle is as
 I described.
 
 The function calls are processed too so that we can set our own handlers to
 execute at the beginning of a function and right before its exit.
 
 Yes, the functions like read[bwql]() and write[bwlq]() are usually inline
 but they pose no problem: on x86 they compile to ordinary MOV instructions
 and the like which are handled as I described above.
 
 The instrumented code will access the ioremapped area the same way as the
 original code would, no need for single-stepping or emulation in this case.

That is very cool, the possibility never even occurred to me.

 What I wrote in my previous letter is that there is a special case when the
 target driver uses some non-inline function provided by the kernel proper
 or by another driver and that function accesses the ioremapped memory area
 of interest.
 
 KernelStrider needs to track all such functions in order not to miss some
 memory accesses to that ioremapped area. Perhaps, that's manageable. There
 are not too many such functions, aren't they?

I don't really know, and personally I was never even interested,
since the page faulting approach was a catch-all method. We
could even detect when we hit some access we couldn't handle right
due to lacking instruction decoding.

I guess to be sure your approach does not miss anything, we'd still
need the page faulting setup as a safety net to know when or if
something is missed, right? And somehow have the instrumented code
circumvent it.

We could use some comments from the real reverse-engineers. I used
to be mostly a tool writer.


Thanks,
pq
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] MmioTrace: Using the Instruction Decoder, etc.

[Pekka Paalanen]

On Fri, 18 Oct 2013 00:11:15 +0400
Eugene Shatokhin euspec...@gmail.com wrote:

 Hi,
 
 Good to know that!
 
 Yes, it should be faster than page faulting, although I haven't done the
 benchmarking yet. And yes, it is not needed to disable all but one CPU. In
 my current implementation, I use an ordered workqueue to send the data to
 the mmapped output buffer (where they will be read from from the user
 space) and that ensures the order of events is kept. May be less than ideal
 but it currently works quite well with network drivers, the performance
 overhead is acceptable there.

Ah, you are not using the ftrace framework nor relayfs? Mmiotrace
used to be relayfs at one point and then converted to ftrace.

 A subtle drawback may be that the system sees the memory reads and writes
 made by the code of the driver directly but if the driver uses some other
 kernel functions, it needs to intercept these calls and determine how they
 access the memory of interest. Theoretically, it could be less accurate
 than page fault handling. A page fault happens no matter if the driver
 accesses the memory directly or via strcpy(), for example. I doubt this
 would be a big problem for tracking the accesses to ioremapped memory
 though.
 
 Nevertheless, it is manageable, the system already handles string
 functions, for example, and reports appropriate events. The handlers for
 other functions could be added as well. So this just requires a bit more
 maintenance work.

Are you saying that you intercept function calls, and *never* rely
on page faulting?

Does that mean that if a driver does the ugly thing and
dereferences an iomem pointer directly, you won't catch that?
Unfortunately, I think proprietary drivers do such uglies, since
they are x86 and x86_64 only where it works. Or they might have the
iomem accessor functions inlined.

What I had in mind was to still use page faulting to catch the
memory accessing machine instructions, but then use emulation to
execute that instruction with the memory address diverted to the
real ioremapped region instead of the dummy region given to the driver.
Currently for each access, on the page fault, mmiotrace uses single
stepping and page table manipulation to let the instruction run for
real, and immediately afterwards set things back to page faulting.

Sorry, I see my terminology was wrong. I don't think we can avoid
the page faulting, but I'd like to avoid the single-stepping and
page table mangling on the fly. Heh, things are slowly coming back
to me.

What do you thing, would it still be interesting?

  Unfortunately, my job exhausts my coding energy, and I haven't even
 touched mmiotrace in years.
 
 I understand. I have many other responsibilities too. Code to write, bugs
 to fix, etc. ;-)
 
 Well, then, when time permits, I'll try to prepare a prototype so that its
 performance and reliability could be evaluated. Hard to tell what the
 numbers will be before that.
 
 Suggestions, comments and other feedback are welcome of course.
 
 And, by the way, video drivers do not use SSE and similar instructions when
 accessing ioremapped memory, do they?
 Such things are rare in the kernel and usually frowned upon so I opted not
 to handle them so far in KernelStrider.

I don't really know. I guess everything could be possible in
proprietary drivers, but you can look at the instruction decoding
code in mmiotrace, which digs up the type and size of access and
the value. That has been enough so far.


Thanks,
pq

 2013/10/17 Pekka Paalanen p...@iki.fi
 
  On Mon, 14 Oct 2013 22:45:09 +0400
  Eugene Shatokhin euspec...@gmail.com wrote:
 
   Hi,
  
   There is an interesting TODO item on MmioTraceDeveloper page:
   kprobes has a generic instruction decoding facility, use that instead of
   homebrewn (or KVM), and use emulation instead of page faulting
  
   Actually, I have done something similar in one of my systems,
  KernelStrider
   (http://code.google.com/p/kernel-strider/). The system instruments a
  kernel
   module when that module is being loaded. The instrumented code executes
   instead of the original one and provides information about the memory
   accesses it makes and the functions it calls. These data are sent to user
   space for further analysis.
  
   Currently, I use this system to detect data races in the Linux kernel
  (and
   have found some). I suppose, it could probably be useful to MmioTrace as
   well.
  
   KernelStrider uses an enhanced version of the x86 instruction decoder
  that
   Kprobes use and relies on binary instrumentation rather than on page
   faults. So, it can track:
   - memory accesses (address and size of the accessed memory as well as the
   access type are recorded)
   - function calls (exported functions and callbacks, one can setup pre-
  and
   post- handlers for these)
  
   Is there any interest in trying this approach to the task of MmioTrace?
  
   If so, we can discuss it. When I have time, I could try to create a
   prototype based

Re: [Nouveau] MmioTrace: Using the Instruction Decoder, etc.

[Pekka Paalanen]

On Mon, 14 Oct 2013 22:45:09 +0400
Eugene Shatokhin euspec...@gmail.com wrote:

 Hi,
 
 There is an interesting TODO item on MmioTraceDeveloper page:
 kprobes has a generic instruction decoding facility, use that instead of
 homebrewn (or KVM), and use emulation instead of page faulting
 
 Actually, I have done something similar in one of my systems, KernelStrider
 (http://code.google.com/p/kernel-strider/). The system instruments a kernel
 module when that module is being loaded. The instrumented code executes
 instead of the original one and provides information about the memory
 accesses it makes and the functions it calls. These data are sent to user
 space for further analysis.
 
 Currently, I use this system to detect data races in the Linux kernel (and
 have found some). I suppose, it could probably be useful to MmioTrace as
 well.
 
 KernelStrider uses an enhanced version of the x86 instruction decoder that
 Kprobes use and relies on binary instrumentation rather than on page
 faults. So, it can track:
 - memory accesses (address and size of the accessed memory as well as the
 access type are recorded)
 - function calls (exported functions and callbacks, one can setup pre- and
 post- handlers for these)
 
 Is there any interest in trying this approach to the task of MmioTrace?
 
 If so, we can discuss it. When I have time, I could try to create a
 prototype based on KernelStrider's core that tracks the memory accesses
 Mmiotrace needs.
 What do you think?

Hi Eugene,

that is very interesting! I assume emulating the instructions is
not only cleaner, but also faster than page-faulting, right? Maybe
even more reliable, perhaps up to the point where we would not need
to disable all but one CPU.

Unfortunately, my job exhausts my coding energy, and I haven't even
touched mmiotrace in years.

However, let's see if there are interested people on the mailing
lists. I'm CC'ing nouveau, since that is where mmiotrace started,
and dri-devel in the hopes to catch other drivers' reverse
engineers.


Thanks,
pq
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] how do I unsubscribe from the Nouveau malling list?

[Pekka Paalanen]

On Sat, 12 Jan 2013 17:50:12 -0600
intok in...@linuxmail.org wrote:

 don't remember the password and the password reminder on the site
 doesn't seem to work.

 http://lists.freedesktop.org/mailman/listinfo/nouveau

Unsubcribing does not seem to require a password, just use the
Unsubscribe or edit options button in the above link, and it
should send you an unsubcription confirmation email.

Does something in that not work?

- pq
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] still seeking way to recover card after cursor disappears or card locks up

[Pekka Paalanen]

On Wed, 30 May 2012 20:55:49 -0700
rm.ric...@jacob21819.net (Robert M. Riches Jr.) wrote:

  I very doubt that rmmod and modprobe will help you in any way since
  nouveau is KMS module and it stays in use the whole time. Something
  will be broken anyway. But you can try and see what's happening, it
  will not brick your card.
 
 Arvydas, thank you very much for that info/advice.  You were
 100% right that rmmod refused to remove the nouveau module.

Hi,

The unloading instructions are also in the wiki:
http://nouveau.freedesktop.org/wiki/KernelModeSetting

Also a suspend-resume cycle has been said to help in recovering a
locked-up GPU.


Thanks,
pq
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] Question about NV18 and GBM library.

[Pekka Paalanen]

On Fri, 27 Apr 2012 21:11:35 -0300
gabriel muguerza glmca...@gmail.com wrote:

 On Thu, Apr 26, 2012 at 2:41 PM, Lucas Stach d...@lynxeye.de
 wrote:
 
  Am Mittwoch, den 25.04.2012, 12:34 -0300 schrieb gabriel
  muguerza:
 
   Hi,
  
   I have a geforce 4mx 440 agp 8x, and I'm trying to use the GBM
   library,
   (as jbarnes in:
   http://virtuousgeek.org/blog/index.php/jbarnes/2011/10/
   and David Hermann in KMSCON:
   https://github.com/dvdhrm/kmscon), without success.
  
   when I try to create a gbm_device, I get: (below the code.)
  
   nouveau_drm_screen_create: unknown chipset nv18
   dri_init_screen_helper: failed to create pipe_screen
   loaded /usr/lib/gbm/pipe_nouveau.so
   nouveau_drm_screen_create: unknown chipset nv18
   failed to load driver: nouveau
  
  
   My question is:
   Is this not supported by the driver?,
   It's a GBM problem? or am I doing something wrong?
  
  Yep, you are right, your GPU is simply too old. GBM is only
  supported with the nouveau gallium drivers, which start with
  the nv30 generation. The nouveau_vieux driver for your card
  does not support GBM.
 
  -- Lucas
 
 
 Ok, thank you.
 (and nor Wayland works, I guess).

You mean Weston. Weston uses GL ES 2, which relies on shaders and
does not have a fixed-function pipeline. NV18 AFAIK does not have
any shader capability, but only a fixed-function pipeline. This
is another big obstacle.

Wayland could be made to work, but it would need some work:
- writing a Wayland server on fixed-function OpenGL
- writing the infrastructure for using EGL/OpenGL on the
  framebuffer offered by DRM

and maybe something else I overlooked.

-- 
Pekka Paalanen
http://www.iki.fi/pq/
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH] master-compat: Compile i915 DRM for out-of-tree. Optimus laptops need it.

[Pekka Paalanen]

On Fri, 11 Nov 2011 05:25:17 -0500
Eric Appleman erapple...@gmail.com wrote:

 On 11/11/2011 05:23 AM, Eric Appleman wrote:
  Hi, a machine with both an Intel and Nvidia GPU needs both
  drivers built as modules otherwise the former will not work
  properly.
 
  - Eric
 Sorry, Thunderbird is bad with attachments.

Sorry, I'm not going to apply this.

This way of installing is meant only for nouveau, and building
i915 is for most people useless.

If you want both nouveau and i915, I would recommend building
the whole kernel with both of these from either Nouveau linux tree,
or Linus' tree. Or some other upstream tree.


Thanks.

-- 
Pekka Paalanen
http://www.iki.fi/pq/
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] better way to test optimus laptop

[Pekka Paalanen]

On Fri, 11 Nov 2011 12:34:06 +0100
Gianluca Cecchi gianluca.cec...@gmail.com wrote:

 Hello,
 I have an Asus laptop, model U36SD with Nvidia optimus technlogy.
 My system has now Fedora 16 with kernel 3.1.0-7.fc16.x86_64
 $ lspci -vnnn|grep VGA
 00:02.0 VGA compatible controller [0300]: Intel Corporation 2nd
 Generation Core Processor Family Integrated Graphics Controller
 [8086:0126] (rev 09) (prog-if 00 [VGA controller])
 01:00.0 VGA compatible controller [0300]: nVidia Corporation
 Device [10de:1050] (rev ff) (prog-if ff)
 
 At the moment, not being able to use optimus technology I compiled
 acpi_call (from 24/06/11) for my kernel and set this in
 /etc/rc.d/rc.local
 /sbin/modprobe acpi_call
 echo '\_SB.PCI0.PEG0.GFX0.DOFF'  /proc/acpi/call
 
 Also, due to some video problems for which I don't know if a
 possible con-cause could be both nouveau and i915 kernel modules
 loaded, I put in my grub.conf settings so that
 $ cat /proc/cmdline
 BOOT_IMAGE=/boot/vmlinuz-3.1.0-7.fc16.x86_64
 root=UUID=ce058d6c-d2ed-49e5-9869-965799f246a5 ro rd.md=0 rd.lvm=0
 rd.dm=0 KEYTABLE=us quiet SYSFONT=latarcyrheb-sun16 rhgb rd.luks=0
 LANG=en_US.UTF-8 i915.i915_enable_rc6=1 elevator=deadline
 nouveau.nomodeset=0
 
 $ sudo lsmod|grep nouve
 $ sudo lsmod|grep i915
 i915  389156  3
 drm_kms_helper 26490  1 i915
 drm   194532  5 ttm,i915,drm_kms_helper
 i2c_algo_bit4958  1 i915
 i2c_core   25728  6
 videodev,i2c_i801,i915,drm_kms_helper,drm,i2c_algo_bit
 video  12388  1 i915
 
 Is this correct approach at the moment? Anything to test in
 Optimus direction and to help nouveau?

Are you sure there is anything to test with Optimus?
I haven't heard of any huge progress.

Do you know how your outputs are wired, and do you have a hw mux?
http://nouveau.freedesktop.org/wiki/Optimus

-- 
Pekka Paalanen
http://www.iki.fi/pq/
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH] master-compat: Compile i915 DRM for out-of-tree. Optimus laptops need it.

[Pekka Paalanen]

On Sat, 12 Nov 2011 05:19:03 -0500
Eric Appleman erapple...@gmail.com wrote:

 I agree with your rationale, but consider the following case that
 has become increasingly important. Let's say a user wants to test
 bleeding-edge Nouveau DRM on a Sandy Bridge laptop with Optimus
 but doesn't have the knowledge or patience to roll an entire
 kernel or wait for a packaged one. Building nouveau and i915 at
 the same time would make for a convenient alternative and would
 permit faster testing as Optimus solutions such as windump,
 dma_buf, and Bumblebee continue to mature. The Makefile certainly
 allows for it. Would a wiki comment be an acceptable alternative
 to inclusion of this patch?

Yeah, sure, documenting it in the wiki would be nice.
But please do check all the i915 dependencies in the Kconfig files
to make sure that i915 gets what it needs. The Makefile probably
overrides many sanity checks in the kernel config system.


Thanks.

-- 
Pekka Paalanen
http://www.iki.fi/pq/
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [Mesa-dev] RFC: ctx-Driver.Map/UnmapTextureImage() hooks

[Pekka Paalanen]

On Mon, 18 Jul 2011 08:09:17 -0600
Brian Paul bri...@vmware.com wrote:

 On 07/15/2011 02:59 PM, Pekka Paalanen wrote:
  On Fri, 15 Jul 2011 12:22:41 -0600
  Brian Paulbri...@vmware.com  wrote:
 
  On 07/15/2011 10:07 AM, Dave Airlie wrote:
  On Fri, Jul 15, 2011 at 4:10 AM, Brian
  Paulbrian.e.p...@gmail.com   wrote:
 
 
  The map-texture-image-v4 branch that I just pushed implements
  this change.  It really cleaned things up for the better and
  will lead to a few more follow-on improvements.
 
  There's no obvious regressions with swrast or the gallium
  drivers.  I updated the intel driver code and tested i915 and
  it seems OK too, but I didn't do a full piglit run on it.  I
  also updated the legacy r600 driver in case anyone cares but
  didn't do any testing of it.
 
  I didn't update any of the other legacy DRI drivers.  Would
  anyone object if we simply stop building mach64, r128,
  unichrome, sis, etc? I'd be happy to remove those drivers
  altogether for that matter.
 
  we could EOL those in 7.11, and if anyone wants to ship them,
  they can just build 7.11 for them.
 
  Sounds good to me.  I think we'd only keep the swrast, intel
  and maybe r300/r600 drivers.  Opinions?
 
  Um, don't kill nouveau_vieux, please.
 
 Does the old nouveau driver support some GPUs that the gallium 
 nv50/nvc0 drivers don't support?

Yes. Like Corbin said, 'nouveau_vieux' is for NV04-NV2x, while
the gallium driver 'nouveau' supports NV30 and later.
http://nouveau.freedesktop.org/wiki/MesaDrivers

 If we want to keep the older driver someone will need to
 volunteer to update the code to support the new driver hooks.

Sorry, I cannot promise that.
Nouveau_vieux seems to have been missing a maintainer for
some time now.


Thanks.

-- 
Pekka Paalanen
http://www.iki.fi/pq/
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] GeForce 5500 crashes driver

[Pekka Paalanen]

On Wed, 25 May 2011 10:11:39 +0200
Flo debian...@gmx.at wrote:

 Hi all,
 
 I have a 7 year old computer which is working fine so far and sufficient
 fast for my 'office' needs. I am running Debian testing. I bought a new
 monitor (HD) and a video card:
 
 256 MB GeForce FX5500, Inno3D, AGP 8x/4x
 
 Working fine, unfortunately it produces a crash:
 
 .) Sometimes after 30 min, sometimes after a day
 .) Can happen anytime, even when screen saver is on. Happens more
 frequently if 'complicated' websites at browser windows are opened.
 .) Mouse is still moving but everything else on the display is frozen.
 .) I cannot switch to a console but I can login via network (i.e. to
 reboot).
 
 I conclude that the crashes are due to the combination of video card and
 driver. So, the card is buggy or the driver is buggy.
 
 I hope you can help me answering the following questions:
 .) Is it reasonable to track down the error? (Maybe it would make sense
 for driver improvement?). What should I start with?

We have bug reporting guidelines here:
http://nouveau.freedesktop.org/wiki/Bugs

Complete kernel and X logs are required to get any insight to
the problem. You also need to specify what versions of all
the software components you use.

Going through the TroubleShooting page is also worth it to
eliminate the usual user errors.

 .) How are the chances that the problem will go away if I buy a similar
 (maybe also GeForce 5500) video card from another manufacturer.

Without further information, I'd say very unlikely.


Thanks.

-- 
Pekka Paalanen
http://www.iki.fi/pq/

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] NV46 disconnected VGA

[Pekka Paalanen]

 this.

And that is what you shall get, once we get the VGA output
online. That really is the default operation, not Zaphod mode.

  What does the  kernel say about the outputs in the log?
 
 localhost $ dmesg # You meant dmesg?

Yes, I should have been more specific. But maybe we don't need it
just yet.

  Has your VGA-monitor's DDC  worked before?
 
 I don't recall that about the VGA in Linux,. although I used an Intel GMA on 
 the 
 LCD, but in the other OS I used to  use extend the desktop weekly.

Do you mean it often lost the desktop settings for the
VGA-connected monitor?

If I got it right, the core of your problem is that the
external monitor, connected via VGA (doesn't matter if
the monitor is a flat panel or a CRT), is never detected
as connected. There are two ways you could try to force
it as connected:

xrandr --output VGA-1 --mode 1024x768 --right-of LVDS-1
or something similar, IIRC that should force-enable the
output.

Forcing the mode on the kernel command line, as per
instructions in
http://nouveau.freedesktop.org/wiki/KernelModeSetting

And keep the simplistic xorg.conf for now.

HTH, Cheers

-- 
Pekka Paalanen
http://www.iki.fi/pq/
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] Nouveau_drv problem and KMS nouveau problem... please HELP!

[Pekka Paalanen]

On Tue, 11 Jan 2011 23:57:53 -0200
Maginot Junior maginot.jun...@gmail.com wrote:

 I have being in a long journey trying to make my distro to have a
 proper support for KMS/DRI. It's something of months, and still
 nothing. I must confess that understanding the KMS concept isn't
 hard, but joing all peaces to work althogether is other thing.
 
 So after a while without proper support, I decided to start all
 over, kernel, X11, nouveau, drm, mesa, and so on.

First things first. Forget about plymouth, libdrm, Mesa and X. Make
the KMS work. For that, you only need the kernel modules. This
means you get a working framebuffer console (fbcon).

 This are some of the links that I used to guied me:
 
 http://dri.freedesktop.org/wiki/Download
 http://www.kernel.org/pub/linux/kernel/v2.6/
 http://nouveau.freedesktop.org/wiki/
 http://nouveau.freedesktop.org/wiki/InstallDRM
 http://nouveau.freedesktop.org/wiki/KernelModeSetting
 http://dri.freedesktop.org/wiki/
 http://gnihce.wordpress.com/2010/08/17/building-dri-drivers-for-mesa-7-8-2/
 http://www.x.org/releases/X11R7.6/src/
 
 I really don't know if I follow the right build order (if there is
 any), I may be ommiting something, but these are the main
 packages I build trying to make a proper KMS support:

Do libdrm first, after you got KMS going.


 Linux-2.6.35.7

35?? Nouveau won't build with that, what have you built, really?

 CONFIG_DRM_KMS_HELPER=m
 CONFIG_DRM=m
 CONFIG_DRM_KMS_HELPER=m
 CONFIG_DRM_TTM=m
 CONFIG_DRM_TDFX=m
 CONFIG_DRM_R128=m
 CONFIG_DRM_RADEON=m
 CONFIG_DRM_RADEON_KMS=y
 CONFIG_DRM_I810=m
 CONFIG_DRM_I830=m
 CONFIG_DRM_I915=m
 CONFIG_DRM_I915_KMS=y
 CONFIG_DRM_MGA=m
 CONFIG_DRM_SIS=m
 CONFIG_DRM_VIA=m
 CONFIG_DRM_SAVAGE=m
 CONFIG_DRM_NOUVEAU=m
 CONFIG_DRM_NOUVEAU_BACKLIGHT=y
 CONFIG_DRM_NOUVEAU_DEBUG=y
 CONFIG_DRM_I2C_CH7006=m

You are not mentioning any of the FB options. See the requirements
in InstallDRM if you build out-of-tree.

 I did downloaded nouveau master and
 nouveau-firmware-20091212.tar.gz, build them inside linux source
 directory and installed the firmwares.

Firmware is not needed. That is mentioned in InstallDRM wiki page.

I do not understand what kernel modules you took. All I know, is
that the current modules from master need at least 2.6.37-rc1 to
build.

 The problem is that booting without NOMODESET cmdline arg gives
 me a blank screen. The system is still operant (I can hit
 CTRL+ALT+DEL in dark and reboot the system). One of the last
 things that I can see before the screen goes blank is [drm] ...
 line If I keep 20-nouveau.conf configuration and use NOMODESET
 xorg doesn't start, commenting it and running gdm makes Xorg
 start. I do have a problem with nouveau_drv.so afaik.
 If I comment 20-nouveau.conf and boot without NOMODESET them I
 have a blank console and a buggy X.
 
 My Xorg's log after booting with NOMODESET and 20-nouveau.conf
 NOT commented:

Nouveau cannot work without KMS. Nomodeset disables KMS.

 My Xorg's log after booting with NOMODESET and with
 20-nouveau.conf commented
...
 [   970.095] (II) Loading sub module fbdevhw
 [   970.095] (II) LoadModule: fbdevhw
 [   970.095] (II) Loading /usr/X11/lib/X11/modules/libfbdevhw.so
 [   970.105] (II) Module fbdevhw: vendor=X.Org Foundation
 [   970.105]compiled for 1.9.3, module version = 0.0.2
 [   970.105]ABI class: X.Org Video Driver, version 8.0
 [   970.105] (EE) open /dev/fb0: No such file or directory
...
 [   970.115] (II) NV(0): Initializing int10
 [   970.120] (II) NV(0): Primary V_BIOS segment is: 0xc000
 [   970.121] (--) NV(0): Console is VGA mode 0x3
 [   970.121] (II) NV(0): Creating default Display subsection in
 Screen section Default Screen Section for depth/fbbpp 24/32
 [   970.121] (==) NV(0): Depth 24, (--) framebuffer bpp 32
 [   970.121] (==) NV(0): RGB weight 888
 [   970.121] (==) NV(0): Default visual is TrueColor

nv driver is very bad, see basic question #4 in
http://nouveau.freedesktop.org/wiki/TroubleShooting
fbdev would be good, but KMS is not working, so that won't either.

The next time you attach logs, try to see that the lines do not
get chopped. They are hard to read, if lines are cut.

So, get your kernel module sources right, and tell exactly what
you used. Provide a complete kernel log, without any plymouth or
X. Just trying to get the basic fbcon on Nouveau.


Thanks.

-- 
Pekka Paalanen
http://www.iki.fi/pq/
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH] drm: Remove DRIVER_DATE and CORE_DATE

[Pekka Paalanen]

On Wed, 22 Dec 2010 10:51:26 +0100
Sedat Dilek sedat.di...@googlemail.com wrote:

 DRIVER_DATE is not maintained or upgraded on changes in many drm
 drivers.
 
 For example radeon has one DRIVER_DATE for User and Kernel
 ModeSetting driver, this makes no sense as UMS and KMS driver
 have different versions. And of course this all increases
 maintenance, too. For radeon it is enough to bump
 {KMS_}DRIVER_MAJOR, {KMS_}DRIVER_MINOR and
 {KMS_}DRIVER_PATCHLEVEL defines.
 
 Furthermore, I also removed CORE_DATE.
 
 With radeon-KMS my dmesg looks now like this:
 
 [   12.328937] [drm] Initialized drm 1.1.0
 [   13.144019] [drm] Initialized radeon 2.8.0 for :01:00.0 on
 minor 0
 
 Signed-off-by: Sedat Dilek sedat.di...@gmail.com
 
 Note: Tested with radeon RV250 (KMS) and linux-next
 (next-20101221).
...
 diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.c 
 b/drivers/gpu/drm/nouveau/nouveau_drv.c
 index bb17057..50abca3 100644
 --- a/drivers/gpu/drm/nouveau/nouveau_drv.c
 +++ b/drivers/gpu/drm/nouveau/nouveau_drv.c
 @@ -416,11 +416,6 @@ static struct drm_driver driver = {
  
   .name = DRIVER_NAME,
   .desc = DRIVER_DESC,
 -#ifdef GIT_REVISION
 - .date = GIT_REVISION,
 -#else
 - .date = DRIVER_DATE,
 -#endif
   .major = DRIVER_MAJOR,
   .minor = DRIVER_MINOR,
   .patchlevel = DRIVER_PATCHLEVEL,

Just a reminder, why this hunk was there in the first place:
it is quite usual for the Nouveau DRM to be compiled out-of-tree,
from different kernel git sources than the hosting kernel.
This was an attempt to record in the kernel log which exact
revision is being used. GIT_REVISION is defined by the Makefile
that is recommended to be used for out-of-tree building.

I didn't check if this patch has been accepted, but I believe
maintaining differences between nouveau/linux-2.6 and upstream
kernel trees is a burden.

Is there a better way to add revision information to an
out-of-tree built kernel module?
Or maybe this is not useful at all?


Cheers.

-- 
Pekka Paalanen
http://www.iki.fi/pq/
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] Display goes off when framebuffer enabled and Kernel Panic with fbset

[Pekka Paalanen]

On Sat, 4 Dec 2010 22:02:34 -0900
Roger rogerx@gmail.com wrote:

 Wow. This is a fluke.  I got around to the recommendation of installing the
 latest kernel snapshot (2.6.37*), but ended up rebooting using 2.6.35 after
 apparently recompiling nouveau-drm out of kernel driver package.

Does this mean you never got the very latest git kernel modules running?
Unfortunately, problems with earlier versions are easily disregarded as
ancient, especially from 2.6.36 and earlier vanilla kernels.

 The fluke looks to me like for this card, I need to be mighty cautious and
 recompile the nouveau-drm modules more often -- or maybe it was the cold boot
 -- else I get the black/white vertical bars and kernel freeze.
 
 
 The following cards seems to work using nouveau framebuffer/Xorg:
 NV40 generation card (0x04b200b1) - G73 [GeForce 7600 GS]
 NV20 generation card (0x025300a3) - NV25 [GeForce4 Ti 4200]
 NV10 generation card (0x011200b2) - NV11 [GeForce2 Go]
 I only noticed some very very minor pixel disintegration when using Xorg 
 Seamonkey using LCars(?) theme colors.  Likely the LCD Display timings(?).
 
 
 
 Anyways, for what it's worth, here's the dmesg output of this GeForce 7600 GS
 card:
 
 # dmesg |grep nouv
 nouveau :01:00.0: PCI INT A - GSI 16 (level, low) - IRQ 16
 [drm] nouveau :01:00.0: Detected an NV40 generation card (0x04b200b1)
 [drm] nouveau :01:00.0: Attempting to load BIOS image from PRAMIN
 [drm] nouveau :01:00.0: ... appears to be valid
 [drm] nouveau :01:00.0: BIT BIOS found
 [drm] nouveau :01:00.0: Bios version 05.73.22.51
 [drm] nouveau :01:00.0: TMDS table script pointers not stubbed
 [drm] nouveau :01:00.0: BIT table 'd' not found
 [drm] nouveau :01:00.0: Found Display Configuration Block version 3.0
 [drm] nouveau :01:00.0: Raw DCB entry 0: 01000300 0028
 [drm] nouveau :01:00.0: Raw DCB entry 1: 03000302 
 [drm] nouveau :01:00.0: Raw DCB entry 2: 04011310 0028
 [drm] nouveau :01:00.0: Raw DCB entry 3: 020223f1 00c0c080
 [drm] nouveau :01:00.0: DCB connector table: VHER 0x30 5 10 2
 [drm] nouveau :01:00.0:   0: 0x2030: type 0x30 idx 0 tag 0x08
 [drm] nouveau :01:00.0:   1: 0x0100: type 0x00 idx 1 tag 0xff
 [drm] nouveau :01:00.0:   2: 0x0210: type 0x10 idx 2 tag 0xff
 [drm] nouveau :01:00.0:   3: 0x0211: type 0x11 idx 3 tag 0xff
 [drm] nouveau :01:00.0:   4: 0x0213: type 0x13 idx 4 tag 0xff
 [drm] nouveau :01:00.0: Parsing VBIOS init table 0 at offset 0xCDAD
 [drm] nouveau :01:00.0: Parsing VBIOS init table 1 at offset 0xD457
 [drm] nouveau :01:00.0: Parsing VBIOS init table 2 at offset 0xDB8B
 [drm] nouveau :01:00.0: Parsing VBIOS init table 3 at offset 0xDD0F
 [drm] nouveau :01:00.0: Parsing VBIOS init table 4 at offset 0xDF1B
 [drm] nouveau :01:00.0: Detected 512MiB VRAM
 nouveau :01:00.0: putting AGP V2 device into 2x mode
 [drm] nouveau :01:00.0: 4 MiB GART (aperture)
 [drm] nouveau :01:00.0: Saving VGA fonts
 [drm] nouveau :01:00.0: Allocating FIFO number 0
 [drm] nouveau :01:00.0: nouveau_channel_alloc: initialised FIFO 0
 [drm] nouveau :01:00.0: Setting dpms mode 3 on vga encoder (output 0)
 [drm] nouveau :01:00.0: Setting dpms mode 3 on tmds encoder (output 1)
 [drm] nouveau :01:00.0: Setting dpms mode 3 on vga encoder (output 2)
 [drm] nouveau :01:00.0: Setting dpms mode 3 on TV encoder (output 3)
 [drm] nouveau :01:00.0: allocated 1280x1024 fb: 0x48000, bo f6a56800
 [drm] nouveau :01:00.0: 0xC210: Parsing digital output script table
 [drm] nouveau :01:00.0: Setting dpms mode 0 on tmds encoder (output 1)
 [drm] nouveau :01:00.0: Output DVI-I-1 is running on CRTC 0 using output A

 [drm] nouveau :01:00.0: PFIFO_DMA_PUSHER - Ch 0

That is a bad problem, which...

 [drm] nouveau :01:00.0: GPU lockup - switching to software fbcon

...forces the GPU unusable. No acceleration whatsoever. The
problem may or may not have been fixed in the latest git. I assume
this log is from 2.6.35, is it not?

 fb0: nouveaufb frame buffer device
 [drm] Initialized nouveau 0.0.16 20090420 for :01:00.0 on minor 0

When you provide kernel logs, please, do not filter them. Nouveau
possibly interacts with lots of other drivers.


Thanks.

-- 
Pekka Paalanen
http://www.iki.fi/pq/
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] Display goes off when framebuffer enabled and Kernel Panic with fbset

[Pekka Paalanen]

On Fri, 3 Dec 2010 22:59:25 -0900
Roger rogerx@gmail.com wrote:

 I yanked the compiled in nouveau-drm from kernel 2.6.35 and
 reinstalled the snapshot =x11-base/nouveau-drm-20100811 package
 providing kernel drivers.

 Looks like I have some newer masked 2.6.36 kernel versions I can
 try, to see if this bug still exists?

As always with unreleased software, the best is to try the latest
development code. You need a 2.6.37-rc kernel for that.

I would suggest the out-of-tree build option described in
http://nouveau.freedesktop.org/wiki/InstallDRM

and then use the x11-overlay git ebuilds (version ) for
libdrm and xf86-video-nouveau.

That is what I do with Gentoo.

Cheers.

-- 
Pekka Paalanen
http://www.iki.fi/pq/
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] updating the source tree

[Pekka Paalanen]

On Thu, 07 Oct 2010 20:07:37 +0200
Grzesiek Sójka p...@pfu.pl wrote:

 On 10/07/10 19:51, Pekka Paalanen wrote:
  On Thu, 07 Oct 2010 19:34:35 +0200
  Grzesiek Sójkap...@pfu.pl  wrote:
 
  I downloaded the nouveau/linux-2.6 using the following:
  git clone --depth 1
  git://anongit.freedesktop.org/nouveau/linux-2.6 Is there an

If you really did that
and then went into linux-2.6/ dir and said:

 # git remote update
 fatal: Not a git repository (or any parent up to mount
 parent /home) Stopping at filesystem boundary
 (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).

I don't understand. Somehow you have deleted the .git/ directory
from that checkout. Or you have GIT_DIR environment variable set.

 This probably means that to be able to update I need to download
 the nouveau/linux-2.6 using the
 
 git remote add nouveau
 git://anongit.freedesktop.org/nouveau/linux-2.6 git checkout -b
 nouveau-master nouveau/master

That works only if you already have a git repo. The previous error
says you don't have. Furthermore, the exact commands you quoted
do not actually download anything. You still need 'git remote update'
before checkout to download.

 instead of
 
 git clone 
 git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git

This will clone Linus' git repo, after which you would use the
'git remote add' incatation to add nouveau repo.

-- 
Pekka Paalanen
http://www.iki.fi/pq/
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] OT: compilation

[Pekka Paalanen]

On Thu, 07 Oct 2010 22:14:19 +0200
Grzesiek Sójka p...@pfu.pl wrote:

 I have two problems with the kernel compilation.
 
 1. I have a small rootfs. It is too small to put all the modules
 there without gzipping it first. So installing it requires lots
 of sweating. That is why I was wondering if there is a (more/less
 easy) way to make the make modules_install command gzip the
 modules on the fly.

Wait, does modprobe support compressed kernel modules? I've
never heard of that. If you really do not want to touch
the partitioning, how about symlinking some directories
elsewhere? Be careful on what is needed to boot, though.

 2. I modified the sources and after compilation the string 
 g76f6e1f-dirty was appended to the kernel version. It is a bit 
 annoying because of the lack of the space at the rootfs. Is there
 a way to avoid this kind of a version extension??

Yes, it is CONFIG_LOCALVERSION_AUTO as far as I recall, disable that.

-- 
Pekka Paalanen
http://www.iki.fi/pq/
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] Trouble with building xf86-video-nouveau

[Pekka Paalanen]

On Tue, 05 Oct 2010 10:17:05 -0700
walt w41...@gmail.com wrote:

 On 10/04/2010 10:38 PM, noname...@pochta.ru wrote:
  I have problem with building nouveau driver. I already have
  installed latest versions of mesa and libdrm. In process of
  building i have this error:
 
  drmmode_display.c: In function drmmode_xf86crtc_resize:
  drmmode_display.c:1076: error: struct _ScrnInfoRec has no
  member named pixmapPrivate
 
 Two wild guesses.  Do you have the proprietary nvidia-drivers
 package installed? If so, run 'eselect opengl list' to find out
 which version you are using.  Try switching to the xorg-x11
 version.
 
 The *- package just pulls from the git repository and build
 whatever code happens to be there at the time.  Try re-installing
 the package again to get any commits you may have missed the
 first time.

No, this is a known breakage due to API changes in the X.org
server. Nouveau DDX does not yet have a fix.

There is already a bug report:
https://bugs.freedesktop.org/show_bug.cgi?id=30482

In the mean time, you just need to revert to an older
(preferrably released) X server.

-- 
Pekka Paalanen
http://www.iki.fi/pq/
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] GeForce FX5200 dual DVI Samsung 204b

[Pekka Paalanen]

On Tue, 05 Oct 2010 16:53:16 +0200
Grzesiek Sójka p...@pfu.pl wrote:

 On 10/05/10 14:55, Francisco Jerez wrote:
  PS. I'm afraid that my system is not very stable when the AGP
  support is turned on both using the nouveau kernel source tree
  and the PLD patched 2.6.35-5 version with an extra amd-k7-agp
  patch. The Xserver uses the driver:
  Unstable? How? What's the problem?
 
 Here are the logs:
 http://yen.ipipan.waw.pl/~gs159090/tmp/log.tgz
 
 BTW: Sometimes the Xserver freezes during normal work.
 Unfortunately I was not able to generate such a crush now. I send
 you logs if it happens again.

Whoa, you have three graphics cards/chips?
X log lists three devices, maybe the third one is not
a graphics card?

Anyway, the Matrox card is an important detail.

X drivers in use:
- nouveau
- mga

kernel drivers in use:
- matroxfb (fb0)
- nouveau (fb1)

Your kernel log is missing the part from boot to 12
seconds. Might not contain anything important, but
would be nice to see it.

You are missing VGA arbiter support in kernel.

I'm not sure how many conflicts all those cards and drivers
create in theory, but missing VGA arbiter is not good in
a multi-card machine.

I hope someone can tell, if the following are conflicts, and
if so, are they fixable:
- mga vs. nouveau DDX (XAA vs. EXA, pre-Randr vs. Randr 1.2)
- mga vs. matroxfb (kernel driver vs. X driver)
- matroxfb vs. nouveau (legacy kernel fb driver vs. KMS driver,
multiple fb devices)

Finally, there is a kernel BUG at the end of the log,
from TTM. I can't tell if it is something already
fixed.

One option is to remove all but the nvidia graphics card,
that would hopefully stabilise your system immediately.
Apparently you are not really using the Matrox card, yes?
At least, disable matroxfb and mga, and enable VGA arbiter,
if not touching the hardware.


Cheers.

-- 
Pekka Paalanen
http://www.iki.fi/pq/
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] dual head

[Pekka Paalanen]

On Tue, 05 Oct 2010 12:31:51 +0200
Grzesiek Sójka p...@pfu.pl wrote:

 Is it possible to get two different fb devices using dual head
 GPU and the nouveau.ko module??

Do you mean the kernel fb devices, /dev/fb*?

AFAIK that is not implemented. Do you want to run
two fb applications on different monitors without X?
Or do you want multi-seat X? What is your use case?

-- 
Pekka Paalanen
http://www.iki.fi/pq/
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] GeForce FX5200 dual DVI Samsung 204b

[Pekka Paalanen]

On Tue, 28 Sep 2010 18:17:25 +0200
Grzesiek Sójka p...@pfu.pl wrote:

 I'm completely lost at the moment so let me start from the
 beginning. First thing is that everything works fine with Nvidia
 binary drivers, which means that hardware is rather OK. After
 loading of the nouveau.ko the monitor connected to DVI-I-1 goes
 to the standby mode. I do not know if the head is turned of or
 maybe some kind of rates are too high/low. I was trying to play
 with video=DVI-I-1: with different modes and switches (M/R/D/e)
 and nothing. At the some time (after loading nouveau.ko) the
 monitor connected with the DVI-I-2 starts to blink. And again I
 was playing with the video=DVI-I-2:??? and nothing. I thought
 that maybe after starting the xorg I will get the proper image at
 both monitor. Unfortunately - no success. According to the Xorg
 log file (Option ModeDebug true) all the refresh rates are
 ok. Moreover I was trying to use different ModeLines and nothing.
 The X server claims that there are two monitor connected and
 working but the first one is in standby mode and the second is
 blinking. Any ideas?? If you need some more information please
 let me know.

Yes, the complete kernel and X logs, like I have requested twice before.
That is the minimum before anyone will seriously start looking into it.

Preferrably, use the simplest setup that fails:
- only one monitor physically connected
- the following xorg.conf:

Section Device
Identifier n
Driver nouveau
Option ModeDebug true
EndSection


Thanks.

-- 
Pekka Paalanen
http://www.iki.fi/pq/
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] GeForce FX5200 dual DVI Samsung 204b

[Pekka Paalanen]

On Tue, 28 Sep 2010 12:43:12 +0200
Grzesiek Sójka p...@pfu.pl wrote:

 On 09/27/10 23:41, Pekka Paalanen wrote:
  Are you saying that forcing a low-refresh-rate mode via video=
  kernel argument does not help?
  
  But you still do get a good picture on the framebuffer console,
  do you not? In that case, X is overriding what kernel thinks is
  the best mode, so you should clean up the X config.
  
  If wiping the X config does not help, post kernel and X logs.
 
 1. At the moment I try to get a proper image on the console. I
 put the comment about the X-log only to explain why I thing that
 there is something wrong with PixClk. Actually the screen blinks
 in the some way at the console and when I run the X-server. I was
 trying to play with the ModeLine but it seems to be ignored. For
 example whatever i put +hsync +vsync or -hsync -vsync I always
 get at the OSD info that both polarisation are positive. So it
 looks like all the timings and etc. are set by the nouveau.ko not
 by the xorg nouveau driver.

Are you sure X even runs and doesn't die too soon?
Anyway, one thing at a time, better disable X for now to debug this.

You said you have dual monitors, does the problem occur with only one?

 2. Whatever I put to the video= I always get the some problem. It
 looks a little bit like only the resolutions is taken and all the
 rest is ignored. I do not have the way to check it but my LCD
 always claims that the mode is 1600x1...@60 horizontal 74.9KHz
 and both polarizations positive. It does not display the PixClk.

I forgot about the dual monitors. When you have more than one
output active, it is best to be explicit on which output is being
set via video= argument, see Forcing Modes at
http://nouveau.freedesktop.org/wiki/KernelModeSetting

My idea with video= was the timings are (sometimes?) computed
with a standard formula, CVT or GTF.
I would expect lower resolution or refresh to produce lower
pixel clock. Experimenting with non-standard modes might be
interesting.

 So the situation is very strange. I think that the good start
 would be checking what are the current rates of the vertical,
 horizontal and pixclk. Is it a way to force nouveau.ko to put it
 into the dmesg?? If not then maybe I could just hard-code
 something like: printk(h=%d,V=%d,P=%d, ???
 into the source tree. The question is where to put it and what
 are the names of the appropriate variables.

Nouveau kernel module has reg_debug option which would show
the raw values being programmed to hardware. drm.ko has the
debug parameter, for which I don't have the documentation at
hand here. It is a bitmask, too. Someone else should guide
you with the source tree.

I think it would be best to make a report in bugzilla,
where you can attach kernel and X logs. X is by default
more verbose, like you said. In X, Option ModeDebug true
in the Device section will give even more information. This
should be done with otherwise minimal xorg.conf.

Did you ever need anything special with the proprietary
driver, like ModeLines or EDID data from file in xorg.conf?


Thanks.

PS. samsung syncmaster 204b, eh? I got one today, I just need
to replace all the capacitors to get it working. Cheap caps
syndrome, I assume.

-- 
Pekka Paalanen
http://www.iki.fi/pq/
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] GeForce FX5200 dual DVI Samsung 204b

[Pekka Paalanen]

On Sat, 25 Sep 2010 16:04:23 +0200
Grzesiek Sójka p...@pfu.pl wrote:

 Im using GeForce FX5200 dual DVI graphics adapter connected with
 two Samsung 204b monitors. At the moment I'm using binary nvidia
 drivers and everything works fine but I'm forced to switch to
 nouveau. Unfortunately there are problems. It seems that
 nouveau.ko wrongly detects the PixelClock of my monitors. More
 precisely, after loading of nouveu.ko the screen starts to blink.
 According to my experience the problem is too hight PixelClock.
 Moreover, in the /var/log/Xorg.0.log you can find the line:
 
 NOUVEAU(0): Ranges: V min: 56 V max: 75 Hz, H min: 30 H max: 81
 kHz, PixClock max 175 MHz
 
 which is false. The maximum PixClk for Sumsung 204b is 162MHz. I
 was trying to play with the video= kernel parameter but there is
 no way to force the PixClk.

Are you saying that forcing a low-refresh-rate mode via video=
kernel argument does not help?

But you still do get a good picture on the framebuffer console,
do you not? In that case, X is overriding what kernel thinks is
the best mode, so you should clean up the X config.

If wiping the X config does not help, post kernel and X logs.


Cheers.

-- 
Pekka Paalanen
http://www.iki.fi/pq/
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH] x86, mmiotrace: add support for tracing STOS instruction

[Pekka Paalanen]

On Sat, 31 Jul 2010 22:51:01 +0200
Marcin Slusarz marcin.slus...@gmail.com wrote:

 Signed-off-by: Marcin Slusarz marcin.slus...@gmail.com
 Cc: Pekka Paalanen p...@iki.fi

I have not checked the correctness of this patch, but otherwise:
Acked-by: Pekka Paalanen p...@iki.fi

 ---
  arch/x86/mm/pf_in.c |   30 +-
  1 files changed, 17 insertions(+), 13 deletions(-)
 
 diff --git a/arch/x86/mm/pf_in.c b/arch/x86/mm/pf_in.c
 index 308e325..38e6d17 100644
 --- a/arch/x86/mm/pf_in.c
 +++ b/arch/x86/mm/pf_in.c
 @@ -40,16 +40,16 @@ static unsigned char prefix_codes[] = {
  static unsigned int reg_rop[] = {
   0x8A, 0x8B, 0xB60F, 0xB70F, 0xBE0F, 0xBF0F
  };
 -static unsigned int reg_wop[] = { 0x88, 0x89 };
 +static unsigned int reg_wop[] = { 0x88, 0x89, 0xAA, 0xAB };
  static unsigned int imm_wop[] = { 0xC6, 0xC7 };
  /* IA32 Manual 3, 3-432*/
 -static unsigned int rw8[] = { 0x88, 0x8A, 0xC6 };
 +static unsigned int rw8[] = { 0x88, 0x8A, 0xC6, 0xAA };
  static unsigned int rw32[] = {
 - 0x89, 0x8B, 0xC7, 0xB60F, 0xB70F, 0xBE0F, 0xBF0F
 + 0x89, 0x8B, 0xC7, 0xB60F, 0xB70F, 0xBE0F, 0xBF0F, 0xAB
  };
 -static unsigned int mw8[] = { 0x88, 0x8A, 0xC6, 0xB60F, 0xBE0F };
 +static unsigned int mw8[] = { 0x88, 0x8A, 0xC6, 0xB60F, 0xBE0F,
 0xAA }; static unsigned int mw16[] = { 0xB70F, 0xBF0F };
 -static unsigned int mw32[] = { 0x89, 0x8B, 0xC7 };
 +static unsigned int mw32[] = { 0x89, 0x8B, 0xC7, 0xAB };
  static unsigned int mw64[] = {};
  #else /* not __i386__ */
  static unsigned char prefix_codes[] = {
 @@ -63,20 +63,20 @@ static unsigned char prefix_codes[] = {
  static unsigned int reg_rop[] = {
   0x8A, 0x8B, 0xB60F, 0xB70F, 0xBE0F, 0xBF0F
  };
 -static unsigned int reg_wop[] = { 0x88, 0x89 };
 +static unsigned int reg_wop[] = { 0x88, 0x89, 0xAA, 0xAB };
  static unsigned int imm_wop[] = { 0xC6, 0xC7 };
 -static unsigned int rw8[] = { 0xC6, 0x88, 0x8A };
 +static unsigned int rw8[] = { 0xC6, 0x88, 0x8A, 0xAA };
  static unsigned int rw32[] = {
 - 0xC7, 0x89, 0x8B, 0xB60F, 0xB70F, 0xBE0F, 0xBF0F
 + 0xC7, 0x89, 0x8B, 0xB60F, 0xB70F, 0xBE0F, 0xBF0F, 0xAB
  };
  /* 8 bit only */
 -static unsigned int mw8[] = { 0xC6, 0x88, 0x8A, 0xB60F, 0xBE0F };
 +static unsigned int mw8[] = { 0xC6, 0x88, 0x8A, 0xB60F, 0xBE0F,
 0xAA }; /* 16 bit only */
  static unsigned int mw16[] = { 0xB70F, 0xBF0F };
  /* 16 or 32 bit */
  static unsigned int mw32[] = { 0xC7 };
  /* 16, 32 or 64 bit */
 -static unsigned int mw64[] = { 0x89, 0x8B };
 +static unsigned int mw64[] = { 0x89, 0x8B, 0xAB };
  #endif /* not __i386__ */
  
  struct prefix_bits {
 @@ -410,7 +410,6 @@ static unsigned long *get_reg_w32(int no,
 struct pt_regs *regs) unsigned long get_ins_reg_val(unsigned long
 ins_addr, struct pt_regs *regs) {
   unsigned int opcode;
 - unsigned char mod_rm;
   int reg;
   unsigned char *p;
   struct prefix_bits prf;
 @@ -437,8 +436,13 @@ unsigned long get_ins_reg_val(unsigned long
 ins_addr, struct pt_regs *regs) goto err;
  
  do_work:
 - mod_rm = *p;
 - reg = ((mod_rm  3)  0x7) | (prf.rexr  3);
 + /* for STOS, source register is fixed */
 + if (opcode == 0xAA || opcode == 0xAB) {
 + reg = arg_AX;
 + } else {
 + unsigned char mod_rm = *p;
 + reg = ((mod_rm  3)  0x7) | (prf.rexr  3);
 + }
   switch (get_ins_reg_width(ins_addr)) {
   case 1:
   return *get_reg_w8(reg, prf.rex, regs);
 -- 
 1.7.1.1

-- 
Pekka Paalanen
http://www.iki.fi/pq/
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] 2 cards in, but work only separately

[Pekka Paalanen]

On Sat, 31 Jul 2010 22:08:23 +
Kārlis Repsons k...@11.lv wrote:

 Hi list,
 my thanks to developers of nouveau first: I wonder how you put it
 together this far, where there's quite enough to appreciate!
 
 This question I have: strangely I can get each of 2 cards to work
 separately for a dualseat PC by toggling on/off fbcon=map: kernel
 option (compiled with CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY)
 -- by doing so I can have each card initialized and start it's
 Xorg, all welll, but can't have both cards initialized (and thus
 used) -- why?
 
 In very short, this is what my dmesg says:
 [drm] Initialized drm 1.1.0 20060810
 nouveau :01:00.0: PCI INT A - GSI 16 (level, low) - IRQ 16
 [drm] Initialized nouveau 0.0.16 20090420 for :01:00.0 on
 minor 0 nouveau :04:00.0: enabling device ( - 0002)
 nouveau :04:00.0: PCI INT A - GSI 16 (level, low) - IRQ 16
 nouveau :04:00.0: PCI INT A disabled
 nouveau: probe of :04:00.0 failed with error -12

Is this really a continuous section of the kernel log, no
lines removed from between?

If that is so, you are using user mode setting, which has been
depracated and removed a long time ago. No support whatsoever
in that case. KMS is mandatory, can you try with that?

What versions of the Nouveau components and the kernel you have?
What cards do you have?

 :01 is address of one card, :04 of the other. What
 happens is that one of cards will fail to be initialized (in one
 case 01, other time 04). So is that supposed to be that way
 currently or I missed to pass some parameters or bug, or..? What
 more should I post here if anyone interested in this?

-- 
Pekka Paalanen
http://www.iki.fi/pq/
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] Why do we disable local IRQ around nouveau_fence_update?

[Pekka Paalanen]

On Wed, 26 May 2010 23:24:57 +0200
Maarten Maathuis madman2...@gmail.com wrote:

 For NV04 i can understand, since it's irq driven fences, so let's
 split the question.
 
 NV10+: can we reduce it to just spin_lock?

I don't know the answer, but I know the theory: if there is
any path, that can take the spinlock from an interrupt
service path, then you must use the irq-safe version everywhere.

 NV04: can't we rely on a normal spin lock and add it as well in
 nv04_graph_mthd_set_ref?

So if NV04 fences are driven by irqs, and the ISR needs to
take the lock, then no, you cannot revert to irq-unsafe spinlocks.
I'm not sure how it relates to ISR bottom halves, though.

Note, that also irq-unsafe spinlocks disable preemption, which
might be enough to disturb audio.


my 2c

-- 
Pekka Paalanen
http://www.iki.fi/pq/
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] Kernel module fails to initialize on AMD751 based system with NV34

[Pekka Paalanen]

On Mon, 24 May 2010 22:55:46 +0200
Clemens Eisserer linuxhi...@gmail.com wrote:

 Hi,
 
  NV0? That's a very bad sign to start with. I'm surprised
  Nouveau does not just throw up right there.
 
 Nouveau status page says NV0x is supported for basic 2D stuff.
 Beside that, I started with NV34 and after that failed, I tried
 that NV0x card.

Notice, how the log did not say NV4, NV04, NV5 nor NV05;
it said NV 0. Your NV34 is detected properly, though.

  These both mention nvidiafb, one of them even rivafb.
  Are you sure these are not loaded? (This is a basic
  troubleshooting question,
  http://nouveau.freedesktop.org/wiki/TroubleShooting )
 
 Come on, I wouldn't have asked here if that would be the case.

In that case you will be surprised to hear that quite many
people ask before reading TroubleShooting.

Sorry, I missed the link to the Ubuntu bug report.
The kernel log there shows that a conflicting driver is
loading:

[3.772842] vga16fb: mapped to 0xc00a
[3.773752] fb0: VGA16 VGA frame buffer device

vga16fb is specifically mentioned as conflicting in
TroubleShooting.

Could you try without vga16fb?


Thanks.

-- 
Pekka Paalanen
http://www.iki.fi/pq/
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] Kernel module fails to initialize on AMD751 based system with NV34

[Pekka Paalanen]

On Mon, 24 May 2010 21:02:09 +0200
Clemens Eisserer linuxhi...@gmail.com wrote:

 Updating the Bios (latest version for that board was Dec. 2000)
 didn't help. I also tried nouveau with an old TNT2M64 card, but
 that didn't succeed either:
 
 [3.443164] nouveau :01:05.0: PCI INT A - Link[LNKB] -
 GSI 11 (level, low) - IRQ 11
 [3.459167] [drm] nouveau :01:05.0: Detected an NV 0
 generation card (0x20114000)
clip

NV0? That's a very bad sign to start with. I'm surprised
Nouveau does not just throw up right there.

Btw. you have not provided a *complete* kernel log from boot.
Plain text attachment would be nice, since your email client
breaks the lines and makes it hard to read. But before that...

 01:05.0 VGA compatible controller: nVidia Corporation NV5M64 [RIVA
 TNT2 Model 64/Model 64 Pro] (rev 11)
   Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV-
 VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
   Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium
 TAbort- TAbort- MAbort- SERR- PERR- INTx-
   Interrupt: pin A routed to IRQ 11
   Region 0: Memory at ee00 (32-bit, non-prefetchable)
 [size=16M] Region 1: Memory at e200 (32-bit, prefetchable)
 [size=32M] Expansion ROM at efef [disabled] [size=64K]
   Capabilities: access denied
   Kernel modules: nvidiafb, rivafb, nouveau

clip

 01:05.0 VGA compatible controller: nVidia Corporation NV34
 [GeForce FX 5200] (rev a1)
   Subsystem: XFX Pine Group Inc. Device 1351
   Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV-
 VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
   Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium
 TAbort- TAbort- MAbort- SERR- PERR- INTx-
   Interrupt: pin A routed to IRQ 11
   Region 0: Memory at ee00 (32-bit, non-prefetchable)
 [size=16M] Region 1: Memory at d800 (32-bit, prefetchable)
 [size=128M] Expansion ROM at efee [disabled] [size=128K]
   Capabilities: access denied
   Kernel modules: nvidiafb, nouveau

These both mention nvidiafb, one of them even rivafb.
Are you sure these are not loaded? (This is a basic
troubleshooting question,
http://nouveau.freedesktop.org/wiki/TroubleShooting )

A complete kernel log would have shown, if these
bad drivers load.

-- 
Pekka Paalanen
http://www.iki.fi/pq/
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] xf86-video-nouveau-git and xorg-server-git

[Pekka Paalanen]

On Thu, 13 May 2010 22:00:52 +0200
yaiba.kurog...@interia.pl wrote:

 Hi! With current git version of xorg-server when I try to compile 
 xf86-video-nouveau I got these errors:
 nouveau_exa.lo
 nouveau_exa.c: In function 'nouveau_exa_create_pixmap':
 nouveau_exa.c:325:3: warning: 'Xcalloc' is deprecated (declared
 at /usr/include/xorg/os.h:225)
 nouveau_exa.c:331:2: warning: 'Xcalloc' is deprecated (declared
 at /usr/include/xorg/os.h:225)
 nouveau_exa.c:372:3: warning: 'Xfree' is deprecated (declared at 
 /usr/include/xorg/os.h:234)
 nouveau_exa.c: In function 'nouveau_exa_destroy_pixmap':
 nouveau_exa.c:388:2: warning: 'Xfree' is deprecated (declared at 
 /usr/include/xorg/os.h:234)
CC nouveau_xv.lo
 nouveau_xv.c: In function 'NVSetupBlitVideo':
 nouveau_xv.c:1582:2: warning: 'Xcalloc' is deprecated (declared
 at /usr/include/xorg/os.h:225)
 (...)

These are all warnings, not errors. If your build fails, the reason
is something else.

-- 
Pekka Paalanen
http://www.iki.fi/pq/
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] Blank screen at startup (conflict with VESA VGA)

[Pekka Paalanen]

On Mon, 12 Apr 2010 12:50:13 +0200
Marcin Slusarz marcin.slus...@gmail.com wrote:

 I'm not aware of any trick to make both nv and nouveau working.
 Maybe there should be a way to prevent nv (and vesa, but not
 fbdev) from loading when KMS is in use?

Yeah, there was a brief discussion about that recently:
http://people.freedesktop.org/~cbrill/dri-log/index.php?date=2010-03-21channel=nouveaushow_html=truehighlight_names=update=Updatedate=2010-03-21

I haven't heard anything about it since.

-- 
Pekka Paalanen
http://www.iki.fi/pq/
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] Blank screen at startup (conflict with VESA VGA)

[Pekka Paalanen]

On Mon, 05 Apr 2010 22:59:40 +0200
Didier Spaier didier.spa...@epsm.fr wrote:

 I have a Lenovo Thinkpad T61. lspci|grep VGA says:
 01:00.0 VGA compatible controller: nVidia Corporation Quadro NVS
 140M (rev a1)
 
 I have Slacware64-13.0 and Slackware64-current installed.
 
 Nouveau is modularized in all my kernels for -current.
 
 A problem arise even if I don't want to use nouveau under X:
 unless nouveau be blacklisted in /etc/modprobe.d/blacklist.conf
 at startup,
 - when using one of the VESA modes at startup after a while
 screen goes blank and I get a warning in syslog e.g: Apr  2
 18:58:56 darkstar kernel: fb: conflicting fb hw usage nouveaufb
 vs VESA VGA - removing generic driver,

This message is the expected behaviour. It is not an error.
It means the vesafb hand-over is working, or at least it
is attempted.

At what stage does the screen go blank? At X startup?

 - no problem when using a VGA mode (text only),
 
 this disregarding which X driver I use afterwards (I always start
 in console mode).

Are you trying to use nouveau.ko in kernel, and a non-Nouveau
X driver at the same time? That cannot work.

If nouveau.ko is loaded, the only option for X is to use
the nouveau driver (or perhaps fbdev). Any other driver,
e.g. vesa or nv, will lead to trouble.

What kind of setup are you trying to run in this regard?

 But according to this page:
 http://nouveau.freedesktop.org/wiki/KernelModeSetting
 I thought nouveaufb shouldn't conflict with vesafb ? Am I wrong ?

The hand-over should work: when nouveaufb initialises, vesafb
gets automatically deactivated.

In any case, complete kernel and X logs will help to diagnose
your situation.

-- 
Pekka Paalanen
http://www.iki.fi/pq/
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] Gallium driver and compatibility issues

[Pekka Paalanen]

On Fri, 12 Mar 2010 17:09:38 +0100
Uwe Bugla uwe.bu...@gmx.de wrote:

 Reason / Conclusion:
 Developers of whatever kind of software aren't omnicient gods.
 They need feedback, cause without that feedback they are lost.

The point is, the developers do NOT need feedback TODAY.
They have enough broken applications to debug on their own.
When this situation changes, it will certainly be announced
to the world. But not yet.

That is the reason why end users should not be trying the
3D part of the driver set. This is also why developers are
so hostile to 3D issues.

-- 
Pekka Paalanen
http://www.iki.fi/pq/
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] Gallium driver and compatibility issues

[Pekka Paalanen]

On Fri, 12 Mar 2010 14:51:34 +0100
Uwe Bugla uwe.bu...@gmx.de wrote:

 Note, that the Nvidia proprietary driver.
 Lapse No. 3:
 Misleading usage of expressions.
 Everybody talking about the Nvidia proprietary driver in the
 graphic card context of Nvidia cards normallly means the blob
 driver shipped by Nvidia (closed source driver!) which does not
 have any problems with stuff like Compiz or other 3D
 applications. I do not like blob drivers for a whole bunch of
 reasons. As you are definitely using the wrong expression it
 remains your personal secret what you are trying to express or
 say.

One of the most common reasons for problems with Nouveau are
the remnants of the proprietary driver. Since you did not
provide kernel log, X log, nor glxinfo output, I of course
assumed the most probable case. A stale libglx from the blob
kills OpenGL, for instance.

Furthermore, you cannot have the Nvidia proprietary 3D
driver running by default, and then use the Nouveau 3D driver
on selected apps. If you use *any* part of Nouveau, you cannot
have *any* part of the proprietary driver, and vice versa.
They cannot live together at all.

I'm sorry I guessed your problem wrong. There was no real
information to begin the diagnosis with.

 Problems are expected on the OpenGL front.
 Lapse No. 4:
 I did not mention nearly all driver parts of the Gallium drivers
 carrying the GL in their names just by chance. I reflect while
 I am typing messages. I explicitly mentioned that the versions of
 the driver parts carrying the GL in their names are NOT
 responsible for the breakage that I reported.
 Thus it still remains your personal secret what you mean by
 OpenGL front.

Actually, they are. Mesa libGL will try to load nouveau_dri.so
to provide hardware accelerated 3D rendering. At this time
OpenGL (via Mesa) is the only real user of nouveau_dri.so.
nouveau_dri.so may be loaded by the X server (AIGLX) or
the application (direct rendering) when they load libGL.

In short, having nouveau_dri.so will break OpenGL and perhaps
kill the X server in the AIGLX case.

 Lapse No. 6:
 Instead of repeating the core message of my request for 4 times
 in this mail (how insane!) I propose to change this page
 http://nouveau.freedesktop.org/wiki/GalliumHowto
 
 in the following way:
 
 1. Wipe off the following stupid idiotic crap:
 
 Warning : Nouveau's developers don't want people to build
 gallium drivers now, and do not support it at all. They also
 don't want bug reports on gallium ATM. This is code in rapid
 development. Bug reports for this are useless, as it's known to
 be broken.

That is rude on purpose. It is supposed to be crystal clear
to everyone, that this is not yet for end users, but apparently
it is not that clear. The time for end users will come, later.
At that time the page will be rewritten to be polite. Right now
it is just a cheatsheet for new developers.

 And once again: The error is not hidden in some library
 file containing the GL in its name, and the versioning of those
 GL files is also NOT the problem.
 It's the sources of the nouveau_dri.so file that do contain the
 bug.

True. nouveau_dri.so misses complete features and contains bugs.

I read your two first posts as nothing more than an elaborate
Fix everything, please. That really is what people are actually
doing on their free time. Trying to kick their butt can only make
them ignorant or angry.

-- 
Pekka Paalanen
http://www.iki.fi/pq/
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] no start with latest modules from git

[Pekka Paalanen]

On Thu, 25 Feb 2010 01:37:57 -0800 (PST)
Sebastian Glita gls...@yahoo.com wrote:

 ok, thanks, but in this way only kernel 2.6.32 was available.
 s.

So you do the out-of-tree build and use 2.6.33 if you wish.
Just get the DRM modules from nouveau/linux-2.6.

 On Wed, Feb 24, 2010 at 11:02 AM, Sebastian Glita
 gls...@yahoo.com wrote:
  Hello,
 
  Using code from git a week is since I cannot start Xorg with
  nouveau on a Quatro NVS 290.
 
  Commits from git.freedesktop.org:
 
  xorg-server - db4f676f25c6d8e58263d5151942be730592d444
  xf86-video-nouveau - 70d0a48b6c3f1a817bf850acd3bae48d063e56b9
  libdrm - 3130f94c6ee32668cb9f0b96b6c8e308a7bb3b11
  mesa - e16f0c14f353cc04ad6cbcf99e3b95ccb1d2c06b
 
 
 And where is the kernel / nouveau drm ? This is probably even more
 important than the rest :)
 So upgrade it too with
 http://cgit.freedesktop.org/nouveau/linux-2.6/

-- 
Pekka Paalanen
http://www.iki.fi/pq/
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH] drm/nouveau: don't hold spin lock while calling kzalloc with GFP_KERNEL

[Pekka Paalanen]

On Sun,  7 Feb 2010 02:11:20 +0100
Maarten Maathuis madman2...@gmail.com wrote:

 - 'joi' on irc pointed out that this triggers a BUG_ON, because
 kzalloc could sleep.
 - The irq handler should restore the value NV03_PFIFO_CACHES, but
 still it's better if this stuff doesn't happen in the middle of
 fifo create context. I see no reason in spin locking pgraph
 create context, it isn't activated at that stage.
 - Move and rename the lock after some discussion with 'joi', even
 better naming suggestions are appreciated.
 
 Signed-off-by: Maarten Maathuis madman2...@gmail.com
 ---
  drivers/gpu/drm/nouveau/nouveau_channel.c |9 ++---
  drivers/gpu/drm/nouveau/nouveau_drv.h |4 +++-
  drivers/gpu/drm/nouveau/nouveau_irq.c |4 ++--
  drivers/gpu/drm/nouveau/nouveau_state.c   |2 +-
  drivers/gpu/drm/nouveau/nv04_fifo.c   |5 +
  drivers/gpu/drm/nouveau/nv40_fifo.c   |5 +
  drivers/gpu/drm/nouveau/nv50_fifo.c   |4 
  7 files changed, 22 insertions(+), 11 deletions(-)

...

 diff --git a/drivers/gpu/drm/nouveau/nv50_fifo.c
 b/drivers/gpu/drm/nouveau/nv50_fifo.c index 204a79f..983e43b
 100644 --- a/drivers/gpu/drm/nouveau/nv50_fifo.c
 +++ b/drivers/gpu/drm/nouveau/nv50_fifo.c
 @@ -243,6 +243,7 @@ nv50_fifo_create_context(struct
 nouveau_channel *chan) struct drm_device *dev = chan-dev;
   struct drm_nouveau_private *dev_priv = dev-dev_private;
   struct nouveau_gpuobj *ramfc = NULL;
 + unsigned long flags;
   int ret;
  
   NV_DEBUG(dev, ch%d\n, chan-id);
 @@ -278,6 +279,8 @@ nv50_fifo_create_context(struct
 nouveau_channel *chan) return ret;
   }
  
 + spin_lock_irqsave(dev_priv-context_switch_lock, flags);
 +
   dev_priv-engine.instmem.prepare_access(dev, true);
  
   nv_wo32(dev, ramfc, 0x08/4, chan-pushbuf_base);
 @@ -310,6 +313,7 @@ nv50_fifo_create_context(struct
 nouveau_channel *chan) return ret;
   }
  
 + spin_unlock_irqrestore(dev_priv-context_switch_lock,
 flags); return 0;
  }

After this patch, sparse complains:
drivers/gpu/drm/nouveau/nv50_fifo.c:241:1: warning: context imbalance in 
'nv50_fifo_create_context' - different lock contexts for basic block

Near the end of the function, the failure exit path does not unlock the
spinlock.

Btw. before this patch nouveau_channel_alloc() contains two cases of
failure path not releasing the spinlock, plus, under the spinlock,
a call to a function that re-locks the spinlock, hence hangs.
Sparse does warn about exiting a function without releasing a
spinlock in every path, i.e., inconsistent lock behaviour.

Thanks.

-- 
Pekka Paalanen
http://www.iki.fi/pq/
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH] drm/nouveau: don't hold spin lock while calling kzalloc with GFP_KERNEL

[Pekka Paalanen]

On Mon, 8 Feb 2010 12:02:01 +0100
Maarten Maathuis madman2...@gmail.com wrote:

 Thanks for pointing that out, is it preferred to use goto style
 failure or just stick the spin unlock everywhere where you return?

In this particular case, just add the unlock where it is needed.
But, keep in mind what might happen, if something else accesses
the things protected by the lock just between you releasing it and
the cleanup function acquiring it.

I believe the goto-style is the preferred way of doing it, but
that would mean rewriting a lot of code, since IMO the calls to
nouveau_channel_free() in the case of nouveau_channel_alloc()
are already non-goto-style. And the functions are very long to
begin with, this would only make them even longer.

Not worth to rewrite it all, unless you find yourself contemplating on
adding parameters like 'bool is_already_locked' to cleanup functions.


Cheers.

-- 
Pekka Paalanen
http://www.iki.fi/pq/
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] 2.6.33 vs. NVIDIA GForce GT 220

[Pekka Paalanen]

On Wed, 27 Jan 2010 18:28:06 -0800
Stephane Marchesin stephane.marche...@gmail.com wrote:

 On Tue, Jan 26, 2010 at 01:47, Pavel Machek pa...@ucw.cz wrote:
  Hi!
 
I tried enabling staging nvidia driver on GT220, but
apparently driver does not know about it. Unfortunately, I
have one of those cards here.
   
(I wonder... is there better mailing list? MAINTAINERS
only lists linux-fbdev)
 
  The list is nouv...@lists.freedesktop.org. And driver knows
  about GT220 just fine, I've been using it for a month or two
  on GT220 already. Don't bother
 
  Perhaps nouveau@lists.freedesktop.org should be added to
  MAINTAINERS?
 
  about the supported cards lists in xf86-video-nouveau or
  wherever else, the driver will happily bind to any nvidia
  video card with known generation, even if nobody has seen that
  precise model before.
 
  Unfortunately, the driver does not seem happy:
 
  Jan 18 12:56:38 pma kernel: [    0.491073] nvidiafb
  :01:00.0: PCI INT A - GSI 16 (level, low) - IRQ 16
  Jan 18 12:56:38 pma kernel: [    0.491507] nvidiafb: Device ID:
  10de0a20
  Jan 18 12:56:38 pma kernel: [    0.491546] Chipset is 10de0a20
  Jan 18 12:56:38 pma kernel: [    0.491584] nvidiafb: unknown
  NV_ARCH Jan 18 12:56:38 pma kernel: [    0.492119] vga16fb:
  initializing
 
 
 Hmm, but this is not nouveau, this is nvidiafb...

And both nvidiafb and vga16fb are known make Nouveau misbehave:
nvidiafb because it messes up the card state, and vga16fb because it
does not do the fb driver hand-over, AFAIK.

Relevant or not, I'd like to advertise our new troubleshooting page:
http://nouveau.freedesktop.org/wiki/TroubleShooting

I'm also adding the CCs that were dropped earlier.

Was the original question in this thread about nvidiafb or Nouveau?


Thanks.

-- 
Pekka Paalanen
http://www.iki.fi/pq/
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH] drm/nouveau: Add module options to disable acceleration.

[Pekka Paalanen]

On Tue, 26 Jan 2010 14:00:42 +
Marcin Kościelnicki koria...@0x04.net wrote:

 noaccel=1 disables all acceleration and doesn't even attempt
 initialising PGRAPH+PFIFO, nofbaccel=1 only makes fbcon
 unaccelerated.
 
 Signed-off-by: Marcin Kościelnicki koria...@0x04.net
 ---
  drivers/gpu/drm/nouveau/nouveau_drv.c   |8 +++
  drivers/gpu/drm/nouveau/nouveau_drv.h   |2 +
  drivers/gpu/drm/nouveau/nouveau_fbcon.c |   10 ++--
  drivers/gpu/drm/nouveau/nouveau_state.c |   32
 +++--- 4 files changed, 37 insertions(+),
 15 deletions(-)
 
 diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.c
 b/drivers/gpu/drm/nouveau/nouveau_drv.c index 343ab7f..a44c3f9
 100644 --- a/drivers/gpu/drm/nouveau/nouveau_drv.c
 +++ b/drivers/gpu/drm/nouveau/nouveau_drv.c
 @@ -75,6 +75,14 @@ MODULE_PARM_DESC(ignorelid, Ignore ACPI lid status);
 int nouveau_ignorelid = 0;
  module_param_named(ignorelid, nouveau_ignorelid, int, 0400);
  
 +MODULE_PARM_DESC(noagp, Disable all acceleration);
 +int nouveau_noaccel = 0;
 +module_param_named(noaccel, nouveau_noaccel, int, 0400);
 +
 +MODULE_PARM_DESC(noagp, Disable fbcon acceleration);
 +int nouveau_nofbaccel = 0;

Globals should not be initialized to zero, since they default to
zero. checkpatch.pl complains:
ERROR: do not initialise externals to 0 or NULL

-- 
Pekka Paalanen
http://www.iki.fi/pq/
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [Discussion] User controls for PowerManagement

[Pekka Paalanen]

Adding dri-devel@ to CC.

On Thu,  7 Jan 2010 22:44:24 +0100
r.spl...@umail.leidenuniv.nl wrote:

 With some progress in PowerManagement support (there's a patch
 nearly done for reading the P-tables, written mostly by xexaxo,
 derived from thunderbirds nvclock, with 0x40 adjustments from
 myself) in my opinion it's time to think about the user aspect of
 this. My personal idea for GPU scaling was similar to that of CPU
 scaling in appearance eventually. When you look at the
 cpufreq-applet for Gnome, you see the choice between every
 supported CPU speed, and an option for Automatic scaling. To make
 an application like this possible nouveau needs to communicate
 with users. I was thinking a procfs or sysfs node for outputting
 a readable table with possible modes like:
 
 03: CPU=135MHz,Shdr=135MHz,Mem=135MHz,Vlt=0.8V,Fan=80%;
 ...
 
 the node name would be something like pm_supported. Another node
 named pm_current could output the current mode (for instance 03),
 and be writable to set the desired mode. Mode numbers will be the
 identifier given by pm_supported, found in the powermode table. A
 third node would then be required to set auto scaling on or off
 (called pm_auto ?). All those nodes could eventually be placed in
 a separate subdirectory (pm?)
 
 1. joi pointed out that procfs is deprecated, and I should use
 sysfs instead. There are two reasons to use procfs:
 - DRM has a pointer to the right DRM subfolder (/proc/drm/card
 number) which can be obtained by drm_device.control-proc_root.
 numberOfcourse, if there's
 something similar for sysfs available, then there's no problem.
 Otherwise procfs simply saves a lot of hassle as long as DRM
 still promotes procfs to the device drivers.
 - sysfs was designed for one value per node. The output of the
 pm_supported node would be an entire table. Is this on par with
 the design of sysfs? So: procfs or sysfs?
 
 2. It sounds sensible to me to have one scaling algorithm
 (whatever that may become... first things first). When you can
 scale you can have the maximum performance as soon as you need
 it... so the aim should be maximum powersaving at all time,
 without sacrificing on performance. Agreed, or should there be
 several auto modes for different situations?

I recall someone (you?) saying this is only for testing for
now, and the proper user interface can be done later. In
any case, I'd like to suggest discussing it on dri-devel@,
since there are other drivers wanting to expose similar
features.

Hopefully people working on power management interfaces
on intel and radeon can comment on this, like is there
an agreed user interface design yet.

btw. I think max powersaving and no performance loss are
mutually exclusive, since changing power modes is not
free nor instantenous. Or is it? How much of the card
you need to stop to change clocks and volts? Do you
need to sync to vblank to prevent visual glitches?

-- 
Pekka Paalanen
http://www.iki.fi/pq/
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [Discussion] User controls for PowerManagement

[Pekka Paalanen]

On Sun, 10 Jan 2010 12:43:02 +0200
Alexey Dobriyan adobri...@gmail.com wrote:

  On Thu,  7 Jan 2010 22:44:24 +0100
  r.spl...@umail.leidenuniv.nl wrote:
  
   1. joi pointed out that procfs is deprecated, and I should use
   sysfs instead.
 
 /proc is not deprecated per se, you simply shouldn't expose
 everything you know to userspace, because it will be impossible
 to remove later.

I think adding random crap to procfs is frowned upon nowadays,
that's probably what he meant. Attributes should be in sysfs.
What to expose is another question, you are right.

If the interface is just temporary, it should probably go into
debugfs. That way one can have the code in the kernel proper,
not fear about freezing it, and prevent people from finding it
by accident. And it should be guarded by an EXPERIMENTAL, DANGEROUS
Kconfig option in any case.

-- 
Pekka Paalanen
http://www.iki.fi/pq/
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] Removal of Non-KMS support

[Pekka Paalanen]

On Wed, 06 Jan 2010 15:32:30 +1000
Ben Skeggs skeg...@gmail.com wrote:

 I did a very quick pass at removing all the non-KMS support from
 the DDX.  It's tested on G80 but nowhere else currently, I
 thought some discussion would be a good idea rather than just
 ripping it out :)
 
 The non-KMS paths are messy, and lets face it, rotting badly.
 IMO the KMS code is stable enough now that we can continue
 without the UMS crutch, and indeed, the KMS code supports a lot
 more chipsets (particularly on GF8 and up) than the UMS code ever
 will.

Considering that any BSD will not have KMS for quite some time
(do they?), this sounds very cruel. Is it really such a big
pain to keep the code around?

OTOH, BSDs are stuck with pre-TTM Nouveau until they port GEM
and TTM to BSDs. How much more will it cost to BSDs to add KMS
to the list of mandatory kernel features... rnoland and others,
any comments?

-- 
Pekka Paalanen
http://www.iki.fi/pq/
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] NV_PFIFO_INTR_DMA_PUSHER

[Pekka Paalanen]

On Mon, 04 Jan 2010 21:46:51 +0100
Krzysztof Smiechowicz deadw...@wp.pl wrote:

 Hello,
 
 Could someone briefly describe (or point me to the documentation)
 what can be a reason for getting NV_PFIFO_INTR_DMA_PUSHER status 
 (nouveau_fifo_irq_handler).

The command stream put into a FIFO has a certain packet format.
The pusher interrupt says the given stream is corrupt, the format
is broken.

This is either a code bug (e.g. BEGIN_RING with incorrect number of
following commands), or (as in this case apparently) data
corruption.

That's all I think I know.

-- 
Pekka Paalanen
http://www.iki.fi/pq/
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] Nouveau ctxprogs (Re: [git pull] drm)

[Pekka Paalanen]

On Thu, 10 Dec 2009 15:33:13 -0500
C. Bergström cbergst...@pathscale.com wrote:

 Pekka Paalanen
 
  The big question is what we call ctxprogs: binary blobs that are
  clearly executable, running somewhere in the GPU. No-one seems
  to know, if those are copyrightable, or if they can be
  redistributed. In their current form, they have been recorded
  from the nvidia proprietary driver using mmiotrace, and copied
  verbatim for each card type.
 
 ---
 (apologies about the copy paste of thread, but I'm joining the
 list late)
 
 Please see my other response.  From my perspective there is only 
 technical issues remaining and no license issues.  I am just
 evaluating and receiving information from one of the nouveau
 devs.  However, ctxprogs was obtained in the same way that the
 rest of the information was via dumping from the mmio-traces.
 (As stated above)

When Nouveau is able to generate ctxprogs itself, I completely
agree. But the current situation is a little different. We are
not collecting just the basic blocks individually like has
been done for everything else.  We are copying a complete program
or something that is a non-trivial composition. The proprietary
driver might be generating it on the fly from basic blocks, or
it might contain the complete programs. We only see the stream
of data going into the card. Apparently there is also freedom
to do things right more than one way(?), so it is not
trivial in the sense that the hardware would force it to be
exactly what we see.

How sure you are that there won't be a problem and that it is not
actually copying a copyrighted work?
Did you already see things the way I put it here?


Thanks.

-- 
Pekka Paalanen
http://www.iki.fi/pq/
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH] nouveau: add ratelimit to nouveau_graph_dump_trap_info

[Pekka Paalanen]

On Fri, 27 Nov 2009 23:31:13 +0100
Xavier Chantry shinin...@gmail.com wrote:

 Often when things get stuck spinning, nouveau_pgraph_intr_error
 and nouveau_graph_dump_trap_info gets called many times, flooding
 logs with PGRAPH_ERROR and filling up the disk.
 
 Pekka Paalanen pointed me to ratelimit, so I went ahead and added
 some ratelimit support. It is much better now :)
 
 I am completely new to the kernel world though so I hope I did
 not do something terribly wrong.
 
 Signed-off-by: Xavier Chantry shinin...@gmail.com

Pushed, finally, with a little message trimming.
Sorry for the delay.

-- 
Pekka Paalanen
http://www.iki.fi/pq/
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [PATCH] drm/nouveau: fix array overflow

[Pekka Paalanen]

Noticed by sparse: in nouveau_dp_link_train(), the array 'status' was
defined as 2 bytes, yet it was accessed for 3 bytes.

Fix it by making the array size 3.

Signed-off-by: Pekka Paalanen p...@iki.fi
---
 drivers/gpu/drm/nouveau/nouveau_dp.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c 
b/drivers/gpu/drm/nouveau/nouveau_dp.c
index a334f17..c2d6eff 100644
--- a/drivers/gpu/drm/nouveau/nouveau_dp.c
+++ b/drivers/gpu/drm/nouveau/nouveau_dp.c
@@ -271,7 +271,8 @@ nouveau_dp_link_train(struct drm_encoder *encoder)
 {
struct drm_device *dev = encoder-dev;
struct nouveau_encoder *nv_encoder = nouveau_encoder(encoder);
-   uint8_t config[4], status[2];
+   uint8_t config[4];
+   uint8_t status[3];
bool cr_done, cr_max_vs, eq_done;
int ret = 0, i, tries, voltage;
 
-- 
1.6.4.4

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] drm git branches revisited

[Pekka Paalanen]

On Wed, 2 Dec 2009 14:10:11 +1000
Dave Airlie airl...@gmail.com wrote:

 So I'm going to change the layout of my git branches again,
 because my current plan isn't working for me.
 
 At the moment drm-next is considered the branch to base new work
 off and to also for downstream trees to
 pull from, this is changing.
 
 I will now maintain
 
 drm-core-next : a branch with all the core DRM/KMS changes in it,
 please base all downstream sub-driver
 trees from this branch in the future. This branch will not
 rebase, it may pull in a downstream driver tree in
 the pre-merge window time, and/or when some patch from that tree
 is required for a patch to the mainline.
 This will be the basis of any trees I send to Linus.

Previously, I've been doing:
git diff drm/drm-next...nouveau/master

If I understand correctly, to gather all the Nouveau development
I should now use:
git diff --stat drm/drm-core-next...nouveau/master
git log ^drm/drm-core-next nouveau/master

where nouveau is the nouveau/linux-2.6 repo.

Right?
Why do I see changes to radeon, i915 and drm core, too?

The last time drm-next was merged into nouveau/master was Nov 4th
and I am quite sure there are no radeon patches committed to
nouveau/master, it has all come from drm-next or linus' merges.

My intent was to create a tentative Nouveau patch and run it
through checkpatch.pl to see if there are new things to fix.
I've been doing that occasionally and running it takes roughly
an hour.

 drm-radeon-next: a tree like Eric's drm-intel-next where radeon
 specific changes will be queued up.
 
 drm-next: This tree will be rebased quite regularly (2-3 days)
 with a git pull of the latest, drm-core-next, drm-radeon-next
 and drm-intel-next, so that the code in drm-next is tested
 better. You should use this tree for testing latest drm stuff
 with an eye to the next Linus kernel.

-- 
Pekka Paalanen
http://www.iki.fi/pq/
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] git - compile error ratelimit - missing include linux/ratelimit.h

[Pekka Paalanen]

On Sat, 05 Dec 2009 15:16:09 -0500
Michael Breuer mbre...@majjas.com wrote:

 Building today in git - kernel 2.6.32 (git) + nouveau (git).
 
 Failed as nouveau_irq.c doesn't include linux/ratelimit.h
 
 Added the include to nouveau_irq.c and was able to compile... not
 sure that's where it ought to go.

Aha, that problem wasn't there with 2.6.31-rc9 which is what Nouveau
is still based on.

I'll push a fix shortly, thanks.

-- 
Pekka Paalanen
http://www.iki.fi/pq/
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] git - compile error ratelimit - missing include linux/ratelimit.h

[Pekka Paalanen]

On Sat, 05 Dec 2009 15:16:09 -0500
Michael Breuer mbre...@majjas.com wrote:

 Building today in git - kernel 2.6.32 (git) + nouveau (git).
 
 Failed as nouveau_irq.c doesn't include linux/ratelimit.h
 
 Added the include to nouveau_irq.c and was able to compile... not
 sure that's where it ought to go.

Okay, a fix pushed. Let me know, if it is still broken.

-- 
Pekka Paalanen
http://www.iki.fi/pq/
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] mandriva 2010.1 cooker test report

[Pekka Paalanen]

On Thu, 26 Nov 2009 15:33:09 +0100
ROUBACH Philippe philippe.roub...@free.fr wrote:

 now nouveau is supplied with Mandriva 2010.1
 
 to install it, just use the mandriva tool as usual but select
 GeForce... (nouveau...)
 
 my conf :
 Asus 8600 GT
 Philips ldc 17  170C
 1024x768 24 bit
 
 Mandriva 2010.1 cooker
 kde 4.3.75
 kernel mode setting : on
 
 - video sd (video dvd,dragon player) : ok 
 - video hd (tv, vlc) : ok 
 - video .mov : ok 
 - photo jpg : ok 
 - flashplayer sd hd : ok 
 - full screen with flashplayer or dragon player : ok 
 - screen 
  . suspend, any level : failed

What does the above failed mean, exactly?

 
 - suspend to ram : ok 
 - sees my two dvi heads : i made no test with 2 screens

-- 
Pekka Paalanen
http://www.iki.fi/pq/
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] mandriva 2010.1 cooker test report

[Pekka Paalanen]

On Thu, 26 Nov 2009 17:53:09 +0100
ROUBACH Philippe philippe.roub...@free.fr wrote:

 Le Thursday 26 November 2009 17:37:27, vous avez écrit :
 
 - screen
 . suspend, any level : failed
 
 kde 4 enregy saving level performance
 i set screen energy saving time out to 1 mn and 2 mn for the
 first and second level
 
 when 1 mn is out nothing happens, screen is still displaying my
 desktop when 2 mn is out nothing happens, screen is still
 displaying my desktop
 
 today i can't install nv or nvidia to check if it is a driver pb

Okay, thanks.
Next time, please use reply to all to have the list cc'd.

btw. you can test monitor power saving on the command line, e.g.
$ xset dpms force off

For more states, see: xset help

-- 
Pekka Paalanen
http://www.iki.fi/pq/
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] Introduction and discussion - Nouveau for Ubuntu Lucid

[Pekka Paalanen]

 proprietary driver and Nouveau.

-- 
Pekka Paalanen
http://www.iki.fi/pq/
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [PATCH 1/2] drm/nouveau: rework bios delays

[Pekka Paalanen]

Replace the BIOS_USLEEP() macro with appropriate calls to udelay() and
msleep(). BIOS_USLEEP() was implemented with mdelay(), which is a
busy-wait. msleep() on the other hand can reschedule, so these paths
cannot be called from interrupt or atomic context.

In init_reset(), BIOS_USLEEP(10) was a no-op, since the delay was
rounded off to zero. This was probably a bug in porting the DDX code to
the kernel. The delay is restored.

In init_time(), since the delay is variable with a large range, it is
implemented as a busy-wait for 1ms, and msleep() otherwise rounding
mostly to the next integer milliseconds.

call_lvds_manufacturer_script() contained a bug in the wait: the delay
was executed in microseconds, when it should be milliseconds. Fixed.

Signed-off-by: Pekka Paalanen p...@iki.fi
---
 drivers/gpu/drm/nouveau/nouveau_bios.c |   20 +++-
 1 files changed, 11 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_bios.c 
b/drivers/gpu/drm/nouveau/nouveau_bios.c
index 2cf4134..adfd263 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bios.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bios.c
@@ -40,8 +40,6 @@
 #define BIOSLOG(sip, fmt, arg...) NV_DEBUG(sip-dev, fmt, ##arg)
 #define LOG_OLD_VALUE(x)
 
-#define BIOS_USLEEP(n) mdelay((n)/1000)
-
 #define ROM16(x) le16_to_cpu(*(uint16_t *)(x))
 #define ROM32(x) le32_to_cpu(*(uint32_t *)(x))
 
@@ -286,7 +284,7 @@ static void still_alive(void)
 {
 #if 0
sync();
-   BIOS_USLEEP(2000);
+   msleep(2);
 #endif
 }
 
@@ -1690,7 +1688,7 @@ init_condition_time(struct nvbios *bios, uint16_t offset,
break;
} else {
BIOSLOG(bios, 0x%04X: Condition not met, sleeping for 
20ms\n, offset);
-   BIOS_USLEEP(2);
+   msleep(20);
}
 
if (!bios_condition_met(bios, offset, cond)) {
@@ -1939,7 +1937,7 @@ init_reset(struct nvbios *bios, uint16_t offset, struct 
init_exec *iexec)
bios_wr32(bios, NV_PBUS_PCI_NV_19, 0);
bios_wr32(bios, reg, value1);
 
-   BIOS_USLEEP(10);
+   udelay(10);
 
bios_wr32(bios, reg, value2);
bios_wr32(bios, NV_PBUS_PCI_NV_19, pci_nv_19);
@@ -2339,7 +2337,7 @@ init_time(struct nvbios *bios, uint16_t offset, struct 
init_exec *iexec)
 * Sleep for time microseconds.
 */
 
-   uint16_t time = ROM16(bios-data[offset + 1]);
+   unsigned time = ROM16(bios-data[offset + 1]);
 
if (!iexec-execute)
return true;
@@ -2347,7 +2345,10 @@ init_time(struct nvbios *bios, uint16_t offset, struct 
init_exec *iexec)
BIOSLOG(bios, 0x%04X: Sleeping for 0x%04X microseconds\n,
offset, time);
 
-   BIOS_USLEEP(time);
+   if (time  1000)
+   udelay(time);
+   else
+   msleep((time + 900) / 1000);
 
return true;
 }
@@ -3154,9 +3155,10 @@ static int call_lvds_manufacturer_script(struct 
drm_device *dev, struct dcb_entr
 
run_digital_op_script(dev, scriptofs, dcbent, head, bios-fp.dual_link);
 
-   if (script == LVDS_PANEL_OFF)
+   if (script == LVDS_PANEL_OFF) {
/* off-on delay in ms */
-   BIOS_USLEEP(ROM16(bios-data[bios-fp.xlated_entry + 7]));
+   msleep(ROM16(bios-data[bios-fp.xlated_entry + 7]));
+   }
 #ifdef __powerpc__
/* Powerbook specific quirks */
if (script == LVDS_RESET  ((dev-pci_device  0x) == 0x0179 || 
(dev-pci_device  0x) == 0x0329))
-- 
1.6.4.4

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [PATCH 2/2] drm/nouveau: fix init_condition_time() reporting

[Pekka Paalanen]

The function reported bogus wait time, if the condition was never
fulfilled. Fix it.

Also do some style fixes in this function and fix a typo.

Signed-off-by: Pekka Paalanen p...@iki.fi
---
 drivers/gpu/drm/nouveau/nouveau_bios.c |   13 +
 1 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_bios.c 
b/drivers/gpu/drm/nouveau/nouveau_bios.c
index adfd263..aee862e 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bios.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bios.c
@@ -1672,6 +1672,7 @@ init_condition_time(struct nvbios *bios, uint16_t offset,
 
uint8_t cond = bios-data[offset + 1];
uint16_t retries = bios-data[offset + 2] * 50;
+   unsigned cnt;
 
if (!iexec-execute)
return true;
@@ -1682,19 +1683,23 @@ init_condition_time(struct nvbios *bios, uint16_t 
offset,
BIOSLOG(bios, 0x%04X: Condition: 0x%02X, Retries: 0x%02X\n,
offset, cond, retries);
 
-   for (; retries  0; retries--)
+   for (cnt = 0; cnt  retries; cnt++) {
if (bios_condition_met(bios, offset, cond)) {
-   BIOSLOG(bios, 0x%04X: Condition met, continuing\n, 
offset);
+   BIOSLOG(bios, 0x%04X: Condition met, continuing\n,
+   offset);
break;
} else {
-   BIOSLOG(bios, 0x%04X: Condition not met, sleeping for 
20ms\n, offset);
+   BIOSLOG(bios, 0x%04X: 
+   Condition not met, sleeping for 20ms\n,
+   offset);
msleep(20);
}
+   }
 
if (!bios_condition_met(bios, offset, cond)) {
NV_WARN(bios-dev,
0x%04X: Condition still not met after %dms, 
-   skiping following opcodes\n, offset, 20 * retries);
+   skipping following opcodes\n, offset, 20 * retries);
iexec-execute = false;
}
 
-- 
1.6.4.4

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 3/3] nv10/exa: Replace celcius with celsius.

[Pekka Paalanen]

Hi,

I have tried these three patches on nv28:
nv10/exa: Fix PictOpAtopReverse for destination pixmaps with no alpha channel.
nv10/exa: Allow component-alpha masks.
nv10/exa: Replace celcius with celsius.

I do not see any problems, before or after. Tested also
rendercheck -t composite,cacomposite -f a8,x8r8g8b8,a8r8g8b8
and all tests pass before and after.

-- 
Pekka Paalanen
http://www.iki.fi/pq/
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH] drm/nouveau: Add DRM_NOUVEAU_DEBUG option

[Pekka Paalanen]

On Thu,  8 Oct 2009 16:26:51 -0500
Matt Parnell par...@gmail.com wrote:

 From: Matt Parnell mparn...@gmail.com
 
 Sometimes we have DEBUG_FS enabled, but don't want output from
 certain modules. Most modules make this an option, so I figured
 that Nouveau needed it too.
 
 Signed-off-by: Matt Parnell mparn...@gmail.com
 ---
  drivers/gpu/drm/Kconfig   |   11 +++
  drivers/gpu/drm/nouveau/Makefile  |2 +-
  drivers/gpu/drm/nouveau/nouveau_debugfs.c |2 --
  drivers/gpu/drm/nouveau/nouveau_drv.c |2 +-
  drivers/gpu/drm/nouveau/nouveau_drv.h |2 +-
  5 files changed, 14 insertions(+), 5 deletions(-)

Pushed, thanks.

-- 
Pekka Paalanen
http://www.iki.fi/pq/
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] master-compat branch in nouveau/linux-2.6

[Pekka Paalanen]

On Tue, 29 Sep 2009 19:46:32 +0300
Pekka Paalanen p...@iki.fi wrote:

 Hi,
 
 I would like to abandon the master-compat branch
 nouveau/linux-2.6 kernel tree. The difference to master branch is
 practically just the out-of-tree build Makefile. I'll find a new
 place for the Makefile and docs, likely in the wiki. Then I will
 break the build in master-compat, so that everyone surely notices
 it is not updated anymore.
 
 The reason for this is to reduce confusion, and that
 master-compat is usually behind master for no good reason.
 InstallDRM page in the wiki can be cleaned up about branches.
 
 This should happen in few days, and I hope everyone will move to
 using master if not already there. If you do not like the idea,
 let me know why.

No complaints received.
Master-compat is now disabled.

-- 
Pekka Paalanen
http://www.iki.fi/pq/
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 3/3] drm/nouveau: Fix TV-out for the new semantics of drm_mode_vrefresh().

[Pekka Paalanen]

All three patches pushed.

Thanks.

-- 
Pekka Paalanen
http://www.iki.fi/pq/
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] master-compat branch in nouveau/linux-2.6

[Pekka Paalanen]

Hi,

I would like to abandon the master-compat branch nouveau/linux-2.6 kernel
tree. The difference to master branch is practically just the out-of-tree
build Makefile. I'll find a new place for the Makefile and docs, likely
in the wiki. Then I will break the build in master-compat, so that
everyone surely notices it is not updated anymore.

The reason for this is to reduce confusion, and that master-compat is
usually behind master for no good reason. InstallDRM page in the wiki
can be cleaned up about branches.

This should happen in few days, and I hope everyone will move to using
master if not already there. If you do not like the idea, let me know
why.


Thanks.

-- 
Pekka Paalanen
http://www.iki.fi/pq/
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [PATCH 2/2] drm/nouveau: unify nouveau_acpi.c code with the driver style

[Pekka Paalanen]

Rename nvidia_dsm() to nouveau_dsm(), since everything else here is
nouveau-something. Otherwise it might get mixed up with other nvidia
drivers.

Use NV_ERROR() for the usual error report format. nvidia-control was
very confusing when I first saw it in logs, I thought it was from a
proprietary driver.

To be able to use NV_ERROR(), pass struct drm_device * as argument to
nouveau_dsm() instead of struct pci_dev *. Also, 'dev' in nouveau code
is usually a drm_device and pdev is a pci_dev, so fix that too.

Signed-off-by: Pekka Paalanen p...@iki.fi
---
 drivers/gpu/drm/nouveau/nouveau_acpi.c |   32 +++-
 1 files changed, 15 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_acpi.c 
b/drivers/gpu/drm/nouveau/nouveau_acpi.c
index 7fb7a9f..ec0f2f3 100644
--- a/drivers/gpu/drm/nouveau/nouveau_acpi.c
+++ b/drivers/gpu/drm/nouveau/nouveau_acpi.c
@@ -28,13 +28,14 @@
 #define NOUVEAU_DSM_POWER_SPEED 0x01
 #define NOUVEAU_DSM_POWER_STAMINA 0x02
 
-static int nvidia_dsm(struct pci_dev *dev, int func, int arg, int *result)
+static int nouveau_dsm(struct drm_device *dev, int func, int arg, int *result)
 {
static char muid[] = {
0xA0, 0xA0, 0x95, 0x9D, 0x60, 0x00, 0x48, 0x4D,
0xB3, 0x4D, 0x7E, 0x5F, 0xEA, 0x12, 0x9F, 0xD4,
};
 
+   struct pci_dev *pdev = dev-pdev;
struct acpi_handle *handle;
struct acpi_buffer output = { ACPI_ALLOCATE_BUFFER, NULL };
struct acpi_object_list input;
@@ -42,7 +43,7 @@ static int nvidia_dsm(struct pci_dev *dev, int func, int arg, 
int *result)
union acpi_object *obj;
int err;
 
-   handle = DEVICE_ACPI_HANDLE(dev-dev);
+   handle = DEVICE_ACPI_HANDLE(pdev-dev);
 
if (!handle)
return -ENODEV;
@@ -61,8 +62,7 @@ static int nvidia_dsm(struct pci_dev *dev, int func, int arg, 
int *result)
 
err = acpi_evaluate_object(handle, _DSM, input, output);
if (err) {
-   printk(KERN_ERR nvidia-control: failed to evaluate _DSM: %d\n,
-  err);
+   NV_ERROR(dev, failed to evaluate _DSM: %d\n, err);
return err;
}
 
@@ -88,24 +88,23 @@ static int nvidia_dsm(struct pci_dev *dev, int func, int 
arg, int *result)
 
 int nouveau_hybrid_setup(struct drm_device *dev)
 {
-   struct pci_dev *pdev = dev-pdev;
int result;
 
-   if (nvidia_dsm(pdev, NOUVEAU_DSM_ACTIVE, NOUVEAU_DSM_ACTIVE_QUERY,
-  result))
+   if (nouveau_dsm(dev, NOUVEAU_DSM_ACTIVE, NOUVEAU_DSM_ACTIVE_QUERY,
+   result))
return -ENODEV;
 
NV_INFO(dev, _DSM hardware status gave 0x%x\n, result);
 
if (result  0x1) { /* Stamina mode - disable the external GPU */
-   nvidia_dsm(pdev, NOUVEAU_DSM_LED, NOUVEAU_DSM_LED_STAMINA,
-  NULL);
-   nvidia_dsm(pdev, NOUVEAU_DSM_POWER, NOUVEAU_DSM_POWER_STAMINA,
-  NULL);
+   nouveau_dsm(dev, NOUVEAU_DSM_LED, NOUVEAU_DSM_LED_STAMINA,
+   NULL);
+   nouveau_dsm(dev, NOUVEAU_DSM_POWER, NOUVEAU_DSM_POWER_STAMINA,
+   NULL);
} else {/* Ensure that the external GPU is enabled */
-   nvidia_dsm(pdev, NOUVEAU_DSM_LED, NOUVEAU_DSM_LED_SPEED, NULL);
-   nvidia_dsm(pdev, NOUVEAU_DSM_POWER, NOUVEAU_DSM_POWER_SPEED,
-  NULL);
+   nouveau_dsm(dev, NOUVEAU_DSM_LED, NOUVEAU_DSM_LED_SPEED, NULL);
+   nouveau_dsm(dev, NOUVEAU_DSM_POWER, NOUVEAU_DSM_POWER_SPEED,
+   NULL);
}
 
return 0;
@@ -113,11 +112,10 @@ int nouveau_hybrid_setup(struct drm_device *dev)
 
 bool nouveau_dsm_probe(struct drm_device *dev)
 {
-   struct pci_dev *pdev = dev-pdev;
int support = 0;
 
-   if (nvidia_dsm(pdev, NOUVEAU_DSM_SUPPORTED,
-  NOUVEAU_DSM_SUPPORTED_FUNCTIONS, support))
+   if (nouveau_dsm(dev, NOUVEAU_DSM_SUPPORTED,
+   NOUVEAU_DSM_SUPPORTED_FUNCTIONS, support))
return false;
 
if (!support)
-- 
1.6.3.3

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [PATCH 1/2] drm/nouveau: unify logging format with DRM core

[Pekka Paalanen]

Change NV_PRINTK() to use DRM_NAME and DRIVER_NAME, making it
essentially generic. Print DRM_NAME in brackets, just like core DRM
logging macros do.

Convert two printk()'s into NV_* logging macro calls.

Signed-off-by: Pekka Paalanen p...@iki.fi
---
 drivers/gpu/drm/nouveau/nouveau_acpi.c  |2 +-
 drivers/gpu/drm/nouveau/nouveau_drv.h   |8 ++--
 drivers/gpu/drm/nouveau/nouveau_fbcon.c |6 --
 3 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_acpi.c 
b/drivers/gpu/drm/nouveau/nouveau_acpi.c
index f71789a..7fb7a9f 100644
--- a/drivers/gpu/drm/nouveau/nouveau_acpi.c
+++ b/drivers/gpu/drm/nouveau/nouveau_acpi.c
@@ -95,7 +95,7 @@ int nouveau_hybrid_setup(struct drm_device *dev)
   result))
return -ENODEV;
 
-   printk(KERN_INFO nouveau: _DSM hardware status gave 0x%x\n, result);
+   NV_INFO(dev, _DSM hardware status gave 0x%x\n, result);
 
if (result  0x1) { /* Stamina mode - disable the external GPU */
nvidia_dsm(pdev, NOUVEAU_DSM_LED, NOUVEAU_DSM_LED_STAMINA,
diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h 
b/drivers/gpu/drm/nouveau/nouveau_drv.h
index 29cf085..a856099 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drv.h
+++ b/drivers/gpu/drm/nouveau/nouveau_drv.h
@@ -1151,9 +1151,13 @@ static inline void nv_wo32(struct drm_device *dev, 
struct nouveau_gpuobj *obj,
nv_wi32(dev, obj-im_pramin-start + index * 4, val);
 }
 
-/* logging */
+/*
+ * Logging
+ * Argument d is (struct drm_device *).
+ */
 #define NV_PRINTK(level, d, fmt, arg...) \
-   printk(level nouveau %s:  fmt, pci_name(d-pdev), ##arg)
+   printk(level [ DRM_NAME ]  DRIVER_NAME  %s:  fmt, \
+   pci_name(d-pdev), ##arg)
 #ifndef NV_DEBUG_NOTRACE
 #define NV_DEBUG(d, fmt, arg...) do {  
\
if (drm_debug) {   \
diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c 
b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
index 3397a88..d6ac9b4 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
@@ -309,8 +309,10 @@ nouveau_fbcon_create(struct drm_device *dev, uint32_t 
fb_width,
info-fbops-fb_fillrect(info, rect);
 
/* To allow resizeing without swapping buffers */
-   printk(allocated %dx%d fb: 0x%lx, bo %p\n, nouveau_fb-base.width,
-  nouveau_fb-base.height, nvbo-bo.offset, nvbo);
+   NV_INFO(dev, allocated %dx%d fb: 0x%lx, bo %p\n,
+   nouveau_fb-base.width,
+   nouveau_fb-base.height,
+   nvbo-bo.offset, nvbo);
 
mutex_unlock(dev-struct_mutex);
return 0;
-- 
1.6.3.3

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH] drm/nouveau: fix WITHIN macro off by one

[Pekka Paalanen]

On Sun, 20 Sep 2009 13:29:24 +0200
Stephane Marchesin marche...@icps.u-strasbg.fr wrote:

 On Fri, Sep 18, 2009 at 20:15, Pekka Paalanen p...@iki.fi wrote:
  Equality in x = y + z is already out of range. X must be
  stricly less.
 
 
 Yeah, I did that back when the SIZE defines were, say, 0x1fff
 instead of 0x2000 so this was required. Seems like the size
 defines changed, but the WITHIN macro wasn't updated.

Thanks for confirming this, I pushed it a while back.

-- 
Pekka Paalanen
http://www.iki.fi/pq/
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [PATCH] drm/nouveau: fix WITHIN macro off by one

[Pekka Paalanen]

Equality in x = y + z is already out of range. X must be stricly less.

Signed-off-by: Pekka Paalanen p...@iki.fi
---
 drivers/gpu/drm/nouveau/nouveau_bios.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_bios.c 
b/drivers/gpu/drm/nouveau/nouveau_bios.c
index 6afd82e..539835a 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bios.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bios.c
@@ -300,7 +300,7 @@ valid_reg(struct nvbios *bios, uint32_t reg)
if (dev_priv-card_type = NV_50)
return 1;
 
-   #define WITHIN(x, y, z) ((x = y)  (x = y + z))
+   #define WITHIN(x, y, z) ((x = y)  (x  y + z))
if (WITHIN(reg, NV_PMC_OFFSET, NV_PMC_SIZE))
return 1;
if (WITHIN(reg, NV_PBUS_OFFSET, NV_PBUS_SIZE))
-- 
1.6.3.3

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [PATCH 1/3] drm/nouveau: change channel regs mapping to ioremap

[Pekka Paalanen]

Use ioremap() for mapping the channel user regs (that are never exposed
to user space) instead of drm_addmap().

This removes the last use cases of drm_addmap/drm_rmmap from Nouveau.

Signed-off-by: Pekka Paalanen p...@iki.fi
---
 drivers/gpu/drm/nouveau/nouveau_channel.c |   13 ++---
 drivers/gpu/drm/nouveau/nouveau_drv.h |9 +++--
 drivers/gpu/drm/nouveau/nv50_display.c|   13 ++---
 3 files changed, 15 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_channel.c 
b/drivers/gpu/drm/nouveau/nouveau_channel.c
index 65810d4..8661b68 100644
--- a/drivers/gpu/drm/nouveau/nouveau_channel.c
+++ b/drivers/gpu/drm/nouveau/nouveau_channel.c
@@ -167,13 +167,12 @@ nouveau_channel_alloc(struct drm_device *dev, struct 
nouveau_channel **chan_ret,
else
user = NV50_USER(channel);
 
-   ret = drm_addmap(dev, drm_get_resource_start(dev, 0) + user,
-PAGE_SIZE, _DRM_REGISTERS, _DRM_DRIVER |
-_DRM_READ_ONLY, chan-user);
-   if (ret) {
-   NV_ERROR(dev, regs %d\n, ret);
+   chan-user = ioremap(pci_resource_start(dev-pdev, 0) + user,
+   PAGE_SIZE);
+   if (!chan-user) {
+   NV_ERROR(dev, ioremap of regs failed.\n);
nouveau_channel_free(chan);
-   return ret;
+   return -ENOMEM;
}
chan-user_put = 0x40;
chan-user_get = 0x44;
@@ -412,7 +411,7 @@ nouveau_channel_free(struct nouveau_channel *chan)
nouveau_notifier_takedown_channel(chan);
 
if (chan-user)
-   drm_rmmap(dev, chan-user);
+   iounmap(chan-user);
 
dev_priv-fifos[chan-id] = NULL;
dev_priv-fifo_alloc_count--;
diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h 
b/drivers/gpu/drm/nouveau/nouveau_drv.h
index 429c109..63cf483 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drv.h
+++ b/drivers/gpu/drm/nouveau/nouveau_drv.h
@@ -169,7 +169,7 @@ struct nouveau_channel {
struct drm_local_map *map;
 
/* mapping of the regs controling the fifo */
-   struct drm_local_map *user;
+   void __iomem *user;
uint32_t user_get;
uint32_t user_put;
 
@@ -1047,11 +1047,8 @@ extern int nouveau_gem_ioctl_info(struct drm_device *, 
void *,
 #endif /* !ioread32_native */
 
 /* channel control reg access */
-#define nvchan_wr32(reg, val) \
-   iowrite32_native((val), \
-   (void __force __iomem *)chan-user-handle + (reg))
-#define nvchan_rd32(reg) \
-   ioread32_native((void __force __iomem *)chan-user-handle + (reg))
+#define nvchan_wr32(reg, val) iowrite32_native((val), chan-user + (reg))
+#define nvchan_rd32(reg) ioread32_native(chan-user + (reg))
 
 /* register access */
 static inline u32 nv_rd32(struct drm_device *dev, unsigned reg)
diff --git a/drivers/gpu/drm/nouveau/nv50_display.c 
b/drivers/gpu/drm/nouveau/nv50_display.c
index 69bfd21..0cf9953 100644
--- a/drivers/gpu/drm/nouveau/nv50_display.c
+++ b/drivers/gpu/drm/nouveau/nv50_display.c
@@ -44,7 +44,7 @@ nv50_evo_channel_del(struct nouveau_channel **pchan)
nouveau_bo_ref(NULL, chan-pushbuf_bo);
 
if (chan-user)
-   drm_rmmap(chan-dev, chan-user);
+   iounmap(chan-user);
 
kfree(chan);
 }
@@ -166,13 +166,12 @@ nv50_evo_channel_new(struct drm_device *dev, struct 
nouveau_channel **pchan)
return ret;
}
 
-   ret = drm_addmap(dev, drm_get_resource_start(dev, 0) +
-NV50_PDISPLAY_USER(0), PAGE_SIZE, _DRM_REGISTERS,
-_DRM_DRIVER | _DRM_READ_ONLY, chan-user);
-   if (ret) {
-   NV_ERROR(dev, Error mapping EVO control regs: %d\n, ret);
+   chan-user = ioremap(pci_resource_start(dev-pdev, 0) +
+   NV50_PDISPLAY_USER(0), PAGE_SIZE);
+   if (!chan-user) {
+   NV_ERROR(dev, Error mapping EVO control regs.\n);
nv50_evo_channel_del(pchan);
-   return ret;
+   return -ENOMEM;
}
 
return 0;
-- 
1.6.3.3

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] Dropping compat from master-compat

[Pekka Paalanen]

On Wed, 9 Sep 2009 20:51:36 +0300
Pekka Paalanen p...@iki.fi wrote:

 Therefore, I will drop compatibility code from master-compat branch,
 and I will add a compile time check for the kernel version. The
 master-compat branch will be just like the master branch, except it
 contains the out-of-tree build scripts. This will force users to
 follow very closely the official RC and release kernels.

It is done. The snapshot is updated.

I did not put any deliberate kernel version checks in place yet.
That may follow later.

$ git diff --stat master..master-compat
 README-nouveau   |   17 +
 nouveau/DEPENDS  |   25 +
 nouveau/Makefile |  100 ++
 3 files changed, 142 insertions(+), 0 deletions(-)

-- 
Pekka Paalanen
http://www.iki.fi/pq/
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] Dropping compat from master-compat

[Pekka Paalanen]

On Wed, 9 Sep 2009 22:02:13 +0200
Andreas Radke a.ra...@arcor.de wrote:

 Am Wed, 9 Sep 2009 20:51:36 +0300
 schrieb Pekka Paalanen p...@iki.fi:
 
  Therefore, I will drop compatibility code from master-compat branch,
  and I will add a compile time check for the kernel version. The
  master-compat branch will be just like the master branch, except it
  contains the out-of-tree build scripts. This will force users to
  follow very closely the official RC and release kernels.
  
  If you want to use the latest Nouveau DRM with an older kernel,
  you get to do the backporting and kernel bug tracking yourself.
  This is the distributions' responsibility in general.
 
 My distribution does not allow any backports to the main packages
 (e.g libdrm and kernel) . We ship almost everything in the latest stable
 released version plain vanilla. If you want us to keep shipping nouveau
 driver please make sure we can always build against the latest stable
 released kernel and libdrm.

But you were already using a backport. What is the difference here?
Because up to now master-compat was just that, a backport.

The kernel bugs I referred to made using Nouveau with 2.6.30.x, x  5
kernels quite dangerous, and 2.6.31 is not out yet. How did you manage
that before 2.6.30.5 came out?

And with libdrm, you were just lucky. There have been times when no
released libdrm contained the required Nouveau code, and no libdrm
releases will be made due to Nouveau until the DRM driver has been
officially released in a Linux kernel. It may still bite you one
day. Nouveau code should not even be a part of libdrm releases yet,
that is why the --enable-nouveau-experimental-api switch exists,
so that libdrm packagers would not need to delete the files while
packaging.

It is not in any way friendly to those who want to distribute
Nouveau, but that can't be helped, really.

 I know there's no released nouveau driver out so far but if you want a
 wide user range make sure it can be build on top of the latest stable
 stuff distributions have in their repos.

That requires a dedicated person for watching kernel bugs. To my
understanding distributions have to do this routinely. Nouveau
developers certainly do not have the time to do that. And it
wasn't really done for master-compat. Other people had to come in
and poke me and say I suck.

It would be nice, if you shipped nouveau, because it means more
testing. But if you are testing with bad kernels, it is not
really that useful.

All that this change of master-compat really means, is that *I*
will not maintain backwards compatibility anymore. I have other
plans. If someone else wants to step up, he or she can. But
developers will always be prejudiced against bug reports
from backported modules, since that is not supported.

Sorry, but I do not see an easy solution. Sometimes I wonder
myself how testing needs distribution which depends on a release
which depends on testing it first. Apparently we just have to
settle with less testing before a release. A universal problem.

-- 
Pekka Paalanen
http://www.iki.fi/pq/
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 4/4] drm/nouveau: fix signedness in nouveau_gpuobj_new()

[Pekka Paalanen]

On Sun,  6 Sep 2009 21:16:03 +0300
Pekka Paalanen p...@iki.fi wrote:

 The size parameter is usually unsigned, but here it was signed. Change
 'int' to 'uint32_t' and propagate the signedness fixes to all callers.
 
 Fixes the sparse warning: nouveau_object.c:254:61: warning: incorrect
 type in argument 3 (different signedness).
 
 Signed-off-by: Pekka Paalanen p...@iki.fi
 ---
  drivers/gpu/drm/nouveau/nouveau_drv.h|4 ++--
  drivers/gpu/drm/nouveau/nouveau_object.c |   14 --
  drivers/gpu/drm/nouveau/nv50_graph.c |6 --
  3 files changed, 14 insertions(+), 10 deletions(-)

This patch series is pushed.

-- 
Pekka Paalanen
http://www.iki.fi/pq/
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH] drm/nouveau: fix ref leak in nouveau_gem_pushbuf_validate()

[Pekka Paalanen]

From ee49e66551a28550b69a1a0fc7f45ec2ab24c295 Mon Sep 17 00:00:00 2001
From: Pekka Paalanen p...@iki.fi
Date: Tue, 8 Sep 2009 00:05:24 +0300
Subject: [PATCH] drm/nouveau: do not call ttm_bo_wait_unreserved()

In nouveau_gem_puhsbuf_validate() path, ttm_bo_reserve() already calls
ttm_bo_wait_unreserved() internally. Calling it again is not only racy
and needless, but it makes the X process hang in uninterruptible sleep.

Remove the call to ttm_bo_wait_unreserved() from
nouveau_gem_pushbuf_validate().

Signed-off-by: Pekka Paalanen p...@iki.fi
---

NOTE!

This is a tentative patch, I didn't even have the time to compile-test it.
On top of the previous.

 drivers/gpu/drm/nouveau/nouveau_gem.c |   17 ++---
 1 files changed, 6 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c 
b/drivers/gpu/drm/nouveau/nouveau_gem.c
index 55e7988..b339de2 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
@@ -286,19 +286,14 @@ nouveau_gem_pushbuf_lookup_and_reserve(struct 
nouveau_channel *chan,
 
ret = ttm_bo_reserve(nvbo-bo, false, false, true,
 chan-fence.sequence);
-   switch (ret) {
-   case 0:
-   *bop = nvbo;
-   return 0;
-   case -EAGAIN:
-   ret = ttm_bo_wait_unreserved(nvbo-bo, false);
-   if (ret == 0)
-   ret = -EAGAIN;
-   /* fall through */
-   default:
+
+   if (ret) {
drm_gem_object_unreference(gem);
+   return ret;
}
-   return ret;
+
+   *bop = nvbo;
+   return 0;
 }
 
 static int
-- 
1.6.3.3

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [PATCH 1/4] drm/nouveau: add reg_debug module parameter

[Pekka Paalanen]

The various register access wrappers in nouveau_hw.h are so noisy when
drm.debug  0, that some of them can overflow the kernel message buffer.

Add nouveau.ko parameter 'reg_debug', a bitmask that enables each of the
wrapper debug messages individually. By default, nothing is printed.

Signed-off-by: Pekka Paalanen p...@iki.fi
---
 drivers/gpu/drm/nouveau/nouveau_drv.c |6 
 drivers/gpu/drm/nouveau/nouveau_drv.h |   20 +++
 drivers/gpu/drm/nouveau/nouveau_hw.h  |   42 +---
 3 files changed, 48 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.c 
b/drivers/gpu/drm/nouveau/nouveau_drv.c
index e9f9abd..d17b16c 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drv.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drv.c
@@ -66,6 +66,12 @@ MODULE_PARM_DESC(tv_norm, Default TV norm.\n
 char *nouveau_tv_norm = NULL;
 module_param_named(tv_norm, nouveau_tv_norm, charp, 0400);
 
+MODULE_PARM_DESC(reg_debug, Reg debug bitmask: 0x1 mc, 0x2 video, 0x4 fb, 0x8 
extdev,\n
+   \t\t0x10 misc regs, 0x20 crtc, 0x40 ramdac, 0x80 vgacrtc,\n
+   \t\t0x100 rmvio, 0x200 vgaattr.\n);
+int nouveau_reg_debug;
+module_param_named(reg_debug, nouveau_reg_debug, int, 0600);
+
 int nouveau_fbpercrtc = 0;
 #if 0
 module_param_named(fbpercrtc, nouveau_fbpercrtc, int, 0400);
diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h 
b/drivers/gpu/drm/nouveau/nouveau_drv.h
index 4a1efa1..aed773e 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drv.h
+++ b/drivers/gpu/drm/nouveau/nouveau_drv.h
@@ -620,6 +620,7 @@ extern int nouveau_uscript_tmds;
 extern int nouveau_vram_pushbuf;
 extern int nouveau_fbpercrtc;
 extern char *nouveau_tv_norm;
+extern int nouveau_reg_debug;
 
 /* nouveau_state.c */
 extern void nouveau_preclose(struct drm_device *dev, struct drm_file *);
@@ -,6 +1112,25 @@ static inline void nv_wo32(struct drm_device *dev, 
struct nouveau_gpuobj *obj,
 #define NV_TRACE(d, fmt, arg...) NV_PRINTK(KERN_INFO, d, fmt, ##arg)
 #define NV_WARN(d, fmt, arg...) NV_PRINTK(KERN_WARNING, d, fmt, ##arg)
 
+/* nouveau_reg_debug bitmask */
+enum {
+   NOUVEAU_REG_DEBUG_MC = 0x1,
+   NOUVEAU_REG_DEBUG_VIDEO  = 0x2,
+   NOUVEAU_REG_DEBUG_FB = 0x4,
+   NOUVEAU_REG_DEBUG_EXTDEV = 0x8,
+   NOUVEAU_REG_DEBUG_REG= 0x10,
+   NOUVEAU_REG_DEBUG_CRTC   = 0x20,
+   NOUVEAU_REG_DEBUG_RAMDAC = 0x40,
+   NOUVEAU_REG_DEBUG_VGACRTC= 0x80,
+   NOUVEAU_REG_DEBUG_RMVIO  = 0x100,
+   NOUVEAU_REG_DEBUG_VGAATTR= 0x200,
+};
+
+#define NV_REG_DEBUG(type, dev, fmt, arg...) do { \
+   if (nouveau_reg_debug  NOUVEAU_REG_DEBUG_##type) \
+   NV_PRINTK(KERN_DEBUG, dev, %s:  fmt, __func__, ##arg); \
+} while (0)
+
 static inline enum nouveau_card_type
 nv_arch(struct drm_device *dev)
 {
diff --git a/drivers/gpu/drm/nouveau/nouveau_hw.h 
b/drivers/gpu/drm/nouveau/nouveau_hw.h
index 129345e..a1880c4 100644
--- a/drivers/gpu/drm/nouveau/nouveau_hw.h
+++ b/drivers/gpu/drm/nouveau/nouveau_hw.h
@@ -59,14 +59,14 @@ static inline uint32_t
 nvReadMC(struct drm_device *dev, uint32_t reg)
 {
uint32_t val = nv_rd32(dev, reg);
-   NV_DEBUG(dev, nvReadMC: reg %08x val %08x\n, reg, val);
+   NV_REG_DEBUG(MC, dev, reg %08x val %08x\n, reg, val);
return val;
 }
 
 static inline void
 nvWriteMC(struct drm_device *dev, uint32_t reg, uint32_t val)
 {
-   NV_DEBUG(dev, nvWriteMC: reg %08x val %08x\n, reg, val);
+   NV_REG_DEBUG(MC, dev, reg %08x val %08x\n, reg, val);
nv_wr32(dev, reg, val);
 }
 
@@ -74,14 +74,14 @@ static inline uint32_t
 nvReadVIDEO(struct drm_device *dev, uint32_t reg)
 {
uint32_t val = nv_rd32(dev, reg);
-   NV_DEBUG(dev, nvReadVIDEO: reg %08x val %08x\n, reg, val);
+   NV_REG_DEBUG(VIDEO, dev, reg %08x val %08x\n, reg, val);
return val;
 }
 
 static inline void
 nvWriteVIDEO(struct drm_device *dev, uint32_t reg, uint32_t val)
 {
-   NV_DEBUG(dev, nvWriteVIDEO: reg %08x val %08x\n, reg, val);
+   NV_REG_DEBUG(VIDEO, dev, reg %08x val %08x\n, reg, val);
nv_wr32(dev, reg, val);
 }
 
@@ -89,14 +89,14 @@ static inline uint32_t
 nvReadFB(struct drm_device *dev, uint32_t reg)
 {
uint32_t val = nv_rd32(dev, reg);
-   NV_DEBUG(dev, nvReadFB: reg %08x val %08x\n, reg, val);
+   NV_REG_DEBUG(FB, dev, reg %08x val %08x\n, reg, val);
return val;
 }
 
 static inline void
 nvWriteFB(struct drm_device *dev, uint32_t reg, uint32_t val)
 {
-   NV_DEBUG(dev, nvWriteFB: reg %08x val %08x\n, reg, val);
+   NV_REG_DEBUG(FB, dev, reg %08x val %08x\n, reg, val);
nv_wr32(dev, reg, val);
 }
 
@@ -104,27 +104,27 @@ static inline uint32_t
 nvReadEXTDEV(struct drm_device *dev, uint32_t reg)
 {
uint32_t val = nv_rd32(dev, reg);
-   NV_DEBUG(dev, nvReadEXTDEV: reg %08x val %08x\n, reg, val);
+   NV_REG_DEBUG(EXTDEV, dev, reg %08x val %08x\n, reg

[Nouveau] [PATCH 3/4] drm/nouveau: remove NVRead and NVWrite

[Pekka Paalanen]

These functions were effectively nv_rd32 and nv_wr32 with a debug print,
and they were never used. Remove them.

Signed-off-by: Pekka Paalanen p...@iki.fi
---
 drivers/gpu/drm/nouveau/nouveau_drv.c |7 ---
 drivers/gpu/drm/nouveau/nouveau_drv.h |   11 +--
 drivers/gpu/drm/nouveau/nouveau_hw.h  |   13 -
 3 files changed, 9 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.c 
b/drivers/gpu/drm/nouveau/nouveau_drv.c
index d17b16c..684c296 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drv.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drv.c
@@ -66,9 +66,10 @@ MODULE_PARM_DESC(tv_norm, Default TV norm.\n
 char *nouveau_tv_norm = NULL;
 module_param_named(tv_norm, nouveau_tv_norm, charp, 0400);
 
-MODULE_PARM_DESC(reg_debug, Reg debug bitmask: 0x1 mc, 0x2 video, 0x4 fb, 0x8 
extdev,\n
-   \t\t0x10 misc regs, 0x20 crtc, 0x40 ramdac, 0x80 vgacrtc,\n
-   \t\t0x100 rmvio, 0x200 vgaattr.\n);
+MODULE_PARM_DESC(reg_debug, Register access debug bitmask:\n
+   \t\t0x1 mc, 0x2 video, 0x4 fb, 0x8 extdev,\n
+   \t\t0x10 crtc, 0x20 ramdac, 0x40 vgacrtc, 0x80 rmvio,\n
+   \t\t0x100 vgaattr. );
 int nouveau_reg_debug;
 module_param_named(reg_debug, nouveau_reg_debug, int, 0600);
 
diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h 
b/drivers/gpu/drm/nouveau/nouveau_drv.h
index aed773e..b717c1c 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drv.h
+++ b/drivers/gpu/drm/nouveau/nouveau_drv.h
@@ -1118,12 +1118,11 @@ enum {
NOUVEAU_REG_DEBUG_VIDEO  = 0x2,
NOUVEAU_REG_DEBUG_FB = 0x4,
NOUVEAU_REG_DEBUG_EXTDEV = 0x8,
-   NOUVEAU_REG_DEBUG_REG= 0x10,
-   NOUVEAU_REG_DEBUG_CRTC   = 0x20,
-   NOUVEAU_REG_DEBUG_RAMDAC = 0x40,
-   NOUVEAU_REG_DEBUG_VGACRTC= 0x80,
-   NOUVEAU_REG_DEBUG_RMVIO  = 0x100,
-   NOUVEAU_REG_DEBUG_VGAATTR= 0x200,
+   NOUVEAU_REG_DEBUG_CRTC   = 0x10,
+   NOUVEAU_REG_DEBUG_RAMDAC = 0x20,
+   NOUVEAU_REG_DEBUG_VGACRTC= 0x40,
+   NOUVEAU_REG_DEBUG_RMVIO  = 0x80,
+   NOUVEAU_REG_DEBUG_VGAATTR= 0x100,
 };
 
 #define NV_REG_DEBUG(type, dev, fmt, arg...) do { \
diff --git a/drivers/gpu/drm/nouveau/nouveau_hw.h 
b/drivers/gpu/drm/nouveau/nouveau_hw.h
index a27e0d0..d24fad0 100644
--- a/drivers/gpu/drm/nouveau/nouveau_hw.h
+++ b/drivers/gpu/drm/nouveau/nouveau_hw.h
@@ -115,19 +115,6 @@ nvWriteEXTDEV(struct drm_device *dev, uint32_t reg, 
uint32_t val)
nv_wr32(dev, reg, val);
 }
 
-static inline uint32_t NVRead(struct drm_device *dev, uint32_t reg)
-{
-   uint32_t val = nv_rd32(dev, reg);
-   NV_REG_DEBUG(REG, dev, reg %08x val %08x\n, reg, val);
-   return val;
-}
-
-static inline void NVWrite(struct drm_device *dev, uint32_t reg, uint32_t val)
-{
-   NV_REG_DEBUG(REG, dev, reg %08x val %08x\n, reg, val);
-   nv_wr32(dev, reg, val);
-}
-
 static inline uint32_t NVReadCRTC(struct drm_device *dev,
int head, uint32_t reg)
 {
-- 
1.6.3.3

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [PATCH 4/4] drm/nouveau: fix signedness in nouveau_gpuobj_new()

[Pekka Paalanen]

The size parameter is usually unsigned, but here it was signed. Change
'int' to 'uint32_t' and propagate the signedness fixes to all callers.

Fixes the sparse warning: nouveau_object.c:254:61: warning: incorrect
type in argument 3 (different signedness).

Signed-off-by: Pekka Paalanen p...@iki.fi
---
 drivers/gpu/drm/nouveau/nouveau_drv.h|4 ++--
 drivers/gpu/drm/nouveau/nouveau_object.c |   14 --
 drivers/gpu/drm/nouveau/nv50_graph.c |6 --
 3 files changed, 14 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h 
b/drivers/gpu/drm/nouveau/nouveau_drv.h
index b717c1c..1581935 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drv.h
+++ b/drivers/gpu/drm/nouveau/nouveau_drv.h
@@ -698,7 +698,7 @@ extern int nouveau_gpuobj_channel_init(struct 
nouveau_channel *,
   uint32_t vram_h, uint32_t tt_h);
 extern void nouveau_gpuobj_channel_takedown(struct nouveau_channel *);
 extern int nouveau_gpuobj_new(struct drm_device *, struct nouveau_channel *,
- int size, int align, uint32_t flags,
+ uint32_t size, int align, uint32_t flags,
  struct nouveau_gpuobj **);
 extern int nouveau_gpuobj_del(struct drm_device *, struct nouveau_gpuobj **);
 extern int nouveau_gpuobj_ref_add(struct drm_device *, struct nouveau_channel 
*,
@@ -711,7 +711,7 @@ extern int nouveau_gpuobj_ref_find(struct nouveau_channel 
*, uint32_t handle,
 extern int nouveau_gpuobj_new_ref(struct drm_device *,
  struct nouveau_channel *alloc_chan,
  struct nouveau_channel *ref_chan,
- uint32_t handle, int size, int align,
+ uint32_t handle, uint32_t size, int align,
  uint32_t flags, struct nouveau_gpuobj_ref **);
 extern int nouveau_gpuobj_new_fake(struct drm_device *,
   uint32_t p_offset, uint32_t b_offset,
diff --git a/drivers/gpu/drm/nouveau/nouveau_object.c 
b/drivers/gpu/drm/nouveau/nouveau_object.c
index efcce79..66ab939 100644
--- a/drivers/gpu/drm/nouveau/nouveau_object.c
+++ b/drivers/gpu/drm/nouveau/nouveau_object.c
@@ -203,7 +203,7 @@ nouveau_ramht_remove(struct drm_device *dev, struct 
nouveau_gpuobj_ref *ref)
 
 int
 nouveau_gpuobj_new(struct drm_device *dev, struct nouveau_channel *chan,
-  int size, int align, uint32_t flags,
+  uint32_t size, int align, uint32_t flags,
   struct nouveau_gpuobj **gpuobj_ret)
 {
struct drm_nouveau_private *dev_priv = dev-dev_private;
@@ -212,7 +212,7 @@ nouveau_gpuobj_new(struct drm_device *dev, struct 
nouveau_channel *chan,
struct mem_block *pramin = NULL;
int ret;
 
-   NV_DEBUG(dev, ch%d size=%d align=%d flags=0x%08x\n,
+   NV_DEBUG(dev, ch%d size=%u align=%d flags=0x%08x\n,
 chan ? chan-id : -1, size, align, flags);
 
if (!dev_priv || !gpuobj_ret || *gpuobj_ret != NULL)
@@ -520,8 +520,8 @@ int nouveau_gpuobj_ref_del(struct drm_device *dev, struct 
nouveau_gpuobj_ref **p
 int
 nouveau_gpuobj_new_ref(struct drm_device *dev,
   struct nouveau_channel *oc, struct nouveau_channel *rc,
-  uint32_t handle, int size, int align, uint32_t flags,
-  struct nouveau_gpuobj_ref **ref)
+  uint32_t handle, uint32_t size, int align,
+  uint32_t flags, struct nouveau_gpuobj_ref **ref)
 {
struct nouveau_gpuobj *gpuobj = NULL;
int ret;
@@ -616,7 +616,7 @@ nouveau_gpuobj_new_fake(struct drm_device *dev, uint32_t 
p_offset,
 }
 
 
-static int
+static uint32_t
 nouveau_gpuobj_class_instmem_size(struct drm_device *dev, int class)
 {
struct drm_nouveau_private *dev_priv = dev-dev_private;
@@ -899,7 +899,9 @@ nouveau_gpuobj_channel_init_pramin(struct nouveau_channel 
*chan)
struct drm_device *dev = chan-dev;
struct drm_nouveau_private *dev_priv = dev-dev_private;
struct nouveau_gpuobj *pramin = NULL;
-   int size, base, ret;
+   uint32_t size;
+   uint32_t base;
+   int ret;
 
NV_DEBUG(dev, ch%d\n, chan-id);
 
diff --git a/drivers/gpu/drm/nouveau/nv50_graph.c 
b/drivers/gpu/drm/nouveau/nv50_graph.c
index 72db3cf..108f672 100644
--- a/drivers/gpu/drm/nouveau/nv50_graph.c
+++ b/drivers/gpu/drm/nouveau/nv50_graph.c
@@ -182,8 +182,10 @@ nv50_graph_create_context(struct nouveau_channel *chan)
struct nouveau_gpuobj *ramin = chan-ramin-gpuobj;
struct nouveau_gpuobj *ctx;
uint32_t *ctxvals = NULL;
-   int grctx_size = 0x7, hdr;
-   int ret, pos;
+   uint32_t grctx_size = 0x7;
+   int hdr;
+   int ret;
+   int pos;
 
NV_DEBUG(dev, ch%d\n, chan-id);
 
-- 
1.6.3.3

___
Nouveau mailing list
Nouveau

Re: [Nouveau] [PATCH] drm/nouveau: init some list_heads

[Pekka Paalanen]

On Wed, 26 Aug 2009 23:53:36 +0200
Maarten Maathuis madman2...@gmail.com wrote:

 - In the case of nvbo-head it is really important to avoid an OOPS if 
 ttm_buffer_object_init fails.
 
 Signed-off-by: Maarten Maathuis madman2...@gmail.com

Aren't you going to push this?
I still haven't really reviewed this, but go ahead.

 ---
  drivers/gpu/drm/nouveau/nouveau_bo.c  |2 ++
  drivers/gpu/drm/nouveau/nouveau_channel.c |1 +
  drivers/gpu/drm/nouveau/nouveau_object.c  |1 +
  3 files changed, 4 insertions(+), 0 deletions(-)
 
 diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
 b/drivers/gpu/drm/nouveau/nouveau_bo.c
 index 24d6f8f..6b8ef6b 100644
 --- a/drivers/gpu/drm/nouveau/nouveau_bo.c
 +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
 @@ -63,6 +63,8 @@ nouveau_bo_new(struct drm_device *dev, struct 
 nouveau_channel *chan,
   nvbo = kzalloc(sizeof(struct nouveau_bo), GFP_KERNEL);
   if (!nvbo)
   return -ENOMEM;
 + INIT_LIST_HEAD(nvbo-head);
 + INIT_LIST_HEAD(nvbo-entry);
   nvbo-mappable = mappable;
   nvbo-no_vm = no_vm;
   nvbo-tile_mode = tile_mode;
 diff --git a/drivers/gpu/drm/nouveau/nouveau_channel.c 
 b/drivers/gpu/drm/nouveau/nouveau_channel.c
 index 382c5b5..6c31d7f 100644
 --- a/drivers/gpu/drm/nouveau/nouveau_channel.c
 +++ b/drivers/gpu/drm/nouveau/nouveau_channel.c
 @@ -138,6 +138,7 @@ nouveau_channel_alloc(struct drm_device *dev, struct 
 nouveau_channel **chan_ret,
   return -ENOMEM;
   dev_priv-fifo_alloc_count++;
   chan = dev_priv-fifos[channel];
 + INIT_LIST_HEAD(chan-nvsw.vbl_wait);
   chan-dev = dev;
   chan-id = channel;
   chan-file_priv = file_priv;
 diff --git a/drivers/gpu/drm/nouveau/nouveau_object.c 
 b/drivers/gpu/drm/nouveau/nouveau_object.c
 index 65d8d25..efcce79 100644
 --- a/drivers/gpu/drm/nouveau/nouveau_object.c
 +++ b/drivers/gpu/drm/nouveau/nouveau_object.c
 @@ -468,6 +468,7 @@ nouveau_gpuobj_ref_add(struct drm_device *dev, struct 
 nouveau_channel *chan,
   ref = kzalloc(sizeof(*ref), GFP_KERNEL);
   if (!ref)
   return -ENOMEM;
 + INIT_LIST_HEAD(ref-list);
   ref-gpuobj   = gpuobj;
   ref-channel  = chan;
   ref-instance = instance;
 -- 
 1.6.4
 
 ___
 Nouveau mailing list
 Nouveau@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/nouveau
 


-- 
Pekka Paalanen
http://www.iki.fi/pq/
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] Debugging help needed

[Pekka Paalanen]

On Sat, 29 Aug 2009 16:08:13 +0200
Anders Eriksson aeriks...@fastmail.fm wrote:

 I once had nouveau working and stable back whem 2.6.29 was released.

That would be before we used a real memory manger, IIRC.

 Nowadays, it hangs within less tahn an hours work. The symptom is that 
 the mouse moves, but no other updates to the screen. The machine is
 otherwise working mostly ok so I can ssh to it. The issue I have is 
 that there is nothing interesting (afaict) in any log. Nothing in 
 Xog.0.log, nothing in dmesg.
 
 The one intersting thing I've noticed is that with drm debuging on I get 
 a ton of these on dmesg:
 
 host [drm:drm_ioctl], pid=2391, cmd=0x40086485, nr=0x85, dev 0xe200, auth=1

0x85 = DRM_COMMAND_BASE + 0x45, so this is DRM_NOUVEAU_GEM_CPU_PREP
(include/drm/nouveau_drm.h), i.e. nouveau_gem_ioctl_cpu_prep() in
drivers/gpu/drm/nouveau/nouveau_gem.c.

 And at, or around the hang, there seem to be a an increase of:
 
 host [drm:drm_ioctl], ret = fff5

Okay, so it is spinning there for some reason, returning -11,
i.e. -EAGAIN. Assuming this is the return of the prep call.

That's all I can tell for now. Full kernel logs might help, you
could open a bug report with that.

-- 
Pekka Paalanen
http://www.iki.fi/pq/
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCHv2 2/2] drm/nouveau: Make the tv_norm parameter description more useful.

[Pekka Paalanen]

On Tue, 25 Aug 2009 15:41:27 +0200
Francisco Jerez curroje...@riseup.net wrote:

 
 Signed-off-by: Francisco Jerez curroje...@riseup.net
 ---
  drivers/gpu/drm/nouveau/nouveau_drv.c |6 +-
  1 files changed, 5 insertions(+), 1 deletions(-)

Both pushed, thanks.

-- 
Pekka Paalanen
http://www.iki.fi/pq/
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH] drm/i2c/ch7006: Fix the scale parameter handling.

[Pekka Paalanen]

On Tue, 25 Aug 2009 16:23:43 +0200
Francisco Jerez curroje...@riseup.net wrote:

 
 Signed-off-by: Francisco Jerez curroje...@riseup.net
 ---
  drivers/gpu/drm/i2c/ch7006_drv.c |   14 ++
  1 files changed, 6 insertions(+), 8 deletions(-)

Pushed, thanks.

-- 
Pekka Paalanen
http://www.iki.fi/pq/
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH] drm/nouveau: rewrite nouveau_dma_wait()

[Pekka Paalanen]

 to the beginning of the push buffer,
 +  * we'll hit the fetching-ahead-of-us path from that
 +  * point on.
 +  *
 +  * the *one* exception to that rule is if we read
 +  * GET==PUT, in which case the below conditional will
 +  * always succeed and break us out of the wait loop.
 +  */
 + chan-dma.free = chan-dma.max - chan-dma.cur;
 + if (chan-dma.free = size)
 + break;

If dma.free == size, doesn't the jump command emitted on the next call
here get written past the end of the buffer? dma.cur will equal dma.max.

 +
 + /* not enough space left at the end of the push buffer,
 +  * instruct the GPU to jump back to the start right
 +  * after processing the currently pending commands.
 +  */
 + OUT_RING  (chan, chan-pushbuf_base | 0x2000);
 + WRITE_PUT (NOUVEAU_DMA_SKIPS);
 +
 + /* we're now submitting commands at the start of
 +  * the push buffer.
 +  */
 + chan-dma.cur  =
 + chan-dma.put  = NOUVEAU_DMA_SKIPS;
   }
  
 - DRM_UDELAY(1);
 + /* engine fetching ahead of us, we have space up until the
 +  * current GET pointer.  the - 1 is to ensure there's
 +  * space left to emit a jump back to the beginning of the
 +  * push buffer if we require it.  we can never get GET == PUT
 +  * here, so this is safe.
 +  */
 + chan-dma.free = get - chan-dma.cur - 1;
   }
  
 - return ret;
 + return 0;
  }
 +
 -- 
 1.6.4


-- 
Pekka Paalanen
http://www.iki.fi/pq/
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH] drm/nouveau: rewrite nouveau_dma_wait()

[Pekka Paalanen]

On Sat, 22 Aug 2009 12:30:03 +0200
Maarten Maathuis madman2...@gmail.com wrote:

 dma.max is adjusted to always have space for the jump.

Ah, then that should be documented somewhere.

But if that is the case, why:
 chan-dma.free = get - chan-dma.cur - 1;

The extra space is not needed in this branch, since the available space
is limited by GET. If it is not locked up, GET will move forward and give
space. Otherwise, we would be in the get = dma.cur branch.

Assuming the jump command is at index dma.max, isn't dma.max the maximum
possible value for GET inside the ring? Therefore
 chan-dma.free = get - chan-dma.cur - 1;
should become equivalent to
 chan-dma.free = chan-dma.max - chan-dma.cur;
but there is the -1.

Or do we observe GET == dma.max + 1 just before it actually jumps?

Or do we simply not know how it behaves and want to be safe?

-- 
Pekka Paalanen
http://www.iki.fi/pq/
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] Delays in DRM nouveau_bios.c

[Pekka Paalanen]

Hi,

questions will follow.

---

diff --git a/drivers/gpu/drm/nouveau/nouveau_bios.c 
b/drivers/gpu/drm/nouveau/nouveau_bios.c
index 99f7bd4..13b3fb1 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bios.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bios.c
@@ -40,8 +40,6 @@
 #define BIOSLOG(sip, fmt, arg...) NV_DEBUG(sip-dev, fmt, ##arg)
 #define LOG_OLD_VALUE(x) //x
 
-#define BIOS_USLEEP(n) mdelay((n)/1000)
-
 #define ROM16(x) le16_to_cpu(*(uint16_t *)(x))
 #define ROM32(x) le32_to_cpu(*(uint32_t *)(x))
 
@@ -50,6 +48,15 @@ struct init_exec {
bool repeat;
 };
 
+static inline void bios_usleep(unsigned usecs)
+{
+   might_sleep();
+   if (usecs  1000 * MAX_UDELAY_MS)
+   udelay(usecs);
+   else
+   msleep(usecs / 1000 + 1);
+}
+
 static bool nv_cksum(const uint8_t *data, unsigned int length)
 {
/* there's a few checksums in the BIOS, so here's a generic checking 
function */
@@ -262,7 +269,7 @@ static int parse_init_table(struct nvbios *, unsigned int, 
struct init_exec *);
 static void still_alive(void)
 {
 // sync();
-// BIOS_USLEEP(2000);
+// bios_usleep(2000);
 }
 
 static uint32_t
@@ -1608,17 +1615,18 @@ init_condition_time(struct nvbios *bios, uint16_t 
offset,
 
for (; retries  0; retries--)
if (bios_condition_met(bios, offset, cond)) {
-   BIOSLOG(bios, 0x%04X: Condition met, continuing\n, 
offset);
+   BIOSLOG(bios, 0x%04X: Condition met, continuing\n,
+   offset);
break;
} else {
BIOSLOG(bios, 0x%04X: Condition not met, sleeping for 
20ms\n, offset);
-   BIOS_USLEEP(2);
+   bios_usleep(2);
}
 
if (!bios_condition_met(bios, offset, cond)) {
NV_WARN(bios-dev,
0x%04X: Condition still not met after %dms, 
-   skiping following opcodes\n, offset, 20 * retries);
+   skipping following opcodes\n, offset, 20 * retries);
iexec-execute = false;
}
 
@@ -1851,7 +1859,7 @@ init_reset(struct nvbios *bios, uint16_t offset, struct 
init_exec *iexec)
bios_wr32(bios, NV_PBUS_PCI_NV_19, 0);
bios_wr32(bios, reg, value1);
 
-   BIOS_USLEEP(10);
+   bios_usleep(10);
 
bios_wr32(bios, reg, value2);
bios_wr32(bios, NV_PBUS_PCI_NV_19, pci_nv_19);
@@ -2233,8 +2241,7 @@ init_time(struct nvbios *bios, uint16_t offset, struct 
init_exec *iexec)
BIOSLOG(bios, 0x%04X: Sleeping for 0x%04X microseconds\n,
offset, time);
 
-   BIOS_USLEEP(time);
-
+   bios_usleep(time);
return true;
 }
 
@@ -2872,9 +2879,11 @@ static int call_lvds_manufacturer_script(struct 
drm_device *dev, struct dcb_entr
 
run_digital_op_script(dev, scriptofs, dcbent, head, bios-fp.dual_link);
 
-   if (script == LVDS_PANEL_OFF)
+   if (script == LVDS_PANEL_OFF) {
/* off-on delay in ms */
-   BIOS_USLEEP(ROM16(bios-data[bios-fp.xlated_entry + 7]));
+   bios_usleep(ROM16(bios-data[bios-fp.xlated_entry + 7]));
+   }
+
 #ifdef __powerpc__
/* Powerbook specific quirks */
if (script == LVDS_RESET  ((dev-pci_device  0x) == 0x0179 || 
(dev-pci_device  0x) == 0x0329))

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [PATCH 1/4] drm/nouveau: refactor nouveau_dma_wait()

[Pekka Paalanen]

A cleanup of nouveau_dma_wait(): extract a sub-function and eliminate
two variables to improve readability.

No functional changes.

Signed-off-by: Pekka Paalanen p...@iki.fi
---
 drivers/gpu/drm/nouveau/nouveau_dma.c |   72 ++---
 1 files changed, 39 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_dma.c 
b/drivers/gpu/drm/nouveau/nouveau_dma.c
index b1f3a71..b787651 100644
--- a/drivers/gpu/drm/nouveau/nouveau_dma.c
+++ b/drivers/gpu/drm/nouveau/nouveau_dma.c
@@ -115,14 +115,43 @@ READ_GET(struct nouveau_channel *chan, uint32_t *get)
return true;
 }
 
+static int
+dma_wait_ring_wrap(struct nouveau_channel *chan, int size, uint32_t get,
+  int *timeout)
+{
+   /* Emit jump to the start of the ring buffer. */
+   OUT_RING(chan, 0x2000 | chan-pushbuf_base);
+
+   if (get = NOUVEAU_DMA_SKIPS) {
+   /* corner case - will be idle */
+   if (chan-dma.put = NOUVEAU_DMA_SKIPS)
+   WRITE_PUT(NOUVEAU_DMA_SKIPS + 1);
+
+   for (; *timeout; (*timeout)--) {
+   if (READ_GET(chan, get)  get  NOUVEAU_DMA_SKIPS)
+   break;
+
+   DRM_UDELAY(1);
+   }
+
+   if (*timeout == 0)
+   return -EBUSY;
+   }
+
+   WRITE_PUT(NOUVEAU_DMA_SKIPS);
+   chan-dma.cur  = NOUVEAU_DMA_SKIPS;
+   chan-dma.put  = NOUVEAU_DMA_SKIPS;
+   chan-dma.free = get - (NOUVEAU_DMA_SKIPS + 1);
+   return 0;
+}
+
 int
 nouveau_dma_wait(struct nouveau_channel *chan, int size)
 {
-   const int us_timeout = 10;
+   int us_timeout = 10;
uint32_t get;
-   int ret = -EBUSY, i;
 
-   for (i = 0; i  us_timeout; i++) {
+   for (; us_timeout; us_timeout--) {
if (!READ_GET(chan, get)) {
DRM_UDELAY(1);
continue;
@@ -131,41 +160,18 @@ nouveau_dma_wait(struct nouveau_channel *chan, int size)
if (chan-dma.put = get) {
chan-dma.free = chan-dma.max - chan-dma.cur;
 
-   if (chan-dma.free  size) {
-   OUT_RING(chan, 0x2000|chan-pushbuf_base);
-   if (get = NOUVEAU_DMA_SKIPS) {
-   /*corner case - will be idle*/
-   if (chan-dma.put = NOUVEAU_DMA_SKIPS)
-   WRITE_PUT(NOUVEAU_DMA_SKIPS + 
1);
-
-   for (; i  us_timeout; i++) {
-   if (READ_GET(chan, get) 
-   get  NOUVEAU_DMA_SKIPS)
-   break;
-
-   DRM_UDELAY(1);
-   }
-
-   if (i = us_timeout)
-   break;
-   }
-
-   WRITE_PUT(NOUVEAU_DMA_SKIPS);
-   chan-dma.cur  =
-   chan-dma.put  = NOUVEAU_DMA_SKIPS;
-   chan-dma.free = get - (NOUVEAU_DMA_SKIPS + 1);
-   }
+   if (chan-dma.free  size)
+   if (dma_wait_ring_wrap(chan, size, get,
+   us_timeout))
+   return -EBUSY;
} else {
chan-dma.free = get - chan-dma.cur - 1;
}
 
-   if (chan-dma.free = size) {
-   ret = 0;
-   break;
-   }
+   if (chan-dma.free = size)
+   return 0;
 
DRM_UDELAY(1);
}
-
-   return ret;
+   return -EBUSY;
 }
-- 
1.6.3.3

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [PATCH 2/4] drm/nouveau: make WRITE_PUT a function

[Pekka Paalanen]

Make WRITE_PUT() an inline function, and pass chan as an argument.
Update chan-dma.put in WRITE_PUT() instead of (almost) everywhere by
hand afterwards.

Signed-off-by: Pekka Paalanen p...@iki.fi
---
 drivers/gpu/drm/nouveau/nouveau_dma.c |5 ++---
 drivers/gpu/drm/nouveau/nouveau_dma.h |   16 +---
 2 files changed, 11 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_dma.c 
b/drivers/gpu/drm/nouveau/nouveau_dma.c
index b787651..28e9c11 100644
--- a/drivers/gpu/drm/nouveau/nouveau_dma.c
+++ b/drivers/gpu/drm/nouveau/nouveau_dma.c
@@ -125,7 +125,7 @@ dma_wait_ring_wrap(struct nouveau_channel *chan, int size, 
uint32_t get,
if (get = NOUVEAU_DMA_SKIPS) {
/* corner case - will be idle */
if (chan-dma.put = NOUVEAU_DMA_SKIPS)
-   WRITE_PUT(NOUVEAU_DMA_SKIPS + 1);
+   WRITE_PUT(chan, NOUVEAU_DMA_SKIPS + 1);
 
for (; *timeout; (*timeout)--) {
if (READ_GET(chan, get)  get  NOUVEAU_DMA_SKIPS)
@@ -138,9 +138,8 @@ dma_wait_ring_wrap(struct nouveau_channel *chan, int size, 
uint32_t get,
return -EBUSY;
}
 
-   WRITE_PUT(NOUVEAU_DMA_SKIPS);
+   WRITE_PUT(chan, NOUVEAU_DMA_SKIPS);
chan-dma.cur  = NOUVEAU_DMA_SKIPS;
-   chan-dma.put  = NOUVEAU_DMA_SKIPS;
chan-dma.free = get - (NOUVEAU_DMA_SKIPS + 1);
return 0;
 }
diff --git a/drivers/gpu/drm/nouveau/nouveau_dma.h 
b/drivers/gpu/drm/nouveau/nouveau_dma.h
index cdaa37d..74db74e 100644
--- a/drivers/gpu/drm/nouveau/nouveau_dma.h
+++ b/drivers/gpu/drm/nouveau/nouveau_dma.h
@@ -118,11 +118,14 @@ BEGIN_RING(struct nouveau_channel *chan, int subc, int 
mthd, int size)
OUT_RING(chan, (subc  13) | (size  18) | mthd);
 }
 
-#define WRITE_PUT(val) do {
\
-   DRM_MEMORYBARRIER();   \
-   nouveau_bo_rd32(chan-pushbuf_bo, 0);  \
-   nvchan_wr32(chan-user_put, ((val)  2) + chan-pushbuf_base);\
-} while (0)
+static inline void
+WRITE_PUT(struct nouveau_channel *chan, uint32_t index)
+{
+   DRM_MEMORYBARRIER();
+   nouveau_bo_rd32(chan-pushbuf_bo, 0);
+   nvchan_wr32(chan-user_put, index * 4 + chan-pushbuf_base);
+   chan-dma.put = index;
+}
 
 static inline void
 FIRE_RING(struct nouveau_channel *chan)
@@ -135,8 +138,7 @@ FIRE_RING(struct nouveau_channel *chan)
return;
chan-accel_done = true;
 
-   WRITE_PUT(chan-dma.cur);
-   chan-dma.put = chan-dma.cur;
+   WRITE_PUT(chan, chan-dma.cur);
 }
 
 static inline void
-- 
1.6.3.3

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [PATCH 2/2] drm/nouveau: fix bo access after CALL implementation

[Pekka Paalanen]

TTM buffer object's virtual cookie may be an iomem cookie or a kernel
virtual address. These need to be handled separately.

Signed-off-by: Pekka Paalanen p...@iki.fi
---
 drivers/gpu/drm/nouveau/nouveau_gem.c |   21 ++---
 1 files changed, 14 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c 
b/drivers/gpu/drm/nouveau/nouveau_gem.c
index 75cae79..6b150fc 100644
--- a/drivers/gpu/drm/nouveau/nouveau_gem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_gem.c
@@ -408,7 +408,7 @@ nouveau_gem_pushbuf_reloc_apply(struct nouveau_channel 
*chan, int nr_bo,
struct drm_nouveau_gem_pushbuf_bo *bo,
int nr_relocs, uint64_t ptr_relocs,
int nr_dwords, int first_dword,
-   uint32_t *pushbuf)
+   uint32_t *pushbuf, bool is_iomem)
 {
struct drm_nouveau_gem_pushbuf_reloc *reloc = NULL;
struct drm_device *dev = chan-dev;
@@ -451,7 +451,11 @@ nouveau_gem_pushbuf_reloc_apply(struct nouveau_channel 
*chan, int nr_bo,
data |= r-vor;
}
 
-   pushbuf[r-reloc_index] = data;
+   if (is_iomem)
+   iowrite32_native(data, (void __force __iomem *)
+   pushbuf[r-reloc_index]);
+   else
+   pushbuf[r-reloc_index] = data;
}
 
kfree(reloc);
@@ -516,7 +520,7 @@ nouveau_gem_ioctl_pushbuf(struct drm_device *dev, void 
*data,
  bo, req-nr_relocs,
  req-relocs,
  req-nr_dwords, 0,
- pushbuf);
+ pushbuf, false);
if (ret)
goto out;
}
@@ -669,6 +673,8 @@ nouveau_gem_ioctl_pushbuf_call(struct drm_device *dev, void 
*data,
 
/* Apply any relocations that are required */
if (do_reloc) {
+   void *pbvirt;
+   bool is_iomem;
ret = ttm_bo_kmap(pbbo-bo, 0, pbbo-bo.mem.num_pages,
  pbbo-kmap);
if (ret) {
@@ -676,17 +682,18 @@ nouveau_gem_ioctl_pushbuf_call(struct drm_device *dev, 
void *data,
goto out;
}
 
+   pbvirt = ttm_kmap_obj_virtual(pbbo-kmap, is_iomem);
ret = nouveau_gem_pushbuf_reloc_apply(chan, req-nr_buffers, bo,
  req-nr_relocs,
  req-relocs,
  req-nr_dwords,
  req-offset / 4,
- pbbo-kmap.virtual);
+ pbvirt, is_iomem);
 
if (!PUSHBUF_CAL) {
-   uint32_t *pushbuf = pbbo-kmap.virtual + req-offset;
-
-   pushbuf[req-nr_dwords - 2] = req-suffix0;
+   nouveau_bo_wr32(pbbo,
+   req-offset / 4 + req-nr_dwords - 2,
+   req-suffix0);
}
 
ttm_bo_kunmap(pbbo-kmap);
-- 
1.6.3.3

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] drm bo accessors etc. v2

[Pekka Paalanen]

Revised patch set v2.

[PATCH 1/8] drm/nouveau: bo read/write wrappers for nv04_crtc.c
[PATCH 2/8] drm/nouveau: use bo accessors for push buffers
[PATCH 3/8] drm/nouveau: OUT_RINGp - optimize OUT_RING loops
[PATCH 4/8] drm/nv50: proper notifier_bo access in 
nv50_display_vblank_crtc_handler()
[PATCH 5/8] drm/nouveau: access fbcon notifier via bo accessors
[PATCH 6/8] drm/nouveau: screen_base and lut must be iomem
[PATCH 7/8] drm/nouveau: remove redundant check in nouveau_bo_del_ttm()
[PATCH 8/8] drm/nouveau: remove mask in nv04_fbcon_imageblit()
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [PATCH 1/8] drm/nouveau: bo read/write wrappers for nv04_crtc.c

[Pekka Paalanen]

Introduce accessors for TTM buffer object memory that has been mapped
into the kernel virtual address space or as IO memory. IO memory needs
to be accessed via special accessor functions, not by dereferencing the
iomem cookie. The wrappers hide the details of 32-bit access and honour
the TTM map type.

nv04_crtc_cursor_set() is changed to use the new wrappers. 'cursor' is
received from user space, which means we cannot assume that it is or is
not iomem. 'nv_crtc-cursor.nvbo' should always be iomem, and as such
the access is relatively slow. Therefore using the wrappers for it, too,
should not cost much.

Signed-off-by: Pekka Paalanen p...@iki.fi
---
 drivers/gpu/drm/nouveau/nouveau_bo.c  |   23 +++
 drivers/gpu/drm/nouveau/nouveau_drv.h |2 ++
 drivers/gpu/drm/nouveau/nv04_crtc.c   |7 ++-
 3 files changed, 27 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index a7b2a61..e7a8d60 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -188,6 +188,29 @@ nouveau_bo_unmap(struct nouveau_bo *nvbo)
ttm_bo_kunmap(nvbo-kmap);
 }
 
+u32
+nouveau_bo_rd32(struct nouveau_bo *nvbo, unsigned index)
+{
+   bool is_iomem;
+   u32 *mem = ttm_kmap_obj_virtual(nvbo-kmap, is_iomem);
+   mem = mem[index];
+   if (is_iomem)
+   return ioread32_native((void __force __iomem *)mem);
+   else
+   return *mem;
+}
+
+void
+nouveau_bo_wr32(struct nouveau_bo *nvbo, unsigned index, u32 val)
+{
+   bool is_iomem;
+   u32 *mem = ttm_kmap_obj_virtual(nvbo-kmap, is_iomem);
+   mem = mem[index];
+   if (is_iomem)
+   iowrite32_native(val, (void __force __iomem *)mem);
+   else
+   *mem = val;
+}
 static struct ttm_backend *
 nouveau_bo_create_ttm_backend_entry(struct ttm_bo_device *bdev)
 {
diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h 
b/drivers/gpu/drm/nouveau/nouveau_drv.h
index b2f69bc..fe6a0a1 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drv.h
+++ b/drivers/gpu/drm/nouveau/nouveau_drv.h
@@ -958,6 +958,8 @@ extern int nouveau_bo_pin(struct nouveau_bo *, uint32_t 
flags);
 extern int nouveau_bo_unpin(struct nouveau_bo *);
 extern int nouveau_bo_map(struct nouveau_bo *);
 extern void nouveau_bo_unmap(struct nouveau_bo *);
+extern u32 nouveau_bo_rd32(struct nouveau_bo *nvbo, unsigned index);
+extern void nouveau_bo_wr32(struct nouveau_bo *nvbo, unsigned index, u32 val);
 
 /* nouveau_fence.c */
 struct nouveau_fence;
diff --git a/drivers/gpu/drm/nouveau/nv04_crtc.c 
b/drivers/gpu/drm/nouveau/nv04_crtc.c
index dfe9003..4e56c25 100644
--- a/drivers/gpu/drm/nouveau/nv04_crtc.c
+++ b/drivers/gpu/drm/nouveau/nv04_crtc.c
@@ -848,7 +848,6 @@ nv04_crtc_cursor_set(struct drm_crtc *crtc, struct drm_file 
*file_priv,
struct nouveau_crtc *nv_crtc = nouveau_crtc(crtc);
struct nouveau_bo *cursor = NULL;
struct drm_gem_object *gem;
-   uint32_t *src, *dst, pixel;
int ret = 0, alpha, i;
 
if (width != 64 || height != 64)
@@ -867,8 +866,6 @@ nv04_crtc_cursor_set(struct drm_crtc *crtc, struct drm_file 
*file_priv,
ret = nouveau_bo_map(cursor);
if (ret)
goto out;
-   src = cursor-kmap.virtual;
-   dst = nv_crtc-cursor.nvbo-kmap.virtual;
 
/* nv11+ supports premultiplied (PM), or non-premultiplied (NPM) alpha
 * cursors (though NPM in combination with fp dithering may not work on
@@ -877,7 +874,7 @@ nv04_crtc_cursor_set(struct drm_crtc *crtc, struct drm_file 
*file_priv,
 * blob uses, however we get given PM cursors so we use PM mode
 */
for (i = 0; i  64 * 64; i++) {
-   pixel = *src++;
+   uint32_t pixel = nouveau_bo_rd32(cursor, i);
 
/* hw gets unhappy if alpha = rgb values.  for a PM image less
 * than shouldn't happen; fix equal to case by adding one to
@@ -897,7 +894,7 @@ nv04_crtc_cursor_set(struct drm_crtc *crtc, struct drm_file 
*file_priv,
}
 #endif
 
-   *dst++ = pixel;
+   nouveau_bo_wr32(nv_crtc-cursor.nvbo, i, pixel);
}
 
nouveau_bo_unmap(cursor);
-- 
1.6.3.3

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [PATCH 6/8] drm/nouveau: screen_base and lut must be iomem

[Pekka Paalanen]

This introduces nvbo_kmap_obj_iovirtual() for cases where the bo memory
is guaranteed (or supposed) to be iomem.

Fbcon assumes screen_base is iomem, and the crtc color LUT must reside
in iomem.

Signed-off-by: Pekka Paalanen p...@iki.fi
---
 drivers/gpu/drm/nouveau/nouveau_drv.h   |   11 +++
 drivers/gpu/drm/nouveau/nouveau_fbcon.c |2 +-
 drivers/gpu/drm/nouveau/nv50_crtc.c |2 +-
 3 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h 
b/drivers/gpu/drm/nouveau/nouveau_drv.h
index 556b0fa..5aca302 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drv.h
+++ b/drivers/gpu/drm/nouveau/nouveau_drv.h
@@ -95,6 +95,17 @@ nouveau_gem_object(struct drm_gem_object *gem)
return gem ? gem-driver_private : NULL;
 }
 
+/* TODO: submit equivalent to TTM generic API upstream? */
+static inline void __iomem *
+nvbo_kmap_obj_iovirtual(struct nouveau_bo *nvbo)
+{
+   bool is_iomem;
+   void __iomem *ioptr = (void __force __iomem *)ttm_kmap_obj_virtual(
+   nvbo-kmap, is_iomem);
+   WARN_ON_ONCE(ioptr  !is_iomem);
+   return ioptr;
+}
+
 struct mem_block {
struct mem_block *next;
struct mem_block *prev;
diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c 
b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
index 6a21a70..2c261fd 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
@@ -588,7 +588,7 @@ static int nouveau_fbcon_create(struct drm_device *dev, 
uint32_t fb_width,
info-flags = FBINFO_DEFAULT | FBINFO_HWACCEL_COPYAREA |
  FBINFO_HWACCEL_FILLRECT | FBINFO_HWACCEL_IMAGEBLIT;
 
-   info-screen_base = nouveau_fb-nvbo-kmap.virtual;
+   info-screen_base = nvbo_kmap_obj_iovirtual(nouveau_fb-nvbo);
info-screen_size = size;
 
info-pseudo_palette = fb-pseudo_palette;
diff --git a/drivers/gpu/drm/nouveau/nv50_crtc.c 
b/drivers/gpu/drm/nouveau/nv50_crtc.c
index f1c67bf..f3dab44 100644
--- a/drivers/gpu/drm/nouveau/nv50_crtc.c
+++ b/drivers/gpu/drm/nouveau/nv50_crtc.c
@@ -43,7 +43,7 @@ nv50_crtc_lut_load(struct nouveau_crtc *crtc)
 {
struct drm_device *dev = crtc-base.dev;
uint32_t index = 0, i;
-   void __iomem *lut = crtc-lut.nvbo-kmap.virtual;
+   void __iomem *lut = nvbo_kmap_obj_iovirtual(crtc-lut.nvbo);
 
NV_DEBUG(dev, \n);
 
-- 
1.6.3.3

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [PATCH 5/8] drm/nouveau: access fbcon notifier via bo accessors

[Pekka Paalanen]

Notifier can live in system memory or VRAM, hence they must be accessed
using the bo wrapper functions.

Remove the redundant member nouveau_channel::m2mf_ntfy_map.

Signed-off-by: Pekka Paalanen p...@iki.fi
---
 drivers/gpu/drm/nouveau/nouveau_dma.c   |2 --
 drivers/gpu/drm/nouveau/nouveau_drv.h   |1 -
 drivers/gpu/drm/nouveau/nouveau_fbcon.c |5 +++--
 3 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_dma.c 
b/drivers/gpu/drm/nouveau/nouveau_dma.c
index 0025c3d..b1f3a71 100644
--- a/drivers/gpu/drm/nouveau/nouveau_dma.c
+++ b/drivers/gpu/drm/nouveau/nouveau_dma.c
@@ -62,8 +62,6 @@ nouveau_dma_init(struct nouveau_channel *chan)
ret = nouveau_bo_map(chan-notifier_bo);
if (ret)
return ret;
-   chan-m2mf_ntfy_map  = chan-notifier_bo-kmap.virtual;
-   chan-m2mf_ntfy_map += chan-m2mf_ntfy;
}
 
/* Initialise DMA vars */
diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h 
b/drivers/gpu/drm/nouveau/nouveau_drv.h
index 8516fda..556b0fa 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drv.h
+++ b/drivers/gpu/drm/nouveau/nouveau_drv.h
@@ -203,7 +203,6 @@ struct nouveau_channel
 
/* GPU object info for stuff used in-kernel (mm_enabled) */
uint32_t m2mf_ntfy;
-   volatile uint32_t *m2mf_ntfy_map;
uint32_t vram_handle;
uint32_t gart_handle;
bool accel_done;
diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c 
b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
index 645b087..6a21a70 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
@@ -71,12 +71,13 @@ nouveau_fbcon_sync(struct fb_info *info)
OUT_RING  (chan, 0);
BEGIN_RING(chan, 0, 0x0100, 1);
OUT_RING  (chan, 0);
-   chan-m2mf_ntfy_map[3] = 0x;
+   nouveau_bo_wr32(chan-notifier_bo, chan-m2mf_ntfy + 3, 0x);
FIRE_RING (chan);
 
ret = -EBUSY;
for (i = 0; i  10; i++) {
-   if (chan-m2mf_ntfy_map[3] == 0) {
+   if (nouveau_bo_rd32(chan-notifier_bo, chan-m2mf_ntfy + 3)
+   == 0) {
ret = 0;
break;
}
-- 
1.6.3.3

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [PATCH 7/8] drm/nouveau: remove redundant check in nouveau_bo_del_ttm()

[Pekka Paalanen]

ttm_bo_kunmap() already checks if the bo is not mapped.

Signed-off-by: Pekka Paalanen p...@iki.fi
---
 drivers/gpu/drm/nouveau/nouveau_bo.c |3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index e7a8d60..eba257a 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -39,8 +39,7 @@ nouveau_bo_del_ttm(struct ttm_buffer_object *bo)
struct drm_nouveau_private *dev_priv = nouveau_bdev(bo-bdev);
struct nouveau_bo *nvbo = nouveau_bo(bo);
 
-   if (unlikely(nvbo-kmap.virtual))
-   ttm_bo_kunmap(nvbo-kmap);
+   ttm_bo_kunmap(nvbo-kmap);
 
if (unlikely(nvbo-gem))
DRM_ERROR(bo %p still attached to GEM object\n, bo);
-- 
1.6.3.3

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [PATCH 8/8] drm/nouveau: remove mask in nv04_fbcon_imageblit()

[Pekka Paalanen]

The local variable 'mask' is simply confusing, the value is equivalent
to zero.

Why? The literal 0 is by default signed. So is ~0. Bitshift to right of
a signed type is implementation defined, gcc replicates the sign bit.
Therefore ~0  x equals always ~0, and the final 'mask' value is 0.

Remove this obfuscation.

Signed-off-by: Pekka Paalanen p...@iki.fi
---
 drivers/gpu/drm/nouveau/nv04_fbcon.c |5 ++---
 1 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nv04_fbcon.c 
b/drivers/gpu/drm/nouveau/nv04_fbcon.c
index 14fc87f..3d19492 100644
--- a/drivers/gpu/drm/nouveau/nv04_fbcon.c
+++ b/drivers/gpu/drm/nouveau/nv04_fbcon.c
@@ -96,7 +96,6 @@ nv04_fbcon_imageblit(struct fb_info *info, const struct 
fb_image *image)
struct nouveau_channel *chan = dev_priv-channel;
uint32_t fg;
uint32_t bg;
-   uint32_t mask = ~(~0  (32 - info-var.bits_per_pixel));
uint32_t dsize;
uint32_t width;
uint32_t *data = (uint32_t *)image-data;
@@ -119,8 +118,8 @@ nv04_fbcon_imageblit(struct fb_info *info, const struct 
fb_image *image)
width = (image-width + 31)  ~31;
dsize = (width * image-height)  5;
 
-   fg = ((uint32_t *) info-pseudo_palette)[image-fg_color] | mask;
-   bg = ((uint32_t *) info-pseudo_palette)[image-bg_color] | mask;
+   fg = ((uint32_t *) info-pseudo_palette)[image-fg_color];
+   bg = ((uint32_t *) info-pseudo_palette)[image-bg_color];
 
BEGIN_RING(chan, NvSubGdiRect, 0x0be4, 7);
OUT_RING  (chan, (image-dy  16) | (image-dx  0x));
-- 
1.6.3.3

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 05/12] drm/nouveau: Use drm_encoder_slave instead of drm_encoder.

[Pekka Paalanen]

On Wed, 12 Aug 2009 02:15:01 +0200
Francisco Jerez curroje...@riseup.net wrote:

 
 Signed-off-by: Francisco Jerez curroje...@riseup.net
 ---
  drivers/gpu/drm/nouveau/nouveau_connector.c |8 
  drivers/gpu/drm/nouveau/nouveau_encoder.h   |   11 ---
  drivers/gpu/drm/nouveau/nv04_output.c   |8 
  drivers/gpu/drm/nouveau/nv50_crtc.c |2 +-
  drivers/gpu/drm/nouveau/nv50_dac.c  |   18 +-
  drivers/gpu/drm/nouveau/nv50_sor.c  |   18 +-
  6 files changed, 35 insertions(+), 30 deletions(-)

 diff --git a/drivers/gpu/drm/nouveau/nouveau_encoder.h 
 b/drivers/gpu/drm/nouveau/nouveau_encoder.h
 index 3344e6c..d558b97 100644
 --- a/drivers/gpu/drm/nouveau/nouveau_encoder.h
 +++ b/drivers/gpu/drm/nouveau/nouveau_encoder.h
 @@ -27,26 +27,31 @@
  #ifndef __NOUVEAU_OUTPUT_H__
  #define __NOUVEAU_OUTPUT_H__
  
 +#include drm_encoder_slave.h
  #include nouveau_drv.h
  
  #define NV_DPMS_CLEARED 0x80
  
  struct nouveau_encoder {
 - struct drm_encoder base;
 + struct drm_encoder_slave base;
  
   struct dcb_entry *dcb;
   int or;
  
 + struct drm_display_mode mode;
   int last_dpms;
  
   struct nv04_output_reg restore;
  };
 -
  static inline struct nouveau_encoder *nouveau_encoder(struct drm_encoder 
 *enc)
  {
 - return container_of(enc, struct nouveau_encoder, base);
 + struct drm_encoder_slave *slave = to_encoder_slave(enc);
 +
 + return container_of(slave, struct nouveau_encoder, base);
  }
  
 +#define to_drm_encoder(x) ((x)-base.base)

I'd prefer static inline functions for this to make the types involved
explicit. Especially the input type.

 +
  int nv50_sor_create(struct drm_device *dev, struct dcb_entry *entry);
  int nv50_dac_create(struct drm_device *dev, struct dcb_entry *entry);

-- 
Pekka Paalanen
http://www.iki.fi/pq/
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH 10/12] drm: Import driver for the ch7006 I2C TV encoder chip.

[Pekka Paalanen]

On Wed, 12 Aug 2009 02:15:06 +0200
Francisco Jerez curroje...@riseup.net wrote:

 
 Signed-off-by: Francisco Jerez curroje...@riseup.net
 ---
  drivers/gpu/drm/Kconfig   |   14 +
  drivers/gpu/drm/Makefile  |1 +
  drivers/gpu/drm/i2c/Makefile  |3 +
  drivers/gpu/drm/i2c/ch7006_drv.c  |  479 
 +
  drivers/gpu/drm/i2c/ch7006_mode.c |  470 
  drivers/gpu/drm/i2c/ch7006_priv.h |  332 +
  include/drm/i2c/ch7006.h  |   86 +++
  7 files changed, 1385 insertions(+), 0 deletions(-)
  create mode 100644 drivers/gpu/drm/i2c/Makefile
  create mode 100644 drivers/gpu/drm/i2c/ch7006_drv.c
  create mode 100644 drivers/gpu/drm/i2c/ch7006_mode.c
  create mode 100644 drivers/gpu/drm/i2c/ch7006_priv.h
  create mode 100644 include/drm/i2c/ch7006.h

This patch should probably go in via dri-devel@ and airlied, like
the other two DRM patches. Would that work?

It would be unused without Nouveau, so it probably won't get to
Linus' before Nouveau does. Airlied?

Does Nouveau build and work otherwise without this patch?

If we take it to the nouveau/linux-2.6 master branch, we would
have to remember to revert it when submitting Nouveau upstream.
OTOH, we could apply it to master-compat branch for testing.
How's that sound?


Thanks.

-- 
Pekka Paalanen
http://www.iki.fi/pq/
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] I have a multihead setup

[Pekka Paalanen]

On Sat, 8 Aug 2009 18:51:18 -0700 (PDT)
Victor Olvera dude...@yahoo.com wrote:

 I was reading thru the project page and I found that you were looking
 for people with multihead setup.
 
 my setup is
 1 AGP TNT2
 1 PCI TNT2
 1 PCI old ATI-all-in-wonder
 
 and I am running Mandriva 2008.1 because its the only linux distro that
 will use my setup...

Multi-card would be the correct term, multihead (on a single card)
is already supported.

First you could test that each card works on its own, without any of
the other two installed. Then try combinations of one nvidia and
one ati card. Then the two nvidia cards installed, which might
already trigger problems even if you tried to use only one of them.
And then using the both of them, and finally all three.

I'm not sure how much of multi-card support is unimplemented, but
it's not just test and report bugs, AFAIK it will involve
implementing things. So it will be an interesting project.

I think Dave Airlie (airlied, Australian timezone) could tell
you about the generic infrastructure, what might still be
missing in the graphics stack. Ben Skeggs (darktama, also Australia)
masters the Nouveau DRM and other stuff. Then there are other
people on the irc channel, mostly on European timezone, who
may also be able to help and answer questions.

It's possible that you find some problems with a TNT2 alone,
so solving those might be a nice entry point into the development.

The most beneficial would be to make them work with KMS.
Non-KMS (as in user mode setting, UMS) does still exist, but
the development is slowly moving away from it.

You should stick to the #nouveau irc channel 24/7 if you can :-)


Cheers.

-- 
Pekka Paalanen
http://www.iki.fi/pq/
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [PATCH 1/7] drm/nouveau: sparse cleanups for undeclared vs. static

[Pekka Paalanen]

Module parameters declarations moved to nouveau_drv.h.
Ioctl table declarations moved to nouveau_drv.h.
nouveau_ioc32.c: include nouveau_drv.h for nouveau_compat_ioctl().

Signed-off-by: Pekka Paalanen p...@iki.fi
---
 drivers/gpu/drm/nouveau/nouveau_bios.c  |3 ---
 drivers/gpu/drm/nouveau/nouveau_connector.c |2 --
 drivers/gpu/drm/nouveau/nouveau_drv.c   |3 ---
 drivers/gpu/drm/nouveau/nouveau_drv.h   |9 +
 drivers/gpu/drm/nouveau/nouveau_fbcon.c |2 --
 drivers/gpu/drm/nouveau/nouveau_ioc32.c |2 +-
 drivers/gpu/drm/nouveau/nouveau_mem.c   |2 --
 7 files changed, 10 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_bios.c 
b/drivers/gpu/drm/nouveau/nouveau_bios.c
index d61e717..d3f052a 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bios.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bios.c
@@ -3249,9 +3249,6 @@ int nouveau_bios_parse_lvds_table(struct drm_device *dev, 
int pxclk, bool *dl, b
return 0;
 }
 
-extern int nouveau_uscript_lvds;
-extern int nouveau_uscript_tmds;
-
 int
 nouveau_bios_run_display_table(struct drm_device *dev, struct dcb_entry 
*dcbent,
   int pxclk)
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c 
b/drivers/gpu/drm/nouveau/nouveau_connector.c
index 5015f75..c89bef7 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -34,8 +34,6 @@
 #include nouveau_connector.h
 #include nouveau_hw.h
 
-extern int nouveau_duallink;
-
 static struct nouveau_encoder *
 nouveau_connector_encoder_get(struct drm_connector *connector, int type)
 {
diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.c 
b/drivers/gpu/drm/nouveau/nouveau_drv.c
index c9b169f..bdee0dc 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drv.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drv.c
@@ -277,9 +277,6 @@ nouveau_pci_resume(struct pci_dev *pdev)
return 0;
 }
 
-extern struct drm_ioctl_desc nouveau_ioctls[];
-extern int nouveau_max_ioctl;
-
 static struct drm_driver driver = {
.driver_features =
DRIVER_USE_AGP | DRIVER_PCI_DMA | DRIVER_SG |
diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h 
b/drivers/gpu/drm/nouveau/nouveau_drv.h
index 25510b3..fa89b14 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drv.h
+++ b/drivers/gpu/drm/nouveau/nouveau_drv.h
@@ -606,6 +606,13 @@ nouveau_bo_ref(struct nouveau_bo *ref, struct nouveau_bo 
**pnvbo)
(ch) = nv-fifos[(id)];  \
 } while(0)
 
+/* nouveau_drv.c */
+extern int nouveau_noagp;
+extern int nouveau_duallink;
+extern int nouveau_uscript_lvds;
+extern int nouveau_uscript_tmds;
+extern int nouveau_fbpercrtc;
+
 /* nouveau_state.c */
 extern void nouveau_preclose(struct drm_device *dev, struct drm_file *);
 extern int  nouveau_load(struct drm_device *, unsigned long flags);
@@ -658,6 +665,8 @@ extern int  nouveau_ioctl_notifier_free(struct drm_device 
*, void *data,
struct drm_file *);
 
 /* nouveau_fifo.c */
+extern struct drm_ioctl_desc nouveau_ioctls[];
+extern int nouveau_max_ioctl;
 extern int  nouveau_fifo_init(struct drm_device *);
 extern int  nouveau_fifo_ctx_size(struct drm_device *);
 extern void nouveau_fifo_cleanup(struct drm_device *, struct drm_file *);
diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c 
b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
index 601eabe..bc229cb 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
@@ -47,8 +47,6 @@
 #include nouveau_fbcon.h
 #include nouveau_dma.h
 
-extern int nouveau_fbpercrtc;
-
 static int
 nouveau_fbcon_sync(struct fb_info *info)
 {
diff --git a/drivers/gpu/drm/nouveau/nouveau_ioc32.c 
b/drivers/gpu/drm/nouveau/nouveau_ioc32.c
index f55ae7a..a2c30f4 100644
--- a/drivers/gpu/drm/nouveau/nouveau_ioc32.c
+++ b/drivers/gpu/drm/nouveau/nouveau_ioc32.c
@@ -36,7 +36,7 @@
 #include drmP.h
 #include drm.h
 
-#include nouveau_drm.h
+#include nouveau_drv.h
 
 /**
  * Called whenever a 32-bit process running under a 64-bit kernel
diff --git a/drivers/gpu/drm/nouveau/nouveau_mem.c 
b/drivers/gpu/drm/nouveau/nouveau_mem.c
index ff473c5..01160fe 100644
--- a/drivers/gpu/drm/nouveau/nouveau_mem.c
+++ b/drivers/gpu/drm/nouveau/nouveau_mem.c
@@ -35,8 +35,6 @@
 #include drm_sarea.h
 #include nouveau_drv.h
 
-extern int nouveau_noagp;
-
 static struct mem_block *
 split_block(struct mem_block *p, uint64_t start, uint64_t size,
struct drm_file *file_priv)
-- 
1.6.3.3

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [PATCH 2/7] drm/nouveau: collect switch blocks in nouveau_fbcon.c

[Pekka Paalanen]

The two large switch blocks are refactored into a function. While doing
this, some inconsistencies are corrected:

- in nouveau_fbcon_check_var(), case 30 was writing to a wrong
  structure.

- in nouveau_fbcon_create(), case 16 was missing transp.length.

Signed-off-by: Pekka Paalanen p...@iki.fi
---
 drivers/gpu/drm/nouveau/nouveau_fbcon.c |  156 ++-
 1 files changed, 51 insertions(+), 105 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c 
b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
index bc229cb..7ccadc0 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
@@ -153,46 +153,15 @@ static int nouveau_fbcon_setcolreg(unsigned regno, 
unsigned red, unsigned green,
return 0;
 }
 
-static int nouveau_fbcon_check_var(struct fb_var_screeninfo *var,
-  struct fb_info *info)
+static int nouveau_fbcon_set_color_fields(int depth,
+ struct fb_var_screeninfo *var)
 {
-   struct nouveau_fbcon_par *par = info-par;
-   struct nouveau_framebuffer *nouveau_fb = par-nouveau_fb;
-   struct drm_device *dev = par-dev;
-   struct drm_framebuffer *fb = nouveau_fb-base;
-   int depth;
-
-   /* Need to resize the fb object !!! */
-   if (var-xres  fb-width || var-yres  fb-height) {
-   NV_ERROR(dev, Requested width/height is greater than current 
fb object %dx%d  %dx%d\n,var-xres,var-yres,fb-width,fb-height);
-   NV_ERROR(dev, Need resizing code.\n);
-   return -EINVAL;
-   }
-
-   switch (var-bits_per_pixel) {
-   case 16:
-   depth = (var-green.length == 6) ? 16 : 15;
-   break;
-   case 32:
-   if (var-transp.length == 2)
-   depth = 30;
-   else
-   if (var-transp.length  0)
-   depth = 32;
-   else
-   depth = 24;
-   break;
-   default:
-   depth = var-bits_per_pixel;
-   break;
-   }
-
switch (depth) {
case 8:
var-red.offset = 0;
var-green.offset = 0;
var-blue.offset = 0;
-   var-red.length = 8;
+   var-red.length = 8; /* 8-bit DAC */
var-green.length = 8;
var-blue.length = 8;
var-transp.length = 0;
@@ -229,14 +198,14 @@ static int nouveau_fbcon_check_var(struct 
fb_var_screeninfo *var,
var-transp.offset = 0;
break;
case 30:
-   info-var.red.offset = 0;
-   info-var.green.offset = 10;
-   info-var.blue.offset = 20;
-   info-var.red.length = 10;
-   info-var.green.length = 10;
-   info-var.blue.length = 10;
-   info-var.transp.offset = 30;
-   info-var.transp.length = 2;
+   var-red.offset = 0;
+   var-green.offset = 10;
+   var-blue.offset = 20;
+   var-red.length = 10;
+   var-green.length = 10;
+   var-blue.length = 10;
+   var-transp.offset = 30;
+   var-transp.length = 2;
break;
case 32:
var-red.offset = 16;
@@ -251,6 +220,45 @@ static int nouveau_fbcon_check_var(struct 
fb_var_screeninfo *var,
default:
return -EINVAL;
}
+   return 0;
+}
+
+static int nouveau_fbcon_check_var(struct fb_var_screeninfo *var,
+  struct fb_info *info)
+{
+   struct nouveau_fbcon_par *par = info-par;
+   struct nouveau_framebuffer *nouveau_fb = par-nouveau_fb;
+   struct drm_device *dev = par-dev;
+   struct drm_framebuffer *fb = nouveau_fb-base;
+   int depth;
+
+   /* Need to resize the fb object !!! */
+   if (var-xres  fb-width || var-yres  fb-height) {
+   NV_ERROR(dev, Requested width/height is greater than current 
fb object %dx%d  %dx%d\n,var-xres,var-yres,fb-width,fb-height);
+   NV_ERROR(dev, Need resizing code.\n);
+   return -EINVAL;
+   }
+
+   switch (var-bits_per_pixel) {
+   case 16:
+   depth = (var-green.length == 6) ? 16 : 15;
+   break;
+   case 32:
+   if (var-transp.length == 2)
+   depth = 30;
+   else
+   if (var-transp.length  0)
+   depth = 32;
+   else
+   depth = 24;
+   break;
+   default:
+   depth = var-bits_per_pixel;
+   break;
+   }
+
+   if (nouveau_fbcon_set_color_fields(depth, var))
+   return -EINVAL;
 
return 0;
 }
@@ -606,69 +614,7 @@ static int nouveau_fbcon_create(struct drm_device *dev, 
uint32_t fb_width,
info-pixmap.flags

[Nouveau] [PATCH 3/7] drm/nouveau: FB_ACCEL_I830 in fbcon is wrong

[Pekka Paalanen]

fb_info::fix.accel field tells user space what kind of accelerations it
can do via the framebuffer interface. Nouveau is definitely not i830, so
set the field to FB_ACCEL_NONE. In the DRM world we have a lot better
APIs for accelerated graphics.

Cc: Dave Airlie airl...@redhat.com
Signed-off-by: Pekka Paalanen p...@iki.fi
---
 drivers/gpu/drm/nouveau/nouveau_fbcon.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c 
b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
index 7ccadc0..228e763 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
@@ -575,7 +575,7 @@ static int nouveau_fbcon_create(struct drm_device *dev, 
uint32_t fb_width,
info-fix.xpanstep = 1; /* doing it in hw */
info-fix.ypanstep = 1; /* doing it in hw */
info-fix.ywrapstep = 0;
-   info-fix.accel = FB_ACCEL_I830;
+   info-fix.accel = FB_ACCEL_NONE;
info-fix.type_aux = 0;
 
info-fbops = nouveau_fbcon_ops;
-- 
1.6.3.3

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau