[U-Boot] [RFC][Timer API] Revised Specification - Implementation details

[Graeme Russ]

Hi Wolfgang,

On Tue, May 31, 2011 at 4:03 PM, Wolfgang Denk <wd at denx.de> wrote:
> Dear Graeme Russ,
>
> In message <BANLkTikZUkk1EaYqCg=5mB2npva2iE6Lew at mail.gmail.com> you wrote:
>>
>> Don't forget the API will have a get_current_ms() so we can do duration
>
> I don't think we will have this.
>
> We have get_timer() (or, as recently suggested, renamed it into
> time_read() or similar).  We don't need yet another function that
> dioes the same just by a different name.

No, I did not mean a new function which does the same as an existing
function - I just meant there would be a function to give us current ms
which means any 'wait_until_ms(x)' style function is ripe for 'abuse'

>> bypassing the resolution correction. If time_reached() did the resolution
>> correction, would this solve the problem of API misuse (yes, I know it puts
>> a complicated calculation back in the loop)
>
> Complicated?  Come on, guys.
>
>
> And please don't forget thatthese are usually delay or timeout loops,
> so who cares how long it takes?
>
>> Yetch! - We will not be exposing ticks!
>
> Oh, I'm no so sure about this.  We will not use it in common code, but
> the interface should be available for special purposes.

Well yes, the suggested API does expose ticks via get_ticks(). And my
current demo implementation also stores ticks in global data as a storage
for 'last ticks' in order to do tick deltas to calculate us/ms deltas...

>> I like simple as much as the next guy - I also like hard to misuse ;)
>
> NAK.  What you today consider "misuse" might actually be a clever
> solution to my problem tomorrow.

Well now that we are doing much more stringent peer reviews on new code
(and re-written code) I guess the misuse argument does become a little bit
irrelavent

> An SPI is good then the standard solution actually covers 99.9% of all
> use cases and is so convenient to use that you don't even think about
> doing it differently.  But it is extremely useful when you also can
> use it for things the designer/implementor never even dreamt of.
>
> So don't try to prevent "misuse".

OK

Regards,

Graeme