2009/12/24 Rafał Miłecki <zaj...@gmail.com>: > W dniu 24 grudnia 2009 17:32 użytkownik Luca Tettamanti > <kronos...@gmail.com> napisał: >> I think it would be safer to execute that code in the IH (or in a tasklet, >> which is guaranteed to run after the handler); the only problem I see is >> that atom_execute_table allocates some memory (ws? workspace?), but the >> GFP flag can be easily adjusted; the rest of the ops seem safe. >> What do you think? > > Thank you for commenting. Indeed we have problems with engine > reclocking not happening right after VBLANK.
The conversion to bh is pretty simple, and it blows up in a spectacular way :-) Aside from the locking (mutex) which has to be reworked, the show stopper is atom_op_delay, which wants to schedule. In my BIOS the biggest delays in SetEngineClock are 200us, so it would be possible to use udelay; not sure if the msec path could use the same treatment. > Marry Christmas! :) Thanks, to you too! L ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
