New Driver: SMI 501 http://bugs.xfree86.org/show_bug.cgi?id=1001
any movement on this bug? i see a siliconmotion driver in CVS...
If no one else gets to it, I'll look at merging this after 6.8.0
Roland, is there time left for 6.8.2?
Daniel Stone wrote: > Roland, is there time left for 6.8.2? Depends on how the patch looks. If the stuff is in trunk, tested there and the changes are isolatated (e.g. don't affect other stuff much) then it may be debateable to push it into X11R6.8.2 (it's a new feature after all). Items to do: - Make sure it's really the MIT license (just to have an answer for the usual release-wranglers question: Xfree86-bugzilla-reference-in-bug-is-it-really-MIT-license-?) - Get it into Xorg trunk - Get it tested there - Attach patch, request approval (you know the drill... :)
Hi, I've started to merge the SM501-enhanced driver with the Xorg trunk. I'd like to sync up with anyone that may also be working on the code (Roland Mainz suggested best would probably be Engbert Eich). So what's the status? For my part, I'm up to line 2116 of smi_driver.c with my "human-assisted three-way merge" now :-) But be warned, I won't have hardware to test anything for ~2 more weeks.
(In reply to comment #5) > Hi, I've started to merge the SM501-enhanced driver with the Xorg trunk. > I'd like to sync up with anyone that may also be working on the code (Roland > Mainz suggested best would probably be Engbert Eich). > > So what's the status? > For my part, I'm up to line 2116 of smi_driver.c with my "human-assisted > three-way merge" now :-) > > But be warned, I won't have hardware to test anything for ~2 more weeks. > Stefan, Feel free to run with this. I don't think anyone else has enough time to handle the merge at the moment. When you get it merged and tested, please post a patch here against cvs and if it looks good, I'll merge it.
Created attachment 1775 [details] [review] First version of SM501 (Voyager) patch Compiles cleanly, but don't expect any more of it.
(In reply to comment #7) > Created an attachment (id=1775) [edit] > First version of SM501 (Voyager) patch > > Compiles cleanly, but don't expect any more of it. nice work. If you run into any problems when you are testing (or feel like adding more features), SMI has full databooks available on their website; might be handy. http://www.siliconmotion.com/
Hi > Created an attachment (id=1775) [edit] > First version of SM501 (Voyager) patch > > Compiles cleanly, but don't expect any more of it. In this patch there is now smi_501.c file :-( Since 6.8.2 has been released, when do you excpect to include this in the CVS? Matej
(In reply to comment #9) > Hi > > > Created an attachment (id=1775) [edit] [edit] > > First version of SM501 (Voyager) patch > > > > Compiles cleanly, but don't expect any more of it. > > In this patch there is now smi_501.c file :-( > Since 6.8.2 has been released, when do you excpect to include > this in the CVS? > > Matej Once it's been tested on some hardware :)
Hi > > In this patch there is now smi_501.c file :-( Where are those files? > > Since 6.8.2 has been released, when do you excpect to include > > this in the CVS? > > > Once it's been tested on some hardware :) O.K. When do expect this to happen? I have modified (well dirty hack) this dirver so the SM501 can work also on other busses not only on the PCI. It works (I did not do much testing) and mplayer can play movies trough xv. I'd like to contribute this, but first I need to get the latest sources from X.org. I'll make it better, not just a quick hack :-) Matej
(In reply to comment #11) > Hi > > > > In this patch there is now smi_501.c file :-( > > Where are those files? > > > > Since 6.8.2 has been released, when do you excpect to include > > > this in the CVS? > > > > > Once it's been tested on some hardware :) > > O.K. > When do expect this to happen? > > I have modified (well dirty hack) this dirver so the SM501 can work > also on other busses not only on the PCI. It works (I did not do > much testing) and mplayer can play movies trough xv. > > I'd like to contribute this, but first I need to get the latest > sources from X.org. > > I'll make it better, not just a quick hack :-) > > Matej Sounds like you got it working on your sm501. Please post any and all related patches here (preferably against xorg cvs)! Once they've been reviewed and proven to work on the hardware, I'll commit them to cvs.
> I have modified (well dirty hack) this dirver so the SM501 can work > also on other busses not only on the PCI. It works (I did not do > much testing) and mplayer can play movies trough xv. > > I'd like to contribute this, but first I need to get the latest > sources from X.org. Nice to see somebody else is also working on the code now. I've got the PCI eval board and got started somewhat. The problem I've got is that the driver manages to initialize the display, but apparently kills the machine in doing this. Any process that dares to move afterwards makes the linux kernel go Oops immediately. From the fact that the bit pattern for the hardware cursor is distorted I conclude that the original author at SM was not aware of endianess issues. Most is still correct as endianess-aware macros are used for register access. Did you base your work on my merge? Did you find any "obvious" bugs in there? What kind of endianess do you have in your hardware configuration? AFAICT, I've got 0x12345678 -> 0x78563412 for MMIO registers, but data in RGB 5:6:5 mode is more like 0x12345678 -> 0x34127856. Stefan
Hi > Nice to see somebody else is also working on the code now. > I've got the PCI eval board and got started somewhat. Great! > The problem I've got is that the driver manages to initialize the display, but > apparently kills the machine in doing this. Any process that dares to move > afterwards makes the linux kernel go Oops immediately. Yes. 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 :-( > From the fact that the bit pattern for the hardware cursor is distorted I > conclude that the original author at SM was not aware of endianess issues. > Most is still correct as endianess-aware macros are used for register access. I am working on PPC, where I had to "force" endianess in of the file (If I reemeber correctly it is in compiler.h). > 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. > Did you find any "obvious" bugs in there? No yet :-) > 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. > AFAICT, I've got 0x12345678 -> 0x78563412 for MMIO registers, but data > in RGB 5:6:5 mode is more like 0x12345678 -> 0x34127856. 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. Matej
> 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
Hi > Strange, I cannot imagine the display driver do anything special when clients > disconnect. But our problem could still be related I guess. Well, if I just start the server in press Ctrl+C it crashes too :-) (Also kill <pid>) > > 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. This worked, but in xfree85/common/compiler.h there is a line (line 1748): # if defined(PPC_MMIO_IS_BE) /* No byteswapping */ which evaluates to false for me (did not look at it why it is so, I just forced it to be true). Oh, I work on mpc5200. > > 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. I'll "upgrade" to your version, when I find some time. > But it's good you use local bus because we might do that too in the future :) Great! We'll debug it together than. BTW, now I use mmap (after opening /dev/mem) to get the access to registers of SM501. Is there other way, more generic? > No success on my side yet. I noticed that SMI_MapMem is called twice Yes. But it calls SMI_UnmapMem too, where you should unmap the memory mapped in the first call SMI_MapMem. > 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. Great. My cursur seems good. What was the problem? Matej
Short update to bugzilla as me and Matej have continued via email. It seems like the system crash problems came about because of some remaining access that stems from the x86/VGA/Lynx history (outb...). After hunting them down, we both got the server running stable. My remaining problem is endianess as I've got the chip running on PCI and the big/little switch of the chip seems to have no effect there. Matej is apparently struggling for with video performance.
matej, stefan: ping. the code freeze for 7.0 is approaching. if you have any updates on the status of this driver we'd like to know.
(In reply to comment #18) > matej, stefan: ping. the code freeze for 7.0 is approaching. if you have any > updates on the status of this driver we'd like to know. Sorry, but don't expect anything from my side. As you will know this is an embedded chip, and I was working on it from a commercial perspective. My project took a entirely different direction and so the SM501 is currently no topic to me. The chip is now used otherwise in the company, so somebody else may take over, but I can't tell for sure. In general, I'm unhappy with the approach of plumbing 501 support into the siliconmotion driver as it is started with the patch, because the 501 is so entirely unlike all the other sm chips and there are so many aspects that need to be taken care of (PCI mode vs. local bus mode, PPC/x86 etc.). There also seem to be unsettling issues with the fb module if you get endianess wrong (or your hardware does), look at the denx driver for the Coral-P to see what I mean. Because it's for embedded anyways, a fresh start with kdrive/xserver seems the best idea to me, but I have no means to pull this off... However, if anybody wants to take the "plumbing" approach any further, I can dig up the work I did until I got cancelled.
(In reply to comment #18) > matej, stefan: ping. the code freeze for 7.0 is approaching. if you have any > updates on the status of this driver we'd like to know. My situation is similar to Stefan's, so don't expect anything from me, either. I was especially disappointed with the support from SM because I got no reply to 3 emails I sent them. I am wiling to help if someone wants to continue with this but our project was redesigned and we are not using SM501 anymore. Sorry. Matej
Hi: Everybody, I used the SM501 at MPC5200 wtih PCI bus, the big/little error is borthing me now, have anybody sovled it ? I send some mails to Silicon Motion , but they only give me no helpless reply waitting for a long time. I modifie somewhere of the drive source code,now the Xfree86 runing up, but the words and the curson display unormaly as all konw the big/little error. I just used framebuufer mode which I closed the XAA. You kown the performlace is lowly. Let's solve the error hand by hand, will you ? Please give me your any advice -----> ourcabin@163.com
The mpc5200 is special in regard to PCI, see this thread: http://marc.theaimsgroup.com/?l=linuxppc-embedded&m=110880278807278&w=4 Btw: Be aware that the 501 is always little-endian in PCI mode, the endian switch is only for local bus mode.
Thanks for your remind, your means is that it only switch the local bus bytes, not any affect for PCI bus? then, how do I change the endian mode to fit little-endian PCI mode?
Created attachment 3134 [details] [review] add 30 bits pixel format to software render compositing
Comment on attachment 3134 [details] [review] add 30 bits pixel format to software render compositing I received this informal diagram from SMI. The endianess in PCI mode is take-or-leave. But mind you that newer PPCs have a endianess bit for their page table entries. But using this amounts to deep kernel hacking...
I've broken the smi501 code out into a separate driver and added dualhead support, however, I don't have the hardware to test at the moment. you can grab the tarball here (builts against modular X): http://www.botchco.com/alex/xorg/smi501.tar.gz
Marking broken (status null/blank) bugs in xorg with no activity in a long time as fixed. Please reopen if you think it's necessary, but first do a search if a similar bug report is already filed and in a NEW/ASSIGNED state. These bugs do not currently show in most search results as they do not have any status. Sorry for this janitorial spam, you know where to send hate mails to when your inbox gets full of bugs you're subscribed to.
I actually have a dev board with a smi501, and I do plan to verify and merge this at some point.
Sorry about the phenomenal bug spam, guys. Adding xorg-team@ to the QA contact so bugs don't get lost in future.
Alex have you had a chance to test the driver on your SMI501 board?
I haven't tested it myself, but several others are successfully using my tree here: http://cgit.freedesktop.org/~agd5f/xf86-video-smi501/
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.