So, once BD are submitted to hw, we have to wait for them to get
back, and that's what the SHUTDOWN state is for. Now, this needs
to completete before we can call e1_start() again and so in case
it wasn't done in time, we just busy waited in e1_start().
Problem is that in the absence of a valid signal, the RX side won't
process anything and so we will wait forever.
For the TX side, if we are in remote tick config and we never had
any valid signal, this could also hang.
So we change this. There is actually no need to wait for the shutdown
to complete, we can resume where we left off.
For RX: We use the 'RECOVER' which basically waits for all pending BD
to be done, empty the fifo and auto-restarts. The only "side effect" is
that we'll loose up to 4 multiframe of data at the beginning but the
RX start is async anyway, no guarantee of where we pick up.
For TX: First we empty the FIFO from any data that wasn't already
submitted to the hardware (and is now stale) and we also use the
'RECOVER' state which will wait until the FIFO reaches nominal level
before starting feeding new data. The "side effect" here is we might
TX up to 4 multiframe of old data. Although this is rather unlikely
because the conditions for TX not to have transmitted those before
are unlikely (and hopefully go away completely with OS#5402)
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: I3f3de5491e0999f89a63f507fafdc4af8c22c905
Previously we were just doing a hard reset, calling init again.
And to stop, it was a bit harsh as well, just calling init with
0 as argument, not cleaning pending descriptors and such.
Now, the HW is initialized once and there is proper startup and
shutdown procedure, leaving things in the proper state.
Init of e1 hardware (call to e1_init) is also delegated to usb_e1
since it's that module that handles all state changes and config
so it makes sense it handles init too rather than calling it from
fw_app.c
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: I639f90ce3488a1a08e87854e74e0586010264f5d
Store Rx/Tx config separately so we can change some of the config
bit depending on current state while still keeping what the user
asked for.
Not really used ATM since state is never IDLE, but for future use.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: I0b4cbf88abc4af801054ba5d6779dede5649852a
Currently it's called 'reset' but really it's the init because
it sets up the memory allocation and such. We rename that to e1f_init
and introduce a true e1f_reset that only clears the fifo and resets
the pointers
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: I425c38e93fb235d5c5fc6f3a5027ac49cf3466d9
This is a bit cleaner when masking in/out those rather than using
the specific vaue that has all bits set.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: If2ca8efff37cb8fd1f1841656537ea8ad11ef55c
There is no remote side alarm if there is no remote-side ...
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: I78f43eded5ed6ffde9d86726ccee2b776a3f4675
* FIFO target level :
- The '8 * 16' makes no sense as the FIFO was 128 so this
is the "full" case and could never be that high.
- We tighten up the margin around 5 * 16 which is the "target"
level for the FIFO
* FIFO size :
We also increase the FIFO size to 256 frames. This doesn't
actually affect latency since the target level is the same,
but it allows more leeway to recover without data loss in
case something goes wrong.
* Ticks :
We don't bother using ticks ... the current algo wasn't
working (or rather not doing anything all that useful),
because the difference between USB clock and E1 clock is
tiny and measured over 1 ms, it's not meaningful.
So for the time being we just sent the nominal rate biased
with the FIFO level to keep it on target and this seems
to work fine.
It'd be nice to have a good long term estimate of the rate
to minimize the jitter, but it doesn't seem to be strictly
required for operation for now.
* Misc cleanup :
Just do all in one function instead of splitting the check
if BD needs refill and the actual refill.
This gets rid of sporadic 'TX FIFO Overflow' conditions
by properly handling the case where we have a bit too much
data.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: Ibd3bc9080961cc56093e43ab9a824840e84c24d2
Currently all the users of those function just statically use port 0
only.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: I17671be65543f5a2bf3d16ba2b5a5081eb38ebdf
Scan over every odd E1 frame TS0 byte to check if the A-bit is set,
indicating a remote alarm. If so, set yellow LED and report via the
error flags communicated to the host by USB interrupt transfer.
Change-Id: Ic4f57cf79bd32cf75f81ef3073cb8d4a2d1857d8
This introduces a number of vendor-specific control requests for
configuration of the icE1usb from the host software.
Closes: OS#4675
Change-Id: I9d28566ba21a2a78def5e4a0ba07ecbc4a583aa9
Those clear bits are only set once at start-up and then later
explicitly. They shouldn't be stored with the user configuration
in state variables.
Change-Id: If38e86aefea7f1be4e1ff5a88860f8be593eeedc
Whenever Rx is aligned, the green LED is permanently on.
Whenever Rx is not aligned, the green LED is blinking.
What's missing is to check for E1 clock ticks and turn the LED off
completely if there are no clock ticks.
Change-Id: I42d53544858dbbbae5206d9a62b08672966c9ebf
The position indicates where we are in terms of frame and multiframe.
The related code was ported over from e1-tracer.
Related: OS#4674
Change-Id: I9e59d86a2e8f4e85ca84c592438ad79966b49448
Currently only the icE1usb-proto is supported. Adaptation for the
final production hardware is yet to be done.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Sylvain Munaut
Harald Welte