> On 3 May 2019, at 02:31, Hans Petter Selasky wrote:
>
> On 2019-05-02 13:38, O'Connor, Daniel wrote:
>>> On 2 May 2019, at 20:33, Hans Petter Selasky wrote:
>>>
>>> On 2019-05-02 12:44, O'Connor, Daniel wrote:
> On 2 May 2019, at 20:02, Hans Petter Selasky wrote:
>
> On
On 2019-05-02 13:38, O'Connor, Daniel wrote:
On 2 May 2019, at 20:33, Hans Petter Selasky wrote:
On 2019-05-02 12:44, O'Connor, Daniel wrote:
On 2 May 2019, at 20:02, Hans Petter Selasky wrote:
On 2019-05-02 11:18, O'Connor, Daniel wrote:
OK, thanks.
To be honest I would much prefer to
> On 2 May 2019, at 20:33, Hans Petter Selasky wrote:
>
> On 2019-05-02 12:44, O'Connor, Daniel wrote:
>>> On 2 May 2019, at 20:02, Hans Petter Selasky wrote:
>>>
>>> On 2019-05-02 11:18, O'Connor, Daniel wrote:
OK, thanks.
To be honest I would much prefer to work out why this
On 2019-05-02 12:44, O'Connor, Daniel wrote:
On 2 May 2019, at 20:02, Hans Petter Selasky wrote:
On 2019-05-02 11:18, O'Connor, Daniel wrote:
OK, thanks.
To be honest I would much prefer to work out why this particular hardware &
software seem to drop the ball for such a long time -
> On 2 May 2019, at 20:02, Hans Petter Selasky wrote:
>
> On 2019-05-02 11:18, O'Connor, Daniel wrote:
>> OK, thanks.
>> To be honest I would much prefer to work out why this particular hardware &
>> software seem to drop the ball for such a long time - 50msec without the
>> kernel getting
On 2019-05-02 11:18, O'Connor, Daniel wrote:
OK, thanks.
To be honest I would much prefer to work out why this particular hardware &
software seem to drop the ball for such a long time - 50msec without the kernel
getting to schedule something (on a basically idle system) is quite perplexing to
> On 2 May 2019, at 18:06, Hans Petter Selasky wrote:
> On 2019-05-02 10:22, O'Connor, Daniel wrote:
>>> On 2 May 2019, at 06:15, Hans Petter Selasky wrote:
>>> On 2019-05-01 10:34, O'Connor, Daniel wrote:
I don't have a solid hypothesis for the failures as yes but one thing I'd
On 2019-05-02 10:22, O'Connor, Daniel wrote:
On 2 May 2019, at 06:15, Hans Petter Selasky wrote:
On 2019-05-01 10:34, O'Connor, Daniel wrote:
I don't have a solid hypothesis for the failures as yes but one thing I'd like
to make sure is that the USB stack is keeping the USB hardware busy
> On 2 May 2019, at 06:15, Hans Petter Selasky wrote:
> On 2019-05-01 10:34, O'Connor, Daniel wrote:
>> I don't have a solid hypothesis for the failures as yes but one thing I'd
>> like to make sure is that the USB stack is keeping the USB hardware busy
>> with pending requests - does anyone
On 2019-05-01 10:34, O'Connor, Daniel wrote:
I don't have a solid hypothesis for the failures as yes but one thing I'd like
to make sure is that the USB stack is keeping the USB hardware busy with
pending requests - does anyone know if the USB FIFO code does that
automatically?
Only the
Hi,
I have a device driver for a USB device (a custom Cypress FX2 based board) that
is relatively simple - it uses the USB FIFO code to create 3 FIFOs (one
bidirectional slow serial interface, one device->PC fast parallel interface
from a hardware FIFO) plus a bunch of ioctls for getting the
11 matches
Mail list logo
