2011/6/28 Timothy Normand Miller <[email protected]>: > Besides the INT instruction, there may be a flag in the VC that needs > to be set. I'm pretty sure that that signal will make its way thence > unabated from the S3 to the XP10, wherein it is again masked by some > flags you have to set.
I found a mail on this list by Mark Marshall from 2. November 2010 12:13: [...] A change to how interrupts are dealt with. I will add the PCI defined disable interrupt bit and the interrupt status bit to config space. I also plan to modify the way in which the clear_interrupt register will work. From a lot of experience with interrupts in embeded platforms this is how it should work: There is a set number of different interrupt sources, all multiplexed onto the same interrupt. We have a number of registers that have the same structure (one bit per source), these registers are called "int_status", "int_mask" and "int_clear". If any interrupt source triggers (there's a hotplug event of whatever), then the corisponding bit in "int_status" gets sets. This always happens. If "(int_status & int_mask) != 0" then we raise an interrupt to the host. If a value is written to "int_clear", then the ones in the value written clear those interrupt sources (and only those). (This is often written as W1C in hardware specs.) The host will perform exactly this sequence to ack the interrupts. temp = int_status; int_clear = temp; handle_ints(temp); This scheme produces "race-free" operation. Almost every other scheme doesn't. [...] > > I'd look for it, but the only thing I can think about right now is my > Ph.D. candidacy exam coming up. I have a candidacy proposal > (basically most of a dissertation, with a proposal for additional > research), a 7-day take-home written exam from July 1 to 7, and a > presentation and oral exam on the 14th. Anyone want to read by 123 > page thesis? :) > > I'll see if I can try to figure it out tonight or some night soon just > before I go to bed. > > On Tue, Jun 28, 2011 at 11:50 AM, Martin Kielhorn > <[email protected]> wrote: >> 2011/6/28 Mark Marshall <[email protected]>: >>> On 28/06/2011 11:35, Martin Kielhorn wrote: >>>> >>>> Hi list, >>>> is it possible to synchronise the drawing process to the vsync cycle of >>>> the graphics >>>> card from user level? >>>> >>>> Or should I try to modify driver/linux/ogp_skel.c to my needs? >>> >>> ogp_skel doesn't really do anything. It is just a skeleton of a driver. >>> >>> I have never tested any of the vblank interrupt generation support. I think >>> the hardware is wired up, but you'd really have to read the RTL to see. >> >> I tried to. But I have no experience with verilog. >> >> I thought setting these registers should enable the interrupt generation: >> (card-rset *card* +vc0-cpu-reset-b+ 1) >> (card-rset *card* +vc0-video-enable+ 1) >> (card-rset *card* +vc0-interrupt-enable+ 1) >> >> But I don't see anything in my dmesg output. >> Do I also have to set the XP10 interrupt mask? >> >> The entire listing of my test code can be found on >> http://paste.lisp.org/+2MWD >> >> Regards, Martin >> >> -- >> Martin Kielhorn >> Randall Division of Cell & Molecular Biophysics >> King's College London, New Hunt's House >> Guy's Campus, London SE1 1UL, U.K. >> tel: +44 (0) 207 848 6519, fax: +44 (0) 207 848 6435 >> _______________________________________________ >> Open-graphics mailing list >> [email protected] >> http://lists.duskglow.com/mailman/listinfo/open-graphics >> List service provided by Duskglow Consulting, LLC (www.duskglow.com) >> > > > > -- > Timothy Normand Miller > http://www.cse.ohio-state.edu/~millerti > Open Graphics Project > -- Martin Kielhorn Randall Division of Cell & Molecular Biophysics King's College London, New Hunt's House Guy's Campus, London SE1 1UL, U.K. tel: +44 (0) 207 848 6519, fax: +44 (0) 207 848 6435 _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
