sr: fx2lafw: Allocate header and packet struct on the stack

The header and packet struct are only used in the scope of this function and
they are freed at the end of it. Also these structs are rather small, so they
can safely be allocate on the stack. By doing so memory leaks on the error paths
are avoided.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
sr: fx2lafw: Properly free transfer

When freeing a transfer we also have to free the transfer buffer. We also have
to keep track of the number of allocated transfers and if the freed transfer was
the last one stop acquisition. This patch introduces a helper function which
takes care of all of this.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
sr: fx2lafw: Avoid unnecessary alloc/free combo

In receive_transfer for each completed transfer a new buffer is allocated and
the old one is freed. We can avoid this by simply reusing the buffer for the
next transfer. This is possible if we only resubmit the transfer after all
processing on the data buffer has been done. A new buffer is only allocated if
the size of the old one is not 4096 bytes.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
sr: fx2lafw: Handle the transfer's status

While errors are usually already implicitly caught by looking at the packet
length field there is one error status which is worth special handling. If the
device has been removed there is not really a chance to recover from this error
so data acquisition can be stop immediately.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
sr: fx2lafw: Calculate buffer size and timeout based on sample rate

Currently timeout and buffer size are hard-coded in the fx2lawfw driver which is
non-optimal if we want to get good results at both high and low sample rates.

The timeout is hard-coded to 40ms, which does not work well when sampling at with
a low sample rate. E.g. at 20kHz filling all available buffer space alone takes
6 seconds. So naturally we'll see a lot of transfers timeout in this case.

The buffer size is hard-coded to 4096 bytes, which does not work well with high
sample rates. E.g. at 24MHz these 4096 bytes are enough space for 0.17 ms of
data. The total buffer size is enough for about 5ms of data. Sooner or later the
application wont be able to resubmit a transfer within this time span and the
device will abort data acquisition. Usually this happens within the first few
seconds of sampling.

This patch adds a few new helper functions which calculate the buffer size and
timeout based on the current sample rate.

The buffer size is chosen to be large enough to hold about 10ms of data and it
also must be a multiple of 512 bytes since the firmware will send us the data in
512 chunks.

The timeout is set to the time it would take to fill the whole available buffer
space plus a 25% headroom to accommodate for jitter. This more than enough, but
there is no need to make the timeout a tight deadline, since it is only meant as
a last resort in case the device stops submitting data. And in this case data
acquisition will be aborted anyway.

The patch also limits the the number of transfers so that the total buffer space
is not much more of 500 ms, this will ensure that we do not have to wait too
long when aborting data acquisition.

This patch also significantly reduces the number of context switches when
sampling at a higher sample rate. On my system for example the CPU load of
sigrok-cli when sampling at 24Mhz goes down from ~25% to 3-4%.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
sr: fxlafw: Move empty_transfer_count to device ctx

If one device is failing it should not affect the transfers of other devices.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>