[#4271] Large overhead from udelay(500) in bfin SPORT driver
Submitted By: Michael McTernan
Open Date
2008-07-22 06:17:19 Close Date
2010-06-11 04:39:56
Priority:
Medium Assignee:
Sonic Zhang
Status:
Closed Fixed In Release:
N/A
Found In Release:
2008R1-RC8 Release:
2008R1
Category:
Drivers Board:
Custom
Processor:
ALL Silicon Revision:
0.5
Is this bug repeatable?:
Yes Resolution:
Fixed
Uboot version or rev.:
Toolchain version or rev.:
2008R1
App binary format:
N/A
Summary: Large overhead from udelay(500) in bfin SPORT driver
Details:
Hi,
The bfin_sport driver contains udelay(500) to allow the last byte of a transfer to be completely serialised prior to disabling the SPORT logic. Having already waited until !(status & TXHRE), this delay need only wait for the serialisation of one word as the holding register and therefore FIFO are already empty.
A SPORT configured at 30MHz need only wait 33.3ns per bit to transfer. Assuming a 16 bit word size + early frame sync, a delay of just more than 566.6ns is sufficient.
When making lots of small transfers out of the SPORT, the 0.5ms delay busy waiting per block can sap performance. The delay would be better calculated as:
(1000*BitsPerWord)/CLKsportMHz ns
I'm not sure if it helps, but the udelay() calls were added to your trunk at revision 2507, Modified Wed Dec 6 07:32:56 2006 UTC by royhuang, with the comment:
"If use internal clock, this driver will hang system. This patch fix this bug"
Regards,
Mike
Follow-ups
--- Mike Frysinger 2009-05-05 16:26:05
another example of delay being incorrect (too short in this case):
blackfin.uclinux.org/gf/project/uclinux-dist/forum/?action=ForumBrowse&_forum_action=MessageReply&message_id=73663
--- Sonic Zhang 2009-06-18 06:34:15
500 us block wait is not necessary any more after a dummy data is put into tx
fifo to ensure the sport tx stops just after all bytes are shifted out except
the demmy data.
Fixed
Files
Changes
Commits
Dependencies
Duplicates
Associations
Tags
File Name File Type File Size Posted By
No Files Were Found