|
osdir.com mailing list archive |
|
Subject: cromwell BootInterrupts.c,1.9,1.10 - msg#00721List: linux.ports.xbox.develIn directory sc8-pr-cvs1:/tmp/cvs-serv20479 Modified Files: BootInterrupts.c Log Message: Xromwell compilefix. Index: BootInterrupts.c =================================================================== RCS file: /cvsroot/xbox-linux/cromwell/BootInterrupts.c,v retrieving revision 1.9 retrieving revision 1.10 diff -C2 -d -r1.9 -r1.10 *** BootInterrupts.c 24 Feb 2003 19:06:01 -0000 1.9 --- BootInterrupts.c 25 Feb 2003 06:32:36 -0000 1.10 *************** *** 325,331 **** void IntHandler1C(void) { - extern volatile USB_CONTROLLER_OBJECT usbcontroller[2]; // bprintf("USB1 Interrupt 1\n"); #ifndef XBE BootUsbInterrupt(&usbcontroller[0]); #endif --- 325,331 ---- void IntHandler1C(void) { // bprintf("USB1 Interrupt 1\n"); #ifndef XBE + extern volatile USB_CONTROLLER_OBJECT usbcontroller[2]; BootUsbInterrupt(&usbcontroller[0]); #endif *************** *** 450,455 **** { // bprintf("USB2 Interrupt 9\n"); - extern volatile USB_CONTROLLER_OBJECT usbcontroller[2]; #ifndef XBE BootUsbInterrupt(&usbcontroller[1]); #endif --- 450,455 ---- { // bprintf("USB2 Interrupt 9\n"); #ifndef XBE + extern volatile USB_CONTROLLER_OBJECT usbcontroller[2]; BootUsbInterrupt(&usbcontroller[1]); #endif ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf Thread at a glance:
Previous Message by Date: click to view message previewRe: CRTC regsOliver Schwartz wrote: > I've played a bit with the CRTC regs today. It seems their setting > is rather uncritical. I've tried different settings from "fbdev" > which allows to modify the CRTC timings directly. Here are the > results: [...] CRTC pixel clock has no effect at all [...] Before making any drastic changes or removing large sections of the original driver code, please note that the CRTC <-> video encoder relationship can be set to either "master", "pseudo-master" or "slave" (see the Conexant datasheet). Switching from one of these modes to another perhaps might make those seemingly unused registers "live" again. Even though we have now been running in the "pseudo-master" mode all the time (I think?), it is not unconceivable that some day we would want to switch the Conexant chip to "slave" mode for some specific video output modes - for example, for VGA passthrough - and then some of those registers (like the above-mentioned pixel clock) might be needed again. -- Jukka Aho +358 6 317 4282 Konepajakatu 9 Q 48 +358 50 349 8812 IRCNet:znark FIN-65100 Vaasa jukka.aho@xxxxxx http://www.iki.fi/znark/ ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf Next Message by Date: click to view message previewRe: CRTC regsOn Mon, 2003-02-24 at 22:37, Oliver Schwartz wrote: Hi Oliver - > I've played a bit with the CRTC regs today. It seems their setting is > rather uncritical. I've tried different settings from "fbdev" which > allows to modify the CRTC timings directly. Here are the results: > > - CRTC pixel clock has no effect at all. If I understand this > correctly this means that 0x680508, 0x68050c as well as CRTC regs > 0x1b and 0x20 can be set to fixed values. The scary "CalcArbitration" > routines in the different nv drivers can be kicked out completely. This would make sense, I believe the Conexant is providing the pixel clock, but is expecting everything else (syncs, blank, and of course pixel data) to be output to it from the nVidia chip. > - All sync margins have no effect and can be assumed 0 for the CRTC > value calculations (affects CRTC register 0x00, 0x04, 0x06, 0x10). Not too certain these guys have NO effect. I found on several registers that they had relationships to the nv fp ones which gave valid bounds to the CRTC values, that is you could grossly change the CRTC ones without impact until they exceeded the corresponding nv fp value. I would try setting them all to zero and FF before writing them off. > - The length of the sync pulses configured in CRTC matters, but a > broad range gives identical results. (registers 0x05 and 0x11). This sounds right, the Conexant is just looking at the onset of sync. > This leaves us with few things to set in the CRTC registers. As far as > timing is concerned only resolution (0x01, 0x02, 0x12 and 0x15) and > sync length have to be specified, the rest can be derived easily. Vertical overscan compensation is still a mystery to me, the one thing that's clear is that you have to screw with the blank region and let the Conexant FIFO solve the sync problems. -Andy ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf Previous Message by Thread: click to view message previewquick questionFirst of all, great work guys. What's the status of playing DVD movies? (Hehe I have enough spare $ for either a MatriX or the stupid dvd remote thing) Adam Karboski Next Message by Thread: click to view message previewHOWTO for X11 and nv framebuffer?I've searched on the web and I couldn't find any HOWTO for setting up nv framebuffer to work on XBox. Could you help me? I'm using Mandrake 9.0 on a v1.0 console, but I think I can try to use the HOWTO even if written for Debian. Thanks a lot TeoMan Loading Comments...
|
|
