Quantcast

Kernel udelay() accuracy after mpurate change

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Kernel udelay() accuracy after mpurate change

Scott Ellis
This post was updated on .
This is all from an Overo running a 3.2 kernel.

It seems udelay() does not adjust for the mpurate change on the
kernel command line.

Measurements are taken with a scope watching a gpio line get toggled.

The gpio toggling is not instantaneous, but it is an order of magnitude
less then the udelay times I'm testing, so I'm ignoring it.

I ran three tests for each udelay.

Clock at 600 MHz

udelay(5)   : 6.1, 5.9, 6.1
udelay(10)  : 10.9, 10.7, 10.9
udelay(20)  : 21.0, 20.7, 20.8
udelay(50)  : 50.6, 50.9, 50.7
udelay(100) : 100.3, 100.5, 100.5

Clock at 800 MHz

udelay(5)   : 4.6, 4.4, 4.4
udelay(10)  : 8.4, 8.2, 8.2
udelay(20)  : 15.5, 15.8, 15.5
udelay(50)  : 38.3, 38.0, 38.1
udelay(100) : 75.6, 75.3, 75.4


The usual expectation is that udelay(x) will delay at least x, so
this could be a problem if you are counting on that.

It's easy enough to calculate the value you should use with udelay()
if you know you are changing the clock, i.e. multiply by 4/3 in this
case.

hrtimers() are not affected, but then they aren't too accurate below
300 usec which leaves a gap where you might need udelay.

This is just a heads up for other Gumstix driver developers out there.

It could be this is obvious or well known, but I didn't see anything
from a cursory Google. I never noticed it before.

I just happened across it working on some hardware needing
a delay in the 40-60 usec range.

I can post a simple kernel module to demonstrate the problem if
anyone is interested.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Kernel udelay() accuracy after mpurate change

JamesAng
Thanks Scott!

This is a very useful finding.

James Ang.


On Thu, May 9, 2013 at 7:15 AM, Scott Ellis <[hidden email]> wrote:
This is all from an Overo running a 3.2 kernel.

It seems udelay() does not adjust for the mpurate change on the
kernel command line.

Measurements are taken with a scope watching a gpio line get toggled.

The gpio toggling is not instantaneous, but it is an order of magnitude
less then the udelay times I'm testing, so I'm ignoring it.

I ran three tests for each udelay.

Clock at 600 MHz

udelay(5)   : 6.1, 5.9, 6.1
udelay(10)  : 10.9, 10.7, 10.9
udelay(20)  : 21.0, 20.7, 20.8
udelay(50)  : 50.6, 50.9, 50.7
udelay(100) : 100.3, 100.5, 100.5

Clock at 800 MHz

udelay(5)   : 4.6, 4.4, 4.4
udelay(10)  : 8.4, 8.2, 8.2
udelay(20)  : 15.5, 15.8, 15.5
udelay(50)  : 38.3, 38.0, 38.1
udelay(100) : 75.6, 75.3, 75.4


The usual expectation is that udelay(x) will delay at least x, so
this could be a problem if you are counting on that.

It's easy enough to calculate the value you should use with udelay()
if you know you are changing the clock, i.e. multiply by 4/3 in this
case.

hrtimers() are not affected, but then they aren't too accurate below
300 usec which leaves a gap where you might need udelay.

This is just a heads up for other Gumstix driver developers out there.

It could be this is obvious or well known, but I didn't see anything
from a cursory Google. I never noticed it before.

I just happened to stumble across it today working on some hardware
needing a delay in the 40-60 usec range.

I can post a simple kernel module to demonstrate the problem if
anyone is interested.



--
View this message in context: http://gumstix.8.x6.nabble.com/Kernel-udelay-accuracy-after-mpurate-change-tp4967243.html
Sent from the Gumstix mailing list archive at Nabble.com.

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and
their applications. This 200-page book is written by three acclaimed
leaders in the field. The early access version is available now.
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users



--
Regards,
James

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and
their applications. This 200-page book is written by three acclaimed
leaders in the field. The early access version is available now.
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Kernel udelay() accuracy after mpurate change

rogecol
We run at 800. Will udelay() only be accurate at 400?

Is there a way to fix this?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Kernel udelay() accuracy after mpurate change

adam
In reply to this post by Scott Ellis
Hi Scott, can you post the kernel module? I'd like to test it on Duovero - as I think I may have run into this issue lately. 

Thank you,

Adam


On Wed, May 8, 2013 at 4:15 PM, Scott Ellis [via Gumstix] <[hidden email]> wrote:
This is all from an Overo running a 3.2 kernel.

It seems udelay() does not adjust for the mpurate change on the
kernel command line.

Measurements are taken with a scope watching a gpio line get toggled.

The gpio toggling is not instantaneous, but it is an order of magnitude
less then the udelay times I'm testing, so I'm ignoring it.

I ran three tests for each udelay.

Clock at 600 MHz

udelay(5)   : 6.1, 5.9, 6.1
udelay(10)  : 10.9, 10.7, 10.9
udelay(20)  : 21.0, 20.7, 20.8
udelay(50)  : 50.6, 50.9, 50.7
udelay(100) : 100.3, 100.5, 100.5

Clock at 800 MHz

udelay(5)   : 4.6, 4.4, 4.4
udelay(10)  : 8.4, 8.2, 8.2
udelay(20)  : 15.5, 15.8, 15.5
udelay(50)  : 38.3, 38.0, 38.1
udelay(100) : 75.6, 75.3, 75.4


The usual expectation is that udelay(x) will delay at least x, so
this could be a problem if you are counting on that.

It's easy enough to calculate the value you should use with udelay()
if you know you are changing the clock, i.e. multiply by 4/3 in this
case.

hrtimers() are not affected, but then they aren't too accurate below
300 usec which leaves a gap where you might need udelay.

This is just a heads up for other Gumstix driver developers out there.

It could be this is obvious or well known, but I didn't see anything
from a cursory Google. I never noticed it before.

I just happened to stumble across it today working on some hardware
needing a delay in the 40-60 usec range.

I can post a simple kernel module to demonstrate the problem if
anyone is interested.


If you reply to this email, your message will be added to the discussion below:
http://gumstix.8.x6.nabble.com/Kernel-udelay-accuracy-after-mpurate-change-tp4967243.html
To start a new topic under Gumstix, email [hidden email]
To unsubscribe from Gumstix, click here.
NAML

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Kernel udelay() accuracy after mpurate change

Scott Ellis
This post was updated on .
https://github.com/scottellis/udelay-test

You'll have to change the gpio pin that is toggled for the
duovero.

And I don't think any of the header pins on the Parlor are
muxed for gpio. But that's not hard to do.
Loading...