[Bug 312] New Driver: SMI 501

[bugzilla-daemon at freedesktop.org]

Please do not reply to this email: if you want to comment on the bug, go to    
       
the URL shown below and enter yourcomments there.     
   
https://bugs.freedesktop.org/show_bug.cgi?id=312          
     




------- Additional Comments From snickl at snickl.freaks.de  2005-02-16 01:47 -------
> I can play movies with the help of mplayer (and trough xv output) but
> when the last client disconnects, the server crashes the kernel and the
> prompt appears. When I press enter, more crashes (actually every running
> process) are reported and the kernel is rebooted.
> I am currently working on this, but I haven't got far yet :-(

Strange, I cannot imagine the display driver do anything special when clients
disconnect. But our problem could still be related I guess.

> I am working on PPC, where I had to "force" endianess in of the file
> (If I reemeber correctly it is in compiler.h).

Me too, (mpc8245 for now). I'm cross-compiling and didn't need to force
endianess. X_BYTE_ORDER == X_BIG_ENDIAN is true for me.
 
> > Did you base your work on my merge?
> 
> No. I used the files provided by Terry Chang.
> I downloaded your patch, but there are no smi_501.[ch] files.

Ooop, yes.
I just did a "cvs diff" without "cvs add"-ing them two before.
Didn't seem much sense with read-only access :)
But I didn't change these two files anyway.

> > What kind of endianess do you have in your hardware configuration?
> 
> Big endian, PPC and I have SM 501 connected on local plus bus,
> not the PCI.

I found the endianess switch of the chip to have no effect on PCI.
It's probably only used for local bus configurations.
But it's good you use local bus because we might do that too in the future :)

> I guess it works for me, but as I said I only tested with simple application
> (xeyes, xlogo, xcalc, ...) and mplayer with xv.
> First I'll try to find why it crashes the kernel, then I'll do more on
> the driver.

No success on my side yet. I noticed that SMI_MapMem is called twice and only
maps the frame buffer the second time, but I guess that's normal as it kept
crashing with a hard-coded memory size (which is the reason it doesn't map it
the first time).

I also ask myself if the remaining references to vgaHW are OK (most are masked
by chipset != MSOC).

Btw, I fixed the HW cursor by replacing the memcpy in smi_hwcurs.c with a
INT32-swapping copy loop, so my assumption on that was correct.

Stefan          
     
     
--           
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email         
     
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.