Hi Wolfgang.
On 12/07/11 20:36, Graeme Russ wrote:
> As I said, I will have a closer look at the Linux API...
OK, I've had a look at how the Linux API is used - in particular
time_after(). Here is a typical random example (from drivers/spi/ep93xx_spi.c):
timeout = jiffies + msecs_to_jif
Wolfgang, Bill
This thread was getting a little long so I took the liberty to snip the lot ;)
Now, the way I see things we are looking at two entirely different issues -
udelay() and the Timer API. Unfortunately, they are somewhat intertwined
because:
a) Some Architectures/SoCs/Boards etc do no
On 7/15/2011 11:34 AM, Wolfgang Denk wrote:
> Dear "J. William Campbell",
>
> In message<4e208227.6010...@comcast.net> you wrote:
>> If the I2C protocol must be available before interrupts are
>> available, then udelay must be used. In the above examples, there are
>> some loops in i2c and
Dear "J. William Campbell",
In message <4e208227.6010...@comcast.net> you wrote:
>
>If the I2C protocol must be available before interrupts are
> available, then udelay must be used. In the above examples, there are
> some loops in i2c and spi that appear to be waiting a full second. I
On 7/15/2011 12:17 AM, Wolfgang Denk wrote:
> Dear "J. William Campbell",
>
> In message<4e1f8127.8030...@comcast.net> you wrote:
>> I am pretty sure that is long enough for someone to notice. . I would be
>> interested in seeing an example of such code as you refer to. Could you
>> point me to on
Dear "J. William Campbell",
In message <4e1f8127.8030...@comcast.net> you wrote:
>
> I am pretty sure that is long enough for someone to notice. . I would be
> interested in seeing an example of such code as you refer to. Could you
> point me to one, because it seems to me that the only reason t
On 7/14/2011 12:41 PM, Wolfgang Denk wrote:
> Dear "J. William Campbell",
>
> In message<4e1cf2e0.1030...@comcast.net> you wrote:
>> Yes, this is true. However, the time_elapsed_since routine can do
>> this dynamically (i.e. add twice the timer resolution) . I think you had
> That would IM
Dear "J. William Campbell",
In message <4e1cf2e0.1030...@comcast.net> you wrote:
>
>Yes, this is true. However, the time_elapsed_since routine can do
> this dynamically (i.e. add twice the timer resolution) . I think you had
That would IMHO be a very bad idea. We have a number of place
Dear Graeme Russ,
In message <4e1ce6ec.1030...@gmail.com> you wrote:
>
> Also remember that if we are looking to inherit nanosecond time base from
> Linux, it will be extremely unlikely that every board will support a native
> 1ns clock source. Typical examples would be 33MHz (~30ns) or 66MHz (~1
On 7/12/2011 5:33 PM, Graeme Russ wrote:
> Hi Reinhard,
>
> On 13/07/11 02:08, Reinhard Meyer wrote:
>> Dear J. William Campbell, All
> [snip]
>
>> Lets just keep the current functions udelay(us) and u32 get_timer(), the
>> latter maybe without parameter. Remove all *masked() and *reset() functions
Hi Reinhard,
On 13/07/11 02:08, Reinhard Meyer wrote:
> Dear J. William Campbell, All
[snip]
> Lets just keep the current functions udelay(us) and u32 get_timer(), the
> latter maybe without parameter. Remove all *masked() and *reset() functions
This is happening and has Wolfgang's 100% support
Hi Wolfgang,
On 12/07/11 23:10, Wolfgang Denk wrote:
> Dear Graeme Russ,
>
> In message <4e1c23b8.6020...@gmail.com> you wrote:
>>
>> So how do we deal with Nios2? It is what caused such a deep investigation
>> into the timer API. We have three choices I can think of off the top of my
>> head:
>>
On 7/12/2011 8:23 AM, Scott McNutt wrote:
> Dear Wolfgang
>
> Wolfgang Denk wrote:
>
>> What exactly is the reason that we cannot have better timer
>> resolutions in NIOS?
> You _can_ have better timer resolutions in Nios. However, there
> are legacy systems that implement timer(s) with a fixed per
Dear J. William Campbell, All
>I have two comments regarding this discussion so far. First, I
> think using the "time" function name at all is a VERY BAD idea. People
> will confuse it with the "normal" c library function that returns the
> time of day since the epoch. One may say that
Dear Wolfgang
Wolfgang Denk wrote:
> What exactly is the reason that we cannot have better timer
> resolutions in NIOS?
You _can_ have better timer resolutions in Nios. However, there
are legacy systems that implement timer(s) with a fixed period
of 10 msec. The use of such implementations is ve
On 7/12/2011 6:10 AM, Wolfgang Denk wrote:
> Dear Graeme Russ,
>
> Do we? What exactly is the needed resolution of the underlying
> hardware timer? So far, it appears sufficient to have it ticking with
> 1000 Hz or more. Are there really systems that cannot provide that?
> The only architecture
Dear Graeme Russ,
In message <4e1c23b8.6020...@gmail.com> you wrote:
>
> So how do we deal with Nios2? It is what caused such a deep investigation
> into the timer API. We have three choices I can think of off the top of my
> head:
>
> 1. Move the whole timer API up to the architecture level an
Hi Wolfgang,
Thanks for the renewed feedback
On 12/07/11 18:49, Wolfgang Denk wrote:
> Dear Graeme,
>
> I'm trying to summarize your last 3 postings here.
>
> In message <4e1b7e0c.8000...@gmail.com> you wrote:
>>
>>> First, I would very much like to get rid of this "_ms" thing. We
>>> should r
Dear Graeme,
I'm trying to summarize your last 3 postings here.
In message <4e1b7e0c.8000...@gmail.com> you wrote:
>
> > First, I would very much like to get rid of this "_ms" thing. We
> > should rather make very clear in the documentation which unit the time
> > services are based on, and use
On 12/07/11 09:36, Graeme Russ wrote:
> On 12/07/11 07:56, Wolfgang Denk wrote:
>> Dear Graeme Russ,
[snip]
>> Having this still in mind, I took a look across the fence to what
>> barebox is doing. Guess what? From "common/clock.c":
>>
>> * clock.c - generic clocksource implementation
>>
On 12/07/11 07:56, Wolfgang Denk wrote:
> Dear Graeme Russ,
>
[snip]
> One thing I always wanted to do in the previous discussion was to check
> what other projects (like Linux, barebox, etc.) are doing in this area.
> I think it is worth reading the Linux Documentation/timers/highres.txt
> docu
Hi Wolfgang,
On 12/07/11 07:56, Wolfgang Denk wrote:
> Dear Graeme Russ,
>
> In message <1309261269-4363-1-git-send-email-graeme.r...@gmail.com> you wrote:
>> The following series is a work-in-progress revamp of the timer API. The aim
>> is to create a new userland API consisting of the following
Dear Graeme Russ,
In message <1309261269-4363-1-git-send-email-graeme.r...@gmail.com> you wrote:
> The following series is a work-in-progress revamp of the timer API. The aim
> is to create a new userland API consisting of the following functions
> (along with a few arch level support functions):
Hi Greame,
Le 08/07/2011 02:25, Graeme Russ a écrit :
> 1) I understand that you would like each individual patch in the series to
> have the in-reply-to header set to the individual parent patch and not have
> the whole series in-reply-to the first (00/16) patch? (It will be a bit of
> a PITA to
On 28/06/11 21:40, Graeme Russ wrote:
> The following series is a work-in-progress revamp of the timer API. The aim
> is to create a new userland API consisting of the following functions
> (along with a few arch level support functions):
>
[snip]
> Graeme Russ (16):
> [Timer]Fix misuse of ARM
Hi Mike,
On Wed, Jun 29, 2011 at 3:08 PM, Mike Frysinger wrote:
> for future reference, could we use the "foo: " style in subjects instead of
> "[foo]". git likes to eat "[...]" automatically and i find it hard to quickly
> parse. it's an abomination on my eyes.
>
> -[PATCH v1 (WIP) 00/16] [Tim
for future reference, could we use the "foo: " style in subjects instead of
"[foo]". git likes to eat "[...]" automatically and i find it hard to quickly
parse. it's an abomination on my eyes.
-[PATCH v1 (WIP) 00/16] [Timer]API Rewrite
+[PATCH/WIP 00/16] timer: API Rewrite
-mike
signature.as
Hi All,
[snip]
>
> Graeme Russ (16):
> [Timer]Fix misuse of ARM *timer_masked() functions outside arch/arm
> [Timer]Remove calls to set_timer outside arch/
> [Timer]Remove calls to set_timer in arch/
> [Timer]Allow reset_timer() only for Nios2
> [Timer]Remove reset_timer() for non-Nios2 arch
The following series is a work-in-progress revamp of the timer API. The aim
is to create a new userland API consisting of the following functions
(along with a few arch level support functions):
u32 time_now_ms(void);
u32 time_since_ms(u32 from, u32 to);
u32 time_max_since_ms(u32 from, u32 to);
T
29 matches
Mail list logo
