1. 24 Jun, 2019 7 commits
    • Philippe Gerum's avatar
      ipipe: timer: do not interpose on undefined handlers · 3782a83a
      Philippe Gerum authored
      There is no point in interposing on clock chip handlers for which
      there was no support originally. In some cases (oneshot_stopped), we
      may even get a kernel fault, jumping to a NULL address.
      
      Interpose on non-NULL original handlers only.
      3782a83a
    • Philippe Gerum's avatar
      ipipe: timer: resume hardware operations in oneshot handler · 6b973178
      Philippe Gerum authored
      Although we won't allow disabling the hardware when the clock event
      logic switches a device to stopped mode - so that we won't affect the
      timer logic running on the head stage unexpectedly -, we still have to
      enable the hardware when switched (back) to oneshot mode, since it may
      have been stopped prior to interposing on the device in
      ipipe_timer_start().
      
      Failing to do so would leave the hardware shut down for both regular
      and Xenomai operations, with no mean to bring it up again.
      6b973178
    • Philippe Gerum's avatar
    • Philippe Gerum's avatar
      ipipe: tick: revive the host tick after device grab · 30b841f9
      Philippe Gerum authored
      Once the device was grabbed by ipipe_timer_start(), any pending host
      tick programmed in the hardware is basically lost, unknown to the
      co-kernel implementing the proxy handlers.
      
      Schedule a host event with the latest target time programmed to have
      the co-kernel know about the pending tick.
      30b841f9
    • Philippe Gerum's avatar
      ipipe: tick: cap timer_set op to device supported max · 0c9e3366
      Philippe Gerum authored
      At this chance, switch the min_delay_tick value to unsigned long to
      match the corresponding clockevent definition.
      0c9e3366
    • Philippe Gerum's avatar
      ipipe: tick: out-of-band devices require GENERIC_CLOCKEVENTS · 8c5fcd77
      Philippe Gerum authored
      Drop the legacy support for architectures not enabling the generic
      clock event framework, which would only provide periodic timing.
      
      We don't support any of those archs, and there is no point in running
      a Xenomai co-kernel on a hardware not capable of handling oneshot
      timing requests.
      8c5fcd77
    • Philippe Gerum's avatar
      ipipe: add out-of-band tick device · 1ff26ed7
      Philippe Gerum authored
      The out-of-band tick device manages the timer hardware by interposing
      on selected clockevent handlers transparently, so that a client domain
      (e.g. a co-kernel) eventually controls such hardware for scheduling
      the high-precision timer events it needs to. Those events are
      delivered to out-of-hand activities running on the head stage,
      unimpeded by (only virtually) interrupt-free sections of the regular
      kernel code.
      
      This commit introduces the generic API for controlling the out-of-band
      tick device from a co-kernel. It also provides for the internal API
      clock event chip drivers should use for enabling high-precision
      timing for their hardware.
      1ff26ed7