Dear Reinhard Meyer,
In message <4ccf1caf.1020...@emk-elektronik.de> you wrote:
>
> For efficiency it would help if CONFIG_SYS_HZ would be allowed to be in the
> range
> of 1000 - 2000 Hz (or 700 - 1400), so on any hardware a simple shift would do
> for
> get_timer(). Of course the constant CONF
On 01.11.2010 14:47, J. William Campbell wrote:
> On 10/27/2010 11:02 PM, Reinhard Meyer wrote:
>> Dear J. William Campbell,
>>> Hi All,
>>>
>>> I am pretty sure the migration to 64 bits was caused by 1) people not
>>> understanding that the timer operating on time DIFFERENCES would work fine
>>>
On 10/27/2010 11:02 PM, Reinhard Meyer wrote:
> Dear J. William Campbell,
>> Hi All,
>>
>> I am pretty sure the migration to 64 bits was caused by 1) people not
>> understanding that the timer operating on time DIFFERENCES would work
>> fine even if the underlying timer wrapped around (most proba
Dear J. William Campbell,
> Hi All,
>
> I am pretty sure the migration to 64 bits was caused by 1) people not
> understanding that the timer operating on time DIFFERENCES would work fine
> even if the underlying timer wrapped around (most probable problem) and
> possibly 2) broken timer function
On 10/26/2010 6:33 AM, Reinhard Meyer wrote:
> Dear Wolfgang Denk,
>>> Then the define CONFIG_SYS_HZ should not be in every.h since that
>>> suggests that a board developer has some freedom there...
>> Agreed - there are historical reasons this has ever been changable at
>> all.
>>
>>> and MOST IMP
On 26.10.2010 18:26, Wolfgang Denk wrote:
> Dear Nishanth Menon,
>
> In message<4cc6f23a.2040...@ti.com> you wrote:
>>
>>> No. This code is always wrong. Please fix it as described.
>> Apologies on being a dudhead, I suppose you mean the following:
>>
>> ulong start;
>> start = get_timer(0);
>> wh
Dear Nishanth Menon,
In message <4cc6f23a.2040...@ti.com> you wrote:
>
> > No. This code is always wrong. Please fix it as described.
> Apologies on being a dudhead, I suppose you mean the following:
>
> ulong start;
> start = get_timer(0);
> while (!(readl(&mmc_base->stat) & CC_MASK)) {
>
Wolfgang Denk had written, on 10/26/2010 10:17 AM, the following:
> Dear Nishanth Menon,
>
> In message <4cc6efb1.9000...@ti.com> you wrote:
>> uint64_t etime; /* actually this could be u32 */
>>
>> etime = get_ticks() + usec2ticks(MAX_RETRY_US);
>> while (!(readl(&mmc_base->stat) & CC_MASK)) {
>>
Dear Nishanth Menon,
In message <4cc6efb1.9000...@ti.com> you wrote:
>
> uint64_t etime; /* actually this could be u32 */
>
> etime = get_ticks() + usec2ticks(MAX_RETRY_US);
> while (!(readl(&mmc_base->stat) & CC_MASK)) {
> if (get_ticks() <= etime) {
> printf("%s: timed
Reinhard Meyer had written, on 10/26/2010 02:57 AM, the following:
> Wolfgang Denk schrieb:
>> Dear Reinhard Meyer,
>>
>> In message <4cc67ca1.9090...@emk-elektronik.de> you wrote:
>>> If implemented with true 64 bits for get_ticks() that function is useable
>>> for timeout programming:
>>>
>>>
Dear Wolfgang Denk,
>> Then the define CONFIG_SYS_HZ should not be in every .h since that
>> suggests that a board developer has some freedom there...
>
> Agreed - there are historical reasons this has ever been changable at
> all.
>
>> and MOST IMPORTANT that some implementations of udelay() mig
Dear Reinhard Meyer,
In message <4cc6aadc.8050...@emk-elektronik.de> you wrote:
>
> Then the define CONFIG_SYS_HZ should not be in every .h since that
> suggests that a board developer has some freedom there...
Agreed - there are historical reasons this has ever been changable at
all.
> and MOS
Dear Wolfgang Denk,
>> Actually CONFIG_SYS_HZ (whatever that is).
>
> It is defined to be 1000.
Ok, game with that.
Then the define CONFIG_SYS_HZ should not be in every .h since that
suggests that a board developer has some freedom there...
>> I think it is necessary to summarize all implicit
Dear Reinhard Meyer,
In message <4cc68a07.6050...@emk-elektronik.de> you wrote:
>
> > Also, this code _is_ a bit different, as "get_timer(0)" makes sure
> > the counter starts ticking again at 0
>
> Nope, it does not reset the counter itself. It returns the current
> counter value (recalculated i
Wolfgang Denk schrieb:
> Dear Reinhard Meyer,
>
> In message <4cc67ca1.9090...@emk-elektronik.de> you wrote:
>> If implemented with true 64 bits for get_ticks() that function is useable
>> for timeout programming:
>>
>> ulong timeval = get_timer (0);
>>
>> do {
>> ...
>>
Dear Reinhard Meyer,
In message <4cc67ca1.9090...@emk-elektronik.de> you wrote:
>
> If implemented with true 64 bits for get_ticks() that function is useable
> for timeout programming:
>
> ulong timeval = get_timer (0);
>
> do {
> ...
> } while (get_timer (timeva
I just had a look at other ARM implementations of timer.c.
Some have a colourful mix of 32 and 64 bits values, resulting
in some 64 bit timer functions returning the upper 32 bits always
cleared.
Some implement udelay() in the "while (xxxtime() < endtime);" variant.
I will fix this for at91 and
17 matches
Mail list logo
