I2C Driver testcase

[punit vara]

Hi Sebastian !

You have suggested me following i2c drivers which follows /dev/i2c framwork :

https://git.rtems.org/rtems/tree/c/src/lib/libbsp/arm/atsam/i2c/atsam_i2c_bus.c
https://git.rtems.org/rtems/tree/c/src/lib/libbsp/arm/xilinx-zynq/i2c/cadence-i2c.c

Can you please provide link to the test case application code for any
of above driver ?

Thanks,
Punit Vara
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

nanosleep.c remarks

[Pavel Pisa]

Hello Gedare and Sebastian,

as the clock_nanosleep is in the place now, I am trying to
analyze consequences and I have some questions.

The first one, why is _Nanosleep_Pseudo_queue required
there. nanosleep is critical function for realtime and
it is quite possible that many threads on more CPUs
us that concurrently. But _Thread_queue_Enqueue calls
_Thread_queue_Acquire( the_thread_queue, _context.Lock_context );
unconditionally. This leads to _SMP_ticket_lock_Acquire on SMP.
So this means that all calls are serialized and contend
for cache lines. But I do not understand why queue
used normally for wakeup request distribution is required
for nanosleep. Original code has only selected appropriate
state and activated scheduller

Original nanosleep

  /*
   *  Block for the desired amount of time
   */
  _Thread_Disable_dispatch();
executing = _Thread_Executing;
_Thread_Set_state(
  executing,
  STATES_DELAYING | STATES_INTERRUPTIBLE_BY_SIGNAL
);
_Watchdog_Initialize(
  >Timer,
  _Thread_Delay_ended,
  0,
  executing
);
_Watchdog_Insert_ticks( >Timer, ticks );
  _Thread_Enable_dispatch();

Actual nanosleep

  /*
   *  Block for the desired amount of time
   */
  _Thread_queue_Enqueue(
&_Nanosleep_Pseudo_queue,
&_Thread_queue_Operations_FIFO,
executing,
STATES_DELAYING | STATES_INTERRUPTIBLE_BY_SIGNAL,
ticks,
discipline,
1
  );

But if simple _Thread_Set_state approach is not supported then
how is it that it is still used in rtems_task_wake_after

rtems_status_code rtems_task_wake_after(
  rtems_interval ticks
)
{
  /*
   * It is critical to obtain the executing thread after thread dispatching is
   * disabled on SMP configurations.
   */
  Thread_Control  *executing;
  Per_CPU_Control *cpu_self;

  cpu_self = _Thread_Dispatch_disable();
executing = _Thread_Executing;

if ( ticks == 0 ) {
  _Thread_Yield( executing );
} else {
  _Thread_Set_state( executing, STATES_DELAYING );
  _Thread_Wait_flags_set( executing, THREAD_WAIT_STATE_BLOCKED );
  _Thread_Timer_insert_relative(
executing,
cpu_self,
_Thread_Timeout,
ticks
  );
}
  _Thread_Dispatch_enable( cpu_self );
  return RTEMS_SUCCESSFUL;
}

Then the time stuff. 

nanosleep_helper() does not distinguish between CLOCK_REALTIME
and CLOCK_MONOTONIC when it computes remaining time (rmtp).
But the intention of this field is that if you call again
nanoslepp/clock_nanosleep with same parameters and rtmp
used as time to wait (in case of TIMER_ABSTIME is not set) then
the final wake time should be +/- same as if there has been
no interruption. If we consider POSIX required behavior/difference
between CLOCK_REALTIME and CLOCK_MONOTONIC and possibility
to adjust realtime clock then it would not work as expected.

By the way, _Timespec_From_ticks works expected way only for
first 1.19 hour after boot if used for absolute time (not used
that way in nanosleep).
For relative time, If the nanosleep is used for longer delay
than 4294 seconds then rtmp the result is complete garbage

void _Timespec_From_ticks(
  uint32_t ticks,
  struct timespec *time
)
{
  uint32_tusecs;

  usecs = ticks * rtems_configuration_get_microseconds_per_tick();

  time->tv_sec  = usecs / TOD_MICROSECONDS_PER_SECOND;
  time->tv_nsec = (usecs % TOD_MICROSECONDS_PER_SECOND) *
TOD_NANOSECONDS_PER_MICROSECOND;
}

If we consider that crystal oscillator is not perfect then
value of rtems_configuration_get_microseconds_per_tick has to be
tuned runtime but problem is that to not shift time by change
of scale if it is not changed at ticks == 0, it means
to use y = a * x + b there and at each time a from a1 to a2
is changed change b such that a2 * x + b2 = a1 * x + b1
to ensure tick to usec monotonicity for conversion of
monotonic time from ticks to timespec.

Another problem is that for higher frequency tick or ting time
source is the value rtems_configuration_get_microseconds_per_tick
is small so relative precision is insufficient.

For clock_nanosleep we get to _TOD_Absolute_timeout_to_ticks
which calls for CLOCK_MONOTONIC in

I have mostly lost track in the call chain there.
bintime2timespec is provided by NewLib as part of BSD time
framework introduction

https://devel.rtems.org/ticket/2271
https://www.daemon-systems.org/man/timecounter.9.html

Structure struct timecounter seems to be almost sane from
the documentation. But u_int64_t tc_frequency without
shifting right requires unnecessarily wide multiplication
or even worse division and relative resolution can be
low for some cases.

I am trying to study the code

static inline void _TOD_Get_zero_based_uptime_as_timespec(
  struct timespec *time
)
{
  _Timecounter_Nanouptime( time );
  --time->tv_sec;
}

where seconds decrement seems suspicious to me.

