Add an absolute time reference in hexo

[Nicolas Pouillon]

We need an abstracted method to retrieve the architecture's frequency. This can be useful to:

• know about the real time elapsed
• implement real data rates (some devices use a subdivision of the main clock for generating baudrates, that means we have to know the main clock freq)

This could be declared in hexo, implemented in arch. Depending on the arch, it could be:

• a calibrating loop on ibmpc
• in the fdt for soclib
• depdendant on the arch for simple

Some problems are non-trivial to solve but may be addressed later:

• CPU frequency scaling
• GALS

[becoulet]

Request based device timer API proposal

[becoulet]

A new timer API using request objects as in block and char API could replace the old timer driver API:

• This allows sharing of timer device and allow having multiple requests pending
• Requests can be single shot or periodic
• Requests can use absolute or relative deadline (delays)
• Operations are request queue and request cancel
• This would allow tickless use of timer device by transparent dynamic reconfiguration of counter from current queue content.
• The driver can internally balance requests on multiple hardware timers (queues), useful for better periodic requests handling.
• Timer information must be available (resolution & unit (cycles/seconds)) to let higher kernel services convert between time units.
• Emu arch would be able to implement this using SIGALARM.
• Nice scheduler wrapping could be done as for char and blocks devs, pthread timed primitives would be able to use this as well.

See proposed header.

A cpu_frequency() function could be added in cpu/cpu.h. The value could then come from a configuration token, calibration loop or freq scaling module depending on configuration.

[Nicolas Pouillon]

• I dont see a reasonable use case for dev_timer_get_value(), could this call be dropped ?
• I dont quite see a correct way of handling the mix between cycles and seconds in a DVFS and/or GALS platform
• Could we restrict this API to fractions of seconds ?
  • High level (sleep(), network timeouts, …) are second-based
  • RT deadlines are seen from an external POV, the only timing reference from the outside is the sec
• We should be extra careful when handling a callback returning true, if we re-enqueue the request, it should be done with
  • t_{re_enqueue} = t_{last_deadline} + t_period, not
  • t_{re_enqueue} = t_{last_deadline} + t_period + t_{callback_handling}

A low-level API is still needed to get the current actual clock freq of the core we run the call on.

We probably need a clock driver API (see #55):

• DVFS control for a tile
• enabling / disabling clock devices in µC