Re: m68k using deprecated internal APIs?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, 28 Oct 2018, Geert Uytterhoeven wrote:


The example I gave was GENERIC_CLOCKEVENTS on m68, which is 
supported on most but not all machines there.

That suggests that the removal of just those machines would suffice 
(as opposed to the removal of the entire arch).

Also, Documentation/features/time/clockevents/arch-support.txt says,
    |        m68k: |  ok  |

These two observations make me wonder whether the clockevents feature 
is related to the discussion quoted above (?)

GENERIC_CLOCKEVENTS is selected only for a few Coldfire CPU types.


!GENERIC_CLOCKEVENTS implies PREEMPT_NONE, and disables the "Timers 
subsystem" (i.e. the NO_HZ config options), but it works fine -- I was 
able to convert the Mac port to !ARCH_USES_GETTIMEOFFSET && 
!GENERIC_CLOCKEVENTS. (Like many of the Coldfire CPU types.)

You can see those patches here,
https://github.com/fthain/linux/commits/mac68k-queue/

Note that !ARCH_USES_GETTIMEOFFSET is a build-time choice, meaning that 
all platforms need to be converted together.

Also, some platforms will need to adopt the clocksource API, otherwise the 
built-in "jiffies" clocksource will get used, causing a regression in 
timer accuracy.

Conversion to the clocksource API is straight-forward where the platform 
already implements arch_gettimeoffset. The conversion is discussed in 
include/linux/time.h:

/* Some architectures do not supply their own clocksource.
 * This is mainly the case in architectures that get their
 * inter-tick times by reading the counter on their interval
 * timer. Since these timers wrap every tick, they're not really
 * useful as clocksources. Wrapping them to act like one is possible
 * but not very efficient. So we provide a callout these arches
 * can implement for use with the jiffies clocksource to provide
 * finer then tick granular time.
 */

(Not sure what is meant by "not very efficient" here.)

Certain 680x0 platforms do not implement arch_gettimeoffset: apollo, q40, 
sun3, sun3x. These platforms can fall back on the "jiffies" clocksource 
with no loss of timer accuracy, so conversion for these platforms is 
trivial.

Should I continue with the clocksource API conversion for the other 
platforms: amiga, atari, bvme6000, hp300, mvme147, mvme16x? This would 
allow for removal of "select ARCH_USES_GETTIMEOFFSET" (and satisfy 
Documentation/features/time/modern-timekeeping) without loss of timer 
accuracy.

Alternatively, we could defer the clocksource API conversion, leaving it 
up to the platform maintainers (who can actually test the driver changes). 
But that would mean that many platforms would suffer a regression in timer 
accuracy upon removal of arch_gettimeoffset.

-- 



[Index of Archives]     [Video for Linux]     [Yosemite News]     [Linux S/390]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux