Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 5 Jul 2013 12:24:00 -0700
From:      Oleksandr Tymoshenko <gonzo@bluezbox.com>
To:        Hans Petter Selasky <hps@bitfrost.no>
Cc:        arm@freebsd.org, usb@freebsd.org
Subject:   Re: Beaglebone USB driver (Mentor Graphics OTG)
Message-ID:  <49E5BE45-208C-4AAD-980D-590F32D9B600@bluezbox.com>
In-Reply-To: <A9072D24-1E28-47D2-A152-D962C74D1811@bluezbox.com>
References:  <51608AA4.2020804@bluezbox.com> <51611A7B.2010105@bitfrost.no> <0927BB4C-6917-408D-B102-AB98F72314B6@bluezbox.com> <51CBDFEA.7050203@bitfrost.no> <A9072D24-1E28-47D2-A152-D962C74D1811@bluezbox.com>

next in thread | previous in thread | raw e-mail | index | archive | help

On 2013-07-01, at 9:48 PM, Oleksandr Tymoshenko <gonzo@bluezbox.com> =
wrote:

>=20
> On 2013-06-26, at 11:47 PM, Hans Petter Selasky <hps@bitfrost.no> =
wrote:
>=20
>> On 06/27/13 02:53, Oleksandr Tymoshenko wrote:
>>>=20
>>> On 2013-04-07, at 12:04 AM, Hans Petter Selasky <hps@bitfrost.no> =
wrote:
>>>=20
>>>> On 04/06/13 22:50, Oleksandr Tymoshenko wrote:
>>>>> Hello,
>>>>>=20

.. skipped ..

>=20
> Writing 127 to FADDR breaks driver. It can't even attach device =
properly.=20
>=20
> I do not completely understand the scenario behind this requirement. =
My=20
> recollection is: when we cancel IN transaction somehow we should =
ensure=20
> that function that currently handles it does not stuck forever. =46rom =
what=20
> I see it's just impossible. There is internal NAK timer that fails the =
transaction
> once it reached configured value (or 3 by default AFAIR). Isn't it =
enough?
>=20
> I tried unloading active uwrtn driver - it unloads with some delay but =
as=20
> far as I can see from logs delay is not due to USB internal =
transactions code
> it must be upper layer.=20
>=20
> Could you, please, elaborate  on the matter?
>=20
> Here is updated version of the patch:=20
> =
http://people.freebsd.org/~gonzo/arm/patches/beaglebone-usb-20130701.diff
>=20
> Besides cosmetic fixes I also synced =
dev/usb/controller/musb_otg_atmelarm.c
> to the latest changes of core logic: added required wrappers and some=20=

> initializations.=20
>=20
> I do not longer have access to USB analyzer so my debugging abilities
> is somewhat limited now.

Hi Hans,

The driver seems to be fairly stable judging from my tests. I'd like to =
commit it
as-is, get more test coverage  from users and tighten up loose ends =
then.=20

What do you think?





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49E5BE45-208C-4AAD-980D-590F32D9B600>