Instead of trying to adjust the LCD's native FPS down from 60 to some desired value, why don't you change your usage of the driver?
Currently, if you using the existing display.c sample code, the main form of frame rate scheduling is through the waitForVsync() call (function that does a ioctl for panning) Coupled with the existing pipes put-get method of data transfer, it binds the producer of data to the explicit scheduling given by the Vsync call, which is then bound to the LCD's frame rate. We changed it around to make it more of a decoupled display system, so that any producer of displayable data will copy it to one of the display buffers (pointed to by displayIdx) and the display thread, upon finding existing data available, will then proceed to do flip the buffers and do a waitForVsync. The main benefit here is that the producer does not get slapped with the delay time for the wait for vsync call. We then added some custom scheduling code that acts to schedule and 'release' displayable frames at the correct times to the display buffers. This way, you can release data to the buffers at whatever rate you'd like (all the way from 1 FPS up to any ridiculous FPS you'd like). The main benefit here is that a 'release' is ~constant time, so you can use your scheduler as the main way of custom scheduling. If you do your own scheduler but don't change the existing code, you'll be doing 'double' scheduling and might get erratic results since the FIFO put and get calls are not guaranteed to return in constant time. Note that this is a slight bit of work, but its extremely useful in the end if you'd like variable frame rate delivery, or if you'd like to do some kind of Audio-Video synchronization Hope it helps, Jerry Johns Design Engineer Nuvation Research Corp - Canada Tel: (519) 746-2304 ext. 221 www.nuvation.com <http://www.nuvation.com>
_______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
