Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

Uplift shmem from wr-switch-sw repo.
Fix previous uplift of shmem and improve debug printout.
Signed-off-by: Adam Wujek <adam.wujek@cern.ch>

Commit based on the commit from wrs-switch-sw described below.

userspace/libwr: printout more details when wrs_shm_write is called

It might be usefull to know whether caller wanted to lock or unlock the shmem
and which shmem.
Signed-off-by: Adam Wujek <adam.wujek@cern.ch>

Commit based on the commit from wrs-switch-sw described below.
Apply changes to the arch-wrs/wrs-startup.c to follow declaration change of
wrs_shm_alloc.

userspace/libwr: in shmem, use pointers to structs intead of void pointers

In shared memory functions take as parameters pinters to structures instead
of void pointers. By this compiler will warn when wrong type of pointer is
passed. For example when pointer to the data in shmem is passed instead of
pointer to the header.
Signed-off-by: Adam Wujek <adam.wujek@cern.ch>

The commit:
15076cb6 arch-wrs: improve locking of shmem
didn't fully apply the patch from the wr-switch repo.
This commit apply changes to arch-wrs/shmem.c that were missed
Signed-off-by: Adam Wujek <adam.wujek@cern.ch>

This shrinks p2p builds by 100 bytes, but increases by 100 bytes
the wrpc defconfig (the one withouth P2P code).
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

This saves 50 bytes in wrpc-sw (and more in x86 builds)
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

Here in ppsi,

  ./MAKEALL wrpc_defconfig wrpc_pdelay_defconfig

shows a very small difference, but most pdelay code is then
discarded by the wrpc-sw link time, due to --gc-sections.
This is the result:

   laptopo% ./MAKEALL spec_defconfig spec_pdelay_defconfig
   ##### Building with 'spec_defconfig'
   /opt/lm32-gcc-4.5.3/bin/lm32-elf-ar: creating libsdbfs.a
      text    data     bss     dec     hex filename
     87688    3492    6352   97532   17cfc wrc.elf
   ##### Building with 'spec_pdelay_defconfig'
   /opt/lm32-gcc-4.5.3/bin/lm32-elf-ar: creating libsdbfs.a
      text    data     bss     dec     hex filename
     93140    3492    6360  102992   19250 wrc.elf

What is missing now is the run-time choice between e2e and p2p. Later....
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

There is a size problem in wrpc-sw, when built with SNMP inside, so
some users, notably CERN, want to avoid the pdelay code (allegedly 7kB
in the binary).

Users who need pdelay don't actually run SNMP, so they don't have the
size problem.  This new setup allows a wrpc-sw without pdelay-related
code.  Wrpc with both mechanisms built in will be run-time configurable.

the wrs and unix configurations for peer delay are removed, because
for those architecture the choice is going to be performed at run time,
in the configuration file.

Please note that this commit is config-only, no code yet is there.
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

Using a data-driven approach to manage incoming frames is definitely
cleaner and clearer.  It even has a (very minor) size reduction for wrpc.

I plan to use this approach overall, as time permits.
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

This won't work, because packets must be sent to two different
IP multicast addresses. This is not supported.  The code being disabled
had the effect of setting the pdelay destination for all frames, even
for E2E runs.

This fixes E2E UDP operation, leaving P2P broken as it was.
Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

Signed-off-by: Alessandro Rubini <rubini@gnudd.com>

If no follow-up is to be received, we trigger pp_servo_got_presp()
on reception of peer delay response.

In this case we also possibly have switch to port state to PASSIVE.

A function should only do what it promises, so msg_unpack_header should
just unpack. This move also gets also us ready for fixing compliance
to 9.5.2.3.

This gets us ready for leaving a state as a consequence of filtered out
messages (9.5.2.3: discard announce AND switch state to PASSIVE).

    See Table 13.
    Note that we keep currentUtcOffset as it is and reset currentUtcOffsetValid,
    because  we presently don't know about leap seconds.
    leap59 and leap61 are forced to zero.

See Table 13.

See Table 20.

We don't support alternate masters at present.

We're not a transparent clock, so this should be ok.

We also avoid setting the same flag while handling a Pdelay_Resp_Followup.

remove duplication, remove code size

11.3 d says:

Upon receipt of the Delay_Resp message by the slave:

1) If the received Sync message indicated that a Follow_Up message will not
   be received, the <meanPathDelay> shall be computed as:
   <meanPathDelay> = [(t2 - t3) + (receiveTimestamp of Delay_Resp message -
   originTimestamp of Sync message) -
   correctionField of Sync message -
   correctionField of Delay_Resp message]/2.
2) If the received Sync message indicated that a Follow_Up message will be
   received, the <meanPathDelay> shall be computed as:
   <meanPathDelay> = [(t2 - t3) + (receiveTimestamp of Delay_Resp message -
   preciseOriginTimestamp of Follow_Up message) -
   correctionField of Sync message -
   correctionField of Follow_Up message -
   correctionField of Delay_Resp message]/2.

We assume that:

t1 = originTimestamp of Sync message (one step) or
t1 = preciseOriginTimestamp of Follow_Up message (two steps)

      and

t4 = receiveTimestamp of Delay_Resp message

wich is true for masters not supporting sub-nanosecond
timestamps (we don't support sub-ns precision via standard protocol, so the
assumption should be true for us).

As sync (or followup) arrives, we calculate m_to_s_dly, which is:

t2 - t1 - cf_sync - cf_followup

When delay_resp arrives, we calculate s_to_m_dly, which is:

t4 - t3 - cf_delay_resp

So [(m_to_s_dly + s_to_m_dly) / 2] should be equal to:

(t2 - t3 + t4 - t1 - cf_sync - cf_followup - cf_delay_resp) / 2

which looks like the 11.3 d expression for mean path delay
(note that cf_followup is zero for a one-step master).

To get this result, we just save the delay_resp cf to ppi->cField.

11.2 c says:

If the twoStepFlag bit of the flagField of the of the Sync message is TRUE,
indicating that a Follow_Up message will be received, then

        <offsetFromMaster> = <syncEventIngressTimestamp> -
       <preciseOriginTimestamp> - <meanPathDelay> -
       correctionField of Sync message -
       correctionField of Follow_Up message.

Before this patch, only the correctionField of the Sync message was
subtracted. We fix things by adding the Follow_Up correctionField to the
Sync correctionField.

Now m_to_s_dly as calculated in pp_servo_got_sync is:

t2 - t1 - sync_cf - follow_up_cf