> > "18.6.2 Forcible Stall by Application
> ...
> looks like clearing a halt requires letting the device software know
> by sending some vendor-specific message, in addition to simply sending
> a Clear Feature command. You have to wonder why they designed their
> controller that way.
I held on to
David Brownell wrote:
I've just implemented ep3 and have tried to test it using g_zero
(substituting "ep3in-bulk" for "ep2in-bulk" as you suggest) but it
has caused the host usbtest driver to crash when I plugged it in:
If it's that early, it suggests there's something wrong with
the descripto
Perhaps I'm limited by the speed of my CPU, I'm only running at about
66MHz, which is half of the maximum speed of the device.
Yes, I'd expect that would hurt PIO throughput.
The main thing that makes me wonder "bug??" is the "ep3" handling,
which is incomplete. That's the 8-byte Interrupt-IN
On Wed, 29 Oct 2003, David Brownell wrote:
> I think I'll have to merge this in dribs'n'drabs. I can do the
> build/config support right away; a Config.in entry would be good too.
> Also that first file_storage.c change (assuming Alan doesn't object).
I don't mind. But first remove the #define
David Brownell wrote:
For what it's worth I'm including my UDC driver as a patch against
your 2.4 gadget tree. I've only tried it with g_zero and
g_file_storage so those are the only changed gadgets. This patch
doesn't include any changes for stall free mass storage operation.
I'm sure ther
For what it's worth I'm including my UDC driver as a patch against your
2.4 gadget tree. I've only tried it with g_zero and g_file_storage so
those are the only changed gadgets. This patch doesn't include any
changes for stall free mass storage operation. I'm sure there are lots
of bugs in t
Julian Back wrote:
David Brownell wrote:
I'm not quite clear what the problem is here -- latch-without-clear?
That's what it sounds like: this chip design didn't really consider
how certain USB features get used, and endpoint halts may need to
be added to the list (with configs and altsettings).
On Wed, 29 Oct 2003, Julian Back wrote:
> Here is the relevant section from the device manual, it may explain the
> situation more clearly:
>
> "18.6.2 Forcible Stall by Application
>
> The application uses the EPSTL register to issue a stall request for the
> USB function module. When the app
David Brownell wrote:
You might want to pull the latest BK code from my trees, there have
been some stall-related changes recently. (Thanks to Pat LaVarre
and Alan Stern for helping sort this out, and I suspect they may
be able to provide further illumination...) The updates weren't
in BK 24 hou
Alan Stern wrote:
On Tue, 28 Oct 2003, David Brownell wrote:
My concern here to cleanup the usb_ep_set_halt() semantics so it
was usable for a "real driver", one that didn't need to care about
the hardware underneath it. I think we're probably as close as
we can get to that state now (BK-current
On Tue, 28 Oct 2003, David Brownell wrote:
> My concern here to cleanup the usb_ep_set_halt() semantics so it
> was usable for a "real driver", one that didn't need to care about
> the hardware underneath it. I think we're probably as close as
> we can get to that state now (BK-current), but we s
I've been having a discussion about this off-list with Pat LaVarre and
David Brownell. Our general conclusion has been that although the
no-stall option is better for the controller driver (since it doesn't have
to worry about halting endpoints) and might lead to somewhat increased
throughput, ne
Julian Back wrote:
Thanks to all on this list I have got my USB Device Controller Driver
for the SuperH working quite well. It works OK with the mass storage
gadget and I've tested it with Linux 2.4, Linux 2.6, Windows 2000 and
Windows XP hosts. We've also got the SuperH host controller at lea
On Tue, 28 Oct 2003, Julian Back wrote:
> Thanks to all on this list I have got my USB Device Controller Driver
> for the SuperH working quite well. It works OK with the mass storage
> gadget and I've tested it with Linux 2.4, Linux 2.6, Windows 2000 and
> Windows XP hosts. We've also got the
Thanks to all on this list I have got my USB Device Controller Driver
for the SuperH working quite well. It works OK with the mass storage
gadget and I've tested it with Linux 2.4, Linux 2.6, Windows 2000 and
Windows XP hosts. We've also got the SuperH host controller at least
partially worki
15 matches
Mail list logo
