W dniu 24 grudnia 2009 23:19 użytkownik Luca Tettamanti <kronos...@gmail.com> napisał: > 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.
I've read LDD3 ch07.pdf again and I can see why I've chosen workqueue. AFAIU tasklets are similar to timers but without execution time as param. It seems to be something like "execute it really soon". That's fine but the problem is we can not sleep in tasklet handler (handlers has to be atomic). As you noticed we need to sleep in reclocking (AtomBIOS command does). I think solution may be sleeping in radeon_pm_idle_work_handler in place where we currently set: "rdev->pm.vblank_callback = true;". We would sleep and ask IRQ code to wake us on VBLANK. Maybe this would be fast enough solution? Or do you have other, better idea? Just keep in mind that we do sleep in radeon_set_engine_clock. -- Rafał ------------------------------------------------------------------------------ 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
