On 21/08/14 15:51, Gedare Bloom wrote:
On Thu, Aug 21, 2014 at 3:03 AM, Sebastian Huber
<sebastian.hu...@embedded-brains.de> wrote:
>On 20/08/14 16:05, Joel Sherrill wrote:
>>
>>
>>On 8/20/2014 8:59 AM, Sebastian Huber wrote:
>>>
>>>On 20/08/14 15:53, Joel Sherrill wrote:
>>>>
>>>>On 8/20/2014 8:12 AM, Daniel Cederman wrote:
>>>>>>
>>>>>>Hi,
>>>>>>
>>>>>>We are currently experiencing this bug reported by Sebastian Huber and
>>>>>>I
>>>>>>could not find any discussion on it on the list. I'm guessing that the
>>>>>>simple solution of moving the call to Clock_driver_support_at_tick()
>>>>>>to
>>>>>>the critical section of _TOD_Tickle_ticks() is not an acceptable
>>>>>>solution, given that it would be a call from score to the BSP?
>>>>
>>>>I don't have a problem with it. Some documentation may need to be
>>>>updated to
>>>>reflect the environment in which the bsp hook is called but I think it
>>>>is pretty
>>>>obvious it is called when an accurate timestamp is wanted.
>>>
>>>Its not that easy. This Clock_driver_support_at_tick() is part of
>>>clockdrv_shell.h. What we need is a proper clock driver API.
>>>
>>Grrr.. I should have actually re-read the PR and not tried to remember
>>the issue.
>>Sorry.:(
>>
>>It looks like the entire sequence needs to be locked. What that exposes
>>is
>>another matter.
>>
>
>The clock handling is entirely broken on SMP and not scalable. Our clock
>infrastructure is only good enough for uni-processor systems, but even here
>the usage of nanosecond timestamps is suboptimal. I would rather use
>something like the FreeBSD time hands:
>
>http://phk.freebsd.dk/pubs/timecounter.pdf
>
Nice. It looks like it would take:
1) Convert the 64-bit timestamps into bintime: a split time_t
'seconds' + uint64_t 'frac' format. The math is shown in the paper.
2) A lock-free ring buffer for the timehands.
3) The timecounter structure that describes the hw clock source, and a
way to register timecounters from BSPs.
4) Rewrite tick handling to do the refresh operation.
Did I miss anything?
5) Adapt all clock drivers or provide a compatibility layer. The requirements
on the counter hardware seem to be weak, but its not always possible to meet
them. For example the classic PowerPC decrementer cannot be used, so we would
need alternatives from some BSPs.
6) Merge this with the CPU counter support. The timecounter implementation
requires counters that count up and that differences can be computed via (t1 -
t0) & mask. For the CPU counter I used a more general approach with the CPU
counter difference function. We should only use one method. I am in favor of
using the FreeBSD code one-to-one.
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
