Re: [linux-fbdev] 2.3.99pre7-8 experiences

[Adam C Powell IV <hazelsct@mit.edu>]

Jeff Garzik wrote:

> Adam C Powell IV wrote:
> >
> > Jeff Garzik wrote:
> >
> > > Applied to clgenfb, with some slight updates.  Should be in
> > > 2.3.99-pre7-pre9 or so..
> >
> > Thanks very much!
> >
> > Is there anything I can do to help fix clgenfb for MacPicasso?  Any
> > printks I can stick into init_vgachip() to help determine why it's
> > oopsing?
>
> For the oopsing, liberally sprinkling printks all over the place, or
> using KDB, seem like the best options.
>
> The Cirrus Logic databooks are at
> http://www.cirrus.com/products/pubs.html if you are interested in
> hardware debugging..

Thanks, downloading as we speak, but in the meantime my problems seem
more basic...

First question: is *anyone* using clgenfb on PPC with a card which
identifies as BT_GD5480?  In clgen_pci_probe_list, it's identified only
as "MacPicasso probably," so it doesn't seem like it.  I ask for
patching purposes, I'm wondering if it's okay to if (type == BT_GD5480)
around fixes for my particular problems, and not break the fb for
someone else.

Next, with a little help from my printks, I think I've isolated the
problem in clgenfb.c.

First, clgen_pci_setup assumes 32 MB for my board, I guess because that
worked for someone else; when I comment the if (*btype == BT_GD5480) to
force a call to clgen_get_memsize(), it crashes in vga_rseq- "Kernel
panic: machine check".  So, I change the 32 * MB_ to 4 * MB_, now it
gets the size right. :-)

But then it dies when init_vgachip calls WHDR(), at the first RGen(),
which calls vga_r with regs = 0 (this is set in clgen_pci_setup() for
non-PREP, the line where it's set has the comment "FIXME: this forces
VGA.  alternatives?") and port = VGA_PEL_MSK = 0x3c6; this falls through
to vga_io_r, which calls inb(), which calls in_8() from
include/asm/io.h, I don't read asm, but the error is "Kernel panic:
machine check".

So I tried setting regs to fbregs_phys, and that bombs in the first
vga_wgfx() call from init_vgachip with "Kernel panic: kernel access of
bad area [pc, lr..] address 0x808013CE tsk swapper/1".

So I tried having RGen call vga_mm_r, which uses readb(x), which is
#defined to (*(x)), and that dies with "Kernel panic: kernel access of
bad area [pc, etc.] address 3C6 tsk swapper/1".  This despite the
request_region in clgen_pci_setup, though I haven't checked for the
return.

So, vga_r() -> vgr_io_r() doesn't work, vga_mm_r() doesn't work, nor
vga_rseq (which calls vga_r), tried dropping vga_rgfx() into RGen()
(though that calls vga_r too), predictably, machine check.

How might I read a register from the card?  Is it necessary in WHDR(),
or can it be avoided/substituted, since the return is dumped into dummy?

Also, I've noticed two unrelated bizarre behaviors:

  1. Even though CLGEN_DEBUG is definitely defined, and gcc -E shows
     things like
     printk("<7>"  "%s: "  "ENTER\n" , __FUNCTION__  ) ;
     (even tried gcc -v with the same options, then duplicated the
     complete cpp command, which gave the same output as gcc -E), these
     DPRINTKs are being _completely ignored_ in the binary, as if
     CLGEN_DEBUG is *not* defined!  What on earth???
  2. I switched from make-kpkg kernel_image to make ARCH=ppc zImage to
     avoid the "make clean" at the end of the kernel_image target.  Even
     so, with all of the .o's in place, it still is compelled to
     recompile almost everything in the entire tree when I touch only
     clgenfb.c (from the timestamps, I know that
     drivers/video/font_xxx.o and fonts.o are not being rebuilt, but
     those are the only things in that directory).  However, if I stop
     the build partway, then it does not recompile everything which has
     compiled so far.  What dependency is being inadvertently touched at
     the end of the build?  How can I avoid it so I only recompile
     clgenfb.c?  Could this have anything to do with the
     include/linux/bitops.h <- include/asm/bitops.h circular dependency?

Any help is much appreciated!

-Adam P.