Re: [MiNT] [PATCH] Add udelay routine for ColdFire

[David Gálvez <dgalvez75@gmail.com>]

Hi Markus!

Thanks for looking into the patch.

2014-04-24 8:08 GMT+02:00 Markus Fröschle <markus@mubf.de>:
>
> Am 23.04.2014 um 19:21 schrieb David Gálvez <dgalvez75@gmail.com>:
>
>> Now the function udelay( ) compiled for ColdFire use the same routine
>> as the 68000 CPU, it just loops so many times as the microseconds
>> requested, of course this is for the faster CF CPU not enough and
>> udelay( ) returns earlier than it should.
>>
>> Code imported from Linux m68k-nommu.
>>
>> Please Alan if it's OK for you commit.
>> <udelay_20140423.diff>
>
> Hi David,
>
> really appreciate your Coldfire efforts, but this looks a bit overengineered to me.
> To my knowledge, all of the Coldfire MCUs (v4e) that are supported by TOS/MiNT
> have two slice timers that are free running with bus frequency on EmuTOS as well
> as on FireTOS which actually makes busy waiting microseconds much easier than
> your implementation:

When doing the patch I thought for half a second about timers but then
I thought that if for another machines MiNT doesn't use them I
shouldn't bother.

> /*
>  * wait for the specified number of us on slice timer 0.
>  */
> void udelay(uint32_t us)
> {
>     int32_t target = MCF_SLT_SCNT(0) - (us * (SYSCLK / 1000));
>
>     while (MCF_SLT_SCNT(0) - target > 0);
> }
>

A couple of questions about the code above:

- Where comes from the 1/1000 component in (SYSCLK / 1000)?
- If target variable is calculated just before the counter expires and
then reloaded with the terminal count value again, Couldn't this
situation give delays much greater than requested?

> The Linux code is probably supposed to support all Coldfire versions including those
> that don’t have the SLT timers so I assume that is the reason its more general. Since
> we’ll probably never need to support earlier Coldfires (if possible at all), I assume we
> can safely use the simpler (and - due to cache effects - most likely more accurate) version?
>

Another thing that must be taken into account with this approach are
Evaluation Boards.
FireTOS use STL 0 for system timer interrupt on EVBs.
Also System bus frequency (SYSCLK in the code above) is 133 for the
FireBee but looking at the FireTOS sources It seems that there are
some EVB (548X??) which have a 100 MHz bus. So the kernel should
figure out where is running on to give SYSCLK the correct value, or we
should make this configurable and make a specific kernel for those
boards.