Mostly to get firmware code fixes
Need some code adaptation in icE1usb firmware to
remove local usb_cdc_notif_serial_state struct
sine tt's included in no2usb cdc proto header now.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: I13e186627077c57329e4a83da11acc01ca5dce35
If the code is built either :
* without -flto
* with -fno-strict-aliasing
* with that struct as 'static' (so it's not on the stack)
Then all works fine. But in the current situation (without the
patch), GCC seems to think there is some aliasing and just plain
removed the `notif.bits = 1` bit of code in that functions
(no warnings printed ...).
Putting the struct as 'static' is the least awful workaround.
I didn't bother reporting bug upstream, because I can't reproduce
on a small test case and I'm sure I'd just get yelled at and that
the compiler is right for some reason ...
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: Ie0a2ce337ce4a9c08c3d27acc4d922a3e5892840
Those files barely even qualify for a license anyway but for
consistency's sake ...
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: I9585f7f01d2dc8393828aa264ae353e2a53a37dd
Bug introduced in da395cc922
but since we never had anyway to use manual mode before,
didn't get noticed ...
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: I6e2b6cf5c7c0c9deaf429be000770316ec88b9d4
This fixes the following Linux kernel error message on the host:
usb 1-1: config 2 has 2 interfaces, different from the descriptor's value: 3
Change-Id: Ideb816169a1e995907901c018e7bd2f963c1a831
Initially it was a good choice to keep the LIU driver in the host
software (easier debugging/changes). However, we never really needed it
to do anything but initialization of the LIU.
So in order to avoid having to teach osmo-e1d or other software the
details about the LIU initialization, let's do this from the firmware
*if* the e1d compatible USB configuration is used.
Closes: OS#5733
Change-Id: Id2217ff4573c4eebd816318128f256e85fb3c3bd
This adds a second USB configuration to the e1-tracer firmware. This
configuration is closer to the USB configuration of an icE1usb and hence
paves the way for using osmo-e1d with the tracer.
The main conceptual difference between the existing "legacy"
configuration and this new "e1d compatible" configuration is to have two
USB interfaces, one for each direction of the traced E1 interface. Each
interface has its own separate two altsettings, one for the disabled
and one for the enabled state.
Unmodified osmo-e1d will not work straight away with this, as it expects
ISO OUT and ISU Feedback endpoints, which a pure rx-only tracing device
of course doesn't have.
Related: OS#5733
Change-Id: I97062b9f12317b1b9b3855409c2380108cb921ff
Let's split the starting and stopping between the two channels.
This is a preparation for a future e1d-compatible mode where each
channel (direction) has its own USB interface and hence must be
individually started/stopped.
Related: OS#5733
Change-Id: I7492325352222269bf0ba1346511c7dfa99c4f64
Let's explicitly specify the VID/PID of the e1-tracer in the dfu-util
invocation 'make dfuprog' to avoid accidentially programming other
attached dfu capable devices.
Change-Id: I6a17f01a621cd4af6827167427fafd2f9f277755
This is disabled by default because turns out the kernel doesn't
actually support PPS on CD for USB-CDC devices :(
And this also increase the interrupt traffic ...
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: Ie5d163434323a23912228003add9870fafefedf9
The original algo is just somehting I originally came up with
on the spot and worked and I never got the time to revisit.
Now after some testing, I implemented a PID loop that seems to
present faster lock time and at least as good stability.
Parameters were not thorougly optimized just some 'hand' tuning
trying to simulate the behavior.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: Ie3ea7243aa4234585f1ace222632bb5580caca75
This is a pretty usefu stat as this is what actually matters
Note that structure is just extended so any call with a wLength
shorter will just get the beginning of the struct (usb stack
limits response to wLength) and thus is fully backward compatible.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: I0aa919d4870ca7e1b653b82ac4f76ed26b5e3b08
Those were low level debug meant to be temporary and somehow ended
up committed.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: Ie1b802f347b0de9ea82edb61faaba6094b8f4dfa
Fine tuning has a limited tuning range. If at some point we
hit the limits, we need to bit the bullet and try to 'transfer'
some of that to the coarse range as best as we can. Hopefully
we get it close enough to limit disruption.
Note that this should really never happen because although it's
limited, the tuning range should be good enough to absorb any
reasonable temperature / aging variation once we have coarse tuned.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: I2d9d348f5466f581b3d6d36c98847c47e2452f98
If we're in hold over mode and getting a bunch of invalid
frequency measurement despite a good fix, then we most likely
ended up on a bad tuning value and we need to recover by starting
from scratch.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: If8503a3eaf695e02a0ef0a3b6536de985d247c20
doing so significantly simplifies the development of a Linux kernel
driver, as the GPS-DO only exists once (not twice, like the per-E1-line
interface), and Linux kernel USB drivers typically are for an interface.
There is an option to write a usb_device_driver, but doing so will
exclude the per-interface drivers from still being probed in their usual
fashion.
While we introduce this new USB Interface for the GPS-DO, we also
move the related control endpoint requests from the device level to the
interface level.
Finally, some naming inconsistency between "enum
ice1usb_gpsdo_antenna_state" vs. the member name antenna_status is
resolved.
Change-Id: Icd6555a14896c38626fb147b78af44ff719f2254
The USB spec requires interface numbers to be in sequential order,
and the existing firmware fails that requirement, as is shown by
the Chapter9 test suite ("USB30CV").
With this patch applied, the USB30CV Chapter9 test suite passes.
Change-Id: I6a5434447ee20f77ce0ba9e7b1884cbd5b466439
Rather basic and not super well tested, use with caution
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: I5f9ce6621492be967d6a44d31f270e107f3ef686
Note that this is read-only. We drop all data from the host
because we can't have the host reconfigure the module ...
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: Ieb6a653ece882c5f90ab27da1bca04c94184dc5a
This only initializes the GPS module and keeps track of the
antenna and fix status
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: I24811f872fafefc7f8dfaa3028c4288001a87d2f
This allows the host driver to obtain the current errors, as they would
normally be reported over the IRQ endpoint. One important use case for
this is to obtain the initial error state when the driver starts up.
Change-Id: I6301bb23234c66afe083ceb500cff8a40813e8b6
We have upcoming ones not related to the E1 interface, so really
it make more sense to not have those in usb_e1.c
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: I686916bb2b2cb90e94ac9c595deab19f189fcd49
The hardware has a tick counter (constantly incremented every
cycle) and a pps counter (which is the tick counter captured
at the pps edge).
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: I2122ea3d636c8a430c6eb945b0c11e26e02fee43
The 32 bit register is split in different fields to speed up
access to the 'in' field. The oe/out fields can't be split because
all writes are 32 bit wide (i.e. no support for byte enable in the
gateware)
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: Ic25377bb777e5d25939f0e8cfe6b7c6ef8641f6d
Also don't force enable the runner in the e1_platform_led_set
callback.
Due to GPIO shortage, the E1 leds control are multiplexed with
SPI so this adds a method to temporarely stop the runner so SPI
can be used.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: Ie671daab5ee5e0b5f58de9d4fef1f0ca7d6d02b6
Those are already in the gateware, this just adds the define for
them.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: I87fae20e4a987c2186d5db6747e03e7ce9789a8f
The init already takes care of both port and also calling
e1_init, so it makes sense to have a usb_e1_poll() that
encapsulate both the actual e1 hardware poll and running
the usb stuff for both port.
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
Change-Id: Icf81efcdc5c8f13480ba2652bc6e7c1ca226ae4d
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
Sylvain Munaut
Harald Welte