Re: [Freemint-discuss] [Freemint-list] Broken udelay() for m68000

[David G. <dga...@gm...>]

Yesterday I sent the email below to the list address at atari-forge, I
didn't watch that the email I was answering was sent to the the old
list address.
Today it bounced so I send it again to the right address.

2018-02-17 10:04 GMT+01:00 David Gálvez <dga...@gm...>:
> 2017-10-16 3:57 GMT+02:00 Miro Kropáček <mir...@gm...>:
>> After some study, it seems it isn't that bad (I think most of you were aware
>> of it): the delay functions are calibrated, quite precisely actually. That
>> loops_per_sec variable is actually a result of such calibration.
>>
>> So the problem is that m68000 code ignores it. I think David is right, the
>> magic formula used in the linux kernel is supposed to work on all m68ks, not
>> only ColdFire (see the comment, "simpler m68k").
>>
>> On m68000, the code is quite chatty:
>>
>>      3a4:       206a 001c       moveal %a2@(28),%a0
>>      3a8:       4878 00c8       pea c8 <oldSR-0x1c>
>>      3ac:       2f10            movel %a0@,%sp@-
>>      3ae:       4e93            jsr %a3@
>>      3b0:       508f            addql #8,%sp
>>      3b2:       720b            moveq #11,%d1
>>      3b4:       e2a8            lsrl %d1,%d0
>>      3b6:       2200            movel %d0,%d1
>>      3b8:       d280            addl %d0,%d1
>>      3ba:       d280            addl %d0,%d1
>>      3bc:       2801            movel %d1,%d4
>>      3be:       e98c            lsll #4,%d4
>>      3c0:       d284            addl %d4,%d1
>>      3c2:       2801            movel %d1,%d4
>>      3c4:       e18c            lsll #8,%d4
>>      3c6:       d284            addl %d4,%d1
>>      3c8:       e789            lsll #3,%d1
>>      3ca:       d081            addl %d1,%d0
>>      3cc:       ec88            lsrl #6,%d0
>>
>> (a3 points to ___udivsi3)
>>
>> However we should use this code also for 68060 and not only for CF as mul
>> ea,dr:dq is not implemented on 060 (leading to a huge performance bottleneck
>> I imagine).
>>
>
> I've just pushed a commit to make 68000 builds to use "real" delays
> and fix this situation.
>
> Some drivers that were adjusted to the old delay method could break,
> For what I could see they're usb.km, storage.udd and asix.xif or the
> TOS variant of them (only 68000 builds).
> I've asked in AF for testers but I didn't get too much feedback, I
> decided to push anyway I don't want the commits to end dying in my
> hard drive as already has happened to me in the past.
> If you read users complaining about these drivers malfunction with
> recent kernel versions keep in mind this commit could be a reason.