There seems to be data structures for precise time computation
and synchronization (sys/timeffc.h, etc.) but I  am not sure
if 

Re: [PATCH 2/4] sys/mman.h: New file. Clean up and add supporting stubs

[Joel Sherrill]

It makes sense to me. Chris identified some mmap capabilities that could be
implemented on normal Barr metal RTEMS but when paravirtualized, we can use
kernel or hypervisor services to support the actual dirty work. But our
code still needs to properly track mmaps and shm_open regions so the unmap
or close is error checked correctly

On Jul 29, 2016 8:07 PM, "Gedare Bloom"  wrote:
>
> On Wed, Nov 19, 2014 at 5:04 PM, Joel Sherrill
>  wrote:
> >
> > On 11/19/2014 2:55 PM, Gedare Bloom wrote:
> >> Is this the same one that Chris has had in use before? (I think that
> >> is who had one in use..)
> > Yes. You wanted it in rtems to avoid me having to add a prototype to a
file
> > to avoid a warning.
> >
> I'm looking at implementing/stubbing some more mman functions. While I
> do this, does it make sense to relocate this mman.h into
> newlib/libc/sys/rtems/include/sys/mman.h?
>
> > I didn't integrate his implementation but only his .h file and stubs.
His
> > implementation will need the addition of tests and code in confdefs.h.
> >
> I may integrate his implementation as part of my effort.
>
> > --joel
> >
> >> -Gedare
> >>
> >> On Wed, Nov 19, 2014 at 2:59 PM, Joel Sherrill
> >>  wrote:
> >>> * Makefile.am updated and preinstall.am regenerated.
> >>> * mprotect.c had a prototype removed now that we have mman.h
> >>> * mmap.c, munmap.c: New stub files.
> >>> ---
> >>>  cpukit/posix/Makefile.am|   5 ++
> >>>  cpukit/posix/include/sys/mman.h | 189

> >>>  cpukit/posix/preinstall.am  |   9 ++
> >>>  cpukit/posix/src/mmap.c |  26 ++
> >>>  cpukit/posix/src/mprotect.c |  10 +--
> >>>  cpukit/posix/src/munmap.c   |  30 +++
> >>>  6 files changed, 261 insertions(+), 8 deletions(-)
> >>>  create mode 100644 cpukit/posix/include/sys/mman.h
> >>>  create mode 100644 cpukit/posix/src/mmap.c
> >>>  create mode 100644 cpukit/posix/src/munmap.c
> >>>
> >>> diff --git a/cpukit/posix/Makefile.am b/cpukit/posix/Makefile.am
> >>> index 346b65a..b3be07c 100644
> >>> --- a/cpukit/posix/Makefile.am
> >>> +++ b/cpukit/posix/Makefile.am
> >>> @@ -21,6 +21,9 @@ include_rtems_posix_HEADERS +=
include/rtems/posix/keyimpl.h
> >>>  include_rtems_posix_HEADERS += include/rtems/posix/config.h
> >>>  include_rtems_posix_HEADERS += include/rtems/posix/posixapi.h
> >>>
> >>> +include_sysdir = $(includedir)/sys
> >>> +include_sys_HEADERS = include/sys/mman.h
> >>> +
> >>>  if HAS_PTHREADS
> >>>  # include
> >>>  include_HEADERS = include/aio.h
> >>> @@ -91,7 +94,9 @@ libposix_a_SOURCES += src/cond.c
src/condattrdestroy.c \
> >>>  src/condtimedwait.c src/condwait.c src/condwaitsupp.c
src/condget.c
> >>>
> >>>  ## MEMORY_C_FILES
> >>> +libposix_a_SOURCES += src/mmap.c
> >>>  libposix_a_SOURCES += src/mprotect.c
> >>> +libposix_a_SOURCES += src/munmap.c
> >>>
> >>>  ## MESSAGE_QUEUE_C_FILES
> >>>  libposix_a_SOURCES += src/mqueue.c src/mqueueclose.c \
> >>> diff --git a/cpukit/posix/include/sys/mman.h
b/cpukit/posix/include/sys/mman.h
> >>> new file mode 100644
> >>> index 000..ddf34cc
> >>> --- /dev/null
> >>> +++ b/cpukit/posix/include/sys/mman.h
> >>> @@ -0,0 +1,189 @@
> >>> +/* $NetBSD: mman.h,v 1.36 2005/09/13 01:42:51 christos Exp $
   */
> >>> +
> >>> +/*-
> >>> + * Copyright (c) 1982, 1986, 1993
> >>> + * The Regents of the University of California.  All rights
reserved.
> >>> + *
> >>> + * Redistribution and use in source and binary forms, with or without
> >>> + * modification, are permitted provided that the following conditions
> >>> + * are met:
> >>> + * 1. Redistributions of source code must retain the above copyright
> >>> + *notice, this list of conditions and the following disclaimer.
> >>> + * 2. Redistributions in binary form must reproduce the above
copyright
> >>> + *notice, this list of conditions and the following disclaimer
in the
> >>> + *documentation and/or other materials provided with the
distribution.
> >>> + * 3. Neither the name of the University nor the names of its
contributors
> >>> + *may be used to endorse or promote products derived from this
software
> >>> + *without specific prior written permission.
> >>> + *
> >>> + * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS
IS'' AND
> >>> + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
THE
> >>> + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
PARTICULAR PURPOSE
> >>> + * ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE
LIABLE
> >>> + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL
> >>> + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE
GOODS
> >>> + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
INTERRUPTION)
> >>> + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
CONTRACT, STRICT
> >>> + * LIABILITY, OR TORT (INCLUDING